RTP для передачи мультикаст

[fox_m]

Последнее время заметил, что операторы стали все чаще использовать RTP over UDP для передачи мультикаста. Какие преимущества дает RTP перед "чистым" UDP?

[LostSoul]

вроде бы можно добавить избыточное кодирование из коробки, только это никто не делает.

реально какую библиотеку готовую прицепить было в софте проще,такую и прицепили

 

[Butch3r]

RTP имеет последовательность пакетов, UDP нет.

[fox_m]

11 минут назад, LostSoul сказал:

вроде бы можно добавить избыточное кодирование из коробки, только это никто не делает.

реально какую библиотеку готовую прицепить было в софте проще,такую и прицепили

 

А в теории, переход на RTP может повысить качество мультика? Или опять же от железа зависит (энкодеров)?

[paradox_]

без теории известно

что если навесить на каждый маршрутизатор амулет

то он не только пакеты перестает терять

но еще и денег по концу месяца приносит

[Sergey R.]

С RTP можно собирать довольно красивые схемки. Как уже сказали выше, пакеты пронумерованы, а это дает следующие преимущества:

Можно видеть, сколько именно пакетов потерялось в потоке, и потерялось ли вообще, возможно пакеты просто перепутались местами.

Также можно пускать один и тот же поток двумя, тремя.. путями и в точки приёма собирать один поток без потерь. Дубликаты будут отбрасываться.

В общем если хочется сделать красиво, и улучшить качество сервиса то лучше юзать RTP.

С UDP всегда будет тяп ляп, даже если юзать железки для резервирования типа DCM9902, то если один канал грохнется, на второй переключение произойдет но ошибок не избежать.

 

На практике делал не маленький проект и всё было сделано на UDP.

Потом было сильно обидно но уже поздно что-то менять) 

Edited April 26, 2019 by Sergey R.

[paradox_]

в mpegts есть все тоже самое что есть в rtp

так что ничего кроме оверхеда к mpegts - rtp не дает

[Sergey R.]

Не согласен, в mpegts есть счётчик который обнуляется.

Ну вижу я сс еррор, это значит счётчик сбился.

А почему? Пакеты местами поменялись? Потерялись? А сколько их потерялось?

Какая железка имея на входе два потока в голом udp/mpegts сможет бесшовно прыгнуть с потока на поток? У кого есть DCM попробуйте)

[paradox_]

вам в секту тех кто верит амулеты(выше картинку дал)

а если на проводной или оптический шнурок повесить подкову которая висела год на стене плача

то данные начинают передаваться по нему, не хуже чем поток с fec

[Sergey R.]

Вот они возможности голого UDP/MPEGTS

Мало информативно всё и нормального бесшовного склеивания не видать.

Вот в моем проекте было безумие когда этот голый UDP гонялся от Парижа до Владивостока.

Ни нормального резервирования не защиты от потерь сделать было не возможно.

Нужно с нуля всё переделывать. Если бы сразу знать всё это...

 

CC errs: The number of times a discontinuity has been detected for all the MPEG-2 Transport Stream continuity counters. This value is the total number of discontinuities detected for all PIDs present. Note that this value does NOT represent the number of MPEG-2 TS packets lost because any continuity counter mismatch detected for an IP-frame will increase CC errs by one. CC errors are serious as they will in practice usually result in visual video artifacts (‘blocking’) if occurring on the video PIDs. CC errors can be due to an erroneous input signal to the streaming head-end (e.g. from satellite rain fading or changes in the uplink). Alternatively, CC errors can arise from IP packets being dropped in the network.

 

 

 

А на самом деле всё от задач зависит. Ест-но пользователям такого нет смысла включать.

Я делал мультикаст для IX. А там без этого ппц вышел.

[Sergey R.]

Так. Еще дополню важный момент. С помощью RTP делается реодеринг. Например, пакеты перепутались местами, в сетях MPLS это не редкость. Так вот если клиентская STB умеет реодеринг, то она соберет пакеты и картинка не рассыпится.

Короче я бы рекомендовал использовать RTP как у магистралов, без RTP им как следует транспорт не организовать: гоню поток из Парижа во Владивосток - по пути куча транзита который лагает. Пускаю потоки одинаковые через несколько транзитов и во Владике склеиваю и получаю идеал.

Для домовых сетей я бы вообще не рекомендовал использовать мультикаст для клиентов) но уж если пришлось то завертывание в RTP упростит диагностику и обеспечит реодеринг. Главное чтобы приставки поддерживали RTP,  вроде вспоминаю у каких-то приставок с этим сложности были.

 

 

[paradox_]

плохо когда инженеры пытаются быть программистами....

реордеринг в rtp такой же как и в mpegts

разницы никакой

можно пофантазировать о том что какой то горе прогер взял готовую rtp либу  в которой по умолчанию на входе есть джиттер

но так можно такой же джиттер поставить и на mpegts, если не криворукий прогер писал мидлваре для приставки 

или плеер, смотря чем играется

и получить тоже самое

 

так что разницы вообще нет и я бы не стал надеяться что в какой то там приставке более умная rtp реализация

 

а так вообщем для инженеров уже есть srt, тесты которого уже делали в теме dvb

все работает как надо на целых mpts потоках а не только на отдельных spts

[Sergey R.]

На mpegts реализовать ничего нельзя из того  что может RTP.

Есть счётчик cc counter в mpegts , который меняется от 0 до 16. Когда он сбоит, как алгоритм должен выглядеть чтобы получить реодеринг?

Он обнуляется в секунду не по одному десятку раз.

Как потоки пустить двумя путями и склеить по счетчику?

SRT да есть. Но на практике какое железо мы будем использовать для него?

И тут речь не о тестах а о продакшн среде) Железки cisco, harmonic и прочее.

И тот же FEC только с RTP работает. И FEC бывает как один поток с избыточностью так и много копий потоков без избыточности которые склеиваются. Всё это на RTP.

 

Кстати если есть идеи и силы то кликай :-D

Рук не хватает катастрофически.

https://hh.ru/vacancy/30810201

 

 

 

 

 

 

 

 

Правильнее сказать не идеи а силы. Всё уже изобретено за нас, осталось реализовать.

[paradox_]

если бы вы имели представление о том как теряются пакеты и о реальном реордеринге

то не говорили бы то вам сс=15 не хватит

вообщем не вам мне рассказывать как работает iptv

 

касательно ссылки это какая то бомжатьня - от 120 000 до 150 000 руб

 

[Sergey R.]

Согласен про бомжатину. Замену мне и ищут. Давно ищут. (но могут найтись люди кто хотят развития)

А так ты прав только в плане SRT.

mpetgs/udp в плане коррекции ошибок может почти нечего. Ничего он не может.

RTP как чуть больший оверхед может куда больше, может всё. Почти всё. Но джиттер этой штукой не компенсируешь.

Идеал что-то вроде SRT, вроде как и джиттер может компенсировать но практик использования нет.

Все на практике испытано. Если ты сам для себя сервис делаешь всё хорошо, тебе нравиться. А если для бизнеса то далеко не уедешь. Рассказывать как работает iptv придется мегафонам билайнам и мтс ам. У которых мониторинг на каждом шагу.  А они за день порвут. Программистов нет, техподдержки нет. Всё-таки сервис узко специализированный, саппорта и инженеры на дороге не валяются. 

 

Но всё же ТС интересовали отличия RTP от голову UDP. Тут всё очевидно. Больше не меньше. Копеечный оверхед на современные каналы не влияет и может решить все проблемы кроме джиттера.

[Sergey R.]

В 25.04.2019 в 11:30, fox_m сказал:

А в теории, переход на RTP может повысить качество мультика? Или опять же от железа зависит (энкодеров)?

Да, именно от железа энкодеров. Или даже от их ПО.

Если энкодер умеет то круто.

Опенсорс тоже это умеет https://code.videolan.org/videolan/multicat можно почитать

 

Нужно смотреть что за задача стоит. Если гоняешь мультик по магистрали по DWDM и прочим каналам (а есть сети которые сейчас без DWDM живут?) то один линк в DWDM флапнул, и еще раз и 10 раз в моменты когда магистралы делают плановые работы. А это в часа три ночи. Если сил много и здоровья много то вперед вставать линк гасить(и найди что гасить если между городами их 10). Даже среднего уровня техподдежрка и среднего(и выше среднего) уровня инженер такого не разрулит.

 

RTP тут на помощь придет.

И в плане клиентов придет, уже и до клиентов смотрю во все районы CWDM/DWDM пошли от разных операторов, один резервирует другого.

 

А на UDP практика есть, вон вакансию кликать не хотят все разбежались)

 

 

[Ivan_83]

В 25.04.2019 в 11:28, Butch3r сказал:

RTP имеет последовательность пакетов, UDP нет.

Послеловательность в mpeg2-ts есть.

 

 

10 часов назад, Sergey R. сказал:

Можно видеть, сколько именно пакетов потерялось в потоке, и потерялось ли вообще, возможно пакеты просто перепутались местами.

Также можно пускать один и тот же поток двумя, тремя.. путями и в точки приёма собирать один поток без потерь. Дубликаты будут отбрасываться.

В общем если хочется сделать красиво, и улучшить качество сервиса то лучше юзать RTP.

 

5 часов назад, Sergey R. сказал:

С помощью RTP делается реодеринг. Например, пакеты перепутались местами, в сетях MPLS это не редкость. Так вот если клиентская STB умеет реодеринг, то она соберет пакеты и картинка не рассыпится.

 

4 часа назад, Sergey R. сказал:

Есть счётчик cc counter в mpegts , который меняется от 0 до 16. Когда он сбоит, как алгоритм должен выглядеть чтобы получить реодеринг?

Он обнуляется в секунду не по одному десятку раз.

Как потоки пустить двумя путями и склеить по счетчику?

RTP - фап-фап-фап.

Ты сам лично видел софт который умеет и делает реаордеринг на rtp?

Если нужно что то гарантировать есть tcp, который из коробки умеют практически все, даже всякие кофеварки с диплеем.

 

4 часа назад, Sergey R. сказал:

https://hh.ru/vacancy/30810201

Ко мне с таким уже приставали какие то хрюки, но я считаю что инженегром-эксплуатантом бесперспективно вообще :)

[Sergey R.]

Иван, про софт, да видел и юзал. Точнее не совсем софт а cisco dcm9902 и ресиверы гармоник.

И вот эта штучка думаю тебе знакомая умеет разбивать на две копии и склеивать наверняка с реодером. https://code.videolan.org/videolan/multicat Но её не юзал.

 

В mpeg-ts последовательность ввиде счётчика, если я не прав поправь. Склеивать и делать реодеринг по счётчику который обнуляется по 100 раз за секунду есть безумие.

 

С tcp тоже верно,  я  пол года назад  оставил тех что к тебе приставали) и спокойно теперь раздаю тв по HLS либо http. Проблем меньше.

 

Но в условиях что у меня были просто без вариантов. Здоровая сеть ты представь. Там и STP  и MPLS и LACP  на всём этом резервирование поднято, на перестроение время нужно.

И там выход только пускать несколькими путями и склеивать.

TCP там тоже не поплодишь, потоков тысяча. 

RTP очень хорошо себя в этом плане показало.

Но на то, чтобы всё там переделать нужна сильная мотивация которую обеспечить не могут, потому я оставил это дело.

 

[Sergey R.]

+ еще интересная практика дебага.

На канале Хабаровск-Владивосток у меня были CC errors. Владельцы каналы не могли найти причину, дотошно спрашивали подробности чем вызваны CC.

Вот навешивал на тестовые стримы RTP, прогонял их и расписывал что происходит. Думали сперва что потери а нет, через mpls кольцо у них там пакетики иногда разными путями летали и давали CC. 

RTP выручил.

Ест-но после этого не фига там ничего не починили, потом к реодеру еще прибавились обрывы связи на минут 5ть а там и tcp не спасет.

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

 

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

[Sergey R.]

А ну и еще забыл важный момент) RTP и дупликаты детектирует. Почитал про то что мониторинг детектирует.

Короче для глубокого копания без RTP далеко не уедешь и по уму лучше сразу навешивать этот копеечный оверхед.

 

RTP packet drop:

Number of consecutive dropped RTP packets exceeds the error- thresholds – only available if RTP headers are present

 

RTP duplicates:

Number of RTP packets with iden- tical RTP counters – only available if RTP headers are present

 

RTP out of order:

There are RTP packets received out of order – only available if RTP headers are present

 

CC skips:

Number of transport stream discon- tinuities due to packet loss. Note that the CC skips number does not necessarily equal the number of lost packets, as several consecutive packets lost will be counted as one CC skip.

 

Во вложении наглядно расписано насколько ущербный голый mpegts в плане диагностики.

Edited April 27, 2019 by Sergey R.

[paradox_]

ему про фому а он про ерёму

вам осталось прочитать стандарт rtp

что бы понять по дефолту, джиттера на ртп не реализовывают

и в случае реордеринга ртп, отставшие пакеты по seq отбрасываются

 

в случае mpegts, сс тоже собьется

 

и в том и в другом случае вы ничего не сделаете

 

и вместо того что бы забивать сеть избыточностью, подстроили мту и размер удп пакетов от источника к приемнику

[Sergey R.]

Не вижу смысла спорить. Был вопрос про rtp, я поделился практикой использования. Буду рад если кто-то также поделиться практикой голово мпегтс. Может тоже есть пути бесшовного склеивания, качественного мониторинга. Названо железо, которое с этим работает. Пока вижу только гон на какой- то оверхед) В мск икс вот я проект гонял там линки есть 64х10г т е по 640гигабит) смешно слушать про оверхед в данном случае. Да и все современные сети сейчас такие. 

[LostSoul]

Тут какой-то холивар уже начался  , но я на всякий случай оставлю это здесь.

Для mpeg-ts для linux есть эффективный модуль ядра, позволяющий подписываться и мониторить  multicast mpegts потоки , собирая статистику cc reorder , drop и прочего.

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

 

[vurd]

2 минуты назад, LostSoul сказал:

Тут какой-то холивар уже начался  , но я на всякий случай оставлю это здесь.

Для mpeg-ts для linux есть эффективный модуль ядра, позволяющий подписываться и мониторить  multicast mpegts потоки , собирая статистику cc reorder , drop и прочего.

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

 

но ссылку и название не скажу?

[LostSoul]

9 минут назад, vurd сказал:

но ссылку и название не скажу?

да почему не скажу-то.   xt_mpeg2ts.ko

 

вот тут он https://github.com/netoptimizer/IPTV-Analyzer/tree/master/iptables-module