[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 7.1)

[Reimar Döffinger]

On Tue, Feb 24, 2009 at 04:58:30PM +0100, Michael Niedermayer wrote:
> On Tue, Feb 24, 2009 at 04:24:36PM +0100, Gwenole Beauchesne wrote:
> > On Tue, 24 Feb 2009, Michael Niedermayer wrote:
> > > the user app can use whatever it needs from AVCodecContext to decide if
> > > its accelerator can handle it or not ...
> > 
> > Then you also nicely break Reimar's recent map tables work since you no 
> > longer have any bijection there. And requiring an extra arg (for e.g. 
> > codec_id) is not a really clean approach either.
> 
> comments from reimar as well as comments from you about improving the design
> and implementation are welcome

While in MPlayer's current design a per-codec PIX_FMT is not necessary,
I do not think the situation is comparable to the per-level PIX_FMT
case.
The notable differences are
1) levels/profile changing within a file is supported in the software
implementation (and such files might be even valid), I do not like a
design that would restrict the hardware implementation to be
_necessarily_ less powerful.
2) profile/level as indicated in the video file can be wrong (and again,
cause no issues for software decoding).
3) the levels-support is not clear-cut, hardware decoders often can
decode higher levels than the manufacturers officially advertise (this
is different from codec support), and what is supported can easily
depend on e.g. free video RAM, some of which an application can free
on-demand.

Not using per-codec PIX_FMTs seems more likely to me to just complicate
things, though I do not know for sure.
In contrast, IMO per-level PIX_FMTs would have been a serious detriment
to future development and generally better hardware support (and I still
consider the usage of this stuff a serious misdesign in the accelration
APIs).