Video

Video: Quantitative Evaluation and Attribute of Overall Brightness in a HDR World

Posted on by Russell Trafford-Jones

HDR has long being heralded as a highly compelling and effective technology as high dynamic range can improve video of any resolution and much better mimics the natural world. HDR continues its relatively slow growth into real-world use, but continues to show progress.

HDR is so compelling because it can feed our senses more light and it’s no secret that TV shops know we like nice, bright pictures on our TV sets. But the reality of production in HDR is that you have to contend with human eyes which have a great ability to see dark and bright images – but not at the same time. The total ability of the eye to simultaneously distinguish brightness is about 12 stops, which is only two thirds of its non-simultaneous total range.
 

 
The fact that our eyes constantly adapt and, let’s face it, interpret what they see, makes understanding brightness in videos tricky. There are dependencies on overall brightness of a picture at any one moment, the previous recent brightness, the brightness of local adjacent parts of the image, the ambient background and much more to consider.

Selios Ploumis steps into this world of varying brightness to creat a ways of quantitatively evaluating brightness for HDR. The starting place is the Average Picture Level (APL) which is what the SDR world uses to indicate brightness. With the greater dynamic range in HDR and the way this is implemented, it’s not clear that APL is up to the job.

Stelios explains his work in analysing APL in SDR and HDR and shows the times that simply taking the average of a picture can trick you into seeing two images as practically the same, whereas the brain clearly sees one as more ‘bright’ than the other. On the same track, he also explains ways in which we can work to differentiate signals better, for instance taking in to account the spread of the brightness values as opposed to APL’s normalised average of all pixels’ values.

The talk wraps up with a description of how the testing was carried out and a summary of the proposals to improve the quantitive analysis of HDR video.

Watch now!
Speakers

Stelios Ploumis Stelios Ploumis
PhD Research Candidate
MTT Innovation Inc.

Video: Avoiding Traps and Pitfalls When Designing SMPTE 2059-2 Networks

Posted on by Russell Trafford-Jones

As the industry gains more and more experience in implementing PTP, AKA SMPTE 2059-2, timing systems it’s natural to share the experiences so we can all find the best way to get the job done.

Thomas Kernen is a staff architect at Mellanox with plenty of experience under his belt regarding PTP so he’s come to the IP Showcase at IBC 2019 to explain.

The talk starts by discussing what good timing actually is and acknowledging everyone’s enthusiasm going into a project for a well designed, fully functioning system. But, importantly, Thomas then looks at a number of real-world restrictions that come into projects which compromise our ability to deliver a perfect system.

Next Thomas looks at aspects of a timing strategy to be careful of. The timing strategy outlines how the timing of your system is going to work, whether that is message rates or managing hierarchy amongst many other possibilities.

The network design itself, of course, has an important impact on your system. This starts at the basics of whether you build a network which is, itself, PTP aware. In general, Thomas says, it should be PTP aware. However, for smaller networks, it may be practical to use without.

Security gets examined next, talking about using encrypted transports, access control lists, ensuring protect interfaces etc. with the aim of preventing unintended access, removing the ability to access physically – much of this is standard IT security, but it’s so often ignored that it’s important to point it out.

PTP is a system, it’s not a signal like B&B so monitoring is important. How will you know the health of your PTP distribution? You need to monitor on the network side, from the point of view of the deices themselves but also analyse the timing signals themselves, for instance, by comparing the timing signals between the main and reserve.

Finally, Thomas warns about designing redundancy systems since “Redundancy in PTP doesn’t exist.” and then finishes with some notes on properly completing a PTP project.

Watch now!

Speaker

Thomas Kernen Thomas Kernen
Staff Architect,
Mellanox Technologies

Video: WAVE (Web Application Video Ecosystem) Update

Posted on by Russell Trafford-Jones

With wide membership including Apple, Comcast, Google, Disney, Bitmovin, Akamai and many others, the WAVE interoperability effort is tackling the difficulties web media encoding, playback and platform issues utilising global standards.

John Simmons from Microsoft takes us through the history of WAVE, looking at the changes in the industry since 2008 and WAVE’s involvement. CMAF represents an important milestone in technology recently which is entwined with WAVE’s activity backed by over 60 major companies.

The WAVE Content Specification is derived from the ISO/IEC standard, “Common media application format (CMAF) for segmented media”. CMAF is the container for the audio, video and other content. It’s not a protocol like DASH, HLS or RTMP, rather it’s more like an MPEG 2 transport stream. CMAF nowadays has a lot of interest in it due to its ability to deliver very low latency streaming of less than 4 seconds, but it’s also important because it represents a standardisation of fMP4 (fragmented MP4) practices.

The idea of standardising on CMAF allows for media profiles to be defined which specify how to encapsulate certain codecs (AV1, HEVC etc.) into the stream. Given it’s a published specification, other vendors will be able to inter-operate. Proof of the value of the WAVE project is the 3 amendments that John mentions issued from MPEG on the CMAF standard which have come directly from WAVE’s work in validating user requirements.

Whilst defining streaming is important in terms of helping in-cloud vendors work together and in allowing broadcasters to more easily build systems, it’s vital the decoder devices are on board too, and much work goes into the decoder-device side of things.

On top of having to deal with encoding and distribution, WAVE also specifies an HTML5 APIs interoperability with the aim of defining baseline web APIs to support media web apps and creating guidelines for media web app developers.

This talk was given at the Seattle Video Tech meetup.

Watch now!
Slides from the presentation
Check out the free CTA specs

Speaker

John Simmons John Simmons
Media Platform Architect,
Microsoft

Video: The Evolution of Video APIs

Posted on by Russell Trafford-Jones

APIs underpin our modern internet and particularly our online streaming services which all. An API is a way for two different programs or services to communicate with each other; allowing access, sharing locations of videos, providing recommendations etc.

Phil Cluff from Mux, takes a look at the evolution of these APIs, showing the simple ones, the complex and how they have changed as time has gone on, culminating in advice to the APIs writers of today and tomorrow.

Security is a big deal and increasingly is in focus for video companies. Whilst the API itself is usually sent over secure means, the service still needs to authenticate users and the use of DRM needs to be considered. Phil talks about this and ultimately the question comes down to what you are trying to protect and your attack surface.

APIs tend to come in two types, explains Phil, Video Platform vs ‘Encoding’ APIs. Encoding APIs a more than pure encoding APIs, there is transcoding, packaging, file transfer and other features built in to most ‘encoding’ services. Video Platform APIs are typically for a whole platform so also include CDN, Analytics, Cataloguing, playback and much more

In terms of advice, Phil explains that APIs can enable ‘normal’ coders – meaning people who aren’t interested specifically in video – to use video in their programs. This can be done through well thought out APIs which make good decisions behind the scenes and use sensible defaults.

API is so important, asserts Phil, that it should be considered as part of the product so treated with similar care. It should be planned, resourced properly, be created as part of a dialogue with customers and, most importantly, revisited later to be upgraded and improved.

Phil finishes the talk with a number of other pieces of advice and answers questions from the floor.

Watch Now!

Speaker

Phil Cluff Phil Cluff
Streaming Specialist,
Mux