Subject: Re: [Cellar] TrackTypes for non-standard data formats

From: Steve Lhomme <[email-masked]>
Date: Sun, 26 Feb 2017 17:24:18 +0100

In general when there's something you want to multiplex there's always
the "complex" type in which you may put whatever you want.

But it is recommended to use existing things or create what's missing.

2017-01-25 5:39 GMT+01:00 Matt Gruenke <[email-masked]>:
> If it'd help to deal with specifics, some examples I have in mind are scene
> geometry (e.g. point clouds, polygonal meshes, Z-buffer), camera pose (e.g.
> position & orientation as vector & quaternion pairs, GPS coordinates,
> compass readings), and various telemetry data (plenty of examples at
> https://en.wikipedia.org/wiki/Telemetry ).

For things like camera position/GPS, if it doesn't change, a tag on a
chapter for that specific thing is probably better. It's easier to
lookup such information among files (theoretically). But obviously
there are lots of cases where this is not the case and we probably
need a kind of track specific for that (sport cameras like Go Pros
come to mind) with proper definition. Maybe the ancillary name is
generic enough to cover all these and then depending on the codec you
know what kind of information you would get.

For the scene geometry I'm not familiar with this. Does it need to be
interleaved with the audio/video things ? A chapter tag is not enough
?

> Although nothing specific comes to mind that wouldn't have a stream-like
> structure, one might allow for more such things as menus and button tracks.
> Perhaps a game streaming application might use a track for player
> information and statistics.
>
> In considering the utility & possible necessity of multiple,
> application-defined TrackTypes, perhaps it's worth reviewing the purposes
> they serve.  One function of TrackType is certainly to simplify semantic
> mapping of the available tracks.  To this end, it can prove more reliable
> than CodecID, since it's certainly possible to use the same encoding for
> tracks with different semantics.
>
> Of course, TrackType also dictates the content model of TrackEntry.  Though,
> I don't know enough about EBML to have a sense of whether it's practical and
> reasonable for applications to extend the schema to allow for custom track
> metadata.
>
> I guess I'd ask why *not* allow ancillary data to have one of ~8 TrackTypes?
> At the very least, I'd suggest using somewhere near the top of the range.
> Then, more values for ancillary data could be added, subsequently, while
> keeping the range contiguous.
>
>
> Matt
>
>
> On Tue, Jan 24, 2017 at 10:24 AM, Dave Rice <[email-masked]> wrote:
>>
>>
>> IIRC the proposal for ancillary tracks was to have Codec_IDs prefixed with
>> "N_". If your binary data stream is wholly private with contents that are
>> not intended to be known by the Matroska specification then perhaps a
>> private Codec ID prefix (such a "X_") would be worthwhile to define. On the
>> other hand, if you could be more transparent you could also consider
>> defining your codec openly, perhaps the application specific use could have
>> wider interest.
>>
>> Or could OggKate store the values you need? Perhaps it's worthwhile to
>> define storage for a time-based metadata track such as this.
>>
>> Dave Rice
>
>
>
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>

-- 
Steve Lhomme
Matroska association Chairman

---

From: Matt Gruenke <[email-masked]>
Date: Sun, 26 Feb 2017 21:21:05 -0500

Where are the complex & ancillary TrackTypes described?  If ancillary
tracks can be named, that would probably be sufficient.  I think the
CodecID should describe only *how *the data is encoded, which might be
insufficient to convey its meaning or relationship to the other tracks.

In all of the examples I mentioned, I can foresee cases where these would
need to be time-stamped frames that might have a different sampling rate
than the video or audio streams, if present.  In fact, this is the case for
one camera I've used, where the depth sensor operates at a different rate
than the primary image sensor.

Matt