Формат OGV правильно воспроизводится на моем компьютере, но перекодирует пропускаемые (дублирующиеся?) Кадры

Я сделал несколько скринкастов, используя recordmydesktop на Ubuntu 12.10. Выводом является файл ogv. Когда я смотрю файл ogv с помощью проигрывателя фильмов по умолчанию (тотем), он выглядит хорошо - аудио и видео синхронизированы. Когда он транскодируется (мной или YouTube), аудио и видео не синхронизированы. Похоже, я пропускаю слайд или два во время повествования.

Обновить

Я подозреваю, что проблема более правильно охарактеризована как удаление дублирующих кадров во время транскодирования. Преобразование видео, где движется мышь, кажется, нормально работает. Но когда я просто говорю во время слайда, эти дублирующие кадры удаляются.

Я видел это, но это не совсем моя ситуация (пытается перейти от 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 секунд каждый. Каждый раз, когда я продвигаю слайды, я тоже касаюсь микрофона (10 с, 15 с, 20 с, 25 с).

Вот некоторые преобразования, которые были сделаны (у каждого есть свои проблемы с синхронизацией видео):

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 Copyright (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- 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-серый --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] Несколько fisbone для одного и того же потока не реализованы. Обновите свою версию 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 тбр, 15 тбн, 15 тбк
    Метаданные:
      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 - кодек AVC H.264 / MPEG-4 - Copyleft 2003-2012 - http://www.videolan.org/x264.html - параметры: cabac = 1 ref = 3 deblock = 1: 0: 0 анализ = 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 мертвая зона = 21,11 fast_pskip = 1 chroma_qp_offset = -2 потоков = 6 lookahead_threads = 1 sliced_threads = 0 nr = 0 decimate = 1 чересстрочный = 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 тбн 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 кбит / с dup = 66 drop = 0    
Разбитый файл, ключевой кадр неправильно помечен. Time = 00: 00: 51.01 битрейт = 125.3 кбит / с dup = 675 drop = 0    
Разбитый файл, ключевой кадр неправильно помечен. Time = 00: 00: 55.05 битрейт = 140.2 кбит / с dup = 782 drop = 0    
Разбитый файл, ключевой кадр неправильно помечен. Time = 00: 00: 59.60 битрейт = 140,5 кбит / с dup = 836 drop = 0    
[ogg @ 0x34d4640] Разбитый файл, ключевой кадр помечен неправильно.
Разбитый файл, ключевой кадр неправильно помечен. Time = 00: 01: 08.00 битрейт = 143.0 кбит / с dup = 900 drop = 0    
Разбитый файл, ключевой кадр неправильно помечен. Time = 00: 01: 11,86 битрейт = 141,6 кбит / с dup = 910 drop = 0    

... повторяется много раз ...

Разбитый файл, ключевой кадр неправильно помечен. Time = 00: 12: 47.62 битрейт = 153.0 кбит / с dup = 9087 drop = 0    
frame = 11521 fps = 87 q = -1.0 Lsize = 14849kB время = 00: 12: 49,48 битрейт = 158,1 кбит / с dup = 9087 drop = 0    
видео: 2401 КБ, аудио: 12024 КБ, субтитры: 0 глобальных заголовков: 0 КБ, мультиплексирование 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 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] Взвешенные 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] кбит / с: 25.60

Видео еще впереди, но в разное время. Похоже, gtk-recordmydesktop генерирует «битый файл». Что раздражает, так это то, что OGV работает, поэтому мне кажется, что я должен быть в состоянии сделать эту работу с некоторым набором опций.

Я обнаружил, что могу рендерить видео в kdenlive, и, похоже, оно там работает. Я все еще хотел бы знать, что происходит. Kdenlive работает намного лучше, но иногда все еще продвигается рано.

Зачем переходить на 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=en&answer=1722171

РЕДАКТИРОВАТЬ: также только что заметил, что ваши оригинальные кадры на скорости 15 кадров в секунду ... это вполне может быть источником проблемы

РЕДАКТИРОВАТЬ 2: Я, казалось, немного неправильно понял вопрос ... в том, что вы начинаете с видео-файла, который является OGV, и я увидел, что вы собираетесь MP4 ... это немного меняет вещи ... .но я собираюсь догадаться, что это как-то связано со звуком 15fps и 22050 Гц ... Я знаю, что частота дискретизации не имеет ничего общего с синхронизацией звука, но из опыта, когда используются нестандартные частоты кадров и частоты дискретизации звука, Я склонен видеть дрейф ... синхронизировать их может быть довольно сложно, но я не могу редактировать их после первоначальной записи с помощью дешевого видеоредактора ...

Хотя программное обеспечение стало лучше справляться с дрейфующим звуком, оно все еще является распространенной проблемой, когда используются необычные частоты кадров и частоты дискретизации, поскольку ключевые точки синхронизации не являются стандартными и могут округлять ключевые кадры и т. Д.

Вы видите, где написано: «Сломанный файл, ключевой кадр неправильно помечен». это то, что он имеет в виду ...

Мой совет для вас будет сделать его как можно ближе, взять его в видеоредактор, вставить и разрезать звук, чтобы он соответствовал вашим желаниям. К сожалению, иногда это как это исправить ...

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

Другая вещь, которую вы можете попробовать, - это преобразовать отснятый материал в стандартную частоту кадров и попытаться повторно воспроизвести звук ... поскольку я почти уверен, что это дрейф видео ... возможно, немного замедляется, а затем ускоряется в направлении конец или наоборот.

РЕДАКТИРОВАТЬ: я смог получить видео для синхронизации с оригиналом с помощью этой команды ffmpeg ... может потребоваться условие скорости, что я и подозревал

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

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

Попробуйте просто поменять контейнер на avi, а не перекодировать, что, похоже, лучше для youtube:

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