можно и где-то могут даже пользоваться. Можно даже указать на то, что SCTP сразу multihomed и позволяет слать пакеты по разным каналам (что бы было веселее собирать на клиентской части), но пока это не массово, как и сам SCTP. Он есть в webrtc для передачи данных и им пользуются для torrent-like вещания, ошибочно называя это p2p стримингом, но это всё таки про HLS.
да, есть несколько разных рекомендаций. С bbr не сталкивался, есть рекомендации по hybla.
честно говоря, лично я ни разу не видел, что бы у клиента всё было плохо и смена tcp cc всё делала сразу хорошо. Как правило смена OVH на хостинг помогает сразу и радикально.
во-первых, TCP в своей универсальности и проработанности дошел до таких высот, что его очень сложно на что-то заменить и по факту получается просто подождать ещё год пока его будет хватать для очередной задачи.
во-вторых, стриминг видео действительно немного отличается от данных. Тут очень ровные потоки данных: всплесков трафика зачастую не бывает. Во-вторых можно терять данные, выбрасывать их. Из потока текстовых данных обычно выбрасывать ничего не хочется.
да, такая система работает у нас в серверной мозаике в видеофиксации судебных заседаний. Получилось обеспечить синхронизацию губ на соседних IP камерах.
Надо ставить метки абсолютного времени на кадры (UTC), но это очень сложно сделать, потому что IP камера не может сообщить, когда был снят кадр, можно лишь узнать, когда он был получен в сжатом виде, т.е. надо мерять ту самую задержку в энкодере.
ох. Вот прям сейчас у нас в списке задач висит помощь людям со стримингом по RTSP файлов вида anny.celebrate.18.320p.mp4 для каких-то древних телефонов, которых в европе бешеное количество
честно говоря, лично я ни разу не видел, что бы у клиента всё было плохо и смена tcp cc всё делала сразу хорошо. Как правило смена OVH на хостинг помогает сразу и радикально.
во-вторых, стриминг видео действительно немного отличается от данных. Тут очень ровные потоки данных: всплесков трафика зачастую не бывает. Во-вторых можно терять данные, выбрасывать их. Из потока текстовых данных обычно выбрасывать ничего не хочется.
Надо ставить метки абсолютного времени на кадры (UTC), но это очень сложно сделать, потому что IP камера не может сообщить, когда был снят кадр, можно лишь узнать, когда он был получен в сжатом виде, т.е. надо мерять ту самую задержку в энкодере.
Есть ещё IP камеры (гигантский объём, сравнимый с количеством мобильных телефонов, потенциально в 10, 100 раз больше) и спутники.
Нетфликс с его очень ограниченными задачами лишь часть.
А H264, который дает существенно лучшее качество давно уже умеет каждый утюг.
А вот на приставках и Smart лучше рассчитывать на h265
Просто не надо называть VP* свободными, пожалуйста. Это не более чем маркетинговый ход гугла, направленный на программистов.