gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] NetStream design status


From: strk
Subject: [Gnash-dev] NetStream design status
Date: Fri, 6 Jun 2008 21:33:13 +0200

I committed first cleanup phase of the design.
In this phase, once I figured what "The Buffer" would be, took
the opportunity to make the buffer mostly controlled by the base
MediaParser class rather then virtualized to childs.
This should make things easier when doing the FFMPEG and the GST
version.

Just for verification, here's the memory status on "buffer full"
condition playing the 2hrs movie with 2hrs "buffer time":

    PID VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  11512 454m 379m 9820 T  0.0 25.0   0:32.61 flashplayer
  11824 387m 349m  14m R 90.5 23.0   1:40.20 lt-gtk-gnash

Pretty close eh ?
Not sure about the shared part.. where gnash has *14 as much memory
shared (I guess it's system libs?); anyway for virtual memory gnash
seems to be even less memory intensive then the proprietary counter
part, and still buffering fully encoded video/audio frames.

Anyway, reguarding the design process, next step is cleaning up
buffer use as there are a couple if issues:

        1) MediaParser itself can't tell us what the current
           buffer "length" is, as that depends on the current
           playhead position. It's interface should be cleaned
           up to simply return info about the last available position.

        2) We need to figure *when* and if to fill and flush the buffer.
           Analisys conducted today suggested that as long as the buffer
           length is <= user-requested one (bufferTime) no frame is ever
           dropped (at least I can see that the virtual memory size doesn't
           reduce while the playhead advances).

        3) Seeking was dropped by this commit, as the previous impl
           relied on having full index of where frame were in input.
           I guess each subclass will know better how to seek. For
           FLV, keeping an index of cue points could do.

As a final note, I had the pleasure to guide Benjamin trough the jungle
populating my mind in this week, so hopefully he'll be helping with the
design task too (you see him in action already :).

--strk;


-- 

 ()   ASCII Ribbon Campaign
 /\   Keep it simple! 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]