[gst-devel] Re: [gst-cvs] thomasvs gst-plugins: gst-plugins/ gst-plugins/ext/mad/

[Ronald S. Bultje]

Hi,

(still found I had to explain this.)

On Thu, 2004-04-08 at 11:21, Thomas Vander Stichele wrote: 
> > On Wed, 7 Apr 2004, Thomas Vander Stichele wrote:
> > > Log message:
> > > do not change caps in middle of stream except on new streams
> > > fixes #139382
> > 
> > That is legal, the patch is wrong.
> 
> Are you *very* sure ? I don't want to argue with someone that knows more
> about MPEG than me :) But afaict from the ISO MPEG-audio spec there are
> only a few things that can change from header to header.  Among these
> are the padding bit and the bitrate.  But neither the sample rate index
> nor the channel index are allowed to change *within one consecutive
> stream* (ie. think one file).
> 
> Note that the patch intends to only allow changes after new stream
> events.
It's legal as it's legal to concatenate two MPEG streams, afaik. Note
that I only have the MPEG video specs here, as I always intend to know
little about audio ( ;-) ), so I cannot look it up myself. This is just
from past memory from times where I *did* read MPEG specs.

> >  Like I said before on bugzilla or IRC
> > (forgot...), we need to resync only after having met at least several
> > valid mpeg audio frame headers in a row, just like in the typefind
> > function.
> 
> Two in a row with valid headers should be enough.  Don't forget that
> this adds latency.  There is probably some improvement that could be
> done in avidemux too instead of just jumping anywhere in the mpeg audio
> stream - the point of synchronization in mpeg audio is decreasing the
> chance of feeding the wrong data, or reducing the cases where you
> deliberately lose sync.
Well, given that syncing on times is done only later, the latency is
very small, unless the source syncs as well (like in streaming mp3).
That's why streaming mp3 (or in general: streaming audio) queues several
seconds of data (buffering). ;).

Ronald