Next topic on NetStream design is I/O. So far, we're using blocking reads on an IOChannel (formerly known as tu_file).
That's our I/O primitive, supporting blocking operations: read, write, seek, tell. Analisys on the proprietary player shows that for filesystem and HTTP channels, NetStream maintains a file-cache in /tmp downloading the whole resource (possibly using a separate thread). NetStream.getBytesLoaded() seems to return the cache size. Now, for RTMP, there's no such file-cache, but couldn't test return of NetStream.getBytesLoaded(), being unable to setup an RTMP server myself (help with this would be appreciated). In any case, what we need to model is how the MediaParser would approach the separate steps of "parsing" and "loading". These steps might be separated only for HTTP and file cases, and not for RTMP, don't know this until I can get some results of getBytesLoaded() and compare to .bufferLength. This is because bufferLength accesses the "parsed data", while getBytesLoaded accesses the "loaded data". At least for HTTP and FILE, "loaded data" is very important on NetStream.seek, in that you can't seek to a position which isn't yet "loaded" (you supposedly get a NetStream.InvalidSeek event), while you can seek to a loaded one. You may have noted 'seek' is just disabled in current head, and that's part of the issue. What I'm trying to model is an abstraction that would make access to the MediaParser input unified reguardless of underlying channel, be it file, http, rtmp. The abstraction will need to support the concept of a "canSeekTo(x)", with which we'd be able to tell when to throw NetStream.InvalidSeek and when instead to just seek there. Also, it should likely expose a getBytesLoaded() with similar semantic (ie: how many bytes are available to seek to). For RTMP, chances are canSeekTo would always return true, if the stream contains as much data, as I belive the RTMP client is supposedly able to seek to any position, requesting the server to move the read cursor. Similarly, getBytesLoaded() would always return the full stream size... FILE based accesses would likely behave like the RTMP ones (ie: everything is available immediately). HTTP based accesses instead will need some file-caching mechanism. This is just a brain storming, so your storming back is highly appreciated. For instance, reading the above, I can see that RTMP advertising capability to seek to every position is really cheating, as Network load would still influence time it takes to get there... maybe not a problem as far as we'll still want to wait for parsed buffer to reach "full" state before starting playback. Comments, use cases, test cases, all highly welcome. --strk; () ASCII Ribbon Campaign /\ Keep it simple! _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
