How to play IPTV streamer by udpsrc?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

How to play IPTV streamer by udpsrc?

tanzhichaoanuo
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.
Reply | Threaded
Open this post in threaded view
|

Re: How to play IPTV streamer by udpsrc?

Wim Taymans
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?
your encoding-name caps property is wrong, it doesn't match the
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
Reply | Threaded
Open this post in threaded view
|

Re: How to play IPTV streamer by udpsrc?

Wim Taymans
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
> "
..or more likely, this stream is not RTP, you'll need to link udpsrc
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
Reply | Threaded
Open this post in threaded view
|

AW: How to play IPTV streamer by udpsrc?

BGraaf
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?
your encoding-name caps property is wrong, it doesn't match the
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
Reply | Threaded
Open this post in threaded view
|

Re: AW: How to play IPTV streamer by udpsrc?

tanzhichaoanuo
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
Reply | Threaded
Open this post in threaded view
|

Re: AW: How to play IPTV streamer by udpsrc?

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.

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
Reply | Threaded
Open this post in threaded view
|

Re: AW: How to play IPTV streamer by udpsrc?

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

Reply | Threaded
Open this post in threaded view
|

Re: How to play IPTV streamer by udpsrc?

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