Le mardi 11 juin 2019 à 10:52 +0200, Philipp Zabel a écrit :

On Wed, 2019-06-05 at 15:39 +0200, Hans Verkuil wrote:

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel