700ms of delay in tsdemux element

[Baby Octopus]

Hi,

While I'm trying to optimize the delay in decodebin playback, I encountered 700ms of latency in tsdemux

Mpegts(h.222) indicated that each PES to have a maximum gap of 700ms. But that doesn't translate to latency. While joining as a new client, the worstcase weight for the client is 700ms to encounter a PES, which will then be decoded asap to sent for rendering

So 700ms doesn't translate to latency. Someone please correct me if I'm wrong

~BO

[Sebastian Dröge-3]

On Tue, 2016-10-25 at 09:41 -0700, Baby Octopus wrote:

> Hi,
>
> While I'm trying to optimize the delay in decodebin playback, I encountered
> 700ms of latency in tsdemux
>
> Mpegts(h.222) indicated that each PES to have a maximum gap of 700ms. But
> that doesn't translate to latency. While joining as a new client, the
> worstcase weight for the client is 700ms to encounter a PES, which will then
> be decoded asap to sent for rendering
>
> So 700ms doesn't translate to latency. Someone please correct me if I'm
> wrong

700ms is the worst case interleave between two different streams, as
such it can happen that for e.g. the video you get buffers with PTSs 0
to 700ms before seeing the first audio with PTS 0.

If we would assume a lower latency than 700ms in that case, all audio
packets would be considered late.


Doing some more adaptive as certainly possible here but would have to
be implemented first.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Baby Octopus]

Then I understand this as more of interleaved delay and not due to maxmimum PES spacing

Interleave delay would been generated at the encoder possibly due to ES encoding delay(Video encoder) and also VBV/HRD delay

If the decoder+parser advertise these delays then there is no need for tsdemuxer to advertise this delay

[Sebastian Dröge-3]

On Wed, 2016-10-26 at 01:12 -0700, Baby Octopus wrote:
> Then I understand this as more of interleaved delay and not due to
> maxmimum PES spacing
>
> Interleave delay would been generated at the encoder possibly due to
> ES encoding delay(Video encoder) and also VBV/HRD delay
>
> If the decoder+parser advertise these delays then there is no need
> for tsdemuxer to advertise this delay

How would the decoder/parser you about the interleaving in the
container format and be able to advertise that as latency?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Baby Octopus]

Only reason why an encoder can introduce significant interleave gap between audio and video are due to encoding delay(mainly for video), mainly the following
1. Buffer frames for lookahead
2. Reordering frames for B pictures
3. VBV buffering  - Page 77 of http://www.etsi.org/deliver/etsi_tr/101200_101299/101290/01.02.01_60/tr_101290v010201p.pdf

#1 is encoder only delay
#2 and #3 and can be extracted by the parser and the decoder and reported to the pipeline

Bug link : https://bugzilla.gnome.org/show_bug.cgi?id=773084