[FFmpeg-devel] [PATCH][7/8] Add VA API accelerated H.264 decoding (take 4)

[Gwenole Beauchesne]

On Mon, 9 Feb 2009, Michael Niedermayer wrote:

> This isnt fair but it is effective and practical, if you have a better
> suggestion, its welcome of course, but not factorizing code or commiting
> suboptimal code is not ok.

Commit and have a third couple of eyes working on leveraging, e.g. through 
a SoC. ;-)

I think I will need to find a kind Carl-Heugen clone. You know, I don't 
have infinite time, what's the real benefit of overhauling the current 
implementation that works? Besides, experience shows that factorization 
doesn't work, or I missed factorization work for X11, Xv, XvMC VO et al. 
in MPlayer for example. There seems to always be subtle differences that 
would tend to be fixed with an over-engineered abstraction.

An alternative is to get Intel step in or other Linux distributors that 
would benefit from a single API used widely (read: system-wide, and from 
an open standard, if we consider fd.o standards).

Your current approach tends to discourage people. I now better understand 
why some other people told me off-list they have stopped trying 
upstream'ing patches and kept them lying around separately, somewhere...

At the very least, you should have commented on the real implementation 
earlier/beforehand, not many weeks after commenting on pure *cosmetics*. 
That's a terrible waste of time, and totally suboptimal process. IOW, 
cosmetics are the last things to care about in a process, especially if 
those are things that could be done through an automated tool.

> But you can also see it positive, if you factorize VDPAU + VAAPI support
> while nvidia doesnt help (and i dont belive they wont ...)

Well, I'd say it's not their role either. In practise, I don't think they 
would have the time anyway. I'd prefer have VDPAU fixes in the driver.

> you can maybe gain some advantage for VAAPI over VDPAU ;)

You know, VA API already has a clear advantage over VDPAU: it supports all 
three major APIs and implementations. ;-) So, I'd even say, if you want to 
have a common FFmpeg base struct, you'd better deriving it from VA API as 
it's descriptive enough to suit your purposes.

> av_register_hw_accel(struct AVHWAccel *hw_accel);

That supposes you have the AVHWAccel structs defined globally elsewhere 
(from the common file registering the hwaccels). i.e. a globally exported 
struct.

>> But there is a problem with this approach. Sometimes, the size of the
>> slice can't be known beforehand. e.g. MPEG-4. Unless you accept to
>> duplicate code to move to the next resync marker or end of buffer, I don't
>> see how to elegantly handle this code.
>
>> Probably make start_slice() take a buffer base + offset into this buffer
>> (for internal optimisation => use a single whole buffer to emit) and have
>> end_slice() take the buffer_end (or size wrt. the previous call to
>> start_slice())?
>
> possible
> its you who knows better what integrates best with the V* APIs

Well, actually, I am hesitating between buffer_end arg or size arg. One 
would argue that end_slice() is better suited to receive an *_end arg than 
a size arg. On the other hand, "size" is more descriptive...

There are also some requirements to specify. e.g. the current 
GetBitContext is OK to be used by those member functions. Otherwise, this 
would require too many args to pass through.

Regards,
Gwenole.