From nobody Sun Nov 3 01:50:36 2019 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 871211200FE for ; Sun, 3 Nov 2019 01:50:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cxz615nJ_mTN for ; Sun, 3 Nov 2019 01:50:31 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 C2B611200F6 for ; Sun, 3 Nov 2019 01:50:31 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id w8so6275341plq.5 for ; Sun, 03 Nov 2019 01:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wKSUgt7uwqZQ4M2NAk2LOn0cW4F6Tkoh4K/YsnPonhI=; b=hOFE1c55Bb76SH7t9IQFdrD4Zmy7b/9YWYg2TlGbDaNQOe8oLEI65OCWxXtbjpklk5 tksVnydW1BiVF5eVVBYHUbQASmXsZeeSsvvsNwFZIupR/jwGsNeJTp1wHHLresF+muTg utFtdlgGgF8enJf2B8gW+nj192H6aFY01c58caU3reLOJOUQ0oTSVVb/18unoVvq8Tmf PZDzBQ9j58A3FmJI3kbtTDolMmRc5FCGmLbiW//lP0qBGGMc0T6U3kYncoxucVIe61f0 6pzTTaGiFeXlmhP9D3xFdwONerq0rfnvGqhAV79RuBXmNo+faG5u/8mLvkQw6K8Dfmxr l1bA== 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=wKSUgt7uwqZQ4M2NAk2LOn0cW4F6Tkoh4K/YsnPonhI=; b=M9bmGGq09fUfDsEJap4ft8JiXfcfjV/88/FEPDRudeO26wiuCMv4dCn8fF1VKiXazj qB9k1SM4mIAikF+guI1Mtf6WoHCzuLgEIMI2g4rIsWZgj7Z3+Tz+holsumlbeBJMuJdw UvIaL0/adbbybo4HRg/OWJxtDLi06K+dew4M6+yZvMr7vmIwhk3oVIuV/szJx4fUpdh9 ayCoZsJTQ1XkuRE7nHdBFgzEjQuFksi9O3zRLyQQs9S6dEkEEMsvQVhmOtokMrCgfe+3 kT6Ktu+knsfkbQLErGlfGjJX2mxZE3qyxe+4UH+TitfaIdmpOqoA555eGjv1HA3/yEWB oDGg== X-Gm-Message-State: APjAAAUL98CfYzXacCc0CA985DuBAS4kPQoGXWpBdMTRmklzj/70S8Bz XPWnwIPV26hKKHzsRfqLA/8DWe30Ef57JymUE9ZrXuzjuNU= X-Google-Smtp-Source: APXvYqwD5NYS8YXScyGn5yDp6VPpvEWSBrlZz9QcCXLwW4MjOKNOM1AqPL2R73gOkRXC6wGpErhEPOwaHFsz/2nsisc= X-Received: by 2002:a17:902:a70f:: with SMTP id w15mr1878432plq.263.1572771031106; Sun, 03 Nov 2019 01:50:31 -0700 (PDT) MIME-Version: 1.0 References: <157186355833.28271.8611443938125504097@ietfa.amsl.com> <5926.1571868060@localhost> In-Reply-To: <5926.1571868060@localhost> From: Steve Lhomme Date: Sun, 3 Nov 2019 09:50:20 +0100 Message-ID: To: Michael Richardson Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-12-10 CHANGED 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, 03 Nov 2019 08:50:34 -0000 Le jeu. 24 oct. 2019 =C3=A0 00:01, Michael Richardson a =C3=A9crit : > > > IESG Secretary wrote: > > The Codec Encoding for LossLess Archiving and Realtime transmission > > (cellar) Working Group will hold > > a virtual interim meeting on 2019-12-10 from 21:00 to 22:00 > > Europe/Paris. > > Note 9pm Paris, which should be the same local time as it is now, right? Yes, that's the proper time. From nobody Sun Nov 3 02:04:44 2019 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 6E4441200FD for ; Sun, 3 Nov 2019 02:04:43 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjqdCo-vS_oW for ; Sun, 3 Nov 2019 02:04:41 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 C71BC120104 for ; Sun, 3 Nov 2019 02:04:41 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id 3so10125729pfb.10 for ; Sun, 03 Nov 2019 02:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XPCMiWD6Ww2i7jy8FFTPZwgGtL/D8REZoQJ4pCeBPb8=; b=cfCQa8X5QBNeFEEE7Klribk091DPfoL315vB6HyzYVnRrLigs5azGB5+QrO2qVYjlj uefx/vMwi9R011DH2l8uwEYiFIgL7tVL9zdu9mZbrRoLCaFKqYwtXrqgp9KTRaVh7xXo QNLOVo8/xTudUsKaAnigZShPJrPzWIwcf/NphX1hIlM76Y4k525HsZKkv/4c+pINpsyY A1LmkEtIiKRR7s5Po38puVq0hU0ZBbfnselSpHc49Pz8jagv7XHHiohVkEli1kEGxQEF vvMRgLBiMZKhx8e/FUKw55K6lSaV6TImwHQaP2fSonfTZwaMjQnA2MjL8kbacu24l9mw sTIA== 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=XPCMiWD6Ww2i7jy8FFTPZwgGtL/D8REZoQJ4pCeBPb8=; b=efx/hYJU2RpVmYPHTA6Pm9tTZDWlHL6rn7eoihfXp38n6J8CZmwvH4d6EMyER5aZug t8SR0oaq4Q7nT8OVsJe3JXFU+fSO1PSzdeZdR7Fxy5nwEftJHfWZlsnDLAie9cNkSKwI TvcPDfJbtsq85RIWD+1V/DzMpASBdhNMqxmt7vpD2+sxRKKS092oWfAbkEuTyBFsOb/6 Y5/8qzLNGj6mHwyFWt4dcYsKjuB7ZRP3lEj1o0eoP3WegXZo4KhM67XHK0IVj9Yc1J+K 0tg2w7DaPLbX3gvJM2eW51AseA2onJw1iUuhIbYVeOiazwxohESoduFPpsB5/HnbH/mJ rsSg== X-Gm-Message-State: APjAAAU/+sXlmFRyJ4v/G04Iebq0e+TA0/qQrqlWcA7NcpxKjXlrw54R 2sNyziVzHp/HSoDEKHFeapcbtjdo/mpEG5UhyKvnnA== X-Google-Smtp-Source: APXvYqwoLMQvVyumparGQiMibQnrj9YqrYqbOjT392DAQ++m1O7JPjMf785BokiT6F1OqvpmVqPpIAtg6ua4S/8tR4w= X-Received: by 2002:a17:90a:eac4:: with SMTP id ev4mr28303364pjb.103.1572775481181; Sun, 03 Nov 2019 02:04:41 -0800 (PST) MIME-Version: 1.0 References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> <26528.1571940866@localhost> In-Reply-To: From: Steve Lhomme Date: Sun, 3 Nov 2019 11:04:30 +0100 Message-ID: To: Alexey Melnikov Cc: Michael Richardson , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Second AD review of draft-ietf-cellar-ebml-10 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, 03 Nov 2019 10:04:43 -0000 Hi, Le ven. 25 oct. 2019 =C3=A0 17:37, Alexey Melnikov = a =C3=A9crit : > > Hi Michael, > > On Thu, Oct 24, 2019, at 7:14 PM, Michael Richardson wrote: > > > > Alexey Melnikov wrote: > > >> A decision as to who is the legitimate documentator of the (exis= ting) > > >> "webm" DocType would be up to the IESG. > > > > > Is "webm" will be worked on in this WG? > > > > No, not unless Google shows up with it! > > WebM shares a container format with Matroska (being EBML), but we are n= ot > > trying standard it. > > So the IANA policy for this entry would be IESG Approval or RFC Required.= Why do you want IESG to be involved in the decision to remove "Reserved" f= or "webm"? I would rather have Expert Review here, so that IESG doesn't nee= d to decide. I'm not sure I understand the distinction between the two. The goal here is to inform creators of an EBML format that "matroska" and "webm" are known to be used elsewhere. > If the WG has good reasons for IESG to be involved, that is fine. But I w= ould like to understand the reason(s) first. > > > Also, I just realized that the IANA registration policy for "ELLAR EBML D= ocType Registry" is not very clear. Does the WG want "IESG Approval" or "RF= C Required" be applied to the whole registry or just to the 2 reserved valu= es? The current text seems to be saying the latter. > > Best Regards, > Alexey > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Nov 3 02:29:49 2019 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 85AE8120108 for ; Sun, 3 Nov 2019 02:29:48 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGvX64ikoNTR for ; Sun, 3 Nov 2019 02:29:46 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 E926A1200FD for ; Sun, 3 Nov 2019 02:29:45 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id z24so4813677pgu.4 for ; Sun, 03 Nov 2019 02:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iMihK/lXojBGpYuEtbXlNndeU8u/zpS5ae2TZSlTrlc=; b=EhJOScZs0o7kV2LgXK2uBF1zQoBwAfi8jCXApdiQIogmqc1FRaWiTYsh8G9ZXTiBbo htZGDnaEMxrM03b191GzMDfdu2v98+dmfbiqj4Snz01tWaDP4IgQ+DnYd37MHnobrWX6 uouEezwp7sqsZKgop3udsIgCFHMCgKORIwUNTTYlf5mUXTEFF/OAmVr3IExHZF0yyB5s 3ztXsRk9/LDGE+Vg+2dOsgnQ+ZKaB0uxyQpn42CDn9vfW5zuOMtgtakzsKlv4ZDqYvK7 1Iec91i1y+d+PAleD9u3aJZdyynxUldC4tkKZMA4M3thcF1hpD0aASR1KEYrHOgcfDYh +1AA== 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=iMihK/lXojBGpYuEtbXlNndeU8u/zpS5ae2TZSlTrlc=; b=Th7Zbjv418jBtuBTXXcv9dGI7MM1z9WbScvwJrWgXsfW9fTcHoLNaEVxCdBS2Q15Nu 1D2UuO4ywVGdWG4rxv4zTYRywDDOiEoq3zZK/IQ02QI0GqsELxbk36+TAsgixObzhDSI 5GI6P4hCoTi3BRhDkQEqW9RoRubR4pQviGPnyVEcRKKifm7VYjkXX0xtuD2q/LtmBntZ tccuZ8KdZjQK2r6CCyT8RmyHq9Mo5qfwJuBjSqsEpDhJOF0lRx/PmHYuC8x8wgn2DkD6 DUrL7AEJiTqOLrv43XzAUkQ5K5JyYwGOTjos7r4hy9rKsYNN7cjxlLBwYc5hze2BJLf9 MKCA== X-Gm-Message-State: APjAAAW4rlPosK+pTHgtsU/i2WHJGitjsR8rO9BK6YUpoSsrxda9HgO7 r0GuNAwG5ylw3R1jDb+QRldIhZ5B1oBwWZzXL93K8ItHB3k= X-Google-Smtp-Source: APXvYqwTxHdlkCmYlzeAWuhY7Jqk6PGpBpIE34SdqX8As4YViG9jIEevJguSsWD8eDP/HeD8p7G5SM7O1OgPi08retg= X-Received: by 2002:a17:90a:eac8:: with SMTP id ev8mr27470670pjb.99.1572776985267; Sun, 03 Nov 2019 02:29:45 -0800 (PST) MIME-Version: 1.0 References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> In-Reply-To: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> From: Steve Lhomme Date: Sun, 3 Nov 2019 11:29:34 +0100 Message-ID: To: Dave Rice Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] matroska and side data vs timecode 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, 03 Nov 2019 10:29:48 -0000 Le mar. 29 oct. 2019 =C3=A0 17:04, Dave Rice a =C3=A9cri= t : > I drafted a pull request at https://github.com/cellar-wg/matroska-specifi= cation/pull/348 that builds upon the new side data structure defined above.= This pull request registers a BlockAddIDType for a 64 bit binary expressio= n of timecode as defined by SMPTE ST12-1:2014 (which is mostly hours, minut= es, seconds, frames, a drop frame flag, and other a few other flags and bin= ary groups). This would allow timecode to be associated with Matroska frame= s such as: > > > > > > > > 2 > SMPTE ST 12-1 timecode > 121 > > > > > > { a video frame } > > > 2 > { SMPTE ST12-1:2014 64-bit binary representation o= f a 07:32:54;18 } > > > > > { the next video frame } > > > 2 > { SMPTE ST12-1:2014 64-bit binary representation o= f a 07:32:54;19 } > > > > > > > With the BlockAdditions, BlockMore, BlockAddID, and BlockAdditional Eleme= nts, I think this would add 18 bytes per timecode expression. Adding timeco= de to one hour of PAL video (25 frames * 3600 seconds/hour) would add about= 1.5 MB to the file. That seems like a big overhead. Is the 64 bits value necessary ? It seems 32 bits might be sufficient (saving 4 bytes). Maybe 40 if you need extra flags. > Implementation Considerations: > > Thinking ahead of this work, I think it would be worthwhile to add a dedi= cated section to the Matroska specification on timecode and describe two me= thods for adding a reference timecode to a Matroska Segment. > > 1. Using tags. Make an official tag =E2=80=9CTIMECODE=E2=80=9D to store a= string of the timecode expression that correlates to the Matroska timestam= p of 0. This approach is limited to storing timecode that is incremental an= d continuous. Defaults for the incrementation and the behavior of the timec= ode could be described as part of the tag definitions and feasibly another = tag or tags could be reserved for timecode flags when the timecode behavior= is not a default. Defining a use of a =E2=80=9CTIMECODE=E2=80=9D tag would= provide the benefit of standardizing an existing practice in FFmpeg=E2=80= =99s Matroska muxer, where rewrapping from a timecode-supportive format to = Matroska carries the timecode value over as a tag. In general I'm not in favor of using tags for data that may be needed when remuxing, especially tied to a timestamp (yes, I mean timestamp). If the first frame is damaged, does the timecode apply to the second frame ? If the first frame timestamp wasn't 0, how do you know the difference you have to apply ? If you want something that will survive this scenario you have to tie this value to the first timestamp. When remuxing, if timestamps are altered of portions at the beginning of the file are removed, you need to edit the first timecode. It may be better to store in the TrackInfo with both the first timestamp and timecode values. It may not work when stripping the audio (as Tobias pointed out). So it may even be put in the SegmentInfo instead of the TrackInfo. You may also set the value in Chapters (which are not tied to a track). There's already a start timestamp. You could add the timecode for this timestamp. That works for NLE sources as well, each non-linear part would be a chapter with its timestamp translation. A good NLE system would also tag this chapter with all kinds of data about the source. (Matroska was also designed for this case in mind). > 2. Using BlockAdditions as described above. This adds more overhead as ea= ch timecode value would be written, but would support non-continuous timeco= de. In FFmpeg, timecode is sometimes carried as side-data such as from the = decklink device via https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/0946c0e= c177dc48ef0677f890aa42d95e667c417. I=E2=80=99d be interested if the Block A= ddition Mapping described above could be used to carry the timecode side da= ta from the decklink device (or other incoming stream with timecode side da= ta) and store the result within the written Matroska BlockGroups. That's the no-brainer option. It just works. It's just less optimal that one value (or a few for NLE sources). > Comments welcome. > > Thanks much, > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Nov 3 02:59:49 2019 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 C13C7120110 for ; Sun, 3 Nov 2019 02:59:46 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 WSSqHXf-mXQv for ; Sun, 3 Nov 2019 02:59:44 -0800 (PST) Received: from 12.mo7.mail-out.ovh.net (12.mo7.mail-out.ovh.net [178.33.107.167]) (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 3E0191200E5 for ; Sun, 3 Nov 2019 02:59:43 -0800 (PST) Received: from player693.ha.ovh.net (unknown [10.108.35.215]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 1256A136A63 for ; Sun, 3 Nov 2019 11:59:41 +0100 (CET) Received: from mediaarea.net (p548F9A0D.dip0.t-ipconnect.de [84.143.154.13]) (Authenticated sender: jerome@mediaarea.net) by player693.ha.ovh.net (Postfix) with ESMTPSA id 22F3CBA5DAF5 for ; Sun, 3 Nov 2019 10:59:41 +0000 (UTC) To: cellar@ietf.org References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> From: Jerome Martinez Message-ID: <3f63d94f-9507-ee67-ccfe-6b85d7a523fb@mediaarea.net> Date: Sun, 3 Nov 2019 11:59:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 12906472110578339985 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrudduuddgvdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenuc Archived-At: Subject: Re: [Cellar] matroska and side data vs timecode 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, 03 Nov 2019 10:59:47 -0000 On 03/11/2019 11:29, Steve Lhomme wrote: > That seems like a big overhead. Is the 64 bits value necessary ? It > seems 32 bits might be sufficient (saving 4 bytes). Maybe 40 if you > need extra flags. Advantage here is that we use a standardized and a lot used (in some domains) time code format, which can also be a direct dump from some sources, and it includes other data (color flag, binary group flags which can contain extra info etc), and could be exported to a SMPTE ST 12 aware equipment without adaptation. Other formats of time code, e.g. configuration (start time code, drop frame, frame rate...) in track header then a 32-bit number for each frame, could be implemented, but IMO it is just another format, independent. Both SMPTE ST 12 and a single number could be implemented, just different purposes/goals. Also sometimes the conversion from SMPTE ST 12 to other time code formats may be not lossless if you use just a number ("buggy" input with different drop frame info etc, differences would be lost). In summary, both SMPTE ST 12 and just a number can work for time codes, but they have different goals, and one would not totally replace the other, just 2 "competing" formats. > In general I'm not in favor of using tags for data that may be needed > when remuxing, especially tied to a timestamp (yes, I mean timestamp). > If the first frame is damaged, does the timecode apply to the second > frame ? If the first frame timestamp wasn't 0, how do you know the > difference you have to apply ? Advantage here is the simplicity of the implementation, and also informing bout what is already done in tools e.g. FFmpeg. Not bullet proof but often good enough. [...] Jérôme From nobody Sun Nov 3 03:07:23 2019 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 DBA8112004C for ; Sun, 3 Nov 2019 03:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 Y52JrojdPxRh for ; Sun, 3 Nov 2019 03:07:20 -0800 (PST) Received: from 20.mo3.mail-out.ovh.net (20.mo3.mail-out.ovh.net [178.33.47.94]) (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 90988120019 for ; Sun, 3 Nov 2019 03:07:20 -0800 (PST) Received: from player688.ha.ovh.net (unknown [10.109.160.143]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id 2B4D322C930 for ; Sun, 3 Nov 2019 12:07:17 +0100 (CET) Received: from mediaarea.net (p548F9A0D.dip0.t-ipconnect.de [84.143.154.13]) (Authenticated sender: jerome@mediaarea.net) by player688.ha.ovh.net (Postfix) with ESMTPSA id 521C1B984155 for ; Sun, 3 Nov 2019 11:07:17 +0000 (UTC) To: cellar@ietf.org References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> <40b8c32e-9136-af70-e844-b9e9f2e1c75a@gmail.com> <6cd23d59-f9d7-0ab8-3a0d-729f9f106de7@noa-archive.com> From: Jerome Martinez Message-ID: <2e267cc1-f764-ced1-3d17-6e46819a8f72@mediaarea.net> Date: Sun, 3 Nov 2019 12:07:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <6cd23d59-f9d7-0ab8-3a0d-729f9f106de7@noa-archive.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Ovh-Tracer-Id: 13034824698179555473 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrudduuddgvdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenuc Archived-At: Subject: Re: [Cellar] matroska and side data vs timecode 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, 03 Nov 2019 11:07:22 -0000 On 30/10/2019 17:28, Tobias Rapp wrote: > [...] Thus I think it would be better to store timecode data as a > separate track, similar to how it could be done in MOV. Both methods have pro and cons. Lot of MOV time codes are linked to a video track, so side data may make sense here, as something we could transmux easily (with slightly less container overhead than a dedicated track). So maybe we should permit both (SMPTE ST 12 in either side data or dedicated track). From nobody Sun Nov 3 05:44:44 2019 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 31DF31200EC for ; Sun, 3 Nov 2019 05:44:42 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co8pRxhAYk1d for ; Sun, 3 Nov 2019 05:44:39 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 D77A1120089 for ; Sun, 3 Nov 2019 05:44:39 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id q26so10328557pfn.11 for ; Sun, 03 Nov 2019 05:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xRWBdm6PaYg3C4VvkY36T3GvqdoO6+OvwyIKXAEWQRA=; b=g5KFDUbA6yn8oferPBwtPZGqYQVWK4ujkncseCj6qnG+8XPEa3TZce/cs606bppcj7 V0A21fV/TxAyZ3bS59a/0kTEZG62hPrfyGbRtdW5O+EkycF7UbP8fnPz5KDjdKzXn0yQ 1C+HcJ2UAfuNjWth/eev+nUK6glw6ayIQd0k7NF2aqFwgLN42bSV+YP94kGINsBnJJy9 TdDx6jzXPxmWE6/e/DBP+oNtIJ7hSfmMy7Vy0BVXgB5UTnU9a6uyaasUEdiDmDDSPIPG wkbnZH33dc8HTcBW59iM9CcQmt2/0bxw1DgGs9VRM8aeEYvmje/iSDUbsSXdsTyynCaO Hs/Q== 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=xRWBdm6PaYg3C4VvkY36T3GvqdoO6+OvwyIKXAEWQRA=; b=QvYn1HHqdAV6cZS+wrrYfWSR2Y2oI9Ue51Y85ivu3RAbI2dUdzC4VTQraAd1O82lQ5 pWcConSiXS27W3cu6/kgFKb/qm9yTeZbCKuYn2D11QMLx5EG4z5raQpfPdhIb5DxRuR+ M6rSAaoRE0sdo223BXUjjvoKBwhEip1SRhpIvbaLgxxM1Df5NjpNzRZUQm/3n1xi6yLj WqdhHLKOcvtu7fF3V09NnTtCReq+AnBRXeTgzQNWwWiTHIRYdVuXkfGpPm80uWoKU/dy +NSCCYyS86GufutudaZYBvt+oOdYsk1pBK/javPZRcbycahKOqyn7DDqW/Wamuz6VWfl vf7Q== X-Gm-Message-State: APjAAAWxWtAdnvoFAcCFIk1v7N+hp/ij8WHm+XaNLykdebArpMkhJidc lYNwBvoTD197Ip2EJ3WmrL4JnvI1Nuu/hu55a1UzY9G2kI0= X-Google-Smtp-Source: APXvYqyevcpUZ2Y3zUjbd8CqB6YHGZ+mh5Jezk24i0Tk7nak9N/8+DRn0TuTdizy+aZ1Xcjjb3F7DlTvVYnIvO7WyGI= X-Received: by 2002:a63:8148:: with SMTP id t69mr25342481pgd.160.1572788679087; Sun, 03 Nov 2019 05:44:39 -0800 (PST) MIME-Version: 1.0 References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> <3f63d94f-9507-ee67-ccfe-6b85d7a523fb@mediaarea.net> In-Reply-To: <3f63d94f-9507-ee67-ccfe-6b85d7a523fb@mediaarea.net> From: Steve Lhomme Date: Sun, 3 Nov 2019 14:44:27 +0100 Message-ID: To: Jerome Martinez Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] matroska and side data vs timecode 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, 03 Nov 2019 13:44:42 -0000 Le dim. 3 nov. 2019 =C3=A0 11:59, Jerome Martinez a = =C3=A9crit : > > On 03/11/2019 11:29, Steve Lhomme wrote: > > That seems like a big overhead. Is the 64 bits value necessary ? It > > seems 32 bits might be sufficient (saving 4 bytes). Maybe 40 if you > > need extra flags. > > Advantage here is that we use a standardized and a lot used (in some > domains) time code format, which can also be a direct dump from some > sources, and it includes other data (color flag, binary group flags > which can contain extra info etc), and could be exported to a SMPTE ST > 12 aware equipment without adaptation. > > Other formats of time code, e.g. configuration (start time code, drop > frame, frame rate...) in track header then a 32-bit number for each > frame, could be implemented, but IMO it is just another format, > independent. Both SMPTE ST 12 and a single number could be implemented, > just different purposes/goals. Also sometimes the conversion from SMPTE > ST 12 to other time code formats may be not lossless if you use just a > number ("buggy" input with different drop frame info etc, differences > would be lost). > > In summary, both SMPTE ST 12 and just a number can work for time codes, > but they have different goals, and one would not totally replace the > other, just 2 "competing" formats. Yes, IMO they are different timecode "codecs" (COder/DECoder). There could also be string versions, I don't know if that's common. That's also why I'd rather have a separate document for such "codecs". It's the same with video/audio/spu codecs and chapter codecs should do the same. It all depends on what solution(s) we end up with. If there's something in the SegmentInfo or TrackInfo then we have to define it in the main document. From nobody Sun Nov 3 09:33:50 2019 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 11B5712006B for ; Sun, 3 Nov 2019 09:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 W51s3FlO9EDk for ; Sun, 3 Nov 2019 09:33:45 -0800 (PST) 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 E2106120018 for ; Sun, 3 Nov 2019 09:33:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D53883897A; Sun, 3 Nov 2019 12:30:51 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BAB9DAAD; Sun, 3 Nov 2019 12:33:42 -0500 (EST) From: Michael Richardson To: Alexey Melnikov , Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> <26528.1571940866@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Second AD review of draft-ietf-cellar-ebml-10 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, 03 Nov 2019 17:33:48 -0000 --=-=-= Content-Type: text/plain >> > Alexey Melnikov wrote: >> > >> A decision as to who is the legitimate documentator of the (existing) >> > >> "webm" DocType would be up to the IESG. >> > >> > > Is "webm" will be worked on in this WG? mcr> No, not unless Google shows up with it! mcr> WebM shares a container format with Matroska (being EBML), but we are not mcr> trying standard it. Alexey> So the IANA policy for this entry would be IESG Approval or RFC Alexey> Required. Why do you want IESG to be involved in the decision to Alexey> remove "Reserved" for "webm"? I would rather have Expert Review Alexey> here, so that IESG doesn't need to decide. So, we went back and forth with IANA on this. While the policy for names other than "webm" and "matroska" is First Come First Served. However, we have reserved the two names as already being in use. "matroska" is within the CELLAR WG already (by IESG decree, when you chartered the WG...) We could use Expert Review. IANA suggested it be under the control of the IESG to determine if some work arrived which properly represented "webm" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2/D3YACgkQgItw+93Q 3WURrQgAg7sWVyQSsB+f18Q5QZUdHdBmmcc8a+9OZ8cxdHHYrq07DHOeBXeeiTVr +7HXjBdegF4/z4aLqaSOBQGmEP7FZlhTgHhe5C/9rQ8NyVmX/uzOyf3Dr5JMyMJA NqcYwoB72KTlRpglEqXSiHi+18qGT5wsvdp14HDNrsRt9I2BhfqGuub4TFYXxpI8 E2hhR16mFWn5Dtt6Co3nOLmSi/02EI/K9+GEoNB809tDnD+shvPUQN5toNhSYnlL +Th8UrkYQ6uzHOoZ4Nw3aaeYYd+/mb/olPV7JeflqeQpGF9h7GJ+JKEU2MniFswD Co9VhBZJJCA8XTv+uISzbvTe7DhojA== =77xb -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 3 09:51:59 2019 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 B740F12008F for ; Sun, 3 Nov 2019 09:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3J-NBG6crlhK for ; Sun, 3 Nov 2019 09:51:55 -0800 (PST) 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 9A99B120018 for ; Sun, 3 Nov 2019 09:51:54 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 00EB83897A; Sun, 3 Nov 2019 12:49:02 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DD83CAAD; Sun, 3 Nov 2019 12:51:53 -0500 (EST) From: Michael Richardson to: Alexey Melnikov , Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: <27826.1572802422@localhost> References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> <26528.1571940866@localhost> <27826.1572802422@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Second AD review of draft-ietf-cellar-ebml-10 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, 03 Nov 2019 17:51:58 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > So, we went back and forth with IANA on this. It's IANA ticket #1124191 and #1130813. https://mailarchive.ietf.org/arch/msg/cellar/603pCXiKGp-8k8eo1xHN17pt5ik -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2/E7kACgkQgItw+93Q 3WWzPQf9E2Z3EhGoxfDhta+xiwByPGtnwOJEq3lkzWUiAAnIY4MjjwyE6Np9o+6Y u4BYyZeTUPaWXEGPh3GFOBM1JeJqWtdWNfYUxSfdVt6pjTiriWdMSZGy1xUURD+e s/Oko5txdjfIHhI8BXQvWoAWoWccSeMx/MyAKptqsaJLbhyfT+jARAjybY4abGx+ xxPcB+JZJ+7+iJAQA4XqvEUVgSNX9WBHE5Ld67zLb/yjJF+zfv087UTvMb7ai+w6 JTV7wtbOtaNSz63kKfljWzRKMgqY3wedjPNldteJvawBbWf9U2SeJflc75ISfG+h j3E7Xw3DFp/cyqnw5u+fBUGidXRcDw== =pi1o -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 4 00:17:45 2019 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 69E071208CE for ; Mon, 4 Nov 2019 00:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=UXyKfaVW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NzDhgi8v 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 vX4wuXd_Gpw8 for ; Mon, 4 Nov 2019 00:17:42 -0800 (PST) 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 A59B9120894 for ; Mon, 4 Nov 2019 00:17:42 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 109F121E3E; Mon, 4 Nov 2019 03:17:42 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 04 Nov 2019 03:17:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=t AmWN4X3TMgsSc/P4LdZGX3KquRJCOsVrxEMxcOWdDo=; b=UXyKfaVWieOen1aEg 48xDA0rggUckKd/Si8euKfYWr1aLtS3sj+M74+s9i19tXPBhaLxIs5S3rPNZ/RHU uV8jFNiIwpQJLPuS0Ap/r53vLnbUHXDf8HOQyKZCtY8GWQaSWoPd5GTKzlMKqkN9 We1ht1YEwxut6sXTu3CgKJOuxlU8hGJsh+gLy5MGaIZn7ufdjufX5ha6CBBZ6G/y HoMx4iFkSIK92OVZ+k+cFyKyW+gzhZkr4187NrgRpP14Cs21hACIeN208+1HM7R6 51HywdJE21zo6utwQJu7za7xM+I1Rykvg9jJOyzXb8wAwgYuIrvdqEK7eimLv6Hy NvMEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=tAmWN4X3TMgsSc/P4LdZGX3KquRJCOsVrxEMxcOWd Do=; b=NzDhgi8v51MUNqu++3w0TlwHKE0/C8NVOXh8qPuv97gTEdZQ2NQJ0tIWS Om0x/pKcU3lpIt6TGlEGZQgxtFwz02iOgertCTySdHGcMDO9p96eDFa5PP5qRQVd kF9vO/gyGLznqxha0qE5OtOyHLynKdco8OkgQlzvUaEcoX07q1sOO7xyxPTfKa7c q3SQMmu8JS17zEfMnJ8F/KFx2biMa6C9ZskyER4p+/A6MglQ+kxcx5ecev/CJiAD OcrimyfTFUXXDeYQBXXzcVUaNeqnMtY1ysvu1Yw+6gWbdmTRyheT0+DHJO9I4R/x 0P08aC1tOrGXmvLu0aAGAiX8WXJ3A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduvddgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhffojgffgffkfhfvsehtqhhmtdhhtdejnecuhfhrohhmpeetlhgv gigvhicuofgvlhhnihhkohhvuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucfkphepledvrdegtddrvdegkedrvddtkeenucfrrghrrghmpehmrghilhhfrhho mheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhmnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: Received: from [10.175.156.150] (92.40.248.208.threembb.co.uk [92.40.248.208]) by mail.messagingengine.com (Postfix) with ESMTPA id 98D7B3060057; Mon, 4 Nov 2019 03:17:41 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (16G102) In-Reply-To: Date: Mon, 4 Nov 2019 08:17:40 +0000 Cc: Michael Richardson , Codec Encoding for LossLess Archiving and Realtime transmission Content-Transfer-Encoding: quoted-printable Message-Id: References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> <26528.1571940866@localhost> To: Steve Lhomme Archived-At: Subject: Re: [Cellar] Second AD review of draft-ietf-cellar-ebml-10 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, 04 Nov 2019 08:17:44 -0000 Hi Steve, > On 3 Nov 2019, at 10:04, Steve Lhomme wrote: >=20 > Hi, >=20 >> Le ven. 25 oct. 2019 =C3=A0 17:37, Alexey Melnikov a =C3=A9crit : >>=20 >> Hi Michael, >>=20 >>> On Thu, Oct 24, 2019, at 7:14 PM, Michael Richardson wrote: >>>=20 >>> Alexey Melnikov wrote: >>>>> A decision as to who is the legitimate documentator of the (existing) >>>>> "webm" DocType would be up to the IESG. >>>=20 >>>> Is "webm" will be worked on in this WG? >>>=20 >>> No, not unless Google shows up with it! >>> WebM shares a container format with Matroska (being EBML), but we are no= t >>> trying standard it. >>=20 >> So the IANA policy for this entry would be IESG Approval or RFC Required.= Why do you want IESG to be involved in the decision to remove "Reserved" fo= r "webm"? I would rather have Expert Review here, so that IESG doesn't need t= o decide. >=20 > I'm not sure I understand the distinction between the two. The goal > here is to inform creators of an EBML format that "matroska" and > "webm" are known to be used elsewhere. The draft reserves 2 names, which is fine. The question is who is going to b= e authorized to change these reservations into proper registrations. The difference between IESG Approval and Expert Review is who is going to de= cide to mark an IANA registration entry as properly registered. IESG is a co= llection of 15 people, whose membership partially changes every year. Curren= t IESG knows almost nothing about EBML. An appointed Expert would have more c= ontext to make a decision. So I think it makes sense for an Expert to handle= this, instead of overloading IESG. (Maybe the following analogy would help: asking IESG is like asking a Board o= f Directors to make a technical direction. While IESG is ultimately responsi= ble for the decision, it would prefer to delegate the decision to technical e= xperts.) Does this make sense? Best Regards, Alexey >=20 >> If the WG has good reasons for IESG to be involved, that is fine. But I w= ould like to understand the reason(s) first. >>=20 >>=20 >> Also, I just realized that the IANA registration policy for "ELLAR EBML D= ocType Registry" is not very clear. Does the WG want "IESG Approval" or "RFC= Required" be applied to the whole registry or just to the 2 reserved values= ? The current text seems to be saying the latter. >>=20 >> Best Regards, >> Alexey From nobody Mon Nov 4 00:20:28 2019 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 E66701209B6 for ; Mon, 4 Nov 2019 00:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=renYiIB0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=brkV502+ 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 Bns2sPdmmTrA for ; Mon, 4 Nov 2019 00:20:15 -0800 (PST) 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 B75121209DB for ; Mon, 4 Nov 2019 00:20:14 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0B2BB21BF7; Mon, 4 Nov 2019 03:20:13 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 04 Nov 2019 03:20:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=Q NJwbN3GL6Sk1iAae2hIctxFGes1mSVtY09tokfNq9A=; b=renYiIB0NjxybMupv 1Li4+Nw8OdkimeOUYYZsEH3t8jpE5oBypkXcKVQ0Hid0rUORZUSM2iQXhbq2kI70 0aEGB5gloQN7I3RZpG8PF84WYBnUqoZwvvouUip5xCEV6JXLpWd2AbX6z2Czp4WG 0a61oBXuUNesH+2kqbVJ13gYwN8sR8Yx6sAexmlbcOMDHsE/lEHmAhoG1IbN5QZ9 iSv5+iyn+Gb/LRLlp3Dk6LDx5qXMA9UXBj8GNrq56VwCTEUft7NuxWvx9EMpvT10 JZNylploILN5mwyV0vo4lEt8mY16sGxUPHBXKf5CFb/LVc/FVv6SSo0yHU+NHzu7 YLvrg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=QNJwbN3GL6Sk1iAae2hIctxFGes1mSVtY09tokfNq 9A=; b=brkV502+cYUPRO2NfDFuRfob2fwmOhZaKmTOr1qbqA/4AOVJHRGujCqoJ mWFE7PJp8+kx8VK74Kc6GTQ+b6QJ+bfWBfRluE+6qvFFq8i2R3hUCfMsje7TBFXF ZHi+glf1oXscPNgNRAW9EZ50vuRwGbkJKonTFogV00v1u78R2/LBxsVe2Gn4maKx JOJ/U4lG5IuEV+o+L4x8smdg8WF5+GdUc1zpQ/4eoFF0mDG6tgGemRGUGY5yADSB UwiDmxp2YUtl4Iox5UanLTYU/z2h5ch13kyQtGZednMv5oMHKzzfaeSwD/SpEN24 v+00TJaKdPHBTfrIIqZ1wi1pfXsFQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduvddgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhofgjfffgkfhfvfesth hqmhdthhdtvdenucfhrhhomheptehlvgigvgihucfovghlnhhikhhovhcuoegrrghmvghl nhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecukfhppeelvddrgedtrddvgeekrddvtd eknecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgr ihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [10.175.156.150] (92.40.248.208.threembb.co.uk [92.40.248.208]) by mail.messagingengine.com (Postfix) with ESMTPA id 967848005A; Mon, 4 Nov 2019 03:20:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (16G102) In-Reply-To: <27826.1572802422@localhost> Date: Mon, 4 Nov 2019 08:20:11 +0000 Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Transfer-Encoding: quoted-printable Message-Id: <2DFE61AC-F094-4A75-8048-8C78B11D884B@fastmail.fm> References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> <26528.1571940866@localhost> <27826.1572802422@localhost> To: Michael Richardson Archived-At: Subject: Re: [Cellar] Second AD review of draft-ietf-cellar-ebml-10 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, 04 Nov 2019 08:20:21 -0000 Hi Michael, > On 3 Nov 2019, at 17:33, Michael Richardson wrote:= >=20 >>>> Alexey Melnikov wrote: >>>>>> A decision as to who is the legitimate documentator of the (existing)= >>>>>> "webm" DocType would be up to the IESG. >>>>=20 >>>>> Is "webm" will be worked on in this WG? >=20 > mcr> No, not unless Google shows up with it! > mcr> WebM shares a container format with Matroska (being EBML), but we a= re not > mcr> trying standard it. >=20 > Alexey> So the IANA policy for this entry would be IESG Approval or RFC= > Alexey> Required. Why do you want IESG to be involved in the decision t= o > Alexey> remove "Reserved" for "webm"? I would rather have Expert Review= > Alexey> here, so that IESG doesn't need to decide. >=20 > So, we went back and forth with IANA on this. > While the policy for names other than "webm" and "matroska" is First Come > First Served. However, we have reserved the two names as already being in= use. > "matroska" is within the CELLAR WG already (by IESG decree, when you > chartered the WG...) >=20 > We could use Expert Review. IANA suggested it be under the control of the > IESG to determine if some work arrived which properly represented "webm" Expert can always ask IESG if the expert is concerned about relationship bet= ween organizations. The most likely outcome is that IESG would say yes. Best Regards, Alexey From nobody Mon Nov 4 11:48:12 2019 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 CB3911200FA; Mon, 4 Nov 2019 11:48:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: last-call@ietf.org, cellar@ietf.org, draft-ietf-cellar-ebml.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <157289688970.13980.7642659058337122087@ietfa.amsl.com> Date: Mon, 04 Nov 2019 11:48:09 -0800 Archived-At: Subject: [Cellar] Genart last call review of draft-ietf-cellar-ebml-13 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: Mon, 04 Nov 2019 19:48:10 -0000 Reviewer: Robert Sparks Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-cellar-ebml-13 Reviewer: Robert Sparks Review Date: 2019-11-04 IETF LC End Date: 2019-11-07 IESG Telechat date: Not scheduled for a telechat Summary: Not ready for publication as a Proposed Standard I had previously reviewed version -09 of this document. Thanks for addressing many of the issues I had raised at that time. My re-review has focused mainly on the diff between -09 and -13. It was surprisingly hard to make useful diffs between these versions, but it was possible to do so by separating out some reordered sections and comparing them separately. I still find this document difficult to comprehend. While not all of the issues I raised were addressed, I don't feel strongly enough about them to repeat them. However, there is one major issue still outstanding that is something the AD should handle. (Attention Alexey) : It's not clear that this group is chartered to produce a general purpose binary equivalent to XML. Instead, it appears to be chartered to document FFV1 and Matroska. EBML as it is currently used for those things needs to be documented, but rather than try to make it into a format that other things besides the work of this group appears out of scope. If I'm correct, then this document shouldn't need to create an IANA registry - it need only document what the group needs (and if the group needs more later, it can update this document). The abstract and introduction would need to be adjusted to scope the purpose of the format to supporting the work of this group. My review assumes a scope of "documenting these existing formats" rather than providing a general purpose markup language. If I'm wrong and this group is chartered to produce an alternative for other protocols to use, this needs review from people who are more expert in that kind of representational design than me. From nobody Mon Nov 4 15:01:56 2019 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 DBA361200FA for ; Mon, 4 Nov 2019 15:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72LnxFNT-wrT for ; Mon, 4 Nov 2019 15:01:34 -0800 (PST) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C182812006A for ; Mon, 4 Nov 2019 15:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=ZiZZFNP1ZyaixezeAAUqdBM6tiC/rym3m7LeXg/Avfs=; b=IMU93uM4TNRiX5QorlkTeA9gt7QtmQisQB3jPE+bMCDsPt4zu8/bdkbwUPItqr1PnX7EvUn0saYll0FU8/oMumm+ymxAlZzrmZTfK2rQk538doEG/Km7j11Rq5hTH/jiowwZCd3MuLk1fQNqJvLiL8xe3c1gC3ZZ+8Lsk1UfVo4=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:60560) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1iRlLd-0004NC-2B for cellar@ietf.org; Tue, 05 Nov 2019 00:01:25 +0100 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 E7DCA6544073; Tue, 5 Nov 2019 00:01:20 +0100 (CET) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.int.bunkus.org (Postfix) with ESMTP id 5133416BC20E; Tue, 5 Nov 2019 00:01:19 +0100 (CET) X-CTCH-RefID: str=0001.0A090211.5DC0ADC5.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 User-agent: mu4e 1.2.0; emacs 26.3 From: Moritz Bunkus To: help Questions , Cellar list Date: Tue, 05 Nov 2019 00:01:19 +0100 Message-ID: <875zjzcklc.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] MKVToolNix v39.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: Mon, 04 Nov 2019 23:01:37 -0000 Hey, Good evening everyone. Here's a nice fresh release of MKVToolNix for y'all: v39. 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 39.0.0 "In The Waiting Line" 2019-11-04 ## New features and enhancements * mkvmerge: Blu-ray: when reading an MPLS playlist mkvmerge will look up and use chapter names from the Blu-ray's "track/chapter names" meta data if it exists. Part of the implementation of 2486. * mkvmerge: MP4 reader: if present, cover art images (the `meta.udta.ilist.covr` atom) will be converted into attachments. * MKVToolNix GUI: multiplexer: when adding a playlist from a Blu-ray disc, = the disc library meta data will be parsed, and the biggest thumbnail, if present, will be added as a new attachment with name `cover.jpg` (extensi= on depends on thumbnail's extension). Implements #2644. * MKVToolNix GUI: multiplexer: when adding a playlist from a Blu-ray disc, = the title from the disc library meta data will be set as the new file title if the disc library meta data contains one & no title has been set yet. * MKVToolNix GUI: multiplexer: the automatically generated destination file name will now be based on the file title if one is set at that point. This works in conjunction with the title being said from the Blu-ray disc libr= ary meta data. * MKVToolNix GUI: chapter editor: when reading chapters from an MPLS playli= st the GUI will look up and use chapter names from the Blu-ray's "track/chap= ter names" meta data if it exists. Part of the implementation of 2486. * MKVToolNix GUI: Windows: added a dark mode that's enabled when Windows 10= 's dark mode is turned on. * translations: added a Bulgarian translation of the programs & the man pag= es by =D0=A1=D0=B8=D0=BC=D0=B5=D0=BE=D0=BD =D0=A6=D0=B2=D0=B5=D1=82=D0=BA=D0= =BE=D0=B2 (see `AUTHORS`). ## Bug fixes * mkvmerge: attachments without a file name won't be ignored anymore. Part = of the fix of #2642. * MKVToolNix GUI: header editor: attachments with an empty name element will be shown as `` as originally intended. Part of the fix of #2642. * Linux AppImage: the AppImage will no longer change directories before running the desired executable allow the use of relative file names. Fixes #2632. ## Build system changes * MKVToolNix now requires a C++ compiler that supports the following featur= es of the C++17 standard: "`[[maybe_unused]]` attribute", "nested namespace definition", "structured bindings". For the GNU Compiler Collection (gcc) this means v7 or newer; for clang it means v4 or newer. * Boost 1.60.0 or newer is now required. ------------------------------------------------------------ Have fun :) mosu From nobody Mon Nov 4 23:51:45 2019 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 11579120255 for ; Mon, 4 Nov 2019 23:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 MhLZboeZidf4 for ; Mon, 4 Nov 2019 23:51:39 -0800 (PST) Received: from mx01.mail.netstorage.at (mx01.mail.netstorage.at [IPv6:2a02:2410:b000:101:3000::c]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD4C12020A for ; Mon, 4 Nov 2019 23:51:38 -0800 (PST) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id 17C69BF46F for ; Tue, 5 Nov 2019 08:51:32 +0100 (CET) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 952E681862 for ; Tue, 5 Nov 2019 08:51:31 +0100 (CET) Received: from [192.168.0.107] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Tue, 5 Nov 2019 08:51:31 +0100 To: cellar@ietf.org References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> From: Tobias Rapp Organization: NOA GmbH Message-ID: <03b98f95-f426-24a9-be2b-d8cc4ab4ef65@noa-archive.com> Date: Tue, 5 Nov 2019 08:51:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20191105075131.4341.9334@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: Re: [Cellar] matroska and side data vs timecode 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, 05 Nov 2019 07:51:45 -0000 On 03.11.2019 11:29, Steve Lhomme wrote: > [...] > > If you want something that will survive this scenario you have to tie > this value to the first timestamp. When remuxing, if timestamps are > altered of portions at the beginning of the file are removed, you need > to edit the first timecode. It may be better to store in the TrackInfo > with both the first timestamp and timecode values. It may not work > when stripping the audio (as Tobias pointed out). So it may even be > put in the SegmentInfo instead of the TrackInfo. It looks tempting to put timecode information inside the video track as they share the framerate as a common property. But in my opinion it would be cleaner to just copy that framerate info into the timecode value structure. For storing a single TC offset using an element in SegmentInfo sounds good. > You may also set the value in Chapters (which are not tied to a > track). There's already a start timestamp. You could add the timecode > for this timestamp. That works for NLE sources as well, each > non-linear part would be a chapter with its timestamp translation. A > good NLE system would also tag this chapter with all kinds of data > about the source. (Matroska was also designed for this case in mind). Setting up a timestamp/timecode mapping via Chapters for non-continuous timecode situations looks like an even better solution than using a dedicated timecode track as this structure should represent the timeline for players. Best regards, Tobias From nobody Tue Nov 5 14:12:14 2019 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 2AD91120025 for ; Tue, 5 Nov 2019 14:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NiTMAdgrdDn9 for ; Tue, 5 Nov 2019 14:12:10 -0800 (PST) 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 919E6120018 for ; Tue, 5 Nov 2019 14:12:10 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 865273897A; Tue, 5 Nov 2019 17:09:13 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B81C7760; Tue, 5 Nov 2019 17:12:07 -0500 (EST) From: Michael Richardson To: Alexey Melnikov cc: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> <26528.1571940866@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Second AD review of draft-ietf-cellar-ebml-10 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, 05 Nov 2019 22:12:13 -0000 --=-=-= Content-Type: text/plain Alexey Melnikov wrote: >> I'm not sure I understand the distinction between the two. The goal >> here is to inform creators of an EBML format that "matroska" and >> "webm" are known to be used elsewhere. > The draft reserves 2 names, which is fine. The question is who is going > to be authorized to change these reservations into proper > registrations. I don't care what we write. IANA said that the IESG was ultimately responsible, either by appointing an Expert Reviewer, or by making the decision itself. As "matroska" is within the CELLAR charter, and we will allocate that name to the document, once the document is published (by Standards Action, which is a superset of IESG Approval), then issue is **only** for "webm". If a design team shows up and wants to say, "Here it the URL for a stable WebM spec", then the IESG should have IANA update it's registry. The question will be whether this is the right design team and the right URL, will either be trivially obvious, or very difficult to determine. I don't know if the IESG will find it any easier to appoint an Expert. (Asking the CELLAR WG will be like asking the Bernie Sander's team about whether it was right for Trump to go after Her Emails) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3B87cACgkQgItw+93Q 3WUbZwgAmexgwGYtqDIjG/TTCVLiQNeGU2XwuI8AgN0I0QgTP7yS7pq/dpU1XBAP RLrKsKa6kUt17S2pm6noOmJrK32UflPfox6i05nT6rHQeUis7jmim0g/w2Zvtn7I uzKIAyJ2Qr3yZjbxr66ULHkzyukIIqpNeb3pfwTf4DI3YrAJ5MsVcg7x4n4bmR7v on3P5QMp0k7PR26XN3hwOcttMgJinFWBI8XpUdjvVD5eU7SfnY2KAEwKHZ3QBNgM rytDK9Qv7GZ+Ewd8xUPJC/fOmOJiPXdX0BihIcOLOg3muuyR3hLJ3XwtEn1gqD5D JtYo/jfrrErUjBKUs0VypLPtfiI8nQ== =kKba -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 8 07:30:18 2019 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 5690712080E; Fri, 8 Nov 2019 07:30:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Shwetha Bhandari via Datatracker To: Cc: last-call@ietf.org, cellar@ietf.org, draft-ietf-cellar-ebml.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Shwetha Bhandari Message-ID: <157322701026.23497.1208790987681323561@ietfa.amsl.com> Date: Fri, 08 Nov 2019 07:30:10 -0800 Archived-At: Subject: [Cellar] Opsdir last call review of draft-ietf-cellar-ebml-13 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, 08 Nov 2019 15:30:10 -0000 Reviewer: Shwetha Bhandari Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts per guidelines in RFC5706 . Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document defines the Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data in a hierarchical form. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines EBML Schemas to convey the semantics of an EBML Document. The draft does not impact operational considerations listed in RFC 5706. However similar to concerns expressed in GENART review the document is standard track and defines general purpose markup language. If this is applicable beyond cellar to other protocols then it needs wider review. From nobody Mon Nov 11 05:00:31 2019 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 D4C6712004D for ; Mon, 11 Nov 2019 05:00:29 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wATquviHNz_e for ; Mon, 11 Nov 2019 05:00:27 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 C366D12020A for ; Mon, 11 Nov 2019 05:00:27 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id 29so9441029pgm.6 for ; Mon, 11 Nov 2019 05:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NskYctN0cH2QM6D6tvHTSpjileKUrc9EkhXX6YFu5gE=; b=EJe5O+8Tfqoj0bgm8N7DWctOZ1rNfS4XTo5krowfZFlTBRoEzhMjSFDOMQ5YV9+5FB MCotpBHXBK7tZKQiYwo4Ou7xoV+QkqltM1Tur1NDVSnzzzjj28UmLwOMSfQxJrtK1tP8 OmilwOhA7gkL5XcxXUD/OPZEa2QmbTsCsXwGqaIt9+W/JWeZUDcYEsX0gUP6N4bAvcc9 jg6Osq7pnbHEvXT4DrlNC90AJ3Uk3M5Uq0BxgA3wte15DDiYqN6Kuz5G9fdbAmgbKR/x G32Ymid2oJ2taiOX+MXgPdG5Ip6gcT0ul4uKshJyTXxvbK0wqCJ2zqyYdjK3hQpLD6s2 lkbg== 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=NskYctN0cH2QM6D6tvHTSpjileKUrc9EkhXX6YFu5gE=; b=Hn+NJyaWKyIcK8/Xy5NUkZ9QUlfOOaobRYds1TPwl04x+/11ROSDLl9DuVUtuDIFpJ GEhtdna+obQiFeM0QGLtzCLEUOdjc6qsESPPFcqYTBJyuCpJGZIc6Bd/HacakP0pLmtZ 3rvSVrShfTIbSiLlPBMrUJKfMOQMbduklOErwkUZZYndZegeOWSoA6G0ABRrDBn4POpT Mr1IIA7H3E96ey9Eti6I+DT2qvQ1CWajOh3hVC/Rr4sh4uuY226p/vlt9d2zpA0jdi/N u2O23rO9UvKVYZKXieWqWB8ybUrVA/2Oh5WYm6URzmkcvzQcIEl7zIJ7mlUvTlC/SiHa bczA== X-Gm-Message-State: APjAAAX/DMnWkgxSR+I+zF+qRcCRjePB+YTbJTH+hvrnKxMUKxgR22Wf 4H9qYfKHx9Su5tDssbopdhHl7zQJSPJA0HXZh31mwA== X-Google-Smtp-Source: APXvYqyUJC8DNKR9J+WeSf9yGXFCX00X9xnpp2dN6iqW84rjc3dVj7tMrJU3TzWHjRX6VTA8nDKh1nwxTnfc+3o8/Q4= X-Received: by 2002:a63:f1c:: with SMTP id e28mr6409637pgl.67.1573477227023; Mon, 11 Nov 2019 05:00:27 -0800 (PST) MIME-Version: 1.0 References: <3835cda8-7bfb-4178-bec7-b0acff9327ba@www.fastmail.com> <26528.1571940866@localhost> In-Reply-To: From: Steve Lhomme Date: Mon, 11 Nov 2019 14:00:16 +0100 Message-ID: To: Alexey Melnikov Cc: Michael Richardson , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Second AD review of draft-ietf-cellar-ebml-10 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, 11 Nov 2019 13:00:30 -0000 Hi, Le lun. 4 nov. 2019 =C3=A0 09:17, Alexey Melnikov = a =C3=A9crit : > > Hi Steve, > > > On 3 Nov 2019, at 10:04, Steve Lhomme wrote: > > > > Hi, > > > >> Le ven. 25 oct. 2019 =C3=A0 17:37, Alexey Melnikov a =C3=A9crit : > >> > >> Hi Michael, > >> > >>> On Thu, Oct 24, 2019, at 7:14 PM, Michael Richardson wrote: > >>> > >>> Alexey Melnikov wrote: > >>>>> A decision as to who is the legitimate documentator of the (existin= g) > >>>>> "webm" DocType would be up to the IESG. > >>> > >>>> Is "webm" will be worked on in this WG? > >>> > >>> No, not unless Google shows up with it! > >>> WebM shares a container format with Matroska (being EBML), but we are= not > >>> trying standard it. > >> > >> So the IANA policy for this entry would be IESG Approval or RFC Requir= ed. Why do you want IESG to be involved in the decision to remove "Reserved= " for "webm"? I would rather have Expert Review here, so that IESG doesn't = need to decide. > > > > I'm not sure I understand the distinction between the two. The goal > > here is to inform creators of an EBML format that "matroska" and > > "webm" are known to be used elsewhere. > > The draft reserves 2 names, which is fine. The question is who is going t= o be authorized to change these reservations into proper registrations. > > The difference between IESG Approval and Expert Review is who is going to= decide to mark an IANA registration entry as properly registered. IESG is = a collection of 15 people, whose membership partially changes every year. C= urrent IESG knows almost nothing about EBML. An appointed Expert would have= more context to make a decision. So I think it makes sense for an Expert t= o handle this, instead of overloading IESG. > (Maybe the following analogy would help: asking IESG is like asking a Boa= rd of Directors to make a technical direction. While IESG is ultimately res= ponsible for the decision, it would prefer to delegate the decision to tech= nical experts.) > > Does this make sense? Yes, thanks a lot for the clarification. It does sound like the simple choice would be to have an Expert Review for new DocTypes. Assigning a name doesn't seem too hard, but if it means making sure the format is actually making proper use of EBML then an "expert" look is needed. Also there's still the question whether we should define a general purpose binary format or just a binary format for Matroska. (see Robert Sparks review and the issue I opened https://github.com/cellar-wg/ebml-specification/issues/304) We may not even have a IANA registry at all in the end. From nobody Thu Nov 21 07:03:31 2019 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 4AB8312081F for ; Thu, 21 Nov 2019 07:03:30 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 S0DTtLRCJPcm for ; Thu, 21 Nov 2019 07:03:28 -0800 (PST) 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 93BA81200E7 for ; Thu, 21 Nov 2019 07:03:28 -0800 (PST) Received: from [146.96.19.240] (port=42464 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iXnzO-0035Ff-DY; Thu, 21 Nov 2019 10:03:26 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Dave Rice In-Reply-To: <03b98f95-f426-24a9-be2b-d8cc4ab4ef65@noa-archive.com> Date: Thu, 21 Nov 2019 10:03:20 -0500 Cc: cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7B1163E2-FCD5-446C-8430-34F94E165101@dericed.com> References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> <03b98f95-f426-24a9-be2b-d8cc4ab4ef65@noa-archive.com> To: Tobias Rapp X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] matroska and side data vs timecode 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, 21 Nov 2019 15:03:30 -0000 Hi all, > On Nov 5, 2019, at 2:51 AM, Tobias Rapp = wrote: >=20 > On 03.11.2019 11:29, Steve Lhomme wrote: >> [...] >> If you want something that will survive this scenario you have to tie >> this value to the first timestamp. When remuxing, if timestamps are >> altered of portions at the beginning of the file are removed, you = need >> to edit the first timecode. It may be better to store in the = TrackInfo >> with both the first timestamp and timecode values. It may not work >> when stripping the audio (as Tobias pointed out). So it may even be >> put in the SegmentInfo instead of the TrackInfo. >=20 > It looks tempting to put timecode information inside the video track = as they share the framerate as a common property. But in my opinion it = would be cleaner to just copy that framerate info into the timecode = value structure. For storing a single TC offset using an element in = SegmentInfo sounds good. =46rom the discussion, there seems to be three approaches for timecode = in Matroska: 1. a single TC offset I proposed having this as a metadata tag, but you=E2=80=99re suggestion = to have the value in Segment Info is interesting. I think the advantage = of having it as a metadata tag is that ffmpeg=E2=80=99s current handling = of (ffmpeg -i timecode.mov output.mkv) would be retroactively valid, = whereas a single offset in SegmentInfo would require implementation = work. 2. frame side-data This allow the timecode (and any other side data) to be stored with the = frame in the Block structure. 3. a timecode track I imagine this would be a track of Clusters where each block contains an = encoded timecode value where the block structure associates the timecode = to a timestamp. Each of these have advantages and disadvantages in terms of simplicity, = implementation, seekability, and resilience; however we do not = necessarily have to select only one. All three approaches could be = defined if we document how these options supersede one another. I=E2=80=99m curious if other would consider it important to favor = limiting the number of approaches listed above. I would prefer to = proceed with refinement to options 1 and 2 concurrently. I=E2=80=99m = less interested in option 3 since timecode is typically used to describe = the contents of another track rather than serve as an independent piece = of data. >> You may also set the value in Chapters (which are not tied to a >> track). There's already a start timestamp. You could add the timecode >> for this timestamp. That works for NLE sources as well, each >> non-linear part would be a chapter with its timestamp translation. A >> good NLE system would also tag this chapter with all kinds of data >> about the source. (Matroska was also designed for this case in mind). >=20 > Setting up a timestamp/timecode mapping via Chapters for = non-continuous timecode situations looks like an even better solution = than using a dedicated timecode track as this structure should represent = the timeline for players. I=E2=80=99m uncertain how this would work, do you mean to use ordered = chapters to place the content along a timeline according to the source = timecode? This may not work if multiple frames in a track all share the = same timecode value, such as when a tape is shuttled during a = duplication process or contains resets within the timecode track. [=E2=80=A6] Dave Rice= From nobody Sun Nov 24 08:43:59 2019 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 33C19120052 for ; Sun, 24 Nov 2019 08:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFr651PGDDd0 for ; Sun, 24 Nov 2019 08:43:56 -0800 (PST) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 51BEC120043 for ; Sun, 24 Nov 2019 08:43:56 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id m71so5322613pjb.12 for ; Sun, 24 Nov 2019 08:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rf+5yuWr0+wJ+p35Hn+BFtqWrhkSJPgofoXy89wxqQM=; b=JpUb7eZLYL3MEFBcPLGKax5ish1Knn+8GpQe363UpJrgXLwsyPzO5Gyq+r7fWf2RH7 22YZFf9XNEAvo7lhUuy6O2OVCgj8Hc2kC64matP3Cp+uA+/mXI3+vR/FU9Icn1Ryw+qe 8xpWQnBuo4V8QokjrYUGXdSiIjbp0lm3CQgOuHKtkna73ZdXJ+N02G6pAsGyuaWnAbyr x41xPvPW0ZtmQ05DttbEmtBjEqfAjsa5LYdh9n6X2UqvAySwlAW20lMLFCX9eglFg1Ja Mov38xAHzv6b62fsx/tdwLSsRGMhoJ92g5uB/Gw9C9Umi3ehj31o4bP1XjxN3Bg5hvG5 wFjw== 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=rf+5yuWr0+wJ+p35Hn+BFtqWrhkSJPgofoXy89wxqQM=; b=FTgGitzUWAjKDaCQtn7SudMP4SFvbgqp94zQGG/1vs9/PnfjdxZZKOg/EdjHODZ5c1 sumcGY8pDSoFsmlabJ969Z7vn0kt6YSoiIzRyGTFYmnvBf9GaO1CAaGQ/yK0UTg0VpPC PCWzIJylZESajn/ZSw8+sw/xFHTOAbHMY35x/VRVdOB2GCX75mRrwfUzULUysNKB/WC4 GNt/xQHiFBAHDel+Ten6MJK0An57c9XsEc1avrnyGY3Z8SWkrM3+rin5/k7gaDfc7bS8 G+VPbBxUFuOhkCu+E+668bg01bINw5pym/uiyATNTZXtsrnMdr82IzwHrPjEoUj9BuO4 PSvA== X-Gm-Message-State: APjAAAXAsM8jB0PjXZ808dKEwZDQ0ZVK55Hf7fcwRr7u1tc5c78ekuUt u2jN6MlB2rIN1IhOSIRS3uIm0QfPnp09SI3jr4grXA== X-Google-Smtp-Source: APXvYqzFRXWKv3vZbsfkeDjlsrjogdCIfUPVKEZ7YMvRwKlE1wl/FdNsNplyGHxnlT/zbWeN79+3x9TxZSIgd+Zw61A= X-Received: by 2002:a17:902:8c84:: with SMTP id t4mr24336973plo.269.1574613835308; Sun, 24 Nov 2019 08:43:55 -0800 (PST) MIME-Version: 1.0 References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> <03b98f95-f426-24a9-be2b-d8cc4ab4ef65@noa-archive.com> <7B1163E2-FCD5-446C-8430-34F94E165101@dericed.com> In-Reply-To: <7B1163E2-FCD5-446C-8430-34F94E165101@dericed.com> From: Steve Lhomme Date: Sun, 24 Nov 2019 17:43:44 +0100 Message-ID: To: Dave Rice Cc: Tobias Rapp , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] matroska and side data vs timecode 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, 24 Nov 2019 16:43:58 -0000 Le jeu. 21 nov. 2019 =C3=A0 16:03, Dave Rice a =C3=A9cri= t : > > Hi all, > > > On Nov 5, 2019, at 2:51 AM, Tobias Rapp wrote: > > > > On 03.11.2019 11:29, Steve Lhomme wrote: > >> [...] > >> If you want something that will survive this scenario you have to tie > >> this value to the first timestamp. When remuxing, if timestamps are > >> altered of portions at the beginning of the file are removed, you need > >> to edit the first timecode. It may be better to store in the TrackInfo > >> with both the first timestamp and timecode values. It may not work > >> when stripping the audio (as Tobias pointed out). So it may even be > >> put in the SegmentInfo instead of the TrackInfo. > > > > It looks tempting to put timecode information inside the video track as= they share the framerate as a common property. But in my opinion it would = be cleaner to just copy that framerate info into the timecode value structu= re. For storing a single TC offset using an element in SegmentInfo sounds g= ood. > > From the discussion, there seems to be three approaches for timecode in M= atroska: > > 1. a single TC offset > I proposed having this as a metadata tag, but you=E2=80=99re suggestion t= o have the value in Segment Info is interesting. I think the advantage of h= aving it as a metadata tag is that ffmpeg=E2=80=99s current handling of (ff= mpeg -i timecode.mov output.mkv) would be retroactively valid, whereas a si= ngle offset in SegmentInfo would require implementation work. But usually tags are not considered/parse in most playback systems. If you need information to playback things correctly (ie display the proper TC) it should be either in Segment Info, Track Info or Clusters. The Timecode may fall in the metadata category and may not be included in there. Also using tags would only work if we adopt exactly the solution already in use by ffmpeg. What tag does it write exactly ? (name, kind of value, target for the tag) > 2. frame side-data > This allow the timecode (and any other side data) to be stored with the f= rame in the Block structure. > > 3. a timecode track > I imagine this would be a track of Clusters where each block contains an = encoded timecode value where the block structure associates the timecode to= a timestamp. > > Each of these have advantages and disadvantages in terms of simplicity, i= mplementation, seekability, and resilience; however we do not necessarily h= ave to select only one. All three approaches could be defined if we documen= t how these options supersede one another. > > I=E2=80=99m curious if other would consider it important to favor limitin= g the number of approaches listed above. I would prefer to proceed with ref= inement to options 1 and 2 concurrently. I=E2=80=99m less interested in opt= ion 3 since timecode is typically used to describe the contents of another = track rather than serve as an independent piece of data. That sounds like something we can discuss a No Time To Wait. > >> You may also set the value in Chapters (which are not tied to a > >> track). There's already a start timestamp. You could add the timecode > >> for this timestamp. That works for NLE sources as well, each > >> non-linear part would be a chapter with its timestamp translation. A > >> good NLE system would also tag this chapter with all kinds of data > >> about the source. (Matroska was also designed for this case in mind). > > > > Setting up a timestamp/timecode mapping via Chapters for non-continuous= timecode situations looks like an even better solution than using a dedica= ted timecode track as this structure should represent the timeline for play= ers. > > I=E2=80=99m uncertain how this would work, do you mean to use ordered cha= pters to place the content along a timeline according to the source timecod= e? This may not work if multiple frames in a track all share the same timec= ode value, such as when a tape is shuttled during a duplication process or = contains resets within the timecode track. Not necessarily ordered-chapters. A chapter already has a mandatory start time, it could have one Timecode to define what that start time corresponds to (or more variants of Timecode for the same start time). Technically that means you could have on Chapter per frame to match it's time exactly with a timecode, that would be a dirty hack. As for reset in tapes, After a reset you should use a different Segment. If there are just gaps of time between continuous takes, you can use on Chapter start/timecode after each discontinuity. > [=E2=80=A6] > > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Mon Nov 25 12:26:54 2019 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 B186D120F60 for ; Mon, 25 Nov 2019 12:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn2zr1MazvHf for ; Mon, 25 Nov 2019 12:26:51 -0800 (PST) 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 2CAB8120F38 for ; Mon, 25 Nov 2019 12:26:12 -0800 (PST) Received: from [146.96.19.240] (port=54301 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iZKvt-001MHM-3Z; Mon, 25 Nov 2019 15:26:10 -0500 From: Dave Rice Message-Id: <73669E32-8239-4017-8A39-F1521CB6E24D@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_93F58DA4-6908-47AD-814A-215FC9456E0A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 25 Nov 2019 15:25:56 -0500 In-Reply-To: Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Tobias Rapp To: Steve Lhomme References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> <03b98f95-f426-24a9-be2b-d8cc4ab4ef65@noa-archive.com> <7B1163E2-FCD5-446C-8430-34F94E165101@dericed.com> X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] matroska and side data vs timecode 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, 25 Nov 2019 20:26:53 -0000 --Apple-Mail=_93F58DA4-6908-47AD-814A-215FC9456E0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 24, 2019, at 11:43 AM, Steve Lhomme = wrote: >=20 > Le jeu. 21 nov. 2019 =C3=A0 16:03, Dave Rice a = =C3=A9crit : >>=20 >> Hi all, >>=20 >>> On Nov 5, 2019, at 2:51 AM, Tobias Rapp = wrote: >>>=20 >>> On 03.11.2019 11:29, Steve Lhomme wrote: >>>> [...] >>>> If you want something that will survive this scenario you have to = tie >>>> this value to the first timestamp. When remuxing, if timestamps are >>>> altered of portions at the beginning of the file are removed, you = need >>>> to edit the first timecode. It may be better to store in the = TrackInfo >>>> with both the first timestamp and timecode values. It may not work >>>> when stripping the audio (as Tobias pointed out). So it may even be >>>> put in the SegmentInfo instead of the TrackInfo. >>>=20 >>> It looks tempting to put timecode information inside the video track = as they share the framerate as a common property. But in my opinion it = would be cleaner to just copy that framerate info into the timecode = value structure. For storing a single TC offset using an element in = SegmentInfo sounds good. >>=20 >> =46rom the discussion, there seems to be three approaches for = timecode in Matroska: >>=20 >> 1. a single TC offset >> I proposed having this as a metadata tag, but you=E2=80=99re = suggestion to have the value in Segment Info is interesting. I think the = advantage of having it as a metadata tag is that ffmpeg=E2=80=99s = current handling of (ffmpeg -i timecode.mov output.mkv) would be = retroactively valid, whereas a single offset in SegmentInfo would = require implementation work. >=20 > But usually tags are not considered/parse in most playback systems. If > you need information to playback things correctly (ie display the > proper TC) it should be either in Segment Info, Track Info or > Clusters. There aren=E2=80=99t that many players I can think of that display = timecode on playback. QuickTime 7 used to but is deprecated. QuickTime X = doesn=E2=80=99t show timecode nor VLC. ffplay can do it by some filter = work that pulls from the metadata. > The Timecode may fall in the metadata category and may not > be included in there. Also using tags would only work if we adopt > exactly the solution already in use by ffmpeg. What tag does it write > exactly ? (name, kind of value, target for the tag) The name is TIMECODE and it writes the timecode value as a string. Like = TIMECODE=3D01:23:45;12 You can make an example of this via: ffmpeg -f lavfi -i testsrc -metadata timecode=3D'01:23:45;12' -t 1 = ffmpeg_timecode.mkv >> 2. frame side-data >> This allow the timecode (and any other side data) to be stored with = the frame in the Block structure. >>=20 >> 3. a timecode track >> I imagine this would be a track of Clusters where each block contains = an encoded timecode value where the block structure associates the = timecode to a timestamp. >>=20 >> Each of these have advantages and disadvantages in terms of = simplicity, implementation, seekability, and resilience; however we do = not necessarily have to select only one. All three approaches could be = defined if we document how these options supersede one another. >>=20 >> I=E2=80=99m curious if other would consider it important to favor = limiting the number of approaches listed above. I would prefer to = proceed with refinement to options 1 and 2 concurrently. I=E2=80=99m = less interested in option 3 since timecode is typically used to describe = the contents of another track rather than serve as an independent piece = of data. >=20 > That sounds like something we can discuss a No Time To Wait. See you next week :) >>>> You may also set the value in Chapters (which are not tied to a >>>> track). There's already a start timestamp. You could add the = timecode >>>> for this timestamp. That works for NLE sources as well, each >>>> non-linear part would be a chapter with its timestamp translation. = A >>>> good NLE system would also tag this chapter with all kinds of data >>>> about the source. (Matroska was also designed for this case in = mind). >>>=20 >>> Setting up a timestamp/timecode mapping via Chapters for = non-continuous timecode situations looks like an even better solution = than using a dedicated timecode track as this structure should represent = the timeline for players. >>=20 >> I=E2=80=99m uncertain how this would work, do you mean to use ordered = chapters to place the content along a timeline according to the source = timecode? This may not work if multiple frames in a track all share the = same timecode value, such as when a tape is shuttled during a = duplication process or contains resets within the timecode track. >=20 > Not necessarily ordered-chapters. A chapter already has a mandatory > start time, it could have one Timecode to define what that start time > corresponds to (or more variants of Timecode for the same start time). > Technically that means you could have on Chapter per frame to match > it's time exactly with a timecode, that would be a dirty hack. Please no. :-O > As for reset in tapes, After a reset you should use a different > Segment. If there are just gaps of time between continuous takes, you > can use on Chapter start/timecode after each discontinuity. I think this is hacky as well. It seems like a lot more to ask a = recording tool to reset to a new Segment because the timecode skipped. Dave >> [=E2=80=A6] >>=20 >> Dave Rice >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_93F58DA4-6908-47AD-814A-215FC9456E0A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Nov 24, 2019, at 11:43 AM, Steve Lhomme <slhomme@matroska.org> wrote:

Le = jeu. 21 nov. 2019 =C3=A0 16:03, Dave Rice <dave@dericed.com> a = =C3=A9crit :

Hi all,

On Nov 5, 2019, at 2:51 AM, Tobias Rapp <t.rapp@noa-archive.com> wrote:

On 03.11.2019 11:29, Steve Lhomme wrote:
[...]
If = you want something that will survive this scenario you have to tie
this value to the first timestamp. When remuxing, if = timestamps are
altered of portions at the beginning of the = file are removed, you need
to edit the first timecode. It = may be better to store in the TrackInfo
with both the = first timestamp and timecode values. It may not work
when = stripping the audio (as Tobias pointed out). So it may even be
put in the SegmentInfo instead of the TrackInfo.

It looks tempting to put timecode = information inside the video track as they share the framerate as a = common property. But in my opinion it would be cleaner to just copy that = framerate info into the timecode value structure. For storing a single = TC offset using an element in SegmentInfo sounds good.

=46rom the discussion, there = seems to be three approaches for timecode in Matroska:

1. a single TC offset
I proposed having this as = a metadata tag, but you=E2=80=99re suggestion to have the value in = Segment Info is interesting. I think the advantage of having it as a = metadata tag is that ffmpeg=E2=80=99s current handling of (ffmpeg -i = timecode.mov output.mkv) would be retroactively valid, whereas a single = offset in SegmentInfo would require implementation work.

But usually tags are not = considered/parse in most playback systems. If
you need = information to playback things correctly (ie display the
proper TC) it should be either in Segment Info, Track Info = or
Clusters.

There aren=E2=80=99t that many players I can think = of that display timecode on playback. QuickTime 7 used to but is = deprecated. QuickTime X doesn=E2=80=99t show timecode nor VLC. ffplay = can do it by some filter work that pulls from the metadata.

The Timecode may fall in the metadata category and may not
be included in there. Also using tags would only work if we = adopt
exactly the solution already in use by ffmpeg. What = tag does it write
exactly ? (name, kind of value, target = for the tag)

The name is TIMECODE and it writes the timecode = value as a string. Like TIMECODE=3D01:23:45;12
You can make an = example of this via:
ffmpeg -f lavfi -i testsrc -metadata = timecode=3D'01:23:45;12' -t 1 ffmpeg_timecode.mkv

2. frame side-data
This allow the timecode (and any other side data) to be = stored with the frame in the Block structure.

3. a timecode track
I imagine this would be a = track of Clusters where each block contains an encoded timecode value = where the block structure associates the timecode to a timestamp.

Each of these have advantages and = disadvantages in terms of simplicity, implementation, seekability, and = resilience; however we do not necessarily have to select only one. All = three approaches could be defined if we document how these options = supersede one another.

I=E2=80=99m curious = if other would consider it important to favor limiting the number of = approaches listed above. I would prefer to proceed with refinement to = options 1 and 2 concurrently. I=E2=80=99m less interested in option 3 = since timecode is typically used to describe the contents of another = track rather than serve as an independent piece of data.

That sounds like something we can = discuss a No Time To Wait.
See you next week :)

You may also set the = value in Chapters (which are not tied to a
track). There's = already a start timestamp. You could add the timecode
for = this timestamp. That works for NLE sources as well, each
non-linear part would be a chapter with its timestamp = translation. A
good NLE system would also tag this chapter = with all kinds of data
about the source. (Matroska was = also designed for this case in mind).

Setting up a timestamp/timecode mapping via Chapters for = non-continuous timecode situations looks like an even better solution = than using a dedicated timecode track as this structure should represent = the timeline for players.

I=E2=80= =99m uncertain how this would work, do you mean to use ordered chapters = to place the content along a timeline according to the source timecode? = This may not work if multiple frames in a track all share the same = timecode value, such as when a tape is shuttled during a duplication = process or contains resets within the timecode track.

Not necessarily ordered-chapters. = A chapter already has a mandatory
start time, it could = have one Timecode to define what that start time
corresponds= to (or more variants of Timecode for the same start time).
Technically that means you could have on Chapter per frame to = match
it's time exactly with a timecode, that would be a = dirty hack.

Please no. :-O

As for reset in = tapes, After a reset you should use a different
Segment. = If there are just gaps of time between continuous takes, you
can use on Chapter start/timecode after each = discontinuity.

I think this is hacky as well. It seems like a lot = more to ask a recording tool to reset to a new Segment because the = timecode skipped.
Dave

[=E2=80=A6]

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



-- =
Steve Lhomme
Matroska association = Chairman

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

= --Apple-Mail=_93F58DA4-6908-47AD-814A-215FC9456E0A-- From nobody Tue Nov 26 00:31:09 2019 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 2FE3212081B for ; Tue, 26 Nov 2019 00:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 1sgZuDyKySOm for ; Tue, 26 Nov 2019 00:31:06 -0800 (PST) Received: from mx01.mail.netstorage.at (mx01.mail.netstorage.at [IPv6:2a02:2410:b000:101:3000::c]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9955312003F for ; Tue, 26 Nov 2019 00:30:40 -0800 (PST) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id E1FA4A0847; Tue, 26 Nov 2019 09:30:34 +0100 (CET) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 37D54811EC; Tue, 26 Nov 2019 09:30:34 +0100 (CET) Received: from [192.168.0.107] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Tue, 26 Nov 2019 09:30:33 +0100 From: Tobias Rapp To: Steve Lhomme , Dave Rice Cc: Codec Encoding for LossLess Archiving and Realtime transmission References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> <03b98f95-f426-24a9-be2b-d8cc4ab4ef65@noa-archive.com> <7B1163E2-FCD5-446C-8430-34F94E165101@dericed.com> Organization: NOA GmbH Message-ID: Date: Tue, 26 Nov 2019 09:30:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20191126083034.6882.1462@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: Re: [Cellar] matroska and side data vs timecode 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, 26 Nov 2019 08:31:09 -0000 On 24.11.2019 17:43, Steve Lhomme wrote: > Le jeu. 21 nov. 2019 à 16:03, Dave Rice a écrit : >> >> [...] >> >> 1. a single TC offset >> I proposed having this as a metadata tag, but you’re suggestion to have the value in Segment Info is interesting. I think the advantage of having it as a metadata tag is that ffmpeg’s current handling of (ffmpeg -i timecode.mov output.mkv) would be retroactively valid, whereas a single offset in SegmentInfo would require implementation work. > > But usually tags are not considered/parse in most playback systems. If > you need information to playback things correctly (ie display the > proper TC) it should be either in Segment Info, Track Info or > Clusters. The Timecode may fall in the metadata category and may not > be included in there. Also using tags would only work if we adopt > exactly the solution already in use by ffmpeg. What tag does it write > exactly ? (name, kind of value, target for the tag) Adding a tag for storing timecode offset is a simple solution and satisfies the most basic requirements. The current list [1] seems to already include other technical tags like "FPS" and "REPLAYGAIN_PEAK" so it should be fine. I would not use a framecount for storing sub-seconds, though, but a HH:MM:SS.MSS pattern like used for date-time (without the date part). This would be valid for audio and video files. An application can render the value in HH:MM:SS:FF syntax for user display, if desired. >>> Setting up a timestamp/timecode mapping via Chapters for non-continuous timecode situations looks like an even better solution than using a dedicated timecode track as this structure should represent the timeline for players. >> >> I’m uncertain how this would work, do you mean to use ordered chapters to place the content along a timeline according to the source timecode? This may not work if multiple frames in a track all share the same timecode value, such as when a tape is shuttled during a duplication process or contains resets within the timecode track. > > Not necessarily ordered-chapters. A chapter already has a mandatory > start time, it could have one Timecode to define what that start time > corresponds to (or more variants of Timecode for the same start time). > Technically that means you could have on Chapter per frame to match > it's time exactly with a timecode, that would be a dirty hack. > > As for reset in tapes, After a reset you should use a different > Segment. If there are just gaps of time between continuous takes, you > can use on Chapter start/timecode after each discontinuity. The latter option seems the most practical. As far as I understand from [2] there can be multiple chapters applied to one segment by using multiple EditionEntry elements. That might be useful because we can have one chapter structure for track labeling "scene one", "scene two", ... and another chapter structure for timecodes (if necessary). I assume timecodes would get an own "ChapterTimecodeOffset" element, similar to existing ChapterTimeStart/-End. Or would you define a "ChapProcessCodecID" for timecodes explicitly? Also maybe we want to store some more information together with the plain time value. Possibly frame-rate and drop-frame flag (for rendering the time in HH:MM:SS[:;]FF syntax) should be put either as optional elements on EditionEntry level or into ChapProcessPrivate. In theory there could be multiple timecode sources (VITC, LTC, etc) but in practice it seems hardware players just output the most precise one currently available so storing the source name in Matroska would not be considered relevant by me. Best regards, Tobias Links: [1] https://www.ietf.org/id/draft-ietf-cellar-tags-03.html [2] https://datatracker.ietf.org/doc/html/draft-ietf-cellar-matroska-04#section-9.3.7 From nobody Tue Nov 26 01:00:10 2019 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 3BE08120821 for ; Tue, 26 Nov 2019 01:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 5iN6qoo6vm55 for ; Tue, 26 Nov 2019 01:00:07 -0800 (PST) Received: from mx02.mail.netstorage.at (mx02.mail.netstorage.at [IPv6:2a02:2410:b000:101:3000::d]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85255120808 for ; Tue, 26 Nov 2019 00:59:48 -0800 (PST) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx02.mail.netstorage.at (Postfix) with ESMTPS id 8E30BA7DF9; Tue, 26 Nov 2019 09:59:43 +0100 (CET) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 15091817B5; Tue, 26 Nov 2019 09:59:43 +0100 (CET) Received: from [192.168.0.107] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Tue, 26 Nov 2019 09:59:42 +0100 To: Dave Rice Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> <03b98f95-f426-24a9-be2b-d8cc4ab4ef65@noa-archive.com> <7B1163E2-FCD5-446C-8430-34F94E165101@dericed.com> <73669E32-8239-4017-8A39-F1521CB6E24D@dericed.com> From: Tobias Rapp Organization: NOA GmbH Message-ID: Date: Tue, 26 Nov 2019 09:59:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <73669E32-8239-4017-8A39-F1521CB6E24D@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20191126085943.10558.21022@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: Re: [Cellar] matroska and side data vs timecode 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, 26 Nov 2019 09:00:09 -0000 On 25.11.2019 21:25, Dave Rice wrote: > >> On Nov 24, 2019, at 11:43 AM, Steve Lhomme > > wrote: >> >> Not necessarily ordered-chapters. A chapter already has a mandatory >> start time, it could have one Timecode to define what that start time >> corresponds to (or more variants of Timecode for the same start time). >> Technically that means you could have on Chapter per frame to match >> it's time exactly with a timecode, that would be a dirty hack. > > Please no. :-O > >> As for reset in tapes, After a reset you should use a different >> Segment. If there are just gaps of time between continuous takes, you >> can use on Chapter start/timecode after each discontinuity. > > I think this is hacky as well. It seems like a lot more to ask a > recording tool to reset to a new Segment because the timecode skipped. > Dave Just out of curiosity: How many timecode jumps (excluding jumps due to corrupt signal) do you experience when recording? From my knowledge there is usually one timecode at the start of a program, and about 1-4 different programs on one carrier tape. Best regards, Tobias From nobody Tue Nov 26 06:02:49 2019 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 52EA11200FF for ; Tue, 26 Nov 2019 06:02:47 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 fGzN8iFOhDNu for ; Tue, 26 Nov 2019 06:02:44 -0800 (PST) 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 37CCC120048 for ; Tue, 26 Nov 2019 06:02:44 -0800 (PST) Received: from [146.96.19.240] (port=24596 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iZbQL-003JoO-Ga; Tue, 26 Nov 2019 09:02:42 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Dave Rice In-Reply-To: Date: Tue, 26 Nov 2019 09:02:27 -0500 Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Steve Lhomme Content-Transfer-Encoding: quoted-printable Message-Id: <76AF6036-FA4F-49E6-BAB9-905135917796@dericed.com> References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> <03b98f95-f426-24a9-be2b-d8cc4ab4ef65@noa-archive.com> <7B1163E2-FCD5-446C-8430-34F94E165101@dericed.com> <73669E32-8239-4017-8A39-F1521CB6E24D@dericed.com> To: Tobias Rapp X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] matroska and side data vs timecode 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, 26 Nov 2019 14:02:47 -0000 > On Nov 26, 2019, at 3:59 AM, Tobias Rapp = wrote: >=20 > On 25.11.2019 21:25, Dave Rice wrote: >>> On Nov 24, 2019, at 11:43 AM, Steve Lhomme > wrote: >>>=20 >>> Not necessarily ordered-chapters. A chapter already has a mandatory >>> start time, it could have one Timecode to define what that start = time >>> corresponds to (or more variants of Timecode for the same start = time). >>> Technically that means you could have on Chapter per frame to match >>> it's time exactly with a timecode, that would be a dirty hack. >> Please no. :-O >>> As for reset in tapes, After a reset you should use a different >>> Segment. If there are just gaps of time between continuous takes, = you >>> can use on Chapter start/timecode after each discontinuity. >> I think this is hacky as well. It seems like a lot more to ask a = recording tool to reset to a new Segment because the timecode skipped. >> Dave >=20 > Just out of curiosity: How many timecode jumps (excluding jumps due to = corrupt signal) do you experience when recording? A non-sequential timecode could happen on every frame. For instance a = tape to tape duplication where the source tape was left in pause mode = while the other tape was recording would leave a long series of frames = with identical timecode values. > =46rom my knowledge there is usually one timecode at the start of a = program, and about 1-4 different programs on one carrier tape. >=20 > Best regards, > Tobias >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar