| |
| 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 секундные паузы перед показом такого видео - обычное дело. А ведь пользователю не нравится ждать. Поэтому от такого сейчас стараются уходить.
| | |
|
|
| 2.30, Максим Лапшин (?), 19:46, 06/05/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Ютуб использует то, что можно сделать в браузере. В браузере можно флеш (это хорошо и надежно работает), можно попробовать MSE (работает, но ещё хрупко), можно webrtc (будет работать только если не смешивать на кухне мясное и молочное).
SRT — это эксперимент на тему UDP для вещания с мобилки на сервер.
| | |
| |
| |
| 4.41, Аноним (-), 19:50, 07/05/2017 [^] [^^] [^^^] [ответить]
| +/– |
Вы бы узнали с кем общаетесь. Хотя что это я. Можно же посмотреть такое шоу по переписке...
| | |
|
|
|
| |
| 2.47, Csh (?), 14:02, 08/05/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Меньшая чувствительность к дрожанию джиттера и контроль за целостностью потока.
| | |
|
| 1.3, Андрей (??), 23:49, 05/05/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну зачем же они взяли OpenSSL: она же ещё неопределённое кол-во времени будет страдать своей особенной лицензией.
| | |
| 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 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Круто, то что нужно, спасибо большое. Я как раз занимаюсь разработкой системы стримминга.
| | |
| 1.17, t28 (?), 10:36, 06/05/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Компании Haivision и Wowza
> клиентской и серверной части SRT написан на языке Си
А как же Java, так любимая программерами из Wowza? 😂
Или это поделка Haivision под франшизой Wowza? Тогда всё понятно.
> SRT реализован поверх UDP
Прогрессируют ребята. Наконец-то догадались, что изпользование CONP
для low latency streaming — есть зло. Ещё где-то лет 10—15 нужно,
чтобы догадались, что UDP контейнер тоже мало пригоден для этих целей. 😄
| | |
| 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.
Вот это по-нашему.
| | |
| |
| |
| |
| 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? Или он так, побалаболить вышел?
| | |
|
|
|
|
|
|
| |
| 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.
| | |
|
|
| |
| 2.46, Demo (??), 12:37, 08/05/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Вообще-то джиттер - это задержка...
То вы с latency перепутали. А jitter --- это вариация задержки.
| | |
|
|
