Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (5)
to General by teroyk - 6 days, 19 hrs ago - more...
|
2006-07-14
, 00:15
|
|
Posts: 503 |
Thanked: 267 times |
Joined on Jul 2006
@ Helsinki
|
#22
|
Updated mplayer binary: http://ufo2000.xcomufo.com/files/mpl...4-armel.tar.gz
Changes:
* added screen blanking prevention hack
* added support for hardware pixel doubling in fullscreen mode with x11 driver ('-vo x11' option)
Now when playing 320x240 or 400x240 video, x11 driver with hardware pixel doubling is prefered and it works faster than sdl (see my previous post for more benchmarking details). The only problem with pixel doubling is lack of flexibility, it only can scale video exactly twice. So discovery video in fullscreen mode with x11 driver is a bit smaller than screen size and has black borders, but at least it can be played without a single frame dropped.
Note: if you tried a previous build, also delete old configuration file: 'rm /home/user/.mplayer/config', a new build has a new option in configuration file enabled by default (-noslices), see mplayer man for more details. It improves performance a bit and seems to be absolutely necessery for proper framedropping with hardware pixel doubling when playing very high bitrate/framerate video. Without this option enabled, some video frames freeze and we get slideshow.
A patch with all these tweaks for mplayer 1.0pre8 sources is included in a tarball. Enjoy
Changes:
* added screen blanking prevention hack
* added support for hardware pixel doubling in fullscreen mode with x11 driver ('-vo x11' option)
Now when playing 320x240 or 400x240 video, x11 driver with hardware pixel doubling is prefered and it works faster than sdl (see my previous post for more benchmarking details). The only problem with pixel doubling is lack of flexibility, it only can scale video exactly twice. So discovery video in fullscreen mode with x11 driver is a bit smaller than screen size and has black borders, but at least it can be played without a single frame dropped.
Note: if you tried a previous build, also delete old configuration file: 'rm /home/user/.mplayer/config', a new build has a new option in configuration file enabled by default (-noslices), see mplayer man for more details. It improves performance a bit and seems to be absolutely necessery for proper framedropping with hardware pixel doubling when playing very high bitrate/framerate video. Without this option enabled, some video frames freeze and we get slideshow.
A patch with all these tweaks for mplayer 1.0pre8 sources is included in a tarball. Enjoy
|
|
2006-07-14
, 03:23
|
|
Posts: 220 |
Thanked: 19 times |
Joined on Jun 2006
|
#23
|
iv downloaded a google video for psp i can play it with -nosound or at a reduce framrate. my question is can i set up a codecs.conf file to use the audio codecs that came with the nokia 770.any sugestions would be great
|
|
2006-07-14
, 13:50
|
|
Posts: 2,152 |
Thanked: 1,490 times |
Joined on Jan 2006
@ Czech Republic
|
#24
|
This is really good. Plays Futurama at 320x240,25fps,304kbits. Some action scenes (the beginning) are slower but generally it is quite watchable. i wonder how expensive is the 'SwScaler: using unscaled Planar YV12 -> BGR 16-bit special converter' part.
I also wonder if YV12->YUV422 or ->YUV420 conversion is much faster than ->BGR
If yes the some hack with using directly OMAPFB_UPDATE_WINDOW ioctl with YUV420 or 422 format could speed it up in fullscreen mode
I also wonder if YV12->YUV422 or ->YUV420 conversion is much faster than ->BGR
If yes the some hack with using directly OMAPFB_UPDATE_WINDOW ioctl with YUV420 or 422 format could speed it up in fullscreen mode
|
|
2006-07-14
, 14:46
|
|
Posts: 2,152 |
Thanked: 1,490 times |
Joined on Jan 2006
@ Czech Republic
|
#25
|
hmm, looks like YV12 is in fact something like YUV420 (whatever that means exactly :) so the conversion is probably trivial
http://www.fourcc.org/fccyuv.htm#YV12
http://msdn.microsoft.com/library/de...YUVFormats.asp
also from the MS article it is clear that yuv->rgb conversion is not so trivial
Last edited by fanoush; 2006-07-14 at 14:55.
http://www.fourcc.org/fccyuv.htm#YV12
http://msdn.microsoft.com/library/de...YUVFormats.asp
also from the MS article it is clear that yuv->rgb conversion is not so trivial
Last edited by fanoush; 2006-07-14 at 14:55.
|
|
2006-07-14
, 15:05
|
|
Posts: 503 |
Thanked: 267 times |
Joined on Jul 2006
@ Helsinki
|
#26
|
2smackpotato: don't know, Nokia 770 uses gstreamer multimedia framework, don't know if mplayer can use gstreamer plugins directly (but mplayer probably can be patched to make some use of them)
2fanoush: Thanks, that is interesting idea. Anyway, we are probably already at ARM core limits (though maybe some time critical parts of decoder can be optimized using armv5 edsp instructions, mplayer uses only armv4 in assembly optimized code fragments). Now in order to improve performance, it would be a good idea to move some work to DSP core (preferably moving color conversion/scaling work to it). We can either try finding a way of using existing DSP based audio codecs from mplayer, or try it the other way around - experiment with compiling ffmpeg based gstreamer plugin and replacing default mpeg4 DSP based decoder with it.
As we don't have a free toolchain for DSP programming, most of the nontrivial parts of code and complicated video codecs would have to be implemented using ARM core. But scaling/color conversion seems to be a relatively simple and well defined task that could be implemented using DSP and reused for any codec. I wonder if DSP can have access both to a memory fragment with a frame decoded by ARM core and to video memory buffer to do this work (from what I read, DSP is only 16-bit cpu, I wonder what addressing modes it supports). And this task could be run simultaneously with decoding the next frame.
Well, everything written above is just a pure speculation It is only a few days passed since I even had a look into mplayer internals. And I have absolutely no prior knowledge about multimedia compression algorithms or even color formats, so I'm sorry for possibly posting here some stupid things All that started from 'hey, it is quite easy to compile mplayer, here is the binary' and turned into fine tuning it into something useful in the end
2fanoush: Thanks, that is interesting idea. Anyway, we are probably already at ARM core limits (though maybe some time critical parts of decoder can be optimized using armv5 edsp instructions, mplayer uses only armv4 in assembly optimized code fragments). Now in order to improve performance, it would be a good idea to move some work to DSP core (preferably moving color conversion/scaling work to it). We can either try finding a way of using existing DSP based audio codecs from mplayer, or try it the other way around - experiment with compiling ffmpeg based gstreamer plugin and replacing default mpeg4 DSP based decoder with it.
As we don't have a free toolchain for DSP programming, most of the nontrivial parts of code and complicated video codecs would have to be implemented using ARM core. But scaling/color conversion seems to be a relatively simple and well defined task that could be implemented using DSP and reused for any codec. I wonder if DSP can have access both to a memory fragment with a frame decoded by ARM core and to video memory buffer to do this work (from what I read, DSP is only 16-bit cpu, I wonder what addressing modes it supports). And this task could be run simultaneously with decoding the next frame.
Well, everything written above is just a pure speculation
It is only a few days passed since I even had a look into mplayer internals. And I have absolutely no prior knowledge about multimedia compression algorithms or even color formats, so I'm sorry for possibly posting here some stupid things All that started from 'hey, it is quite easy to compile mplayer, here is the binary' and turned into fine tuning it into something useful in the end
 |
|
2006-07-14
, 16:39
|
|
Posts: 1,743 |
Thanked: 1,231 times |
Joined on Jul 2006
@ Twickenham, UK
|
#27
|
That's why Nokia chose to go open-source with the 770
|
|
2006-07-14
, 16:40
|
|
Posts: 1,743 |
Thanked: 1,231 times |
Joined on Jul 2006
@ Twickenham, UK
|
#28
|
oh and thanks a lot for the time spent in this..
|
|
2006-07-14
, 17:58
|
|
Posts: 220 |
Thanked: 19 times |
Joined on Jun 2006
|
#29
|
what director do we put additional codecs in. I want to a link to /lib/dsp/modules/aac.o in there. or am I barking up the wrong tree
|
|
2006-07-14
, 18:02
|
|
Posts: 2,152 |
Thanked: 1,490 times |
Joined on Jan 2006
@ Czech Republic
|
#30
|
Color conversion can be done directly by hwa742 chip. Would be nice to have more documentation about it though. I already wrote to email mentioned here
http://www.erd.epson.com/vdc/html/contents/S1D13742.htm but got no answer (no surprise :-).
Also I'm not sure but it looks like DSP doesn't send video to epson chip. It only draws it to shared framebuffer which is then send to the chip by kernel omapfb driver from videoplayer code. So if DSP doesn't decode mp4 video there is no reason to use it for other video steps since there is in fact nothing left to do.
DSP tools are free
http://www.gossamer-threads.com/list...pers/3938#3938
gstreamer is probably the right way to go (ffmpeg or other plugin using main cpu) but it doesn't mean patched mplayer is not useful. Currently it is not very clear how to display video with gstreamer on device (preferably also pixel doubled).
http://www.erd.epson.com/vdc/html/contents/S1D13742.htm but got no answer (no surprise :-).
Also I'm not sure but it looks like DSP doesn't send video to epson chip. It only draws it to shared framebuffer which is then send to the chip by kernel omapfb driver from videoplayer code. So if DSP doesn't decode mp4 video there is no reason to use it for other video steps since there is in fact nothing left to do.
DSP tools are free
http://www.gossamer-threads.com/list...pers/3938#3938
gstreamer is probably the right way to go (ffmpeg or other plugin using main cpu) but it doesn't mean patched mplayer is not useful. Currently it is not very clear how to display video with gstreamer on device (preferably also pixel doubled).
Also tried to run some benchmarks. Used discovery video without scaling for tests.
time ./mplayer -benchmark -nosound -vo null /home/user/MyDocs/.videos/Discovery.avi
Everything changes when showing scaled video, SDL time grows up to 49.67 seconds, X11 becomes a real slideshow and is unusable.
My tests also show that -mcpu=arm926ej-s is a bit faster than -march=armv5te, but not a big deal.
Last edited by Serge; 2006-07-13 at 06:46.