[FFmpeg-devel] GSoC Participation

[Michael Niedermayer]

On Mon, Mar 29, 2010 at 02:57:19PM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Mon, Mar 29, 2010 at 02:10:28AM +0100, M?ns Rullg?rd wrote:
> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> 
> >> > On Sun, Mar 28, 2010 at 07:21:30AM +0100, M?ns Rullg?rd wrote:
> >> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> >> 
> >> >> > On Sat, Mar 27, 2010 at 11:30:45AM -0400, Ronald S. Bultje wrote:
> >> >> >> Hi,
> >> >> >> 
> >> >> >> On Sat, Mar 27, 2010 at 11:20 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> >> >> >> > Right, so I was wondering about that qualification task already. For
> >> >> >> > float mp3 decoder, your best bet is to go on to IRC and talk directly
> >> >> >> > to Alex, who will mentor that task.
> >> >> >> 
> >> >> >> Correction, this would be Michael, according to the wiki.
> >> >> >
> >> >> > i was already confused when you said alex mentors it, but he can
> >> >> > surely play the powerless figurehead mentor if he likes, you know
> >> >> > my dislike for googles "i agree" licences
> >> >> >
> >> >> > back to the topic
> >> >> > a qual task for float support in the mpeg audio decoder would be to
> >> >> > convert dct32() as it is to float AND also implement dct32() in SSE
> >> >> > and by using our generic fft/dct code. We dont know which of these 3
> >> >> > would end up faster and this will be needed for the float mpeg audio
> >> >> > project anyway so its not really extra work.
> >> >> > (yes you should know a bit x86 asm for this project otherwise the
> >> >> > resulting code would not be competetive on modern desktop systems)
> >> >> 
> >> >> If the generic fft/dct code can be used, all manner of asm
> >> >> optimisations will come for free.
> >> >
> >> > i wonder how much speed we would loose if the generic dct code
> >> > where used for our 8x8 dct. 
> >> 
> >> Quite a lot, I'd guess.
> >> 
> >> > also theres more code that needs to be written in simd in mp3, the
> >> > antialias filter is one example
> >> 
> >> Yes, the mp3 decoder could easily be made much faster with SIMD.The
> >> catch is, any CPU with SIMD is fast enough to decode mp3 without
> >> breaking a sweat, so there is little motivation other than pride to
> >> do this.
> >
> > faster mp3 decoding means more cpu time for the video decoder
> 
> When mp3 decoding takes only 1% or so, optimising it will only be able
> to give you 1% more time for video. 

true, and we are happy about every 0.1% we can get for faster h264 decoding
here we should be able to get more than 0.1% speedup, this does seem worth
to me and not just pride. Thats just my oppinion if course...

if i would not have done any optimizations in h264*c that where less
than 1% than the code would be significantly slower now.


> Besides, films tend to use AAC,
> AC3, or DTS these days.

sure but mp3 is still quite a step above the average in ffmpeg, if one
looks at all thouse obscure codecs we support

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100329/d5a5fa1f/attachment.pgp>