W3C home > Mailing lists > Public > public-html-media@w3.org > February 2013

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

From: Kevin Streeter <kstreete@adobe.com>
Date: Thu, 7 Feb 2013 15:14:59 -0800
To: David Singer <singer@apple.com>, Aaron Colwell <acolwell@google.com>
CC: Adrian Bateman <adrianba@microsoft.com>, Michael Thornburgh <mthornbu@adobe.com>, "public-html-media@w3.org" <public-html-media@w3.org>, Bob Lund <b.lund@cablelabs.com>
Message-ID: <0FEA137C08A9DF4781EEF745038C96944222215333@nambx03.corp.adobe.com>
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.


-----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 Thursday, 7 February 2013 23:15:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:32 UTC