This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"A user agent recognises and supports data from a MPEG DASH media resource as being equivalent to a HTML track based on the AdaptationSet or ContentComponent mimeType:" It is unclear how many tracks should be created: 1 per AS or 1 per Representation, or 1 per ContentComponent. Also, it is not clear which AS should be exposed ? All including those for which the mime type is not supported? Please rephrase using normative statements such as: "User agents shall expose HTML tracks for all AdaptationSet elements in an MPD. For AdaptationSets for which the MIME type is not supported, it shall expose the associated tracks as HTML TextTracks. For AdaptationSets for which the MIME Type is supported, it shall expose AdaptationSet whose MIME main type is "video" (resp. "audio") as HTML VideoTracks (resp. AudioTracks) and as TextTracks for all others. In a given AdaptationSet, UA shall expose all Representations as an HTML Track. If representations carry multiplexed streams, the UA shall expose each ContentComponent as an HTML Track."
(In reply to Cyril Concolato from comment #0) > "A user agent recognises and supports data from a MPEG DASH media resource > as being equivalent to a HTML track based on the AdaptationSet or > ContentComponent mimeType:" > It is unclear how many tracks should be created: 1 per AS or 1 per > Representation, or 1 per ContentComponent. This same question came up in Bug 26921 [1]. I commented that an HTML track should be created for every AdaptationSet or child ContentComponent. I will create a PR to clarify that. > Also, it is not clear which AS > should be exposed ? All including those for which the mime type is not > supported? Good question. For DASH content played using MSE in HTML, if the UA doesn't support the MIME type of an AS then it wouldn't be able to process initialization segments and no tracks will be created for that resource. It might be worth stating that this should be the case. > > Please rephrase using normative statements such as: > "User agents shall expose HTML tracks for all AdaptationSet elements in an > MPD. For AdaptationSets for which the MIME type is not supported, it shall > expose the associated tracks as HTML TextTracks. For AdaptationSets for > which the MIME Type is supported, it shall expose AdaptationSet whose MIME > main type is "video" (resp. "audio") as HTML VideoTracks (resp. AudioTracks) > and as TextTracks for all others. In a given AdaptationSet, UA shall expose > all Representations as an HTML Track. If representations carry multiplexed > streams, the UA shall expose each ContentComponent as an HTML Track." The Sourcing spec is informative, which is why the statements are not normative. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26921
(In reply to Bob Lund from comment #1) > (In reply to Cyril Concolato from comment #0) > > "A user agent recognises and supports data from a MPEG DASH media resource > > as being equivalent to a HTML track based on the AdaptationSet or > > ContentComponent mimeType:" > > It is unclear how many tracks should be created: 1 per AS or 1 per > > Representation, or 1 per ContentComponent. > > This same question came up in Bug 26921 [1]. I commented that an HTML track > should be created for every AdaptationSet or child ContentComponent. I will > create a PR to clarify that. Let's have that discussion on that bug. > > Also, it is not clear which AS > > should be exposed ? All including those for which the mime type is not > > supported? > > Good question. For DASH content played using MSE in HTML, if the UA doesn't > support the MIME type of an AS then it wouldn't be able to process > initialization segments and no tracks will be created for that resource. It > might be worth stating that this should be the case. Why do you suppose that the tracks will only be created using MSE? With video.addTextTrack() [2] you can create the track for types not supported by MSE. That's what I do in MP4Box.js [3] [2] http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#dom-media-addtexttrack [3] https://github.com/gpac/mp4box.js > > > > > Please rephrase using normative statements such as: > > "User agents shall expose HTML tracks for all AdaptationSet elements in an > > MPD. For AdaptationSets for which the MIME type is not supported, it shall > > expose the associated tracks as HTML TextTracks. For AdaptationSets for > > which the MIME Type is supported, it shall expose AdaptationSet whose MIME > > main type is "video" (resp. "audio") as HTML VideoTracks (resp. AudioTracks) > > and as TextTracks for all others. In a given AdaptationSet, UA shall expose > > all Representations as an HTML Track. If representations carry multiplexed > > streams, the UA shall expose each ContentComponent as an HTML Track." > > The Sourcing spec is informative, which is why the statements are not > normative. 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."
(In reply to Cyril Concolato from comment #2) > (In reply to Bob Lund from comment #1) > > (In reply to Cyril Concolato from comment #0) > > > "A user agent recognises and supports data from a MPEG DASH media resource > > > as being equivalent to a HTML track based on the AdaptationSet or > > > ContentComponent mimeType:" > > > It is unclear how many tracks should be created: 1 per AS or 1 per > > > Representation, or 1 per ContentComponent. > > > > This same question came up in Bug 26921 [1]. I commented that an HTML track > > should be created for every AdaptationSet or child ContentComponent. I will > > create a PR to clarify that. > Let's have that discussion on that bug. OK. Then this bug should be closed and marked as a duplicate of bug 26921. > > > > 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. > > > > Good question. For DASH content played using MSE in HTML, if the UA doesn't > > support the MIME type of an AS then it wouldn't be able to process > > initialization segments and no tracks will be created for that resource. It > > might be worth stating that this should be the case. > Why do you suppose that the tracks will only be created using MSE? With > video.addTextTrack() [2] you can create the track for types not supported by > MSE. That's what I do in MP4Box.js [3] > This bug was about creating tracks from the DASH MPD. Script created tracks is another topic. > [2] > http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#dom-media- > addtexttrack > [3] https://github.com/gpac/mp4box.js > > > > > > > > > Please rephrase using normative statements such as: > > > "User agents shall expose HTML tracks for all AdaptationSet elements in an > > > MPD. For AdaptationSets for which the MIME type is not supported, it shall > > > expose the associated tracks as HTML TextTracks. For AdaptationSets for > > > which the MIME Type is supported, it shall expose AdaptationSet whose MIME > > > main type is "video" (resp. "audio") as HTML VideoTracks (resp. AudioTracks) > > > and as TextTracks for all others. In a given AdaptationSet, UA shall expose > > > all Representations as an HTML Track. If representations carry multiplexed > > > streams, the UA shall expose each ContentComponent as an HTML Track." > > > > The Sourcing spec is informative, which is why the statements are not > > normative. > 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.
(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.
(In reply to Cyril Concolato from comment #4) > (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 would be metadata text tracks. The spec already has language for which AdaptationSet and ContentComponents result in the creation of metadata tracks. As it stands now, the latest version [1] states exactly what constitutes an HTML track based on AS or CC MIME type. We could add a note stating that that the UA does not need to create tracks for audio/video MIME types that it 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. The bug you submitted refers to UA. > 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. > By hand, I assume you mean script. Yes, script can create text tracks. > > > > 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.
(In reply to Bob Lund from comment #5) > (In reply to Cyril Concolato from comment #4) > > (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 would be metadata text tracks. The spec already has language for which > AdaptationSet and ContentComponents result in the creation of metadata > tracks. > > As it stands now, the latest version [1] states exactly what constitutes an > HTML track based on AS or CC MIME type. We could add a note stating that > that the UA does not need to create tracks for audio/video MIME types that > it cannot render. [1] http://rawgit.com/w3c/HTMLSourcingInbandTracks/master/index.html#mpegdash > > > 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. > > The bug you submitted refers to UA. > > > 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. > > > > By hand, I assume you mean script. Yes, script can create text tracks. > > > > > > > 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.
Proposed Pull Request https://github.com/w3c/HTMLSourcingInbandTracks/pull/32
(In reply to Cyril Concolato from comment #7) > Proposed Pull Request > https://github.com/w3c/HTMLSourcingInbandTracks/pull/32 Merged.