Beiträge von jb_alvarado

Hier an ganz einfaches Beispiel:

Habe das Video verwendet:
https://www.youtube.com/watch?v=ybPtPFAww_A

umbenannt zu talking.mp4 und dann folgenden Befehl für rawvideo abgesetzt:

for i in talking.mp4 talking.mp4 talking.mp4 talking.mp4; do ffmpeg -i $i -pix_fmt yuv420p -r 25 -af apad -shortest -c:v rawvideo -c:a pcm_s16le -ar 44100 -ac 2 -threads 2 -f avi -; done | ffmpeg -thread_queue_size 256 -i pipe: -c:v libx264 -c:a aac test.mp4

Am Ende siehst du schon dass es nicht mehr sync ist. Hingegen mit:

for i in talking.mp4 talking.mp4 talking.mp4 talking.mp4; do ffmpeg -i $i -pix_fmt yuv420p -r 25 -af apad -shortest -c:v mpeg2video -b:v 50000k -minrate 50000k -maxrate 50000k -intra -c:a mp2 -ar 44100 -ac 2 -threads 2 -f mpegts -; done | ffmpeg -thread_queue_size 256 -i pipe: -c:v libx264 -c:a aac test-sync.mp4

bleibt es sync.

Normalerweise würde ich dazwischen noch einen Buffer setzten, aber so geht es zu Not auch.

Edit:
ich glaube du hast doch recht, apad funktioniert nur wenn Audio kürzer ist, aber nicht wenn Audio länger ist. Werde mal noch weiter testen ob es wirklich das ist und was ich dagegen tun kann, vielleicht reicht ein -shortest wirklich schon. Habe das immer nur in Kombination mit apad verwendet.

Zitat von sneaker2

Puh, ich habe da nicht wirklich Ahnung von. Meine Vermutung, warum es irgendwann Async wird: Video- und Tonspur sind nicht immer gleich lang.

Die Vermutung hatte ich auch schon, dafür habe ich: -af apad -shortest mit eingebaut, aber das hilft nicht. Auch hat mpegts nicht das Problem, da bleibt es sync.

Ich habe das Python Projekt noch gefunden: https://github.com/Zulko/moviepy . Da geht man generell anders mit Videofiles um - es werden die Clips in einzelne Frames auf gesplittet und gepipet. Auch ein interessanter Ansatz! Allerdings bin ich in Python noch nicht so fit um da komplett durch zu steigen. Vielleicht versuche ich mich da mehr einzuarbeiten und diesen Ansatz zu verwenden.

Hallo zusammen!

Ich habe eine Methode gefunden, wie ich mit ffmpeg beliebig viele Videos aneinanderreihen kann, ohne dass es zur Unterbrechung kommt. Damit kann ich z.B. Playlisten streamen, brauche mir keine Gedanken über das Quellformat machen und die Listen sind jederzeit dynamisch editierbar (nicht wie bei concat).
Dazu entwickle ich gerade ein Python Tool: https://github.com/jb-alvarado/ffplayout

Im Prinzip funktioniert das ganze so, dass ich über einen Haufen Clips loope und mit ffmpeg abspiele, das ganze in einen Buffer (pv, oder mbuffer) pipe und den Output wieder in ffmpeg einspeise. Als Shell Script würde das dann so aussehen:

for i in *.mp4, do
    ffmpeg -i "$i" [codec settings] -f mpegts -
done | muffer -m 31000k | ffmpeg -i pipe: [codec settings] -f flv rtmp://address...

Jetzt ist mir nur folgendes Aufgefallen:

• nehme ich mpegts als pipe Format, muss ich den Stream verlustbehaftet kodieren bevor die zweite ffmpeg das ganze noch mal komprimieren muss. Am besten würde hier mpeg2 funktionieren, es kommt nur gelegentlich mal zu Warnungen das die PTS korrigiert werden müssen
• verwende ich hingegen avi als pipe Format kann ich einen rawvideo Stream in die Pipe schicken, es kommt zu keinen Fehlermeldungen wegen PTS und ich habe einen (fast) verlustfreien Stream in der Pipe. Allerdings läuft hier Audio und Video mit der Zeit asynchron.
• würde ich nur Clips nehmen die alle gleich kodiert sind und ich mit Stream Copy arbeiten wollte, funktioniert das nur reibungslos mit dem Format ismv, allerdings habe ich wieder das gleiche Problem, dass der Stream asynchron wird.

Am liebsten wäre mir Szenario 2 und 3. Ich hätte zwei verschiedene Anwendungen, wo das für mich praktisch wäre, allerdings bekomme ich es nicht hin Audio und Video synchron zu halten.

Habt ihr eine Idee, warum sich die Container unterschiedlich verhalten und wie ich das hinbekommen könnte das alles synchron bleibt?

Grüße

Jonathan

Ah cool, hast du es noch hinbekommen! Danke! Ja zu einer bestimmten Zeit ein und ausblenden wäre noch nötig. Zum Geschwindigkeitsvergleich brauche ich es aber erst mal nicht, da reicht der trim. In ffmpeg hatte ich es zuerst nicht hinbekommen: loop auf input; trim, fade und overlay so zu kombinieren, dass nur im eingeblendeten Zustand der overlay berechnet wird. Das hat dazu geführt, dass die Kompression ziemlich langsam war.

Jetzt schaut der Befehle in etwa so aus:

ffmpeg -i video.mkv -loop 1 -i image.png -filter_complex "\
[1:v]split[sp1][sp2];\
[sp1]fifo,trim=duration=5,fade=t=in:st=0:d=0.5,fade=out:st=4.5:d=0.5,setpts=PTS+2/TB[ps1];\
[0:v][ps1]overlay=enable=between(t\,2\,7)[ov1];\
[sp2]fifo,trim=duration=5,fade=t=in:st=0:d=0.5,fade=out:st=4.5:d=0.5,setpts=PTS+50/TB[ps2];\
[ov1][ps2]overlay=enable=between(t\,50\,7)[out]"\
-map "[out]" ...

Damit geht es gut.

Werde morgen mal Beides vergleiche und berichten, was schneller ist.

Grüße

Edit: Das mit dem Vergleichen scheitert daran, dass ich das ganze in OSX nicht gescheit zum laufen bekommen und ffmpeg jetzt mit den obigen Parameter ziemlich flott ist und ich kaum glaube, dass vapoursynth hier schneller wäre.

Danke fürs ausführliche testen Selur! alpha=False hatte ich auch versucht, war die einzige Möglichkeit das Image überhaupt angezeigt zu bekommen, allerdings dann ohne Alpha. aplha=True braucht immer Fehlermeldungen, egal was danach kommt. Schade, dass das nicht so ohne weiteres geht, sind ja eigentlich ganz rudimentäre Compositing Funktionen, die schon seit Jahrzehnten im Schnitt verwendet werden, dass das nicht richtig unterstützt wird ist eigenartig.

Im Prinzip kann ich auch bei meiner ffmpeg Variante bleiben - da ging's ja grundsätzlich - muss nur noch die Performanceprobleme in den Griff bekommen.

Hallo Allerseits,
ich setzte mich das erste mal mit Vapoursynth auseinander und versuche nun ein png Bild (mit Alphakanal) über ein Video zu legen. Also das Resultat sollte so ausschauen, dass ich ein Video habe wo eine Bauchbinde an bestimmter Stelle für, sagen wir 10 Sekunden, ein und ausgeblendet wird. Die Bauchbinde hat dabei die gleiche Auflösung wie das Video nur eben mit Transparenz so das nur ein Balken gesehen wird.

In FFmpeg habe ich das ganze schon hinbekommen, allerdings würde ich es gerne mal in Vapoursynth umsetzten und die Geschwindigkeit vergleichen.

Mein Testscript schaut momentan so aus:

import vapoursynth as vs
core = vs.get_core()
video = core.ffms2.Source(source='1.mkv')
image = core.imwrif.Read('2.png', alpha=True)


image = image * 50


out = core.std.Merge(clipa=video, clipb=image, weight=[1, 1])
out.set_output()

Leider funktioniert das so nicht, weil der Alphakanal nicht akzeptiert wird.

Wisst ihr wie hier der richtige Ansatz wäre?

Grüße

jb_

Also es ist so, dass wir vorher mpeg2 hatten und da ging immer alles problemlos. Allerdings wollten wir etwas Speicherplatz sparen und haben uns deshalb entschieden zu h264 zu wechseln. Die Videos werden nicht gelöscht, somit werden es mit der Zeit immer mehr.

Wenn die Clips mit Adobe Media Encoder komprimiert werden, tauchen auch keine Fehler.

Habe jetzt noch mal versucht die Settings von Adobe zu übernehmen, soviel gibt mediainfo da auch nicht preis und jetzt sind mir keine Fehler aufgefallen. Dort wird Level 5.1 eingestellt und reference frames 2 (vorher hate ich nur 3,4,6 und 8 versucht). Meine Zeile schaut demnach so aus:

ffmpeg -hide_banner -i 'input.mp4' -vf scale=1024:576 -pix_fmt yuv420p -sws_flags lanczos+accurate_rnd+full_chroma_int -c:v libx264 -b:v 1.8M -preset slower -g 12 -level 5.1 -refs 2 -x264opts bframes=1:vbv-maxrate=2000:vbv-bufsize=2000:nal-hrd=cbr -c:a aac -b:a 192k output.mp4

Adobe verwendet auch kein CABAC. Hatte ich testhalber auch mal ausgemacht, aber keinen Unterschied festgestellt. Könnte das Auswirkung haben?

Ja, sneaker2, du hast recht, da kann was nicht stimmen. Bei dem Test, wo die bframes aus waren, habe ich nicht nachgeschaut welche Frames nicht angezeigt werden.

Edit: es scheint wohl wirklich an den Referenz Frames zu liegen. Habe die nun auf 2 und nutze wieder crf ohne Profile und Level zu setzen und funktioniert. Hoffen wir mal, dass das bei allen Clips so ist.

Leider waren jetzt doch wieder Fehler drin. Was ich bis jetzt herausgefunden habe:

- man kann das ganze wirklich bis aufs Frame genau reproduzieren
- setzte ich Referenzframes manuell runter tauchen mehr Fehler auf
- cbr/vbr bringen beide Fehler
- kleine GoP Sizes scheint das ganze besser zu machen
- bframes deaktivieren hilft nichts
- bframes auf 3 verschiebt die fehlerhaften Frames an eine andere Stelle
- wenn ich richtig gerechnet habe tauche die Fehler, wenn sie auftauchen, bei einem bframe auf

Danke für den Hinweis, monarc! Der Kompressionsvorgang läuft jetzt schon seit ein paar Tagen, aber ich werde gerne noch mal diesen Parameter testen.

Grüße

Jonathan

Hatte jetzt noch mal getestet:

Variable Bitrate (b:v 1.6M; minrate 1M; maxrate 2.4M) > Fehler
crf 19 > Fehler, aber nur 1 Frame lang
crf 20 > Fehler
Konstante Bitrate (b:v 1.8M; minrate 1.8M; maxrate 1.8M) > keine Fehler (zuminest bis jetzt nicht)

Alle Test haben bframe=1 und -x264opts force-cfr=1 -vsync 1, also im Prinzip die Settings vom letzten Post.

Ja eigentlich verwende ich auch immer crf, allerdings habe ich die meisten Fehler wegbekommen durch cbr. Meine Vermutung war, dass die Bitrate zu sehr runtergeregelt hat, bei Standbilder und daher die Fehler kamen.

Bei diesen Files geht Qualität vor Größe und die durchschnittliche Größe von den Clips ist noch im Raum des Vertretbaren (ca. 580 mb für 40 Minuten Clip). Viele Clips die in das Streaming Programm geladen werden, sind schon mal komprimiert worden und hinter der Streaming Software hängt noch mal ein Kompressionsvorgang, der fürs Web komprimiert. Da will ich nicht unnötig geizen mit den Bits.

Ok, danke für die Info! Was hällst du dann von diesen Settings:

ffmpeg -hide_banner -i "$lName" -vf scale=1024:576 \
-pix_fmt yuv420p -sws_flags lanczos+accurate_rnd+full_chroma_int -c:v libx264 -b:v 1.8M \
-preset slower -g 12 -minrate 1.8M -maxrate 1.8M -bufsize 1.8M -x264opts force-cfr=1:bframes=1 -vsync 1 \
-c:a aac -b:a 192k -threads 11 -nostdin "$dNName/${nName}.mp4"

der Thread ist schon etwas älter, meinst du die Thematik ist immer noch aktuell? Dort habt ihr b-frame=1 genommen. Wäre das immer noch deine Empfehlung? Müsste recht schnell entscheiden, weil ich den Komprimierungsjob schon gestartet hatte. Jetzt kann ich ihn noch stoppen und neu starten. bei ~1650 Files zählt jede Stunde :).

Die Codec Settings, die sich ergeben sind diese:

cabac=1 ref=8 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=9 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 \
threads=11 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 \
keyint=12 keyint_min=1 scenecut=40 intra_refresh=0 rc_lookahead=30 rc=cbr mbtree=1 bitrate=1800 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=1800 vbv_bufsize=1800 nal_hrd=none \
filler=0 ip_ratio=1.40 aq=1:1.00

Ah ok, na dann habe ich jetzt beides eingestellt :). Kein crf sondern: -b:v 1.8M -minrate 1.8M -maxrate 1.8M -buffsize 1.8M -x264opts force-cfr=1 -vsync 1. Zusätzlich habe ich nun Profile, Level und ref nicht mehr beschränkt und die GoP Size ist nun auf 12. Damit sind mir bis jetzt keine Fehler mehr aufgefallen. Wenn B-Frames nicht unterstützt werden würden, müssten doch generell Fehler auftauchen und nicht nur bei Standbilder, oder? Auch schreibt die Doku, wenn etwas von dem Codec nicht unterstützt werden würde, es auf das Ouick Time zurückgreifen würde, zum decodieren.

Hallo monarc, danke für deine Antwort. Ich habe das jetzt mal versucht, mit der konstanten Bitrate, scheint schon viel besser zu funktionieren, aber noch nicht 100%. Wundern tut es mich, dass es nur in diesem einen Programm so ist. Selbst in Premiere kann ich die Clips einladen und dort tauchen die Fehler auch nicht auf.

Hallo Allerseits,

wir haben hier ein Problem was wir bis jetzt nicht lösen konnten und jetzt hoffe ich, dass mir hier vielleicht jemand helfen kann.

Es ist so, dass wir Videos in ffmpeg nach mp4/h264/aac komprimieren und diese werden dann in "Cinegy" (ein Playout Programm) geladen und gestreamt. Nun ist es so, dass Cinegy vereinzelt Frames nicht darstellt. In der Programmvorschau taucht dann "Media Offline" auf und im Stream ist es dann schwarz. Wenn es vorkommt, dann sind es so 2-8 Frames ca.. Auch scheint es immer nur vor zukommen wenn im Video gerade ein Standbild ist, z.B. eine Powerpointfolie.

Dieses Problem tritt auch nur in diesem Programm auf. In VLC, Quick Time, mpv, sieht man nichts. Wenn ich das ganze in ein mov packe, scheint es besser zu sein. Allerdings wird das auch nicht immer ganz sauber abgespielt und die Clips haben ein paar mehr Frames, wodurch unsere Datenbank nicht mehr übereinstimmen würde.

Hattet ihr schon mal so ein Problem und wisst ihr was man da machen kann? Ich dachte schon, vielleicht liegt es an der variablen Bitrate, aber sicher bin ich mir auch nicht.

Unsere Setting sind:

ffmpeg -i "input" -pix_fmt yuv420p -s 1024x576 -sws_flags lanczos -c:v libx264 -crf 20 -preset slower -g 25 -profile:v Main -level 3.1 -refs 4 -maxrate 3M -bufsize 3M -c:a aac -b:a 192k -threads 8 "out.mp4"
mp4box "out.mp4" -hint -brand mp42 -out "output.mp4"

Grüße

jb_

Der Punkt LGPL(v3) wurde auf Wunsch eines Users hinzugefügt.

Das Problem mit mintty wurde in der Readme behandelt und beschrieben wie man das fixen kann. Steht ganz groß auf der Hauptseite:

Zitat

mintty

Recent mintty changes force use of a flag that didn't exist in previous versions. If a window shows up while running the .bat file complaining with something about mintty, fix with:
run mintty using the shortcut
enter and run pacman -Sy --noconfirm --force mintty
close mintty and re-run the .bat as normal

Naja wenn es sich nicht wirklich um einen Fehler, sondern um eine Limitierung handelt, könnte es schon problematisch sein :).

Danke für die Hinweis! Habe auch mal hingeschrieben.

Die Dateien sollten jedes mal überschrieben werden.