[Bug 24863] Per-track metadata for video and audio tracks

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

Silvia Pfeiffer <silviapfeiffer1@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |silviapfeiffer1@gmail.com

--- Comment #2 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to Jon Piesing (HbbTV) from comment #0)
> This issue is raised on behalf of HbbTV - see http://www.hbbtv.org, an
> organisation specifying the use of web technologies in television receivers.
> HbbTV is in the process of adding the HTML5 video element to its
> specification. The current HbbTV specification uses the <object> element for
> presenting video in an HTML page.
> 
> The HbbTV specification based on the object element provides much richer set
> of information about videotracks and audiotracks than is found in HTML5. As
> well as kind, language and id that are in HTML5, some examples that are not
> included in HTML 5 include the following;
> - encoding (e.g. AVC vs HEVC or HE-AAC vs Dolby vs DTS)
> - number of audio channels (stereo vs 5.1 vs 7.1)
> - whether the track is encrypted

If a Web developer needs such information about files, they can always add them
to a list that they provide to the app (e.g. a JSON list of file name and these
properties). Then, once the Web page is loaded on the client, they can check
what the browser supports and pick the right file (e.g. what codecs via
canPlayType(), and the Encrypted Media Extension via MediaKeys, see e.g.
http://www.html5rocks.com/en/tutorials/eme/basics/).


> Apps may use this information to decide what tracks to present. This is
> particularly critical for content streamed via MPEG DASH or pushed via the
> broadcast. In both cases the content provider may offer multiple video and
> audio tracks which have identical "kind" and "language" and differ only one
> of the above.

If you're using DASH, the developer has to download the DASH manifest file
first and gets all the information about encryption, number of channels,
encoding, kind, id and language out of the manifest file. They can then make a
decision which file to give to the UA to decode.

Note, however, that this doesn't mean that the UA will be able to decode that
file, since different UAs support different formats. The developer will have to
use the canPlayType() function to find out what the UA supports:
http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#dom-navigator-canplaytype


> We have considered using the HTML5 extensions mechanisms to add properties
> to VideoTrack and AudioTrack but this is not popular among our members for a
> variety of reasons. 

Agreed. I am not convinced there is a need for an extension yet.


> We would prefer to avoid having to explain to content providers that the
> video element can only be used for the simplest use-cases involving MPEG
> DASH and content pushed via the broadcast channel and that otherwise they
> must use the object element as defined in our current specification.

Does what I explained above satisfy your use case?

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

Received on Monday, 10 March 2014 07:23:12 UTC