[Matroska-devel] EBML specification component for review - Element Data Size

Steve Lhomme slhomme at matroska.org
Sun May 3 08:32:32 CEST 2015


On Sat, May 2, 2015 at 8:45 PM, Dave Rice <dave at dericed.com> wrote:
>
>
> > On May 2, 2015, at 12:08 PM, wm4 <nfxjfg at googlemail.com> wrote:
> >
> > On Sat, 2 May 2015 17:59:22 +0200
> > Steve Lhomme <slhomme at matroska.org> wrote:
> >
> >> On Fri, May 1, 2015 at 12:48 PM, wm4 <nfxjfg at googlemail.com> wrote:
> >>
> >>> On Fri, 1 May 2015 12:15:04 +0200
> >>> Moritz Bunkus <moritz at bunkus.org> wrote:
> >>>
> >>> There's EBMLMaxIDLength, which gives the length of IDs. I see
> >>> absolutely no point in making this value different from 4.
> >>>
> >>>
> >> You never know. Maybe someone will want to put a SHA1 someday.
> >>
> >
> > Doesn't make sense. The ID has to follow a certain formatting (the
> > variable length encoding), so you can't have arbitrary data as ID. Only
> > a subset of SHA1 hashes are valid EBML IDs.
>
> Perhaps I'm missing it, but I don't think the EBML spec is strong enough to say that Element IDs must use variable length encoding. The closest is where it says "Element ID coded with an UTF-8 like system", but it's missing a declaration of mandate or "MUST".


Good point. Although, as for a lot of things, it's implied by the
EBMLMaxIDLength which means it could be of any size. Current EBML
parsers could not deal with non formatted IDs of fixed size. So I
think it should say in the specs it's variable length. It could be
possible to extend EBML with another element in the header that says
so. But that would break backward compatibility.

-- 
Steve Lhomme
Matroska association Chairman


More information about the Matroska-devel mailing list