h264parse/aacparse: caps renegotiation fails due to baseparse calling gst_pad_use_fixed_caps
Submitted by Jonas Larsson
Link to original bug (#669509)
Description
Created attachment 206935
Patch to allow downstream caps renegotiation
I have:
vsrc ! videorate ! omxh264enc ! h264parse ! fakesink
Video source has variable frame rate and videorate force-fps is set dynamically on the running pipeline. This triggers downstream caps negotiation that fails in h264parse.
- upstream calls gst_pad_get_allowed_caps on h264parse:sink
- gst_h264_parse_get_caps is called to determine allowed caps
- gst_h264_parse_get_caps calls gst_pad_get_allowed_caps on h264parse:src
- gst_pad_get_allowed_caps on h264parse:src return the current caps
- current caps and new caps differ in frame rate and new caps are rejected
The reason for failure: baseparse is calling gst_pad_use_fixed_caps on h264parse:src, so the current caps is returned.
From docs "Use this function on a pad that, once gst_pad_set_caps() has been called on it, cannot be renegotiated to something else." This is not appropriate for h264 as it can change its properties mid stream (new SPS/PPS). For example, frame-rate may be variable, for example in video conferencing.
Example:
gst_pad_get_allowed_caps (h264parse:src) returns
video/x-h264,width=640,height=480,framerate=1/1,profile=baseline,level=1.1, parsed=true,stream-format=byte-stream,alignment=au
gst_pad_get_allowed_caps (h264parse:sink) returns
video/x-h264,width=640,height=480,framerate=1/1,profile=baseline,level=1.1
Encoder (gst-omx / basevideoencoder) think downstream can only handle framerate=1/1 and rejects new caps with framerate=2/1 even though downstream actually can handle it.
Patch 206935, "Patch to allow downstream caps renegotiation":
h264parser-renegotiate.patch