Subject: [Cellar] question about relative defaults and BlockDuration

From: Dave Rice <[email-masked]>
Date: Sun, 3 Jul 2016 18:49:43 -0400

Hi all,

The EBML Schema for Matroska currently has Elements where a default value is taken from a related Element. I'd like to write up a process to define this in the EBML spec, but have some questions.

Firstly these are the currently used relative defaults in Matroska

name                   			default
BlockDuration           		DefaultDuration
DisplayWidth            		PixelWidth - PixelCropLeft - PixelCropRight
DisplayHeight           		PixelHeight - PixelCropTop - PixelCropBottom
OutputSamplingFrequency 	SamplingFrequency

For DisplayWidth, DisplayHeight, and OutputSamplingFrequency it is very straightforward to reference the default value since it references other Elements within the same Parent Element. However I'm not sure on how to define the relationship between BlockDuration and DefaultDuration. The closest xpath-like expression of relationship I can get it

default of BlockDuration = ../../Tracks/TrackEntry[TrackNumber=Block/BlockTrackNumber]/DefaultDuration

but an issue here is that BlockTrackNumber isn't an element but a value within the binary structure of Block. This means that a Matroska reader wouldn't be able to determine the default value of BlockDuration unless it was also able to parse the binary structure of Block. Is there a better way to express how to resolve the default value of BlockDuration?

Is it easier to say that BlockDuration has no default, but when used then BlockDuration overrides DefaultDuration? I am glad that the existence of this field may soothe Kieran Kunhya: https://twitter.com/obencoder/status/747522225310433280.

Excepting the Block Duration issue, I propose adding these sentences to the `default` attribute of the EBML Schema definition.

We also need some method to distinguish when a default is a string versus when a default is a path to another value. For instance to distinguish a default of the string "SamplingFrequency" from the value of the related Element with that name.

Dave Rice

---

From: Moritz Bunkus <[email-masked]>
Date: Mon, 4 Jul 2016 13:07:56 +0200

Hey,

yeah, Matroska's frame timestamps, duration and FPS issues are probably
the ugliest part of the whole format :/

> Is it easier to say that BlockDuration has no default, but when used
> then BlockDuration overrides DefaultDuration?

Interesting approach. We could indeed state that it something like this:

------------------------------------------------------------
The Element `BlockDuration` does not have a default value.

The algorithm that determines a frame's duration in a `BlockGroup` is as
follows:

1. If the `BlockGroup` element contains a `BlockDuration` element then
   the duration of each frame in that `BlockGroup` is `BlockDuration /
   number of frames in BlockGroup`. Algorithm terminates.

2. If the track headers corresponding to this `BlockGroup` element
   contain a `DefaultDuration` element then the duration of each frame
   in that `BlockGroup` is `DefaultDuration / number of frames in
   BlockGroup`. Algorithm terminates.

3. If there is a `BlockGroup` or `SimpleBlock` with a timestamp higher
   than the current `BlockGroup` object then the duration of each frame
   in that `BlockGroup` is `timestamp of following BlockDuration or
   SimpleBlock / number of frames in BlockGroup`. Algorithm
   terminates. [this one needs a better description — e.g. something
   with the next BlockGroup/SimpleBlock in display order]

4. Otherwise the duration is undefined.
------------------------------------------------------------

Similar for `SimpleBlock`, just skip step 1.

> We also need some method to distinguish when a default is a string
> versus when a default is a path to another value. For instance to
> distinguish a default of the string "SamplingFrequency" from the value
> of the related Element with that name.

Use different attributes? For example:

- default="Whatever"  ← this means that the string "Whatever" is the
  default
- default-from="Whenever"  ← this means take the default from the
  element "Whenever"

Kind regards,
mosu

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 12 Jul 2016 20:50:39 +0200

> Interesting approach. We could indeed state that it something like this:

That sounds very good.

> 4. Otherwise the duration is undefined.

or "@Whenever" that's seems clear enough and likely to be confused
with an actual value. Shouldn't this go in the EBML specs to describe
how defaults should be understood ?

> Kind regards,
> mosu
>
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

-- 
Steve Lhomme
Matroska association Chairman