Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - zap

Pages: [1]
1
Linux Applications / Mplayer Development And Optimization For Arm
« on: November 07, 2007, 01:23:59 pm »
Quote from: Serge
Please also try testing atty's build without '-lavdopts idct=16' option (it forces armv5te optimized idct from ffmpeg, but atty's build should be able to use a more efficient iwmmxt optimized idct from IPP).
I ran it without this option since I thought atty's mplayer uses the right idct transform by default. By the way, Angstrom' mplayer also seems to use the best idct transform by default, at least I haven't noticed any difference when running mplayer with and without this option.

Quote from: Serge
Anyway, as already mentioned in this thread, there is something wrong with mplayer running on Zaurus devices (or the devices with XScale core). For example, even Nokia 770 with 252MHz ARM9E cpu appears to be faster than Zaurus when playing this matrix video clip (time for decoding it is ~158 seconds). Though intuitively everything should be quite the opposite: Zaurus has a lot higher cpu clock frequency and supports iwmmxt SIMD instructions in addition to armv5te.
Tried the same clip on TCPMP on my old Dell Axim X5 (400MHz PXA255, 64Mb RAM). It shows 131.68% so indeed it looks like something is wrong on Zaurus, because my Dell Axim has a 100MHz bus and C3100 has AFAIK 143MHz bus (e.g. faster RAM).

Quote from: Serge
In order to get optimal mplayer performance on Zaurus, somebody just needs to profile it there (doing it with gprof is quite simple), find performance bottlenecks and try to fix them. I might have a look at what's wrong if I got XScale device to experiment with (I had plans to buy some motorola EZX phone, A1200 or E6, but these plans are on hold now).
I'll try to do that when time permits.

2
Linux Applications / Mplayer Development And Optimization For Arm
« on: November 06, 2007, 05:50:38 pm »
Took a look at tcpmp sources this evening. ffmpeg sources were not modified (except palmOS-specific hacks), so I believe the big speed difference is just because hx4700 is a quite fast device, or mplayer does something terribly wrong (?).

Aside from this, nothing interesting in tcpmp sources. Just a collection of codecs from various sources and the glue code. Lots of custom assembly for fast blitting and scaling.

3
Linux Applications / Mplayer Development And Optimization For Arm
« on: November 06, 2007, 10:00:22 am »
Did some benchmarks today in different environments.

Same command line as above, same video clip, mplayer 1.0 rc2 24587-r5, built by XorA (from Angstrom iwmmxt feed) gave about 181 seconds minimal time.

atty's mplayer on Cacko ROM gave about 162 seconds (same command line, same clip).

TCPMP on a iPAQ 4700 (624MHz PXA270 CPU) gave "228%" in benchmark mode, which translates, I think, to  187.64/2.28=82.3 seconds.

Serge, perhaps TCPMP is worth looking as well? As far as I know, it is open-source.

Pages: [1]