Frame zu Timecode zu EXIF, Go is no go

Neben 4K Video braucht man eigentlich keine Photos. Die Frame Exports sollten nur eben EXIF Daten haben. Ich wollte erst an die Videoloupe-Macher eine email schreiben, die ja schon die Frame-Nummer in den Filenamen einsetzen, stieg dann aber doch kurz in eine handgemachte Lösung ein.

ffprobe -v 0 -of csv=p=0 -select_streams 0 -show_entries stream=r_frame_rate video gibt die fps aus, was man weiterverwursteln kann. Ein Perl Modul timecode schien am besten. Plan ist, dann mal per Bash:
1. File aus Exportname (Videoloupe) finden
2. Startzeit des Videos erhalten ffprobe -v quiet input.mp4 -print_format json -show_entries stream=index,codec_type:stream_tags=creation_time:format_tags=creation_time
3. Regex der Frame-Nummer erhalten und daraus die Zeit im Video errechnen (frames * milliseconds je frame)
4. Einbindung der Realzeit als EXIF und speichern

Eigentlich einfach aber nicht die Tagesaufgabe aber das geht hoffentlich mal während downtimes mit bash.

Weitere Zeitverschwender heute:
PHP7.3 hat ’nen Bug – musste die JIT Sache ausschalten.

Telize läuft statt auf Openresty jetzt auf dem kore Framework. Extrem schnelles C-Web-Framework mit Python Bindings. Die Kompilierung brauchte libmaxminddb und ließ sich dann auf dem Mac doch nicht kompilieren. Versuch der Sache auf Ubuntu – kore 3.2 aus dem tar kompiliert und installiert, dann klappte der build. Das Ding lief auch, nur bekam ich per curl bei den endpoints ein 404. Keine Ahnung! Das etzte commit war eben erst vor ein paar Stunden. Performance-technisch sollte das Ding aber das schnellste sein, was es gibt. Leider vermehrte ich mir Zeit, weil ich einfach keine Antworten vom Server bekam. Selbst filemap wurde nicht im config erkannt. Ich gab hier erst mal auf und nahm einfach das feegeoip Dockerimage, was problemlos lief. Ist nicht mehr aktuell doch apilayer/freegeoip/ wollte wohl ’nen login.

Zusammen mit nginx wäre dann auch nginx-proxy cool. Man optimiert sich schnell Sachen zusammen, die am Ende nicht laufen. Docker geht wenigstens, so wie ich das sehe. Mit docker stats gab bei dem GeoIP Teil RAM belegung von 130 Mbyte aus. Sparsam sieht anders aus aber ich muss was zu laufen bringen. Ein paar GB mehr RAM sind immer noch billiger als die Alternative. Noch billiger scheinen vor traction einfach externe Services. Damit geht’s jetzt weiter. Den ganzen Unfug mit Installationen spare ich mir für einfachere Zeiten.

Zurück zu wttr:
go clean -i -n github.com/schachmat/wego
go get -u github.com/tschwery/wego

Damit war’s aber nicht getan, weil ich die PNG render branch wollte. In Go ging das über den Umweg:
Erst mal ’nen Wetterfont installiert. Dann die branch ausgecheckt:

git clone https://github.com/tschwery/wego.git
cd wego/
git checkout png-renderer
go build

OK, ging, nur die config nicht und es hatte sich hier wohl nichts geändert. Remote branches gehen mit dem go Import-System basierend auf git URLs eben nicht so einfach. Ich probierte eine Weile herum aber das war schon heftig demotivierend. Dann mit Tower merge und rebase und es ging trotzdem nicht. Muss mich doch mit dem golang build Prozess beschäftigen, was wieder nichts Sichtbares bringt.

Enttäuschend unproduktiver Tag.

0 Responses to “Frame zu Timecode zu EXIF, Go is no go”


Kommentare sind zur Zeit nicht möglich.
2018-12-18_15-41-31_RIMG6228.jpg
2018-12-18_15-41-31_RIMG6228.jpg
2018-12-18_15-41-40_RIMG6229.jpg
2018-12-18_15-41-40_RIMG6229.jpg
2018-12-18_15-42-03_RIMG6230.jpg
2018-12-18_15-42-03_RIMG6230.jpg
2018-12-18_15-43-54_RIMG6232.jpg
2018-12-18_15-43-54_RIMG6232.jpg
2018-12-18_15-44-09_RIMG6235.jpg
2018-12-18_15-44-09_RIMG6235.jpg
2018-12-18_15-44-14_RIMG6236.jpg
2018-12-18_15-44-14_RIMG6236.jpg
2018-12-18_15-44-56_RIMG6238.jpg
2018-12-18_15-44-56_RIMG6238.jpg
2018-12-18_15-45-01_RIMG6239.jpg
2018-12-18_15-45-01_RIMG6239.jpg