Re: [RFC] docs: dev-decoder: Add two more reasons for dynamic change

[Stanimir Varbanov <stanimir.varbanov@linaro.org>]

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@linaro.org>
>> ---
>>  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