Re: [Cellar] AV1 mapping Matroska

"Timothy B. Terriberry" <> Sat, 30 June 2018 13:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4E0B130DC7 for <>; Sat, 30 Jun 2018 06:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 85EuWmXG6tFT for <>; Sat, 30 Jun 2018 06:54:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98C9112F295 for <>; Sat, 30 Jun 2018 06:54:36 -0700 (PDT)
Received: from localhost (localhost6.localdomain []) by (Postfix) with ESMTP id 6F5ACC008D for <>; Sat, 30 Jun 2018 13:54:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p7heNcakCmU5 for <>; Sat, 30 Jun 2018 13:54:34 +0000 (UTC)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id D84BABFF58 for <>; Sat, 30 Jun 2018 13:54:31 +0000 (UTC)
To: Codec Encoding for LossLess Archiving and Realtime transmission <>
References: <> <>
From: "Timothy B. Terriberry" <>
Message-ID: <>
Date: Sat, 30 Jun 2018 06:54:21 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 SeaMonkey/
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Cellar] AV1 mapping Matroska
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 30 Jun 2018 13:54:40 -0000

Steve Lhomme wrote:
> You're right. This is a mistake on my part. Instead of MUST it's a
> SHOULD. Because Matroska allows to override the codec internal values
> to display this differently, including changing the aspect ratio or
> forcing physical dimensions. I will change that.

Keep in mind that "SHOULD" tends to have a somewhat stronger force in an 
IETF specification than in normal English. If you're going to use SHOULD 
and not MUST, it is a good idea to explain when someone might reasonably 
violate that SHOULD (if you can't because you can't think of a reason, 
then you want MUST; if you can't because there are too many reasons, 
then you want MAY).

> You mean in my document or the AV1 specs ? My understanding is that
> the AV1 bitstream allow Sequence Header OBUs to be found within the
> stream. And doesn't mention which elements are allowed to change or
> not. Maybe there will be profiles for such restrictions. It won't be

See Section 7.5 "Ordering of OBUs":

"Sequence header OBUs may appear in any order within a coded video 
sequence. Within a particular coded video sequence, the contents of 
sequence_header_obu must be bit-identical each time the sequence header 
appears except for the contents of operating_parameters_info. A new 
coded video sequence is required if the sequence header parameters change."

So the question you want to answer is how what is stored in a Matroska 
file maps to a "coded video sequence". My opinion (as an individual) is 
that a single EBML Document should correspond to a single coded video 
sequence. That means that nothing in the sequence header can change 
(except for the operating_parameters_info).