[Bug 782778] h264parse: Alignment of input caps no longer set to a default value

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=782778

--- Comment #2 from Will <wiwright at tycoint.com> ---
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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.