From nobody Tue Aug 1 12:38:52 2017 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 C962613215C for ; Tue, 1 Aug 2017 12:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, 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 qXlDeMSV2lhm for ; Tue, 1 Aug 2017 12:38:49 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 1EB3E131C2A for ; Tue, 1 Aug 2017 12:38:49 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id h199so13153075ith.0 for ; Tue, 01 Aug 2017 12:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rq2K0QBJenmshgBa17XsFSl1HpnQ4Uz/PGuiO9Lmn2w=; b=oI1yhSufYUmAeEk6AD4riZKpUaOZ4N9S9GZaxjhTBztpV4XNKtphSxRy2L5jnOofy5 dQtZBfG1h6lcz2tlzsxqJ1Y+M4yQj4QMjY4KxHqc8BFYCQPhC8xc8qefJzHU2GjdZx8S lHb/Pe3KC0wF8NgotmuJ6Dz1yTzEJ+jx/0lYzwDsCs9zNJ5HDfVtCJlxiCuy6IhB6SCD gkAANeUWP3RUBJYD/g13JnuTViAknZNaniJEiBk4IaOT0cgCkdV8g2iebyCL8oeE7TXV 2m/kDzJbAPGOPf93FUvwe9oiTuaZcLXR12H7uhOJGTy4cjcSq9znmhV6dFznCkcHcduP S5Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rq2K0QBJenmshgBa17XsFSl1HpnQ4Uz/PGuiO9Lmn2w=; b=F1SPO+6D5T8wNTRG8+Aw/8mzcdV9vPyBJVNuBEJhx1XiR1Zbo652SJdknmbzyOPm5S 9HIcNx1keWew4oLT+vdvU0qIKtjJHqbQ2/krmEU5r+z2/dIOaBsGoObs3MHyRt/Q7+BU +9kxjztwpLjom18loqoe8Zm1iIT72dSmTcKEDnKeR+XZO0pVhY8c9hCdiAamKuYsALwQ 7+JpUUsRATkMXWey4HsjEOimvvltFy4hhPG0BKDx7ZKvwrjM1UrZFukFsbcfqu1jchUT jov6gMVOZ7Bn9Rx6h819D2zFjVOBxSqNtEcLOITyBrFHk8XR6LvVtw3AhXT3vyvXiJ3L 3c1Q== X-Gm-Message-State: AIVw113fRT7lriM5iG+oFX77lMNcjC2SEKSX+DQWtumCVL3mKhATREoT hMsd/oVktC7honvV9WefHiYjApFDZfRn2r8= X-Received: by 10.36.47.146 with SMTP id j140mr3208347itj.166.1501616327836; Tue, 01 Aug 2017 12:38:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.15.213 with HTTP; Tue, 1 Aug 2017 12:38:06 -0700 (PDT) From: Tessa Fallon Date: Tue, 1 Aug 2017 15:38:06 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a113f862ecf56b20555b64be1" Archived-At: Subject: [Cellar] Minutes from CELLAR IETF 99 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 01 Aug 2017 19:38:51 -0000 --001a113f862ecf56b20555b64be1 Content-Type: text/plain; charset="UTF-8" Thanks to Mo Zanaty for taking minutes. They are now available here: https://datatracker.ietf.org/meeting/99/materials/minutes-99-cellar --001a113f862ecf56b20555b64be1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks to Mo Zanaty for taking minutes.=C2=A0 They are now= available here:

--001a113f862ecf56b20555b64be1-- From nobody Wed Aug 2 08:39:59 2017 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 9FFCF13213D for ; Wed, 2 Aug 2017 08:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 QKFWYrRpUV6Q for ; Wed, 2 Aug 2017 08:39:55 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 320A1124B18 for ; Wed, 2 Aug 2017 08:39:55 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id m85so45056384wma.0 for ; Wed, 02 Aug 2017 08:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=rYp4+aEj/7YMCoF01Itm+/6Q+8dd2uEa77xvKogERDg=; b=N/4Y3P7vton+xisBcn5kBbJNF79bsTkV7F+pkgcOQFpDzyXfQYJvDQKkzCss1rADS6 SAhTlfn91rRsY9D+I3rUdsypu4oVLDCAuioeXlleksTud62+P6Z9fxXTSwlkNQ0R1GMI +cIMoIi7LclefTMdVCpXHbfQfaLGPlYjap2KITlbSWsL5dRNDVVhtRZv1iIPKruP9Shf Or1Zr79q0speI23Melic3a387gDC7/slBZaA81qV0JFMdlbJhApeTwGqu94QS+hwfkvp kd/RKDYZt6Pir0ehuB/+FlkznvwyoKP0ju76woc2La774q3hbop5lcZIkcwytB4qrfi+ HQnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rYp4+aEj/7YMCoF01Itm+/6Q+8dd2uEa77xvKogERDg=; b=NF7STq+zs4kNHLkbKzTq+ppK+Pc6WApf2GbNIQNssqxPr5vNNcvSVhFzUOyRExq8Yk GEpnSZDZWxaa472xkuWqZt1jQFRfFp1wXQSk9gv0isCE0rbgcjsyKF70ItTgL1IAOaRK JwQTlDF4hZo0azl3Lz/odllSimlMWMIzg7Z6C15GP3aBucHQQiUUld8S14ZoaCqRCx4i hKsRbLWA3wzy/JRSsiDyM7yoO+pXv7mLl14s8Dbr3X7RH5B3BmjSCaieqWdBZdbgwV+5 SO0HLlnLuup9E9oMKiseOxU3cfHPYq8HM58O0tV3VhhIejTwM6No8X+n4+pRfL/fyMjq velQ== X-Gm-Message-State: AIVw113DoNw7h+/rfi6cPyBERBlgmM+DgQ4/K2PHpJ6DizdiUix5kPtc l0uMkBoSDlRB2Qrm/MA= X-Received: by 10.80.194.193 with SMTP id u1mr19661751edf.103.1501688393369; Wed, 02 Aug 2017 08:39:53 -0700 (PDT) Received: from [192.168.1.159] ([149.12.11.37]) by smtp.googlemail.com with ESMTPSA id f29sm2042660edd.23.2017.08.02.08.39.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 08:39:52 -0700 (PDT) To: cellar@ietf.org References: <517340df-9bc8-c4e5-1085-011dcbaa54ce@gmail.com> <61ef1a40-7b56-4403-cde5-bba2aff0c338@mediaarea.net> From: Derek Buitenhuis Message-ID: <533b300a-564c-f651-5a1f-b48e61e65063@gmail.com> Date: Wed, 2 Aug 2017 16:39:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <61ef1a40-7b56-4403-cde5-bba2aff0c338@mediaarea.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Quick Review of draft-ietf-cellar-ffv1-00 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 02 Aug 2017 15:39:57 -0000 On 7/28/2017 6:18 PM, Jerome Martinez wrote: >> Why only SHOULD? > Why not? > We would like to avoid AVI compatibility layer (the files in the wild, > using a template from Microsoft), and we would like to have a native > binding in Matroska. I was thinking it should be a MUST, because no other alternatives are given in the document (such as the VFW compatible version), or maybe a reference to existing VFW-style types added to the document? - Derek From nobody Sun Aug 6 07:22:14 2017 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 88056132040 for ; Sun, 6 Aug 2017 07:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjHdII5bArEL for ; Sun, 6 Aug 2017 07:22:10 -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 A6151131D21 for ; Sun, 6 Aug 2017 07:22:10 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id u207so31134373ywc.3 for ; Sun, 06 Aug 2017 07:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uw01pLlOX4ZsIoeGlRYdQ4z6C4a6ndDedbkGOYCEVsM=; b=tzQlexLH4HRfgaev4cSVJ8UwCOgIxz39BL4hevJWlsPY2fiG0EruGqMfAEYbJJbKxZ 0p2Y7rMR0IAWUQzucXyUAo82xKFVgnC1/SCPEjEHzrtJjZPYCxt+q5h7AG5feB+DlkCH UdaSVB+yuczBL05Foi1kd0wR5iBbTgZLwzR1Ms9Yf8nqbvZSAyLnUD7mUOR5YinXurgo TczjglhoEMgWdopAC1coSGFkoyoGCC1UQFoLr5eV/Oy0okC3XJRL0m7+otm/WXvG1gyA szTOtmOGlYJYKHDFSJTMH3KXjjgDCRVyYs4NftDJ2Cj6ok9dOe1n29osIPGP667TaJsA RtkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uw01pLlOX4ZsIoeGlRYdQ4z6C4a6ndDedbkGOYCEVsM=; b=EcSpg+V0fC6NXR+zAsgmJYnR5Sxllb2Ag37Q1ebfQ1xHOUoy5enhmM1mK8N9Y4Fe9R yb3K4oSeR9XytcdvIBJv7pWiw1LPyGbLKT4NxMF2k3YVkTfelbk8mPDm/bik3yNoZoTu J77hryuhaXfMxRHrnDe7TahHqi/oFnyMIuveA5i/uZQbTQRfcmQ7plnXJ+S3LOY95T0q wtZc1vGtmzwiwT1anIqLjtm6pTBAf/IckVQZ6LnU1ms90IQtkDceFAEm8Vvnw2grGN1o 84gpIiYuWh0ssks5ePKBi0gcvtx7S2VmNx/Lfpe1jKUIuoS/S7FBkLd0kHXWF0yLXC3r EwFw== X-Gm-Message-State: AIVw1106WqusMigpE9NF3sQ1Ac+CIXasFaxIvS5kmoXTQv6sDyZDcXDf 8B45PGfCn01fZuWBJ1n/p3VgpTqigzVv X-Received: by 10.129.174.26 with SMTP id m26mr6621263ywh.340.1502029329780; Sun, 06 Aug 2017 07:22:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.13.208 with HTTP; Sun, 6 Aug 2017 07:22:09 -0700 (PDT) In-Reply-To: References: <027149E8-31E1-4EC0-AD40-6E9B84FFF8F5@gmail.com> From: Steve Lhomme Date: Sun, 6 Aug 2017 16:22:09 +0200 Message-ID: To: Rodger Combs Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Matroska: "Forced" and "Default" flag definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 14:22:13 -0000 2017-07-31 1:38 GMT+02:00 Rodger Combs : > I've submitted these changes as a PR to the specification repository: > https://github.com/Matroska-Org/matroska-specification/pull/158 > > On Jul 20, 2017, at 01:32, Rodger Combs wrote: > > Currently, Matroska's "forced" flag's documentation describes a feature that > wouldn't be particularly useful as defined, and doesn't match any > implementation's behavior I know of (though if any implementation actually > does overlay a forced track alongside a normal one, please let me know). I'd > like to propose an updated definition of the default and forced flags: > > - Default: > For audio or video, set if that track SHOULD be active if no language found > matches the user's preference; this can be used to specify the original > content language. For subtitles, set if that track SHOULD be chosen if there > are multiple tracks which match the user's language preferences. (1 bit) IMO there's no reason to differentiate subtitles from the other tracks. > Alternate definition: > Set if that track (audio, video or subs) SHOULD be active if multiple tracks > found matches the user's language preference. This can be used to specify a > "normal" track (as opposed to other tracks containing commentary or other > alternate content). (1 bit) > > If the alternate definition is used, then the original/default language > should be the first track of its type. If the first definition given is > used, then the first track of a given language and type should be the > "normal" one. It might be generally useful to add flags for track types > (commentary, hearing-impaired, descriptive audio service, etc...), but > that's out of scope of this proposal. Agreed, that would be a welcome addition. > - Forced: > Applies only to subtitles. Why ? For example you could have a forced video track. Some parts of the main video would be overlayed to show signs in the local language or censor parts in a specific country. > Set if that track SHOULD be active during > playback, even if the user's preferences would normally not enable subtitles > with the selected audio track; this can be used for tracks containing only > translations of foreign-language audio or onscreen text. (1 bit) > > > These definitions better match the intent of the flags on DVD and BD, > without implying user-hostile behavior or overlays of multiple tracks, and I > think they do a better job of carrying information about the relevant > tracks. They also match at least some existing implementation behavior. > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Mon Aug 7 17:10:12 2017 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 3D96A12EAF7 for ; Mon, 7 Aug 2017 17:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1kN1Q7TRn97 for ; Mon, 7 Aug 2017 17:10:07 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 12E7A129B25 for ; Mon, 7 Aug 2017 17:09:47 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id v29so11712477qtv.3 for ; Mon, 07 Aug 2017 17:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=qUPwxgCObcqfYduniHwMw4DbDFrHQeJCOQmG6mzVhiA=; b=Y3F+kQ6sQJPIsUVN37Jh+OqrO1jkVU/9PHw1Z9Br8SsYw05SPEZvYldk/kAbSr3iGI 1c/m0DSYUvWUiMqvzD/fx918aUHFrZRfS7kaLs5mw3Un0JB/xHOQAa9w4ZfRRV7/TdJy bWTPute4NE87pMZNug19RlttrfkGNxb/JSSVv+tQhCKke4ujQqXZNpWqhuK/7Fi2LbQJ 6CRyb+/W/iMz3kw/hb6LH8+3ztWwZGVRAO+LCbpvp2BgCp4wCCodSseeo35UTP2269SQ Itl1sJprp9tRpsvKvDTe/4OWR7vLj4nc0VQ0qekEQiCiJLT43gBzcTctbkd0q2LAllQw fOmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=qUPwxgCObcqfYduniHwMw4DbDFrHQeJCOQmG6mzVhiA=; b=aGr6N/IBNfrxmfylUwwgqGyhLQxDaoS4g+AojdcZLT8TNWtkVdZGBeIHUEu8VOfBYj z9n+eL12WZNGSp22E6k/ptOSjAD6LPIqGZZu4UclEyA4eg8/w67ljrEFaPe3jcyN+0rt NK5P0r9JlNi5X1qVSLJbr91vlv1FljpiVw3Ub20stjFqn8UpwK6xrq6z52nBExpQE3XT yFxit8IU3euwmLMRRjROkFzsrWK+nFH+5mq+KOimkhnXtTnYhsy1zBQ2xFUxWwN8XMDE GeKJ5lXMZNOYyTe2xLefjPSZMDJxkYdoRKT6OOsea4iX5RO00NQ5yQO0COGTKRrq0uGi 82JA== X-Gm-Message-State: AHYfb5i0s7rzYkPel5ZfHv1F9wJWfbp8EIRMhiSAVbCI0mUXOTvIkSn4 ILLJhGEUtslfrtOdono= X-Received: by 10.237.37.244 with SMTP id y49mr3148510qtc.313.1502150985909; Mon, 07 Aug 2017 17:09:45 -0700 (PDT) Received: from ?IPv6:2607:fb90:2408:de1f:4c7c:bf4f:7a3f:14c0? ([2607:fb90:2408:de1f:4c7c:bf4f:7a3f:14c0]) by smtp.gmail.com with ESMTPSA id r23sm4157qtc.50.2017.08.07.17.09.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 17:09:45 -0700 (PDT) From: Ashley Blewer Content-Type: multipart/alternative; boundary=Apple-Mail-0E0B17BD-EB85-439A-9606-4C2404338D44 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 7 Aug 2017 20:09:44 -0400 Message-Id: <538B01A1-5411-43B4-818C-82A704370CD4@gmail.com> To: cellar@ietf.org X-Mailer: iPhone Mail (14G60) Archived-At: Subject: [Cellar] Contributing recommendations (for new users) (according to me) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 08 Aug 2017 00:10:10 -0000 --Apple-Mail-0E0B17BD-EB85-439A-9606-4C2404338D44 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi CELLAR, I've talked to a couple of lurkers on this list that want to get involved bu= t don't know where to start. Here are a few guidelines just based on my expe= rience: EBML, Matroska, FFV1, FLAC: Review for inconsistencies: typos, contradictions, ambiguity in the document= ation. So just picking one of the specs and giving it a good review is incre= dibly helpful. The Matroska spec needs a lot of work here, as it is written i= n a colloquial manner inconsistent with "standards-style" language. There's p= lenty of work to do before that can really start to matter, but it's a good s= tarting point to get familiar with the docs. That's what I've started doing.= This can be brought up on the CELLAR list (preferred), brought up as a Gith= ub issue for the specification, or a pull request can be sent to change the c= odebase and a conversation can happen there. Specs can be reviewed purely with an eye towards compliance with RFC2119 (ht= tps://www.ietf.org/rfc/rfc2119.txt): Are these words being used appropriatel= y? Is there something listed as a SHOULD but should be a MUST? Is the word b= eing used but not capitalized, and so recommendation is being unintentionall= y implied, and the word should either become full-caps or changed? This kind= of tedious-work passthrough is a good way to familiarize yourself with one o= f the documents with plans to analyze more specifically later.=20 EBML: EBML is in a more advanced stage than others, but can still use more eyes fo= r general review. This initial review of EBML is helpful as a guideline for w= hat to look for and how to look for it: https://mailarchive.ietf.org/arch/ms= g/cellar/Mfj44tK1gyfqjU3Uu1tI5fMovtk Matroska: I've been just doing that general work of cleaning up language and looking f= or inconsistencies. Matroska docs are VERY long and helpful for users but le= ss "specification standard". Lots of eyes here would be helpful since there i= s a lot of ground to cover. There's a handful of issues on the Github tracke= r (https://github.com/Matroska-Org/matroska-specification/issues) but not su= re how many are suitable for novices. A review of the Matroska spec that see= ks for any redundant or conflicting information is a worthwhile endeavor. We= are very fortunate to have Moritz and Steve as active members and contribut= ors to this group. :)=20 FFV1: FFV1 is a little harder to break into, but there was a review by Derek Buite= nhuis posted to the CELLAR list on July 28 pointing out questions ( https://= mailarchive.ietf.org/arch/msg/cellar/qItSPq06vc9MaxsZFPJ3GmREsr4 ). Work tow= ards reviewing and deciding what can be done with this can be used as a basi= s for where to start looking. Again, just searching for typos and contradict= ions and noting them is important. FLAC: FLAC has some issues on the issue tracker that could be worked on: https://g= ithub.com/privatezero/flac_markdown/issues Issue #25 is of note -- when I have more time, I'll dig into that one a bit m= ore and make new tickets. It seems like the code and the specification have d= iverged slightly in terms of what things are named, and the spec should be u= pdated to reflect what is in the source code. That's some fun ("fun") diggin= g-around work that takes time but isn't intrinsically hard or requires exper= tise in the languages. The original ticket is about getting anchors to work,= there's some discussion in the ticket about what to do about that. In general, FLAC needs a more permanent Github home that isn't Andrew's pers= onal Github (as reported by the IETF meeting notes -- unsure what kind of nu= dging should be done here), and more nudging on the flac-dev list about any q= uestions in the spec that need explaining. It'd be good to get a closer feed= back loop with the FLAC crew, which can be done by bringing up issues on bot= h listservs. Not that much work has been started on FLAC yet so it's open te= rrain.=20 Overall, just reading and questioning the specifications is valuable work. If you are not very familiar with Github or are generally unsure how to cont= ribute there, please feel free to contact me off-list and I'd be happy to ex= plain/clarify questions. My best, Ashley=20 --Apple-Mail-0E0B17BD-EB85-439A-9606-4C2404338D44 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi CELLAR,

I've talked to a couple of lurkers on this= list that want to get involved but don't know where to start. Here are a fe= w guidelines just based on my experience:

EBML, Matroska, FFV1, FLAC:

<= /span>
R= eview for inconsistencies: typos, contradictions, ambiguity in the documenta= tion. So just picking one of the specs and giving it a good review is incred= ibly helpful. The Matroska spec needs a lot of work here, as it is written i= n a colloquial manner inconsistent with "standards-style" language. There's p= lenty of work to do before that can really start to matter, but it's a good s= tarting point to get familiar with the docs. That's what I've started doing.= This can be brought up on the CELLAR list (preferred), brought up as a Gith= ub issue for the specification, or a pull request can be sent to change the c= odebase and a conversation can happen there.

Specs can be reviewed purely= with an eye towards compliance with RFC2119 (https://www.ietf.org/rfc/rfc2119.txt): Are these word= s being used appropriately? Is there something listed as a SHOULD but should= be a MUST? Is the word being used but not capitalized, and so recommendatio= n is being unintentionally implied, and the word should either become full-c= aps or changed? This kind of tedious-work passthrough is a good way to famil= iarize yourself with one of the documents with plans to analyze more specifi= cally later. 

EBML:

EBML is in a more advanced stage than others,= but can still use more eyes for general review. This initial review of EBML= is helpful as a guideline for what to look for and how to look for it: = ;https://mailarchive.ietf.org/arch/msg/cellar/Mfj44tK1gyfqjU3Uu1tI5= fMovtk

Matroska:

I've been just doing that general work of cleaning= up language and looking for inconsistencies. Matroska docs are VERY long an= d helpful for users but less "specification standard". Lots of eyes here wou= ld be helpful since there is a lot of ground to cover. There's a handful of i= ssues on the Github tracker (https://github.com/Matroska-Org/matroska-specific= ation/issues) but not sure how many are suitable for novices. A review o= f the Matroska spec that seeks for any redundant or conflicting information i= s a worthwhile endeavor. We are very fortunate to have Moritz and Steve as a= ctive members and contributors to this group. :) 

= FFV1:
=

FFV1 is a= little harder to break into, but there was a review by Derek Buitenhuis pos= ted to the CELLAR list on July 28 pointing out questions ( htt= ps://mailarchive.ietf.org/arch/msg/cellar/qItSPq06vc9MaxsZFPJ3GmREsr4&nb= sp;). Work towards reviewing and deciding what can be done with this can be u= sed as a basis for where to start looking. Again, just searching for typos a= nd contradictions and noting them is important.

FLAC:

FLAC has some is= sues on the issue tracker that could be worked on: https://github.com/privatezero/f= lac_markdown/issues

Issue #25 is of note -- when I have more time, I'= ll dig into that one a bit more and make new tickets. It seems like the code= and the specification have diverged slightly in terms of what things are na= med, and the spec should be updated to reflect what is in the source code. T= hat's some fun ("fun") digging-around work that takes time but isn't intrins= ically hard or requires expertise in the languages. The original ticket is a= bout getting anchors to work, there's some discussion in the ticket about wh= at to do about that.

In general, FLAC needs a more permanent Github home t= hat isn't Andrew's personal Github (as reported by the IETF meeting notes --= unsure what kind of nudging should be done here), and more nudging on the f= lac-dev list about any questions in the spec that need explaining. It'd be g= ood to get a closer feedback loop with the FLAC crew, which can be done by b= ringing up issues on both listservs. Not that much work has been started on = FLAC yet so it's open terrain. 

Overall, just reading and questionin= g the specifications is valuable work.

If you are not very familiar with G= ithub or are generally unsure how to contribute there, please feel free to c= ontact me off-list and I'd be happy to explain/clarify questions.

=
My best= ,

Ashley 
= --Apple-Mail-0E0B17BD-EB85-439A-9606-4C2404338D44-- From nobody Wed Aug 9 02:44:22 2017 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 B3A501320DC for ; Wed, 9 Aug 2017 02:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 thJNVAYUzkzl for ; Wed, 9 Aug 2017 02:44:20 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42AB1320CF for ; Wed, 9 Aug 2017 02:44:20 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l82so36647023ywc.2 for ; Wed, 09 Aug 2017 02:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=tm1Ci3TASQvg6TMR+QKuOBM1JCi2UPZZSgYrYuuJq40=; b=Ei5Zn5nah7bdBoDcN+kJ8l9/j62GzafjQqrchsQXJmN1Owq+xn++tGDwJyivvvG4h2 H8S+nwTqp6PYxYr5Dd/s5slZBpZ9c+1PM8+74um4D6VLhgWCDZiChTg/0+yc1DF7Q8mU NY1VSay6I2DlTpMZVW2jeskj6pPIy1YdkfHXlxzG0y5NeRIZb2FUQv9t+AsQQWzpD90J +5iJnM/sEQrhBiXiuYmLrbuHTDcekmJ4VB/X5id7gK+PIZ40XSkFXOM9csLDBxt9fZIb cd/cPe/Gh7aCnRRUZP4roIGadFlT1sZyitd7N9Tfw/k0IHr1VtURAGpK6ByMlWWiLRUt 5xVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tm1Ci3TASQvg6TMR+QKuOBM1JCi2UPZZSgYrYuuJq40=; b=TbfUzhuzG0GLjkIamVRbVWojv9D/xHigybM78S+P2e3QpY5b6Kc2YbvG3nckz0fudd Hx3oZsWm4FWeX65Xo/R7dTtjVkvq/K7GvKxOJEipg9BMehVKjcSBb1D0oU04L9Tm6eMR dAwQp33jBpOrdEWD4BQtu9PdaUjaAgxzSWYh1d9s3Oguhh93CCyrYeICCigWW8zFDXGJ UXZtxda/KObI2i64UxinS3QKD3rUIuTUPpnXYGbsC+3glYF8Y73HYOqpqLwUNaQMynud tdpqpk41pfuslekr8jPEUsCh4bHrSAkpm6wC2U7qDY4Zp6LwOXg7iSR7V7tJx6MVw3Gq vKzA== X-Gm-Message-State: AHYfb5gBBLLgQh/MhwBYilWT6d2pSwJMbtzE9NfrLG+sKXaRHyFn8oa/ NI6h3XcMIMHnW9Z22iCvTq7kYhN0TBuh35k= X-Received: by 10.37.196.193 with SMTP id u184mr5924083ybf.11.1502271859773; Wed, 09 Aug 2017 02:44:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.13.208 with HTTP; Wed, 9 Aug 2017 02:44:19 -0700 (PDT) From: Steve Lhomme Date: Wed, 9 Aug 2017 11:44:19 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] EBML Rational Number X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 09:44:22 -0000 Since some Matroska elements would be better as rational numbers we need a way to store them. I think a type would be better than using two EBML Signed Integers. The bits in the VDATA would be divided in half. The first part (signed) for the numerator, the second part (signed?) for the denominator. Opinions ? -- Steve Lhomme Matroska association Chairman From nobody Wed Aug 9 02:48:44 2017 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 F1F66126CC4 for ; Wed, 9 Aug 2017 02:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogrunArWMuZ1 for ; Wed, 9 Aug 2017 02:48:42 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB65A126C22 for ; Wed, 9 Aug 2017 02:48:41 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:59812) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dfNbO-0007kh-2g for cellar@ietf.org; Wed, 09 Aug 2017 11:48:35 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 912156541E61 for ; Wed, 9 Aug 2017 11:48:34 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0207.598ADA73.0020, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1502272114; bh=7qWkD0KTirx3MgQhAyfedBTFSVjKbeuEMIeBqeql8KI=; h=References:From:To:Subject:In-reply-to:Date:From; b=EZNOgD+DFoQRWMFeqL1ZMSvokGBaKq00DB+k7iRYKWaWp0a/nkCo66T8V9N2ml+vm 4OGQsxDlGPd8f0+crF93QLz2vPG2ekspJPEmrXt038/dQXSq7UsJZrFVcqIZHermn9 35rNwhzo3KG/HMvC8UkXMsmENu7neEaricmsmMjo8bzMWdFRU8qZMGVJ6uIrDmWP5v w5JxjIyjMtXp3TG1sKngsquFY7Mkx0fdmTO4nzZx4Cmj7l/CfOtYMTpRCjXl+8kkXE o51R8M0bObWaA/oUqd9tvSNDqZrWEwrZXLF43c88fJKkqZRIPxbr0e+VLVk6g3oTU0 rjqycvm6Y58jfQI4SK9U54+U8EJrU4ur/v+8MmDLlMPwJLCqjZRp7bH2lAJ/S1zR0N RLNHhhO+QAT24zIdoB9Fn8XPPI+yByP6fsYK6YKoPbb1nooAAhJWdk1RMoFTw9WgRv 4RnLMr70d8MJMwWh08q+xDHanQxGYSddkr1ZbDMcqzps0a+w+qQIXPU+6nAmFUVOYa BOy7R3qx9yW9mNVdq90gmXq1cKcAUEsPj7n/Z5XgfMqYE4146QJpddkSCSWOtrSXMN 7CgBilMsG8d3wSHYz3evKm9vo6fU3ZcYmFp6muZAiTpm8B5tgeyY22zfS/5LXksGBJ iZ8SeXFWrxEZH1+YkKjqciz0= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTPS id 86B411C9B197 for ; Wed, 9 Aug 2017 11:48:32 +0200 (CEST) References: User-agent: mu4e 0.9.18; emacs 25.2.1 From: Moritz Bunkus To: Codec Encoding for LossLess Archiving and Realtime transmission In-reply-to: Date: Wed, 09 Aug 2017 11:48:32 +0200 Message-ID: <87shh1xea7.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] EBML Rational Number X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 09:48:43 -0000 Hey, to be honest, I'd rather we focus on turning both specs into IETF standard. Extending both specs with new elements is all good and fine, but it only adds to the already huge task we still have before us. Kind regards, mosu From nobody Wed Aug 9 15:15:16 2017 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 1ECBF13226B for ; Wed, 9 Aug 2017 15:15: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, 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 AEpNdU6MMaDx for ; Wed, 9 Aug 2017 15:15:12 -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 A6179132195 for ; Wed, 9 Aug 2017 15:15:12 -0700 (PDT) X-Originating-IP: 213.47.41.20 Received: from localhost (213-47-41-20.cable.dynamic.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 16548172098 for ; Thu, 10 Aug 2017 00:15:10 +0200 (CEST) Date: Thu, 10 Aug 2017 00:14:03 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20170809221403.GW6482@nb4> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VnCKLxguT6BBzdXa" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] EBML Rational Number X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 22:15:15 -0000 --VnCKLxguT6BBzdXa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 09, 2017 at 11:44:19AM +0200, Steve Lhomme wrote: > Since some Matroska elements would be better as rational numbers we > need a way to store them. I think a type would be better than using > two EBML Signed Integers. The bits in the VDATA would be divided in > half. The first part (signed) for the numerator, the second part > (signed?) for the denominator. >=20 > Opinions ? no oppinion on if adding a new element is a good idea or not but if one is added with a pair of numbers only one number needs to be signed. -a / -b =3D=3D a / b If one was crazy then one could also improve compression by only storng relative primes. For example if a and b are even they can always be divided by 2 so there is no need to waste a codeword for that in theory ... i find this interresting which is why i mention it. Its certainly not a good idea due to complexity vs (totally neglgible) gain. An alternative to storing things using a pair of numbers would be to use a existing type and use the nearest rational number. this would provide some backward compatibility [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus --VnCKLxguT6BBzdXa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlmLiSsACgkQYR7HhwQLD6tVXwCdH3HMsTLqITj+jPeaXZPYkFIp XY8AnjtcbH5fDLWdxZ+MqShnwuucLidG =PvZ3 -----END PGP SIGNATURE----- --VnCKLxguT6BBzdXa-- From nobody Wed Aug 9 16:29:19 2017 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 6D9441270AC for ; Wed, 9 Aug 2017 16:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKYZCsI3eBL8 for ; Wed, 9 Aug 2017 16:29:15 -0700 (PDT) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D38B126B71 for ; Wed, 9 Aug 2017 16:29:15 -0700 (PDT) Received: from eris.local (dynamic-adsl-84-221-84-43.clienti.tiscali.it [84.221.84.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 7E698341742 for ; Wed, 9 Aug 2017 23:29:12 +0000 (UTC) To: cellar@ietf.org References: From: Luca Barbato Message-ID: <3aaa4953-96f4-7298-14a2-f365db12bc63@libav.org> Date: Thu, 10 Aug 2017 01:29:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Thunderbird/55.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] EBML Rational Number X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 23:29:17 -0000 On 09/08/2017 11:44, Steve Lhomme wrote: > Since some Matroska elements would be better as rational numbers we > need a way to store them. I think a type would be better than using > two EBML Signed Integers. The bits in the VDATA would be divided in > half. The first part (signed) for the numerator, the second part > (signed?) for the denominator. I'd rather not add another type and keep rational numbers as pairs of integers (signed numerator, unsigned denominator). lu From nobody Wed Aug 9 23:29:13 2017 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 D4CC4132451 for ; Wed, 9 Aug 2017 23:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 OPbFCnIcLd8U for ; Wed, 9 Aug 2017 23:28:59 -0700 (PDT) Received: from 13.mo3.mail-out.ovh.net (13.mo3.mail-out.ovh.net [188.165.33.202]) (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 05AF813256B for ; Wed, 9 Aug 2017 23:28:57 -0700 (PDT) Received: from player797.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id 6542C11D2CC for ; Thu, 10 Aug 2017 08:28:54 +0200 (CEST) Received: from [192.168.2.120] (p5DDB6F96.dip0.t-ipconnect.de [93.219.111.150]) (Authenticated sender: jerome@mediaarea.net) by player797.ha.ovh.net (Postfix) with ESMTPSA id BE05E2E007D for ; Thu, 10 Aug 2017 08:28:54 +0200 (CEST) To: cellar@ietf.org References: <87shh1xea7.fsf@bunkus.org> From: Jerome Martinez Message-ID: Date: Thu, 10 Aug 2017 08:28:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <87shh1xea7.fsf@bunkus.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr X-Ovh-Tracer-Id: 18241267342790955153 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelkedrkeeigdduudefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] EBML Rational Number X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 10 Aug 2017 06:29:02 -0000 Le 09/08/2017 à 11:48, Moritz Bunkus a écrit : > to be honest, I'd rather we focus on turning both specs into IETF > standard. Extending both specs with new elements is all good and fine, but > it only adds to the already huge task we still have before us. I second that. From nobody Thu Aug 10 00:03:42 2017 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 045D8132580 for ; Thu, 10 Aug 2017 00:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRZySuqpPOav for ; Thu, 10 Aug 2017 00:03:39 -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 361FE13257F for ; Thu, 10 Aug 2017 00:03:39 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u207so53416995ywc.3 for ; Thu, 10 Aug 2017 00:03: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:from:date:message-id:subject:to :cc; bh=qFAUyPzvWBHdqSS/YuJB2m1ARdr7FBXZFS3L/srMhHM=; b=aHRri/6dVYKZ7x8XeVE5O1rZZ9F2jqcFI16UbxicX5+dWdA4YU5CeDf67nvd10Ps2O 9YreHbluDD7RqMCpwGLvWhkRB3jIMSi8oqwd3YiZFcHQ0QSlI2xEbpYziFAxdismz0Ds tNTS/2U5GKIG5bv3jCsXMMern51pPyKBAzgfqGvnsnyEJIH65IraR9ONgAJB0ovxc2Tr fIj8KOPh0u6YpP7FkQGCw8WPpAZbg7SqNEe4vsZfug03SkbaaLol4s+SjulNXgDSbNU8 I8Fi5fojQBDAUbH3yMC4eoPXhHPqE0AyakkEEfN8iAb2w2G9VGCHqkFEwIaWOI7AMFBO qsZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qFAUyPzvWBHdqSS/YuJB2m1ARdr7FBXZFS3L/srMhHM=; b=dHdyIdT4LRv1/pfy6rXvYQvB85oPX44qVxtwDJ/dXLRrjrgLzpGgdoqLsLODQ9vc6s Cd2hpNhBCQbtJHdAwqFM57yaFwc9UkKVORDv6GQCISCclO26fb/fiYmfmDtLHo8hzkUt KMgNHcadM4FpzPUb+vuNuWN1881r2qkP87d6VT0semgkpCfRlRQNKtKC5CAPRO/QyR0h Ha0cz+Wx/1jsuVBAli2EgenkwD9k3MjqvFOObdMHUwj47G1HG+VDwp4z7qSZC2+CBcPm TQLx9TjRVfkv+k1UNS2apCQMLpM9N9GfT34xCyFa0eSLZxGZVY7/s64OH4IcsmowWuoF nfUA== X-Gm-Message-State: AHYfb5hziJsX6j9h13Ai2dkKOEQK+I0/Bx3t6am0P8aVCW8HTNVjMhGM bVojW0Vt4nWhvEplWXbm0SCBmrAUb8Ml X-Received: by 10.37.196.193 with SMTP id u184mr8765416ybf.11.1502348618361; Thu, 10 Aug 2017 00:03:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.13.208 with HTTP; Thu, 10 Aug 2017 00:03:37 -0700 (PDT) In-Reply-To: <87shh1xea7.fsf@bunkus.org> References: <87shh1xea7.fsf@bunkus.org> From: Steve Lhomme Date: Thu, 10 Aug 2017 09:03:37 +0200 Message-ID: To: Moritz Bunkus Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] EBML Rational Number X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 10 Aug 2017 07:03:41 -0000 2017-08-09 11:48 GMT+02:00 Moritz Bunkus : > Hey, > > to be honest, I'd rather we focus on turning both specs into IETF > standard. Extending both specs with new elements is all good and fine, but > it only adds to the already huge task we still have before us. I totally agree but I wanted to put out there for discussion. It can be added in the far future or later. It's definitely not a priority right now. > Kind regards, > mosu > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Thu Aug 10 08:23:55 2017 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 874D01321D5 for ; Thu, 10 Aug 2017 08:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLSQYBADh9vk for ; Thu, 10 Aug 2017 08:23:52 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535EC132190 for ; Thu, 10 Aug 2017 08:23:52 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 16so6215835qtz.4 for ; Thu, 10 Aug 2017 08:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=INhlCQg+zjWXT10KjWl81sKSSrW6usKQIyT6LHcQMqQ=; b=hM0CuSvi1wyBbl++mChBaWksdjXy5xCXDcotC7OoqQw+H87jtyBLN5ruWE4Hpt/USN LdjRyewDKpH3ivP42zSP8FjMc9eTw3uGFwZbVG6i0Og2vtxpV2i7k3PDomGIi78luwPx obpTZOFrhGjZecsbff3t9/pFu9Rb9+H/44/DjMye4hRKZXmFl77IhuyfHRkUMzgA+rsy aO6w3HRVCcKrQmgwQSD61+AId7bOW7nahYfl5V5QcKmE9FvYvgO6RLEODBdFuD3t8n05 lIbCR60vhn9vYqLOpWY3boAXfYq9CPu7ERnus2f7BSy8ZtWc3FcHP3vd2fDckHOXdZyj GJSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=INhlCQg+zjWXT10KjWl81sKSSrW6usKQIyT6LHcQMqQ=; b=gxz+REhUVOzJtQq7oLhGJRMtti+zEvlQf6XdetHY80rC6KSO0k8GmM/euqPOuZ4V7z 95bqTgm8iybGADIlKHNUQT5YvYgAZ8sLajD4cpqKb5vUGy58HyYNzGT5MjqYYzjvFxSY tU5NPvL9BXe2XUnKtPxsrj+l0DqrT0u20rAZTzAogkgaoi8yiwO71pAsO3PiKfv4NBos cY7q0B0n5mizsgQykc5kSO7YrrtY1C1s2k2juhQBTmL3Q4WDi3J+VDeOdQncNEjc1FGH Lucevtd4I+bgkGM1GdReEGMrVZ3MO55a80/76Ww8EIS68xzpdhdYh+VHCuL4QR6KOmkb X67Q== X-Gm-Message-State: AHYfb5jQk1/+3FAZ3sGJn5zis9SSlSCBk3O0TUFji57tasvgYJR1giLU 0SHaH1sd389/QV1seUcU4QazqZyBBy0MBME= X-Received: by 10.200.37.139 with SMTP id e11mr17515639qte.50.1502378631149; Thu, 10 Aug 2017 08:23:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.73 with HTTP; Thu, 10 Aug 2017 08:23:50 -0700 (PDT) From: Ashley Blewer Date: Thu, 10 Aug 2017 11:23:50 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a11c03282a0c258055667c8bb" Archived-At: Subject: [Cellar] Matroska: Which comes first, CRC or Timecode? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 10 Aug 2017 15:23:54 -0000 --001a11c03282a0c258055667c8bb Content-Type: text/plain; charset="UTF-8" Hi, I want to follow up on-list about an issue arising in this PR clarifying language in the ordered guidelines of Matroska. (And trying to keep the PR scoped to mostly small grammar/structure errors!) The original last line seems to contract other statements made in the specification. The last line, originally, was: As each `BlockGroup` and `SimpleBlock` of a `Cluster` Element needs the Cluster `Timecode`, the `Timecode` Element MUST occur as the first Child Element within the `Cluster` Element. But, as Dave Rice brought up, a Cluster with a CRC-32 element expects the CRC-32 to be first, not Timecode. Moritz said: "I think that Timecode being the first element is just a recommendation, not a requirement. The intention is that the Timecode is found before the first Element that needs it (BlockGroup or SimpleBlock). Therefore placing the CRC32 Element first wouldn't do any harm." Does anyone have any opinions on this? Should CRC always come first if present, and Timecode should always come first, but second to CRC? Other solutions? For now, I updated the PR with Dave's advice... The Timecode Element MUST occur as in storage order before any SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element Thanks, Ashley --001a11c03282a0c258055667c8bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I want to follow up on-list about a= n issue arising in this PR clarifying language in the ordered guidelin= es of Matroska. (And trying to keep the PR scoped to mostly small grammar/s= tructure errors!)

The original last line seems to = contract other statements made in the specification.=C2=A0

The last line, originally, was:

As each `BlockGroup` and `SimpleBlock` of a `Clu= ster` Element needs the Cluster `Timecode`, the `Timecode` Element MUST occ= ur as the first Child Element within the `Cluster` Element.

But, as Dave Rice brought up, a Cluster with a CRC-32 = element expects the CRC-32 to be first, not Timecode.

<= div>Moritz said:

"I think that Timecode being= the first element is just a recommendation, not a requirement. The intenti= on is that the Timecode is found before the first Element that needs it (Bl= ockGroup or SimpleBlock). Therefore placing the CRC32 Element first wouldn&= #39;t do any harm."

Does anyone have any opin= ions on this? Should CRC always come first if present, and Timecode should = always come first, but second to CRC? Other solutions?

=
For now, I updated the PR with Dave's advice...

The Timecode Element MUST occur as in = storage order before any SimpleBlock, BlockGroup, or EncryptedBlock within = the Cluster Element

Thanks,
<= br>
Ashley
--001a11c03282a0c258055667c8bb-- From nobody Thu Aug 10 08:32:27 2017 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 16CF1132386 for ; Thu, 10 Aug 2017 08:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 6hnAOnLBHy47 for ; Thu, 10 Aug 2017 08:32:24 -0700 (PDT) Received: from server172-2.web-hosting.com (server172-2.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 1C6CC1321BE for ; Thu, 10 Aug 2017 08:32:24 -0700 (PDT) Received: from [146.96.19.240] (port=13106 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dfpRd-002UT4-SB; Thu, 10 Aug 2017 11:32:23 -0400 From: Dave Rice Message-Id: <1394AE67-63F0-4194-B897-AB00F7DD5D71@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6AD13820-32FB-4F56-BF69-30AC9CC306E9" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Thu, 10 Aug 2017 11:32:20 -0400 In-Reply-To: Cc: Codec Encoding for LossLess Archiving and Realtime transmission To: Ashley Blewer References: X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Matroska: Which comes first, CRC or Timecode? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 10 Aug 2017 15:32:26 -0000 --Apple-Mail=_6AD13820-32FB-4F56-BF69-30AC9CC306E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 10, 2017, at 11:23 AM, Ashley Blewer = wrote: >=20 > Hi, >=20 > I want to follow up on-list about an issue arising in this PR = = clarifying language in the ordered guidelines of Matroska. (And trying = to keep the PR scoped to mostly small grammar/structure errors!) >=20 > The original last line seems to contract other statements made in the = specification.=20 >=20 > The last line, originally, was: >=20 > As each `BlockGroup` and `SimpleBlock` of a `Cluster` Element needs = the Cluster `Timecode`, the `Timecode` Element MUST occur as the first = Child Element within the `Cluster` Element. >=20 > But, as Dave Rice brought up, a Cluster with a CRC-32 element expects = the CRC-32 to be first, not Timecode. >=20 > Moritz said: >=20 > "I think that Timecode being the first element is just a = recommendation, not a requirement. The intention is that the Timecode is = found before the first Element that needs it (BlockGroup or = SimpleBlock). Therefore placing the CRC32 Element first wouldn't do any = harm." >=20 > Does anyone have any opinions on this? Should CRC always come first if = present, and Timecode should always come first, but second to CRC? Other = solutions? >=20 > For now, I updated the PR with Dave's advice... >=20 > The Timecode Element MUST occur as in storage order before any = SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element FWIW, ffmpeg writes CRC-32 before Timecode (correct via EBML spec, = incorrect via current Matroska spec). ... Dave Rice= --Apple-Mail=_6AD13820-32FB-4F56-BF69-30AC9CC306E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Aug 10, 2017, at 11:23 AM, Ashley Blewer <ashley.blewer@gmail.com> wrote:

Hi,

I = want to follow up on-list about an issue arising in this PR clarifying language in the ordered guidelines of = Matroska. (And trying to keep the PR scoped to mostly small = grammar/structure errors!)

The original last line seems to contract other statements = made in the specification. 

The last line, originally, = was:

As each `BlockGroup` and = `SimpleBlock` of a `Cluster` Element needs the Cluster `Timecode`, the = `Timecode` Element MUST occur as the first Child Element within the = `Cluster` Element.

But, as Dave Rice brought up, a Cluster = with a CRC-32 element expects the CRC-32 to be first, not = Timecode.

Moritz= said:

"I = think that Timecode being the first element is just a recommendation, = not a requirement. The intention is that the Timecode is found before = the first Element that needs it (BlockGroup or SimpleBlock). Therefore = placing the CRC32 Element first wouldn't do any harm."

Does anyone have any = opinions on this? Should CRC always come first if present, and Timecode = should always come first, but second to CRC? Other solutions?

For now, I updated the = PR with Dave's advice...

The Timecode = Element MUST occur as in storage order before any SimpleBlock, = BlockGroup, or EncryptedBlock within the Cluster Element


FWIW, ffmpeg writes CRC-32 before Timecode (correct via = EBML spec, incorrect via current Matroska spec).
<Cluster>
= <CRC-32/>
<Timecode/>
= <SimpleBlock>...</SimpleBlock>
</Cluster>

Dave Rice
= --Apple-Mail=_6AD13820-32FB-4F56-BF69-30AC9CC306E9-- From nobody Thu Aug 10 08:46:42 2017 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 AF5ED132391 for ; Thu, 10 Aug 2017 08:46:40 -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, HTML_MESSAGE=0.001, 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 mNVwXDpz33j5 for ; Thu, 10 Aug 2017 08:46:38 -0700 (PDT) Received: from 10.mo3.mail-out.ovh.net (10.mo3.mail-out.ovh.net [87.98.165.232]) (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 2FDD71321BE for ; Thu, 10 Aug 2017 08:46:37 -0700 (PDT) Received: from player797.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id AE45812B2C6 for ; Thu, 10 Aug 2017 17:46:35 +0200 (CEST) Received: from [192.168.2.120] (p5DDB6F96.dip0.t-ipconnect.de [93.219.111.150]) (Authenticated sender: jerome@mediaarea.net) by player797.ha.ovh.net (Postfix) with ESMTPSA id 228872E007D for ; Thu, 10 Aug 2017 17:46:35 +0200 (CEST) To: cellar@ietf.org References: From: Jerome Martinez Message-ID: Date: Thu, 10 Aug 2017 17:46:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F162DAC9A8005B0B47B227C8" Content-Language: en-US X-Ovh-Tracer-Id: 9212957462733197457 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelkedrkeejgdelvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Matroska: Which comes first, CRC or Timecode? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 10 Aug 2017 15:46:41 -0000 This is a multi-part message in MIME format. --------------F162DAC9A8005B0B47B227C8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 10/08/2017 à 17:23, Ashley Blewer a écrit : > > For now, I updated the PR with Dave's advice... > > The Timecode Element MUST occur as in storage order before any > SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element IMHO CRC is general purpose, so "must be first" must be obeyed in priority. I would be less limiting the list of blocks after Timecode, something like "The Timecode Element MUST occur as in storage order before any element specific to the Cluster Element" (i.e. all nested in the Cluster element in the specs). --------------F162DAC9A8005B0B47B227C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Le 10/08/2017 à 17:23, Ashley Blewer a écrit :

For now, I updated the PR with Dave's advice...

The Timecode Element MUST occur as in storage order before any SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element

IMHO CRC is general purpose, so "must be first" must be obeyed in priority.
I would be less limiting the list of blocks after Timecode, something like "The Timecode Element MUST occur as in storage order before any element specific to the Cluster Element" (i.e. all nested in the Cluster element in the specs).
--------------F162DAC9A8005B0B47B227C8-- From nobody Thu Aug 10 12:14:16 2017 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 412A2132418 for ; Thu, 10 Aug 2017 12:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hYrxdS_NCtd for ; Thu, 10 Aug 2017 12:14:12 -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 E97CB132414 for ; Thu, 10 Aug 2017 12:14:11 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id c74so12980666iod.4 for ; Thu, 10 Aug 2017 12:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+k69c6Y9mQQbpHUHjYjedkF7yVtdPlcCv+28A7+Wmzc=; b=rhTEbo2ximFtua3rt9KfDopBt5bmt3+D9XjQNpwqiEF7OffYykLwMDwjICXmRh1tYz zu2sDIvJ8+taVXK+/Hn5fra8eo3xyBgEdu6X+tVnpKT7nOhl/2XW4xFMF3Yp9EB7jimb Tg51e0QMgkNWWVUPoSavkasyGfoEcV9/ZOSqhzIncF2qwn2heJvU2GjH6RK+fGFM45Qm WlDI+KFAnBcgEhGusUNQv1WV9iGRUf+AGSkPbhL00b9xNdYZxaHumR7YJSQdxI6LTbAl JUccOUMjM0oWsiARGtCg9j7nel+471SPRWppQYTn6AXGcvK7fuijJwdFhUQkfHCo2C9x Thsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+k69c6Y9mQQbpHUHjYjedkF7yVtdPlcCv+28A7+Wmzc=; b=JJrPtpx01jjSwV8Jb94wrrDWE7hVNFcvJLp/Mipzklaqajy33L1ndTf0/Z7AoGX6H4 qg2Gx8tx13tvVnBvLSkyhe1SWD6usNRWaAAvPvtUy0HGZ7sFKJdJUOQgkE8bQAC4QRn6 NIgm6tUg8PUhk1uHoF3u8314LKyKo1iUYEktctmolATH5wNuHFWL5lK75QBH6TpRL6xI lqNONP2nPRE+g8hh78a6adf5LNG7THiS9ncD4IfUd0k06cPZxiZ0z2DVPViJPBsLnFWi WyHGitljyFBD8FDp5maPkUVKYggjy/TUZ/1ul2Li+gC9QJfC22GYANYrJ6hHezgf5Vyw /i1w== X-Gm-Message-State: AHYfb5g2n6ZSPuxvJw6o3EreAgyvV1LuA0FaG2mLMIYZHruVKQuRLCGs 9JWcctigFQHQYuqAZ2Nz7NzOVo5NdWm4 X-Received: by 10.107.135.33 with SMTP id j33mr11947662iod.257.1502392451202; Thu, 10 Aug 2017 12:14:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.15.213 with HTTP; Thu, 10 Aug 2017 12:14:09 -0700 (PDT) Received: by 10.107.15.213 with HTTP; Thu, 10 Aug 2017 12:14:09 -0700 (PDT) In-Reply-To: References: From: Tessa Fallon Date: Thu, 10 Aug 2017 15:14:09 -0400 Message-ID: To: Jerome Martinez Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a113ed0725e04c005566b00e1" Archived-At: Subject: Re: [Cellar] Matroska: Which comes first, CRC or Timecode? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 10 Aug 2017 19:14:14 -0000 --001a113ed0725e04c005566b00e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Should this be out to a vote? On Aug 10, 2017 11:46, "Jerome Martinez" wrote: > Le 10/08/2017 =C3=A0 17:23, Ashley Blewer a =C3=A9crit : > > > For now, I updated the PR with Dave's advice... > > The Timecode Element MUST occur as in storage order before any > SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element > > > IMHO CRC is general purpose, so "must be first" must be obeyed in priorit= y. > I would be less limiting the list of blocks after Timecode, something lik= e > "The Timecode Element MUST occur as in storage order before any element > specific to the Cluster Element" (i.e. all nested in the Cluster element = in > the specs). > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --001a113ed0725e04c005566b00e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Should this be out to a vote?

On Aug 10, 2017 11:46, "Jerome Mar= tinez" <jerome@mediaarea.ne= t> wrote:
=20 =20 =20
Le 10/08/2017 =C3= =A0 17:23, Ashley Blewer a =C3=A9crit=C2=A0:

For now, I updated the PR with Dave's advice...

The Timecode Element MUST occur as in storage order before any SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element

IMHO CRC is general purpose, so "must be first" must be obeye= d in priority.
I would be less limiting the list of blocks after Timecode, something like "The Timecode Element MUST occur as in storage orde= r before any element specific to the Cluster Element" (i.e. all nest= ed in the Cluster element in the specs).

_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar
--001a113ed0725e04c005566b00e1-- From nobody Thu Aug 10 13:12:45 2017 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 85AAD132430 for ; Thu, 10 Aug 2017 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBqHBcGUvzUq for ; Thu, 10 Aug 2017 13:12:42 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15A5131D70 for ; Thu, 10 Aug 2017 13:12:42 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id d136so10502682qkg.3 for ; Thu, 10 Aug 2017 13:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oBv6w1QrNB0agbxV+J69kb4ARMoMHcIzP0j5SBTAu10=; b=lM39do8GDaELQdBj2NMetFM4V/iphjl4ChI4eI6/LCTTdouRDrf5S5RKhKF9DB4W4b tHFxj+c3dWTWs4bO+hC6bjGCqN0H1d2O04fFVqZSd8fot/p4NuEo3R+/WIlsUfo73j3/ U49A8WtcemndexwNUSCDe3rRroCcFt04m8KCppoBF1QZgoCQhAlLYDgJ41uxiLpXjukE Q3ahRzyAKDAIVIONT0QQxSkHUChaXgXdaFtYXnSr+InnIfWlYKDDKCPROUmk00BBd2LE oom6woo0ydRuCjZXuTp/dashUjgOpFJxrZ5WRHj7Ux1SMxDRC0dKs/F4GMj7NM0GN68C NECQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oBv6w1QrNB0agbxV+J69kb4ARMoMHcIzP0j5SBTAu10=; b=Y9o/Sf1Pr8+rWysN6fNBf54a0AtkEuYTYp1hCZ4CBTQvjaLI6Rta/JnqJRWFSmKa2f XmfKvD21QFWFAkqE7NfQFmu2uzMRahEwfu04lRgw2+07P2w2x9Cvt0idRWiM56kGhmqN WUFY5JuXL1avBYXtRSxpvTBXJWUVNUYjxTFzJ5bRl7NkeZp7L1ndPAI739t7+fQ3fV80 ZWRBvSiagFvHBiDvfq9OM6vsD5yjA2dSlm3MWyMAtfmoRVGKYQDjoYPKPvqTT0fhK9Tr XVH6gMKZdAya1D46K8c0YLQ1tBM0enurDHW81wVWhi80uuTfU+Q5Qb+nueuB2WhRjfR5 SNOw== X-Gm-Message-State: AHYfb5g74uKKpCaSJlDlvfOBxprrPHDlih1qijo+UDkTPUocq2ijzXSE F5LSp3oXwzm8U3aqSKj1bUTIvsBAgg== X-Received: by 10.55.76.193 with SMTP id z184mr17075780qka.146.1502395961872; Thu, 10 Aug 2017 13:12:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.73 with HTTP; Thu, 10 Aug 2017 13:12:41 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Thu, 10 Aug 2017 16:12:41 -0400 Message-ID: To: Tessa Fallon Cc: Jerome Martinez , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a114a896c9e959a05566bd1cd" Archived-At: Subject: Re: [Cellar] Matroska: Which comes first, CRC or Timecode? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 10 Aug 2017 20:12:44 -0000 --001a114a896c9e959a05566bd1cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hmm... not well-versed on the voting, but I don't think so. I think it's just a matter of opinions interpreting the existing specs and considering how it has been generally interpreted. On Thu, Aug 10, 2017 at 3:14 PM, Tessa Fallon wrote: > Should this be out to a vote? > > On Aug 10, 2017 11:46, "Jerome Martinez" wrote: > >> Le 10/08/2017 =C3=A0 17:23, Ashley Blewer a =C3=A9crit : >> >> >> For now, I updated the PR with Dave's advice... >> >> The Timecode Element MUST occur as in storage order before any >> SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element >> >> >> IMHO CRC is general purpose, so "must be first" must be obeyed in >> priority. >> I would be less limiting the list of blocks after Timecode, something >> like "The Timecode Element MUST occur as in storage order before any >> element specific to the Cluster Element" (i.e. all nested in the Cluster >> element in the specs). >> >> _______________________________________________ >> 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 > > --001a114a896c9e959a05566bd1cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm... not well-versed on the voting, but I don't thin= k so. I think it's just a matter of opinions interpreting the existing = specs and considering how it has been generally interpreted.=C2=A0

On Thu, Aug 10, 2017= at 3:14 PM, Tessa Fallon <tessa.fallon@gmail.com> wrot= e:
Should this be out t= o a vote?

On Aug 10, 2017 11:46, "Jerome Martinez" <= ;jerome@mediaarea= .net> wrote:
=20 =20 =20
Le 10/08/2017 =C3=A0 17:23, Ashley Blewer a =C3=A9crit=C2=A0:

For now, I updated the PR with Dave's advice...

The Timecode Element MUST occur as in storage order before any SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element

IMHO CRC is general purpose, so "must be first" must be obeye= d in priority.
I would be less limiting the list of blocks after Timecode, something like "The Timecode Element MUST occur as in storage orde= r before any element specific to the Cluster Element" (i.e. all nest= ed in the Cluster element in the specs).

_______________________________________________
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

--001a114a896c9e959a05566bd1cd-- From nobody Thu Aug 10 13:26:08 2017 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 8AC23132460 for ; Thu, 10 Aug 2017 13:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 vm5ZllIeeS-K for ; Thu, 10 Aug 2017 13:26:05 -0700 (PDT) Received: from server172-2.web-hosting.com (server172-2.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 8C26213244E for ; Thu, 10 Aug 2017 13:26:04 -0700 (PDT) Received: from [146.96.19.240] (port=53964 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dfu1n-001z2i-4K; Thu, 10 Aug 2017 16:26:03 -0400 From: Dave Rice Message-Id: <28216B34-9D6B-4285-BE16-CC6B82539561@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8626678C-E226-4359-9C6F-60BC21EDF3F8" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Thu, 10 Aug 2017 16:25:57 -0400 In-Reply-To: Cc: Tessa Fallon , Jerome Martinez , Codec Encoding for LossLess Archiving and Realtime transmission To: Ashley Blewer References: X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Matroska: Which comes first, CRC or Timecode? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 10 Aug 2017 20:26:08 -0000 --Apple-Mail=_8626678C-E226-4359-9C6F-60BC21EDF3F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don't think anyone is advocating for Timecode before CRC-32, so maybe = a vote is not necessary. Dave > On Aug 10, 2017, at 4:12 PM, Ashley Blewer = wrote: >=20 > Hmm... not well-versed on the voting, but I don't think so. I think = it's just a matter of opinions interpreting the existing specs and = considering how it has been generally interpreted.=20 >=20 > On Thu, Aug 10, 2017 at 3:14 PM, Tessa Fallon > wrote: > Should this be out to a vote? >=20 > On Aug 10, 2017 11:46, "Jerome Martinez" > wrote: > Le 10/08/2017 =C3=A0 17:23, Ashley Blewer a =C3=A9crit : >>=20 >> For now, I updated the PR with Dave's advice... >>=20 >> The Timecode Element MUST occur as in storage order before any = SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element >=20 > IMHO CRC is general purpose, so "must be first" must be obeyed in = priority. > I would be less limiting the list of blocks after Timecode, something = like "The Timecode Element MUST occur as in storage order before any = element specific to the Cluster Element" (i.e. all nested in the Cluster = element in the specs). >=20 > _______________________________________________ > 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 = >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_8626678C-E226-4359-9C6F-60BC21EDF3F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I don't think anyone is advocating for = Timecode before CRC-32, so maybe a vote is not necessary.
Dave

On Aug 10, 2017, at 4:12 PM, Ashley Blewer = <ashley.blewer@gmail.com> wrote:

Hmm... not well-versed on the voting, but I don't think so. I = think it's just a matter of opinions interpreting the existing specs and = considering how it has been generally interpreted. 

On Thu, = Aug 10, 2017 at 3:14 PM, Tessa Fallon <tessa.fallon@gmail.com> wrote:
Should this be out to a vote?

On Aug 10, 2017 11:46, "Jerome Martinez" = <jerome@mediaarea.net> wrote:
=20 =20 =20
Le = 10/08/2017 =C3=A0 17:23, Ashley Blewer a =C3=A9crit :

For now, I updated the PR with Dave's = advice...

The Timecode Element MUST occur as in storage order before any SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element

IMHO CRC is general purpose, so "must be first" must be obeyed in priority.
I would be less limiting the list of blocks after Timecode, something like "The Timecode Element MUST occur as in storage order before any element specific to the Cluster Element" (i.e. all nested in the Cluster element in the specs).

_______________________________________________
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


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

= --Apple-Mail=_8626678C-E226-4359-9C6F-60BC21EDF3F8-- From nobody Thu Aug 10 23:03:15 2017 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 DD491132478 for ; Thu, 10 Aug 2017 23:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bwufq1EfJIK for ; Thu, 10 Aug 2017 23:03:10 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 89AD3132456 for ; Thu, 10 Aug 2017 23:03:10 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id m88so16798972iod.2 for ; Thu, 10 Aug 2017 23:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OMUpdPjgktrp6wpLKQbSl/w0ycmLfecRIFFYaqHTQZw=; b=UJ/gKfrhbE3RhPhWbkEHW7O1R92N8cRIsJnMyOTkvqopO6wihtiZkBr45qtxR9cEdU Geo4+tCpfgs4BZVQDo8SY3QdWnIDEf0ncycl7GZwOIDv8l2Cfw3/c1jXFiDx02rg//ST 2EGGIK6IQiBr0reVdZabgQ/ZctOdoOfhy10w7iEKMgHjjni1ebdlTNglvWln8YvUy5EX RRlu55/mOEJLvsDRhlllsimaB9yyrLmVov/oNrfCbS9Qn9SjF4LwfzAgluZkCp8Egi9G tZxsQFKqvHo3VMKJ3OzSHm90l15Bopp4bVRGt6jNpe84LSy1lDcRK6M+EFf8q1TbfJ5K l39g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OMUpdPjgktrp6wpLKQbSl/w0ycmLfecRIFFYaqHTQZw=; b=TiQX9c2FNkcXW9iqw9v9JlkAWpY6uVXeSaNimVbM3ZsGlRGkdYVy42GIBlHgVdIwRW PfKjDGPo8+3Io03S9OC5LrLt9dCerJBTQKezIIqmIZ/IDdh3e/VhKwnT8OgxyM3PuFkk sKw8rSGk4vKZjemAAGkQWK/K1K9pP6U2ubKTzczaM2FVJ+o1enGHhSlE4M/Pdou+fggn LXZBX4jRxypINlPyfWI4k3p96rtHI+a4sPfryUqNfRJnm4/Pb+F895lhlQnBd67k6njA 7dVJcMVdo1vxUC8wr9r3eiAuPOBkIhIxLVLErcDnJlx2xnpogxatgH96qK1BN8Q7IePZ QFNg== X-Gm-Message-State: AHYfb5gzW+QDZpGF0LTg2Kx/uiE/EsWkRwCeLATQkDMAC33yQS2nhxM5 rqK0zqhZCLWMIVVDAmFDF6jQT048oA== X-Received: by 10.107.22.65 with SMTP id 62mr11642040iow.32.1502431389868; Thu, 10 Aug 2017 23:03:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.15.213 with HTTP; Thu, 10 Aug 2017 23:03:08 -0700 (PDT) Received: by 10.107.15.213 with HTTP; Thu, 10 Aug 2017 23:03:08 -0700 (PDT) In-Reply-To: <28216B34-9D6B-4285-BE16-CC6B82539561@dericed.com> References: <28216B34-9D6B-4285-BE16-CC6B82539561@dericed.com> From: Tessa Fallon Date: Fri, 11 Aug 2017 02:03:08 -0400 Message-ID: To: Dave Rice Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Jerome Martinez , Ashley Blewer Content-Type: multipart/alternative; boundary="94eb2c05df2a4aeba5055674113f" Archived-At: Subject: Re: [Cellar] Matroska: Which comes first, CRC or Timecode? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 11 Aug 2017 06:03:13 -0000 --94eb2c05df2a4aeba5055674113f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok. I was confused by the PR issue. Please remember that conversations on Github should be in sync with conversations on the list. We do not want two separate conversation streams On Aug 10, 2017 16:26, "Dave Rice" wrote: I don't think anyone is advocating for Timecode before CRC-32, so maybe a vote is not necessary. Dave On Aug 10, 2017, at 4:12 PM, Ashley Blewer wrote: Hmm... not well-versed on the voting, but I don't think so. I think it's just a matter of opinions interpreting the existing specs and considering how it has been generally interpreted. On Thu, Aug 10, 2017 at 3:14 PM, Tessa Fallon wrote: > Should this be out to a vote? > > On Aug 10, 2017 11:46, "Jerome Martinez" wrote: > >> Le 10/08/2017 =C3=A0 17:23, Ashley Blewer a =C3=A9crit : >> >> >> For now, I updated the PR with Dave's advice... >> >> The Timecode Element MUST occur as in storage order before any >> SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element >> >> >> IMHO CRC is general purpose, so "must be first" must be obeyed in >> priority. >> I would be less limiting the list of blocks after Timecode, something >> like "The Timecode Element MUST occur as in storage order before any >> element specific to the Cluster Element" (i.e. all nested in the Cluster >> element in the specs). >> >> _______________________________________________ >> 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 > > _______________________________________________ Cellar mailing list Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar --94eb2c05df2a4aeba5055674113f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok. I was confused by the PR issue.=C2=A0
Please remember that conversations on Github should be in sync= with conversations on the list. We do not want two separate conversation s= treams

<= div class=3D"gmail_quote">On Aug 10, 2017 16:26, "Dave Rice" <= dave@dericed.com> wrote:
I don't think anyone is advocating for Timecode before CRC-32, = so maybe a vote is not necessary.
Dave

On Aug 10, 2017, at 4:12 PM, Ashley Blewer <ashley.blewer@gmail.com> wrote:
Hmm... not well-versed on the voting, but I don't think so.= I think it's just a matter of opinions interpreting the existing specs= and considering how it has been generally interpreted.=C2=A0

On Thu, Aug 10, 2017 at 3= :14 PM, Tessa Fallon <tessa.fallon@gmail.com> wrote:
Should this be out to a v= ote?

On Aug 10, 2017 11:46, "Jerome Ma= rtinez" <= jerome@mediaarea.net> wrote:
=20 =20 =20
Le 10/08/2017 =C3=A0 17:23, Ashley Blewer a =C3=A9crit=C2=A0:

For now, I updated the PR with Dave's advice...

The Timecode Element MUST occur as in storage order before any SimpleBlock, BlockGroup, or EncryptedBlock within the Cluster Element

IMHO CRC is general purpose, so "must be first" must be obeye= d in priority.
I would be less limiting the list of blocks after Timecode, something like "The Timecode Element MUST occur as in storage orde= r before any element specific to the Cluster Element" (i.e. all nest= ed in the Cluster element in the specs).

_______________________________________________
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

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


--94eb2c05df2a4aeba5055674113f-- From nobody Thu Aug 10 23:15:24 2017 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 583301326F2 for ; Thu, 10 Aug 2017 23:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIzYV047uwsQ for ; Thu, 10 Aug 2017 23:15:22 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54781326F1 for ; Thu, 10 Aug 2017 23:15:21 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:37318) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dg3E3-0001Ds-05 for cellar@ietf.org; Fri, 11 Aug 2017 08:15:15 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id CBA916540DA1 for ; Fri, 11 Aug 2017 08:15:14 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0206.598D4B73.0093, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1502432114; bh=9TxtOGVqpIWTFCCVhdV73Bt6KL4W6y2/AdzXgyUyg4E=; h=References:From:To:Cc:Subject:In-reply-to:Date:From; b=CUNisQenMfoJAkqJ+umVHEWMECqP0lMK5HH3+etrS9FvWBuDi/+ZkIlTpcyBLo1bk /sqyepNAw4qvlgT55JmArPziNp+XlRTN9D2ofm1LEJpaun3FRv3kQTBYXdk+vkH5NW gudbQ2OON9u8hVCHY1rfyQvN9cUIyU+9fiJ+G9fALICFcil82lCnqG39m7hFJyUBAv cB8OeX737P0xNE7f388Qpk6cz1zXi7bb3KZl4AFSjZrQTMTx1GwNqI6jl+jquSmA07 ThwHzp7cYKDn6hIuqB/KQOQQRYd2qHMvT2dnmT2NP+hVPo3GL3zXFjNEqgQ5Jz3ADN jtD1rb5E0eUPO3QrMqEwXPNB9Dhj8Jn06mGputo6fDaMXL3kOVBIILXP7auju6TTK/ 8Xs53u8bjlAFwmROcZNDQmMQZQSCUuCiX42OHlGiUgTs9AqhQvi2TG6bDm51yY5kSK K6yFXZGPzPdV/JgSLwp0Z5Nzk6+vVHM1SO3iquIRe36bd3Tyfd3XsGO+P52pNma9hY 1b2AfoconCwMTzdI3p3gdOEwtbCTkJNoVv/RTL57UbefuHz00acfELb2f4ea67IfUj OnZR9gzGIayJNJlYkLtbQicyiXdJsGJQQmbtPBBE2FtaYgqZssFDz9LKPDUM070rfa 1Z5jJ87ZwsMqoLGb6dUnYRdo= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTPS id 157BE1CB26D8 for ; Fri, 11 Aug 2017 08:15:14 +0200 (CEST) References: User-agent: mu4e 0.9.18; emacs 25.2.1 From: Moritz Bunkus To: Codec Encoding for LossLess Archiving and Realtime transmission Cc: In-reply-to: Date: Fri, 11 Aug 2017 08:15:14 +0200 Message-ID: <87lgmqy6j1.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] Matroska: Which comes first, CRC or Timecode? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 11 Aug 2017 06:15:23 -0000 Hey, as the main discussion seems to take place here, I'll repeat what I've written on Github: The intention behind making `Timecode` the first element is that the Timecode is found before the first Element that needs it (BlockGroup or SimpleBlock). Therefore placing the CRC32 Element first wouldn't do any harm. The `Timecode Element` doesn't have to be the first overall, it just has to come before any of {BlockGroup, SimpleBlock, EncryptedBlock}. Therefore I agree with Dave; no one seems to be arguing in favor of placing `Timecode` before `CRC32`; hence no vote seems to be required. We're all in polite agreement and just have to figure out the exact wording. Kind regards, mosu From nobody Thu Aug 10 23:29:11 2017 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 D2F781252BA for ; Thu, 10 Aug 2017 23:29:09 -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 rWKMVoYxi28x for ; Thu, 10 Aug 2017 23:29:07 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97B1132479 for ; Thu, 10 Aug 2017 23:29:07 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 77so23615148itj.1 for ; Thu, 10 Aug 2017 23:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YYwYEeWqn528pMn0u26+ynqld7jPn3VtTa1eAoIo1UU=; b=IUEe9FrghQ9AgPjTRMlVtXcpK0eDGM8wp88IRak5xx4sIFgK0PNOPTbGTGKDqhk+s0 u+yfQTx4EVntBztTZQkSBu2qu++DFGO+SxgdHY+oqF6RY71ieeV5eReuhhPjCE2grIQU sz36f9ah7QgIXe98AaUnq/Ke2IIiwO02kGkOfCfJ9CMIyIRmKeJWdOvRJ85fUrKpM8oB BLVRUXtg4eLAqAxsImueiEwZKcs/uzekv2z/ozsnMfdrm3ONyvch0hrjVgMNSuaw/tAS e8xiPU0xzl3LljLgBSd4pmsj3K4hy7Ab7TUF7dST2Ut+UdFBs+159Z5zJ+aYw9zS7IMc +tPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YYwYEeWqn528pMn0u26+ynqld7jPn3VtTa1eAoIo1UU=; b=ejglJSBFwkTJjyO0xrcNmrm7wj1HbaWIXekyYED70kY5E0ZaOgxERJXv3ZyT3AX5AJ TbM9vdZwfHRih6APMEPEU5iIQ5PQpqd9+fuqm/3EbA2+NnwXaQ9kVPuQXXoSnw7Nx/Op TOmA25zrUzBMBYlwn32VRJYNCU8nYY8ozGM6K6uKY6v8R6viggafBkwMCtEQUEcHmPId BD0P6CrlCqUGjTukyc1BovDAFNQG3Db7LBuoec9xsymu0UoK7CnG/JQ7UWoqKEvYmeso 4z2yyRPKKoKFfqpPmFne82XkJL8pwzaeyoBHM+nX2mpGtiKFW//spOiukN+8k3mDYL1j hc6g== X-Gm-Message-State: AHYfb5jAHKuy8lrbEC9LxqezejOA/XPCi6dTJJ0bwUPUPt1gSc9jnlbR JmRjQ7cGF1mAImVh4bJ6XYazwa1iBw== X-Received: by 10.36.78.83 with SMTP id r80mr11952519ita.131.1502432947012; Thu, 10 Aug 2017 23:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.15.213 with HTTP; Thu, 10 Aug 2017 23:29:06 -0700 (PDT) Received: by 10.107.15.213 with HTTP; Thu, 10 Aug 2017 23:29:06 -0700 (PDT) In-Reply-To: <87lgmqy6j1.fsf@bunkus.org> References: <87lgmqy6j1.fsf@bunkus.org> From: Tessa Fallon Date: Fri, 11 Aug 2017 02:29:06 -0400 Message-ID: To: Moritz Bunkus Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a113a0df61b0c2d0556746e52" Archived-At: Subject: Re: [Cellar] Matroska: Which comes first, CRC or Timecode? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 11 Aug 2017 06:29:10 -0000 --001a113a0df61b0c2d0556746e52 Content-Type: text/plain; charset="UTF-8" Ok, that is fine with me; just checking in. On Aug 11, 2017 02:15, "Moritz Bunkus" wrote: Hey, as the main discussion seems to take place here, I'll repeat what I've written on Github: The intention behind making `Timecode` the first element is that the Timecode is found before the first Element that needs it (BlockGroup or SimpleBlock). Therefore placing the CRC32 Element first wouldn't do any harm. The `Timecode Element` doesn't have to be the first overall, it just has to come before any of {BlockGroup, SimpleBlock, EncryptedBlock}. Therefore I agree with Dave; no one seems to be arguing in favor of placing `Timecode` before `CRC32`; hence no vote seems to be required. We're all in polite agreement and just have to figure out the exact wording. Kind regards, mosu _______________________________________________ Cellar mailing list Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar --001a113a0df61b0c2d0556746e52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, that is fine with me; just checking in.

On Aug 11, 2017 02:15, "Moritz Bunkus" <moritz@bunkus.org> wrote:
Hey,

as the main discussion seems to take place here, I'll repeat what I'= ;ve
written on Github:

The intention behind making `Timecode` the first element is that the
Timecode is found before the first Element that = needs it (BlockGroup or
SimpleBlock). Therefore placing the CRC32 Element first wouldn't do any=
harm. The `Timecode Element` doesn't have to be the first overall= , it just
has to come before any of {BlockGroup, SimpleBlock, EncryptedBlock}.

Therefore I agree with Dave; no one seems to be arguing in favor of placing=
`Timecode` before `CRC32`; hence no vote seems to be required. We're al= l in
polite agreement and just have to figure out the exact wording.

Kind regards,
mosu

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

--001a113a0df61b0c2d0556746e52-- From nobody Sat Aug 12 09:16:24 2017 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 4B41613250B for ; Sat, 12 Aug 2017 09:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 csc_HQrfejj5 for ; Sat, 12 Aug 2017 09:16:21 -0700 (PDT) Received: from server172-2.web-hosting.com (server172-2.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 095ED132509 for ; Sat, 12 Aug 2017 09:16:20 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:40407 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dgZ5H-0044Sp-2A; Sat, 12 Aug 2017 12:16:20 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_2E76EA0D-7EDE-426F-9E1E-24997F26835B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Sat, 12 Aug 2017 12:16:16 -0400 Cc: James Almer , David Singer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] fixing Matroska FieldOrder values and definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 12 Aug 2017 16:16:23 -0000 --Apple-Mail=_2E76EA0D-7EDE-426F-9E1E-24997F26835B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Reporting this issue here for discussion as it is a bit complex and = involves correcting a definition for an Element which is already well in = use. On January 11, 2016 a FieldOrder Element was added to Matroska in this = commit: = https://github.com/Matroska-Org/foundation-source/commit/298ebf318f0794479= ac753eef87d5bbef0abdaf8 = . Prior to this Matroska had a binary value to = say if the frame was interlaced or not but no method to describe the = type of interlacement. The values for FieldOrder were derived from the = Apple QuickTime File Format specification at = https://developer.apple.com/library/content/documentation/QuickTime/QTFF/Q= TFFChap3/qtff3.html = which includes: > 9 =E2=80=93 B is displayed earliest, T is stored first in the file. 14 = =E2=80=93 T is displayed earliest, B is stored first in the file. However in a discussion about the conflict between the Quicktime File = Format specification and another Apple doc at = https://developer.apple.com/library/content/technotes/tn2162/_index.html#/= /apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-THE__FIEL__IMAGEDESCRIPTION_EXT= ENSION__FIELD_FRAME_INFORMATION = , an Apple engineer in this comment = https://github.com/amiaopensource/vrecord/issues/170#issuecomment-32193766= 8 = noted that what Apple does in practice is: > 9 =E2=80=93 T is earlier than B. 14 =E2=80=93 B is earlier than T and noted that > This is, afaik, what we do; the file format documentation appears to = be, um, guilty of, well, wrongness. As a result I=E2=80=99d like to correct the Matroska field order = definitions from=20 9 =3D Interlaced with bottom field displayed first and top field stored = first. 14 =3D Interlaced with top field displayed first and bottom field stored = first. to 9 =3D Top field displayed first. Fields are interleaved in storage with = the top line of the top field stored first. 14 =3D Bottom field displayed first. Fields are interleaved in storage = with the top line of the top field stored first. This flips the existing drafted definitions, but corrects the existing = files created with ffmpeg to match their contents and what is practiced = by Apple in QuickTime, although their specification is wrong. I think = leaving the Matroska FieldOrder definitions would cause more harm as = we=E2=80=99d adopt the same wrongness of the QuickTime specification and = would then consider most real world files with FieldOrder as wrong = according to the specification. I have a pull request for this for consideration at = https://github.com/Matroska-Org/matroska-specification/pull/162 = . Also = please consider this thread which started the consideration of this = issue, https://github.com/amiaopensource/vrecord/issues/170 = . Best Regards, Dave Rice= --Apple-Mail=_2E76EA0D-7EDE-426F-9E1E-24997F26835B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,
Reporting this issue here for = discussion as it is a bit complex and involves correcting a definition = for an Element which is already well in use.

On January 11, 2016 a FieldOrder = Element was added to Matroska in this commit: https://github.com/Matroska-Org/foundation-source/commit/298ebf= 318f0794479ac753eef87d5bbef0abdaf8. Prior to this Matroska had a = binary value to say if the frame was interlaced or not but no method to = describe the type of interlacement. The values for FieldOrder were = derived from the Apple QuickTime File Format specification at https://developer.apple.com/library/content/documentation/Quick= Time/QTFF/QTFFChap3/qtff3.html which includes:
9 =E2=80=93 B is = displayed earliest, T is stored first in the file. 14 =E2=80=93 T is = displayed earliest, B is stored first in the file.

However in a discussion about the = conflict between the Quicktime File Format specification and another = Apple doc at https://developer.apple.com/library/content/technotes/tn2162/_i= ndex.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-THE__FIEL__IMAGEDESC= RIPTION_EXTENSION__FIELD_FRAME_INFORMATION,
an = Apple engineer in this comment https://github.com/amiaopensource/vrecord/issues/170#issuecomme= nt-321937668 noted that what Apple does in practice = is:
9 =E2=80=93 = T is earlier than B. 14 =E2=80=93 B is earlier than T
and = noted that
This = is, afaik, what we do; the file format documentation appears to be, um, = guilty of, well, wrongness.

As a result I=E2=80=99d like to correct the Matroska field = order definitions from 

9 =3D Interlaced with = bottom field displayed first and top field stored first.
14 =3D Interlaced with top field displayed first and bottom = field stored first.

to

9 = =3D Top field displayed first. Fields are interleaved in storage = with the top line of the top field stored first.
14 = =3D Bottom field displayed first. Fields are interleaved in storage = with the top line of the top field stored first.

This flips the existing drafted = definitions, but corrects the existing files created with ffmpeg to = match their contents and what is practiced by Apple in QuickTime, = although their specification is wrong. I think leaving the Matroska = FieldOrder definitions would cause more harm as we=E2=80=99d adopt the = same wrongness of the QuickTime specification and would then consider = most real world files with FieldOrder as wrong according to the = specification.

I= have a pull request for this for consideration at https://github.com/Matroska-Org/matroska-specification/pull/162= . Also please consider this thread which started the consideration = of this issue, https://github.com/amiaopensource/vrecord/issues/170.
=

Best = Regards,
Dave Rice
= --Apple-Mail=_2E76EA0D-7EDE-426F-9E1E-24997F26835B-- From nobody Sat Aug 12 09:27:05 2017 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 71E8A13218F for ; Sat, 12 Aug 2017 09:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDkOzGGwf2Mb for ; Sat, 12 Aug 2017 09:27:02 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF63132190 for ; Sat, 12 Aug 2017 09:27:01 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:54640) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dgZFQ-0000BO-2Y; Sat, 12 Aug 2017 18:26:50 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 964136540DA2; Sat, 12 Aug 2017 18:26:48 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0205.598F2C4A.001D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1502555208; bh=HUGoRsgQtemKY43Hy2TfxgvrUQkUujFWFWWqCxH4If0=; h=References:From:To:Cc:Subject:In-reply-to:Date:From; b=ErKKep6pt2MX6bfsMZalsGjEzROPd4Z98ba1DAs6cr1XXvc2R61xnh1O9TOhLVUJO dM7Er78bRmJE4C4mhdBrFDReBBdgHq30duRgzW0OREUBPEdCGQRA2Bo/Lc61F/lnBX 7qucQtA9v93nzn9Pu6P7pBne3JpkjEdM9iqn6jwCyiAys5+yWZL9OLQh+zMinrrAs2 txMs39sJ0lOCrtBMiG5zh/f2z1NzTsOX70s6DUIfDXYAgLFubMAmOAUGu195lq8LZn iYQvLWZUb8eF1gra87N905cUHwmKqbHfQPvwH77bXm7Xm8TiMVqQx1+k+1LBXUn2KG +9os+td26LK3JYNPhco/gR6Pljp4AOYHwkfYvtSOs2m4A4nON/MLxlfMd3MV8jRk8I +xxnFho3oD/KznmwpQgr78Z0+xNGr8pS4EyRg0dVJh0FZ7229wgj2/qljnapwpGxg4 HOpXvbn/u/zFdobTaHXLIzksRruUMg6OJKM8w8+goYFiQ0k1VgaSPf0PfsJFhNLy3x 6TeM86qstNr57ESKEBacFQC2t43F/aOK2N/tlsT+OxiS73dRVGBR5e8jP3Sm2k0snc cEHc610xcTSp10MYkXHaHBbsz0aO/pEsWgIwyZqXcxt2MObybfpCrdg/4+olQHGuUA w1EmZCHqfP+Cx748Vp4Doz74= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTPS id BDB9C1CE23EC; Sat, 12 Aug 2017 18:26:47 +0200 (CEST) References: User-agent: mu4e 0.9.18; emacs 25.2.1 From: Moritz Bunkus To: Codec Encoding for LossLess Archiving and Realtime transmission , David Singer , James Almer In-reply-to: Date: Sat, 12 Aug 2017 18:26:47 +0200 Message-ID: <87a834iwfs.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] fixing Matroska FieldOrder values and definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 12 Aug 2017 16:27:03 -0000 Hey, thanks for the writeup. I've read the whole issue vrecord#170 and your proposal (though I haven't looked through Apple's documentation that you've linked; I trust you guys to be exact in this). I concur with your proposal & will approve the corresponding PR. Kind regards, mosu From nobody Sat Aug 12 09:46:11 2017 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 2A85B1323A6 for ; Sat, 12 Aug 2017 09:46:10 -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 bZ8Yg9tG8ljp for ; Sat, 12 Aug 2017 09:46:08 -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 3EC1E1323AB for ; Sat, 12 Aug 2017 09:46:08 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id z18so33973364qka.4 for ; Sat, 12 Aug 2017 09:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sXAv2xBk5KmdQur0VY2mEEXgKTjo1oWyCApgOCsGceU=; b=rRVm4TyjKH8ozW7stn9u6nfKXCJB7GsENW+X4xhV2MmeBDpnJpqajTVi5E+UPxMW+G kIcQvk+9noUHWFekWSurXfgBWH4WNW8Z37IEJI6YDx6Fa9/0lxwaxkVKcPhlVLP59Mwc oUbRDOe7s6PNL35Vmt6Inpp4GhJfafAoz1M0MlbWynAvRyZKHRX5bj8b8BCTk7dXBauT aDGprvQueeuVHjGr8nyrGKttX9i3zgkSplDu0vjWzUw7Qrzb8YBVxa6C1dVeocDn03KQ nL3tGNmgN1r45iHCGiE5RsC+3LtE5b/c6gSvWNVAl5d9h7vs86WMk1eCJVhzdRyWD9QU 1bJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sXAv2xBk5KmdQur0VY2mEEXgKTjo1oWyCApgOCsGceU=; b=I+VNUT53n7uEfohN32yefEDPuppqsNn+AX7N0+Gvo/1Wph/VrSyAM4Cx3vk0U0e8BX bm9DLPktz7eIXV4fwOIHC+6k74Y4cB+g/q2p6uEDgOIBAj8X5Cu1RvVPFw81pMSbULoO gCDgi/2cX0/HjMx+/o7ib4pKuOdKvrr/+k1jHWcZDxOPPpFyrDsERTCqFT53Lmx2Ef+N +FY1mT2cvFu3ojDhVf92uElFD83aTJky7q3M4DO06xSXfQmbHLekUtU4YPfdPqZOC53f 4L+MeTJxZH1NtXEbehN4cbi7+AqPZfZo8T5gZEjgjhZx/ZXjLNc9RcDkBe7L7XH8274r o19g== X-Gm-Message-State: AHYfb5j0uyLeBNvJx0anSm9+PahNMZV05IazWD31yLIbsCtQjdvcjbAU CgmqD5wECsZe8FuqVYIcscHFNUrc6q1t X-Received: by 10.55.19.104 with SMTP id d101mr1467569qkh.296.1502556367290; Sat, 12 Aug 2017 09:46:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.22.213 with HTTP; Sat, 12 Aug 2017 09:46:06 -0700 (PDT) Received: by 10.55.22.213 with HTTP; Sat, 12 Aug 2017 09:46:06 -0700 (PDT) In-Reply-To: References: From: Kieran O Leary Date: Sat, 12 Aug 2017 17:46:06 +0100 Message-ID: To: Dave Rice Cc: cellar@ietf.org, James Almer , David Singer Content-Type: multipart/alternative; boundary="001a11400a988707990556912aea" Archived-At: Subject: Re: [Cellar] fixing Matroska FieldOrder values and definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 12 Aug 2017 16:46:10 -0000 --001a11400a988707990556912aea Content-Type: text/plain; charset="UTF-8" I think this should be implemented as it clears up a lot of confusion about real world implementations versus the specifications. Thanks for putting this together. --001a11400a988707990556912aea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this should be implemented as it clears up a lot = of confusion about real world implementations versus the specifications. Th= anks for putting this together.=C2=A0
--001a11400a988707990556912aea-- From nobody Sat Aug 12 09:49:51 2017 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 9AD5713217D for ; Sat, 12 Aug 2017 09:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 cw-Ue1eH2oIY for ; Sat, 12 Aug 2017 09:49:48 -0700 (PDT) Received: from server172-2.web-hosting.com (server172-2.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 B7CEF13208E for ; Sat, 12 Aug 2017 09:49:48 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:47153 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dgZbe-0007vC-Vg; Sat, 12 Aug 2017 12:49:48 -0400 From: Dave Rice Message-Id: <2E927788-DF33-430E-B7E2-CDEF571D0B13@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1B89BB34-6FEB-4D3D-AAD4-01B2A3010BA4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 12 Aug 2017 12:49:44 -0400 In-Reply-To: Cc: David Singer , James Almer To: Codec Encoding for LossLess Archiving and Realtime transmission References: X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] fixing Matroska FieldOrder values and definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 12 Aug 2017 16:49:51 -0000 --Apple-Mail=_1B89BB34-6FEB-4D3D-AAD4-01B2A3010BA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 12, 2017, at 12:16 PM, Dave Rice wrote: >=20 > Hi all, > Reporting this issue here for discussion as it is a bit complex and = involves correcting a definition for an Element which is already well in = use. >=20 > On January 11, 2016 a FieldOrder Element was added to Matroska in this = commit: = https://github.com/Matroska-Org/foundation-source/commit/298ebf318f0794479= ac753eef87d5bbef0abdaf8 = . Prior to this Matroska had a binary value to = say if the frame was interlaced or not but no method to describe the = type of interlacement. The values for FieldOrder were derived from the = Apple QuickTime File Format specification at = https://developer.apple.com/library/content/documentation/QuickTime/QTFF/Q= TFFChap3/qtff3.html = which includes: >> 9 =E2=80=93 B is displayed earliest, T is stored first in the file. = 14 =E2=80=93 T is displayed earliest, B is stored first in the file. >=20 > However in a discussion about the conflict between the Quicktime File = Format specification and another Apple doc at = https://developer.apple.com/library/content/technotes/tn2162/_index.html#/= /apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-THE__FIEL__IMAGEDESCRIPTION_EXT= ENSION__FIELD_FRAME_INFORMATION = , > an Apple engineer in this comment = https://github.com/amiaopensource/vrecord/issues/170#issuecomment-32193766= 8 = noted that what Apple does in practice is: >> 9 =E2=80=93 T is earlier than B. 14 =E2=80=93 B is earlier than T > and noted that >> This is, afaik, what we do; the file format documentation appears to = be, um, guilty of, well, wrongness. >=20 > As a result I=E2=80=99d like to correct the Matroska field order = definitions from=20 >=20 > 9 =3D Interlaced with bottom field displayed first and top field = stored first. > 14 =3D Interlaced with top field displayed first and bottom field = stored first. >=20 > to >=20 > 9 =3D Top field displayed first. Fields are interleaved in storage = with the top line of the top field stored first. > 14 =3D Bottom field displayed first. Fields are interleaved in storage = with the top line of the top field stored first. >=20 > This flips the existing drafted definitions, but corrects the existing = files created with ffmpeg to match their contents and what is practiced = by Apple in QuickTime, although their specification is wrong. I think = leaving the Matroska FieldOrder definitions would cause more harm as = we=E2=80=99d adopt the same wrongness of the QuickTime specification and = would then consider most real world files with FieldOrder as wrong = according to the specification. >=20 > I have a pull request for this for consideration at = https://github.com/Matroska-Org/matroska-specification/pull/162 = . Also = please consider this thread which started the consideration of this = issue, https://github.com/amiaopensource/vrecord/issues/170 = . Relatedly I supplied a patch for ffmpeg on the same issue at = http://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/214848.html = . Best Regards, Dave Rice --Apple-Mail=_1B89BB34-6FEB-4D3D-AAD4-01B2A3010BA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 12, 2017, at 12:16 PM, Dave Rice <dave@dericed.com> = wrote:

Hi all,
Reporting this issue here for discussion as it is a bit = complex and involves correcting a definition for an Element which is = already well in use.

On January 11, 2016 a FieldOrder Element was added to = Matroska in this commit: https://github.com/Matroska-Org/foundation-source/commit/298ebf= 318f0794479ac753eef87d5bbef0abdaf8. Prior to this Matroska had a = binary value to say if the frame was interlaced or not but no method to = describe the type of interlacement. The values for FieldOrder were = derived from the Apple QuickTime File Format specification at https://developer.apple.com/library/content/documentation/Quick= Time/QTFF/QTFFChap3/qtff3.html which includes:
9 =E2=80=93 B is = displayed earliest, T is stored first in the file. 14 =E2=80=93 T is = displayed earliest, B is stored first in the file.

However in a discussion about the = conflict between the Quicktime File Format specification and another = Apple doc at https://developer.apple.com/library/content/technotes/tn2162/_i= ndex.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG10-THE__FIEL__IMAGEDESC= RIPTION_EXTENSION__FIELD_FRAME_INFORMATION,
an = Apple engineer in this comment https://github.com/amiaopensource/vrecord/issues/170#issuecomme= nt-321937668 noted that what Apple does in practice = is:
9 =E2=80=93 = T is earlier than B. 14 =E2=80=93 B is earlier than T
and = noted that
This = is, afaik, what we do; the file format documentation appears to be, um, = guilty of, well, wrongness.

As a result I=E2=80=99d like to correct the Matroska field = order definitions from 

9 =3D Interlaced with = bottom field displayed first and top field stored first.
14 =3D Interlaced with top field displayed first and bottom = field stored first.

to

9 = =3D Top field displayed first. Fields are interleaved in storage = with the top line of the top field stored first.
14 = =3D Bottom field displayed first. Fields are interleaved in storage = with the top line of the top field stored first.

This flips the existing drafted = definitions, but corrects the existing files created with ffmpeg to = match their contents and what is practiced by Apple in QuickTime, = although their specification is wrong. I think leaving the Matroska = FieldOrder definitions would cause more harm as we=E2=80=99d adopt the = same wrongness of the QuickTime specification and would then consider = most real world files with FieldOrder as wrong according to the = specification.

I= have a pull request for this for consideration at https://github.com/Matroska-Org/matroska-specification/pull/162= . Also please consider this thread which started the consideration = of this issue, https://github.com/amiaopensource/vrecord/issues/170.
=

Relatedly I supplied = a patch for ffmpeg on the same issue at http://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/214848.htm= l.
Best Regards,
Dave Rice


= --Apple-Mail=_1B89BB34-6FEB-4D3D-AAD4-01B2A3010BA4-- From nobody Sun Aug 13 12:32:29 2017 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 72C6113268C for ; Sun, 13 Aug 2017 12:32:28 -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 PkU-Qe8TC0l2 for ; Sun, 13 Aug 2017 12:32:26 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CE8132516 for ; Sun, 13 Aug 2017 12:32:26 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id z18so41708955qka.4 for ; Sun, 13 Aug 2017 12:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ECQJqtuwbkuCI3kyow3RPgikm7Ncrm08oHLiVeOdscI=; b=V9fmDv0f4XjA5orWP4yrQcHiTGeUB1Su10HYMYFA2owmr9IdNBn98eVvwEy2tQAVkv nU4yW3KTKdZMRn+/1w7vyslXdwbSqLG4nCeL/z7Ng7OHEuGVcI1vWCmJMIkCkDfWyMbZ IqVLqBVgqCpMbd2zHA8TyPYbdyg/Re4y9bl/uOqJWAqbf7GD7lsP7Fszsmk/pAK71RxS hrupAqIze6VKw3RKbu6cRru3GVgUm4r2YxsVL7vMnEwJSKKiYmEYRkAq77XtAy6quxr1 dupHHxPxr7YdzK3TrO4mF9F7Mm3pF5iPUmkECv8kyz2MtGjqMkFgU5arOtxB9jorMVOc XN4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ECQJqtuwbkuCI3kyow3RPgikm7Ncrm08oHLiVeOdscI=; b=NVyzwNFkGc51KzyOCOx3j+35f+TcANwBtmeyP6cHLT2k7KjgjEwTgvOuuwjX/W1Mgn D85DhEyv0VYugQmHUIhevfldq1e6bBohK7VZAZx2UGAw82mA/itCgBvcte9bEuWv3Hlj 0xSbjJ+7ckES7o1RHhYfEEpYL9W2SQ+tqVEJli7DlNXzSspUBs89hwwl7Z6vRzIgxFvf PogCUwYbMLFVxituisnFdb3v6d5RxJt8G87/wlHaXp9YoIfac2EQtPqNXbErDNbyrB3U 0Ly4BlHWXWCzitGxEkGL5KBkj9OpGvHqT6iUXStN4EWnVAXOOW8uT0jUSOei7iv07azd L2Ag== X-Gm-Message-State: AHYfb5i2epH1EQAengn1Ub20nlJPqATGTSUVd5gnhv4DY9khE35ETLCu U7j/m1AURqlj7Jwj1QG8ClhxgGIwBciQ X-Received: by 10.55.214.4 with SMTP id t4mr20112059qki.252.1502652745639; Sun, 13 Aug 2017 12:32:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.73 with HTTP; Sun, 13 Aug 2017 12:32:25 -0700 (PDT) In-Reply-To: References: <87lgmqy6j1.fsf@bunkus.org> From: Ashley Blewer Date: Sun, 13 Aug 2017 15:32:25 -0400 Message-ID: To: Tessa Fallon Cc: Moritz Bunkus , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a114782ce1feb190556a79b9c" Archived-At: Subject: Re: [Cellar] Matroska: Which comes first, CRC or Timecode? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 19:32:28 -0000 --001a114782ce1feb190556a79b9c Content-Type: text/plain; charset="UTF-8" I updated the PR with Dave's recommended wording and we seem to have consensus there. I would like this PR to be again considered for review! On Fri, Aug 11, 2017 at 2:29 AM, Tessa Fallon wrote: > Ok, that is fine with me; just checking in. > > On Aug 11, 2017 02:15, "Moritz Bunkus" wrote: > > Hey, > > as the main discussion seems to take place here, I'll repeat what I've > written on Github: > > The intention behind making `Timecode` the first element is that the > Timecode is found before the first Element that needs it (BlockGroup or > SimpleBlock). Therefore placing the CRC32 Element first wouldn't do any > harm. The `Timecode Element` doesn't have to be the first overall, it just > has to come before any of {BlockGroup, SimpleBlock, EncryptedBlock}. > > Therefore I agree with Dave; no one seems to be arguing in favor of placing > `Timecode` before `CRC32`; hence no vote seems to be required. We're all in > polite agreement and just have to figure out the exact wording. > > Kind regards, > mosu > > _______________________________________________ > 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 > > --001a114782ce1feb190556a79b9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I updated the PR with Dave's recommended wording and w= e seem to have consensus there. I would like this PR to be again considered= for review!

On Fri, Aug 11, 2017 at 2:29 AM, Tessa Fallon <tessa.fallon@gmail.co= m> wrote:
Ok, that is fine with me; just checking in.

On Aug 11, 2017 02:15, "Moritz Bunkus" <moritz@bunkus.org>= wrote:
Timecode is found before the= first Element that needs it (BlockGroup or
SimpleBlock). Therefore placing the CRC32 Element first wouldn't do any=
harm. The `Timecode Element` doesn't have to be the first overall= , it just
has to come before any of {BlockGroup, SimpleBlock, EncryptedBlock}.

Therefore I agree with Dave; no one seems to be arguing in favor of placing=
`Timecode` before `CRC32`; hence no vote seems to be required. We're al= l in
polite agreement and just have to figure out the exact wording.

Kind regards,
mosu

_______________________________________________
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

--001a114782ce1feb190556a79b9c-- From nobody Sun Aug 13 12:52:09 2017 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 C09D71324E9 for ; Sun, 13 Aug 2017 12:52:07 -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 bgt-qM6wyYX5 for ; Sun, 13 Aug 2017 12:52:05 -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 643B51324DD for ; Sun, 13 Aug 2017 12:52:05 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id d136so42117528qkg.3 for ; Sun, 13 Aug 2017 12:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=scJ4t9yIcG6VwJmgQKb2gwYhqF6ZolYAow4wtOlylWc=; b=B4DyG942xM0eZiQTrO34EQtx6at3qAioCMOY1yW2ey/l80G+Gy62zl+ITtEK0p9f1X AIQS5d2Z57HexWjjSVZgz+u16QNqXBL7q1RpccZYQUKNSZe3qOyWdGfH0MTD58VSR7CB GyEYV3bqfsY7jwuLKTLP+wS5VZi8HosFpQyETlvQBZ1/gcsw595yd2Jw5QbtNFeskywL LrYxDTKpK1ShHoPqsDGpzuZla3Fg/0jXANFyVnrdGuASjvL+aD68PbHbRG1v6cqvASH+ nm9uW1f9q6Rq9xBeyywWXXyWFptuljqMrr+vBJ0mDpaHjM4Us3NleSqb2ZK5fwrEZiAz /ATg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=scJ4t9yIcG6VwJmgQKb2gwYhqF6ZolYAow4wtOlylWc=; b=GCIZ6FDd7K5ye+dGArstVqaM7lS5FGXF+Ci6ktxLUWxwItz0e0jlvvv3M51QRvzPmz QBXFYGpPqGMmwICwQS/hGsody5ZDqoBaP1kbCvtEAz3fsxEgdJqAm9/1Ac2VZJZj0eFf ijTp2WLi68trDJo+S4Wvr/5yXmtN8XDegLAymMSLRbK8h2ZGhIpOB6DSZiWxqXAgDzD8 3huTzd7+uUROrI81mMiQXPwPEjwREG2PdtdRUxcsDQVKKu0e0j1YDFkXQo72i6EsZJ93 n0r+BP/OZfxjqn6FdLL0DGHCum3dGdNGElRC/ztYAtGxF2HYnbtfyBH7B2H4PeAhPC7w NIPQ== X-Gm-Message-State: AHYfb5iIH1UqmVyupfSJ8gf17ua7gPL9M0WNNkNQRInt+KZDcpmJs5TF c2Phf7BsRmQX7DjYZN48L5Sm9pwX+W+PO2k= X-Received: by 10.55.46.66 with SMTP id u63mr29005579qkh.333.1502653924326; Sun, 13 Aug 2017 12:52:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.73 with HTTP; Sun, 13 Aug 2017 12:52:03 -0700 (PDT) From: Ashley Blewer Date: Sun, 13 Aug 2017 15:52:03 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a114f64166144e10556a7e1a1" Archived-At: Subject: [Cellar] Matroska: Nesting subtitle info under one Subtitle section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 19:52:08 -0000 --001a114f64166144e10556a7e1a1 Content-Type: text/plain; charset="UTF-8" PR here: https://github.com/Matroska-Org/matroska-specification/pull/163 Proposal to congregate all subtitles information under one main Subtitles section, instead of having different subtitles as their own top-level section. Right now, the built specification has each taking up a line, like: ``` 32. Subtitles . . . . . . . . . . . . . . . . . . . . . . . . . . 174 33. Images Subtitles . . . . . . . . . . . . . . . . . . . . . . 174 34. SRT Subtitles . . . . . . . . . . . . . . . . . . . . . . . . 177 35. SSA/ASS Subtitles . . . . . . . . . . . . . . . . . . . . . . 178 36. USF Subtitles . . . . . . . . . . . . . . . . . . . . . . . . 181 37. WebVTT . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 ``` ...etc. This would nest them all under section 32. Ashley --001a114f64166144e10556a7e1a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
PR here:=C2=A0https://github.com/Matroska-Org/matroska-sp= ecification/pull/163

Proposal to congregate all= subtitles information under one main Subtitles section, instead of having = different subtitles as their own top-level section.

Right now, the built specification has each taking up a line, like:
=

```
32. Subtitles . . . . . . . . . . . . . .= . . . . . . . . . . . . 174
=C2=A0 =C2=A033. Images Subtitles = =C2=A0. . . . . . . . . . . . . . . . . . . . . . 174
=C2=A0 =C2= =A034. SRT Subtitles . . . . . . . . . . . . . . . . . . . . . . . . 177
=C2=A0 =C2=A035. SSA/ASS Subtitles . . . . . . . . . . . . . . . . = . . . . . . 178
=C2=A0 =C2=A036. USF Subtitles . . . . . . . . . = . . . . . . . . . . . . . . . 181
=C2=A0 =C2=A037. WebVTT =C2=A0.= . . . . . . . . . . . . . . . . . . . . . . . . . . 181
```
...etc.

This would nest them all under secti= on 32.

Ashley
--001a114f64166144e10556a7e1a1-- From nobody Sun Aug 13 13:39:05 2017 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 BE1CA13293C for ; Sun, 13 Aug 2017 13:39:02 -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 8nr7ZQ8b0Kcb for ; Sun, 13 Aug 2017 13:39:01 -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 CF514132520 for ; Sun, 13 Aug 2017 13:39:00 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id a77so42128233qkb.0 for ; Sun, 13 Aug 2017 13:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Aa4TfydVNgj0sDR/iXMzXMPqRceeVLnRJbPijAfhduc=; b=Og2lZLjtOrfx9lvtKOOiEdUk6hTDeeUTHXgECMfxnxVVfFoAKW3KeQ5z0npemlT7k0 lSX5frplNbJe1EegntVaa5lTyM6LQkSX7Ky7hw0UXhZLMk+4u04g73dTe8RZFkqn1dui qjffw+TL9bG+k8+CgA9YZVGGFCF0h9XmMkD96x9JFs7a43BA4xOwOxbQq68WwvQukdpt B4uIaCrB9X8OJYdlVJvxBnB5qa1+Jm/5mglYYha2nS/nZDIYhxtsRseiSBEVIIKa9dz6 WRc7qAvCQG0rRkQGxIka2So2XxzkzcRQgoq+3fH3MdHM4nP+0gQmq7z44ej4reAa2kQr LWOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Aa4TfydVNgj0sDR/iXMzXMPqRceeVLnRJbPijAfhduc=; b=Zs4f1HMJcUEmfjDde+Madrujq2QDF6B3Dccm7ZgYFcI8/fw/Lyv+y8hDDwGoA7/zhd kxFV1LRivnoVwTwhdO5q06WaJPNrg73w3PXTCUnKdrRMtrufx/h7MjE1LBbA8bbWSaHg TIFr3+C3cSWbSOuabQ9xmAfZa0rYKySfwXlSMTMLHMsrTqJPescMf8liJMThHd2wYbmO o/UOQH/V3rh2blJFzZA2XOkAkuWIVmZ+O1NAtjrUWwU4NToVT32JE3oqi+sQJt4gLlpV DJEHUVyhsLUEhAdWTi7WqWPt5fNwT2PwOicU2zEepOeUld1vwYxJJIu/iKYfBYH+7osB nVvw== X-Gm-Message-State: AHYfb5iW12vv/uAVezE38gjdht9OMc/LPUlEIPfaQXWpqztdnDfbTA18 FcmzlGILPXXT8VJB4W09i7Tj7VvwJHa85+o= X-Received: by 10.55.20.21 with SMTP id e21mr5315820qkh.82.1502656739781; Sun, 13 Aug 2017 13:38:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.73 with HTTP; Sun, 13 Aug 2017 13:38:59 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Sun, 13 Aug 2017 16:38:59 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a113a0c5831b09e0556a88905" Archived-At: Subject: Re: [Cellar] Matroska: Nesting subtitle info under one Subtitle section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 20:39:03 -0000 --001a113a0c5831b09e0556a88905 Content-Type: text/plain; charset="UTF-8" Here's another small PR for the Menu and Streaming sections, following the same pattern and tidying up the document: https://github.com/Matroska-Org/matroska-specification/pull/164 On Sun, Aug 13, 2017 at 3:52 PM, Ashley Blewer wrote: > PR here: https://github.com/Matroska-Org/matroska-specification/pull/163 > > Proposal to congregate all subtitles information under one main Subtitles > section, instead of having different subtitles as their own top-level > section. > > Right now, the built specification has each taking up a line, like: > > ``` > 32. Subtitles . . . . . . . . . . . . . . . . . . . . . . . . . . 174 > 33. Images Subtitles . . . . . . . . . . . . . . . . . . . . . . 174 > 34. SRT Subtitles . . . . . . . . . . . . . . . . . . . . . . . . 177 > 35. SSA/ASS Subtitles . . . . . . . . . . . . . . . . . . . . . . 178 > 36. USF Subtitles . . . . . . . . . . . . . . . . . . . . . . . . 181 > 37. WebVTT . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 > ``` > ...etc. > > This would nest them all under section 32. > > Ashley > --001a113a0c5831b09e0556a88905 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's another small PR for the Menu and Streaming sec= tions, following the same pattern and tidying up the document:=C2=A0https:= //github.com/Matroska-Org/matroska-specification/pull/164



On Sun, Aug 13, 2017 at 3:52 PM, Ashley Blewer <<= a href=3D"mailto:ashley.blewer@gmail.com" target=3D"_blank">ashley.blewer@g= mail.com> wrote:
PR here:=C2=A0https://github.com/Matroska-= Org/matroska-specification/pull/163

Propos= al to congregate all subtitles information under one main Subtitles section= , instead of having different subtitles as their own top-level section.

Right now, the built specification has each taking up= a line, like:

```
32. Subtitles . . . .= . . . . . . . . . . . . . . . . . . . . . . 174
=C2=A0 =C2=A033.= Images Subtitles =C2=A0. . . . . . . . . . . . . . . . . . . . . . 174
=C2=A0 =C2=A034. SRT Subtitles . . . . . . . . . . . . . . . . . . .= . . . . . 177
=C2=A0 =C2=A035. SSA/ASS Subtitles . . . . . . . .= . . . . . . . . . . . . . . 178
=C2=A0 =C2=A036. USF Subtitles .= . . . . . . . . . . . . . . . . . . . . . . . 181
=C2=A0 =C2=A03= 7. WebVTT =C2=A0. . . . . . . . . . . . . . . . . . . . . . . . . . . 181
```
...etc.

This would nest the= m all under section 32.

Ashley

--001a113a0c5831b09e0556a88905-- From nobody Sun Aug 13 19:47:25 2017 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 4DA351200C5 for ; Sun, 13 Aug 2017 19:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7c8otM5qYvt for ; Sun, 13 Aug 2017 19:47:20 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 26E6212008A for ; Sun, 13 Aug 2017 19:47:19 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id d29so32108671uai.2 for ; Sun, 13 Aug 2017 19:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=CXOFJlxLtTZpOLFVVCX2TK0QG7hqJoIOBccL23pjiNs=; b=AlaKtjtiL6neGFlHzFTDQx60xPL6WdU9gxKQhi3FdO9XOLjgy2J1gzrT/PxbtPfZ5w QrXyKn2TeqZJpWOAWJk913StbpkxICWjvVkNysh9+7t3+sIjPBpCsaZHfVH2PN7xirim XjXlfAIhr3bVy8wOY2I7TsrQPyWXi1V4b2Qa7efJmcJuDsbsOGGkOR7Bi3Doz35mL/d6 FLpgQyFvGVa/4GdiZDvizkyy9qrsPtaNlBy/JhGqbAnFwkHCz/AnuNz2lXXjsnYHXSoe jwclz5Wvtzvg8T6ZFlexzjba5sEbbPDxRjue3eZMuYP/R34x5s2y3kfkfb/cpmMlIznr K7Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=CXOFJlxLtTZpOLFVVCX2TK0QG7hqJoIOBccL23pjiNs=; b=oTBk3VV0VZK6VaP9iFl8+iRGjPBJ8x6NS8TKiFZJx219o2LD4CIFoD9JZo/Pna36qs BV+tz3w3pFoR2iCeojafXlQ8C/3iSCAvsxLJnBUWdiJ1gOa3nlFI3Ju2LFotik1Efzeb ixSF5VdlX6ITideAChYKUsrgAWu+eczD1cUUnv0dnOMsW+NisJqk4Utgb8/JkbJsYatv wss/S9mwZX7iAw8brYm5UPWzByksaabhcoq/lPTfQFiPhTj+EpON3YNQN9MAHQ1qtoPh lleeuXUemRy531VWaanjcmYrii5uebwhAkco1JGFucyk6ZdAY+R9QkyBlMEWwc7bzt7O aYww== X-Gm-Message-State: AHYfb5jP3uYxYovplBoiLsIBPhB+y2K2llJy7K1DdXDEx+CK3CGqTYHf 0eS508denu33qjGwU/KmjUk1PyIhHg== X-Received: by 10.176.92.111 with SMTP id a47mr16724843uag.219.1502678838824; Sun, 13 Aug 2017 19:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.107.67 with HTTP; Sun, 13 Aug 2017 19:47:18 -0700 (PDT) In-Reply-To: <538B01A1-5411-43B4-818C-82A704370CD4@gmail.com> References: <538B01A1-5411-43B4-818C-82A704370CD4@gmail.com> From: Katherine Frances Date: Mon, 14 Aug 2017 14:47:18 +1200 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary="f403043eb8f46654f70556adaed1" Archived-At: Subject: Re: [Cellar] Contributing recommendations (for new users) (according to me) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 02:47:23 -0000 --f403043eb8f46654f70556adaed1 Content-Type: text/plain; charset="UTF-8" Hey Ashley, Thanks for this timely post. Dave Rice contacted me some months ago to help with the specs, but new job & general life responsibilities got in the way. So it's a useful mail for me, hopefully I can dive into some spec work in the next while! Cheers, K On Tue, Aug 8, 2017 at 12:09 PM, Ashley Blewer wrote: > Hi CELLAR, > > I've talked to a couple of lurkers on this list that want to get involved > but don't know where to start. Here are a few guidelines just based on my > experience: > > EBML, Matroska, FFV1, FLAC: > > Review for inconsistencies: typos, contradictions, ambiguity in the > documentation. So just picking one of the specs and giving it a good review > is incredibly helpful. The Matroska spec needs a lot of work here, as it is > written in a colloquial manner inconsistent with "standards-style" > language. There's plenty of work to do before that can really start to > matter, but it's a good starting point to get familiar with the docs. > That's what I've started doing. This can be brought up on the CELLAR list > (preferred), brought up as a Github issue for the specification, or a pull > request can be sent to change the codebase and a conversation can happen > there. > > Specs can be reviewed purely with an eye towards compliance with RFC2119 ( > https://www.ietf.org/rfc/rfc2119.txt): Are these words being used > appropriately? Is there something listed as a SHOULD but should be a MUST? > Is the word being used but not capitalized, and so recommendation is being > unintentionally implied, and the word should either become full-caps or > changed? This kind of tedious-work passthrough is a good way to familiarize > yourself with one of the documents with plans to analyze more specifically > later. > > EBML: > > EBML is in a more advanced stage than others, but can still use more eyes > for general review. This initial review of EBML is helpful as a guideline > for what to look for and how to look for it: https://mailarchive.ietf.o > rg/arch/msg/cellar/Mfj44tK1gyfqjU3Uu1tI5fMovtk > > Matroska: > > I've been just doing that general work of cleaning up language and looking > for inconsistencies. Matroska docs are VERY long and helpful for users but > less "specification standard". Lots of eyes here would be helpful since > there is a lot of ground to cover. There's a handful of issues on the > Github tracker (https://github.com/Matroska-O > rg/matroska-specification/issues) but not sure how many are suitable for > novices. A review of the Matroska spec that seeks for any redundant or > conflicting information is a worthwhile endeavor. We are very fortunate to > have Moritz and Steve as active members and contributors to this group. :) > > FFV1: > > FFV1 is a little harder to break into, but there was a review by Derek > Buitenhuis posted to the CELLAR list on July 28 pointing out questions ( > https://mailarchive.ietf.org/arch/msg/cellar/qItSPq06vc9MaxsZFPJ3GmREsr4 ). > Work towards reviewing and deciding what can be done with this can be used > as a basis for where to start looking. Again, just searching for typos and > contradictions and noting them is important. > > FLAC: > > FLAC has some issues on the issue tracker that could be worked on: > https://github.com/privatezero/flac_markdown/issues > > Issue #25 is of note -- when I have more time, I'll dig into that one a > bit more and make new tickets. It seems like the code and the specification > have diverged slightly in terms of what things are named, and the spec > should be updated to reflect what is in the source code. That's some fun > ("fun") digging-around work that takes time but isn't intrinsically hard or > requires expertise in the languages. The original ticket is about getting > anchors to work, there's some discussion in the ticket about what to do > about that. > > In general, FLAC needs a more permanent Github home that isn't Andrew's > personal Github (as reported by the IETF meeting notes -- unsure what kind > of nudging should be done here), and more nudging on the flac-dev list > about any questions in the spec that need explaining. It'd be good to get a > closer feedback loop with the FLAC crew, which can be done by bringing up > issues on both listservs. Not that much work has been started on FLAC yet > so it's open terrain. > > Overall, just reading and questioning the specifications is valuable work. > > If you are not very familiar with Github or are generally unsure how to > contribute there, please feel free to contact me off-list and I'd be happy > to explain/clarify questions. > > My best, > > Ashley > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --f403043eb8f46654f70556adaed1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Ashley,

Thanks for this = timely post. Dave Rice contacted me some months ago to help with the specs,= but new job & general life responsibilities got in the way. So it'= s a useful mail for me, hopefully I can dive into some spec work in the nex= t while!

Cheers, K

=

On Tue, Aug 8, 20= 17 at 12:09 PM, Ashley Blewer <ashley.blewer@gmail.com> wrote:
Hi CELLAR,

I'= ve talked to a couple of lurkers on this list that want to get involved but= don't know where to start. Here are a few guidelines just based on my = experience:

EBML, Matroska, FFV1, FLAC:

Review for inconsistencies: typos, contradict= ions, ambiguity in the documentation. So just picking one of the specs and = giving it a good review is incredibly helpful. The Matroska spec needs a lo= t of work here, as it is written in a colloquial manner inconsistent with &= quot;standards-style" language. There's plenty of work to do befor= e that can really start to matter, but it's a good starting point to ge= t familiar with the docs. That's what I've started doing. This can = be brought up on the CELLAR list (preferred), brought up as a Github issue = for the specification, or a pull request can be sent to change the codebase= and a conversation can happen there.

Specs can be reviewed purely with an eye t= owards compliance with RFC2119 (https://www.ietf.org/rfc/rfc2119.txt): Are= these words being used appropriately? Is there something listed as a SHOUL= D but should be a MUST? Is the word being used but not capitalized, and so = recommendation is being unintentionally implied, and the word should either= become full-caps or changed? This kind of tedious-work passthrough is a go= od way to familiarize yourself with one of the documents with plans to anal= yze more specifically later.=C2=A0

EBML:

EBML is in a more advanced stage than others= , but can still use more eyes for general review. This initial review of EB= ML is helpful as a guideline for what to look for and how to look for it:= =C2=A0https://mailarchive.ietf.org/arch/ms= g/cellar/Mfj44tK1gyfqjU3Uu1tI5fMovtk

Matroska:

I've been just doing tha= t general work of cleaning up language and looking for inconsistencies. Mat= roska docs are VERY long and helpful for users but less "specification= standard". Lots of eyes here would be helpful since there is a lot of= ground to cover. There's a handful of issues on the Github tracker (https://github.com/Matroska-Org/matroska-specification/= issues) but not sure how many are suitable for novices. A review o= f the Matroska spec that seeks for any redundant or conflicting information= is a worthwhile endeavor. We are very fortunate to have Moritz and Steve a= s active members and contributors to this group. :)=C2=A0
=
= FFV1:

FFV1 is a little hard= er to break into, but there was a review by Derek Buitenhuis posted to the = CELLAR list on July 28 pointing out questions (=C2=A0https://mailarchive.ietf.org/arch/msg/cellar/qItSPq06vc9Max= sZFPJ3GmREsr4=C2=A0). Work towards reviewing and deciding what can be d= one with this can be used as a basis for where to start looking. Again, jus= t searching for typos and contradictions and noting them is important.

FLAC:

FLAC has= some issues on the issue tracker that could be worked on:=C2=A0http= s://github.com/privatezero/flac_markdown/issues
<= span style=3D"background-color:rgba(255,255,255,0)">
<= span style=3D"background-color:rgba(255,255,255,0)">Issue #25 is of note --= when I have more time, I'll dig into that one a bit more and make new = tickets. It seems like the code and the specification have diverged slightl= y in terms of what things are named, and the spec should be updated to refl= ect what is in the source code. That's some fun ("fun") diggi= ng-around work that takes time but isn't intrinsically hard or requires= expertise in the languages. The original ticket is about getting anchors t= o work, there's some discussion in the ticket about what to do about th= at.
<= br>
I= n general, FLAC needs a more permanent Github home that isn't Andrew= 9;s personal Github (as reported by the IETF meeting notes -- unsure what k= ind of nudging should be done here), and more nudging on the flac-dev list = about any questions in the spec that need explaining. It'd be good to g= et a closer feedback loop with the FLAC crew, which can be done by bringing= up issues on both listservs. Not that much work has been started on FLAC y= et so it's open terrain.=C2=A0

Overall, just reading and questioning the spe= cifications is valuable work.

If you are not very familiar with Github or are ge= nerally unsure how to contribute there, please feel free to contact me off-= list and I'd be happy to explain/clarify questions.

My best,

Ashley=C2=A0<= /div>

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

--f403043eb8f46654f70556adaed1-- From nobody Sat Aug 19 00:24:16 2017 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 1B00F1326E9 for ; Sat, 19 Aug 2017 00:24:14 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNatUtCpcrDl for ; Sat, 19 Aug 2017 00:24:12 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F08132355 for ; Sat, 19 Aug 2017 00:24:12 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:53470) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1diy70-0008Fz-1n; Sat, 19 Aug 2017 09:24:02 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 3AA4F6540ED8; Sat, 19 Aug 2017 09:24:02 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0206.5997E792.00A9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1503127442; bh=aT4fdZQEcRzol615RFNYFkpRMrUcHgzLNA4IwcJPHtQ=; h=From:To:Cc:Subject:Date:From; b=v1vNPreD010LElMthJdpyMt5BoeLkr6cM/+WQeYpASVwnuctT2tfEqnmkwV0eu01F r8TekQ8R2jE6XveY8C/PkuV92LK5twksYEoIpk35Ec21XeTDoePmcbQCx2+kK8uhI0 5e6pzCrrA6VTPhKEHa1OGebk2JYSd/UstHk9l2Q9i8Lct//UzYn0ZmnPVUpSvUPWja W7TzhMlTbiEJmt4GP/bse5pm44vo4v9a7UBLkGs2O/Owe5DqIMGN6J8Lf37+qKwS3v JoW6Ml5SnJyB76aa2u7glhk0FEwEBb1nkPPrUg1T9Sy+TRs87H9NK9FEYcts9qm3Sz c6L2wQie9ERlD2JgE9SliqQ87PcmwZ0vGiABlobXTCJq91wiUSr7F11l6irI76JWqr 4KnDI5mrmRI/NsPwABo+dzWG56eIHGW5KtwRnxjpDM04shD5Z+0W/BeZOvrxgTbKzN UvRVbhD3zotQ0ie4RbA6qkX3kzXVPLRWGgTi2Uq9y3nm/D4ajWrZuKaUkvSjaNypr4 pBEPgf4YNcn1+PE8J5RaZSZILl32JQ9pwTrhYiEZZFKsb8yyGF7WBNgdFpm56TG68I fOB/Blfky0dpsqnPWy/gG+sJUc1rtg1B3LkC0L51LrWFfBszueE4hh8xUFmnzKdyGt 9CyexyhVCSXRyndYLlHxyaVo= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTPS id A604A1D599A7; Sat, 19 Aug 2017 09:24:01 +0200 (CEST) User-agent: mu4e 0.9.18; emacs 25.2.1 From: Moritz Bunkus To: matroska-devel Cc: CELLAR list Date: Sat, 19 Aug 2017 09:24:01 +0200 Message-ID: <87pobsc966.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Cellar] libEBML v1.3.5 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 19 Aug 2017 07:24:14 -0000 Hey, I've released new versions of libEBML (v1.3.5). Download link for the impatient: https://dl.matroska.org/downloads/libebml/libebml-1.3.5.tar.xz Note that compressions' been switched from bzip2 to xz, hence a different extension. The library is API and ABI compatible with previous 1.3.x releases and did not have its .so version bumped. It contains a couple of minor fixes and a major change in behavior regarding writing EbmlMaster elements and mandatory elements with known default values. The upcoming release of MKVToolNix will rely on that new behavior and will therefore require libebml 1.3.5. Here's libEBML's ChangeLog since the previous release (v1.3.4): ---------------------------------------------------------------------- 2017-08-19 Moritz Bunkus * Released v1.3.5. 2017-08-09 Moritz Bunkus * The function EbmlMaster::CheckMandatory() will now only return false if a mandatory element is missing for which there's no default value in the specifications. This means that callers such as EbmlMaster::UpdateSize() and by extension EbmlMaster::Render() will not insist on all mandatory elements being present anymore, but only those for which there's no default value. 2017-08-06 Moritz Bunkus * Added a template function `FindNextChild`. Patch by C.W. Betts. 2017-08-04 Steve Lhomme * Fix reading and EBML element even though the ID was not found within the allowed reading limit. 2016-11-28 Moritz Bunkus * Fixed an instance of undefined behavior in EbmlElement::GetSemantic() due to binding a dereferenced null pointer to a reference. 2016-07-15 Moritz Bunkus * Replaced the outdated address of the Free Software Foundation with their current one. Fixes #15. ---------------------------------------------------------------------- Have fun. Kind regards, mosu From nobody Sat Aug 19 01:19:54 2017 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 93BC41326F6 for ; Sat, 19 Aug 2017 01:19:53 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMcHo95jq0K4 for ; Sat, 19 Aug 2017 01:19:52 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39F613239C for ; Sat, 19 Aug 2017 01:19:51 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:60208) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1diyyt-0000i1-11 for cellar@ietf.org; Sat, 19 Aug 2017 10:19:43 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id E89166540ED8; Sat, 19 Aug 2017 10:19:42 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0201.5997F49F.0085, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1503130783; bh=2P/IJSTVgq8qcZ7ZoR0r8O8u4Vw+c7ceiPl7c3kv5zE=; h=From:To:Subject:Date:From; b=KQiQVRssTzX+z+HPTkoamYf7dnjHVDn7xd2xDsflVV7JmFkUc2mizC307tUvIsEYH STpkkFzzQPmEhgCz1R1zl+8U+X1M9SbD2acIcMP5vIZrvGwiRy0Ee25cJp1fYvaUOh kuiQdiXIRuXLY4uiffKHKtyafyxxOtgdqS5iGpLef8bp2giJGMSG/ujve4vABOa8iJ 1kKgRpSBZVXYNVSQKPIJ8s35NXxY+XkWO+wt3nfMtt5959puXDqy1QlG+ZO5YxUlkG 6p9yzeEgxkKgCpSmoWzUEeXJ523yYSUuTO3AvZWLdkXbFUaRCHvGqvjGM/DHGynB8K EPSKjg9bxEo8+VCV+l9vOWAG3fOz1PK49Xow1wrYPwilgS89lZ92nHC/k2svD+j3cJ ZpfOB9P+bFN+BXHi2fmrmQ/EoU47NUCG4wzRyfifTanfc4DwawruUAlqSSxzhVmH4S afCNAh0K+bEq29VgJWm6naxCjeokCDSI+JKJ+sLEr0DP+UHvzfehDCceGZepfkJknC 7Qz+idQYqAaTTKjMvm5cVCW1B4paTO8VTa/+RXRdhH7s+J0gGvY+V4fXz3IyVoRKVS FA4W3RxaHGtBTYP+F+lNPqmJDY1P2ugp2YaT+Nv/PAn6QV5CZesiIlTkTKjttLGc9I oSPi5YRQosfjKvImidHcCEjU= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTPS id EB1F51D5EC66; Sat, 19 Aug 2017 10:19:41 +0200 (CEST) User-agent: mu4e 0.9.18; emacs 25.2.1 From: Moritz Bunkus To: matroska-users , Cellar list Date: Sat, 19 Aug 2017 10:19:41 +0200 Message-ID: <87o9rcc6le.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cellar] MKVToolNix v15.0.0 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 19 Aug 2017 08:19:54 -0000 Hey, Here's the brand new version 15.0.0 of MKVToolNix. A lot of work has gone into improving support for new track header elements important for video archival purposes. A couple of bugs have been fixed, too, as usual. Changes for package maintainers: libEBML v1.3.5 is now required. An option has been added to 'configure' for compiling without the code that checks online for new releases. See below for details. **Deprecation warning** This is a reminder that certain features having been deprecated since v9.7.0. They're scheduled to be removed in the first release of 2018. These features are: * mkvmerge: the options "--identify-verbose", "--identify-for-gui", "--identify-for-mmg" and "--identification-format verbose" (use "--identification-format json --identify" or its short form "-J" instead) * all command line tools: the old, proprietary format used for option files (use JSON option files instead) Here are the usual links: …to the source code: https://mkvtoolnix.download/source.html …to the binaries: https://mkvtoolnix.download/downloads.html The Windows and macOS binaries have already been built and uploaded. Linux binaries are still being built and will be available shortly. Here are the NEWS since the previous release: ------------------------------------------------------------ # Version 15.0.0 "Duel with the Devil" 2017-08-19 ## Important notes * mkvmerge, mkvpropedit, GUI's header and chapter editors: the programs will no longer add most missing Matroska elements that are mandatory but have a default value in the Matroska specification (e.g. the `TagLanguage` element with a value of `und` if it isn't present in its `SimpleTag` parent). Due to this change libEBML v1.3.5 is now required. ## New features and enhancements * MKVToolNix GUI: multiplex tool: added a new entry to the "source files" context menu labeled "Set destination file name from selected file's name". It will force the GUI to consider the selected file to be the reference for automatically setting the file name, no matter which file was originally added as the first file. It will also force setting the destination file name once if automatic destination file name generation is turned off in the preferences. Implements part of #2058. * MKVToolNix GUI: multiplex tool: added an option in the preferences on "Multiplexer" → "Output" labeled "Only use the first source file that contains a video track". If enabled, only source files containing video tracks will be used for setting the destination file name. Other files that are added are ignore. Implements the rest of #2058. * MKVToolNix GUI: header editor: added support for editing the video colour attributes. Implements the second half of #2038. * MKVToolNix GUI: header editor: added support for the "video projection" track header attributes. Part of the implementation of #2064. * MKVToolNix GUI: job queue: selected jobs can now be move up and down by pressing the `Ctrl+Up` and `Ctrl+Down` keys. Additionally, push buttons to move them up & down are shown if the corresponding option is enabled in the preferences. Implements #2060. * mkvmerge: added support for the "video projection" track header attributes. Part of the implementation of #2064. * mkvinfo: added support for the "video projection" track header attributes. Part of the implementation of #2064. * mkvpropedit: added support for editing the video colour attributes. Implements one half of #2038. * mkvpropedit: added support for the "video projection" track header attributes. Part of the implementation of #2064. ## Bug fixes * all: selecting the program's language (e.g. via the `--ui-language` command-line option or via the GUI's preferences) did not work on Linux & Unix if the `LANGUAGE` environment variable was set and didn't include the desired language. Fixes #2070. * MKVToolNix GUI: removed the keyboard shortcuts for switching between the different tools (e.g. `Ctrl+Alt+1` for the multiplexer). They overlapped with basic functionality on keyboards that use an `AltGr` key, e.g. German ones, where `AltGr+7` emits `{`. As `AltGr+key` is implemented as `Ctrl+Alt+key` under the hood, this means that `AltGr+7` is really `Ctrl+Alt+7` which the GUI now took to mean "switch to the job queue" instead of "insert `{`". Fixes #2056. * MKVToolNix GUI: header editor: after saving the file the GUI wasn't updating its internal file modification timestamp. That lead to the GUI wrongfully claiming that the file had been modified externally when the user wanted to save the file once more, requiring a reload of the file losing all modifications made since saving the first time. * mkvmerge: DTS handling: some source files provide timestamps for audio tracks only once every `n` audio frames. In such situations mkvmerge was buffering too much data resulting in a single gap in the timestamps of one frame duration after frame number `n - 1` (the second audio timestamp read from the source file was used one output frame too early). Fixes #2071. * mkvinfo: fixed a null pointer dereference if an `EbmlBinary` element's data pointer is a null pointer. Fixes #2072. ## Build system changes * configure: added option `--disable-update-check`. If given, the code checking online for available updates will be disabled. The update check is enabled and included in the GUI by default. * libEBML v1.3.5 is now required. ## Other changes * mkvmerge: the option `--colour-matrix` has been renamed to `--colour-matrix-coefficients` in order to match the specification more closely. The old option name will continue to be recognized as well. ------------------------------------------------------------ Have fun :) Kind regards, mosu From nobody Sat Aug 19 12:23:37 2017 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 185AD1329DB for ; Sat, 19 Aug 2017 12:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8aBOxPHe6NE for ; Sat, 19 Aug 2017 12:23:34 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017031329D9 for ; Sat, 19 Aug 2017 12:23:34 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id p3so67811222qtg.2 for ; Sat, 19 Aug 2017 12:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=oeHhYvLGpxavR9kApro1/SoL7YtefCOE4Wj45b5V3sg=; b=TPM+Qv31VZQEZScMo0zvtl8Rc6mpmn6rIwZWIJ3U1p3s1gpEwMvxZZflgnDrHDVk5L UWgGOiWQH9TLp9IZPad7n3i+qYkqlR8NVHWhdihvWVy+q12H6srivY4UhCcsCUuaFX+w 1J8f13P3re+Yf1UdXnfBa7Oosq6wPviFCzD0cWBljmDObw+LLHBQ/asYo9FS5MaCE685 LQwVtJqA1mxV7TYeu3yqQvm51Dllm8eLE5gC+neEq3AHLgPFyi3xJy3v/3ZgXlO+6IwN qNiDmPLjMtbKifBD4H1MC9FIyxbILNgGqkot3vKQRLlmMPr4+i3PnFl5zrKqo/6s9ZUx B4qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oeHhYvLGpxavR9kApro1/SoL7YtefCOE4Wj45b5V3sg=; b=hC3DHBEwZ14R8drzUF8TtoJGo7NCfVHxrauBSq39eUlBVT/SvGvRcLeAStxx+ZBGNj cGop3IWY8NC8+Nw+GITHs59tdPm/jvXd5wVdRouFaeF04xmHaj0q0pK5jF9EJIfK2vEH kT9D3HQmaGJung9R/uM1RULXd8Z7bzWG8G7SKeBTJf7R42VOB6MLNGGdArtr/eLK7MKi yMlgxzVKwUckMfVKk9SwDLWVJkeLuQpjotwPE1vgctQDyxxba9qMOK0MCFMoC5L2swiF cy80jqbku5kFRV+fUomp2r2s3FjwJ+Bq5Ky9MVjWrd1Xg3D8Gc8uBdSz03QHSIqwnLxe NQ8Q== X-Gm-Message-State: AHYfb5gE6ljqwF8xWxLDViJ1icYyH7+EFefJ4c79orZUISFD1MVrIPa/ 0L0HL+kOKvIsbibmqIi8jqUU//rAVORV X-Received: by 10.200.37.139 with SMTP id e11mr19123037qte.50.1503170612927; Sat, 19 Aug 2017 12:23:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.73 with HTTP; Sat, 19 Aug 2017 12:23:32 -0700 (PDT) From: Ashley Blewer Date: Sat, 19 Aug 2017 15:23:32 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a11c032826b9ffa0557202e89" Archived-At: Subject: [Cellar] matroska-specification pull requests up for review X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 19 Aug 2017 19:23:36 -0000 --001a11c032826b9ffa0557202e89 Content-Type: text/plain; charset="UTF-8" Hi CELLAR. I've been working on the Matroska specification again and opened up a few PRs for consideration, mostly related to structure. 167 : Clears up language in the three indexes for Matroska, Tags, and Codecs. Mostly just "typo correction." Moritz approved this, thanks mosu. 168 : Proposal to remove advice about checking against the Matroska test files, or proposal to consider moving this to a different part of the spec (it doesn't "fit in" currently, not under any subheading, so it appears under the last, which right now is below the Schema.) 169 : Removes an extra level-2 header element from the structure section (because it was the only one, kinda lonely) and adds a space to the beginning of the Schema section (forcing the build to treat this as a new level-1 section). 170 : Proposal to move the "notes.md" section to the end of the specification in the Makefile. This seems to be miscellaneous and needs some more work done, possibly moving much of this to other parts of the spec, so seems right to stick it at the end of the build for now. Thanks everybody!!! Ashley --001a11c032826b9ffa0557202e89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi CELLAR.

I've been working on the= Matroska specification again and opened up a few PRs for consideration, mo= stly related to structure.

167: Clears up lan= guage in the three indexes for Matroska, Tags, and Codecs. Mostly just &quo= t;typo correction." Moritz approved this, thanks mosu.

<= /div>
168: Proposal to remove advice about checking against the Ma= troska test files, or proposal to consider moving this to a different part = of the spec (it doesn't "fit in" currently, not under any sub= heading, so it appears under the last, which right now is below the Schema.= )=C2=A0

169: Removes an extra level-2 header = element from the structure section (because it was the only one, kinda lone= ly) and adds a space to the beginning of the Schema section (forcing the bu= ild to treat this as a new level-1 section).

170<= /a>: Proposal to move the "notes.md&qu= ot; section to the end of the specification in the Makefile. This seems to = be miscellaneous and needs some more work done, possibly moving much of thi= s to other parts of the spec, so seems right to stick it at the end of the = build for now.

Thanks everybody!!!

<= /div>
Ashley
--001a11c032826b9ffa0557202e89-- From nobody Sat Aug 19 13:37:19 2017 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 2FF1D1329EB for ; Sat, 19 Aug 2017 13:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejil6jbqGO8V for ; Sat, 19 Aug 2017 13:37:15 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 E4D001329F3 for ; Sat, 19 Aug 2017 13:37:13 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id o63so2765051qkb.3 for ; Sat, 19 Aug 2017 13:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=k8vhkqDC5wxPQECEs5xX1p0FKI4PaTz/3goRS6UZV4g=; b=g4nAdK7dgySRn0uAo86I3zyZD72AezCvOTeTzt++gaR8cmf5dKoMbBGoSY2zobEACI pXRaGiWKBTzqL8yQdp3HwZ+85XLVnPPKBFOg7KAvzog/ps+cqjwusqclrqqpQe5uyAig kgrgakNNPXOFZP/HMifeIJDpoYoo26Hcz1ohsc8zs2+lveoJRd4pWgy6DyuWS5wnWRW9 gIV9CT/jaTKV50V89H3h92JOiGwRt1j246OD5DGeYuw+xHdQ4pfW1d89PvvlLDuz0GyF rCnGWq5/L3awr2lNFTBLrH6gylkv7C/KMtFbGgCvx7M1oaXnSH/g2eIF1xZC+CckAcA1 oYQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=k8vhkqDC5wxPQECEs5xX1p0FKI4PaTz/3goRS6UZV4g=; b=fNQkQs5DcgRw4nbQMIi7yXIoviFNyM5OzcWITcVtrzcl29e0B+APQvRoc/zwkzQSrN bC86prPtVI+y0WYBlIg5bdtq2KRdna/GBYZJrxjCAYXL4954u0C6h/eH5t7r1bP/kaIV CaGcV5QL0Ufsh6ihhRPXOm+P/T95q80EZP6AABPjBVl+Vl6HCJB5NfS+JnwzbWJLpA+J ypgn+EtMliUcDB2ngEXihVOSaRmMutNHkORdNFdXM66+M7AmmGVeXjifeIoPzVlbTf3I nibW1flOvhgwDbAc0TH5G6BYWhETPgs5yNnHUWBL4UGyWr1B/Y59iOxQLWplHMiLOjcX jSRA== X-Gm-Message-State: AHYfb5jpKPNHgr1G1KW5gcugO/g2qzmUzbIm9tIhEoe6yxWkCrvxqfY1 tFpzeLXirAjum9BpouV42G4S4eqv0I8H X-Received: by 10.55.108.3 with SMTP id h3mr16912796qkc.17.1503175032867; Sat, 19 Aug 2017 13:37:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.73 with HTTP; Sat, 19 Aug 2017 13:37:12 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Sat, 19 Aug 2017 16:37:12 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a11487c34de94290557213546" Archived-At: Subject: Re: [Cellar] matroska-specification pull requests up for review X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 19 Aug 2017 20:37:17 -0000 --001a11487c34de94290557213546 Content-Type: text/plain; charset="UTF-8" To continue on this tiny sprint of mine... 171 : Small request to add a space between header signifier ("#") and header text. I just checked in on PR 149 while there, and it seems to be generally-approved. Is there any reason this hasn't been merged into master? It resolves a number of issues. What about the streaming section? I'm working on refining the language there, requesting comments in PR 172 (it's pretty short). Thanks again! Ashley On Sat, Aug 19, 2017 at 3:23 PM, Ashley Blewer wrote: > Hi CELLAR. > > I've been working on the Matroska specification again and opened up a few > PRs for consideration, mostly related to structure. > > 167 : > Clears up language in the three indexes for Matroska, Tags, and Codecs. > Mostly just "typo correction." Moritz approved this, thanks mosu. > > 168 : > Proposal to remove advice about checking against the Matroska test files, > or proposal to consider moving this to a different part of the spec (it > doesn't "fit in" currently, not under any subheading, so it appears under > the last, which right now is below the Schema.) > > 169 : > Removes an extra level-2 header element from the structure section (because > it was the only one, kinda lonely) and adds a space to the beginning of the > Schema section (forcing the build to treat this as a new level-1 section). > > 170 : > Proposal to move the "notes.md" section to the end of the specification > in the Makefile. This seems to be miscellaneous and needs some more work > done, possibly moving much of this to other parts of the spec, so seems > right to stick it at the end of the build for now. > > Thanks everybody!!! > > Ashley > --001a11487c34de94290557213546 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To continue on this tiny sprint of mine...

<= div>171: Small request to add a space between header signifier ("= #") and header text.

I just checked in on PR= 149=C2=A0while there, and it seems to be generally-approved. Is there = any reason this hasn't been merged into master? It resolves a number of= issues.

What about the streaming section? I'm= working on refining the language there, requesting comments=C2=A0in P= R 172 (it's pretty short).

Thanks again!
=

Ashley



On Sat, Aug 19, 2017 at = 3:23 PM, Ashley Blewer <ashley.blewer@gmail.com> wrote= :
Hi CELLAR.

I've been working on the Matroska specification again and opene= d up a few PRs for consideration, mostly related to structure.
167: Clears up language in the three in= dexes for Matroska, Tags, and Codecs. Mostly just "typo correction.&qu= ot; Moritz approved this, thanks mosu.

168: Proposal to remove advice about checking against the Matro= ska test files, or proposal to consider moving this to a different part of = the spec (it doesn't "fit in" currently, not under any subhea= ding, so it appears under the last, which right now is below the Schema.)= =C2=A0

169: Removes an extr= a level-2 header element from the structure section (because it was the onl= y one, kinda lonely) and adds a space to the beginning of the Schema sectio= n (forcing the build to treat this as a new level-1 section).
170: Proposal to move the "notes.md" section to the en= d of the specification in the Makefile. This seems to be miscellaneous and = needs some more work done, possibly moving much of this to other parts of t= he spec, so seems right to stick it at the end of the build for now.
<= div>
Thanks everybody!!!

Ashley

--001a11487c34de94290557213546-- From nobody Tue Aug 22 07:04:29 2017 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 C3ED91321C7 for ; Tue, 22 Aug 2017 07:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 HDXEF3cu0X9G for ; Tue, 22 Aug 2017 07:04:20 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D63126DD9 for ; Tue, 22 Aug 2017 07:04:20 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id s187so23323941ywf.2 for ; Tue, 22 Aug 2017 07:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=mYDOYk3tpifvBXKCE4F0zk76tKZd8WlaVbQjlNrwH1A=; b=zeitaZIT+QHVvS42MXeKmxG6pEQwLNYO2kLm+kBfOdgLXnASyXhUJy82245IXPnx3B MDIzUWDIgOpGLGVMuE9M1gLIx+6wkT8OfqXYyY+zGxCOT+SnMH33Z554KgZAmi8xVvqq owtefPqdZ0P/clekF9sdWmfnE0UZV1PXGryMp75FqTRnILDg+1rlynJ6GGSJd/RF0Hy2 ggRbiGRGuDE2UBcXldK2I94zcOkLM4HXwwvyPX1Zcoi2w8IwPOvVT3PZoCBsYfT29ObA GIENqUpShPd5vFwXsWRCtugJ8uYoV4/nuxOKT4rP3iQ5Up6x4A1Y9qLv6jDV38A82MKC D8vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mYDOYk3tpifvBXKCE4F0zk76tKZd8WlaVbQjlNrwH1A=; b=PgO2gDQEf+5VQioPGWbUYuInFlQBfT9ueqfvqVyqU/4G5jIsK8BrllGZxVIDbLRwz2 dNHEpF7t0iKJwzV4y26C3S/XbBX4GJNFd9IjhfE113tizTsaOIlZmJxbiZRrXVrlDEkQ 9dky80yZf97k+JP+c+giUnXso8kSlhq/Cu+S2aPCA1Hz+61Dv0j7R/axpntb36uFduGV yDgeu1UA8xt38SG+tyzDnuLTUEb1umJNM0kLyzJ0/pUwnl6Ds5U/ySBALI40NU+qhAfP +Qoj4IlXHiyE48AjZh1glaCbxeHhL0jnxEfHtq/ron4jN1mCJNNd/swNRCKrdGsoCYrF cmWQ== X-Gm-Message-State: AHYfb5jjpkyEJ9oOHlr5o68nxF0FipoS+6pL0ksZa6z8ALl+pBn+jXza 5nMXK6PMpX/ld5a4NtosIXqjYMMSyqlQsNQ= X-Received: by 10.37.248.29 with SMTP id u29mr714100ybd.332.1503410659161; Tue, 22 Aug 2017 07:04:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.68.9 with HTTP; Tue, 22 Aug 2017 07:04:18 -0700 (PDT) From: Steve Lhomme Date: Tue, 22 Aug 2017 16:04:18 +0200 Message-ID: To: Matroska Devel , Matroska Users , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] mkvalidator & mkclean X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 22 Aug 2017 14:04:27 -0000 As I fixed the code generator from ebml_matroska.xml to C and C++ code I can make new builds of the tools I maintain with the latest specifications, elements and deprecated elements. mkvalidator is now 0.5.2: - Display the filename at the end of the processing - Add a --quick option to exit after the first error/warning - Add new elements from IETF CELLAR group - Deprecate more elements based on IETF CELLAR group - fix crash with files that have no Segment - fix crash on incomplete files - fix crash on invalid ID - fix bitrate display for high bitrate on large files mkclean is now 0.8.10: - update the list of Matroska elements from the IETF CELLAR group work - fix many parsing crashes in libebml2 -- Steve Lhomme Matroska association Chairman From nobody Tue Aug 22 08:43:46 2017 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 0B80A1321AC; Tue, 22 Aug 2017 08:43:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ben@nostrum.com, tessa.fallon@gmail.com, cellar@ietf.org, cellar-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150341662495.6029.2317157213010907186.idtracker@ietfa.amsl.com> Date: Tue, 22 Aug 2017 08:43:44 -0700 Archived-At: Subject: [Cellar] cellar - Not having a session at IETF 100 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 22 Aug 2017 15:43:45 -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 100. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Fri Aug 25 10:22:06 2017 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 7B928126C7A for ; Fri, 25 Aug 2017 10:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjw8nygmEYYL for ; Fri, 25 Aug 2017 10:22:02 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 411E2132961 for ; Fri, 25 Aug 2017 10:21:53 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id o63so2096369qkb.3 for ; Fri, 25 Aug 2017 10:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=DK1QYV8yVZa8M15d8axTh/SmcbEfBTYz9HfPeZk0UmY=; b=cbrHTJdwb/PQVSRtJ/npPm00ylDxKAv7tCtr8c7RO6cWJlQXkTn8lwLw/3muGoMAqR xkUplI+DcgzcXiy107kOy4R7jeq+lglhQGshSeL5CZN7/hjwMugVt3xuBcenH4Opa+pi DNpUru55Br7Ctaqpyooj5Am/sSYHGpa5XEiZME7sI/Cbd3QZMtdD3Q/KNjn1txRp6UTA eW1dwV2xERExMmfjsfnXfNJijW7StgjI6zYxGzD3B24ASNwvOiesBi9pmRgnW9E0LCO/ BG5gSDefpunZsnFU4fS8D8LdV49fXB0BEGt8Y82XzUjmkymrzqOxvnIA8d5bhbq5ZFqz 9oeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=DK1QYV8yVZa8M15d8axTh/SmcbEfBTYz9HfPeZk0UmY=; b=b5Q/usotRF77fVjjtlQaX0a3ERw59Ujp1uWY7mPgLDe1frH0BtOWLmF3ImVh5EhBW3 0JfxTrHFWPJp+XhWZP0AzwkrDKUSMXap90xq1viYBSLGQ7ySTf4ua2Ss9E96xd9isyBi 8bYceoRryj/wqbSDO0YgzcW9If7FTLEv8MdbIY/jScUg1YfDoT1q9Zo67GbtcCQP3ViV QBmOw2KWaVxlc92AThO5pMc/PQlPlt5mrPLubW4tkBKd8QmrO+6kZqSVjJZfbMwphSQ3 qjLHgJmm4T8EDJu+O6+JWAwUz4Zsfu4G10yX2oyivcQ323VjvAVkvWgkFtNAYVj+i//w cvaw== X-Gm-Message-State: AHYfb5gwJrAh4xzzjNck3CIjVJ/GL77KmrP/9cBxwJz7isqMiXvRjwBh spC3UQYmZjLJwJBnNSP20OG2tRsq3WOyvgY= X-Received: by 10.233.221.67 with SMTP id r64mr8363227qkf.158.1503681712150; Fri, 25 Aug 2017 10:21:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.73 with HTTP; Fri, 25 Aug 2017 10:21:51 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Fri, 25 Aug 2017 13:21:51 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="94eb2c046b9a4edde10557972ea4" Archived-At: Subject: Re: [Cellar] matroska-specification pull requests up for review X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 17:22:04 -0000 --94eb2c046b9a4edde10557972ea4 Content-Type: text/plain; charset="UTF-8" Hello, all of these have been resolved, except PR 149 is still outstanding. I arranged the large Notes section of the Matroska specification in an attempt to give it more structure. Notes are in the PR on Github: https://github.com/Matroska-Org/matroska-specification/pull/173 Feedback welcome and encouraged! On Sat, Aug 19, 2017 at 4:37 PM, Ashley Blewer wrote: > To continue on this tiny sprint of mine... > > 171 : > Small request to add a space between header signifier ("#") and header text. > > I just checked in on PR 149 > while > there, and it seems to be generally-approved. Is there any reason this > hasn't been merged into master? It resolves a number of issues. > > What about the streaming section? I'm working on refining the language > there, requesting comments > in PR > 172 (it's pretty short). > > Thanks again! > > Ashley > > > > On Sat, Aug 19, 2017 at 3:23 PM, Ashley Blewer > wrote: > >> Hi CELLAR. >> >> I've been working on the Matroska specification again and opened up a few >> PRs for consideration, mostly related to structure. >> >> 167 : >> Clears up language in the three indexes for Matroska, Tags, and Codecs. >> Mostly just "typo correction." Moritz approved this, thanks mosu. >> >> 168 : >> Proposal to remove advice about checking against the Matroska test files, >> or proposal to consider moving this to a different part of the spec (it >> doesn't "fit in" currently, not under any subheading, so it appears under >> the last, which right now is below the Schema.) >> >> 169 : >> Removes an extra level-2 header element from the structure section (because >> it was the only one, kinda lonely) and adds a space to the beginning of the >> Schema section (forcing the build to treat this as a new level-1 section). >> >> 170 : >> Proposal to move the "notes.md" section to the end of the specification >> in the Makefile. This seems to be miscellaneous and needs some more work >> done, possibly moving much of this to other parts of the spec, so seems >> right to stick it at the end of the build for now. >> >> Thanks everybody!!! >> >> Ashley >> > > --94eb2c046b9a4edde10557972ea4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

all of these have been resolved,= except PR 149 is still outstanding.

I arranged th= e large Notes section of the Matroska specification in an attempt to give i= t more structure. Notes are in the PR on Github:=C2=A0https://github.com/M= atroska-Org/matroska-specification/pull/173

Fe= edback welcome and encouraged!=C2=A0
=
On Sat, Aug 19, 2017 at 4:37 PM, Ashley Blew= er <ashley.blewer@gmail.com> wrote:
To continue on this tiny sprint of mine..= .

171: Small request to add a spa= ce between header signifier ("#") and header text.

=
I just checked in on PR 149=C2=A0while th= ere, and it seems to be generally-approved. Is there any reason this hasn&#= 39;t been merged into master? It resolves a number of issues.
What about the streaming section? I'm working on refining t= he language there, requesting comments=C2=A0in PR 17= 2 (it's pretty short).

Thanks again!

Ashley
=



On= Sat, Aug 19, 2017 at 3:23 PM, Ashley Blewer <ashley.blewer@gmail.c= om> wrote:
Hi CELLAR.

I've been working on the Matroska specif= ication again and opened up a few PRs for consideration, mostly related to = structure.

167: Clears up l= anguage in the three indexes for Matroska, Tags, and Codecs. Mostly just &q= uot;typo correction." Moritz approved this, thanks mosu.
168: Proposal to remove advice about che= cking against the Matroska test files, or proposal to consider moving this = to a different part of the spec (it doesn't "fit in" currentl= y, not under any subheading, so it appears under the last, which right now = is below the Schema.)=C2=A0

169= : Removes an extra level-2 header element from the structure section (b= ecause it was the only one, kinda lonely) and adds a space to the beginning= of the Schema section (forcing the build to treat this as a new level-1 se= ction).

170: Proposal to mo= ve the "notes.md&quo= t; section to the end of the specification in the Makefile. This seems to b= e miscellaneous and needs some more work done, possibly moving much of this= to other parts of the spec, so seems right to stick it at the end of the b= uild for now.

Thanks everybody!!!

Ashley


--94eb2c046b9a4edde10557972ea4-- From nobody Sat Aug 26 08:50:07 2017 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 5E2D31326F3 for ; Sat, 26 Aug 2017 08:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BP01CRlFSeL4 for ; Sat, 26 Aug 2017 08:50:03 -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 8FB9213291B for ; Sat, 26 Aug 2017 08:50:03 -0700 (PDT) Received: from smtp5.infomaniak.ch (smtp5.infomaniak.ch [83.166.132.18]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v7QFo1jn011724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sat, 26 Aug 2017 17:50:01 +0200 Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v7QFo0Pn035540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 26 Aug 2017 17:50:01 +0200 Date: Sat, 26 Aug 2017 17:50:01 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: [Cellar] Implementation hints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 15:50:06 -0000 Hello, we are currently discussing on Matroska's GitHub (and previously on FLAC's as well) about some implementation hints, that are present in the current specifications, but should be removed, or about hints that were given while discussing the specifications. I guess it would be useful to group these hints in separate, specific documents, instead of archiving them... in the rubbish bin. In my opinion, they can save a lot of time for those who wish to implement the specifications by programming a parser or a player. Best regards, Reto AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: | Twitter: @retoch From nobody Sat Aug 26 09:19:55 2017 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 549541321D8 for ; Sat, 26 Aug 2017 09:19:54 -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 FIY4utR0Jc7l for ; Sat, 26 Aug 2017 09:19:52 -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 11276132153 for ; Sat, 26 Aug 2017 09:19:52 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id o63so10895954qkb.3 for ; Sat, 26 Aug 2017 09:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rmLhZdJU9zYY3rpYXoTOwZ25lSQO5A9uCTwuKWILD/4=; b=jxEmkyByAl3jIdlx9oyeq88KW+K87KDEvjwV3qbvfxFfjLXs4CWh6Jse0THrRURRo0 x/vxAgdPvCAxuG4LRwPfsMGdEp5rQsUAGGAiKOEAjgX7b/SE9ZHNFJrgmkndemZikCD5 2BVBLmHF1CUpJHsjcmx0+YTSt+xKEg8fxHOzvPgwmT1jFguolPqVQQPRYGdzHdbso8B/ FR6M298Ri63nNwVgh4PCBEaHi5tc0b6EvQxZMX/JG4TFRGqZPwTh6D7A/pd+yMsvNmQX jb+CPyibvvTS72Y7PYIbJizs4aN4ArWGqT66WDjh7lTQQ9eZRmSR809pzQ5Xfhgdp7eS C9aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rmLhZdJU9zYY3rpYXoTOwZ25lSQO5A9uCTwuKWILD/4=; b=fMV2BsC7hR/n8XlTnI+OjB693RXb/arftNhf7rbp6sqTzgmPWurbtlCOZmMSE5PkBo 4omnP5njG3AVNex+yTjO9otyMDUv6TociKkgrG9SAW79T0GUrAMcWylStBEqt9ovmdpN TbVLNCdh7f8bXgCtll6Xj7qmBzOKXhwzYZnL/K2CAu7WJLcOPagzG9DMhvDp5FApXw3D fuO8HyjtX5LVu4TW9yrh5UkA+qUp2BoIVtHpLkZDA0/7HzzrTmMD18drlQCYdfaH0IcF OZwcls5O5tsUHMC6r1dxsmJge2vz2wM7983NqrVIBnAOVRS0AXIF5FxOXhJtH3mY6HaH XiBA== X-Gm-Message-State: AHYfb5jZA4qX16SSSEWGn9sjhMot2k2Y57n9NtCTn17x8/EmNusa/OVK ACi7xu04NVZJUbn+JiqVqju8O873pef/ln4= X-Received: by 10.55.106.67 with SMTP id f64mr2761196qkc.15.1503764391095; Sat, 26 Aug 2017 09:19:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.73 with HTTP; Sat, 26 Aug 2017 09:19:50 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Sat, 26 Aug 2017 12:19:50 -0400 Message-ID: To: Reto Kromer Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a11487bc65b72d00557aa6e86" Archived-At: Subject: Re: [Cellar] Implementation hints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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 Aug 2017 16:19:54 -0000 --001a11487bc65b72d00557aa6e86 Content-Type: text/plain; charset="UTF-8" Thanks Reto! Related aforementioned convo is here, in this PR: https://github.com/Matroska-Org/matroska-specification/pull/168 Ashley On Sat, Aug 26, 2017 at 11:50 AM, Reto Kromer wrote: > Hello, > > we are currently discussing on Matroska's GitHub (and previously > on FLAC's as well) about some implementation hints, that are > present in the current specifications, but should be removed, or > about hints that were given while discussing the specifications. > I guess it would be useful to group these hints in separate, > specific documents, instead of archiving them... in the rubbish > bin. In my opinion, they can save a lot of time for those who > wish to implement the specifications by programming a parser or > a player. > > Best regards, Reto > > > AV Preservation by reto.ch > chemin du Suchet 5 | 1024 Ecublens | Switzerland > Web: | Twitter: @retoch > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a11487bc65b72d00557aa6e86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Reto!

Related aforementioned con= vo is here, in this PR:=C2=A0https://github.com/Matroska-Org/matroska-spec= ification/pull/168

Ashley

On Sat, Aug 26, 2017 at 11= :50 AM, Reto Kromer <lists@reto.ch> wrote:
Hello,

we are currently discussing on Matroska's GitHub (and previously
on FLAC's as well) about some implementation hints, that are
present in the current specifications, but should be removed, or
about hints that were given while discussing the specifications.
I guess it would be useful to group these hints in separate,
specific documents, instead of archiving them... in the rubbish
bin. In my opinion, they can save a lot of time for those who
wish to implement the specifications by programming a parser or
a player.

Best regards, Reto


AV Preservation by reto.ch
chemin du Suchet 5 | 1024 Ecublens | Switzerland
Web: <h= ttps://reto.ch> | Twitter: @retoch

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

--001a11487bc65b72d00557aa6e86--