Re: [Gnash-dev] NetStream design - episode 2: The PlayHead

[strk]

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;