media-libs/a52dec is already using even EAPI-2. Please consider default enabling USE=djbfft for it, to get the performance benefits by default. Here's a short comparison on a 45 minute AVI file with A52 audio in it. It demonstrates that djbfft gets the job done 2.1 seconds faster, out of an unknown time (the 11.6 and 13.7 seconds include demuxing of AVI) - a quick test with sending demux output straight to fakesink instead of going through the a52 decoder results in 1.15sec, so I assume that's the time for all the non-A52-decoding parts, so it's small compared to the actual A52 decoding time. The mplayer one timing is for reference, and shows that they have a heavily patched liba52 that has various other acceleration variants available, including 3dnow! and SSE, that I'll file a separate bug for. I realize that mplayer does dump to file too, and gstreamer doesn't, but it's still much quicker with the SSE optimization in liba52. With mplayer (mplayer seems to have a liba52 copy that has a SSE optimized IDMCT transform) $ time mplayer -vo null -vc null -ao pcm:fast -benchmark test.avi ... Opening audio decoder: [liba52] AC3 decoding with liba52 Using SSE optimized IMDCT transform Using MMX optimized resampler AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000) Selected audio codec: [a52] afm: liba52 (AC3-liba52) ... BENCHMARKs: VC: 0.077s VO: 0.000s A: 5.751s Sys: 3.278s = 9.106s BENCHMARK%: VC: 0.8491% VO: 0.0000% A: 63.1538% Sys: 35.9971% = 100.0000% real 0m9.137s user 0m6.013s sys 0m1.077s Gstreamer using gst-plugins-a52dec, which in turn relies on media-libs/a52dec: With USE=-djbfft (the current default): $ time gst-launch-0.10 filesrc location=test.avi ! avidemux ! a52dec ! fakesink Setting pipeline to PAUSED ... No accelerated IMDCT transform found Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 13623398303 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... real 0m13.722s user 0m13.482s sys 0m0.220s After liba52dec is rebuilt to have USE=djbfft AND I manually patched gst-plugins-a52dec to enable MM_ACCEL_DJBFFT (going to gstreamer upstream with a patch separately): Setting pipeline to PAUSED ... Using djbfft for IMDCT transform Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 11475860134 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... real 0m11.599s user 0m11.306s sys 0m0.267s
I have filed http://bugzilla.gnome.org/show_bug.cgi?id=592787 for the gstreamer bits, for the default to make actual difference for some popular media players
No-one cares? :P Anyhow, from the GStreamer side, gst-plugins-a52dec flips the flag to use djbfft optimization in a52dec if available for a long time now, would be nice to have it enabled by default for users, as the "upstream" separate a52dec package doesn't have the SIMD optimizations found in mplayer internal fork and elsewhere, so most users would benefit from djbfft right now.
