[maxlapshin]

Как автор видеостримингового сервера erlyvideo (http://erlyvideo.ru/ ) я бы хотел немного написать про опыт доставки видео через интернет и проэкстраполировать это на локальную сеть.

 

HTTP стриминг

 

Интернет харатеризуется неизвестной скоростью канала до абонента, непредсказуемыми прокси-серверами между абонентом и сервером и кучей других проблем, которые успешно решаются

в рамках контролируемой сети.

 

Не вдаваясь в детали, как именно мучались производители средств доставки видео последние 10 лет, можно с уверенностью сказать: сегодня остается только HTTP-стриминг.

Но не потоковая передача MPEG-TS по HTTP (connection: close без content-length), а кусочно-фрагментированная доставка, которая сводится к перекачке файлов клиенту.

 

Идея HTTP-стриминга (говорим прежде всего про HLS, а так же про HDS) в том, что видеопоток нарезается на кусочки (характер нарезки варьируется), эти кусочки пишутся

в отдельные файлы и ссылки на эти файлы пишутся в манифест. В случае раздачи прямого эфира используется метод скользящего окна, когда пишутся ссылки только на последние N фрагментов.

 

Дальше клиентский плеер скачивает манифест, скачивает несколько фрагментов, формируя буфер и может оперировать желаемым битрейтом на основании скорости скачивания: если в буфере осталось

только 2 фрагмента, значит дело швах и надо снижать битрейт. Если в буфере больше 5 фрагментов, значит можно повысить битрейт.

 

Профит

В итоге логика работы плеера сильно упростилась и впервые возник работающий мультибитрейтный плеер. На RTMP у адоба так и не получилось ничего пристойного добиться, а тут сразу получилось.

 

Сервер же превращается просто в нарезалку потока на файлики. Масштабирование, за которое так любят брать деньги вендоры, превращается в установку varnish, который работает как часы: один, второй, пятый.

 

Вопрос, связанный с DRM решается так: файлы шифруются AES, а плеер ходит по определенному урлу за ключом. Ключ можно ротировать хоть на каждый новый фрагмент (но ведь не нужно же, достаточно раз в минуту).

 

Минусы

 

Большая задержка. 30 секунд вообще считается минимально приличным буфером для HLS плеера.

 

На самом деле в этом нет ничего страшного, если речь не идет о риалтайме. Просто получилось так, что очень сильно разделилась доставка риалтайм видео и доставка не риалтаймового видео.

Т.е. видеочаты — это одно, а телевидение — другое. Учитывая, что речь больше не идет о UDP, а только по доставке файлов по HTTP смысл борьбы за микросекунды и стабильность сети сильно снизился,

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

 

На графике загрузки сети трафик одного клиента будет выглядить чередой пиков. Но уже при сотне клиентов всё выравнивается.

 

Локальная сеть

 

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

а из центра будет идти при этом только один поток видео.

 

Учитывая, что на HLS клиенты надо отдавать только H.264/AAC, то видео можно (увы, нужно) сжать с 4-8 мегабит MPEG-2 до 700 kbit H.264, что в предельном случае может дать экономию нагрузки сети, если такая потребность имеется.

 

Из минусов — надо ставить транскодеры. Самый простой и дешевый вариант — VLC + Core i7/Xeon. На один Core i7 можно повесить примерно 10-15 каналов SD.

 

Приставки

 

Приставки Amino умеют неплохо проигрывать HLS с прошивкой с оперой. Учитывая, что там опера, построение видеосистемы превращается в написание веб-сайта.

 

 

Резюме

 

Надеюсь, что кому-нибудь будет полезно или хотя бы будет пища для размышления.

 

У меня самого к сообществу такой вопрос: чем лучше всего организовывать HTTP прокси в такой системе? По факту получается аналог IGMP snooping-свитча, который смотрит в трафик внутри и его перехватывает.

 

Видится два варианта:

1) настройка прозрачного прокси (но идея плоха тем, что получается компонент через который пролезает весь пользовательский трафик)

2) помнить, где какие прокси и раздавать клиентам их адреса в веб-страничках на основании клиентских IP адресов. Эдакий внутренний CDN

Изменено 22 января, 2012 пользователем maxlapshin

[mag@]

 

Приставки Amino умеют неплохо проигрывать HLS с прошивкой с оперой. Учитывая, что там опера, построение видеосистемы превращается в написание веб-сайта.

 

 

Можно уточнить какие именно Amino? 125, 130, 140я или 500тые?

[Снежкин]

Идея HTTP-стриминга (говорим прежде всего про HLS, а так же про HDS) в том, что видеопоток нарезается на кусочки (характер нарезки варьируется), эти кусочки пишутся

в отдельные файлы и ссылки на эти файлы пишутся в манифест. В случае раздачи прямого эфира используется метод скользящего окна, когда пишутся ссылки только на последние N фрагментов.

Дальше клиентский плеер скачивает манифест, скачивает несколько фрагментов, формируя буфер и может оперировать желаемым битрейтом на основании скорости скачивания: если в буфере осталось

только 2 фрагмента, значит дело швах и надо снижать битрейт. Если в буфере больше 5 фрагментов, значит можно повысить битрейт.

уже реализовано на http://megogo.net

движок на флеше

Изменено 23 января, 2012 пользователем Снежкин

[maxlapshin]

Можно уточнить какие именно Amino? 125, 130, 140я или 500тые?

 

Я работаю сейчас со 140-ми. Играют без вопросов.

 

 

уже реализовано на http://megogo.net движок на флеше

 

Да, на этом сайте взят плеер на OSMF, который реализовала Adobe. Используется стриминг HDS.