Re: [Cellar] AV1 mapping Matroska

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

Return-Path: <tterribe@xiph.org>
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 D4E0B130DC7 for <cellar@ietfa.amsl.com>; Sat, 30 Jun 2018 06:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85EuWmXG6tFT for <cellar@ietfa.amsl.com>; Sat, 30 Jun 2018 06:54:36 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C9112F295 for <cellar@ietf.org>; Sat, 30 Jun 2018 06:54:36 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 6F5ACC008D for <cellar@ietf.org>; Sat, 30 Jun 2018 13:54:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7heNcakCmU5 for <cellar@ietf.org>; Sat, 30 Jun 2018 13:54:34 +0000 (UTC)
Received: from [172.31.0.23] (38-132-129-164.dynamic-broadband.skybest.com [38.132.129.164]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id D84BABFF58 for <cellar@ietf.org>; Sat, 30 Jun 2018 13:54:31 +0000 (UTC)
To: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
References: <f603a9f5-d7dc-6640-1f53-f4d7b62a788e@googlemail.com> <CAOXsMFJJbHbh3=Gnu7Uag4Skq5+=jOimFNPxuicgDiVdbven4w@mail.gmail.com>
From: "Timothy B. Terriberry" <tterribe@xiph.org>
Message-ID: <dada3690-c8da-05db-4ddb-32476c1170f5@xiph.org>
Date: Sat, 30 Jun 2018 06:54:21 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.7.0
MIME-Version: 1.0
In-Reply-To: <CAOXsMFJJbHbh3=Gnu7Uag4Skq5+=jOimFNPxuicgDiVdbven4w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/CTYfdmX06c3-zImh_Qz77zI04VE>
Subject: Re: [Cellar] AV1 mapping Matroska
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.26
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: 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).