OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

5 Pages V  « < 3 4 5  
Reply to this topicStart new topic
> Mplayer Development And Optimization For Arm
speculatrix
post Sep 4 2007, 01:03 PM
Post #61





Group: Admin
Posts: 3,281
Joined: 29-July 04
From: Cambridge, England
Member No.: 4,149



could there be other factors affecting memory access - ensuring the right word size is used and not just aligning on the correct byte boundary, reading the data in the right size chunks to make best of use of any arm caching and pre-fetch logic in the CPU?

the Z has got quite poor CF speed as (so I understand) it shares bus cycles with the main memory, the SD slot is faster because it's a separate bus off the CPU.
Go to the top of the page
 
+Quote Post
XorA
post Sep 20 2007, 05:46 AM
Post #62





Group: Members
Posts: 101
Joined: 23-June 04
Member No.: 3,800



Todays SVN mplayer with rev 257 of IDCT code produces there benchmarks.

Im thinking this is an improvement.

Machine is SL-C3200 Zaurus

mplayer -nosound -vo null -quiet -benchmark -loop 12 -lavdopts idct=16 matrixbench_normdivx_vbrmp3.avi | grep BENCHMARKs
BENCHMARKs: VC: 186.320s VO: 0.064s A: 0.000s Sys: 2.718s = 189.103s
BENCHMARKs: VC: 188.632s VO: 0.065s A: 0.000s Sys: 3.130s = 191.827s
BENCHMARKs: VC: 188.897s VO: 0.065s A: 0.000s Sys: 2.742s = 191.704s
BENCHMARKs: VC: 189.111s VO: 0.065s A: 0.000s Sys: 2.710s = 191.886s
BENCHMARKs: VC: 188.934s VO: 0.065s A: 0.000s Sys: 2.699s = 191.698s
BENCHMARKs: VC: 189.177s VO: 0.064s A: 0.000s Sys: 2.727s = 191.968s
BENCHMARKs: VC: 188.932s VO: 0.064s A: 0.000s Sys: 2.725s = 191.721s
BENCHMARKs: VC: 189.237s VO: 0.064s A: 0.000s Sys: 2.705s = 192.007s
BENCHMARKs: VC: 188.937s VO: 0.066s A: 0.000s Sys: 2.707s = 191.709s
BENCHMARKs: VC: 189.076s VO: 0.065s A: 0.000s Sys: 2.717s = 191.857s
BENCHMARKs: VC: 189.161s VO: 0.065s A: 0.000s Sys: 2.713s = 191.939s
BENCHMARKs: VC: 189.101s VO: 0.065s A: 0.000s Sys: 2.721s = 191.887s
Go to the top of the page
 
+Quote Post
zap
post Nov 6 2007, 07:00 AM
Post #63





Group: Members
Posts: 3
Joined: 3-November 07
From: St. Petersburg, Russia
Member No.: 20,892



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.
Go to the top of the page
 
+Quote Post
zap
post Nov 6 2007, 02:50 PM
Post #64





Group: Members
Posts: 3
Joined: 3-November 07
From: St. Petersburg, Russia
Member No.: 20,892



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.
Go to the top of the page
 
+Quote Post
Serge
post Nov 6 2007, 11:26 PM
Post #65





Group: Members
Posts: 51
Joined: 8-October 06
Member No.: 11,724



Hello zap,

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).

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.

TCPMP might be an interesting option (for somebody else to try), but I'm satistied with mplayer/ffmpeg on Nokia 770 and N800 at the moment. Translating mplayer performance on Nokia 770 to 'TCMP percents', it would be something like 118%, and if we try to estimate how it would theoretically run at 624MHz, that would be ~290%. I know that this approximation is wrong as memory speed also does matter a lot, but anyway, looks like both TCPMP and ffmpeg should provide at least comparable performance.

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).
Go to the top of the page
 
+Quote Post
zap
post Nov 7 2007, 10:23 AM
Post #66





Group: Members
Posts: 3
Joined: 3-November 07
From: St. Petersburg, Russia
Member No.: 20,892



QUOTE(Serge @ Nov 7 2007, 10:26 AM) *
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(Serge @ Nov 7 2007, 10:26 AM) *
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(Serge @ Nov 7 2007, 10:26 AM) *
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.
Go to the top of the page
 
+Quote Post
tjchick
post Nov 13 2007, 02:38 PM
Post #67





Group: Members
Posts: 14
Joined: 9-May 06
Member No.: 9,821



Just a quick update from me, mostly of interest to the angstrom people...

You may remember I hacked mplayer/ffmpeg to actually use iwmmxt rather than just compiling them.

I got VC times of apx 43 seconds for the doom clip running on angstrom.

Now I am using *the same binary* and get VC times of 37 seconds on the latest Angstrom test images, so something has changed, maybe cache support or iwmmxt support in the kernel. Anyhow, my results are now about the same as my tests on cacko with attys mplayer.

If I use the default mplayer included in the angstrom iwmmxt feeds, I see VC of 52 seconds. I'm going to take a look, and try the svn version.

Cheers,
Tim
Go to the top of the page
 
+Quote Post
speculatrix
post Nov 13 2007, 02:59 PM
Post #68





Group: Admin
Posts: 3,281
Joined: 29-July 04
From: Cambridge, England
Member No.: 4,149



good news indeed, anything which improves the media performance on the zaurus is great!
Go to the top of the page
 
+Quote Post

5 Pages V  « < 3 4 5
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 30th September 2014 - 03:59 AM