rowan.depomerai

It’s been a long time since I’ve updated you, for which I apologise. However the good news is this will hopefully be my last post about lipsync issues on BBC HD. That’s in part because I’m really running out of bad puns based on the word ’sync’, but mostly because – and I realise I’m tempting fate here – we may have got to the bottom of it all. Let me elabourate…

If you read the comments on this blog, you’ll recall that we’ve been having problems with the lipsync of stereo programmes on BBC HD. Surround sound programmes have been fine since the previous work I’ve done, but stereo was not working quite right. It turns out that our broadcast chain introduces around 15ms of audio delay on stereo programmes, which is normally too little to notice. However if a programme is delivered with audio slightly late, as recently happened with Hustle, the two small and virtually invisible delays add up to create one much larger and very noticeable delay. So the question has been, where is that 15ms coming from, and how can we remove it? I’ve spent a long time looking at this over the last few weeks, and I’ve been tearing my hair out as every bit of testing we’ve done has given results that we couldn’t quite explain, until yesterday when things became clear.

I’ve mentioned before that we use Dolby E to encode audio around our broadcast infrastructure. It’s a technology that allows us to fit up to 8 channels of audio (plus some extra metadata) into the data space which usually fits just 2 audio channels. The difficulty lies in the fact that surround sound programmes arrive at the BBC with Dolby E encoded audio, whereas stereo programmes use uncompressed audio. The same broadcast infrastructure has to handle both types of audio with the same latencies (delays). Dolby E takes time to decode (1 video frame or 40ms to be precise) so we delay the video by the same amount to compensate and ensure that they stay in sync. But the stereo must therefore be delayed by the same amount, otherwise that video delay we’ve added will cause stereo programmes to be out of sync. The question you’re probably asking by now is “so what went wrong on BBC HD?”. It’s a good question, dear reader, and it has a simple and a complex answer. The simple version is this; we thought that the delays through each piece of equipment were the same for stereo and surround programmes, but our testing proved that this wasn’t the case. Finding which device had the problem and why was more challenging, and that forms the long answer…

Before I continue, I’ll tell you what happens now. The details of the problem, and therefore the solution, finally became clear only yesterday. We used a duplicate set of equipment to do tests without affecting broadcast chain. The solution we found requires some pretty major changes, so we’re waiting now on authorisation from the relevant people to allow us to make the changes in the broadcast chain. I’m sure you’ll appreciate that if any old engineer was allowed to change the on-air equipment in fundamental ways, we’d be a bit open to disastrous mistakes; so you’ll have to allow us a couple of days to get the change done. Soon enough though, we will get the changes on air and we should have properly in-sync stereo as well as surround programmes, rather than only “roughly in-sync” stereo. Phew!

Those who just want to know what we’re up to and when things will be better will hopefully be satisfied with what I’ve said so far. The hardcore tech-heads amoung you may want to know more however, so I’ll do my best to explain… When a programme arrives in the mixing part of the signal path (be it from a playout server or from a live contribution), the audio is embedded in the video. In other words, there’s one cable which carries both audio and video in a digital data stream. So the first thing that we do is de-embed the audio. We take the SDI video stream and extract the audio, spewing it out on a separate digital audio interface. This then goes to a Dolby E decoder, which decodes Dolby E if present, or just passes through the audio unchanged if it’s uncompressed. At this point the audio goes through the mixer, then gets Dolby E encoded, embedded again and continues on its way. It’s the de-embedder and the decoder that we’re interested in here, as they make up the bit of the signal path which is able to behave differently depending on whether the incoming audio is PCM (uncompressed) or Dolby E. My initial suspicions were around the decoder, which has a configuration option for how it handles PCM audio. It passes it through unaltered, however it can delay it by one of two amounts; “minimum” or “single frame”. The single frame option is what we want, as it delays the audio by the same amount as a Dolby E stream would be delayed, thus keeping everything in sync. However we have been using “minimum” because even in this mode the PCM ends up being a bit too late, so setting it to “single frame” just makes things worse. But why? I shan’t tell you all the possibilities we checked and the false leads we had, instead I shall cut to the chase… it was the de-embedder’s fault!

Don’t you just hate it when electronic devices are too smart for their own good? When your word processor magically changes (c) to a copyright symbol and actually you just wanted a c in brackets? Well, our de-embedder was being way to smart for its own good. We had been under the impression that it was applying a frame of delay to all audio. This is much more than it needed to, but by selecting a one frame delay it becomes predictable and easy to manage. Excellent, thought I. The problem is that it wasn’t that simple. After a lot of settings checking, head scratching and examination of the somewhat cryptic manual, it turned out that all audio was not being treated equal. We inadvertently had the device configured to delay the PCM audio by 1 frame but not the Dolby E! The bright idea behind this option in the de-embedder is to allow you to compensate for the decode delay of the Dolby E by similarly delaying PCM and/or the video. However, as I previously mentioned, we were already applying a compensating delay in the Dolby decoder itself. So we had 2 sets of delay where we only wanted one! Then even with the Dolby decoder set to apply “minimum” delay to PCM audio, it seems to add about 15ms of delay – a familiar figure! So what we shall be doing is turning off all delay in the de-embedder and setting the “single frame” delay mode in the decoder. Job done… I hope.

Hopefully I’ve given some insight into the problems we’ve had, and – touch wood – we should be all fixed soon. You’ll likely be unable to see the difference when we do make the change, because you should be unable to see the sync error currently due to it being so small. However, next time we have a programme delivered with a tiny lipsync error it should stay tiny and impossible to notice, rather than being amplified by the broadcast chain into a serious and visible error.

A final note just to say that I come to the end of my time working for BBC HD soon, I shall be moving on to another project. I’ll aim to do one more post before I leave to tell you a little about some other things we’ve been doing, so expect a post next week.

This entry was posted on Thursday, March 5th, 2009 at 10:19 am and is filed under BBC HD Audio. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.