[FFmpeg-devel] GSoC Participation

Måns Rullgård mans
Mon Mar 29 03:10:28 CEST 2010


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.

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



More information about the ffmpeg-devel mailing list