Не совсем. Webtorrent, насколько я вижу, допилили фичу, которая уже есть в некоторых торрент-клиентах - запрашивать пакеты в порядке воспроизведения и проигрывать их сразу. Технически это как раз ближе к HLS и работает для существующих видео, не для трансляций реального времени. Фильм так посмотреть можно, живую трансляцию хоккейного матча - увы. Но штука, безусловно, полезная для своих задач.
Вопрос цены вопроса, естественно. Пилить такое ради галочки "смотри чего мы умеем" или просто впрок - сомнительное решение. А когда на кону экономия весьма ощутимых денег и экономия эта даже в краткосрочной перспективе отобьет стоимость разработки и сопровождения - совсем другое пальто.
Насчет "отдавать единицы" не соглашусь - исходя из моих экспериментов, бюджетный ноут вполне способен отдавать 3-5 видео потоков без боли и страданий. С аудио все еще вкуснее, естетсвенно.
Идея эта давно витает в воздухе, но из-за узости ниши и высокого порога входа не сильно отсвечивает. И пока opensource-решение не появится - так и останется уделом фанатов и крупняка.
Не думаю, что разница оверхеда транспорта будет сколь либо значима / определяющя. Гораздо большая разница будет из-за того что в HLS гвоздями прибиты h264/mp3, а в WebRTC можно использовать VP8/VP9(если допустимо)/Opus. Например, чтобы предоставить несколько уровней качества, HLS требует отдельно кодировать каждый поток, а в VP можно использовать Simulcast.
Самый быстрый это не обязательно минимальный TTL на последней миле - у разных источников разная накопленная задержка.
Хорошим решением был бы выбор активного соединения из списка имеющихся основываясь на сумме "зарержка источника" + round trip time между источником и получателем. Т.е. * новый пир получает список из 10 источников с минимальной собственной задержкой * к каждому из них клиент устанавливает пассивное соединение и смотрит roundTripTime * лучшая комбинация выбирается активной.
Смотреть TTL до всех-всех источников я бы не стал - для этого нужно установить соединение (хотя бы DataChannel) ко всем источникам, на больших сетках это будет знатно грузить и источники и сигнальный.
Не совсем. Webtorrent, насколько я вижу, допилили фичу, которая уже есть в некоторых торрент-клиентах - запрашивать пакеты в порядке воспроизведения и проигрывать их сразу. Технически это как раз ближе к HLS и работает для существующих видео, не для трансляций реального времени. Фильм так посмотреть можно, живую трансляцию хоккейного матча - увы. Но штука, безусловно, полезная для своих задач.
Вопрос цены вопроса, естественно. Пилить такое ради галочки "смотри чего мы умеем" или просто впрок - сомнительное решение. А когда на кону экономия весьма ощутимых денег и экономия эта даже в краткосрочной перспективе отобьет стоимость разработки и сопровождения - совсем другое пальто.
Насчет "отдавать единицы" не соглашусь - исходя из моих экспериментов, бюджетный ноут вполне способен отдавать 3-5 видео потоков без боли и страданий. С аудио все еще вкуснее, естетсвенно.
Идея эта давно витает в воздухе, но из-за узости ниши и высокого порога входа не сильно отсвечивает. И пока opensource-решение не появится - так и останется уделом фанатов и крупняка.
Не думаю, что разница оверхеда транспорта будет сколь либо значима / определяющя. Гораздо большая разница будет из-за того что в HLS гвоздями прибиты h264/mp3, а в WebRTC можно использовать VP8/VP9(если допустимо)/Opus. Например, чтобы предоставить несколько уровней качества, HLS требует отдельно кодировать каждый поток, а в VP можно использовать Simulcast.
Самый быстрый это не обязательно минимальный TTL на последней миле - у разных источников разная накопленная задержка.
Хорошим решением был бы выбор активного соединения из списка имеющихся основываясь на сумме "зарержка источника" + round trip time между источником и получателем. Т.е.
* новый пир получает список из 10 источников с минимальной собственной задержкой
* к каждому из них клиент устанавливает пассивное соединение и смотрит roundTripTime
* лучшая комбинация выбирается активной.
Смотреть TTL до всех-всех источников я бы не стал - для этого нужно установить соединение (хотя бы DataChannel) ко всем источникам, на больших сетках это будет знатно грузить и источники и сигнальный.