On Sat, May 17, 2008 at 01:21:59PM -0700, John Gilmore wrote: > > The (parser) process would run in its thread and fill the video/audio > > buffers > > till end of input stream is reached. > > Shouldn't there be some backpressure from the buffering subsystem and > the player, to avoid filling all available memory with frames that won't > be used for a long time?
Good question. For sure continuos streams will require that (assuming they exist, but not having experience with that - think videoconferencing). Anyway, by flash spec the "buffer size" can be controlled by user, in terms of seconds. There might be an upper limit, but still user can control the buffer size. I based my tought of "cache" all on a naive analisys of the proprietary player dealing with an ~1 hour video from youtube. The youtube player seekbar fills up till the end (takes about 30minutes of downloading), even if the playhead is in "pause" mode. Once the buffer is filled up, you can move the playhead in *every* region of the buffer and the corresponding image pops up really quick, so to assume no further downloading is happening. That part can be implementation-specific in that user doesn't really control the whole buffer size, but just the amount that he wants to be available before playhead starts consuming frames. 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... As a final note, the buffer I'm talking about contains *encoded* frames, so should use far less memory then fully decoded ones. Of course the 'continuos stream' case makes any of the above tricks insufficient. > > Theoretically position should only move forward when all > > frames at the current one have been consumed, but as long as > > we have 2 consumers in two different threads it is not clear which one > > (if not an external actor) would be responsible to mark total consumption. > > Whichever one finishes later, I'd presume. While someone is still > eating, you don't pick up the plates and bring the next course. Agreed. The solution suggested later (keep track of wheter or not consumers finished their plate) should implement that. > Is the intention to be running a video completely from RAM, supporting > arbitrary seeking around within RAM? Or is the intention to be > running a video stream that's coming in over the network, using RAM > for current frames, discarding frames after they've been played, and > implementing seeking by communication with the other end of the > network? Or some mix of the two? The proprietary player uses a mix of the two. If you seek to a region which is not yet buffered, it fetches new data from network (starting with a given offset) and the "red bar" (buffered region) will start from there and keep going. But remember that in the 1hour case, it really looks like the whole time is buffered (ram or disk..). ref: http://www.youtube.com/watch?v=WfNFjmwdAwo (1hr 45min) --strk; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
