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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux