Comments 19
Скажите, а DASH в вашей сфере насколько хорошо себя чувствует? С учетом того, что в плане полноты стандарта по сравнению с DASH, HLS выглядит как дешевая подтирка, очень странно, что все по-прежнему активно цепляются за HLS.
И еще момент: существуют ли свои подходы к ABR? Я так понимаю, что для рилтайм стриминга критерии могут существенно отличаться от таковых для обычного вещания и тем более от VOD.
DASH — это боль и страдание, особенно в условиях реальной жизни.
Потому и любить его можно только издалека.
Я то же самое могу сказать и про HLS, особенно, если сценарии использования выходят за пределы «проиграть хоть как-то, в бытовых условиях».
А если задавать разные неудобные вопросы, вроде синхронизации разных MPEG2-TS стримов через PCR и поведения, не определенного стандартом, то вообще мрак.
Если говорить про то, как DASH работает, а не про подоплёку его активного продвижения (хейтерство Apple, желание Google сделать себе жизнь проще и т.д.) то
DASH — очень капризен и требует очень высокого качества источника.
Его массовое внедрение бьёт в первую очередь по мелким игрокам у которых не всегда всё хорошо и часто нет возможности привести условия к идеальным.
Вместо тысячи слов посмотрите как самый свежий референс работает.
И попробуйте перемотку.
Если так выглядит референс, то наверно лучше ещё подождать, прежде чем к нему приходить.
Но и с MPEG2 на вход тоже наверное не стоит мириться. 2к17 уже кончается всё-таки.
Или у вас какой-то жёсткий прям сценарий?
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. Для файлов — времени не существует, в плане поступления данных.
Это всё в идеальном мире, т.е. когда кому-то показывают как это всё работает и просят через 3 минуты удалиться, пока не набежал рассинхрон. Вот когда эти цифры начинают расходиться, HLS клиенты выживывают и пару раз квакнув продолжают играть, вернув себе синхронзацию, а DASH клиенты зависают и рассыпаются.
Вы всё таки не забывайте, что HLS — это в каком-то смысле гибрид VOD и Live, т.е. сегменты то скачиваются и при пилообразном трафике говорить о равномерности поступления кадров очень сложно.
Приходит в голову Youtube Live, OK Live кстати у последних с реализацией полный порядок:
неоднократно обычным FFMPEG RTMP энкодером отправлял им поток в течении 3-х часов, они его по DASH в плеер зрителям раздают ( до 39 000 одновременно в пике ) — никаких проблем.
DASH ещё неплохо интегрирован с браузерными DRM.
Они очень удачно совместили проигрывание и упаковку так, что бы упаковка была в mp4, но совместима с DASH для проигрывания просто byte offset.
Чего для live — не следил.
Ой, у меня задержка. Часть 2