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

Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Thu, 06 February 2020 10:16 UTC

Return-Path: <andreas.rheinhardt@gmail.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837FB120273 for <cellar@ietfa.amsl.com>; Thu, 6 Feb 2020 02:16:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrkGih_2lDja for <cellar@ietfa.amsl.com>; Thu, 6 Feb 2020 02:15:58 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA2612001A for <cellar@ietf.org>; Thu, 6 Feb 2020 02:15:58 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id 203so3686187lfa.12 for <cellar@ietf.org>; Thu, 06 Feb 2020 02:15:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:mime-version:in-reply-to :content-transfer-encoding; bh=Ki8m0BuPoOVdwW0u7b8Cw/sJjRhHS13ILeWurBMfOW4=; b=RzKE5A6mGsRAH6SoxuTyaY2Eb5J74/jUdzoXumepCRgrlACnLV4dAtkE2MmKGSiuzb 3TfstjqQGDaVZpF1/tJiOSLtcOrqR6FWkICgHykul5U4a+4PTYrhNEwPwu+7Ij6rjYtt VtxYUTyuEpx7OT+PcZROX5Di4/MxSm0cuOJWS8Eu9ZNOYDvhbImNPmfWd5OL98QmDNC5 Tg3Y65qSw9m4tn1uk3RdczXtGduNa1uZb2H37oKs8qyyb3wQ3+Qv/9HFqzIL6DBJLi9x a9rUM1cAOOkKmeW2pKN9Lhk37S2OLCnDL2icjjNfRYK1qPyAovxa80LtNyJUbRclLZDd v4hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :mime-version:in-reply-to:content-transfer-encoding; bh=Ki8m0BuPoOVdwW0u7b8Cw/sJjRhHS13ILeWurBMfOW4=; b=PkN0ixi4mz8D88NmiAy+lVOTi4KoWX1MuLuaAgDcJpyXvddB2J3CEHLjfq6CuTmlGh 8CL4gOO7CaObfkJbgz4CxUvXBCYTbgADjO92sw3eIUDsbTzWruBkRLf4bZnlrsZ1XQF0 K4j18/1iv1AZPWKpLOz2N8XhrhxO/V1dkYOA4Yr/XG8O+IYV0/uLiOLlDqXGPPdmOQbB vNoGmVeohhArJp7Y9Z60wswDTQcp8Xl93krmIKpUWNgG1gz9Y46UKH87i2TqgokSBn4J c1gH08DLE/knHUs9HDSHTZKSkg59FFpndaRWfGi8yTsL+1RQvrOW90+zxE1Qh8WAQ5cU Pxig==
X-Gm-Message-State: APjAAAXKU+ctM2at6rFjjxb4o6j0rnqxvsvrSj5WiMAHHUPYWYG0Zgsb bxd9YwtwJ5KMiz3SFBtoG9AD+vpK
X-Google-Smtp-Source: APXvYqwNBdgKnslOfZWx3luUja7BFABQCpqwcIknHVGxmhl9FKG7ZQYjfFSWHPRT1EUvkQZLth1nfg==
X-Received: by 2002:a19:7015:: with SMTP id h21mr1418844lfc.68.1580984155802; Thu, 06 Feb 2020 02:15:55 -0800 (PST)
Received: from [127.0.0.1] ([158.174.122.199]) by smtp.gmail.com with ESMTPSA id d20sm1083539ljg.95.2020.02.06.02.15.54 for <cellar@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 02:15:55 -0800 (PST)
From: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
To: cellar@ietf.org
References: <CAHUoET+QjYNe4-peA7k-xWQxy8oznNdj7TVfT_L-xUTC-5gMSw@mail.gmail.com>
Message-ID: <a3f6f329-9334-8db8-0761-e296fb302652@gmail.com>
Date: Thu, 06 Feb 2020 10:15:00 +0000
MIME-Version: 1.0
In-Reply-To: <CAHUoET+QjYNe4-peA7k-xWQxy8oznNdj7TVfT_L-xUTC-5gMSw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/9uiP7PrTsS05kbxAM80f55otMbc>
Subject: Re: [Cellar] Can there really be "many Blocks in a BlockGroup"?
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 10:16:01 -0000

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