[Bug 608148] tsdemux: Better handle PCR<=>PTS conversion (big difference, latency, ...)

[GStreamer (GNOME Bugzilla)]

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

Baby octopus <jagadishkamathk at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jagadishkamathk at gmail.com

--- Comment #45 from Baby octopus <jagadishkamathk at gmail.com> ---
Edward, 

>> The reason why in mpeg-ts streams the PTS of the various 
>> audio and video streams can be so much higher than the 
>> co-located PCR is because it takes into account the maximum 
>> latency/buffering needed in demuxing/buffering/decoding/reordering 
>> in order for the target buffer to be properly displayed.
Can this be assumed? Shouldn't the buffering at the decoder side by independent
of PTS-PCR gap? 
If we do PTS - first_pcr, it would invariablly introduce latency due to
timestamp GAP. Assume 1second gap between PTS and PCR for H264 video. This
would make the video timestamp to start from 1s leading to latency due to
starting timestamp
Does it make sense to do PTS-first_seen_ES_PTS in such a case?
first_seen_ES_PTS should be common across all the ES belonging to that program

>> Due to that difference, tsdemux needs to report not 
>> the end-to-end latency (PTS - PCR received at the same time) 
>> but only the min/max latency it introduces itself. This boils 
>> down to the interleaving/packetization latency. The other 
>> downstream elements (parsers, queue, decoders, ...) will add min/max 
>> latency specific to those streams and end up with the ideal 
>> capture-to-display latency
Ideally this says
1. txdemux should report only its latency(processing) and do not report about
max interleaving latency of 700ms which might have been introduced due to
difference in buffering of ES(Video needing lookahead/Bframes buffering )
2. Parsers should advertise buffering latency, something like vbv_delay or
init_cbp_removal_delay
3. Decoder should report B pic reordering delay

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