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

Michael Niedermayer michaelni
Tue Aug 29 11:15:49 CEST 2006


Hi

On Tue, Aug 29, 2006 at 06:03:06PM +1000, John Dalgliesh wrote:
> 
> 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! :)

there are many ways to do this
A.
always_inline decode_block(..., int unpack){
    ...
    if(unpack){ //unquantize
        level= ((level*2+1)*qscale*quant_matrix[j])>>5;
        level= (level-1)|1;
    }
    ...
    if(unpack) block[j] = level;
    else{
        block[2*i  ] = level;
        block[2*i+1] = run;
    }
    ...
}

if(foobar)
    decode_block(..., 0);
else
    decode_block(..., 1);

or
B.
#define decode_block_internal(..., unpack){\
    ...
    if(unpack){ //unquantize\
        level= ((level*2+1)*qscale*quant_matrix[j])>>5;\
        level= (level-1)|1;\
    }\
    ...
    if(unpack) block[j] = level;\
    else{\
        block[2*i  ] = level;\
        block[2*i+1] = run;\
    }\
    ...
}

decode_block(...){
    decode_block_internal(..., 1);
}
decode_block_unvlc(...){
    decode_block_internal(..., 0);
}

or other variations of that, most important though is to carefully benchmark
it (see START/STOP_TIMER) to ensure everything works as expected, the inline
based variants depend on gcc not messing but they are cleaner and more
readable ...

PS: also if anyone does that, please merge the decode_block_foobar() and
decode_block_foobar_fast() functions they are nearly identical and i should
have implemented them like descibed above furthermore merging them will half
the number of functions which need to be changed for apple hw decoding support


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is




More information about the ffmpeg-devel mailing list