Re: validity?

Moritz Bunkus <[email protected]> Mon, 3 Aug 2015 17:58:50 +0200
Newsgroups	gmane.comp.multimedia.matroska.devel
Message-ID	<[email protected]>
Hey,

> - Are undefined/unknown/unregistered elements allowed in the EBML
>   Header? For a MKV file are Elements that are not in either the EBML
>   or MKV spec allowed?

I would say that unknown elements should have to be treated the same way
no matter where they occur. Otherwise the EBML Head structure could
never be extended further.

However, I would say that an EBML Head itself can only contain other
EBML elements and not one of the semantic ones. E.g. a doc type spec
MUST NOT define elements which would be valid as a child element of an
EBML Head. I cannot think of a use case for allowing this, and it would
make parsing difficult (a parser would have to parse the head, get the
doc type, switch to that mode and re-parse the head in order to find
valid elements according to the doc type).

> - Is it correct that mandatory elements are optional unless they have
>   no registered default value? If a mandatory element does not appear
>   then the default value is used. Thus "WritingApp" which is mandatory
>   but has no default MUST appear but TimecodeScale which is mandatory
>   but with a default may or may not appear.

That's how I've always understood it, yes. I would describe it the other
way around, though, as the majority of elements does not have a default
value, something like »Mandatory elements MUST be present unless they
have a default value.«

I also tend to dislike double negation (…unless… no…) as it makes texts
harder to understand.

> - When is Element ordering important? Can EBML Elements be in any
>   order? I imagine having a bunch of Clusters in random order may make
>   playback difficult.

For Matroska there are two aspects regarding order:

1. The level 1 elements: certain elements (track headers, segment info)
   should be found before the first cluster is found in order to enable
   playback. This is somewhat murky (e.g. linking via meta seek
   elements).

2. The clusters should be ordered according to their timestamp in order
   to avoid excessive seeking (and streaming would also
   suffer). However, tiny clusters may actually violate that rule: the
   most extreme case would be a video track with B frames with a single
   frame per cluster. In that case the frame timecodes would be
   something like 0, 120, 40, 80… and so would the cluster
   timecodes. Those clusters would occur in the same order in the file
   violating this rule – but that would actually be OK.

Otherwise the order is flexible.

Kind regards,
mosu

_______________________________________________
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
signature.asc (application/pgp-signature, 819 B)