[FFmpeg-devel] [PATCH][7/8] Add VA API accelerated H.264 decoding (take 4)
Mon Feb 9 16:59:13 CET 2009
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
>> 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
> 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.
More information about the ffmpeg-devel