HTTP

Думаю не ошибусь, если скажу, что в нынешние времена веб-программирование занимает львиную долю всего программирования, а HTTP это кровь и нервы веба.

Использование HTTP дает много преимуществ:

• огромная развитая инфраструктура библиотек, фреймворков и всяких тулов под множество языков программирования;
• огромное число разработчиков и компаний, большой суммарный опыт, сложившиеся традиции с долгой историей (в масштабах истории IT как таковой);
• простые требования к клиенту (по сути нужен только браузер);
• гарантированная доставка данных;
• данные проходят через фаерволы;

Скажем так, вряд ли вы найдете разработчика, который никогда не имел дела с HTTP. Но вы легко найдете разработчиков, которые никогда не имели дела с какими-то другими способами передачи данных, кроме HTTP.

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

Однако пользователь, конечно, не хочет ждать, пока скачается весь файл. А хочет смотреть видео сразу же. И это возможно -- файл можно смотреть прямо в процессе скачивания (вот я вас удивил, да? :). Это называют Streaming Video или Progressive Downloading. А еще это называют Pseudo Streaming, дабы отличать от True Streaming, который реализуется с помощью медиа сервера (и о чем речь пойдет позже).

При этом пользователю доступна для просмотра только та часть видео, которая уже загрузилась на текущий момент. И только в пределах этой части возможна прокрутка.

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

Реализовать это не сложно на любом серверном языке программирования, например, на РНР. Но такая реализация будет малоэффективной. Поэтому обычно используют специальные модули для веб-сервера. Существуют, например, H264 streaming module для Apache, Lighttpd, Nginx и IIS; или FLV streaming module для Lighttpd. Такие модули пишутся на C и они гораздо эффективнее, чем собственный велосипед на интерпретируемом языке. Вот YouTube использует lighttpd.

Следующая проблема, которую нужно решить -- гладкое воспроизведение видео в условиях переменного качества связи. Ширина канала пользователя может меняться быстро и значительно. Если канала не хватает для передачи видео с той же скоростью, с которой оно воспроизводится, то будут возникать паузы. Желательно иметь одно и тоже видео, закодированное в разных вариантах качества (с разными битрейтами), и отдавать пользователю то качество, которое позволяет принять его канал.

Очевидный вариант -- иметь несколько видео файлов с одинаковым контентом, но разным битрейтом, определить ширину канала у пользователя, и отдать ему подходящий файл. Увы, такой простой вариант не годится, потому что ширина канала может измениться во время просмотра видео. Поэтому инженерная мысль дошла до того, чтобы не только иметь видео контент в разных битрейтах, а еще и дробить его на мелкие куски, скажем, по 10 секунд, и каждый такой кусок сохранять в отдельный файл. Тогда при изменении ширины канала пользователя его можно переключить на другую последовательность файлов, с другим качеством.

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

Именно таким образом построены решения по HTTP Streaming от Apple, Microsoft и Adobe.

• Apple HTTP Adaptive Streaming for iPhone/iPad
• Microsoft Smooth Streaming for Silverlight
• Adobe Dynamic Streaming for Flash

Все они похожи, но отличаются нюансами. Например, Apple использует транспортный контейнер MPEG-TS, а Microsoft и Adobe используют контейнер MP4 (при одинаковом у всех кодеке -- H.264).

На этом разговор про HTTP завершаем. Еще я предлагаю вам ознакомится с мнением Макса Лапшина, что вариант, выбранный Apple, хуже и с позитивным опытом использования Adobe Dynamic Streaming.