Le jeudi 30 avril 2020 à 14:38 +0300, Stanimir Varbanov a écrit : > Here we add two more reasons for dynamic-resolution-change state > (I think the name is misleading espesially "resolution" word, maybe > 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. Just to help with the use case, colorspace changes need to be communicated to the following HW or software in your media pipeline. Let's consider a V4L2 only use case: m2m decoder -> m2m color transform - >... The userspace needs to be aware on time, so that it can reconfigure the color transformation parameters. The V4L2 event is a miss-fit though, as it does not tell exactly which buffer will start having this new colorspace. So in theory, one would have to: - drain - send the new csc parameters - resume I'm not sure if our drivers implement resuming after CMD_STOP, do you have information about that ? We could also go through streamoff/on cycle in the mean time. Most codec won't allow changing these parameters on delta frames, as it would force the decoder doing CSC conversion of the reference frames in decode process, that seems unrealistically complex requirement. That being said, please keep in mind that in VP9, reference frames do not have to be of the same sizes. You can change the resolution at any point in time. No one managed to decode the related test vectors [0] with our current event base resolution change notification. [0] FRM_RESIZE https://www.webmproject.org/vp9/levels/ > > 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. > > Whenever that happens, the decoder must proceed as follows: >
