lkml.org 
[lkml]   [2020]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v4 04/12] v4l: Add source event change for bit-depth
From
Date
Hi Hans,

On 1/9/20 10:57 AM, Hans Verkuil wrote:
> On 1/9/20 8:41 AM, Stanimir Varbanov wrote:
>> Hi Hans,
>>
>> On 1/8/20 6:09 PM, Hans Verkuil wrote:
>>> On 1/6/20 4:49 PM, Stanimir Varbanov wrote:
>>>> This event indicate that the source color bit-depth is changed
>>>> during run-time. The client must get the new format and re-allocate
>>>> buffers for it. This can usually happens with video decoder (encoders)
>>>> when the bit-stream color bit-depth is changed from 8 to 10bits
>>>> or vice versa.
>>>>
>>>> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>>>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>>>> ---
>>>> Documentation/media/uapi/v4l/vidioc-dqevent.rst | 8 +++++++-
>>>> Documentation/media/videodev2.h.rst.exceptions | 1 +
>>>> include/uapi/linux/videodev2.h | 1 +
>>>> 3 files changed, 9 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>>>> index 42659a3d1705..fad853d440cf 100644
>>>> --- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>>>> +++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>>>> @@ -402,7 +402,13 @@ call.
>>>> that many Video Capture devices are not able to recover from a temporary
>>>> loss of signal and so restarting streaming I/O is required in order for
>>>> the hardware to synchronize to the video signal.
>>>> -
>>>> + * - ``V4L2_EVENT_SRC_CH_COLOR_DEPTH``
>>>> + - 0x0002
>>>> + - This event gets triggered when color bit-depth change is detected
>>>> + from a video decoder. Applications will have to query the new pixel
>>>> + format and re-negotiate the queue. In most cases the streaming must be
>>>> + stopped and restarted (:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>`
>>>> + followed by :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>`).
>>>
>>> I think this is too specific for decoders. Something similar to the
>>> CH_RESOLUTION description would be more appropriate:
>>>
>>> - This event gets triggered when a color bit-depth change (but not a
>>> resolution change!) is detected at an input. This can come from an
>>
>> What you mean by "but not a resolution change" here? Resolution change
>> and bit-depth change cannot occur on the same time, or something else.
>
> What I was trying to say is that a resolution change implies a possible bit-depth
> change as well, whereas V4L2_EVENT_SRC_CH_COLOR_DEPTH is only set if there is
> a bit-depth change but no resolution change.
>
> V4L2_EVENT_SRC_CH_RESOLUTION requires that userspace does a full resync to the
> new format, CH_COLOR_DEPTH implies that only the bit depth changed.

CH_COLOR_DEPTH implies format re-negotiation as well. In Venus case
8->10bit change will change the format of OPB buffers (now it is not
possible because of lack of v4l modifiers) and DPB buffers becomes
compressed raw buffers (to optimize bandwidth).

>
> Which actually makes me wonder: is there a difference between the two change flags
> w.r.t. userspace behavior? If there is, then that should be carefully documented,
> if there isn't, then is this new flag really needed?

Looking into semantics of v4l events, CH_COLOR_DEPTH makes sense because
it describes what actually changed (similar to CH_RESOLUTION). I would
say that v4l2_event::type V4L2_EVENT_SOURCE_CHANGE implies format
re-negotiation and v4l2_event::src_change just informs userland what
exactly is changed.

I'll postpone this patch until we have clear vision what will be the
usage in user-space.

--
regards,
Stan

\
 
 \ /
  Last update: 2020-01-10 11:54    [W:0.081 / U:1.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site