Re: [Cellar] AV1 mapping Matroska

Andreas Rheinhardt <> Fri, 29 June 2018 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B8BE130E29 for <>; Fri, 29 Jun 2018 15:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xti1O-fxiMY8 for <>; Fri, 29 Jun 2018 15:11:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADB98130E1B for <>; Fri, 29 Jun 2018 15:11:05 -0700 (PDT)
Received: by with SMTP id c5-v6so10110295wrs.10 for <>; Fri, 29 Jun 2018 15:11:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:subject:to:in-reply-to:message-id:date:mime-version :content-transfer-encoding; bh=HssF7oasnKP6lDdJYTZszvhaAuCr0fBeRN5WqZu+R0Y=; b=fVw5oCW5muRDRCEEqaNLdW3ZhqbYQBvv6SbxVAfeqtonB7YGQTBmfnh94iJrNq4A0M 9t5lwY15Pds63DGAwZgzvzdtEKWlvAAqU47QFUP2XRDpKpD5X/kYO+C9txqqoeu6GTkE W+kmLcpv3ARcbBPZTgFYKMttBlCxDrXMg82mCqL1WzPQCphA3nyMTGMITx3/pJvvhEVm cUW4xs0/phXCJQSyVvtt7BgHoUWJ6m2UIkc9B9nsL/7N6T/kI4palJb30QRcav5y6YMC qpXVsA/j/oZL4W9ZPExplnYfIIjgfnzrJonMHu/D1KaKnyn80rElEmN/om9heozm5xGx 976Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:subject:to:in-reply-to:message-id:date :mime-version:content-transfer-encoding; bh=HssF7oasnKP6lDdJYTZszvhaAuCr0fBeRN5WqZu+R0Y=; b=EquGxSdPFis1RpN/sMtWs1mKtyA0fXeIF3++VuUiZlXkJGrUP1za43CZ4b2vcmAKzb 5dpL+LE5hV5Shx5TQJnnrAgtVwWUEok6nHHIs29gkUm2J4fvs3X+cazfoSLcfE1MzG2M AjJVxsTJlfUAUBAiml0ybufmL8o5B81zINRTfPgKiUQ3Tj7ceqFEnJZUfKo1D81CaDZo Z49nyfJr+yTKmBbhAvyVN1ab7UufZ9bpoeDkPFU1UsaDTd+sw7cvA3f4MtErYLa7wM0N MaCHcYnKV+BclsMrz92W44EXz/XVbgWGejB29aWJCCtAMDHTTtIgZ+98t1STZj5XhV/q 4IUQ==
X-Gm-Message-State: APt69E15izWJI1b/jIRPorl1Zq3iunrzvFaEWcVCGWkhMcNheiTQVc7Y xRptEdT18hRFPXM9gpEWdMwRMePk
X-Google-Smtp-Source: AAOMgpdZs1EFM2s4weRwi7V3SR1Q15XlI7r3Wmi3mqMYJrwpkfkhfRJrj/AmC83DGj0jSXvbKy18KA==
X-Received: by 2002:adf:9226:: with SMTP id 35-v6mr9637436wrj.44.1530310263851; Fri, 29 Jun 2018 15:11:03 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id e126-v6sm4096658wmd.43.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 15:11:03 -0700 (PDT)
From: Andreas Rheinhardt <>
Message-ID: <>
Date: Fri, 29 Jun 2018 22:09:00 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
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: Fri, 29 Jun 2018 22:17:45 -0000


I have only just started reading the specification, but I already have
some comments:

1. Your proposal says that DisplayHeight and DisplayWidth must be set so
that they agree with what is said in the CodecPrivate/in the bitstream
so that one can't use the Matroska fields anymore to override what is
set in the bitstream. If I am not mistaken, then AV1 would be unique in
this regard among all the video codecs that are allowed in Matroska. I
don't see a reason for this at all and propose that there shouldn't be a
special treatment for DisplayHeight and DisplayWidth in AV1.

2. Two sequence header OBUs with the same [seq_profile],
[high_bitdepth], [seq_level_idx] and [color_range] can still differ in
the [BitDepth] derived from them due to [twelve_bit]. Therefore I wonder
if this is the right restriction. Wouldn't it be better if it is
demanded that the derived [BitDepth] coincide for every sequence header OBU?

3. Given that AV1 seems to only use one Sequence Header OBU at a time
couldn't one use the CodecState and CueCodecState elements to designate
where the currently active Sequence Header OBU can be found so that one
doesn't need to repeat the Sequence Header with every keyframe?
(Btw: There are currently conflicting recommendations regarding the
existence of Sequence Header OBU if there is actually only one Sequence
Header OBU. On the one hand, they should be omitted, on the other hand
every block marked as keyframe should start with a Sequence Header OBU.)

Andreas Rheinhardt/mkver

PS: This is my first mail to this list and I hope that it will be
presented as a reply to Steve Lhomme's proposed AV1 mapping in Matroska,
but given the fact that I only subscribed today I can't simply reply,
but had to explicitly set the "In-Reply-To" field. Hope it works.