[FFmpeg-devel] [PATCH] CODEC_CAP_HWACCEL --> CODEC_CAP_HWACCEL_XVMC

[Ivan Kalvachev]

On 1/6/09, Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> On Tue, Jan 06, 2009 at 08:30:19PM +0200, Ivan Kalvachev wrote:
>> On 1/6/09, Diego Biurrun <diego at biurrun.de> wrote:
>> > Here is a patch to do $subject.  Any objections?
>> >
>> > Diego
>> >
>>
>> Not acceptable.
>>
>> This flag have never been ment to be XVMC specific, nor there should
>> be one flag for each acceleration method that is in use.
>
> Then please tell what the flag _was_ meant to be/mean, because so far
> nobody has had a good answer to what it is good for (except maybe to
> hack around some of the codec_id mess that IMO violates the API, but at
> least is bad design).

Its intended meaning is that:
- this codec would call get_format() for sure.
- when get_format() is called, avctx would have valid entries for
height, width, color depth, profile, level
(or whatever goodie you need for the formats in the fmt[] table).
- during get_format() it is safe to set some flags (like render order
for slices)
and you can also set custom get/release_buffer() functions.
(The later is important because mpeg1/2 decoder can switch resolutions,
and you have to free the old buffers before changing these callbacks.)


The idea is that in the format table you can put
the accelerated formats first and followed by normal pixel format.
This way if the player fails to negotiate acceptable hardware
acceleration it would fallback to software only decoding.

The get_format() function these days is mostly abolished
and systematically removed.  Maybe on next major API break
we can rename it to "hw_acceleration_init()" or something.

Initially, I didn't create ffmpeg12mc with that CAPS. It was added later as
intermediate step towards removal of the specific codec.
This is why I also have xvmc modes for chroma formats,
similarly to the normal pixel formats (legacy).


More over.
The "avctx->xvmc_acceleration" turned out to be really bad name,
I think it should be renamed to "hw_acceleration_mode". (API break;)

This variable was created because xvmc can have 3 different
pix_fmt for mpeg2 (different number of chroma channels)
and it also can support different codecs
(some mpeg variants by asus I think).

In short, instead of relaying on specific codec, codec_id, pix_fmt or
codec_cap,
you should relay on specific xvmc/hw_acceleration mode.

It's biggest advantage of this variable is that
the value of 0 guarantees that we are in software decoding mode.


Thank you for asking.