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

Hendrik Leppkes h.leppkes at gmail.com
Sat Apr 13 02:27:40 EEST 2019


On Sat, Apr 13, 2019 at 1:17 AM Lukas Rusak <lorusak at gmail.com> wrote:
>
> On Thu, 2019-04-11 at 21:03 +0200, Hendrik Leppkes wrote:
> > 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
>
> So why don't the software only formats follow the api and also call
> ff_get_format like is done here? That would stop from applications
> having to hardcode the hardware decoding formats.
>

Because the callback is useless if there is only one format.
Its meant to negotiate hardware formats, not inform the user that
there is no hardware acceleration. There is also dozens if not
hundreds of codecs, changing them all to add the callback would be a
lot of work for apparently no benefit.

If you just want to know if a decoder supports hardware acceleration
of any kind, then check AVCodec.hw_configs, it contains plenty
information to make such decisions without hardcoding anything.

- Hendrik


More information about the ffmpeg-devel mailing list