[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4d1260be46be22d7b40fab9788763af796d118dc.camel@ndufresne.ca>
Date: Fri, 01 Aug 2025 11:23:35 -0400
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: ming.qian@....nxp.com, mchehab@...nel.org, hverkuil-cisco@...all.nl
Cc: sebastian.fricke@...labora.com, shawnguo@...nel.org,
s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com,
linux-imx@....com, xiahong.bao@....com, eagle.zhou@....com,
imx@...ts.linux.dev, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 2/4] media: docs: dev-decoder: Trigger dynamic
source change for colorspace
Hi Ming,
Le vendredi 18 avril 2025 à 16:54 +0800, ming.qian@....nxp.com a écrit :
> From: Ming Qian <ming.qian@....nxp.com>
>
> If colorspace changes, the client needs to renegotiate the pipeline,
> otherwise the decoded frame may not be displayed correctly.
>
> When a colorspace change in the stream, the decoder sends a
> V4L2_EVENT_SOURCE_CHANGE event with changes set to
> V4L2_EVENT_SRC_CH_COLORSPACE. After client receive this source change
> event, then client can switch to the correct stream setting. And each
> frame can be displayed properly.
sorry for the long delay. While reading this, in any case userspace have to read
the new format. Why can't userspace compare the old and new v4l2_format and
decide to avoid re-allocation that way ?
There is also backward compatbility issues for driver that was sending
V4L2_EVENT_SRC_CH_RESOLUTION for colorspace change before. Despite the costly
re-allocation, userspace only watching for V4L2_EVENT_SRC_CH_RESOLUTION would
endup not updating the colorspace anymore.
Combining both would be an option, but then V4L2_EVENT_SRC_CH_RESOLUTION means
any v4l2_format changes, which is awkward. What do you think of leaving to
userspace the task of comparing the old and new v4l2_format ?
Nicolas
>
> So add colorspace as a trigger parameter for dynamic resolution change.
>
> Signed-off-by: Ming Qian <ming.qian@....nxp.com>
> ---
> v2
> - Add V4L2_EVENT_SRC_CH_COLORSPACE for colorspace source change event
>
> .../userspace-api/media/v4l/dev-decoder.rst | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> index ef8e8cf31f90..51d6da3eea4a 100644
> --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> @@ -784,8 +784,8 @@ before the sequence started. Last of the buffers will have
> the
> must check if there is any pending event and:
>
> * if a ``V4L2_EVENT_SOURCE_CHANGE`` event with ``changes`` set to
> - ``V4L2_EVENT_SRC_CH_RESOLUTION`` is pending, the `Dynamic Resolution
> - Change` sequence needs to be followed,
> + ``V4L2_EVENT_SRC_CH_RESOLUTION`` or ``V4L2_EVENT_SRC_CH_COLORSPACE`` is
> pending,
> + the `Dynamic Resolution Change` sequence needs to be followed,
>
> * if a ``V4L2_EVENT_EOS`` event is pending, the `End of Stream` sequence
> needs
> to be followed.
> @@ -932,13 +932,17 @@ reflected by corresponding queries):
>
> * the minimum number of buffers needed for decoding,
>
> -* bit-depth of the bitstream has been changed.
> +* bit-depth of the bitstream has been changed,
> +
> +* colorspace of the bitstream has been changed.
>
> Whenever that happens, the decoder must proceed as follows:
>
> 1. After encountering a resolution change in the stream, the decoder sends a
> ``V4L2_EVENT_SOURCE_CHANGE`` event with ``changes`` set to
> - ``V4L2_EVENT_SRC_CH_RESOLUTION``.
> + ``V4L2_EVENT_SRC_CH_RESOLUTION``, or a colorspace change in the stream,
> the
> + decoder sends a ``V4L2_EVENT_SOURCE_CHANGE`` event with ``changes`` set
> to
> + ``V4L2_EVENT_SRC_CH_COLORSPACE``.
>
> .. important::
>
> @@ -946,6 +950,11 @@ Whenever that happens, the decoder must proceed as
> follows:
> values applying to the stream after the resolution change, including
> queue formats, selection rectangles and controls.
>
> +.. note::
> + A ``V4L2_EVENT_SOURCE_CHANGE`` event with ``changes`` set to
> + ``V4L2_EVENT_SRC_CH_RESOLUTION`` will affect the allocation, but
> + ``V4L2_EVENT_SRC_CH_COLORSPACE`` won't.
> +
> 2. The decoder will then process and decode all remaining buffers from
> before
> the resolution change point.
>
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists