[PATCH RFC 0/2] media: amphion: Clarify and restore V4L2_FMT_FLAG_DYN_RESOLUTION for VC1L

[PATCH RFC 0/2] media: amphion: Clarify and restore V4L2_FMT_FLAG_DYN_RESOLUTION for VC1L

[Ming Qian]

The V4L2_FMT_FLAG_DYN_RESOLUTION flag was removed from the VC1 Annex L
format in commit e670f5d672ef ("media: amphion: only insert the first
sequence startcode for vc1l format") because the amphion VPU does not
support mid-stream dynamic resolution changes for this format.

However, the flag also serves another purpose: it indicates to userspace
that the decoder will emit an initial V4L2_EVENT_SOURCE_CHANGE event
during the Initialization phase (as described in the V4L2 stateful
decoder specification, section 4.5.1.5). Without this flag, userspace
frameworks like GStreamer will not subscribe to or wait for the initial
source change event, causing the CAPTURE queue setup to fail.

This was discussed in the original patch review:
https://lore.kernel.org/lkml/7f19f803-4af4-f90d-48d5-63fc0fc780a5@xs4all.nl

The GStreamer side of the issue is tracked here:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/work_items/5126

This series:
1. Clarifies in the decoder documentation that
   V4L2_FMT_FLAG_DYN_RESOLUTION also indicates the driver will emit an
   initial source change event during initialization.
2. Restores the flag for the amphion VC1 Annex L format so that
   userspace can properly detect and wait for the initial resolution
   event.

Signed-off-by: Ming Qian <ming.qian@oss.nxp.com>
---
Ming Qian (2):
      media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage
      media: amphion: Add V4L2_FMT_FLAG_DYN_RESOLUTION for VC1L

 Documentation/userspace-api/media/v4l/dev-decoder.rst | 8 ++++++++
 drivers/media/platform/amphion/vdec.c                 | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)
---
base-commit: 06cb687a5132fcffe624c0070576ab852ac6b568
change-id: 20260608-flag-dyn-resolution-f39fd24a0ba2

[PATCH RFC 1/2] media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage

[Ming Qian]

The V4L2_FMT_FLAG_DYN_RESOLUTION flag was originally documented only in
the context of mid-stream resolution changes. However, userspace
applications (e.g. GStreamer) also rely on this flag to determine
whether the decoder will emit an initial V4L2_EVENT_SOURCE_CHANGE event
during the Initialization phase, before producing any decoded frames.

Add a note in the Initialization section to clarify that decoders
setting V4L2_FMT_FLAG_DYN_RESOLUTION will always emit an initial source
change event, allowing clients to use this flag to decide whether to
wait for the initial resolution signal.

Signed-off-by: Ming Qian <ming.qian@oss.nxp.com>
---
 Documentation/userspace-api/media/v4l/dev-decoder.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst
index 2beb6ba1b3c2..19c1912804bd 100644
--- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
+++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
@@ -361,6 +361,14 @@ Initialization
     indicated by the decoder sending a ``V4L2_EVENT_SOURCE_CHANGE`` event with
     ``changes`` set to ``V4L2_EVENT_SRC_CH_RESOLUTION``.
 
+    .. note::
+
+       Decoders that set the ``V4L2_FMT_FLAG_DYN_RESOLUTION`` flag for the
+       coded format will always emit an initial ``V4L2_EVENT_SOURCE_CHANGE``
+       event with ``V4L2_EVENT_SRC_CH_RESOLUTION`` during this phase. Clients
+       can use this flag to determine whether the decoder will signal the
+       initial resolution before producing decoded frames.
+
     * It is not an error if the first buffer does not contain enough data for
       this to occur. Processing of the buffers will continue as long as more
       data is needed.

-- 
2.54.0

[PATCH RFC 2/2] media: amphion: Add V4L2_FMT_FLAG_DYN_RESOLUTION for VC1L

[Ming Qian]

The amphion VPU decoder always emits an initial V4L2_EVENT_SOURCE_CHANGE
event after parsing the resolution from the stream header for VC1 Annex
L format. Without V4L2_FMT_FLAG_DYN_RESOLUTION, userspace (e.g.
GStreamer) cannot determine that the driver will signal the initial
resolution, causing it to skip waiting for the event and fail to set up
the CAPTURE queue properly.

Add V4L2_FMT_FLAG_DYN_RESOLUTION to the VC1 Annex L format entry to
indicate that the decoder will emit the source change event during
initialization, consistent with other coded formats supported by this
driver.

Fixes: e670f5d672ef ("media: amphion: only insert the first sequence startcode for vc1l format")
Signed-off-by: Ming Qian <ming.qian@oss.nxp.com>
---
 drivers/media/platform/amphion/vdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/amphion/vdec.c b/drivers/media/platform/amphion/vdec.c
index a9f0521f2e1a..75808482d090 100644
--- a/drivers/media/platform/amphion/vdec.c
+++ b/drivers/media/platform/amphion/vdec.c
@@ -136,7 +136,7 @@ static const struct vpu_format vdec_formats[] = {
 		.mem_planes = 1,
 		.comp_planes = 1,
 		.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
-		.flags = V4L2_FMT_FLAG_COMPRESSED
+		.flags = V4L2_FMT_FLAG_DYN_RESOLUTION | V4L2_FMT_FLAG_COMPRESSED
 	},
 	{
 		.pixfmt = V4L2_PIX_FMT_MPEG2,

-- 
2.54.0

RE: [PATCH RFC 1/2] media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage

[Ming Qian (OSS)]

>-----Original Message-----
>From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
>Sent: Monday, June 8, 2026 12:06 PM
>To: Ming Qian (OSS) <ming.qian@oss.nxp.com>
>Cc: imx@lists.linux.dev; Frank.Li@kernel.org; linux-media@vger.kernel.org
>Subject: Re: [PATCH RFC 1/2] media: docs: Clarify
>V4L2_FMT_FLAG_DYN_RESOLUTION usage
>
>Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
>to consider:
>- [High] The added documentation conflates
>`V4L2_FMT_FLAG_DYN_RESOLUTION` (which designates mid-stream dynamic
>resolution switching capability) with the mandatory initial
>`V4L2_EVENT_SOURCE_CHANGE` event. By stating "Clients can use this flag to
>determine whether the decoder will signal the initial resolution", it explicitly
>legitimizes a flawed userspace heuristic that violates the V4L2 stateful decoder
>specification. The specification mandates that for coded formats containing
>resolution info, the decoder MUST parse the stream and emit an initial
>`V4L2_EVENT_SOURCE_CHANGE` event (Initialization Step 4). Compliant drivers
>(e.g., `coda`) correctly emit this initial event but do NOT set
>`V4L2_FMT_FLAG_DYN_RESOLUTION` because they lack mid-stream switching
>capabilities. If userspace follows this documented advice, it will erroneously
>skip waiting for the initial event on these drivers, breaking Capture Setup and
>stream decoding.
>--
>
>commit ec9c0583334c246f7813132b55724e42622e8edd
>Author: Ming Qian <ming.qian@oss.nxp.com>
>
>media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage
>
>This commit updates the V4L2 stateful decoder documentation to clarify the
>usage of the V4L2_FMT_FLAG_DYN_RESOLUTION flag. It adds a note stating
>that decoders setting this flag will always emit an initial source change event.
>The documentation suggests clients can use this flag to decide whether to wait
>for the initial resolution signal.
>
>> diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst
>> b/Documentation/userspace-api/media/v4l/dev-decoder.rst
>> --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
>> +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
>> @@ -361,6 +361,14 @@ Initialization
>[ ... ]
>> +    .. note::
>> +
>> +       Decoders that set the ``V4L2_FMT_FLAG_DYN_RESOLUTION`` flag for
>the
>> +       coded format will always emit an initial
>``V4L2_EVENT_SOURCE_CHANGE``
>> +       event with ``V4L2_EVENT_SRC_CH_RESOLUTION`` during this phase.
>Clients
>> +       can use this flag to determine whether the decoder will signal the
>> +       initial resolution before producing decoded frames.
>
>[Severity: High]
>Does this guidance conflate the V4L2_FMT_FLAG_DYN_RESOLUTION flag,
>which designates mid-stream dynamic resolution switching, with the
>mandatory initial V4L2_EVENT_SOURCE_CHANGE event?
>
>The V4L2 Stateful Decoder API requires an initial
>V4L2_EVENT_SOURCE_CHANGE event during the Initialization phase for stream
>parsing, irrespective of dynamic resolution support.
>
>Compliant drivers like coda correctly emit this initial event but do not set
>V4L2_FMT_FLAG_DYN_RESOLUTION because they lack mid-stream switching
>capabilities.
>
>If userspace follows this documented advice, wouldn't it erroneously skip
>waiting for the initial event on these drivers, potentially breaking capture setup
>and stream decoding?
>
>--
>Sashiko AI review · https://sashiko.dev/#/patchset/20260608-flag-dyn-
>resolution-v1-0-44dc65516148@oss.nxp.com?part=1

Hi,

Thanks for the review.

You are right that the V4L2 stateful decoder specification states the initial V4L2_EVENT_SOURCE_CHANGE is mandatory for coded formats that contain resolution information in the stream (Initialization Step 4).

However, in practice, GStreamer's v4l2 stateful decoder implementation uses V4L2_FMT_FLAG_DYN_RESOLUTION to determine whether to subscribe and wait for the initial source change event. The reasoning from the GStreamer side, as Nicolas explained [1]:

  
"https://docs.kernel.org/userspace-api/media/v4l/dev-decoder.html#dynamic-resolution-change
    Says:
        Not all decoders can detect resolution changes. Those that do set the
        V4L2_FMT_FLAG_DYN_RESOLUTION flag.

    So normally that wording should prevent requiring an initial SRC_CH,
    or emitting later SRC_CH. Your driver don't have this flag, then your
    driver can't emit this event. But a measure we should take into
    GStreamer would be to not register (or mark) this event."

@Nicolas, could you elaborate on why GStreamer needs V4L2_FMT_FLAG_DYN_RESOLUTION to handle the initial source change event?
Is this something that should be fixed on the GStreamer side (i.e., always wait for the initial event), or is the current heuristic intentional due to legacy drivers that don't emit the event?

[1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/work_items/5126

Best regards,
Ming

Re: [PATCH RFC 1/2] media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage

[Nicolas Dufresne]

[-- Attachment #1: Type: text/plain, Size: 6817 bytes --]

Hi Ming,

Le lundi 08 juin 2026 à 06:26 +0000, Ming Qian (OSS) a écrit :
> 
> 
> > -----Original Message-----
> > From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
> > Sent: Monday, June 8, 2026 12:06 PM
> > To: Ming Qian (OSS) <ming.qian@oss.nxp.com>
> > Cc: imx@lists.linux.dev; Frank.Li@kernel.org; linux-media@vger.kernel.org
> > Subject: Re: [PATCH RFC 1/2] media: docs: Clarify
> > V4L2_FMT_FLAG_DYN_RESOLUTION usage
> > 
> > Thank you for your contribution! Sashiko AI review found 1 potential
> > issue(s)
> > to consider:
> > - [High] The added documentation conflates
> > `V4L2_FMT_FLAG_DYN_RESOLUTION` (which designates mid-stream dynamic
> > resolution switching capability) with the mandatory initial
> > `V4L2_EVENT_SOURCE_CHANGE` event. By stating "Clients can use this flag to
> > determine whether the decoder will signal the initial resolution", it
> > explicitly
> > legitimizes a flawed userspace heuristic that violates the V4L2 stateful
> > decoder
> > specification. The specification mandates that for coded formats containing
> > resolution info, the decoder MUST parse the stream and emit an initial
> > `V4L2_EVENT_SOURCE_CHANGE` event (Initialization Step 4). Compliant drivers
> > (e.g., `coda`) correctly emit this initial event but do NOT set
> > `V4L2_FMT_FLAG_DYN_RESOLUTION` because they lack mid-stream switching
> > capabilities. If userspace follows this documented advice, it will
> > erroneously
> > skip waiting for the initial event on these drivers, breaking Capture Setup
> > and
> > stream decoding.
> > --
> > 
> > commit ec9c0583334c246f7813132b55724e42622e8edd
> > Author: Ming Qian <ming.qian@oss.nxp.com>
> > 
> > media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage
> > 
> > This commit updates the V4L2 stateful decoder documentation to clarify the
> > usage of the V4L2_FMT_FLAG_DYN_RESOLUTION flag. It adds a note stating
> > that decoders setting this flag will always emit an initial source change
> > event.
> > The documentation suggests clients can use this flag to decide whether to
> > wait
> > for the initial resolution signal.
> > 
> > > diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > @@ -361,6 +361,14 @@ Initialization
> > [ ... ]
> > > +    .. note::
> > > +
> > > +       Decoders that set the ``V4L2_FMT_FLAG_DYN_RESOLUTION`` flag for
> > the
> > > +       coded format will always emit an initial
> > ``V4L2_EVENT_SOURCE_CHANGE``
> > > +       event with ``V4L2_EVENT_SRC_CH_RESOLUTION`` during this phase.
> > Clients
> > > +       can use this flag to determine whether the decoder will signal the
> > > +       initial resolution before producing decoded frames.
> > 
> > [Severity: High]
> > Does this guidance conflate the V4L2_FMT_FLAG_DYN_RESOLUTION flag,
> > which designates mid-stream dynamic resolution switching, with the
> > mandatory initial V4L2_EVENT_SOURCE_CHANGE event?
> > 
> > The V4L2 Stateful Decoder API requires an initial
> > V4L2_EVENT_SOURCE_CHANGE event during the Initialization phase for stream
> > parsing, irrespective of dynamic resolution support.
> > 
> > Compliant drivers like coda correctly emit this initial event but do not set
> > V4L2_FMT_FLAG_DYN_RESOLUTION because they lack mid-stream switching
> > capabilities.
> > 
> > If userspace follows this documented advice, wouldn't it erroneously skip
> > waiting for the initial event on these drivers, potentially breaking capture
> > setup
> > and stream decoding?
> > 
> > --
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260608-flag-dyn-
> > resolution-v1-0-44dc65516148@oss.nxp.com?part=1
> 
> Hi,
> 
> Thanks for the review.
> 
> You are right that the V4L2 stateful decoder specification states the initial
> V4L2_EVENT_SOURCE_CHANGE is mandatory for coded formats that contain
> resolution information in the stream (Initialization Step 4).

Be aware that Sashiko is an AI bot, llm words things with extreme conviction,
and it this case forget about backward compatibility from pre-spec.

> 
> However, in practice, GStreamer's v4l2 stateful decoder implementation uses
> V4L2_FMT_FLAG_DYN_RESOLUTION to determine whether to subscribe and wait for
> the initial source change event. The reasoning from the GStreamer side, as
> Nicolas explained [1]:
> 
>   
> "
> https://docs.kernel.org/userspace-api/media/v4l/dev-decoder.html#dynamic-resolu
> tion-change
>     Says:
>         Not all decoders can detect resolution changes. Those that do set the
>         V4L2_FMT_FLAG_DYN_RESOLUTION flag.
> 
>     So normally that wording should prevent requiring an initial SRC_CH,
>     or emitting later SRC_CH. Your driver don't have this flag, then your
>     driver can't emit this event. But a measure we should take into
>     GStreamer would be to not register (or mark) this event."
> 
> @Nicolas, could you elaborate on why GStreamer needs
> V4L2_FMT_FLAG_DYN_RESOLUTION to handle the initial source change event?
> Is this something that should be fixed on the GStreamer side (i.e., always
> wait for the initial event), or is the current heuristic intentional due to
> legacy drivers that don't emit the event?

The coda source_change notification is completely fake. It does not dependent on
the bitstream content. So the event is left there, since its kind of part of the
ABI, but it does not behave like other implementation, or pre-spec drivers.

So what we do in GStreamer, is that for legacy driver (no
V4L2_FMT_FLAG_DYN_RESOLUTION), we pre-allocate both queues, based on our guessed
dimensions. If it happens that the conformance windows is small enough, it often
works. DRC will only work if the display dimension changes.

For any modern driver, that implement V4L2_FMT_FLAG_DYN_RESOLUTION, we strictly
wait for the event, and on DRC, even if the display resolution changes, we let
the driver tell us when to actually reconfigure. The legacy method was kept to
not break coda and older driver, the new method is a lot more reliable, and
avoid allocating twice the capture queue (wrong guess).

The userspace implementation is also a bit more flexible, as normally the legacy
way should kind of work for any drivers, and we still subscribe it seems. But
the implication is just strange and shouldn't be needed in drivers with
V4L2_FMT_FLAG_DYN_RESOLUTION support.

Nicolas



> 
> [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/work_items/5126
> 
> Best regards,
> Ming

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH RFC 1/2] media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage

[Ming Qian(OSS)]

On Tue, Jun 09, 2026 at 02:00:02PM -0400, Nicolas Dufresne wrote:

Hi Nicolas,
> Hi Ming,
> 
> Le lundi 08 juin 2026 à 06:26 +0000, Ming Qian (OSS) a écrit :
> > 
> > 
> > > -----Original Message-----
> > > From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
> > > Sent: Monday, June 8, 2026 12:06 PM
> > > To: Ming Qian (OSS) <ming.qian@oss.nxp.com>
> > > Cc: imx@lists.linux.dev; Frank.Li@kernel.org; linux-media@vger.kernel.org
> > > Subject: Re: [PATCH RFC 1/2] media: docs: Clarify
> > > V4L2_FMT_FLAG_DYN_RESOLUTION usage
> > > 
> > > Thank you for your contribution! Sashiko AI review found 1 potential
> > > issue(s)
> > > to consider:
> > > - [High] The added documentation conflates
> > > `V4L2_FMT_FLAG_DYN_RESOLUTION` (which designates mid-stream dynamic
> > > resolution switching capability) with the mandatory initial
> > > `V4L2_EVENT_SOURCE_CHANGE` event. By stating "Clients can use this flag to
> > > determine whether the decoder will signal the initial resolution", it
> > > explicitly
> > > legitimizes a flawed userspace heuristic that violates the V4L2 stateful
> > > decoder
> > > specification. The specification mandates that for coded formats containing
> > > resolution info, the decoder MUST parse the stream and emit an initial
> > > `V4L2_EVENT_SOURCE_CHANGE` event (Initialization Step 4). Compliant drivers
> > > (e.g., `coda`) correctly emit this initial event but do NOT set
> > > `V4L2_FMT_FLAG_DYN_RESOLUTION` because they lack mid-stream switching
> > > capabilities. If userspace follows this documented advice, it will
> > > erroneously
> > > skip waiting for the initial event on these drivers, breaking Capture Setup
> > > and
> > > stream decoding.
> > > --
> > > 
> > > commit ec9c0583334c246f7813132b55724e42622e8edd
> > > Author: Ming Qian <ming.qian@oss.nxp.com>
> > > 
> > > media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage
> > > 
> > > This commit updates the V4L2 stateful decoder documentation to clarify the
> > > usage of the V4L2_FMT_FLAG_DYN_RESOLUTION flag. It adds a note stating
> > > that decoders setting this flag will always emit an initial source change
> > > event.
> > > The documentation suggests clients can use this flag to decide whether to
> > > wait
> > > for the initial resolution signal.
> > > 
> > > > diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > @@ -361,6 +361,14 @@ Initialization
> > > [ ... ]
> > > > +    .. note::
> > > > +
> > > > +       Decoders that set the ``V4L2_FMT_FLAG_DYN_RESOLUTION`` flag for
> > > the
> > > > +       coded format will always emit an initial
> > > ``V4L2_EVENT_SOURCE_CHANGE``
> > > > +       event with ``V4L2_EVENT_SRC_CH_RESOLUTION`` during this phase.
> > > Clients
> > > > +       can use this flag to determine whether the decoder will signal the
> > > > +       initial resolution before producing decoded frames.
> > > 
> > > [Severity: High]
> > > Does this guidance conflate the V4L2_FMT_FLAG_DYN_RESOLUTION flag,
> > > which designates mid-stream dynamic resolution switching, with the
> > > mandatory initial V4L2_EVENT_SOURCE_CHANGE event?
> > > 
> > > The V4L2 Stateful Decoder API requires an initial
> > > V4L2_EVENT_SOURCE_CHANGE event during the Initialization phase for stream
> > > parsing, irrespective of dynamic resolution support.
> > > 
> > > Compliant drivers like coda correctly emit this initial event but do not set
> > > V4L2_FMT_FLAG_DYN_RESOLUTION because they lack mid-stream switching
> > > capabilities.
> > > 
> > > If userspace follows this documented advice, wouldn't it erroneously skip
> > > waiting for the initial event on these drivers, potentially breaking capture
> > > setup
> > > and stream decoding?
> > > 
> > > --
> > > Sashiko AI review · https://sashiko.dev/#/patchset/20260608-flag-dyn-
> > > resolution-v1-0-44dc65516148@oss.nxp.com?part=1
> > 
> > Hi,
> > 
> > Thanks for the review.
> > 
> > You are right that the V4L2 stateful decoder specification states the initial
> > V4L2_EVENT_SOURCE_CHANGE is mandatory for coded formats that contain
> > resolution information in the stream (Initialization Step 4).
> 
> Be aware that Sashiko is an AI bot, llm words things with extreme conviction,
> and it this case forget about backward compatibility from pre-spec.
> 
> > 
> > However, in practice, GStreamer's v4l2 stateful decoder implementation uses
> > V4L2_FMT_FLAG_DYN_RESOLUTION to determine whether to subscribe and wait for
> > the initial source change event. The reasoning from the GStreamer side, as
> > Nicolas explained [1]:
> > 
> >   
> > "
> > https://docs.kernel.org/userspace-api/media/v4l/dev-decoder.html#dynamic-resolu
> > tion-change
> >     Says:
> >         Not all decoders can detect resolution changes. Those that do set the
> >         V4L2_FMT_FLAG_DYN_RESOLUTION flag.
> > 
> >     So normally that wording should prevent requiring an initial SRC_CH,
> >     or emitting later SRC_CH. Your driver don't have this flag, then your
> >     driver can't emit this event. But a measure we should take into
> >     GStreamer would be to not register (or mark) this event."
> > 
> > @Nicolas, could you elaborate on why GStreamer needs
> > V4L2_FMT_FLAG_DYN_RESOLUTION to handle the initial source change event?
> > Is this something that should be fixed on the GStreamer side (i.e., always
> > wait for the initial event), or is the current heuristic intentional due to
> > legacy drivers that don't emit the event?
> 
> The coda source_change notification is completely fake. It does not dependent on
> the bitstream content. So the event is left there, since its kind of part of the
> ABI, but it does not behave like other implementation, or pre-spec drivers.
> 
> So what we do in GStreamer, is that for legacy driver (no
> V4L2_FMT_FLAG_DYN_RESOLUTION), we pre-allocate both queues, based on our guessed
> dimensions. If it happens that the conformance windows is small enough, it often
> works. DRC will only work if the display dimension changes.
> 
> For any modern driver, that implement V4L2_FMT_FLAG_DYN_RESOLUTION, we strictly
> wait for the event, and on DRC, even if the display resolution changes, we let
> the driver tell us when to actually reconfigure. The legacy method was kept to
> not break coda and older driver, the new method is a lot more reliable, and
> avoid allocating twice the capture queue (wrong guess).
> 
> The userspace implementation is also a bit more flexible, as normally the legacy
> way should kind of work for any drivers, and we still subscribe it seems. But
> the implication is just strange and shouldn't be needed in drivers with
> V4L2_FMT_FLAG_DYN_RESOLUTION support.
> 
> Nicolas
> 
> 

Thanks for the detailed explanation of GStreamer's approach.

I have a couple of follow-up questions:

1. Regarding coda's source change being "completely fake":

   Looking at the coda driver code, its seq_init_work does parse the
   bitstream via hardware (SEQ_INIT command), and the source change event
   is only emitted after ctx->initialized is set — which requires the
   hardware to successfully parse the stream headers. After the event,
   userspace can call G_SELECTION to retrieve the actual display crop
   rectangle parsed from the bitstream.

   The limitation is that coda requires userspace to set a sufficiently
   large resolution via S_FMT(OUTPUT) beforehand (since it validates
   stream dimensions fit within the pre-configured buffer size rather
   than updating G_FMT with parsed dimensions). But the event itself
   does depend on bitstream content and carries useful information
   (visible resolution via selection API).

   So it seems coda could work with the standard init flow — the source
   change event is real, just the information delivery is partial (crop
   via G_SELECTION rather than full coded resolution via G_FMT). Would
   you agree, or is there another reason GStreamer treats it as legacy?

2. Regarding s5p-mfc:

   Interestingly, s5p-mfc sets V4L2_FMT_FLAG_DYN_RESOLUTION but does
   NOT emit an initial source change event. After SEQ_DONE, it simply
   transitions to MFCINST_HEAD_PARSED state and wakes up waiters —
   userspace discovers the resolution by calling G_FMT(CAPTURE) which
   internally blocks until header parsing completes.

   The source change event is only emitted during mid-stream resolution
   changes (RES_CHANGE_FLUSH path). How does GStreamer handle this case?
   Does it timeout waiting for the initial event and fall back, or does
   it use some other mechanism?

Overall, I agree that using V4L2_FMT_FLAG_DYN_RESOLUTION to unify the
behavior (both initial source change and mid-stream DRC) is the right
direction. But the current state has some inconsistencies:

  - coda: emits initial source change, but does NOT set DYN_RESOLUTION
  - s5p-mfc: sets DYN_RESOLUTION, but does NOT emit initial source change

If we want to document that "DYN_RESOLUTION implies initial source change
event will be emitted", s5p-mfc would need to be fixed to comply. Does
that seem reasonable, or should we take a different approach?

Regards,
Ming

> 
> > 
> > [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/work_items/5126
> > 
> > Best regards,
> > Ming

Re: [PATCH RFC 1/2] media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage

[Ming Qian(OSS)]

On Wed, Jun 10, 2026 at 11:49:06AM +0900, Ming Qian(OSS) wrote:
> On Tue, Jun 09, 2026 at 02:00:02PM -0400, Nicolas Dufresne wrote:
> 
> Hi Nicolas,

> > Hi Ming,
> > 
> > Le lundi 08 juin 2026 à 06:26 +0000, Ming Qian (OSS) a écrit :
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
> > > > Sent: Monday, June 8, 2026 12:06 PM
> > > > To: Ming Qian (OSS) <ming.qian@oss.nxp.com>
> > > > Cc: imx@lists.linux.dev; Frank.Li@kernel.org; linux-media@vger.kernel.org
> > > > Subject: Re: [PATCH RFC 1/2] media: docs: Clarify
> > > > V4L2_FMT_FLAG_DYN_RESOLUTION usage
> > > > 
> > > > Thank you for your contribution! Sashiko AI review found 1 potential
> > > > issue(s)
> > > > to consider:
> > > > - [High] The added documentation conflates
> > > > `V4L2_FMT_FLAG_DYN_RESOLUTION` (which designates mid-stream dynamic
> > > > resolution switching capability) with the mandatory initial
> > > > `V4L2_EVENT_SOURCE_CHANGE` event. By stating "Clients can use this flag to
> > > > determine whether the decoder will signal the initial resolution", it
> > > > explicitly
> > > > legitimizes a flawed userspace heuristic that violates the V4L2 stateful
> > > > decoder
> > > > specification. The specification mandates that for coded formats containing
> > > > resolution info, the decoder MUST parse the stream and emit an initial
> > > > `V4L2_EVENT_SOURCE_CHANGE` event (Initialization Step 4). Compliant drivers
> > > > (e.g., `coda`) correctly emit this initial event but do NOT set
> > > > `V4L2_FMT_FLAG_DYN_RESOLUTION` because they lack mid-stream switching
> > > > capabilities. If userspace follows this documented advice, it will
> > > > erroneously
> > > > skip waiting for the initial event on these drivers, breaking Capture Setup
> > > > and
> > > > stream decoding.
> > > > --
> > > > 
> > > > commit ec9c0583334c246f7813132b55724e42622e8edd
> > > > Author: Ming Qian <ming.qian@oss.nxp.com>
> > > > 
> > > > media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage
> > > > 
> > > > This commit updates the V4L2 stateful decoder documentation to clarify the
> > > > usage of the V4L2_FMT_FLAG_DYN_RESOLUTION flag. It adds a note stating
> > > > that decoders setting this flag will always emit an initial source change
> > > > event.
> > > > The documentation suggests clients can use this flag to decide whether to
> > > > wait
> > > > for the initial resolution signal.
> > > > 
> > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > @@ -361,6 +361,14 @@ Initialization
> > > > [ ... ]
> > > > > +    .. note::
> > > > > +
> > > > > +       Decoders that set the ``V4L2_FMT_FLAG_DYN_RESOLUTION`` flag for
> > > > the
> > > > > +       coded format will always emit an initial
> > > > ``V4L2_EVENT_SOURCE_CHANGE``
> > > > > +       event with ``V4L2_EVENT_SRC_CH_RESOLUTION`` during this phase.
> > > > Clients
> > > > > +       can use this flag to determine whether the decoder will signal the
> > > > > +       initial resolution before producing decoded frames.
> > > > 
> > > > [Severity: High]
> > > > Does this guidance conflate the V4L2_FMT_FLAG_DYN_RESOLUTION flag,
> > > > which designates mid-stream dynamic resolution switching, with the
> > > > mandatory initial V4L2_EVENT_SOURCE_CHANGE event?
> > > > 
> > > > The V4L2 Stateful Decoder API requires an initial
> > > > V4L2_EVENT_SOURCE_CHANGE event during the Initialization phase for stream
> > > > parsing, irrespective of dynamic resolution support.
> > > > 
> > > > Compliant drivers like coda correctly emit this initial event but do not set
> > > > V4L2_FMT_FLAG_DYN_RESOLUTION because they lack mid-stream switching
> > > > capabilities.
> > > > 
> > > > If userspace follows this documented advice, wouldn't it erroneously skip
> > > > waiting for the initial event on these drivers, potentially breaking capture
> > > > setup
> > > > and stream decoding?
> > > > 
> > > > --
> > > > Sashiko AI review · https://sashiko.dev/#/patchset/20260608-flag-dyn-
> > > > resolution-v1-0-44dc65516148@oss.nxp.com?part=1
> > > 
> > > Hi,
> > > 
> > > Thanks for the review.
> > > 
> > > You are right that the V4L2 stateful decoder specification states the initial
> > > V4L2_EVENT_SOURCE_CHANGE is mandatory for coded formats that contain
> > > resolution information in the stream (Initialization Step 4).
> > 
> > Be aware that Sashiko is an AI bot, llm words things with extreme conviction,
> > and it this case forget about backward compatibility from pre-spec.
> > 
> > > 
> > > However, in practice, GStreamer's v4l2 stateful decoder implementation uses
> > > V4L2_FMT_FLAG_DYN_RESOLUTION to determine whether to subscribe and wait for
> > > the initial source change event. The reasoning from the GStreamer side, as
> > > Nicolas explained [1]:
> > > 
> > >   
> > > "
> > > https://docs.kernel.org/userspace-api/media/v4l/dev-decoder.html#dynamic-resolu
> > > tion-change
> > >     Says:
> > >         Not all decoders can detect resolution changes. Those that do set the
> > >         V4L2_FMT_FLAG_DYN_RESOLUTION flag.
> > > 
> > >     So normally that wording should prevent requiring an initial SRC_CH,
> > >     or emitting later SRC_CH. Your driver don't have this flag, then your
> > >     driver can't emit this event. But a measure we should take into
> > >     GStreamer would be to not register (or mark) this event."
> > > 
> > > @Nicolas, could you elaborate on why GStreamer needs
> > > V4L2_FMT_FLAG_DYN_RESOLUTION to handle the initial source change event?
> > > Is this something that should be fixed on the GStreamer side (i.e., always
> > > wait for the initial event), or is the current heuristic intentional due to
> > > legacy drivers that don't emit the event?
> > 
> > The coda source_change notification is completely fake. It does not dependent on
> > the bitstream content. So the event is left there, since its kind of part of the
> > ABI, but it does not behave like other implementation, or pre-spec drivers.
> > 
> > So what we do in GStreamer, is that for legacy driver (no
> > V4L2_FMT_FLAG_DYN_RESOLUTION), we pre-allocate both queues, based on our guessed
> > dimensions. If it happens that the conformance windows is small enough, it often
> > works. DRC will only work if the display dimension changes.
> > 
> > For any modern driver, that implement V4L2_FMT_FLAG_DYN_RESOLUTION, we strictly
> > wait for the event, and on DRC, even if the display resolution changes, we let
> > the driver tell us when to actually reconfigure. The legacy method was kept to
> > not break coda and older driver, the new method is a lot more reliable, and
> > avoid allocating twice the capture queue (wrong guess).
> > 
> > The userspace implementation is also a bit more flexible, as normally the legacy
> > way should kind of work for any drivers, and we still subscribe it seems. But
> > the implication is just strange and shouldn't be needed in drivers with
> > V4L2_FMT_FLAG_DYN_RESOLUTION support.
> > 
> > Nicolas
> > 
> > 
> 
> Thanks for the detailed explanation of GStreamer's approach.
> 
> I have a couple of follow-up questions:
> 
> 1. Regarding coda's source change being "completely fake":
> 
>    Looking at the coda driver code, its seq_init_work does parse the
>    bitstream via hardware (SEQ_INIT command), and the source change event
>    is only emitted after ctx->initialized is set — which requires the
>    hardware to successfully parse the stream headers. After the event,
>    userspace can call G_SELECTION to retrieve the actual display crop
>    rectangle parsed from the bitstream.
> 
>    The limitation is that coda requires userspace to set a sufficiently
>    large resolution via S_FMT(OUTPUT) beforehand (since it validates
>    stream dimensions fit within the pre-configured buffer size rather
>    than updating G_FMT with parsed dimensions). But the event itself
>    does depend on bitstream content and carries useful information
>    (visible resolution via selection API).
> 
>    So it seems coda could work with the standard init flow — the source
>    change event is real, just the information delivery is partial (crop
>    via G_SELECTION rather than full coded resolution via G_FMT). Would
>    you agree, or is there another reason GStreamer treats it as legacy?
> 
> 2. Regarding s5p-mfc:
> 
>    Interestingly, s5p-mfc sets V4L2_FMT_FLAG_DYN_RESOLUTION but does
>    NOT emit an initial source change event. After SEQ_DONE, it simply
>    transitions to MFCINST_HEAD_PARSED state and wakes up waiters —
>    userspace discovers the resolution by calling G_FMT(CAPTURE) which
>    internally blocks until header parsing completes.
> 
>    The source change event is only emitted during mid-stream resolution
>    changes (RES_CHANGE_FLUSH path). How does GStreamer handle this case?
>    Does it timeout waiting for the initial event and fall back, or does
>    it use some other mechanism?
> 
> Overall, I agree that using V4L2_FMT_FLAG_DYN_RESOLUTION to unify the
> behavior (both initial source change and mid-stream DRC) is the right
> direction. But the current state has some inconsistencies:
> 
>   - coda: emits initial source change, but does NOT set DYN_RESOLUTION
>   - s5p-mfc: sets DYN_RESOLUTION, but does NOT emit initial source change
> 
> If we want to document that "DYN_RESOLUTION implies initial source change
> event will be emitted", s5p-mfc would need to be fixed to comply. Does
> that seem reasonable, or should we take a different approach?

Hi,

I'd like to follow up with a correction regarding the s5p-mfc driver.

I apologize for the confusion in my earlier analysis. The s5p-mfc driver
does define V4L2_FMT_FLAG_DYN_RESOLUTION in its internal formats[]
table. However, the vidioc_enum_fmt() implementation never copies these
flags to userspace:

  f->pixelformat = formats[i].fourcc;
  return 0;  /* f->flags is never set! */

This is a bug - from userspace's perspective, VIDIOC_ENUM_FMT always
returns flags = 0, which is why GStreamer treats s5p-mfc via the legacy
path.

Looking at the driver's actual behavior:

- Initial resolution: After header parsing, the driver wakes up the
  waiting context but does not send V4L2_EVENT_SOURCE_CHANGE. Userspace
  discovers the resolution by calling G_FMT after STREAMON.

- Mid-stream resolution change: The driver does send
  V4L2_EVENT_SOURCE_CHANGE with V4L2_EVENT_SRC_CH_RESOLUTION.

So if V4L2_FMT_FLAG_DYN_RESOLUTION is defined to cover both initial and
mid-stream resolution changes:

- It should not set the flag - because it doesn't fire the event for
  initial resolution.
- It should set the flag - because it supports mid-stream DRC via the
  event.

Neither setting nor clearing the flag accurately describes the driver's
current behavior.

The more natural fix would be to add V4L2_EVENT_SOURCE_CHANGE for the
initial resolution case as well, then properly report
V4L2_FMT_FLAG_DYN_RESOLUTION through VIDIOC_ENUM_FMT. If all existing
drivers that support mid-stream DRC can similarly be updated to fire the
event for initial resolution, then perhaps the spec change to split the
flag isn't strictly necessary - drivers just need to be fixed to comply
with the current definition.

I'd appreciate hearing others' thoughts on whether this unified approach
is practical across all existing drivers.

Best regards,
Ming

> 
> Regards,
> Ming
> 
> > 
> > > 
> > > [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/work_items/5126
> > > 
> > > Best regards,
> > > Ming
> 
> 
> 

Re: [PATCH RFC 1/2] media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage

[Hans Verkuil]

On 10/06/2026 05:36, Ming Qian(OSS) wrote:
> On Wed, Jun 10, 2026 at 11:49:06AM +0900, Ming Qian(OSS) wrote:
>> On Tue, Jun 09, 2026 at 02:00:02PM -0400, Nicolas Dufresne wrote:
>>
>> Hi Nicolas,
> 
>>> Hi Ming,
>>>
>>> Le lundi 08 juin 2026 à 06:26 +0000, Ming Qian (OSS) a écrit :
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
>>>>> Sent: Monday, June 8, 2026 12:06 PM
>>>>> To: Ming Qian (OSS) <ming.qian@oss.nxp.com>
>>>>> Cc: imx@lists.linux.dev; Frank.Li@kernel.org; linux-media@vger.kernel.org
>>>>> Subject: Re: [PATCH RFC 1/2] media: docs: Clarify
>>>>> V4L2_FMT_FLAG_DYN_RESOLUTION usage
>>>>>
>>>>> Thank you for your contribution! Sashiko AI review found 1 potential
>>>>> issue(s)
>>>>> to consider:
>>>>> - [High] The added documentation conflates
>>>>> `V4L2_FMT_FLAG_DYN_RESOLUTION` (which designates mid-stream dynamic
>>>>> resolution switching capability) with the mandatory initial
>>>>> `V4L2_EVENT_SOURCE_CHANGE` event. By stating "Clients can use this flag to
>>>>> determine whether the decoder will signal the initial resolution", it
>>>>> explicitly
>>>>> legitimizes a flawed userspace heuristic that violates the V4L2 stateful
>>>>> decoder
>>>>> specification. The specification mandates that for coded formats containing
>>>>> resolution info, the decoder MUST parse the stream and emit an initial
>>>>> `V4L2_EVENT_SOURCE_CHANGE` event (Initialization Step 4). Compliant drivers
>>>>> (e.g., `coda`) correctly emit this initial event but do NOT set
>>>>> `V4L2_FMT_FLAG_DYN_RESOLUTION` because they lack mid-stream switching
>>>>> capabilities. If userspace follows this documented advice, it will
>>>>> erroneously
>>>>> skip waiting for the initial event on these drivers, breaking Capture Setup
>>>>> and
>>>>> stream decoding.
>>>>> --
>>>>>
>>>>> commit ec9c0583334c246f7813132b55724e42622e8edd
>>>>> Author: Ming Qian <ming.qian@oss.nxp.com>
>>>>>
>>>>> media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage
>>>>>
>>>>> This commit updates the V4L2 stateful decoder documentation to clarify the
>>>>> usage of the V4L2_FMT_FLAG_DYN_RESOLUTION flag. It adds a note stating
>>>>> that decoders setting this flag will always emit an initial source change
>>>>> event.
>>>>> The documentation suggests clients can use this flag to decide whether to
>>>>> wait
>>>>> for the initial resolution signal.
>>>>>
>>>>>> diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst
>>>>>> b/Documentation/userspace-api/media/v4l/dev-decoder.rst
>>>>>> --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
>>>>>> +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
>>>>>> @@ -361,6 +361,14 @@ Initialization
>>>>> [ ... ]
>>>>>> +    .. note::
>>>>>> +
>>>>>> +       Decoders that set the ``V4L2_FMT_FLAG_DYN_RESOLUTION`` flag for
>>>>> the
>>>>>> +       coded format will always emit an initial
>>>>> ``V4L2_EVENT_SOURCE_CHANGE``
>>>>>> +       event with ``V4L2_EVENT_SRC_CH_RESOLUTION`` during this phase.
>>>>> Clients
>>>>>> +       can use this flag to determine whether the decoder will signal the
>>>>>> +       initial resolution before producing decoded frames.
>>>>>
>>>>> [Severity: High]
>>>>> Does this guidance conflate the V4L2_FMT_FLAG_DYN_RESOLUTION flag,
>>>>> which designates mid-stream dynamic resolution switching, with the
>>>>> mandatory initial V4L2_EVENT_SOURCE_CHANGE event?
>>>>>
>>>>> The V4L2 Stateful Decoder API requires an initial
>>>>> V4L2_EVENT_SOURCE_CHANGE event during the Initialization phase for stream
>>>>> parsing, irrespective of dynamic resolution support.
>>>>>
>>>>> Compliant drivers like coda correctly emit this initial event but do not set
>>>>> V4L2_FMT_FLAG_DYN_RESOLUTION because they lack mid-stream switching
>>>>> capabilities.
>>>>>
>>>>> If userspace follows this documented advice, wouldn't it erroneously skip
>>>>> waiting for the initial event on these drivers, potentially breaking capture
>>>>> setup
>>>>> and stream decoding?
>>>>>
>>>>> --
>>>>> Sashiko AI review · https://sashiko.dev/#/patchset/20260608-flag-dyn-
>>>>> resolution-v1-0-44dc65516148@oss.nxp.com?part=1
>>>>
>>>> Hi,
>>>>
>>>> Thanks for the review.
>>>>
>>>> You are right that the V4L2 stateful decoder specification states the initial
>>>> V4L2_EVENT_SOURCE_CHANGE is mandatory for coded formats that contain
>>>> resolution information in the stream (Initialization Step 4).
>>>
>>> Be aware that Sashiko is an AI bot, llm words things with extreme conviction,
>>> and it this case forget about backward compatibility from pre-spec.
>>>
>>>>
>>>> However, in practice, GStreamer's v4l2 stateful decoder implementation uses
>>>> V4L2_FMT_FLAG_DYN_RESOLUTION to determine whether to subscribe and wait for
>>>> the initial source change event. The reasoning from the GStreamer side, as
>>>> Nicolas explained [1]:
>>>>
>>>>   
>>>> "
>>>> https://docs.kernel.org/userspace-api/media/v4l/dev-decoder.html#dynamic-resolu
>>>> tion-change
>>>>     Says:
>>>>         Not all decoders can detect resolution changes. Those that do set the
>>>>         V4L2_FMT_FLAG_DYN_RESOLUTION flag.
>>>>
>>>>     So normally that wording should prevent requiring an initial SRC_CH,
>>>>     or emitting later SRC_CH. Your driver don't have this flag, then your
>>>>     driver can't emit this event. But a measure we should take into
>>>>     GStreamer would be to not register (or mark) this event."
>>>>
>>>> @Nicolas, could you elaborate on why GStreamer needs
>>>> V4L2_FMT_FLAG_DYN_RESOLUTION to handle the initial source change event?
>>>> Is this something that should be fixed on the GStreamer side (i.e., always
>>>> wait for the initial event), or is the current heuristic intentional due to
>>>> legacy drivers that don't emit the event?
>>>
>>> The coda source_change notification is completely fake. It does not dependent on
>>> the bitstream content. So the event is left there, since its kind of part of the
>>> ABI, but it does not behave like other implementation, or pre-spec drivers.
>>>
>>> So what we do in GStreamer, is that for legacy driver (no
>>> V4L2_FMT_FLAG_DYN_RESOLUTION), we pre-allocate both queues, based on our guessed
>>> dimensions. If it happens that the conformance windows is small enough, it often
>>> works. DRC will only work if the display dimension changes.
>>>
>>> For any modern driver, that implement V4L2_FMT_FLAG_DYN_RESOLUTION, we strictly
>>> wait for the event, and on DRC, even if the display resolution changes, we let
>>> the driver tell us when to actually reconfigure. The legacy method was kept to
>>> not break coda and older driver, the new method is a lot more reliable, and
>>> avoid allocating twice the capture queue (wrong guess).
>>>
>>> The userspace implementation is also a bit more flexible, as normally the legacy
>>> way should kind of work for any drivers, and we still subscribe it seems. But
>>> the implication is just strange and shouldn't be needed in drivers with
>>> V4L2_FMT_FLAG_DYN_RESOLUTION support.
>>>
>>> Nicolas
>>>
>>>
>>
>> Thanks for the detailed explanation of GStreamer's approach.
>>
>> I have a couple of follow-up questions:
>>
>> 1. Regarding coda's source change being "completely fake":
>>
>>    Looking at the coda driver code, its seq_init_work does parse the
>>    bitstream via hardware (SEQ_INIT command), and the source change event
>>    is only emitted after ctx->initialized is set — which requires the
>>    hardware to successfully parse the stream headers. After the event,
>>    userspace can call G_SELECTION to retrieve the actual display crop
>>    rectangle parsed from the bitstream.
>>
>>    The limitation is that coda requires userspace to set a sufficiently
>>    large resolution via S_FMT(OUTPUT) beforehand (since it validates
>>    stream dimensions fit within the pre-configured buffer size rather
>>    than updating G_FMT with parsed dimensions). But the event itself
>>    does depend on bitstream content and carries useful information
>>    (visible resolution via selection API).
>>
>>    So it seems coda could work with the standard init flow — the source
>>    change event is real, just the information delivery is partial (crop
>>    via G_SELECTION rather than full coded resolution via G_FMT). Would
>>    you agree, or is there another reason GStreamer treats it as legacy?
>>
>> 2. Regarding s5p-mfc:
>>
>>    Interestingly, s5p-mfc sets V4L2_FMT_FLAG_DYN_RESOLUTION but does
>>    NOT emit an initial source change event. After SEQ_DONE, it simply
>>    transitions to MFCINST_HEAD_PARSED state and wakes up waiters —
>>    userspace discovers the resolution by calling G_FMT(CAPTURE) which
>>    internally blocks until header parsing completes.
>>
>>    The source change event is only emitted during mid-stream resolution
>>    changes (RES_CHANGE_FLUSH path). How does GStreamer handle this case?
>>    Does it timeout waiting for the initial event and fall back, or does
>>    it use some other mechanism?
>>
>> Overall, I agree that using V4L2_FMT_FLAG_DYN_RESOLUTION to unify the
>> behavior (both initial source change and mid-stream DRC) is the right
>> direction. But the current state has some inconsistencies:
>>
>>   - coda: emits initial source change, but does NOT set DYN_RESOLUTION
>>   - s5p-mfc: sets DYN_RESOLUTION, but does NOT emit initial source change
>>
>> If we want to document that "DYN_RESOLUTION implies initial source change
>> event will be emitted", s5p-mfc would need to be fixed to comply. Does
>> that seem reasonable, or should we take a different approach?
> 
> Hi,
> 
> I'd like to follow up with a correction regarding the s5p-mfc driver.
> 
> I apologize for the confusion in my earlier analysis. The s5p-mfc driver
> does define V4L2_FMT_FLAG_DYN_RESOLUTION in its internal formats[]
> table. However, the vidioc_enum_fmt() implementation never copies these
> flags to userspace:
> 
>   f->pixelformat = formats[i].fourcc;
>   return 0;  /* f->flags is never set! */
> 
> This is a bug - from userspace's perspective, VIDIOC_ENUM_FMT always
> returns flags = 0, which is why GStreamer treats s5p-mfc via the legacy
> path.
> 
> Looking at the driver's actual behavior:
> 
> - Initial resolution: After header parsing, the driver wakes up the
>   waiting context but does not send V4L2_EVENT_SOURCE_CHANGE. Userspace
>   discovers the resolution by calling G_FMT after STREAMON.
> 
> - Mid-stream resolution change: The driver does send
>   V4L2_EVENT_SOURCE_CHANGE with V4L2_EVENT_SRC_CH_RESOLUTION.
> 
> So if V4L2_FMT_FLAG_DYN_RESOLUTION is defined to cover both initial and
> mid-stream resolution changes:
> 
> - It should not set the flag - because it doesn't fire the event for
>   initial resolution.
> - It should set the flag - because it supports mid-stream DRC via the
>   event.
> 
> Neither setting nor clearing the flag accurately describes the driver's
> current behavior.
> 
> The more natural fix would be to add V4L2_EVENT_SOURCE_CHANGE for the
> initial resolution case as well, then properly report
> V4L2_FMT_FLAG_DYN_RESOLUTION through VIDIOC_ENUM_FMT. If all existing
> drivers that support mid-stream DRC can similarly be updated to fire the
> event for initial resolution, then perhaps the spec change to split the
> flag isn't strictly necessary - drivers just need to be fixed to comply
> with the current definition.
> 
> I'd appreciate hearing others' thoughts on whether this unified approach
> is practical across all existing drivers.

Just a quick reply to mention that the s5p-mfc driver predates a lot of the
newer uAPIs for stateful codecs. It's why it behaves in a not-quite-standard
way. So there is history here. The resolution change support was added in
commit 0520e4cc3bb9d back in 2014, three years after the driver was first
added to the kernel. The stateful decoder spec as we have today was only
introduced in 2019.

Regards,

	Hans

> 
> Best regards,
> Ming
> 
>>
>> Regards,
>> Ming
>>
>>>
>>>>
>>>> [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/work_items/5126
>>>>
>>>> Best regards,
>>>> Ming
>>
>>
>>
> 

Re: [PATCH RFC 1/2] media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage

[Nicolas Dufresne]

[-- Attachment #1: Type: text/plain, Size: 11522 bytes --]

Le mercredi 10 juin 2026 à 11:49 +0900, Ming Qian(OSS) a écrit :
> On Tue, Jun 09, 2026 at 02:00:02PM -0400, Nicolas Dufresne wrote:
> 
> Hi Nicolas,
> > Hi Ming,
> > 
> > Le lundi 08 juin 2026 à 06:26 +0000, Ming Qian (OSS) a écrit :
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
> > > > Sent: Monday, June 8, 2026 12:06 PM
> > > > To: Ming Qian (OSS) <ming.qian@oss.nxp.com>
> > > > Cc: imx@lists.linux.dev; Frank.Li@kernel.org; linux-media@vger.kernel.org
> > > > Subject: Re: [PATCH RFC 1/2] media: docs: Clarify
> > > > V4L2_FMT_FLAG_DYN_RESOLUTION usage
> > > > 
> > > > Thank you for your contribution! Sashiko AI review found 1 potential
> > > > issue(s)
> > > > to consider:
> > > > - [High] The added documentation conflates
> > > > `V4L2_FMT_FLAG_DYN_RESOLUTION` (which designates mid-stream dynamic
> > > > resolution switching capability) with the mandatory initial
> > > > `V4L2_EVENT_SOURCE_CHANGE` event. By stating "Clients can use this flag to
> > > > determine whether the decoder will signal the initial resolution", it
> > > > explicitly
> > > > legitimizes a flawed userspace heuristic that violates the V4L2 stateful
> > > > decoder
> > > > specification. The specification mandates that for coded formats containing
> > > > resolution info, the decoder MUST parse the stream and emit an initial
> > > > `V4L2_EVENT_SOURCE_CHANGE` event (Initialization Step 4). Compliant drivers
> > > > (e.g., `coda`) correctly emit this initial event but do NOT set
> > > > `V4L2_FMT_FLAG_DYN_RESOLUTION` because they lack mid-stream switching
> > > > capabilities. If userspace follows this documented advice, it will
> > > > erroneously
> > > > skip waiting for the initial event on these drivers, breaking Capture Setup
> > > > and
> > > > stream decoding.
> > > > --
> > > > 
> > > > commit ec9c0583334c246f7813132b55724e42622e8edd
> > > > Author: Ming Qian <ming.qian@oss.nxp.com>
> > > > 
> > > > media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage
> > > > 
> > > > This commit updates the V4L2 stateful decoder documentation to clarify the
> > > > usage of the V4L2_FMT_FLAG_DYN_RESOLUTION flag. It adds a note stating
> > > > that decoders setting this flag will always emit an initial source change
> > > > event.
> > > > The documentation suggests clients can use this flag to decide whether to
> > > > wait
> > > > for the initial resolution signal.
> > > > 
> > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > @@ -361,6 +361,14 @@ Initialization
> > > > [ ... ]
> > > > > +    .. note::
> > > > > +
> > > > > +       Decoders that set the ``V4L2_FMT_FLAG_DYN_RESOLUTION`` flag for
> > > > the
> > > > > +       coded format will always emit an initial
> > > > ``V4L2_EVENT_SOURCE_CHANGE``
> > > > > +       event with ``V4L2_EVENT_SRC_CH_RESOLUTION`` during this phase.
> > > > Clients
> > > > > +       can use this flag to determine whether the decoder will signal the
> > > > > +       initial resolution before producing decoded frames.
> > > > 
> > > > [Severity: High]
> > > > Does this guidance conflate the V4L2_FMT_FLAG_DYN_RESOLUTION flag,
> > > > which designates mid-stream dynamic resolution switching, with the
> > > > mandatory initial V4L2_EVENT_SOURCE_CHANGE event?
> > > > 
> > > > The V4L2 Stateful Decoder API requires an initial
> > > > V4L2_EVENT_SOURCE_CHANGE event during the Initialization phase for stream
> > > > parsing, irrespective of dynamic resolution support.
> > > > 
> > > > Compliant drivers like coda correctly emit this initial event but do not set
> > > > V4L2_FMT_FLAG_DYN_RESOLUTION because they lack mid-stream switching
> > > > capabilities.
> > > > 
> > > > If userspace follows this documented advice, wouldn't it erroneously skip
> > > > waiting for the initial event on these drivers, potentially breaking capture
> > > > setup
> > > > and stream decoding?
> > > > 
> > > > --
> > > > Sashiko AI review · https://sashiko.dev/#/patchset/20260608-flag-dyn-
> > > > resolution-v1-0-44dc65516148@oss.nxp.com?part=1
> > > 
> > > Hi,
> > > 
> > > Thanks for the review.
> > > 
> > > You are right that the V4L2 stateful decoder specification states the initial
> > > V4L2_EVENT_SOURCE_CHANGE is mandatory for coded formats that contain
> > > resolution information in the stream (Initialization Step 4).
> > 
> > Be aware that Sashiko is an AI bot, llm words things with extreme conviction,
> > and it this case forget about backward compatibility from pre-spec.
> > 
> > > 
> > > However, in practice, GStreamer's v4l2 stateful decoder implementation uses
> > > V4L2_FMT_FLAG_DYN_RESOLUTION to determine whether to subscribe and wait for
> > > the initial source change event. The reasoning from the GStreamer side, as
> > > Nicolas explained [1]:
> > > 
> > >   
> > > "
> > > https://docs.kernel.org/userspace-api/media/v4l/dev-decoder.html#dynamic-resolu
> > > tion-change
> > >     Says:
> > >         Not all decoders can detect resolution changes. Those that do set the
> > >         V4L2_FMT_FLAG_DYN_RESOLUTION flag.
> > > 
> > >     So normally that wording should prevent requiring an initial SRC_CH,
> > >     or emitting later SRC_CH. Your driver don't have this flag, then your
> > >     driver can't emit this event. But a measure we should take into
> > >     GStreamer would be to not register (or mark) this event."
> > > 
> > > @Nicolas, could you elaborate on why GStreamer needs
> > > V4L2_FMT_FLAG_DYN_RESOLUTION to handle the initial source change event?
> > > Is this something that should be fixed on the GStreamer side (i.e., always
> > > wait for the initial event), or is the current heuristic intentional due to
> > > legacy drivers that don't emit the event?
> > 
> > The coda source_change notification is completely fake. It does not dependent on
> > the bitstream content. So the event is left there, since its kind of part of the
> > ABI, but it does not behave like other implementation, or pre-spec drivers.
> > 
> > So what we do in GStreamer, is that for legacy driver (no
> > V4L2_FMT_FLAG_DYN_RESOLUTION), we pre-allocate both queues, based on our guessed
> > dimensions. If it happens that the conformance windows is small enough, it often
> > works. DRC will only work if the display dimension changes.
> > 
> > For any modern driver, that implement V4L2_FMT_FLAG_DYN_RESOLUTION, we strictly
> > wait for the event, and on DRC, even if the display resolution changes, we let
> > the driver tell us when to actually reconfigure. The legacy method was kept to
> > not break coda and older driver, the new method is a lot more reliable, and
> > avoid allocating twice the capture queue (wrong guess).
> > 
> > The userspace implementation is also a bit more flexible, as normally the legacy
> > way should kind of work for any drivers, and we still subscribe it seems. But
> > the implication is just strange and shouldn't be needed in drivers with
> > V4L2_FMT_FLAG_DYN_RESOLUTION support.
> > 
> > Nicolas
> > 
> > 
> 
> Thanks for the detailed explanation of GStreamer's approach.
> 
> I have a couple of follow-up questions:
> 
> 1. Regarding coda's source change being "completely fake":
> 
>    Looking at the coda driver code, its seq_init_work does parse the
>    bitstream via hardware (SEQ_INIT command), and the source change event
>    is only emitted after ctx->initialized is set — which requires the
>    hardware to successfully parse the stream headers. After the event,
>    userspace can call G_SELECTION to retrieve the actual display crop
>    rectangle parsed from the bitstream.
> 
>    The limitation is that coda requires userspace to set a sufficiently
>    large resolution via S_FMT(OUTPUT) beforehand (since it validates
>    stream dimensions fit within the pre-configured buffer size rather
>    than updating G_FMT with parsed dimensions). But the event itself
>    does depend on bitstream content and carries useful information
>    (visible resolution via selection API).
> 
>    So it seems coda could work with the standard init flow — the source
>    change event is real, just the information delivery is partial (crop
>    via G_SELECTION rather than full coded resolution via G_FMT). Would
>    you agree, or is there another reason GStreamer treats it as legacy?

Its possible I miss-understood the code indeed.

> 
> 2. Regarding s5p-mfc:
> 
>    Interestingly, s5p-mfc sets V4L2_FMT_FLAG_DYN_RESOLUTION but does
>    NOT emit an initial source change event. After SEQ_DONE, it simply
>    transitions to MFCINST_HEAD_PARSED state and wakes up waiters —
>    userspace discovers the resolution by calling G_FMT(CAPTURE) which
>    internally blocks until header parsing completes.
> 
>    The source change event is only emitted during mid-stream resolution
>    changes (RES_CHANGE_FLUSH path). How does GStreamer handle this case?
>    Does it timeout waiting for the initial event and fall back, or does
>    it use some other mechanism?

That one I have no idea, that MFC driver gets highly hacked up on Android, and
Samsung is pretty much gone from the general purpose SBC or IoT world. Last time
I worked with MFC, they did not have that flags set (it didn't exist yet), and
the blocking G_FMT was the thing that pretty much everyone disliked, and why we
made a spec for newly introduce decoder.

I'd assume that GStreamer cannot operate on mainline MFC. It would be nice to
fix, but I don't myself have the bandwidth. Is there anyone left at Samsung that
cares about it ? Adding the two maintainers. Though clearly, its non spec
compliant to flag V4L2_FMT_FLAG_DYN_RESOLUTION without emitting the initial
event.

> 
> Overall, I agree that using V4L2_FMT_FLAG_DYN_RESOLUTION to unify the
> behavior (both initial source change and mid-stream DRC) is the right
> direction. But the current state has some inconsistencies:
> 
>   - coda: emits initial source change, but does NOT set DYN_RESOLUTION
>   - s5p-mfc: sets DYN_RESOLUTION, but does NOT emit initial source change
> 
> If we want to document that "DYN_RESOLUTION implies initial source change
> event will be emitted", s5p-mfc would need to be fixed to comply. Does
> that seem reasonable, or should we take a different approach?

I think though that we don't have to have that documented, since
V4L2_FMT_FLAG_DYN_RESOLUTION comes after the V4L2 stateful spec, and so, if you
include that flag you also have to comply to the spec. Maybe I'm a bit wishful,
but the reality is that this is more about unmaintained territory.

For CODA, its very very old, and the legacy way of guessing the allocation is
what works best there. Though, I'd be happy to help fix and test this one, I do
have this hardware, and surprisingly, imx6 which host this IP is still in use
today.

Nicolas

> 
> Regards,
> Ming
> 
> > 
> > > 
> > > [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/work_items/5126
> > > 
> > > Best regards,
> > > Ming
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH RFC 1/2] media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage

[Nicolas Dufresne]

[-- Attachment #1: Type: text/plain, Size: 4814 bytes --]

Le mercredi 10 juin 2026 à 08:15 +0200, Hans Verkuil a écrit :
> > The more natural fix would be to add V4L2_EVENT_SOURCE_CHANGE for the
> > initial resolution case as well, then properly report
> > V4L2_FMT_FLAG_DYN_RESOLUTION through VIDIOC_ENUM_FMT. If all existing
> > drivers that support mid-stream DRC can similarly be updated to fire the
> > event for initial resolution, then perhaps the spec change to split the
> > flag isn't strictly necessary - drivers just need to be fixed to comply
> > with the current definition.
> > 
> > I'd appreciate hearing others' thoughts on whether this unified approach
> > is practical across all existing drivers.
> 
> Just a quick reply to mention that the s5p-mfc driver predates a lot of the
> newer uAPIs for stateful codecs. It's why it behaves in a not-quite-standard
> way. So there is history here. The resolution change support was added in
> commit 0520e4cc3bb9d back in 2014, three years after the driver was first
> added to the kernel. The stateful decoder spec as we have today was only
> introduced in 2019.

Fair point. Now, some clarification about the initial event. When this was re-
implemented in GStreamer, we explicitly don't prepare the capture queue (no
REQBUFS/CREATE_BUF, its not streaming). So effectively, the driver is forced to
start with only the output queue, and that was assumed to force the initial
event. The src_ch event indicates that the driver is stuck until the capture
queue has been reconfigured (or configured in this cased).

I think you make a good point that this is not very clearly stated, but it was
also intentional to use that flag as a boundary before expecting this very
strict behaviour. From a HW stand point, it does make quite some sense, since
the parsing of header and discovery should happen separately from the capture
buffer requirement. This is the main difference between stateless and stateful.
In userspace, this workflow allowed to better decouple the output and capture
threads, which very typically is a independent threads (true for GStreamer and
Chromium at minimum).

In the legacy path in gstreamer, the capture queue format is guessed, allocated
and set to streaming. In that case, the driver only have to emit the initial
event if the capture queue configuration miss-match its requirements. I believe
that was done so it aligned with some legacy flow. In theory this should work
with earlier implementation of SOURCE_CHANGE, but remains a best effort. CODA960
being the only legacy implementation I kept testing over time. With CODA today,
if the guessed allocation failed, everything fails, which seems to be a bug or
limitation from you analyses. Fixing it can be tricky, as we need to ensure we
maintain backward compatibility with older userspace. Specially for CODA which
is massively deployed. A lot of strangeness in CODA comes from its reversed
engineered nature. Note that, I do have spec for this one these days, and can
answer questions. I do know that we actually get a subset of the SPS, which
should fully cover the needs for the DYN_RESOLUTION.

The thing that also comes with V4L2_FMT_FLAG_DYN_RESOLUTION, is also the drain
flow. There was just no drain flow prior to this and the matching decoder spec.
So to drain the capture queue on SOURCE_CHANGE, we had to track the state of the
queue, and avoid going back into polling once the queue was drained (since
polling previously blocked). That tracking have simply never been implemented in
GStreamer. The only legacy draining flow we had, was the infamous zero sized
buffer, which was ambiguous, since there was 3 possibilities instead of 2:

- Failed decode
- Failed decode and drained
- Drained

If a decode failed at entropy decode, the resulting failed buffer would be
signalled and confused with the drain. And so the other infamous LAST flag was
added. But then MFC signals the drain state independently, not at the same time
as the last buffer, and so EPIPE on DQBUF was introduced. With the new spec, we
forced this drain flow onto both draining on end-of-stream (CMD_STOP) and to
happen somewhere after any SOURCE_CHANGE, and if you use
V4L2_FMT_FLAG_DYN_RESOLUTION you must follow the DRC flow from the new spec.

I don't know if sharing the drain mechanism for DRC and actual CMD_STOP was the
best idea in the world, but it is what is it now, and for sure, old or
unmaintained drivers endup with highly inconsistent state. I'm happy with the
idea to improve the spec, and to improve the drivers concistency too, as long as
we can actually test, since it too complex to change without testing. I think,
if something could help, it would be to implement couple of the legacy flow in
vivid driver, so we could test virtually.

Nicolas

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH RFC 1/2] media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage

[Ming Qian(OSS)]

On Wed, Jun 10, 2026 at 09:20:12AM -0400, Nicolas Dufresne wrote:
> Le mercredi 10 juin 2026 à 11:49 +0900, Ming Qian(OSS) a écrit :
> > On Tue, Jun 09, 2026 at 02:00:02PM -0400, Nicolas Dufresne wrote:
> > 
> > Hi Nicolas,
> > > Hi Ming,
> > > 
> > > Le lundi 08 juin 2026 à 06:26 +0000, Ming Qian (OSS) a écrit :
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: sashiko-bot@kernel.org <sashiko-bot@kernel.org>
> > > > > Sent: Monday, June 8, 2026 12:06 PM
> > > > > To: Ming Qian (OSS) <ming.qian@oss.nxp.com>
> > > > > Cc: imx@lists.linux.dev; Frank.Li@kernel.org; linux-media@vger.kernel.org
> > > > > Subject: Re: [PATCH RFC 1/2] media: docs: Clarify
> > > > > V4L2_FMT_FLAG_DYN_RESOLUTION usage
> > > > > 
> > > > > Thank you for your contribution! Sashiko AI review found 1 potential
> > > > > issue(s)
> > > > > to consider:
> > > > > - [High] The added documentation conflates
> > > > > `V4L2_FMT_FLAG_DYN_RESOLUTION` (which designates mid-stream dynamic
> > > > > resolution switching capability) with the mandatory initial
> > > > > `V4L2_EVENT_SOURCE_CHANGE` event. By stating "Clients can use this flag to
> > > > > determine whether the decoder will signal the initial resolution", it
> > > > > explicitly
> > > > > legitimizes a flawed userspace heuristic that violates the V4L2 stateful
> > > > > decoder
> > > > > specification. The specification mandates that for coded formats containing
> > > > > resolution info, the decoder MUST parse the stream and emit an initial
> > > > > `V4L2_EVENT_SOURCE_CHANGE` event (Initialization Step 4). Compliant drivers
> > > > > (e.g., `coda`) correctly emit this initial event but do NOT set
> > > > > `V4L2_FMT_FLAG_DYN_RESOLUTION` because they lack mid-stream switching
> > > > > capabilities. If userspace follows this documented advice, it will
> > > > > erroneously
> > > > > skip waiting for the initial event on these drivers, breaking Capture Setup
> > > > > and
> > > > > stream decoding.
> > > > > --
> > > > > 
> > > > > commit ec9c0583334c246f7813132b55724e42622e8edd
> > > > > Author: Ming Qian <ming.qian@oss.nxp.com>
> > > > > 
> > > > > media: docs: Clarify V4L2_FMT_FLAG_DYN_RESOLUTION usage
> > > > > 
> > > > > This commit updates the V4L2 stateful decoder documentation to clarify the
> > > > > usage of the V4L2_FMT_FLAG_DYN_RESOLUTION flag. It adds a note stating
> > > > > that decoders setting this flag will always emit an initial source change
> > > > > event.
> > > > > The documentation suggests clients can use this flag to decide whether to
> > > > > wait
> > > > > for the initial resolution signal.
> > > > > 
> > > > > > diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > > b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > > --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > > +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > > > > > @@ -361,6 +361,14 @@ Initialization
> > > > > [ ... ]
> > > > > > +    .. note::
> > > > > > +
> > > > > > +       Decoders that set the ``V4L2_FMT_FLAG_DYN_RESOLUTION`` flag for
> > > > > the
> > > > > > +       coded format will always emit an initial
> > > > > ``V4L2_EVENT_SOURCE_CHANGE``
> > > > > > +       event with ``V4L2_EVENT_SRC_CH_RESOLUTION`` during this phase.
> > > > > Clients
> > > > > > +       can use this flag to determine whether the decoder will signal the
> > > > > > +       initial resolution before producing decoded frames.
> > > > > 
> > > > > [Severity: High]
> > > > > Does this guidance conflate the V4L2_FMT_FLAG_DYN_RESOLUTION flag,
> > > > > which designates mid-stream dynamic resolution switching, with the
> > > > > mandatory initial V4L2_EVENT_SOURCE_CHANGE event?
> > > > > 
> > > > > The V4L2 Stateful Decoder API requires an initial
> > > > > V4L2_EVENT_SOURCE_CHANGE event during the Initialization phase for stream
> > > > > parsing, irrespective of dynamic resolution support.
> > > > > 
> > > > > Compliant drivers like coda correctly emit this initial event but do not set
> > > > > V4L2_FMT_FLAG_DYN_RESOLUTION because they lack mid-stream switching
> > > > > capabilities.
> > > > > 
> > > > > If userspace follows this documented advice, wouldn't it erroneously skip
> > > > > waiting for the initial event on these drivers, potentially breaking capture
> > > > > setup
> > > > > and stream decoding?
> > > > > 
> > > > > --
> > > > > Sashiko AI review · https://sashiko.dev/#/patchset/20260608-flag-dyn-
> > > > > resolution-v1-0-44dc65516148@oss.nxp.com?part=1
> > > > 
> > > > Hi,
> > > > 
> > > > Thanks for the review.
> > > > 
> > > > You are right that the V4L2 stateful decoder specification states the initial
> > > > V4L2_EVENT_SOURCE_CHANGE is mandatory for coded formats that contain
> > > > resolution information in the stream (Initialization Step 4).
> > > 
> > > Be aware that Sashiko is an AI bot, llm words things with extreme conviction,
> > > and it this case forget about backward compatibility from pre-spec.
> > > 
> > > > 
> > > > However, in practice, GStreamer's v4l2 stateful decoder implementation uses
> > > > V4L2_FMT_FLAG_DYN_RESOLUTION to determine whether to subscribe and wait for
> > > > the initial source change event. The reasoning from the GStreamer side, as
> > > > Nicolas explained [1]:
> > > > 
> > > >   
> > > > "
> > > > https://docs.kernel.org/userspace-api/media/v4l/dev-decoder.html#dynamic-resolu
> > > > tion-change
> > > >     Says:
> > > >         Not all decoders can detect resolution changes. Those that do set the
> > > >         V4L2_FMT_FLAG_DYN_RESOLUTION flag.
> > > > 
> > > >     So normally that wording should prevent requiring an initial SRC_CH,
> > > >     or emitting later SRC_CH. Your driver don't have this flag, then your
> > > >     driver can't emit this event. But a measure we should take into
> > > >     GStreamer would be to not register (or mark) this event."
> > > > 
> > > > @Nicolas, could you elaborate on why GStreamer needs
> > > > V4L2_FMT_FLAG_DYN_RESOLUTION to handle the initial source change event?
> > > > Is this something that should be fixed on the GStreamer side (i.e., always
> > > > wait for the initial event), or is the current heuristic intentional due to
> > > > legacy drivers that don't emit the event?
> > > 
> > > The coda source_change notification is completely fake. It does not dependent on
> > > the bitstream content. So the event is left there, since its kind of part of the
> > > ABI, but it does not behave like other implementation, or pre-spec drivers.
> > > 
> > > So what we do in GStreamer, is that for legacy driver (no
> > > V4L2_FMT_FLAG_DYN_RESOLUTION), we pre-allocate both queues, based on our guessed
> > > dimensions. If it happens that the conformance windows is small enough, it often
> > > works. DRC will only work if the display dimension changes.
> > > 
> > > For any modern driver, that implement V4L2_FMT_FLAG_DYN_RESOLUTION, we strictly
> > > wait for the event, and on DRC, even if the display resolution changes, we let
> > > the driver tell us when to actually reconfigure. The legacy method was kept to
> > > not break coda and older driver, the new method is a lot more reliable, and
> > > avoid allocating twice the capture queue (wrong guess).
> > > 
> > > The userspace implementation is also a bit more flexible, as normally the legacy
> > > way should kind of work for any drivers, and we still subscribe it seems. But
> > > the implication is just strange and shouldn't be needed in drivers with
> > > V4L2_FMT_FLAG_DYN_RESOLUTION support.
> > > 
> > > Nicolas
> > > 
> > > 
> > 
> > Thanks for the detailed explanation of GStreamer's approach.
> > 
> > I have a couple of follow-up questions:
> > 
> > 1. Regarding coda's source change being "completely fake":
> > 
> >    Looking at the coda driver code, its seq_init_work does parse the
> >    bitstream via hardware (SEQ_INIT command), and the source change event
> >    is only emitted after ctx->initialized is set — which requires the
> >    hardware to successfully parse the stream headers. After the event,
> >    userspace can call G_SELECTION to retrieve the actual display crop
> >    rectangle parsed from the bitstream.
> > 
> >    The limitation is that coda requires userspace to set a sufficiently
> >    large resolution via S_FMT(OUTPUT) beforehand (since it validates
> >    stream dimensions fit within the pre-configured buffer size rather
> >    than updating G_FMT with parsed dimensions). But the event itself
> >    does depend on bitstream content and carries useful information
> >    (visible resolution via selection API).
> > 
> >    So it seems coda could work with the standard init flow — the source
> >    change event is real, just the information delivery is partial (crop
> >    via G_SELECTION rather than full coded resolution via G_FMT). Would
> >    you agree, or is there another reason GStreamer treats it as legacy?
> 
> Its possible I miss-understood the code indeed.
> 
> > 
> > 2. Regarding s5p-mfc:
> > 
> >    Interestingly, s5p-mfc sets V4L2_FMT_FLAG_DYN_RESOLUTION but does
> >    NOT emit an initial source change event. After SEQ_DONE, it simply
> >    transitions to MFCINST_HEAD_PARSED state and wakes up waiters —
> >    userspace discovers the resolution by calling G_FMT(CAPTURE) which
> >    internally blocks until header parsing completes.
> > 
> >    The source change event is only emitted during mid-stream resolution
> >    changes (RES_CHANGE_FLUSH path). How does GStreamer handle this case?
> >    Does it timeout waiting for the initial event and fall back, or does
> >    it use some other mechanism?
> 
> That one I have no idea, that MFC driver gets highly hacked up on Android, and
> Samsung is pretty much gone from the general purpose SBC or IoT world. Last time
> I worked with MFC, they did not have that flags set (it didn't exist yet), and
> the blocking G_FMT was the thing that pretty much everyone disliked, and why we
> made a spec for newly introduce decoder.
> 
> I'd assume that GStreamer cannot operate on mainline MFC. It would be nice to
> fix, but I don't myself have the bandwidth. Is there anyone left at Samsung that
> cares about it ? Adding the two maintainers. Though clearly, its non spec
> compliant to flag V4L2_FMT_FLAG_DYN_RESOLUTION without emitting the initial
> event.
> 
> > 
> > Overall, I agree that using V4L2_FMT_FLAG_DYN_RESOLUTION to unify the
> > behavior (both initial source change and mid-stream DRC) is the right
> > direction. But the current state has some inconsistencies:
> > 
> >   - coda: emits initial source change, but does NOT set DYN_RESOLUTION
> >   - s5p-mfc: sets DYN_RESOLUTION, but does NOT emit initial source change
> > 
> > If we want to document that "DYN_RESOLUTION implies initial source change
> > event will be emitted", s5p-mfc would need to be fixed to comply. Does
> > that seem reasonable, or should we take a different approach?
> 
> I think though that we don't have to have that documented, since
> V4L2_FMT_FLAG_DYN_RESOLUTION comes after the V4L2 stateful spec, and so, if you
> include that flag you also have to comply to the spec. Maybe I'm a bit wishful,
> but the reality is that this is more about unmaintained territory.

Hi Nicolas,

Thanks for the detailed explanations and historical context.

I still think an explicit note in the documentation would be valuable.
The amphion case is a good example: the flag was intentionally removed
because the reviewer interpreted V4L2_FMT_FLAG_DYN_RESOLUTION as only
relating to mid-stream resolution changes, not the initial source change
event.

The wording in the "Dynamic Resolution Change" section:

    "Not all decoders can detect resolution changes. Those that do set
     the V4L2_FMT_FLAG_DYN_RESOLUTION flag."

can easily be read as "this flag is only about mid-stream DRC", which
is what led to the amphion flag removal. A clarifying note in the
Initialization section ties the two concepts together explicitly and
helps prevent such misunderstandings in the future.

Regards,
Ming

> 
> For CODA, its very very old, and the legacy way of guessing the allocation is
> what works best there. Though, I'd be happy to help fix and test this one, I do
> have this hardware, and surprisingly, imx6 which host this IP is still in use
> today.
> 
> Nicolas
> 
> > 
> > Regards,
> > Ming
> > 
> > > 
> > > > 
> > > > [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/work_items/5126
> > > > 
> > > > Best regards,
> > > > Ming
> >