Re: [MSE] Resolving Bug 24370

From: Aaron Colwell <acolwell@google.com<mailto:acolwell@google.com>>
Date: Tuesday, April 1, 2014 at 6:17 PM
To: "<public-html-media@w3.org<mailto:public-html-media@w3.org>>" <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: [MSE] Resolving Bug 24370
Resent-From: <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Resent-Date: Tuesday, April 1, 2014 at 6:17 PM

So right now Bug 24370<https://www.w3.org/Bugs/Public/show_bug.cgi?id=24370> is the only bug left against MSE. That bug triggered the creation of Bug 24563<https://www.w3.org/Bugs/Public/show_bug.cgi?id=24563> which has resulted in a spirited discussion. Then about 2 weeks ago I had an IM conversation with Hixie to sort things out and he was still leaning towards not allowing these attributes to become mutable.

Here is a summary of what I believe his concerns are:
1. kind & language changing during playback was never intended to work in HTML5. This being possible in out-of-band tracks was just an artifact of using HTML to specify tracks.
2. Allowing kind & language to change during playback could result in all sorts of added complexity to the HTML5 spec.
3. There don't appear to be compelling use cases to justify the complexity.
4. If the web application is getting the kind & language data from the manifest instead of the media file, then why shouldn't the web application be responsible for selecting appropriate tracks instead of the UA?

After the IM discussion with Hixie, I am starting to wonder myself what people are actually trying to accomplish with the mutable language and track attributes. If you look closely at the HTML5 spec there isn't any existing spec text that talks about what happens if this information changes after readyState transitions to HAVE_METADATA.

I'd like the people who care about this particular feature to answer the following questions so that we can make some progress.

1. What do you expect the UA to do when kind and/or language is changed on a xxxTrack object?
2. Why isn't the language & kind data simply placed in the initialization segments instead of only being in a DASH manifest?
3. Are there real world, compelling examples that require support for language and/or kind to be able to change during playback?

I wouldn’t expect the kind of a specific track to change. I haven’t seen the case where language would change. All the cases with multiple media kinds and languages use multiple tracks, potentially with tracks being added/deleted over time. Each track has non-changing kind/language attributes.


Without any extra information I doubt we'll be able to resolve this issue. Right now, I'm leaning towards removing the mutable definitions since there is no actual UA behavior connected to these attributes changing value.

+1


Aaron