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

[strk]

On Thu, Jun 05, 2008 at 01:21:06PM +0200, strk wrote:
> 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

Update info (found out the FLV wasn't fully downloaded yet):

    PID   VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  22654  81600  22m 9824 S  9.2  1.5   0:01.69 flashplayer
  24284   192m 137m 9140 S  4.3  9.0   0:02.17 flashplayer
  24284   310m 236m 9140 R  3.3 15.6   0:04.46 flashplayer
  24284   344m 274m 9140 S  7.0 18.1   0:05.53 flashplayer
  24284   460m 379m 9800 S 61.7 25.0   0:10.31 flashplayer <-- bufferTime 
reached
  24284   460m 380m 9820 R 79.8 25.0   0:31.49 flashplayer <-- playing
  24284   460m 380m 9820 R 76.0 25.0   1:01.95 flashplayer <-- playing

So we get 460Mb of memory used when 2hrs of audio/video are *buffered*
when the full file size is 288Mb. 22Mb we get when buffering 2 seconds,
and also when buffering 0.1 seconds, so we can take it as a base memory 
occupation. That in turn gives a figure of about roughly 440Mb of buffer
for a 288Mb of file.
I've no idea how big would be decoded frames, can the compression ratio
be as few as 0.65 ?
The contained video is H263, audio is MP3.

--strk;