Subject: [Cellar] Can there really be "many Blocks in a BlockGroup"?

From: Michael Bradshaw <[email-masked]>
Date: Wed, 5 Feb 2020 12:00:02 -0800

index_matroska.md
<https://github.com/cellar-wg/matroska-specification/blob/master/index_matroska.md>
currently
says:

"There can be many Blocks in a BlockGroup provided they all have the same
timestamp. It is used with different parts of a frame with different
priorities." (source
<https://github.com/cellar-wg/matroska-specification/blob/master/index_matroska.md#block-structure>
)
"There can be many Block Elements in a BlockGroup provided they all have
the same timestamp. It is used with different parts of a frame with
different priorities." (source
<https://github.com/cellar-wg/matroska-specification/blob/master/index_matroska.md#simpleblock-structure>
)

Neither of these seem right to me since Block has maxOccurs="1"
<https://github.com/cellar-wg/matroska-specification/blob/a577e0da858f56688ffedb975a49cbfacddc667c/ebml_matroska.xml#L138>
.

Is this just an outdated error in index_matroska.md?

Thanks,
--Michael

---

From: Andreas Rheinhardt <[email-masked]>
Date: Thu, 06 Feb 2020 10:15:00 +0000

> <https://github.com/cellar-wg/matroska-specification/blob/master/index_matroska.md#simpleblock-structure>

This sentence should have never been copied from the BlockGroup
description.

> ..
That's an interesting observation. I was not aware of the
maxOccurs="1" and it seems to be not supported at all by the software
I tested: FFmpeg ignores all but the last of the Blocks; mkvmerge only
uses the first of the blocks and mkclean crashes while mkvalidator
complains about a unique element occuring more than once.

maxOccurs="1" has been added in commit
6210296013de0e3f95ca15fde43595bfcd6ee774 (which belongs to PR #124);
it was in response to
<https://mailarchive.ietf.org/arch/msg/cellar/EefXScpaicRCZTRiQel8l2nEATY>.
There was no 'maxOccurs="unbounded"' present before this commit, so
that this commit did not create the contradiction between the
EBML-scheme and the desription of the BlockGroup element.

Given that there is no codec mapping that makes use of this "different
priorities" feature and that this contradiction alone meant that it
could only be used if we require the EBMLDocTypeReadVersion to be at
least four, it makes sense to adapt the description of the BlockGroup
structure to conform to the Matroska EBML-scheme.

- Andreas

PS: There would be another hypothetical use-case for multiple Blocks
inside the same BlockGroup: Blocks from different tracks that share
the same timing. This scenario is not uncommon when one translates
subtitles; yet I don't think it would be worth the additional
complexity to allow this. Furthermore, the point about
EBMLDocTypeReadVersion would apply here as well.
(I actually thought the specs to allow this already and fixing this
was on my to-do-list for the Matroska demuxer in FFmpeg. But the
quotes by Michael made me realize that I was wrong.)

---

From: Michael Bradshaw <[email-masked]>
Date: Tue, 18 Feb 2020 12:59:38 -0800

I've opened a PR for this:
https://github.com/cellar-wg/matroska-specification/pull/366

On Thu, Feb 6, 2020 at 2:16 AM Andreas Rheinhardt <
[email-masked]> wrote:

> Michael Bradshaw:
> > index_matroska.md
> > <
> https://github.com/cellar-wg/matroska-specification/blob/master/index_matroska.md
> >
> > currently
> > says:
> >
> > <
> https://github.com/cellar-wg/matroska-specification/blob/master/index_matroska.md#block-structure
> >
> > )
> > <
> https://github.com/cellar-wg/matroska-specification/blob/master/index_matroska.md#simpleblock-structure
> >
> > )
>
> > <
> https://github.com/cellar-wg/matroska-specification/blob/a577e0da858f56688ffedb975a49cbfacddc667c/ebml_matroska.xml#L138
> >
> > ..
> >
> <https://mailarchive.ietf.org/arch/msg/cellar/EefXScpaicRCZTRiQel8l2nEATY
> >.
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>