From nobody Mon May 8 11:43:45 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 204F9128B51; Mon, 8 May 2017 11:43:44 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149426902403.10555.9825922819373731315.idtracker@ietfa.amsl.com> Date: Mon, 08 May 2017 11:43:44 -0700 Archived-At: Subject: [Cellar] cellar - Update to a Meeting Session Request for IETF 99 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: Mon, 08 May 2017 18:43:44 -0000 An update to a meeting session request has just been submitted by Tessa Fallon, a Chair of the cellar working group. --------------------------------------------------------- Working Group Name: Codec Encoding for LossLess Archiving and Realtime transmission Area Name: Applications and Real-Time Area Session Requester: Tessa Fallon Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: netvc codec rtcweb dispatch Second Priority: sipcore mmusic avtcore Third Priority: payload perc sipbrandy stir People who must be present: Ben Campbell Tim Terriberry Tessa Fallon Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue May 9 19:08:18 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 3EE77128AFE; Tue, 9 May 2017 19:08:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149438209621.26587.10180909535076372855@ietfa.amsl.com> Date: Tue, 09 May 2017 19:08:16 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-niedermayer-cellar-ffv1-02.txt 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: Wed, 10 May 2017 02:08:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission of the IETF. Title : FF Video Codec 1 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-niedermayer-cellar-ffv1-02.txt Pages : 36 Date : 2017-05-09 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-02 https://datatracker.ietf.org/doc/html/draft-niedermayer-cellar-ffv1-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-niedermayer-cellar-ffv1-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 10 01:42: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 50CF1126D46 for ; Wed, 10 May 2017 01:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpDmiB6PypW7 for ; Wed, 10 May 2017 01:42:01 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD7B120227 for ; Wed, 10 May 2017 01:42:00 -0700 (PDT) Received: from [10.0.0.11] (1360030002.d-dsl.at [::ffff:81.16.105.50]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 10 May 2017 10:42:45 +0200 id 0000000000000061.000000005912D285.00002AAD Message-ID: <5912D256.9090706@das-werkstatt.com> Date: Wed, 10 May 2017 10:41:58 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] Proper FFV1 support in VirtualDub: Crowdfunding 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, 10 May 2017 08:42:03 -0000 Dear fellow FFV1 users :) In order to finally provide a nice-to-use OpenSource licensed video capture, editing and transcoding GUI, we're working on an improved version of VirtualDub with built-in FFV1 support: http://www.av-rd.com/projects/2017-virtualdub_ffv1.html The link contains information about the planned improvements, as well as a call to raising funds for this development. Please feel free to share this information with everyone possibly interested easier access and handling of FFV1 files on Windows platforms. :D Nice greetings! Peter B. From nobody Wed May 10 08:19:17 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 E550012948E for ; Wed, 10 May 2017 08:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uw-edu.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 VnWQF_R1nohd for ; Wed, 10 May 2017 08:19:14 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003: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 1873D127698 for ; Wed, 10 May 2017 08:19:14 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id l18so39287467oig.2 for ; Wed, 10 May 2017 08:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uw-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=NQHhHiwTzN5VQ+TsmVZPReBkHv6cW052kMkc3kZoaEA=; b=e4KC9ik+5Xe6XK7l0MSdw0XGifwQ6xx5WJZXHll481joq1paLDOuP/8DlE0OotzN/y gcUlv0DmEOOrphdA881E+FkY5RnIRTEgk5SX8R1mgGt2WrXl1ID64kcu95ZSGLPDgMxx CmVJlfMzRzv6e3SYWFa6xrZvDnRjpwrooxe2/cQKfv3uI2DGbnIzSODT10SH1xax9/cy hvZ4f432EBrr6Fkl5La1TmCMY71mq23Vzvve2mEGEuIczbvMeDnuiLDcvYZq4YOs/fRZ Wf/UTFSzo30RYdUxtvIQ/i8tIA9Je82LUOSPBvGmHdbxnDyCR3mUxQb8diCdAYq00vmW xhmA== 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=NQHhHiwTzN5VQ+TsmVZPReBkHv6cW052kMkc3kZoaEA=; b=J8iloNCu5PqKMZmKqvO/vQExYJoi7OYB7zIRpVwESr6WfUPArqJtx5Gm/S7Ryt7kAb c8CZkq+1ge0F3jCpS/IAn/G6mWN2gbsqxWJqoQdGaL471g/Z6HBEx2DeIUkuhDCL6bzC dpVVf//aJ+UMpQ0K+il09N6rQ/th/oQrMKrcI+2pqQ91qSTp2YvTOToT9+ILP700oc+z 8UZEFwd9StRUOc6n1rz+UiYb3BoDVCe0kaHV5G96gR9TuVA8Z5pV+rdskRV3R9HHSnl3 pFjy5MJBUY/Eo9JRph5JAkLoZrXxSD/UGfs9HnaD3J/C0HszXzY25kgbtN4V96Ai3ZS5 X8Vw== X-Gm-Message-State: AODbwcD47S4WvRdrFiEGl0IznPfpP9UOakvNlWk0ZZvkRnEQ54AtjQ74 0XxOvYMVpc4I6O/E3OqrIOhp0yR9h6z6IaY= X-Received: by 10.157.57.136 with SMTP id y8mr3107961otb.260.1494429553357; Wed, 10 May 2017 08:19:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.144.105 with HTTP; Wed, 10 May 2017 08:19:13 -0700 (PDT) From: Andrew James Weaver Date: Wed, 10 May 2017 11:19:13 -0400 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a11407770ab8c92054f2cfe23 Archived-At: Subject: [Cellar] FLAC Markdown 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, 10 May 2017 15:19:16 -0000 --001a11407770ab8c92054f2cfe23 Content-Type: text/plain; charset=UTF-8 Hello all! In a previous discussions on this list about people interested in working on the FLAC standard, I said that I would be willing to start the process of converting the existing standard into Markdown. I am writing to inform the list that I have begun preliminary work on this conversion. Currently that work is living here https://github.com/privatezero/flac_markdown. Best, Andrew Weaver -- Andrew Weaver, MLIS American Archive of Public Broadcasting National Digital Stewardship Resident @ CUNY TV weevz@uw.edu --001a11407770ab8c92054f2cfe23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all!

In a previous discussions on= this list about people interested in working on the FLAC standard, I said = that I would be willing to start the process of converting the existing sta= ndard into Markdown. I am writing to inform the list that I have begun prel= iminary work on this conversion.

Currently that wo= rk is living here = https://github.com/privatezero/flac_markdown.

= Best,
Andrew Weaver


--
Andrew Weaver, MLIS
American Archive of Public Broadcasting=
= National Digital Stewardship Resi= dent @ CUNY TV
--001a11407770ab8c92054f2cfe23-- From nobody Wed May 10 09:15:35 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 2ED52129C43 for ; Wed, 10 May 2017 09:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.581 X-Spam-Level: * X-Spam-Status: No, score=1.581 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 SOPjCpkLDFqR for ; Wed, 10 May 2017 09:15:32 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572D71242F7 for ; Wed, 10 May 2017 09:15:32 -0700 (PDT) Received: from [146.96.19.240] (port=48622 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 1d8UGv-001qca-Ge; Wed, 10 May 2017 12:15:30 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_90447D5A-2489-4C41-BD8F-59590DAC022D" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Wed, 10 May 2017 12:15:27 -0400 In-Reply-To: Cc: cellar@ietf.org To: Andrew Weaver 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] FLAC Markdown 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, 10 May 2017 16:15:34 -0000 --Apple-Mail=_90447D5A-2489-4C41-BD8F-59590DAC022D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Andrew, > On May 10, 2017, at 11:19 AM, Andrew James Weaver = wrote: >=20 > Hello all! >=20 > In a previous discussions on this list about people interested in = working on the FLAC standard, I said that I would be willing to start = the process of converting the existing standard into Markdown. I am = writing to inform the list that I have begun preliminary work on this = conversion. >=20 > Currently that work is living here = https://github.com/privatezero/flac_markdown = . I sent a pull request at = https://github.com/privatezero/flac_markdown/pull/1, which starts to add = a process to convert the markdown to the RFC format using the same = Makefile approach that we use with the FFV1 and EBML markdown files. = There's still a lot of inter-document cross-referencing that needs to be = adjusted before the Makefile works. For instance current = cross-referencing like: [*SUBFRAME\_VERBATIM*](#subframe_verbatim) won't render as expected in a plain text RFC, but would simply render to = something like "Section X.X.X". In EBML we use markdown such as See [the section on `Element Data Size`](#element-data-size) for rules = that apply to elements of unknown length. so that in the RFC this renders to See Section 7 for rules that apply to elements of unknown length. and in the markdown it renders to See the section on Element Data Size = for rules that apply to elements of = unknown length. Best Regards, Dave Rice= --Apple-Mail=_90447D5A-2489-4C41-BD8F-59590DAC022D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Andrew,

On May 10, 2017, at 11:19 AM, = Andrew James Weaver <weevz@uw.edu> wrote:

Hello all!

In a previous discussions on this list about people = interested in working on the FLAC standard, I said that I would be = willing to start the process of converting the existing standard into = Markdown. I am writing to inform the list that I have begun preliminary = work on this conversion.

Currently that work is living here https://github.com/privatezero/flac_markdown.

I sent a pull request = at https://github.com/privatezero/flac_markdown/pull/1, = which starts to add a process to convert the markdown to the RFC format = using the same Makefile approach that we use with the FFV1 and EBML = markdown files. There's still a lot of inter-document cross-referencing = that needs to be adjusted before the Makefile works. For instance = current cross-referencing like:

[*SUBFRAME\_VERBATIM*](#subframe_verbatim)

won't render as expected in a plain text RFC, = but would simply render to something like "Section X.X.X".

In EBML we use markdown such as
See [the section on `Element Data =
Size`](#element-data-size) for rules that apply to elements of unknown =
length.
so that in the RFC this renders = to
See Section 7 for rules that =
apply to elements of unknown length.
and in the = markdown it renders to

See the section on Element Data Size for rules that apply to elements = of unknown length.

Best Regards,
Dave = Rice
= --Apple-Mail=_90447D5A-2489-4C41-BD8F-59590DAC022D-- From nobody Wed May 10 18:17:57 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 16ABE126DEE for ; Wed, 10 May 2017 18:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrbVt9kPiJgr for ; Wed, 10 May 2017 18:17:54 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 27BDC126557 for ; Wed, 10 May 2017 18:17:42 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id a10so144530itg.1 for ; Wed, 10 May 2017 18:17: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=8yDQGKQy6FlWP0Ju73nEpLm2aKOwbl5yxweatbkoslc=; b=Ocmnyj97/TF1goxmc/tajXFtdoVYUlq8Qb3Q6U+HddGEeraCUD8lrHoGvMFqnt/1EM jfL49wBGTfcH6E+N5mtH0QTKrhwTUXQ0u0DtwfSXS0LTlAdCibzkZQyWb/IoDMs2wMNn ARuvI9NmvVWc0zJAOp18NJBOMXRfjE77g/OekyItncuN/4NwENcVmLvSSCpdfuAFzqmd qUbatLP16YlNOW36lA9090PdhcKk1OChOOj3Ma1PJQIlK2WrXTWOAksrblDc1kOBeboU NBR9XNjhSrJnv7vn0KSYswkPCXEo7A76B4IAtJuQnz17v91aIh6jxQDBSjksbNpU+3Ab RuOQ== 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=8yDQGKQy6FlWP0Ju73nEpLm2aKOwbl5yxweatbkoslc=; b=e7aLh5H8DRswLtkiVxZM6a1GATaCu2auBiQJrz8xkOFlYIW0xtxr/pKWH4/1zX9Sm9 wCDyF+Kr1vzC1yqRBSCCZiQ92BdTp/K/PENFxHm7Q5ZkiZbJ/WBzrb3lJ7DXIucz8JT1 JbG3TMsiK9i7wvNLTH0puxNJvQhFLafKVqQFTC3E12DYWAyjO43pbFzgavDU3T9zGkgH znGtrDQ2mXDL9sXSNp81hcRR8865kPluI2ri+f3MMc0B6VOWP6YDSGs5x6nOfi9fBNSI W5pcKKyXeI9BpWg4LxcW9Go2r3634+pt5vJgKa9CoHwR9/ytoHaFWC5sfMv/slfNhNzW y1Nw== X-Gm-Message-State: AODbwcCPPOrLv3jKlK4+UU0GEV2o5mIF4cY8c91cdK0vH0KnA5gnRqTx hEAIvWGdDVY2CyGFUaJEBckI5g/DsQ== X-Received: by 10.36.46.210 with SMTP id i201mr8002987ita.77.1494465461580; Wed, 10 May 2017 18:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.159.16 with HTTP; Wed, 10 May 2017 18:17:40 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Wed, 10 May 2017 21:17:40 -0400 Message-ID: To: Dave Rice Cc: Andrew Weaver , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary=001a114a9b08f7795c054f355ae7 Archived-At: Subject: Re: [Cellar] FLAC Markdown 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, 11 May 2017 01:17:56 -0000 --001a114a9b08f7795c054f355ae7 Content-Type: text/plain; charset=UTF-8 This is a great start, thanks for initiating the process, Andrew! If there are any people on this list authoritatively associated with FLAC... is there a better repository with which to begin this work? Ashley On Wed, May 10, 2017 at 12:15 PM, Dave Rice wrote: > Hi Andrew, > > On May 10, 2017, at 11:19 AM, Andrew James Weaver wrote: > > Hello all! > > In a previous discussions on this list about people interested in working > on the FLAC standard, I said that I would be willing to start the process > of converting the existing standard into Markdown. I am writing to inform > the list that I have begun preliminary work on this conversion. > > Currently that work is living here https://github.com/ > privatezero/flac_markdown. > > > I sent a pull request at https://github.com/privatezero/flac_markdown/ > pull/1, which starts to add a process to convert the markdown to the RFC > format using the same Makefile approach that we use with the FFV1 and EBML > markdown files. There's still a lot of inter-document cross-referencing > that needs to be adjusted before the Makefile works. For instance current > cross-referencing like: > > [*SUBFRAME\_VERBATIM*](#subframe_verbatim) > > won't render as expected in a plain text RFC, but would simply render to > something like "Section X.X.X". > > In EBML we use markdown such as > > See [the section on `Element Data Size`](#element-data-size) for rules that apply to elements of unknown length. > > so that in the RFC this renders to > > See Section 7 for rules that apply to elements of unknown length. > > and in the markdown it renders to > > See the section on Element Data Size > > for rules that apply to elements of unknown length. > > Best Regards, > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --001a114a9b08f7795c054f355ae7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a great start, thanks for initiating the process, = Andrew!

If there are any people on this list authoritati= vely associated with FLAC... is there a better repository with which to beg= in this work?

Ashley

On Wed, May 10, 2017 at 12:15 PM, D= ave Rice <dave@dericed.com> wrote:
Hi Andrew,

On May 10, 2017, at 11:19 AM, An= drew James Weaver <wee= vz@uw.edu> wrote:

Hello all!

In a p= revious discussions on this list about people interested in working on the = FLAC standard, I said that I would be willing to start the process of conve= rting the existing standard into Markdown. I am writing to inform the list = that I have begun preliminary work on this conversion.

=
Currently that work is living here https://github.com/privatezero= /flac_markdown.

I s= ent a pull request at=C2=A0https://github.com/privatezero/flac_= markdown/pull/1, which starts to add a process to convert the mark= down to the RFC format using the same Makefile approach that we use with th= e FFV1 and EBML markdown files. There's still a lot of inter-document c= ross-referencing that needs to be adjusted before the Makefile works. For i= nstance current cross-referencing like:

[*SUBFRAME= \_VERBATIM*](#subframe_verbatim)

won't re= nder as expected in a plain text RFC, but would simply render to something = like "Section X.X.X".

In EBML we use mar= kdown such as
See [the section on `Element Data Size`](=
#element-data-size) for rules that apply to elements of unknown length.
so that in the RFC this renders to
See Section =
7 for rules that apply to elements of unknown length.
and in the =
markdown it renders to

See the section on Element Data=
 Size for rules that apply to elements of unknown length.
<=
div>
Best Regards,
Dave Rice

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

--001a114a9b08f7795c054f355ae7-- From nobody Wed May 10 21:51: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 C0C35128A32 for ; Wed, 10 May 2017 21:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 XAPadrRbA61K for ; Wed, 10 May 2017 21:51:09 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E523126BF6 for ; Wed, 10 May 2017 21:51:08 -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 v4B4p6ZW020253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 11 May 2017 06:51:06 +0200 Received: from [192.168.192.31] (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 v4B4p5sv038082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 May 2017 06:51:05 +0200 From: Reto Kromer Content-Type: multipart/alternative; boundary=Apple-Mail-B824273C-F28E-4956-80B6-6A076C410AD7 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Thu, 11 May 2017 06:51:05 +0200 Message-Id: To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: iPhone Mail (14E304) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] FLAC Markdown 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, 11 May 2017 04:51:12 -0000 --Apple-Mail-B824273C-F28E-4956-80B6-6A076C410AD7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Should this note also be posted on the [flac-dev] listserv? Best regards, Re= to >>> On May 10, 2017, at 11:19 AM, Andrew James Weaver wrote: >>>=20 >>> Hello all! >>>=20 >>> In a previous discussions on this list about people interested in workin= g on the FLAC standard, I said that I would be willing to start the process o= f converting the existing standard into Markdown. I am writing to inform the= list that I have begun preliminary work on this conversion. >>>=20 >>> Currently that work is living here https://github.com/privatezero/flac_m= arkdown. --Apple-Mail-B824273C-F28E-4956-80B6-6A076C410AD7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Should this note also be posted on the [= flac-dev] listserv? Best regards, Reto


On May 10, 2017, at 11:1= 9 AM, Andrew James Weaver <weevz@uw.edu> wrote:

Hello all!

I= n a previous discussions on this list about people interested in working on t= he FLAC standard, I said that I would be willing to start the process of con= verting the existing standard into Markdown. I am writing to inform the list= that I have begun preliminary work on this conversion.

=
Currently that work is living here https:= //github.com/privatezero/flac_markdown.

= --Apple-Mail-B824273C-F28E-4956-80B6-6A076C410AD7-- From nobody Fri May 12 02:52: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 3BB4112EB32 for ; Fri, 12 May 2017 02:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8ASfJZuZ-Ax for ; Fri, 12 May 2017 02:52:54 -0700 (PDT) Received: from 5.mo177.mail-out.ovh.net (5.mo177.mail-out.ovh.net [46.105.39.154]) (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 4FE0112EC08 for ; Fri, 12 May 2017 02:41:42 -0700 (PDT) Received: from player714.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id B37C054F37 for ; Fri, 12 May 2017 11:41:40 +0200 (CEST) Received: from [192.168.2.101] (p5DDB7469.dip0.t-ipconnect.de [93.219.116.105]) (Authenticated sender: jerome@mediaarea.net) by player714.ha.ovh.net (Postfix) with ESMTPSA id E5E433C00A6 for ; Fri, 12 May 2017 11:41:39 +0200 (CEST) From: Jerome Martinez To: Codec Encoding for LossLess Archiving and Realtime transmission Message-ID: <8c37c822-6a74-b8d9-d4a0-0525ccec42db@mediaarea.net> Date: Fri, 12 May 2017 11:41:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 9463188720349155473 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeljedrtdejgddukecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: [Cellar] Matroska AlphaMode element 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, 12 May 2017 09:52:58 -0000 In Matroska specs, I read: \Segment\Tracks\TrackEntry\Video\AlphaMode "Alpha Video Mode. Presence of this Element indicates that the BlockAdditional Element could contain Alpha data." for me, verb "could" here is disturbing: does it means that for any video entry, I can put this element whatever is the content (alpha or not, BlockAdditionalelement present or not)? does it mean that I can skip this element whatever is the content (alpha or not, BlockAdditionalelement present or not)? I would like to have something more explicit about what is expected (when should this element be used) and what is valid (actually what is invalid), e.g which line below is valid or invalid when AlphaMode is 0 (default if not present), and when AlphaMode is 1? - BlockAdditional is not present and Block contains YUV content - BlockAdditional is not present and Block contains YUVA content - BlockAdditional is present and containing no alpha content (it contains something else) - BlockAdditional is present and containing alpha (with or without something else) Background: I am testing MKV/FFV1 output from FFmpeg with all colorspaces (pix_fmt), and AlphaMode is set to 1 with yuva420p pix_fmt (8-bit), this is the only one (e.g. no AlphaMode with yuv420 or yuva420p9), I find "53 C0 81 01" bytes in the resulting MKV, no BlockAdditional (when Alpha channel is present, it is in FFV1 bitstream) and I would like to know if it is valid or not before filling an FFmpeg ticket about the difference with AlphaMode between 8-bit and 9-bit content, and putting a test in MediaConch. ffmpeg -f lavfi -i mandelbrot=s=4x4 -vf format=yuva420p -t 1 -c rawvideo -c:v ffv1 yuva420p.mkv Jérôme From nobody Fri May 12 10:10:39 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 2C104129B97 for ; Fri, 12 May 2017 10:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.581 X-Spam-Level: * X-Spam-Status: No, score=1.581 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 CMYrJP5v1Ett for ; Fri, 12 May 2017 10:10:33 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C464512EB30 for ; Fri, 12 May 2017 10:06:09 -0700 (PDT) Received: from [146.96.19.240] (port=59645 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 1d9E0y-003YWz-Df; Fri, 12 May 2017 13:06:08 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_03E66E5D-DB12-4938-B8C5-BA92BC3F04C8" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Fri, 12 May 2017 13:05:42 -0400 In-Reply-To: Cc: flac-dev@xiph.org To: Andrew Weaver , Codec Encoding for LossLess Archiving and Realtime transmission 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] FLAC Markdown 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, 12 May 2017 17:10:37 -0000 --Apple-Mail=_03E66E5D-DB12-4938-B8C5-BA92BC3F04C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, And cc'ing flac-dev. > On May 10, 2017, at 12:15 PM, Dave Rice wrote: >=20 > Hi Andrew, >=20 >> On May 10, 2017, at 11:19 AM, Andrew James Weaver > wrote: >>=20 >> Hello all! >>=20 >> In a previous discussions on this list about people interested in = working on the FLAC standard, I said that I would be willing to start = the process of converting the existing standard into Markdown. I am = writing to inform the list that I have begun preliminary work on this = conversion. >>=20 >> Currently that work is living here = https://github.com/privatezero/flac_markdown = . >=20 > I sent a pull request at = https://github.com/privatezero/flac_markdown/pull/1 = , which starts to = add a process to convert the markdown to the RFC format using the same = Makefile approach that we use with the FFV1 and EBML markdown files. = There's still a lot of inter-document cross-referencing that needs to be = adjusted before the Makefile works. For instance current = cross-referencing like: >=20 > [*SUBFRAME\_VERBATIM*](#subframe_verbatim) >=20 > won't render as expected in a plain text RFC, but would simply render = to something like "Section X.X.X". >=20 > In EBML we use markdown such as > See [the section on `Element Data Size`](#element-data-size) for rules = that apply to elements of unknown length. > so that in the RFC this renders to > See Section 7 for rules that apply to elements of unknown length. > and in the markdown it renders to >=20 > See the section on Element Data Size = for rules that apply to elements of = unknown length. I added some issues to the flac_markdown repository and Andrew addressed = them in https://github.com/privatezero/flac_markdown/pull/7. Most of = these issues pertain to unintended semantic differences between the FLAC = specification as it exists in its original HTML form at = https://xiph.org/flac/format.html and the markdown rendition being = worked on at = https://github.com/privatezero/flac_markdown/blob/master/flac.md. Since the recent work focuses on a change of format from HTML to = markdown, I suggest that short term goals on the flac specification = focus on: - verifying semantic equalness with the html version - resolving issues that block the mmark/xml2rfc process that generates = the RFC formats of the specification - add standard RFC boilerplate (abstract, rfc2119, etc) Dave Rice= --Apple-Mail=_03E66E5D-DB12-4938-B8C5-BA92BC3F04C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,
And cc'ing flac-dev.

On May 10, 2017, at 12:15 PM, Dave Rice <dave@dericed.com> = wrote:

Hi Andrew,

On May 10, 2017, at 11:19 AM, Andrew James = Weaver <weevz@uw.edu>= wrote:

Hello all!

In a previous discussions on this list about people = interested in working on the FLAC standard, I said that I would be = willing to start the process of converting the existing standard into = Markdown. I am writing to inform the list that I have begun preliminary = work on this conversion.

Currently that work is living here https://github.com/privatezero/flac_markdown.

I sent a pull = request at https://github.com/privatezero/flac_markdown/pull/1, = which starts to add a process to convert the markdown to the RFC format = using the same Makefile approach that we use with the FFV1 and EBML = markdown files. There's still a lot of inter-document cross-referencing = that needs to be adjusted before the Makefile works. For instance = current cross-referencing like:

[*SUBFRAME\_VERBATIM*](#subframe_verbatim)

won't render as expected = in a plain text RFC, but would simply render to something like "Section = X.X.X".

In = EBML we use markdown such as
See [the section on `Element Data Size`](#element-data-size) =
for rules that apply to elements of unknown length.
so that in the RFC this renders to
See Section 7 for rules that apply to elements of unknown =
length.
and in the markdown it renders = to

See = the section on Element Data Size for rules that apply to elements = of unknown length.

I added some issues to the flac_markdown = repository and Andrew addressed them in https://github.com/privatezero/flac_markdown/pull/7. Most = of these issues pertain to unintended semantic differences between the = FLAC specification as it exists in its original HTML form at https://xiph.org/flac/format.html and the markdown = rendition being worked on at https://github.com/privatezero/flac_markdown/blob/master/flac.m= d.

Since the recent work focuses = on a change of format from HTML to markdown, I suggest that short term = goals on the flac specification focus on:
- verifying = semantic equalness with the html version
- resolving issues = that block the mmark/xml2rfc process that generates the RFC formats of = the specification
- add standard RFC boilerplate (abstract, = rfc2119, etc)

Dave = Rice
= --Apple-Mail=_03E66E5D-DB12-4938-B8C5-BA92BC3F04C8-- From nobody Tue May 16 04:50:49 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 2A043129C43 for ; Tue, 16 May 2017 04:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 uZBgGRGJeaWd for ; Tue, 16 May 2017 04:50:45 -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 34B10129687 for ; Tue, 16 May 2017 04:47:12 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id 203so51251677ywe.0 for ; Tue, 16 May 2017 04:47:12 -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:content-transfer-encoding; bh=FRG38IS9uRrmCPB6zhOKlwIMNFXDpJbsoRN36LTnis8=; b=WLNAZav6KfK3+h83QRY0/jCF8BJO7ZM+nxIXsrQg7VbVn5tpCWpGXr2+/TkNdJo8LC K7h3qeH6bi5h9+9xrTEUkd8ZaN2/s7BqXjtWgizXrgCxNu2zU3tr+pNmr/ZlO/axZP4d kGm7MngWY578euPet7As60s4dNbDxHSZbAcAorfnVVDIK40JsBFWUfGhv6ZsvSmhtAi5 psGb1oOX4DW2H1seKZgpCy+TMvfT3EQPnghhenMErfZA342GNPq6+0KHEbZR2dAn3Vgt 4Uc8Uyej3LyTwNd6RSSjxj2O5q+yZqTXH0DgQO9IT7xhmFaJzGP7XKj717AS9IHpRXk/ BYLg== 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:content-transfer-encoding; bh=FRG38IS9uRrmCPB6zhOKlwIMNFXDpJbsoRN36LTnis8=; b=XWJ3d04/iRPh9hchXgrGujbxc1xXwd5HMsPJ2O5U68Os9EzNcRiqDz7AlAPpmzCnXj yqT0ag6XoRBhi8kiKLgoeJdYvfaupP4NrUuJz3pC4xPNFXBz35WyQCvIEbl4AFBlY3gi jjpeg2S6hEGjfUOgXre+pMcw+ryG61l9Sb7oWt456OFu5aKmVxBoOvkWAdkkEZz2n6xd MuTZ6akQZvbMDL8u0KQiktRHjQhiyaACc81rdsremoNPg0/4FpthvcJHh2My50+4Gi9l ueZlM3Slc3vMiHmGFunJfjAt7sBqDKTj3te+YLYZqGdVkptdn7ytWrVApqvqEXXaJUSP qd3Q== X-Gm-Message-State: AODbwcBjkqRRTv6PmBXy3tVp31YdAw+6ftPZLawSKdT2U9bBmcLMOmI1 R9R/CpunHw0D7kb371U8/5IQeiz3tA== X-Received: by 10.129.39.145 with SMTP id n139mr9175186ywn.10.1494935231158; Tue, 16 May 2017 04:47:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.13.6 with HTTP; Tue, 16 May 2017 04:47:10 -0700 (PDT) In-Reply-To: References: <2651a6f3-9c9a-6f76-2ee7-4d5c23b1ce57@mediaarea.net> <922C5404-EC19-462D-A836-C952E66C2FD8@dericed.com> <9244b201-9097-365f-b7da-f2d8553616ee@mediaarea.net> <79FE60E9-88D8-4922-AE76-9D1924E1D6EB@dericed.com> <43056655-cf09-9d54-6552-4ed4b655e74f@mediaarea.net> <34CA7943-497F-449A-81DA-3237CB87BDD7@dericed.com> <1db0fb80-2441-a4f0-729e-bc5b5cfd1a84@mediaarea.net> From: Steve Lhomme Date: Tue, 16 May 2017 13:47:10 +0200 Message-ID: To: Dave Rice Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] QuickTime timecode tracks in Matroska, was Ancillary data in Matroska 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, 16 May 2017 11:50:47 -0000 2017-04-29 4:03 GMT+02:00 Dave Rice : > >> On Apr 26, 2017, at 3:51 AM, Steve Lhomme wrote: >> >> A bit late on the party but I agree with the move to a more specific >> track type for timecodes rather than the generic ancillary data. >> >> 2017-03-20 22:07 GMT+01:00 Jerome Martinez : >>> Le 20/03/2017 =C3=A0 21:37, Dave Rice a =C3=A9crit : >>>> >>>> [...] >>>>>> >>>>>> I=E2=80=99ve only seen a single value stored but then sometimes an e= dit list >>>>>> used to alter the ordering of the timecode (in case when its >>>>>> non-sequential). For Matroska possibly it could simply store a new t= imecode >>>>>> Block at any case when it is not sequential. >>>>> >>>>> What about seeking? >>>> >>>> Isn't the seeking similar to QuickTime. >>> >>> >>> Difference is that in QuickTime, a wrong "seek table" makes the playbac= k >>> impossible, so developers are more careful about it. and in the file I >>> remember (I must still find it), there was only one offset in the offse= t >>> table of QuickTime and a single "chunk" of time code with byte size of = 4 >>> bytes per frame (to be confirmed as you say you saw edit lists instead) >>> >>>> In QuickTime you'd need the offset table of the timecode track to >>>> understand the number and location of all timecode samples. In Matrosk= a you >>>> would use the associated CuePoints of the timecode track for the same >>>> reference. By parsing Cues the reader should be able to determine if t= he >>>> timecode is stripped or not and if not then have the CueTimes for each >>>> associated timecode Cluster. >>>> >>>>> If you have a timecode block at the first frame and also at the middl= e of >>>>> the file, how a player can know that there is a timecode block breaki= ng the >>>>> sequential order without parsing the whole file when there is a seek = request >>>>> to the last minute of content? In that case, time code real value wou= ld be >>>>> set to "waiting for new block" (and this block never comes). I don't = think >>>>> that forcing full parsing of the file with time code for seeking is a= good >>>>> solution. >>>> >>>> Same. But in the case of video if you seek to a P-frame then you have = to >>>> go backwards and decode from the I-frame. Similarly if seeking to a >>>> timepoint without a timecode Cluster (analogous to a P-frame), then th= e >>>> reader would have to use the Cues to decode the prior timecode Cluster >>>> (analogous to I-frame) in order to determine the timecode value of the= seek >>>> point. >>> >>> >>> Possible. >>> But we need to be careful, what does it means? >>> examples of issue: >>> 1/ can a player consider that if there is only one CuePoint with CueTra= ck =3D >>> the ID of the time code track, it means that this is a stripped content= and >>> time codes are in sequential order? >>> 2/ can a player consider that if there are only 2 CuePoints with CueTra= ck =3D >>> the ID of the time code track, it means that this is a stripped content= and >>> time codes are in sequential order except for one place and there is a >>> single discontinuity? >>> 3/ or must a player consider that if there only 2 CuePoints (let say fr= ame 0 >>> and frame 1000) with CueTrack =3D the ID of the time code track, it mea= ns that >>> it must seek to 0 if the requested frame is 999 (so a loooooong read of= the >>> file on disk before being able to play frame 999) >>> If answers are 2/ yes 3/ no, I understand that the only method for stor= ing a >>> time code track with all values not sequential is to have a CuePoint fo= r >>> each time code frame (which makes the Cues huge, 15-20 bytes of CuePoin= t per >>> time code frame). >>> >>> Please provide example about how you imagine CuePoints in the cases: >>> 1/ sequential time codes during 2000 frames >>> 2/ sequential time codes during 2000 frames except one discontinuity at >>> frame 1000 >>> 3/ 2000 different times codes >>> and where a player must seek if the request is to seek to frame 999. >> >> Are timecode frames supposed to be matching a specific video frame or >> audio frame ? Or they are loose ? If the former case it may be best to >> be attached as a BlockAdditional. Otherwise they should always be in >> sequential/display order, just like audio is. Even if video is not. > > I'd propose to limit the use case to the former. The idea of storing time= code data within BlockAdditional is interesting, but would that limit the m= etadata possibilities. For instance if timecode data is stored as it's own = TrackEntry, then potentially a file may contain two timecode TrackEntries, = one depicting timecode values from the original source materials used (like= ly non-continuous), whereas another TrackEntry could represent a new contin= uous timecode track that served some purpose in a video production. With th= ese timecodes as two TrackEntries with their own Clusters, they could have = distinct names and could be independently described with flags, so one may = be enabled and default while the other is disabled. In general it's not a good idea to have to places to define the same thing. I suppose a "final" timecode compare to a "source material" timecode would make sense though. In that case it's better to use a separate track. > With timecode in BlockAddition, there could potentially be two sets of ti= mecode (two BlockMore), but they would be indistinguishable and could not b= e controlled or labelled independently. Correct, there's no way to tag BlockAddition or set one as default. >> Having a separate track means the timestamps may not match exactly the >> video or audio tracks. So in case of seeking/discontinuity it's like >> you said, there's a state where you need to way for the next Timecode >> block to know where you are. > > This is the case if the there's one timecode value stored per video frame= , but this may not be the case. We also discussed using QuickTime's strateg= y of storing an integer as a timecode while the timecode track's private da= ta notes what equation to use to convert the integer into a timecode (flags= like max24, timebase, etc). In this case a timecode value would only need = to be stored at a point in time when the timecode is non-continuous. That could nice. But if there's a discontinuity it's tricky to know a particular timecode when seeking. That would require (as in mandatory) that such track have Cue entries for all discontinuity. There's no such requirements for other tracks for now. >> But in general a Timecode block >> should/must be placed before the audio/video it corresponds to. It's >> the same requirement there is in WebM that audio blocks are muxed >> before video blocks. Timecode would be even more prioritary. > > Does Matroska have the same ordering requirement? No it is only for WebM. > I don't see them. Is it valid to store Clusters in reverse timestamp orde= r? Clusters must have stricly incrementing timestamps. I thought it was written somewhere but it's not. > Dave Rice > --=20 Steve Lhomme Matroska association Chairman From nobody Tue May 16 04:53:18 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 7FBB3129B2A for ; Tue, 16 May 2017 04:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 vdYDQQ2vRplJ for ; Tue, 16 May 2017 04:53:15 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894A912EB3B for ; Tue, 16 May 2017 04:49:26 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id s22so34508977ybe.3 for ; Tue, 16 May 2017 04:49:26 -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=mgUQRIUmT4gT+YguZShNuKeYjBqZneq0Fktuv06hb2g=; b=joa804FzmZGl1U5vNFjKHzHh9jdfGTRtwYx7LbWV/FlHC5cUSBG7EG6KineGoOTq83 WqS5aSSSKWOFEJLrSqOpLzyR4LxW8Ssc3cjT7cW/ddOu+7y3D0Q9gCX5ljnufnBOOJHN Aa/pBdvjq2LKij2tqS2bsQxg8e7iQWjo71D6weQlOgmt5rpwYh70JzcZVRCWIvwggT53 ft6OR0BAIGu7KgNXXY96VgjQnpYdkSJ24L1fhEoyC+OGNTQjYdZiHTkf/0Lkr9mk9pUs NqAiu8Nj9Ku6HcQoyTCb235DJbDfGzTP1MPmZr12WNwI4QcB0hXgvOt6TPvRo+FKzM4h WSqQ== 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=mgUQRIUmT4gT+YguZShNuKeYjBqZneq0Fktuv06hb2g=; b=QYLVVsZUIhKXIZDwotBCpFYZ8e3YVKYiKodIxpRs8Q5boWCy0Hf1RsOOxngKe/0Upj ByMkmg3+42BdqVv2um079k8pQ1/6zqkBND9nE1acuQTN6BpaCOieWC3uRWPV7xA1SWBh D/Cz96P0AJLW+2vLgTgeSaW3ZZw7lyUsZ4G0be8V+bs9Id9uAkEmFRSHUrftlKUkUUPE lor3uZIZC8PzT4dyDiDKSygbSd9Cw4ih3xVyMCl7QOwtSPTnHOYj7A7mu6sVE0+XDksi O+cpzq8phJnEsd6ab682lne8sDKFsBIddQ4d2BVafB44YuM7YKsirUF0op+clJJb2IRu CyRA== X-Gm-Message-State: AODbwcCRDs0AZuGJobMNFyyRdC8nYghVYoh/QIa+6KSWYBPLIu2bF4xr Xlydql/xdTvdeTAyWBDKR9fgn8yaRg== X-Received: by 10.37.44.4 with SMTP id s4mr8986678ybs.84.1494935365830; Tue, 16 May 2017 04:49:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.13.6 with HTTP; Tue, 16 May 2017 04:49:25 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Tue, 16 May 2017 13:49:25 +0200 Message-ID: To: Reto Kromer Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] cellar - New Meeting Session Request for IETF 99 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, 16 May 2017 11:53:16 -0000 I might go in person but that's still up in the air. When do we need an answer ? And When do we know which date the CELLAR meeting would be on ? Thanks 2017-04-27 12:40 GMT+02:00 Reto Kromer : > Please count me as remote attendee. Thank you! Reto > > > Steve Lhomme wrote: > >>I'll probably do that as well. >> >>2017-04-26 21:43 GMT+02:00 Peter B. : >>> I'd be participating remotely, too :D >>> >>> >>> Cheers, >>> Peter >>> >>> On 04/26/2017 04:08 PM, Ashley Blewer wrote: >>>> Fortunately for everyone on the list interested in this meeting but >>can't >>>> hop over to Prague, IETF does an excellent job of ensuring remote >>>> participation! >>>> >>>> Ashley >>>> >>> >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >> > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Tue May 16 05:09:03 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 1F99412EB3D for ; Tue, 16 May 2017 05:09:01 -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 JusvyL2HygyH for ; Tue, 16 May 2017 05:08:59 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC662128768 for ; Tue, 16 May 2017 05:05:19 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l74so37087817ywe.2 for ; Tue, 16 May 2017 05:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=hiJWKaV6aYcSdBxOHP8ZFvU4wH3kfjlgC0M3hR8se7E=; b=BLg1FCAaIZR9cxQAFSonzdB2Iv52WDFNAUxHZCkFUREWhHAaGvUq/4q8Q0sCBy/L53 I+bHu0t2l6esz03iLqllLWQE1SWQaTBizcOWyoBeTLFOB9Wak1SHscn16ic8ViSMXBUH oyQcJfNR7MbOJ/Hd/+f7YNKlJp0HMK8e8ovHXLWzEp5iSyWbGHNRJ4GPrhW69PSg3wrX WCXlvUplC8z3DRwxpkqlsrsqJ8Aav/uz+KlmaAMEaMqZFyy7YU3GxLc42ORm3JFjAnKo 9WCbUABRn++IzVUDay6O1R68hLtqxV9tJZULK4JWwwcWAYqYJ/F8vDNvTaWx1R13oBP5 oDtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=hiJWKaV6aYcSdBxOHP8ZFvU4wH3kfjlgC0M3hR8se7E=; b=FRolOBN+uWfdCjrSBGIuFDR6VRMwxCCCkQPG1rNJDKre1d0uNp0HoCJSa4vuUnZ8vu wdLdwSR2WAEgtOAmlbqm46d1yKV02LHYYnWd9wbSwaVtPnVLFAolAHd1GcUZWvPhA5ju nhTxR8GMTRYrcqyRZZfSkIXp8ITQMtTdsMHqFJEjupMux2szM2p8bttmN55zV4LhwcwA vaL9fH7n0PuSympXRZbknQUyFOgN4ibA9f/647r5jIqdm52IT1CV2y/PdpMJWapf2FFs zd5aNbJ9AfyZRcR05OK21QAHqE2az9DtHVpY0gp2OfHJx12mNi04Z5VueGKTFI01nYo1 pYaQ== X-Gm-Message-State: AODbwcDNUm2vgffb9AiHBJrcaANrxNHCxYeGARsoXno8jEdnqPl831NC I//Bp2fnYapBYlrikADVy0ne2soAhjzP X-Received: by 10.129.138.70 with SMTP id a67mr9429987ywg.218.1494936318731; Tue, 16 May 2017 05:05:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.13.6 with HTTP; Tue, 16 May 2017 05:05:18 -0700 (PDT) In-Reply-To: <8c37c822-6a74-b8d9-d4a0-0525ccec42db@mediaarea.net> References: <8c37c822-6a74-b8d9-d4a0-0525ccec42db@mediaarea.net> From: Steve Lhomme Date: Tue, 16 May 2017 14:05:18 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Matroska AlphaMode element 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, 16 May 2017 12:09:01 -0000 2017-05-12 11:41 GMT+02:00 Jerome Martinez : > In Matroska specs, I read: > > \Segment\Tracks\TrackEntry\Video\AlphaMode > "Alpha Video Mode. Presence of this Element indicates that the > BlockAdditional Element could contain Alpha data." > > for me, verb "could" here is disturbing: does it means that for any video > entry, I can put this element whatever is the content (alpha or not, > BlockAdditionalelement present or not)? does it mean that I can skip this > element whatever is the content (alpha or not, BlockAdditionalelement > present or not)? I had to search deep in my memory to find what this is. It is a flag to indicate that one of the BlockAddtional ID corresponds to alpha data for the main video Block. The block addition is interpreted by the codec so it's up to the codec to know what to do with this ID and how to interpret the BlockAdditional data. So this flag is just informational to know if a particular track main contain alpha data via BlockAddition parsing. > I would like to have something more explicit about what is expected (when > should this element be used) and what is valid (actually what is invalid)= , > e.g which line below is valid or invalid when AlphaMode is 0 (default if = not > present), and when AlphaMode is 1? > - BlockAdditional is not present and Block contains YUV content > - BlockAdditional is not present and Block contains YUVA content > - BlockAdditional is present and containing no alpha content (it contains > something else) > - BlockAdditional is present and containing alpha (with or without someth= ing > else) IMO it should be 0 or 1. Or rather 0 or . It doesn't matter the codec of the original content. > Background: I am testing MKV/FFV1 output from FFmpeg with all colorspaces > (pix_fmt), and AlphaMode is set to 1 with yuva420p pix_fmt (8-bit), this = is > the only one (e.g. no AlphaMode with yuv420 or yuva420p9), I find "53 C0 = 81 > 01" bytes in the resulting MKV, no BlockAdditional (when Alpha channel is > present, it is in FFV1 bitstream) and I would like to know if it is valid= or If there's no BlockAdditional then it's used the wrong way. It's not a flag to inform that the track contains alpha data. On the other hand I doubt anyone uses it how it was meant to. So we might as well use it as a flag to tell whether the video contains alpha data. > not before filling an FFmpeg ticket about the difference with AlphaMode > between 8-bit and 9-bit content, and putting a test in MediaConch. > ffmpeg -f lavfi -i mandelbrot=3Ds=3D4x4 -vf format=3Dyuva420p -t 1 -c raw= video > -c:v ffv1 yuva420p.mkv > > J=C3=A9r=C3=B4me > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Tue May 16 05:40:38 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 015C2128B8D for ; Tue, 16 May 2017 05:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.079 X-Spam-Level: X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 KW1rPI_YIZxH for ; Tue, 16 May 2017 05:40:34 -0700 (PDT) Received: from 4.mo68.mail-out.ovh.net (4.mo68.mail-out.ovh.net [46.105.59.63]) (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 AC21A1293E9 for ; Tue, 16 May 2017 05:36:55 -0700 (PDT) Received: from player711.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 3745C525CB for ; Tue, 16 May 2017 14:36:53 +0200 (CEST) Received: from [192.168.2.101] (p5DDB7469.dip0.t-ipconnect.de [93.219.116.105]) (Authenticated sender: jerome@mediaarea.net) by player711.ha.ovh.net (Postfix) with ESMTPSA id EB60838008D for ; Tue, 16 May 2017 14:36:52 +0200 (CEST) To: cellar@ietf.org References: <8c37c822-6a74-b8d9-d4a0-0525ccec42db@mediaarea.net> From: Jerome Martinez Message-ID: <2c64b607-0d81-33be-1cf8-c13c06d64008@mediaarea.net> Date: Tue, 16 May 2017 14:36:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 17466366733480693905 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeljedrudehgdehgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Matroska AlphaMode element 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, 16 May 2017 12:40:37 -0000 Le 16/05/2017 à 14:05, Steve Lhomme a écrit : > > If there's no BlockAdditional then it's used the wrong way. It's not a > flag to inform that the track contains alpha data. > On the other hand I doubt anyone uses it how it was meant to. So we > might as well use it as a flag to tell whether the video contains > alpha data. I don't think that indicating that the the video contains alpha data is useful as we don't indicate that it contains color planes or any other planes. and it would deeply change the meaning of the element. So is it OK to explicitly say that this elements must (should?) not be present if there is no BlockAdditional or if there is no alpha in BlockAdditional? From nobody Tue May 16 12:11:56 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 58BCA12EBF7 for ; Tue, 16 May 2017 12:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG3dUWQkOvbL for ; Tue, 16 May 2017 12:11:52 -0700 (PDT) Received: from relays-agent02.techservices.illinois.edu (relays-agent02.techservices.illinois.edu [204.93.2.5]) (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 C284F12EC79 for ; Tue, 16 May 2017 12:06:44 -0700 (PDT) Received: from uex133.ad.uillinois.edu (uex133.cites.illinois.edu [192.17.212.209]) by relays-agent02.techservices.illinois.edu (8.16.0.17/8.16.0.17) with ESMTPS id v4GJ6bWk024606 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 16 May 2017 14:06:43 -0500 Received: from uex133.ad.uillinois.edu (192.17.212.209) by uex133.ad.uillinois.edu (192.17.212.209) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 16 May 2017 14:06:39 -0500 Received: from CITESHT4.ad.uillinois.edu (192.17.212.154) by uex133.ad.uillinois.edu (192.17.212.209) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Tue, 16 May 2017 14:06:39 -0500 Received: from CITESMBX5.ad.uillinois.edu ([169.254.10.79]) by CITESHT4.ad.uillinois.edu ([192.17.54.147]) with mapi id 14.03.0319.002; Tue, 16 May 2017 14:06:39 -0500 From: "Jones, Jimi Lee" CC: Codec Encoding for LossLess Archiving and Realtime transmission Thread-Topic: [Cellar] cellar - New Meeting Session Request for IETF 99 Thread-Index: AQHSznbMVxnQdV/teU6K33Hd15I8BqH3Uhcw Date: Tue, 16 May 2017 19:06:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.174.232.96] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705160152 X-Spam-OrigSender: jjones7@illinois.edu X-Spam-Bar: Archived-At: Subject: Re: [Cellar] cellar - New Meeting Session Request for IETF 99 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, 16 May 2017 19:11:54 -0000 SSBwbGFuIHRvIHBhcnRpY2lwYXRlIHJlbW90ZWx5LiANCg0KSmltaSBKb25lcw0KU2Nob29sIG9m IEluZm9ybWF0aW9uIFNjaWVuY2VzDQpVbml2ZXJzaXR5IG9mIElsbGlub2lzIGF0IFVyYmFuYS1D aGFtcGFpZ24NCjUwMSBFYXN0IERhbmllbCBTdHJlZXQNCk1DLTQ5Mw0KQ2hhbXBhaWduLCBJTCA2 MTgyMC02MjExDQpodHRwOi8vd3d3Lmxpcy5pbGxpbm9pcy5lZHUvIA0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGV2ZSBMaG9tbWUgW21haWx0bzpzbGhvbW1lQG1hdHJv c2thLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBNYXkgMTYsIDIwMTcgNjo0OSBBTQ0KVG86IFJldG8g S3JvbWVyDQpDYzogQ29kZWMgRW5jb2RpbmcgZm9yIExvc3NMZXNzIEFyY2hpdmluZyBhbmQgUmVh bHRpbWUgdHJhbnNtaXNzaW9uDQpTdWJqZWN0OiBSZTogW0NlbGxhcl0gY2VsbGFyIC0gTmV3IE1l ZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0IGZvciBJRVRGIDk5DQoNCkkgbWlnaHQgZ28gaW4gcGVyc29u IGJ1dCB0aGF0J3Mgc3RpbGwgdXAgaW4gdGhlIGFpci4NCg0KV2hlbiBkbyB3ZSBuZWVkIGFuIGFu c3dlciA/IEFuZCBXaGVuIGRvIHdlIGtub3cgd2hpY2ggZGF0ZSB0aGUgQ0VMTEFSIG1lZXRpbmcg d291bGQgYmUgb24gPw0KDQpUaGFua3MNCg0KMjAxNy0wNC0yNyAxMjo0MCBHTVQrMDI6MDAgUmV0 byBLcm9tZXIgPGxpc3RzQHJldG8uY2g+Og0KPiBQbGVhc2UgY291bnQgbWUgYXMgcmVtb3RlIGF0 dGVuZGVlLiBUaGFuayB5b3UhIFJldG8NCj4NCj4NCj4gU3RldmUgTGhvbW1lIHdyb3RlOg0KPg0K Pj5JJ2xsIHByb2JhYmx5IGRvIHRoYXQgYXMgd2VsbC4NCj4+DQo+PjIwMTctMDQtMjYgMjE6NDMg R01UKzAyOjAwIFBldGVyIEIuIDxwYkBkYXMtd2Vya3N0YXR0LmNvbT46DQo+Pj4gSSdkIGJlIHBh cnRpY2lwYXRpbmcgcmVtb3RlbHksIHRvbyA6RA0KPj4+DQo+Pj4NCj4+PiBDaGVlcnMsDQo+Pj4g UGV0ZXINCj4+Pg0KPj4+IE9uIDA0LzI2LzIwMTcgMDQ6MDggUE0sIEFzaGxleSBCbGV3ZXIgd3Jv dGU6DQo+Pj4+IEZvcnR1bmF0ZWx5IGZvciBldmVyeW9uZSBvbiB0aGUgbGlzdCBpbnRlcmVzdGVk IGluIHRoaXMgbWVldGluZyBidXQNCj4+Y2FuJ3QNCj4+Pj4gaG9wIG92ZXIgdG8gUHJhZ3VlLCBJ RVRGIGRvZXMgYW4gZXhjZWxsZW50IGpvYiBvZiBlbnN1cmluZyByZW1vdGUgDQo+Pj4+IHBhcnRp Y2lwYXRpb24hDQo+Pj4+DQo+Pj4+IEFzaGxleQ0KPj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBDZWxsYXIgbWFpbGluZyBs aXN0DQo+Pj4gQ2VsbGFyQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jZWxsYXINCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IENlbGxhciBtYWlsaW5nIGxpc3QNCj4gQ2VsbGFyQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2VsbGFyDQoNCg0K DQotLQ0KU3RldmUgTGhvbW1lDQpNYXRyb3NrYSBhc3NvY2lhdGlvbiBDaGFpcm1hbg0KDQoNCg== From nobody Thu May 18 09:17: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 75E061292F4 for ; Thu, 18 May 2017 09:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7S0HqHDotDA for ; Thu, 18 May 2017 09:17:48 -0700 (PDT) Received: from relays-agent02.techservices.illinois.edu (relays-agent02.techservices.illinois.edu [204.93.2.5]) (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 C5E5C12EB23 for ; Thu, 18 May 2017 09:12:13 -0700 (PDT) Received: from uex132.ad.uillinois.edu (uex132.cites.illinois.edu [192.17.212.208]) by relays-agent02.techservices.illinois.edu (8.16.0.17/8.16.0.17) with ESMTPS id v4IGC87A014927 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 18 May 2017 11:12:09 -0500 Received: from uex132.ad.uillinois.edu (192.17.212.208) by uex132.ad.uillinois.edu (192.17.212.208) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 18 May 2017 11:12:08 -0500 Received: from CITESHT2.ad.uillinois.edu (192.17.212.152) by uex132.ad.uillinois.edu (192.17.212.208) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Thu, 18 May 2017 11:12:08 -0500 Received: from CITESMBX5.ad.uillinois.edu ([169.254.10.79]) by CITESHT2.ad.uillinois.edu ([128.174.34.207]) with mapi id 14.03.0319.002; Thu, 18 May 2017 11:12:08 -0500 From: "Jones, Jimi Lee" To: Codec Encoding for LossLess Archiving and Realtime transmission Thread-Topic: Invitation to participate in PhD dissertation related to CELLAR standards development work Thread-Index: AdLP8XTwdAqlZESuQNa/pXfwHAG/WQ== Date: Thu, 18 May 2017 16:12:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.174.232.96] Content-Type: multipart/alternative; boundary="_000_C9B9372FEDBD0F4D8BB90BF9BCFBAE4557CC1111CITESMBX5aduill_" MIME-Version: 1.0 X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705180106 X-Spam-OrigSender: jjones7@illinois.edu X-Spam-Bar: Archived-At: Subject: [Cellar] Invitation to participate in PhD dissertation related to CELLAR standards development work 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, 18 May 2017 16:17:50 -0000 --_000_C9B9372FEDBD0F4D8BB90BF9BCFBAE4557CC1111CITESMBX5aduill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apologies for any cross-posts of the following: Greetings! I am emailing to ask if you would be interested in being a parti= cipant in my upcoming doctoral dissertation work. My work will be, in short= , to look at the development and/or adoption of two video digitization stan= dards: the FADGI MXF/JPEG2000 application specification and/or the CELLAR M= atroska/FFV1 combination (or something similar, since the CELLAR work is st= ill in progress). To this end, I would like to interview you to learn more about: * Your participation in developing either or both of these standard= s (if applicable) * Your choice to use or NOT to use either of these standards, or so= mething similar, in your digitization work (if applicable) If you are involved in digitization work, I would also like to conduct a si= te visit to observe your work to learn more about how you and your institut= ion use (or choose NOT to use) these (or similar) container/encoding combin= ations. Because my work has not yet been approved by my university's Institutional = Review Board (https://oprs.research.illinois.edu/about-oprs-irb), I am not = able to start asking you questions now about your work. I should get formal= approval for this work this summer. Think of this email as simply a reques= t for your participation. I would like to conduct interviews and site visit= s in the fall of 2017 and the spring of 2018, as your schedule permits. If = you choose to participate (and, of course, I hope you will), I am happy to = work out details about scheduling with you. If you can think of other people with whom I should talk, either at your in= stitution or elsewhere, please let me know! I am also happy to provide the full dissertation proposal document if you'd= like. I hope to hear from you, and thank you for considering my request! Best, Jimi Jimi Jones School of Information Sciences University of Illinois at Urbana-Champaign 501 East Daniel Street MC-493 Champaign, IL 61820-6211 http://www.lis.illinois.edu/ ---- A bit more about my proposed dissertation work: My research focuses on standards for moving image digitization - the social= aspects of their design, the technical choices that drive their developmen= t and the decision-making processes of large and small cultural heritage re= positories when picking an encoding/container combination for digitizing th= eir legacy video materials. I want to do qualitative analyses of two models= of standards development: how they are developed by large, well-funded ins= titutions/associations and how they are developed "bottom up" by the open-s= ource/not-for-profit realm. More specifically, I plan to look at the development and implementation of = the Library of Congress' MXF/JPEG 2000 application specification (AS-07 - h= ttp://www.digitizationguidelines.gov/guidelines/MXF_app_spec.html) and the = development of the Matroska/FFV1 specification by the CELLAR group (https:/= /mediaarea.net/MediaConch/2016/07/26/No-Time-To-Wait-Preservation-FFV1-Matr= oska-Symposium/). I also plan to look at implementations of Matroska and FF= V1. I believe my research will make a theoretical contribution to our understan= ding of how audiovisual standards are developed, how they work and how they= are implemented in the library/archives world. My work will also contribut= e to a growing body of work related to video digitization in the world of c= ultural heritage. --_000_C9B9372FEDBD0F4D8BB90BF9BCFBAE4557CC1111CITESMBX5aduill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Apologies for any = cross-posts of the following:

 

 

Greetings! I am email= ing to ask if you would be interested in being a participant in my upcoming= doctoral dissertation work. My work will be, in short, to look at the development and/or adoption of two video digitization stand= ards: the FADGI MXF/JPEG2000 application specification and/or the CELLAR Ma= troska/FFV1 combination (or something similar, since the CELLAR work is sti= ll in progress).

 

To this end, I would = like to interview you to learn more about:

·       &nb= sp; Your participation in developing eit= her or both of these standards (if applicable)

·       &nb= sp; Your choice to use or NOT to use eit= her of these standards, or something similar, in your digitization work (if= applicable)

 

If you are involved i= n digitization work, I would also like to conduct a site visit to observe y= our work to learn more about how you and your institution use (or choose NOT to use) these (or similar) container/encoding combinati= ons.

 

Because my work has n= ot yet been approved by my university’s Institutional Review Board (<= /span>https://oprs.research.illinois.edu/about-oprs-irb), I am not able to start asking you questions now about your work. I should = get formal approval for this work this summer. Think of this email as simpl= y a request for your participation. I would like to conduct interviews and = site visits in the fall of 2017 and the spring of 2018, as your schedule permits. If you choose to partici= pate (and, of course, I hope you will), I am happy to work out details abou= t scheduling with you.

 

If you can think o= f other people with whom I should talk, either at your institution or elsew= here, please let me know!

 

I am also happy to pr= ovide the full dissertation proposal document if you’d like.

 

I hope to hear from y= ou, and thank you for considering my request!


Best,

 

Jimi

 

Jimi Jones

School of Information= Sciences

University of Illinoi= s at Urbana-Champaign

501 East Daniel Stree= t

MC-493

Champaign, IL 61820-6= 211

http://www.lis.illinois.edu/

 

----

 

A bit more about m= y proposed dissertation work:

My research focuses o= n standards for moving image digitization - the social aspects of their des= ign, the technical choices that drive their development and the decision-making processes of large and small cultural heritage rep= ositories when picking an encoding/container combination for digitizing the= ir legacy video materials. I want to do qualitative analyses of two models = of standards development: how they are developed by large, well-funded institutions/associations and how they= are developed “bottom up” by the open-source/not-for-profit re= alm.

 

More specifically, I = plan to look at the development and implementation of the Library of Congre= ss’ MXF/JPEG 2000 application specification (AS-07 - http://www.digitizationguidelines.gov/guidelines/MXF_a= pp_spec.html) and the development of the Matroska/FFV1 specification by the CELLAR group= (https://mediaarea.net= /MediaConch/2016/07/26/No-Time-To-Wait-Preservation-FFV1-Matroska-Symposium= /). I also plan to look at implementations of Matroska and FFV1. <= /o:p>

 

I believe my research= will make a theoretical contribution to our understanding of how audiovisu= al standards are developed, how they work and how they are implemented in the library/archives world. My work will also contribute to= a growing body of work related to video digitization in the world of cultu= ral heritage.

 

--_000_C9B9372FEDBD0F4D8BB90BF9BCFBAE4557CC1111CITESMBX5aduill_-- From nobody Thu May 18 09:35: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 3DA9D12EB45 for ; Thu, 18 May 2017 09:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_REMOTE_IMAGE=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viaa.be 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 Wr-CMM96DCUD for ; Thu, 18 May 2017 09:35:18 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5CD1270AC for ; Thu, 18 May 2017 09:29:38 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id h16so28270302vkd.2 for ; Thu, 18 May 2017 09:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viaa.be; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Kd6GEW53PsSjzyZtaPu3LByRt5EinEODC2FZY0NThSc=; b=di++6b4WaAETPo7VgpVpX+w3l+KH7TRK1pTpFpy7LMF1IkbyuMQf8dCeGacNxiITnV qTsex22OpCjxyqIihtoFbzEGJ224goEqVVwN7LAZx0h74qAbQOfK07p2X1dLVzUFbYG4 eQYZis74Ph3GLe8oNf+qeDODJiG6BOgmd8MA2IMCAwtRizPPnOwuxtQhq64ql9a2geSU JYsmi6QWLVCEjofk4uHPm3TUczpTfV9gQS3k0HsVh8tNW1xTj0zzZUh5ahbCsooXZosL 6I1wTPI484lCYLA6X9AvuyGwlFgG8KEWgieG/FFEmZGtAYOkTVt5phAjwcqpWgWW9QBn KTzA== 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=Kd6GEW53PsSjzyZtaPu3LByRt5EinEODC2FZY0NThSc=; b=C+2HM5oLdxw9jWLnOASZTYbpuXzubViNaXofvOW8LxiUmB2PWtiaSh8lvwRcD/Av5P KkJgFs8FD6CTaQigfSH+TL9SkNR/l8sxN5Ic1XX9N+k9B/unQUiKJlFOF5yUpIGkyfuR 2VDlR5WuH0MTHadXA4fIrN2qPiB0iEtUhexymTrV05vh8GBy69Ouu493keyx7uq8cUZ7 GpNGTc9bE6Z89feEV8AsJKvJpokeJaa9Mds0hN7HRP5paNZ0/+DHGSZ7O6dHZl7cBLRA eAzCk6cEzMXWrjzS0ojMlGlauKbMvu2wPgaWIhRqtw5SpiWMdqMKpG5PDlk9uu2XLIpU zuUw== X-Gm-Message-State: AODbwcA6z29eroILSSR7dr9QVKpuX5Glcz2FeBCwJHLqAkXuT1PEDitj /nWjF9xmSc8mA9WMgFmUcXYTblZKkCeJ X-Received: by 10.31.254.78 with SMTP id l75mr2497013vki.34.1495124977749; Thu, 18 May 2017 09:29:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.77.130 with HTTP; Thu, 18 May 2017 09:29:07 -0700 (PDT) In-Reply-To: References: From: Brecht Declercq Date: Thu, 18 May 2017 18:29:07 +0200 Message-ID: To: "Jones, Jimi Lee" , cellar@ietf.org Content-Type: multipart/alternative; boundary="94eb2c149ff031b063054fcee9f2" Archived-At: Subject: Re: [Cellar] Invitation to participate in PhD dissertation related to CELLAR standards development work 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, 18 May 2017 16:35:22 -0000 --94eb2c149ff031b063054fcee9f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Jimi Lee, dear colleagues, I think that our institution VIAA could be an interesting case in this regard, as we opted 4 years ago to go for MXF/JPEG2000 and currently we keep a keen eye on MKV/FFv1, as we also tell in this blog post: https://viaa.be/en/tech-blog/2017/4/resultaten-onderzoek-ffv1-en-mkv Happy to tell you about how we made our decision and how our future decisions are getting shaped. I also would like to point you to the *Call for Papers of the FIAT/IFTA World Conference in Mexico in October*: http://fiatifta.org/index.php/2017/04/07/call-for-presentations-fiatifta-wo= rld-conference-2017/ It is no coincidence that this CfP mentions (chapter 6): *Transformation in the digital age: sustainability, digital preservation and large-scale transcoding and/or rewrapping:* - The quest for a sustainable format and codec: reconciling preservation and production needs: what will the future bring? - Transcoding project management: deciding, planning, testing, executing, controlling and evaluating - Preservation watchdogs: checking sustainability and file integrity in large-scale digital archives The deadline to submit a paper *is May 31st.* Best regards, 2017-05-18 18:12 GMT+02:00 Jones, Jimi Lee : > *Apologies for any cross-posts of the following:* > > > > > > Greetings! I am emailing to ask if you would be interested in being a > participant in my upcoming doctoral dissertation work. My work will be, i= n > short, to look at the development and/or adoption of two video digitizati= on > standards: the FADGI MXF/JPEG2000 application specification and/or the > CELLAR Matroska/FFV1 combination (or something similar, since the CELLAR > work is still in progress). > > > > To this end, I would like to interview you to learn more about: > > =C2=B7 Your participation in developing either or both of these > standards (if applicable) > > =C2=B7 Your choice to use or NOT to use either of these standards= , or > something similar, in your digitization work (if applicable) > > > > If you are involved in digitization work, I would also like to conduct a > site visit to observe your work to learn more about how you and your > institution use (or choose NOT to use) these (or similar) > container/encoding combinations. > > > > Because my work has not yet been approved by my university=E2=80=99s Inst= itutional > Review Board (https://oprs.research.illinois.edu/about-oprs-irb), I am > not able to start asking you questions now about your work. I should get > formal approval for this work this summer. Think of this email as simply = a > request for your participation. I would like to conduct interviews and si= te > visits in the fall of 2017 and the spring of 2018, as your schedule > permits. If you choose to participate (and, of course, I hope you will), = I > am happy to work out details about scheduling with you. > > > > *If you can think of other people with whom I should talk, either at your > institution or elsewhere, please let me know!* > > > > I am also happy to provide the full dissertation proposal document if > you=E2=80=99d like. > > > > I hope to hear from you, and thank you for considering my request! > > > Best, > > > > Jimi > > > > Jimi Jones > > School of Information Sciences > > University of Illinois at Urbana-Champaign > > 501 East Daniel Street > > MC-493 > > Champaign, IL 61820-6211 > > http://www.lis.illinois.edu/ > > > > ---- > > > > *A bit more about my proposed dissertation work:* > > My research focuses on standards for moving image digitization - the > social aspects of their design, the technical choices that drive their > development and the decision-making processes of large and small cultural > heritage repositories when picking an encoding/container combination for > digitizing their legacy video materials. I want to do qualitative analyse= s > of two models of standards development: how they are developed by large, > well-funded institutions/associations and how they are developed =E2=80= =9Cbottom > up=E2=80=9D by the open-source/not-for-profit realm. > > > > More specifically, I plan to look at the development and implementation o= f > the Library of Congress=E2=80=99 MXF/JPEG 2000 application specification = (AS-07 - > http://www.digitizationguidelines.gov/guidelines/MXF_app_spec.html) and > the development of the Matroska/FFV1 specification by the CELLAR group ( > https://mediaarea.net/MediaConch/2016/07/26/No-Time- > To-Wait-Preservation-FFV1-Matroska-Symposium/). I also plan to look at > implementations of Matroska and FFV1. > > > > I believe my research will make a theoretical contribution to our > understanding of how audiovisual standards are developed, how they work a= nd > how they are implemented in the library/archives world. My work will also > contribute to a growing body of work related to video digitization in the > world of cultural heritage. > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --=20 [image: VIAA] Brecht Declercq Manager Digitalisering & Acquisitie VIAA vzw* | Sassevaartstraat 46/209 | 9000 Gent | Belgi=C3=AB | www.vi= aa.be * T: +32 9 298 05 01 *|* M: +32 474 25 04 67 --94eb2c149ff031b063054fcee9f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Jimi Lee, dear colleagues,

I think= that our institution VIAA could be an interesting case in this regard, as = we opted 4 years ago to go for MXF/JPEG2000 and currently we keep a keen ey= e on MKV/FFv1, as we also tell in this blog post:=C2=A0

Happy to tell you about how we made our decision = and how our future decisions are getting shaped.

I= also would like to point you to the Call for Papers of the FIAT/IFTA= World Conference in Mexico in October:

It is= no coincidence that this CfP mentions (chapter 6):

Transformation in the digital age: sustainabil= ity, digital preservation and large-scale transcoding and/or rewrapping:
  • The quest for a sustainable format and c= odec: reconciling preservation and production needs: what will the future b= ring?
  • Transcoding project management: deciding, planning, testing, e= xecuting, controlling and evaluating
  • Preservation watchdogs: checkin= g sustainability and file integrity in large-scale digital archives

The deadline to submit a paper is May 31st.<= /b>

Best regards,=C2=A0

<= br>

20= 17-05-18 18:12 GMT+02:00 Jones, Jimi Lee <jjones7@illinois.edu><= /span>:

Apologies for any = cross-posts of the following:

=C2=A0<= /span>

=C2=A0<= /span>

Greetings! I am email= ing to ask if you would be interested in being a participant in my upcoming= doctoral dissertation work. My work will be, in short, to look at the development and/or adoption of two video digitization stand= ards: the FADGI MXF/JPEG2000 application specification and/or the CELLAR Ma= troska/FFV1 combination (or something similar, since the CELLAR work is sti= ll in progress).

=C2=A0

To this end, I would = like to interview you to learn more about:

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Your participation in developing either= or both of these standards (if applicable)

=C2=B7=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Your choice to use or NOT to use either= of these standards, or something similar, in your digitization work (if ap= plicable)

=C2=A0

If you are involved i= n digitization work, I would also like to conduct a site visit to observe y= our work to learn more about how you and your institution use (or choose NOT to use) these (or similar) container/encoding combinati= ons.

=C2=A0

Because my work has n= ot yet been approved by my university=E2=80=99s Institutional Review Board = (https://oprs.research.illinois.edu/about-oprs-i= rb), I am not able to start asking you questions now about your work. I should = get formal approval for this work this summer. Think of this email as simpl= y a request for your participation. I would like to conduct interviews and = site visits in the fall of 2017 and the spring of 2018, as your schedule permits. If you choose to partici= pate (and, of course, I hope you will), I am happy to work out details abou= t scheduling with you.

=C2=A0

If you can think o= f other people with whom I should talk, either at your institution or elsew= here, please let me know!

=C2=A0

I am also happy to pr= ovide the full dissertation proposal document if you=E2=80=99d like.

=C2=A0

I hope to hear from y= ou, and thank you for considering my request!


Best,

=C2=A0

Jimi=

=C2=A0

Jimi Jones<= /u>

School of Information= Sciences

University of Illinoi= s at Urbana-Champaign

501 East Daniel Stree= t

MC-493<= u>

Champaign, IL 61820-6= 211

http://www.lis.illinois.edu/=

=C2=A0

----=

=C2=A0

A bit more about m= y proposed dissertation work:

My research focuses o= n standards for moving image digitization - the social aspects of their des= ign, the technical choices that drive their development and the decision-making processes of large and small cultural heritage rep= ositories when picking an encoding/container combination for digitizing the= ir legacy video materials. I want to do qualitative analyses of two models = of standards development: how they are developed by large, well-funded institutions/associations and how they= are developed =E2=80=9Cbottom up=E2=80=9D by the open-source/not-for-profi= t realm.

=C2=A0

More specifically, I = plan to look at the development and implementation of the Library of Congre= ss=E2=80=99 MXF/JPEG 2000 application specification (AS-07 - http://www.digitizationguidelin= es.gov/guidelines/MXF_app_spec.html) and the development of the Matroska/FFV1 specification by the CELLAR group= (h= ttps://mediaarea.net/MediaConch/2016/07/26/No-Time-To-Wait-Preser= vation-FFV1-Matroska-Symposium/). I also plan to look at implementations of Matroska and FFV1.

=C2=A0

I believe my research= will make a theoretical contribution to our understanding of how audiovisu= al standards are developed, how they work and how they are implemented in the library/archives world. My work will also contribute to= a growing body of work related to video digitization in the world of cultu= ral heritage.

=C2=A0


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



--

3D"VIAA"
=C2=A0 =C2=A0 =C2=A0Brecht Declercq
=C2=A0 = =C2=A0 =C2=A0Manager Digitalisering & Acquisitie

=C2=A0 =C2=A0 =C2=A0VIAA vz= w=C2=A0|=C2=A0Sassevaartstraat 46/209=C2=A0| 9000 Gent | Belgi=C3= =AB |=C2=A0www.viaa.be<= /span>
=C2=A0 =C2=A0 =C2=A0T: +32 9 298 05 01=C2=A0|<= /span>=C2=A0M: +32 474 25 04 67=C2=A0


= <= /div>


=C2=A0= =C2=A0
=C2=A0
=C2=A0
=C2=A0
--94eb2c149ff031b063054fcee9f2-- From nobody Sun May 21 06:22:49 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 CAF0A129406 for ; Sun, 21 May 2017 06:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbHjMm_ZJ3z4 for ; Sun, 21 May 2017 06:22:47 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6631292FC for ; Sun, 21 May 2017 06:22:47 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id p73so39485357ywp.0 for ; Sun, 21 May 2017 06:22:47 -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:content-transfer-encoding; bh=rPE/6muw6Qskn9MhWmxRkiv9mGAF/JqTMHAe8yvV1r0=; b=jD8tg34AjS8CwFIfddJKrfY7l0uP8kv5i2imX6Wym9NMFLSKvhqRV5Z+J3T3x5Uct+ IXG1Lqob0yNihVUnjVqn9fQW1OYfxw+JN6Y/LeIvCOnUmu9FIvkPnu3/AhFzuiCXkxQU alRDXp7/Bwo0/1SHUdZrtXfQl4igP+s9V35Ku0hrNxvnIfsdFl8AHUSZcWtvlNdJwnOn yn9oyRBfxTPhVC/hDBlpxpoX5j4OJiZcYTyVZli9bgt30LG34aAjnlaTOy0r8n/VY3pJ xPtDJOO1eDrQdp5bK722azoHKgkEDzvT41gxd3rnx+xrj3exB/Ul0ujE2QkaVJ6SBPwH 1qNQ== 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:content-transfer-encoding; bh=rPE/6muw6Qskn9MhWmxRkiv9mGAF/JqTMHAe8yvV1r0=; b=YkHr2yOstM4EI/CecUyiZUUuglGKtsb19Mtouqmdpy4lpkU3un5qi/mHUhh+QC1LX+ objlBOuFrh83tgsg5KE9rjD90W3Z0m0/ZlhWv+Nvu4WErxpM8CDSOXQkigW2yLgwJA55 F1Cn9nEIJsEAOH3uzb3IJV6l0mj/n9GreHhCRjoSBbNgV/cq0OmvlKjoYmDhrtTgeWVi NVHnntfWd/5ehuMOiajpSYGSuLbBL1/t9I3RH+ZMnlQB2hix7DNIETmdp8V/YpVXIMHq xoYwcjMi55pKLcDvKIZypkt6oXYIyMUxT0jzg2+tjI+Hwmofopfc+mX1mnK9XZRCYji2 afPQ== X-Gm-Message-State: AODbwcBP7gB8FJT6SrQhWNIEQOQaRG0NKJ5TGjm//qt8GhC3eBog7Vka Xm6ifN5+BjJFKHNvvI7jRD9XaN0N49T9 X-Received: by 10.129.159.131 with SMTP id w125mr15212768ywg.210.1495372966386; Sun, 21 May 2017 06:22:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.129.193 with HTTP; Sun, 21 May 2017 06:22:45 -0700 (PDT) In-Reply-To: <2c64b607-0d81-33be-1cf8-c13c06d64008@mediaarea.net> References: <8c37c822-6a74-b8d9-d4a0-0525ccec42db@mediaarea.net> <2c64b607-0d81-33be-1cf8-c13c06d64008@mediaarea.net> From: Steve Lhomme Date: Sun, 21 May 2017 15:22:45 +0200 Message-ID: To: Jerome Martinez Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Matroska AlphaMode element 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, 21 May 2017 13:22:49 -0000 2017-05-16 14:36 GMT+02:00 Jerome Martinez : > Le 16/05/2017 =C3=A0 14:05, Steve Lhomme a =C3=A9crit : >> >> >> If there's no BlockAdditional then it's used the wrong way. It's not a >> flag to inform that the track contains alpha data. >> On the other hand I doubt anyone uses it how it was meant to. So we >> might as well use it as a flag to tell whether the video contains >> alpha data. > > > I don't think that indicating that the the video contains alpha data is > useful as we don't indicate that it contains color planes or any other Then we should deprecate it. It's most likely not used and there's current no clean what do define what BlockAdditionID does for what codec. In fact it's internal to the codec interpretation. So it probably belongs in the codec mapping description. But not a particular value in the file. > planes. and it would deeply change the meaning of the element. > So is it OK to explicitly say that this elements must (should?) not be > present if there is no BlockAdditional or if there is no alpha in > BlockAdditional? I think it's OK to say it should never be present. > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun May 21 07:02: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 1EF6C1293F9 for ; Sun, 21 May 2017 07:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 xwR85eJcw0Ah for ; Sun, 21 May 2017 07:02:04 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::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 60AC0124281 for ; Sun, 21 May 2017 07:02:04 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id 187so19190351ybg.0 for ; Sun, 21 May 2017 07:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J8Q0Jg4PA3OaL5Ivrxe6gTMZgZ40hJiicHnGCWSRd0E=; b=JD9KALV/MxoWYsWneHpQtyG94rlf8o3Fm8qko7xcLTXKB9+OMuClPABLdYJFVrFiMD +cStLn7/Sn1lphDcvMW+wIT+FrTb9ds0FMQHWzvBRuxNi6Vt8drWLEz5Iu8u4iAAFty0 SNgX1XbNw/qublLOT9Sj1NUL1zPGvgNm3OSgxm1RXh+ldahtQuCdPf8U/uW+eZ7FCBjY L5sUe13vCCbEQVp0CGYrXwTH5Rg8NxJpC/tWGh8iuvO5nRHB2TfykSctIdQuLz9/HLg2 SVg9Ku6ss6XhMszu+hh9M5MgUTsUkBVk43kFC9pxwb8xR/Ed2Cld/NJhq1lNRRoxnMtt tfCA== 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=J8Q0Jg4PA3OaL5Ivrxe6gTMZgZ40hJiicHnGCWSRd0E=; b=JsygBRTuiCtzE3iQsNSdxI17WpJts9iuoSsHQChj2SpcAVG4RS+vke1s+Z3KW5ppzk 2Ofel9q+T15lnrdorKmUDTBuF7a6syCj6MbWIU62j0sG/vxH+V4/kq2sgNPhvEwYi5ny p4sPlwt1gTstMM5+r7uPFTHDzpQ7aTBXs2Z67y9z0Ok7qjBvTsoghxg3QP0kYsZpzw/4 EC6yjYouOQtRNyhp/c4j5lcoR23ip8Rc6Q7hL2SFEJDGvMY9Sx60+noNydRJab3gSqlh UcvPI6RUhzWJssLHEE+bMHQChUUHUQEmIGZ9aGt7RHef7kiW+TFqCy3fxo3SY2s/1BJ0 PGeg== X-Gm-Message-State: AODbwcD3nMB6UjYWBowKR5oCDL006Jml+kpouLkUyaKwq4FCd/KYLzPn 4EZ2blMnyYGtNNP9jlyDNKT1EB6FiAdZbbA= X-Received: by 10.37.44.129 with SMTP id s123mr4246526ybs.84.1495375323525; Sun, 21 May 2017 07:02:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.129.193 with HTTP; Sun, 21 May 2017 07:02:02 -0700 (PDT) In-Reply-To: References: <90625ABD-48AE-41CC-AFE1-24BD57A62415@dericed.com> <52163786-3428-4524-A772-0C5E121D991A@dericed.com> From: Steve Lhomme Date: Sun, 21 May 2017 16:02:02 +0200 Message-ID: To: Matt Gruenke Cc: Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] TrackTypes for non-standard data formats 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, 21 May 2017 14:02:06 -0000 2017-04-29 22:20 GMT+02:00 Matt Gruenke : > On Fri, Apr 28, 2017 at 8:37 PM, Dave Rice wrote: > >> >> I sent a pull request for review at >> https://github.com/Matroska-Org/matroska-specification/pull/117, which adds >> this to the Codec Mapping page. >> >> ## Recommendations for the Creation of New Codec Mappings >> >> Creators of new Codec Mappins to be used in the context of Matroska: >> >> - SHOULD assume that all Codec Mappings they create might become >> standardized, public, commonly deployed, or usable across multiple >> implementations. >> >> - SHOULD employ meaningful values for Codec ID and Codec Name that they >> have reason to believe are currently unused. >> >> - SHOULD NOT prefix their Codec ID with "X-" or similar constructs. >> >> These recommendations are based upon Section 3 of [@!RFC6648]. > > > It's important to note that while IANA deprecated the X- prefix, they > replaced it with the Vendor and Personal trees. > > https://tools.ietf.org/html/rfc6838#section-3 > > > > So, you can certainly say "don't use X_". But, if someone has an encoding > that doesn't fit any of the existing prefixes, then using "Y_" is just as > bad (or worse). Copying my reply to PR #117 improving the Codec ID definition: In fact I would add that they must adhere to the nomenclature in the Codec ID section found upper in the specification (which doesn't seem to render nicely in HTML). For already known codec types they just follow this rule and use a fancy name (previous SHOULD in this section). For unknown codec types maybe it's better to seek for a consensus before using a new codec type. Maybe there are good reasons it's not there. How about adding EXPERIMENTAL/ names and/or PRIVATE/? Should we add the 4 types of custom IDs like in https://tools.ietf.org/html/rfc6838#section-3 ? (vendor, personal, unregistered, external) Also as a side note, GoPro just defined a "custom" track in MP4 for precise GPS handling. https://github.com/gopro/gpmf-parser Now that I think about it, the track type would have been better as a bit field. So for example when audio and video are mixed it would be 1|2 (3). And various common types of metadata would have a bit (subtitle, teletext, buttons, gps, etc). That would avoid having all kinds of types for all kinds of combinations... Right now the GoPro track would fall in the category of "complex" > > Matt > -- Steve Lhomme Matroska association Chairman From nobody Mon May 22 11:06: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 403EE1270AC for ; Mon, 22 May 2017 11:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.581 X-Spam-Level: * X-Spam-Status: No, score=1.581 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 l2mrE31Xsuhq for ; Mon, 22 May 2017 11:06:36 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80685126DEE for ; Mon, 22 May 2017 11:06:36 -0700 (PDT) Received: from [146.96.19.240] (port=56925 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 1dCrix-001LG4-3w; Mon, 22 May 2017 14:06:34 -0400 From: Dave Rice Message-Id: <5ECF235E-7934-468F-B3A7-90CE6EEEB555@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D5331444-8C3E-4C81-A44A-605CD9C47370" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Mon, 22 May 2017 14:06:29 -0400 In-Reply-To: Cc: flac-dev@xiph.org To: Codec Encoding for LossLess Archiving and Realtime transmission References: X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.6 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] FLAC Markdown 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, 22 May 2017 18:06:40 -0000 --Apple-Mail=_D5331444-8C3E-4C81-A44A-605CD9C47370 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 12, 2017, at 1:05 PM, Dave Rice wrote: >=20 > Hi all, > And cc'ing flac-dev. >=20 >> On May 10, 2017, at 12:15 PM, Dave Rice > wrote: >>=20 >> Hi Andrew, >>=20 >>> On May 10, 2017, at 11:19 AM, Andrew James Weaver > wrote: >>>=20 >>> Hello all! >>>=20 >>> In a previous discussions on this list about people interested in = working on the FLAC standard, I said that I would be willing to start = the process of converting the existing standard into Markdown. I am = writing to inform the list that I have begun preliminary work on this = conversion. >>>=20 >>> Currently that work is living here = https://github.com/privatezero/flac_markdown = . >>=20 >> I sent a pull request at = https://github.com/privatezero/flac_markdown/pull/1 = , which starts to = add a process to convert the markdown to the RFC format using the same = Makefile approach that we use with the FFV1 and EBML markdown files. = There's still a lot of inter-document cross-referencing that needs to be = adjusted before the Makefile works. For instance current = cross-referencing like: >>=20 >> [*SUBFRAME\_VERBATIM*](#subframe_verbatim) >>=20 >> won't render as expected in a plain text RFC, but would simply render = to something like "Section X.X.X". >>=20 >> In EBML we use markdown such as >> See [the section on `Element Data Size`](#element-data-size) for = rules that apply to elements of unknown length. >> so that in the RFC this renders to >> See Section 7 for rules that apply to elements of unknown length. >> and in the markdown it renders to >>=20 >> See the section on=C2=A0Element Data Size = for rules that apply to elements of = unknown length. >=20 > I added some issues to the flac_markdown repository and Andrew = addressed them in https://github.com/privatezero/flac_markdown/pull/7 = . Most of these = issues pertain to unintended semantic differences between the FLAC = specification as it exists in its original HTML form at = https://xiph.org/flac/format.html = and the markdown rendition being worked on at = https://github.com/privatezero/flac_markdown/blob/master/flac.md = . >=20 > Since the recent work focuses on a change of format from HTML to = markdown, I suggest that short term goals on the flac specification = focus on: > - verifying semantic equalness with the html version > - resolving issues that block the mmark/xml2rfc process that generates = the RFC formats of the specification > - add standard RFC boilerplate (abstract, rfc2119, etc) To summarize recent work on the FLAC specification, the document has = been adjusted in its new markdown format in order to achieve semantic = similarity to the original HTML rendition on the xiph.org site. In order = to get the structural data (such as the tables at the end of = https://xiph.org/flac/format.html) to fit in plain text RFC style, the = tables were dissected a bit to separate value lists from structural = lists. In this way the subcomponents and defined in their own sections = instead of the prior strategy of detailing lists and pseudocode within = large tables. For instance see the original rendition of the frame = header documentation from https://xiph.org/flac/format.html#frame_header = compared to the dissected version which gives the subcomponents their = own subsequent sections at = https://github.com/privatezero/flac_markdown/blob/7a5c21d49d1fda89609ffa9e= dfca2447c7ca3c5e/flac.md#frame_header. Splitting out the subcomponents = into their own sections also gives space to be more explicate in = defining them, such as = https://github.com/privatezero/flac_markdown/commit/3aaa5f293102018bd7c414= 09e79e36f510557d96. Andrew noticed that there are some issues with managing section titles = that contain underscores and getting internal sectional citations to = work. For instance (#frame-header) will link to `FRAME HEADER` (space) = but not `FRAME_HEADER` (underscore). Is there any reason not to swap the = all-caps, underscored component names to tilde-quoted, all caps name = with spaces rather than underscores? For convenience, here is a rendering of the plain text RFC output of = git-master of the FLAC format repository: = https://gist.github.com/dericed/2639d0eed5e064b4dec1399bc8716833. I suggest reviews of the current markdown from those familiar with the = historical FLAC format specification so that we ensure that the current = work is the same in meaning to the original html version of the = specification. Best Regards, Dave Rice= --Apple-Mail=_D5331444-8C3E-4C81-A44A-605CD9C47370 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 12, 2017, at 1:05 PM, Dave Rice <dave@dericed.com> = wrote:

Hi all,
And cc'ing flac-dev.

On May = 10, 2017, at 12:15 PM, Dave Rice <dave@dericed.com> wrote:

Hi Andrew,

On May 10, 2017, at 11:19 AM, Andrew James Weaver <weevz@uw.edu> = wrote:

Hello all!

In a previous discussions on this list about people = interested in working on the FLAC standard, I said that I would be = willing to start the process of converting the existing standard into = Markdown. I am writing to inform the list that I have begun preliminary = work on this conversion.

Currently that work is living here https://github.com/privatezero/flac_markdown.

I sent a pull = request at https://github.com/privatezero/flac_markdown/pull/1, = which starts to add a process to convert the markdown to the RFC format = using the same Makefile approach that we use with the FFV1 and EBML = markdown files. There's still a lot of inter-document cross-referencing = that needs to be adjusted before the Makefile works. For instance = current cross-referencing like:

[*SUBFRAME\_VERBATIM*](#subframe_verbatim)

won't render as expected = in a plain text RFC, but would simply render to something like "Section = X.X.X".

In = EBML we use markdown such as
See [the section on `Element Data Size`](#element-data-size) =
for rules that apply to elements of unknown length.
so that in the RFC this renders to
See Section 7 for rules that apply to elements of unknown =
length.
and in the markdown it renders = to

See the section on Element = Data Size for= rules that apply to elements of unknown = length.

I added some issues to the = flac_markdown repository and Andrew addressed them in https://github.com/privatezero/flac_markdown/pull/7. Most = of these issues pertain to unintended semantic differences between the = FLAC specification as it exists in its original HTML form at https://xiph.org/flac/format.html and the markdown rendition = being worked on at https://github.com/privatezero/flac_markdown/blob/master/flac.m= d.

Since = the recent work focuses on a change of format from HTML to markdown, I = suggest that short term goals on the flac specification focus = on:
- = verifying semantic equalness with the html version
- resolving issues that = block the mmark/xml2rfc process that generates the RFC formats of the = specification
- = add standard RFC boilerplate (abstract, rfc2119, = etc)

To summarize = recent work on the FLAC specification, the document has been adjusted in = its new markdown format in order to achieve semantic similarity to the = original HTML rendition on the xiph.org site. In order to get the structural data (such = as the tables at the end of https://xiph.org/flac/format.html) to fit in plain text = RFC style, the tables were dissected a bit to separate value lists from = structural lists. In this way the subcomponents and defined in their own = sections instead of the prior strategy of detailing lists and pseudocode = within large tables. For instance see the original rendition of the = frame header documentation from https://xiph.org/flac/format.html#frame_header compared = to the dissected version which gives the subcomponents their own = subsequent sections at https://github.com/privatezero/flac_markdown/blob/7a5c21d49d1fd= a89609ffa9edfca2447c7ca3c5e/flac.md#frame_header. Splitting out the = subcomponents into their own sections also gives space to be more = explicate in defining them, such as https://github.com/privatezero/flac_markdown/commit/3aaa5f29310= 2018bd7c41409e79e36f510557d96.

Andrew noticed that there are some issues with = managing section titles that contain underscores and getting internal = sectional citations to work. For instance (#frame-header) will link to = `FRAME HEADER` (space) but not `FRAME_HEADER` (underscore). Is there any = reason not to swap the all-caps, underscored component names to = tilde-quoted, all caps name with spaces rather than = underscores?

For convenience, here = is a rendering of the plain text RFC output of git-master of the FLAC = format repository: https://gist.github.com/dericed/2639d0eed5e064b4dec1399bc871683= 3.

I suggest reviews of the = current markdown from those familiar with the historical FLAC format = specification so that we ensure that the current work is the same in = meaning to the original html version of the specification.

Best Regards,
Dave = Rice
= --Apple-Mail=_D5331444-8C3E-4C81-A44A-605CD9C47370-- From nobody Tue May 30 09:03: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 2403312954D for ; Tue, 30 May 2017 09:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 uFLWFasNDcEA for ; Tue, 30 May 2017 09:03:21 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 296F5126E01 for ; Tue, 30 May 2017 09:03:21 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id r63so44188494itc.1 for ; Tue, 30 May 2017 09:03:21 -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=eA4D9Rx4mThPUGRY5Z+zXdZvEwrrIwqxeC4OUISQbfc=; b=n7qxsVszTeEzW9rS/uYS4xADWjQVdUekdopg+LO9vw4aAaC6NxAGXZUG8oIYg+oDEf Qs4unb4szHOOvYEIWm7xSdgLmalq/ScwbAIu7fhVfXwyE2t/UyQw14PLADgnuC4X7Fxp id3at85M7fRs6q+ZBYUR3gLGp6QsM+/ANxgHo+9j8oSsXUSsF/26prLcHB6rQV6RXqbF EI9BNZgNN4eTrt0rZRdOLqJjsBi88VMF5i7HBAa+pexyYYXDtPfQiSTy/v876jkwxnX7 dDroDhNFx2BffHhrTLGpHZjwpi4Ylw28GOXyi57+99OmFeHMl3p74t/wINVzoz5aA+iD KZMw== 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=eA4D9Rx4mThPUGRY5Z+zXdZvEwrrIwqxeC4OUISQbfc=; b=DQvKixwR+ozd0qUAlSwko/uiKIkExvgsxB5a1hH3/wvr3KmO9OS1DuAc3rumNgzY8u 8dZ59IFsweZ/dvvccwYD/bTe8aNpaCvRm+4ggC2kOtVh0XKkuKj0ZZomThBdKikjhVCH hhL8hf2Eix6H+OWETthoFQLjQSymYVcp8e9ns5R1ZMJYNHD22MtyahA3nhXeQ3LAQUBu hRTQfSqLJyf20lU1mxGaduqArAgUKf7fHkltY+NmwKEtv5Znz2FMj0JuOocoew6oK8Pn lZoN8Okzt+Kq0PGUwa2nqlnKeqQqoFltbN0A8LyzX+a/Yjl0tnlH4yOP7Xq2vK/qlx3D SC4Q== X-Gm-Message-State: AODbwcCulvCEKT0UTfyXvdScF02OVDGsWtVWLhPejIlGKpOMFD1wKtkz BW9huFJSBGZL6HPbDB37QiCsftwunsRC X-Received: by 10.36.118.12 with SMTP id z12mr2772668itb.47.1496160200389; Tue, 30 May 2017 09:03:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.25.11 with HTTP; Tue, 30 May 2017 09:02:39 -0700 (PDT) In-Reply-To: References: From: Tessa Fallon Date: Tue, 30 May 2017 12:02:39 -0400 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a114412ca4597ac0550bff1fb" Archived-At: Subject: Re: [Cellar] cellar - New Meeting Session Request for IETF 99 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, 30 May 2017 16:03:23 -0000 --001a114412ca4597ac0550bff1fb Content-Type: text/plain; charset="UTF-8" Hi Steve, There is no deadline for answering, unless you are going to be there in person and need to register for the IETF. The preliminary IETF agenda is scheduled to be published 6/16. Best, TEssa On Tue, May 16, 2017 at 7:49 AM, Steve Lhomme wrote: > I might go in person but that's still up in the air. > > When do we need an answer ? And When do we know which date the CELLAR > meeting would be on ? > > Thanks > > 2017-04-27 12:40 GMT+02:00 Reto Kromer : > > Please count me as remote attendee. Thank you! Reto > > > > > > Steve Lhomme wrote: > > > >>I'll probably do that as well. > >> > >>2017-04-26 21:43 GMT+02:00 Peter B. : > >>> I'd be participating remotely, too :D > >>> > >>> > >>> Cheers, > >>> Peter > >>> > >>> On 04/26/2017 04:08 PM, Ashley Blewer wrote: > >>>> Fortunately for everyone on the list interested in this meeting but > >>can't > >>>> hop over to Prague, IETF does an excellent job of ensuring remote > >>>> participation! > >>>> > >>>> Ashley > >>>> > >>> > >>> _______________________________________________ > >>> Cellar mailing list > >>> Cellar@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cellar > >> > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > -- > Steve Lhomme > Matroska association Chairman > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a114412ca4597ac0550bff1fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Steve,

There is no deadline for answ= ering, unless you are going to be there in person and need to register for = the IETF.=C2=A0 The preliminary IETF agenda is scheduled to be published 6/= 16.

Best,
TEssa

On Tue, May 16, 2017 at 7:49 AM, Steve Lh= omme <slhomme@matroska.org> wrote:
I might go in person but that's still up in the air.

When do we need an answer ? And When do we know which date the CELLAR
meeting would be on ?

Thanks

2017-04-27 12:40 GMT+02:00 Reto Kromer <lists@reto.ch>:
> Please count me as remote attendee. Thank you! Reto
>
>
> Steve Lhomme wrote:
>
>>I'll probably do that as well.
>>
>>2017-04-26 21:43 GMT+02:00 Peter B. <pb@das-werkstatt.com>:
>>> I'd be participating remotely, too :D
>>>
>>>
>>> Cheers,
>>> Peter
>>>
>>> On 04/26/2017 04:08 PM, Ashley Blewer wrote:
>>>> Fortunately for everyone on the list interested in this me= eting but
>>can't
>>>> hop over to Prague, IETF does an excellent job of ensuring= remote
>>>> participation!
>>>>
>>>> Ashley
>>>>
>>>
>>> _______________________________________________
>>> Cellar mailing list
>>> Cellar@ietf.org
>>> https://www.ietf.org/mailman/listinf= o/cellar
>>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar



--
Steve Lhomme
Matroska association Chairman

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

--001a114412ca4597ac0550bff1fb--