From nobody Fri Apr 1 11:20: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 012B412D62F for ; Fri, 1 Apr 2016 11:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cRIRsFa1oqHc for ; Fri, 1 Apr 2016 11:20:11 -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 23D3212D55A for ; Fri, 1 Apr 2016 11:20:11 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 6D6F323B71A3; Fri, 1 Apr 2016 20:20:08 +0200 (CEST) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id E347123B7175; Fri, 1 Apr 2016 20:19:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016040101; t=1459534799; bh=C6orqPB41dpD2xwE2gHq001iXzwiEBpWg6HoVw/YxAo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=fsKUAu1hNIg1eiR90J1hYefleSG+91QdhWyDlcJRUwGbXO/CLdYZr1RdWQpV6WRV3 VddyOF45IFLxOde9V7IyCbQyqht9C7nFR9pgmiE+qyMF6Lkr/50hg1CyQhBENk4Bna iLN0Ta/RuyTP3OMHGl+pFytgE6sVTnIa6SxJ2qmfRPvPHqCghyB/+GN1dN+IkVUHI0 jv/DE3T7iGJ5PR7NRYhVYPn2NbhCA3j/XFKQTH34WLTdf1UuGb1+IT13GLmV7mz1Gc VvctP/uwuAOg58E9XjhuyGscO69mJDqBmd9gs4jymgyWkGeDMp5a/oMKvJq7W3oylC KJUEM8dNa29GY7cW7Mcg6EGuxJKQkPGtHC5M4nJJBKkFkIN7tIuxPGkSIB2sWiXWGm K6XrICaJUUrj94+XuXFJEV+AmBazH3poTMGV0LK7yI8E3bbrkOyhAQx5mdFoa3Yz3N 8invEKCXLz8awN7CYAAEsT0QuP+GXG0HsUtMIeop+uBL7/WB5ns4z3vNOeB0JVW4O6 Td7zHlIGYnKZFJvNVum/kstBhZToNj7q21szZsZ9mOmgB0vBRXWJJt994kanuNfGkU MlsxrUJ8GFWIlFeMM5mKi0zeLd3kNupuLG1xraRlZ/jhEfcL6r/XGC9wpdXsQLtTbc Zkvc2a97e/Jh9zshZOl+gr+Q= Received: by sweet-chili.local (Postfix, from userid 1000) id 55915508E5E; Fri, 1 Apr 2016 20:19:58 +0200 (CEST) Date: Fri, 1 Apr 2016 20:19:58 +0200 From: Moritz Bunkus To: CELLAR list , matroska-devel Message-ID: <20160401181957.GN7450@bunkus.org> References: <20160314102441.GD25555@bunkus.org> <20160320181742.GW25937@bunkus.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zHDeOHGDnzKksZSU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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: Cc: Denis Charmet Subject: Re: [Cellar] [Matroska-devel] Storage of WebVTT subtitles in Matroska 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, 01 Apr 2016 18:20:13 -0000 --zHDeOHGDnzKksZSU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, > Why not put the identifier and style inside the block addition keeping > the same formalism? =E2=80=A6 > or even better (imo) swap line 1 and 2 since what interests the player > is the style and not the id and the notes. =E2=80=A6 > This would really allow a player to interpret the whole WebVTT stuff > as srt without too much effort and then add in a second time the > support of style Valid points. Another update to the proposal: --start----------------------------------------------------- (A) CodecID: S_TEXT/WEBVTT (B) Matroska CodecPrivate: This element contains all global blocks before the first subtitle entry. This starts at the "WEBVTT" file identification marker but excludes the optional byte order mark. (C) Non-global WebVTT blocks (e.g. "NOTE") before a WebVTT Cue Text are stored in Matroska's BlockAddition element together with the Matroska Block containing the WebVTT Cue Text these blocks precede (see below for he actual format). (D) Matroska Blocks: Each WebVTT Cue Text is stored directly in the Matroska Block. A muxer must change all WebVTT Cue Timestamps present within the Cue Text to be relative to the Matroska Block's timestamp. The Cue's start timestamp is used as the Matroska Block's timestamp. The difference between the Cue's end timestamp and its start timestamp is used as the Matroska Block's duration. (E) Matroska BlockAdditions: each Matroska Block may be accompanied by one BlockAdditions element. Its format is as follows: The first line contains the WebVTT Cue Text's optional Cue Settings List followed by one line feed character (U+0x000a). The Cue Settings List may be empty in which case the line consists of the line feed character only. The second line contains the WebVTT Cue Text's optional Cue Identifier followed by one line feed character (U+0x000a). The line may be empty indicating that there was no Cue Identifier in the source file in which case the line consists of the line feed character only. The third and all following lines contain all WebVTT Comment Blocks that precede the current WebVTT Cue Block. These may be absent. If there is no Matroska BlockAddition element stored together with the Matroska Block then all three components (Cue Settings List, Cue Identifier, Cue Comments) must be assumed to be absent. --end------------------------------------------------------- Rationale for the changes: (A) Consistency: most text subtitle formats in Matroska use S_TEXT/=E2=80= =A6. (B) Again keeping as much data as possible. In WebVTT the file signature may be followed by additional data. So let's just keep that data intact. It doesn't cost much, and a demuxer could feed CodecPrivate directly into a WebVTT parser. (C), (D) and (E) have been changed according to Denis' proposal to store the non-text components in BlockAdditions elements. Example. WebVTT source file: --start----------------------------------------------------- WEBVTT with text after the signature STYLE ::cue { background-image: linear-gradient(to bottom, dimgray, lightgray); color: papayawhip; } /* Style blocks cannot use blank lines nor "dash dash greater than" */ NOTE comment blocks can be used between style blocks. STYLE ::cue(b) { color: peachpuff; } REGION id:bill width:40% lines:3 regionanchor:0%,100% viewportanchor:10%,90% scroll:up NOTE Notes always span a whole block and can cover multiple lines. Like this one. An empty line ends the block. hello 00:00:00.000 --> 00:00:10.000 Example entry 1: Hello world. NOTE style blocks cannot appear after the first cue. 00:00:25.000 --> 00:00:35.000 Example entry 2: Another entry. This one has multiple lines. 00:01:03.000 --> 00:01:06.500 position:90% align:right size:35% Example entry 3: That stuff to the right of the timestamps are cue settings. 00:03:10.000 --> 00:03:20.000 Example entry 4: Entries can even include timestamps. For example:<00:03:15.000>This becomes visible five seconds after the first part. --end------------------------------------------------------- Resulting CodecPrivate element: --start----------------------------------------------------- WEBVTT with text after the signature STYLE ::cue { background-image: linear-gradient(to bottom, dimgray, lightgray); color: papayawhip; } /* Style blocks cannot use blank lines nor "dash dash greater than" */ NOTE comment blocks can be used between style blocks. STYLE ::cue(b) { color: peachpuff; } REGION id:bill width:40% lines:3 regionanchor:0%,100% viewportanchor:10%,90% scroll:up NOTE Notes always span a whole block and can cover multiple lines. Like this one. An empty line ends the block. --end------------------------------------------------------- Example Cue 1: timestamp 00:00:00.000, duration 00:00:10.000, Block's content: --start----------------------------------------------------- Example entry 1: Hello world. --end------------------------------------------------------- BlockAddition's content: --start----------------------------------------------------- hello --end------------------------------------------------------- Example Cue 2: timestamp 00:00:25.000, duration 00:00:10.000, Block's content: --start----------------------------------------------------- Example entry 2: Another entry. This one has multiple lines. --end------------------------------------------------------- BlockAddition's content: --start----------------------------------------------------- NOTE style blocks cannot appear after the first cue. --end------------------------------------------------------- Example Cue 3: timestamp 00:01:03.000, duration 00:00:03.500, Block's content: --start----------------------------------------------------- Example entry 3: That stuff to the right of the timestamps are cue settings. --end------------------------------------------------------- BlockAddition's content: --start----------------------------------------------------- position:90% align:right size:35% --end------------------------------------------------------- Example Cue 4: timestamp 00:03:10.000, duration 00:00:10.000, Block's conte= nt: --end------------------------------------------------------- Example entry 4: Entries can even include timestamps. For example:<00:00:05.000>This becomes visible five seconds after the first part. --end------------------------------------------------------- This Block does not need a BlockAddition as the Cue did not contain an Identifier, nor a Settings List, and it wasn't preceded by Comment blocks. Kind regards, mosu --zHDeOHGDnzKksZSU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW/rvIAAoJEHSvAK3y4yyFDLEP/0JJRBiTYO5VwtwfmZcGzu/A uL20eZ+UsZA8FREpHAIfa7qGw16iJbeko95ILu7DIUuf7KNBUUcr4sp1OMw9lV7l 5yznaBZnP7P+BunaUmLo98dFsNnaUa+kBYrQRwQfktchh4h7iGIKF9P7WwHQlN6M O39STN+BhJa6LQ/NDbtGCRNMKWOFHZOdMLR1qpBsHpBhYToO/2CJgy2mHcKV1wCH XdUpU9PlqadPsmqwpcqN0rLWu1Md/9xEx5On0/07mPQWKNIqJAjGZQzHknF0Wnoj oVYaSBAy9ZVtPJiemSSv1Jirnrk+8YDa6RdycGYL+/E8PJ8HPHxSiJRzcVywjw9q 8IXB5ZrFhVcOlIhpOzZIpGu8hpqalJmVoMqNm+jWr60mcBiKgU5X7mesiSC9p0u6 304IgyPlZWVftzH08ohuu6lh6IUvTsnuMPAjPxFZVZeGC+MuqEMliWkNKEszG9ht K7sGGcSl2n0d9dw0lp4Wy/CcQR8IYuQF2UXuNor+VHcuWWf7eG46i91KMgXWVlHy xVGA6brbgUQG+dFtYCFLPDmxIsuNbI+KBoaUfLAcLlxZJOmmdKZN9gwt1GxVQY2z 97ImhEoyEsjdL1VstNaQdFXIQDuuCCKi+dz9jyaQ3FdU8M+77C1vDVpl+jlHcr4n ssoRLNv64q9O/3TX1xYU =2uik -----END PGP SIGNATURE----- --zHDeOHGDnzKksZSU-- From nobody Wed Apr 6 13:54: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 260BE12D59B for ; Wed, 6 Apr 2016 13:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 nYhm-hhregDL for ; Wed, 6 Apr 2016 13:54:24 -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 6029112D52A for ; Wed, 6 Apr 2016 13:54:24 -0700 (PDT) Received: from [146.96.19.240] (port=34587 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 1anuSz-000DRC-EK for cellar@ietf.org; Wed, 06 Apr 2016 16:54:23 -0400 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 6 Apr 2016 16:54:20 -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] spherical video+ 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, 06 Apr 2016 20:54:26 -0000 Hi all, I recently saw the RFC draft work at = https://github.com/google/spatial-media/blob/master/docs/spherical-video-r= fc.md. Regarding the combination of frame cropping and stereo mode it = clarifies: "Cropping, initial view, and projection properties are shared = across the left/right eyes. Each video frame is divided into the = left/right eye regions then cropping and view information is applied = treating each region as a separate video frame." Is this considered true = for Matroska. =46rom my reading of the current Matroska spec I would = presume that the PixelCrop* elements refer to the overall frame = regardless of StereoMode data. Also this document proposes storing spherical video metadata in XML form = in the Tags elements instead of in EBML sub-elements of the Video = Element. Is anyone aware of this project? Or is it worthwhile to = collaborate to include the considerations of this document within = current Matroska specification efforts. Best Regards, Dave Rice= From nobody Tue Apr 12 00:18:38 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 98AF612E68C for ; Tue, 12 Apr 2016 00:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaz6Ie3tXgPs for ; Tue, 12 Apr 2016 00:18:36 -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 3A17512E695 for ; Tue, 12 Apr 2016 00:18:36 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id A053C27B728F; Tue, 12 Apr 2016 09:18:33 +0200 (CEST) Received: from sweet-chili.local (unknown [10.55.1.18]) by liselle.bunkus.org (Postfix) with ESMTPS id 55F4327B727C; Tue, 12 Apr 2016 09:18:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016040101; t=1460445509; bh=o5Qye1NSQkguMzA9Djt5BWTpL6dzQoPROnUGEB0MUf8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=LBa1MYa20tBorutstuFOzeA5n3X3qQO3BDt/D4hvREr32XZgpx4qZgRKCUCxxYZ5V v6CTXf+0lv9vxIcsyFxDliBkRmxk2lHpHpEvYxN7ZYK5CTSpZPORYMJpU3Spw1Izse lHjHApH6adyb0azkuWotrR5VXQZWhq+gfaTt5YWPU9mxDfnZA5GrVNDhviffRZMmt1 e0AJaZypK+3MMa51GZN0GA2CgwNipyOjxoYhJGHcAOb21LHE9UslGyGED7TTL5HWU5 Q7Y0mJHAknCppiauPmeTY3Bm2cWaowUvXPTV6L/rFBXkprdxjvJYVMjfawGX0JFwR5 O5IG9LiE49LWCypFUML3tVshoz2wc/2H/T59GmfADGBJWU0+91Eb+DbGC99flK7gZ0 yb3bUp9ZCmtQCXbD3WDKuuuwd6ckJuCRiEEq94kmN9LPQ7sES0kas4iq60BvA47oGu Hii2CRVUoHHogmyY1TeJMk7e/Dkroh+Y/qkD/FeexpBBnyWhZVh3s+R3m35x/Rqonv fBjJMM2yibC6PKBZqM3UxumRs7ms3BnX/v6JGXfm2eTDAfRdssby7xwTspI6r1w6B5 7V/qQbobgcQ2EnTgzbufIjuNy3KV4YOcd1jLahuFhuHC9F9CaDb8MR4PN4HsGOF66A +Gn41jhN5+dIm+FgirPLYztk= Received: by sweet-chili.local (Postfix, from userid 1000) id DB8A353DC80; Tue, 12 Apr 2016 09:18:28 +0200 (CEST) Date: Tue, 12 Apr 2016 09:18:28 +0200 From: Moritz Bunkus To: CELLAR list , matroska-devel Message-ID: <20160412071828.GG20341@bunkus.org> References: <20160314102441.GD25555@bunkus.org> <20160320181742.GW25937@bunkus.org> <20160401181957.GN7450@bunkus.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/i8j2F0k9BYX4qLc" Content-Disposition: inline In-Reply-To: <20160401181957.GN7450@bunkus.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Cc: Denis Charmet Subject: Re: [Cellar] [Matroska-devel] Storage of WebVTT subtitles in Matroska 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: Tue, 12 Apr 2016 07:18:37 -0000 --/i8j2F0k9BYX4qLc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, > Another update to the proposal: As there were no more comments I've implemented support for WebVTT in mkvmerge and mkvextract yesterday following my spec proposal from April 1st. I'll put that up on www.matroska.org within the next couple of days. Kind regards, mosu --/i8j2F0k9BYX4qLc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJXDKFEAAoJEHSvAK3y4yyFpsIQAMpJA5V43H+bXngvpR8f2OX7 EaFBHrVtiVbImpYerYFWrbLF22qTn9Gz6YEDcevGARsJSyhpDHedFIdn3h4E5nc2 XXtHYNS15h8XLxjNo2WgB64P5ed6MWijJyypdBf4eUNsyshzrNhDjp4Pn7M+d3p3 w4UL/rZX9rHJ9cMXzikARK1UeMnVLW+BWhLPxuvZbPL/xbw1vOr7Y9I8z/RtcrTW tE2Q30Ig3irYUiI6KhUZmW/q5m9VAtjkUFv+F+C8wguLJvNlHh5y1Rho84T/iOq9 ysNy5PG5Yv5f499vP2s9qUnAzVI/A2eEGm/1hLoHlAYaY1lDDpRDZKYTaBQ8EN70 wV+lGtAS9JOlckblUvRLLMYxKN/zreekog9gFyzf+oSFDiOAJMIjH8m+my2z9Dxs 7yTK5unFecznftM/RYZNaFSkbjJZNqP/JbeyVWRR2jCQ99Yx1JEFgHd6usbjVU55 J+5v91Q1zQFGUseaALZ12tFoq8+Xs1QnqHm1B4xt+wiLAOTl3ssT4MMM27nRAfrJ wOgfgXxXCdZZgVkS89U92AcWePVbtqbYMV49q3KYqV0lri7jAL/NfWT6OmvDTxK3 3QKmuxsT1IV6FUpxwMfFp4s1gO8c7uJXQ6fr6gcz79SV7UUOmfUuHx/TjTZWAArT xIVA1v9HSWA0YlNYAHsw =8KgM -----END PGP SIGNATURE----- --/i8j2F0k9BYX4qLc-- From nobody Wed Apr 13 01:15: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 D333712E144 for ; Wed, 13 Apr 2016 01:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAEMb_CT82pP for ; Wed, 13 Apr 2016 01:15:10 -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 B8D1812E09F for ; Wed, 13 Apr 2016 01:15:10 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 1495527CC924; Wed, 13 Apr 2016 10:15:06 +0200 (CEST) Received: from sweet-chili.local (unknown [10.55.1.18]) by liselle.bunkus.org (Postfix) with ESMTPS id B86F527CC91B; Wed, 13 Apr 2016 10:15:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016040101; t=1460535304; bh=4HUaWowCFHVsZibARRKRi2XJglXREuD1W+rbz61qBt8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=OW4wOemMmHNNu0ccckLgiixcZyRsn2goO3scy9JfhngAUbHe7YRsgVbq9ITcLP7g8 q7i8pefvpZRx/cWxioW26dgCnIMXlbYfEYbbjRdFFnOcLhF2KI0tW80U2t45uaNkQ4 HQluyH+G4iC+jdSmMYc7mg8THdopmBkCDlH0LHJWmQgtz+4k9/OAFyFC0LBRPvFKX/ 5RT+wAymYlghvRB4ee9VF7SunyqIebatoZabc7dCG146ET+rEYoJV8OVIV7XBm/g7P wpgpL/LqUd38RmKZXrru2t0I1N925P5YOXYQZnvd92jinmbCLrltePIlHRcTz0k6Ra oi/r5MQxWP+yvLtrw/DIhLmsdP6aFzpFRtmfbsN5uhrMEAQ6QtYjt91NXwxa4WhNB5 dheOokKLESuN9008QF+f6OimhCtQbRi8wsK9g2tyMl2Yv8ayYipulTqZ/2UZ6Tm066 mdYlq5MUSMMaJgk72+zE5GJrBApqqq+I6UHtnjRNQMmH8FWAD5YazuIEleSfXmqP88 /AS/fy/4MYHP/3Rb0O9Ri+l4dHh8YPTCST0znTyjSIXkagjqxr7u5YkslzQARR/Ayc IN0CtumjS8Dq4Arazqd6M50db5gyygLzIXYpHTt/C5oyzj71FNrT1lXUQLSujd32oF 1ruBubfX/0d+9al2dkzbKOBw= Received: by sweet-chili.local (Postfix, from userid 1000) id 48A67541051; Wed, 13 Apr 2016 10:15:04 +0200 (CEST) Date: Wed, 13 Apr 2016 10:15:04 +0200 From: Moritz Bunkus To: Moritz Bunkus via Matroska-devel Message-ID: <20160413081503.GA5186@bunkus.org> References: <20160314102441.GD25555@bunkus.org> <20160320181742.GW25937@bunkus.org> <20160401181957.GN7450@bunkus.org> <20160412071828.GG20341@bunkus.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <20160412071828.GG20341@bunkus.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Cc: CELLAR list Subject: Re: [Cellar] [Matroska-devel] Storage of WebVTT subtitles in Matroska 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, 13 Apr 2016 08:15:14 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, the specs have been added to the website: https://www.matroska.org/technical/specs/subtitles/webvtt.html Kind regards, mosu --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJXDgAHAAoJEHSvAK3y4yyF9zgP/jGi2XFOA4Q7mCcdEwIyMn5N jm8NARCwf4MO0jaSZ69h7bvrqofez9zBacpCchZRv/rFxdsBAljH6hh7gWAXEL++ GjwuWDyVGm8d3xZdw7z3VI8gUe1crE+XfDH44gOY9yecbJM9djQwjL3iEmxI6T2O IV8sqVH4gu193wiA6f9eU8xn8cW3CP3R2EOOhXkB2zFFO5mjAt4VsIx1TwGyy6Ba UkecEN4WnUUjrFFUqRRiRxwOBnJkzRRV8sXQu6KUpZ3lSyprPPCRGJW9HeQqSy5s sfBBn8MOb25fONA31/2jUXPy4kUjnkzlFJFEHh6eO934VgWdyA+hvGcdrEUiifmt R2rlnQLdzHrIC0BDAmHde84ef4KkwyMPf2XFPPbJoSZGbQBDcMFe5bqJG9M0X8jr MAHNzE1CG6fP8boftNaGp3G2pq2Ah0L3wGq97v/WUz44R7WpB66eolvbwZFHZjKC Va/wis3QOMCox5ZcXI7ei1tBtQnfiwNZAX2m8zq4Ic/I2hgE35WEzwOxiTez9730 CHsnGUqZxlmrndrNHpxoEfn6wb/DAvnRinqRLxAeY/GJ4E6bpR6242tvK9kOdeB1 cS4wyvbqK5ePM+98SxPKp7+07h1tZUXupo919W2/cfOu/LepGxxPq04cy344e60b 7XvfLu5Tc9vJdVkXf2Ln =KgT2 -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From nobody Sun Apr 17 06:16: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 802E612DE7A for ; Sun, 17 Apr 2016 06:16:22 -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 6EtFbdyxaUWM for ; Sun, 17 Apr 2016 06:16:19 -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 A07C012DE70 for ; Sun, 17 Apr 2016 06:16:19 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:46908 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 1armYh-0033gG-C6; Sun, 17 Apr 2016 09:16:19 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_A643D61C-2277-4425-8E38-F11920793671" Message-Id: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com> Date: Sun, 17 Apr 2016 09:16:13 -0400 To: Nithin Mathew Kurien , 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] patch on textual expressions of floats in EBML 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, 17 Apr 2016 13:16:22 -0000 --Apple-Mail=_A643D61C-2277-4425-8E38-F11920793671 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Here=E2=80=99s my patch to add a small section on the textual = representation of floats in EBML Schemas (this would be relevant when a = =E2=80=98range=E2=80=99 or =E2=80=98default=E2=80=99 value is declared = for an EBML Float Element. I=E2=80=99m not exactly sure my examples are = correct, please review. There=E2=80=99s a few issues with parsing Hexadecimal Floating-Point = Constants in a range. For instance, with integers the hyphen is the = delimiter between the maximum and minimum value of the range but hyphen = may also be used within a Hexadecimal Floating-Point Constants to = express a negative binary power. For instance in a range like this the = hyphens have two meanings: 0x1p-8-0x1p-2. I cited = http://www.exploringbinary.com/hexadecimal-floating-point-constants/ as = the definition of Hexadecimal Floating-Point Constants rather than = redefine Hexadecimal Floating-Point Constants within the EBML spec. Is = there a more official citation for Hexadecimal Floating-Point Constants? The patch includes line updates to =E2=80=9CExpression of range=E2=80=9D = but this is only to include float as an option. Mostly it=E2=80=99s the = "#### Textual expression of Floats=E2=80=9D section in need of review. = The patch may be seen in a GitHub context here: = https://github.com/MediaArea/ebml-specification/commit/a3dc4c2e3128048e991= a3fa0907d501654383ae7. =46rom 880936692e37b3bdd0e8ec57332278491e5e470b Mon Sep 17 00:00:00 2001 From: dericed Date: Sun, 17 Apr 2016 09:05:24 -0400 Subject: [PATCH] define textual expression of floats in ebml schema --- specification.markdown | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/specification.markdown b/specification.markdown index cc39012..ea78cfe 100644 --- a/specification.markdown +++ b/specification.markdown @@ -271,13 +271,23 @@ An Identically-Recurring Element is an Element = that may occur within its Parent =20 #### Expression of range =20 -The `range` attribute MUST only be used with EBML Elements that are = either `signed integer` or `unsigned integer`. The `range` attribute = does not support date or float 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: +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: =20 - - `x-y` where x and y are integers 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, meaning that the value MUST be = greater than `x`. - - `x` where `x` is an integer, meaning that the value MUST be equal = `x`. + - `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`. =20 -The `range` may use the prefix `not ` to indicate that the expressed = range is negated. +The `range` may use the prefix `not ` to indicate that the expressed = range is negated. Please also see the section on [textual expression of = floats](#textual-expression-of-floats). + +#### Textual expression of Floats + +When a float must be represented textually, such as within a `default` = or `range` value of an EBML Schema, the expression of `range` for a = float Element MUST represent the float range as a [Hexadecimal = Floating-Point = Constants](http://www.exploringbinary.com/hexadecimal-floating-point-const= ants/). The following table provides examples of expressions of float = ranges. + +| as decimal | as Hexadecimal Floating-Point Constants |=20 +|-------------|-----------------------------------------| +| 0.0-1.0 | 0x0p+1-0x1p+0 | +| 1.0-256.0 | 0x1p+0-0x1p+8 | +| 0.857421875 | 0x1.b7p-1 | =20 #### Note on the Use of default attributes to define Mandatory EBML = Elements =20 --=20 2.8.1 Best Regards, Dave Rice= --Apple-Mail=_A643D61C-2277-4425-8E38-F11920793671 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,
Here=E2=80=99s = my patch to add a small section on the textual representation of floats = in EBML Schemas (this would be relevant when a =E2=80=98range=E2=80=99 = or =E2=80=98default=E2=80=99 value is declared for an EBML Float = Element.  I=E2=80=99m not exactly sure my examples are correct, = please review.

There=E2=80=99s a few issues with parsing Hexadecimal Floating-Point = Constants in a range. For instance, with integers the hyphen is the = delimiter between the maximum and minimum value of the range but hyphen = may also be used within a Hexadecimal Floating-Point Constants to express a = negative binary power. For instance in a range like this the hyphens = have two meanings: 0x1p-8-0x1p-2.

I cited http://www.exploringbinary.com/hexadecimal-floating-point-const= ants/ as the definition of Hexadecimal Floating-Point Constants rather than = redefine Hexadecimal Floating-Point Constants within the EBML spec. Is = there a more official citation for Hexadecimal Floating-Point = Constants?

The patch includes line updates = to =E2=80=9CExpression of range=E2=80=9D but this is only to = include float as an option. Mostly it=E2=80=99s the "#### Textual = expression of Floats=E2=80=9D section in need of review. The patch may = be seen in a GitHub context here: https://github.com/MediaArea/ebml-specification/commit/a3dc4c2e= 3128048e991a3fa0907d501654383ae7.


=46rom = 880936692e37b3bdd0e8ec57332278491e5e470b Mon Sep 17 00:00:00 = 2001
From: = dericed <dave@dericed.com>
Date: Sun, 17 Apr 2016 09:05:24 = -0400
Subject: [PATCH] define textual expression of floats in ebml = schema

---
 specification.markdown | 20 = +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 = deletions(-)

diff --git a/specification.markdown = b/specification.markdown
index cc39012..ea78cfe = 100644
--- = a/specification.markdown
+++ = b/specification.markdown
@@ -271,13 +271,23 @@ An = Identically-Recurring Element is an Element that may occur within its = Parent
 
 #### Expression of range
 
-The `range` attribute MUST = only be used with EBML Elements that are either `signed integer` or = `unsigned integer`. The `range` attribute does not support date or float = 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:
+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 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, meaning = that the value MUST be greater than `x`.
-    - `x` where `x` is an = integer, meaning that the value MUST be equal `x`.
+    - `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.
+The `range` may use the prefix `not ` to = indicate that the expressed range is negated. Please also see the = section on [textual expression of = floats](#textual-expression-of-floats).
+
+#### Textual expression of = Floats
+
+When a float must be represented textually, such as within a = `default` or `range` value of an EBML Schema, the expression of `range` = for a float Element MUST represent the float range as a [Hexadecimal = Floating-Point Constants](http://www.exploringbinary.com/hexadecimal-floating-point-const= ants/). 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     =                     =       |
 
 #### Note on the Use of default attributes to define = Mandatory EBML Elements
 
-- 
2.8.1

Best Regards,
Dave = Rice
= --Apple-Mail=_A643D61C-2277-4425-8E38-F11920793671-- From nobody Mon Apr 18 01:29:40 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 9AD9712D12B for ; Mon, 18 Apr 2016 01:29:38 -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 x-SrqK1fSDz1 for ; Mon, 18 Apr 2016 01:29:35 -0700 (PDT) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (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 AB54D12B057 for ; Mon, 18 Apr 2016 01:29:35 -0700 (PDT) Received: by mail-yw0-x241.google.com with SMTP id v81so3734011ywa.2 for ; Mon, 18 Apr 2016 01:29: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=c8riM8nTSAiEg/mlXSqsTH56da5VhNibnMX1I0Hckzk=; b=aAqLoJuNaxMuMjviBoF2oqaSuOPgUVEO8Pd4ujOkSCC7JpdsgG30yCO0mn6NpC6zUb 9h5isrT2XhYGi76DBdvypXGn9oW4jVW4vGfKIO1krtf0aVhZv5rrmHef4k4TxuT8cupL CxOgalvXAQzrejVwIjNibTU7uszzbkaurTCC9SStZ4nVJUMxuk9Hu6hXLwsP3EPHNZdB KhihiKvLx9mRaxL0yZJ2kj50LkpXAWQVt4ojE0mdu2nGxQb4yW5Q1FrMiIWKf2cop7Kb +ANqn6BzNDXpkI8F0Py6Qqn5VE1GhJ4SBv6Ps8OeNEX3k3C/H6lDnDEM4rx33jwoFmoq yGHg== 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=c8riM8nTSAiEg/mlXSqsTH56da5VhNibnMX1I0Hckzk=; b=FQZlXje3C4NwcwVBhCA5sqpyO89wB7FEUcTX07RHmkluPRtovMtZ/HlLIX1sJL/o0G 1WNvVSRc4J+L46WHuATbYCcJD2q+uV3Fw/z0SU6Wvmm6WnZJCdgx+h2U8QF5C6CUd9ha PrPU1NrDdvTiymu63nKJKEGFUwYFaG4Z/Y8kbHrOrkGTTWt5ujq2aYH1bCRi4ur15gah YC2nSZHjR7VwCw2tr8r/4cW5Zn7oIbWjmWby82NFHxewYSuU6Z+iFpxzhV8mO+nqf92Z /YxQUevnWRYRbuZw6mOOW9F/hkFUOqQiinnNhwNhsWmRFXDs+yLoI2HoVYetypHC7eL4 PjKg== X-Gm-Message-State: AOPr4FUTHnYSnt93XMSsnXgVuwdbc8/Do8QjUgoYPZf0ZDSrphjX4Foy79X+ezr5BKx8qqYTv+E1KBVymq+vcQ== MIME-Version: 1.0 X-Received: by 10.129.83.196 with SMTP id h187mr20942643ywb.319.1460968174881; Mon, 18 Apr 2016 01:29:34 -0700 (PDT) Received: by 10.83.48.67 with HTTP; Mon, 18 Apr 2016 01:29:34 -0700 (PDT) In-Reply-To: References: <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> <9CE0170E-E63D-411D-AFAF-EE5CBB4B56D7@dericed.com> <20160219214538.GL4557@nb4> Date: Mon, 18 Apr 2016 10:29:34 +0200 Message-ID: From: Steve Lhomme To: Hendrik Leppkes , Discussion about the current and future development of Matroska , cellar@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Frank Galligan Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal 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, 18 Apr 2016 08:29:38 -0000 Following the Videolan Colorimetry workshop from this week-end, I have a better understanding of this whole subject. I think it's good if we can have as much information in Matroska as we can. But they probably should be split between elements that are necessary for accurate playback (list to be defined) and the other information like how the content was captured on camera. The first group should be in the TrackInfo while the others should be just tags (so with string names) that target the whole file or some chapters (each scene probably has different capture characteristics). >From Frank's list I would put those in the TrackInfo: - MatrixCoefficients - Range - TransferFunction - Primaries - BitsPerChannel - ChromaSubsamplingHorz / ChromaSubsamplingVert - CbSubsamplingHorz / CbSubsamplingVert I'm not sure about the Luminance min/max but maybe it's needed for HDR ? Not sure either about arbitrary RGB chromacity values of the primaries. Are people deviating from the few norms that are available ? And have tools for playback ? That seems to provide the same information as the "Primaries" field and it's never good to have 2 different set of values describing the same thing. You never know if you have to write both and which to use for playback especially when you need 8 values to make one set to compare... Are MaxCLL and MaxFALL exclusive ? Are they needed for HDR playback ? I think MasteringMetadata is not needed for playback. For list of possible values, we shouldn't follow lists from standards that are not freely available. We should also have the default value be 0 when possible. And no "reserved" values. 2016-03-29 19:12 GMT+02:00 Hendrik Leppkes via Matroska-devel : > On Tue, Mar 29, 2016 at 6:11 PM, Frank Galligan via Matroska-devel > wrote: >> >> >> On Mon, Mar 28, 2016 at 5:05 AM, Steve Lhomme wrote: >>> >>> 2016-03-17 5:46 GMT+01:00 Frank Galligan : >>> > OK really no comments for a long time. >>> > >>> > On Fri, Feb 19, 2016 at 1:45 PM, Michael Niedermayer >>> > wrote: >>> >> >>> >> Hi >>> >> >>> >> On Thu, Feb 18, 2016 at 11:50:27AM -0800, Frank Galligan wrote: >>> >> > Here is the current proposal, minus the reference to the 265 doc. >>> >> > >>> >> > The parent element would be Video [E0]. >>> >> > >>> >> > >>> >> > Element Name: Colour >>> >> > >>> >> > Level: 4 >>> >> > >>> >> > ID: [55][B0] >>> >> > >>> >> > Mandatory: - >>> >> > >>> >> > Multiple: - >>> >> > >>> >> > Default: - >>> >> > >>> >> > Type: m >>> >> > >>> >> > Description: Settings describing the colour format. >>> >> > >>> >> > >>> >> > Element Name: MatrixCoefficients >>> >> > >>> >> > Level: 5 >>> >> > >>> >> > ID: [55][B1] >>> >> > >>> >> > Mandatory: - >>> >> > >>> >> > Multiple: - >>> >> > >>> >> > Default: 2 >>> >> > >>> >> > Type: u >>> >> > >>> >> > Description: The Matrix Coefficients of the video used to derive >>> >> > luma >>> >> > and >>> >> > >>> >> > chroma values from reg, green, and blue color primaries. >>> >> > For >>> >> > >>> >> > clarity, the value and meanings for MatrixCoefficients >>> >> > are >>> >> > adopted >>> >> > >>> >> > from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1: >>> >> > BT709, >>> >> > >>> >> > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: >>> >> > SMPTE >>> >> > 170M, >>> >> > >>> >> > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant >>> >> > Luminance, >>> >> > >>> >> > 10: BT2020 Constant Luminance) >>> >> > >>> >> > >>> >> >>> >> > Element Name: BitsPerChannel >>> >> > >>> >> > Level: 5 >>> >> > >>> >> > ID: [55][B2] >>> >> > >>> >> > Mandatory: - >>> >> > >>> >> > Multiple: - >>> >> > >>> >> > Default: 0 >>> >> > >>> >> > Type: u >>> >> > >>> >> > Description: Number of decoded bits per channel. A value of 0 >>> >> > indicates >>> >> > that >>> >> > >>> >> > the BitsPerChannel is unspecified. >>> >> > >>> >> >>> >> what would this be set to for old 16bit rgb, that is 5 bit red >>> >> 6 bit green, 5 bit blue rawvideo. >>> >> This maybe does not matter and iam not strongly suggesting to add it, >>> >> rather i want to point it out so its not unintentionally forgotten >>> > >>> > >>> > I didn't get into RGB here. As you said 565, 551, there are a good >>> > amount of >>> > combinations. I think DirectShow (or maybe it was DirectDraw) that had >>> > R,G,B, and A masks to show which bits belonged to which channel. I also >>> > worked with formats like RGBBGR repeating. >>> >> >>> >> >>> >> >>> >> [...] >>> >> >>> >> > Element Name: CbSubsamplingHorz >>> >> > >>> >> > Level: 5 >>> >> > >>> >> > ID: [55][B5] >>> >> > >>> >> > Mandatory: - >>> >> > >>> >> > Multiple: - >>> >> > >>> >> > Default: - >>> >> > >>> >> > Type: u >>> >> > >>> >> > Description: The amount of pixels to remove in the Cb channel for >>> >> > every >>> >> > pixel >>> >> > >>> >> > not removed horizontally. This is additive with >>> >> > >>> >> > ChromaSubsamplingHorz. Example: For video with 4:2:1 >>> >> > chroma >>> >> > >>> >> > subsampling, the ChromaSubsamplingHorz should be set to >>> >> > 1 >>> >> > and >>> >> > >>> >> > CbSubsamplingHorz should be set to 1. >>> >> > >>> >> > >>> >> > Element Name: CbSubsamplingVert >>> >> > >>> >> > Level: 5 >>> >> > >>> >> > ID: [55][B6] >>> >> > >>> >> > Mandatory: - >>> >> > >>> >> > Multiple: - >>> >> > >>> >> > Default: - >>> >> > >>> >> > Type: u >>> >> > >>> >> > Description: The amount of pixels to remove in the Cb channel for >>> >> > every >>> >> > pixel >>> >> > >>> >> > not removed vertically. This is additive with >>> >> > >>> >> > ChromaSubsamplingVert. >>> >> >>> >> What if Cr is subsampled more than Cb ? >>> >> That too is rather obscure, but theres code in FFmpeg to handle such >>> >> jpegs, so i suspect this case while very rare is not entirely non >>> >> existent ... >>> > >>> > >>> > I guess we can add that as well if more people really want it. Actually >>> > I >>> > didn't even have CbSubsampling* elements at first. I only added that to >>> > support the 4:2:1 format that was defined in the first enum. >>> >> >>> >> >>> >> >>> >> > >>> >> > >>> >> > Element Name: ChromaSitingHorz >>> >> > >>> >> > Level: 5 >>> >> > >>> >> > ID: [55][B7] >>> >> > >>> >> > Mandatory: - >>> >> > >>> >> > Multiple: - >>> >> > >>> >> > Default: 0 >>> >> > >>> >> > Type: u >>> >> > >>> >> > Description: How Chroma is subsampled horizontally. (0: Unspecified, >>> >> > 1: >>> >> > Left >>> >> > >>> >> > collocated , 2: Half) >>> >> > >>> >> > Element Name: ChromaSitingVert >>> >> > >>> >> > Level: 5 >>> >> > >>> >> > ID: [55][B8] >>> >> > >>> >> > Mandatory: - >>> >> > >>> >> > Multiple: - >>> >> > >>> >> > Default: 0 >>> >> > >>> >> > Type: u >>> >> > >>> >> > Description: How Chroma is subsampled vertically. (0: Unspecified, >>> >> > 1: >>> >> > Top >>> >> > >>> >> > collocated , 2: Half) >>> >> > >>> >> >>> >> iam not sure this is enough to specify all variants >>> >> for 4:2:0 alone there are a few different variants >>> >> theres mpeg1 style >>> >> mpeg2 progressive and interlaced >>> >> the mpeg2/mpeg4 style also differs from itself if the image is fliped >>> >> right-left >>> >> cropping 1 or 2 lines of the top of mpeg2 yuv420 also results in >>> >> different variants >>> > >>> > >>> > >>> > I also didn't get into interlaced. >>> > >>> > >>> > >>> > I don't think we should add enough elements to support every format that >>> > was >>> > ever produced. Opinions? >>> >>> For archival (one of the main goal here) I think we should. >>> >>> > I think we should probably strive to support 99% of what is currently >>> > produced today. Opinions? >>> >>> The problem is that when you leave 1% out, you need to be sure it's >>> possible to integrate it later. Usually the best approach is to know >>> beforehand how you're going to do it. So in the end it's just like >>> covering it. That's just a general remark though. >> >> I don't want to exclude anything in the future, but I also don't want to >> make something overly complex/over specified to support a format that will >> barely see any use. >> >> I want to move forward with this, so how about we make a list and then vote >> on what we think should be added to the sepc? >> 1. Raw RGB >> 2. Raw YUV >> 3. Interlaced >> 4. mpeg1 style >> 5. mpeg2 pogessive >> 6. mpeg2 interlaced >> 7. image flipped right-left >> 8. jpeg Cr subsampled more than Cb >> 9. non-linear color values (DPX scans) >> >> Anything else we should add? >> > > Just my 2 cents, but if you want to support everything and the kitchen > sink, you should use string fields that can be arbitrarily expanded, > instead of integer enumerations. > > - Hendrik > _______________________________________________ > Matroska-devel mailing list > Matroska-devel@lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel -- Steve Lhomme Matroska association Chairman From nobody Mon Apr 18 08:00: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 D0F9D12DFAA for ; Mon, 18 Apr 2016 08:00:37 -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, 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 MMS7KpJlopEs for ; Mon, 18 Apr 2016 08:00:34 -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 800A312E06A for ; Mon, 18 Apr 2016 08:00:33 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id j74so27247219ywg.1 for ; Mon, 18 Apr 2016 08:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=SfxiOPb6LPOQTJ0RNyG40CxvshOMfBPvR5vIQ3nd4KI=; b=JVOVstkKbDIvFbub7lPYjO0nZ6q6mThfyshp2R6RgsOZ55lLx3mYd73oBCcfMSg5g8 cTW+XboaeYi8WuLy8ZkYaprMl4R4VMreDbpYOaz7j6xn6mvdm1JYpEgHoXaQPHf1HxI+ EOQbWB5oiRoAxx/NB5yE7qG9sokPuaZixQilfTdPrjCJZvpKwXjsKADYZs7ID8/GIh4U 0NCtz0KATr2DDuITKzpLkE9FqKUxyrS+Z4K5VgEiQ8OlfAy0oPdgZ4V6RMhGAK4cQ/4L O6HnV9n6NjasLIugD5nC3H0KRQnnkI50oBMHIzIOYJgeT/VDRsUgCV2yfNik9DC7KMRP f2FA== 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=SfxiOPb6LPOQTJ0RNyG40CxvshOMfBPvR5vIQ3nd4KI=; b=Rc9s91Aq6tFDDF4frV+oKbIu8973MWt7xpzlgd9JBZhBOjiL7X/k6D0gz/lrZMuyTQ aG7nDR6Y0j+4A4vb90iJq+FC4HOZwFxiewNWmnwhZ/uts9ZhcGZeULrVFj10Tx7Y/q/5 1+60Gg1fzsVaBm9TzxO6R3vH9l+pJpm3SmX+BbiyalDFrKlygH4EFpUi72r2qn6EQ7AS 8rmePfEcfjEuPuKTXs7cfQDGKX8NH4bA0wH4uCr8YZhcstI5Tu7Jzcr2/u0pakNNK7vM fqBCsBAhXbeo2HKobWQ3QyyruGXVGcMWWJNMXzPmBvGdht4frdrMtmInZIDSaMLbVMD4 gEkA== X-Gm-Message-State: AOPr4FUh+8FSwKfd+60HD2nuKF8AvRF9x4V2NHjw7bDKJQGql+ULkjN140WXe/cg4RseNi0/1Bds99aGcKS2dA== MIME-Version: 1.0 X-Received: by 10.37.21.5 with SMTP id 5mr19106127ybv.22.1460991632772; Mon, 18 Apr 2016 08:00:32 -0700 (PDT) Received: by 10.129.116.137 with HTTP; Mon, 18 Apr 2016 08:00:32 -0700 (PDT) In-Reply-To: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com> References: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com> Date: Mon, 18 Apr 2016 20:30:32 +0530 Message-ID: From: Nithin Mathew Kurien To: Dave Rice Content-Type: multipart/alternative; boundary=001a113e56424a99810530c39f00 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] patch on textual expressions of floats in EBML 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: Mon, 18 Apr 2016 15:00:38 -0000 --001a113e56424a99810530c39f00 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Sun, Apr 17, 2016 at 6:46 PM, Dave Rice wrote: > Hi all, > Here=E2=80=99s my patch to add a small section on the textual representat= ion of > floats in EBML Schemas (this would be relevant when a =E2=80=98range=E2= =80=99 or =E2=80=98default=E2=80=99 > value is declared for an EBML Float Element. I=E2=80=99m not exactly sur= e my > examples are correct, please review. > > There=E2=80=99s a few issues with parsing Hexadecimal Floating-Point Cons= tants in > a range. For instance, with integers the hyphen is the delimiter between > the maximum and minimum value of the range but hyphen may also be used > within a Hexadecimal Floating-Point Constants to express a negative > binary power. For instance in a range like this the hyphens have two > meanings: 0x1p-8-0x1p-2. > > I think the parser can resolve this issue without much trouble. In this context, the hyphen expresses a negative binary power, when it is preceded by a 'P' or 'p'. On the other hand, the hyphen serves as the delimiter between the minimum and maximum values, when it is not preceded by a 'P' or 'p'. This criterion can be used to distinguish the two cases. I cited http://www.exploringbinary.com/hexadecimal-floating-point-constants= / > as the definition of Hexadecimal Floating-Point Constants rather than > redefine Hexadecimal Floating-Point Constants within the EBML spec. Is > there a more official citation for Hexadecimal Floating-Point Constants? > > The official citation is the C11 standard (ISO/IEC 9899:2011); but the document is available only for a fee from the ISO website. A publicly available draft is http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pd= f. The relevant section is 6.4.4.2 Floating constants (pages 65-66). > The patch includes line updates to =E2=80=9CExpression of range=E2=80=9D = but this is only > to include float as an option. Mostly it=E2=80=99s the "#### Textual expr= ession of > Floats=E2=80=9D section in need of review. The patch may be seen in a Git= Hub > context here: > https://github.com/MediaArea/ebml-specification/commit/a3dc4c2e3128048e99= 1a3fa0907d501654383ae7 > . > > > From 880936692e37b3bdd0e8ec57332278491e5e470b Mon Sep 17 00:00:00 2001 > From: dericed > Date: Sun, 17 Apr 2016 09:05:24 -0400 > Subject: [PATCH] define textual expression of floats in ebml schema > > --- > specification.markdown | 20 +++++++++++++++----- > 1 file changed, 15 insertions(+), 5 deletions(-) > > diff --git a/specification.markdown b/specification.markdown > index cc39012..ea78cfe 100644 > --- a/specification.markdown > +++ b/specification.markdown > @@ -271,13 +271,23 @@ An Identically-Recurring Element is an Element that > may occur within its Parent > > #### Expression of range > > -The `range` attribute MUST only be used with EBML Elements that are > either `signed integer` or `unsigned integer`. The `range` attribute does > not support date or float EBML Elements. The `range` expression may conta= in > whitespace for readability but whitespace within a `range` expression MUS= T > NOT convey meaning. The expression of the `range` MUST adhere to one of t= he > following forms: > +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: > > In this context, does 'float' mean only 32-bit floats, or does it mean both 32-bit floats and 64-bit doubles? If it is the latter, then I think 'floating constant' (given in the C11 standard) may be a more unambiguous term. - - `x-y` where x and y are integers 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, meaning that the value MUST be > greater than `x`. > - - `x` where `x` is an integer, meaning that the value MUST be equal > `x`. > + - `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. > +The `range` may use the prefix `not ` to indicate that the expressed > range is negated. Please also see the section on [textual expression of > floats](#textual-expression-of-floats). > + > +#### Textual expression of Floats > + > +When a float must be represented textually, such as within a `default` o= r > `range` value of an EBML Schema, the expression of `range` for a float > Element MUST represent the float range as a [Hexadecimal Floating-Point > Constants]( > http://www.exploringbinary.com/hexadecimal-floating-point-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 | > > The table is correct regarding the representation of the constants. Maybe we can also include an example containing negative floating constants like this one: -1.0--0.857421875 -0x1p+0--0x1.b7p-1 #### Note on the Use of default attributes to define Mandatory EBML > Elements > > -- > 2.8.1 > > Best Regards, > Dave Rice > Thanks and regards, Nithin --001a113e56424a99810530c39f00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Sun, Apr 17, 2016 at 6:46 PM, Dave Rice <dave@dericed.com>= wrote:
Hi all,
Here=E2=80=99s my patch to add a small section on the te= xtual representation of floats in EBML Schemas (this would be relevant when= a =E2=80=98range=E2=80=99 or =E2=80=98default=E2=80=99 value is declared f= or an EBML Float Element.=C2=A0 I=E2=80=99m not exactly sure my examples ar= e correct, please review.

There=E2=80=99s a few is= sues with parsing=C2=A0Hexadecimal Floa= ting-Point Constants in a range. For instance, with integers the hyphen is = the delimiter between the maximum and minimum value of the range but hyphen= may also be used within a=C2=A0= Hexadecimal Floating-Point Constants to express a negative binary power. Fo= r instance in a range like this the hyphens have two meanings:=C2=A0= 0x1p-8-0x1p-2.

I thi= nk the parser can resolve this issue without much trouble. In this context,= the hyphen expresses a negative binary power, when it is preceded by a = 9;P' or 'p'. On the other hand, the hyphen serves as the delimi= ter between the minimum and maximum values, when it is not preceded by a &#= 39;P' or 'p'. This criterion can be used to distinguish the two= cases.

I cited=C2=A0http://www.exploringbinary.com/hexadecimal-f= loating-point-constants/ as the definition of=C2=A0Hexadecimal Floating-Point Constants rather than r= edefine=C2=A0Hexadecimal Floatin= g-Point Constants within the EBML spec. Is there a more official citation f= or=C2=A0Hexadecimal Floating-Poi= nt Constants?

The official citation is the C11 standard = (ISO/IEC 9899:2011); but the document is available only for a fee from the = ISO website. A publicly available draft is http://www.open-std.org/jtc1/sc22/wg1= 4/www/docs/n1570.pdf. The relevant section is 6.4.4.2 Floating constant= s (pages 65-66).
=C2=A0
The patch includes line updates to=C2=A0=E2=80=9CEx= pression of range=E2=80=9D but this is only to include float as an option. = Mostly it=E2=80=99s the "#### Textual expression of Floats=E2=80=9D se= ction in need of review. The patch may be seen in a GitHub context here:=C2= =A0https://github.com/Me= diaArea/ebml-specification/commit/a3dc4c2e3128048e991a3fa0907d501654383ae7<= /a>.


= Date: Sun, 17 Apr 2016 09:05:24 -0400
Subject: [PATCH] define textual expression of flo= ats in ebml schema

---
= =C2=A0specification.markdown | 20 +++++++++++++++-----
=C2=A01 file changed, 15 insertions(+), 5 deletions(-)<= /font>

diff --git a/specification.markdown b/specification.markdown
index cc39012..ea78cfe 100644
--- a/specification.markdown
+++ b/specification.markdown
@@ -271,13 +271,23 @@ An Identically-Recurring Element i= s an Element that may occur within its Parent
=C2=A0
=C2=A0#### Expr= ession of range
=C2=A0
=
-The `range` attribute MUST only be used with E= BML Elements that are either `signed integer` or `unsigned integer`. The `r= ange` attribute does not support date or float EBML Elements. The `range` e= xpression may contain whitespace for readability but whitespace within a `r= ange` expression MUST NOT convey meaning. The expression of the `range` MUS= T adhere to one of the following forms:
+The `range` attribute MUST only be used with EBML Elements that are e= ither `signed integer`, `unsigned integer`, or `float`. The `range` attribu= te 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:

In thi= s context, does 'float' mean only 32-bit floats, or does it mean bo= th 32-bit floats and 64-bit doubles? If it is the latter, then I think '= ;floating constant' (given in the C11 standard) may be a more unambiguo= us term.

- =C2=A0 =C2=A0- `x-y` where = x and y are integers and `y` must be greater than `x`, meaning that the val= ue must be greater than or equal to `x` and less than or equal to `y`.
- =C2=A0 =C2=A0- `>x` where `x` is a= n integer, meaning that the value MUST be greater than `x`.
- =C2=A0 =C2=A0- `x` where `x` is an integer, mean= ing that the value MUST be equal `x`.
+ =C2=A0 =C2=A0- `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`.
+ =C2=A0 =C2=A0- `>x` where `x` is an integer or float, meaning that = the value MUST be greater than `x`.
+ =C2=A0 =C2=A0- `x` where `x` is an integer or float, meaning that the va= lue MUST be equal `x`.
=C2=A0
-The `range` may use the prefix `not ` t= o indicate that the expressed range is negated.
+The `range` may use the prefix `not ` to indicate that the ex= pressed range is negated. Please also see the section on [textual expressio= n of floats](#textual-expression-of-floats).
+
+#### Textual expressio= n of Floats
+
+When a float must be represented textually, such as wit= hin a `default` or `range` value of an EBML Schema, the expression of `rang= e` for a float Element MUST represent the float range as a [Hexadecimal Flo= ating-Point Constants](http://www.exploringbinary.c= om/hexadecimal-floating-point-constants/). The following table provides= examples of expressions of float ranges.
+
+| as decimal =C2=A0| as H= exadecimal Floating-Point Constants |=C2=A0
+|-------------|-----------------------------------------|<= /div>
+| 0.0-1.0 =C2=A0 =C2=A0 | 0x0p+1-0x1p+0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
+| 1.0-256.0 = =C2=A0 | 0x1p+0-0x1p+8 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+| 0.857421875 | 0x1.b7p-1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0
Th= e table is correct regarding the representation of the constants. Maybe we = can also include an example containing negative floating constants like thi= s one:

-1.0--0.857421875 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0-0x1p+0--= 0x1.b7p-1

<= /div>
=C2=A0#### Note on the Use of default attributes to define Man= datory EBML Elements
<= div>=C2=A0
-= -=C2=A0
2.8.1

=
Best Regards,
Dave Rice

Thanks and regards,
Nithin
--001a113e56424a99810530c39f00-- From nobody Mon Apr 18 08:57:19 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 A62BD12E191 for ; Mon, 18 Apr 2016 08:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeMIpj91NutP for ; Mon, 18 Apr 2016 08:57:14 -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 6FE8D12E1A7 for ; Mon, 18 Apr 2016 08:57:14 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 8D4F42950504; Mon, 18 Apr 2016 17:57:11 +0200 (CEST) Received: from sweet-chili.local (unknown [10.55.1.18]) by liselle.bunkus.org (Postfix) with ESMTPS id 7C94229504F6 for ; Mon, 18 Apr 2016 17:57:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016040101; t=1460995028; bh=92XNd5C2R3fNmnFm1zUQoWaIQV5IJiSbfoY1n8HVJVM=; h=Date:From:To:Subject:References:In-Reply-To; b=dKQHKwNkuhmvHFVy4ZJoOt4wQnMpwn14Kvrc91WriTYgFGBav/36J09lB0VSHSuyO lfMu4Wwp4zZdLwTyfV6l8GVCWIi6t5nMeefxWZP2dn+M2Au7rmRYiINKwvU2LhdevV xZ/9bTALG7to6FxhQfE6SqY5ns4ygA+NfZTO3rUzJnFK0nncKBsOzjoixFHkksFSGm /UYFY+kCAoNHKujDZU4o5/tr6Koj+aA0x63uHgoM+TiGi2xpa9Yrs1dcH0Foshu5jQ 8EiOwUnNdurmRU27LyxSMQYaf0l8UROwHAYBtEjma0tgb1T/d0ilbzCyOTQx1uap4e YFmbrC8odU4pcxXDBd3dA/dvhE9A3Aolbfv9YlRXf+GJjkyfGllyTLvhKDx89en245 o8qx2V6XmaGeWkvmMC0eYmnNgD7psZ2OXdfTLV0fOqbV4ujTyk6RJ7x0fd56XnFAzG dv1ClDlKor+7OeQ0YFftPxsZAxX9BjKyVBnEYZNbhlVMj90QmrMNXJfv5Mf3FtZ3aV YhUib+vNvfEoIt/PaXjztQWgsGotvsz4hcH/ue3bUO5Iq/veiNMeP++vvpZ4ki9ZFh Vcfoh1a99os87nm88NaH6nKH1CuiGDW7c/fVovfUqoHbz3XxFmW8GvWLvaWR9qFq4f XLi7GiGKEsL3GYFXq4GHExpk= Received: by sweet-chili.local (Postfix, from userid 1000) id 149D6551CF9; Mon, 18 Apr 2016 17:57:07 +0200 (CEST) Date: Mon, 18 Apr 2016 17:57:07 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160418155706.GI30912@bunkus.org> References: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TKDEsImF70pdVIl+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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 on textual expressions of floats in EBML 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: Mon, 18 Apr 2016 15:57:16 -0000 --TKDEsImF70pdVIl+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, > > I think the parser can resolve this issue without much trouble. In this > context, the hyphen expresses a negative binary power, when it is preceded > by a 'P' or 'p'. On the other hand, the hyphen serves as the delimiter > between the minimum and maximum values, when it is not preceded by a 'P' or > 'p'. This criterion can be used to distinguish the two cases. I agree. If a p occurs the following element must be the exponent. Therefore there's no ambiguity. > In this context, does 'float' mean only 32-bit floats, or does it mean > both 32-bit floats and 64-bit doubles? If it is the latter, then I think > 'floating constant' (given in the C11 standard) may be a more unambiguous > term. The specs always talk about the numerical types as they apply to EBML (section "EBML Element Types" at [1]). We don't talk about data types in a specific programming language; that's an implementation detail the specs shouldn't care about. So "float" means up to 64bits, just as "unsigned integer" does. We don't say "uint64_t" there either. Kind regards, mosu [1] https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown --TKDEsImF70pdVIl+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJXFQPNAAoJEHSvAK3y4yyF0igP/0y6jRpBqznilUUGQ7nCDl1L hLAuIZLrenr+l02JJck44ecAF01iSMZ7heijcryP/dOWD0kTcLFWNXnaRrtKill3 +sYz1RQXQ76QNh8T+fFtlAhqLkp1Gqqv2KQs7ERfrUBmQfyeNwCNBxAZOes865H6 W77BExsjyyjoT1Ba+Kqvakog2cbptJUaZBjhr2gVU1o6OT5CkCWwYF6pau9j9pBG wRXJuG0fhY5jC2cdV7cc4TZJBghcf9ANAvJ27iHKR4XiXHFNC0f25p0mzpLCpjq3 WDRf91zsv6rZ9dvxAexn5/p4spIqctqa13lNT07Cc3AkqqZ7r9Rt00IOtZi5ba9W +OQ1uadWovCO7j0QhLnKiD8Pi1tavfBwNjJRgZPw3nNvQOXnhpB76hscJ205rYaq 4/1Up/zYAOkgANz0ycmFLU+1TS5l/qhXGrWboXuQT2zHNBTa64WEit43HkdlIJfY YDFqYyhqRYDlWgr86DPotDq/SQ6oAHlEDBtU1ECZevem1DBqICjqVJPkYAD9/Q9P dFbvEnyFtTkyDBXiwzHnXIee+W423UTzh6J3TRXBBEFqwCg0VHCylP1i9JZNFpHN ASfPUPpuDuF995aIYSbE0bVylu/tt4btJHtWkfQzATld7yXsJi2raMW6W1hv2KoA tpHE0l+vPPVm7xkZNN0Y =i6Qp -----END PGP SIGNATURE----- --TKDEsImF70pdVIl+-- From nobody Mon Apr 18 09:01:02 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 6580612E1BD for ; Mon, 18 Apr 2016 09:01:01 -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 dGsCZsuZlmnv for ; Mon, 18 Apr 2016 09:00:59 -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 C263112E1BC for ; Mon, 18 Apr 2016 09:00:59 -0700 (PDT) Received: from [146.96.19.240] (port=28743 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 1asBbc-0042ps-UQ; Mon, 18 Apr 2016 12:00:59 -0400 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DBC03DFB-9904-475F-B735-06D7F12E6C89"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Dave Rice In-Reply-To: <20160418155706.GI30912@bunkus.org> Date: Mon, 18 Apr 2016 12:00:54 -0400 Message-Id: <08896C4C-F809-4614-9489-21A16D9BE12D@dericed.com> References: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com> <20160418155706.GI30912@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 on textual expressions of floats in EBML 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: Mon, 18 Apr 2016 16:01:01 -0000 --Apple-Mail=_DBC03DFB-9904-475F-B735-06D7F12E6C89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 18, 2016, at 11:57 AM, Moritz Bunkus wrote: >=20 > Hey, >=20 >>> I think the parser can resolve this issue without much trouble. In = this >> context, the hyphen expresses a negative binary power, when it is = preceded >> by a 'P' or 'p'. On the other hand, the hyphen serves as the = delimiter >> between the minimum and maximum values, when it is not preceded by a = 'P' or >> 'p'. This criterion can be used to distinguish the two cases. >=20 > I agree. If a p occurs the following element must be the > exponent. Therefore there's no ambiguity. Regarding such interpretation, currently specdata.xml expresses float = range in a style of "0.0-1.0". Should we say that both forms are valid = as ranges? Or that "0x0p+1-0x1p+0" is valid but "0.0-1.0" is invalid. >> In this context, does 'float' mean only 32-bit floats, or does it = mean >> both 32-bit floats and 64-bit doubles? If it is the latter, then I = think >> 'floating constant' (given in the C11 standard) may be a more = unambiguous >> term. >=20 > The specs always talk about the numerical types as they apply to EBML > (section "EBML Element Types" at [1]). We don't talk about data types = in > a specific programming language; that's an implementation detail the > specs shouldn't care about. So "float" means up to 64bits, just as > "unsigned integer" does. We don't say "uint64_t" there either. >=20 > Kind regards, > mosu >=20 > [1] = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_DBC03DFB-9904-475F-B735-06D7F12E6C89 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXFQS3AAoJEIlM1Sx2ptr5gvkQAK2TQ15ovKQ0Nemcwt9e/4al cdy/GD7iKg+eQJvVF5COHEmxXlZ9sdg6DlpDdMsdcTvvcfIBzE1/dY75On2rWloL SBR3+Z/X+TFHfhK4NQ2mRgz+vMcEv2k1NtGWyIGfGL7mGaEgMpX1FrHCdxQ9F8sB wJr4AwKnF1TlazwnqT5OGXproKG2SklAwb84ofo0597Rod3WdXTah8R/e6vXBw2v GFUSpI/wgmyUkC1ETyZWhwF6TI90A2xDqAF44vesm4+IFkxAT+2PXq5o6SPFGppj j5Cc/Fegm2mATYkWW7IRhpRdVaGM0NrjoWE+aqBvPolgG2mcUnIxJaX73b8BjsET L+HlHYMJNxPK65ZcQl8hPUvttIPFhjCaaNd7n5OT9kTzH+b/fUYsovijPRpxvhGM wHTRrBNNiq6lV5tBqL9PlP+DjJMfuV3/Yd+TmdB403YR0/NdgDqo9spFKSo0oGfo QDqt+ib/qflczTRzhTLRoSiObVwg7Xi4A142hy18bKaa0lUAhe6wUL9fQro+3JSW bskg/JufJUjeOVHDaTpwIcIlt0xmX8i+BStHhDapE+2Ibuht5pyQgzzVoDhUYj5o oWCDwwdCHlrlHhMH+DuClq60d1SwsZvgDMws12RdgRUOvZi/kOVDRDrnhGXfsgDs 4mjzJlZRvgeA24lRkugd =vqpp -----END PGP SIGNATURE----- --Apple-Mail=_DBC03DFB-9904-475F-B735-06D7F12E6C89-- From nobody Wed Apr 20 18:14: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 2ECA512E7D9 for ; Wed, 20 Apr 2016 18:14:48 -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 axadBX0o8Nxp for ; Wed, 20 Apr 2016 18:14:44 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 913EA12E67C for ; Wed, 20 Apr 2016 18:14:44 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id f89so54043234ioi.0 for ; Wed, 20 Apr 2016 18:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nGia8ScLRQvWcAWA53BliJlDFqoPo8Q4qbuasLexijM=; b=qPqj/PYZHvOXIp6Fe5ZD1Q2G8VXJeKqlfT/7kp4v3MgMrQzZuPbWbDTOENtd08Gdvz WtBfD4II2nwxS6duxLz52MleP/h71eLTBkZE3qfVP/rj5/huDgHLBunPuIcqk3epI6aS PpU3IGdSHVygqZ2UtQ7mYRkZwWQbRK8GJjz9gQALrYOBe3l9BCmAM2wMhYifXRQOrqol uZsVD5bTatrCAFPuGmmzoh4bgsQI18I528Hc53V8798ocT+xQvq+gufIGvkSw88Dka1c fVIWkp4jGHVgztdkHM8N9mKzFaSJzZgtUv91FRQffktcRNV1T5CUUCTf0aCMNLAvpDAh YlPw== 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=nGia8ScLRQvWcAWA53BliJlDFqoPo8Q4qbuasLexijM=; b=FwnVUNrVRwcgWPrQOdw7RaypvLAKTQDzBtveZ3Ax/UeLCn1lDEO7toQT4MyD1v5LoI KQHM4oQnk0fxmAmA4J/OV0HrkNJdj1xZzEdInX5aVPo4d7IIaBaGFbSnLlXGr9VtLxD8 TEFWZGHITyrWz/YMgNm6mtv6PhgEKeablM8XZ1t0Zjk46xQbLUWC7BQq8xzmMOOdolhY MN1Bk/Bx5jugFLblUGIXVgeAlAOZUxkzszNyVDwxiLd3VBaXIyM3cfTQpDCFZGfM3Vyl pBDQZQIfbYzcbgb+LTOdcGuqokXs1LFEedgC+f9YiAgwPjfnkoUaEWtPKer5/WU9tAC2 lVsg== X-Gm-Message-State: AOPr4FXkBgjWWjsxwEprss8kugghbPHJmtAEV6RmIRUAaTE3xDrZUlLuF4ksW1s+7t486MX1I8s/hKw3OK99mw== MIME-Version: 1.0 X-Received: by 10.107.4.74 with SMTP id 71mr15126826ioe.22.1461201283801; Wed, 20 Apr 2016 18:14:43 -0700 (PDT) Received: by 10.79.9.196 with HTTP; Wed, 20 Apr 2016 18:14:43 -0700 (PDT) In-Reply-To: References: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> <442FEE5C-FCE3-4966-AFA0-CF6159E79C39@dericed.com> Date: Wed, 20 Apr 2016 21:14:43 -0400 Message-ID: From: Ashley Blewer To: Steve Lhomme Content-Type: multipart/alternative; boundary=001a113ee9f0776d8b0530f46f26 Archived-At: Cc: Dave Rice , cellar@ietf.org Subject: Re: [Cellar] Proposal to work on Github Pages site 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, 21 Apr 2016 01:14:48 -0000 --001a113ee9f0776d8b0530f46f26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Apologies for not being more specific about this usage... I updated the repository with information about how to view changes, view the webpage, and view local changes. The changes are in the new README: https://github.com/ablwr/mkv_jekyll_poc Pull requests can't be readily made visible live, but you can pull down someone's pull request and view it locally on your own machine. Also, if a user forks the repo and merges their changes to their own gh-pages branch, they should be able to see and share the differences. For example, if and when this repo moves to MatroskaOrg, I can still fork it, commit a change to my fork in the gh-pages branch, and see it by going to ablwr.github.io/mkv_jekyll_poc/. Likewise, Dave could do the same and his changes could be seen on dericed.github.io/mkv_jekyll_poc/. I hope that makes sense. Ashley On Mon, Mar 28, 2016 at 8:19 AM, Steve Lhomme wrote: > 2016-03-26 23:42 GMT+01:00 Dave Rice : > > Hi all, > > > > On Mar 24, 2016, at 9:38 PM, Ashley Blewer > wrote: > > > > Hi all, > > > > I intentionally haven't merged this PR since it's being used as an > example. > > I am happy to merge it in, but I myself am not representative of > MatroskaOrg > > so it doesn't feel right for me to approve of Dave's work on this. > > LGTM > > > Would it be better if this demo was brushed up (that's on me) and moved > to > > MatroskaOrg Github account and work can be commented on via the listser= v > and > > approved there? > > Not sure, how can we preview the content of this repository as a > webpage ? Can pull requests be visible as web pages too ? That would > make it easier to validate changes. > > > I=E2=80=99ll leave this to WG Chairs, Steve, and Moritz and whomever co= ntributes > to > > clarifying a contribution and approval process for the Matroska spec, n= ow > > that the one for EBML is getting very close to completed (I hope). > > IMO yes, EBML is in a good shape now. > > > The current Matroska spec is on a website, in Drupal posts, which is no= t > so > > RFC-like and doesn=E2=80=99t offer the same list of features for collab= oration as > > github. I suggest we work Matroska specification website in a GitHub re= po > > (wherever that may be located). > > Yes. Also the old specs will likely remain as they are, at least a > legacy reference. We'll probably have a different URL for the official > RFC for EBML and Matroska (in addition to being published wherever > RFCs are). > > > Ashley=E2=80=99s draft repo at > > https://github.com/ablwr/mkv_jekyll_poc/blob/gh-pages/index.md > represents > > only https://matroska.org/technical/specs/index.html. My initial PR at > > https://github.com/ablwr/mkv_jekyll_poc/pull/1/files mostly focuses on > > removing the redundancy with the EBML specification and instead > deferring to > > that as a dependency. > > > > For next steps I propose moving the Element Table from > > https://matroska.org/technical/specs/chapters/index.html. I think > eventually > > we could have a build process that combining information from > specdata.xml > > with the rest of the specification to make nice human-readable versions > and > > interactive tables of the Matroska spec, but for specification work I > think > > it may help to separate the EBML Schema data of the table and the rules > and > > specification of Matroska into separate documents (one in xml and one i= n > > markdown). > > Sounds good. > > > Also I propose moving copies of other Matroska specification pages to t= he > > GitHub repo for refinement. I suggest starting with these: > > https://matroska.org/technical/diagram/index.html > > https://matroska.org/technical/specs/notes.html > > https://matroska.org/technical/order/index.html > > > > And then moving on the the pages to focus on the Top Level Elements, su= ch > > as: > > https://matroska.org/technical/specs/chapters/index.html > > https://matroska.org/technical/cover_art/index.html (expanding this to > cover > > other types of Attachments) > > > > I think through this work we could separate the current content of > > matroska.org in information that should become part of a Matroska RFC > spec > > and other data that is intended to support that (such as the info on us= er > > guides, faq, downloads, logos, etc). > > We could use /technical/drafts/ > > > I=E2=80=99m a bit inspired by the IETF work on Opus where there is now = the Opus > RFC > > https://tools.ietf.org/html/rfc6716 and a supplementary > > https://www.opus-codec.org website that contextualizes the RFC and > > integrations non-spec documentation, samples, and community information= . > I > > think a similar approach may work with Matroska. > > http://specs.matroska.org/ ? > > > Comments welcome. > > > > Best Regards, > > Dave > > > > Let me know your thoughts! > > > > Ashley > > > > On Thu, Mar 17, 2016 at 10:45 PM, Dave Rice wrote: > >> > >> Hi all, > >> > >> To test this out, I submitted a Pull Request to Ashley=E2=80=99s mkv_j= ekyll_poc > >> repository. I am open to either matroska-spec-repo approach as Ashley > >> demonstrated in GitHub; however I have a preference for the jekyll > version > >> as we could work on the specifications in Markdown rather than directl= y > in > >> HTML. I find Markdown patches a lot easier to read than HTML patches. > >> > >> The pull request is here: > https://github.com/ablwr/mkv_jekyll_poc/pull/1. > >> > >> The PR mainly has two changes: > >> > >> - The introduction is rephrased to say that the specification is WIP a= nd > >> associate it to CELLAR WG. > >> > >> > This document is a work-in-progress specification defining the > Matroska > >> > file format as part of the [IETF Cellar working > >> > group](https://datatracker.ietf.org/wg/cellar/charter/). But since > it's > >> > quite complete it is used as a reference for the development of > libmatroska. > >> > Legacy versions of the specification can be found > >> > [here](/files/matroska.pdf) (PDF doc by Alexander No=C3=A9 -- outdat= ed). > >> > > >> > For a simplified diagram of the layout of a Matroska file, see the > >> > [Diagram page](../diagram/index.html). > >> > >> I could also move the reference to Alexander No=C3=A9=E2=80=99s docume= nt into a new > >> `Legacy Matroska` section to reference historical Matroska documents > while > >> contextualizing them as superseded by CELLAR=E2=80=99s work. > >> > >> - I also removed the section of the Matroska specification that is > >> redundant to the EBML specification. Instead I added a section that > states > >> that Matroska is dependent on EBML like this: > >> > >> > ### Basis in EBML > >> > > >> > Matroska is a Document Type of EBML (Extensible Binary Meta Language= ). > >> > This specification is dependent on the [EBML > >> > Specification]( > https://github.com/Matroska-Org/ebml-specification/blob/master/specificat= ion.markdown > ). > >> > For an understanding of Matroska's EBML Schema, see in particular th= e > >> > sections of the EBML Specification covering [EBML Element > >> > Types]( > https://github.com/Matroska-Org/ebml-specification/blob/master/specificat= ion.markdown#ebml-element-types > ), > >> > [EBML > >> > Schema]( > https://github.com/Matroska-Org/ebml-specification/blob/master/specificat= ion.markdown#ebml-schema > ), > >> > and [EBML > >> > Structure]( > https://github.com/Matroska-Org/ebml-specification/blob/master/specificat= ion.markdown#structure > ). > >> > >> One disadvantage of the mkv_jekyll_poc repo over the mkv_pages_poc rep= o > is > >> the presentation of the Matroska Element table, > >> http://ablwr.github.io/mkv_jekyll_poc/#elements-semantic, but I am > >> interested in the idea of re-designing the presentation of the table. > >> > >> Thanks, > >> Dave Rice > >> > >> > >> > On Mar 14, 2016, at 4:29 AM, Steve Lhomme > wrote: > >> > > >> > 2016-03-13 15:24 GMT+01:00 Ashley Blewer : > >> >> We can always dedicate the table of elements to its own page -- the > >> >> current > >> >> page is pretty lengthy. Unless there are others who strongly favor > the > >> >> other > >> >> approach, I can continue working on the Jekyll-based site and it wi= ll > >> >> be > >> >> ready for future collaboration with version-control built in. > >> >> > >> >> Steve, do you think the Jekyll site should mimic/replicate exactly > the > >> >> current site design or is some change in aesthetics fine? Don't kno= w > if > >> >> we're tied to having the Github Page site look like Matroska.org or > if, > >> >> since it's for spec viewing and work in particular, it's fine to > appear > >> >> differently. > >> > > >> > The design doesn't matter too much. As long as it's easy to read and > >> > navigate. > >> > > >> >> Thanks much! > >> >> > >> >> Ashley > >> >> > >> >> On Sun, Mar 13, 2016 at 6:24 AM, Steve Lhomme > >> >> wrote: > >> >>> > >> >>> 2016-03-06 22:39 GMT+01:00 Ashley Blewer = : > >> >>>> Hey all! > >> >>>> > >> >>>> There's been some discussion about a collaborative framework with > >> >>>> which > >> >>>> to > >> >>>> continue work on the Matroska specification in a code-development > >> >>>> context > >> >>>> after we've had conversations on this list. > >> >>>> > >> >>>> I'd like to propose we migrate the Matroska specification to > Github. > >> >>>> As > >> >>>> I > >> >>>> mentioned before, I'm happy to carry this transition to completio= n > on > >> >>>> a > >> >>>> MatroskaOrg-hosted or CELLAR-hosted Github organizational account= , > >> >>>> but > >> >>>> would > >> >>>> like to hear from everyone on which site is the best for a > >> >>>> collaborative > >> >>>> environment. > >> >>>> > >> >>>> Option 1: Jekyll-based website that automatically translates > Markdown > >> >>>> to > >> >>>> HTML. > >> >>>> Option 1 repo: https://github.com/ablwr/mkv_jekyll_poc > >> >>>> Please note this currently follows a Jekyll theme standard but ca= n > be > >> >>>> made > >> >>>> to look like the Matroska site. > >> >>>> > >> >>>> The pros and cons are both in terms of ease of use. The benefits > are > >> >>>> working > >> >>>> in the more human-readable Markdown instead of HTML. The negative > is > >> >>>> that > >> >>>> running a local Jekyll server to preview work before submitting a > >> >>>> request is > >> >>>> harder than opening up a static site. > >> >>>> > >> >>>> Also, tables can be difficult to read and create in Markdown. > >> >>>> However, > >> >>>> the > >> >>>> primary table located on the specification page is rendered via X= ML > >> >>>> and > >> >>>> would not have to be rewritten in Markdown (although this example > >> >>>> does > >> >>>> have > >> >>>> it written in Markdown). > >> >>>> > >> >>>> Option 2: Standard HTML website. > >> >>>> Option 2 repo: https://github.com/ablwr/mkv_pages_poc > >> >>>> This has been translated to replicate the Matroska site. > >> >>>> > >> >>>> Like I said above, previewing work doesn't require running a loca= l > >> >>>> server. > >> >>>> But work is harder to read because it's in HTML and most changes > will > >> >>>> be > >> >>>> very text-based anyway. > >> >>>> > >> >>>> After we come to a decision, I can move relevant specification > >> >>>> details > >> >>>> to > >> >>>> this site and it can be used to make changes to the standard afte= r > >> >>>> decisions > >> >>>> are made here on CELLAR. > >> >>> > >> >>> I never heard of Jekyll before but it seems interesting. That woul= d > be > >> >>> for the RFC based specs, so maybe the table of elements will go in > the > >> >>> end or be presented differently. Until the RFC work is done we > should > >> >>> keep the current specs as they are, just fixing things when we fin= d > >> >>> issues. > >> >>> So as a starting project I think the Markdown approach is good. We > can > >> >>> always go back to pure HTML and continue from there later. While t= he > >> >>> opposite is more work and not trivial. > >> >>> > >> >>>> My best, > >> >>>> > >> >>>> Ashley Blewer > >> >>>> > >> >>>> _______________________________________________ > >> >>>> Cellar mailing list > >> >>>> Cellar@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/cellar > >> >>>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Steve Lhomme > >> >>> Matroska association Chairman > >> >> > >> >> > >> > > >> > > >> > > >> > -- > >> > Steve Lhomme > >> > Matroska association Chairman > >> > > >> > _______________________________________________ > >> > 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 > > > > > > > > -- > Steve Lhomme > Matroska association Chairman > --001a113ee9f0776d8b0530f46f26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologies for not being more specific about this usage... = I updated the repository with information about how to view changes, view t= he webpage, and view local changes. The changes are in the new README:=C2= =A0https://github.com/a= blwr/mkv_jekyll_poc

Pull requests can't be readi= ly made visible live, but you can pull down someone's pull request and = view it locally on your own machine. Also, if a user forks the repo and mer= ges their changes to their own gh-pages branch, they should be able to see = and share the differences. For example, if and when this repo moves to Matr= oskaOrg, I can still fork it, commit a change to my fork in the gh-pages br= anch, and see it by going to=C2=A0ablwr.github.io/mkv_jekyll_poc/. Likewise, Dave could do the = same and his changes could be seen on dericed.github.io/mkv_jekyll_poc/. I hope that makes se= nse.

Ashley



On Mon, Ma= r 28, 2016 at 8:19 AM, Steve Lhomme <slhomme@matroska.org> wrote:
2016-03-26 23:4= 2 GMT+01:00 Dave Rice <dave@dericed.= com>:
> Hi all,
>
> On Mar 24, 2016, at 9:38 PM, Ashley Blewer <ashley.blewer@gmail.com> wrote:
>
> Hi all,
>
> I intentionally haven't merged this PR since it's being used a= s an example.
> I am happy to merge it in, but I myself am not representative of Matro= skaOrg
> so it doesn't feel right for me to approve of Dave's work on t= his.

LGTM

> Would it be better if this demo was brushed up (that's on me) and = moved to
> MatroskaOrg Github account and work can be commented on via the listse= rv and
> approved there?

Not sure, how can we preview the content of this repository as a
webpage ? Can pull requests be visible as web pages too ? That would
make it easier to validate changes.

> I=E2=80=99ll leave this to WG Chairs, Steve, and Moritz and whomever c= ontributes to
> clarifying a contribution and approval process for the Matroska spec, = now
> that the one for EBML is getting very close to completed (I hope).

IMO yes, EBML is in a good shape now.

> The current Matroska spec is on a website, in Drupal posts, which is n= ot so
> RFC-like and doesn=E2=80=99t offer the same list of features for colla= boration as
> github. I suggest we work Matroska specification website in a GitHub r= epo
> (wherever that may be located).

Yes. Also the old specs will likely remain as they are, at least a legacy reference. We'll probably have a different URL for the official<= br> RFC for EBML and Matroska (in addition to being published wherever
RFCs are).

> Ashley=E2=80=99s draft repo at
> https://github.com/ablwr/mkv_jeky= ll_poc/blob/gh-pages/index.md represents
> only https://matroska.org/technical/specs/inde= x.html. My initial PR at
> https://github.com/ablwr/mkv_jekyll_poc/p= ull/1/files mostly focuses on
> removing the redundancy with the EBML specification and instead deferr= ing to
> that as a dependency.
>
> For next steps I propose moving the Element Table from
> https://matroska.org/technical/specs/ch= apters/index.html. I think eventually
> we could have a build process that combining information from specdata= .xml
> with the rest of the specification to make nice human-readable version= s and
> interactive tables of the Matroska spec, but for specification work I = think
> it may help to separate the EBML Schema data of the table and the rule= s and
> specification of Matroska into separate documents (one in xml and one = in
> markdown).

Sounds good.

> Also I propose moving copies of other Matroska specification pages to = the
> GitHub repo for refinement. I suggest starting with these:
> https://matroska.org/technical/diagram/index.h= tml
> https://matroska.org/technical/specs/notes.html<= /a>
> https://matroska.org/technical/order/index.html<= /a>
>
> And then moving on the the pages to focus on the Top Level Elements, s= uch
> as:
> https://matroska.org/technical/specs/ch= apters/index.html
> https://matroska.org/technical/cover_art/ind= ex.html (expanding this to cover
> other types of Attachments)
>
> I think through this work we could separate the current content of
> m= atroska.org in information that should become part of a Matroska RFC sp= ec
> and other data that is intended to support that (such as the info on u= ser
> guides, faq, downloads, logos, etc).

We could use /technical/drafts/

> I=E2=80=99m a bit inspired by the IETF work on Opus where there is now= the Opus RFC
> https://tools.ietf.org/html/rfc6716 and a supplementary<= br> > https://www.opus-codec.org website that contextualizes the RFC an= d
> integrations non-spec documentation, samples, and community informatio= n. I
> think a similar approach may work with Matroska.

http://specs.matroska.org/ ?

> Comments welcome.
>
> Best Regards,
> Dave
>
> Let me know your thoughts!
>
> Ashley
>
> On Thu, Mar 17, 2016 at 10:45 PM, Dave Rice <dave@dericed.com> wrote:
>>
>> Hi all,
>>
>> To test this out, I submitted a Pull Request to Ashley=E2=80=99s m= kv_jekyll_poc
>> repository. I am open to either matroska-spec-repo approach as Ash= ley
>> demonstrated in GitHub; however I have a preference for the jekyll= version
>> as we could work on the specifications in Markdown rather than dir= ectly in
>> HTML. I find Markdown patches a lot easier to read than HTML patch= es.
>>
>> The pull request is here: https://github.com/= ablwr/mkv_jekyll_poc/pull/1.
>>
>> The PR mainly has two changes:
>>
>> - The introduction is rephrased to say that the specification is W= IP and
>> associate it to CELLAR WG.
>>
>> > This document is a work-in-progress specification defining th= e Matroska
>> > file format as part of the [IETF Cellar working
>> > group](https://datatracker.ietf.org/wg/= cellar/charter/). But since it's
>> > quite complete it is used as a reference for the development = of libmatroska.
>> > Legacy versions of the specification can be found
>> > [here](/files/matroska.pdf) (PDF doc by Alexander No=C3=A9 --= outdated).
>> >
>> >=C2=A0 For a simplified diagram of the layout of a Matroska fi= le, see the
>> > [Diagram page](../diagram/index.html).
>>
>> I could also move the reference to Alexander No=C3=A9=E2=80=99s do= cument into a new
>> `Legacy Matroska` section to reference historical Matroska documen= ts while
>> contextualizing them as superseded by CELLAR=E2=80=99s work.
>>
>> - I also removed the section of the Matroska specification that is=
>> redundant to the EBML specification. Instead I added a section tha= t states
>> that Matroska is dependent on EBML like this:
>>
>> > ### Basis in EBML
>> >
>> > Matroska is a Document Type of EBML (Extensible Binary Meta L= anguage).
>> > This specification is dependent on the [EBML
>> > Specification](https://github.com/Matroska-Org/ebml-specification/blob/maste= r/specification.markdown).
>> > For an understanding of Matroska's EBML Schema, see in pa= rticular the
>> > sections of the EBML Specification covering [EBML Element
>> > Types](https://github.com/Matroska-Org/ebml-specification= /blob/master/specification.markdown#ebml-element-types),
>> > [EBML
>> > Schema](https://github.com/Matroska-Org/ebml-specification/blob/= master/specification.markdown#ebml-schema),
>> > and [EBML
>> > Structure](https://github.com/Matroska-Org/ebml-specification/blob= /master/specification.markdown#structure).
>>
>> One disadvantage of the mkv_jekyll_poc repo over the mkv_pages_poc= repo is
>> the presentation of the Matroska Element table,
>> http://ablwr.github.io/mkv_jekyll_p= oc/#elements-semantic, but I am
>> interested in the idea of re-designing the presentation of the tab= le.
>>
>> Thanks,
>> Dave Rice
>>
>>
>> > On Mar 14, 2016, at 4:29 AM, Steve Lhomme <slhomme@matroska.org> wrote:
>> >
>> > 2016-03-13 15:24 GMT+01:00 Ashley Blewer <ashley.blewer@gmail.com>:
>> >> We can always dedicate the table of elements to its own p= age -- the
>> >> current
>> >> page is pretty lengthy. Unless there are others who stron= gly favor the
>> >> other
>> >> approach, I can continue working on the Jekyll-based site= and it will
>> >> be
>> >> ready for future collaboration with version-control built= in.
>> >>
>> >> Steve, do you think the Jekyll site should mimic/replicat= e exactly the
>> >> current site design or is some change in aesthetics fine?= Don't know if
>> >> we're tied to having the Github Page site look like M= atroska.org or if,
>> >> since it's for spec viewing and work in particular, i= t's fine to appear
>> >> differently.
>> >
>> > The design doesn't matter too much. As long as it's e= asy to read and
>> > navigate.
>> >
>> >> Thanks much!
>> >>
>> >> Ashley
>> >>
>> >> On Sun, Mar 13, 2016 at 6:24 AM, Steve Lhomme <slhomme@matroska.org>
>> >> wrote:
>> >>>
>> >>> 2016-03-06 22:39 GMT+01:00 Ashley Blewer <ashley.blewer@gmail.com>:
>> >>>> Hey all!
>> >>>>
>> >>>> There's been some discussion about a collabor= ative framework with
>> >>>> which
>> >>>> to
>> >>>> continue work on the Matroska specification in a = code-development
>> >>>> context
>> >>>> after we've had conversations on this list. >> >>>>
>> >>>> I'd like to propose we migrate the Matroska s= pecification to Github.
>> >>>> As
>> >>>> I
>> >>>> mentioned before, I'm happy to carry this tra= nsition to completion on
>> >>>> a
>> >>>> MatroskaOrg-hosted or CELLAR-hosted Github organi= zational account,
>> >>>> but
>> >>>> would
>> >>>> like to hear from everyone on which site is the b= est for a
>> >>>> collaborative
>> >>>> environment.
>> >>>>
>> >>>> Option 1: Jekyll-based website that automatically= translates Markdown
>> >>>> to
>> >>>> HTML.
>> >>>> Option 1 repo: https://github.com/a= blwr/mkv_jekyll_poc
>> >>>> Please note this currently follows a Jekyll theme= standard but can be
>> >>>> made
>> >>>> to look like the Matroska site.
>> >>>>
>> >>>> The pros and cons are both in terms of ease of us= e. The benefits are
>> >>>> working
>> >>>> in the more human-readable Markdown instead of HT= ML. The negative is
>> >>>> that
>> >>>> running a local Jekyll server to preview work bef= ore submitting a
>> >>>> request is
>> >>>> harder than opening up a static site.
>> >>>>
>> >>>> Also, tables can be difficult to read and create = in Markdown.
>> >>>> However,
>> >>>> the
>> >>>> primary table located on the specification page i= s rendered via XML
>> >>>> and
>> >>>> would not have to be rewritten in Markdown (altho= ugh this example
>> >>>> does
>> >>>> have
>> >>>> it written in Markdown).
>> >>>>
>> >>>> Option 2: Standard HTML website.
>> >>>> Option 2 repo: https://github.com/ab= lwr/mkv_pages_poc
>> >>>> This has been translated to replicate the Matrosk= a site.
>> >>>>
>> >>>> Like I said above, previewing work doesn't re= quire running a local
>> >>>> server.
>> >>>> But work is harder to read because it's in HT= ML and most changes will
>> >>>> be
>> >>>> very text-based anyway.
>> >>>>
>> >>>> After we come to a decision, I can move relevant = specification
>> >>>> details
>> >>>> to
>> >>>> this site and it can be used to make changes to t= he standard after
>> >>>> decisions
>> >>>> are made here on CELLAR.
>> >>>
>> >>> I never heard of Jekyll before but it seems interesti= ng. That would be
>> >>> for the RFC based specs, so maybe the table of elemen= ts will go in the
>> >>> end or be presented differently. Until the RFC work i= s done we should
>> >>> keep the current specs as they are, just fixing thing= s when we find
>> >>> issues.
>> >>> So as a starting project I think the Markdown approac= h is good. We can
>> >>> always go back to pure HTML and continue from there l= ater. While the
>> >>> opposite is more work and not trivial.
>> >>>
>> >>>> My best,
>> >>>>
>> >>>> Ashley Blewer
>> >>>>
>> >>>> _______________________________________________ >> >>>> Cellar mailing list
>> >>>> Cellar@ietf.or= g
>> >>>> https://www.ietf.org/mailman/l= istinfo/cellar
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Steve Lhomme
>> >>> Matroska association Chairman
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Steve Lhomme
>> > Matroska association Chairman
>> >
>> > _______________________________________________
>> > Cellar mailing list
>> > Cellar@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cel= lar
>>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar >
>



--
Steve Lhomme
Matroska association Chairman

--001a113ee9f0776d8b0530f46f26-- From nobody Sat Apr 23 16:33:11 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 1D9F512B061 for ; Sat, 23 Apr 2016 16:33:10 -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 cRRkT0Teiv15 for ; Sat, 23 Apr 2016 16:33: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 24D1412B008 for ; Sat, 23 Apr 2016 16:33:08 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:38348 helo=[10.0.1.5]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1au72u-000BJF-Ow; Sat, 23 Apr 2016 19:33:07 -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: Date: Sat, 23 Apr 2016 19:33:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9D064728-1A0A-4632-B566-2F97DACC7B78@dericed.com> References: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com> To: Nithin Mathew Kurien 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 on textual expressions of floats in EBML 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: Sat, 23 Apr 2016 23:33:10 -0000 Here's an updated patch for float ranges in EBML Schema that = incorporates Nithin's advice. A pull request is here: = https://github.com/Matroska-Org/ebml-specification/pull/61 =46rom cbe07820fe85ed0aa4c591727cdc9f88a2339e11 Mon Sep 17 00:00:00 2001 From: dericed Date: Sun, 17 Apr 2016 09:05:24 -0400 Subject: [PATCH] define textual expression of floats in ebml schema --- specification.markdown | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/specification.markdown b/specification.markdown index cc39012..3f262b9 100644 --- a/specification.markdown +++ b/specification.markdown @@ -271,13 +271,26 @@ An Identically-Recurring Element is an Element = that may occur within its Parent =20 #### Expression of range =20 -The `range` attribute MUST only be used with EBML Elements that are = either `signed integer` or `unsigned integer`. The `range` attribute = does not support date or float 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: +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: =20 - - `x-y` where x and y are integers 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, meaning that the value MUST be = greater than `x`. - - `x` where `x` is an integer, meaning that the value MUST be equal = `x`. + - `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`. =20 -The `range` may use the prefix `not ` to indicate that the expressed = range is negated. +The `range` may use the prefix `not ` to indicate that the expressed = range is negated. Please also see the section on [textual expression of = floats](#textual-expression-of-floats). + +#### 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](http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf) = (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 |=20 +|-------------------|-----------------------------------------| +| 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 immediately preceded by a letter = `p`, then the `-` (hyphen) represents the separator between the minimal = and maximum value permitted by the range. =20 #### Note on the Use of default attributes to define Mandatory EBML = Elements =20 --=20 2.8.0 From nobody Sat Apr 23 16:47: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 C97EB12B074 for ; Sat, 23 Apr 2016 16:47:49 -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 zmgOnQzna9J2 for ; Sat, 23 Apr 2016 16:47: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 5831A12B019 for ; Sat, 23 Apr 2016 16:47:48 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:38277 helo=[10.0.1.5]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1au7H7-000cNV-1c; Sat, 23 Apr 2016 19:47:47 -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: Date: Sat, 23 Apr 2016 19:47:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160314081136.GC25555@bunkus.org> <56E71710.2000609@xiph.org> <524C94C8-084B-47E4-B101-CAD701EB94C5@nostrum.com> To: Steve Lhomme 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: Ben Campbell , cellar@ietf.org, "Timothy B. Terriberry" Subject: Re: [Cellar] license of the Matroska specification 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, 23 Apr 2016 23:47:50 -0000 > On Mar 20, 2016, at 5:43 AM, Steve Lhomme = wrote: >=20 > 2016-03-14 20:59 GMT+01:00 Ben Campbell : >> On 14 Mar 2016, at 14:54, Timothy B. Terriberry wrote: >>=20 >>> Moritz Bunkus wrote: >>>>=20 >>>> Hey, >>>>=20 >>>> just like the EBML specs we haven't really talked about a license >>>> yet. I'm fine with CC BY 4.0. Steve? >>>=20 >>>=20 >>> To allow the IETF to publish the documents, authors are required to = grant >>> a license to the IETF as detailed in BCP 78 Section 5.3 >>> . The IETF in turn = grants a >>> license to everyone, as detailed at = >>> (apologies for the non-https link). >>>=20 >>> The IETF does not require copyright assignment, so of course it is >>> possible to also publish the material under other licenses (as long = as it >>> does not claim to be an RFC). See RFC 5377 Section 4.5 >>> for details. >>=20 >>=20 >> To be clear, submitting an internet draft with the standard = boilerplate >> assigns copyright of the _draft_ (and resulting RFC) itself to the = IETF >> trust, in addition to the authors. That does not restrict the authors = from >> publishing other versions with different copyrights. >=20 > Fine with me for the IETF document. > The one on matroska.org should be like the EBML one, CC BY 4.0. I send a pull request here = https://github.com/ablwr/mkv_jekyll_poc/pull/2 that matching the = licensing style of the EBML repo in the = https://github.com/ablwr/mkv_jekyll_poc repo. Dave Rice= From nobody Sun Apr 24 08:08:29 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 67E5612B052 for ; Sun, 24 Apr 2016 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGL1thB7QuA5 for ; Sun, 24 Apr 2016 08:08:26 -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 8DD2312B018 for ; Sun, 24 Apr 2016 08:08:26 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id C6A532AFAC3C; Sun, 24 Apr 2016 17:08:20 +0200 (CEST) Received: from sweet-chili.local (unknown [10.55.1.18]) by liselle.bunkus.org (Postfix) with ESMTPS id 5C0EE2AFAC35 for ; Sun, 24 Apr 2016 17:08:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016040101; t=1461510498; bh=xPtOZoqK5tmKrHnlUrd0XlHq65DKIzemid/WPxvQs0U=; h=Date:From:To:Subject:References:In-Reply-To; b=GpWa83z6v6oEleCzojSd3Xz+TAYTKQrF8BWDTMvo9vEV1nWD4wMGUfhK8g24MJxqa EStDH0fWfYmDA6FFQ0Sp97CVH7HgUSVi1hTGjiHvoFPCXuMGL7ClldSHbeuuLcsCSZ fFjsysHbTpH8tDfvEc8dPunDztGZDWCrz4DXeIx1Hjbl8Qs0ITii+90UeL8Kgwmu0P Igw9bnqP0yZZ1IKoWC2V2jspdkCykRwFljv4MkaCMc7zzvUb7mreWkmFhrB1eKySCk Sb7HBJJiOnixXNugs5OkoRGuY6eNfMy3gzd9hJq1h+0bcrHAOR2lCZLtcvMu2L2zbZ pqJ6Gu9kPqAXY+I43DKTB6CLgqVuy/cHVCjthvEgQj3JMVQNFwLjqJ0tmrcpfX8Hfv gWOlBbztmgZf84SMXH7C3t1gR9YYXR7LR0g52Oe+rwYSL0zGRd1aZjvnOGzonBPMud 8oGOANXB/60AJvBdqBCFrmfTWF+UsOO8WEpnVQTakIIHTl5i6N5T/ssQ/hXCnPUxtP IswtnbYgEmcjXSCsr8rNl/0hMJT+5kFpP+ovaTvD339HgyBeCaQmZSyidHkXvX/CEm 22bvaRXUp3M5FNPlW3BMvZz747ChS28TAG7YaFG2ZD/Y83y5c+1cf7x+KZtL11jvDC VbLztmKSM8iUOHC/KvOcud6A= Received: by sweet-chili.local (Postfix, from userid 1000) id D6D7057B30B; Sun, 24 Apr 2016 17:08:17 +0200 (CEST) Date: Sun, 24 Apr 2016 17:08:17 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160424150817.GE5603@bunkus.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ey/N+yb7u/X9mFhi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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] Proposal to work on Github Pages site 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, 24 Apr 2016 15:08:28 -0000 --ey/N+yb7u/X9mFhi Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, thanks again for working on this, Ashley. As there haven't been any votes against Jekyll and no specific complaints with your work I've just copied your repository over to the Matroska-Org organization: https://github.com/Matroska-Org/matroska-specification I've decided not to use Github's cloning functionality in order not to confuse users by the "cloned from=E2=80=A6" message =E2=80=93 the official = repo should look official, too ;) The history's been preserved, of course. I've also adjusted the URL to the pages site. Kind regards, mosu --ey/N+yb7u/X9mFhi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJXHOFhAAoJEHSvAK3y4yyFi68P/RDp1y4c1StBaFaNTC7+3KCs bN1V/Hz4pBjXwTmfVQF240iSuEheKtmsYx4O+VsrPeO6NpcLdZ9Rglj/N1Nqp+MD W512wfe0eXhgJaP5Vy2is1XE0qazwAwLCbiAa7NLYE0RBJRgwgw4zk5KelOGZs8k Nt2f5uGaBIYFnZ1kQTKKyZyFKWIrzcv/DLctaI5rZ/TpUqVfnobp1neEvnoULWvw si+VJd91Ookk8VK4NJrsCVjOw0/xc1yl41WxhQYZWpbHoARBLTqsQE0n/nRz5R6N grWExQDcdZsQCxQsZ9bABCurQx42U/gPWOvEIv1OyzvZwIcNdMIdPAiEPUF9Ineh mvQI/vavpvf5atm2u/oeHWdAaVJBGugPIx074YQA0Lu0+PjBQn5XkMwVTiSOohWT TUJ9orBA7wAuMRr5rmxiatjl/D7ksBma8CyTvtiN2S+mfvMgyp3W0Dy4Skgk5erl jcQmzTvNnUusF5UO4NsiVnT3BR7N6zmEHDpazwmvwNNl487d2G5CKCQIFofWBU3G WHEaB0NzWeZWT2vB5i+JFg653JKGWYM2ESQ9Qkf7Tao5BN9Ofv2wi0LsNuAqlzC3 cxk9sBdB5w+JM1cBIl3rm/c/F+0tP0352VptSqe9KwocgTluAuS9dqFgZH9uyzUl PXR+82wKjP4DFzpMyMmx =zlLC -----END PGP SIGNATURE----- --ey/N+yb7u/X9mFhi-- From nobody Sun Apr 24 08:11: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 CAFB212D516 for ; Sun, 24 Apr 2016 08:11:25 -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 IsrtSJFCQImX for ; Sun, 24 Apr 2016 08:11:23 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 5E2AB12D137 for ; Sun, 24 Apr 2016 08:11:23 -0700 (PDT) Received: by mail-ig0-x22f.google.com with SMTP id bi2so47689903igb.0 for ; Sun, 24 Apr 2016 08:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4gwe+mSf3eN/5QwK62la7/Z31GHz2hgJ/UnxAHmchVw=; b=SL76Oq+AH6KsoqEnRJpK5CBtHf5NuG9/pAfceS6DGA7k4CYDrnaxs2x6sWrpvZDZq1 4GS1IJD+z/zrGd6uCn9DWVKifKOwJtfxaKlMiT/7/Lv8EJvZSwjEjLkNVnMCbcqoBTXx 2GjmmDF5cJUBq26nLUN0ewCZDQs9qTY+QRB0B4QsuUoPreHqdweGNwDdmyNtXWtqn/bt ZxpNdQcFL5bOHBlpt4j52/ryCZPp2qPL36/cJXD1+B7stjNVROrHUycSPy7ep8FUkdnz IFiM/D0Zc4PumHIeXdvpp4YCHSK4XWtXcpvUxCHXfmtaDETcSpLoUoWyyFwyfHUhUe55 BQlQ== 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=4gwe+mSf3eN/5QwK62la7/Z31GHz2hgJ/UnxAHmchVw=; b=a2v7YkGOQtjhsGl4yljczpVn6CbRsNru8C4k2df2tXcFvMNc5GulVLDarvgoVe/8WN +IpCNIMgsiRlHuXo0UXBey7aejvKF4hmqerprgIFX3xQBWx4TX9VJSBMg52dfIk+W1g0 2/gtl49et+HKtTKn/j7ubUnm4dfPD8Dubid3EMEOPfAc2xak3nRFhJGlrWGbUzi5c/+a LYZuQ3H2suvIp0cyugPsQJvZqvuQS22rpkmNWSS3q0EqcZjc1R83TxylXir+8uW6IKLd 8DRrA9KBwJr9T2LyDq1vBL5T+S5gmze0t30RonVz5gmhK5IHYsqN4cpMfD8/zTyk00tb bdUg== X-Gm-Message-State: AOPr4FVSNc+doI8DBaPY6aVjOfsJnq/F3EjOrRaQi//mkCf7b/7LRR+mhwZKuEw8e3vGtdeBgvzb6FS8a5akGQ== MIME-Version: 1.0 X-Received: by 10.50.36.9 with SMTP id m9mr7852411igj.91.1461510682694; Sun, 24 Apr 2016 08:11:22 -0700 (PDT) Received: by 10.79.9.196 with HTTP; Sun, 24 Apr 2016 08:11:22 -0700 (PDT) In-Reply-To: <20160424150817.GE5603@bunkus.org> References: <20160424150817.GE5603@bunkus.org> Date: Sun, 24 Apr 2016 11:11:22 -0400 Message-ID: From: Ashley Blewer To: Moritz Bunkus Content-Type: multipart/alternative; boundary=089e013c69c213dfca05313c79cd Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Proposal to work on Github Pages site 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, 24 Apr 2016 15:11:25 -0000 --089e013c69c213dfca05313c79cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Apr 24, 2016 at 11:08 AM, Moritz Bunkus wrote: > Hey, > > thanks again for working on this, Ashley. > > I'll continue to work on it with gusto! > As there haven't been any votes against Jekyll and no specific > complaints with your work I've just copied your repository over to the > Matroska-Org organization: > > https://github.com/Matroska-Org/matroska-specification > > I've decided not to use Github's cloning functionality in order not to > confuse users by the "cloned from=E2=80=A6" message =E2=80=93 the officia= l repo should > look official, too ;) > > Emphatically agree! > The history's been preserved, of course. I've also adjusted the URL to > the pages site. > > Kind regards, > mosu > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --089e013c69c213dfca05313c79cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 24, 2016 at 11:08 AM, Moritz Bunkus <<= a href=3D"mailto:moritz@bunkus.org" target=3D"_blank">moritz@bunkus.org= > wrote:
Hey,

thanks again for working on this, Ashley.

I'll continue to work on it with gusto!
=C2=A0
As there haven't been any votes against Jekyll and no specific
complaints with your work I've just copied your repository over to the<= br> Matroska-Org organization:

https://github.com/Matroska-Org/matroska-speci= fication

I've decided not to use Github's cloning functionality in order not= to
confuse users by the "cloned from=E2=80=A6" message =E2=80=93 the= official repo should
look official, too ;)

Emphatically agree!
=C2=A0
The history's been preserved, of course. I've also adjusted the URL= to
the pages site.

Kind regards,
mosu

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


--089e013c69c213dfca05313c79cd-- From nobody Sun Apr 24 08:39: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 A8DCA12B02A for ; Sun, 24 Apr 2016 08:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 KDf08uijS4sd for ; Sun, 24 Apr 2016 08:39:56 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 8905F12B013 for ; Sun, 24 Apr 2016 08:39:56 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id o66so167559731ywc.3 for ; Sun, 24 Apr 2016 08:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=h7zn4TAhpVH3bKauUqVz61+7Gh2Fd5IO3V5L1bHdOxY=; b=yVg4XCO5BF4L51emO+3QIYI1+0nlzry40AE2Ny0WIGmzNjI46H8UgdfeUHxJq8PScX TQ8jplPTsBaDjYJJos+TGny6Y24lW790EsLlmeyrExU5YzbGQ2BfxJyZhsKcVEr8U4xP DgbvznmMNeB3JzuBW1Lxxe3DS42Puc1WmZTiauphiR5gtIDbxNBLWqNIisRHo3Z3ezen OaPvq3XWxw5HsSR601OYVTKT7eVCJx5XaHS94dPeBCaMUdJPDOpbt/hr2WWasoY2x5vE tnX/v/6crG5UGyU3/Xsf/W9CQcnUWgtEQSBziA2QCoOtEkxko3OQ2RzFVA6Du0kyTfqf 9jtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=h7zn4TAhpVH3bKauUqVz61+7Gh2Fd5IO3V5L1bHdOxY=; b=N6NT5X8m3zXJth3I7pKnb3tqdZnsk/8Nvq0T/eYg77aN6VAFMEnx3fJVCd39Qyxt6D edbuW0OojOQXcsAytgWYaIldwpZa/egFwByWsqAv8jA+JHMLQh8lBi5zPjgfoNt/YsR4 dWOljotkxWax7AYv6Z7n4X76/5WJLuVFBwa0sHqA/ipk7M+QP9/rfp3uXIr5LUYSQVCw sVLr3K5Xzxkjb+XHU2z7tQ7EhtRb7JtU0meTST+4r+Io6Qll0hmrd4ycUh69eso12Aip m3jrCd4U/o2E6qqRghRlg9u/f1dtHN7p5d1WIAvETM0Ds6T++43hxF9zwcq8oooEIwSL zVCA== X-Gm-Message-State: AOPr4FWh1QFZC2Us9YzQIFo678fm03BNEouFs2fGi4WBWg2YM1/nN2tsXmzQwCqX0q+zqGHMF4Jkc28bcl8PJg== MIME-Version: 1.0 X-Received: by 10.129.98.139 with SMTP id w133mr12452225ywb.222.1461512395687; Sun, 24 Apr 2016 08:39:55 -0700 (PDT) Received: by 10.129.116.137 with HTTP; Sun, 24 Apr 2016 08:39:55 -0700 (PDT) Date: Sun, 24 Apr 2016 21:09:55 +0530 Message-ID: From: Nithin Mathew Kurien To: cellar@ietf.org, Discussion about the current and future development of Matroska Content-Type: multipart/alternative; boundary=001a11470a7c2e49a505313cdf59 Archived-At: Subject: [Cellar] Channel Positions for Multichannel LPCM Track Inside Matroska 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, 24 Apr 2016 15:39:58 -0000 --001a11470a7c2e49a505313cdf59 Content-Type: text/plain; charset=UTF-8 Hi, Currently the specification for storing a multichannel LPCM track (CodecID A_PCM/INT/LIT) inside a Matroska file [1, 2], does not specify a way to indicate the channel positions of the track. Due to this, players find it difficult to map the channels to the correct speaker positions when playing such a track. MakeMKV employs a workaround for this problem. It stores the track under the CodecID A_MS/ACM, along with a WAVEFORMATEXTENSIBLE structure in CodecPrivate. This structure contains a field called dwChannelMask which specifies the channel positions [3]. This is identical to the way LPCM is stored inside AVI files. The problem with this approach is that most players do not recognise the CodecID A_MS/ACM, except for a few open-source players like Kodi [4]. In the case of a FLAC track (inside either a raw .FLAC file or a .MKA file), we can specify an optional WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag [5]. Could a similar solution be implemented for LPCM inside Matroska too? On a related note, the ffmpeg documentation [6] specifies additional channel positions which are not found in the Microsoft documentation [3], like Wide Left and Wide Right speakers. Are these speaker positions recognised by players when reading WAV files? [1] https://matroska.org/technical/specs/codecid/index.html [2] http://haali.su/mkv/codecs.pdf [3] https://msdn.microsoft.com/en-us/library/windows/hardware/dn653308(v=vs.85).aspx [4] http://www.makemkv.com/forum2/viewtopic.php?f=8&t=2530 [5] https://sourceforge.net/p/mediainfo/discussion/297609/thread/164b4fb3/ [6] https://ffmpeg.org/doxygen/2.2/channel__layout_8h_source.html Thanks and regards, Nithin --001a11470a7c2e49a505313cdf59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Currently the specification for sto= ring a multichannel LPCM track (CodecID A_PCM/INT/LIT)=C2=A0inside a Matros= ka file [1, 2], does not specify a way to indicate the channel positions of= the track. Due to this, players find it difficult to map the channels to t= he correct speaker positions when playing such a track. MakeMKV employs a w= orkaround for this problem. It stores the track under the CodecID A_MS/ACM,= along with a WAVEFORMATEXTENSIBLE structure in CodecPrivate. This structur= e contains a field called dwChannelMask which specifies the channel positio= ns [3]. This is identical to the way LPCM is stored inside AVI files. The p= roblem with this approach is that most players do not recognise the CodecID= A_MS/ACM, except for a few open-source players like Kodi [4].=C2=A0
<= div>
In the case of a FLAC track (inside either a raw .FLAC f= ile or a .MKA file), we can specify an optional=C2=A0WAVEFORMATEXTENSIBLE_C= HANNEL_MASK tag [5]. Could a similar solution be implemented for LPCM insid= e Matroska too?

On a related note, the ffmpeg docu= mentation [6] specifies additional channel positions which are not found in= the Microsoft documentation [3], like Wide Left and Wide Right speakers. A= re these speaker positions recognised by players when reading WAV files?

[3]=C2=A0https://msdn.microsoft.co= m/en-us/library/windows/hardware/dn653308(v=3Dvs.85).aspx

Thanks and regards,
Nithin=
--001a11470a7c2e49a505313cdf59-- From nobody Sun Apr 24 17:30:19 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 5C8CC12B05F for ; Sun, 24 Apr 2016 17:30:17 -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 7AQ_1vO-Qv7G for ; Sun, 24 Apr 2016 17:30:13 -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 C4EDB12B027 for ; Sun, 24 Apr 2016 17:30:13 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:37988 helo=[10.0.1.5]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1auUPh-002XTi-2I; Sun, 24 Apr 2016 20:30:13 -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: <56FAC283.7040609@xiph.org> Date: Sun, 24 Apr 2016 20:30:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <621429AD-FBDC-4ADA-915D-BA780A788EF1@dericed.com> References: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> <442FEE5C-FCE3-4966-AFA0-CF6159E79C39@dericed.com> <56F97437.7090208@xiph.org> <2C8E9DA4-C7BE-47F4-AA26-3AA6D8A99163@dericed.com> <56FABAAD.2060003@xiph.org> <2BE0712A-A849-403E-AA14-3A738F75A890@dericed.com> <56FAC283.7040609@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] Proposal to work on Github Pages site 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, 25 Apr 2016 00:30:17 -0000 Hi Timothy, > On Mar 29, 2016, at 1:59 PM, Timothy B. Terriberry = wrote: >=20 > Dave Rice wrote: >>=20 >>> On Mar 29, 2016, at 1:26 PM, Timothy B. Terriberry = wrote: >>>=20 >>> Dave Rice wrote: >>>> Tim, how 'done' should we be before submitting as a draft? >>>=20 >>> The normal bar for an individual draft is, "There are some words on = a page." >>=20 >> In that case, here's = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown. >=20 > It still has to be submitted through the normal datatracker: > https://datatracker.ietf.org/submit/ >=20 > Submissions are currently closed in preparation for next week's = meeting in Buenos Aires (as they are two weeks before every meeting, to = give people time to read the drafts before the meeting). They will = re-open on Monday. I'm taking a look at the submission process in consideration of = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown. Beyond "words on a page" the upload page seems to require = "Either a plain-text document or a valid .xml file which can be = processed by the xml2rfc processor must be provided". I haven't done this before but since we're working almost exclusively in = markdown (in the FFV1, EBML, and MKV repos) I'd like to find an = efficient way to create a Makefile or process to convert markdown to an = upload-friendly document. I see some discussion in IETF lists about = consideration of supporting markdown as a submission format. I've been = looking at the approach used here = https://github.com/miekg/mmark/wiki/Syntax, but wanted to ask for advice = before proceeding too far. Thanks, Dave Rice From nobody Mon Apr 25 16:51:31 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 3572C12D0B7 for ; Mon, 25 Apr 2016 16:51:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=mozilla-com.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 Y4hXGmTg5erZ for ; Mon, 25 Apr 2016 16:51:26 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC3812B00A for ; Mon, 25 Apr 2016 16:51:25 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id r5so64444289pag.1 for ; Mon, 25 Apr 2016 16:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Ul9CQOgrJa9X4FNzSqVBBiFecXjw9Bki4KxadLaCa/4=; b=pX1ijv4rxT3xSYlHPu1VW5bHcZYq2T3T5wG/1KHXh32Tg+ttd/B2w5WY9+KsuQEBU9 mQ2eAvvbFDBDK13DJ6JkkiUe3U3x7VUfSYlEw1uRtRGply4+W3dVgLkr2+RyBsN6HGs7 XeeY6I/6os1BDMWNyhr+Jgn3b5A4V0shgrxEx6iM1EwoPwhhC+1LwSeG2EovsmnB3YJd PWteP0qDKU8gQtXSUHjm/vfZitbxry4FZc/UlkI0iUU0rN+LU/gcVYFmohk7WYwC1QWR PJIpAES/CYiB5iNVPa9HGNFVXRt2tPzDivOZvhav9/jV63J112H5iuvmEhpmuMHzPqo1 Lrxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Ul9CQOgrJa9X4FNzSqVBBiFecXjw9Bki4KxadLaCa/4=; b=iucZIdOQoLoqk+oeqtVZDINOxYonj2fu2zCywMqZaiHUPaQcEmul89ey3pP9k/8l1w ReZpO3eOarp/0bqxwYjXj0tJbAPp8MskELehsMAyTYPlV8KABl8gRp/oup2TJQtrByK/ zjmpqfds9Ga+Suyt0CnM8q4pvCYB9zp1+F/K43Y8wNIvRIdFRsX91JW3gle5onUptn1U xQin3trqFp+qsix/JXLXj7VgawG68Y75KM+UzcMDXqUoyxM8Lli0Kj6fZJGeOk/QITCy KLYB/tSL2+Hbp+bvvAKcAU/TePEK2bET8nLVqo5FEyqhzqyODXWEu8qPCC3VdwHvJmy9 6GEQ== X-Gm-Message-State: AOPr4FXhAvb++tfsQZS5BymvMknqe7dFZ6F38Ep+TGWZtOLNwlhFR2/GRcYKrpIlnmHD+KI8 X-Received: by 10.66.47.196 with SMTP id f4mr188798pan.126.1461628285425; Mon, 25 Apr 2016 16:51:25 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:7e7a:91ff:fe9e:8126? ([2620:101:80fc:224:7e7a:91ff:fe9e:8126]) by smtp.gmail.com with ESMTPSA id hk7sm32806455pad.25.2016.04.25.16.51.23 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 16:51:24 -0700 (PDT) To: cellar@ietf.org References: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> <442FEE5C-FCE3-4966-AFA0-CF6159E79C39@dericed.com> <56F97437.7090208@xiph.org> <2C8E9DA4-C7BE-47F4-AA26-3AA6D8A99163@dericed.com> <56FABAAD.2060003@xiph.org> <2BE0712A-A849-403E-AA14-3A738F75A890@dericed.com> <56FAC283.7040609@xiph.org> <621429AD-FBDC-4ADA-915D-BA780A788EF1@dericed.com> From: Thomas Daede X-Enigmail-Draft-Status: N1110 Message-ID: <571EAD7A.2010905@mozilla.com> Date: Mon, 25 Apr 2016 16:51:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <621429AD-FBDC-4ADA-915D-BA780A788EF1@dericed.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] Proposal to work on Github Pages site 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, 25 Apr 2016 23:51:30 -0000 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 On 04/24/2016 05:30 PM, Dave Rice wrote: > Hi Timothy, > >> On Mar 29, 2016, at 1:59 PM, Timothy B. Terriberry wrote: >> >> Dave Rice wrote: >>> >>>> On Mar 29, 2016, at 1:26 PM, Timothy B. Terriberry wrote: >>>> >>>> Dave Rice wrote: >>>>> Tim, how 'done' should we be before submitting as a draft? >>>> >>>> The normal bar for an individual draft is, "There are some words on a page." >>> >>> In that case, here's https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown. >> >> It still has to be submitted through the normal datatracker: >> https://datatracker.ietf.org/submit/ >> >> Submissions are currently closed in preparation for next week's meeting in Buenos Aires (as they are two weeks before every meeting, to give people time to read the drafts before the meeting). They will re-open on Monday. > > I'm taking a look at the submission process in consideration of https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown. Beyond "words on a page" the upload page seems to require "Either a plain-text document or a valid .xml file which can be processed by the xml2rfc processor must be provided". > > I haven't done this before but since we're working almost exclusively in markdown (in the FFV1, EBML, and MKV repos) I'd like to find an efficient way to create a Makefile or process to convert markdown to an upload-friendly document. I see some discussion in IETF lists about consideration of supporting markdown as a submission format. I've been looking at the approach used here https://github.com/miekg/mmark/wiki/Syntax, but wanted to ask for advice before proceeding too far. > Thanks, > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > From nobody Mon Apr 25 17:08: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 BAF9412D105 for ; Mon, 25 Apr 2016 17:08:35 -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 q9KOr1G6w431 for ; Mon, 25 Apr 2016 17:08:34 -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 119E512B00A for ; Mon, 25 Apr 2016 17:08:34 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id A24E1C30D9 for ; Tue, 26 Apr 2016 00:08:33 +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 L3-VJlVnI3gs for ; Tue, 26 Apr 2016 00:08:33 +0000 (UTC) Received: from [10.252.27.26] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id D6336C0137 for ; Tue, 26 Apr 2016 00:08:30 +0000 (UTC) Message-ID: <571EB178.7010902@xiph.org> Date: Mon, 25 Apr 2016 17:08:24 -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: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> <442FEE5C-FCE3-4966-AFA0-CF6159E79C39@dericed.com> <56F97437.7090208@xiph.org> <2C8E9DA4-C7BE-47F4-AA26-3AA6D8A99163@dericed.com> <56FABAAD.2060003@xiph.org> <2BE0712A-A849-403E-AA14-3A738F75A890@dericed.com> <56FAC283.7040609@xiph.org> <621429AD-FBDC-4ADA-915D-BA780A788EF1@dericed.com> <571EAD7A.2010905@mozilla.com> In-Reply-To: <571EAD7A.2010905@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Proposal to work on Github Pages site 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: Tue, 26 Apr 2016 00:08:36 -0000 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). From nobody Mon Apr 25 17:38: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 1C70812D09C for ; Mon, 25 Apr 2016 17:38:46 -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 7LZbFQiMtaxC for ; Mon, 25 Apr 2016 17:38:42 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 DD8BA12B01E for ; Mon, 25 Apr 2016 17:38:41 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id f89so1994136ioi.0 for ; Mon, 25 Apr 2016 17:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=t3+Zl4lTi1YIGYZ5eiRjTqTdnvqCmYhIIMkr59JE9Lk=; b=hue1a0i/fUDN4IOXt36q3dLoOyqxf68MftauHkf4pFwdT1GtN1aXKJg3ecb+pU8VY7 B822MuKtm6eUKKQ8K43Cq8btZfN3eiDbT5wxXwOFvcbZ6RWSXOWy6ZGS9wFhci+VhQFN POxS3olNBzwchfsBtzhftE4d/k3Io+lLkVJV9e3H/zncleANaUBcG5+sPBerPgG3lSy5 iDTqg1uatQlIR6cA1+JapYTxW01KZrBAHwKgITAtyvTryG59lTiPsLzIARWuYPLlesmf 0cERRE0yqQKtdRrFQADTAvpLh3EuDmQRZoaCj52QMB82DFlszUqSeV0T4IF47FV4hQId k9CQ== 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=t3+Zl4lTi1YIGYZ5eiRjTqTdnvqCmYhIIMkr59JE9Lk=; b=MvP2QLW3r+RFUSlAC1RGDSKKYh9dJaJgeY/TjiOQ+3f3LytjJVRIefXliYUCWd4yHM gme0r9kOvWnHtPUgvc1EEycJ0CSSy7iZumE1AfLJ9cGPIlxTm0foGfjYNGbJr8B7kjzY ImfK+PkeW8C/L2h/4nX3DncMdgobQacS96Q37uT9Z0qXdZeRsAWOBeFmSEsHtbz2wWlJ nH2D2cvpqAC7RQfndAu94COFcJGPFXm/IgR/h1A/BpIHAjslmzfdvr0+S1le3NJKuT4P 9J6m/jaenxwGF4pZFZfUmu9LCIVy5EKrt5Tyt2EkIqY7qCjDU/dnlreSh6Q5aJ0kygf+ F8/Q== X-Gm-Message-State: AOPr4FWcwNTlN5gzqq2RwluFisOrdMlIR4eI+VUlBlPdyreXy0mSdUYXqD9j8VuTqsvwuiT2OKR3Q6DmlFkfXA== MIME-Version: 1.0 X-Received: by 10.107.147.138 with SMTP id v132mr203493iod.38.1461631121268; Mon, 25 Apr 2016 17:38:41 -0700 (PDT) Received: by 10.79.9.196 with HTTP; Mon, 25 Apr 2016 17:38:40 -0700 (PDT) In-Reply-To: <571EB178.7010902@xiph.org> References: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> <442FEE5C-FCE3-4966-AFA0-CF6159E79C39@dericed.com> <56F97437.7090208@xiph.org> <2C8E9DA4-C7BE-47F4-AA26-3AA6D8A99163@dericed.com> <56FABAAD.2060003@xiph.org> <2BE0712A-A849-403E-AA14-3A738F75A890@dericed.com> <56FAC283.7040609@xiph.org> <621429AD-FBDC-4ADA-915D-BA780A788EF1@dericed.com> <571EAD7A.2010905@mozilla.com> <571EB178.7010902@xiph.org> Date: Mon, 25 Apr 2016 20:38:40 -0400 Message-ID: From: Ashley Blewer To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=94eb2c05617ac6a4c505315883e3 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Proposal to work on Github Pages site 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: Tue, 26 Apr 2016 00:38:46 -0000 --94eb2c05617ac6a4c505315883e3 Content-Type: text/plain; charset=UTF-8 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 > --94eb2c05617ac6a4c505315883e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thomas, thanks for posting this!=C2=A0

On Mon, Apr 25, 2016 at 8:08 PM= , Timothy B. Terriberry <tterribe@xiph.org> 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 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

--94eb2c05617ac6a4c505315883e3-- From nobody Mon Apr 25 19:58: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 4909A12B05F for ; Mon, 25 Apr 2016 19:58: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 eSsGoa6GT4Ln for ; Mon, 25 Apr 2016 19:58:08 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E2C12B027 for ; Mon, 25 Apr 2016 19:58:08 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id u185so4759873iod.3 for ; Mon, 25 Apr 2016 19:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1OjbFCUgTsOBm51GfdqfAXm+5ON1IRFFicX7pNOIh8k=; b=y0E74YmQzL3LeoFaEAu1UWwxBKyAW18SckDlMGP0lq8TKf+5Z50Yd7TDQGlKo/M+W4 9DZubGpO5jlaOXSOAI7Oto3UUfTAYHBCosmUWi2sY265cbuNVh1QU7thO2oGKYfSYRDG LIUW6SSLyZFoAmKOx7p1tw40bs6HPxMCIbJSNvnDTF1LEwbsGBONrhXakzbdmfHT8KG5 tcQadbJ6QBquka6aJvZPOm5DKp+3G85mIQ57V3KzR5LBWg5po8nR6eKuH4Sevc6btfG9 PCUWsXFHwoFZGjxAmHgIBJ3L6GHxi0zQOJj5UAJ1ehvrYJ8PfIjdilkyzJeu6X6cxPSa 4l8Q== 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=1OjbFCUgTsOBm51GfdqfAXm+5ON1IRFFicX7pNOIh8k=; b=PMPjbW4lbeWBP4oDFREsHVEqxJRetluS8cnyjN6E5QR9xGrLRC0Zdsf+46aUCPTh+s nCiZJ9xWgINOlxCDrXGdeI2aBmhtZ0lLcbYgOBuQfn8ANMVDVv5KGQelaGyeD6imCm0+ zfJdsLDtmZjE6+s+ReCluWckXSE2YGxMnKvF42JlYzuQaTbAywFY2IzYr5bBFp6KWZun U82hb2Z/dWNI00a1ct4qNPCystrhzyizZfwlZQC5IPVN+IF6uOCMVCWs6wOkvN8mgaX+ yELDO/AdQ3QCJYNVuoR5N2B+Lh2UuKL0bYVQXJBBG610sf5jhGNV95wIMwJfss61Ourd Zz+w== X-Gm-Message-State: AOPr4FVJR8ZRkfFv3A6BhCXfG82c1oc3i7EJENLzWKYY1dRk0bAJICSJN+ULhXRLTpoS0vOkYTN0dCExcaGbJw== MIME-Version: 1.0 X-Received: by 10.107.147.138 with SMTP id v132mr629269iod.38.1461639487341; Mon, 25 Apr 2016 19:58:07 -0700 (PDT) Received: by 10.79.9.196 with HTTP; Mon, 25 Apr 2016 19:58:07 -0700 (PDT) In-Reply-To: References: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> <442FEE5C-FCE3-4966-AFA0-CF6159E79C39@dericed.com> <56F97437.7090208@xiph.org> <2C8E9DA4-C7BE-47F4-AA26-3AA6D8A99163@dericed.com> <56FABAAD.2060003@xiph.org> <2BE0712A-A849-403E-AA14-3A738F75A890@dericed.com> <56FAC283.7040609@xiph.org> <621429AD-FBDC-4ADA-915D-BA780A788EF1@dericed.com> <571EAD7A.2010905@mozilla.com> <571EB178.7010902@xiph.org> Date: Mon, 25 Apr 2016 22:58:07 -0400 Message-ID: From: Ashley Blewer To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=94eb2c05617a6eccf005315a769d Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Proposal to work on Github Pages site 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: Tue, 26 Apr 2016 02:58:12 -0000 --94eb2c05617a6eccf005315a769d Content-Type: text/plain; charset=UTF-8 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 >> > > --94eb2c05617a6eccf005315a769d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I demo'ed the above template and it seems promising, b= ut the Markdown would need a lot of work to get it integrated -- the curren= t MD document includes some unconventional HTML tags (abbr, pre) and the te= mplate also doesn't like the way the document can link to itself using = syntax like this:=C2=A0[SimpleBlock structure](#simpleblock_structure). Not= sure how well this will play with Github-pages.

I'l= l keep investigating. Also using the core component of this (xml2rfc), we m= ight be able to build our own Makefile that auto-generates an RFC.

Ashley

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

On Mon, Apr 25, 2016 at 8:08 PM, Timothy B. Terriberry <tterr= ibe@xiph.org> 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 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


--94eb2c05617a6eccf005315a769d-- From nobody Tue Apr 26 13:01:35 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 2D82F12D56C for ; Tue, 26 Apr 2016 13:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uvhEkwdJ_oY1 for ; Tue, 26 Apr 2016 13:01:33 -0700 (PDT) Received: from 10.mo179.mail-out.ovh.net (10.mo179.mail-out.ovh.net [46.105.79.46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F50312D522 for ; Tue, 26 Apr 2016 13:01:32 -0700 (PDT) Received: from player799.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 3597EFF8D66 for ; Tue, 26 Apr 2016 22:01:27 +0200 (CEST) Received: from [192.168.2.101] (p5DDB6630.dip0.t-ipconnect.de [93.219.102.48]) (Authenticated sender: jerome@francoallemand.eu) by player799.ha.ovh.net (Postfix) with ESMTPSA id EDD6D52006A for ; Tue, 26 Apr 2016 22:01:26 +0200 (CEST) From: Jerome Martinez To: cellar@ietf.org Message-ID: <104d0f51-4b95-509f-13e2-b305f5f7fe3d@mediaarea.net> Date: Tue, 26 Apr 2016 22:01:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 14490050327509930129 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekkedrjeelgddufeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: [Cellar] FFV1 slices count 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: Tue, 26 Apr 2016 20:01:35 -0000 Checking FFmpeg code for how FFV1 slices are constrained, I understand that: - FFmpeg encoder tries to find a value compatible with some constraints (minimum 2 rows and 2 columns, rows count must not be > 2x columns count, columns count must not be > 2x rows count, and slices count can not be more than 64). so 25 is acceptable (5x5, OK), 26 is not (13x2 or 2x13 are the only combinations, NOK) - FFmpeg decoder accepts any slices count below 256 I don't see any of these constraints in the current FFV1 specifications. I also don't see any reason to have these constraints: cases like 1 row and 64 columns could be used somewhere, not really worse than 8 rows and 8 columns (and maybe someday an encoder could compare compression performance an select 1x64 for compression performance with some frames). In 10 years, maybe we'll have 8K frames and CPUs with 1024 low-powered cores everywhere, having 32x32 slices (slices of 256x144 pixels) could make sense. On another side, the current specifications don't limit the count of slices, so having more slices than pixels on a row (so we have slices with 0 pixels) is theoretically possible. I would like to have comments on: - do we agree that we don't have any constraint on the slices count in the specification. FFmpeg implementation is a developer decision only and does not have any impact on the specification? - should we add a constraint about num_h_slices must be less or equal to the frame width, and num_v_slices must be less or equal to frame height? - In the future, we could have "profiles" as constraints for performance reasons, like "profile 1 = 720x576 pixels maximum, 64 slices maximum; profile 2 = 1920x1080 pixels maximum, 256 slices maximum", in addition to the core specifications without such arbitrary choices. From nobody Tue Apr 26 17:39: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 BEF4E12D590 for ; Tue, 26 Apr 2016 17:39:30 -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 abcDiphQoKyG for ; Tue, 26 Apr 2016 17:39:28 -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 926A312D0C8 for ; Tue, 26 Apr 2016 17:39:28 -0700 (PDT) Received: from mfilter47-d.gandi.net (mfilter47-d.gandi.net [217.70.178.178]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 4927CFB881 for ; Wed, 27 Apr 2016 02:39:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter47-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter47-d.gandi.net (mfilter47-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id IYn72HitVYE1 for ; Wed, 27 Apr 2016 02:39:25 +0200 (CEST) X-Originating-IP: 213.47.64.66 Received: from localhost (chello213047064066.6.14.vie.surfer.at [213.47.64.66]) (Authenticated sender: michael@niedermayer.cc) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 5131EFB882 for ; Wed, 27 Apr 2016 02:39:24 +0200 (CEST) Date: Wed, 27 Apr 2016 02:37:39 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160427003739.GF25812@nb4> References: <104d0f51-4b95-509f-13e2-b305f5f7fe3d@mediaarea.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A8xjPF+9FK49keUa" Content-Disposition: inline In-Reply-To: <104d0f51-4b95-509f-13e2-b305f5f7fe3d@mediaarea.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] FFV1 slices count 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, 27 Apr 2016 00:39:31 -0000 --A8xjPF+9FK49keUa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2016 at 10:01:26PM +0200, Jerome Martinez wrote: > Checking FFmpeg code for how FFV1 slices are constrained, I understand th= at: > - FFmpeg encoder tries to find a value compatible with some > constraints (minimum 2 rows and 2 columns, rows count must not be > > 2x columns count, columns count must not be > 2x rows count, and > slices count can not be more than 64). so 25 is acceptable (5x5, > OK), 26 is not (13x2 or 2x13 are the only combinations, NOK) > - FFmpeg decoder accepts any slices count below 256 >=20 > I don't see any of these constraints in the current FFV1 specifications. > I also don't see any reason to have these constraints: cases like 1 > row and 64 columns could be used somewhere, not really worse than 8 > rows and 8 columns (and maybe someday an encoder could compare > compression performance an select 1x64 for compression performance > with some frames). In 10 years, maybe we'll have 8K frames and CPUs > with 1024 low-powered cores everywhere, having 32x32 slices (slices > of 256x144 pixels) could make sense. >=20 > On another side, the current specifications don't limit the count of > slices, so having more slices than pixels on a row (so we have > slices with 0 pixels) is theoretically possible. >=20 >=20 > I would like to have comments on: > - do we agree that we don't have any constraint on the slices count > in the specification. FFmpeg implementation is a developer decision > only and does not have any impact on the specification? There is: 5.6.1 Restrictions In version 2 and later the maximum slice size in pixels is width*height ------------ 4 , unless the frame is smaller or equal 352x288 this is to ensure that fast multithreaded decoding is possible. > - should we add a constraint about num_h_slices must be less or > equal to the frame width, and num_v_slices must be less or equal to > frame height? I think a restriction stating that "each slice must contain at least one sample from each plane" should be added Otherwise that may lead to odd special cases where a slice has luma but no chroma samples > - In the future, we could have "profiles" as constraints for > performance reasons, like "profile 1 =3D 720x576 pixels maximum, 64 > slices maximum; profile 2 =3D 1920x1080 pixels maximum, 256 slices > maximum", in addition to the core specifications without such > arbitrary choices. >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar >=20 --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates --A8xjPF+9FK49keUa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlcgCdMACgkQYR7HhwQLD6uouwCgmW+Q4YBjN5eDpn4HhNsr6l59 ihgAn0YFwEA31bRgYUx+I79Pnhlgy6CD =Zt83 -----END PGP SIGNATURE----- --A8xjPF+9FK49keUa--