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 15:12:53 CEST 2008
On Thu, 24 Apr 2008 15:00:33 +0200 (CEST) David Samblas Martinez
<dsamblas at yahoo.es> babbled:
> I know and I'm sorry if I was missunderstood I'm not
> complaining about I will be unable to play video, I
> complaining about Have a 640x480 resolution screen and
> not able to play at 640x480 resolution.
no. but it can SCALE lower resolution video UP to 640x480. see my other mails.
> Well more than complaining about this is that I
> believe that with that cpu and graphical power I will
> be able to do that, maybe not now but developing the
> glamo drivers it would be posible, but today I realize
> that is a bus issue so no matter how much Hz and
> features drivers had read the sd and play
> 640x480x25fps at time doesn't fit in the "pipe", and
> we cannot change the tube.
> But again is all about my own expectations and the
> ignorace about the shared sd/graphics bus issue.
>
> Cuestions:,
> It will be able to play full screen at 480*320*25=5.6
> m/s ?
> 1.4 M/s is enought to read the video on the sd at same
> time??
see my other mail. 320x240 at 30fps is not possible. off sd card about 19fps is
the limit @ 320x240. 21fps if from internal flash. i did actual tests. mpeg4
video.
> I if I not wrong mp4 ratio is 16:1 so 1.4*16=22.4 max
depends on your compression quality. can be anything.
> raw video data in the 1.4 pipe so seems to be enough
> even for a less cpu eater video compresion.
nup. did benchmarks. you need cpu for the DECODE. every second u spend copying
data to video ram (the cpu does the copy - there is no usable dma. while the
cpu copies - it is not decoding). so if you fill up the glamo bus (7m/s) u will
do 0 decoding.
> I will be able to live with a little pixelation ;)(a
> lot of irony in this phrase in the era of youtube
> fullscreen videos on 1280x1024 screen)
>
>
> --- Peter Kraker <peter.kraker at volja.net> escribió:
>
> > 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
> > >
> > >
> >
> > > _______________________________________________
> > 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>
More information about the community
mailing list
