Re: [Cellar] AV1 mapping update
Steve Lhomme <slhomme@matroska.org> Wed, 18 July 2018 09:41 UTC
Return-Path: <slhomme@matroska.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 D7203130DD8 for <cellar@ietfa.amsl.com>; Wed, 18 Jul 2018 02:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com
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 mYIVOgFrd2hY for <cellar@ietfa.amsl.com>; Wed, 18 Jul 2018 02:41:34 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AAB12777C for <cellar@ietf.org>; Wed, 18 Jul 2018 02:41:34 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id n7-v6so1763175pgq.4 for <cellar@ietf.org>; Wed, 18 Jul 2018 02:41:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I8ZGYjcVA2LC+EiZMUtzgMvIXmedvbWJ+Dfd07cUAtg=; b=lMAyuC2LG4FJY+GgWvuqSOj7efux5OHHvDr3AllKzBgoqQe99dISM5/+WIsbPmOeDa W2dhbrgDumIFcviVzGg64bZLwcTCIT3jw/LD9pGTHpCIOIIfj0kZzcbXt0Aco17MySqd p7+r4z8XfqcHsmPTnSxY9XVA6wkQTEfNbiMH0bahexDlPwb8MFt89Soblq4VOFA2qs+S mMBVsdLinAZ8Fjdn4wnpL2/0Rpnc5cwV1dp5gfFaKwxvuJanOLdTvsgisxGcYVmUAY2C Wf1tjsk9XIKZtLxr57+V7bLozHy+r+RIpqmpqE9OSnDm0bo3sswb6VxpOewPsQGRRju/ N8ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I8ZGYjcVA2LC+EiZMUtzgMvIXmedvbWJ+Dfd07cUAtg=; b=c+cCRjGsVWHnEpqV3Ay9SH3ep7gmzJxO+Gev1DJwNPsGXOW2237eR1ufpKyEP78JRN i+CaRn16nrJu502KcYn1b5jrf7Q/LWumdsRHvEGQZfbxjedwmReN+jy+ewvof8y5/jSi XwjxZDgjZ59dP6umryAZXVdaqqbRY4cEE1VR+rdwL5PDy20f/MU9SxTg8oC6aesvZ+kx KH2rhwwEATteV2pdcT3L9vbqNgMlnDOUjlYTunZqINEUx6iuW5Co2T0A/cQfrfRXkRc7 mparRnkf7jF5oNfOjIRpho5qq0se6l7Y/C4pFW+iaSQHLJul3B95IGy99gk7GXJ+sVx/ tweA==
X-Gm-Message-State: AOUpUlHvgTsPfI8CgNb6e1mj77df000Um9yXFL9QhdkEiC1by39yblDN H730YFHybbx/NYo2Ksmo6+bOTxcuaA5lJsiIHC5JcC2X
X-Google-Smtp-Source: AAOMgpe/Ml3NMMjuTmy2y0WSQ1KsvZTJo/gsY+7k1lMrFmijFAX7Fg7oHFId8LIdEF0DfFIlyorb7M4xTodYVWhbwc8=
X-Received: by 2002:a65:5245:: with SMTP id q5-v6mr5016308pgp.67.1531906893622; Wed, 18 Jul 2018 02:41:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:9c13:0:0:0:0 with HTTP; Wed, 18 Jul 2018 02:41:32 -0700 (PDT)
In-Reply-To: <c50475ce-3f09-5bf7-32ee-76ee7d55af52@xiph.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> <CAOXsMFJtc9pq+PphRb5kF9Mp4jyS5j3LQi6vQQmHRyTDYWyQ-A@mail.gmail.com> <b8486fa4-132b-f814-7046-91efb0a48ec6@googlemail.com> <10d56d2a-3053-6069-7805-54bb4fd1d4e0@xiph.org> <b8c8236c-5dd7-5511-6994-730ea0aaef84@googlemail.com> <c50475ce-3f09-5bf7-32ee-76ee7d55af52@xiph.org>
From: Steve Lhomme <slhomme@matroska.org>
Date: Wed, 18 Jul 2018 11:41:32 +0200
Message-ID: <CAOXsMFJjsUVEDBuL9LMr6YukK+-E-7d9p9mDZATMmFWw-SFB1g@mail.gmail.com>
To: "Timothy B. Terriberry" <tterribe@xiph.org>
Cc: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/2Le5KOzqrG4czq_ajrhQKACnoVg>
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: Wed, 18 Jul 2018 09:41:37 -0000
Hi Tim, 2018-07-16 17:11 GMT+02:00 Timothy B. Terriberry <tterribe@xiph.org>: > Andreas Rheinhardt wrote: >> >> every timestamp in Matroska is a multiple of 1 ns (this number is >> hard-coded) so that NTSC timings can't be exactly represented on the >> container level: E.g. the default duration field for 24/1.001fps content >> would indicate 41708333ns, although it is 41708333.33333333...ns. So by >> preserving the bitstream information it is possible to increase the >> certainity that 41708333ns actually means 24/1.001 fps. > > > This seems like a good enough reason that it should probably be explicitly > described in the draft (especially if you want any of that to work in > practice). If that's the only reason then okay, but if there are a lot of > other reasons, then SHOULD may be too strong. In any cases the container time will apply. It's fine to "resample" a 24fps to display it in 1fps (slow motion mode) without changing the coded data. So it doesn't really matter how the source was encoded. (I'm not sure decoders do temporal adjustments, at least when interlacing is not involved). > As an aside the timestamp situation still makes me sad. All of us :( We still haven't come up with a good backward compatible solution. For future Matroska versions it's certainly doable. >> 2. Would it be legal to code a frame with [show_frame] 0, >> [showable_frame] 1 followed (perhaps immediately) by a frame header in >> the same temporal unit that has [show_existing_frame] set to 1 and >> outputs the frame just coded? If yes, is there any reason to ever use >> it? I don't see any. According to the definition, this temporal unit > > > I think it is legal. I don't know why you would ever do it, but it wouldn't > cause any great harm. Does it complicate anything to allow it any more than > DRAPs complicate things already? No, it's just not optimal. It may happen in cases where some frames that were in between were dropped (or some capture system that would only keep keyframes from a source stream). > It gets more complicated when you consider spatial scalability. It is > possible for you to have a RAP for a frame other than the base layer, so you > may actually have one or more shown frames in the same temporal unit (for > different spatial layers) before a (delayed or even non-delayed) RAP, and > again be unable to re-order them, and now whether you can start display at > that frame or a following frame can depend on which operating point you are > trying to use. > > In particular, the problem is that the AV1 specification defines a RAP in > terms of a *frame*, and not in terms of a temporal unit. Because Matroska > defines its blocks as containing a temporal unit, and RAPs in terms of a > block, you will have to define the details of when a temporal unit should be > considered a RAP (or DRAP, KFDRP, etc.) based on the frames contained inside > of it. > > I think it may have been a mistake to do things this way in the AV1 > specification, since the idea was always for temporal units to be the unit > of muxing in any container, but I expect it was done this way out of > expediency to avoid having to think through all of these cases. We have to > think through them now. Sadly it's too late to fix this. And on our side we cannot just assume people will just do "the right thing" if the spec allows different/odd ways. > As I said in another mail, I think it may be okay to impose additional > restrictions on top of the AV1 specification, especially if it makes > everyone else's lives easier. This may be one such case. While the > situations described above may confer some marginal advantage, and I can > imagine an encoder that could take advantage of them, I don't think there > would be a big loss by forbidding them. I agree. We could also have a different CodecID for a more loose/less seek friendly version. > I do think it would be a very good idea to have the *same* restrictions (if > any) for Matroska and MP4. If something is technically allowed by the AV1 > specification but you can't actually put that into any container, then in > practical terms it might as well not be allowed. But if we allow some things > in Matroska but don't allow them in MP4, or vice versa, then you just have > an interoperability mess. I agree. That's why I had a few picks there to see how things are done. There doesn't seem to be much restrictions on the bitstream itself (other that the ones I already copied like the low overhead bitstream format). But that also means if we want to add new restrictions we need to have them on the MP4 side as well. >> 5. What do you think of the restriction of a Matroska track to a (subset >> of) a CVS? > > > If you look back to my mail on June 30th, I thought I was the one who > suggested it in the first place. > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman
- [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