Re: EBML specification component for review - Element Data Size

On Sat, May 2, 2015 at 6:23 PM, Jerome Martinez <[email protected]>
wrote:

> Le 02/05/2015 18:08, Steve Lhomme a écrit :
>
>>
>>
>> As said in one of the proposed text, unknown size elements MUST be
>> master/list elements. They cannot be binary blobs or numbers. I don't think
>> it's written anywhere, but it should. Although as in a lot of case with
>> these unwritten rules, they are pretty obvious.
>>
>
> In a specification, nothing can be "pretty obvious", all must be written.
> If it is not written, let's add it.
>

Yup.


> that said, it is not so true for binary blobs: we can imagine we start to
> write a frame without knowing the size of the frame (because we have only
> its first slice at the moment of writing, low latency mode without being
> "real time") and we'll write the size of the frame only when we get the
> last slice.
>

But in that case that's just a temporary state of the file, in the end the
file has a size set. We use this technique extensively with Matroska muxers.


> FYI, this is used in MXF format ("incomplete" mode) and the unknown size
> of the blob is present in the file if the muxer crashed (most player can
> play the file despite this unknown element size, size is considered to be
> up to the end of the file). So I would not forbid unknown size element for
> binary blobs.


You can't expect a specification to cover files created by a program that
crashed.

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