- From: Brendan Long <self@brendanlong.com>
- Date: Fri, 18 Oct 2013 19:13:40 -0600
- To: Glenn Adams <glenn@skynav.com>
- CC: "HTML WG (public-html@w3.org)" <public-html@w3.org>
- Message-ID: <5261DCC4.8000708@brendanlong.com>
On 10/18/13 6:14 PM, Glenn Adams wrote:
>
> The advantages are:
>
> * It's easier to do with GStreamer.
>
> No it isn't. There is no requirement to populate /data/.
>
> * It should be easier for JS developers to work with.
>
> Not particularly. See above.
>
>
> * 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.
>
> Of course you have to parse it. DataCue is not expected to contain a
> TS byte stream, a stream of TS packets, a stream of TS sections, etc.
Is that the consensus of the WG? If DataCue is expected to contain
structured data, then why does the binary .data attribute exist? I'm not
opposed to using DataCue for this, but I want to make sure I'm not going
off in a direction that no one else will follow.
> Any implementation that uses DataCue should document the circumstances
> in which it is constructed, what the binary data buffer contains, and
> how the text field, if non null, represents that data.
>
> Implementations would normally used an internal type that effectively
> represents a subclass of DataCue. But this doesn't mean there is a
> need to export a JS version of that subclass when DataCue will do.
>
> 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".
>
>
> Why do you think it wasn't meant for this? That was what it was
> intended to do. Again, implementations that populate a track with
> DataCue instances should document how they are using DataCue in this
> regard.
I'm trying to make sure the format I'm using it acceptable to other
implementers, so I can document it in the one place that matters: The
HTML spec.
--------------010502050808080202010804
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 10/18/13 6:14 PM, Glenn Adams wrote:<br>
<blockquote
cite="mid:CACQ=j+cMZcbhZ9aLyeA=RBvWa_UPTZ-kzNuPSbUtku8fQ6jF+A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">The advantages are:<br>
<ul>
<li>It's easier to do with GStreamer.</li>
</ul>
</div>
</blockquote>
<div>No it isn't. There is no requirement to populate <i>data</i>.</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<ul>
<li>It should be easier for JS developers to work
with.</li>
</ul>
</div>
</blockquote>
<div>Not particularly. See above.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<ul>
<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>
</div>
</blockquote>
<div>Of course you have to parse it. DataCue is not expected
to contain a TS byte stream, a stream of TS packets, a
stream of TS sections, etc.</div>
</div>
</div>
</div>
</blockquote>
Is that the consensus of the WG? If DataCue is expected to contain
structured data, then why does the binary .data attribute exist? I'm
not opposed to using DataCue for this, but I want to make sure I'm
not going off in a direction that no one else will follow.<br>
<br>
<blockquote
cite="mid:CACQ=j+cMZcbhZ9aLyeA=RBvWa_UPTZ-kzNuPSbUtku8fQ6jF+A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Any implementation that uses DataCue should document
the circumstances in which it is constructed, what the
binary data buffer contains, and how the text field, if
non null, represents that data.</div>
<div><br>
</div>
<div>Implementations would normally used an internal type
that effectively represents a subclass of DataCue. But
this doesn't mean there is a need to export a JS version
of that subclass when DataCue will do.</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<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>
</div>
</blockquote>
<div><br>
</div>
<div>Why do you think it wasn't meant for this? That was
what it was intended to do. Again, implementations that
populate a track with DataCue instances should document
how they are using DataCue in this regard.</div>
</div>
</div>
</div>
</blockquote>
I'm trying to make sure the format I'm using it acceptable to other
implementers, so I can document it in the one place that matters:
The HTML spec.<br>
<br>
</body>
</html>
--------------010502050808080202010804--
Received on Saturday, 19 October 2013 01:14:16 UTC