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; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
