[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3c3a7b0c053c5366be4ad0c4a9a3bd205aaea731.camel@ndufresne.ca>
Date: Tue, 06 Dec 2022 12:46:57 -0500
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Hans Verkuil <hverkuil-cisco@...all.nl>,
Ming Qian <ming.qian@....com>, mchehab@...nel.org
Cc: shawnguo@...nel.org, robh+dt@...nel.org, s.hauer@...gutronix.de,
kernel@...gutronix.de, festevam@...il.com, linux-imx@....com,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Tomasz Figa <tfiga@...omium.org>
Subject: Re: [PATCH] media: videobuf2: add V4L2_BUF_FLAG_HEADERS_ONLY flag
Le mardi 06 décembre 2022 à 10:05 +0100, Hans Verkuil a écrit :
> > For decoders, if a a decoder is in "separate mode", it seems that sending
> > headers must happen this way. If this uses a separate path internally, the
> > kernel needs also to be aware which buffers are what (and we don't parse in
> > the
> > kernel). In very basic case, the driver assume that the first buffer after
> > streamon is a header, but that prevents resolution changes without a
> > drain+flush, which android and chromeos folks seems to use. (I always drain
> > and
> > flush for what I'm doing).
>
> OK, thank you for the explanation.
>
> So if this is going to be added, then existing drivers that use
> V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE have to be adapted to use the new flag
> as well.
>
> From what I can tell those are the mediatek vcodec, venus and s5p-mfc
> encoders.
> I suspect/hope that it won't be too difficult to add this new flag there.
The exercise will also be very informative for the reviewers, so yes, I would
ask Ming to update all the drivers, though its fine to only compile test this
and leave it to the maintainers to verify (at least that's my opinion). I don't
see this change as a break, as any existing userspace will just ignore this, and
maybe managed to support it by deep parsing (which will keep working).
Otherwise, existing userspace using this mode have been broken for
renegotiation, and that change will not deteriorate (nor improve) the end
result.
Nicolas
>
> Regards,
>
> Hans
Powered by blists - more mailing lists