[Bug 791471] v4l2object: non-default colorimetry broken for v4l2h264enc

[GStreamer (GNOME Bugzilla)]

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

--- Comment #15 from Philipp Zabel <p.zabel at pengutronix.de> ---
With the V4L2 codec API discussion flaring up again, I'm unsure as ever how to
handle this, but I understand that using the verified colorimetry alone will
not suffice. At the very least colorimetry that is fixed on the sink pad should
be available on the source pad initially.

I wasn't aware before that currently the V4L2 API does not allow to set
colorimetry on the capture side at all. Given that everybody seems to expect
encoder colorimetry to be set on the unencoded output queue, and the encoder
initialization scheme makes us call S_FMT on the capture queue first, I see no
way to read useful capture queue colorimetry before the first source change
event at all.

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