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

[strk]

On Sun, May 18, 2008 at 10:07:22AM +0200, strk wrote:

We were talking about analisys of the proprietary player
in reguard to where the buffer is...

> Also, it is possible that the cache is kept on disk rather then in RAM:
> I haven't closely looked at it (memory use didn't seem to grow a lot).
> Gnash's tu_file supports seeking already, using a disk cache...

Went deeper in testing. Here are the results:

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).

--strk;