On Thu, Apr 11, 2019 at 7:47 PM Peter F <peter.fruehber...@gmail.com> wrote: > > Hi, > > Am Do., 11. Apr. 2019 um 00:50 Uhr schrieb Hendrik Leppkes > <h.lepp...@gmail.com>: > > > > On Thu, Apr 11, 2019 at 12:39 AM Lukas Rusak <loru...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".