public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ming Qian(OSS)" <ming.qian@oss.nxp.com>
To: Hans Verkuil <hverkuil-cisco@xs4all.nl>, mchehab@kernel.org
Cc: nicolas@ndufresne.ca, shawnguo@kernel.org, robh+dt@kernel.org,
	s.hauer@pengutronix.de, kernel@pengutronix.de,
	festevam@gmail.com, linux-imx@nxp.com, xiahong.bao@nxp.com,
	eagle.zhou@nxp.com, tao.jiang_2@nxp.com, imx@lists.linux.dev,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/4] media: v4l: dev-decoder: Add source change V4L2_EVENT_SRC_CH_COLORSPACE
Date: Tue, 8 Apr 2025 16:45:03 +0800	[thread overview]
Message-ID: <c9aef3f6-43cd-48fb-8aba-0abd33c4e263@oss.nxp.com> (raw)
In-Reply-To: <d5a8988f-1038-4a8b-8478-968ceca37879@xs4all.nl>

Hi Hans,

On 2025/4/8 16:30, Hans Verkuil wrote:
> On 08/04/2025 08:34, Ming Qian(OSS) wrote:
>> Hi Hans,
>>
>> On 2025/4/7 17:54, Hans Verkuil wrote:
>>> On 17/01/2025 07:19, Ming Qian wrote:
>>>> Add a new source change V4L2_EVENT_SRC_CH_COLORSPACE that
>>>> indicates colorspace change in the stream.
>>>> The change V4L2_EVENT_SRC_CH_RESOLUTION will always affect
>>>> the allocation, but V4L2_EVENT_SRC_CH_COLORSPACE won't.
>>>>
>>>> Signed-off-by: Ming Qian <ming.qian@oss.nxp.com>
>>>> ---
>>>>    Documentation/userspace-api/media/v4l/vidioc-dqevent.rst | 9 +++++++++
>>>>    .../userspace-api/media/videodev2.h.rst.exceptions       | 1 +
>>>>    include/uapi/linux/videodev2.h                           | 1 +
>>>>    3 files changed, 11 insertions(+)
>>>>
>>>> diff --git a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
>>>> index 8db103760930..91e6b86c976d 100644
>>>> --- a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
>>>> +++ b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
>>>> @@ -369,6 +369,15 @@ call.
>>>>    	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_COLORSPACE``
>>>> +      - 0x0002
>>>> +      - This event gets triggered when a colorsapce change is detected at
>>>
>>> colorsapce -> colorspace
>>>
>>
>> Will fix in v3
>>
>>>> +	an input. This can come from a video decoder. Applications will query
>>>
>>> It can also come from a video receiver. E.g. an HDMI source changes colorspace
>>> signaling, but not the resolution.
>>>
>>>> +	the new colorspace information (if any, the signal may also have been
>>>> +	lost)
>>>
>>> Missing . at the end. Also, if the signal is lost, then that is a CH_RESOLUTION
>>> change, not CH_COLORSPACE.
>>>
>> OK, will fix in v3
>>>> +
>>>> +	For stateful decoders follow the guidelines in :ref:`decoder`.
>>>
>>> I think this should emphasize that if CH_COLORSPACE is set, but not CH_RESOLUTION,
>>> then only the colorspace changed and there is no need to reallocate buffers.
>>>
>>
>> OK, will add in v3
>>
>>> I also wonder if the description of CH_RESOLUTION should be enhanced to explain
>>> that this might also imply a colorspace change. I'm not sure what existing codec
>>> drivers do if there is a colorspace change but no resolution change.
>>
>> I think there is no uniform behavior at the moment, it depends on the
>> behavior of the decoder. Maybe most decoders ignore this.
> 
> Can you try to do a quick analysis of this? Don't spend too much time on this,
> but it is helpful to have an idea of how existing codecs handle this.
> 
> Regards,
> 
> 	Hans
> 

I checked the vpu used in our platforms,
1. amphion vpu, it will ignore the colorspace change.
2. hantro g1/g2 decoder, it also ignore the colorspace change.
3. chipsnmedia wave6 decoder, the firmware detect the colorspace change
for HEVC format, but ignore for AVC format. But its driver just ignore
it.
4. chipsnmedia wave511 decoder, same as wave6.

Regards,
Ming

>>
>>>
>>> I'm a bit concerned about backwards compatibility issues: if a userspace application
>>> doesn't understand this new flag and just honors CH_RESOLUTION, then it would
>>> never react to just a colorspace change.
>>>
>>> Nicolas, does gstreamer look at these flags?
>>
>> I checked the gstreamer code, it does check this flag:
>>
>> if (event.type == V4L2_EVENT_SOURCE_CHANGE &&
>>       (event.u.src_change.changes & V4L2_EVENT_SRC_CH_RESOLUTION)) {
>>     GST_DEBUG_OBJECT (v4l2object->dbg_obj,
>>         "Can't streamon capture as the resolution have changed.");
>>     ret = GST_V4L2_FLOW_RESOLUTION_CHANGE;
>> }
>>
>> Currently the gstreamer can't handle the CH_COLORSPACE flag.
>>
>> Thanks,
>> Ming
>>
>>>
>>> Regards,
>>>
>>> 	Hans
>>>
>>>> +
>>>>    Return Value
>>>>    ============
>>>>    
>>>> diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
>>>> index 35d3456cc812..ac47c6d9448b 100644
>>>> --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
>>>> +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
>>>> @@ -526,6 +526,7 @@ replace define V4L2_EVENT_CTRL_CH_RANGE ctrl-changes-flags
>>>>    replace define V4L2_EVENT_CTRL_CH_DIMENSIONS ctrl-changes-flags
>>>>    
>>>>    replace define V4L2_EVENT_SRC_CH_RESOLUTION src-changes-flags
>>>> +replace define V4L2_EVENT_SRC_CH_COLORSPACE src-changes-flags
>>>>    
>>>>    replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ :c:type:`v4l2_event_motion_det`
>>>>    
>>>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>>>> index c8cb2796130f..242242c8e57b 100644
>>>> --- a/include/uapi/linux/videodev2.h
>>>> +++ b/include/uapi/linux/videodev2.h
>>>> @@ -2559,6 +2559,7 @@ struct v4l2_event_frame_sync {
>>>>    };
>>>>    
>>>>    #define V4L2_EVENT_SRC_CH_RESOLUTION		(1 << 0)
>>>> +#define V4L2_EVENT_SRC_CH_COLORSPACE		(1 << 1)
>>>>    
>>>>    struct v4l2_event_src_change {
>>>>    	__u32 changes;
>>>
>>
> 

  reply	other threads:[~2025-04-08  8:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-17  6:19 [PATCH v2 1/4] media: v4l: dev-decoder: Add source change V4L2_EVENT_SRC_CH_COLORSPACE Ming Qian
2025-01-17  6:19 ` [PATCH v2 2/4] media: docs: dev-decoder: Trigger dynamic source change for colorspace Ming Qian
2025-01-17  6:19 ` [PATCH v2 3/4] media: amphion: Clear last_buffer_dequeued flag for DEC_CMD_START Ming Qian
2025-01-17  6:19 ` [PATCH v2 4/4] media: amphion: Trigger source change if colorspace chagned Ming Qian
2025-04-07  9:54 ` [PATCH v2 1/4] media: v4l: dev-decoder: Add source change V4L2_EVENT_SRC_CH_COLORSPACE Hans Verkuil
2025-04-08  6:34   ` Ming Qian(OSS)
2025-04-08  8:30     ` Hans Verkuil
2025-04-08  8:45       ` Ming Qian(OSS) [this message]
2025-04-08  9:39         ` Hans Verkuil
2025-04-08 10:09           ` Ming Qian(OSS)
2025-04-08 21:03   ` Nicolas Dufresne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c9aef3f6-43cd-48fb-8aba-0abd33c4e263@oss.nxp.com \
    --to=ming.qian@oss.nxp.com \
    --cc=eagle.zhou@nxp.com \
    --cc=festevam@gmail.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=tao.jiang_2@nxp.com \
    --cc=xiahong.bao@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox