[Bug 26923] [InbandTracks] Number of HTML tracks from DASH

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26923

--- Comment #4 from Cyril Concolato <cyril.concolato@telecom-paristech.fr> ---
(In reply to Bob Lund from comment #3)
> OK. Then this bug should be closed and marked as a duplicate of bug 26921.
Part of this bug is a duplicate. Not all (see below). I don't want to close it.

> > > > Also, it is not clear which AS
> > > > should be exposed ? All including those for which the mime type is not
> > > > supported?
> 
> This question did not get addressed. It seems to make sense that the UA
> should only create audio, video and non-metadata text tracks for media
> streams it can render.
Why would you only expose those tracks? Those tracks will be rendered. I agree
standardization will help for interoperability in the UI. But standardization
is even more important for the other tracks. The tracks that the browser cannot
render. Those are interesting to expose to JS so that JS app do something with
them. That's also mentioned by Silvia in [3]
"Exposing cues to JavaScript enables a Web developer to create all
sorts of interesting presentations around it, such as interactive
transcripts rendered next to the video."
[3] http://lists.w3.org/Archives/Public/public-inbandtracks/2014Sep/0014.html


> This bug was about creating tracks from the DASH MPD. Script created tracks
> is another topic.
I disagree. Scripts can be used to create tracks from the MPD. For the tracks
that are known to be supported, rely on MSE, for others do it by hand.


> > Why? Informative specs are not really useful. It should be normative. UA
> > don't have to implement it, but if they decide to implement it, it should be
> > done in a normative way. The MSE follows that approach for instance, it says:
> > "If an implementation claims to support a MIME type listed in the registry,
> > its SourceBuffer implementation must conform to the byte stream format
> > specification listed in the registry entry."
> 
> Feel free to go down that path.
Fine. Thanks.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 9 October 2014 09:58:19 UTC