Video of Qt 4.4 on Neo1973: brings iPhone like graphics

[thomasg]

According to the SD problem:
As far as I know emdete has noticed exactly what you assume.
Reading from the SD while using the display heavily (in his case this was a
VGA Edje/Evas gui) isn't really possible - the display will work, but the SD
won't get any bandwith, so transfer will be extremely slow or stop
completely.

On 4/24/08, The Rasterman Carsten Haitzler <raster at openmoko.org> wrote:
>
> 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>
>
>
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20080424/8b67a767/attachment.htm