<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
As written by raster, you can play video at lower resolution. Also
implementing support for mpeg4 should help a great deal.<br>
<br>
David Samblas Martinez pravi:
<blockquote cite="mid:704832.9970.qm@web27602.mail.ukl.yahoo.com"
 type="cite">
  <pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:mail@doublemalt.net">&lt;mail@doublemalt.net&gt;</a> escribió:

  </pre>
  <blockquote type="cite">
    <pre wrap="">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:
    </pre>
    <blockquote type="cite">
      <pre wrap="">On Thu, 24 Apr 2008 09:24:26 +0200 polz
      </pre>
    </blockquote>
    <pre wrap=""><a class="moz-txt-link-rfc2396E" href="mailto:polz@aufbix.org">&lt;polz@aufbix.org&gt;</a> babbled:
    </pre>
    <blockquote type="cite">
      <pre wrap="">  
      </pre>
      <blockquote type="cite">
        <pre wrap="">On Thursday 24 April 2008 05:52:52 Carsten
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">Haitzler wrote:
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">    
        </pre>
        <blockquote type="cite">
          <pre wrap="">On Wed, 23 Apr 2008 18:28:40 +0200 thomasg
          </pre>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap=""><a class="moz-txt-link-rfc2396E" href="mailto:thomas@gstaedtner.net">&lt;thomas@gstaedtner.net&gt;</a> babbled:
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">yup. those 7m/sec (that's write to video ram) is
          </pre>
        </blockquote>
      </blockquote>
    </blockquote>
    <pre wrap="">also shared with SD card
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">IO. 
      
          </pre>
        </blockquote>
        <pre wrap="">Correct me if I'm wrong, but it seems to me that
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">this means it should be 
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">impossible to playback videos in full-screen from
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">an SD card on a gta02.
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">640*480*25 = 7680000 and that's with 8bpp.

Has anyone tested video playback on a GTA02 yet ?
    
        </pre>
      </blockquote>
      <pre wrap="">correct. yuv will be w * h * 1.5 bytes for 1 frame
      </pre>
    </blockquote>
    <pre wrap="">(standard video yuv). so
    </pre>
    <blockquote type="cite">
      <pre wrap="">3240x240*1.5*30 (320x240 @ 30fps) = 3.4m/sec -
      </pre>
    </blockquote>
    <pre wrap="">BUT... when u are copying you
    </pre>
    <blockquote type="cite">
      <pre wrap="">have ZERO cpu cycles to decode the next video
      </pre>
    </blockquote>
    <pre wrap="">frame. so that means 50% of cpu
    </pre>
    <blockquote type="cite">
      <pre wrap="">cycles will be spent ONLY copying video data to
      </pre>
    </blockquote>
    <pre wrap="">video ram. the other 50% u have
    </pre>
    <blockquote type="cite">
      <pre wrap="">left to decode the mpeg1/2/4 or whatever video in
      </pre>
    </blockquote>
    <pre wrap="">system ram to a yuv buffer. i
    </pre>
    <blockquote type="cite">
      <pre wrap="">would say this is the realistic highest resolution
      </pre>
    </blockquote>
    <pre wrap="">you will get. 480x320@30fps
    </pre>
    <blockquote type="cite">
      <pre wrap="">is the MOST you will get (6.9m/sec), but u have
      </pre>
    </blockquote>
    <pre wrap="">ZERO (or almost) cpu cycles to
    </pre>
    <blockquote type="cite">
      <pre wrap="">actually decode the video into yuv.

remember here i am assuming use of xvideo and the
      </pre>
    </blockquote>
    <pre wrap="">yuv to rgb conversion and
    </pre>
    <blockquote type="cite">
      <pre wrap="">scaling on the glamo - which xglamo does support.
      </pre>
    </blockquote>
    <pre wrap="">if you do software yuv-&gt;rgb +
    </pre>
    <blockquote type="cite">
      <pre wrap="">scale then its even less fun. with software. the
      </pre>
    </blockquote>
    <pre wrap="">best u will get is 11fps at
    </pre>
    <blockquote type="cite">
      <pre wrap="">640x480 - and this is NO cpu cycles to actually
      </pre>
    </blockquote>
    <pre wrap="">decode the video, convert it to
    </pre>
    <blockquote type="cite">
      <pre wrap="">16bit rgb and scale. in reality i expect you to
      </pre>
    </blockquote>
    <pre wrap="">see 2-5fps in this scenario,
    </pre>
    <blockquote type="cite">
      <pre wrap="">maybe eve 1fps.

this is ONLY playback if the video data is already
      </pre>
    </blockquote>
    <pre wrap="">in ram - ie the mpeg data is
    </pre>
    <blockquote type="cite">
      <pre wrap="">cached. if it is read off internal flash you will
      </pre>
    </blockquote>
    <pre wrap="">pay an IO cost - but it's not
    </pre>
    <blockquote type="cite">
      <pre wrap="">shared with the glamo bus. if it is on SD card -
      </pre>
    </blockquote>
    <pre wrap="">you will basically have to now
    </pre>
    <blockquote type="cite">
      <pre wrap="">share the IO between SD and graphics. i believe
      </pre>
    </blockquote>
    <pre wrap="">the graphics IO takes
    </pre>
    <blockquote type="cite">
      <pre wrap="">precedence over SD card IO, so as long as u keep
      </pre>
    </blockquote>
    <pre wrap="">the glamo gfx bus busy, sd
    </pre>
    <blockquote type="cite">
      <pre wrap="">will be on hold until u stop. then some sd io can
      </pre>
    </blockquote>
    <pre wrap="">get through.
    </pre>
    <blockquote type="cite">
      <pre wrap="">with the glamo you need to be careful what you do
      </pre>
    </blockquote>
    <pre wrap="">and how you do it. if you can
    </pre>
    <blockquote type="cite">
      <pre wrap="">keep something entirely within the glamo - it
      </pre>
    </blockquote>
    <pre wrap="">should be ok. so things like
    </pre>
    <blockquote type="cite">
      <pre wrap="">uploaded pixmaps and then blitting them around is
      </pre>
    </blockquote>
    <pre wrap="">ok. video decode is another
    </pre>
    <blockquote type="cite">
      <pre wrap="">matter entirely. the glamo has an mpeg4 decoder on
      </pre>
    </blockquote>
    <pre wrap="">it - but we don't have any
    </pre>
    <blockquote type="cite">
      <pre wrap="">api to access that directly/sanely and just feed
      </pre>
    </blockquote>
    <pre wrap="">it an mpeg4 stream. any other
    </pre>
    <blockquote type="cite">
      <pre wrap="">codec has to be done on the cpu anyway and
      </pre>
    </blockquote>
    <pre wrap="">uploaded across the bus as yuv data.
    </pre>
    <blockquote type="cite">
      <pre wrap="">  
      </pre>
    </blockquote>
    <pre wrap="">
_______________________________________________
Openmoko community mailing list
<a class="moz-txt-link-abbreviated" href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openmoko.org/mailman/listinfo/community">http://lists.openmoko.org/mailman/listinfo/community</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->


      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.


_______________________________________________
Openmoko community mailing list
<a class="moz-txt-link-abbreviated" href="mailto:community@lists.openmoko.org">community@lists.openmoko.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openmoko.org/mailman/listinfo/community">http://lists.openmoko.org/mailman/listinfo/community</a>

  </pre>
</blockquote>
<br>
</body>
</html>