Xuggler incorrectly calculates audio timestamps for audio streams with a non-zero start duration

[GoogleCodeExporter]

To reproduce:
1) Use a codec (e.g. windows media audio) that requires one or more packets
to be cached before it can begin decoding
2) Make sure the codec has a non-zero start time set for that stream.

If you do that, the first audio sample we encode from the audio will have
incorrect guessed timestamps which will lead us to later attempt to write
audio with non-monotonically increasing timestamps.

See
http://groups.google.com/group/xuggler-users/browse_thread/thread/2a84adfd330f62
6a

Original issue reported on code.google.com by art.cla...@gmail.com on 21 Apr 2009 at 6:02

[GoogleCodeExporter]

This turns out to be tricky to fix and exposes some incorrect login in the
StreamCoder.  The right way to fix this is:

a) An encoding stream coder needs to figure out the next expects pts (like the
decoders do).
b) If needs to count 'samples' in terms of frame size coming out of the encoder 
and
update pts accordingly
c) it also needs to compare the set of samples currently being encoded against 
the
expected value, and increment the 'fake' pts if it looks like a StreamCoder 
user has
accidentally dropped a packet.
d) in short, it's a little bit of a rewrite which I'm punting for now, but it's 
a big
bug and should be fixed in 2.1

Original comment by art.cla...@gmail.com on 21 Apr 2009 at 6:17

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Issue 111 has been merged into this issue.

Original comment by art.cla...@gmail.com on 1 May 2009 at 2:31

[GoogleCodeExporter]

Fixed in r393 (hopefully).  For inclusion in Xuggler 2.1

Original comment by art.cla...@gmail.com on 1 May 2009 at 2:33

• Changed state: Fixed