On Thu, May 17, 2007 at 01:12:53AM +0200, Tomas Groth wrote: > > --- strk <[EMAIL PROTECTED]> skrev: > > > On Wed, May 16, 2007 at 09:10:26PM +0200, strk wrote: > > > On Wed, May 16, 2007 at 06:22:32PM +0000, Tomas Groth wrote: > > > > > > > + /// Returns the "bufferlength", meaning the differens between > > > > the > > > > + /// current frames timestamp and the timestamp of the last > > > > parseable > > > > + /// frame. Returns the difference in milliseconds. > > > > + uint32_t getBufferLength(); > > > > > > I'm not sure this is what we really need. > > > If this is what you get by reading NetStream.bufferLength > > > then I'd expect it to decrease and increase as the stream goes. > > > In any way I'd expect it to NEVER become == total length if > > > we play while buffering. > > Is the problem that it increases and decreases? why would that be a problem? > And no, if we play while buffering it should never return the total length of > the FLV.
Confirmed. No problem. bufferLength does increase and decrease. See NetStream-SquareTest.swf We'll have to add anothere test there: seeking back. From the comment above seeking-to-0 and stopping should result in bufferLength being == total length, we want to verify this (I suspect the buffer stops being filled) > > Another though.. can NetStream play a continuos stream, > > like an IP radio ? > > In this case we can't think the buffer will keep growing... > > > NetStream is suppose to support this, and I think it might already works, but > because of the reason you mention it is not officially supported yet. We'll > need to modify the way curl_adaptor stores data, or something like that... After the release... --strk; _______________________________________________ Gnash-commit mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-commit
