The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлен SRT, открытый протокол для потоковой передачи видео

05.05.2017 21:32

Компании Haivision и Wowza, развивающие платформы для организации потокового видеовещания, учредили организацию SRT Alliance, нацеленную на продвижение нового открытого транспортного протокола SRT для безопасной доставки высококачественного потокового видео с минимальными задержками. Код эталонной реализации клиентской и серверной части SRT написан на языке C++ и открыт под лицензией LGPLv2. Для добавления поддержки SRT в приложения подготовлена разделяемая библиотека.

В отличие от передачи видео абонентам кабельных сетей, доставка потокового видео через обычный интернет сопряжена с рядом проблем, связанных с усложнениями при построении сетевой инфраструктуры, кэшировании CDN-сетями и перекодированием видео, а также возможными сетевыми перегрузками в области "последней мили". Протокол SRT разработан для организации потокового вещания высококачественного видео поверх публичных TCP/IP-сетей, снижая негативные эффекты от потери пакетов, неоднородностей потока (jitter) и непостоянства пропускной способности каналов.

SRT обеспечивает минимальные задержки при доставке видео, обеспечивает постоянный мониторинг характеристик канала между конечными точками, адаптируется к параметрам канала связи в режиме реального времени и предоставляет упрощенные механизмы обхода межсетевых экранов. Для защиты от перехвата данных используется шифрование в режиме end-to-end (ключи присутствуют только на стороне конечного отправителя и получателя) c использованием 128/256-разрядного шифра AES. Отмечается, что протокол SRT хорошо подходит как для вещательных компаний и производителей продуктов для передачи видео, так и для разработчиков систем стримминга и online-вещания.

SRT реализован поверх UDP и напоминает по своей сути RUDP (Reliable UDP), предоставляя средства для быстрой повторной передачи потерянных пакетов и восстановления синхронизации видеопотока во времени после сбоев связи. Наработки основаны на протоколе, разработанном компанией Haivision для организации вещания в сетях с непостоянным качеством связи и большими задержками доставки пакетов. SRT уже используется в таких продуктах Haivision, как Makito X H.264/HEVC, Haivision Media Gateway, KB и Kraken. Компания Wowza заявила о применении SRT в Wowza Streaming Engine и других своих продуктах.

  1. Главная ссылка к новости (http://www.haivision.com/news-...)
  2. OpenNews: Открыты спецификации на беспроводной протокол Z-Wave
  3. OpenNews: Google намерен использовать сетевой протокол QUIC в браузере Chrome по умолчанию
  4. OpenNews: Открыт протокол uTP, призванный уменьшить нагрузку при использовании BitTorrent
  5. OpenNews: BitTorrent тестирует расширение протокола для организации потокового вещания
  6. OpenNews: Компания Google представила основанный на UDP экспериментальный протокол QUIC для ускорения Web
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/46505-video
Ключевые слова: video, stream
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (49) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Принц (?), 23:15, 05/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Чем он лучше того что использует для трансляций тот же ютуб?
     
     
  • 2.6, h31 (ok), 01:29, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На Ютубе нет задачи сделать минимальную задержку. Да, есть режим трансляции, но даже там задержка составляет порядка десяти секунд.
    Не знаю про трансляции, но для обычных видосиков Ютуб использует MPEG-DASH. Правда, использует очень странным образом, кодирует весь ролик одним файлом. Стандарт предполагает, что видео кодируется небольшими кусочками, чтобы легко можно было перематывать, на ходу менять качество и т.д. А если кодируется одним файлом, то зачем вообще заморачиваться с DASH? Хватило бы и обычного progressive streaming.
     
     
  • 3.9, kernel (??), 06:24, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Немного не по теме, но отвечу про один файл. Далеко не обязательно все кусочки держать отдельно, вполне можно их собрать в одном файле и в заголовке прописать начало каждого. Затем с помощью byte-range запроса запросить отдельный кусок. Так что, в конечном итоге никакой разницы нет, использовать отдельный файл на каждый кусок или один файл на все. В стандарте, кстати, есть оба варианта.
     
     
  • 4.27, h31 (ok), 16:54, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо за ответ!
    Всё равно как-то не по себе, когда понимаешь, что внутри ютубовского JavaScript-а лежит полноценный парсер MP4. Хотя вроде как новые браузеры сами умеют DASH/HLS обрабатывать. Это немного успокаивает.
     
  • 4.37, XoRe (ok), 12:09, 07/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Далеко не обязательно
    > все кусочки держать отдельно, вполне можно их собрать в одном файле
    > и в заголовке прописать начало каждого.

    У такого подхода есть один минус - для проигрывания видео нужно полностью скачать и отпарсить заголовок. Чем больше файл, тем больше заголовок. 10-20 секундные паузы перед показом такого видео - обычное дело. А ведь пользователю не нравится ждать. Поэтому от такого сейчас стараются уходить.

     
     
  • 5.43, Ан (??), 05:24, 08/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем сразу все?
     
  • 2.7, user (??), 01:41, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > того что использует для трансляций тот же ютуб

    https://en.wikipedia.org/wiki/HTTP_Live_Streaming он использует

     
  • 2.30, Максим Лапшин (?), 19:46, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ютуб использует то, что можно сделать в браузере.  В браузере можно флеш (это хорошо и надежно работает), можно попробовать MSE (работает, но ещё хрупко), можно webrtc (будет работать только если не смешивать на кухне мясное и молочное).

    SRT — это эксперимент на тему UDP для вещания с мобилки  на сервер.

     
     
  • 3.39, Аномномномнимус (?), 12:30, 07/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Флеш хорошо и надёжно работает? Какая-то альтернативная реальность?
     
     
  • 4.41, Аноним (-), 19:50, 07/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Вы бы узнали с кем общаетесь. Хотя что это я. Можно же посмотреть такое шоу по переписке...
     

  • 1.2, Андрей (??), 23:48, 05/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Интересны отличия от стандартного RTP.
     
     
  • 2.47, Csh (?), 14:02, 08/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Меньшая чувствительность к дрожанию джиттера и контроль за целостностью потока.
     
     
  • 3.48, Аноним (-), 17:15, 08/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Дрожание джиттера это джиттер в квадрате? ;)
     

  • 1.3, Андрей (??), 23:49, 05/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну зачем же они взяли OpenSSL: она же ещё неопределённое кол-во времени будет страдать своей особенной лицензией.
     
  • 1.4, Не нужно (?), 00:33, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Недостаточно протоколов, нужно строить больше протоколов.
     
  • 1.5, Аноним (-), 00:35, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лоеры всея индустрии повернули носы на запах денег, настороженно потирая патенты.
     
  • 1.8, Аноним (-), 04:26, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    >SRT реализован поверх UDP...

    Шо опять?..  Опыта с uTP оказалось мало?

     
     
  • 2.11, zanswer CCNA RS (?), 09:19, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Расскажите подробнее, что именно их должно было остановить от выбора в пользу UDP, для передачи видео потока, с минимальными задержками, без необходимости в сегментировании или подтверждении передачи данных на транспортном уровне?

    SRT самостоятельно умеет определять потери пакетов, задержки и дрожание (jitter) задержек. Зачем ему дублировать данный функционал на транспортном уровне, в лице TCP?

    Очевидно, что авторы протокола ставили перед собой цель, создать максимально эффективный, но узко специализированный протокол, для передачи потокового видео. Отсюда и выбор в пользу транспортного протокола без отслеживания состояния, с минимальным размером заголовка в 8 байт и полным отсутствием контроля за получением, очерёдностью получения или буферами принимающей стороны в рамках протокола транспортного уровня.

     
     
  • 3.12, Ydro (?), 09:30, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Не может быть автоматической подстройки качества передаваемого видео без получения периодических данных от клиента о качестве (пропускной способности) канала связи, учитывая при этом, что маршруты могут меняться вне зависимости от желания передающей стороны и приёмной.
     
     
  • 4.14, zanswer CCNA RS (?), 09:43, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так клиент их и передаёт очевидно в рамках SRT общения между клиентом и сервером, я не смотрел документацию по данному протоколу, но поправимо, если будет потребность выяснить, как он выполняет мониторинг качества канала.
     
  • 3.35, sakra (ok), 08:17, 07/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем ему дублировать данный функционал на транспортном уровне, в лице TCP?

    Та же мысль.  Потом мне показалось, что людям нужен Multicast, а TCP-транспорт в оно не умеет.  Может быть одна из причин?

     
     
  • 4.36, zanswer CCNA RS (?), 10:31, 07/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Как вариант, хотя в новости не сказано о multicast, а на сайте альянса они просят заполнить форму, чтобы получить больше сведений о их протоколе. Но, если бы они поддерживали reliable multicast, я думаю, что они бы об этом упомянули в своём пресс релизе.
     
  • 2.31, Максим Лапшин (?), 19:48, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>SRT реализован поверх UDP...
    > Шо опять?..  Опыта с uTP оказалось мало?

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

    Но всё это можно было сделать 10 лет назад на RTP

     

  • 1.10, Игорь (??), 08:34, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Круто, то что нужно, спасибо большое. Я как раз занимаюсь разработкой системы стримминга.
     
     
  • 2.13, Ydro (?), 09:33, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Готовь открыть своё творение под лицензией LGPLv2


     
     
  • 3.15, Игорь (??), 09:47, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А если я не хочу?
     
  • 3.20, Аноним (-), 11:59, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    LGPLv2 позволяет динамическое связывание с проприетарщиной.
     

  • 1.17, t28 (?), 10:36, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Компании Haivision и Wowza
    > клиентской и серверной части SRT написан на языке Си

    А как же Java, так любимая программерами из Wowza? 😂
    Или это поделка Haivision под франшизой Wowza? Тогда всё понятно.

    > SRT реализован поверх UDP

    Прогрессируют ребята. Наконец-то догадались, что изпользование CONP
    для low latency streaming — есть зло. Ещё где-то лет 10—15 нужно,
    чтобы догадались, что UDP контейнер тоже мало пригоден для этих целей. 😄

     
     
  • 2.32, Аноним (-), 20:39, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Пока винда не поддерживает DCCP, особого выбора нет.
     

  • 1.18, JL2001 (ok), 10:51, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    какие видео/аудио-потоковые протоколы используются во всяких токсах-скайпах?
    чем этот лучше/хуже?
     
     
  • 2.25, Аноним (-), 15:00, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > какие видео/аудио-потоковые протоколы используются во всяких токсах-скайпах?

    Разные.

    > чем этот лучше/хуже?

    Разным для разных.

    P.S.: Всегда сочувствую людям, которым отрезали доступ в поисковики и Википедию.

     

  • 1.19, adolfus (ok), 11:15, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Код эталонной реализации клиентской и серверной части 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
    $

     
     
  • 2.22, Аноним (-), 12:06, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    C++ тоже хорошо или, в случае юзерспейса, даже лучше. Главное, не на новом, модном, стильном, молодёжном.
     

  • 1.21, Аноним (-), 12:02, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >Код эталонной реализации клиентской и серверной части SRT написан на языке Си и открыт под лицензией LGPLv2.

    Вот это по-нашему.

     
  • 1.23, Аноним (-), 13:09, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А кто-нибудь объяснит чем их webrtc не устроило?
     
     
  • 2.24, Crazy Alex (ok), 14:51, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тем, что это вагон переусложнённой фигни?
     
     
  • 3.26, Аноним (-), 15:05, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    И? Зато стандарт который уже поддерживает куча народа.
     
     
  • 4.29, Crazy Alex (ok), 18:28, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И есть шанс, что если сделать что-то получше, то его тоже поддержит куча народа. А формальные стандарты нынче стали менее важны.
     
     
  • 5.33, Аноним (-), 20:58, 06/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Какая куча? И что с неё? Потоковый сервер видео вменяемый может подскажешь? Был ерлевидео - стал полностью платным. Всё остальное, вменяемое, только за деньги. И даже там этот вебртц кое-как впиливался. Сейчас не знаю в каком состоянии поддержка в разном серверном софте - несколько лет не слежу. И это за несколько лет существования в качестве "стандарта". Сколько ждать этот срт в софте, пять лет, десять?
     
     
  • 6.50, Аноним (-), 19:51, 08/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >Сколько ждать этот срт в софте, пять лет, десять?

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

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

     
     
  • 7.51, Аноним (-), 10:27, 09/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Отлично. Прямо с завтрашнего рабочего дня начинаю пользоваться. Благородный дон конечно мне поможет с ссылками на открытые серверы потокового вещания видео с поддержкой SRT? Или он так, побалаболить вышел?
     

  • 1.28, Аноним (-), 17:29, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Годнота!
     
  • 1.34, Аноним (-), 23:27, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    перепутать просто с hikvision
     
  • 1.38, XoRe (ok), 12:15, 07/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, чем им RTSP не устроил.
     
     
  • 2.42, t28 (?), 22:44, 07/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > чем им RTSP не устроил

    RTSP — угрёбищная TCP-шная фигня.

     
  • 2.45, Анонимный БСДун (?), 12:05, 08/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    UDP отлично разлетается мультикастами по провайдерским сетям и фактически является основой для современных IPTV-решений.
     
     
  • 3.52, XoRe (ok), 17:52, 15/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > UDP отлично разлетается мультикастами по провайдерским сетям и фактически является основой
    > для современных IPTV-решений.

    Совершенно верно. А они хотят это в OTT.

     

  • 1.44, Анонимный БСДун (?), 11:37, 08/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вообще-то джиттер - это задержка...
     
     
  • 2.46, Demo (??), 12:37, 08/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вообще-то джиттер - это задержка...

    То вы с latency перепутали. А jitter --- это вариация задержки.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру