Re: JSON metadata cues?

On Fri, Oct 18, 2013 at 7:13 PM, Brendan Long <self@brendanlong.com> wrote:

>  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?
>

First, I'm speaking for myself here.


> If DataCue is expected to contain structured data, then why does the
> binary .data attribute exist?
>

For generic cues which can be represented as binary using an ArrayBuffer
(or derived type) and for which a text version may or may not be available.


> 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.
>

The purpose of DataCue is to serve as a generic container for metadata
cues. Since every metadata cue can be represented as an ArrayBuffer, there
is no problem in doing so. Whether a text form is exposed is up to the
specific usage of DataCue. Thus my suggestion that any UA that internally
generates DataCues should document their usage.



>
>
>   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.
>

It isn't the only place that matters. The HTML spec makes reference to many
other specifications and further, there is a well defined HTML extension
specification process [1]. I doubt if there would be consensus to include a
specific usage of DataCue that pertains to MPEG-2 in the HTML specification
proper. It would be more appropriate to include in the Cablelabs
specification you referenced [2].

[1] http://www.w3.org/html/wg/wiki/ExtensionSpecifications
[2] http://html5.cablelabs.com/tracks/media-container-mapping.html