FFmpeg, аккуратная задержка аудио при конвертировании

Объясните физический смысл этой «задержки», как он рассчитывается, на что влияет, и как вы его в ощущениях видите. Как по мне, это фигня какая-то. ФФмпег чаще всего делает всё нормально, и нормальный плеер всё должен корректно проигрывать.

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

Как оно там рассчитывается я только догадываюсь, наверно поиском первых присутствий аудио и видео в «кадрах» контейнера. Разница во времени между первыми вхождениями - это задержка. Пусть меня поправят.

вы рассинхрон этот в сконвертированных видео видите? 0.1 с должно быть уже заметно.

Могу только предположить, что у кодеков, предназначенных для аудио, могут быть большие фреймы, например, по 60мс, и ffmpeg каким-то образом пытается подогнать исходное аудио под первый фрейм кодирования.

А какой fps у видео, к слову?

Я на ffmpeg подписан.

В соседней теме уже о значении положения -ss относительно -i писали. Раскроем тему.

Если -ss перед -i, то начало потока будет приблизительным. Время определяется на транспортном уровне, а здесь можно определить (и отрезать) видео по границе GOP, а аудио - по границе пакета. Достоинство этого способа - экономичность. Не надо читать (скачивать) весь файл. Не надо декодировать.

Если -ss после -i (но перед выходным файлом), позиционирование будет максимально точное - с точность до кадра и сэмпла. Но это потребует полного декодирования входного потока и последующего кодирования отрезанного потока. А это большие затраты: ввод-вывод и процессор.

Если в начале надо много пропустить, а отрезать максимально точно, то можно комбинировать оба способа позиционирования. Для этого надо учесть размер GOP: грубо спозиционироваться не ближе чем за GOP size до на начала, а потом сделать точное позиционирование:

ffmpeg ... -ss 00:25:00 -i http://mytube/hlup-hlup -ss 00:25:46 ...

Однако, все это совсем не связано с:

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

Синхронизация не имеет отношения к

Delay relative to video                  : -824ms

Эта задержка связана с B-frames. Из-за них мы не можем сразу декодировать первые кадры. Поэтому надо видео поток пускать с опережением звука на количество B-frames. Этот сдвиг происходит на транспортном уровне. Проигрыватель все это декодирует, задержит как надо, нарисует кадр и хлюпнет динамиком вовремя, т.е. синхронно. Для пользователя этот параметр определяет как быстро можно начать воспроизведение.

То, что в твоих примерах задержка плавает, это естественно. Задержка зависит от кодека и муксера. А на синхронизацию это не влияет.

Но при внесении задержки видео на 5 секунд "-itsoffset 5" выходит явный рассинхрон. А плееры ведут себя по разному: vlc проигрывает звук ничего не показывая первые 5 секунд, mpv начинает с начала видео, отбрасывая предшествующий звук. Кстати, значение указанное -itsoffset суммируется с уже существующей задержкой. Зачем? Может я таким образом синхронизировать пытаюсь.

Но при внесении задержки видео на 5 секунд "-itsoffset 5" выходит явный рассинхрон

- Ударь меня!
- Буммм!
- Аааа! Ты че дерешься?!

От изменения «Delay relative to video» содержание не меняется. Если эта задержка будет равна 0 при наличии B-frames, то это ляжет нагрузкой на проигрыватель. Поэтому по закону (стандарту) делают задержку _доставки_ звука.

А от "-itsoffset 5" (покажи видео на 5 сек. позже) содержание меняется!

и vlc, и mpv - ведут себя ожидаемо.

У тебя рассинхрон в мозгах. Ты чего хочешь-то?

-itsoffset к видео меняет «Delay relative to video» для аудио.
-itsoffset не поддерживает отрицательные величины. Как же подвинуть в минус звук если не видео вперёд?
Что я хочу? Да убрать нафиг всякие задержки сохранив синхронность. Как?

Эта задержка на синхронность не влияет. У тебя звук и видео записаны в один файл? Значит они уже синхронизированы.

Если при проигрывании этого файла у тебя картинка со звуком расходятся, то надо редактировать: менять timestamps кадров/звука. Это можно и itsoffset сделать. itsoffset отрицательные значения поддерживает. И потом подрезать висящие концы можно, чтобы не было звука без картинки и наоборот.

Задержка «Delay relative to video» определяется стандартом. Можно и ее убрать. Возможно, так ссать против ветра:

ffmpeg ... -muxdelay 0 -muxpreload 0 output.mkv

Эта задержка на синхронность не влияет

Мне что ушам/глазам своим не верить. Сейчас проверил еще раз, вот так:

ffmpeg -i in.mkv -itsoffset 5 -i in.wav -c:v libx264 -preset fast -crf 21 -sn -c:a copy -map 0:0 -map 1:0 out.mkv

Delay relative to video                  : 4s 160ms

muxdelay 0 -muxpreload

Вот эти не влияют, да, и на вывод mediainfo тоже.

ffmpeg -i in.mkv -itsoffset 5 -i in.wav

Ох-ты! Какой поворот! Теперь ты сводишь звук с картинкой! Муха в котлете. Да еще и wav. Напомню, вопрос ставился так:

Delay relative to video                  : -182ms

И т.п. Интересует почему задержка - величина непостоянная, можно ли в этом деле доверять ffmpeg-у, всё ли он делает правильно?

Мой ответ: эта задержка определяется параметрами кодирования, мультиплексирования и свойствами исходного материала. ffmpeg все делает правильно.

Так мы об чем беседуем?

К слову, если вам вдруг понадобиться использовать фильтр decimate, он может давать рассинхронизацию звука. Нужно применить патч.

http://git.videolan.org/?p=ffmpeg.git;a=patch;h=e4b0a77021a25fd538ef14791e31c...

Так мы об чем беседуем?

Смотри, одна и та же штука «Delay relative to video» может как влиять на синхронность, в случае когда её внесли через -itsoffset, так может и не влиять, когда её ffmpeg при муксинге посчитал нужной. Вот это для меня как-то странно и не совсем понятно. Ну да ладно.

Если я тебя ещё не совсем достал, скажи пожалуйста как муксить правильней? Примеры ниже. Как в первом случае с задержкой но где аудио не дефолт или как во втором - с дефолтом без задержки.

$ ffmpeg -i video.mkv -i audio-filtered.wav -c:v copy -c:a libfdk_aac -vbr 1 -map 0:0 -map 1:0 test1.mkv

$ mediainfo test1.mkv
...
Audio
ID                                       : 2
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : LC
Codec ID                                 : A_AAC
Duration                                 : 17mn 11s
Channel(s)                               : 1 channel
Channel positions                        : Front: C
Sampling rate                            : 44.1 KHz
Compression mode                         : Lossy
Delay relative to video                  : 1mn 5s
Default                                  : No
Forced                                   : No

$ ffmpeg -i audio-filtered.wav -c:a libfdk_aac -vbr 1 audio-filtered.mkv
$ ffmpeg -i video.mkv -i audio-filtered.mkv -c copy -map 0:0 -map 1:0 test2.mkv
$ mediainfo test2.mkv
...
Audio
ID                                       : 2
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : LC
Codec ID                                 : A_AAC
Duration                                 : 17mn 11s
Channel(s)                               : 1 channel
Channel positions                        : Front: C
Sampling rate                            : 44.1 KHz
Compression mode                         : Lossy
Default                                  : Yes
Forced                                   : No