Переменный битрейт для потоковой передачи?

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

https://support.google.com/youtube/answer/1722171?hl=ru

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

Я думаю, вы неправильно понимаете, что делает кодирование с переменным битрейтом. Это не вводит заикание или паузы.
IDK, который проголосовал за это. Это не плохой вопрос, ИМО, просто вопрос для начинающих.
О, также обратите внимание, что ваша ссылка посвящена тому, как делать видео для ЗАГРУЗКИ на YouTube, чтобы их можно было перекодировать перед потоковой передачей. Это один раз кодировать, один раз декодировать, без ограничений в реальном времени, вариант использования полностью отличается от хостинга видео для потоковой передачи. Для загрузки на YouTube вы хотите использовать большой битрейт, и если у вас есть пропускная способность загрузки, время кодирования имеет такое же значение, как и полученный размер файла. Таким образом, вы можете использовать x264 --crf 16 --preset fast.
Я не ошибаюсь и не новичок (на самом деле я создал свой первый сервис потокового видео в 1997 году). Я отвечу на все остальное в вашем ответе, но уточню: ссылка была лишь одним из примеров рекомендации, которую я вижу повсюду. Основываясь на ваших ответах, кажется, что все просто предполагают, что каналы и буферы достаточно велики, чтобы компенсировать всплески битрейта в наши дни.

Ответы (1)

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

Я предполагаю, что вы собираетесь использовать кодек h.264 (также известный как AVC), так как это де-факто стандарт для потокового видео в Интернете. VP8 не такого хорошего качества. VP9 может выглядеть лучше, чем h.264, но поддержка ограничена. HEVC (h.265) также лучше, чем h.264, но опять же поддержка проигрывателя ограничена. (А аппаратное ускорение декодирования не будет широко распространено в течение многих лет. Это важно, потому что HEVC очень интенсивно использует процессор для декодирования, больше, чем AVC.)

Я говорю о сравнении качества с лучшими доступными кодировщиками для каждого кодека. x264 для AVC, VPx от Google для VP8/VP9 и x265 для HEVC. Все с настройками выкручены почти до конца. Однако x265 начнет получать количество секунд на кадр вместо кадров в секунду для 1080p с такими медленными настройками. (на x264 порядка быстрее, так как он был практически зрелым в течение нескольких лет, и было обнаружено несколько новых ускорений или улучшений качества.)

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

Случайный поиск в Google на x264 vbv для потоковой передачи: http://forum.doom9.org/showthread.php?t=147460

Пример из x264 --fullhelp:

  Constant bitrate at 1000kbps with a 2 second-buffer:
        x264 --vbv-bufsize 2000 --bitrate 1000 -o <output> <input>

(на самом деле не используйте однопроходный режим целевого битрейта. Либо 2pass, если у вас есть конкретный целевой битрейт, либо crf с целевым качеством.)

редактирование: рекомендуемое использование для потоковой передачи, по словам ведущего разработчика x264 (Джейсона Гарретта-Глазера), — это режим целевого качества (CRF) с битрейтом, ограниченным VBV. например

x264 --vbv-bufsize 2000 --vbv-maxrate 1000 --crf 22 -preset slower -o <output> <input>

vbv-maxrateэто максимальная скорость, с которой буфер может заполниться. (т.е. максимальная пропускная способность сети). vbv-bufsizeэто, конечно, размер буфера, который допускает неустойчивые пики битрейта выше, чем vbv-maxrate.

И, конечно же, если вы кодируете один раз, чтобы создать файл, который будет транслироваться много раз, тратьте на это как можно больше процессорного времени. Время кодирования не имеет большого значения по сравнению с получением максимального качества на битрейт (компромисс между скоростью и искажением, также известный как RD). Кодирование происходит только один раз, и любые биты, которые вы можете сохранить (при сохранении того же качества), сохраняются при каждой загрузке. например, используйте x264 с --preset veryslow.

Как вы говорите, плееры буферизуют потоки. Так что же происходит, когда буфер заканчивается? Почему воспроизведение заикается и останавливается, конечно! Возьмем ваш пример, приведенный выше. Представьте, что пользователь получает стабильное соединение со скоростью 1200 кбит/с к моему сервису. Представьте, что пользователь смотрит поток, который требует около 1000 кбит/с в течение первых пяти минут. Большой! Но теперь, если этот файл является VBR (обратите внимание, что их пример не является таковым), вашему файлу может внезапно потребоваться 2500 кбит/с в течение следующих пяти минут. Ваш 2-секундный буфер заканчивается довольно быстро, и зритель практически больше не может смотреть видео.
Весь смысл сообщения кодировщику размера буфера заключается в том, чтобы он мог принять это во внимание для управления скоростью, чтобы убедиться, что он не переполняет буфер. x264 всегда будет предупреждать вас, если он не соответствует вашим требованиям VBV. (например, чрезвычайно низкий битрейт для HD, и он не мог получить его, даже размывая все до дерьма.)
Я думаю, что материал, который вы нашли до сих пор, не объяснил, так это то, что VBR не обязательно означает VBR только с целью качества. Современные аудио- и видеокодеры теперь поддерживают управление скоростью VBR с ограничениями, при котором также соблюдаются общие и локальные ограничения скорости передачи. Но в остальном они могут свободно тратить биты там, где это необходимо, чтобы получить максимально возможное качество всего клипа. Вы правы в том, что здесь есть проблема, которую необходимо учитывать, и --vbv-buffsizeзаключается в том, как это делается.
edit: обновил мой ответ после повторного поиска в Google. vbv-maxrate- это скорость заполнения буфера, а не пик декодирования, ограниченный процессором декодера. А CRF + VBV — это рекомендуемый способ кодирования видео в режиме онлайн (в реальном времени) или в автономном режиме для потоковой передачи.
Переменный битрейт для потоковой передачи?
СпросиСетьПолитика конфиденциальности1y, 0v