[me-media-timed-events] mav Media Timed Events comments (#29)

mavgit has just created a new issue for https://github.com/w3c/me-media-timed-events:

== mav Media Timed Events comments ==
All document:
- Uses both "MPEG DASH" & "MPEG-DASH". Suggest using one or other consistently.

ReSpec Headers:
- [`editors`](https://github.com/w3c/respec/wiki/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`](https://github.com/w3c/respec/wiki/github) option and remove the duplicate [`otherLinks`](https://github.com/w3c/respec/wiki/otherLinks) option.
- Version history from [`otherLinks`](https://github.com/w3c/respec/wiki/otherLinks) should be deleted. It's already in the standard ReSpec [`github`](https://github.com/w3c/respec/wiki/github) option.

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](https://github.com/w3c/respec/wiki/ReSpec-Editor's-Guide#definitions-and-linking) 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](https://en.wikipedia.org/wiki/Interactive_television) (e.g. [BBC Red Button](https://en.wikipedia.org/wiki/BBC_Red_Button), [American idol voting](https://en.wikipedia.org/wiki/American_Idol#Audience_voting), [EBIF](https://en.wikipedia.org/wiki/Enhanced_TV_Binary_Interchange_Format), etc.) 
b. ad insertion (e.g. [SCTE 35](https://www.scte.org/SCTEDocs/Standards/SCTE%2035%202017.pdf)).
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](https://en.wikipedia.org/wiki/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](https://cta.tech/cta/media/EventImages/TechStandards/CTA-5001-Final_v2_pdf.pdf).
- 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.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.3 DASH Industry Forum APIs for Interactivity
- 3rd paragraph: "inband" -> "in-band", as defined in 2. Terminology.

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
- Add [SCTE35] (It's in SpecRef.)

Please view or discuss this issue at https://github.com/w3c/me-media-timed-events/issues/29 using your GitHub account

Received on Thursday, 20 December 2018 00:09:37 UTC