W3C home > Mailing lists > Public > public-texttracks@w3.org > April 2012

Fwd: [RFC] WebM temporal metadata

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 10 Apr 2012 13:22:02 +1000
Message-ID: <CAHp8n2mJfJz-f-DsddRP_g-0TQ1dO=Gk+sSh6GOXqm-KLm7NOw@mail.gmail.com>
To: public-texttracks@w3.org
Cc: jzern@google.com
(Forwarding to TextTracks CG at W3C for discussion of including
name-value fields in WebVTT header)

Hi all,

There has been a discussion on the WebM-discuss mailing list about
supporting specific name-value header fields in WebVTT for
kind=metadata tracks. James has a particular use case where he wants
to encapsulate GPS data in JSON format into WebVTT and encapsulate
that into a WebM text track. It is important in this scenario to be
able to find out about the format of the data in the WebM track before
starting to download the full WebM file. I assume this is mostly so
you can start up the correct application / display at the beginning of
receiving a file and attache the right parser.

This brings back the discussion about the support of name-value pairs
in WebVTT headers. We still haven't made a decision as to what format
we expect them to be in, see
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15851 . I'd be happy
with the RFC822 style.

In addition to deciding on the format of the file-wide metadata, we
need to decide what a browser should do with it.

I think we are all pretty much agreed that the browser should in
principle ignore all headers. However, it would be useful to JS
developers to be able to extract those headers and do something with
them.

Therefore, I would propose introduction of an interface function to
the TextTrack object [1] that provides the list of headers:
DOMString getHeader();
In this case, the JS programmer can parse the text into a list of
name-value pairs and determine what to do with it.

Alternatively, this could be improved through introducing a
TextTrackHeader object which is a list of name-value pairs.

Note that such an access function may also provide for the
requirements of bug 13359 [2]

Cheers,
Silvia.


[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#texttrack
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=13359

---------- Forwarded message ----------
From: James Zern <jzern@google.com>
Date: Tue, Apr 10, 2012 at 4:39 AM
Subject: Re: [RFC] WebM temporal metadata
To: webm-discuss@webmproject.org


On Fri, Apr 6, 2012 at 16:41, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> On Sat, Apr 7, 2012 at 3:38 AM, James Zern <jzern@google.com> wrote:
>> On Thu, Apr 5, 2012 at 22:20, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>>> On Fri, Apr 6, 2012 at 3:56 AM, James Zern <jzern@google.com> wrote:
>>>> On Thu, Apr 5, 2012 at 00:51, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>>>>> Hi James,
>>>>>
>>>>> Is there a reason that we need to constrain the metadata format? What
>>>>> is the use case?
>>>>>
>>>> Without something like name=value pairs how are we to determine the
>>>> format of the (mixed) metadata payload? Unless there's an indicator at
>>>> the file level, which would make separate webvtt files a necessity.
>>>> The use case we've been working with is GPS data, how to format that
>>>> will be an open question after this is settled.
>>>
>>> I suppose if somebody wants to make use of the metadata track
>>> possibilities, we will require two things:
>>>
>>> 1. an indication what format a parser will need to expect to be able
>>> to parse out information from the cues
>>> 2. an indication of what data is actually included in the track and
>>> therefore what applications will be able to make any sense of the
>>> included data.
>>>
>>> These are also issues that WebVTT should solve, so it's not just a
>>> matter of WebM.
>>
>> Right, which is why I thought it would be beneficial to start with
>> WebVTT and then translate that into an in-band webm track.
>>
>>> I would expect to solve this through adding fields to
>>> the file-wide metadata that indication what 1 and 2 are.  That means
>>> we really have to get file-wide metadata into the WebVTT spec, see
>>> this bug [1].
>>>
>>> Let's hypothetically assume we are using file-wide metadata as
>>> described in [2] and encapsulate it as described in [2] in the
>>> CodecPrivate sub-element of the Track element. I think what we could
>>> for example do to include 1 and 2:
>>>
>>> DataFormat = { NameValue, JSON, XML, ...}
>>> DataHint = GPS data
>>>
>>> The first field is from a set list of values, the second one is free
>>> text string that a parser could read to decide whether it is able to
>>> interpret the data.
>>>
>>> In this way it would be possible to specify as many metadata tracks as
>>> one needs and use one of a fixed set of formats that parsers typically
>>> are able to cope with.
>>>
>>> Would something like this work for you?
>>>
>> Yes I think so. It's conceptually simpler to have separate
>> tracks/files for each metadata subtype, so the translation should be
>> simple enough.
>
> Cool. Let's work on that basis then.
>
> How do you think an example WebVTT file for your requirements would look like?
>

One of the simplest examples might be to embed a geojson object:

WEBVTT
DataFormat: GeoJSON
DataHint: GPS data


00:00.000 --> 00:01.000
{
   "type":"Feature",
   "id":"OpenLayers.Feature.Vector_314",
   "properties":{},
   "geometry":{ "type":"Point", "coordinates":[97.03125, 39.7265625] },
   "crs":{
       "type":"OGC",
       "properties":{ "urn":"urn:ogc:def:crs:OGC:1.3:CRS84" }
   }
 }

Other formats could be used as the payload: NMEA, GPX, KML, though it
might be useful to translate any comments (if the format supports
them) to a cue identifier.

--
You received this message because you are subscribed to the Google
Groups "WebM Discussion" group.
To post to this group, send email to webm-discuss@webmproject.org.
To unsubscribe from this group, send email to
webm-discuss+unsubscribe@webmproject.org.
For more options, visit this group at
http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.
Received on Tuesday, 10 April 2012 03:22:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:19 UTC