Re: [Cellar] AV1 mapping Matroska

Steve Lhomme <slhomme@matroska.org> Mon, 09 July 2018 08:17 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 77BAC130F1B for <cellar@ietfa.amsl.com>; Mon, 9 Jul 2018 01:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 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] 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 WubsHSAUgvbD for <cellar@ietfa.amsl.com>; Mon, 9 Jul 2018 01:17:41 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 C3DFA130E27 for <cellar@ietf.org>; Mon, 9 Jul 2018 01:17:41 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id x13-v6so3198144pfh.5 for <cellar@ietf.org>; Mon, 09 Jul 2018 01:17: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 :content-transfer-encoding; bh=sWs5L73ybUg4rwbSWMECBI6oHK/Zol3zQ5cXtHL3fMk=; b=EwHq5S+VYyBr+xOUQuGZaB86M+kQi2Y2oJoT5czwm1LCMX3D9Lau0nPQwcMeQnZLCJ usBn7votqdEQJluzMuKYuZCocJngtSbPMxQ5uFtjsjel436kAPcsd4cTC8aKu4/5C9lq JiDN5lukVQVJX9wuoMXVBfMRIuF+aMzNUBoHr0p5BYJ0cmoSkmQOk6zCpiP1S1iyrGuX cQtsHfxmwTMhDJEo8LG/Y4p6Ly9eMUjGnd2HEOd5qM+N/A9OLL4+L0Jj13enCW4MB58b /PpFEDvlYxo8mepznv6y+oZFrXdv6Rm2IKj+yZpoEOBwDAoLLBs0Dqg2rk6QJXHTrM+4 o7VA==
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:content-transfer-encoding; bh=sWs5L73ybUg4rwbSWMECBI6oHK/Zol3zQ5cXtHL3fMk=; b=R1KQ25/9b9wHSmwDYk9ie00LYiG4+gAT+Fs9MV0ORdzuEqriEFsrMgziVIKo9IrGOK alxSucHOZGuMAOh8MB7XwPaK6KXlH/dwa7xQhOjIFQDOfPIvZssOwRzL+eOgKGIwa0VS oaaQNv/bwdQ2nQXa0affCvu6bwqTEYhDfdE0c0XsEYpsZ1ofvCt67vQR+5jPqDlpD4sO 4cdCH7mF6gFsSJ98ShaOxM49pOtRfCDmcoF4hciJhjTM1OWDZ9YgQHxKNvHIDOwkASG0 /9sISOAbWmsHpJQjJ/u6ZHe/4BRs/rz3ia8UnY0Y8XrangaO/71qAdnkDBDcx9julNc/ SqAQ==
X-Gm-Message-State: APt69E2tAtyW0ojm8AX39uVspXGFcmvmLoFl84yAvNqN7KDLFTGLqjkX lPFQCzavSnAytJtHEdLBff6WQiEEWF0e6y/8VH5VeQ==
X-Google-Smtp-Source: AAOMgpf37zi5pgnz5ZuRXA9nYnOC5yW0FwZ78LGGJPPaW6lKU8xQoAkDUlI+//FNK5E0kuT7RYyRFptbgoajZi+Q2+8=
X-Received: by 2002:a62:384:: with SMTP id 126-v6mr2985557pfd.11.1531124260940; Mon, 09 Jul 2018 01:17:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Mon, 9 Jul 2018 01:17:40 -0700 (PDT)
In-Reply-To: <20180702190701.GR4839@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> <CAOXsMF+Q-RzwapNOamqc9G9XttnzMXyUuSY8_HFAA+h+4YsMJA@mail.gmail.com> <36a0dc7e-8579-d99c-4beb-e8f4ce019eff@mediaarea.net> <20180702190701.GR4839@michaelspb>
From: Steve Lhomme <slhomme@matroska.org>
Date: Mon, 09 Jul 2018 10:17:40 +0200
Message-ID: <CAOXsMFKG_cvaUEgQdR3ub6g354w8VwESY_9Nj4NdXmx6JgQOTA@mail.gmail.com>
To: 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/lXYhyyw-MkPvY_PySvJhFQk1Ir4>
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, 09 Jul 2018 08:17:45 -0000

2018-07-02 21:07 GMT+02:00 Michael Niedermayer <michael@niedermayer.cc>:
> On Mon, Jul 02, 2018 at 01:14:02PM +0200, Jerome Martinez wrote:
>> On 02/07/2018 12:51, Steve Lhomme wrote:
>> >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.
>>
>> Not possible with e.g. real time streaming (you don't know in advance the
>> next SPS/PPS)
>
> In cases where the SPS/PPS can change and it is not known when the global
> header needs to be produced (that is for example real time streaming).
> it follows that there should be no global header or it should not contain
> any SPS/PPS. But only things which are known for the whole stream.

In Matroska this can be achieved by starting a new Segment when the
codec parameters change. That has an impact on all tracks at the same
time so it may not be good/friendly in all cases. We could describe
this scenario in the specs when a `PrevUID` should be used to specify
the new Segment is a continuation of the previous segment. Actually
even the NextUID could be generated for each Segment and written when
it starts. Technically it would be a correct segment hard-linking but
in the context of live streaming (unknown duration per segment).

> I would argue this is kind of the definition of a global header.
> It applies globally to the whole stream.
> Storing only one out of several PPS/SPS in the header
> (which was mentioned above) feels  rather incorrect to me. And any
> software which makes decissions based on SPS data like resolution and
> aspect ratio could benefit from knowing if it needs to scan the whole
> stream for SPS changes or if it can trust the first or global header
>
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you drop bombs on a foreign country and kill a hundred thousand
> innocent people, expect your government to call the consequence
> "unprovoked inhuman terrorist attacks" and use it to justify dropping
> more bombs and killing more people. The technology changed, the idea is old.
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>



-- 
Steve Lhomme
Matroska association Chairman