Как понизить латентность h.264 видео в FFMPEG не прибегая к zerolatency?

Question

[StrangeAttractor]

В wiki ffmpeg сказано:

You may be able to decrease initial "startup" latency by specifing that I-frames come "more frequently" (or basically always, in the case of x264's zerolatency setting), though this can increase frame size and decrease quality, see ​here for some more background. Basically for typical x264 streams, it inserts an I-frame every 250 frames. This means that new clients that connect to the stream may have to wait up to 250 frames before they can start receiving the stream (or start with old data). So increasing I-frame frequency (makes the stream larger, but might decrease latency).

Как включить нулевую латентность вполне понятно - "-tune zerolatency", но я так и не понял как указать более высокую (но всё же не максимальную) частоту I-фрэймов, что советует этот параграф ("by specifing that I-frames come more frequently"). К чему относится описание "Basically for typical x264 streams, it inserts an I-frame every 250 frames" (что подразумевается в данном предложении "it")?

Answer 1

[XaLBa]

Вообще, под задержкой в zerolatency подразумевается разница между тем, когда кадр пришёл на вход энкодеру, и когда он его отдал. Задержка может быть вызвана, что декодер буферизует некоторое количество кадров. Насколько я помню, по умолчанию 40.

Без буферизации не получится кодировать B-кадры. Также, анализируя кадры из будущего, энкодер более точно распределяет битрейт между кадрами. Количество буферизуемых кадров контролируется параметром rc_lookahead.

Количество используемых по умолчанию B-кадров — 3, поэтому уменьшать их число или отключать стоит при необходимости в совсем малой задержке.

Также советую более подробно посмотреть на другие параметры, которые задаются через --tune zerolatency:

- zerolatency:
    --bframes 0 --force-cfr --no-mbtree
    --sync-lookahead 0 --sliced-threads
    --rc-lookahead 0

Если же вам нужно уменьшить интервал между I-кадрами, насколько я понял, в ffmpeg это делается опцией -g. Но на задержке это не сказывается. Возможно, даже слегка её увеличивает, поскольку I-кадры сжимаются хуже.

Comments

[StrangeAttractor]

Может я вообще всё неправильно понял? Меня интересует латентность не на этапе кодирования, а на этапе воспроизведения: бывает комп затупит, подвиснет на несколько кадров, а потом несколько секунд после возобновления движения на экране искарёженная каша, лишь с контурами и некоторыми частями правильной картинки. Я думал это от того, что в потоке периодически вставляются опорные кадры с целой картинкой (я думал т.н. "I-кадры" - это оно и есть), а все остальные считаются рекурсивно как разница от предыдущей и что "понижение латентности" - это вставка этих опорных кадров почаще.

[XaLBa]

Да, то, что вам нужно — это уменьшить интервал между I-кадрами. Как уже написал, в ffmpeg это должно делаться с помощью параметра -g <число кадров>.

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

Обычно повышенная частота I-кадров нужна для специальных случаев при передаче по сети. Например, IPTV или спутниковое вещание: телевизор не сможет показать картинку, пока не встретит в потоке I-кадр. При этом увеличение частоты I-кадров ухудшает степень сжатия. Поэтому при подборе настроек приходится искать баланс между качеством видео и временем, в среднем необходимым для «включения» картинки.

[StrangeAttractor]

@XaLBa "Но вообще, странно, что происходят такие сбои" - ничего странного: старенький ноутик на Core 2 Duo со старым Intel GMA (к которому кривые драйверы), который я гружу кучей задач одновременно как ломовую лошадь (а ещё частоту понизил чтобы не раскалялся и подольше прослужил) и слабенький смартфончик на котором я пытаюсь ещё и скорость проигрывания в VLC увеличивать, так что всё логично. Вот хочу немного беднягам задачу упростить :-] А ещё друган занимается IPTV, там тоже такое частенько наблюдается при недостаточно стабильном канале у клиента - ему тоже посоветую.

[ptQa]

Можно еще без b-кадров кодить и rc-lookahead поставить нулевым, тогда по идее должно быть меньше нагрузки на проц (если софтварное декодирование, конечно). Плюс возможно плеер декодит в 1 треде, можно включить декодинг сразу на двух, ffplay последний умеет это по дефолту.

[StrangeAttractor]

А есть что-нибудь аналогичное для обычных MPEG4 и MPEG2 (кодирую тем же FFMPEG)? Пытаюсь кодануть видео для проигрывания на старом оборудовании. Поддерживаются MPEG2 (MPG), MPEG4 (AVI) и H.264 (MP4). Всё работает, но на динамичных моментах сильно торомозит (на компе норм). H.264 с -zerolatency - уже получше. Думаю может если более старый алгоритм задействовать - будет побыстрее, но для них я не знаю как B-кадры регулировать (размер файла значения не имеет, MJPEG не поддерживается).

[XaLBa]

StrangeAttractor: Если вопрос в том, чтобы быстро декодировать, то это другая история. В первую очередь, стоит попробовать закодировать с -tune fastdecode (тоже алиас для набора опций x264). Отключение B-кадров, возможно тоже поможет. Остальные настройки от -tune zerolatency не влияют на скорость декодирования.

Если с fastdecode всё равно тормозит, то возможно битрейт слишком высокий, и стоит попробовать его понизить. Также можно уменьшать разрешение, у ffmpeg есть опции, в каком разрешении кодировать.

По поводу MPEG2 и MPEG4, увы, помочь не смогу. Но, вообще, думаю, что и конфигурацию x264 можно упростить настолько, что сложность декодирования будет сравнимой.