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

2015-10-11 9:13 GMT+02:00 Steve Lhomme <[email protected]>:
> 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

In the *case* of mandatory.

> 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



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