RE: [MSE] transport stream constraints vs Apple's HLS

A couple of thoughts:

* Please file concrete bugs for the changes you think we need to make. We should discuss all such bugs.

* Our goal was to keep the first version of MSE simple but useful. We should prioritise any bugs that you think fundamentally are incompatible with something more general over those that are about missing functionality that could be added later.

-----Original Message-----
From: Kevin Streeter [mailto:kstreete@adobe.com] 
Sent: Thursday, February 7, 2013 3:15 PM
To: David Singer; Aaron Colwell
Cc: Adrian Bateman; Michael Thornburgh; public-html-media@w3.org; Bob Lund
Subject: RE: [MSE] transport stream constraints vs Apple's HLS

I would like to add that there is an important distinction between the byte stream format recommendations made in the MSE spec and the *capabilities* provided by the MSE APIs.  

We may choose to constrain the transport stream requirements in the MSE spec to something simpler than HLS in order to promote interoperability, but that won't stop a UA from implementing support for any HLS content.  The UA may even choose to implement entirely new byte stream formats.

On the other hand, limitations in the API will make it difficult for an application writer to access those additional UA capabilities.

Even if we choose not to remove all the constraints on the transport stream format, I feel we should try to avoid baking assumptions into the API that would prevent HLS from being supported more completely.  We can't predict all the possible bytes stream formats that a UA may choose to implement, but HLS is a concrete example of a popular protocol that can't be implemented with the MSE API as it is currently written.

-K

-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: Tuesday, February 05, 2013 3:39 PM
To: Aaron Colwell
Cc: Adrian Bateman; Michael Thornburgh; public-html-media@w3.org; Bob Lund
Subject: Re: [MSE] transport stream constraints vs Apple's HLS

I think it's worth saying that one of the main motivations to support MPEG-2 Transport Streams at all is to be able to take stuff 'as is' from environments that use them, and re-purpose it.  That argues for the minimum number of restrictions.  If people are going to be asked to transcode, then a change of format might also be possible (though 'using existing tooling' also comes into play).

It's one of the reasons that HLS uses transport streams, I think.

So, having the possibility of using essentially unconstrained TSs -- possibly with consequences that can be averted by adopting constraints -- makes sense.

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Friday, 8 February 2013 20:50:13 UTC