Video: TV moving to all IP – Dream or Reality?

As IP continues to infiltrate all aspects of the broadcast industry, this panel asks how close we are to all-IP TV delivery, what that would actually mean and how what technologies exist to get us there. As we’ve seen in contribution and production, IP brings with it benefits to those that embrace it, but not all of those benefits apply to every business so this panel considers where the real value actually lies.

Pedro Bandeira from Deutsche Telekom, Rob Suero from RDK, Xavier Leclercq from Broadpeak joins Wyplay’s Dominique Feral in this discussion moderated by Andreas Waltenspiel. The discussion starts with the motivations to move to IP with Pedro explaining that the services he delivers are viewed by the viewers alongside the big internet-delivered services like Netflix. As such, he needs access to the same technologies and sees a lot of innovation in that sphere. This is why he’s advocating a move away from multicast delivery of video to unicast; delivering with exactly the same technologies the giants are using.

 

 

For Pedro, streaming technology is an enabler, not a differentiator. As the foundation of his service, he wants it to be rock solid so feels the choice of partners to provide the technology is very important as he intends to benefit from incremental improvements as the base technologies improve. Part of the flexibility that unicast technologies provide, says Pedro, is removing the baggage of older technologies. He sees these as a burden when he wants the same service and quality of experience on devices as well as STBs.

Rob from Broadpeak feels that Multicast, or specifically Multicast-ABR is a really interesting technology because of the scalability and network efficiency which Pedro is willing to sacrifice to access other streaming technologies. Multicast ABR, however, delivers to the home as multicast so the impact on the telco network is minimised and only in the home is the service translated into a standard stream like HLS or DASH. In principle this allows companies like Deutsche Telekom to use the technologies he’s interested in whilst also delivering with network efficiency.

“A great technology for transitioning” is Pedro’s view of ABR Multicast. If we had the bandwidth, he feels no one would bother using it. However, he does agree that it’s useful in those markets whether the infrastructure can’t support a pure unicast offering and he does see ABR Multicast being part of his delivery strategy. He would prefer to avoid it as it requires home gateways and vendor support as well as being another point of failure. With 50 million homes in Europe on IPTV, there are plenty of services to transition.

The conversation then turns to RDK, the generically titled Reference Development Kit which is the name of an open source project, Rob explains, which abstracts the creation of new OTT apps and services from the underlying vendor equipment meaning you don’t have to develop software for each and every device. Removing the ties to OEMs keeps costs down for operators and allows them to be more agile. Dominique explains how writing with RDK may be free, but that doesn’t mean it’s easy and points to an experience where Wyplay shaved 6 seconds of latency off a customer’s service by optimising the way the app was written. At the end of the day, Dominique sees the route to a good, low-latency service as a fight with all aspects of the system including the encoder, packaging protocol, CDN, DRM latency and much more. This means optimising RDK is just part of a wide package of services that companies like Wyplay can offer.

The panel concludes by talking about learning RDK, upskilling colleagues, bringing them along on the journey to all-IP and offering advice to those embarking on projects.

Watch now!
Speakers

Pedro Bandeira
VP Product & New Business, Europe,
Deutsche Telekom
Rob Suero Rob Suero
Head of Technology,
RDK
Dominique Feral Dominique Feral
Chief Sales & Marketing Officer,
Wyplay
Xavier Leclercq Xavier Leclercq
Head of Business Development,
Broadpeak
Andy Waltenspiel Moderator: Andreas Waltenspiel
Founder & GM,
Waltenspiel Management Consulting

Video: Proper Network Designs and Considerations for SMPTE ST-2110

Networks from SMPTE ST 2110 systems can be fairly simple, but the simplicity achieved hides a whole heap of careful considerations. By asking the right questions at the outset, a flexible, scalable network can be built with relative ease.

“No two networks are the same” cautions Robert Welch from Arista as he introduces the questions he asks at the beginning of the designs for a network to carry professional media such as uncompressed audio and video. His thinking focusses on the network interfaces (NICs) of the devices: How many are there? Which receive PTP? Which are for management and how do you want out-of-band/ILO access managed? All of these answers then feed into the workflows that are needed influencing how the rest of the network is created. The philosophy is to work backwards from the end-nodes that receive the network traffic.

Robert then shows how these answers influence the different networks at play. For resilience, it’s common to have two separate networks at work sending the same media to each end node. Each node then uses ST 2022-7 to find the packets it needs from both networks. This isn’t always possible as there are some devices which only have one interface or simply don’t have -7 support. Sometimes equipment has two management interfaces, so that can feed into the network design.

PTP is an essential service for professional media networks, so Robert discusses some aspects of implementation. When you have two networks delivering the same media simultaneously, they will both need PTP. For resilience, a network should operate with at least two Grand Masters – and usually, two is the best number. Ideally, your two media networks will have no connection between them except for PTP whereby the amber network can benefit from the PTP from the blue network’s grandmaster. Robert explains how to make this link a pure PTP-only link, stopping it from leaking other information between networks.

Multicast is a vital technology for 2110 media production, so Robert looks at its incarnation at both layer 2 and layer 3. With layer 2, multicast is handled using multicast MAC addresses. It works well with snooping and a querier except when it comes to scaling up to a large network or when using a number of switches. Robert explains that this because all multicast traffic needs to be sent through the rendez-vous point. If you would like more detail on this, check out Arista’s Gerard Phillips’ talk on network architecture.

Looking at JT-NM TR-1001, the guidelines outlining the best practices for deploying 2110 and associated technologies, Robert explains that multicast routing at layer 3 works much increases stability, enables resiliency and scalability. He also takes a close look at the difference between ‘all source’ multicasting supported by IGMP version 2 and the ability to filter for only specific sources using IGMP version 3.

Finishing off, Robert talks about the difficulties in scaling PTP since all the replies/requests go into the same multicast group which means that as the network scales, so does the traffic on that multicast group. This can be a problem for lower-end gear which needs to process and reject a lot of traffic.

Watch now!
Speaker

Robert Welch Robert Welch
Technical Solutions Lead
Arista Networks

Video: Case Study – ST 2110 4K OB Van for AMV

Systems based on SMPTE ST 2110 continue to come online throughout the year and, as they do, it’s worth seeing the choices they made to make it happen. We recently featured a project building two OB truck and how they worked around COVID 19 to deliver them. Today we’re looking at an OB truck based on Grass Valley and Cisco equipment.

Anup Mehta and Rahul Parameswaran from Cisco join the VSF’s Wes Simpson to explain their approach to getting ST 2110 working to deliver a scalable truck for All Mobile Video. This brief was to deliver a truck based on NMOS control, maximal COTS equipment, flexible networking with scalable PTP and security.

Thinking back to yesterday’s talk on Network Architecture we recognise the ‘hub and spoke’ architecture in use which makes a lot of sense in OB trucks. Using monolithic routers is initially tempting for OB trucks, but there is a need for a lot of 1G and 10G ports which tends to use up high-bandwidth ports on core routers quickly. Therefore moving to a monolithic architecture with multiple, directly connected, access switches makes them most sense. As Gerard Philips commented, this is a specialised form of the more general ‘spine-leaf’ architecture which is typically deployed in larger systems.

One argument against using IGMP/PIM routing in larger installations is that those protocols have no understanding of the wider picture. They don’t take a system-wide view like a SDN controller would. If IGMP is a paper roadmap, SDN is satnav with up to date road metrics, full knowledge of width/weight restrictions and live traffic alerts. To address this, Cisco created their own technology Non-Blocking Multicast (NBM) which takes in to account the bandwidth of the streams and works closely with Cisco’s DCNM (Data Centre Network Manager). These Cisco technologies allow more insight into the system as a whole, thus make better decisions.

Anup and Rahul continue to explain how the implementation of PTP was scaled by offloading the processing to line cards than relying on the main CPU of the unit before explaining how the DCNM, not only supporting the NBM feature, also supports GV Orbit. This is the configuration and system management unit from GV. From a security perspective, the network, by default, denies access to any connections into the port plus it has the ability to enforce bandwidth limits to stop accidental flooding or similar.

Watch now!
Speakers

Anup Mehta Anup Mehta
Product Manager,
Cisco
Rahul Parameswaran Rahul Parameswaran
Senior Technical Product Manager,
Cisco

Video: Multicast ABR opens the door to a new DVB era

Multicast ABR (mABR) is a way of delivering standard HTTP-based streams like HLS and DASH over multicast. This can be done using an ISP’s managed network to multicast to thousands of homes and only within the home itself does the stream gets converted into unicast HTTP. This allows devices in the home to access streaming services in exactly the same way as they would Netflix or iPlayer, but avoiding strain on the core network. Streaming is a point-to-point service so each device takes its own stream. If you have 3 devices in the home watching a service, you’ll be sending 3 streams out to them. With mABR, the core network only ever sees one stream to the home and the linear scaling is done internally.

Guillaume Bichot from Broadpeak explains how this would work with a multicast server that picks up the streaming files from a CDN/the internet and converts it into multicast. This then needs a gateway at the other end to convert back into multicast. The gateway can run on a set-top-box in the home, as long as multicast can be carried over the last mile to the box. Alternatively, it can be upstream at a local headend or similar.

At the beginning of the talk, we hear from BBC R&D’s Richard Bradbury who explains the current state of the work. Published as DVB Bluebook A176, this is currently written to account for live streaming, but will be extended in the future to deal with video on demand. The gateway is able to respond with a standard HTTP redirect if it becomes overloaded which seamlessly pushes the player’s request directly to the relevant CDN endpoint.

DVB also outlines how players can contact the CDN for missing data or video streams that are not provided, currently, via the gateway. Guillaume outlines which parts of the ecosystem are specified and which are not. For instance, the function of the server is explained but not how it achieves this. He then shows where all this fits into the network stack and highlights that this is protocol-agnostic as far as delivery of media. Whilst they have used DVB-DASH as their assumed target, this could as easily work with HLS or other formats.

Guillaume finishes by showing deployment examples. We see that this can work with uni-directional satellite feeds with a return channel over the internet. It can also work with multiple gateways accessible to a single consumer.

The webinar ends with questions though, during the webinar, Richard Bradbury was answering questions on the chat. DVB has provided a transcript of these questions.

Watch now!
Download the slides from this presentation
Speakers

Richard Bradbury Richard Bradbury
Lead Research Engineer,
BBC R&D
Guillaume Bichot Guillaume Bichot
Principal Engineer, Head of Exploration,
Broadpeak