Как стать автором
Обновить

Комментарии 19

Спасибо за статью, интересно посмотреть на проблемы коллег с другой стороны. По работе мне приходится сталкиваться с QAM/IP вещанием в сетях кабельного телевидения.

Скажите, а DASH в вашей сфере насколько хорошо себя чувствует? С учетом того, что в плане полноты стандарта по сравнению с DASH, HLS выглядит как дешевая подтирка, очень странно, что все по-прежнему активно цепляются за HLS.

И еще момент: существуют ли свои подходы к ABR? Я так понимаю, что для рилтайм стриминга критерии могут существенно отличаться от таковых для обычного вещания и тем более от VOD.

DASH — это боль и страдание, особенно в условиях реальной жизни.
Потому и любить его можно только издалека.

Подробнее, пожалуйста.

Я то же самое могу сказать и про HLS, особенно, если сценарии использования выходят за пределы «проиграть хоть как-то, в бытовых условиях».

А если задавать разные неудобные вопросы, вроде синхронизации разных MPEG2-TS стримов через PCR и поведения, не определенного стандартом, то вообще мрак.

Если говорить про то, как DASH работает, а не про подоплёку его активного продвижения (хейтерство Apple, желание Google сделать себе жизнь проще и т.д.) то
DASH — очень капризен и требует очень высокого качества источника.


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


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


Но и с MPEG2 на вход тоже наверное не стоит мириться. 2к17 уже кончается всё-таки.
Или у вас какой-то жёсткий прям сценарий?

DASH — типичный пример академического дизайна. Он рассчитан на поток строго из SDI и строго с атомных часов. Т.е. уже банальный стрим с мобильного телефона, пропущенный через RTMP уже не укладывается в прокрустово ложе DASH и MSE.

HLS — практичная штука, оно работает, везде существует и гораздо менее хрупкое.

Про PCR: многим клиентам вообще наплевать на PCR, они его не читают, потому что в аудио и видео потоках идут DTS. Но конечно для олдовых mpegts-пуристов это ересь требующая очистительного костра =)
DASH — типичный пример академического дизайна. Он рассчитан на поток строго из SDI и строго с атомных часов. Т.е. уже банальный стрим с мобильного телефона, пропущенный через RTMP уже не укладывается в прокрустово ложе DASH и MSE.
Вы сейчас говорите про сам стандарт или про его реализации? То что реализации оставляют желать лучшего, это и так понятно. Особенно опен-сорсные. Именно потому что, как правило, кладут на половину спецификации и «забивают на PCR». В итоге имеем, что имеем.

Про PCR: многим клиентам вообще наплевать на PCR, они его не читают, потому что в аудио и видео потоках идут DTS. Но конечно для олдовых mpegts-пуристов это ересь требующая очистительного костра

И это очень печально. Потому что PTS/DTS и PCR это фундаментально разные вещи. То что декодер можно завести только на PTS не означает, что PCR не нужен. Но вы, как специалист, это и так должны понимать.

А потом возникает ситуация, что «у меня все сутками работало на тестах», а как только код попадает в поле, да еще на миллионы устройств — приехали. Особенно это критично для транскодеров, стоящих, как правило, в аппаратной кабельного оператора и работающих годами.
я и про стандарт, и про реализации. Они друг друга стоят и в отличие от закрытых, опенсорсные хоть как-то можно допилить и подправить. Закрытые лучше не трогать вообще, они рассчитаны строго на один единственный сценарий использования с единственным бекендом и набором контента.

Про PCR я ваших страданий не понимаю. DTS/PTS в потоках достаточно что бы без проблем показывать связное аудио и видео. PCR нужен для игрищ вида: а давайте здесь пихнем левый DTS или не пихнем его вообще.
DASH — типичный пример академического дизайна. Он рассчитан на поток строго из SDI и строго с атомных часов. Т.е. уже банальный стрим с мобильного телефона, пропущенный через RTMP уже не укладывается в прокрустово ложе DASH и MSE.
На 100% согласен.
HLS — практичная штука, оно работает, везде существует и гораздо менее хрупкое.
Ну вот, те же яйца, только с другого ракурса. Удобство только в том, что Apple жестко диктует что и как. DASH, по сравнению с HLS, намного более «обтекаем»: контейнер не описан, кодек не описан, движок на стороне браузера — тоже (MSE лишь частный случай) и т.д. В общем, делайте что хотите и как хотите.
Про PCR: многим клиентам вообще наплевать на PCR, они его не читают, потому что в аудио и видео потоках идут DTS. Но конечно для олдовых mpegts-пуристов это ересь требующая очистительного костра.
Тут вы загнули. PCR — это синхронизация часов источника и приемника, а DTS/PTS это синхронизация медиапотоков между собой. Короче, PCR вообще нужен только при real-time вещании. Cвязи ненужности одного при наличии другого я, например, не уловил.
Короче, PCR вообще нужен только при real-time вещании.
Поправлю. Он нужен во всех случаях, когда у вас на руках в каждый момент времени есть только фрагмент стрима. Даже в случае HLS/DASH, хотя вроде бы «все должно быть нормально, ибо есть большой запас в несколько сегментов и ~30 секунд». Именно из-за clock drift-а, который упорно не хочет понимать топикстартер, декодоер рано или поздно упрется в одну из границ буфера и привет лаги/дропы. А потом начинают говорить, что стандарт говно. Именно поэтому, стандарт MP2 специфицирует допустимый дрифт PCR не более чем на 500 наносекунд.

Резюмируя: когда вам весь TS доступен локально на диске, то PCR не нужен. Когда вы получаете его из кабеля (QAM) или скачиваете из сети по частям (стриминг, VOD и особенно realtime) — нужен. Во втором случае надо использовать PCR pacing в демультиплексоре.
Еще поправка:
Он нужен во всех случаях, когда у вас на руках в каждый момент времени есть только фрагмент стрима.

PCR — это сервис и в общем случае его может не быть в потоке, если это не TS. У меня было куча таких задач. И в любом случае, нужно синхронизовать таймер на приеме так, чтобы он тикал точно как на передающей стороне. Иначе, буфер либо опустошится, либо переполнится. В общем случае (без PCR), это делается по PTS в потоке и по времени прихода семплов физически, хитрым усреднением и разной эвристикой. Все это актуально только если точно известно что поток — live. Для файлов — времени не существует, в плане поступления данных.
Да, разумеется.
В целом получается, что в приличном потоке PCR, DTS (на аудио и видео), а так же fps и sample rate надежно дублируют друг друга. PCR тикает с одной точностью в одном месте потока, DTS на всех пидах тикает с меньшей точностью, но без дрифта от PCR, причем дельта между видеокадрами по DTS строго равна 3600 (для 25 fps), а между аудиокадрами samples/sample_rate (с коэффициентом).

Это всё в идеальном мире, т.е. когда кому-то показывают как это всё работает и просят через 3 минуты удалиться, пока не набежал рассинхрон. Вот когда эти цифры начинают расходиться, HLS клиенты выживывают и пару раз квакнув продолжают играть, вернув себе синхронзацию, а DASH клиенты зависают и рассыпаются.

Вы всё таки не забывайте, что HLS — это в каком-то смысле гибрид VOD и Live, т.е. сегменты то скачиваются и при пилообразном трафике говорить о равномерности поступления кадров очень сложно.
Вот интересно где этот DASH реализован что бы можно было посмотреть-покрутить ?!
Приходит в голову Youtube Live, OK Live кстати у последних с реализацией полный порядок:
неоднократно обычным FFMPEG RTMP энкодером отправлял им поток в течении 3-х часов, они его по DASH в плеер зрителям раздают ( до 39 000 одновременно в пике ) — никаких проблем.
Кстати сегодня увидел в новостях, что OK запускают прямые спортивные трансляции в 4K, раздавать также по DASH планируют…
да, они давно с DASH работают, им нравится.

DASH ещё неплохо интегрирован с браузерными DRM.
А что у ОК в качестве медиа сервера?
они рассказывали, что самописный кусок кода на Java, по крайней мере для VOD.

Они очень удачно совместили проигрывание и упаковку так, что бы упаковка была в mp4, но совместима с DASH для проигрывания просто byte offset.

Чего для live — не следил.
Кстати, не в тему, но все же продолжая тему OK Live…
При трансляции в субботу ( 23 декабря ) матча Реал — Барселона пик одновременных подключений был 2,2 млн. ( многие при этом выбирали 4K качество ) при такой нагрузке сервера раздачи стали сыпаться…
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий