[gst-devel] New DXR3 plugin in bugzilla

[Martin Soto]

Hi Ronald (and everyone!):

On Thu, 2003-05-29 at 16:54, Ronald Bultje wrote:
> I've noted that too. I'm guessing the video/audio part of the DXR3 form
> a well-integrated A/V sync whole?
> 
> In Gst, you would normally use GstClock for A/V sync. If you succeed in
> integrating the DXR3 audio/video sync stuff into the GstClock objects,
> sync will be fine with osssink as well.

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.

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? 

> > gst-launch dvdnavsrc title=1 chapter=1 ! mpegdemux name=demux
> > .private_stream_1_0 ! .ac3_sink dxr3audiosink demux.video_00 ! { queue !
> > dxr3videosink }
...
> Well, assuming you use a queue, it should work. If not, it's probably
> GStreamer bug. I'm not exactly sure where to start debugging this. Can
> you get information from a --gst-mask=-1 log? Or push one to bugzilla
> for us to review?

Ok.  I'll look into that and post something to bugzilla.  It seems to me
it may be a parsing problem, because my driver application (written in
python) works properly with the queues.

> Yes, timing isn't perfect. You sometimes notice small "hickups" in the
> sound, just as when the soundcard is not getting enough data or so.
> 
> CPU usage isn't even close to 100%, so I'm guessing a52dec isn't
> decoding all data or pushing all data forward. Probably a plugin bug
> then.

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.

> Well, they work well, thanks! I'm looking forward to your app.

I'm glad to hear that.  At list this is an starting point.  I'll keep
improving the elements as time permits.

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

Cheers,

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