IPShowcase

Video: Case Study FIS Ski World Championship

Posted on by Russell Trafford-Jones

There’s a lot to learn when it comes to implementing video over IP, so it’s healthy to stand back from the details and see a working system in use to understand how the theory becomes reality. There’s been a clear change in the tone of conversation at the IP Showcase over the years as we’ve shifted from ‘trust us, this could work’ to ‘this is what it looks like!’ That’s not to say there’s not plenty to be done, but this talk about an uncompressed 2110 remote production workflow is great example of how the benefits of IP are being realised by broadcasters.
Robert Erickson is with Grass Valley specialising in sports such as the FIS Alpine World Ski Championships which were in the city of Åre in Sweden some 600km from Stockholm where Sweden’s public broadcaster SVT is based. With 80 cameras at the championships to be remotely controlled over an uncompressed network, this was no small project. Robert explains the two locations were linked by a backbone of two 100Gbps circuits.

The principle behind SVT’s project was to implement a system which could be redeployed, wouldn’t alter the viewers’ experience and would reduce staff and equipment on site. Interestingly the director wanted to be on-site meaning that the production was then split between much of the staff being in Stockholm, which of course was where most of the equipment was, and Åre. The cameras were natively IP, so no converters were needed in the field.

Centralisation was the name of the game, based in Stockholm, producing an end-to-end IP chain. Network switching was provided by Arista which aggregated the feeds of the cameras and brought them to Stockholm where the CCUs were located. Robert highlights the benefits of this approach which include the use of COTS switches, scalability and indifference as to the circuits in use. We then have a look inside the DirectIP connection which is a 10gig ‘pipe’ carrying 2022-6 camera and return feeds along with control and talkback, replicating the functionality of a SMPTE fibre in IP.

To finish up, Robert talks about the return visions, including multivewers, which were sent back to Åre. A Nimbra setup was used to take advantage of a lower-bandwidth circuit using JPEG 2000 to send the vision back. In addition, it carried the data to connect the vision mixer/switcher at Åre with the switch at Stockholm. This was the only point at which noticeable latency was introduced to the tune of around 4 frames.

Watch now!
Download the presentation
Speakers

Robert Erickson Robert Erickson
Strategic Account Manager Sports and Venues,
Grass Valley

Video: Efficient Carriage of Sub-Rasters With ST 2110-20

Posted on by Russell Trafford-Jones

One of the main promises of IP video is flexibility and what better way to demonstrate that than stepping off the well-worn path of broadcast resolutions? 1920×1080 is much loved nowadays, but not everything needs to be put into an HD-sized frame. SMPTE ST-2110 allows video of all shapes and sizes, so let’s not be afraid to use the control given to us.

Paul Briscoe, talking on behalf of Evertz, takes the podium to explain the idea. Using logo insertion as an expample, he shows that if you want to put a small BUG/DOG/graphic on screen with a key, then real there’s not a lot of data that needs to be transferred. Typically a graphic needs a key and a fill. Whilst the key is typically luma-only, the fill needs to be full colour.

In the world of SDI, sending your key and fill around would need two whole HD signals and up to 6Gbps of data. When your graphic is only a small logo, these SDI signals are mainly redundant data. Using ST 2110-20, however, in the IP domain we can be much more efficient. 2110 allows resolutions up to 32,000 pixels square so we should be able to send just the information which is necessary.

Paul introduces the idea of a “pixel group” (pgroup) which is the minimal group of video data samples that make up an integer number of pixels and also align to an octet boundary. Along with defining a size, we also get to define an X,Y position. Paul explains how using pgroups helps, and hinders, sending video this way and then delves in to how timing would work. To finish off, Paul examines edge cases and talks about other examples such as stock tickers, not to mention the possibility of motion as we get to define the X, Y position.

Watch now!
This wall chart gives more info on pgroups and other low-level ST 2110-20 constructs.
Download the slides from this presentation

Speakers

Paul Briscoe Paul Briscoe
Principal Consultant,
Televisionary Consulting

Video: Benefits of IP Systems for Sporting Venues

Posted on by Russell Trafford-Jones

As you walk around any exhibitions there seems to be a myriad of ‘benefits’ of IP working, many of which don’t resonate for particular use cases. Only the most extraordinary businesses need all of the benefits, so in this talk, Imagine Communication’s John Mailhot discusses how IP helps sports venues.

John sets the scene by separating out the function of OB trucks and the ‘inside production’ facilities which have a whole host of non-TV production to do including driving scoreboards, displays inside the venue, replays and importantly has to deal with over 250 events a year, not all of which will have an OB truck.

We see that the scale that IP can work at is a great benefit as many signals can fit down one fibre and 2022-7 seamless switching can easily provide full redundancy for every fibre and SFP. This is a level of redundancy which is simply not seen in SDI systems. With stadia being very large, necessitating cable runs of over 500m, the fact that IP needs fewer cables overall is a great benefit.

John shows an example of an Arista switch only 7U in height which provides 144x 100G ports meaning it could support over 4000 inputs and 4000 outputs. Such density is unprecedented and for OB trucks can be a dealbreaker. For sports venues, this can also be a big motivator but also allow more flexibility in distributing the solution rather than relying on a massive central interconnect with a 1100×1100 SDI router in a central CTA.

TV is nothing without audio and the benefits to audio in 2110 are non trivial since with the audio being split off from the video, we are no longer limited to dealing with just 16 channels per video and de-embedding from a video frame any time we want to touch it.

Timing is an interesting benefit. I say this because, whilst PTP can end up being quite complex compared to black and burst, it has some big benefits. First off, it can live in the same cables as your data where as black and burst requires a whole separate cable infrastructure. PTP also allows you to timestamp all essences which helps with lip-sync throughout your workflow.

John leads us through some examples of how this works for different areas finishing by summing up the relevant benefits such as scalability, multi-format, space efficient, and timing amongst others.

Watch now!
Download the slides
Speakers

John Mailhot John Mailhot
CTO, Networking & Infrastructure,
Imagine Communications

Video: PTP in Virtualized Media Environment

Posted on by Russell Trafford-Jones

How do we reconcile the tension between the continual move towards virtualisation, microservices and docker-like deployments and the requirements of SMPTE 2110 to have highly precise timing so it can synchronise the video, audio and other essence streams? Virtualisation adds fluidity in to computing so it can share a single set of resources amongst many virtual computers yet PTP, the Precision Time Protocol a successor to NTP, requires close to nano-second precision in its timestamps.

Alex Vainman from Mellanox explains how to make PTP work in these cases and brings along a case study to boot. Starting with a little overview and a glossary, Alex explains the parts of the virtual machine and the environment in which it sits. There’s the physical layer, the hypervisor as well as the virtual machines themselves – each virtual machine being it’s own self-contained computer sitting on a shared computer. Hardware must be shared between, often, many different computers. However some devices aren’t intended to be shared. Take, for instance, a dongle that contains a licence for software. This should clearly be only owned by one computer therefore there is a ‘direct’ mode which means that it is only seen by one computer. Alex goes on to explain the different virtualisation I/O modes which allow devices which can be shared, a printer, storage or CPU for instance need to have access computers may need to wait until they have access to the device to enable sharing. Waiting, of course, is not good for a precision time protocol.

In order to understand the impact that virtualisation might have, Alex details the accuracy and other requirements necessary to have PTP working well enough to support SMPTE 2110 workflows. Although PTP is an IEEE standard, this is just a standard to define how to establish accurate time. It doesn’t help us understand how to phase and bring together media signals without SMPTE ST 2059-1 and -2 which provide the standard of the incoming PTP signal and the way by which we can compare timing and media signals (more info here.) All important is to understand how PTP can actually determine the accurate time given that we know every single message has an unknown propagation delay. By exchanging messages, Alex shows, it is quite practical to measure the delays involved and bring them into the time calculation.

We now have enough information to see why the increased jitter of VM-based systems is going to cause a problem as there are non-deterministic factors such as contention and traffic load to consider as well as factors such as software overhead. Alex takes us through the different options of getting PTP well synchronised in a variety of different VM architectures. The first takes the host clock and ensures that is synchronised to PTP. Using a dedicated PTP library within the VM, this then speaks to the host clock and synchronises the VM OS clock providing very accurate timing. Another, where hardware support in the VM’s hardware for PTP isn’t present, is to have NICs with dedicated PTP support which can directly support the VM OSes maintaining their own PTP clock. The major downside here is that each OS will have to make their own PTP calls creating more load on the PTP system as opposed to the previous architecture whereby the host clock of the VM was the only clock synchronising to the system PTP and therefore there was only ever one set of PTP messages no matter how many VMs were being supported.

To finish off, Alex explains how Windows VMs can be supported – for now through third-party software – and summarises the ways in which we can, in fact, create PTP ecosystems that incorporate virtual machines.

Watch now!
Download the slides
Speakers

Alex Vainman Alex Vainman
Senior Staff Engineer,
Mellanox Technologies