Format OGV działa poprawnie na moim komputerze, ale transkodowanie upuszcza (duplikuje?) Klatki

Zrobiłem zestaw screencastów za pomocą recordmydesktop na Ubuntu 12.10. Dane wyjściowe to plik ogv. Kiedy oglądam plik ogv przy użyciu domyślnego odtwarzacza filmów (totemu), wygląda dobrze - audio i wideo są zsynchronizowane. Po transkodowaniu (przeze mnie lub YouTube) audio i wideo nie są zsynchronizowane. Wygląda na to, że pomijam slajd lub dwa podczas narracji.

Aktualizacja

Podejrzewam, że problem jest lepiej scharakteryzowany jako upuszczanie zduplikowanych ramek podczas transkodowania. Konwersja wideo w miejscu, w którym porusza się mysz, wydaje się normalnie działać dobrze. Ale kiedy rozmawiam podczas slajdu, zduplikowane klatki są odrzucane.

Widziałem to, ale to nie do końca moja sytuacja (próba przejścia z ogv -> cokolwiek) /superuser/436187/ffmpeg-convert-video-w-dropped-frames-out-of-sync

Pliki AVI wydają się poprawnie tłumaczyć! Zakładam, że będzie to dla kogoś wielka wskazówka. Nadal chciałbym wyśledzić podstawowy problem. Testuję konwersję moich poprzednich filmów do AVI, ale zajmuje to trochę czasu, ponieważ muszę sprawdzać każde przejście.

Przykłady

To jest oryginalny plik OGV z gtk-recordmydesktop: http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ogv

Film zaczyna się od slajdu przez 10 sekund, a następnie przechodzi do 3 kolejnych slajdów po 5 sekund. Za każdym razem, gdy przesuwam slajdy, stukam też mikrofon (10s, 15s, 20s, 25s).

Oto niektóre konwersje, które zostały wykonane (każdy wyświetla własne problemy z synchronizacją wideo):

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

• ten pokazuje pierwszy slajd w pierwszej klatce, ale szybko przechodzi obok niego
• zostało to zrobione przy użyciu akcji ffmpeg

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

• ten jest dość blisko - z jakiegoś powodu w wieku 13 lat decyduje się jednak na awans
• zostało to zrobione przy użyciu statycznej wersji ffmpeg sprzed kilku dni

Tutaj jest na youtube - widać, że około 13s przesuwa się wcześnie (od slajdu 1 -> slajd 2):

Oto dowód, że plik OGV działa poprawnie:

tłumaczenie ffmpeg

Używając ffmpeg lub avconv, wydaje mi się, że uzyskuję podobne wyniki jak youtube (przejścia wydają się odbywać wcześnie, ale niekoniecznie w tym samym czasie).

Oto polecenie, którego używam (z najnowszą statyczną wersją ffmpeg) i dane wyjściowe:

$ ~ / ffmpeg / ffmpeg -i JSP.ogv JSP.mp4
wersja ffmpeg N-50025-gb8bb661 Copyright (c) 2000-2013 deweloperzy FFmpeg
  zbudowany 17 lutego 2013 05:23:03 z gcc 4.6 (Debian 4.6.3-1)
  konfiguracja: --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-grey --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] Wiele fisbone dla tego samego strumienia nie jest zaimplementowane. Zaktualizuj swoją wersję FFmpeg do najnowszej wersji z Git. Jeśli problem nadal występuje, oznacza to, że plik ma funkcję, która nie została zaimplementowana.
[ogg @ 0x34d4640] Analiza nagłówka nie powiodła się dla strumienia 0
[ogg @ 0x34d4640] Uszkodzony plik, klatka kluczowa niepoprawnie zaznaczona.
Wprowadź nr 0, ogg z „JSP.ogv”:
  Czas trwania: 00: 12: 49,67, start: 0,000000, szybkość transmisji: 224 kb / s
    Strumień # 0: 0: Dane: brak
    Strumień # 0: 1: Wideo: theora, yuv420p, 1600x880 [SAR 1: 1 DAR 20:11], 15 fps, 15 tbr, 15 tbn, 15 tbc
    Metadane:
      RECORDMYDESKTOP: 0.3.8.1
    Strumień 0: 2: Audio: vorbis, 22050 Hz, mono, fltp, 89 kb / s
[libx264 @ 0x369c5e0] przy użyciu SAR = 1/1
[libx264 @ 0x369c5e0] z wykorzystaniem możliwości procesora: MMX2 SSE2 Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 0x369c5e0] profil Wysoki, poziom 4.0
[libx264 @ 0x369c5e0] 264 - rdzeń 129 r2230 1cffe9f - kodek AVC H.264 / MPEG-4 AVC - Copyleft 2003-2012 - http://www.videolan.org/x264.html - opcje: cabac = 1 ref = 3 deblock = 1: 0: 0 analizuj = 0x3: 0x113 me = hex subme = 7 psy = 1 psy_rd = 1.00: 0.00 mixed_ref = 1 me_range = 16 chroma_me = 1 krata = 1 8x8dct = 1 cqm = 0 deadzone = 21,11 fast_pskip = 1 chroma_qp_offset = -2 wątki = 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 wagab = 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
Wyjście # 0, mp4, do „JSP.mp4”:
  Metadane:
    enkoder: Lavf54.63.100
    Strumień # 0: 0: Wideo: h264 ([33] [0] [0] [0] / 0x0021), yuv420p, 1600x880 [SAR 1: 1 DAR 20:11], q = -1--1, 15360 tbn , 15 tbc
    Metadane:
      RECORDMYDESKTOP: 0.3.8.1
    Strumień # 0: 1: Audio: aac ([64] [0] [0] [0] / 0x0040), 22050 Hz, mono, s16, 128 kb / s
Mapowanie strumienia:
  Strumień # 0: 1 -> # 0: 0 (teora -> libx264)
  Strumień # 0: 2 -> # 0: 1 (vorbis -> libvo_aacenc)
Naciśnij [q], aby zatrzymać, [?], Aby uzyskać pomoc
[ogg @ 0x34d4640] Zepsuty plik, klatka kluczowa niepoprawnie zaznaczona.
    Ostatnia wiadomość powtórzona 2 razy
Zepsuty plik, klatka kluczowa niepoprawnie oznaczona. = 00: 00: 08.37 bitrate = 28,7 kb / s dup = 66 drop = 0    
Zepsuty plik, klatka kluczowa niepoprawnie zaznaczona. Czas = 00: 00: 51,01 bitrate = 125,3 kbit / s dup = 675 spadek = 0    
Zepsuty plik, klatka kluczowa niepoprawnie zaznaczona. Czas = 00: 00: 55,05 bitrate = 140,2 kb / s dup = 782 spadek = 0    
Zepsuty plik, klatka kluczowa niepoprawnie zaznaczona. Czas = 00: 00: 59,60 bitrate = 140,5 kb / s dup = 836 spadek = 0    
[ogg @ 0x34d4640] Uszkodzony plik, klatka kluczowa niepoprawnie zaznaczona.
Zepsuty plik, klatka kluczowa niepoprawnie zaznaczona. Czas = 00: 01: 08.00 bitrate = 143,0kbit / s dup = 900 drop = 0    
Zepsuty plik, klatka kluczowa niepoprawnie zaznaczona. Czas = 00: 01: 11,86 bitrate = 141,6 kbit / s dup = 910 spadek = 0    

... powtarzane wiele razy ...

Zepsuty plik, klatka kluczowa niepoprawnie zaznaczona. Czas = 00: 12: 47,62 bitrate = 153,0 kbit / s dup = 9087 spadek = 0    
ramka = 11521 fps = 87 q = -1,0 Lsize = 14849 kB czas = 00: 12: 49,48 bitrate = 158,1 kb / s dup = 9087 drop = 0    
wideo: 2401kB audio: 12024kB podtytuły: 0 globalne nagłówki: obciążenie nadmiarowe 0kB 2.938094%
[libx264 @ 0x369c5e0] ramka I: 49 Śr. QP: 16,05 rozmiar: 29658
[libx264 @ 0x369c5e0] ramka P: 2912 Śr. QP: 9,88 rozmiar: 114
[libx264 @ 0x369c5e0] ramka B: 8560 Śr. QP: 12,76 rozmiar: 78
[libx264 @ 0x369c5e0] kolejne klatki B: 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% pominąć: 99,9%
[libx264 @ 0x369c5e0] MB B I16..4: 0,0% 0,0% 0,0% B16..8: 0,3% 0,0% 0,0% bezpośredni: 0,0% pominąć: 99,7% L0: 65,3% L1: 34,6% BI: 0,1%
[libx264 @ 0x369c5e0] Transformacja 8x8 intra: 0,5% inter: 15,8%
[libx264 @ 0x369c5e0] zakodowane 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] Ważone ramki typu P: Y: 0,0% UV: 0,0%
[libx264 @ 0x369c5e0] ref. P L0: 82,5% 1,4% 11,9% 4,3%
[libx264 @ 0x369c5e0] ref. B L0: 47,2% 52,4% 0,4%
[libx264 @ 0x369c5e0] ref B L1: 99,2% 0,8%
[libx264 @ 0x369c5e0] kb / s: 25.60

Film nadal jest odtwarzany wcześnie, ale w różnych momentach. Wygląda na to, że gtk-recordmydesktop generuje „uszkodzony plik”. Irytujące jest to, że OGV działa, więc wydaje mi się, że powinienem móc sprawić, by działał z pewnym zestawem opcji.

Przekonałem się, że mogę renderować wideo w kdenlive i wydaje się, że tam działa. Nadal chciałbym wiedzieć, co się dzieje. kdenlive wykonuje znacznie lepszą robotę, ale czasami rozwija się wcześnie.

Po co konwertować na OGV, kiedy twoje ostateczne przesyłanie będzie na youtube, mogę się mylić, ale możesz przekonwertować na kodek wideo x264 z AAC Audio nawet na Linuksie i przesłać to do youtube, biorąc pod uwagę, że tak wolą być przesłane. Próbowałeś zrobić h264 i przesłać na youtube zamiast pliku OGV i sprawdzić, czy to jest problem. Ponieważ założę się, że jeśli to rozwiąże problem, to wiesz, że był to problem z przesyłaniem OGV do youtube, a jeśli to nie rozwiąże, może to być problem z liczbą klatek na sekundę przy interpretacji youtube lub coś podobnego.

W przeszłości występowało wiele problemów z plikami OGV przesyłanymi do youtube. Nie mogę sobie wyobrazić, że jest w 100% naprawiony nawet w tym momencie.

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

EDYCJA: zauważyłem również, że twój oryginalny materiał ma prędkość 15 klatek na sekundę ... to może być źródłem problemu

EDYCJA 2: Wydawało mi się, że trochę źle odczytałem pytanie ... ponieważ zaczynasz od pliku wideo, który jest OGV, i widziałem, że wybierasz się do MP4 ... to trochę zmienia rzeczy ... . przypuszczam jednak, że ma to coś wspólnego z dźwiękiem 15 klatek na sekundę i 22050 Hz ... Wiem, że częstotliwość próbkowania nie ma nic wspólnego z synchronizacją dźwięku, ale z doświadczenia, gdy korzystam z niestandardowych częstotliwości klatek i sampleratów audio, Miałem tendencję do dryfowania ... synchronizacja może być trudna, ale nie mogę ich edytować po początkowym nagraniu za pomocą taniego edytora wideo ...

Chociaż oprogramowanie poprawiło dryfowanie dźwięku, nadal jest częstym problemem podczas korzystania z nietypowych klatek na sekundę i próbkowania, ponieważ punkty synchronizacji klatek kluczowych nie są standardowe i mogą zaokrąglać klatki kluczowe itp.

Widzisz, gdzie jest napisane: „Zepsuty plik, klatka kluczowa niepoprawnie oznaczona”. właśnie to dotyczy ...

radzę, abyś zbliżył go jak najbliżej, zabrał go do edytora wideo, wsuwał i kroił dźwięk, aby dopasować go tak, jak chcesz. Niestety czasami tak to naprawia ...

Transkodery oparte na oprogramowaniu nie zawsze działają tak, jak powinny ... hen, dlaczego konfiguracja protools i / lub zapalona konfiguracja miałyby być dostarczane ze sprzętem w celu dalszego zapewnienia możliwości synchronizacji i stałej liczby klatek itp.

Inną rzeczą, którą możesz spróbować, jest konwersja materiału do standardowej liczby klatek na sekundę i próba ponownego odtworzenia dźwięku ... ponieważ jestem całkiem pewien, że wideo dryfuje ... prawdopodobnie bardzo nieznacznie zwalnia, a następnie przyspiesza w kierunku koniec lub odwrotnie.

EDYCJA: Byłem w stanie zsynchronizować wideo z oryginałem za pomocą tego polecenia ffmpeg ... może potrzebować klauzuli częstości, co podejrzewałem

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

Miałem problem z podobnym problemem na Ubuntu 12.04.3 LTS. Rozwiązałem problem za pomocą statycznej kompilacji ffmpeg, która jest dostępna na stronie http://johnvansickle.com/ffmpeg/

Spróbuj po prostu zmienić kontener na avi zamiast transkodować, co wydaje się działać lepiej na youtube:

ffmpeg -i JSP.ogv -vcodec copy -acodec copy JSP.avi