LATENCY IS GENERATED…
STREAMS SHOULD BE LEFT IP UNTIL THERE IS A GOOD REASON FOR THEM TO BE OUTPUT TO THE BASEBANDWORLD
y ... by a frame phaser – free-running input signals require a frame phaser that synchronises them. y ... on the network – each stream takes a certain amount of time to traverse the network. y ... by the video receiver – a stream infrastructure. Since the stream was concurrent at input (or synchronised by the frame phaser) and took non- zero time to traverse the network, it is delayed a little, with respect to the SDI infrastructure. And it must be delayed further until the beginning of the next frame (∆ = one frame). transmitted to an SDI output has to run in sync with the SDI
Latency induced at this stage adds up to 20 lines for decompression, a few more for buffer management, and some extra for encapsulation – for an overall delay of just 4ms. Beyond this stage, all ingested signals are available to the entire system as IP streams. If the video switcher is IP-compliant, no IP–SDI conversion is required before its input, and so no additional delay is induced. The same applies to slow-motion machines: those with IP ports also cause no latency. There is an important consideration for the entire operation. Video must be synchronous with audio at every point where the combined signal is passed on to a baseband device (SDI) – or where an internal router (inside a C100) is required for clean switching. CONTROL YOUR CONVERSIONS The smartest way of keeping latency in check is to work with as few IP–SDI–IP conversions as possible. Remain in the IP realm as long as you can. That is the reason why optional VC-2 conversion routines inside dedicated V__matrix C100 blades have IP inputs and outputs: the blades only compress or decompress streams. Technically, these C100 blades could perform any one of a variety of additional tasks, like gateway functionality or internal routing. However, the customer in our example does not take advantage of this.
Routing a signal from a C100’s SDI input to one of its outputs requires two synchronisation passes – one at the input, another before the output – both of which induce latency. If such a ‘looped’ stream is transported elsewhere – to be output to a multiviewer, for instance – it needs to be synchronised a third time. Streams should be left in the IP domain until there is a good reason for them to be output to the baseband world. As long as the delay prior to this ‘final’ synchronisation and conversion pass remains below one frame, the output signal only needs to be nudged beyond the end of an ‘incomplete’ frame, resulting in a delay of only a single frame between ingest and output of a signal. Lawo’s new DSK (Downstream Keyer) licence for V__matrix C100 blades, called +ab_dsk, is also used by its Belgian customer. It works with an IP stream as background and an SDI-based key and fill. This is due to most graphics machines still only having SDI outputs. By now, you know that this involves an SDI–IP conversion, and so an additional time-alignment pass – hence an additional one-frame delay at the keyer ’s output. All broadcasters expect minimal latency. With some sensible workflow structuring, you can be certain it won’t run away from you.
LATENCY CAN BE AVOIDED…
y ... if the input signal is synchronous, or at least syntonous (having the same frequency) – in this case, no frame phasing would be required. y ... on the network – while the network can’t be sped up, multiple hops across it can be avoided by leveraging V__matrix’s comprehensive audio and video processing toolset. It is possible, for instance, to have colour correction, SDR/HDR conversion, A/B mixing and downstream keying inside a single C100 processing blade. y ... by omitting synchronisation – signals that don’t need to be output via SDI, or mixed using an A/B mixer, don’t need to be synchronised in the video receiver. IP-native processing can mostly happen asynchronously, resulting in lower latency.
feedmagazine.tv
Powered by FlippingBook