From nobody Wed Mar 2 09:01:30 2016 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BD71AD1A3; Fri, 19 Feb 2016 07:54:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160219155426.5552.89772.idtracker@ietfa.amsl.com> Date: Fri, 19 Feb 2016 07:54:26 -0800 Archived-At: X-Mailman-Approved-At: Wed, 02 Mar 2016 09:01:27 -0800 Cc: ben@nostrum.com, tessa.fallon@gmail.com, cellar@ietf.org, cellar-chairs@ietf.org Subject: [Cellar] cellar - Not having a session at IETF 95 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2016 15:54:27 -0000 Tessa Fallon, a chair of the cellar working group, indicated that the cellar working group does not plan to hold a session at IETF 95. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed Mar 2 09:01:31 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAB01A89E9 for ; Sun, 28 Feb 2016 14:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 zRP5YW9FCSdT for ; Sun, 28 Feb 2016 14:12:35 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 8F51E1A89BB for ; Sun, 28 Feb 2016 14:12:35 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id e185so118096748vkb.1 for ; Sun, 28 Feb 2016 14:12:35 -0800 (PST) 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=g1jw8W2dxeb/mEpLqhSoX9X2CykC+gMVV3MWkf32bu8=; b=vLYFUy1OB/yq5sr7O8vtcjYGSyOOgw60fk3ogOW4qBDqubT/E8XG4fxHuRHqPaISDo jYQukNvBWboayjvOS0EiTXmyIiNksDAdKOKpqrq+xlYHqNRG5vEk3GAOkAgSw3gyTUm+ 87F7xnmz4FZGUaKUkXZ9uhsVUfCGTtHcoCVR2SOoDXoraX32ia4NpWRoeZhpWmJZvaEU tkMUB2lYU5MWIb0WBLnG+i4XMOhfXeFdUE1ds8J1Te+DnpE4NkaE1TOrmMurNL9sy+ms 0VPzqEE62oKrHYFoQBanGZuLTZJrEOVDQFIpzJzv6bIbN5Z1zL8JZOZ23LDIso9Ks+GL sS9Q== 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=g1jw8W2dxeb/mEpLqhSoX9X2CykC+gMVV3MWkf32bu8=; b=cs7iGxjaRlw74cgHYXHOj5fHKElcc+KqVOqKpS6QmJ0RgOGwiaFHplali/WZHkNcvc 9AqJVnsNKZpixu2YnDcnZwrMwob8owkAdVy6vUR0yTJ8V7LxzGouWUFiLNSH7zUfA9G+ yDo8lhy2scSHPrLbjb9W87Kl2iUmM6UJB6VaFIZiFH8LwtWILRuPimfiFSO4Yc8qqNHs 6adyRFIlEhcsAFOh7PgsGdZ0uQhH6uUhdP5AcscqlaaNIPkWeYY01boZOWRG9HBui3eD ifWzgTBeCt2a6yVuSQ4ahQ0yF+UDPQIZBcAueuZHv/loAEfumQPdrgtoKmyNI5k87li8 DTIw== X-Gm-Message-State: AD7BkJI8zXqLUT7WX5mCE4RBnryeCGXEhq2DN7C1SlIx6ZbeZpnF5tjtOm8PXnumEhf2KfXpjouXUN6HO5tdKw== MIME-Version: 1.0 X-Received: by 10.31.2.205 with SMTP id 196mr9123794vkc.18.1456697554718; Sun, 28 Feb 2016 14:12:34 -0800 (PST) Received: by 10.176.1.162 with HTTP; Sun, 28 Feb 2016 14:12:34 -0800 (PST) In-Reply-To: References: Date: Sun, 28 Feb 2016 23:12:34 +0100 Message-ID: From: madshi To: Steve Lhomme Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Wed, 02 Mar 2016 09:01:27 -0800 Cc: Discussion about the current and future development of Matroska , cellar@ietf.org, Nithin Mathew Kurien , Hendrik Leppkes Subject: Re: [Cellar] [Matroska-devel] Depth offsets for subtitles in case of 3D MVC tracks in MKV files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2016 22:12:37 -0000 2016-02-14 15:50 GMT+01:00 Steve Lhomme : > 2016-01-26 14:39 GMT+01:00 Nithin Mathew Kurien : >> Hi, >> >> It's like this. Suppose the MVC video track has 8 frames. Also suppose it >> has 5 Offset Metadata Sequences embedded in it at the time of encoding. >> (Sequence entries are in pixels, positive if in front of the screen, and >> negative if behind.) >> >> Frame 1 2 3 4 5 6 7 8 >> Seq1 5 1 -8 -2 -9 1 -3 -1 >> Seq2 8 1 0 8 -4 -5 4 -1 >> Seq3 -2 8 -3 -5 7 5 -5 -4 >> Seq4 9 0 0 -5 -2 1 -4 -1 >> Seq5 -9 3 -2 -4 -6 0 -3 6 >> >> If the M2TS container has 2 subtitle tracks P1, P2 and 1 menu track I1, then >> a mapping can be defined in the M2TS container like this: >> P1 : Seq1 >> P2 : Seq3 >> I1 : Seq4 > > OK, so it seems it's both in the header and in the track (the GOP is > part of the stream, I think). Yes. As Nithin Mathew explained (thanks!), there are SEI 3D depth info blocks inside of the video stream. We don't need to do anything about them. But there's additional data in the Blu-Ray playlist file(s) which assigns specific subtitle tracks to an "array index" in the SEI 3D depth info block. In the meanwhile nevcairiel and I have already added full support for all this 3D depth offset stuff to LAV Splitter/Video decoder and madVR, when playing back original Blu-Rays. But for Matroska there's no full solution possible yet, because the information in the playlist cannot be properly stored yet. It would be great if we could get an official solution for this soon, because we'd like to implement it "now", and we have the MakeMKV devs on board for this now, too. Basically I think what we need is one additional item for each subtitle track which simply assigns one SEI 3D depth array index to the subtitle track. E.g. something like "stereo_subtitle_offset_id", or whatever. The name is not important to me. Possible values I think are between 0..31 for 3D Blu-Rays. One additional piece of information would be which array indexes of the SEI 3D depth info block are assigned to IG (interactive graphics). This could be used by media players or video renderers to decide at which 3D depth to draw the user interface (GUI/OSD). FWIW, it could be none, one or multiple array indexes. So the information field in the MKV header would have to be some sort of list/array. Logically this info would probably belong to the video track. This is less important than the subtitle assignment, though. But would still be nice to have. Best regards, madshi. From h.leppkes@gmail.com Mon Feb 29 00:22:44 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3C11B2DC6 for ; Mon, 29 Feb 2016 00:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 0yQ-MKH_Hyoi for ; Mon, 29 Feb 2016 00:22:43 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 E08611B2DB5 for ; Mon, 29 Feb 2016 00:22:42 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id n186so37102958wmn.1 for ; Mon, 29 Feb 2016 00:22:42 -0800 (PST) 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=TFW3F7FSJ9eGCT7zxUlWeRv8OX8EUm2DaEp2qwqnqiQ=; b=ow8b5h1z/mT81bvTXgQRswjnm4w7qZ17PxJTqizeFBiLBUb7rD96KWy16gHFCHSYAB Ul0uvSqw2ksckjUKpbd8ezUT0iTUa8sXA+B3BiqrA4w6eg8RjVBueRKXmzqE5uNfo/mg k3jW3HLvbro78fP4Ew5fxxn+7BYlQj6tj3B7n+iXsjbLrGGeNH5IvG5baM22vrjBRDOE w3xtThue9GYrOC4lS8AVI4iKsVAYAKK5hNIbJbedj9XNIm3l4PADISANdhnyWvr4v8AV YbhKjFIynSVRkSMoOk7/hg1MGZ3nrGeuIGR3uxklgYfFQZKqHMBfCqkAvzI4XmFibHhQ ovTQ== 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=TFW3F7FSJ9eGCT7zxUlWeRv8OX8EUm2DaEp2qwqnqiQ=; b=Ayzhv648TrZxCdTVzpNxr/YqV1c/OHRTu37IUZl2dp7HDRLWtdPrKrmR/A+Kxu6Oqm xAR8yRfSCjNnOwj8kUYOafBfLVSK4c6vrIaRpc02MO4/Jsx2RefkFQwpbme9JphhtZNM +DcxmCuOdsjqLejLAY4BYeLqM1n1awwzPHqoSO8tc6C9pEpwl4wE7zLvLuTujlycLy3L oYPINY9bhRsXpe7YCJddQb5fYme1gAMc7TkhD0JnRZCOLt5hu8bW8F7gRZbNa9S8Lk13 5t5V8EznUprKbulQWFiFKFyoTF9hyW7OPe/JjdWsXiWhlpxFnS6OzxQ3bw6KhZS5J/j1 hQ1Q== X-Gm-Message-State: AD7BkJJtJB583DpY9KlRMwKjoMsHQWq6wQvFs4ZsIUeNiAV1p+2FEpoHXOlp+jPQ4o/1XF7vYdql2TD1XFeNTg== MIME-Version: 1.0 X-Received: by 10.28.148.207 with SMTP id w198mr7325234wmd.66.1456734161476; Mon, 29 Feb 2016 00:22:41 -0800 (PST) Received: by 10.27.212.12 with HTTP; Mon, 29 Feb 2016 00:22:41 -0800 (PST) In-Reply-To: References: Date: Mon, 29 Feb 2016 09:22:41 +0100 Message-ID: From: Hendrik Leppkes To: Steve Lhomme Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Wed, 02 Mar 2016 09:01:27 -0800 Cc: Discussion about the current and future development of Matroska , cellar@ietf.org, Nithin Mathew Kurien , madshi Subject: Re: [Cellar] [Matroska-devel] Depth offsets for subtitles in case of 3D MVC tracks in MKV files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 08:23:29 -0000 On Mon, Feb 29, 2016 at 8:51 AM, Steve Lhomme wrote: > > If we want the general case to work we may introduce an element at the > same level as CodecState that defines the Z-order for the Block. That > means it would have to translate the lookup index in the SEI to the > actual z-order value (if I understand correctly how it works). We need > to define if it's like the CodecState, ie it only changes from scene > to scene, not Block by Block. So it would be a State that needs to be > remembered when needed and only written when it changes. > > What is the range of depth allowed in Blu-Rays ? Are they discrete > value or floating values ? > The "depth" is defined in discrete pixel values in the BD SEI, ie. the offset to move it left/right for each eye, so it doesn't have a direct meaning of "depth", but just instructions on how to render it. Note that the way this is implemented on Blu-rays, the depth can change from frame to frame. Every GOP has a new SEI block which includes one offset for every frame in the SEI, so its controlled on a frame level, not a scene/GOP level. (( This time sent to the list as well. )) - Hendrik From nobody Wed Mar 2 09:01:34 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECFE1B2E51 for ; Mon, 29 Feb 2016 00:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 hyesl36rAkgm for ; Mon, 29 Feb 2016 00:54:56 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 679881B2E55 for ; Mon, 29 Feb 2016 00:54:56 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id k196so128243570vka.0 for ; Mon, 29 Feb 2016 00:54:56 -0800 (PST) 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=xA01z37cpuvh0D5Vym3SbOBojTqyk+xTOsxpj29nGbo=; b=UU2Ezn6v131kEs8GP0d+/tKIa9JQusgNiR21LeDwbxCsuNhQ5ar2X0HYGpmLpWHnJb bGOtmxEzG6s2aisPkunKIbnmf7pQX7XBwive+jcT1CHhVp2pWLug4GEUZ2BYzRHM8i1L jt7yH/6yIm7AAbk5uYrD6lknbrAJedGlAjCdFGccOQ8ThwuBGsQcS4LS1fa53G53+2aG x8b9L6RQRlQA3wVR0f+NhR42iE0BhsXwvXBBjel5nda+DiQPw8RpFUb8KT+0YC9bPldo 9aTb/qmtV7twugbe1YzdnCl2MPApzktJZGwYUP5OIr3vVk5BxBbCrFub6LRBuZNlshw4 UaaA== 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=xA01z37cpuvh0D5Vym3SbOBojTqyk+xTOsxpj29nGbo=; b=IJ1iCHrnYln63nEahb0LQSm0EbqE14YFzTAXb3qsCBnsC4ToRnArtfBkJA+sBETAnu QQXFpKbWsUrVAS/PMJU6zP7PamJ3FI9w8bu9vllUdAMfdm7q0xyB1Mv/6ENLsODt6Chp qanGor9gbQ132NGMvy2HgFI0DcRFZnACKMxXysc8c0BdvkN5mm000CLc//TklOp+8Bfd 1CAmVFotlbewE8zUC+GdssXIaR635m/HOAMxK9Mq6H7Vc2BdIOuQywRH0G+CUjx7+Jrn mn6xEOQadZ6w4Edcp/Qb1iy5HCMWzhqXrkrKBTl5A+3EjWrzuUiyFJgEQEOkAfW08ABq wP8w== X-Gm-Message-State: AD7BkJI62/xv4sDvwbHAMliECBvpn+ew794gVsjbaxj3tQBgbK/7zUaz3Dt3UDR8jzmavJ7/jLCeogs6GQodSQ== MIME-Version: 1.0 X-Received: by 10.31.135.79 with SMTP id j76mr9252037vkd.91.1456736095500; Mon, 29 Feb 2016 00:54:55 -0800 (PST) Received: by 10.176.1.162 with HTTP; Mon, 29 Feb 2016 00:54:55 -0800 (PST) In-Reply-To: References: Date: Mon, 29 Feb 2016 09:54:55 +0100 Message-ID: From: madshi To: Steve Lhomme , Discussion about the current and future development of Matroska Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Wed, 02 Mar 2016 09:01:27 -0800 Cc: cellar@ietf.org Subject: Re: [Cellar] [Matroska-devel] Fwd: Depth offsets for subtitles in case of 3D MVC tracks in MKV files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 08:54:58 -0000 > Ah, interresting. We could still use a z-order value, because > that's what 3D is about. The problem is that a 3D frame usually has different depths in different sections of the image. Each subtitle track has its own position where it's drawn, and its own x offset (-> depth) assigned to it, and depending on which section of the video frame the subtitles are drawn over, the depth could be widely different for different subtitle tracks (at least theoretically). Practically that means we don't really have one depth information per frame (or block), which works for all subtitles and OSD/GUI. Instead we have a different depth information for each separate subtitle track per video frame, and one (or multiple or none) more depth information for OSD/GUI depth per frame. > So I think we should go with the CodecState approach. Meaning > we need a specific codec ID for such Blu-Ray subtitles. We > should not write the CodecState if the values are the same as > the time it was previously written. CodecState is per Cluster, though, not per Track, so I'm not sure which exact information you'd want to store there? (Unless I'm misunderstanding the MKV cluster/track structure.) I think we need to store an array index per subtitle track in order to properly cover the depth information contained for subtitles in 3D Blu-Ray. I suppose if you wanted to make this totally codec independent, one other option would be to store the depth (or x offset) directly as a property of the subtitle track, but if we do that, then depth could only change once for each subtitle image, I think, which is too limited to properly capture what 3D Blu-Ray can do, because with 3D Blu-Ray, subtitles can have a different depth per subtitle track *and* per video frame. Best regards, madshi. From nobody Wed Mar 2 09:01:36 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416861B2E88 for ; Mon, 29 Feb 2016 01:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 KjHrwrc-bH8b for ; Mon, 29 Feb 2016 01:14:13 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D371B2E87 for ; Mon, 29 Feb 2016 01:14:13 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id c3so127645588vkb.3 for ; Mon, 29 Feb 2016 01:14:13 -0800 (PST) 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=QjkmlfaZxQOMa414i6ek5HyLboW9uuZnTKtfhaSlTaI=; b=HRuzIy6W6bXtFUeH2uOCC54b2ZszGzbCk8eRa0k6ER/++W7FZHtWRRJgxzufcfU0rt zKpX5DbBHqWfmE29r6gEZTxSJIx+u1g3IliuScnV2ns6r8SSibXrlkh8MSzhuETkYeuy kwj+Wo1xdH0+qT23P/ORriNnnPqhBhtW2rqQeq4cJJ86yN2UVGTTfCRN+hs0j1kRGvfl gKDVDC2khNai5yuBhYhNHDhDiD9xhCSACWTBr6iMcHosP4I9wVeLSYSSOelXDHO9TT8B lM2HRuDWgxXbMYfSGxclN/vcrsQ/iX6CUJ1YsYaNlDZfpT/AKa3MLGjsacH0/4zKX1Ga vIgw== 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=QjkmlfaZxQOMa414i6ek5HyLboW9uuZnTKtfhaSlTaI=; b=llL8XnVx7OFSS5xISusvmr4oMFhsbSsYl7oKkQdm5/5v9p0OE5oE1vQSuCERj9wiX9 oM1E91U97EnBgBxYjpECQyejiEBy+Un/GIQSLZ/RtM4kgGRF0IOyyo5rryRv5r4FIwsf SwIRlKtB1fUcWEmV5TPdCXgueUJgm64oozlPmY/K1WzTdUcldaI6NE24HCnyuHiVTUpQ lfkTSRRRiJ41Rom0ePIrFYze+3gMuN+mZ4Wusl7hvUk0GJYyZCLKu2J1W7cj0q4FfKFV ED69KB//b5C6YFQnpz0aXk6FdJjTN/R0igNa+veXLJe8+wLJGhqw7yvk9J6u5jMCsEKU Ha4w== X-Gm-Message-State: AD7BkJJhhrnmTIgycpLuWdgQ6jBDUH7EHs31f5PELiGidJpEmQVhnfgL6sQVyPW8iLnXz4BXOg66eMyoY+eULA== MIME-Version: 1.0 X-Received: by 10.31.162.82 with SMTP id l79mr10664451vke.76.1456737252922; Mon, 29 Feb 2016 01:14:12 -0800 (PST) Received: by 10.176.1.162 with HTTP; Mon, 29 Feb 2016 01:14:12 -0800 (PST) In-Reply-To: <20160229090425.GK4466@bunkus.org> References: <20160229090425.GK4466@bunkus.org> Date: Mon, 29 Feb 2016 10:14:12 +0100 Message-ID: From: madshi To: Moritz Bunkus , Discussion about the current and future development of Matroska Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Wed, 02 Mar 2016 09:01:27 -0800 Cc: CELLAR list Subject: Re: [Cellar] [Matroska-devel] Fwd: Depth offsets for subtitles in case of 3D MVC tracks in MKV files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 09:14:15 -0000 2016-02-29 10:04 GMT+01:00 Moritz Bunkus via Matroska-devel : >> CodecState is per Cluster, though, not per Track, > > This is wrong. CodecState is a child element of BlockGroup. It's effect > as it's been meant to be understood so far is to replace CodecPrivate > for that track from that BlockGroup onwards (until another BlockGroup > with CodecState comes along). So it _could_ be used for changing Z-depth > values for individual subtitle frames. However, as it's supposed to > replace CodecPrivate I don't think it would be a good fit for Z-depth > data as Z-depth data is additional data that changes on a frame-by-frame > basis; it doesn't invalidate the existing CodecPrivate data. > > CodecState was meant for situations in which e.g. a whole new set of > SEIs/PPSs come along. > > I'd prefer new elements, or maybe BlockAddition. Ok, thanks. I think the key thing that needs to be decided first is which of the two following approaches we want to use: 1) Do we want to store *ALL* 3D subtitle depth information we need into the MKV header structures? If we do that, we need to be able to store (up to) one depth information per subtitle track per video frame. 2) Do we want to make use of the SEI 3D depth information? In that case all we need to store in addition to that is one "int" per subtitle track, for the whole MKV file! Best regards, madshi. From nobody Wed Mar 2 09:01:38 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4001B2EB0 for ; Mon, 29 Feb 2016 01:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 e15whO-YqMAY for ; Mon, 29 Feb 2016 01:26:52 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32D91B2E86 for ; Mon, 29 Feb 2016 01:26:51 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id l68so49704012wml.1 for ; Mon, 29 Feb 2016 01:26:51 -0800 (PST) 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=tfAUe8bjbLxv0kWdGyHtRK+77zNBjaTM2I6VSoa3qVw=; b=t3BL5fFBF6BOMTs24cM160jwO53+FZgZUNAMfaI6B3hyuvZq5NuD07yOXxReIP+vDP 2eVWZbkUHgc2WMWMIGTDUFp8GXQl7Ngvjy/lUUMHyd0Ufe7mgiL4drvY1atQk62py/5t tgMKZYE7lz2QhaqNs0c2NSwCOCgwJLB2qu0WaHW4IabaV/lKB/yE/i6SRSyodO5gMz8v Jjyx+fg/j/NfFo44v/CviU9QV6ObT3hJPwA4VfS+dOnyCWIqdFgG6Xd4Nh/tKBrgADv/ N5R7KhZjtUw83KlVqdWgbxAUztQGC722YtCb34a+3192/s0sqW8d4cp+VRrmwemNvppF BJfQ== 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=tfAUe8bjbLxv0kWdGyHtRK+77zNBjaTM2I6VSoa3qVw=; b=axLOV/cEMhPgY90uljsiVmFyl3znyWJuWi8BYAK+RMJVAQ2PZpa7f1fjtGOC/nDLRf +/ev8V67o+nZbQZvC3tPwNM5j+NZnPRpSlbw26swRXyGLs4gfZxhRgBn0rRemzCRyuhH 3b1DNupQnbKm1D2W5GyDkkG2DAXhrETLWuP0bf4LAFdlm0huI3BnitP3l2QIPk4RYlqG GBM5kGUel9QSseJ9LZyji5ehsHbFyELWrVKGDdLuqu/3udcS/DMzUdsgsOPhhCOk/dn+ 14wQfyTfKuAth3GOMSP8jF8GRptZH5XYdpeVkiiMYLry44u7x3iDlqHdjI/AaCxzwKzU JN9g== X-Gm-Message-State: AD7BkJJQ0C1yjT1O4AdT4hbyvYrATIKUYAq8zOyfzMDUN6dZyXkpfu4FAsqC0zyBZRfdZLjBOdycANgNsv9xSg== MIME-Version: 1.0 X-Received: by 10.28.95.86 with SMTP id t83mr6262300wmb.86.1456738010332; Mon, 29 Feb 2016 01:26:50 -0800 (PST) Received: by 10.27.212.12 with HTTP; Mon, 29 Feb 2016 01:26:50 -0800 (PST) In-Reply-To: References: <20160229090425.GK4466@bunkus.org> Date: Mon, 29 Feb 2016 10:26:50 +0100 Message-ID: From: Hendrik Leppkes To: Discussion about the current and future development of Matroska Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Wed, 02 Mar 2016 09:01:27 -0800 Cc: CELLAR list Subject: Re: [Cellar] [Matroska-devel] Fwd: Depth offsets for subtitles in case of 3D MVC tracks in MKV files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 09:26:53 -0000 On Mon, Feb 29, 2016 at 10:14 AM, madshi via Matroska-devel wrote: > 2016-02-29 10:04 GMT+01:00 Moritz Bunkus via Matroska-devel > : >>> CodecState is per Cluster, though, not per Track, >> >> This is wrong. CodecState is a child element of BlockGroup. It's effect >> as it's been meant to be understood so far is to replace CodecPrivate >> for that track from that BlockGroup onwards (until another BlockGroup >> with CodecState comes along). So it _could_ be used for changing Z-depth >> values for individual subtitle frames. However, as it's supposed to >> replace CodecPrivate I don't think it would be a good fit for Z-depth >> data as Z-depth data is additional data that changes on a frame-by-frame >> basis; it doesn't invalidate the existing CodecPrivate data. >> >> CodecState was meant for situations in which e.g. a whole new set of >> SEIs/PPSs come along. >> >> I'd prefer new elements, or maybe BlockAddition. > > Ok, thanks. > > I think the key thing that needs to be decided first is which of the two > following approaches we want to use: > > 1) Do we want to store *ALL* 3D subtitle depth information we need > into the MKV header structures? If we do that, we need to be able > to store (up to) one depth information per subtitle track per video frame. This is the problem that occured to me just now as well - there is typically more depth information than subtitle frames. BDs store the depth information based on video frames, not subtitle frames, so any subtitle frame can change its depth for each video frame to react to changes in the video. Which means that storing such information inside the subtitle track is probably going to be rather problematic. > > 2) Do we want to make use of the SEI 3D depth information? In that > case all we need to store in addition to that is one "int" per subtitle > track, for the whole MKV file! > This would certainly be the easier option, but it is highly specific to H264 MVC SEI's, so I can see how they might be reluctant to do that. - Hendrik From nobody Fri Mar 4 11:15:21 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C90C1A8829 for ; Fri, 4 Mar 2016 11:15:20 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 nMnPmG-pJ4PG for ; Fri, 4 Mar 2016 11:15:18 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87F41A882A for ; Fri, 4 Mar 2016 11:15:16 -0800 (PST) Received: from [192.168.2.129] ([188.100.165.102]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6874-1ZeqAC2bcY-00yAGv for ; Fri, 04 Mar 2016 20:15:14 +0100 To: cellar@ietf.org References: <56C0D0D6.8000005@mediaarea.net> From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <56D9DEBF.5060705@gmx.de> Date: Fri, 4 Mar 2016 20:15:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:49BRlCcpA283YopJCykQUHUWCvFxqRt6cieAG5Se7aTrqsWiZeU vLpxxx6D9MxiHSkUwb+HXOwzGi/o1K7d4lZEQXPJ6LR+qBcT5m9CbxAXPHa7AHRMV0sSuLX jlNiQqGCbuNm6t/0t62YeKc0hmE1c0Q9D9VfFjgo1Vc4BagDB437TOFojyZCdI9RTXf+KCw CJREm5KSRQrEsZjHw0pMQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:TCw6WW+p0Sg=:GYswkHPZr8177xznygSdil roYM6AtW39n9FLHPigNxKN8y+ivOdk+nzD6kw0dvSEiUvyImMlKP6x5W8h0ZCaVYefYIIhrGX sxG4WA6mZVIQLpTB9ulY3XAsNOhDN0+ctzGwGHHhEx+MeIK8EIxM8s/CXEiiER7CHe+d4uSCE iaK5uzDV5hwZEdylRguEEj48zsSX/v+C6hHsI5auDqZylJTip60gEmt/dtTe371rHkdWXBJVh QPf2zRH+iwZJvHOaTbRzAIDebpIojAYMSBjL2G4RH9g4EgP6/hYYSOpTcDcjAirdRxeQn61zo hFPkPVQTBOJ/Wv1E8/VPmpEBYO36XyHbh9kOUBFfLl9QHPgwp+sC8Uq9QUoGAdcDRQhk+oyKx UrOqKKM2YRj/hfy4i+zu4Dv3lHlH83+JXGp6qVx/arGNmBt+UorwU4CO8sO0CUIDqufi20cPL chDJ1XZjS76OU/GSmjlX9Hz1iLKrDeMXPtnT11K8qVkRAYrzcf5ZCFHUroerw0GXhaJpheHhW +6uTQhCZi+HuFyTRSoguBxZyMky/xuCBY2p+lZbhmtn2xq8jQt8g3QaNrJZgautfpxeLIyiBf uV/9hQEnCjlYRMcyDbSvKOGCU/WJdSTsrv6X87/mDa1fFOpSsIqrgQDOYH5eS1RI0rUJ0UDOA E4WufnsTHwm6u4r1Lz3knllkolmsykw6iDBj4eykKg1L9yNS6OFRNDIvvJSk+Zeihx4xmm0FC mNdiRq89pNqAq7WGKMa6aXtgf4Nu5Piw1KRNUytqx4w9wk2xDBeDty61YJT5Afhk1hdBejZnD xFXLHrp Archived-At: Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 04 Mar 2016 19:15:20 -0000 28.02.2016, 15:22 Steve Lhomme: > 2016-02-14 20:09 GMT+01:00 Jerome Martinez : >> On 14/02/2016 19:08, Steve Lhomme wrote: >>> >>> 2016-02-14 18:33 GMT+01:00 Dave Rice : >>> [...] >>> >>>> Within the EBML Schema section I suggest adding: >>>> >>>> "An EBML Schema MUST declare exactly one Element at Level 0 (referred to >>>> as the Root Element) that MUST occur exactly once within an EBML Document. >>>> The Root Element MUST be mandatory and MUST be defined to occur exactly >>>> once. Note that the EBML and Void Elements may also occur at Level 0 but are >>>> not considered to be Root Elements." >>>> >>>> With this, I also suggest changing both EBML (Header) and Segment in the >>>> Matroska spec to non-multiple. >>>> >>>> This would mean: >>>> >>>> invalid (multiple Root Elements) >>>> >>>> >>>> >>>> >>>> >>>> invalid (only header and no Root Element) >>>> >>>> >>>> >>>> valid (the usual MKV file) >>>> >>>> >>>> >>>> >>>> valid (two concatenated EBML Documents) >>>> >>>> >>>> >>>> >>>> >>> >>> If that's valid, then it's fine with me. Although it should be noted >>> that in that case the second EBML header is not taken in consideration >>> and only the first one is used. That's to ensure the whole block of >>> concatenanted data can be handled just by knowing the first header. >> >> >> but if the second EBML header is different, analysis is wrong. >> So if we say that only the first one EBML header should be read: >> - we must state that we can concatenate files only if they have the same >> EBML header (so same Matroska version? I don't the reason we should mandate >> that Matroska versions are same) >> - we must state that EBML header must be identical. >> >> From my point of view that does not make sense (why do we need to duplicate >> the EBML header in that case). >> >> I am ok for having EBML header before each segment, but in that case the >> EBML header just before the segment should be considered as having the right >> info (e.g. Matroska version). >> >> I am afraid about such file: >> EBML header with Matroska v4 (from file 1) >> Segment conforming to Matroska v4 (from file 1) >> EBML header with Matroska v5 (from file 2) >> Segment conforming to Matroska v5 (from file 2) > > I think we need more precision on the way compatible Doctypes can be > handled. It may be per format and not a rule set for all EBML > documents. For example mixing Matroska v1, v2 and v3 is fine as long > as you know beforehand you need v3 compatibility (so maybe it's ok > only if it appears first). You could also mix WebM and Matroska > Doctypes in the real world and still be okay. It appears that you don't have reached a consensus on the question whenever such structures should be valid. EBML should remain open to that. Then something building upon it can use it, forbid its use or restrict it. Matroska could make use of it, but IMO it should be optional for a player to support such a file. The thing with having it in EBML in general is that you couldn't mix (with) Doctypes that forbid it. To me it seems like it would create some overhead in the code. Just guessing. You could mix WebM and Matroska Doctypes, but Firefox will not play a Matroska file. How would a player or an editor have to handle files where it would support Matroska v4, but not v5? Skip the v5 segment? Refuse to handle the file altogether? WebM and Matroska is the same problem, someone choose to implement only WebM (maybe because of the restriction in codecs) and has to decide what to do. What if some segment is invalid? Does it make the whole file invalid? > IMO at the EBML level (not knowing semantics) there's no reason to > restrict mismatching Doctypes. The thing we should restrict is whether > there's always an EBML header before an EBML content. IMO that should > be mandatory. > >> In the case we have first EBML header as the reference header, we parse >> second segment as Matroska v4 but it is actually v5. >> >> >>> Also that you don't mix different DocType in the same file (or do we >>> want to allow that ?). Meaning could also >>> be valid. >> >> >> Is there any reason we don't want different DocType? (and >> DocTypeReadVersion?) >> >> Jérôme >> >> Regards, Sebastian From nobody Sun Mar 6 05:48:27 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1831B3915 for ; Sun, 6 Mar 2016 05:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] autolearn=ham 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 s3A8TuVV3scL for ; Sun, 6 Mar 2016 05:48:24 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353511B3086 for ; Sun, 6 Mar 2016 05:48:24 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id e6so94197022vkh.2 for ; Sun, 06 Mar 2016 05:48:24 -0800 (PST) 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=epB4ielSek/zzQR5EsxnjW+ov7Q+dW68FzXMs1Te30Q=; b=O0nnh+XHHTjff4z22szx7EYEu+f65myWYvoYLjiKDpipKQLOFp6UKIMRhzS8yQvnUa ZeaPHGCAxvL8I+B42MQiVk5gMSPIBpDpJlOMJ4n8XE3c3tXLy+BV2B7IygJ7XbE98c++ d9/H8NSFdwQ2duybEjHm4UgWlmn/34kzJUnUeF4I2X+DNnigfz8eA3qAN1gub7ZHItvM R9dzX+AUypDQ6t+8hyJTClcnuHEluoSJVIJ/AycFnEw/MKa/csfgDJMw7Rxq3I87julv 5cEnwdaZIl1AAgn947IF4lFJuk9kOK98+bTjHZKDs79owMdJBA+EGCYkq1AYXTq1yzgU gHpg== 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=epB4ielSek/zzQR5EsxnjW+ov7Q+dW68FzXMs1Te30Q=; b=fEknkzeFz2LDG8Hm7juDiDAZ+kyRDsTfd5kKt6iuCCMgfmFVPQqiCIakxSIAYKC3p1 ybBzIc/4n94E/EwsB4yOvS3jSOesUB963NL79sMMYVitiAJNrpFEfASg2TpIZug/f3hs MSs0QTN73mIBPqG9mytU+2YBiqkmJJSdOu192Q256nuFq41i6L9r5uDeRcko+sKtvrLR JbmSiczHQ2E335IOUsBubprZjcX2RUhjL/BVa/8FyHVzRmLNn8bAnG+NEzQXHEoTu0pN SnXfZfcvlS4p1G/Vgp1Zs5DaqPDQrz+iDk+CwkPqWjnLLibxs6EL6HKNuDiN/yuwDgO4 9SLA== X-Gm-Message-State: AD7BkJLuyLK196xXtYj0XJxx87spcx8F2qM7pmCf92kDDH6ZqOvChFs9XGgmmmpslX9JyBOP2KO3PY275Y55kQ== MIME-Version: 1.0 X-Received: by 10.31.133.7 with SMTP id h7mr15593221vkd.32.1457272103303; Sun, 06 Mar 2016 05:48:23 -0800 (PST) Received: by 10.176.66.134 with HTTP; Sun, 6 Mar 2016 05:48:23 -0800 (PST) In-Reply-To: <56D4554F.9040308@noa-archive.com> References: <56D036BA.9000603@noa-archive.com> <20160228111117.GD25696@bunkus.org> <56D4554F.9040308@noa-archive.com> Date: Sun, 6 Mar 2016 14:48:23 +0100 Message-ID: From: Steve Lhomme To: Tobias Rapp Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Display area clarification question X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2016 13:48:26 -0000 2016-02-29 15:27 GMT+01:00 Tobias Rapp : > On 28.02.2016 15:31, Steve Lhomme wrote: >> >> 2016-02-28 12:11 GMT+01:00 Moritz Bunkus : >>> >>> Hey, >>> >>> it's true that we've never clarified this. I'm not even sure whether or >>> not we've had a consensus on how to interpret the values. >> >> >> Correct, but trust me, it was in my head the whole time ;) Although >> the name PixelCrop* imply that it happens on Pixel*, unlike Display* >> values. > > > One could (in theory) invent similar DisplayCrop* elements that apply on top > of DisplayWidth/Height values which could be used to describe > letterboxed/pillarboxed material. This would be somehow similar to the AFD > flag [1] in MPEG but globally on the stream/track. > >>> For me PixelCrop* applies directly to the PixelWidth/Height values. And >>> Display* determines the intended size for displaying the video after the >>> cropping parameters have been applied. So yes, your interpretation is >>> the one I'm favoring as well. >> >> >> Yes, the cropping happens on the pixels, the display size are just how >> to display those remaining pixels. > > > OK, have tried to make a patch, see attached file. > > Note that I have changed the default value of DisplayWidth/Height to take > the cropping into regard. Not sure how critical this is regarding backwards > compatibility. It affects files which have at least one PixelCrop* element > value > 0 and no DisplayWidth/Height element. Thanks. I applied the change but not in the specs yet. The default values were not used in code (AFAIK). > Best regards, > Tobias > > > Links: > [1] https://en.wikipedia.org/wiki/Active_Format_Description > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Sun Mar 6 13:39:31 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE941B3A57 for ; Sun, 6 Mar 2016 13:39:29 -0800 (PST) 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 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 BfIgdXE4EQS6 for ; Sun, 6 Mar 2016 13:39:27 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985AA1B3A40 for ; Sun, 6 Mar 2016 13:39:27 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id m184so113053409iof.1 for ; Sun, 06 Mar 2016 13:39:27 -0800 (PST) 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=9hCaprmUpwMVYEB3Om1qr72I+//QHrQuoJj1YKgX8Bg=; b=rKYuGDft3CzmCQvQ/M/F73xPEPZ5u+8TEu3xqzmix0wLFB4vrCXGYjDVmb2kak0KC6 HSE98I4xjEwgMOdMBLQytv/Z0hhl6ZIZ6bkX9VFqpY2lEOtMdpkNbsSDzu+0zyslLokB LvqdqynG2rnHjP6pTsmrT3DPga/0viFtRIM9zsO+091Jrz+o0h0Y9srRUANlaNF6E+pn SR4NGANuHAx5Zuy8iXreH/AJOFrwVBnTbd2IdIqQDgM1YbSDaTKiUxTq7CtbErE11nfa XsHuM1+X4KDVpvh4RSGnOUcaL9Bu78srlv7n5gsGwlcr3KP3haRvjEZTwhQJt9CeVm3l DH9w== 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=9hCaprmUpwMVYEB3Om1qr72I+//QHrQuoJj1YKgX8Bg=; b=No9Q43KAY1EF8kQaKO6IPtWSdiBOvprXL5XSmxwgf/SCKARLgtyW1tYkjtTzyKMADb UC5DmZ2Zlt+xFkjV63ZwRLl+rRlO7vFUDYhOrJO8denqW0x8QRrA5nn4ovXgdrbTfWC5 oQN+Py7pekQke/b3wIuWXhlM578h06mA2H5S81aJr0xVOzP2+FWmKvt8C4eYUpLOcju5 Sr9UKqo0VNF4dFM0iJJLwAlxVDX+9yt3MM6yyUKG/x3WiS8AIZUbLePuwQ2BkMxq+hkN 9LA+7zJ5bWwRzQ5AfHKuba6oZQIeamrNCVu+220beZvyyS06mVSWNu+DWo6E40+IaYPA 1hQQ== X-Gm-Message-State: AD7BkJKpOIYA7hqTHo8mCc/geseZAPL+CQzzDrveeQ1Jau+EIGsNSdhhyUSrMeiVBFSCqb7VKrD2IOKHw/yCVA== MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr16382972ioe.38.1457300366916; Sun, 06 Mar 2016 13:39:26 -0800 (PST) Received: by 10.79.9.196 with HTTP; Sun, 6 Mar 2016 13:39:26 -0800 (PST) Date: Sun, 6 Mar 2016 16:39:26 -0500 Message-ID: From: Ashley Blewer To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a1140b472b3870c052d682ef7 Archived-At: Subject: [Cellar] Proposal to work on Github Pages site X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2016 21:39:29 -0000 --001a1140b472b3870c052d682ef7 Content-Type: text/plain; charset=UTF-8 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 completion 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 can 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 XML 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 local 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 after decisions are made here on CELLAR. My best, Ashley Blewer --001a1140b472b3870c052d682ef7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey all!=

There's been some discussion ab= out a collaborative framework with which to continue work on the Matroska s= pecification in a code-development context after we've had conversation= s on this list.

<= /div>
I'd like to propo= se we migrate the Matroska specification to Github. As I mentioned before, = I'm happy to carry this transition to completion on a MatroskaOrg-hoste= d or CELLAR-hosted Github organizational account, but would like to hear fr= om everyone on which site is the best for a collaborative environment.

Option 1: Jekyll-based website that automat= ically translates Markdown to HTML.
Please note thi= s currently follows a Jekyll theme standard but can be made to look like th= e Matroska site.

The pros and= cons are both in terms of ease of use. The benefits are working in the mor= e human-readable Markdown instead of HTML. The negative is that running a l= ocal Jekyll server to preview work before submitting a request is harder th= an opening up a static site.

Also, ta= bles can be difficult to read and create in Markdown. However, the primary = table located on the=C2=A0specification page=C2=A0is rendered via XM= L and would not have to be rewritten in Markdown (although this example doe= s have it written in Markdown).

Option 2= : Standard HTML website.
This has been translated to repl= icate the Matroska site.

Like= I said above, previewing work doesn't require running a local server. = But work is harder to read because it's in HTML and most changes will b= e very text-based anyway.

After we co= me to a decision, I can move relevant specification details to this site an= d it can be used to make changes to the standard after decisions are made h= ere on CELLAR.

My best,

Ashley Blewer
--001a1140b472b3870c052d682ef7-- From nobody Sun Mar 6 21:04:06 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3031A8AAA for ; Sun, 6 Mar 2016 21:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no 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 gRqq7XtewawJ for ; Sun, 6 Mar 2016 21:04:03 -0800 (PST) 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 55F901A8AA9 for ; Sun, 6 Mar 2016 21:04:03 -0800 (PST) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:37267 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1acnKs-002QJU-FJ for cellar@ietf.org; Mon, 07 Mar 2016 00:04:03 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <56D036BA.9000603@noa-archive.com> Date: Mon, 7 Mar 2016 00:03:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <28AA7D94-34DC-4C31-9847-6912C70250DF@dericed.com> References: <56D036BA.9000603@noa-archive.com> To: cellar@ietf.org X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Display area clarification question X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2016 05:04:05 -0000 > On Feb 26, 2016, at 6:27 AM, Tobias Rapp = wrote: >=20 > Hello, >=20 > when archiving SD material lines of the vertical blanking interval = (VBI) are sometimes stored at the top of the frame. For PAL the typical = stored size is 608x720 pixels with the bottom 576x720 area containing = the actual image content. >=20 > =46rom looking at the Matroska specs this can be mapped into: >=20 > PixelWidth =3D 720 > PixelHeight =3D 608 > PixelCropBottom =3D 0 > PixelCropTop =3D 32 > PixelCropLeft =3D 0 > PixelCropRight =3D 0 >=20 > I guess that the definition of the display area (DisplayWidth, = DisplayHeight) applies to the pixel frame size *after* cropping? >=20 > In that case it would be great if this would be made more explicit in = the documentation of DisplayWidth and DisplayHeight. Also the defaults = should reflect that (i.e. default DisplayWidth =3D PixelWidth - = PixelCropLeft - PixelCropRight). I tried to find some sample files that use PixelCrop* to see what the = implementation was like, but unfortunately this feature appears to be = rarely used. I found some samples all written by "libDivXMediaFormat 3.0.0.0386=E2=80=9D= where all the PixelCrop* values are set to zero. This sample appears to use PixelCrop* for non-defaults: = http://archive.org/download/dl.icemusic.com/ArashFt.Aysel-AlwaysliveEurovi= sionSemiFinal2009.-WwW.Myicemusic-IR.mkv PixelWidth: 720 PixelHeight: 576 PixelCropBottom: 4 PixelCropTop =3D 0 PixelCropLeft =3D 2 PixelCropRight =3D 4 DisplayWidth =3D 1024 DisplayHeight =3D 576 The sample does have blank rows and columns on the left, right, and = bottom edges so the cropping makes sense. Are there any display tools = that use this feature? When I play this sample in VLC, I see Display resolution set to 714x572, = which is DisplayWidth - (PixelCropLeft + PixelCropRight) x DisplayHeight = - (PixelCropBottom + PixelCropTop), but as far as I can tell the pxiels = are still displayed rather than cropped. ffplay from git-master plays the video at 720x576 (apparently not using = PixelCrop* in any way). Neither VLC or ffplay appear to actually crop the presentation, though = with VLC it has an impact on the display size. While studying sample files I found a few other issues with Display = area. I found 27 files, all from "WonderShare Matroska Muxer=E2=80=9D that set = DisplayWidth and DisplayHeight to 0 even though this is clearly invalid. = Example: = http://archive.org/download/gov.house.ogr.mark.20090310/gov.house.ogr.mark= .20090310.mkv I also see many files where DisplayWidth and DisplayHeight are set to = very small values as if aspect ratios but with DisplayUnit unset (thus = DisplayUnit defaults to Pixels). For instance = http://archive.org/download/1937-Die-Schlacht-um-Miggershausen/1937-DieSch= lachtUmMiggershausen12m28s.mkv by "libebml v0.7.7 + libmatroska = v0.8.0=E2=80=9D "mkvmerge v1.7.0 ('What Do You Take Me For') built on = Apr 28 2006 17:20:19=E2=80=9D uses a DisplayWidth of 4, DisplayHeight of = 3, and unset DisplayUnit. If I understand the spec correctly, during = playback the video should occupy four pixels by three pixels of the = screen. Here=E2=80=99s another 4/3 example but with DisplayUnit = specifically set to 0 (i.e. pixels): = http://archive.org/download/3n-2zwd-1/az1.mkv (muxed by = libDivXMediaFormat 3.4.1.0004). In cases where I=E2=80=99ve seen DisplayUnit set to 3 (i.e. Display = Aspect Ratio), the DisplayHeight and DisplayWidth are set to high = numbers such as 1920x1080 or 1280x720 rather than 16x9. I may try to rewrite some of the Display definitions to add clarity, = please if you have any comments on these notes please let me know. Best Regards, Dave Rice= From nobody Sun Mar 6 21:15:39 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4761A8BB6 for ; Sun, 6 Mar 2016 21:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no 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 uQEYdFQO-CHI for ; Sun, 6 Mar 2016 21:15:36 -0800 (PST) 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 213961A8AF1 for ; Sun, 6 Mar 2016 21:15:36 -0800 (PST) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:46657 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1acnW2-002mKu-Ss for cellar@ietf.org; Mon, 07 Mar 2016 00:15:36 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <56D9DEBF.5060705@gmx.de> Date: Mon, 7 Mar 2016 00:15:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56C0D0D6.8000005@mediaarea.net> <56D9DEBF.5060705@gmx.de> To: cellar@ietf.org X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 07 Mar 2016 05:15:38 -0000 > On Mar 4, 2016, at 2:15 PM, Sebastian G. wrote: >=20 > 28.02.2016, 15:22 Steve Lhomme: >> 2016-02-14 20:09 GMT+01:00 Jerome Martinez : >>> On 14/02/2016 19:08, Steve Lhomme wrote: >>>>=20 >>>> 2016-02-14 18:33 GMT+01:00 Dave Rice : >>>> [...] >>>>=20 >>>>> Within the EBML Schema section I suggest adding: >>>>>=20 >>>>> "An EBML Schema MUST declare exactly one Element at Level 0 = (referred to >>>>> as the Root Element) that MUST occur exactly once within an EBML = Document. >>>>> The Root Element MUST be mandatory and MUST be defined to occur = exactly >>>>> once. Note that the EBML and Void Elements may also occur at Level = 0 but are >>>>> not considered to be Root Elements." >>>>>=20 >>>>> With this, I also suggest changing both EBML (Header) and Segment = in the >>>>> Matroska spec to non-multiple. >>>>>=20 >>>>> This would mean: >>>>>=20 >>>>> invalid (multiple Root Elements) >>>>>=20 >>>>> >>>>> >>>>> >>>>>=20 >>>>> invalid (only header and no Root Element) >>>>>=20 >>>>> >>>>>=20 >>>>> valid (the usual MKV file) >>>>>=20 >>>>> >>>>> >>>>>=20 >>>>> valid (two concatenated EBML Documents) >>>>>=20 >>>>> >>>>> >>>>> >>>>> >>>>=20 >>>> If that's valid, then it's fine with me. Although it should be = noted >>>> that in that case the second EBML header is not taken in = consideration >>>> and only the first one is used. That's to ensure the whole block of >>>> concatenanted data can be handled just by knowing the first header. >>>=20 >>>=20 >>> but if the second EBML header is different, analysis is wrong. >>> So if we say that only the first one EBML header should be read: >>> - we must state that we can concatenate files only if they have the = same >>> EBML header (so same Matroska version? I don't the reason we should = mandate >>> that Matroska versions are same) >>> - we must state that EBML header must be identical. >>>=20 >>> =46rom my point of view that does not make sense (why do we need to = duplicate >>> the EBML header in that case). >>>=20 >>> I am ok for having EBML header before each segment, but in that case = the >>> EBML header just before the segment should be considered as having = the right >>> info (e.g. Matroska version). >>>=20 >>> I am afraid about such file: >>> EBML header with Matroska v4 (from file 1) >>> Segment conforming to Matroska v4 (from file 1) >>> EBML header with Matroska v5 (from file 2) >>> Segment conforming to Matroska v5 (from file 2) >>=20 >> I think we need more precision on the way compatible Doctypes can be >> handled. It may be per format and not a rule set for all EBML >> documents. For example mixing Matroska v1, v2 and v3 is fine as long >> as you know beforehand you need v3 compatibility (so maybe it's ok >> only if it appears first). You could also mix WebM and Matroska >> Doctypes in the real world and still be okay. >=20 > It appears that you don't have reached a consensus on the question > whenever such structures should be valid. >=20 > EBML should remain open to that. Then something building upon it can = use > it, forbid its use or restrict it. Matroska could make use of it, but > IMO it should be optional for a player to support such a file. I agree. I think it appears that there=E2=80=99s consensus for (please = correct me if I=E2=80=99m wrong): - EBML should allow EBML Documents to be concatenated as an EBML Stream - each EBML Document must contain an EBML Header and one Root Element = (Segment for matroska/webm) I think we also don=E2=80=99t yet have consensus on: - What extra requirements should Matroska place on EBML Streams of = Matroska/webm files (should docTypes and versions be known before the = whole stream is read) - Should players in any cases be expected to support EBML Streams = (either of consistent type/versions or not)? I propose to change Segment to mandatory and non-repeating within an = EBML Document. Back to the original question of this thread. Any objections with a = proposal like this statement for the EBML specification: "An EBML Schema MUST declare exactly one Element at Level 0 (referred to = as the Root Element) that MUST occur exactly once within an EBML = Document. The Root Element MUST be mandatory and MUST be defined to = occur exactly once. Note that the EBML and Void Elements may also occur = at Level 0 but are not considered to be Root Elements." > The thing with having it in EBML in general is that you couldn't mix > (with) Doctypes that forbid it. >=20 > To me it seems like it would create some overhead in the code. Just > guessing. >=20 > You could mix WebM and Matroska Doctypes, but Firefox will not play a > Matroska file. That makes sense. A matroska player is more complex than a webm player. = Still I would love to see Firefox as a comprehensive Matroska player. Dave > How would a player or an editor have to handle files where it would > support Matroska v4, but not v5? Skip the v5 segment? Refuse to handle > the file altogether? >=20 > WebM and Matroska is the same problem, someone choose to implement = only > WebM (maybe because of the restriction in codecs) and has to decide = what > to do. >=20 > What if some segment is invalid? Does it make the whole file invalid? >=20 >> IMO at the EBML level (not knowing semantics) there's no reason to >> restrict mismatching Doctypes. The thing we should restrict is = whether >> there's always an EBML header before an EBML content. IMO that should >> be mandatory. >>=20 >>> In the case we have first EBML header as the reference header, we = parse >>> second segment as Matroska v4 but it is actually v5. >>>=20 >>>=20 >>>> Also that you don't mix different DocType in the same file (or do = we >>>> want to allow that ?). Meaning could = also >>>> be valid. >>>=20 >>>=20 >>> Is there any reason we don't want different DocType? (and >>> DocTypeReadVersion?) >>>=20 >>> J=C3=A9r=C3=B4me >>>=20 >>>=20 >=20 > Regards, > Sebastian >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Wed Mar 9 11:31:43 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 D2E7C12D960 for ; Wed, 9 Mar 2016 11:31:41 -0800 (PST) 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYIKgPxFxhAD for ; Wed, 9 Mar 2016 11:31:40 -0800 (PST) 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 EE03812D8F0 for ; Wed, 9 Mar 2016 11:31:30 -0800 (PST) Received: from [38.123.136.241] (port=61001 helo=[192.168.17.184]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1adjpS-0011OX-NU for cellar@ietf.org; Wed, 09 Mar 2016 14:31:31 -0500 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <024A3647-85BD-42F5-AEAA-AF549C3F5CAF@dericed.com> Date: Wed, 9 Mar 2016 14:31:28 -0500 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=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] Matroska Tags 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, 09 Mar 2016 19:31:42 -0000 Hi all, I'm working on updating the documentation in the Matroska Tags section, = but have some questions and comments. The definitions for Tags and Tag imply that the Tag structure only = contains metadata that relates to Tracks and Chapters, but elsewhere = documentation refers to Tags in use to describe Attachments. I propose = to adding Attachments to the Tag and Tags definitions. Is there anything = else that Tags can describe besides Segment, Chapters, Tracks, and = Attachments. If the Matorska Segment is a part of a linked series of Segments (using = PrevUID and/or NextUID), is it possible to use Tags to refer to the = linked series of Segments? I'm presuming that the Tags element may only describe data within the = same containing Segment, is that right? The Targets element is mandatory and the description says "It is empty = to describe everything in the segment." Does "is Empty" mean that the = Targets Master-element is literally empty with a zero value in the = Element Data Size. I find it a little unintuitive that the TagAttachmentUID element relates = to another called FileUID. I realize that it's challenging to change the = name of an element at this phase, but :( For the linking UID Elements in this section I propose adding the = Element that the element links to by name. I'm confused as to why there are both TargetTypeValue and TargetType. = The TargetTypeValue just seems like the human-readable version of = TargetType, but what if they conflict? Are there scenarios where = TargetType should be used but not TargetTypeValue? If Tag contains TagTrackUID=3D0 and TagTrackUID=3D{SPECIFIC_TRACKID}, = does this mean the Tag element refers to all tracks? There is TagEditionUID but EditionUID is not mandatory, so it seems as = if the ability to describe a Chapter Edition depends on if an UID = happens to be there. The other UID Elements that Tags relate to are all = mandatory. Any reason that EditionUID is optional? SimpleTag is one of the rare Elements that can appear at multiple = levels. Is it true that the only valid parent elements of SimpleTag are = Tag and SimpleTag? Best Regards, Dave Rice= From nobody Sun Mar 13 01:26:34 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A5812D54C for ; Sun, 13 Mar 2016 01:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDBYpQ5PTE8A for ; Sun, 13 Mar 2016 01:26:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7FD12D535 for ; Sun, 13 Mar 2016 01:26:29 -0800 (PST) Received: from [192.168.2.129] ([188.100.165.102]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M8axL-1Zt6PI17ul-00wESc for ; Sun, 13 Mar 2016 10:26:27 +0100 References: From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE To: cellar@ietf.org Message-ID: <56E5323C.6030504@gmx.de> Date: Sun, 13 Mar 2016 10:26:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:5eklzCgTVkSpqT8b+UmMY6GIOoh16wGeBZM/9qm1WcFjZ5/i82n SldfyWEpzxlrgKO6bdXZbMXsd+LrTu+ulTORK0ata9kNEhuTXTAMVCFEnT8wmXAMDdAwUpK 6uJPIApHVIA/1o3+8fAbzkeZXFRIwmQF2grtw1P5O+3Uf+t3aJGreojDTFg5XRQBQJhnGYk ED2npkGvh+6urQyNfQWsw== X-UI-Out-Filterresults: notjunk:1;V01:K0:7VybLhlAU4Q=:ZPkfqGvQD8bte5j3vqpbkA rXkNNmTeoLJbqsrbn8o27S4xX+/qslWsAYJIi5JN6P8XnJSjenIjaBRhHSaFxLwlG2ZuvqSEp hD7QHRnqOXsOlaBhKbvO+ul0QDavWpF9qp1s1QLW1lqsxlXuZa8k3ikb7s/7H3cKBAi11VK+V PBDBy0P7yALDctEX1mq+p7JNzYE/dK0epjBaKH4vgxlGk0E0S5/bsVFHNDQFnH3wAtS33YCUA u6ptvX3m4Da5gbKoy5lH7AEohkUTFTiJw9hwxFahil2yQIunYcZTfVnGEGa9+41arUvUBMqsf tiLGTfKxCNlp5SQQ+s7InMKw+KotKxhkdj5ZHD0Sj4HuojRnMMNLG1zSVb/bpwWKgUHzpRv3y fcJk3x1EjozfDplGV5tNchi2S4eA8NF3efmW77FFEaKeiVTN3d2imUtfGL4lmGphIoUC+PZm2 0vZG8t92zStZLJQFwDe9CeLbt4fTO43sCt7hrdrZYFk5b6pzcjtBIcP/ENYmZrlvGVQs5GQjN AYyHfUW4CVKoHsk/lGh144yw8TFZKyHTzLmAA+y0ymZDqs14YZA52Nm3zvjpF0tdBAlmdCoLs qeYukvByhGJ77gD2pYzWuStFY3cv9by6V3SvrqPLykvPp9Ifa+ZdEiKWQ7lcYENQNenm+tozq H1G9zvzFicaDUXIcbKLpSl6fvKtbdTEfLaJvDBu72XsYMe59ge9XzyHNLWBzPNDE0C1KJZ00p 7BWLWCvsbmZFkvb9PTOzz+1oZIWAPwkJ8N7x7322cAgcF5i4eupJgJPkhyeT2PIdWSulZrEnW DxP/9m5 Archived-At: Subject: Re: [Cellar] [Matroska-devel] Depth offsets for subtitles in case of 3D MVC tracks in MKV files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 09:26:32 -0000 29.02.2016, 08:51 Steve Lhomme: > 2016-02-28 23:12 GMT+01:00 madshi : >> 2016-02-14 15:50 GMT+01:00 Steve Lhomme : >>> 2016-01-26 14:39 GMT+01:00 Nithin Mathew Kurien : >>>> Hi, >>>> >>>> It's like this. Suppose the MVC video track has 8 frames. Also suppose it >>>> has 5 Offset Metadata Sequences embedded in it at the time of encoding. >>>> (Sequence entries are in pixels, positive if in front of the screen, and >>>> negative if behind.) >>>> >>>> Frame 1 2 3 4 5 6 7 8 >>>> Seq1 5 1 -8 -2 -9 1 -3 -1 >>>> Seq2 8 1 0 8 -4 -5 4 -1 >>>> Seq3 -2 8 -3 -5 7 5 -5 -4 >>>> Seq4 9 0 0 -5 -2 1 -4 -1 >>>> Seq5 -9 3 -2 -4 -6 0 -3 6 >>>> >>>> If the M2TS container has 2 subtitle tracks P1, P2 and 1 menu track I1, then >>>> a mapping can be defined in the M2TS container like this: >>>> P1 : Seq1 >>>> P2 : Seq3 >>>> I1 : Seq4 >>> >>> OK, so it seems it's both in the header and in the track (the GOP is >>> part of the stream, I think). >> >> Yes. As Nithin Mathew explained (thanks!), there are SEI 3D depth info >> blocks inside of the video stream. We don't need to do anything about them. >> But there's additional data in the Blu-Ray playlist file(s) which >> assigns specific >> subtitle tracks to an "array index" in the SEI 3D depth info block. >> >> In the meanwhile nevcairiel and I have already added full support for all >> this 3D depth offset stuff to LAV Splitter/Video decoder and madVR, when >> playing back original Blu-Rays. But for Matroska there's no full solution >> possible yet, because the information in the playlist cannot be properly >> stored yet. >> >> It would be great if we could get an official solution for this soon, because >> we'd like to implement it "now", and we have the MakeMKV devs on board >> for this now, too. >> >> Basically I think what we need is one additional item for each subtitle >> track which simply assigns one SEI 3D depth array index to the subtitle >> track. E.g. something like "stereo_subtitle_offset_id", or whatever. The >> name is not important to me. Possible values I think are between 0..31 >> for 3D Blu-Rays. > > That seems to be heavily relying on the Blu-ray specs. I'd favor a > solution that is more generic and doesn't have to go through "codec > specific" lookup tables. In general I also prefer a solution that is independent from Blu-Ray. > Otherwise if the codec used for Blu-Rays subtitles is already > specific, we could just use the CodecState to store the SEI value when > it changes. > https://matroska.org/technical/specs/index.html#CodecState > > That means custom made text subtitles will not work properly with 3D > Blu-ray content because it doesn't use the same codec. Practically it seems better to have it as close as possible to Blu-Ray to make it easier to support it for hardware players that already support 3D Blu-Rays. > If we want the general case to work we may introduce an element at the > same level as CodecState that defines the Z-order for the Block. That > means it would have to translate the lookup index in the SEI to the > actual z-order value (if I understand correctly how it works). We need > to define if it's like the CodecState, ie it only changes from scene > to scene, not Block by Block. So it would be a State that needs to be > remembered when needed and only written when it changes. > > What is the range of depth allowed in Blu-Rays ? Are they discrete > value or floating values ? > >> One additional piece of information would be which array indexes of the >> SEI 3D depth info block are assigned to IG (interactive graphics). This >> could be used by media players or video renderers to decide at which >> 3D depth to draw the user interface (GUI/OSD). FWIW, it could be none, >> one or multiple array indexes. So the information field in the MKV header >> would have to be some sort of list/array. Logically this info would >> probably belong to the video track. This is less important than the >> subtitle assignment, though. But would still be nice to have. >> >> Best regards, madshi. > From nobody Sun Mar 13 03:24:17 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600A112D585 for ; Sun, 13 Mar 2016 03:24:15 -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 WIg6RdPbgDdz for ; Sun, 13 Mar 2016 03:24:13 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B3612D579 for ; Sun, 13 Mar 2016 03:24:13 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g3so137292368ywa.3 for ; Sun, 13 Mar 2016 03:24:13 -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=kiZ8/MMjChv6OVwejRXbKUszJ9oydwgokhx3ATghChc=; b=CcoXRJGUl8N3clrcoBvzWq5wANFcz2rMpSnucISXd2n8CH8I6bUxO+6JN9bvzmCqhm n6HBBjPci75kN8q2sPJp1cRe9KusId87yoNrC+KldLLmXnkLWVx6yPTf+0iyS3c0xCt4 4MXHUi1GOI1PMBbDwtzYqoW4zKdMMvaVx/6pnwbCceVHe5SnabIxqmvTfbJGkIR/QNZ1 oS99EOos/yC9Oeci/GKN3fhUtHSk1mU9wT3BvUeLWUtUsDouBHzRn1Onn/+StFGt/yFG 4XkOj/M33Gzcl5d7VsnWZCDFTl9FX4/JBOCpLD6IX4mOeIdo8STCzsZ9lAQSv/TzNhQH ACsA== 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=kiZ8/MMjChv6OVwejRXbKUszJ9oydwgokhx3ATghChc=; b=ZuE8w23Kr2gmdJCNitrAPbQItOGXxDmoR4ie44tgg2iQm9+ZiZaKtXgl3OsYBvFzQX vm5XJ+6gtirbd0FB7YK2Ev2GKuJvwoe0LqctykMkqToqLGuRDsok5aeoxNJ7l4o3HiHI 1G9l77UoFM4q9vxJW2uDbiYr0fj123urInHEoFZPp4NAg9EF0IyEy8LuzMyBM/o88SyW lULUdvrbdott+ThJJKx+ULnUTs58BMN0WGNBCOldpHHXrDlUXFQ92IzuoHHrmnw5/02y NZinB7H/HYcT1kZZH4E6m+DlNBG60tF5idNuyOmJj2+7H1mwbAtcIDpkpZLv+hb6ljyT oX5g== X-Gm-Message-State: AD7BkJJ+ehWFuvDMLdofCp5sLz2CJyi9nS3OM7jnPm/4gpyfAgzyPvoPHkPlAhoKs5TAu9IGS6cAEFYMPdEucw== MIME-Version: 1.0 X-Received: by 10.13.199.68 with SMTP id j65mr9339430ywd.289.1457864652293; Sun, 13 Mar 2016 03:24:12 -0700 (PDT) Received: by 10.83.58.69 with HTTP; Sun, 13 Mar 2016 03:24:12 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 Mar 2016 11:24:12 +0100 Message-ID: From: Steve Lhomme To: Ashley Blewer Content-Type: text/plain; charset=UTF-8 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, 13 Mar 2016 10:24:15 -0000 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 completion 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 can 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 XML 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 local 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 after decisions > are made here on CELLAR. I never heard of Jekyll before but it seems interesting. That would 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 find 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 the 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 From nobody Sun Mar 13 06:38:15 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51A612D979 for ; Sun, 13 Mar 2016 06:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1fbtsDh94qYj for ; Sun, 13 Mar 2016 06:38:10 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 CC7CE12D6C2 for ; Sun, 13 Mar 2016 06:38:09 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id d65so139806692ywb.0 for ; Sun, 13 Mar 2016 06:38:09 -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:content-transfer-encoding; bh=sC6S+ijyZ8/3G+Y2hxyGsMfEnOTQOvI1LyfnWY38Sks=; b=nEBA0YEjC0A3BKlos5+h7mpLKTRHEUcswMxAN2xhlyjWnReGHVUiEM7QzlDc2n2KGP vYRfCAgvJLulpO0+JiHmcDqQSj0mLgxTcviSlPRdiIKQ/VCeeNa6oWZX6RVWmdD/hdK2 rF2SNso8KOznucP5ElNthiJmv/xtShqljVaSswl3mfqDYsleWFn76Ln1PZY3C+C3w9f4 CyTxEctac37BxPKe0/WWsvpaO954m90Sx1NrKjRzvnsMaKPdQrhyyYgo27JZpM7TXXsh 6Chqdpr+kLDVYUQaL164tKVTpn9e8o+9aumjec9KXmJvyGlmJ+z5mA6IzYQTSqb7qkM2 Mjpw== 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:content-transfer-encoding; bh=sC6S+ijyZ8/3G+Y2hxyGsMfEnOTQOvI1LyfnWY38Sks=; b=SVQD0BFonUTX+O4ZIKGvn0fdms5fv+EY10VhxzNmDwssfR/WctXfT2AhGArQVT02M1 cONu2JsXzNxySQk2S9TTa85yrTYGlEyUXXSe/tw1HNzviqsP6t9ret+3Yz1YYpNYc8mK SvgTSnHtUcmarxeVLaqME3jVeMcK5QGCzBxYknkVAm3AMoll7kf01C3UpQ7SiFrrRNzX ksy+mgEnwN1sJc65VsPZPeD8CSdq+63WEEVTidWECIGsKCPnaVxQOB5tKx3NwrkwnLD3 Pu75GEwNecGysE69hVkjPB6qNQfnHoVoTQwXj4kU6ELWzKT/cD5VC6wb6LqpZjl+1E4J MK8w== X-Gm-Message-State: AD7BkJIZKluZL/9ndyzeVS4VoSfWsiaSXyykqfcISTy7eZPgWKTcwsKfdU0iiTtYBGx9aJaIa6Ccjt0m5Fo6ug== MIME-Version: 1.0 X-Received: by 10.13.255.4 with SMTP id p4mr9693512ywf.54.1457876289047; Sun, 13 Mar 2016 06:38:09 -0700 (PDT) Received: by 10.83.58.69 with HTTP; Sun, 13 Mar 2016 06:38:08 -0700 (PDT) In-Reply-To: <28AA7D94-34DC-4C31-9847-6912C70250DF@dericed.com> References: <56D036BA.9000603@noa-archive.com> <28AA7D94-34DC-4C31-9847-6912C70250DF@dericed.com> Date: Sun, 13 Mar 2016 14:38:08 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Display area clarification question 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, 13 Mar 2016 13:38:14 -0000 2016-03-07 6:03 GMT+01:00 Dave Rice : > >> On Feb 26, 2016, at 6:27 AM, Tobias Rapp wrote: >> >> Hello, >> >> when archiving SD material lines of the vertical blanking interval (VBI)= are sometimes stored at the top of the frame. For PAL the typical stored s= ize is 608x720 pixels with the bottom 576x720 area containing the actual im= age content. >> >> From looking at the Matroska specs this can be mapped into: >> >> PixelWidth =3D 720 >> PixelHeight =3D 608 >> PixelCropBottom =3D 0 >> PixelCropTop =3D 32 >> PixelCropLeft =3D 0 >> PixelCropRight =3D 0 >> >> I guess that the definition of the display area (DisplayWidth, DisplayHe= ight) applies to the pixel frame size *after* cropping? >> >> In that case it would be great if this would be made more explicit in th= e documentation of DisplayWidth and DisplayHeight. Also the defaults should= reflect that (i.e. default DisplayWidth =3D PixelWidth - PixelCropLeft - P= ixelCropRight). > > I tried to find some sample files that use PixelCrop* to see what the imp= lementation was like, but unfortunately this feature appears to be rarely u= sed. > > I found some samples all written by "libDivXMediaFormat 3.0.0.0386=E2=80= =9D where all the PixelCrop* values are set to zero. > > This sample appears to use PixelCrop* for non-defaults: http://archive.or= g/download/dl.icemusic.com/ArashFt.Aysel-AlwaysliveEurovisionSemiFinal2009.= -WwW.Myicemusic-IR.mkv > PixelWidth: 720 > PixelHeight: 576 > PixelCropBottom: 4 > PixelCropTop =3D 0 > PixelCropLeft =3D 2 > PixelCropRight =3D 4 > DisplayWidth =3D 1024 > DisplayHeight =3D 576 > > The sample does have blank rows and columns on the left, right, and botto= m edges so the cropping makes sense. Are there any display tools that use t= his feature? > > When I play this sample in VLC, I see Display resolution set to 714x572, = which is DisplayWidth - (PixelCropLeft + PixelCropRight) x DisplayHeight - = (PixelCropBottom + PixelCropTop), but as far as I can tell the pxiels are s= till displayed rather than cropped. In VLC your mileage may vary depending on the vout you're using, and thus the platform. To make sure your vou respects cropping, make sure the "offset_test.ogv" sample is displayed correctly: https://wiki.xiph.org/TheoraTestsuite There are also issues for players in general: if the codec specifies cropping values, should the container values go on top of them or simply replace them ? In VLC it's not handled properly. In the case of Matroska it should replace the values from the codec. At least that was originally the plan with 1080p MPEG2 that was coded in 1088 pixels. I think that's how mkvmerge handles it too. > ffplay from git-master plays the video at 720x576 (apparently not using P= ixelCrop* in any way). > > Neither VLC or ffplay appear to actually crop the presentation, though wi= th VLC it has an impact on the display size. > > While studying sample files I found a few other issues with Display area. > > I found 27 files, all from "WonderShare Matroska Muxer=E2=80=9D that set = DisplayWidth and DisplayHeight to 0 even though this is clearly invalid. Ex= ample: http://archive.org/download/gov.house.ogr.mark.20090310/gov.house.og= r.mark.20090310.mkv > > I also see many files where DisplayWidth and DisplayHeight are set to ver= y small values as if aspect ratios but with DisplayUnit unset (thus Display= Unit defaults to Pixels). For instance http://archive.org/download/1937-Die= -Schlacht-um-Miggershausen/1937-DieSchlachtUmMiggershausen12m28s.mkv by "li= bebml v0.7.7 + libmatroska v0.8.0=E2=80=9D "mkvmerge v1.7.0 ('What Do You T= ake Me For') built on Apr 28 2006 17:20:19=E2=80=9D uses a DisplayWidth of = 4, DisplayHeight of 3, and unset DisplayUnit. If I understand the spec corr= ectly, during playback the video should occupy four pixels by three pixels = of the screen. Here=E2=80=99s another 4/3 example but with DisplayUnit spec= ifically set to 0 (i.e. pixels): http://archive.org/download/3n-2zwd-1/az1.= mkv (muxed by libDivXMediaFormat 3.4.1.0004). > > In cases where I=E2=80=99ve seen DisplayUnit set to 3 (i.e. Display Aspec= t Ratio), the DisplayHeight and DisplayWidth are set to high numbers such a= s 1920x1080 or 1280x720 rather than 16x9. > > I may try to rewrite some of the Display definitions to add clarity, plea= se if you have any comments on these notes please let me know. > > Best Regards, > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Mar 13 06:42:25 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE6B12D62A for ; Sun, 13 Mar 2016 06:42:23 -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 7ZZOVjyv_iPf for ; Sun, 13 Mar 2016 06:42:21 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48AB012D61A for ; Sun, 13 Mar 2016 06:42:21 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id g3so139829887ywa.3 for ; Sun, 13 Mar 2016 06:42:21 -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:content-transfer-encoding; bh=7JawrFQ1vEpinmglF3kYx1s9Ee0MsFiYZtdwh9HlIdg=; b=PsdxmZQmPK4zvLR8hD/DYTMUKZzxnAS1ksM8NZdwDTKBROdyuhal5CWLATxYxIBzlm Fa/Wwrcb+HQoGYDMOT8VdqgFRoIqZoZQ4rXL2It0Qvqn5uJUX7vPVSsT8Ewx2XscU8Dv sH4ZyW9AQvpKmiBMk0d3VWeZaXtnA6ZZB6LsX9yBfvbJuLU/wdSexLlSazolmXpV5Qwl zsuNGgPzROLD/NHVm2PUTJjL7Bl6us2IyUZWSp7Q9p+UoP7m8pSmvtQwzHM6CbNXR7hV lIo3sEW8a3WL/Itl13R8tehppQNTGjeD8YtAVVgInDprkqCOR3/vk7MKbYO3Sp6myK6Y 2vyw== 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:content-transfer-encoding; bh=7JawrFQ1vEpinmglF3kYx1s9Ee0MsFiYZtdwh9HlIdg=; b=FvoMgz7dKK4oavsXAed74Dpbr/ctbxzNNv+ZyIg49nwpvwtfV2gCUiQ7vqZOvREfjW CJic0aI9DR1iCweUhhMKgp4T8S4JnbIRix2kdXD1v47UTLwFOrPmanAqkdREzXYozDW/ WuWUA/3H1TW+Pc3oyaTHwtGPqCVNNX1V2FV8KNa/8AjI5ptEXrek3h4F2Zt6VlEm4lJX SqazPzf8WeLolIhzL3gkVesS9nUQjZBuq7eOvLf3FsUgeQA6uvT2QNZAMAZ9XCLcq5La rhenmVGPWRcfGE8ER1TpdBjlXaTu0trS3lupwMH1Jet6JPhAHsBVvN86MAhxlYvZnnLJ vJpA== X-Gm-Message-State: AD7BkJKSzV1fQ/6Ts5SUHpXA8bPThp6G7Dh5AmjHh213vchTptQQdk+0QS24NPTvVbOR+UjRcQ80Q1NYtx02Tg== MIME-Version: 1.0 X-Received: by 10.129.29.3 with SMTP id d3mr9580535ywd.190.1457876540607; Sun, 13 Mar 2016 06:42:20 -0700 (PDT) Received: by 10.83.58.69 with HTTP; Sun, 13 Mar 2016 06:42:20 -0700 (PDT) In-Reply-To: References: <56C0D0D6.8000005@mediaarea.net> <56D9DEBF.5060705@gmx.de> Date: Sun, 13 Mar 2016 14:42:20 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 13:42:23 -0000 2016-03-07 6:15 GMT+01:00 Dave Rice : > >> On Mar 4, 2016, at 2:15 PM, Sebastian G. wrote: >> >> 28.02.2016, 15:22 Steve Lhomme: >>> 2016-02-14 20:09 GMT+01:00 Jerome Martinez : >>>> On 14/02/2016 19:08, Steve Lhomme wrote: >>>>> >>>>> 2016-02-14 18:33 GMT+01:00 Dave Rice : >>>>> [...] >>>>> >>>>>> Within the EBML Schema section I suggest adding: >>>>>> >>>>>> "An EBML Schema MUST declare exactly one Element at Level 0 (referre= d to >>>>>> as the Root Element) that MUST occur exactly once within an EBML Doc= ument. >>>>>> The Root Element MUST be mandatory and MUST be defined to occur exac= tly >>>>>> once. Note that the EBML and Void Elements may also occur at Level 0= but are >>>>>> not considered to be Root Elements." >>>>>> >>>>>> With this, I also suggest changing both EBML (Header) and Segment in= the >>>>>> Matroska spec to non-multiple. >>>>>> >>>>>> This would mean: >>>>>> >>>>>> invalid (multiple Root Elements) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> invalid (only header and no Root Element) >>>>>> >>>>>> >>>>>> >>>>>> valid (the usual MKV file) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> valid (two concatenated EBML Documents) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> If that's valid, then it's fine with me. Although it should be noted >>>>> that in that case the second EBML header is not taken in consideratio= n >>>>> and only the first one is used. That's to ensure the whole block of >>>>> concatenanted data can be handled just by knowing the first header. >>>> >>>> >>>> but if the second EBML header is different, analysis is wrong. >>>> So if we say that only the first one EBML header should be read: >>>> - we must state that we can concatenate files only if they have the sa= me >>>> EBML header (so same Matroska version? I don't the reason we should ma= ndate >>>> that Matroska versions are same) >>>> - we must state that EBML header must be identical. >>>> >>>> From my point of view that does not make sense (why do we need to dupl= icate >>>> the EBML header in that case). >>>> >>>> I am ok for having EBML header before each segment, but in that case t= he >>>> EBML header just before the segment should be considered as having the= right >>>> info (e.g. Matroska version). >>>> >>>> I am afraid about such file: >>>> EBML header with Matroska v4 (from file 1) >>>> Segment conforming to Matroska v4 (from file 1) >>>> EBML header with Matroska v5 (from file 2) >>>> Segment conforming to Matroska v5 (from file 2) >>> >>> I think we need more precision on the way compatible Doctypes can be >>> handled. It may be per format and not a rule set for all EBML >>> documents. For example mixing Matroska v1, v2 and v3 is fine as long >>> as you know beforehand you need v3 compatibility (so maybe it's ok >>> only if it appears first). You could also mix WebM and Matroska >>> Doctypes in the real world and still be okay. >> >> It appears that you don't have reached a consensus on the question >> whenever such structures should be valid. >> >> EBML should remain open to that. Then something building upon it can use >> it, forbid its use or restrict it. Matroska could make use of it, but >> IMO it should be optional for a player to support such a file. > > I agree. I think it appears that there=E2=80=99s consensus for (please co= rrect me if I=E2=80=99m wrong): > - EBML should allow EBML Documents to be concatenated as an EBML Stream > - each EBML Document must contain an EBML Header and one Root Element (Se= gment for matroska/webm) > > I think we also don=E2=80=99t yet have consensus on: > - What extra requirements should Matroska place on EBML Streams of Matros= ka/webm files (should docTypes and versions be known before the whole strea= m is read) > - Should players in any cases be expected to support EBML Streams (either= of consistent type/versions or not)? > > I propose to change Segment to mandatory and non-repeating within an EBML= Document. That sounds right to me. In the context of the EBML Document there should only be one Segment. Having multiple "EBML Document" concatenated is a higher level definition than what the amount of elements are allowed at a certain level ((0 in this case). Is it what you call an EBML Stream ? In that case, that seems correct to me. > Back to the original question of this thread. Any objections with a propo= sal like this statement for the EBML specification: > > "An EBML Schema MUST declare exactly one Element at Level 0 (referred to = as the Root Element) that MUST occur exactly once within an EBML Document. = The Root Element MUST be mandatory and MUST be defined to occur exactly onc= e. Note that the EBML and Void Elements may also occur at Level 0 but are n= ot considered to be Root Elements." LGTM. >> The thing with having it in EBML in general is that you couldn't mix >> (with) Doctypes that forbid it. >> >> To me it seems like it would create some overhead in the code. Just >> guessing. >> >> You could mix WebM and Matroska Doctypes, but Firefox will not play a >> Matroska file. > > That makes sense. A matroska player is more complex than a webm player. S= till I would love to see Firefox as a comprehensive Matroska player. > Dave > >> How would a player or an editor have to handle files where it would >> support Matroska v4, but not v5? Skip the v5 segment? Refuse to handle >> the file altogether? >> >> WebM and Matroska is the same problem, someone choose to implement only >> WebM (maybe because of the restriction in codecs) and has to decide what >> to do. >> >> What if some segment is invalid? Does it make the whole file invalid? >> >>> IMO at the EBML level (not knowing semantics) there's no reason to >>> restrict mismatching Doctypes. The thing we should restrict is whether >>> there's always an EBML header before an EBML content. IMO that should >>> be mandatory. >>> >>>> In the case we have first EBML header as the reference header, we pars= e >>>> second segment as Matroska v4 but it is actually v5. >>>> >>>> >>>>> Also that you don't mix different DocType in the same file (or do we >>>>> want to allow that ?). Meaning could also >>>>> be valid. >>>> >>>> >>>> Is there any reason we don't want different DocType? (and >>>> DocTypeReadVersion?) >>>> >>>> J=C3=A9r=C3=B4me >>>> >>>> >> >> Regards, >> Sebastian >> >> _______________________________________________ >> 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 --=20 Steve Lhomme Matroska association Chairman From nobody Sun Mar 13 06:58:34 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FF112D62A for ; Sun, 13 Mar 2016 06:58:32 -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 1PChyaE55GN6 for ; Sun, 13 Mar 2016 06:58:30 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 5174B12D624 for ; Sun, 13 Mar 2016 06:58:30 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id g127so140005809ywf.2 for ; Sun, 13 Mar 2016 06:58:30 -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:content-transfer-encoding; bh=fyN4kbmmyWl5GoeDl8OWku6bh2XVzX6vkZOIZLHbiJk=; b=HVT2mA2X6H9gGtG2m8jTrOzBofiQRVvzOa1/7OHpYQW0rAJ1CrD5ETJPkyCi17i9a0 zvYAd4dd0fUhPeXT5lx4Xt9e8u52JbGIb00livwJmiC2Iybb1Hxpcv7LFEE9/c1XbaCO cUNMJAnapuHBfcOhbsFa3A9udfX+PDZRDXZSHlKfEg2raKaAtk/XABiFNmvF/EfN3yA1 QMDo7h93US9bTylI7sHt+0a0Uto8A54WygOSlYQ/Y1E8WJH/qGyg1+p9BO7noS8LC499 TowRDDF2JA3xewz0WpNoP0E5KRcK+wsEAAmRTv6l7O99DETx7iPj9xnNmBSKpXUte1bo EYbw== 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:content-transfer-encoding; bh=fyN4kbmmyWl5GoeDl8OWku6bh2XVzX6vkZOIZLHbiJk=; b=PXoEGV11w6JtOCLW1k8ZU0grnWTR96NvAzqnXnWpunrrMBNvUKh0he5OGzZ9bmI+UN WzJRW7WdF25jBgnkLcTh3UD6Tqbq0nKgdmVDR71Nr2DCLV5fxgXVLfUndqBYg0HogNU/ 3JI2+xaBGhyxgJNE1pbv6qPuCGGl3p8M2nVRe1mw/4sNO3c5s+RWLT1GfLEIUqSpmBHB qbbd/5ke9hCKOGUEZ1f52s/9k7CiYqAIelPwmMYbehzzW/Q8PuoYJFoS6zpNoYF1qJa9 4KxFxtqw7Beiq0P/L6EGRsEpWYesNrljPdNRDx9OWK3NfWz4dnhYP8Eu+S6xom43Kbfr pk6Q== X-Gm-Message-State: AD7BkJKLTVGEo8ELlxGX1ohWDTzN7DJzmpu+Fc98twMQ0JbZXco9GZVkPcjEn7SyYDkuYgz8q1Vlx+J2MmIGOA== MIME-Version: 1.0 X-Received: by 10.37.21.5 with SMTP id 5mr9864153ybv.22.1457877509477; Sun, 13 Mar 2016 06:58:29 -0700 (PDT) Received: by 10.83.58.69 with HTTP; Sun, 13 Mar 2016 06:58:29 -0700 (PDT) In-Reply-To: <024A3647-85BD-42F5-AEAA-AF549C3F5CAF@dericed.com> References: <024A3647-85BD-42F5-AEAA-AF549C3F5CAF@dericed.com> Date: Sun, 13 Mar 2016 14:58:29 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Matroska Tags 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, 13 Mar 2016 13:58:32 -0000 2016-03-09 20:31 GMT+01:00 Dave Rice : > Hi all, > > I'm working on updating the documentation in the Matroska Tags section, b= ut have some questions and comments. Before going into the details. The tags have been redone 2 or 3 times. You can find ancient classes in libmatroska to deal with the old system. At some point we should drop this. That system used one element per tag name. That was way too much and harder to extend. > The definitions for Tags and Tag imply that the Tag structure only contai= ns metadata that relates to Tracks and Chapters, but elsewhere documentatio= n refers to Tags in use to describe Attachments. I propose to adding Attach= ments to the Tag and Tags definitions. Is there anything else that Tags can= describe besides Segment, Chapters, Tracks, and Attachments. An Edition can be tagged. See the 4 different possible UIDs https://www.matroska.org/technical/specs/tagging/index.html#TagTrackUID > If the Matorska Segment is a part of a linked series of Segments (using P= revUID and/or NextUID), is it possible to use Tags to refer to the linked s= eries of Segments? No, tags are only for the current Segment. If we want this feature we should add (multiple) SegmentUIDs as targets. The "COLLECTION" target type may cover this case too. It is "soft linking" though. For example 2 files with the same COLLECTION name may not actually be related. On the other hand, remuxing/transcoding would preserve the target even after the Segment UID(s) changed. > I'm presuming that the Tags element may only describe data within the sam= e containing Segment, is that right? So far, yes. > The Targets element is mandatory and the description says "It is empty to= describe everything in the segment." Does "is Empty" mean that the Targets= Master-element is literally empty with a zero value in the Element Data Si= ze. If the element is not set or set with no data. > I find it a little unintuitive that the TagAttachmentUID element relates = to another called FileUID. I realize that it's challenging to change the na= me of an element at this phase, but :( > For the linking UID Elements in this section I propose adding the Element= that the element links to by name. > > I'm confused as to why there are both TargetTypeValue and TargetType. The= TargetTypeValue just seems like the human-readable version of TargetType, = but what if they conflict? Are there scenarios where TargetType should be u= sed but not TargetTypeValue? You're right, it's the human-readable form. You could use one or the other (maybe that's not good). When there's both the TargetTypeValue is what matters. The specs says TargetType is only informational. I think the only reason TargetTypeValue is not mandatory is to allow tagging tracks/chapters/etc in the same tag. But maybe that's just too confusing and complex and it should just be made mandatory. It already had a default value so shouldn't be an issue when reading old files. > If Tag contains TagTrackUID=3D0 and TagTrackUID=3D{SPECIFIC_TRACKID}, doe= s this mean the Tag element refers to all tracks? All tracks in the segment, yes. > There is TagEditionUID but EditionUID is not mandatory, so it seems as if= the ability to describe a Chapter Edition depends on if an UID happens to = be there. The other UID Elements that Tags relate to are all mandatory. Any= reason that EditionUID is optional? Most of the times (99.99%) Chapters only have one edition. So it would mean adding extra useless data in most cases. > SimpleTag is one of the rare Elements that can appear at multiple levels.= Is it true that the only valid parent elements of SimpleTag are Tag and Si= mpleTag? Yes. > Best Regards, > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Mar 13 07:24:08 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 27BC512D583 for ; Sun, 13 Mar 2016 07:24:06 -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 5ASvjTyCUgmd for ; Sun, 13 Mar 2016 07:24:04 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F014612D505 for ; Sun, 13 Mar 2016 07:24:03 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id g203so195919528iof.2 for ; Sun, 13 Mar 2016 07:24:03 -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=YDPZ4Ld9dGC183gjKP2Vcez0SlACzJ/SY16/Zm9NUNo=; b=ifH+t1PqbXgOHd6nkXgRwtT8IqhY6maVDvVJ7KZrrWbuOtXmCQIK7zfY+x8T5QUnuR L7YNzpZSW46ufjIKM0cIJjBMnHnAnJ0NshiBTfTzLRfrirWg8SUiO7+EfCARCqELy8GW wBxjMVogKUrZMQNMkHmR7HTwe0tqekiMD3wUFCUeN/lQ1URJ2hSfNB1RqlGMgCmGcW9Q NxLi6Q/drAAva93XWRGx4n7WTLzSCnmUafZmr2AeEJ3r9zjRLThRNT+fPyGDsBYA+rM9 lsSFs8YPgB8wD9uYVq/6G2FUVyJbDTjhZrQHxWm85iTLHyLkK/EG7gl7peyjd61XJ7n7 c8CA== 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=YDPZ4Ld9dGC183gjKP2Vcez0SlACzJ/SY16/Zm9NUNo=; b=Fdmzk+aYNMV2JKjmLJ1RbDHFQ6sjND3SYrqUIQkt5TPT76KyMbhHW3xg/PL6BcLl1b +QsAA3bsKUiBHdzi5sBYw8aqNLVpCHH9Jkwpr7ld1bqM3v9+MnB7V/UPSazhkvy8j0oJ H0vnr2gm1gsKX/gyQonTLWh2nWtBBH3X6c241J+/vgPgJoBuvCzvyKA2ukFEOmK9VIej 5SKcETy3Tr4jB1IoORmLKSmaS12cEEw2np7s4RY5aVqsHUlurI6yFDtp1el1sZ9+PJ3C kvn8RdQ1CrgZG87MQ+CLP8NzT9+mYAoLc1AvHyHbZbbXXbCXKsIzMjSU90BifofpAiuW lQwg== X-Gm-Message-State: AD7BkJLuF7/tCYaPsmBy916G6DVB38Tr17upQE7FC0HNmgkA0hrFoAnHwTJ8sPCfR4+wGVRntNRqH6n5mEOvCw== MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr18128568ioe.38.1457879043333; Sun, 13 Mar 2016 07:24:03 -0700 (PDT) Received: by 10.79.9.196 with HTTP; Sun, 13 Mar 2016 07:24:03 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 Mar 2016 10:24:03 -0400 Message-ID: From: Ashley Blewer To: Steve Lhomme Content-Type: multipart/alternative; boundary=001a1140b47280e7b7052deeea87 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, 13 Mar 2016 14:24:06 -0000 --001a1140b47280e7b7052deeea87 Content-Type: text/plain; charset=UTF-8 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 will 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 know 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. 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 completion 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 can 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 XML 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 local > 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 after > decisions > > are made here on CELLAR. > > I never heard of Jekyll before but it seems interesting. That would 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 find > 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 the > 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 > --001a1140b47280e7b7052deeea87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We can always dedicate the table of elements to its own pa= ge -- 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 si= te and it will be ready for future collaboration with version-control built= in.

Steve, do you think the Jekyll site should mimic/re= plicate exactly the current site design or is some change in aesthetics fin= e? Don't know if we're tied to having the Github Page site look lik= e Matroska.org or if, since it's for spec viewing and work in particula= r, it's fine to appear differently.

Thanks muc= h!

Ashley
On Sun, Mar 13, 2016 at 6:24 AM, Steve Lhomme = <slhomme@matroska.org> wrote:
2016-03-06 22:39 GMT+01:00 A= shley Blewer <ashley.blewer@g= mail.com>:
> Hey all!
>
> There's been some discussion about a collaborative framework with = which to
> continue work on the Matroska specification in a code-development cont= ext
> after we've had conversations on this list.
>
> I'd like to propose we migrate the Matroska specification to Githu= b. As I
> mentioned before, I'm happy to carry this transition to completion= 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 collaborati= ve
> 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 can be = made
> to look like the Matroska site.
>
> The pros and cons are both in terms of ease of use. The benefits are w= orking
> in the more human-readable Markdown instead of HTML. The negative is t= hat
> running a local Jekyll server to preview work before submitting a requ= est 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 XML an= d
> 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 local= server.
> But work is harder to read because it's in HTML and most changes w= ill 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 after dec= isions
> are made here on CELLAR.

I never heard of Jekyll before but it seems interesting. That w= ould 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 find
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 the
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

--001a1140b47280e7b7052deeea87-- From nobody Sun Mar 13 07:45:03 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 7EFF512D63C for ; Sun, 13 Mar 2016 07:45: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 VmZzXKKCWM88 for ; Sun, 13 Mar 2016 07:44: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 8F14012D63A for ; Sun, 13 Mar 2016 07:44:59 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:33418 helo=[10.0.1.11]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1af7GM-000kLl-Gu for cellar@ietf.org; Sun, 13 Mar 2016 10:45:00 -0400 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> Date: Sun, 13 Mar 2016 10:44:52 -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=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] Matroska Attachments 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, 13 Mar 2016 14:45:01 -0000 Dear CELLAR, =46rom a review of the Attachments section a few more questions and = comments before I send a patch. What is the status of FileReferral, FileUsedStartTime, and = FileUsedEndTime. These seem to be part of a Matroska extension for divX. = Should these Elements be included in our work? Are these deprecated? FileUID is defined as "Unique ID representing the file, as random as = possible." (actually many UID Elements use this language about = randomness). Does this mean that a Unique ID field could be any length = from 1 to 8 octets? Or are Unique IDs presumed to be a specific length? Most of the specific narrative about attachments appears to be here: = https://www.matroska.org/technical/cover_art/index.html. It lists some = reserved attachment file names like cover, cover_land, small_cover. Are = there more reserved names like this? I think this document should be = expanded to cover other use cases for attachments to include both access = and preservation examples, but what should they be: - cover, poster images - fonts to support subtitles - logs or additional metadata - archived copy of a decoder? I'd be interested to here in other innovative ways to use attachments. Also the cover image examples seem to use specs that are aged. A cover = image is recommended to be 600 pixels tall/wide, but should this values = be increased as user expectations of image quality increase? Dave Rice= From nobody Sun Mar 13 08:35: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 1076E12D584 for ; Sun, 13 Mar 2016 08:35:39 -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 Q1zyXVRvfgdo for ; Sun, 13 Mar 2016 08:35:36 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E63D12D536 for ; Sun, 13 Mar 2016 08:35:36 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:44591 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 1af83J-0020om-Oe; Sun, 13 Mar 2016 11:35:37 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Sun, 13 Mar 2016 11:35:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56C0D0D6.8000005@mediaarea.net> <56D9DEBF.5060705@gmx.de> To: Steve Lhomme X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-0.2 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] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 15:35:39 -0000 > On Mar 13, 2016, at 9:42 AM, Steve Lhomme = wrote: >=20 > 2016-03-07 6:15 GMT+01:00 Dave Rice : >>=20 >>> On Mar 4, 2016, at 2:15 PM, Sebastian G. wrote: >>>=20 >>> 28.02.2016, 15:22 Steve Lhomme: >>>> 2016-02-14 20:09 GMT+01:00 Jerome Martinez : >>>>> On 14/02/2016 19:08, Steve Lhomme wrote: >>>>>>=20 >>>>>> 2016-02-14 18:33 GMT+01:00 Dave Rice : >>>>>> [...] >>>>>>=20 >>>>>>> Within the EBML Schema section I suggest adding: >>>>>>>=20 >>>>>>> "An EBML Schema MUST declare exactly one Element at Level 0 = (referred to >>>>>>> as the Root Element) that MUST occur exactly once within an EBML = Document. >>>>>>> The Root Element MUST be mandatory and MUST be defined to occur = exactly >>>>>>> once. Note that the EBML and Void Elements may also occur at = Level 0 but are >>>>>>> not considered to be Root Elements." >>>>>>>=20 >>>>>>> With this, I also suggest changing both EBML (Header) and = Segment in the >>>>>>> Matroska spec to non-multiple. >>>>>>>=20 >>>>>>> This would mean: >>>>>>>=20 >>>>>>> invalid (multiple Root Elements) >>>>>>>=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>=20 >>>>>>> invalid (only header and no Root Element) >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> valid (the usual MKV file) >>>>>>>=20 >>>>>>> >>>>>>> >>>>>>>=20 >>>>>>> valid (two concatenated EBML Documents) >>>>>>>=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>=20 >>>>>> If that's valid, then it's fine with me. Although it should be = noted >>>>>> that in that case the second EBML header is not taken in = consideration >>>>>> and only the first one is used. That's to ensure the whole block = of >>>>>> concatenanted data can be handled just by knowing the first = header. >>>>>=20 >>>>>=20 >>>>> but if the second EBML header is different, analysis is wrong. >>>>> So if we say that only the first one EBML header should be read: >>>>> - we must state that we can concatenate files only if they have = the same >>>>> EBML header (so same Matroska version? I don't the reason we = should mandate >>>>> that Matroska versions are same) >>>>> - we must state that EBML header must be identical. >>>>>=20 >>>>> =46rom my point of view that does not make sense (why do we need = to duplicate >>>>> the EBML header in that case). >>>>>=20 >>>>> I am ok for having EBML header before each segment, but in that = case the >>>>> EBML header just before the segment should be considered as having = the right >>>>> info (e.g. Matroska version). >>>>>=20 >>>>> I am afraid about such file: >>>>> EBML header with Matroska v4 (from file 1) >>>>> Segment conforming to Matroska v4 (from file 1) >>>>> EBML header with Matroska v5 (from file 2) >>>>> Segment conforming to Matroska v5 (from file 2) >>>>=20 >>>> I think we need more precision on the way compatible Doctypes can = be >>>> handled. It may be per format and not a rule set for all EBML >>>> documents. For example mixing Matroska v1, v2 and v3 is fine as = long >>>> as you know beforehand you need v3 compatibility (so maybe it's ok >>>> only if it appears first). You could also mix WebM and Matroska >>>> Doctypes in the real world and still be okay. >>>=20 >>> It appears that you don't have reached a consensus on the question >>> whenever such structures should be valid. >>>=20 >>> EBML should remain open to that. Then something building upon it can = use >>> it, forbid its use or restrict it. Matroska could make use of it, = but >>> IMO it should be optional for a player to support such a file. >>=20 >> I agree. I think it appears that there=E2=80=99s consensus for = (please correct me if I=E2=80=99m wrong): >> - EBML should allow EBML Documents to be concatenated as an EBML = Stream >> - each EBML Document must contain an EBML Header and one Root Element = (Segment for matroska/webm) >>=20 >> I think we also don=E2=80=99t yet have consensus on: >> - What extra requirements should Matroska place on EBML Streams of = Matroska/webm files (should docTypes and versions be known before the = whole stream is read) >> - Should players in any cases be expected to support EBML Streams = (either of consistent type/versions or not)? >>=20 >> I propose to change Segment to mandatory and non-repeating within an = EBML Document. >=20 > That sounds right to me. In the context of the EBML Document there > should only be one Segment. Having multiple "EBML Document" > concatenated is a higher level definition than what the amount of > elements are allowed at a certain level ((0 in this case). Is it what > you call an EBML Stream ? In that case, that seems correct to me. That understanding matches mine. That an EBML Document is comprised of = one EBML Element and one Root Element (Segment in mkv/webm) and = optionally VOID Elements. Many EBML Documents may be concatenated into = an EBML Stream (some constraints on EBML Streams are still in open = discussion). Pull request submitted here: = https://github.com/Matroska-Org/foundation-source/pull/11 >> Back to the original question of this thread. Any objections with a = proposal like this statement for the EBML specification: >>=20 >> "An EBML Schema MUST declare exactly one Element at Level 0 (referred = to as the Root Element) that MUST occur exactly once within an EBML = Document. The Root Element MUST be mandatory and MUST be defined to = occur exactly once. Note that the EBML and Void Elements may also occur = at Level 0 but are not considered to be Root Elements." >=20 > LGTM. Pull request submitted here: = https://github.com/Matroska-Org/ebml-specification/pull/58 >>> The thing with having it in EBML in general is that you couldn't mix >>> (with) Doctypes that forbid it. >>>=20 >>> To me it seems like it would create some overhead in the code. Just >>> guessing. >>>=20 >>> You could mix WebM and Matroska Doctypes, but Firefox will not play = a >>> Matroska file. >>=20 >> That makes sense. A matroska player is more complex than a webm = player. Still I would love to see Firefox as a comprehensive Matroska = player. >> Dave >>=20 >>> How would a player or an editor have to handle files where it would >>> support Matroska v4, but not v5? Skip the v5 segment? Refuse to = handle >>> the file altogether? >>>=20 >>> WebM and Matroska is the same problem, someone choose to implement = only >>> WebM (maybe because of the restriction in codecs) and has to decide = what >>> to do. >>>=20 >>> What if some segment is invalid? Does it make the whole file = invalid? >>>=20 >>>> IMO at the EBML level (not knowing semantics) there's no reason to >>>> restrict mismatching Doctypes. The thing we should restrict is = whether >>>> there's always an EBML header before an EBML content. IMO that = should >>>> be mandatory. >>>>=20 >>>>> In the case we have first EBML header as the reference header, we = parse >>>>> second segment as Matroska v4 but it is actually v5. >>>>>=20 >>>>>=20 >>>>>> Also that you don't mix different DocType in the same file (or do = we >>>>>> want to allow that ?). Meaning could = also >>>>>> be valid. >>>>>=20 >>>>>=20 >>>>> Is there any reason we don't want different DocType? (and >>>>> DocTypeReadVersion?) >>>>>=20 >>>>> J=C3=A9r=C3=B4me >>>>>=20 >>>>>=20 >>>=20 >>> Regards, >>> Sebastian >>>=20 >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Sun Mar 13 08:41:27 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399FB12D64E for ; Sun, 13 Mar 2016 08:41:25 -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 32CVvvovqDqe for ; Sun, 13 Mar 2016 08:41: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 0884A12D64B for ; Sun, 13 Mar 2016 08:41:24 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:41308 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 1af88x-0026EB-4o for cellar@ietf.org; Sun, 13 Mar 2016 11:41:24 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 13 Mar 2016 11:41: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=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] ebml constraints on occurrences 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, 13 Mar 2016 15:41:25 -0000 The definition for min and maxOccurs which define how often the Element = can occur didn=E2=80=99t work for Level 0 Elements. The definition was: > An integer to express the minimal number of occurrences that the EBML = Element MUST occur within its Parent Element if its Parent Element is = used. however, Level 0 Elements have no Parent Element. I added the line: > If the Element has no Parent Level (as is the case with Elements at = Level 0), then minOccurs refers to constaints on the Element's = occurrence within the EBML Document. This is in this PR: = https://github.com/Matroska-Org/ebml-specification/pull/59 Dave Rice= From nobody Sun Mar 13 10:24: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 D9A3512D6BF for ; Sun, 13 Mar 2016 10:24:36 -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 yeVX59SNIfXD for ; Sun, 13 Mar 2016 10:24:35 -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 6210312D6BD for ; Sun, 13 Mar 2016 10:24:34 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:41204 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 1af9kn-000DWA-AR for cellar@ietf.org; Sun, 13 Mar 2016 13:24:35 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <90F49141-8B2B-4DB6-8727-A8F903493BF5@dericed.com> Date: Sun, 13 Mar 2016 13:24:30 -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=-1.0 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] Top-Level Elements X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 17:24:37 -0000 There are several places where =E2=80=9CTop-Level Elements=E2=80=9D are = referred to in the Matroska specification documents, but it=E2=80=99s = not defined. In XML the Top-Level Element is the node at Level 0, but in = Matroska=E2=80=99s environment the Level 0 Element is the Root Element = and the Level 1 Elements are the Top-Level Elements. To clarify I added this line to the EBML spec: > Elements defined to only occur at Level 1 are known as Top-Level = Elements. I used the term =E2=80=98only=E2=80=99 because CRC-32 and Void are = allowed to occur there but I wouldn=E2=80=99t consider them Top-Level = Elements since they may freely occur in other levels. Also in a few places where Level 0 and Level 1 Elements were referenced, = I updated the references to use the terms Root Element and Top-Level = Elements instead. Here=E2=80=99s the PR for the EBML Spec: https://github.com/Matroska-Org/ebml-specification/pull/60 And updating some language in Matroska=E2=80=99s EBML Schema: = https://github.com/MediaArea/matroska-foundation-source/commit/9c3245873ef= 5eacb2a96b854169b0d7f513fdccd Dave Rice= From nobody Sun Mar 13 10:28:47 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE50612D6BB for ; Sun, 13 Mar 2016 10:28:45 -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 2ZEgScbwChbO for ; Sun, 13 Mar 2016 10:28:44 -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 5F43C12D6D1 for ; Sun, 13 Mar 2016 10:28:35 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:44243 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 1af9og-000Fuw-Lc for cellar@ietf.org; Sun, 13 Mar 2016 13:28:36 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <588EFF1A-54FE-4356-AB63-F632122D8926@dericed.com> Date: Sun, 13 Mar 2016 13:28:31 -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=-1.0 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] human readable EBML Element definitions 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, 13 Mar 2016 17:28:46 -0000 Hi all, I=E2=80=99m looking for advice on how to present EBML Elements in a = human readable form.=20 The current structure in the EBML Specification is a bit messy and hard = to read: = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown#ebml-header-elements I just tried to update this to tables with one table per Element = definition: = https://github.com/MediaArea/ebml-specification/blob/update-EBML-elements-= to-new-definition-style/specification.markdown#ebml-header-elements But there=E2=80=99s also the current form of the matroska.org = presentation of the Elements at = https://matroska.org/technical/specs/index.html#LevelEBML. Any advice or comments or suggestions on what works? Best Regards, Dave Rice= From nobody Sun Mar 13 10:58:47 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6B712D6EF for ; Sun, 13 Mar 2016 10:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICDQvMPwE6ql for ; Sun, 13 Mar 2016 10:58:43 -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 80DBE12D711 for ; Sun, 13 Mar 2016 10:58:43 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:48667 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 1afAHo-000jXK-Jo; Sun, 13 Mar 2016 13:58:44 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Sun, 13 Mar 2016 13:58:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2760A3BD-2BA6-43C8-88D1-B001F7BB6706@dericed.com> References: <67CC4B76-C58C-452C-BFA4-735D1469F5C5@dericed.com> <5693DAF4.7090803@mediaarea.net> <9F069A81-015C-436E-96BE-CD014DD5591D@dericed.com> <5693F2AD.4080206@gmx.de> <5BBDFD1A-E2B2-40D8-B61D-1B4000B84372@dericed.com> <970BC6A9-BDED-4743-9D40-7FAC266B53EF@dericed.com> To: Steve Lhomme X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 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] Matroska Interlacement proposal draft (+ minver and webm in EBML Schemas) 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, 13 Mar 2016 17:58:46 -0000 > On Jan 26, 2016, at 6:53 AM, Steve Lhomme = wrote: >=20 > 2016-01-22 6:29 GMT+01:00 Dave Rice : >>=20 >>> On Jan 14, 2016, at 7:13 AM, Steve Lhomme = wrote: >>>=20 >>> 2016-01-11 21:42 GMT+01:00 Dave Rice : >>>>=20 >>>>> On Jan 11, 2016, at 1:21 PM, Sebastian G. wrote: >>>>>=20 >>>>> 11.01.2016, 18:08 Dave Rice: >>>>>> Update FlagInterlaced version 3 >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> Element Name: FlagInterlaced >>>>>> Level: 4 >>>>>> ID: [9A] >>>>>> Mandatory: mand. >>>>>> Multiple: - >>>>>> Range: 0-2 >>>>>> Default: 0 >>>>>> Type: u >>>>>> Description: A flag to declare is the video is known to = be progressive or interlaced and if applicable to declare details about = the interlacement. >>>>>> 0: undetermined >>>>>> 1: interlacement (unknown field ordering) >>>>>=20 >>>>> '(unknown field order)' is not required if it is split into to = elements. >>>>> I have no preference for or against splitting it up. >>>>>=20 >>>>>> 2: progressive >>>>>>=20 >>>>>> Element Name: FieldOrdering >>>>>> Level: 4 >>>>>> ID: [9D] >>>>>> Mandatory: mand. >>>>>> Multiple: - >>>>>> Range: 0-2 >>>>>> Default: 0 >>>>>> Type: u >>>>>> Description: Declare the field ordering of the video. If = FlagInterlaced is not set to 1, this Element MUST be ignored. >>>>>>=20 >>>>>> 0 undetermined >>>>>> 1 interlaced (bottom field first) >>>>>> 2 interlaced (top field first) >>>>>=20 >>>>> I think that using '0' as no statement is a good decision. >>>>=20 >>>> [=E2=80=A6] >>>>=20 >>>> Based on comments, I made the following patch. I also renamed the = proposed =E2=80=9CFieldOrdering=E2=80=9D element to =E2=80=9CField = Order=E2=80=9D and change the meaning of FlagInterlaced=3D1 to simply = =E2=80=9Cinterlaced=E2=80=9D. >>>>=20 >>>> Creating the patch for specdata.xml brought up two new issues: >>>>=20 >>>> The format of specdata.xml includes an attribute called = =E2=80=98minver=E2=80=99 to refer to which version of Matroska began = supporting the element. According to matroska.org "Version 4 is = currently work in progress. There may be further additions to v4.=E2=80=9D= ; however there has been no distinction within specdata.xml between = =E2=80=98in progress=E2=80=99 and official. Perhaps Matroska should mark = version 4 as official as-is and the ongoing work within CELLAR would = work towards a release of version 5. In the patch below I used = minver=3D=E2=80=9C5RC=E2=80=9D as (version 5 release candidate) in infer = that it is not official (yet). >>>>=20 >>>> Also specdata.xml includes a boolean attribute to say if the = element is supported by webm. FlagInterlaced is supported by webm (as = correlates to http://www.webmproject.org/docs/container/), but I=E2=80=99m= leaving webm=3D=E2=80=9C1=E2=80=9D off of the new element = =E2=80=9CFieldOrder=E2=80=9D (as I=E2=80=99m not on that team). >>>>=20 >>>> =46rom 5d7f7b8122232c20a3e39de70d587f684b48cd2f Mon Sep 17 00:00:00 = 2001 >>>> From: dericed >>>> Date: Mon, 11 Jan 2016 15:11:26 -0500 >>>> Subject: [PATCH] clarify FlagInterlaced and add FieldOrder element >>>>=20 >>>> --- >>>> spectool/specdata.xml | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>=20 >>>> diff --git a/spectool/specdata.xml b/spectool/specdata.xml >>>> index 57abb97..2167e15 100644 >>>> --- a/spectool/specdata.xml >>>> +++ b/spectool/specdata.xml >>>> @@ -109,7 +109,8 @@ between two successive fields at the output of = the decoding process (see >>> The chapter codec using this ID (0: Matroska Script, 1: = DVD-menu). >>>> The binary value = used to represent this track in the chapter codec data. The format = depends on the ChapProcessCodecID used. >>>> Video settings. >>>> - Set if the video is interlaced. = (1 bit) >>>> + A flag to declare is the video is = known to be progressive or interlaced and if applicable to declare = details about the interlacement. (0: undetermined, 1: interlaced, 2: = progressive) >>>> + Declare the field ordering of the video. If = FlagInterlaced is not set to 1, this Element MUST be ignored. (0: = undetermined, 1: interlaced with bottom field first, 2: interlaced with = top field first) >>>=20 >>> I'll have to check if the spec generating tools supports minver as a >>> non integer before merging this. >>=20 >> So perhaps we should have a separate xml for drafting while the work = on the version is underway. Such as: >>=20 >> - specdata.xml (as the official version 4 EBML Schema) >> - specdata_v5_draft.xml as a working document to patch to until = Matroska version 5 is deemed official >=20 > Sounds like a good plan. >=20 >>>> Stereo-3D video mode (0: mono, 1: side by side (left eye = is first), 2: top-bottom (right eye is first), 3: top-bottom (left eye = is first), 4: checkboard (right is first), 5: checkboard (left is = first), 6: row interleaved (right is first), 7: row interleaved (left is = first), 8: column interleaved (right is first), 9: column interleaved = (left is first), 10: anaglyph (cyan/red), 11: side by side (right eye is = first), 12: anaglyph (green/magenta), 13 both eyes laced in one Block = (left eye is first), 14 both eyes laced in one Block (right eye is = first)) . There are some more details on 3D = support in the Specification Notes. >>>> Alpha Video Mode. Presence of this element indicates that = the BlockAdditional element could contain Alpha data. = DEPRECATED, DO NOT = USE. Bogus StereoMode value used in old versions of libmatroska. (0: = mono, 1: right eye, 2: left eye, 3: both eyes). >>>> Width of the encoded video frames in pixels. >>>> =E2=80=94 >>>> 2.6.4 I=E2=80=99ve updated this proposal for interlacement fields. The = FieldOrder element now reflects the same options as used in the second = byte of the fiel atom of the QuickTime spec = (https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/QTFF= Chap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-124374). See also: = https://github.com/FFmpeg/FFmpeg/blob/fb9036b3142e06631a70810c3d779f8e2d9f= 180c/libavformat/mov.c#L1324-L1336. A difference between that FieldOrder list provided here and the = QuickTime version, is that I added 2 to represent an undefined order = (presently any Matroska field with FlagInterlaced and no FieldOrder is = technically of an undetermined order, so I think it is necessary to add = a value to indicate so). Note that the list for FlagInterlaced differs from the QuickTime spec. = In QuickTime 1=3Dprog and 2=3Dint but this is reversed in Matroska. Too = late to change this, but I think it=E2=80=99s sensible to draw from = QuickTime for the fieldOrder list. The definitions are like this: name: FlagInterlaced level: 4 id: 0x9A type: uinteger mandatory: 1 minver: 2 webm: 1 default: 0 range: 0-2 documentation: A flag to declare is the video is known to be progressive = or interlaced and if applicable to declare details about the = interlacement. (0: undetermined, 1: interlaced, 2: progressive) name: FieldOrder level: 4 id: 0x9D type: uinteger mandatory: 1 minver: 4 default: 2 range: 0-14 documentation: Declare the field ordering of the video. If = FlagInterlaced is not set to 1, this Element MUST be ignored. (0: = Progressive, 1: Interlaced with top field display first and top field = stored first, 2: Undetermined field order, 6: Interlaced with bottom = field displayed first and bottom field stored first, 9: Interlaced with = bottom field displayed first and top field stored first, 14: Interlaced = with top field displayed first and bottom field stored first) I left the minver as 4, but should this be set to 5. I suppose this = question applies to the Colour Format proposal as well. A draft pull request is updated and available at: = https://github.com/Matroska-Org/foundation-source/pull/13 Best Regards, Dave Rice From nobody Sun Mar 13 12:25:00 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF94D12D6C6 for ; Sun, 13 Mar 2016 12:24:58 -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 EAmXBpNV-1r1 for ; Sun, 13 Mar 2016 12:24:57 -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 6DE2812D65D for ; Sun, 13 Mar 2016 12:24:57 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:42069 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 1afBdI-002x3Y-JK for cellar@ietf.org; Sun, 13 Mar 2016 15:24:58 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 13 Mar 2016 15:24:53 -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=-1.0 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] 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: Sun, 13 Mar 2016 19:24:59 -0000 The EBML specification is licensed under CC BY 4.0: = https://github.com/Matroska-Org/ebml-specification/blob/master/README.mark= down What is the license for the documentation and specification of Matroska. = I see this https://matroska.org/node/47, but it doesn=E2=80=99t list the = license of the spec specifically. Am I missing something? Dave Rice= From nobody Mon Mar 14 01:11:43 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 00A8E12DA48 for ; Mon, 14 Mar 2016 01:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijg2-eHPenGC for ; Mon, 14 Mar 2016 01:11:40 -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 A9C0D12DA47 for ; Mon, 14 Mar 2016 01:11:40 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 2C20C195D18A; Mon, 14 Mar 2016 09:11:38 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 53C14195D183 for ; Mon, 14 Mar 2016 09:11:37 +0100 (CET) Received: by sweet-chili.local (Postfix, from userid 1000) id CF6C41D6F83; Mon, 14 Mar 2016 09:11:36 +0100 (CET) Date: Mon, 14 Mar 2016 09:11:36 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160314081136.GC25555@bunkus.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0lnxQi9hkpPO77W3" 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] 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: Mon, 14 Mar 2016 08:11:42 -0000 --0lnxQi9hkpPO77W3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, just like the EBML specs we haven't really talked about a license yet. I'm fine with CC BY 4.0. Steve? Kind regards, mosu --0lnxQi9hkpPO77W3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW5nI4AAoJEHSvAK3y4yyFLv8QAKKqb78m9QpTfvoXK/GlazQ2 JRdmM+zjm3vxpO3m7ngc+eEBfQ7RZzlnjvhRjea93kcdeewQJshC27JpAbOOLwLI qacaADrvcFpxKA9qinjk7GR5jaSMr+oCsZbXJbXCWO6wLp6wrgb1EzkT9/9sx+Wr gHXQKDnO3x+VIvMvKnMa1uVXAFHe8icWhUGTqjcoVQDDuPzkT3WZopCVLmsT8395 83r7w87uOstvDFngo4O21ToxndXDRzuzdDr7KOOLcnXe9gIZ5xAzdmm+dz9WZRXy ogJrY4BrWNFpTpNlwKGuZpfoYdpjUyqp2piLM3G+uSZWC19kHdtC4sifKpgANQ+V LXEAOCEgZamn82rm5KVZnmJGWr7159stMUWC92RKnD7cPGsDjkCkIVPZIfjIR8Jh NOTyFlKW6d27ZDW6sYYYBgGl2cNrA6xCfgR3BKR/rm+hcgz69SYv4BjRqpHBIP1k U0hxt52h5prUINWtVs9J3IhVYpoxPCFqz7IF9qHhtn8Tgmljz6JsKJTT+kNwDcYQ i2pnA5x0VB131hC62BZYKXc/xnjUkQZ3PDm+eTKJfuO0/RGaDFppbPyd00exMeim gr1i8CdsBKZ7hz+VSL8ihGJRzopkokcg24MPvl07XOwZM/usOC1ySY/Xm9xVTs6l 8HBQaQv59sspUQa+XX4x =tXCg -----END PGP SIGNATURE----- --0lnxQi9hkpPO77W3-- From nobody Mon Mar 14 01:29:44 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 4F83312D9B9 for ; Mon, 14 Mar 2016 01:29:43 -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 Dt9i1oqgx-v3 for ; Mon, 14 Mar 2016 01:29:40 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBE712D8ED for ; Mon, 14 Mar 2016 01:29:40 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g127so158457413ywf.2 for ; Mon, 14 Mar 2016 01:29:40 -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=dxQVMFeoWw0v6Tu1M4mi6R1wzve0+7iRKSaQ3XN/vRE=; b=lLUdbq1fEMFX4IycGIKNFW2RhhG15Z+QeCb7gKMY6dYuPLiukYN3/wEn2owJh2XrTe ND3ZuqWwxvZcSgSxq8C6XEnoc5O6/taUZGksJFlslu8m4wyoClxuHd7SczrWx7yn4s7k cUl07fkgY08xsPTutmmSYBq35zGQFmFX94L5RXnT1hj4XSkcFvyQXQb4+Warxo1qsJkY TqezW4UwkkofTXzzSwi87UCb6wekWvrHgWzs4oY6YDepGaC67czRjAfvqnMUTTb8LMXt 6wZ1fEdz/vusg2IUtWjXXTGIq9A6Q//b6u6NuzPxbhi+weB0rB8tUfzTICC/p7vyruxV QGEw== 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=dxQVMFeoWw0v6Tu1M4mi6R1wzve0+7iRKSaQ3XN/vRE=; b=I+Rp901iSHywKeiKEDb0My1e9r35sq4u+seCb5sD0hRDVJlUgfXDSCe1AfMJHBCDMo Z4IVJXohU1jDq8O6rYfxsVigpMkmICjklSNnQtl3KxSA4fPmFZprV3ySuYXcDwGu1MtJ Y8SFNHf9qhF5XGxKUS61/DiInBvt6+rExSe/6qqIXh9AXrAFvAqjttpTsjBH1CQE8gMM Vv4RFjnWlsDCSjfGKIo4XJVKe8LdG59YsIw46VFQFLK294Eseya4FXr3vwIO8CEow/3C O2yCLzHOHZ4aQyP+VT9bdOUY1UptnadfUtwqcdxeIs0UBhBMkTnnbtkqJt7PFvCPr3Yt 2MHA== X-Gm-Message-State: AD7BkJLoYa/3pXlFNfZol1RV2lA8iibyvoZCOk6TAVpLKj6l72CDX1L+rhIz7D/i3GI5z1Ree2GAs4PES5Sgxw== MIME-Version: 1.0 X-Received: by 10.37.231.135 with SMTP id e129mr10941573ybh.11.1457944179470; Mon, 14 Mar 2016 01:29:39 -0700 (PDT) Received: by 10.83.58.69 with HTTP; Mon, 14 Mar 2016 01:29:39 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Mar 2016 09:29:39 +0100 Message-ID: From: Steve Lhomme To: Ashley Blewer Content-Type: text/plain; charset=UTF-8 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, 14 Mar 2016 08:29:43 -0000 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 will 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 know 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 completion 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 can 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 XML 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 local >> > 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 after >> > decisions >> > are made here on CELLAR. >> >> I never heard of Jekyll before but it seems interesting. That would 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 find >> 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 the >> 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 From nobody Mon Mar 14 03:24:51 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5835E12D521 for ; Mon, 14 Mar 2016 03:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbp46np0BSi5 for ; Mon, 14 Mar 2016 03:24:48 -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 3A60112D1E5 for ; Mon, 14 Mar 2016 03:24:48 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id C36A5195ECCD; Mon, 14 Mar 2016 11:24:44 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 20003195ECBF; Mon, 14 Mar 2016 11:24:42 +0100 (CET) Received: by sweet-chili.local (Postfix, from userid 1000) id 853AE1D72A4; Mon, 14 Mar 2016 11:24:41 +0100 (CET) Date: Mon, 14 Mar 2016 11:24:41 +0100 From: Moritz Bunkus To: CELLAR list , matroska-devel Message-ID: <20160314102441.GD25555@bunkus.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UoPmpPX/dBe4BELn" Content-Disposition: inline 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: [Cellar] 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: Mon, 14 Mar 2016 10:24:50 -0000 --UoPmpPX/dBe4BELn Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, I'm currently looking into storing WebVTT subtitles[1] in Matroska due to user requests and Youtube's usage of WebVTT. The format is similar to SRT but unfortunately much more powerful and therefore not as straightforward to store. Things we have to specify how to store include: 1. The actual CodecID and encoding 2. Codec private data (all global blocks like STYLE, REGION and NOTEs appearing before the first entry) 3. NOTE blocks between entries 4. tags/numbers preceding an entry 5. cue settings 6. cue timestamps in entries Here's an example including all of the aforementioned problems: ------------------------------------------------------------ WEBVTT 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. 4 00:00:40.000 --> 00:00:45.000 Example entry 3: Entries can be numbered (like this one)=E2=80=A6 00:00:46.000 --> 00:00:47.000 Example entry 4: =E2=80=A6but don't have to be. 00:01:03.000 --> 00:01:06.500 position:90% align:right size:35% Example entry 5: That stuff to the right of the timestamps are cue settings. 00:02:02.500 --> 00:02:22.500 region:bill align:right Example entry 6: Hi, I=E2=80=99m Bill. I'm using a region defined a= bove. 00:03:10.000 --> 00:03:20.000 region:bill align:right Example entry 7: Entries can even include timestamps. For example:<00:03:15.000>This becomes visible five seconds after the first part. ------------------------------------------------------------ Implementation details: 1. CodecID and encoding Easy enough. I propose S_WEBVTT and using UTF-8. 2. Codec private data WebVTT files consist of blocks. Blocks are separated by blank lines. Each WebVTT file starts with a block consisting solely of the line "WEBVTT". There are several blocks that can only occur before the first entry. Examples of those blocks are "STYLE" or "REGION". There are other blocks that may occur both before the first entry and before any other entry. This is mostly the comment block "NOTE". I propose to store all blocks that occur before the first entry in CodecPrivate without modifying them. This includes the "WEBVTT" file magic block. 3. NOTE blocks between entries A comment block ("NOTE =E2=80=A6") can appear between subtitle entries (see above between example entries 1 and 2). We have to decide whether or not we want to keep them when muxing into Matroska. If we do we need to store them somehow. I defer a proposal until I've mentioned the remaining points. 4. tags/numbers preceding an entry Each entry always has a timestamp line, but that line may be preceded by a line containing an entry number (example entry 3) or a free-form tag of some kind (example entry 1). Those tags/numbers are irrelevant for playback, but they may convey information to a person editing the entries. We have to decide whether or not we want to keep them when muxing into Matroska. If we do we need to store them somehow. I defer a proposal until I've mentioned the remaining points. 5. cue settings These are the things listed after the timestamps (example entries 5 and 6). They are very relevant to playback and must be included, either out of band or in band. I defer a proposal until I've mentioned the remaining points. 6. cue timestamps in entries Cue timestamps occur within an entry (example entry 7) and tell the player to process parts of the entry only at a certain point in time. Cue timestamps are absolute, unfortunately, and not relative to the start of the entry itself. The example entry 7 contains two parts, one that is shown at 3:10, and the second part that's shown five seconds later. Storing such absolute timestamps in-band makes manipulation at the container level (e.g. applying some kind of delays or splitting and joining files) very difficult. I therefore propose that a muxer MUST change cue timestamps to be relative to the start of the entry during muxing and that a demuxer MUST change the cue timestamps back to be absolute during demuxing. As several other modifications of each entry's content will be necessary (see below) this should be OK. Proposed entry storage format: As can be seen above there are several pieces of information for each entry that must be kept apart from the actual text to show. Matroska currently doesn't provide block elements for these kinds of information. The only element coming close to the purpose is CodecState. The problem with CodecState is, though, that CodecState is supposed to _replace_ CodecPrivate from the point of its occurrence in the file. Therefore it cannot really be used for storing things like "NOTE" blocks between entries or the entry tag/number lines. I also favor keeping as much information as possible. This means keeping the "NOTE" blocks between entries as well as keeping the tag/number lines. Therefore I propose to use the following storage format for entries: 1. (optional) all non-global blocks preceding an entry (the "NOTE" blocks); each block is followed by a blank line marking its end. 2. (optional) the tag/number line 3. (required) the timestamp line with start and end timestamps removed but including the cue settings; leading/trailing whitespaces are removed; the entry's start timestamp is stored as the Matroska block's start timestamp; the difference between the entry's end and start timestamps is stored as the Matroska block's duration 4. (required) the entry's content lines with all cue timestamps being shifted to be relative to the Matroska block's start timestamp A demuxer will have to re-create the entry by inserting the start/end timestamps and by shifting the embedded cue timestamps back to their absolute values. Rationale for removing the start/end timestamps and for shifting embedded cue timestamps: duplicating container-level information (start timestamp, end timestamp/duration) in-band makes any kind of container-level transformation extremely difficult. Here's how several example entries from above would be modified: ---start--------------------------------------------------------- hello --> Example entry 1: Hello world. ---end----------------------------------------------------------- ---start--------------------------------------------------------- NOTE style blocks cannot appear after the first cue. --> Example entry 2: Another entry. This one has multiple lines. ---end----------------------------------------------------------- ---start--------------------------------------------------------- 4 --> Example entry 3: Entries can be numbered (like this one)=E2=80=A6 ---end----------------------------------------------------------- ---start--------------------------------------------------------- --> region:bill align:right Example entry 7: Entries can even include timestamps. For example:<00:00:05.000>This becomes visible five seconds after the first part. ---end----------------------------------------------------------- I'm open to all kinds of suggestions. Kind regards, mosu [1] https://w3c.github.io/webvtt/ --UoPmpPX/dBe4BELn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW5pFpAAoJEHSvAK3y4yyFjh8P/RvCmj2YN3zHbfVaUbSBN6Sl 7pvOAJ9GpK1QvpkmqS3MiBRIpkLH/AZ0I8A0fXSzTpna6hwx9pl/8qtshymZAKld mE43Fb5HQ3D/T7ks+As+rW89sC7Bw2kQ6UYGO/ap8Cd7cLEuQeJQ9vWMOBHK8WHt acGvUjxZNRPBXDaKzAYG07ICQ618dW5TqJRMtoNMvS33SBFkc9/vC2rrsxrMx+LT gtbhqxCLEfliyGOnPcIz2fwSFjoV857htgWn3ADNZYMPNVryTCcYSU2U0k+uhC5V VjQJkPB4zLm1iiVf9vNN5RpIKeA0vqtlSVPfH6UCzczg5Hbn593j3JAPrtiVelTf NmflOHo0wC85JjeafCafmBunQfU46kPZAohUL5tB0WkEmMhw6rAw7k0fD8w35YkA 0QG9C3vrHZu//1oiAEZyAMBsdtnSFjIB9k5BVHlrm/AOleS+Kz/k38DiLM6ZIsdX bfahsMylIBmjAbCFHKVmrst3ATzk2R+/CDfF2E5Ev6+w8BEeojMwJ/7DZ1GDGOCg YfWe/yTwv/IeBgEB5ooyn1AiShWFgUvDzfgYCw0kRrX7P1UKWD+xgj49EqZ9Ib1M ouhO5WvI69wEalYs2oz+bhiHWfFTOjiue+hDlI1mgH6CszNbsaaIZYQvR0K2y3E2 oYOyDpu4H/fBcYXVSjjD =ebaR -----END PGP SIGNATURE----- --UoPmpPX/dBe4BELn-- From nobody Mon Mar 14 08:59:00 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7344C12D65C for ; Mon, 14 Mar 2016 08:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErIgy_tOIlJX for ; Mon, 14 Mar 2016 08:58:57 -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 ACA6C12DA88 for ; Mon, 14 Mar 2016 08:57:51 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 71F881990309; Mon, 14 Mar 2016 16:57:47 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 4DEF5198FDC6; Mon, 14 Mar 2016 16:57:28 +0100 (CET) Received: by sweet-chili.local (Postfix, from userid 1000) id AAE281D7F2D; Mon, 14 Mar 2016 16:57:27 +0100 (CET) Date: Mon, 14 Mar 2016 16:57:27 +0100 From: Moritz Bunkus To: CELLAR list , matroska-devel Message-ID: <20160314155727.GG25555@bunkus.org> References: <20160314102441.GD25555@bunkus.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GUPx2O/K0ibUojHx" Content-Disposition: inline In-Reply-To: <20160314102441.GD25555@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: Subject: Re: [Cellar] 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: Mon, 14 Mar 2016 15:58:58 -0000 --GUPx2O/K0ibUojHx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, aaaand I just noticed that the WebM guys already have a document about storing WebVTT in WebM: http://wiki.webmproject.org/webm-metadata/temporal-metadata/webvtt-in-webm I haven't reviewed it yet but using the same way to store WebVTT seems highly sensible to me :) Kind regards, mosu --GUPx2O/K0ibUojHx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW5t9nAAoJEHSvAK3y4yyFcI8P/RlcC327NwPgiGsWyUO9V24S 6JSw+T7YsBS7X/dP4O35wqCXQ8tAmzJfugRK2BSbdkoW7KPOCCJ3OFLd/29TrzvK Y/+caus1wkjDq71L/XOjlOlQcnf9tflZl/W+lSehZJ561S2pqOhdI+IAlFvvW+Sl ZvgISyjQAztnrORXdif6rxLNQeVv5uHUxAbtxzJfBhcBsLLMaZuhqcbWzuO1k7SJ WMv816N7A1uwivYb4SipCTQp6dbAhd9qVXTYln0y4lSsVtjp+VvMG6hx1uMNJSOP 6p27uy+PdvhiAl3ffrjTnyuh80TS9VG8av/WifI+iXc+TszJ8oDZYlcHHJdxs/OV okb+pTXecQUzEbbu0LJA5B0XDPiF+JlDH6+O8AjWjc4B3y6Qmcu08V+tkLCB31sh KLBa/3ZD0QmwixLI7bUbCmx+X1v9v8SV+UKZkdUdziA+PbNZK0wZiNjtv2Lx+2bK mnYYuHdTxTopTHf+uS1TwthRHoLNLclKVH8IgSen7aDh3iMJgHkpNorrRnmo3Faf zbfjYLHXDW0J3srYxnXn6/kAEk89cv18GArpFhnoPN+tdL6BIG7UjmB6st9Nix// OSiLGLXQC48bRi6g/fg3raDGp1eKjqsDlTRiwoQ1ai/O182eTPCPqk6kEhGo+yfq L0cZ5jzXjimAmocxIB63 =VALH -----END PGP SIGNATURE----- --GUPx2O/K0ibUojHx-- From nobody Mon Mar 14 11:36:03 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 CE8B412D6F7 for ; Mon, 14 Mar 2016 11:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ukw-sIAlSdGc for ; Mon, 14 Mar 2016 11:36:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E5C12D6BB for ; Mon, 14 Mar 2016 11:35:56 -0700 (PDT) Received: from [192.168.2.129] ([188.100.165.102]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Ln897-1aBiuH42Zx-00hKFA; Mon, 14 Mar 2016 19:35:49 +0100 To: Cellar@ietf.org, "Matroska-devel@lists.matroska.org" ">>" Discussion about the current and future development of Matroska From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <56E70483.8090908@gmx.de> Date: Mon, 14 Mar 2016 19:35:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:J+/oo5pWj8RI086WfaCZganjQxrDGcFCGsD8Cv9TQy3kgjCKGB9 6EpI7drmL7ZVLgGG0mlGz1w3vh6adHLfVrRSFhdRYuJ0sY6bD/BwH51BUxOK5BUA8FMgjKQ 9Nlekx18YLGFPqDns7BdpnNLW+5BNnEROp1frWrGMQJCT2RrbJFPTEcugm6usv8uev5Xb3G MtPDeo9d0G6J7/e5gu+Kg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Fs/a2+S+E6Y=:kkZY+5bxWRpTmhWPYLFL/V K/5KyW6bSeGBVJf6u6Upi50IaZJkyOVTyc04qPMmjCVgBB9aKRDqhNWyL2yZpJ/nScHerEMkA b2iAo3oOI4mw1qPaBYwN5lrEf3LEcyza3hR+BSwEhHVrdN1xSRkmH9OFoxM4T3s9/rq8ACShD d8mxRaMB45l5GtsS9+12/5uUOtA/EKiFZl/Wj+qV7cAxtIX5I9o6hD+LnjCfeUpJsU1Un1cHg Mt2iGM7hibz3M5Hq3mXdqln2I/kXZZXUPzNTrNV2l9nkuzVZxcJYc8MKnOKINJcoCxpJ54T+o +YkQ75FhdSR43W6pBkgIUGwa3pEJp+g2ZeTESmBBIG7PpaeFb9hc61Da5RU1YTe74xW1r4llf LLMjAVd5jCBYn8GXdzdFbUYzEm4Ioe3j52W+cyagjRcgWrgCs1BKAKmRql8aSlybB7TUg7j61 CAD4s9wZzH9EXUtubRHiFmr8383AovxGmSDQ4JVpSRMfXQObqutRfIedEyUrVZmufJGxMdH8S RreJHaGCUCutD3quxEhqPTwvsWXz8G2mwwz1kgZA6xiqfzB0iF8VWV2pifzaXl5y6f3b1QNCh 49tSn0OR0jFA4daKZZfjw7xsuAiiTm2AUJLyqYt4geykrY5/FDk+uNsP/CxSXmCHpUrkzwhvc A+WnDk2hhuIe7i7Irq55n6q7vfwCHpEkzUX2vXzJLF4K6Un8heUV3BMzMmd1UluWrW/Ew0Zwe WLbgDoGt3qTwRgne6LFeFNqQwZX99CgDJQ07vVtnIoK61h9cCj8MULpdT/JigNdvRqIDj/bru nu+dsx1 Archived-At: Subject: [Cellar] Storing USF 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: Mon, 14 Mar 2016 18:36:02 -0000 Hello, because the storage for WebVTT subtitles is being specified now I noticed that USF is listed in the Codec Specs [1], but the specification that goes into details [2] says "Under Construction". The Codec Specs says it is mostly defined but not typed out yet. Is this still something that has to be done? The specification of the USF subtitle format seems to be located at some private website [3]. Greetings, Sebastian [1] https://www.matroska.org/technical/specs/codecid/index.html [2] https://www.matroska.org/technical/specs/subtitles/usf.html [3] http://www.titlevision.dk/usf.htm From nobody Mon Mar 14 12:55:08 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 C41FB12D73C for ; Mon, 14 Mar 2016 12:55:05 -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 BRYDAmbj0nlJ for ; Mon, 14 Mar 2016 12:54:57 -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 1CC4912D50C for ; Mon, 14 Mar 2016 12:54:57 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 9D1D6C1FDD for ; Mon, 14 Mar 2016 19:54:56 +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 h_PjurUe1uf8 for ; Mon, 14 Mar 2016 19:54:56 +0000 (UTC) Received: from [10.252.25.129] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 88F81C1BBC for ; Mon, 14 Mar 2016 19:54:56 +0000 (UTC) Message-ID: <56E71710.2000609@xiph.org> Date: Mon, 14 Mar 2016 12:54:56 -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: <20160314081136.GC25555@bunkus.org> In-Reply-To: <20160314081136.GC25555@bunkus.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Mon, 14 Mar 2016 19:55:06 -0000 Moritz Bunkus wrote: > Hey, > > just like the EBML specs we haven't really talked about a license > yet. I'm fine with CC BY 4.0. Steve? 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). 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. From nobody Mon Mar 14 13:00: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 2B9D012D542 for ; Mon, 14 Mar 2016 13:00:01 -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, RP_MATCHES_RCVD=-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 0qkBhHirIqVk for ; Mon, 14 Mar 2016 12:59:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F02512D4FF for ; Mon, 14 Mar 2016 12:59:59 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2EJxv3v070696 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Mar 2016 14:59:58 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Timothy B. Terriberry" Date: Mon, 14 Mar 2016 14:59:57 -0500 Message-ID: <524C94C8-084B-47E4-B101-CAD701EB94C5@nostrum.com> In-Reply-To: <56E71710.2000609@xiph.org> References: <20160314081136.GC25555@bunkus.org> <56E71710.2000609@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5232) Archived-At: Cc: cellar@ietf.org 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: Mon, 14 Mar 2016 20:00:01 -0000 On 14 Mar 2016, at 14:54, Timothy B. Terriberry wrote: > Moritz Bunkus wrote: >> Hey, >> >> just like the EBML specs we haven't really talked about a license >> yet. I'm fine with CC BY 4.0. Steve? > > 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). > > 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. 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. Thanks! Ben. From nobody Mon Mar 14 14:05:06 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0AB12D611 for ; Mon, 14 Mar 2016 14:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBJT1Jsbg_vr for ; Mon, 14 Mar 2016 14:05:03 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 4815D12D5AA for ; Mon, 14 Mar 2016 14:05:03 -0700 (PDT) Received: by mail-ob0-x231.google.com with SMTP id fp4so189830846obb.2 for ; Mon, 14 Mar 2016 14:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EYibjFc9edPejh9jM0GFYF4yYK43a4TdhwshOfI/2uQ=; b=D8hYAa8FRENm03OuRPvTTgMsZZAegtanJH7B0GEUNIyy4ByYVnzQ9ToEgIyffyGNpS rtOhakTpxPupvYBfcNL4p4eTZyLzwQw9/FSUKw1+LauOLTn+MhVF7DRyJP76YznRIov9 wLH/laUOvNdwrbBZbKzpOXUH1bFTWvIHiPtCZYywKq1qxqHVJawn5tT/hNGhd2xCJRZl Hs0J9yzsSkhgH6tmlQdusOBA5JMbadF8plku7qbChA1UgXcPp//KWgekjQhBp+kHr/sa 1/8R+zo1EtWV+06fz7Bce5ozXV41wM0iJH9josx/FCN0gJRodScv8foNZ1B4PGrufPu/ rBMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EYibjFc9edPejh9jM0GFYF4yYK43a4TdhwshOfI/2uQ=; b=gYyxCHq3RWT4jBWCr1UmXHxbhczUJ6TfDl1Ao807ViUVg09Pc4AC3Hdgutwsao64UT sI4/aA8jDPNjJWGKCG+/ft9TpSAZ/M49pHF7urgTKZURllepN4s5kyWoDvCdJ8I5siHz VFQD99VrSHOHjezFahOWEk0hwrzMd0mivipxsIBHsDUOzsuuKtjwjj8CP+oBhoO5kvje 3r95DAakMbWmHJuT/zamJTm365GtVlGZS7WP85pa+cUWTfNLDVOhIVKn91iSsrNqMmKh 3lLowezj7qnyTsEJVRmHfuLV+XqGSYgk+KHsIJrqBWH7LvizymxukhhpTkELB01KL4Mb 3aow== X-Gm-Message-State: AD7BkJLJMIsoZSTYAp54DVHkPhVSE+up4B1/8seuASE8qVwUoma+m4QkUxjepdEWQ+eVT/D3uHBFTmiR7Q2lDKgw X-Received: by 10.182.16.233 with SMTP id j9mr16802218obd.9.1457989502566; Mon, 14 Mar 2016 14:05:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.23.193 with HTTP; Mon, 14 Mar 2016 14:04:43 -0700 (PDT) In-Reply-To: <20160226154219.GB19798@bunkus.org> References: <20160226154219.GB19798@bunkus.org> From: Michael Bradshaw Date: Mon, 14 Mar 2016 14:04:43 -0700 Message-ID: To: Moritz Bunkus Content-Type: multipart/alternative; boundary=001a11c30aa26345ca052e08a2fa Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Is there a way for a Block to indicate it contains a keyframe? 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, 14 Mar 2016 21:05:05 -0000 --001a11c30aa26345ca052e08a2fa Content-Type: text/plain; charset=UTF-8 On Fri, Feb 26, 2016 at 7:42 AM, Moritz Bunkus wrote: > Hey, > > a BlockGroup contains a key frame if it doesn't contain any > ReferenceBlock elements. If it contains one ReferenceBlock then it's a P > frame; with two ReferenceBlock elements it's a B frame. In that case I think the wording for ReferenceBlock should be clarified to require all timestamps of referenced blocks to be written. As it's currently worded, ReferenceBlock sounds optional for non-keyframes. I might propose the following additional wording: "A ReferenceBlock element is mandatory for every referenced block." --001a11c30aa26345ca052e08a2fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 26, 2016 at 7:42 AM, Moritz Bunkus <moritz@bunkus.org> wrote:
Hey,

a BlockGroup contains a key frame if it doesn't contain any
ReferenceBlock elements. If it contains one ReferenceBlock then it's a = P
frame; with two ReferenceBlock elements it's a B frame.

In that case I think the wording for ReferenceBlock should= be clarified to require all timestamps of referenced blocks to be written.= As it's currently worded, ReferenceBlock sounds optional for non-keyfr= ames. I might propose the following additional wording:

"A ReferenceBlock element is mandatory for every referenced bloc= k."
--001a11c30aa26345ca052e08a2fa-- From nobody Mon Mar 14 14:30:45 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 996D212D78C for ; Mon, 14 Mar 2016 14:30:36 -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 UTDujeEBylp6 for ; Mon, 14 Mar 2016 14:30:33 -0700 (PDT) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D825E12D697 for ; Mon, 14 Mar 2016 14:30:33 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 75F29C17C7 for ; Mon, 14 Mar 2016 21:30:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du3gFLABh4XU for ; Mon, 14 Mar 2016 21:30:33 +0000 (UTC) Received: from [10.252.25.129] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 619FEBFEF9 for ; Mon, 14 Mar 2016 21:30:33 +0000 (UTC) Message-ID: <56E72D79.5040208@xiph.org> Date: Mon, 14 Mar 2016 14:30:33 -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: <20160314081136.GC25555@bunkus.org> <56E71710.2000609@xiph.org> <524C94C8-084B-47E4-B101-CAD701EB94C5@nostrum.com> In-Reply-To: <524C94C8-084B-47E4-B101-CAD701EB94C5@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Mon, 14 Mar 2016 21:30:36 -0000 Ben Campbell wrote: > 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. Correct, for the collective work published as an RFC. See BCP 78 Section 5.9 . From nobody Wed Mar 16 21:46:58 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE3E12DB3A for ; Wed, 16 Mar 2016 21:46:56 -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 HXFzea6grPmH for ; Wed, 16 Mar 2016 21:46:54 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44AB12D5B5 for ; Wed, 16 Mar 2016 21:46:54 -0700 (PDT) Received: by mail-ob0-x22a.google.com with SMTP id fp4so72581842obb.2 for ; Wed, 16 Mar 2016 21:46:54 -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=g75PidKpgzIIcOJtAuIQQTHaGiDburRS8wmlcEPi9FA=; b=dkXutbq1+cG8x6K2u7N8dQzxtt/S9ciXmkAt7UdmoV4ImAMLpjIcBlLhWdqKJaB42n L0wtD5Rg/nJUNLOmY1+KsDV95ygEZBwJ9IhzaAdJTd1ip7v9mXIMSrmFRLFOk4tjFVGd 4czGTbo+ryrjvrqLV7DxKvDAdC8efqYz+8RP6GsmfTUEt1QUiTV53LeDBCL2HzwEuw0w FbSiqTC9zZ/UpxjRz8MA3J2OYAETsb4d+MbfA84199TGBrFN+y3k9s8X74VicXM4F70j jgc7pkJLJQ9+XX8isZ9OUAlwwK3CTeWgfH8VfwuZ+9wDSXg8GhsqU1Ao0kEdxucpC7+y 69aA== 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=g75PidKpgzIIcOJtAuIQQTHaGiDburRS8wmlcEPi9FA=; b=a5QaMNBNa/0JCHOUQ0zbZNLyl+Nu7iD8aoxbJIzzg8X10Wx+XT2k2Kmt5VuWJgBOZN p1M9J4OZN6QHM/VmzYaIyhD4H4K3iWWajQ/fH1fnWHyWdDGbwOixz0oloBjJE1nCx43J lX4Cb1cfhEshe01tRoqhsFru2cJVGkLSkYmu/MYaJ44xd4/QgkZprBHflwH2245mUAl4 4GoynfIfkcfJCcwUZQg+YziiaM2NatOd8QbtBK05Kf/jVrNcYSzSbC0n5E6va17csl/C i2DCSUAAzxD7pMPpUG+fMlkileMUS23taAOe7c0c4K7EL1xF+sLho0SKDL/kHuRur9Ii N8nQ== X-Gm-Message-State: AD7BkJKm1pk9LFLp9rIKv0NmvzZ+sxLd9ZyusCcgxIRA/q0yoFyeM/oFxc0ZnugujCQZV4ZD9AE6N2NqZkuKTA== MIME-Version: 1.0 X-Received: by 10.60.70.1 with SMTP id i1mr4968343oeu.13.1458190014067; Wed, 16 Mar 2016 21:46:54 -0700 (PDT) Received: by 10.202.87.202 with HTTP; Wed, 16 Mar 2016 21:46:53 -0700 (PDT) In-Reply-To: <20160219214538.GL4557@nb4> References: <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> <9CE0170E-E63D-411D-AFAF-EE5CBB4B56D7@dericed.com> <20160219214538.GL4557@nb4> Date: Wed, 16 Mar 2016 21:46:53 -0700 Message-ID: From: Frank Galligan To: Michael Niedermayer Content-Type: multipart/alternative; boundary=001a11334770cdbeb2052e3751e8 Archived-At: Cc: Jerome Martinez , Dave Rice , cellar@ietf.org, Discussion about the current and future development of Matroska 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: Thu, 17 Mar 2016 04:46:57 -0000 --001a11334770cdbeb2052e3751e8 Content-Type: text/plain; charset=UTF-8 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? I think we should probably strive to support 99% of what is currently produced today. Opinions? Next what are we missing and what do you think we need to add to support the formats? Would adding interlaced and horizontal flip elements be enough to support the 4:2:0 that people are using today? > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No snowflake in an avalanche ever feels responsible. -- Voltaire > --001a11334770cdbeb2052e3751e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK really no comments for a long time.=C2=A0

On Fri, Feb 19, 2016 at 1:4= 5 PM, Michael Niedermayer <michael@niedermayer.cc> wrot= e:
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:=C2=A0 =C2=A0 =C2=A0 =C2=A0 4
>
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B0]
>
> Mandatory:=C2=A0 =C2=A0 -
>
> Multiple:=C2=A0 =C2=A0 =C2=A0-
>
> Default:=C2=A0 =C2=A0 =C2=A0 -
>
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m
>
> Description:=C2=A0 Settings describing the colour format.
>
>
> Element Name: MatrixCoefficients
>
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B1]
>
> Mandatory:=C2=A0 =C2=A0 -
>
> Multiple:=C2=A0 =C2=A0 =C2=A0-
>
> Default:=C2=A0 =C2=A0 =C2=A0 2
>
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>
> Description:=C2=A0 The Matrix Coefficients of the video used to derive= luma and
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 chroma values from reg= , green, and blue color primaries. For
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clarity, the value and= meanings for MatrixCoefficients are
> adopted
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from Table 4 of ISO/IE= C 23001-8:2013/DCOR1. (0:GBR, 1: BT709,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2: Unspecified, 3: Res= erved, 4: FCC, 5: BT470BG, 6: SMPTE 170M,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7: SMPTE 240M, 8: YCOC= G, 9: BT2020 Non-constant Luminance,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10: BT2020 Constant Lu= minance)
>
>

> Element Name: BitsPerChannel
>
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B2]
>
> Mandatory:=C2=A0 =C2=A0 -
>
> Multiple:=C2=A0 =C2=A0 =C2=A0-
>
> Default:=C2=A0 =C2=A0 =C2=A0 0
>
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>
> Description:=C2=A0 Number of decoded bits per channel. A value of 0 in= dicates
> that
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the BitsPerChannel is = unspecified.
>

what would this be set to for old 16bit rgb, that is 5 bit red<= br> 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 mayb= e it was DirectDraw) that had R,G,B, and A masks to show which bits belonge= d to which channel. I also worked with formats like RGBBGR repeating.=C2=A0=


[...]

> Element Name: CbSubsamplingHorz
>
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B5]
>
> Mandatory:=C2=A0 =C2=A0 -
>
> Multiple:=C2=A0 =C2=A0 =C2=A0-
>
> Default:=C2=A0 =C2=A0 =C2=A0 -
>
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>
> Description:=C2=A0 The amount of pixels to remove in the Cb channel fo= r every
> pixel
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not removed horizontal= ly. This is additive with
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ChromaSubsamplingHorz.= Example: For video with 4:2:1 chroma
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 subsampling, the Chrom= aSubsamplingHorz should be set to 1 and
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CbSubsamplingHorz shou= ld be set to 1.
>
>
> Element Name: CbSubsamplingVert
>
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B6]
>
> Mandatory:=C2=A0 =C2=A0 -
>
> Multiple:=C2=A0 =C2=A0 =C2=A0-
>
> Default:=C2=A0 =C2=A0 =C2=A0 -
>
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>
> Description:=C2=A0 The amount of pixels to remove in the Cb channel fo= r every
> pixel
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not removed vertically= . This is additive with
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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 CbSubs= ampling* elements at first. I only added that to support the 4:2:1 format t= hat was defined in the first enum.


>
>
> Element Name: ChromaSitingHorz
>
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B7]
>
> Mandatory:=C2=A0 =C2=A0 -
>
> Multiple:=C2=A0 =C2=A0 =C2=A0-
>
> Default:=C2=A0 =C2=A0 =C2=A0 0
>
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>
> Description:=C2=A0 How Chroma is subsampled horizontally. (0: Unspecif= ied, 1:
> Left
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collocated , 2: Half)<= br> >
> Element Name: ChromaSitingVert
>
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B8]
>
> Mandatory:=C2=A0 =C2=A0 -
>
> Multiple:=C2=A0 =C2=A0 =C2=A0-
>
> Default:=C2=A0 =C2=A0 =C2=A0 0
>
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>
> Description:=C2=A0 How Chroma is subsampled vertically. (0: Unspecifie= d, 1: Top
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collocated , 2: Half)<= br> >

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 als= o didn't get into interlaced.


<= br>
I don't think we should add enough elements to support ev= ery format that was ever produced. Opinions?


<= /div>

I think we should probably strive to support 99% o= f what is currently produced today. Opinions?


=
Next what are we missing and what do you think we need to add to= support the formats?


Would adding = interlaced and horizontal flip elements be enough to support the 4:2:0 that= people are using today?

[...]

--
Michael=C2=A0 =C2=A0 =C2=A0GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC= 787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire

--001a11334770cdbeb2052e3751e8-- From nobody Thu Mar 17 19:45: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 783A212D913 for ; Thu, 17 Mar 2016 19:45: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 E4eWtb1HAeXX for ; Thu, 17 Mar 2016 19:45:47 -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 33BB412D58E for ; Thu, 17 Mar 2016 19:45:47 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:33519 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 1agkQ5-000mmV-3P; Thu, 17 Mar 2016 22:45:48 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Thu, 17 Mar 2016 22:45:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> References: To: cellar@ietf.org X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-0.2 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: Steve Lhomme , Ashley Blewer 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: Fri, 18 Mar 2016 02:45:49 -0000 Hi all, To test this out, I submitted a Pull Request to Ashley=E2=80=99s = mkv_jekyll_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 directly 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 and = 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 -- outdated). >=20 > 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 document = 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 =20 > =20 > 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/mas= ter/specification.markdown). For an understanding of Matroska's EBML = Schema, see in particular the sections of the EBML Specification = covering [EBML Element = Types](https://github.com/Matroska-Org/ebml-specification/blob/master/spec= ification.markdown#ebml-element-types), [EBML = Schema](https://github.com/Matroska-Org/ebml-specification/blob/master/spe= cification.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_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: >=20 > 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 will = be >> ready for future collaboration with version-control built in. >>=20 >> Steve, do you think the Jekyll site should mimic/replicate 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 Matroska.org or = if, >> since it's for spec viewing and work in particular, it's fine to = appear >> differently. >=20 > The design doesn't matter too much. As long as it's easy to read and = navigate. >=20 >> Thanks much! >>=20 >> Ashley >>=20 >> On Sun, Mar 13, 2016 at 6:24 AM, Steve Lhomme = wrote: >>>=20 >>> 2016-03-06 22:39 GMT+01:00 Ashley Blewer : >>>> Hey all! >>>>=20 >>>> 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. >>>>=20 >>>> I'd like to propose we migrate the Matroska specification to = Github. As >>>> I >>>> mentioned before, I'm happy to carry this transition to completion = 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. >>>>=20 >>>> 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 can = be >>>> made >>>> to look like the Matroska site. >>>>=20 >>>> 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. >>>>=20 >>>> Also, tables can be difficult to read and create in Markdown. = However, >>>> the >>>> primary table located on the specification page is rendered via XML = and >>>> would not have to be rewritten in Markdown (although this example = does >>>> have >>>> it written in Markdown). >>>>=20 >>>> Option 2: Standard HTML website. >>>> Option 2 repo: https://github.com/ablwr/mkv_pages_poc >>>> This has been translated to replicate the Matroska site. >>>>=20 >>>> Like I said above, previewing work doesn't require running a local >>>> server. >>>> But work is harder to read because it's in HTML and most changes = will be >>>> very text-based anyway. >>>>=20 >>>> 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 after >>>> decisions >>>> are made here on CELLAR. >>>=20 >>> I never heard of Jekyll before but it seems interesting. That would = 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 find >>> 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 the >>> opposite is more work and not trivial. >>>=20 >>>> My best, >>>>=20 >>>> Ashley Blewer >>>>=20 >>>> _______________________________________________ >>>> Cellar mailing list >>>> Cellar@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cellar >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> Steve Lhomme >>> Matroska association Chairman >>=20 >>=20 >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Sun Mar 20 02:26:07 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2075612D739 for ; Sun, 20 Mar 2016 02:26:06 -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 3Dt93_Y4czzT for ; Sun, 20 Mar 2016 02:26:04 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 4ECFB12D736 for ; Sun, 20 Mar 2016 02:26:04 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id h129so185939454ywb.1 for ; Sun, 20 Mar 2016 02:26:04 -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:content-transfer-encoding; bh=ume7nNCgTGJGxOwYIYrG9NxIxtT3filpZBtHe6oJyEw=; b=O0bfqXIeMFE7gnt+qvdNzIHMDttVR/fLke8VYyZ116YHxGKeaHJCdz32FvVV9nWiBu KaNXILYIi3ulq6Dn46bpPdPYRMKE/8McJ0NURt3xC1Rjl7uBuV0g5EzcbWjT9v+FFJKs TGvfuKqbzCbvHX6CoI8lAAiMQvXdHWoYD6LbFTBjlrbQJFWXZHCIp9Ke4J/95uos8dDM Evmw/NgUI1mtsIkuBHKD5LUuELkS+ZYGik9s80XQZXL/OcAgFeFvzSw2xPqrHDOlpoqK GJ0Mbk6qn1y4ZkYjKu6Uww6cdb0+kKMWf77u6Q3dAvyeFnWcUJ/nk4LERmQ4NaS0zUKs +mfg== 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:content-transfer-encoding; bh=ume7nNCgTGJGxOwYIYrG9NxIxtT3filpZBtHe6oJyEw=; b=maZOCyEUkv9VCZltNAxw5OvjCpJ0qEyXuhIuOeWbHerky6ccnAGk5yuBg97dQHGhwS OLQrLvxqAn5uaX54A/TvueftAUUfU1sfh0kaVMZ38I8xv7py2hmq4dC42FJxqTvbb6eS pTCi1BInDG2BpQP4aKmdL1UE824yfwUEXysLc8eGK3rRCivKe3VYntVhLpoh9C5nsKLZ zdN/lo3F0s0TcfkahWwFc3w5tZWPtCL1SC87gs5GGY01iFb5l8z0KRIAq7zvDhrqJ1I1 qC0zk4xH7JM1sQwmq/aDqHT+EGzUwU8+3EMKU910gSp/kwxIcJhwvqMIFRHzZ2HaOLPy Jk8g== X-Gm-Message-State: AD7BkJLuMkRqw4bArki17WbAPXoXyIAharbUvvtoZeb1jsM/pT0+jrgrVFRmJSMwm95bIZ3EOmNb4g2W6XeEoA== MIME-Version: 1.0 X-Received: by 10.13.255.4 with SMTP id p4mr10699805ywf.54.1458465963376; Sun, 20 Mar 2016 02:26:03 -0700 (PDT) Received: by 10.83.28.196 with HTTP; Sun, 20 Mar 2016 02:26:03 -0700 (PDT) In-Reply-To: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> Date: Sun, 20 Mar 2016 10:26:03 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Matroska Attachments 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, 20 Mar 2016 09:26:06 -0000 2016-03-13 15:44 GMT+01:00 Dave Rice : > Dear CELLAR, > > From a review of the Attachments section a few more questions and comment= s before I send a patch. > > What is the status of FileReferral, FileUsedStartTime, and FileUsedEndTim= e. These seem to be part of a Matroska extension for divX. Should these Ele= ments be included in our work? Are these deprecated? > > FileUID is defined as "Unique ID representing the file, as random as poss= ible." (actually many UID Elements use this language about randomness). Doe= s this mean that a Unique ID field could be any length from 1 to 8 octets? = Or are Unique IDs presumed to be a specific length? It doesn't specify any length, but the bigger the more random. The binary approach of FileReferral allows longer lengths so we may keep it. But it's not good to have 2 systems in place. I'd rather turn FileUID into a binary element (as well as TagAttachmentUID and AttachmentLink). It's doable as all existing values would still be interpreted the same. As for the format, different systems may want to use different things like MD5, SHA-1 or some random number. Not sure if we should force one of them. > Most of the specific narrative about attachments appears to be here: http= s://www.matroska.org/technical/cover_art/index.html. It lists some reserved= attachment file names like cover, cover_land, small_cover. Are there more = reserved names like this? I think this document should be expanded to cover= other use cases for attachments to include both access and preservation ex= amples, but what should they be: > - cover, poster images > - fonts to support subtitles > - logs or additional metadata > - archived copy of a decoder? > > I'd be interested to here in other innovative ways to use attachments. A matroska file with just attachments for storage. But I don't think it has any advantage over TAR or RAR. > Also the cover image examples seem to use specs that are aged. A cover im= age is recommended to be 600 pixels tall/wide, but should this values be in= creased as user expectations of image quality increase? As recommandations, yes. > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Mar 20 02:32:25 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762DA12D595 for ; Sun, 20 Mar 2016 02:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CSynDUuuKxKM for ; Sun, 20 Mar 2016 02:32:22 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 B66DD12D52D for ; Sun, 20 Mar 2016 02:32:22 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id h129so186011477ywb.1 for ; Sun, 20 Mar 2016 02:32:22 -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:content-transfer-encoding; bh=+95lptDYxXLcJhY96lDgyyzfYXPiM7bsImrjRWfk7Vw=; b=WWMFGOcZa27GmpuzH6ZpWkG5dVVaUk4eUymN/tQzIGT1WESZLR7IUdFD+fSx1pe2Hj ZnxmweGlW18nrw8txfRhiAyt9yODc98Gap8pcylK9ozaCwvl7nxopozVq0vU/j0o1yuC YIHEaVODPKlqEv6Mt0u7gpMq/1ZVOaxlSLwtbxXZ/FhaP3rrc4Ua/t6B91uVXB4RYP9t Nc5N5TjMid7kSAotydwhmKUEkdqM0v9RWr9VZIT7RIRckA+1fA4k9xrIRnDDpjF0ztLQ Tw3x4yz4OkCcSMmoZT2+QdbYTloaeZO4HiwZWQ284NmBZ751aUGMOIa6LdzVpaU3SBWd TteQ== 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:content-transfer-encoding; bh=+95lptDYxXLcJhY96lDgyyzfYXPiM7bsImrjRWfk7Vw=; b=IcCpZRuZOW6SMo99635hh/RcJqpxvqpckY+pbYzXZK02a9+rx7UX8gGE/BFGTNeEzM 4FfJ89sK73R3IUTYKXrWId4kIfmqT5IXdFVJkUHDt6FcaFg+QTMGROWfS1Uc6WDtaIg7 MV8xouuxgvkCO46/hP14PnBzyAOeE4qeMeoSInuG6CIOpfBAudhdnO6wEqNCKUbjjono 4zyqvUMsNUDtIpBWQzkQHDffIzMqMm2t9YI3NMllhNzpKZofaC/HcO7DMQoZy1rmeg8H qpyuJQdEzg9j6p8Di9xe/d8b8Z8ZNLwdpq6HDZxA89FgTveHxyNh1rn51U2j61F6WgaS FCuQ== X-Gm-Message-State: AD7BkJK2IUURmdEnPKUXpAfKYubReWtZRqv0Xfc/XQzrmDpdldaB/8H86mzVoBEPgoiyVaklGOdQ77nQfVjrbA== MIME-Version: 1.0 X-Received: by 10.13.199.68 with SMTP id j65mr10647269ywd.289.1458466341974; Sun, 20 Mar 2016 02:32:21 -0700 (PDT) Received: by 10.83.28.196 with HTTP; Sun, 20 Mar 2016 02:32:21 -0700 (PDT) In-Reply-To: <588EFF1A-54FE-4356-AB63-F632122D8926@dericed.com> References: <588EFF1A-54FE-4356-AB63-F632122D8926@dericed.com> Date: Sun, 20 Mar 2016 10:32:21 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] human readable EBML Element definitions 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, 20 Mar 2016 09:32:24 -0000 2016-03-13 18:28 GMT+01:00 Dave Rice : > Hi all, > I=E2=80=99m looking for advice on how to present EBML Elements in a human= readable form. > > The current structure in the EBML Specification is a bit messy and hard t= o read: https://github.com/Matroska-Org/ebml-specification/blob/master/spec= ification.markdown#ebml-header-elements > > I just tried to update this to tables with one table per Element definiti= on: https://github.com/MediaArea/ebml-specification/blob/update-EBML-elemen= ts-to-new-definition-style/specification.markdown#ebml-header-elements It would look better if each table had the same (full) width. > But there=E2=80=99s also the current form of the matroska.org presentatio= n of the Elements at https://matroska.org/technical/specs/index.html#LevelE= BML. > > Any advice or comments or suggestions on what works? It depends on the target document. For a document with precise description of each element, the more room there is for text, the better. So your table per element is probably better. For a document to look quickly for element values and semantic attributes (ID, type, mandatory, multiple, default) one line per element is better. > Best Regards, > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Mar 20 02:43:47 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29D012D73C for ; Sun, 20 Mar 2016 02:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tY4NynchIFr for ; Sun, 20 Mar 2016 02:43:45 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 281F912D528 for ; Sun, 20 Mar 2016 02:43:45 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id g3so186233007ywa.3 for ; Sun, 20 Mar 2016 02:43:45 -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=3JU9qzb4qUjLCRTrsI6p+zYQ3TAQ1MexgDRuzr4rqx8=; b=FUss25NXJDH+juRtrA8il4VGp0vUijKmGNCA45X6rnxAwS6WIpTxOcI05IE4pu7fsi 0V7bcHUfRgwGypAJr8G9tGAPf9yXjAARUHED0wLhefMWmT5qie8XTyLj6D/bF1u2Jffw FQAgBCuQRBDOuEpESq8HXS+HLH9m5FkqhyrTFmBB41njH6+8AGGQG7jZKZ6B+flfP7CG nZi7ONJP0uNzw6ZLK91gzfJZjJrec+1r8JISbErwHwZaXOh4CaM2G2TTsENRdiqs8Y66 UxOCZVUJXXIJJMDz1chidXrd2YPD96fqjNszB+fA9wAbH2PZget8PGS9JxaREFlcQECL XULA== 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=3JU9qzb4qUjLCRTrsI6p+zYQ3TAQ1MexgDRuzr4rqx8=; b=g7CaeD6RdElWOw4P4Uo78NafXJlhKauxpf+PaW7d5XcHlj5r/vt+GwpzMECo0lQZWj 5UBWYBnRbvTdD18ia+1IT6FJ+WZep8gFquNpbx4pXO1dFoqv8m0xdA5u2oArTNsSLwwM nwUVCXjBzTyUu3GmLZaARRc1aFp7afreBzAD8ndi7/c8WFuoCXKtyAyiaDGJYkw5PL9Y uA9QL0aod41EKa2axR30PUI0kuR/Z/8LBlHORwteaUkVN/egp6Tx2hHdtFNULHMqgQDT yEcQoizSF4J/yO9fNBOyRuuorEnpm3n6UtjRnczM+vFuBRrkmgo8O5kNOuV4EG/eHHeu MZyQ== X-Gm-Message-State: AD7BkJKx/CKftXoKxe0UPgjW8JzkMIZ7EbkVFpeQuzMpNEvB7kQAr7fh28Vy21d+F3929OfEyND0HXhicZhdFQ== MIME-Version: 1.0 X-Received: by 10.129.55.134 with SMTP id e128mr12294975ywa.277.1458467024397; Sun, 20 Mar 2016 02:43:44 -0700 (PDT) Received: by 10.83.28.196 with HTTP; Sun, 20 Mar 2016 02:43:44 -0700 (PDT) In-Reply-To: <524C94C8-084B-47E4-B101-CAD701EB94C5@nostrum.com> References: <20160314081136.GC25555@bunkus.org> <56E71710.2000609@xiph.org> <524C94C8-084B-47E4-B101-CAD701EB94C5@nostrum.com> Date: Sun, 20 Mar 2016 10:43:44 +0100 Message-ID: From: Steve Lhomme To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 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: Sun, 20 Mar 2016 09:43:47 -0000 2016-03-14 20:59 GMT+01:00 Ben Campbell : > On 14 Mar 2016, at 14:54, Timothy B. Terriberry wrote: > >> Moritz Bunkus wrote: >>> >>> Hey, >>> >>> just like the EBML specs we haven't really talked about a license >>> yet. I'm fine with CC BY 4.0. Steve? >> >> >> 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). >> >> 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. > > > 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. Fine with me for the IETF document. The one on matroska.org should be like the EBML one, CC BY 4.0. > Thanks! > > Ben. > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sun Mar 20 11:17:55 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4073C12D5BA for ; Sun, 20 Mar 2016 11:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqvyTyAoLrEK for ; Sun, 20 Mar 2016 11:17:52 -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 4ADE312D52C for ; Sun, 20 Mar 2016 11:17:51 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 68C9C1B94232; Sun, 20 Mar 2016 19:17:48 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 3A6F31B94222; Sun, 20 Mar 2016 19:17:43 +0100 (CET) Received: by sweet-chili.local (Postfix, from userid 1000) id 9207144EFDC; Sun, 20 Mar 2016 19:17:42 +0100 (CET) Date: Sun, 20 Mar 2016 19:17:42 +0100 From: Moritz Bunkus To: Discussion about the current and future development of Matroska , CELLAR list Message-ID: <20160320181742.GW25937@bunkus.org> References: <20160314102441.GD25555@bunkus.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FmwJltL8yKUx7YXQ" 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] [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: Sun, 20 Mar 2016 18:17:54 -0000 --FmwJltL8yKUx7YXQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, thanks for your input, Denis. I've looked over the document from the WebM project[1] thinking about WebVTT inclusion. Unfortunately it's rather old (from 2012), and its text leads me to believe that WebVTT has changed considerable since then. For one the WebM proposal states that no CodecPrivate content will be used; however, several global blocks in WebVTT are not covered at all. Additionally the WebM project proposes splitting the WebVTT content into two tracks, one for the styling, one for the content. I don't like this approach at all as we currently don't have any method of linking two tracks in a way that clearly indicates that those tracks must be kept and used together. I therefore don't think we can use the WebM proposal. That being said the WebM proposal contains similar thoughts to mine about keeping the entry tags and the timecode line Additionally using the BlockAdditions is a good idea; thanks, Denis. I'm incorporating it. Denis had an objection: > That's basically useless... I'd remove it too, the less useless stuff > the decoder/muxer has to handle, the better. My goal is still to keep as much information from the WebVTT file as possible without compromising Matroska's general ideas (and hopefully without jumping through hoops). I aspire to the same for other source container formats, not just for WebVTT. The reason is that Matroska is not solely used for storing content for later playback but also as an intermediate format. And keeping as much information as possible makes it a lot easier to edit the content later. Another objection/question: > >6. cue timestamps in entries > Wouldn't it be easier to just create another block starting with the > new timestamp and ending with containing block end? Maybe. My problem is that I don't fully understand where they're trying to go with allowing cue timestamps within the content in the first place. Would something like this be valid? ------------------------------------------------------------ 00:02:00.000 --> 00:02:10.000 No fair!<00:02:01.500>You changed the outcome by measuring it! ------------------------------------------------------------ I guess yes, and splitting this up into two entries would require duplicating at leas the tag like. Additionally the muxer would= have to calculate where exactly the text after the embedded cue time stamp would have to appear. It quickly gets pretty complicated for a muxer. Therefore (and for keeping the original structure as intact as possible) I'm against splitting entries on embedded cue timestamps. Here's my updated storage format proposal: ------------------------------------------------------------ (A) CodecID: S_WEBVTT (B) CodecPrivate: This element contains all global blocks before the first subtitle entry. The =C2=BBWEBVTT=C2=AB file identification marker= is NOT part of CodecPrivate. (C) Non-global blocks (e.g. =C2=BBNOTE=C2=AB) before an entry are stored in Matroska's BlockAddition element together with the entry they precede (D) Each entry consists of three or more lines: 1. The first line contains the entry's cue identifier if present in the source file followed by a WebVTT line terminator. If no cue identifier was used then only the WebVTT line terminator is used. 2. The second line contains the entry's timestamp line with the actual timestamps removed followed by cue settings if present followed by a WebVTT line terminator. The start timestamp is used as the block's start timestamp, and the difference between the block's end and start timestamps are used as the block's duration. 3. All following lines are the content lines from the entry. If the content lines contain cue timestamps then those timestamps MUST be adjusted to be relative to the entry's start timestamp (and a demuxer has to reverse this process again). ------------------------------------------------------------ Here's an example how an entry could be converted. If a WebVTT file looks like this: ---start--------------------------------------------------------- WEBVTT example entry 1 00:03:10.000 --> 00:03:20.000 region:bill align:right Entries can even include timestamps. For example: <00:03:15.000>This becomes visible five seconds after the first part. NOTE This is a comment block. 00:05:22.000 --> 00:05:28.700 Another entry, this one with neither a cue identifier nor cue settings. ---end----------------------------------------------------------- then the converted first entry would look line this: ---start--------------------------------------------------------- example entry 1 --> region:bill align:right Entries can even include timestamps. For example: <00:00:05.000>This becomes visible five seconds after the first part. ---end----------------------------------------------------------- The second Matroska block will contain a BlockAddition element: ---start--------------------------------------------------------- NOTE This is a comment block. ---end----------------------------------------------------------- and the actual block: ---start--------------------------------------------------------- --> Another entry, this one with neither a cue identifier nor cue settings. ---end----------------------------------------------------------- Kind regards, mosu [1] http://wiki.webmproject.org/webm-metadata/temporal-metadata/webvtt-in-= webm --FmwJltL8yKUx7YXQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW7ulAAAoJEHSvAK3y4yyF/f8P/1XTpScD8yL2VeCANHb9aFq9 FeP5VOdKrmKiISj+w+DavtOSt84hIlRy9725EuzY+Ne67uY37ev/eCJT06WNPbC6 7ltJo8HZpEAX0ZOwh3PeDaAt+D+IfY29H8e5s/BHX7aY0XtRUj5d4yLHml6JLSIk 3z4yYx4c3+atqzrpDNJ76kL2IQGC/HKRAlJoRao8sVSt9wv6sqTUBcxi1zOqq2BK NoLtKIKtICjpmx8+x0oSY3QjKW/ZXOCGYogV3/NfGhI00vToz/dZwB9dxt5wbPa5 1LMVA4jhyqrWbFUXjh5g/Y3rsRFtiDyB3M0FTFydJvkZy597Ns/ccuaW7WwYxQTN sJnTSRiWdn4LyXoRO7lURaO44RSPWw17URhscB/sWdMtNBUKgjU6bf+nDLJk7bCm GGxrCrxDCeoDzKzICr+VPDCB57YQqbbmeLgy5ogZ13ysBnjBqySNiIA5zryq7kl7 ui1RvyIYnuIBjBfzI5wHc5AU22kXmBvRZOFYQw2w3uKDhRxrw3t19nkZuOJeWkQ/ xLmS6XtZnOGPTFA4BRzuTSkX+fAJePyIFgkSPKpI0ddjztPf6vU/ljFaMHpHmNTz 1q1aFQCWIG0fLorrU+dLvNXbXpnlDqcBc6xb1jKNxuiyhkoelwZJN1OcT5urfNsX Mfi8Iq46a2/KD8oOHI8d =rWq2 -----END PGP SIGNATURE----- --FmwJltL8yKUx7YXQ-- From nobody Sun Mar 20 11:32:55 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E22412D510 for ; Sun, 20 Mar 2016 11:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm6CDwcAooO6 for ; Sun, 20 Mar 2016 11:32:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5CB12D50D for ; Sun, 20 Mar 2016 11:32:50 -0700 (PDT) Received: from [192.168.2.129] ([146.60.194.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lcjgd-1ZyAKu3tep-00k7w7 for ; Sun, 20 Mar 2016 19:32:48 +0100 To: cellar@ietf.org References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <56EEECD1.1020109@gmx.de> Date: Sun, 20 Mar 2016 19:32:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:3PhyrfGXt2YWUwvEE8cmcjMDAb7CWSPqwP4jNd5UV9g49vsX6ES CIjHG/5sastlyyg9bDMfpnylOXMtk8XauEQImHRS49IuXrG6fahbX3LUd9tqhoaB8abvJTP IIRySGJy1gUV4IpItPGtrMrN8Ya9xv1UgXkCqaXlHdK1Isj9MzQIx6ZWpf1YP9g7mHkYYaR EwVnGiyvCKE/ANY91zKYQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:PdEvcjXkM6Q=:6R88jFuI7Dsm8W8oKaRxi2 JLDq0d8OOC/LSBNdsh/Xi7g7a0xmau0e+p/lecHKyOdS3MiXvyBNQvzRYPDT/2ZMnuKmmKRY9 3SwxeUHNMSyt14DUGkdNB55htw1kd8pht/DVVcfjDg8OJh13EJHeyIMj2wA+67TOyKUB5j7K3 vR1y20PxgqdPL3tqSZGQAN+6bg9i1ntgNn4Ruie97f3QasbAJ3W2uSJlPZmPnk/e9Iq+TuzBW BsKgdkn0F58A8qy2g9o9EZy+eOtOtlhGxvT3vCpetoj7YCcyJa6P4+8RdGPUk15JijUb2iqoA QmgRMXiQzAcz1TV1lzKJHPlTzLux5Uhi31g4ESq5HaplY8okdXZNPCzOqeqM2vPn+DQpwN/N9 D+kjl8e11B+kHjNlfVlsZb/cjMpsqglc7mXP/96RolXsAIJNLV2cBTLsx04ZsTaveTRBjMN1Q 7hYl1pdxmeIoPaRgr9nTOEeIywUEcgjwMSoy76ZsA4bw1YoePp8vnrB51RXqtdcYgNkEUAuPS hKuzEa24xput90+W3J91w0Z8tuGgpS3Z6WDrzVHm2VlpqlsuBIdWxmpmlHA20HrlT6CSso4dx MR+fbiLF2En8aIIyIiiGAn2RnDbpAWhjt0DUOkL2KwGQY2eE3yGzsN6jcs3I1KK7Dr7a5xm5F HiufvxKf9kAYmISK97iEtAdv0flMi2NghnS6AN1RYDXKquVh2FK950QDv8TpXiIPFnOvfHThP OZMUdkv90j3LlMQlKHP8m3LEvk/UQFTr2NvTO0pPFwIHjgeWPGcCLzjOJ/73ToPkXq+9iwnoZ psMyrVO Archived-At: Subject: Re: [Cellar] Matroska Attachments 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, 20 Mar 2016 18:32:52 -0000 20.03.2016, 10:26 Steve Lhomme: > 2016-03-13 15:44 GMT+01:00 Dave Rice : >> Dear CELLAR, >> >> From a review of the Attachments section a few more questions and comments before I send a patch. >> >> What is the status of FileReferral, FileUsedStartTime, and FileUsedEndTime. These seem to be part of a Matroska extension for divX. Should these Elements be included in our work? Are these deprecated? >> >> FileUID is defined as "Unique ID representing the file, as random as possible." (actually many UID Elements use this language about randomness). Does this mean that a Unique ID field could be any length from 1 to 8 octets? Or are Unique IDs presumed to be a specific length? > > It doesn't specify any length, but the bigger the more random. The > binary approach of FileReferral allows longer lengths so we may keep > it. But it's not good to have 2 systems in place. I'd rather turn > FileUID into a binary element (as well as TagAttachmentUID and > AttachmentLink). It's doable as all existing values would still be > interpreted the same. > > As for the format, different systems may want to use different things > like MD5, SHA-1 or some random number. Not sure if we should force one > of them. > >> Most of the specific narrative about attachments appears to be here: https://www.matroska.org/technical/cover_art/index.html. It lists some reserved attachment file names like cover, cover_land, small_cover. Are there more reserved names like this? I think this document should be expanded to cover other use cases for attachments to include both access and preservation examples, but what should they be: >> - cover, poster images >> - fonts to support subtitles >> - logs or additional metadata >> - archived copy of a decoder? >> >> I'd be interested to here in other innovative ways to use attachments. - Preview images for media catalogs that don't contain any codecs. - Text-basted information about the content, plot, cast or whatever. (media libraries could use them) - Error recovery files e.g. using hamming codes. (for tools that try to recover errors, not for players) - Specifications of Matroska, the audio codecs, video codecs, the subtitles (for very long-term storage) - Public-key (DRM is possible, but also authenticating against a server to get updates on the content you watch [or are about to watch], like a documentary you purchased.) - Picture or text-based annotations. > A matroska file with just attachments for storage. But I don't think > it has any advantage over TAR or RAR. It certainly has the advantage that attachments can't be lost. Attachments can't be edited (directly), which has both advantages and disadvantages. So unless someone touches the matroska file it contains all the attachments that are the way the creator intended them to be. With an archive you can extract all files, then delete some or extract the archive just partly. Like having a font that is supposed to be used with one of the subtitles that has been muxed into the file. Having more ways to interact with attachments in Matroska seems like a good thing to me. Safely handling the attachments is up to the application anyway. Should anyone be concerned about security attachments could be ignored. I'd like to see Matroska used more often than it is right now. AVI was good enough back in the good old days, currently MP4 seems to offer enough that it is used very very often. If Matroska has more advantages over other containers it should see more usage, at least in theory. >> Also the cover image examples seem to use specs that are aged. A cover image is recommended to be 600 pixels tall/wide, but should this values be increased as user expectations of image quality increase? > > As recommandations, yes. > How would "values be increased as user expectations of image quality increase" be specified? It is possible to recommend a minimum resolution. To me it seems like a good idea to do so. It is possible to recommend a maximum resolution, but here I would let it open as the limit might not be adequate. Currently it can't be expected that a 4K image will be displayed by everything that supports cover images right now, but at some point in might be the case. You might could say "image quality should reflect state-of-the-art standards, while also considering legacy systems." Best regards, Sebastian From nobody Sun Mar 20 11:38:57 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAA112D50D for ; Sun, 20 Mar 2016 11:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0cLibYFCLh1 for ; Sun, 20 Mar 2016 11:38:55 -0700 (PDT) Received: from liselle.bunkus.org (liselle.bunkus.org [176.9.119.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE8112D506 for ; Sun, 20 Mar 2016 11:38:54 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id BD43D1B94814; Sun, 20 Mar 2016 19:38:52 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 402D31B9480C; Sun, 20 Mar 2016 19:38:51 +0100 (CET) Received: by sweet-chili.local (Postfix, from userid 1000) id AC4EE44FBF4; Sun, 20 Mar 2016 19:38:50 +0100 (CET) Date: Sun, 20 Mar 2016 19:38:50 +0100 From: Moritz Bunkus To: "Sebastian G. via Matroska-devel" Message-ID: <20160320183850.GX25937@bunkus.org> References: <56E70483.8090908@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ggEtdcIX3XIOBw6T" Content-Disposition: inline In-Reply-To: <56E70483.8090908@gmx.de> 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@ietf.org Subject: Re: [Cellar] [Matroska-devel] Storing USF 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: Sun, 20 Mar 2016 18:38:56 -0000 --ggEtdcIX3XIOBw6T Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, > Is this still something that has to be done? mkvmerge has supported USF for ages, and there have been no changes in just as long (last substantial change to USF support was in 2005). I'd consider it=E2=80=A6 stable. Maybe =C2=BBdead=C2=AB would be more appropria= te :) Basically the specs could be described like this: (A) CodecID: S_TEXT/USF (B) CodecPrivate: The content of CodecPrivate is the XML content of the whole USF file with the node and all of its children removed. (C) Entries: child node of the node is converted into a single Matroska block. The 's =C2=BBstart=C2=AB attrib= ute is used as the block's start timestamp. The difference between the node's =C2=BBstop=C2=AB and =C2=BBstart=C2=AB attributes is used as the= block's duration. The block's content is the whole child of the node including all of its content. The opening and closing tags are part of the content, too. Example. Let's assume this simple USF file: --start----------------------------------------------------- No fair! You changed the outcome by measuring it! --end------------------------------------------------------- CodecPrivate will look like this: --start----------------------------------------------------- --end------------------------------------------------------- The first node's corresponding block will start at 00:00:01.120, have a duration of 3s 145ms and look like this: --start----------------------------------------------------- No fair! You changed the outcome by measuring it! --end------------------------------------------------------- Kind regards, mosu --ggEtdcIX3XIOBw6T Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW7u46AAoJEHSvAK3y4yyFTkoQAJZdrEM3bpoiWw2JJ3/j03tk VqumUX97f/vYmVcKudEk8sI9YT4Jp3OY6UG9Wlyz+1xRm+QhTJWv8p/8CEoybXdr ACFvugI91GPR6mV4baCJ0snq9+eqhbJ5qlVJpNqMvnQ6MseP5eHHBH5pGH8wd4kZ hAaIJLvCBz7Cg7GEbm/rEkv1UHKQuVo0vSOqlpXMLH6brfciPNKQd25V+3couhae jfCU0DZhdsgnvwQkK4U5u0LKUKp5AptXeyPrXlxrjo1Da07w0nYxfG24DmG150pq 7l3WbSyeo3PbXg1DMWFDP2ZhrP4NoLIJ8/2DTlHhBudXPK9gfSOoFFxnH2wuGLrU 1ZD8Vihyxrh1KcgLIaEGLAn3gblrfb0wVPcmDAw/Pa+af8Kko8dNtD7cf54qNTe+ h9zimAoyhLVeXScZ2XylFZdrumQXU4vddNHqy9Sewqyo+m/RXsamh7/eOew/GA1L BRfSM8wta257Rig37MTXSShg3Honcmoe2WoKBj9HAmD16bt1EE0fJEVB1tkduqtx 0Xqnme/9o7uMhYajCd+SGhH8xAxduFQw/2uCD7qPQ50ZklXXbD/q7dNqAc2QCPU2 SaVe87+ZmDBp3xWQIvosL/A+1O3TafFt2AGDtTqnO4web9omI9LQw0WPUCuzT02y 4ffX9rXkFEE3i8DS3jNs =wrFl -----END PGP SIGNATURE----- --ggEtdcIX3XIOBw6T-- From nobody Sun Mar 20 11:39: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 4508212D571 for ; Sun, 20 Mar 2016 11:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRJA91ZAKq0R for ; Sun, 20 Mar 2016 11:39:33 -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 0D05512D543 for ; Sun, 20 Mar 2016 11:39:33 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id B8FEF1B949F0; Sun, 20 Mar 2016 19:39:31 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 687A41B949D8; Sun, 20 Mar 2016 19:39:30 +0100 (CET) Received: by sweet-chili.local (Postfix, from userid 1000) id D3E7244FBF9; Sun, 20 Mar 2016 19:39:29 +0100 (CET) Date: Sun, 20 Mar 2016 19:39:29 +0100 From: Moritz Bunkus To: Moritz Bunkus via Matroska-devel Message-ID: <20160320183929.GY25937@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="L9fXoLhVbEF7eqMD" Content-Disposition: inline In-Reply-To: <20160320181742.GW25937@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: Sun, 20 Mar 2016 18:39:34 -0000 --L9fXoLhVbEF7eqMD Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, > (A) CodecID: S_WEBVTT I'd be OK with S_TEXT/WEBVTT, too, as the other text subtitle formats all use some variation of S_TEXT/=E2=80=A6 Kind regards, mosu --L9fXoLhVbEF7eqMD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW7u5hAAoJEHSvAK3y4yyFnroP/1tSziXFOXop3LCLzYIyg4uk Y8y6+s0eWKs29/mCXUsNPBsRy1Yfp4n5P0L9Rr3A9wpVtp4gFe+CU1wugj9gJfGt hOw9I0Y5/r8g3qyUSkmV8piAuFrp7wVtvZwrxKIblSJ6rdXRBPeVYAtFSKCpz6OK ZVfJKZpMw8GGhEWlrPABNNvCQKb53s/LFHGsaF9bOOoD8KGsUEfogkiZJxfgX+s0 Ywin3TpysRFf+K/oSp5pgUM3/SNreOoj9Rfz5WPYE5e8p3C9vQMjjujBC6W+wjdN RqMZZAbvx4ojBwfzUmHT8E1E6lQ4F+78MB7f/82xXBCujuoyK+rNLerI4TagkpQA vX9DytwIl9pugSgr0YzZcUeM/WHROFAl8N93MKhbY8PMayY/qwf6nm3ZpFXe6auE oqzxs+mpZi7sGzPUBA7lB+w4BJvEQTuUbmr4l2cqOGK5PEcjGB8KPfVLoSsagPHG k2RIs4xQfdFMSbUJwu09bh0ge8s92ZKxIBIiSFOI0BsSoGLG+RhXJlESR+zYnroO nU5yDF3Z4bOKdxUdaTg2vH9zXWlBGU3Svwp1Yf0mDZ79ReeXhP7yP4yd3Y6Sl6R8 co0NF0K642+50TM+G+aIsl5oX3pGTAE4BfjtKMW/t7lhYvtCNMwOMr+WAesK6hfy SAULNFc5VBl7VYnoWsCW =gH6x -----END PGP SIGNATURE----- --L9fXoLhVbEF7eqMD-- From nobody Sun Mar 20 13:22:30 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6575212D625 for ; Sun, 20 Mar 2016 13:22:27 -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 lMjjCXKprYYS for ; Sun, 20 Mar 2016 13:22:13 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7C812D720 for ; Sun, 20 Mar 2016 13:22:13 -0700 (PDT) Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id A08E91720A4; Sun, 20 Mar 2016 21:22:11 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter36-d.gandi.net (mfilter36-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id YijwIgT3e4Si; Sun, 20 Mar 2016 21:22:09 +0100 (CET) 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 relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 630DA1720BF; Sun, 20 Mar 2016 21:22:09 +0100 (CET) Date: Sun, 20 Mar 2016 21:21:04 +0100 From: Michael Niedermayer To: "Sebastian G. " Message-ID: <20160320202104.GI4557@nb4> References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XXzK2Xfuky388NdO" Content-Disposition: inline In-Reply-To: <56EEECD1.1020109@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Matroska Attachments 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, 20 Mar 2016 20:22:27 -0000 --XXzK2Xfuky388NdO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 20, 2016 at 07:32:49PM +0100, Sebastian G. wrote: > 20.03.2016, 10:26 Steve Lhomme: > > 2016-03-13 15:44 GMT+01:00 Dave Rice : > >> Dear CELLAR, > >> > >> From a review of the Attachments section a few more questions and comm= ents before I send a patch. > >> > >> What is the status of FileReferral, FileUsedStartTime, and FileUsedEnd= Time. These seem to be part of a Matroska extension for divX. Should these = Elements be included in our work? Are these deprecated? > >> > >> FileUID is defined as "Unique ID representing the file, as random as p= ossible." (actually many UID Elements use this language about randomness). = Does this mean that a Unique ID field could be any length from 1 to 8 octet= s? Or are Unique IDs presumed to be a specific length? > >=20 > > It doesn't specify any length, but the bigger the more random. The > > binary approach of FileReferral allows longer lengths so we may keep > > it. But it's not good to have 2 systems in place. I'd rather turn > > FileUID into a binary element (as well as TagAttachmentUID and > > AttachmentLink). It's doable as all existing values would still be > > interpreted the same. > >=20 > > As for the format, different systems may want to use different things > > like MD5, SHA-1 or some random number. Not sure if we should force one > > of them. > >=20 > >> Most of the specific narrative about attachments appears to be here: h= ttps://www.matroska.org/technical/cover_art/index.html. It lists some reser= ved attachment file names like cover, cover_land, small_cover. Are there mo= re reserved names like this? I think this document should be expanded to co= ver other use cases for attachments to include both access and preservation= examples, but what should they be: > >> - cover, poster images > >> - fonts to support subtitles > >> - logs or additional metadata > >> - archived copy of a decoder? > >> > >> I'd be interested to here in other innovative ways to use attachments. >=20 > - Preview images for media catalogs that don't contain any codecs. > - Text-basted information about the content, plot, cast or whatever. > (media libraries could use them) > - Error recovery files e.g. using hamming codes. (for tools that try to > recover errors, not for players) isnt that outside the scope of matroska ? that kind of recovery makes sense for any file, not just multimedia also such attachments would become invalid very likely if they get just copied from an input to an output matroska file, so would require some special care in tools [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope --XXzK2Xfuky388NdO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlbvBjAACgkQYR7HhwQLD6v/ywCfQ2GOyCQBwjbi4VYJK15h7eJt CJcAn1PWuAK0cGQsaS775Vr47Qi/Hqdf =Jawy -----END PGP SIGNATURE----- --XXzK2Xfuky388NdO-- From nobody Sun Mar 20 13:51: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 E7BB312D67D for ; Sun, 20 Mar 2016 13:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjkoUiloiIDP for ; Sun, 20 Mar 2016 13:51:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF1F12D515 for ; Sun, 20 Mar 2016 13:51:30 -0700 (PDT) Received: from [192.168.2.129] ([146.60.194.109]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LrNE4-1Zf4ux2m9E-0139p9 for ; Sun, 20 Mar 2016 21:51:27 +0100 To: cellar@ietf.org References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> <20160320202104.GI4557@nb4> From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <56EF0D52.2060609@gmx.de> Date: Sun, 20 Mar 2016 21:51:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160320202104.GI4557@nb4> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Gs8HwX/txHDgflJUwaw7KeM8wQFMea0daU44eeRWm0VfeM63/Xk og7bSREbjj2KYnRqWBbeIK8UjvQQ7PfgKPkmT5IZFyVt+9lr8ck1EJxELp5WWvkReC2e90n ZiUMBykGUIlW1jXKAc3FfuLnXuXMn/Rk5yYho6ZaJCm9eu/EP1BATP/K9su/mG6YYUBkNiP qcIhj0+ttfvcQwLiGk7jQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:02BjJEWlYwk=:1wfSI7zA4SV39oxUfeJRoZ J+n+0mfneInJEqLKH9ASuD+sVYTjZISkAF3pDA3SEAlAH8W7sFw6FF5w0YSueYjV63yEd+UfQ EYAvhud1J2KgyuScYz5Y2fqrz6g3XMzSoqQxw9HWs8VRlqJvCnMank5A0fBGouHUCkuuOwGPF meumeNRp5g54b5+W4bCaffzNAQLqPnc8vD+plPzaTKKfqujuqTYYyh8+YyqG3NlnFS0FPG/Vm 5JJWSr8rl3mvCofwOUdN2dlioLCiGTSbZqxpr2iRcXF9wrc9Md4PqmC7VYVDURi45W2bDFl72 FVS/B4iakYiRtpowf4uaXDos58FMUkeckNdVUgi0AuviDWRsN+lTBuY3tYo+ff9FeaThig92u o8ard7mqwKk26KljJKWlVvIbhGXc1xHUn5Sp6luPDkvQ1yKTHGGdKbgB5aEB+0TPBxj6qqqLm l9dQCdnrI6ZIw/C9eHDF7757+UGrR/viLPiUP2AHGe8vKVGgQcZGYspQyAVtRkMwJVL9ql59J qQ/981aLUsZBs3WmTJbPNthMkokBFEvqLO2F3stVRLt4vvPbogJ15y9KSlpAYWKnKIEv2YRUI O906kJCLUvBVMuhqrA0kyOGjDlVlMAfWNq3Oug9w5+rMVwn9fE73xX1KYhvc28lFoRfv1wRQG Wq8GmFGTFpd3iCaMfep2xQmmABv0ml1TVbYlKTr2CMPSA8mAnNSctnyRmTkLi2E0ozJLztmpG wimhBfBaOIZ3HGiMaWn6S04pfYca4nseG5gKGiz08lFjM1J0vercXCIuyUOLuGFJuAse5Qqij GDdM4E2 Archived-At: Subject: Re: [Cellar] Matroska Attachments 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, 20 Mar 2016 20:51:33 -0000 20.03.2016, 21:21 Michael Niedermayer: > On Sun, Mar 20, 2016 at 07:32:49PM +0100, Sebastian G. wrote: >> 20.03.2016, 10:26 Steve Lhomme: >>> 2016-03-13 15:44 GMT+01:00 Dave Rice : >>>> Dear CELLAR, >>>> >>>> From a review of the Attachments section a few more questions and comments before I send a patch. >>>> >>>> What is the status of FileReferral, FileUsedStartTime, and FileUsedEndTime. These seem to be part of a Matroska extension for divX. Should these Elements be included in our work? Are these deprecated? >>>> >>>> FileUID is defined as "Unique ID representing the file, as random as possible." (actually many UID Elements use this language about randomness). Does this mean that a Unique ID field could be any length from 1 to 8 octets? Or are Unique IDs presumed to be a specific length? >>> >>> It doesn't specify any length, but the bigger the more random. The >>> binary approach of FileReferral allows longer lengths so we may keep >>> it. But it's not good to have 2 systems in place. I'd rather turn >>> FileUID into a binary element (as well as TagAttachmentUID and >>> AttachmentLink). It's doable as all existing values would still be >>> interpreted the same. >>> >>> As for the format, different systems may want to use different things >>> like MD5, SHA-1 or some random number. Not sure if we should force one >>> of them. >>> >>>> Most of the specific narrative about attachments appears to be here: https://www.matroska.org/technical/cover_art/index.html. It lists some reserved attachment file names like cover, cover_land, small_cover. Are there more reserved names like this? I think this document should be expanded to cover other use cases for attachments to include both access and preservation examples, but what should they be: >>>> - cover, poster images >>>> - fonts to support subtitles >>>> - logs or additional metadata >>>> - archived copy of a decoder? >>>> >>>> I'd be interested to here in other innovative ways to use attachments. >> >> - Preview images for media catalogs that don't contain any codecs. >> - Text-basted information about the content, plot, cast or whatever. >> (media libraries could use them) > >> - Error recovery files e.g. using hamming codes. (for tools that try to >> recover errors, not for players) > > isnt that outside the scope of matroska ? For implementing in Matroska directly, probably. Since this is about the attachment system it can be used for that or any other thing. > that kind of recovery makes sense for any file, not just multimedia > also such attachments would become invalid very likely if they get > just copied from an input to an output matroska file, so would > require some special care in tools Indeed, special tools would be required to handle this case. That should be no concern to Matroska itself. Even cover images are not of great use for a media player, that reads a file and just plays it. Best regards, Sebastian From nobody Thu Mar 24 18:38:34 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFC812D13E for ; Thu, 24 Mar 2016 18:38:33 -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 YzrqaUAyRQz2 for ; Thu, 24 Mar 2016 18:38:30 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 378C412D0DB for ; Thu, 24 Mar 2016 18:38:30 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id l20so4778464igf.0 for ; Thu, 24 Mar 2016 18:38:30 -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=pO7jbdITaad7ire7g+SWLElsInf4vZ5TyvsQPAu9/IE=; b=fegFYoXwHvI0qZPiSUhbmjN36UQ4w5asTcg/ZX7/FrK9HNX/cQLPDBr8VkaFB3pQTH Znibsb7fxMDxj0hZrRfqzqYu2FAB8xOJ9ytuqr1vkJMMak0egaBVbVyaW8VHJRaObfMI QjwkWxy+Q9CT0cigj102OuJVI/G3ICKtmnkh8/O8radHSNt3QIzNhvzm5l4H5EDslLUQ aPX8JiPt8UZDlKze7fdKjBomuFjL/IHx4dH0NfQj0CpzbFNzIOouBgOUrQgWwrls9tzi fkLffk0gBN0sC1pQlktvm9pTLojUGqN9wTRCYSYiAxpYCgTLJuT9VBRZD/icHdOjC7SL ayRw== 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=pO7jbdITaad7ire7g+SWLElsInf4vZ5TyvsQPAu9/IE=; b=bBsv3Bi3jA9ufxiMHPWKdmUVj7mcmW2RBImP9UIuZBQngsdBhl0lCVglMnoCB/tYhU UH2wysah5WNaano8CmWWrc8JtMFMcEh+oZduwP0cqbiAmul1jIZr/t67gGMZCANJJ+uP r9BAgltLL8YC8JgDD2fNGTEBHohqn/Ny7TV+Nm+/9XWt0fcGP43901SPkXESAPGKvyDT eZgpKm5H/f5cQyZ5jIZtjzTE/UCyHR9lGoCRZ6v1ESu1/83E88KN0OktFCPjO6ubJ6IJ H0ieH/ZNM8OYUav97REAI1F04cLg712HajvZumNgwc+0hmGctcmKY/xhroFSNHlZv1Bh LxKA== X-Gm-Message-State: AD7BkJJAwz7yPhZfxQZIuHV2BUR36ccljsKC0d6S6wUd1CVAYkv1BNB2hMZNRnntwsnkKg8t0bfiJGEPm5TeSw== MIME-Version: 1.0 X-Received: by 10.50.178.180 with SMTP id cz20mr31688428igc.44.1458869909433; Thu, 24 Mar 2016 18:38:29 -0700 (PDT) Received: by 10.79.9.196 with HTTP; Thu, 24 Mar 2016 18:38:29 -0700 (PDT) In-Reply-To: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> References: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> Date: Thu, 24 Mar 2016 21:38:29 -0400 Message-ID: From: Ashley Blewer To: Dave Rice Content-Type: multipart/alternative; boundary=089e01538994b9b1ca052ed59ef5 Archived-At: Cc: cellar@ietf.org, Steve Lhomme 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: Fri, 25 Mar 2016 01:38:33 -0000 --089e01538994b9b1ca052ed59ef5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. 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 listserv and approved there? 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_jeky= ll_poc > repository. I am open to either matroska-spec-repo approach as Ashley > demonstrated in GitHub; however I have a preference for the jekyll versio= n > as we could work on the specifications in Markdown rather than directly i= n > 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 and > 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 -- outdated). > > > > 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 document = into a new > `Legacy Matroska` section to reference historical Matroska documents whil= e > 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 state= s > 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 the > 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 repo i= s > 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 will = 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 know i= f > >> 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 appea= r > >> 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 completion o= n > a > >>>> MatroskaOrg-hosted or CELLAR-hosted Github organizational account, b= ut > >>>> would > >>>> like to hear from everyone on which site is the best for a > collaborative > >>>> environment. > >>>> > >>>> Option 1: Jekyll-based website that automatically translates Markdow= n > to > >>>> HTML. > >>>> Option 1 repo: https://github.com/ablwr/mkv_jekyll_poc > >>>> Please note this currently follows a Jekyll theme standard but can b= e > >>>> 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. Howeve= r, > >>>> the > >>>> primary table located on the specification page is rendered via XML > and > >>>> would not have to be rewritten in Markdown (although this example do= es > >>>> 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 local > >>>> server. > >>>> But work is harder to read because it's in HTML and most changes wil= l > be > >>>> very text-based anyway. > >>>> > >>>> After we come to a decision, I can move relevant specification detai= ls > >>>> to > >>>> this site and it can be used to make changes to the standard after > >>>> decisions > >>>> are made here on CELLAR. > >>> > >>> I never heard of Jekyll before but it seems interesting. That would b= e > >>> for the RFC based specs, so maybe the table of elements will go in th= e > >>> 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 find > >>> issues. > >>> So as a starting project I think the Markdown approach is good. We ca= n > >>> always go back to pure HTML and continue from there later. While the > >>> 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 > > --089e01538994b9b1ca052ed59ef5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I intentionally haven't mer= ged 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 fe= el right for me to approve of Dave's work on this.

=
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 li= stserv and approved there?

Let me know your though= ts!

Ashley
<= br>
On Thu, Mar 17, 2016 at 10:45 PM, Dave Rice <= span dir=3D"ltr"><= dave@dericed.com> wrote:
Hi= all,

To test this out, I submitted a Pull Request to Ashley=E2=80=99s mkv_jekyll= _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 directly 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 and as= sociate it to CELLAR WG.

> This document is a work-in-progress specification defining the Matrosk= a 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 libmatros= ka. Legacy versions of the specification can be found [here](/files/matrosk= a.pdf) (PDF doc by Alexander No=C3=A9 -- outdated).
>
>=C2=A0 For a simplified diagram of the layout of a Matroska file, see t= he [Diagram page](../diagram/index.html).

I could also move the reference to Alexander No=C3=A9=E2=80=99s document in= to 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 redundan= t to the EBML specification. Instead I added a section that states that Mat= roska 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-O= rg/ebml-specification/blob/master/specification.markdown). For an under= standing of Matroska's EBML Schema, see in particular the sections of t= he EBML Specification covering [EBML Element Types](https://github.com/= Matroska-Org/ebml-specification/blob/master/specification.markdown#ebml-ele= ment-types), [EBML Schema](https://github.com/Matroska-Org/ebml-specificat= ion/blob/master/specification.markdown#ebml-schema), and [EBML Structur= e](ht= tps://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_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 <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 page -- th= e 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 w= ill 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 know if
>> we're tied to having the Github Page site look like Matroska.o= rg or if,
>> since it's for spec viewing and work in particular, it's f= ine to appear
>> differently.
>
> The design doesn't matter too much. As long as it's easy to re= ad 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 collaborative fra= mework with which
>>>> to
>>>> continue work on the Matroska specification in a code-deve= lopment
>>>> context
>>>> after we've had conversations on this list.
>>>>
>>>> I'd like to propose we migrate the Matroska specificat= ion to Github. As
>>>> I
>>>> mentioned before, I'm happy to carry this transition t= o completion 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 translat= es Markdown to
>>>> HTML.
>>>> Option 1 repo: https://github.com/ablwr/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 use. The be= nefits are
>>>> working
>>>> in the more human-readable Markdown instead of HTML. The n= egative is
>>>> that
>>>> running a local Jekyll server to preview work before submi= tting a
>>>> request is
>>>> harder than opening up a static site.
>>>>
>>>> Also, tables can be difficult to read and create in Markdo= wn. However,
>>>> the
>>>> primary table located on the specification page is rendere= d via XML 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_p= ages_poc
>>>> This has been translated to replicate the Matroska site. >>>>
>>>> Like I said above, previewing work doesn't require run= ning a local
>>>> server.
>>>> But work is harder to read because it's in HTML and mo= st changes will be
>>>> very text-based anyway.
>>>>
>>>> After we come to a decision, I can move relevant specifica= tion details
>>>> to
>>>> this site and it can be used to make changes to the standa= rd after
>>>> decisions
>>>> are made here on CELLAR.
>>>
>>> I never heard of Jekyll before but it seems interesting. That = would be
>>> for the RFC based specs, so maybe the table of elements will g= o 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= find
>>> 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. Whi= le the
>>> opposite is more work and not trivial.
>>>
>>>> My best,
>>>>
>>>> Ashley Blewer
>>>>
>>>> _______________________________________________
>>>> Cellar mailing list
>>>> Cellar@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/c= ellar
>>>>
>>>
>>>
>>>
>>> --
>>> Steve Lhomme
>>> Matroska association Chairman
>>
>>
>
>
>
> --
> Steve Lhomme
> Matroska association Chairman
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar

--089e01538994b9b1ca052ed59ef5-- From nobody Sat Mar 26 15:42: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 A8BE412D566 for ; Sat, 26 Mar 2016 15:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GVOknj0fT19 for ; Sat, 26 Mar 2016 15:42:35 -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 8113B12D59F for ; Sat, 26 Mar 2016 15:42:35 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:36143 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 1ajwud-002gb2-9b; Sat, 26 Mar 2016 18:42:36 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_6EF409A1-BAC2-4A7D-801F-04E3662E9703" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Sat, 26 Mar 2016 18:42:27 -0400 Message-Id: <442FEE5C-FCE3-4966-AFA0-CF6159E79C39@dericed.com> References: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> To: Ashley Blewer 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, Steve Lhomme 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: Sat, 26 Mar 2016 22:42:38 -0000 --Apple-Mail=_6EF409A1-BAC2-4A7D-801F-04E3662E9703 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, > On Mar 24, 2016, at 9:38 PM, Ashley Blewer = wrote: >=20 > Hi all, >=20 > 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. >=20 > 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 = listserv and approved there? I=E2=80=99ll leave this to WG Chairs, Steve, and Moritz and whomever = contributes 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). The current Matroska spec is on a website, in Drupal posts, which is not = so RFC-like and doesn=E2=80=99t offer the same list of features for = collaboration as github. I suggest we work Matroska specification = website in a GitHub repo (wherever that may be located). 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 in markdown). 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.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, = such 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 user guides, faq, downloads, logos, etc). 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. Comments welcome. Best Regards, Dave > Let me know your thoughts! >=20 > Ashley >=20 > On Thu, Mar 17, 2016 at 10:45 PM, Dave Rice > wrote: > Hi all, >=20 > To test this out, I submitted a Pull Request to Ashley=E2=80=99s = mkv_jekyll_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 directly in HTML. I find Markdown patches a lot = easier to read than HTML patches. >=20 > The pull request is here: = https://github.com/ablwr/mkv_jekyll_poc/pull/1 = . >=20 > The PR mainly has two changes: >=20 > - The introduction is rephrased to say that the specification is WIP = and associate it to CELLAR WG. >=20 > > 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 -- outdated). > > > > For a simplified diagram of the layout of a Matroska file, see the = [Diagram page](../diagram/index.html). >=20 > I could also move the reference to Alexander No=C3=A9=E2=80=99s = document into a new `Legacy Matroska` section to reference historical = Matroska documents while contextualizing them as superseded by = CELLAR=E2=80=99s work. >=20 > - 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: >=20 > > ### 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/mas= ter/specification.markdown = ). For an understanding of Matroska's EBML Schema, see in = particular the sections of the EBML Specification covering [EBML Element = Types](https://github.com/Matroska-Org/ebml-specification/blob/master/spec= ification.markdown#ebml-element-types = ), [EBML = Schema](https://github.com/Matroska-Org/ebml-specification/blob/master/spe= cification.markdown#ebml-schema = ), and [EBML = Structure](https://github.com/Matroska-Org/ebml-specification/blob/master/= specification.markdown#structure = ). >=20 > 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_poc/#elements-semantic = , but I am = interested in the idea of re-designing the presentation of the table. >=20 > Thanks, > Dave Rice >=20 >=20 > > 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 = will 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 = know 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 = completion 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 = can 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 = XML 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 = local > >>>> 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 = after > >>>> decisions > >>>> are made here on CELLAR. > >>> > >>> I never heard of Jekyll before but it seems interesting. That = would 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 = find > >>> 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 = the > >>> 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 = >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_6EF409A1-BAC2-4A7D-801F-04E3662E9703 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 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.

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 listserv = and approved there?

I=E2=80=99ll leave this to WG Chairs, Steve, and = Moritz and whomever contributes 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).

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

Ashley=E2=80=99s draft = repo at https://github.com/ablwr/mkv_jekyll_poc/blob/gh-pages/index.md<= /a> represents only https://matroska.org/technical/specs/index.html. My = initial PR at https://github.com/ablwr/mkv_jekyll_poc/pull/1/files m= ostly 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 in = markdown).

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/specs/notes.html
<= a href=3D"https://matroska.org/technical/order/index.html" = class=3D"">https://matroska.org/technical/order/index.html
<= br class=3D"">
And then moving on the the pages to focus on = the Top Level Elements, such 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 user guides, faq, downloads, logos, etc).

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.

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 = mkv_jekyll_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 directly 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 and = 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 -- = outdated).
>
>  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 document = 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/= specification.markdown). For an understanding of Matroska's EBML = Schema, see in particular 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_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 <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 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 will 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 = know 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 <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 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 = completion 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 can 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 XML 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 local
>>>> 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 after
>>>> decisions
>>>> are made here on CELLAR.
>>>
>>> I never heard of Jekyll before but it seems interesting. = That would 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 find
>>> 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 the
>>> 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

= --Apple-Mail=_6EF409A1-BAC2-4A7D-801F-04E3662E9703-- From nobody Mon Mar 28 05:05:44 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 89F9D12D8A7 for ; Mon, 28 Mar 2016 05:05:42 -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 dZ2-DINvkDeL for ; Mon, 28 Mar 2016 05:05:40 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522AB12D174 for ; Mon, 28 Mar 2016 05:05:40 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id s5so107246598qkd.0 for ; Mon, 28 Mar 2016 05:05:40 -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=ucpXbde3QYujpayRci053dFRyCxPTsCIxu5c94pgn5g=; b=HaGmquZhdjPGuuZSHxCmrOWzVo+3KnDF+el0hjYTBqHrS0gE2tV9Da9v2fxe3dCg0o 2MM9XPkTaPHZie3HkuCA3q7tEumrXFOTvIOW4Lp2SGKqH8oha/6jjtZ0RSjdA1FH6lde ctzMeh1x8CbRFiJPamcCGbR99ENLzaqDnlAID0L6OhoxVel+do9kcYQ+KliLjiIQ9GSU EE8/w/Ybg3p5+Eo1WfpM8i1sz4sGzdxiCmMqEUM5ASQANUuwUPVhZMoHXqpt/PWMopTD 6CUM/Y203wH1gwMp0doESk985x8h9MDJpYozFlE0d85cO8KoeEjvrPA2S5qz2q7xvkjC 3usA== 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=ucpXbde3QYujpayRci053dFRyCxPTsCIxu5c94pgn5g=; b=O+7/OgN//kgIq768aNCtA9aIrT/FJ/a9Kl5RkJPLDOuVmBWRht/yPkAGKMJs7x5CIY AJHPBMdYc28QibvgaHlmZKaC39S14oUq8hlMvlkbcB3s73r2l66tXjrv2SevNg30JR8e Qx86ZJBuV6Zq/NuDYTMzmlIKR2CqAUO38k+JbWA/3CRUSy07qCptUQFHYsRX5WJ9X6Ai g44O1m9MnDjmzpUfLZeVAuZw7A9r8kKuAXVx6sXYsy8E4zFHJxyDZM3oQZuchnSBzCO0 9d2Ekeq4bgFF939PWuol7fU3oHi3MSzJpRlATiRCM4miZVNW0ZocngoTS2DHVCCGuKcq ADcw== X-Gm-Message-State: AD7BkJIgo2Bqic0xP20rvZns01EsLpRQ0mbPf2QS0VBZmhfjtg3xHTjBxhfF1h1Pd2dx1O2xPM49/oPSzLbWJg== MIME-Version: 1.0 X-Received: by 10.37.71.130 with SMTP id u124mr2147533yba.93.1459166739326; Mon, 28 Mar 2016 05:05:39 -0700 (PDT) Received: by 10.83.28.196 with HTTP; Mon, 28 Mar 2016 05:05:39 -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, 28 Mar 2016 14:05:39 +0200 Message-ID: From: Steve Lhomme To: Frank Galligan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Michael Niedermayer , Jerome Martinez , cellar@ietf.org, Discussion about the current and future development of Matroska , Dave Rice 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, 28 Mar 2016 12:05:42 -0000 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. > Next what are we missing and what do you think we need to add to support the > formats? > > > Would adding interlaced and horizontal flip elements be enough to support > the 4:2:0 that people are using today? >> >> >> [...] >> >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> No snowflake in an avalanche ever feels responsible. -- Voltaire > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Mon Mar 28 05:19:43 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 3121812D8E4 for ; Mon, 28 Mar 2016 05:19:42 -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 nEt2QNOwo9zr for ; Mon, 28 Mar 2016 05:19:39 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 5C97112D8D8 for ; Mon, 28 Mar 2016 05:19:39 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id i4so68492041qkc.3 for ; Mon, 28 Mar 2016 05:19:39 -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:content-transfer-encoding; bh=ZmF5GnRwpypkFhQVKYRzpfWzubgGQ69FZaYxw/ZyIP8=; b=HhC+HQiOBLk9j6BiNYsUOv+D4GbCP6xzsggqEs7DGvWC4H/3o/OGs6PLswR8N+RkpF hdte56Yf24vo91ZUU1FSOe+gKgTgIRpBJQvkP29vLawZMqDtCpeSKn+KCwubfRqSj87g xedDWMHEOcgkDrt11hvLstwz5MejJ66NRN9tFusCjmT08wC4t+zAN+HAN9zogMAarLfW IyXHdpUVbq2ReCFAZKAvYKSc7o14aTuBXWo0O/lcuz8GqH1qEYXGnCkNpB8FCt5Ynp52 OiVs59q//toO4H/jr9SV1rqdEoCgn+L9rmzsj0QxMxfRoRzQBihMZGB61RwGAMuuW5b1 6aCQ== 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:content-transfer-encoding; bh=ZmF5GnRwpypkFhQVKYRzpfWzubgGQ69FZaYxw/ZyIP8=; b=Xyq6rMmai52Sp4WyHG4sWQdlfjrlTT357UnJ1AN0kBCKFLpVMFKJB7UUp3ZI37vSGi WOfs2p4P8LdV/U8qPZi5NUk7SuKLdGRbiBRlaOHjzNoDuTTpfoeqVdxeEKZqoV/4+vqM 6wjbE86ZWYK1K3ON7UJjsaxl14lOxrnlF9VGu13N6BljzCpyI9xwsI6EYWbZ7HovvtSj 9xohRPPtRHBhnQyuDxES8UgpwkmgyjUnLuBf0/fF76n2D9iNTl9gb9QF6Y5sDhjeTKAT 9D5/9HUTuCJmAkT1vLxvroc2obkD6iA6+ljVXnQWp0c0r734oDR0pDdn67OH78OgZbwZ jMIA== X-Gm-Message-State: AD7BkJL3SMbwOO/iCfU0kJ9QWg7+LMhSdzZcGhwZbDDNx5Pe2B0cyWYxWujoHjwgViQ4rkeBd6qUPuHT9zFcSQ== MIME-Version: 1.0 X-Received: by 10.13.247.4 with SMTP id h4mr14795432ywf.15.1459167578460; Mon, 28 Mar 2016 05:19:38 -0700 (PDT) Received: by 10.83.28.196 with HTTP; Mon, 28 Mar 2016 05:19:38 -0700 (PDT) In-Reply-To: <442FEE5C-FCE3-4966-AFA0-CF6159E79C39@dericed.com> References: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> <442FEE5C-FCE3-4966-AFA0-CF6159E79C39@dericed.com> Date: Mon, 28 Mar 2016 14:19:38 +0200 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org, Ashley Blewer 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, 28 Mar 2016 12:19:42 -0000 2016-03-26 23:42 GMT+01:00 Dave Rice : > Hi all, > > On Mar 24, 2016, at 9:38 PM, Ashley Blewer wrot= e: > > Hi all, > > I intentionally haven't merged this PR since it's being used as an exampl= e. > I am happy to merge it in, but I myself am not representative of Matroska= Org > 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 t= o > MatroskaOrg Github account and work can be commented on via the listserv = 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 cont= ributes 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 not = so > RFC-like and doesn=E2=80=99t offer the same list of features for collabor= ation as > github. I suggest we work Matroska specification website in a GitHub repo > (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 eventua= lly > we could have a build process that combining information from specdata.xm= l > with the rest of the specification to make nice human-readable versions a= nd > interactive tables of the Matroska spec, but for specification work I thi= nk > it may help to separate the EBML Schema data of the table and the rules a= nd > 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.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, such > as: > https://matroska.org/technical/specs/chapters/index.html > https://matroska.org/technical/cover_art/index.html (expanding this to co= ver > 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 spe= c > and other data that is intended to support that (such as the info on user > 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 th= e 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_jek= yll_poc >> repository. I am open to either matroska-spec-repo approach as Ashley >> demonstrated in GitHub; however I have a preference for the jekyll versi= on >> as we could work on the specifications in Markdown rather than directly = 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 and >> associate it to CELLAR WG. >> >> > This document is a work-in-progress specification defining the Matrosk= a >> > 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 libmat= roska. >> > Legacy versions of the specification can be found >> > [here](/files/matroska.pdf) (PDF doc by Alexander No=C3=A9 -- outdated= ). >> > >> > 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 document= into a new >> `Legacy Matroska` section to reference historical Matroska documents whi= le >> 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 stat= es >> 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/specification.markdown). >> > For an understanding of Matroska's EBML Schema, see in particular 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/mas= ter/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_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 th= e >> >> 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/replicate exactly th= e >> >> 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 Matroska.org or i= f, >> >> since it's for spec viewing and work in particular, it's fine to appe= ar >> >> 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 completion = 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 Markdo= wn >> >>>> to >> >>>> HTML. >> >>>> Option 1 repo: https://github.com/ablwr/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 use. The benefits ar= e >> >>>> working >> >>>> in the more human-readable Markdown instead of HTML. The negative i= s >> >>>> 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 XML >> >>>> 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 local >> >>>> server. >> >>>> But work is harder to read because it's in HTML and most changes wi= ll >> >>>> 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 after >> >>>> decisions >> >>>> are made here on CELLAR. >> >>> >> >>> I never heard of Jekyll before but it seems interesting. That would = be >> >>> for the RFC based specs, so maybe the table of elements will go in t= he >> >>> end or be presented differently. Until the RFC work is done we shoul= d >> >>> keep the current specs as they are, just fixing things when we find >> >>> issues. >> >>> So as a starting project I think the Markdown approach is good. We c= an >> >>> always go back to pure HTML and continue from there later. While the >> >>> 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 > > --=20 Steve Lhomme Matroska association Chairman From nobody Mon Mar 28 05:30:44 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 3DC3612D187 for ; Mon, 28 Mar 2016 05:30:43 -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 GKT85T9YFvUZ for ; Mon, 28 Mar 2016 05:30:41 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E7412D169 for ; Mon, 28 Mar 2016 05:30:40 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id o6so108142237qkc.2 for ; Mon, 28 Mar 2016 05:30:40 -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:content-transfer-encoding; bh=/PxQCHxmqZITBRS+4NnL6onfTcyYTXpau9Rd9B/O8nU=; b=rKAfi0yLxQrfKsDQkPaqZSNbpkNW5WZrpZBl+72vh3GQNph+crX9NhZjRdIe8jj6I9 zndVKwjxAIT15fgvgWg5CfZiKPekK/sbMjo7TC12EE1CYlpuZ9QqKVv9O53E/KrD6uU2 14CiTC2eNbslOFId5QDQCInixPb9KKjVf+DwmM24IGjX3fgyvImeQ2l2lLi8+Cs+qTGo w648WjsE0YMl9hThcwPTbYJ2ZnI9R5mFlav+A5dF8BsjFoCIhTDrHdNQVjN2G8sNFQFR aQZVcs1UQPm6rkT70xejVLGLLzM4CYQWZK8UH+lVqr7apTFrn5wruoC5hICG3zSsIzoS eVtw== 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:content-transfer-encoding; bh=/PxQCHxmqZITBRS+4NnL6onfTcyYTXpau9Rd9B/O8nU=; b=CHDbcUYm1ylUbQnV5eyLK/Aww1j+bMfluQWS4nEaRbFtg8M9+TvypmHf5KMor7RVYt LUEB/qP960DmD8ZaZcVYK8iE418e9Wpx3KzGYhtp6G79Jwt6R6yz8Vx1ucjljRqMj3mm 9D5wQNc06pHs858mdP3nrQfynuKLzU43W44gYSi3Pyiga0D9q43ArAfGnOeC43tLnPFJ kEqC23FyXnhXlEg16ZOj9U6WCwJbyKuFTBHx2oDjtvQcqIjPxHwKN4IzbBrYCx3uaukE flVzGpJLTzov3N1elia9QZi5xiWBRH5+8WcSS9EEF1N9gCiWXN9EJZKlutXlSbr1V1j2 CXyA== X-Gm-Message-State: AD7BkJIYIdTO6xcGd6dJI6ldVtbjJxphhzNtnYVFlfCuLl9dfoWjAI+6DHUsvf3RWoGebyS28+yJ7Da3ox2wVw== MIME-Version: 1.0 X-Received: by 10.37.22.197 with SMTP id 188mr13189779ybw.98.1459168239971; Mon, 28 Mar 2016 05:30:39 -0700 (PDT) Received: by 10.83.28.196 with HTTP; Mon, 28 Mar 2016 05:30:39 -0700 (PDT) In-Reply-To: <56EEECD1.1020109@gmx.de> References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> Date: Mon, 28 Mar 2016 14:30:39 +0200 Message-ID: From: Steve Lhomme To: "Sebastian G. " Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Matroska Attachments 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, 28 Mar 2016 12:30:44 -0000 2016-03-20 19:32 GMT+01:00 Sebastian G. : > 20.03.2016, 10:26 Steve Lhomme: >> 2016-03-13 15:44 GMT+01:00 Dave Rice : >>> Dear CELLAR, >>> >>> From a review of the Attachments section a few more questions and comme= nts before I send a patch. >>> >>> What is the status of FileReferral, FileUsedStartTime, and FileUsedEndT= ime. These seem to be part of a Matroska extension for divX. Should these E= lements be included in our work? Are these deprecated? >>> >>> FileUID is defined as "Unique ID representing the file, as random as po= ssible." (actually many UID Elements use this language about randomness). D= oes this mean that a Unique ID field could be any length from 1 to 8 octets= ? Or are Unique IDs presumed to be a specific length? >> >> It doesn't specify any length, but the bigger the more random. The >> binary approach of FileReferral allows longer lengths so we may keep >> it. But it's not good to have 2 systems in place. I'd rather turn >> FileUID into a binary element (as well as TagAttachmentUID and >> AttachmentLink). It's doable as all existing values would still be >> interpreted the same. >> >> As for the format, different systems may want to use different things >> like MD5, SHA-1 or some random number. Not sure if we should force one >> of them. >> >>> Most of the specific narrative about attachments appears to be here: ht= tps://www.matroska.org/technical/cover_art/index.html. It lists some reserv= ed attachment file names like cover, cover_land, small_cover. Are there mor= e reserved names like this? I think this document should be expanded to cov= er other use cases for attachments to include both access and preservation = examples, but what should they be: >>> - cover, poster images >>> - fonts to support subtitles >>> - logs or additional metadata >>> - archived copy of a decoder? >>> >>> I'd be interested to here in other innovative ways to use attachments. > > - Preview images for media catalogs that don't contain any codecs. > - Text-basted information about the content, plot, cast or whatever. > (media libraries could use them) > - Error recovery files e.g. using hamming codes. (for tools that try to > recover errors, not for players) > - Specifications of Matroska, the audio codecs, video codecs, the > subtitles (for very long-term storage) > - Public-key (DRM is possible, but also authenticating against a server > to get updates on the content you watch [or are about to watch], like a > documentary you purchased.) > - Picture or text-based annotations. > >> A matroska file with just attachments for storage. But I don't think >> it has any advantage over TAR or RAR. > > It certainly has the advantage that attachments can't be lost. > Attachments can't be edited (directly), which has both advantages and > disadvantages. So unless someone touches the matroska file it contains > all the attachments that are the way the creator intended them to be. > > With an archive you can extract all files, then delete some or extract > the archive just partly. You can probably do the same with Matroska. Adding Matroska support in 7-zip might be a fun project (if it's not handled already). After that, apart from the multimedia part of the file it's just a (very) basic archival format. > Like having a font that is supposed to be used with one of the subtitles > that has been muxed into the file. > > Having more ways to interact with attachments in Matroska seems like a > good thing to me. Safely handling the attachments is up to the > application anyway. Should anyone be concerned about security > attachments could be ignored. Yes, for example there might be a virus in a font and you might have to install it on the system before you can use it. Same thing with a PNG or a JPEG. That's already a concern with what we have now. But it's out of the scope of Matroska how each type of file is used. As long as we extract the proper data, not more, not less with the proper strings attached, we're fine. > I'd like to see Matroska used more often than it is right now. AVI was > good enough back in the good old days, currently MP4 seems to offer > enough that it is used very very often. If Matroska has more advantages > over other containers it should see more usage, at least in theory. I agree. >>> Also the cover image examples seem to use specs that are aged. A cover = image is recommended to be 600 pixels tall/wide, but should this values be = increased as user expectations of image quality increase? >> >> As recommandations, yes. >> > > How would "values be increased as user expectations of image quality > increase" be specified? Not sure if there is a de facto standard for movies and TV shows or album covers in the HD world. Maybe there is for pirated stuff that we could look into. I'm not sure there's such a thing for legal content. > It is possible to recommend a minimum resolution. To me it seems like a > good idea to do so. It is possible to recommend a maximum resolution, > but here I would let it open as the limit might not be adequate. > > Currently it can't be expected that a 4K image will be displayed by > everything that supports cover images right now, but at some point in > might be the case. So far it's a grey area. I'm not sure this kind of recommendation should be in the Matroska RFC. That's more guidelines around what the specs cover. > You might could say "image quality should reflect state-of-the-art > standards, while also considering legacy systems." > > Best regards, > Sebastian > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Mon Mar 28 06:14:57 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D8B12D934 for ; Mon, 28 Mar 2016 06:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yBFqggqIa4JP for ; Mon, 28 Mar 2016 06:14:54 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 4214412D937 for ; Mon, 28 Mar 2016 06:14:51 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id x64so69292966qkd.1 for ; Mon, 28 Mar 2016 06:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=b2ke4uf4dCUUvHH1Nx2ieaSL8lfrveyXn0DhEO1jOhE=; b=o+RilEYXyjGiRG7l44pGe9CKlrAy7mCQzPSZKqhPNNbfQ0BZlEReioYh05aLH/WOOQ HfcnMwd8U/Ta+hmgBTnl7XFIf3plyhirT5K+PCiBDOpwYVOmXpds3ciexEu3emAsRxRl 4095QEcfXCVr0eU8W6ZWEpQaSxsrMjZtQ1MRtAeUEKs8lpFBnNs1R2rximGdT+bjmCuL YAn77ZohUCYX1ol15ib8CX1ROw1wWO35xMIyn+aWJMGYPjwj+p7DuXsov2ZfBmXNxXwI eF9iJfVgDZyjNpo23UWd8hmsFnQLS3YeojuFOEB9wgz87O2DzHFOA30C4GG9pIV9YKiw 0LgQ== 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=b2ke4uf4dCUUvHH1Nx2ieaSL8lfrveyXn0DhEO1jOhE=; b=b6WOxbT7wPUwayJ8nFRtEE9FKz/UmNMugJo3wFkrY93OFVROLaOIX2yoMrSJ6sFmzy K4NGf9UNEDMB5LhsKRYsPiK7UDuYhrDzoBB4WPqzqHO4d+JgImypZMuXQRi0l4NGDuHE dFL36hWUhrxW80uMoW2iyTLymZQBtiSsxRQRL6rYg8uWbtULhQyx4Wc9QhOo1ANFnlgs UylLHBuSf0t+lNxw2ycWZDPdQfEb2yKCZAifS1HwEYMkFnBeBcq+LIJqMfDsWvsNYFjD F869PvOKkQQ3jZzf0CengIdWxFL8EVCuPqJ8Bw8G+QhdTZLniuRWp/imneMjhYkl+Sot kfRg== X-Gm-Message-State: AD7BkJJdpim08I8FLzWYnuEWj9QLXsGzUTa433z9aGRuzKrz65BeSgV9FISNRMf3lBfGl8Kj+gp9bNSPSIuQaw== MIME-Version: 1.0 X-Received: by 10.37.22.197 with SMTP id 188mr13293115ybw.98.1459170890233; Mon, 28 Mar 2016 06:14:50 -0700 (PDT) Received: by 10.83.28.196 with HTTP; Mon, 28 Mar 2016 06:14:50 -0700 (PDT) Date: Mon, 28 Mar 2016 15:14:50 +0200 Message-ID: From: Steve Lhomme To: cellar@ietf.org, Matroska Devel Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Cellar] Specs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 13:14:56 -0000 I updated the specs on https://www.matroska.org/technical/specs/index.html according to the latest version on specdata.xml here: https://github.com/Matroska-Org/foundation-source/blob/master/spectool/specdata.xml -- Steve Lhomme Matroska association Chairman From nobody Mon Mar 28 07:45: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 34E1812D9B3 for ; Mon, 28 Mar 2016 07:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ_8NfUdWSXq for ; Mon, 28 Mar 2016 07:45:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428B412DA38 for ; Mon, 28 Mar 2016 07:45:16 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2SEj9a7033185 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Mar 2016 09:45:10 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Steve Lhomme" Date: Mon, 28 Mar 2016 09:45:09 -0500 Message-ID: In-Reply-To: References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: cellar@ietf.org, "Sebastian G." Subject: Re: [Cellar] Matroska Attachments 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, 28 Mar 2016 14:45:22 -0000 On 28 Mar 2016, at 7:30, Steve Lhomme wrote: > Having more ways to interact with attachments in Matroska seems like a >> good thing to me. Safely handling the attachments is up to the >> application anyway. Should anyone be concerned about security >> attachments could be ignored. > > > Yes, for example there might be a virus in a font and you might have > to install it on the system before you can use it. Same thing with a > PNG or a JPEG. That's already a concern with what we have now. But > it's out of the scope of Matroska how each type of file is used. As > long as we extract the proper data, not more, not less with the proper > strings attached, we're fine. Any ability to carry arbitrary (potentially executable) attachments will get scrutiny from at least the security ADs and the security directorate reviewer(s). I agree it's out of scope for Matroska to police those, but you will want to at least have language describing the issue, and to point out that applications (or OSs or something) need to police them. Thanks! Ben. From nobody Mon Mar 28 08:35: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 B01E412DAC4 for ; Mon, 28 Mar 2016 08:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtUMZX5PrukK for ; Mon, 28 Mar 2016 08:35:29 -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 3E30112DAD2 for ; Mon, 28 Mar 2016 08:35:10 -0700 (PDT) Received: from [146.96.19.240] (port=26129 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 1akZC3-003eBD-8V; Mon, 28 Mar 2016 11:35:09 -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: Mon, 28 Mar 2016 11:35:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <18E69030-167D-4A3E-953D-86BB3205F39A@dericed.com> References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> To: Ben Campbell 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, Steve Lhomme , "Sebastian G." Subject: Re: [Cellar] Matroska Attachments 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, 28 Mar 2016 15:35:30 -0000 > On Mar 28, 2016, at 10:45 AM, Ben Campbell wrote: >=20 > On 28 Mar 2016, at 7:30, Steve Lhomme wrote: >=20 >> Having more ways to interact with attachments in Matroska seems like = a >>> good thing to me. Safely handling the attachments is up to the >>> application anyway. Should anyone be concerned about security >>> attachments could be ignored. >>=20 >> Yes, for example there might be a virus in a font and you might have >> to install it on the system before you can use it. Same thing with a >> PNG or a JPEG. That's already a concern with what we have now. But >> it's out of the scope of Matroska how each type of file is used. As >> long as we extract the proper data, not more, not less with the = proper >> strings attached, we're fine. >=20 > Any ability to carry arbitrary (potentially executable) attachments = will get scrutiny from at least the security ADs and the security = directorate reviewer(s). I agree it's out of scope for Matroska to = police those, but you will want to at least have language describing the = issue, and to point out that applications (or OSs or something) need to = police them. Presently an attached file in Matroska is only described with a = FileName, mimetype, and description. There is no permissions, uid, gid, = modification timestamps, etc. So IIUC there no method to clarify if an = attached file is executable or not. Perhaps the specifications should clarify though, if any permissions = should be presumed of an attachment. For instance if a parser exports = the Attachment back to a file, what defaults should be used for = permissions and other file attributes. Other question, should there be other Elements to track other file = attributes? I remember a proposal to use Matroska Attachments similar to = tar, but handling of file attributes is lacking to make this feasible. Dave Rice= From nobody Mon Mar 28 08:55:27 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C08012DBDF for ; Mon, 28 Mar 2016 08:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYxx-Phap1Tj for ; Mon, 28 Mar 2016 08:55:25 -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 C816512DBE6 for ; Mon, 28 Mar 2016 08:52:40 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 73C9820BE965; Mon, 28 Mar 2016 17:52:38 +0200 (CEST) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 3D7AA20BE94D for ; Mon, 28 Mar 2016 17:52:28 +0200 (CEST) Received: by sweet-chili.local (Postfix, from userid 1000) id A7D314E38D3; Mon, 28 Mar 2016 17:52:27 +0200 (CEST) Date: Mon, 28 Mar 2016 17:52:27 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160328155227.GQ7792@bunkus.org> References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> <18E69030-167D-4A3E-953D-86BB3205F39A@dericed.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Rnz0oC2K6vQ5doJs" Content-Disposition: inline In-Reply-To: <18E69030-167D-4A3E-953D-86BB3205F39A@dericed.com> 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] Matroska Attachments 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, 28 Mar 2016 15:55:26 -0000 --Rnz0oC2K6vQ5doJs Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, > Presently an attached file in Matroska is only described with a > FileName, mimetype, and description. There is no permissions, uid, > gid, modification timestamps, etc. So IIUC there no method to clarify > if an attached file is executable or not. > > Perhaps the specifications should clarify though, if any permissions > should be presumed of an attachment. For instance if a parser exports > the Attachment back to a file, what defaults should be used for > permissions and other file attributes. I don't think that it's our (the spec's) job to specify how local system security should be managed. This would be a slippery slope. We're not security experts, and security is one of those fields someone has to be really knowledgeable to get it right. I also don't see the point in making any kind of rules from our side. There are use cases across the whole board regarding system security: from not using any attachments at all; over keeping them in a temporary location only accessible to the current user and deleting them right after playback; to asking the user if she wants to install the fonts extracted from the attachments into the system's font database. It should not be up to the specs to make any kind of assumption here. The specs should mention attachments and the various attack vectors in any future RFC's security section, of course. I wouldn't track file attributes either. Let's see what kind of attributes there are and whether or not it makes sense to include them: - IDs of owning user/group: completely meaningless outside of origin's system/domain - Names of owning user/group: just as meaningless outside of origin's system/domain - Read-only, read/write: meaningless outside of origin's security zone - Immutable: dito - Executable: dangerous and prone to confusion with the MIME type. What if an attachment of MIME type text/plain is marked executable? Doesn't make sense, now does it? And what about different platforms? An attachment of MIME type application/x-dosexec on Linux? MIME types should be enough for a reader to figure out whether or not an attachment has any business of being executable on the current platform. Kind regards, mosu --Rnz0oC2K6vQ5doJs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW+VM2AAoJEHSvAK3y4yyFBysP/18pn8SjS3tUZKTV0h98Z6fc BTU40Cl1mHTE4QU1theAdOgPmHVt0bO6IFmNjxUUc9V5Zmzhg5j0bjKUJSyFf5e3 ILnyVTeV810f2kTkyAbm5DdnTkfCVsQGi9C+1T5UaFDp8zps1vm+uXs7Ygrp9aKJ CZ6oEE3iApxewtR56Taieh/EEbm1mudHt4SljlmeUvsGB+j+S3/SDr2YXPtzmAwP LsmpoGy27xUsRojnkPkYlOS1juHFl6+Hu0BP471TR5RjANjtrJIvhxgljh5YWSJN mXtiYWMO/B1a7mIn+LX1n1uj03ObBNB5T3xyUjMlG6v7C9ZXCnCc+PGZmz57DdYD Hp3Goladhn1ZUVWgQPzy4KP66miSvikXK+mWY4VY8f+fAgUao1Ki9hGlNd9Hb57Q 019nSCXa+zs9pW5maMlwzOR8G7hy0f065HIR5iMg/Zf24HAvlJ3pV6kDJX6J+FUw ISo7H0NtxO2P7GS3aXG2mbrxGI4shLAX/FrbNw7UGuncNGDL8icmAn0NHo4Vc1dy cCL/1pNvKA7JRVi7cBT4ax0JAQtnfSUOtpdpL3zYrpbL80aTMU/Zqd93FV0er6+J hkq0ZiW4tIhyJOyrcG9D5rLvqLKf65vG9q/BpC9IpfTv0lcQVRtMk35XNen2oVAA rXqeR6Q1w93g+4EkLB42 =nS5k -----END PGP SIGNATURE----- --Rnz0oC2K6vQ5doJs-- From nobody Mon Mar 28 11:06:12 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2423D12D121 for ; Mon, 28 Mar 2016 11:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a8Cio26Fs8G for ; Mon, 28 Mar 2016 11:06:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7501512D1CD for ; Mon, 28 Mar 2016 11:06:04 -0700 (PDT) Received: from [192.168.2.129] ([188.109.66.9]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MMCFR-1aepKG2FvZ-007ynB for ; Mon, 28 Mar 2016 20:06:01 +0200 To: cellar@ietf.org References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> <18E69030-167D-4A3E-953D-86BB3205F39A@dericed.com> <20160328155227.GQ7792@bunkus.org> From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <56F97286.6070001@gmx.de> Date: Mon, 28 Mar 2016 20:05:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160328155227.GQ7792@bunkus.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:g0sqmbklQa+CRDP65Gr73XOcY0VnkZ8+vWtGSMU3I2pzT++R1c5 iHyJtYGDoqIWHgQsTu8AKff9CWhWSAch7cAqrWU7otGQcwEiCR9V+Ifm6VsQdzDTG1GiKZK fvYFFjMUc7B0gigIVoIYOfKd7LlEluru79+BTJThr4J7A5+o30+9NGrVv1TTpnQ1/+vA+aq A/AOqqTwSHWJW8TOt9apw== X-UI-Out-Filterresults: notjunk:1;V01:K0:xoeCsQK909k=:9Yf8PcOM887iLdAcxLBK3J pHywU3KePC/GF7Z/a3cdvaTyubnyx7hDL7PVS2gXKM0btX4al+IHX9m0LT2Ivp8aBWI+eD2th 76EGgNyNj6VVlGultIIp7VXpuPF4NU1L/Gy8m/sVjetyhAWE2yuPPUS9nZx/ksowVvignp7Sk qD4rJ2D+aaTEFq316iUGjfVOrPpJdPfhjGeb1X0hK3tKTH+Yyn6ugk7+bfZ5ZdDyuJm8aYi6x TGHFf2V1qPSqYerJoflWAMmMsi7efH0VCFTUEukG/T5Qv+2SpbepLpUxb67OCYg/4HfKuCEWZ WxJbc3P6lHNcaayL7BdQPkSnl7d3YkyZPJ1MLIaZ87j2P/2YEYrQC7XUpIxGCdAkkf0nb1JDr 6vwq+6bQmamFH63p8eCi15D56WRI0baH12e40UPevlWaQuWq2y8RYLqswMeDA/kUwaPskhaKu t82Hei9v6dBlt+g+8xh6jcfXvMY2cgPvo3p1DUKwcDBNNR9OXQTNY7FrnNAMtCtS6/iRi34ai KyBUDX96yJL6uy+91yq3Kgf2mv92KxFtQ/d9ICO8I4YYZO8ICXSzRDlJeAHdZzzLQTmrpfc8W n16sU3MfWYDl0a+w0yQkqrXN/KZwTbdkeR8eVT6Ya5M8kc4A3rSuCcxhSIKzNOx77xnWhOCc4 GOkU3JKPz2TH3bl+q4Ys5y+YW+6Y5DqLhGVFG4+b4YgWdLecJzye6MjDcBS9SxCTY7tG08oIT 4m33KTAwK9dvK26Hu+cIBofezuf4yIHzreGvTPNRm9WD0X6rNAKDPubFkNxS55ZS9GGgpzcS5 /qDNoBA Archived-At: Subject: Re: [Cellar] Matroska Attachments 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, 28 Mar 2016 18:06:10 -0000 28.03.2016, 17:52 Moritz Bunkus: > Hey, > >> Presently an attached file in Matroska is only described with a >> FileName, mimetype, and description. There is no permissions, uid, >> gid, modification timestamps, etc. So IIUC there no method to clarify >> if an attached file is executable or not. >> >> Perhaps the specifications should clarify though, if any permissions >> should be presumed of an attachment. For instance if a parser exports >> the Attachment back to a file, what defaults should be used for >> permissions and other file attributes. > > I don't think that it's our (the spec's) job to specify how local system > security should be managed. This would be a slippery slope. We're not > security experts, and security is one of those fields someone has to be > really knowledgeable to get it right. > > I also don't see the point in making any kind of rules from our > side. There are use cases across the whole board regarding system > security: from not using any attachments at all; over keeping them in a > temporary location only accessible to the current user and deleting them > right after playback; to asking the user if she wants to install the > fonts extracted from the attachments into the system's font database. It > should not be up to the specs to make any kind of assumption here. I agree with the two paragraphs above. With the addition of recommending to handle attachments in a safe way. Without trying to police it in any way. This has to be up to the system handling Matroska files and attachments. For example, Email in itself does not restrict what I do with attachments, some servers or mail-clients however, do restrict me. The same could apply to Matroska, in theory I could attach anything to it, but I have to live with restrictions, which are enforced by software handling such files. If someone chooses to parse an attached PDF while also supporting the full PDF specifications s/he has to be sure to understand the implications, like that PDF flies can contain flash. > The specs should mention attachments and the various attack vectors in > any future RFC's security section, of course. Indeed that should be the case. > I wouldn't track file attributes either. Let's see what kind of > attributes there are and whether or not it makes sense to include them: > > - IDs of owning user/group: completely meaningless outside of origin's > system/domain > - Names of owning user/group: just as meaningless outside of origin's > system/domain > - Read-only, read/write: meaningless outside of origin's security zone > - Immutable: dito > - Executable: dangerous and prone to confusion with the MIME type. What > if an attachment of MIME type text/plain is marked executable? Doesn't > make sense, now does it? And what about different platforms? An > attachment of MIME type application/x-dosexec on Linux? I also see very little, if any, gain in transporting those information inside a Matroska file. It might be interesting to have a read-only flag for an attachment to signal that it shouldn't be altered. But again, I think it shouldn't be policed. I got told, that on Linux binaries (or files in general) saved with Thunderbird don't have the executable flag. The user or some application would have to do that. Might be worth to recommend such a behavior, again without policing it. On Windows there is no execution flag anyway. > MIME types should be enough for a reader to figure out whether or not an > attachment has any business of being executable on the current platform. I agree that a reader should use the MIME type as an indicator to what the file is supposed to be. It should not blindly trust that the MIME type is correct. It is up to the software handling the attachment to ensure that it is what it is supposed to be. Not like reading an attachment that is supposed to be a font, but is in fact some executable that then gets executed. Out of my head I can't see why a reader would execute an attached executable, while I still see a reason to attach an executable. Currently, I hope any reader would not execute something without having a very good reason for it (I currently can't think of one), because I think no one would implement it in such a way. (I'm sure someone will prove me wrong, at some point in time.) You can have recommendations on how to handle attachments, but I don't see a way to enforce some kind of policy. > Kind regards, > mosu > Best regards, Sebastian From nobody Mon Mar 28 11:13:16 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 9358712D523 for ; Mon, 28 Mar 2016 11:13:14 -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 5RsVDIAOwg8m for ; Mon, 28 Mar 2016 11:13:12 -0700 (PDT) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0878312D1E9 for ; Mon, 28 Mar 2016 11:13:12 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 86F5CC06C6 for ; Mon, 28 Mar 2016 18:13:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj5EMuxgyDmN for ; Mon, 28 Mar 2016 18:13:11 +0000 (UTC) Received: from [10.252.25.7] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 71FA8BFF50 for ; Mon, 28 Mar 2016 18:13:11 +0000 (UTC) Message-ID: <56F97437.7090208@xiph.org> Date: Mon, 28 Mar 2016 11:13:11 -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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed 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, 28 Mar 2016 18:13:14 -0000 Steve Lhomme wrote: >> I’ll leave this to WG Chairs, Steve, and Moritz and whomever contributes 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. Are you planning to submit this as an internet-draft? From nobody Mon Mar 28 12:37: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 3C73512DB18 for ; Mon, 28 Mar 2016 12:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85zVUAtaXVDo for ; Mon, 28 Mar 2016 12:37:34 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DCB312D118 for ; Mon, 28 Mar 2016 12:37:34 -0700 (PDT) Received: from mfilter34-d.gandi.net (mfilter34-d.gandi.net [217.70.178.165]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 8F875A80C0 for ; Mon, 28 Mar 2016 21:37:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter34-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter34-d.gandi.net (mfilter34-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 409jPa2m9q9V for ; Mon, 28 Mar 2016 21:37:31 +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 relay3-d.mail.gandi.net (Postfix) with ESMTPSA id E23D7A80C7 for ; Mon, 28 Mar 2016 21:37:30 +0200 (CEST) Date: Mon, 28 Mar 2016 21:36:17 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160328193617.GB25812@nb4> References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> <18E69030-167D-4A3E-953D-86BB3205F39A@dericed.com> <20160328155227.GQ7792@bunkus.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50" Content-Disposition: inline In-Reply-To: <20160328155227.GQ7792@bunkus.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] Matroska Attachments 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, 28 Mar 2016 19:37:36 -0000 --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 28, 2016 at 05:52:27PM +0200, Moritz Bunkus wrote: > Hey, >=20 > > Presently an attached file in Matroska is only described with a > > FileName, mimetype, and description. There is no permissions, uid, > > gid, modification timestamps, etc. So IIUC there no method to clarify > > if an attached file is executable or not. > > > > Perhaps the specifications should clarify though, if any permissions > > should be presumed of an attachment. For instance if a parser exports > > the Attachment back to a file, what defaults should be used for > > permissions and other file attributes. >=20 > I don't think that it's our (the spec's) job to specify how local system > security should be managed. This would be a slippery slope. We're not > security experts, and security is one of those fields someone has to be > really knowledgeable to get it right. >=20 > I also don't see the point in making any kind of rules from our > side. There are use cases across the whole board regarding system > security: from not using any attachments at all; over keeping them in a > temporary location only accessible to the current user and deleting them > right after playback; to asking the user if she wants to install the > fonts extracted from the attachments into the system's font database. It > should not be up to the specs to make any kind of assumption here. >=20 > The specs should mention attachments and the various attack vectors in > any future RFC's security section, of course. The specs could list a "core" set of attachment mime types that are recommanded to be supported. That would make it easier for applications generating files to know what can be put in that is likely going to be interpreted and applications on the receiving end to know what minium set makes sense to support. (or looking at it from the other side what mime types can be ignored to minimize the attack surface without impacting the majority of uses) [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlb5h7EACgkQYR7HhwQLD6vfWQCfUB2z+Ft7imUMZFfmE930WmuX uUIAoIK6FkJG1/GODCgM8hDiVMgnpBkP =Z62+ -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50-- From nobody Mon Mar 28 14:26:03 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 E297112D553 for ; Mon, 28 Mar 2016 14:26:01 -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 nxebMJqDVVW3 for ; Mon, 28 Mar 2016 14:25: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 85DC812D4FD for ; Mon, 28 Mar 2016 14:25:59 -0700 (PDT) Received: from [146.96.19.240] (port=18912 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 1akefb-003nAm-M2; Mon, 28 Mar 2016 17:25:58 -0400 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BA5F2258-4AAC-4329-8252-150A99A1DFFB"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Dave Rice In-Reply-To: <20160328193617.GB25812@nb4> Date: Mon, 28 Mar 2016 17:25:53 -0400 Message-Id: <91CD1376-274D-456B-BB57-0B981CB7A54F@dericed.com> References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> <18E69030-167D-4A3E-953D-86BB3205F39A@dericed.com> <20160328155227.GQ7792@bunkus.org> <20160328193617.GB25812@nb4> To: Michael Niedermayer 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] Matroska Attachments 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, 28 Mar 2016 21:26:02 -0000 --Apple-Mail=_BA5F2258-4AAC-4329-8252-150A99A1DFFB Content-Type: multipart/alternative; boundary="Apple-Mail=_3D64EC99-33ED-417B-A582-B7E035ED469E" --Apple-Mail=_3D64EC99-33ED-417B-A582-B7E035ED469E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 28, 2016, at 3:36 PM, Michael Niedermayer = wrote: >=20 > On Mon, Mar 28, 2016 at 05:52:27PM +0200, Moritz Bunkus wrote: >> Hey, >>=20 >>> Presently an attached file in Matroska is only described with a >>> FileName, mimetype, and description. There is no permissions, uid, >>> gid, modification timestamps, etc. So IIUC there no method to = clarify >>> if an attached file is executable or not. >>>=20 >>> Perhaps the specifications should clarify though, if any permissions >>> should be presumed of an attachment. For instance if a parser = exports >>> the Attachment back to a file, what defaults should be used for >>> permissions and other file attributes. >>=20 >> I don't think that it's our (the spec's) job to specify how local = system >> security should be managed. This would be a slippery slope. We're not >> security experts, and security is one of those fields someone has to = be >> really knowledgeable to get it right. >>=20 >> I also don't see the point in making any kind of rules from our >> side. There are use cases across the whole board regarding system >> security: from not using any attachments at all; over keeping them in = a >> temporary location only accessible to the current user and deleting = them >> right after playback; to asking the user if she wants to install the >> fonts extracted from the attachments into the system's font database. = It >> should not be up to the specs to make any kind of assumption here. >>=20 >> The specs should mention attachments and the various attack vectors = in >> any future RFC's security section, of course. >=20 > The specs could list a "core" set of attachment mime types that > are recommanded to be supported. +1 > That would make it easier for applications generating files to know > what can be put in that is likely going to be interpreted and > applications on the receiving end to know what minium set makes sense > to support. (or looking at it from the other side what mime types > can be ignored to minimize the attack surface without impacting the > majority of uses) For a whitelist we could use: text/* image/* video/* application/pdf application/xml ? I've had trouble locating existing Matroska files with Attachments. The = Internet Archive has ~90,000 matroska files and has been my largest = sample set, but none of them use attachments. The primary examples of = attachments I've seen come from samples.ffmpeg.org. Are there any other = online collections of matroska files that may include attachments that I = could analyze? Dave Rice --Apple-Mail=_3D64EC99-33ED-417B-A582-B7E035ED469E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 28, 2016, at 3:36 PM, Michael Niedermayer <michael@niedermayer.cc> wrote:

On Mon, Mar 28, 2016 at 05:52:27PM +0200, Moritz = Bunkus wrote:
Hey,

Presently = an attached file in Matroska is only described with a
FileName, mimetype, and description. There is no permissions, = uid,
gid, modification timestamps, etc. So IIUC there no = method to clarify
if an attached file is executable or = not.

Perhaps the specifications should = clarify though, if any permissions
should be presumed of = an attachment. For instance if a parser exports
the = Attachment back to a file, what defaults should be used for
permissions and other file attributes.

I don't think that it's our (the = spec's) job to specify how local system
security should be = managed. This would be a slippery slope. We're not
security = experts, and security is one of those fields someone has to be
really knowledgeable to get it right.

I also don't see the point in making any kind of rules from = our
side. There are use cases across the whole board = regarding system
security: from not using any attachments = at all; over keeping them in a
temporary location only = accessible to the current user and deleting them
right = after playback; to asking the user if she wants to install the
fonts extracted from the attachments into the system's font = database. It
should not be up to the specs to make any = kind of assumption here.

The specs should = mention attachments and the various attack vectors in
any = future RFC's security section, of course.

The specs could list a = "core" set of attachment mime types that
are recommanded to be = supported.

+1

That would make it easier for applications = generating files to know
what can be put in that is likely going to be = interpreted and
applications on the receiving end to know what = minium set makes sense
to support. (or looking at it from the other = side what mime types
can be ignored to minimize the attack surface = without impacting the
majority of = uses)

For a whitelist we could use:
text/*
image/*
video/*
application/pdf
application/xml
?

I've had trouble locating = existing Matroska files with Attachments. The Internet Archive has = ~90,000 matroska files and has been my largest sample set, but none of = them use attachments. The primary examples of attachments I've seen come = from samples.ffmpeg.org. Are there any other online = collections of matroska files that may include attachments that I could = analyze?
Dave Rice


= --Apple-Mail=_3D64EC99-33ED-417B-A582-B7E035ED469E-- --Apple-Mail=_BA5F2258-4AAC-4329-8252-150A99A1DFFB 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----- iQIcBAEBCAAGBQJW+aFiAAoJEIlM1Sx2ptr5frkP/jSqgBQyVX5a14MzeRAjCiUm xeXmdD0WadnS+E9k73pIlBYHXTRNO9gIr7KKuL/cpoFcJxEt6awmws+JrKs0VMyh NA0dgSFWil33hj5qR3dLvvROzh1JU+6CMQaqC2e4I3Ig4HacAXJi6P7GI48sF3pS oQ4a63C0d8MzthwUsYGB+/VNafwNSX6QOGIGXkqHtd4T3OApxMZjeJx4O5TSTY8N rb5fQ2E4kcb/dezsJ9PEGPUn12Dn0sbPJ4X9/BjedyC24UdwvI5NVFxPUrEZqcxG 7Kb/9XVMKmJGrBJnr3+ANFZ6boSYmCyeldWCZFgkijxrn+pLaAOMBuMgF485gRMs F/mo8mp8s8uYuquvDAbxfLDhWm10O5TTzJ3fqrbvrvQ+a8R7tNvwKA5ZfILIy6hL UD0JoYKY8C5eedCsWFkv+W4KUJuA+A/hYbBE5F4q7i3Kp1XL/S6c6S/OV35PltwG mUxj7upNQk6tOKxM1uO2SqwFHFNH9Gosf15IFxaaty/A2U+GPnfFeAgc97yvU3qd TS55J6tzYNmQyX1/S4yvhd9sv6HCGdJ8ioMslSYLLJL+iy5gBnfqiPa7EoADT3Tv XhdOx+VR0C4fmDis57xCgliAXxnAx2XsYuetJGXNAbDZzwHDxz72zHMfPmVCkHAx 9gqHIzIFfJ51nmPjKgog =VL6e -----END PGP SIGNATURE----- --Apple-Mail=_BA5F2258-4AAC-4329-8252-150A99A1DFFB-- From nobody Tue Mar 29 05:46:44 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 6513112DDB8 for ; Tue, 29 Mar 2016 05:46:42 -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 K6EVhR_UYIN8 for ; Tue, 29 Mar 2016 05:46:38 -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 3748612D17D for ; Tue, 29 Mar 2016 05:46:25 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:40777 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 1akt2J-000h8Q-At; Tue, 29 Mar 2016 08:46:23 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <20160329102352.216ec3bc@debian> Date: Tue, 29 Mar 2016 08:46:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160329102352.216ec3bc@debian> To: FFmpeg development discussions and patches 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] [FFmpeg-devel] [PATCH] lavf/matroskadec: Demux the PixelCrop* values 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, 29 Mar 2016 12:46:42 -0000 Hi, > On Mar 29, 2016, at 4:23 AM, wm4 wrote: >=20 > On Sat, 26 Mar 2016 16:56:55 -0600 > Nic Wolfe wrote: >=20 >> The Matroska spec defines PixelCropTop, PixelCropBottom, = PixelCropLeft, >> and PixelCropRight elements: = https://www.matroska.org/technical/specs/index.html >>=20 >> This commit adds support for demuxing these values so that >> applications using libav* >> are able to use them when playing the stream. They're added to the = AVStream's >> metadata if they are set to something non-zero. >>=20 >>=20 >> My official patch is base64 encoded and attached but I will also >> include the diff below for (hopefully) convenience. >>=20 >=20 > To elaborate on why this change is bad (in its current state): >=20 > - It's not clearly defined what the pixelcrop fields mean. Do they > operate before or after aspect rasto is applied? Do they affect > aspect ratio calculation? What if aspect ratio or video size change > later? Does it get applied after h264 bitstream cropping, does it > override it? AFAIK these issues were also discussed on the cellar > mailing list, but I didn't follow it. It was discussed on CELLAR but not patched yet. At the moment, the best = clarification is from Steve Lhomme in this post = https://mailarchive.ietf.org/arch/search/?email_list=3Dcellar&q=3Ddisplay+= area+question: "Yes, the cropping happens on the pixels, the display = size are just how to display those remaining pixels.=E2=80=9D So the = pixelcrop is applied before the aspect ratio. AFAIK there is no determination as to how h264 bitstream cropping and = Matroska cropping should be prioritized (cc=E2=80=99ing CELLAR on this). I think the PixelCrop documentation also needs to consider handling in = video stereo modes. > - There should generally be a concept at least in libavformat's API = how > to handle cropping. For example, it could be some sort of = well-defined > AVStream side data. (Personally I'd be a fan of adding it to AVFrame > too. There's no way around if it should work for hw decoding.) > - Worst of all: it's exported as generic metadata. This means that: > - API users could start interpreting the same metadata fields for > other formats than Matroska too > - Transcoders like ffmpeg CLI will copy the crop metadata to other > containers (as normal metadata). > - Non-Matroska files might be created that contain the "made > up" libavformat Matroska demuxer metadata, and the creator of the > file expects that programs respect it. > (Something like this almost happened with the "old" libavformat > rotation metadata, which is also exported as normal metadata.) >=20 > While just adding a "hack" to export metadata for essentially 1 API > user might be acceptable if adding "proper" API is too hard for now, = at > least the last point needs to be fixed. I also support a demuxer option to allow pixelcrop to be ignored. Best Regards, Dave Rice= From nobody Tue Mar 29 08:22:17 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36ABC12D930 for ; Tue, 29 Mar 2016 08:22:16 -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 TNB5U1dtkliD for ; Tue, 29 Mar 2016 08:22:14 -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 3F3FC12D946 for ; Tue, 29 Mar 2016 08:21:49 -0700 (PDT) Received: from [146.96.19.240] (port=30301 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 1akvSf-000dhT-3u; Tue, 29 Mar 2016 11:21:47 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_15070451-5524-41F1-B51B-743F250F106D" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <20160328193617.GB25812@nb4> Date: Tue, 29 Mar 2016 11:21:39 -0400 Message-Id: <95199A2E-8442-40D6-A275-5D5598F07F87@dericed.com> References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> <18E69030-167D-4A3E-953D-86BB3205F39A@dericed.com> <20160328155227.GQ7792@bunkus.org> <20160328193617.GB25812@nb4> To: Michael Niedermayer 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] Matroska Attachments 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, 29 Mar 2016 15:22:16 -0000 --Apple-Mail=_15070451-5524-41F1-B51B-743F250F106D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 28, 2016, at 3:36 PM, Michael Niedermayer = > wrote: >=20 > On Mon, Mar 28, 2016 at 05:52:27PM +0200, Moritz Bunkus wrote: >> Hey, >>=20 >>> Presently an attached file in Matroska is only described with a >>> FileName, mimetype, and description. There is no permissions, uid, >>> gid, modification timestamps, etc. So IIUC there no method to = clarify >>> if an attached file is executable or not. >>>=20 >>> Perhaps the specifications should clarify though, if any permissions >>> should be presumed of an attachment. For instance if a parser = exports >>> the Attachment back to a file, what defaults should be used for >>> permissions and other file attributes. >>=20 >> I don't think that it's our (the spec's) job to specify how local = system >> security should be managed. This would be a slippery slope. We're not >> security experts, and security is one of those fields someone has to = be >> really knowledgeable to get it right. >>=20 >> I also don't see the point in making any kind of rules from our >> side. There are use cases across the whole board regarding system >> security: from not using any attachments at all; over keeping them in = a >> temporary location only accessible to the current user and deleting = them >> right after playback; to asking the user if she wants to install the >> fonts extracted from the attachments into the system's font database. = It >> should not be up to the specs to make any kind of assumption here. >>=20 >> The specs should mention attachments and the various attack vectors = in >> any future RFC's security section, of course. >=20 > The specs could list a "core" set of attachment mime types that > are recommanded to be supported. +1 > That would make it easier for applications generating files to know > what can be put in that is likely going to be interpreted and > applications on the receiving end to know what minium set makes sense > to support. (or looking at it from the other side what mime types > can be ignored to minimize the attack surface without impacting the > majority of uses) For a whitelist we could use: text/* image/* video/* application/pdf application/xml others? I've had trouble locating existing Matroska files with Attachments. The = Internet Archive has ~90,000 matroska files and has been my largest = sample set, but none of them use attachments. The primary examples of = attachments I've seen come from samples.ffmpeg.org = . Are there any other online collections of = matroska files that may include attachments that I could analyze? Dave Rice --Apple-Mail=_15070451-5524-41F1-B51B-743F250F106D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 28, 2016, at 3:36 PM, Michael = Niedermayer <michael@niedermayer.cc> wrote:

On Mon, Mar 28, 2016 at 05:52:27PM +0200, Moritz = Bunkus wrote:
Hey,

Presently = an attached file in Matroska is only described with a
FileName, mimetype, and description. There is no permissions, = uid,
gid, modification timestamps, etc. So IIUC there no = method to clarify
if an attached file is executable or = not.

Perhaps the specifications should = clarify though, if any permissions
should be presumed of = an attachment. For instance if a parser exports
the = Attachment back to a file, what defaults should be used for
permissions and other file attributes.

I don't think that it's our (the = spec's) job to specify how local system
security should be = managed. This would be a slippery slope. We're not
security = experts, and security is one of those fields someone has to be
really knowledgeable to get it right.

I also don't see the point in making any kind of rules from = our
side. There are use cases across the whole board = regarding system
security: from not using any attachments = at all; over keeping them in a
temporary location only = accessible to the current user and deleting them
right = after playback; to asking the user if she wants to install the
fonts extracted from the attachments into the system's font = database. It
should not be up to the specs to make any = kind of assumption here.

The specs should = mention attachments and the various attack vectors in
any = future RFC's security section, of course.

The specs could list a = "core" set of attachment mime types that
are recommanded to be = supported.

+1

That would make it easier for = applications generating files to know
what can be put in that is likely going = to be interpreted and
applications on the receiving end to know what = minium set makes sense
to support. (or looking at it from the other = side what mime types
can be ignored to minimize the attack surface = without impacting the
majority of = uses)

For a whitelist we could use:
text/*
image/*
video/*
application/pdf
application/xml
others?

I've had = trouble locating existing Matroska files with Attachments. The Internet = Archive has ~90,000 matroska files and has been my largest sample set, = but none of them use attachments. The primary examples of attachments = I've seen come from samples.ffmpeg.org. Are there any other online = collections of matroska files that may include attachments that I could = analyze?
Dave Rice


= --Apple-Mail=_15070451-5524-41F1-B51B-743F250F106D-- From nobody Tue Mar 29 09:00:58 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983B912DA43 for ; Tue, 29 Mar 2016 09:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrAtN5v1yW0X for ; Tue, 29 Mar 2016 09:00:52 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA67D12DA21 for ; Tue, 29 Mar 2016 08:58:57 -0700 (PDT) Received: from [146.96.19.240] (port=27908 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 1akw2e-001XAU-6l; Tue, 29 Mar 2016 11:58:56 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <56F97437.7090208@xiph.org> Date: Tue, 29 Mar 2016 11:58:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2C8E9DA4-C7BE-47F4-AA26-3AA6D8A99163@dericed.com> References: <661BB32C-E74B-4E60-AC62-7BF103D8648A@dericed.com> <442FEE5C-FCE3-4966-AFA0-CF6159E79C39@dericed.com> <56F97437.7090208@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: Tue, 29 Mar 2016 16:00:56 -0000 > On Mar 28, 2016, at 2:13 PM, Timothy B. Terriberry = wrote: >=20 > Steve Lhomme wrote: >>> I=E2=80=99ll leave this to WG Chairs, Steve, and Moritz and whomever = contributes 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). >>=20 >> IMO yes, EBML is in a good shape now. >=20 > Are you planning to submit this as an internet-draft? I think the EBML specification, as seen at = https://github.com/MediaArea/ebml-specification/blob/master/specification.= markdown, is about ready for a more thorough review. There are a few = remaining issues that I can see: - finishing defining how to express ranges in an EBML Schema for float = elements. I suppose we need the same rules for expressing a default. - Define how to express a conditional or equation as a default value or = range in an EBML Schema; for instance I think that saying BlockDuration = should default to DefaultDuration is not specific enough, but should = explain the relationship between these two elements. It would have to be = something like ../../Tracks/TrackEntry/DefaultDuration, though perhaps = even this isn't clear enough because the correct TrackEntry must be = selected. - We could probably use a better style for presenting an EBML Element = definition than the style currently used at = https://github.com/MediaArea/ebml-specification/blob/master/specification.= markdown#ebml-header-elements. There may be a few other open issues, but probably not very many. Tim, how 'done' should we be before submitting as a draft? Dave Rice= From nobody Tue Mar 29 09:16:48 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0612712D994 for ; Tue, 29 Mar 2016 09:16:47 -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 C8PVaAaN0Gon for ; Tue, 29 Mar 2016 09:16:44 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 D2CC412DA78 for ; Tue, 29 Mar 2016 09:12:13 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id h6so28880396oia.2 for ; Tue, 29 Mar 2016 09:12:13 -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=+c1pgiKuHZ09soAS/SG26XHay/ylYyEtntrCSj6+4zw=; b=LcglwxaAVyvjyO877NOK4hAQqZJX4C0G3N5Dd57sbAAGgBVIOtZ5QXzXyYqLZOMtYH P45TC+7PJlR4wvSGZZGe7Km7zORMRYUZfSCnBsGkF1ZQGYp33pKKAqzujT3AmWzUAvG8 w+ecVX6+iMZOeHXkk9xW0ARQ7XzYp7qcxabDceJAtb1pyiHzFSHEwgRwUYvJwhAjJxtg LSabbgwMpc/ZUQt2Ugo35asP/LnWMBRS87FbNmd2AwsELcpep2U3eKTcQ9O1q7BcLhUw 0ju9sOz+DuFAP0DTE9kfASIP0KPMQ9iApmX8KQNaNDvHmxCtxRTWjtrY6V0Oe0x1IkOy GE7Q== 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=+c1pgiKuHZ09soAS/SG26XHay/ylYyEtntrCSj6+4zw=; b=mPgGBWJQQwMdR4Wh4JYIq9myPzV9FdLtgNtFqin4v5/EqsikILhGgYJhGe3ljiXc/9 k6Nk75p4gGSXI1sDdPBPnGEGGDA4gI/E2iTmjCVsRKQhX+GD93X/SupnWRS5Y51A9Yqi STpcdaj9QcAk4HVhPoD+xSKFbVrQhs2/evB7vkCxwsURaEdWx88/TL5YEonPLX8GWSEG cVYbgzKoaCrvXZSKXPigRidu9U8tY/+YhQ9NqiTrnVaKBJavcT/9wFjTNqNmapFuPfLl D8KYqT6gw6g8i/UPawLGAb8GeEfR+PgnOUhZGbGZzqP05oV/lqdn/5OxV4Cb+E5I7T9T fWEA== X-Gm-Message-State: AD7BkJINu6qHX80GljcYq5YSX8mh6VvdZjXoTcxHRtvzGD+6vbSMj4HKZ+yd/5HmnAha4gpA26tSlB9s0k9koA== MIME-Version: 1.0 X-Received: by 10.157.24.1 with SMTP id b1mr1598315ote.142.1459267912556; Tue, 29 Mar 2016 09:11:52 -0700 (PDT) Received: by 10.202.49.65 with HTTP; Tue, 29 Mar 2016 09:11:52 -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: Tue, 29 Mar 2016 09:11:52 -0700 Message-ID: From: Frank Galligan To: Steve Lhomme Content-Type: multipart/alternative; boundary=001a1141bd5a8f74c0052f3249d5 Archived-At: Cc: Michael Niedermayer , Jerome Martinez , cellar@ietf.org, Discussion about the current and future development of Matroska , Dave Rice 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: Tue, 29 Mar 2016 16:16:47 -0000 --001a1141bd5a8f74c0052f3249d5 Content-Type: text/plain; charset=UTF-8 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? > > Next what are we missing and what do you think we need to add to support > the > > formats? > > > > > > Would adding interlaced and horizontal flip elements be enough to support > > the 4:2:0 that people are using today? > >> > >> > >> [...] > >> > >> -- > >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > >> > >> No snowflake in an avalanche ever feels responsible. -- Voltaire > > > > > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > -- > Steve Lhomme > Matroska association Chairman > --001a1141bd5a8f74c0052f3249d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 28, 2016 at 5:05 AM, Steve Lhomme <slhomme@matroska.org= > wrote:
2016-03-17 5:46 GMT+01:00 Frank Galligan <frankgalligan@gmail.com>:
> OK really no comments for a long time.
>
> On Fri, Feb 19, 2016 at 1:45 PM, Michael Niedermayer
> <michael@niedermayer.cc> 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:=C2=A0 =C2=A0 =C2=A0 =C2=A0 4
>> >
>> > ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B0]
>> >
>> > Mandatory:=C2=A0 =C2=A0 -
>> >
>> > Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >
>> > Default:=C2=A0 =C2=A0 =C2=A0 -
>> >
>> > Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m
>> >
>> > Description:=C2=A0 Settings describing the colour format.
>> >
>> >
>> > Element Name: MatrixCoefficients
>> >
>> > Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >
>> > ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B1]
>> >
>> > Mandatory:=C2=A0 =C2=A0 -
>> >
>> > Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >
>> > Default:=C2=A0 =C2=A0 =C2=A0 2
>> >
>> > Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >
>> > Description:=C2=A0 The Matrix Coefficients of the video used = to derive luma
>> > and
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 chroma values= from reg, green, and blue color primaries.
>> > For
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clarity, the = value and meanings for MatrixCoefficients are
>> > adopted
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from Table 4 = of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1:
>> > BT709,
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2: Unspecifie= d, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE
>> > 170M,
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7: SMPTE 240M= , 8: YCOCG, 9: BT2020 Non-constant Luminance,
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10: BT2020 Co= nstant Luminance)
>> >
>> >
>>
>> > Element Name: BitsPerChannel
>> >
>> > Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >
>> > ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B2]
>> >
>> > Mandatory:=C2=A0 =C2=A0 -
>> >
>> > Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >
>> > Default:=C2=A0 =C2=A0 =C2=A0 0
>> >
>> > Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >
>> > Description:=C2=A0 Number of decoded bits per channel. A valu= e of 0 indicates
>> > that
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the BitsPerCh= annel 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 als= o
> worked with formats like RGBBGR repeating.
>>
>>
>>
>> [...]
>>
>> > Element Name: CbSubsamplingHorz
>> >
>> > Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >
>> > ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B5]
>> >
>> > Mandatory:=C2=A0 =C2=A0 -
>> >
>> > Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >
>> > Default:=C2=A0 =C2=A0 =C2=A0 -
>> >
>> > Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >
>> > Description:=C2=A0 The amount of pixels to remove in the Cb c= hannel for every
>> > pixel
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not removed h= orizontally. This is additive with
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ChromaSubsamp= lingHorz. Example: For video with 4:2:1 chroma
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 subsampling, = the ChromaSubsamplingHorz should be set to 1
>> > and
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CbSubsampling= Horz should be set to 1.
>> >
>> >
>> > Element Name: CbSubsamplingVert
>> >
>> > Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >
>> > ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B6]
>> >
>> > Mandatory:=C2=A0 =C2=A0 -
>> >
>> > Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >
>> > Default:=C2=A0 =C2=A0 =C2=A0 -
>> >
>> > Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >
>> > Description:=C2=A0 The amount of pixels to remove in the Cb c= hannel for every
>> > pixel
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not removed v= ertically. This is additive with
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ChromaSubsamp= lingVert.
>>
>> What if Cr is subsampled more than Cb ?
>> That too is rather obscure, but theres code in FFmpeg to handle su= ch
>> jpegs, so i suspect this case while very rare is not entirely non<= br> >> existent ...
>
>
> I guess we can add that as well if more people really want it. Actuall= y I
> didn't even have CbSubsampling* elements at first. I only added th= at to
> support the 4:2:1 format that was defined in the first enum.
>>
>>
>>
>> >
>> >
>> > Element Name: ChromaSitingHorz
>> >
>> > Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >
>> > ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B7]
>> >
>> > Mandatory:=C2=A0 =C2=A0 -
>> >
>> > Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >
>> > Default:=C2=A0 =C2=A0 =C2=A0 0
>> >
>> > Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >
>> > Description:=C2=A0 How Chroma is subsampled horizontally. (0:= Unspecified, 1:
>> > Left
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collocated , = 2: Half)
>> >
>> > Element Name: ChromaSitingVert
>> >
>> > Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >
>> > ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][B8]
>> >
>> > Mandatory:=C2=A0 =C2=A0 -
>> >
>> > Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >
>> > Default:=C2=A0 =C2=A0 =C2=A0 0
>> >
>> > Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >
>> > Description:=C2=A0 How Chroma is subsampled vertically. (0: U= nspecified, 1:
>> > Top
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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 fli= ped
>> 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 forma= t 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<= br> > produced today. Opinions?

The problem is that when you leave 1% out, you need to be sure it= 9;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<= br> covering it. That's just a general remark though.
= I don't want to exclude anything in the future, but I also don't wa= nt to make something overly complex/over specified to support a format that= will barely see any use.

I want to move forward w= ith 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. j= peg Cr subsampled more than Cb
9.=C2=A0non-linear color values (D= PX scans)

Anything else we should add?
<= br>


> Next what are we missing and what do you think we need to add to suppo= rt the
> formats?
>
>
> Would adding interlaced and horizontal flip elements be enough to supp= ort
> the 4:2:0 that people are using today?
>>
>>
>> [...]
>>
>> --
>> Michael=C2=A0 =C2=A0 =C2=A0GnuPG fingerprint: 9FF2128B147EF6730BAD= F133611EC787040B0FAB
>>
>> No snowflake in an avalanche ever feels responsible. -- Voltaire >
>
>
> _____________________________= __________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar >



--
Steve Lhomme
Matroska association Chairman

--001a1141bd5a8f74c0052f3249d5-- From nobody Tue Mar 29 09:55:54 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A147A12DA0E for ; Tue, 29 Mar 2016 09:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_ziMWqySypR for ; Tue, 29 Mar 2016 09:55:49 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDE212DB74 for ; Tue, 29 Mar 2016 09:47:38 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u2TGkodj024272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 29 Mar 2016 18:46:50 +0200 Received: from Castor.local (85-218-38-132.dclient.lsne.ch [85.218.38.132]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u2TGknjJ025014; Tue, 29 Mar 2016 18:46:49 +0200 Date: Tue, 29 Mar 2016 18:46:49 +0200 From: Reto Kromer To: Frank Galligan X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Cc: Michael Niedermayer , Steve Lhomme , Discussion about the current and future development of Matroska , Jerome Martinez , cellar@ietf.org, Dave Rice 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: Tue, 29 Mar 2016 16:55:52 -0000 =46rank Galligan wrote: >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? >9. non-linear color values (DPX scans) The non-linear world would be very useful - at least for me. 10. Bayer filters. And I am personally a unconditional supporter of YCoCg - for strictly mathematical reasons! - yet I feel often alone. Best regards, Reto AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: http://reto.ch | Twitter: @retoch AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: http://reto.ch | Twitter: @retoch From nobody Tue Mar 29 10:44:53 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C0012DFC7 for ; Tue, 29 Mar 2016 10:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.336 X-Spam-Level: X-Spam-Status: No, score=-4.336 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0yXQkzJPglB for ; Tue, 29 Mar 2016 10:44:41 -0700 (PDT) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A13412DA5C for ; Tue, 29 Mar 2016 10:26:06 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id A83E0C03D7 for ; Tue, 29 Mar 2016 17:26:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlnI2Awnj4YJ for ; Tue, 29 Mar 2016 17:26:05 +0000 (UTC) Received: from [10.252.28.245] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 919BBC0724 for ; Tue, 29 Mar 2016 17:26:05 +0000 (UTC) Message-ID: <56FABAAD.2060003@xiph.org> Date: Tue, 29 Mar 2016 10:26:05 -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> In-Reply-To: <2C8E9DA4-C7BE-47F4-AA26-3AA6D8A99163@dericed.com> Content-Type: text/plain; charset=UTF-8; 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, 29 Mar 2016 17:44:47 -0000 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." From nobody Tue Mar 29 11:16:26 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5783C12E203 for ; Tue, 29 Mar 2016 11:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw-JuEJix_d6 for ; Tue, 29 Mar 2016 11:16:20 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B17B12E049 for ; Tue, 29 Mar 2016 10:52:18 -0700 (PDT) Received: from rrcs-50-74-108-74.nyc.biz.rr.com ([50.74.108.74]:6238 helo=[10.10.20.114]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1akxoI-000KJs-LY; Tue, 29 Mar 2016 13:52:17 -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: <56FABAAD.2060003@xiph.org> Date: Tue, 29 Mar 2016 13:52:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2BE0712A-A849-403E-AA14-3A738F75A890@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> 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: Tue, 29 Mar 2016 18:16:24 -0000 > 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." In that case, here's = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown. dave= From nobody Tue Mar 29 11:36:04 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 E764112DEF1 for ; Tue, 29 Mar 2016 11:36:02 -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 KNNtc6n7L5cK for ; Tue, 29 Mar 2016 11:35:59 -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 B271C12DDCF for ; Tue, 29 Mar 2016 11:07:01 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 14957BFF81 for ; Tue, 29 Mar 2016 17:59:32 +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 joUivW-pwk-W for ; Tue, 29 Mar 2016 17:59:32 +0000 (UTC) Received: from [10.252.28.245] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id F30F1BFD82 for ; Tue, 29 Mar 2016 17:59:31 +0000 (UTC) Message-ID: <56FAC283.7040609@xiph.org> Date: Tue, 29 Mar 2016 10:59:31 -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> In-Reply-To: <2BE0712A-A849-403E-AA14-3A738F75A890@dericed.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, 29 Mar 2016 18:36:03 -0000 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.