[gstreamer-bugs] [Bug 621296] New: Bosch H263 RFC 4629 and pt from RTSP
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Fri Jun 11 05:32:28 PDT 2010
https://bugzilla.gnome.org/show_bug.cgi?id=621296
GStreamer | gst-plugins-good | 0.10.23
Summary: Bosch H263 RFC 4629 and pt from RTSP
Classification: Desktop
Product: GStreamer
Version: 0.10.23
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gst-plugins-good
AssignedTo: gstreamer-bugs at lists.sourceforge.net
ReportedBy: marc.leeman at gmail.com
QAContact: gstreamer-bugs at lists.sourceforge.net
GNOME target: ---
GNOME version: ---
I am trying to handle;decode a Bosch H263 stream.
I can decode it by using the following chains:
gst-launch rtspsrc location=rtsp://10.3.0.174/video?line=1 ! gstrtpbin !
udpsink host=239.4.33.33 port=3333
DISPLAY=:0 gst-launch udpsrc uri=udp://239.4.33.33:3333
caps="application/x-rtp" ! rtph263pdepay ! video/x-h263 ! typefind ! ffdec_h263
! glimagesink sync=False
However,
DISPLAY=:0 gst-launch rtspsrc location=rtsp://10.3.0.174/video?line=1 !
rtph263pdepay ! video/x-h263 ! typefind ! ffdec_h263 ! glimagesink sync=False
Is a big nono
I thing I managed to trach the issue down to the following:
When using RTSP
/GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0.GstGhostPad:recv_rtp_src_0_4294967295_36:
caps = application/x-rtp, media=(string)video, payload=(int)36,
clock-rate=(int)90000, encoding-name=(string)H263-1998, npt-start=(guint64)0,
play-speed=(double)1, play-scale=(double)1
When sending the RTP directly again to the network and listening to the RTP
stream; I get
/GstPipeline:pipeline0/GstRtpH263PDepay:rtph263pdepay0.GstPad:sink: caps =
application/x-rtp, media=(string)video, payload=(int)96, clock-rate=(int)90000,
encoding-name=(string)H263-1998
Where does the PT=36 come from?
The answer lies in the RTSP communication:
RTSP response message 0x7fff94d5d6e0
status line:
code: '200'
reason: 'OK'
version: '1.0'
headers:
key: 'CSeq', value: '2'
key: 'Cache-Control', value: 'no-cache'
key: 'Content-Type', value: 'application/sdp'
key: 'Content-Length', value: '158'
body: length 159
00000000 (0x1071400): 76 3d 30 0d 0a 6f 3d 2d 20 30 20 30 20 49 4e 20 v=0..o=-
0 0 IN
00000010 (0x1071410): 49 50 34 20 31 30 2e 33 2e 30 2e 31 37 34 0d 0a IP4
10.3.0.174..
00000020 (0x1071420): 73 3d 4c 49 56 45 20 56 49 45 57 0d 0a 74 3d 30 s=LIVE
VIEW..t=0
00000030 (0x1071430): 20 30 0d 0a 63 3d 49 4e 20 49 50 34 20 30 2e 30 0..c=IN
IP4 0.0
00000040 (0x1071440): 2e 30 2e 30 0d 0a 6d 3d 76 69 64 65 6f 20 30 20
.0.0..m=video 0
00000050 (0x1071450): 52 54 50 2f 41 56 50 20 33 36 0d 0a 61 3d 72 74 RTP/AVP
36..a=rt
00000060 (0x1071460): 70 6d 61 70 3a 33 36 20 48 32 36 33 2d 31 39 39 pmap:36
H263-199
00000070 (0x1071470): 38 2f 39 30 30 30 30 0d 0a 61 3d 63 6f 6e 74 72
8/90000..a=contr
00000080 (0x1071480): 6f 6c 3a 72 74 73 70 3a 2f 2f 31 30 2e 33 2e 30
ol:rtsp://10.3.0
00000090 (0x1071490): 2e 31 37 34 2f 76 69 64 65 6f 0d 0a 0d 0a 00
.174/video.....
sdp packet 0x7fff94d5d620:
version: '0'
origin:
username: '-'
sess_id: '0'
sess_version: '0'
nettype: 'IN'
addrtype: 'IP4'
addr: '10.3.0.174'
session_name: 'LIVE VIEW'
information: '(NULL)'
uri: '(NULL)'
connection:
nettype: 'IN'
addrtype: 'IP4'
address: '0.0.0.0'
ttl: '0'
addr_number: '0'
key:
type: '(NULL)'
data: '(NULL)'
medias:
media 0:
media: 'video'
port: '0'
num_ports: '4294967295'
proto: 'RTP/AVP'
formats:
format '36'
information: '(NULL)'
key:
type: '(NULL)'
data: '(NULL)'
attributes:
attribute 'rtpmap' : '36 H263-1998/90000'
attribute 'control' : 'rtsp://10.3.0.174/video'
It looks as if RTSP pushes PT 36, while in fact the stream is sent with PT 96.
Sending it over the network removes the false information of the SDP.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs
mailing list