flv streaming

[Andrew Kopeyko]

On Wed, 26 Dec 2007, Alexey Kovyrin wrote:

>> On Dec 26, 2007 1:59 PM, Andrew Kopeyko <kaa at zvuki.ru> wrote:
>> Возможен - это описано в rfc про RTCP\RTSP как расширенная
>> функциональность.
>>
>> Наверное, именно из-за опицональности этого функционала seeking
>> поддерживается далеко не всеми серверами (в основном - проприентариными 
>> и платными); ну, а в силу этого, - и не всякими клиентами.

> Seeking в http streaming поддерживается всеми популярными
> веб-серверами (а это именно их задача) уже лет 100 как (apache,
> lighttpd, nginx).

Вот здесь вы, Алексей, заблуждаетесь и ошибаетесь.

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

Во-вторых, streaming - это, как учит нас Википедия 
http://en.wikipedia.org/wiki/Streaming_media , постоянный поток 
мультимедия данных, от сервера к клиенты, обрабатываемый в реальном 
времени: обоими, в случае live, или только клиентом, в случае on-demand.

Идея стримминга состоит в том, чтобы передавая только необходимые клиенту 
_в данный_момент_ данные (+- буферизация, но _небольшая_),
- уменьшить время от подключения до начала воспроизведения
- снизить нагрузку на сеть (ибо клиент может и не дослушать\досмотреть, а
   байтики-то уже переданы по сети...
Функция "защиты от скачивания" добавилась сильно позднее, а первоначальная 
задача была уменьшить нагрузку на не мощную сеть.


streaming от http отличается тем, что
- использует, как правило, 2 соединения: управляющее, и для данных; причём
   для данных может использоваться UDP
   - если используется 1 соединение, то seeking ограничен уже принятой
     клиентом частью потока
- поток данных передаётся с примерно постоянной скоростью, определяемой
   сторонами, а не каналом + настройками сервера\шейпера
- скорость потока данных может пересогласовываться и меняться в процессе
- может иметь несколько потоков данных, например: видео + звук, но это уже
   больше от используемого кодека зависит (современные могут
   мультиплексировать единственный транспортный поток)
- сервер в редких случаях по своей инициативе закрывает соединение -
   только в случае окончания on-demand streaming
- может работать с multicast'ом
- может работать как с файлами, так и с непрерывными источниками (live)
- не повторяет "пропавшие" данные - они уже не нужны...

Как видите, отличия разительны - и, в силу этого, реализация 
streaming-сервера сложнее, чем http-сервера.

Поэтому стримминг эмулируют, "приспосабливая" имеющиеся http-сервера, 
пользуясь
- толщиной современных broadband каналов;
- возможностью клиента буферизовать _много_ быстро-принимаемого контента,
   и затем уже с постоянной скоростью кормить им собственно кодек;
- умением распространённых кодеков мультиплексировать несколько
   media-потоков в единственном транспортном
Параметр start=XXX модуля mod_flv - это и есть пример такого приспосабливания.

Вот, кстати, сформулировался фундаментальный критерий отличия streaming от 
его http-эмуляции :

   В streaming'е функция seeking реализуется без прерывания соединения
   клиента с сервером, а в случае http-эмуляции - с прерыванием, ибо клиент
   делает новый запрос к серверу с другим параметром start=XXX.

   note:
   То, что этот новый запрос может быть передан серверу в пределах того же
   keep-alive соединения - сути дела не меняет, ибо мы говорим об
   соединениях прикладного уровня, а не транспортного.


А то, что плеер не позволяет сохранить принимаемый контент на диск - это 
ещё не streaming...


-- 
Best regards,
Andrew Kopeyko <kaa at zvuki.ru>