Re: [Cellar] AV1 mapping Matroska

Steve Lhomme <> Sat, 30 June 2018 07:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5656613103B for <>; Sat, 30 Jun 2018 00:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 9B7ZpcIJfkt7 for <>; Sat, 30 Jun 2018 00:49:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9FC113103A for <>; Sat, 30 Jun 2018 00:49:58 -0700 (PDT)
Received: by with SMTP id g3-v6so5225214pfi.1 for <>; Sat, 30 Jun 2018 00:49:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NAMwkE24f69rQ8LoQ2+eJzwKNwgnqDIhvXgFMLJxSgg=; b=uZqPDCNkcJqbiRdp6hRXPs75EkLM3J2vTEbUspTwJG7PzjGXkUt1+1cTVLB3mWHHGO Ut7E0lqKkQJoqBdC9UGdM9sWZ9nX3kdrkPjQEgcgFtcw7gbjpGS3zHb1pPE2H02B/ihV Sn4okjMc32eoaor1fV7YEQbguYX3+Wlldzuli4pN4XDBihqnz+xuc843L4jejSlS0cxP y/iYRJBn/AP5zX8l//iRx03+G+KaPasHeTQ+QLSvZztdMfWCVo4PRuNnSZ+yWqyTCdVh /Ti5dv/coPQEIPhN0h01wnTjlimh++T3l9gmigCd00z5N2K8ChG9KE889v46W/NhGMl5 EfuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NAMwkE24f69rQ8LoQ2+eJzwKNwgnqDIhvXgFMLJxSgg=; b=FAQtYjD6L9BDu2EWDyohVYUnP2z1jQ6jOymP90CllitmeZPI6RyDqcoHm8JAst6w86 v/6QC1Fv9IXLAEX/MmqXk6a9fjYfCZ6sH4/0i5XRCx1nGUvrXyyFfwEYxNycRPZ84U8V zsIEZu//HGOr4+2sFTEjbb/kJqwtkfrCPaHbLcmGH/hJ7NlpbGxZezMkHqAPVqyfnVyz lOSKNPSOWyB3jrF6XyX3hOwBnVfOVYyOGMVZQ6Q0ouZ5QSZ/K9ThbmalIG+j7QG917wl xwAqXbfoyYPqJJEu3BO2czaCxvYobMMsC5fGhS0wrKRfH5aZDO4o/lUaHzDjF50Bqhw8 giZQ==
X-Gm-Message-State: APt69E1bH+HO99u7z2R9rO6Wae13hnPrJThqxHci70GP9cu8mWh+TXti 2Ko6ndVND4k689OybmlwjopOCeqW5bGp5SpdKxmrjQ==
X-Google-Smtp-Source: AAOMgpfuZIw/3Qy1Wt1iD2QnK7OmPzAb4sn/Vp2TILmI4xKc/iFLmExVL2PQqxTv+iho7AaPQ6KPpJ55bsY4/EPz/Bo=
X-Received: by 2002:a62:8d16:: with SMTP id z22-v6mr3943595pfd.181.1530344998203; Sat, 30 Jun 2018 00:49:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Sat, 30 Jun 2018 00:49:57 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Steve Lhomme <>
Date: Sat, 30 Jun 2018 09:49:57 +0200
Message-ID: <>
To: Andreas Rheinhardt <>
Cc: Codec Encoding for LossLess Archiving and Realtime transmission <>
Content-Type: text/plain; charset="UTF-8"
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 07:50:00 -0000

I updated my pull request with these 2 changes.

2018-06-30 9:44 GMT+02:00 Steve Lhomme <>rg>:
> Hi,
> 2018-06-30 0:09 GMT+02:00 Andreas Rheinhardt
> <>om>:
>> Hello,
>> 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.
> 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.
>> 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?
> It depends if it influences the output of the decoder or the decoder
> that can be used. My main concern here is that we have the necessary
> information to setup the decoder to start playback and be done with
> the duration of the Segment. Otherwise that means the CodecPrivate is
> sufficient.
> There's a fine line between being too restrictive and forcing multiple
> Segment for a simple internal change in the codec. So we don't want to
> restrict too many field from the Sequence Header. But on the other
> hand we want to ensure a Segment is consistent, especially regarding
> seeking.
> That being said, you're right [high_bitdepth] and [twelve_bit] are the
> ones needed to make up the actual [BitDepth] so I will change that.
>> 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?
> Yes, that would be a good use for when seeking is used. But these
> elements were ruled out as deprecated because they were of no use
> until now. I know VLC doesn't read them for example.
>> (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.)
> 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
> stored in the bitstream (which is frozen) but could be extra data we
> put in the CodecPrivate.
>> 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.
> It worked perfectly. Thanks for taking the time to review this !
>> _______________________________________________
>> Cellar mailing list
> --
> Steve Lhomme
> Matroska association Chairman

Steve Lhomme
Matroska association Chairman