Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Медиапотоки по HTTP  (Прочитано 21026 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« : 09-08-2012 16:01 » 

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

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

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

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

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 09-08-2012 17:37 » 

Ничего особенного. POST/GET (200) с опциональной передачей с указанного места (206). Фишка в самом сервере, чтобы передавать данные с необходимой скоростью, не ниже необходимой для realtime и, желательно, c упреждением задержек.
Ну, контекстно могут быть заморочки, но в целом, это просто.
« Последнее редактирование: 09-08-2012 17:39 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 09-08-2012 19:17 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 09-08-2012 20:46 » 

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

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

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

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

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

Наглядный пример последнего случая - передача видео с youtube.
« Последнее редактирование: 09-08-2012 20:49 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #4 : 10-08-2012 07:53 » 

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 10-08-2012 15:31 » 

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

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

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #6 : 10-08-2012 15:52 » 

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

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #7 : 10-08-2012 18:09 » 

Dimka, Мне кажется, что ты на пустом месте трудности строиш. Для сервера медиа файлы ничем не отличаются от файлов HTML например. Клиент его запросил, он ему и отдал. Как клиент будет с ним работать, это не проблема сервера. IMHO Тут даже синхронизировать ничего не нужно.  Низнаю, как работают другие браузеры, Firefox например весь медиапоток кеширует на диске. Так что, после проигрывания, если не закрыть страницу, есть шанс переписать файл. А протокол HTTP используется потому, что нет проблем с файрволами. Найдется другой протокол, который будет такой же универсальный с файрволами, будут и его использовать.
« Последнее редактирование: 10-08-2012 18:14 от Finch » Записан

Не будите спашяго дракона.
             Джаффар (Коша)
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #8 : 10-08-2012 19:58 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #9 : 10-08-2012 20:44 » 

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

Не будите спашяго дракона.
             Джаффар (Коша)
zubr
Гость
« Ответ #10 : 10-08-2012 20:51 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #11 : 10-08-2012 21:29 » 

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

Цитата: zubr
запусти в броузере видеоролик
HTML 5 элемент video? Всякие flash-плееры не интересуют.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
zubr
Гость
« Ответ #12 : 11-08-2012 04:27 » 

Цитата
Частичные 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
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #13 : 11-08-2012 05:32 » 

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

P.S. Я же не прошу рассказывать про возможности HTTP. Я прошу рассказать, как это работает на линии сервер-клиент между страницей HTML 5 в браузере и веб-сервером.
« Последнее редактирование: 11-08-2012 05:43 от Dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #14 : 11-08-2012 07:14 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #15 : 21-08-2012 17:20 » 

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

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

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

Буду думать, что делать с FF.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #16 : 21-08-2012 18:55 » 

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

Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #17 : 21-08-2012 20:49 » new

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

P.S. В IE 9 элемент audio вообще не распознаётся.
« Последнее редактирование: 22-08-2012 05:53 от Dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines