OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: tovarish on February 22, 2007, 04:58:07 pm
-
Hi all
For work i was in the process of porting ffmpeg to various platforms so i thought why not do it for the zaurus too. The only problem i encountered was that the pdaxrom gcc (beta 1 edition) crashed (????? ) when optimisation level -O3 was used. I changed that to -O2 and it compiled fine.
From my tests on my c860 i found that results were a bit better than mplayer if i played the video outside x. the video should also be 320x240 max resolution.
Let me know if you guys find it faster than mplayer. I have not included anything other than the codecs included in ffmpeg itself.
On other news i will look at the scource code of tcpmp a nice media player for palm and ppc to see if i can port it in parts. I cant imagine that my loox 720 ppc undeclocked to 312Mhz plays videos better than zaurus at 400Mhz.
Tovarish
PS sorry no ipk as it just is one executable that can be put anywhere.
-
Will it work with other ROMs? Is it just "ffplay file.avi"?
Thanks
-
tried it with a couple of divx encodes at 320x240 but the a/v just go out of sync really badly - can't work out how to frameskip.
Is there any way of using the bvdd driver with this?
Nice to have an alternative to mplayer.
-
Answered my own question, on the Sharp ROM it complains of a missing shared library.
-
I tried this in commandline and it complained about missing libSDL-1.2.so.0
------------------------------------------------------------
ffplay highlands-320x240.avi
error while loading shared libraries: libSDL-1.2.so.0
------------------------------------------------------------
The first time I tried ffplayer was in smplayer.
smplayer allows you to choose the player executable in prefrences.
Naturally, it didn't work because the above library isn't installed on my system.
I'm running pdaxcii13-akita5.3 (It's a basic install without a lot of stuff included).
EDIT:
I installed sdl_1.2.9_armv5tel.ipk
Now the missing library error is gone, but my short clip gives this error. It plays with mplayer.
------------------------------------------------------------
I/O error occured.
Usually this means that the input file is truncated and/or corrupted
------------------------------------------------------------
EDIT2:
Playing an *.mp4 file, I get this error.
------------------------------------------------------------
Xlib extension "XVideo" missing on display ":0.0".
------------------------------------------------------------
This video does play, without sound.
This is the only time I have been able to play this particular video on a Zaurus, without a third of the screen cropped off.
The aspect ratio was true to the actual video.
All versions of mplayer. (pdaxrom, cacko/kino, or cacko/zplayer) chopped off a third of the screen.
-
i am playing videos encoded with divx or xvid along with mp3 for audio.
It only depended on sdl and i thought that was installed by default.
It wont work in other roms as it links to sdl compiled with vpf
-
The reason I'm trying different video players is because I don't want to re-encode every video that I download, or my entire "Lost TV series" collection which has 62 videos now.
The highlands-320x240 is a game capture divx 5.0
The *.mp4 file is a poker tutorial that I downloaded from a poker site.
All the "Lost TV series" videos are xvid videos
Kino with mplayer plays most of my short clips, but has problems with the "Lost" videos.
Are you still going to try to port TCPMP?
I can play my Lost videos on my Palm using TCPMP.
-
yeah i am looking at it, i compiled all their non wince, palmos code but i am thinking how i can glue the ui. the only c++ ui i know well is qt and qt seems a little heavy for zaurus. maybe i'll skip ui altogether and use ffplay code to glue it.
btw tcpmp uses ffmpeg and even an older version that. it does have more audio codecs and that could explain audio working in palmos tcpmp.
------------------------------------------------------------
Xlib extension "XVideo" missing on display ":0.0".
------------------------------------------------------------
is available only when the xserver has hardware video extensions. we have to wait till oz gets a working xserver with xvideo which should help video playback a lot. it is just a warning thats all.
as such until good harware video extensions are possible we can say goodbye to >320x240 videos and >512kbps bitrates in the zaurus.
I did a lot of work wrt video playback on the zaurus and the bottleneck is indeed screen drawing. atty's mplayer and my optimised mplayer compile is well capable of decoding videos 640x480 and ~768kbps bitrates but really screws up in drawing.
-
Does this mean that if tcpmp gets compiled, we can play 640x480 videos at over 300kbps? Or am I reading that wrong?
-
I did a lot of work wrt video playback on the zaurus and the bottleneck is indeed screen drawing. atty's mplayer and my optimised mplayer compile is well capable of decoding videos 640x480 and ~768kbps bitrates but really screws up in drawing.
On the other hand, screen drawing performance is not so critical as decoding. It is possible to skip drawing of some frames on heavy video, but you cant skip decoding without getting some very ugly artefacts on screen. Also screen drawing performance can be probably improved a lot, it takes ~20% cpu resources or less than that on Nokia 770 now (with hardware YUV colorspace support and JIT accelerated software scaling), from what I read, Zaurus should have at least comparable capabilities if not better.
As for decoding performance. My observations show that increasing resolution has much higher impact on performance than bitrate (low resolution videos can have bitrate way higher than 1000kbps and play nicely, but 640x480 even with a low bitrate is a challenge). Also how did you check that mplayer is capable of decoding this video? Just running it with -benchmark option and verifying that decoding took less time than video clip length is not enough for smooth playback. Resources consumption for decoding can vary between different frames a lot, the most complicated scenes are those which contain a lot of panning and motion. So you can get really bad performance on some scenes while cpu would be used quite low on the others. On of the examples of such videos is Doom clip that was used to test mplayer performance on some devices here: https://www.oesf.org/forums/index.php?showtopic=22280 (https://www.oesf.org/forums/index.php?showtopic=22280)
I don't know if TCPMP is that much better inherently (and if video output is the real bottleneck, TCPMP would crawl too until it gets optimized video output). Probably just optimizing mplayer and ffmpeg can result in comparable results.
-
I did a lot of work wrt video playback on the zaurus and the bottleneck is indeed screen drawing. atty's mplayer and my optimised mplayer compile is well capable of decoding videos 640x480 and ~768kbps bitrates but really screws up in drawing.
On the other hand, screen drawing performance is not so critical as decoding. It is possible to skip drawing of some frames on heavy video, but you cant skip decoding without getting some very ugly artefacts on screen. Also screen drawing performance can be probably improved a lot, it takes ~20% cpu resources or less than that on Nokia 770 now (with hardware YUV colorspace support and JIT accelerated software scaling), from what I read, Zaurus should have at least comparable capabilities if not better.
As for decoding performance. My observations show that increasing resolution has much higher impact on performance than bitrate (low resolution videos can have bitrate way higher than 1000kbps and play nicely, but 640x480 even with a low bitrate is a challenge). Also how did you check that mplayer is capable of decoding this video? Just running it with -benchmark option and verifying that decoding took less time than video clip length is not enough for smooth playback. Resources consumption for decoding can vary between different frames a lot, the most complicated scenes are those which contain a lot of panning and motion. So you can get really bad performance on some scenes while cpu would be used quite low on the others. On of the examples of such videos is Doom clip that was used to test mplayer performance on some devices here: https://www.oesf.org/forums/index.php?showtopic=22280 (https://www.oesf.org/forums/index.php?showtopic=22280)
I don't know if TCPMP is that much better inherently (and if video output is the real bottleneck, TCPMP would crawl too until it gets optimized video output). Probably just optimizing mplayer and ffmpeg can result in comparable results.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=155116\"][{POST_SNAPBACK}][/a][/div]
they are all based on ffmpeg anyway so ffplay, tcpmp, mplayer, etc.. all will have similar performance depending on the compile time optimisations and/or build options as well as the cvs/svn version they are based on...
-
yeah meanie is right all of them aer basically based on ffmpeg. I did see however that tcpmp has a lot of assembly optimisations so that will help.
I have tested mplayer with various optimisation levels on atty's 1.1.5 code and found that video decoding time (with -benchmark, 640x480, 768k) is quite less than the playtime. if you say this is not accurate enough i have no other way of benchmarking. For both the cxxx and cxxxx models we have w100 (capable of mpeg4 decoding) and intel's graphics support so theoretically they are well capable of playing videos but i havent yet seen as good video playback as on my wm2003 fs loox 720 even at 312Mhz underclocked.
speaking of optimisation do other people experience problems with the compiler included with beta1 (pdaxromsdk) wrt -O2,-O3. lot of apps cause the compiler to crash on high optimisation levels (sdlheretic, ffmpeg, etc.)
-
they are all based on ffmpeg anyway so ffplay, tcpmp, mplayer, etc.. all will have similar performance depending on the compile time optimisations and/or build options as well as the cvs/svn version they are based on...
As far as I know, TCPMP has both its own optimized decoders (better optimized) and ffmepg (better compatibility).
But I still think that ffmpeg has a good potential for further optimizations on ARM devices. Some ARM related optimizations were added recently (can be in MPlayer 1.0rc1), some are still in SVN and will be available when the next version of MPlayer gets released. Even more optimizations will be added later.
Right now 252MHz Nokia 770 is quite good for video playback (using mplayer), it is almost able play 512x384 videos smoothly. Anything lower than that can be watched more or less successfully. A newer model, 330MHz Nokia N800 has no problems with 512x384 videos (but it still has very annoying problems with tearing because of improper vsync).
-
speaking of optimisation do other people experience problems with the compiler included with beta1 (pdaxromsdk) wrt -O2,-O3. lot of apps cause the compiler to crash on high optimisation levels (sdlheretic, ffmpeg, etc.)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=155131\"][{POST_SNAPBACK}][/a][/div]
Check the memory used by GCC while compiling. The higher optimisation levels need more memory, and I think there's at least one option which makes the memory requirements skyrocket.
-
PS sorry no ipk as it just is one executable that can be put anywhere.
i take this is for armv5 ?? as i tried running it on 5500 and got nothing but "Illegal Instruction"