After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 621296 - Bosch H263: RTSP source sends pt value 36; breaks with rtph263pdepay (caps mismatch)
Bosch H263: RTSP source sends pt value 36; breaks with rtph263pdepay (caps mi...
Status: RESOLVED DUPLICATE of bug 639292
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.23
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-06-11 12:32 UTC by Marc Leeman
Modified: 2011-06-24 11:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
add caps for bosch (1.14 KB, patch)
2010-06-11 13:00 UTC, Marc Leeman
none Details | Review
remove pt deps in caps (6.31 KB, patch)
2011-05-13 12:07 UTC, Marc Leeman
none Details | Review

Description Marc Leeman 2010-06-11 12:32:22 UTC
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.
Comment 1 Marc Leeman 2010-06-11 12:46:15 UTC
It's not in conflict; only if I don't pick gstrtpbin; it does not care about the pt, and (wrongly) assumes it is 96.

Due to the wrong assumption; it seems to be able to decode it.
Comment 2 Marc Leeman 2010-06-11 13:00:09 UTC
Created attachment 163385 [details] [review]
add caps for bosch

added caps:
      application/x-rtp
                  media: video
                payload: 36
             clock-rate: 90000
          encoding-name: H263-1998


Alternatively; I've written a module specific for Bosch' free interpretation of pt values; allowing you to overwrite it to anything else.

This approach also works (... ! rtpptchange pt=96 ! ...)

I can submit this simple module too
Comment 3 Mark Nauwelaerts 2010-06-11 13:49:36 UTC
It looks like rtpptchange's goal can also be achieved by using capssetter.
Comment 4 Marc Leeman 2010-06-11 14:36:43 UTC
looks as if it's working as a replacement for rtpptchange; thanks for the hint.
Comment 5 Olivier Crête 2010-06-12 01:39:27 UTC
Any reason we don't allow ANY pt (invalid ones) in all the depayloaders ?
Comment 6 Wim Taymans 2010-06-14 14:58:50 UTC
(In reply to comment #5)
> Any reason we don't allow ANY pt (invalid ones) in all the depayloaders ?

We use the static payload types to select the depayloader when there is no encoding-name. 

I guess we could rearrange some things to not require the payload type when the encoding-name is there. not quite sure what the consequences are..
Comment 7 Matthias Blaicher 2011-05-13 10:57:40 UTC
This also effects Bosch x264 streams. In my case a NBN-921 IP camera. 

@Mark: Could you provide an example on how to overwrite the caps with capssetter?
I tried all combinations (with and without setting the full caps) I could think of like:

gst-launch rtspsrc location="rtsp://192.168.1.98" ! capssetter replace=true caps="application/x-rtp,payload=(int)96"  ! rtph264depay ! ffdec_h264 ! xvimagesink

Patching the source code works though but I'm not so sure how to do it nicely.
Comment 8 Marc Leeman 2011-05-13 12:06:15 UTC
I am applying a local patch to remove the dependency on the pt types on the rtph264(de)pay or mp4v(de)pay in the caps since quite some time. Bosch has a number of these hardware encoders and this is fine for us.

I've contacted Wim a couple of times on this and there was an agreement (I thought so) that this would be acceptable; but it never got in the latest releases. I think there is even a patch on bugzilla somewhere.
Comment 9 Marc Leeman 2011-05-13 12:07:39 UTC
Created attachment 187762 [details] [review]
remove pt deps in caps

and now it's here too
Comment 10 Marc Leeman 2011-06-24 11:33:38 UTC

*** This bug has been marked as a duplicate of bug 639292 ***