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

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

            Bug ID: 24863
           Summary: Per-track metadata for video and audio tracks
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: hbbtvjon@gmail.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org

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

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. Obviously the 'id' will be different between such tracks but
enabling encoding/channels/encryption to be determined from the 'id' would
likely introduce significant issues in many content providers workflow.

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. 

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.

We would appreciate your feedback on whether there are other ways to expose
this sort of information to apps. At what point in the future HTML5 process
would it become possible to discuss adding additional properties to AudioTrack
and VideoTrack?

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

Received on Friday, 28 February 2014 16:03:51 UTC