GNOME Bugzilla – Bug 751490
mpegaudioparse: Non-increasing PTS issue
Last modified: 2018-11-03 15:01:26 UTC
Hi, I'm getting successive audio frames with the same timestamp when I run a transport stream with the following pipeline. The playback becomes jerky due to this repeat of timestamp(non linear in time) gst-launch-1.0 filesrc location=/root/cinekids.ts ! tsdemux ! mpegaudioparse ! audio/mpeg ! checksumsink I have analysed the stream and found the stream has NO packet losses. The issue happens with mpegaudioparse element. Every PES here has either 3 or 4 access units The file is at https://drive.google.com/file/d/0BzAa6BlwN3-cUUVLaHFzUmFvdzA/view?usp=sharing. The output file is at http://pastebin.com/VKjjyD6V. The erroneous timestamps are at line #171, #506, #841 etc, repeating once in 8 seconds(approx) -J
While testing with git master, it seems I can't reproduce this issue. I went over all timestamps and no PTS are duplicated. Also, playback till the end is completly smooth. Can you test with git master (aka 1.5.2) and confirm this is also fixed for you ?
Hi, I could reproduce the repeated timestamps with 1.5.2 as well. Here is the dump http://pastebin.com/yFgminbA Timestamps are repated at line #176:177, #511:512 etc I ran the same pipeline as that I ran for 1.4.5 gst-launch-1.0 filesrc location=/root/file.ts ! tsdemux ! mpegaudioparse ! audio/mpeg ! checksumsink Am I missing something here if you are unable to reproduce this? ~J
I can reproduce this: gst-launch-1.0 filesrc location=751490.ts ! tsdemux ! mpegaudioparse ! fakesink silent=false -v | grep 0:00:04.209 | colrm 1 106 | colrm 76 999 dts: 0:00:04.137059333, pts: 0:00:04.209059333, duration: 0:00:00.024000000 dts: 0:00:04.209059333, pts: 0:00:04.209059333, duration: 0:00:00.024000000 dts: 0:00:04.209059333, pts: 0:00:04.233059333, duration: 0:00:00.024000000 dts: 0:00:04.209059333, pts: 0:00:04.257059333, duration: 0:00:00.024000000 mpegaudioparse/baseparse could probably handle this better, however in practice the audio decoder/audiosinks will smooth out jitter like this. Why is that not happening in your case?
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
(In reply to Tim-Philipp Müller from comment #3) > I can reproduce this: > > gst-launch-1.0 filesrc location=751490.ts ! tsdemux ! mpegaudioparse ! > fakesink silent=false -v | grep 0:00:04.209 | colrm 1 106 | colrm 76 999 > > dts: 0:00:04.137059333, pts: 0:00:04.209059333, duration: 0:00:00.024000000 > dts: 0:00:04.209059333, pts: 0:00:04.209059333, duration: 0:00:00.024000000 > dts: 0:00:04.209059333, pts: 0:00:04.233059333, duration: 0:00:00.024000000 > dts: 0:00:04.209059333, pts: 0:00:04.257059333, duration: 0:00:00.024000000 I'm sorry, but there is no duplicated TS here. Don't confuse the DTS and the PTS.
(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.
(In reply to Nicolas Dufresne (stormer) from comment #5) > > dts: 0:00:04.137059333, pts: 0:00:04.209059333, duration: 0:00:00.024000000 > > dts: 0:00:04.209059333, pts: 0:00:04.209059333, duration: 0:00:00.024000000 Indeed, that I missed. We need to check if this dup exist before mpegaudioparse. If so, it's a muxer issue. What I'm trying to explain, is that the symptom seems a lot bigger then the about of dup in the PTS, hence why I think wowza ignore CTS on audio streams.
I'm investigating into this issue. In case of "04.209059333" problem, in gst_base_parse_chain, Duration is 0:00:00.024000000 The pts in adaptor is 0:00:04.137059333 ( newly pushed by tsdemux ) prev_pts is 0:00:04.041059333 next_pts is 0:00:04.113059333, which is updated in previous gst_base_parse_handle_and_push_frame call, which means the next expected pts is this. But by the logic below, next_pts is updated to 0:00:04.137059333, which means one duration is skipped. if (GST_CLOCK_TIME_IS_VALID (pts) && (parse->priv->prev_pts != pts)) parse->priv->prev_pts = parse->priv->next_pts = pts; This causes the reported problem finally. I think this is happening because gap of PTS between each audio stream in ts file is not consistent even audio data size is consistent. Sometimes 72ms for 2010 bytes, sometimes 96ms for 2010 bytes. And I don't think this ts file is invalid, but I'm not sure baseparse should handle this case. First case PTS: 0:00:04.041059333 DTS: 0:00:04.041059333 PTS: 0:00:04.065059333 DTS: 0:00:04.041059333 PTS: 0:00:04.089059333 DTS: 0:00:04.041059333 PTS: 0:00:04.137059333 DTS: 0:00:04.137059333 -> one duration skipped PTS: 0:00:04.161059333 DTS: 0:00:04.137059333 PTS: 0:00:04.185059333 DTS: 0:00:04.137059333 PTS: 0:00:04.209059333 DTS: 0:00:04.137059333 PTS: 0:00:04.209059333 DTS: 0:00:04.209059333 -> problem happens PTS: 0:00:04.233059333 DTS: 0:00:04.209059333 PTS: 0:00:04.257059333 DTS: 0:00:04.209059333 Second case PTS: 0:00:12.081059333 DTS: 0:00:12.081059333 PTS: 0:00:12.105059333 DTS: 0:00:12.081059333 PTS: 0:00:12.129059333 DTS: 0:00:12.081059333 PTS: 0:00:12.177059333 DTS: 0:00:12.177059333 -> one duration skipped PTS: 0:00:12.201059333 DTS: 0:00:12.177059333 PTS: 0:00:12.225059333 DTS: 0:00:12.177059333 PTS: 0:00:12.249059333 DTS: 0:00:12.177059333 PTS: 0:00:12.249059333 DTS: 0:00:12.249059333 -> problem happens PTS: 0:00:12.273059333 DTS: 0:00:12.249059333
Yes, there seem to be jitter in the stream itself. One idea would be correct the jitter in the parser itself, but I'm not sure if it breaks normal flow Can we have an element to handle jitters, just like rtpjitterbuffer? Is there a jitter management code somewhere which can be pulled out and made an element, for a smoother playback?
Since this does not pertain to parser issue as such, shall I close the bug? PTS jitter handling would be a "good to have feature" rather than considering it as a bug!
Well, the crafted DTS here and the PTS being sometimes duplicated are both most likely bugs. An acceptable jitter would consist of timestamp going forward, but duration would vary for the same number of samples.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/196.