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

Peter Kraker peter.kraker at volja.net
Thu Apr 24 14:10:54 CEST 2008


As written by raster, you can play video at lower resolution. Also 
implementing support for mpeg4 should help a great deal.

David Samblas Martinez pravi:
> 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?
>
> --- 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
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20080424/2f11b320/attachment.htm 


More information about the community mailing list