> I am not sure that I agreen on having to modify PCR even if you add > data to the mux. Every service has it's own PCR, If you add a new pid > without PCR, then you just have to increase output datarate > accordingly. You are right in general, but not quite in the precise values. > As long as the PCR leaves the muxing software at the same > time as it would do without injecting the pid, This is simply quite impossible to acheive, unless you exactly add a fixed number of packets between *each* original packet. If you leave two consecutive original packets together and insert a new packet between two original packets (P1 P2 P3 => P1 P2 Pnew P3), you introduce PCR jitter. A PCR value is precise to the bit. Inserting a packet means inserting many bits (188*8). In an existing PID, you will find PCR's in, say, packets Px, Py and Pz. These packets are not necessarily equally spaced in the TS. During your muxing operation, you will add, say, 1 packet between Px and Py and 2 (or zero) packets between Py and Pz. Thus, some PCR's become wrong. > there should be no > difference at the receiving end. Remember that the PCR's represent a "system clock", not a program clock (which is implemented by DTS and PTS). PCR's are used as system clock reference by the receiving STB. They must be extremely precise. Usually, the PCR's are restamped by a hardware oscillator at the output of the MUX and even sometimes restamped inside the modulator itself. Of course, if the TS is used in a software codec running as a PC application, PCR jitter is harmless since the system clock of the rendering engine is likely to be the PC system clock, not the PCR's. STB are different. -Thierry _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
