[FFmpeg-devel] FFmpeg MT and HWACCEL mess

[Reimar Döffinger]

On Sun, Mar 27, 2011 at 07:59:35PM +0200, Michael Niedermayer wrote:
> On Sun, Mar 27, 2011 at 02:40:58PM +0200, Reimar Döffinger wrote:
> > I just had to realize that due all the new thread code in avcodec_open
> > making the HWACCEL stuff anything than a messy, broken hack has become
> > even harder.
> > Since it both initializes the threads and skips calling init, that means
> > whether to use threads or not has to be decided during init.
> > However we do not have any data available during init, so we have no chance
> > of testing whether the hardware supports the given input, nor can we use
> > get_format to decide which if any hwaccel to use.
> > This also pretty much puts a block on implementing a codec what would
> > automatically decide between hwaccel with readback and software decoding.
> > Any ideas or should I just finally take the hint and give up on FFmpeg
> > supporting hardware decoding in a way that isn't a PITA?
> 
> How would you sugest that ffmpeg should handle it?

I've said from the beginning that I consider the whole CODEC_CAP thing
a misadventure born of laziness.
However my early attempts to change it got no real reaction and more
and more code is added that makes things more and more brittle and
thus harder to actually improve anything.

> about having sufficient information early enough, there is extradata
> available during init. And our parsers contain code to extract the
> global header into extradata.

That's however not even remotely how the codecs are designed, the
MPEG1/2 decoder doesn't even decide between MPEG-1 and MPEG-2 before
decoding.

> And a decoder that switches between hw and multiframe-threaded software
> can be done with a codec that switches between 2 codec instances.
> It still has the problem that the 2 variants have different delay
> (multiframe software has higher delay) and this should cause problems
> with switching independant of implementation

First, there is no real problem in adding delay, even if it is probably
not a good idea.
However I don't care so much about runtime switching, just the case
"I want it to use the hardware when it is available and not when it is
not" working without 100 lines that exist for no other reason than a
bad API would be great!
For example how is an application even supposed to find that hardware-accelerated
codec?
Just trawling through the list and looking for both a matching codec id and
CODEC_CAP works, as does hardcoding the name but both sure aren't a sensible way!
Admittedly CrystalHD still is an issue even with my suggested approach.