Re: [Cellar] AV1 mapping update
"Timothy B. Terriberry" <tterribe@xiph.org> Sat, 14 July 2018 20:34 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 52DF5130DC5 for <cellar@ietfa.amsl.com>; Sat, 14 Jul 2018 13:34:02 -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 6_oj7yWgQRD1 for <cellar@ietfa.amsl.com>; Sat, 14 Jul 2018 13:34:00 -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 AFF5812F1A5 for <cellar@ietf.org>; Sat, 14 Jul 2018 13:34:00 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 9F4BEC0B13 for <cellar@ietf.org>; Sat, 14 Jul 2018 20:34:00 +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 EssRK-I6GBn0 for <cellar@ietf.org>; Sat, 14 Jul 2018 20:33:59 +0000 (UTC)
Received: from [31.133.140.210] (dhcp-8cd2.meeting.ietf.org [31.133.140.210]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id C2900C04F3 for <cellar@ietf.org>; Sat, 14 Jul 2018 20:33:59 +0000 (UTC)
To: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
References: <CAOXsMFKHo6RS+q8KCXKoKCiBBS9pVqs92wsLgSfXZO+DT3dStQ@mail.gmail.com> <ca0f009e-a245-fcd6-95f8-f051736c9161@googlemail.com> <CAOXsMFL5-MaHQaAOyh7jSFUpCNbSEvAWKmAHcepaF+QsQuYbHw@mail.gmail.com> <fee747da-77ca-9282-a4c3-c112fd746507@googlemail.com>
From: "Timothy B. Terriberry" <tterribe@xiph.org>
Message-ID: <65e82a9f-26b2-11d8-44d5-7b1d6ed131a2@xiph.org>
Date: Sat, 14 Jul 2018 13:33:59 -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: <fee747da-77ca-9282-a4c3-c112fd746507@googlemail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/7GR1mfLk5yhrLCTvdcN7jHeUk6g>
Subject: Re: [Cellar] AV1 mapping update
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.27
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, 14 Jul 2018 20:34:03 -0000
Andreas Rheinhardt wrote: >> It's not up to the container to solve this. >> > It is not up to the container to decide whether the possibly damaged > frames between the DRAP and the KFDRP should be displayed, but it very I would argue that this does have implications for file trimming. The Matroska mapping is allowed to place more requirements on an implementation than the AV1 specification. So there is a choice to make. Just considering the default (no further restrictions) or requiring one of the three example behaviors in the spec has the following implications: If you choose to leave the handling of frames between the DRAP and the KFDRP implementation-defined, then someone cutting a stream has no idea how they will be handled. So the only safe thing to do is to strip them all. This adds some minor complexity burden to the remuxer, but guarantees that all such useless data will get stripped by a correct implementation. Choosing to require decoding and display even when the reference frames are not available would produce a similar result (since packet loss concealment is not normative). Choosing to require decoding and display of all frames that are guaranteed to be correct might allow a remuxer to cut at slightly more places without including an entire extra keyframe interval, but given that such frames are not required to be consecutive, this would get pretty complicated to implement (but at least it is optional: you can always fall back to stripping all such frames as above). Choosing to require that only frames starting from the KFDRP be decoded and displayed means that a remuxer does not need to strip such frames to guarantee consistent output from all players, allowing it to be slightly simpler, at the cost of allowing it to include some data that is useless. None of this helps you for seeking, because you don't have a choice about which frames to include, so one must rely on the player not to display garbage (in the case that references are missing) or stuttering output (in the case that only some frames between the DRAP and KFDRP are correctly decodable).
- [Cellar] AV1 mapping update Steve Lhomme
- Re: [Cellar] AV1 mapping update Andreas Rheinhardt
- Re: [Cellar] AV1 mapping update Steve Lhomme
- Re: [Cellar] AV1 mapping update Steve Lhomme
- Re: [Cellar] AV1 mapping update Andreas Rheinhardt
- Re: [Cellar] AV1 mapping update Steve Lhomme
- Re: [Cellar] AV1 mapping update Steve Lhomme
- Re: [Cellar] AV1 mapping update Timothy B. Terriberry
- Re: [Cellar] AV1 mapping update Andreas Rheinhardt
- Re: [Cellar] AV1 mapping update Timothy B. Terriberry
- Re: [Cellar] AV1 mapping update Andreas Rheinhardt
- Re: [Cellar] AV1 mapping update Timothy B. Terriberry
- Re: [Cellar] AV1 mapping update Timothy B. Terriberry
- Re: [Cellar] AV1 mapping update Steve Lhomme