- From: Brendan Long <self@brendanlong.com>
- Date: Fri, 18 Oct 2013 15:48:53 -0600
- To: "HTML WG (public-html@w3.org)" <public-html@w3.org>
- Message-ID: <5261ACC5.6080003@brendanlong.com>
I'm looking at implementing the CableLabs "Exposing In-Band Media
Container Tracks in HTML5
<http://html5.cablelabs.com/tracks/media-container-mapping.html>" spec,
and it seems to conflict with the idea behind DataCue*, so I'm wondering
how people would feel about a cue with no .data attribute, and a
getCueAsObject(), returning a JavaScript object.
The reason this would be helpful if that, at least in GStreamer, getting
raw binary data is actually relatively difficult, and we easily have
access to structured data. For example, we have GstMpegTsSection
<http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-libs/html/gst-plugins-bad-libs-Base-MPEG-TS-sections.html>
for MPEG-TS metadata and GstToc
<http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstToc.html>
for the table of contents (which converts nicely to WebVTT already). I
assume other kinds of metadata will also be exposed this way, not as raw
binary streams, like the spec seems to expect.
With structured data, it would be nice if we could just throw it into a
JSON object, like so:
interface JSONCue : TextTrackCue <http://www.w3.org/html/wg/drafts/html/master/single-page.html#texttrackcue> {
readonly attribute DOMString text <http://www.w3.org/html/wg/drafts/html/master/single-page.html#dom-datacue-text>; /* JSON */
readonly attribute object getCueAsObject(); /* JavaScript object */
};
The advantages are:
* It's easier to do with GStreamer.
* It should be easier for JS developers to work with.
* At least in MPEG-TS, tracks aren't easily separated, so providing a
metadata track without parsing it doesn't really make sense. This
may not apply to other formats though.
The disadvantage is:
* It may be harder to create in non-GStreamer media pipelines.
My question is, does this make sense for other implementors, or is this
only easier for GStreamer? We /could/ rebuild the binary format from the
structured data if we needed to, I just want to make sure we're not
doing something unnecessarily complicated if providing structured data
makes more sense for other media pipelines too.
* I realize we could just use DataCue and put JSON in the text and data
fields, but that doesn't seem to be what it was meant for, so I don't
want to do that unless the concensus is that it's "the right thing to do".
--------------060401090504020705020801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I'm looking at implementing the CableLabs "<a
href="http://html5.cablelabs.com/tracks/media-container-mapping.html">Exposing
In-Band Media Container Tracks in HTML5</a>" spec, and it seems to
conflict with the idea behind DataCue*, so I'm wondering how people
would feel about a cue with no .data attribute, and a
getCueAsObject(), returning a JavaScript object.<br>
<br>
The reason this would be helpful if that, at least in GStreamer,
getting raw binary data is actually relatively difficult, and we
easily have access to structured data. For example, we have <a
href="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-libs/html/gst-plugins-bad-libs-Base-MPEG-TS-sections.html">GstMpegTsSection</a>
for MPEG-TS metadata and <a
href="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstToc.html">GstToc</a>
for the table of contents (which converts nicely to WebVTT already).
I assume other kinds of metadata will also be exposed this way, not
as raw binary streams, like the spec seems to expect.<br>
<br>
With structured data, it would be nice if we could just throw it
into a JSON object, like so:<br>
<pre class="idl">interface <dfn>JSON</dfn><dfn id="datacue">Cue</dfn> : <a href="http://www.w3.org/html/wg/drafts/html/master/single-page.html#texttrackcue">TextTrackCue</a> {
readonly attribute DOMString <a href="http://www.w3.org/html/wg/drafts/html/master/single-page.html#dom-datacue-text" title="dom-DataCue-text">text</a>; /* JSON */
readonly attribute object getCueAsObject(); /* JavaScript object */
};</pre>
The advantages are:<br>
<ul>
<li>It's easier to do with GStreamer.</li>
<li>It should be easier for JS developers to work with.</li>
<li>At least in MPEG-TS, tracks aren't easily separated, so
providing a metadata track without parsing it doesn't really
make sense. This may not apply to other formats though.<br>
</li>
</ul>
<p>The disadvantage is:<br>
</p>
<ul>
<li>It may be harder to create in non-GStreamer media pipelines.<br>
</li>
</ul>
My question is, does this make sense for other implementors, or is
this only easier for GStreamer? We <i>could</i> rebuild the binary
format from the structured data if we needed to, I just want to make
sure we're not doing something unnecessarily complicated if
providing structured data makes more sense for other media pipelines
too.<br>
<br>
* I realize we could just use DataCue and put JSON in the text and
data fields, but that doesn't seem to be what it was meant for, so I
don't want to do that unless the concensus is that it's "the right
thing to do".<br>
</body>
</html>
--------------060401090504020705020801--
Received on Friday, 18 October 2013 21:49:30 UTC