Компании Haivision (https://en.wikipedia.org/wiki/Haivision) и Wowza (https://en.wikipedia.org/wiki/Wowza_Streaming_Engine), развивающие платформы для организации потокового видеовещания, учредили (http://www.haivision.com/news-events/news/haivision-and-wowz... организацию SRT Alliance (http://www.srtalliance.org/), нацеленную на продвижение нового открытого транспортного протокола SRT для безопасной доставки высококачественного потокового видео с минимальными задержками. Код эталонной реализации клиентской и серврной части SRT написан на языке Си и открыт (https://github.com/Haivision/srt) под лицензией LGPLv2. Для добавления поддержки SRT в приложения подготовлена разделяемая библиотека.
В отличие от передачи видео абонентам кабельных сетей, доставка потокового видео через обычный интернет сопряжена с рядом проблем, связанных с усложнениями при построении сетевой инфраструктуры, кэшировании CDN-сетями и перекодированием видео, а также возможными сетевыми перегрузками в области "последней мили (https://ru.wikipedia.org/wiki/%D0%9F%D0%.... Протокол SRT разработан для организации потокового вещания высококачественного видео поверх публичных TCP/IP-сетей, снижая негативные эффекты от потери пакетов, неоднородностей потока (jitter) и непостоянства пропускной способности каналов.
SRT обеспечивает минимальные задержки при доставке видео, обеспечивает постоянный мониторинг характеристик канала между конечными точками, адаптируется к параметрам канала связи в режиме реального времени и предоставляет упрощенные механизмы обхода межсетевых экранов. Для защиты от перехвата данных используется шифрование в режиме end-to-end (ключи присутствуют только на стороне конечного отправителя и получателя) c использованием 128/256-разрядного шифра AES. Отмечается, что протокол SRT хорошо подходит как для вещательных компаний и производителей продуктов для передачи видео, так и для разработчиков систем стримминга и online-вещания.SRT реализован поверх UDP и напоминает по своей сути RUDP (https://ru.wikipedia.org/wiki/RUDP) (Reliable UDP), предоставляя средства для быстрой повторной передачи потерянных пакетов и восстановления синхронизации видеопотока во времени после сбоев связи. Наработки основаны на протоколе, разработанном компанией Haivision для организации вещания в сетях с непостоянным качеством связи и большими задержками доставки пакетов. SRT уже используется в таких продуктах Haivision, как Makito X H.264/HEVC, Haivision Media Gateway, KB и Kraken. Компания Wowza заявила о применении SRT в Wowza Streaming Engine и других своих продуктах.
URL: http://www.haivision.com/news-events/news/haivision-and-wowz...
Новость: http://www.opennet.ru/opennews/art.shtml?num=46505
Чем он лучше того что использует для трансляций тот же ютуб?
На Ютубе нет задачи сделать минимальную задержку. Да, есть режим трансляции, но даже там задержка составляет порядка десяти секунд.
Не знаю про трансляции, но для обычных видосиков Ютуб использует MPEG-DASH. Правда, использует очень странным образом, кодирует весь ролик одним файлом. Стандарт предполагает, что видео кодируется небольшими кусочками, чтобы легко можно было перематывать, на ходу менять качество и т.д. А если кодируется одним файлом, то зачем вообще заморачиваться с DASH? Хватило бы и обычного progressive streaming.
Немного не по теме, но отвечу про один файл. Далеко не обязательно все кусочки держать отдельно, вполне можно их собрать в одном файле и в заголовке прописать начало каждого. Затем с помощью byte-range запроса запросить отдельный кусок. Так что, в конечном итоге никакой разницы нет, использовать отдельный файл на каждый кусок или один файл на все. В стандарте, кстати, есть оба варианта.
Спасибо за ответ!
Всё равно как-то не по себе, когда понимаешь, что внутри ютубовского JavaScript-а лежит полноценный парсер MP4. Хотя вроде как новые браузеры сами умеют DASH/HLS обрабатывать. Это немного успокаивает.
> Далеко не обязательно
> все кусочки держать отдельно, вполне можно их собрать в одном файле
> и в заголовке прописать начало каждого.У такого подхода есть один минус - для проигрывания видео нужно полностью скачать и отпарсить заголовок. Чем больше файл, тем больше заголовок. 10-20 секундные паузы перед показом такого видео - обычное дело. А ведь пользователю не нравится ждать. Поэтому от такого сейчас стараются уходить.
А зачем сразу все?
> того что использует для трансляций тот же ютубhttps://en.wikipedia.org/wiki/HTTP_Live_Streaming он использует
Ютуб использует то, что можно сделать в браузере. В браузере можно флеш (это хорошо и надежно работает), можно попробовать MSE (работает, но ещё хрупко), можно webrtc (будет работать только если не смешивать на кухне мясное и молочное).SRT — это эксперимент на тему UDP для вещания с мобилки на сервер.
Флеш хорошо и надёжно работает? Какая-то альтернативная реальность?
Вы бы узнали с кем общаетесь. Хотя что это я. Можно же посмотреть такое шоу по переписке...
Интересны отличия от стандартного RTP.
Меньшая чувствительность к дрожанию джиттера и контроль за целостностью потока.
Дрожание джиттера это джиттер в квадрате? ;)
Ну зачем же они взяли OpenSSL: она же ещё неопределённое кол-во времени будет страдать своей особенной лицензией.
Недостаточно протоколов, нужно строить больше протоколов.
Лоеры всея индустрии повернули носы на запах денег, настороженно потирая патенты.
>SRT реализован поверх UDP...Шо опять?.. Опыта с uTP оказалось мало?
Расскажите подробнее, что именно их должно было остановить от выбора в пользу UDP, для передачи видео потока, с минимальными задержками, без необходимости в сегментировании или подтверждении передачи данных на транспортном уровне?SRT самостоятельно умеет определять потери пакетов, задержки и дрожание (jitter) задержек. Зачем ему дублировать данный функционал на транспортном уровне, в лице TCP?
Очевидно, что авторы протокола ставили перед собой цель, создать максимально эффективный, но узко специализированный протокол, для передачи потокового видео. Отсюда и выбор в пользу транспортного протокола без отслеживания состояния, с минимальным размером заголовка в 8 байт и полным отсутствием контроля за получением, очерёдностью получения или буферами принимающей стороны в рамках протокола транспортного уровня.
Не может быть автоматической подстройки качества передаваемого видео без получения периодических данных от клиента о качестве (пропускной способности) канала связи, учитывая при этом, что маршруты могут меняться вне зависимости от желания передающей стороны и приёмной.
Так клиент их и передаёт очевидно в рамках SRT общения между клиентом и сервером, я не смотрел документацию по данному протоколу, но поправимо, если будет потребность выяснить, как он выполняет мониторинг качества канала.
> Зачем ему дублировать данный функционал на транспортном уровне, в лице TCP?Та же мысль. Потом мне показалось, что людям нужен Multicast, а TCP-транспорт в оно не умеет. Может быть одна из причин?
Как вариант, хотя в новости не сказано о multicast, а на сайте альянса они просят заполнить форму, чтобы получить больше сведений о их протоколе. Но, если бы они поддерживали reliable multicast, я думаю, что они бы об этом упомянули в своём пресс релизе.
>>SRT реализован поверх UDP...
> Шо опять?.. Опыта с uTP оказалось мало?разница тут в том, что есть понятие окна. Т.е. если видео не успели закачать за 5 секунд, то можно расслабиться и идти дальше.
Но всё это можно было сделать 10 лет назад на RTP
Круто, то что нужно, спасибо большое. Я как раз занимаюсь разработкой системы стримминга.
Готовь открыть своё творение под лицензией LGPLv2
А если я не хочу?
LGPLv2 позволяет динамическое связывание с проприетарщиной.
> Компании Haivision и Wowza
> клиентской и серверной части SRT написан на языке СиА как же Java, так любимая программерами из Wowza? 😂
Или это поделка Haivision под франшизой Wowza? Тогда всё понятно.> SRT реализован поверх UDP
Прогрессируют ребята. Наконец-то догадались, что изпользование CONP
для low latency streaming — есть зло. Ещё где-то лет 10—15 нужно,
чтобы догадались, что UDP контейнер тоже мало пригоден для этих целей. 😄
Пока винда не поддерживает DCCP, особого выбора нет.
какие видео/аудио-потоковые протоколы используются во всяких токсах-скайпах?
чем этот лучше/хуже?
> какие видео/аудио-потоковые протоколы используются во всяких токсах-скайпах?Разные.
> чем этот лучше/хуже?
Разным для разных.
P.S.: Всегда сочувствую людям, которым отрезали доступ в поисковики и Википедию.
"Код эталонной реализации клиентской и серверной части SRT написан на языке Си"
Галимая брехня
$ find -type f -name '*.h' -exec grep -H "class" {} \; | wc
96 349 4401
[podenok@zepp srt]$ find -type f -name '*.h' -exec grep -H "template" {} \; | wc
36 180 2086
$
C++ тоже хорошо или, в случае юзерспейса, даже лучше. Главное, не на новом, модном, стильном, молодёжном.
>Код эталонной реализации клиентской и серверной части SRT написан на языке Си и открыт под лицензией LGPLv2.Вот это по-нашему.
А кто-нибудь объяснит чем их webrtc не устроило?
Тем, что это вагон переусложнённой фигни?
И? Зато стандарт который уже поддерживает куча народа.
И есть шанс, что если сделать что-то получше, то его тоже поддержит куча народа. А формальные стандарты нынче стали менее важны.
Какая куча? И что с неё? Потоковый сервер видео вменяемый может подскажешь? Был ерлевидео - стал полностью платным. Всё остальное, вменяемое, только за деньги. И даже там этот вебртц кое-как впиливался. Сейчас не знаю в каком состоянии поддержка в разном серверном софте - несколько лет не слежу. И это за несколько лет существования в качестве "стандарта". Сколько ждать этот срт в софте, пять лет, десять?
>Сколько ждать этот срт в софте, пять лет, десять?Начни пользоваться сейчас. Прежде всего идет обкатка на своих наработках, а после успешных тестов уходит в массы.
Если ты не можешь написать свой клиент для SRT, то это не значит, что другие не могут. Вообще, надо радоваться, что движение есть.
Отлично. Прямо с завтрашнего рабочего дня начинаю пользоваться. Благородный дон конечно мне поможет с ссылками на открытые серверы потокового вещания видео с поддержкой SRT? Или он так, побалаболить вышел?
Годнота!
перепутать просто с hikvision
Интересно, чем им RTSP не устроил.
> чем им RTSP не устроилRTSP — угрёбищная TCP-шная фигня.
UDP отлично разлетается мультикастами по провайдерским сетям и фактически является основой для современных IPTV-решений.
> UDP отлично разлетается мультикастами по провайдерским сетям и фактически является основой
> для современных IPTV-решений.Совершенно верно. А они хотят это в OTT.
Вообще-то джиттер - это задержка...
> Вообще-то джиттер - это задержка...То вы с latency перепутали. А jitter --- это вариация задержки.