[gst-devel] New DXR3 plugin in bugzilla

[Martin Soto]

Hi Ronald!

On Wed, 2003-06-11 at 19:46, Ronald Bultje wrote:
> 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.

No big deal.  In the mean time I was able to change my code to use the
GstClock system.  Still many rough edges, but all in all, it works. I
watched to movies with it last weekend :-)

> 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.

This looks like a really good idea.  I'll keep my stuff as standard as
possible.  By the way, now that my video and spu sinks use GstClock, I
could use osssink for the sound.  My only problem is that osssink lacks
support for direct digital audio output, like for AC3 or DTS sent to an
external decoder.

I think that osssink (and alsasink as well) should be extended to
support digital audio.  A difficulty there is how to support the
multiple audio formats (AC3, DTS and anything that may come in the
future that is suitable for a SP/DIF connection).  An idea would be to
define a raw SP/DIF data type, and make the audio sinks support that. 
Additional elements would parse the multiple sound formats, and pack
them into SP/DIF packets.  If that sounds good, I may give a try at
implementing it, at least for osssink.

> > 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).

It seems to me that the wrong activate function is being called from
osssink.c.  I'll check and send a patch if I can find a solution.

> > 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).

Yeah.  It could be done in mpegdemux, and indeed probably easier, since
the AC3 pack header contains information about where the first AC3
packet starts, that is now being silently discarded.  The cuestion is
how to handle that.  You could interpolate the timestamp to make it
correspond to the start of the buffer, but that doesn't make a lot of
sense.  The other option would be breaking the buffers according to the
AC3 structure instead of keeping the MPEG arbitrary packet divisions. 
That's more programming work but it is probably the best solution.

Cheers,

M. S.
-- 
Martin Soto <soto at informatik.uni-kl.de>