Формат OGV відтворюється належним чином на моєму комп’ютері, але перекодування скидає (дублює?) Кадри


11

Я зробив набір скріншотів, використовуючи recordmydesktop на ubuntu 12.10. Вихід - ogv-файл. Коли я переглядаю файл ogv за допомогою програвача фільму за замовчуванням (тотем), він виглядає добре - аудіо та відео синхронізуються. Коли вона перекодується (мною або ютубом), аудіо та відео не синхронізовані. Схоже, я пропускаю через слайд-два під час розповіді.

Оновлення

Я підозрюю, що проблема більш правильно характеризується як випадання дублікатів кадрів під час перекодування. Перетворення відео, куди рухається миша, здається, нормально працює. Але коли я просто розмовляю під час слайду, ці дублікати кадрів випадають.

Я це бачив, але це не зовсім моя ситуація (намагаюся перейти з ogv -> що-небудь) /superuser/436187/ffmpeg-convert-video-w-dropped-frames-out-of-sync

AVI файли, здається, правильно перекладаються! Я припускаю, що це буде великим натяком для когось. Я все одно хотів би розглянути основну проблему. Я тестую перетворення своїх попередніх відео в AVI, але це потребує певного часу, оскільки мені потрібно перевірити кожен перехід.

Приклади

Це оригінальний файл OGV від gtk-recordmydesktop: http://dl.dropbox.com/u/64693533/sync_test/sync_test1.ogv

Відео починається з слайду протягом 10 секунд, потім переходить до ще 3 слайдів по 5 секунд. Кожного разу, коли я просуваю слайди, я також торкаюся мікрофона (10s, 15s, 20s, 25s).

Ось кілька перетворень, які були виконані (кожен відображає власні проблеми з тимчасовим відео):

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

  • цей показує перший слайд у першому кадрі, але швидко просувається повз нього
  • це було зроблено за допомогою акції ffmpeg

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

  • цей досить близький - чомусь у 13-х він вирішує просуватися, хоча
  • це було зроблено за допомогою статичної збірки ffmpeg від декількох днів тому

Ось це на youtube - ви можете бачити, що близько 13-х років він просувається рано (зі слайда 1 -> слайда 2):

Ось доказ файлу OGV працює правильно:

ffmpeg переклад

Використовуючи ffmpeg або avconv, я, здається, отримую подібні результати, як у youtube (переходи, здається, відбуваються рано, але необов'язково одночасно).

Ось команда, яку я використовую (із недавньою статичною збіркою ffmpeg) та виводить:

$ ~ / ffmpeg / ffmpeg -i JSP.ogv JSP.mp4
ffmpeg версія N-50025-gb8bb661 Авторські права (c) 2000-2013 розробники FFmpeg
  побудований 17 лютого 2013 05:23:03 з gcc 4.6 (Debian 4.6.3-1)
  конфігурація: --prefix = / root / ffmpeg-static / 64bit --extra-cflags = '- I / root / ffmpeg-static / 64bit / include -static' --extra-ldflags = '- L / root / ffmpeg- статичний / 64bit / lib -static '--extra-libs =' - lxml2 -lexpat -lfreetype '--enable-статичний - відключити-спільний --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
  лібавутіл 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] Кілька риббонів для одного потоку не реалізовані. Оновіть свою версію FFmpeg до новітньої версії від Git. Якщо проблема все-таки виникає, це означає, що ваш файл має функцію, яка не була реалізована.
[ogg @ 0x34d4640] Помилка розбору заголовка для потоку 0
[ogg @ 0x34d4640] Несправний файл, ключовий кадр неправильно позначений.
Введення № 0, ogg, з 'JSP.ogv':
  Тривалість: 00: 12: 49,67, початок: 0,000000, бітрейт: 224 кб / с
    Потік № 0: 0: Дані: немає
    Потік № 0: 1: Відео: theora, yuv420p, 1600x880 [SAR 1: 1 DAR 20:11], 15 кадрів в секунду, 15 tbr, 15 tbn, 15 tbc
    Метадані:
      RECORDMYDESKTOP: 0.3.8.1
    Потік № 0: 2: Аудіо: vorbis, 22050 Гц, моно, fltp, 89 кбіт / с
[libx264 @ 0x369c5e0], використовуючи SAR = 1/1
[libx264 @ 0x369c5e0] з використанням можливостей процесора: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[libx264 @ 0x369c5e0] профіль Високий, рівень 4,0
[libx264 @ 0x369c5e0] 264 - ядро ​​129 r2230 1cffe9f - H.264 / MPEG-4 AVC кодек - Copyleft 2003-2012 - http://www.videolan.org/x264.html - параметри: cabac = 1 ref = 3 deblock = 1: 0: 0 проаналізувати = 0х3: 0х113 мені = шістнадцятковий субме = 7 пси = 1 пси_рд = 1,00: 0,00 змішаний_реф = 1 ме_ранж = 16 хрома_ме = 1 решітка = 1 8х8dct = 1 см2 = 0 мертвий пояс = 21,11 швидкий_піпп = 1 chroma_qp_offset = -2 нитки = 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 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
Вихід №0, mp4, до 'JSP.mp4':
  Метадані:
    датчик: Lavf54.63.100
    Потік № 0: 0: Відео: h264 ([33] [0] [0] [0] / 0x0021), yuv420p, 1600x880 [SAR 1: 1 DAR 20:11], q = -1--1, 15360 tbn , 15 табл
    Метадані:
      RECORDMYDESKTOP: 0.3.8.1
    Потік № 0: 1: Аудіо: aac ([64] [0] [0] [0] / 0x0040), 22050 Гц, моно, s16, 128 кбіт / с
Потокове відображення:
  Потік № 0: 1 -> # 0: 0 (theora -> libx264)
  Потік № 0: 2 -> # 0: 1 (vorbis -> libvo_aacenc)
Натисніть [q] для зупинки, [?] Для отримання довідки
[ogg @ 0x34d4640] Несправний файл, некерований кадр, неправильно позначений.
    Останнє повідомлення повторено 2 рази
Зламаний файл, нефіксований кадр неправильно позначений. = 00: 00: 08,37 бітрейт = 28,7 кбіт / с дуб = 66 крап = 0    
Несправний файл, ключовий кадр неправильно позначений.time = 00: 00: 51.01 бітрейт = 125,3 кбіт / с дуб = 675 крапля = 0    
Пошкоджений файл, ключовий кадр неправильно позначений. Час = 00: 00: 55,05 бітрейт = 140,2 кбіт / с дуб = 782 крап = 0    
Пошкоджений файл, ключовий кадр неправильно позначений. Час = 00: 00: 59,60 бітрейт = 140,5 кбіт / с дуб = 836 крап = 0    
[ogg @ 0x34d4640] Несправний файл, ключовий кадр неправильно позначений.
Несправний файл, ключовий кадр неправильно позначений.time = 00: 01: 08.00 бітрейт = 143,0 кбіт / с дуб = 900 крап = 0    
Несправний файл, ключовий кадр неправильно позначений. Час = 00: 01: 11,86 бітрейт = 141,6 кбіт / с дуб = 910 крап = 0    

... повторюється багато разів ...

Несправний файл, ключовий кадр неправильно позначений.time = 00: 12: 47,62 бітрейт = 153,0 кбіт / с дуб = 9087 крапля = 0    
кадр = 11521 fps = 87 q = -1,0 Lsize = 14849kB час = 00: 12: 49,48 бітрейт = 158,1kbit / s dup = 9087 drop = 0    
відео: 2401kB аудіо: 12024kB субтитр: 0 глобальні заголовки: 0kB muxing overhead 2.938094%
[libx264 @ 0x369c5e0] кадр I: 49 Сер. QP: 16,05 розмір: 29658
[libx264 @ 0x369c5e0] кадр P: 2912 Сер. QP: 9,88 розмір: 114
[libx264 @ 0x369c5e0] кадр B: 8560 Сер. QP: 12,76 розмір: 78
[libx264 @ 0x369c5e0] послідовні 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% пропуск: 99,9%
[libx264 @ 0x369c5e0] mb B I16..4: 0,0% 0,0% 0,0% B16..8: 0,3% 0,0% 0,0% прямий: пропуск 0,0%: 99,7% L0: 65,3% L1: 34,6% BI: 0,1%
[libx264 @ 0x369c5e0] 8x8 перетворення внутрішньо: 0,5% інтер: 15,8%
[libx264 @ 0x369c5e0] закодовано y, uvDC, uvAC внутрішньо: 6,4% 0,1% 0,1% інтер: 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] Зважені P-рамки: Y: 0,0% УФ: 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] кб / с: 25.60

Відео все ще просувається рано, але в різний час. Здається, gtk-recordmydesktop генерує "розбитий файл". Що дратує те, що OGV працює, тому здається, що я маю змогу зробити цю роботу з деяким набором варіантів.

Я виявив, що можу відтворити відео в kdenlive, і воно, здається, працює там. Я все одно хотів би знати, що відбувається. kdenlive робить набагато кращу роботу, але іноді все-таки просувається рано.


2
Будь ласка, покажіть свою команду ffmpeg та отриманий повний консольний вихід.
логікан

Хороша ідея @LordNeckbeard Я додав команду та вихід. Я помічаю помилку / попередження: досягнуто max_analyze_duration.
Амір Т

Чи все-таки виникає проблема, якщо ви використовуєте недавню статичну збірку ffmpeg ? Це виключає будь-які потенційні помилки, з якими ви можете зіткнутися, які вже були виправлені з новою версією ffmpeg. Не потрібно встановлювати чи нічого. Просто завантажте, витягніть архів і виконайте включений ffmpegдвійковий файл.
llogan

Чи можете ви надати зразок вхідного файлу, з яким можна відтворити проблему?
llogan

Хороша ідея, я зберу маленьку та опублікую її пізніше сьогодні ввечері.
Амір Т

Відповіді:


4

Навіщо конвертувати в OGV, коли остаточне завантаження відбуватиметься у youtube, я можу помилятися, але ви можете конвертувати в x264 відео кодек з AAC Audio навіть у Linux та завантажувати його у youtube, враховуючи, що це те, що вони вважають за краще завантажити. Ви спробували створити h264 та завантажити в youtube замість файлу OGV і побачити, чи це не проблема. Тому що я б став би в заклад, що якщо це вирішує це, то ви знаєте, що це проблема з завантаженням OGV на youtube, і якщо це не вирішує, це може бути проблемою зі швидкістю кадрів з інтерпретацією youtube або чимось подібним.

У минулому було багато проблем із файлами OGV, завантаженими на youtube. Я не можу уявити, що це на 100% фіксується навіть у цій точці.

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

EDIT: також щойно помітив, що ваші оригінальні кадри мають 15 кадрів в секунду ... це може бути джерелом проблеми

EDIT 2: Я, здається, трохи перечитав питання ... будучи тим, що ви починаєте з відеофайлу, який є OGV, і я побачив, що ви збираєтеся MP4 ... це трохи змінить речі. . Але я думаю, це має щось спільне з аудіо 15fps та 22050 Гц ... Я знаю, що частота вибірки не має нічого спільного з синхронізацією звуку, але з досвіду використання нестандартних частот кадрів та зразків звуку, Я схильний бачити дрейфування ... отримати їх для синхронізації може бути досить складно, не маючи можливості їх редагувати після початкової запису за допомогою дешевого відеоредактора ...

У той час як програмне забезпечення стало краще щодо дрейфування аудіо, все ж це поширена проблема при використанні нечастових кадрів і вибірки, оскільки ключові точки синхронізації не є стандартними і можуть округлювати ключові кадри тощо.

Ви бачите, де написано "Зламаний файл, ключовий кадр неправильно позначений". саме про це йдеться ...

моя порада для вас, щоб ви наблизили його якомога ближче, візьміть його у відеоредактор і підсуньте та виріжте звук, щоб він відповідав тому, як ви хочете. На жаль, іноді так це виправлено ...

Програмні транскодери не завжди працюють так, як слід ... Зважаючи на те, чому налаштування протоколів та / або завзята настройка поставляються з обладнанням для подальшого забезпечення можливостей синхронізації та постійної частоти кадрів тощо ...

Інша річ, яку ви можете спробувати, - це перетворити кадри в стандартний кадр і спробувати перезавантажити звук ... так як я впевнений, що це відео дрейфує ... напевно, так трохи сповільнюється, а потім прискорюється до кінець або навпаки.

EDIT: Мені вдалося змусити відео синхронізуватись із оригіналом за допомогою цієї команди ffmpeg ... можливо, у ньому знадобиться ставка ставки, в чому я підозрював

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


Оригінальний файл - відео Theora та аудіо Vorbis у контейнері ogv. Наскільки я знаю, Amir T не перекодує цей формат, але коли він намагається перекодувати оригінал за допомогою ffmpeg або YouTube, проблема синхронізації проявляється.
llogan

Формат введення - ogv, який видає gtk-recordmydesktop. Я намагаюся дістатися до чогось іншого, крім ogv (flv тощо).
Амір Т

Прочитайте мою оновлену відповідь ... Я думаю, що це питання FPS
Chris James Champeau

1
Додавання -r 15- це те саме, що пропустити його, тому що ffmpeg успадкує частоту кадрів вводу за замовчуванням, а отримані вихідні файли, з або без -r 15, точно такі ж, як і ffmpeg з git head (версія N-50285-gad89952). Якщо це працює для вас, використовуючи старішу версію ffmpeg, це може бути регресом, і про це слід повідомити у відстежувачі помилок FFmpeg .
логіан

1
Я з @LordNeckbeard, ви повинні повідомити про це як про помилку FFMPEG
Кріс Джеймс Шампо

3

Я боровся з подібною проблемою на Ubuntu 12.04.3 LTS. Я вирішив проблему за допомогою статичної збірки ffmpeg, яка доступна на веб-сайті http://johnvansickle.com/ffmpeg/


1
Я також спробував статичну збірку, і вона працювала дещо краще. Можливо, помилка була виправлена, і в цьому випадку може бути корисним додати номер версії зі статичної збірки до своєї відповіді?
Амір Т

0

Спробуйте просто змінити контейнер на avi, а не перекодувати, що, здається, працює краще для youtube:

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

Я спробував це, і завантаження просто не закінчує обробку так само, як якщо б я завантажував OGV. Оскільки ця відповідь передує youtube, що приймає OGV, це має бути саме ця зміна. Прикро, що ffmpeg все ще має цю проблему перетворення через чотири роки.
MCR

Мій ffpmeg є: 3.2.14-1 ~ deb9u1 (APT-отримати встановлений)
MCR

Я спробував усі варіанти вище, зі статичними збірками (git-20191029), і, хоча він стає трохи кращим, аудіо та відео не синхронізуються. Якщо для спроби потрібно велике --max_muxing_queue_size значення. Я використовував 40960.
MCR
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.