Re: [PATCH v7 2/4] media: videodev2: add V4L2_FMT_FLAG_FIXED_RESOLUTION

[Nicolas Dufresne]

Le mardi 11 juin 2019 Ã 10:52 +0200, Philipp Zabel a Ãcrit :
> On Wed, 2019-06-05 at 15:39 +0200, Hans Verkuil wrote:
> > Hi Maxime,
> > 
> > I am wondering if this flag shouldn't be inverted: you set
> > V4L2_FMT_FLAG_DYN_RESOLUTION if dynamic resolution is supported,
> > otherwise it isn't.
> > 
> > Can all the existing mainlined codec drivers handle midstream
> > resolution changes?
> > 
> > s5p-mfc, venus and mediatek can, but I see no SOURCE_CHANGE event in
> > the coda drivers, so I suspect that that can't handle this.
> > 
> > Philipp, what is the status of the coda driver for dynamic resolution
> > changes?
> 
> FTR, to my knowledge there is no dynamic resolution change support in
> the firmware, as there is no signal (interrupt nor picture run return
> value) to indicate that different headers were parsed.
> 
> I am planning to add the initial source change event required by the
> current decoder API documentation, but I am afraid there will be no
> support for source changes due to mid-stream resolution changes due to
> firmware limitations.

I'm far from familiar with this IP, but at least on CODA988, I can read
from the manual that the workflow is to first guess the allocation, and
if you guess it wrong, an error is returned. What seems to match the
SOURCE_CHANGE event in that version would be in the picture status
register, the bit 20, which is documented as triggered if the stream
requires bigger buffers sizes, or more buffers. After fixing that, you
should, if I read correctly, retry.

It does not notify if the buffers are too large, but you can detect,
since there is register with the output stream information. This
basically means that for V4L2 restriction, you'd have to bounce the
buffers on frame size boundary or something like thisÃ

This workflow is very similar to how OMX works, but V4L2 is even less
flexible on allocation vs format, forcing more re-allocation.

> 
> regards
> Philipp