Handling of PCR insertion in mpegtsmux

[Baby Octopus]

Marc,

> Well, that depends on what you deem necessary. Low-latency equipment 
> may not able to handle the current "bursty" udpsink output. The burstier 
> it gets, the more delay (and buffering) is needed on the receiving side. 

I agree!

> And as said, it seems conceptually wrong to apply internal transport 
> delays on the PCR. Would that mean that you would want every other 
> (external) retransmission of the stream to have its PCRs (and thus PTSes 
> and DTSes) rewritten as well? 

 Totally agreed. It is important to make sure PCR is hardly tampered in
successive transmission

> 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

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

~BO




--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Handling-of-PCR-insertion-in-mpegtsmux-tp4661447p4661480.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.