Workflows Archives – Page 3 of 17 – The Broadcast Knowledge

Video: Public Internet Transport of Live Broadcast Video – SRT, NDI and RIST for Compressed Video

Posted on 15th April 2021 by Russell Trafford-Jones

Getting video over the internet and around the cloud has well-established solutions, but not only are they continuing to evolve, they are still new to some. This video looks at workflows that are possible teaming up SRT, RIST and NDI by getting a glimpse into projects that have gone live in 2020. We also get a deeper look at RIST’s features with a Q&A.

This video from SMPTE’s New York section starts with Bryan Nelson from Alpha Video who’s been involved in many cloud-based NDI projects many of which also use SRT to get in and out of the cloud. NDI’s a lightly compressed, low-delay codec suitable for production and works well on 1GbE networks. Not dependant on multicast, it’s a technology that lends itself to cloud-based production where it’s found many uses. Bryan looks at a number of workflows that are also enabled by the Sienna production system which can use many video formats including NDI.

For more information on SRT and RIST, have a look at this SMPTE video outlining how they work and the differences. For a deeper dive into NDI, this SMPTE webinar with VizRT explains how its works and also gives demos of the same software that Bryan uses. To get a feel for how NDI fits in with live production compared to SMPTE’s uncompressed ST 2110, this IBC Panel discussion ‘Where can SMPTE ST 2110 and NDI Co-exist’? explores the topic further.

Bryan’s first example is the 2020 NFL draft is first up which used remote contribution on iPhones streaming using SRT. All streams were aggregated in AWS and converted to NDI feeding NDI multiviewers and routed. These were passed down to on-prem NDI processors which used HP ProLiant servers to output as SDI for handoff to other broadcast workflows. The router could be controlled by soft panels but also hardware panels on-prem. Bryan explores an extension to this idea where multiple cloud domains can be used, with NDI being the handoff between them. In one cloud system, VizRT vision mixing and graphics can be added with multiviewers and other outputs being sent via SRT to remote directors, producers etc. Another cloud system could be controlled by a third party with other processing ahead of then being sent to side and being decoded to SDI on-prem. This can be totally separate to acquisition from SDI & NDI with cameras located elsewhere. SRT & NDI become the mediators between this decentralised production environment.

Bryan finishes off by talking about remote NLE monitoring and various types of MCR monitoring. NLE editing is made easy through NDI integration within Adobe Premiere and Avid Media Composer. It’s possible to bring all of these into a processing engine and move them over the public internet for viewing elsewhere via Apple TV or otherwise.

Ciro Noronha from Cobalt Digital takes the last half of the video to talk about RIST. In addition to the talks mentioned above, Ciro recently gave a talk exploring the many RIST use cases. A good written overview of RIST can be found here.

Ciro looks at the two published profiles that form RIST, the simple and main profile. The simple profile defines RTP interoperability with error correction, using re-requested packets with the option of bonding links. Ciro covers its use of RTCP for maintaining the channel and handling the negative acknowledgements (NACKs) which are based on RFC 4585. RIST can bond multiple links or use 2022-7 seamless switching.

The Main profile builds on the simple profile by adding encryption, authentication and tunnelling. Tunnels allow multiple flows down one connection which simplifies firewall configuration, encryption and allows either end to initiate the bi-directional link. The tunnel can also carry non-RIST traffic for any other purpose. The tunnels are FRE over UDP (RFC 8086). DTLS is used for encryption which is almost identical to TLS used to secure websites. DTLS uses certificates meaning you get to authenticate the other end, not just encrypt the data. Alternatively, you can send a password that avoids the need for certificates when that’s not needed or for one-to-many distribution. Ciro concludes by showing that it can work with up to 50% packet loss and answers many questions in the Q&A.

Watch now!
Speakers

	Bryan Nelson Sales Account Executive, Alpha Video
	Ciro Noronha President, RIST Forum Executive Vice President of Engineering, Cobalt Digital

Video: Standardising Microservices on the Basis of MCMA

Posted on 30th March 2021 by Russell Trafford-Jones

Microservices are a way of splitting up large programs and systems into many, many, smaller parts. Building up complex workflows from these single-function modules makes has many benefits including simplifying programming and testing, upgrading your system seamlessly with no downtime, scalability and the ability to run on the cloud. Microservices were featured last week on The Broadcast Knowledge. Microservices do present challenges, such as orchestrating hundreds of processes into a coherent media workflow.

The EBU is working with SMPTE and the Open Services Alliance for Media on a cloud-agnostic open source project called MCMA, Media Cloud Microservice Architecture. The MCMA project isn’t a specification, rather it a set of software providing tools to enable a move to microservices. We hear from Alexandre Rouxel from the EBU and Loïc Barbou from Bloomberg that this project started out of a need from some broadcasters to create a scalable infrastructure that could sit on a variety of cloud infrastructure.

Direct link

What is a service? Created a standard idea of a service that contains standard operations. Part of the project is a set of libraries that work with NodeJS and .net which deal with the code needed time and time again such as logging, handling data repositories, security etc. Joost Rovers explains how the Job Processor and Service Registry work together to orchestrate the media workflows and ensure there’s a list of every microservice available, and how to communicate with it. MCMA places shims in front of cloud services on GCP, AWS, Azure etc in order that each service looks the same. Joost outlines the libraries and modules available for MCMA and how they could be used.

Watch now!
Speakers

	Loïc Barbou Consultant, Bloomberg
	Alexandre Rouxel Data Scientist & Project Coordinator, EBU
	Joost Rovers Managing Director, Rovers IT

Video: Best Practices for End-to-End Workflow and Server-Side Ad Insertion Monitoring

Posted on 26th March 2021 by Russell Trafford-Jones

This video from the Streaming Video Alliance, presented at Mile High Video 2020 looks at the result of recent projects document the best practice for two important activities: server-side ad insertion (SSAI) and end-to-end (E2E) workflow monitoring. First off, is E2E monitoring which defines a multi-faceted approach to making sure you’re delivering good-quality content well.

The this part of the talk is given by Christopher Kulbakas who introduces us to the document published by the Streaming Video Alliance covering monitoring best practices. The advice surrounds three principles: Creating a framework, deciding on metrics, and correlation. Christopher explains the importance of monitoring video quality after a transcode or encode since it’s easy to take a sea of green from your transport layer to indicate that viewers are happy. If your encode looks bad, viewers won’t be happy just because the DASH segments were delivered impeccably.

The guidance helps your monitor your workflow. ‘End to end’ doesn’t imply the whole delivery chain, only how to ensure the part you are responsible for is adequately monitored.

Christopher unveils the principles behind the modular monitoring across the workflow and tech stack:
1) Establish monitoring scope
Clearly delineate your responsibility from that of other parties. Define exactly how and to what standard data will be handled between the parties.

2) Partition workflow with monitoring points
Now your scope is clear, you can select monitoring points before and after key components such as the transcoder.

3) Decompose tech stage
Here, think of each point in the workflow to be monitored as a single point in a stack of technology. There will be content needing a perceptual quality monitor, Quality of Service (QoS) and auxiliary layers such as player events, logs and APIs which can be monitored.

4) Describe Methodology
This stage calls for documenting the what, where, how and why of your choices, for instance explaining that you would like to check the manifest and chunks on the output of the packager. You’d do this with HTTP-GET requests for the manifest and chunks for all rungs of the ladder. After you have finished, you will have a whole set of reasoned monitoring points which you can document and also share with third parties.

5) Correlate results
The last stage is bringing together this data, typically by using an asset identifier. This way, all alarms for an asset can be grouped together and understood as a whole workflow.

End-to-End Server-Side Ad Monitoring

The last part of this talk is from Mourad Kioumgi from Sky who walks us through a common scenario and how to avoid it. An Ad Buyer complains their ad didn’t make it to air. Talking to every point in the chain, everyone checks their own logs and says that their function was working, from the schedulers to the broadcast team inserting the SCTE markers. The reality is that if you can’t get to the bottom of this, you’ll lose money as you lose business and give refunds.

The Streaming Video Alliance considered how to address this through better monitoring and are creating a blueprint and architecture to monitor SSAI systems.

Mourad outlines these possible issues that can be found in SSAI systems:
1) Duration of content is different to the ad duration.
2) Chunks/manifest are not available or poorly hosted
3) The SCTE marker fails to reach downstream systems
4) Ad campaigns are not fulfilled despite being scheduled
5) Ad splicing components fail to create personalised manifests
6) Over-compression of the advert.

Problems 2,3, 5 and 6 are able to be caught by the monitoring proposed which revolves around adding the Creative ID and AdID into the manifest file. This way, problems can be correlated which particularly improves the telemetry back from the player which can deliver a problem report and specify which asset was affected. Other monitoring probes are added to monitor the manifests and automatic audio and video quality metrics. Sky successfully implemented this as a proof of concept with two vendors working together resulting in a much better overview of their system.

Mourad finishes his talk looking at the future creating an ad monitoring framework to distribute an agreed framework document for. best practices.

Watch now!
Speakers

	Christopher Kulbakas Project Lead, Senior Systems Designer, Media Technology & infrastructure, CBC/Radio Canada
	Mourad Kioumgi VOD Solutions Architect. Sky

Video: A Broadcasters Guide To Microservices

Posted on 22nd March 2021 by Russell Trafford-Jones

Promising to simplify programming, improve resilience and redundancy, Microservices have been moving into the media and broadcast space for several years now adopted by names such as EVS and Imagine Communications as well as being the focus of a joint project between SMPTE, EBU and Open Services Alliance. This video explains what microservices are and why they can work well for media & entertainment.

In this video from nxtedition, Roger Persson introduces colleagues Robert Nagy and Jesper Ek to answer questions on microservices. Microservices are individual, independent programs that talk together to create a whole system. They stand in contrast to monolithic programs which have many functions in one piece of software. Splitting each function of a program into its own microservice is similar, but better than modularising a monolithic program since you can run any number of microservices on any hardware leaving you able to create a dynamic and scalable program across many servers and even locations.

Jesper explains that microservices are a type of modular software design, but with the lines between the modules better defined. The benefit comes from the simplicity of microservices. Modules can still be complex but microservices are small and simple having only one function. This makes testing microservices as part of the development workflow simpler and when it comes to extending software, the work is easier. Using microservices does require a well-organised development department, but with that organisation comes many benefits for the company. One thing to watch out for, though, is that although microservices themselves are simple, the more you have, the more complex your system is. Complex systems require careful planning no matter how they are implemented. The idea, though, is that that’s made all the easier due to the modular approach of microservices.

With so many small services being spawned, finishing and being respawned, Roger asks whether an orchestration layer is necessary. Robert agrees this is for the best, but points out that their approach to an orchestration can take many forms from ‘schedulers’ such as Docker Swarm or Kubernetes which take your instruction on which microservices are needed on which hardware with which properties. Up to more complex options which abstract the workflow from the management of the microservices itself. This can work in real-time ensuring that the correct microservices are created for the workflow options being requested.

The ease of managing a live microservice-based system is explored next. Each part is so small, and will typically be running several times, that services can be updated while they are live with no impact to the service running. You can bring up a new version of the microservice and once that is running kill off the old ones either naturally as part of the workflow (in general services will never run more than 15 minutes before being closed) or explicitly. Failover, similarly, can work simply by seeing a hardware failure and spawning new services on another server.

Because of this indifference to the underlying hardware, Microservices can be spun up anywhere whether on-premise or in-cloud. Cloud-only services are certainly an option, but many companies do find that low-latency, high-bandwidth operations are still best done on-premise close to the source of the video. The cloud can be used to offload peaks or for storage.

As ever, there’s no one solution that fits everyone. The use of microservices is a good option and should be considered by vendors creating software. For customers, typically other aspects of the solution will be more important than the microservice approach, but deal-breaking features may be made possible or improved by the vendor’s choice to use microservices.

Watch now!
Speakers