RTP > UDP

[nal]

Встала довольно интересная задача: на лету конвертировать мультикаст приходящий в RTP в такой же мультикаст, лишь в UDP. Внутри у мультикаста будет n-ое кол-во каналов.

Какими железками это возможно сделать? Если нет, то может быть имеется какое-нибудь чисто софтовое решение, будь-то какой VLS?

[Pasha_49]

Я с помощью VLC перегоняю видео с камер(rtsp) в udp multicast.

[nal]

Может тогда подскажите сразу версию постабильнее? Чтобы было не боязно пускать в работу?

[Globus]

А чем вам мешает RTP? Его не понимает STB?

[denis_vid]

Встала довольно интересная задача: на лету конвертировать мультикаст приходящий в RTP в такой же мультикаст, лишь в UDP. Внутри у мультикаста будет n-ое кол-во каналов.

Какими железками это возможно сделать? Если нет, то может быть имеется какое-нибудь чисто софтовое решение, будь-то какой VLS?

Какой смысл транскодировать шило в мыло?

[secandr]

Встала подобная проблема. Конвертируем RTP в UDP на vlc. Периодически отваливается исходящий поток по части каналов. Иногда помогает control stop/play, иногда рестарт vlc, а иногда ничего не помогает :(

 

Какой смысл транскодировать шило в мыло?

 

Источник не наш и переделать его нельзя. Приставки покупались самые дешёвые под UDP-шный поток. Заставить пару сотен пользователей сменить приставку - не вариант. Остаётся только менять шило на мыло...

 

Может быть у кого-то адекватно получилось конвертировать поток?

[secandr]

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

[danilbal]

VLC с периодическим рестартом... даже со скриптами которые его рестартят...

[tipok]

А всего-то нужно вырезать первых 12 байт из каждого RTP-пакета...

[Globus]

А всего-то нужно вырезать первых 12 байт из каждого RTP-пакета...

 

вот-вот! именно вырезать, а не обрабатывать. В чем нелюбовь к RTP?

 

Между тем в этих 12 байтах есть информация, полезная при диагностике сети - точное время выхода пакета из IP-стримера и 16-битный счетчик IP-пакетов (в TS счетик СС всего лишь 4 бита).

[tipok]

Некоторые приставки напрочь отказываются принимать RTP (например DIB-120 4.05.005).

Ну, обычный RTP-это мелочь. Вот как быть, если нужно принять IP-поток, который идёт вместе с Pro-MPEG COP3r2 FEC, вот это уже задачка, причём каждый производитель железа делает свой велосипед (с квадратными колёсами). Вот например патч для VLC: http://degnet.de/~flo/vlc-ulpfec/vlc-ulpfec.patch но у меня FEC - так и не заработало.

[^rage^]

выкиньте vlc, используйте gstreamer.

[^rage^]

выкиньте vlc, используйте gstreamer.

[tipok]

выкиньте vlc, используйте gstreamer.

 

А как вы собираете UDP-пакеты 1316 байт в GStreamer'е? Разобрать RTP-то можно, а вот собрать raw-UDP - тут проблема, так как GStreamer норовит каждый 188-байтный транспортный пакет отправить в своём отдельном UDP-пакете, что не есть хорошо, мне вот пришлось самому выкручиваться и написать плагин.

Edited April 26, 2012 by tipok

[Globus]

Ну, обычный RTP-это мелочь. Вот как быть, если нужно принять IP-поток, который идёт вместе с Pro-MPEG COP3r2 FEC, вот это уже задачка, причём каждый производитель железа делает свой велосипед (с квадратными колёсами). Вот например патч для VLC: http://degnet.de/~flo/vlc-ulpfec/vlc-ulpfec.patch но у меня FEC - так и не заработало.

 

С FEC-ом значительно сложнее. Данные FEC идут в одном или двух дополнительных мультикастах. Их тоже надо принять. Затем обработка FEC - очень ресурсоемкая операция. Многие проф. железки за лицензию на поддержку FEC хотят немалую денюжку. А дополнительно, - и специальные платы IP-входа с более мощным процессором.

 

В случае с RTP все в 1000 раз проще - пропустил первые 12 байт после заголовка IP пакета, а далее работаешь как обычно. Всего-то 2-3 строчки кода.