mav Media Timed Events comments

[mavgit]

All document:

• Uses both "MPEG DASH" & "MPEG-DASH" throughout. Suggest using one or other consistently.

Conformance:

• Currently all your references are Normative because ReSpec changed and now ignores [[ vs. [[! and goes by sections instead. I would guess that section 6 Recommendations is supposed to be the only Normative section, correct?
• Mark each informative section like this:

  <section class="informative">

• If the whole doc is meant to be informative, then do the above to the top level section.
• If you are using conformance language in the spec, add the boilerplate conformance section like this:

  <section id="conformance"></section>

• Eliminate any usage of must and should, unless they are meant to be for conformance (e.g. section 6). There are currently 2 musts in 4.4 and 3 musts in section 6. There are currently 7 shoulds before section 6, 7 shoulds in section 6. It's likely some of the shoulds in section 6 are intended to be musts.

ReSpec Headers:

• editors Do you want your email addresses on this? It's often left blank since these can get out of date and invite spam. It's not needed, since people can file GitHub issues.
• There are two "Participate:" sections. Should be just one. Keep the one from the standard ReSpec github option and remove the duplicate otherLinks option.
• Version history from otherLinks should be deleted. It's already in the standard ReSpec github option.
• Remove [SCTE-35] from localBiblio. SpecRef includes [SCTE35].
• Remove [WEBVTT] from localBiblio. SpecRef includes [WEBVTT]
• Other final published specs in localBiblio should be added into SpecRef.

Abstract

• "such as subtitles, captions, or other web content" Subtitles and captions are already supported in HTML5, so these are bad examples to motivate a new API. This document shouldn't mention subtitles or captions. This document should use other compelling examples in the Abstract that are currently unsupported, such as interactive television and ad insertion.

1. Introduction:

   • The Abstract & Introduction aren't in synch. One expects the Abstract to be a short intro and the introduction to be a longer intro. Here it is the opposite - the Abstract is a pretty good summary, but the Introduction is shorter and only defines the term "media timed events". Suggest making Introduction cover at least all of the Abstract.

2. Terminology

   • Suggest using ReSpec <dfn> element for in-band and out-of-band. (e.g. <dfn>in-band</dfn>)
   • The reference for the definition of media timeline should be to [HTML], not [HTML52].
   • Inconsistent commas before "such as": -- no comma: "corresponding to a live broadcast such as a sporting event" vs. -- comma: "accessibility-related assets, such as large print rendering of captions".

3. Use cases

   • My biggest issue with the spec: The use cases are very weak. I think the two biggest use cases are: a. interactive TV (e.g. BBC Red Button, American idol voting, EBIF, etc.) b. ad insertion (e.g. SCTE 35). You should lead with the most widely deployed use cases and end with undeployed use cases, if any. I would start the list with interactive TV and ad insertion (and maybe T-Commerce).

3.1 Audio stream with titles and images

• I like how this starts with what a user wants to do (why) in the first paragraph and then provides technology references (how) in a second paragraph. That's a good structure for a use case. It would be good if all the use cases could do this. Other use cases start with technical references.
• The second sentence is a run-on sentence. Perhaps one sentence for HLS timed metadata and one sentence for RadioVIS?
• This is a good, well-stated use case, but I wouldn't lead with an audio-only use case.

3.2 MPEG DASH manifest expiry notifications

• This is the first usage of emsg in the spec, but emsg isn't defined till section 5. Perhaps change "An in-band emsg event is used..." to "An in-band event called Event Message Box (emsg) is used...".
• It starts with the technical reference and ends with the why (reducing the load on HTTP servers). Suggest a general use case paragraph, then a paragraph with the DASH & emsg specifics, like in 3.1.
• "[MPEGDASH] describes a DASH specific event..." Isn't everything in DASH DASH-specific? Perhaps "[MPEGDASH] describes an event..."
• "...notify a DASH player web application..." Isn't this any DASH player, not just web? Perhaps "...notify a DASH player..."
• Typo: "An in-band emsg event is used an alternative...". Should that be "...used as an alternative..."?
• Run-on sentence: "An in-band emsg even...requests" is hard to understand. Suggest splitting it into two or three sentences. -The "this issue" link in the Editor's Note is a bad reference for this public document because the two links to substantive content are both in a non-public part of the CTA WAVE site. Perhaps replace that link with a link to section 3.2 of the public WAVE Content spec.
• Also, no need for an Editor's Note. This reference should be in the text of the use case.

3.3 Synchronized map animations

• As in 3.2, this use case starts with the tech reference to WebVMT. It should start with a user-oriented use case, then reference WebVMT in a second paragraph on tech references.
• This should be lower on the list if it's not deployed?

3.4 Media analysis visualization

• This should be lower on the list if it's not deployed?
• It needs at least one reference.

3.5 Presentation of auxiliary content in live media

• Never heard of this and I don't fully understand it from the description.
• This should be lower on the list if it's not deployed?
• It needs at least one reference.

4. Related industry standards
   • This needs some explanatory text as to why this collection of standards are related. Is it "The following Industry standards include requirements for media timed events. Any new web API should support all these requirements."?

4.x

• CMAF is missing from this list. It should be the first one included, because it's the most likely driver for getting this feature supported. CMAF section 7.4.5 Event Message Box ('emsg') describes the requirements, modeled on DASH emsg. Also, informative Annex E Event Messages discusses use cases in detail. The SpecRef is [MPEGCMAF].

4.1 MPEG-DASH

• The first paragraph is a run-on sentence which should be broken up. For example, it could be something like:

  In MPEG-DASH, events may be either in-band or out-of band:

  • In-band events are emsg boxes in ISO BMFF files. in-band events may be signaled in the MPD (Media Presentation Description)
  • Out-of-band events are an EventStream fragment in the MPD (i.e., an instance of the EventStream child of the MPD.Period element).

• "...signalled in the DASH manifest document (MPD)..." MPD defined and used above in this section, so perhaps: "...signaled in the MPD...". (Also typo: "signalled" should be "signaled").

4.2 HbbTV

• I don't see the point of the last sentence. Of course emsg doesn't work on Edge. That's what this requirements spec is all about!

4.3 DASH Industry Forum APIs for Interactivity

• 3rd paragraph: "inband" -> "in-band", as defined in 2. Terminology.
• There needs to be a reference for DAInty, DASH APIs for Interactivity.

4.4 BBC Subtitle Guidelines

• I'm not sure why this is included here. Subtitles are already supported in HTML5.

4.6 MPEG Working Draft on Carriage of Web Resources in ISO BMFF

• This doesn't mention the specific media timed events requirements like the other sections do.

4.7 WebVTT

• I'm not sure why this is included here. WebVTT is already supported in HTML5.

5.1.1 DASH and ISO BMFF emsg events

• This should also include CMAF, which also has emsg, in the section title and contents.
• Reference Recommendation HTML 5.2 instead of draft 5.3. HTML 5.2 specifies DataCue in section 44.7.13.11.6 Text tracks exposing in-band metadata
• Is the Editor's Note question "Which of these is preferred?" to be answered in the final spec?

5.1.2 Synchronization and timing

• More is needed than just one sentence. What are the timing guarantees? Why aren't they enough? How do they cause events to be missed? What is the recommended solution?

6.5 6.5 DASH events

• Shouldn't the title be emsg events, to include DASH, CMAF, et. al.

6.6 Synchronization

• "... within time constraints described elsewhere in this report." No! The time constraints need to be explicitly in this requirements section.

A. References

• [WEB-MEDIA-GUIDELINES] Web Media Application Developer Guidelines is now a Final CG Report here: https://www.w3.org/2018/12/webmediaguidelines.html

[chrisn]

I believe we've addressed all your comments, but please re-open if we've missed anything.