Re: [Cellar] AV1 mapping Matroska

Michael Niedermayer <michael@niedermayer.cc> Mon, 02 July 2018 19:07 UTC

Return-Path: <michael@niedermayer.cc>
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 DAC671312C9 for <cellar@ietfa.amsl.com>; Mon, 2 Jul 2018 12:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=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 vCC20kAVwK_U for <cellar@ietfa.amsl.com>; Mon, 2 Jul 2018 12:07:04 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1621312C8 for <cellar@ietf.org>; Mon, 2 Jul 2018 12:07:04 -0700 (PDT)
X-Originating-IP: 213.47.41.20
Received: from localhost (213-47-41-20.cable.dynamic.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 2318F40013 for <cellar@ietf.org>; Mon, 2 Jul 2018 19:07:01 +0000 (UTC)
Date: Mon, 2 Jul 2018 21:07:01 +0200
From: Michael Niedermayer <michael@niedermayer.cc>
To: cellar@ietf.org
Message-ID: <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HR4ti3j4RKbrMpBw"
Content-Disposition: inline
In-Reply-To: <36a0dc7e-8579-d99c-4beb-e8f4ce019eff@mediaarea.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/_-CBiY6AHZSC_USgjWPU09aoW_I>
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 19:07:14 -0000

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>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.

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.