Re: [RFC] docs: dev-decoder: Add two more reasons for dynamic change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 26, 2020 at 12:26 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
>
> On 30/04/2020 13:38, Stanimir Varbanov wrote:
> > Here we add two more reasons for dynamic-resolution-change state
> > (I think the name is misleading espesially "resolution" word, maybe
>
> espesially -> especially
>
> > dynamic-bitstream-change is better to describe).
> >
> > The first one which could change in the middle of the stream is the
> > bit-depth. For worst example the stream is 8bit at the begging but
> > later in the bitstream it changes to 10bit. That change should be
> > propagated to the client so that it can take appropriate  action. In
> > this case most probably it has to stop the streaming on the capture
> > queue and re-negotiate the pixel format and start the streaming
> > again.
> >
> > The second new reason is colorspace change. I'm not sure what action
> > client should take but at least it should be notified for such change.
> > One possible action is to notify the display entity that the colorspace
> > and its parameters (y'cbcr encoding and so on) has been changed.
> >
> > Signed-off-by: Stanimir Varbanov <stanimir.varbanov@xxxxxxxxxx>
> > ---
> >  Documentation/userspace-api/media/v4l/dev-decoder.rst | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > index 606b54947e10..bf10eda6125c 100644
> > --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
> > @@ -906,7 +906,11 @@ reflected by corresponding queries):
> >
> >  * visible resolution (selection rectangles),
> >
> > -* the minimum number of buffers needed for decoding.
> > +* the minimum number of buffers needed for decoding,
> > +
> > +* bit-depth of the bitstream has been changed,
> > +
> > +* colorspace (and its properties) has been changed.
>
> For this I want to have a new source change flag:
>
> V4L2_EVENT_SRC_CH_COLORIMETRY
>
> Changing colorimetry without changing resolution/bit depth does not
> require buffers to be re-allocated, it just changes how the pixel
> data is interpreted w.r.t. color. And that is important to know.

FWIW, the visible resolution (i.e. compose rectangle) change that is
already defined doesn't require buffers to be re-allocated either.
Backwards compatibility requires V4L2_EVENT_SRC_CH_RESOLUTION to be
set, but perhaps we could have further flags introduced, which would
mean visible resolution and stream format (pixelformat, resolution)
exclusively?

Best regards,
Tomasz



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux