Hi Nicolas,
Am Donnerstag, den 02.10.2014, 09:44 -0400 schrieb Nicolas Dufresne:
Le 2014-10-02 09:39, Philipp Zabel a écrit :
Yes, that is exactly what I had in mind. I'd like to get to a clear description in what order to correctly set up a codec for streaming and some clarification about what should happen in error conditions, such as selecting incompatible output&capture formats, trying to decode a 4:2:2 JPEG into a 4:2:0 YUV buffer, or filling P-frames at the beginning of the stream into a H.264 decoder. And then there is the issue of stream end and the EOS signal.
Ah, now I get why you wanted to split the JPEG decoder from the others.
Yes, that is one of the reasons. The other being that the CODA960 has a separately controlled hardware unit that does not use the same bitstream buffer mechanism as the other codecs.
I think it relates to the topic I wanted to bring. We basically need a mechanism to enumerate format after the output device format has been set. Otherwise, we need to do a lot of trial and error if we try to negotiate an capture format.
The JPEG decoding issue is something that can't be statically enumerated at all. We don't know what the JPEG's chroma subsampling is until after STREAMON, when the driver could peek into the first buffer's header.
We might be able to use ENUM_FMT and ENUM_FRAMESIZES on the capture side if we decide that they change their meaning after STREAMON on the output side and only list formats that the codec can generate from the already queued frames.
regards Philipp