Das OGV-Format wird auf meinem Computer ordnungsgemäß abgespielt, aber beim Transkodieren werden Frames gelöscht (doppelt?).

Ich habe eine Reihe von Screencasts mit recordmydesktop unter Ubuntu 12.10 erstellt. Die Ausgabe ist eine OGV-Datei. Wenn ich die ogv-Datei mit dem Standard-Movie-Player (Totem) anschaue, sieht es gut aus - Audio und Video sind synchron. Wenn es (von mir oder YouTube) transkodiert wird, sind Audio und Video nicht synchron. Es sieht so aus, als würde ich beim Erzählen ein oder zwei Folien überspringen.

Aktualisieren

Ich vermute, das Problem lässt sich besser dadurch beschreiben, dass während der Transcodierung doppelte Frames gelöscht werden. Das Konvertieren von Videos, bei denen sich die Maus bewegt, scheint normalerweise gut zu funktionieren. Aber wenn ich nur während einer Folie spreche, werden diese doppelten Frames gelöscht.

Ich habe das gesehen, aber es ist nicht ganz meine Situation (versuche, von ogv -> irgendetwas zu gehen) https://superuser.com/questions/436187/ffmpeg-convert-video-w-dropped-frames-out-of-sync

AVI-Dateien scheinen korrekt zu übersetzen! Ich nehme an, dass dies ein großer Hinweis für jemanden sein wird. Ich würde immer noch gerne das zugrunde liegende Problem aufspüren. Ich teste die Konvertierung meiner vorherigen Videos in AVI, aber das dauert eine Weile, da ich jeden Übergang überprüfen muss.

Beispiele

Dies ist die Original-OGV-Datei von gtk-recordmydesktop: http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ogv

Das Video beginnt mit einer Folie für 10 Sekunden und geht dann zu 3 weiteren Folien mit jeweils 5 Sekunden über. Jedes Mal, wenn ich die Folien vorschiebe, tippe ich auch auf das Mikrofon (10s, 15s, 20s, 25s).

Hier sind einige Konvertierungen, die durchgeführt wurden (jede zeigt ihre eigenen Video-Timing-Probleme):

http://dl.dropbox.com/u/64693533/sync_test/sync_test1.mp4

  • Dieses zeigt das erste Dia im ersten Frame, geht aber schnell daran vorbei
  • Dies wurde mit dem Stock ffmpeg gemacht

http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ffmpeg-static.mp4

  • Dieser ist ziemlich nah dran - aus irgendeinem Grund entscheidet er sich jedoch bei 13s, weiterzumachen
  • Dies wurde mit dem statischen Build von ffmpeg von vor ein paar Tagen gemacht

Hier ist es auf YouTube - Sie können sehen, dass es bei etwa 13 Sekunden früh voranschreitet (von Folie 1 -> Folie 2):

Hier ist der Beweis, dass die OGV-Datei korrekt funktioniert:

ffmpeg-Übersetzung

Mit ffmpeg oder avconv scheine ich ähnliche Ergebnisse wie bei youtube zu erhalten (Übergänge scheinen früh, aber nicht unbedingt gleichzeitig zu erfolgen).

Hier ist der Befehl, den ich verwende (mit einem aktuellen statischen Build von ffmpeg) und ausgebe:

$ ~/ffmpeg/ffmpeg -i JSP.ogv JSP.mp4
ffmpeg-Version N-50025-gb8bb661 Copyright (c) 2000-2013 die FFmpeg-Entwickler
  erstellt am 17. Februar 2013 05:23:03 mit gcc 4.6 (Debian 4.6.3-1)
  Konfiguration: --prefix=/root/ffmpeg-static/64bit --extra-cflags='-I/root/ffmpeg-static/64bit/include -static' --extra-ldflags='-L/root/ffmpeg- static/64bit/lib -static' --extra-libs='-lxml2 -lexpat -lfreetype' --enable-static --disable-shared --disable-ffserver --disable-doc --enable-bzlib --enable -zlib --enable-postproc --enable-runtime-cpudetect --enable-libx264 --enable-gpl --enable-libtheora --enable-libvorbis --enable-libmp3lame --enable-gray --enable-libass - -enable-libfreetype --enable-libopenjpeg --enable-libspeex --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-version3 --enable-libvpx
  libavutil 52.17.101 / 52.17.101
  libavcodec 54.91.103 / 54.91.103
  libavformat 54.63.100 / 54.63.100
  libavdevice 54.3.103 / 54.3.103
  libavfilter 3.38.100 / 3.38.100
  libswscale 2.2.100 / 2.2.100
  libswresample 0.17.102 / 0.17.102
  libpostproc 52. 2.100 / 52. 2.100
[ogg @ 0x34d4640] Mehrere Fisbone für denselben Stream sind nicht implementiert. Aktualisieren Sie Ihre FFmpeg-Version auf die neueste Version von Git. Wenn das Problem weiterhin auftritt, weist Ihre Datei eine Funktion auf, die nicht implementiert wurde.
[ogg @ 0x34d4640] Header-Parsing für Stream 0 fehlgeschlagen
[ogg @ 0x34d4640] Defekte Datei, Keyframe nicht korrekt markiert.
Eingabe #0, ogg, aus 'JSP.ogv':
  Dauer: 00:12:49.67, Start: 0.000000, Bitrate: 224 kb/s
    Stream #0:0: Daten: keine
    Stream #0:1: Video: theora, yuv420p, 1600x880 [SAR 1:1 DAR 20:11], 15 fps, 15 tbr, 15 tbn, 15 tbc
    Metadaten:
      RECORDMYDESKTOP : 0.3.8.1
    Stream #0:2: Audio: vorbis, 22050 Hz, mono, fltp, 89 kb/s
[libx264 @ 0x369c5e0] mit SAR=1/1
[libx264 @ 0x369c5e0] mit CPU-Fähigkeiten: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 0x369c5e0] Profil Hoch, Stufe 4.0
[libx264 @ 0x369c5e0] 264 - Kern 129 r2230 1cffe9f - H.264/MPEG-4 AVC-Codec - Copyleft 2003-2012 - http://www.videolan.org/x264.html - Optionen: cabac=1 ref=3 deblock =1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip= 1 chroma_qp_offset=-2 threads=6 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=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=15 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Ausgabe #0, mp4, zu 'JSP.mp4':
  Metadaten:
    Encoder: Lavf54.63.100
    Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 1600x880 [SAR 1:1 DAR 20:11], q=-1--1, 15360 tbn , 15 zu bestätigen
    Metadaten:
      RECORDMYDESKTOP : 0.3.8.1
    Stream #0:1: Audio: aac ([64][0][0][0] / 0x0040), 22050 Hz, mono, s16, 128 kb/s
Stream-Mapping:
  Stream #0:1 -> #0:0 (theora -> libx264)
  Stream #0:2 -> #0:1 (vorbis -> libvo_aacenc)
Drücken Sie [q] zum Stoppen, [?] für Hilfe
[ogg @ 0x34d4640] Defekte Datei, Nicht-Keyframe nicht korrekt markiert.
    Letzte Nachricht 2 Mal wiederholt
Defekte Datei, Nicht-Keyframe nicht korrekt markiert.=00:00:08.37 Bitrate= 28,7kbit/s dup=66 drop=0    
Defekte Datei, Keyframe nicht korrekt markiert.time=00:00:51.01 bitrate= 125.3kbits/s dup=675 drop=0    
Defekte Datei, Keyframe nicht korrekt markiert.time=00:00:55.05 bitrate= 140.2kbits/s dup=782 drop=0    
Defekte Datei, Keyframe nicht korrekt markiert.time=00:00:59.60 bitrate= 140.5kbits/s dup=836 drop=0    
[ogg @ 0x34d4640] Defekte Datei, Keyframe nicht korrekt markiert.
Defekte Datei, Keyframe nicht korrekt markiert.time=00:01:08.00 bitrate= 143.0kbits/s dup=900 drop=0    
Defekte Datei, Keyframe nicht korrekt markiert.time=00:01:11.86 bitrate= 141.6kbits/s dup=910 drop=0

... viele Male wiederholt ...

Defekte Datei, Keyframe nicht korrekt markiert.time=00:12:47.62 bitrate= 153.0kbits/s dup=9087 drop=0    
frame=11521 fps= 87 q=-1.0 Lsize= 14849kB time=00:12:49.48 bitrate= 158.1kbits/s dup=9087 drop=0    
Video: 2401 KB Audio: 12024 KB Untertitel: 0 Globale Header: 0 KB Muxing-Overhead 2,938094 %
[libx264 @ 0x369c5e0] Frame I:49 Durchschnitt QP:16.05 Größe: 29658
[libx264 @ 0x369c5e0] Frame P: 2912 Durchschnitt QP: 9,88 Größe: 114
[libx264 @ 0x369c5e0] Frame B: 8560 Durchschnitt QP: 12,76 Größe: 78
[libx264 @ 0x369c5e0] aufeinanderfolgende B-Frames: 0,9 % 0,1 % 0,2 % 98,9 %
[libx264 @ 0x369c5e0] mb I I16..4: 90,8 % 0,4 % 8,8 %
[libx264 @ 0x369c5e0] mb P I16..4: 0,0 % 0,0 % 0,0 % P16..4: 0,0 % 0,0 % 0,0 % 0,0 % 0,0 % überspringen: 99,9 %
[libx264 @ 0x369c5e0] mb B I16..4: 0,0 % 0,0 % 0,0 % B16..8: 0,3 % 0,0 % 0,0 % direkt: 0,0 % überspringen: 99,7 % L0: 65,3 % L1: 34,6 % BI: 0,1 %
[libx264 @ 0x369c5e0] 8x8-Transformation intra: 0,5 % inter: 15,8 %
[libx264 @ 0x369c5e0] codiert y,uvDC,uvAC intra: 6,4 % 0,1 % 0,1 % inter: 0,0 % 0,0 % 0,0 %
[libx264 @ 0x369c5e0] i16 v, h, dc, p: 94 % 4 % 2 % 0 %
[libx264 @ 0x369c5e0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19 % 22 % 44 % 1 % 2 % 2 % 3 % 1 % 6 %
[libx264 @ 0x369c5e0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35 % 17 % 19 % 4 % 5 % 5 % 5 % 5 % 5 %
[libx264 @ 0x369c5e0] i8c dc,h,v,p: 100 % 0 % 0 % 0 %
[libx264 @ 0x369c5e0] Gewichtete P-Frames: Y: 0,0 % UV: 0,0 %
[libx264 @ 0x369c5e0] ref P L0: 82,5 % 1,4 % 11,9 % 4,3 %
[libx264 @ 0x369c5e0] Referenz B L0: 47,2 % 52,4 % 0,4 %
[libx264 @ 0x369c5e0] Referenz B L1: 99,2 % 0,8 %
[libx264 @ 0x369c5e0] kb/s:25,60

Das Video rückt immer noch früh vor, aber zu unterschiedlichen Zeiten. Es hört sich so an, als würde gtk-recordmydesktop eine "kaputte Datei" erzeugen. Was ärgerlich ist, ist, dass das OGV funktioniert, also scheint es, als sollte ich in der Lage sein, dies mit einigen Optionen zum Laufen zu bringen.

Ich habe festgestellt, dass ich das Video in kdenlive rendern kann und es scheint dort zu funktionieren. Ich würde trotzdem gerne wissen, was los ist. kdenlive macht einen viel besseren Job, aber es kommt manchmal immer noch früh voran.

Bitte zeigen Sie Ihren ffmpeg-Befehl und die daraus resultierende vollständige Konsolenausgabe.
Gute Idee @LordNeckbeard Ich habe den Befehl und die Ausgabe hinzugefügt. Ich bemerke einen Fehler/eine Warnung: max_analyze_duration erreicht.
Tritt das Problem weiterhin auf, wenn Sie einen aktuellen statischen Build von ffmpeg verwenden ? Dadurch werden potenzielle Fehler ausgeschlossen, auf die Sie möglicherweise stoßen und die bereits mit einer neueren Version von ffmpeg behoben wurden. Keine Notwendigkeit zu installieren oder irgendetwas. Einfach herunterladen, das Archiv extrahieren und dann die enthaltene ffmpegBinärdatei ausführen.
Können Sie eine Beispieleingabedatei bereitstellen, mit der das Problem reproduziert werden kann?
Gute Idee, ich werde ein kleines zaubern und es später heute Abend posten.
Wäre eine Antwort im Sinne von „Verwenden Sie ein anderes Bildschirmaufzeichnungsprogramm“ akzeptabel? Es sieht so aus, als ob GTK-recordmydesktop beschädigte Dateien erstellt.
@evilsoup - Leider nein, ich habe bereits eine Reihe von Aufnahmen erstellt, bevor ich das Problem bemerkte. Außerdem kann ich das OGV unter Linux problemlos ansehen, sodass es scheint, dass es nicht vollständig beschädigt ist. Davon abgesehen werde ich versuchen herauszufinden, warum es "kaputte Dateien" erstellt.
Sofern mir nichts fehlt, ist dies wahrscheinlich ein Fehler oder ein Mangel an Ogg-Funktionsunterstützung in ffmpeg und/oder ein Fehler in recordmydesktop (für den ffmpeg keinen besonderen Fall gemacht hat). Ein Fehlerbericht ist hier möglicherweise die beste Option. Stellen Sie sicher, dass Sie die neueste verfügbare ffmpeg-Version verwenden, zeigen Sie Ihren ffmpeg-Befehl und die vollständige Konsolenausgabe an, geben Sie sync_test1.ogv, und versuchen Sie, das Problem nach Möglichkeit nur mit nativen Encodern (keine lib*wie libx264) anzuzeigen.
Danke für den Vorschlag @LordNeckbeard Ich werde einen Fehlerbericht einreichen und sehen, wohin das führt. Irgendeine Idee, warum AVI zu funktionieren scheint?

Antworten (4)

Warum in OGV konvertieren, wenn Ihr endgültiger Upload auf YouTube erfolgen soll? Ich kann mich irren, aber Sie können den x264-Videocodec mit AAC-Audio sogar unter Linux konvertieren und auf YouTube hochladen, wenn man bedenkt, dass dies sowieso der bevorzugte Upload ist. Haben Sie versucht, ein h264 zu erstellen und es auf YouTube hochzuladen, anstatt die OGV-Datei, und zu sehen, ob das das Problem war. Denn ich würde wetten, dass Sie, wenn das Problem dadurch gelöst wird, wissen, dass es ein Problem mit dem Hochladen des OGV auf YouTube war, und wenn es nicht gelöst wird, könnte es sich um ein Bildratenproblem mit der Interpretation von YouTube oder etwas Ähnliches handeln.

In der Vergangenheit gab es viele Probleme mit OGV-Dateien, die auf YouTube hochgeladen wurden. Ich kann mir nicht vorstellen, dass es auch jetzt zu 100% behoben ist.

http://support.google.com/youtube/bin/answer.py?hl=de&answer=1722171

BEARBEITEN: Ich habe auch gerade bemerkt, dass Ihr Originalmaterial 15 fps hat ... dies könnte sehr wohl die Ursache des Problems sein

BEARBEITEN 2: Ich schien die Frage ein wenig falsch verstanden zu haben ... da Sie mit einer Videodatei beginnen, die OGV ist, und ich gesehen habe, dass Sie zu MP4 wechseln ... das ändert die Dinge ein wenig ... .aber ich vermute, dass es etwas mit den 15 fps und 22050 Hz Audio zu tun hat ... Ich weiß, dass die Abtastrate nichts mit der Synchronisierung des Audios zu tun hat, aber aus Erfahrung bei der Verwendung von nicht standardmäßigen Bildraten und Audio-Sampleraten, Ich habe tendenziell ein Abdriften gesehen ... es kann ziemlich schwierig sein, diese zu synchronisieren, wenn man sie nach der ersten Aufnahme nicht mit einem billigen Video-Editor bearbeiten kann ...

Obwohl die Software beim Abdriften von Audio besser geworden ist, ist es immer noch ein häufiges Problem, wenn ungewöhnliche Frameraten und Sampleraten verwendet werden, da die Keyframe-Synchronisierungspunkte nicht standardmäßig sind und Keyframes runden usw.

Sie sehen, wo es heißt: "Beschädigte Datei, Keyframe nicht korrekt markiert." darauf bezieht es sich...

Mein Rat für Sie wäre, es so nah wie möglich zu bringen, es in einen Videoeditor zu nehmen und das Audio zu verschieben und zu schneiden, damit es Ihren Wünschen entspricht. Leider wird das manchmal so gelöst...

Softwarebasierte Transcoder funktionieren nicht immer so, wie sie sollten ... daher würde ein Protools-Setup und / oder ein Avid-Setup mit Hardware geliefert, um die Synchronisierungsfähigkeiten und konstante Bildraten usw. weiter sicherzustellen ...

Eine andere Sache, die Sie versuchen könnten, ist, das Filmmaterial in eine Standard-Framerate zu konvertieren und zu versuchen, das Audio neu zu marieren ... da ich mir ziemlich sicher bin, dass es das Video ist, das driftet ... wahrscheinlich ganz leicht langsamer und dann in Richtung beschleunigt Ende oder umgekehrt.

BEARBEITEN: Ich konnte das Video mit diesem ffmpeg-Befehl mit dem Original synchronisieren. Möglicherweise ist die Ratenklausel erforderlich, was ich vermutet habe

ffmpeg -i sync_test1.ogv -strict experimental -pix_fmt yuv420p -r 15 -vcodec h264 -acodec aac sync_test1.mp4

Die Originaldatei ist Theora-Video und Vorbis-Audio im OGV-Container. Soweit ich weiß, kodiert Amir T nicht in dieses Format neu, aber wenn er versucht, das Original entweder mit ffmpeg oder YouTube neu zu kodieren, tritt das Synchronisierungsproblem auf.
Das Eingabeformat ist ogv, was gtk-recordmydesktop ausgibt. Ich versuche, etwas anderes als ogv (flv usw.) zu erreichen.
Lesen Sie meine aktualisierte Antwort ... Ich denke, es ist ein Problem von FPS
Ich habe eine Beispielquelldatei hinzugefügt. Das Synchronisationsproblem ist sehr auffällig. Es scheint mir, als würden eine Reihe von Frames für verschiedene Formate entfernt.
Versuchen Sie dies ... siehe neue Antwort
Das Hinzufügen -r 15ist dasselbe wie das Weglassen, da ffmpeg standardmäßig die Eingabebildrate erbt und die resultierenden Ausgabedateien mit oder ohne -r 15genau die gleichen sind wie ffmpeg von git head (Version N-50285-gad89952). Wenn es bei Ihnen mit einer älteren ffmpeg-Version funktioniert, könnte dies eine Regression sein und sollte dem FFmpeg-Bug-Tracker gemeldet werden .
@ChrisJamesChampeau danke für den Vorschlag - ich habe den von Ihnen aufgelisteten Befehl mit dem statischen Build von ffmpeg ausprobiert. Ich bekomme Folie 2 bei 12 Sekunden und 3 bei 17 Sekunden: dl.dropbox.com/u/64693533/sync_test/sync_test1.cjc.mp4
Nun, das FFmpeg, das ich verwende, ist eine MAC-Version im Vergleich zu Ihrer Linus-Version, nicht sicher, aber ich vermute, dass es einen Fehler mit Ihrem FFMPEG geben muss. hast du schon versucht es zu entfernen und die neuste Version neu zu installieren?
Ja, ich habe zwei Versionen ausprobiert, die Ubuntu-Standardversion von apt-get und die statische Version.
Ich bin bei @LordNeckbeard, Sie sollten dies als Fehler an FFMPEG melden

Ich hatte mit einem ähnlichen Problem unter Ubuntu 12.04.3 LTS zu kämpfen. Ich habe das Problem mit dem statischen ffmpeg-Build behoben, der unter http://johnvansickle.com/ffmpeg/ verfügbar ist.

Ich habe auch einen statischen Build ausprobiert und es hat etwas besser funktioniert. Vielleicht wurde der Fehler behoben, in diesem Fall könnte es hilfreich sein, die Versionsnummer aus dem statischen Build zu Ihrer Antwort hinzuzufügen?

Es scheint, dass dieser Fehler immer noch in recordmydesktopist, oder zumindest habe ich genau die gleichen Symptome hier mit der Version von Debian testing ( 0.3.8.1+svn602-1.1).

Ich habe es gerade geschafft, dieses Video auf folgende Weise fast korrekt zu transcodieren:

  1. Verwenden Sie VLC.
  2. Bitten Sie es, in das WebM-"Profil" umzucodieren.
  3. Bitten Sie ihn, das Video anzuzeigen, während es transkodiert wird.

Das Ergebnis hat immer noch die korrekte Synchronisation (yay!), aber es leidet immer noch unter einem Problem: Das resultierende Video kündigt sich als länger als 4 Stunden an, während mein Video nur 25 Minuten dauert. Peertube listet es daher als 4-Stunden-Video auf, obwohl beim Start der Wiedergabe die korrekte 25-Minuten-Dauer angezeigt wird, sodass das Problem nicht zu schwerwiegend ist.

Punkt 3 ist wichtig, aber auch Punkt 2: Vielleicht funktionieren auch andere Profile, aber zumindest das H264-Profil lieferte mir ein unbrauchbares Video (entweder mit schlechtem Sync wie ffmpegoder schlechter).

Versuchen Sie, den Container einfach in avi zu ändern, anstatt ihn zu transcodieren, was für YouTube besser zu funktionieren scheint:

ffmpeg -i JSP.ogv -vcodec copy -acodec copy JSP.avi
Ich habe das versucht, und der Upload wird einfach nie fertig verarbeitet, genauso wie wenn ich OGV hochlade. Da diese Antwort älter ist als YouTube OGV akzeptiert hat, muss es diese Änderung sein. Ärgerlich, dass ffmpeg nach vier Jahren immer noch dieses Konvertierungsproblem hat.
Mein ffpmeg ist: 3.2.14-1~deb9u1 (apt-get installiert)
Ich habe alle oben genannten Variationen mit statischen Builds (git-20191029) ausprobiert, und obwohl es ein bisschen besser wird, sind Audio und Video nicht synchronisiert. Wenn man es versucht, braucht man einen großen --max_muxing_queue_size-Wert. Ich habe 40960 verwendet.
Das OGV-Format wird auf meinem Computer ordnungsgemäß abgespielt, aber beim Transkodieren werden Frames gelöscht (doppelt?).
AntwortenHierDatenschutz-Bestimmungen1y, 0v