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
<[EMAIL PROTECTED]> babbled:
On Thursday 24 April 2008 05:52:52 Carsten
Haitzler wrote:
On Wed, 23 Apr 2008 18:28:40 +0200 thomasg
<[EMAIL PROTECTED]> 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. [EMAIL PROTECTED]
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@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
