[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