Video Playback virtually impossible on Neo Freerunner? (Re: Video of Qt 4.4 on Neo1973: brings iPhone like graphics)

[Carsten Haitzler (The Rasterman)]

On Thu, 24 Apr 2008 12:44:50 +0200 (CEST) David Samblas Martinez
<dsamblas at yahoo.es> babbled:

> I'm gonna still buy the freerunner when as soon as it
> become avialble and I will work as hard as my
> non-linux-freak life let me do it.
>  
> But I have to admit than this video limitation in the
> neo's video  has dissapoint me very deeply.
> 
> The good news is that I have been disapointed BEFORE I
> have bought the neo and even Before the freerunner is
> released so OM gives me the oportunity to decide and
> evaluate if this is a stopper to buy this phone or
> not.
>  
> Can any of the core team confirm this video
> limitations?

did you read my mail? :) it has limitations. i detailed them in my previous
email. :) (yes - i'm core team).

> --- Christoph Witzany <mail at doublemalt.net> escribió:
> 
> > As I understood Video playback will be virtually
> > impossible on the 
> > freerunner, at least from the sd card (which is the
> > only sensible 
> > location to store videos on the neo ftm).
> > 
> > Please correct me if I misunderstood.
> > 
> > Well that could have the potential to kill the
> > Freerunner as consumer 
> > product. Just because virtually every other 100$
> > phone does it which is 
> > shaping the consumers' expectations.
> > And while I do not expect to use this feature more
> > than a couple times a 
> > month it would make me reconsider using it as my
> > main phone (I'll be 
> > using it as development platform, so it doesn't
> > matter for now).
> > 
> > I think that this design should be reconsidered as
> > soon as possible if 
> > Openmoko really wants to go into the consumer
> > market.
> > 
> > PS: What about streaming media from the net? Any
> > musings and/or actual 
> > experiences with that? If I interpreted Carsten
> > right 640x480 video will 
> > display at 5-10 fps at best, right?
> > 
> > 
> > Carsten Haitzler (The Rasterman) schrieb:
> > > 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.
> > >
> > >   
> > 
> > 
> > _______________________________________________
> > Openmoko community mailing list
> > community at lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> > 
> 
> 
> 
>       ______________________________________________ 
> Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
> 
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>