Что вообще такое видео и как оно устроено
В этом треде попробую в 2-х словах накидать про видео-потоки, кодеки и покажу на примере пару особенностей.
Вообще видео, если очень упростить - это куча картинок, которые сменяют друг друга на экране в определенном порядке и с определенной скоростью.
Картинки должны быть одинакового размера и иметь таймстемп (так называемое, время воспроизведения на таймлайне).
Если взять какую-нить монтажку (например: Final Cut, Adobe Premiere) и глянуть на окно предпросмотра - мы увидим там набор из результирующих картинок, которые собирается из слоев, эффектов и доп. обвязок. Это так называемые RAW (сырые) кадры, которые рендерятся без сжатия.
Очевидно, если мы возьмем и сложим вместе кучу таких RAW-кадров или даже пожатых JPEGов и поставим их в хронолог. порядке - получится очень жирный файл, в интернете его будут качать до появления внуков. Поэтому лучшие умы человечества придумали такую штуку как CODEC.
CODEC - это железка или софт, который может сжимать/расжимать данные. Слово CODEC образовано от двух слов - coder/decoder.
Coder - штука, которая сжимает по своим алгоритмам данные, а Decoder соответсвенно - расжимает обратно (КО). В медиа кодеки - это сжатие с потерями.
Немного теории видеостроения. Если взять 5-сек. ролик и присмотреться, то весь видос можно снести к самому первому кадру и к тому, что из него "вытекает".
Например, на видео летит фризби. Первый кадр будет его начальное положение. А следующие - перемещение фризби по старому фону.
То есть, посмотрев и описав разность между кадрами, можно "выкинуть" лишние группы пикселей, а оставить только разницу между ними и описать где она происходит. Тем самым, второй и последующие кадры мы значительно уменьшаем в "весе" и финальное видео будет меньше JPEGового
Как идет разбиение видео
Видеопоток делится на группы пикселей, которые "перетаскиваются" по области рендера. В области, где картинка не меняется - макроблок заимствуется из предыдущего кадра. При движении же макроблок дробится на блоки/пиксели и "дорисовывается" поверх старого.
В видео есть 3 вида кадров:
- I-Frame - ключевой кадр, описанный полностью
- P-Frame - кадр, который опирается на предыдущий кадр
- B-Frame - кадр, который опирается на предыдущий и последующий кадры
Вот статейка про это: blog.video.ibm.com/streaming-vide…
Кол-во фреймов между одним и следующим ключевым (опорным) кадром называется GOP (en.wikipedia.org/wiki/Group_of_…). Он может быть константный или "плавающий". В зависимости от типа желаемого контента на выходе может быть применен один или другой тип и дать свои "плюшки".
Например, если вы показываете обычные MP4 по сети, то лучше использовать динамический GOP, так как енкодер будет сам определять когда нужно поставить ключевой кадр. Например, при смене плана (когда картинка меняется очень сильно) лучше поставить ключевой кадр для лучшего качества
В теории P и B кадры должны быть меньше I кадров, но это не всегда так. Например, при использовании константного GOPа смена планов скорее всего не попадет на ключевой фрейм. Тут, из-за большой разности в кадрах, кол-во битрейта на такой P/B фрейм понадобится большое.
Про битрейт и его количество
Чем больше битрейта вы "накините" на файл-тем качественнее и отчетливее он будет. Заигрываться с этим параметром не стоит, ибо:
- файл может получиться оч жирным
- в зависимости от картинки, есть "точка насыщения" контента, когда больше уже не надо
Предположим, вы сделали контент вашей мечты и откодили его. И вот дорожки бинарями лежат на вашем сервере и ждут своего часа. Как его посмотреть по сети? Нужно сделать его пригодным к проигрыванию через сеть. Самый распространенный способ - раздавать по HTTP.
Есть варианты:
- отдавать файл как специально подготовленным MP4
- отдавать через HTTP стриминг (HLS/DASH/MSS), предварительно "нарезав его кусками"
И тот и другой вариант имеет свои достоинства и недостатки.
Устройство MP4
Структура MP4 файла описывается т.н. "атомами". Вот основные из них:
- ftyp (тип файла и совместимость)
- mdat(payload, или сам контент)
- moov(атом со всей метадатой дорожек в MP4)
PS: Про то как читать MP4 неплохо расписал Максим Лапшин (levgem.livejournal.com/275096.html)
При транскодинге медиа в MP4 вначале записывается [ftyp] (без него никак), потом пишется медиа [mdat], откодированное при определенных настройках кодека, а уже в конце - записывается [moov] со всеми данными о файле - его длительности, составе медиапотоков и хар-ми на их декодинг.
Воспроизведение (декодирование) MP4 файла начинается со считывания именно [moov] атома, так как декодеры нужно настроить таким образом, чтобы payload был корректно воспроизведен плеером. И если он в самом конце файла - нужно будет скачать файл целиком, после чего его можно играть
Для того, чтобы иметь возможность играть файл сразу - меняют структуру MP4 файла, а именно: ставят [moov] атом в начало файла.
Например, было:
[ftyp][mdat][moov]
Стало:
[ftyp][moov][mdat]
Таким образом, по получении первых нескольких килобайт информации можно играть контент.
Http стриминг в целом работает по примерно такой же схеме, за исключением того, что файл дробится на части (чанки) и отдается либо отдельными файлами, либо байт-ренджами. Все адреса-явки-пароли находятся в манифесте (файле, который описывает вариации потоков, их адреса и св-ва)
Классический стриминг работает так:
-плеер получает манифест на контент
-в плеер тянутся init-чанки с выбранными дорожками (в них есть тот самый [moov]-атом)
-получив init-чанк, плеер инициализируется и готов к плейбеку
-получив чанки с контентом, плеер их воспроизводит
-профит)
Как мы видим/слышим закодированный контент
В плеерах есть декодеры, которые на основании информации в [moov] атомах интерпретируют закодированный payload медиа-контента. В зависимости от алгоритмов codec-ов, на это может уходить достаточно большое количество ресурсов устройства.
Хороший пример - Ютуб. Основной видео-кодек Ютуба VP8. На некоторых устройствах идет софтварное декодирование потока, что сильно бьет по производительности устройства в целом. Взамен этому - видео в VP8 много легче H264 при +/- одинаковом качестве итоговой картинки.
Ну вот, как-то так. На всякий приложу пару статей интересных про это вот все:
bitmovin.com/adaptive-strea…
elcomienzo.ru/h265-vs-h264-s…
macxdvd.com/mac-video-conv…