Re: JSON metadata cues?

On Sat, Oct 19, 2013 at 8:48 AM, Brendan Long <self@brendanlong.com> wrote:
> I'm looking at implementing the CableLabs "Exposing In-Band Media Container
> Tracks in HTML5" spec,

I'd be careful about implementing that spec. It's unofficial and will
likely be overhauled very soon.

In fact, there is a new Community Group that was just started by a few
people focusing on re-working that spec [1] and re-working the
respective parts in the HTML spec [2]:
http://www.w3.org/community/inbandtracks/ (not sure why those that
started the group have not automatically turned into members).

[1] http://html5.cablelabs.com/tracks/media-container-mapping.html
[2] http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#sourcing-in-band-text-tracks

I suggest you join that CG, which is where the use of TextTrackCue /
DataCue will be discussed, too.
That CG may come back with an extension 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 for MPEG-TS metadata
> and GstToc 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 {
>       readonly attribute DOMString   text; /* JSON */
>       readonly attribute object getCueAsObject(); /* JavaScript object */
> };

Would we need to specify the interface of the object that is returned?
I.e. MPEG2TS returns a specific MPEG2TS object with an expected
structure etc. ?

I am not opposed to creating a JSONCue interface, but we need to
analyse the use case and the consequences properly.
We should come up with an example of how such an interface would be
used by a JS dev.

Cheers,
Silvia.


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

Received on Tuesday, 22 October 2013 23:21:23 UTC