[Gnash-dev] NetStream design: input handling

[strk]

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!