Медиапотоки по HTTP

[Dimka]

Кто может вкратце изложить, как осуществляется передача медиапотока по HTTP?

В интернетах обычно пишут в духе "поставь медиасервер". Меня не интересуют инструменты. Меня интересуют особенности трансляции.

Допустим, есть браузер с поддержкой HTML 5. И в нём открыта страница, на которой объект audio, способен проиграть wav. Если указать в качестве src некий URL, то что происходит дальше?

1) wav как файл загружается на клиента и только потом воспроизводится?
2) wav начинает воспроизводиться, параллельно подгружаясь?

Если вариант 2, то как всё это работает на плохих каналах с обрывом соединений? Организует ли сам браузер докачку, или пользователь вынужден перезагрузить объект для повторной попытки воспроизведения?

Если файл достаточно большой, и передача потока затягивается, допустим, на час, как всё это хозяйство обрабатывает таймауты операций и лимиты по объёму на клиенте и сервере?

[RXL]

Ничего особенного. POST/GET (200) с опциональной передачей с указанного места (206). Фишка в самом сервере, чтобы передавать данные с необходимой скоростью, не ниже необходимой для realtime и, желательно, c упреждением задержек.
Ну, контекстно могут быть заморочки, но в целом, это просто.

[Dimka]

RXL, я понимаю, что не сложно. Смущает именно временнАя длительность передачи и преодоление этой проблемы через нарезку на куски.

[RXL]

Генерация realtime медиапотока на сервере и его realtime воспроизведение на клиенте по определению не синхронизированы (если только они не пользуются общим задающим генератором). Это приведет к периодическому пропаданию фрагментов при воспроизведении, либо периодическому отбрасыванию избыточных фрагментов. Выгоднее производить такую ресинхронизацию в моменты передачи тишины.

Передача медиапотока по сети имеет пульсации. В телекоммуникациях есть термин jitter - дрожание сигнала/потока. В контексте медиапотока термин применяется к защитному буферу, призванному сглаживать пульсации сети. Если буфер опустел, происходит пропадание фрагмента, если переполнен - возможен отброс излишка. Логично, что буфер должен быть большего объема: при переполнении поздняя часть буфера отбрасывается. Больший размер буфера лучше сглаживает пульсации, но увеличивает задержку передачи.

Примеры: IP-телефония, inet-радиостанции, IP-видеосвязь.

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

Также контроль возможен на уровне TCP. Если клиент не успевает воспроизводить, то по переполнению TCP-буферов приема передача остановится. Если серверу остановка не выгодна, он может разорвать соединение или как-то иначе сигнализировать о необходимости рестарта медиапотока.

Наглядный пример последнего случая - передача видео с youtube.

[Dimka]

Это всё общие слова, и мне непонятно, как это связано с HTTP.

Вот есть, к примеру, Chrome или FF, вот на страничке есть audio с src, указывающим на какой-нибудь http://myserver/audio.cgi. Какие настройки веб-сервера нужны, чтобы аудиопоток длительностью воспроизведения час, потихоньку "сочился" из сервера на клиента со скоростью чуть выше скорости воспроизведения. Как минимум, это таймаут операции, если поток отдаётся как response на один request. Причём как-то так это надо сделать, чтобы для других запросов таймаут оставался вменяемо коротким.

[RXL]

Ну, если для тебя они общие...

С HTTP никак не связано. Только как обмен HTTP-заголовками как метаинформацией. HTTP не управляет потоком.

Видео/аудио в браузере поддерживает HTML 5. Ранние версии HTML, как и XHTML не поддерживают видео - его реализуют через плагины браузеров. Судя по "audion с src", речь о HTML 5.

В твоей ситуации все просто: сервер отдает как может, клиент принимает, как ему надо. Сперва защитный буфер клиента заполняется до отметки "норм" и запускается воспроизведение. Если буфер опустеет, звук прервется до поступления новой порции (как правило, при этом буфер также должен быть заполнен до "норм"). При полном заполнении буфера клиент перестает принимать данные и средствами TCP поток останавливается, до опустошения буфера до отметки "норм". Альтернативно клиент принимает поток без верхнего лимита, буферизируя его в кеш-файле.

[Dimka]

RXL, вот в том-то и дело. Меня не поток интересует (как буферы заполняются, и что с этим бывает, я и так знаю). Меня интересует именно HTTP как транспорт для потока.

И да, я сразу сказал про HTML 5 - в самом первом посте.

P.S. Похоже, пока сам не займусь опытами, не узнаю.

[Finch]

Dimka, Мне кажется, что ты на пустом месте трудности строиш. Для сервера медиа файлы ничем не отличаются от файлов HTML например. Клиент его запросил, он ему и отдал. Как клиент будет с ним работать, это не проблема сервера. IMHO Тут даже синхронизировать ничего не нужно.  Низнаю, как работают другие браузеры, Firefox например весь медиапоток кеширует на диске. Так что, после проигрывания, если не закрыть страницу, есть шанс переписать файл. А протокол HTTP используется потому, что нет проблем с файрволами. Найдется другой протокол, который будет такой же универсальный с файрволами, будут и его использовать.

[Dimka]

Finch, так мне как раз не надо, чтобы по HTTP поток передавался как обычный файл (на полной скорости весь объём). Мне надо, чтобы по HTTP шёл именно поток (медленно и долго, по мере воспроизведения). И терзают меня сомнения, что веб-сервер на такое по умолчанию согласен.

[Finch]

Ну так, огранич лимит скорости передачи файла. В чем проблема? Насколько я понял по онлайн фильмам, так в принципе и делают.

[zubr]

Dimka, запусти http-сниффер и запусти в броузере видеоролик - сразу все станет понятно.
Там идет get-запрос со множеством параметров, где один из параметров - кусок (начало и размер) видео-контента. В ответ от сервера идет кусок этого видеофрагмента. Таким образом за корректную работу получения видеопотока отвечает клиент, а сервер только выдает нужные фрагменты файла.

[Dimka]

Угу. Т.е., как я выше и сказал, пока сам экспериментально не установлю, что к чему, фиг кто расскажет.

запусти в броузере видеоролик

HTML 5 элемент video? Всякие flash-плееры не интересуют.

[zubr]

Частичные GET

HTTP позволяет запросить не сразу всё содержимое ресурса, а только указанный фрагмент. Такие запросы называются частичные GET, возможность их выполнения необязательна (но желательна) для серверов. Частичные GET в основном используются для докачки файлов и быстрого параллельного скачивания в нескольких потоках. Некоторые программы скачивают заголовок архива, выводят пользователю внутреннюю структуру, а потом уже запрашивают фрагменты с указанными элементами архива.

Для получения фрагмента клиент посылает серверу запрос с заголовком Range, указывая в нём необходимые байтовые диапазоны. Если сервер не понимает частичные запросы (игнорирует заголовок Range), то он вернёт всё содержимое со статусом 200, как и при обычном GET. В случае успешного выполнения сервер возвращает вместо кода 200 ответ со статусом 206 (Partial Content), включая в ответ заголовок Content-Range. Сами фрагменты могут быть переданы двумя способами:

    В ответе помещается заголовок Content-Range с указанием байтовых диапазонов. В соответствии с ними фрагменты последовательно помещаются в основное тело. При этом Content-Length должен соответствовать суммарному объёму всего тела.
    Сервер указывает медиа тип multipart/byteranges для основного содержимого и передаёт фрагменты указывая соответствующий Content-Range для каждого элемента (см. также Множественное содержимое).

http://ru.wikipedia.org/wiki/HTTP#.D0.A7.D0.B0.D1.81.D1.82.D0.B8.D1.87.D0.BD.D1.8B.D0.B5_GET

[Dimka]

Да знаю я про частичные GET - так любая качалка работает. Меня интересует, как ведут себя элементы HTML 5 - умеют ли делать докачки. О чём я спросил в самом начале.

P.S. Я же не прошу рассказывать про возможности HTTP. Я прошу рассказать, как это работает на линии сервер-клиент между страницей HTML 5 в браузере и веб-сервером.

[RXL]

Элементы HTML - абстракция. Вопрос к реализации. Более того, ничто не мешает какому-либо браузеру поменять реализацию в очередной версии.

[Dimka]

Добрался до проверок.

Во-первых, удивило и порадовало, что в audio помимо wav есть поддержка ogg и в Chrome, и в FF. Хотя поддержки mp2 или mp3 нету. Это важно с точки зрения экономии занимаемой ширины канала при трансляции: ogg выходит в 10 раз экономнее wav c pcm внутри. Пробовал в wav поместить mp2/3 вместо pcm - не воспроизводит.

Во-вторых, при ответе сервера 206 вместе с соответствующими заголовками про range Chrome инициирует дополнительные запросы, чтобы докачать содержимое. А вот FF этого не делает, ограничиваясь тем кусочком, что он скачал в первый заход. И это печально.

Буду думать, что делать с FF.

[RXL]

Ogg ничем не уступает mp3. Вопрос быстрее в том, поддерживает ли IE9+ ogg или надо держать на сайте альтернативу.
Наверняка поддержка mp3 решается плагинами к соотв. браузерам.

[Dimka]

RXL, мне не нужен IE, речь не идёт о публичном сайте.

P.S. В IE 9 элемент audio вообще не распознаётся.