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

[John Gilmore]

> 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?

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

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?

        John