[Bug 751490] mpegaudioparse: Non-increasing PTS issue

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=751490

--- Comment #6 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Baby octopus from comment #4)
> Hi Tim,
> 
> The final audio sink is not present in my pipeline. My pipeline repacketizes
> the incoming TS stream into an RTMP stream and pushes it to Wowza server.
> The audio glitches were seen on output of Wowza. And when I debugged this, I
> found out out the repeated timestamps could be a problem for this
> 
> May be this webplayer which reads from Wowza server does not handle jitters

I believe Wowza doest not handle the CTS for audio streams. I think we one
should do some research about the DTS behaviour of mpegaudio parse.

For the reference, FLV muxed format (what we pass to rtmpsink), encode the DTS
in the bitstream. The it saves a delta, the CTS to find out the PTS. So the PTS
shall be:

PTS(n) = DTS(n) + CTS(n)

I believe Wowza does not do this math for audio stream. In probably 80% of the
case this is valid thing to do. We need to dig the mepg specs to find the valid
thing to do. We can then decide to modify mpegaudioparse or flvmux to accomate
whatever spec expects what.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.