rowan.depomerai

Last time I  told you about the efforts we’ve been making at BBC HD to get an A/V sync test to your TV in order that you can measure the synchronisation between audio and video in your home TV setup. You’ll be very pleased to know that we’re done and the test has made it to air! Andy Quested has posted in his blog about how you can use the sync test – and its counterpart the test card – to line-up your equipment. I therefore won’t repeat that here, but I wanted to give you a bit more detail about what we’ve achieved and how.

I told you in my previous post that we needed to check every element of the signal chain in order to ensure that we broadcast this signal completely in-sync. We started by getting the sync test itself into the promo loop which runs on BBC HD during the day. Here’s a slide from a presentation I have last week on how we did this:

Given that we had the sync test itself on tape and tested in-sync, we then put this into the edit suite. (In the interests of BBC neutrality I ought to point out that this particular suite is an Avid, though we do use other software too! In fact, a Final Cut Pro suite was used extensively in producing the sync test in the first place.) We then took that to the dub, which is the part of the editing process where the audio is tweaked, finished and finalised. This is the only place in the editing chain where we can move the audio by sub-frame (i.e. millisecond) increments. We then went back to tape, having encoded the audio in Dolby E. Back to the edit suite we go (3 floors down), where we can play out the tape and examine the sync signal on a CRT. This is necessary because the projector and other displays in the dubbing suite are not guaranteed to be perfectly in sync. We used a clever little box with a light sensor and an audio input to check what the sync offset is by examining the white flash at the top of the screen.

Armed with a number of milliseconds of sync offset, we headed back to the dub, moved the audio to correct for the offset, and repeated the process. We went round this loop a few times before getting it perfect, and it’s here that I shall hang my head and beg the forgiveness of my mother who’s a mathematician, because at least one extra iteration was required because I messed up the conversion between milliseconds (which the measuring device works in) and 100ths of a frame (which the dubbing suite works in). Oops! However, I eventually came away armed with the December BBC HD promo which included a sync test which we knew was in sync.

The next part of the puzzle was the broadcast chain:

We ingested the tape into our playout servers, run by Red Bee. We then played the clip out and measured the sync on the server’s output. It was within 1ms, which was great news. From there we checked a few more places through the chain, ending up in CCA, the Central Communications Area in Television Centre. This is the last point in the chain before we encode the video for broadcast, and we discovered a delay of no more than 2ms. Great news!

Shortly after, we took the file from the playout server to Kingswood Warren, where we have a duplicate setup of the encoding chain. We ran the test through the encoders and found that they introduce a few milliseconds of audio delay. However, they have a configuration parameter which allows you to delay the incoming video. We already use this parameter to correct for the delay introduced to the audio by Dolby E decoding and Dolby Digital encoding, so all we needed to do was change this number. We sent this change request to our technology partner Siemens, who implemented the change. We were then good to go, and arranged a one-off broadcast of the test signal.

The reason we do this is so we can test that the signal transmitted really is in sync. As Andy explained in his blog, the usual broadcasting process is to test that a signal is “OK leaving me”, in other words it is correct when we send it. However we wanted to go further here and ensure that it is “OK arriving at you”, meaning that when you receive it from a satellite dish the signal is definately in sync. This means you can be sure that any offset you find is introduced by your equipment and not our broadcast. We were very pleased to find that the offset was 0.9ms, which is very tiny indeed. This made one very happy Rowan last week.

However nothing’s ever that simple, is it?! We found that the sync test caused a problem with our output encoders. The eagle eyed amoung you will notice that in my last post the screenshot of the sync test was green, whereas the version that we now transmit is grey. (The white flashes are and have always been white, obviously!). The short version of the story is that a certain part of the green signal caused a problem in the MPEG4 encoder which caused magenta (purple-ish) flashes to appear on the video. This was obviously no good, so we had to ammend the signal. However don’t panic, the new colouring doesn’t affect how you use the signal to line-up your sync!

So how do we check the off-air signal is in sync? After all, if we decoded it and used the normal sync checker to examine a CRT display, we could get an inaccurate measurement, as the decoder could intoroduce a delay all of its own. However, there’s a more reliable method.

• First we capture the bitstream onto a computer.
• We can the use a transport stream analysis tool to decode the individual frames of video, and find the frame with the first white line flash. Each frame in the broadcast stream has a Presentation Timestamp (PTS), so we note the PTS for that frame.
• We then use the analysis tool to decode the Dolby Digital audio to an analogue waveform displayed on screen. Next, find the start of the audio clap in this waveform. Unlike the video frame there will not be a PTS just for this audio sample, the PTS will cover a large number of samples. So we find this PTS and note it down and then count how many audio samples there are from this PTS to the sample at the start of the audio clap – we refer to this as the audio offset.
• By subtracting one of the PTS values from the other and taking into account the audio offset, the A/V timing in the stream can be determined. This is all done by a colleague at Kingswood, but given the amount of arithmetic involved, and the widely know inability of engineers to do simple maths (as proved by me earlier), he always gets the values sanity checked by me or someone else! (If you’re interested, the PTS values are in units of 90kHz and the audio will have been sampled at 48kHz, just to make everything complex!)

So there you go, that’s how we get a signal in sync to arrive at your home. After changing the colours, we of course had to ingest the clip into our playout servers all over again, so we did a new off-air sync test to ensure that nothing went wrong in the process of making the change, and I’m pleased to say everything went well!

So if you have an HD receiver and your sound is connected to a separate amplifier, get yourself on over to Andy’s blog and find out how to test your setup. After Christmas I’ll let you know how we’re getting on with other aspects of my work, like improving the way we test incoming HD signals from outside broadcasts prior to transmission. Have a great Christmas!

This entry was posted on Wednesday, December 17th, 2008 at 12:24 pm 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.