slashCAM Forum

Hallo Zusammen,

ich habe gerade in Problem welches mir Kopfzerbrechen bereitet:

Ich habe einen Clip aus FCPX in h264 exportiert. Bis hier stimmt noch alles.
Wenn ich diesen nun auf youtube hochlade ist die Audiospur nicht mehr synchron, sondern kommt knapp 1,5 frames zu früh. Um den Fehler einzugrenzen habe ich das gleiche mit einem ProRes 422HQ File gemacht: Gleiches Ergebnis. Bei Facebook(Video) passiert dies ebenso.
Um den Fehler weiter einzugrenzen habe ich das ProRes und auch das h264 file mit Handbrake konvertiert. Verschiedene Settings ausprobiert, immer das gleiche Ergebnis => 1,5 frames zu früh. Auch mal verschiedene Audio-Samplerates ausprobiert ohne Erfolg. Jetzt weiß ich leider nicht mehr was ich noch testen könnte. Entweder macht FCPX irgendwas mit den Files, dass kein anderer Encoder mehr was damit anfangen kann oder ich habe irgendwas übersehen. Das Quellmaterial in FCPX macht übrigens auch keinen Unterschied. Habe zum Testen mal ein Projekt nur mit Generatoren aus FCPX erstellt und das Problem bleibt das gleiche.

Irgendeine Idee? (Wenn ich aus FCPX direkt zu youtube hochlade bleibt das Problem auch bestehen. Habe jetzt als workaround die Audiospur extra nach hinten geschoben, aber das kann ja nicht die Lösung sein…)

Ein YouTube-Link zu einem Demovideo wäre hilfreich.

Korrektur:

Auf youtube ist Audio ein Frame zu spät, mit Handbrake 1,5 Frames zu früh.

Hier auf youtube:

Hier das original h264 aus FCPX: https://we.tl/B4nXuYiCGj
Und hier das h264 mit Handbrake aus dem ProRes File generiert: https://we.tl/iz7AXfUR5k

smfoo hat geschrieben: ↑Fr 13 Apr, 2018 16:38
Hier das original h264 aus FCPX: https://we.tl/B4nXuYiCGj

er sagt mir nur:
Wir konnten einige wichtige Teile der Webseite nicht laden.

das ist aber ein sehr sophistisches Problem:
1.5 Frames sync-offset entspricht bei 50fps ca 10m Micro-Abstand.
Das ist nix, was man bewussst wahrnehmen könnte.

was kommt denn aus FCPX raus?
Die Äppelei macht manchmal auch VFR, das bringt bekanntermaßen manchmal sync-Probleme
beim de-/um-codieren.
Also zuerst CFR forcieren.

Hm, die wetransfer Seite funktioniert bei mir.
Aus FCPX kommt 25fps cfr raus.

Bezüglich der Wahrnehmbarkeit: Vielleicht schwankt das auch je nach File, ich bin jedenfalls nur darauf gekommen, weil ich es nach dem upload gemerkt habe, nicht weil ich danach gesucht habe. Ich müsste das noch mal basierend auf dem Originalvideo bei dem das Problem zum ersten mal aufgetreten ist checken.

Ich kann es mit dem Demovideos zumindest in einer Analyse bestätigen. Vielleicht hat es damit zu tun, dass YouTube daraus eine variable Framerate macht und zudem ein Flag mit "First Frame Duration -40 ms" schreibt. Allerdings sehe ich die Asynchronität der YouTube-Version beim Abspielen im Browser nicht. Dort wirkt der Ton an manchen Stellen sogar 1 Frame zu früh, da der Browser hin und wieder ein Videoframe verschluckt.

Es sind 25 fps und somit 60 ms (milli, nicht mikro) bei 1,5 Frames.

verwendest du ein aktuelles fcpx?

ich kenne dieses problem nämlich eigentlich nur von alten quicktime-versionen, die tatsächlich fast regelmäßig diese off-by-one fehler gezeigt haben, wenn man sie mit irgendwelchen ffmpeg basierenden lösungen weiterverarbeitet hat. darum finde ich es ja eigentlich auch ganz schlau, derartige probleme vor den upload zu youtube eben auch mit genau solchen playern zu kontrolieren, die sich auf die selben mechanismen stützen, wie sie dann auch bei den großen netzanbietern in der weiterverarebeitung genutzt werden.

Ja, es ist die aktuelle fcpx version. Die kam ja erst vor einigen Tagen und vorher hatte ich das Problem eigentlich nicht. Vielleicht liegt da auch der Fehler.

@Marco: Hast du eine Quelle zu der "First Frame Duration -40 ms" Angabe? Habe das gerade gegoogelt, aber nichts gefunden. Nicht dass ich dir nicht glaube, wollte nur genauer dahinter steigen.

Diese "Duration - 40 ms" ist die Information, die MediaInfo zu der Datei ausgibt, die ich als 1080p25-Version von YouTube runterladen habe. In deiner FCP-Version ist dieses Flag dagegen nicht vorhanden.

-40ms ist OK denn es darf auch wie bei vielen DVD's -80ms sein,
den das ist genau die Zeit bis der Ton das Ohr erreicht.

Ja, bei einem Betrachtungsabstand von 13 Metern zum Display würden 40 ms passen, wenn es +40 ms wären oder wenn die -40 ms den Ton beträfen. Es sind aber -40 ms fürs Bild. Bild wird vorgezogen, nicht Ton. Und 13 Meter Entfernung ...

Zweifeln darfst Du - mehr nicht, denn so ist die Regel.

Marco hat geschrieben: ↑Fr 13 Apr, 2018 21:12 Ja, bei einem Betrachtungsabstand von 13 Metern zum Display würden 40 ms passen, wenn es +40 ms wären oder wenn die -40 ms den Ton beträfen. Es sind aber -40 ms fürs Bild. Bild wird vorgezogen, nicht Ton. Und 13 Meter Entfernung ...

falsch, bild ist lichtgeschwindigkeit, ton schallgeschwindigkeit, also im zweifel ton vor bild...

lg

srone

Also, die Unterschiede zwischen den verschiedenen Varianten kann ich mir grade auch nicht erklären, aber ich finde es zumindest grundsätzlich verwegen, bei der Wiedergabe eines YouTube Videos zu erwarten, dass quer über alle involvierten Geräte und Wiedergabebedingungen eine 100% Bild-Ton-Synchronität erhalten bleibt. +/- 1 frame würde ich sogar schon für aussergewöhnlich gut halten, ich bin sicher, dass die statistische Realität weit darüber liegt.


- Carsten

Ich finde diese "share" Funktion total zum k*tzen. Allerdings finde ich 1 oder 1.5 frame Versatz und mehr, laufend auf tube also nix besonderes IMHO. Vielleicht hast Du ja einen bug entdeckt? Wenns in der älteren Version nicht so war?

»also im zweifel ton vor bild «

Ja, eben. Es geschieht hier aber genau umgekehrt.

» denn so ist die Regel. «

Die Faustregel ist, dass pro Meter Entfernung eine Tonverzögerung von 3 ms entsteht.

carstenkurz hat geschrieben: ↑Fr 13 Apr, 2018 22:22 ...ich finde es zumindest grundsätzlich verwegen, bei der Wiedergabe eines YouTube Videos zu erwarten, dass quer über alle involvierten Geräte und Wiedergabebedingungen eine 100% Bild-Ton-Synchronität erhalten bleibt. +/- 1 frame würde ich sogar schon für aussergewöhnlich gut halten, ich bin sicher, dass die statistische Realität weit darüber liegt.

für die reale ausgabe an diversen geräten mag das schon stimmen, aber zumindest die heruntergeladene datei sollte trotzdem frei von diesem fehler sein.

Ich kenne gar keinen 'offiziellen Weg' ein YouTube Video herunterzuladen. Die Videos sind ganz klar für die Internet-Wiedergabe konvertiert, daher würde es mich auch nicht überraschen, wenn darin Dinge angelegt sind, die nicht für Offline-Wiedergabe oder -Analyse geeignet sind.

- Carsten

carstenkurz hat geschrieben: ↑Fr 13 Apr, 2018 23:49 Ich kenne gar keinen 'offiziellen Weg' ein YouTube Video herunterzuladen. Die Videos sind ganz klar für die Internet-Wiedergabe konvertiert, daher würde es mich auch nicht überraschen, wenn darin Dinge angelegt sind, die nicht für Offline-Wiedergabe oder -Analyse geeignet sind.
- Carsten

Wenn es dein eigenes Video ist: Creator Studio>Videos>Dropdown Menü neben dem Video>MP4 runterladen


Danke an den Rest für die vielen Infos ich gehe das alles mal durch.

YouTube verwendet aber kein MP4. Nochmal, es gibt keinen offiziellen Weg, YouTube Videos herunterzuladen. Die werden von YouTube in ihre speziellen Streaming-Container konvertiert, um die Ansprüche der YouTube Streaming-Nutzer zu erfüllen. Alles was Du da raus kriegst, hat durch die komplexe Konvertierung nichts mehr mit dem Ausgangsmaterial zu tun, und was Du da raus kriegst, auch nicht.

- Carsten

carstenkurz hat geschrieben: ↑Sa 14 Apr, 2018 16:31 YouTube verwendet aber kein MP4. Nochmal, es gibt keinen offiziellen Weg, YouTube Videos herunterzuladen. Die werden von YouTube in ihre speziellen Streaming-Container konvertiert, um die Ansprüche der YouTube Streaming-Nutzer zu erfüllen. Alles was Du da raus kriegst, hat durch die komplexe Konvertierung nichts mehr mit dem Ausgangsmaterial zu tun, und was Du da raus kriegst, auch nicht.

das hängt davon ab, mit welchem browser du youtube nutzt.
in den meisten fällen wird defaultmäßig VP9 ausgeliefert, nur bei apple devices bzw. browsern ist es weiterhin h.264.

manuelle runterladen kann man aber beide versionen. da sind auch keine großen geheimnisse oder besonderheiten damit verbunden, wie man sie nicht auch sonst in ganz noremalen MP4 bzw. MPEG-TS files vorfinden würde -- ein wenig zerstückelt halt. es werden dazu auch nur ganz einfache web-übliche übertragungsmittel genutzt, auch wenn das ganze durch für adaptive bandbreiten-adaption mittels HLS od. DASH auf den ersten blick ein bisserl komplizierter aussieht.

https://de.wikipedia.org/wiki/HTTP-Streaming

Nochmal - auch wenn Du bei YouTube einen Stream abgreifst, egal in welchem Format, kriegst Du nur das geliefert, was YouTube aus seinen eigenen internen Formaten zu Verfügung stellt. Und das sind keine universellen Download-Formate, sondern Konvertierungen aus dem Material, das Du hochgeladen hast. Nichts davon wird von YouTube explizit für die Offline-Nutzung bereit gestellt. Daher können sich die Ansprüche an dieses Material auch nur nach der dafür vorgesehenen Nutzung im Streaming orientieren.

- Carsten

warum versucht du da so krampfhaft irgendetwas in ganz einfache technische vorgänge hineinzudichten, für die in der praxis überhaupt keine notwendigkeit besteht?

dass das jatzt übers netzt abgewicklet wird und irgendwo während der übertragung prinzipiell auch auf eine parallel vorhandene versin mit mehr oder weniger bandbreite gewechselt werden kann, ändert überhaupt nichts daran, dass man durchaus auch mit ganz einfachen HTTP basierenden mitteln -- also im einfachsten fall, einem webbrowser -- auf die eigentlichen daten zugreifen kann, wenn man weiß, wie das in einem solchen fall organisiert ist bzw. wo die betreffenden file-fragmente liegen. und natürlich wird bei der übertragung selbst an diesen daten auch nicht das geringste geändert.

man muss sich zwar mit all diesen details des web-streamings nicht unbedingt näher befassen, wenn es einen nicht weiter interessiert, nur sollte man es dann konsequenter weise besser unterlassen, darüber irgendwelche völlig unhaltbaren "vermutungen" in die welt zu setzten.