Now I want to play the IPTV stream which was captured by WireShark and was saved in th pcap file,
Server: I use the "tcpreplay -i eth0 iptv.pcap" to sent the stream on a server computer, Client: and use the command: "gst-launch-0.10 -v gstrtpbin name=rtpbin udpsrc multicast-iface=eth0 multicast-group=225.1.2.2 port=8034 caps="application/x-rtp, \ media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, \ ssrc=(guint)1253787951, payload=(int)33, clock-base=(guint)3847989125, \ seqnum-base=(guint)25200" ! \ rtpbin.recv_rtp_sink_0 rtpbin. ! rtpmp2tdepay ! mpegtsdemux name=d ! queue \ ! 'video/x-h264' ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! queue ! xvimagesink " Result: On the client,when execute the above command,I stop at: Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock But I use VLC on the client ,then can get the server stream and can play it normally.Wheather there is some wrong with my pipeline command? By doing some research,I find the IPTV stream is different from the common stream: 1.I use tcpdump -i eth0 ,and get the follow infor: 09:11:55.138926 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.142901 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.146890 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.150871 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.154911 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.160492 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.164337 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 As the length is 1348,If I play a pcap file(the length is 1316) use the tcpreplay,then I use udpsrc on the client can get the stream and can play it.So wheather the length 1348 is not a common rtp package ,or udpsrc can't deal with the larger then 1348 package? Thanks very much.For this ,I try many ways and many days,but still failed. zhichao. |
On 05/14/2012 04:25 PM, tanzhichaoanuo wrote:
> Now I want to play the IPTV stream which was captured by WireShark and was > saved in th pcap file, > Server: > I use the "tcpreplay -i eth0 iptv.pcap" to sent the stream on a server > computer, > > Client: > and use the command: > "gst-launch-0.10 -v gstrtpbin name=rtpbin udpsrc multicast-iface=eth0 > multicast-group=225.1.2.2 port=8034 caps="application/x-rtp, \ > media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, \ > ssrc=(guint)1253787951, payload=(int)33, clock-base=(guint)3847989125, \ > seqnum-base=(guint)25200" ! \ > rtpbin.recv_rtp_sink_0 rtpbin. ! rtpmp2tdepay ! mpegtsdemux name=d ! queue \ > ! 'video/x-h264' ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! queue ! > xvimagesink > " > > Result: > On the client,when execute the above command,I stop at: > Setting pipeline to PAUSED ... > Pipeline is live and does not need PREROLL ... > Setting pipeline to PLAYING ... > New clock: GstSystemClock > > But I use VLC on the client ,then can get the server stream and can play it > normally.Wheather there is some wrong with my pipeline command? depayloader accepted caps. Wim > > By doing some research,I find the IPTV stream is different from the common > stream: > 1.I use tcpdump -i eth0 ,and get the follow infor: > 09:11:55.138926 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.142901 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.146890 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.150871 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.154911 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.160492 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.164337 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > > As the length is 1348,If I play a pcap file(the length is 1316) use the > tcpreplay,then I use udpsrc on the client can get the stream and can play > it.So wheather the length 1348 is > not a common rtp package ,or udpsrc can't deal with the larger then 1348 > package? > Thanks very much.For this ,I try many ways and many days,but still failed. > zhichao. > > > -- > View this message in context: http://gstreamer-devel.966125.n4.nabble.com/How-to-play-IPTV-streamer-by-udpsrc-tp4632303.html > Sent from the GStreamer-devel mailing list archive at Nabble.com. > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by tanzhichaoanuo
On 05/14/2012 04:25 PM, tanzhichaoanuo wrote:
> Now I want to play the IPTV stream which was captured by WireShark and was > saved in th pcap file, > Server: > I use the "tcpreplay -i eth0 iptv.pcap" to sent the stream on a server > computer, > > Client: > and use the command: > "gst-launch-0.10 -v gstrtpbin name=rtpbin udpsrc multicast-iface=eth0 > multicast-group=225.1.2.2 port=8034 caps="application/x-rtp, \ > media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, \ > ssrc=(guint)1253787951, payload=(int)33, clock-base=(guint)3847989125, \ > seqnum-base=(guint)25200" ! \ > rtpbin.recv_rtp_sink_0 rtpbin. ! rtpmp2tdepay ! mpegtsdemux name=d ! queue \ > ! 'video/x-h264' ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! queue ! > xvimagesink > " directly to the mpeg TS demuxer. Wim > > Result: > On the client,when execute the above command,I stop at: > Setting pipeline to PAUSED ... > Pipeline is live and does not need PREROLL ... > Setting pipeline to PLAYING ... > New clock: GstSystemClock > > But I use VLC on the client ,then can get the server stream and can play it > normally.Wheather there is some wrong with my pipeline command? > > By doing some research,I find the IPTV stream is different from the common > stream: > 1.I use tcpdump -i eth0 ,and get the follow infor: > 09:11:55.138926 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.142901 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.146890 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.150871 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.154911 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.160492 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.164337 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > > As the length is 1348,If I play a pcap file(the length is 1316) use the > tcpreplay,then I use udpsrc on the client can get the stream and can play > it.So wheather the length 1348 is > not a common rtp package ,or udpsrc can't deal with the larger then 1348 > package? > Thanks very much.For this ,I try many ways and many days,but still failed. > zhichao. > > > -- > View this message in context: http://gstreamer-devel.966125.n4.nabble.com/How-to-play-IPTV-streamer-by-udpsrc-tp4632303.html > Sent from the GStreamer-devel mailing list archive at Nabble.com. > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by Wim Taymans
Hallo Wim,
der RTP-Client erwartet einen UDP-String, tcpreplay nutz jedoch tcp. Das kann nicht funktionieren. Nutze als gstreamer element doch tcpclientsrc. Das sollte funktionieren. Auf Serverseite würde ich dann auch tcpserversink verwenden. Server: gst-launch-0.10 filesrc location=iptv.pcap ! tcpserversink port=xxxx Client: gst-launch-0.10 tcpclientsrc host=yyyy port=yyyy ! mpegtsdemux \ name=d ! queue ! 'video/x-h264' ! ffdec_h264 ! ffmpegcolorspace ! \ videoscale ! queue ! xvimagesink Gruß Bernhard -----Ursprüngliche Nachricht----- Von: gstreamer-devel-bounces+bernhard.graaf=[hidden email] [mailto:gstreamer-devel-bounces+bernhard.graaf=[hidden email]] Im Auftrag von Wim Taymans Gesendet: Montag, 14. Mai 2012 17:12 An: [hidden email] Betreff: Re: How to play IPTV streamer by udpsrc? On 05/14/2012 04:25 PM, tanzhichaoanuo wrote: > Now I want to play the IPTV stream which was captured by WireShark and was > saved in th pcap file, > Server: > I use the "tcpreplay -i eth0 iptv.pcap" to sent the stream on a server > computer, > > Client: > and use the command: > "gst-launch-0.10 -v gstrtpbin name=rtpbin udpsrc multicast-iface=eth0 > multicast-group=225.1.2.2 port=8034 caps="application/x-rtp, \ > media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, \ > ssrc=(guint)1253787951, payload=(int)33, clock-base=(guint)3847989125, \ > seqnum-base=(guint)25200" ! \ > rtpbin.recv_rtp_sink_0 rtpbin. ! rtpmp2tdepay ! mpegtsdemux name=d ! queue \ > ! 'video/x-h264' ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! queue ! > xvimagesink > " > > Result: > On the client,when execute the above command,I stop at: > Setting pipeline to PAUSED ... > Pipeline is live and does not need PREROLL ... > Setting pipeline to PLAYING ... > New clock: GstSystemClock > > But I use VLC on the client ,then can get the server stream and can play it > normally.Wheather there is some wrong with my pipeline command? depayloader accepted caps. Wim > > By doing some research,I find the IPTV stream is different from the common > stream: > 1.I use tcpdump -i eth0 ,and get the follow infor: > 09:11:55.138926 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.142901 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.146890 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.150871 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.154911 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.160492 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > 09:11:55.164337 IP 61.181.150.102.12502> 225.1.2.2.8034: UDP, length 1348 > > As the length is 1348,If I play a pcap file(the length is 1316) use the > tcpreplay,then I use udpsrc on the client can get the stream and can play > it.So wheather the length 1348 is > not a common rtp package ,or udpsrc can't deal with the larger then 1348 > package? > Thanks very much.For this ,I try many ways and many days,but still failed. > zhichao. > > > -- > View this message in context: http://gstreamer-devel.966125.n4.nabble.com/How-to-play-IPTV-streamer-by-udpsrc-tp4632303.html > Sent from the GStreamer-devel mailing list archive at Nabble.com. > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Hello Wim:
Thanks very much for your reply. This morning I again test the pcap file,and find some new : Server: anuo@ubuntu:/mnt/hgfs/DM8148/Share$ sudo tcpreplay -i eth8 h264_multicast.pcap processing file: h264_multicast.pcap Client: PC One: Use the Ubuntu 10.04 which was installed on a VMware Workstation ,then sometimes can receive the stream can play it and sometims can't(need restart the VMware) PC two: Use notebook PC which only install the Ubuntu 10.04(No windows xp),but can't receive anyting. And all I use the same command and the same version gstreamer. Command: gst-launch -v gstrtpbin name=rtpbin udpsrc multicast-iface=eth0 multicast-group=225.1.2.10 port=8050 caps="application/x-rtp, \ media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, \ ssrc=(guint)1253787951, payload=(int)33, clock-base=(guint)3847989125, \ seqnum-base=(guint)25200" ! \ rtpbin.recv_rtp_sink_0 rtpbin. ! rtpmp2tdepay ! mpegtsdemux name=d ! queue \ ! 'video/x-h264' ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! queue ! xvimagesink If I connect udpsrc directly to mpegtsdemux: gst-launch -v udpsrc multicast-iface=eth8 multicast-group=225.1.2.10 port=8050 \ ! mpegtsdemux name=d ! queue \ ! 'video/x-h264' ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! queue ! xvimagesink Then nothing can be received.I analyse the stream package by Wireshark,I find the stream in deed was a rtp package: ----------------Wireshark capture list start-------------------------------------- No. Time Source Destination Protocol Length Identification Info 29114 66.054620 61.181.150.103 225.1.2.10 UDP 1390 0x0001 (1) Source port: 12508 Destination port: 8050 Frame 29114: 1390 bytes on wire (11120 bits), 1390 bytes captured (11120 bits) Arrival Time: Feb 23, 2012 10:49:06.161104000 涓浗鏍囧噯鏃堕棿 Epoch Time: 1329965346.161104000 seconds [Time delta from previous captured frame: 0.003405000 seconds] [Time delta from previous displayed frame: 0.003405000 seconds] [Time since reference or first frame: 66.054620000 seconds] Frame Number: 29114 Frame Length: 1390 bytes (11120 bits) Capture Length: 1390 bytes (11120 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ip:udp:data] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: HuaweiTe_1c:a7:3f (00:18:82:1c:a7:3f), Dst: IPv4mcast_01:02:0a (01:00:5e:01:02:0a) Destination: IPv4mcast_01:02:0a (01:00:5e:01:02:0a) Address: IPv4mcast_01:02:0a (01:00:5e:01:02:0a) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: HuaweiTe_1c:a7:3f (00:18:82:1c:a7:3f) Address: HuaweiTe_1c:a7:3f (00:18:82:1c:a7:3f) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol Version 4, Src: 61.181.150.103 (61.181.150.103), Dst: 225.1.2.10 (225.1.2.10) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 1376 Identification: 0x0001 (1) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 60 Protocol: UDP (17) Header checksum: 0xc264 [correct] [Good: True] [Bad: False] Source: 61.181.150.103 (61.181.150.103) Destination: 225.1.2.10 (225.1.2.10) User Datagram Protocol, Src Port: 12508 (12508), Dst Port: 8050 (8050) Source port: 12508 (12508) Destination port: 8050 (8050) Length: 1356 Checksum: 0x0000 (none) [Good Checksum: False] [Bad Checksum: False] Data (1348 bytes) 0000 90 21 f2 66 12 cf a6 d5 08 0f bd 04 5a 58 00 04 .!.f........ZX..-----------RTP package head 0010 03 02 43 f2 4f 45 9d a0 06 aa 02 50 06 93 00 00 ..C.OE.....P.... 0020 47 03 f2 1f 0b 20 b4 75 5c 26 e8 ed 97 c9 4b c6 G.... .u\&....K. 0030 44 1b 4c 18 01 e8 a6 02 f0 c4 7b 47 72 9a 80 30 D.L.......{Gr..0------Ts data start 0040 c9 06 96 dc 28 76 25 18 80 cc fb 4b 8a 7e 19 5b ....(v%....K.~.[ 0050 8b f4 2e 38 17 53 96 33 d6 2a 92 a2 56 4f 97 dd ...8.S.3.*..VO.. 0060 b4 4e e2 e3 1f a6 5f 87 c9 4d cb 8f f2 ad b4 95 .N...._..M...... 0070 97 dd 18 3a 26 bc cf a7 d0 2b 91 a4 ad ae 4f 04 ...:&....+....O. 0080 23 63 c2 ea 8c 8e f0 90 e5 0c bb 7f a5 ee 39 50 #c............9P 0090 04 c8 01 87 4e 73 95 4b 75 7a 07 36 69 67 4d 61 ....Ns.Kuz.6igMa 00a0 9a ca dc 1d 08 d7 7e 3a 66 1a 7a 55 07 f3 dd 53 ......~:f.zU...S ----------------------End Accodring to RTP header, version 2: Ver P X CC M PT Sequence Number Timestamp SSRC CSRC [0..15] According to: 0000 90 21 f2 66 12 cf a6 d5 08 0f bd 04 5a 58 00 04 .!.f........ZX..-----------RTP package head 0010 03 02 43 f2 4f 45 9d a0 06 aa 02 50 06 93 00 00 ..C.OE.....P.... The 32 bytes ,is a rtp package,and have header extension X, Extension. -------has been set 1 in this example. If set, the fixed header is followed by exactly one header extension PT, Payload Type. 7 bits.----is 33 in this example(MP2T) ----------and so on Now,I have some question about my pipeline: 1. In the PC I use tcpdump can see the package data and print data length is 1348 bytes,but why udpsrc can't get it? Is this because udpsrc plugin or caps="application/x-rtp...." settings ? I use gst-launch -v to debug and print the infro ,but can't print anything,may be the udpsrc plugin can't receive data more than 1348 bytes? or ? 2. I have test another H264 TS stream,and play it with VLC by the methord of RTP,and I use the above gstreamer pipeline command, all can be received and can be played. but the stream data length was 1328 bytes ,not 1348bytes,as the RTP head lengh is 12 bytes ,not 32 bytes. So ,Why My pipeline command can play only the RTP stream which has 12 bytes rtp head,not 32 bytes? Wheather I use to change the udpsrc or other code? Thanks very much. zhichao. -- View this message in context: http://gstreamer-devel.966125.n4.nabble.com/How-to-play-IPTV-streamer-by-udpsrc-tp4632303p4634036.html Sent from the GStreamer-devel mailing list archive at Nabble.com. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On 05/15/2012 09:23 AM, tanzhichaoanuo wrote:
> Hello Wim: If you're unsure if you are receiving anything, try this first gst-launch-0.10 udpsrc ... ! fakesink -v then add other elements until it stops working. Wim > > Thanks very much for your reply. > This morning I again test the pcap file,and find some new : > > Server: > anuo@ubuntu:/mnt/hgfs/DM8148/Share$ sudo tcpreplay -i eth8 > h264_multicast.pcap > > processing file: h264_multicast.pcap > > > > Client: > PC One: > > Use the Ubuntu 10.04 which was installed on a VMware Workstation ,then > sometimes can receive the stream can play it and sometims can't(need restart > the VMware) > > PC two: > Use notebook PC which only install the Ubuntu 10.04(No windows xp),but can't > receive anyting. > And all I use the same command and the same version gstreamer. > > Command: > > gst-launch -v gstrtpbin name=rtpbin udpsrc multicast-iface=eth0 > multicast-group=225.1.2.10 port=8050 caps="application/x-rtp, \ > media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, \ > ssrc=(guint)1253787951, payload=(int)33, clock-base=(guint)3847989125, \ > seqnum-base=(guint)25200" ! \ rtpbin.recv_rtp_sink_0 rtpbin. ! rtpmp2tdepay > ! mpegtsdemux name=d ! queue \ ! 'video/x-h264' ! ffdec_h264 ! > ffmpegcolorspace ! videoscale ! queue ! xvimagesink If I connect udpsrc > directly to mpegtsdemux: gst-launch -v udpsrc multicast-iface=eth8 > multicast-group=225.1.2.10 port=8050 \ ! mpegtsdemux name=d ! queue \ ! > 'video/x-h264' ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! queue ! > xvimagesink > > Then nothing can be received.I analyse the stream package by Wireshark,I > find the stream in deed was a rtp package: > > ----------------Wireshark capture list > start-------------------------------------- > No. Time Source Destination Protocol Length Identification Info > 29114 66.054620 61.181.150.103 225.1.2.10 UDP 1390 0x0001 (1) Source port: > 12508 Destination port: 8050 > Frame 29114: 1390 bytes on wire (11120 bits), 1390 bytes captured (11120 > bits) > Arrival Time: Feb 23, 2012 10:49:06.161104000 涓浗鏍囧噯鏃堕棿 > Epoch Time: 1329965346.161104000 seconds > [Time delta from previous captured frame: 0.003405000 seconds] > [Time delta from previous displayed frame: 0.003405000 seconds] > [Time since reference or first frame: 66.054620000 seconds] > Frame Number: 29114 > Frame Length: 1390 bytes (11120 bits) > Capture Length: 1390 bytes (11120 bits) > [Frame is marked: False] > [Frame is ignored: False] > [Protocols in frame: eth:ip:udp:data] > [Coloring Rule Name: UDP] > [Coloring Rule String: udp] > Ethernet II, Src: HuaweiTe_1c:a7:3f (00:18:82:1c:a7:3f), Dst: > IPv4mcast_01:02:0a (01:00:5e:01:02:0a) > Destination: IPv4mcast_01:02:0a (01:00:5e:01:02:0a) > Address: IPv4mcast_01:02:0a (01:00:5e:01:02:0a) > .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) > .... ..0. .... .... .... .... = LG bit: Globally unique address (factory > default) > Source: HuaweiTe_1c:a7:3f (00:18:82:1c:a7:3f) > Address: HuaweiTe_1c:a7:3f (00:18:82:1c:a7:3f) > .... ...0 .... .... .... .... = IG bit: Individual address (unicast) > .... ..0. .... .... .... .... = LG bit: Globally unique address (factory > default) > Type: IP (0x0800) > Internet Protocol Version 4, Src: 61.181.150.103 (61.181.150.103), Dst: > 225.1.2.10 (225.1.2.10) > Version: 4 > Header length: 20 bytes > Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT > (Not ECN-Capable Transport)) > 0000 00.. = Differentiated Services Codepoint: Default (0x00) > .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable > Transport) (0x00) > Total Length: 1376 > Identification: 0x0001 (1) > Flags: 0x00 > 0... .... = Reserved bit: Not set > .0.. .... = Don't fragment: Not set > ..0. .... = More fragments: Not set > Fragment offset: 0 > Time to live: 60 > Protocol: UDP (17) > Header checksum: 0xc264 [correct] > [Good: True] > [Bad: False] > Source: 61.181.150.103 (61.181.150.103) > Destination: 225.1.2.10 (225.1.2.10) > User Datagram Protocol, Src Port: 12508 (12508), Dst Port: 8050 (8050) > Source port: 12508 (12508) > Destination port: 8050 (8050) > Length: 1356 > Checksum: 0x0000 (none) > [Good Checksum: False] > [Bad Checksum: False] > Data (1348 bytes) > 0000 90 21 f2 66 12 cf a6 d5 08 0f bd 04 5a 58 00 04 > .!.f........ZX..-----------RTP package head > 0010 03 02 43 f2 4f 45 9d a0 06 aa 02 50 06 93 00 00 ..C.OE.....P.... > 0020 47 03 f2 1f 0b 20 b4 75 5c 26 e8 ed 97 c9 4b c6 G.... .u\&....K. > 0030 44 1b 4c 18 01 e8 a6 02 f0 c4 7b 47 72 9a 80 30 > D.L.......{Gr..0------Ts data start > 0040 c9 06 96 dc 28 76 25 18 80 cc fb 4b 8a 7e 19 5b ....(v%....K.~.[ > 0050 8b f4 2e 38 17 53 96 33 d6 2a 92 a2 56 4f 97 dd ...8.S.3.*..VO.. > 0060 b4 4e e2 e3 1f a6 5f 87 c9 4d cb 8f f2 ad b4 95 .N...._..M...... > 0070 97 dd 18 3a 26 bc cf a7 d0 2b 91 a4 ad ae 4f 04 ...:&....+....O. > 0080 23 63 c2 ea 8c 8e f0 90 e5 0c bb 7f a5 ee 39 50 #c............9P > 0090 04 c8 01 87 4e 73 95 4b 75 7a 07 36 69 67 4d 61 ....Ns.Kuz.6igMa > 00a0 9a ca dc 1d 08 d7 7e 3a 66 1a 7a 55 07 f3 dd 53 ......~:f.zU...S > > > > ----------------------End > > Accodring to RTP header, version 2: > > Ver P X CC M PT Sequence Number > Timestamp > SSRC > CSRC [0..15] > > > According to: > 0000 90 21 f2 66 12 cf a6 d5 08 0f bd 04 5a 58 00 04 > .!.f........ZX..-----------RTP package head > 0010 03 02 43 f2 4f 45 9d a0 06 aa 02 50 06 93 00 00 ..C.OE.....P.... > > The 32 bytes ,is a rtp package,and have header extension X, Extension. > -------has been set 1 in this example. > If set, the fixed header is followed by exactly one header extension > > > PT, Payload Type. 7 bits.----is 33 in this example(MP2T) ----------and so on > > > > Now,I have some question about my pipeline: > 1. > In the PC I use tcpdump can see the package data and print data length > is 1348 bytes,but why udpsrc can't get it? > Is this because udpsrc plugin or caps="application/x-rtp...." settings ? > I use gst-launch -v to debug and print the infro ,but can't print > anything,may be the udpsrc plugin can't receive data more than 1348 bytes? > or ? > > 2. > I have test another H264 TS stream,and play it with VLC by the methord > of RTP,and I use the above gstreamer pipeline command, all can be received > and can be played. but the stream data length was 1328 bytes ,not > 1348bytes,as the RTP head lengh is 12 bytes ,not 32 bytes. So ,Why My > pipeline command can play only the RTP stream which has 12 bytes rtp > head,not 32 bytes? > > Wheather I use to change the udpsrc or other code? > > Thanks very much. > > zhichao. > > > > -- > View this message in context: http://gstreamer-devel.966125.n4.nabble.com/How-to-play-IPTV-streamer-by-udpsrc-tp4632303p4634036.html > Sent from the GStreamer-devel mailing list archive at Nabble.com. > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
<quote author="Wim Taymans">
On 05/15/2012 09:23 AM, tanzhichaoanuo wrote: > Hello Wim: If you're unsure if you are receiving anything, try this first gst-launch-0.10 udpsrc ... ! fakesink -v then add other elements until it stops working. Hello Wim: Thanks for your reply again. According to your suggestion,I connect my commputer to the IPTV,and play a multicast stream. 1。 tzc@tzc-laptop:~$ sudo tcpdump -i eth0 08:58:02.186501 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 08:58:02.190486 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 08:58:02.194492 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 08:58:02.198450 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 08:58:02.202844 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 08:58:02.206425 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 08:58:02.210473 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 08:58:02.215165 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 08:58:02.218436 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 08:58:02.222653 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 08:58:02.226575 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 08:58:02.234453 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 ---------------------------------------------------- at the same I use the command: tzc@tzc-laptop:~/Myproject$ gst-launch-0.10 udpsrc multicast-group=225.1.2.2 port=8034 ... ! fakesink -v Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock ---------------stop, here,can't receive anything. But When I play a H264 TS stream(1326 bytes one package) with VLC ,then : gst-launch-0.10 udpsrc multicast-group=225.1.2.2 port=8034 ... ! fakesink -v /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (1328 bytes, timestamp: 0:00:15.638164478, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0x8e9e240" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (1328 bytes, timestamp: 0:00:15.638214764, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0x8e9e180" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (1328 bytes, timestamp: 0:00:15.639597342, duration: none, offset: -1, offset_end: -1, flags: 0 ) 0x8e9e0c0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* (fakesink0:sink) (1328 bytes, timestamp: ------------------------------------------------ So,Now I am sure there may be some problem on udpsrc plugin,Wheather it can receive the package more than 1348 bytes? have you test it? Thanks very much for you telling me the methord to find the problem. zhichao. |
In reply to this post by tanzhichaoanuo
Hello all:
I have resolved the above problem. The IPTV multicast package can't be received and played by gstreamer,this is because udpsrc plugin can't get the net stream,but when I debug in the kernel,I found the multicast package was dropped in the IP layer because of IP routing.Why will result this? This is because the source address of the IPTV stream. for example: I use tcpdump -i eth0 ,and get the follow infor: 09:11:55.138926 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.142901 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.146890 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.150871 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.154911 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.160492 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 09:11:55.164337 IP 61.181.150.102.12502 > 225.1.2.2.8034: UDP, length 1348 the source IP addresss was 61.181.150.102,and my local IP address was 192.168.0.100.and the local route table don't include 61.XX.XX.XX After reconfig the kernel,and select the net options ,reconfig the IP route infor will resolve this. Thanks all the same. zhichao. |
Free forum by Nabble | Edit this page |