On 09/06/2020 11:44, Stanimir Varbanov wrote: > 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? > You still need to drain the capture queue, so only after draining and a V4L2_DEC_CMD_START (or a STREAMOFF/ON pair) will the new colorimetry become active. But the big difference with CH_RESOLUTION is that no new capture buffers have to be allocated for just a colorimetry change. Regards, Hans
