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

[Christoph Witzany]

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