Re: Ker-ching!
>>>All audio and video frames are stamped with a field called PTS - the Presentation Time Stamp. This denotes the point at which the frame is required to be played out. The transport stream contains elements called PCR - the Program Clock Reference. This syncs the System Time Clock (STC) on the decoder to the time on the encoder. All compliant decoders will thus be running synchronised STCs, and so will output audio and video frames at the same time.
Yes, I know what's in an MPEG transport stream, thanks. And no it does not sync the STC on the decoder to that of the encoder at the head-end. The STC in the decoder will always lag behind the encoder due to the propagation delays (only really significant for satellite DVB-S) and also the encoding/modulation & demodulation/decoding delays (significant for all DVB).
The PCRs are there to synchronise elementary streams within a single transport stream on a single set-top box not to some external absolute time reference.
Absolute time is handled by a UTC value in the TDT but this is not used for determining when to output elementary streams. It's only for clock and EPG display etc.
>>> None of that matters, as this is not an open-loop system; the frames are presented at the time specified in the PTS, not whenever the box feels like it.
It is an open loop system. A closed loop system requires feedback. There is no communication from the STB to the head-end. Essentialy all audio, video and timing data flows in one direction, even within the STB. (The STC might well be a digital PLL kept locked to the PCRs but that's purely for reducing AV timing jitter.)
>>>Are you trying to tell me that's a significant delay? You're going to find it hard to measure that, let alone perceive it.
I'm telling you exactly that.
It's hardly surprising. Decompressing compressed audio and video and syncing different streams requires buffering. As does applying FEC. Or combining the sub-channel bitstreams - which is another form of syncing. Or converting to HDMI format or PAL signals. All this buffering introduces a delay.
This delay will inevitably be different for different implementations. At least 100 milliseconds different in the case of my kit, I would say.
This is one of the reasons why STBs can take so long to 'change channels'. All those buffers have to be flushed and refilled before the new picture and sound can be output. If the delays were imperceptible then channel changes could appear instantaneous on every STB. On a good STB with a really fast DSP channel changes are fast - on a cheap one they're slow, more evidence that the delay is variable between STB models.
>>>That's because, in larger rooms, the speed of sound becomes significant; the difference in path length between the operator and each set of speakers can cause differences in when the sound actually reaches the ears.
Erm - the delay compensation on the digital audio input from the TV isn't for between the front and back speakers on the sound system, it's between the speakers on the TV and the front speakers & woofer on the sound system. Nothing to do with room acoustics - that's a separate function.
Anyway, sound travels at around 340m/s in air at standard temperature and pressure. The distance between the STB & radio in my living room and the ones in one of the bedrooms is around 15 metres. If I have the analog FM radio in the bedroom on at the same time as the one in the living room the propagation delay of around 50ms is too short to be noticeable by the human ear - I perceive no 'echo effect'.
They delays between the audio from the DVB STBs in the two rooms is very noticeable and so must be at least 80 milliseconds, probably more like 200 ms from what I can tell.
Anyway, if I stand in the doorway I can see both screens. The video on one clearly lags behind that on the other. You're not going to claim that's because of the distance difference are you?
And yes, that's with both on standard def or both on high def. Although you seem to be implying that that shouldn't matter - when in fact it shows an even greater difference with HD on one and SD on the other.
>>>They [my STBS] might well be a common chipset and be based on the same reference software ...
You're not supporting your case. If they were using the same chipset & software and they are still out of sync - which they most definitely are - then even the same kit can have different delays!
Anyway, this is rather off topic for the article in question, so I'll bid you adieu.
Biting the hand that feeds IT
