[FFmpeg-devel] GSoC Participation

Måns Rullgård mans
Mon Mar 29 15:57:19 CEST 2010


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.  Besides, films tend to use AAC,
AC3, or DTS these days.

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



More information about the ffmpeg-devel mailing list