TV Home Forum

BBC Two/Lambing Live Problem

No sound on Lambing Live (April 2011)

This site closed in March 2021 and is now a read-only archive
IS
Inspector Sands
Not every duration can ever be ingested as it would simply require too much server space only a selection make it to server.

Not every duration, just a few 2 minuters, a few 5's and a few 10's.

It's a state of the art broadcast centre, designed to be upgradable and expandable, I find it hard to believe it doesn't have enough server space for a few short permanant standbys Wink
NG
noggin Founding member
Yep - there are two issues aren't there?

There are scheduled standbys which are there to replace specific programmes if, for some reason, they are late deliveries and fail to deliver OR are live programmes which for some reason can't be broadcast (and this is known about before TX). These are usually of similar duration to the shows they are standbys for. These standbys are scheduled along with the main programme usually - so are different for each live show. Ingesting all of these would be an issue - but these aren't designed to be played in breakdown situations.

There is a separate requirement to fill the gaps when a live programme (or a recorded programme played in via a non-standard route - say live from an edit suite or from a remote location) is interrupted for either a technical reason (loss of power, major equipment failure, loss of circuit etc.), for an editorial reason (the show is hijacked by protestors), or a safety reason (the location the show is broadcasting from has a fire alarm etc.) These would be shorter standbys and not specific to the programme they are replacing. It would be an editorial decision - informed by an understanding of the failure - which would decide what duration to play. A major power failure on site is likely to take a minimum of 5'00" (probably nearer 10'00") to cope with, whereas a mistaken circuit misroute could be rectified in seconds.
NG
noggin Founding member
It's a state of the art broadcast centre, designed to be upgradable and expandable, I find it hard to believe it doesn't have enough server space for a few short permanant standbys Wink


Hmm - and it's a state of the art broadcast centre which still can't do ECPs without a frame jump as the DVE goes in, or lose a key and background cleanly on a cut...

(No matching frame delay in the source to the DVE means when the DVE goes in you see the rolling credits jump back a frame or two, and the key and background issue is that you often see the text over menus etc. disappear a frame before the background does... Both very poor. Amazed that they are deemed acceptable.)

And don't get me started about the 702vs720 twitching at the end of HD programmes on BBC One HD... When BBC One HD opts back into BBC One SD for junctions off the back of live HD shows, they go a frame or two earlier on the HD channel, cutting to an upconvert of the SD channel carrying the HD show downconverted, but one of the bits of kit (either the upconverter or the downconverter) is incorrectly set-up and causes a width change. (Probably a result of people still not realising that 702x576 is the 16:9 portion of the image NOT 720x576...)
MA
Markymark

And don't get me started about the 702vs720 twitching at the end of HD programmes on BBC One HD... When BBC One HD opts back into BBC One SD for junctions off the back of live HD shows, they go a frame or two earlier on the HD channel, cutting to an upconvert of the SD channel carrying the HD show downconverted, but one of the bits of kit (either the upconverter or the downconverter) is incorrectly set-up and causes a width change. (Probably a result of people still not realising that 702x576 is the 16:9 portion of the image NOT 720x576...)


Ah, that's what the twitch is ! I've tried to freeze it on my PVR to examine what's going on, but it's impossible to hit the pause button at the right moment.

While we're on the subject of Red Bee misdemeanors, can I chuck in the 250ms audio mute one second after the start of every commercial break on the C4 South/East macro region, and the chroma lagging one field behind the luma on many C4/E4/M4 programmes, a fault that persisted for almost a year ! It was due AIUI to some anomaly when moving material between archive and near line servers ? !
NG
noggin Founding member

And don't get me started about the 702vs720 twitching at the end of HD programmes on BBC One HD... When BBC One HD opts back into BBC One SD for junctions off the back of live HD shows, they go a frame or two earlier on the HD channel, cutting to an upconvert of the SD channel carrying the HD show downconverted, but one of the bits of kit (either the upconverter or the downconverter) is incorrectly set-up and causes a width change. (Probably a result of people still not realising that 702x576 is the 16:9 portion of the image NOT 720x576...)


Ah, that's what the twitch is ! I've tried to freeze it on my PVR to examine what's going on, but it's impossible to hit the pause button at the right moment.


That's my best guess. 1920x1080 16:9 source, 1920x1080 destination, but somewhere along the line there is a width change as it goes via SD. I suspect this is caused by one converter correctly configured to convert between HD and SD with a 1920x1080 to 702x576 mapping, but the other converting in the other direction to be doing an incorrect 1920x1080 to 720x576 mapping - causing a width mismatch once the signal has gone there and back.

The number of 'professional' engineers, editors, designers etc. and manufacturers who don't know that 16:9 is NOT 720x576 in SD but only the 702x576 central portion (with an extra 9 samples each side to make the maths work nicely - and also to avoid clipping of edge transitions) is scary...

ISTR that the 702vs720 issue is pretty widespread these days (including on the SD downconverted outputs of some HD cameras...)

Quote:

While we're on the subject of Red Bee misdemeanors, can I chuck in the 250ms audio mute one second after the start of every commercial break on the C4 South/East macro region, and the chroma lagging one field behind the luma on many C4/E4/M4 programmes, a fault that persisted for almost a year ! It was due AIUI to some anomaly when moving material between archive and near line servers ? !


Ah - I spotted the chroma / luma mismatch - very annoying...

And on the subject of C4 - whatever horrid box is doing their end credit promotions appears to do something very nasty to interlaced content (I don't think it is my TV's de-interlacer)
MA
Markymark

And on the subject of C4 - whatever horrid box is doing their end credit promotions appears to do something very nasty to interlaced content (I don't think it is my TV's de-interlacer)


It's not, I've seen it on a CRT telly.
NG
noggin Founding member

And on the subject of C4 - whatever horrid box is doing their end credit promotions appears to do something very nasty to interlaced content (I don't think it is my TV's de-interlacer)


It's not, I've seen it on a CRT telly.


Thought so - looked to consistent to be a display fault. Can't believe that anyone is allowing it to continue. Renders closing credits car-crash bad...
HA
harshy Founding member
I thought is was 704x576 but you say 702x576 noggin.
NG
noggin Founding member
I thought is was 704x576 but you say 702x576 noggin.


704x576 is the nearest "MPEG multiple" to 702x576 - and is used by some broadcasters for transmission.

However it all comes back to analogue compatibility.

The active line in analogue 50Hz SD (PAL composite or Analogue Component YPrPb) is 52us in duration. This is the duration of a 4:3 or 16:9 analogue signal.

With a luminance sampling rate of 13.5MHz that means 52us lasts for exactly 702 samples.

However for a number of reasons there is latitude in the digital ITU 601 (formerly CCIR Rec 601) spec that makes the digital active line a bit wider than 702 samples. This ensured that slightly mistimed signals didn't get cropped, and also ensured that edge transitions didn't get clipped - which could cause ringing. (Similar logic is behind the 16-235 rather than 0-255 dynamic range used in digital video 8-bit sampling) This means the 720 sample line is 'longer' than the analogue 4:3 or 16:9 lines - and thus the 720x576 frame is slightly wider than 4:3 or 16:9.

However 702 is not a nice multiple of 8 or 16, which are the usual macroblock dimensions used in digital compression like MPEG2 and H264. So either the entire 720x576 image is compressed to MPEG2/H264 (which would be the expectation for studio compression - as you don't want to lose the edges within a studio set-up), OR the nearest MPEG multiple of 704x576 is used (with only 2 samples - 1 each side - of lattitude).

The theory is that the extra 18 or 2 samples in the 720x or 704x576 frame compared to the 702x576 frame should never be seen on a display (as that should only show the 4:3 or 16:9 702x576 central portion if operating correctly) so there is no point wasting bandwith sending them...

(Within a studio you DO have the issue of what happens when you shrink a picture - should you see the full width of the 720x576 frame - which is guaranteed to have black edges if from a standard analogue source or a digital source only filling the 4:3/16:9 image area ???)
DA
davidhorman
I thought is was 704x576 but you say 702x576 noggin.


704 is the case for NTSC, and it's also a valid width for DVD video, while 702 isn't due to, as Noggin said, not being a multiple of 16.

David

Newer posts