[Matroska-devel] EBML specification component for review - Element Data Size
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>
> 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.
> 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
Matroska association Chairman
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Matroska-devel