[FFmpeg-devel] [PATCH] libavcodec/libdav1d: add libdav1d_get_format method to call ff_get_format

[Hendrik Leppkes]

On Thu, Apr 11, 2019 at 7:47 PM Peter F <peter.fruehberger at gmail.com> wrote:
>
> Hi,
>
> Am Do., 11. Apr. 2019 um 00:50 Uhr schrieb Hendrik Leppkes
> <h.leppkes at gmail.com>:
> >
> > On Thu, Apr 11, 2019 at 12:39 AM Lukas Rusak <lorusak at gmail.com> wrote:
> > >
> > > This will allow applications to properly init the decoder in
> > > cases where a hardware decoder is tried first and and software
> > > decoder is tried after by calling the get_format callback.
> > >
> > > Even though there is no hardware pixel formats available
> > > we still need to return the software pixel format.
> > >
> > > Tested with Kodi by checking if multithreaded software
> > > decoding is properly activated.
> > > ---
> > >  libavcodec/libdav1d.c | 12 +++++++++++-
> > >  1 file changed, 11 insertions(+), 1 deletion(-)
> > >
> >
> > This doesn't make sense to m e. get_format isn't called on a wide
> > variety of decoders, and is only useful when there is a hardware
> > format of any kind.
> > Please elaborate what exactly this is trying to achieve.
>
> Can you elaborate on how to use ffmpeg's API properly as a client to
> decide if a decoder is a SW decoder and therefore howto properly setup
> (multi-)threading, especially it cannot be changed once initialized?
>

I think you are approaching this from the wrong side. Even if the
decoder would support hardware, generally hardware support is limited.
So if someone plays a 10-bit  H264 file, which no consumer hardware
supports, or even worse, a very high resolution file which is beyond
hardware limits, do you want to run single-threaded and slow? I hope
not.

The way I solve that is to just close the decoder and re-open it if
needed, so I can change such settings. You also fare much  better if
you accept that you might  need to hard-code which codecs support
hardware at all. Considering thats one new one every 4 years or so,
it'll probably be fine.

- Hendrik