Handling of PCR insertion in mpegtsmux

Marc Olzheim marc at your.tv
Thu Aug 8 07:17:42 PDT 2013


On Thu, Aug 08, 2013 at 12:09:55AM -0700, Baby Octopus wrote:
> > Aslo, I think that mangling the PCR for transmission will result in a 
> > lot of PCR jitter in the decoder, while obfuscating this by making the 
> > introduced network jitter undetectable. 
> 
> Didn't quite get this. Not necessarily it introduces jitter on decoder side.
> And in any case you can never be sure of how much of jitter exist with every
> packet. Best way is to average the the jitter effect over a sufficiently
> large number of samples

The jitter detection of the PCR depends on the deviation of the PCR with
respect to the encoding. If there is too much jitter, low-buffer
decoders will run into problems. Mangling the PCR will almost certainly
influence the PCR jitter; if it wouldn't, there would not be a need to
meddle with it in the first place.

Measuring network jitter on a VBR stream can be crudely done by
examining the PCRs in the stream and simply measuring the deviation of
the difference with wall clock time.  Flattening the PCRs would result
in that detection mechanism's failure.

Perhaps a bit far fetched, but I've seen this done in practice.

On CBR streams detecting network jitter is obviously easier. ;)

> Thanks for your input. It was well worth pondering my thoughts over this :)

And thank you for making me order my thoughts on this. ;)

Marc


More information about the gstreamer-devel mailing list