On Fri, Jul 19, 2019 at 5:41 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > On 7/19/19 4:45 AM, Tomasz Figa wrote: > > On Mon, Jul 15, 2019 at 9:37 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > >> > >> On 6/11/19 10:13 AM, Hans Verkuil wrote: > >>> On 6/9/19 4:38 PM, Maxime Jourdan wrote: > >>>> Hello, > >>>> > >>>> This RFC proposes a new format flag - V4L2_FMT_FLAG_DYN_RESOLUTION - used > >>>> to tag coded formats for which the device supports dynamic resolution > >>>> switching, via V4L2_EVENT_SOURCE_CHANGE. > >>>> This includes the initial "source change" where the device is able to > >>>> tell userspace about the coded resolution and the DPB size (which > >>>> sometimes translates to V4L2_CID_MIN_BUFFERS_FOR_CAPTURE). > >>> > >>> Shouldn't the initial source change still be there? The amlogic decoder > >>> is capable of determining the resolution of the stream, right? It just > >>> can't handle mid-stream changes. > >> > >> I've been thinking about this a bit more: there are three different HW capabilities: > >> > >> 1) The hardware cannot parse the resolution at all and userspace has to tell it > >> via S_FMT. > >> > >> 2) The hardware can parse the initial resolution, but is not able to handle > >> mid-stream resolution changes. > >> > >> 3) The hardware can parse the initial resolution and all following mid-stream > >> resolution changes. > >> > >> We can consider 2 the default situation. > > > > Any particular reason for 2 being the default? I'm especially > > wondering about that as most of the drivers actually provide 3. > > Various reasons: > > 1) I prefer to have a flag indicating what IS supported rather than what > isn't. > 2) An application that checks this flag and doesn't see it (i.e. if a > flag-aware application is used with an older kernel where these flags > aren't set) will still work, but with possibly reduced functionality. > If the flag would indicate that something is NOT supported, then they > would fail when combined with an older kernel and a driver that doesn't > support dynamic resolution changes. > 3) None of the encoders support it, so there too it makes sense to have > 'no dynamic resolution change' as the default. It's nicely symmetrical > for encoders and decoders. > 4) Some formats do not support it, so again, having no dynamic res changes > as the default makes sense. Okay, I think you convinced me, thanks! Feel free to add my Acked-by. Best regards, Tomasz
