From nobody Wed Jun 1 05:36:48 2016 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 449C012D1B4 for ; Wed, 1 Jun 2016 05:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 PCgOQ05ZC4As for ; Wed, 1 Jun 2016 05:36:44 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A30A12D1B8 for ; Wed, 1 Jun 2016 05:36:36 -0700 (PDT) Received: from mfilter42-d.gandi.net (mfilter42-d.gandi.net [217.70.178.172]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id DDDB7C5A7A for ; Wed, 1 Jun 2016 14:36:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter42-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter42-d.gandi.net (mfilter42-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Kitv1Q0KyJif for ; Wed, 1 Jun 2016 14:36:32 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 44604C5B02 for ; Wed, 1 Jun 2016 14:36:31 +0200 (CEST) Date: Wed, 1 Jun 2016 14:36:30 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160601123630.GA4636@nb4> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] [PATCH FFV1] Remove slice_count reference X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 12:36:47 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 31, 2016 at 09:17:36PM +0200, Jerome Martinez wrote: > slice_count is used but not defined. > It is actually not in the bistream, so we remove it from the spec. >=20 > I also remove "i" from "Slice ( i )" because the current usage is > not coherent: either we use "i" everywhere (slice_y [ i ], > picture_structure [ i ], slice_crc_parity [ i ]...) or nowhere, and > avoiding it simplifies the spec without having misunderstanding (we > explicitly say that slices are independent). >=20 > ffv1.md | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > 0c926a33bb52ceeed72428e2969f649f5ca8ec13 0001-Remove-slice_count-referen= ce.patch > From 89508033906c9d93df9d797262d5bfbbce69a4c2 Mon Sep 17 00:00:00 2001 > From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D > Date: Tue, 31 May 2016 20:35:31 +0200 > Subject: [PATCH] Remove slice_count reference applied thanks [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldO1s4ACgkQYR7HhwQLD6sv0gCcCYMBIFAqHh2mAfE+11pgLfsv LUIAnRXsErMk0oIU1nxkgDQC9fJxPPTt =qAns -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From nobody Wed Jun 1 08:19:32 2016 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 A4FE512D51F for ; Wed, 1 Jun 2016 08:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 zC2nGvyyxKxx for ; Wed, 1 Jun 2016 08:19:26 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 A8F2812D1DC for ; Wed, 1 Jun 2016 08:19:26 -0700 (PDT) Received: from [146.96.19.240] (port=20656 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b87vV-000VtY-8Y; Wed, 01 Jun 2016 11:19:25 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <572A45B0.2010301@xiph.org> Date: Wed, 1 Jun 2016 11:19:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5729865A.8050208@xiph.org> <8038712D-919D-4723-8F8D-936909CEC033@dericed.com> <572A45B0.2010301@xiph.org> To: "Timothy B. Terriberry" X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 15:19:31 -0000 Hi Tim, > On May 4, 2016, at 2:55 PM, Timothy B. Terriberry = wrote: >=20 > Dave Rice wrote: >> I'm coordinating another event in Berlin related to using Matroska >> and FFV1 at the Deutsche Kinemathek within archives so some of that >> group may likely attend. >=20 > Any rough estimate of how big that other group will be? Hard to say. >> To attend the working group meeting in person, is the minimal >> sufficient registration for attendance a day pass? >=20 > Correct. >=20 >>> Are there any other WGs you'd like to avoid a conflict with? >>=20 >> netvc certainly. Are there other active audiovisual working groups? >=20 > There are a number of other WGs in the Applications and Real-Time = (ART) Area... I was already planning to add the ones that I personally = will need to attend, but if there's something from an area, just let me = know. I think you know these groups much better than I. This will be my first = IETF conference. Do you have an idea on when (or if?) a CELLAR session would be = scheduled. I'm hoping to plan some other format-related events around = it. Best Regards, Dave Rice From nobody Wed Jun 1 09:03:48 2016 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 96F9412D533 for ; Wed, 1 Jun 2016 09:03: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 CU0z1x7YuIxX for ; Wed, 1 Jun 2016 09:03:43 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D2712D11B for ; Wed, 1 Jun 2016 09:03:35 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id x189so22723521ywe.3 for ; Wed, 01 Jun 2016 09:03:35 -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:date:message-id:subject:from:to :cc; bh=JQpsqipm3MAAfpURcnQbizADxcECGj6OsxqdiXhICwk=; b=SLw/pI80Q5zPQ3gshSTvwPktT9FOCr76D57zcaIo/qwo3v1TMo955i+h7Q9EohN3ag 9yCPN4Yj/v5DGDtntjeMjgvZ0nbG+wYir1XLUqioxvGnPe+wOMra3ofusiC18pmgnLiL TLMFYf6o32b+rrPhAgVcZyEFQrB4yWt0osgiBjNQcb8sjQ2goTZ0z3HnDFynS5Ci6Lhc KkWUm5N48alWhhPabFQyONQeOgB5MZhJ9n6CKTGkZ55fGsK4Frzu5AZUhusuGxY8uwPQ xYGzRr9NmYy4GgmF1g6J5VvIflToizcjfNhKfsZU00E5gBV9rsdeFLoo6UlW56VImQH/ 4mig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JQpsqipm3MAAfpURcnQbizADxcECGj6OsxqdiXhICwk=; b=Ygxy/IUNFzt/mG24nDvBfBw+AG3JibBUghYwj+JbUdrTj4H+7IhUB25OMO0qYECoBT wMQcqJPDP4XD2QXyoGHyVLra+UxBIMrxjdsK1qryZ/ANCAASCJ+Fu9gmlY3qo4TapWfV hHuReYPUzQf2tXDAp1oQgsxvGoqPQiaMI7f+PNedAqn3luRO/3WAc2u9ALnFURIcU6Pi TUCAqSRZtPdEK3d08YpenE1NbBNS3Vvn9Bz7z66tYoi+ef/984Su8Z4lodOTZWDvt5/+ bHvQK0BOhCikmq1TJCjidBVQ0t6fei78sQy5x75GDeR6IsJTQo3G9WBx0Qzu/b4sPd89 8LLQ== X-Gm-Message-State: ALyK8tKCqbh/QlkVf4Sx9dkAGVRJfIMM2ktS3jsXgpth/Dl63zzs+SB2CEdeP770FKkPZfIhxJUUGV0zXefMWA== MIME-Version: 1.0 X-Received: by 10.13.204.197 with SMTP id o188mr2697251ywd.247.1464797014607; Wed, 01 Jun 2016 09:03:34 -0700 (PDT) Received: by 10.83.48.143 with HTTP; Wed, 1 Jun 2016 09:03:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jun 2016 18:03:34 +0200 Message-ID: From: Steve Lhomme To: Luca Barbato Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] can Mandatory Elements be Empty Elements? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 16:03:46 -0000 I agree. It's good that we can often track issues to a specific program/version. But we cannot rely on it. It's informational and should not be mandatory. Those making programs and proud of their work will fill these values. The ones who want to hide and not be blamed won't be. Also making the change won't affect existing files. 2016-05-24 15:39 GMT+02:00 Luca Barbato : > On 24/05/16 15:16, Dave Rice wrote: >> Removing this requirement would reduce a tiny amount of space but >> cause a lot of confusion. Compared to other audiovisual containers, >> I'm glad that almost all Matroska files can be traced back to the >> tools used to create them. Also nearly every Matroska file follows >> the requirement and uses MuxingApp and WritingApp. Some Handbrake >> files do not follow the rule though. > > The information is not trustworthy anyway. > > If a file is readable w/out certain information it should stay optional > IMHO. > > Usual warning: > > "Relying on certain strings to enable quirk-modes is a recipe for a > disaster, please do not do that. If you want to support a quirk make so > you detect the quirk and fallback when possible" > > lu > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Wed Jun 1 12:26:25 2016 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 A8B8F12D1DE for ; Wed, 1 Jun 2016 12:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ktm5kjqawbTw for ; Wed, 1 Jun 2016 12:26:23 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1609A12B039 for ; Wed, 1 Jun 2016 12:26:23 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id z189so90558330itg.0 for ; Wed, 01 Jun 2016 12:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=pHooB5GSMr9MVBbFD6BtFT0XHxPJs7cpdUpABOv8sHQ=; b=ZwgZEhB/7c945eTG4EOyhhO2z0GMrt1W/imakGSg6ciVnL9Fq8MPL4p9hcGw48vc1r d0la8iuqKFU6aPtYh37ovEQVYgsG7gh3QPXZAPKq6AVUqwiJGt+cFQbrxbkcS16lhYBa ocIvxv6J1CWYn9kOnuUKieHny311dGhs+uVSYqcrnn2tzx1TFUnrFcyb04+CJQTrQz/I zA/zrz9JCNA63GbmJ3AUv1O09ipuBSFY27xFUJ9TAdfoSq3uOUSw53iWV4uXTzQgKGiv ropS55YgHNlTI2BEiDdj4FCAx3wEUB/u1Lzu24MyxXfOfmkUfJY552yB+vCGzFMGiKaI LpUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=pHooB5GSMr9MVBbFD6BtFT0XHxPJs7cpdUpABOv8sHQ=; b=bmogIt4kkdBD0hBwTLvAgYUYUWg8v3rSlGZgV8HTwmLfRRd6CllLPiWnwjVJ1hJECZ h9ecF8Z0Oj+qIho7yFuxAk54MIRlX1ogB4qJ4LqcRld5U7vl4P77UU493cTcVCas9e3z 47ik3jphNvSeifjNqSPrubGIcBfk2rwEC+dYoOiSB0k9eV5MCcP7UK+IP5nN2Ltw0KPK a7bfL3fs7Ao/liKI8iPj9QqwZeP3GX/ABE6WTCUSF1XpJwDlW+AyGKeVWiaq/63kVy9X mZbkLr+NlVug0Dr/1SW1XQS4NtmulHXXGRddaaIa5qRQMs3Sx5mY5X8p534SAr/gT2Px sH1Q== X-Gm-Message-State: ALyK8tKpdWOKkjCuGjtRg/aqULKrWVPXgcBh63GdPXZDHHVyrxBv77fuLBxpifDN+SFDpHYIgiB8GM5bmF9YzbhY X-Received: by 10.36.82.210 with SMTP id d201mr8142652itb.61.1464809180241; Wed, 01 Jun 2016 12:26:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.15.22 with HTTP; Wed, 1 Jun 2016 12:26:00 -0700 (PDT) In-Reply-To: References: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> <13C43671-E7FC-4011-B759-0E4F0E003D98@dericed.com> From: Michael Bradshaw Date: Wed, 1 Jun 2016 12:26:00 -0700 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a11447f36e1cf9805343c7619 Archived-At: Subject: Re: [Cellar] Matroska Ordering Guidelines X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 19:26:25 -0000 --001a11447f36e1cf9805343c7619 Content-Type: text/plain; charset=UTF-8 On Sat, May 28, 2016 at 8:13 AM, Dave Rice wrote: > > I could renaming it to "Ordering Requirements", though I think including > both mandates and recommendations on ordering in the same section is okay, > or possibly having one subsection on mandates and one subsequent subsection > on recommendations. > Alternatively, just naming it "Ordering" or "Ordering in Matroska" and then clearly using SHOULD/MUST throughout the section would clarify what's a recommendation and what's a requirement. I'd be content with something like that. --001a11447f36e1cf9805343c7619 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, May 28, 2016 at 8:13 AM, Dave Rice <dave@dericed.com> wro= te:
=
I could renaming it to "Ordering Requirements", though I thi= nk including both mandates and recommendations on ordering in the same sect= ion is okay, or possibly having one subsection on mandates and one subseque= nt subsection on recommendations.

Alternatively, just naming it "Ordering" or "Orderi= ng in Matroska" and then clearly using SHOULD/MUST throughout the sect= ion would clarify what's a recommendation and what's a requirement.= I'd be content with something like that.=C2=A0
--001a11447f36e1cf9805343c7619-- From nobody Wed Jun 1 14:09:49 2016 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 E6BB012D611 for ; Wed, 1 Jun 2016 14:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 YUHw3NK8JSor for ; Wed, 1 Jun 2016 14:09:47 -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 4449812B01F for ; Wed, 1 Jun 2016 14:09:47 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id D67B5C169F; Wed, 1 Jun 2016 21:09:46 +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 l6h6sgCyd3v5; Wed, 1 Jun 2016 21:09:46 +0000 (UTC) Received: from [10.252.25.214] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id B75FEC1053; Wed, 1 Jun 2016 21:09:46 +0000 (UTC) Message-ID: <574F4F1A.6010903@xiph.org> Date: Wed, 01 Jun 2016 14:09:46 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: Dave Rice References: <5729865A.8050208@xiph.org> <8038712D-919D-4723-8F8D-936909CEC033@dericed.com> <572A45B0.2010301@xiph.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 21:09:49 -0000 Dave Rice wrote: > Do you have an idea on when (or if?) a CELLAR session would be scheduled. I'm hoping to plan some other format-related events around it. Important meeting dates are published here: https://ietf.org/meeting/important-dates-2016.html For the Berlin meeting, the draft agenda (schedule) will be available for comment on June 17th, and the final version one week later on the 24th. From nobody Wed Jun 1 14:19:59 2016 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 032C212D0C5 for ; Wed, 1 Jun 2016 14:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 B5zi8hJwSaiD for ; Wed, 1 Jun 2016 14:19:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 774CD12B01F for ; Wed, 1 Jun 2016 14:19:56 -0700 (PDT) Received: from [10.10.1.2] ([162.216.46.76]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u51LJBGI098568 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2016 16:19:12 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.76] claimed to be [10.10.1.2] From: "Ben Campbell" To: "Dave Rice" Date: Wed, 01 Jun 2016 17:19:09 -0400 Message-ID: In-Reply-To: <574F4F1A.6010903@xiph.org> References: <5729865A.8050208@xiph.org> <8038712D-919D-4723-8F8D-936909CEC033@dericed.com> <572A45B0.2010301@xiph.org> <574F4F1A.6010903@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: cellar@ietf.org, "Timothy B. Terriberry" Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jun 2016 21:19:58 -0000 A couple of notes, below: On 1 Jun 2016, at 17:09, Timothy B. Terriberry wrote: > Dave Rice wrote: >> Do you have an idea on when (or if?) a CELLAR session would be >> scheduled. I'm hoping to plan some other format-related events around >> it. > > Important meeting dates are published here: > https://ietf.org/meeting/important-dates-2016.html > > For the Berlin meeting, the draft agenda (schedule) will be available > for comment on June 17th, and the final version one week later on the > 24th. As we discussed in previous conversations, the chairs can request constraints on when a group is scheduled. The IESG and secretariat will honor such requests as best they can, but there are no promises. Occasionally things change even after the so-called "final" version is published. Thanks! Ben. > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Fri Jun 3 18:14:55 2016 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 D036012D125 for ; Fri, 3 Jun 2016 18:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no 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 2kKxF1oWrv08 for ; Fri, 3 Jun 2016 18:14:52 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 5966A12B049 for ; Fri, 3 Jun 2016 18:14:52 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:43545 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b90Ar-00307u-Tt for cellar@ietf.org; Fri, 03 Jun 2016 21:14:51 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <0267C7D2-1FFD-4771-974C-9C14C537D396@dericed.com> Date: Fri, 3 Jun 2016 21:14:48 -0400 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] matroska test files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 04 Jun 2016 01:14:54 -0000 Hi all, I committed the content of the Matroska test file collection from = http://sourceforge.net/projects/matroska/files/test_files/matroska_test_w1= _1.zip/download to a new GitHub repository at = https://github.com/dericed/matroska-test-files. I also started a pull = request to convert the html to markdown. That branch can be seen here: = https://github.com/dericed/matroska-test-files/tree/html2md. I think there are a lot of advantages to having the test file collection = in github rather than sourceforge as the community can more easily = supply issues and comments, users can send new samples as pull requests, = or request samples via issues. Steve, Mortiz, I can transfer the ownership to the Matroska-Org account = or you=E2=80=99re welcome to import it. Best Regards, Dave Rice= From nobody Sat Jun 4 07:57:37 2016 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 42D8A12D162 for ; Sat, 4 Jun 2016 07:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no 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 78zzPrgmUra5 for ; Sat, 4 Jun 2016 07:57:34 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 D0DA612D135 for ; Sat, 4 Jun 2016 07:57:34 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:41709 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b9D12-001D0v-3z; Sat, 04 Jun 2016 10:57:34 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Jun 2016 10:57:29 -0400 Message-Id: <11CEAE32-1F69-4794-997D-24207F6D74CC@dericed.com> To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Ashley Blewer Subject: [Cellar] paper on Matroska and FFV1 standardization accepted for iPres X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 04 Jun 2016 14:57:36 -0000 Hi all, I wanted to share news that a paper about Matroska and FFV1 = standardization that Ashley Blewer and I drafted was accepted into iPRES = 2016 which is an international conference on digital preservation to be = held in Bern, Switzerland in early October. Between now and the July = 15th deadline, we=E2=80=99ll expand and improve the paper for submitted. = The current working draft is available on Google Docs [2]. We=E2=80=99d = like to crowd-source the paper so co-authoring, reviews, and suggestions = are very welcome. Best Regards, Dave Rice [1] http://www.ipres2016.ch/ [2] = https://docs.google.com/document/d/1oH757ViN5YKUzVhsxxWhGnT2nJSkH8WRvzEpHK= zKGI4/edit?usp=3Dsharing= From nobody Sat Jun 4 08:13:06 2016 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 16F1E12D1D0 for ; Sat, 4 Jun 2016 08:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 eU9tPYHH7eSc for ; Sat, 4 Jun 2016 08:13:01 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 D3F8412D146 for ; Sat, 4 Jun 2016 08:13:00 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id f67so11899842ith.1 for ; Sat, 04 Jun 2016 08:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=F7Q/GclTLe+LUD3npUn7MJgqZqledmYV0NF1SAhWnzo=; b=F8XihjBGSCCjCRlIHwjv3gTrLCU0zKtKGVrO0p7etjFinScZwe4pzkjDmJI8daLf2N R5PCAmcDPSrX5+uDrpX6WsZYEtP3UUpP5lFQO6QV75wmpivJEimSegoSQo54VoATgp8E Gbm3iV8S5dxOtr1AiqOeqloyP68XzbFsDUGe5/FGYin4nRckvwa+GlcmnyAgxEYF4TeF qtxQ3Z9fY8HfgPmLP6jVZ16H4w2XeIEAvDwxnAag0WiJmT3eeRQ5Sly/pBkt7Qy+21nl F6An/G5b0d83LmUKjWNJMLsyEFNNtnrgRKkKYTj83ikiosl4eq7BQwef+A0WmeLx5gdK YVEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=F7Q/GclTLe+LUD3npUn7MJgqZqledmYV0NF1SAhWnzo=; b=PMIG/mYMUP+G43vs2sAu9PUQCrebW/49I/uX+xDybm1oMkDNARRkeBkbkcqN8UoaFk QSpkh/dGRcn2qB6dcoR4yKEvLYNuwvWMLdyhSdFGUN5wJTKOtDAtyR6Q9Z7d4rSJhf+h 2sJR2Qr/YieGPe3xtnhMB+9QA9fotbr1J/TRiN4rplW1J6SG+k+Fn/WQ3ujin8romAIU rlACv9+815d4EreMvVPLJrj1LeDSv1CS+6kWUjXsED0Esee1K4vbXVlrnwp+pRyv0MoW Ir1TRUXtYtEeasQx1D0JEmWt//MykgJibzJWnLao0T28PfqZioZ2ybdnfV2jNddWU6Lm c1Ow== X-Gm-Message-State: ALyK8tKgcA818v2nQj3oppUHYLYdzmMrN3TomarJVjjWJihG+aoJrgoykQ2RKi1p/c208dxLCUb+3eo7DsVaYQ== X-Received: by 10.36.120.12 with SMTP id p12mr6585926itc.22.1465053180137; Sat, 04 Jun 2016 08:13:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.133.197 with HTTP; Sat, 4 Jun 2016 08:12:59 -0700 (PDT) From: Ashley Blewer Date: Sat, 4 Jun 2016 11:12:59 -0400 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a114ab6ca61163905347546e6 Archived-At: Subject: [Cellar] Building an RFC X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 04 Jun 2016 15:13:05 -0000 --001a114ab6ca61163905347546e6 Content-Type: text/plain; charset=UTF-8 Bumping this and renaming the thread topic. Does anyone have experience building an RFC and also have time to help gather one together (for EBML and/or Matroska)? The submission deadline is July 8th. Ashley On Mon, Apr 25, 2016 at 10:58 PM, Ashley Blewer wrote: > I demo'ed the above template and it seems promising, but the Markdown > would need a lot of work to get it integrated -- the current MD document > includes some unconventional HTML tags (abbr, pre) and the template also > doesn't like the way the document can link to itself using syntax like > this: [SimpleBlock structure](#simpleblock_structure). Not sure how well > this will play with Github-pages. > > I'll keep investigating. Also using the core component of this (xml2rfc), > we might be able to build our own Makefile that auto-generates an RFC. > > Ashley > > On Mon, Apr 25, 2016 at 8:38 PM, Ashley Blewer > wrote: > >> Thomas, thanks for posting this! >> >> On Mon, Apr 25, 2016 at 8:08 PM, Timothy B. Terriberry > > wrote: >> >>> Thomas Daede wrote: >>> >>>> Martin Thompson has a template on Github that includes makefiles to >>>> generate a draft from Markdown. >>>> >>>> https://github.com/martinthomson/i-d-template >>>> >>>> It is based on a tool called kramdown-rfc2629 that will generate xml2rfc >>>> compatible output from Markdown. It has worked well for me for a couple >>>> of drafts in the netvc github, as well as some really big drafts, like >>>> TLS 1.3: https://github.com/tlswg/tls13-spec >>>> >>> >>> I have never used the tools in question, but Thomas's advice seems >>> cogent to me (at the very least a lot better than converting by hand). >>> >>> >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >>> >> >> > --001a114ab6ca61163905347546e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bumping this and renaming the thread topic. Does anyone ha= ve experience building an RFC and also have time to help gather one togethe= r (for EBML and/or Matroska)? The submission deadline is July 8th.

=
Ashley


On Mon, Apr 25, 2016 at 10:58 PM, Ashley Blewer <ashley.blewer@gmail.com> wrote:
I demo'ed the above template and it seems pr= omising, but the Markdown would need a lot of work to get it integrated -- = the current MD document includes some unconventional HTML tags (abbr, pre) = and the template also doesn't like the way the document can link to its= elf using syntax like this:=C2=A0[SimpleBlock structure](#simpleblock_struc= ture). Not sure how well this will play with Github-pages.

I'll keep investigating. Also using the core component of this (xml2= rfc), we might be able to build our own Makefile that auto-generates an RFC= .

A= shley

On Mon, Apr 25, 2016 = at 8:38 PM, Ashley Blewer <ashley.blewer@gmail.com> wr= ote:
Thomas, thanks for = posting this!=C2=A0

On Mon, Apr 25, 2016 at 8:08 PM, Timothy B. Terriberry <= tterribe@xiph.org> wrote:
<= span>Thomas Daede wrote:
Martin Thompson has a template on Github that includes makefiles to
generate a draft from Markdown.

https://github.com/martinthomson/i-d-template

It is based on a tool called kramdown-rfc2629 that will generate xml2rfc compatible output from Markdown. It has worked well for me for a couple
of drafts in the netvc github, as well as some really big drafts, like
TLS 1.3: https://github.com/tlswg/tls13-spec

I have never used the tools in question, but Thomas's advice seems coge= nt to me (at the very least a lot better than converting by hand).


_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar



--001a114ab6ca61163905347546e6-- From nobody Mon Jun 6 04:07:13 2016 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 DAC9112B03D for ; Mon, 6 Jun 2016 04:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 c6UdY52yOu-3 for ; Mon, 6 Jun 2016 04:07:09 -0700 (PDT) Received: from 3.mo178.mail-out.ovh.net (3.mo178.mail-out.ovh.net [46.105.44.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B2312D0A5 for ; Mon, 6 Jun 2016 04:07:08 -0700 (PDT) Received: from player791.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id 033DA1000D3E for ; Mon, 6 Jun 2016 13:07:06 +0200 (CEST) Received: from [192.168.2.101] (p5DDB5AFE.dip0.t-ipconnect.de [93.219.90.254]) (Authenticated sender: jerome@francoallemand.eu) by player791.ha.ovh.net (Postfix) with ESMTPSA id B248D42008C for ; Mon, 6 Jun 2016 13:07:06 +0200 (CEST) From: Jerome Martinez To: cellar@ietf.org Message-ID: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> Date: Mon, 6 Jun 2016 13:07:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------795A8E344948A1EE4A848152" X-Ovh-Tracer-Id: 6438458619332202641 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrieelgdeffecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: [Cellar] [PATCH FFV1] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 11:07:12 -0000 This is a multi-part message in MIME format. --------------795A8E344948A1EE4A848152 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit As "height" word is currently used for both height in raster elements and height in pixels, I do make it explicit when the pixel height is used. I remove any reference to Plane() (which is not defined) in order to have colorspace_type and slice_pixel_height in the same block whatever is the color_space. The slice height in pixels is defined; explicit floor() during its computing (I use the mathematical symbol instead of the C function name in order to be more generic) --------------795A8E344948A1EE4A848152 Content-Type: text/plain; charset=UTF-8; name="0001-SliceContent-description-update.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-SliceContent-description-update.patch" RnJvbSA2MmVhZDIwZDI1YzliOTY5MzFlZWFjZTBkZjhmNWI3Mjg0YTRmNGEzIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBNb24sIDYgSnVuIDIwMTYg MTM6MDQ6MDUgKzAyMDAKU3ViamVjdDogW1BBVENIXSBTbGljZUNvbnRlbnQgZGVzY3JpcHRp b24gdXBkYXRlCgpEaWZmZXJlbmNlIGJldHdlZW4gaGVpZ2h0IGluIHNsaWNlIHJhc3RlciBl bGVtZW50cyBhbmQgcGl4ZWxzCkRlZmluZXMgc2xpY2VfcGl4ZWxfaGVpZ2h0Ci0tLQogZmZ2 MS5tZCB8IDIzICsrKysrKysrKysrKysrKysrKy0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMTgg aW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9mZnYxLm1kIGIv ZmZ2MS5tZAppbmRleCBhNTAzZDZjLi42NmVkMGUyIDEwMDY0NAotLS0gYS9mZnYxLm1kCisr KyBiL2ZmdjEubWQKQEAgLTEyNSw2ICsxMjUsMTIgQEAgX18hYV9fICAgICAgICAgIG1lYW5z IGJvb2xlYW4gbG9naWNhbCAibm90Ii4KIF9fYcKgP8KgYsKgOsKgY19fICAgaWYgYSBpcyB0 cnVlLCB0aGVuIGIsIG90aGVyd2lzZSBjLgogLS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K IAorIyMgTWF0aGVtYXRpY2FsIGZ1bmN0aW9ucworCistLS0tLS0tLS0tLS0tLS0gICAgICAg ICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQorX18mbGZsb29yO2EmcmZsb29yO19fICAgICAgIG1lYW5zIHRo ZSBpbnRlZ3JhbCBwYXJ0IG9mIGEgIAorLS0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KKwogIyMgT3JkZXIgb2Ygb3BlcmF0aW9uIHByZWNlZGVuY2UKIAogV2hlbiBv cmRlciBvZiBwcmVjZWRlbmNlIGlzIG5vdCBpbmRpY2F0ZWQgZXhwbGljaXRseSBieSB1c2Ug b2YgcGFyZW50aGVzZXMsIG9wZXJhdGlvbnMgYXJlIGV2YWx1YXRlZCBpbiB0aGUgZm9sbG93 aW5nIG9yZGVyIChmcm9tIHRvcCB0byBib3R0b20sIG9wZXJhdGlvbnMgb2Ygc2FtZSBwcmVj ZWRlbmNlIGJlaW5nIGV2YWx1YXRlZCBmcm9tIGxlZnQgdG8gcmlnaHQpLiBUaGlzIG9yZGVy IG9mIG9wZXJhdGlvbnMgaXMgYmFzZWQgb24gdGhlIG9yZGVyIG9mIG9wZXJhdGlvbnMgdXNl ZCBpbiBTdGFuZGFyZCBDLgpAQCAtNDYyLDkgKzQ2OCw5IEBAIFRoZSBzYW1lIGNvbnRleHQg d2hpY2ggaXMgaW5pdGlhbGl6ZWQgdG8gMTI4IGlzIHVzZWQgZm9yIGFsbCBmaWVsZHMgaW4g dGhlIGhlYWRlCiAKIFRoZSBmb2xsb3dpbmcgTVVTVCBiZSBwcm92aWRlZCBieSBleHRlcm5h bCBtZWFucyBkdXJpbmcgaW5pdGlhbGl6YXRpb24gb2YgdGhlIGRlY29kZXI6CiAKLSoqZnJh bWVcX3dpZHRoKiogaXMgZGVmaW5lZCBhcyBmcmFtZSB3aWR0aCBpbiBwaXhlbHMuCisqKmZy YW1lXF9waXhlbFxfd2lkdGgqKiBpcyBkZWZpbmVkIGFzIGZyYW1lIHdpZHRoIGluIHBpeGVs cy4KIAotKipmcmFtZVxfaGVpZ2h0KiogaXMgZGVmaW5lZCBhcyBmcmFtZSBoZWlnaHQgaW4g cGl4ZWxzLgorKipmcmFtZVxfcGl4ZWxcX2hlaWdodCoqIGlzIGRlZmluZWQgYXMgZnJhbWUg aGVpZ2h0IGluIHBpeGVscy4KIAogRGVmYXVsdCB2YWx1ZXMgYXQgdGhlIGRlY29kZXIgaW5p dGlhbGl6YXRpb24gcGhhc2U6CiAKQEAgLTYyMyw5ICs2MjksMTAgQEAgSW5mZXJyZWQgdG8g YmUgMCBpZiBub3QgcHJlc2VudC4KIHxTbGljZUNvbnRlbnQoICkgeyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHR5cGUgIHwKIHzCoMKgwqDCoGlmKCBj b2xvcnNwYWNlXF90eXBlID09IDApIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICB8CiB8wqDCoMKgwqDCoMKgwqDCoGZvciggcCA9IDA7IHAgXDwgcHJpbWFyeVxfY29s b3JcX2NvdW50OyBwKysgKSB7ICAgICB8ICAgICAgIHwKLXzCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqBQbGFuZSggcCApICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgIHwKK3zCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBmb3IoIHkgPSAwOyB5IFw8IHNs aWNlXF9waXhlbFxfaGVpZ2h0OyB5KysgKSAgICB8ICAgICAgIHwKK3zCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoExpbmUoIHAsIHkgKSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICB8CiB8wqDCoMKgwqB9IGVsc2UgaWYoIGNvbG9yc3BhY2VcX3R5 cGUgPT0gMSApIHsgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfAotfMKgwqDCoMKgwqDC oMKgwqBmb3IoIHkgPSAwOyB5IFw8IGhlaWdodDsgeSsrICkgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICB8Cit8wqDCoMKgwqDCoMKgwqDCoGZvciggeSA9IDA7IHkgXDwgc2xpY2Vc X3BpeGVsXF9oZWlnaHQ7IHkrKyApICAgICAgICB8ICAgICAgIHwKIHzCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqBmb3IoIHAgPSAwOyBwIFw8IHByaW1hcnlcX2NvbG9yXF9jb3VudDsgcCsr ICkgeyB8ICAgICAgIHwKIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoExpbmUo IHAsIHkgKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiB8wqDC oMKgwqB9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgfApAQCAtNjMzLDYgKzY0MCwxMiBAQCBJbmZlcnJlZCB0byBiZSAw IGlmIG5vdCBwcmVzZW50LgogCiAqKnByaW1hcnlcX2NvbG9yXF9jb3VudCoqIGlzIGRlZmlu ZWQgYXMgMSArICggY2hyb21hX3BsYW5lcyA/IDIgOiAwICkgKyAoIGFscGhhX3BsYW5lID8g MSA6IDAgKS4KIAorKipzbGljZVxfcGl4ZWxcX2hlaWdodCoqIGlzIHRoZSBzbGljZSBoZWln aHQgaW4gcGl4ZWxzLiAgCitJdHMgdmFsdWUgaXMgJmxmbG9vcjsoIHNsaWNlXF95ICsgc2xp Y2VcX2hlaWdodCApICogZnJhbWVfcGl4ZWxcX2hlaWdodCAvIG51bVxfdlxfc2xpY2VzJnJm bG9vcjsgLSBzbGljZVxfcGl4ZWxcX3kKKworKipzbGljZVxfcGl4ZWxcX3kqKiBpcyB0aGUg c2xpY2UgdmVydGljYWwgcG9zaXRpb24gaW4gcGl4ZWxzLiAgCitJdHMgdmFsdWUgaXMgJmxm bG9vcjtzbGljZV95ICogZnJhbWVfcGl4ZWxcX2hlaWdodCAvIG51bVxfdlxfc2xpY2VzJnJm bG9vcjsKKwogIyMgU2xpY2UgRm9vdGVyCiAKIE5vdGU6IHNsaWNlIGZvb3RlciBpcyBhbHdh eXMgYnl0ZSBhbGlnbmVkLgpAQCAtODc1LDcgKzg4OCw3IEBAIE1BWFxfQ09OVEVYVFxfSU5Q VVRTIGlzIDUuCiAKICMjIyBSZXN0cmljdGlvbnMKIAotVG8gZW5zdXJlIHRoYXQgZmFzdCBt dWx0aXRocmVhZGVkIGRlY29kaW5nIGlzIHBvc3NpYmxlLCBzdGFydGluZyB2ZXJzaW9uIDMg YW5kIGlmIGZyYW1lXF93aWR0aCAqIGZyYW1lXF9oZWlnaHQgaXMgbW9yZSB0aGFuIDEwMTM3 Niwgc2xpY2VcX3dpZHRoICogc2xpY2VcX2hlaWdodCBNVVNUIGJlIGxlc3Mgb3IgZXF1YWwg dG8gbnVtXF9oXF9zbGljZXMgKiBudW1cX3ZcX3NsaWNlcyAvIDQuCitUbyBlbnN1cmUgdGhh dCBmYXN0IG11bHRpdGhyZWFkZWQgZGVjb2RpbmcgaXMgcG9zc2libGUsIHN0YXJ0aW5nIHZl cnNpb24gMyBhbmQgaWYgZnJhbWVcX3BpeGVsXF93aWR0aCAqIGZyYW1lXF9waXhlbFxfaGVp Z2h0IGlzIG1vcmUgdGhhbiAxMDEzNzYsIHNsaWNlXF93aWR0aCAqIHNsaWNlXF9oZWlnaHQg TVVTVCBiZSBsZXNzIG9yIGVxdWFsIHRvIG51bVxfaFxfc2xpY2VzICogbnVtXF92XF9zbGlj ZXMgLyA0LgogTm90ZTogMTAxMzc2IGlzIHRoZSBmcmFtZSBzaXplIGluIHBpeGVscyBvZiBh IDM1MngyODggZnJhbWUgYWxzbyBrbm93biBhcyBDSUYgKCJDb21tb24gSW50ZXJtZWRpYXRl IEZvcm1hdCIpIGZyYW1lIHNpemUgZm9ybWF0LgogCiBGb3IgZWFjaCBmcmFtZSwgZWFjaCBw b3NpdGlvbiBpbiB0aGUgc2xpY2UgcmFzdGVyIE1VU1QgYmUgZmlsbGVkIGJ5IG9uZSBhbmQg b25seSBvbmUgc2xpY2Ugb2YgdGhlIGZyYW1lIChubyBtaXNzaW5nIHNsaWNlIHBvc2l0aW9u LCBubyBzbGljZSBvdmVybGFwcGluZykuCi0tIAoyLjcuMC53aW5kb3dzLjEKCg== --------------795A8E344948A1EE4A848152-- From nobody Wed Jun 8 06:21:46 2016 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 249F712D918 for ; Wed, 8 Jun 2016 06:21:45 -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 1rHg4xqQBWa2 for ; Wed, 8 Jun 2016 06:21:43 -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 73EB712D0DA for ; Wed, 8 Jun 2016 06:21:42 -0700 (PDT) Received: from [192.168.0.14] (chello213047163139.5.15.vie.surfer.at [::ffff:213.47.163.139]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 08 Jun 2016 15:21:40 +0200 id 0000000000000024.0000000057581BE5.00006DC7 Message-ID: <57581BE3.4050808@das-werkstatt.com> Date: Wed, 08 Jun 2016 15:21:39 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: cellar@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] FFV1: Correct full name of the codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 13:21:45 -0000 Hi! I know this might come as a super-stupid question from me, but: @Michael Niedermayer: What does the abbreviation "FFV1" now really stand for? Source code says "FF Video Codec 1": http://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=libavcodec/ffv1enc.c;hb=HEAD Yet, I silently assumed it's "FFmpeg Video Codec 1"... I just wanted to clarify this ;) Thanksalot in advance, Pb From nobody Wed Jun 8 06:25:00 2016 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 0D3B612D1C1 for ; Wed, 8 Jun 2016 06:24:58 -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 G1ek7j6Gr_IB for ; Wed, 8 Jun 2016 06:24:56 -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 AD27F12D0E0 for ; Wed, 8 Jun 2016 06:24:56 -0700 (PDT) Received: from [192.168.0.14] (chello213047163139.5.15.vie.surfer.at [::ffff:213.47.163.139]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 08 Jun 2016 15:24:56 +0200 id 0000000000000041.0000000057581CA8.000076BD Message-ID: <57581CA6.3030207@das-werkstatt.com> Date: Wed, 08 Jun 2016 15:24:54 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: cellar@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] Invalid link in ffv1.html specs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 13:24:58 -0000 The CELLAR page lists FFV1 specification link as: https://mediaarea.net/temp/ffv1.html In there, it says: "The latest version of this document is available at https://raw.github.com/FFmpeg/FFV1/master/ffv1.lyx" But the LYX link says "Not found" :( Regards, Pb PS: Wasn't there a discussion a while ago about using something else than lyx? From nobody Wed Jun 8 06:27:59 2016 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 CBAA912D11F for ; Wed, 8 Jun 2016 06:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 6_JVTU27uXsA for ; Wed, 8 Jun 2016 06:27:55 -0700 (PDT) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 0894212B03D for ; Wed, 8 Jun 2016 06:27:55 -0700 (PDT) Received: from eris.local (dynamic-adsl-84-220-81-12.clienti.tiscali.it [84.220.81.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 58F5E340D04 for ; Wed, 8 Jun 2016 13:27:53 +0000 (UTC) To: cellar@ietf.org References: <57581CA6.3030207@das-werkstatt.com> From: Luca Barbato Message-ID: Date: Wed, 8 Jun 2016 15:27:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <57581CA6.3030207@das-werkstatt.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Invalid link in ffv1.html specs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 13:27:58 -0000 On 08/06/16 15:24, Peter B. wrote: > The CELLAR page lists FFV1 specification link as: > https://mediaarea.net/temp/ffv1.html > > In there, it says: > > "The latest version of this document is available at > https://raw.github.com/FFmpeg/FFV1/master/ffv1.lyx" > > But the LYX link says "Not found" :( > > > Regards, > Pb > > > PS: Wasn't there a discussion a while ago about using something else > than lyx? > It moved to markdown since long ago: https://raw.githubusercontent.com/FFmpeg/FFV1/master/ffv1.md lu From nobody Wed Jun 8 06:32:13 2016 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 8810F12D0C9 for ; Wed, 8 Jun 2016 06:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 RNlj0M-vPT-O for ; Wed, 8 Jun 2016 06:32:08 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 B7A6512D59D for ; Wed, 8 Jun 2016 06:32:08 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id z123so8612839itg.0 for ; Wed, 08 Jun 2016 06:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S9GuoQhPYfn2Npo+70VU3RUUhyesWFOknxVYp1JhzBI=; b=qlM07khnHQ9bmn4L4yDO+0zwYTuOOcgqXt0nWAc+ZQFssNKJVifz1n4UZcGFoRkp/B /U5Z5wEIVLUbvf8DV9YQMZyfj3+dJZc+6SrsHcY1Xj/vQwPttEBh0+hghdQqegYEa/PP QGqEoU868XHLiSNk/T+8mWq1GQMQDTylaUOq2w+kbJe6j+LZcc5Itp11eJjdCqxXAeFn 34Rkjz194rUDGrLswjoxrv0+SPrELfcRcGrFzguHiJpdORd7GykEkgi5dizqH2ZKxrgJ /2DO4hKYTEqxDoVwSHDowk+DgvPrrnasaXYbdOaPELxUH/8HQG9jTWunjAIKBQ6Z+EqG QRBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S9GuoQhPYfn2Npo+70VU3RUUhyesWFOknxVYp1JhzBI=; b=e97NT3GaPUFD4UQKe89xZ+6sevHx53fR6FFFKnqKgNeYDvufd4AcC2E4B/Tswh8qDZ emcrJFw8ryQ7Kjx5axOJTId4jdmx5wqoRqZTVow1tJA0P5eX0BmI8YX6+jVqpxbkQSUa 7ibVBizg/xnRe5NJcZVp8JwZtha/QkqT5sdrjDIpdMwsaUJCVxHTstyfZU5XiSpJuARZ eSnDKnzqq6xiI7ZWEBKYaXqUTpnhoxQrKszg+U5myHhLtbnfmqzpy3jMbreLME5bsSLl 0NfBauTjwK4W9nGxz6SntUjLMDh3im11SnMczagXCjmYGca7c/Of/BXz4UdDom6nojCQ az1w== X-Gm-Message-State: ALyK8tJvcJ5l6qNJP9RekBKcpWE9TtR7llCju+QIF6cFCvufM4Cz8EniPMjknGiDDvf3fVzpfm/1EFv/Mo95zg== X-Received: by 10.36.57.211 with SMTP id l202mr8634759ita.22.1465392727057; Wed, 08 Jun 2016 06:32:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.133.197 with HTTP; Wed, 8 Jun 2016 06:32:06 -0700 (PDT) In-Reply-To: <57581CA6.3030207@das-werkstatt.com> References: <57581CA6.3030207@das-werkstatt.com> From: Ashley Blewer Date: Wed, 8 Jun 2016 09:32:06 -0400 Message-ID: To: "Peter B." Content-Type: multipart/alternative; boundary=001a114ab3caf4209f0534c454c0 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Invalid link in ffv1.html specs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 13:32:10 -0000 --001a114ab3caf4209f0534c454c0 Content-Type: text/plain; charset=UTF-8 nice catch, Peter. We fully converted FFV1 to Markdown: https://github.com/FFmpeg/FFV1/blob/master/ffv1.md I don't know when the legacy LYX was removed from Github though (without digging into source code history). On Wed, Jun 8, 2016 at 9:24 AM, Peter B. wrote: > The CELLAR page lists FFV1 specification link as: > https://mediaarea.net/temp/ffv1.html > > In there, it says: > > "The latest version of this document is available at > https://raw.github.com/FFmpeg/FFV1/master/ffv1.lyx" > > But the LYX link says "Not found" :( > > > Regards, > Pb > > > PS: Wasn't there a discussion a while ago about using something else > than lyx? > > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a114ab3caf4209f0534c454c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
nice catch, Peter.

We fully converted F= FV1 to Markdown:=C2=A0https://github.com/FFmpeg/FFV1/blob/master/ffv1.md
=
I don't know when the legacy LYX was removed from Github= though (without digging into source code history).

On Wed, Jun 8, 2016 at 9:24= AM, Peter B. <pb@das-werkstatt.com> wrote:
The CELLAR page lists FFV1 specification link as:
https://mediaarea.net/temp/ffv1.html

In there, it says:

"The latest version of this document is available at
https://raw.github.com/FFmpeg/FFV1/master/ffv1.lyx= "

But the LYX link says "Not found" :(


Regards,
Pb


PS: Wasn't there a discussion a while ago about using something else than lyx?




_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

--001a114ab3caf4209f0534c454c0-- From nobody Wed Jun 8 06:32:51 2016 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 9FC2D12B054 for ; Wed, 8 Jun 2016 06:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 niBEmzctixoq for ; Wed, 8 Jun 2016 06:32:48 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 0740C12B03D for ; Wed, 8 Jun 2016 06:32:48 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id m62so9193200iof.0 for ; Wed, 08 Jun 2016 06:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dv0BVUsMFayv7Lg/ly4OT6DbfWuDRBlAtc1uxpQiuno=; b=WYkG7KWb8vbj6nRYbvP4CoROE9/NxELtg9Zo+q/sLQzeGvOmJE/ifesrbE9xKL4XEv 8vV8pd7+wcrKWb/9K9HzfyYFP/JPwoW8It6TiNXdr7BVV/L3sk5oT/7PWKHj5ULq+jAS 0vdBFd1B1sEnzrIoahYyJpij86pY94F9zmZPFuRBBh9vOvVnhDFdBycrd+v8zR8AKgsb pVtuN1xl1HI9F4poEkzCU9XhFzx9rqnIUEcfHFT4QehmJVKMRXnlkV2a30evR9FauJyV Sh3ZGDWTbOKnK7QQr16J/+uLloHV6v95wz9ocna0m8sllw6NmLZLzW9W5PtGRvUc21To n/ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dv0BVUsMFayv7Lg/ly4OT6DbfWuDRBlAtc1uxpQiuno=; b=cQNzQy4G0E6OYHghwprIn9Fi86Pll36NdAbuQcJ2pADeSGn8Nn1d2S7CIhtfdO9pyh uBv4KjRfgfOn9l9U0CtFLeNT4kIvuGos4FmmmI9MP5DKWBvSUkQuC6RIGUyuBgMysLWT miACHSRPnziJimyDIDsDqh1bo+e/Z6wENeFOHp2MO5XLXP2+S0iLf4PmxZIt92DqddOJ kZYreZYv2dQHkL27nlZxzDsc0WF2XY7mwFJmQfd24MIstRYrLXXStp5k8arGCu5CgMx5 870ILzCThTMQk3pCPeim7A5jzFpieXguzWWnMI73F7hxcWQvLNmm7O2xm/XsP9dklw6t W+cQ== X-Gm-Message-State: ALyK8tKDHRO/vQ2TpZWCI7QgQ3ZArsLHxpnIH2CH8RexS+BA2qi5XmXxZ/SIHOedQOE69vc86WerCBDPkc5BLw== X-Received: by 10.107.141.132 with SMTP id p126mr7979778iod.38.1465392767367; Wed, 08 Jun 2016 06:32:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.133.197 with HTTP; Wed, 8 Jun 2016 06:32:46 -0700 (PDT) In-Reply-To: References: <57581CA6.3030207@das-werkstatt.com> From: Ashley Blewer Date: Wed, 8 Jun 2016 09:32:46 -0400 Message-ID: To: "Peter B." Content-Type: multipart/alternative; boundary=94eb2c05a4e05b042f0534c457a8 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Invalid link in ffv1.html specs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 13:32:50 -0000 --94eb2c05a4e05b042f0534c457a8 Content-Type: text/plain; charset=UTF-8 The FFV1 spec, I should clarify. ;) On Wed, Jun 8, 2016 at 9:32 AM, Ashley Blewer wrote: > nice catch, Peter. > > We fully converted FFV1 to Markdown: > https://github.com/FFmpeg/FFV1/blob/master/ffv1.md > > I don't know when the legacy LYX was removed from Github though (without > digging into source code history). > > On Wed, Jun 8, 2016 at 9:24 AM, Peter B. wrote: > >> The CELLAR page lists FFV1 specification link as: >> https://mediaarea.net/temp/ffv1.html >> >> In there, it says: >> >> "The latest version of this document is available at >> https://raw.github.com/FFmpeg/FFV1/master/ffv1.lyx" >> >> But the LYX link says "Not found" :( >> >> >> Regards, >> Pb >> >> >> PS: Wasn't there a discussion a while ago about using something else >> than lyx? >> >> >> >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> > > --94eb2c05a4e05b042f0534c457a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The FFV1 spec, I should clarify. ;)

On Wed, Jun 8, 2016 at 9:32 AM, As= hley Blewer <ashley.blewer@gmail.com> wrote:
nice catch, Peter.

=
We fully converted FFV1 to Markdown:=C2=A0https://github.com/FFm= peg/FFV1/blob/master/ffv1.md

I don't know = when the legacy LYX was removed from Github though (without digging into so= urce code history).

On Wed, Jun 8, 2016 a= t 9:24 AM, Peter B. <pb@das-werkstatt.com> wrote:
The CELLAR page lists FFV1 specification link as= :
https://mediaarea.net/temp/ffv1.html

In there, it says:

"The latest version of this document is available at
https://raw.github.com/FFmpeg/FFV1/master/ffv1.lyx= "

But the LYX link says "Not found" :(


Regards,
Pb


PS: Wasn't there a discussion a while ago about using something else than lyx?




_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar


--94eb2c05a4e05b042f0534c457a8-- From nobody Wed Jun 8 06:39:06 2016 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 AE84312D5F6 for ; Wed, 8 Jun 2016 06:38:58 -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 hLUwAJdGyzEj for ; Wed, 8 Jun 2016 06:38: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 21FD612D5CA for ; Wed, 8 Jun 2016 06:38:50 -0700 (PDT) Received: from [192.168.0.14] (chello213047163139.5.15.vie.surfer.at [::ffff:213.47.163.139]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 08 Jun 2016 15:38:50 +0200 id 0000000000000041.0000000057581FEA.00000C6F Message-ID: <57581FE8.9000700@das-werkstatt.com> Date: Wed, 08 Jun 2016 15:38:48 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: cellar@ietf.org References: <57581CA6.3030207@das-werkstatt.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Invalid link in ffv1.html specs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 13:38:59 -0000 On 06/08/2016 03:32 PM, Ashley Blewer wrote: > nice catch, Peter. > > We fully converted FFV1 to Markdown: > https://github.com/FFmpeg/FFV1/blob/master/ffv1.md > > I don't know when the legacy LYX was removed from Github though (without > digging into source code history). @Luca, Ashley: Thanks! So I did remember correctly ;) So the link in the mediaarea.net specs should be updated to point to the actual latest version (in Markdown)? Kind regards, Pb From nobody Wed Jun 8 06:43:58 2016 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 0B9C412D16F for ; Wed, 8 Jun 2016 06:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 lnlW2M8UUDaN for ; Wed, 8 Jun 2016 06:43:55 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 315F512D5FB for ; Wed, 8 Jun 2016 06:43:55 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id z189so126824842itg.0 for ; Wed, 08 Jun 2016 06:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U+odahH6kpnfK3bNePFDS4koQSaXpCmaDOa1xycSOmw=; b=Qp/PFMx3UhdEAzIYZ5kWjoCW8JTK+wEN/j4jAkcQJEKrJbNunDIBj+B+++rQx4A/sJ JUXQ6js/ZfpAzwD95nbGNvC0l/KUJ5EGA08FuEmCohXnc4TSTdU+xClONC2l1UsCY8IT WXjHNfb9HGYJgwwmajTmQNO5oU39rvnzQWIMC/32sB/McS6M0+X+xRLS0TeZyCpi4nwl mWohsFFkXmo0nVfjiI7wo6N7lgFwfPwxLEP4TuCxKgYYrZm5difJhPU9J+2SmbxUcpo6 n2HXpIZIDxppGsVLLTdA7tiaD8H1njoV6jtrgysniiF54ecznlr3q5Donj0T8OdHv1Ox u5XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U+odahH6kpnfK3bNePFDS4koQSaXpCmaDOa1xycSOmw=; b=a1byHXU6y5HABIxjDf4iTr2Mn8Z2OTnmiDYE2il9tyJGxzGmw2CBRdwZKEiWyfR3uA oyp5KOO4k/gL3wjiuXjh3QgCejOt/PR23ZcAQHfoQ01QoHrkjttvbyxcckUpzBOrIEPj OwiTgxPx5g0ykA43ATc5FrFpzXXDGTz3fd+3h7mVAW/DImJyhD9iUI0L5k1cAsZwM5t1 KhpLs9Zbot8dj8G8kzQmfGuopKCfuHeUj2voL57rghyzh7beO43lOeb2k1oD76Pgvy+x mMP0HXCmffhJ8QIPv12d+HyYDHWb3a1TIdjszFj89VRUsTedrfkTgA7YxCniA/YVkuYb I9Wg== X-Gm-Message-State: ALyK8tLEo+qG6qX30JXoL/sege2bnb2yKdZL4SO/+ZSf7xRtaP0epeh9DnZF/tWXoQKwicUFiQExmhs0cxdogg== X-Received: by 10.36.39.3 with SMTP id g3mr8015978ita.53.1465393434553; Wed, 08 Jun 2016 06:43:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.133.197 with HTTP; Wed, 8 Jun 2016 06:43:54 -0700 (PDT) In-Reply-To: <57581FE8.9000700@das-werkstatt.com> References: <57581CA6.3030207@das-werkstatt.com> <57581FE8.9000700@das-werkstatt.com> From: Ashley Blewer Date: Wed, 8 Jun 2016 09:43:54 -0400 Message-ID: To: "Peter B." Content-Type: multipart/alternative; boundary=001a1147cc2e1f95310534c47f2c Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Invalid link in ffv1.html specs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 13:43:57 -0000 --001a1147cc2e1f95310534c47f2c Content-Type: text/plain; charset=UTF-8 Yes. Or now that the FFV1-spec-to-Markdown conversion is solid, CELLAR should probably link directly to the Github page. The HTML hosted on MediaArea is, I presume?, an earlier rendering of the Markdown from the Makefile. The Markdown now directs to https://raw.github.com/FFmpeg/FFV1/master/ffv1.md. Ashley On Wed, Jun 8, 2016 at 9:38 AM, Peter B. wrote: > On 06/08/2016 03:32 PM, Ashley Blewer wrote: > > nice catch, Peter. > > > > We fully converted FFV1 to Markdown: > > https://github.com/FFmpeg/FFV1/blob/master/ffv1.md > > > > I don't know when the legacy LYX was removed from Github though (without > > digging into source code history). > > @Luca, Ashley: > > Thanks! So I did remember correctly ;) > > So the link in the mediaarea.net specs should be updated to point to the > actual latest version (in Markdown)? > > > Kind regards, > Pb > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a1147cc2e1f95310534c47f2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes. Or now that the FFV1-spec-to-Markdown conversion is s= olid, CELLAR should probably link directly to the Github page.

The HTML hosted on MediaArea is, I presume?, an earlier rendering of= the Markdown from the Makefile. The Markdown now directs to=C2=A0https://raw.github.c= om/FFmpeg/FFV1/master/ffv1.md.

Ashley

On Wed, Jun 8,= 2016 at 9:38 AM, Peter B. <pb@das-werkstatt.com> wrote:<= br>
On 06/08/2016 03:32 PM, = Ashley Blewer wrote:
> nice catch, Peter.
>
> We fully converted FFV1 to Markdown:
> https://github.com/FFmpeg/FFV1/blob/master/ff= v1.md
>
> I don't know when the legacy LYX was removed from Github though (w= ithout
> digging into source code history).

@Luca, Ashley:

Thanks! So I did remember correctly ;)

So the link in the mediaarea.net specs should be updated to point to the
actual latest version (in Markdown)?


Kind regards,
Pb

_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

--001a1147cc2e1f95310534c47f2c-- From nobody Wed Jun 8 06:44:21 2016 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 CEBE712D8E4 for ; Wed, 8 Jun 2016 06:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 3Zf91YZCOSIp for ; Wed, 8 Jun 2016 06:44:18 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 000D912D8E3 for ; Wed, 8 Jun 2016 06:44:17 -0700 (PDT) Received: from [146.96.19.240] (port=13864 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bAdmJ-000nNY-SO; Wed, 08 Jun 2016 09:44:16 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <57581FE8.9000700@das-werkstatt.com> Date: Wed, 8 Jun 2016 09:44:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6C65B7DE-578E-4E41-A53F-38F58D5C828C@dericed.com> References: <57581CA6.3030207@das-werkstatt.com> <57581FE8.9000700@das-werkstatt.com> To: Peter Bubestinger X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Invalid link in ffv1.html specs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 13:44:20 -0000 > On Jun 8, 2016, at 9:38 AM, Peter B. wrote: >=20 > On 06/08/2016 03:32 PM, Ashley Blewer wrote: >> nice catch, Peter. >>=20 >> We fully converted FFV1 to Markdown: >> https://github.com/FFmpeg/FFV1/blob/master/ffv1.md >>=20 >> I don't know when the legacy LYX was removed from Github though = (without >> digging into source code history). >=20 > @Luca, Ashley: >=20 > Thanks! So I did remember correctly ;) >=20 > So the link in the mediaarea.net specs should be updated to point to = the > actual latest version (in Markdown)? The link to the mediaarea.net page should be removed. It was set up = while we were working on the makefile. At this point the ffv1.md file is = "the latest version" of itself so it should refer to a static abandoned = page on mediaarea.net. Dave Rice > Kind regards, > Pb >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Wed Jun 8 07:17:34 2016 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 BE19512D8CD for ; Wed, 8 Jun 2016 07:17:33 -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 BobN6UxVaJx8 for ; Wed, 8 Jun 2016 07:17:31 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981D312D59D for ; Wed, 8 Jun 2016 07:17:31 -0700 (PDT) Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 71CACC5A88 for ; Wed, 8 Jun 2016 16:17:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id WB7nCsUutw3S for ; Wed, 8 Jun 2016 16:17:27 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 851E4C5A8D for ; Wed, 8 Jun 2016 16:17:27 +0200 (CEST) Date: Wed, 8 Jun 2016 16:17:18 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160608141718.GV4636@nb4> References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="36+Jv5wzUORg1Ut4" Content-Disposition: inline In-Reply-To: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] [PATCH FFV1] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 14:17:33 -0000 --36+Jv5wzUORg1Ut4 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 06, 2016 at 01:07:05PM +0200, Jerome Martinez wrote: > As "height" word is currently used for both height in raster > elements and height in pixels, I do make it explicit when the pixel > height is used. > I remove any reference to Plane() (which is not defined) in order to > have colorspace_type and slice_pixel_height in the same block > whatever is the color_space. > The slice height in pixels is defined; explicit floor() during its > computing (I use the mathematical symbol instead of the C function > name in order to be more generic) >=20 >=20 > ffv1.md | 23 ++++++++++++++++++----- > 1 file changed, 18 insertions(+), 5 deletions(-) > 27e2cc62b6d01343143ef004d80b487b21e326f0 0001-SliceContent-description-u= pdate.patch > From 62ead20d25c9b96931eeace0df8f5b7284a4f4a3 Mon Sep 17 00:00:00 2001 > From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D > Date: Mon, 6 Jun 2016 13:04:05 +0200 > Subject: [PATCH] SliceContent description update >=20 > Difference between height in slice raster elements and pixels > Defines slice_pixel_height > --- > ffv1.md | 23 ++++++++++++++++++----- > 1 file changed, 18 insertions(+), 5 deletions(-) >=20 > diff --git a/ffv1.md b/ffv1.md > index a503d6c..66ed0e2 100644 > --- a/ffv1.md > +++ b/ffv1.md > @@ -125,6 +125,12 @@ __!a__ means boolean logical "not". > __a=A0?=A0b=A0:=A0c__ if a is true, then b, otherwise c. > --------------- --------------------------------------------------------= -------- > =20 > +## Mathematical functions > + > +--------------- --------------------------------------------= -------------------- > +__⌊a⌋__ means the integral part of a =20 > +--------------- --------------------------------------------= -------------------- what is the integer part of -1.5 ? and is that intended ? i suggest "the largest integer less than or equal to a" > + > ## Order of operation precedence > =20 > When order of precedence is not indicated explicitly by use of parenthes= es, operations are evaluated in the following order (from top to bottom, op= erations of same precedence being evaluated from left to right). This order= of operations is based on the order of operations used in Standard C. > @@ -462,9 +468,9 @@ The same context which is initialized to 128 is used = for all fields in the heade > =20 > The following MUST be provided by external means during initialization o= f the decoder: > =20 > -**frame\_width** is defined as frame width in pixels. > +**frame\_pixel\_width** is defined as frame width in pixels. > =20 > -**frame\_height** is defined as frame height in pixels. > +**frame\_pixel\_height** is defined as frame height in pixels. > =20 > Default values at the decoder initialization phase: > =20 > @@ -623,9 +629,10 @@ Inferred to be 0 if not present. > |SliceContent( ) { | type | > |=A0=A0=A0=A0if( colorspace\_type =3D=3D 0) { = | | > |=A0=A0=A0=A0=A0=A0=A0=A0for( p =3D 0; p \< primary\_color\_count; p++ )= { | | > -|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Plane( p ) = | | > +|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0for( y =3D 0; y \< slice\_pixel\_he= ight; y++ ) | | > +|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Line( p, y ) = | | this doesnt work as not all planes have the same size in case of chroma subsampling [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle --36+Jv5wzUORg1Ut4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldYKO4ACgkQYR7HhwQLD6sKWgCcCLZaz+VRnTc4P6w9syHJdVk9 CfQAnRECZLleWXZNBzfkrggyWDkO2Prh =C/dB -----END PGP SIGNATURE----- --36+Jv5wzUORg1Ut4-- From nobody Wed Jun 8 07:39:41 2016 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 83ADD12D84B for ; Wed, 8 Jun 2016 07:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 iec65m8Jwiti for ; Wed, 8 Jun 2016 07:39:38 -0700 (PDT) Received: from 7.mo178.mail-out.ovh.net (7.mo178.mail-out.ovh.net [46.105.58.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4740B12D1DD for ; Wed, 8 Jun 2016 07:39:37 -0700 (PDT) Received: from player791.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id E5EACFFCF96 for ; Wed, 8 Jun 2016 16:39:35 +0200 (CEST) Received: from [192.168.2.101] (p5DDB5AFE.dip0.t-ipconnect.de [93.219.90.254]) (Authenticated sender: jerome@francoallemand.eu) by player791.ha.ovh.net (Postfix) with ESMTPSA id A7046420073 for ; Wed, 8 Jun 2016 16:39:35 +0200 (CEST) To: cellar@ietf.org References: <57581CA6.3030207@das-werkstatt.com> <57581FE8.9000700@das-werkstatt.com> From: Jerome Martinez Message-ID: <369ee2f7-c6df-7e92-ba54-08a12ad2b304@mediaarea.net> Date: Wed, 8 Jun 2016 16:39:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <57581FE8.9000700@das-werkstatt.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 3325626852537798801 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrjeefgdejhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Invalid link in ffv1.html specs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 14:39:41 -0000 Le 08/06/2016 15:38, Peter B. a crit : > So the link in the mediaarea.net specs should be updated to point to the > actual latest version (in Markdown)? the link was a temporary (check the directory in the link ;-) ) copy of the HTML output and should not be used in official publications, we forgot to change that. From nobody Wed Jun 8 07:41:41 2016 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 97D3312D672 for ; Wed, 8 Jun 2016 07:41:39 -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] 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 hIxCBu64uDMz for ; Wed, 8 Jun 2016 07:41:37 -0700 (PDT) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 9BED512D8A3 for ; Wed, 8 Jun 2016 07:41:37 -0700 (PDT) Received: from [192.168.0.3] (dynamic-adsl-84-220-81-12.clienti.tiscali.it [84.220.81.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id DD9DC340D3C for ; Wed, 8 Jun 2016 14:41:35 +0000 (UTC) To: cellar@ietf.org References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> From: Luca Barbato Organization: Libav Message-ID: <57582E9C.6020101@libav.org> Date: Wed, 8 Jun 2016 16:41:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20160608141718.GV4636@nb4> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] [PATCH FFV1] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 14:41:39 -0000 On 08/06/16 16:17, Michael Niedermayer wrote: > On Mon, Jun 06, 2016 at 01:07:05PM +0200, Jerome Martinez wrote: >> As "height" word is currently used for both height in raster >> elements and height in pixels, I do make it explicit when the pixel >> height is used. >> I remove any reference to Plane() (which is not defined) in order to >> have colorspace_type and slice_pixel_height in the same block >> whatever is the color_space. >> The slice height in pixels is defined; explicit floor() during its >> computing (I use the mathematical symbol instead of the C function >> name in order to be more generic) >> >> > >> ffv1.md | 23 ++++++++++++++++++----- >> 1 file changed, 18 insertions(+), 5 deletions(-) >> 27e2cc62b6d01343143ef004d80b487b21e326f0 0001-SliceContent-description-update.patch >> From 62ead20d25c9b96931eeace0df8f5b7284a4f4a3 Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= >> Date: Mon, 6 Jun 2016 13:04:05 +0200 >> Subject: [PATCH] SliceContent description update >> >> Difference between height in slice raster elements and pixels >> Defines slice_pixel_height >> --- >> ffv1.md | 23 ++++++++++++++++++----- >> 1 file changed, 18 insertions(+), 5 deletions(-) >> >> diff --git a/ffv1.md b/ffv1.md >> index a503d6c..66ed0e2 100644 >> --- a/ffv1.md >> +++ b/ffv1.md >> @@ -125,6 +125,12 @@ __!a__ means boolean logical "not". >> __a ? b : c__ if a is true, then b, otherwise c. >> --------------- ---------------------------------------------------------------- >> >> +## Mathematical functions >> + > >> +--------------- ---------------------------------------------------------------- >> +__⌊a⌋__ means the integral part of a >> +--------------- ---------------------------------------------------------------- > > what is the integer part of -1.5 ? > and is that intended ? > > i suggest "the largest integer less than or equal to a" > > >> + >> ## Order of operation precedence >> >> When order of precedence is not indicated explicitly by use of parentheses, operations are evaluated in the following order (from top to bottom, operations of same precedence being evaluated from left to right). This order of operations is based on the order of operations used in Standard C. >> @@ -462,9 +468,9 @@ The same context which is initialized to 128 is used for all fields in the heade >> >> The following MUST be provided by external means during initialization of the decoder: >> >> -**frame\_width** is defined as frame width in pixels. >> +**frame\_pixel\_width** is defined as frame width in pixels. >> >> -**frame\_height** is defined as frame height in pixels. >> +**frame\_pixel\_height** is defined as frame height in pixels. >> >> Default values at the decoder initialization phase: >> >> @@ -623,9 +629,10 @@ Inferred to be 0 if not present. >> |SliceContent( ) { | type | >> | if( colorspace\_type == 0) { | | >> | for( p = 0; p \< primary\_color\_count; p++ ) { | | >> -| Plane( p ) | | >> +| for( y = 0; y \< slice\_pixel\_height; y++ ) | | >> +| Line( p, y ) | | > > this doesnt work as not all planes have the same size in case of > chroma subsampling > If there is a plan to support non-planar formats as well probably it could be spun as a separate description depending on the colorspace. lu From nobody Wed Jun 8 07:46:33 2016 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 9CF0B12D635 for ; Wed, 8 Jun 2016 07:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 ko91d9WEkXcX for ; Wed, 8 Jun 2016 07:46:30 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 629AF12D694 for ; Wed, 8 Jun 2016 07:46:28 -0700 (PDT) Received: from [146.96.19.240] (port=33352 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bAekT-002FdR-HP; Wed, 08 Jun 2016 10:46:27 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_8D7C8958-AB23-4147-B31E-246076A5D3DA" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <57582E9C.6020101@libav.org> Date: Wed, 8 Jun 2016 10:46:23 -0400 Message-Id: <9EEDB2AE-E1AD-4F06-B2F5-23C8047F7498@dericed.com> References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <57582E9C.6020101@libav.org> To: Luca Barbato X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] [PATCH FFV1] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 14:46:31 -0000 --Apple-Mail=_8D7C8958-AB23-4147-B31E-246076A5D3DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 8, 2016, at 10:41 AM, Luca Barbato = wrote: >=20 > On 08/06/16 16:17, Michael Niedermayer wrote: >> On Mon, Jun 06, 2016 at 01:07:05PM +0200, Jerome Martinez wrote: >>> As "height" word is currently used for both height in raster >>> elements and height in pixels, I do make it explicit when the pixel >>> height is used. >>> I remove any reference to Plane() (which is not defined) in order to >>> have colorspace_type and slice_pixel_height in the same block >>> whatever is the color_space. >>> The slice height in pixels is defined; explicit floor() during its >>> computing (I use the mathematical symbol instead of the C function >>> name in order to be more generic) >>>=20 >>>=20 >>=20 >>> ffv1.md | 23 ++++++++++++++++++----- >>> 1 file changed, 18 insertions(+), 5 deletions(-) >>> 27e2cc62b6d01343143ef004d80b487b21e326f0 = 0001-SliceContent-description-update.patch >>> =46rom 62ead20d25c9b96931eeace0df8f5b7284a4f4a3 Mon Sep 17 00:00:00 = 2001 >>> From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D = >>> Date: Mon, 6 Jun 2016 13:04:05 +0200 >>> Subject: [PATCH] SliceContent description update >>>=20 >>> Difference between height in slice raster elements and pixels >>> Defines slice_pixel_height >>> --- >>> ffv1.md | 23 ++++++++++++++++++----- >>> 1 file changed, 18 insertions(+), 5 deletions(-) >>>=20 >>> diff --git a/ffv1.md b/ffv1.md >>> index a503d6c..66ed0e2 100644 >>> --- a/ffv1.md >>> +++ b/ffv1.md >>> @@ -125,6 +125,12 @@ __!a__ means boolean logical "not". >>> __a ? b : c__ if a is true, then b, otherwise c. >>> --------------- = ---------------------------------------------------------------- >>>=20 >>> +## Mathematical functions >>> + >>=20 >>> +--------------- = ---------------------------------------------------------------- >>> +__⌊a⌋__ means the integral part of a >>> +--------------- = ---------------------------------------------------------------- >>=20 >> what is the integer part of -1.5 ? >> and is that intended ? >>=20 >> i suggest "the largest integer less than or equal to a" >>=20 >>=20 >>> + >>> ## Order of operation precedence >>>=20 >>> When order of precedence is not indicated explicitly by use of = parentheses, operations are evaluated in the following order (from top = to bottom, operations of same precedence being evaluated from left to = right). This order of operations is based on the order of operations = used in Standard C. >>> @@ -462,9 +468,9 @@ The same context which is initialized to 128 is = used for all fields in the heade >>>=20 >>> The following MUST be provided by external means during = initialization of the decoder: >>>=20 >>> -**frame\_width** is defined as frame width in pixels. >>> +**frame\_pixel\_width** is defined as frame width in pixels. >>>=20 >>> -**frame\_height** is defined as frame height in pixels. >>> +**frame\_pixel\_height** is defined as frame height in pixels. >>>=20 >>> Default values at the decoder initialization phase: >>>=20 >>> @@ -623,9 +629,10 @@ Inferred to be 0 if not present. >>> |SliceContent( ) { | type = | >>> | if( colorspace\_type =3D=3D 0) { | = | >>> | for( p =3D 0; p \< primary\_color\_count; p++ ) { | = | >>> -| Plane( p ) | = | >>> +| for( y =3D 0; y \< slice\_pixel\_height; y++ ) | = | >>> +| Line( p, y ) | = | >>=20 >> this doesnt work as not all planes have the same size in case of >> chroma subsampling >>=20 >=20 > If there is a plan to support non-planar formats as well probably it = could be spun as a separate description depending on the colorspace. I would like to see bayer formats in the plan at some point to = accommodate raw camera and film scanner data. Dave Rice --Apple-Mail=_8D7C8958-AB23-4147-B31E-246076A5D3DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jun 8, 2016, at 10:41 AM, Luca Barbato <luca.barbato@libav.org> wrote:

On 08/06/16 16:17, Michael Niedermayer = wrote:
On Mon, = Jun 06, 2016 at 01:07:05PM +0200, Jerome Martinez wrote:
As "height" word is = currently used for both height in raster
elements and = height in pixels, I do make it explicit when the pixel
height is used.
I remove any reference to = Plane() (which is not defined) in order to
have = colorspace_type and slice_pixel_height in the same block
whatever is the color_space.
The slice height = in pixels is defined; explicit floor() during its
computing = (I use the mathematical symbol instead of the C function
name in order to be more generic)



 ffv1.md |   23 = ++++++++++++++++++-----
 1 file changed, 18 = insertions(+), 5 deletions(-)
27e2cc62b6d01343143ef004d80b487b21e326f0 =  0001-SliceContent-description-update.patch
=46rom = 62ead20d25c9b96931eeace0df8f5b7284a4f4a3 Mon Sep 17 00:00:00 2001
From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D = <jerome@mediaarea.net>
Date: Mon, 6 Jun = 2016 13:04:05 +0200
Subject: [PATCH] SliceContent = description update

Difference between = height in slice raster elements and pixels
Defines = slice_pixel_height
---
 ffv1.md | 23 = ++++++++++++++++++-----
 1 file changed, 18 = insertions(+), 5 deletions(-)

diff --git = a/ffv1.md b/ffv1.md
index a503d6c..66ed0e2 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ = -125,6 +125,12 @@ __!a__ =          means boolean = logical "not".
 __a ? b : c__   if a is = true, then b, otherwise c.
 --------------- = ----------------------------------------------------------------

+## Mathematical functions
+

+--------------- =             --= --------------------------------------------------------------
+__&lfloor;a&rfloor;__ =       means the integral part of a
+--------------- =             --= --------------------------------------------------------------

what is the integer part of -1.5 = ?
and is that intended ?

i = suggest "the largest integer less than or equal to a"


+
 ## Order of operation precedence

 When order of precedence is not indicated explicitly by = use of parentheses, operations are evaluated in the following order = (from top to bottom, operations of same precedence being evaluated from = left to right). This order of operations is based on the order of = operations used in Standard C.
@@ -462,9 +468,9 @@ The = same context which is initialized to 128 is used for all fields in the = heade

 The following MUST be provided = by external means during initialization of the decoder:

-**frame\_width** is defined as frame width in pixels.
+**frame\_pixel\_width** is defined as frame width in = pixels.

-**frame\_height** is defined as = frame height in pixels.
+**frame\_pixel\_height** is = defined as frame height in pixels.

 Default values at the decoder initialization phase:

@@ -623,9 +629,10 @@ Inferred to be 0 if not = present.
 |SliceContent( ) { =             &n= bsp;           &nbs= p;            =      | type  |
 | =    if( colorspace\_type =3D=3D 0) { =             &n= bsp;           &nbs= p;  |       |
 |        for( p =3D = 0; p \< primary\_color\_count; p++ ) {     | =       |
-| =            Plane( = p ) =             &n= bsp;           &nbs= p;            = |       |
+| =            for( y = =3D 0; y \< slice\_pixel\_height; y++ )    | =       |
+| =             &n= bsp;  Line( p, y ) =             &n= bsp;           &nbs= p;      | =       |

this doesnt work as not all planes have the same size in case = of
chroma subsampling


If there is a plan to support non-planar formats = as well probably it could be spun as a separate description depending on = the colorspace.

I would = like to see bayer formats in the plan at some point to accommodate raw = camera and film scanner data.
Dave Rice

= --Apple-Mail=_8D7C8958-AB23-4147-B31E-246076A5D3DA-- From nobody Wed Jun 8 07:57:00 2016 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 A2D1E12D992 for ; Wed, 8 Jun 2016 07:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 wxWMrn6YsGME for ; Wed, 8 Jun 2016 07:56:57 -0700 (PDT) Received: from 5.mo178.mail-out.ovh.net (5.mo178.mail-out.ovh.net [46.105.51.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5436112D991 for ; Wed, 8 Jun 2016 07:56:57 -0700 (PDT) Received: from player791.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id 7BE7B1008E57 for ; Wed, 8 Jun 2016 16:56:55 +0200 (CEST) Received: from [192.168.2.101] (p5DDB5AFE.dip0.t-ipconnect.de [93.219.90.254]) (Authenticated sender: jerome@francoallemand.eu) by player791.ha.ovh.net (Postfix) with ESMTPSA id 42D4E42007F for ; Wed, 8 Jun 2016 16:56:55 +0200 (CEST) To: cellar@ietf.org References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> From: Jerome Martinez Message-ID: <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> Date: Wed, 8 Jun 2016 16:56:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160608141718.GV4636@nb4> Content-Type: multipart/alternative; boundary="------------8078E42861D39824A482C4F1" X-Ovh-Tracer-Id: 3618360825761239185 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrjeefgdejkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] [PATCH FFV1] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 14:56:59 -0000 This is a multi-part message in MIME format. --------------8078E42861D39824A482C4F1 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 08/06/2016 16:17, Michael Niedermayer a crit : > On Mon, Jun 06, 2016 at 01:07:05PM +0200, Jerome Martinez wrote: > >> +--------------- ---------------------------------------------------------------- >> +__⌊a⌋__ means the integral part of a >> +--------------- ---------------------------------------------------------------- > what is the integer part of -1.5 ? > and is that intended ? > > i suggest "the largest integer less than or equal to a" it is intended for positive values (pixels), and from https://en.wikipedia.org/wiki/Floor_and_ceiling_functions : "The floor function is also called the *greatest integer* or *entier* (French for "integer") function, and its value at /x/ is called the *integral part* or *integer part* of /x/; for negative values of /x/ the latter terms are sometimes instead taken to be the value of the /ceiling/ function, i.e., the value of /x/ rounded to an integer towards 0." So I reused the "integral part" wording from this definition, and the integer part of -1.5 is 1 which is sometimes used for floor of negative number (not in C/C++, but maybe elsewhere?) anyway, I have no strong opinion on it, I just preferred to use the Wikipedia definition rather than the C/C++ spec definition and I am using it only for positive values, and if nobody else has an opinion on it I am OK to switch to the C/C++ definition. > > >> + >> ## Order of operation precedence >> >> When order of precedence is not indicated explicitly by use of parentheses, operations are evaluated in the following order (from top to bottom, operations of same precedence being evaluated from left to right). This order of operations is based on the order of operations used in Standard C. >> @@ -462,9 +468,9 @@ The same context which is initialized to 128 is used for all fields in the heade >> >> The following MUST be provided by external means during initialization of the decoder: >> >> -**frame\_width** is defined as frame width in pixels. >> +**frame\_pixel\_width** is defined as frame width in pixels. >> >> -**frame\_height** is defined as frame height in pixels. >> +**frame\_pixel\_height** is defined as frame height in pixels. >> >> Default values at the decoder initialization phase: >> >> @@ -623,9 +629,10 @@ Inferred to be 0 if not present. >> |SliceContent( ) { | type | >> | if( colorspace\_type == 0) { | | >> | for( p = 0; p \< primary\_color\_count; p++ ) { | | >> -| Plane( p ) | | >> +| for( y = 0; y \< slice\_pixel\_height; y++ ) | | >> +| Line( p, y ) | | > this doesnt work as not all planes have the same size in case of > chroma subsampling ho, right, slice_pixel_height should be slice_pixel_height[p] and its definition defined accordingly. but I reused the code for colorspace_type == 1, which does not make any difference between planes, and I don't see constraints on h_chroma_subsample and v_chroma_subsample when colorspace_type == 1. I need a clarification: are the following settings valid? - colorspace_type == 1 and chroma_planes == 0. - colorspace_type == 1 and chroma_planes == 1 and (h_chroma_subsample not 1 or v_chroma_subsample not 1). I see nothing about such forbidden settings and the part "for( y = 0; y < height; y++ )" already in the spec would be wrong in that case, for the same reason, or did I misunderstand something? --------------8078E42861D39824A482C4F1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Le 08/06/2016 16:17, Michael Niedermayer a crit:
On Mon, Jun 06, 2016 at 01:07:05PM +0200, Jerome Martinez wrote:


+---------------             ----------------------------------------------------------------
+__&lfloor;a&rfloor;__       means the integral part of a  
+---------------             ----------------------------------------------------------------

what is the integer part of -1.5 ?
and is that intended ?

i suggest "the largest integer less than or equal to a"

it is intended for positive values (pixels), and from https://en.wikipedia.org/wiki/Floor_and_ceiling_functions :
"The floor function is also called the greatest integer or entier (French for "integer") function, and its value at x is called the integral part or integer part of x; for negative values of x the latter terms are sometimes instead taken to be the value of the ceiling function, i.e., the value of x rounded to an integer towards 0."

So I reused the "integral part" wording from this definition, and the integer part of -1.5 is 1 which is sometimes used for floor of negative number (not in C/C++, but maybe elsewhere?)

anyway, I have no strong opinion on it, I just preferred to use the Wikipedia definition rather than the C/C++ spec definition and I am using it only for positive values, and if nobody else has an opinion on it I am OK to switch to the C/C++ definition.





+
 ## Order of operation precedence
 
 When order of precedence is not indicated explicitly by use of parentheses, operations are evaluated in the following order (from top to bottom, operations of same precedence being evaluated from left to right). This order of operations is based on the order of operations used in Standard C.
@@ -462,9 +468,9 @@ The same context which is initialized to 128 is used for all fields in the heade
 
 The following MUST be provided by external means during initialization of the decoder:
 
-**frame\_width** is defined as frame width in pixels.
+**frame\_pixel\_width** is defined as frame width in pixels.
 
-**frame\_height** is defined as frame height in pixels.
+**frame\_pixel\_height** is defined as frame height in pixels.
 
 Default values at the decoder initialization phase:
 
@@ -623,9 +629,10 @@ Inferred to be 0 if not present.
 |SliceContent( ) {                                           | type  |
 |if( colorspace\_type == 0) {                            |       |
 |for( p = 0; p \< primary\_color\_count; p++ ) {     |       |
-|Plane( p )                                      |       |
+|for( y = 0; y \< slice\_pixel\_height; y++ )    |       |
+|Line( p, y )                                |       |

this doesnt work as not all planes have the same size in case of
chroma subsampling

ho, right, slice_pixel_height should be slice_pixel_height[p] and its definition defined accordingly.
but I reused the code for colorspace_type == 1, which does not make any difference between planes, and I don't see constraints on h_chroma_subsample and v_chroma_subsample when colorspace_type == 1.

I need a clarification: are the following settings valid?
- colorspace_type == 1 and chroma_planes == 0.
- colorspace_type == 1 and chroma_planes == 1 and (h_chroma_subsample not 1 or v_chroma_subsample not 1). I see nothing about such forbidden settings and the part "for( y = 0; y < height; y++ )" already in the spec would be wrong in that case, for the same reason, or did I misunderstand something?



--------------8078E42861D39824A482C4F1-- From nobody Wed Jun 8 08:33:57 2016 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 6EC8012D81E for ; Wed, 8 Jun 2016 08:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 RsjOott7YEcK for ; Wed, 8 Jun 2016 08:33:54 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 1047012D665 for ; Wed, 8 Jun 2016 08:33:54 -0700 (PDT) Received: from [146.96.19.240] (port=17698 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bAfUN-003NxP-01; Wed, 08 Jun 2016 11:33:53 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <57581BE3.4050808@das-werkstatt.com> Date: Wed, 8 Jun 2016 11:33:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <524C1D1C-3466-4B21-AF9D-688FF4B13412@dericed.com> References: <57581BE3.4050808@das-werkstatt.com> To: Peter Bubestinger X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] FFV1: Correct full name of the codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 15:33:57 -0000 > On Jun 8, 2016, at 9:21 AM, Peter B. wrote: >=20 > Hi! >=20 > I know this might come as a super-stupid question from me, but: >=20 > @Michael Niedermayer: > What does the abbreviation "FFV1" now really stand for? >=20 > Source code says "FF Video Codec 1": > = http://git.videolan.org/?p=3Dffmpeg.git;a=3Dblob_plain;f=3Dlibavcodec/ffv1= enc.c;hb=3DHEAD >=20 > Yet, I silently assumed it's "FFmpeg Video Codec 1"... I hadn't had that assumption, but considered that the 'FF' of 'FFV1' is = the same meaning as the 'FF' in FFmpeg, ffprobe, ffplay, etc, which = AFAIK is 'fast forward'. Still I almost never hear any reference to "FF Video Codec 1" but almost = entirely it is referenced as FFV1. > I just wanted to clarify this ;) >=20 >=20 > Thanksalot in advance, > Pb >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Wed Jun 8 08:35:26 2016 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 80D9A12D941 for ; Wed, 8 Jun 2016 08:35:24 -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 rtv68oqt_rHC for ; Wed, 8 Jun 2016 08:35:23 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8329712D942 for ; Wed, 8 Jun 2016 08:35:22 -0700 (PDT) Received: from mfilter49-d.gandi.net (mfilter49-d.gandi.net [217.70.178.180]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 3F149FB8D5 for ; Wed, 8 Jun 2016 17:35:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter49-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter49-d.gandi.net (mfilter49-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id zHiq9E8_MHst for ; Wed, 8 Jun 2016 17:35:18 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 91A20FB8E4 for ; Wed, 8 Jun 2016 17:35:18 +0200 (CEST) Date: Wed, 8 Jun 2016 17:35:08 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160608153508.GW4636@nb4> References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xUyMHIOv46mebLva" Content-Disposition: inline In-Reply-To: <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] [PATCH FFV1] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 15:35:24 -0000 --xUyMHIOv46mebLva Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 08, 2016 at 04:56:46PM +0200, Jerome Martinez wrote: > Le 08/06/2016 =E0 16:17, Michael Niedermayer a =E9crit : > >On Mon, Jun 06, 2016 at 01:07:05PM +0200, Jerome Martinez wrote: [...] > >> ## Order of operation precedence > >> When order of precedence is not indicated explicitly by use of parent= heses, operations are evaluated in the following order (from top to bottom,= operations of same precedence being evaluated from left to right). This or= der of operations is based on the order of operations used in Standard C. > >>@@ -462,9 +468,9 @@ The same context which is initialized to 128 is use= d for all fields in the heade > >> The following MUST be provided by external means during initializatio= n of the decoder: > >>-**frame\_width** is defined as frame width in pixels. > >>+**frame\_pixel\_width** is defined as frame width in pixels. > >>-**frame\_height** is defined as frame height in pixels. > >>+**frame\_pixel\_height** is defined as frame height in pixels. > >> Default values at the decoder initialization phase: > >>@@ -623,9 +629,10 @@ Inferred to be 0 if not present. > >> |SliceContent( ) { | type | > >> | if( colorspace\_type =3D=3D 0) { | = | > >> | for( p =3D 0; p \< primary\_color\_count; p++ ) { | = | > >>-| Plane( p ) | | > >>+| for( y =3D 0; y \< slice\_pixel\_height; y++ ) | = | > >>+| Line( p, y ) | | > >this doesnt work as not all planes have the same size in case of > >chroma subsampling >=20 > ho, right, slice_pixel_height should be slice_pixel_height[p] and > its definition defined accordingly. > but I reused the code for colorspace_type =3D=3D 1, which does not make > any difference between planes, and I don't see constraints on > h_chroma_subsample and v_chroma_subsample when colorspace_type =3D=3D 1. >=20 > I need a clarification: are the following settings valid? > - colorspace_type =3D=3D 1 and chroma_planes =3D=3D 0. > - colorspace_type =3D=3D 1 and chroma_planes =3D=3D 1 and > (h_chroma_subsample not 1 or v_chroma_subsample not 1). I see > nothing about such forbidden settings and the part "for( y =3D 0; y < > height; y++ )" already in the spec would be wrong in that case, for > the same reason, or did I misunderstand something? The implementation does not support these cases, so you can do either define them to something usefull or disallow, it should not affect anything existing [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus --xUyMHIOv46mebLva Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldYOywACgkQYR7HhwQLD6t8SACfY63DPPdRH+rq1ICzJhRzcM5P xC4AnjdCDqJhwFUqfHd5d7dz0sv/9Qqu =0O7Y -----END PGP SIGNATURE----- --xUyMHIOv46mebLva-- From nobody Wed Jun 8 08:54:07 2016 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 0D20312D9CE for ; Wed, 8 Jun 2016 08:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 3cHnMfcWFY6W for ; Wed, 8 Jun 2016 08:54:04 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 1D77F12D77B for ; Wed, 8 Jun 2016 08:53:59 -0700 (PDT) Received: from [146.96.19.240] (port=31881 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bAfnp-003kfW-62; Wed, 08 Jun 2016 11:53:58 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <99F7F8B9-86D7-4A91-99A8-B700C7857EDE@dericed.com> Date: Wed, 8 Jun 2016 11:53:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6173E5B6-6A20-4803-8807-BB483E295EC6@dericed.com> References: <99F7F8B9-86D7-4A91-99A8-B700C7857EDE@dericed.com> To: cellar@ietf.org X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Michael Bradshaw Subject: Re: [Cellar] [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLReadVersion X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 15:54:06 -0000 Bumping this. > On May 24, 2016, at 5:54 PM, Dave Rice wrote: >=20 >=20 >> On May 24, 2016, at 5:47 PM, Luca Barbato = wrote: >>=20 >> On 24/05/16 22:52, Michael Bradshaw wrote: >>> Hi, >>>=20 >>> I propose the following patch for the EBML specification. Currently, >>> EBMLVersion and EBMLReadVersion do not have a range specified, = suggesting >>> the value 0 should be legal (albeit probably nonsensical). >>>=20 >>>=20 >>>> =46rom f0e547502890fa9efa0b966a08544f5b91f8ccd7 Mon Sep 17 00:00:00 = 2001 >>> From: Michael Bradshaw >>> Date: Tue, 17 May 2016 10:14:42 -0700 >>> Subject: [PATCH 1/1] Specify a range of >0 for = EBMLVersion/EBMLReadVersion >>>=20 >>> --- >>> specification.markdown | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>=20 >>> diff --git a/specification.markdown b/specification.markdown >>> index 3f262b9..3fb4b01 100644 >>> --- a/specification.markdown >>> +++ b/specification.markdown >>> @@ -336,7 +336,7 @@ Element Name: EBMLVersion >>> EBML ID: [42][86] >>> Mandatory: Yes >>> Multiple: No >>> - Range: - >>> + Range: >0 >=20 > AFAIK there have only ever been one version of EBML. With = EBMLVersion=3D1. Perhaps instead of ">0=E2=80=9D, we could simply say = =E2=80=9C1=E2=80=9D as no other value is valid. Someday if IETF defines = a version 2 of EBML than the Range can be updated to =E2=80=9C1-2=E2=80=9D= and so on. Any other opinion on this? Should we set EBMLVersion and EBMLReadVersion = to ">0" or simply to be only "1" (since the spec defines no other valid = EBML version)? >>> Default: 1 >>> Element Type: Unsigned Integer >>> Description: The version of EBML parser used to create the = EBML >>> Document. >=20 > I never really looked at this description too closely but perhaps this = should reference the version of the EBML specification rather than the = EBML parser. The version of the parser (i.e. libebml) is not what is = intended here. >=20 >>> @@ -347,7 +347,7 @@ Element Name: EBMLReadVersion >>> EBML ID: [42][F7] >>> Mandatory: Yes >>> Multiple: No >>> - Range: - >>> + Range: >0 >=20 > Same comment as above. >=20 >>> Default: 1 >>> Element Type: Unsigned Integer >>> Description: The minimum EBML version a parser has to support = to >>> read this EBML Document. >>> -- >>> 2.8.0.rc2 >>>=20 >>=20 >>> =3D0 then ? >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Wed Jun 8 09:17:26 2016 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 3516D12D5B7 for ; Wed, 8 Jun 2016 09:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 GmijVfNjUpW2 for ; Wed, 8 Jun 2016 09:17:24 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 E4F1212D0F4 for ; Wed, 8 Jun 2016 09:17:23 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id a5so14309565ita.1 for ; Wed, 08 Jun 2016 09:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Wd/8b8dGht7xWF95QkCs9TBDww+2nrIBDOREEbxwH+4=; b=jJn3VlvsaoKh6SFq8mJj1RLgEVuR8BSpgiV5w6vOHwqBgvG217VIRHwNwNDKZezMza AAOF3n9xmPHACh2rIGukCk4XjDtbiU7M/NucL8+vwCEPzNSKg9UHYvuikHjf1UbDbwdl 06J/QK4k5iZuIBDX6F2ckEUKstZt8BIOEYLB4E4JHdyzRUvsrPDIej2GxSJNtjKiNdkb VdePX9b8f3Q5TECsWs+uH62dEIbxhrF5X/OpQx7rtEuTBslOXyKda8gSRSfY3n6c3iBx E1iJBCEAU/QVcDg7+ITZJ0QsMWrySfPz7xJrLDdrAztGRya76Kk+09S78uUw342NNA69 NyWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Wd/8b8dGht7xWF95QkCs9TBDww+2nrIBDOREEbxwH+4=; b=GERqNhtG7zU4ZUf4YVlp+l4nWtMhTSegHAvfHRC8RAzdMXnJfw4GIjBRLSYqE5Jy0p m1l05w+n3DH9YKIePbGoPEi2rY988jEvuQ2M0Wn9suhHlO4WF5qTmx9KcOypGbc44qg8 2R2tvCE5e93uhbzPWERmkA/W8e1Q0AHVTcAlwTKYC03nnJFV5wKO/7PZAGcLp3N2Z4pz ADpKzCk+4xRhBuC92Ua4n404qarPKGXU+jSSCgAvdzEL7y0Blc769A4NcnWZcQX7oWoe YodpOlCA9iaKxAdZg3pOA8y6USy/1pfICDpMHUbwAov3ARGUMEOunxBmqieEX/VT7nTr xsqw== X-Gm-Message-State: ALyK8tLMo4jpCG1tUZI4VmLgh3HDCuUjQRZEZrTLJikp64OiNdz+JFL+/11X/vuCiUVC8YXtiC9vs3l+A/xhO3MP X-Received: by 10.36.28.201 with SMTP id c192mr9521346itc.96.1465402643192; Wed, 08 Jun 2016 09:17:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.111.214 with HTTP; Wed, 8 Jun 2016 09:17:03 -0700 (PDT) In-Reply-To: <6173E5B6-6A20-4803-8807-BB483E295EC6@dericed.com> References: <99F7F8B9-86D7-4A91-99A8-B700C7857EDE@dericed.com> <6173E5B6-6A20-4803-8807-BB483E295EC6@dericed.com> From: Michael Bradshaw Date: Wed, 8 Jun 2016 09:17:03 -0700 Message-ID: To: Dave Rice Content-Type: multipart/alternative; boundary=001a1144b80c0069700534c6a4e0 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLReadVersion X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 16:17:25 -0000 --001a1144b80c0069700534c6a4e0 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 8, 2016 at 8:53 AM, Dave Rice wrote: > > Any other opinion on this? Should we set EBMLVersion and EBMLReadVersion > to ">0" or simply to be only "1" (since the spec defines no other valid > EBML version)? I'm in favor of requiring it to be only "1" and reserving other values for future standards. --001a1144b80c0069700534c6a4e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 8, 2016 at 8:53 AM, Dave Rice <dave@dericed.com> wrot= e:
Any other opinion on this? Should we set E= BMLVersion and EBMLReadVersion to ">0" or simply to be only &q= uot;1" (since the spec defines no other valid EBML version)?

I'm in favor of requiring it to be only "1&= quot; and reserving other values for future standards.=C2=A0
--001a1144b80c0069700534c6a4e0-- From nobody Wed Jun 8 09:40:49 2016 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 6822B12DA28 for ; Wed, 8 Jun 2016 09:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 VhGHeWfRr3Zi for ; Wed, 8 Jun 2016 09:40:44 -0700 (PDT) Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:151:7310::105:1]) (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 2B04A12DA1F for ; Wed, 8 Jun 2016 09:40:44 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 1FF7535FB045; Wed, 8 Jun 2016 18:40:42 +0200 (CEST) Received: from sweet-chili.local (unknown [10.55.1.18]) by liselle.bunkus.org (Postfix) with ESMTPS id DFD8435FB03F for ; Wed, 8 Jun 2016 18:40:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016040101; t=1465404041; bh=WeOV8uaTl/N6kD2Ic3TregzMeNWZaPiGupqwI/h9laA=; h=Date:From:To:Subject:References:In-Reply-To; b=EohPOrJ4zYp9oTNru1MHbRe40TtQdJagcMZCWlfsqVzjzVna+5holT5+EHE15mQrU Z5XILL9s8xijIxMeFVCDkkY4zRLCs9U9gpft1hZCoi9+qmPOAyp+rrDO45XkdNj7IE 6yAlLDqWEo7OB87YQJc9RJnpozX0ffSCS7gG/uuRm/TFF18dTmDzO/EgjVCARtzbj+ ebdOgel5phVBXC4uFwG0fZv39D+Gz5AGS6bT8Ri+37Vl6ubGQsRtzT+QgV4HMIbQNr 3UJN7hcP81CbUsT4R1XVIz/sa2D6aD6BkBl5tI3/k33jyj5MQKKe10p91WboxA7tFw 50FbSXCiVM/inZ94y4DCXxp7xPXSMjpVd5be7UYXbDgz9o+wUuXk3NtroYHA4jyrA5 WUAye3bu+fqugY6JBeWHYffDBtQP2ywWlLnKY5ABFaicl5rwW4RE/+wOHz76TUvlbM R8WZEiLg3VQCAlh5246qovTeewD5mE3VHgyhav8Pzu7Qewtg1K8LnTHrxztNQsCH3r AanQ3YJ7nhtrnQuvRptDb1uQgJXL/4icH7bk7+UJLE3gjfraVSTAavSBFLKza/3szY R5xpPT6cPqEt6UcuFkN9gQdbsy913DTUTFx8bDsTf4LgkveB4lDkm7ooPP/HXwyojZ NDpyGW65HeA4JNfV5TASiaOA= Received: by sweet-chili.local (Postfix, from userid 1000) id 594AA6ABA65; Wed, 8 Jun 2016 18:40:40 +0200 (CEST) Date: Wed, 8 Jun 2016 18:40:40 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160608164040.dpdyhi7eyiprtod6@bunkus.org> References: <99F7F8B9-86D7-4A91-99A8-B700C7857EDE@dericed.com> <6173E5B6-6A20-4803-8807-BB483E295EC6@dericed.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1-neo () X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLReadVersion X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 16:40:45 -0000 Hey, > I'm in favor of requiring it to be only "1" and reserving other values > for future standards. Seconded, though it's not a strong preference. Kind regards, mosu From nobody Wed Jun 8 09:46:24 2016 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 3026C12D7AE for ; Wed, 8 Jun 2016 09:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 wQAK-YjE9wqs for ; Wed, 8 Jun 2016 09:46:21 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 D7F7212D142 for ; Wed, 8 Jun 2016 09:46:16 -0700 (PDT) Received: from [146.96.19.240] (port=22840 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bAgcR-000j8R-8Z; Wed, 08 Jun 2016 12:46:16 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <20160608164040.dpdyhi7eyiprtod6@bunkus.org> Date: Wed, 8 Jun 2016 12:46:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6D20B9E1-6D64-4C29-8535-84DFE8352162@dericed.com> References: <99F7F8B9-86D7-4A91-99A8-B700C7857EDE@dericed.com> <6173E5B6-6A20-4803-8807-BB483E295EC6@dericed.com> <20160608164040.dpdyhi7eyiprtod6@bunkus.org> To: Moritz Bunkus X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLReadVersion X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 16:46:22 -0000 > On Jun 8, 2016, at 12:40 PM, Moritz Bunkus wrote: >=20 > Hey, >=20 >> I'm in favor of requiring it to be only "1" and reserving other = values >> for future standards. >=20 > Seconded, though it's not a strong preference. Thanks, pr is here: = https://github.com/Matroska-Org/ebml-specification/pull/65/files Dave Rice= From nobody Wed Jun 8 14:18:37 2016 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 5E56312D187 for ; Wed, 8 Jun 2016 14:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 EUX190vwr8as for ; Wed, 8 Jun 2016 14:18:33 -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 F1D4712B05B for ; Wed, 8 Jun 2016 14:18:32 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u58LIU1q030683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 8 Jun 2016 23:18:30 +0200 Received: from Castor.local (wsip-174-67-112-140.no.no.cox.net [174.67.112.140]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u58LISXv013980 for ; Wed, 8 Jun 2016 23:18:29 +0200 Date: Wed, 8 Jun 2016 23:18:35 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: <9EEDB2AE-E1AD-4F06-B2F5-23C8047F7498@dericed.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) Archived-At: Subject: Re: [Cellar] [PATCH FFV1] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 Jun 2016 21:18:35 -0000 Dave Rice wrote: [...] >I would like to see bayer formats in the plan at some point >to accommodate raw camera and film scanner data. I second this strongly. Best regards, Reto From nobody Thu Jun 9 10:07:26 2016 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 0E8F212D5AB for ; Thu, 9 Jun 2016 10:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 LY_ZfRShXqJr for ; Thu, 9 Jun 2016 10:07:19 -0700 (PDT) Received: from 6.mo178.mail-out.ovh.net (6.mo178.mail-out.ovh.net [46.105.53.132]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A90F12D098 for ; Thu, 9 Jun 2016 10:00:57 -0700 (PDT) Received: from player791.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id 2D6B9FFCA21 for ; Thu, 9 Jun 2016 19:00:56 +0200 (CEST) Received: from [192.168.2.101] (p5DDB5AFE.dip0.t-ipconnect.de [93.219.90.254]) (Authenticated sender: jerome@francoallemand.eu) by player791.ha.ovh.net (Postfix) with ESMTPSA id DA6B6420095 for ; Thu, 9 Jun 2016 19:00:55 +0200 (CEST) To: cellar@ietf.org References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> <20160608153508.GW4636@nb4> From: Jerome Martinez Message-ID: <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> Date: Thu, 9 Jun 2016 19:00:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160608153508.GW4636@nb4> Content-Type: multipart/mixed; boundary="------------8125B9E3E7F6558563EE09DC" X-Ovh-Tracer-Id: 11585510044901707921 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrjeehgdellecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] [PATCH FFV1] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 17:07:25 -0000 This is a multi-part message in MIME format. --------------8125B9E3E7F6558563EE09DC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 08/06/2016 17:35, Michael Niedermayer a crit : > On Wed, Jun 08, 2016 at 04:56:46PM +0200, Jerome Martinez wrote: > [...] >> I need a clarification: are the following settings valid? >> - colorspace_type == 1 and chroma_planes == 0. >> - colorspace_type == 1 and chroma_planes == 1 and >> (h_chroma_subsample not 1 or v_chroma_subsample not 1). I see >> nothing about such forbidden settings and the part "for( y = 0; y < >> height; y++ )" already in the spec would be wrong in that case, for >> the same reason, or did I misunderstand something? > The implementation does not support these cases, so you can do > either define them to something usefull or disallow, it should not > affect anything existing I prefer to explicitly forbid what we did not test, I'll provide another patch for it. New patch attached, expecting that v_chroma_subsample is 1 when colorspace_type == 1. I need to change the definition of "/" for being able to use "ceil" so there is some formatting changes in other parts of the spec, let me know if you prefer that I split the patch. --------------8125B9E3E7F6558563EE09DC Content-Type: text/plain; charset=UTF-8; name="0001-SliceContent-description-update.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="0001-SliceContent-description-update.patch" >From ba2c3471a60b2480259e118be8f2ea3085003d51 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= Date: Thu, 9 Jun 2016 18:52:47 +0200 Subject: [PATCH] SliceContent description update Difference between height in slice raster elements and pixels Defines slice_pixel_height --- ffv1.md | 71 ++++++++++++++++++++++++++++++++++++++++++----------------------- 1 file changed, 46 insertions(+), 25 deletions(-) diff --git a/ffv1.md b/ffv1.md index a503d6c..9eea06a 100644 --- a/ffv1.md +++ b/ffv1.md @@ -74,7 +74,7 @@ __-a__ means negation of a. __a \* b__ means a multiplied by b. -__a / b__ means a divided by b with truncation of the result toward zero. +__a / b__ means a divided by b. __a % b__ means remainder of a divided by b. @@ -125,6 +125,16 @@ __!a__ means boolean logical "not". __a ? b : c__ if a is true, then b, otherwise c. --------------- ---------------------------------------------------------------- +## Mathematical functions + +--------------- ---------------------------------------------------------------- +__⌊a⌋__ the largest integer less than or equal to a +--------------- ---------------------------------------------------------------- + +--------------- ---------------------------------------------------------------- +__⌈a⌉__ the smallest integer greater than or equal to a +--------------- ---------------------------------------------------------------- + ## Order of operation precedence When order of precedence is not indicated explicitly by use of parentheses, operations are evaluated in the following order (from top to bottom, operations of same precedence being evaluated from left to right). This order of operations is based on the order of operations used in Standard C. @@ -462,9 +472,9 @@ The same context which is initialized to 128 is used for all fields in the heade The following MUST be provided by external means during initialization of the decoder: -**frame\_width** is defined as frame width in pixels. +**frame\_pixel\_width** is defined as frame width in pixels. -**frame\_height** is defined as frame height in pixels. +**frame\_pixel\_height** is defined as frame height in pixels. Default values at the decoder initialization phase: @@ -618,21 +628,32 @@ Inferred to be 0 if not present. ## Slice Content -| | -|------------------------------------------------------------|:------| -|SliceContent( ) { | type | -|    if( colorspace\_type == 0) { | | -|        for( p = 0; p \< primary\_color\_count; p++ ) { | | -|            Plane( p ) | | -|    } else if( colorspace\_type == 1 ) { | | -|        for( y = 0; y \< height; y++ ) | | -|            for( p = 0; p \< primary\_color\_count; p++ ) { | | -|                Line( p, y ) | | -|    } | | -|} | | +| | +|--------------------------------------------------------------|:------| +|SliceContent( ) { | type | +|    if( colorspace\_type == 0) { | | +|        for( p = 0; p \< primary\_color\_count; p++ ) { | | +|            for( y = 0; y \< plane\_pixel\_height[ p ]; y++ ) | | +|                Line( p, y ) | | +|    } else if( colorspace\_type == 1 ) { | | +|        for( y = 0; y \< slice\_pixel\_height; y++ ) | | +|            for( p = 0; p \< primary\_color\_count; p++ ) { | | +|                Line( p, y ) | | +|    } | | +|} | | **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + ( alpha_plane ? 1 : 0 ). +**plane\_pixel\_height[ p ]** is the height in pixels of plane p of the slice. +plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_planes ? 2 : 0 ) ] value is slice\_pixel\_height +if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixel\_height[ 2 ] value is ⌈slice\_pixel\_height / ( 1 << v_chroma_subsample )⌉ + +**slice\_pixel\_height** is the height in pixels of the slice. +Its value is ⌊( plane\_y + plane\_height ) * frame_pixel\_height / num\_v\_slices⌋ - slice\_pixel\_y + +**slice\_pixel\_y** is the slice vertical position in pixels. +Its value is ⌊slice_y * frame_pixel\_height / num\_v\_slices⌋ + ## Slice Footer Note: slice footer is always byte aligned. @@ -837,15 +858,15 @@ Table: 0 0 1 1 1 1 2 2-2-2-2-1-1-1-1 0 Stored values: 1, 3, 1 -```c -QuantizationTable( i ) { // type - scale = 1 - for( j = 0; j < MAX_CONTEXT_INPUTS; j++ ) { - QuantizationTablePerContext( i, j, scale ) - scale *= 2 * len_count[ i ][ j ] - 1 - } - context_count[ i ] = ( scale + 1 ) / 2 -``` +| | +|---------------------------------------------------------------------------| +| QuantizationTable( i ) { | +|   scale = 1 | +|   for( j = 0; j < MAX_CONTEXT_INPUTS; j++ ) { | +|       QuantizationTablePerContext( i, j, scale ) | +|       scale \*= 2 \* len_count[ i ][ j ] - 1 | +|   } | +|   context_count[ i ] = ⌊( scale + 1 ) / 2⌋ | MAX\_CONTEXT\_INPUTS is 5. @@ -875,7 +896,7 @@ MAX\_CONTEXT\_INPUTS is 5. ### Restrictions -To ensure that fast multithreaded decoding is possible, starting version 3 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4. +To ensure that fast multithreaded decoding is possible, starting version 3 and if frame\_pixel\_width * frame\_pixel\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4. Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format. For each frame, each position in the slice raster MUST be filled by one and only one slice of the frame (no missing slice position, no slice overlapping). -- 2.7.0.windows.1 --------------8125B9E3E7F6558563EE09DC-- From nobody Thu Jun 9 14:11:57 2016 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 61F0E12DA05 for ; Thu, 9 Jun 2016 14:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 o1oNVctw3Vhe for ; Thu, 9 Jun 2016 14:11:53 -0700 (PDT) Received: from 5.mo178.mail-out.ovh.net (5.mo178.mail-out.ovh.net [46.105.51.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59AAF12D9FE for ; Thu, 9 Jun 2016 14:11:53 -0700 (PDT) Received: from player791.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id 614311004B9B for ; Thu, 9 Jun 2016 23:11:51 +0200 (CEST) Received: from [192.168.2.101] (p5DDB5AFE.dip0.t-ipconnect.de [93.219.90.254]) (Authenticated sender: jerome@francoallemand.eu) by player791.ha.ovh.net (Postfix) with ESMTPSA id 308AC420079 for ; Thu, 9 Jun 2016 23:11:51 +0200 (CEST) From: Jerome Martinez To: cellar@ietf.org Message-ID: Date: Thu, 9 Jun 2016 23:11:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 15823115817593868433 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrjeeigddtvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: [Cellar] FFmpeg FFV1 decoder capabilities vs FFV1 specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 21:11:56 -0000 I am checking FFV1 decoder capabilities, and I have some questions about it, especially because FFV1 specifications has no limitations about e.g. bit depth, subsampling. At the end of the email there is list of inputs supported by FFmpeg FFV1 decoder, from different bit depth, colorspace, chroma presence, alpha presence, and chroma subsampling (Horizontal and Vertical). I tested all theoretical cases; I removed from the list some cases in order to have a smaller list: - less than 8 bits: same as 8 bits - more than 16 bits: not supported - subsampling: I removed cases not from real world, not supported - JPEG 2000 RCT: no subsampling supported (and spec has issues with it, see next email) Questions: - yuva411p is unsupported; looks like it is not in the list of pix_fmt in FFmpeg, despite the existence of yuva444p, yuva422p, yuva420p. Is it intended (no one interested in yuva411p in any video format)? Is it theoretically possible with FFV1? - for YCbCr, no support of 11/12/13/14/15 bit depths. Is it theoretically possible with FFV1? Is it theoretically feasible in FFmpeg without adding new pix_fmt for the one supported in JPEG 2000 RCT? (e.g. mapping 14-bit YCbCr planar from FFV1 to FFmpeg gbrp14le pix_fmt)? - for JPEG 2000 RCT, I understand that 11/13/15/16 bit depths are mapped to a 8-bit FFmpeg pix_fmt (e.g. bgr0), so with loss of data (decoding then re-encoding is not lossless). Do I understand wrong or is it a bug? Is it theoretically possible in FFV1? - for JPEG 2000 RCT, I understand that 9/10/12/14 bit depths with alpha are mapped to a FFmpeg pix_fmt without alpha (e.g. AV_PIX_FMT_GBRP9 for 9-bit with alpha), so with loss of data (decoding then re-encoding is not lossless). Do I understand wrong or is it a bug? Is it theoretically possible in FFV1? - are bit depths more than 16-bit theoretically possible with FFV1? bit depth | colorspace | chroma presence | alpha presence | H chroma subsampling | V chroma subsampling | FFmpeg pix_fmt 8 bits | YCbCr | No chroma | No alpha | | | gray 8 bits | YCbCr | No chroma | Alpha | | | ya8 8 bits | YCbCr | Chroma | No alpha | | | yuv444p 8 bits | YCbCr | Chroma | No alpha | H/2 | | yuv422p 8 bits | YCbCr | Chroma | No alpha | H/2 | V/2 | yuv420p 8 bits | YCbCr | Chroma | No alpha | H/4 | | yuv411p 8 bits | YCbCr | Chroma | Alpha | | | yuva444p 8 bits | YCbCr | Chroma | Alpha | H/2 | | yuva422p 8 bits | YCbCr | Chroma | Alpha | H/2 | V/2 | yuva420p 8 bits | YCbCr | Chroma | Alpha | H/4 | | 8 bits | RCT | No chroma | No alpha | | | bgr0 8 bits | RCT | No chroma | Alpha | | | bgra 8 bits | RCT | Chroma | No alpha | | | bgr0 8 bits | RCT | Chroma | Alpha | | | bgra 9 bits | YCbCr | No chroma | No alpha | | | gray16le 9 bits | YCbCr | No chroma | Alpha | | | 9 bits | YCbCr | Chroma | No alpha | | | yuv444p9le 9 bits | YCbCr | Chroma | No alpha | H/2 | | yuv422p9le 9 bits | YCbCr | Chroma | No alpha | H/2 | V/2 | yuv420p9le 9 bits | YCbCr | Chroma | No alpha | H/4 | | 9 bits | YCbCr | Chroma | Alpha | | | yuva444p9le 9 bits | YCbCr | Chroma | Alpha | H/2 | | yuva422p9le 9 bits | YCbCr | Chroma | Alpha | H/2 | V/2 | yuva420p9le 9 bits | YCbCr | Chroma | Alpha | H/4 | | 9 bits | RCT | No chroma | No alpha | | | gbrp9le 9 bits | RCT | No chroma | Alpha | | | gbrp9le 9 bits | RCT | Chroma | No alpha | | | gbrp9le 9 bits | RCT | Chroma | Alpha | | | gbrp9le 10 bits | YCbCr | No chroma | No alpha | | | gray16le 10 bits | YCbCr | No chroma | Alpha | | | 10 bits | YCbCr | Chroma | No alpha | | | yuv444p10le 10 bits | YCbCr | Chroma | No alpha | H/2 | | yuv422p10le 10 bits | YCbCr | Chroma | No alpha | H/2 | V/2 | yuv420p10le 10 bits | YCbCr | Chroma | No alpha | H/4 | | 10 bits | YCbCr | Chroma | Alpha | | | yuva444p10le 10 bits | YCbCr | Chroma | Alpha | H/2 | | yuva422p10le 10 bits | YCbCr | Chroma | Alpha | H/2 | V/2 | yuva420p10le 10 bits | YCbCr | Chroma | Alpha | H/4 | | 10 bits | RCT | No chroma | No alpha | | | gbrp10le 10 bits | RCT | No chroma | Alpha | | | gbrp10le 10 bits | RCT | Chroma | No alpha | | | gbrp10le 10 bits | RCT | Chroma | Alpha | | | gbrp10le 11 bits | YCbCr | No chroma | No alpha | | | gray16le 11 bits | YCbCr | No chroma | Alpha | | | 11 bits | YCbCr | Chroma | No alpha | | | 11 bits | YCbCr | Chroma | No alpha | H/2 | | 11 bits | YCbCr | Chroma | No alpha | H/2 | V/2 | 11 bits | YCbCr | Chroma | No alpha | H/4 | | 11 bits | YCbCr | Chroma | Alpha | | | 11 bits | YCbCr | Chroma | Alpha | H/2 | | 11 bits | YCbCr | Chroma | Alpha | H/2 | V/2 | 11 bits | YCbCr | Chroma | Alpha | H/4 | | 11 bits | RCT | No chroma | No alpha | | | bgr0 11 bits | RCT | No chroma | Alpha | | | bgra 11 bits | RCT | Chroma | No alpha | | | bgr0 11 bits | RCT | Chroma | Alpha | | | bgra 12 bits | YCbCr | No chroma | No alpha | | | gray16le 12 bits | YCbCr | No chroma | Alpha | | | 12 bits | YCbCr | Chroma | No alpha | | | 12 bits | YCbCr | Chroma | No alpha | H/2 | | 12 bits | YCbCr | Chroma | No alpha | H/2 | V/2 | 12 bits | YCbCr | Chroma | No alpha | H/4 | | 12 bits | YCbCr | Chroma | Alpha | | | 12 bits | YCbCr | Chroma | Alpha | H/2 | | 12 bits | YCbCr | Chroma | Alpha | H/2 | V/2 | 12 bits | YCbCr | Chroma | Alpha | H/4 | | 12 bits | RCT | No chroma | No alpha | | | gbrp12le 12 bits | RCT | No chroma | Alpha | | | gbrp12le 12 bits | RCT | Chroma | No alpha | | | gbrp12le 12 bits | RCT | Chroma | Alpha | | | gbrp12le 13 bits | YCbCr | No chroma | No alpha | | | gray16le 13 bits | YCbCr | No chroma | Alpha | | | 13 bits | YCbCr | Chroma | No alpha | | | 13 bits | YCbCr | Chroma | No alpha | H/2 | | 13 bits | YCbCr | Chroma | No alpha | H/2 | V/2 | 13 bits | YCbCr | Chroma | No alpha | H/4 | | 13 bits | YCbCr | Chroma | Alpha | | | 13 bits | YCbCr | Chroma | Alpha | H/2 | | 13 bits | YCbCr | Chroma | Alpha | H/2 | V/2 | 13 bits | YCbCr | Chroma | Alpha | H/4 | | 13 bits | RCT | No chroma | No alpha | | | bgr0 13 bits | RCT | No chroma | Alpha | | | bgra 13 bits | RCT | Chroma | No alpha | | | bgr0 13 bits | RCT | Chroma | Alpha | | | bgra 14 bits | YCbCr | No chroma | No alpha | | | gray16le 14 bits | YCbCr | No chroma | Alpha | | | 14 bits | YCbCr | Chroma | No alpha | | | 14 bits | YCbCr | Chroma | No alpha | H/2 | | 14 bits | YCbCr | Chroma | No alpha | H/2 | V/2 | 14 bits | YCbCr | Chroma | No alpha | H/4 | | 14 bits | YCbCr | Chroma | Alpha | | | 14 bits | YCbCr | Chroma | Alpha | H/2 | | 14 bits | YCbCr | Chroma | Alpha | H/2 | V/2 | 14 bits | YCbCr | Chroma | Alpha | H/4 | | 14 bits | RCT | No chroma | No alpha | | | gbrp14le 14 bits | RCT | No chroma | Alpha | | | gbrp14le 14 bits | RCT | Chroma | No alpha | | | gbrp14le 14 bits | RCT | Chroma | Alpha | | | gbrp14le 15 bits | YCbCr | No chroma | No alpha | | | gray16le 15 bits | YCbCr | No chroma | Alpha | | | 15 bits | YCbCr | Chroma | No alpha | | | 15 bits | YCbCr | Chroma | No alpha | H/2 | | 15 bits | YCbCr | Chroma | No alpha | H/2 | V/2 | 15 bits | YCbCr | Chroma | No alpha | H/4 | | 15 bits | YCbCr | Chroma | Alpha | | | 15 bits | YCbCr | Chroma | Alpha | H/2 | | 15 bits | YCbCr | Chroma | Alpha | H/2 | V/2 | 15 bits | YCbCr | Chroma | Alpha | H/4 | | 15 bits | RCT | No chroma | No alpha | | | bgr0 15 bits | RCT | No chroma | Alpha | | | bgra 15 bits | RCT | Chroma | No alpha | | | bgr0 15 bits | RCT | Chroma | Alpha | | | bgra 16 bits | YCbCr | No chroma | No alpha | | | gray16le 16 bits | YCbCr | No chroma | Alpha | | | 16 bits | YCbCr | Chroma | No alpha | | | yuv444p16le 16 bits | YCbCr | Chroma | No alpha | H/2 | | yuv422p16le 16 bits | YCbCr | Chroma | No alpha | H/2 | V/2 | yuv420p16le 16 bits | YCbCr | Chroma | No alpha | H/4 | | 16 bits | YCbCr | Chroma | Alpha | | | yuva444p16le 16 bits | YCbCr | Chroma | Alpha | H/2 | | yuva422p16le 16 bits | YCbCr | Chroma | Alpha | H/2 | V/2 | yuva420p16le 16 bits | YCbCr | Chroma | Alpha | H/4 | | 16 bits | RCT | No chroma | No alpha | | | bgr0 16 bits | RCT | No chroma | Alpha | | | bgra 16 bits | RCT | Chroma | No alpha | | | bgr0 16 bits | RCT | Chroma | Alpha | | | bgra From nobody Thu Jun 9 14:22:32 2016 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 205F312D0EB for ; Thu, 9 Jun 2016 14:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ygyNO3yHiUTH for ; Thu, 9 Jun 2016 14:22:26 -0700 (PDT) Received: from 4.mo178.mail-out.ovh.net (4.mo178.mail-out.ovh.net [46.105.49.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA4A12D0BD for ; Thu, 9 Jun 2016 14:22:25 -0700 (PDT) Received: from player791.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id D6F1AFFCDC3 for ; Thu, 9 Jun 2016 23:22:23 +0200 (CEST) Received: from [192.168.2.101] (p5DDB5AFE.dip0.t-ipconnect.de [93.219.90.254]) (Authenticated sender: jerome@francoallemand.eu) by player791.ha.ovh.net (Postfix) with ESMTPSA id BCB4D420079 for ; Thu, 9 Jun 2016 23:22:23 +0200 (CEST) From: Jerome Martinez To: cellar@ietf.org Message-ID: <88d5ce7a-9214-fdbd-51d8-5f869e8ce5aa@mediaarea.net> Date: Thu, 9 Jun 2016 23:22:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 16001008002718961809 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrjeeigddtgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: [Cellar] FFV1 JPEG 2000 RCT and chroma subsampling X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 21:22:29 -0000 I have mixed feelings about a theoretical case, when the spec could be slightly adapted in order to support this case but we have no decoder able to decode it for the moment. - colorspace_type == 1 (JPEG 2000 RCT, lines are interleaved Y, Cb, Cr, Alpha for line 0 then Y, Cb, Cr, Alpha for line 1...) - h_chroma_subsample not 1 or v_chroma_subsample not 1 If h_chroma_subsample is not 1, I think it will be handled the same way as with colorspace_type == 0, I see no difficulty about it. If v_chroma_subsample is not 1, the algorithm in SliceContent() is wrong because height is not same for all planes. So either we explicitly forbid this case or we adapt the algorithm without decoder for decoding it. Which option do you prefer? * in v_chroma_subsample definition, we add "if colorspace_type is 1, v_chroma_subsample MUST be 1" * We change for( y = 0; y < height; y++ ) for( p = 0; p < primary_color_count; p++ ) Line( p, y ) to something like: for( y = 0; y < height; y++ ) for( p = 0; p < primary_color_count; p++ ) if ( p == luma || p == alpha || height%v_chroma_subsample ) Line( p, y ) e.g. for 4:4:0 (full horizontal sampling, ½ vertical sampling, ), we would have: Y1, Cb, Cr, Alpha1, Y2, Alpha2 Note: this would be not the first case without decoder e.g. there is no decoder for gray+alpha more than 8-bit. From nobody Thu Jun 9 14:29:42 2016 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 399AF12D0D1 for ; Thu, 9 Jun 2016 14:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 9aYPVCuP85io for ; Thu, 9 Jun 2016 14:29:36 -0700 (PDT) Received: from 4.mo178.mail-out.ovh.net (4.mo178.mail-out.ovh.net [46.105.49.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5E612D575 for ; Thu, 9 Jun 2016 14:29:35 -0700 (PDT) Received: from player791.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id 1D56B100C5CF for ; Thu, 9 Jun 2016 23:29:34 +0200 (CEST) Received: from [192.168.2.101] (p5DDB5AFE.dip0.t-ipconnect.de [93.219.90.254]) (Authenticated sender: jerome@francoallemand.eu) by player791.ha.ovh.net (Postfix) with ESMTPSA id ECC6E420076 for ; Thu, 9 Jun 2016 23:29:33 +0200 (CEST) To: cellar@ietf.org References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> <20160608153508.GW4636@nb4> <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> From: Jerome Martinez Message-ID: Date: Thu, 9 Jun 2016 23:29:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> Content-Type: multipart/mixed; boundary="------------66D8421D37CCC289B2A61E0D" X-Ovh-Tracer-Id: 16122323716583461009 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrjeeigddthecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] [PATCH FFV1] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 09 Jun 2016 21:29:38 -0000 This is a multi-part message in MIME format. --------------66D8421D37CCC289B2A61E0D Content-Type: multipart/alternative; boundary="------------5962EE99D3151E258178AF50" --------------5962EE99D3151E258178AF50 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sorry, there was a typo (around v_chroma_subsample usage in the definition of plane_pixel_height) in the previous patch proposal, here is a new one. Le 09/06/2016 19:00, Jerome Martinez a crit : > Le 08/06/2016 17:35, Michael Niedermayer a crit : >> On Wed, Jun 08, 2016 at 04:56:46PM +0200, Jerome Martinez wrote: >> [...] >>> I need a clarification: are the following settings valid? >>> - colorspace_type == 1 and chroma_planes == 0. >>> - colorspace_type == 1 and chroma_planes == 1 and >>> (h_chroma_subsample not 1 or v_chroma_subsample not 1). I see >>> nothing about such forbidden settings and the part "for( y = 0; y < >>> height; y++ )" already in the spec would be wrong in that case, for >>> the same reason, or did I misunderstand something? >> The implementation does not support these cases, so you can do >> either define them to something usefull or disallow, it should not >> affect anything existing > > I prefer to explicitly forbid what we did not test, I'll provide > another patch for it. > New patch attached, expecting that v_chroma_subsample is 1 when > colorspace_type == 1. > I need to change the definition of "/" for being able to use "ceil" so > there is some formatting changes in other parts of the spec, let me > know if you prefer that I split the patch. > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --------------5962EE99D3151E258178AF50 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Sorry, there was a typo (around v_chroma_subsample usage in the definition of plane_pixel_height) in the previous patch proposal, here is a new one.

Le 09/06/2016 19:00, Jerome Martinez a crit:
Le 08/06/2016 17:35, Michael Niedermayer a crit :
On Wed, Jun 08, 2016 at 04:56:46PM +0200, Jerome Martinez wrote:
[...]
I need a clarification: are the following settings valid?
- colorspace_type == 1 and chroma_planes == 0.
- colorspace_type == 1 and chroma_planes == 1 and
(h_chroma_subsample not 1 or v_chroma_subsample not 1). I see
nothing about such forbidden settings and the part "for( y = 0; y <
height; y++ )" already in the spec would be wrong in that case, for
the same reason, or did I misunderstand something?
The implementation does not support these cases, so you can do
either define them to something usefull or disallow, it should not
affect anything existing

I prefer to explicitly forbid what we did not test, I'll provide another patch for it.
New patch attached, expecting that v_chroma_subsample is 1 when colorspace_type == 1.
I need to change the definition of "/" for being able to use "ceil" so there is some formatting changes in other parts of the spec, let me know if you prefer that I split the patch. 



_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar


--------------5962EE99D3151E258178AF50-- --------------66D8421D37CCC289B2A61E0D Content-Type: text/plain; charset=UTF-8; name="0001-SliceContent-description-update.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="0001-SliceContent-description-update.patch" >From 4f99215fd2075a7e8212f4bfce45c2e7d45164af Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= Date: Thu, 9 Jun 2016 23:27:19 +0200 Subject: [PATCH] SliceContent description update Difference between height in slice raster elements and pixels Defines slice_pixel_height and plane_pixel_height[ p ] --- ffv1.md | 71 ++++++++++++++++++++++++++++++++++++++++++----------------------- 1 file changed, 46 insertions(+), 25 deletions(-) diff --git a/ffv1.md b/ffv1.md index a503d6c..2d23de5 100644 --- a/ffv1.md +++ b/ffv1.md @@ -74,7 +74,7 @@ __-a__ means negation of a. __a \* b__ means a multiplied by b. -__a / b__ means a divided by b with truncation of the result toward zero. +__a / b__ means a divided by b. __a % b__ means remainder of a divided by b. @@ -125,6 +125,16 @@ __!a__ means boolean logical "not". __a ? b : c__ if a is true, then b, otherwise c. --------------- ---------------------------------------------------------------- +## Mathematical functions + +--------------- ---------------------------------------------------------------- +__⌊a⌋__ the largest integer less than or equal to a +--------------- ---------------------------------------------------------------- + +--------------- ---------------------------------------------------------------- +__⌈a⌉__ the smallest integer greater than or equal to a +--------------- ---------------------------------------------------------------- + ## Order of operation precedence When order of precedence is not indicated explicitly by use of parentheses, operations are evaluated in the following order (from top to bottom, operations of same precedence being evaluated from left to right). This order of operations is based on the order of operations used in Standard C. @@ -462,9 +472,9 @@ The same context which is initialized to 128 is used for all fields in the heade The following MUST be provided by external means during initialization of the decoder: -**frame\_width** is defined as frame width in pixels. +**frame\_pixel\_width** is defined as frame width in pixels. -**frame\_height** is defined as frame height in pixels. +**frame\_pixel\_height** is defined as frame height in pixels. Default values at the decoder initialization phase: @@ -618,21 +628,32 @@ Inferred to be 0 if not present. ## Slice Content -| | -|------------------------------------------------------------|:------| -|SliceContent( ) { | type | -|    if( colorspace\_type == 0) { | | -|        for( p = 0; p \< primary\_color\_count; p++ ) { | | -|            Plane( p ) | | -|    } else if( colorspace\_type == 1 ) { | | -|        for( y = 0; y \< height; y++ ) | | -|            for( p = 0; p \< primary\_color\_count; p++ ) { | | -|                Line( p, y ) | | -|    } | | -|} | | +| | +|--------------------------------------------------------------|:------| +|SliceContent( ) { | type | +|    if( colorspace\_type == 0) { | | +|        for( p = 0; p \< primary\_color\_count; p++ ) { | | +|            for( y = 0; y \< plane\_pixel\_height[ p ]; y++ ) | | +|                Line( p, y ) | | +|    } else if( colorspace\_type == 1 ) { | | +|        for( y = 0; y \< slice\_pixel\_height; y++ ) | | +|            for( p = 0; p \< primary\_color\_count; p++ ) { | | +|                Line( p, y ) | | +|    } | | +|} | | **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + ( alpha_plane ? 1 : 0 ). +**plane\_pixel\_height[ p ]** is the height in pixels of plane p of the slice. +plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_planes ? 2 : 0 ) ] value is slice\_pixel\_height +if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixel\_height[ 2 ] value is ⌈slice\_pixel\_height / v\_chroma\_subsample⌉ + +**slice\_pixel\_height** is the height in pixels of the slice. +Its value is ⌊( plane\_y + plane\_height ) * frame_pixel\_height / num\_v\_slices⌋ - slice\_pixel\_y + +**slice\_pixel\_y** is the slice vertical position in pixels. +Its value is ⌊slice_y * frame_pixel\_height / num\_v\_slices⌋ + ## Slice Footer Note: slice footer is always byte aligned. @@ -837,15 +858,15 @@ Table: 0 0 1 1 1 1 2 2-2-2-2-1-1-1-1 0 Stored values: 1, 3, 1 -```c -QuantizationTable( i ) { // type - scale = 1 - for( j = 0; j < MAX_CONTEXT_INPUTS; j++ ) { - QuantizationTablePerContext( i, j, scale ) - scale *= 2 * len_count[ i ][ j ] - 1 - } - context_count[ i ] = ( scale + 1 ) / 2 -``` +| | +|---------------------------------------------------------------------------| +| QuantizationTable( i ) { | +|   scale = 1 | +|   for( j = 0; j < MAX_CONTEXT_INPUTS; j++ ) { | +|       QuantizationTablePerContext( i, j, scale ) | +|       scale \*= 2 \* len_count[ i ][ j ] - 1 | +|   } | +|   context_count[ i ] = ⌊( scale + 1 ) / 2⌋ | MAX\_CONTEXT\_INPUTS is 5. @@ -875,7 +896,7 @@ MAX\_CONTEXT\_INPUTS is 5. ### Restrictions -To ensure that fast multithreaded decoding is possible, starting version 3 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4. +To ensure that fast multithreaded decoding is possible, starting version 3 and if frame\_pixel\_width * frame\_pixel\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4. Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format. For each frame, each position in the slice raster MUST be filled by one and only one slice of the frame (no missing slice position, no slice overlapping). -- 2.7.0.windows.1 --------------66D8421D37CCC289B2A61E0D-- From nobody Sat Jun 11 13:20:17 2016 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 7631B12B014 for ; Sat, 11 Jun 2016 13:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 r4bpXYsdF_GE for ; Sat, 11 Jun 2016 13:20:12 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA3E12B047 for ; Sat, 11 Jun 2016 13:20:11 -0700 (PDT) Received: from mfilter33-d.gandi.net (mfilter33-d.gandi.net [217.70.178.164]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id F01D317209B for ; Sat, 11 Jun 2016 22:20:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter33-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter33-d.gandi.net (mfilter33-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eiYmLIceTv3k for ; Sat, 11 Jun 2016 22:20:08 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 5B39D1720A3 for ; Sat, 11 Jun 2016 22:20:08 +0200 (CEST) Date: Sat, 11 Jun 2016 22:19:55 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160611201955.GZ4636@nb4> References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> <20160608153508.GW4636@nb4> <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RQipzlYdbiO9/NWI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] [PATCH FFV1] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 11 Jun 2016 20:20:15 -0000 --RQipzlYdbiO9/NWI Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 09, 2016 at 11:29:25PM +0200, Jerome Martinez wrote: > Sorry, there was a typo (around v_chroma_subsample usage in the > definition of plane_pixel_height) in the previous patch proposal, > here is a new one. >=20 > Le 09/06/2016 =E0 19:00, Jerome Martinez a =E9crit : > >Le 08/06/2016 =E0 17:35, Michael Niedermayer a =E9crit : > >>On Wed, Jun 08, 2016 at 04:56:46PM +0200, Jerome Martinez wrote: > >>[...] > >>>I need a clarification: are the following settings valid? > >>>- colorspace_type =3D=3D 1 and chroma_planes =3D=3D 0. > >>>- colorspace_type =3D=3D 1 and chroma_planes =3D=3D 1 and > >>>(h_chroma_subsample not 1 or v_chroma_subsample not 1). I see > >>>nothing about such forbidden settings and the part "for( y =3D 0; y < > >>>height; y++ )" already in the spec would be wrong in that case, for > >>>the same reason, or did I misunderstand something? > >>The implementation does not support these cases, so you can do > >>either define them to something usefull or disallow, it should not > >>affect anything existing > > > >I prefer to explicitly forbid what we did not test, I'll provide > >another patch for it. > >New patch attached, expecting that v_chroma_subsample is 1 when > >colorspace_type =3D=3D 1. > >I need to change the definition of "/" for being able to use > >"ceil" so there is some formatting changes in other parts of the > >spec, let me know if you prefer that I split the patch. > > > > > > > >_______________________________________________ > >Cellar mailing list > >Cellar@ietf.org > >https://www.ietf.org/mailman/listinfo/cellar >=20 >=20 > ffv1.md | 71 +++++++++++++++++++++++++++++++++++++++++----------------= ------- > 1 file changed, 46 insertions(+), 25 deletions(-) > 80e49d33f9e13946b1160098da0d3c7e2ef0a93f 0001-SliceContent-description-u= pdate.patch > >From 4f99215fd2075a7e8212f4bfce45c2e7d45164af Mon Sep 17 00:00:00 2001 > From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D > Date: Thu, 9 Jun 2016 23:27:19 +0200 > Subject: [PATCH] SliceContent description update >=20 > Difference between height in slice raster elements and pixels > Defines slice_pixel_height and plane_pixel_height[ p ] > --- > ffv1.md | 71 ++++++++++++++++++++++++++++++++++++++++++-----------------= ------ > 1 file changed, 46 insertions(+), 25 deletions(-) >=20 > diff --git a/ffv1.md b/ffv1.md > index a503d6c..2d23de5 100644 > --- a/ffv1.md > +++ b/ffv1.md > @@ -74,7 +74,7 @@ __-a__ means negation of a. > =20 > __a=A0\*=A0b__ means a multiplied by b. > =20 > -__a=A0/=A0b__ means a divided by b with truncation of the result t= oward zero. > +__a=A0/=A0b__ means a divided by b. > =20 > __a=A0%=A0b__ means remainder of a divided by b. if a / b is the precisse and not rounded value then a % b as the corresponding remainder does not make sense [...] > +**plane\_pixel\_height[ p ]** is the height in pixels of plane p of the = slice. =20 > +plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_planes= ? 2 : 0 ) ] value is slice\_pixel\_height =20 > +if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixe= l\_height[ 2 ] value is ⌈slice\_pixel\_height / v\_chroma\_subsample&= rceil; the plane\_pixel\_*[0] should be changed to be rounded toward chroma raster size in the next bitstream version this would simplify slice geometry i think [...] > @@ -837,15 +858,15 @@ Table: 0 0 1 1 1 1 2 2-2-2-2-1-1-1-1 0 > =20 > Stored values: 1, 3, 1 > =20 > -```c > -QuantizationTable( i ) { // type > - scale =3D 1 > - for( j =3D 0; j < MAX_CONTEXT_INPUTS; j++ ) { > - QuantizationTablePerContext( i, j, scale ) > - scale *=3D 2 * len_count[ i ][ j ] - 1 > - } > - context_count[ i ] =3D ( scale + 1 ) / 2 > -``` > +| = | > +|-----------------------------------------------------------------------= ----| > +| QuantizationTable( i ) { = | > +|=A0=A0=A0scale =3D 1 = | > +|=A0=A0=A0for( j =3D 0; j < MAX_CONTEXT_INPUTS; j++ ) { = | > +|=A0=A0=A0=A0=A0=A0=A0QuantizationTablePerContext( i, j, scale ) = | > +|=A0=A0=A0=A0=A0=A0=A0scale \*=3D 2 \* len_count[ i ][ j ] - 1 = | > +|=A0=A0=A0} = | > +|=A0=A0=A0context_count[ i ] =3D ⌊( scale + 1 ) / 2⌋ = | please move the reformating into a separate patch its difficult to see what changed [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato --RQipzlYdbiO9/NWI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldccmsACgkQYR7HhwQLD6s3RwCeJuBHYrNiuDt65sbjj3Lpeg0G wSUAoJZC8Pa60QhjL57Q6eE8cTRmF8qG =hen1 -----END PGP SIGNATURE----- --RQipzlYdbiO9/NWI-- From nobody Sat Jun 11 13:36:50 2016 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 D683E12D0B4 for ; Sat, 11 Jun 2016 13:36:48 -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 t9g4BOn2kGJE for ; Sat, 11 Jun 2016 13:36:47 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6434812B041 for ; Sat, 11 Jun 2016 13:36:47 -0700 (PDT) Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 63F6FC5A49 for ; Sat, 11 Jun 2016 22:36:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter19-d.gandi.net (mfilter19-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Mozb4cHQlChX for ; Sat, 11 Jun 2016 22:36:44 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id DC3E0C5A51 for ; Sat, 11 Jun 2016 22:36:43 +0200 (CEST) Date: Sat, 11 Jun 2016 22:36:30 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160611203630.GA4636@nb4> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CV9g7MldeTA+KTr7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] FFmpeg FFV1 decoder capabilities vs FFV1 specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 11 Jun 2016 20:36:49 -0000 --CV9g7MldeTA+KTr7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 09, 2016 at 11:11:42PM +0200, Jerome Martinez wrote: > I am checking FFV1 decoder capabilities, and I have some questions > about it, especially because FFV1 specifications has no limitations > about e.g. bit depth, subsampling. >=20 > At the end of the email there is list of inputs supported by FFmpeg > FFV1 decoder, from different bit depth, colorspace, chroma presence, > alpha presence, and chroma subsampling (Horizontal and Vertical). > I tested all theoretical cases; I removed from the list some cases > in order to have a smaller list: > - less than 8 bits: same as 8 bits > - more than 16 bits: not supported > - subsampling: I removed cases not from real world, not supported > - JPEG 2000 RCT: no subsampling supported (and spec has issues with > it, see next email) >=20 > Questions: > - yuva411p is unsupported; looks like it is not in the list of > pix_fmt in FFmpeg, despite the existence of yuva444p, yuva422p, > yuva420p. Is it intended (no one interested in yuva411p in any video > format)? Is it theoretically possible with FFV1? i see nothing special on yuva411p, so it shoud be fine > - for YCbCr, no support of 11/12/13/14/15 bit depths. Is it > theoretically possible with FFV1? Is it theoretically feasible in i dont see why it wouldnt work > FFmpeg without adding new pix_fmt for the one supported in JPEG 2000 > RCT? (e.g. mapping 14-bit YCbCr planar from FFV1 to FFmpeg gbrp14le > pix_fmt)? i dont understand the question > - for JPEG 2000 RCT, I understand that 11/13/15/16 bit depths are > mapped to a 8-bit FFmpeg pix_fmt (e.g. bgr0), so with loss of data > (decoding then re-encoding is not lossless). Do I understand wrong > or is it a bug? Is it theoretically possible in FFV1? sounds like a bug / implementation limitation > - for JPEG 2000 RCT, I understand that 9/10/12/14 bit depths with > alpha are mapped to a FFmpeg pix_fmt without alpha (e.g. > AV_PIX_FMT_GBRP9 for 9-bit with alpha), so with loss of data > (decoding then re-encoding is not lossless). Do I understand wrong > or is it a bug? Is it theoretically possible in FFV1? sounds like a bug / implementation limitation > - are bit depths more than 16-bit theoretically possible with FFV1? i think so [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates --CV9g7MldeTA+KTr7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldcdk4ACgkQYR7HhwQLD6tcIgCfV09I3vEhTLdOu7zztz/isxjH /IMAn3o18kwXcTasK0+iawAjePn9lVm+ =0UTH -----END PGP SIGNATURE----- --CV9g7MldeTA+KTr7-- From nobody Mon Jun 13 12:14:27 2016 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 EA24F12D95E for ; Mon, 13 Jun 2016 12:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 fWGYTDYJhZYc for ; Mon, 13 Jun 2016 12:14:10 -0700 (PDT) Received: from 8.mo178.mail-out.ovh.net (8.mo178.mail-out.ovh.net [46.105.74.227]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B6D12D957 for ; Mon, 13 Jun 2016 12:14:10 -0700 (PDT) Received: from player791.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id 8CCCF1008756 for ; Mon, 13 Jun 2016 21:14:08 +0200 (CEST) Received: from [192.168.2.101] (p5DDB5AFE.dip0.t-ipconnect.de [93.219.90.254]) (Authenticated sender: jerome@francoallemand.eu) by player791.ha.ovh.net (Postfix) with ESMTPSA id 3DB93420073 for ; Mon, 13 Jun 2016 21:14:08 +0200 (CEST) To: cellar@ietf.org References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> <20160608153508.GW4636@nb4> <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> <20160611201955.GZ4636@nb4> From: Jerome Martinez Message-ID: Date: Mon, 13 Jun 2016 21:14:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160611201955.GZ4636@nb4> Content-Type: multipart/mixed; boundary="------------C404EBD765F1C8AFC8CB4F14" X-Ovh-Tracer-Id: 432345565056209041 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrkedugddufedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] [PATCH FFV1 1/2] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 19:14:14 -0000 This is a multi-part message in MIME format. --------------C404EBD765F1C8AFC8CB4F14 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 11/06/2016 22:19, Michael Niedermayer a crit : > On Thu, Jun 09, 2016 at 11:29:25PM +0200, Jerome Martinez wrote: > [...] > if a / b is the precisse and not rounded value then a % b as > the corresponding remainder does not make sense a % b removed > [...] > please move the reformating into a separate patch > its difficult to see what changed Patch 1/2 is about formatting only. --------------C404EBD765F1C8AFC8CB4F14 Content-Type: text/plain; charset=UTF-8; name="0001-Reformatting-before-SliceContent-changes.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename*0="0001-Reformatting-before-SliceContent-changes.patch" >From 42509e64d6560e5724c0ccfbc27f3ca306d35451 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= Date: Mon, 13 Jun 2016 21:05:17 +0200 Subject: [PATCH 1/2] Reformatting before SliceContent changes Explicit floor and ceil instead of truncation of a / b Add "pixel_" prefix in order to avoid conflict with width/height in count of elements in the slice raster Larger SliceContent formatted array size QuantizationTable() moved to a formatted array --- ffv1.md | 64 ++++++++++++++++++++++++++++++++++++---------------------------- 1 file changed, 36 insertions(+), 28 deletions(-) diff --git a/ffv1.md b/ffv1.md index a503d6c..49019c2 100644 --- a/ffv1.md +++ b/ffv1.md @@ -74,9 +74,7 @@ __-a__ means negation of a. __a \* b__ means a multiplied by b. -__a / b__ means a divided by b with truncation of the result toward zero. - -__a % b__ means remainder of a divided by b. +__a / b__ means a divided by b. __a & b__ means bit-wise "and" of a and b. @@ -125,6 +123,16 @@ __!a__ means boolean logical "not". __a ? b : c__ if a is true, then b, otherwise c. --------------- ---------------------------------------------------------------- +## Mathematical functions + +--------------- ---------------------------------------------------------------- +__⌊a⌋__ the largest integer less than or equal to a +--------------- ---------------------------------------------------------------- + +--------------- ---------------------------------------------------------------- +__⌈a⌉__ the smallest integer greater than or equal to a +--------------- ---------------------------------------------------------------- + ## Order of operation precedence When order of precedence is not indicated explicitly by use of parentheses, operations are evaluated in the following order (from top to bottom, operations of same precedence being evaluated from left to right). This order of operations is based on the order of operations used in Standard C. @@ -153,7 +161,7 @@ __a...b__ means any value starting from a to b, inclusive. **remaining\_bits\_in\_bitstream( )** means the count of remaining bits after the current position in the bitstream. It is computed from the NumBytes value multiplied by 8 minus the count of bits already read by the bitstream parser. -**byte\_aligned( )** means remaining\_bits\_in\_bitstream( ) % 8 is 0. +**byte\_aligned( )** means remaining\_bits\_in\_bitstream( ) is a multiple of 8. \pagebreak @@ -462,9 +470,9 @@ The same context which is initialized to 128 is used for all fields in the heade The following MUST be provided by external means during initialization of the decoder: -**frame\_width** is defined as frame width in pixels. +**frame\_pixel\_width** is defined as frame width in pixels. -**frame\_height** is defined as frame height in pixels. +**frame\_pixel\_height** is defined as frame height in pixels. Default values at the decoder initialization phase: @@ -618,18 +626,18 @@ Inferred to be 0 if not present. ## Slice Content -| | -|------------------------------------------------------------|:------| -|SliceContent( ) { | type | -|    if( colorspace\_type == 0) { | | -|        for( p = 0; p \< primary\_color\_count; p++ ) { | | -|            Plane( p ) | | -|    } else if( colorspace\_type == 1 ) { | | -|        for( y = 0; y \< height; y++ ) | | -|            for( p = 0; p \< primary\_color\_count; p++ ) { | | -|                Line( p, y ) | | -|    } | | -|} | | +| | +|--------------------------------------------------------------|:------| +|SliceContent( ) { | type | +|    if( colorspace\_type == 0) { | | +|        for( p = 0; p \< primary\_color\_count; p++ ) { | | +|            Plane( p ) | | +|    } else if( colorspace\_type == 1 ) { | | +|        for( y = 0; y \< height; y++ ) | | +|            for( p = 0; p \< primary\_color\_count; p++ ) { | | +|                Line( p, y ) | | +|    } | | +|} | | **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + ( alpha_plane ? 1 : 0 ). @@ -837,15 +845,15 @@ Table: 0 0 1 1 1 1 2 2-2-2-2-1-1-1-1 0 Stored values: 1, 3, 1 -```c -QuantizationTable( i ) { // type - scale = 1 - for( j = 0; j < MAX_CONTEXT_INPUTS; j++ ) { - QuantizationTablePerContext( i, j, scale ) - scale *= 2 * len_count[ i ][ j ] - 1 - } - context_count[ i ] = ( scale + 1 ) / 2 -``` +| | +|---------------------------------------------------------------------------| +| QuantizationTable( i ) { | +|   scale = 1 | +|   for( j = 0; j < MAX_CONTEXT_INPUTS; j++ ) { | +|       QuantizationTablePerContext( i, j, scale ) | +|       scale \*= 2 \* len_count[ i ][ j ] - 1 | +|   } | +|   context_count[ i ] = ⌊( scale + 1 ) / 2⌋ | MAX\_CONTEXT\_INPUTS is 5. @@ -875,7 +883,7 @@ MAX\_CONTEXT\_INPUTS is 5. ### Restrictions -To ensure that fast multithreaded decoding is possible, starting version 3 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4. +To ensure that fast multithreaded decoding is possible, starting version 3 and if frame\_pixel\_width * frame\_pixel\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4. Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format. For each frame, each position in the slice raster MUST be filled by one and only one slice of the frame (no missing slice position, no slice overlapping). -- 2.7.0.windows.1 --------------C404EBD765F1C8AFC8CB4F14-- From nobody Mon Jun 13 12:18:49 2016 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 A0F7D12D950 for ; Mon, 13 Jun 2016 12:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 vVkLbBm0ZZ-Y for ; Mon, 13 Jun 2016 12:18:41 -0700 (PDT) Received: from 10.mo178.mail-out.ovh.net (10.mo178.mail-out.ovh.net [46.105.76.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301A412D93C for ; Mon, 13 Jun 2016 12:18:41 -0700 (PDT) Received: from player791.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id AA0371008CB2 for ; Mon, 13 Jun 2016 21:18:39 +0200 (CEST) Received: from [192.168.2.101] (p5DDB5AFE.dip0.t-ipconnect.de [93.219.90.254]) (Authenticated sender: jerome@francoallemand.eu) by player791.ha.ovh.net (Postfix) with ESMTPSA id 8A3E4420078 for ; Mon, 13 Jun 2016 21:18:39 +0200 (CEST) To: cellar@ietf.org References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> <20160608153508.GW4636@nb4> <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> <20160611201955.GZ4636@nb4> From: Jerome Martinez Message-ID: Date: Mon, 13 Jun 2016 21:18:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160611201955.GZ4636@nb4> Content-Type: multipart/mixed; boundary="------------CADBBA0CFE33C44A1DB70667" X-Ovh-Tracer-Id: 508625287106465937 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrkedugddufedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] [PATCH FFV1 2/2] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 19:18:43 -0000 This is a multi-part message in MIME format. --------------CADBBA0CFE33C44A1DB70667 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 11/06/2016 22:19, Michael Niedermayer a crit : > On Thu, Jun 09, 2016 at 11:29:25PM +0200, Jerome Martinez wrote: > > [...] > >> +**plane\_pixel\_height[ p ]** is the height in pixels of plane p of the slice. >> +plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_planes ? 2 : 0 ) ] value is slice\_pixel\_height >> +if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixel\_height[ 2 ] value is ⌈slice\_pixel\_height / v\_chroma\_subsample⌉ > the plane\_pixel\_*[0] should be changed to be rounded toward chroma > raster size in the next bitstream version > this would simplify slice geometry i think > I add this item to my list of items to debate after the standardization of FFV1 0/1/3. Attached is the patch corresponding to changes only. --------------CADBBA0CFE33C44A1DB70667 Content-Type: text/plain; charset=UTF-8; name="0002-SliceContent-description-update.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="0002-SliceContent-description-update.patch" >From 1791299ecd9df5b623416b58398c4c3fe63d06d3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= Date: Mon, 13 Jun 2016 21:11:39 +0200 Subject: [PATCH 2/2] SliceContent description update Describe how to call Line() when color_space is 0 Define slice_pixel_height and slice_pixel_y Define plane_pixel_height[ p ] --- ffv1.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/ffv1.md b/ffv1.md index 49019c2..dfdb7e7 100644 --- a/ffv1.md +++ b/ffv1.md @@ -631,9 +631,10 @@ Inferred to be 0 if not present. |SliceContent( ) { | type | |    if( colorspace\_type == 0) { | | |        for( p = 0; p \< primary\_color\_count; p++ ) { | | -|            Plane( p ) | | +|            for( y = 0; y \< plane\_pixel\_height[ p ]; y++ ) | | +|                Line( p, y ) | | |    } else if( colorspace\_type == 1 ) { | | -|        for( y = 0; y \< height; y++ ) | | +|        for( y = 0; y \< slice\_pixel\_height; y++ ) | | |            for( p = 0; p \< primary\_color\_count; p++ ) { | | |                Line( p, y ) | | |    } | | @@ -641,6 +642,16 @@ Inferred to be 0 if not present. **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + ( alpha_plane ? 1 : 0 ). +**plane\_pixel\_height[ p ]** is the height in pixels of plane p of the slice. +plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_planes ? 2 : 0 ) ] value is slice\_pixel\_height +if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixel\_height[ 2 ] value is ⌈slice\_pixel\_height / v\_chroma\_subsample⌉ + +**slice\_pixel\_height** is the height in pixels of the slice. +Its value is ⌊( plane\_y + plane\_height ) * frame_pixel\_height / num\_v\_slices⌋ - slice\_pixel\_y + +**slice\_pixel\_y** is the slice vertical position in pixels. +Its value is ⌊slice_y * frame_pixel\_height / num\_v\_slices⌋ + ## Slice Footer Note: slice footer is always byte aligned. -- 2.7.0.windows.1 --------------CADBBA0CFE33C44A1DB70667-- From nobody Thu Jun 16 21:44:26 2016 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 A9C9D12D0EB for ; Thu, 16 Jun 2016 21:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 LgbrCdGTJdwG for ; Thu, 16 Jun 2016 21:44:23 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 6CCFB12D600 for ; Thu, 16 Jun 2016 21:36:18 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:37954 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bDlVw-001Uan-GV for cellar@ietf.org; Fri, 17 Jun 2016 00:36:17 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <5CBBD1F2-E4D4-4453-B74E-BC854B3F673D@dericed.com> Date: Fri, 17 Jun 2016 00:36:14 -0400 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] An attempt at EBML specification in RFC form X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 04:44:25 -0000 Hi all, I published a pull request [1] to the EBML specification which includes = changes to support making an RFC document from the markdown-based = specification using both mmark [2] and xml2rfc. Here=E2=80=99s some = notes and questions about this work: The use of hyphenated section names would not work with mmark, so I = changed the phrase =E2=80=9CIdentically-Recurring Elements=E2=80=9D to = "Identically Recurring Elements=E2=80=9D [3]. If there=E2=80=99s any = objection I could feasibly add an id to the associated section header. I added a new markdown file called rfc_frontmatter.markdown which = contains metadata used to construct the RFC document. This currently = contains: % Title =3D "Extensible Binary Meta Language" % abbrev =3D "EBML" % category =3D "info" % docName =3D "" % ipr=3D "trust200902" % area =3D "" % workgroup =3D "cellar" % keyword =3D [""] % % [[author]] % initials=3D"S." % surname=3D"Lhomme" % fullname=3D"Steve Lhomme=E2=80=9D This is partly based off changes from a document I found in the mmark = repo with some customization for this project. However I am very = unfamiliar with the IETF use of these values. What is our area, ipr, = docName, etc? Also, I had used Steve as the author, but who I=E2=80=99m = unclear on who are the authors of the EBML specification. Steve? Moritz? I added a Makefile [4] to build the rfc output in text and html form via = mmark and pandoc. I am not well experienced in coding Makefiles and = welcome suggestions. I also added a gitignore file to ignore the outputs of the makefile to = make it easier for git users to not accidentally commit the built files. The text output of the makefile is available for review at = https://gist.github.com/dericed/fee1352b273be97a2e1879760ade96c3 [5]. = The sections in lines 13 - 43 [6] appear to be IETF boilerplate output = by xml2rfc. Should I make any changes to the use of xml2rfc for now? Also now that we can see the EBML specification in RFC form there are = some places where the formatting of the document should clearly be = adjusted. Some of the markdown used prevents the RFC from properly = line-wrapping and some tables don=E2=80=99t fit in the width of the RFC. = I suggest these changes wait for another pull request, but would like = comments on this approach for building RFC from our markdown. Best Regards, Dave Rice [1] https://github.com/Matroska-Org/ebml-specification/pull/66 [2] https://github.com/miekg/mmark [3] = https://github.com/Matroska-Org/ebml-specification/pull/66/files/c5cec7b4b= a212bd08cb466d9a5ea80fd9915a809?short_path=3D01f3b0f#diff-01f3b0f2fbf3e443= 27e6072f64ddc8a0 [4] = https://github.com/Matroska-Org/ebml-specification/pull/66/commits/d8560f1= 6c108b8a184e47cdefb43512a6a46dc9b [5] https://gist.github.com/dericed/fee1352b273be97a2e1879760ade96c3 [6] = https://gist.github.com/dericed/fee1352b273be97a2e1879760ade96c3#file-ebml= _rfc-txt-L13-L43= From nobody Thu Jun 16 22:01:30 2016 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 F35AF12B050 for ; Thu, 16 Jun 2016 22:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 BVnE36nWospv for ; Thu, 16 Jun 2016 22:01:27 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 24FE112B00C for ; Thu, 16 Jun 2016 22:01:27 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:36380 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bDluH-001vYx-5x for cellar@ietf.org; Fri, 17 Jun 2016 01:01:26 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 17 Jun 2016 01:01:23 -0400 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] An attempt at FFV1 specification in RFC form X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 05:01:29 -0000 Hi all, As with the last thread I submitted a pull request [1] to add RFC = features to the FFV1 repo. Some comments and questions: To get everything to work I had to remove [2] some stray   from the = markdown. Michael, any reason for those to be there? The ffv1 repo already has a Makefile which outputs HTML and PDF versions = of the specification and uses metadata tags at the top of the spec to = communicate to pandoc which creates the output. Since the metadata for = the PDF/HTML is different than that for the RFC, I created a frontmatter = file for each of those types. The rfc_frontmatter currently looks like = this: % Title =3D "FF Video Codec 1" % abbrev =3D "FFV1" % category =3D "info" % docName =3D "" % ipr=3D "trust200902" % area =3D "" % workgroup =3D "cellar" % keyword =3D [""] % % [[author]] % initials=3D"M." % surname=3D"Niedermayer" % fullname=3D"Michael Niedermayer" As with the other thread, I am not very familiar with using these = values. Feedback and corrections are very welcome. I did edits to the FFV1 Makefile that were similar to the EBML Makefile = [3]. Feedback welcome. And here=E2=80=99s an example of the current RFC output from the = makefile in this pull request: = https://gist.github.com/dericed/882c4ad6f4cc3e16a8104a663964e42c [4]. There are a few places where the markdown formatting of the FFV1 = specification breaks the RFC=E2=80=99s line wrapping. Also the FFV1 = specification includes a lot of LaTeX and math which doesn=E2=80=99t = render properly in a text based RFC. The equations in here may be a = challenge to present accurately in plain text. Best Regards, Dave Rice [1] https://github.com/FFmpeg/FFV1/pull/19 [2] = https://github.com/FFmpeg/FFV1/pull/19/commits/2cbbae19d282f6c440c7986d0d5= c5e554c756ae4 [3] = https://github.com/FFmpeg/FFV1/pull/19/commits/8b6b1ef29fb79a40fe135b01cc9= 3eacdf48718aa [4] https://gist.github.com/dericed/882c4ad6f4cc3e16a8104a663964e42c= From nobody Thu Jun 16 22:44:25 2016 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 CDB3F12B00C for ; Thu, 16 Jun 2016 22:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=unavailable 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 01Ez4M4aNASu for ; Thu, 16 Jun 2016 22:44:22 -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 B200B12B035 for ; Thu, 16 Jun 2016 22:36:33 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 7FA59C45C1 for ; Fri, 17 Jun 2016 05:36:33 +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 Cjd7M7zUlfzG for ; Fri, 17 Jun 2016 05:36:32 +0000 (UTC) Received: from [172.26.0.233] (unknown [194.73.252.249]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 44502C4530 for ; Fri, 17 Jun 2016 05:36:31 +0000 (UTC) Message-ID: <57638C5E.90506@xiph.org> Date: Thu, 16 Jun 2016 22:36:30 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: <5CBBD1F2-E4D4-4453-B74E-BC854B3F673D@dericed.com> In-Reply-To: <5CBBD1F2-E4D4-4453-B74E-BC854B3F673D@dericed.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] An attempt at EBML specification in RFC form X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 05:44:24 -0000 Dave Rice wrote: > % Title = "Extensible Binary Meta Language" > % abbrev = "EBML" > % category = "info" This should be "std" (for Standards Track, instead of Informational, as we agreed when adding the milestone). > % docName = "" This should be something like "draft--cellar-ebml-00". The use of an author's name indicates that this is an individual draft. If it is formally adopted as a working group draft, it will become "draft-ietf-cellar-ebml-00" instead. The trailing -00 is the version number, which you will increment each time you submit a new version to the datatracker. > % ipr= "trust200902" Unless you're updating an old RFC (which you're not), this is the correct thing to use. > % area = "" CELLAR is in the Applications and Real-Time Area, so "art" is the correct thing here. You can find this information on the charter page for CELLAR in the datatracker: https://datatracker.ietf.org/wg/cellar/charter/ > Also, I had used Steve as the author, but who I’m unclear on who are the authors of the EBML specification. Steve? Moritz? From a technical point of view, the authors/editors are the people who must sign off during the AUTH48 process (the last step before publication by the RFC Editor) and respond to inquiries such as errata. One author is required to approve posting an updated version of a draft to the datatracker. All authors are required to approve the document during AUTH48. From a policy point of view, exactly who should be an author or editor is somewhat subjective. You can find some guidance in various places: https://tools.ietf.org/html/rfc7221#section-3 https://www.rfc-editor.org/old/policy.html#policy.authlist https://tools.ietf.org/html/draft-carpenter-whats-an-author (that last one is an individual draft, and thus only represents that individual's opinion, rather than the consensus of any working group or of the IETF as a whole) Since we have not yet formally adopted your draft as a working-group draft, and it is still an individual draft, the choice of authors/editors is "whoever wants to be". It is the WG chairs' responsibility to appoint authors/editors when a draft is formally adopted, but unless there is some specific reason to do otherwise, this is usually just the same authors and editors who contributed the individual draft. Once adopted, the authors/editors are required to follow the guidelines in https://tools.ietf.org/html/rfc2418#section-6.3 From nobody Fri Jun 17 01:49:22 2016 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 01B7912D109 for ; Fri, 17 Jun 2016 01:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 Bnffmj1cy71y for ; Fri, 17 Jun 2016 01:49:18 -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 1D23812D098 for ; Fri, 17 Jun 2016 01:49:17 -0700 (PDT) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u5H8nFMM032271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 17 Jun 2016 10:49:15 +0200 Received: from Castor.local (dynamic.wline.6rd.res.cust.swisscom.ch [IPv6:2a02:1205:5021:2510:58db:59dc:7b1:21e4] (may be forged)) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u5H8nFhQ030578 for ; Fri, 17 Jun 2016 10:49:15 +0200 Date: Fri, 17 Jun 2016 10:49:15 +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 (470) 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] An attempt at EBML specification in RFC form X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 08:49:21 -0000 Oops, sorry! I corrected more or less the same on GitHub before noticing this email... Reto Timothy B. Terriberry wrote: >Dave Rice wrote: >>% Title =3D "Extensible Binary Meta Language" >>% abbrev =3D "EBML" >>% category =3D "info" > >This should be "std" (for Standards Track, instead of=20 >Informational, as we agreed when adding the milestone). > >>% docName =3D "" > >This should be something like "draft-surname>-cellar-ebml-00". The use of an author's name indicates=20 >that this is an individual draft. If it is formally adopted as=20 >a working group draft, it will become=20 >"draft-ietf-cellar-ebml-00" instead. The trailing -00 is the=20 >version number, which you will increment each time you submit a=20 >new version to the datatracker. > >>% ipr=3D "trust200902" > >Unless you're updating an old RFC (which you're not), this is=20 >the correct thing to use. > >>% area =3D "" > >CELLAR is in the Applications and Real-Time Area, so "art" is=20 >the correct thing here. You can find this information on the=20 >charter page for CELLAR in the datatracker: https://datatracker.ietf.org/w= g/cellar/charter/ > >>Also, I had used Steve as the author, but who I=E2=80=99m unclear on who = are the >authors of the EBML specification. Steve? Moritz? > > From a technical point of view, the authors/editors are the=20 >people who must sign off during the AUTH48 process (the last=20 >step before publication by the RFC Editor) and respond to=20 >inquiries such as errata. One author is required to approve=20 >posting an updated version of a draft to the datatracker. All=20 >authors are required to approve the document during AUTH48. > > From a policy point of view, exactly who should be an author=20 >or editor is somewhat subjective. You can find some guidance in=20 >various places: > >https://tools.ietf.org/html/rfc7221#section-3 >https://www.rfc-editor.org/old/policy.html#policy.authlist >https://tools.ietf.org/html/draft-carpenter-whats-an-author > >(that last one is an individual draft, and thus only represents=20 >that individual's opinion, rather than the consensus of any=20 >working group or of the IETF as a whole) > >Since we have not yet formally adopted your draft as a=20 >working-group draft, and it is still an individual draft, the=20 >choice of authors/editors is "whoever wants to be". It is the=20 >WG chairs' responsibility to appoint authors/editors when a=20 >draft is formally adopted, but unless there is some specific=20 >reason to do otherwise, this is usually just the same authors=20 >and editors who contributed the individual draft. Once adopted,=20 >the authors/editors are required to follow the guidelines in https://tools= .ietf.org/html/rfc2418#section-6.3 > >_______________________________________________ >Cellar mailing list >Cellar@ietf.org >https://www.ietf.org/mailman/listinfo/cellar > AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: https://reto.ch | Twitter: @retoch From nobody Fri Jun 17 02:37:28 2016 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 9FC2C12D0A5 for ; Fri, 17 Jun 2016 02:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 bvD8F5TtId8b for ; Fri, 17 Jun 2016 02:37:25 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8C512B059 for ; Fri, 17 Jun 2016 02:37:25 -0700 (PDT) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id AECDF41C08F for ; Fri, 17 Jun 2016 11:37:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id etYgaw12K80z for ; Fri, 17 Jun 2016 11:37:22 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0B09641C086 for ; Fri, 17 Jun 2016 11:37:21 +0200 (CEST) Date: Fri, 17 Jun 2016 11:37:02 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160617093702.GO4636@nb4> References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> <20160608153508.GW4636@nb4> <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> <20160611201955.GZ4636@nb4> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkUjpNzvt17RSo84" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] [PATCH FFV1 1/2] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 09:37:26 -0000 --vkUjpNzvt17RSo84 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 13, 2016 at 09:14:07PM +0200, Jerome Martinez wrote: > Le 11/06/2016 =E0 22:19, Michael Niedermayer a =E9crit : > >On Thu, Jun 09, 2016 at 11:29:25PM +0200, Jerome Martinez wrote: [...] > @@ -837,15 +845,15 @@ Table: 0 0 1 1 1 1 2 2-2-2-2-1-1-1-1 0 > =20 > Stored values: 1, 3, 1 > =20 > -```c > -QuantizationTable( i ) { // type > - scale =3D 1 > - for( j =3D 0; j < MAX_CONTEXT_INPUTS; j++ ) { > - QuantizationTablePerContext( i, j, scale ) > - scale *=3D 2 * len_count[ i ][ j ] - 1 > - } > - context_count[ i ] =3D ( scale + 1 ) / 2 > -``` > +| = | > +|-----------------------------------------------------------------------= ----| > +| QuantizationTable( i ) { = | > +|=A0=A0=A0scale =3D 1 = | > +|=A0=A0=A0for( j =3D 0; j < MAX_CONTEXT_INPUTS; j++ ) { = | > +|=A0=A0=A0=A0=A0=A0=A0QuantizationTablePerContext( i, j, scale ) = | > +|=A0=A0=A0=A0=A0=A0=A0scale \*=3D 2 \* len_count[ i ][ j ] - 1 = | > +|=A0=A0=A0} = | > +|=A0=A0=A0context_count[ i ] =3D ⌊( scale + 1 ) / 2⌋ = | ^^^^^^^ i ommitted this one from the commit as scale is always odd thus scale+1 always a multiple of 2 [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. --vkUjpNzvt17RSo84 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldjxL4ACgkQYR7HhwQLD6sSqQCgjs0kqRmzZZ9XF8O10P6VpG+L fiEAn2l08IgJmoPn++SewvJv/+hrLp6r =3mPV -----END PGP SIGNATURE----- --vkUjpNzvt17RSo84-- From nobody Fri Jun 17 02:38:26 2016 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 AAC9412D0A5 for ; Fri, 17 Jun 2016 02:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 zpnXkFGBbtfm for ; Fri, 17 Jun 2016 02:38:24 -0700 (PDT) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE1B12B05A for ; Fri, 17 Jun 2016 02:38:24 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 757E84860D1 for ; Fri, 17 Jun 2016 11:29:19 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 425C741C096 for ; Fri, 17 Jun 2016 11:29:18 +0200 (CEST) Date: Fri, 17 Jun 2016 11:28:59 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160617092859.GN4636@nb4> References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> <20160608153508.GW4636@nb4> <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> <20160611201955.GZ4636@nb4> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="epRuUhiNkW/O9uqo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] [PATCH FFV1 1/2] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 09:38:26 -0000 --epRuUhiNkW/O9uqo Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 13, 2016 at 09:14:07PM +0200, Jerome Martinez wrote: > Le 11/06/2016 =E0 22:19, Michael Niedermayer a =E9crit : > >On Thu, Jun 09, 2016 at 11:29:25PM +0200, Jerome Martinez wrote: > >[...] > >if a / b is the precisse and not rounded value then a % b as > >the corresponding remainder does not make sense >=20 > a % b removed >=20 > >[...] > >please move the reformating into a separate patch > >its difficult to see what changed >=20 > Patch 1/2 is about formatting only. > ffv1.md | 64 ++++++++++++++++++++++++++++++++++++---------------------= ------- > 1 file changed, 36 insertions(+), 28 deletions(-) > 863cabb56a2e87858b26101b59445d6317f3b0bd 0001-Reformatting-before-SliceC= ontent-changes.patch > >From 42509e64d6560e5724c0ccfbc27f3ca306d35451 Mon Sep 17 00:00:00 2001 > From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D > Date: Mon, 13 Jun 2016 21:05:17 +0200 > Subject: [PATCH 1/2] Reformatting before SliceContent changes >=20 > Explicit floor and ceil instead of truncation of a / b > Add "pixel_" prefix in order to avoid conflict with width/height > in count of elements in the slice raster > Larger SliceContent formatted array size > QuantizationTable() moved to a formatted array applied thanks [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope --epRuUhiNkW/O9uqo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldjwtsACgkQYR7HhwQLD6tQSgCeJd1Nk4R0uvGpnVuYQQKpEivA n2IAnRYCsO9BZ/jTZKKTC3i9H2620JTa =12C4 -----END PGP SIGNATURE----- --epRuUhiNkW/O9uqo-- From nobody Fri Jun 17 05:20:52 2016 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 2CAEF12D146 for ; Fri, 17 Jun 2016 05:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 bHW6v2WGMWnK for ; Fri, 17 Jun 2016 05:20:46 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 9D1B7127058 for ; Fri, 17 Jun 2016 05:20:46 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:35866 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bDslH-003kn0-RV; Fri, 17 Jun 2016 08:20:45 -0400 Content-Type: multipart/mixed; boundary="Apple-Mail=_3D35EB3B-CCAE-45D1-BBEC-D0B319198DAA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: <57638C5E.90506@xiph.org> Date: Fri, 17 Jun 2016 08:20:33 -0400 Message-Id: <286C62FD-3073-487F-AD1A-A81CC2C3D6D6@dericed.com> References: <5CBBD1F2-E4D4-4453-B74E-BC854B3F673D@dericed.com> <57638C5E.90506@xiph.org> To: "Timothy B. Terriberry" X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-1.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] An attempt at EBML specification in RFC form X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 12:20:50 -0000 --Apple-Mail=_3D35EB3B-CCAE-45D1-BBEC-D0B319198DAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 17, 2016, at 1:36 AM, Timothy B. Terriberry = wrote: >=20 > Dave Rice wrote: >> % Title =3D "Extensible Binary Meta Language" >> % abbrev =3D "EBML" >> % category =3D "info" >=20 > This should be "std" (for Standards Track, instead of Informational, = as we agreed when adding the milestone). >=20 >> % docName =3D "" >=20 > This should be something like "draft--cellar-ebml-00". The use of an author's name indicates that = this is an individual draft. If it is formally adopted as a working = group draft, it will become "draft-ietf-cellar-ebml-00" instead. The = trailing -00 is the version number, which you will increment each time = you submit a new version to the datatracker. >=20 >> % ipr=3D "trust200902" >=20 > Unless you're updating an old RFC (which you're not), this is the = correct thing to use. >=20 >> % area =3D "" >=20 > CELLAR is in the Applications and Real-Time Area, so "art" is the = correct thing here. You can find this information on the charter page = for CELLAR in the datatracker: = https://datatracker.ietf.org/wg/cellar/charter/ I updated the pull request based on all the above suggestions. The = metadata for the EBML RFC is now: % Title =3D "Extensible Binary Meta Language" % abbrev =3D "EBML" % category =3D "std" % docName =3D "draft-lhomme-cellar-ebml-00" % ipr=3D "trust200902" % area =3D "art" % workgroup =3D "cellar" % keyword =3D [""] % % [[author]] % initials=3D"S." % surname=3D"Lhomme" % fullname=3D"Steve Lhomme" >> Also, I had used Steve as the author, but who I=E2=80=99m unclear on = who are the authors of the EBML specification. Steve? Moritz? >=20 > =46rom a technical point of view, the authors/editors are the people = who must sign off during the AUTH48 process (the last step before = publication by the RFC Editor) and respond to inquiries such as errata. = One author is required to approve posting an updated version of a draft = to the datatracker. All authors are required to approve the document = during AUTH48. >=20 > =46rom a policy point of view, exactly who should be an author or = editor is somewhat subjective. You can find some guidance in various = places: >=20 > https://tools.ietf.org/html/rfc7221#section-3 > https://www.rfc-editor.org/old/policy.html#policy.authlist > https://tools.ietf.org/html/draft-carpenter-whats-an-author >=20 > (that last one is an individual draft, and thus only represents that = individual's opinion, rather than the consensus of any working group or = of the IETF as a whole) >=20 > Since we have not yet formally adopted your draft as a working-group = draft, and it is still an individual draft, the choice of = authors/editors is "whoever wants to be". It is the WG chairs' = responsibility to appoint authors/editors when a draft is formally = adopted, but unless there is some specific reason to do otherwise, this = is usually just the same authors and editors who contributed the = individual draft. Once adopted, the authors/editors are required to = follow the guidelines in https://tools.ietf.org/html/rfc2418#section-6.3 Steve, Moritz, other, specific suggestions for EBML authorship? Leave as = Steve alone, add other working group members? Here=E2=80=99s an update of the EBML draft. I=E2=80=99m not suggesting = this is =E2=80=98done=E2=80=99 but it does meet the =E2=80=98words on a = page=E2=80=99 test and happens to also look like an RFC draft. --Apple-Mail=_3D35EB3B-CCAE-45D1-BBEC-D0B319198DAA Content-Disposition: attachment; filename=draft-lhomme-cellar-ebml-00.txt Content-Type: text/plain; name="draft-lhomme-cellar-ebml-00.txt" Content-Transfer-Encoding: quoted-printable cellar S. Lhomme Internet-Draft June 17, 2016 Intended status: Standards Track Expires: December 19, 2016 Extensible Binary Meta Language draft-lhomme-cellar-ebml-00 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 19, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Lhomme Expires December 19, 2016 [Page 1] =0C Internet-Draft EBML June 2016 Table of Contents 1. EBML specifications . . . . . . . . . . . . . . . . . . . . . 2 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Notation and Conventions . . . . . . . . . . . . . . . . 3 1.3. Security Considerations . . . . . . . . . . . . . . . . . 3 1.4. Structure . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5. Variable Size Integer . . . . . . . . . . . . . . . . . . 4 1.5.1. VINT_WIDTH . . . . . . . . . . . . . . . . . . . . . 4 1.5.2. VINT_MARKER . . . . . . . . . . . . . . . . . . . . . 4 1.5.3. VINT_DATA . . . . . . . . . . . . . . . . . . . . . . 4 1.5.4. VINT Examples . . . . . . . . . . . . . . . . . . . . 4 1.6. Element ID . . . . . . . . . . . . . . . . . . . . . . . 5 1.7. Element Data Size . . . . . . . . . . . . . . . . . . . . 6 1.8. EBML Element Types . . . . . . . . . . . . . . . . . . . 8 1.9. EBML Document . . . . . . . . . . . . . . . . . . . . . . 9 1.9.1. EBML Header . . . . . . . . . . . . . . . . . . . . . 9 1.9.2. EBML Body . . . . . . . . . . . . . . . . . . . . . . 10 1.10. EBML Stream . . . . . . . . . . . . . . . . . . . . . . . 10 1.11. Elements semantic . . . . . . . . . . . . . . . . . . . . 10 1.11.1. EBML Schema . . . . . . . . . . . . . . . . . . . . 10 1.11.2. EBML Header Elements . . . . . . . . . . . . . . . . 18 1.11.3. Global elements (used everywhere in the format) . . 20 2.1. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 1. EBML specifications 1.1. Introduction EBML, short for Extensible Binary Meta Language, specifies a binary and octet (byte) aligned format inspired by the principle of XML. The goal of the EBML Specification is to define a generic, binary, space-efficient format that may be utilized to define more complex formats (such as containers for multimedia content) using an EBML Schema. The definition of the EBML format recognizes the idea behind HTML and XML as a good one: separate structure and semantics allowing the same structural layer to be used with multiple, possibly widely differing semantic layers. Except for the EBML Header and a few global elements this specification does not define particular EBML format semantics; however this specification is intended to define how other EBML-based formats may be defined. EBML uses a simple approach of building Elements upon three pieces of data (tag, length, and value) as this approach is well known, easy to parse, and allows selective data parsing. The EBML structure Lhomme Expires December 19, 2016 [Page 2] =0C Internet-Draft EBML June 2016 additionally allows for hierarchical arrangement to support complex structural formats in an efficient manner. 1.2. Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 1.3. Security Considerations EBML itself does not offer any kind of security. It has nothing to do with authentication, it does not provide confidentiality, only marginally useful and effective data integrity options (CRC elements). EBML does not provide any kind of authorization. Even if the semantic layer offers any kind of encryption, EBML itself may leak information at both the semantic layer (as declared via the DocType element) and within the EBML structure (you can derive the presence of EBML elements even with an unknown semantic layer with a heuristic approach; not without errors, of course, but with a certain degree of confidence). Attacks on an EBML reader may include: - Invalid Element IDs that are longer than the limit stated in the EBMLMaxIDLength Element of the EBML Header. - Invalid Element IDs that are not encoded in the shortest-possible way. - Invalid Element IDs comprised of reserved values. - Invalid Element Data Size values that are longer than the limit stated in the EBMLMaxSizeLength Element of the EBML Header. - Invalid Element Data Size values (e.g. extending the length of the Element beyond the scope of the Parent Element; possibly triggering access-out-of-bounds issues). - Very high lengths in order to force out-of-memory situations resulting in a denial of service, access- out-of-bounds issues etc. - Missing Elements that are mandatory and have no declared default value. - Usage of 0x00 octets in EBML Elements with a string type. - Usage of invalid UTF-8 encoding in EBML Elements of UTF-8 type (e.g. in order to trigger access-out-of- bounds or buffer overflow issues). - Usage of invalid data in EBML Elements with a date type. 1.4. Structure EBML uses a system of Elements to compose an EBML Document. Elements incorporate three parts: an Element ID, an Element Data Size, and Element Data. The Element Data, which is described by the Element ID, may include either binary data or one or many other Elements. Lhomme Expires December 19, 2016 [Page 3] =0C Internet-Draft EBML June 2016 1.5. Variable Size Integer The Element ID and Element Data Size are both encoded as a Variable Size Integer, developed according to a UTF-8 like system. The Variable Size Integer is composed of a VINT_WIDTH, VINT_MARKER, and VINT_DATA, in that order. Variable Size Integers shall be referred to as VINT for shorthand. 1.5.1. VINT_WIDTH Each Variable Size Integer begins with a VINT_WIDTH which consists of zero or many zero-value bits. The count of consecutive zero-values of the VINT_WIDTH plus one equals the length in octets of the Variable Size Integer. For example, a Variable Size Integer that starts with a VINT_WIDTH which contains zero consecutive zero-value bits is one octet in length and a Variable Size Integer that starts with one consecutive zero-value bit is two octets in length. The VINT_WIDTH MUST only contain zero-value bits or be empty. 1.5.2. VINT_MARKER The VINT_MARKER serves as a separator between the VINT_WIDTH and VINT_DATA. Each Variable Size Integer MUST contain exactly one VINT_MARKER. The VINT_MARKER MUST be one bit in length and contain a bit with a value of one. The first bit with a value of one within the Variable Size Integer is the VINT_MARKER. 1.5.3. VINT_DATA The VINT_DATA portion of the Variable Size Integer includes all data that follows (but not including) the VINT_MARKER until end of the Variable Size Integer whose length is derived from the VINT_WIDTH. The bits required for the VINT_WIDTH and the VINT_MARKER combined use one bit per octet of the total length of the Variable Size Integer. Thus a Variable Size Integer of 1 octet length supplies 7 bits for VINT_DATA, a 2 octet length supplies 14 bits for VINT_DATA, and a 3 octet length supplies 21 bits for VINT_DATA. If the number of bits required for VINT_DATA are less than the bit size of VINT_DATA, then VINT_DATA may be zero-padded to the left to a size that fits. The VINT_DATA value MUST be expressed a big-endian unsigned integer. 1.5.4. VINT Examples This table shows examples of Variable Size Integers at widths of 1 to 5 octets. The Representation column depicts a binary expression of Variable Size Integers where VINT_WIDTH is depicted by '0', the VINT_MARKER as '1', and the VINT_DATA as 'x'. Lhomme Expires December 19, 2016 [Page 4] =0C Internet-Draft EBML June 2016 +-------------+------+----------------------------------------------+ | Octet Width | Size | Representation | +-------------+------+----------------------------------------------+ | 1 | 2^7 | 1xxx xxxx | | 2 | 2^14 | 01xx xxxx xxxx xxxx | | 3 | 2^21 | 001x xxxx xxxx xxxx xxxx xxxx | | 4 | 2^28 | 0001 xxxx xxxx xxxx xxxx xxxx xxxx xxxx | | 5 | 2^35 | 0000 1xxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx | | | | xxxx | +-------------+------+----------------------------------------------+ Note that data encoded as a Variable Size Integer may be rendered at octet widths larger than needed to store the data. In this table a binary value of 0b10 is shown encoded as different Variable Size Integers with widths from one octet to four octet. All four encoded examples have identical semantic meaning though the VINT_WIDTH and the padding of the VINT_DATA vary. +--------------+-------------+--------------------------------------+ | Binary Value | Octet Width | As Represented in Variable Size | | | | Integer | +--------------+-------------+--------------------------------------+ | 10 | 1 | 1000 0010 | | 10 | 2 | 0100 0000 0000 0010 | | 10 | 3 | 0010 0000 0000 0000 0000 0010 | | 10 | 4 | 0001 0000 0000 0000 0000 0000 0000 | | | | 0010 | +--------------+-------------+--------------------------------------+ 1.6. Element ID The Element ID MUST be encoded as a Variable Size Integer. By default, EBML Element IDs may be encoded in lengths from one octet to four octets, although Element IDs of greater lengths may be used if the octet length of the EBML Document's longest Element ID is declared in the EBMLMaxIDLength Element of the EBML Header. The VINT_DATA component of the Element ID MUST NOT be set to either all zero values or all one values. The VINT_DATA component of the Element ID MUST be encoded at the shortest valid length. For example, an Element ID with binary encoding of 1011 1111 is valid, whereas an Element ID with binary encoding of 0100 0000 0011 1111 stores a semantically equal VINT_DATA but is invalid because a shorter VINT encoding is possible. The following table details this specific example further: Lhomme Expires December 19, 2016 [Page 5] =0C Internet-Draft EBML June 2016 +------------+-------------+----------------+-------------------+ | VINT_WIDTH | VINT_MARKER | VINT_DATA | Element ID Status | +------------+-------------+----------------+-------------------+ | | 1 | 0111111 | Valid | | 0 | 1 | 00000000111111 | Invalid | +------------+-------------+----------------+-------------------+ The octet length of an Element ID determines its EBML Class. +------------+--------------+--------------------------------+ | EBML Class | Octet Length | Number of Possible Element IDs | +------------+--------------+--------------------------------+ | Class A | 1 | 2^7 - 2 =3D 126 | | Class B | 2 | 2^14 - 2^7 - 1 =3D 16,255 | | Class C | 3 | 2^21 - 2^14 - 1 =3D 2,080,767 | | Class D | 4 | 2^28 - 2^21 - 1 =3D 266,388,303 | +------------+--------------+--------------------------------+ 1.7. Element Data Size The Element Data Size expresses the length in octets of Element Data. The Element Data Size itself MUST be encoded as a Variable Size Integer. By default, EBML Element Data Sizes can be encoded in lengths from one octet to eight octets, although Element Data Sizes of greater lengths MAY be used if the octet length of the EBML Document's longest Element Data Size is declared in the EBMLMaxSizeLength Element of the EBML Header. Unlike the VINT_DATA of the Element ID, the VINT_DATA component of the Element Data Size is NOT REQUIRED to be encoded at the shortest valid length. For example, an Element Data Size with binary encoding of 1011 1111 or a binary encoding of 0100 0000 0011 1111 are both valid Element Data Sizes and both store a semantically equal value. Although an Element ID with all VINT_DATA bits set to zero is invalid, an Element Data Size with all VINT_DATA bits set to zero is allowed for EBML Data Types which do not mandate a non-zero length. An Element Data Size with all VINT_DATA bits set to zero indicates that the Element Data of the Element is zero octets in length. Such an Element is referred to as an Empty Element. If an Empty Element has a "default" value declared then that default value MUST be interpreted as the value of the Empty Element. If an Empty Element has no "default" value declared then the semantic meaning of Empty Element is defined as part of the definition of the EBML Element Types. An Element Data Size with all VINT_DATA bits set to one is reserved as an indicator that the size of the Element is unknown. The only reserved value for the VINT_DATA of Element Data Size is all bits set Lhomme Expires December 19, 2016 [Page 6] =0C Internet-Draft EBML June 2016 to one. This rule allows for an Element to be written and read before the size of the Element is known; however unknown Element Data Size values SHOULD NOT be used unnecessarily. An Element with an unknown Element Data Size MUST be a Master-element in that it contains other EBML Elements as sub-elements. Master-elements MAY only use an unknown size if the "unknownsizeallowed" attribute of the EBML Schema is set to true. The end of a Master-element with unknown size is determined by the beginning of the next element that is not a valid sub-element of that Master-element. An Element with an unknown Element Data Size is referred to as an "Unknown-Sized Element". For Element Data Sizes encoded at octet lengths from one to eight, this table depicts the range of possible values that can be encoded as an Element Data Size. An Element Data Size with an octet length of 8 is able to express a size of 2^56-2 or 72,057,594,037,927,934 octets (or about 72 petabytes). The maximum possible value that can be stored as Element Data Size is referred to as "VINTMAX". +--------------+----------------------+ | Octet Length | Possible Value Range | +--------------+----------------------+ | 1 | 0 to 2^7-2 | | 2 | 0 to 2^14-2 | | 3 | 0 to 2^21-2 | | 4 | 0 to 2^28-2 | | 5 | 0 to 2^35-2 | | 6 | 0 to 2^42-2 | | 7 | 0 to 2^49-2 | | 8 | 0 to 2^56-2 | +--------------+----------------------+ If the length of Element Data equals 2^(n*7)-1 then the octet length of the Element Data Size MUST be at least n+1. This rule prevents an Element Data Size from being expressed as a reserved value. For example, an Element with an octet length of 127 MUST NOT be encoded in an Element Data Size encoding with a one octet length. The following table clarifies this rule by showing a valid and invalid expression of an Element Data Size with a VINT_DATA of 127 (which is equal to 2^(1*7)-1). Lhomme Expires December 19, 2016 [Page 7] =0C Internet-Draft EBML June 2016 +------------+-------------+----------------+-----------------------+ | VINT_WIDTH | VINT_MARKER | VINT_DATA | Element Data Size | | | | | Status | +------------+-------------+----------------+-----------------------+ | | 1 | 1111111 | Reserved (meaning | | | | | Unknown) | | 0 | 1 | 00000001111111 | Valid (meaning 127 | | | | | octets) | +------------+-------------+----------------+-----------------------+ 1.8. EBML Element Types Each defined EBML Element MUST have a declared Element Type. The Element Type defines a concept for storing data that may be constrained by length, endianness, and purpose. Element Data Type: Signed Integer Endianness: Big-endian Length: A Signed Integer Element MUST declare a length that is = no greater than 8 octets. An Signed Integer Element with a zero-octet = length represents an integer value of zero. Definition: A Signed Integer stores an integer (meaning that it can = be written without a fractional component) which may be negative, = positive, or zero. Because EBML limits Signed Integers to 8 octets in = length a Signed Element may store a number from = -9,223,372,036,854,775,808 to +9,223,372,036,854,775,807. Element Data Type: Unsigned Integer Endianness: Big-endian Length: A Unsigned Integer Element MUST declare a length that is = no greater than 8 octets. An Unsigned Integer Element with a zero-octet = length represents an integer value of zero. Definition: An Unsigned Integer stores an integer (meaning that it = can be written without a fractional component) which may be positive or = zero. Because EBML limits Unsigned Integers to 8 octets in length an = unsigned Element may store a number from 0 to = 18,446,744,073,709,551,615. Element Data Type: Float Endianness: Big-endian Length: A Float Element MUST declare of length of either 0 = octets (0 bit), 4 octets (32 bit) or 8 octets (64 bit). A Float Element = with a zero-octet length represents a numerical value of zero. Definition: A Float Elements stores a floating-point number as = defined in IEEE 754. Element Data Type: String Endianness: None Length: A String Element may declare any length from zero to = `VINTMAX`. Definition: A String Element may either be empty (zero-length) or = contain Printable ASCII characters in the range of 0x20 to 0x7E. Octets = with all bits set to zero may follow the string value when needed. Element Data Type: UTF-8 Endianness: None Length: A UTF-8 Element may declare any length from zero to = `VINTMAX`. Definition: A UTF-8 Element shall contain only a valid Unicode = string as defined in [RFC 2279](http://www.faqs.org/rfcs/rfc2279.html). = Octets with all bits set to zero may follow the UTF-8 value when needed. Element Data Type: Date Lhomme Expires December 19, 2016 [Page 8] =0C Internet-Draft EBML June 2016 Endianness: None Length: A Date Element MUST declare a length of either 0 octets = or 8 octets. A Date Element with a zero-octet length represents a = timestamp of 2001-01-01T00:00:00.000000000 UTC. Definition: The Date Element MUST contain a Signed Integer that = expresses a point in time referenced in nanoseconds from the precise = beginning of the third millennium of the Gregorian Calendar in = Coordinated Universal Time (also known as 2001-01-01T00:00:00.000000000 = UTC). This provides a possible expression of time from = 1708-09-11T00:12:44.854775808 UTC to 2293-04-11T11:47:16.854775807 UTC. Element Data Type: Master-element Endianness: None Length: A Master-element may declare any length from zero to = `VINTMAX`. The Master-element may also use an unknown length. See the = section on Element Data Size for rules that apply to elements of unknown = length. Definition: The Master-element contains zero, one, or many other = elements. Elements contained within a Master-element must be defined for = use at levels greater than the level of the Master-element. For instance = is a Master-element occurs on level 2 then all contained Elements must = be valid at level 3. Element Data stored within Master-elements SHOULD = only consist of EBML Elements and SHOULD NOT contain any data that is = not part of an EBML Element. When EBML is used in transmission or = streaming, data that is not part of an EBML Element is permitted to be = present within a Master-element if `unknownsizeallowed` is enabled = within that Master-element's definition. In this case, the reader should = skip data until a valid Element ID of the same level or the next greater = level of the Master-element is found. What Element IDs are considered = valid within a Master-element is identified by the EBML Schema for that = version of the EBML Document Type. Any data contained with a = Master-element that is not part of an Element SHOULD be ignored. Element Data Type: Binary Endianness: None Length: A binary element may declare any length from zero to = `VINTMAX`. Definition: The contents of a Binary element should not be = interpreted by the EBML parser. 1.9. EBML Document An EBML Document is comprised of only two components, an EBML Header and an EBML Body. An EBML Document MUST start with an EBML Header which declares significant characteristics of the entire EBML Body. An EBML Document MAY only consist of EBML Elements and MUST NOT contain any data that is not part of an EBML Element. The initial EBML Element of an EBML Document and the Elements that follow it are considered Level 0 Elements. If an EBML Master-element is considered to be at level N and it contains one or many other EBML Elements then the contained Elements shall be considered at Level N+1. Thus a Level 2 Element would have to be contained by a Master-element (at Level 1) that is contained by another Master-element (at Level 0). 1.9.1. EBML Header The EBML Header is a declaration that provides processing instructions and identification of the EBML Body. The EBML Header may be considered as analogous to an XML Declaration. All EBML Documents MUST begin with a valid EBML Header. The EBML Header documents the EBML Schema (also known as the EBML DocType) that may be used to semantically interpret the structure and meaning of the EBML Document. Additionally the EBML Header documents the versions of both EBML and the EBML Schema that were used to write the EBML Document and the versions required to read the EBML Document. The EBML Header consists of a single Master-element with an Element ID of 'EBML'. The EBML Header MUST ONLY contain EBML Elements that are defined as part of the EBML Specification. Lhomme Expires December 19, 2016 [Page 9] =0C Internet-Draft EBML June 2016 All EBML Elements within the EBML Header MUST NOT utilize any Element ID with a length greater than 4 octets. All EBML Elements within the EBML Header MUST NOT utilize any Element Data Size with a length greater than 4 octets. 1.9.2. EBML Body All data of an EBML Document following the EBML Header may be considered the EBML Body. The end of the EBML Body, as well as the end of the EBML Document that contains the EBML Body, is considered as whichever comes first: the beginning of a new level 0 EBML Header or the end of the file. The EBML Body MAY only consist of EBML Elements and MUST NOT contain any data that is not part of an EBML Element. Although the EBML specification itself defines precisely what EBML Elements are to be used within the EBML Header, the EBML specification does not name or define what EBML Elements are to be used within the EBML Body. The definition of what EBML Elements are to be used within the EBML Body is defined by an EBML Schema. 1.10. EBML Stream An EBML Stream is a file that consists of one or many EBML Documents that are concatenated together. An occurrence of a Level 0 EBML Header marks the beginning of an EBML Document. 1.11. Elements semantic 1.11.1. EBML Schema An EBML Schema is an XML Document that defines the properties, arrangement, and usage of EBML Elements that compose a specific EBML Document Type. The relationship of an EBML Schema to an EBML Document may be considered analogous to the relationship of an XML Schema [2] to an XML Document [3]. An EBML Schema MUST be clearly associated with one or many EBML Document Types. An EBML Schema must be expressed as well-formed XML. An EBML Document Type is identified by a unique string stored within the EBML Header element called DocType; for example "matroska" or "webm". As an XML Document, the EBML Schema MUST use "" as the top level element. The "" element MAY contain "" sub-elements. Each "" defines one EBML Element through the use of several attributes which are defined in the section on Section 1.11.1.1. EBML Schemas MAY contain additional attributes to extend the semantics but MUST not conflict is the definitions of the "" attributes defined within this specification. Lhomme Expires December 19, 2016 [Page 10] =0C Internet-Draft EBML June 2016 Within the EBML Schema each EBML Element is defined to occur at a specific level. For any specificied EBML Element that is not at level 0, the Parent EBML Element refers to the EBML Master-element that that EBML Element is contained within. For any specifiied EBML Master-element the Child EBML Element refers to the EBML Elements that may be immediately contained within that Master-element. For any EBML Element that is not defined at level 0, the Parent EBML Element may be identified by the preceding "" node which has a lower value as the defined "level" attribute. The only exception for this rule are Global EBML Elements which may occur within any Parent EBML Element within the restriction of the Global EBML Element's range declaration. An EBML Schema MUST declare exactly one Element at Level 0 (referred to as the Root Element) that MUST occur exactly once within an EBML Document. The Root Element MUST be mandatory (with minOccurs set to 1) and MUST be defined to occur exactly once (maxOccurs set to 1). Note that the EBML and Void Elements may also occur at Level 0 but are not considered to be Root Elements. Elements defined to only occur at Level 1 are known as Top-Level Elements. The EBML Schema does not itself document the EBML Header, but documents all data of the EBML Document that follows the EBML Header. The EBML Header itself is documented by this specification in the Section 1.11.2 section. The EBML Schema also does not document Global Elements that are defined by the EBML Specification (namely Void and CRC-32). 1.11.1.1. EBML Schema Element Attributes Within an EBML Schema the "" uses the following attributes to define the EBML Schema: Lhomme Expires December 19, 2016 [Page 11] =0C Internet-Draft EBML June 2016 +-----------+----------+--------------------------------------------+ | attribute | required | definition | | name | | | +-----------+----------+--------------------------------------------+ | docType | Yes | The "docType" lists the official name of | | | | the EBML Document Type that is defined by | | | | the EBML Schema; for example, "". = | | version | Yes | The "version" lists an incremental non- | | | | negative integer that specifies the | | | | version of the docType documented by the | | | | EBML Schema. Unlike XML Schemas, an EBML | | | | Schema documents all versions of a | | | | docType's definition rather than using | | | | separate EBML Schemas for each version of | | | | a docType. Elements may be introduced and | | | | deprecated by using the "minver" and | | | | "maxver" attributes of . | +-----------+----------+--------------------------------------------+ Within an EBML Schema the "" uses the following attributes to define an EBML Element. +--------------------+----------+-----------------------------------+ | attribute name | required | definition | +--------------------+----------+-----------------------------------+ | name | Yes | The official human-readable name | | | | of the EBML Element. The value of | | | | the name MUST be in the form of | | | | an NCName as defined by the XML | | | | Schema specification [4]. | | level | Yes | The level notes at what | | | | hierarchical depth the EBML | | | | Element may occur within an EBML | | | | Document. The Root Element of an | | | | EBML Document is at level 0 and | | | | the Elements that it may contain | | | | are at level 1. The level MUST be | | | | expressed as an integer; however, | | | | the integer may be followed by a | | | | '+' symbol to indicate that the | | | | EBML Element is valid at any | | | | higher level. | | global | No | A boolean to express if an EBML | | | | Element MUST occur at its defined | | | | level or may occur within any | | | | Parent EBML Element. If the | | | | "global" attribute is not | Lhomme Expires December 19, 2016 [Page 12] =0C Internet-Draft EBML June 2016 | | | expressed for that Element then | | | | that element is to be considered | | | | not global. | | id | Yes | The Element ID expressed in | | | | hexadecimal notation prefixed by | | | | a '0x'. To reduce the risk of | | | | false positives while parsing | | | | EBML Streams, the IDs of the Root | | | | Element and Top-Level Elements | | | | SHOULD be at least 4 octets in | | | | length. Element IDs defined for | | | | use at Level 0 or Level 1 MAY use | | | | shorter octet lengths to | | | | facilitate padding and optimize | | | | edits to EBML Documents; for | | | | instance, the EBML Void Element | | | | uses an Element ID with a one | | | | octet length to allow its usage | | | | in more writing and editing | | | | scenarios. | | minOccurs | No | An integer to express the minimal | | | | number of occurrences that the | | | | EBML Element MUST occur within | | | | its Parent Element if its Parent | | | | Element is used. If the Element | | | | has no Parent Level (as is the | | | | case with Elements at Level 0), | | | | then minOccurs refers to | | | | constaints on the Element's | | | | occurrence within the EBML | | | | Document. If the minOccurs | | | | attribute is not expressed for | | | | that Element then that Element | | | | shall be considered to have a | | | | minOccurs value of 0. This value | | | | of minOccurs MUST be a positive | | | | integer. The semantic meaning of | | | | minOccurs within an EBML Schema | | | | is considered analogous to the | | | | meaning of minOccurs within an | | | | XML Schema [5]. Note that | | | | Elements with minOccurs set to | | | | "1" that also have a default | | | | value declared are not required | | | | to be stored but are required to | | | | be interpretted, see the Section | | | | 1.11.1.6. | | maxOccurs | No | A value to express the maximum | Lhomme Expires December 19, 2016 [Page 13] =0C Internet-Draft EBML June 2016 | | | number of occurrences that the | | | | EBML Element MAY occur within its | | | | Parent Element if its Parent | | | | Element is used. If the Element | | | | has no Parent Level (as is the | | | | case with Elements at Level 0), | | | | then maxOccurs refers to | | | | constaints on the Element's | | | | occurrence within the EBML | | | | Document. This value may be | | | | either a positive integer or the | | | | term "unbounded" to indicate | | | | there is no maximum number of | | | | occurrences or the term | | | | "identical" to indicate that the | | | | Element is an Section 1.11.1.3. | | | | If the maxOccurs attribute is not | | | | expressed for that Element then | | | | that Element shall be considered | | | | to have a maxOccurs value of 1. | | | | The semantic meaning of maxOccurs | | | | within an EBML Schema is | | | | considered analogous to the | | | | meaning of minOccurs within an | | | | XML Schema [6], with EBML Schema | | | | adding the concept of Identically | | | | Recurring Elements. | | range | No | For Elements which are of | | | | numerical types (Unsigned | | | | Integer, Signed Integer, Float, | | | | and Date) a numerical range may | | | | be specified. If specified that | | | | the value of the EBML Element | | | | MUST be within the defined range | | | | inclusively. See the Section | | | | 1.11.1.4 for rules applied to | | | | expression of range values. | | default | No | A default value may be provided. | | | | If an Element is mandatory but | | | | not written within its Parent | | | | EBML Element, then the parser of | | | | the EBML Document MUST insert the | | | | defined default value of the | | | | Element. EBML Elements that are | | | | Master-elements MUST NOT declare | | | | a default value. | | type | Yes | As defined within the Section | | | | 1.8, the type MUST be set to one | Lhomme Expires December 19, 2016 [Page 14] =0C Internet-Draft EBML June 2016 | | | of the following values: | | | | 'integer' (signed integer), | | | | 'uinteger' (unsigned integer), | | | | 'float', 'string', 'date', | | | | 'utf-8', 'master', or 'binary'. | | unknownsizeallowed | No | A boolean to express if an EBML | | | | Element MAY be used as an | | | | "Unknown-Sized Element" (having | | | | all VINT_DATA bits of Element | | | | Data Size set to 1). The | | | | "unknownsizeallowed" attribute | | | | only applies to Master-elements. | | | | If the "unknownsizeallowed" | | | | attribute is not used it is | | | | assumed that the element is not | | | | allowed to use an unknown Element | | | | Data Size. | | minver | No | The "minver" (minimum version) | | | | attribute stores a non-negative | | | | integer that represents the first | | | | version of the docType to support | | | | the element. If the "minver" | | | | attribute is not used it is | | | | assumed that the element has a | | | | minimum version of "1". | | maxver | No | The "maxver" (maximum version) | | | | attribute stores a non-negative | | | | integer that represents the last | | | | or most recent version of the | | | | docType to support the element. | | | | If the "maxver" attribute is not | | | | used it is assumed that the | | | | element has a maximum version | | | | equal to the value stored in the | | | | "version" attribute of . | +--------------------+----------+-----------------------------------+ The "" nodes shall contain a description of the meaning and use of the EBML Element stored within one or many "" sub-elements. The "" sub-element may use a "lang" attribute which may be set to the RFC 5646 value of the language of the element's documentation. The "" nodes MUST be arranged hierarchically according to the permitted structure of the EBML Document Type. An "" node that defines an EBML Element which is a Child Element of another Parent Element MUST be stored as an immediate sub-element of the "" node that defines the Parent Element. "" nodes Lhomme Expires December 19, 2016 [Page 15] =0C Internet-Draft EBML June 2016 that define Level 0 Elements and Global Elements should be sub- elements of "". 1.11.1.2. EBML Schema Example Container of data and attributes = representing one or many files. An attached file. Filename of the attached = file. MIME type of the = file. Modification timestamp of the = file. The data of the file. 1.11.1.3. Identically Recurring Elements An Identically Recurring Element is an Element that may occur within its Parent Element more than once but that each recurrence within that Parent Element MUST be identical both in storage and semantics. Identically Recurring Elements are permitted to be stored multiple times within the same Parent Element in order to increase data resilience and optimize the use of EBML in transmission. Identically Recurring Elements SHOULD include a CRC-32 Element as a Child Element; this is especially recommended when EBML is used for long- term storage or transmission. If a Parent Element contains more than one copy of an Identically Recurring Element which includes a CRC-32 Child Element then the first instance of the Identically Recurring Element with a valid CRC-32 value should be used for interpretation. If a Parent Element contains more than one copy of an Identically Recurring Element which does not contain a CRC-32 Child Element or if CRC-32 Child Elements are present but none are valid then the first instance of the Identically Recurring Element should be used for interpretation. Lhomme Expires December 19, 2016 [Page 16] =0C Internet-Draft EBML June 2016 1.11.1.4. Expression of range The "range" attribute MUST only be used with EBML Elements that are either "signed integer", "unsigned integer", or "float". The "range" attribute does not support date EBML Elements. The "range" expression may contain whitespace for readability but whitespace within a "range" expression MUST NOT convey meaning. The expression of the "range" MUST adhere to one of the following forms: - `x-y` where x and y are integers or floats and `y` must be greater = than `x`, meaning that the value must be greater than or equal to `x` = and less than or equal to `y`. - `>x` where `x` is an integer or float, meaning that the value MUST be = greater than `x`. - `x` where `x` is an integer or float, meaning that the value MUST be = equal `x`. The "range" may use the prefix "not" to indicate that the expressed range is negated. Please also see the section on Section 1.11.1.5. 1.11.1.5. Textual expression of Floats When a float value is represented textually in an EBML Schema, such as within a "default" or "range" value, the float values MUST be expressed as a Hexadecimal Floating-Point Constants as defined in the C11 standard ISO/IEC 9899:2011 [7] (see section 6.4.4.2 on Floating Constants). The following table provides examples of expressions of float ranges. | as decimal | as Hexadecimal Floating-Point Constants | |----------- --------|-----------------------------------------| | 0.0-1.0 | 0x0p+1-0x1p+0 | | 1.0-256.0 | 0x1p+0-0x1p+8 | | 0.857421875 | 0x1.b7p-1 | | -1.0--0.857421875 | -0x1p+0--0x1.b7p-1 | Within an expression of a float range, as in an integer range, the "-" (hyphen) character is the separator between the minimal and maximum value permitted by the range. Note that Hexadecimal Floating-Point Constants also use a "-" (hyphen) when indicating a negative binary power. Within a float range, when a "-" (hyphen) is immediately preceded by a letter "p", then the "-" (hyphen) is a part of the Hexadecimal Floating-Point Constant which notes negative binary power. Within a float range, when a "-" (hyphen) is not immediately preceded by a letter "p", then the "-" (hyphen) represents the separator between the minimal and maximum value permitted by the range. 1.11.1.6. Note on the Use of default attributes to define Mandatory EBML Elements If a Mandatory EBML Element has a default value declared by an EBML Schema and the EBML Element's value is equal to the declared default value then that Element is not required to be present within the EBML Lhomme Expires December 19, 2016 [Page 17] =0C Internet-Draft EBML June 2016 Document if its Parent EBML Element is present. In this case, the default value of the Mandatory EBML Element may be assumed although the EBML Element is not present within its Parent EBML Element. Also in this case the parser of the EBML Document MUST insert the defined default value of the Element. If a Mandatory EBML Element has no default value declared by an EBML Schema and its Parent EBML Element is present than the EBML Element must be present as well. If a Mandatory EBML Element has a default value declared by an EBML Schema and its Parent EBML Element is present and the EBML Element's value is NOT equal to the declared default value then the EBML Element MUST be used. This table clarifies if a Mandatory EBML Element MUST be written, according to if the default value is declared, if the value of the EBML Element is equal to the declared default value, and if the Parent EBML Element is used. +---------------+----------------+--------------+-------------------+ | Is the | Is the value | Is the | Then is storing | | default value | equal to | Parent | the EBML Element | | declared? | default? | Element | required? | | | | used? | | +---------------+----------------+--------------+-------------------+ | Yes | Yes | Yes | No | | Yes | Yes | No | No | | Yes | No | Yes | Yes | | Yes | No | No | No | | No | n/a | Yes | Yes | | No | n/a | No | No | | No | n/a | Yes | Yes | | No | n/a | No | No | +---------------+----------------+--------------+-------------------+ 1.11.1.7. Note on the Use of default attributes to define non-Mandatory EBML Elements If an EBML Element is not Mandatory, has a defined default value, and is an Empty EBML Element then the EBML Element MUST be interpreted as expressing the default value. 1.11.2. EBML Header Elements This specification here contains definitions of all EBML Elements of the EBML Header. Element Name: EBML Lhomme Expires December 19, 2016 [Page 18] =0C Internet-Draft EBML June 2016 Level: 0 EBML ID: [1A][45][DF][A3] Mandatory: Yes Multiple: No Range: - Default: - Element Type: Master-element Description: Set the EBML characteristics of the data to follow. Each = EBML Document has to start with this. Element Name: EBMLVersion Level: 1 EBML ID: [42][86] Mandatory: Yes Multiple: No Range: 1 Default: 1 Element Type: Unsigned Integer Description: The version of EBML parser used to create the EBML = Document. Element Name: EBMLReadVersion Level: 1 EBML ID: [42][F7] Mandatory: Yes Multiple: No Range: 1 Default: 1 Element Type: Unsigned Integer Description: The minimum EBML version a parser has to support to read = this EBML Document. Element Name: EBMLMaxIDLength Level: 1 EBML ID: [42][F2] Mandatory: Yes Multiple: No Range: >3 Default: 4 Element Type: Unsigned Integer Description: The EBMLMaxIDLength is the maximum length in octets of = the Element IDs to be found within the EBML Body. An EBMLMaxIDLength = value of four is recommended, though larger values are allowed. Element Name: EBMLMaxSizeLength Lhomme Expires December 19, 2016 [Page 19] =0C Internet-Draft EBML June 2016 Level: 1 EBML ID: [42][F3] Mandatory: Yes Multiple: No Range: >0 Default: 8 Element Type: Unsigned Integer Description: The EBMLMaxSizeLength is the maximum length in octets of = the expression of all Element Data Sizes to be found within the EBML = Body. To be clear EBMLMaxSizeLength documents the maximum 'length' of = all Element Data Size expressions within the EBML Body and not the = maximum 'value' of all Element Data Size expressions within the EBML = Body. Elements that have a Element Data Size expression which is larger = in octets than what is expressed by EBMLMaxSizeLength SHALL be = considered invalid. Element Name: DocType Level: 1 EBML ID: [42][82] Mandatory: Yes Multiple: No Range: - Default: matroska Element Type: String Description: A string that describes and identifies the content of = the EBML Body that follows this EBML Header. Element Name: DocTypeVersion Level: 1 EBML ID: [42][87] Mandatory: Yes Multiple: No Range: - Default: 1 Element Type: Unsigned Integer Description: The version of DocType interpreter used to create the = EBML Document. Element Name: DocTypeReadVersion Level: 1 EBML ID: [42][85] Mandatory: Yes Multiple: No Range: - Default: 1 Element Type: Unsigned Integer Description: The minimum DocType version an interpreter has to = support to read this EBML Document. 1.11.3. Global elements (used everywhere in the format) Element Name: CRC-32 Lhomme Expires December 19, 2016 [Page 20] =0C Internet-Draft EBML June 2016 Level: 1+ Global: Yes EBML ID: [BF] Mandatory: No Multiple: No Range: - Default: - Element Type: Binary Description: The CRC-32 Element contains a 32 bit Cyclic Redundancy = Check value of all the Element Data of the Parent Element as stored = except for the CRC-32 Element itself. When the CRC-32 Element is = present, the CRC-32 Element MUST be the first ordered Element within its = Parent Element for easier reading. All Top-Level Elements of an EBML = Document SHOULD include a CRC-32 Element as a Child Element. The CRC in = use is the IEEE-CRC-32 algorithm as used in the ISO 3309 standard and in = section 8.1.1.6.2 of ITU-T recommendation V.42, with initial value of = 0xFFFFFFFF. The CRC value MUST be computed on a little endian bitstream = and MUST use little endian storage. Element Name: Void Level: 0+ Global: Yes EBML ID: [EC] Mandatory: No Multiple: Yes Range: - Default: - Element Type: Binary Description: Used to void damaged data, to avoid unexpected behaviors = when using damaged data. The content is discarded. Also used to reserve = space in a sub-element for later use. 2. References 2.1. URIs [1] https://tools.ietf.org/html/rfc2119 [2] http://www.w3.org/XML/Schema#dev [3] http://www.w3.org/TR/xml/ [4] http://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-decl [5] https://www.w3.org/TR/xmlschema-0/#ref6 [6] https://www.w3.org/TR/xmlschema-0/#ref6 [7] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf Author's Address Steve Lhomme Lhomme Expires December 19, 2016 [Page 21] --Apple-Mail=_3D35EB3B-CCAE-45D1-BBEC-D0B319198DAA Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Best Regards, Dave Rice --Apple-Mail=_3D35EB3B-CCAE-45D1-BBEC-D0B319198DAA-- From nobody Fri Jun 17 08:21:28 2016 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 7AF0812D754 for ; Fri, 17 Jun 2016 08:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.336 X-Spam-Level: X-Spam-Status: No, score=-4.336 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 zot078zl3c-1 for ; Fri, 17 Jun 2016 08:21:19 -0700 (PDT) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 9D01412D751 for ; Fri, 17 Jun 2016 08:21:19 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 69998C49EC for ; Fri, 17 Jun 2016 15:21:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-Ufu1YaVgsy for ; Fri, 17 Jun 2016 15:21:19 +0000 (UTC) Received: from [172.26.0.233] (unknown [194.73.252.249]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id CD2FDC1BB1 for ; Fri, 17 Jun 2016 15:21:18 +0000 (UTC) Message-ID: <5764156D.40100@xiph.org> Date: Fri, 17 Jun 2016 08:21:17 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: <5CBBD1F2-E4D4-4453-B74E-BC854B3F673D@dericed.com> <57638C5E.90506@xiph.org> <286C62FD-3073-487F-AD1A-A81CC2C3D6D6@dericed.com> In-Reply-To: <286C62FD-3073-487F-AD1A-A81CC2C3D6D6@dericed.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] An attempt at EBML specification in RFC form X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jun 2016 15:21:20 -0000 Dave Rice wrote: > Steve, Moritz, other, specific suggestions for EBML authorship? Leave as Steve alone, add other working group members? Given the way you've been acting in capacity as editor thus far, I'd suggest you might want to consider adding yourself. From nobody Sat Jun 18 00:14:47 2016 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 1B50C12D0BB for ; Sat, 18 Jun 2016 00:14:47 -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 Vi6ztWOmzYuz for ; Sat, 18 Jun 2016 00:14:45 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2235612B004 for ; Sat, 18 Jun 2016 00:14:44 -0700 (PDT) Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 7110041C084 for ; Sat, 18 Jun 2016 09:14:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter36-d.gandi.net (mfilter36-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 0q_RsLXfIvJt for ; Sat, 18 Jun 2016 09:14:42 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id D239E41C074 for ; Sat, 18 Jun 2016 09:14:40 +0200 (CEST) Date: Sat, 18 Jun 2016 09:14:20 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160618071420.GP4636@nb4> References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> <20160608153508.GW4636@nb4> <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> <20160611201955.GZ4636@nb4> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1MXu+reqKPHC6GN9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] [PATCH FFV1 2/2] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 18 Jun 2016 07:14:47 -0000 --1MXu+reqKPHC6GN9 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 13, 2016 at 09:18:38PM +0200, Jerome Martinez wrote: > Le 11/06/2016 =E0 22:19, Michael Niedermayer a =E9crit : > >On Thu, Jun 09, 2016 at 11:29:25PM +0200, Jerome Martinez wrote: > > > >[...] > > > >>+**plane\_pixel\_height[ p ]** is the height in pixels of plane p of th= e slice. > >>+plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_plan= es ? 2 : 0 ) ] value is slice\_pixel\_height > >>+if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pi= xel\_height[ 2 ] value is ⌈slice\_pixel\_height / v\_chroma\_subsampl= e⌉ > >the plane\_pixel\_*[0] should be changed to be rounded toward chroma > >raster size in the next bitstream version > >this would simplify slice geometry i think > > >=20 > I add this item to my list of items to debate after the > standardization of FFV1 0/1/3. >=20 > Attached is the patch corresponding to changes only. > ffv1.md | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > c2176452cd73caa1b268391913deab1b38d34aa1 0002-SliceContent-description-u= pdate.patch > >From 1791299ecd9df5b623416b58398c4c3fe63d06d3 Mon Sep 17 00:00:00 2001 > From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D > Date: Mon, 13 Jun 2016 21:11:39 +0200 > Subject: [PATCH 2/2] SliceContent description update >=20 > Describe how to call Line() when color_space is 0 > Define slice_pixel_height and slice_pixel_y > Define plane_pixel_height[ p ] > --- > ffv1.md | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) >=20 > diff --git a/ffv1.md b/ffv1.md > index 49019c2..dfdb7e7 100644 > --- a/ffv1.md > +++ b/ffv1.md > @@ -631,9 +631,10 @@ Inferred to be 0 if not present. > |SliceContent( ) { | type | > |=A0=A0=A0=A0if( colorspace\_type =3D=3D 0) { = | | > |=A0=A0=A0=A0=A0=A0=A0=A0for( p =3D 0; p \< primary\_color\_count; p++ )= { | | > -|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Plane( p ) = | | > +|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0for( y =3D 0; y \< plane\_pixel\_he= ight[ p ]; y++ ) | | > +|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Line( p, y ) = | | > |=A0=A0=A0=A0} else if( colorspace\_type =3D=3D 1 ) { = | | > -|=A0=A0=A0=A0=A0=A0=A0=A0for( y =3D 0; y \< height; y++ ) = | | > +|=A0=A0=A0=A0=A0=A0=A0=A0for( y =3D 0; y \< slice\_pixel\_height; y++ ) = | | > |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0for( p =3D 0; p \< primary\_color\_= count; p++ ) { | | > |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Line( p, y ) = | | > |=A0=A0=A0=A0} |= | > @@ -641,6 +642,16 @@ Inferred to be 0 if not present. > =20 > **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + = ( alpha_plane ? 1 : 0 ). > =20 > +**plane\_pixel\_height[ p ]** is the height in pixels of plane p of the = slice. =20 > +plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_planes= ? 2 : 0 ) ] value is slice\_pixel\_height =20 > +if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixe= l\_height[ 2 ] value is ⌈slice\_pixel\_height / v\_chroma\_subsample&= rceil; > + > +**slice\_pixel\_height** is the height in pixels of the slice. =20 > +Its value is ⌊( plane\_y + plane\_height ) * frame_pixel\_height = / num\_v\_slices⌋ - slice\_pixel\_y =20 what is plane_y or plane_height ? [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA --1MXu+reqKPHC6GN9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldk9MwACgkQYR7HhwQLD6uTQQCeL9jnQTQ/cxQ+mWtTxA5oywOi VLoAmwYuskRIbqLANPQfxQeq+tRCRaJT =OC7q -----END PGP SIGNATURE----- --1MXu+reqKPHC6GN9-- From nobody Sat Jun 18 00:25:58 2016 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 444D312B057 for ; Sat, 18 Jun 2016 00:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 67JyO6kZsf1P for ; Sat, 18 Jun 2016 00:25:56 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED39612B004 for ; Sat, 18 Jun 2016 00:25:55 -0700 (PDT) Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id C6C9341C090 for ; Sat, 18 Jun 2016 09:25:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id MUaaKQlxYisL for ; Sat, 18 Jun 2016 09:25:53 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 1799041C07D for ; Sat, 18 Jun 2016 09:25:52 +0200 (CEST) Date: Sat, 18 Jun 2016 09:25:32 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160618072532.GQ4636@nb4> References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> <20160608153508.GW4636@nb4> <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> <20160611201955.GZ4636@nb4> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XFkHhpX+zY/pUGhI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] [PATCH FFV1 2/2] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 18 Jun 2016 07:25:57 -0000 --XFkHhpX+zY/pUGhI Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 13, 2016 at 09:18:38PM +0200, Jerome Martinez wrote: > Le 11/06/2016 =E0 22:19, Michael Niedermayer a =E9crit : > >On Thu, Jun 09, 2016 at 11:29:25PM +0200, Jerome Martinez wrote: > > > >[...] > > > >>+**plane\_pixel\_height[ p ]** is the height in pixels of plane p of th= e slice. > >>+plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_plan= es ? 2 : 0 ) ] value is slice\_pixel\_height > >>+if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pi= xel\_height[ 2 ] value is ⌈slice\_pixel\_height / v\_chroma\_subsampl= e⌉ > >the plane\_pixel\_*[0] should be changed to be rounded toward chroma > >raster size in the next bitstream version > >this would simplify slice geometry i think > > >=20 > I add this item to my list of items to debate after the > standardization of FFV1 0/1/3. >=20 > Attached is the patch corresponding to changes only. > ffv1.md | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > c2176452cd73caa1b268391913deab1b38d34aa1 0002-SliceContent-description-u= pdate.patch > >From 1791299ecd9df5b623416b58398c4c3fe63d06d3 Mon Sep 17 00:00:00 2001 > From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D > Date: Mon, 13 Jun 2016 21:11:39 +0200 > Subject: [PATCH 2/2] SliceContent description update >=20 > Describe how to call Line() when color_space is 0 > Define slice_pixel_height and slice_pixel_y > Define plane_pixel_height[ p ] > --- > ffv1.md | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) >=20 > diff --git a/ffv1.md b/ffv1.md > index 49019c2..dfdb7e7 100644 > --- a/ffv1.md > +++ b/ffv1.md > @@ -631,9 +631,10 @@ Inferred to be 0 if not present. > |SliceContent( ) { | type | > |=A0=A0=A0=A0if( colorspace\_type =3D=3D 0) { = | | > |=A0=A0=A0=A0=A0=A0=A0=A0for( p =3D 0; p \< primary\_color\_count; p++ )= { | | > -|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Plane( p ) = | | > +|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0for( y =3D 0; y \< plane\_pixel\_he= ight[ p ]; y++ ) | | > +|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Line( p, y ) = | | > |=A0=A0=A0=A0} else if( colorspace\_type =3D=3D 1 ) { = | | > -|=A0=A0=A0=A0=A0=A0=A0=A0for( y =3D 0; y \< height; y++ ) = | | > +|=A0=A0=A0=A0=A0=A0=A0=A0for( y =3D 0; y \< slice\_pixel\_height; y++ ) = | | > |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0for( p =3D 0; p \< primary\_color\_= count; p++ ) { | | > |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Line( p, y ) = | | > |=A0=A0=A0=A0} |= | > @@ -641,6 +642,16 @@ Inferred to be 0 if not present. > =20 > **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + = ( alpha_plane ? 1 : 0 ). > =20 > +**plane\_pixel\_height[ p ]** is the height in pixels of plane p of the = slice. =20 > +plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_planes= ? 2 : 0 ) ] value is slice\_pixel\_height =20 > +if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixe= l\_height[ 2 ] value is ⌈slice\_pixel\_height / v\_chroma\_subsample&= rceil; > + > +**slice\_pixel\_height** is the height in pixels of the slice. =20 > +Its value is ⌊( plane\_y + plane\_height ) * frame_pixel\_height = / num\_v\_slices⌋ - slice\_pixel\_y =20 > + > +**slice\_pixel\_y** is the slice vertical position in pixels. =20 > +Its value is ⌊slice_y * frame_pixel\_height / num\_v\_slices&rflo= or; > + also these are just the y coordinates, the x ones are missing [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad --XFkHhpX+zY/pUGhI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldk92wACgkQYR7HhwQLD6sRIgCdFQj8P6lF6x6RvoBMzAeUxmkz dRoAnRzFruGlOcgjd2DdGTG6UaEvhyrn =Mxd5 -----END PGP SIGNATURE----- --XFkHhpX+zY/pUGhI-- From nobody Sat Jun 18 04:00:12 2016 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 DC84212B027 for ; Sat, 18 Jun 2016 04:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 DrwCon-fTqQj for ; Sat, 18 Jun 2016 04:00:08 -0700 (PDT) Received: from 8.mo4.mail-out.ovh.net (8.mo4.mail-out.ovh.net [188.165.33.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F0B128B44 for ; Sat, 18 Jun 2016 04:00:07 -0700 (PDT) Received: from player687.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id 2050010041BB for ; Sat, 18 Jun 2016 13:00:06 +0200 (CEST) Received: from [192.168.2.101] (p508BAB7D.dip0.t-ipconnect.de [80.139.171.125]) (Authenticated sender: jerome@francoallemand.eu) by player687.ha.ovh.net (Postfix) with ESMTPSA id DA62E2C0072 for ; Sat, 18 Jun 2016 13:00:05 +0200 (CEST) To: cellar@ietf.org References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> <20160608153508.GW4636@nb4> <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> <20160611201955.GZ4636@nb4> <20160618071420.GP4636@nb4> From: Jerome Martinez Message-ID: Date: Sat, 18 Jun 2016 12:59:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160618071420.GP4636@nb4> Content-Type: multipart/mixed; boundary="------------50D512A281C74BF90ACC7379" X-Ovh-Tracer-Id: 3005308328459833489 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrledvgdefgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] [PATCH FFV1 2/2] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 18 Jun 2016 11:00:11 -0000 This is a multi-part message in MIME format. --------------50D512A281C74BF90ACC7379 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 18/06/2016 09:14, Michael Niedermayer a crit : > On Mon, Jun 13, 2016 at 09:18:38PM +0200, Jerome Martinez wrote: > >> +**plane\_pixel\_height[ p ]** is the height in pixels of plane p of the slice. >> +plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_planes ? 2 : 0 ) ] value is slice\_pixel\_height >> +if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixel\_height[ 2 ] value is ⌈slice\_pixel\_height / v\_chroma\_subsample⌉ >> + >> +**slice\_pixel\_height** is the height in pixels of the slice. >> +Its value is ⌊( plane\_y + plane\_height ) * frame_pixel\_height / num\_v\_slices⌋ - slice\_pixel\_y > what is plane_y or plane_height ? sorry, typos during some changes I have made between my initial thoughts and the final patch. They are slice_y and slice_height, which are defined (in the slice header). Updated patch attached. Le 18/06/2016 09:25, Michael Niedermayer a crit : > also these are just the y coordinates, the x ones are missing x coordinates will be defined the same way after the y coordinates are accepted (in order to not do the same mistakes as with x coordinates) and when we need them (y coordinates are not used in SliceContent() so not defined in this location, they are used in Line() which will be defined in the next patch). --------------50D512A281C74BF90ACC7379 Content-Type: text/plain; charset=UTF-8; name="0002-SliceContent-description-update.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="0002-SliceContent-description-update.patch" >From 8520d64d8982e256285e04dc1dccb6ce6c5bd182 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= Date: Sat, 18 Jun 2016 12:11:13 +0200 Subject: [PATCH 2/2] SliceContent description update Describe how to call Line() when color_space is 0 Define slice_pixel_height and slice_pixel_y Define plane_pixel_height[ p ] --- ffv1.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/ffv1.md b/ffv1.md index a02744b..395fecc 100644 --- a/ffv1.md +++ b/ffv1.md @@ -631,9 +631,10 @@ Inferred to be 0 if not present. |SliceContent( ) { | type | |    if( colorspace\_type == 0) { | | |        for( p = 0; p \< primary\_color\_count; p++ ) { | | -|            Plane( p ) | | +|            for( y = 0; y \< plane\_pixel\_height[ p ]; y++ ) | | +|                Line( p, y ) | | |    } else if( colorspace\_type == 1 ) { | | -|        for( y = 0; y \< height; y++ ) | | +|        for( y = 0; y \< slice\_pixel\_height; y++ ) | | |            for( p = 0; p \< primary\_color\_count; p++ ) { | | |                Line( p, y ) | | |    } | | @@ -641,6 +642,16 @@ Inferred to be 0 if not present. **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + ( alpha_plane ? 1 : 0 ). +**plane\_pixel\_height[ p ]** is the height in pixels of plane p of the slice. +plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_planes ? 2 : 0 ) ] value is slice\_pixel\_height +if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixel\_height[ 2 ] value is ⌈slice\_pixel\_height / v\_chroma\_subsample⌉ + +**slice\_pixel\_height** is the height in pixels of the slice. +Its value is ⌊( slice\_y + slice\_height ) * slice\_pixel\_height / num\_v\_slices⌋ - slice\_pixel\_y + +**slice\_pixel\_y** is the slice vertical position in pixels. +Its value is ⌊slice_y * frame\_pixel\_height / num\_v\_slices⌋ + ## Slice Footer Note: slice footer is always byte aligned. -- 2.7.0.windows.1 --------------50D512A281C74BF90ACC7379-- From nobody Sat Jun 18 04:13:14 2016 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 16DFE12D096 for ; Sat, 18 Jun 2016 04:13:13 -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 dutNB-GwtdNO for ; Sat, 18 Jun 2016 04:13:11 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D0A12B05C for ; Sat, 18 Jun 2016 04:13:11 -0700 (PDT) Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id CC14841C080 for ; Sat, 18 Jun 2016 13:13:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter37-d.gandi.net (mfilter37-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 3JJirlGq1dl7 for ; Sat, 18 Jun 2016 13:13:08 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 2A61A41C07F for ; Sat, 18 Jun 2016 13:13:07 +0200 (CEST) Date: Sat, 18 Jun 2016 13:12:47 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160618111247.GR4636@nb4> References: <4ace1080-b931-d21c-7178-52167d80a1c0@mediaarea.net> <20160608141718.GV4636@nb4> <990317fe-5ec1-53f5-3c95-5182f1d7f8e7@mediaarea.net> <20160608153508.GW4636@nb4> <02aa9fbf-e545-eef5-1b62-5339c988ed84@mediaarea.net> <20160611201955.GZ4636@nb4> <20160618071420.GP4636@nb4> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cUlGATvL9lcudEbI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] [PATCH FFV1 2/2] SliceContent description update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 18 Jun 2016 11:13:13 -0000 --cUlGATvL9lcudEbI Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 18, 2016 at 12:59:53PM +0200, Jerome Martinez wrote: > Le 18/06/2016 =E0 09:14, Michael Niedermayer a =E9crit : > >On Mon, Jun 13, 2016 at 09:18:38PM +0200, Jerome Martinez wrote: > > > >>+**plane\_pixel\_height[ p ]** is the height in pixels of plane p of th= e slice. > >>+plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_plan= es ? 2 : 0 ) ] value is slice\_pixel\_height > >>+if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pi= xel\_height[ 2 ] value is ⌈slice\_pixel\_height / v\_chroma\_subsampl= e⌉ > >>+ > >>+**slice\_pixel\_height** is the height in pixels of the slice. > >>+Its value is ⌊( plane\_y + plane\_height ) * frame_pixel\_heigh= t / num\_v\_slices⌋ - slice\_pixel\_y > >what is plane_y or plane_height ? >=20 > sorry, typos during some changes I have made between my initial > thoughts and the final patch. > They are slice_y and slice_height, which are defined (in the slice header= ). > Updated patch attached. >=20 >=20 > Le 18/06/2016 =E0 09:25, Michael Niedermayer a =E9crit : > >also these are just the y coordinates, the x ones are missing >=20 > x coordinates will be defined the same way after the y coordinates > are accepted (in order to not do the same mistakes as with x > coordinates) and when we need them (y coordinates are not used in > SliceContent() so not defined in this location, they are used in > Line() which will be defined in the next patch). > ffv1.md | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > c4214698f7c22886680a46ad8ae1a621feffcd5c 0002-SliceContent-description-u= pdate.patch > >From 8520d64d8982e256285e04dc1dccb6ce6c5bd182 Mon Sep 17 00:00:00 2001 > From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D > Date: Sat, 18 Jun 2016 12:11:13 +0200 > Subject: [PATCH 2/2] SliceContent description update >=20 > Describe how to call Line() when color_space is 0 > Define slice_pixel_height and slice_pixel_y > Define plane_pixel_height[ p ] > --- > ffv1.md | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) applied btw, maybe the trailing whitespace of the file should be removed and not be re-added thanks [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable --cUlGATvL9lcudEbI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldlLK8ACgkQYR7HhwQLD6snrwCggcOKrpotgZv7R/G4fsFUtldR 8IQAniKd1oOZSbfNOpYUgMuZfDl5gPRV =Yv4g -----END PGP SIGNATURE----- --cUlGATvL9lcudEbI-- From nobody Sat Jun 18 07:17:58 2016 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 9305C12D505 for ; Sat, 18 Jun 2016 07:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 IRsEFCtNKBYz for ; Sat, 18 Jun 2016 07:17:54 -0700 (PDT) Received: from 5.mo4.mail-out.ovh.net (5.mo4.mail-out.ovh.net [188.165.44.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4020512D0E2 for ; Sat, 18 Jun 2016 07:17:53 -0700 (PDT) Received: from player687.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id 5FABBFFCCF9 for ; Sat, 18 Jun 2016 16:17:52 +0200 (CEST) Received: from [192.168.2.101] (p508BAB7D.dip0.t-ipconnect.de [80.139.171.125]) (Authenticated sender: jerome@francoallemand.eu) by player687.ha.ovh.net (Postfix) with ESMTPSA id 21CB42C0072 for ; Sat, 18 Jun 2016 16:17:51 +0200 (CEST) To: cellar@ietf.org From: Jerome Martinez Message-ID: <689e1ea5-1828-3d6d-7db3-ff7ad58d3c11@mediaarea.net> Date: Sat, 18 Jun 2016 16:17:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------6C81031523CD43A0C5C8ABDE" X-Ovh-Tracer-Id: 6345571875213217937 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrledvgdejhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: [Cellar] [PATCH] Add definition of Line() X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 18 Jun 2016 14:17:56 -0000 This is a multi-part message in MIME format. --------------6C81031523CD43A0C5C8ABDE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit the algorithm is similar for both colorspaces, but I preferred to separate them in order to have coherency with the descriptions in SliceContent(). --------------6C81031523CD43A0C5C8ABDE Content-Type: text/plain; charset=UTF-8; name="0001-Add-definition-of-Line.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-Add-definition-of-Line.patch" RnJvbSA5MzEzMjE3ODdkZDM2OTliYzY3MWNiMGRlZTYwMTZkODEyNjYxMmNkIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBTYXQsIDE4IEp1biAyMDE2 IDE2OjE3OjA1ICswMjAwClN1YmplY3Q6IFtQQVRDSF0gQWRkIGRlZmluaXRpb24gb2YgTGlu ZSgpCgpBbHNvIGRlZmluZSBzbGljZV9waXhlbF93aWR0aCwgc2xpY2VfcGl4ZWxfeAphbmQg cGxhbmVfcGl4ZWxfd2lkdGhbIHAgXQotLS0KIGZmdjEubWQgfCAyNCArKysrKysrKysrKysr KysrKysrKysrKysKIDEgZmlsZSBjaGFuZ2VkLCAyNCBpbnNlcnRpb25zKCspCgpkaWZmIC0t Z2l0IGEvZmZ2MS5tZCBiL2ZmdjEubWQKaW5kZXggMzk1ZmVjYy4uY2I3OWFiMyAxMDA2NDQK LS0tIGEvZmZ2MS5tZAorKysgYi9mZnYxLm1kCkBAIC02NTIsNiArNjUyLDMwIEBAIEl0cyB2 YWx1ZSBpcyAmbGZsb29yOyggc2xpY2VcX3kgKyBzbGljZVxfaGVpZ2h0ICkgKiBzbGljZVxf cGl4ZWxcX2hlaWdodCAvIG51bVxfCiAqKnNsaWNlXF9waXhlbFxfeSoqIGlzIHRoZSBzbGlj ZSB2ZXJ0aWNhbCBwb3NpdGlvbiBpbiBwaXhlbHMuICAKIEl0cyB2YWx1ZSBpcyAmbGZsb29y O3NsaWNlX3kgKiBmcmFtZVxfcGl4ZWxcX2hlaWdodCAvIG51bVxfdlxfc2xpY2VzJnJmbG9v cjsKIAorIyMgTGluZQorCit8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKK3wtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXw6LS0tLS0t fAorfExpbmUoIHAsIHkgKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCB0eXBlICB8Cit8wqDCoMKgwqBpZiggY29sb3JzcGFjZVxfdHlwZSA9 PSAwKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8Cit8wqDCoMKg wqDCoMKgwqDCoGZvciggeCA9IDA7IHggXDwgcGxhbmVcX3BpeGVsXF93aWR0aFsgcCBdOyB4 KysgKSAgICAgIHwgICAgICAgfAorfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoFBpeGVsKCBw LCB5LCB4ICkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8Cit8 wqDCoMKgwqB9IGVsc2UgaWYoIGNvbG9yc3BhY2VcX3R5cGUgPT0gMSApIHsgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICB8Cit8wqDCoMKgwqDCoMKgwqDCoGZvciggeCA9IDA7IHgg XDwgc2xpY2VcX3BpeGVsXF93aWR0aDsgeCsrICkgICAgICAgICAgIHwgICAgICAgfAorfMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoFBpeGVsKCBwLCB5LCB4ICkgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICB8Cit8wqDCoMKgwqB9ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8Cit8 fSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgIHwKKworKipwbGFuZVxfcGl4ZWxcX3dpZHRoWyBwIF0qKiBpcyB0 aGUgd2lkdGggaW4gcGl4ZWxzIG9mIHBsYW5lIHAgb2YgdGhlIHNsaWNlLiAgCitwbGFuZVxf cGl4ZWxcX3dpZHRoWyAwIF0gYW5kIHBsYW5lXF9waXhlbFxfd2lkdGhbIDEgKyAoIGNocm9t YVxfcGxhbmVzID8gMiA6IDAgKSBdIHZhbHVlIGlzIHNsaWNlXF9waXhlbFxfd2lkdGggIAor aWYgY2hyb21hXF9wbGFuZXMgaXMgc2V0IHRvIDEsIHBsYW5lXF9waXhlbFxfd2lkdGhbIDEg XSBhbmQgcGxhbmVcX3BpeGVsXF93aWR0aFsgMiBdIHZhbHVlIGlzICZsY2VpbDtzbGljZVxf cGl4ZWxcX3dpZHRoIC8gdlxfY2hyb21hXF9zdWJzYW1wbGUmcmNlaWw7CisKKyoqc2xpY2Vc X3BpeGVsXF93aWR0aCoqIGlzIHRoZSB3aWR0aCBpbiBwaXhlbHMgb2YgdGhlIHNsaWNlLiAg CitJdHMgdmFsdWUgaXMgJmxmbG9vcjsoIHNsaWNlXF94ICsgc2xpY2VcX3dpZHRoICkgKiBz bGljZVxfcGl4ZWxcX3dpZHRoIC8gbnVtXF9oXF9zbGljZXMmcmZsb29yOyAtIHNsaWNlXF9w aXhlbFxfeCAgCisKKyoqc2xpY2VcX3BpeGVsXF94KiogaXMgdGhlIHNsaWNlIGhvcml6b250 YWwgcG9zaXRpb24gaW4gcGl4ZWxzLiAgCitJdHMgdmFsdWUgaXMgJmxmbG9vcjtzbGljZV94 ICogZnJhbWVcX3BpeGVsXF93aWR0aCAvIG51bVxfaFxfc2xpY2VzJnJmbG9vcjsKKwogIyMg U2xpY2UgRm9vdGVyCiAKIE5vdGU6IHNsaWNlIGZvb3RlciBpcyBhbHdheXMgYnl0ZSBhbGln bmVkLgotLSAKMi43LjAud2luZG93cy4xCgo= --------------6C81031523CD43A0C5C8ABDE-- From nobody Sat Jun 18 08:42:57 2016 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 7B69F12D640 for ; Sat, 18 Jun 2016 08:42:56 -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 pok1KeBuI_c9 for ; Sat, 18 Jun 2016 08:42:55 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213A112D633 for ; Sat, 18 Jun 2016 08:42:54 -0700 (PDT) Received: from mfilter35-d.gandi.net (mfilter35-d.gandi.net [217.70.178.166]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 9CCF3C5A54 for ; Sat, 18 Jun 2016 17:42:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter35-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter35-d.gandi.net (mfilter35-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id qaF1HH7cf5Uf for ; Sat, 18 Jun 2016 17:42:51 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 34B96C5A5C for ; Sat, 18 Jun 2016 17:42:50 +0200 (CEST) Date: Sat, 18 Jun 2016 17:42:29 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160618154229.GS4636@nb4> References: <689e1ea5-1828-3d6d-7db3-ff7ad58d3c11@mediaarea.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pdljsUaSfr6a298O" Content-Disposition: inline In-Reply-To: <689e1ea5-1828-3d6d-7db3-ff7ad58d3c11@mediaarea.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] [PATCH] Add definition of Line() X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 18 Jun 2016 15:42:56 -0000 --pdljsUaSfr6a298O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 18, 2016 at 04:17:39PM +0200, Jerome Martinez wrote: > the algorithm is similar for both colorspaces, but I preferred to > separate them in order to have coherency with the descriptions in > SliceContent(). > ffv1.md | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > beffc7fb6d5128a2ef8d1232dead12b7c187c1b7 0001-Add-definition-of-Line.pat= ch > From 931321787dd3699bc671cb0dee6016d8126612cd Mon Sep 17 00:00:00 2001 > From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D > Date: Sat, 18 Jun 2016 16:17:05 +0200 > Subject: [PATCH] Add definition of Line() >=20 > Also define slice_pixel_width, slice_pixel_x > and plane_pixel_width[ p ] > --- > ffv1.md | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) applied thanks [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. --pdljsUaSfr6a298O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAldla+UACgkQYR7HhwQLD6tE7wCffLa2kVx/qrS+d5s2OuJQQncN glQAn3BrXRQxLjcpwnbHl36csYNhwUcK =fa5K -----END PGP SIGNATURE----- --pdljsUaSfr6a298O-- From nobody Mon Jun 20 06:50:53 2016 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 1D9F512D113 for ; Mon, 20 Jun 2016 06:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 TGKckFvpkVVr for ; Mon, 20 Jun 2016 06:50:48 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 A6413126579 for ; Mon, 20 Jun 2016 06:50:47 -0700 (PDT) Received: from [146.96.19.240] (port=11610 helo=[10.10.201.73]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bEzb9-003i2o-3R; Mon, 20 Jun 2016 09:50:46 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <5764156D.40100@xiph.org> Date: Mon, 20 Jun 2016 09:50:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4B30F339-4196-4268-8FF1-019024D777D3@dericed.com> References: <5CBBD1F2-E4D4-4453-B74E-BC854B3F673D@dericed.com> <57638C5E.90506@xiph.org> <286C62FD-3073-487F-AD1A-A81CC2C3D6D6@dericed.com> <5764156D.40100@xiph.org> To: "Timothy B. Terriberry" X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] An attempt at EBML specification in RFC form X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jun 2016 13:50:52 -0000 > On Jun 17, 2016, at 11:21 AM, Timothy B. Terriberry = wrote: >=20 > Dave Rice wrote: >> Steve, Moritz, other, specific suggestions for EBML authorship? Leave = as Steve alone, add other working group members? >=20 > Given the way you've been acting in capacity as editor thus far, I'd = suggest you might want to consider adding yourself. The PR is updated to add my name. = https://github.com/Matroska-Org/ebml-specification/pull/66 Dave Rice= From nobody Fri Jun 24 09:10:38 2016 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 4671912DD77; Fri, 24 Jun 2016 09:01:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160103.10933.95914.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:01:03 -0700 Archived-At: Cc: ben@nostrum.com, cellar@ietf.org Subject: [Cellar] cellar - Requested session has been scheduled for IETF 96 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 16:01:03 -0000 Dear Tim Terriberry, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cellar Session 1 (2:00:00) Tuesday, Afternoon Session I 1400-1600 Room Name: Tiergarten size: 110 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Codec Encoding for LossLess Archiving and Realtime transmission Area Name: Applications and Real-Time Area Session Requester: Tim Terriberry Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: rtcweb avtcore netvc Second Priority: mmusic avtext Third Priority: acme tcpinc tls webpush Special Requests: If possible, we would prefer a slot on Tuesday or Wednesday, in order to coordinate with other Matroska/FFV1-related events in Berlin. Failing those, Monday is the next best day. Thanks. --------------------------------------------------------- From nobody Sat Jun 25 19:05:23 2016 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 CCEE6128B44 for ; Sat, 25 Jun 2016 19:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 F7yOUAZJv82x for ; Sat, 25 Jun 2016 19:05:20 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 3C286127078 for ; Sat, 25 Jun 2016 19:05:20 -0700 (PDT) Received: from [172.56.29.126] (port=63246 helo=[172.20.10.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bGzRl-002P3O-GF for cellar@ietf.org; Sat, 25 Jun 2016 22:05:19 -0400 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <54684B49-358B-4E32-A250-BD95C7EFEFDD@dericed.com> Date: Sat, 25 Jun 2016 22:05:19 -0400 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] presentation of the Matroska schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 02:05:22 -0000 Hi all, I'm looking for feedback on how to present Matroska Elements in the = specification. Currently the definitions of the Matroska elements are at = https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/ebml_= matroska.xml. This xml defines the elements as an EBML Schema which is = defined in the EBML spec. Currently the human readable presentation of = the Matroska Elements is in a big table at = https://matroska.org/technical/specs/index.html#LevelEBML. With the current displays of Matroska elements I think we have a few = issues: - Only very sparse descriptions are used for the elements. I think a = long description would be the table unwieldy. - The hierarchy of elements is hard to understand in the table (would = have to scroll back up to the element of the lower level, with some = exceptions for global elements). - This form of the table won't fit well into an RFC style document. =46rom the ebml_matroska.xml we have an XSL file that can convert it to = an HTML table to replicate the existing presentation. I've been working = on another XSL that converts the ebml_matroska.xml file into a markdown = document which presents each element in its own table. A draft of the = output is here: = https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac. In = this style of presentation there is more room per element so I added = data to show the parent element, child element(s), and element in = hierarchical context. Markdown like this could be used when at RFC is = built. I think a markdown output of the matroska elements (with a table per = element) also allows up to add more types of descriptions. For example = in the ebml_matroska.xml, we currently only have one description, but = this could be extended in order to have different types such as: - definition - rationale - usage notes - references (could optionally link to test files that demonstrate the = element) Each element would require a definition (a short description) which = would be used in outputs such as = https://matroska.org/technical/specs/index.html#LevelEBML, but the = markdown output for the RFC or more verbose displays of element data = could include the additional descriptions. So I'd like feedback on: - impressions of = https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac - is it worthwhile to add new data to element definitions such as = rationale and usage notes? Best Regards, Dave Rice= From nobody Sun Jun 26 13:12:23 2016 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 9C35212D114 for ; Sun, 26 Jun 2016 13:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 xn56eGzS5Hf0 for ; Sun, 26 Jun 2016 13:12:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E07112D0CC for ; Sun, 26 Jun 2016 13:12:17 -0700 (PDT) Received: from [192.168.178.25] ([91.3.241.209]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDW9x-1b7aok0rxV-00GoJz; Sun, 26 Jun 2016 22:11:27 +0200 To: Dave Rice , cellar@ietf.org References: <54684B49-358B-4E32-A250-BD95C7EFEFDD@dericed.com> From: hubblec4 Message-ID: <914c29de-89a1-e505-64c6-07ddf34a07dc@gmx.ch> Date: Sun, 26 Jun 2016 22:11:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <54684B49-358B-4E32-A250-BD95C7EFEFDD@dericed.com> Content-Type: multipart/alternative; boundary="------------FF04896B28CB7358078DBA69" X-Provags-ID: V03:K0:rwroD2uhjjfPgbmKk/Y9o82E+wTxyv6lR+yrGAAsGRZiPjwj6JN MuQHTipih2A2EPoBemlgSvWljoNGXfchfhPB7Wlq6uDbcA8MQzuppwO4IKS52YO2Jy8KIzR 8RbVt37/gRnrAdRy/DOOxzlhQ6TLC+gSInn8CxGNxQnU7sPbDrQk58wmlxrbIYpAKw1kn4W OYqdrBETIxsyHKNjFyiGQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:9fjxDKgfiHQ=:Ng4lSu2gl0BETzi2yzsiiN FrbND0V39q7ISL4fBpaskaLnFcfOA6JVJBKMaD2dHM0da2lm0cgbKtxcV0O6kzR1zOzR0JfFG hheeLxYWiLGDSFH5SI5QUi3JxJPyIu7l5JfY6udCJG8SZEkES7VF8lYpZ4QGJveH+A9QzP8xJ l39MCiqHXuW8bel1no7wKORhVGfT9Y5c8loYv1DcY1zn9Vi7DowAU6r9uMaC850bb1aLF2Qqg PHoP12EJAEfeVIx87BQvEusLWTdGWK4aQTCxDeRatqLqpRdYF6Oa0f8wfIMLMfOW0kfVLsSWG 1iHUskbAieHDnZGfnoczVRuJQRQyx7mev2AJXBflwHa42DVGDMQ3BJJpHYGOVJaFaHxUjo063 OOq15qZ6eooDSgSzAP99WYQuRJl0HTgSFda4qk3i6T+149LyI0JRWoLa6kWZcLmNcVgM6wBw6 TAxpWp9s1j9hzEr0A2z0uN5ccz4oZZaXtzgj5EhNDpwa01IeaCVW7ehqchSL/RYcOz3v6Xvl5 KY1t/X/PVSwbq1KGILxycNQWg2ImsKHTNDuV1KvimLRGwJ6tRhtfSqWTGufY33WZHHHiEqlCD udrrqTItljji+8rdopftwF4UCMcBy0Dj9/3QX8grQ8vZHGX/OIZglLMxo+se1e4vDAczVLA3e x5GEVjRh44jkv5x+9unqB+MW0Xn9rU7MBOY2LPeNNAA8fToSX3Cr1WXygOqOMzMvJ5bVjhCsG uYT9r6TPqShK86zBe1ibzYHAoN/IVXQPYXE8cSJOMMwUxAR0X1MWW3FGqxyUc1qTSUPtJCm91 gz2PxKj Archived-At: Subject: Re: [Cellar] presentation of the Matroska schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 20:12:22 -0000 This is a multi-part message in MIME format. --------------FF04896B28CB7358078DBA69 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi all This is my first post here. My name is Martin Below and I'm from germany and 38 years old. In 2008, I came across Matroska. I am very interested in the specs, especially for the Chapters, and the Tags. In my chapterEditor project there is a Chapter- Tags- and (first simple) Menu editor. I found the specs was a good help, but not perfect and sometimes I was a bit confused. Mosu helps me a lot with infos which I can't find on the Matroska page. @Dave Rice The new style looks pretty good. Maybe you can use "Level-colors" like in the old style (maybe the deeper levels(gray) should have other colors). I like the new data's(parent element, child element(s), and element in hierarchical context) and the structure. Extended description "usage notes" is very important in my eye's. In the beginning at my project I decided users can enter valid settings and values only. But what is valid? The element ChapterTimeEnd(CTE) has no description that it can used with EditionFlagOrdered=true only. If an edition is not ordered the CTE has no effect and a splitter will ignore them. Is a CTE allowed in a non-ordered edition? The same for ChapterSegementUID and ChapterSegmentEditionUID. More complex is the question of nested-ordered-chapters. Extended description "references" a is a great idea. Nothing is better as samples!!! I found in the old style 2 elements marked with a "+". ChapterAtom and SimpleTag. This elements can be a child element of its own. You should add the ChapterAtom element in the "Child Elements"-section of the ChapterAtom(same with SimpleTag). Some element names do not match to the specs-element names. Starting from "ChapString" to "ChapProcessData". I waste lot of time until Mosu told me that "Chap" is not correct. The element names should change to the correct form. (ChapterString - ChapterProcessData). I hope it helps you. At the moment I have not much time, but I will help to improve Matroska. I know many about Chapters and Tags, but I know there are many more and it will takes time to learn everything. Best Regards, Martin Below Am 26.06.2016 um 04:05 schrieb Dave Rice: > Hi all, > > I'm looking for feedback on how to present Matroska Elements in the specification. Currently the definitions of the Matroska elements are at https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/ebml_matroska.xml. This xml defines the elements as an EBML Schema which is defined in the EBML spec. Currently the human readable presentation of the Matroska Elements is in a big table at https://matroska.org/technical/specs/index.html#LevelEBML. > > With the current displays of Matroska elements I think we have a few issues: > > - Only very sparse descriptions are used for the elements. I think a long description would be the table unwieldy. > - The hierarchy of elements is hard to understand in the table (would have to scroll back up to the element of the lower level, with some exceptions for global elements). > - This form of the table won't fit well into an RFC style document. > > From the ebml_matroska.xml we have an XSL file that can convert it to an HTML table to replicate the existing presentation. I've been working on another XSL that converts the ebml_matroska.xml file into a markdown document which presents each element in its own table. A draft of the output is here: https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac. In this style of presentation there is more room per element so I added data to show the parent element, child element(s), and element in hierarchical context. Markdown like this could be used when at RFC is built. > > I think a markdown output of the matroska elements (with a table per element) also allows up to add more types of descriptions. For example in the ebml_matroska.xml, we currently only have one description, but this could be extended in order to have different types such as: > - definition > - rationale > - usage notes > - references (could optionally link to test files that demonstrate the element) > > Each element would require a definition (a short description) which would be used in outputs such as https://matroska.org/technical/specs/index.html#LevelEBML, but the markdown output for the RFC or more verbose displays of element data could include the additional descriptions. > > So I'd like feedback on: > > - impressions of https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac > - is it worthwhile to add new data to element definitions such as rationale and usage notes? > > Best Regards, > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --------------FF04896B28CB7358078DBA69 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi all

This is my first post here.

My name is Martin Below and I'm from germany and 38 years old.
In 2008, I came across Matroska.
I am very interested in the specs, especially for the Chapters, and the Tags.
In my chapterEditor project there is a Chapter- Tags- and (first simple) Menu editor.
I found the specs was a good help, but not perfect and sometimes I was a bit confused.

Mosu helps me a lot with infos which I can't find on the Matroska page.

@Dave Rice

The new style looks pretty good.
Maybe you can use "Level-colors" like in the old style (maybe the deeper levels(gray) should have other colors).

I like the new data's(parent element, child element(s), and element in hierarchical context) and the structure.

Extended description "usage notes" is very important in my eye's.
In the beginning at my project I decided users can enter valid settings and values only.
But what is valid?
The element ChapterTimeEnd(CTE) has no description that it can used with EditionFlagOrdered=true only.
If an edition is not ordered the CTE has no effect and a splitter will ignore them.
Is a CTE allowed in a non-ordered edition?
The same for ChapterSegementUID and ChapterSegmentEditionUID.
More complex is the question of nested-ordered-chapters.

Extended description "references" a is a great idea. Nothing is better as samples!!!

I found in the old style 2 elements marked with a "+". ChapterAtom and SimpleTag.
This elements can be a child element of its own.
You should add the ChapterAtom element in the "Child Elements"-section of the ChapterAtom(same with SimpleTag).

Some element names do not match to the specs-element names.
Starting from "ChapString" to "ChapProcessData".
I waste lot of time until Mosu told me that "Chap" is not correct.
The element names should change to the correct form. (ChapterString - ChapterProcessData).

I hope it helps you.


At the moment I have not much time, but I will help to improve Matroska.
I know many about Chapters and Tags, but I know there are many more and it will takes time to learn everything.


Best Regards,
Martin Below



Am 26.06.2016 um 04:05 schrieb Dave Rice:
Hi all,

I'm looking for feedback on how to present Matroska Elements in the specification. Currently the definitions of the Matroska elements are at https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/ebml_matroska.xml. This xml defines the elements as an EBML Schema which is defined in the EBML spec. Currently the human readable presentation of the Matroska Elements is in a big table at https://matroska.org/technical/specs/index.html#LevelEBML.

With the current displays of Matroska elements I think we have a few issues:

- Only very sparse descriptions are used for the elements. I think a long description would be the table unwieldy.
- The hierarchy of elements is hard to understand in the table (would have to scroll back up to the element of the lower level, with some exceptions for global elements).
- This form of the table won't fit well into an RFC style document.

>From the ebml_matroska.xml we have an XSL file that can convert it to an HTML table to replicate the existing presentation. I've been working on another XSL that converts the ebml_matroska.xml file into a markdown document which presents each element in its own table. A draft of the output is here: https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac. In this style of presentation there is more room per element so I added data to show the parent element, child element(s), and element in hierarchical context. Markdown like this could be used when at RFC is built.

I think a markdown output of the matroska elements (with a table per element) also allows up to add more types of descriptions. For example in the ebml_matroska.xml, we currently only have one description, but this could be extended in order to have different types such as:
- definition
- rationale
- usage notes
- references (could optionally link to test files that demonstrate the element)

Each element would require a definition (a short description) which would be used in outputs such as https://matroska.org/technical/specs/index.html#LevelEBML, but the markdown output for the RFC or more verbose displays of element data could include the additional descriptions.

So I'd like feedback on:

- impressions of https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac
- is it worthwhile to add new data to element definitions such as rationale and usage notes?

Best Regards,
Dave Rice
_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

--------------FF04896B28CB7358078DBA69-- From nobody Sun Jun 26 15:20:42 2016 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 A92B012D187 for ; Sun, 26 Jun 2016 15:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 bBmOi2YOXEyr for ; Sun, 26 Jun 2016 15:20:39 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 503EE12D0EE for ; Sun, 26 Jun 2016 15:20:39 -0700 (PDT) Received: from mc35736d0.tmodns.net ([208.54.87.195]:32859 helo=[172.20.10.2]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bHIPs-002ZME-Lx; Sun, 26 Jun 2016 18:20:38 -0400 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <56678134-6E83-4CA0-914A-0A4420894481@dericed.com> Date: Sun, 26 Jun 2016 18:20:39 -0400 To: cellar@ietf.org, Steve Lhomme , Moritz Bunkus Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] deprecated elements? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 22:20:41 -0000 Hi Steve, Moritz, or anyone who may know their Matroska history well, I'm working on element presentations and noticed some inconsistency in = deprecated elements. TimeSlice is listed as deprecated in its description but doesn't list a = maxver. So when was TimeSlice deprecated / what is the maxver of = TimeSlice? Same question for LaceNumber? OldStereoMode. I think I've asked about this before but it has a maxver = of 0. Was there a Matroska version 0? Also the minver is 1, so this = doesn't really make sense. Should maxver of OldStereoMode be 1? Some elements note as deprecated do list a maxver which implies when the = deprecation happens. For instance TrackTimecodeScale is deprecated after = version 3. Best Regards, Dave Rice= From nobody Sun Jun 26 15:41:42 2016 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 BEF9812D18F for ; Sun, 26 Jun 2016 15:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 ldHLXnQlczte for ; Sun, 26 Jun 2016 15:41:36 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 BAFE212D0EE for ; Sun, 26 Jun 2016 15:41:36 -0700 (PDT) Received: from mc35736d0.tmodns.net ([208.54.87.195]:41466 helo=[172.20.10.2]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bHIk5-003DOD-IB; Sun, 26 Jun 2016 18:41:36 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_DE76D7D9-67C0-4033-8D2A-7CF509BF6750" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <914c29de-89a1-e505-64c6-07ddf34a07dc@gmx.ch> Date: Sun, 26 Jun 2016 18:41:32 -0400 Message-Id: <3AAF2F03-9D0F-4DA6-966F-44D34F12E084@dericed.com> References: <54684B49-358B-4E32-A250-BD95C7EFEFDD@dericed.com> <914c29de-89a1-e505-64c6-07ddf34a07dc@gmx.ch> To: hubblec4 X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] presentation of the Matroska schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 22:41:40 -0000 --Apple-Mail=_DE76D7D9-67C0-4033-8D2A-7CF509BF6750 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Martin, > On Jun 26, 2016, at 4:11 PM, hubblec4 wrote: >=20 > Hi all >=20 > This is my first post here.=20 > My name is Martin Below and I'm from germany and 38 years old.=20 Welcome!!! btw since you are in Germany have you seen = https://mediaarea.net/MediaConch/notimetowait.html ? > In 2008, I came across Matroska. > I am very interested in the specs, especially for the Chapters, and = the Tags. > In my chapterEditor = project there is a Chapter- Tags- and (first simple) Menu editor. > I found the specs was a good help, but not perfect and sometimes I was = a bit confused. >=20 > Mosu helps me a lot with infos which I can't find on the Matroska = page. If in turn you could help get such info into the matroska or ebml = specifications it would improve their quality. > @Dave Rice >=20 > The new style = looks = pretty good.=20 > Maybe you can use "Level-colors" like in the old style (maybe the = deeper levels(gray) should have other colors). Well the Markdown in particular is prepped to be transformed into an RFC = where everything in fixed width and plain text so in that case there's = no options for colors or much formatting, but I think the same markdown = could be used to make an alternate presentation to the current element = table, so that maybe we could have a condensed table version and then a = larger one like the markdown draft where more details can be given for = each element. > I like the new data's(parent element, child element(s), and element in = hierarchical context) and the structure. Thanks. > Extended description "usage notes" is very important in my eye's. > In the beginning at my project I decided users can enter valid = settings and values only. > But what is valid? Well I'm hoping to judge if there's enough volunteer energy for this. = Currently each Matroska element has an average definition word count of = 17. Then more extensive descriptions are sometimes interspersed into the = rest of the narrative. But if we extended the structure in = https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/ebml_= matroska.xml to include additional descriptions we could communicate = more effective about how this is to be used.=20 For instance, whereas we currently define an element with Muxing application or library = ("libmatroska-0.4.3"). we could have something like: Muxing application or = library ("libmatroska-0.4.3"). The Muxing application = should be documented in order to allow a Matroska file to be associated = with the software that created the file. It is recommended to = include the full name of the muxing application followed by the version = number. Then the table could only use the documentation[@type=3D'definition'] = whereas other renditions such as the RFC could use all the documentation = values. > The element ChapterTimeEnd(CTE) has no description that it can used = with EditionFlagOrdered=3Dtrue only. > If an edition is not ordered the CTE has no effect and a splitter will = ignore them. > Is a CTE allowed in a non-ordered edition? > The same for ChapterSegementUID and ChapterSegmentEditionUID. > More complex is the question of nested-ordered-chapters. Thanks for bringing these up. I think we can agree on how to structure = and store element descriptions then we can start new threads to draft = extended documentation for each element so that the questions and = scenarios you bring up can be better clarified by the documentation. > Extended description "references" a is a great idea. Nothing is better = as samples!!! >=20 > I found in the old style 2 elements marked with a "+". ChapterAtom and = SimpleTag. > This elements can be a child element of its own. > You should add the ChapterAtom element in the "Child Elements"-section = of the ChapterAtom(same with SimpleTag). Thanks for pointing this out. I'll add handling of recursion into my = draft and send a pull request. > Some element names do not match to the specs-element names.=20 > Starting from "ChapString" to "ChapProcessData". > I waste lot of time until Mosu told me that "Chap" is not correct. > The element names should change to the correct form. (ChapterString - = ChapterProcessData). Moritz, can you verify this. =46rom google search I see that = "ChapterString"+matroska is more popular than "ChapString"+matroska but = I am hesitant to change names in an official document too quickly. > I hope it helps you. Yes, very much. > At the moment I have not much time, but I will help to improve = Matroska. > I know many about Chapters and Tags, but I know there are many more = and it will takes time to learn everything. >=20 >=20 > Best Regards, > Martin Below Best Regards, Dave Rice >=20 >=20 > Am 26.06.2016 um 04:05 schrieb Dave Rice: >> Hi all, >>=20 >> I'm looking for feedback on how to present Matroska Elements in the = specification. Currently the definitions of the Matroska elements are at = https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/ebml_= matroska.xml = . This xml defines the elements as an EBML Schema which is = defined in the EBML spec. Currently the human readable presentation of = the Matroska Elements is in a big table at = https://matroska.org/technical/specs/index.html#LevelEBML = . >>=20 >> With the current displays of Matroska elements I think we have a few = issues: >>=20 >> - Only very sparse descriptions are used for the elements. I think a = long description would be the table unwieldy. >> - The hierarchy of elements is hard to understand in the table (would = have to scroll back up to the element of the lower level, with some = exceptions for global elements). >> - This form of the table won't fit well into an RFC style document. >>=20 >> >=46rom the ebml_matroska.xml we have an XSL file that can convert it = to an HTML table to replicate the existing presentation. I've been = working on another XSL that converts the ebml_matroska.xml file into a = markdown document which presents each element in its own table. A draft = of the output is here: = https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac = . In = this style of presentation there is more room per element so I added = data to show the parent element, child element(s), and element in = hierarchical context. Markdown like this could be used when at RFC is = built. >>=20 >> I think a markdown output of the matroska elements (with a table per = element) also allows up to add more types of descriptions. For example = in the ebml_matroska.xml, we currently only have one description, but = this could be extended in order to have different types such as: >> - definition >> - rationale >> - usage notes >> - references (could optionally link to test files that demonstrate = the element) >>=20 >> Each element would require a definition (a short description) which = would be used in outputs such as = https://matroska.org/technical/specs/index.html#LevelEBML = , but the = markdown output for the RFC or more verbose displays of element data = could include the additional descriptions. >>=20 >> So I'd like feedback on: >>=20 >> - impressions of = https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac = >> - is it worthwhile to add new data to element definitions such as = rationale and usage notes? >>=20 >> Best Regards, >> Dave Rice >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar = >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_DE76D7D9-67C0-4033-8D2A-7CF509BF6750 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Martin,

On Jun 26, 2016, at 4:11 PM, = hubblec4 <hubblec4@gmx.ch> wrote:

=20 =20

Hi = all

This is my first post here.

My name is Martin Below and I'm from germany and 38 years = old. 

Welcome!!! btw since you are in Germany have you = seen https://mediaarea.net/MediaConch/notimetowait.html = ?

In = 2008, I came across Matroska.
I am very interested in the specs, especially for the Chapters, and the Tags.
In my chapterEditor project there is a Chapter- Tags- and (first simple) Menu editor.
I found the specs was a good help, but not perfect and sometimes I was a bit confused.

Mosu helps me a lot with infos which I can't find on the Matroska page.

If in turn you could help get such info into the = matroska or ebml specifications it would improve their quality.

@Dave Rice

The new style looks pretty good.
Maybe you can use "Level-colors" like in the old style (maybe the deeper levels(gray) should have other colors).

Well = the Markdown in particular is prepped to be transformed into an RFC = where everything in fixed width and plain text so in that case there's = no options for colors or much formatting, but I think the same markdown = could be used to make an alternate presentation to the current element = table, so that maybe we could have a condensed table version and then a = larger one like the markdown draft where more details can be given for = each element.

I like the new data's(parent element, child element(s), and element in hierarchical context) and the structure.

Thanks.

Extended description "usage notes" is very important in my eye's.
In the beginning at my project I decided users can enter valid settings and values only.
But what is valid?

Well I'm hoping to judge if there's enough = volunteer energy for this. Currently each Matroska element has an = average definition word count of 17. Then more extensive descriptions = are sometimes interspersed into the rest of the narrative. But if we = extended the structure in https://github.com/Matroska-Org/matroska-specification/blob/gh-= pages/ebml_matroska.xml to include additional descriptions we could = communicate more effective about how this is to be = used. 

For instance, whereas we = currently define an element with

<element name=3D"MuxingApp" level=3D"2"=  id=3D"0x4D80" type=3D"utf-8" minOccurs=3D"1" minver=3D= "1">
    = <documentation lang=3D"en">Muxing application or library = ("libmatroska-0.4.3").</documentation>
</element>

we could = have something like:

<element name=3D"MuxingApp" level=3D"2"=  id=3D"0x4D80" type=3D"utf-8" minOccurs=3D"1" minver=3D= "1">
    <documentation lang=3D"en" = type=3D"definition">Muxing application or library = ("libmatroska-0.4.3").</documentation>
    = <documentation lang=3D"en" type=3D"rationale">The Muxing = application should be documented in order to allow a Matroska file to be = associated with the software that created the = file.</documentation>
    = <documentation lang=3D"en" type=3D"usage notes">It is = recommended to include the full name of the muxing application followed = by the version number.</documentation>
</element>

Then the = table could only use the documentation[@type=3D'definition'] whereas = other renditions such as the RFC could use all the documentation = values.

The element ChapterTimeEnd(CTE) has no description that it can used with EditionFlagOrdered=3Dtrue only.
If an edition is not ordered the CTE has no effect and a splitter will ignore them.
Is a CTE allowed in a non-ordered edition?
The same for ChapterSegementUID and ChapterSegmentEditionUID.
More complex is the question of nested-ordered-chapters.

Thanks = for bringing these up. I think we can agree on how to structure and = store element descriptions then we can start new threads to draft = extended documentation for each element so that the questions and = scenarios you bring up can be better clarified by the = documentation.

Extended description "references" a is a great idea. Nothing is better as samples!!!

I found in the old style 2 elements marked with a "+". ChapterAtom and SimpleTag.
This elements can be a child element of its own.
You should add the ChapterAtom element in the = "Child Elements"-section of the ChapterAtom(same with = SimpleTag).

Thanks for pointing this out. I'll add handling of = recursion into my draft and send a pull request.

Some element names do not match to the specs-element names.
Starting from "ChapString" to "ChapProcessData".
I waste lot of time until Mosu told me that "Chap" is not = correct.
The element names should change to the correct form. (ChapterString - ChapterProcessData).
Moritz, can you verify this. =46rom google search = I see that "ChapterString"+matroska is more popular than = "ChapString"+matroska but I am hesitant to change names in an official = document too quickly.

I hope it helps you.

Yes, very much.

At the moment I have not much time, but I will help to improve Matroska.
I know many about Chapters and Tags, but I know there are many more and it will takes time to learn everything.


Best Regards,
Martin Below

Best Regards,
Dave Rice



Am 26.06.2016 um 04:05 schrieb Dave Rice:
Hi all,

I'm looking for feedback on how to present Matroska Elements in the =
specification. Currently the definitions of the Matroska elements are at =
https://github.com/Matroska-Org/matroska-specificati=
on/blob/gh-pages/ebml_matroska.xml. This xml defines the elements as =
an EBML Schema which is defined in the EBML spec. Currently the human =
readable presentation of the Matroska Elements is in a big table at https:/=
/matroska.org/technical/specs/index.html#LevelEBML.

With the current displays of Matroska elements I think we have a few =
issues:

- Only very sparse descriptions are used for the elements. I think a =
long description would be the table unwieldy.
- The hierarchy of elements is hard to understand in the table (would =
have to scroll back up to the element of the lower level, with some =
exceptions for global elements).
- This form of the table won't fit well into an RFC style document.

>=46rom the ebml_matroska.xml we have an XSL file that can convert it =
to an HTML table to replicate the existing presentation. I've been =
working on another XSL that converts the ebml_matroska.xml file into a =
markdown document which presents each element in its own table. A draft =
of the output is here: =
https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac. In =
this style of presentation there is more room per element so I added =
data to show the parent element, child element(s), and element in =
hierarchical context. Markdown like this could be used when at RFC is =
built.

I think a markdown output of the matroska elements (with a table per =
element) also allows up to add more types of descriptions. For example =
in the ebml_matroska.xml, we currently only have one description, but =
this could be extended in order to have different types such as:
- definition
- rationale
- usage notes
- references (could optionally link to test files that demonstrate the =
element)

Each element would require a definition (a short description) which =
would be used in outputs such as https:/=
/matroska.org/technical/specs/index.html#LevelEBML, but the markdown =
output for the RFC or more verbose displays of element data could =
include the additional descriptions.

So I'd like feedback on:

- impressions of =
https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac
- is it worthwhile to add new data to element definitions such as =
rationale and usage notes?

Best Regards,
Dave Rice
_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org=
/mailman/listinfo/cellar

_______________________________________________
Cellar = mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_DE76D7D9-67C0-4033-8D2A-7CF509BF6750-- From nobody Sun Jun 26 16:03:34 2016 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 5E62D12D195 for ; Sun, 26 Jun 2016 16:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 3mXqPdAWYxsh for ; Sun, 26 Jun 2016 16:03:31 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 11ABD12D196 for ; Sun, 26 Jun 2016 16:03:31 -0700 (PDT) Received: from mc35736d0.tmodns.net ([208.54.87.195]:45578 helo=[172.20.10.2]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bHJ5M-003dFN-AN for cellar@ietf.org; Sun, 26 Jun 2016 19:03:30 -0400 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7B7994FA-E2F9-44F8-80F8-13A26C01948D@dericed.com> Date: Sun, 26 Jun 2016 19:03:25 -0400 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] ebml: add recursive attribute and update level attribute X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 23:03:33 -0000 Hi all, In the EBML spec I added a definition for a 'recursive' attribute in the = EBML Schema and modified the 'level 'attribute's description. The pull = request can be viewed here: = https://github.com/Matroska-Org/ebml-specification/pull/67. For review = here are the updated definitions. Better re-writes are welcome. level: The level notes at what hierarchical depth the EBML Element may occur = within an EBML Document. The Root Element of an EBML Document is at = level 0 and the Elements that it may contain are at level 1. The level = MUST be expressed as an integer. Note that for Elements defined as = `global` and `recursive` the Element MAY occur at a level greater than = or equal to the defined `level`. recusrive A boolean to express if an EBML Element MAY be stored recursively. In = this case the Element MAY be stored at levels greater that defined in = the `level` attribute if the Element is a Child Element of a Parent = Element with the same Element ID. The `recursive` attribute only applies = to Master-elements. If the `recursive` attribute is not used it is = assumed that the element is not allowed to be used recursively. Best Regards, Dave Rice= From nobody Sun Jun 26 16:20:39 2016 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 31D0C12D19E for ; Sun, 26 Jun 2016 16:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 yp1n-DBpUzpq for ; Sun, 26 Jun 2016 16:20:36 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 7F6B912B039 for ; Sun, 26 Jun 2016 16:20:36 -0700 (PDT) Received: from mc35736d0.tmodns.net ([208.54.87.195]:29927 helo=[172.20.10.2]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bHJLs-0041GO-OO for cellar@ietf.org; Sun, 26 Jun 2016 19:20:36 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_C54F8BEA-4E7F-4A38-A541-434708467581" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Sun, 26 Jun 2016 19:20:24 -0400 References: <54684B49-358B-4E32-A250-BD95C7EFEFDD@dericed.com> To: cellar@ietf.org In-Reply-To: <54684B49-358B-4E32-A250-BD95C7EFEFDD@dericed.com> X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] presentation of the Matroska schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 23:20:38 -0000 --Apple-Mail=_C54F8BEA-4E7F-4A38-A541-434708467581 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 25, 2016, at 10:05 PM, Dave Rice wrote: >=20 > I think a markdown output of the matroska elements (with a table per = element) also allows up to add more types of descriptions. For example = in the ebml_matroska.xml, we currently only have one description, but = this could be extended in order to have different types such as: > - definition > - rationale > - usage notes > - references (could optionally link to test files that demonstrate the = element) I provided a pull request at = https://github.com/Matroska-Org/ebml-specification/pull/68 which extends = the use of the element in the EBML Schema to classify = what types of documentation are provided in element definitions. Best Regards, Dave Rice= --Apple-Mail=_C54F8BEA-4E7F-4A38-A541-434708467581 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jun 25, 2016, at 10:05 PM, Dave Rice <dave@dericed.com> = wrote:

I think a markdown output of the matroska = elements (with a table per element) also allows up to add more types of = descriptions. For example in the ebml_matroska.xml, we currently only = have one description, but this could be extended in order to have = different types such as:
- definition
- rationale
- usage notes
- references (could = optionally link to test files that demonstrate the element)

I provided a pull request at https://github.com/Matroska-Org/ebml-specification/pull/68 = which extends the use of the <documentation> element in the EBML = Schema to classify what types of documentation are provided in element = definitions.
Best Regards,
Dave = Rice
= --Apple-Mail=_C54F8BEA-4E7F-4A38-A541-434708467581-- From nobody Mon Jun 27 00:12:18 2016 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 53A3A12B042 for ; Mon, 27 Jun 2016 00:12:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 tEOl475HZ6fv for ; Mon, 27 Jun 2016 00:12:16 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 D1BD2128874 for ; Mon, 27 Jun 2016 00:12:15 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l125so147079986ywb.2 for ; Mon, 27 Jun 2016 00:12:15 -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=f9MOCaCmHDS3ehzH2U5CMk6gA3gU38Ss8t4lgyT6Izk=; b=o+tR6SNwPI0z6xwswUYTKi4w0MUCVkFUdzO3RDvSUA2xRbF7uEdVnq1NO1j0THOVYz HZM6o14W4oibv9vJcIE23uA4JwOaJMgZGUSLUbXtlEW2WFE5mt3N4+aWqwmPvwaFimLJ 7NbS9Q9IV5Gc3vJ8F+6/8WgbzmmGE9XyXBzn5Kfzpxp4xT2bUJDfxq3RGozwI3LFm9JZ ma82KuE/50yEtWzLMRiTzF/07ERTJUfXrmqLDfcO7RBQb/g/4RzjLPk5zqr5FBT850DZ C33yxvEL6W6yfMX4Lv7cDooHfg9RPix7tCjEWBQ92NPVYdygJytudE6eAhd+PV8zO1N2 v8mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f9MOCaCmHDS3ehzH2U5CMk6gA3gU38Ss8t4lgyT6Izk=; b=fAUGuPz80ywpsb+2fiYSRLoAA/AVn1K+VAoeWAC8GjPDhFebJ1+OBiYEK2f4QdPLBP vkjogB01kvWju/aGx/Mnxowg8GXnnnVUM2OlY2KXidbtM6v2md+I0oXiA/PFvQgIgZcp 0At1z8swKqnSYt0W49RwxDmwabYGEiEM1Exng/tKRyBBVybhI7zybNQ/V/jWLwPoXKrk yjsS853LK/JTkfQNYu4cJWZPIHZQr5CVIbx0RWNaZ8aI7AFfDROvyP3Ij6pZKWd+ytdy jMJCu5Zn+RW03g4OvoJ5T/MIy6nAf1OI2E8fftZTBtsyKclDRamLXoJQWKz6na8j+Wg8 OwiQ== X-Gm-Message-State: ALyK8tIoOFrIgulp9Nb9T54LajZkWs8fcLPhEbOUrQ2Dqet/NtcnZbcpbFZ8Tr4oi243CyX+UR97m1yKOG+l7g== X-Received: by 10.37.60.7 with SMTP id j7mr10183587yba.22.1467011534886; Mon, 27 Jun 2016 00:12:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.53.198 with HTTP; Mon, 27 Jun 2016 00:12:14 -0700 (PDT) In-Reply-To: <56678134-6E83-4CA0-914A-0A4420894481@dericed.com> References: <56678134-6E83-4CA0-914A-0A4420894481@dericed.com> From: Steve Lhomme Date: Mon, 27 Jun 2016 09:12:14 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Moritz Bunkus , cellar@ietf.org Subject: Re: [Cellar] deprecated elements? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 07:12:17 -0000 2016-06-27 0:20 GMT+02:00 Dave Rice : > Hi Steve, Moritz, or anyone who may know their Matroska history well, > > I'm working on element presentations and noticed some inconsistency in deprecated elements. > > TimeSlice is listed as deprecated in its description but doesn't list a maxver. So when was TimeSlice deprecated / what is the maxver of TimeSlice? According to archive.org It was there in the early specs and the text saying it's deprecated is in the v2 version specs. So I'd say deprecated since v2. We might even go as far as just removing it. I don't think anyone ever used this. > Same question for LaceNumber? Same as above. > OldStereoMode. I think I've asked about this before but it has a maxver of 0. Was there a Matroska version 0? Also the minver is 1, so this doesn't really make sense. Should maxver of OldStereoMode be 1? It's an experimental 3D mode that was introduced during v3 and dropped during v3 in 2011. > Some elements note as deprecated do list a maxver which implies when the deprecation happens. For instance TrackTimecodeScale is deprecated after version 3. > > Best Regards, > Dave Rice -- Steve Lhomme Matroska association Chairman From nobody Tue Jun 28 19:18:14 2016 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 D32F712D8A1 for ; Tue, 28 Jun 2016 19:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 wDRGYRhXSBog for ; Tue, 28 Jun 2016 19:18:11 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 D85D812B049 for ; Tue, 28 Jun 2016 19:18:10 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id s63so33763861ioi.3 for ; Tue, 28 Jun 2016 19:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1quKaNxKxZc1oEfUHlXWcRcuKeePx3u+ODVLygCox0s=; b=hFdNSBudqtuYq5SIVCW6do1PiWQ8Td6O8jMBD2WkDpiKRI/xP+0D52JIDAM5kHcEEf 2arekc196kDbSSVTauZ0K8y19zNcS4S0sM3Rjy2EPbiGNJqThamBSUAk9FVTSx9KkW6S ffR1mQIqbXJgnnGs04fUVAtLJ0QjWJAyp3tXSFFQuDyVFIEJCcyukfegW4DZ2CQMdm0O 5ZqFQaJSy8jiEcpX+UjvT5jhCgJ8sDYs8FmxeA/R7ks/GYHtFTA9QIimnTeCfcFUD3Y/ 1BctYYWguRMoxE3HqZfapXlu/2VBlxT3IBnN3TcPgytlF11AE/oEdmH3JConOsm1UdQZ ORZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1quKaNxKxZc1oEfUHlXWcRcuKeePx3u+ODVLygCox0s=; b=F3B6iZ5njmmIwEhmBVKo8XG90u9yB7oNMQUuknPtgkSa9ydvdvAYu8+LZdu6iA8fPM eDruCjzIUin8pa8XhvXdYuGF7/SGs7ec39x8KQrl2TwtHJDgD7PbVesGxbb1KScuuM5Z jv+Bg+XJm1n3gNnXhlWtpmYTLltkPpIl+gPdBq/7sHHnP3Zu4vOqi10ysqGIs2cjE3Sl XNP6ro+ZoGguo/8PAM2xoAPpHFlS5++FnXlGY4PtktbmJJN+oWdU3524pDxb5fmK3HNv Cbkl1hxrrvlQHpJO0IoEC2DSJxA4zBzotssXJm/KI5gW0ebXnzifV7o1g7oB85jfPktS ADEQ== X-Gm-Message-State: ALyK8tL2hKHV+GykeUkcHugv4bK2W/NMogj2F0fFOHEf9nj5TZh7nQunkybOVlQNg+crAeETkSduyY15U+Ui1g== X-Received: by 10.107.141.10 with SMTP id p10mr6755614iod.38.1467166690252; Tue, 28 Jun 2016 19:18:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.133.197 with HTTP; Tue, 28 Jun 2016 19:18:09 -0700 (PDT) In-Reply-To: <11CEAE32-1F69-4794-997D-24207F6D74CC@dericed.com> References: <11CEAE32-1F69-4794-997D-24207F6D74CC@dericed.com> From: Ashley Blewer Date: Tue, 28 Jun 2016 22:18:09 -0400 Message-ID: To: Dave Rice Content-Type: multipart/alternative; boundary=94eb2c05d1146626020536615de6 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] paper on Matroska and FFV1 standardization accepted for iPres X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 02:18:13 -0000 --94eb2c05d1146626020536615de6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all, Wanting to bump this original thread and also to thank Sebastian G. for the comments and feedback so far. Keep 'em coming! Looking forward to sharing CELLAR's work with the digital preservation community. Ashley Blewer On Sat, Jun 4, 2016 at 10:57 AM, Dave Rice wrote: > Hi all, > > I wanted to share news that a paper about Matroska and FFV1 > standardization that Ashley Blewer and I drafted was accepted into iPRES > 2016 which is an international conference on digital preservation to be > held in Bern, Switzerland in early October. Between now and the July 15th > deadline, we=E2=80=99ll expand and improve the paper for submitted. The c= urrent > working draft is available on Google Docs [2]. We=E2=80=99d like to crowd= -source > the paper so co-authoring, reviews, and suggestions are very welcome. > > Best Regards, > Dave Rice > > [1] http://www.ipres2016.ch/ > [2] > https://docs.google.com/document/d/1oH757ViN5YKUzVhsxxWhGnT2nJSkH8WRvzEpH= KzKGI4/edit?usp=3Dsharing --94eb2c05d1146626020536615de6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

Wanting to bump this origina= l thread and also to thank Sebastian G. for the comments and feedback so fa= r. Keep 'em coming! Looking forward to sharing CELLAR's work with t= he digital preservation community.

Ashley Blewer

On Sat,= Jun 4, 2016 at 10:57 AM, Dave Rice <dave@dericed.com> wrote:=
Hi all,

I wanted to share news that a paper about Matroska and FFV1 standardization= that Ashley Blewer and I drafted was accepted into iPRES 2016 which is an = international conference on digital preservation to be held in Bern, Switze= rland in early October. Between now and the July 15th deadline, we=E2=80=99= ll expand and improve the paper for submitted. The current working draft is= available on Google Docs [2]. We=E2=80=99d like to crowd-source the paper = so co-authoring, reviews, and suggestions are very welcome.

Best Regards,
Dave Rice

[1] http://www.ipres2016.ch/
[2] https://docs.google.com/document/d/1oH757ViN5YKUzVhsxxWhGnT2nJSkH8WRvzEpH= KzKGI4/edit?usp=3Dsharing

--94eb2c05d1146626020536615de6-- From nobody Wed Jun 29 12:34:52 2016 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 271C912DEC7 for ; Wed, 29 Jun 2016 12:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 19fuHHtaZ-zI for ; Wed, 29 Jun 2016 12:34:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E8912DEDA for ; Wed, 29 Jun 2016 12:34:47 -0700 (PDT) Received: from [192.168.178.25] ([91.3.228.144]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MZCQ8-1b1vMv1a7I-00KzK1 for ; Wed, 29 Jun 2016 21:34:45 +0200 To: cellar@ietf.org References: <54684B49-358B-4E32-A250-BD95C7EFEFDD@dericed.com> <914c29de-89a1-e505-64c6-07ddf34a07dc@gmx.ch> From: hubblec4 Message-ID: <3c922f4b-dd14-8acb-ce92-1399e7026b63@gmx.ch> Date: Wed, 29 Jun 2016 21:34:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <914c29de-89a1-e505-64c6-07ddf34a07dc@gmx.ch> Content-Type: multipart/alternative; boundary="------------A0620E0863CD78D0CE8B1B69" X-Provags-ID: V03:K0:ndVmMjQuLFEe5oOozQ/vCfVR5tYnguXXo/hwCOmCpLyOC88hdZG TzWAk41c/if/NHEJwclGQTAJEErvKFI2dWjtZ5Xx91uBZLpPJ2QS4l/oet1mjy1aE7fVwC5 aUITZomIgjRDt7pygzZ5TQd8YdYUtgeNde9kS5Ml80aQSSvJ2VFBBMZQG6Bv75W1dSoAnPt 9AqpHAS7F/aGhFAANfXWQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:rNmV4+XCaxc=:BENPReBX0y6DuDBGiZFB9M roTG4exYYHSbFzVNuRXMtKda+Cwwn5/D4BPtSRwAKABpGeiDHQE3JhAwW/BOGdmBQxzWM4x5K keDILYcJaMh5hDAI1flcXT3orxhqu2k0ls57dAyS0so5VnL8k8gvdJ9d28xt7pm9HJGZKBi0J 9hEVaGGZ5c1RPzzkeKaO9ROhLgLzJu4zn4sa+TfngoCH0ngWky2pjW4cOFUMSMtzRHydjRcfu ui71uEjayCmQdydT8iEbMjxWjiab5pkgq9QN+7H50RSQkRznzPzDNNMHBs5bbmW1ck6qsQ9T5 bhFdZ+CM4wZGbkW0EMbMWOjFAmVhgQ0csGpQSYq7YVO0D3fKvySXICuwGrHaJoUiknOQSccrp DyDZK7meGJxNJw7Tos5/3nOtKuduqrDwhVRhwy16jPd8k53g8dlV2qoXwN9MxDUyTJ1Lwq9dN 92F1ykcpMayrzFD+ZcMLX8z/qX/pj3p2RwYIffGM73oQmteV4rhfZdL6W7Oc/jfI7ASmGOdp/ aN866m8LAwrE4pu9g7KZUNAtysfK70rK4KrvxMODjxt8rU37OvKeLQtl7M4YldTOmRozl+m2j 3JZXhRjsVFFoPV+yHHTM37WFbd+JYXQt24myUn6hI578N3ql9nvWA0pJxC5s/L4+jJejUOIFL 73tJpsplMc4N+tN41IHojISc2LJiUO1+L7Rwi75PPn91/DCPgq3clWqr/IO7QLn1Dv37Pk9JR Fz/u8r7NkFXWpVCRBZM+GQcyV4hu7o/P5d1pL06jvEhtMKMi5xiG4MNVjzJmGJ1eUV4XcilFS v6Z07p9 Archived-At: Subject: Re: [Cellar] presentation of the Matroska schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 19:34:51 -0000 This is a multi-part message in MIME format. --------------A0620E0863CD78D0CE8B1B69 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi all I have discovered an inaccuracy at ChapterTimeStart/End element type. Type is "uinteger" that means 1, 2, 3, ond so on. But the time format looks like this 00:00:00.123456789. Exists an element type "Time"? Best Regards, Martin Below > > > Am 26.06.2016 um 04:05 schrieb Dave Rice: >> Hi all, >> >> I'm looking for feedback on how to present Matroska Elements in the specification. Currently the definitions of the Matroska elements are athttps://github.com/Matroska-Org/matroska-specification/blob/gh-pages/ebml_matroska.xml. This xml defines the elements as an EBML Schema which is defined in the EBML spec. Currently the human readable presentation of the Matroska Elements is in a big table athttps://matroska.org/technical/specs/index.html#LevelEBML. >> >> With the current displays of Matroska elements I think we have a few issues: >> >> - Only very sparse descriptions are used for the elements. I think a long description would be the table unwieldy. >> - The hierarchy of elements is hard to understand in the table (would have to scroll back up to the element of the lower level, with some exceptions for global elements). >> - This form of the table won't fit well into an RFC style document. >> >> >From the ebml_matroska.xml we have an XSL file that can convert it to an HTML table to replicate the existing presentation. I've been working on another XSL that converts the ebml_matroska.xml file into a markdown document which presents each element in its own table. A draft of the output is here:https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac. In this style of presentation there is more room per element so I added data to show the parent element, child element(s), and element in hierarchical context. Markdown like this could be used when at RFC is built. >> >> I think a markdown output of the matroska elements (with a table per element) also allows up to add more types of descriptions. For example in the ebml_matroska.xml, we currently only have one description, but this could be extended in order to have different types such as: >> - definition >> - rationale >> - usage notes >> - references (could optionally link to test files that demonstrate the element) >> >> Each element would require a definition (a short description) which would be used in outputs such ashttps://matroska.org/technical/specs/index.html#LevelEBML, but the markdown output for the RFC or more verbose displays of element data could include the additional descriptions. >> >> So I'd like feedback on: >> >> - impressions ofhttps://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac >> - is it worthwhile to add new data to element definitions such as rationale and usage notes? >> >> Best Regards, >> Dave Rice >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar --------------A0620E0863CD78D0CE8B1B69 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Hi all

I have discovered an inaccuracy at ChapterTimeStart/End element type.
Type is "uinteger" that means 1, 2, 3, ond so on.
But the time format looks like this 00:00:00.123456789.
Exists an element type "Time"?
 

Best Regards,
Martin Below


Am 26.06.2016 um 04:05 schrieb Dave Rice:
Hi all,

I'm looking for feedback on how to present Matroska Elements in the specification. Currently the definitions of the Matroska elements are at https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/ebml_matroska.xml. This xml defines the elements as an EBML Schema which is defined in the EBML spec. Currently the human readable presentation of the Matroska Elements is in a big table at https://matroska.org/technical/specs/index.html#LevelEBML.

With the current displays of Matroska elements I think we have a few issues:

- Only very sparse descriptions are used for the elements. I think a long description would be the table unwieldy.
- The hierarchy of elements is hard to understand in the table (would have to scroll back up to the element of the lower level, with some exceptions for global elements).
- This form of the table won't fit well into an RFC style document.

>From the ebml_matroska.xml we have an XSL file that can convert it to an HTML table to replicate the existing presentation. I've been working on another XSL that converts the ebml_matroska.xml file into a markdown document which presents each element in its own table. A draft of the output is here: https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac. In this style of presentation there is more room per element so I added data to show the parent element, child element(s), and element in hierarchical context. Markdown like this could be used when at RFC is built.

I think a markdown output of the matroska elements (with a table per element) also allows up to add more types of descriptions. For example in the ebml_matroska.xml, we currently only have one description, but this could be extended in order to have different types such as:
- definition
- rationale
- usage notes
- references (could optionally link to test files that demonstrate the element)

Each element would require a definition (a short description) which would be used in outputs such as https://matroska.org/technical/specs/index.html#LevelEBML, but the markdown output for the RFC or more verbose displays of element data could include the additional descriptions.

So I'd like feedback on:

- impressions of https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac
- is it worthwhile to add new data to element definitions such as rationale and usage notes?

Best Regards,
Dave Rice
_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

--------------A0620E0863CD78D0CE8B1B69-- From nobody Wed Jun 29 12:38:39 2016 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 0AE7912D68B for ; Wed, 29 Jun 2016 12:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 rs_0G8DYNBha for ; Wed, 29 Jun 2016 12:38:36 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 08DE612D665 for ; Wed, 29 Jun 2016 12:38:36 -0700 (PDT) Received: from [146.96.19.240] (port=26833 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bILJg-002Mvw-83; Wed, 29 Jun 2016 15:38:35 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_BD998768-8C1C-4C65-8EED-89259EB4E39C" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <3c922f4b-dd14-8acb-ce92-1399e7026b63@gmx.ch> Date: Wed, 29 Jun 2016 15:38:30 -0400 Message-Id: References: <54684B49-358B-4E32-A250-BD95C7EFEFDD@dericed.com> <914c29de-89a1-e505-64c6-07ddf34a07dc@gmx.ch> <3c922f4b-dd14-8acb-ce92-1399e7026b63@gmx.ch> To: hubblec4 X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] presentation of the Matroska schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 19:38:38 -0000 --Apple-Mail=_BD998768-8C1C-4C65-8EED-89259EB4E39C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jun 29, 2016, at 3:34 PM, hubblec4 wrote: >=20 > Hi all >=20 > I have discovered an inaccuracy at ChapterTimeStart/End element type. > Type is "uinteger" that means 1, 2, 3, ond so on. > But the time format looks like this 00:00:00.123456789. > Exists an element type "Time"? I suspect that it is uinteger, but that it uses nanoseconds as a unit of = measurement which the definition doesn't convey. The examples at = https://matroska.org/technical/specs/chapters/index.html use the 'ns' = unit of measurement for the examples, but a reference to the unit of = measurement should really be in the definition of usage notes of the = elements. Dave > Best Regards, > Martin Below >>=20 >>=20 >> Am 26.06.2016 um 04:05 schrieb Dave Rice: >>> Hi all, >>>=20 >>> I'm looking for feedback on how to present Matroska Elements in the = specification. Currently the definitions of the Matroska elements are at = https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/ebml_= matroska.xml = . This xml defines the elements as an EBML Schema which is = defined in the EBML spec. Currently the human readable presentation of = the Matroska Elements is in a big table at = https://matroska.org/technical/specs/index.html#LevelEBML = . >>>=20 >>> With the current displays of Matroska elements I think we have a few = issues: >>>=20 >>> - Only very sparse descriptions are used for the elements. I think a = long description would be the table unwieldy. >>> - The hierarchy of elements is hard to understand in the table = (would have to scroll back up to the element of the lower level, with = some exceptions for global elements). >>> - This form of the table won't fit well into an RFC style document. >>>=20 >>> >=46rom the ebml_matroska.xml we have an XSL file that can convert = it to an HTML table to replicate the existing presentation. I've been = working on another XSL that converts the ebml_matroska.xml file into a = markdown document which presents each element in its own table. A draft = of the output is here: = https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac = . In = this style of presentation there is more room per element so I added = data to show the parent element, child element(s), and element in = hierarchical context. Markdown like this could be used when at RFC is = built. >>>=20 >>> I think a markdown output of the matroska elements (with a table per = element) also allows up to add more types of descriptions. For example = in the ebml_matroska.xml, we currently only have one description, but = this could be extended in order to have different types such as: >>> - definition >>> - rationale >>> - usage notes >>> - references (could optionally link to test files that demonstrate = the element) >>>=20 >>> Each element would require a definition (a short description) which = would be used in outputs such as = https://matroska.org/technical/specs/index.html#LevelEBML = , but the = markdown output for the RFC or more verbose displays of element data = could include the additional descriptions. >>>=20 >>> So I'd like feedback on: >>>=20 >>> - impressions of = https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac = >>> - is it worthwhile to add new data to element definitions such as = rationale and usage notes? >>>=20 >>> Best Regards, >>> Dave Rice >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar = >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = --Apple-Mail=_BD998768-8C1C-4C65-8EED-89259EB4E39C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jun 29, 2016, at 3:34 PM, hubblec4 <hubblec4@gmx.ch> = wrote:

Hi all

I have discovered an = inaccuracy at ChapterTimeStart/End element type.
Type is = "uinteger" that means 1, 2, 3, ond so on.
But the time = format looks like this 00:00:00.123456789.
Exists an = element type "Time"?

I suspect that it is uinteger, but that it uses = nanoseconds as a unit of measurement which the definition doesn't = convey. The examples at https://matroska.org/technical/specs/chapters/index.html = use the 'ns' unit of measurement for the examples, but a reference to = the unit of measurement should really be in the definition of usage = notes of the elements.
Dave

Best Regards,
Martin Below


Am 26.06.2016 um 04:05 schrieb Dave Rice:
Hi all,

I'm looking for feedback on how to present Matroska Elements in the =
specification. Currently the definitions of the Matroska elements are at =
https://github.com/Matroska-Org/matroska-specificati=
on/blob/gh-pages/ebml_matroska.xml. This xml defines the elements as =
an EBML Schema which is defined in the EBML spec. Currently the human =
readable presentation of the Matroska Elements is in a big table at https:/=
/matroska.org/technical/specs/index.html#LevelEBML.

With the current displays of Matroska elements I think we have a few =
issues:

- Only very sparse descriptions are used for the elements. I think a =
long description would be the table unwieldy.
- The hierarchy of elements is hard to understand in the table (would =
have to scroll back up to the element of the lower level, with some =
exceptions for global elements).
- This form of the table won't fit well into an RFC style document.

>=46rom the ebml_matroska.xml we have an XSL file that can convert it =
to an HTML table to replicate the existing presentation. I've been =
working on another XSL that converts the ebml_matroska.xml file into a =
markdown document which presents each element in its own table. A draft =
of the output is here: =
https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac. In =
this style of presentation there is more room per element so I added =
data to show the parent element, child element(s), and element in =
hierarchical context. Markdown like this could be used when at RFC is =
built.

I think a markdown output of the matroska elements (with a table per =
element) also allows up to add more types of descriptions. For example =
in the ebml_matroska.xml, we currently only have one description, but =
this could be extended in order to have different types such as:
- definition
- rationale
- usage notes
- references (could optionally link to test files that demonstrate the =
element)

Each element would require a definition (a short description) which =
would be used in outputs such as https:/=
/matroska.org/technical/specs/index.html#LevelEBML, but the markdown =
output for the RFC or more verbose displays of element data could =
include the additional descriptions.

So I'd like feedback on:

- impressions of =
https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac
- is it worthwhile to add new data to element definitions such as =
rationale and usage notes?

Best Regards,
Dave Rice
_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org=
/mailman/listinfo/cellar

_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_BD998768-8C1C-4C65-8EED-89259EB4E39C-- From nobody Wed Jun 29 12:48:13 2016 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 64BA812D0BC for ; Wed, 29 Jun 2016 12:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 hanLu-Ukwuyu for ; Wed, 29 Jun 2016 12:48:09 -0700 (PDT) Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:151:7310::105:1]) (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 2B9B212B01C for ; Wed, 29 Jun 2016 12:48:09 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id CE3E83A64BC4; Wed, 29 Jun 2016 21:48:06 +0200 (CEST) Received: from sweet-chili.local (unknown [10.55.1.18]) by liselle.bunkus.org (Postfix) with ESMTPS id A2EEE3A64BBD for ; Wed, 29 Jun 2016 21:48:05 +0200 (CEST) Received: by sweet-chili.local (Postfix, from userid 1000) id 2FBF370D729; Wed, 29 Jun 2016 21:48:05 +0200 (CEST) Date: Wed, 29 Jun 2016 21:48:05 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160629194804.lgxprie6qgv2xa4x@bunkus.org> References: <54684B49-358B-4E32-A250-BD95C7EFEFDD@dericed.com> <914c29de-89a1-e505-64c6-07ddf34a07dc@gmx.ch> <3c922f4b-dd14-8acb-ce92-1399e7026b63@gmx.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3c922f4b-dd14-8acb-ce92-1399e7026b63@gmx.ch> User-Agent: Mutt/1.6.1-neo (2016-05-23) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] presentation of the Matroska schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 19:48:11 -0000 Hey, > I have discovered an inaccuracy at ChapterTimeStart/End element type. > Type is "uinteger" that means 1, 2, 3, ond so on. But the time format > looks like this 00:00:00.123456789. Exists an element type "Time"? There's no time type. ChapterTimeStart and End are stored as nanoseconds. However, for human consumption they're usually written as timestamps as that's easier to grasp. This also applies to mkvmerge's XML chapter file format. The on-disc storage is still a normal EBML unsigned integer, just like e.g. the number of audio channels in the track headers and countless other elements. I agree with Dave that this should be made clear(er). Kind regards, mosu From nobody Wed Jun 29 12:50:48 2016 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 610FC12B017 for ; Wed, 29 Jun 2016 12:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 OBqIJS1A5uMA for ; Wed, 29 Jun 2016 12:50:45 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 2851E12D1A7 for ; Wed, 29 Jun 2016 12:50:45 -0700 (PDT) Received: from [146.96.19.240] (port=14027 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bILVT-002TeG-4T; Wed, 29 Jun 2016 15:50:44 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <20160629194804.lgxprie6qgv2xa4x@bunkus.org> Date: Wed, 29 Jun 2016 15:50:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54684B49-358B-4E32-A250-BD95C7EFEFDD@dericed.com> <914c29de-89a1-e505-64c6-07ddf34a07dc@gmx.ch> <3c922f4b-dd14-8acb-ce92-1399e7026b63@gmx.ch> <20160629194804.lgxprie6qgv2xa4x@bunkus.org> To: Moritz Bunkus X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] presentation of the Matroska schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 19:50:46 -0000 > On Jun 29, 2016, at 3:48 PM, Moritz Bunkus wrote: >=20 > Hey, >=20 >> I have discovered an inaccuracy at ChapterTimeStart/End element type. >> Type is "uinteger" that means 1, 2, 3, ond so on. But the time = format >> looks like this 00:00:00.123456789. Exists an element type "Time"? >=20 > There's no time type. ChapterTimeStart and End are stored as > nanoseconds. However, for human consumption they're usually written as > timestamps as that's easier to grasp. This also applies to mkvmerge's > XML chapter file format. >=20 > The on-disc storage is still a normal EBML unsigned integer, just like > e.g. the number of audio channels in the track headers and countless > other elements. >=20 > I agree with Dave that this should be made clear(er). Is the concept of "unit of measurement" a prominent enough issue that it = should be its own attribute in element definitions? Or should units of = measurements simply be documented in the definition? Dave= From nobody Wed Jun 29 12:58:58 2016 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 7A3DE12D550 for ; Wed, 29 Jun 2016 12:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 mUNwpV385kwe for ; Wed, 29 Jun 2016 12:58:55 -0700 (PDT) Received: from liselle.bunkus.org (liselle.bunkus.org [176.9.119.9]) (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 EFC2512D513 for ; Wed, 29 Jun 2016 12:58:54 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 408C53A64DE6; Wed, 29 Jun 2016 21:58:53 +0200 (CEST) Received: from sweet-chili.local (unknown [10.55.1.18]) by liselle.bunkus.org (Postfix) with ESMTPS id 1B23C3A64DE0 for ; Wed, 29 Jun 2016 21:58:52 +0200 (CEST) Received: by sweet-chili.local (Postfix, from userid 1000) id 98E6370D75F; Wed, 29 Jun 2016 21:58:51 +0200 (CEST) Date: Wed, 29 Jun 2016 21:58:51 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160629195851.nuxjvapwgiwx2rur@bunkus.org> References: <54684B49-358B-4E32-A250-BD95C7EFEFDD@dericed.com> <914c29de-89a1-e505-64c6-07ddf34a07dc@gmx.ch> <3c922f4b-dd14-8acb-ce92-1399e7026b63@gmx.ch> <20160629194804.lgxprie6qgv2xa4x@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.1-neo (2016-05-23) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] presentation of the Matroska schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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 Jun 2016 19:58:56 -0000 Hey, > Is the concept of "unit of measurement" a prominent enough issue that > it should be its own attribute in element definitions? Or should units > of measurements simply be documented in the definition? My 2c: It should simply be part of the human-readable documentation, I think. I don't see big advantages in declaring them as attributes, especially for elements where other elements determine the actual unit (e.g. DisplayUnit for DisplayWidth/DisplayHeight). Declaraing that as machine-readable attributes is probably more work than it's worth. Just state something like "the chapter's start time in ns, relative to the beginning of the segment". The notes could then also mention that the preferred form of display for human consumption is some kind of timestamp format instead of the raw number (similar to how sampling frequencies are often written as 48 kHz instead of 48000 – it's just way more obvious and useful in the case of timestamps vs. ns). Kind regards, mosu From nobody Wed Jun 29 20:02:32 2016 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 343C212D19E for ; Wed, 29 Jun 2016 20:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 v4QyQpi-_HOL for ; Wed, 29 Jun 2016 20:02:26 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 8D45812D11D for ; Wed, 29 Jun 2016 20:02:26 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:43646 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bISFC-000VXu-6u; Wed, 29 Jun 2016 23:02:25 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: <4B30F339-4196-4268-8FF1-019024D777D3@dericed.com> Date: Wed, 29 Jun 2016 23:02:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7531D4FD-B64C-4019-90A7-60C4D55F0353@dericed.com> References: <5CBBD1F2-E4D4-4453-B74E-BC854B3F673D@dericed.com> <57638C5E.90506@xiph.org> <286C62FD-3073-487F-AD1A-A81CC2C3D6D6@dericed.com> <5764156D.40100@xiph.org> <4B30F339-4196-4268-8FF1-019024D777D3@dericed.com> To: cellar@ietf.org X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Tessa Fallon , rjsparks@nostrum.com, "Timothy B. Terriberry" Subject: Re: [Cellar] An attempt at EBML specification in RFC form X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 03:02:30 -0000 Hi all, > On Jun 20, 2016, at 9:50 AM, Dave Rice wrote: >=20 >> On Jun 17, 2016, at 11:21 AM, Timothy B. Terriberry = wrote: >>=20 >> Dave Rice wrote: >>> Steve, Moritz, other, specific suggestions for EBML authorship? = Leave as Steve alone, add other working group members? >>=20 >> Given the way you've been acting in capacity as editor thus far, I'd = suggest you might want to consider adding yourself. >=20 > The PR is updated to add my name. = https://github.com/Matroska-Org/ebml-specification/pull/66 I=E2=80=99ve submitted another pull request to change formatting to fix = some of the issues with the RFC draft for EBML. The pr is reviewable = here: https://github.com/Matroska-Org/ebml-specification/pull/70. It=E2=80= =99s mostly adjustments to the presentation of tables and indentation as = well as a few fixes to follow RFC2119 more accurately. The new draft output of the makefile is here: = https://gist.github.com/dericed/3ecc06cbc9abdeb3464f2c7d68d7b1ac When I run the document through https://www.ietf.org/tools/idnits I get = these error messages. Apparently some of the table of content numbering = doesn=E2=80=99t follow recommended ip range recommendations. idnits 2.14.01=20 /tmp/draft-lhomme-cellar-ebml-00.txt: /tmp/draft-lhomme-cellar-ebml-00.txt(859): Found possible IPv4 address = '1.11.1.6' in position 38; this doesn't match the suggested = documentation address ranges specified in RFC 6890 (or successor): = blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and = 203.0.113.0/24 (TEST-NET-3); or the 233.252.0.0/24 (MCAST-TEST-NET) = example multicast address range specified in RFC 5771. /tmp/draft-lhomme-cellar-ebml-00.txt(904): Found possible IPv4 address = '1.11.1.4' in position 38; this doesn't match the suggested = documentation address ranges specified in RFC 6890 (or successor): = blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and = 203.0.113.0/24 (TEST-NET-3); or the 233.252.0.0/24 (MCAST-TEST-NET) = example multicast address range specified in RFC 5771. Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): = --------------------------------------------------------------------------= -- No issues found here. Checking nits according to = http://www.ietf.org/id-info/1id-guidelines.txt: = --------------------------------------------------------------------------= -- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : = --------------------------------------------------------------------------= -- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See = Section 2.2 of http://www.ietf.org/id-info/checklist for how to handle the = case when there are no actions for IANA.) ** The document seems to lack separate sections for = Informative/Normative References. All references will be assumed normative when checking = for downward references. =3D=3D There are 2 instances of lines with non-RFC6890-compliant IPv4 = addresses in the document. If these are example addresses, they should be = changed. Miscellaneous warnings: = --------------------------------------------------------------------------= -- =3D=3D Using lowercase 'not' together with uppercase 'MUST', 'SHALL', = 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. = Please use uppercase 'NOT' together with RFC 2119 keywords (if that is = what you mean). =20 Found 'MUST not' in this paragraph: =20 As an XML Document, the EBML Schema MUST use "" as the top level element. The "" element MAY contain = "" sub-elements. Each "" defines one EBML Element through = the use of several attributes which are defined in the section on Section 1.11.1.1. EBML Schemas MAY contain additional attributes to extend = the semantics but MUST not conflict is the definitions of the = "" attributes defined within this specification. =3D=3D Couldn't figure out when the document was first submitted -- = there may comments or warnings related to the use of a disclaimer for = pre-RFC5378 work that could not be issued because of this. Please check the = Legal Provisions document at http://trustee.ietf.org/license-info to = determine if you need the pre-RFC5378 disclaimer. Checking references for intended status: Proposed Standard = --------------------------------------------------------------------------= -- (See RFCs 3967 and 4897 for information about using normative = references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1116 looks like a reference '[1] https://tools.ietf.org/html/rfc2119...' -- Missing reference section? '2' on line 1118 looks like a reference '[2] http://www.faqs.org/rfcs/rfc2279.html...' -- Missing reference section? '3' on line 1120 looks like a reference '[3] http://www.w3.org/XML/Schema#dev...' -- Missing reference section? '4' on line 1122 looks like a reference '[4] http://www.w3.org/TR/xml/...' -- Missing reference section? '5' on line 1124 looks like a reference '[5] http://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-decl...' -- Missing reference section? '6' on line 1126 looks like a reference '[6] https://www.w3.org/TR/xmlschema-0/#ref6...' -- Missing reference section? '7' on line 1128 looks like a reference '[7] https://www.w3.org/TR/xmlschema-0/#ref6...' -- Missing reference section? '8' on line 1130 looks like a reference '[8] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf...' -- Missing reference section? '1A' on line 954 looks like a reference '| EBML ID | [1A][45][DF][A3]...' -- Missing reference section? '45' on line 954 looks like a reference '| EBML ID | [1A][45][DF][A3]...' -- Missing reference section? 'DF' on line 954 looks like a reference '| EBML ID | [1A][45][DF][A3]...' -- Missing reference section? 'A3' on line 954 looks like a reference '| EBML ID | [1A][45][DF][A3]...' -- Missing reference section? '42' on line 1059 looks like a reference '| EBML ID | [42][85]...' -- Missing reference section? '86' on line 968 looks like a reference '| EBML ID | [42][86]...' -- Missing reference section? 'F7' on line 981 looks like a reference '| EBML ID | [42][F7]...' -- Missing reference section? 'F2' on line 995 looks like a reference '| EBML ID | [42][F2]...' -- Missing reference section? 'F3' on line 1010 looks like a reference '| EBML ID | [42][F3]...' -- Missing reference section? '82' on line 1032 looks like a reference '| EBML ID | [42][82]...' -- Missing reference section? '87' on line 1045 looks like a reference '| EBML ID | [42][87]...' -- Missing reference section? '85' on line 1059 looks like a reference '| EBML ID | [42][85]...' -- Missing reference section? 'BF' on line 1075 looks like a reference '| EBML ID | [BF]...' -- Missing reference section? 'EC' on line 1101 looks like a reference '| EBML ID | [EC]...' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (=3D=3D), 22 = comments (--). Best Regards, Dave Rice From nobody Wed Jun 29 22:56:10 2016 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 BA00512D90A for ; Wed, 29 Jun 2016 22:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 mZ9HasZg_Lx7 for ; Wed, 29 Jun 2016 22:56:08 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 63E2612D61C for ; Wed, 29 Jun 2016 22:56:08 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:46965 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bIUxJ-000I5I-By; Thu, 30 Jun 2016 01:56:07 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jun 2016 01:56:03 -0400 Message-Id: <4CEAF2BB-CC50-44A8-8E4A-CBDBA24813FF@dericed.com> To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: hubblec4@gmx.ch Subject: [Cellar] Matroska Info section questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 05:56:09 -0000 Hi all, I=E2=80=99m prepping to revise/extend some of the Elements in the Info = section and have a few questions. There are three filename elements here: SegmentFilename, PrevFilename, = and NextFilename. The latter two should be escaped but the first = doesn=E2=80=99t reference escaping. I think this is a mistake and that = all three are intended to be escaped, right? In these filename definitions, there is language like "An escaped = filename corresponding to the previous Segment.=E2=80=9D which seems to = infer that file has one segment and a segment has one file. However, the = previous segment could be within the same file. Is it valid to have a = Matroska file with 2 segments, where they have distinct UIDs but share = values for SegmentFilename and Prev/Next Filename? Is it valid for SegmentUID to equal PrevUID or SegmentUID to equal = NextUID? Maybe to loop the content? Any good reference to define filename escaping? Similar to the 3 filename elements, there are also three UIDs, = SegmentUID, PrevUID and NextUID, to chain Segments. There=E2=80=99s some = opportunity for conflict here (between UIDs and Filenames). Should we = say that the UIDs are more authoritative at chaining than filenames? Also can the Next/PrevUID refer to other Segments within the same file? Is it safe to presume that NextUID and PrevUID are ignorable if = SegmentFamily is not used? SegmentUID is not generally mandated, but is it a mandate if the Segment = is chained? IIUC, chained Segments represent content that should be presented = sequentially (ie. play a.mkv then b.mkv then c.mkv), but are there other = kinds of relationships between chained Segments? Such as a video-only = mkv and an audio-only mka chained together to play simultaneously? Must chained Segments share a continuous segmented timecode? For = instance if seeking in a segment before the earlier timecode, should the = player switch to the prior chained segment? If there an authoritative way to tell is a Segment is part of a chain or = not? The presence of SegmentFamily alone? Duration is measured in nanoseconds, right? Or is the duration measured = in 1/TimecodeScale? The definition of DateUTC is unclear to me. It states: "Date of the = origin of timestamp (value 0), i.e. production date.=E2=80=9D Origin of = the content, the matroska file? If I have a newly made Matroska file of = a rip of a 2005 DVD of The Wizard of Oz, should I put 1939 (the = production date of The Wizard of Oz), or 2005 (the production date of = the DVD) or 2016 (the production date of the Matroska file)? TimecodeScale. I seem to remember some issues here, where some prominent = players do not support non-1000000 scales? What recommendations should = we make here. Should non-1000000 values be avoided in some circumstances = but not others? The DateUTC has nanosecond accuracy, but what should be done if the = timestamp available is less precise than needed. Just presume 0=E2=80=99s?= Muxing and Writing Apps. I can add in some recommendations to say the = name of the application/library followed by the version. Any other = particular practice to recommend here? I don=E2=80=99t really understand the ChapterTranslate elemental = structure well. Martin Below, could you review these. Title. Any particular recommendations or practices here? Best Regards, Dave Rice= From nobody Thu Jun 30 05:28:28 2016 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 E0CF612D0AC for ; Thu, 30 Jun 2016 05:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 XXVONFvqO8aU for ; Thu, 30 Jun 2016 05:28:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D630E12B00A for ; Thu, 30 Jun 2016 05:28:23 -0700 (PDT) Received: from [192.168.178.25] ([91.3.229.165]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lk7T8-1buh3O1XbO-00c9fN for ; Thu, 30 Jun 2016 14:28:20 +0200 To: cellar@ietf.org References: <4CEAF2BB-CC50-44A8-8E4A-CBDBA24813FF@dericed.com> From: hubblec4 Message-ID: <2bec0e81-d04b-b76c-b8aa-a42cd9ee4c2b@gmx.ch> Date: Thu, 30 Jun 2016 14:28:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <4CEAF2BB-CC50-44A8-8E4A-CBDBA24813FF@dericed.com> Content-Type: multipart/alternative; boundary="------------FFA4F1201974C5C26F6E5310" X-Provags-ID: V03:K0:KZEQnuKw1yBi51wbRg3OH1sqilpE04FcrHXC3Cf1zrUvmXP6RK0 5bIxvgx7G3gKtzPpCgyTUVL2bz2NEHWr5/8mvvQ2ZoIdzoYhzuqmodc4vsd6xG/zmjptRbX i1bI8jV8b8wjzEztvle359NnWkEbUnyLHhG6BNxGbjjrZ5am6x6k8K8cSA14LCNFrO3xQH/ 0D96mvK131W30Z/D1YkmQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:3pNyTa+dofk=:4MW17lI1F15k5IOkfVXKhD 6qk2MYuqdyL2Z+I509BX0Yq5PFB16gPCz8x7gBQkYyy6Fl8vElQ4dC1JXK5aMs89XRq5Fyo7B ECMzZX9D20ayOm9E1olq/+hevuyZyUnFU4m5ZpNGSHSt9L8AmhAP5rj28t6HL3Ws8m466cBCO jk+N9h+ApzaZ2HvqMSid18OWjga20h7Sni6QgIbemcbTtjD/eRhVGakfdhEbD063a4f+3bFyo nWgKLwPOauZ8r+68CviVXDBOnWkBKpwC2pd683jDHeWUlJS+NsoCVLJ4y7wKOZoP8szjz+5QX uDEyhd/jqRoq+UR1aB/9F3TSvJprC/9xT8Pj57d/V5i4kHxdtPq2rdh2EvKaaWgTFwQRwH5Qt d3FEtw1BZYJmc2BVEV49ZJhAvs1SdUqL5qIw8ux6Dquudk3U70n01qku10XwT9PYxwVh4WWIx BBH9WQltrLO4emceqeW5U00RXqoAkQHCyVqVW9DvJS5bu3nQnchGUl6iDRTRY4vfs56piJGlC tqifKk0M4UesG9el6sQzy4IgeuVluUQFUwxwNxUQBgmURa/D8VMI22vJjv2NJkUMQIUR9GLIu adXlK0WDpbuRIxGVkJ82Dg82GkqUZ0XV0KTswL922iUQQnrySpKoV5ERH/TT1HmhnjN97KljK r/F0FsgZpg0hbICsG9RKNTY8jXxzFop8rJpSl78dAyazPSili6Fio7dCsNnYIdHnXl2zWGIHa wOY95gVgzr/bd83BfFa9XA/n/99S/kNwkJ6NBgn/5i64Ttb6CMfTYPjUU3kcnEaHKljJ4vNZW TH4dHzS Archived-At: Subject: Re: [Cellar] Matroska Info section questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 12:28:27 -0000 This is a multi-part message in MIME format. --------------FFA4F1201974C5C26F6E5310 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Am 30.06.2016 um 07:56 schrieb Dave Rice: > In these filename definitions, there is language like "An escaped filename corresponding to the previous Segment.” which seems to infer that file has one segment and a segment has one file. However, the previous segment could be within the same file. Is it valid to have a Matroska file with 2 segments, where they have distinct UIDs but share values for SegmentFilename and Prev/Next Filename? That is indeed a good question. My first thought is that one segment means one file and vice versa. > Is it valid for SegmentUID to equal PrevUID or SegmentUID to equal NextUID? Maybe to loop the content? That will be a question of the ability of a splitter. The loop will be infinity, how and when break the player/splitter this loop? > Similar to the 3 filename elements, there are also three UIDs, SegmentUID, PrevUID and NextUID, to chain Segments. There’s some opportunity for conflict here (between UIDs and Filenames). Should we say that the UIDs are more authoritative at chaining than filenames? Yes of course, an UID should have a higer valence. A filename is easy to change by the user, and then are all linkings break. The UID's are not so easy to manipulate. > Also can the Next/PrevUID refer to other Segments within the same file? If are allowed more then one segement per file then I think it should be possible. > Is it safe to presume that NextUID and PrevUID are ignorable if SegmentFamily is not used? The usage of SegementFamily is not really clear for me. For what is this used? The element can be present multiple times, but for which Segments then applies the respective SegementFamily? > SegmentUID is not generally mandated, but is it a mandate if the Segment is chained? I think yes. > IIUC, chained Segments represent content that should be presented sequentially (ie. play a.mkv then b.mkv then c.mkv), but are there other kinds of relationships between chained Segments? Such as a video-only mkv and an audio-only mka chained together to play simultaneously? Is that really possible to combine a video-only and an audio-only mkv to play simultaneously? Sounds for me not really as a "chaining", more like a "combining". Again a question of the splitter/player. > Must chained Segments share a continuous segmented timecode? For instance if seeking in a segment before the earlier timecode, should the player switch to the prior chained segment? I thought that's is a normal behaviour. > If there an authoritative way to tell is a Segment is part of a chain or not? The presence of SegmentFamily alone? If SegementFamily tell us the Segment is part of a chain, then is this good enough. > Duration is measured in nanoseconds, right? Or is the duration measured in 1/TimecodeScale? I think it is 1/TimecodeScale. I hope we can have nanoseconds precessions in future. I asked Mosu a lot of doing this, but the answer was/is that is not possible at the monent. > I don’t really understand the ChapterTranslate elemental structure well. > Martin Below, could you review these. I must confess that I did not understand 100%. The ChapterTranslate element structure looks like the ChapterProcess element structure. And then it all depends on whether you use, Matroska script (ChapterProcessCodecID = 0 (default)) or DVDcommand set (ChapterProcessCodecID = 1). If you use DVD command set for a chapter, you can specify the DVD-level equivalent. Example: 30 80 00 01 means Video Title Set (VTS) on Level 1 28 00 01 01 means Title TTU 1 on Level 2 20 00 01 00 00 40 00 00 means PGC PGC_1 type 0x00 = Basic PGC on Level 3 and so on. But to specify an edition you must use ChapterTranslate. ChapterTranslateEditionUID defines corresponding to the edition. (I think thats clear) ChapterTranslateCodec is the same like ChapterProcessCodecID. Only at the moment a value of 1 makes sense. ChapterTranslateID is the same like ChapterProcessPrivate Example: 00 00 means Video Manager (VMG) This is a topic of Matroska menu, there are no ways to test it and the documentations are very rare. If you use DVD-Menu you need a lot of knowledge about the structure and then the interpretation for Matroska. I have try to figure out how this works and I think I understand ca.60% . On the other hand we could use Matroska script to build better/simpler menu structures (clearly defined). At the moment exists only one command "|GotoAndPlay( ChapterUID );|". We could create new commands, simple and good documented. Segement-Linking: The linking via the info-elements (Prev/Next) is more than complicate and unflexible. If you use Filename-linking and the user changed the file names, linking breaks. The linking works in/as "a row" only. That means: a.mkv then b.mkv then c.mkv (or b-a-c) and so on. Ever the whole segment/mkv is played in the chain. The Segement-Linking via Chapters is easier and more flexible. You must not enter Prev/Next UID's. Only the segmentID is used. Linking parts of a segment is possible! (a_part1.mkv > b_part1.mkv > a_part2.mkv > b_part2.mkv) Best Regards Martin Below --------------FFA4F1201974C5C26F6E5310 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



Am 30.06.2016 um 07:56 schrieb Dave Rice:
In these filename definitions, there is language like "An escaped filename corresponding to the previous Segment.” which seems to infer that file has one segment and a segment has one file. However, the previous segment could be within the same file. Is it valid to have a Matroska file with 2 segments, where they have distinct UIDs but share values for SegmentFilename and Prev/Next Filename?
That is indeed a good question. My first thought is that one segment means one file and vice versa.

Is it valid for SegmentUID to equal PrevUID or SegmentUID to equal NextUID? Maybe to loop the content?
That will be a question of the ability of a splitter. The loop will be infinity, how and when break the player/splitter this loop? 

Similar to the 3 filename elements, there are also three UIDs, SegmentUID, PrevUID and NextUID, to chain Segments. There’s some opportunity for conflict here (between UIDs and Filenames). Should we say that the UIDs are more authoritative at chaining than filenames?
Yes of course, an UID should have a higer valence. A filename is easy to change by the user, and then are all linkings break. The UID's are not so easy to manipulate.

Also can the Next/PrevUID refer to other Segments within the same file?
If are allowed more then one segement per file then I think it should be possible. 
Is it safe to presume that NextUID and PrevUID are ignorable if SegmentFamily is not used?
The usage of SegementFamily is not really clear for me. For what is this used? The element can be present multiple times, but for which Segments then applies the respective SegementFamily?

 
SegmentUID is not generally mandated, but is it a mandate if the Segment is chained?
I think yes.

IIUC, chained Segments represent content that should be presented sequentially (ie. play a.mkv then b.mkv then c.mkv), but are there other kinds of relationships between chained Segments? Such as a video-only mkv and an audio-only mka chained together to play simultaneously?
Is that really possible to combine a video-only and an audio-only mkv to play simultaneously? Sounds for me not really as a "chaining", more like a "combining".
Again a question of the splitter/player.

Must chained Segments share a continuous segmented timecode? For instance if seeking in a segment before the earlier timecode, should the player switch to the prior chained segment?
I thought that's is a normal behaviour.

If there an authoritative way to tell is a Segment is part of a chain or not? The presence of SegmentFamily alone?
 If SegementFamily tell us the Segment is part of a chain, then is this good enough.

Duration is measured in nanoseconds, right? Or is the duration measured in 1/TimecodeScale?
I think it is 1/TimecodeScale. I hope we can have nanoseconds precessions in future. I asked Mosu a lot of doing this,
but the answer was/is that is not possible at the monent.

I don’t really understand the ChapterTranslate elemental structure well.
Martin Below, could you review these.
I must confess that I did not understand 100%.
The ChapterTranslate element structure looks like the ChapterProcess element structure.
And then it all depends on whether you use, Matroska script (ChapterProcessCodecID = 0 (default)) or DVD command set (ChapterProcessCodecID = 1).
If you use DVD command set for a chapter, you can specify the DVD-level equivalent.
Example:
<ChapterProcessPrivate format="hex">30 80 00 01</ChapterProcessPrivate> means Video Title Set (VTS) on Level 1
<ChapterProcessPrivate format="hex">28 00 01 01</ChapterProcessPrivate> means Title TTU 1 on Level 2
<ChapterProcessPrivate format="hex">20 00 01 00 00 40 00 00</ChapterProcessPrivate> means
PGC PGC_1 type 0x00 = Basic PGC on Level 3
and so on.

But to specify an edition you must use ChapterTranslate.
ChapterTranslateEditionUID defines corresponding to the edition. (I think thats clear)
ChapterTranslateCodec is the same like ChapterProcessCodecID. Only at the moment a value of 1 makes sense.
ChapterTranslateID is the same like ChapterProcessPrivate
Example:
<ChapterTranslateID format="hex">00 00</ChapterTranslateID> means Video Manager (VMG)

This is a topic of Matroska menu, there are no ways to test it and the documentations are very rare.
If you use DVD-Menu you need a lot of knowledge about the structure and then the interpretation for Matroska.
 I have try to figure out how this works and I think I understand ca.60% . On the other hand we could use Matroska script to build better/simpler menu structures (clearly defined).
At the moment exists only one command "GotoAndPlay( ChapterUID );".
We could create new commands, simple and good documented.



Segement-Linking:
The linking via the info-elements (Prev/Next) is more than complicate and unflexible.
If you use Filename-linking and the user changed the file names, linking breaks.
The linking works in/as "a row" only. That means: a.mkv then b.mkv then c.mkv (or b-a-c) and so on.
Ever the whole segment/mkv is played in the chain.

The Segement-Linking via Chapters is easier and more flexible.
You must not enter Prev/Next UID's. Only the segmentID is used.
Linking parts of a segment is possible! (a_part1.mkv > b_part1.mkv > a_part2.mkv > b_part2.mkv)

Best Regards
Martin Below
--------------FFA4F1201974C5C26F6E5310-- From nobody Thu Jun 30 10:29:14 2016 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 3163A12B01F for ; Thu, 30 Jun 2016 10:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 G24AJauktRj6 for ; Thu, 30 Jun 2016 10:29:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5580512D96F for ; Thu, 30 Jun 2016 10:29:01 -0700 (PDT) Received: from [192.168.2.129] ([146.60.197.26]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MSv6D-1aqrUc0eur-00RowR for ; Thu, 30 Jun 2016 19:28:59 +0200 To: cellar@ietf.org References: <4CEAF2BB-CC50-44A8-8E4A-CBDBA24813FF@dericed.com> <2bec0e81-d04b-b76c-b8aa-a42cd9ee4c2b@gmx.ch> From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <47d8c9ad-6e6c-9644-7b34-89189365f4ea@gmx.de> Date: Thu, 30 Jun 2016 19:28:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <2bec0e81-d04b-b76c-b8aa-a42cd9ee4c2b@gmx.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:k/rKGfSybNv7MLJLXLiKVAhUg5AslkcqRj61c59VRz6RumW13VO 40d0R8tmw6AdfzGFGgGSd9nQClnw+YGEkC1sfWSxc/IpXsUE5OmIsVO9FvO5BEk/VYw4TSY 6r1jeQA0JidwjeU5PmMABf5K8DS3qTHclrWzDAa0Pn+bZS7WBbAy0XKNTPmww+gS7Gmm4tj eHztnkxDGZFKJ3j+uKP8A== X-UI-Out-Filterresults: notjunk:1;V01:K0:oi1YK//GkpQ=:eKP73sXrBo4yBj5ZwjFaUy Xtz1gLG4wYdrHDFKNpnazeCaKbFAYVBBk+MT8T1lySobadK9ygIm1kW62AxtLTkBF5BhGd67B s36eR7lYGhvmdkm/Jf2ejDQPhjToAvlJFOgAP7qk2ueidhzt29dJvV4v1ZGHnu7/42XRSGxIu WSpYb6oNXc9iMzCTqingAfKonHpSicR5PEH5KxBl6HFiNiDIGI4vWghA8dzjjM+U6btFLQea2 zOe9Y+wQVokm3eEkU1q+OjDRn+WLObh4ZwOnIlup8MzZdta8kJaBUBeO8H378FvvRBFyohrdW MN+02+yRmvup2sFxpqt997rqluhqe+w7xcOUrv+A+RE16tlx+Vx9EA1NMZUykzHv11ITnaIpq BM7hG/YYQ2bdgnf7I4IHWcTm3Ns8abPb9BEd2tUNQWhFhR8a5ibpZ2UAvaD+4WRWKBhtkuNTg EMe+RDdSBthcS1MD0Q32ML47yHD/yC+pNh1OcHwB0+4+XZExhVnAq0VBLQTJK7yMMdYX3e+F1 onbju01rrYRYqt/UlKjxmtWd4QJnw3ZBkeZ+aeGidQP4vT6an0xfzxqWCV8iofZRFyLB9SEwa Ehz77AVX3Cf5cCzEZ4wk5eldi7lSNtYmhkDzUsf+aPXo5fpNkIcuFM+QlolusQ7SgDK5lpg8k bSPSj+lFvuuVh8GW9iLPQHepuLOdtzrkYkVcpkqijTmCC+bk88BS6kwDobUtnKcPnZQuQWLyn RhN4zzKioijXSI12gfXRZYfPMnKa70xIQoaEfHHeFni37Q/71yXTrH+xN+N5DAWLKkdOdR+nS rR5ZOs1 Archived-At: Subject: Re: [Cellar] Matroska Info section questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 17:29:12 -0000 30.06.2016, 14:28 hubblec4: > >> Similar to the 3 filename elements, there are also three UIDs, >> SegmentUID, PrevUID and NextUID, to chain Segments. Theres some >> opportunity for conflict here (between UIDs and Filenames). Should we >> say that the UIDs are more authoritative at chaining than filenames? > Yes of course, an UID should have a higer valence. A filename is easy to > change by the user, and then are all linkings break. The UID's are not > so easy to manipulate. +1 The chance of having UIDs collide is very low; having the user tamper with the file name bears a much higher risk. >> SegmentUID is not generally mandated, but is it a mandate if the >> Segment is chained? > I think yes. +1 If you want to use it as reference it has to be included. When there is linking/chaining than it should be mandatory. >> IIUC, chained Segments represent content that should be presented >> sequentially (ie. play a.mkv then b.mkv then c.mkv), but are there >> other kinds of relationships between chained Segments? Such as a >> video-only mkv and an audio-only mka chained together to play >> simultaneously? > Is that really possible to combine a video-only and an audio-only mkv to > play simultaneously? Sounds for me not really as a "chaining", more like > a "combining". > Again a question of the splitter/player. Wouldn't anyone mux a audio-only and a video only file to get a mkv that contains both, the video stream and the audio stream. Players are supposed to handle such files as they are ordinary files. Otherwise it might be hugely complex. (Don't get me wrong there are video players that allow to load a different audio file to play it along with the video.) I'm not sure if the intro/ending case is still valid for current seasons of any series, but the potential use was to encode the intro and the ending once. So that one has: a.mkv (intro) then b.mkv (episode1) then c.mkv (ending) a.mkv (intro) then d.mkv (episode2) then c.mkv (ending) a.mkv (intro) then e.mkv (episode3) then c.mkv (ending) >> Must chained Segments share a continuous segmented timecode? For >> instance if seeking in a segment before the earlier timecode, should >> the player switch to the prior chained segment? > I thought that's is a normal behaviour. I also assumed that this would be the standard behavior. If a player/splitter finds all parts (a.mkv b.mkv c.mkv) and I am seeking backwards from b.mkv up to a point where b.mkv would not contain any data I'd expect it to load the a.mkv to continue seeking. In other words if there are segments that are linked I expect the player to treat all segments as one file. If I tell the player to jump to 1m20s and that is located in a.mkv i expect it to go there. (On the other hand if only b.mkv is present and I want to jump to 1m20s it should use only b.mkv as reference and jump to 1m20s of that file.) >> If there an authoritative way to tell is a Segment is part of a chain >> or not? The presence of SegmentFamily alone? > If SegementFamily tell us the Segment is part of a chain, then is this > good enough. IIRC it is not possible to say in which position a part is, just by looking at the part (beside the start and the end, which lack either a previous segment or a following segment). I'm unaware of any authoritative way to tell if a segment is a part of a chain. Best Regards, Sebastian From nobody Thu Jun 30 11:13:54 2016 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 ABE2412DABA for ; Thu, 30 Jun 2016 11:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 LCZn25ROClgN for ; Thu, 30 Jun 2016 11:13:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0FF012D08F for ; Thu, 30 Jun 2016 11:13:41 -0700 (PDT) Received: from [192.168.178.25] ([91.3.229.165]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MaqeA-1b3mDR16oU-00KMWN for ; Thu, 30 Jun 2016 20:13:39 +0200 To: cellar@ietf.org References: <4CEAF2BB-CC50-44A8-8E4A-CBDBA24813FF@dericed.com> <2bec0e81-d04b-b76c-b8aa-a42cd9ee4c2b@gmx.ch> <47d8c9ad-6e6c-9644-7b34-89189365f4ea@gmx.de> From: hubblec4 Message-ID: Date: Thu, 30 Jun 2016 20:13:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <47d8c9ad-6e6c-9644-7b34-89189365f4ea@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:dY3Dh3WFo1aKGMjzUJslVzEKy29qfx4ya2/tqKtVL9s3K4xD+2u 40OSUBGpEVG+9ON8wuHs1hvAPRqWAw+tBIwvBBXG1LN2DbMiWPhWW5bwCstIUqLcD1sGegt CiTezoIMeSRCInF/+TSjOuUWltSmV9mdb8rqn/+EyNaYCXfKsZEirKhG2gnEPB8BuHd+UCy I2wTTgmzQhMP4VEvbCbkg== X-UI-Out-Filterresults: notjunk:1;V01:K0:4WKJSvsBwDU=:O433D+KFUTbzk+wPK40WVR hVOWbw5ug1fl+DPUihAHBCsKpHQtBXgJCHyCVm/uxl2Qn65UHzMjmHIY/qngujaJi0/rRH4hf B006zwL4KpOCWy1knEJnimTbZNF0RPjhpKswv8UmFDMrAbKOrggteNknYvdMuHkbMyJtdDaiy zrPUwVVZEcjHWyR2HbfOOoRKVoUjnRIbP3zza7rtQ0SHVHlgUuKc4IN4EeNJ11Bwaf/c4hKXR caJPOQz0nQHhLvFH4q5jW7KpFBs76/Nl1gUKv8QAu0HkFHiSkOwwgrJ5YM0HPybuvhWH2wMib 4Fse0zA7pKct8wDtdbqsZZUMKTkb4026bQOWGjFuoesLdNHis3VD407HpZZNJO4jyLKVGgDiz cDj+fTb8+NV1KRaxu53LwLrKR2rfqGZsnC42ZbRAzq6/QXg2E9yccq3tvZ+7EnGVSTqKdyg6X 0ofrVMqYx4UOkIlYIOa4cNpsdgXLnLMV4Im5AeSUX4N2ms6jHvEMc/3OEulYG0E9U3Rj/2OQc XlY/2w884rU9q8dmXMIfeck3mjiHUBM/i7zy01Tc+pgdV6pUJvU7HTY4t7wiToPvmuQuVOVA4 KXiAUvNcw83d987eoejcTCGqP8grVpTcsu9MHFKinHBlJGitCmlDSHi+5/uVlZ21ARHtEM7EU d1beI75nunhN1gd/y+pM2vt0npNhpo+iGlT+lsWvAQz4Mll77AzgYaps5S8EXdzQNKPKx4UgC KrJlxGpoLZGD7ODs1Q/B5Ekut6muTpCvz+AWn+VbMMrEduRU1MopipSUdAbO+mW+XWa/bnX5B BDQVAIJ Archived-At: Subject: Re: [Cellar] Matroska Info section questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 18:13:53 -0000 Hi Sebastian Am 30.06.2016 um 19:28 schrieb Sebastian G. : > >>> IIUC, chained Segments represent content that should be presented >>> sequentially (ie. play a.mkv then b.mkv then c.mkv), but are there >>> other kinds of relationships between chained Segments? Such as a >>> video-only mkv and an audio-only mka chained together to play >>> simultaneously? >> Is that really possible to combine a video-only and an audio-only mkv to >> play simultaneously? Sounds for me not really as a "chaining", more like >> a "combining". >> Again a question of the splitter/player. > Wouldn't anyone mux a audio-only and a video only file to get a mkv that > contains both, the video stream and the audio stream. Players are > supposed to handle such files as they are ordinary files. Otherwise it > might be hugely complex. (Don't get me wrong there are video players > that allow to load a different audio file to play it along with the video.) You are right. MPC-HC and other good players allows to load externel audio and subtitle files and play them simultaneously. > I'm not sure if the intro/ending case is still valid for current seasons > of any series, but the potential use was to encode the intro and the > ending once. So that one has: > > a.mkv (intro) then b.mkv (episode1) then c.mkv (ending) > a.mkv (intro) then d.mkv (episode2) then c.mkv (ending) > a.mkv (intro) then e.mkv (episode3) then c.mkv (ending) And this is the next disadvantage of File-Segement-Linking. Intro und ending are separted files. With Chapter-Segment-Linking(CSL) looks your example like this: a.mkv (intro + episode1 + ending) b.mkv (CSL to a.mkv(intro) + episode2 + CSL to a.mkv(ending)) c.mkv (CSL to a.mkv(intro) + episode3 + CSL to a.mkv(ending)) b and c mkv consist of the episode only. Best Regards Martin Below From nobody Thu Jun 30 12:13:15 2016 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 E939D12D9DB for ; Thu, 30 Jun 2016 12:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 OLCfpADBvPf2 for ; Thu, 30 Jun 2016 12:13:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF7812DB1F for ; Thu, 30 Jun 2016 12:13:06 -0700 (PDT) Received: from [192.168.2.129] ([146.60.197.26]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lp3sy-1bmY2W1Ws8-00eqL8 for ; Thu, 30 Jun 2016 21:13:04 +0200 To: cellar@ietf.org References: <4CEAF2BB-CC50-44A8-8E4A-CBDBA24813FF@dericed.com> <2bec0e81-d04b-b76c-b8aa-a42cd9ee4c2b@gmx.ch> <47d8c9ad-6e6c-9644-7b34-89189365f4ea@gmx.de> From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <54aadf8f-6588-cc89-ebeb-5cdee94d4067@gmx.de> Date: Thu, 30 Jun 2016 21:13:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:sBJ1H3zg5LdNjf/pSh0jGWYfRYf5UrtSJcM8sFd5m9nO6Egsf1F 4ioKNvnSdy3F4923kj2oClz9ZHoqf2I1at2WcY9+MpzzlVSAff4WSksTbYzhGetUFbakm4y ZJOebaTaKmegkfqN1o+5mTzym48NNucBPd9P7YohS8xGm5YeNtcrIaZY0fgFbPsuuUxXxRF mgCr22ZrmliCQDig9zbpA== X-UI-Out-Filterresults: notjunk:1;V01:K0:HwiXICdHiMU=:RL1KNdr27dEmV9yB+GTKJf TMhBbFhRDMgx265xWAgegZBYxOnQ0kj7L3G/8hcNU/rZli1BAqwZl71wTS9nl122+gcKZjA9N 3G5s7tCRBf90o6dPbTAwDoCwITruIJq+FRfV917wV00uoDjUN2RacOMo0hMnj1Bq3um9amH0D VM3o/xu+G4h7fxRZTUFaQ/4MbvNLNxc8iD+c5Ry7r3SLCb3y/E6iJo20Wp4BjsH8Xnp9bEQ4E 8R6HPbaf/E9RqPyml8xFGP5TD9i+5lwX9rMFFPClyb2Bl+ZXBCbVDyvf/qq8y7NSROfjlFG/B FdqzRKv3eBvHFJk1Er8HkwLeGbs2q5JieB5Ecc7Ne6s5L+CSM54hJPTZaeAY1FLjPejcVTw7G fwdseBOIEp+JwI5Se+RTf1CCbA2aVgR1syo1uXzFmi8PUuD3LFUNc0SysZ7qudRa9tibLc06j oEie9d9ASF/X2hFF8WM7afKHcGJnOMCnK6YLTYrbCwXRYQ0qozqeN69HZ1nR/p+nTghza0B5L 7iaYEoQGYuSQy2qTCYojX9YccYvNTtyNwABQIW6J3FLwV/Sy1AGFmtyhtc3cVG/dnIFtA6HVy 6EpfeeBq96RsOjrWvuxRjV6+BY0XrzXH5/nLHDZNq4pmGfMsOsDc4MmTSBcMy0sWOnW6wo1q/ 5SbXBYcLp7phSvjIlRo0vRsPJ4A7VLu6HE3Tcu5I6+bekc4xxX7F7YyCQPDML3DUO//z37JtL h7k6G/nLSRvv1VXQmAUVTwp/wF/qOCtlJ0V8NwAjDNWvVY2CEv2aSrzTviqfh0J7w93gkv/D5 XTlQnID Archived-At: Subject: Re: [Cellar] Matroska Info section questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jun 2016 19:13:10 -0000 30.06.2016, 20:13 hubblec4: > Hi Sebastian Hi Martin > > Am 30.06.2016 um 19:28 schrieb Sebastian G. : >> >>>> IIUC, chained Segments represent content that should be presented >>>> sequentially (ie. play a.mkv then b.mkv then c.mkv), but are there >>>> other kinds of relationships between chained Segments? Such as a >>>> video-only mkv and an audio-only mka chained together to play >>>> simultaneously? >>> Is that really possible to combine a video-only and an audio-only mkv to >>> play simultaneously? Sounds for me not really as a "chaining", more like >>> a "combining". >>> Again a question of the splitter/player. >> Wouldn't anyone mux a audio-only and a video only file to get a mkv that >> contains both, the video stream and the audio stream. Players are >> supposed to handle such files as they are ordinary files. Otherwise it >> might be hugely complex. (Don't get me wrong there are video players >> that allow to load a different audio file to play it along with the >> video.) > > You are right. MPC-HC and other good players allows to load externel > audio and subtitle files > and play them simultaneously. > >> I'm not sure if the intro/ending case is still valid for current seasons >> of any series, but the potential use was to encode the intro and the >> ending once. So that one has: >> >> a.mkv (intro) then b.mkv (episode1) then c.mkv (ending) >> a.mkv (intro) then d.mkv (episode2) then c.mkv (ending) >> a.mkv (intro) then e.mkv (episode3) then c.mkv (ending) > And this is the next disadvantage of File-Segement-Linking. > Intro und ending are separted files. > With Chapter-Segment-Linking(CSL) looks your example like this: > > a.mkv (intro + episode1 + ending) > b.mkv (CSL to a.mkv(intro) + episode2 + CSL to a.mkv(ending)) > c.mkv (CSL to a.mkv(intro) + episode3 + CSL to a.mkv(ending)) > b and c mkv consist of the episode only. > This is indeed more sophisticated (I'm expressing this as positive). >From an outside perspective the relation between those files is unclear. E.g. a user that removes a.mkv after watching b.mkv might be surprised that c.mkv does not display correctly. Nevertheless CSL is something good. > Best Regards > Martin Below > Best Regards, Sebastian