Pull to refresh

Comments 33

Переключаясь по вкладкам, и увидев заголовок, долго не мог осознать на том ли я ресурсе нахожусь

Кликбейт такой кликбейт.

Насчёт предложения переписать tcp и о том, что это долго. Так подумать, а в сфере протоколов низкого уровня ничего и не менялось десятилетие, большой срок для ИТ. Это потому что найден золотой ключ, ничего не нужно улучшать? Или все же (как для стриминга) потребность есть но дорого, долго и никто из крупных корпораций не подписался на это?

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

во-вторых, стриминг видео действительно немного отличается от данных. Тут очень ровные потоки данных: всплесков трафика зачастую не бывает. Во-вторых можно терять данные, выбрасывать их. Из потока текстовых данных обычно выбрасывать ничего не хочется.
да, есть несколько разных рекомендаций. С bbr не сталкивался, есть рекомендации по hybla.

честно говоря, лично я ни разу не видел, что бы у клиента всё было плохо и смена tcp cc всё делала сразу хорошо. Как правило смена OVH на хостинг помогает сразу и радикально.
А что не так с OVH? Стоят железные сервера, всё ништяк. Кроме тех случаев, когда у них с сетью что-то, но это редко бывает.
очень любят реселлить сеть, продавая 10 гигабит по 100 баксов. а наши клиенты это любят брать и хотят верить в чудеса и сказки.
UFO just landed and posted this here
Чисто теоретический вопрос — SCTP нельзя использовать в качестве транспорта? Он как раз про надежность и про ровные потоки данных, в тяжелых телекомах он весьма популярен. Хотя я не уверен, что он проедет через public internet, где-то едет, где-то — нет.
можно и где-то могут даже пользоваться. Можно даже указать на то, что SCTP сразу multihomed и позволяет слать пакеты по разным каналам (что бы было веселее собирать на клиентской части), но пока это не массово, как и сам SCTP. Он есть в webrtc для передачи данных и им пользуются для torrent-like вещания, ошибочно называя это p2p стримингом, но это всё таки про HLS.
А на всякие варианты по-верх UDP не смотрели (enet)?
классическая схема с доставкой по UDP выглядит так: рассылающий сервер хранит у себя последние N пакетов. Принимающий клиент держит буфер и если в буфере оказываются дырки (все пакеты нумерованные), то он шлет серверу команду: перепошли мне пакет.

Основная рассылка при этом вообще может делаться мультикастом и тогда можно обслуживать огромное количество абонентов без потерь и с низкими затратами.

Но что-то такая схема не особо пошла.
Как было сказано на одной из конференций: «Представьте что вам нужно транспортное средство, которое одновременно будет ездить по асфальту, луне, пустыне и болоту, оно будет ездить, но везде плохо, например по скорости проиграет обычному автомобилю на асфальте» Так и TCP он должен работать в ДЦ c 40G каналами и через спутник, где высокое Latency, поэтому он такой какой есть, его улучшают, но придумать что-то такое же универсальное, очень тяжело.
да вот как-то получилось, что сравнение то так себе: TCP в целом везде неплох и его очень сложно поменять на что-то другое.

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

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

Надо ставить метки абсолютного времени на кадры (UTC), но это очень сложно сделать, потому что IP камера не может сообщить, когда был снят кадр, можно лишь узнать, когда он был получен в сжатом виде, т.е. надо мерять ту самую задержку в энкодере.
В мире беспилотников ( любительских) в FPV сегменте, до сих пор нет хорошей связки цифрового видео тракта и передачи видео картинки в очки (с минимальной задержкой < 50 мс). Обычно это либо HD картинка максимум, но большая задержка, либо намного хуже качество и аналоговая, но с минимум задержки, либо рвется связь видео потока. Исключение DJI продукция. Хотелось бы узнать, как с высоты вашего опыта можно было бы реализовать ( и на каких решениях, протоколах, кодеках) передачу FullHD ( или выше) с носителя, где видео тракт, скажем, максимум по весу = 500 грамм с камерой на борту, мог бы передаваться по усиленному каналу WIFI ( 500 метров и больше), для трансляции в FPV шлем full hd цифрой. Очень насущная проблема. И да, очень важна минимальная задержка ( идеал <25 мс).
я бы думал в таком направлении: писать оригинальное качество на флешку, а слать возможно плавающее качество. Транспортом выбрать UDP, возможно FEC. И поглубже поковыряться в wifi: там есть свои задержки, лаги и ретрансмиты.
Первое выкинуть wi-fi. Дальше осовыные зедержки это на приеме кадра и запихивание его в SoC для сжатия. И еще надо учитывать fps матрицы. Например если у нас 30 фпс то мы не можем сделать задержку меньше 33мс просто физически(SoC который может обрабатывать на сжатие не полный кадр мне ни разу не попадался). Соответственно нам нужно матрица минимум 60 фпс а лучше 120. И потом мы просто отбрасываем лишние кадры.
Тоесть для FPV больше критична матрица и SoC которые умеет быстро сжимать и который умеет отдвать нарезанные кадры с енкодера.
Плавающее качество мне кажется плохим решением из-за радиоканала.
Ну для fpv используется свой радиоканал с односторонним передатчиком и приемником.
аналоговый fullhd видеолинк типа AHD в камерах? Может всё таки есть какая-то разумная цифра?
Нет цифра. Например можно взять что-то типа dvb-t просто уйти по частотам и просто формируем mpegts. Например у нас на очень старом SoC который только-только тянет fullhd, и модульной камере от панасонике на обычном HD при передаче на комп и софтовом декодировании получается 250мс.
Из готового есть разнообразные цифровые радиомодули до 2Мбит (знаю что мало — да и в реальных условиях будет еще хуже) или можно делать свое, взяв за основу какой-нибудь SDR вроде HackRF — благо, вся математика уже написана. Кстати, dvb-t вроде какие-то любители уже запускали, но там вопрос про задержки не стоял. В любом случае, довести до ума это будет сложно — DJI не зря за свои игрушки столько денег хочет
речь ведь о «локальном» стриминге, тут можно посмотреть на протокол/либу NDI. Использует «слабое» сжатие (FullHD ~100Mbs) поскольку рассчитан на гигабитную сеть и минимальную задержку, легко прикручивается. Если у Вас айфон и вайфай (5гц) то можете протестить на нашем JustWifiCam (аппстор). Вот один из юзкейсов использования.
image
У вас будет задержка явно несопостовимая для FPV. Меньше 100мс на обычных смартфонах можно и не мечтать.
речь об использованиях смартфона для FPV и не шла. речь о протоколе NDI который можно попробовать использовать для FPV.
Ага а канал где вы такой возьмете? Знаете 100мб/с с коптера это очень круто. И если хардварный энкодинг h264 есть то вот зачем нужен какойто левый формат и софтовое сжатие?
Сжимать в h264 можно быстро особенно если аппаратно делать(а только так и надо)
А у вас нет таблицы типа протокол/size/Cpu/latency?

Из собственных экспериментов могу сказать, что самый быстрый протокол из тех, что я сумел настроить и использовать это WebRTC.
webrtc стандартный для новых браузеров и по udp, поэтому у него не будет (не должно быть) плавающей задержки.
Немного странная логика: если что то используется для новых браузеров и по UDP, то у него нет задержки.
UDP выбран за то, что у него не возникает плавающей сетевой задержки. Она ожидается достаточно стабильной в районе времени пинга (половины, понятно).
Only those users with full accounts are able to leave comments. Log in, please.