GNOME Bugzilla – Bug 729555
Fail to negotiate pipeline using rtph263ppay, avenc_h263p and a fixed caps filter
Last modified: 2018-11-03 12:56:18 UTC
The following pipeline works "gst-launch-1.0 videotestsrc ! avenc_h263p ! rtph263ppay ! udpsink" but this one doesn't: $ gst-launch-1.0 -v videotestsrc ! avenc_h263p ! rtph263ppay ! application/x-rtp ! udpsink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive /GstPipeline:pipeline0/avenc_h263p:avenc_h263p0.GstPad:sink: caps = video/x-raw, format=(string)I420, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive ERROR: from element /GstPipeline:pipeline0/avenc_h263p:avenc_h263p0: GStreamer error: negotiation problem. Additional debug info: gstvideoencoder.c(1368): gst_video_encoder_chain (): /GstPipeline:pipeline0/avenc_h263p:avenc_h263p0: encoder not initialized ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... /GstPipeline:pipeline0/avenc_h263p:avenc_h263p0.GstPad:sink: caps = NULL /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = NULL Freeing pipeline ... In the first pipeline, gst_ffmpeg_caps_with_codecid() is called with "video/x-h263, variant=(string)itu" (1 struct) and so everything works fine. But in the second one, it's called with "video/x-h263, variant=(string)itu, h263version=(string)h263, annex-f=(boolean)false, annex-i=(boolean)false, annex-j=(boolean)false, annex-t=(boolean)false; video/x-h263, variant=(string)itu, h263version=(string)h263" (2 structs); this function only use the first structure and so it fails to negotiate.
Created attachment 275878 [details] log GST_DEBUG=3,GST_CAPS:6,*EVENT*:6,*PAD*:6,libav:6 gst-launch-1.0 -v videotestsrc ! avenc_h263p ! rtph263ppay ! application/x-rtp ! udpsink
This is caused by a mismatch between the SDP Offer/Answer style negotiation and the GStreamer Caps negotiation and how they clash in our application/x-rtp caps. In SDP Offer/Answer, if no options are specified for H.263, it means that only the baseline profile is supported (which is what avenc_h263 produces). One has to specify some options to get the H.263+ profile (which is what avenc_h263p produces). In GStreamer, no options means anything is supported. I tried to bridge the gap by allowing everything if downstream returns ANY, but parsing it as SDP if it returns something, which explains the odd behavior here. In Farstream, we alays put avenc_h263 and avenc_h263p together in a autoconvert so that it choses the right element based on downstream caps.
So is there anything that needs to be done here?
I stumbled over this as well. In my usecase I have an rtpbin into which I feed from an appsrc. My pipeline is something like this: rtpbin name=rtpbin format=time do-timestamp=TRUE \ appsrc caps=<caps> ! videoconvert ! videoscale ! videorate ! avenc_h263p ! rtph263ppay ! rtpbin.send_rtp_sink_0 \ rtpbin.send_rtp_src_0 ! udpsink Could you detail what exactly is necessary for h263p in gstreamer? For now I had to disable h263p as I couldn't get it to work... :/
Here's the problem. The I think avenc_h263p does not handle caps negotiation properly. 0:00:00.088757835 29455 0x91cca0 DEBUG GST_CAPS gstutils.c:2830:GstCaps *gst_pad_query_caps(GstPad *, GstCaps *):<rtph263ppay0:sink> query returned video/x-h263, variant=(string)itu, h263version=(string)h263, annex-f=(boolean)false, annex-i=(boolean)false, annex-j=(boolean)false, annex-t=(boolean)false; video/x-h263, variant=(string)itu, h263version=(string)h263 0:00:00.088762679 29455 0x91cca0 DEBUG GST_CAPS gstpad.c:2628:GstCaps *gst_pad_get_allowed_caps(GstPad *):<avenc_h263p0:src> allowed caps video/x-h263, variant=(string)itu, h263version=(string)h263, annex-f=(boolean)false, annex-i=(boolean)false, annex-j=(boolean)false, annex-t=(boolean)false; video/x-h263, variant=(string)itu, h263version=(string)h263 0:00:00.088768365 29455 0x91cca0 DEBUG libav gstavvidenc.c:446:gst_ffmpegvidenc_set_format:<avenc_h263p0> chose caps video/x-h263, variant=(string)itu, h263version=(string)h263, annex-f=(boolean)false, annex-i=(boolean)false, annex-j=(boolean)false, annex-t=(boolean)false; video/x-h263, variant=(string)itu, h263version=(string)h263 0:00:00.088772156 29455 0x91cca0 LOG libav gstavcodecmap.c:2877:gst_ffmpeg_caps_with_codecid: codec_id:20, codec_type:0, caps:video/x-h263, variant=(string)itu, h263version=(string)h263, annex-f=(boolean)false, annex-i=(boolean)false, annex-j=(boolean)false, annex-t=(boolean)false; video/x-h263, variant=(string)itu, h263version=(string)h263 context:0x902800 0:00:00.088777660 29455 0x91cca0 DEBUG libav gstavcodecmap.c:2940:gst_ffmpeg_caps_with_codecid: no codec data 0:00:00.088779959 29455 0x91cca0 LOG libav gstavcodecmap.c:735:gst_ffmpeg_codecid_to_caps: codec_id:20, context:0x902800, encode:1 0:00:00.088782703 29455 0x91cca0 LOG libav gstavcodecmap.c:265:gst_ff_vid_caps_new: context:0x902800, codec_id:20, mimetype:video/x-h263 0:00:00.088786709 29455 0x91cca0 LOG libav gstavcodecmap.c:287:gst_ff_vid_caps_new: setting framerate: 30/1 0:00:00.088791945 29455 0x91cca0 LOG libav gstavcodecmap.c:2153:gst_ffmpeg_codecid_to_caps: caps for codec_id=20: video/x-h263, width=(int)320, height=(int)240, framerate=(fraction)30/1, variant=(string)itu, h263version=(string)h263p, annex-f=(boolean)false, annex-j=(boolean)false, annex-i=(boolean)false, annex-t=(boolean)false 0:00:00.088799840 29455 0x91cca0 DEBUG libav gstavvidenc.c:525:gst_ffmpegvidenc_set_format: Unsupported codec - no caps found
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/12.