Quote:
Quote:
Quote:
All I can say is that I can get acceptable video performance with my smartbook and MPlayer. Make sure that you use the default X11 output in MPlayer. Using other outputs (for example GL or GL2) is a bad idea.
You can also try the Android 2.2 image that was made available. It can play some movies (codes issues probably) and smartbook is able to play them correclty.
With x11 output in MPlayer, I get at most 0.1fps on a 700mb 2h mpeg2 video. I don't consider that acceptable. Xv doesn't work at all.
Thanks for the advice, but Android is useless on a netbook, and I don't want to dual boot (is that possible btw?) just to play video.
Afaict, there's no hardware acceleration at all going on. I note that now, the efika mx netbook page on genesi's site states that there isn't yet software support for the hardware decoding. I wonder when it'll happen.
Xv is disabled because it locks the system specifically (we did have it enabled in the past but some kernel finagling seems to have broken it) and in general, it steals memory bandwidth for the VPU and IPU - we are working on a new driver which uses GPU texturing to render the video data and offload the bus (and the conversion) from that arbiter and those IP cores.
Multimedia acceleration is a twofold problem - first of all, that what we ship has to absolutely work out of the box, that means you pick a video file, it plays, it does not crash the system. You get that now, it's just sloooow because it's all done on the CPU.
Second of all, several media codecs are patented and to ship software that plays them we have to pay patent royalties to people like the MPEG LA, Thomson, Fraunhofer, Apple. Some of this isn't set up so if we shipped *today* we'd have accelerated video codecs but no audio codecs, and this means playing video becomes rather pointless in the end..
Once they're resolved we'll release. Current work focuses on the 2D driver (new Xv overlay method) and a kernel update.
as iv said before matt , you and markos, after all who better than the proven SIMD freevec dev should be helping out the ARM x264 and ffmpeg/libav VLC dev's port and write new NEON SIMD right now over on their IRC dev channels.
then this slow video playback speed would improve immensely and in a very short time, they need ARM NEON mentor's to step up and help out for GSOC for instance and Genesi customer's would benefit very quickly, for very little outlay on your part...
http://wiki.videolan.org/SoC_x264_2011
keep in mind virtually all the x264 SIMD gets taken and ported to or used directly by all the other video app's in use today, especially ffmpeg/libav and even the virtually unmaintained Mplayer takes and port's it's code from these too.
you could do a lot worse than also get Daniel <Jumpyshoes> Kang the 17 year old GCI student (that came to x264 knowing very little about SIMD and yet ended up writing the 10bit and AVX SIMD routines so speeding the APP up a lot with mentor instruction from <Dark_Shikari> within 2 days or so) an efika laptop etc and have markos mentor him for the ARM cortex NEON SIMD.
Daniel had stated on IRC etc he wants to learn ARM cortex NEON SIMD and port all his x86 SIMD routines to that too, but <Dark_Shikari> doesn't know that NEON and no other ARM dev has stepped up to date, and no kit to develop and test that code on OC.
given all the unit's bill have given out to date , it seems like a very odd thing to miss this simple option.
... to hang out on IRC, keeping a log of any questions and comments etc that pop up there, give a net-book and mentor a student that is willing and able and will port his SIMD to ARM NEON x264, FFmpeg/Libav, and perhaps even VLC if you encourage and ask he try and do that and make CPU NEON SIMD video playback so much better and faster, and OC no problem with end users installing and using that until you can sort out any legal HW playback licence problem's.
will you,markos and bill arrange and do that ?, then simply pop over to the #x264dev and libAVdevel (where lu_zero resides mostly today it seems) IRC channel's and get things moving..., there should be some real results within days or weeks if he's mentored and supported properly, it's not like he can even do the GSOC this year and get payed as he's not old enough to take part.
OC finally porting
yasm to ARM cortex might also help get over that speed bump too as they use that were ever possible on the x86 port code, if some cortex NEON dev can be bothered to make the effort OC.
BTW what does a current git pull of the x264 and a simple compile make
checkasm --bench
result show on efika today ?, anyone care to post a permanent
http://pastebin.com link of that to get an i.mx5 baseline and see if and when the speed improves given the limited NEON SIMD that's in there right now.
Login
Register
FAQ
Search