Re: EBML specification component for review - Element Data Size

01.05.2015, 12:15 Moritz Bunkus:
> Hey,
> 
> [...]
>> In the context of Matroska, I'd disallow unknown lengths in almost all
>> contexts (i.e. disallow them by default, allow them only when
>> explicitly specifified). Because they make demuxing a pain, and most
>> Matroska demuxers probably support unknown length at a few places at
>> best.
> 
> While this being true we have to be careful not to invalidate existing
> files retroactively. Unknown sizes have been in the specs since the
> beginning; changing them now is not something we should do on a whim (if
> at all).
> 


I have no preference here. In the context of Matroska the only case that
gets to my mind where elements with unknown sizes occur would be
(live)streaming where the file is written and then read, before the file
is completed. (It's the only use-case that gets to my mind, that does
not mean it is the only one.)

I strongly prefer demuxers to handle unknown sizes in all cases, no
matter where they occur, but reality seems to be that software has
flaws, rather than being perfect. This would make me argue against
having unknown lengths being expected to occur everywhere. Instead I
would favor them to be specified where they are allowed to occur.

On the other hand why should it be limited if there is no negative impact?!

Ideally demuxers would work in safe-mode by default, where they work
just like the specs tell them, while also having a debug-mode in which
they try to handle anything that comes along.

Best regards,
Sebastian
_______________________________________________
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