Fragen zu Framerate und Wiedergabe-Ruckeln

[b-flow]

Hallo miteinander!

Ich benutze Resolve 18.6 auf einem MacBook Pro M1 Max und bin bei meinem ersten Projekt auf ein Problem mit ruckliger Wiedergabe gestoßen, zu dem ich auch mit Hilfe der Forensuche keine Lösung gefunden habe.

Ich habe eine Videodatei von einem Handy, für die ich bereits je nach Tool eine unterschiedliche Framerate angezeigt bekomme:
 - VLC sagt 30.038054 fps
 - ffprobe sagt 30.04 fps
 - Resolve sagt 30.000 fps
Das alleine finde ich schon irritierend. Die Datei wird sowohl von VLC als auch von QuickTimePlayer flüssig abgespielt.

Wenn ich ein neues Projekt in Resolve erstelle und den Clip importiere, fragt mich Resolve, ob ich die Projekt-/Timeline-Framerate anpassen will. Sage ich ja, steht in den Project-Settings 30 fps. Ziehe ich den Clip auf die Timeline und exportiere das Projekt mit 30 fps in H.264 in einem MP4-Container, verhält sich die exportierte Datei folgendermaßen:
 - VLC sagt 30 fps, die Wiedergabe ruckelt aber. Ich hab mal bei 0.25x Speed ca. 3 fps mitgezählt, also bei Normalgeschwindigkeit ca. 12 fps.
 - QuickTimePlayer spielt das Video flüssig ab.
 - ffprobe sagt 30 fps, meldet aber auch "Unsupported codec with id 0 for input stream 2"

Mache ich einen dummen Anfängerfehler? Hat jemand eine Idee, was ich probieren könnte?
Ein Freund meinte, ich soll mal beim Exportieren den Haken bei "Bypass re-encode when possible" wegmachen, das hat aber nix verändert.

LG b-flow

---

Hier noch die genauen Infos von ffprobe:

Input-Videodatei:

Code:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isommp42
    creation_time   : 2022-07-17T15:15:48.000000Z
    com.android.version: 11
  Duration: 00:06:31.46, start: 0.000000, bitrate: 20105 kb/s
  Stream #0:0[0x1](eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, smpte170m, progressive), 1920x1080, 20001 kb/s, SAR 1:1 DAR 16:9, 30.04 fps, 30 tbr, 90k tbn (default)
    Metadata:
      creation_time   : 2022-07-17T15:15:48.000000Z
      handler_name    : VideoHandle
      vendor_id       : [0][0][0][0]
    Side data:
      displaymatrix: rotation of -180.00 degrees
  Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 96 kb/s (default)
    Metadata:
      creation_time   : 2022-07-17T15:15:48.000000Z
      handler_name    : SoundHandle
      vendor_id       : [0][0][0][0]

exportiere Videodatei:

Code:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test_bypassOn.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    creation_time   : 2024-02-02T11:39:25.000000Z
    encoder         : Blackmagic Design DaVinci Resolve
  Duration: 00:06:31.53, start: 0.000000, bitrate: 14529 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080, 14207 kb/s, SAR 1:1 DAR 16:9, 30 fps, 30 tbr, 15360 tbn (default)
    Metadata:
      creation_time   : 2024-02-02T11:39:25.000000Z
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
      timecode        : 01:00:00:00
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 319 kb/s (default)
    Metadata:
      creation_time   : 2024-02-02T11:39:25.000000Z
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
  Stream #0:2[0x3](eng): Data: none (tmcd / 0x64636D74) (default)
    Metadata:
      creation_time   : 2024-02-02T11:39:25.000000Z
      handler_name    : TimeCodeHandler
      timecode        : 01:00:00:00
Unsupported codec with id 0 for input stream 2

[nomade]

Der einzige Fehler: es ist ein Handy! Die können keine feste Bildfrequenz.
Schick's durch Shutter Encoder und lass es auf eine feste Zahl umstellen.

[b-flow]

Danke für die fixe Antwort!

OK, in der Tat sagt Shutter Encoder für dieses Handyvideo:

Code:

Frame rate mode:    Variable
Frame rate:         30.039 FPS
Minimum frame rate: 23.968 FPS
Maximum frame rate: 40.089 FPS

Dann ist das also der Grund, warum verschiedene Tools verschiedene Framerates anzeigen, nehme ich an.

Ich frage mich nun:
 - Wie ermitteln die Tools denn die Framerate und wieso kommen sie dabei zu verschiedenen Ergebnissen?
 - Wieso sagen einem VLC, ffprobe oder Resolve nicht, dass es variable Framerate ist? Ist das nicht wichtig zu wissen, zumindest in Resolve?
 - Ist es immer sinnvoll, die Quelldatei mit Shutter Encoder zu inspizieren und eine konstante Framerate draus zu machen, bevor man damit was macht?
 - Wieso tut das Resolve nicht automatisch, sondern lässt es drauf ankommen, bis man im Endergebnis merkt, dass was nicht passt?
 - Und wie kommt es überhaupt zu dem Stutter-Effekt? QuickTimePlayer stellt es ja wie gewünscht da, also irgendwie ist die Information scheinbar vorhanden. Alle Tools (auch Shutter Encoder) sind sich außerdem einig, dass die exportierte Datei 30 fps besitzt. Wie kann es dann zu Darstellungsproblemen kommen?
 - Was passiert bei der "Korrektur" der variablen Framerate eig mit den Audiodaten? Geht mir da der Sync kaputt?

Ich bin sehr interessiert an den technischen Hintergründen. 

Ich probier derweil mal aus, ob ich mein Problem so lösen kann.

edit: Frage ergänzt

[b-flow]

Leider besteht Problem weiterhin.

Ich habe in Shutter Encoder H.264 ausgewählt und unter "Erweiterte Funktionen" "Konform durch" ausgewählt und 30 fps eingestellt. Das Ergebnis spielt flüssig in VLC ab und zeigt hier auch genau 30 fps an. Mache ich eine neues Resolve-Projekt, importiere das Video, akzeptiere die Änderung der Timeline-Framerate und exportiere wie zuvor bei 30 fps, habe ich wieder einen Export, der im QuickTimePlayer flüssig abspielt, in VLC aber ruckelt. ffprobe zeigt den gleichen Output.


An der variablen Framerate scheint es also nicht zu liegen.

[nomade]

Grundsätzlich erstmal:
Alle professionellen Schnittsysteme kommen aus einer Ära, als alle Kameras ihre Bildgeschwindigkeit eisern eingehalten haben. Das taten sie, seit sie nicht mehr per Handkurbel betrieben wurden. Selbst eine mechanische Kamera wurde mit Quarz stabilisiert, weil Profis den Ton meistens getrennt aufnehmen. Außerdem kriegt jedes Einzelbild eine eindeutige 'Adresse', nämlich den Timecode. Der ist aber von Echtzeit abhängig. Darauf verlassen sich alle diese Programme, es steckt sozusagen in ihrem Fundament.

Player dagegen versuchen, je nach Qualität der Programmierung, alles irgendwie abzuspielen, was man ihnen vorsetzt. VLC ist leider schon lange nicht mehr das Tool der Wahl, die Leute haben wohl etwas die Lust verloren, ist halt 'für umme'. Ich kriege da manchmal auch einen miserablen Ton vorgeführt. Probier mal IINA oder MPV.

Nun kommen die Handys und wollen auf einmal auch filmen. Deines scheint einen besonders großen Toleranzbereich zu haben. Ein aktuelles iPhone zeigt mit einer guten Kamera-App Abweichungen unter einem Prozent, bei 60 fps z. B. 59,940 bis 60,181 fps. Damit kommt DR dann schon einigermaßen klar. Aber offensichtlich kriegt's nicht einmal Apple bei einem sündteuern Spitzengerät perfekt hin. Realistisch zeigt das MediaInfo, andere zeigen oft nur den Durchschnittswert oder den nächstliegenden Standardwert.

Wenn Shutter Encoder es nicht stabil bekommt, wird es schwierig. Aber es kann schon sein, dass trotz stabiler Bildrate beim Export was schief läuft. Probier doch mal einen Export in ProRes und schau Dir an, was MediaInfo dann angibt.

Und Synchronton? Vergiß es!
Oder besorg Dir 'ne Kamera, die nicht telefonieren kann.

[nomade]

Noch ein Tipp: Mal probeweise vor der Aufnahme auf Flugzeug-Modus einstellen. Wird's dann besser?

[TomStg]

Probiere anstelle von Shutter Encoder mal den Compressor von Apple. Damit bekam ich jedes Handy-Video konstant und zuverlässig auf die gewünschte Bildrate.

Falls es bei der Nachbearbeitung von Handy-Clips auf Synchronität ankommt, wird es schnell sehr aufwendig. Denn diese ist grundsätzlich nicht mehr vorhanden, sobald nachträglich eine konstante Bildrate erzeugt wurde. Dann muss frameweise die Synchronität kontrolliert und entsprechend framegenau manuell angepasst werden. Bei Sprache lässt sich das einigermaßen zügig machen, aber bei Musik ist es sehr sehr zeitintensiv.

Und endlich mal den VLC komplett zu vergessen, wäre eine sehr gute Aktion. Denn VLC gaukelt eine Konformität vor, die es außerhalb von VLC nicht gibt. Haupt-Ursache dafür ist ua die umfangreiche Codec-Bibliothek, die in VLC eingebaut ist, aber dem übergeordneten Rechner-System nicht zur Verfügung steht.

[b-flow]

Danke für eure ausführlichen Antworten. 

Alle Tools sind sich ja einig, dass der Export 30 fps hat. Wenn ich den Export wieder in Resolve importiere, kann ich die einzelnen Frames durchsteppen, die sehen alle gut aus. Ist damit nicht irgendwie schon klar, dass das Problem am Player liegt und nicht an der Datei selbst? Also zumindest mit der VFR sollte das nix mehr zu tun haben, oder? (wurde nicht mit meinem Handy aufgenommen übrigens, kann da nix ausprobieren)

Inwiefern zeigt MediaInfo das realistisch und nicht auch nur einen Durchschnittswert?

MediaInfo:

• Originaldatei:
  English, 20.0 Mb/s, 1920*1080 (16:9), at 30.039 FPS, AVC (NTSC) (High@L4) (CABAC / 1 Ref Frames) VideoHandle
  
• nach Shutter Encoder (hier wurde scheinbar komprimiert, obwohl ich as nicht wollte!):
  English, 6 000 kb/s, 1920*1080 (16:9), at 30.000 FPS, AVC (High@L5.1) (CABAC / 4 Ref Frames) VideoHandle
  
• Resolve-Export:
  6 257 kb/s, 1280*720 (16:9), at 30.000 FPS, AVC (High@L3.1) (CABAC / 5 Ref Frames)
  

Vergleich der Player bzgl. des Resolve-Exports:

• QuickTimePlayer hat die beste Wiedergabequalität, es sieht sehr smooth aus.
  
• Der Player in Resolve spielt es ebenso super ab, sieht flüssig aus.
  
• IINA is möglicherweise genauso gut. Ich kann es mit meinen ungeübten Augen nicht sagen, ob möglicherweise ein ganz bisschen Stutter da ist. Definitiv sehr akzeptabel.
  
• Der Player, der auf meinem Handy in Telegram verwendet wird, zeigt es auch flüssig an.
  
• mpv zeigt etwas Stutter, manchmal werden offenbar Frames wiederholt, aber im Schnitt zeigt er wohl schon 30 fps. Nicht optimal, für einen Profi vermutlich nicht akzeptabel, für mich als Noob aber okay.
  
• VLC ist halt ganz schlecht, weil er einfach konstant nur 12 fps ausgibt und daher alles auffällig abgehackt aussieht.
  

Ich würde euch ja gerne einen Schnipsel aus dem Video zur Verfügung stellen, wenn das hilft, weiß aber nicht genau, wie. Via wetransfer vielleicht?

Mit Codecs und Formaten kenne ich mich quasi null aus. Ich wollte was sehr verbreitetes nehmen, was hoffentlich jeder ohne Probleme abspielen kann, egal ob PC, Mac, Android etc. Dachte, dass ich da mit H.264+MP4 ganz gut fahre. Was spricht denn für ProRes+MOV?

---

Dass der Timecode-Stream im Export ist, ist vermutlich eine gute Sache, oder? Kenne mich damit auch null aus. Macht der VLC möglicherweise Probleme?
ffprobe meckert ja wegen genau diesem Stream, wenn ich das richtig lese, weil es den Codec nicht kennt.

[HarryH]

Ist die geringere Export-Auflösung gewollt?
Hast du es mal mit einer höhere Datenrate (Deliver > Quality) versucht?

[b-flow]

Achso ja, die geringere Auflösung ist beim tatsächlichen Projekt gewollt. Im Testprojekt, bei dem ich den einen Clip unverändert in unveränderter Auflösung exportiere, ist das Verhalten gleich.

Bei "Quality" ist in Resolve "Automatic" eingestellt, ansonsten müsste ich "Restrict to" wählen, und das wollte ich eher nicht.