[gst-devel] New DXR3 plugin in bugzilla

[Ronald Bultje]

Hey Martin,

I'm a bit late, I lost track of some emails in my messy inbox for a few
days. I'll still try to be helpful now, though.

On Sun, 2003-06-01 at 22:23, Martin Soto wrote:
> Ok, I'm giving it a try now. I just stole the clock from osssink (it is
> quite generic, shouldn't we have something like that in GStreamer
> proper?) and am making my sound sink provide such a clock.  This is
> indeed a cleaner way to implement synchronization, I hope I can make it
> work.

Maybe, there's lots of things for which this goes, though. Benjamin and
I have been thinking of some generic 'audiosink' elements, where a
normal audio output element (being a soundserver or a soundcard driver)
would just be a subclass of this. The audiosink then handles all
sync/state stuff, the subclass only implements an 'open', 'close' and
'write' function. You probably see how this is useful. The clock stuff
would be part of this. The same ideas are floating around for videosink,
videosrc and audiosrc. The whole idea is that plugin programming would
be cleaneer and things like A/V sync would suddenly be part of all
output/device plugins instead of just 'some'.

However, we still need to do this. ;). Try to stay as close to osssink
as possible, that'll make the conversion a lot easier for us once we get
around to it. I'm guessing this idea will be discussed in-depth in
Dublin.

> I have a question, however.  Whenever you do a gst_clock_handle_discont,
> the "accept_discont" internal flag will be set to false (line 630 of
> gstclock.c).  As far as I can understand, this is made to prevent the
> clock from handling the same discontinuous event many times.  Now, in
> order to set this flag back to true (later discont events won't be
> handled if you don't) you need to call gst_clock_set_active with a true
> value.  The question is, when should I do that to guarantee that a
> discontinuous event is properly handled?  Looking at what osssink does,
> I can think of situations in which a single discont event will change
> the time value of the clock twice.  Is that meant to work like that? 

It's only handled once, because the gstossclock function to handle the
event has an internal flag that keeps track here. The clock is set back
to active when the _get() or _chain() function is called agian (which
means w're back playing).

> Well, from what I've learnt from the DVD stuff, timestamps for AC3 sound
> are handled in a particular way.  Since typical AC3 packets are around
> 1600 bytes long, MPEG transport packs (which hold about 2000 bytes of
> data) will normally contain portions of two or three AC3 packets.  When
> you find a timestamp in the header of the MPEG pack, this timestamp is
> not associated to the start of the MPEG pack (which is normally some
> random point in the middle of an AC3 packet) but to the first AC3 packet
> that starts inside the pack.
> 
> The mpegdemux element just sends a buffer for every MPEG pack found, and
> directly converts the timestamps to GStreamer time.  This means that the
> timestamps don't really match, and you need to somehow parse the AC3
> stream to fix them.  I guess a52dec doesn't have this into account, and
> that leads to timestamps that are slightly off after the sound is
> decoded.

Hm, shouldn't mpegdemux take care of this. I mean, of course, you cna
create a a52dec parse element, but that's not the point, demuxers should
do this, too, if it's specifically due to a format-specific thing (which
efinately is the case with MPEG's weird stream format).

> > PS: if you want, you can place the app into Gst CVS or so, it's probably
> > possible to get you CVS access into our Gst CVS for that.
> That would be great, specially for maintaining the DXR3 stuff.  What I
> see now is that the work necessary to play DVDs is 95% enhancements to
> GStreamer and 5% development of a driver program.  Of course I can keep
> sending patches, but having CVS access would make it way simpler.

I forgot to discuss this. I'll keep you posted on this.

Ronald

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