[whatwg] How to handle multitrack media resources in HTML

[Jer Noble]

On Apr 11, 2011, at 5:26 PM, Ian Hickson wrote:

> On Fri, 8 Apr 2011, Jer Noble wrote:
>> 
>> Sorry, by playbackState, I meant readyState.  And I was suggesting that, 
>> much in the same way that you've provided .buffered and .seekable 
>> properties which "expose the intersection of the slaved media elements' 
>> corresponding ranges", that a readyState property could similarly 
>> reflect the readyState values of all the slaved media elements. In this 
>> case, the MediaController's hypothetical readyState wouldn't flip to 
>> HAVE_ENOUGH_DATA until all the constituent media element's ready states 
>> reached at least the same value.
> 
> So basically it would return the lowest possible value amongst the slaved 
> elements? I guess we could expose such a convenience accessor, but what's 
> the use case? It seems easy enough to implement manually in JS, so unless 
> there's a compelling case, I'd be reluctant to add it.

Yes, this would be just a convenience, as I tried to make clear below.  So I don't want to seem like I'm pushing this too hard.  But since you asked...

>> Of course, this would imply that the load events fired by a media 
>> element (e.g. loadedmetadata, canplaythrough) were also fired by the 
>> MediaController, and I would support this change as well.
> 
> I don't see why it would imply that, but certainly we could add events 
> like that to the controller. Again though, what's the use case?

The use case for the events is the same one as for the convenience property: without a convenience event, authors would have to add event listeners to every slave media element.   So by "imply", I simply meant that if the use case for the first was compelling enough to warrant new API, the second would be warranted as well.

Lets say, for example, an author wants to change the color of a play button when the media in a media group all reaches the HAVE_ENOUGH_DATA readyState.

Current API:
	function init() {
		var mediaGroupElements = document.querySelectorAll("*[mediaGroup=group1]");
		for (var i = 0; i < mediaGroupElements.length; ++i)
			mediaGroupElements.item(i).addEventListener('canplaythrough', readyStateChangeListener, false);
	}

	function readyStateChangeListener(e) {
		var mediaGroupElements = document.querySelectorAll("*[mediaGroup=group1]");
		var ready = mediaGroupElements.length > 0;
		for (var i = 0; i < mediaGroupElements.length; ++i)
			if (mediaGroupElements.item(i).readyState < HAVE_ENOUGH_DATA)
				ready = false;
		if (ready)
			changePlayButtonColor();
	}

"Convenience" API:
	function init() {
		var controller = document.querySelector("*[mediaGroup=group1]").controller;
		controller.addEventListener('canplaythrough'), changePlayButtonColor, true;
	}

I think the convenience benefits are pretty obvious.  Maybe not compelling enough, however. :)

>> Again, this would be just a convenience for authors, as this information 
>> is already available in other forms and could be relatively easily 
>> calculated on-the-fly in scripts.  But UAs are likely going to have do 
>> these calculations anyway to support things like autoplay, so adding 
>> explicit support for them in API form would not (imho) be unduly 
>> burdensome.
> 
> Autoplay is handled without having to do these calculations, as far as I 
> can tell. I don't see any reason why the UA would need to do these 
> calculations actually. If there are compelling use cases, though, I'm 
> happy to add such accessors.


Well, how exactly is autoplay handled in a media group?  Does the entire media group start playing when the first media element in a group with it's autoplay attribute set reaches HAVE_ENOUGH_DATA?

-Jer

 Jer Noble <jer.noble at apple.com>