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

[Michael Bradshaw <[e-mail]>]

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 <
[e-mail]> wrote:

> Michael Bradshaw:
> > 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
> >
> > )
>
> This sentence should have never been copied from the BlockGroup
> description.
>
> >
> > 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?
> >
> 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.)
>
> _______________________________________________
> Cellar mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cellar
>