Re: Several (minor) issues or underspecified areas in the MKV spec

2015-10-05 18:07 GMT+02:00 Michael Bradshaw <[email protected]>:
> On Sun, Oct 4, 2015 at 6:43 AM, Steve Lhomme <[email protected]> wrote:
>>
>> On Sep 29, 2015 03:04, "Michael Bradshaw" <[email protected]> wrote:
>>
>> > What’s the point of default values for non-mandatory elements in the MKV
>> > spec? Why not make them mandatory if they have a default value?
>>
>> You could set the element in the file if you want, but if it's the default
>> value (likely a very common value) you don't have to write it, the semantic
>> reader will get it.
>
>
> But is there any real difference between a non-mandatory element with a
> default value, and a mandatory element with a default value? The two seem
> effectively equivalent. If there's no meaningful difference, why not just
> make any element with a default value a mandatory element?

In the of mandatory, you don't even have to write it in the file at
all. Whenever you read the parent element, either it's there and you
read the value (if there's one) or you assume you have the default
value.

If it's not mandatory and not written, then you do not have the
element and its value. So if you want the element you have to write at
least the ID and a size of 0. Each time you want it.

>> > Is the duration of a block always evenly distributed amongst its frames
>> > (for a block that has multiple laced frames in it)? I don’t see any explicit
>> > mention in the MKV spec as to how the block’s duration is supposed to be
>> > distributed to its frames, and I think that should be mentioned.
>>
>> Only the timestamp (aka timecode in the specs) of the first frame is known
>> and the duration is for each frame...
>
> The spec says BlockDuration is the duration of the block, not the duration
> of each frame (average or otherwise).

Correct, they are 2 different things. There is the DefaultDuration
which is "per frame". And the BlockDuration which is for that
particular BlockGroup, no matter how many frames it contains.

> Additionally, if the duration must be
> computed as the delta between the current block's timestamp/timecode and the
> next block's, then this delta certainly refers to the duration of the block
> and not each frame.

Yes, the BlockDuration applies to the whole BlockGroup.

We may rename DefaultDuration to DefaultFrameDuration to make this more clear.

> FFmpeg's demuxer evenly distributes the block's duration amongst all the
> frames[1]. This distribution is logical, but not explicitly mandated in the
> MKV spec, and I think it should be if it's the intended behavior.
>
> [1]:
> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskadec.c#L2888

This may be okay is not cases but not all. Codecs like Vorbis or AAC
have frames with different sample sizes in the same stream. So the
duration may differ frame by frame. The lacing was added specifically
for Vorbis because it has very small packets and a lot of container
space would be wasted otherwise. In that case it's incorrect to assume
all frames have the same duration. It should be the job of a
packetizer or the decoder to recover the proper length for each
packet.

> _______________________________________________
> Matroska-devel mailing list
> [email protected]
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel



-- 
Steve Lhomme
Matroska association Chairman
_______________________________________________
Matroska-devel mailing list
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel