From nobody Thu Aug 2 10:48:44 2018 Return-Path: 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 092D8129C6B for ; Thu, 2 Aug 2018 10:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 4KoaaIlmEaIA for ; Thu, 2 Aug 2018 10:48:39 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 9C0411286E3 for ; Thu, 2 Aug 2018 10:48:39 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id v17-v6so2144386qkb.11 for ; Thu, 02 Aug 2018 10:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rdkhMEC1epTFezpV5tsG2EEm3b2DLPZlhOad9FSVdL4=; b=piA+uV7QQtGi4b8zV29RZG9VbH4DJzgNOfTINsT4/naeVJeYwyv40jKN5kxlbtwV6N 6QSVuta9NWVhi3esHFnlJY5xTLWvQfTPjbIhaS7U33XfNPc/yLWzoS9zYWkALz4NbYfG MFjqs1dIR7nP+4y3pXJu88B63KvyslrvTl+ZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rdkhMEC1epTFezpV5tsG2EEm3b2DLPZlhOad9FSVdL4=; b=goJeCDqBFrwYfXp8LaYlMPdEtaszkhDWInwuychD2tnimYTGo7K2Rdti9rDux9R9m8 4bhn9povosXp/xXMv17TVRm7wp77wObwF5gy5xMkwTgzjYIUZr5AZzmisFIoBUnLJLPl TexXFXlGK86SdGv9JHhAgCz0R7a+WffjWpX09PniIDMiXJjmD1aO4F7PwvVhM/7c3lWW NnOuRaKvm7SYCyoIDyJYiKaugqdZi1FmU0+cTxuOR3fUaKSrS4rnP4klyX2EFR+EsB58 uRkzc8amMNaeU0aIPXOD77l3Twl+IVBPH7qu+qxEjt1StwGLE+76lHFon45I4SDYPeZy 7TWQ== X-Gm-Message-State: AOUpUlHaiaBusmZMnpRmM3fXjEGmRvz/P8VxYkt8pgIZOpI9sf2v/V9F uRo2qm9jcjOYlqeCB8kDglDL+WE5eDdCPyV+jBQobCVjbcU= X-Google-Smtp-Source: AAOMgpfuPgSxC8tN1HsNUaNbVQkeEhXWyhCne4XkFJTqrCULxLmpWQeBulTu9ti9LFIQaa7xuE432q6JT9UpB40Qgoo= X-Received: by 2002:a37:284a:: with SMTP id o71-v6mr474778qkh.176.1533232118561; Thu, 02 Aug 2018 10:48:38 -0700 (PDT) MIME-Version: 1.0 References: <62c29889-49f5-6634-049a-a2d73315bb3c@googlemail.com> <4ff1f1f8-3b66-e229-7884-c851dae8e2e0@googlemail.com> In-Reply-To: From: Cyril Concolato Date: Thu, 2 Aug 2018 10:48:27 -0700 Message-ID: To: slhomme@matroska.org Cc: cellar@ietf.org Content-Type: multipart/alternative; boundary="000000000000c9287e0572776b86" Archived-At: Subject: Re: [Cellar] AV1 seeking X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 17:48:43 -0000 --000000000000c9287e0572776b86 Content-Type: text/plain; charset="UTF-8" Sorry for the delay in responding. See more comments below. On Wed, Jul 18, 2018 at 8:36 AM Steve Lhomme wrote: > Hi Cyril, > > Thanks for clarifying some things. > > 2018-07-18 16:59 GMT+02:00 Cyril Concolato : > > > > On Wed, Jul 18, 2018 at 3:43 PM Steve Lhomme > wrote: > >> > >> I asked Cyril Concolato to join the conversation so we can discuss the > >> differences between our current mapping and the ISOBMFF/MP4 one he is > >> working on. > > > > Thanks Steve. > > > > Some comments regarding the previous messages I read in the archives of > this > > list: > > > > "In MP4 they have [initial_presentation_delay_minus_one] in the > > CodecPrivate. I did not understand it so far because it's not found in > > the AV1 spec. But it seems to guarantee that to read frame 'f' you > > need to decode X frame before that one. In our case that would be 5 to > > have at least a decoded." > > [CC] "initial_presentation_delay_minus_one" in the AV1-ISOBMFF is > related to > > the "initial_display_delay" in the AV1 codec spec. They express the same > > delay but in different units: the latter expresses it in number of > decoded > > frames, while the former expresses it in number of presented frames. The > > reason for this difference is that an application may not be able to know > > when a frame is not decoded it only sees when it is output. > > That said, this delay is not at all related to the seeking feature. It > tells > > you how many frames have to be decoded (or output) to guarantee smooth > > playback if the decoder decodes at the decode rate of the level > indicated in > > the bitstream. It may be useful for low latency applications. > > OK but it is a duplicate value from the Sequence Header OBU may (or > may not) be found in the configOBU. [CC] This is not exactly a duplicate as it is expressed with a different unit but yes they should convey the same information. > Maybe it would be worth having a > specific atom just for that ? And you have either this atom or the one > with a Sequence Header OBU but not both. > [CC] The current syntax already allows that without boxing it. But I do think there is a value for a player to have the file format one even if the Sequence Header one is present, given that they are in different units. Otherwise, the player has to do the conversion. > > There are many [initial_display_delay_minus_1] values in a single > Sequence Header OBU. So I assume the value stored in MP4 is the > maximum value ? IMO it should be said in the document. > [CC] There are multiple values if scalability is used, which is not covered specifically by the current spec. Plus, unless it has changed in the base AV1 spec, the first value is assumed to be the recommended one. But I agree this could be clarified in the spec. > > Also in what cases a Sequence Header OBU would not be found in the > configOBU ? [CC] Just like for AVC you have avc3 or HEVC hev1. In Live Scenarios, you might not know in advance the exact configuration you are going to produce, yet you want to generate the initialization segment. > IMO it should be specified. We may have the same > requirement but it seems better to me to always have one. It helps > knowing the profile of the codec to initiate the decoder instance. > [CC] In the case of local file playback, you have the first sample so you have the codec. In the case of Adaptive Streaming, you have 'codecs' parameter that can help. > Otherwise we need to wait for the actual data when playback has > already started (along with audio and subtitles). > [CC] Not necessarily if you have a manifest or a MIME type. Cyril > > > "IMO this is a bad design because it mixes the container with the codec > > (something done in the past in ogg with bad results). Seeking should > > not ask the codec how it should be done. Also that means to mux such > > an MP4 you'd need to scan the whole source first to verify the value > > is correct or that information needs to be given to the muxer by the > > encoder/packetizer (this information is not found in the stream)." > > [CC] I don't understand what this means. > > Ogg is notorious for tying the container and the codec data. You can't > know the timestamp from just reading ogg, you need to know the codec > and analyse the data inside. So if seeking in AV1-in-ISOBMFF required > the demuxer to parse the "initial_presentation_delay_minus_one" data > would be a bit similar. But as you explained, it's not the case. > > >> > >> > >> IMO there are two main differences for now: > >> > >> - initial_presentation_delay_present / > >> initial_presentation_delay_minus_one which we may or may not store > >> (and where does it come from) > > > > [CC] Hope it's clearer. > > Yes > > >> - the configOBU that may be completely empty, whereas in our case we > >> have exactly one Sequence Header OBU and the ones in the Segment must > >> be very close to that one. > > > > [CC] The intent of the AV1-ISOBMFF spec is that the Sequence Header OBU > has > > to be present in-band and may be present in the configOBU and if present > > shall be identical. In your spec, I don't understand what "very close > > means". AV1 does not allow variation of Sequence Header within a CVS. > > "Very close" was in my email but that's not the wording in the > MKV/WebM mapping. In that document there is this CVS documentation: > > "A Coded Video Sequence is a sequence of video frames where the > contents of [sequence_header_obu] must be bit-identical for all the > Sequence Header OBUs found in the bitstream before Matroska > encapsulation except for the contents of [operating_parameters_info]." > > [operating_parameters_info] is allowed to change in a CVS in our case. > This is the same as found in the AV1 specification 7.5 Ordering of > OBUs: > > "Sequence header OBUs may appear in any order within a coded video > sequence. Within a particular coded video sequence, the contents of > sequence_header_obu must be bit-identical each time the sequence > header appears except for the contents of operating_parameters_info." > > I suppose by "shall be identical" that's the change that is allowed. > But is there are reason not to put a Sequence Header OBU in the > AV1CodecConfigurationRecord ? In Matroska we advise to strip the > similar ones from the bitstream to save space so that's a direct > benefit of putting it there. But there's also a benefit for playback > (a similar feature is missing from VP9 and causes hardware detection > issues in VLC). > > > > HTH, > > Cyril > > Thanks again. > > >> > >> -- > >> Steve Lhomme > >> Matroska association Chairman > >> > >> _______________________________________________ > >> Cellar mailing list > >> Cellar@ietf.org > >> https://www.ietf.org/mailman/listinfo/cellar > > > > -- > Steve Lhomme > Matroska association Chairman > --000000000000c9287e0572776b86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the delay in responding. See more comments below= .

On Wed, Jul 18, 2018 a= t 8:36 AM Steve Lhomme <slhomme@= matroska.org> wrote:
Hi Cyri= l,

Thanks for clarifying some things.

2018-07-18 16:59 GMT+02:00 Cyril Concolato <cconcolato@netflix.com>:
>
> On Wed, Jul 18, 2018 at 3:43 PM Steve Lhomme <slhomme@matroska.org> wrote: >>
>> I asked Cyril Concolato to join the conversation so we can discuss= the
>> differences between our current mapping and the ISOBMFF/MP4 one he= is
>> working on.
>
> Thanks Steve.
>
> Some comments regarding the previous messages I read in the archives o= f this
> list:
>
> "In MP4 they have [initial_presentation_delay_minus_one] in the > CodecPrivate. I did not understand it so far because it's not foun= d in
> the AV1 spec. But it seems to guarantee that to read frame 'f'= you
> need to decode X frame before that one. In our case that would be 5 to=
> have at least a decoded."
> [CC] "initial_presentation_delay_minus_one" in the AV1-ISOBM= FF is related to
> the "initial_display_delay" in the AV1 codec spec. They expr= ess the same
> delay but in different units: the latter expresses it in number of dec= oded
> frames, while the former expresses it in number of presented frames. T= he
> reason for this difference is that an application may not be able to k= now
> when a frame is not decoded it only sees when it is output.
> That said, this delay is not at all related to the seeking feature. It= tells
> you how many frames have to be decoded (or output) to guarantee smooth=
> playback if the decoder decodes at the decode rate of the level indica= ted in
> the bitstream. It may be useful for low latency applications.

OK but it is a duplicate value from the Sequence Header OBU may (or
may not) be found in the configOBU.
[CC] This is not exact= ly a duplicate as it is expressed with a different unit but yes they should= convey the same information.
=C2=A0
Maybe it would be worth having a
specific atom just for that ? And you have either this atom or the one
with a Sequence Header OBU but not both.
[CC] The curr= ent syntax already allows that without boxing it. But I do think there is a= value for a player to have the file format one even if the Sequence Header= one is present, given that they are in different units. Otherwise, the pla= yer has to do the conversion.
=C2=A0

There are many [initial_display_delay_minus_1] values in a single
Sequence Header OBU. So I assume the value stored in MP4 is the
maximum value ? IMO it should be said in the document.
[CC] There are multiple values if scalability is used, which is not covere= d specifically by the current spec. Plus, unless it has changed in the base= AV1 spec, the first value is assumed to be the recommended one. But I agre= e this could be clarified in the spec.
=C2=A0

Also in what cases a Sequence Header OBU would not be found in the
configOBU ?
[CC] Just like for AVC you have avc3 or HEVC = hev1. In Live Scenarios, you might not know in advance the exact configurat= ion you are going to produce, yet you want to generate the initialization s= egment.
=C2=A0
IMO it should = be specified. We may have the same
requirement but it seems better to me to always have one. It helps
knowing the profile of the codec to initiate the decoder instance.
[CC] In the case of local file playback, you have the first sa= mple so you have the codec. In the case of Adaptive Streaming, you have = 9;codecs' parameter that can help.=C2=A0=C2=A0
=C2=A0
Otherwise we need to wait for the actual data when playback has
already started (along with audio and subtitles).
[CC]= Not necessarily if you have a manifest or a MIME type.


Cyril

=C2=A0

> "IMO this is a bad design because it mixes the container with the= codec
> (something done in the past in ogg with bad results). Seeking should > not ask the codec how it should be done. Also that means to mux such > an MP4 you'd need to scan the whole source first to verify the val= ue
> is correct or that information needs to be given to the muxer by the > encoder/packetizer (this information is not found in the stream)."= ;
> [CC] I don't understand what this means.

Ogg is notorious for tying the container and the codec data. You can't<= br> know the timestamp from just reading ogg, you need to know the codec
and analyse the data inside. So if seeking in AV1-in-ISOBMFF required
the demuxer to parse the "initial_presentation_delay_minus_one" d= ata
would be a bit similar. But as you explained, it's not the case.

>>
>>
>> IMO there are two main differences for now:
>>
>> - initial_presentation_delay_present /
>> initial_presentation_delay_minus_one which we may or may not store=
>> (and where does it come from)
>
> [CC] Hope it's clearer.

Yes

>> - the configOBU that may be completely empty, whereas in our case = we
>> have exactly one Sequence Header OBU and the ones in the Segment m= ust
>> be very close to that one.
>
> [CC] The intent of the AV1-ISOBMFF spec is that the Sequence Header OB= U has
> to be present in-band and may be present in the configOBU and if prese= nt
> shall be identical. In your spec, I don't understand what "ve= ry close
> means". AV1 does not allow variation of Sequence Header within a = CVS.

"Very close" was in my email but that's not the wording in th= e
MKV/WebM mapping. In that document there is this CVS documentation:

"A Coded Video Sequence is a sequence of video frames where the
contents of [sequence_header_obu] must be bit-identical for all the
Sequence Header OBUs found in the bitstream before Matroska
encapsulation except for the contents of [operating_parameters_info]."=

[operating_parameters_info] is allowed to change in a CVS in our case.
This is the same as found in the AV1 specification 7.5 Ordering of
OBUs:

"Sequence header OBUs may appear in any order within a coded video
sequence. Within a particular coded video sequence, the contents of
sequence_header_obu must be bit-identical each time the sequence
header appears except for the contents of operating_parameters_info."<= br>
I suppose by "shall be identical" that's the change that is a= llowed.
But is there are reason not to put a Sequence Header OBU in the
AV1CodecConfigurationRecord ? In Matroska we advise to strip the
similar ones from the bitstream to save space so that's a direct
benefit of putting it there. But there's also a benefit for playback (a similar feature is missing from VP9 and causes hardware detection
issues in VLC).


> HTH,
> Cyril

Thanks again.

>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>>
>> _______________________________________________
>> Cellar mailing list
>> Cellar@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/cellar



--
Steve Lhomme
Matroska association Chairman
--000000000000c9287e0572776b86-- From nobody Thu Aug 2 14:31:45 2018 Return-Path: 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 DC5D3130F52 for ; Thu, 2 Aug 2018 14:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 ktlfJohldjeL for ; Thu, 2 Aug 2018 14:31:32 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 A6135130E20 for ; Thu, 2 Aug 2018 14:31:32 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id n85-v6so2500730qke.8 for ; Thu, 02 Aug 2018 14:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5h5DlP9X6/MNVse1CpZ6rpSx1ySByZWkGTQGs6QnoBw=; b=Ra8WxV3h9D2jyGJDaQvJDAiyjpOlIoPszvyZPnSAovLftlHxi0wNDozoSWqSX9rezy HGvfnnhsB47OGwDbh935uGglrvaNQgP5lB9G1FvUVZpJM612+ce9wpZBFvpOySa4GTcC 0wEYNQm+p0qHY85Uk4zXDoeJInkjt0jYnokeg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5h5DlP9X6/MNVse1CpZ6rpSx1ySByZWkGTQGs6QnoBw=; b=U6ENMHxfbswBa+cg3Z61S7ungpq79DHyehRieQ4qZHzFxGIcMWgIQxox3E91r0K04B RnilDxKurSxBiuUy7bI8wuCRwK4phEDReMjaY5BAvp7Zq6tuY24g53IMbXOPD2E0OH9i iSUICLtNUkUXivP3qeIQ3EuHQXCcfD/n9bY+DT32U/2AIpPjl2+1XVlCh5jVYJ21gfLo NTSbh5Psb2+Sz2OP3Z0TgMpFeEWie7e3OI6DmTQ+gxdGJTcQa+4ZUjJj8iTZcwrctK2f 3/TucahqgREuSaAhyJytF4r+60aU5QMPScB+LdSuYVQOHZT2CaerW5gIqTtvy1e8PhrP uF7Q== X-Gm-Message-State: AOUpUlGg0E4KBX4mCOeQ/YRe+U2ssCPAOcRjLV/EakXc3PUk2BJ1o9gw fzgKG1MY2B/6SZ87oNc6SUWnTftcMcd02HolO+aRYg== X-Google-Smtp-Source: AAOMgpfnE8NPhKqZg6ke8D7rqbL9Cw8pcvl13LDfD7vA6ZjCDIxsZc7wLse+TJOIqD+KwLp5d5dNH8Kp1PZQp4Bd9zw= X-Received: by 2002:a37:7a46:: with SMTP id v67-v6mr1162429qkc.188.1533245491535; Thu, 02 Aug 2018 14:31:31 -0700 (PDT) MIME-Version: 1.0 References: <62c29889-49f5-6634-049a-a2d73315bb3c@googlemail.com> <4ff1f1f8-3b66-e229-7884-c851dae8e2e0@googlemail.com> <7d95865e-0314-ee21-640d-69ea29cf4716@googlemail.com> In-Reply-To: <7d95865e-0314-ee21-640d-69ea29cf4716@googlemail.com> From: Cyril Concolato Date: Thu, 2 Aug 2018 14:31:20 -0700 Message-ID: To: andreas.rheinhardt@googlemail.com Cc: cellar@ietf.org Content-Type: multipart/alternative; boundary="000000000000e0945705727a888a" Archived-At: Subject: Re: [Cellar] AV1 seeking X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 21:31:43 -0000 --000000000000e0945705727a888a Content-Type: text/plain; charset="UTF-8" Hi Andreas, Thank you for your detailed, helpful comments. See below for my responses. On Thu, Jul 19, 2018 at 1:47 AM Andreas Rheinhardt < andreas.rheinhardt@googlemail.com> wrote: > Hello Cyril, > > thanks for joining us here. > > Cyril Concolato: > > "In MP4 they have [initial_presentation_delay_minus_one] in the > > CodecPrivate. I did not understand it so far because it's not found in > > the AV1 spec. But it seems to guarantee that to read frame 'f' you > > need to decode X frame before that one. In our case that would be 5 to > > have at least a decoded." > > [CC] "initial_presentation_delay_minus_one" in the AV1-ISOBMFF is related > > to the "initial_display_delay" in the AV1 codec spec. They express the > same > > delay but in different units: the latter expresses it in number of > decoded > > frames, while the former expresses it in number of presented frames. The > > reason for this difference is that an application may not be able to know > > when a frame is not decoded it only sees when it is output. > > That said, this delay is not at all related to the seeking feature. It > > tells you how many frames have to be decoded (or output) to guarantee > > smooth playback if the decoder decodes at the decode rate of the level > > indicated in the bitstream. It may be useful for low latency > applications. > > > That confirms what I have been thinking all along. But nevertheless I > have some questions (My interest stems from the fact that I am in favour > of including a field indicating how many frames need to be decoded in > advance): > > 1. What exactly is the "display model verification algorithm" that the > AV1-ISOBMFF speaks about? Does this just mean that the bitstream so > constructed should be tested whether it fulfills the requirements of > annex E of the AV1 specification? > [CC] That text was written when the base AV1 spec was still moving and Annex E did not exist. Yes, this is related to the decoder model, but not the full model with its buffer constraints, just the display one. The idea is that if you set a value smaller than 10 (max theoretical bound) you can guarantee that a decoder that decodes at the limit of the decoding rate given in the level will be able to present all the frames as intended, at their presentation time. > > 2. If yes, then how can one test this precisely? > [CC] There were discussions in AOM about extending the software for that but I'm not sure of the latest status. > > a) There are two operating modes in annex E.3: Resource availability > mode and decoding schedule mode. The latter mode needs > buffer_removal_time values for the check; but these values SHOULD have > been removed from the bitstream when muxing into ISOBMFF so this can in > general not be checked with the ISOBMFF file alone. Is it intended that > the muxer checks this during muxing when the original file with the > original values are still available or not? > Or do you just test this in resource availability mode. For the resource > availability mode equal_picture_interval equal should have been set to 1 > (i.e. crf video), but E.3.1 also says "If the parameters listed above > are not specified by the bitstream, the parameters necessary to input > into this model can be signaled by the application or some other means." > I have not found that this crf requirement is in any way necessary. Are > you simply using the timestamps derived from the ISOBMFF file (even if > vfr) and use them to check in resource availability mode? > [CC] These are good points. Thank you for raising them. Again, initially there was only the equivalent of the "resource availability mode". This should be clarified. Also, as indicated in the AV1-ISOBMFF, the timing of frames is given by the ISOBMFF structures not by inband values: "The presentation times of AV1 samples are given by the ISOBMFF structures. The timing_info_present_flag in the Sequence Header OBU (in the configOBUs field or in the associated samples) SHOULD be set to 0. If set to 1, the timing_info structure of the Sequence Header OBU, the frame_presentation_time and buffer_removal_time fields of the Frame Header OBUs, if present, SHALL be ignored for the purpose of timed processing of the ISOBMFF file." and this is true for validating the value of initial_presentation_delay as indicated: "set the frame_presentation_time field of the frame header of each presentable frame such that it matches the presentation time difference between the sample carrying this frame and the previous sample (if it exists, 0 otherwise)". I will try to make that clearer. > > b) If one has verified that one can use a value of k for > initial_presentation_delay_minus_one, is this value also automatically > applicable for starting the presentation at any RAP (or at least any > keyframe/non-delayed RAP because -- after all, discarding the samples in > front of a keyframe RAP should give a conformant bitstream)? The answer > is of course tautologically true if "display model verification > algorithm" includes checking presentation from every RAP onwards, but > the current spec proposal talks only about constructing a (singular) > hypothetical bitstream consisting of all the OBUs in the sample entry > followed by all OBUs in all the samples. > The reason I am asking this are bitstreams like this one (everything > inside square brackets forms a temporal unit; &x means that a showable > frame x is output via the show_existing_frames mechanism (if I am not > mistaken, then it is allowed to output frames more than once -- and it > might even make sense to do this at the beginning if there are several > static frames at the beginning which sometimes happens with logos/black > frames)): > [A] [B] [&B] [C] [D E] [&D] > A is a keyframe RAP, B an ordinary frame that is allowed to be output > more than once. And it is output more than once. C is another > non-delayed keyframe. One can start presentation as soon as one has A > decoded (assuming the decoder can decode one frame during the > presentation time of one frame): > When one reaches the temporal unit [B], one has already decoded B. One > can decode C while B is shown. > When one reaches [&B], one has of course B still available. When one > shows B a second time, one can decode D. This effectively means that > when one starts at the very beginning, one enters the second CVS with > two frames already decoded (as if one started decoding at C with > initial_display_delay_minus_1 set to 1) and therefore one can use > temporal units like [D E] with more than one frame to decode. > In the above bitstream, one could use > initial_presentation_delay_minus_one equal to zero for presentation from > the beginning, but for decoding from C onwards one would need a value of 1. > [CC] The AV1 spec has changed at the last minute regarding the ability to output a given frame multiple times. The published version allows it only for non-key-frames. That said, your analysis seems right (as B is a non-keyframe). As you note, the current text mentions constructing a single bitstream, but that might not be useful enough because it does not give you any information about what to do when starting at a subsequent RAP. I see 2 options: a) the text could be changed to apply the procedure at every RAP leading to the max value over all CVS being used but that might introduce latency in generating the file or in generating multiple sample entries (one per set of CVS with a different value); or b) instead of signaling this delay in the sample entry, we need to be able to associate a value with each CVS start (i.e. sample groups). Thoughts? > > 3. a) The ISOBMFF specs contain the clause: "set the first > initial_display_delay_minus_1 field of each Sequence Header OBU to the > number of frames contained in the first > initial_presentation_delay_minus_one + 1 samples," > Is this really intended? Shouldn't it read: "set the first > initial_display_delay_minus_1 field of each Sequence Header OBU to the > number of frames - 1 contained in the first > initial_presentation_delay_minus_one + 1 samples," > After all initial_display_delay_minus_1 includes a minus 1, too; without > the minus 1 one would have to decode the first frame of the sample > number initial_presentation_delay_minus_one + 1 (zero-based), too, > before the presentation can start. > [CC] Good catch! Let's make sure we agree on some examples: a) all TU are made of a single frame with show_frame=1 and all frames take the same amount of time to be decoded and the timing is CFR. In this case, there is a guarantee that you can present all frames at their presentation time after the first frame has been decoded. So initial_display_delay_minus_1 = 0. Given that all TU are made of 1 frame, initial_presentation_delay_minus_one = 0. b) There is one non-showable frame in the sequence and one TU has 2 frames. So initial_display_delay_minus_1 = 1. If the first TU contains 2 frames, then you can set initial_presentation_delay_minus_one = 0. If the second TU contains 2 frames, then you can set initial_presentation_delay_minus_one = 1 (the number of frames in the first 2 TUs will be 3, so initial_display_delay_minus_1 will hypothetically be set to 2 which is greater than the correct value (1), so this is fine). if another TU contains the 2 frames, then you can set initial_presentation_delay_minus_one = 1 (and in this case the hypothetical value of initial_display_delay_minus_1 will match the minimum theoretical value). Do we agree? > b) If one has a compliant AV1 bitstream where the Sequence Headers all > include the initial_display_delay_minus_1 for every operating point, > [CC] First, they don't need to syntactically include it, we can assume the values are known. Then, as indicated in my previous response, the current text assumes only 1 operating point and if not, takes the first one. then one can use the maximum of all these initial_display_delay_minus_1 > as initial_presentation_delay_minus_one if my above corrections turns > out to be right and is accepted? (If it's not accepted, then one could > even use the first the maximum - 1, couldn't one?) > [CC] I think there are two points here: - the variation across CVSs: I agree taking the maximum would work but as indicated above this could introduce latency and I'm wondering if signaling at the CVS level is not preferable - the value of initial_presentation_delay_minus_one depends on the value of initial_display_delay_minus_1 but also on the distribution of the frames in TUs. In the following cases, initial_display_delay_minus_1 is constant but initial_presentation_delay_minus_one differs [A] [b c d] [e] [f] [&c] [&b]: initial_display_delay_minus_1 = 2 because once c has been decoded you can display A while decoding d and the rest will be decoded/presented correctly. initial_presentation_delay_minus_one = 1 because c is decoded when the decoding TU [b c d] outputs d. [A] [b] [c] [d e f] [&d] [&e]: initial_display_delay_minus_1 = 2 because once c has been decoded, you present A while decoding d, present b while decoding e and present c while decoding f and the rest will follow, but initial_presentation_delay_minus_one = 2 because c is decoded in the 3rd TU. Cyril --000000000000e0945705727a888a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andreas,

Thank you f= or your detailed, helpful comments. See below for my responses.
=


On Thu, Jul = 19, 2018 at 1:47 AM Andreas Rheinhardt <andreas.rheinhardt@googlemail.com> wrote:
Hello Cyril,

thanks for joining us here.

Cyril Concolato:
> "In MP4 they have [initial_presentation_delay_minus_one] in the > CodecPrivate. I did not understand it so far because it's not foun= d in
> the AV1 spec. But it seems to guarantee that to read frame 'f'= you
> need to decode X frame before that one. In our case that would be 5 to=
> have at least a decoded."
> [CC] "initial_presentation_delay_minus_one" in the AV1-ISOBM= FF is related
> to the "initial_display_delay" in the AV1 codec spec. They e= xpress the same
> delay but in different units: the latter expresses it in number of dec= oded
> frames, while the former expresses it in number of presented frames. T= he
> reason for this difference is that an application may not be able to k= now
> when a frame is not decoded it only sees when it is output.
> That said, this delay is not at all related to the seeking feature. It=
> tells you how many frames have to be decoded (or output) to guarantee<= br> > smooth playback if the decoder decodes at the decode rate of the level=
> indicated in the bitstream. It may be useful for low latency applicati= ons.
>
That confirms what I have been thinking all along. But nevertheless I
have some questions (My interest stems from the fact that I am in favour of including a field indicating how many frames need to be decoded in
advance):

1. What exactly is the "display model verification algorithm" tha= t the
AV1-ISOBMFF speaks about? Does this just mean that the bitstream so
constructed should be tested whether it fulfills the requirements of
annex E of the AV1 specification?
[CC] That text was w= ritten when the base AV1 spec was still moving and Annex E did not exist. Y= es, this is related to the decoder model, but not the full model with its b= uffer constraints, just the display one. The idea is that if you set a valu= e smaller than 10 (max theoretical bound) you can guarantee that a decoder = that decodes at the limit of the decoding rate given in the level will be a= ble to present all the frames as intended, at their presentation time.=C2= =A0=C2=A0

=C2=A0

2. If yes, then how can one test this precisely?
[CC] = There were discussions in AOM about extending the software for that but I&#= 39;m not sure of the latest status.
=C2=A0

a) There are two operating modes in annex E.3: Resource availability
mode and decoding schedule mode. The latter mode needs
buffer_removal_time values for the check; but these values SHOULD have
been removed from the bitstream when muxing into ISOBMFF so this can in
general not be checked with the ISOBMFF file alone. Is it intended that
the muxer checks this during muxing when the original file with the
original values are still available or not?
Or do you just test this in resource availability mode. For the resource availability mode equal_picture_interval equal should have been set to 1 (i.e. crf video), but E.3.1 also says "If the parameters listed above<= br> are not specified by the bitstream, the parameters necessary to input
into this model can be signaled by the application or some other means.&quo= t;
I have not found that this crf requirement is in any way necessary. Are
you simply using the timestamps derived from the ISOBMFF file (even if
vfr) and use them to check in resource availability mode?
<= div>
[CC] These are good points. Thank you for raising them. Again, ini= tially there was only the equivalent of the "resource availability mod= e". This should be clarified. Also, as indicated in the AV1-ISOBMFF, t= he timing of frames is given by the ISOBMFF structures not by inband values= :
"The presentation times of AV1 samples are given by the IS= OBMFF structures. The timing_info_present_flag in the Sequence Header OBU (= in the configOBUs field or in the associated samples) SHOULD be set to 0. I= f set to 1, the timing_info structure of the Sequence Header OBU, the frame= _presentation_time and buffer_removal_time fields of the Frame Header OBUs,= if present, SHALL be ignored for the purpose of timed processing of the IS= OBMFF file."

and this is true for validating = the value of initial_presentation_delay as indicated:
"set t= he frame_presentation_time field of the frame header of each presentable fr= ame such that it matches the presentation time difference between the sampl= e carrying this frame and the previous sample (if it exists, 0 otherwise)&q= uot;.=C2=A0=C2=A0

I will try to make that clearer.=
=C2=A0

b) If one has verified that one can use a value of k for
initial_presentation_delay_minus_one, is this value also automatically
applicable for starting the presentation at any RAP (or at least any
keyframe/non-delayed RAP because -- after all, discarding the samples in front of a keyframe RAP should give a conformant bitstream)? The answer
is of course tautologically true if "display model verification
algorithm" includes checking presentation from every RAP onwards, but<= br> the current spec proposal talks only about constructing a (singular)
hypothetical bitstream consisting of all the OBUs in the sample entry
followed by all OBUs in all the samples.
The reason I am asking this are bitstreams like this one (everything
inside square brackets forms a temporal unit; &x means that a showable<= br> frame x is output via the show_existing_frames mechanism (if I am not
mistaken, then it is allowed to output frames more than once -- and it
might even make sense to do this at the beginning if there are several
static frames at the beginning which sometimes happens with logos/black
frames)):
[A] [B] [&B] [C] [D E] [&D]
A is a keyframe RAP, B an ordinary frame that is allowed to be output
more than once. And it is output more than once. C is another
non-delayed keyframe. One can start presentation as soon as one has A
decoded (assuming the decoder can decode one frame during the
presentation time of one frame):
When one reaches the temporal unit [B], one has already decoded B. One
can decode C while B is shown.
When one reaches [&B], one has of course B still available. When one shows B a second time, one can decode D. This effectively means that
when one starts at the very beginning, one enters the second CVS with
two frames already decoded (as if one started decoding at C with
initial_display_delay_minus_1 set to 1) and therefore one can use
temporal units like [D E] with more than one frame to decode.
In the above bitstream, one could use
initial_presentation_delay_minus_one equal to zero for presentation from the beginning, but for decoding from C onwards one would need a value of 1.=
[CC] The AV1 spec has changed at the last minute rega= rding the ability to output a given frame multiple times. The published ver= sion allows it only for non-key-frames. That said, your analysis seems righ= t (as B is a non-keyframe). As you note, the current text mentions construc= ting a single bitstream, but that might not be useful enough because it doe= s not give you any information about what to do when starting at a subseque= nt RAP. I see 2 options: a) the text could be changed to apply the procedur= e at every RAP leading to the max value over all CVS being used but that mi= ght introduce latency in generating the file or in generating multiple samp= le entries (one per set of CVS with a different value); or b) instead of si= gnaling this delay in the sample entry, we need to be able to associate a v= alue with each CVS start (i.e. sample groups). Thoughts?

=C2=A0

3. a) The ISOBMFF specs contain the clause: "set the first
initial_display_delay_minus_1 field of each Sequence Header OBU to the
number of frames contained in the first
initial_presentation_delay_minus_one + 1 samples,"
Is this really intended? Shouldn't it read: "set the first
initial_display_delay_minus_1 field of each Sequence Header OBU to the
number of frames - 1 contained in the first
initial_presentation_delay_minus_one + 1 samples,"
After all initial_display_delay_minus_1 includes a minus 1, too; without the minus 1 one would have to decode the first frame of the sample
number initial_presentation_delay_minus_one + 1 (zero-based), too,
before the presentation can start.
[CC] Good catch!
Let's make sure we agree on some examples:
a) all TU = are made of a single frame with show_frame=3D1 and all frames take the same= amount of time to be decoded and the timing is CFR. In this case, there is= a guarantee that you can present all frames at their presentation time aft= er the first frame has been decoded. So initial_display_delay_minus_1 =3D 0= . Given that all TU are made of 1 frame, initial_presentation_delay_minus_o= ne =3D 0.
b) There is one non-showable frame in the sequence and = one TU has 2 frames. So initial_display_delay_minus_1 =3D 1.=C2=A0
If the first TU contains 2 frames, then you can set initial_presentation_= delay_minus_one =3D 0.
If the second TU contains 2 frames, then y= ou can set initial_presentation_delay_minus_one =3D 1 (the number of frames= in the first 2 TUs will be 3, so initial_display_delay_minus_1 will hypoth= etically be set to 2 which is greater than the correct value (1), so this i= s fine).
if another TU contains the 2 frames, then you can set in= itial_presentation_delay_minus_one =3D 1 (and in this case the hypothetical= value of initial_display_delay_minus_1 will match the minimum theoretical = value).
Do we agree?=C2=A0


b) If one has a compliant AV1 bitstream where the Sequence Headers all
include the initial_display_delay_minus_1 for every operating point,
[CC] First, they don't need to syntactically include it,= we can assume the values are known.=C2=A0
Then, as indicated in = my previous response, the current text assumes only 1 operating point and i= f not, takes the first one.=C2=A0

then one can use the maximum of all these initial_display_delay_minus_1
as initial_presentation_delay_minus_one if my above corrections turns
out to be right and is accepted? (If it's not accepted, then one could<= br> even use the first the maximum - 1, couldn't one?)
[CC] I think there are two points here:
- the variation across C= VSs: I agree taking the maximum would work but as indicated above this coul= d introduce latency and I'm wondering if signaling at the CVS level is = not preferable
- the value of initial_presentation_delay_minus_on= e depends on the value of initial_display_delay_minus_1 but also on the dis= tribution of the frames in TUs.
In the following cases, initial_d= isplay_delay_minus_1 is constant but initial_presentation_delay_minus_one d= iffers
[A] [b c d] [e] [f] [&c] [&b]: initial_display_del= ay_minus_1 =3D 2 because once c has been decoded you can display A while de= coding d and the rest will be decoded/presented correctly. initial_presenta= tion_delay_minus_one =3D 1 because c is decoded when the decoding TU [b c d= ] outputs d.=C2=A0
[A] [b] [c] [d e f] [&d] [&e]: initial= _display_delay_minus_1 =3D 2 because once c has been decoded, you present A= while decoding d, present b while decoding e and present c while decoding = f and the rest will follow, but initial_presentation_delay_minus_one =3D 2 = because c is decoded in the 3rd TU.=C2=A0

Cyril
--000000000000e0945705727a888a-- From nobody Thu Aug 2 15:10:46 2018 Return-Path: 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 7E555130E1E for ; Thu, 2 Aug 2018 15:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netflix.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 o8LXfxvhcath for ; Thu, 2 Aug 2018 15:10:43 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 68E5E130DC2 for ; Thu, 2 Aug 2018 15:10:43 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id z8-v6so4109440qto.9 for ; Thu, 02 Aug 2018 15:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FgsEcT6XpSfl5Knu26oQmsIdgEjjfiz4tISkh/tqA8A=; b=iqrULM2NfmNoe+NKgMie625fo4IsOLGOJwNU7wMwCrCwidVOchHE98/0PNHEmqmfKD 6G7UIr3WizeXJVXlb6jqspSJEEfju7NN/Q4MluNjxd2uW2rG/JwjEW5k8XRiXLqmGvoI vw+zCR01fhJ3UKuchhzHPSuMkKmBuBaBFcaOk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FgsEcT6XpSfl5Knu26oQmsIdgEjjfiz4tISkh/tqA8A=; b=fNA6hVjg6fKgrMEae5YvyZM4wN9xK1mUEMKh6Zc9XGPaHANBQDhYaAniTfmj4E42Mg 3gFkEWOJZz44E4ovRVPnGpiSPKUf3akDpeSTXNXS0iKJPpw1Tugmxbrr1eXnFsD/3QUo fokDnArBafvVowYm7GDq+hZ2NbKt5iaeRTt5ETi0xDLv0zhQyWUuYee93jW4qThPkkN9 DumA1Z0BJMdo0p+1hmD2OmEaBizjRrdSa+XHn36vrlQrw3KESimzEiN9f60lCYDUFaVj EGFguZRYWNYw/sGOu2vBQiCZMQ42wQeJAH4RjLm0s5Ufk3rovZCF+eKH05RxpDlGJM0V EgeQ== X-Gm-Message-State: AOUpUlGJCLIDG325PHb0NjthHzUHEnRQK8nnlBTdj90mZKpiW7i4N8Hg abs1qEkENkUyS6O4p8dLnryhVL82t6FYJoKSOHHVYA== X-Google-Smtp-Source: AAOMgpfZGPBVOeHtpU0sYvgvr1ScJmi8c5bWvU2WzKp9KV9m8Af3oki3l96IH8AccC5e45ddn7jbDYpdmjejuCXcqsg= X-Received: by 2002:ac8:809:: with SMTP id u9-v6mr1315580qth.303.1533247842463; Thu, 02 Aug 2018 15:10:42 -0700 (PDT) MIME-Version: 1.0 References: <336a1f43-e223-dc57-78f7-ad1f88e7d488@googlemail.com> In-Reply-To: <336a1f43-e223-dc57-78f7-ad1f88e7d488@googlemail.com> From: Cyril Concolato Date: Thu, 2 Aug 2018 15:10:31 -0700 Message-ID: To: andreas.rheinhardt@googlemail.com Cc: cellar@ietf.org Content-Type: multipart/alternative; boundary="00000000000000dd3505727b15ee" Archived-At: Subject: Re: [Cellar] AV1 init X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 22:10:45 -0000 --00000000000000dd3505727b15ee Content-Type: text/plain; charset="UTF-8" On Thu, Jul 19, 2018 at 6:04 AM Andreas Rheinhardt < andreas.rheinhardt@googlemail.com> wrote: > > "If an OBU is not the last OBU in a `Block`, it MUST follow the [Low > Overhead Bitstream Format syntax] (i.e. it MUST have > [obu_has_size_field] set to 1); the last OBU in a `Block` MAY have > [obu_has_size_field] set to 0, in which case it is assumed to fill the > remainder of the `Block`." > [CC] Just wanted to clarify one possible misunderstanding here. The Low Overhead Bitstream Format is the one specified in Section 5.2 of AV1, by opposition to the other length-delimited format specified in Annex B. The LOBF allows obu_has_size_field to be set to 1 or 0. The "it MUST follow the [Low Overhead Bitstream Format syntax] (i.e. it MUST have [obu_has_size_field] set to 1)" is misleading here. You might want to rephrase. Cyril --00000000000000dd3505727b15ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Jul 19, 2018 at 6:04 AM Andreas Rheinhardt <andreas.rheinhardt@googlemail.com> wrote:=

"If an OBU is not the last OBU in a `Block`, it MUST follow the [Low Overhead Bitstream Format syntax] (i.e. it MUST have
[obu_has_size_field] set to 1); the last OBU in a `Block` MAY have
[obu_has_size_field] set to 0, in which case it is assumed to fill the
remainder of the `Block`."
[CC] Just wanted to cl= arify one possible misunderstanding here. The Low Overhead Bitstream Format= is the one specified in Section 5.2 of AV1, by opposition to the other len= gth-delimited format specified in Annex B. The LOBF allows obu_has_size_fie= ld to be set to 1 or 0. The "it MUST follow the [Low Overhead Bitstrea= m Format syntax] (i.e. it MUST have [obu_has_size_field] set to 1)" is= misleading here. You might want to rephrase.

Cyri= l
--00000000000000dd3505727b15ee-- From nobody Mon Aug 6 00:02:14 2018 Return-Path: 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 3BB2C130DDE for ; Mon, 6 Aug 2018 00:02:13 -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 uLpyOe9oBo0t for ; Mon, 6 Aug 2018 00:02:06 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 AB8E6128CE4 for ; Mon, 6 Aug 2018 00:02:06 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id b11-v6so6402994pfo.3 for ; Mon, 06 Aug 2018 00:02:06 -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=4FtaVxGchse2b3rKYArOGYnSaoMaRxy1LJjRcdGWzoU=; b=VmzuJUBtBo34t6/pxoSKFDuqg6f0scWNbO3uuD+bNKUniKFDFyylH5obqwF7ptdNGE dw6U1cLCDo0Zbh37w0pYl4eUFxGg1W46EtLMAba+ey+RDTcWqDi64sN8dmJARjQO69jL xNf1qA/mBEFRKY+5b1eV2KLakwczCH47kfhbqefozHTnLqc2Ohx4a6uLETPEo+PO6raZ K4jRnAADR0YsdcXUMSGJ0atUxuquxvD9h+xixh0nYTB16QzLuLxrX8+rTjJzUXeng+kM JKXGGas6oZwi0E+paHkbbY/3I22AvpkMG2xSMv6Di336lqzE8Ti216Z9b4fgobKFm6J5 GcEg== 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=4FtaVxGchse2b3rKYArOGYnSaoMaRxy1LJjRcdGWzoU=; b=GGPCgxhph9WlHCTJrxdEp7GI5ji8hz2WtIRKt2TvRBvzIBJh+g0i/X29c1yWH/T8lm rVq9JWQrD9byLUsNqPSFNgeb4pTyzayVp3zPVUgbBQ5h1q+0yKjkYBOWo3z/pBAKg2gZ OuNgvJIm2ewKJkiafxqBYd3xtbLO8tGNHWmDdvQEHCkQcPdckvjYign76TJZuDMgM8xC IcPx7nMAJQAcQrwc1tuutlKZlhrWLa0nwOnaer5c1enqs/SiDhdOyMyVW2o2i37GG0CA RWI9TV0ITuesWYuE2NEGyyIMHX0WdvYZn1bMLqovc0As1Zv1afU6hLFFT48lIS9kuG5d zqBg== X-Gm-Message-State: AOUpUlEQjdMrp0klGtqqfKihk5Fu6rlZfem3LM46SAPlQA0Z8PnR9FGy jVDMgbkC0uqcjexgTQP+PJtpi4YgT1vU96nOmuH1h74+5gs= X-Google-Smtp-Source: AAOMgpcfaGgzsfwkURxfIlgHEAo/ayuVtubALio1NK74NfmyoYQxIzSfMUvWQJcCWvuMn/pl8lnSbuGpgtQ3togIplc= X-Received: by 2002:a62:8d16:: with SMTP id z22-v6mr15826757pfd.181.1533538926277; Mon, 06 Aug 2018 00:02:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9c13:0:0:0:0 with HTTP; Mon, 6 Aug 2018 00:02:05 -0700 (PDT) In-Reply-To: References: <62c29889-49f5-6634-049a-a2d73315bb3c@googlemail.com> <4ff1f1f8-3b66-e229-7884-c851dae8e2e0@googlemail.com> From: Steve Lhomme Date: Mon, 6 Aug 2018 09:02:05 +0200 Message-ID: To: Cyril Concolato Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] AV1 seeking X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 07:02:13 -0000 2018-08-02 19:48 GMT+02:00 Cyril Concolato : > Sorry for the delay in responding. See more comments below. No problem, >> IMO it should be specified. We may have the same >> requirement but it seems better to me to always have one. It helps >> knowing the profile of the codec to initiate the decoder instance. > > [CC] In the case of local file playback, you have the first sample so you > have the codec. In the case of Adaptive Streaming, you have 'codecs' > parameter that can help. But that's the problem. At least with libavcodec it selects the hardware or software decoder after the first frame is parsed. But at this point you already set the number of threads it can use (usually a lot), except this is incompatible with the hardware decoders (there are some workarounds but it still lead to HW performance issues). This can be avoided by knowing the profile before libavcodec is initialized. This is possible for all known codec except for VP9 which doesn't have extradata, and we can't know if we need to use the 8 bits decoder or the 10 bits decoder. I would like to avoid this as much as possible. Especially since 12 bits HW support might not be widespread. But at least I know each bit depth will be a different decoder in the hardware. >> Otherwise we need to wait for the actual data when playback has >> already started (along with audio and subtitles). > > [CC] Not necessarily if you have a manifest or a MIME type. Relying on metadata outside a file to play a file is usually not a good idea (which one has precedence when both information are found and not equal). But I understand it's a common use case for adaptive streaming. It just doesn't work for every other use case. From nobody Mon Aug 13 02:05:48 2018 Return-Path: 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 4DD47130E96 for ; Mon, 13 Aug 2018 02:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 moUPd-44EmLq for ; Mon, 13 Aug 2018 02:05:44 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ADF8130E91 for ; Mon, 13 Aug 2018 02:05:43 -0700 (PDT) Received: from [IPv6:2001:4bca:200:ce91:58d7:590f:9d18:2] ([2001:4bca:110b:9291:58d7:590f:9d18:2]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Mon, 13 Aug 2018 11:05:41 +0200 id 000000000000016A.000000005B7149E5.00002273 To: Codec Encoding for LossLess Archiving and Realtime transmission From: "Peter B." Message-ID: <78a980a9-af56-0f4e-acc1-ecdbe710bb6a@das-werkstatt.com> Date: Mon, 13 Aug 2018 11:05:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Cellar] FFV1 Profiles? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 09:05:46 -0000 Hi all :) I was recently asked for "profiles" for FFV1/MKV (for preservation). So I think this would be the right place to discuss good parameter options for different profiles, that can then be implemented e.g. as Mediaconch policy, as well as maybe also in FFmpeg? Here's my suggestion for FFV1 profiles, and I'd be very happy to hear about your opinions: ## Preservation:   * GOP=1   * FFV1 version 3   * SliceCRC=1   * Slices=24 ## IMLS (Intermediate Lossless):   * GOP=1   * FFV1 version 3   * SliceCRC=0   * Slices=24 I didn't put pix_fmt, aspect ratio or framerate in there, because I'd say it should be kept as-is, if possible (why not?). So I'm not speaking about format normalization ;) As you see, I've also not put coder/context in there yet, since I must admit I'm not 100% sure about when to choose which. For >8 bpc it does matter though. So what do you think about this? Thanks in advance and nice greetings, Peter PS: I'll post another mail regarding possible profile definitions for MKV. From nobody Mon Aug 13 02:24:23 2018 Return-Path: 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 E1490130E9A for ; Mon, 13 Aug 2018 02:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 BXAsc9O4Jw1n for ; Mon, 13 Aug 2018 02:24:19 -0700 (PDT) Received: from 9.mo173.mail-out.ovh.net (9.mo173.mail-out.ovh.net [46.105.72.44]) (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 65EA1128B14 for ; Mon, 13 Aug 2018 02:24:19 -0700 (PDT) Received: from player730.ha.ovh.net (unknown [10.109.143.109]) by mo173.mail-out.ovh.net (Postfix) with ESMTP id 2BD74D1108 for ; Mon, 13 Aug 2018 11:24:17 +0200 (CEST) Received: from [192.168.2.120] (p3EE2DA18.dip0.t-ipconnect.de [62.226.218.24]) (Authenticated sender: jerome@mediaarea.net) by player730.ha.ovh.net (Postfix) with ESMTPSA id 170114400B5 for ; Mon, 13 Aug 2018 11:24:16 +0200 (CEST) To: cellar@ietf.org References: <78a980a9-af56-0f4e-acc1-ecdbe710bb6a@das-werkstatt.com> From: Jerome Martinez Message-ID: <300f5186-34a8-17b3-68fe-89cfa1c775fd@mediaarea.net> Date: Mon, 13 Aug 2018 11:24:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <78a980a9-af56-0f4e-acc1-ecdbe710bb6a@das-werkstatt.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 5638506733699534993 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtjedrudefgdduiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] FFV1 Profiles? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 09:24:22 -0000 On 13/08/2018 11:05, Peter B. wrote: > Hi all :) > > I was recently asked for "profiles" for FFV1/MKV (for preservation). > > So I think this would be the right place to discuss good parameter > options for different profiles, that can then be implemented e.g. as > Mediaconch policy, as well as maybe also in FFmpeg? > > > Here's my suggestion for FFV1 profiles, and I'd be very happy to hear > about your opinions: > > ## Preservation: >   * GOP=1 >   * FFV1 version 3 >   * SliceCRC=1 >   * Slices=24 > > ## IMLS (Intermediate Lossless): >   * GOP=1 >   * FFV1 version 3 >   * SliceCRC=0 >   * Slices=24 > > I didn't put pix_fmt, aspect ratio or framerate in there, because I'd > say it should be kept as-is, if possible (why not?). > So I'm not speaking about format normalization ;) > > As you see, I've also not put coder/context in there yet, since I must > admit I'm not 100% sure about when to choose which. For >8 bpc it does > matter though. > > > So what do you think about this? IMO profiles word should be used for something similar to other formats, i.e. a set of features that a decoder must support, with increasing level of difficulty for the decoder. and the only difference between the 2 suggested profiles is only a feature not difficult to implement, so it may be in all decoders. I consider the suggestions more as encoding policies, which should not be indicated in the FFV1 bitstream, maybe as MediaConch suggested policy && FFmpeg option for setting all in 1 option. Example: a profile should indicate that up to 24 slices must be supported by the decoder, not that there must be 24 slices (this is a user policy, not a decoder constraint). I don't see obvious features to remove in a decoder, maybe the support of GOP not 1 (more work for keeping the status of the decoder between 2 frames), chroma subsampling, RGB (additional transformation step), aspect ratio in all slices not same (this "feature" is actually not supported by any decoder AFAIK)... list of supported pix_fmt is also an issue, but this is not easy because the list is long (vs other formats). then I think more about "levels" indicating max count of slices, width/height/frame rate i.e. max count of pixels per second... From nobody Mon Aug 13 07:12:56 2018 Return-Path: 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 72B37130EF1 for ; Mon, 13 Aug 2018 07:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 vUoA0kY7CGNP for ; Mon, 13 Aug 2018 07:12:54 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D423C130E79 for ; Mon, 13 Aug 2018 07:12:53 -0700 (PDT) Received: from [IPv6:2001:4bca:200:ce91:58d7:590f:9d18:2] ([2001:4bca:110b:9291:58d7:590f:9d18:2]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Mon, 13 Aug 2018 16:12:51 +0200 id 0000000000000071.000000005B7191E3.000008B5 To: cellar@ietf.org References: <78a980a9-af56-0f4e-acc1-ecdbe710bb6a@das-werkstatt.com> <300f5186-34a8-17b3-68fe-89cfa1c775fd@mediaarea.net> From: "Peter B." Message-ID: Date: Mon, 13 Aug 2018 16:12:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <300f5186-34a8-17b3-68fe-89cfa1c775fd@mediaarea.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] FFV1 Profiles? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 14:12:55 -0000 On 13/08/18 11:24, Jerome Martinez wrote: > I consider the suggestions more as encoding policies, which should not > be indicated in the FFV1 bitstream, maybe as MediaConch suggested > policy && FFmpeg option for setting all in 1 option. Yes! That's exactly what I meant. Sorry for the confusion :D Cheers, Peter From nobody Thu Aug 16 05:54:20 2018 Return-Path: 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 A7CA4130E67 for ; Thu, 16 Aug 2018 05:54:19 -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 aKDmkJWhjHBm for ; Thu, 16 Aug 2018 05:54:17 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 D9A8B126DBF for ; Thu, 16 Aug 2018 05:54:17 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id p12-v6so2006871pfh.2 for ; Thu, 16 Aug 2018 05:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=idBqHnJSjXYQGhYGmNxSUE1BqJ/vWEYRMHk+BtgkisU=; b=eOlWpJqkuce3Uw2NYSBJHJTQ7yn/RDiu7gJRfCM/xoOZXvhGQ9bT1BpUx/lGG90WLn 0ff6jQWOKqAz02pHOuXamFRwd0jusBc0KFD3mkxigya6skMzXy4/InT4VNKSb2kOg0TV 2Q33H+N1dfhzr7P1xJmgc8SccihQLysSPG70pmfxPWibdWvMCKRTgBTgih1AlX61Im2+ Tp/Uihj3FR/KnScozXjqZHXzySHftkpnjITLLY6iUQZcA2B4uK5hM09VR7IBPi/Hcjx0 LnbehdkEo7M1V39cB1x6C/497FFmJCQx2R+G+8EimjPKHIxYdBLkWQBAT4iFQEaPMVk3 KWAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=idBqHnJSjXYQGhYGmNxSUE1BqJ/vWEYRMHk+BtgkisU=; b=rshNP0rXNHam0HhqadIvGKQBRl+8ttKU61xHUMVq3woPzWWKPQplk1jS8pvJ4yO1th cmV3e5z3s1NJohJmGmVqkMA8mOBYlsDExftg0mijTM+7jRskFDBK+kHL1TfZODa/A7ma TZk0Y/19Z17r1d8EqrNWsOtgKuAtIDG0zM0Vl5j5J/2zVnBS0iP9kqdgrj4SNBThSS8k hOgUqZDO49hNLb4RreD2WGiyflzJk4c+BEasOunXVlkvwXOFVRUIuBosIrhrGAt5hVMw wLOcL3savoWLE03KamBZiC6Ya2wAAMsumOhZv2fOIsZGjJiyzFFEC4VG0gJDI717GNgA kgaw== X-Gm-Message-State: AOUpUlE/+xygN10VIeKNx3tVlJ6os7wO0NaRM88vuWVzvG5akF5CbgBq m6QeA6g6DBqDtSUHUIAJecac2JoPYGGkZ5Zd6mcrBdgyh7/bAA== X-Google-Smtp-Source: AA+uWPzbCppQREiyTOuBXQU6GCqVNEEt/1Ap7XOPE2IBnJO53IZ15PqduVohtNUMrCRVUahjFDdbSOM8ylNIEBv2Jh4= X-Received: by 2002:aa7:8118:: with SMTP id b24-v6mr32118684pfi.78.1534424057152; Thu, 16 Aug 2018 05:54:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9c13:0:0:0:0 with HTTP; Thu, 16 Aug 2018 05:54:16 -0700 (PDT) From: Steve Lhomme Date: Thu, 16 Aug 2018 14:54:16 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] AV1 update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 12:54:20 -0000 As the work on the ISOBMFF produced many welcome changes I updated the current draft for Matroska. The main changes include: - use the structure from AV1CodecConfigurationRecordv1 in CodecPrivate so we can identify the codec variant precisely before starting playback. - not include any OBU anymore in the CodecPrivate. They are already found in the Blocks and the data that would have been useful are already in the CodecPrivate structure or the metadata in the Matroska fields. - separate the mandatory TrackEntry elements from the others and separate the ones which value come from the Sequence Header OBU, the metadata OBUs or other fields. - add the notion of CVS Sequence Header OBU which corresponds to all a Sequence Header OBU where all the bits are equal for the whole duration of the Coded Video Sequence. Seeking is now straightforward to Keyframes/BlockGroup with no ref. The rest remains undefined territory. But we don't omit and reinject any OBU. As always the current draft can be found here: https://github.com/Matroska-Org/matroska-specification/blob/av1-mappin/codec/av1.md -- Steve Lhomme Matroska association Chairman From nobody Thu Aug 16 06:54:23 2018 Return-Path: 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 B6E26130F75 for ; Thu, 16 Aug 2018 06:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 JgBzSaqh4P5f for ; Thu, 16 Aug 2018 06:54:12 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B754E130F46 for ; Thu, 16 Aug 2018 06:54:12 -0700 (PDT) Received: from [IPv6:2001:4bca:200:ce91:58d7:590f:9d18:2] ([2001:4bca:110b:9291:58d7:590f:9d18:2]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 16 Aug 2018 15:54:10 +0200 id 000000000000005B.000000005B758202.00006716 From: "Peter B." To: Codec Encoding for LossLess Archiving and Realtime transmission References: <78a980a9-af56-0f4e-acc1-ecdbe710bb6a@das-werkstatt.com> Message-ID: Date: Thu, 16 Aug 2018 15:54:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <78a980a9-af56-0f4e-acc1-ecdbe710bb6a@das-werkstatt.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] FFV1 encoding policies (was "FFV1 Profiles") X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 13:54:20 -0000 Hi everyone :) In order to define useful encoding policies for FFV1: Any suggestions regarding the encoding options for "coder" and "context" for different sources? For example: coder X performs better on VHS source, but coder Y for DigiBeta, DV, etc. In my initial tests (2010), large context resulted in better compression for VHS. What are your experiences in that regard? Thank you very much in advance, Peter From nobody Wed Aug 22 19:52:01 2018 Return-Path: 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 DBCC1130DD6 for ; Wed, 22 Aug 2018 19:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 jvB_9IzA-r91 for ; Wed, 22 Aug 2018 19:51:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9EF130DCC for ; Wed, 22 Aug 2018 19:51:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 13F16208D1 for ; Wed, 22 Aug 2018 23:09:44 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8F55A3015; Wed, 22 Aug 2018 22:51:55 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8CF68CC for ; Wed, 22 Aug 2018 22:51:55 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] DRAFT minutes from July 31 virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 02:52:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable INFO: https://datatracker.ietf.org/meeting/interim-2018-cellar-03/session= /cellar WEBEX: Meeting number: 313 505 170 Meeting password: dq64cWsm Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dme21026faa14be85507cdef66b= 860014e Host key: 763872 Audio connection: 1-650-479-3208 Call-in toll number (US/Canada) Slides: https://docs.google.com/presentation/d/1iotL3RR_cgb_dmUWd0RvGi39= 9d2hvNPTkR6a49RF5c4/edit?usp=3Dsharing (slides do not say anything that isn't below) Attendees: 1. Michael Richardson (mcr) 2. Kieran O'Leary 3. Martin Below 4. J=C3=A9r=C3=B4me Martinez 5. Dave Rice (call-in user 2) 6. Steve Lhomme 7. Ashley Blewer 8. Tim Terriberry Regrets: 1. Andrew Weaver (last minute issue) 2. Michael Niedermayer 3. Moritz Bunkus 4. Agenda: 1. Note Well. 2. Draft minutes from Last meeting. https://www.ietf.org/mail-archive/web/cellar/current/msg01505.html 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual03?useMonospac= eFont=3Dtrue https://datatracker.ietf.org/meeting/interim-2018-cellar-01/material= s/minutes-interim-2018-cellar-01-201805292000 2b) Roll call - as listed above. 4. Any updates from IETF102. - Tim only person at IETF102 - GENART review. Matt spent over a month of effort on the review!!! Please take a good look at the comments. - Link to Matt Miller's review - https://mailarchive.ietf.org/arch/msg/cellar/671YjBEqo-vdtrHdUebAp= fu7t_8 - Pull request from Dave, responding to pretty much all his comments.... there are a few suggestions that were not adopted, = but that was due to it being controversial. - Biggest part that is still pending, lots of pseudo-code, was looking for more narative, and there were concerns about conflicts... How to read the pseudo-code out loud while communicating it to another person. Added "as-read"... - DR looking for experience with other RFCs, looking for other - examples of pseudo-code with narative. ACTION: mcr to ask for advice. (DONE) - RFC6716 has good points in the first half (up to section 4.2), and the second half was not as well received. - FFV1 --- Dave to review 6716, Jerome to do some markup on current code. 5. EBML document status. How to get this into WG Last Call. - explanation of what it is. - 8 issues open, 4 are "feature requests" for a future revision, 4 are small issues with pull requests outstanding. - Link to IANA considerations thread - https://www.ietf.org/mail-archive/web/cellar/current/msg01601.html - EBML Header has TLV Element with Document Type. ElementID=3Dxxx. - EBML Header Document Type needs a registry for Document Types: what is= the amending - EBML header ElementIDs should have an update rule that says IETF Stand= ards Action to update, (and version must be > 1). https://tools.ietf.org/html/rfc8126 <- different rules. 6. Milestones for WG. Proposed changes: Jul 2018 Adopt matroska specifications as WG documents Aug 2018 Submit specification for EBML to IESG (Standards Trac= k) Oct 2018 Adopt flac specifications as WG documents not yet enough work on this? most work has been making the document more RFC-like. wait for Andrew Weaver to comment on this. Oct 2018 Submit informational specification for FFV1 video cod= ec versions 0, 1 and 3 to IESG for publication draft-ietf-cellar-ffv1 -> just needs as-read narative to be sorted out. -> implies WGLC for mid-September. Dec 2019 Submit specification for FFV1 video codec version 4 to= IESG (Standards Track) xxx 2019 Submit informational specification for Matroska contai= ner format versions 1, 2 and 3 to IESG for publication xxx 2019 Submit specification for FLAC audio codec to IESG (Sta= ndards Track) draft-xiph-cellar-flac xxx 2019 Submit specification for Matroska container format version 4 to IESG (Standards Track) draft-lhomme-cellar-matroska Do we need another WG document for AV1 codec? Would be ready as soon as we settle with MP4.... (iso-bmmf) (How does AV1 go into MP4, and how it goes into Matroska) Why would we need another document, rather than use the CODEC registry in m= atroska? SL: there are more details than fit, and maybe each codec needs a document to explain how it fits in. DR: Recommend we add av1 to CODEC registry in matroska as well SL: agrees What would be appropriate values for xxx above? (for now,= April 2019) 7. responses/plan to address GENART review of ffv1. ACTION: - pseudo-code vs narative. - IANA registries and values for EBML Header vs Document. - update milestones. - new document for AV1. (SL) - Add AV1 to CODEC registry. - =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlt+IUsACgkQgItw+93Q 3WUyyggAjwMHTTrNiV4c18ERXNDSWNNQ+6NTqzrc6c6vmejNAiqjbnOip6d04fGK lBgLye1cvD38VkSFa5vFq0KbjFzf2Msruc96l/ChwkipkAc0K1YLaoYW1xJSzl4N /XYP1r25KFPPu5pvdGhbuAHOdoyfFal82wP7+JaYI0OapypmnL8obJOzMpW/vzNG F8/TFqkJskk2esVTiTb7A01ggAgrKleEfDM8ZFG29sHxwisip4R4ICFGnMt1E7ra fmiBrCycWU98Y+rDJnpi4VUi5GrFgiCoTfh7MyEe0BhvFTiH/8wCIV12Mev/d7sv K1rZgXkr/gYdcVwEVp20olk6W8tfBQ== =3Boh -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 22 19:55:33 2018 Return-Path: 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 B7A03130DCC for ; Wed, 22 Aug 2018 19:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 itXm046XjxOW for ; Wed, 22 Aug 2018 19:55:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0D5129C6B for ; Wed, 22 Aug 2018 19:55:30 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A40D3208D1 for ; Wed, 22 Aug 2018 23:13:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2B4903015; Wed, 22 Aug 2018 22:55:29 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 28895CC for ; Wed, 22 Aug 2018 22:55:29 -0400 (EDT) From: Michael Richardson to: cellar@ietf.org In-Reply-To: <3571.1534992715@localhost> References: <3571.1534992715@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] DRAFT minutes from July 31 virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 02:55:32 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > - DR looking for experience with other RFCs, looking for other - > examples of pseudo-code with narative. ACTION: mcr to ask for > advice. (DONE) The advice I got from other documents was not very consistent. A question I asked was whether the pseudo-code or the narrative would be normative, and different people had different views, and some just didn't see any issue about whether there was conflict or not. Some went as far as to just throw python into their document, and declared it normative! [One assumes the code is free of bugs.] -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlt+IiAACgkQgItw+93Q 3WX7Pwf+NnOrbjzH3QyVMme+ofiQDwZEImQgw030kWfcTKJ+2W1yj1SbINiwKtIT P/wQ4V5fseg8P7fXLbQPtbFVa+CDV0f+hbunpVTqWvEQdoOGbGKUuxoMfilXK8+3 NRSDhGTy7ftcvaSrHIMHd9OJ8VDXYV8M2Y8I4FxkWlAcLtrs+1u8aBkFhjpnuQOH bDu7c1abDwq7RFkJHDY+bnjRZFrmyl+/cKiI1lnnYOb57lW7fI9FjYCG7dbBRUu5 AeOzP7ZJrlJi9ioWYttY8KJNEACFUyaUR9A/X6FVTSh6QLMXlHpMcP86o72M3CXO HOjVobBKca8iotj0/19NHAfO+jtr3Q== =BOwU -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 22 20:00:26 2018 Return-Path: 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 7C2E2130DCC for ; Wed, 22 Aug 2018 20:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 i_UxjNveBWg0 for ; Wed, 22 Aug 2018 20:00:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C139D129C6B for ; Wed, 22 Aug 2018 20:00:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 89701208D1 for ; Wed, 22 Aug 2018 23:18:10 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0FB613015; Wed, 22 Aug 2018 23:00:22 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0D677CC for ; Wed, 22 Aug 2018 23:00:22 -0400 (EDT) From: Michael Richardson to: cellar@ietf.org In-Reply-To: <3571.1534992715@localhost> References: <3571.1534992715@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] Action Items resulting from July 31 virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 03:00:25 -0000 --=-=-= Content-Type: text/plain One, how to get these two: > 2. Michael Niedermayer > 3. Moritz Bunkus to the virtual interim meeting. > 4. Any updates from IETF102. - Tim only person at IETF102 - GENART > review. Matt spent over a month of effort on the review!!! Please > take a good look at the comments. Will we have a revised draft for next week with the GENART comments acted upon? > - Link to Matt Miller's review - > https://mailarchive.ietf.org/arch/msg/cellar/671YjBEqo-vdtrHdUebApfu7t_8 > - Pull request from Dave, responding to pretty much all his > comments.... there are a few suggestions that were not adopted, but > that was due to it being controversial. > - Biggest part that is still pending, lots of pseudo-code, was > looking for more narative, and there were concerns about > conflicts... How to read the pseudo-code out loud while communicating > it to another person. Added "as-read"... I'm leaving this here. Could we try something and post a new ID, and see how we like the result? > - FFV1 --- Dave to review 6716, Jerome to do some markup on > current code. Noting this here. > 5. EBML document status. How to get this into WG Last Call. - > explanation of what it is. - 8 issues open, 4 are "feature requests" > for a future revision, 4 are small issues with pull requests > outstanding. Can we get the authors to communicate to close the pull requests? > 6. Milestones for WG. Proposed changes: Jul 2018 Adopt matroska Our AD has not yet approved the proposed milestones changes. I think that we will have to have another go at getting the IANA Considerations worked out for the set of documents. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlt+I0UACgkQgItw+93Q 3WVLKQf/YgM7WqrSuiK9A7Qs/Cad5KFI9xSKwbqnc5H467cGv+cnTmPrwxcaLn8b xZwqggUBQSfBiDm6HmQFO5feQn7tOvEepTDAznoFuyyoUUJ8FJNpFIrc1ixtxmqx PTENvCl5BSffUBbfCTbxCx3EY0nXdyGScMhzaXgnPOuIi6A4IN1IKoBuYDsV0REv RZbWSfnISMAx2Y2utfspcr+FFbBLzw3hD0tHaUqgWQbZ3rFYY3FiV4Pa3wuvm/DI O7UKiNgQ6J8mnd/yh2uLzdl+E6zHqw+vF1lyFEB4JQilujQRVMlJ1F1P098Kwp1e W97Mlb53wXmGZuSMlpIW//qiItMdVg== =hRow -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 22 23:03:55 2018 Return-Path: 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 9E566128BAC for ; Wed, 22 Aug 2018 23:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 mdRzSJQ9AajC for ; Wed, 22 Aug 2018 23:03:52 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 2E525124C04 for ; Wed, 22 Aug 2018 23:03:51 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w7N63ios003064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 23 Aug 2018 08:03:44 +0200 Received: from Castor.local (dynamic.wline.6rd.res.cust.swisscom.ch [IPv6:2a02:1205:34e2:bed0:8896:9bec:d3f2:df24] (may be forged)) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w7N63hnU015569 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 23 Aug 2018 08:03:44 +0200 Date: Thu, 23 Aug 2018 08:03:44 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: <4580.1534992929@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-Mailer: Braille 0.5 (c) 1982 by Reto Kromer, Poschiavo, Switzerland X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] DRAFT minutes from July 31 virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 06:03:55 -0000 Michael Richardson wrote: >A question I asked was whether the pseudo-code or the narrative >would be normative, and different people had different views, >and some just didn't see any issue about whether there was >conflict or not. I refrain that in my personal opinion the pseudo-code should be normative, because it's more precise than plain English. In case of conflict, the pseudo-code should be considered (until the conflict is resolved, of course). >Some went as far as to just throw python into their document, >and declared it normative! [One assumes the code is free of >bugs.] I did suggest to use a C skeleton here. (I cannot remember now who said "Everything will be C in the end. If it=E2=80=99s not C, it=E2=80= =99s not the end." during #32c3 ;-) Best regards, Reto From nobody Thu Aug 23 05:53:49 2018 Return-Path: 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 3BE92130DC8 for ; Thu, 23 Aug 2018 05:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 wykyCAfQTZzX for ; Thu, 23 Aug 2018 05:53:45 -0700 (PDT) Received: from 9.mo69.mail-out.ovh.net (9.mo69.mail-out.ovh.net [46.105.56.78]) (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 B7329130DC0 for ; Thu, 23 Aug 2018 05:53:45 -0700 (PDT) Received: from player792.ha.ovh.net (unknown [10.109.146.137]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id 54E6225B75 for ; Thu, 23 Aug 2018 14:53:42 +0200 (CEST) Received: from [192.168.2.120] (p3EE2D347.dip0.t-ipconnect.de [62.226.211.71]) (Authenticated sender: jerome@mediaarea.net) by player792.ha.ovh.net (Postfix) with ESMTPSA id 498A7A00BC for ; Thu, 23 Aug 2018 14:53:42 +0200 (CEST) To: cellar@ietf.org References: <3571.1534992715@localhost> <4580.1534992929@localhost> From: Jerome Martinez Message-ID: Date: Thu, 23 Aug 2018 14:53:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4580.1534992929@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 12562228210705567889 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtjedrfeefgdehfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] DRAFT minutes from July 31 virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 12:53:48 -0000 On 23/08/2018 04:55, Michael Richardson wrote: > A question I asked was whether the pseudo-code or the narrative would be > normative, and different people had different views, and some just didn't see > any issue about whether there was conflict or not. In the case of FFV1, an additional argument about having the pseudo-code as normative is that it was the one extracted from the reference decoder. Additionally, the pseudo-code was used by the implementation of another decoder (used for confirming that the pseudo-code is fine) i.e. it is the most tested part. > > Some went as far as to just throw python into their document, and declared > it normative! [One assumes the code is free of bugs.] Here, as we describe the state of an encoder/decoder already in the wild, bugs found in the code would be normative ;-). (this is actually already the case, we have 2 exceptions listed in the doc, when we found that the draft of spec was not in sync with the reference encoder/decoder). So IMO for this case (FFV1), the pseudo-code should be normative. This would not be new at IETF, RFC 6716 is "worse" and says "The primary normative part of this specification is provided by the source code in Appendix A", so I suggest to add the a similar paragraph, replacing "source code" by "pseudo-code". Jérôme From nobody Thu Aug 23 06:00:33 2018 Return-Path: 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 23027130DD0 for ; Thu, 23 Aug 2018 06:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 bRr2esXAbbAk for ; Thu, 23 Aug 2018 06:00:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCD0130DC8 for ; Thu, 23 Aug 2018 06:00:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AE95020090; Thu, 23 Aug 2018 09:18:15 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C4CF91448; Thu, 23 Aug 2018 09:00:25 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C2834127A; Thu, 23 Aug 2018 09:00:25 -0400 (EDT) From: Michael Richardson To: Jerome Martinez cc: cellar@ietf.org In-Reply-To: References: <3571.1534992715@localhost> <4580.1534992929@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Thu, 23 Aug 2018 09:00:25 -0400 Message-ID: <764.1535029225@localhost> Archived-At: Subject: Re: [Cellar] DRAFT minutes from July 31 virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 13:00:31 -0000 Jerome Martinez wrote: > On 23/08/2018 04:55, Michael Richardson wrote: >> A question I asked was whether the pseudo-code or the narrative would >> be normative, and different people had different views, and some just >> didn't see any issue about whether there was conflict or not. > In the case of FFV1, an additional argument about having the > pseudo-code as normative is that it was the one extracted from the > reference decoder. Additionally, the pseudo-code was used by the > implementation of another decoder (used for confirming that the > pseudo-code is fine) i.e. it is the most tested part. Then let's declare the pseudo-code as normative here. >> Some went as far as to just throw python into their document, and >> declared it normative! [One assumes the code is free of bugs.] > Here, as we describe the state of an encoder/decoder already in the > wild, bugs found in the code would be normative ;-). (this is actually > already the case, we have 2 exceptions listed in the doc, when we found > that the draft of spec was not in sync with the reference > encoder/decoder). > So IMO for this case (FFV1), the pseudo-code should be normative. This > would not be new at IETF, RFC 6716 is "worse" and says "The primary > normative part of this specification is provided by the source code in > Appendix A", so I suggest to add the a similar paragraph, replacing > "source code" by "pseudo-code". Good. From nobody Fri Aug 24 11:55:59 2018 Return-Path: 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 7FD66130E1F for ; Fri, 24 Aug 2018 11:55:58 -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 4IZwnal3UTd6 for ; Fri, 24 Aug 2018 11:55:56 -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 4C3D2130E1E for ; Fri, 24 Aug 2018 11:55:52 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 1C148C024B for ; Fri, 24 Aug 2018 18:55:52 +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 rpNdukJUIDn8 for ; Fri, 24 Aug 2018 18:55:52 +0000 (UTC) Received: from [10.252.25.71] (unknown [63.245.221.198]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id E602DC01F2 for ; Fri, 24 Aug 2018 18:55:51 +0000 (UTC) To: cellar@ietf.org References: <3571.1534992715@localhost> <4580.1534992929@localhost> From: "Timothy B. Terriberry" Message-ID: Date: Fri, 24 Aug 2018 11:55:51 -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: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] DRAFT minutes from July 31 virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 18:55:59 -0000 Jerome Martinez wrote: > This would not be new at IETF, RFC 6716 is "worse" and says "The primary > normative part of this specification is provided by the source code in > Appendix A", so I suggest to add the a similar paragraph, replacing > "source code" by "pseudo-code". Just as a historical comment, the approach taken in RFC 6716 was chosen explicitly for time-to-market reasons, not because it was a better way to write a standard, and my understanding of the current IETF opinion of that choice is that it was a mistake that should not be repeated. So you may not want to rely on this argument. That's not to say your current choice is a bad one, but you should focus on the part where it's "better" and RFC 6716 is "worse". From nobody Sun Aug 26 05:26:26 2018 Return-Path: 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 9E2271294D0 for ; Sun, 26 Aug 2018 05:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org 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 Joeu9e1hn1f9 for ; Sun, 26 Aug 2018 05:26:23 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 7ACA81277CC for ; Sun, 26 Aug 2018 05:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2017070101; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=KwH/a/QxL5RmbyFXRV/U7HTS2MnWA28liykGAWfKVMU=; b=T8nPQr6sCy4+P0N4SSofOqG+dQDFisFPNe+n0hW9ZonVJQRoUoKQv2imKoqFu2TZGKXQYmzBCwKnVVZUwNZvfbBbdacaCrO40+twezY8ycpWsgyDIfg2zDaRBmLwpl2nkvHf/sXJM8zutUArnYSF+nKVOp2tzZikBZM7FUUyE45TyyZIHmSHIDZhVShUYq2O3NAHjswLbGF4pUSG2hSfVUXxpb0ow5vZHQ1WLvICpl7N+RRc6pcWrNwFTenoTzz/A4iy9sbyFKS2INOc7fcpfLDsDGTL1LnyjhJQ/PEWeXh/cg1HlUqD6wDTuUSrEFblccmjYyk/HLJnCL/7guoo/VlRtpfmVHAcspkNRtV8Xzba0DrMKZWGAdDDyF8h4Eb6AdNZnlCeiHSJ5YC3Yt8Qg9Ci/onHP9X0Iq4V3P39VLHdnMZRyjC4ccEIqnWPS/yWvwxwOVDrvTWq5E47fkEFI3wTQbkzTdqJQOjWlX7OxTsfG8gs72zGKbNb/R11VIZZ5hq2eY/dO/0DtXFjWReXW3PE94xuSYFG2ePOFaXxgwAOaFtSqEC/hxlill4zsa9TvFqGd+a9pAPrRzXZLW4ZvG2dSKwLLho8lnsdazfqU02Om4BHlOCeGdPgHZgpef747a/7REqvM3PEYYmXuoYdYud+A5RYwoUfQjvoKGr2VT0=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:35644) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ftu7V-00045g-0M; Sun, 26 Aug 2018 14:26:17 +0200 X-Virus-Scanned: amavisd-new at bunkus.org Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id D435E6540006; Sun, 26 Aug 2018 14:26:10 +0200 (CEST) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 176CA4464A30; Sun, 26 Aug 2018 14:26:10 +0200 (CEST) User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: Cellar list , help Questions Date: Sun, 26 Aug 2018 14:26:09 +0200 Message-ID: <87efel1fha.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] MKVToolNix v26 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2018 12:26:24 -0000 Hey, time for another release of MKVToolNix, v26.0.0. It's on the smaller side regarding the number of changes. Here are the usual links: =E2=80=A6to the source code: https://mkvtoolnix.download/source.html =E2=80=A6to the binaries: https://mkvtoolnix.download/downloads.html The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available of the course of the next couple of hours. Here are the NEWS since the previous release: ------------------------------------------------------------ # Version 26.0.0 "In The Game" 2018-08-26 ## New features and enhancements * mkvmerge: chapter generation: if the name template given by `--generate-chapters-name-template` is empty, no names (`ChapterDisplay` master elements with `ChapterString`/`ChapterLanguage` children) will be generated for the chapter atoms. Part of the implementation of #2275. * mkvmerge: chapters: chapter names generated from MPLS files will now use = the name template if one is set via `--generate-chapters-name-template`. Part= of the implementation of #2275. * mkvmerge: mkvmerge will no longer abort with an error message if no audio, video and subtitle tracks should be multiplexed. This allows copying of chapters from non-chapter source files (e.g. Matroska or MP4 files). * MKVToolNix GUI: the font size in the tool selector on the left will scale with the font size the user selects in the preferences. * MKVToolNix GUI: the GUI will no longer automatically resize the columns in tree and list views to match the content size. Instead it remembers and restores the widths set by the user. Implements #2353. * MKVToolNix GUI: multiplexer: the chapter name template will now be set automatically to the name template in the preferences' "chapter editor" section. Additionally the option `--generate-chapters-name-template =E2= =80=A6` will be passed to mkvmerge in situations when mkvmerge will generate chapters (either because automatic generation is enabled or if chapters are genera= ted for MPLS playlists). Part of the implementation of #2275. * MKVToolNix GUI: chapter editor: if the chapter name template is empty, chapters will be generated without names. Part of the implementation of #2275. * MKVToolNix GUI: chapter editor: added an option to remove all chapter nam= es to the "additional modifications" dialog. Part of the implementation of #2275. ## Bug fixes * mkvmerge: Matroska reader: fixed wrong timestamps when appending Matroska files where the second Matroska file's first timestamp is bigger than 0. Fixes #2345. * mkvmerge: MP4 reader: fixed division by zero errors during file identification if the timescale is 0 in the `MVHD` atom. * mkvmerge: Windows Television DVR files are now recognized as an unsupport= ed file type. This prevents mis-detection as MPEG-2 with an accompanying flo= od of error messages. Fixes #2347. * MKVToolNix GUI: info tool: under certain circumstances "cues" were shown = at the wrong level (inside the previous master element instead of on level 1). Fixes #2361. * MKVToolNix GUI: job queue: fixed invalid memory handling and consequent crashes when using the "edit in corresponding tool & remove from job queu= e" option if one of the files in that job contained attached files. Fixes #2368. ## Build system changes * An AppStream metadata file will be installed in `$prefix/share/metainfo`. ------------------------------------------------------------ Have fun :) mosu From nobody Sun Aug 26 06:12:36 2018 Return-Path: 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 A8418130DE5 for ; Sun, 26 Aug 2018 06:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, 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 S5PKl9EOlA2U for ; Sun, 26 Aug 2018 06:12:32 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 5787A130DC2 for ; Sun, 26 Aug 2018 06:12:32 -0700 (PDT) Received: from smtp8.infomaniak.ch (smtp8.infomaniak.ch [83.166.132.38]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w7QDCUCM007745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sun, 26 Aug 2018 15:12:30 +0200 Received: from Castor.local (84-73-238-96.dclient.hispeed.ch [84.73.238.96]) (authenticated bits=0) by smtp8.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w7QDCTBA192185 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 26 Aug 2018 15:12:30 +0200 Date: Sun, 26 Aug 2018 15:12:30 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-Mailer: Braille 0.5 (c) 1982 by Reto Kromer, Poschiavo, Switzerland X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: [Cellar] Meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2018 13:12:35 -0000 Hello, is there any meeting this week? (I'll be travelling on Tuesday and on Friday.) Best regards, Reto From nobody Sun Aug 26 17:07:08 2018 Return-Path: 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 2E2DE12DD85 for ; Sun, 26 Aug 2018 17:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 tCKoXWfYJMtk for ; Sun, 26 Aug 2018 17:07:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03081277C8 for ; Sun, 26 Aug 2018 17:07:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3AE302008F; Sun, 26 Aug 2018 20:25:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9D9F3193D; Sun, 26 Aug 2018 20:07:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9B3FB18A5; Sun, 26 Aug 2018 20:07:03 -0400 (EDT) From: Michael Richardson To: Reto Kromer cc: cellar@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] Meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 00:07:07 -0000 --=-=-= Content-Type: text/plain Reto Kromer wrote: > is there any meeting this week? There is, and we are remiss at getting the agenda posted, but it will be at the normal time (2000 UTC). The agenda will be out Monday morning. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluDQKcACgkQgItw+93Q 3WUNbQgAmNKxkgnTdXvRZoUlndNLlFsbFMSS7E14+pBKnDFWdKpQSif+iLbH/JiA MNX2Ke/O1DXIDqbidUG6VsnRd4FQ8pUo4053dw4obANOU4VofgDzNSXp02eXV8Ys Tz1u2GYK9Gr09J7IF1urFRtrP/UxoVoeYZgfAHzUTwEM77VcKePZnN3dzbquxtgG Wg8ZIyrREtLO3dko3/ZeIDCr+Oz75Mg5bRDN6pVUPvZcyHCIQalzlyLm3bdtl1Go akBvbgj+WYzwa4vYpRzyiZxrBc/RUruZjyQdQbtHQWj2q2LGRTbaX5QFkgyaDIM2 jBjzpBSo/kQH4urEyiQqSwC4Hx609g== =HULd -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 27 14:59:21 2018 Return-Path: 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 2548F130E1F for ; Mon, 27 Aug 2018 14:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 IoX8J6nnbFzG for ; Mon, 27 Aug 2018 14:59:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB04130E0C for ; Mon, 27 Aug 2018 14:59:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DA30C20491 for ; Mon, 27 Aug 2018 18:17:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3BAEE33E6; Mon, 27 Aug 2018 17:59:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3813A33E5 for ; Mon, 27 Aug 2018 17:59:15 -0400 (EDT) From: Michael Richardson to: cellar@ietf.org X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] draft Agenda for Virtual Interim meeting August 28, 2018 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 21:59:20 -0000 --=-=-= Content-Type: text/plain CELLAR -- Agenda for Virtual Interim Meeting August 28, 2018 20:00 UTC INFO: https://datatracker.ietf.org/meeting/interim-2018-cellar-04/session/cellar WEBEX: Meeting number: 313 505 170 Meeting password: dq64cWsm Meeting link: https://ietf.webex.com/ietf/j.php?MTID=me21026faa14be85507cdef66b860014e Audio connection: 1-650-479-3208 Call-in toll number (US/Canada) Agenda: 1. Note Well. 2. Draft minutes from Last meeting 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual04?useMonospaceFont=true 2b) Roll call 4. WG status update - milestones submitted. - EBML not in WG last call yet. - 5. Progress on EBML comments and review. - when we can get EBML-05 posted? - 8 issues open, 4 are "feature requests" for a future revision, 4 are small issues with pull requests outstanding. https://github.com/Matroska-Org/ebml-specification/issues/183 https://github.com/Matroska-Org/ebml-specification/issues/182 https://github.com/Matroska-Org/ebml-specification/issues/176 https://github.com/Matroska-Org/ebml-specification/issues/175 https://github.com/Matroska-Org/ebml-specification/issues/164 https://github.com/Matroska-Org/ebml-specification/issues/157 https://github.com/Matroska-Org/ebml-specification/issues/156 https://github.com/Matroska-Org/ebml-specification/issues/48 6. EBML IANA Considerations, REDUX. - Link to IANA considerations thread - https://www.ietf.org/mail-archive/web/cellar/current/msg01601.html - EBML Header has TLV Element with Document Type. ElementID=xxx. - EBML Header Document Type needs a registry for Document Types: what is the amending - EBML header ElementIDs should have an update rule that says IETF Standards Action to update, (and version must be > 1). 7. Any other Business. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluEdDIACgkQgItw+93Q 3WVAwQf+OOMz2WsmZTwTmc/VkEWBXklBwLUFHxrLnqrBerMBea6ECHKOoQ6WD9GH 4Mf7WylzFtlXLA0QpBQrRW0kx6SiUOXqptuX7ilrfz7e3COzj1R6T3vUzD5jzZPK /rpesn32CGy8TLm09GoItKBlKMOmJFBKYcHkL3Y+Xp086FMXR5O48gWDjEmlTFNs +agPXLFz92NMPhTzq7gdysKAiiHUV8HRHF71CWKK48V7A1CvuA8lF6UQK5IvgWWW 4TNuvu7xDISFpLy3zjsq45QE+N+4QZ795roFD6Cx4HILoWw0tE3F8Z9cPAVYgaaE PD2dAQ51p61NkpRqivJiNx8GfFqnyQ== =2kVv -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 27 21:32:49 2018 Return-Path: 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 60FB112D949 for ; Mon, 27 Aug 2018 21:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 s_4fUTvDVbP2 for ; Mon, 27 Aug 2018 21:32:44 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 86FB512008A for ; Mon, 27 Aug 2018 21:32:44 -0700 (PDT) Received: from smtp7.infomaniak.ch (smtp7.infomaniak.ch [83.166.132.30]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w7S4WfLW012451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 28 Aug 2018 06:32:42 +0200 Received: from Castor.local (fix.22.15.195.vtx.ch [195.15.22.68] (may be forged)) (authenticated bits=0) by smtp7.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w7S4WeXI173181 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2018 06:32:41 +0200 Date: Tue, 28 Aug 2018 06:32:38 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-Mailer: Braille 0.5 (c) 1982 by Reto Kromer, Poschiavo, Switzerland X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] draft Agenda for Virtual Interim meeting August 28, 2018 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 04:32:48 -0000 Michael Richardson wrote: >CELLAR -- Agenda for Virtual Interim Meeting >August 28, 2018 20:00 UTC I'm afraid, most probably I'll not be able to join (possibly at=20 the end, at around 20:45 UTC). >5. Progress on EBML comments and review. >- when we can get EBML-05 posted? >- 8 issues open, 4 are "feature requests" for a future revision, 4 are >small issues with pull requests outstanding. [...] >https://github.com/Matroska-Org/ebml-specification/issues/175 "Mine" could be implemented quickly, but is not of urgency. Best regards, Reto From nobody Tue Aug 28 12:06:54 2018 Return-Path: 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 9F888130EC9 for ; Tue, 28 Aug 2018 12:06:53 -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 Wm1LEQ1JuLV3 for ; Tue, 28 Aug 2018 12:06:51 -0700 (PDT) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (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 D8F29127148 for ; Tue, 28 Aug 2018 12:06:51 -0700 (PDT) Received: by mail-pg1-x542.google.com with SMTP id y4-v6so1159834pgp.9 for ; Tue, 28 Aug 2018 12:06:51 -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=ESKTpltcPM4AmFD8zS5qaJakxBrcrk/aLhlfbYdKZmE=; b=cKlgoQT3DgEfCGCRn0/Z/U9BFioiwEz+pUA1tH46CR+S7UqgbGOdbNNJer5tnaDMD1 psK5gkgN4Yb6aolxBT1HTwhPZ60Cg6R2Gy/VARtZ0GwcePpSNwWk2BVsCkupEExpm4o/ iLUxmqJO56ihtlgWplOnmXSXfGY+3ES8oEWzF4pj2U3zEf+iLpLDjb6oOy74i/DZOVKv kKxOHJ8VNph00j6VhqFr8NFgVOw6OZsITASRAbPQMd60hXrKddi7kVR/87qAL2E+TPZt JWK5Je0sOTbw+utZKr9QmczU3CRxXIs8czZgrrCMOWmjO/4FSRKyrsCBUtGZ6oANeId0 cOrQ== 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=ESKTpltcPM4AmFD8zS5qaJakxBrcrk/aLhlfbYdKZmE=; b=b1TQD/mGVe2iKEHHgxcaCMuC7zRf+oPNmrGDf5ZdKfETTAsd2wkds1U7DhveEPPy02 kdqagNacbUUWjLBRhF/wM8SOxJAh3d2nQyMOrRB1NRP1xXtY+1vA+l/nu/yDyzpYOoxe Rz4fPAmFpNK1psjm6FsQaGF0UcyImm72vu/oZvySyvm/C+SJjcuYcVCvUoVv+Lhv3FGq VrFnyRx53+0c9CBxRk6UAQnGY/r6lK8h6xNEzkoOfsbdkuf1lREoOrWrbJWqQo/xQbRQ FcE5xQSA0Hd4RxWaQPLdQfYHweau7G+4DXHc64dSpwhfcSt/sSwEyc8rQvVAS8a/2A3p QiDQ== X-Gm-Message-State: APzg51A36nMNoPfJyS9MVzzsqzfuUm6kat88T+yk/DUPNYa62pKWiiUR yGTnoy7qoYexSErChxQ4XpjgipZweFsBFBPaG3Jmr/Q3 X-Google-Smtp-Source: ANB0Vdb3cJC/QuykXnWvOgDguIM6S2kUR8kyrBk7JRTUIrpM37m2U81XhFrmREHaqWnrXmzMXaMpkUaxo2iQPmAdKlQ= X-Received: by 2002:a63:5c5e:: with SMTP id n30-v6mr2721161pgm.253.1535483211067; Tue, 28 Aug 2018 12:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9c13:0:0:0:0 with HTTP; Tue, 28 Aug 2018 12:06:50 -0700 (PDT) In-Reply-To: <3970.1531804177@localhost> References: <15361.1528336434@localhost> <3970.1531804177@localhost> From: Steve Lhomme Date: Tue, 28 Aug 2018 21:06:50 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] IANA Considerations for EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 19:06:54 -0000 2018-07-17 7:09 GMT+02:00 Michael Richardson : > > Dave Rice wrote: > > I might be mistaken here, but from the draft the process of > > registering an Element ID via IANA only seems interested in the > > Element ID itself. For a curious onlooker of the IANA registrations= it > > might be helpful to see what the associated DocType is so that the > > context and semantics could be understood, otherwise the registrati= on > > only seems to indicate that somewhere someone registered it via > > first-come first-serve. > > I've been reading ebml more deeply in the last two weeks, and I actually = have > significant concerns. I don't really understand what is going on. > > We have a virtual interim on the 31st, and I'd like to discuss this > in person, perhaps. Earlier 1:1 if you think you could help me. > > In particular, I have no idea what the binary format of EBML even is! > I thought I'd just missed the description before... > > > Additionally I think I=E2=80=99d prefer (except for the IDs used by= EBML > > itself) that the combination of DocType and ElementID be required a= s > > unique rather than only the ElementID itself. This seems analogous = to > > how the same node name is allowed in various XML Schemas but don=E2= =80=99t > > necessarily have any relation to one another in semantics. > > That's a choice. > Given 2^35 ElementIDs, I don't see why you'd want to complicate your life > that way. Yes but Class A (1 octet) elements are rare and the most likely to be used for each EBML-based format. Matroska uses a lot of them. That will leave almost none left for the other formats. > > Is it acceptable to extend the IANA Considerations section to clari= fy > > the required information for registrations? From the discussion in = the > > pull request these scenarios seem to be: > > If you want to make the ElementID a function of DocType, then put all the > ElementID allocations into the document that defines that DocType. > > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ > --=20 Steve Lhomme Matroska association Chairman From nobody Tue Aug 28 12:53:55 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3036128CB7; Tue, 28 Aug 2018 12:53:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <153548603361.6102.2784201887692251424@ietfa.amsl.com> Date: Tue, 28 Aug 2018 12:53:53 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ebml-06.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 19:53:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : Extensible Binary Meta Language Authors : Steve Lhomme Dave Rice Moritz Bunkus Filename : draft-ietf-cellar-ebml-06.txt Pages : 40 Date : 2018-08-28 Abstract: This document defines the Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data in a hierarchical form. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ebml-06 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ebml-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ebml-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 28 12:56:25 2018 Return-Path: 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 B7F0C130E05 for ; Tue, 28 Aug 2018 12:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2_VIV2NQuyAJ for ; Tue, 28 Aug 2018 12:56:23 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 E49D9128CB7 for ; Tue, 28 Aug 2018 12:56:22 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id h23-v6so4152476ita.5 for ; Tue, 28 Aug 2018 12:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YvtcwE1/0p8AGRHgIJpO98YALdJK+CivkpiYJVtAKlk=; b=PmQJc63Z13HkZLWnTQJ4pb3BWJcFnsTPPoDs7PWFcaAKJFcilbZzZKsInZlPIfY2/t 1+TIZ6K5e8L/uXWY1YMv9Xc5/4oOkc4H8e21GVHEjMzhCiD85PanbQE8086gvouN+ZBx NMo7OgvJAZ7mvVFQH+qH/6ZPP9s7kkjAanvbslEGKWVK59BVDdOhB+3JNGn2jZSwwgPB ygJwC5E/nmNLZ1/Ap6+rBFYvI4ekCsMvdfhsWlrgQ+wbcUyJSu6obAaTehNYHR6Cr+sp 1eMiovlzo3zoh/NAeykGPDpZ4qnohUNCdjeWOKAVdNFsuyhMJyrbnXqiGrKN95MTvo+i 1OFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YvtcwE1/0p8AGRHgIJpO98YALdJK+CivkpiYJVtAKlk=; b=OF1ktNABnzS5rrKFvm+45l4QVnIYcrAApgJviosaR1A7j5kbluEFIY05sBzCtw9Nz2 CSSShd/q5LDcVD0Qm4MSp2B4bnpn+NL10uLT9zsjwtO/b9isHmKZ4IsrlVKZYo9anx0r c/9fi3KduYWk1AqDUGM7gYj52bu8EAR93XpxRFWPFm9SfrWlkuVS5ejimvwAY6TX6JgN 611TGAIhRGBB8NtNFb80QJouAJbEwuGm1sWMr0ekUO3KWKCy0/HUu4KoI/tas22YdXFR ST2Xbh/ip590w8MS3e3N59zlUrCxaytVmhNR/nCJNA1WIRm3Jqvl3DZkSdo6Ub/yjbkl RH6A== X-Gm-Message-State: APzg51D65CR1k9V6yX3cuBvDRjT6FrJQkvVBoORdcssAJYRxtVkHhBsx +0RP4bpUhXsy5aw9LL7p/sqTi+WWGLneBSSdP07wCA== X-Google-Smtp-Source: ANB0Vda9BH2+KBbaF2VOb3umKHsby6R2HhUWRvnYBYTGqx2qLIiCpZmkYXBOfvyS4vinEYGjD8nO0CytK5vmGER91gc= X-Received: by 2002:a24:5004:: with SMTP id m4-v6mr2894888itb.38.1535486181745; Tue, 28 Aug 2018 12:56:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ashley Blewer Date: Tue, 28 Aug 2018 15:56:10 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000006badf00574843cd0" Archived-At: Subject: Re: [Cellar] draft Agenda for Virtual Interim meeting August 28, 2018 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 19:56:25 -0000 --0000000000006badf00574843cd0 Content-Type: text/plain; charset="UTF-8" Sending my regrets, have to work and cannot be at the meeting today! On Tue, Aug 28, 2018 at 12:32 AM Reto Kromer wrote: > Michael Richardson wrote: > > >CELLAR -- Agenda for Virtual Interim Meeting > >August 28, 2018 20:00 UTC > > I'm afraid, most probably I'll not be able to join (possibly at > the end, > at around 20:45 UTC). > > >5. Progress on EBML comments and review. > >- when we can get EBML-05 posted? > >- 8 issues open, 4 are "feature requests" for a future revision, 4 are > >small issues with pull requests outstanding. > > [...] > > >https://github.com/Matroska-Org/ebml-specification/issues/175 > > "Mine" could be implemented quickly, but is not of urgency. > > Best regards, Reto > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --0000000000006badf00574843cd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sending my regrets, have to work and cannot be at the meet= ing today!

On Tue,= Aug 28, 2018 at 12:32 AM Reto Kromer <= lists@reto.ch> wrote:
Michae= l Richardson wrote:

>CELLAR -- Agenda for Virtual Interim Meeting
>August 28, 2018=C2=A0 =C2=A0 =C2=A0 =C2=A0 20:00 UTC

I'm afraid, most probably I'll not be able to join (possibly at the end,
at around 20:45 UTC).

>5. Progress on EBML comments and review.
>- when we can get EBML-05 posted?
>- 8 issues open, 4 are "feature requests" for a future revisi= on, 4 are
>small issues with pull requests outstanding.

[...]

>https://github.com/Matroska-Org/ebm= l-specification/issues/175

"Mine" could be implemented quickly, but is not of urgency.

Best regards, Reto

_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--0000000000006badf00574843cd0-- From nobody Tue Aug 28 15:20:53 2018 Return-Path: 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 6B665130F25 for ; Tue, 28 Aug 2018 15:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 0NQpgaVBV8IW for ; Tue, 28 Aug 2018 15:20:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F03E130DC9 for ; Tue, 28 Aug 2018 15:20:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1141720491; Tue, 28 Aug 2018 18:38:56 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0490A26DF; Tue, 28 Aug 2018 18:20:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 01CFC11E7; Tue, 28 Aug 2018 18:20:47 -0400 (EDT) From: Michael Richardson To: Steve Lhomme cc: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: <15361.1528336434@localhost> <3970.1531804177@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] IANA Considerations for EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 22:20:52 -0000 --=-=-= Content-Type: text/plain Steve Lhomme wrote: > Yes but Class A (1 octet) elements are rare and the most likely to be > used for each EBML-based format. Matroska uses a lot of them. That > will leave almost none left for the other formats. I think that the way to do this is to have each DocType (such as Matroska) create a new registry for Element IDs used in the DocumentBody. In each of the registries that are created, I think that the Element IDs used/defined in the EBML document should also be reserved. This is just to avoid any confusion. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluFyr8ACgkQgItw+93Q 3WWaYwf+OdN4pbXl3iE/eOXLPItTuBvp6HsLdhlQJkLAJvaS9ilf15b/U7gPO6YY pKhvwvYy2sMVngF/o/9NItDgaEibkxZeaaO9rjLq/CS7P4Lsx53WUH2aczP/oGmA IOZxjyKXbNMv9lEWFRtVGd8Y2WB9gaQXuGKcFRkqeUNl8LntyhmqwVCxas5T9fjN zc0UcUaueOk9/HJVE1vG6QwSHTdI6WHOO8xAXyWEFsUrs+n+oFsIpDTGWsyHfeHR 8FrnRmdSFioXzCVR1pRK1JsNiEFWzVB60Z+HC372OatqWXpIuD+IWoZgRNqMkXni kZxzmufnOyIDXJVvMs6XW9ritZP4Ug== =VXWA -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 28 15:25:36 2018 Return-Path: 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 55674130DE8 for ; Tue, 28 Aug 2018 15:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 N0WA26pf9otN for ; Tue, 28 Aug 2018 15:25:34 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFCF130E1C for ; Tue, 28 Aug 2018 15:25:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 14DE120491; Tue, 28 Aug 2018 18:43:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 05F4A26DF; Tue, 28 Aug 2018 18:25:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 028F011E7; Tue, 28 Aug 2018 18:25:33 -0400 (EDT) From: Michael Richardson To: Ashley Blewer cc: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] draft Agenda for Virtual Interim meeting August 28, 2018 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 22:25:35 -0000 --=-=-= Content-Type: text/plain Ashley Blewer wrote: > Sending my regrets, have to work and cannot be at the meeting today! The notes are at: https://etherpad.tools.ietf.org/p/notes-cellar-virtual04?useMonospaceFont=true and I will edit them into minutes this week. Alas, we could not turn on the webex recording. I wish we could use meetecho for virtual interims. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAluFy9wACgkQgItw+93Q 3WVZiwf/dtUmNP0rLBKqL4Rb7H4ksRLcuZJC6Avte8ez5V8VU+0xMJ76Lg1Iu9w5 L8QKIC3/qGvQ7Upv8CfojssW98WFfS3p9NkWM+1BrwWbCB/GHYma9Cm7bW2lJY92 P/gycNfFamji/dJyuV6aC89uhJlW7nAqbIg82b1Pg70IJz0cohqsFPm00JUhaTMo i3r1UWwwRCOpmMT/n0q+0zjEgkG4KZJueZl0+nsyYozGpNS9TsF6PRf/KusjF5kE 5GyFugKfDOs7SMu26qssSit7ib2bXDcKSgIWzybJ6lqJ0pAA97EVSsW21IwBvEVI 5Ld1PaeIOOXED67AOqfOpOQaZuiLZg== =ANaR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 28 22:19:45 2018 Return-Path: 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 64FF8130DC6 for ; Tue, 28 Aug 2018 22:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org 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 lDgOk4-FXrkl for ; Tue, 28 Aug 2018 22:19:42 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 035C712D949 for ; Tue, 28 Aug 2018 22:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2017070101; h=Message-ID:From:CC:To:Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Date; bh=gcMqDKz1D2Jg2IrG8+VYPY6uSwe2SXxrQAoE8dG1k40=; b=ZPH/URdTBIkdmz7Wm1PBZXnnqkI1p2MP/Fb92d5MBMqOQEf4whCU5UR3n1ydQupS0ANO/tLpDjH5maKlp3PX/TaX7lb2zCOsdjTnv2IGTUQ7jUrWSsuqvNp/d3eqhe0Sww+67fJc8DYCdO8hlb4IDbQhXkHzzWoQ0f9/3hg41jyvdiLx8iRYICU3VFaEuEGuIr2WXMWrO9kL2jZ6qCEBLvZdMb2d8z1ov0OgkvfE8qsbCwP84DABtI7aDOaJfLSjO2+YoeCUZdTzEFsthELb//bjNkeqMS42eWNVKsqIhBfwqSyHraHuvSld3OoIJtk+9BGq6uY+3LlmR1qeVuRkfP07xPb7qidM83elMjThax9eEuT80E/UdJ+JtJ/AWKDTfXM4eaAIP7kP4Q4oQ9V64OO+clgo09DUP9VJKWVI40vCjipCXolYY08MJ7rxfGfeH1jBo1s5hAtpzDHxw51Cu1ca8ECRgHVReCqg9otKKtmfHY1tHeKrOi/yrqOH0dxxMcWf1ysoP8iARaj4q9K/QR4LLwoHfCCOLPtpqf+04NVcbJUx1xDwxs/Ra1ruN3+sUXEGKGpQZrIH3uk7k0V8pOtv6dQLxAKafyHTj5f0T98k6JCe73NxIAIA/2T3U51xIK0C3bxjvJCgYNUzQUbZPv19xtpaNYw6pHeYqNdqEZ4=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:49178) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1fust7-0003ct-26; Wed, 29 Aug 2018 07:19:29 +0200 X-Virus-Scanned: amavisd-new at bunkus.org Received: from [IPv6:2003:a:f28:de00:1899:74a9:a253:70bd] (unknown [IPv6:2003:a:f28:de00:1899:74a9:a253:70bd]) by liselle.bunkus.org (Postfix) with ESMTPSA id 302A96541602; Wed, 29 Aug 2018 07:19:22 +0200 (CEST) Date: Wed, 29 Aug 2018 07:19:18 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <3110.1535494847@localhost> References: <15361.1528336434@localhost> <3970.1531804177@localhost> <3110.1535494847@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: cellar@ietf.org, Michael Richardson , Steve Lhomme CC: Codec Encoding for LossLess Archiving and Realtime transmission From: Moritz Bunkus Message-ID: <45BD9DE6-A391-4C55-B582-B3BC78EC7E1C@bunkus.org> Archived-At: Subject: Re: [Cellar] IANA Considerations for EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 05:19:44 -0000 Hey, Yes, I completely agree with this proposal=2E Kind regards Mosu