How to play IPTV streamer by udpsrc？

Discussion:

tanzhichaoanuo

2012-05-14 14:25:21 UTC

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.

--
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.

Wim Taymans

2012-05-14 15:11:31 UTC

Permalink

Post by tanzhichaoanuo
Now I want to play the IPTV stream which was captured by WireShark and was
saved in th pcap file,
I use the "tcpreplay -i eth0 iptv.pcap" to sent the stream on a server
computer,
"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
"
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?

your encoding-name caps property is wrong, it doesn't match the
depayloader accepted caps.

Wim

Post by tanzhichaoanuo
By doing some research,I find the IPTV stream is different from the common
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
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Bernhard Graaf

2012-05-14 15:34:15 UTC

Permalink

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=***@lists.freedesktop.org [mailto:gstreamer-devel-bounces+bernhard.graaf=***@lists.freedesktop.org] Im Auftrag von Wim Taymans
Gesendet: Montag, 14. Mai 2012 17:12
An: gstreamer-***@lists.freedesktop.org
Betreff: Re: How to play IPTV streamer by udpsrc？

your encoding-name caps property is wrong, it doesn't match the
depayloader accepted caps.

Wim

tanzhichaoanuo

2012-05-15 07:11:08 UTC

Permalink

Hello Wim:
Thanks very much for your reply.
This morning I again test the pcap file,and find some new :
Server:
***@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
-------------------------------
-------------------
--------------------------------------------------------Wireshark capture
list stop----------------------------------------------

Accodring 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)
Identifies the format of the RTP payload and determines its interpretation
by the application. A profile specifies a default static mapping of payload
type codes to payload formats. Additional payload type codes may be defined
dynamically through non-RTP means. An RTP sender emits a single RTP payload
type at any given time; this field is not intended for multiplexing separate
media streams.

----------and so on,

NowïŒI have some question about my pipeline:

1.In the PC I use tcpdump can see the package data and printf 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-tp4632303p4634024.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.

tanzhichaoanuo

2012-05-15 07:23:06 UTC

Permalink

Hello Wim:

Thanks very much for your reply.
This morning I again test the pcap file,and find some new :

Server:
***@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.

Wim Taymans

2012-05-15 07:46:55 UTC

Permalink

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

Post by tanzhichaoanuo
Thanks very much for your reply.
h264_multicast.pcap
processing file: h264_multicast.pcap
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)
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.
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
----------------Wireshark capture list
start--------------------------------------
No. Time Source Destination Protocol Length Identification Info
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]
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)
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
Ver P X CC M PT Sequence Number
Timestamp
SSRC
CSRC [0..15]
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
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
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

tanzhichaoanuo

2012-05-15 13:20:50 UTC

Permalink

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-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-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.

--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/How-to-play-IPTV-streamer-by-udpsrc-tp4632303p4634446.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.

Wim Taymans

2012-05-14 15:27:18 UTC

Permalink

..or more likely, this stream is not RTP, you'll need to link udpsrc
directly to the
mpeg TS demuxer.

Wim

Post by tanzhichaoanuo
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
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
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

tanzhichaoanuo

2012-05-22 13:52:25 UTC

Permalink

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.

--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/How-to-play-IPTV-streamer-by-udpsrc-tp4632303p4649913.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.