[gstreamer-bugs] [Bug 621296] New: Bosch H263 RFC 4629 and pt from RTSP

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.