[FFmpeg-devel] GSoC Participation

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> 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...

I'm not going stop anyone who wants to simdify ffmp3.  I might even do
it myself if I find myself bored one day.  However, things that people
actually want and/or pay for take priority.

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

I'm well aware of that.

>> 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

Many of those are barely optimised at all though.  I could probably
speed up VP5/6 by 20% or more if I tried.  I profiled it a while back,
and found some rather obvious things to improve.  Does anyone care?
I'm afraid I forgot the details...

-- 
M?ns Rullg?rd
mans at mansr.com