[gst-devel] 0.9 proposals
in7y118 at public.uni-hamburg.de
Wed Dec 8 05:27:01 CET 2004
It's very likely that we'll come up with a better bytestream interface in
the future. In fact I've come up with GstFilePad already (it's part of
bytestream), which IMO is quite nice, though I think I'm the only one that
has ever really used it. ;)
On Tue, 7 Dec 2004, Owen Fraser-Green wrote:
> On Sat, 2004-12-04 at 14:22 +0100, Ronald S. Bultje wrote:
> > Given that I've written some demuxers, let me please comment on this.
> > First of all, I'm mostly assuming bytestream here. We've got some other
> > ways, but all demuxers but ogg use bytestream.
> > *snip*
> > So basically, we're pretty screwed here. Writing chain-based demuxers
> > (or state machines, as Dave calls them) is not all that good of an
> > option.
> I may be wrong but I assumed Dave was thinking of keeping them as loop-
> based elements but which ask for chunks at the beginning of their loop
> functions and then chew on the chunks. This is of course close to being
> chain-based except that you can ask for chunks which correspond to the
> segment you're reading instead of having to join bits of buffers
> together when a segment spans two or more buffers. Then the it's easy to
> make the code requesting the segment handle interrupts etc. as opposed
> to the normal was of requesting field-by-field.
> It strikes me amid all of this that maybe the bytestream interface is a
> bit broken. It's pretty irritating both to code and to read to have to
> check for, and handle, interrupts for every field the plugin wants to
> read. Would it be possible to implement bytestream so that it calls a
> callback in the plugin when an interrupt occurs, then the
> bytestream_read (or whatever the call is) only returns upon success (or
> complete failure) effectively suspending the state of the plugin in the
> middle of its data chewing until the event is dealt with?
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel