[Ffmpeg-devel] MPEG-2 Acceleration Under Mac OS X - Can We Move This Forward?

[John Dalgliesh]

Hi,

On Mon, 28 Aug 2006, Rich Felker wrote:
> On Tue, Aug 29, 2006 at 01:58:19AM +0100, Robert Swain wrote:
>> galenz at zinkconsulting.com wrote:
>>> I'm tossing this out to you all, as ffmpeg developers, in hopes that
>>> somebody has some interest in working further on this. It would be
>>> interesting if the functionality could somehow be integrated into
>>> libavcodec, or perhaps just simply an effective player be put together.
>>> There are millions of users who could benefit!
>>
>> I'm interested in this as I have a MacBook and such things would be useful.
>> I doubt I have the same level of skills as yourself and John but I might be
>> able to offer some suggestions. My initial thought was that you might try
>> to make it into a library such that it can be easily used by any project.
>> MPlayerOSX or VLC might be other points of interest if you don't want to
>> make it into a library. Also, is it possible to extend to functionality of
>> the code to allow decoding of other codecs than MPEG-2?
>
> The best way to use this IMO is to make a vo driver for it in MPlayer,
> possibly merging it with an existing relevant MPlayer vo driver.
> FFmpeg libs should communicate with the driver the same way they do
> for xvmc.

Firstly I should say that I am the John that Galen is talking about (and 
I'm definitely not famous/rare enough to omit my last name :). I haven't 
worked on this any further since January when it was technically finished, 
and probably won't for quite some time so anyone who wants to run with it 
is most welcome. I know at least one person has started on a patch...

As Rich says, the ffmpeg portion is quite small; all it has to do is get 
the data out in the right way. I did of course use a modified file from 
ffmpeg to do this (mpeg12.c) in Accellent.

IIRC the problem is that the data expected by the Apple API is one level 
higher than XVMC. It takes the un-VLC'd run/level values plus the 
macroblock type (to determine the scantable) whereas XVMC just takes the 
whole 64 element block. This is great from a bandwidth point of view but 
doesn't integrate well with the existing mpeg decoding routine in ffmpeg.

I didn't come up with a solution that doesn't either:
1. Add lots of #ifdefs uglifying the code (and preventing runtime 
selection), or
2. Add lots of ifs slowing down the code, or
3. Duplicate significant portions of the code.

Whoever takes this on will first have to decide which of these is the 
lesser evil (probably 3? or 2 if ifs prove predictable?). And then making 
a coherent case to the list. Good luck! :)

{P^/