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

Carsten Haitzler (The Rasterman) raster at openmoko.org
Thu Apr 24 13:20:12 CEST 2008


On Thu, 24 Apr 2008 11:19:37 +0200 Christoph Witzany <mail at doublemalt.net>
babbled:

> 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.

that is quite possible. 320x240 video would be sane possibly if the source is
internal flash instead of SD or maybe 802.11.

> 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).

well we could quietly say nothing and wait until you find out, but my position
is just to put the facts out as-is and give you my best interpretation of them.

remember every other $100 phone is *NOT* $100 - it is $300 or $400 or $500 - it
is SUBSIDISED by the carrier. when you sing up saying you will pay the telco
money for the next 12 or 24 months, they subsidies the phone. when the carrier
tells the phone maker "disable this feature so the customer HAS to pay us to
send their photos via email, instead of just using usb or sd-cards" they
subsidise it further hoping/knowin they will xtort more money from you in
services etc. etc. if you want the REAL cost - ask the carrier what you would
pay for the phone with NO contract, or find a shop that sells the same phone
"unlocked".

secondly these "$100" phones are mostly QVGA, not VGA. we have to fill/drive 4
times as many pixels as they do.

thirdly - they don't (mostly) offer wifi. in fact they don't do a lot the
freerunner does. an actual $100 phone (that is $100 when unlocked) does very
very very very little - the $100 ones u think of are actually much more.

> I think that this design should be reconsidered as soon as possible if 
> Openmoko really wants to go into the consumer market.

it can't be. it's too late in production. freerunner is as-is. with the good
and the ugly. we are open about it and at least give you the option of doing
something about it, and knowing in advance all the gory details.

> 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?

you will be able to manage 320x240 at 30fps i expect streamed video. of course if
you lower the framerate you can increase the resolution. you can do the math
(with 15fps you get 2x the pixels - 448x336 at 15fps for example, 640x480 at 7.5fps
etc.).

again - we could do better if we limited ourselves to just mpeg4 (which is what
almost all phones do - they do only 1 codec or maybe 2), but the problem here
is that xv does not provide a way to do this sanely (stream just mpeg4 data to
x so it decodes in hardware). the graphics chip (glamo) can decode mpeg4
itself, but we dont have the time or resources to do this properly ourselves.
you are free to do it yourself as we provide all the code, but you would need to
reverse-engineer the graphics chip or hope that graphics documentation can be
made public. right now you need an NDA to see the docs.

> 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


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




More information about the community mailing list