[gstreamer-bugs] [Bug 549940] [audio decoders] Add jitter correction for timestamps

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=549940

  GStreamer | gst-ffmpeg | Ver: HEAD CVS

Edward Hervey changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1




------- Comment #2 from Edward Hervey  2008-08-30 14:35 UTC -------
Maybe I should explain a bit more why this is needed.

In normal cases (playbin), the jitter correction will actually be done in the
audio sinks (which allow up to an insane 500ms jitter).

 But in many other cases, you actually want that jitter fixed as upstream as
possible.
 It can't be fixed in most demuxers, since they don't know the ACTUAL duration
of the outgoing encoded buffers. You actually need to decode those samples to
know their duration. Demuxers that handle raw audio could handle it though.

 So the next most upstream element where it can be fixed is... the decoder,
which once it's decoded the sample, knows it's duration.

 This is needed for proper accurate seeking (used constantly with gnonlin and
therefore jokosher/pitivi/...).

 Let's take the case of an asf/wma2 file. You want to seek to 1s, and let's say
the demuxer is smart enough and does output the buffer that starts JUST before
that position.
 Here are the values of the buffers that asfdemux will output:
 Buffer A timestamp 0:00.9000 duration 0:00.095
 Buffer B timestamp 0:01.0500 duration 0:00.105

 Those buffers will be received by the decoder, which will decode the first
buffer, calculate the duration based on the number of samples (which is equal
to 1s) see that it's not within the requested segment (starting at 0:01.00) and
discard it.
 The next buffer commes along, is decoded, the actual duration is calculate (1s
again) ... but gets clipped to 950ms and is outputted with a wrong timestamp.

 This is just one side effect of the jitter if its not corrected before the
sinks, I'm sure some other issues will pop up too.
 The next buffer comes


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=549940.