Сперва приведу основные ресурсы, из которых можно получить всю базовую информацию по протоколу:
спецификация протокола - http://www.adobe.com/devnet/f4v.html
описание файла манифеста - (формат f4m)
И, конечно же, основной ресурс, где весьма толково, без мудреных слов объяснено, как на практике подготовить файлы для вещания по данной технологии - http://www.thekuroko.com/http-dynamic-streaming-getting-started/
Повторять информацию, приведенную в вышеуказанном блоге, думаю, не имеет смысла, поэтому я лишь обобщу её и укажу те нюансы, с которыми я столкнулся и о которых нигде в сети информации не нашел.
Как происходит проигрывание потокого видео? Изначально плеер запрашивает файл манифеста (f4m), из которого он получает общую информацию о видеопотоке. Далее, если это прописано в манифесте, могут запрашиваться другие файлы, содержащие дополнительную управляющую информацию. После этого плеер осуществляет последовательные запросы фрагментов. Фрагмент представляет собой точно такой же mp4 файл (точнее, файл формата Adobe, структура которого очень близка к структуре mp4), но намного меньшего размера и содержит аудио и видео данные, обычно достаточные лишь для нескольких секунд проигрывания. Т.е. плеер запросил фрагмент, проиграл его, запросил следующий, проиграл, и т. д.
Первая сложность, с которой я столкнулся, была в том, что инструмент от Adobe - f4fpackeger, используемый при подготовке файлов на сервере, работает именно с файлами. Нам же нужны фрагменты, т. к. у нас видео передаётся в прямом эфире и на момент отправки видеоданных плееру мы еще понятия не имеем, какие данные у нас будут, скажем, через минуту. Что представляют собой фрагмент и какова его структура — об этом информация отсутствует. Лишь в спецификации формата вкратце упоминаются те атомы (т. е. такие блоки данных в файле, со строго определенной информацией), которые могут присутствовать в фрагментах и отсутствуют при подготовке обычных файлов. Но ни детального описания, ни примеров я не нашел. Т.е. той информации, которую мне удалось найти, было абсолютно недостаточно для разработки. Пришлось экспериментировать.
И вот тут, в процессе изучения структуры атомов , меня ждал первый сюрприз. В то время, как Microsoft в своей технологии создания фрагментов использует структуру атомов, очень близкую к самой структуре mp4, у Adobe всё обстоит иначе. Например, в mp4 файлах в атомах mdat содержатся только аудио/видео данные, без какой бы то ни было управляющей информации. У Adobe большая часть управляющей информации присутствует присутствует как раз в mdat атоме, совместно с аудио/видео данными. Причем присутствует не просто так, а инкапсулируя в себя протокол RTMP. Т.е. та моя позиция, согласно которой я считал, что разбираясь с форматом адаптивного стриминга от Adobe мне не потребуется знание протокола RTMP, оказалась ошибочной. Пришлось разбираться с RTMP. Правда, всё-таки не в полном объеме, но всё-равно пришлось. К счастью, множество экспериментальных попыток, анализ информации со всех сторон сделали своё дело и я успешно справился со структурой mdat атома.
Далее нужно было понять, как именно формировать фрагменты, т. к., как я уже отмечал, f4fpackager работает с файлами. К счастью, методом проб и ошибок, я успешно справился и с этой задачей, в итоге трансляция заработала.
Здесь меня поджидал следующий бич, с которым, как я замечал, сталкиваются многие вещательные системы — это синхронизация видео и аудио. Данному вопросу я посвятил отдельную заметку — синхронизация аудио и видео данных
Остался последний шаг.
Я проанализировал те данные, которые сейчас отправлялись плееру. Невооруженным глазом было видно, что среди них весьма значительную часть составляет абсолютно неважная управляющая информация, иногда даже просто ненужная. Эта информация передавалась с каждым фрагментом, давая ощутимую добавку к битрейту. Не знаю, зачем так было сделано, может быть были какие-то объективные причины, но у меня сразу возникло желание избавиться от этой ненужной информации. И действительно, после ряда экпериментов я сократил управляющую информацию процентов на 70 при том, что это абсолютно никак не сказалось на воспроизведении плеером. В частности, данный факт можно вполне рассматривать как преимущество перед профессиональными системами видеотрансляций от Adobe.
Игорь, Октябрь 2012.
|