При разработке айфона Apple решила спроектировать и реализовать свой протокол для передачи видео. Несмотря на то, что существует масса протоколов: RTSP, MPEG-TS, HTTP (раздача файлов), RTMP, все они имеют какие-то слабые стороны. Все не-HTTP протоколы объединяет одна общая проблема: они режутся корпоративными файрволами и плохо переносят сильные флуктуации качества интернета.

Раздача файлов по HTTP имеет другую проблему: либо невозможность просмотра прямого эфира, либо отсутствие перемотки по потоку/файлу. Т.е. либо раздаем поток как flv-файл (endless http streaming), либо раздаем mp4 и тогда никакого прямого эфира.

Концепция протокола

Душа Microsoft реинкарнировалась в Apple и та решила пойти своим уникальным путём, плюнув на все существующие наработки. Они предложили брать видеопоток, резать его на сегменты где-то по 10 секунд, укладывать на диск и раздавать плейлист в котором урлы к этим файлам указаны по порядку просмотра. Этот подход позволяет перенести на браузер детекцию скорости до сервера, переключение между потоками (если интернета мало, просто скачиваем сегмент поменьше из соседнего плейлиста), а так же сильно сократить издержки на стриминг, ведь промежуточные прокси должны активно кешировать сегменты, тем самым многократно снижать трафик. Дьявол в деталях, ведь Microsoft SmoothStreaming устроен почти точно так же, но не так!

Проблема хранения

Детали кроются в том способе, которым упаковывается поток. Если вы хотите раздать через Apple HLS mp4 файл, то прийдется дополнительно раскошелиться, ведь поток должен быть упакован в MPEG-TS. MPEG-TS — это транспортный контейнер с очень широкими возможностями и спроектированный для передачи в том числе и вне IP сетей. Как следствие в нём есть много дублирующей информации, рассчитанной для детекции и даже коррекции ошибок. При передаче по HTTP эта информация избыточна, как результат в зависимости от ситуации объём хранения увеличивается на 15-30% Вот так с нихрена взяли и увеличили. Сравните это с Microsoft Streaming, в котором раздаются mp4 сегменты.

Apple предлагает брать открытый сегментер, пропускать через него файл и на диск лягут уже нарезанные сегменты с плейлистом. Т.е. вместо 30% роста объёма хранения, предлагается этот объём увеличить на 130%, ведь для других клиентов мы должны хранить mp4 файлы.

Самое то главное, что такой способ хранения в сотне маленьких файлов наносит ощутимый удар по файловой системе.

Логичное желание для устранения этой проблемы взять для этого медиастриминговый сервер типа erlyvideo, который умеет сегментировать на лету: он берет mp4 файл и перепаковывает нужный отрезок времени в MPEG-TS сегмент. Тут мы подходим к самой большой проблеме,

Проблема дизайна

Самая большая проблема это опять же выбор MPEG-TS. Дело в том, что для контроля за ошибками в этом контейнере используются continuity conters, это 4-х битные счетчики идущие в каждом аудио и видеоканале. Они должны идти связанно: 8,9,10,11,12,13,14,15,1,2. Если счетчики в соседних блоках не стыкуются, плеер в айфоне начинает спотыкаться.

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

Как же надо было сделать?

А сделать надо было так: не придумывать собственного велосипеда с треугольными колесами, а взять протокол Microsoft Smooth Streaming, в котором всё упаковывается в mp4 сегменты. Их очень легко генерировать на лету, они не завязаны друг на друга.