Re: Re[2]: flv streaming

[Andrew Kopeyko <kaa@xxxxxxxx>]

On Wed, 26 Dec 2007, Alexey Kovyrin wrote:

> > On Dec 26, 2007 1:59 PM, Andrew Kopeyko <kaa@xxxxxxxx> 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@xxxxxxxx>