Re: [Cellar] AV1 mapping Matroska

Steve Lhomme <slhomme@matroska.org> Mon, 02 July 2018 10:51 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 C15E2130F13 for <cellar@ietfa.amsl.com>; Mon, 2 Jul 2018 03:51:44 -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 eQhmBm14nGjU for <cellar@ietfa.amsl.com>; Mon, 2 Jul 2018 03:51:41 -0700 (PDT)
Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (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 B6412130E06 for <cellar@ietf.org>; Mon, 2 Jul 2018 03:51:41 -0700 (PDT)
Received: by mail-pl0-x22d.google.com with SMTP id m16-v6so7769776pls.11 for <cellar@ietf.org>; Mon, 02 Jul 2018 03:51:41 -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:content-transfer-encoding; bh=KTT7aFV64X90IztfWJwPHAgPa5o+u0cPsbTUEvlB0DU=; b=wnuy3JrQ+HKrCNd2Uk33qPpTUGEJxjRPHIluf5N+EdUqmx/KPSZLlcFXn96cAcr0iy E5dE8a2vq73NUlZFHwJs8neWzNjgAm4spL33LTPxSWJhrqizSOgA9d78p0WL9qS4IzLF ZoalRI9kH3ENXiKpucF9qZiCZkFDq9B3j2162V5e5VojXwngHr6pUCcpqbzbYj1X1+hI W7ZdqPCEtvW6XiOB1JVqgOdQkkMLfTuKB/1ZZFiIjNlal0WSjvPuSikZJPBQWHfl8vJ2 /OM9yvmTDu0Lh8inCi2G8C8G1z2k9PO8DEs6CkZnvQl5SK16ARqTyydP0LMjtFPnnJOD x6SQ==
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:content-transfer-encoding; bh=KTT7aFV64X90IztfWJwPHAgPa5o+u0cPsbTUEvlB0DU=; b=rpFaL90XLkpIAxpRQCyXnLvFjdwEG6NA8TVSzzwbh/AdTApwk3bGM+b+UyllTEyPSd av5m78ZTcEEtYUvvrtAVSQTHSqF8XVOQvNrkt7NfMANDfKQsKP8+WcS1AIQc7Mk45Mzz Ez9zBO/EGMYKBVfK4nF/tht7gaafZuUycpwJPhH8l8frWiU4f2fqfz5OgoU6/DGnrPQv yYDWY/S8iupTUmG3+9oLWyhv9d0Jl4FBg09O0AXl+yv8LcU6OfGkQxt7upF+D9TCmZ7V kc9IBGwpnTATBmJUE2mTVlZl3O/LThTRkiuQKNuvDblSTmuDn0Ei1hjBexdUcuDw5wLr ia3Q==
X-Gm-Message-State: APt69E276ULa+i7e8zx7c2cv2iltG5AplAn5tnJV9bwHstm5g5qbyGUK mVkdRRaEsRyrxGNum3XF67fUlA7a3i4H/n7JIvTdCQ==
X-Google-Smtp-Source: ADUXVKLSV1m9Ms9SnDrkn53HqV2uVJj5VQY+fz28nR3WY+PZRNzqrBK9YKJ+Pol0XOZm2i9pt/jtxlUVlk7Zt6AaD24=
X-Received: by 2002:a17:902:8c95:: with SMTP id t21-v6mr25665186plo.306.1530528701040; Mon, 02 Jul 2018 03:51:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Mon, 2 Jul 2018 03:51:40 -0700 (PDT)
In-Reply-To: <20180702103455.GQ4839@michaelspb>
References: <f603a9f5-d7dc-6640-1f53-f4d7b62a788e@googlemail.com> <CAOXsMFJJbHbh3=Gnu7Uag4Skq5+=jOimFNPxuicgDiVdbven4w@mail.gmail.com> <dada3690-c8da-05db-4ddb-32476c1170f5@xiph.org> <CAOXsMF+CPW6VJsFaeahuL00hnvq5dUO-gHE3sYXPr5iVy8s1aQ@mail.gmail.com> <87efgmdqou.fsf@bunkus.org> <20180702103455.GQ4839@michaelspb>
From: Steve Lhomme <slhomme@matroska.org>
Date: Mon, 02 Jul 2018 12:51:40 +0200
Message-ID: <CAOXsMF+Q-RzwapNOamqc9G9XttnzMXyUuSY8_HFAA+h+4YsMJA@mail.gmail.com>
To: Michael Niedermayer <michael@niedermayer.cc>
Cc: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/tr4bP_aQ54bWlSMbxas8GOeZVxw>
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: Mon, 02 Jul 2018 10:51:45 -0000

2018-07-02 12:34 GMT+02:00 Michael Niedermayer <michael@niedermayer.cc>:
> Hi
>
> On Mon, Jul 02, 2018 at 09:47:45AM +0200, Moritz Bunkus wrote:
>> Hey,
>>
>> > Looking at the term "coded video sequence" (CVS) in other codecs (H.264
>> > and H.265) it seems it's a common term. And for those codec one Segment
>> > correspond to one CVS, with the parameters of that CVS stored in the
>> > CodecPrivate (SPS + PPS for H.264 for example). So we should probably go
>> > in that simple way.
>>
>> I have quite a lot of h.264 samples here, mainly M2TS from DVB, where
>> SPS/PPS change mid-stream, often multiple times. For such files the first
>> occurrences of SPS/PPS make up the AvcC in CodecPrivate, but all key frames
>> are still prefixed with the currently active SPS/PPS — because that's the
>> only way to signal that stuff has actually changed.
>
> IMHO All SPS/PPS should be in the "global header" (CodecPrivate) which the
> global header applies to, not just the first.
> This way an application can know all resolutions, aspect ratios and so on
> from just the header without the need to scan through all random access
> points.

My understanding is that it's how it's done in MP4:

"Each AVC sample entry, which contains the AVC video stream decoder
specific information, includes a group of SPSs and PPSs. This group of
parameter sets functions much like a codebook. Each parameter set has
an identifier, and each slice references the parameter set it was
coded against using the parameter set's identifier."

I have to check but I don't think Sequence Headers OBUs have
identifiers like that in AV1.

By the way, this is one mapping for V_AV1. There could be other AV1
mapping in Matroska where there is no CodecPrivate and there could be
multiple coded video sequences in it. But it would require the use of
CodecState and CueCodecState which is currently not an option for
WebM. So for now I will concentrate on a single coded video sequence.
And if needed in the future we can do a different one.


> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are too smart to engage in politics are punished by being
> governed by those who are dumber. -- Plato
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>



-- 
Steve Lhomme
Matroska association Chairman