Video of Qt 4.4 on Neo1973: brings iPhone like graphics
Carsten Haitzler (The Rasterman)
raster at openmoko.org
Thu Apr 24 10:39:05 CEST 2008
On Thu, 24 Apr 2008 09:24:26 +0200 polz <polz at aufbix.org> babbled:
> On Thursday 24 April 2008 05:52:52 Carsten Haitzler wrote:
> > On Wed, 23 Apr 2008 18:28:40 +0200 thomasg <thomas at gstaedtner.net> babbled:
> > yup. those 7m/sec (that's write to video ram) is also shared with SD card
> > IO.
> Correct me if I'm wrong, but it seems to me that this means it should be
> impossible to playback videos in full-screen from an SD card on a gta02.
> 640*480*25 = 7680000 and that's with 8bpp.
> Has anyone tested video playback on a GTA02 yet ?
correct. yuv will be w * h * 1.5 bytes for 1 frame (standard video yuv). so
3240x240*1.5*30 (320x240 @ 30fps) = 3.4m/sec - BUT... when u are copying you
have ZERO cpu cycles to decode the next video frame. so that means 50% of cpu
cycles will be spent ONLY copying video data to video ram. the other 50% u have
left to decode the mpeg1/2/4 or whatever video in system ram to a yuv buffer. i
would say this is the realistic highest resolution you will get. 480x320 at 30fps
is the MOST you will get (6.9m/sec), but u have ZERO (or almost) cpu cycles to
actually decode the video into yuv.
remember here i am assuming use of xvideo and the yuv to rgb conversion and
scaling on the glamo - which xglamo does support. if you do software yuv->rgb +
scale then its even less fun. with software. the best u will get is 11fps at
640x480 - and this is NO cpu cycles to actually decode the video, convert it to
16bit rgb and scale. in reality i expect you to see 2-5fps in this scenario,
maybe eve 1fps.
this is ONLY playback if the video data is already in ram - ie the mpeg data is
cached. if it is read off internal flash you will pay an IO cost - but it's not
shared with the glamo bus. if it is on SD card - you will basically have to now
share the IO between SD and graphics. i believe the graphics IO takes
precedence over SD card IO, so as long as u keep the glamo gfx bus busy, sd
will be on hold until u stop. then some sd io can get through.
with the glamo you need to be careful what you do and how you do it. if you can
keep something entirely within the glamo - it should be ok. so things like
uploaded pixmaps and then blitting them around is ok. video decode is another
matter entirely. the glamo has an mpeg4 decoder on it - but we don't have any
api to access that directly/sanely and just feed it an mpeg4 stream. any other
codec has to be done on the cpu anyway and uploaded across the bus as yuv data.
Carsten Haitzler (The Rasterman) <raster at openmoko.org>
More information about the community