lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d2adae2b6d0f370f17b9bac94ae4e9207dccbad.camel@ndufresne.ca>
Date:   Tue, 11 Jun 2019 20:58:32 -0400
From:   Nicolas Dufresne <nicolas@...fresne.ca>
To:     Philipp Zabel <p.zabel@...gutronix.de>,
        Hans Verkuil <hverkuil@...all.nl>,
        Maxime Jourdan <mjourdan@...libre.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hans.verkuil@...co.com>
Cc:     Kevin Hilman <khilman@...libre.com>,
        Jerome Brunet <jbrunet@...libre.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-amlogic@...ts.infradead.org
Subject: Re: [PATCH v7 2/4] media: videodev2: add
 V4L2_FMT_FLAG_FIXED_RESOLUTION

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ