<kaz> scribenick: kaz

cpn: CTA WAVE is one of the most significant projects in the media industry at the moment,
... so I wanted to invite somebody from CTA WAVE and share information on the recent work,
... standards publications, and collaboration with W3C.
... So invited John Simmons and Mark Vickers to present to us the media content spec and HTML5 environment spec developed by the CTA WAVE project.
... I put both topics in the agenda, but I'm not sure we can cover both in the time we have.
... So I suggest we concentrate on the content side today, and we can follow up with the HTML5 spec next month.
... Could you please introduce yourself, John?

johnsim: I have some slides to share.
... https://www.w3.org/2011/webtv/wiki/images/c/c6/WAVE-CMAF_-_Draft_A.pdf

<cpn> scribenick: cpn

johnsim: I oversee the commercial media planning in Windows, in Azure, customer focused groups, also standards groups.
... In WAVE, I'm the chair of the web content spec task force.
... We just published a 2018 draft of the content spec recently.
... If we have time, we could also talk about the HTML5 work, as these go hand in hand.
... I'll give an overview of WAVE, then CMAF, and then the contents of the WAVE content spec, published at NAB.

The CTA WAVE project

johnsim: The WAVE project uses global standards, and is not developing new standards, similar to DASH-IF.
... It's defining interop points between existing standards.
... We're basing our work on CMAF, which DASH-IF is also busy accommodating today, as well as the W3C collaboration on HTML5.
... Everyone here understands the interop issues we have, many different formats.
... Content producers have demands on what needs to be supported on devices.
... A common collection of media formats, CMAF media profiles, cost efficiency, CDNs.
... Issues with uniformity of device playback, so there's a device capability task force,
... e.g., how splice conditioning is handled.
... There's the issue of a common platform for media playback, most of us believe is HTML5, but lack of uniformity in browsers.
... They're not evergreen. We've made great strides with MSE and EME, but there are still some missing capabilities for greater common functionality across media platforms.
... WAVE addresses global interop issues, targets desktop and embedded devices,
... also non-HTML5 devices, but we don't have test cases for those.
... They can use our specs to define the functionality, but we have no way to verify them.
... HTML5 is our reference platform. We also have developer guideines.
... Organisationally, there's a steering committee and 3 task forces: content spec, device playback capabilitites, HTML5 API.
... Regarding membership, I'd say there's not enough from Europe and Asia. The BBC has been very active driving the content spec, also Sky has been there since day one.
... The HTML5 spec available from CTA and W3C, but the content spec only from CTA.
... There are some pending specifications, including event messaging, although not time yet to do them.

CMAF

johnsim: CMAF is the container for audio and video content.
... This can cause some confusion, CMAF not a new presentation format, like DASH or HLS.
... It codifies best practices.
... Primarily, if you're producing DASH content, it's probably very close to being CMAF compliant.
... It's important because a sizeable part of the market supports HLS. CMAF is a flavour that DASH and HLS both support.
... It's a published ISO/IEC spec (not free).
... Where did CMAF come from? An 18-month Microsoft and Apple co-development,
... cross platform, proposed in 2015. We had one-on-one meetings with lots of companies,
... and requirements were submitted by those companies.
... It was done last summer, then went through the ISO process, which is fairly slow.
... By the time we completed the process, it was established as a live linear format. We think it's the appropriate encoding format for media distribution on the web.
... The object model has a box structure, the chunk model enables low latency.
... You can have multiple chunks, so the content is delivered with lower latency.
... DASH-IF is discussing how to use the chunk delivery model to reduce latency to a couple of seconds.
... Sub-second latency needs something fancier.
... Regarding HLS/DASH interop, Apple announced support, you can have same content in HLS with a m3u8 manifest pointing to the same encrypted media content, provides better edge cache efficiency.
... We're focused not only on the encoding standards for interop, also the HTML5 reference platform for devices.

WAVE Content Spec

johnsim: The content spec is derived from the CMAF spec, extended with non-MPEG media profiles.
... CMAF defines media profiles, a binding of video, audio codecs and captions, how they're encapsulated in the container.
... CMAF only defines MPEG specific profiles, but it also defines how to extend bindings to non-MPEG codecs, eg ETSI (Dolby codecs), and AoM (AV1).
... The ability to reference CMAF profiles from MPEG and those published elsewhere in one spec provides one of the pieces needed for interop on the encoding side.
... We went through a process to decide which profiles are important enough to include, spent a year to agree based on our criteria.
... We came up with a scheme to define what goes into the spec.
... These are video profiles in the 2018 public spec.
... There's a wiki that everyone has access to that lists all the profiles, and the criteria.
... There are additional video profiles not listed here that didn't make it into the 2018 spec,
... also audio profiles. Some are published elsewhere, like AC-3 and AC-4 (not published in the CMAF spec),
... some are published at ETSI.
... There's also closed captioning, IMSC-1 (text and image), and WebVTT.
... The reason for choosing IMSC-1 was compatibility with EBU TT-D. We're aiming for global significance for captioning.
... Looking from a DASH perspective, there can be a sequence of WAVE programs,
... but there's an issue around splice constraints between programs.
... When you have a series of presentations, how do you handle the splice points between them?
... We have a splice constraint profile in the content spec that most devices should be able to handle.
... A point evolution for WAVE will be the need more advanced splice points between presentations.
... When that happens, we'll publish another version of the content spec.
... There's the common encryption specs, MSE and EME, and progressive web apps.
... Discussion or questions?

mark: What's happening now with CMAF in MPEG?

johnsim: There is work going on, splice conditioning is a topic at MPEG.
... There was an amendment, adding media profiles from MPEG.
... As a personal opinion, the CMAF work today won't alter its adoption in the industry in the present.
... The work done before submitting to MPEG by Microsoft and Apple and others was quite good, and has been broadly implemented by lots of encoding partners.
... So the work isn't to repair things missing critical to adoption.
... Going back to the list of participants, are there people here involved in DASH-IF?

giri: I get involved in DASH-IF as needed, but in general our companies are involved there, yes.

johnsim: There's an evolving relationship between WAVE and DASH-IF. When CMAF was submitted to MPEG, some conformance software was developed.
... That work was done in association with DASH-IF, for historical reasons.
... WAVE intends to extends that verification software to non-MPEG codecs.
... For those involved in DASH-IF and wondering about WAVE, there's a lot of collaboration, there'll be more shared work.
... I expect DASH-IF to embrace CMAF, and the HTML5 spec to become part and parcel of what DASH-IF is looking at.

giri: W3C's mechanism for streaming is MSE. The formats are defined in the byte stream registry. There are only two.
... Reading those specs, it describes the boxes, which is why we don't have an emsg implementation. Will these specs be updated?

johnsim: I don't know. I'll take an action item to find out.
... The emsg box is important. I don't know if anything else needs to change, though.
... Quite a few companies are doing CMAF with MSE today, so maybe an update isn't needed.
... emsg is a signalling problem. JavaScript players parse and handle emsg themselves. In Windows we can handle them in the OS correctly and fire events that can be handled by applications.
... The problem is that there is no standard way to communicate this in HTML5. There have been previous discussions about DataCue. I've discussed with Safari and Chrome teams but this has not progressed as yet.
... Having the JavaScript application handle it is a mess, typically the event is at the beginning of the chunk. It's much better for the browser/platform to do it.

giri: I don't disagree. But the byte stream registry specs don't mandate it

johnsim: People building the products sometimes ignore the spec.
... But i agree, we need to look at it.

<kaz> scribenick: kaz

cpn: Thanks Giri for this, those were exactly the questions I wanted to ask.
... I also wanted to mention that we have a TF on Media Timed Event within this IG, where emsg is in scope.

<scribe> scribenick: cpn

johnsim: There's some issues around timing that the TF could help answer, e.g, in how/when to invoke the events.

mark: We want to discuss at WICG
... I hope to have the discussion there, and put together a document.

johnsim: WICG sounds right to me, that sounds practical.

<kaz> scribenick: kaz

cpn: The TF will have it's next call on the third Monday, on 18th June.
... I will send an announcement about that to the IG.
... As Mark described, we want to bring the discussion to the WICG.
... There may be other industry groups interested in this topic.

<cpn> scribenick: cpn

johnsim: To be honest, if Chrome were to implement a model for emsg tomorrow, that would become the de-facto standard.
... And that's fine, as long as all voices are heard about what needs to happen.
... We need all the major browsers in the conversation, because otherwise it's just people talking.

cpn: I can reach out to people for the next call?

johnsim: In terms of there being a concerted effort, there needs to be a more formal process. A forum, which should be W3C related, like this IG. Make sure we get the right people.

mark: What was the feeling about the exisitng DataCue API?

johnsim: The feeling was that it needs some work, we can't just enable it and be done.
... I'm not sure there's a consensus that DataCue is the way to go.
... Microsoft already implemented DataCue in Edge, didn't wire up emsg. but we do have emsg for applications (rather than the browser)
... If other browsers all agree on the way to go, we'd do that post-haste.
... It's a worthy collaboration between WAVE and the IG, to tackle this one specific thing.
... And also the byte stream requirements.

<Zakim> nigel, you wanted to ask why extending CMAF is a good idea given that the value of CMAF is that it is a minimal profile

nigel: CMAF exists to simplify the world, but WAVE seems to be extending it. How do these work together?

johnsim: As an example, if I want to use AC-3 audio in a CMAF presentation, someone has to write the spec for how to do the binding.
... It's important for the future to be able to create new bindings, because new codecs show up, such as H.266, AV-2.
... It reduces the multiplicity if the container format is future-proofed.
... This is the intent behind CMAF.

nigel: So the minimum requirements must be met, but you could choose another codec.

johnsim: One thing that's happened, we need a way to report what codecs are supported, i.e., the Media Capabilities API.
... As we're out of time, I'm happy to join again to go into it further.

<kaz> scribenick: kaz

cpn: Thanks!
... There are a few things to follow up here: emsg, and the byte stream registry.
... I will take an action item to capture the byte stream registry question in the IG's GitHub issue tracker
... MTE TF call will be held on June 18th

johnsim: I have conflict at that time, there's a WAVE call

mark: That timeslot on a Monday is problematic as there are occasional WAVE calls.

will: We may be able to rearrange.

cpn: Let's talk about that offline, including Giri as the TF leader
... Thanks for joining, all. Thanks in particular to John for presenting today.

johnsim: My pleasure.

[adjourned]