Jump to content

RTMP поток в Multicast

llaann
 Share

Recommended Posts

llaann

llaann

Posted
Posted

Приветствую всех!

Задача стоит следующая, Есть сервер CentOS 6 там развернут ffmpeg, на нём я принимаю RTMP и хочу отдать его например на udp://@224.0.42.1:10191, его должен принять Chameleon WISI по multicast. Но что-то не получается. Между сервером и WISI есть ещё DGS-3627. Может кто подскажет как организовать стримминг, хотябы ткуть носом в нормальную документацию.

Спасибо.

llaann

llaann

Posted
  • Author
Posted

Запускаю так: 

ffmpeg -fflags genpts  -i rtmp://195.20.196.69:1935/tugantel/tugantel  -f mpegts -re  udp://@224.0.42.1:10191

Выводит следующее:

ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers
 built on Jun  7 2013 18:31:22 with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-3)
 configuration: --enable-version3 --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvpx --enable-libfaac --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libvo-aacenc --enable-libxvid --disable-ffplay --enable-shared --enable-gpl --enable-postproc --enable-nonfree --enable-avfilter --enable-pthreads --extra-cflags=-fPIC --arch=x86_64
 libavutil      52. 18.100 / 52. 18.100
 libavcodec     54. 92.100 / 54. 92.100
 libavformat    54. 63.104 / 54. 63.104
 libavdevice    54.  3.103 / 54.  3.103
 libavfilter     3. 42.103 /  3. 42.103
 libswscale      2.  2.100 /  2.  2.100
 libswresample   0. 17.102 /  0. 17.102
 libpostproc    52.  2.100 / 52.  2.100
[flv @ 0xb26040] Estimating duration from bitrate, this may be inaccurate
Input #0, flv, from 'rtmp://195.20.196.69:1935/tugantel/tugantel':
 Metadata:
   author          : 
   copyright       : 
   description     : 
   keywords        : 
   rating          : 
   title           : 
   presetname      : Custom
   creationdate    : Thu Jun 20 16:30:44 2013
                   : 
   videodevice     : AVerMedia BDA Analog Capture
   avclevel        : 31
   avcprofile      : 66
   videokeyframe_frequency: 5
   audiodevice     : ?8=. 2E>4 (Realtek High Definit
   audiochannels   : 1
   audioinputvolume: 75
 Duration: N/A, start: 0.000000, bitrate: 1601 kb/s
   Stream #0:0: Video: h264 (Baseline), yuv420p, 720x576 [sAR 1:1 DAR 5:4], 1536 kb/s, 25 tbr, 1k tbn, 50 tbc
   Stream #0:1: Audio: mp3, 44100 Hz, mono, s16p, 65 kb/s
Output #0, mpegts, to 'udp://@224.0.42.1:10191':
 Metadata:
   author          : 
   copyright       : 
   description     : 
   keywords        : 
   rating          : 
   title           : 
   presetname      : Custom
   creationdate    : Thu Jun 20 16:30:44 2013
                   : 
   videodevice     : AVerMedia BDA Analog Capture
   avclevel        : 31
   avcprofile      : 66
   videokeyframe_frequency: 5
   audiodevice     : ?8=. 2E>4 (Realtek High Definit
   audiochannels   : 1
   audioinputvolume: 75
   encoder         : Lavf54.63.104
   Stream #0:0: Video: mpeg2video, yuv420p, 720x576 [sAR 1:1 DAR 5:4], q=2-31, 200 kb/s, 90k tbn, 25 tbc
   Stream #0:1: Audio: mp2, 44100 Hz, mono, s16, 128 kb/s
Stream mapping:
 Stream #0:0 -> #0:0 (h264 -> mpeg2video)
 Stream #0:1 -> #0:1 (mp3 -> mp2)
Press [q] to stop, [?] for help
frame=  666 fps= 28 q=31.0 Lsize=    3217kB time=00:00:26.65 bitrate= 988.6kbits/s dup=1 drop=60

Что ещё необходимо предоставить?

srg555

srg555

Posted
Posted

tcpdump -i <интерфейс_выхода_мультикаста> "net 224.0.0.0/4" -c 20 -n -nn

 

Куда должен литься мультикаст?(на какой интерфейс) и покажите ip ro li. Возможно, нужно указать куда лить мультик путём ip ro add 224.0.0.0/4 dev ethX

llaann

llaann

Posted
  • Author
Posted

tcpdump -i <интерфейс_выхода_мультикаста> "net 224.0.0.0/4" -c 20 -n -nn

 

Куда должен литься мультикаст?(на какой интерфейс) и покажите ip ro li. Возможно, нужно указать куда лить мультик путём ip ro add 224.0.0.0/4 dev ethX

tcpdump на самом сервере показывает:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth7, link-type EN10MB (Ethernet), capture size 65535 bytes

17:17:51.120510 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 1472

17:17:51.120523 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 1472

17:17:51.120530 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 64

17:17:51.120546 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 1472

17:17:51.120550 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 32

17:17:51.122878 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 1472

17:17:51.122896 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 32

17:17:51.125270 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 1472

17:17:51.125282 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 784

17:17:51.186062 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 1472

17:17:51.186075 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 220

17:17:51.188234 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 1472

17:17:51.188246 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 1472

17:17:51.188254 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 64

17:17:51.188263 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 1472

17:17:51.188274 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 784

17:17:51.190501 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 1472

17:17:51.190507 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 220

17:17:51.192208 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 1472

17:17:51.192215 IP 192.168.1.201.58550 > 224.0.42.1.10191: UDP, length 408

20 packets captured

44 packets received by filter

0 packets dropped by kernel

ip ro li даёт следующее, сервер ещё является NAT'ом:

213.189.240.108/30 dev eth8 proto kernel scope link src 213.189.240.110

79.104.34.116/30 dev eth6 proto kernel scope link src 79.104.34.118

193.104.64.0/24 via 192.168.1.201 dev eth7

171.25.177.0/24 via 192.168.1.201 dev eth7

192.168.1.0/24 dev eth7 proto kernel scope link src 192.168.1.201

192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.201

172.25.0.0/24 dev eth7 proto kernel scope link src 172.25.0.3

172.24.0.0/16 via 192.168.1.1 dev eth7

172.24.0.0/16 dev eth7 proto kernel scope link src 172.24.0.3

172.25.0.0/16 via 192.168.1.1 dev eth7

172.16.0.0/16 via 192.168.1.1 dev eth7

172.16.0.0/16 dev eth7 proto kernel scope link src 172.16.0.3

169.254.0.0/16 dev eth7 scope link metric 1003

169.254.0.0/16 dev eth6 scope link metric 1004

169.254.0.0/16 dev eth8 scope link metric 1005

169.254.0.0/16 dev br0 scope link metric 1011

blackhole 192.168.0.0/16 proto zebra

10.0.0.0/8 via 192.168.1.1 dev eth7

224.0.0.0/4 dev eth7 scope link

default via 79.104.34.117 dev eth6

Маршрут вроде бы есть, в iptables следующее добавил:

в цепочке

*filter

:FORWARD ACCEPT [0:0]

:INPUT ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

#################

-A FORWARD -p igmp -i eth6 -o eth7 -j ACCEPT

-A INPUT -d 224.0.0.0/4 -j ACCEPT

-A FORWARD -d 224.0.0.0/4 -j ACCEPT

#################

в цепочке

*mangle

:FORWARD ACCEPT [0:0]

:INPUT ACCEPT [0:0]

:PREROUTING ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

:POSTROUTING ACCEPT [0:0]

############################

-A PREROUTING -d 224.0.0.0/240.0.0.0 -p udp -j TTL --ttl-inc 1

############################

Мультикаст должен литься через eth7. Возможно на DGS-3627 надо что-то допилить?

vitalyb

vitalyb

Posted
Posted (edited)

У ffmpeg ts udp выход неправильный - без группировки по mpeg пакетам - просто дует в сокет сколько влезет и в результате оборудование, ожидающие увидеть в одном udp пакете 7 аккуратно уложенных mpeg-ts ничего кроме мусора не видит.

Edited by vitalyb
vitalyb

vitalyb

Posted
Posted

llaann

нашел костыль, который я когда-то использовал (от какой версии не знаю):

--- udp.c.orig	2012-09-28 04:37:35.000000000 +0300
+++ udp.c	2012-11-02 15:03:11.000000000 +0200
@@ -795,6 +795,11 @@
            return ret;
    }

+    if (size < 188)
+	return 0;
+    if (size > 188*7)
+	size = 188*7;
+
    if (!s->is_connected) {
        ret = sendto (s->udp_fd, buf, size, 0,
                      (struct sockaddr *) &s->dest_addr,

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

 

Или использовать другое ПО.

srg555

srg555

Posted
Posted

llaann

Multicast из сервера дует. Теперь ищите его у клиента также тспдампом или ваершарком. Если проблема в самих данных, то попробуйте другим софтом, например vlc

llaann

llaann

Posted
  • Author
Posted

llaann

Multicast из сервера дует. Теперь ищите его у клиента также тспдампом или ваершарком. Если проблема в самих данных, то попробуйте другим софтом, например vlc

Запускаю так:

vlc rtmp://195.20.196.69:1935/tugantel/tugantel --sout '#std{access=udp,dst=224.0.42.2:10191,ttl=10}' -vvv

Усебя в wireshark'е вижу что поток пошёл. На клиенте ничего не получаю. Пытаюсь у себя принять, также пусто. Может что-то не так делаю.

srg555

srg555

Posted
Posted

llaann

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

llaann

llaann

Posted
  • Author
Posted (edited)

Вобщем решил проблему передачей в Unicast, вроде завелось. Теперь другая возникла проблема vlc кричит следующее, на клиенте появляются тормоза, рассыпание картинки, и через некоторое время вообще всё тормозит и vlc отключается:

 

[0x7f711c0044b8] access_output_udp access out debug: late packet for UDP input (1039737)

[0x7f711c0044b8] access_output_udp access out debug: late packet for UDP input (1009815)

[0x7f711c0044b8] access_output_udp access out debug: late packet for UDP input (979342)

[0x7f711c0044b8] access_output_udp access out debug: late packet for UDP input (948868)

[0x7f711c0044b8] access_output_udp access out debug: late packet for UDP input (918394)

[0x7f711c0044b8] access_output_udp access out debug: packet has been sent too late (1039767)

[0x7f711c0044b8] access_output_udp access out debug: late packet for UDP input (887919)

[0x7f711c0044b8] access_output_udp access out debug: late packet for UDP input (857474)

[0x7f711c0044b8] access_output_udp access out debug: packet has been sent too late (1009893)

[0x7f711c0044b8] access_output_udp access out debug: packet has been sent too late (979437)

[0x7f711c0044b8] access_output_udp access out debug: packet has been sent too late (948993)

[0x7f711c0044b8] access_output_udp access out debug: packet has been sent too late (918537)

[0x7f711c0044b8] access_output_udp access out debug: packet has been sent too late (888090)

[0x7f711c0044b8] access_output_udp access out debug: packet has been sent too late (857634)

[0x7f711c005ca8] main mux warning: late buffer for mux input (1372906)

[0x7f711c005ca8] main mux warning: late buffer for mux input (1335700)

[0x7f711c005ca8] main mux warning: late buffer for mux input (1297660)

[0x7f711c005ca8] main mux warning: late buffer for mux input (1261529)

[0x7f711c005ca8] main mux warning: late buffer for mux input (1223494)

 

Запускаю так:

cvlc /mnt/lv2/03.mkv --sout '#transcode{vcodec=h264,vb=0,scale=0,width=640,height=480,acodec=mpga,ab=256,channels=2,samplerate=44100}:std{access=udp{ttl=1},mux=ts,dst=192.168.1.222:10192}' -vvv
Edited by llaann
vitalyb

vitalyb

Posted
Posted

Можно попробовать у vlc какой-нибудь буфер для кеша увеличить.

 

И еще, хамелеону в ряде случаев с UDP жизненно необходим IP поток с постоянным битрейтом, на счет RTP не знаю.

llaann

llaann

Posted
  • Author
Posted

Можно попробовать у vlc какой-нибудь буфер для кеша увеличить.

 

И еще, хамелеону в ряде случаев с UDP жизненно необходим IP поток с постоянным битрейтом, на счет RTP не знаю.

А какой именно буфер? Про битрейт это vb=сколько-то?

  • 9 months later...
vurd

vurd

Posted
Posted

в erlyvideo это вроде нормально сделано

 

Что-то оно не особо работает.

 

При простейшем конфиге стопы по 6 секунд.

13:04:14.027724 IP 127.0.0.1.51973 > 127.0.0.1.5000: UDP, length 1316
13:04:14.027733 IP 127.0.0.1.51973 > 127.0.0.1.5000: UDP, length 1316
13:04:14.027749 IP 127.0.0.1.51973 > 127.0.0.1.5000: UDP, length 1316
13:04:14.027758 IP 127.0.0.1.51973 > 127.0.0.1.5000: UDP, length 1316
13:04:14.027766 IP 127.0.0.1.51973 > 127.0.0.1.5000: UDP, length 188
13:04:20.130441 IP 127.0.0.1.50831 > 127.0.0.1.5000: UDP, length 1316
13:04:20.130470 IP 127.0.0.1.50831 > 127.0.0.1.5000: UDP, length 1316
13:04:20.130484 IP 127.0.0.1.50831 > 127.0.0.1.5000: UDP, length 1316
13:04:20.130494 IP 127.0.0.1.50831 > 127.0.0.1.5000: UDP, length 1316
13:04:20.130504 IP 127.0.0.1.50831 > 127.0.0.1.5000: UDP, length 1316

 

2All Может быть есть какое-то решение для организации стриминга rtmp to multicast udp?

  • 6 months later...
crossassembler

crossassembler

Posted
Posted

2All Может быть есть какое-то решение для организации стриминга rtmp to multicast udp?

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

  • 1 year later...
safit

safit

Posted
Posted

Приветствую всех! Столкнулся с проблемой описанной в топике. Прошерстил весь интернет, очень мало информации по сприванию ffmpeg и vlc с wisi chameleon.

Может кто-нибудь все же решил эту проблему? Отзовитесь?

 

Пробовал уже кучу вариаций vlc и ffmpeg. Стиримил и файлы через udp(rtp) multicast(unicast), и потоки (включая рестрим потока сделанного самой wisi из dvb-c).

У ffmpeg понял, что проблема с битрейтом, не может он делать потоки с CBR, у него все-равно получаются VBR. А поскольку vlc использует тот же ffmpeg, то и у него тоже нет CBR. В общем, подскажите, если кто владеет, как с сервера скормить хамелеону IPTV? (

kosorezik

kosorezik

Posted
Posted

Приветствую всех! Столкнулся с проблемой описанной в топике. Прошерстил весь интернет, очень мало информации по сприванию ffmpeg и vlc с wisi chameleon.

Может кто-нибудь все же решил эту проблему? Отзовитесь?

 

Пробовал уже кучу вариаций vlc и ffmpeg. Стиримил и файлы через udp(rtp) multicast(unicast), и потоки (включая рестрим потока сделанного самой wisi из dvb-c).

У ffmpeg понял, что проблема с битрейтом, не может он делать потоки с CBR, у него все-равно получаются VBR. А поскольку vlc использует тот же ffmpeg, то и у него тоже нет CBR. В общем, подскажите, если кто владеет, как с сервера скормить хамелеону IPTV? (

Попробуйте VLC

pcr=10,shaping=1000,use-key-frames,dts-delay=500

 

pcr="PCR interval in ms" allows to set at which interval Program Clock References will be sent

 

shaping="shaping delay in ms" to set the minimum interval during which the bitrate of the stream will remain constant, for variable bitrate streams

 

use-key-frames uses I frames as limits for the shaping intervals

 

и обновитесь до последней версии там есть буфер по входу на Хамелионе - регулируемый

ShumBor

ShumBor

Posted
Posted

а если попробовать RTMP -> ffmpeg -> loopback , loopback -> astra -> output

Правда это увеличит задержку (зависит от буфера в астре), но я так пересобирал hls

в астре input = {"udp://226.1.1.2:1234#no_analyze"}, output = {"udp://224.1.1.211:1234#sync=3&cbr=2"}

в ffmpeg выход был -tune zerolatency -f mpegts udp://226.1.1.2:1234?pkt_size=1316

С таким конфигом у меня была задержка около 6-7 секунд

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.