GNOME Bugzilla – Bug 621296
Bosch H263: RTSP source sends pt value 36; breaks with rtph263pdepay (caps mismatch)
Last modified: 2011-06-24 11:33:38 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.
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.
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
It looks like rtpptchange's goal can also be achieved by using capssetter.
looks as if it's working as a replacement for rtpptchange; thanks for the hint.
Any reason we don't allow ANY pt (invalid ones) in all the depayloaders ?
(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..
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.
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.
Created attachment 187762 [details] [review] remove pt deps in caps and now it's here too
*** This bug has been marked as a duplicate of bug 639292 ***