W3C home > Mailing lists > Public > public-web-and-tv@w3.org > June 2018

[me] minutes - 5 June 2018

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 11 Jun 2018 14:58:17 +0900
Message-ID: <CAJ8iq9WPuBeJ81=UQwhSuearRKOJUnM9=oF-8o6ERj_Jod1Wgg@mail.gmail.com>
To: public-web-and-tv@w3.org
available at:

also as text below.

Thanks a lot for presenting the slides on CTA WAVE, John!
And thanks a lot for taking the minutes, Chris!




      [1] http://www.w3.org/

                               - DRAFT -

           Media & Entertainment IG monthly call 5 June 2018

05 Jun 2018


          Chris_Needham, John_Simmons, Kaz_Ashimura,
          Masaru_Takechi, Louay_Bassbouss, Giridhar_Mandyam,
          Chris_O'Brien, Mark_Vickers, Nigel_Megitt,
          Peter_Pogrzeba, Will_Law, John_Luther, Tatsuya_Igarashi


          Chris_Needham, Mark_Vickers

          cpn, kaz


     * [2]Topics
         1. [3]The CTA WAVE project
         2. [4]CMAF
         3. [5]WAVE Content Spec
     * [6]Summary of Action Items
     * [7]Summary of Resolutions

   <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.

      [8] 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
   ... 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
   ... 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
   ... 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
   ... 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.


   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
   ... 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
   ... 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
   ... 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
   ... 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
   ... 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

   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
   ... 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

   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
   ... There may be other industry groups interested in this

   <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
   ... Microsoft already implemented DataCue in Edge, didn't wire
   up emsg. but we do have emsg for applications (rather than the
   ... If other browsers all agree on the way to go, we'd do that
   ... 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

   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
   ... 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
   ... 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

   <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
   ... Thanks for joining, all. Thanks in particular to John for
   presenting today.

   johnsim: My pleasure.


Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [9]scribe.perl version
    1.147 ([10]CVS log)
    $Date: 2018/06/08 05:06:44 $

      [9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [10] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 11 June 2018 05:59:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 11 June 2018 05:59:29 UTC