Re: EBML specification component for review - Element Data Size
Steve Lhomme <[email protected]>
| Newsgroups | gmane.comp.multimedia.matroska.devel |
|---|---|
| Message-ID | <CAOXsMF+Oy0JWbxFBrHfb3SKxg+7YnHNdk+OaXGR5xhk+W+M8XQ@mail.gmail.com> |
On Sat, May 2, 2015 at 8:45 PM, Dave Rice <[email protected]> wrote: > > > > On May 2, 2015, at 12:08 PM, wm4 <[email protected]> wrote: > > > > On Sat, 2 May 2015 17:59:22 +0200 > > Steve Lhomme <[email protected]> wrote: > > > >> On Fri, May 1, 2015 at 12:48 PM, wm4 <[email protected]> wrote: > >> > >>> On Fri, 1 May 2015 12:15:04 +0200 > >>> Moritz Bunkus <[email protected]> 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 _______________________________________________ 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