[FFmpeg-devel] ALT_BITSTREAM_READER vs. A32 on ARMv4

Måns Rullgård mans
Sat Dec 27 20:57:10 CET 2008


"Mike ." <giac2000 at hotmail.com> writes:

>> To: ffmpeg-devel at mplayerhq.hu
>> From: mans at mansr.com
>> Date: Sat, 27 Dec 2008 11:10:17 +0000
>> Subject: Re: [FFmpeg-devel] ALT_BITSTREAM_READER vs. A32 on ARMv4
>> 
>> "Mike ." <giac2000 at hotmail.com> writes:
>> 
>> >> To: ffmpeg-devel at mplayerhq.hu
>> >> From: mans at mansr.com
>> >> Date: Fri, 26 Dec 2008 23:57:55 +0000
>> >> Subject: Re: [FFmpeg-devel] ALT_BITSTREAM_READER vs. A32 on ARMv4
>> >> 
>> >> "Mike ." <giac2000 at hotmail.com> writes:
>> >> 
>> >> > Hi.
>> >> >
>> >> > I'm decoding wma on ARMv4 using the ALT_BITSTREAM_READER.  The list
>> >> > indicates that the A32_BITSTREAM_READER should be faster, however in
>> >> > my testing its actually a bit slower.  Is there anything I'm missing
>> >> > (I simply forced the definition in bitstream.h to one or the other and
>> >> > benchmarked)?  Perhaps this is normal for ARM7TDMI?
>> >> >
>> >> > Also, whats different about the two readers?  I've started digging
>> >> > through them but I'm not really sure why they do things differently.
>> >> 
>> >> Using 32-bit aligned loads is often faster than several smaller loads
>> >> on architectures that do not support unaligned accesses.  Sometimes
>> >> extra processing overhead required to take advantage of this kills the
>> >> improvement.  The bitstream readers are unfortunately rather sensitive
>> >> to specifics of the CPU, so benchmarks are usually the only accurate
>> >> way to tell which is faster.
>> >> 
>> >> Please try all three bitstream readers and report your results.
>> >> 
>> >
>> > Thanks for the advice.
>> >
>> > My results (percent real time for a 192k WMAv2 track):
>> >
>> > LIBMPEG2_BITSTREAM_READER: 257.3%
>> >
>> > ALT_BITSTREAM_READER: 257.9% 
>> >
>> > A32_BITSTREAM_READER: 249.4%
>> 
>> This looks like A32_BITSTREAM_READER is the fastest on your CPU, or am
>> I misinterpreting your numbers?
>
> 100% is real time, so having higher percentages means its decoding faster.

Could you give numbers as absolute (user) time for the decode instead?
That is less confusing.

If you also could test some other codecs, that would be great.

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




More information about the ffmpeg-devel mailing list