From nobody Fri Sep 1 05:28:05 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADDC1341A2 for ; Fri, 1 Sep 2017 05:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7Xc5tS3JYRq for ; Fri, 1 Sep 2017 05:28:01 -0700 (PDT) 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 C1ADC1321A8 for ; Fri, 1 Sep 2017 05:28:01 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx02.mail.netstorage.at (Postfix) with ESMTPS id DE068A1EA8 for ; Fri, 1 Sep 2017 14:27:26 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 92C0781AEA for ; Fri, 1 Sep 2017 14:27:26 +0200 (CEST) Received: from [192.168.0.110] (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) ; Fri, 1 Sep 2017 14:27:26 +0200 To: Codec Encoding for LossLess Archiving and Realtime transmission From: Tobias Rapp Organization: NOA GmbH Message-ID: <675d4543-53ca-b702-9396-0f6ebdda500f@noa-archive.com> Date: Fri, 1 Sep 2017 14:27:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20170901122726.12104.20120@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: DE068A1EA8.A7234 X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=-0.5, benoetigt 6, autolearn=not spam, BAYES_00 -0.50) X-NetStorage-MailScanner-From: t.rapp@noa-archive.com Archived-At: Subject: [Cellar] Adding cues for audio tracks X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 12:28:03 -0000 Hello, the recommendations section of the "Cues" chapter (43.2) contains the following paragraph: """ Audio tracks SHOULD only be referenced in "CuePoint Elements" if no video track is present. In this case "CuePoint Elements" SHOULD reference audio keyframes at most once every 500 milliseconds. """ I understand this helps optimizing Matroska file size but at the cost of seeking performance. When video bitrate is large (FFV1 1080p) and seeking latency is high (tape-based storage system) the additional round-trips to find the accurate audio track position can be in the range of minutes. So for this scenario adding audio tracks to the cluster index makes sense and index size overhead is still small compared to the total file size. In my opinion it would be better to indicate that the recommendation is fully optional, using text like: """ References to audio tracks MAY be skipped in "CuePoint Elements" if a video track is present. When included the "CuePoint Elements" SHOULD reference audio keyframes at most once every 500 milliseconds. """ Regards, Tobias From nobody Fri Sep 1 05:33:34 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC561341CD for ; Fri, 1 Sep 2017 05:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqGJZ_nycMHU for ; Fri, 1 Sep 2017 05:33:31 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6457132F16 for ; Fri, 1 Sep 2017 05:33:31 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:46142) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dnl8T-0005W3-1b for cellar@ietf.org; Fri, 01 Sep 2017 14:33:21 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 430366540DA1 for ; Fri, 1 Sep 2017 14:33:21 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0202.59A95391.00F9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1504269201; bh=RY6uBHPyfCFbfyTiPVf3/X/Bx2Aal1sWfv0WjpbDeMc=; h=References:From:To:Cc:Subject:In-reply-to:Date:From; b=2HYZOR3dIwzYil+yPQHeLCShsrkFsQ6I0yqqwc0JyNBKEXiD7z8sVEYFxZ43fx7hU eeeoTc8SauoSQhZwnLhUSCsWp58WbEap8OBYG3R1u+hon4W54b7avDhxijxSzWlaXW zLJfgY/C0XzfUWzrzeLaddtMdZrhPHJlrYrI0Ov9Cgn/QUCCMEn6FaUYnZfpedwZ/5 IkPEGdkRR+cGl+q4Vh5mFC0IXgP6pA9JxQkP5ZStg/G602CEoxVQgNZ844ryBv5rDj YVfIujt9ocCsve/daanU4xgtZER3am7EAVIHeYra/vfDrxU9LHzJTJODfRgAN37iqh dslx5UOZgGiXLiu6bo0ADaPDDXYxG/QFfi0sRez1CJmpHf27yhrc6qb9IA91t/CKUW 9YtzQzsKDh7t+EOZA3eHbCeLTi03TOSdIs8jJZYtu+A/NJKl+pMiZDdZtuJvIZNs2V YH1zbVTMDqINcJXZwadR7C34wcZoMGI0vMUZvoajRXkxjuJbX5TFHAl4dp6LrLEEXH xSEC4toKGE33L28M1ZFKdT702vQwqX/GA7ZnVjW0hIvGdfBR6gPk2jBPRCLRTKp83f shxc9x+z00+lZcNtzBVKPz1OY+b/YyHPzRUP0dRDDLyQd152dCbnYGHWimbkAno6Bb KUggY2IgS+xhzXX9fDJ11pko= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTPS id BF21D1E5E4AC for ; Fri, 1 Sep 2017 14:33:20 +0200 (CEST) References: <675d4543-53ca-b702-9396-0f6ebdda500f@noa-archive.com> User-agent: mu4e 0.9.18; emacs 25.2.1 From: Moritz Bunkus To: Codec Encoding for LossLess Archiving and Realtime transmission Cc: In-reply-to: <675d4543-53ca-b702-9396-0f6ebdda500f@noa-archive.com> Date: Fri, 01 Sep 2017 14:33:20 +0200 Message-ID: <87inh2fvjj.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] Adding cues for audio tracks X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 12:33:33 -0000 Hey, I'd be fine with such a change. Care to create a pull request? Kind regards, mosu From nobody Fri Sep 1 05:54:21 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444B2132A8F for ; Fri, 1 Sep 2017 05:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuaD2ilefPB9 for ; Fri, 1 Sep 2017 05:54:18 -0700 (PDT) Received: from mx01.mail.netstorage.at (mx01.mail.netstorage.at [89.207.144.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3B4133069 for ; Fri, 1 Sep 2017 05:54:17 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id E971BA0476 for ; Fri, 1 Sep 2017 14:54:01 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 96FF48207E for ; Fri, 1 Sep 2017 14:54:01 +0200 (CEST) Received: from [192.168.0.110] (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) ; Fri, 1 Sep 2017 14:54:01 +0200 To: cellar@ietf.org References: <675d4543-53ca-b702-9396-0f6ebdda500f@noa-archive.com> <87inh2fvjj.fsf@bunkus.org> From: Tobias Rapp Organization: NOA GmbH Message-ID: <7dc2b2e8-92eb-f841-99a1-f1c71a20467e@noa-archive.com> Date: Fri, 1 Sep 2017 14:54:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <87inh2fvjj.fsf@bunkus.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20170901125401.16507.89472@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: E971BA0476.A39E6 X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=-0.5, benoetigt 6, autolearn=not spam, BAYES_00 -0.50) X-NetStorage-MailScanner-From: t.rapp@noa-archive.com Archived-At: Subject: Re: [Cellar] Adding cues for audio tracks X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 12:54:20 -0000 On 01.09.2017 14:33, Moritz Bunkus wrote: > Hey, > > I'd be fine with such a change. Care to create a pull request? > > Kind regards, > mosu Will try to educate myself on GitHub pull requests and create one. Thanks for feedback, Tobias From nobody Fri Sep 1 08:12:00 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD30F13422C for ; Fri, 1 Sep 2017 08:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RKN5t8VogNP for ; Fri, 1 Sep 2017 08:11:56 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBA5132D6A for ; Fri, 1 Sep 2017 08:11:56 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id a21so2196312qkg.5 for ; Fri, 01 Sep 2017 08:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uCVWBtDbRFhtE74EyzgS5vPjQfJ6TBt59FYpdhvqUMA=; b=nJ3xiEuLOCG7ImjtqirH9GRfQ4dKkkYorbMnOlVlfjEVMMI6RQafKnkYVOGnK9oKoB 688MNm32yLTwfnS78NjHTCOCd7to7OXrzmg1iBuFCv2Yuk9Ip/wHwI+DCdV5nGpYBBct MY8dSKgYlnHPBiCouY92+5WPqNjP2GGeC3c3zw4ihbsKhd0j5J7f90JR6IYRSFYsbjE7 sFhHzJkbIBpwsfaekwksaERyFDz71qhjWy5yC67+tkOtnEEmnr1kPuCeI8R7SMEtSO4A +WBpEVDE+qImF4DJWI8Si/WBh9Cf7fncqd+E3M+zfkmWplCQ9ciKz3RYHAmJBsZe6cgk hjWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uCVWBtDbRFhtE74EyzgS5vPjQfJ6TBt59FYpdhvqUMA=; b=XrJU2POAgJnUyfaqB7XbE9gWRTinEvn6GKvuONcZDNv3UNJJwvfQDk2QdHqx7M+ZCh eBNqg1Cg649CV2N5LOZKoSbaR9m3GQ3ToMI+Dn3uCjSfqjChGd7v397b/5orbDJorJh/ dU1InJLEhzJjEXWaZDC2EXFUxUy2K6U3st9yQJfmbCCCyyQNcbs72GBkhPKMUofsJZvP VNICBUVzS+rgYCQJ5I4u+nkQoJWwN1ONKySxyFkxU6ML+ILs1gFxVtAM2VJWtem+Ch0d rkKH2VDiS/2IYlccIuzuFs5+eML68VmYGHksyvbKlb4yxntZHy/oUDB+D/Ioht/8fko4 QTJQ== X-Gm-Message-State: AHPjjUjJeOfojmgVyM+or5p9yheZ7ATDLRp9xprUc9V45taaTCs5Rz3S q/S1nrgsITM8zKqZ2+P/LIo2xJXF/ml5 X-Google-Smtp-Source: ADKCNb4ik/Ng4eTh2EXuzpfLarPCrEcrTjgrO3ybDm7BGeI+w+iu2e12edajGctrZmLzZRqUGJFmQahovLUNzgIEqhU= X-Received: by 10.55.5.21 with SMTP id 21mr1965610qkf.158.1504278715030; Fri, 01 Sep 2017 08:11:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.98.73 with HTTP; Fri, 1 Sep 2017 08:11:54 -0700 (PDT) In-Reply-To: <7dc2b2e8-92eb-f841-99a1-f1c71a20467e@noa-archive.com> References: <675d4543-53ca-b702-9396-0f6ebdda500f@noa-archive.com> <87inh2fvjj.fsf@bunkus.org> <7dc2b2e8-92eb-f841-99a1-f1c71a20467e@noa-archive.com> From: Ashley Blewer Date: Fri, 1 Sep 2017 11:11:54 -0400 Message-ID: To: Tobias Rapp Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a11488c0873ee460558222e3c" Archived-At: Subject: Re: [Cellar] Adding cues for audio tracks X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 15:11:58 -0000 --001a11488c0873ee460558222e3c Content-Type: text/plain; charset="UTF-8" I agree with this change too. Tobias (and everyone else), Happy to help if you have any questions about using Github! Just send me an email off-list! Ashley On Fri, Sep 1, 2017 at 8:54 AM, Tobias Rapp wrote: > On 01.09.2017 14:33, Moritz Bunkus wrote: > >> Hey, >> >> I'd be fine with such a change. Care to create a pull request? >> >> Kind regards, >> mosu >> > > Will try to educate myself on GitHub pull requests and create one. > > Thanks for feedback, > Tobias > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a11488c0873ee460558222e3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with this change too.=C2=A0

Tob= ias (and everyone else), Happy to help if you have any questions about usin= g Github! Just send me an email off-list!

Ashley

On Fri,= Sep 1, 2017 at 8:54 AM, Tobias Rapp <t.rapp@noa-archive.com><= /span> wrote:
On 01.09.2= 017 14:33, Moritz Bunkus wrote:
Hey,

I'd be fine with such a change. Care to create a pull request?

Kind regards,
mosu

 Will try to educate myself on GitHub pull requests and create one.

Thanks for feedback,
Tobias


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

--001a11488c0873ee460558222e3c-- From nobody Thu Sep 7 06:33:04 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57462132EFC for ; Thu, 7 Sep 2017 06:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4tsunahX9x2 for ; Thu, 7 Sep 2017 06:33:01 -0700 (PDT) Received: from mx02.mail.netstorage.at (mx02.mail.netstorage.at [89.207.146.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C35132EF8 for ; Thu, 7 Sep 2017 06:33:00 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx02.mail.netstorage.at (Postfix) with ESMTPS id 807A2A06BE for ; Thu, 7 Sep 2017 15:32:29 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 4E00481C94 for ; Thu, 7 Sep 2017 15:32:29 +0200 (CEST) Received: from [127.0.0.1] (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) ; Thu, 7 Sep 2017 15:32:29 +0200 From: Tobias Rapp To: Codec Encoding for LossLess Archiving and Realtime transmission Organization: NOA GmbH Message-ID: Date: Thu, 7 Sep 2017 15:32:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20170907133229.3581.72590@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: 807A2A06BE.A664A X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=-0.5, benoetigt 6, autolearn=not spam, BAYES_00 -0.50) X-NetStorage-MailScanner-From: t.rapp@noa-archive.com Archived-At: Subject: [Cellar] EBML element identifier assignment X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 13:33:03 -0000 Hi, just out of curiosity: How are EBML element identifiers chosen which are used within Matroska? Often-used elements seem to get a shorter identifier which in turn determines the most significant bits. Are the remaining bits assigned randomly? In case some vendor would like to add a new element (theoretical example, I have no current plans), is there some "reserved range" similar to the Private Use Area of Unicode? Regards, Tobias From nobody Fri Sep 8 05:14:29 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8721326ED for ; Fri, 8 Sep 2017 05:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 GO0GR8kBcjsD for ; Fri, 8 Sep 2017 05:14:25 -0700 (PDT) Received: from mx02.mail.netstorage.at (mx02.mail.netstorage.at [89.207.146.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397BC1321B6 for ; Fri, 8 Sep 2017 05:14:24 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx02.mail.netstorage.at (Postfix) with ESMTPS id 59BDAA06D6 for ; Fri, 8 Sep 2017 14:14:09 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 0DECF816D1 for ; Fri, 8 Sep 2017 14:14:09 +0200 (CEST) Received: from [127.0.0.1] (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) ; Fri, 8 Sep 2017 14:14:09 +0200 From: Tobias Rapp To: Codec Encoding for LossLess Archiving and Realtime transmission Organization: NOA GmbH Message-ID: <2bddc712-3d56-0efd-058f-ff1533eb6f41@noa-archive.com> Date: Fri, 8 Sep 2017 14:14:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20170908121409.2963.62550@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: 59BDAA06D6.A8040 X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=-0.5, benoetigt 6, autolearn=not spam, BAYES_00 -0.50) X-NetStorage-MailScanner-From: t.rapp@noa-archive.com Archived-At: Subject: [Cellar] Status of the ChannelPositions element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 12:14:27 -0000 Hi, when looking for a way to store audio channel positions in Matroska I stumbled over the "ChannelPositions" element. Currently it is defined as having a binary value but unfortunately the specification doesn't actually mention the format (see section 7.3.145). If I remember correctly, Steve Lhomme mentioned some time ago that this element was once defined but never used. So I guess the (current) ChannelPositions element definition can be removed from the specs? What would be a suitable replacement? I think it should at least support the typical named channel positions like (Front)Left/(Front)Right/Center/LFE/..., possibly using a list similar to table 7 in section "Speaker Channel Position" of ISO/IEC 23001-8:2013 for mapping positions to numerical values (maybe with an "Unknown" position value inserted at the front). Likely 3D positions will be important in the future. Does anybody have some experience in how 3D positions are described (Google/WebM developers)? At least I'd suggest to use a "type" flag that indicates whether the position list contains named positions, 3D coordinates or some other future data format. Or we take the same approach as used for the Projection elements and simply adopt the data structure of ISOBMFF box "chnl". The pros and cons in my opinion: (+) allows for more simple re-wrapping between MP4 and MKV; (-) adds MP4 container semantics to MKV (FullBox flags, alignment/endianness requirements) (-) document version available to me (ISO/IEC 14496-12:2015E) doesn't really describe what an "object" is and how it is stored; (-) due to using the speaker position list of ISO/IEC 23001-8 doesn't allow some of the channels to indicate unknown position; In the end my proposal would be to not directly follow ISOBMFF. Instead we could do: (a) add element "ChannelPositionType" of type enum/integer with values: 1 => Channel Configuration (based on ISO/IEC 23001-8:2013, section "Channel Configuration") 2 => Channel Mask (based on WAVEFORMATEXTENSIBLE, field "dwChannelMask") 3 => Position List (based on ISO/IEC 23001-8:2013, section "Speaker Channel Position") 4 => 3D Position List (based on ?) (b) add element "ChannelPositionData/ChannelPositionPrivate" with data type depending on the value of ChannelPositionType: 1 => unsigned integer 2 => unsigned integer 3 => array of unsigned integers, length is defined by "Channels" element, 0=Unknown, 1=Left, 2=Right, ... 4 => array of speaker coordinate structure (TBD), length is defined by "Channels" element Suggestions and opinions welcome. Regards, Tobias From nobody Fri Sep 8 10:17:27 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BBA124B18 for ; Fri, 8 Sep 2017 10:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-5UMYn00hak for ; Fri, 8 Sep 2017 10:17:24 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541AC132D55 for ; Fri, 8 Sep 2017 10:17:24 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id x190so18230373oix.3 for ; Fri, 08 Sep 2017 10:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bjkbgbCYUAMAGctijrVOJVxN9jYUWstG1e4PXHOhG9Y=; b=ZLWpysyucsOjOh8AwjAw87UqxA3xsHLPB/8Np7Pop4NV82mGCNCT23aEB3UKei6Mgt yjquH8eZNNv6RgT3/5Phn54wke3tUaeOx7Ly80Uvvo5rKLsmBPc5IrIIczoWnETziELX 0tN3I6bWfS3zHdSch5VU9B4/YksevGXosCKGkaLHFHH631fVYZci0D7pzFMRxwYoL2Zb 3/MRACOxJKB3zpWd/Ly9sbVHxD/3RKO7nPcPFu4JjqDZMdRgxTaQJj6yvqwQj5Ss2PJL EsTK9AqirkzgXRgBYaYvfFNVl9WCu66RPBPktKITz5fY6nwEk/Yi+mGTCLzPZwYmYse0 GmJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bjkbgbCYUAMAGctijrVOJVxN9jYUWstG1e4PXHOhG9Y=; b=V+GzbeCGKuiMUwtvWXARvhFt3M1wUSU4FfkRIMluREJwv6IgYVLJPm6Q5vcoIzDj87 PYwv0y9u5FlvTUnuwqBt4K0KAYuxAcfcG7Prr9+5YWLJwtPBmBFcNqxATAlM1GMEyTg7 CEoiAEGRbvD5mG8B4T28dqTPPa3fy0u7HjE92jRVF8p6IOZ27g1GV1iXTu9mIIrU1NsS LeSu6fwtKfiCNloGQpEWz7nrdDkZ+GqrpuMz/q8MIZJ6md6zzp/xID7dQ5/PKMP3WKNv /w8Tcj0D+DVMrKa9q98C9S72QlarJDykYNpPDyyn7+CyKVPpIuQpUb4juKaCAXgJXjzY qaVw== X-Gm-Message-State: AHPjjUgjryNGXedDJPqsMgW+yFc2l+HbEchRp78xDQjjI11YeaoX1+gg uvR9NgqnuPt3GXoHDW3/+kX3i7y3tgpfhZ/oag== X-Google-Smtp-Source: AOwi7QBkEed/8mB330eVJ3Po8J4IFLSGtggpJ2KpmMH0QWyc3qTDOmADGKvxdWEY06F/g6RtOMgDyNsOVegRAcTQAzo= X-Received: by 10.202.231.139 with SMTP id e133mr3153899oih.218.1504891043355; Fri, 08 Sep 2017 10:17:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.60.13 with HTTP; Fri, 8 Sep 2017 10:17:02 -0700 (PDT) In-Reply-To: <2bddc712-3d56-0efd-058f-ff1533eb6f41@noa-archive.com> References: <2bddc712-3d56-0efd-058f-ff1533eb6f41@noa-archive.com> From: Michael Bradshaw Date: Fri, 8 Sep 2017 10:17:02 -0700 Message-ID: To: Tobias Rapp Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a1140808410f43a0558b0c0a6" Archived-At: Subject: Re: [Cellar] Status of the ChannelPositions element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 17:17:26 -0000 --001a1140808410f43a0558b0c0a6 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 8, 2017 at 5:14 AM, Tobias Rapp wrote: > > Likely 3D positions will be important in the future. Does anybody have > some experience in how 3D positions are described (Google/WebM developers)? YouTube generally uses Opus with channel mapping families defined by: https://tools.ietf.org/html/draft-ietf-codec-ambisonics That is, the decoded audio is ambisonic spatial audio with SN3D normalization in ACN channel order. There are others, though. Dolby's Atmos stuff uses actual object positions for each sound (and they move around; they're not fixed). There are others I've heard of but can't remember enough details to coherently talk about them. In short, there are several very different ways people have historically represented 3D audio (and that has persisted to the present day, and will continue for the foreseeable future IMO). The Opus spatial audio we're using gets its channel mapping stored in the OpusHead packet (which is stored in Matroska's CodecPrivate element). So unfortunately this work is complicated by the fact that some audio codecs already define channel mappings/positions (and don't need more help from Matroska), but others don't (e.g., raw LPCM) and need help from Matroska to specify what each channel means. In the end, if Matroska does add something like this, I think something along the lines of option (a) is more appealing, though I'm not a big fan of multiple ways to represent the same information. That just adds complexity to parsers/players (I'd personally rather put the complexity in the muxer/encoder, since I think there are fewer muxers in existence and muxing is less common a task than parsing/playing). --Michael --001a1140808410f43a0558b0c0a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 8, 2017 at 5:14 AM, Tobias Rapp <t.rapp@noa-archive.com&g= t; wrote:
Likely 3D positions will be important in the future. Does anybody have some= experience in how 3D positions are described (Google/WebM developers)?

YouTube generally uses Opus with channel mappi= ng families defined by:=C2=A0https://tools.ietf.org/html/draft-ietf-codec-ambisoni= cs
That is, the decoded audio is ambisonic spatial audio with= SN3D normalization in ACN channel order. There are others, though. Dolby&#= 39;s Atmos stuff uses actual object positions for each sound (and they move= around; they're not fixed). There are others I've heard of but can= 't remember enough details to coherently talk about them. In short, the= re are several very different ways people have historically=C2=A0represente= d 3D audio (and that has persisted to the present day, and will continue fo= r the foreseeable future IMO).

The Opus spatial au= dio we're using gets its channel mapping stored in the OpusHead packet = (which is stored in Matroska's CodecPrivate element). So unfortunately = this work is complicated by the fact that some audio codecs already define = channel mappings/positions (and don't need more help from Matroska), bu= t others don't (e.g., raw LPCM) and need help from Matroska to specify = what each channel means.

In the end, if Matroska d= oes add something like this, I think something along the lines of option (a= ) is more appealing, though I'm not a big fan of multiple ways to repre= sent the same information. That just adds complexity to parsers/players (I&= #39;d personally rather put the complexity in the muxer/encoder, since I th= ink there are fewer muxers in existence and muxing is less common a task th= an parsing/playing).

--Michael
--001a1140808410f43a0558b0c0a6-- From nobody Mon Sep 11 02:19:29 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B28F132F81 for ; Mon, 11 Sep 2017 02:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HuU6d1a9Hq3u for ; Mon, 11 Sep 2017 02:19:21 -0700 (PDT) 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 54265126BF0 for ; Mon, 11 Sep 2017 02:19:20 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id B698EA1C07; Mon, 11 Sep 2017 11:19:05 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 6241281AD8; Mon, 11 Sep 2017 11:19:05 +0200 (CEST) Received: from [127.0.0.1] (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) ; Mon, 11 Sep 2017 11:19:05 +0200 To: Michael Bradshaw Cc: Codec Encoding for LossLess Archiving and Realtime transmission References: <2bddc712-3d56-0efd-058f-ff1533eb6f41@noa-archive.com> From: Tobias Rapp Organization: NOA GmbH Message-ID: <94948eab-21ae-79be-4b6e-846e5a98f985@noa-archive.com> Date: Mon, 11 Sep 2017 11:19:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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: <20170911091905.28951.86878@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: B698EA1C07.A4F9B X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=-0.5, benoetigt 6, autolearn=not spam, BAYES_00 -0.50) X-NetStorage-MailScanner-From: t.rapp@noa-archive.com Archived-At: Subject: Re: [Cellar] Status of the ChannelPositions element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 09:19:28 -0000 Hi Michael, thanks for your informative summary about handling ambisonics in Ogg/Opus. > The Opus spatial audio we're using gets its channel mapping stored in > the OpusHead packet (which is stored in Matroska's CodecPrivate > element). So unfortunately this work is complicated by the fact that > some audio codecs already define channel mappings/positions (and don't > need more help from Matroska), but others don't (e.g., raw LPCM) and > need help from Matroska to specify what each channel means. Ok, so there should be some statement that in case no channel mapping elements are defined on container level the audio channel mapping should be taken from the codec level. Is it necessary to explicitly disallow storing the mapping on both container _and_ codec level to avoid muxer conflicts? > In the end, if Matroska does add something like this, I think something > along the lines of option (a) is more appealing, though I'm not a big > fan of multiple ways to represent the same information. That just adds > complexity to parsers/players (I'd personally rather put the complexity > in the muxer/encoder, since I think there are fewer muxers in existence > and muxing is less common a task than parsing/playing). My idea was to implement both elements (a) and (b) together, one indicating the type and the other containing the actual data. Both elements could be merged into one, using the first byte(s) as a flag for the type of data that is following. I had chosen two separate elements as it seemed to better match the EBML-style, but I have no personal preference. And yes, not all proposed ChannelPositionType values are actually necessary. Having worked a lot with BWF/WAVE files my minimal requirement would be the "Channel Mask" value type. Regards, Tobias From nobody Fri Sep 22 05:59:43 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684B1134320 for ; Fri, 22 Sep 2017 05:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, 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 83U1WvCjzTet for ; Fri, 22 Sep 2017 05:59:39 -0700 (PDT) Received: from mx02.mail.netstorage.at (mx02.mail.netstorage.at [89.207.146.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D87132F76 for ; Fri, 22 Sep 2017 05:59:38 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx02.mail.netstorage.at (Postfix) with ESMTPS id 7C5BAA0C2B for ; Fri, 22 Sep 2017 14:59:23 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 2A32B82933 for ; Fri, 22 Sep 2017 14:59:23 +0200 (CEST) Received: from [127.0.0.1] (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) ; Fri, 22 Sep 2017 14:59:23 +0200 To: cellar@ietf.org References: <2bddc712-3d56-0efd-058f-ff1533eb6f41@noa-archive.com> <94948eab-21ae-79be-4b6e-846e5a98f985@noa-archive.com> From: Tobias Rapp Organization: NOA GmbH Message-ID: Date: Fri, 22 Sep 2017 14:59:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <94948eab-21ae-79be-4b6e-846e5a98f985@noa-archive.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20170922125923.15966.14079@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: 7C5BAA0C2B.A75AD X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=-0.5, benoetigt 6, autolearn=not spam, BAYES_00 -0.50) X-NetStorage-MailScanner-From: t.rapp@noa-archive.com Archived-At: Subject: Re: [Cellar] Status of the ChannelPositions element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 12:59:41 -0000 Hi, there are some possible directions for further development of this topic and I'd like to get some feedback on which one is preferred: Option 1: Don't add anything regarding audio channel positions to the Matroska spec. Information is available to players for audio codecs that include channel position data as part of the encoded bitstream (Opus, AAC), for audio codecs that miss this information the player has to make assumptions (PCM). Option 2: Add some generic audio channel position element(s) to the Matroska spec. Information is available to players for all audio codecs, in case the encoded bitstream also contains channel position data the Matroska spec should define which one takes precedence. Option 3: Add audio channel position data to the codec mapping section of the Matroska spec. Channel position data is stored within CodecPrivate element only for audio codecs that do not provide the information as part of the bitstream (PCM). Opinions? Best regards, Tobias From nobody Fri Sep 22 06:24:55 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B46C132F76 for ; Fri, 22 Sep 2017 06:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 rZFSn4T1TUN7 for ; Fri, 22 Sep 2017 06:24:51 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182E8132D51 for ; Fri, 22 Sep 2017 06:24:50 -0700 (PDT) Received: from smtp5.infomaniak.ch (smtp5.infomaniak.ch [83.166.132.18]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8MDOmUO010578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 22 Sep 2017 15:24:48 +0200 Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8MDOlU2029782 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 22 Sep 2017 15:24:48 +0200 Date: Fri, 22 Sep 2017 15:24:48 +0200 From: Reto Kromer To: Tobias Rapp cc: cellar@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Status of the ChannelPositions element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 13:24:53 -0000 Tobias Rapp wrote: >there are some possible directions for further development of >this topic and I'd like to get some feedback on which one is >preferred: Ha! Will you be in Vienna? I have included in my wish list that one too. In my presentation, if accepted, I have included some wishes for all - EBML, Matroska, FFV1 and FLAC -, originated on my experience from the field. Best regards, Reto From nobody Fri Sep 22 07:40:46 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C45013447C for ; Fri, 22 Sep 2017 07:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 c93CWGPDeIpN for ; Fri, 22 Sep 2017 07:40:43 -0700 (PDT) Received: from mx02.mail.netstorage.at (mx02.mail.netstorage.at [89.207.146.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8433134473 for ; Fri, 22 Sep 2017 07:40:42 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx02.mail.netstorage.at (Postfix) with ESMTPS id 998E5A0C27; Fri, 22 Sep 2017 16:40:29 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 4422982530; Fri, 22 Sep 2017 16:40:29 +0200 (CEST) Received: from [127.0.0.1] (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) ; Fri, 22 Sep 2017 16:40:29 +0200 To: Reto Kromer Cc: cellar@ietf.org References: From: Tobias Rapp Organization: NOA GmbH Message-ID: <313f4463-8c99-1a53-396a-73ce724e8d07@noa-archive.com> Date: Fri, 22 Sep 2017 16:40:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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: <20170922144029.29606.65080@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: 998E5A0C27.A53B1 X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=-0.5, benoetigt 6, autolearn=not spam, BAYES_00 -0.50) X-NetStorage-MailScanner-From: t.rapp@noa-archive.com Archived-At: Subject: Re: [Cellar] Status of the ChannelPositions element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 14:40:45 -0000 On 22.09.2017 15:24, Reto Kromer wrote: > Tobias Rapp wrote: > >> there are some possible directions for further development of >> this topic and I'd like to get some feedback on which one is >> preferred: > > Ha! Will you be in Vienna? I have included in my wish list that > one too. In my presentation, if accepted, I have included some > wishes for all - EBML, Matroska, FFV1 and FLAC -, originated on > my experience from the field. No, but some of my Vienna colleagues will be there. Is some Matroska/FFV1 working meeting planned for No Time To Wait 2? Best regards, Tobias From nobody Sun Sep 24 06:25:18 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A76133078 for ; Sun, 24 Sep 2017 06:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBm-ISkBEOC0 for ; Sun, 24 Sep 2017 06:25:14 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B72F1201F8 for ; Sun, 24 Sep 2017 06:25:14 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id x131so3221810ywa.10 for ; Sun, 24 Sep 2017 06:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Yolpr9s80D8k48j6wwM9OhRzLzEBevBdY6zDx16wBBk=; b=lvDVx0enJZSpLSLqZuIB4kw+SSryqGMqWaA90h4C+Ym9fwvHCZ+KqjjAl0DKx09NDA iAiMzKSrNOLmdn94o3J1C3mk6/TfN6Rc3tkQvgmFTaTkApQeZ0JGyCIFAC46p4JigeVS dHK+DcQ8Iun+NBYyJAIAp2PCQ9J4SaAyHAH80XlyNLN9HpM5qW6s86u12vbq5O7vOFib BmLZJosmcpbdxlKpXhzWMhtSHNhBlaXeonK+6buGlivqKYO2QCqWXTj4SWC3pap3Lbvh bB01GHFmneEowGwKvxyL9zduj6BQFXXKxTZozrzbxUkDWsH+9rJ5k89uAoyWZiBrrbm4 TCDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Yolpr9s80D8k48j6wwM9OhRzLzEBevBdY6zDx16wBBk=; b=J9wrkZXAddvvDN4gNuQjxWQvS/9F8lfq7Of8GUMIt13vbvQmwZqeIivKNTHjrowCN9 z1NV9z+D9+XnJ46L+ATFMDjlbCu3WN8ilpqLKK+KSif/q00AAK7jYkzoizXjUHRvstVJ nxYpmD6DpPdCDKMKGD8XhQxfXPVr/2QT9ln2b27wxKNOgaWCfkvHzJs1C49uR53cKBlJ uwnooJOl00/q3VsNrfQl0c/ZkRqHyW83tDXOOxhcjIbc1Uz3nOCKPTOYjc7TRFzQlH0r Ter4Rlcpo7z+ljAGDI3s4sFR5t1wi4N77PYeaCp8+6RGUbakGbpCVaQXgiMGMPJdxFhJ kakA== X-Gm-Message-State: AHPjjUjVmVul5+lLUS/sAlG1slgi6EBPJG4MolhDodqmixhVdQ1140Li KmSjHC7h6jFg1na8NSuxxULwRiecOkRzcxXlLBtoFMLT X-Google-Smtp-Source: AOwi7QDO7+nUEZwt2IzSU/9ovSE6rAHmUh85LFsKEsanFrQxIV5WRwc9yw+mO+OeqnGouKuJsoZwm48fbnudsmvNJy8= X-Received: by 10.129.78.207 with SMTP id c198mr2826744ywb.121.1506259513492; Sun, 24 Sep 2017 06:25:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Sun, 24 Sep 2017 06:25:12 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 24 Sep 2017 15:25:12 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Implementation hints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 13:25:17 -0000 IMO that's something that doesn't go in specifications (hence the idea to remove them). IMO it doesn't go in something that goes through the IETF process either. I think it belongs either on the website or Github (or both). It might also go with the conformance test files that Dave has been working on. It would be good to have one location about tips for muxing/demuxing, testing, etc. 2017-08-26 18:19 GMT+02:00 Ashley Blewer : > Thanks Reto! > > Related aforementioned convo is here, in this PR: > https://github.com/Matroska-Org/matroska-specification/pull/168 > > Ashley > > On Sat, Aug 26, 2017 at 11:50 AM, Reto Kromer wrote: >> >> Hello, >> >> we are currently discussing on Matroska's GitHub (and previously >> on FLAC's as well) about some implementation hints, that are >> present in the current specifications, but should be removed, or >> about hints that were given while discussing the specifications. >> I guess it would be useful to group these hints in separate, >> specific documents, instead of archiving them... in the rubbish >> bin. In my opinion, they can save a lot of time for those who >> wish to implement the specifications by programming a parser or >> a player. >> >> Best regards, Reto >> >> >> AV Preservation by reto.ch >> chemin du Suchet 5 | 1024 Ecublens | Switzerland >> Web: | Twitter: @retoch >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Sun Sep 24 06:36:34 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC32213308D for ; Sun, 24 Sep 2017 06:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRslGp-dAvMA for ; Sun, 24 Sep 2017 06:36:31 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE3313308A for ; Sun, 24 Sep 2017 06:36:30 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id x131so3229968ywa.10 for ; Sun, 24 Sep 2017 06:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=43FFk/MoWxj+SPo+6ycyUUwecTVrLY0C/3xHL07UpOc=; b=ArOfgt93vAUedcx4wiI/rkmI7RWIfYFWdlbPWkLJWvf7DIUuBmmbnQo2GnqtWu7kND J+Mysy2XvWvX45Wg0yDYvpvBp2cy4LU2jkOS162HdatbzPNxoVCogX/I049VFUm8vfta 5JpYvbFCRjzMPzw7NAD5HFtQSKCBrfOPHkvQuBVkHQtqLNTnn7eTI2vH5axOBd6QiCZO HcsW2ZJLoHfqWoUZTV8uUDARvwIuurRfcxCcnqR+wMhr63kmf2394eLAeVbfBgMf62tn R5f7Q7Ng0NkUVCeMMSXHwoN9pmW43dhwC1dlDTrENGJPaUSIWFbFyNRdxbbBbKKNaECc 1xWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=43FFk/MoWxj+SPo+6ycyUUwecTVrLY0C/3xHL07UpOc=; b=Pxb+Gb/YXpm/wB4PfVYJHdtvgTxKNzZzRihDpCk0u9G5hM5mc8QYmvTAHRZk9OXIQ1 I6TJC458I0vtRRry/Duhr7avtc5R9xMfOyqua+peWYAsZwCEKI/HphiQlCsIXsTcxL8V jTeCr16aLvLfQddc30cfPyhNPxhAeMLG4fJ79JfXZgoaQ5zAbIOkDQW6f3tnDutgDvpf u+EW2zt6gu7ywT6SsS2oydM2WP4iN4/FdiLsrbSFrUEbbzAmY/T3BU94Qz6tZP68cb1A im2j7RYVvw+P0gBGEkFPKzcyA1OUwK/EUD5kXrP3clrYB4DqgZkKuUojU08vQEzbjtxB ZzNg== X-Gm-Message-State: AHPjjUjlQr2U6l87zmRkyfOpuNMNAlGr+zAzkIBeBxzsFM3W5dHl6pHy 1wQyWGJDKldlx3UCuJyGpR2EcuCjsbzNk4rEEeDZKw== X-Google-Smtp-Source: AOwi7QAhD4WcZIKuKgrfRMYmPdMf0E9YFkZgiyUs5veMPVzGNZd3ipjivT0cl/Nxi9TnFV3JqsZogp2Y1BwOgGwTmh4= X-Received: by 10.37.72.4 with SMTP id v4mr3016373yba.36.1506260190156; Sun, 24 Sep 2017 06:36:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Sun, 24 Sep 2017 06:36:29 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 24 Sep 2017 15:36:29 +0200 Message-ID: To: Tobias Rapp Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] EBML element identifier assignment X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 13:36:33 -0000 2017-09-07 15:32 GMT+02:00 Tobias Rapp : > Hi, > > just out of curiosity: How are EBML element identifiers chosen which are > used within Matroska? Often-used elements seem to get a shorter > identifier which in turn determines the most significant bits. Are the > remaining bits assigned randomly? Elements with only 1 byte are usually only for elements that we are sure will be used a lot in the format (outside of the default value). Elements with 4 bytes are the higher level elements that we want to seek to and recover quickly without false positive when there's damage in the file. The rest of the bits are no exactly random. When possible they use a character or ASCII symbol that can be associated with what the element is about. So when you look in binary it almost makes sense. Some values that always go together also have incremental values from one another. > In case some vendor would like to add a new element (theoretical > example, I have no current plans), is there some "reserved range" > similar to the Private Use Area of Unicode? No. It would be good to keep track of them in some ways through. Like the DivX ones for example. > Regards, > Tobias > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sun Sep 24 06:50:00 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAC91321F5 for ; Sun, 24 Sep 2017 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L30DNUhg3R2M for ; Sun, 24 Sep 2017 06:49:56 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39238126BF3 for ; Sun, 24 Sep 2017 06:49:56 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id p10so3247124ywh.8 for ; Sun, 24 Sep 2017 06:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CEuow/Y10VY2Xvgt6uNGbVRGUMLj2lpu8A5hLecdGuA=; b=u4lJdPNiJvBF4b1+WdQZd0JICMjLuKceeaiQzR9BUo7n9ACrtR/W105cOvhBK/HIjo 1DsLEJQhB6duNhvnYM0vaPhgbIrk2FZ6gkfJcDkF3azBAtYVAMre16tu1oON9syvUuVI xLugylHwCxF+7BrZCPBWzdSR+BpVFWrD6y2oAO6z3rmVyUp5JvC6LSCR0KJtngvpZuJ1 BdxjEYYiUPHbkK122BonGDELi8KFMV4/FYpddbh191b0Yd20Yux9eI/6rluZw5NFgpZk 7QHQA9/xPPX/ws/bc10g64Mgym3m78ntVetjHankG4TsgKDxLdg2hAq8AXqb9FluT/F+ ktjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CEuow/Y10VY2Xvgt6uNGbVRGUMLj2lpu8A5hLecdGuA=; b=q0XzmrUpHefJZN/cocIB9dKL+KaFFjM5mNPAv0niAZrhoIOWvLHf4jBqycRrNhSD15 54W1E/5W+hlMPYIcDkcmqEb8y9d0GgyA87N4eYd9094w1P8JXKgs1RBmjqc+lDj0WUG5 7h8bcwbXUJw8ceS5PSVr0d9iJ2x+V7ERyiHn2rtMFcSxHg3kbFrjzZc9ONPo3hdXJqUE Bxopsjf94rFM82yb+fbkyW51cYbyFBnvdLS7ivRkikOchDEb80noqN9D49w5iLjQ1Pgd n0VJncG/UjCQ3bi9XxqXql3oAokX7fFliHISL5BXtJRogEsO9IwO70DDPWhl7AgCpXkK zjEA== X-Gm-Message-State: AHPjjUi21d5i5FNzowyrNGIHXujmdHeIOTfd4nFW7vBnQxbSDrEDj8nZ cHVTaPGJhMCsjqT5DtD5dfuhl/wMuWj8m7xnY0HsWA== X-Google-Smtp-Source: AOwi7QAwbepgx8rjnrn53v+PSNjT3oYXjDslmFsNS/z17mrFP03P1Z/V41jGc5w/pQmucYJpI5koP8botpc0UaR+z8U= X-Received: by 10.129.78.207 with SMTP id c198mr2855990ywb.121.1506260995387; Sun, 24 Sep 2017 06:49:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Sun, 24 Sep 2017 06:49:54 -0700 (PDT) In-Reply-To: References: <2bddc712-3d56-0efd-058f-ff1533eb6f41@noa-archive.com> <94948eab-21ae-79be-4b6e-846e5a98f985@noa-archive.com> From: Steve Lhomme Date: Sun, 24 Sep 2017 15:49:54 +0200 Message-ID: To: Tobias Rapp Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Status of the ChannelPositions element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 13:49:58 -0000 2017-09-22 14:59 GMT+02:00 Tobias Rapp : > Hi, > > there are some possible directions for further development of this topic and > I'd like to get some feedback on which one is preferred: > > Option 1: Don't add anything regarding audio channel positions to the > Matroska spec. Information is available to players for audio codecs that > include channel position data as part of the encoded bitstream (Opus, AAC), > for audio codecs that miss this information the player has to make > assumptions (PCM). > > Option 2: Add some generic audio channel position element(s) to the Matroska > spec. Information is available to players for all audio codecs, in case the > encoded bitstream also contains channel position data the Matroska spec > should define which one takes precedence. > > Option 3: Add audio channel position data to the codec mapping section of > the Matroska spec. Channel position data is stored within CodecPrivate > element only for audio codecs that do not provide the information as part of > the bitstream (PCM). There might be option 4: always have a value set in the container and optionally in the codec if it wants to. One of the possible value(s) in Matroska could be a special value "see codec" for things that are too complex for Matroska. In general, for playback, it's good to know before you start decoding how you have to configure the audio output and that involves how many channels and how they interact with each other. And the best way for that is to look at what the container says. Before parsing the actual data and opening the decoder. With PCM we need to have as many mappings as possible anyway. It can't be left to interpretation. I like the 2 elements approach. For stereo, multichannel and object-based things can be quite different. It's at least good to know if a track is either 3 of these types (there might be more) before selecting it. And the way we store the actual mapping for each can be different. But we need a way to specify how each format is going to be stored. We may even have 3 elements: multichannel, ac-3 style, binary blob with a custom mapping. > Opinions? > > Best regards, > > Tobias > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sun Sep 24 07:17:23 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC2013308D for ; Sun, 24 Sep 2017 07:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 6AKNMrWwCsVZ for ; Sun, 24 Sep 2017 07:17:20 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0C0132055 for ; Sun, 24 Sep 2017 07:17:20 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8OEHIE6024556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sun, 24 Sep 2017 16:17:18 +0200 Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8OEHH7J052491 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 24 Sep 2017 16:17:17 +0200 Date: Sun, 24 Sep 2017 16:17:20 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Implementation hints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 14:17:22 -0000 Steve Lhomme wrote: >IMO that's something that doesn't go in specifications (hence >the idea to remove them). IMO it doesn't go in something that >goes through the IETF process either. I think it belongs either >on the website or Github (or both). It might also go with the >conformance test files that Dave has been working on. > >It would be good to have one location about tips for >muxing/demuxing, testing, etc. +1 for GitHub From nobody Sun Sep 24 07:50:18 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B86913308D for ; Sun, 24 Sep 2017 07:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7r6C61CI3yI for ; Sun, 24 Sep 2017 07:50:15 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7671C132055 for ; Sun, 24 Sep 2017 07:50:14 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id q8so4597678qkl.12 for ; Sun, 24 Sep 2017 07:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PjHNp08U7AX8C4Ba1uFqKGNzqkuVbffgV4Z1KlrWBR0=; b=i5lbgNwvd/UB94fkMGIGrFipGK7ejf9boWDsvh0xeY4p9wUBST42txok3DUT9bipNe NdRvHzUEIOe+LgOdSrulZnQC6FQzIevA6z0CsWI3moehr5Q1TX0Xhf1hmN6jqVEmfSe9 Ukg478IoNoHZ25utJWgECdf3lM5EcTEhoyf8xlfT2F+3VigsZ9+hogdLH+3QaGqekb5m r8RKEHe7Wq3E29ERuM2dWMiaoZE7vHqwu8KiikWfBt689PIB7KM2H0CrNzheq0vH0Mw1 +xMsYrw6H3zSuPMAHpt5cV7orYpK5VSMR11BuyhA0tZ5NAAGEezbpETWp+IccdIGh+q5 Pwhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PjHNp08U7AX8C4Ba1uFqKGNzqkuVbffgV4Z1KlrWBR0=; b=fL2rA9HKA5yMhfJdS+iiEnTZJUKmx0aBh8UMeA67UEOQwU90LyDWCaxJtW3RbX+JEj OXspt8UOz4wiQ8Sl4Wt/AcrA6Kp/6o9Vz02V89D4FxKoY15Zi/p5OM4cwTaN8txDKo/d qQMqQNZrqUURo+oPcVXDqrSlv1qGb2iaZ7EvPKip+gWg0aidL+jnccjeE2qnexY1+e7X eeVT9pf0wjmRnnVjI59vsLSMDBj9oIWvWZ5ooLbbFq8QSw63Uda3kdgUNvoQGMf5zCuV 63nqmofdFmUrfnoXQNWjTwv1SEyDwUCVo0fga4NWzPVlKZZ6uMUs87bI3mexAu3GiUcT fXLQ== X-Gm-Message-State: AHPjjUgZxcMYVZ2DlM1SXs/TRq1lfjrMiaDqtKMsajOq+h+ZIh3kddUi 97ofcRWn68hlUbuexoroaTD0xgYzImEDSISoSshYrg== X-Google-Smtp-Source: AOwi7QB/HyhKXwvyMmTnSB6nGOYFXfzcWTMWVJP+VTy51FltfoD+xE5CoEkINfmFjd8PIzNXucuQO0B/Y4WXqjh8TqI= X-Received: by 10.55.102.73 with SMTP id a70mr6408523qkc.345.1506264614074; Sun, 24 Sep 2017 07:50:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.242 with HTTP; Sun, 24 Sep 2017 07:50:13 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Sun, 24 Sep 2017 10:50:13 -0400 Message-ID: To: Reto Kromer Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="94eb2c057bf6427e420559f08ff2" Archived-At: Subject: Re: [Cellar] Implementation hints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 14:50:17 -0000 --94eb2c057bf6427e420559f08ff2 Content-Type: text/plain; charset="UTF-8" Good because we removed it. ;) On Sun, Sep 24, 2017 at 10:17 AM, Reto Kromer wrote: > Steve Lhomme wrote: > > >IMO that's something that doesn't go in specifications (hence > >the idea to remove them). IMO it doesn't go in something that > >goes through the IETF process either. I think it belongs either > >on the website or Github (or both). It might also go with the > >conformance test files that Dave has been working on. > > > >It would be good to have one location about tips for > >muxing/demuxing, testing, etc. > > +1 for GitHub > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --94eb2c057bf6427e420559f08ff2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good because we removed it. ;)

On Sun, Sep 24, 2017 at 10:17 AM, Reto = Kromer <lists@reto.ch> wrote:
= Steve Lhomme wrote:

>IMO that's something that doesn't go in specifications (hence >the idea to remove them). IMO it doesn't go in something that
>goes through the IETF process either. I think it belongs either
>on the website or Github (or both). It might also go with the
>conformance test files that Dave has been working on.
>
>It would be good to have one location about tips for
>muxing/demuxing, testing, etc.

+1 for GitHub

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

--94eb2c057bf6427e420559f08ff2-- From nobody Mon Sep 25 05:02:57 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3D71342D6 for ; Mon, 25 Sep 2017 05:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbeSgn2OrK22 for ; Mon, 25 Sep 2017 05:02:55 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DB91342DA for ; Mon, 25 Sep 2017 05:02:55 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id q80so4521838ywg.2 for ; Mon, 25 Sep 2017 05:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=v0kOz0CHWa5z6unjtBTxiLm2VnA6c1cAi/1G4BqHjCY=; b=JnQ1KOD5NYfDxGE1Djw6VAlGpbZwGi1nP2mPWrkjXUA7747HomuxzCRdSY7npUyPjY poooBwbvciA+tEqOxoBhehRBI9JwmOQB4xC9DQBoGcIJQ+DA9S67vq1+nJyaijNSMgc3 3udzB2pRLZ8w/bZLbusZrYOZw2gEGHsePtA2VuPadpFQTfHBL8BLALuxf7dzAkMLzfNE ClfPfUR+S77riA2qPzxS8OV/K3KOqn6NoRAopnWE4eDCkaEndIQOLFTbiW2E4U018p23 tqEpDdHz04X8W+LtkZDiZAyTMK577abZmF7uO/Gvp/q67TrYC+nis+00uL1LBR2+mN3S vevQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=v0kOz0CHWa5z6unjtBTxiLm2VnA6c1cAi/1G4BqHjCY=; b=fqX3LdmKrpv7A4jmb72ANofeCgYW7HMLGRyVQ2FxdKSDTVzMbV3XNiF1oGXWPqtMfl 8Vh/CjAtMrrLFdWIOP0lgY+ax9REFc0MdaQwBbMD8SGpSW1uDAP2t8HluoZNG+qGNd5t RKLPHvJU6nISQJEBKIFES6ZV7aZ3iH1BsvvSjSFD2//fQk1JJoxuzctHHC8CzM342+e2 yzl1MYFQbVZnE+3BRpW2BwR9f9HNzOn+vgJSbwZvFeYlf93y/HzQu6wnQB5aOSbKmfqR j12tYy7T5dswMXKbzfEzYl3HpnfpRRSwls7EVIhXmxrvkg6C49aFOfKm0kgUQobQ0bJg R/wg== X-Gm-Message-State: AHPjjUjAGrOdWtLZPDd3NjH5bLk4smBEk2ww/ainSWsTHl6ogDik1QIz +5xvfG9C3suRRe8aZnPui7MXbrhWuKCrPYskAWu9HA== X-Google-Smtp-Source: AOwi7QAJ6OZQ4WmfEL6a4KINXzNSD2Ziu2H1ovWzWNVnJWRxUqy+FEnaPWjNz8q3foYLPGjDcUg89KQQ0wL55WkoiSo= X-Received: by 10.129.145.22 with SMTP id i22mr4209871ywg.259.1506340974602; Mon, 25 Sep 2017 05:02:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Mon, 25 Sep 2017 05:02:53 -0700 (PDT) From: Steve Lhomme Date: Mon, 25 Sep 2017 14:02:53 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:02:57 -0000 As many of you know, in Matroska we use(d) the work timecode where in fact it should be timestamps. It goes as far as names in the code we use. This can be confusing for people who can actually tell the difference between the two. And since we plan to introduce timecodes, it might be a good idea to make this change. The XML will keep the old names in the cppname so the generated code(s) remain unchanged. Also some defines should be added with the new names and the old ones marked as deprecated. -- Steve Lhomme Matroska association Chairman From nobody Mon Sep 25 05:38:35 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB231342EE for ; Mon, 25 Sep 2017 05:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmT7bqofftQA for ; Mon, 25 Sep 2017 05:38:32 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A5E133226 for ; Mon, 25 Sep 2017 05:38:32 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id o42so7476631wrb.3 for ; Mon, 25 Sep 2017 05:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=VlLuT1S1ol0h/3Tu/NIZOOzaaQp9V7hgrBFFEDmO/ds=; b=bpd9JKg/XPuhR4etLFc+FmN9BuBQoCHJgiEKwcveKCujMH4PmQE4eeOqL+eJ3fWOfV B7VGYG2n0SkTDEm5s0eHpkGy/XWAMnDgtxgQb0pRVHJzXGN1dZvCyRwnEjnleJT0mNDU uXSAaE4R4pEsrT2mqgIyfJbinNdhQLYTkDGFxcyX6MT3TTWuQLM0vEU6Ga1ak4Va2ejN 57x8E/k+wVxVw1bSSo89a/14pw/acvd4cWMwXeY7utXxlpXodSG1PiNJm44LyOY4vm33 KI6KgYQPTGvacnVu4eOXnBpMHMjhZ+0Th6PZn2BBlKF4qAZWGXBPcn8iYxvOanADMv/+ +ZSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=VlLuT1S1ol0h/3Tu/NIZOOzaaQp9V7hgrBFFEDmO/ds=; b=HIHqIQAi1ywETSDN6tfrwNyIEcvC9mYvbgh+D+PJ7gPCp1mIKSW3dkSAG2U4ugZ6lv Ejc4iHDvl8yrWVyUKrbWAd0uw8Eg5bP7Y1Ph/nN/ejmNeq3Ywow91FMfKkCo0qiGBPSD RkdMNiHWZKdap9jQDDHZFpDJPJEn17poJqurpkOoWtttBwc8/hvmkNj+YXnvThJkUPi4 Jlmw7qSgiI+rdRUcmDXu67YzXWH4+A4QF4ECR/I5PuKQOLHnaMlmQLnGKfAnHcy1YJVo DV4fiMryVqYpklIx/v9bNdEzOwOuDKpkr1qlyxgulbKTvs8OAlWH33c78OEvU53Ln+08 ALVw== X-Gm-Message-State: AHPjjUhq87GYemzFMw8fZs9SUpIVowvjLosmMd9h2HNgTy7Yq1AX7DBB ep4WBanaPa3Uz6mPT4n/icKX9MSNp0MMrg31LWOn X-Google-Smtp-Source: AOwi7QBeB09B+AFcFzEKJ3q5boarnyrkdS/KFelDP76yHg30IjTnhATgBGxKf4/eTdAKWYaxU3I+/OKNvrHSGLFSYD8= X-Received: by 10.223.176.46 with SMTP id f43mr6586846wra.206.1506343110730; Mon, 25 Sep 2017 05:38:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.6.2 with HTTP; Mon, 25 Sep 2017 05:38:29 -0700 (PDT) Received: by 10.28.6.2 with HTTP; Mon, 25 Sep 2017 05:38:29 -0700 (PDT) In-Reply-To: References: From: Kieran O Leary Date: Mon, 25 Sep 2017 13:38:29 +0100 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary="001a11438d5a066ce3055a02d64b" Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:38:34 -0000 --001a11438d5a066ce3055a02d64b Content-Type: text/plain; charset="UTF-8" +1 I think this would be great, I find the current naming to be confusing. --001a11438d5a066ce3055a02d64b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

I think t= his would be great, I find the current naming to be confusing.=C2=A0
<= /div> --001a11438d5a066ce3055a02d64b-- From nobody Mon Sep 25 05:40:33 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89FC1342E6 for ; Mon, 25 Sep 2017 05:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsPGOZq2e10F for ; Mon, 25 Sep 2017 05:40:31 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3257D133226 for ; Mon, 25 Sep 2017 05:40:31 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id q124so19100167wmb.0 for ; Mon, 25 Sep 2017 05:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=p6t7MtDj4kyOdwO+9ZETqHaSYEEPpkG//vUUIXoKDuI=; b=BBDCi8hQe+2KgDfrWOYdpSRjGxLzcmgAKE8HVxb6oUOKgdWmLqHB6FEte+5SFJLl9J y2yi8wCzaGdi6haT6+ImzlXccViVZKkZzOp4QPOhhz88SE478xpzF3QXrXa//4A8QtUi yozMjDq29UhNROGTbZtJubXiiQAGY6pbyI0XN2y9uuvaJQpKlgXeZKmGlddBW3WYo7YC p6R3m+0I8Jotn/f+KkGxmD156AKgOz1HKx5/MmWyla/Llcn2qA/a4TiDtVUvRTs4g/zr ADHsV8oE/O5hFmH6hJ4MVkbIoZrZ+9330P56b1EGG5BgPilq0+batptB8Y2ldzZYymVs YIsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=p6t7MtDj4kyOdwO+9ZETqHaSYEEPpkG//vUUIXoKDuI=; b=OK/gYq393OUqxsl/dGSLBvcsXNsR2yjP4GynsaPrPwdSngh9pHvqjmdJjHpWxkYkB2 AdVcmTMQdQtuLputblahPwHUOpBhVM2qLFs9ZWT9Cx9RhC+4pQsxcf22oGnQmuriaOR0 69nqY70yqetUG9Va50MzIPFrkkwR9smWXMSfO+AvzxiMIIi1oXD2Kf/bHBJV3acqYuDa bX8Ilq6CZJEFD8J0pT726j8d6xj598apT0VB5dKuKIZz0z80t8msXd2QBCXdqvzV3tza h7/kX3KzaeaDHB3Ke5w59GhzyZm715PSpcIaM/Anur0y2urvCBt3IwfJfF56HGi07Nvg muBg== X-Gm-Message-State: AHPjjUhRLJ26+W+TAzea9QHLL/UeQ+UA+osMydhfbUhHn6j6Xay3J3jH ++IbZ4W2xRh2I3nX70sF9mztzxkZ X-Google-Smtp-Source: AOwi7QD5XDh07xwZeN46HOcUOLCYxgKbrCoUPFEh6IfG0i8BpUQOJ7JRDZkKs3rQ6dF81U+VYhu4VA== X-Received: by 10.80.190.77 with SMTP id b13mr13794190edi.184.1506343228410; Mon, 25 Sep 2017 05:40:28 -0700 (PDT) Received: from [192.168.1.159] ([82.129.104.219]) by smtp.googlemail.com with ESMTPSA id k8sm4048014ede.91.2017.09.25.05.40.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 05:40:27 -0700 (PDT) To: cellar@ietf.org References: From: Derek Buitenhuis Message-ID: <66b1ca6f-6fbe-4568-c0ad-f04cc1430927@gmail.com> Date: Mon, 25 Sep 2017 13:40:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:40:33 -0000 On 9/25/2017 1:38 PM, Kieran O Leary wrote: > > I think this would be great, I find the current naming to be confusing.  A hearty +1 from me too. Fun fact: my introduction to the FOSS multimedia community on IRC was me arguing about timecodes being timestamps due to this weird naming ;). Many years ago... - Derek From nobody Mon Sep 25 05:42:01 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0BE1342F6 for ; Mon, 25 Sep 2017 05:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sx10ciG6ojck for ; Mon, 25 Sep 2017 05:41:59 -0700 (PDT) Received: from 10.mo177.mail-out.ovh.net (10.mo177.mail-out.ovh.net [46.105.73.133]) (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 0B12C1342F1 for ; Mon, 25 Sep 2017 05:41:59 -0700 (PDT) Received: from player688.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 52597806B4 for ; Mon, 25 Sep 2017 14:41:47 +0200 (CEST) Received: from [192.168.2.120] (p5DDB6596.dip0.t-ipconnect.de [93.219.101.150]) (Authenticated sender: jerome@mediaarea.net) by player688.ha.ovh.net (Postfix) with ESMTPSA id F1838200B2 for ; Mon, 25 Sep 2017 14:41:46 +0200 (CEST) To: cellar@ietf.org References: From: Jerome Martinez Message-ID: Date: Mon, 25 Sep 2017 14:41:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Ovh-Tracer-Id: 17981465938834886801 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelledrjedtgdehjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:42:01 -0000 On 25/09/2017 14:02, Steve Lhomme wrote: > As many of you know, in Matroska we use(d) the work timecode where in > fact it should be timestamps. It goes as far as names in the code we > use. > > This can be confusing for people who can actually tell the difference > between the two. And since we plan to introduce timecodes, it might be > a good idea to make this change. > > The XML will keep the old names in the cppname so the generated > code(s) remain unchanged. Also some defines should be added with the > new names and the old ones marked as deprecated. > +1, but we need to put notes about the old name presence in old doc, so nobody is surprised to find a different name elsewhere and can "map" the old name to the new name by reading the up to date spec. From nobody Mon Sep 25 06:19:41 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5711342AC for ; Mon, 25 Sep 2017 06:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Fm3gYiNLicQ for ; Mon, 25 Sep 2017 06:19:38 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F06C12421A for ; Mon, 25 Sep 2017 06:19:38 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u11so4678699ywh.7 for ; Mon, 25 Sep 2017 06:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+GoM4bNf9bwrJkZLNV8HDL99aeKWCBAYhw/94Q6J0jA=; b=oKhvbbJO+IInKG7Tuy6XxQXHFUJ8PhMbTbysYM75pIYyu2BtJRcrWns91kQwuDbX2W iXskmmZVKUbb7HlBQyGKa3QTA0JJwxpH1cua8DJXWXN6JH6WaWdKK6wEwt6seEkgGyo9 BYFrbGiETnl+QrD9Z0GHnVt0GptSCSGmXqBv79p7a34MgCW8knAvtXoWeGQhweKTjt1M vT+oUAmbaqsK4z3z/J0xFfJrTBTbmXeBMBUYTP9yiDlF4IekO6Szb6dp0jCwkgzz6H99 y9ymxQi41f3aevyucPiMYK5W/Uje8IV5oKwUKGbmpKaPnSv231xaCJX7uYQ7v+HzwTPE Wlmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+GoM4bNf9bwrJkZLNV8HDL99aeKWCBAYhw/94Q6J0jA=; b=CyXiPAZzjGbILjrVuE3/uifhzHUem7pGF0Kq4yF7Qya1jHD/GM8+l+ijNGLQjOVdIg 5VzX/aWLCGGg52ZmCeqB07n17w5vxHqzYMkMrbRAtYwFnImi1Js5dzLIUbJ0QINGolWl YGNfBWiEzZd+jbh8dFuyPg2j6XRGUMPjrXwW1QW4OqY6Z+hu1rN2S+L7PrFf/RF+wArR wBqXidyAEgi85GFw8pVPuGy7G96YoAlGlZ3a/Ff+Gsw9yYcSaktezG0de2DxpdVvR3vg 5JrCpbooTtu7XMYLLxTt2VMRSuI5tbGQQ2WjjBalP4+opZoJVQiVNUqgOrdZj975qkFl V1GQ== X-Gm-Message-State: AHPjjUhM62HzJrJRW7alDee/bxIIA840M6+r5LolBU0zaZIGJxye51pX FJHmdo6XTit2FagjtwMwIikGjmQraoNW6zKdmVdR44mV X-Google-Smtp-Source: AOwi7QD2WT7uPeEHwtIDEJV3KlEZ3MpduV8ymIoEaV4UpMSCYC1il+rcNf2rYpO7EeEsIwOJ/j40ZxaOOhfIFA4TUSQ= X-Received: by 10.37.72.4 with SMTP id v4mr4781997yba.36.1506345577071; Mon, 25 Sep 2017 06:19:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Mon, 25 Sep 2017 06:19:36 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Mon, 25 Sep 2017 15:19:36 +0200 Message-ID: To: Jerome Martinez Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:19:40 -0000 Here goes the Pull Request: https://github.com/Matroska-Org/matroska-specification/pull/199 I split the commit in two with one adding the reference to the old naming as Jerome suggested. 2017-09-25 14:41 GMT+02:00 Jerome Martinez : > On 25/09/2017 14:02, Steve Lhomme wrote: >> >> As many of you know, in Matroska we use(d) the work timecode where in >> fact it should be timestamps. It goes as far as names in the code we >> use. >> >> This can be confusing for people who can actually tell the difference >> between the two. And since we plan to introduce timecodes, it might be >> a good idea to make this change. >> >> The XML will keep the old names in the cppname so the generated >> code(s) remain unchanged. Also some defines should be added with the >> new names and the old ones marked as deprecated. >> > +1, but we need to put notes about the old name presence in old doc, so > nobody is surprised to find a different name elsewhere and can "map" the old > name to the new name by reading the up to date spec. > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Mon Sep 25 06:43:33 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED3C134316 for ; Mon, 25 Sep 2017 06:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLECEDQ4HlGS for ; Mon, 25 Sep 2017 06:43:29 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625F2134311 for ; Mon, 25 Sep 2017 06:43:29 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id j5so6668440qkd.0 for ; Mon, 25 Sep 2017 06:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=39xuXB2rBn5yGzsHWconEGHXnuZF7R87BsBI1roBb6E=; b=YbSCyaRZ6H6SgEGaSD/txKAnpj1uLifMbEa99ljUEyqBqXgHXhViCyYzaE1+uHNUqV iL704sDC0WKkd23MBEpbNurBrpljVlSQu9v2/r4glYw1qYFmtFVVtJ7wBcCniK2oEG5h YKEdXg3lbhR+CnAzbpxhExxIoraMuVPRpk9VeFyeBpWdc0zH0HhCsu8uoaEUfDuA1fFw H1mMDSQDmw8/OkDOxglvP1cEgh2vtAeLnm0jHI6cf0HWQYITXlFmoRyWyFO7F/oQa+3m f+PxqDkkGEjDORPtVnHvtVPLkomKWvSXhzrq19UEKExQuriKQ2b3OcsV2ncEBxo6MmVH UV4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=39xuXB2rBn5yGzsHWconEGHXnuZF7R87BsBI1roBb6E=; b=OuNk9YIQQB/igJSlqE0PyUR5SNEJRkS8JkbvbjeMwL978ILOhm+L6zu4y9h+l/2qn/ r58CihYUhzmYWmDI18kfv+bn3JI94K5x79uec8PZN3sGfL/0wJTEtRwi8yLtn0L2E4U9 v/9CkVLcWZ5NmODSLMvNSJCGC0TBHC/q7TxcCs9vQHAaePiCnh0i8HSjKN65G89Jx6Sc e9kK/k9WMpiGFHQo6aKrwl+vKi7HqEbURrun6HQj5UF7OltcVT+d0R34nWjnPEHqcyGD oVypYnA0nVWKe3uxA+ilJD3ExoyAgfrHmxluQc6ltcK5q0WBF5a8+IdKXS10hH5oqzRr QSYA== X-Gm-Message-State: AHPjjUh2XUA0mXPI573f72dtBrg6G4igl8gR38MXYeD0aD5u9OQX+yqz cL+Ic7H3F5W5rwr7REeE5aacicogbxTh9f7sPFfQ0RAA X-Google-Smtp-Source: AOwi7QCzRfS/Afx7mk747yXA5gxQhBSm+km4TliiURgoBv0dRPY6Nw1yq00aregec05j0vcZ6EWXBaydvtbtxkh6Vco= X-Received: by 10.55.176.4 with SMTP id z4mr10537406qke.159.1506347008140; Mon, 25 Sep 2017 06:43:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.242 with HTTP; Mon, 25 Sep 2017 06:43:27 -0700 (PDT) From: Ashley Blewer Date: Mon, 25 Sep 2017 09:43:27 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="94eb2c070154542c35055a03bebd" Archived-At: Subject: [Cellar] Matroska: Lofty goals in the menu section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:43:31 -0000 --94eb2c070154542c35055a03bebd Content-Type: text/plain; charset="UTF-8" Hello, I've opened up an Issue to remove some of the Menu Specification section: https://github.com/Matroska-Org/matroska-specification/issues/201 The Menu Specification has not previously been included in the Matroska draft, but we are currently building with it, according to the Makefile, so I assume it will appear in the next iteration? Ashley --94eb2c070154542c35055a03bebd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, I've opened up an Issue to remove some of the M= enu Specification section:=C2=A0https://github.com/Matroska-Org/matroska= -specification/issues/201

The Menu Specification has= not previously been included in the Matroska draft, but we are currently b= uilding with it, according to the Makefile, so I assume it will appear in t= he next iteration?

Ashley
--94eb2c070154542c35055a03bebd-- From nobody Mon Sep 25 06:56:20 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD70913431B for ; Mon, 25 Sep 2017 06:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 xFt8W2iRP4XF for ; Mon, 25 Sep 2017 06:56:17 -0700 (PDT) Received: from server172-2.web-hosting.com (server172-2.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 188D8134318 for ; Mon, 25 Sep 2017 06:56:17 -0700 (PDT) Received: from [146.96.19.240] (port=59312 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dwTrr-002L7H-NV for cellar@ietf.org; Mon, 25 Sep 2017 09:56:16 -0400 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Mon, 25 Sep 2017 09:56:14 -0400 References: To: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: Message-Id: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:56:19 -0000 > On Sep 25, 2017, at 8:41 AM, Jerome Martinez = wrote: >=20 > On 25/09/2017 14:02, Steve Lhomme wrote: >> As many of you know, in Matroska we use(d) the work timecode where in >> fact it should be timestamps. It goes as far as names in the code we >> use. >>=20 >> This can be confusing for people who can actually tell the difference >> between the two. And since we plan to introduce timecodes, it might = be >> a good idea to make this change. >>=20 >> The XML will keep the old names in the cppname so the generated >> code(s) remain unchanged. Also some defines should be added with the >> new names and the old ones marked as deprecated. >>=20 > +1, but we need to put notes about the old name presence in old doc, = so nobody is surprised to find a different name elsewhere and can "map" = the old name to the new name by reading the up to date spec. -1 for me. I think this move can cause some unforeseen consequences since it = involves renaming several elements such as "Timecode", "TimecodeScale", = "ReferenceTimecode" (if still exists). The pairing of these names with = the element ids are used within many Matroska Readers such as mkvinfo, = mkvtoolnix, mkvparse, mediaconch. The names are also widely used in = libavformat. It seems like a large undertaking to coordinate the = elements to be renaming in some many tools. Also those trying to = research these elements will be so confused since they will be = referenced with different names in different places (such as historical = mailing lists, forums, etc). As an alternative proposal, I'd suggest that the current "Timecode" = concept of Matroska have it's name expanded to something like "Matroska = Timecode" which is defined in relation to the "Timecode" and = "TimecodeScale" elements but that those elements are not renamed. Then = other timecode formats can be added as Tracks or Tags but with a = clarifier that they are not "Matroska Timecode". Dave Rice= From nobody Mon Sep 25 07:28:45 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A2013443E for ; Mon, 25 Sep 2017 07:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 1OhasdRDpkIK for ; Mon, 25 Sep 2017 07:28:39 -0700 (PDT) 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 F1089134451 for ; Mon, 25 Sep 2017 07:28:33 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx02.mail.netstorage.at (Postfix) with ESMTPS id 707C1A1704; Mon, 25 Sep 2017 16:28:04 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 5C95181591; Mon, 25 Sep 2017 16:28:03 +0200 (CEST) Received: from [127.0.0.1] (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) ; Mon, 25 Sep 2017 16:28:03 +0200 To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission References: From: Tobias Rapp Organization: NOA GmbH Message-ID: <88103a97-524f-e8bb-af77-7a01e084bf13@noa-archive.com> Date: Mon, 25 Sep 2017 16:28:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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: <20170925142803.11712.81987@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: 707C1A1704.A3000 X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=-0.5, benoetigt 6, autolearn=not spam, BAYES_00 -0.50) X-NetStorage-MailScanner-From: t.rapp@noa-archive.com Archived-At: Subject: Re: [Cellar] EBML element identifier assignment X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 14:28:42 -0000 On 24.09.2017 15:36, Steve Lhomme wrote: > 2017-09-07 15:32 GMT+02:00 Tobias Rapp : >> Hi, >> >> just out of curiosity: How are EBML element identifiers chosen which are >> used within Matroska? Often-used elements seem to get a shorter >> identifier which in turn determines the most significant bits. Are the >> remaining bits assigned randomly? > > Elements with only 1 byte are usually only for elements that we are > sure will be used a lot in the format (outside of the default value). > Elements with 4 bytes are the higher level elements that we want to > seek to and recover quickly without false positive when there's damage > in the file. > > The rest of the bits are no exactly random. When possible they use a > character or ASCII symbol that can be associated with what the element > is about. So when you look in binary it almost makes sense. Didn't notice the ASCII usage yet but will take a look the next time I make a MKV hex dump :-) > Some values that always go together also have incremental values from > one another. > >> In case some vendor would like to add a new element (theoretical >> example, I have no current plans), is there some "reserved range" >> similar to the Private Use Area of Unicode? > > No. It would be good to keep track of them in some ways through. Like > the DivX ones for example. I assume you refer to the list of EBML elements listed at http://labs.divx.com/node/16601 which seem to be part of the current EBML spec draft. Is it useful to reserve some element ID range for "private use" and declare that it won't be used by future MKV versions? Pros/Cons I see: (+) allows for more flexibility at vendors (-) might encourage fragmentation of the standard Thus I'm not completely sure it's worth the work but just want to get the question out of my head and ask the list for opinions. Regards, Tobias From nobody Mon Sep 25 07:47:55 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90B013448A for ; Mon, 25 Sep 2017 07:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 CACAnduy58bC for ; Mon, 25 Sep 2017 07:47:47 -0700 (PDT) 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 34058134496 for ; Mon, 25 Sep 2017 07:47:06 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id 44055A11BA; Mon, 25 Sep 2017 16:46:49 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 6DD698180C; Mon, 25 Sep 2017 16:46:48 +0200 (CEST) Received: from [127.0.0.1] (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) ; Mon, 25 Sep 2017 16:46:48 +0200 From: Tobias Rapp To: Codec Encoding for LossLess Archiving and Realtime transmission Cc: Dave Rice References: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> Organization: NOA GmbH Message-ID: <9421ead6-2ae0-6180-7686-8dc0bcfdc728@noa-archive.com> Date: Mon, 25 Sep 2017 16:46:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20170925144648.14679.63321@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: 44055A11BA.A2BD9 X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=-0.5, benoetigt 6, autolearn=not spam, BAYES_00 -0.50) X-NetStorage-MailScanner-From: t.rapp@noa-archive.com Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 14:47:50 -0000 On 25.09.2017 15:56, Dave Rice wrote: > >> On Sep 25, 2017, at 8:41 AM, Jerome Martinez wrote: >> >> On 25/09/2017 14:02, Steve Lhomme wrote: >>> As many of you know, in Matroska we use(d) the work timecode where in >>> fact it should be timestamps. It goes as far as names in the code we >>> use. >>> >>> This can be confusing for people who can actually tell the difference >>> between the two. And since we plan to introduce timecodes, it might be >>> a good idea to make this change. >>> >>> The XML will keep the old names in the cppname so the generated >>> code(s) remain unchanged. Also some defines should be added with the >>> new names and the old ones marked as deprecated. >>> >> +1, but we need to put notes about the old name presence in old doc, so nobody is surprised to find a different name elsewhere and can "map" the old name to the new name by reading the up to date spec. > > -1 for me. > > I think this move can cause some unforeseen consequences since it involves renaming several elements such as "Timecode", "TimecodeScale", "ReferenceTimecode" (if still exists). The pairing of these names with the element ids are used within many Matroska Readers such as mkvinfo, mkvtoolnix, mkvparse, mediaconch. The names are also widely used in libavformat. It seems like a large undertaking to coordinate the elements to be renaming in some many tools. Also those trying to research these elements will be so confused since they will be referenced with different names in different places (such as historical mailing lists, forums, etc). I don't know about mkv* tools or MediaConch but AFAICS there would be no user-visible changes in libavformat. And while it's true that renaming the element now in Matroska v4 might cause a little confusion I think it would be some lost opportunity not fixing the elements before standardization. So +1 from my side. Regards, Tobias From nobody Mon Sep 25 07:59:00 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E3D13449D for ; Mon, 25 Sep 2017 07:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3tG_ib5W0MN for ; Mon, 25 Sep 2017 07:58:57 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9911133087 for ; Mon, 25 Sep 2017 07:58:56 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id u205so4899766ywa.5 for ; Mon, 25 Sep 2017 07:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VcukrQJHlyY7pVv1a8/q7E13f+ouXvHfHmPGhDo7TKI=; b=Y+3e5qPQnRnHf2WZUW0kND6sipWs4f2ydRWh7XjkZDOJcNiUQpL6QfQq6hi/s3rjew GDhgmx3EUJ5shAINtkcKRGCmCo+S4Lx+h4VHUxWnAJ7Oc9Sp5yy2nMAPwVlqR2avYMVL /bxI6cZ9OMQ56cZrxZqKw4pqVWCUFIVdTEHZ5a1rmGVcEJs7kOV5Zg1E/DWPsyLDy1Fi 4vDTz8HDYYfEK23JokARdM2e6cjloz4WXF0hRV5R/XFYIl7pD/FkXpAAVvHNdA9eNTts A8+9sOMfFT+pfyez6FsCL7LLecZwQEy1pTSWeQefDaYJzKMi9LKTC4u1R7WPcElubc7T Lexg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VcukrQJHlyY7pVv1a8/q7E13f+ouXvHfHmPGhDo7TKI=; b=OF1P7TDyrCB1j9qMx7Wv5HUx4yb3piB+RU6THhvUVMadZu/PCZzHP+Cy4JmAu6sjwb 77b2+XBUl0na8GvcLCd6mCKYr5okDBOZWcbzApioaw6eDxUmcs2FrvzejmVdr6sPFnqI x830YeLxD6K+tsJ60DOXLl6TfMaDDt09Hg5yykzYyP1MuizfdlQ/Y+bGsqE8qnDqxov0 5fp/ZG+eftFil7kmdHWG9K4X8dmzNHy2AuE5yGMPS3VbWq0u6lD89mu/7wFh7vjGSbDt W3iu5sq96dDFUgMs1OuSAT20SQFpsZOH5Aph45oixfmkeV7dmS+THKZdjZsyhSZ3uR1p 38NQ== X-Gm-Message-State: AHPjjUgwT3YDmCZYBa+9gRLfb77/E0Mx+ejNOvml4E7/pLbfmKbD4xXw qtuOp38swhxIZ2SoiFEb9aoBSGt+P1t0MQf/dvck9w== X-Google-Smtp-Source: AOwi7QD7MWUQNdaCf6W02K+aMwWJHPoCDHsz5xgVd52JT4fmYLWoDFJ6zNmBQhhx0xTSrIy7YKasMV84YR0eKrigNqo= X-Received: by 10.129.96.132 with SMTP id u126mr4599887ywb.54.1506351535819; Mon, 25 Sep 2017 07:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Mon, 25 Sep 2017 07:58:55 -0700 (PDT) In-Reply-To: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> References: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> From: Steve Lhomme Date: Mon, 25 Sep 2017 16:58:55 +0200 Message-ID: To: Dave Rice Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 14:58:59 -0000 2017-09-25 15:56 GMT+02:00 Dave Rice : > >> On Sep 25, 2017, at 8:41 AM, Jerome Martinez wrot= e: >> >> On 25/09/2017 14:02, Steve Lhomme wrote: >>> As many of you know, in Matroska we use(d) the work timecode where in >>> fact it should be timestamps. It goes as far as names in the code we >>> use. >>> >>> This can be confusing for people who can actually tell the difference >>> between the two. And since we plan to introduce timecodes, it might be >>> a good idea to make this change. >>> >>> The XML will keep the old names in the cppname so the generated >>> code(s) remain unchanged. Also some defines should be added with the >>> new names and the old ones marked as deprecated. >>> >> +1, but we need to put notes about the old name presence in old doc, so = nobody is surprised to find a different name elsewhere and can "map" the ol= d name to the new name by reading the up to date spec. > > -1 for me. > > I think this move can cause some unforeseen consequences since it involve= s renaming several elements such as "Timecode", "TimecodeScale", "Reference= Timecode" (if still exists). The pairing of these names with the element id= s are used within many Matroska Readers such as mkvinfo, mkvtoolnix, mkvpar= se, mediaconch. The names are also widely used in libavformat. If it's strings that are internal to the code, it doesn't matter what they are called. I can even do the patches for some projects. For strings that are presented to the user that might be a problem. IIRC there's a timecode file format for example in mkvmerge that use the old name(s). The command line parameters of mkvmerge may differ as well. But in that case it does not really matter if they match exactly what's in the specs. But I understand changing the output of a tool like mkvinfo might be problematic. IIRC it's based on cppname though or otherwise it has it's on ID<>string correspondance and no need to change for now. > It seems like a large undertaking to coordinate the elements to be renami= ng in some many tools. Also those trying to research these elements will be= so confused since they will be referenced with different names in differen= t places (such as historical mailing lists, forums, etc). These names won't be lost. They will actually be in the specs: https://github.com/Matroska-Org/matroska-specification/pull/199/commits/473= 9ec73165785959af256ba65b1f14449655770 > As an alternative proposal, I'd suggest that the current "Timecode" conce= pt of Matroska have it's name expanded to something like "Matroska Timecode= " which is defined in relation to the "Timecode" and "TimecodeScale" elemen= ts but that those elements are not renamed. Then other timecode formats can= be added as Tracks or Tags but with a clarifier that they are not "Matrosk= a Timecode". But then you're adding some new definition that may not match with existing programs either. > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Mon Sep 25 08:03:26 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7651344A2 for ; Mon, 25 Sep 2017 08:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83JT83uGJM5c for ; Mon, 25 Sep 2017 08:03:23 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B9B13449D for ; Mon, 25 Sep 2017 08:03:23 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l4so4908931ywa.6 for ; Mon, 25 Sep 2017 08:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eyM6/L9AfTU1IaD5I8Yk2rjRnxhsyWm1QoDbnsQSpRM=; b=xDfyrSuzwTnZIO4OY7fB2M3O/EWFxY4hfFJH7OJPN09PG3IAKo4SijevQuIxcorpUa mkk+v/J9cTgCCzLTr6vSU8GQU/2sl3S7bZsNujtSXc6LpdAJb0SUfS8SFH7GTKtU5quo DUJaN+8hBrNvNnZQD8gZBX0psucovAE1lJj0VLX11nLSqAgMNRTK/3822hHZAJ+XI+07 xGla7JXOp8F5g8xvASnhCUplIgsNvKL0a06R4jqjIqGgo6KlA0MGoBZEkbVA3K6olbxP bhsg74NhCfVPYfoO6FdW1U25AkSCMuplOUsKLw2JEPSdqGMXAmIx31Zl/qMDpSwy/R+L RIJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eyM6/L9AfTU1IaD5I8Yk2rjRnxhsyWm1QoDbnsQSpRM=; b=FI7C6PV3Px8MmV63I1ZuwSCJ7YFfojXCeZm4GbHpcCCDyNW4bizW4zyvowG5m7UnvR Cv/uN0TXmJQ28pVV1MA1scdmJY/NNBqtw+LiaS539y2oWOzYRdMW8MzqxM0bKGrL1HWi XYGgHdL2vkdNJXCQmNsFXgRJ9WxoUsHUoN92nrflTT79+INQdqTM859TbC9PAhZgAVbV 0jz/GRvToOfrsZ+vsypUT75lhaPhOIzHaHPfBubqKYJff77Q8h3zREzJnIRyZ3dqfTzW cT/v5nfoqT5vSQVGKeQfAwd3aT12T+Sn+HHfI/tk2kAyCrdX6jtW2yCdLEwLz/ue0Kyx Uyew== X-Gm-Message-State: AHPjjUgl2oJmeHm0A0YF380CcNd5TKdkAc5HmPmkp6+YoP2MTYFTt2dV Fz9wok8Dza8ZU8owetcuH76X1Y33YCxYAtGWc2HpLQ== X-Google-Smtp-Source: AOwi7QDy4tcr2hN+QN/QPiVRXfm8Gen4TUtaoy0+MEBU4bYQfLNF0EhyPEGkdXWktfjje9BtEXKLMeXk9yeo1TVUCag= X-Received: by 10.37.189.18 with SMTP id f18mr4863449ybk.447.1506351802533; Mon, 25 Sep 2017 08:03:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Mon, 25 Sep 2017 08:03:21 -0700 (PDT) In-Reply-To: <9421ead6-2ae0-6180-7686-8dc0bcfdc728@noa-archive.com> References: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> <9421ead6-2ae0-6180-7686-8dc0bcfdc728@noa-archive.com> From: Steve Lhomme Date: Mon, 25 Sep 2017 17:03:21 +0200 Message-ID: To: Tobias Rapp Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Dave Rice Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 15:03:25 -0000 2017-09-25 16:46 GMT+02:00 Tobias Rapp : > On 25.09.2017 15:56, Dave Rice wrote: >> >> >>> On Sep 25, 2017, at 8:41 AM, Jerome Martinez >>> wrote: >>> >>> On 25/09/2017 14:02, Steve Lhomme wrote: >>>> >>>> As many of you know, in Matroska we use(d) the work timecode where in >>>> fact it should be timestamps. It goes as far as names in the code we >>>> use. >>>> >>>> This can be confusing for people who can actually tell the difference >>>> between the two. And since we plan to introduce timecodes, it might be >>>> a good idea to make this change. >>>> >>>> The XML will keep the old names in the cppname so the generated >>>> code(s) remain unchanged. Also some defines should be added with the >>>> new names and the old ones marked as deprecated. >>>> >>> +1, but we need to put notes about the old name presence in old doc, so >>> nobody is surprised to find a different name elsewhere and can "map" the old >>> name to the new name by reading the up to date spec. >> >> >> -1 for me. >> >> I think this move can cause some unforeseen consequences since it involves >> renaming several elements such as "Timecode", "TimecodeScale", >> "ReferenceTimecode" (if still exists). The pairing of these names with the >> element ids are used within many Matroska Readers such as mkvinfo, >> mkvtoolnix, mkvparse, mediaconch. The names are also widely used in >> libavformat. It seems like a large undertaking to coordinate the elements to >> be renaming in some many tools. Also those trying to research these elements >> will be so confused since they will be referenced with different names in >> different places (such as historical mailing lists, forums, etc). > > > I don't know about mkv* tools or MediaConch but AFAICS there would be no > user-visible changes in libavformat. And while it's true that renaming the > element now in Matroska v4 might cause a little confusion I think it would > be some lost opportunity not fixing the elements before standardization. Yes, that's my main point here. We have the last chance to fix this legacy for good. > So +1 from my side. > > Regards, > Tobias > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Mon Sep 25 08:07:13 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4570C13448E for ; Mon, 25 Sep 2017 08:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcDW_EeacFSp for ; Mon, 25 Sep 2017 08:07:11 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB556133087 for ; Mon, 25 Sep 2017 08:07:10 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id u11so4922358ywh.7 for ; Mon, 25 Sep 2017 08:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CC2tE3Hp+QUA9P8j3IoyH8rQJexHpqcJEBqSajo6Pds=; b=muj3ZvxvYSmgl0i0oZVaOtStR/RjUX+w6IY9qnUuUlJxn1h4lbw5Ug1Y9lUkQlN6mQ cKAPKhsd94rh3MkBMuOhnjB3+mtK5AsF4B6dRQQ801HQUoakgMcb7SpVdReAMGdM/lae 6zk2I1p1W7TVZJAb9g0WlDATZ/yVLGCxbEZ8GHk51oeX+GS1m4DhQ1SQoX14zjKy92ZC KbDYf14YgLuXitA+J4n0oEHKPkwyH3EkJ4xK43E+fGb9LVr3YHmQyIFNkDKNnQcAMjbb d8oyCPz3GU0o0L0EMwfwoDA+4l5IDBtRZ66B5RooJdprnVGQXjybRk+cGzCYnhpPqH+F k0Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CC2tE3Hp+QUA9P8j3IoyH8rQJexHpqcJEBqSajo6Pds=; b=BnOZAew5sqAqajCppuJ/5tLksfgmLbeuA5k2g7i9qM3CnUX2skbwDuEkVunK3vf57s gEyCWSOMvwSzwAUCmUmdln2hQ4gYCJmbLZx5M9tnNPRUUhv0vANjRZ39j1r5PU97YXN4 Ot1rBMVdj6ioRySjJBwy3N9aAQOyHfedRWw0g2oRA+OYhSI5oq6tpjFWzBL5SkhsIl1p CY/lX1hwvQOqJ0kyvrgDjufG//KrkP8uPAxkHuVSk7Ya/U4MWIjfY0LHZo55DbdMr86s RrTViy40DuE4q8Xr3LJS2nqUQJWWZrXFbNWFdfQs5N5FxDW3q4qaizT1eovlHOC3eOXG UuRg== X-Gm-Message-State: AHPjjUit6rKjUtVmRDHm6ZkuCnCoRAeifC1OZ7zXC5YgRzYBBiK+nE31 OYv82du0zB0mDh45+yPrKXYRtN/p59l+1G2QHASPag== X-Google-Smtp-Source: AOwi7QDyh4igR8LkfjTqNENOW27/6OkqckB/9mwHcv80Em9Bqf3dcQLlxT71gyHnFcAa8h054Xekn8l5qJGAXTuh4Ik= X-Received: by 10.37.171.97 with SMTP id u88mr4699709ybi.324.1506352029938; Mon, 25 Sep 2017 08:07:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Mon, 25 Sep 2017 08:07:09 -0700 (PDT) In-Reply-To: <88103a97-524f-e8bb-af77-7a01e084bf13@noa-archive.com> References: <88103a97-524f-e8bb-af77-7a01e084bf13@noa-archive.com> From: Steve Lhomme Date: Mon, 25 Sep 2017 17:07:09 +0200 Message-ID: To: Tobias Rapp Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] EBML element identifier assignment X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 15:07:12 -0000 2017-09-25 16:28 GMT+02:00 Tobias Rapp : > On 24.09.2017 15:36, Steve Lhomme wrote: >> >> 2017-09-07 15:32 GMT+02:00 Tobias Rapp : >>> >>> Hi, >>> >>> just out of curiosity: How are EBML element identifiers chosen which are >>> used within Matroska? Often-used elements seem to get a shorter >>> identifier which in turn determines the most significant bits. Are the >>> remaining bits assigned randomly? >> >> >> Elements with only 1 byte are usually only for elements that we are >> sure will be used a lot in the format (outside of the default value). >> Elements with 4 bytes are the higher level elements that we want to >> seek to and recover quickly without false positive when there's damage >> in the file. >> >> The rest of the bits are no exactly random. When possible they use a >> character or ASCII symbol that can be associated with what the element >> is about. So when you look in binary it almost makes sense. > > > Didn't notice the ASCII usage yet but will take a look the next time I make > a MKV hex dump :-) > >> Some values that always go together also have incremental values from >> one another. >> >>> In case some vendor would like to add a new element (theoretical >>> example, I have no current plans), is there some "reserved range" >>> similar to the Private Use Area of Unicode? >> >> >> No. It would be good to keep track of them in some ways through. Like >> the DivX ones for example. > > > I assume you refer to the list of EBML elements listed at > http://labs.divx.com/node/16601 which seem to be part of the current EBML > spec draft. > > Is it useful to reserve some element ID range for "private use" and declare > that it won't be used by future MKV versions? > > Pros/Cons I see: > (+) allows for more flexibility at vendors > (-) might encourage fragmentation of the standard It might be a good idea to reserve some level 1, 2 and 4 elements for future Matroska usage. This way we know they are not used by anyone. It might be a little late for that though as we have no idea what's out there in the wild. > Thus I'm not completely sure it's worth the work but just want to get the > question out of my head and ask the list for opinions. > > Regards, > Tobias > -- Steve Lhomme Matroska association Chairman From nobody Mon Sep 25 08:24:32 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140931344A8 for ; Mon, 25 Sep 2017 08:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 BsZG34jrj4wn for ; Mon, 25 Sep 2017 08:24:28 -0700 (PDT) Received: from mx01.mail.netstorage.at (mx01.mail.netstorage.at [89.207.144.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5DB31344A5 for ; Mon, 25 Sep 2017 08:24:27 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id AAA0CA074C; Mon, 25 Sep 2017 17:24:14 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 529DC812F8; Mon, 25 Sep 2017 17:24:14 +0200 (CEST) Received: from [127.0.0.1] (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) ; Mon, 25 Sep 2017 17:24:14 +0200 To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission References: <2bddc712-3d56-0efd-058f-ff1533eb6f41@noa-archive.com> <94948eab-21ae-79be-4b6e-846e5a98f985@noa-archive.com> From: Tobias Rapp Organization: NOA GmbH Message-ID: <43176f6d-6d24-c3cb-6f43-9cff7aa5a826@noa-archive.com> Date: Mon, 25 Sep 2017 17:24:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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: <20170925152414.21946.29520@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: AAA0CA074C.A6D90 X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=-0.5, benoetigt 6, autolearn=not spam, BAYES_00 -0.50) X-NetStorage-MailScanner-From: t.rapp@noa-archive.com Archived-At: Subject: Re: [Cellar] Status of the ChannelPositions element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 15:24:31 -0000 On 24.09.2017 15:49, Steve Lhomme wrote: > 2017-09-22 14:59 GMT+02:00 Tobias Rapp : >> Hi, >> >> there are some possible directions for further development of this topic and >> I'd like to get some feedback on which one is preferred: >> >> Option 1: Don't add anything regarding audio channel positions to the >> Matroska spec. Information is available to players for audio codecs that >> include channel position data as part of the encoded bitstream (Opus, AAC), >> for audio codecs that miss this information the player has to make >> assumptions (PCM). >> >> Option 2: Add some generic audio channel position element(s) to the Matroska >> spec. Information is available to players for all audio codecs, in case the >> encoded bitstream also contains channel position data the Matroska spec >> should define which one takes precedence. >> >> Option 3: Add audio channel position data to the codec mapping section of >> the Matroska spec. Channel position data is stored within CodecPrivate >> element only for audio codecs that do not provide the information as part of >> the bitstream (PCM). > > There might be option 4: always have a value set in the container and > optionally in the codec if it wants to. One of the possible value(s) > in Matroska could be a special value "see codec" for things that are > too complex for Matroska. Looks like a variant of option (2) data-location wise (i.e. stored in generic elements, not codec private data). Likely the "see codec" value would be used as a default for backwards compatibility. > In general, for playback, it's good to know before you start decoding > how you have to configure the audio output and that involves how many > channels and how they interact with each other. And the best way for > that is to look at what the container says. Before parsing the actual > data and opening the decoder. With PCM we need to have as many > mappings as possible anyway. It can't be left to interpretation. > > I like the 2 elements approach. For stereo, multichannel and > object-based things can be quite different. It's at least good to know > if a track is either 3 of these types (there might be more) before > selecting it. And the way we store the actual mapping for each can be > different. But we need a way to specify how each format is going to be > stored. We may even have 3 elements: multichannel, ac-3 style, binary > blob with a custom mapping. Not sure how channel mapping is done for AC-3. Do you refer to the "Audio Coding Mode"? So it seems we agree that using a "ChannelPositionType" / "ChannelPositionData" element pair would be the most flexible option. What would be the purpose of the third element you mentioned? Regards, Tobias From nobody Mon Sep 25 08:27:23 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946F51344A8 for ; Mon, 25 Sep 2017 08:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvbvALn3AWGz for ; Mon, 25 Sep 2017 08:27:21 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E708D13448E for ; Mon, 25 Sep 2017 08:27:20 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id v72so4967458ywa.3 for ; Mon, 25 Sep 2017 08:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DsaXCaKwLfwMy6THu/h26y8/cLXDrNlnSb3ZsEJ8tFE=; b=hnAlKraXbWyDWbf8OtSqXiCSdP1y5RyVOZz62ZOm4Q5gj5asdEY8MFgEwFK0kae3Ly /96B2EK2+mM9F1YSrf8UUtBBvsyiIKo/m6mGFwulse/s8kLKQoY6HtjX+w5TVv5Uaslw RvVQVMVMbwV/pnpXOfFJwDc1waxbfbWoOyHU42+DTlBWQRVOaxranBuaw7wC4Ogfyllv 1m5huetQfUcxZ6S6l/KIMLO5nnNHtiShX1bpaAZkVQSLR7eORdv/D1MyJMvYnt/6zHpD yVppOldMZ16nVJdOBTkXbzUSK/c5jzukBqke5ro70FoaErOyDqa0E1ouYGnU8S0gwIHB zmhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DsaXCaKwLfwMy6THu/h26y8/cLXDrNlnSb3ZsEJ8tFE=; b=Be43Rz/Lhn0KgXoh+8XlIA6u44bWchAsRl0T38PXTr5m/H4O4jCuld7IDa5sVaBUGd +O3DQj51t0bG55AtWZzcX8kVqChtY/0IVrCtG8WWz0CyK1YOlwA06A+XeYGJkRzS5voq zWG+qjbQsyDbwt4vt/78L89bd9/pQ7KsUuRiukSCORHnO58tzwuvKK6pnvjwr2NBMBSA P4lOtfYFzLBFNtMHo5Du0sEUUwr4SEvSVifwoHdk9u1zd4hlU64tL2kvY0yOYJYJm1CM QmuMt8FbxjS1KhYpfDsbpJYIzgoht0lEZJOk34RuDFwXVNTjwEjY6Rz7UevRx2AqkQBG ae/w== X-Gm-Message-State: AHPjjUjcGwzpjJ2PGshOjvvWVWS9cB1eoUFTjmu6ZpvvCaPMZRcvX8Mh lnqRyW1He29TVPBFyyKDvSJKzR9nZeMPMBVjWaDH1Q== X-Google-Smtp-Source: AOwi7QCfAejdJ7dPgqmbi/kSyRq5TRNPdOXzRvXOAkvbD173RVu4nJDjiWw91cNNGbaoTu66a9SzDjngwMR7LnhkTI4= X-Received: by 10.37.15.4 with SMTP id 4mr4738907ybp.49.1506353240075; Mon, 25 Sep 2017 08:27:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Mon, 25 Sep 2017 08:27:19 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Mon, 25 Sep 2017 17:27:19 +0200 Message-ID: To: Ashley Blewer Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Matroska: Lofty goals in the menu section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 15:27:22 -0000 This text surely doesn't belong in the specs. The menu specificiation should probably be its own document, as it was before. We just need to make sure the corresponding elements are well described in the general Matroska specifications. Because we won't be able to reference documents that will be ready at a (much) later date. 2017-09-25 15:43 GMT+02:00 Ashley Blewer : > Hello, I've opened up an Issue to remove some of the Menu Specification > section: https://github.com/Matroska-Org/matroska-specification/issues/201 > > The Menu Specification has not previously been included in the Matroska > draft, but we are currently building with it, according to the Makefile, so > I assume it will appear in the next iteration? > > Ashley > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Mon Sep 25 08:33:14 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B724D132025 for ; Mon, 25 Sep 2017 08:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpO0l4rzZKby for ; Mon, 25 Sep 2017 08:33:12 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16829132E24 for ; Mon, 25 Sep 2017 08:33:11 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id v72so4981036ywa.3 for ; Mon, 25 Sep 2017 08:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PCBFCB+JhqTx0OjnxDL0eDkHwvQIlGrfBh+pAJBA1Dc=; b=Hv0zuo5mbPw8GPL6dsn5vJ9iZpT+IIOV3JOj3i74MPvc2v/NI1qBqzKdC+bzytCT3H j774QO3KTl9Kun6N/Y4YvCSve3nXrGz7VwXlPqA1edeAn77GVOXI+L5SufN7j94f0eT6 8M+RH7I42/bNaiCERw13kvMqv98quwYl5haiyYaqtTXVFsTky66fy9Ro0iX14S7d6Mpr h8lb/PCWMZPjWixo9HTJKCBMsW6vrF3HsclGF8NFxJ0Lpx6VtQpw7umfTbd05XlGyCTs AdFF40R7sXZmqts+oHODH0qno5f9Hztx+YFV3h79X5AWuV/nUNWbrN/Mji9E6ppV+iZl 5KuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PCBFCB+JhqTx0OjnxDL0eDkHwvQIlGrfBh+pAJBA1Dc=; b=jvGQTBZjcqGDqWwYvEeGeSCzg1pPz01Z2DgiRDBbJa1d5S7jKZvBZbBsIwJ4fzpI+m pMuybYpI6Wm/oZbrkUHx5I0I21dPLjE9metQ08KHQJ/F0lKEM6LBBu57k8g0vJ6EAzVi A96PbF7QgabRjwHVM1kuZcfuQbxFjf70Yzg/A99M5l27La7GexlnKL8NCaRj4JqX9EN4 NL4v9pTD2mxS7vVjPO+wIyOuDPXjz5hveDk0M5OlzL8cGxQ+5EONOTFILOwDgB24KqP0 2DjUd8qUyKDoCZ7uTUv+ZnV4SHxvkNfFwrUpiPK1uBu055TehS4TfP/Z3fS/eU8V//Z3 Uh5A== X-Gm-Message-State: AHPjjUh7/Pshvv67d2yQCCgDtv4OAmdjEUcJdLNF6+zeyN64MFuB+Ha+ pSob3akmWtrB4uRop2XNzdqChhwfDgvp8mkZvFK7UQ== X-Google-Smtp-Source: AOwi7QASogmMsWCfBFLxqLSWD97EqaDnGTsw1GWMn3hHq1VwEvqAVss9OrZjI9oyGW+J0hDEKo3G8XlEB+xTEKwgEyY= X-Received: by 10.129.78.207 with SMTP id c198mr4763078ywb.121.1506353587003; Mon, 25 Sep 2017 08:33:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Mon, 25 Sep 2017 08:33:06 -0700 (PDT) In-Reply-To: <43176f6d-6d24-c3cb-6f43-9cff7aa5a826@noa-archive.com> References: <2bddc712-3d56-0efd-058f-ff1533eb6f41@noa-archive.com> <94948eab-21ae-79be-4b6e-846e5a98f985@noa-archive.com> <43176f6d-6d24-c3cb-6f43-9cff7aa5a826@noa-archive.com> From: Steve Lhomme Date: Mon, 25 Sep 2017 17:33:06 +0200 Message-ID: To: Tobias Rapp Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Status of the ChannelPositions element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 15:33:14 -0000 2017-09-25 17:24 GMT+02:00 Tobias Rapp : > On 24.09.2017 15:49, Steve Lhomme wrote: >> >> 2017-09-22 14:59 GMT+02:00 Tobias Rapp : >>> >>> Hi, >>> >>> there are some possible directions for further development of this topic >>> and >>> I'd like to get some feedback on which one is preferred: >>> >>> Option 1: Don't add anything regarding audio channel positions to the >>> Matroska spec. Information is available to players for audio codecs that >>> include channel position data as part of the encoded bitstream (Opus, >>> AAC), >>> for audio codecs that miss this information the player has to make >>> assumptions (PCM). >>> >>> Option 2: Add some generic audio channel position element(s) to the >>> Matroska >>> spec. Information is available to players for all audio codecs, in case >>> the >>> encoded bitstream also contains channel position data the Matroska spec >>> should define which one takes precedence. >>> >>> Option 3: Add audio channel position data to the codec mapping section of >>> the Matroska spec. Channel position data is stored within CodecPrivate >>> element only for audio codecs that do not provide the information as part >>> of >>> the bitstream (PCM). >> >> >> There might be option 4: always have a value set in the container and >> optionally in the codec if it wants to. One of the possible value(s) >> in Matroska could be a special value "see codec" for things that are >> too complex for Matroska. > > > Looks like a variant of option (2) data-location wise (i.e. stored in > generic elements, not codec private data). Likely the "see codec" value > would be used as a default for backwards compatibility. Yes >> In general, for playback, it's good to know before you start decoding >> how you have to configure the audio output and that involves how many >> channels and how they interact with each other. And the best way for >> that is to look at what the container says. Before parsing the actual >> data and opening the decoder. With PCM we need to have as many >> mappings as possible anyway. It can't be left to interpretation. >> >> I like the 2 elements approach. For stereo, multichannel and >> object-based things can be quite different. It's at least good to know >> if a track is either 3 of these types (there might be more) before >> selecting it. And the way we store the actual mapping for each can be >> different. But we need a way to specify how each format is going to be >> stored. We may even have 3 elements: multichannel, ac-3 style, binary >> blob with a custom mapping. > > > Not sure how channel mapping is done for AC-3. Do you refer to the "Audio > Coding Mode"? > > So it seems we agree that using a "ChannelPositionType" / > "ChannelPositionData" element pair would be the most flexible option. What > would be the purpose of the third element you mentioned? For arbitrary values. For example you have just top and bottom channels or north/south/east/west. I don't know if there are existing ways to define all kinds of channel formats, or even some formats that are kind of generic and we can reuse. > Regards, > Tobias > -- Steve Lhomme Matroska association Chairman From nobody Mon Sep 25 08:50:17 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC9D132E24 for ; Mon, 25 Sep 2017 08:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1Q-yPDtaWgy for ; Mon, 25 Sep 2017 08:50:13 -0700 (PDT) Received: from 7.mo177.mail-out.ovh.net (7.mo177.mail-out.ovh.net [46.105.61.149]) (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 9CF9E1344AE for ; Mon, 25 Sep 2017 08:50:13 -0700 (PDT) Received: from player688.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id A7B2F7CB1B for ; Mon, 25 Sep 2017 17:50:11 +0200 (CEST) Received: from [192.168.2.120] (p5DDB6596.dip0.t-ipconnect.de [93.219.101.150]) (Authenticated sender: jerome@mediaarea.net) by player688.ha.ovh.net (Postfix) with ESMTPSA id 5EFB420077 for ; Mon, 25 Sep 2017 17:50:11 +0200 (CEST) To: cellar@ietf.org References: <88103a97-524f-e8bb-af77-7a01e084bf13@noa-archive.com> From: Jerome Martinez Message-ID: Date: Mon, 25 Sep 2017 17:50:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Ovh-Tracer-Id: 2716515003764248721 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelledrjedtgdeljecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] EBML element identifier assignment X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 15:50:16 -0000 On 25/09/2017 17:07, Steve Lhomme wrote: > It might be a good idea to reserve some level 1, 2 and 4 elements for > future Matroska usage. This way we know they are not used by anyone. > It might be a little late for that though as we have no idea what's > out there in the wild. Actually classic idea (from other specs) is to reserve some elements for future **not** Matroska usage a.k.a. explicitly flagged "private use". All other elements would be forbidden if not in specs. I suggest not to reserve any level 1 or 2 elements, as they are too rare for affording to lose them for private use. Some ideas from other readings: - we could assign 1 byte of a 4-byte element for private use i.e. [XX][00][00][00] to [XX][FF][FF][FF] are defined as for private use depending of the registry, and we decide about [XX] value in specs. - we could assign a "registry" element (where? In EBML part after DocTypeReadVersion? Issue is if one wants to use private elements from 2 registries), an entity willing to use private elements would have to write this element ant put its name in it (advising reverse DNS naming convention?), or we could say that the 2nd and 3rd bytes (2^16 possibilities :) ) need to be registered to Matroska with name of the entity planning to use the private elements, before usage, or advising that they should be chosen trying to be unique (depending of their name?) Main issue I see is that WebM is expanding elements when they want and we may have to try to find an agreement that such range is reserved if we want to be able to "backport" their addition to Matroska specs so WebM stays a subset of Matroska, but this is actually true for all other new elements too. From nobody Mon Sep 25 09:05:30 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630AF1344AE for ; Mon, 25 Sep 2017 09:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1uOfLNFPqhW for ; Mon, 25 Sep 2017 09:05:12 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BB71344B8 for ; Mon, 25 Sep 2017 09:05:12 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id o143so5059087ywd.12 for ; Mon, 25 Sep 2017 09:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zExRBUipi6DJI4SA57HXRsl+DcHERqgSY7dbPk3g7Eo=; b=x2SaTvbI1nlFd0EcHPZnJ6aA25xL/Ju6JB5NBPIUkZ+wVu8cP7uEb+uh9eQOGScAad M4GOoxKA0aZgN2Vl5Y88YmfuX/ZdBDMGfbqU5rzcbYTzE1fZDS/jgybxUKw38JX3sSlP dvv93CbZz3dJPCH4EnsTLKknHvrlFgYUkbAbjTUzi+syWPFWGRXP5Dl6xmoxERHrmp1/ l45qzx/XTUi4J0EaZ3Cfaolb/8WqOkJJ/+X8D0pxQ1AJzYQQ1v0HpYFI74HzvGQjBAjs iZgo89BxxDyyA+AaZtyw7sJAwk/cXG5d1um0KUsrEAVXKkI4lCWAFxCn3fVB6xYPiHOn gICQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zExRBUipi6DJI4SA57HXRsl+DcHERqgSY7dbPk3g7Eo=; b=UhX6z9Z7POV4L6uzFdP+5ITcxycahh8FGmAf6g88QbRKGXefY7Sxg6y+NBlmk+kCEF LohEj9DhQCVfjPk86kGQg6GwukQ0xQ52+Wu7FQZG40vkka/3NnKypMELDomcFwbCyVbM zYy+q5AUZ0fTlZdReA5zSn1J5DvajXe/XtsfcI0BP2KQ7aUwy1xb2uASp4nuLjy1j17V dtAtBHAot+yVxG28SRJM6pFNSkU40hd/WxfW6w9eCVpdibfmuKVXrAMZjcQKO08ThP1D 5zHT5j6rfD2nFXVcEjxnsyS1ethmO2V7eC43ireD2zEEfdNCoDvWgLByqbubw7kGYARu sWGw== X-Gm-Message-State: AHPjjUjZKrpCnXjAAysNrxMhYpndXWXZvVa/T3cQh3RSPwPOBQNriijr UMlzeAKYn1VJYjhE+NtGebd/Bm7gx5NBbZsTzdKmx1Dt X-Google-Smtp-Source: AOwi7QCFPZTYvQTPNG108q8PJ86vRjAxuBu1Q5fjQM7rbNdOSDb1cUWlz6jn3RgGXLOnRJgBTU4WUg7s+VfOZBL2UnU= X-Received: by 10.37.72.4 with SMTP id v4mr5095775yba.36.1506355506737; Mon, 25 Sep 2017 09:05:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Mon, 25 Sep 2017 09:05:06 -0700 (PDT) In-Reply-To: References: <88103a97-524f-e8bb-af77-7a01e084bf13@noa-archive.com> From: Steve Lhomme Date: Mon, 25 Sep 2017 18:05:06 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] EBML element identifier assignment X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:05:23 -0000 2017-09-25 17:50 GMT+02:00 Jerome Martinez : > On 25/09/2017 17:07, Steve Lhomme wrote: >> >> It might be a good idea to reserve some level 1, 2 and 4 elements for >> future Matroska usage. This way we know they are not used by anyone. >> It might be a little late for that though as we have no idea what's >> out there in the wild. There's also the problem of 2 entities using the same reserved/free ID for something different without knowing each other. On the `Matroska Reader` side we should allow any ID we don't know about. But maybe on the writing side the specs should be stricter on what is allowed and what is not. > > Actually classic idea (from other specs) is to reserve some elements for > future **not** Matroska usage a.k.a. explicitly flagged "private use". > All other elements would be forbidden if not in specs. > I suggest not to reserve any level 1 or 2 elements, as they are too rare for > affording to lose them for private use. Level 1 are rare indeed. That doesn't mean a custom format should not be allowed to use any. Even if there's only 1 or 2 allowed. > Some ideas from other readings: > - we could assign 1 byte of a 4-byte element for private use i.e. > [XX][00][00][00] to [XX][FF][FF][FF] are defined as for private use Yes, maybe [XX]['P'][YY] and [XX]['P'][YY][YY] could be reserved ranges. We have to find a range with a fancy code that doesn't collide with any ID we have. > depending of the registry, and we decide about [XX] value in specs. > - we could assign a "registry" element (where? In EBML part after > DocTypeReadVersion? Issue is if one wants to use private elements from 2 > registries), an entity willing to use private elements would have to write > this element ant put its name in it (advising reverse DNS naming > convention?), or we could say that the 2nd and 3rd bytes (2^16 possibilities > :) ) need to be registered to Matroska with name of the entity planning to > use the private elements, before usage, or advising that they should be > chosen trying to be unique (depending of their name?) The registry in the header is probably too much, or it should cover the whole range of IDs (EBML v2 ?) or may a diff compared to a specified version of the DocType. But IMO it's better to have a public registry and tell people to register their IDs. Similar to what exists for MP4 atoms. But I think that would be something that goes through IETF/IANA. > Main issue I see is that WebM is expanding elements when they want and we > may have to try to find an agreement that such range is reserved if we want > to be able to "backport" their addition to Matroska specs so WebM stays a > subset of Matroska, but this is actually true for all other new elements > too. I'm sure if we setup some rules, they will follow them. > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Mon Sep 25 09:31:25 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D7E1344B4 for ; Mon, 25 Sep 2017 09:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa2ppPBjc2bA for ; Mon, 25 Sep 2017 09:31:22 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6141D1344F0 for ; Mon, 25 Sep 2017 09:31:18 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id q124so21477979wmb.0 for ; Mon, 25 Sep 2017 09:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ESSRoIilGx0TIW29ztfJGqNu57RgUOl6kyNo7rbPKcY=; b=ZaD8L7iEZSyU0URqWFH/hUHVUG3YDMZ+3hcSIhtjjuhMrOb3U6ELsJEUzxdvk5myfC 7mQUKrRXX7jDopAksRcnsyOWH+Q67cyw7RbSI9mp/ZJ4IEixPZ02NoEkL8eG8u9NQr3O y1a781pt4xyyePfcMfniLhxQ89etH/3fzYSn4scBeLBEana9FniVEhpLX7sKCfW+ZWNP KN68II9fJslG+oDJIczQIOQ2zz+9dvYRdpdes1gVdI41VbwRbND2zV3YTNgQ3egq9lPE w/e0pDe+EtOXTuDz6ogXhj6yM8A5VIpCLJqY4y/NetJTwaqyadR6NH0Lps92SZ16H8na 8MLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ESSRoIilGx0TIW29ztfJGqNu57RgUOl6kyNo7rbPKcY=; b=h4kobej7pvrhcJ5rRVO/rRbMiHLjZS0sj+XPKJEj+ZbDfKdbLolu1B3sum6vRUAFKU VKgNXVBSeoK/o0KlrPQ+dVSECoXm+q6h4EG7GnGNRfMFFksmHoauQLZPSGOzKY9OEc6Q vcndEf+6lnvM1wSbTYtS94O68oux5TR3leLixDlzt4qyKdmpAYrBgBtIFVYuWT/FIY9W CiGbj9F939fEp+VT8zbT/gPACjKRzHzYeqb60Ar550VRCcxBrvzZxk663RqkSbGZrM1/ ky/jsJs3p7TkA1zBjFfsf18P+8HjoikFursnT/w2Vnt/L5P/GWDoWt+Rk5+33oLupmFa oPGw== X-Gm-Message-State: AHPjjUhu1ki12jtnr0n4Vewxk2x9euo1mS2tzILy8QmFwrlH/etn4NfE EC3l8vFVrheG+TkUcJzPGFKuMnQU X-Google-Smtp-Source: AOwi7QCW/LTuOANWwpi4xj0SfI/pQGmsrx9uxigXs1+difoACBhUHbcZkQNnkKFZoVLWJ9CBQnjbsg== X-Received: by 10.80.140.251 with SMTP id r56mr14206104edr.299.1506357076749; Mon, 25 Sep 2017 09:31:16 -0700 (PDT) Received: from [192.168.1.159] ([82.129.104.219]) by smtp.googlemail.com with ESMTPSA id m10sm3659163eda.30.2017.09.25.09.31.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 09:31:16 -0700 (PDT) To: cellar@ietf.org References: From: Derek Buitenhuis Message-ID: <6d910d4e-8cbb-afa2-5b4f-40cb7d01ae3f@gmail.com> Date: Mon, 25 Sep 2017 17:31:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Matroska: Lofty goals in the menu section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:31:24 -0000 On 9/25/2017 4:27 PM, Steve Lhomme wrote: > The menu specificiation should probably be its own document, as it was > before. We just need to make sure the corresponding elements are well > described in the general Matroska specifications. Because we won't be > able to reference documents that will be ready at a (much) later date. This may be off topic, but... has there ever even been a Matroska file with menus produced? If not, is it even worth keeping alive? - Derel From nobody Mon Sep 25 10:46:25 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99CF134535 for ; Mon, 25 Sep 2017 10:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 QJEPWkmYbJ2E for ; Mon, 25 Sep 2017 10:46:22 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3441330B2 for ; Mon, 25 Sep 2017 10:46:22 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8PHkKet017949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 25 Sep 2017 19:46:20 +0200 Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8PHkJSM059883 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 25 Sep 2017 19:46:20 +0200 Date: Mon, 25 Sep 2017 19:46:20 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Matroska: Lofty goals in the menu section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 17:46:25 -0000 Derek Buitenhuis wrote: >This may be off topic, but... has there ever even been a >Matroska file with menus produced? If not, is it even worth >keeping alive? Yes, of course! I did, but it was an exercise for the students, not in production. I do neither know one who did in production. Best regards, Reto From nobody Mon Sep 25 11:17:14 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784CB132D96 for ; Mon, 25 Sep 2017 11:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHoMzfmdkKej for ; Mon, 25 Sep 2017 11:17:12 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663DD132332 for ; Mon, 25 Sep 2017 11:17:12 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:43130) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dwXw9-0003dd-1b; Mon, 25 Sep 2017 20:16:58 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 4B706654000B; Mon, 25 Sep 2017 20:16:57 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0206.59C9481A.007D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1506363417; bh=iepjf4qWZD/kl0SNNmf1RrAcvB44/Uav/mBZgc4RAO0=; h=References:From:To:Cc:Subject:In-reply-to:Date:From; b=KA+F6cnpmHpmeGEv7Xv984SMP6CSAb0zRAQA5Y1JnSTDVTOEZ/mn7ngM4sqnj1ig9 MohJ46L9zjHQFar4Wy+harlptKa08c48uYwIaHsQGzRjrgaoEcu3+AogbyraJyHXOi NHk2jc/c0lgoue6l8go8zz42AGbdDIb7jN5kBP/KvpqiFso4WxtO52Slr4ku9W9w4m tIU/S4gxJPZHzPHgSb/E8l34YtFeZmH5P47DUITwCV5KjDoFzpZaG0m9E6PXND/5RI A/CjXjy8LxhKASQwQzxlWLX4RZW58oaOziPn5t6JvzY+/QO/YOL8hYXMAFdraS+fl5 0+PitmN9HdiQJfgu8+E+z7ydrOFHg+myp7ANxiZfSiVAEURuhYcsRKaCPKnJjaY2rv je8kK1GXCF2WBOZh4w6KVYUJ+vrDSE5LAXFqAu8N22yQwg4pCf20p592DMmwbYkLuv E/2gMkms8Tfj7Qz6XKQLKglw1YqbRcOcmdK2/OYy9TVujqi2YkA5U6yTdCwjAULrox I1oL7viNQBWCYiBwCfTFm/TfAMclHGmtuYSlkZqHXya6gD3O0bGDM3sPAwlkwntgML 61sixwATihu9xktH6h5oIWfO7O4mpqghqDuyA+fNIH0Ja5AUruDvKYL0+8Iw0BbWGz p/jkTeLsNwbC+vK6JYILf504= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTPS id AAA241FFE8A8; Mon, 25 Sep 2017 20:16:56 +0200 (CEST) References: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> User-agent: mu4e 0.9.18; emacs 25.3.1 From: Moritz Bunkus To: Steve Lhomme Cc: Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission In-reply-to: Date: Mon, 25 Sep 2017 20:16:56 +0200 Message-ID: <8760c6iqxz.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 18:17:13 -0000 Hey, for MKVToolNix renaming those things would be a (big) problem. There are several places where the names and terms are used, with varying degrees of issues if they're changed: 1. The class names in the code. This is obviously not an issue if the class names are kept. However, I can foresee issues if we introduce new elements that deal with real timecodes (as in timecode tracks). One could imagine an element that contains the timecode (real world usage) a cluster starts on. In the specs that might be called… Cluster Timecode (as the old one would be renamed to Cluster Timestamp). However, in the code the old element is still called KaxClusterTimecode — so what should the new element be called in the code? 2. Program options and the corresponding documentation: there are several options in mkvmerge, mkvextract and mkvpropedit that deal with timestamps that are currently named something-timecode-something (e.g. `mkvextract file.mkv timecodes_v2 …` or `mkvmerge -o out.mkv --timecodes 0:tc.txt input.avi`). For each of those I'd have to add additional options named something-timestamp-something and keep the old names indefinitely in order not to break existing third-party applications. The documentation would have to be adjusted as well. 3. File formats. mkvmerge supports several versions of the file format used with its `--timecodes` option. Those files contain the word `timecode`, too, and I'd have to adjust the parser accordingly. Documentation has to be adjusted for this, too. 4. Strings in the GUIs: UI labels, help texts. 5. mkvinfo's output. mkvinfo uses the term `timecode` a lot in its user-facing output. As I know there are tons of users out there who parse mkvinfo's output and who get very upset each time I change the format, I've taken to be much more conservative about these changes. For options 2 through 5 my translators would have to translate a lot of new strings, too. These are the things that I can think of off the top of my head. Of those 5 is the most important one to me by far. At the moment I think I would opt not to change mkvinfo's output in order not to break existing applications. That would make the whole endeavour somewhat questionable for me. Apart from all the work it would impose on me, I also see the danger of overlooking consequences such a fundamental change. I'm not even positive I've thought it through in the context of MKVToolNix, the project I know the ins and outs of like no other. Standardization also means creating a stable base for implementations, and this change would be the opposite: a huge disruption to an already existing, huge software base. Therefore I have to agree with Dave and -1 such a change. Kind regards, mosu From nobody Mon Sep 25 14:06:32 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9601345A5 for ; Mon, 25 Sep 2017 14:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 mwLVpOIfwdov for ; Mon, 25 Sep 2017 14:06:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 64AB4126C0F for ; Mon, 25 Sep 2017 14:06:28 -0700 (PDT) Received: from [192.168.2.101] ([93.243.175.52]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MfEZG-1dhg3k0yl8-00OpW9 for ; Mon, 25 Sep 2017 23:06:26 +0200 To: cellar@ietf.org References: From: hubblec4 Message-ID: <7bd96443-79c5-24e7-fd3a-ce697e4be9de@gmx.ch> Date: Mon, 25 Sep 2017 23:06:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:yDGtTfBYGeXzp37DDiqLgghSdoFbamg0VeI7u8FBnoTZzgwK71n eBcTE/L9zOzLgcg67pNEEjCsPl997CZLzRCzeliOC/31q7BfCvoLpVCRMk2NmN/2e13/9NR YbFSJ6UV/dF5Zl5AYPO0lGxeeWd/5WgZEEEYWIWk9mLIaiA5O7QPco9R245SkUVFv0de4og 8SIpMBE8HgSL00fciUgzg== X-UI-Out-Filterresults: notjunk:1;V01:K0:bTBHr8F7LlQ=:JdpVfvYF5/iJRAsBM77CVE Mi1gphhzbekVGkWJ7MdjEX8eLrDXQYAADFbkcrHCrCIYx8j/myv6EiphMQbxwh8Jpx9oQ2uWa InXcbIUQ3zd9VTftZoKgoFmMuTlzgKiib8xg3uH2YnTn/4N+HUULO40t990m720WHitomK7mL cQXg5C05o8mRS6RkRHTXOidUq2jdgmhricyTxD8NBJMSQhDV21L8QiF5Mf+O40gcuAFCJN1Kv eVebNkqCS/O/DI9iCIIsZllBXIKmI4GqovbaqGsb19euSUwb5kK6kjUQmW6+1cOL+tpRV4R8c xPxXLGhy6MsrYOesCMhT3x74yw/Dscc6YYQKHnxPpXnpB28H3/EX33Roa6SiDpkOw/q5FFSBT OmCgc3F+ZZ0avkSGpt92aP4k59jUk5NGpTWekd6cWsMt4Y9I++92RrMZJChxy+WHYdqz7podv xlvRSbENuBLdRoluA2YxtgH5SywONrZdK3RFwb7YXYYu6DeQLHF8o3XKW/ml2rJ8mDz0EEmRQ 8nbL57s2ctNDuzH1vtOgrEleLZqiP8SFNmTayXw+kFQZ/QdNSNmISkbIW+tWlLdJqxOCKxz/p BKMS65ZqcPdVPDdATzAYN2k5jNbOfrbjt4hEk1bbPWkDJ2eHyz7jPSE+RA8qAlYW8rLv+vJJe PPHkDFWId2Hb/0cnbXQjn64C5y6sICgy9pE5SRXNIvk7NCJf8Y+FxEleN8hwwWZMfdLGi93FB xHxfaDc0391LOY74zVtLM6QsZOafVYT9WA2IMvCIVzgmFncxsCllHqmd2Q5ZVPpTuRzPWPsh7 XpdhKYgkMuQCeXFh01zjxUsLG3fkyXNb3d3Afjr21rI6i3iLXA= Archived-At: Subject: Re: [Cellar] Matroska: Lofty goals in the menu section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 21:06:31 -0000 Am 25.09.2017 um 19:46 schrieb Reto Kromer: > Derek Buitenhuis wrote: > >> This may be off topic, but... has there ever even been a >> Matroska file with menus produced? If not, is it even worth >> keeping alive? > Yes, of course! I did, but it was an exercise for the students, > not in production. I do neither know one who did in production. > Hey Reto, could you imagine to share your exercise with me/us? @Derek I have tried to build Matroska DVD menu mkv's with DVDMenuXtractor(DMX). This tool is very old and not compatible with the new MKVToolNix(mkvmerge). So I can't test such files. Another problem is, that VLC is the only one with such a support, and unfortunately it works not really good. While I studied Matroska, I found the "Medium-Linking-System" and with this system I have write a Matroska Menu Editor. Such menus are not a full menu like we know from DVD or Bluray, but it was my door to a "new Matroska Menu" which is grown in my mind. Best regards Martin Below From nobody Mon Sep 25 14:14:02 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739221345B3 for ; Mon, 25 Sep 2017 14:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04HdaFT4bM2Z for ; Mon, 25 Sep 2017 14:14:00 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB85B1345A8 for ; Mon, 25 Sep 2017 14:13:59 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id q8so8400067qtb.5 for ; Mon, 25 Sep 2017 14:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=j0zf9hPmpryDP/0jz8mMaqOenfoqGYdcvJHSDJOcYFs=; b=bt8S7lKPNOBvLhYuw6eaIuO5FTenrhCoP9SGjZtLc3Ww8OjQkhjMPPHRiAlDcVZiap pglNC9SS8GajIMcdQ8PM9J411uES7WCp0mOxgfF+86JhrzEmDahodoT6KuRw1eZ5tJo9 ErIMQgrnPImaf7Jy+KLxOBrDi3ZMAmrQ2O4PBfRMUfur00IZQJkz7MLgRaftFNmCpxb4 jijgynhlnunNXvpvSWsZKmkoctSREZNgpTiA/BlsB6iaeekYKmsjG0T9kXeLeVs7/1e3 av3Ep9TAZFeDg1Os4c5E3n9tOuPIJ3FYZhBDePz1mrLh0Nt7Cyp+EjvHXLn9aMwOeoZr 0YeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=j0zf9hPmpryDP/0jz8mMaqOenfoqGYdcvJHSDJOcYFs=; b=E/0KHSjkT65gHWiXKV3o26Q0Es23CoD4fGuT/2/6TbWczpeo1AOyENrcJ1ntaJ7Wny b8Nerm7GaoUMJn4JlxIUU+sJ9W4NFFgtIrpkfbJidgHKAjeYBCWtYhAg4TKIKA7dtEmC 653z7VXjRRRAShOFwF2Iwp1YzgaR2tzwxRR50ivwWUbjvZa6MROwTV4aI/4szabPq4tl fputya4GoVZrlnyEpaBV+qSw0qfns3vheIyYi7r2pagbQkg7Z0K3VHkp5SnCPgcyibN4 ocTxbKa8tFPrnEE65uQp07Pz2YcpY3Yz1nbwR51asdR/XpRhdSPHR+9AXgUWqf5gyNWz daTg== X-Gm-Message-State: AHPjjUjxaw44jZ/GWd9+WTVZVAJ0R3PriYfhmkK6y+IxeqC/VgEh3sXn it1DLBJQaxyCrN/wOf91YK4gbLkTj5GQy+gbUS7poMFD X-Google-Smtp-Source: AOwi7QBdeHFjiABQq1GgVLb6fxMvty0rZ8Dsd/LYX7ue8nVC7iyfyKwf0X+rGNJjHd6zo8qKTR2w1V6REdBmIOgJ7c8= X-Received: by 10.200.39.174 with SMTP id w43mr13919668qtw.154.1506374038602; Mon, 25 Sep 2017 14:13:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.172 with HTTP; Mon, 25 Sep 2017 14:13:57 -0700 (PDT) In-Reply-To: <6d910d4e-8cbb-afa2-5b4f-40cb7d01ae3f@gmail.com> References: <6d910d4e-8cbb-afa2-5b4f-40cb7d01ae3f@gmail.com> From: Hendrik Leppkes Date: Mon, 25 Sep 2017 23:13:57 +0200 Message-ID: To: CELLAR list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Matroska: Lofty goals in the menu section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 21:14:01 -0000 On Mon, Sep 25, 2017 at 6:31 PM, Derek Buitenhuis wrote: > On 9/25/2017 4:27 PM, Steve Lhomme wrote: >> The menu specificiation should probably be its own document, as it was >> before. We just need to make sure the corresponding elements are well >> described in the general Matroska specifications. Because we won't be >> able to reference documents that will be ready at a (much) later date. > > This may be off topic, but... has there ever even been a Matroska file > with menus produced? If not, is it even worth keeping alive? > I think its definitely something that should be considered to be dropped entirely. In its current form it has never really been used in the real world, and its also quite an antiquated approach, mimicking DVD menus. The documentation in the current matroska specs has been called a "draft" since forever and is full of language like "we'll try to..." - Hendrik From nobody Mon Sep 25 14:36:57 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA601345C0 for ; Mon, 25 Sep 2017 14:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 jbYrcSStWPCX for ; Mon, 25 Sep 2017 14:36:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 D126112EC30 for ; Mon, 25 Sep 2017 14:36:53 -0700 (PDT) Received: from [192.168.2.101] ([93.243.175.52]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MXZbS-1dtigH3P4o-00WYNG for ; Mon, 25 Sep 2017 23:36:51 +0200 To: cellar@ietf.org References: <6d910d4e-8cbb-afa2-5b4f-40cb7d01ae3f@gmail.com> From: hubblec4 Message-ID: <9cce8795-7216-29fe-259a-381f1f27fa77@gmx.ch> Date: Mon, 25 Sep 2017 23:36:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:u1xVOiHW5PamoqcHnC1GOt5AlpkhQ6HEkDlDKvKOYsk7Wlhi2xP UslveEcsiLH5I1pXJKkgHkse6o/u+k0p/pjdI2KBxnfmIFpm2UtCQ98U5HyMfV+EDI6gNUw ey3OgdlhhYdQENV5bDxFHnxJVvhBUwynnLSpjg+PqnAWOhgb6ZxggZqGm/QfNe7ZRTmEHWS DLhfg658kQ5gEqfoA+6Nw== X-UI-Out-Filterresults: notjunk:1;V01:K0:PWR9H3p6gCw=:epqRcvPVTs3qfrFjeY+fvE 0CfE/rylNFAtwWpnGuclMtK1K4W5E9KZJ+A+eiYY5mPNQxcpPZ4uU1q//9Jm4PJ9xOQgWRlUD ug9MgRR4d50zzPVax3cGXdH28T1e0qLo015qsNuW1TBk1blnZWiSZZx/Mya9FMlUS7fLVJRae lwzhkJh1YfkI37CnPJ08YoXDTIvCQpglo4aC/MI1hQUGXe+NS/VRRnS9QiWg0Vt+SceEJquCm /af+KLYpRKcAcmbKhSKAra+5RbUS6dV6z2aKAghbQYteVhHteASTd5rIJ9/GJz6Oy/RTH34xx Nr7PIA/o58eG03DzAxX/uJcMPXfAsXEFAgtXxhRhJPAlfHjmF+tLTsBe5WQ3Oet7CcNL6qUKo NleHRwjJOBMlBySVh54P7lj4aIaD6I3KZIM7g8V6VhzH0ReLig4r0fpDc/4M6lhPqY7DlX6dU og6lleVA16THOjLFUpkusSy7LPjIwLE7goL+gZYg3LDw4DXwySs+ZDFKG7SCVy0motDnrfnzi PKCx2YPhf/n+Oe4cRvrOtWknZCeDGJFN6K0MxFmtNO8LByL1ACYCMaP5Y0vV0WsblFS1d5XJA /X1Y9Osa/yzJ2P43Ae9v8peLOc4HSIyfKFHQrcCg29CPnJylhAO/Da9cKM/VHu1dTL1hiAh6l E++QfKHkWSMwVKEjzb0ffFp/WMJKGUgTgtqQaV2OHIUQyCfr8j95y8Eo01ZrBHEA6nOrUjJSC ZjnGkZoQGsam8ZBmGf5ZHR7CDc5vEcHOrwyhjkPhY9i7gxq2vtttmDDPOgdd0VoSus9f+gb6J 8yRMaahct/SE2Ju4Y4t8Mt8KIcZkRHD1owxcVQ0KV1ceMP+oYQ= Archived-At: Subject: Re: [Cellar] Matroska: Lofty goals in the menu section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 21:36:56 -0000 Am 25.09.2017 um 23:13 schrieb Hendrik Leppkes: > On Mon, Sep 25, 2017 at 6:31 PM, Derek Buitenhuis > wrote: >> On 9/25/2017 4:27 PM, Steve Lhomme wrote: >>> The menu specificiation should probably be its own document, as it was >>> before. We just need to make sure the corresponding elements are well >>> described in the general Matroska specifications. Because we won't be >>> able to reference documents that will be ready at a (much) later date. >> This may be off topic, but... has there ever even been a Matroska file >> with menus produced? If not, is it even worth keeping alive? >> > I think its definitely something that should be considered to be > dropped entirely. In its current form it has never really been used in > the real world, and its also quite an antiquated approach, mimicking > DVD menus. > The documentation in the current matroska specs has been called a > "draft" since forever and is full of language like "we'll try to..." > > - Hendrik > > Hi Hendrik, I know your are not a friend of menus and I don't like to remove things, but in this case maybe you are right. The Matroska DVD menu was / is never used. One important point (for me) are the specs which have to expand to discribe this system. All DVD Commands are now also in the Matroska specs with a description of their "new" usage. For the Matroska-Splitter developer it will be also much work to implement this system. But Matroska without a menu support is not good. A simple container like mp4 has menu support. Matroska can use his own Native menu system to get a simple, powerful menu function. Best regards Martin Below From nobody Mon Sep 25 16:49:33 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3D1134608 for ; Mon, 25 Sep 2017 16:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 CRL9CZenZaoH for ; Mon, 25 Sep 2017 16:49:31 -0700 (PDT) Received: from server172-2.web-hosting.com (server172-2.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C0E1345FC for ; Mon, 25 Sep 2017 16:49:31 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:41052 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dwd7v-001uOJ-0D for cellar@ietf.org; Mon, 25 Sep 2017 19:49:30 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Mon, 25 Sep 2017 19:49:23 -0400 To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-1.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] webm webvtt codec ids X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 23:49:32 -0000 Hi all, I=E2=80=99ve found a few matroska files using the "D_WEBVTT/SUBTITLES=E2=80= =9D codec id. This isn=E2=80=99t defined in the Codec specs and the = =E2=80=9CD_=E2=80=9D prefix isn=E2=80=99t either. I see this in both = webm code and in libavformat. Does the =E2=80=9CD_=E2=80=9D prefix for = codec mappings have any meaning worth defining? Do = "D_WEBVTT/SUBTITLES=E2=80=9D and "S_TEXT/WEBVTT=E2=80=9D have the same = meaning? Dave Rice= From nobody Mon Sep 25 16:56:45 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C425F134607 for ; Mon, 25 Sep 2017 16:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 NgNh0ERLfBy9 for ; Mon, 25 Sep 2017 16:56:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 F01371321A4 for ; Mon, 25 Sep 2017 16:56:41 -0700 (PDT) Received: from [192.168.2.101] ([93.243.175.52]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LiHc7-1damfc2ifb-00nUQM for ; Tue, 26 Sep 2017 01:56:39 +0200 To: cellar@ietf.org References: From: hubblec4 Message-ID: <0195d532-101f-f179-b494-ed4c4ce2943e@gmx.ch> Date: Tue, 26 Sep 2017 01:56:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------55B380175B5987BE3D1777E1" X-Provags-ID: V03:K0:yDFkUpK+aU6bMUgrM6A9lBlNxZEmngmJr3hve1yMCMST9c7gDAe 2/2kafvmI0QTSuIooDl52Rl5G8pj34hbzcngYrwpKCiyhU/qAIPvtAK8QCxkZrKfwDXTwTf Wf+OPl96GumgNKrj4piVtAjlaKlOZ2lWpMbE61wWoZq7Qgg0jwOLMsD/YtUQZPlsYkJtWVr uuD04/fRtYubz7S6r8BhA== X-UI-Out-Filterresults: notjunk:1;V01:K0:tVUaXDUxnNc=:g4UfLpuJV74hd5dzROb8uA +A+vedRqA0oxHSsxDbXDw/YN7HBkv/pCTf2A+skGsS5dppl1o0u+sz73yQiBeoH7SxCpNfDx1 fhzRWWUeoYLdSixbHnjU/NbkQetOC2i87Z8QGL18/e8fPZiPtUTYVWSZJrMED+vqbDSenrFqc Uf+TjWVhBLryKR+9eEGtyJ0MEmNon/65Xt+cddh7TazW+apcASbiuVXfQ9NQXC6Md27zRsIun i/npmbWhCQwKbhWkK/yhulaiWlsTzZ4K4CZPbWSd7srY15xdUlN0+5r99FO9FnrjqP6w+MztJ AP2ev3Ep7foay9WrJNjPmiExVL2JyWzWmnkz0OLc5oEbegEWuS4W/jeV7ldHcLRGjq+LY1gYU B3Eb0+V10+pc4sidlIDaN4V+at+akDnRb7hsbnyxNC5tnE/knq60L5i5fIM2ysgw1Vyx6wxV5 bYmFcq8g61JZoC5mbjSSRXG1CIW1mbxc3+KCvjVGjtH/q1C0VkJcuSxFh/RuPzXGteWLRlzMg aLvxaevbNtLtIt4VQe/swAm4T8y6cmnncIPmPQe9eCEEBYeYzQUSnpztsaT65QWXAmYHGOONF 9QmJV6PECpSESV9ktGDrv/Nd4Zr5rizr/AnN1RlZywGeEFm++Bxb+ePASl5JV8JDF/9vgKFH3 PYX6vgqb2T3rRDHBf/nTQEV6p2afCvjlgpzrczVsBovldNVTrjFDvSz8b0srQJqf6O8bk8HDC 89I6TPHdjbK6oalN3FujsRqlN9JiaIDpne7mSby1neHbZXXHNlT2bfQ/lRJQngM4p83B44I3b 0azAptxMoJDSRre3GQCiHRl2nQ9t0forXaj6PcxoZRgvRj6XKQ= Archived-At: Subject: Re: [Cellar] webm webvtt codec ids X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 23:56:44 -0000 This is a multi-part message in MIME format. --------------55B380175B5987BE3D1777E1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dave Am 26.09.2017 um 01:49 schrieb Dave Rice: > Hi all, > I’ve found a few matroska files using the "D_WEBVTT/SUBTITLES” codec id. This isn’t defined in the Codec specs and the “D_” prefix isn’t either. I see this in both webm code and in libavformat. Does the “D_” prefix for codec mappings have any meaning worth defining? Do "D_WEBVTT/SUBTITLES” and "S_TEXT/WEBVTT” have the same meaning? > Dave Rice > How old are the matroska files? WEBVTT subs have not been so long implemented in Matroska. For the moment I would say this ID's are wrong. Martin --------------55B380175B5987BE3D1777E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Dave

Am 26.09.2017 um 01:49 schrieb Dave Rice:
Hi all,
I’ve found a few matroska files using the "D_WEBVTT/SUBTITLES” codec id. This isn’t defined in the Codec specs and the “D_” prefix isn’t either. I see this in both webm code and in libavformat. Does the “D_” prefix for codec mappings have any meaning worth defining? Do "D_WEBVTT/SUBTITLES” and "S_TEXT/WEBVTT” have the same meaning?
Dave Rice

How old are the matroska files? WEBVTT subs have not been so long implemented in Matroska.

For the moment I would say this ID's are wrong.

Martin
--------------55B380175B5987BE3D1777E1-- From nobody Tue Sep 26 00:31:52 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86A9132D44 for ; Tue, 26 Sep 2017 00:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHbufQtmEclt for ; Tue, 26 Sep 2017 00:31:49 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69755132D41 for ; Tue, 26 Sep 2017 00:31:48 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id t127so6450591ywg.4 for ; Tue, 26 Sep 2017 00:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=LB+QcCW1W5bXS9vNoaH6dXaPQDro3cwu0cGM0fAqBNg=; b=P8IVbiTdT6I3MZrF1E7QrPUmEv4KSvWZ607k/oOSAs1hziCNEzLkDASXeuMQOB0+PI GYjhfhmqEjKP/Pebax+5ODIUJ5qn3Fq543c2VSpmO6zmQL0jl607RZJ2I/lRGXFUqsIn xf+SOwDTespbyAkUC3msBPDmZlrEstqrKR1U/tOHpTqP9alevdBR98KM/KCeydKdM88B DSV2vLgi3y6OozExwjxvBByuvFgbIfIKPg3TdwkFmpDmRiXbJLtOFYp+mI2ncavYek8z IWpQqhBnvJ57Mvg8XhQFJMFcLeXBWqJXCVdh9X8jCApoOIs356zFz5uK80a0n4JcTG/G xLdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=LB+QcCW1W5bXS9vNoaH6dXaPQDro3cwu0cGM0fAqBNg=; b=MFBsbkk8vqPR4BO0r6vAhJcKzRtVE2dxl9pG8GfjWmsx3ZlUxiXD3o9UBg4yNXB3H2 7nC8NjP8Lqd8w5XgP7+0JBtvF3FMzOXu9kb+ecGS7m1WGh3EgIUGUCLgIA65fO0kjI12 v89HR0Z4uyiQx8ryzyB4CeVsQTilnaV9fkW8ASwJlnBjVrd7n9aV9W7+Fs8PvrJt7Tmw L5kjczWq7WHB4D17ybyLL0Ql1Fmb0mfKonzbs0Sca6HHKJ+cipLQKbw6vF16k3HpGVqK qvEfT9zc7aOq6EUuAR9H+kfTdTWQseoei4MeNhEsqE6ez1e2QtrBfp1g2W12qgnUV5oB eYXQ== X-Gm-Message-State: AHPjjUg/9mJ6VjQCiszL8y51yi5skFltE9MuyEI0PVI1SjjM94zDOs2C QVPlo3tmPRvPO1TRlGabGtKn2YoErr5g4LtxvzzAq54S X-Google-Smtp-Source: AOwi7QCt1RNgaOP/dBS5b8XAcmLaggvBsOkesFFhQ6VRHZ8GCd6qjgENcPTB1SNjVZ0rYc0N1SNN0OVjddytKgmkxRI= X-Received: by 10.37.171.97 with SMTP id u88mr5933153ybi.324.1506411107922; Tue, 26 Sep 2017 00:31:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Tue, 26 Sep 2017 00:31:47 -0700 (PDT) In-Reply-To: <8760c6iqxz.fsf@bunkus.org> References: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> <8760c6iqxz.fsf@bunkus.org> From: Steve Lhomme Date: Tue, 26 Sep 2017 09:31:47 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 07:31:51 -0000 2017-09-25 20:16 GMT+02:00 Moritz Bunkus : > Hey, > > for MKVToolNix renaming those things would be a (big) problem. There are > several places where the names and terms are used, with varying degrees o= f > issues if they're changed: > > 1. The class names in the code. This is obviously not an issue if the cla= ss > names are kept. > > However, I can foresee issues if we introduce new elements that deal > with real timecodes (as in timecode tracks). One could imagine an > element that contains the timecode (real world usage) a cluster starts > on. In the specs that might be called=E2=80=A6 Cluster Timecode (as th= e old one > would be renamed to Cluster Timestamp). However, in the code the old > element is still called KaxClusterTimecode =E2=80=94 so what should th= e new > element be called in the code? In this particular case it's easy, there cannot be a Timecode for a Cluster. There cannot be a timecode scale or track timecode scale either. Also if it's a track type there might be specific fields in the track entry but it will probably be prefixed, similar to KaxVideoPixelWidth or KaxAudioSamplingFreq. > 2. Program options and the corresponding documentation: there are several > options in mkvmerge, mkvextract and mkvpropedit that deal with > timestamps that are currently named something-timecode-something > (e.g. `mkvextract file.mkv timecodes_v2 =E2=80=A6` or `mkvmerge -o out= .mkv > --timecodes 0:tc.txt input.avi`). For each of those I'd have to add > additional options named something-timestamp-something and keep the ol= d > names indefinitely in order not to break existing third-party > applications. > > The documentation would have to be adjusted as well. I don't think this is a huge task. And it is not mandatory even if the names in the specifications change. The "--timecodes 0:tc.txt" is more problematic. But it will have to be handled when (and not if) we add real timecode tracks. > 3. File formats. mkvmerge supports several versions of the file format us= ed > with its `--timecodes` option. Those files contain the word `timecode`= , > too, and I'd have to adjust the parser accordingly. > > Documentation has to be adjusted for this, too. The file format shouldn't change for the timestamp files, too bad it's called timecode. But if it was called blahblah people will still need to read/write it that way. > 4. Strings in the GUIs: UI labels, help texts. It might be the trickiest part. But again, that will need to be done one way or another because timecode tracks are coming. > 5. mkvinfo's output. mkvinfo uses the term `timecode` a lot in its > user-facing output. As I know there are tons of users out there who > parse mkvinfo's output and who get very upset each time I change the > format, I've taken to be much more conservative about these changes. Yes, IMO that shouldn't change. Or if it becomes a problem with timecode tracks, have a legacy mode using the old strings and by default use the new ones (or the other way around). > For options 2 through 5 my translators would have to translate a lot of n= ew > strings, too. > > These are the things that I can think of off the top of my head. Of those= 5 > is the most important one to me by far. At the moment I think I would opt > not to change mkvinfo's output in order not to break existing > applications. That would make the whole endeavour somewhat questionable f= or > me. > > Apart from all the work it would impose on me, I also see the danger of > overlooking consequences such a fundamental change. I'm not even positive > I've thought it through in the context of MKVToolNix, the project I know > the ins and outs of like no other. Standardization also means creating a > stable base for implementations, and this change would be the opposite: a > huge disruption to an already existing, huge software base. But the first thing you see in the Timestamp section is that it used to be called timecodes. > Therefore I have to agree with Dave and -1 such a change. Rather than voting I'd prefer reaching a consensus. > Kind regards, > mosu --=20 Steve Lhomme Matroska association Chairman From nobody Tue Sep 26 00:34:11 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D861A132D44 for ; Tue, 26 Sep 2017 00:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 g-ne2QiFsDfo for ; Tue, 26 Sep 2017 00:34:07 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A385F132D41 for ; Tue, 26 Sep 2017 00:34:06 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8Q7Y4Qt021829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 26 Sep 2017 09:34:04 +0200 Received: from castor.home (dynamic.wline.6rd.res.cust.swisscom.ch [IPv6:2a02:1205:c688:7d90:ed7b:ef2d:64a8:f31a] (may be forged)) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8Q7Y3Bb058995 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 26 Sep 2017 09:34:03 +0200 Date: Tue, 26 Sep 2017 09:34:04 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Matroska: Lofty goals in the menu section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 07:34:10 -0000 hubblec4 wrote: >could you imagine to share your exercise with me/us? I have included some of our experimentations in the presentation for Vienna. I could add this one too, although all the others come from the production side and are not academics' playground. Best regards, Reto From nobody Tue Sep 26 00:38:01 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E7A132351 for ; Tue, 26 Sep 2017 00:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 YRJM9gCFj9Ss for ; Tue, 26 Sep 2017 00:37:59 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37A113209C for ; Tue, 26 Sep 2017 00:37:58 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8Q7bufm004850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 26 Sep 2017 09:37:56 +0200 Received: from castor.home (dynamic.wline.6rd.res.cust.swisscom.ch [IPv6:2a02:1205:c688:7d90:ed7b:ef2d:64a8:f31a] (may be forged)) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8Q7buJI012326 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 26 Sep 2017 09:37:56 +0200 Date: Tue, 26 Sep 2017 09:37:56 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 07:38:00 -0000 Steve Lhomme wrote: >Rather than voting I'd prefer reaching a consensus. +1 From nobody Tue Sep 26 00:42:34 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B02C13209C for ; Tue, 26 Sep 2017 00:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LGWOxUPUFbJm for ; Tue, 26 Sep 2017 00:42:30 -0700 (PDT) Received: from 9.mo177.mail-out.ovh.net (9.mo177.mail-out.ovh.net [46.105.72.238]) (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 216AA12426E for ; Tue, 26 Sep 2017 00:42:29 -0700 (PDT) Received: from player688.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id DD0A57B244 for ; Tue, 26 Sep 2017 09:42:27 +0200 (CEST) Received: from [192.168.2.120] (p5DDB6596.dip0.t-ipconnect.de [93.219.101.150]) (Authenticated sender: jerome@mediaarea.net) by player688.ha.ovh.net (Postfix) with ESMTPSA id 51B0D2008B for ; Tue, 26 Sep 2017 09:42:27 +0200 (CEST) To: cellar@ietf.org References: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> <8760c6iqxz.fsf@bunkus.org> From: Jerome Martinez Message-ID: <78f095a8-664d-66ed-b44f-867e78e71144@mediaarea.net> Date: Tue, 26 Sep 2017 09:42:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Ovh-Tracer-Id: 352125198199754897 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelledrjedugddufeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 07:42:32 -0000 On 26/09/2017 09:31, Steve Lhomme wrote: > 2017-09-25 20:16 GMT+02:00 Moritz Bunkus : > [...] > >> 4. Strings in the GUIs: UI labels, help texts. > It might be the trickiest part. But again, that will need to be done > one way or another because timecode tracks are coming. This is my concern too. If we keep the name as is in IETF specs, we "sanctuarize" it, and we may have issues when we talk about a time code track. > >> 5. mkvinfo's output. mkvinfo uses the term `timecode` a lot in its >> user-facing output. As I know there are tons of users out there who >> parse mkvinfo's output and who get very upset each time I change the >> format, I've taken to be much more conservative about these changes. > Yes, IMO that shouldn't change. Or if it becomes a problem with > timecode tracks, have a legacy mode using the old strings and by > default use the new ones (or the other way around). Not so easy, as there may be other tools handling output after using our tools (I have the same issue as mkvinfo with MediaTrace output), e.g. output is stored in a database for long term searching, and changing words has impact on output previously stored. Headache. But I think it is better to do it now rather than handling misunderstandings later about timecode being timestamp and timecode being really time code. > >> Therefore I have to agree with Dave and -1 such a change. > Rather than voting I'd prefer reaching a consensus. +1 ;-). More seriously, I don't see something in the middle, looks like a binary choice :( (we change or we don't). If no change, this is also like saying that there will be never a change in words when it is written once. This is a bit hard, I would say that only hexadecimal values should be fixed. In that case, I guess we need to put a bit everywhere a "( meaning timestamp)". Someone with a proposal able to have a consensus? Jérôme From nobody Tue Sep 26 00:55:53 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B7F132351 for ; Tue, 26 Sep 2017 00:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmvvGuqmUS1C for ; Tue, 26 Sep 2017 00:55:50 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5AA132A1A for ; Tue, 26 Sep 2017 00:55:49 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id u11so6497697ywh.7 for ; Tue, 26 Sep 2017 00:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=qEPf29j4dYzHBHPb2An5ZP15phTsX7Tt6W0/LmQOuJU=; b=aWV9PCvI6T6YoNpT9KxGiU3k8J0Tvdu7bebeGrYpRf+V4h4TfFHplw9PS6hMkxfTz7 rj8BVSBROCah/y55LYKUbzmQ6NFR1VMQDJu6TL3P/NICpG8cCuMko1Pf5+0RMFo8n4Up j0uGo7UBRKi7svpDyOijoupvCYCnhFNsTSGefMjNs/qKPpLfQxDk0wGHmEsNCxrGNBhT sdhgvfvPpA1ZU/Qh1LCknLo/RlQ00UyJS5EyhzV7lErx/aeUwCkP8OCBGp0sFOaSgf5m 8/GroKlcdUh5ZU7R7hi3l5hpy5gSQr7lmbKL27TZzWk3p+7ybUM3qu19tb36dPA0s+GQ TlrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=qEPf29j4dYzHBHPb2An5ZP15phTsX7Tt6W0/LmQOuJU=; b=MsNfqlpPyUgJhcDOIk7to3g8ZYe/Hlcb1hLH99spbhdhvRghODYCbyir5rQxRgc6U4 bUOP/GvGC8YdcXLsEO79gcOE95535hYoDRmL20EMUGOIp4Wcl18PWP14q902Bf9lAJAQ L/9ML3BEMTJgnHEF8A8eXMnyWSxgimaJzH7BTbZphZYBucbCi/a5lOxCExuBxcboUvpH MFPcvvwamTDAUfRXNd2QgXmKZE65nDsUqiNW3BghZlAFq+6yCXUeKfhW7nlR0Xmn7Da3 Mx8YrMizg0Q6ssQfaxQKgYodmUqMTsBNMo3QucAhAwdU2k2LMp9fK2lWj2IyzACuSO3O v0lQ== X-Gm-Message-State: AHPjjUjQWuukQE3+tWDuEbW9eDRdBhQaXVwVLTEOh6BZfb1h0ikBuODJ Bf2P+EVieiuEsly5+TcJJA3RX8zeeVTKy9YGw1rvAA== X-Google-Smtp-Source: AOwi7QAGqor+qneJuIjGhu8SuLJwv2x10NjbqeC7S7uz8msCWTL2hCN40GY38PX+h3iu8F/IESrIgyWhP+i8cC0s5YA= X-Received: by 10.129.141.70 with SMTP id w6mr6160840ywj.301.1506412548969; Tue, 26 Sep 2017 00:55:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Tue, 26 Sep 2017 00:55:48 -0700 (PDT) In-Reply-To: <78f095a8-664d-66ed-b44f-867e78e71144@mediaarea.net> References: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> <8760c6iqxz.fsf@bunkus.org> <78f095a8-664d-66ed-b44f-867e78e71144@mediaarea.net> From: Steve Lhomme Date: Tue, 26 Sep 2017 09:55:48 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 07:55:52 -0000 Maybe it will be easier to reach a consensus when we have Timecode tracks. So we can delay this change until timecode tracks are (mostly) done. 2017-09-26 9:42 GMT+02:00 Jerome Martinez : > On 26/09/2017 09:31, Steve Lhomme wrote: >> >> 2017-09-25 20:16 GMT+02:00 Moritz Bunkus : >> [...] >> >>> 4. Strings in the GUIs: UI labels, help texts. >> >> It might be the trickiest part. But again, that will need to be done >> one way or another because timecode tracks are coming. > > > This is my concern too. > If we keep the name as is in IETF specs, we "sanctuarize" it, and we may > have issues when we talk about a time code track. > >> >>> 5. mkvinfo's output. mkvinfo uses the term `timecode` a lot in its >>> user-facing output. As I know there are tons of users out there who >>> parse mkvinfo's output and who get very upset each time I change th= e >>> format, I've taken to be much more conservative about these changes= . >> >> Yes, IMO that shouldn't change. Or if it becomes a problem with >> timecode tracks, have a legacy mode using the old strings and by >> default use the new ones (or the other way around). > > > Not so easy, as there may be other tools handling output after using our > tools (I have the same issue as mkvinfo with MediaTrace output), e.g. out= put > is stored in a database for long term searching, and changing words has > impact on output previously stored. > Headache. > But I think it is better to do it now rather than handling misunderstandi= ngs > later about timecode being timestamp and timecode being really time code. > >> >>> Therefore I have to agree with Dave and -1 such a change. >> >> Rather than voting I'd prefer reaching a consensus. > > > +1 ;-). > > More seriously, I don't see something in the middle, looks like a binary > choice :( (we change or we don't). > If no change, this is also like saying that there will be never a change = in > words when it is written once. This is a bit hard, I would say that only > hexadecimal values should be fixed. In that case, I guess we need to put = a > bit everywhere a "( meaning timestamp)". > > Someone with a proposal able to have a consensus? > > J=C3=A9r=C3=B4me > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Tue Sep 26 01:08:53 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87E2128D0D for ; Tue, 26 Sep 2017 01:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-DMH6xHx3-H for ; Tue, 26 Sep 2017 01:08:51 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6051321A6 for ; Tue, 26 Sep 2017 01:08:51 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id s62so6512537ywg.0 for ; Tue, 26 Sep 2017 01:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ZIW2VyI+Ii2MKFQ+eMkNvhoEsOhGnfRjxlOyDiuNERM=; b=UOVBIlGpRRCO9FyBCDm0pFzrpDXUi3EiJig+eUO+4AAyaOCTLK/QIj8MltX3DErwmV 5umGDrn098raf03a4/V5bft9KmNt0a8PEILZuRXBs4vHNS4B5Iw2ZrG99aTd1cdbZCCl CX6vWgIl00o/3+6URARLc262gxIagf9PBe7cIA+4Ag2mrsFnbbvvioyx4lZvZC4vHb3F pQRsefPQRDGfmYAM2WJqzObbJHaO3vx6B4o5TvCR+vzmcZD6aL/kDsOZKo/34wjgh3Wa HmwAeJQewx3AQLbYcMyN+2jN5rV3xOXxjjee5ECRwrEVrbjtNOe762DHWxncO0esIvKR Zyrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ZIW2VyI+Ii2MKFQ+eMkNvhoEsOhGnfRjxlOyDiuNERM=; b=WUdv/Bliu/zImVKb8BgDtbcsxk5adR1fiioUx9ps/+dqhuVZhN9keUlY4dS6XOIXDt GbCOuyadkIJOiCz+IbCvpMcbJ2NUXGvcwuBgPDSfxoDcsyF5Mz7ZCXEMDLvGMQYZBkST lp40mykOtz5CcXAllFj327yjwnJXha5Bk/sSPsSWRsv6Fw3NyoXkNNeI0yFwiKMBkiKt 7EH6irWP9R21iFNtYJ75BDZ1u2VL75aYcuA/PCyuwQBfGzShZSEKs/gv/6+iSQmpljbh tzyIXvosxxOKwO6vX5wSPEsr74GoyWznLWdCKnSL2of2NXYacnfLV2PSYXMQgayoUfiz s4Fw== X-Gm-Message-State: AHPjjUg/pzwtIRxO40S6Z5KsPBPo3pnhaz7MAPJHz6Z1yH3uZdwx0XNx kZozZpPXNIPbdB68U97YFl4YNvja4lb4Zti0l72Lsw== X-Google-Smtp-Source: AOwi7QA+rzP0gI2lFcqj3VQ9OhaYXjXSaJc3OgyZNB0GAODWeFQiccxZ8NrD9afnOOJJkE/gaooWLjljPnACNM2TCQg= X-Received: by 10.129.85.215 with SMTP id j206mr6136303ywb.230.1506413330392; Tue, 26 Sep 2017 01:08:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.48.215 with HTTP; Tue, 26 Sep 2017 01:08:49 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Tue, 26 Sep 2017 10:08:49 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Matroska: Lofty goals in the menu section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 08:08:53 -0000 IMO we should keep the "chapter codec" approach. It seems flexible enough to allow a lot of things. Then there's the question of which codec to define, if any. IMO the Matroska one should be kept as well. It doesn't contain a lot of commands and it's supported by a few players. The DVD one should go. It's incomplete and not well supported (I fixed basic support in VLC recently, but still). But there's the legal aspect. It's based on reverse engineered DVD specifications. 2017-09-26 9:34 GMT+02:00 Reto Kromer : > hubblec4 wrote: > >>could you imagine to share your exercise with me/us? > > I have included some of our experimentations in the presentation > for Vienna. I could add this one too, although all the others > come from the production side and are not academics' playground. > > Best regards, Reto > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Tue Sep 26 01:35:42 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7231132D41 for ; Tue, 26 Sep 2017 01:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaKDBFM66kCK for ; Tue, 26 Sep 2017 01:35:39 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2F413292E for ; Tue, 26 Sep 2017 01:35:38 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o77so9294150qke.9 for ; Tue, 26 Sep 2017 01:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=1qkQTanYWmpxX8dV1GgRPVpfjAuBZj1klmBflg9Ofn8=; b=PgPP0IY8f9sD3d8F4l3oRcuUEMYAVTE99d363o9H28xKqinT5bcMtqgWquzcmV7l/Y 2Bv9jN7wn+ZjdXg7tA661wHAkifjRqvxuqXMs5VZG5eUlI4mQefMslayo36Nh7GDgC29 ajmNF9muQz28lVCVpiABdSXK7qM+Piat5NgN4KFIb4BvISlrHM4WwIIPcuKoTFGsqlTW JZExLRapYyH76SE0HFBfplGU6wkLqCdsvtVGUwE0uS3HxrKF5fbDQiB71okH17uq7YUX 7SgSRAVoBVKBwRCXsglsNJytbWuh69aR7puQf6+o/cNtki/zN74QkcPWX15O5/G1ZAVt j4/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=1qkQTanYWmpxX8dV1GgRPVpfjAuBZj1klmBflg9Ofn8=; b=Qg4bQabwXxeqYCMdhjA8aqGAO/6p3CRf1LtdNCf8PcGUEwdhGsK4lnvfhi4Wp76/tF 7tpfnv5hLaCSQIUVkpwF7agNHFdhF6z+8ttiiSyeu8X/sS6YWR09TqCoOrgBKxYGx/4e 9/xuNNchF2SNv+pahndowpIlnGs4vSdGAQGymCLjlmXNs73EOuIJB9+MR0FUEd1ozqcv q2ytIjqQURAZ4MWajlM7gnsVl4J9xH+8euU1m19XHlwYVGLbVh+zSE4IY/fUjkOO7fGD f/X1GqYK0x27ThR9y4ysDV2f/mcibV97kWq4Dk71sG4SJ38IQdv1GcQq3eVRKwtWhs/d 6xQQ== X-Gm-Message-State: AHPjjUioHYfw4BkaaJrTBUOz8Dtn7wS4AZIX958Hg2GSXrl/BBJc+GCk iXce8GRepeP/KC2jIPWvWq5pAVbc3VEHSmcy2dO1BPrH X-Google-Smtp-Source: AOwi7QANFrksyV3hScDqPjh/cQyUdXVSLLMsQjdoYF4X4NmXwPbWLXdj4NwiQMOpla2aiVbac3oZiBp4kVTkOcoVwzk= X-Received: by 10.55.126.2 with SMTP id z2mr14376699qkc.39.1506414937817; Tue, 26 Sep 2017 01:35:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.172 with HTTP; Tue, 26 Sep 2017 01:35:37 -0700 (PDT) In-Reply-To: References: From: Hendrik Leppkes Date: Tue, 26 Sep 2017 10:35:37 +0200 Message-ID: To: CELLAR list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] webm webvtt codec ids X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 08:35:41 -0000 On Tue, Sep 26, 2017 at 1:49 AM, Dave Rice wrote: > Hi all, > I=E2=80=99ve found a few matroska files using the "D_WEBVTT/SUBTITLES=E2= =80=9D codec id. This isn=E2=80=99t defined in the Codec specs and the =E2= =80=9CD_=E2=80=9D prefix isn=E2=80=99t either. I see this in both webm code= and in libavformat. Does the =E2=80=9CD_=E2=80=9D prefix for codec mapping= s have any meaning worth defining? Do "D_WEBVTT/SUBTITLES=E2=80=9D and "S_T= EXT/WEBVTT=E2=80=9D have the same meaning? This codec id is from the WebM spec, strictly speaking its only valid in webm, not in Matroska. https://www.webmproject.org/docs/container/#webvtt-guidelines They use D_WEBVTT/ for different content in WebVTT format. PS: Re-send to the list. Can someone please configure this mailing list to properly set Reply-To headers, so I don't keep messing up replying to the list? - Hendrik From nobody Tue Sep 26 01:39:05 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FEB132D41 for ; Tue, 26 Sep 2017 01:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 P_1b94OzXWra for ; Tue, 26 Sep 2017 01:39:02 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32697132C2A for ; Tue, 26 Sep 2017 01:39:02 -0700 (PDT) Received: from smtp5.infomaniak.ch (smtp5.infomaniak.ch [83.166.132.18]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8Q8cxiA009494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 26 Sep 2017 10:39:00 +0200 Received: from castor.home (dynamic.wline.6rd.res.cust.swisscom.ch [IPv6:2a02:1205:c688:7d90:ed7b:ef2d:64a8:f31a] (may be forged)) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8Q8cxXN045876 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 26 Sep 2017 10:38:59 +0200 Date: Tue, 26 Sep 2017 10:38:59 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Matroska: Lofty goals in the menu section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 08:39:04 -0000 Steve Lhomme wrote: >IMO we should keep the "chapter codec" approach. It seems >flexible enough to allow a lot of things. > >Then there's the question of which codec to define, if any. IMO >the Matroska one should be kept as well. It doesn't contain a >lot of commands and it's supported by a few players. I agree. >The DVD one should go. It's incomplete and not well supported >(I fixed basic support in VLC recently, but still). But there's >the legal aspect. It's based on reverse engineered DVD >specifications. I know. Yet prime numbers are never illegal ;-) Sadly, archives have to deal with DVDs. The content should be "migrated" as long as the drives are available and cheap. Therefore I personally consider Matroska an excellent solution for this purpose. Best regards, Reto From nobody Tue Sep 26 01:49:44 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E8713292E for ; Tue, 26 Sep 2017 01:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_Kc9S2JbYvg for ; Tue, 26 Sep 2017 01:49:42 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E1413207A for ; Tue, 26 Sep 2017 01:49:41 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:60280) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dwlYd-00069S-1S for cellar@ietf.org; Tue, 26 Sep 2017 10:49:35 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 385F5654000B for ; Tue, 26 Sep 2017 10:49:35 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0203.59CA149F.01C7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1506415775; bh=XY8s2xFTh1QILilIbx3tl3c6kG7ddrIxxI7A+WEXXRc=; h=References:From:To:Subject:In-reply-to:Date:From; b=CfddaWYZ+DHsSVGjsFNd2F3vbhgHa2N9N5tcrR1IysFvaDAlqR6ElAN5gNrCTbcHn Znupli+/EDxd/ibI2sZfWc5U6kpezH6mKHqloWC9QW7uqRch3WWkh18R2AUkgjyVko R1lIPfTR3EQkmUZBHQ7o2/Rak+drxF4WlVcWKQs2jQ/1Dd79YD8b8JJvvaqqG2j5vI hhkqsDPAWMCdH1SSQJn/5ryzuq7lsZiTbyPwFUQ/jvNlCmW/UYm8nnxXW8kRiucZU4 WEq/6ic3DkTqtY22o8wm+U7uBNyX4lp0IgwwyZEl0XLMPb9lDGQMaum8WGY8H4TAp5 EGbcN1Z0CZ3Bju47o4yjqBgAV2VHoDYn9TF92jCGAeYszaGoXd6YxETdsTlSAOftdl idPXwEISGR2bL5A1fHwZuhEOE0H20UnsaQAJjifsNOWZGzvvk7pSS7UmZBRqRwwveR 1kOPneRaPm/q1OheeyQt5Nv0XI5h86kdIiA8mgHydttjxAalQqX6nhX6MgXcpPEeNg xq4+DpNitlMuRKAgcmPcUKVQHBdn6u9yxim25P06+r/XqQNBPzSPX+BGkNQkNObU48 G1KKN7Hip6GE2Nk7eKJ0wLyKZTKQjkW313xe48Li/Y97kZerqiWYg4xdHKIuLPqplR pRhKssdV73GrPbOfZHEh0Evk= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTPS id 826B32008AB3 for ; Tue, 26 Sep 2017 10:49:34 +0200 (CEST) References: User-agent: mu4e 0.9.18; emacs 25.3.1 From: Moritz Bunkus To: CELLAR list In-reply-to: Date: Tue, 26 Sep 2017 10:49:34 +0200 Message-ID: <87ing5n8td.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] webm webvtt codec ids X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 08:49:43 -0000 Hey, >> I’ve found a few matroska files using the "D_WEBVTT/SUBTITLES” codec >> id. This isn’t defined in the Codec specs and the “D_” prefix isn’t >> either. I see this in both webm code and in libavformat. Does the “D_” >> prefix for codec mappings have any meaning worth defining? Do >> "D_WEBVTT/SUBTITLES” and "S_TEXT/WEBVTT” have the same meaning? D_WEBVTT/… are CodecIDs from the WebM mapping for WebVTT[1]. However, back when I implemented WebVTT for Matroska in March 2016 I noticed that the WebM mapping was based on an older WebVTT spec and that it did not represent best Matroska practices. Therefore we decided on a different mapping in Matroska. See [2] for details. So no, we should not define it (our official mapping is S_TEXT/WEBVTT), and it is definitely not the same. Kind regards, mosu [1] http://wiki.webmproject.org/webm-metadata/temporal-metadata/webvtt-in-webm [2] https://lists.matroska.org/pipermail/matroska-devel/2016-March/005012.html From nobody Tue Sep 26 01:54:33 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF8213292E for ; Tue, 26 Sep 2017 01:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTS6GQEWiBxa for ; Tue, 26 Sep 2017 01:54:30 -0700 (PDT) Received: from 10.mo177.mail-out.ovh.net (10.mo177.mail-out.ovh.net [46.105.73.133]) (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 AB76413207A for ; Tue, 26 Sep 2017 01:54:30 -0700 (PDT) Received: from player688.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 87C357CD80 for ; Tue, 26 Sep 2017 10:54:28 +0200 (CEST) Received: from [192.168.2.120] (p5DDB6596.dip0.t-ipconnect.de [93.219.101.150]) (Authenticated sender: jerome@mediaarea.net) by player688.ha.ovh.net (Postfix) with ESMTPSA id 359DF20083 for ; Tue, 26 Sep 2017 10:54:28 +0200 (CEST) To: cellar@ietf.org References: <87ing5n8td.fsf@bunkus.org> From: Jerome Martinez Message-ID: <47677471-0154-6f74-1e0c-588eb63e6a00@mediaarea.net> Date: Tue, 26 Sep 2017 10:54:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <87ing5n8td.fsf@bunkus.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Ovh-Tracer-Id: 1568378572488708241 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelledrjedvgdduudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] webm webvtt codec ids X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 08:54:32 -0000 On 26/09/2017 10:49, Moritz Bunkus wrote: > Hey, > >>> I’ve found a few matroska files using the "D_WEBVTT/SUBTITLES” codec >>> id. This isn’t defined in the Codec specs and the “D_” prefix isn’t >>> either. I see this in both webm code and in libavformat. Does the “D_” >>> prefix for codec mappings have any meaning worth defining? Do >>> "D_WEBVTT/SUBTITLES” and "S_TEXT/WEBVTT” have the same meaning? > D_WEBVTT/… are CodecIDs from the WebM mapping for WebVTT[1]. However, back > when I implemented WebVTT for Matroska in March 2016 I noticed that the > WebM mapping was based on an older WebVTT spec and that it did not > represent best Matroska practices. Therefore we decided on a different > mapping in Matroska. See [2] for details. > > So no, we should not define it (our official mapping is S_TEXT/WEBVTT), and > it is definitely not the same. I suggest that we define D_WEBVTT/* in Matroska spec, as "reserved", + "SHOULD NOT use and MAY read it" wording and a link to WebM website, because files are there and WebM is a lot used, we need to avoid conflicts. any luck that WebM moves to Matroska version in the future? From nobody Tue Sep 26 05:21:56 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCDD133091 for ; Tue, 26 Sep 2017 05:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 nRLj18za49Vc for ; Tue, 26 Sep 2017 05:21:53 -0700 (PDT) Received: from mx01.mail.netstorage.at (mx01.mail.netstorage.at [89.207.144.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB431331D9 for ; Tue, 26 Sep 2017 05:21:37 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id 5A5DBA0373 for ; Tue, 26 Sep 2017 14:21:24 +0200 (CEST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 1D16D80B20 for ; Tue, 26 Sep 2017 14:21:24 +0200 (CEST) Received: from [127.0.0.1] (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 Sep 2017 14:21:24 +0200 To: cellar@ietf.org References: <88103a97-524f-e8bb-af77-7a01e084bf13@noa-archive.com> From: Tobias Rapp Organization: NOA GmbH Message-ID: <5f8e7d2b-5a05-bc57-ebe8-31b32d34b927@noa-archive.com> Date: Tue, 26 Sep 2017 14:21:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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: <20170926122124.17602.43534@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: 5A5DBA0373.A7557 X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=-0.5, benoetigt 6, autolearn=not spam, BAYES_00 -0.50) X-NetStorage-MailScanner-From: t.rapp@noa-archive.com Archived-At: Subject: Re: [Cellar] EBML element identifier assignment X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 12:21:55 -0000 On 25.09.2017 17:50, Jerome Martinez wrote: > On 25/09/2017 17:07, Steve Lhomme wrote: >> It might be a good idea to reserve some level 1, 2 and 4 elements for >> future Matroska usage. This way we know they are not used by anyone. >> It might be a little late for that though as we have no idea what's >> out there in the wild. > > Actually classic idea (from other specs) is to reserve some elements for > future **not** Matroska usage a.k.a. explicitly flagged "private use". > All other elements would be forbidden if not in specs. > I suggest not to reserve any level 1 or 2 elements, as they are too rare > for affording to lose them for private use. I agree it should be this direction, not inverse. > Some ideas from other readings: > - we could assign 1 byte of a 4-byte element for private use i.e. > [XX][00][00][00] to [XX][FF][FF][FF] are defined as for private use > depending of the registry, and we decide about [XX] value in specs. Sounds like a good idea. > - we could assign a "registry" element (where? In EBML part after > DocTypeReadVersion? Issue is if one wants to use private elements from 2 > registries), an entity willing to use private elements would have to > write this element ant put its name in it (advising reverse DNS naming > convention?), or we could say that the 2nd and 3rd bytes (2^16 > possibilities :) ) need to be registered to Matroska with name of the > entity planning to use the private elements, before usage, or advising > that they should be chosen trying to be unique (depending of their name?) We should try to keep complexity low. Adding a recommendation like "element [XX][00][00][00] SHOULD contain a registry string in reverse DNS naming style when using elements from the private range" would be enough, in my view. > Main issue I see is that WebM is expanding elements when they want and > we may have to try to find an agreement that such range is reserved if > we want to be able to "backport" their addition to Matroska specs so > WebM stays a subset of Matroska, but this is actually true for all other > new elements too. Don't know how such an agreement is typically handled in IETF specifications: as part of the spec itself, IANA, external, ... Regards, Tobias From nobody Tue Sep 26 10:37:31 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519121342EE for ; Tue, 26 Sep 2017 10:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEme-DbEnfxS for ; Tue, 26 Sep 2017 10:37:11 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30C81330AD for ; Tue, 26 Sep 2017 10:37:10 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id 4so3738427itv.4 for ; Tue, 26 Sep 2017 10:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GZ17Pdy+WQ9cmO8fdk7V7txmAxrupg/xYUrn/ns5d8M=; b=iDuF97TdpqIzVE2YzFwFLYU4a1pQrFGB92y4qXA9Zlx+Lg7W+ZFl166KdvABN8jHN6 ZhGJn4BwrLrs1pOjsdtiJbhXE8+5l3hZlAe5ZwMauQ3k+okwHf92sVwag/jyxKQLKjgk 1CiJvEKrRipaNG7JVn8/+isQnnj6jaQN608L8NhYVOlaMBApdt260xPLBmzEZ2fx3VzE jFa3A6enln9AC7Dg4sNU1oywdJIkpWuZixm/sFLr5W9SPk969CGMMsYZYuOaSpTySwRL m+ieJEneWOPYeSV742d/o8Q8tdt9T2g4VoSPKRdkusEQcb0xuf3XiqXIqf58ou6Gco92 ALBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GZ17Pdy+WQ9cmO8fdk7V7txmAxrupg/xYUrn/ns5d8M=; b=ugIEeiDiV8Urco23rSio8NPSoqqvllHr+5EiXCYkZEHFyYov91lbtBYqr1J8xJ8CsD 2Trn7LObSSOP0HustWf4h0lQ8svV0tYNjhXOz5VLUXNtZ6ausNKsDXqOAKk8WBtEVDyv EVgQ5WhUVcoqxonu34AZ9Bj02bcfA0no1Uagp7pzRzIpJtmthwcZVaZ3aoJlR/Sm+udK d5vb3AEx2FUjI/0zZxiBvf+rb8d0seep3kR162wdg7D0jjCdUGu6AxFG9S02WABTpd1w MyNIQPc/glGfDppCyNxPD0Zz5HxIg1K+3Gvd+X7yRrkswxI9HbXDgwMGArlZ/oM1d/r2 QHcw== X-Gm-Message-State: AHPjjUgeoNKj+PJeLehHvfJMtFQCkF1wkfNqbqn0o9hNIhAHmCxYVlYz 58/issd3WYQg7UxcvWSwlUPtzL5ixSul3Ek0/mbYig== X-Google-Smtp-Source: AOwi7QAYT9nbFEfniUz1StZAy29H8WlTLHVuUXBZ5LGLEjtIfPakAUTu1XlHNted2j8o1M0wDOw5E7xrAmdBYkMc63A= X-Received: by 10.36.250.10 with SMTP id v10mr6857308ith.135.1506447429918; Tue, 26 Sep 2017 10:37:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.170.73 with HTTP; Tue, 26 Sep 2017 10:36:49 -0700 (PDT) In-Reply-To: References: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> <8760c6iqxz.fsf@bunkus.org> <78f095a8-664d-66ed-b44f-867e78e71144@mediaarea.net> From: Michael Bradshaw Date: Tue, 26 Sep 2017 10:36:49 -0700 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="94eb2c034768ef5341055a1b1f95" Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 17:37:30 -0000 --94eb2c034768ef5341055a1b1f95 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm in favor of renaming *Timecode* elements to *Timestamp*, with a footnote added to the spec that mentions their previous historical names. On Tue, Sep 26, 2017 at 12:55 AM, Steve Lhomme wrote= : > Maybe it will be easier to reach a consensus when we have Timecode > tracks. So we can delay this change until timecode tracks are (mostly) > done. > > 2017-09-26 9:42 GMT+02:00 Jerome Martinez : > > On 26/09/2017 09:31, Steve Lhomme wrote: > >> > >> 2017-09-25 20:16 GMT+02:00 Moritz Bunkus : > >> [...] > >> > >>> 4. Strings in the GUIs: UI labels, help texts. > >> > >> It might be the trickiest part. But again, that will need to be done > >> one way or another because timecode tracks are coming. > > > > > > This is my concern too. > > If we keep the name as is in IETF specs, we "sanctuarize" it, and we ma= y > > have issues when we talk about a time code track. > > > >> > >>> 5. mkvinfo's output. mkvinfo uses the term `timecode` a lot in its > >>> user-facing output. As I know there are tons of users out there w= ho > >>> parse mkvinfo's output and who get very upset each time I change > the > >>> format, I've taken to be much more conservative about these > changes. > >> > >> Yes, IMO that shouldn't change. Or if it becomes a problem with > >> timecode tracks, have a legacy mode using the old strings and by > >> default use the new ones (or the other way around). > > > > > > Not so easy, as there may be other tools handling output after using ou= r > > tools (I have the same issue as mkvinfo with MediaTrace output), e.g. > output > > is stored in a database for long term searching, and changing words has > > impact on output previously stored. > > Headache. > > But I think it is better to do it now rather than handling > misunderstandings > > later about timecode being timestamp and timecode being really time cod= e. > > > >> > >>> Therefore I have to agree with Dave and -1 such a change. > >> > >> Rather than voting I'd prefer reaching a consensus. > > > > > > +1 ;-). > > > > More seriously, I don't see something in the middle, looks like a binar= y > > choice :( (we change or we don't). > > If no change, this is also like saying that there will be never a chang= e > in > > words when it is written once. This is a bit hard, I would say that onl= y > > hexadecimal values should be fixed. In that case, I guess we need to pu= t > a > > bit everywhere a "( meaning timestamp)". > > > > Someone with a proposal able to have a consensus? > > > > J=C3=A9r=C3=B4me > > > > > > _______________________________________________ > > 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 > --94eb2c034768ef5341055a1b1f95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm in favor of renaming *Timecode* elements to *Times= tamp*, with a footnote added to the spec that mentions their previous histo= rical names.

On Tue, Sep 26, 2017 at 12:55 AM, Steve Lhomme <slhomme@matroska.org> wrote:
Maybe it will be eas= ier to reach a consensus when we have Timecode
tracks. So we can delay this change until timecode tracks are (mostly)
done.

2017-09-26 9:42 GMT+02:00 Jerome Martinez <jerome@mediaarea.net>:
> On 26/09/2017 09:31, Steve Lhomme wrote:
>>
>> 2017-09-25 20:16 GMT+02:00 Moritz Bunkus <moritz@bunkus.org>:
>> [...]
>>
>>> 4. Strings in the GUIs: UI labels, help texts.
>>
>> It might be the trickiest part. But again, that will need to be do= ne
>> one way or another because timecode tracks are coming.
>
>
> This is my concern too.
> If we keep the name as is in IETF specs, we "sanctuarize" it= , and we may
> have issues when we talk about a time code track.
>
>>
>>> 5. mkvinfo's output. mkvinfo uses the term `timecode` a lo= t in its
>>>=C2=A0 =C2=A0 =C2=A0user-facing output. As I know there are ton= s of users out there who
>>>=C2=A0 =C2=A0 =C2=A0parse mkvinfo's output and who get very= upset each time I change the
>>>=C2=A0 =C2=A0 =C2=A0format, I've taken to be much more cons= ervative about these changes.
>>
>> Yes, IMO that shouldn't change. Or if it becomes a problem wit= h
>> timecode tracks, have a legacy mode using the old strings and by >> default use the new ones (or the other way around).
>
>
> Not so easy, as there may be other tools handling output after using o= ur
> tools (I have the same issue as mkvinfo with MediaTrace output), e.g. = output
> is stored in a database for long term searching, and changing words ha= s
> impact on output previously stored.
> Headache.
> But I think it is better to do it now rather than handling misundersta= ndings
> later about timecode being timestamp and timecode being really time co= de.
>
>>
>>> Therefore I have to agree with Dave and -1 such a change.
>>
>> Rather than voting I'd prefer reaching a consensus.
>
>
> +1 ;-).
>
> More seriously, I don't see something in the middle, looks like a = binary
> choice :( (we change or we don't).
> If no change, this is also like saying that there will be never a chan= ge in
> words when it is written once. This is a bit hard, I would say that on= ly
> hexadecimal values should be fixed. In that case, I guess we need to p= ut a
> bit everywhere a "( meaning timestamp)".
>
> Someone with a proposal able to have a consensus?
>
> J=C3=A9r=C3=B4me
>
>
> _______________________________________________
> 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

--94eb2c034768ef5341055a1b1f95-- From nobody Tue Sep 26 11:06:53 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF221342DB for ; Tue, 26 Sep 2017 11:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 t1Ua7XWZVcvU for ; Tue, 26 Sep 2017 11:06:50 -0700 (PDT) Received: from server172-2.web-hosting.com (server172-2.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236AE1342CE for ; Tue, 26 Sep 2017 11:06:50 -0700 (PDT) Received: from [146.96.19.240] (port=7127 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dwuFq-004FNc-Vs; Tue, 26 Sep 2017 14:06:48 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0DBEC39C-0699-4C24-950A-EF8BFF0A6B2B" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Tue, 26 Sep 2017 14:06:44 -0400 In-Reply-To: Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission To: Michael Bradshaw References: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> <8760c6iqxz.fsf@bunkus.org> <78f095a8-664d-66ed-b44f-867e78e71144@mediaarea.net> X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:06:52 -0000 --Apple-Mail=_0DBEC39C-0699-4C24-950A-EF8BFF0A6B2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If considering renaming the Timecode elements then should we consider = other elements as well. ChapCountry? Language->TrackLanguage. Also I'd suggest considering a version bump with the change, so that the = changes would apply to Matroska version 5+. > On Sep 26, 2017, at 1:36 PM, Michael Bradshaw = wrote: >=20 > I'm in favor of renaming *Timecode* elements to *Timestamp*, with a = footnote added to the spec that mentions their previous historical = names. >=20 > On Tue, Sep 26, 2017 at 12:55 AM, Steve Lhomme > wrote: > Maybe it will be easier to reach a consensus when we have Timecode > tracks. So we can delay this change until timecode tracks are (mostly) > done. >=20 > 2017-09-26 9:42 GMT+02:00 Jerome Martinez >: > > On 26/09/2017 09:31, Steve Lhomme wrote: > >> > >> 2017-09-25 20:16 GMT+02:00 Moritz Bunkus >: > >> [...] > >> > >>> 4. Strings in the GUIs: UI labels, help texts. > >> > >> It might be the trickiest part. But again, that will need to be = done > >> one way or another because timecode tracks are coming. > > > > > > This is my concern too. > > If we keep the name as is in IETF specs, we "sanctuarize" it, and we = may > > have issues when we talk about a time code track. > > > >> > >>> 5. mkvinfo's output. mkvinfo uses the term `timecode` a lot in its > >>> user-facing output. As I know there are tons of users out = there who > >>> parse mkvinfo's output and who get very upset each time I = change the > >>> format, I've taken to be much more conservative about these = changes. > >> > >> Yes, IMO that shouldn't change. Or if it becomes a problem with > >> timecode tracks, have a legacy mode using the old strings and by > >> default use the new ones (or the other way around). > > > > > > Not so easy, as there may be other tools handling output after using = our > > tools (I have the same issue as mkvinfo with MediaTrace output), = e.g. output > > is stored in a database for long term searching, and changing words = has > > impact on output previously stored. > > Headache. > > But I think it is better to do it now rather than handling = misunderstandings > > later about timecode being timestamp and timecode being really time = code. > > > >> > >>> Therefore I have to agree with Dave and -1 such a change. > >> > >> Rather than voting I'd prefer reaching a consensus. > > > > > > +1 ;-). > > > > More seriously, I don't see something in the middle, looks like a = binary > > choice :( (we change or we don't). > > If no change, this is also like saying that there will be never a = change in > > words when it is written once. This is a bit hard, I would say that = only > > hexadecimal values should be fixed. In that case, I guess we need to = put a > > bit everywhere a "( meaning timestamp)". > > > > Someone with a proposal able to have a consensus? > > > > J=C3=A9r=C3=B4me > > > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar = >=20 >=20 >=20 > -- > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_0DBEC39C-0699-4C24-950A-EF8BFF0A6B2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
If considering renaming the Timecode elements = then should we consider other elements as well. ChapCountry? = Language->TrackLanguage.

Also I'd suggest considering a version bump with the change, = so that the changes would apply to Matroska version 5+.

On = Sep 26, 2017, at 1:36 PM, Michael Bradshaw <mjbshaw@google.com> = wrote:

I'm in favor of renaming *Timecode* elements to = *Timestamp*, with a footnote added to the spec that mentions their = previous historical names.

On Tue, Sep 26, 2017 at 12:55 AM, = Steve Lhomme <slhomme@matroska.org> wrote:
Maybe it will be = easier to reach a consensus when we have Timecode
tracks. So we can delay this change until timecode tracks are = (mostly)
done.

2017-09-26 9:42 GMT+02:00 Jerome Martinez <jerome@mediaarea.net>:
> On 26/09/2017 09:31, Steve Lhomme wrote:
>>
>> 2017-09-25 20:16 GMT+02:00 Moritz Bunkus <moritz@bunkus.org>: >> [...]
>>
>>> 4. Strings in the GUIs: UI labels, help texts.
= >>
>> It might be the trickiest part. But again, that will need to be = done
>> one way or another because timecode tracks are coming.
>
>
> This is my concern too.
> If we keep the name as is in IETF specs, we "sanctuarize" it, and = we may
> have issues when we talk about a time code track.
>
>>
>>> 5. mkvinfo's output. mkvinfo uses the term `timecode` a lot = in its
>>>     user-facing output. As I know there are = tons of users out there who
>>>     parse mkvinfo's output and who get very = upset each time I change the
>>>     format, I've taken to be much more = conservative about these changes.
>>
>> Yes, IMO that shouldn't change. Or if it becomes a problem = with
>> timecode tracks, have a legacy mode using the old strings and = by
>> default use the new ones (or the other way around).
>
>
> Not so easy, as there may be other tools handling output after = using our
> tools (I have the same issue as mkvinfo with MediaTrace output), = e.g. output
> is stored in a database for long term searching, and changing words = has
> impact on output previously stored.
> Headache.
> But I think it is better to do it now rather than handling = misunderstandings
> later about timecode being timestamp and timecode being really time = code.
>
>>
>>> Therefore I have to agree with Dave and -1 such a = change.
>>
>> Rather than voting I'd prefer reaching a consensus.
>
>
> +1 ;-).
>
> More seriously, I don't see something in the middle, looks like a = binary
> choice :( (we change or we don't).
> If no change, this is also like saying that there will be never a = change in
> words when it is written once. This is a bit hard, I would say that = only
> hexadecimal values should be fixed. In that case, I guess we need = to put a
> bit everywhere a "( meaning timestamp)".
>
> Someone with a proposal able to have a consensus?
>
> J=C3=A9r=C3=B4me
>
>
> _______________________________________________
> 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

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

= --Apple-Mail=_0DBEC39C-0699-4C24-950A-EF8BFF0A6B2B-- From nobody Tue Sep 26 11:26:45 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF833134305 for ; Tue, 26 Sep 2017 11:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QZLTqod84f5 for ; Tue, 26 Sep 2017 11:26:35 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243551342DD for ; Tue, 26 Sep 2017 11:26:35 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id p10so7711971ywh.8 for ; Tue, 26 Sep 2017 11:26:35 -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; bh=+iyJpFzMOz1qhfxKP6zcG5RalLuqQABMxZzPmi96YIE=; b=Fq/UO7UNaK5gE9B3M8WaSjON82xY4j8kCienHi/TkPogZrV5w0/dqMaFBxc9OFbq30 AhEFErfW5jIt4MSi9GeAcf6BQzUGpjlsSTZaPXWfCjC4jzXL0/DUvsxkmTjw6h4ahYzS VwzX5LIFY04dLb6f3MNgJLNrMZq+K0G+msV5JAKwcG8seaFZtyFQeIJRbYH8RYFW0+2i 3CO2Nu9Z2lM+8rkeAsIJcZ2aT0JhaMaFm8TvcqvUwQhhWsbhSeh2gWAn98Q0Aw0WvgIq V70MWxx1mYUHFVFdEYja4Zd3cXcdsJZ9EN/ciBZqIszZI37rgyuiFPJanVrvcBQ6nwKF fcag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+iyJpFzMOz1qhfxKP6zcG5RalLuqQABMxZzPmi96YIE=; b=IrKfTOgobuE4z37hw5krTUVuk5c/FqM/Vqmy0Rw86WnmKkkCUEECVm4WFdFWOrCghC +cdfqh6XO52wVcQUidpngn2NYSdFMq9dhXSH9urH0j3kK74659evJsbeadwTKPzjawin GhNPXGc93rIoZPg+XiAeV7HsAgUM7nd1lTU3anf80tRCsRj7KwDZ70Fidxro9YweFhgV hR0eERE/FehT3vb6OWikhV4RL4uY+louU13dZMJpM5ZV2fFugjMCPRDBYqFIvyFqcwdx I1wUcQNRDYu21u2H+eBhlUrBT1U6S8GvQ+TZndk3Id+GAvwfcoIZ8onnZ3RG9yO8ABcA Wz+Q== X-Gm-Message-State: AHPjjUhYZHbB7s/T2HDT52hID/f98yv3HIBgXHS3X5SiSxKFjcV2Ctbd FCFZqAdv35IBqyUpUcZLVPXgT26GS3QSStDsVtLy6A== X-Google-Smtp-Source: AOwi7QDPz2IZ3CP/eOj/acVzSNHHIuqv/WoA0e3sU+M7BpQM+kEuvZilsGgTSv+inKaJP2zLt0q7On0gahgWqUlCcR4= X-Received: by 10.13.216.80 with SMTP id a77mr6766045ywe.83.1506450394414; Tue, 26 Sep 2017 11:26:34 -0700 (PDT) MIME-Version: 1.0 References: <3E0D1D5D-6288-446F-AC3B-FC903DC6E04F@dericed.com> <8760c6iqxz.fsf@bunkus.org> <78f095a8-664d-66ed-b44f-867e78e71144@mediaarea.net> In-Reply-To: From: Steve Lhomme Date: Tue, 26 Sep 2017 18:26:23 +0000 Message-ID: To: Dave Rice , Michael Bradshaw Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a114e462aa193d5055a1bd0b5" Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:26:44 -0000 --001a114e462aa193d5055a1bd0b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IMO we can change the mnemonics. The produced data are strictly the same. They are not tied to the names. If anyone started an independent specification for Matroska they could also use their own set of names. As long as the format is interpreted the same. Ashley might not agree to get rid of ChapCountry. On Tue 26 Sep 2017 at 20:06, Dave Rice wrote: > If considering renaming the Timecode elements then should we consider > other elements as well. ChapCountry? Language->TrackLanguage. > > Also I'd suggest considering a version bump with the change, so that the > changes would apply to Matroska version 5+. > > On Sep 26, 2017, at 1:36 PM, Michael Bradshaw wrote: > > I'm in favor of renaming *Timecode* elements to *Timestamp*, with a > footnote added to the spec that mentions their previous historical names. > > On Tue, Sep 26, 2017 at 12:55 AM, Steve Lhomme > wrote: > >> Maybe it will be easier to reach a consensus when we have Timecode >> tracks. So we can delay this change until timecode tracks are (mostly) >> done. >> >> 2017-09-26 9:42 GMT+02:00 Jerome Martinez : >> > On 26/09/2017 09:31, Steve Lhomme wrote: >> >> >> >> 2017-09-25 20:16 GMT+02:00 Moritz Bunkus : >> >> [...] >> >> >> >>> 4. Strings in the GUIs: UI labels, help texts. >> >> >> >> It might be the trickiest part. But again, that will need to be done >> >> one way or another because timecode tracks are coming. >> > >> > >> > This is my concern too. >> > If we keep the name as is in IETF specs, we "sanctuarize" it, and we m= ay >> > have issues when we talk about a time code track. >> > >> >> >> >>> 5. mkvinfo's output. mkvinfo uses the term `timecode` a lot in its >> >>> user-facing output. As I know there are tons of users out there >> who >> >>> parse mkvinfo's output and who get very upset each time I change >> the >> >>> format, I've taken to be much more conservative about these >> changes. >> >> >> >> Yes, IMO that shouldn't change. Or if it becomes a problem with >> >> timecode tracks, have a legacy mode using the old strings and by >> >> default use the new ones (or the other way around). >> > >> > >> > Not so easy, as there may be other tools handling output after using o= ur >> > tools (I have the same issue as mkvinfo with MediaTrace output), e.g. >> output >> > is stored in a database for long term searching, and changing words ha= s >> > impact on output previously stored. >> > Headache. >> > But I think it is better to do it now rather than handling >> misunderstandings >> > later about timecode being timestamp and timecode being really time >> code. >> > >> >> >> >>> Therefore I have to agree with Dave and -1 such a change. >> >> >> >> Rather than voting I'd prefer reaching a consensus. >> > >> > >> > +1 ;-). >> > >> > More seriously, I don't see something in the middle, looks like a bina= ry >> > choice :( (we change or we don't). >> > If no change, this is also like saying that there will be never a >> change in >> > words when it is written once. This is a bit hard, I would say that on= ly >> > hexadecimal values should be fixed. In that case, I guess we need to >> put a >> > bit everywhere a "( meaning timestamp)". >> > >> > Someone with a proposal able to have a consensus? >> > >> > J=C3=A9r=C3=B4me >> > >> > >> > _______________________________________________ >> > 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 >> > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > > --001a114e462aa193d5055a1bd0b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IMO we can change the mnemonics. The produced data are strictly the same. T= hey are not tied to the names.
If anyone started an independent specific= ation for Matroska they could also use their own set of names. As long as t= he format is interpreted the same.

Ashley might not agree to get rid= of ChapCountry.
On Tue 26 S= ep 2017 at 20:06, Dave Rice <dave@de= riced.com> wrote:
If considering renaming the Timecode eleme= nts then should we consider other elements as well. ChapCountry? Language-&= gt;TrackLanguage.

Also I'd suggest considering= a version bump with the change, so that the changes would apply to Matrosk= a version 5+.

On Sep 26, 2017, at 1:36 PM, Michael Bradshaw <= ;mjbshaw@google.com= > wrote:

I'm in favor of renaming *Timecode* elemen= ts to *Timestamp*, with a footnote added to the spec that mentions their pr= evious historical names.

On Tue, Sep 26, 2017 at 12:55 AM, Steve Lhomme <slhomme@ma= troska.org> wrote:
Maybe it= will be easier to reach a consensus when we have Timecode
tracks. So we can delay this change until timecode tracks are (mostly)
done.

2017-09-26 9:42 GMT+02:00 Jerome Martinez <jerome@mediaarea.net>:
> On 26/09/2017 09:31, Steve Lhomme wrote:
>>
>> 2017-09-25 20:16 GMT+02:00 Moritz Bunkus <moritz@bunkus.org>:
>> [...]
>>
>>> 4. Strings in the GUIs: UI labels, help texts.
>>
>> It might be the trickiest part. But again, that will need to be do= ne
>> one way or another because timecode tracks are coming.
>
>
> This is my concern too.
> If we keep the name as is in IETF specs, we "sanctuarize" it= , and we may
> have issues when we talk about a time code track.
>
>>
>>> 5. mkvinfo's output. mkvinfo uses the term `timecode` a lo= t in its
>>>=C2=A0 =C2=A0 =C2=A0user-facing output. As I know there are ton= s of users out there who
>>>=C2=A0 =C2=A0 =C2=A0parse mkvinfo's output and who get very= upset each time I change the
>>>=C2=A0 =C2=A0 =C2=A0format, I've taken to be much more cons= ervative about these changes.
>>
>> Yes, IMO that shouldn't change. Or if it becomes a problem wit= h
>> timecode tracks, have a legacy mode using the old strings and by >> default use the new ones (or the other way around).
>
>
> Not so easy, as there may be other tools handling output after using o= ur
> tools (I have the same issue as mkvinfo with MediaTrace output), e.g. = output
> is stored in a database for long term searching, and changing words ha= s
> impact on output previously stored.
> Headache.
> But I think it is better to do it now rather than handling misundersta= ndings
> later about timecode being timestamp and timecode being really time co= de.
>
>>
>>> Therefore I have to agree with Dave and -1 such a change.
>>
>> Rather than voting I'd prefer reaching a consensus.
>
>
> +1 ;-).
>
> More seriously, I don't see something in the middle, looks like a = binary
> choice :( (we change or we don't).
> If no change, this is also like saying that there will be never a chan= ge in
> words when it is written once. This is a bit hard, I would say that on= ly
> hexadecimal values should be fixed. In that case, I guess we need to p= ut a
> bit everywhere a "( meaning timestamp)".
>
> Someone with a proposal able to have a consensus?
>
> J=C3=A9r=C3=B4me
>
>
> _______________________________________________
> 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

_______________________________________________
Cellar mailing list
<= a href=3D"mailto:Cellar@ietf.org" target=3D"_blank">Cellar@ietf.org
= = https://www.ietf.org/mailman/listinfo/cellar

--001a114e462aa193d5055a1bd0b5-- From nobody Tue Sep 26 11:40:13 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739CF13305E for ; Tue, 26 Sep 2017 11:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 ksq37vf2zmEf for ; Tue, 26 Sep 2017 11:40:10 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795371323F7 for ; Tue, 26 Sep 2017 11:40:10 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8QIe8Es001899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 26 Sep 2017 20:40:08 +0200 Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v8QIe7H1022835 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 26 Sep 2017 20:40:08 +0200 Date: Tue, 26 Sep 2017 20:40:09 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Rename Timecode* elements to Timestamp* X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 18:40:12 -0000 Dave Rice wrote: >Also I'd suggest considering a version bump with the change, so >that the changes would apply to Matroska version 5+. Will the stream change? If so, I am in favour of a version bump, otherwise I don't see the necessity. I have the impression latter is the case, but I might be wrong. Best regards, Reto