Hi Pawel,
Am Mittwoch, den 01.10.2014, 21:28 +0900 schrieb Pawel Osciak:
Hi Hans, Thanks for taking care of this!
On Mon, Sep 22, 2014 at 8:42 PM, Hans Verkuil hverkuil@xs4all.nl wrote:
Pawel:
- Existing codec API ambiguities (does this belong to this topic?)
Not really. This is about the existing codec API (the new codec API proposal below is a variant for a slightly different type of codecs, those that can't parse the bitstream).
I plan for this to be similar to some previous sessions we've had about general ambiguities in the API: a list of issues with a decision on each (optionally with a short discussion if needed). The list is not short, but I don't want to take too much of everyone's time, and it really depends on how much discussion will be needed. Could be 1h or so perhaps... We could move this to the end of the day maybe?
Philipp's "clarification of encoder/decoder handling" sounds like it could be related, I'm not sure what exactly he'd like to discuss. My plan is to discuss the state machine, try to clarify behaviors such as what happens on streamon/streamoff, how s_fmt, crop behave, when we can/should reqbufs, etc.
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.
Also, for the selection API, I have a mem2mem scaler hardware block with a bit strange limitations on cropping and composing (for example output size is arbitrary in principle, but since scanlines are only written out in bursts of at least 8 pixels, there might be garbage right of the target rectangle).
I'd really like to write a solid, detailed documentation of this API as a result of this discussion, but there are a lot of ambiguities.
- A proposal for a new codec API extension/mode for HW codecs that
can't parse elementary streams
This could be 15 minutes probably for just the presentation, assuming no discussion.
regards Philipp