Ну, во-первых, с трудом представляется реализация серверов доступа, раздающих чанки hls пакетами mpeg-ts. Не представлю, как вообще можно было насчитать заметный pps при переходе от mpeg-ts к fmp4 чанкам. Раздают-то чанки а не пакеты.
Во вторых, выигрыш от монолитного манифеста mpeg-dash c учетом общего количества обращений к бекенду находится в пределах ошибки измерений. Его плюс вовсе не в монолитности, а в механизме шаблонизации имени чанка, что при соответствующем устройстве плеера позволит загружать чанк, не ожидая изменения манифеста. Похожая логика реализуется в релизациях плееров под HLS с низкой задержкой.
В третьих, константный битрейт в 2018-м году, ну это прям архаика. Вы проигрываете гораздо больше на транскодинге, хранении и картинке, нежели выигрываете в нескольких частных случаях.
Раз уж разговор зашел за битрейт, и, очевидно, про экономию битрейта то четвертых, про B-фреймы: временное расстояние между ними и зависимыми фреймами в рамках остальных задержек остального тракта находятся в рамках 5-10%. Да, понятно, в этом случае возникают дополнительные требования к транспорту. Но это же не повод просто сказать, что вредная и ненужная часть. А так бывает, что транслировать надо не только говорящую голову, отснятую на камеру с кристально чистой картинкой.
В четвертых, часть статьи про udp, коррекцию ошибок и т.п. кране напоминает протокол kcp (https://github.com/xtaci/kcp-go) и даже был какая-то реализация rtmp поверх этого протокола (https://github.com/LiveStudioSolution/joy4)
Осталось только строго обосновать фразу " я переформулирую задачу более корректно." И все будет в порядке. Ну и 4-й параграф про двух мудрецов тоже прекрасен.
Мда. Эта штука не понимает, что типы можно создавать в схемах (хотя, конечно, низкий поклон, что вообще такую сущность еще не забыли). Эта штука как-то очень специфично работает с перегружаемыми процедурами, как бог на душу положит синхронизирует состояние с базами, она вообще не понимает, что под пользователем может быть доступно несколько баз. И это только на вскидку.
Толку от впн-ов, замены днс-ов и прочих доморощенных методов обхода роскомнадзора, если ваши клиенты идут мимо с вашего полуработающего сайта, или не работающего вовсе благодаря сабжу? Смена места жительства тоже не поможет, если клиент российский. Переводите простои в деньги, а деньги в коллективные иски. Способны к самоорганизации, не? Иначе все это не более, чем птичьи песни для роскомнадзора.
Во вторых, выигрыш от монолитного манифеста mpeg-dash c учетом общего количества обращений к бекенду находится в пределах ошибки измерений. Его плюс вовсе не в монолитности, а в механизме шаблонизации имени чанка, что при соответствующем устройстве плеера позволит загружать чанк, не ожидая изменения манифеста. Похожая логика реализуется в релизациях плееров под HLS с низкой задержкой.
В третьих, константный битрейт в 2018-м году, ну это прям архаика. Вы проигрываете гораздо больше на транскодинге, хранении и картинке, нежели выигрываете в нескольких частных случаях.
Раз уж разговор зашел за битрейт, и, очевидно, про экономию битрейта то четвертых, про B-фреймы: временное расстояние между ними и зависимыми фреймами в рамках остальных задержек остального тракта находятся в рамках 5-10%. Да, понятно, в этом случае возникают дополнительные требования к транспорту. Но это же не повод просто сказать, что вредная и ненужная часть. А так бывает, что транслировать надо не только говорящую голову, отснятую на камеру с кристально чистой картинкой.
В четвертых, часть статьи про udp, коррекцию ошибок и т.п. кране напоминает протокол kcp (https://github.com/xtaci/kcp-go) и даже был какая-то реализация rtmp поверх этого протокола (https://github.com/LiveStudioSolution/joy4)