Re: Preparation of MSE Proposed Recommendation

Inline:
tl;dr: For MSE, I've landed a bunch of spec changes, and will work on #99,
#124, and #104 next; then w-p-t work. Philippe's registry spec issue
(MSE#74) and MSE test results readiness for PR query from Paul are pending
Philippe.


On Fri, Aug 5, 2016 at 5:33 PM, Paul Cotton <Paul.Cotton@microsoft.com>
wrote:
...

> 1. At Risk Features
>
> > The appendStream feature is covered by ISSUE-14 [2].
>
I removed appendStream from MSEv1 today:
https://github.com/w3c/media-source/pull/139
Note: This assumes CfC for its removal will succeed.

> The VideoPlaybackQuality and totalFrameDelay features are covered by
> ISSUE-69 [3].
>
I removed VPQ+totalFrameDelay from MSEv1 today:
https://github.com/w3c/media-source/pull/135
Note: This assumes CfC for its removal will succeed.

> > The TrackDefault feature is covered by ISSUE-136 [5].
>
I removed TrackDefault from MSEv1 today:
https://github.com/w3c/media-source/pull/138
Note: This assumes CfC for its removal will succeed.


> 2. Remaining V1Editorial issues
>
> Matt: Since we have seen no movement on the HTML 5.1 issue that is
> blocking MSE ISSUE-99, do we have a work around we can use WITHOUT any HTML
> 5.1 change?
>
> https://github.com/w3c/media-source/issues/99
>
> https://github.com/w3c/html/issues/550
>
I'll craft an MSE fix for #99 and try to land it tomorrow. It will follow
the path laid out in #99 comments, so though I'm less comfortable lacking
review from Jerry and Mark for it before landing it, I'm somewhat confident
it will stick.

> Mark: When are we going to finish the WebIDL work?
>
> Matt and David: Given that Mark and Jerry are on vacation this coming
> week, can you take care of this so it does not block us?
>
> https://github.com/w3c/media-source/issues/83
>
I made a copy of Mark's PR, resolved merge conflicts (mostly due to the
at-risk features' removals, above), and landed it today:
https://github.com/w3c/media-source/pull/141

...

> Matt: Can you close out ISSUE-45 using Jerry’s proposed change?
>
> https://github.com/w3c/media-source/issues/45
>
I landed Jerry's fix today: https://github.com/w3c/media-source/pull/134

> 3.  Recent MSE issues with no milestone
>
>
>
> Matt: What do we plan to do with the following recent MSE issues?  Do any
> of these bugs block us from proceeding to PR?
>
> https://github.com/w3c/media-source/issues/137
>
I believe this is VNext. I've marked it as such last week and haven't heard
otherwise.

> https://github.com/w3c/media-source/issues/124
>
I'm not totally sure yet if this is something blocking PR, but I'm fairly
sure it doesn't. At worst, it seems like documented, defined behavior that
might seem weird to apps, but I think would still be interoperable. It
comes down to whether or not implementations decide that "can" or "cannot"
handle rendering of partial audio/video coded frames. I'll take a look
tomorrow after #99.

> https://github.com/w3c/media-source/issues/110
>
I closed this today. It was really pointing out where Chrome and Edge are a
little too lenient w.r.t. the ISOBMFF bytestream spec's definition of an
initialization segment (requiring an ftyp box prior to the moov box).
Chrome has an implementation bug to become more strict about this:
http://crbug.com/504514
Paul: If we need to relax this particular piece of a bytestream spec, can
that be done out-of-band of MSE v1?

> https://github.com/w3c/media-source/issues/104
>
I'll look further tomorrow, but IIUC, we are already "asynchronously"
attaching, since the resource selection algorithm (triggered by setting
src= MSE object URL) runs the MSE attachment steps in parallel after
awaiting a stable state. Though @foolip mentions that "parallel" wording is
weird, it's in HTMLMediaElement. Perhaps only a non-normative note in MSE
might help folks understand what's going on here. I'll investigate tomorrow
(after #99 and #124). Mark agreed already this is purely editorial, so I've
relabeled it today as such.

>  4. MSE Testing results
>
>
>
> Philippe: Can you summarize our current MSE testing status?  Do we have
> enough evidence to proceed to PR?  What if anything do we need to do about
> Jean-Yves Avenard private email about MSE test results?
>
> https://lists.w3.org/Archives/Team/team-html-chairs/2016Aug/0001.html
>
Philippe: please respond :)
I have multiple w-p-t PRs to review and merge. I believe @tidoust's
contributions form a large part of them.
Note that the PTS vs DTS issue reported by Firefox, in Chrome and Edge are
specific to ISOBMFF and not the webm bytestream. If we get >2 interop on
the latter, I'm confident at least Chrome will eventually fix the PTS vs
DTS issues it has with ISOBMFF.

> 5. MSE Registry
>
> Philippe:  Can you give an exact schedule for completing the EME and MSE
> Registry work?
>
> https://github.com/w3c/media-source/issues/74
>
> which depends on
>
> https://github.com/w3c/encrypted-media/issues/104
>
> https://github.com/w3c/encrypted-media/pull/213
>
>
>
> /paulc
>
>
>
> *From:* Paul Cotton [mailto:Paul.Cotton@microsoft.com]
> *Sent:* Wednesday, August 3, 2016 6:40 PM
> *To:* 'public-html-media@w3.org' <public-html-media@w3.org>
> *Subject:* CfC: Handling of MSE Candidate Recommendation "at risk"
> features
>
>
>
> The HTML Media Extensions WG is issuing a Call for Consensus to determine
> how to handle the "at risk" features published in the most recent MSE
> Candidate Recommendation [1].
>
> This CfC proposes to remove ALL of the "at risk" features identified in
> [1] and they will NOT appear in the upcoming candidate Proposed
> Recommendation.
>
>         The following features are at risk and may be removed:
>
>                 . The appendStream method on the sourceBuffer object and
> algorithm steps that are used only by it.
>
>                 . The VideoPlaybackQuality object and the HTMLVideoElement
> Extensions that use it.
>
>                 . The totalFrameDelay attribute on the
> VideoPlaybackQuality object.
>
>                 . The TrackDefault object and its related objects,
> attributes, methods and algorithms, including: TrackDefaultList,
> SourceBuffer.trackDefaults, Default track language, Default track label,
> and Default track kinds.
>
> The appendStream feature is covered by ISSUE-14 [2].  The current CR text
> will be maintained in MSE VNext for further work and to await
> implementations of the Streams API and the associated parts of MSE.
>
>
>
> The VideoPlaybackQuality and totalFrameDelay features are covered by
> ISSUE-69 [3].  The current CR text will NOT appear in the initial MSE VNext
> and will be worked on in the Web Incubator Community Group [4].
>
>
>
> The TrackDefault feature is covered by ISSUE-136 [5].  The current CR text
> will be maintained in MSE VNext for further work and to await MSE
> implementations of this feature.
>
>
>
> Silence will be taken to mean there is no objection, but positive
> responses are encouraged.  If there are no objections by Wednesday Aug 10,
> this resolution will carry and we will proceed with the removal of the
> identified at risk features as we prepare the MSE Proposed Recommendation.
>
> /paulc
> HTML Media Extensions WG Chair
>
> [1] http://www.w3.org/TR/2016/CR-media-source-20160705/
>
> [2] https://github.com/w3c/media-source/issues/14
>
> [3] https://github.com/w3c/media-source/issues/69
>
> [4] https://wicg.github.io/media-playback-quality/
>
> [5]  https://github.com/w3c/media-source/issues/136
>
>
>
> Paul Cotton, Microsoft Canada
>
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
>
> Tel: (425) 705-9596 Fax: (425) 936-7329
>
>
>