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

Lukas Rusak lorusak at gmail.com
Sat Apr 13 02:16:46 EEST 2019


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.

What we do currently is open the codec single threaded to try
hardware formats. The get_format callback will return a hardware format
for the decoder and if not we reopen the codec with multithreading
enabled. Is there a better method to do this initialization?

Regards,
Lukas Rusak




More information about the ffmpeg-devel mailing list