Я пытаюсь понять, каковы существенные различия между серверной архитектурой, которая разработан для потоковой передачи мультимедиа, например FLV или h.264 для Flash-плееров по сравнению с обычным HTTP-сервером (например, Apache, обслуживающим статический контент), который может обеспечивать передачу данных также из смещений в больших файлах.
Я говорю о статическом видео-контенте, а не о потоковой передаче с прямой камеры или чего-то подобного. У меня всегда было впечатление, что обычный веб-сервер подойдет. Требования: обычное воспроизведение / пауза, а также прямой поиск для незагруженных частей видео. Мне кажется, что последнее также возможно со случайными серверами.
Дело в том, что настоящие потоковые серверы более эффективны, или есть вещи, которые они могут делать, а обычные серверы - нет?
Спасибо
Дело с живой и / или динамической потоковой передачей заключается в том, что простой протокол HTTP не имеет встроенных механизмов (в отличие от чего-то вроде RTMP). Так что на одном конце должен быть разум. На самом деле лучше, если у клиента есть «мозги», так сказать, и сделать веб-серверы немыми. Это хорошо для масштабируемости. Microsoft, яблоко, и Adobe у всех теперь есть довольно надежные решения для потоковой передачи через HTTP, где клиент знает, как запрашивать у сервера разные разрешения, битрейты и, самое главное, разные временные сегменты видеопотока. Это делает их решениями с очень большой пропускной способностью, кешем и CDN. Microsoft и Adobe действительно требуют, чтобы серверная часть модуля «разбивала» большой файл на сегменты, в то время как Apple предлагает вам предварительно разбить файлы на части и использовать полностью стандартный HTTP-сервер. Но в остальном весь интеллект находится в клиентском плагине, и вы можете поместить кеши прокси или CDN в режим исходной выборки в сочетании с любым из решений для очень быстрого масштабирования.
Традиционные протоколы потоковой передачи с установлением соединения требуют выделенных серверов и просто плохо масштабируются. Вы должны заплатить большие деньги Akamai или Limelight, чтобы запустить большое количество потоков для огромной аудитории. У них есть десятки тысяч серверов для обработки таких вещей.
Относительно новые параметры на основе HTTP, упомянутые выше, на самом деле работают с огромной инфраструктурой кэширования HTTP, уже существующей в Интернете в организациях и интернет-провайдерах, а также с огромной инфраструктурой кэширования HTTP, предлагаемой сетями CDN (которые обычно предлагают более низкие цены на доставку HTTP, чем подключение -на основе потоковой передачи).
Apple даже представила свое решение потоковой передачи Live HTTP в IETF для рассмотрения в качестве открытого стандарта (хотя я подозреваю, что есть патенты, о которых стоит беспокоиться от Move Networks, первопроходца в этом направлении).
"который может обеспечить подачу данных также из смещений в больших файлах"
Это требует дополнительных умений на клиенте и сервере - по сути, вы накладываете другой протокол поверх HTTP. Но существует множество инструментов, которые делают именно это. Однако я не знаю ни одного, работающего с источником потоковой передачи (например, камерой) - только с файлами, для которых определено начало измерения смещения. OTOH будет очень сложно перемещаться по прямой трансляции.