[gst-devel] muxers

David Schleef ds at schleef.org
Tue Oct 15 18:47:04 CEST 2002

On Tue, Oct 15, 2002 at 09:34:11PM +0200, Ronald Bultje wrote:
> Okay, the first situation (chainbased doesn't work) sucks, and the
> second one has severe side-effects:
> [*] it depends on the timestamps being correct

If your MPEG timestamps are incorrect, your stream will be screwed
up anyway.  Timestamps are there for a reason -- they're not
supposed to be incorrect.

> For point 3, Wim suggested to listen to EOS signals. This works well
> only *if* the element provides an EOS signal.

And sources that don't provide an EOS should be fixed.

> For osssrc/v4lsrc, for
> example, this isn't the case, so bad-synced signals (which happens on
> 99% of the soundcards because of broken video clocks) will cause this to
> fail horribly as well.

It sounds like you need to resample the audio (or video) inputs to
make the clocks synchronized.  No fancy muxer will be able to
multiplex two streams that are not sampled at the nominal rate,
unless the system stream has the ability to sychronize non-slaved
clocks.  MPEG can do this, but even in that case, there are strict
rules as to how far off the clocks may be (100 ppm, iirc.)

It wouldn't be hard to write a plugin similar to audioscale that
resampled an input stream according to the timestamps and the
nominal rate.

> conclusion: muxing currently sucks.

No, the streams feeding the muxer are inadequate.


More information about the gstreamer-devel mailing list