Hi,
Le mardi 07 janvier 2025 à 14:36 +0900, Ming Qian a écrit :
If colorspace changes, the client needs to renegotiate the pipeline,
otherwise the decoded frame may not be displayed correctly.
If it can trigger an source change event, then client can switch to the
correct stream setting. And each frame can be displayed properly.
So add colorspace as a trigger parameter for dynamic resolution change.
Signed-off-by: Ming Qian <ming.qian@xxxxxxxxxxx>
---
Documentation/userspace-api/media/v4l/dev-decoder.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst
index ef8e8cf31f90..49566569ad26 100644
--- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
+++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
@@ -932,7 +932,9 @@ reflected by corresponding queries):
* the minimum number of buffers needed for decoding,
-* bit-depth of the bitstream has been changed.
+* bit-depth of the bitstream has been changed,
+
+* colorspace of the bitstream has been changed.
Did you really mean colorspace in the way this term is used in V4L2 ? What we
want this event to be used for is when the capture storage size or amount
changes, perhaps you mean when the capture pixelformat changes ? This will
indeed happen if you change the bit-depth, subsampling (not mentioned here
either) or change the way colors are repsented (RGB, YCbCr, etc.).
Whenever that happens, the decoder must proceed as follows: