GNOME Bugzilla – Bug 782778
h264parse: Alignment of input caps no longer set to a default value
Last modified: 2018-11-03 14:08:31 UTC
In the following change the 'handling of input caps corner cases for the h264parse element" was tidied up. https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/gst/videoparsers/gsth264parse.c?h=1.4&id=ea7d5027a079fad397b0ad97a0be48c69121e30e Although not sure, I believe that there may have been an unintended behavioural change with the above submission. Prior to the submission, when the stream format was not specified in the input caps the local 'format' variable was assigned a default value of GST_H264_PARSE_FORMAT_BYTE and the local 'alignment' variable was assigned a default value of GST_H264_PARSE_ALIGN_AU. After the submission when the stream format was not specified in the input caps the local 'format' variable was assigned a default value of GST_H264_PARSE_FORMAT_BYTE and the local 'alignment' variable was left unchanged. When 'format' is given a default value, should alignement be given a value that is appropriate for the chosen default stream format? Not doing so, can result in unexpected behaviour of the gst_h264_parse_negotiate() method that gst_h264_parse_set_caps() calls
No alignment is fine, but no stream-format is tricky. It's a required field for h264 caps.
Sebastian, thanks for the quick response. My GStreamer and H264 knowledge is relatively limited, so I apologise if the following is a foolish question. Consider the situation in which the input caps are GST_H264_PARSE_FORMAT_NONE and GST_H264_PARSE_ALIGN_NONE. gst_h264_parse_set_caps() would set the local 'format' variable to GST_H264_PARSE_FORMAT_BYTE and leave the 'align' value unaltered, i.e. GST_H264_PARSE_ALIGN_NONE gst_h264_parse_set_caps() calls gst_h264_parse_negotiate(). Within gst_h264_parse_negotiate() because the h264 source pad only supports alignment capabilities of GST_H264_PARSE_ALIGN_AU and GST_H264_PARSE_ALIGN_NAL, there will be no intersect between the input caps (GST_H264_PARSE_FORMAT_BYTE and GST_H264_PARSE_ALIGN_NONE) and the h264 source pad. This then results in the h264 source pad caps being 'fixated', which then means that a format of GST_H264_PARSE_FORMAT_AVC and align of GST_H264_PARSE_ALIGN_AU is negotiated. Prior to to the change "ea7d5027a079fad397b0ad97a0be48c69121e30e", a format of GST_H264_PARSE_FORMAT_BYTE and align of GST_H264_PARSE_ALIGN_AU would have been negotiated in this situation. To my inexperienced eye, this seems like a more reasonable result. Sebastian, what is your assessment of this situation?
The reported bug here isn't clear. I have put some H264 bytestream into a file. If I run that, without filter: gst-launch-1.0 -v filesrc location=test.h264 ! h264parse ! fakesink I get AVC/au. If I add a capsfilter like this: gst-launch-1.0 -v filesrc location=test.h264 ! h264parse ! video/x-h264,stream-format=byte-stream ! fakesink It's properly negotiated, and I get ByteStream/au. To me the default choice is not idea, in general we tend to argue that when downstream does not specify anything it's preferred to produce byte-stream, so at least this would return in similar same file: gst-launch-1.0 -v filesrc location=test.h264 ! h264parse ! filesink location=out.h264 Is that what you are reporting ?
Would it be possible to answer the questions?
Nicolas, apologies for the slow reply. Yes, that is what I am reporting. Prior to the change that I referred to, your example **unfiltered** pipleline (listed below) would have negotiated byte/au. But after the change, as you saw, avc/au is negotiated gst-launch-1.0 -v filesrc location=test.h264 ! h264parse ! fakesink It is the behavioural change, without the presence of the capsfilter, that I am reporting. I realise that when a capsfilter is specified, that the negotiated caps are as expected.
I can reproduce this. Looks like a regression. Not sure it's related to that particular commit of mine though, I may have re-fixed this again afterwards. h264parse should definitely default to stream-format=byte-stream with fakesink or appsink if downstream has ANY caps.
-- 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-plugins-bad/issues/557.