[FFmpeg-devel] [PATCH 4/6] truehd: tune VLC decoding for ARM.

Michael Niedermayer michaelni at gmx.at
Thu Mar 20 12:33:24 CET 2014


On Thu, Mar 20, 2014 at 07:45:13AM +0100, Reimar Döffinger wrote:
> On 19.03.2014, at 22:39, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Wed, Mar 19, 2014 at 05:26:19PM +0000, Ben Avison wrote:
> >> Profiling on a Raspberry Pi revealed the best performance to correspond
> >> with VLC_BITS = 5. Results for overall audio decode and the get_vlc2 function
> >> in particular are as follows:
> >> 
> >>              Before          After
> >>              Mean   StdDev   Mean   StdDev  Confidence  Change
> >> 6:2 total     348.8  20.1     339.6  15.1    88.8%       +2.7%  (insignificant)
> >> 6:2 function  38.1   8.1      26.4   4.1     100.0%      +44.5%
> >> 8:2 total     339.1  15.4     324.5  15.5    99.4%       +4.5%
> >> 8:2 function  33.8   7.0      27.3   5.6     99.7%       +23.6%
> >> 6:6 total     604.6  20.8     572.8  20.6    100.0%      +5.6%
> >> 6:6 function  95.8   8.4      68.9   8.2     100.0%      +39.1%
> >> 8:8 total     766.4  17.6     741.5  21.2    100.0%      +3.4%
> >> 8:8 function  106.0  11.4     86.1   9.9     100.0%      +23.1%
> >> ---
> >> libavcodec/mlpdec.c |   13 ++++++++++---
> >> 1 files changed, 10 insertions(+), 3 deletions(-)
> > 
> > applied
> 
> This sounds to me like cache-tuning.
> The Raspberry Pi CPU is really tiny, calling it "optimize for ARM" seems like a misleading title.
> There is a good chance that with larger implementations the original values _might_ be faster, just like the smaller ones might be better with e.g. x86 Atoms.
> Note: not tested and thus I do not suggest any changes, but pointing out that basing this on CPU architecture is likely far from optimal in many cases.

maybe some kind of target cache size define could be added in/by
configure ?


also i had tested it on a i7 and the original was faster there
dont remember numbers but it wasnt a huge difference

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

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140320/5106a9ed/attachment.asc>


More information about the ffmpeg-devel mailing list