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
-------------------------------
-------------------
--------------------------------------------------------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.
<br/><hr align="left" width="300" />
View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/How-to-play-IPTV-streamer-by-udpsrc-tp4632303p4634024.html">Re: AW: How to play IPTV streamer by udpsrc？</a><br/>
Sent from the <a href="http://gstreamer-devel.966125.n4.nabble.com/">GStreamer-devel mailing list archive</a> at Nabble.com.<br/>