Hi Hans, On 5/26/20 1:26 PM, Hans Verkuil wrote: > On 30/04/2020 13:38, Stanimir Varbanov wrote: >> Here we add two more reasons for dynamic-resolution-change state >> (I think the name is misleading espesially "resolution" word, maybe > > espesially -> especially > >> dynamic-bitstream-change is better to describe). >> >> The first one which could change in the middle of the stream is the >> bit-depth. For worst example the stream is 8bit at the begging but >> later in the bitstream it changes to 10bit. That change should be >> propagated to the client so that it can take appropriate action. In >> this case most probably it has to stop the streaming on the capture >> queue and re-negotiate the pixel format and start the streaming >> again. >> >> The second new reason is colorspace change. I'm not sure what action >> client should take but at least it should be notified for such change. >> One possible action is to notify the display entity that the colorspace >> and its parameters (y'cbcr encoding and so on) has been changed. >> >> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@xxxxxxxxxx> >> --- >> Documentation/userspace-api/media/v4l/dev-decoder.rst | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst >> index 606b54947e10..bf10eda6125c 100644 >> --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst >> +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst >> @@ -906,7 +906,11 @@ reflected by corresponding queries): >> >> * visible resolution (selection rectangles), >> >> -* the minimum number of buffers needed for decoding. >> +* the minimum number of buffers needed for decoding, >> + >> +* bit-depth of the bitstream has been changed, >> + >> +* colorspace (and its properties) has been changed. > > For this I want to have a new source change flag: > > V4L2_EVENT_SRC_CH_COLORIMETRY > > Changing colorimetry without changing resolution/bit depth does not > require buffers to be re-allocated, it just changes how the pixel > data is interpreted w.r.t. color. And that is important to know. I'm going to create a patch for this event, but I started to wonder do we need new buffer flag for this? Something like below sequence: - client receive SRC_CH_COLORIMETRY event - client issue G_FMT(CAPTURE queue) - at that point the client has to know the last buffer with previous colorimetry and thus the buffer with new colorimetry How the client will know the buffer with new colorimetry? -- regards, Stan
