GNOME Bugzilla – Bug 616414
mpegtsdemux: account for pat/pmt latency in newsegment
Last modified: 2012-09-24 22:28:35 UTC
Hi, I'm doing some tests with the mpegtsdemux plugin and I'm getting lateframes because the plugin does not account for the latency introduced by the PAT/PMT parsing, in push mode. It does work in the majority of mpeg-ts streams, because the mpegtsdemux introduces a constant 700ms latency in the pipeline and that is usually enough to receive the first PMT and create pads. However, if in a stream the PMT are not resent fast enough, the 700ms latency might not be enough. A latency of first_pmt_time - base_time should be accounted for. I'm not sure if the newsegment start sent on the pad has to be tweaked or if the global latency has to be changed. To reproduce this easily, just skip a few PAT in gst_mpegts_stream_parse_pat and the bug should happen.
Does this still happen with the latest releases?
Arnaud, can you please let us know if you can reproduce the problem in latest release ?
Hi, The problem does still happen with latest git version. In my original post I say the latency should be first_pmt_time - base_time, more precisely it is first_pcr_time - base_time. Another solution would be to set the base time to the time the first pcr is received, but this does not work since the pipeline would already in playing state when live.
This still applies to the tsdemux element as, the same way we only introduce a 700ms without properly calculating the latency.
This does not apply to tsdemux in live mode because the timestamp of buffers being outputted are calculated in a different way. The wrong latency is another issue.
Arnaud, is this still an issue with git ? It now uses tsdemux by default.
May I guess that this is OBSOLETE? Please reopen if it's not. Thanks.