[gst-devel] 0.9 proposals

[Ronald S. Bultje]

Hi,

On Thu, 2004-12-02 at 20:04, David Schleef wrote:
> On Thu, Dec 02, 2004 at 03:55:40PM +0100, Martin Soto wrote:
> > Not only for demux elements. Most complex elements would be a PITA to
> > program using this model. I don't doubt Benjamin can make any element
> > you throw at him work using this model, but I don't think most people
> > will have the skills or, for the sake of it, the time and patience
> > necessary to write elements this way.
> 
> Have you ever tried?  IMO, getting an element 100% right is easier
> to do by 1) realizing you have a state machine, 2) designing a
> state machine, and 3) implementing the state machine.  It's certainly
> easier than 1) writing some code, 2) bug fixing hidden state
> transitions in the code, and 3) realizing (oh shit!) that you have
> a pooly-designed state machine.
> 
> Writing a state machine is not hard, it just requires planning and
> a bit of noodle work.

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. Dave has a good point
here. All demuxers are in fact already state machines. Most demuxers are
also very poorly implemented for that, and I'm fixing issues only as
they pop up, because it's too much work otherwise. This sucks and needs
to change. The best example is to take a demuxer, let it run and pause
it randomly for no good reason. The best example of such a thing is the
INTERRUPT event. With regard to that (let's assume you pause an element,
which generates an interrupt event), I expect/know that:

* asfdemux will die, no matter what. If you're lucky (for some wma
files), you can get it working, but that's pure luck. Asfdemux cannot
pause wile inside its loopfunction. This is a serious bug from a user
perspective.
* avidemux and qtdemux work, but only if you do this after header
reading. This only works because they index their data and don't read
data lineairly. They will die when doing this during header reading.
* matroskademux uses the most gruesome evil hack to get around interrupt
events. It will die, like all of the above, if you do this during header
reading. If you pause it, it'll just continue running because of the
above hack, until it's cluster is completely read.
* rmdemux is barely worth mentioning, it'll usually dies reardless of
what you do (although it's getting better).
* oggdemux is actually correct. The downside of all of this is that
oggdemux is a ^!^^!#^!^&@$&@ unmaintainable piece of crap. Seriously.
* I think mpegdemux sort-of works, but I'm unsure as to how well. The
upside of MPEG is that it's resyncable so even if we'd lose sync during
an INTERRUPT event, it wouldn't matter so much.

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. Seriously, Dave and Benjamin, you're not gonna write all those
elements. I will, mr. X from company Y will, and contributor N with a
cheap digital camera of vendor M and type P with weird_format Q will. It
has to be doable for them. Oggdemux is unmaintainable, even for Wim and
me. That's very painful, and not a good sign. This is not the way.
Obviously, the hack in matroskademux isn't all that good either, and
indexing only works for some formats (like AVI and Quicktime) and does
not apply to all formats. And besides that, we'll have to rewrite all
demuxers. That seriously sucks.

I guess what I'm saying is that we'll need to sit down and document what
we really actually expect as a preferred outcome here for element
writers before we decide that threading, not-threading or $my_solution
is the solution. I think this is called scenario-based design. I
definately don't have *the* solution, but I'm open to suggestions.

Cheers,

Ronald

-- 
Ronald S. Bultje <rbultje at ronald.bitfreak.net>