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

Steve Lhomme slhomme at matroska.org
Sat May 2 18:48:15 CEST 2015


On Sat, May 2, 2015 at 6:23 PM, Jerome Martinez <jerome at mediaarea.net>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20150502/b7edd68e/attachment.html>


More information about the Matroska-devel mailing list