gnash-dev
[Top][All Lists]
Advanced

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

Re: [Gnash-dev] NetStream design - More about "the buffer"


From: strk
Subject: Re: [Gnash-dev] NetStream design - More about "the buffer"
Date: Thu, 5 Jun 2008 13:21:06 +0200

On Sun, May 18, 2008 at 10:56:38AM +0200, strk wrote:

> http://www.youtube.com/watch?v=_kfbDnVMmtw 2hr (2hr.flv)
> Downloaded FLV file size: 287,927,013 (275M)
> 
> Disk usage increase while buffering with playhead in pause mode;
> stops increasing when firefox process is stopped; resumes when process 
> resumed.
> Found this to be a file called /tmp/FlashK8xhzU, the name suggests it's not
> a firefox-specific thing..
> file(1) reports: FlashK8xhzU: Macromedia Flash Video
> 
> Follows memory use:
>           PID VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>         11625 259m 116m  26m R  4.7  7.7   2:52.07 firefox
>         11625 259m 116m  26m R  4.7  7.7   2:53.12 firefox
>         11625 259m 116m  26m S  6.7  7.7   2:56.07 firefox
>         11625 259m 118m  26m R 17.6  7.8   3:09.87 firefox (~17 min buffer)
>         11625 259m 120m  26m R 12.6  7.9   3:46.80 firefox (~37 min buffer)
>         11625 259m 121m  26m R  0.0  8.0   4:09.94 firefox (~1 hr buffer)
>         11625 275m 126m  26m R  3.5  8.4   4:50.38 firefox (~1 hr 45 min 
> buffer)
>         11625 275m 127m  26m R  9.9  8.4   5:00.57 firefox (all buffered)
> 
> At the end, the seek bar is all red and you can move the playhead on every 
> position
> getting a full decoded image back. The cache file is the whole size reported
> by wget on the get_video uri (287,927,013).
> Unlinking the cache file (/tmp/FlashK8xhzU) doesn't break anything (I guess 
> the player
> has open file descriptors there).

I found out that the youtube progress bar has two overlying colors.
One red is the bytesLoaded/bytesTotal, and another red is the bufferLength.

Here's memory state when loading the *same* FLV from local filesystem, but
setting bufferTime to 2 hours (ie: buffer all before starting to play):

          PID  VIRT  RES  SHR  S %CPU %MEM    TIME+  COMMAND
        21929  325m 248m  9820 R 75.7 16.3   2:00.56 flashplayer


While this is the same video, but with only 2 seconds of buffering:

          PID  VIRT  RES  SHR  S %CPU %MEM    TIME+  COMMAND
        22654 81600  22m  9824 S  9.2  1.5   0:01.69 flashplayer

Huge difference in memory use ...

So, it seems that the "buffer" (in NetStream terms) is really an 
in-memory one, and contains *encoded* data (or memory used would be
much larger, while it isn't much bigger then the file size itself).

--strk;








reply via email to

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