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. 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: -- 2.17.1
