Bild erzeugen aus Text - schneller als convert?

[reox]

Ich bräuchte in einem Video einen Timecode, also wieviele Millisekunden seit einem Event passiert sind. Für kdenlive (mit dem ich gerade arbeite) scheint der Workflow zu sein, sich ein Video als Overlay zu erstellen, dass den Timecode hat. Hier wird zB eine Seite genannt, die sowas anbietet: https://forum.kde.org/viewtopic.php?f=265&t=118225
Allerdings in einem sehr kleinen Format und es werden keine Millisekunden gezählt sondern Frames...
Ich dachte mir, das sollte man doch auch mit "Hausmitteln" hinbekommen... So schauts jetzt aus:

Code: Alles auswählen

#!/usr/bin/zsh

FPS=30.0
LENGTH=60.0 # in seconds

POINTSIZE=120

for tc in $(seq 0 $((1000 / FPS / 1000)) $((LENGTH))); do
    tc=$(printf "%0.4f" $tc | tr "," ".")
    S=$(date -u +"%H:%M:%S,%4N" -d "@$tc")
    echo -n -e "$S\r" 1>&2
    convert -size 1000x$((POINTSIZE + 20)) xc:white -font "FreeMono" -pointsize $POINTSIZE -fill black -annotate +0+$((POINTSIZE - 10)) "$S" png:-
done | ffmpeg -r $FPS -f image2pipe -s 1000x$((POINTSIZE + 20)) -i - -vcodec libx265  test.mp4

achtung, die float arithmetik geht nicht mit bash - da muss man wohl auf bc zurückgreifen, wenn es überall laufen soll.

Größtes Problem: Es ist wahnsinnig langsam! convert braucht zum erstellen des Bildes eine ganze weile...
Geht das noch irgendwie schneller? Ich mein oft muss man es ja eh nicht ausführen, aber trotzdem

[NAB]

Geht das noch irgendwie schneller? Ich mein oft muss man es ja eh nicht ausführen, aber trotzdem

Erst mal solltest du testen, ob es wirklich an "convert" liegt, dass es so langsam ist. Wenn ja, könntest du dir:
1) einmalig die Bilder 0.png bis 9.png, Doppelpunkt.png und Komma.png berechnen lassen.
2) diese gemäß dem Inhalt von $S Zeichen für Zeichen zusammenkleben:
http://www.imagemagick.org/discourse-se ... hp?t=11320

Wenn's dann immer noch zu langsam ist, könntest du BMP statt PNG verwenden.

[Meillo]

Dir scheinen Millisekunden und framegenaue Auszeichnung wichtig zu sein, darum wird meine Idee vermutlich nicht gehen. Sonst koenntest du es naemlich mit Subtitles probieren, aber ich glaube nicht, dass die so exakt sind.

[MSfree]

Erst mal solltest du testen, ob es wirklich an "convert" liegt, dass es so langsam ist

Ja, es liegt unter anderem auch an convert. Allerdings muß man für die Einblendung von ein paar Zahlen und Zeichen (hh:mm:ss.sss) kein 1000 mal X großen Bild rechnen, 12 Zeichen passen auch problemlos auf 150 Pixel Breite und 30 Pixel Höhe, und die lassen sich sehr schnell rendern.

[Lord_Carlos]

.png ist komprimiert, deswegen braucht es etwas CPU Leistung. Bei einer fixen Festplatte wueder ich wie NAB schon sagte mal BMP, oder TIFF .TGA versuchen.

Das kann einen sehr grossen unterschied machen.

libx265 braucht auch sehr sehr viel CPU. -preset fast kann da etwas abhilfe schaffen.

Echt bitter das man so ein gehacke machen muss.

[breakthewall]

Welche Hardware steht Dir eigentlich zur Verfügung? Anhand dessen ließe sich bereits abschätzen, inwieweit die Ausführungsgeschwindigkeit normal ist.

[Lord_Carlos]

top, htop oder ein anderer Pressemanager sollte anzeigen ob es h265 oder convert der Uebeltaeter ist.

Ich habe mal Hunderttausende 1440p .png erstellen wollen, das war selbst mit 6x 4Ghz + HT uebelst langsam. .TGA hat bei mir abhilfe geschafft.

[reox]

@NAB: Ja es ist sicher das convert. Wenn ich die Bilder speichere komme ich auf ca 1 Bild pro Sekunde.
selbst wenn ffmpeg noch langsam ist, dann ist ein sehr großer teil jedenfalls convert.
Ich wollte einen Transparenz layer haben, daher auch png. Ich habe anstelle von x265 jetzt mov genommen (ja mov!!!), weil das transparenz unterstüzt. in kdenlive muss man dann nicht mehr mit den alpah layern herumfummeln...

@Meillo: naja ich hab selber dann gemerkt, dass vermutlich die zehntel ausreichen, da man mehr im video nicht sieht. Aber es geht mir schon darum einen exakten Timecode zu haben.

@MSfree: nunja, die videos zum runterladen sind genau in der größe 150px... da sieht man bei einem Full HD Video nur noch pixel wenn man das größer macht. Die Schriftgröße habe ich extra so gewählt, damit man es wenns sein muss verkleinern kann - jedenfalls nie vergrößern muss.
Außerdem ist der unterschied zwischen 8pt und 120pt marginal. Das dauert gefühlt gleich lang.

@Lord_Carlos: tga kann ich noch probieren, ich hab es halt die paar minuten laufen lassen und gut is wie schon geschrieben, ist x265 auch gar nicht so gut, weil es keinen transparenz kanal kann...

@Breakthewal: i5 2400 4 kerne ohne HT, nvidia gtx660, 16GB RAM und 2 SSDs. Einen Xeon E31245 hätte ich auch noch...

Ich werd mal mit den Formaten herumprobieren!
die beste lösung ist wohl mal in der Nacht alle möglichen Timecodes zu erstellen und für immer und ewig zu speichern

[Lord_Carlos]

Dies hier kann nicht was du willst? https://userbase.kde.org/Kdenlive/Manua ... namic_Text
Sieht so aus als wenn es auch frames zaehlt.

[reox]

Dies hier kann nicht was du willst? https://userbase.kde.org/Kdenlive/Manua ... namic_Text
Sieht so aus als wenn es auch frames zaehlt.

Ähhhh ja...
Schön das die das Feature so toll versteckt haben, dass ich es nicht gefunden habe.

Naja aber vllt kann man das script ja nochmal für was anderes gebrauchen. Ich werd trotzdem mal mit den Formaten herumprobieren, was da am schellsten geht.

[Lord_Carlos]

Erstes Ergebnis bei google

[reox]

komisch, ich hab ewig lang nach timecode, timer und ähnlichem gesucht und nur den Forenbeitrag gefunden... Ich hatte mir schon irgendwie gedacht, dass sowas eigentlich bei einer Videoschnittsoftware dabei sein sollte.
Wenn ich nach "timecode kdenlive" suche, ist es tatsächlich auf platz 1. Bei dem suchbegriff "timer kdenlive"/"stopwatch kdenlive" kommt bei mir der forenbeitrag...