From mo@bunkus.online Sat Apr 4 07:15:08 2020 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 E27A83A0D73 for ; Sat, 4 Apr 2020 07:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499, FROM_SUSPICIOUS_NTLD_FP=0.219, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bunkus.online 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 fACjRo9T0LV4 for ; Sat, 4 Apr 2020 07:15:06 -0700 (PDT) Received: from liselle.localdomain (liselle.bunkus.org [144.76.140.85]) (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 961BB3A0D87 for ; Sat, 4 Apr 2020 07:15:03 -0700 (PDT) Received: from adara.bunkus.org (unknown [IPv6:2a01:4f8:200:1d01::feed:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by liselle.localdomain (Postfix) with ESMTPS id 4CFC63C81510 for ; Sat, 4 Apr 2020 16:15:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.online; s=mail2019123101; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=Ns7nfTF1SZE9eGBQRbfaKFZF3EyT36s/dhfF4PcZwSY=; b=QfGhqMj+YDIR+OA9TTDqGAVygP1E8ONlUC5vek/pjQjjQ5ykI2cR8NS6fi7nhihPZ1LvOYSHsJJuDX6PrvehjNizIFA/F5rfgEDkKLOLsY1BeXzpnI8oYO3OscpEcd3ixYgNywZv7PhW3S7Os4b+KXOBzJULJIxI0DAJ2uJTKrCjMHIyj2XKRokFcWizUBgnH2m32K12Cg+cmoz9pj1IpumeF47xKj0nWQbpIz31S2JzoFUiuxjX0b54hrDEM1uLT0bMix2Hu1VaQToFbHaCU0y8k8staRHtRMx3BODJOb/BdFmSaIKANPlr5FjGiIHyyOmJhM1FXVug8pDNpB7HYA==; Received: from liselle.bunkus.org ([2a01:4f8:200:144f::105:1]:58172) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1jKjZT-0002pf-0P; Sat, 04 Apr 2020 16:14:51 +0200 Received: from sweet-chili.int.bunkus.org (unknown [10.55.5.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by liselle.bunkus.org (Postfix) with ESMTPS id F0E1737C1383; Sat, 4 Apr 2020 16:14:50 +0200 (CEST) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.int.bunkus.org (Postfix) with ESMTP id 9833124145EE; Sat, 4 Apr 2020 16:14:50 +0200 (CEST) User-agent: mu4e 1.2.0; emacs 26.3 From: Moritz Bunkus To: help Questions , Cellar list Date: Sat, 04 Apr 2020 16:14:50 +0200 Message-ID: <878sjbban9.fsf@bunkus.online> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] MKVToolNix v45.0.0 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2020 14:22:34 -0000 Hello dear people, I sincerely hope you're all healthy or at least on the way there. I'm fine, and having some more time on my hands I was able to get more done wrt. MKVToolNix. So this release is a bit bigger than the previous ones. Nothing's changed for package managers. Here are the usual links: =E2=80=A6to the source code: https://mkvtoolnix.download/source.html =E2=80=A6to the binaries: https://mkvtoolnix.download/downloads.html The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available of the course of the next couple of hours. Here are the NEWS since the previous release: ------------------------------------------------------------ # Version 45.0.0 "Heaven in Pennies" 2020-04-04 ## New features and enhancements * mkvmerge: mkvmerge has never supported appending & splitting FLAC audio tracks. mkvmerge will now emit error messages when the user attempts eith= er instead of continuing and creating invalid FLAC tracks. * MKVToolNix GUI: added an option in the preferences to turn on eliding text on tab headers. If enabled, tab names will be shortened so that all tab headers fit into the window's width. Implements #2768. * MKVToolNix GUI: added an option in the preferences to disable all tooltip= s. * MKVToolNix GUI: Windows: debug output sent via Qt's to Windows' debugging facility will use a more verbose message format including the application name, making it easier to filter for in SysInternal's "Debug View" utilit= y. * MKVToolNix GUI: multiplexer: if the file identification fails due to a JS= ON parser error, the output generated by `mkvmerge` will be output via Qt's debugging facility (viewable with SysInternal's "Debug View" utility on Windows; on other systems it's output on `STDERR`) allowing insight into what's gone wrong. * MKVToolNix GUI: multiplexer: if an error occurs during file identificatio= n, the name of the processed file will be mentioned in the error message. * MKVToolNix GUI: multiplexer: if an error occurs during identification of multiple files, the GUI will ask the user whether to continue or abort the identification process. Implements #2778. * MKVToolNix GUI: job queue: added an option in the preferences for removing completed jobs when exiting the program depending on their status. Implements #2769. ## Bug fixes * mkvmerge: H.265/HEVC packetizer: fixed changing the NALU size length, it = was using the wrong offset into the `hevcC` structure. * mkvmerge: MP4 reader: fixed calculating the duration of video tracks that only contain a single frame. Fixes #2747. * mkvmerge: MP4 reader: if there's no frame offset table (`ctts` atom) pres= ent for H.265/HEVC video tracks, mkvmerge will determine the timestamp order itself instead of relying on the timestamps in the MP4 being in the presentation order required by Matroska. Fixes #2777. * mkvpropedit: Windows: mkvpropedit wasn't caching when reading the file to modify, slowing down operations such as adding track statistics tags considerably. Fixes #2761. * MKVToolNix GUI: multiplexer: when using the title as part of the destinat= ion file name (both automatically as well as using the "copy title to destination file name" function) all characters that aren't valid in a fi= le name are replaced by hyphens. * MKVToolNix GUI: multiplexer: the "copy title to destination file name" function was broken when the "make file name unique" option in the preferences was disabled. In that case the file base name was removed regardless of what the title was set to at the time. * MKVToolNix GUI: multiplexer: when using the "show command line" menu opti= on on Windows the path to the `mkvmerge` executable was shown with forward slashes instead of backslashes. This is a purely cosmetic fix as Windows supports both forward and backward slashes. * MKVToolNix GUI: multiplexer: when adding Blu-ray playlists the GUI used to only look for the English version of the disc library information (title & cover images). Now the GUI will present all disc library entries in the "select playlist to add" dialog & let the user chose which one to use (if any). Fixes #2765. * MKVToolNix GUI: multiplexer, info tool: fixed the "warn before overwritin= g" check wrt. jobs creating the same file. Fixes #2758. ------------------------------------------------------------ So try to have some fun, especially in these trying times. mosu From nobody Sun Apr 5 00:38:21 2020 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 F00C73A15ED for ; Sun, 5 Apr 2020 00:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=CNmEKBBQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zQEBH5Dq 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 E4YZmTk8Xz8q for ; Sun, 5 Apr 2020 00:38:13 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024CD3A15EB for ; Sun, 5 Apr 2020 00:38:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 768F85C01A8 for ; Sun, 5 Apr 2020 03:32:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 05 Apr 2020 03:32:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=xuVV8jjWt9nCrp80YAvfKrdHp4EhC6LaZnd+g6txN30=; b=CNmEKBBQ V8tX1e/Xve3NXvte7TZdR+c9c1nhkuJ9x7q/c8iZcq17l67XkqWoYgEUPznNWlLY kIzb4HRO7UidWzUG0sft4GF9DHUAKJ6//Ds8Y02MBUMbxuAQ8DNrW7v04c+ytvfQ 43qB+8WRbdIqIJv6eYXSp7+UuZKKU5WMEkNACO7SME0+/Eos7O1Mgnpvdr66VcI7 epnoJl0x1aTcBYIjGpF7WPNpkRBDw2qaPRg69gjsqJAwfSqkQiVY6mi+q0pSbqti nzoaE2tGXL2Z0D8hHE/jAlCbfyj6iiF4JR9WpVbnHtILotYO8qnTVuZLILxTVvwh 9MEik6UTNqJfXA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=xuVV8jjWt9nCrp80YAvfKrdHp4EhC 6LaZnd+g6txN30=; b=zQEBH5Dq2rtdK6Y8MMgkr/h1p2wgHGscBcgnKs8sn2AiN eM3lkYmu/zNLXdE8FaPgdncTNLfE5Te2UJYSFJyjDksAjv0by9gNb4PEbV5Kb8rj YutelcLcVZACQJtuOdhGz0blHCPeaVYl1jVu4aPFcPlqZu458WuWNyehaoPP+QSk 5YwrDSWszGtj27DqlDWLwtxLnNm+hvO1nzoIfwUFw9pkZ0H0Ee+V9WS6XCaZxnpn /saMZoi6WPVJA8KCbOwmvufxdE70uFiuj8a5AFS72S2BqKjSfE7ByGxfvQzbtsAj zjnzzFvL4OZzrxQu/UhQyyNsni6qIOQBYVeCXqcRw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppeehvddrudejjedrhedrheenucevlhhushhtvghrufhi iigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmh hnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [52.177.5.5]) by mail.messagingengine.com (Postfix) with ESMTPA id 3B062306D1E1 for ; Sun, 5 Apr 2020 03:32:21 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============4490970181261769531==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200405073221.3B062306D1E1@mailuser.nyi.internal> Date: Sun, 5 Apr 2020 03:32:21 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2020 07:38:15 -0000 --===============4490970181261769531== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #365 Add a flag for BDR, WB, BD, DVD, TV, HDTV, source of video file. (= 1 by robUx4) https://github.com/cellar-wg/matroska-specification/issues/365 [clarifi= cations] [spec_tags]=20 Pull requests ------------- * cellar-wg/matroska-specification (+2/-2/=F0=9F=92=AC9) 2 pull requests submitted: - update markdown tables (by dericed) https://github.com/cellar-wg/matroska-specification/pull/368=20 - update document titles (by dericed) https://github.com/cellar-wg/matroska-specification/pull/367=20 6 pull requests received 9 new comments: - #334 give an empty default to Targets (2 by dericed, mcr) https://github.com/cellar-wg/matroska-specification/pull/334 [bug] [cla= rifications]=20 - #318 add a ChapterContentType to mark chapters with a type of content (= 1 by mcr) https://github.com/cellar-wg/matroska-specification/pull/318 [enhanceme= nt] [format addition] [spec_main]=20 - #249 Add avs2 codec mapping (1 by mcr) https://github.com/cellar-wg/matroska-specification/pull/249 [codec map= ping] [enhancement] [new_document] [spec_codecs]=20 - #158 Adjust definition of "forced" and "default" flags to better reflec= t usage (1 by mcr) https://github.com/cellar-wg/matroska-specification/pull/158 [clarifica= tions] [spec_main]=20 - #115 info on storing/using font files in attachments (3 by mcr) https://github.com/cellar-wg/matroska-specification/pull/115 [clarifica= tions] [spec_main]=20 - #112 add T_QUICKTIME codec mapping (1 by mcr) https://github.com/cellar-wg/matroska-specification/pull/112 [codec map= ping] [new_document] [spec_codecs]=20 2 pull requests merged: - update document titles https://github.com/cellar-wg/matroska-specification/pull/367 [spec_code= cs] [spec_main] [spec_tags]=20 - False edition flag default https://github.com/cellar-wg/matroska-specification/pull/340 [clarifica= tions] [enhancement] [spec_main]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============4490970181261769531== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday April 05, 2020

Events without label "editorial"

Issues

cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

Pull requests

cellar-wg/matroska-specification (+2/-2/=F0=9F=92=AC9)

2 pull requests submitted:

6 pull requests received 9 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============4490970181261769531==-- From nobody Sun Apr 12 00:38:16 2020 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 254FB3A1782 for ; Sun, 12 Apr 2020 00:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=16EI6YPr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G6V7v2PC 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 RWzSbfHytRnG for ; Sun, 12 Apr 2020 00:38:11 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6F43A1781 for ; Sun, 12 Apr 2020 00:38:11 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6B8915C00DE for ; Sun, 12 Apr 2020 03:32:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 12 Apr 2020 03:32:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=XYPovBp6w2p4m8lMv3Ghsqs1NnABDsW1uRrfQzFvllo=; b=16EI6YPr ST5gAV16v+yL55LyIXZJcnMdeHCHBkMB6Bw88h3qU+I57Oh9ur577f5pL3hfHHuU SU2hAdxqNDdR07kUAWB/IpLjst48v0Jy3wP9XnU7v/SPUyOBUMoue7rWbyNjBFzW sdFvNEVttkf/czR6DkNh+gimU5elu6H0Gy5lSwZBPLWtW9kUryDW7vwXEpjfBBgG 7kT+tVyulXA28K1Cv5+15u2hUFnawJFR+WIEw2/byv3X8LXD+YYapK+33yXyZWis OMCTM3+WvK0eq4GnCg6syrBk8WJYlh1cHE0hDDfT5aTqgGBfqor8D3govUEo6Opz 1kYq3tjvS6t9+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=XYPovBp6w2p4m8lMv3Ghsqs1NnABD sW1uRrfQzFvllo=; b=G6V7v2PCIp0ZdYejBf4UEdGQeUsGesqt1SYReiqXlOp8v VfkNK47K8Jxa9Lzn3sIEHcgtincIMgSjlF9sAioZcQNmsXwvEGMC10f+sKOWip09 0aFuatK7s1a2Gr6wADphzjUN0Lk/Zpj2uNSiu/0k1r8d8LW3jS+Onray1BmO6Z87 W3OUlj30PE3vgYMM/BYerIJXxX4W4D1AV+DkGTiFlgNwC7O8F2P+w0Mh5lKqR2gq Mr0mdQbPbyv6mXa+m0P5vpY/T4Vkjn5NdwNZeskgbyTE3/ncjAwaPWBE0VlHBFQy GCu3n3plEd5743h+5nQWeyWJB1FZrhP7USAgz+ViQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvdeigddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppeehuddrudeguddrudejjedrhedvnecuvehluhhsthgv rhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplh ihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az115.internal.cloudapp.net (unknown [51.141.177.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 143BE3280067 for ; Sun, 12 Apr 2020 03:32:46 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============8762945154001855228==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200412073246.143BE3280067@mailuser.nyi.internal> Date: Sun, 12 Apr 2020 03:32:46 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 12 Apr 2020 07:38:13 -0000 --===============8762945154001855228== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Pull requests ------------- * cellar-wg/matroska-specification (+0/-1/=F0=9F=92=AC2) 1 pull requests received 2 new comments: - #318 add a ChapterContentType to mark chapters with a type of content (= 2 by hubblec4, robUx4) https://github.com/cellar-wg/matroska-specification/pull/318 [enhanceme= nt] [format addition] [new_document] [spec_main] [webm] [wontfix]=20 1 pull requests merged: - update markdown tables https://github.com/cellar-wg/matroska-specification/pull/368=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============8762945154001855228== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday April 12, 2020

Events without label "editorial"

Pull requests

cellar-wg/matroska-specification (+0/-1/=F0=9F=92=AC2)

1 pull requests received 2 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============8762945154001855228==-- From nobody Fri Apr 17 10:12:21 2020 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 B243B3A091E; Fri, 17 Apr 2020 10:12:11 -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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <158714353166.17463.16500991967496041153@ietfa.amsl.com> Date: Fri, 17 Apr 2020 10:12:11 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-tags-04.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 17:12:12 -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 WG of the IETF. Title : Matroska Media Container Tag Specifications Authors : Steve Lhomme Moritz Bunkus Dave Rice Filename : draft-ietf-cellar-tags-04.txt Pages : 22 Date : 2020-04-17 Abstract: This document defines the Matroska tags, namely the tag names and their respective semantic meaning. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-tags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-tags-04 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-tags-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-tags-04 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 Fri Apr 17 10:15:11 2020 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 C51633A091E; Fri, 17 Apr 2020 10:15:08 -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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <158714370872.7452.8820299663476399395@ietfa.amsl.com> Date: Fri, 17 Apr 2020 10:15:08 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-codec-04.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 17:15:09 -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 WG of the IETF. Title : Matroska Media Container Codec Specifications Authors : Steve Lhomme Moritz Bunkus Dave Rice Filename : draft-ietf-cellar-codec-04.txt Pages : 50 Date : 2020-04-17 Abstract: This document defines the Matroska codec mappings, including the codec ID, layout of data in a "Block Element" and in an optional "CodecPrivate Element". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-codec-04 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-codec-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-codec-04 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 Fri Apr 17 10:41:28 2020 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 6D1843A0970; Fri, 17 Apr 2020 10:41:25 -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.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <158714528535.12721.16419581561880452987@ietfa.amsl.com> Date: Fri, 17 Apr 2020 10:41:25 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-matroska-05.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 17:41:25 -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 WG of the IETF. Title : Matroska Media Container Format Specifications Authors : Steve Lhomme Moritz Bunkus Dave Rice Filename : draft-ietf-cellar-matroska-05.txt Pages : 170 Date : 2020-04-17 Abstract: This document defines the Matroska audiovisual container, including definitions of its structural elements, as well as its terminology, vocabulary, and application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-matroska-05 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-matroska-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-matroska-05 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 Sun Apr 19 00:38:20 2020 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 0574B3A00D2 for ; Sun, 19 Apr 2020 00:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=mnot.net header.b=yLJr9qKt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nKDcc1qQ 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 XHh7BPwcMpMm for ; Sun, 19 Apr 2020 00:38:17 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6223A00C9 for ; Sun, 19 Apr 2020 00:38:17 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 79D29602 for ; Sun, 19 Apr 2020 03:32:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 19 Apr 2020 03:32:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=NQNnKaxviKM5OoTKAkBkPIdbsfwAGKijbRafTeWEoWk=; b=yLJr9qKt CTX0VgUH1p6c1eHck2HGzRDnUJQvGerwOcFI+OhEjBOybsR83PXUXQiCB+VMzz/b bjOq5YL3wAStmzQr+MryH1kFBYCQmOnkEHhSvgNCp1NDZ1JYv6ubqKxp7PrZFlwe UADt9TooGud6OccVbLVUOJxseg7MR37/RPjYc8iZhuFNn8QVbPponuBBAbFBnQxn J20qYOp9j812MG7e61bVF+ODhtUZIl1m8JoOGmH85twRCB/nNPr6FpELYhuZMEkX WeDqv40TKmPFWLjmgkR1nci10bQn/vEFqhQHYivGy/VmSWZZpLxqIqOzRNKUahx+ Hw0pD61LdT7RhQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=NQNnKaxviKM5OoTKAkBkPIdbsfwAG KijbRafTeWEoWk=; b=nKDcc1qQmwXPfa2kF5kkyOWcRrm26zyyzL/WXODDZaZ4T xZrYAMLBPmUJAGnrkWmSd3sLQy2B2O37iqhc9WHoa1bWKM7mMq+eF2UklqmDQz2o StUVcqbBxsqap57OyrwhY5R3k52vHYjY1up7a4EuagiaUXfViB6m/Qm/HrEUGZFG QtzrPDpn9DcoDXH1L+XVFSy1PoLRpty0uQpTKYsLJUD009mvfW3oYJCdDhy8mZzw 2Lfy3VAeI2B1vTf/v6xmhWK8f944IW6J0j2x8mUt5IjW6pXhovwFTr3h0ot4x3X3 PJTXNSDNQA5x3v7/Uk1SgLpbiFIeqHnV4TrhF6/Ng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgedtgdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphephedvrddujeejrddujedrvdegvdenucevlhhushht vghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az89.internal.cloudapp.net (unknown [52.177.17.242]) by mail.messagingengine.com (Postfix) with ESMTPA id 039D33280059 for ; Sun, 19 Apr 2020 03:32:28 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3056896252056173075==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200419073228.039D33280059@mailuser.nyi.internal> Date: Sun, 19 Apr 2020 03:32:28 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 19 Apr 2020 07:38:19 -0000 --===============3056896252056173075== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+1/-0/=F0=9F=92=AC2) 1 issues created: - Mark which elements (UIDs) need to be preserved when remuxing (by robUx= 4) https://github.com/cellar-wg/matroska-specification/issues/370 [clarifi= cations] [spec_main]=20 1 issues received 2 new comments: - #316 Will codec spec update future? (2 by liyuxi, robUx4) https://github.com/cellar-wg/matroska-specification/issues/316 [spec_co= decs]=20 Pull requests ------------- * cellar-wg/matroska-specification (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - bump draft versions (by dericed) https://github.com/cellar-wg/matroska-specification/pull/369=20 1 pull requests merged: - bump draft versions https://github.com/cellar-wg/matroska-specification/pull/369=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============3056896252056173075== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday April 19, 2020

Events without label "editorial"

Issues

cellar-wg/matroska-specification (+1/-0/=F0=9F=92=AC2)

1 issues created:

1 issues received 2 new comments:

Pull requests

cellar-wg/matroska-specification (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============3056896252056173075==-- From nobody Sun Apr 26 00:38:13 2020 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 C6DA43A0B8E for ; Sun, 26 Apr 2020 00:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=mnot.net header.b=NYjBWBd6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zPtrQoDC 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 yIGDBGlNlmjv for ; Sun, 26 Apr 2020 00:38:03 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53DC13A0C79 for ; Sun, 26 Apr 2020 00:38:03 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 205B25C0312 for ; Sun, 26 Apr 2020 03:32:51 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 26 Apr 2020 03:32:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=3/+totauntPz3rS8ARQ1xua2EI788CxCNQbdYbZ16U4=; b=NYjBWBd6 g/pd+z+Tk3MlTY6cHNlTIBQd5NGws7kgSTdRmO72LqaI1ezeVU8OSwV56yUsKBw8 lOVPEBzj37sXvqBLk93f40WVJthygrnx4aD7ATYVjzQRzBK4Vd3f2UzDnOy1mXjj LSBPvabtbOIuMcm7H8jR4Q9qQNlcnG0LV/P0erGFL5VAoVOr7VAsyy03rRJsy996 EGLPHlAZLETLQyJrXbWVohnrobd52i22KyRn616ym7tm1QYZiQvo8dmPlIx7L8+1 31ozGUpC7hdbtLP5dM9/0/123g4m1FlYH/+coIdwTnFAc7Mcdin2X1FWrs2u3U2n gCzZcVlW0ro81w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=3/+totauntPz3rS8ARQ1xua2EI788 CxCNQbdYbZ16U4=; b=zPtrQoDC7XZ1hyMGP1JeWH8hDDwlsnXoEqEpra/E9QJm+ mG/FV8NtlQBHK+yUj2eBvPF1mKr0Ajpy8RhhWDJn/psAE2MHq1p+IEZUsaWXJqYV K/NwHo0VWvo6mbs+oy3EoEqMS5XlrJljKFjmKtAPhr6PF5PntZiqKFI3P3ugv7ud Wb4qqkPrVoD8mWDfwXEoY8Ll8DAfwfQc6SHankMmr7X8gm02ZgahNLTE6MoJ6JIs HlC8CrQQa2ECLCOsMZcQWbXmKMplO5fHJelzD5NCOGwXJPX6pT81BYs+JBUXnVS4 9Q4X4CcbDyvw6t3ymfUf0crfrQzPFozZx+fChSCIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheeigddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppedufedrledtrddvvdeirddvtddvnecuvehluhhsthgv rhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplh ihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az86.internal.cloudapp.net (unknown [13.90.226.202]) by mail.messagingengine.com (Postfix) with ESMTPA id E05BB3065E0F for ; Sun, 26 Apr 2020 03:32:50 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============0013185823691563420==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200426073250.E05BB3065E0F@mailuser.nyi.internal> Date: Sun, 26 Apr 2020 03:32:50 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 07:38:06 -0000 --===============0013185823691563420== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+1/-1/=F0=9F=92=AC3) 1 issues created: - duplicate id used in BlockAdditionMapping (by dericed) https://github.com/cellar-wg/matroska-specification/issues/371=20 3 issues received 3 new comments: - #371 duplicate id used in BlockAdditionMapping (1 by hubblec4) https://github.com/cellar-wg/matroska-specification/issues/371=20 - #370 Mark which elements (UIDs) need to be preserved when remuxing (1 b= y hubblec4) https://github.com/cellar-wg/matroska-specification/issues/370 [clarifi= cations] [spec_main]=20 - #363 ChapterThumbnail (1 by hubblec4) https://github.com/cellar-wg/matroska-specification/issues/363 [format = addition] [spec_main]=20 1 issues closed: - duplicate id used in BlockAdditionMapping https://github.com/cellar-wg/= matroska-specification/issues/371=20 Pull requests ------------- * cellar-wg/matroska-specification (+1/-1/=F0=9F=92=AC1) 1 pull requests submitted: - fix duplicate ID between BlockAddIDType and BlockAddIDExtraData (by rob= Ux4) https://github.com/cellar-wg/matroska-specification/pull/372 [XML Schem= a] [bug]=20 1 pull requests received 1 new comments: - #318 add a ChapterContentType to mark chapters with a type of content (= 1 by hubblec4) https://github.com/cellar-wg/matroska-specification/pull/318 [enhanceme= nt] [format addition] [new_document] [spec_main] [webm] [wontfix]=20 1 pull requests merged: - fix duplicate ID between BlockAddIDType and BlockAddIDExtraData https://github.com/cellar-wg/matroska-specification/pull/372 [XML Schem= a] [bug]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============0013185823691563420== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday April 26, 2020

Events without label "editorial"

Issues

cellar-wg/matroska-specification (+1/-1/=F0=9F=92=AC3)

1 issues created:

3 issues received 3 new comments:

1 issues closed:

Pull requests

cellar-wg/matroska-specification (+1/-1/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

Repositories tracked by this digest:

 --===============0013185823691563420==-- From sbshepherd@ChurchofJesusChrist.org Wed Apr 22 06:48:35 2020 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 3FCBF3A0CAF for ; Wed, 22 Apr 2020 06:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=churchofjesuschrist.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JraFpO-3PsJw for ; Wed, 22 Apr 2020 06:48:30 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2076.outbound.protection.outlook.com [40.107.94.76]) (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 C45713A0CAE for ; Wed, 22 Apr 2020 06:48:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xy4Vjn4bN7n8iUMZ2VzAPPjOP07GJ1wreRm2C+9ocE5EQUUP0xPDQXyK7Y38RVT7a2KdePxFq9nSb1dGhw7o01k28r44bD9CqymZnLOj5PvGtIRrW2u/6scuq7YIP3fOgJcIz991BWybwAJ9ZhqQhow0xj9D+iVdbs9p93XDpEuCyXnS5Q7i8cyzk7jGbxymV2d0SxbLeVbQcLBoYjptKgeuNCV6D/cWw+GNuDlZ4HW1QF1zIH/TDRYgurKJT8yt8uIWi8+AmXnBPr1uOt8BlXsNOtfEM0TDensanfZ/QeQcMJc366phae65uS0pBZ1S30+NLWjf3RoXVoKwuPGIlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z9NxpVWBAE2fpC5R/ZZpsckaRVcpyGopaXsj913oYhI=; b=NOX1yFsk7kQTl6xrYf3XP5Kkzx0SzMEpuffmdTMl9hZvLclB0NYd3EF0Y/hnuIcoiMLcGWdqaIhFcSJoMPqk+QxWrtv10eFZYPE27peeEpfgW/Pm8YwVXN92pjqyvZ5fmTLib8u9J97PHk2qX3JzFJ3P5X/j70e9b3+jCfTmgsACvHnFpk2VQK7DhsWkbNsLEb1cg8ugNiaas246KAcju1NGPKhh7SdN/TJw+ziqz3RxmbQoD5OGVSYO8nIuwIE4ccezhZHn0XjRXNcpt3kZokjrQX50XeRRXQZMDAQ/7k4/yQleTZ2U5d2bRC/1NIlr/05aAdGg/ydpPylRMCO2Bw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=churchofjesuschrist.org; dmarc=pass action=none header.from=churchofjesuschrist.org; dkim=pass header.d=churchofjesuschrist.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ChurchofJesusChrist.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z9NxpVWBAE2fpC5R/ZZpsckaRVcpyGopaXsj913oYhI=; b=B8Xa8xNVg36jLttmquM79SFLkzn1M92JvqjtczV1oxeYeY0SLK5LvdxPKH8EJ4YyVTkYol2Jzur30rOVTLTXFgyHIhDroqSKG/pwrQIAvcEDDNwsnwzpDOb8PQTOg/6lThM6fIyoWsMO/Cmas84zwz+rkxXHepuighFpakhHxIg= Received: from CY4PR04MB0729.namprd04.prod.outlook.com (2603:10b6:903:e2::22) by CY4PR04MB0342.namprd04.prod.outlook.com (2603:10b6:903:3f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Wed, 22 Apr 2020 13:48:29 +0000 Received: from CY4PR04MB0729.namprd04.prod.outlook.com ([fe80::dc2d:fcf0:aed9:825e]) by CY4PR04MB0729.namprd04.prod.outlook.com ([fe80::dc2d:fcf0:aed9:825e%11]) with mapi id 15.20.2921.030; Wed, 22 Apr 2020 13:48:29 +0000 From: Scott Shepherd To: "cellar@ietf.org" Thread-Topic: Matroska support for closed captions? Thread-Index: AdYYq3tJ1eobUzwuRSCicAtNBb4EZQ== Date: Wed, 22 Apr 2020 13:48:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_03ef5274-90b8-4b3f-8a76-b4c36a43e904_ActionId=af88db4a-4b9b-45a1-9a50-0000bd9bbc53; MSIP_Label_03ef5274-90b8-4b3f-8a76-b4c36a43e904_ContentBits=0; MSIP_Label_03ef5274-90b8-4b3f-8a76-b4c36a43e904_Enabled=true; MSIP_Label_03ef5274-90b8-4b3f-8a76-b4c36a43e904_Method=Standard; MSIP_Label_03ef5274-90b8-4b3f-8a76-b4c36a43e904_Name=Not Protected_2; MSIP_Label_03ef5274-90b8-4b3f-8a76-b4c36a43e904_SetDate=2020-04-22T13:39:14Z; MSIP_Label_03ef5274-90b8-4b3f-8a76-b4c36a43e904_SiteId=61e6eeb3-5fd7-4aaa-ae3c-61e8deb09b79; authentication-results: spf=none (sender IP is ) smtp.mailfrom=sbshepherd@ChurchofJesusChrist.org; x-originating-ip: [76.23.36.182] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d1189d89-bd96-4e46-35e9-08d7e6c3d6ce x-ms-traffictypediagnostic: CY4PR04MB0342: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03818C953D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR04MB0729.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(39850400004)(136003)(366004)(396003)(346002)(2906002)(9686003)(66446008)(81156014)(55016002)(52536014)(6916009)(71200400001)(6506007)(64756008)(76116006)(66946007)(66476007)(86362001)(66556008)(8676002)(33656002)(26005)(316002)(786003)(186003)(7696005)(8936002)(478600001)(5660300002)(85282002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ChurchofJesusChrist.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: v2K/0pl3BI2dClPWgi/PY+BwzqnlZ4thvv5eAriFSkb0Pe1LBzbfJaq4SJbnF1OOYNcut9JGX83IUaE054AeTesXgNlfprIoQOTgrinUR9fVATpDjh7MSz2P3v1UinrkzhWR+lqBQLpbzDe6n6MswB92eoiIAxz+Z+Ux5lu2EHl+G+L+j/3BaIJuQvzpz6PYpHcaK5XwLja4p1SlqoXXslR77x3OrJX7a1Ic7phxFi/V3ee3cCwHC04SR8d6kNJ9fvx56eCjYflserib53w7RgLdxP28/J376V156kYqHccMk7LSwhHniL+CSGdp6sufc1TpEm+rV4e7M19lB5KKWcK2UGnky+0RN7LCTqWsP35y9YYCMXUkIR4TpPQxEXRYjw2GpxdOptS3l3RnNDZSbc07n5kz40BeDgphgBGuvqWfhB/sz4Ig9lbyPgF74DraDKLldapWmSG8UQpBwdvwXQmH5m5uKBYhrsMVSH4unqSRwhyq8o+JKj3cxHYRE+yo x-ms-exchange-antispam-messagedata: paomSIuvIa4slUTcNXh/SOjjnw/RXTAbZNAs6rnNV9ocF0G7seX6jfGba/AKXdoPdTYtCWPZ+ZPkySLT8nhATe4HYnxGQdspDvTfk7b5DglJznEnoau4VJb5/qEz5AHk66yf2142Ez7OlrbzICk4pw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR04MB072989A9F039E5DFCBBF1E40C9D20CY4PR04MB0729namp_" MIME-Version: 1.0 X-OriginatorOrg: churchofjesuschrist.org X-MS-Exchange-CrossTenant-Network-Message-Id: d1189d89-bd96-4e46-35e9-08d7e6c3d6ce X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2020 13:48:29.1215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 61e6eeb3-5fd7-4aaa-ae3c-61e8deb09b79 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5w9rrNPazFFOO9DJaMP3Tqcju1lcSJgK6XSa6F3X7u9GoCvx3DSdmqB4AwSPSXPV0eHtsx22rX23IGR11Ej2exr8B/ENot4oZ2NuH6E+xG98XwHikzSYwayhluGVpSY7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB0342 Archived-At: X-Mailman-Approved-At: Mon, 27 Apr 2020 08:40:01 -0700 Subject: [Cellar] Matroska support for closed captions? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 22 Apr 2020 13:50:59 -0000 --_000_CY4PR04MB072989A9F039E5DFCBBF1E40C9D20CY4PR04MB0729namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Are there any plans to expand Matroska capability to contain additional str= eam types such as timecode and closed captions? We have some .MXF files (mostly JPEG2000) and are toying with the idea of m= igrating them to FFV1/.MKV, but currently .MKV can't contain timecode or cl= osed caption streams. While I can't say I fully understand the need for mul= tiple timecode streams (often there are 3 streams in the .MXF), we'd defini= tely be losing data where closed captions exist. I know that .MKV can hold "attachments," but attachments don't seem like th= e right solution here. I also know .MKV can hold subtitles, but what we're = seeing in these .MXF files is EIA-608 and EIA-708 closed captions that fail= to carry over to .MKV. Ideally, we'd use ffmpeg to transcode JPEG2000/.MXF to FFV1/.MKV and map al= l existing streams. Is that possible currently? If not, is it on the roadma= p or can it be put on the roadmap? This is one of the main obstacles keepin= g us from embracing the FFV1/.MKV combination. Scott Shepherd --_000_CY4PR04MB072989A9F039E5DFCBBF1E40C9D20CY4PR04MB0729namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Are there any plans to expand= Matroska capability to contain additional stream types such as timecode an= d closed captions?

 

We have some .MXF files (most= ly JPEG2000) and are toying with the idea of migrating them to FFV1/.MKV, b= ut currently .MKV can't contain timecode or closed caption streams. While I= can’t say I fully understand the need for multiple timecode streams (often there are 3 streams in the .MXF)= , we’d definitely be losing data where closed captions exist.

 

I know that .MKV can hold &qu= ot;attachments," but attachments don't seem like the right solution he= re. I also know .MKV can hold subtitles, but what we’re seeing in the= se .MXF files is EIA-608 and EIA-708 closed captions that fail to carry over to .MKV.

 

Ideally, we'd use ffmpeg to t= ranscode JPEG2000/.MXF to FFV1/.MKV and map all existing streams. Is that p= ossible currently? If not, is it on the roadmap or can it be put on the roa= dmap? This is one of the main obstacles keeping us from embracing the FFV1/.MKV combination.

 

Scott Shepherd

--_000_CY4PR04MB072989A9F039E5DFCBBF1E40C9D20CY4PR04MB0729namp_-- From nobody Mon Apr 27 08:46:42 2020 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 9DEDE3A0D87 for ; Mon, 27 Apr 2020 08:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 rKlnRQA45N5U for ; Mon, 27 Apr 2020 08:46:39 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 231323A0DB8 for ; Mon, 27 Apr 2020 08:46:39 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:44579 helo=[10.0.1.6]) by server172.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jT5xp-004O2g-Vo; Mon, 27 Apr 2020 11:46:38 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Dave Rice In-Reply-To: Date: Mon, 27 Apr 2020 11:46:32 -0400 Cc: "cellar@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <514D57FC-BD77-45E7-846A-046363BED953@dericed.com> References: To: Scott Shepherd X-Mailer: Apple Mail (2.3608.80.23.2.2) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Matroska support for closed captions? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 15:46:41 -0000 Hi Scott, > On Apr 22, 2020, at 9:48 AM, Scott Shepherd = wrote: >=20 > Hi all, > =20 > Are there any plans to expand Matroska capability to contain = additional stream types such as timecode and closed captions? Feel welcome to open a ticket at = https://github.com/cellar-wg/matroska-specification/issues/new. > We have some .MXF files (mostly JPEG2000) and are toying with the idea = of migrating them to FFV1/.MKV, but currently .MKV can't contain = timecode or closed caption streams. While I can=E2=80=99t say I fully = understand the need for multiple timecode streams (often there are 3 = streams in the .MXF), we=E2=80=99d definitely be losing data where = closed captions exist. > =20 > I know that .MKV can hold "attachments," but attachments don't seem = like the right solution here. I also know .MKV can hold subtitles, but = what we=E2=80=99re seeing in these .MXF files is EIA-608 and EIA-708 = closed captions that fail to carry over to .MKV.=20 For EIA-608 and EIA-708 data I suppose, either a new type of Codec = Mapping could be written (and then these would be a new type of subtitle = track) or they could be support as side-data with a = BlockAdditionalMapping as described at = https://www.ietf.org/id/draft-ietf-cellar-codec-04.html#name-block-additio= nal-mapping. I=E2=80=99m unsure which technique the community would = recommend but curious for some discussion on it. [=E2=80=A6] Best Regards, Dave Rice From nobody Mon Apr 27 09:09:08 2020 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 6CDB83A0E6B for ; Mon, 27 Apr 2020 09:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 w78H8TzTE8uh for ; Mon, 27 Apr 2020 09:08:19 -0700 (PDT) Received: from 9.mo68.mail-out.ovh.net (9.mo68.mail-out.ovh.net [46.105.78.111]) (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 AED9C3A0E8B for ; Mon, 27 Apr 2020 09:08:17 -0700 (PDT) Received: from player716.ha.ovh.net (unknown [10.110.208.43]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 84F01163DC6 for ; Mon, 27 Apr 2020 18:08:15 +0200 (CEST) Received: from mediaarea.net (p548F9B78.dip0.t-ipconnect.de [84.143.155.120]) (Authenticated sender: jerome@mediaarea.net) by player716.ha.ovh.net (Postfix) with ESMTPSA id D411E11BB9AD6 for ; Mon, 27 Apr 2020 16:08:14 +0000 (UTC) To: cellar@ietf.org References: <514D57FC-BD77-45E7-846A-046363BED953@dericed.com> From: Jerome Martinez Message-ID: <6e93c666-4414-abab-0f2e-fbe6beaec904@mediaarea.net> Date: Mon, 27 Apr 2020 18:08:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <514D57FC-BD77-45E7-846A-046363BED953@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 247416505558765713 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrheelgdelhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheplfgvrhhomhgvucforghrthhinhgviicuoehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkpheptddrtddrtddrtddpkeegrddugeefrdduheehrdduvddtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeduiedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvthdprhgtphhtthhopegtvghllhgrrhesihgvthhfrdhorhhg Archived-At: Subject: Re: [Cellar] Matroska support for closed captions? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 16:08:29 -0000 On 27/04/2020 17:46, Dave Rice wrote: > > For EIA-608 and EIA-708 data I suppose, either a new type of Codec Mapping could be written (and then these would be a new type of subtitle track) or they could be support as side-data with a BlockAdditionalMapping as described at https://www.ietf.org/id/draft-ietf-cellar-codec-04.html#name-block-additional-mapping. I’m unsure which technique the community would recommend but curious for some discussion on it. As MXF have JPEG-2000, I guess that captions are in a standalone ancillary data (SMPTE ST 291) track. As a first shot, I would not be in favor of BlockAdditionalMapping because the track does not depend on data in another bistream. then there would (at least) 2 choices: - demux of the track from MXF and mux of this track as is; advantage is that we lose no other data inside the ancillary data, disadvantage is that lot of different content (several formats of captions, bar data, VBI, time codes, Acquisition Metadata...) are muxed in the "raw" stream, more difficult for a demuxer/player. - demux of the captions from Ancillary data from MXF; advantage is that we have 1 track per content stream, disadvantage is that we may lose some other "opaque" data from the ancillary data. That said, we could propose both. Jérôme From nobody Mon Apr 27 09:54:02 2020 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 65B303A0F87 for ; Mon, 27 Apr 2020 09:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=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=kernellabs-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWjkCZ6At1YO for ; Mon, 27 Apr 2020 09:53:58 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 AA9C23A0F70 for ; Mon, 27 Apr 2020 09:53:58 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id y26so9722085ioj.2 for ; Mon, 27 Apr 2020 09:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernellabs-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MiMlDzStkYfnGUh7kcyAVwsn9apR6hhaQOiDvP4WbP8=; b=bwSexdHbbv0KszsgcrXBqAIWXGwXrTLsXapH8G4iNW7URnusSWUf7AJrL2xmuVli9B 6VFXF9IDm3rvrzWDX7QRfHoxACZUDCfglbDpC3KB6czD8kWekr894+B9xRO1GTCuBZf1 5t42iSA7aIgc829GfEn4hTot2PRMDqXRAU4uxkhx1VJSTJvfvwT52O1YX9yLRJQWGMne aXdtFT2KI9EhIhQVsowkfTe/FBYneY8TcQfl9eDZgEkmtLaS7+MS6I5bkT1mWYT7g/k1 rsxEQKovO+XboKznbIAqkC22Kl6Iai1ahJn+V5wmqk2l0tbuaQmmT+RDybAFOtteJp2H SCYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MiMlDzStkYfnGUh7kcyAVwsn9apR6hhaQOiDvP4WbP8=; b=hkss+FTxjVSsgf7GSIfuN4Zwx/10wPW+GE7/goIStxu7ocKILG86qblSEFpKu9cF70 stU7ACWapxkhHKcGxJ8QaWcu1rgARxQTdOJiploSYg8k0ti8LMa2qrEYFP2kI7iPb+MV lEJLbs85lJ8flMupTqkZQDYC7WKkODKjU8ilmAzYvvQn/0iJ9cJaV6ZOGhu52YXwFVrd OqME9rBoEsRoPGjoPhCLv69DIy0wBanatu/ws1aVwH0QtGnu4Jd8jV05Q6lf5HI/S+ut Cu8LWBFSpzkXQf6d8mBUQkGKDWkafNhTgHHHxVSHIm6bk9HDQEyfrq2UyI87dXeATVxn ZMUg== X-Gm-Message-State: AGi0PubOaX1OwBSJgFZ8C3vBbhxD53CKUcD2UN1D3RHj8fM7gGPDTiWO u1GtiwW7VciZAAyExkZaOfT98LzydhsLxL+u24XKw9x5 X-Google-Smtp-Source: APiQypLUSNQtUbIzWqHRwIawkf9HUZqdvCee3OimL/zQEaJ/DNKGViMVaTAVgJkvFQ6qWSX4WPUtBHmy5V9xcYsCZw8= X-Received: by 2002:a5e:9b13:: with SMTP id j19mr21508846iok.86.1588006437537; Mon, 27 Apr 2020 09:53:57 -0700 (PDT) MIME-Version: 1.0 References: <514D57FC-BD77-45E7-846A-046363BED953@dericed.com> <6e93c666-4414-abab-0f2e-fbe6beaec904@mediaarea.net> In-Reply-To: <6e93c666-4414-abab-0f2e-fbe6beaec904@mediaarea.net> From: Devin Heitmueller Date: Mon, 27 Apr 2020 12:53:46 -0400 Message-ID: To: Jerome Martinez Cc: cellar@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Matroska support for closed captions? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 16:54:01 -0000 On Mon, Apr 27, 2020 at 12:09 PM Jerome Martinez wro= te: > > On 27/04/2020 17:46, Dave Rice wrote: > > > > For EIA-608 and EIA-708 data I suppose, either a new type of Codec Mapp= ing could be written (and then these would be a new type of subtitle track)= or they could be support as side-data with a BlockAdditionalMapping as des= cribed at https://www.ietf.org/id/draft-ietf-cellar-codec-04.html#name-bloc= k-additional-mapping. I=E2=80=99m unsure which technique the community woul= d recommend but curious for some discussion on it. > > > As MXF have JPEG-2000, I guess that captions are in a standalone > ancillary data (SMPTE ST 291) track. > As a first shot, I would not be in favor of BlockAdditionalMapping > because the track does not depend on data in another bistream. > > then there would (at least) 2 choices: > - demux of the track from MXF and mux of this track as is; advantage is > that we lose no other data inside the ancillary data, disadvantage is > that lot of different content (several formats of captions, bar data, > VBI, time codes, Acquisition Metadata...) are muxed in the "raw" stream, > more difficult for a demuxer/player. > - demux of the captions from Ancillary data from MXF; advantage is that > we have 1 track per content stream, disadvantage is that we may lose > some other "opaque" data from the ancillary data. > > That said, we could propose both. > > J=C3=A9r=C3=B4me For what it's worth, we have the same general problem within ffmpeg. File formats like MXF and MP4 treat captions and timecodes as a separate track, while other formats like TS expect it to be tied to the individual video frames as side data. There's no easy answer, and in particular it's a huge pain when you need to convert from one to the other (e.g. extracting captions from the SEI in an H.264 TS where it gets treated as video frame side data, and creating an MP4 where captions need their own subtitle track). Devin --=20 Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com From nobody Mon Apr 27 10:50:25 2020 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 139EE3A12BD for ; Mon, 27 Apr 2020 10:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SUBJ_ALL_CAPS=0.5, T_SPF_PERMERROR=0.01, 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 Am9CUGNi09Zt for ; Mon, 27 Apr 2020 10:48:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24ED3A12E4 for ; Mon, 27 Apr 2020 10:48:39 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AD7AA38981 for ; Mon, 27 Apr 2020 13:46:45 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6D3054CC for ; Mon, 27 Apr 2020 13:48:37 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] 2020-04-28 VIRTUAL INTERIM AGENDA (TOMORROW, TUESDAY) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 17:48:56 -0000 --=-=-= Content-Type: text/plain The DT sometimes posts these on it's own, but it seems not have done so last night. CELLAR -- DRAFT AGENDA for Virtual Interim Meeting April 28, 2020 21:00 Amsterdam *** 19:00 UTC 15:00 NYC 12:00 San Francisco INFO: https://datatracker.ietf.org/meeting/interim-2020-cellar-04/session/cellar https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-04-cellar-01/ WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from March 31 meeting (attached below) 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=true 2b) APPEAR.IN is now called "whereby.com" https://whereby.com/cellar-interim 2c) Roll call 4. WG status update * EBML -- still in RFC-editor queue, waiting to get to top * FFV1 -- version 12 was posted 2020-01-28 *** NEEDS REVISED VERSION *** - Can someone help? 5. Extension drafts on Matroska 6. Work on Matroska issues. NEXT MEETING May 26, 2020. ---- PREVIOUS NOTES CELLAR -- DRAFT AGENDA for Virtual Interim Meeting March 31, 2020 21:00 Amsterdam *** 19:00 UTC 15:00 NYC 12:00 San Francisco Present: 1. Michael Richardson 1. Martin Below 1. Steve Lhomme 1. Jerome Martinez 1. Spencer Dawkins 1. Dave Rice 1. Adam INFO: https://datatracker.ietf.org/meeting/interim-2020-cellar-03/session/cellar https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-03-cellar-01/ WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from January 28 meeting (attached below) (Feb. 25 meeting did not achieve quorum) accepted unanimously. 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=true 2b) APPEAR.IN is now called "whereby.com" https://whereby.com/cellar-interim 2c) Roll call 4. WG status update * EBML -- version 17 was posted 2020-01-27 IESG approved it, and it is now in RFC-editor queue. IANA has reviewed it, created registries. Guestimate is that RFC-editor will complete work by end of March, maybe sooner. proposed Designated Experts: Primary: Dave Rice Secondary: Steve Lhomme and Moritz Bunkus * FFV1 -- version 12 was posted 2020-01-28, AD waiting for our revisions. still waiting for new document. - plan to finish this week. - 5. FFV1 issues. 6. Work on Matroska issues. - reduced pull requests to 7 open, still 51 issues open. NEXT MEETING April 28, 2020. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6nGvUACgkQgItw+93Q 3WWfMwf/ahbNd+C57zlhnbJAYkJp7VWOdceSdvcmiY5VGjhCqCkWH+ssmBW2603Z EGXeeyPFBPeSKkhb3Ol7lBm4qjybbr3oYe+ld+oe0+6HNC7hgxtu9ccgQ2E1fFvd mXfyetAGElwhqwIUDd9itY6MGvj806aqXdzWrU6qp54lAeZ0YRTOLnthuoRvV0Zu ZjetQYuzJP+69jh9AhmbfeO8X7XGPnzXRmFsHDVRtmfYOvq3Dw8cGeUtdL4JBB3f UGg9UpgI2CI8kUE2Ne/vs4f+uSxup3OW3fCccCUp8/Oxq+lQwtmonX3SBVJ0S30Q XYP+JYAZ+O+zWnKR224uuRGZ/k0iDA== =aXQD -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 27 12:15:45 2020 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 917663A1AD0 for ; Mon, 27 Apr 2020 12:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=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 En1Fs91uiq-K for ; Mon, 27 Apr 2020 12:15:40 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 D3A033A1ACD for ; Mon, 27 Apr 2020 12:15:39 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id i10so21869936wrv.10 for ; Mon, 27 Apr 2020 12:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=X3ZgfKERyiSorGosz3KGpiP6/0qbCTnPT1sq4V4LNU8=; b=hbz76NjqFlY5P+d0IAWvYgDcpJXeIXZXb3ytumXZR41hT1FvcCFEKoxdoje8C6/0FD JUByqEdgXV/c7dMqDTc4jcRaPU5BxFdC2jxNtzK5niWOpJ+IoFu5qd1JYT05QZ1PSU3h QLsvyosJeIeJxyr42CNsHeUnVKhnMz6yEqDLoUYfrNIrVgNOr91Lzqu5gI0SkA7VD0OD iyI/yXbJAZ5J2ZHwncr0ZMzYKyiJKUTJLTOZm97NbOX1l1BRRYbUbTyld6I+d/KnTho1 V8EyXArtG02xsOv7G2u9G9mtZJkLPX1LbjNOpjSMoZHgunfnzrKsxCw0kLkoehDOkK83 KkGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=X3ZgfKERyiSorGosz3KGpiP6/0qbCTnPT1sq4V4LNU8=; b=cn2B7XG+Lu8wyyIxIUZQir2XDgO1vdUJkUeCBVw82EuaICEs+kNLXl89xX/kEDMbWw mVc0XJ9K1VyCQ6EPyC9VkjbQ76EFkOPzyFb0PE2Mkb2L89hvUU7IGBfZPtNCL4Qtbtnb 0LD1Q8UL70Y8yM3bYK/fGUlmlb6AY9Bhj3Hmf0np8WkvQ5zmLfEr6gOKrYdFiiT5+v7m hJWsXWp1QoB9Lj3FCU0/SndE8nlRFq1d232vH4c5yyLqt6tsVed4bx8rOpWi4t4YeRCf u8L3SsqlivBP9C0/dSoMIIIwvIxkCw4hto0p7AeKoBbBBUBc/CqIlAreMPiyQOQObblx CKTQ== X-Gm-Message-State: AGi0PuaXlyMj6oVIjLMikBqiCUxGz58dg10xoHcTI8F4gMs74b9Sy80Z xMJLgyZixRWya0nuj+7IQvI2n9XQCsM0Rslpn4whgsh0NYo= X-Google-Smtp-Source: APiQypJHwqBNU1zw0AVsptoe5UQe0aCPgyZHjMt2kxrkefkpuYJiiOFfZ+tDnpVkDRD43wuxMcsBH6uTq+6hBHay3QQ= X-Received: by 2002:a5d:45cf:: with SMTP id b15mr28210660wrs.78.1588014937657; Mon, 27 Apr 2020 12:15:37 -0700 (PDT) MIME-Version: 1.0 References: <514D57FC-BD77-45E7-846A-046363BED953@dericed.com> <6e93c666-4414-abab-0f2e-fbe6beaec904@mediaarea.net> In-Reply-To: From: Hendrik Leppkes Date: Mon, 27 Apr 2020 21:15:27 +0200 Message-ID: To: CELLAR list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Matroska support for closed captions? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 19:15:43 -0000 On Mon, Apr 27, 2020 at 6:54 PM Devin Heitmueller wrote: > > On Mon, Apr 27, 2020 at 12:09 PM Jerome Martinez w= rote: > > > > On 27/04/2020 17:46, Dave Rice wrote: > > > > > > For EIA-608 and EIA-708 data I suppose, either a new type of Codec Ma= pping could be written (and then these would be a new type of subtitle trac= k) or they could be support as side-data with a BlockAdditionalMapping as d= escribed at https://www.ietf.org/id/draft-ietf-cellar-codec-04.html#name-bl= ock-additional-mapping. I=E2=80=99m unsure which technique the community wo= uld recommend but curious for some discussion on it. > > > > > > As MXF have JPEG-2000, I guess that captions are in a standalone > > ancillary data (SMPTE ST 291) track. > > As a first shot, I would not be in favor of BlockAdditionalMapping > > because the track does not depend on data in another bistream. > > > > then there would (at least) 2 choices: > > - demux of the track from MXF and mux of this track as is; advantage is > > that we lose no other data inside the ancillary data, disadvantage is > > that lot of different content (several formats of captions, bar data, > > VBI, time codes, Acquisition Metadata...) are muxed in the "raw" stream= , > > more difficult for a demuxer/player. > > - demux of the captions from Ancillary data from MXF; advantage is that > > we have 1 track per content stream, disadvantage is that we may lose > > some other "opaque" data from the ancillary data. > > > > That said, we could propose both. > > > > J=C3=A9r=C3=B4me > > For what it's worth, we have the same general problem within ffmpeg. > File formats like MXF and MP4 treat captions and timecodes as a > separate track, while other formats like TS expect it to be tied to > the individual video frames as side data. There's no easy answer, and > in particular it's a huge pain when you need to convert from one to > the other (e.g. extracting captions from the SEI in an H.264 TS where > it gets treated as video frame side data, and creating an MP4 where > captions need their own subtitle track). > Well, its more like TS does not handle closed captions at all, which is why they get thrown in with the video. Its not a TS concept, but a video one. If we have the option to carry them seperately, then I believe we should. It makes it so much easier for everything involved - and there is precedent for that in eg. MP4 already as well. You can always go the "TS way" with Matroska as well if you must, since its entirely container-agnostic, but if container support is being build, I see no reason to handle them differently then "proper" subtitles. - Hendrik From nobody Tue Apr 28 01:03:00 2020 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 C8B5D3A0E4B for ; Tue, 28 Apr 2020 01:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 LX9F971Fi8KV for ; Tue, 28 Apr 2020 01:02:57 -0700 (PDT) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87813A0E49 for ; Tue, 28 Apr 2020 01:02:56 -0700 (PDT) Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 54099240013 for ; Tue, 28 Apr 2020 08:02:53 +0000 (UTC) Date: Tue, 28 Apr 2020 10:02:48 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20200428080248.GV10047@michaelspb> References: <1366.1588009717@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Nachn7RqbTHiMSEX" Content-Disposition: inline In-Reply-To: <1366.1588009717@localhost> Archived-At: Subject: Re: [Cellar] 2020-04-28 VIRTUAL INTERIM AGENDA (TOMORROW, TUESDAY) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 28 Apr 2020 08:02:59 -0000 --Nachn7RqbTHiMSEX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 27, 2020 at 01:48:37PM -0400, Michael Richardson wrote: >=20 > The DT sometimes posts these on it's own, but it seems not have done so l= ast night. >=20 > CELLAR -- DRAFT AGENDA for Virtual Interim Meeting > April 28, 2020 21:00 Amsterdam *** > 19:00 UTC > 15:00 NYC > 12:00 San Francisco I did yesterday have some intermittent net connection issues. So if i fail = to appear during that meeting its this time not because i forgot ;) Also just to use this opertunity, i think we should put more effort into improving features & compression. This would ensure that by the time the text is fully polished it is still relevant and also it could attract more and a different kind of people if we did something like a compression/algor= ithm competition for the next version of ffv1 and flac. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threat= s=20 related to an insecure 5G network, it needs to rethink the extent to which = it values corporate profits and government espionage over security.-Bruce Schn= eier --Nachn7RqbTHiMSEX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEAREIAAYFAl6n4ygACgkQYR7HhwQLD6u8uQCdH6nlV5gcIcJ9Vana9E5LVsZq k7cAnRsvG5Vgd4WTNNUgW2soTHQYWUPh =U0EQ -----END PGP SIGNATURE----- --Nachn7RqbTHiMSEX-- From nobody Tue Apr 28 01:15:44 2020 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 8AB453A0EEC for ; Tue, 28 Apr 2020 01:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kS5QKUIm2rmq for ; Tue, 28 Apr 2020 01:15:41 -0700 (PDT) Received: from 8.mo68.mail-out.ovh.net (8.mo68.mail-out.ovh.net [46.105.74.219]) (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 CFEF53A0ED5 for ; Tue, 28 Apr 2020 01:15:40 -0700 (PDT) Received: from player758.ha.ovh.net (unknown [10.108.42.176]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 8ECB6164DA1 for ; Tue, 28 Apr 2020 10:15:38 +0200 (CEST) Received: from mediaarea.net (p548F98B2.dip0.t-ipconnect.de [84.143.152.178]) (Authenticated sender: jerome@mediaarea.net) by player758.ha.ovh.net (Postfix) with ESMTPSA id 338E311D8F385 for ; Tue, 28 Apr 2020 08:15:37 +0000 (UTC) To: cellar@ietf.org References: <1366.1588009717@localhost> <20200428080248.GV10047@michaelspb> From: Jerome Martinez Message-ID: Date: Tue, 28 Apr 2020 10:15:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200428080248.GV10047@michaelspb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 16585068581810868369 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedriedugddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefheenucfhrhhomheplfgvrhhomhgvucforghrthhinhgviicuoehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvtheqnecukfhppedtrddtrddtrddtpdekgedrudegfedrudehvddrudejkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejheekrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] 2020-04-28 VIRTUAL INTERIM AGENDA (TOMORROW, TUESDAY) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 28 Apr 2020 08:15:43 -0000 On 28/04/2020 10:02, Michael Niedermayer wrote: > Also just to use this opertunity, i think we should put more effort into > improving features & compression. This would ensure that by the time the > text is fully polished it is still relevant and also it could attract more > and a different kind of people if we did something like a compression/algorithm > competition for the next version of ffv1 and flac. The text for FFV1 v0-v3 is nearly finished, just some fixes to push, which are not fancy and not a technical challenge, but having an IETF RFC would also attract more people. It is pretty important for the adoption of FFV1 by several entities. Additionally, the compression ratio is not the main feedback I have, lot of people complain about the speed especially on 4K, and there is surely already a lot to do on this part without a new version, but this topic should also be part of the design of the next version of FFV1 (and seeing the limits of FFV1 v3 with the current HW, massively parallelized, would be a precondition for the design of FFV1 v4 IMO, lot to do :) ). Jérôme From nobody Tue Apr 28 06:29:20 2020 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 DCC313A152E for ; Tue, 28 Apr 2020 06:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 s0gyKY0UWkD3 for ; Tue, 28 Apr 2020 06:29:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B953A1693 for ; Tue, 28 Apr 2020 06:28:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AA17938983; Tue, 28 Apr 2020 09:26:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2D51998A; Tue, 28 Apr 2020 09:28:33 -0400 (EDT) From: Michael Richardson To: Michael Niedermayer , cellar@ietf.org In-Reply-To: <20200428080248.GV10047@michaelspb> References: <1366.1588009717@localhost> <20200428080248.GV10047@michaelspb> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] 2020-04-28 VIRTUAL INTERIM AGENDA (TOMORROW, TUESDAY) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 28 Apr 2020 13:29:19 -0000 --=-=-= Content-Type: text/plain Michael Niedermayer wrote: >> CELLAR -- DRAFT AGENDA for Virtual Interim Meeting >> April 28, 2020 21:00 Amsterdam *** >> 19:00 UTC >> 15:00 NYC >> 12:00 San Francisco > I did yesterday have some intermittent net connection issues. So if i fail to appear > during that meeting its this time not because i forgot ;) Understood! > Also just to use this opertunity, i think we should put more effort into > improving features & compression. This would ensure that by the time the > text is fully polished it is still relevant and also it could attract more > and a different kind of people if we did something like a compression/algorithm > competition for the next version of ffv1 and flac. My understanding is that ffv1 v0-3, which is past WGLC, documents only things that are already out there. I'm not sure that ffv1 v4 should include new work either, but the WG could decide to that. Alternatively, this competition might make for a good extension draft. While more documents are not necessarily better because of the fixed overhead of getting through the process, given the immense size of our documents, I think it would be fine. I note that the flac code is already a separate draft. I'm not exactly sure how the competition would work. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6oL4AACgkQgItw+93Q 3WWN5wgAtYGptr2gnj/CxHU9nbmT3EdUXyKFBJh/CDIvLBomM6u2dDmzzYv5PGxh uzCSv+yetcm3b3KT6P9g1donkP1l5et7UFmx0Y73w/TjEVQHne49+zsx5IFyTyFo kP2j8I3QceouRgN6iyEfOzhlmfEx+OSLA97QkElvGsd0YSt6XVrCaPK2cKEsTrS2 FHYdojbFZpe6GrFb55zjeFqp8kxg/C6taL7xJ2ZEzw1bAmIz6nSQYz8TTylYUDtv xH8wY1Zbe0qgvGZDQQ6tYyJoOfJX/qZqZ3OnQ7SxI8exNZbkIfJlcLxSFsqJvGLF QbMYm/bYZMpVNx1eIkGQ4IqmlXMZ+A== =PX8W -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 28 11:47:16 2020 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 A9CD43A0935; Tue, 28 Apr 2020 11:47:09 -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.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <158809962963.21469.3501324837906539000@ietfa.amsl.com> Date: Tue, 28 Apr 2020 11:47:09 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-v4-10.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 28 Apr 2020 18:47:10 -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 WG of the IETF. Title : FFV1 Video Coding Format Version 4 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-v4-10.txt Pages : 53 Date : 2020-04-28 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-ietf-cellar-ffv1-v4/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-v4-10 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-v4-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-v4-10 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 Tue Apr 28 11:47:24 2020 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 3435F3A0934; Tue, 28 Apr 2020 11:47:11 -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.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <158809963115.5981.9143968467791325492@ietfa.amsl.com> Date: Tue, 28 Apr 2020 11:47:11 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-13.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 28 Apr 2020 18:47:11 -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 WG of the IETF. Title : FFV1 Video Coding Format Version 0, 1, and 3 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-13.txt Pages : 51 Date : 2020-04-28 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-ietf-cellar-ffv1/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-13 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-13 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 Tue Apr 28 22:15:47 2020 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 26DCB3A0779 for ; Tue, 28 Apr 2020 22:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=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 WVnTuxfAE94M for ; Tue, 28 Apr 2020 22:15:41 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 C437B3A0774 for ; Tue, 28 Apr 2020 22:15:40 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id g184so519681vsc.0 for ; Tue, 28 Apr 2020 22:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=EDhGJulUDkpT2KVL4Ia8weZFt0qfh973ELtKYfRC6JA=; b=ArGVMn/WVU50l6/HHByTQt7JyKLB9q+3uQ932conucVEiKGToPKQJwRqCczb46Xr0S OFMOY1mLJ3ntJLh6LJS0rQturVb66Yy/ivg0enjILui2tzAdLzXhIISSeRPfSCCDjQjQ DeRkig8fVDtOyiua8Ky7CuFy8B/upfUNkN3LCv73jsxT/qgY3AFZK83oNLU6IkVS9StG eF3+D7OZshbooVBg2Td9XEweexXK6RqmCzft0Ck4Wrz5Uccn/yNeB07tiYnCAMDHw+rS BhOyIp3+1ECAa7G6JFkCCFPhFrVmgo3zyBZvwxQ5K6wZqGt1dfOJFYzoLHsi+pJTPkUW tuVw== 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:cc; bh=EDhGJulUDkpT2KVL4Ia8weZFt0qfh973ELtKYfRC6JA=; b=DoUa3Gk5oDBLGQ8JzSHhXyAWma+Nrqr9n1WTVfgl0xi73sHfj83vvgbZbu0MHktXIw xkOIr2UEaGl6XIKxn2uAEW8S166p6Rx2T0rtuCSlsYYbMHZuhLkhQoesKxHkGUXa2p5Y dzztygs/3hmJ2PORFNxXIPcitWARzvjOdMW4wVrBkaJJYfHRowuXVHCm/SlbhRBge4Z4 1sGX2mKUUgvxV6Aowk6dSaIIxGc77GlaE0PCmZnwchmt4i5vJvdeEsnF01jJ3LBGakhO L7P9Cu6n44laUnvslCUoq+oqbO2wlbY339Lny+9mhzS6c5DEzQIf5M6a0WYgx6sLV8EO ylNw== X-Gm-Message-State: AGi0PubQdQvef8paGctkcEHPPZ4QyKuIocXdBn8grbGyzr0Wv4zlUk/u VclpdlfMXvCzQoZBw0Izp/6rEdgcJ6FkoH+qOzreSkw/8EY= X-Google-Smtp-Source: APiQypIjgpMSksWX4j86s6FF0mdCpam1dr+KvAlNfbceawL99OGe6NVmpYTrv9QGQf1TIms/MKEbULzti7QajthVaf8= X-Received: by 2002:a05:6102:208a:: with SMTP id h10mr23468622vsr.13.1588137339119; Tue, 28 Apr 2020 22:15:39 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Tue, 28 Apr 2020 22:15:28 -0700 Message-ID: To: cellar@ietf.org Cc: Adam Roach Content-Type: multipart/alternative; boundary="000000000000f3f03a05a4670915" Archived-At: Subject: [Cellar] draft-ietf-cellar-ffv1-13 comments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 05:15:45 -0000 --000000000000f3f03a05a4670915 Content-Type: text/plain; charset="UTF-8" Hi there, I've reviewed -13 of this document, and the results are below. I also used Adam's prior AD review as a checklist of sorts. I think this needs one more round before it can be sent to the IESG. Fortunately most of this is editorial, but there's a lot, and there are one or two substantive things I urge you to address. Section 2.1: * "RCT" doesn't appear as a standalone term in this document other than as part of the string "JPEG2000-RCT", so I don't know if it's worth including in your glossary. * "TBA" is not used in this document other than in the glossary. It should probably be removed. Sections 2.1 and 3.5: * "1 or more" should become "one or more". Similarly, "1 of the 5" should be "one of the five". Section 2.2.2: * The sentence starting "With" should be attached to the previous sentence with a comma. It's not a sentence by itself. * "This is equivalent to, b times dividing a by 2 with rounding toward negative infinity." -- I suggest: "This is equivalent to dividing a by 2, b times, with rounding toward negative infinity." Section 2.2.5: * The layout of this table is a little hard to parse. I would quote the terms you're describing, or put colons after them, or something like that. Section 3.3: * The "Background" paragraph starts out talking in the past tense, then switches to present ("was used", then "when the issue is discovered"). Then it switches back in a later sentence. That should all be past tense, right? * It looks a little odd to quote an equation, especially where that's not done elsewhere in the document so far. Section 3.7.2: * The spacing around and within the equations in this section is not consistent with the rest of the document. * "offsetted" should be "offset" Section 3.8.1.1.1: * "3 modes" should be "three modes" * "1 byte shorter" should be "one byte shorter" * "3 places" should be "three places" * "Above describes the range decoding, encoding is defined as ..." -- this should be two separate sentences Section 3.8.1.2: * As Adam mentioned in his review: "The exact contexts used are best described by Figure 15, followed by some comments.", but there are no comments after Figure 15 nor after this prose. * Adam also pointed out that this table appears to have a "type" column that serves no purpose. It should either be used or removed. Or, if as I think I figured out much later, this layout is actually a way to indicate the types of output values when the pseudo-code yields something, you really should explain that either here, or maybe earlier where you're describing conventions used in this document. * Adam also pointed out that the put_rac() function is defined nowhere in this document nor is a definition for it referenced. Section 3.8.2.1: * "2 parts" should be "two parts" * "the prefix stores ..." should be the start of a new sentence. * Another table with an unused "type" column. Section 3.8.2.1.2: * The prose in the ESC line uses too many commas. Maybe: "the value - 11, in MSB first order; ESC may only ..." Section 3.8.2.1.3: * Same issue about "value". Section 3.8.2.2.1: * "2 parts" -- "two parts"; "2nd' -- "second" * "the prefix" should begin a new sentence * another table with an unused "type" column Section 3.8.2.2.2: * This code uses a function defined in the next section. They should be swapped perhaps, or at least a forward reference would be helpful. * The final paragraph appears to be made up of two sentences run together. Section 3.8.2.3: * sign_extend() is undefined. Section 4: * "1 or more" -- "one or more" * This is the first time there's a reference to a "header". Is more context needed here? Section 4.1: * QuantizationTableSet() isn't defined until much later in the document. Again, a forward reference would be helpful. Section 4.1.1: * "... version 2 files SHOULD NOT exist ..." -- what's an implementer supposed to do with this normative instruction? Section 4.1.3: * "... there is no known implementations ..." -- change "is" to "are", or use "implementation" Section 4.1.5: * The normative language at the end here is pretty crisp, but what should an implementation do if it receives something that doesn't comply? Section 4.1.7: * The sentence at the end appears to be two sentences run together. Section 4.1.8, 4.1.9: * The spacing in the equations here isn't consistent with the rest of the document. Section 4.1.15: * This conditional syntax is incomplete since the ":" part is missing. Section 4.1.16: * As Adam pointed out, another unexplained reference to "header" ("global" in this case). Section 4.2: * First-ever reference to a "track header". Section 4.2.2: * Change "crc" to "CRC" (two instances). It's correct the third time. Section 4.2.3.1: * "AVI " should be just "AVI" (i.e., remove the trailing space) Section 4.4: * Addressing normative language to authors of revisions to this document is novel. I suggest using non-normative prose here. * "an other" should be "another" Section 4.5.5: * Rather than separating this formula away from the text as was done in prior sections, here it's quoted inline. I find the former much more readable. Section 4.6: * Another table with an empty "type" column. I think I see now that the column is populated against each line that outputs something, but can it not just be omitted when there's no output to the function? * But does this function really output nothing? Sections 4.6.1 through 4.6.4: * Same comment as before about inline formulae. Section 4.7: * This should have indicators for output types, I think. Section 4.7.1: * I don't understand the second sentence. I parse it as: "X" and "Y" value is "Z". Did you mean "The values of X and Y are Z"? * Same problem on the next line, coupled with quoted inline equations again. Sections 4.7.2 and 4.7.3: * Same issue with quoted inline equations. Section 7: * Does the subtype intend to be case-sensitive? i.e., couldn't "ffv1" work? * Required parameters should be "N/A" if you have none to register. * "This parameter is used to signal ..." -- to what is this referring? Section 8: * This can be merged with Section 7. Section 9: * Appendices go after the references. -MSK --000000000000f3f03a05a4670915 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

I've reviewed = -13 of this document, and the results are below.=C2=A0 I also used Adam'= ;s prior AD review as a checklist of sorts.

I thin= k this needs one more round before it can be sent to the IESG.=C2=A0 Fortun= ately most of this is editorial, but there's a lot, and there are one o= r two substantive things I urge you to address.

Section 2= .1:
* "RCT" doesn't appear as a standalone term= in this document other than as part of the string "JPEG2000-RCT"= , so I don't know if it's worth including in your glossary.
* "TBA" is not used in this document other than in the glo= ssary.=C2=A0 It should probably be removed.

Se= ctions 2.1 and 3.5:
* "1 or more" should become &qu= ot;one or more".=C2=A0 Similarly, "1 of the 5" should be &qu= ot;one of the five".

Section 2.2.2:
* The sentence starting "With" should be attached to the= previous sentence with a comma.=C2=A0 It's not a sentence by itself.
* "This is equivalent to, b times dividing a by 2 with roundi= ng toward negative infinity." -- I suggest: "This is equivalent t= o dividing a by 2, b times,=C2=A0with rounding toward negative infinity.&qu= ot;

Section 2.2.5:
* The layout of this tab= le is a little hard to parse.=C2=A0 I would quote the terms you're desc= ribing, or put colons after them, or something like that.

Section 3.3:
* The "Background" paragraph starts o= ut talking in the past tense, then switches to present ("was used"= ;, then "when the issue is discovered").=C2=A0 Then it switches b= ack in a later sentence.=C2=A0 That should all be past tense, right?
* It looks a little odd to quote an equation, especially where that= 's not done elsewhere in the document so far.

<= div>Section 3.7.2:
* The spacing around and within the equati= ons in this section is not consistent with the rest of the document.
<= div>* "offsetted" should be "offset"

Section 3.8.1.1.1:
* "3 modes" should be &qu= ot;three modes"
* "1 byte shorter" should be &= quot;one byte shorter"
* "3 places" should be &quo= t;three places"
* "Above describes the range decodi= ng, encoding is defined as ..." -- this should be two separate sentenc= es

Section 3.8.1.2:=
* As Adam mentioned in his review: "The exact contexts = used are best described by Figure 15, followed by some comments.", but= there are no comments after Figure 15 nor after this prose.
= * Adam also pointed out that this table appears to have a "type" = column that serves no purpose.=C2=A0 It should either be used or removed.= =C2=A0 Or, if as I think I figured out much later, this layout is actually = a way to indicate the types of output values when the pseudo-code yields so= mething, you really should explain that either here, or maybe earlier where= you're describing conventions used in this document.
* A= dam also pointed out that the put_rac() function is defined nowhere in this= document nor is a definition for it referenced.

Section = 3.8.2.1:
* "2 parts"= should be "two parts"
* "the prefix stores ..= ." should be the start of a new sentence.
* Another tabl= e with an unused "type" column.

Section 3.8.2.1.2:
* The prose in the ESC line uses too many commas.=C2=A0 Maybe: "= ;the value - 11, in MSB first order; ESC may only ..."

Section 3.8.2.1.3:
* Same issue about "value".

Section 3.8.2.2.1:
* "2 parts&qu= ot; -- "two parts"; "2nd' -- "second"
* "the prefix" should begin a new sentence
* anot= her table with an unused "type" column

S= ection 3.8.2.2.2:
* This code uses a function defined in the = next section.=C2=A0 They should be swapped perhaps, or at least a forward r= eference would be helpful.
* The final paragraph appears to b= e made up of two sentences run together.

Secti= on 3.8.2.3:
* sign_extend() is= undefined.

Section 4:
* "1 or = more" -- "one or more"
* This is the first tim= e there's a reference to a "header".=C2=A0 Is more context ne= eded here?

Section 4.1:
* Quanti= zationTableSet() isn't defined until much later in the document.=C2=A0 = Again, a forward reference would be helpful.

Secti= on 4.1.1:
* "... version 2 files SHOULD NOT exist ...&qu= ot; -- what's an implementer supposed to do with this normative instruc= tion?

Section 4.1.3:
* "...= there is no known implementations ..." -- change "is" to &q= uot;are", or use "implementation"

Section 4.1.5:
* The normative language at the end here is= pretty crisp, but what should an implementation do if it receives somethin= g that doesn't comply?

Section 4.1.7:
* The sentence at the end appears to be two sentences run together.

Section 4.1.8, 4.1.9:
* The spacing i= n the equations here isn't consistent with the rest of the document.

Section 4.1.15:
* This conditional syn= tax is incomplete since the ":" part is missing.
Section 4.1.16:
* As Adam pointed out, another u= nexplained reference to "header" ("global" in this case= ).

Section 4.2:
* First-ever referen= ce to a "track header".

Section 4.2.2:
* Change "crc" to "CRC" (two instances).= =C2=A0 It's correct the third time.

Section 4.2.3.1:
* "AVI " shou= ld be just "AVI" (i.e., remove the trailing space)

=
Section 4.4:
* Addressing normative language to au= thors of revisions to this document is novel.=C2=A0 I suggest using non-nor= mative prose here.
* "an other" should be "ano= ther"

Section 4.5.5:
* Rather than sep= arating this formula away from the text as was done in prior sections, here= it's quoted inline.=C2=A0 I find the former much more readable.
<= div>
Section 4.6:
* Another table with an empty= "type" column.=C2=A0 I think I see now that the column is popula= ted against each line that outputs something, but can it not just be omitte= d when there's no output to the function?
* But does this= function really output nothing?

Sections 4.6.= 1 through 4.6.4:
* Same comment as before about inline formul= ae.

Section 4.7:
* This should h= ave indicators for output types, I think.

Section = 4.7.1:
* I don't understand the second sentence.=C2=A0 I = parse it as: "X" and "Y" value is "Z".=C2=A0 = Did you mean "The values of X and Y are Z"?
* Same = problem on the next line, coupled with quoted inline equations again.
=

Sections 4.7.2 and 4.7.3:
* Same issue wi= th quoted inline equations.

Section 7:
* Does the subtype intend to be case-sensitive?=C2=A0 i.e., couldn't= "ffv1" work?
* Required parameters should be "= ;N/A" if you have none to register.
* "This paramet= er is used to signal ..." -- to what is this referring?

=
Section 8:
* This can be merged with Section 7.

Section 9:
* Appendices go after the r= eferences.

-MSK
--000000000000f3f03a05a4670915-- From nobody Wed Apr 29 13:48:46 2020 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 04A373A17B4 for ; Wed, 29 Apr 2020 13:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 Xh5_GXbBvd8X for ; Wed, 29 Apr 2020 13:48:37 -0700 (PDT) Received: from 4.mo3.mail-out.ovh.net (4.mo3.mail-out.ovh.net [178.33.46.10]) (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 6D7963A17AE for ; Wed, 29 Apr 2020 13:48:35 -0700 (PDT) Received: from player715.ha.ovh.net (unknown [10.110.171.136]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id B9FAF24CA47 for ; Wed, 29 Apr 2020 22:48:33 +0200 (CEST) Received: from mediaarea.net (p548F98B2.dip0.t-ipconnect.de [84.143.152.178]) (Authenticated sender: jerome@mediaarea.net) by player715.ha.ovh.net (Postfix) with ESMTPSA id 0D3ED11B45370; Wed, 29 Apr 2020 20:48:27 +0000 (UTC) To: cellar@ietf.org References: Cc: "Murray S. Kucherawy" , Adam Roach From: Jerome Martinez Message-ID: <6a5d91f3-e4b4-7238-3f59-c1f4064901a9@mediaarea.net> Date: Wed, 29 Apr 2020 22:48:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EBA04BB101B0CB8BB69062D8" Content-Language: en-US X-Ovh-Tracer-Id: 16726650493173108792 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrieefgdduhedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpedvhfdvhfegtefhjedvveejtdfgteduvedujeektdfgtdevteekgefhvdduvefhtdenucffohhmrghinhepghhithhhuhgsrdgtohhmpdefrdekrddurddvpdefrdekrddvrddupdefrdekrddvrdefpdegrddvrdefrddunecukfhppedtrddtrddtrddtpdekgedrudegfedrudehvddrudejkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejudehrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] draft-ietf-cellar-ffv1-13 comments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 20:48:44 -0000 This is a multi-part message in MIME format. --------------EBA04BB101B0CB8BB69062D8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 29/04/2020 07:15, Murray S. Kucherawy wrote: > I've reviewed -13 of this document, and the results are below.  I also > used Adam's prior AD review as a checklist of sorts. Thank you for your review. I put comments below to say 'Fixed' if the referenced pull request addresses it. Some of 'TO DO' and in a few places, I mention your name in the comment as I would like clarification. https://github.com/FFmpeg/FFV1/pull/199 > Section 2..1: > * "RCT" doesn't appear as a standalone term in this document other > than as part of the string "JPEG2000-RCT", so I don't know if it's > worth including in your glossary. Fixed. "RCT" definition is repeated when we explain "JPEG2000-RCT", so I removed it. > * "TBA" is not used in this document other than in the glossary.  It > should probably be removed. Fixed. It is used in FFV1 v4 development branch but not in v3, so I flagged it as v4 only, it will not be in the next IETF doc. > Sections 2.1 and 3.5: > * "1 or more" should become "one or more".  Similarly, "1 of the 5" > should be "one of the five". Fixed. > Section 2.2.2: > * The sentence starting "With" should be attached to the previous > sentence with a comma.  It's not a sentence by itself. > * "This is equivalent to, b times dividing a by 2 with rounding toward > negative infinity." -- I suggest: "This is equivalent to dividing a by > 2, b times, with rounding toward negative infinity." Fixed. > Section 2.2.5: > * The layout of this table is a little hard to parse. I would quote > the terms you're describing, or put colons after them, or something > like that. Fixed. I used the same method as previous chapters: "(name)" means (meaning). > Section 3.3: > * The "Background" paragraph starts out talking in the past tense, > then switches to present ("was used", then "when the issue is > discovered").  Then it switches back in a later sentence.  That should > all be past tense, right? Fixed. > * It looks a little odd to quote an equation, especially where that's > not done elsewhere in the document so far. Fixed. > Section 3.7.2: > * The spacing around and within the equations in this section is not > consistent with the rest of the document. Fixed. > * "offsetted" should be "offset" Fixed. > Section 3.8.1.1.1: > * "3 modes" should be "three modes" > * "1 byte shorter" should be "one byte shorter" > * "3 places" should be "three places" > * "Above describes the range decoding, encoding is defined as ..." -- > this should be two separate sentences Fixed. > Section 3.8.1.2 : > * As Adam mentioned in his review: "The exact contexts used are best > described by Figure 15, followed by some comments.", but there are no > comments after Figure 15 nor after this prose. > * Adam also pointed out that this table appears to have a "type" > column that serves no purpose.  It should either be used or removed.  > Or, if as I think I figured out much later, this layout is actually a > way to indicate the types of output values when the pseudo-code yields > something, you really should explain that either here, or maybe > earlier where you're describing conventions used in this document. > * Adam also pointed out that the put_rac() function is defined nowhere > in this document nor is a definition for it referenced. We still have to handle these issues (separate fixes) > Section 3.8.2.1 : > * "2 parts" should be "two parts" > * "the prefix stores ...." should be the start of a new sentence. Fixed. > * Another table with an unused "type" column. On the unused column global issue, the corresponding patch is in discussion: https://github.com/FFmpeg/FFV1/pull/196#issuecomment-620697043 > Section 3.8.2.1.2: > * The prose in the ESC line uses too many commas. Maybe: "the value - > 11, in MSB first order; ESC may only ..." Fixed. As there is a "may" which is used not really in a RFC 2119 manner, I extracted the sentence from the table and used "MUST NOT". > Section 3.8.2.1.3: > * Same issue about "value". Murray, I didn't get it (no comma there) > Section 3.8.2.2.1: > * "2 parts" -- "two parts"; "2nd' -- "second" > * "the prefix" should begin a new sentence Fixed. > * another table with an unused "type" column Same as with other tables. > Section 3.8.2.2.2: > * This code uses a function defined in the next section.  They should > be swapped perhaps, or at least a forward reference would be helpful. TO DO. > * The final paragraph appears to be made up of two sentences run together. Fixed. > Section 3.8.2.3 : > * sign_extend() is undefined. TO DO. > Section 4: > * "1 or more" -- "one or more" Fixed. > * This is the first time there's a reference to a "header".  Is more > context needed here? TO DO. > Section 4.1: > * QuantizationTableSet() isn't defined until much later in the > document.  Again, a forward reference would be helpful. TO DO. > Section 4.1.1: > * "... version 2 files SHOULD NOT exist ..." -- what's an implementer > supposed to do with this normative instruction? Fixed. We indicate that it is possible for a decoder to meet such stream, and the implementer is not required to support it, but it is also not required not to support it. It is just not part of the standard. I rephrased in order to just say to reject such content. > Section 4.1.3: > * "... there is no known implementations ..." -- change "is" to "are", > or use "implementation" Fixed. > Section 4.1.5: > * The normative language at the end here is pretty crisp, but what > should an implementation do if it receives something that doesn't comply? Fixed. I rephrased and say to reject such content > Section 4.1.7: > * The sentence at the end appears to be two sentences run together. Fixed. > Section 4.1.8, 4.1.9: > * The spacing in the equations here isn't consistent with the rest of > the document. Fixed. > Section 4.1.15: > * This conditional syntax is incomplete since the ":" part is missing. TO DO. Not missing in source file (in Markdown) and not missing in IETF HTML output. Issue is in text output. > Section 4.1.16: > * As Adam pointed out, another unexplained reference to "header" > ("global" in this case). TO DO. > Section 4.2: > * First-ever reference to a "track header". TO DO. > Section 4.2.2: > * Change "crc" to "CRC" (two instances).  It's correct the third time. Fixed. > Section 4.2.3.1 : > * "AVI " should be just "AVI" (i.e., remove the trailing space) Murray, the "trailing" space is required. It is a part of a 4-letter identifier found in AVI files (0x41564920 in hexadecimal). > Section 4.4: > * Addressing normative language to authors of revisions to this > document is novel.  I suggest using non-normative prose here. Fixed. I pushed the prose to the end in an informative appendix. > * "an other" should be "another" Fixed. > Section 4.5.5: > * Rather than separating this formula away from the text as was done > in prior sections, here it's quoted inline.  I find the former much > more readable. Fixed. > Section 4.6: > * Another table with an empty "type" column.  I think I see now that > the column is populated against each line that outputs something, but > can it not just be omitted when there's no output to the function? Same as with other tables. > * But does this function really output nothing? Murray, not sure I understand the question. This function read nothing from the input, and call Line() which calls Pixel(). It is in a standalone pseudo-code block for an having blocks easy to understand (SliceHeader(), SliceContent(), SliceHeader()). SliceContent() could move into Slice() but IMO it is less readable. > Sections 4.6.1 through 4.6.4: > * Same comment as before about inline formulae. Fixed. But it means that all is in one chapter, IMO it is a lot of formulae. > Section 4.7: > * This should have indicators for output types, I think. Fixed. I added a "sd" type. > Section 4.7.1: > * I don't understand the second sentence.  I parse it as: "X" and "Y" > value is "Z".  Did you mean "The values of X and Y are Z"? Fixed. I reworded a bit this part. > * Same problem on the next line, coupled with quoted inline equations > again. Fixed. > Sections 4.7.2 and 4.7.3: > * Same issue with quoted inline equations. Fixed. > Section 7: > * Does the subtype intend to be case-sensitive?  i.e., couldn't "ffv1" > work? Fixed. > * Required parameters should be "N/A" if you have none to register. Fixed. > * "This parameter is used to signal ..." -- to what is this referring? TO DO. > Section 8: > * This can be merged with Section 7. Fixed. > Section 9: > * Appendices go after the references. TO DO. Jérôme --------------EBA04BB101B0CB8BB69062D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

On 29/04/2020 07:15, Murray S. Kucherawy wrote:
I've reviewed -13 of this document, and the results are below.  I also used Adam's prior AD review as a checklist of sorts.

Thank you for your review. I put comments below to say 'Fixed' if the referenced pull request addresses it. Some of 'TO DO' and in a few places, I mention your name in the comment as I would like clarification.
https://github.com/FFmpeg/FFV1/pull/199


Section 2..1:
* "RCT" doesn't appear as a standalone term in this document other than as part of the string "JPEG2000-RCT", so I don't know if it's worth including in your glossary.

Fixed.
"RCT" definition is repeated when we explain "JPEG2000-RCT", so I removed it.


* "TBA" is not used in this document other than in the glossary.  It should probably be removed.

Fixed.
It is used in FFV1 v4 development branch but not in v3, so I flagged it as v4 only, it will not be in the next IETF doc.


Sections 2.1 and 3.5:
* "1 or more" should become "one or more".  Similarly, "1 of the 5" should be "one of the five".

Fixed.


Section 2.2.2:
* The sentence starting "With" should be attached to the previous sentence with a comma.  It's not a sentence by itself.
* "This is equivalent to, b times dividing a by 2 with rounding toward negative infinity." -- I suggest: "This is equivalent to dividing a by 2, b times, with rounding toward negative infinity."

Fixed.


Section 2.2.5:
* The layout of this table is a little hard to parse.  I would quote the terms you're describing, or put colons after them, or something like that.

Fixed.
I used the same method as previous chapters: "(name)" means (meaning).


Section 3.3:
* The "Background" paragraph starts out talking in the past tense, then switches to present ("was used", then "when the issue is discovered").  Then it switches back in a later sentence.  That should all be past tense, right?

Fixed.


* It looks a little odd to quote an equation, especially where that's not done elsewhere in the document so far.

Fixed.


Section 3.7.2:
* The spacing around and within the equations in this section is not consistent with the rest of the document.

Fixed.


* "offsetted" should be "offset"

Fixed.


Section 3.8.1.1.1:
* "3 modes" should be "three modes"
* "1 byte shorter" should be "one byte shorter"
* "3 places" should be "three places"
* "Above describes the range decoding, encoding is defined as ..." -- this should be two separate sentences

Fixed.


Section 3.8.1.2:
* As Adam mentioned in his review: "The exact contexts used are best described by Figure 15, followed by some comments.", but there are no comments after Figure 15 nor after this prose.
* Adam also pointed out that this table appears to have a "type" column that serves no purpose.  It should either be used or removed.  Or, if as I think I figured out much later, this layout is actually a way to indicate the types of output values when the pseudo-code yields something, you really should explain that either here, or maybe earlier where you're describing conventions used in this document.
* Adam also pointed out that the put_rac() function is defined nowhere in this document nor is a definition for it referenced.

We still have to handle these issues (separate fixes)


Section 3.8.2.1:
* "2 parts" should be "two parts"
* "the prefix stores ...." should be the start of a new sentence.

Fixed.


* Another table with an unused "type" column.

On the unused column global issue, the corresponding patch is in discussion:
https://github.com/FFmpeg/FFV1/pull/196#issuecomment-620697043


Section 3.8.2.1.2:
* The prose in the ESC line uses too many commas.  Maybe: "the value - 11, in MSB first order; ESC may only ..."

Fixed.
As there is a "may" which is used not really in a RFC 2119 manner, I extracted the sentence from the table and used "MUST NOT".


Section 3.8.2.1.3:
* Same issue about "value".

Murray, I didn't get it (no comma there)


Section 3.8.2.2.1:
* "2 parts" -- "two parts"; "2nd' -- "second"
* "the prefix" should begin a new sentence

Fixed.


* another table with an unused "type" column

Same as with other tables.


Section 3.8.2.2.2:
* This code uses a function defined in the next section.  They should be swapped perhaps, or at least a forward reference would be helpful.

TO DO.


* The final paragraph appears to be made up of two sentences run together.

Fixed.


Section 3.8.2.3:
* sign_extend() is undefined.

TO DO.


Section 4:
* "1 or more" -- "one or more"

Fixed.


* This is the first time there's a reference to a "header".  Is more context needed here?

TO DO.


Section 4.1:
* QuantizationTableSet() isn't defined until much later in the document.  Again, a forward reference would be helpful.

TO DO.


Section 4.1.1:
* "... version 2 files SHOULD NOT exist ..." -- what's an implementer supposed to do with this normative instruction?

Fixed.
We indicate that it is possible for a decoder to meet such stream, and the implementer is not required to support it, but it is also not required not to support it. It is just not part of the standard.
I rephrased in order to just say to reject such content.


Section 4.1.3:
* "... there is no known implementations ..." -- change "is" to "are", or use "implementation"

Fixed.


Section 4.1.5:
* The normative language at the end here is pretty crisp, but what should an implementation do if it receives something that doesn't comply?

Fixed.
I rephrased and say to reject such content


Section 4.1.7:
* The sentence at the end appears to be two sentences run together.

Fixed.


Section 4.1.8, 4.1.9:
* The spacing in the equations here isn't consistent with the rest of the document.

Fixed.


Section 4.1.15:
* This conditional syntax is incomplete since the ":" part is missing.

TO DO.
Not missing in source file (in Markdown) and not missing in IETF HTML output.
Issue is in text output.


Section 4.1.16:
* As Adam pointed out, another unexplained reference to "header" ("global" in this case).

TO DO.


Section 4.2:
* First-ever reference to a "track header".

TO DO.


Section 4.2.2:
* Change "crc" to "CRC" (two instances).  It's correct the third time.

Fixed.


Section 4.2.3.1:
* "AVI " should be just "AVI" (i.e., remove the trailing space)

Murray, the "trailing" space is required. It is a part of a 4-letter identifier found in AVI files (0x41564920 in hexadecimal).


Section 4.4:
* Addressing normative language to authors of revisions to this document is novel.  I suggest using non-normative prose here.

Fixed.
I pushed the prose to the end in an informative appendix.


* "an other" should be "another"

Fixed.


Section 4.5.5:
* Rather than separating this formula away from the text as was done in prior sections, here it's quoted inline.  I find the former much more readable.

Fixed.

Section 4.6:
* Another table with an empty "type" column.  I think I see now that the column is populated against each line that outputs something, but can it not just be omitted when there's no output to the function?

Same as with other tables.


* But does this function really output nothing?

Murray, not sure I understand the question.
This function read nothing from the input, and call Line() which calls Pixel().
It is in a standalone pseudo-code block for an having blocks easy to understand (SliceHeader(), SliceContent(), SliceHeader()).
SliceContent() could move into Slice() but IMO it is less readable.


Sections 4.6.1 through 4.6.4:
* Same comment as before about inline formulae.

Fixed.
But it means that all is in one chapter, IMO it is a lot of formulae.


Section 4.7:
* This should have indicators for output types, I think.

Fixed.
I added a "sd" type.


Section 4.7.1:
* I don't understand the second sentence.  I parse it as: "X" and "Y" value is "Z".  Did you mean "The values of X and Y are Z"?

Fixed.
I reworded a bit this part.


* Same problem on the next line, coupled with quoted inline equations again.

Fixed.


Sections 4.7.2 and 4.7.3:
* Same issue with quoted inline equations.

Fixed.


Section 7:
* Does the subtype intend to be case-sensitive?  i.e., couldn't "ffv1" work?

Fixed.


* Required parameters should be "N/A" if you have none to register.

Fixed.


* "This parameter is used to signal ..." -- to what is this referring?

TO DO.


Section 8:
* This can be merged with Section 7.

Fixed.


Section 9:
* Appendices go after the references.

TO DO.

Jérôme

--------------EBA04BB101B0CB8BB69062D8-- From nobody Wed Apr 29 18:51:51 2020 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 0CE853A0CB4 for ; Wed, 29 Apr 2020 18:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=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 MXmIG7UTRqYh for ; Wed, 29 Apr 2020 18:51:47 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 774B03A0CE3 for ; Wed, 29 Apr 2020 18:51:47 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id a7so1763121uak.2 for ; Wed, 29 Apr 2020 18:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tIDh8ylD1I+sGbVemk65KjWDEB0R8s/Po+x60ZDU8Jg=; b=Mp4Ycsetk1U5FHhvYDq3P7M4qc96Kp6ztnfQw1Zx09HSa2l4z0supNRtPZJQDvPkpp gfdVoNcOn260f0twBkgBBGLl32oxm1qUuyr3mmcmUUivRkzmRDGZi3swBK+ewa+74AaL T0+ZuON1PSpmbPifzcdg6hL5FdPIZvaUKnf5rXoDKtENrZpH5fnX9R9wTZkTxz+3C1Un igpIU5Cisr8qPipXFPSvJ0W+l2LpdL5J9C2FI9TuzxVRGvt09/VpcpdCUnaDky/VxNYU wicYrSxdOAZjzouMU1ciAdNWOrO536eBwgH8kJx5RiiJxT2RuaWjgyeqYur1oMbEKJcw LXNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tIDh8ylD1I+sGbVemk65KjWDEB0R8s/Po+x60ZDU8Jg=; b=OJItuI9HRG/jMBIpncMnKofIaXNQOT+gObwQQGvqQqvTLoy9wzyj+lYP9+wY1fZbMV etH0aHVLFIT95XUvBih6wpEzJygklMcE+LL4W8NrEUIly0kq0NIwDh+s+htZFikZE/yk VAJMhyRkqwft/6IjzNeOVV1CElsQMndNbNgVLxEL/cNdYwwzesSIY1RLCB7nIgzJYGc9 mO5r9Wu3gxqCbYvc88MvFi0PhmgaP13+FqXpA2T22LQB9aVN2Gx2ICAq/hbgMw4s1NKA 5I4+IlPC4I49SvijQUPPXaZjxX4G1xu4m5JPFk3vrQ8UTNddzOlcnbUw7QTO/1x3vSPy 0BYw== X-Gm-Message-State: AGi0PuYAnd+GnaE3APWJHMdxhgoE6HcuGzp2ZnlDDpZzn1c0dcQeQFDj O0/PTswqEk3NKAO4hk0IzzEqwk+kQWRrAhksPurPc59l2is= X-Google-Smtp-Source: APiQypIOpJhgVy0f6j0TkgjCRRevMFNGVPka8oUX5BItiZfCGEZXGuKWljdjcKFYHpeJGlJzVx9Akz0RMTdJUJsgW84= X-Received: by 2002:ab0:4503:: with SMTP id r3mr618117uar.101.1588211506290; Wed, 29 Apr 2020 18:51:46 -0700 (PDT) MIME-Version: 1.0 References: <6a5d91f3-e4b4-7238-3f59-c1f4064901a9@mediaarea.net> In-Reply-To: <6a5d91f3-e4b4-7238-3f59-c1f4064901a9@mediaarea.net> From: "Murray S. Kucherawy" Date: Wed, 29 Apr 2020 18:51:34 -0700 Message-ID: To: Jerome Martinez Cc: cellar@ietf.org, Adam Roach Content-Type: multipart/alternative; boundary="000000000000a9240805a4784e77" Archived-At: Subject: Re: [Cellar] draft-ietf-cellar-ffv1-13 comments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 01:51:50 -0000 --000000000000a9240805a4784e77 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 29, 2020 at 1:48 PM Jerome Martinez wrote: > Section 3.8.2.1.3: > * Same issue about "value". > > Murray, I didn't get it (no comma there) > Sorry, disregard. This referred to an issue I had with an earlier section but I changed my mind, and deleted that one but forgot to delete this one. > Section 4.2.3.1: > * "AVI " should be just "AVI" (i.e., remove the trailing space) > > Murray, the "trailing" space is required. It is a part of a 4-letter > identifier found in AVI files (0x41564920 in hexadecimal). > Interesting. You might want to make that clear, because I expect the RFC Editor will have exactly the same question. > Section 4.6: > * Another table with an empty "type" column. I think I see now that the > column is populated against each line that outputs something, but can it > not just be omitted when there's no output to the function? > > Same as with other tables. > > > * But does this function really output nothing? > > Murray, not sure I understand the question. > This function read nothing from the input, and call Line() which calls > Pixel(). > It is in a standalone pseudo-code block for an having blocks easy to > understand (SliceHeader(), SliceContent(), SliceHeader()). > SliceContent() could move into Slice() but IMO it is less readable. > This goes back to not understanding how to interpret these these "type" columns. But also, this is another place where a forward reference to Line() would be helpful. And then down in Line(), there are lines of pseudo-code that appear to be standalone array references. In the table in Section 4.1, those lines have types, which I thought means there's some output happening. Is that not the case here? If not, then this is a nested set f function calls that do some computation but don't appear to yield anything. That's why I'm confused here. Sections 4.6.1 through 4.6.4: > * Same comment as before about inline formulae. > > Fixed. > But it means that all is in one chapter, IMO it is a lot of formulae. > You don't have to put them all in one chapter. I was thinking of just this for 4.6.1, for example: "primary_color_count" is defined as: 1 + ( chroma_planes ? 2 : 0 ) + ( extra_plane ? 1 : 0 ) That even parses in C. :-) -MSK --000000000000a9240805a4784e77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 29, 2020 at 1:48 PM Jerome Ma= rtinez <jerome@mediaarea.net= > wrote:
=20 =20 =20
Section 3.8.2.1.3:
* Same issue about "value".

Murray, I didn't get it (no comma there)

=

Sorry, disregard.=C2=A0 This referre= d to an issue I had with an earlier section but I changed my mind, and dele= ted that one but forgot to delete this one.


Section 4.2.3= .1:
* "AVI " should be just "AVI" (i.e., r= emove the trailing space)

Murray, the "trailing" space is required. It is a part= of a 4-letter identifier found in AVI files (0x41564920 in hexadecimal).

Interesting.= =C2=A0 You might want to make that clear, because I expect the RFC Editor w= ill have exactly the same question.


Section 4.6:
* Another table with an empty "type" column.=C2= =A0 I think I see now that the column is populated against each line that outputs something, but can it not just be omitted when there's no output to the function?

Same as with other tables.


* But does this function really output nothing?

Murray, not sure I understand the question.
This function read nothing from the input, and call Line() which calls Pixel().
It is in a standalone pseudo-code block for an having blocks easy to understand (SliceHeader(), SliceContent(), SliceHeader()).
SliceContent() could move into Slice() but IMO it is less readable.


This goes back to not understanding how to interpret these these "t= ype" columns.=C2=A0 But also, this is another place where a forward re= ference to Line() would be helpful.=C2=A0 And then down in Line(), there ar= e lines of pseudo-code that appear to be standalone array references.=C2=A0= In the table in Section 4.1, those lines have types, which I thought means= there's some output happening.=C2=A0 Is that not the case here?=C2=A0 = If not, then this is a nested set f function calls that do some computation= but don't appear to yield anything.=C2=A0 That's why I'm confu= sed here.

Sections 4.6.1 through 4.6.4:
* Same comment as before about inline formulae.

Fixed.
But it means that all is in one chapter, IMO it is a lot of formulae.

You don'= t have to put them all in one chapter. =C2=A0 I was thinking of just this f= or 4.6.1, for example:

"primary_co=
lor_count" is defined as:

    1 + ( chroma_planes ? 2 : 0 ) + (=
 extra_plane ? 1 : 0 )

That even parses in C. :-)

-MSK
--000000000000a9240805a4784e77--