From nobody Wed Feb 1 07:24: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 A26BB129E55 for ; Wed, 1 Feb 2017 07:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.756 X-Spam-Level: X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, 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 6d8iiLbWqGiK for ; Wed, 1 Feb 2017 07:24:22 -0800 (PST) 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 1BD0312947A for ; Wed, 1 Feb 2017 07:24:21 -0800 (PST) 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 v11FOJ2G002308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 1 Feb 2017 16:24:19 +0100 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 v11FOI0X031693 for ; Wed, 1 Feb 2017 16:24:19 +0100 Date: Wed, 1 Feb 2017 16:24:19 +0100 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: [Cellar] The Reel Thing X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 15:24:24 -0000 Is someone of the CELLAR gang presenting something at "The Reel Thing XL" symposium on 28-30 May in Amsterdam (apart the hands-on session submitted by Erwin Verbruggen)? http://the-reel-thing.org Best regards, Reto AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: https://reto.ch | Twitter: @retoch From nobody Wed Feb 1 14:57: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 5008F1295EB for ; Wed, 1 Feb 2017 14:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 QBuvgWsXpogy for ; Wed, 1 Feb 2017 14:57:55 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F752129577 for ; Wed, 1 Feb 2017 14:57:55 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:41664 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cZ3qb-000Dtb-Js; Wed, 01 Feb 2017 17:57:54 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_063ED5E6-3D17-4853-B7AE-0484036B8EAA" Date: Wed, 1 Feb 2017 17:57:49 -0500 Message-Id: <1888ECBC-8420-406C-B259-EB31B08D0952@dericed.com> To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) 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: Cc: Nick.Drouin@live.com Subject: [Cellar] adding VP8 and VP9 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 22:57:56 -0000 --Apple-Mail=_063ED5E6-3D17-4853-B7AE-0484036B8EAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi cellar, Just before the cellar wg became active there was a proposal = on matroska-devel to document use of VP8 and VP9 in Matroska, = similar to how they have been defined in webm. I started a pull request = at https://github.com/Matroska-Org/matroska-specification/pull/91 to add = them. The original thread also proposes adding WEBVTT but it seems there=E2=80=99= s some open questions there about how to do so. Dave Rice --Apple-Mail=_063ED5E6-3D17-4853-B7AE-0484036B8EAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi cellar,

Just before the cellar wg became active there was a proposal on matroska-devel to document = use of VP8 and VP9 in Matroska, similar to how they have been defined in = webm. I started a pull request at https://github.com/Matroska-Org/matroska-specification/pull/91<= /a> to add them.

The original thread also proposes adding WEBVTT but it seems = there=E2=80=99s some open questions there about how to do so.

Dave Rice

= --Apple-Mail=_063ED5E6-3D17-4853-B7AE-0484036B8EAA-- From nobody Wed Feb 1 16:01:09 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B359B1295F8 for ; Wed, 1 Feb 2017 16:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wj_mzXRAcTFt for ; Wed, 1 Feb 2017 16:01:06 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5077C12959A for ; Wed, 1 Feb 2017 16:01:06 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:37602 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cZ4pk-001J2y-M7 for cellar@ietf.org; Wed, 01 Feb 2017 19:01:05 -0500 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8A89A5B6-BBDE-40F4-92C9-68FCF2881B21@dericed.com> Date: Wed, 1 Feb 2017 19:01:02 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] enumeration lists for EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 00:01:08 -0000 Hi cellar, These pull requests relate to an issue Steve opened at = https://github.com/Matroska-Org/ebml-specification/issues/114 for = defining an enumeration list for EBML Elements. This pull request includes an update to the EBMLSchema.xsd to allow = elements along with documentation in the EBML spec, = https://github.com/Matroska-Org/ebml-specification/pull/130. And this = updates the EBML Schema for Matroska accordingly: = https://github.com/Matroska-Org/matroska-specification/pull/92. This is = inspired by the restriction element of XML Schemas = (http://www.w3schools.com/xml/schema_facets.asp). So: A set of track types coded on 8 bits (1: = video, 2: audio, 3: complex, 0x10: logo, 0x11: subtitle, 0x12: buttons, = 0x20: control). becomes: A set of track types coded on 8 = bits. This impacts the definition of the following Elements: ChapterTranslateCodec TrackType TrackTranslateCodec FlagInterlaced FieldOrder StereoMode OldStereoMode DisplayUnit AspectRatioType MatrixCoefficients ChromaSitingHorz ChromaSitingVert Range TransferCharacteristics Primaries ProjectionType TrackPlaneType ChapProcessTime Comments welcome, Dave= From nobody Thu Feb 2 01:03: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 4BA041293EB for ; Thu, 2 Feb 2017 01:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 8GqI796YDUr7 for ; Thu, 2 Feb 2017 01:03:22 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 C5C98127077 for ; Thu, 2 Feb 2017 01:03:21 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id v77so2712039wmv.0 for ; Thu, 02 Feb 2017 01:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=sAzfSXJGxnxnjXvXl0zgsfaBno4u/xHXTVWh6tJBhzk=; b=ure1GbmYCbX1GsOKB//usFqqUzFQ0RVLoUAMTmxY1vR0Hfki2lbMBvrLlvbpDsOITu XsokVKiw66xw15Lbrx2/pQXzEt/qS4kAb7p7uTthE6LmoTkFTPzepvzNu3zViwc1O/c9 BSuFpkng5lByPz12wf/FNeQKMsoTV7644Kyl1xZasgpDJp9M6pm7CfeFtOPvLllfqKJH hRAqaqvIpHusFqjcKzjKtM0WQeWfbbVK15ILjv4JXPbmPGz7XCLyxE4b+i5u7ZxgAhQ5 TMP5OR2DuxGQqf+71Le0Re25EjVninO9MZa1apu4Ak7kTiVbsLlQTb00QKz0COnRIIJ/ hWrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=sAzfSXJGxnxnjXvXl0zgsfaBno4u/xHXTVWh6tJBhzk=; b=JlgCgVS13dJjK9QRv42Ih3/XXC/BceA9+d4mIIBBo1JN0RYt8LOzZ8oqhvwOhUB0ZU tkYw+bANlc9q2fw85ozxv4FhM8XiksPy7YPVdPRZ88JkqHTHh8oqBwoDrLX4SDda4f8H 9iTYRNVoekO7b4OylIe4Ue2r1lV8IrAT6XL/VnTbcwM9QmFdxyNWKGWRo+yw/3zLueUM 09/2mKCBJFS5JHLbsYjmTfDbp1Ra4poT8WPmUT2JzTXbi3JiFpNxxY1lRJH7oBjBKsHk 12MaOoP24bX+F1EHFIZ1/PUiQproPq/KcTG5YTiTf9+eEyrkD5t/uKMLuWWgPQqJo0VU AGMA== X-Gm-Message-State: AIkVDXJ5E0cYy9hHMwxmhLtgJ4nsPb1hz/IzaqJxBjwRB3lqVkJ+/Tl1vdp1QgWACzhJrw== X-Received: by 10.28.136.68 with SMTP id k65mr28614844wmd.48.1486026197035; Thu, 02 Feb 2017 01:03:17 -0800 (PST) Received: from debian (p4FF02F5F.dip0.t-ipconnect.de. [79.240.47.95]) by smtp.googlemail.com with ESMTPSA id m188sm32798309wma.0.2017.02.02.01.03.16 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 02 Feb 2017 01:03:16 -0800 (PST) Date: Thu, 2 Feb 2017 10:03:19 +0100 From: wm4 To: cellar@ietf.org Message-ID: <20170202100319.27f573dd@debian> In-Reply-To: <58525F89.5000600@das-werkstatt.com> References: <58525F89.5000600@das-werkstatt.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 02 Feb 2017 09:03:23 -0000 On Thu, 15 Dec 2016 10:16:57 +0100 "Peter B." wrote: > ======================= > container or codec - or both? > ======================= > > > All 3 versions have their pros and cons, but I think having it in both > causes more trouble than does good (see below). Using the codec has another advantage: parameters can change at runtime. I have seen Matroska files which have both codec and container aspect ratio set, and for which the codec aspect ratio changed at runtime. There are barely two pieces of software which handle this the same way. On the other hand, no matter what you do, getting multiple implementations to handle codec/container mismatch the same way has a high chance of failure, because they could support the codec and container hints to a different degree. I think ideally, container hints should either not be defined, or if they are, reflect the codec hints exactly. If Matroska can contain midstream parameter changes, this would require Matroska to have a mechanism for reflecting them in the container metadata. From nobody Sat Feb 4 05:14:39 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FDD129575 for ; Sat, 4 Feb 2017 05:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 OqZmgs_FNmfF for ; Sat, 4 Feb 2017 05:14:37 -0800 (PST) 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 7DB601295EF for ; Sat, 4 Feb 2017 05:14:37 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id w75so27312163ywg.1 for ; Sat, 04 Feb 2017 05:14:37 -0800 (PST) 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=1sK/D8ZacLBuu4ijbUgiU8bhjjGYU5lb5YQyb8vji5Y=; b=iDala2k+8PnIK2pqOyBgmXwXnXIobCtz4uHecWJlj6SwZGDDKxiDrAlxnL8PtpAgav SWmlBcv3ujGVJ4Cjdooycu5fthzVT5vQRVBHER0MtfCoVYN9Y4h46iLTaudnHPacI9EN tzDoU16Rd0KcOI5sD0mW5Lm6RQYRUaAF8wH6T8phS0DXDOiP+ed0L48Br8/uhlY0x+PA X0IU0vKiKy1K7AgdgykPaLe8oGhqYmjmCeXflalgHx3tAgLCbwTFBGHAUYSLXyg3okRj Lv1qZjCnFmjnvzedYi41wuKr48BaOAejvBRUUu4IAjVnwz9dR0Yfv7htEmY4cLvPC+5Y 0MlA== 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=1sK/D8ZacLBuu4ijbUgiU8bhjjGYU5lb5YQyb8vji5Y=; b=VihSX0muE/w35dYRt7bboF3MHhD4VyzKLS7nVm0iIJAk6lEqH5lxhJNx+Lbs8km2Ey bBQwfV79aUqN6Pa7kzIFyRlJhe8lC5EUWnNvnZqecpruYKsLUVnOL+FmBFTZIlI1T/Li X1zqFe9QxwlT6Txeqv7EGnD3TwHGREK0DgazhfP3a/u9y+ICzUofUl4Hm6Lm4MBRlcQi VEK6XJM64lANDA/Tqobh6Ca+t3FMAwoBqxfHAFABo0GTIZPZS00+xO9j9+fC6XLJVL2F MqQk5KGXVAHUnCCLxkK4BlNmidaVwA5uMoYRO8AnLxZ5cpG3od2pBZUcZ7iCl+d/F4vN fLSw== X-Gm-Message-State: AMke39noRK2Z1XTDMSGMBwOUJfRuib4URHgQZyVPGi5Fw5U1vX7pSfaTVzYxh2toZEl6P/7ZhcLLKfmJDFeowg== X-Received: by 10.13.196.129 with SMTP id g123mr1153186ywd.17.1486214076681; Sat, 04 Feb 2017 05:14:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 05:14:36 -0800 (PST) In-Reply-To: <1888ECBC-8420-406C-B259-EB31B08D0952@dericed.com> References: <1888ECBC-8420-406C-B259-EB31B08D0952@dericed.com> From: Steve Lhomme Date: Sat, 4 Feb 2017 14:14:36 +0100 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Nick.Drouin@live.com, Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] adding VP8 and VP9 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 13:14:39 -0000 They definitely need to go in. The VP9 link should be changed to something more stable and revent. Otherwise LGTM. 2017-02-01 23:57 GMT+01:00 Dave Rice : > Hi cellar, > > Just before the cellar wg became active there was a proposal on > matroska-devel to document use of VP8 and VP9 in Matroska, similar to how > they have been defined in webm. I started a pull request at > https://github.com/Matroska-Org/matroska-specification/pull/91 to add the= m. > > The original thread also proposes adding WEBVTT but it seems there=E2=80= =99s some > open questions there about how to do so. > > Dave Rice > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Sat Feb 4 05:16:40 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 6D0FD1295EF for ; Sat, 4 Feb 2017 05:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 b0mSA_RMjdSl for ; Sat, 4 Feb 2017 05:16:37 -0800 (PST) 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 47702129575 for ; Sat, 4 Feb 2017 05:16:37 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id u68so27382105ywg.0 for ; Sat, 04 Feb 2017 05:16:37 -0800 (PST) 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=6ybu1ougrpSIUJdbbVVV69pwuwgJNPessFgoxSBeGXs=; b=gZEUjTU5OP5pCnQ7g8Xm+2sGVAXVfcWcqjVU3XaoxcGHHEk0XJocCSQfE+tZcYmUeF qzUp5Qey7mV6ZgsuM2Km9t8vsRWA/4RfZVeY+huP0x0bp6AF9Si7kHpsf/5L6LJEvym8 +xGbf3n8DCQaBiQb0677MgzSVTngOYjD6pz2hyX0k/v2BEd4kPOya4/M+NtM3+9ZC95V B0RSVMWPthEDJOARIY5yPSEIkSGs/yMalH3H4kHizj+W2DMRWUY4cO2pbb9HdqNUOgsY glEoSE5Uce0+x8t97UEyJYrUwWxGGLzP4ytpXis8yCCxiHaV3kyYo684XROp32emgPoa DJRg== 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=6ybu1ougrpSIUJdbbVVV69pwuwgJNPessFgoxSBeGXs=; b=K4ophfTijgNIMWNDktJVP/jJbvQtfqk3rAAitGRqjG//PpmMVdpOurqMfOJEJaRa0u +GjeaLdyrE350/jyMYyOEIjGmvbFGnqi/7Da7yjYeuWVRDNIiDQtxIxuajVoizJc86FM AALl3l1fg2R9+OBGGowBXv+AFGSlA3G8Sx0tB2/hHhL+0HHSAaJczjqU+Xey9+Z/ECuI 4sbiDqMHbRsZx4PvAiVoDyykMapAvGJ92gDyH04KQn7fbnnE4lLj4KDiSrNR2IQz5xM4 o04yhihbm9YgJkQmIvYU2EFi0qedcgyeXgA3Ay+nMAEXpazvd4++qRaSLo4fl0Tc7S3I VPgg== X-Gm-Message-State: AIkVDXLo2me97+7jVjmtWK6i1qqvWGIOLKKbPwgmiLHBexc2QnmOmEFMPCrScuVShXGEDm9e7eQciFnU7S/ayA== X-Received: by 10.13.198.2 with SMTP id i2mr1135875ywd.201.1486214196468; Sat, 04 Feb 2017 05:16:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 05:16:36 -0800 (PST) In-Reply-To: References: From: Steve Lhomme Date: Sat, 4 Feb 2017 14:16:36 +0100 Message-ID: To: Reto Kromer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] The Reel Thing X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 13:16:38 -0000 Not AFAIK but that's tempting. 2017-02-01 16:24 GMT+01:00 Reto Kromer : > Is someone of the CELLAR gang presenting something at "The > Reel Thing XL" symposium on 28-30 May in Amsterdam (apart > the hands-on session submitted by Erwin Verbruggen)? > > http://the-reel-thing.org > > Best regards, Reto > > > AV Preservation by reto.ch > chemin du Suchet 5 | 1024 Ecublens | Switzerland > Web: https://reto.ch | Twitter: @retoch > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sat Feb 4 05:23:15 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E31129645 for ; Sat, 4 Feb 2017 05:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 B5ybhUJCf-wG for ; Sat, 4 Feb 2017 05:23:13 -0800 (PST) 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 A6028129629 for ; Sat, 4 Feb 2017 05:23:13 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id v200so27281970ywc.3 for ; Sat, 04 Feb 2017 05:23:13 -0800 (PST) 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=deW8mGyK3c8CkvIhGqmRALs/5Igs1kyVtFhhsBE6hUc=; b=jfyZ379T9EAWAq1pPaBIOutVSogJwx16fhxWjwl04BHuJKIKIrEHxWN9BRYye+EsYY uVpiaq6qa3PIf0Ime4r8y2kZMqRoz5QWh3i3gOxegICmMipmrnsvVDVbABZo11fHs/LB QUgcLWQWI2buF52LbQSbUs83f/9qJZfxdpCVEx2nShCDaTFMGYNTOwY9YSc0VWjH3iTh dJ7q0wd7UxCaZ64gwIRRUs5Y0ZPRK/S9ONn6Mgy9LyJTImBpW/0EKydV+dUv9N/1EjSn aKByIrqhkhG9H9KSzxJkfWJPSRE5lFRmBu/S2YI4qMWrQB6mNynevdWK/cqTVyjNN1a5 z2PA== 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=deW8mGyK3c8CkvIhGqmRALs/5Igs1kyVtFhhsBE6hUc=; b=I17CtQSi1htCryDUREiigF0IGbdlVbQPHvlQqEUxwlF7xk1DkGfJjkTGqwJ7a7Oxz7 KWAc+t9f/z7OYZtGTEx/znIOcFxCrlsk/56IRBO8wL7fu1G+ThsEa2tZCGPcdEXgIKN0 mEGBsQ4dtG6QIoj8fFoFKvTGZ6pftMMpnZZ3dXm2kuvm/g/NEGwN8/NvnVCgZGOYQh0i bEadclFFIZRd/wklGuXi3R+kKF0IFDOVNKhjt9/oVBhdjgd8SrJxZsNIT1svp0dQMfcN JMNYcGrMulF9MGhf48pWyb26OUdcoRFho0LByiXQv6M/JQrbjrqQwWinLKq3wgEK8aZw vJ3Q== X-Gm-Message-State: AIkVDXKhg4kqn9CwIVhQNSPW7BdDPaBRuSCY34+habWFnSd6mgHPCx/9GoodkmW8bYvFXY7yGZW2HU6A9XlpkQ== X-Received: by 10.13.241.199 with SMTP id a190mr1217360ywf.311.1486214592927; Sat, 04 Feb 2017 05:23:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 05:23:12 -0800 (PST) In-Reply-To: <8A89A5B6-BBDE-40F4-92C9-68FCF2881B21@dericed.com> References: <8A89A5B6-BBDE-40F4-92C9-68FCF2881B21@dericed.com> From: Steve Lhomme Date: Sat, 4 Feb 2017 14:23:12 +0100 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] enumeration lists for EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 13:23:15 -0000 Both LGTM. Reto pointed a possible typo but other than that it's fine. 2017-02-02 1:01 GMT+01:00 Dave Rice : > Hi cellar, > > These pull requests relate to an issue Steve opened at https://github.com= /Matroska-Org/ebml-specification/issues/114 for defining an enumeration lis= t for EBML Elements. > > This pull request includes an update to the EBMLSchema.xsd to allow elements along with documentation in the EBML spec, https://github.com/Ma= troska-Org/ebml-specification/pull/130. And this updates the EBML Schema fo= r Matroska accordingly: https://github.com/Matroska-Org/matroska-specificat= ion/pull/92. This is inspired by the restriction element of XML Schemas (ht= tp://www.w3schools.com/xml/schema_facets.asp). > > So: > > > A set of track types coded on 8 bits (1: vid= eo, 2: audio, 3: complex, 0x10: logo, 0x11: subtitle, 0x12: buttons, 0x20: = control). > > > becomes: > > > A set of track types coded on 8 bits. > > > > > > > > > > > > This impacts the definition of the following Elements: > > ChapterTranslateCodec > TrackType > TrackTranslateCodec > FlagInterlaced > FieldOrder > StereoMode > OldStereoMode > DisplayUnit > AspectRatioType > MatrixCoefficients > ChromaSitingHorz > ChromaSitingVert > Range > TransferCharacteristics > Primaries > ProjectionType > TrackPlaneType > ChapProcessTime > > Comments welcome, > Dave > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sat Feb 4 05:48:09 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7642129AA7 for ; Sat, 4 Feb 2017 05:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 fCEeaX_mTK-v for ; Sat, 4 Feb 2017 05:48:07 -0800 (PST) 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 B5B79129AA5 for ; Sat, 4 Feb 2017 05:48:07 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id l19so27512885ywc.2 for ; Sat, 04 Feb 2017 05:48:07 -0800 (PST) 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=q7f5Molh6Bv1jbJWkR0UtTiuSQGQtQxPPLgyvRJC6w8=; b=k3CJ7UF54G7v9Ymu6AoXguKxCUYX77LFOCb/Ff5/oG+qgAKksi9P2WoC1oHGN3NZz+ OA3tg5z9AE4dqTeNph4T4k7JjIXRrGN9LC/SZyoD7JHkqObHVWbRAKnbm0P2YRkQfHhQ TFWd9gLkk71mmzcVfFX9LIuELbEZGzvmL5ETsRQQMxfF/wlUAe8XyYRPI9Nq00iSKjck aqRJttc0/D7MvVrTe7hP4e0WOkqa4lPawVzkiP1MQDaItY68DPckO/ricUyIuTVzzwra kcMaBYgoEkWs8aU5bHqqwBhqJ2f3qIkPWA540ExS6mVsP1g2vZadBvukVd1ekCiejevN IGQQ== 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=q7f5Molh6Bv1jbJWkR0UtTiuSQGQtQxPPLgyvRJC6w8=; b=It7gpclUe0+s13SjezVIFPXc7MkIxp5qhSjEhOslB1XBf2tx+dka3C+Hsd9y2srlGw OIr/IEpJ5qO7QxzD//hdlSnEJ7M1bE1PVAGtXmv8uJxOawHtRMhgeyNgDI6LqjVlkkSN nCtKSe/1xeWgwXcJwzWVxVUj1YqyGWm7lpRVUK4y2ACmnvvLloKFqckifIxUgo+axP4y v7xCCXIMkJfuy4XuG0dBEtZddM+hlVICUd3v3d7EWTG6/oM3VyVsmXULasKtQ57Az8tQ cwZ+823kLePCfund4IhKgGHS14IuPx65Uc2vDBcuaQR8NqWKo8qIhBwz6irg1cGA4rLT bk5g== X-Gm-Message-State: AIkVDXJuo6qQ2LxbxcdFVWelA+Ujn3oSGLXmQUJD/x+bbLJKNIT2fchuziYmudrrKK/Uz3gQGt6tDa0W4Hdzxg== X-Received: by 10.13.241.199 with SMTP id a190mr1273317ywf.311.1486216086827; Sat, 04 Feb 2017 05:48:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 05:48:06 -0800 (PST) In-Reply-To: <8E74E6A0-83BB-46DD-A5D2-F732C7ABDA6A@dericed.com> References: <8E74E6A0-83BB-46DD-A5D2-F732C7ABDA6A@dericed.com> From: Steve Lhomme Date: Sat, 4 Feb 2017 14:48:06 +0100 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] re-formatting the Matroska Codec Mappings X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 13:48:09 -0000 2017-01-24 4:22 GMT+01:00 Dave Rice : > Hi all, > > The documentation on how to document a Codec Mapping in Matroska has been > integrated into the GitHub repo. Now here's a attempt to update the Codec > Mapping page to use the new form: > https://github.com/Matroska-Org/matroska-specification/pull/88. Some note= s > about the update: > > There are many informal questions left within the codec_specs document, > usually listed with a =E2=80=9C???=E2=80=9D. Steve, Moritz, are these not= es to self? Can we > resolve or remove them? For example V_MS/VFW/FOURCC contains "Where is th= e > Huffman table stored in HuffYUV, not AVISTREAMINFO ??? And the FourCC, no= t > in AVISTREAMINFO.fccHandler ???=E2=80=9D Also the definition for A_AC3 se= ems to > question if there is any Private Data for that encoding "The private data= is > void ???=E2=80=9D. Yes, that should be removed. The A_AC3 description could get some love. The ACM part can be dropped but it leaves pretty much nothing. Since it must be a standardized format we should link to that in one form or another. I think it's better to accept this pull request and not delay separate issues about the content. > In some cases the original list of codec mappings was nested, I flattened= it > which increases clarify but also increases redundancy. > > The description for V_MPEG1, V_MPEG2, A_MPC, and S_TEXT/USF seem to imply > that they are not yet defined, though their definitions are in early stat= es. > > The pull request updates the form of the Codec Mappings, but isn=E2=80=99= t intended > to update or clarify all of the language (there=E2=80=99s still a lot to = do there). > > And some questions: > > Should we define a structure to detail Private Data? For instance Private > Data for V_MS/VFW/FOURCC contains a BITMAPINFOHEADER and for V_REAL conta= ins > a real_video_props_t. These structures are defined in linked references b= ut > is it worthwhile to define the structure within the Codec Mapping? There = is > a method for defining bitstream data already in the FFV1 specification > (example) which we could adapt. IMO it shouldn't. When the documentation is public/stable enough we don't need to describe it again. It is needed when the mapping is not trivial like removing parts, adding parts or voiding some parts. > The definition for A_AAC/?????/??? implies that it applies to all A_AAC/* > Codec Mappings and its description says "AAC audio always uses wFormatTag > 0xFF=E2=80=9D which implies that WAVEFORMATEX is used in the Private Data= ; however > each definition for A_AAC/* says that the Private Data is void. So why do= es > it need to be said that "AAC audio always uses wFormatTag 0xFF=E2=80=9D? = The A_PCM > Codec Mappings reference wFormatTag as well. I think it was a way to tell that AAC mapping corresponds to the 0xFF wFormatTag in Windows ACM. I don't think we need to care about the ACM correspondance anymore except when it's necessary to interpret the mapping. > V_Uncompressed references a KaxCodecColourSpace element but there isn=E2= =80=99t such > a thing. Is it intended to refer to the ColourSpace Element? Yes and a lot more like Colour, MasteringMetadata and anything that cannot be deduced by the codec itself. > A_PCM/* references a KaxAudioBitDepth element. Is this meant to be the > BitDepth Element? Yes and how the channels are layed out although I'm not sure we have that y= et. > The specs list A_QUICKTIME/QDMC and A_QUICKTIME/QDM2 as deprecated and > superseded by A_QUICKTIME. However we note deprecation with a date in the > =E2=80=9CDeprecation Date=E2=80=9D value, but I=E2=80=99m unable to deter= mine when that date was. > Suggestions on a date to use or an alternate expression to note Codec > deprecation? Maybe Moritz know better but I don't know about these particular formats and would guess they have never been used. > Best Regards, > Dave Rice > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > Hi from FOSDEM. --=20 Steve Lhomme Matroska association Chairman From nobody Sat Feb 4 06:15: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 6AD48129A8C for ; Sat, 4 Feb 2017 06:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TRE1eQDv8MH for ; Sat, 4 Feb 2017 06:15:53 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17354129A6A for ; Sat, 4 Feb 2017 06:15:53 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id w194so14113829ybe.0 for ; Sat, 04 Feb 2017 06:15:53 -0800 (PST) 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=VLwRQ1gDnX2VUQZzBbtZGZVi+ZPpr+2TxiG/FXakHOw=; b=cAdZ0Ql7RQg5D1tngKP5ThcoYBglgIprDi1rBLyd32Zs5NqZtc/F9Oq+DlYF4dFm4R MqFmZEvK0UMGkTRKrtsKjybsvpXUkdkSIvCBcp3HSy/fYO+EAlQop6ziqKBgpsxS/odY tTOFWCwATRgoF9d4W106zjueyIHcqkENLm2Rk9ZzxEQsXBasOIDiX/bJKWc5AvBXfGT0 ZsMEWHmr+VRTBkphEvJiMLZlaD/HkuuK/mBKQPgI3JALH7KpRUqaL7KIaFrQqwodLCij BfRCzqARm0VA1hV4pVRgrlPfcJlk6/PR9Ed21GQ8UaEEH1eajA5ytGRuoF8vqFTh+1Mr p+HA== 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=VLwRQ1gDnX2VUQZzBbtZGZVi+ZPpr+2TxiG/FXakHOw=; b=cYbdFAIl9IpLJ5MeYJIBFtbeZD12N1/kMu2nKgObAbuTEm8a6kHXavavuANTo4nNmO UfMhVxyCocB9bk0vyNMMC5mt/hBHE17ivTj2twkxyS6XkRhpnpJP4UNNhnYyuCajycwm aX4QydbxfYzFEnHgJH93ACLvLWWhzq9fxrEgYwnN0CuQZCA5VAYSmY2+qDbAiQAiEKHA IBR4tOIKIRNqGFeL5ItVldfUMMYKmbpG8SzID2O0zgj5fo3sCF0odJAESQihtNeL0FNb xqSQuGQNaEMuizBbHrTPrWwdnsb1DWNSrTue6Lfkd+cundlWVKcG9PLP/X+B+bLPhD89 3zGw== X-Gm-Message-State: AMke39nsCS5ja5bSz64NMZCoIL/PCvmK8/DBU/BUZwK8UO8BK6L7Zg5I+7FSb1g86x3cAxM0KYugiZiwEy7DZg== X-Received: by 10.37.212.150 with SMTP id m144mr1328371ybf.149.1486217752103; Sat, 04 Feb 2017 06:15:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 06:15:51 -0800 (PST) In-Reply-To: <20170202100319.27f573dd@debian> References: <58525F89.5000600@das-werkstatt.com> <20170202100319.27f573dd@debian> From: Steve Lhomme Date: Sat, 4 Feb 2017 15:15:51 +0100 Message-ID: To: wm4 Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 14:15:54 -0000 Sorry being late on this. This is a more general issue than just the colours, it's also true for cropping. The classic case is 1080p MPEG-2 files which actually report 1088 height (IIRC) and so cropping is forced in the container. In general we need to tell in the Matroska very clearly how it works between the codec and the container. IMO the sensitive way to do it is leave it to the codec when it knows, and put it in the container when the codec doesn't have the information. When it is found in the container AND in the codec, it should mean that the container decided to override whatever the codec says. For example if the codec put the wrong information, it's possible to fix it "losslessly" in the container (in the sense you don't have to edit each frame and reencode them). Or maybe change values to make things look better (or worse). There should not be a scenario where you get the information twice and pick whichever you want. I know playback frameworks are not exactly designed that way right now (FFmpeg/libav/VLC) but IMO that's the clean way to handle it. 2017-02-02 10:03 GMT+01:00 wm4 : > On Thu, 15 Dec 2016 10:16:57 +0100 > "Peter B." wrote: > >> ======================= >> container or codec - or both? >> ======================= >> >> >> All 3 versions have their pros and cons, but I think having it in both >> causes more trouble than does good (see below). > > Using the codec has another advantage: parameters can change at runtime. > > I have seen Matroska files which have both codec and container aspect > ratio set, and for which the codec aspect ratio changed at runtime. > There are barely two pieces of software which handle this the same way. > > On the other hand, no matter what you do, getting multiple > implementations to handle codec/container mismatch the same way has a > high chance of failure, because they could support the codec and > container hints to a different degree. > > I think ideally, container hints should either not be defined, or if > they are, reflect the codec hints exactly. If Matroska can contain > midstream parameter changes, this would require Matroska to have a > mechanism for reflecting them in the container metadata. > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sat Feb 4 06:28:37 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF47A129B1A for ; Sat, 4 Feb 2017 06:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCMTiZd7zvyc for ; Sat, 4 Feb 2017 06:28:33 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B10129B18 for ; Sat, 4 Feb 2017 06:28:33 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id 123so14079406ybe.3 for ; Sat, 04 Feb 2017 06:28:33 -0800 (PST) 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=Lf1wAKYZmpKrxiau9kCJkvTmkOofJ9PMljBN2Q8Klrc=; b=zpVQWR+TJIclL/TW/tUG4jzuty/ZpOnrjgrN1xq54WFUBFSskLSbJSY73tDWgpDE/C SxPRvEA9rLf8jdw/bFd57WInlr0hpVTYkV3Vr1E5p/5+r/q+ACDD9nie/to2+Ny8DGlH MrGranCM+5Orzz8elbRL+31N/+/fz1NJVyF+IMU574gjksVthVSQ2lPxnRPgFXvtoQop ZukcJJZ6Cpq8pyA1SYvl3q91ToP2Z9Nsh0CY5VXf1Rr9rOsdtI7trGemcwnqzuaQo0fo nGQIfIoY37uHGFjbRo2IwUxTJqPa9tubGxDniPZXI0JZl1YRFH9gDICIY0BA1gTO319Z qU7A== 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=Lf1wAKYZmpKrxiau9kCJkvTmkOofJ9PMljBN2Q8Klrc=; b=USfAVzAgSb7vrGY0OVpcQJkcbtrCtxT/11lHhQ6PxqddccaM+ZCqJ7uhFiTLrlGMQI NA635r3QFFCBZSHBLD44YuoysoCFZY7MZP+fdufKvBCVUfAERMKLRi33vxRXne9WFutC USFHuMVHPBhMTFgKpS36kFD+jsE6rQlLHQ0VwG4TEqHh2DlXaKxIZp+QNxLwQVr7oYwr L+1HRa/MSzMpre9XeQFkET/aITUixEMC2yuSqTtfMM7FYwEvRD8PjiSxrWLNfTfvpC7o 6XHJ+DFBBi+kxZzpQ/KMZdMzMC3xljZydYoq94b+xcx8PGkqeZCuXhw644sfP3qcGVif HtjQ== X-Gm-Message-State: AMke39lEchCT9wdk5TOGc5JayPYcBc4LMg3gRjgDe4ObZOzB7ts4KiBOineSBlNaAAGIW0jFWF7KZxwk1GtB4A== X-Received: by 10.37.201.196 with SMTP id z187mr1434659ybf.161.1486218512764; Sat, 04 Feb 2017 06:28:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 06:28:32 -0800 (PST) In-Reply-To: References: <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> From: Steve Lhomme Date: Sat, 4 Feb 2017 15:28:32 +0100 Message-ID: To: Reto Kromer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Rationale Numbers for timestamps X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 14:28:36 -0000 2017-01-15 18:12 GMT+01:00 Reto Kromer : > Dave Rice wrote: > >>For hand cranked silent film, the film prints would usually >>be distributed with recommended frame rates, so that the >>projectionist is =E2=80=98trying=E2=80=99 to crank in order to present at >>18 fps (or as directed). If that film is digitization to a >>Matroska file then I think that the Matroska should also be >>labelled for an 18 fps projection just as the film print >>would have been. If there=E2=80=99s desire to replicate the >>unperfect cranking of a human operator than that could be >>accomplished by the player and not the file itself. Should >>I file a ticket for VLC to accept input from a USB-attached >>hand crank? I'm sure we have had weirder requests. You may want to give an example of such a device we can test with, though :) > +1 > > There is not only the operator's "imperfect hand-cranking", > but also the films themselves that may have different > projection speeds between reels and also inside a single > reel. Many instruction sheets for the operator as well as > for the conductor are known. Given that's an edge case we would like to handle can you tell a bit more about the limits we would have to reach ? The fact it's in the same reel or different reel doesn't really matter if it's all in one Segment. But the different possible values or if some say things like 'just roll it as fast as humanly possible'. Of course in such case we still have the old system that still works fine when you don't need pure digital accuracy. > Best regards, Reto > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sat Feb 4 06:39:40 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 4EE02129B22 for ; Sat, 4 Feb 2017 06:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 V5m5P_UXbxmh for ; Sat, 4 Feb 2017 06:39:38 -0800 (PST) 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 736D3129B27 for ; Sat, 4 Feb 2017 06:39:38 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id u68so28016074ywg.0 for ; Sat, 04 Feb 2017 06:39:38 -0800 (PST) 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=etX5IAeVAfYRxRY4dLpnWM5MQcPmG9+AjsjX6mPPhl4=; b=H64ncxd6V5n81MxEFJYGS/r3YsZ9M4ptskenzXYtz8MfbNvylrieq0k2lLejghxMJ4 g8jYoQe5YfpzzXwtlzQvV+pEAf4fuOLYJ5yuR/UFdcxdYhQIfXJ2UjNsw4PM/QY5gxy4 /8JEASg92s8LysVUj1plT08vmltr5l7JviFcgk82Eccfru83FoDnSaAfoyN8gFd1p37W Z449GQD29jdHFkgB5gLUaSSJPmPnQlkuPLPLJYLWqlHhofeEXq928EAFvPvmYaAEUD24 PQVs7mU/570xTRxbYYj2Oa3HdFeYZzcZzttPdO6FFr6AYCbn+DvnbU8B4bG1oaghq1cS 10AA== 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=etX5IAeVAfYRxRY4dLpnWM5MQcPmG9+AjsjX6mPPhl4=; b=oWsRG2tZd9mBgGwBc57oeybGM/bKd/C/WKp8lGYPs2KyaDQ5MDL82V6GJG0trL/vcO VVDDORiOhFOgm/g/WtjtVmF8LF0UcWLAm+loR999p9nFEKGRBmV1R0djPjSMbhMif8UH 4MXz7s5OVDPOE7MuVBqiC/o4hYzJvwzPlRhVwcM9BxSLIoByXsUVK0fq3L9OeMXqsyQH Tx+UfmI/OJ1xWvYxPGOonEU7ZYHpmIwn0BDARf7uM8HX6BhA1xgGGgzWWJ1D+ovC9OMP M7GKApA60d46BGjbA46hHJA44eDctu3oJj2HQr78s+I0tz8NqtlRI0DTkJb/4t+n5E1/ k3/w== X-Gm-Message-State: AMke39l+ijZGflFORyO4o737qBkADWWENDRQ53p+hFghQ3mqJBowFZIGzo2MnjhXzl9aJVOUv0Yr2hDC/3/UsA== X-Received: by 10.129.79.200 with SMTP id d191mr1490334ywb.75.1486219177442; Sat, 04 Feb 2017 06:39:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 06:39:37 -0800 (PST) In-Reply-To: <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> From: Steve Lhomme Date: Sat, 4 Feb 2017 15:39:37 +0100 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jerome Martinez , Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Rationale Numbers for timestamps X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 14:39:40 -0000 2017-01-15 17:24 GMT+01:00 Dave Rice : > Hi Jerome, Steve, > >> On Jul 27, 2016, at 3:28 PM, Steve Lhomme wrote: >> >> 2016-07-27 6:13 GMT+02:00 Jerome Martinez : >>> On 27/07/2016 04:35, Steve Lhomme wrote: >>>> >>>> As the topic often resurfaces maybe it's time we discuss it in the >>>> context of CELLAR. >>>> >>>> There have been talks about ways to do it in the Matroska mailing >>>> before in this thread: >>>> >>>> https://lists.matroska.org/pipermail/matroska-devel/2012-October/00429= 4.html >>>> >>>> https://lists.matroska.org/pipermail/matroska-devel/2012-October/00429= 5.html >>>> >>>> https://lists.matroska.org/pipermail/matroska-devel/2012-October/00429= 6.html >>>> >>>> https://lists.matroska.org/pipermail/matroska-devel/2012-October/00429= 9.html >>>> >>>> An element to handle it was added (still in specdata.xml but commented= ) >>>> >>>> https://lists.matroska.org/pipermail/matroska-devel/2012-September/004= 289.html >>>> and later removed >>>> >>>> https://lists.matroska.org/pipermail/matroska-devel/2012-December/0043= 17.html >>>> >>>> So far there was nothing conclusive but it seems it's not possible to >>>> do it properly in a backward compatible way. >>>> >>>> The constraints are simple: >>>> - backward compatible, so the 16 bits timestamp value in the >>>> (Simple)Block must remain unchanged. This value is multiplied by the >>>> scale (global and/or per track) to get the actual timestamp. >>>> - There could be some acceptable rounding between the two coexisting >>>> systems. >>>> - The rounding should happen in the current system, the rationale >>>> should always be exact (provided the source is exact) >>>> - A lot of Matroska elements are based on the timestamp scales. So >>>> they may be adjusted accordingly >>>> - We must minimize the elements where the same information is found >>>> twice. Basically only scale elements should be added. Maybe some >>>> elements for the Cluster timestamp might be added as well if >>>> necessary. >>>> - because of the 16 bits range per Cluster differences between a >>>> rationale system and the ns system must be tight. >>>> - we still want Clusters to be 4-5s long to minimize the scope of >>>> errors and buffering before playback. It may also correspond to some >>>> GOP values. >>>> - sample accuracy for audio would be good. >>>> >>>> Let the math begin. >>> >>> >>> Rationale Numbers for timestamps are usually for US style fixed framera= te, >>> so I think my answer in a previous email still applies. >>> https://mailarchive.ietf.org/arch/msg/cellar/WQCExNvAZy4goibE3_chnFB1w0= c >>> Please comment about which need would not be fulfilled with this propos= al. >>> >>> Copy/paste: >>> >>> I don't like the idea to have an incompatible change with such feature, >>> because this is not a "must have" for 99% of people, and Matroska "v5" >>> will not be adopted with that. >>> I think that we can have a workaround for having additional 0.99% happy >>> without the need of a break in compatibility: >>> - lot of people want to know the exact frame rate of a fixed frame rate >>> stream, people muxing from tapes know that the frame rate is fixed >>> (hardware limitation) so can set this element in the header. >> >> Let's rewind a decade or more. The timestamps were originally using >> floating points on purpose. At the time all sources were analog (film >> or video tape). And in the analog world the clock is never perfect. >> You cannot expect to have 30000/1001 frames per second and 48000 >> samples a second for hours without some drift. And I'd rather have the >> timing as accurate as the analog source rather than clean it for the >> digital world. > > It=E2=80=99s true that analog format frame rates are more analogous to fl= oating points. A video tape may stretch unevenly from use so that frames do= n=E2=80=99t start with exact precision. However these discrepancies complic= ate digitization and most videotape digitization will use a hardware time b= ase corrector to buffer analog video in order to transmit it accordingly to= a more precise clock, so that the resulting digital file will have already= had it=E2=80=99s frame rate =E2=80=98cleaned=E2=80=99. > > To Jerome, by "set this element in the header=E2=80=9D do you mean within= the Info Element similar to how it contains a nominal Duration Element? Or= do you mean to set this within the associated Track Element? I=E2=80=99m a= ssuming per track. > >> In the context of digitizing for archivists I don't know if that's >> something that's taken in account. Dave ? For example how is that >> solved for movies from the early days where a guy would have to turn a >> handle to advance the film. It's definitely not a very precise/clean >> clock. > > For videotapes that are stretched or shrunken to affect the presentation = timing, these deviations are not the intent of the recording, so using a ti= me base corrector fixes the frame rate. Also in the case of film shrinkage = the projector should still present at 24 fps although damage is more likely= . So I think following the intent of the format whether 30000/1001 or 24 fp= s is correct. > > For hand cranked silent film, the film prints would usually be distribute= d with recommended frame rates, so that the projectionist is =E2=80=98tryin= g=E2=80=99 to crank in order to present at 18 fps (or as directed). If that= film is digitization to a Matroska file then I think that the Matroska sho= uld also be labelled for an 18 fps projection just as the film print would = have been. If there=E2=80=99s desire to replicate the unperfect cranking of= a human operator than that could be accomplished by the player and not the= file itself. Should I file a ticket for VLC to accept input from a USB-att= ached hand crank? > >>> putting >>> frame rate info in the header with numerator and denominator is enough >>> for doing the difference between 30000/1001 and 29970/1000, and the >>> current millisecond timestamp is enough (a demuxer aware of the >>> framerate element can "correct" the timecode from e.g. 0.033s to >>> 1001/30000 second; an old player just play the file with 1 ms >>> precision). We could add some rules in case a timecode does not fit the >>> frame rate (e.g. if timecode is 0.031, frame rate info is considered no= t >>> applicable) >> >> In video the issue is not too big. But if we want sample precision for >> audio, the fraction is a lot bigger (up to 192000 fps with modern pro >> hardware). And with a timestamp scale shared among tracks that could >> be problematic. If we want sample precision for audio and video we >> could end up we'd lose a big range of the 16 bits available per >> Cluster. Each of the 65536 Block timestamp would be 1/192,000s >> (0.0052ms) giving a max Cluster duration of 0.341333s (65536/192000). >> If we want to precision for a 1001/30000 track and a 1/192000 track we >> would need a fraction of 1001/(30000*192000) (0.000173ms) resulting in >> a Cluster max duration of 0.011s. > > Yes, this approach is not scalable. One could have 24000/1001 video, 3000= 0/1001 video, 44100 hz audio, and 192000 hz audio in the same file. > >> If the muxer knows that a track will always pack samples by an amount >> X (1152 in MP3 for example) we can regain some duration. But that's >> not always the case. Some codecs like Vorbis pack only a small amount >> of samples per frame and the amount can vary between frames (In Vorbis >> I, legal frame sizes are powers of two from 64 to 8192 samples). The >> worst case scenario (I know of) of Vorbis at 192 KHz, frame precision >> of the timestamp means we can only have a Cluster duration of 21.84s >> (65536*64/192000). Mixed with NTSC video that's >> 65536*64*1001/30000*192000 =3D 0.72s max duration for sample precision >> per frame (not sample but it's close enough). That's still 21 video >> frames in that Cluster. Not too bad. >> >>> - people having variable frame rate with very precise timestamp need to >>> know it before starting the muxing and can use a Timecodescale element >>> of 1 (so precision of 1 nanosecond, usually enough when there is no >>> fixed frame rate). >> >> I can think of 3 different variable frame rate use cases: >> >> - mixing video (25/29fps) and film sources (24fps) into one final video >> - a camera dropping some frames or only storing images when they >> change. In this case there's likely a stable main clock like in >> constant frame rate. >> - a camera that would work like the eye. When there's >> adrenaline/danger you capture images faster. In this case there's no >> real clock. The timestamps can happen at anytime. > > I understand the issues of adding a frame rate numerator and denominator = to the track header as multiple timestamps could round to the same incremen= t of the frame rate. However what if the rounding to the nearest increment = of the frame rate is enabled by one of the reserved flag bits of the Block = Header (such as bit 1 of flags =3D Enable TimeScale Alignment)? > > Thus if the frame rate of the track header is 120000/1001, then > > If Matroska timecode is 4 and Enable TimeScale Alignment is 0, than it is= at 4 / (1000000000 / TimecodeScale ). > If Matroska timecode is 4 and Enable TimeScale Alignment is 1, than it is= at 0 / 1200000 (nearest increment of the rationale frame rate). > > If Matroska timecode is 17 and Enable TimeScale Alignment is 0, than it i= s at 17 / (1000000000 / TimecodeScale ). > If Matroska timecode is 17 and Enable TimeScale Alignment is 1, than it i= s at 2002 / 1200000 (nearest increment of the rationale frame rate). I'm not sure I follow the math but using a flag in the SimpleBlock/Block sounds interresting. But in effect wouldn't all blocks have either 1 or 0 from a muxer version ? In that case it would just mean the rationale timecode system should be used, if the demuxer can deal with it. And basically that would mean it should be used if present. Do we need to extra flag for that ? > Ignoring the rationale frame rate and the Enable TimeScale Alignment bit = would still decode to the accuracy supported by the TimecodeScale; however = a player that uses the rationale frame rate and Enable TimeScale Alignment = could round the timecode to the nearest increment of the frame rate. > > Such a feature would not be useful for mixed timebase content (documentar= y that mixes 24000/1001 and 30000/1001 framerates together). As said by Jerome. In most cases there's an easy common factor. The problem is really the example described early with a more variable analog source. If it doesn't have a stable clock (why not?) then the old system should be "good enough". >>> Which real life scenario can not deal with such workaround? >> >> The question is: why do we want rationale number if we're going to >> allow some form of rounding between the tracks that match the >> timestamp scale precisely and the one that don't. IMO if there's >> rounding let's just keep what we have. >> >>> Compared to the concerns in: >>> https://lists.matroska.org/pipermail/matroska-devel/2012-October/004294= .html >>> It is per track so it resolves most concern >>> For PCM, the corresponding video framerate is sometimes used and it wou= ld >>> not be resolved correctly, right (i.e. at 30000/1001 fps, there are >>> sometimes 1601 samples and sometimes 1602 samples and it is not possibl= e to >>> do the difference with the 16-bit timestamp having the millisecond >>> precision) >>> Note that my proposal is similar to the one in the mail having criticis= m >>> about TimecodeScaleDenominator (proposal of TrackTimeBaseNumerator and >>> TrackTimeBaseDenominator) > > [=E2=80=A6] > > Best Regards, > Dave Rice > --=20 Steve Lhomme Matroska association Chairman From nobody Sat Feb 4 06:49:07 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE579129B2F for ; Sat, 4 Feb 2017 06:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[SPF_NEUTRAL=0.652] 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 1EFCiG0wwK4b for ; Sat, 4 Feb 2017 06:49:04 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7124F129B2B for ; Sat, 4 Feb 2017 06:49:04 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:39530 helo=[10.0.1.12]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1ca1e7-001KH2-Gu; Sat, 04 Feb 2017 09:49:03 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: Date: Sat, 4 Feb 2017 09:50:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1888ECBC-8420-406C-B259-EB31B08D0952@dericed.com> To: Steve Lhomme 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: Cc: Nick.Drouin@live.com, Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] adding VP8 and VP9 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 14:49:06 -0000 The VP9 format specification is still in draft form. We could use = https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bits= tream-specification-v0.6-20160331-draft.pdf as used on = http://www.webmproject.org/vp9/. This link is not hosted by IETF but is = more up to date. Is the IETF actively working on VP9? Dave > On Feb 4, 2017, at 8:14 AM, Steve Lhomme wrote: >=20 > They definitely need to go in. The VP9 link should be changed to > something more stable and revent. Otherwise LGTM. >=20 > 2017-02-01 23:57 GMT+01:00 Dave Rice : >> Hi cellar, >>=20 >> Just before the cellar wg became active there was a proposal on >> matroska-devel to document use of VP8 and VP9 in Matroska, similar to = how >> they have been defined in webm. I started a pull request at >> https://github.com/Matroska-Org/matroska-specification/pull/91 to add = them. >>=20 >> The original thread also proposes adding WEBVTT but it seems = there=E2=80=99s some >> open questions there about how to do so. >>=20 >> Dave Rice >>=20 >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >>=20 >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman From nobody Sat Feb 4 06:55:38 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3B7129648 for ; Sat, 4 Feb 2017 06:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[SPF_NEUTRAL=0.652] 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 koUQ6GGg5032 for ; Sat, 4 Feb 2017 06:55:34 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094E612944E for ; Sat, 4 Feb 2017 06:55:34 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:47978 helo=[10.0.1.12]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1ca1kS-001S09-JC; Sat, 04 Feb 2017 09:55:33 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: Date: Sat, 4 Feb 2017 09:56:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <18752B8C-73D0-4312-85DE-5566CC805AF5@dericed.com> References: <1888ECBC-8420-406C-B259-EB31B08D0952@dericed.com> To: Steve Lhomme X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.1 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: Cc: Nick.Drouin@live.com, Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] adding VP8 and VP9 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 14:55:35 -0000 The VP9 link is updated to http://www.webmproject.org/vp9. = https://github.com/Matroska-Org/matroska-specification/pull/91 should be = ready. Dave > On Feb 4, 2017, at 9:50 AM, Dave Rice wrote: >=20 > The VP9 format specification is still in draft form. We could use = https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bits= tream-specification-v0.6-20160331-draft.pdf as used on = http://www.webmproject.org/vp9/. This link is not hosted by IETF but is = more up to date. >=20 > Is the IETF actively working on VP9? > Dave >=20 >> On Feb 4, 2017, at 8:14 AM, Steve Lhomme = wrote: >>=20 >> They definitely need to go in. The VP9 link should be changed to >> something more stable and revent. Otherwise LGTM. >>=20 >> 2017-02-01 23:57 GMT+01:00 Dave Rice : >>> Hi cellar, >>>=20 >>> Just before the cellar wg became active there was a proposal on >>> matroska-devel to document use of VP8 and VP9 in Matroska, similar = to how >>> they have been defined in webm. I started a pull request at >>> https://github.com/Matroska-Org/matroska-specification/pull/91 to = add them. >>>=20 >>> The original thread also proposes adding WEBVTT but it seems = there=E2=80=99s some >>> open questions there about how to do so. >>>=20 >>> Dave Rice >>>=20 >>>=20 >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Steve Lhomme >> Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Sat Feb 4 07:09: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 AF11E129B89 for ; Sat, 4 Feb 2017 07:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 hm4GnN6_JDrt for ; Sat, 4 Feb 2017 07:09:32 -0800 (PST) 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 496EF129B7F for ; Sat, 4 Feb 2017 07:09:31 -0800 (PST) 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 v14F9So5024739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sat, 4 Feb 2017 16:09:29 +0100 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 v14F9SRq047247 for ; Sat, 4 Feb 2017 16:09:28 +0100 Date: Sat, 4 Feb 2017 16:09:29 +0100 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] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 15:09:34 -0000 Steve Lhomme wrote: >In general we need to tell in the Matroska very clearly how >it works between the codec and the container. Indeed. >IMO the >sensitive way to do it is leave it to the codec when it >knows, and put it in the container when the codec doesn't >have the information. When it is found in the container AND >in the codec, it should mean that the container decided to >override whatever the codec says. Sorry, Steve, I am personally not convinced. From a previous discussion I have understood that when both the container and the codec hold an information, then the codec should have the precedence, because the probability it is kept safe during a trans-muxing is per se much higher. Just my thoughts, as I started doing so for our own restoration applications (using NUT, not Matroska, but the principle seems to me to be the same). Reto AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: https://reto.ch | Twitter: @retoch From nobody Sat Feb 4 07:12: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 819E7129AF7 for ; Sat, 4 Feb 2017 07:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 b4HdQbdXPxQ7 for ; Sat, 4 Feb 2017 07:12:30 -0800 (PST) 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 5F511129A9B for ; Sat, 4 Feb 2017 07:12:30 -0800 (PST) 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 v14FCSHJ028673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sat, 4 Feb 2017 16:12:28 +0100 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 v14FCSqN057756 for ; Sat, 4 Feb 2017 16:12:28 +0100 Date: Sat, 4 Feb 2017 16:12:28 +0100 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] The Reel Thing X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 15:12:31 -0000 Steve Lhomme wrote: >Not AFAIK but that's tempting. Please allow me an update. If we decide to propose something, then it should happen very fast, because I know that during this coming week they are meeting for the programme's content. On my side I am hesitating. Best regards, Reto AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: https://reto.ch | Twitter: @retoch From nobody Sat Feb 4 07:34: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 9D34E129418 for ; Sat, 4 Feb 2017 07:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[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 v6yv9nPpKPu6 for ; Sat, 4 Feb 2017 07:34:28 -0800 (PST) Received: from 5.mo179.mail-out.ovh.net (5.mo179.mail-out.ovh.net [46.105.43.140]) (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 6493B124281 for ; Sat, 4 Feb 2017 07:34:27 -0800 (PST) Received: from player732.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 203F91F296 for ; Sat, 4 Feb 2017 16:34:25 +0100 (CET) Received: from [151.216.134.182] (unknown [151.216.134.182]) (Authenticated sender: jerome@mediaarea.net) by player732.ha.ovh.net (Postfix) with ESMTPSA id 949E910007D; Sat, 4 Feb 2017 16:34:21 +0100 (CET) To: Steve Lhomme References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> From: Jerome Martinez Message-ID: <402d0e5e-4e64-2341-9a0d-a18d56a7d2c1@mediaarea.net> Date: Sat, 4 Feb 2017 16:34:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 17618363218798907537 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelgedrjeefgdektdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Archived-At: Cc: Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Rationale Numbers for timestamps X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 15:34:30 -0000 On 04/02/2017 15:39, Steve Lhomme wrote: > [...] > I'm not sure I follow the math but using a flag in the > SimpleBlock/Block sounds interresting. But in effect wouldn't all > blocks have either 1 or 0 from a muxer version ? In that case it would > just mean the rationale timecode system should be used, if the demuxer > can deal with it. And basically that would mean it should be used if > present. Do we need to extra flag for that ? In previous discussions there were some concerns about when a muxer starts to mux with constant frame rate config but the "real time" feeding changes during muxing and it is no more with this frame rate, the "rouding" would be still there from a demuxer point of view without the flag; This flag is an answer to this concern, the algo can be deactivated during muxing even if it is not possible to change the Matroska header e.g. live stream. From nobody Sat Feb 4 07:36:10 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 5813A1293D9 for ; Sat, 4 Feb 2017 07:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 M_sX-E-JoJi6 for ; Sat, 4 Feb 2017 07:36:08 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 5121D124281 for ; Sat, 4 Feb 2017 07:36:08 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id l19so28363912ywc.2 for ; Sat, 04 Feb 2017 07:36:08 -0800 (PST) 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=Q4dYr+YL/5hO4JFfYHjHkzZsehQgdk6+IZ4NpzA+pIY=; b=kTGjQjWnrcEF3Inr9MDKHUT2i1NbPAK3RAZy9BfsC2ftWCSamrZAyECIPrWWPxLICv V6HtFQ4FCQ1bzF+xCpqb/Hy3qt57ndhmwJj5Ku4NZVvasVTYlaKrxjc59/Ku624cu+Nj oNofzqj2acywKXIH/qF8DoBJ6DkBoFcyHop15yeB03JC2DmDID+wpDqLzBMlB51ZBdTU Vxq8ltopKILFhXNUgGkUPSrmys24P3XS/D2gymv3v9fxREmkg33X3j7La2Gk85WilKNR wGLOtWP/T11tEidrdvUu2bnI3w/WuVynqBgIzWpmKBZl0IAmJ90kpiiNQIrxZ/qGEFsH vWXw== 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=Q4dYr+YL/5hO4JFfYHjHkzZsehQgdk6+IZ4NpzA+pIY=; b=CQ8yX7N0VkZaKkI7aOT3EjqsZEcpX9dqqyAvEbBv3eE4iC+f4gYpm1qK9kKYXVpN0p KtyI52C3J2tCk5WrcSF0e7Gmd9x5ivlddOzOf/Orr0V2Z3jhF9BFXoLJY+jsDUwyROqm F+05oWiTJ7O2rOv8gAnUW6z1RGLHIQ1iijT5BQUJ9DEYxlrxDHUv7IAUm1cfWer2rQ+b C7bD6KB3W5mUXI4mHsO3vsigZe2OvHVRZ0+sxwUIgXlQFK0xSk18uTDwb0Qjm/GTz98p q9Ei8npGYV4q0/+ES44m4FYkon/V9BzJbWGvmgdxYIBhu9gu14+CayENSUHeS7evEJLs /3OQ== X-Gm-Message-State: AIkVDXJcLVVmXqDjSbI2YbzQtCANOxN1FE/JPfc5wrUGlUUM5EzNHqx4zP24BMG2FUbE2Frp6POb6QRC2fdXIw== X-Received: by 10.129.183.39 with SMTP id v39mr1534113ywh.266.1486222567528; Sat, 04 Feb 2017 07:36:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 07:36:07 -0800 (PST) Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 07:36:07 -0800 (PST) In-Reply-To: <402d0e5e-4e64-2341-9a0d-a18d56a7d2c1@mediaarea.net> References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> <402d0e5e-4e64-2341-9a0d-a18d56a7d2c1@mediaarea.net> From: Steve Lhomme Date: Sat, 4 Feb 2017 16:36:07 +0100 Message-ID: To: Jerome Martinez Content-Type: multipart/alternative; boundary=94eb2c117c763212080547b62893 Archived-At: Cc: Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Rationale Numbers for timestamps X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 15:36:09 -0000 --94eb2c117c763212080547b62893 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, I remember now. That sounds usable then. Le 4 f=C3=A9vr. 2017 16:34, "Jerome Martinez" a =C3= =A9crit : > On 04/02/2017 15:39, Steve Lhomme wrote: > >> [...] >> I'm not sure I follow the math but using a flag in the >> SimpleBlock/Block sounds interresting. But in effect wouldn't all >> blocks have either 1 or 0 from a muxer version ? In that case it would >> just mean the rationale timecode system should be used, if the demuxer >> can deal with it. And basically that would mean it should be used if >> present. Do we need to extra flag for that ? >> > > In previous discussions there were some concerns about when a muxer start= s > to mux with constant frame rate config but the "real time" feeding change= s > during muxing and it is no more with this frame rate, the "rouding" would > be still there from a demuxer point of view without the flag; > This flag is an answer to this concern, the algo can be deactivated durin= g > muxing even if it is not possible to change the Matroska header e.g. live > stream. > > > --94eb2c117c763212080547b62893 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, I remember now. That sounds usable then.=C2=A0
<= div class=3D"gmail_extra">
Le=C2=A04 f=C3=A9v= r. 2017 16:34, "Jerome Martinez" <jerome@mediaarea.net> a =C3=A9crit=C2=A0:
On 04/02/2017 15:39, Steve Lhomme = wrote:
[...]
I'm not sure I follow the math but using a flag in the
SimpleBlock/Block sounds interresting. But in effect wouldn't all
blocks have either 1 or 0 from a muxer version ? In that case it would
just mean the rationale timecode system should be used, if the demuxer
can deal with it. And basically that would mean it should be used if
present. Do we need to extra flag for that ?

In previous discussions there were some concerns about when a muxer starts = to mux with constant frame rate config but the "real time" feedin= g changes during muxing and it is no more with this frame rate, the "r= ouding" would be still there from a demuxer point of view without the = flag;
This flag is an answer to this concern, the algo can be deactivated during = muxing even if it is not possible to change the Matroska header e.g. live s= tream.


--94eb2c117c763212080547b62893-- From nobody Sat Feb 4 07:44:12 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1875912940E for ; Sat, 4 Feb 2017 07:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFixtB5Thi-G for ; Sat, 4 Feb 2017 07:44:09 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D90124281 for ; Sat, 4 Feb 2017 07:44:09 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id o65so14467166ybo.2 for ; Sat, 04 Feb 2017 07:44:09 -0800 (PST) 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=KjRsjJAGfsKAkVVwwvjBdt4GIKJ+xqWMXnIcOxIwt2c=; b=wzmjDZw4eMhNdFFtSM91t7vtlJmBPeSgClMic6p0EKQoZFFUZRvDDbmcPD3rowuGwY WA0RYxHxkKvKGiTM7LQxp1NwB4RnoiTXkL+64gsNETn6lrFv5aaAH/7IbIyZHYG9pKnk WhgNm8pe3i46p8LDY5rSCl8ytiSHYJ8qytnf59iMx/gA89/Ef08W/NYORZC5dlUpMrPO k5jmaE1B0vp5URJHOwjwkLPvujZM5TqtvqTyKqS7JEadhJw6BZr5nIA1NAowJ5UUoyIo pkzQyr89eb+O0P1fqK3GIKFCXBAPXEqO6s9xVTFgX6I392hv9exb4Hk/qRwU09y5zcr5 GRBg== 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=KjRsjJAGfsKAkVVwwvjBdt4GIKJ+xqWMXnIcOxIwt2c=; b=HllsTEoKCUN+1MnCDOVSy4H+HxBNHuZzJPzMHnfBgwEsTCPg0zxxPvxKZPQhtsuro7 GEiBLOc1fE4aj6pEHE2GHiBuZsh+ZCFsA6MIKrvhqzTqqLe/DwWmviyqpHTzPH3GmvB1 aWU3lwzv3mL1d5ExNpAbtmsh+Wic5a3OcAbEcrH2UH6mFaWbqkwPgZrSYMYFVGz3d/g6 rsQBBAP/RCL1jb4u6jgWopvFKOO0DGRAQi/5+KmOB4q9ZQIoKESPKmRJVQwx3Qqhkomh NzOB/ezLa5ExRqhzRWAZ+v+5SpH/CGIwV6sc5Dhi/I80jOdcrFlIXw0xb+22t14s5mSZ P1DQ== X-Gm-Message-State: AMke39nSweG68InyMNfoz0RVeXvXwsHmJJ05FnNw+LblBnGgA1+m2Ex90lec8J9AbxPCzTQNjOyrN3iskXj4JA== X-Received: by 10.37.219.193 with SMTP id g184mr1637341ybf.19.1486223048834; Sat, 04 Feb 2017 07:44:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 07:44:08 -0800 (PST) Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 07:44:08 -0800 (PST) In-Reply-To: References: From: Steve Lhomme Date: Sat, 4 Feb 2017 16:44:08 +0100 Message-ID: To: Reto Kromer Content-Type: multipart/alternative; boundary=94eb2c186b46e236250547b64442 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] The Reel Thing X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 15:44:11 -0000 --94eb2c186b46e236250547b64442 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you want we can try to present something together. On my own I'm not sure I would be the right one for the crowd. Le 4 f=C3=A9vr. 2017 16:12, "Reto Kromer" a =C3=A9crit : > Steve Lhomme wrote: > > >Not AFAIK but that's tempting. > > Please allow me an update. > > If we decide to propose something, then it should happen > very fast, because I know that during this coming week they > are meeting for the programme's content. > > On my side I am hesitating. > > Best regards, Reto > > > AV Preservation by reto.ch > chemin du Suchet 5 | 1024 Ecublens | Switzerland > Web: https://reto.ch | Twitter: @retoch > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --94eb2c186b46e236250547b64442 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you want we can try to present something together. On = my own I'm not sure I would be the right one for the crowd.=C2=A0
=

Le=C2=A04 f=C3=A9= vr. 2017 16:12, "Reto Kromer" <lists@reto.ch> a =C3=A9crit=C2=A0:
Steve Lhomme wrote:

>Not AFAIK but that's tempting.

Please allow me an update.

If we decide to propose something, then it should happen
very fast, because I know that during this coming week they
are meeting for the programme's content.

On my side I am hesitating.

Best regards, Reto


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

_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar
--94eb2c186b46e236250547b64442-- From nobody Sat Feb 4 07:46:07 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD30912940E for ; Sat, 4 Feb 2017 07:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.653 X-Spam-Level: X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_NEUTRAL=0.652] 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 uvMjVY0BBUb7 for ; Sat, 4 Feb 2017 07:46:05 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7E2124281 for ; Sat, 4 Feb 2017 07:46:05 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:45451 helo=[10.0.1.12]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1ca2XL-002hlN-GI; Sat, 04 Feb 2017 10:46:04 -0500 From: Dave Rice Message-Id: <41FEE115-519D-4633-8A26-6FFE8C1897D4@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8B9E9866-5CE8-42DD-9F47-AD9F356A33B0" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Sat, 4 Feb 2017 10:47:19 -0500 In-Reply-To: To: Steve Lhomme References: X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Reto Kromer Subject: Re: [Cellar] The Reel Thing X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 15:46:06 -0000 --Apple-Mail=_8B9E9866-5CE8-42DD-9F47-AD9F356A33B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1. Sorry I can not be there, but I can help prep a presentation from = afar. Dave > On Feb 4, 2017, at 10:44 AM, Steve Lhomme = wrote: >=20 > If you want we can try to present something together. On my own I'm = not sure I would be the right one for the crowd.=20 >=20 > Le 4 f=C3=A9vr. 2017 16:12, "Reto Kromer" > a =C3=A9crit : > Steve Lhomme wrote: >=20 > >Not AFAIK but that's tempting. >=20 > Please allow me an update. >=20 > If we decide to propose something, then it should happen > very fast, because I know that during this coming week they > are meeting for the programme's content. >=20 > On my side I am hesitating. >=20 > Best regards, Reto >=20 >=20 > AV Preservation by reto.ch > chemin du Suchet 5 | 1024 Ecublens | Switzerland > Web: https://reto.ch | Twitter: @retoch >=20 > _______________________________________________ > 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=_8B9E9866-5CE8-42DD-9F47-AD9F356A33B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
+1. Sorry I can not be there, but I can help = prep a presentation from afar.
Dave

On = Feb 4, 2017, at 10:44 AM, Steve Lhomme <slhomme@matroska.org> wrote:

If you want we can try to present something together. On my = own I'm not sure I would be the right one for the crowd. 

Le 4 = f=C3=A9vr. 2017 16:12, "Reto Kromer" <lists@reto.ch> a =C3=A9crit :
Steve Lhomme wrote:

>Not AFAIK but that's tempting.

Please allow me an update.

If we decide to propose something, then it should happen
very fast, because I know that during this coming week they
= are meeting for the programme's content.

On my side I am hesitating.

Best regards, Reto


AV Preservation by reto.ch
chemin du Suchet 5 | 1024 Ecublens | Switzerland
Web: https://reto.ch | 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

= --Apple-Mail=_8B9E9866-5CE8-42DD-9F47-AD9F356A33B0-- From nobody Sat Feb 4 07:50: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 BE267129B91 for ; Sat, 4 Feb 2017 07:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 J3i7sbJyRYFN for ; Sat, 4 Feb 2017 07:50:42 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E07129A5A for ; Sat, 4 Feb 2017 07:50:42 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id u68so28577563ywg.0 for ; Sat, 04 Feb 2017 07:50:42 -0800 (PST) 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=6VRSVrvC7OvVDYMwqoTcLrtlq8BK+1sC695dnuPjwzA=; b=kBx265LBGKTYsdin2A95yOSMJll+HyGScJlOnMmehuv0Stn766n9Ngr7ke4QMhvQxA AzutSm95/zO/hOKh9n9vNNpB86UkvEsh2dLk5SEml7bPJvh5WJGaeqv3xJDVI762HaHn uB0B92BbZrxGHuXhr0NrKie0nSLQMfZKC7sJ0+Cuo3KL6DUO0hWYSqkRAYEIoJivKsUv liJpz+JDVU6Z/vuMBnG3DBQpBzqJpDpaMRRgOwL3aAhVxVJlgZmHrTwMJuVYd55nZMQi vmm3Do9XdbbfWo3B/NSCwn4tK2v+nImP5Mvr7s29VS1Q6QC1R1mGWALvsxXFhCXJuoo3 VY4g== 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=6VRSVrvC7OvVDYMwqoTcLrtlq8BK+1sC695dnuPjwzA=; b=HQf3kw/N/tZWvVEFPEFyXas4eWxbTR72tuJyQC66IWIxSIWDhbP+6QalBGf5R7EavF eCpY7NIOg2drTq6EX53wqyR6urHoWXmeFfVRvOQ5hVfBx7iu46ibQb72j1VgzsbFE/3D OoMfJxVN5mN+NhkSND3lpW85/lWJ4HKPRhqhlpvLWCyE5O2X1gCMu6b1whHGCRUzYJTg fy8t2NovAPcvOKbenPXNZHELcQV8tNTnPKoOSi/1tGknk54ik/Qa9vSaEZRHYVFSwoTf twkV/dLbZ2dOIA7rxnS9EWY7mV9lstMrFuN8AhnnTv2I7mCeIghh0Ler/mih9FeEl0ff Thbw== X-Gm-Message-State: AIkVDXJgNB1g6md8ZaKrmn7Rqha12XuT1RGbyOA5JQGU59aBxMk1z6QwqwpcGGIqMAyXrMoMmK1Vs0yDq2wLkA== X-Received: by 10.129.183.39 with SMTP id v39mr1564740ywh.266.1486223441449; Sat, 04 Feb 2017 07:50:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 07:50:41 -0800 (PST) Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 07:50:41 -0800 (PST) In-Reply-To: References: From: Steve Lhomme Date: Sat, 4 Feb 2017 16:50:41 +0100 Message-ID: To: Reto Kromer Content-Type: multipart/alternative; boundary=94eb2c117c7648e3600547b65c3e Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 15:50:44 -0000 --94eb2c117c7648e3600547b65c3e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 4 f=C3=A9vr. 2017 16:09, "Reto Kromer" a =C3=A9crit : Steve Lhomme wrote: >In general we need to tell in the Matroska very clearly how >it works between the codec and the container. Indeed. >IMO the >sensitive way to do it is leave it to the codec when it >knows, and put it in the container when the codec doesn't >have the information. When it is found in the container AND >in the codec, it should mean that the container decided to >override whatever the codec says. Sorry, Steve, I am personally not convinced. From a previous discussion I have understood that when both the container and the codec hold an information, then the codec should have the precedence, because the probability it is kept safe during a trans-muxing is per se much higher. IMO it's either preserved or lost but the chance of being modified by accident during remuxing should be low. If by design it must be there only to change the value of the codec (that would include non existent value) then losing it or changing it means the muxer is broken. Now if the question is whether FFV1 should store it or Matroska, I would say FFV1. In the container it should be to alter it or provide the information that isn't known from that codec (like raw video or audio). Just my thoughts, as I started doing so for our own restoration applications (using NUT, not Matroska, but the principle seems to me to be the same). Reto AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: https://reto.ch | Twitter: @retoch _______________________________________________ Cellar mailing list Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar --94eb2c117c7648e3600547b65c3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Le=C2=A04 f=C3=A9vr. 2017 16:09, "Reto Kromer" <lists@reto.ch> a =C3=A9crit=C2=A0:
Ste= ve Lhomme wrote:

>In general we need to tell in the Matroska very clearly how
>it works between the codec and the container.

Indeed.

>IMO the
>sensitive way to do it is leave it to the codec when it
>knows, and put it in the container when the codec doesn't
>have the information. When it is found in the container AND
>in the codec, it should mean that the container decided to
>override whatever the codec says.

Sorry, Steve, I am personally not convinced. From a previous
discussion I have understood that when both the container
and the codec hold an information, then the codec should
have the precedence, because the probability it is kept safe
during a trans-muxing is per se much higher.

IMO it's either prese= rved or lost but the chance of being modified by accident during remuxing s= hould be low.=C2=A0

If b= y design it must be there only to change the value of the codec (that would= include non existent value) then losing it or changing it means the muxer = is broken.=C2=A0

Now if = the question is whether FFV1 should store it or Matroska, I would say FFV1.= In the container it should be to alter it or provide the information that = isn't known from that codec (like raw video or audio).=C2=A0

Just my thoughts, as I started doing so for our own
restoration applications (using NUT, not Matroska, but the
principle seems to me to be the same). Reto


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

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

--94eb2c117c7648e3600547b65c3e-- From nobody Sat Feb 4 07:51: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 C731B129418 for ; Sat, 4 Feb 2017 07:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 k-xAv8MJja8N for ; Sat, 4 Feb 2017 07:51:25 -0800 (PST) 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 64F24124281 for ; Sat, 4 Feb 2017 07:51:25 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id l19so28482019ywc.2 for ; Sat, 04 Feb 2017 07:51:25 -0800 (PST) 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=TKlxYIx2boQGrY7MR8gzaNlxdpF5hapF4OaMS/KdYN8=; b=p+a1sCNE0vgYOnjIb8ooPtYJ0s+AvMiW+jpYu4I2hKoPNtWyEFmn4x2WKsvOes7vNQ US0j2Sm5dEDQtkRmcFEic/fZeV5HrNabo+KhMKeFe3odAfKlUrpaatLmmKjTVLejkO3f KUhtdt5m8p41Sf1Wpye5EI0dBLXqsI7JldByW5sPrBWPoGCIshhO7Xag6K+ldLKDq2qQ Qr0TTolHM67IjpGXDb5WrfXsiDVpOlDBe4e2YQJYAlnHn45s5BxFjajiIwyl8IoJifez FCMNNFF/FBRD+cT5ehkD41YjwRpoU7Y7uK/6lm0z8n2YkF818yGDAXzL4ljgjAyyJtj6 dtJQ== 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=TKlxYIx2boQGrY7MR8gzaNlxdpF5hapF4OaMS/KdYN8=; b=h0D9f+WHq/dYNAV12mUYwPQoDqPIOuqDJso03mrOWZ4ycpkNSR65i18F26xlhIzlxV jjslPAZC2exQPX9XBy6FuHxFUHuLvKxFqj3OSagD7QtUkF2rfeTkzbUBNuuvgGZ7M/Eq k9QB7SR6h/bCudXX6k3I/k1ayIJ4Z3eT4iiJe69dVRTP5zyc6AVOyNDC+RUPtbntdpVQ Vm+qJeuXYO3KEcTe0p7Ob0pSxYOnrHK6boYDsCdnW4x1jq/IOOIrm+KIWlGPVAlJErtF TrefJvCPWC/0v7KlhhOq6q3vA51JDDzUPVxvq8Ca9x3Zijcxv+8RKTV7GFb4XKvdvRMp ZIAg== X-Gm-Message-State: AMke39mrnMWZNc7M81m1Sk3MFaDx1qKf8fqhdB8zUm/Bq1mwiCF4GhEnLaYy2jjD46ZQ7p634WVLJDlAD1ZWaQ== X-Received: by 10.13.196.129 with SMTP id g123mr1549872ywd.17.1486223484616; Sat, 04 Feb 2017 07:51:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 07:51:23 -0800 (PST) Received: by 10.83.46.203 with HTTP; Sat, 4 Feb 2017 07:51:23 -0800 (PST) In-Reply-To: <41FEE115-519D-4633-8A26-6FFE8C1897D4@dericed.com> References: <41FEE115-519D-4633-8A26-6FFE8C1897D4@dericed.com> From: Steve Lhomme Date: Sat, 4 Feb 2017 16:51:23 +0100 Message-ID: To: Dave Rice Content-Type: multipart/alternative; boundary=001a114d80fcdb893c0547b65e93 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Reto Kromer Subject: Re: [Cellar] The Reel Thing X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 15:51:27 -0000 --001a114d80fcdb893c0547b65e93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Given the time and location I should be able to go. Le 4 f=C3=A9vr. 2017 16:46, "Dave Rice" a =C3=A9crit : > +1. Sorry I can not be there, but I can help prep a presentation from afa= r. > Dave > > On Feb 4, 2017, at 10:44 AM, Steve Lhomme wrote: > > If you want we can try to present something together. On my own I'm not > sure I would be the right one for the crowd. > > Le 4 f=C3=A9vr. 2017 16:12, "Reto Kromer" a =C3=A9crit : > >> Steve Lhomme wrote: >> >> >Not AFAIK but that's tempting. >> >> Please allow me an update. >> >> If we decide to propose something, then it should happen >> very fast, because I know that during this coming week they >> are meeting for the programme's content. >> >> On my side I am hesitating. >> >> Best regards, Reto >> >> >> AV Preservation by reto.ch >> chemin du Suchet 5 | 1024 Ecublens | Switzerland >> Web: https://reto.ch | 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 > > > --001a114d80fcdb893c0547b65e93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Given the time and location I should be able to go.=C2=A0=

Le=C2=A04 f= =C3=A9vr. 2017 16:46, "Dave Rice" <dave@dericed.com> a =C3=A9crit=C2=A0:
= +1. Sorry I can not be there, but I can help prep a presentation from afar.=
Dave

On Feb 4, 2017= , at 10:44 AM, Steve Lhomme <slhomme@matroska.org> wrote:

If you wa= nt we can try to present something together. On my own I'm not sure I w= ould be the right one for the crowd.=C2=A0
=
Le=C2=A04 f=C3=A9vr. 2017 16:12, "Reto = Kromer" <lists@r= eto.ch> a =C3=A9crit=C2=A0:
Steve Lhomme wrote:

>Not AFAIK but that's tempting.

Please allow me an update.

If we decide to propose something, then it should happen
very fast, because I know that during this coming week they
are meeting for the programme's content.

On my side I am hesitating.

Best regards, Reto


AV Preservation by reto.ch
chemin du Suchet 5 | 1024 Ecublens | Switzerland
Web: http= s://reto.ch | 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

--001a114d80fcdb893c0547b65e93-- From nobody Sat Feb 4 07:59:40 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 27F3A129B27 for ; Sat, 4 Feb 2017 07:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[SPF_NEUTRAL=0.652] 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 85ydUXjgHJnM for ; Sat, 4 Feb 2017 07:59:38 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93E6129B9F for ; Sat, 4 Feb 2017 07:59:37 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:48293 helo=[10.0.1.12]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1ca2kS-0035hr-DA for cellar@ietf.org; Sat, 04 Feb 2017 10:59:37 -0500 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\)) Message-Id: Date: Sat, 4 Feb 2017 11:00:52 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission 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: [Cellar] define FFV1 in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 15:59:39 -0000 Hi cellar, I submitted this pull request to define an FFV1 Codec Mapping for = Matroska, = https://github.com/Matroska-Org/matroska-specification/pull/94. = Currently all FFV1 in Matroska uses the V_MS/VFW/FOURCC Mapping. In = addition to what is listed below I think the V_MS/VFW/FOURCC definition = may need to be extended to say that when V_MS/VFW/FOURCC is used for = FFV1, and the FFV1 is version 3 or greater, then the BITMAPINFOHEADER = MUST have the Configuration Record as Private Data. Comments? Is it advantageous to define this when V_MS/VFW/FOURCC is = already the practice? Here is the text of the proposed Codec Mapping: ### V_FFV1 Codec ID: V_FFV1 Codec Name: FF Video Codec 1 Description: FFV1 is a lossless intra-frame video encoding format = designed to efficiently compress video data in a variety of pixel = formats. Compared to uncompressed video, FFV1 offers storage = compression, frame fixity, and self-description, which makes FFV1 useful = as a preservation or intermediate video format. [Draft FFV1 = Specification](https://datatracker.ietf.org/doc/draft-niedermayer-cellar-f= fv1/) Initialisation: For FFV1 versions 2 or less, `Private Data` SHOULD NOT = be written. For FFV1 version 3 and greater, the `Private Data` MUST = contain the FFV1 Configuration Record structure, as defined in = https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-01#section-4.1, = and no other data. Dave Rice From nobody Sun Feb 5 03:33:28 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 1D73F1294C3 for ; Sun, 5 Feb 2017 03:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6N0E6HWcGBZL for ; Sun, 5 Feb 2017 03:33:25 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE27F120724 for ; Sun, 5 Feb 2017 03:33:25 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id l19so35571429ywc.2 for ; Sun, 05 Feb 2017 03:33:25 -0800 (PST) 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=eeQN3s1I6rxaCjH51OBe+kDGJCrkctOIeuMhNi5ncfk=; b=NbNzdtUlfo+7mPAtVzbayJ02BlWc08F+CVzzu5Qb2iKRWdNgn5X+lwlrlB2YuvJQUn H+I8bb5vdTjkhF2zxejs9ZysFV/UEdKKOtlasKMQZluB/jjJmSVzO2o/xyxxkB3+9Mtl +2LIMDKJjCpZly6wow9B0mHDUnRBpYnEQV1OWyzm2vYGwAoNJFiSU4ecBBirBTv+vShp 6Mdp9NY9XoxNtmPbJecIyPAedMP+/gx8KuVPbKNcnejcaaGiiGv0tD0pUgcOVyIV6hVF EKnZ5P5zCn1/c1hOOzE4VTltrLp3G6lt3sdAXJavObDnt1PHRhX1dmG+KpOiDpMEKnId gj/w== 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=eeQN3s1I6rxaCjH51OBe+kDGJCrkctOIeuMhNi5ncfk=; b=KRqprweiglcc5z9d4H81xNC+e9aw0xu7fO7ov8OAaYWl+tnamtH7wZmoP0BzhNdAxV H9YgQNxMlOHPNwVU9mywm9qcQkTAAEx/jlNhlf0SzZttXb3SAYde6Xx7oMl6nDhAmn/L FvQUsyrk/LOZZ7Q+svSLp6XN20Wd9Qo2JGtwc/4vYx7r5lDDh0UCcmF30SZvGvrFKOj8 jbZyKPY/e4cYep8zhgNX2oJckzAGKXNMgLJniIGMzBbDCvo2SvVTwdhpatv9+57w98Xz Zw09JUEx5VJ6P9MZVYH72i23utvO2jK/eNuimfb8paVo0NqWNNd0HzSFhUENVn15Y5do XUMQ== X-Gm-Message-State: AIkVDXJj87+paPPyuCj2/gRt3MqpQizlsChoKRS/sZ0UAMMZCHfhYkiei2qFCp2ThKt9YrbGChC4BjIb/3eeYg== X-Received: by 10.13.198.2 with SMTP id i2mr3502325ywd.201.1486294404857; Sun, 05 Feb 2017 03:33:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sun, 5 Feb 2017 03:33:24 -0800 (PST) In-Reply-To: References: From: Steve Lhomme Date: Sun, 5 Feb 2017 12:33:24 +0100 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] define FFV1 in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 11:33:27 -0000 2017-02-04 17:00 GMT+01:00 Dave Rice : > Hi cellar, > > I submitted this pull request to define an FFV1 Codec Mapping for Matrosk= a, https://github.com/Matroska-Org/matroska-specification/pull/94. Currentl= y all FFV1 in Matroska uses the V_MS/VFW/FOURCC Mapping. In addition to wha= t is listed below I think the V_MS/VFW/FOURCC definition may need to be ext= ended to say that when V_MS/VFW/FOURCC is used for FFV1, and the FFV1 is ve= rsion 3 or greater, then the BITMAPINFOHEADER MUST have the Configuration R= ecord as Private Data. > > Comments? Is it advantageous to define this when V_MS/VFW/FOURCC is alrea= dy the practice? The VFW codecs should only be for codecs that were primarily found as Video For Windows codecs, with much less else documentation. For new formats and/or formats with proper documentation we should use a properly named mapping. So V_FFV1 is a lot better. > Here is the text of the proposed Codec Mapping: > > ### V_FFV1 > > Codec ID: V_FFV1 > > Codec Name: FF Video Codec 1 > > Description: FFV1 is a lossless intra-frame video encoding format designe= d to efficiently compress video data in a variety of pixel formats. Compare= d to uncompressed video, FFV1 offers storage compression, frame fixity, and= self-description, which makes FFV1 useful as a preservation or intermediat= e video format. [Draft FFV1 Specification](https://datatracker.ietf.org/doc= /draft-niedermayer-cellar-ffv1/) > > Initialisation: For FFV1 versions 2 or less, `Private Data` SHOULD NOT be= written. For FFV1 version 3 and greater, the `Private Data` MUST contain t= he FFV1 Configuration Record structure, as defined in https://tools.ietf.or= g/html/draft-niedermayer-cellar-ffv1-01#section-4.1, and no other data. LGTM. > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 5 03:36:22 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3B41294C3 for ; Sun, 5 Feb 2017 03:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 LIJefHW7KHzT for ; Sun, 5 Feb 2017 03:36:18 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5216A1293FF for ; Sun, 5 Feb 2017 03:36:18 -0800 (PST) Received: from mfilter13-d.gandi.net (mfilter13-d.gandi.net [217.70.178.141]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 8E327A80C8 for ; Sun, 5 Feb 2017 12:36:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter13-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter13-d.gandi.net (mfilter13-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Sl0fBPz2N89W for ; Sun, 5 Feb 2017 12:36:15 +0100 (CET) X-Originating-IP: 213.47.41.20 Received: from localhost (213-47-41-20.cable.dynamic.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 13448A80C2 for ; Sun, 5 Feb 2017 12:36:13 +0100 (CET) Date: Sun, 5 Feb 2017 12:36:11 +0100 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20170205113611.GD5794@nb4> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZJcv+A0YCCLh2VIg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] define FFV1 in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 11:36:20 -0000 --ZJcv+A0YCCLh2VIg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 05, 2017 at 12:33:24PM +0100, Steve Lhomme wrote: > 2017-02-04 17:00 GMT+01:00 Dave Rice : > > Hi cellar, > > > > I submitted this pull request to define an FFV1 Codec Mapping for Matro= ska, https://github.com/Matroska-Org/matroska-specification/pull/94. Curren= tly all FFV1 in Matroska uses the V_MS/VFW/FOURCC Mapping. In addition to w= hat is listed below I think the V_MS/VFW/FOURCC definition may need to be e= xtended to say that when V_MS/VFW/FOURCC is used for FFV1, and the FFV1 is = version 3 or greater, then the BITMAPINFOHEADER MUST have the Configuration= Record as Private Data. > > > > Comments? Is it advantageous to define this when V_MS/VFW/FOURCC is alr= eady the practice? >=20 > The VFW codecs should only be for codecs that were primarily found as > Video For Windows codecs, with much less else documentation. For new > formats and/or formats with proper documentation we should use a > properly named mapping. So V_FFV1 is a lot better. +1 [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad --ZJcv+A0YCCLh2VIg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAliXDisACgkQYR7HhwQLD6vYdACcDWu+uMUFHpEhlcjpr+Xzruav 7twAnjDjj0PvJ4UtdG9laYdSpaZQUOIJ =dATq -----END PGP SIGNATURE----- --ZJcv+A0YCCLh2VIg-- From nobody Sun Feb 5 04:13: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 681E512956A for ; Sun, 5 Feb 2017 04:13:45 -0800 (PST) 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 VurLs7gq6yHT for ; Sun, 5 Feb 2017 04:13:43 -0800 (PST) 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 68F2512955E for ; Sun, 5 Feb 2017 04:13:43 -0800 (PST) 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 v15CDehJ031984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sun, 5 Feb 2017 13:13:40 +0100 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 v15CDemv039780 for ; Sun, 5 Feb 2017 13:13:40 +0100 Date: Sun, 5 Feb 2017 13:13:40 +0100 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: <20170205113611.GD5794@nb4> 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] define FFV1 in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 12:13:45 -0000 Michael Niedermayer wrote: >> > Comments? Is it advantageous to define this when >> > V_MS/VFW/FOURCC is already the practice? >>=20 >> The VFW codecs should only be for codecs that were >> primarily found as Video For Windows codecs, with much >> less else documentation. For new formats and/or formats >> with proper documentation we should use a properly named >> mapping. So V_FFV1 is a lot better. > >+1 +1 Best regards, Reto From nobody Sun Feb 5 05:59:16 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A13D129412 for ; Sun, 5 Feb 2017 05:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2sCU6OFVmOE for ; Sun, 5 Feb 2017 05:59:12 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6B5127601 for ; Sun, 5 Feb 2017 05:59:12 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id o65so18813165ybo.2 for ; Sun, 05 Feb 2017 05:59:12 -0800 (PST) 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=sNZYDvtdIzGUctdCT9KjWdn60fW+0V4tZSmdcyFbjhg=; b=tlbIS2YF4gftu0F/zPQMzRCQ6y9kyZHgO++wDBB2xU6GZd8oAwBSQDIZliguyLz29w zAyfGNwRFdWYEWWnudvIqpXhQsmpo5ZA1i5XEbbQonPUXQqPtkPevLFurbKkVmZuYDlM FvWAIgsCuam+1hnvBhwLNq3VyBBPl1M6KfuFeD1FT3ZjYFHWHBAHKQfKs6zdSSxXYZRI 5ngTiLNxD/rdRk/D0Pkkq2knzRSUJJqYrn9GymdkUGhausEDEwD9Mq5ZFey35u8AJqF3 o+5ZUUMOJvMviWOh52EU2vOFxv+y257NXy9DL64zeTydFV9BYQ2YIfMxYZTNiDnTahFq sg0g== 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=sNZYDvtdIzGUctdCT9KjWdn60fW+0V4tZSmdcyFbjhg=; b=QgLqBeX/XWoCU1ZJpx1IPTyb+vRzEqPGhm/aaCrMmnkk5sP7oNfumrxYSDO3SlXaUG YP7Tlc7kktRvfXTRkFahOPSliOLYA5fDPfMcyYEzI9lYvg5c+anQi1WMLErOXfetNfB1 cgaDJ5qZVOk29+o3LRgdW54NHb982rD7WQhqaeYqz7uBHosV3sD5+Rc9QVDBMcG9lW1/ yULRxT83siOyhf9J6YGMe82U1XdE/xoVva6Ej+ttJQurmImHhke+u6Sl1PYiIjtcTzay 0jKIg20/Lhnl77/Q0HGcZg3cTdx0g/emBe/AFUksW0x+MDPo6TWcg1huwt8x5Ys6Lk2a eY/w== X-Gm-Message-State: AMke39ngApkoJsSrV16hZnj1JPcmLQ1hA02b8agWrm3V+NIpEv4rgEWfU2QRuUoxTE3cgaIZ5BAfI295b6QYbA== X-Received: by 10.37.88.5 with SMTP id m5mr4006783ybb.7.1486303151302; Sun, 05 Feb 2017 05:59:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sun, 5 Feb 2017 05:59:10 -0800 (PST) In-Reply-To: References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> <402d0e5e-4e64-2341-9a0d-a18d56a7d2c1@mediaarea.net> From: Steve Lhomme Date: Sun, 5 Feb 2017 14:59:10 +0100 Message-ID: To: Jerome Martinez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Rationale Numbers for timestamps X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 13:59:14 -0000 I'll try to summarize the proposition as I understood it and how it applies to real world example. - We would keep the current TimecodeScale (TimestampScale) as it is to scale from 1ns to something that gives enough range in a Cluster (65536 values of 1ns * TimestampScale). The current default for TimestampScale is 1.000.000 so that each tick (Block sample start) has a 1ms precision (65s per Cluster with that amount). - the worst case (from previous emails) seem to be sample precision for 192kHz audio. That would need 5.2 =C2=B5s precision. To achieve that the TimestampScale would be around 5.000, giving a maximum Cluster duration to 0.341ms which is probably not desirable. Given these data are usually packed a factor of 8 sample per block seem reasonable enough. That gives a 2.7s duration for a Cluster which is reasonable for streaming and resilience. - There are cases where using the same tick with both clocks might create some rounding issues. Because the tick basis is the nanosecond one, and it's usually not in a multiple of each channels' clock, and we need a reasonable range for the Cluster, the precision is not a nanoseconds but usually in 1ms (default values). Even 1ms is not good enough for videos that have 30000/1001 timestamps (29.970029.. ms per frame). - The new system would work in parallel, reusing the same ticks but using a rationale clock specific to each track. - The chapter times are stored in non scaled format, ie in nanoseconds. So we can be sample precise (with some rounding) for 192kHz sources easily. Given that I made a short simulation of timestamps for a 30000/1001 video stream. https://docs.google.com/a/matroska.org/spreadsheets/d/1az-uc2= Niklvm7Cy9fSpXGMIlWISUxlmwMboUFpY96sE/edit?usp=3Dsharing It turns out that the rounding we apply between the original timestamp and the 1ms precision shifts the tick by minus one every ~34 frames. So you increase the tick by 30 every frame but every 34 frame you increase the tick by 29. Because of that the difference between the Matroska clock and the pure rationale clock keeps drifting. This drift cannot be represented by a bit. We do have at least 3 bits available in SimpleBlock and Block. Given us 7 possible drifts allowed in a single Cluster. From my example that allows 250 frames or 7.5s. That's ample enough. We still have to study the effect of reducing the TimestampScale to be closer to the duration per frame and for audio. One thing we need to take in account though is if it's going to create problems when remuxing and cutting. Since the rounding compensation is done on one basis for 0.0. If you cut a few frames the rounding will probably need to be adjusted by the same number of frames. On the other hand a muxer that is not aware of this system will drop it and only the old value remains. A muxer that is aware will not that the correct timestamp is the one from the rationale value and should compute the tick value from that. 2017-02-04 16:36 GMT+01:00 Steve Lhomme : > Ok, I remember now. That sounds usable then. > > Le 4 f=C3=A9vr. 2017 16:34, "Jerome Martinez" a = =C3=A9crit : >> >> On 04/02/2017 15:39, Steve Lhomme wrote: >>> >>> [...] >>> I'm not sure I follow the math but using a flag in the >>> SimpleBlock/Block sounds interresting. But in effect wouldn't all >>> blocks have either 1 or 0 from a muxer version ? In that case it would >>> just mean the rationale timecode system should be used, if the demuxer >>> can deal with it. And basically that would mean it should be used if >>> present. Do we need to extra flag for that ? >> >> >> In previous discussions there were some concerns about when a muxer star= ts >> to mux with constant frame rate config but the "real time" feeding chang= es >> during muxing and it is no more with this frame rate, the "rouding" woul= d be >> still there from a demuxer point of view without the flag; >> This flag is an answer to this concern, the algo can be deactivated duri= ng >> muxing even if it is not possible to change the Matroska header e.g. liv= e >> stream. >> >> > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 5 15:21:40 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 62509129A7A for ; Sun, 5 Feb 2017 15:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rJyF10lwpsn for ; Sun, 5 Feb 2017 15:21:36 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE65B12950C for ; Sun, 5 Feb 2017 15:21:36 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:38684 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 1caW7c-000XLT-4M for cellar@ietf.org; Sun, 05 Feb 2017 18:21:36 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_EBBC1A6C-7862-4AFD-9125-09563AA9652D" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <04A7F638-0E15-4949-BB49-98BD88082667@dericed.com> Date: Sun, 5 Feb 2017 18:21:25 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3259) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] mkv ColourSpace and uncompressed video X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 23:21:38 -0000 --Apple-Mail=_EBBC1A6C-7862-4AFD-9125-09563AA9652D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi cellar, I=E2=80=99m hoping to clarify the use of uncompressed video in Matroska = and find a way to avoid muxing errors such as = https://github.com/FFmpeg/FFmpeg/blob/8c1342e631d635f6cad13f9374c4f2005c22= b9e5/libavformat/matroskaenc.c#L1117-L1118 = . Currently Matroska supports a Codec ID of V_Uncompressed which relies on = the ColourSpace Element to detail how the uncompressed video is stored. = There is not much documentation here but the ColourSpace references a = value in AVI (which seems to be the biCompression value of = BITMAPINFOHEADER. I=E2=80=99d like to clean up this documentation but = would like something more clear than a vague reference to AVI. Is there a reliable authority of fourcc=E2=80=99s that we can reference = to uncompressed video or should ColourSpace be defined with an = enumeration list which provides a list of value (such as I420, NV12, = NV21, RGBA, UYVY, Y41B, Y42B, Y800, YUV9, YUY2, YVYU) along with their = definitions? Also I can only find occasions of ColourSpace used when the Codec is = V_Uncompressed. Are there instances when it is valid to use ColourSpace = when the Codec ID is not V_Uncompressed. Was there any reason that = ColourSpace was used to store the fourcc, rather than using CodecPrivate = as done with VFW? Dave Rice= --Apple-Mail=_EBBC1A6C-7862-4AFD-9125-09563AA9652D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi cellar,

I=E2=80=99m hoping to clarify the use = of uncompressed video in Matroska and find a way to avoid muxing errors = such as https://github.com/FFmpeg/FFmpeg/blob/8c1342e631d635f6cad13f937= 4c4f2005c22b9e5/libavformat/matroskaenc.c#L1117-L1118.

Currently Matroska = supports a Codec ID of V_Uncompressed which relies on the ColourSpace = Element to detail how the uncompressed video is stored. There is not = much documentation here but the ColourSpace references a value in AVI = (which seems to be the biCompression value of BITMAPINFOHEADER. I=E2=80=99= d like to clean up this documentation but would like something more = clear than a vague reference to AVI.

Is there a reliable authority of = fourcc=E2=80=99s that we can reference to uncompressed video or should = ColourSpace be defined with an enumeration list which provides a list of = value (such as I420, NV12, NV21, RGBA, UYVY, Y41B, Y42B, Y800, YUV9, = YUY2, YVYU) along with their definitions?

Also I can only find occasions of = ColourSpace used when the Codec is V_Uncompressed. Are there instances = when it is valid to use ColourSpace when the Codec ID is not = V_Uncompressed. Was there any reason that ColourSpace was used to store = the fourcc, rather than using CodecPrivate as done with VFW?

Dave = Rice
= --Apple-Mail=_EBBC1A6C-7862-4AFD-9125-09563AA9652D-- From nobody Sat Feb 11 07:44:43 2017 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AFB12988D; Sat, 11 Feb 2017 07:44:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148682788214.11049.197934725191715820.idtracker@ietfa.amsl.com> Date: Sat, 11 Feb 2017 07:44:42 -0800 Archived-At: Cc: tterriberry@mozilla.com, ben@nostrum.com, cellar@ietf.org, cellar-chairs@ietf.org Subject: [Cellar] cellar - Not having a session at IETF 98 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 15:44:42 -0000 Tim Terriberry, a chair of the cellar working group, indicated that the cellar working group does not plan to hold a session at IETF 98. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Mon Feb 13 22:46: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 85A4212947A for ; Mon, 13 Feb 2017 22:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 O7KA0C3OsffQ for ; Mon, 13 Feb 2017 22:46:54 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E88F12940E for ; Mon, 13 Feb 2017 22:46:53 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id k127so74689006vke.0 for ; Mon, 13 Feb 2017 22:46:53 -0800 (PST) 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=Empa3go30k2SEFhXN+953ACNL0pLjwPmrTEMc+U5t1U=; b=UVWRt2Ly9YWXYAV+GqCfMzQbOqdnEdlkjbJFpoCALL7q+wHuTZGnJcN2fdwzA/wLmh VwbySdC6KiTXAmWPfY7goK5AkJzPz6Ek8zNhpWGFUjIrhwrpuvsiw8iS1omixf4fMkiC z9PCbfc7jfi7t+4hKbRpjoJZ3sFc7i43PHCMdbYkyAFPbSpH6PkT2wonuqOJKSuxxso6 UrnTrEqRVk6Xpdpk/shPb6tcfbqgFdbac+0/W4BvjQe2Gvy8AMdNreYs8YpTU1OF2ue/ QtLaIHp3yRJfcycQuIfWHB7+MHYVlm5HaR+dcg4nPglr/BhqD359wW3Gi0LbBz4ofTwa eUmw== 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=Empa3go30k2SEFhXN+953ACNL0pLjwPmrTEMc+U5t1U=; b=jt7zwIGiWshyMxMMybcqWW34DcdxDD3vNrLBi1Cp5zIuW7sK3mCfM9oJLU5STXW5eT hA5qC7CrJIxbovvUHCfdh9kYa1oz+7sC0BsxAbcAaDh6/22G3VujhqgvKRIekhh9M8oE OD3T84S/7bl7VFQBbqLaS9w73q/SejWTKrTU+/z6dfXO06Ru/mcHs75cwkXA7A9ilMoZ i3I8Bs05Z0TGTrpEfoDMBhRO9/k3EUlHq0c/5pf+2GO1Nz29t+MGnM/YIvLF/knLTH3u Ibn4lMsFJp2jF/XSG4yvBMuF8xcagGHmXgdjasltJsxQUlhpLMHoKqDHDznC+mQKFvJ1 cMNA== X-Gm-Message-State: AMke39n8qQAyFah6xgyVMvw2oFYIVuOwobIih1XOhzj+sxO+S1xtsFpRI+yIq8pOpAIJcvoFkP7ndwr94oajWw== X-Received: by 10.31.58.215 with SMTP id h206mr11642747vka.164.1487054812887; Mon, 13 Feb 2017 22:46:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.102.196 with HTTP; Mon, 13 Feb 2017 22:46:52 -0800 (PST) From: Matt Gruenke Date: Tue, 14 Feb 2017 01:46:52 -0500 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a114407d4e24275054877edae Archived-At: Subject: [Cellar] CodecIDs for non-standard and unregistered data formats X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 14 Feb 2017 06:46:55 -0000 --001a114407d4e24275054877edae Content-Type: text/plain; charset=UTF-8 Related to my recent query about TrackTypes for non-standard data formats, I'd like to discuss CodecIDs. I had previously raised this issue, on the matroska-devel list, and was advised to take it up, here. In the interim, my thinking on the matter has evolved. I wonder why not allow IANA Media Types (aka MIME types), as a sub-class of CodecIDs? Of course, the official Matroska CodecID would be preferred, for all formats for which one has been designated. However, this would enable broader use of Matroska files, including for private, application-specific data stream formats. Perhaps a prefix like 'X_MEDIATYPE/' could simply be prepended to media type names conforming with RFC 6838. The value of TrackType would still determine whether video, audio, or any other type-specific elements can be used in such tracks. Thank you for considering my suggestion. Matt --001a114407d4e24275054877edae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Related to my recent query about TrackTypes for non-standa= rd data formats, I'd like to discuss CodecIDs.=C2=A0 I had previously r= aised this issue, on the matroska-devel list, and was advised to take it up= , here.=C2=A0 In the interim, my thinking on the matter has evolved.
I wonder why not allow IANA Media Types (aka MIME types), as a= sub-class of CodecIDs?=C2=A0 Of course, the official Matroska CodecID woul= d be preferred, for all formats for which one has been designated.=C2=A0 Ho= wever, this would enable broader use of Matroska files, including for priva= te, application-specific data stream formats.

Perh= aps a prefix like 'X_MEDIATYPE/' could simply be prepended to media= type names conforming with RFC 6838.=C2=A0 The value of TrackType would st= ill determine whether video, audio, or any other type-specific elements can= be used in such tracks.

Thank you for considering= my suggestion.


Matt
=
--001a114407d4e24275054877edae-- From nobody Sun Feb 19 05:17:12 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE081294C2 for ; Sun, 19 Feb 2017 05:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 7L5yZBpy0MBl for ; Sun, 19 Feb 2017 05:17:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 0311A129409 for ; Sun, 19 Feb 2017 05:17:07 -0800 (PST) Received: from [192.168.178.25] ([91.47.56.201]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MFuC6-1cci4k3plW-00ErR8 for ; Sun, 19 Feb 2017 14:17:05 +0100 To: cellar@ietf.org References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> <402d0e5e-4e64-2341-9a0d-a18d56a7d2c1@mediaarea.net> From: hubblec4 Message-ID: <62a09f2e-27ab-48e0-f7e1-afe909fec5c9@gmx.ch> Date: Sun, 19 Feb 2017 14:17:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E50D534D1A5899545BA48B7E" X-Provags-ID: V03:K0:G1KVHAJqqhmzFms1IwfZfswhQNl5ky7ow33V8lo3tM5EaCl+AFb tv+bicmRhAgt4aDUzmTbce7VT2auH8hBI1d1IVTy6BIUGezkVUNEhk+XsBjMUCBx/cPD7Yt 2UY9+bschwB7kbNtc+pdEr/5wLNcN7rRYusffltXklyj59u1y65DLOTWhIQZTJ26/+r8pwm X4ma3Nai/1AArKdJV4KJg== X-UI-Out-Filterresults: notjunk:1;V01:K0:KwreerZEH8g=:YLKAHpf/DwAX1pBRsX/4jt 3JiZmDcjRx2ue934qliu/QJ8Zd6552EYj1YSfl5Bv8oHWNvO8D461J5O17bZ74KRlSUmEw7pV oLcbfb6rp/3fwBNzukAi6jsLzF40XmkjvDhTxxZMS2J8xh0fBaMYlIX6+6Myy3Jc+o3xudwwN K6aSmDWkohVFzFQjvPtoDDqIblPIAlz7dMd3FXLtioTvqon0v+FwPnJwOolz6kaStszQ+SYdF FuSfgPKmteKVxIjQhkdZD2dJJyOyvjGrlwZXgIvr2K7kOIcIxFcrL405hN/bPFUEnx+UpvEep k7CoJZXQdrf5/sybSVIJyAU4FDD+sLfbRudS29y1P2DV5jrg/NSjYUEOM4rqHTLCEURYuD9cu Lwt/c1l7Ku7PIFcg5RzPYUEIUJ/Jj7quGl4arwlY5FYdsRykU1t3LM0NfmwBj/3ZNnEeqt+Ae GSd/3/HYTWiudwNX+CqaIqI4lnrPtTHoMX5C2uJPL1YyAMmOA+WW41Cd9jCmKgqsypvgXFW/S /UDkZ3lGnlVA3uOieSbP7ueqrgIiCkp9/XNjtVUsKny2lcL6Lw3JBir7Y6+L3rMJfpumV1bO3 uZaTXY9LmDEUUCt5KZuLV9y/4lSq44UAb7wPyCeCCXFQdfqLVIudfXICJz/C3l8WyaPXvH1aB ZRqbM4V/TpoUHgePA4iot3/kz3Q3ED5nKNJRDzFIvyxZplCm4BcXeC4/o6ryZEPdAIOURtqEh I+eqTaVkzxpqR6dzIU4X/GzVe5fXL54RxKjr0Q+zpMM7Vi0XLNzYNpc1i5CmykJIDKKMXUFCB qdmMl6G Archived-At: Subject: [Cellar] Matroska Chapters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 13:17:10 -0000 This is a multi-part message in MIME format. --------------E50D534D1A5899545BA48B7E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all I hope this topic is not too boring and we can improve/implement important "use" notes. In my chapterEditor thread was a topic "chapter.xml from makemkv" which generate non-ordered chapters with end time stamps. So far known to me there is no splitter which read the end times of non-ordered chapters. In Mosu's new Chapter Editor is it not more possible to set the start times equal to the end times. The DVDMenuXtractor generate ordered chapters without an end time stamp. What is the correct behavior? My suggestions are: Data for non-ordered chapters can be set, but with a warning/info that this data will not be used. Ordered-chapter end times can be set to "empty", equal or greater as the start time but never smaller as the start time. The normal way: End times are greater as the start times. A new virtual timeline use this chapter and takes the play duration of this chapter into account. End time equal to start time: Lav splitter ignores such ordered chapters, cause the play duration is 0. Furthermore LAV-splitter recognized only Level 1 ordered chapters. For this I have three possible ways in my mind. 1. Only as chapter mark The chapter is shown to the user interface and you can jump to this point in the timeline. This is the same behaviour like ordered chapters from Level 2 and deeper. LAV-splitter ignores the "ordered" state and reads the start time only. 2. Use the ordered times from the nested ordered chapter (I prefer this option) Nested-ordered-endtimes is a topic where I can't find infos. My theorie is that such chapters must have then nested chapters and the first nested chapter start time must be the start/end time of the parent chapter. A splitter should read than the nested-ordered play duration an takes into acount. 3. Endless loop The frame which correspond to the start time of such a chapter is shown endless. We could simulate a behaviour for menu's like in DVD's/Bluray's. Some user option in the player could be prohibited. Empty end times: This can be found in DVDMenuXtractor menu.xml output. In principle we could use the same 3 possibilities here like for "End time equal to start time" Another EBML element which makes not right sense to me, is ChapterSegmentEditionUID[6E][BC]. When such an UID is specified, the splitter should play this edition from the linked segment. But an edition have not a start nor an end time! What is with the specified chapter start and end time? This chapter duration must than match as a sum of all chapter play durations of the linked edition. What is when in the linked edition has chapters with linking to other editions? Or is there an other method in use? Thanks for reading and sorry for my bad english. Best reagrds Martin _______________________________________________ Matroska-devel mailing list Matroska-devel@lists.matroska.org https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel Read Matroska-Devel on GMane:http://dir.gmane.org/gmane.comp.multimedia.matroska.devel --------------E50D534D1A5899545BA48B7E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi all

I hope this topic is not too boring and we can improve/implement important "use" notes.

In my chapterEditor thread was a topic "chapter.xml from makemkv" which generate non-ordered chapters with end time stamps. So far known to me there is no splitter which read the end times of non-ordered chapters.
In Mosu's new Chapter Editor is it not more possible to set the start times equal to the end times.
The DVDMenuXtractor generate ordered chapters without an end time stamp.

What is the correct behavior?

My suggestions are:
Data for non-ordered chapters can be set, but with a warning/info that this data will not be used.
Ordered-chapter end times can be set to "empty", equal or greater as the start time but never smaller as the start time.

The normal way:
End times are greater as the start times. A new virtual timeline use this chapter and takes the play duration of this chapter into account.

End time equal to start time:
Lav splitter ignores such ordered chapters, cause the play duration is 0.
Furthermore LAV-splitter recognized only Level 1 ordered chapters.
For this I have three possible ways in my mind.
1. Only as chapter mark
The chapter is shown to the user interface and you can jump to this point in the timeline. This is the same behaviour like ordered chapters from Level 2 and deeper. LAV-splitter ignores the "ordered" state and reads the start time only.

2. Use the ordered times from the nested ordered chapter (I prefer this option)
Nested-ordered-endtimes is a topic where I can't find infos. My theorie is that such chapters must have then
nested chapters and the first nested chapter start time must be the start/end time of the parent chapter.
A splitter should read than the nested-ordered play duration an takes into acount.

3. Endless loop
The frame which correspond to the start time of such a chapter is shown endless.
We could simulate a behaviour for menu's like in DVD's/Bluray's. Some user option in the player could be prohibited.

Empty end times:
This can be found in DVDMenuXtractor menu.xml output.
In principle we could use the same 3 possibilities here like for "End time equal to start time"


Another EBML element which makes not right sense to me, is ChapterSegmentEditionUID[6E][BC].
When such an UID is specified, the splitter should play this edition from the linked segment.
But an edition have not a start nor an end time!
What is with the specified chapter start and end time? This chapter duration must than match as a sum of all chapter play durations of the linked edition. What is when in the linked edition has chapters with linking to other editions?
Or is there an other method in use?


Thanks for reading and sorry for my bad english.

Best reagrds
Martin











_______________________________________________
Matroska-devel mailing list
Matroska-devel@lists.matroska.org
https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
--------------E50D534D1A5899545BA48B7E-- From nobody Tue Feb 21 07:38:16 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DDE129C32 for ; Tue, 21 Feb 2017 07:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 k2BoGF2pKg_6 for ; Tue, 21 Feb 2017 07:38:07 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E668C129585 for ; Tue, 21 Feb 2017 07:37:49 -0800 (PST) Received: from [146.96.19.240] (port=38637 helo=[10.10.201.45]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cgCVf-002iWf-F4; Tue, 21 Feb 2017 10:37:49 -0500 From: Dave Rice Message-Id: <435B0D9F-9514-4976-8F31-02660246A5FD@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3998F36A-E6DF-4808-9856-B001F5EF3286" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Tue, 21 Feb 2017 10:37:45 -0500 In-Reply-To: <62a09f2e-27ab-48e0-f7e1-afe909fec5c9@gmx.ch> To: hubblec4 References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> <402d0e5e-4e64-2341-9a0d-a18d56a7d2c1@mediaarea.net> <62a09f2e-27ab-48e0-f7e1-afe909fec5c9@gmx.ch> 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: Cc: cellar@ietf.org Subject: Re: [Cellar] Matroska Chapters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 21 Feb 2017 15:38:14 -0000 --Apple-Mail=_3998F36A-E6DF-4808-9856-B001F5EF3286 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, > On Feb 19, 2017, at 8:17 AM, hubblec4 wrote: >=20 > Hi all >=20 > I hope this topic is not too boring and we can improve/implement = important "use" notes. >=20 > In my chapterEditor thread was a topic "chapter.xml from makemkv" = which generate non-ordered chapters with end time stamps. So far known = to me there is no splitter which read the end times of non-ordered = chapters. > In Mosu's new Chapter Editor is it not more possible to set the start = times equal to the end times. > The DVDMenuXtractor generate ordered chapters without an end time = stamp. >=20 > What is the correct behavior? Good point. Is there any purpose to ChapterTimeEnd if the chapters are = non-ordered? Would it be fair to describe ChapterTimeEnd as only = relevant to playback if EditionFlagOrdered=3D1. > My suggestions are: > Data for non-ordered chapters can be set, but with a warning/info that = this data will not be used. This could be said within the specification. It's a bit much to request = that all Matroska editors also say it. > Ordered-chapter end times can be set to "empty", equal or greater as = the start time but never smaller as the start time. That makes sense to me, though is there any meaning of ChapterTimeStart = =3D ChapterTimeEnd? Is an empty ChapterTimeEnd semantically equivalent = to ChapterTimeStart =3D ChapterTimeEnd or equivalent to ChapterTimeEnd = of the last timestamp (or infinity)? > The normal way:=20 > End times are greater as the start times. A new virtual timeline use = this chapter and takes the play duration of this chapter into account. >=20 > End time equal to start time:=20 > Lav splitter ignores such ordered chapters, cause the play duration is = 0. +1, Having an ordered chapter where ChapterTimeStart =3D ChapterTimeEnd = should be ignored. > Furthermore LAV-splitter recognized only Level 1 ordered chapters. Is there a use case for hierarchical ordered chapters? I'm not sure what = a level 2 of an ordered chapter would do? Should an ordered chapter be = permitted to have an ordered chapter as a child? > For this I have three possible ways in my mind. > 1. Only as chapter mark > The chapter is shown to the user interface and you can jump to this = point in the timeline. This is the same behaviour like ordered chapters = from Level 2 and deeper. LAV-splitter ignores the "ordered" state and = reads the start time only. >=20 > 2. Use the ordered times from the nested ordered chapter (I prefer = this option) > Nested-ordered-endtimes is a topic where I can't find infos. My = theorie is that such chapters must have then > nested chapters and the first nested chapter start time must be the = start/end time of the parent chapter. > A splitter should read than the nested-ordered play duration an takes = into acount. >=20 > 3. Endless loop > The frame which correspond to the start time of such a chapter is = shown endless. > We could simulate a behaviour for menu's like in DVD's/Bluray's. Some = user option in the player could be prohibited. >=20 > Empty end times: > This can be found in DVDMenuXtractor menu.xml output. > In principle we could use the same 3 possibilities here like for "End = time equal to start time" >=20 >=20 > Another EBML element which makes not right sense to me, is = ChapterSegmentEditionUID[6E][BC]. > When such an UID is specified, the splitter should play this edition = from the linked segment. > But an edition have not a start nor an end time!=20 > What is with the specified chapter start and end time? This chapter = duration must than match as a sum of all chapter play durations of the = linked edition. What is when in the linked edition has chapters with = linking to other editions? > Or is there an other method in use? I've never used ChapterSegmentEditionUID but it does seem valuable. The = specification is not so clear, but my presumption would be that you'd = add the ChapterTimeStart of the chapter using ChapterSegmentEditionUID = to the starting time of the related Segment's Edition. > Thanks for reading and sorry for my bad english. No worries. I think there is a lot to discuss regarding chapters. = Honestly I often go to http://mod16.org/hurfdurf/?p=3D8 = for information about Matroska = chapters rather than the more official but sparse documentation on = matroska.org . Perhaps first we could clarify the = documentation of the chapter elements in the Matroska Schema = and then extend the chapter documentation = to give descriptive sections on: - the use of Non-Ordered Chapters - the use of Ordered Chapters - how to handle Chapters that reference external Segments and/or = Editions - also a definition for the xml expression of chapters Dave Rice > Best reagrds > Martin >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Matroska-devel mailing list > Matroska-devel@lists.matroska.org = > https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel = > Read Matroska-Devel on GMane: = http://dir.gmane.org/gmane.comp.multimedia.matroska.devel = _______________= ________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_3998F36A-E6DF-4808-9856-B001F5EF3286 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Martin,

On Feb 19, 2017, at 8:17 AM, = hubblec4 <hubblec4@gmx.ch> wrote:

=20 =20
Hi all
=
I hope this topic is not too boring and we can improve/implement important "use" notes.

In my chapterEditor thread was a topic "chapter.xml from makemkv" which generate non-ordered chapters with end time stamps. So far known to me there is no splitter which read the end times of non-ordered chapters.
In Mosu's new Chapter Editor is it not more possible to set the start times equal to the end times.
The DVDMenuXtractor generate ordered chapters without an end time stamp.

What is the correct behavior?

Good point. Is there any purpose = to ChapterTimeEnd if the chapters are non-ordered? Would it be fair = to describe ChapterTimeEnd as only relevant to playback = if EditionFlagOrdered=3D1.

My suggestions are:
Data for non-ordered chapters can be set, but with a warning/info that this data will not be used.

This could be said within the specification. It's = a bit much to request that all Matroska editors also say it.

Ordered-chapter end times can be set to "empty", equal or greater as the start time but never smaller as the start time.

That makes sense to me, though is there any = meaning of ChapterTimeStart =3D ChapterTimeEnd? Is an empty = ChapterTimeEnd semantically equivalent to ChapterTimeStart =3D = ChapterTimeEnd or equivalent to ChapterTimeEnd of the last timestamp (or = infinity)?

The normal way:
End times are greater as the start times. A new virtual timeline use this chapter and takes the play duration of this chapter into account.

End time equal to start time:
Lav splitter ignores such ordered chapters, cause the play duration is 0.
+1, Having an ordered chapter = where ChapterTimeStart =3D ChapterTimeEnd should be = ignored.

Furthermore LAV-splitter recognized only Level 1 ordered = chapters.

Is there a use case for hierarchical ordered = chapters? I'm not sure what a level 2 of an ordered chapter would do? = Should an ordered chapter be permitted to have an ordered chapter as a = child?

For this I have three possible ways in my mind.
1. Only as chapter mark
The chapter is shown to the user interface and you can jump to this point in the timeline. This is the same behaviour like ordered chapters from Level 2 and deeper. LAV-splitter ignores the "ordered" state and reads the start time only.

2. Use the ordered times from the nested ordered chapter (I prefer this option)
Nested-ordered-endtimes is a topic where I can't find infos. My theorie is that such chapters must have then
nested chapters and the first nested chapter start time must be the start/end time of the parent chapter.
A splitter should read than the nested-ordered play duration an takes into acount.

3. Endless loop
The frame which correspond to the start time of such a chapter is shown endless.
We could simulate a behaviour for menu's like in DVD's/Bluray's. Some user option in the player could be prohibited.

Empty end times:
This can be found in DVDMenuXtractor menu.xml output.
= In principle we could use the same 3 possibilities here like for "End time equal to start time"


Another EBML element which makes not right sense to me, is = ChapterSegmentEditionUID[6E][BC].
When such an UID is specified, the splitter should play this edition from the linked segment.
But an edition have not a start nor an end time!
What is with the specified chapter start and end time? This chapter duration must than match as a sum of all chapter play durations of the linked edition. What is when in the linked edition has chapters with linking to other editions?
Or is there an other method in use?

I've never = used ChapterSegmentEditionUID but it does seem valuable. The = specification is not so clear, but my presumption would be that you'd = add the ChapterTimeStart of the chapter using ChapterSegmentEditionUID = to the starting time of the related Segment's Edition.

Thanks for reading and sorry = for my bad english.

No worries. I think there is a lot to discuss = regarding chapters. Honestly I often go to http://mod16.org/hurfdurf/?p=3D8 for information = about Matroska chapters rather than the more official but sparse = documentation on matroska.org. Perhaps first we could clarify the = documentation of the chapter elements in the Matroska Schema and then extend = the chapter documentation to give = descriptive sections on:
- the use of Non-Ordered = Chapters
- the use of Ordered Chapters
- how to = handle Chapters that reference external Segments and/or = Editions
- also a definition for the xml expression of = chapters

Dave Rice

Best reagrds
Martin











_______________________________________________
Matroska-devel mailing list
Matroska-devel@lists.mat=
roska.org
https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://=
dir.gmane.org/gmane.comp.multimedia.matroska.devel
_______________________________________________
Cellar = mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_3998F36A-E6DF-4808-9856-B001F5EF3286-- From nobody Wed Feb 22 05:06: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 54B851297A7 for ; Wed, 22 Feb 2017 05:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.736 X-Spam-Level: X-Spam-Status: No, score=-3.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 WJvuGygk9JJ1 for ; Wed, 22 Feb 2017 05:06:41 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 405BD129706 for ; Wed, 22 Feb 2017 05:06:40 -0800 (PST) Received: from [192.168.178.25] ([91.47.61.166]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LmOLO-1c7k2U312Q-00Ztds; Wed, 22 Feb 2017 14:06:33 +0100 To: cellar@ietf.org, matroska-devel@lists.matroska.org References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> <402d0e5e-4e64-2341-9a0d-a18d56a7d2c1@mediaarea.net> <62a09f2e-27ab-48e0-f7e1-afe909fec5c9@gmx.ch> <435B0D9F-9514-4976-8F31-02660246A5FD@dericed.com> From: hubblec4 Message-ID: Date: Wed, 22 Feb 2017 14:06:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <435B0D9F-9514-4976-8F31-02660246A5FD@dericed.com> Content-Type: multipart/mixed; boundary="------------3ADFD068E14733B687BDC646" X-Provags-ID: V03:K0:09o1S+WvfxgvqFLhkMrvuEdSqC1E9Czp8u1F23QC2vm1cQw9xy0 DhWL9OzrxlEsvLIyYX+G81UV+xFqAigYMDZtfY9Wt5Jdckeok+v9M8fBKcrRd0DmY5InJwW TfVWOhN/JNCrZjPygfk818DLwjwpSDi4bBLzP6CUmDjjAEYAeVbLDb2KuRmQwtoIXcZvC67 dp+b0JBGl5WQiXfDTTMdg== X-UI-Out-Filterresults: notjunk:1;V01:K0:3ox1dJrewgQ=:Pk3D375PbjXjFEyEcf050R FYQOCUGfhdDCJzG+1pQBRzv9QbzQE6Rdvys2VvudEtHVxI9MZsqt2Rl9lWwbQJDe2gO0C5Dev Hf++Vm9sKZAZs/zus+NOvUGd1aG/D5Y2rp66sHIaggT2NajG8t/FElaVawE/TjnHROI+TF5jY yvA5/1NVlSybUhr0jPSBxfz97+hVeOEqANZQN2yji7jNUfyjmOn+paCPQDXWzAzlPpjvdif8n jTLW/aZzcdBg7ZieyBb4+U8JJ8RkuV+32mKLQH74fqx8MD10QmdjWMGHEcBmiz2fh3Y+fTF+A x9V7q42Pcie9XsOqc/3XItvebOO7oHzgTvUZesiqpcp9PmlIiew07E0d8I2eDTHoPPNumlGLL x2zzSB02Kq4QbZLqUyfl2YtX2OepFKWAABTz3n+McbWlBJNsPtgMpYvxlfTdpI3vYA1DBezih 4PXMu0lfwvzNHsE2kqN97dTzRnmx7ydBoTr5eHii/4oqBYKHTPsztvQnR4RhlhlSCbgsAonGK HBCVz5AoSUKCQHyX47uYigHl50FqnM7t5gdvxHc7+NGmi6zjionPB9pnLsgHIe/FII/E4by0E xWV9WuXKWLdCSsK6Pyt1vyCbaq6ENaRBFLRQ94lnTYwA7muwnBimPyJtaqE1/V9WuDDLdRVZm 2tv6++WqfAqvG/i/d7ICVf0LajXE3FO1eqtWHSrioWbELJyrn00Il/yxvuDl8TYEM4VEnqxlt VeH28dLQeZK/FyKP1SOKw34EzpfLq+vU/D+N7X1YIDXriRzyzunSu7gZhfziQuDihA1SVLUUd oWO+kqCvMU5ENw0sAHY6QYsBi+IbYqud1omv8DpYxK/uVB+DDLUWctELXhbuXB6Z2XdxQsNqe jDxOZIoZ7RWcrN/3LBLUrjaq+dvO1RTmuQlQvdZPRarFe3U5zMhIUIP/o6QcbuMBIi9LD56mD fh0iBQ+fl/ISO8L8vizcy9lQUtFTyYkpI8AK01y2Gp8hPeGkgl+4yGqfJM0nTVY4cw9kLKEhR ZW90txFSIu9HfeFahrOWNbRt2QdVYLTmCUOFK/qDvNzH Archived-At: Subject: Re: [Cellar] Matroska Chapters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 13:06:44 -0000 This is a multi-part message in MIME format. --------------3ADFD068E14733B687BDC646 Content-Type: multipart/alternative; boundary="------------C7832D0DC018D78E78F1A375" --------------C7832D0DC018D78E78F1A375 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi all Am 21.02.2017 um 16:37 schrieb Dave Rice: > Hi Martin, > >> On Feb 19, 2017, at 8:17 AM, hubblec4 > > wrote: >> >> Hi all >> >> I hope this topic is not too boring and we can improve/implement >> important "use" notes. >> >> In my chapterEditor thread was a topic "chapter.xml from makemkv" >> which generate non-ordered chapters with end time stamps. So far >> known to me there is no splitter which read the end times of >> non-ordered chapters. >> In Mosu's new Chapter Editor is it not more possible to set the start >> times equal to the end times. >> The DVDMenuXtractor generate ordered chapters without an end time stamp. >> >> What is the correct behavior? > > Good point. Is there any purpose to ChapterTimeEnd if the chapters are > non-ordered? No there is no purpose! But as info it is maybe important. A short description: When you create mkv's with makemkv and you need ordered editions/chapters, so it is easy to build an ordered editon. In practice: You load such an mkv to Mosu's Chapter Editor(CE), then enable the EditionFlagOrdered=1 and all fine, cause the end times was allready exists. If there are no end times you must enter all end times manually (a lot of work). Mosu's CE has no function to create/calculate ordered end times, but my chaperEditor(cE) has such a function. An other problem of ordered chapter end times, is the last chapter. The end time of the last chapter must be the duration of the video(in normal situations), but this info is nowhere strored in a chapter.xml (only in an mkv where it is possible to extract the play duration info). > Would it be fair to describe ChapterTimeEnd as only relevant to > playback if EditionFlagOrdered=1. Yes it would be fair. Every splitter will ignore this EBML elements. But there are more EBML elements which affects that: - ChapterTimeEnd - SegmentUID - SegmentEditionUID - the whole ChapProcess (ChapProcess: I have found it only in DVDMenuXtractor(DMX) output.xml files. Without ordered chapters I think it makes not sense, but I'm not 100% sure) > >> My suggestions are: >> Data for non-ordered chapters can be set, but with a warning/info >> that this data will not be used. > > This could be said within the specification. It's a bit much to > request that all Matroska editors also say it. +1 Such an info is very important(my opinion). All "new" Matroska editors can use this info an old one could be updated(or not). > >> Ordered-chapter end times can be set to "empty", equal or greater as >> the start time but never smaller as the start time. > > That makes sense to me, though is there any meaning of > ChapterTimeStart = ChapterTimeEnd? Is an empty ChapterTimeEnd > semantically equivalent to ChapterTimeStart = ChapterTimeEnd or > equivalent to ChapterTimeEnd of the last timestamp (or infinity)? > For the moment is no meaning defined for ChapterTimeStart(CTS) = ChapterTimeEnd(CTE) but we could/should. In pratice such a chapter will be ignored (this makes the parsing/splitting process easier). But I say that is not good and we lose flexibility. >> The normal way: >> End times are greater as the start times. A new virtual timeline use >> this chapter and takes the play duration of this chapter into account. >> >> End time equal to start time: >> Lav splitter ignores such ordered chapters, cause the play duration is 0. > > +1, Having an ordered chapter where ChapterTimeStart = ChapterTimeEnd > should be ignored. Why should such a chapter be ignored? Ok, there is no duration and irrelevant for the new virtual timeline, but you can have other info in such chapters: 1. a deeper ordered chapter where you can find a duration 2. ChapProcess can be used 3. only use as chapter mark > >> Furthermore LAV-splitter recognized only Level 1 ordered chapters. > > Is there a use case for hierarchical ordered chapters? I'm not sure > what a level 2 of an ordered chapter would do? Should an ordered > chapter be permitted to have an ordered chapter as a child? Yes there are use case's (only in an early VLC version, but not really for practice). DVDMenuXtractor output.xml for VMG or VTS or the VTSM. A hugh topic and to much to discribe here. When it is ok please download my cE http://forum.gleitz.info/attachment.php?attachmentid=99288&d=1486654181 You find in this email a 7zip with DMX.xml files from the Aliens DVD. My cE reads all the XML comments und have a very nice overview about the hierarchical Matroska-DVD-Menu structure. Then you will see that the level 5 ordered chapters are used for the new timeline. Cause, all levels between 1 and 4 are reserved for the DVD-menu-structure. (I have just noticed that DMX.xml files can have a start time stamp and an end time stamp with set to 00:00:00.000000000) There are one pratice at the moment. My Matroska Menu Editor: When I combine many files of an episode in many editions in a menu-start.mkv (all with Chapter-Segment-Linking) and I will naviagte through the editions/chapters it is not really handy. For LAV splitter: In the tray icon you see many editions(thats fine). But such an edition(with 20 or more files) has a lot of chapters. To get a better overview which chapters belong to an episode.mkv I use nested chapters. And therfore is a complex algorithm necessary cause all chapters have to be defined twice. First chapter (level 1) for the ordering and the new timeline duration and only the first chapter of an episode.mkv is visible, all others must be set to hidden=true. Second chapter (level 2) with the same time stamps(at the moment it is enough when the start time is defined), which is used as chapter mark/jump. Here a link to a small samle with 3 cutted epsiode.mkv files http://forum.videohelp.com/attachments/40602-1487505284/MatroskaMenu_Chapter-Segment-Linking.7z Here an other menu.xml sample. http://forum.gleitz.info/attachment.php?attachmentid=99279&d=1485686941 I reported a playback bug of such menu.xml files to VLC forum and it was fixed. https://forum.videolan.org/viewtopic.php?f=2&t=137611 In the videohelp forum I have discussed this with a member and he his the same opinion like me. http://forum.videohelp.com/threads/368560-chapterEditor%28OGG-XML-TTXT-m-AVCHD-m-editions-mkv-Matroska-Menu%29-names-CLI?p=2425793&viewfull=1#post2425793 A ordered chapter with a valid duration(greater then 0) should not have nested-ordered chapters, cause it makes not sense. The duration of the nested-ordered chapter is not defined in the parent chapter-duration. But for ordered chapters that have a 0 duration or no end time stamp a nested-ordered chapter can/should be used. > >> For this I have three possible ways in my mind. >> 1. Only as chapter mark >> The chapter is shown to the user interface and you can jump to this >> point in the timeline. This is the same behaviour like ordered >> chapters from Level 2 and deeper. LAV-splitter ignores the "ordered" >> state and reads the start time only. >> >> 2. Use the ordered times from the nested ordered chapter (I prefer >> this option) >> Nested-ordered-endtimes is a topic where I can't find infos. My >> theorie is that such chapters must have then >> nested chapters and the first nested chapter start time must be the >> start/end time of the parent chapter. >> A splitter should read than the nested-ordered play duration an takes >> into acount. >> >> 3. Endless loop >> The frame which correspond to the start time of such a chapter is >> shown endless. >> We could simulate a behaviour for menu's like in DVD's/Bluray's. Some >> user option in the player could be prohibited. >> >> Empty end times: >> This can be found in DVDMenuXtractor menu.xml output. >> In principle we could use the same 3 possibilities here like for "End >> time equal to start time" >> >> >> Another EBML element which makes not right sense to me, is >> ChapterSegmentEditionUID[6E][BC]. >> When such an UID is specified, the splitter should play this edition >> from the linked segment. >> But an edition have not a start nor an end time! >> What is with the specified chapter start and end time? This chapter >> duration must than match as a sum of all chapter play durations of >> the linked edition. What is when in the linked edition has chapters >> with linking to other editions? >> Or is there an other method in use? > > I've never used ChapterSegmentEditionUID but it does seem valuable. > The specification is not so clear, but my presumption would be that > you'd add the ChapterTimeStart of the chapter using > ChapterSegmentEditionUID to the starting time of the related Segment's > Edition. (Sorry I don't right understand) The specs say's "The EditionUID to play from the segment linked in ChapterSegmentUID." A splitter generate the virtual time line but the duration info is not available/wrong, or the splitter must calculate it first. > >> Thanks for reading and sorry for my bad english. > > No worries. I think there is a lot to discuss regarding chapters. > Honestly I often go to http://mod16.org/hurfdurf/?p=8 for information > about Matroska chapters rather than the more official but sparse > documentation on matroska.org . All my Matroska features in cE comes through very often reading this wonderful page. > Perhaps first we could clarify the documentation of the chapter > elements in the Matroska Schema > and > then extend the chapter documentation > to > give descriptive sections on: > - the use of Non-Ordered Chapters > - the use of Ordered Chapters > - how to handle Chapters that reference external Segments and/or Editions > - also a definition for the xml expression of chapters > I will help where I can. Best regards Martin Below > Dave Rice > >> Best reagrds >> Martin >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Matroska-devel mailing list >> Matroska-devel@lists.matroska.org >> https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane:http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >> _______________________________________________ >> 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 --------------C7832D0DC018D78E78F1A375 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi all


Am 21.02.2017 um 16:37 schrieb Dave Rice:
Hi Martin,

On Feb 19, 2017, at 8:17 AM, hubblec4 <hubblec4@gmx.ch> wrote:

Hi all

I hope this topic is not too boring and we can improve/implement important "use" notes.

In my chapterEditor thread was a topic "chapter.xml from makemkv" which generate non-ordered chapters with end time stamps. So far known to me there is no splitter which read the end times of non-ordered chapters.
In Mosu's new Chapter Editor is it not more possible to set the start times equal to the end times.
The DVDMenuXtractor generate ordered chapters without an end time stamp.

What is the correct behavior?

Good point. Is there any purpose to ChapterTimeEnd if the chapters are non-ordered?

No there is no purpose! But as info it is maybe important.
A short description:
When you create mkv's with makemkv and you need ordered editions/chapters, so it is easy to build an ordered editon.
In practice:
You load such an mkv to Mosu's Chapter Editor(CE), then enable the EditionFlagOrdered=1 and all fine, cause the end times was allready exists. If there are no end times you must enter all end times manually (a lot of work).
Mosu's CE has no function to create/calculate ordered end times, but my chaperEditor(cE) has such a function.
An other problem of ordered chapter end times, is the last chapter. The end time of the last chapter must be the duration of the video(in normal situations), but this info is nowhere strored in a chapter.xml (only in an mkv where it is possible to extract the play duration info).



Would it be fair to describe ChapterTimeEnd as only relevant to playback if EditionFlagOrdered=1.

Yes it would be fair. Every splitter will ignore this EBML elements.
But there are more EBML elements which affects that:
- ChapterTimeEnd
- SegmentUID
- SegmentEditionUID
- the whole ChapProcess
(ChapProcess: I have found it only in DVDMenuXtractor(DMX) output.xml files. Without ordered chapters I think it makes not sense, but I'm not 100% sure)




My suggestions are:
Data for non-ordered chapters can be set, but with a warning/info that this data will not be used.

This could be said within the specification. It's a bit much to request that all Matroska editors also say it.

+1 Such an info is very important(my opinion). All "new" Matroska editors can use this info an old one could be updated(or not).


Ordered-chapter end times can be set to "empty", equal or greater as the start time but never smaller as the start time.

That makes sense to me, though is there any meaning of ChapterTimeStart = ChapterTimeEnd? Is an empty ChapterTimeEnd semantically equivalent to ChapterTimeStart = ChapterTimeEnd or equivalent to ChapterTimeEnd of the last timestamp (or infinity)?


For the moment is no meaning defined for ChapterTimeStart(CTS) = ChapterTimeEnd(CTE) but we could/should.
In pratice such a chapter will be ignored (this makes the parsing/splitting process easier).
But I say that is not good and we lose flexibility.



The normal way:
End times are greater as the start times. A new virtual timeline use this chapter and takes the play duration of this chapter into account.

End time equal to start time:
Lav splitter ignores such ordered chapters, cause the play duration is 0.

+1, Having an ordered chapter where ChapterTimeStart = ChapterTimeEnd should be ignored.

Why should such a chapter be ignored? Ok, there is no duration and irrelevant for the new virtual timeline, but you can have other info in such chapters:
1. a deeper ordered chapter where you can find a duration
2. ChapProcess can be used
3. only use as chapter mark



Furthermore LAV-splitter recognized only Level 1 ordered chapters.

Is there a use case for hierarchical ordered chapters? I'm not sure what a level 2 of an ordered chapter would do? Should an ordered chapter be permitted to have an ordered chapter as a child?

Yes there are use case's (only in an early VLC version, but not really for practice).
DVDMenuXtractor output.xml for VMG or VTS or the VTSM.
A hugh topic and to much to discribe here.
When it is ok please download my cE http://forum.gleitz.info/attachment.php?attachmentid=99288&d=1486654181
You find in this email a 7zip with DMX.xml files from the Aliens DVD.

My cE reads all the XML comments und have a very nice overview about the hierarchical Matroska-DVD-Menu structure.
Then you will see that the level 5 ordered chapters are used for the new timeline.
Cause, all levels between 1 and 4 are reserved for the DVD-menu-structure.
(I have just noticed that DMX.xml files can have a start time stamp and an end time stamp with set to 00:00:00.000000000)

There are one pratice at the moment. My Matroska Menu Editor:
When I combine many files of an episode in many editions in a menu-start.mkv (all with Chapter-Segment-Linking)
and I will naviagte through the editions/chapters it is not really handy.
For LAV splitter: In the tray icon you see many editions(thats fine). But such an edition(with 20 or more files) has a lot of chapters.
To get a better overview which chapters belong to an episode.mkv I use nested chapters.
And therfore is a complex algorithm necessary cause all chapters have to be defined twice.
First chapter (level 1) for the ordering and the new timeline duration and only the first chapter of an episode.mkv is visible, all others must be set to hidden=true.
Second chapter (level 2) with the same time stamps(at the moment it is enough when the start time is defined), which is used as chapter mark/jump.

Here a link to a small samle with 3 cutted epsiode.mkv files
http://forum.videohelp.com/attachments/40602-1487505284/MatroskaMenu_Chapter-Segment-Linking.7z
Here an other menu.xml sample.
http://forum.gleitz.info/attachment.php?attachmentid=99279&d=1485686941

I reported a playback bug of such menu.xml files to VLC forum and it was fixed.
https://forum.videolan.org/viewtopic.php?f=2&t=137611 


In the videohelp forum I have discussed this with a member and he his the same opinion like me.

http://forum.videohelp.com/threads/368560-chapterEditor%28OGG-XML-TTXT-m-AVCHD-m-editions-mkv-Matroska-Menu%29-names-CLI?p=2425793&viewfull=1#post2425793


A ordered chapter with a valid duration(greater then 0) should not have nested-ordered chapters, cause it makes not sense. The duration of the nested-ordered chapter is not defined in the parent chapter-duration.

But for ordered chapters that have a 0 duration or no end time stamp a nested-ordered chapter can/should be used.  



For this I have three possible ways in my mind.
1. Only as chapter mark
The chapter is shown to the user interface and you can jump to this point in the timeline. This is the same behaviour like ordered chapters from Level 2 and deeper. LAV-splitter ignores the "ordered" state and reads the start time only.

2. Use the ordered times from the nested ordered chapter (I prefer this option)
Nested-ordered-endtimes is a topic where I can't find infos. My theorie is that such chapters must have then
nested chapters and the first nested chapter start time must be the start/end time of the parent chapter.
A splitter should read than the nested-ordered play duration an takes into acount.

3. Endless loop
The frame which correspond to the start time of such a chapter is shown endless.
We could simulate a behaviour for menu's like in DVD's/Bluray's. Some user option in the player could be prohibited.

Empty end times:
This can be found in DVDMenuXtractor menu.xml output.
In principle we could use the same 3 possibilities here like for "End time equal to start time"


Another EBML element which makes not right sense to me, is ChapterSegmentEditionUID[6E][BC].
When such an UID is specified, the splitter should play this edition from the linked segment.
But an edition have not a start nor an end time!
What is with the specified chapter start and end time? This chapter duration must than match as a sum of all chapter play durations of the linked edition. What is when in the linked edition has chapters with linking to other editions?
Or is there an other method in use?

I've never used ChapterSegmentEditionUID but it does seem valuable. The specification is not so clear, but my presumption would be that you'd add the ChapterTimeStart of the chapter using ChapterSegmentEditionUID to the starting time of the related Segment's Edition.

(Sorry I don't right understand)

The specs say's
"The EditionUID to play from the segment linked in ChapterSegmentUID."

A splitter generate the virtual time line but the duration info is not available/wrong, or the splitter must calculate it first.



Thanks for reading and sorry for my bad english.

No worries. I think there is a lot to discuss regarding chapters. Honestly I often go to http://mod16.org/hurfdurf/?p=8 for information about Matroska chapters rather than the more official but sparse documentation on matroska.org.
All my Matroska features in cE comes through very often reading this wonderful page.

Perhaps first we could clarify the documentation of the chapter elements in the Matroska Schema and then extend the chapter documentation to give descriptive sections on:
- the use of Non-Ordered Chapters
- the use of Ordered Chapters
- how to handle Chapters that reference external Segments and/or Editions
- also a definition for the xml expression of chapters


I will help where I can.


Best regards
Martin Below



Dave Rice

Best reagrds
Martin











_______________________________________________
Matroska-devel mailing list
Matroska-devel@lists.matroska.org
https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
_______________________________________________
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

--------------C7832D0DC018D78E78F1A375-- --------------3ADFD068E14733B687BDC646 Content-Type: application/x-7z-compressed; name="DVDMenuXtractor.7z" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DVDMenuXtractor.7z" N3q8ryccAASXVOe6qiQAAAAAAAAjAAAAAAAAACwDBaUAHg/LhxHYzmaRD4Meyv17M9R/6bfa KDF2JWYgTSoJbWr3KXA4QROVCIrQWx2TS+JShn3Z5i9ZpfbK8ysY3nIcQwK7xtxV3u+MNYia HOkTuMVOj1jT5yn1cA7rbRRfDAfxD43QThezJeWkgZG/gu45qblkIyn7tSkPOhmWOxxkVBt/ Oi5KKkggVmEUFftDPq6IneuuR9QJOGUo8ostJha+LOPG79B071M0UjwrLVNyerua86w1+TZ3 tCdqHk/N4RhwlTgGrzY2mkUnzDHjhcXB5htdn12mz4JSWodvk/N5H4RuR1NiUVHYjQDzFX2l pfrB9UnBi14pVM9iG63JcSFCf3nyMRiRjDzEpfnvPXga/SzePZgrnT2NXrsgaVl2/PdGpvAO NqOgHvTs0jDyWuO8eiuy7kTAEWylnw2glGGZqu2pSnTf8juffCemdvYyX+0WKUGb9RoI4kLt T+9HRsmWd70eAMxuIqOl5p6UnspT0wUzfD++KquFO7F6h9lHb+PTD4vahNZj+STLx23Rpxw1 X7bvkS4XvHpQjezTN2T5oXVOXiRWOyUQEXxfIF6GJ3PSbo4eAcB025fhNiC2Zq72WhB/LLIm pO2eLekgUCKpCnKYe9QPGB2FbfFHEry3ozs6I7emyQVQT6lgdh87C6JIgpStwTQ/M5jhRRSG 84CgqmAYgDV90B6RbA+w4idcI8lsDiROIeEQe6i+ZOpB8vpUx+Sb372bqm0lcW6pHU7m9YXR Qf/pYZnz7HAz8GZ+MQjHx328wnHN74YsrFmPa4208pJU+icxm4QQ6wcemW6E8sNPcu5Rf79m zIeroFc6Q4aumD9GzKrTE5FSHkPl00hOEbtqkAI1/OoyTdTsEaWHeuVmIq9lpvzuJlJsX2mT Ez3AU8GK/uoHhoK9ff0XZxSNOgLYPhbQSBNP1a7t8WLTmw/r+PVcQxNKZIeCQxZ4XuK962dQ ap9Y0fTrEKXeVGZqxzLAUwqPRXJbIanOi5+N4ezttyHZFkGeRLpXeOZsaAcK0zyRnU1lqnLN 4cWBdyjgqsE75CQC+plHyyWtqoNw1g5nXqH9BPwp0JehBz0fNPH1T9xPnDXxMkkLDyBY1+p2 PJqZyprcb7jBqv0KePKh4Pm0STQLq3vVoSxhJ6Ki2E/jac+WzJBlzO/sjf+2AbFMZigmPQ4V HbtElhkVySwJS9Bfc69SlkbFpG/c6F5XjFGJTIDkn30ZsnBT4wDeUbHfmI7AdViycrN0PKsm GkORAZEoEmKdsb5WE/cbsyTYAF39jfiIr6/xiBS1TUnIHcYkYLDjYPBmBY5YxyszLyQ9oufP 9dKDnr09vwwc3vnTmMxr+RGZ+v+PaFXXTGP+cSW4kym+f1aFwaE4dugKNhMn4DkYE0DfrvNL BeTd6nXTKXawSWknlRY6yxKoPEautDleQE4sF5kEqLzJib5itZAcOUPZA9P/vvPf96dl612f Gy91Hi2OLy0/afnyArqQU04rvhRFGKfseQhckq5PXw5Nn5goBNc3EdWOyBzdRh7Oi/6svbHS U8fRtL0+gSAQXAPMnFz2QTEh9v1lSHfWttM5/Z2yoMF5qchCUIiJ0mHcnhU8XGFu4cSvfkYg cmGyNB5/FSm0So2bW3yYZRfjXS4AVbwlZjyP/RVjpb/3rgqADHZhZZtCLuw1XWHfc8e8GIT/ jqF82TymvYdrKYI0RvYHMOU5m/GFb7wYep1VLKC95/XST8jh1ecePQzb8laDipV8L6fZ/qk+ 7vCiZaHsbd8iOJusnidsvEkHPSwfsVXazUrdMKFogWOfsAy7OwjGqEj5AG8fsmO7EwIiown1 CpDI5KhINQ8MN9TvMiW0UjAoOZKpL/rBVpE1OrY0pBL+FSDQJZNU0Rbm/6yOYWF2GgeEAcd4 nI+8t3/nOE0Z785t4y1l1CyUwgxDz+U60c4+NJP6JnjWed2X1zGJoRWvsBWFQCgt+YmjMFTV 3yH6GsiZRjkxyyDWfYrFdtMB9huJRgVoDf6ZIoE+NdpiEKAC7iov3hOwsY48nvoqm2xQaJKl y4Tah5C5g9uWXkNF7TXdcbVw1IKGRg+NzN8LkkdVoBR0El6EMVZx+AwT2tmXZo85jY96JdBW danTvd1KzGQwJZBSM9CPPoiKA7N9LAfw+oyD51bAiLn7o6KrYdn4kCkJiFQLTc5Uw8QAT9hv iqLyJ8vsrXGWwIeCEFCWQLeCSiNBxkd/rA4kwNfcHz24dZeHBc7Qxp/xTKtmT39sdjmRCdsf ZMKcxT2E8HEqk2mpdBx6EvWQKEFO+5uN3DFb1N7UnzP5lHTVNshTzgP1rN5YN2uZ/2jy0f5F WqXu3knVIsqMqWByq4A6wmq7Ih2xXTF9+dI7VT8kOcoM7bwSXxW+rEHnwZQ70e1De5gpTtHc R/qBQhMzcr0lmfkyX+bfYnPlYe/g5e7+ej61IIrj2wmrdtKVEHvNqx+sKQXsPfCoB3KVKA9C P73qFAVx9FgXeKyhlGySHnyE2Uc8hsZEV1IdeeHSn/RF2jiYJbGcJHT+Y9E3NSie2x6/jb0H 6gfwwJWBZkIoN6/wbbVck3kgeZyoZiFtkTmFzkAkNmwrzBYrMsdbWP7iJQXek7nuH7Z+ZtOf lgAj2/0pvA1eim7bYTYQZgPVBSgT2szi5JVkR/pWx1WT1PkKysLSeGW2vFz311FfgY86+uVa 4SEhWoMIjNby7kwmtSHcdo4YjGMDZjeA3hUAOJCowxsQ06Mb+0NKjTLu01/rZcUDcfHK+344 38VZfYP5dSFYvMp+IkAOxbYxG7EGl1wFWD/OcYNQefSSJ1n5PNLbF8NWq7Aiw6zqLOh6ydVQ g6Q+vgK46Uz5GD5DPss+wiCIjxYLdxqjxMFVb25BGQNakYMmlMG325VQ8oBobbrZG6ybN+3y W1snT11Fm2XHgvreb+h+UWh6K5Q3MPKHW3bj4Sgi4BqUWjlmrfqYoO1fUS6tFMbcibBgVpEX SikMnQn40vqYclew/X3qa34DdPTdGR3iaq2P9v1pC9EGBQyA+xaaGvN4jBCbNQuurgX8fn+F tJqKMZDkdoEh8rcHemhjdTAhPKDS2lteZsK86+S8JUnuK5AcRNc6OgJLztb/O3OtrzTaTGcj kt/mYl7gNYyd3MQtspxB4TxrOtoEnRwTyzuXxb3UwNktMFsEwhEeY+ZaUlIBlGCmUQK6MW9S aEgdMoXmlGUNVHB/EYbN9pDsxXacXZ3yookCdKn2nGtpOCkn3f80hHw/XVAw/A63iFB79M4p OYUHF1dMYB6oA5WMmDF17XpgSYtVn8Ot4w5Rf9sNWzTuwFTdS7632CZWZHZcZFIXdShPf4ox Tf6zgOWtXxp70lxjKEKbERHZsCZQSodJOj4Z/v0udQpq79uPZdYGtSX9Rdp10ZFd64zM0brW yMNOlOz+/xK4g9MAojIN0z/eVG/EK4xaKljiDKuprqWlhDgzFlGFAPl6+4TMwGIlW8qsyTdv bnzbm/qjbYceU/jB99/Qx44WAJpwbRu4Lj+7ketTv9CEk7fyBFyMLlhKIBGOrKBtInPpRmaW 5f1q+pVT3FkEB9p2suh0sy3IW21W5p3tCRCRft6zcSe7nDrSRQVHp/+Huz+nvbyqAmqHbsJL zBtDDCW47MymU6Q27qbm70arq9ml3brtY/DggzOW+o/qk2D6+A6CbBxJv36/8uBnsS0p4tex NnYRnr5epH0IcBq7LThREsGSFi+D0qJsUjjDAh4IMa2YXmRvbK85GF0g1SJbuH6A7gRG6W9N /+HGTRRcXgFsFwOMLSCq25lXny2RWO/CsycQ88p/mSJMpJtFx8bidur8kfj/Zu/EcQPkhpdr l3cur8UXehj00dPHcnT1rQThRaB1KYp6zKBeOHanQf1FkWEc4hmLowGdq3I1XKKxf6np2B0H GdLbQKplJ6S7lAERLt73DobsoE6029pYfjOlfxbTkEgqwgud1vi41NtLM3yRYuivNImi4/hU 1MNvosL3K095ijv5RQnKNGNmx+665DGp7ElQKrHUY/p0iJWvYFm+WIX5nAL5JdI5uI4odVxH vIgB6J7a5jPh+86mD4RMOf6pXupLNG/b4JUndhCMDVUEwUYdGc5Nz15Aud4bvdT+RxLj8N2W 6mc3tiCCW313GO43PB7iysLNYA93WRv28//8n7ze+nKa0nJY27nj722iPoKvoiSk7gJc43Ru OYffUGffZwOiNO0IEH0BH9rpt7RiSm1HoBUslVD1K9lpypID2dv6PPG4RrAiL4Ptnce4512U hyRTPfyLQf+lx3BZUqWQO3QqzjbhuxbmBh7gInGI/QZsG/M8BIyqAJnK4HN7g6h5NNeGf6vt yv8dIdThodW81WBZ7Dly5tlg2L80XEHFU/tNqWWlM+VLVGK/inHRKkCMSUCpUFGRiUuUVEd8 76Tt2ScqUcdPQV1fKT7FZeaSEWb2Jvb3AAFeokhJLa5e1d7H3RffW94y/v84uvxLZS2of6kK 6Wb5PSdImea2BnNUplTUDFBQTMg6DkFSKMs5VFjn79GNpvBZnbm7YQYcA6y55UPeoLjiUt0J qqVfkg1jNaARs9ajPEuRP7ZjcWl5w4wu47AX2W4pn8OxHMfYkMUQyvHbumAuwlZtp91mpfik KEluvRBkXWf0W6WAPSvz02hVLAcWSRycdAidiOG7hBRkZ8dooHuzYdj/yv7kkavg4bSBfSNG 4ZG40GGruliLWN8+3v4vq1LACHjhnu8R8oq3qwWdEgTZYjnMqGKveo9sF0ARu5+s6XqVQQKI Cy1d/4bCgavRvQ3GMLIM1aWGfLd2QzizkpfydOaMrsa4W+y1eGj1vrKAhvSxKN7f7iE6KbqS JF/E2uoqo7I9AM8rnXxKviDUQn+XWVBZvOyp3ExG2AV3HQ6CoHrwZiz+JLzm9+Y5cg9NR7Z0 1usDpcuTHuGDZPeYQROJUE5QZ9b3e+1KS5R4IAv9j0UBvm9rjZ+TwVe0CcoupBbFLn2SGs1S g8Ubs866JdIuctNbCSDuN4YQhW+SuSzinkQ9T4alp3n6XCoDagJe5iq3FQTLh2LTa8nHgGqS rQESJKSO6XLCiXF7B0rEDs8GbfaUu06Bj4bfAUkzEBfk2ojn2qdHcmbcr7sNfXusu40M6eO0 fHVeWQdJvKaoqifHTJhrGpgTDD7DpesmmvADn/FxJDNDungeIyRAOgcSCNWfL3xVNSmEJmDC LixTQMk/3sMw+vvULqexC0pH1ENfdSqy5DBRNNGvF3cMGn72zKLhLbVpx5eaDXdhVMgFmtMw PClMosmG8JPVHNNqhAHBBPyzfGUX8bBBzNKO0tqYBT7MN/ABIFCdiyYVMvL91+5v3n1Txbly Yvr98d601saH/7FixmLrPfO7m/bJU4RmnYIG/qaNHhlFw0B+v6a27bcHa1rP/edgpRFmxgO2 scmya5BNQV2nqqVH17ARuo9ckaOfScc4TdthvM0ipM6bm32vjbmyjkqXsnZGa3L6a1wtUn/+ Gefr9qb5wXYUTpah/JzzxdbIVjRB7cRQs3u0NynzvHhiymM0nWZm+mVN2MTWU36az+wPT5p6 hTKvLxOmsgMamvPiMb8yWFKIrZXSs9b34cUFaTPbncIfd0XF3kACNS1ZrGOovMmbHjFpR1in i/gny7ECFPLEa8CO+IfRg1Hj3hsK+CqoO6jN1A+pR3v+aqLxNt15scnb6MmCCS4XzrUTDWkw wD/tNnqF1rldFLv241UJo/MFl7xtE/BeWckUUcuWOwFEf290bCH6/jvi6iXVeMu835LJ+p2L omwpgLBoCWiMylD18iY6ioQ1LhmQHliwlGLUMRWqNgMwovWF6wglqCYTJIHLnEwcrmBKknIh MUbdgwZ4B2fgjiyRNk+Tjz0yb17ZRrc7lAajAdHeTAlNbq1Z8kCYreUkGZ4PwNAuUg6xXv0C ++mf12xBvJOovFewNNub/RHrrTzft4sxe01BCcyquKIFjSALUEkSFvGLR2HJralt+vzsp1gF jPEWIl8s2cYLEU+TW74ZzR04dNLfrAbCy55d0s1QZnbXkMCEf0sPqi4KQ6BvAw2kQY9pvK/U X3pMQd+rjRcRHk1G/ABGC3EGb3f07KLDc7wOj+dKANBInXv6Wyj+hINlt9f4tzi6JoW3+5GC VDur5KTpJq9Bjj5/dk0OEeEQYGYJlaAmOyiunQo07cchJxuAuILwUCCVDQ5Lht6oAP2ckW/S E1zH0N1JygKSRYM2ZM0loMUvmZBmlzgPO+v8tD2i9UPt8wilIMnuOvit6CjlMxphPjBb7Ull Qm0kQaPjGn0lLiYBmsEv1WUeVceLVcJAuOQbalTjDGi1EAJZzUaBmavXl1T27UEEUQnpoy8I pWYLMWIHM9gWnEuqu/kK4eltAtmNuCW7pwq6WfXtSdk0Z85HTSMjqv2DN06wRf/h/sK+Cx/0 4Wru6c03uhAwRXuIAHE7uEuCWosU/e4eQyrnzh8CkbEt11lBsOHz4bkHiqFoko4JT89D+ZXy B3yxgJ0qwrK2JoR/JCbD1wEyu/oGsjQle+QaPTdCXlPIYJ6mMYNt3SRX/8Nfj1g8nSUM3tmE izdd6/0s2wtbHrrDvQZPhAETk4ElTMJ06ia8MS11FgVjiWKTooGW0fn2MHXnZmfYOOQOZJAV oAWdJ5L4RJw3ICiRJpe0+hMNRbA8/eHPt8akhci8nf/ygbEdoHrpAFWGZybZBimy8oejGdOH LDbsNoszPPLkgTXFilFVTbbJggi73CMGAw2f4+FwNGMEdwS7dqWJnYFClIvC8FwhRNdAWJRA cBfU+kkHQH0BQrEyak0Xdq+yKHWNPnilKfhnqFbwzgOkqkZWCTkAMuckQBL+eek7h9IWNRlS /D0dQ7V0Vh76yEf4dIqm8jmprZ68WVrjpgpUon1/sGakLhQHx90rr96jztNtHbmR3sw9rgmP z0HrJRC4EOo5tHTOgIkbSGlj++q0ZoBeQKZ5ExVNoVx725q0VedsTNjVqgsu4YUbSgx+KdOg 7w1qL2qSUKyG+ddqBRsqS1PTOe37Dgt67nsEVL1SAnaZcLa1+WGOmduNvUZBMyb5aXUoOeG4 /Ggx0WJN3EDanrbnwqZaExelyJqEiIhp3llCulCJP9f7Mxsal4OLVeX7HoLZR5igCwaAQTxo Ht3LNQ57iD0dWJwquo+Wok836jOUDmrMIHYbB6I8E+mGcDXH7Tb1BtuON8EXCU+Tti36H0Jd cKX523qLanRxD53y12TBv6xyWeWnzrmoWKx7uuAbHKIrWBRO5iTOL/Sz5PqhCUcMhg4j/x6K mbOIIY5AniDiYCaVbjdFyJfUZK9rj9z01qTQrf5yTqUTc3xhuA6CySMrFKkJuk8l0tis6Q75 an0ZWpcKipb0WotW7JphWwJMxLHKEc5X7vjPDm49nyONK2ryCXnJUUfZfA0GNYHg1H5++ttZ gFbLotXtVEi5/E9EeVIDMTLqming2K6r0CRzIUrqUXVLMUJ8O1N9k0QhMZH5fUKI1REyiAtE fHgB1fNY5ddAhJEn7nZ5DonxTgDL+sEqqJqWZ70+DWJwPbAroZ8TKjOGOVUQgMzGJbXTtwqz ejJtszVYVZTd69dIe68rrcuzdyiqTj2k/y2BDpU67iqC3o5Ga2HQRjaFSkEdk8DT8ApyTiAV IhEiUiJAtdJQ/tMa5a2txnCOxJNFQHWQ0+FPaJatp/wZsBOuHigqdOtMQVvJRWemVSQu+r9L 6ZXsZsvDEb6i1+SsCPHsb6UvP4Ot5vK4vabE9faWHYqgQ72PoCIrkV1U0jFbE0z5QBbjXR+/ cLb0lCpYGNHk4IGqTlZay1jVQFh4y1bS5i/dYtqAk/8GVHbYfN+Eoo3uB46OWhMsYaBhUL7H KoH4HdOukMqx+KB+GO5DfultVp1FWaccebBFoLR9gOqvUHutCl8I/Cwn5ICPih822pLUVuqa OyghvV67O/bciyUllVMgK5Ek3djR4VwF9EfKWJ5vOOrkCBHdGey3tlTbN0dGNVTPt6eoiK6z XNoh4bFolEeDWiHVKzWStSBtf1Vrc0/fobn5O2vMYnHPofhkCrDirb6qZWdh4K71EnmY1N5y QmpFbbl0Xv7VQ1sDoFtn332oghcQoBYxik+UwLCCNvhbKKaGj8Z9/QdXuBPZsAFz75beHRCH NIlZxIjklva6UrMgjPto1Msdd/rEyikvMBKl78fT5oAKop5aDKB5AMXzNvMV/e6r+EZoq4/4 FHXLe1APVP1a7plSn0uhkir/7bZYqnnhn9I6fSXzqKhKw6L7m0xdd0Ol5jnKYV8ywiKGNhX3 xw7U1ONDFe0MHjWyJkard7VEGelBhPIamBjoL/CFdRk58XvS3ILBHOufwR3QMNPdtNyFQAxv jbL3vPJvekKC9OTF6evLu6Fc2jYsssMlJ49Rn7xITyQIhvaJ7Hfgy/2EhvRWNSm7qWD/sOLK Ju1lkfO20jBR00jxNAwXoQANJApW0UYKhr1Fn0iFFUz1xeMbUQ/aojDuccLaTPmzmBRimB7E VKrcolR/06FYwRdpMrlRgTB165/7T9UxPiLU8cRwzBvaRKvfm9Pn+PYFjfyPQaJkxB9NaK2v qRww0mRJDCumAsOcwyLwov4+PUzqhrhQPPfFnt5RD6jxPs68lyJigFlkTuJ5m+1OtWthhRl+ 5aUXigcZRELhQDt59DIkuGBbXhDkwGEl/HAVUBZnOws2iJ3IFjNsSslmKze2KosqscfnfEQq ozXayvrQD+178sYq0uUPHiGFhT792szgg+BC4YE24xo6r8JSwpYBByqTu9ifaRtHsMHg2v28 O4U8J1dmbpS5fj0C8gxBwHVGG/0/xrcsbSVJR6gvnEFP1G74dYg8EeAi0wl7NVcIR4JgLdI4 iZE7xApqj5bdnm9Uef3baM4RgJfNzvblXNHLcicwCPnGuvFLLYe69+H53JOWV9QWcku4861W EF2G2Q4JwrD/ksjnOLu9YelPnmQirMvr25lMCww9S8xq343agRxD3hG7JvGXVrvu7U8nE6YV Ag1ol6A//Y4NPkRO/OFbVbRq9PvI+bj2kEkQrAXH5L9Xdr4SSqjYMXqQZUPyMWaXvSbxrtQn TeCv1BRAgsdxWYj7zJAjqlyLXj8R6hZBu4zMIA/q5H7w1DwCMcRT9a//X8ZDf9GbaMUyZbYc MHyJdnCdZQCW6oNjjlna/9LgmIZvijtg0jux17n+NwbP8v2MMTUzEG9KyWTahklgb8NtaNCX OxFZmUR7kzyHNHcDNid2wfAfu698LrhYjXy1mtIOmTt9sJ9i25ZJ/4+YSWlDtHMVcPdGsR+6 6rZGD0hpbZQKQVsbMyZWyw18RlaJOPRXy2OKW+SS702RvAIpwjE3X0s7q7qr55NIjrOYL8Q0 +eOFaOX5PkeiD3dpoMTRHQbhAbWXEm1IjCWKi7SBECgq/Wr5S5ba/QWNown3hxv5MEMSPPNQ q3jwwZArw6KXgXrclJEIk+BIQC+y67OiZcQI1pJ4kulPHq+GO4rsm4Ey3+bmQTjxVSZlViWn 91T2LF4Hv37lpkoP7J2nXny5CI88hyLAjGcJ+vdHdZnsj30ZNxO70rSg00m+BIZzRlcZaTLT EycmJ7+gRWxWFgb5gx+iU/BXT7T40QULkXlU1MunJHZFtU2+xjlHwfOx0EIMAC7uwHkGR8mu 3LSfUVBG/eWKutn/i78Y3oJzy8ZgAJTbc+Zn18+Blu2XG6aerDXsEKmoby+OA1pcZtgCf0C9 0sBLD6hh7VLjwK8/Kufa6ZDcO+vCZcrofabIHsbYhqNzn8A0Ua7k/P+YGHw6cZ6KFiMvbL8Y cqUc8V/S/Qbf0YJ2HpcQ1OH2tJpuxHH+ASfryJsmqF4L0dUCige5VRigKf9Cgy1GQ1hxe6a4 YA4lSTdq817VNG7wpaLiTB6j1oZBV7oDwx5LtI3V+C/0AhWtupzMnMwpG4624sya6i/4Qa/p feWiQ1ASE2ttd5snUt74ObShUqoPogYSWxXD+GVJfr2BSmvFiTzVYck1iHiHWUd6t+RuFE2o huG1ry2i3qipfqzWvxYAI+EEVkKBPGPC6Cpa8dCLoT91CzHzAs5hu9/Q/A1v2ohmaj1DuUjp 16LTyt+TV/NOtHLbokPP2zbY3Z+136nag6H0y8Vfx1Ri+pnmFgz2ojcxAFH9AP/OQV/cOOwE GZxztwieL6TMXQN2OYqL0sOOifLvTnNs1zMRSXKzVM/sT9w96l/K3l/oeipWfzvX4Rmk0yje AFVXmJw0UguvdR31JPZ4bNdNbeS8qW8XvHG9E8qECvBqsUzwTMpk43CetBm6d1ueWKyIb54m N8uQCICVKdGm1M1Uv3qX249/Vkih2dEKcmNjxIytwZLvMz8DICTW4I9EFczJ2FP2/mXbnUJG 5SfkM3vCZd7koE3s2+Lx44AILXONAQmwEdsXCSeSJi2ObzgG99i7W37Ynic9X2IuCCIYR46Q 1xV2asDjyZ8gZkW4mzFVm+AYo25Sn5EOAnv9hON7iad8BR2cEwkv9/0PKposxYUQfR9PASE7 fCJPKR4CxVpBV7UDZN8jYwNj5he0Oyn5uBJ1iRDJARCKbZY89J+CfDj9qNj9aI8tr8OVaY0+ MS9EVJ9azoFi/4T12l2D7ZXAnWpd+lKNqe0e0BqG+9G5hmcadFfmI+PQMUX5zv63l/ie/Z4R tqE1JqzimN5cygzy3Z5rSJ4h3FU3WKWE26+r4VwM951SUIZOROxuj5Xkip8ZeU7QMbuX+lfK JXl5UCfztD061rq3Jzy5GS7HK1ilaEy6oVaLfjykpUOQlI7gsT+031JgDBAlSzODj+ffRPIV iFY+JJ6nPhsEhBwNYe4frfXRnekiYBHCPLpLwKijhaZKVj5csGwoR2qa31yzBvrdKHazLCsQ jEHUUfhDYjImqgnGpJzhEA3YZYs+a5zxqt+p5Z3YPYPeN0ZHffMdoOELQOjKX2Nd0JvCpDQ0 M+P7YXMcfkU1tzhydpfnXMex2N+rS31beT9N2rCgLFqUvZpjq7OKzo70ADKRN5B+1bqTtxV5 URV6aq4HkpoYSmXFqm1wOfuYKIna2g/bKWz0ghK5gjTNy4TuvkqG0PBe70M5Pi5UXGvytFjC dOgE3UGOlSyYRrAArJ9ZH88pncL6chCVNMD/MDffPJ9x5fYjvETqnnqr/gHkVOjP4Afz7qBe L8oqpxenDEn6SjQCAvtY7IoYZsLmoXbi92JisPf1l1YDcFabtCQ0XBKOldoyf0nLGkiKJDTJ Pw/j0+h7EyemR5tnrK+7LaloIh/UQzwLrlSi/+OoMjSvCAjd6e1D5xsU4h18rLJpzVcF12A+ GLjHMVJCEDyl4bTcuyiviyXv9ncYrniA25ng/RJs+w3SkltwCNoMgCt3dXxNKHywSoc/5m+V 0II/dg5BiSM2lOlgsl/egxB+BkxrkLv52whG+Ded2MPddcZeRVHUpAbqIdzZgUT6iURSq3My AYsx8SrnwhGrtE2M3/umyK59x02e8lGpLvato4rkjoZXr78DZn3cBnf5PyYSwbsdg6zLGeiz JywnYmrQoELZ4H92osoB2s0o75jNXzRc8oXoyz5LbfMevUaTpGoaXSs+QXFS/75HVnsUGkCo 9frWf7/zXMSEPCyADAizz8dGEggqch2+gg+dM6ApCV3IvOwWr/FJYF3ZpBVNZwk0vn0oL7/F CcEQ0kYy46h5ol6luevt98ql+f0VOXEul4IFGDCgDdsDf2vi1GTlGPjDMcirX6o4KOFoqHFb wj9au4pqlorrnCN5lYpjJC2Zv4yzP2xCT+OWTJp5Rek9/DLwGy2rw08oHa/t9fV9Y2p2KVnO iEAPSi2AFDOpEn9XXQ4VXP6fOtgz+XX9VjweXNeOmWITHqQ/X5CfvDPrL7y0YyZ8gN9lVHaH 9ImYWLHOOumEhN3ut/Rn+Z5hD5INkABqpH4BtVTjgf80fIsGWNdAiTlN7VfoViBvn95MM3oQ X/wdwhrb6HTxGC0ZygdUnkh4HOYsWMZw7WqhjN2OSzNAueEhXXBy1LBOZXKuYHHbKJ+2j1gD ZWXLvAZK6CHDyYPAglnk2DHjd8gQv5fl9x5fMphqWYCda6UgV0YdQ8ZgvFzJQqFLONcRgVVC dek6MhnRcYTUHdFitY1Mtypf5LSbPKhBG+ivcw7v+BZjMvfvzsEKspz4z9Bd1vnrjvtN+/7K tH9bY6XBgF4isO7qto7CtV/o+oT6BM3tPJ3wTFCCvzddqlRA4hQPbBZgMYhaxz/e2a8UsAAA AIEzB64P1rM5+mclR1cF4TPpwuSXBS+NVB0TmXOaCiVX6Q+bwEMrRQklDpdMeOR0vPyokDjx Rgn+3RlsNz4VuR0JHnD3oaGx0mMDbjbmw+B6M6TeJP1fFdnpd/CPofUO9ndhrPjqRi35ox1q 2MaZ2whwgp040N1bbr79nJ0dE2QSVqQoAD4ADww0MwUgVwQjnfq5uomjzhR9npQmByW88VWC xBatofbY++k6SXPJfcsEwpgVO8/IABcGo/EBCYC5AAcLAQABIwMBAQVdABAAAAyBjgoBwRH2 hwAA --------------3ADFD068E14733B687BDC646-- From nobody Wed Feb 22 06:34: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 895E4129994 for ; Wed, 22 Feb 2017 06:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt-EMxJdq4VT for ; Wed, 22 Feb 2017 06:34:41 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E67E12997C for ; Wed, 22 Feb 2017 06:34:41 -0800 (PST) Received: from [146.96.19.240] (port=57590 helo=[10.10.201.45]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cgY05-000GkT-EE; Wed, 22 Feb 2017 09:34:40 -0500 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A75AECC0-304E-4148-9A2C-36E751FB1CFA" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Wed, 22 Feb 2017 09:34:35 -0500 In-Reply-To: To: Discussion about the current and future development of Matroska References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> <402d0e5e-4e64-2341-9a0d-a18d56a7d2c1@mediaarea.net> <62a09f2e-27ab-48e0-f7e1-afe909fec5c9@gmx.ch> <435B0D9F-9514-4976-8F31-02660246A5FD@dericed.com> X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.1 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: Cc: cellar@ietf.org Subject: Re: [Cellar] [Matroska-devel] Matroska Chapters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 14:34:43 -0000 --Apple-Mail=_A75AECC0-304E-4148-9A2C-36E751FB1CFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On Feb 22, 2017, at 8:06 AM, hubblec4 wrote: >=20 > Hi all >=20 > Am 21.02.2017 um 16:37 schrieb Dave Rice: >> Hi Martin, >>=20 >>> On Feb 19, 2017, at 8:17 AM, hubblec4 > wrote: >>>=20 >>> Hi all >>>=20 >>> I hope this topic is not too boring and we can improve/implement = important "use" notes. >>>=20 >>> In my chapterEditor thread was a topic "chapter.xml from makemkv" = which generate non-ordered chapters with end time stamps. So far known = to me there is no splitter which read the end times of non-ordered = chapters. >>> In Mosu's new Chapter Editor is it not more possible to set the = start times equal to the end times. >>> The DVDMenuXtractor generate ordered chapters without an end time = stamp. >>>=20 >>> What is the correct behavior? >>=20 >> Good point. Is there any purpose to ChapterTimeEnd if the chapters = are non-ordered? >=20 > No there is no purpose! But as info it is maybe important. I thought about this more later. When the playback point is greater than = or equal to the chapter start time and less than the chapter end time, a = player could display the title of that chapter. So for instance chapter1 00:01-00:03 chapter2 00:05-00:07 At 00:02, the player could display that the playback is within chapter1. At 00:04, the player could display that it it outside a chapter. If the end times are omitted, then 00:04 would be inferred to be part of = chapter1. Perhaps we could define that chapters are ranges rather than points in = time and that if omitted then the end time is whatever comes first, the = next sibling chapter start in time or the end of the segment. > A short description: > When you create mkv's with makemkv and you need ordered = editions/chapters, so it is easy to build an ordered editon. > In practice:=20 > You load such an mkv to Mosu's Chapter Editor(CE), then enable the = EditionFlagOrdered=3D1 and all fine, cause the end times was allready = exists. If there are no end times you must enter all end times manually = (a lot of work).=20 > Mosu's CE has no function to create/calculate ordered end times, but = my chaperEditor(cE) has such a function. > An other problem of ordered chapter end times, is the last chapter. = The end time of the last chapter must be the duration of the video(in = normal situations), but this info is nowhere strored in a chapter.xml = (only in an mkv where it is possible to extract the play duration info). mkvpropedit supports chapter xml with an ordered edition without an end = time. I use this to create one chapter edition which refers to the = entire segment, whereas another chapter edition references only part of = it. So it is like: 1 0 0 12338659363134957115 00:00:00.000000000 0 1 14022955415078936670 Full eng Any issue with no ChapterTimeEnd in an ordered edition? >> Would it be fair to describe ChapterTimeEnd as only relevant to = playback if EditionFlagOrdered=3D1. >=20 > Yes it would be fair. Every splitter will ignore this EBML elements. > But there are more EBML elements which affects that: > - ChapterTimeEnd > - SegmentUID > - SegmentEditionUID > - the whole ChapProcess=20 > (ChapProcess: I have found it only in DVDMenuXtractor(DMX) output.xml = files. Without ordered chapters I think it makes not sense, but I'm not = 100% sure) See above use case: to allow a player to say what chapter the player is = 'within'. >>> My suggestions are: >>> Data for non-ordered chapters can be set, but with a warning/info = that this data will not be used. >>=20 >> This could be said within the specification. It's a bit much to = request that all Matroska editors also say it. >=20 > +1 Such an info is very important(my opinion). All "new" Matroska = editors can use this info an old one could be updated(or not). >=20 >>=20 >>> Ordered-chapter end times can be set to "empty", equal or greater as = the start time but never smaller as the start time. >>=20 >> That makes sense to me, though is there any meaning of = ChapterTimeStart =3D ChapterTimeEnd? Is an empty ChapterTimeEnd = semantically equivalent to ChapterTimeStart =3D ChapterTimeEnd or = equivalent to ChapterTimeEnd of the last timestamp (or infinity)? >>=20 >=20 > For the moment is no meaning defined for ChapterTimeStart(CTS) =3D = ChapterTimeEnd(CTE) but we could/should. > In pratice such a chapter will be ignored (this makes the = parsing/splitting process easier). > But I say that is not good and we lose flexibility.=20 >=20 >=20 >=20 >>> The normal way:=20 >>> End times are greater as the start times. A new virtual timeline use = this chapter and takes the play duration of this chapter into account. >>>=20 >>> End time equal to start time:=20 >>> Lav splitter ignores such ordered chapters, cause the play duration = is 0. >>=20 >> +1, Having an ordered chapter where ChapterTimeStart =3D = ChapterTimeEnd should be ignored. >=20 > Why should such a chapter be ignored? Ok, there is no duration and = irrelevant for the new virtual timeline, but you can have other info in = such chapters: > 1. a deeper ordered chapter where you can find a duration > 2. ChapProcess can be used=20 > 3. only use as chapter mark >=20 >=20 >>=20 >>> Furthermore LAV-splitter recognized only Level 1 ordered chapters. >>=20 >> Is there a use case for hierarchical ordered chapters? I'm not sure = what a level 2 of an ordered chapter would do? Should an ordered chapter = be permitted to have an ordered chapter as a child? >=20 > Yes there are use case's (only in an early VLC version, but not really = for practice). > DVDMenuXtractor output.xml for VMG or VTS or the VTSM. > A hugh topic and to much to discribe here.=20 > When it is ok please download my cE = http://forum.gleitz.info/attachment.php?attachmentid=3D99288&d=3D148665418= 1 = > You find in this email a 7zip with DMX.xml files from the Aliens DVD.=20= >=20 > My cE reads all the XML comments und have a very nice overview about = the hierarchical Matroska-DVD-Menu structure. > Then you will see that the level 5 ordered chapters are used for the = new timeline. > Cause, all levels between 1 and 4 are reserved for the = DVD-menu-structure. > (I have just noticed that DMX.xml files can have a start time stamp = and an end time stamp with set to 00:00:00.000000000) >=20 > There are one pratice at the moment. My Matroska Menu Editor: > When I combine many files of an episode in many editions in a = menu-start.mkv (all with Chapter-Segment-Linking) > and I will naviagte through the editions/chapters it is not really = handy. > For LAV splitter: In the tray icon you see many editions(thats fine). = But such an edition(with 20 or more files) has a lot of chapters.=20 > To get a better overview which chapters belong to an episode.mkv I use = nested chapters.=20 > And therfore is a complex algorithm necessary cause all chapters have = to be defined twice. > First chapter (level 1) for the ordering and the new timeline duration = and only the first chapter of an episode.mkv is visible, all others must = be set to hidden=3Dtrue. > Second chapter (level 2) with the same time stamps(at the moment it is = enough when the start time is defined), which is used as chapter = mark/jump. >=20 > Here a link to a small samle with 3 cutted epsiode.mkv files=20 > = http://forum.videohelp.com/attachments/40602-1487505284/MatroskaMenu_Chapt= er-Segment-Linking.7z = > Here an other menu.xml sample. > = http://forum.gleitz.info/attachment.php?attachmentid=3D99279&d=3D148568694= 1 = >=20 > I reported a playback bug of such menu.xml files to VLC forum and it = was fixed. > https://forum.videolan.org/viewtopic.php?f=3D2&t=3D137611 = =20 >=20 >=20 > In the videohelp forum I have discussed this with a member and he his = the same opinion like me. >=20 > = http://forum.videohelp.com/threads/368560-chapterEditor%28OGG-XML-TTXT-m-A= VCHD-m-editions-mkv-Matroska-Menu%29-names-CLI?p=3D2425793&viewfull=3D1#po= st2425793 = >=20 >=20 > A ordered chapter with a valid duration(greater then 0) should not = have nested-ordered chapters, cause it makes not sense. The duration of = the nested-ordered chapter is not defined in the parent = chapter-duration. >=20 > But for ordered chapters that have a 0 duration or no end time stamp a = nested-ordered chapter can/should be used. =20 >=20 >=20 >>=20 >>> For this I have three possible ways in my mind. >>> 1. Only as chapter mark >>> The chapter is shown to the user interface and you can jump to this = point in the timeline. This is the same behaviour like ordered chapters = from Level 2 and deeper. LAV-splitter ignores the "ordered" state and = reads the start time only. >>>=20 >>> 2. Use the ordered times from the nested ordered chapter (I prefer = this option) >>> Nested-ordered-endtimes is a topic where I can't find infos. My = theorie is that such chapters must have then >>> nested chapters and the first nested chapter start time must be the = start/end time of the parent chapter. >>> A splitter should read than the nested-ordered play duration an = takes into acount. >>>=20 >>> 3. Endless loop >>> The frame which correspond to the start time of such a chapter is = shown endless. >>> We could simulate a behaviour for menu's like in DVD's/Bluray's. = Some user option in the player could be prohibited. >>>=20 >>> Empty end times: >>> This can be found in DVDMenuXtractor menu.xml output. >>> In principle we could use the same 3 possibilities here like for = "End time equal to start time" >>>=20 >>>=20 >>> Another EBML element which makes not right sense to me, is = ChapterSegmentEditionUID[6E][BC]. >>> When such an UID is specified, the splitter should play this edition = from the linked segment. >>> But an edition have not a start nor an end time!=20 >>> What is with the specified chapter start and end time? This chapter = duration must than match as a sum of all chapter play durations of the = linked edition. What is when in the linked edition has chapters with = linking to other editions? >>> Or is there an other method in use? >>=20 >> I've never used ChapterSegmentEditionUID but it does seem valuable. = The specification is not so clear, but my presumption would be that = you'd add the ChapterTimeStart of the chapter using = ChapterSegmentEditionUID to the starting time of the related Segment's = Edition. >=20 > (Sorry I don't right understand) >=20 > The specs say's=20 > "The EditionUID to play from the segment linked in ChapterSegmentUID." >=20 > A splitter generate the virtual time line but the duration info is not = available/wrong, or the splitter must calculate it first. >=20 >=20 >>=20 >>> Thanks for reading and sorry for my bad english. >>=20 >> No worries. I think there is a lot to discuss regarding chapters. = Honestly I often go to http://mod16.org/hurfdurf/?p=3D8 = for information about Matroska = chapters rather than the more official but sparse documentation on = matroska.org . > All my Matroska features in cE comes through very often reading this = wonderful page. Then perhaps some of the statements of that page should be included = within the specification. ;) >> Perhaps first we could clarify the documentation of the chapter = elements in the Matroska Schema = and then extend the chapter documentation = to give descriptive sections on: >> - the use of Non-Ordered Chapters >> - the use of Ordered Chapters >> - how to handle Chapters that reference external Segments and/or = Editions >> - also a definition for the xml expression of chapters >>=20 >=20 > I will help where I can. >=20 >=20 > Best regards > Martin Below Dave Rice >=20 >=20 >> Dave Rice >>=20 >>> Best reagrds >>> Martin >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Matroska-devel mailing list >>> Matroska-devel@lists.matroska.org = >>> https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel = >>> Read Matroska-Devel on GMane: = http://dir.gmane.org/gmane.comp.multimedia.matroska.devel = _______________= ________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar = >>=20 >>=20 >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar = >=20 > _______________________________________________ > Matroska-devel mailing list > Matroska-devel@lists.matroska.org > https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: = http://dir.gmane.org/gmane.comp.multimedia.matroska.devel --Apple-Mail=_A75AECC0-304E-4148-9A2C-36E751FB1CFA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On Feb 22, 2017, at 8:06 AM, = hubblec4 <hubblec4@gmx.ch> wrote:

=20 =20

Hi = all


Am 21.02.2017 um 16:37 schrieb Dave Rice:
Hi Martin,

On Feb 19, 2017, at 8:17 AM, hubblec4 <hubblec4@gmx.ch> wrote:

Hi = all

I hope this topic is not too boring and we can improve/implement important "use" notes.

In my chapterEditor thread was a topic "chapter.xml from makemkv" which generate non-ordered chapters with end time stamps. So far known to me there is no splitter which read the end times of non-ordered chapters.
In Mosu's new Chapter Editor is it not more possible to set the start times equal to the end times.
The DVDMenuXtractor generate ordered chapters without an end time stamp.

What is the correct behavior?

Good point. Is there any purpose = to ChapterTimeEnd if the chapters are non-ordered?

No there is no purpose! But as info it is maybe important.

I = thought about this more later. When the playback point is greater than = or equal to the chapter start time and less than the chapter end time, a = player could display the title of that chapter. So for = instance

chapter1 = 00:01-00:03
chapter2 00:05-00:07

At 00:02, the player could display that the = playback is within chapter1.
At 00:04, the player could = display that it it outside a chapter.

If the end times are omitted, then 00:04 would be = inferred to be part of chapter1.
Perhaps we could define that = chapters are ranges rather than points in time and that if omitted then = the end time is whatever comes first, the next sibling chapter start in = time or the end of the segment.

A short description:
When you create mkv's with makemkv and you need ordered editions/chapters, so it is easy to build an ordered editon.
In practice:
You load such an mkv to Mosu's Chapter Editor(CE), then enable the EditionFlagOrdered=3D1 and all fine, cause the end times was = allready exists. If there are no end times you must enter all end times manually (a lot of work).
Mosu's CE has no function to create/calculate ordered end times, but my chaperEditor(cE) has such a function.
An other problem of ordered chapter end times, is the last chapter. The end time of the last chapter must be the duration of the video(in normal situations), but this info is nowhere strored in a chapter.xml (only in an mkv where it is possible to extract the play duration info).

mkvpropedit supports chapter xml with an ordered = edition without an end time. I use this to create one chapter edition = which refers to the entire segment, whereas another chapter edition = references only part of it. So it is like:

<EditionEntry>
  =   <EditionFlagOrdered>1</EditionFlagOrdered>
  =   <EditionFlagHidden>0</EditionFlagHidden>
  =   <EditionFlagDefault>0</EditionFlagDefault>
  =   <EditionUID>12338659363134957115</EditionUID>
    <ChapterAtom>
  =   =   <ChapterTimeStart>00:00:00.000000000</ChapterTimeStar= t>
    =   <ChapterFlagHidden>0</ChapterFlagHidden>
    =   <ChapterFlagEnabled>1</ChapterFlagEnabled>
    =   <ChapterUID>14022955415078936670</ChapterUID>
      <ChapterDisplay>
      =   <ChapterString>Full</ChapterString>
      =   <ChapterLanguage>eng</ChapterLanguage>
      </ChapterDisplay>
    </ChapterAtom>
  </EditionEntry>

Any issue with no ChapterTimeEnd in an ordered = edition?

Would it be fair to = describe ChapterTimeEnd as only relevant to playback if EditionFlagOrdered=3D1.

Yes it would be fair. Every splitter will ignore this EBML = elements.
But there are more EBML elements which affects that:
- ChapterTimeEnd
- SegmentUID
- SegmentEditionUID
- the whole ChapProcess
(ChapProcess: I have found it only in DVDMenuXtractor(DMX) output.xml files. Without ordered chapters I think it makes not sense, but I'm not 100% = sure)

See above use case: to allow a player to say what = chapter the player is 'within'.

My suggestions are:
Data for non-ordered chapters can be set, but with a warning/info that this data will not be used.

This could be said within the specification. = It's a bit much to request that all Matroska editors also say it.

+1 Such an info is very important(my opinion). All "new" Matroska editors can use this info an old one could be updated(or not).


Ordered-chapter end times can be set to "empty", equal or greater as the start time but never smaller as the start time.

That makes sense to me, though is there any = meaning of ChapterTimeStart =3D ChapterTimeEnd? Is an empty ChapterTimeEnd semantically equivalent to ChapterTimeStart =3D= ChapterTimeEnd or equivalent to ChapterTimeEnd of the last timestamp (or infinity)?


For the moment is no meaning defined for ChapterTimeStart(CTS) =3D ChapterTimeEnd(CTE) but we could/should.
In pratice such a chapter will be ignored (this makes the parsing/splitting process easier).
But I say that is not good and we lose flexibility.



The = normal way:
End times are greater as the start times. A new virtual timeline use this chapter and takes the play duration of this chapter into account.

End time equal to start time:
Lav splitter ignores such ordered chapters, cause the play duration is 0.

+1, Having an ordered chapter = where ChapterTimeStart =3D ChapterTimeEnd should be ignored.

Why should such a chapter be ignored? Ok, there is no duration and irrelevant for the new virtual timeline, but you can have other info in such chapters:
1. a deeper ordered chapter where you can find a duration
2. ChapProcess can be used
3. only use as chapter mark



= Furthermore LAV-splitter recognized only Level 1 ordered = chapters.

Is there a use case for hierarchical ordered = chapters? I'm not sure what a level 2 of an ordered chapter would do? Should an ordered chapter be permitted to have an ordered chapter as a child?

Yes there are use case's (only in an early VLC version, but not really for practice).
DVDMenuXtractor output.xml for VMG or VTS or the VTSM.
A hugh topic and to much to discribe here.
When it is ok please download my cE http://forum.gleitz.info/attachment.php?attachmentid=3D9928= 8&d=3D1486654181
You find in this email a 7zip with DMX.xml files from the Aliens DVD.

My cE reads all the XML comments und have a very nice overview about the hierarchical Matroska-DVD-Menu structure.
Then you will see that the level 5 ordered chapters are used for the new timeline.
Cause, all levels between 1 and 4 are reserved for the DVD-menu-structure.
(I have just noticed that DMX.xml files can have a start time stamp and an end time stamp with set to 00:00:00.000000000)

There are one pratice at the moment. My Matroska Menu Editor:
When I combine many files of an episode in many editions in a menu-start.mkv (all with Chapter-Segment-Linking)
and I will naviagte through = the editions/chapters it is not really handy.
For LAV splitter: In the tray icon you see many editions(thats fine). But such an edition(with 20 or more files) has a lot of chapters.
To get a better overview which chapters belong to an episode.mkv I use nested chapters.
And therfore is a complex algorithm necessary cause all chapters have to be defined twice.
First chapter (level 1) for the ordering and the new timeline duration and only the first chapter of an episode.mkv is visible, all others must be set to hidden=3Dtrue.
Second chapter (level 2) with the same time stamps(at the moment it is enough when the start time is defined), which is used as chapter mark/jump.

Here a link to a small samle with 3 cutted epsiode.mkv files
http://forum.videohelp.com/attachments/4060= 2-1487505284/MatroskaMenu_Chapter-Segment-Linking.7z
Here an other menu.xml sample.
http://forum.gleitz.info/attachment.php?attachmentid=3D9927= 9&d=3D1485686941

I reported a playback bug of such menu.xml files to VLC forum and it was fixed.
htt= ps://forum.videolan.org/viewtopic.php?f=3D2&t=3D137611 


In the videohelp forum I have discussed this with a member and he his the same opinion like me.

http://forum.videohelp.com/threads/368560-chapterEd= itor%28OGG-XML-TTXT-m-AVCHD-m-editions-mkv-Matroska-Menu%29-names-CLI?p=3D= 2425793&viewfull=3D1#post2425793


A ordered chapter with a valid duration(greater then 0) should not have nested-ordered chapters, cause it makes not sense. The duration of the nested-ordered chapter is not defined in the parent chapter-duration.

But for ordered chapters that have a 0 duration or no end time stamp a nested-ordered chapter can/should be used.  



For = this I have three possible ways in my mind.
1. Only as chapter mark
The chapter is shown to the user interface and you can jump to this point in the timeline. This is the same behaviour like ordered chapters from Level 2 and deeper. LAV-splitter ignores the "ordered" state and reads the start time only.

2. Use the ordered times from the nested ordered chapter (I prefer this option)
Nested-ordered-endtimes is a topic where I can't find infos. My theorie is that such chapters must have = then
nested chapters and the first nested chapter start time must be the start/end time of the parent = chapter.
A splitter should read than the nested-ordered play duration an takes into acount.

3. Endless loop
The frame which correspond to the start time of such a chapter is shown endless.
We could simulate a behaviour for menu's like in DVD's/Bluray's. Some user option in the player could be prohibited.

Empty end times:
This can be found in DVDMenuXtractor menu.xml = output.
In principle we could use the same 3 possibilities here like for "End time equal to start time"


Another EBML element which makes not right sense to me, is = ChapterSegmentEditionUID[6E][BC].
When such an UID is specified, the splitter should play this edition from the linked segment.
But an edition have not a start nor an end time!
What is with the specified chapter start and end time? This chapter duration must than match as a sum of all chapter play durations of the linked edition. What is when in the linked edition has chapters with linking to other editions?
Or is there an other method in use?

I've never = used ChapterSegmentEditionUID but it does seem valuable. The specification is not so clear, but my presumption would be that you'd add the ChapterTimeStart of the chapter using ChapterSegmentEditionUID to the starting time of the related Segment's Edition.

(Sorry I don't right understand)

The specs say's
"The EditionUID to play from the segment linked in ChapterSegmentUID."

A splitter generate the virtual time line but the duration info is not available/wrong, or the splitter must calculate it first.



Thanks = for reading and sorry for my bad english.

No worries. I think there is a lot to discuss = regarding chapters. Honestly I often go to http://mod16.org/hurfdurf/?p=3D8 for information about Matroska chapters rather than the more official but sparse documentation on matroska.org.
All my Matroska features in cE comes through very often reading this wonderful page.

Then perhaps some of the statements of that page = should be included within the specification. ;)

Perhaps first we could clarify the = documentation of the chapter elements in the Matroska Schema and then extend = the chapter documentation to give = descriptive sections on:
- the use of Non-Ordered Chapters
- the use of Ordered Chapters
- how to handle Chapters that reference = external Segments and/or Editions
- also a definition for the xml expression of = chapters


I will help where I can.


Best regards
Martin Below

Dave Rice



Dave Rice

Best reagrds
Martin











_______________________________________________
Matroska-devel mailing list
Matroska-devel@lists.mat=
roska.org
https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://=
dir.gmane.org/gmane.comp.multimedia.matroska.devel
_______________________________________________
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

<DVDMenuXtr= actor.7z>_______________________________________________
Matroska-devel mailing list
Matroska-devel@lists.matroska.org
https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-de= vel
Read Matroska-Devel on GMane: = http://dir.gmane.org/gmane.comp.multimedia.matroska.devel

= --Apple-Mail=_A75AECC0-304E-4148-9A2C-36E751FB1CFA-- From nobody Wed Feb 22 07:15:08 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEC3129970 for ; Wed, 22 Feb 2017 07:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.736 X-Spam-Level: X-Spam-Status: No, score=-3.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 BL4_u2GtysxD for ; Wed, 22 Feb 2017 07:15:06 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 7742312996E for ; Wed, 22 Feb 2017 07:15:05 -0800 (PST) Received: from [192.168.178.25] ([91.47.61.166]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M6Ana-1cRe4i18BO-00yBzw for ; Wed, 22 Feb 2017 16:15:02 +0100 To: cellar@ietf.org References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> <402d0e5e-4e64-2341-9a0d-a18d56a7d2c1@mediaarea.net> <62a09f2e-27ab-48e0-f7e1-afe909fec5c9@gmx.ch> <435B0D9F-9514-4976-8F31-02660246A5FD@dericed.com> From: hubblec4 Message-ID: <170b4e51-8bf5-252d-f7a8-50433bae0666@gmx.ch> Date: Wed, 22 Feb 2017 16:14:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B472662064788434F5192112" X-Provags-ID: V03:K0:NTPQJhGICRrPU5fgnMUbzFfgP1XijRgE0TMc0Db2vNGeDDkM9WZ f21EI0qfiAe3xiGuoO+BMntAXBvxRUeJFwjhPxO93NTefCYYAKEHDbYQphhoE3JjAYPzPzz zcXJb8uGdFVC7vtWh9Hu4Tld7RfxKdmtiEVBLat/ikgtrZQrx4PuZerwFVde81hNfT7xHrh 2ihCT0WR8+cxADAZHho4Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:aGNP5NQ1hSM=:DGl+4tcZfI/zOPIg8Y5tH8 NmvaqKwwWzXwGr/0nYLHNT8JSoPQj4OI3rAu5K9xE8Iu3YO0iwC9PzPgOyhEAUGRNcdw1Oqj8 ahGjPhnYotfYDii8uQi4VrH5mssk9Pk+0ZbJHrnZRaYuTH9nLao8O2rxj725wusDb9xvaGnDe ZEX3fSRsja7jWNdX4F9IwzS9p2IfBFg/FZ0mnasI6QRudAuDELUFA3j45MA5j5hNU5eIXe9Gu KR1dAoTUt0/5oQGImT7Wfga6GS+p0RsuWO1ic6odz0Lx54N9YGhs13IgAEIxKyYk3OxM05oiL b/nx8RB9pz+E0OGfQZZPQ2Niou9ndnDdWWvtvRwlKyxwHClfQQtEpl8btVry3K6MfBDQyUub8 SrtN1uK1zbFzHNwixmUXM5gVMn3JrvenZR8mTLp3fVmLViDun3lDJdIWajaEmvB4qSW1AhrZ7 1wGNmRTmlL+CIRAVmVYWOoGDWQh02DAZm6TLPLa0c2gMPMsZAuAliRffOn6tSV2WeclILWQZo UCp74umqVm6SIcTBSFVN5nmsHA97ApXklKoi0/YYLOjKi7GkmHXRd2EycOoESzaMagSa/pXop zk5HrAfggo2qPavXpYR5lxAcNaKMkl9zugdHohey1yp0gHb5ZAXt71MxxY5zBkCDspzZHI8CI hIkFeBtnVqMD7RrNeFps+OgZ83sfmcYRdU0Z0hjOi9RiNkQl9+2/plhL7tqY2K8mGt2/oCXoF Pl9tY0pxV5alK2UJ0lcVtnFgnP8xUlUjdmtjSUBDBBUybjIL1sP0T3BFdfxvkdE/2xey49T55 6ernhCA Archived-At: Subject: Re: [Cellar] [Matroska-devel] Matroska Chapters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 15:15:07 -0000 This is a multi-part message in MIME format. --------------B472662064788434F5192112 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Dave Am 22.02.2017 um 15:34 schrieb Dave Rice: > Hi, > >> On Feb 22, 2017, at 8:06 AM, hubblec4 > > wrote: >> >> Hi all >> >> >> Am 21.02.2017 um 16:37 schrieb Dave Rice: >>> Hi Martin, >>> >>>> On Feb 19, 2017, at 8:17 AM, hubblec4 >>> > wrote: >>>> >>>> Hi all >>>> >>>> I hope this topic is not too boring and we can improve/implement >>>> important "use" notes. >>>> >>>> In my chapterEditor thread was a topic "chapter.xml from makemkv" >>>> which generate non-ordered chapters with end time stamps. So far >>>> known to me there is no splitter which read the end times of >>>> non-ordered chapters. >>>> In Mosu's new Chapter Editor is it not more possible to set the >>>> start times equal to the end times. >>>> The DVDMenuXtractor generate ordered chapters without an end time >>>> stamp. >>>> >>>> What is the correct behavior? >>> >>> Good point. Is there any purpose to ChapterTimeEnd if the chapters >>> are non-ordered? >> >> No there is no purpose! But as info it is maybe important. > > I thought about this more later. When the playback point is greater > than or equal to the chapter start time and less than the chapter end > time, a player could display the title of that chapter. So for instance > > chapter1 00:01-00:03 > chapter2 00:05-00:07 > > At 00:02, the player could display that the playback is within chapter1. > At 00:04, the player could display that it it outside a chapter. > Your 2 chapters (use in an ordered edition) will interpereted to a new virtual timeline as follows: chapter1: start time 00:00 - 2minutes duration - end time 00:02(not included) chapter2: start time 00:02 - 2minutes duration - end time 00:04(not included) At 00:02, the player could display that the playback is within chapter2 ot chapter1. At 00:04, the chapter point is behind the new virtual timeline. ChapterTime stamps in ordered editions are not the defined time stamps, all time stamps must be recalculated to virtual time stamps. Only for simple ordered editions (1 edition with continuous ordered chapters) are defined time stamps equal to virtual time stamps. > If the end times are omitted, then 00:04 would be inferred to be part > of chapter1. > Perhaps we could define that chapters are ranges rather than points in > time and that if omitted then the end time is whatever comes first, > the next sibling chapter start in time or the end of the segment. > No 100% clear what you mean, but it sound not really good to me. >> A short description: >> When you create mkv's with makemkv and you need ordered >> editions/chapters, so it is easy to build an ordered editon. >> In practice: >> You load such an mkv to Mosu's Chapter Editor(CE), then enable the >> EditionFlagOrdered=1 and all fine, cause the end times was allready >> exists. If there are no end times you must enter all end times >> manually (a lot of work). >> Mosu's CE has no function to create/calculate ordered end times, but >> my chaperEditor(cE) has such a function. >> An other problem of ordered chapter end times, is the last chapter. >> The end time of the last chapter must be the duration of the video(in >> normal situations), but this info is nowhere strored in a chapter.xml >> (only in an mkv where it is possible to extract the play duration info). > > mkvpropedit supports chapter xml with an ordered edition without an > end time. I use this to create one chapter edition which refers to the > entire segment, whereas another chapter edition references only part > of it. So it is like: > > > 1 > 0 > 0 > 12338659363134957115 > > 00:00:00.000000000 > 0 > 1 > 14022955415078936670 > > Full > eng > > > > > Any issue with no ChapterTimeEnd in an ordered edition? This case is only working with a "normal mkv", like a single episode. But what is with multi-Edition-Title mkv's created from multi-Edition Blurays? The end of a segment is different to the end of an edition. In such mkv's you have one first edition with the ordered m2ts contents and at the end are all other m2ts files. In this case your chapter-sample plays to long. Martin Below --------------B472662064788434F5192112 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Dave

Am 22.02.2017 um 15:34 schrieb Dave Rice:
Hi,

On Feb 22, 2017, at 8:06 AM, hubblec4 <hubblec4@gmx.ch> wrote:

Hi all


Am 21.02.2017 um 16:37 schrieb Dave Rice:
Hi Martin,

On Feb 19, 2017, at 8:17 AM, hubblec4 <hubblec4@gmx.ch> wrote:

Hi all

I hope this topic is not too boring and we can improve/implement important "use" notes.

In my chapterEditor thread was a topic "chapter.xml from makemkv" which generate non-ordered chapters with end time stamps. So far known to me there is no splitter which read the end times of non-ordered chapters.
In Mosu's new Chapter Editor is it not more possible to set the start times equal to the end times.
The DVDMenuXtractor generate ordered chapters without an end time stamp.

What is the correct behavior?

Good point. Is there any purpose to ChapterTimeEnd if the chapters are non-ordered?

No there is no purpose! But as info it is maybe important.

I thought about this more later. When the playback point is greater than or equal to the chapter start time and less than the chapter end time, a player could display the title of that chapter. So for instance

chapter1 00:01-00:03
chapter2 00:05-00:07

At 00:02, the player could display that the playback is within chapter1.
At 00:04, the player could display that it it outside a chapter.


Your 2 chapters (use in an ordered edition) will interpereted to a new virtual timeline as follows:

chapter1: start time 00:00 - 2minutes duration - end time 00:02(not included)
chapter2: start time 00:02 - 2minutes duration - end time 00:04(not included)

At 00:02, the player could display that the playback is within chapter2 ot chapter1.
At 00:04, the chapter point is behind the new virtual timeline.

ChapterTime stamps in ordered editions are not the defined time stamps, all time stamps must be recalculated to virtual time stamps.
Only for simple ordered editions (1 edition with continuous ordered chapters) are defined time stamps equal to virtual time stamps.

If the end times are omitted, then 00:04 would be inferred to be part of chapter1.
Perhaps we could define that chapters are ranges rather than points in time and that if omitted then the end time is whatever comes first, the next sibling chapter start in time or the end of the segment.


No 100% clear what you mean, but it sound not really good to me.
 



A short description:
When you create mkv's with makemkv and you need ordered editions/chapters, so it is easy to build an ordered editon.
In practice:
You load such an mkv to Mosu's Chapter Editor(CE), then enable the EditionFlagOrdered=1 and all fine, cause the end times was allready exists. If there are no end times you must enter all end times manually (a lot of work).
Mosu's CE has no function to create/calculate ordered end times, but my chaperEditor(cE) has such a function.
An other problem of ordered chapter end times, is the last chapter. The end time of the last chapter must be the duration of the video(in normal situations), but this info is nowhere strored in a chapter.xml (only in an mkv where it is possible to extract the play duration info).

mkvpropedit supports chapter xml with an ordered edition without an end time. I use this to create one chapter edition which refers to the entire segment, whereas another chapter edition references only part of it. So it is like:

<EditionEntry>
    <EditionFlagOrdered>1</EditionFlagOrdered>
    <EditionFlagHidden>0</EditionFlagHidden>
    <EditionFlagDefault>0</EditionFlagDefault>
    <EditionUID>12338659363134957115</EditionUID>
    <ChapterAtom>
      <ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
      <ChapterFlagHidden>0</ChapterFlagHidden>
      <ChapterFlagEnabled>1</ChapterFlagEnabled>
      <ChapterUID>14022955415078936670</ChapterUID>
      <ChapterDisplay>
        <ChapterString>Full</ChapterString>
        <ChapterLanguage>eng</ChapterLanguage>
      </ChapterDisplay>
    </ChapterAtom>
  </EditionEntry>

Any issue with no ChapterTimeEnd in an ordered edition?

This case is only working with a "normal mkv", like a single episode.
But what is with multi-Edition-Title mkv's created from multi-Edition Blurays?
The end of a segment is different to the end of an edition.
In such mkv's you have one first edition with the ordered m2ts contents and at the end are all other m2ts files.
In this case your chapter-sample plays to long.


Martin Below
--------------B472662064788434F5192112-- From nobody Thu Feb 23 03:25:15 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643BC1296CB for ; Thu, 23 Feb 2017 03:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.236 X-Spam-Level: X-Spam-Status: No, score=-4.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 g2_4IVNUCXw0 for ; Thu, 23 Feb 2017 03:25:11 -0800 (PST) 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 BC0841296AB for ; Thu, 23 Feb 2017 03:25:10 -0800 (PST) Received: from [192.168.178.25] ([91.47.61.152]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M9Jss-1cUFXo415K-00Cexg for ; Thu, 23 Feb 2017 12:25:07 +0100 To: cellar@ietf.org References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> <402d0e5e-4e64-2341-9a0d-a18d56a7d2c1@mediaarea.net> <62a09f2e-27ab-48e0-f7e1-afe909fec5c9@gmx.ch> <435B0D9F-9514-4976-8F31-02660246A5FD@dericed.com> From: hubblec4 Message-ID: <30711a01-dbd9-f90f-dbe5-62bf0c74b5a8@gmx.ch> Date: Thu, 23 Feb 2017 12:24:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1EB3ADC44F8931B2CF429413" X-Provags-ID: V03:K0:RGTTt17dqFWaFRzAViE013r+GmePqDxuU7d8fbUlHLVKG4WYyzB O0ZEHsUUu61zskwB0kKrEgEsKmnxOJwyVEtUCumZj+m+cjm3JeBtsC1Fc6SvuBRjdn2dAIu G0uaRG9IQ5pAdWrNRtkcLKhRSh4H0GXJwkpHT33BLakZ//kpHSu0jrd4VbJQtWO3kfMFYl7 Otz51A6s8TTszdqtbrQGA== X-UI-Out-Filterresults: notjunk:1;V01:K0:tvnXat3kU38=:+yoXgvB8JuzN9+qpoIwmoE 9BYugHDll+l2V9VN9xQS2zT2IhsJvj0bHhzybaC19yrwO+clZyGciQX6le4swGmmR23uP1O8m lD+wDD2gVF0M2iIDpF4AbH4dVGLBWx0uEDCx8zfQKeETpjoynVs0Rb3zXd4k2NxnaljSAGKoK qVoBNQsAZfFnY865GPBbk1w4V1L67iECQJO8CNY3930Omy/Xvu01heV4FwgZMMC5rbIwAN/yq nCGD6Ir9FzResJc/XCp6zgw+U4i4WjH/q5NyomjavMfXPX8dVae01Zy5FCMEDvaZbkUaPZcLN Hr1XyCxFI6bubo3N8MB5zTdbsZUQektLHtHK0cuNk4juFvvcxr1Ux6dbezFE2SkUod0hA6Ya6 Uo2VaRTW9a3cHxcd6DorKjBgjQafP1TfKD0IzyFQAl+AhVtBABSZ2RN22rgWSIG5V7+ROr8+y u31rN2AzPe0vGN+9lkf8bBBupij1ecUJzu5HHXWxSrbnK9CUoCdWRMKbUFd/etHG/bEMSXl7n /sgz4GFWuY80uFj88nhofb375Y54+MPS+zqfzgb4iZVXiXucRNA7af7klub7mnykNtZ/j30Na OeYcfliDsb8emZfCOqz/A/b9lOFu3xg0i5aaixB1gyd76XmkqQCVE7CiFt2dCWyoW6C9GF8LF XwqCNtpArV155k2r8Ps0t6CMbjIE7nmSENURKQOSq6R0JnuPdYWhaoCLra6QA/8afXkxYOBAD fFHL3LdsjRhgQsxy3F1KtceeArvYc2pbFJF4RvdGMQJszOyoo4VkgDc8ebLOk1GKqUju17tbe o15m2Z2 Archived-At: Subject: Re: [Cellar] [Matroska-devel] Matroska Chapters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 23 Feb 2017 11:25:13 -0000 This is a multi-part message in MIME format. --------------1EB3ADC44F8931B2CF429413 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Dave Am 22.02.2017 um 15:34 schrieb Dave Rice: > >>> >>>> Ordered-chapter end times can be set to "empty", equal or greater >>>> as the start time but never smaller as the start time. >>> >>> That makes sense to me, though is there any meaning of >>> ChapterTimeStart = ChapterTimeEnd? Is an empty ChapterTimeEnd >>> semantically equivalent to ChapterTimeStart = ChapterTimeEnd or >>> equivalent to ChapterTimeEnd of the last timestamp (or infinity)? >>> >> >> For the moment is no meaning defined for ChapterTimeStart(CTS) = >> ChapterTimeEnd(CTE) but we could/should. >> In pratice such a chapter will be ignored (this makes the >> parsing/splitting process easier). >> But I say that is not good and we lose flexibility. >> >> >> >>>> The normal way: >>>> End times are greater as the start times. A new virtual timeline >>>> use this chapter and takes the play duration of this chapter into >>>> account. >>>> >>>> End time equal to start time: >>>> Lav splitter ignores such ordered chapters, cause the play duration >>>> is 0. >>> >>> +1, Having an ordered chapter where ChapterTimeStart = >>> ChapterTimeEnd should be ignored. >> >> Why should such a chapter be ignored? Ok, there is no duration and >> irrelevant for the new virtual timeline, but you can have other info >> in such chapters: >> 1. a deeper ordered chapter where you can find a duration >> 2. ChapProcess can be used >> 3. only use as chapter mark >> >> >>> >>>> Furthermore LAV-splitter recognized only Level 1 ordered chapters. >>> >>> Is there a use case for hierarchical ordered chapters? I'm not sure >>> what a level 2 of an ordered chapter would do? Should an ordered >>> chapter be permitted to have an ordered chapter as a child? >> In the Matroska specs(Chapters) section "DVD menu", the following is written: "Each level of a chapter corresponds to a logical level in the DVD system that is stored in the first octet of the ChapProcessPrivate." Like in DMX output.xml files are the start time stamps equal to the end time stamps. When we forbidden such ordered chapters we break the Matroska-DVD-Menu system. It is recommend to say ordered chapters with start time equal to the end time, must have a nested-ordered chapter. Otherwise such a chapter is used for chapter mark only (or for menu navigation commands stored in the ChapProcess section). I'm not really interessted in Matroska-DVD-Menu system, it is to hugh, to complex. But I will bring to life the Matroska-Native-Menu system. I'm sure I will need nested-ordered-chapters for this. Best regards Martin Below --------------1EB3ADC44F8931B2CF429413 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Dave


Am 22.02.2017 um 15:34 schrieb Dave Rice:


Ordered-chapter end times can be set to "empty", equal or greater as the start time but never smaller as the start time.

That makes sense to me, though is there any meaning of ChapterTimeStart = ChapterTimeEnd? Is an empty ChapterTimeEnd semantically equivalent to ChapterTimeStart = ChapterTimeEnd or equivalent to ChapterTimeEnd of the last timestamp (or infinity)?


For the moment is no meaning defined for ChapterTimeStart(CTS) = ChapterTimeEnd(CTE) but we could/should.
In pratice such a chapter will be ignored (this makes the parsing/splitting process easier).
But I say that is not good and we lose flexibility.



The normal way:
End times are greater as the start times. A new virtual timeline use this chapter and takes the play duration of this chapter into account.

End time equal to start time:
Lav splitter ignores such ordered chapters, cause the play duration is 0.

+1, Having an ordered chapter where ChapterTimeStart = ChapterTimeEnd should be ignored.

Why should such a chapter be ignored? Ok, there is no duration and irrelevant for the new virtual timeline, but you can have other info in such chapters:
1. a deeper ordered chapter where you can find a duration
2. ChapProcess can be used
3. only use as chapter mark



Furthermore LAV-splitter recognized only Level 1 ordered chapters.

Is there a use case for hierarchical ordered chapters? I'm not sure what a level 2 of an ordered chapter would do? Should an ordered chapter be permitted to have an ordered chapter as a child?



In the Matroska specs(Chapters) section "DVD menu", the following is written:
"Each level of a chapter corresponds to a logical level in the DVD system that is stored in the first octet of the ChapProcessPrivate."

Like in DMX output.xml files are the start time stamps equal to the end time stamps.
When we forbidden such ordered chapters we break the Matroska-DVD-Menu system.
It is recommend to say ordered chapters with start time equal to the end time, must have a nested-ordered chapter.
Otherwise such a chapter is used for chapter mark only (or for menu navigation commands stored in the ChapProcess section).

I'm not really interessted in Matroska-DVD-Menu system, it is to hugh, to complex.
But I will bring to life the Matroska-Native-Menu system. I'm sure I will need nested-ordered-chapters for this.


Best regards
Martin Below



 --------------1EB3ADC44F8931B2CF429413-- From nobody Thu Feb 23 20:18: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 DAAC61294F4 for ; Thu, 23 Feb 2017 20:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK9xlJbU5TPc for ; Thu, 23 Feb 2017 20:18:13 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9CD129508 for ; Thu, 23 Feb 2017 20:18:12 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:42736 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1ch7KZ-001bxh-Ko; Thu, 23 Feb 2017 23:18:11 -0500 From: Dave Rice Message-Id: <922C5404-EC19-462D-A836-C952E66C2FD8@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BA9E8517-4549-4CD8-82E3-246E08BFD4CF" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 23 Feb 2017 23:18:05 -0500 In-Reply-To: To: Jerome Martinez References: <2651a6f3-9c9a-6f76-2ee7-4d5c23b1ce57@mediaarea.net> X-Mailer: Apple Mail (2.3259) 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: Cc: cellar@ietf.org Subject: Re: [Cellar] Ancillary data in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 04:18:15 -0000 --Apple-Mail=_BA9E8517-4549-4CD8-82E3-246E08BFD4CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, > On Jan 7, 2017, at 11:57 AM, Dave Rice wrote: [=E2=80=A6] >> On Dec 27, 2016, at 3:22 PM, Jerome Martinez = wrote: [=E2=80=A6] >> "N_" prefix arbitrary used (2nd letter of "Ancillary" because first = letter is already used) >=20 > Please also add a patch for the TrackType Element in ebml_matroska.xml = as we=E2=80=99ll need an unsigned integer to represent the = =E2=80=98ancillary=E2=80=99 type of track. >=20 >> N_QUICKTIME: is a pure copy of V_QUICKTIME and A_QUICKTIME already = supported in Matroska, N_ would be used which would be used for e.g. = tmcd codec (QuickTime time code). Exactly same principles as video and = audio. Note that classic usage is to store only the first frame content = and other content is computed from it, so a player would have to read = the first frame even if there is a direct seek request to another place; = this could be avoided with some "hack" in the track header, could be the = next step after this one is accepted. >=20 > Would need a clear caveat in the definition that this implementation = would only support storage of the first timecode value and computation = of each additional value. A transwrap from a mov file with a timecode = track that uses an edit list to handle non-continuous timecode could not = be a lossless transwrap in this case, since the edit list would be lost = and the new timecode track in the Matroska file would appear continuous. >=20 > Also reference to tmcd atom is not clear enough. Is it tref/tmcd, = gmhd/tmcd, stsd/tmcd. >=20 > If this is stsd/tmcd (I presume), then what time scale should be used? = The time scale stored in tmcd or the time scale of the Matroska track? >=20 > I like that copying stsd/tmcd copies in the timecode label as well. I started a draft of a PR for defining QuickTime-style timecode in = Matroska based on Jerome=E2=80=99s suggestion, see = https://github.com/Matroska-Org/matroska-specification/pull/102 = . I = left CodecPrivate as containing the entire Sample description table = array of the stsd atom, rather than starting after the track type atom = (such as the image descriptor, sound descriptor), because in the case of = timecode, values of the tmcd are needed to interpret what the successive = timecode values will be. The description of the Codec Mapping uses = timecode as an example of ancillary data but not exclusively. Perhaps we = should constrain what quicktime media types are relevant here, as = several of the media types defined at = https://developer.apple.com/library/content/documentation/QuickTime/QTFF/Q= TFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-SW1 = could be = considered as ancillary. Comments? Best Regards, Dave Rice --Apple-Mail=_BA9E8517-4549-4CD8-82E3-246E08BFD4CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,

On Jan 7, 2017, at 11:57 AM, = Dave Rice <dave@dericed.com> wrote:

[=E2=80=A6]

On Dec 27, 2016, at 3:22 PM, Jerome Martinez = <jerome@mediaarea.net> = wrote:

[=E2=80=A6]

"N_" prefix arbitrary used (2nd letter of = "Ancillary" because first letter is already used)

Please also add a patch for the = TrackType Element in ebml_matroska.xml as we=E2=80=99ll need an unsigned = integer to represent the =E2=80=98ancillary=E2=80=99 type of track.

N_QUICKTIME: is a pure copy of V_QUICKTIME and A_QUICKTIME = already supported in Matroska, N_ would be used which would be used for = e.g. tmcd codec (QuickTime time code). Exactly same principles as video = and audio. Note that classic usage is to store only the first frame = content and other content is computed from it, so a player would have to = read the first frame even if there is a direct seek request to another = place; this could be avoided with some "hack" in the track header, could = be the next step after this one is accepted.

Would need a clear caveat in the = definition that this implementation would only support storage of the = first timecode value and computation of each additional value. A = transwrap from a mov file with a timecode track that uses an edit list = to handle non-continuous timecode could not be a lossless transwrap in = this case, since the edit list would be lost and the new timecode track = in the Matroska file would appear continuous.

Also reference to tmcd atom is not clear enough. Is it = tref/tmcd, gmhd/tmcd, stsd/tmcd.

If this is = stsd/tmcd (I presume), then what time scale should be used? The time = scale stored in tmcd or the time scale of the Matroska track?

I like that copying stsd/tmcd copies in the = timecode label as well.

I started a draft of a PR for defining = QuickTime-style timecode in Matroska based on Jerome=E2=80=99s = suggestion, see https://github.com/Matroska-Org/matroska-specification/pull/102= . I left CodecPrivate as containing the entire Sample description = table array of the stsd atom, rather than starting after the track type = atom (such as the image descriptor, sound descriptor), because in the = case of timecode, values of the tmcd are needed to interpret what the = successive timecode values will be. The description of the Codec Mapping = uses timecode as an example of ancillary data but not exclusively. = Perhaps we should constrain what quicktime media types are relevant = here, as several of the media types defined at https://developer.apple.com/library/content/documentation/Quick= Time/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-SW1 could be considered as ancillary. Comments?

Best Regards,
Dave Rice

= --Apple-Mail=_BA9E8517-4549-4CD8-82E3-246E08BFD4CF-- From nobody Fri Feb 24 03:32:16 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40F41294D5 for ; Fri, 24 Feb 2017 03:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wbREMWLauChv for ; Fri, 24 Feb 2017 03:32:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 09AF31293EE for ; Fri, 24 Feb 2017 03:32:10 -0800 (PST) Received: from [192.168.178.25] ([91.47.61.33]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MVNDK-1cpYlq01hG-00Yi6Q for ; Fri, 24 Feb 2017 12:32:08 +0100 To: cellar@ietf.org References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> <402d0e5e-4e64-2341-9a0d-a18d56a7d2c1@mediaarea.net> <62a09f2e-27ab-48e0-f7e1-afe909fec5c9@gmx.ch> <435B0D9F-9514-4976-8F31-02660246A5FD@dericed.com> <170b4e51-8bf5-252d-f7a8-50433bae0666@gmx.ch> From: hubblec4 Message-ID: <1ad0a0cc-a7dc-1f83-a796-954cad908d90@gmx.ch> Date: Fri, 24 Feb 2017 12:31:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <170b4e51-8bf5-252d-f7a8-50433bae0666@gmx.ch> Content-Type: multipart/alternative; boundary="------------3936176213A140F6BEBAC8F7" X-Provags-ID: V03:K0:5VUDcLqeWgB+NTwPjMwzdO7LpdI2JtFmLXHoWQxpOsn76jPh5Nj GS+Gwu+XFpi3h3NmFPUVv+I0u3QTGfaOP+l7qGLsI8j6Mv8Va87UJ+CZMpog7uDdbzpCG9m ALTksXRdXbSFL52sF87o03ZnayFxzQ5l6PkY0JCmaY5noSciZhJp8Kfx5jcHSfj1ynpEFMG Z/C20AnzdAqlEikmBXEhw== X-UI-Out-Filterresults: notjunk:1;V01:K0:+JVo+Kml6ao=:siKYoa4GRavgnj1KwTf0tq jf2XCMZYEPLwS0OVd8sXpF/XizUxMLzr7+0cTTqoZqzD2ok8ATiTlfPgWkKXPFGmguO0a6h14 nO5S1NUevdlkLINulQJSygB9ulpfhtRrdWR/1ss1dpeP7+pyGFN7ECjntB7/oxcg0FDtBtPbj vY4PCjYnOH6NH79sTnA2iOwT4IQBsL+Jidmekvfqb0oRMZhWypqI8I3yRWW/TAIxzPYj65jO1 0e59jhOhwT0cDJMR/9Jk6qnGabHTZ1oH/Xegjxw4UkRfBpzAIZ3wttTbcJngNenU8EU57R/wn 9haXsLK9UIo8cHlRqe06pMt4jYrm2TalJcz2tPtaiFKQC/9eI9hGGJN0noP30WnV2WlzIW51a A5O0y3gKtDTy45TUDBhFN1N0Jc0lWFDEYS0L9YHw1Zzxvu9tdmTwh3CBNlTkZ2gQc1PhW6PGL m4PSYkAfkDSy1mi/RPGpbWYL70hsLtJx7hX1LwxDMtREE5EMQYqIuHK2E2F5hxweygBD7RSPt NgVpMftLP9ByPPVS3BI3/RbTDnBYrXCWWu7urzcIlJqJ/ixxdxmmRMC82RJzOoWqwL4O0rdOw 5GHgrPlB+rN0K00LRW9Z5OpTyP7kElW1tDvPH0c5+Mm7icDBqVvFHstfb40I0A3JU0D7/SFf0 jUl+RdwPjgZ2jt/7cCK/IH9P7vHxktHNnbXLq/YqOPGJycUQDqedYbjYbabhJtPfX4Fj8Er0K GAkkSk3llPmRrZTjrtd+I4AqybutdRFaTbRn2VD95hhApGm3ZE+m0oiC/ha/XOkOf0GoDmOLL 8JmbuUo Archived-At: Subject: Re: [Cellar] [Matroska-devel] Matroska Chapters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 24 Feb 2017 11:32:14 -0000 This is a multi-part message in MIME format. --------------3936176213A140F6BEBAC8F7 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Dave I found this on github: VLC supports Matroska-DVD-Menu system, uses "SegmentFamily" and read all the Chapter-Process commands. Here a link to the source code of the mkv-demuxer. https://github.com/videolan/vlc/tree/master/modules/demux/mkv Martin Below Am 22.02.2017 um 16:14 schrieb hubblec4: > Hi Dave > > Am 22.02.2017 um 15:34 schrieb Dave Rice: >> Hi, >> >>> On Feb 22, 2017, at 8:06 AM, hubblec4 >> > wrote: >>> >>> Hi all >>> >>> >>> Am 21.02.2017 um 16:37 schrieb Dave Rice: >>>> Hi Martin, >>>> >>>>> On Feb 19, 2017, at 8:17 AM, hubblec4 >>>> > wrote: >>>>> >>>>> Hi all >>>>> >>>>> I hope this topic is not too boring and we can improve/implement >>>>> important "use" notes. >>>>> >>>>> In my chapterEditor thread was a topic "chapter.xml from makemkv" >>>>> which generate non-ordered chapters with end time stamps. So far >>>>> known to me there is no splitter which read the end times of >>>>> non-ordered chapters. >>>>> In Mosu's new Chapter Editor is it not more possible to set the >>>>> start times equal to the end times. >>>>> The DVDMenuXtractor generate ordered chapters without an end time >>>>> stamp. >>>>> >>>>> What is the correct behavior? >>>> >>>> Good point. Is there any purpose to ChapterTimeEnd if the chapters >>>> are non-ordered? >>> >>> No there is no purpose! But as info it is maybe important. >> >> I thought about this more later. When the playback point is greater >> than or equal to the chapter start time and less than the chapter end >> time, a player could display the title of that chapter. So for instance >> >> chapter1 00:01-00:03 >> chapter2 00:05-00:07 >> >> At 00:02, the player could display that the playback is within chapter1. >> At 00:04, the player could display that it it outside a chapter. >> > > Your 2 chapters (use in an ordered edition) will interpereted to a new > virtual timeline as follows: > > chapter1: start time 00:00 - 2minutes duration - end time 00:02(not > included) > chapter2: start time 00:02 - 2minutes duration - end time 00:04(not > included) > > At 00:02, the player could display that the playback is within > chapter2 ot chapter1. > At 00:04, the chapter point is behind the new virtual timeline. > > ChapterTime stamps in ordered editions are not the defined time > stamps, all time stamps must be recalculated to virtual time stamps. > Only for simple ordered editions (1 edition with continuous ordered > chapters) are defined time stamps equal to virtual time stamps. > >> If the end times are omitted, then 00:04 would be inferred to be part >> of chapter1. >> Perhaps we could define that chapters are ranges rather than points >> in time and that if omitted then the end time is whatever comes >> first, the next sibling chapter start in time or the end of the segment. >> > > No 100% clear what you mean, but it sound not really good to me. > > > > >>> A short description: >>> When you create mkv's with makemkv and you need ordered >>> editions/chapters, so it is easy to build an ordered editon. >>> In practice: >>> You load such an mkv to Mosu's Chapter Editor(CE), then enable the >>> EditionFlagOrdered=1 and all fine, cause the end times was allready >>> exists. If there are no end times you must enter all end times >>> manually (a lot of work). >>> Mosu's CE has no function to create/calculate ordered end times, but >>> my chaperEditor(cE) has such a function. >>> An other problem of ordered chapter end times, is the last chapter. >>> The end time of the last chapter must be the duration of the >>> video(in normal situations), but this info is nowhere strored in a >>> chapter.xml (only in an mkv where it is possible to extract the play >>> duration info). >> >> mkvpropedit supports chapter xml with an ordered edition without an >> end time. I use this to create one chapter edition which refers to >> the entire segment, whereas another chapter edition references only >> part of it. So it is like: >> >> >> 1 >> 0 >> 0 >> 12338659363134957115 >> >> 00:00:00.000000000 >> 0 >> 1 >> 14022955415078936670 >> >> Full >> eng >> >> >> >> >> Any issue with no ChapterTimeEnd in an ordered edition? > > This case is only working with a "normal mkv", like a single episode. > But what is with multi-Edition-Title mkv's created from multi-Edition > Blurays? > The end of a segment is different to the end of an edition. > In such mkv's you have one first edition with the ordered m2ts > contents and at the end are all other m2ts files. > In this case your chapter-sample plays to long. > > > Martin Below > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --------------3936176213A140F6BEBAC8F7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Dave

I found this on github:
VLC supports Matroska-DVD-Menu system, uses "SegmentFamily" and read all the Chapter-Process commands.
Here a link to the source code of the mkv-demuxer.
https://github.com/videolan/vlc/tree/master/modules/demux/mkv


Martin Below




Am 22.02.2017 um 16:14 schrieb hubblec4:
Hi Dave

Am 22.02.2017 um 15:34 schrieb Dave Rice:
Hi,

On Feb 22, 2017, at 8:06 AM, hubblec4 <hubblec4@gmx.ch> wrote:

Hi all


Am 21.02.2017 um 16:37 schrieb Dave Rice:
Hi Martin,

On Feb 19, 2017, at 8:17 AM, hubblec4 <hubblec4@gmx.ch> wrote:

Hi all

I hope this topic is not too boring and we can improve/implement important "use" notes.

In my chapterEditor thread was a topic "chapter.xml from makemkv" which generate non-ordered chapters with end time stamps. So far known to me there is no splitter which read the end times of non-ordered chapters.
In Mosu's new Chapter Editor is it not more possible to set the start times equal to the end times.
The DVDMenuXtractor generate ordered chapters without an end time stamp.

What is the correct behavior?

Good point. Is there any purpose to ChapterTimeEnd if the chapters are non-ordered?

No there is no purpose! But as info it is maybe important.

I thought about this more later. When the playback point is greater than or equal to the chapter start time and less than the chapter end time, a player could display the title of that chapter. So for instance

chapter1 00:01-00:03
chapter2 00:05-00:07

At 00:02, the player could display that the playback is within chapter1.
At 00:04, the player could display that it it outside a chapter.


Your 2 chapters (use in an ordered edition) will interpereted to a new virtual timeline as follows:

chapter1: start time 00:00 - 2minutes duration - end time 00:02(not included)
chapter2: start time 00:02 - 2minutes duration - end time 00:04(not included)

At 00:02, the player could display that the playback is within chapter2 ot chapter1.
At 00:04, the chapter point is behind the new virtual timeline.

ChapterTime stamps in ordered editions are not the defined time stamps, all time stamps must be recalculated to virtual time stamps.
Only for simple ordered editions (1 edition with continuous ordered chapters) are defined time stamps equal to virtual time stamps.

If the end times are omitted, then 00:04 would be inferred to be part of chapter1.
Perhaps we could define that chapters are ranges rather than points in time and that if omitted then the end time is whatever comes first, the next sibling chapter start in time or the end of the segment.


No 100% clear what you mean, but it sound not really good to me.
 



A short description:
When you create mkv's with makemkv and you need ordered editions/chapters, so it is easy to build an ordered editon.
In practice:
You load such an mkv to Mosu's Chapter Editor(CE), then enable the EditionFlagOrdered=1 and all fine, cause the end times was allready exists. If there are no end times you must enter all end times manually (a lot of work).
Mosu's CE has no function to create/calculate ordered end times, but my chaperEditor(cE) has such a function.
An other problem of ordered chapter end times, is the last chapter. The end time of the last chapter must be the duration of the video(in normal situations), but this info is nowhere strored in a chapter.xml (only in an mkv where it is possible to extract the play duration info).

mkvpropedit supports chapter xml with an ordered edition without an end time. I use this to create one chapter edition which refers to the entire segment, whereas another chapter edition references only part of it. So it is like:

<EditionEntry>
    <EditionFlagOrdered>1</EditionFlagOrdered>
    <EditionFlagHidden>0</EditionFlagHidden>
    <EditionFlagDefault>0</EditionFlagDefault>
    <EditionUID>12338659363134957115</EditionUID>
    <ChapterAtom>
      <ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
      <ChapterFlagHidden>0</ChapterFlagHidden>
      <ChapterFlagEnabled>1</ChapterFlagEnabled>
      <ChapterUID>14022955415078936670</ChapterUID>
      <ChapterDisplay>
        <ChapterString>Full</ChapterString>
        <ChapterLanguage>eng</ChapterLanguage>
      </ChapterDisplay>
    </ChapterAtom>
  </EditionEntry>

Any issue with no ChapterTimeEnd in an ordered edition?

This case is only working with a "normal mkv", like a single episode.
But what is with multi-Edition-Title mkv's created from multi-Edition Blurays?
The end of a segment is different to the end of an edition.
In such mkv's you have one first edition with the ordered m2ts contents and at the end are all other m2ts files.
In this case your chapter-sample plays to long.


Martin Below


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

--------------3936176213A140F6BEBAC8F7-- From nobody Sun Feb 26 07:59: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 33998129970 for ; Sun, 26 Feb 2017 07:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.653 X-Spam-Level: X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_NEUTRAL=0.652] 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 KOhE1d8H8cno for ; Sun, 26 Feb 2017 07:59:27 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA241298D0 for ; Sun, 26 Feb 2017 07:59:27 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:47624 helo=[10.0.1.18]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1ci1EL-000sBk-1G; Sun, 26 Feb 2017 10:59:26 -0500 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ACC2FCF7-0E49-4ADC-A5BF-9AF44DCB7232" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Sun, 26 Feb 2017 10:59:22 -0500 In-Reply-To: <20160802105623.665a7a7059d7ee80bb4d670165c8327d.3e3d408fe7.wbe@email03.godaddy.com> To: Doug Ewell References: <20160802105623.665a7a7059d7ee80bb4d670165c8327d.3e3d408fe7.wbe@email03.godaddy.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: Cc: cellar@ietf.org Subject: Re: [Cellar] Language codes in Matroska and EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 15:59:29 -0000 --Apple-Mail=_ACC2FCF7-0E49-4ADC-A5BF-9AF44DCB7232 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Doug and others, I created a pull request to add an BCP47 contextualized Language Element = everywhere there was an existing ISO 639-2 Language Element, and updated = documentation to give precedence to the BCP47 version when available. = https://github.com/Matroska-Org/matroska-specification/pull/103/files = . For the old ISO 639-2 Elements I added a disclaimer like this: > This Element MUST be ignored if the LanguageIETF Element is used in = the same TrackEntry. The new BCP 47 Language Elements are defined like this: > Specifies the language of the track according to BCP 47 and using the IANA Language Subtag Registry. For reference there are three Language Elements in Matroska: Language = (to provide the Language of a related Track), TagLanguage (to give the = name used in a piece of metadata), ChapLanguage (to give the language of = the label of a Chapter). Comments? Dave Rice > On Aug 2, 2016, at 1:56 PM, Doug Ewell wrote: >=20 > Thanks to J=C3=A9r=C3=B4me and Moritz for pointing to the January = discussion > about language coding. >=20 > It looks like the discussion originally focused on expanding the > existing data element in Matroska to incorporate ISO 639-3. Later > discussion was on truly adopting BCP 47, and maintaining compatibility > with existing Matroska implementations by creating a new, BCP > 47-compliant language element that would take precedence over the > existing one. This seems sensible and would allow data producers to > migrate to the BCP 47 approach over time. >=20 > An important detail about BCP 47 is that compliant applications use = the > IANA Language Subtag Registry [1] as their canonical source for = language > subtags (codes) and other subtags, and NOT the ISO standards directly. > The Registry is maintained carefully through IANA to be compatible = with > the ISO standards, except when doing so would cause conflicts or > incompatibility. >=20 > For example, the chaos that ensued in 2003 when ISO 3166/MA reassigned > the retired code element [CS] to mean "Serbia and Montenegro," when > numerous applications were still using it to mean "Czechoslovakia," > would have caused very little trouble if BCP 47 had existed, because a > numeric replacement code would have been chosen for Serbia and > Montenegro to resolve the conflict. >=20 > So it's important to steer clear of statements like "RFC 5646 = recommends > to use ISO 639 when it is possible" and "RFC 5646 recommends 2-letter > codes when 3-letters codes are not necessary," because what RFC 5646 > actually says is to use the subtags that are in the Registry. >=20 > Another important point is that parsing a BCP 47 tag to remove all but > the primary language subtag is dead simple: just stop right before the > first hyphen, if any. So "sr-Latin-ME" becomes "sr". There is no need = to > worry about whether the primary language subtag is 2 or 3 letters = long. > The only exceptions are for the grandfathered tags "i-default" and > "i-mingo" and for private-use tags starting with "x-", all of which = are > unlikely to occur in multimedia data. There are well-defined matching > mechanisms for more complex scenarios; see RFC 4647. >=20 > BCP 47 (sometimes as "RFC 5646" or its predecessors) is referenced > normatively in more than 60 RFCs, and informatively in another 20, = plus > numerous drafts. So there is no question that it is widely supported! >=20 > Please feel free to contact the ietf-languages mailing list [2] with = any > questions concerning BCP 47. >=20 > [1] http://www.iana.com/assignments/language-subtag-registry > [2] http://www.alvestrand.no/mailman/listinfo/ietf-languages >=20 >=20 > -- > Doug Ewell | Thornton, CO, US | ewellic.org >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_ACC2FCF7-0E49-4ADC-A5BF-9AF44DCB7232 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Doug and others,

I created a pull request to add an = BCP47 contextualized Language Element everywhere there was an existing = ISO 639-2 Language Element, and updated documentation to give precedence = to the BCP47 version when available. https://github.com/Matroska-Org/matroska-specification/pull/103= /files.

For = the old ISO 639-2 Elements I added a disclaimer like this:

This Element MUST be ignored if the LanguageIETF Element is = used in the same TrackEntry.

The new BCP 47 Language Elements are = defined like this:

Specifies the language = of the track according to <a href=3D"https://tools.ietf.org/html/bcp47">BCP 47</a> = and using the = <a href=3D"http://www.iana.com/assignments/language-subtag-registr= y/language-subtag-registry">IANA Language = Subtag Registry</a>.

For reference there are three Language Elements in Matroska: = Language (to provide the Language of a related Track), TagLanguage (to = give the name used in a piece of metadata), ChapLanguage (to give the = language of the label of a Chapter).

Comments?

Dave Rice

On = Aug 2, 2016, at 1:56 PM, Doug Ewell <doug@ewellic.org> = wrote:

Thanks to J=C3=A9r=C3=B4me and Moritz for pointing to the = January discussion
about language coding.

It looks like the discussion originally focused on expanding = the
existing data element in Matroska to incorporate ISO = 639-3. Later
discussion was on truly adopting BCP 47, and = maintaining compatibility
with existing Matroska = implementations by creating a new, BCP
47-compliant = language element that would take precedence over the
existing one. This seems sensible and would allow data = producers to
migrate to the BCP 47 approach over time.

An important detail about BCP 47 is that = compliant applications use the
IANA Language Subtag = Registry [1] as their canonical source for language
subtags = (codes) and other subtags, and NOT the ISO standards directly.
The Registry is maintained carefully through IANA to be = compatible with
the ISO standards, except when doing so = would cause conflicts or
incompatibility.

For example, the chaos that ensued in 2003 when ISO 3166/MA = reassigned
the retired code element [CS] to mean "Serbia = and Montenegro," when
numerous applications were still = using it to mean "Czechoslovakia,"
would have caused very = little trouble if BCP 47 had existed, because a
numeric = replacement code would have been chosen for Serbia and
Montenegro to resolve the conflict.

So it's important to steer clear of statements like "RFC 5646 = recommends
to use ISO 639 when it is possible" and "RFC = 5646 recommends 2-letter
codes when 3-letters codes are = not necessary," because what RFC 5646
actually says is to = use the subtags that are in the Registry.

Another important point is that parsing a BCP 47 tag to = remove all but
the primary language subtag is dead simple: = just stop right before the
first hyphen, if any. So = "sr-Latin-ME" becomes "sr". There is no need to
worry = about whether the primary language subtag is 2 or 3 letters long.
The only exceptions are for the grandfathered tags = "i-default" and
"i-mingo" and for private-use tags = starting with "x-", all of which are
unlikely to occur in = multimedia data. There are well-defined matching
mechanisms = for more complex scenarios; see RFC 4647.

BCP= 47 (sometimes as "RFC 5646" or its predecessors) is referenced
normatively in more than 60 RFCs, and informatively in = another 20, plus
numerous drafts. So there is no question = that it is widely supported!

Please feel = free to contact the ietf-languages mailing list [2] with any
questions concerning BCP 47.

[1] = http://www.iana.com/assignments/language-subtag-registry[2] http://www.alvestrand.no/mailman/listinfo/ietf-languages

--
Doug Ewell | = Thornton, CO, US | ewellic.org

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

= --Apple-Mail=_ACC2FCF7-0E49-4ADC-A5BF-9AF44DCB7232-- From nobody Sun Feb 26 08:24: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 B29C3129982 for ; Sun, 26 Feb 2017 08:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 KLraGRgMf7Xf for ; Sun, 26 Feb 2017 08:24:20 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 3A5FA129971 for ; Sun, 26 Feb 2017 08:24:20 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id d1so14832329ywd.2 for ; Sun, 26 Feb 2017 08:24:20 -0800 (PST) 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=vA0kfVav2y8eXNl1qZu9Ycgnf/OGBNqHGLzGZEuG8U0=; b=aHWJAHUELq/U0iSfLsZbZRffh1jubPBI7XCmF38T36+10Epryc6P+TX9c7ha40Q8Qs WT1/DuPLpkVT8GQwGqeVT9p+M9K2gRV7TUwZthxnWm10Rx/8B9lPmrt6KpLlJKykZ01Y yGdO5SY6fMEnZgrLHZTTC5RYXD06ml5Ecmzfrq/mrIcspMC5XltaXHTE2Y/RRCq5z7jk YPsqoVJtpd97/RDQfwhLJqn3fKPnS1Kt+8yb/1CqLikX5flMShLGqpVlNh28JEJxKwi4 RRqfC/FxsS2lFlqS2xs51xpIe5Cyp0u7c+Gl2ugwJvRzoFiJUgMYnoZbaGwQn1zWwZIv /8pA== 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=vA0kfVav2y8eXNl1qZu9Ycgnf/OGBNqHGLzGZEuG8U0=; b=doJ/+rOz7K2IQawWbZjBjjqWkKDHBUsJPxpLxPSi43e1lA5oWarF5QErFMg4P+rq8d hFlMzIlewoxXgPdktpHJlLHRwClBlXoQ8axnPg/37NE8aYM5EYZRwBTp41v9MksKY2Kk dFK5OnJBASbQLhLl/hYYKsTjLSb0z7B2Iq9fa1qGmHvKx07F4e5McgFdE1Tzb1jJvBWG wv0JukQTXzQJyFT8FINTzw9I1Cq9+LWpCJ9SxdXc7+va9qvZD7xfcDDpCZA20oUoU5W7 P1pqGDcFVQLjYO/LTFCNzkqesuODY9Yqii9x7BUBfNwuHMBQBvOrudHgMAbwyKOBod5U Xj/w== X-Gm-Message-State: AMke39npFFhWljkZhalZUlFWCTG5dlwP+JyUm+GU5j0csZQC6LQI62bQPgQKJJvwBDsgxKA9+vBBZkJ8liDxOQ== X-Received: by 10.13.198.2 with SMTP id i2mr8600065ywd.201.1488126259335; Sun, 26 Feb 2017 08:24:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.15.133 with HTTP; Sun, 26 Feb 2017 08:24:18 -0800 (PST) In-Reply-To: References: <90625ABD-48AE-41CC-AFE1-24BD57A62415@dericed.com> From: Steve Lhomme Date: Sun, 26 Feb 2017 17:24:18 +0100 Message-ID: To: Matt Gruenke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] TrackTypes for non-standard data formats X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 16:24:21 -0000 In general when there's something you want to multiplex there's always the "complex" type in which you may put whatever you want. But it is recommended to use existing things or create what's missing. 2017-01-25 5:39 GMT+01:00 Matt Gruenke : > If it'd help to deal with specifics, some examples I have in mind are scene > geometry (e.g. point clouds, polygonal meshes, Z-buffer), camera pose (e.g. > position & orientation as vector & quaternion pairs, GPS coordinates, > compass readings), and various telemetry data (plenty of examples at > https://en.wikipedia.org/wiki/Telemetry ). For things like camera position/GPS, if it doesn't change, a tag on a chapter for that specific thing is probably better. It's easier to lookup such information among files (theoretically). But obviously there are lots of cases where this is not the case and we probably need a kind of track specific for that (sport cameras like Go Pros come to mind) with proper definition. Maybe the ancillary name is generic enough to cover all these and then depending on the codec you know what kind of information you would get. For the scene geometry I'm not familiar with this. Does it need to be interleaved with the audio/video things ? A chapter tag is not enough ? > Although nothing specific comes to mind that wouldn't have a stream-like > structure, one might allow for more such things as menus and button tracks. > Perhaps a game streaming application might use a track for player > information and statistics. > > In considering the utility & possible necessity of multiple, > application-defined TrackTypes, perhaps it's worth reviewing the purposes > they serve. One function of TrackType is certainly to simplify semantic > mapping of the available tracks. To this end, it can prove more reliable > than CodecID, since it's certainly possible to use the same encoding for > tracks with different semantics. > > Of course, TrackType also dictates the content model of TrackEntry. Though, > I don't know enough about EBML to have a sense of whether it's practical and > reasonable for applications to extend the schema to allow for custom track > metadata. > > I guess I'd ask why *not* allow ancillary data to have one of ~8 TrackTypes? > At the very least, I'd suggest using somewhere near the top of the range. > Then, more values for ancillary data could be added, subsequently, while > keeping the range contiguous. > > > Matt > > > On Tue, Jan 24, 2017 at 10:24 AM, Dave Rice wrote: >> >> >> IIRC the proposal for ancillary tracks was to have Codec_IDs prefixed with >> "N_". If your binary data stream is wholly private with contents that are >> not intended to be known by the Matroska specification then perhaps a >> private Codec ID prefix (such a "X_") would be worthwhile to define. On the >> other hand, if you could be more transparent you could also consider >> defining your codec openly, perhaps the application specific use could have >> wider interest. >> >> Or could OggKate store the values you need? Perhaps it's worthwhile to >> define storage for a time-based metadata track such as this. >> >> Dave Rice > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Sun Feb 26 08:29:39 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37C2129982 for ; Sun, 26 Feb 2017 08:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 enaMIYd1h74Q for ; Sun, 26 Feb 2017 08:29:36 -0800 (PST) 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 B41E4129971 for ; Sun, 26 Feb 2017 08:29:36 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id p77so27037256ywg.1 for ; Sun, 26 Feb 2017 08:29:36 -0800 (PST) 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=OePQRM22AxMiDq8ZhH3ToR1w9MxBHLt1yQecHVkhubU=; b=DC+BCm7Gh3vUL16rD7+DJprz2E6SPbcV/u/ozJpIL6BKJp3AXlwaSprEloV6Q3l6Rc zL3RWJXT571iZzTvt39kT/QUq7L3/l7O/NLsUnqYZ/M802xNBOitXCX3rl4m3IrjlRkz Tm5lUuKH8hgepWGIWmgmxqDzJHH2rUFRnFocdHSEzndZt441gbkFdWEm738hSB/ihC2k UWVcbxCBm+YnxOnoLmgnhoitgN7yyu5qAneIrEvwr/gAZ2ZC1AjVHpGGanrgKPRzCCnm Jgf8R0Vo7H0j8ozHquk28gtHm/YZz4VWAm8x/EQfPpN38jtdIPT6RESp8P1HbaSLgEf1 u5tg== 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=OePQRM22AxMiDq8ZhH3ToR1w9MxBHLt1yQecHVkhubU=; b=TABpEbTHOQ/C5Fy90M5dWrR/0vWiOKh1dCfrkfGzYg7USui7wNbDRYUG4qni+HbZon R/NFQ0q25K/xcFeJqlsdkdFcd/b5HzJQUwU07sTwi9HnP7hAWhV3flnw7aF4PZsqX6Ru Jnh7NOqiyJZD5VFygidqlyrIHJpA4wQHaTPn8u9ktpz6u3lpen79A3WvhCfAkRlo8Gl1 Cp02FgIoV8l+jfST18pi3j1z2Ff8zCWqmTREtxyFhRuJj5DJ+7W+WDx63Hq7KEGHgjiT VoSJxkiAWWJsQc6/fj9Rcz84iPwMyu/aPdTOL0LQ9yLk8kZtUkyoq/Hf7XptvM80VXCh ntQA== X-Gm-Message-State: AMke39lti8ukb5PrExTp16sKCcr+peo6lYLuvqUESOb/DpVCsA8ajmeYZhFeX4DVNx8mbb6NtAZDUyG792zEYg== X-Received: by 10.13.241.199 with SMTP id a190mr8944537ywf.311.1488126575926; Sun, 26 Feb 2017 08:29:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.15.133 with HTTP; Sun, 26 Feb 2017 08:29:35 -0800 (PST) In-Reply-To: References: From: Steve Lhomme Date: Sun, 26 Feb 2017 17:29:35 +0100 Message-ID: To: Matt Gruenke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] CodecIDs for non-standard and unregistered data formats X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 16:29:38 -0000 2017-02-14 7:46 GMT+01:00 Matt Gruenke : > Related to my recent query about TrackTypes for non-standard data formats, > I'd like to discuss CodecIDs. I had previously raised this issue, on the > matroska-devel list, and was advised to take it up, here. In the interim, > my thinking on the matter has evolved. > > I wonder why not allow IANA Media Types (aka MIME types), as a sub-class of > CodecIDs? Of course, the official Matroska CodecID would be preferred, for > all formats for which one has been designated. However, this would enable > broader use of Matroska files, including for private, application-specific > data stream formats. The main goal of Matroska is multimedia interleaved/timestamped data. It's possible to have "complex" track and put in it whatever you want. If a timestamp is required. If it's not, using attachment is what you want and it already has a MIME type. > Perhaps a prefix like 'X_MEDIATYPE/' could simply be prepended to media type > names conforming with RFC 6838. The value of TrackType would still > determine whether video, audio, or any other type-specific elements can be > used in such tracks. Although tempting I think it's better to avoid interleaving all kinds of stuff with audio/video. You could want to embed a "video/quicktime" but it would not be interleaved, or you'd need to parse/mux the data and then it's not a clean "video/quicktime" you get anymore. > Thank you for considering my suggestion. > > > Matt > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Sun Feb 26 08:40: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 C5EDE129991 for ; Sun, 26 Feb 2017 08:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 yd_vowaS2OtT for ; Sun, 26 Feb 2017 08:40:16 -0800 (PST) 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 984E312998D for ; Sun, 26 Feb 2017 08:40:16 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id p77so27085772ywg.1 for ; Sun, 26 Feb 2017 08:40:16 -0800 (PST) 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=WFyoY/GI3DOB35o8f3EG6AMzvzHt8oAT5f69BMO9UHU=; b=Qm0GnOxwF/GK0j2umsIda6clOuGa4SfXYT6Eqls2KZF7UeT1R6zo0LF60X3DKqd62f LD3NQFRFkxXp2pVSNpM08mIlujXYK7WY4Q4vvOWaVnL2WNqzxLoI59BZr7jusky/wZ3z VgoBx5VcEm/EkL0g7y6YvXhmlQjzrjUG92YKX7vBSbGF2+2Vk7ACkAuAu224whOoEqIH 8/sAXzTuFi9HjChy2gRxd5VXiqvaCuFEDsFXecMCW2yVG5t7IS3dTjr/++R6PJIkwdJk ORKfLToi3b/SIsdha79Ih3mG7tprd1ZkpvBZBugplfLMQoUVvJS71HXFeET8+P+JXUHg fVNg== 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=WFyoY/GI3DOB35o8f3EG6AMzvzHt8oAT5f69BMO9UHU=; b=EQFUlN8zPEuCXHepJX57uNvRIh7Vt0lN5CpzvmdiHAmPhjs5RKLwR/cZCALlJyWaDT 0Xuv8peFyF4sBoF1qdH+erkRubFKvhzhlifEa0E9cvoeD/j6kz+1kxymF7n9C/JRDSQc bpNf8ivo6RHzXZsEboLcqTw5BlIt1VwSovqK+fO7LQOXcmLIPbNS+OLL0effNG2aFgWM mGA0G2dc+2ireyvK/iTsnwBEiHaBCOmFbeCxLKv7n52SR2GaMhv/8H4gSSu3Ot4MyfA7 nX3Jv6Sr4nY+0mr4VnWniB55L1OmHTBvmNDxdc5kAPxBH/7QxFOAL1YBQ0zD6xPKWLKb MB3A== X-Gm-Message-State: AMke39nbHF+RC0hyuwmZuN5Z5i31sHBJ99xQ3ncg2lmz0pbyCkyIjg5ZIG/i0ZeHoRmFsZWSWc71KnPPdVgKkg== X-Received: by 10.13.239.129 with SMTP id y123mr9340106ywe.131.1488127215806; Sun, 26 Feb 2017 08:40:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.15.133 with HTTP; Sun, 26 Feb 2017 08:40:15 -0800 (PST) In-Reply-To: <798B10B6-D518-494B-8DC1-78DCFD1E4514@dericed.com> References: <798B10B6-D518-494B-8DC1-78DCFD1E4514@dericed.com> From: Steve Lhomme Date: Sun, 26 Feb 2017 17:40:15 +0100 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] TimeSlice and LaceNumber, deprecated in an unknown version X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 16:40:18 -0000 2016-05-28 20:10 GMT+02:00 Dave Rice : > Hi all, > > From specdata.xml is: > > Contains extra time information about the= data contained in the Block. While there are a few files in the wild with = this Element, it is no longer in use and has been deprecated. Being able to= interpret this Element is not required for playback. > > The rever= se number of the frame in the lace (0 is the last frame, 1 is the next to l= ast, etc). While there are a few files in the wild with this Element, it is= no longer in use and has been deprecated. Being able to interpret this Ele= ment is not required for playback. > > These elements are noted as deprecated, but there is no declared maxver. = Anyone remember when these were deprecated or what the maxver should be? I went through the specs on the Wayback machine and they were never marked deprecated. They are marked as deprecated on the WebM page though: http://www.webmproject.org/docs/container/ When v2 was added it was part of it, but the text actually said it was deprecated. So I think we can put maxver=3D"1". > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 26 08:48:19 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457F3129992 for ; Sun, 26 Feb 2017 08:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.653 X-Spam-Level: X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_NEUTRAL=0.652] 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 njH809Ce4ETA for ; Sun, 26 Feb 2017 08:48:15 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF615129991 for ; Sun, 26 Feb 2017 08:48:15 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:48312 helo=[10.0.1.18]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1ci1zW-0020DP-J8; Sun, 26 Feb 2017 11:48:14 -0500 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6F2B7C99-15B7-4F50-93B9-540D7101F2C7" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Sun, 26 Feb 2017 11:48:08 -0500 In-Reply-To: To: Steve Lhomme References: <798B10B6-D518-494B-8DC1-78DCFD1E4514@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: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] TimeSlice and LaceNumber, deprecated in an unknown version X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 16:48:17 -0000 --Apple-Mail=_6F2B7C99-15B7-4F50-93B9-540D7101F2C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 26, 2017, at 11:40 AM, Steve Lhomme = wrote: >=20 > 2016-05-28 20:10 GMT+02:00 Dave Rice : >> Hi all, >>=20 >> =46rom specdata.xml is: >>=20 >> Contains extra time information = about the data contained in the Block. While there are a few files in = the wild with this Element, it is no longer in use and has been = deprecated. Being able to interpret this Element is not required for = playback. >>=20 >> The = reverse number of the frame in the lace (0 is the last frame, 1 is the = next to last, etc). While there are a few files in the wild with this = Element, it is no longer in use and has been deprecated. Being able to = interpret this Element is not required for playback. >>=20 >> These elements are noted as deprecated, but there is no declared = maxver. Anyone remember when these were deprecated or what the maxver = should be? >=20 > I went through the specs on the Wayback machine and they were never > marked deprecated. They are marked as deprecated on the WebM page > though: > http://www.webmproject.org/docs/container/ >=20 > When v2 was added it was part of it, but the text actually said it was > deprecated. So I think we can put maxver=3D"1". Updated here: = https://github.com/Matroska-Org/matroska-specification/pull/105 = . [...] Dave= --Apple-Mail=_6F2B7C99-15B7-4F50-93B9-540D7101F2C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 26, 2017, at 11:40 AM, Steve Lhomme <slhomme@matroska.org> wrote:

2016-05-28 20:10 GMT+02:00 Dave Rice <dave@dericed.com>:
Hi all,

=46rom specdata.xml is:

<element name=3D"TimeSlice" level=3D"4" id=3D"0xE8" = type=3D"master" multiple=3D"1" minver=3D"1" divx=3D"0">Contains extra = time information about the data contained in the Block. While there are = a few files in the wild with this Element, it is no longer in use and = has been deprecated. Being able to interpret this Element is not = required for playback.</element>

<element name=3D"LaceNumber" cppname=3D"SliceLaceNumber" = level=3D"5" id=3D"0xCC" type=3D"uinteger" minver=3D"1" default=3D"0" = divx=3D"0">The reverse number of the frame in the lace (0 is the last = frame, 1 is the next to last, etc). While there are a few files in the = wild with this Element, it is no longer in use and has been deprecated. = Being able to interpret this Element is not required for = playback.</element>

These elements = are noted as deprecated, but there is no declared maxver. Anyone = remember when these were deprecated or what the maxver should be?

I went through the specs on the = Wayback machine and they were never
marked deprecated. = They are marked as deprecated on the WebM page
though:
http://www.webmproject.org/docs/container/

When v2 was added it was part of it, but the = text actually said it was
deprecated. So I think we can = put maxver=3D"1".


[...]

Dave
= --Apple-Mail=_6F2B7C99-15B7-4F50-93B9-540D7101F2C7-- From nobody Sun Feb 26 08:59: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 1ECE5129993 for ; Sun, 26 Feb 2017 08:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c4yoUPBuEDZ for ; Sun, 26 Feb 2017 08:59:49 -0800 (PST) Received: from 1.mo1.mail-out.ovh.net (1.mo1.mail-out.ovh.net [178.32.127.22]) (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 07DAD12998D for ; Sun, 26 Feb 2017 08:59:48 -0800 (PST) Received: from player169.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id 8D6C45965D for ; Sun, 26 Feb 2017 17:59:46 +0100 (CET) Received: from [192.168.2.101] (p5DDB7A97.dip0.t-ipconnect.de [93.219.122.151]) (Authenticated sender: jerome@mediaarea.net) by player169.ha.ovh.net (Postfix) with ESMTPSA id 73640580072; Sun, 26 Feb 2017 17:59:43 +0100 (CET) To: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission References: From: Jerome Martinez Message-ID: <31b2ba89-917f-d614-5688-d86b348a10e9@mediaarea.net> Date: Sun, 26 Feb 2017 17:59:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 685110095508672524 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelhedrvdeggdeludcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Archived-At: Cc: Matt Gruenke Subject: Re: [Cellar] CodecIDs for non-standard and unregistered data formats X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 16:59:51 -0000 Le 26/02/2017 à 17:29, Steve Lhomme a écrit : > 2017-02-14 7:46 GMT+01:00 Matt Gruenke : >> Related to my recent query about TrackTypes for non-standard data formats, >> I'd like to discuss CodecIDs. I had previously raised this issue, on the >> matroska-devel list, and was advised to take it up, here. In the interim, >> my thinking on the matter has evolved. >> >> I wonder why not allow IANA Media Types (aka MIME types), as a sub-class of >> CodecIDs? Of course, the official Matroska CodecID would be preferred, for >> all formats for which one has been designated. However, this would enable >> broader use of Matroska files, including for private, application-specific >> data stream formats. > The main goal of Matroska is multimedia interleaved/timestamped data. > It's possible to have "complex" track and put in it whatever you want. > If a timestamp is required. If it's not, using attachment is what you > want and it already has a MIME type. > >> Perhaps a prefix like 'X_MEDIATYPE/' could simply be prepended to media type >> names conforming with RFC 6838. The value of TrackType would still >> determine whether video, audio, or any other type-specific elements can be >> used in such tracks. > Although tempting I think it's better to avoid interleaving all kinds > of stuff with audio/video. You could want to embed a "video/quicktime" > but it would not be interleaved, or you'd need to parse/mux the data > and then it's not a clean "video/quicktime" you get anymore. I don't think this is the point. Let's imagine we don't have any AVI compatibility layer (for whatever reason, e.g. lawyers convinced a country that BITMAPINFOHEADER / WAVEFORMATEX structure are patented), we have no other way for having e.g. AMR, G719, G729 and so on because it is not defined in native Matroska codec identifiers, but IANA media types have them (so a muxer could use "X_MEDIATYPE/audio/G729"). Consider Matt suggestion as similar to the AVI compatibility layer: this is just another way to define a codec identifier, also for interleaved/timestamped video and audio content. Right now, I am thinking to TTML fragments (subtitles), instead of defining any TTML stuff in Matroska specs, "X_MEDIATYPE/application/ttml+xml" could be used and we rely on https://www.iana.org/assignments/media-types/application/ttml+xml . For crazy ideas but we should not forbid crazy ideas :), someone may want to use PDF as a video format with one PDF page per video frame (similar to MJPEG), and instead of defining and requesting a "V_PDF" codec identifier, one would use "X_MEDIATYPE/application/pdf". At long term, a potential decision would be to delegate codec identifiers management to IANA as they already do the job (for RTP and so on) in order to not duplicate efforts, and use Matroska list only when IANA does not fit Matroska needs, i.e. why should we care of having a spec about "V_MPEG4/ISO/AVC" (note: it is not on the codec spec page but a lot used) if we could rely on "video/H264" registration? (this is theoretical, "V_MPEG4/ISO/AVC" is already used. but we could do that for upcoming AV1 defined by IETF). Jérôme From nobody Sun Feb 26 14:38:51 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F5A127077; Sun, 26 Feb 2017 14:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F019SG0-6_K2; Sun, 26 Feb 2017 14:38:49 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E512A12941E; Sun, 26 Feb 2017 14:38:49 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:48957 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1ci7Sn-00467G-86; Sun, 26 Feb 2017 17:38:49 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_35175924-C663-4DEB-8440-1732BC68C6DB" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <21528B90-FB0F-4F9C-8F02-E024E986C30A@dericed.com> Date: Sun, 26 Feb 2017 17:38:43 -0500 To: cellar-chairs@ietf.org X-Mailer: Apple Mail (2.3259) 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: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: [Cellar] draft-ietf-cellar-ebml-02 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 22:38:51 -0000 --Apple-Mail=_35175924-C663-4DEB-8440-1732BC68C6DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear cellar, I submitted a version 02 of draft-ietf-cellar-ebml to the datatracker. I = also marked a corresponding release point in GitHub at = https://github.com/Matroska-Org/ebml-specification/releases/tag/v02 = . = This update from version 01 reflects commits from 2016-10-15 though = 2017-02-26 as seen at = https://github.com/Matroska-Org/ebml-specification/commits/master = . There are a few open issues or ideas for EBML listed = https://github.com/Matroska-Org/ebml-specification/issues = but overall = I think this one is in very good shape. Tim, Tessa, what next steps do you recommend before submitting to IESG? Best Regards, Dave Rice --Apple-Mail=_35175924-C663-4DEB-8440-1732BC68C6DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear cellar,

I = submitted a version 02 of draft-ietf-cellar-ebml to the = datatracker. I also marked a corresponding release point in GitHub = at https://github.com/Matroska-Org/ebml-specification/releases/tag= /v02. This update from version 01 reflects commits from 2016-10-15 = though 2017-02-26 as seen at https://github.com/Matroska-Org/ebml-specification/commits/mast= er.

There = are a few open issues or ideas for EBML listed https://github.com/Matroska-Org/ebml-specification/issues&n= bsp;but overall I think this one is in very good shape.

Tim, Tessa, what next = steps do you recommend before submitting to IESG?

Best Regards,
Dave Rice

= --Apple-Mail=_35175924-C663-4DEB-8440-1732BC68C6DB-- From nobody Sun Feb 26 15:31:38 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B411295C8 for ; Sun, 26 Feb 2017 15:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8YThZsqj0h3 for ; Sun, 26 Feb 2017 15:31:35 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F9B129516 for ; Sun, 26 Feb 2017 15:31:35 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:42074 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1ci8Hs-000UFP-JK; Sun, 26 Feb 2017 18:31:34 -0500 From: Dave Rice Message-Id: <0B185EDE-66D4-4E83-B337-D359FCF0C5B0@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EAD3654E-2DD4-4D20-BFD5-9C37349B8D6A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 26 Feb 2017 18:31:29 -0500 In-Reply-To: To: Steve Lhomme References: X-Mailer: Apple Mail (2.3259) 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: Cc: Tessa Fallon , Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] IETF current milestones: request for feedback X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 23:31:37 -0000 --Apple-Mail=_EAD3654E-2DD4-4D20-BFD5-9C37349B8D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tessa, Steve, cellar, > On Sep 18, 2016, at 3:44 AM, Steve Lhomme = wrote: >=20 > 2016-09-13 15:58 GMT+02:00 Tessa Fallon : >> At the CELLAR meeting in July, it was decided that working group = milestones >> would need to be revised. The current list is below. >>=20 >> Would those working on FFV1, EBML, and Matroska weigh in on the state = of the >> specifications and projected timelines for work to be completed? I = note >> that the most recent changes to EBML were submitted on Sunday 9/11. = Where >> does this leave the document? >=20 > It's an on-going effort. There are currently 16 issues opened on the > EBML specs alone: > https://github.com/Matroska-Org/ebml-specification/issues = EBML is down to 7 issues now, though some are ideas/considerations = rather than issues. I propose that a milestone for submitting EBML to = IESG is reset to a date in the near-future (end of March), and nudge for = more comprehensive peer-reviews of the EBML specification. > There are 5 on Matroska but that's because most of the effort has been > concentrated on EBML yet: > https://github.com/Matroska-Org/matroska-specification/issues = Matroska is now up to 19 issues since it=E2=80=99s been more active = lately. It=E2=80=99s certainly a large specification so perhaps we = should set a new list of more granular milestones for the components of = the specification: - attachments - chapters / menu - codec_specs - cues - diagram - the EBML Schema of Matroska - index / notes / order_guidelines / streaming - subtitles - tagging / metadata Volunteers to manage a review of the state of each component? With FFV1, there=E2=80=99s 6 open issues and half refer to future = version enhancements. Volunteers willing, I think it=E2=80=99s likely a = version 0, 1, 2, 3 specification of FFV1 could be ready to submit to the = IESG at the end of March as well. However these depend on sufficient peer-reviews. Perhaps we could = collaborate with one of the other audiovisual working groups for a = cross-peer-review. Here=E2=80=99s a new draft of a milestone list, please comment/advice: ? Submit specification for FLAC audio codec to IESG (Standards Track) Jul 2017 Submit specification for FFV1 video codec version 4 to IESG = (Standards Track) Sep 2017 Submit specification for Matroska container format version 4 to = IESG (Standards Track) Mar 2017 Submit informational specification for FFV1 video codec = versions 0, 1 and 3 to IESG for publication Mar 2017 Submit specification for EBML to IESG (Standards Track) May 2017 Submit informational specification for Matroska container = format versions 1, 2 and 3 to IESG for publication Although since Matroska version 4 has been in use for so longer, perhaps = the milestone to work on a future Matroska version should be changed to = =E2=80=98version 5=E2=80=99 rather than 4. Also FLAC? There=E2=80=99s been a few volunteer to get this started = (self included), but as far as I know, there=E2=80=99s no progress on = this specification. Thanks much, Dave > There are way more elements to defined in Matroska, various > interactions between them and all kinds of loopholes that we need to > iron out. >=20 >> Much thanks, >> Tessa >>=20 >> Date >> Dec 2016 Submit specification for FLAC audio codec to IESG (Standards = Track) >> Sep 2016 Submit specification for FFV1 video codec version 4 to IESG >> (Standards Track) >> Jul 2016 Submit specification for Matroska container format version 4 = to >> IESG (Standards Track) >> Jul 2016 Submit informational specification for FFV1 video codec = versions 0, >> 1 and 3 to IESG for publication >> Jun 2016 Submit specification for EBML to IESG (Standards Track) >> Jun 2016 Submit informational specification for Matroska container = format >> versions 1, 2 and 3 to IESG for publication >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >>=20 >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_EAD3654E-2DD4-4D20-BFD5-9C37349B8D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Tessa, Steve, cellar,

On = Sep 18, 2016, at 3:44 AM, Steve Lhomme <slhomme@matroska.org> wrote:

2016-09-13 15:58 GMT+02:00 Tessa Fallon <tessa.fallon@gmail.com>:
At the CELLAR meeting in July, it was decided = that working group milestones
would need to be revised. =   The current list is below.

Would = those working on FFV1, EBML, and Matroska weigh in on the state of = the
specifications and projected timelines for work to be = completed?  I note
that the most recent changes to = EBML were submitted on Sunday 9/11.  Where
does this = leave the document?

It's an = on-going effort. There are currently 16 issues opened on the
EBML specs alone:
https://github.com/Matroska-Org/ebml-specification/issues

EBML = is down to 7 issues now, though some are ideas/considerations rather = than issues. I propose that a milestone for submitting EBML to IESG is = reset to a date in the near-future (end of March), and nudge for more = comprehensive peer-reviews of the EBML specification.

There are 5 on Matroska but that's because most of the effort = has been
concentrated on EBML yet:
https://github.com/Matroska-Org/matroska-specification/issues











There are way more elements = to defined in Matroska, various
interactions between them = and all kinds of loopholes that we need to
iron out.

Much = thanks,
Tessa

Date
Dec 2016 Submit specification for FLAC audio codec to IESG = (Standards Track)
Sep 2016 Submit specification for FFV1 = video codec version 4 to IESG
(Standards Track)
Jul 2016 Submit specification for Matroska container format = version 4 to
IESG (Standards Track)
Jul 2016 = Submit informational specification for FFV1 video codec versions 0,
1 and 3 to IESG for publication
Jun 2016 Submit = specification for EBML to IESG (Standards Track)
Jun 2016 = Submit informational specification for Matroska container format
versions 1, 2 and 3 to IESG for publication

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




-- =
Steve Lhomme
Matroska association = Chairman

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

= --Apple-Mail=_EAD3654E-2DD4-4D20-BFD5-9C37349B8D6A-- From nobody Sun Feb 26 16:26:34 2017 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CEB1299DF; Sun, 26 Feb 2017 16:26:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148815519323.3027.6991189467442300464.idtracker@ietfa.amsl.com> Date: Sun, 26 Feb 2017 16:26:33 -0800 Archived-At: Cc: cellar@ietf.org Subject: [Cellar] I-D Action: draft-ietf-cellar-ebml-02.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 00:26:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission of the IETF. Title : Extensible Binary Meta Language Authors : Steve Lhomme <> Dave Rice <> Moritz Bunkus <> Filename : draft-ietf-cellar-ebml-02.txt Pages : 34 Date : 2017-02-26 Abstract: This document defines the Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data in a hierarchical form. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cellar-ebml-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ebml-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 26 18:21:10 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 52F64129A8B for ; Sun, 26 Feb 2017 18:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71pgK24u-GxJ for ; Sun, 26 Feb 2017 18:21:06 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 85EA8129A83 for ; Sun, 26 Feb 2017 18:21:06 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id 40so42359065uau.2 for ; Sun, 26 Feb 2017 18:21:06 -0800 (PST) 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=aNAD80xCa4+EGfhEvyXcUNC4e8vOAFAAAZ5hEpgC0bI=; b=d7Lyj/QxuqkzYU4kAgpalA4H9jZzndayBYXZmL+b07teSEH3zhwECONG9a6qePLfbg S2GQ7pOec5OeuuY1zzi8eczlw902JWk8NOOfGYU6qe338D+xqCDE1xoSzWx5dqcfrCVR 6hV+vjTHlrGX37pKNV3oOQvoI7Bs2zSBAEv13C1CThyi3GOzOxR1ZaO8BvNWvmyDEWiT O8hGuDD7BVtWoKmcIreJR0R739OKB2CY7iJCBgZRcYrTa42S0Z8xwtoL3PS1ynoVoPx2 X9M9/3F3U73Dk/niwu1U3pJNnUuFDDzgF4G/RXxSmntfH8UQYDZkO/mw5Zvu7HpHD4u8 yibg== 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=aNAD80xCa4+EGfhEvyXcUNC4e8vOAFAAAZ5hEpgC0bI=; b=BSlS+Z54U8w74KfxXQFczukuVAA50kzxw9yA6hF1y46vXoSi7GpRp/RGaoyDazjQq6 9gGdA7Z79HigXK5sy309TUCRqioZUeVWIXCT1pd/o8/NSUc2PFgvMlxnk9Kr+GY8tOA5 ejfp/nlGizg9njVldiCCSdXKojS9Z7xvwdBsMZxO2Hb3MVsi1AaBroYI/AXnZQqa+kyS ZPZcnKjxXwE7AEr3qUutZQdHwZ0GX9YIkyabTEJbA76S3YuhAyBI44tE/gOze3kq3Qzl psEskKqnUo07wJQ+AXkEsFCuyZQ4Cz5Qzb0ZbDDgODZONsn3CWaJD71hbBQ7eKeSsHjT NmoA== X-Gm-Message-State: AMke39np846ANgoANJoMiToOPQ0hivZdM0H5HL+s0xYkosID+ywzZNj73nXy9ZVXcnLD+hxTxMDQ3NdXIXJSug== X-Received: by 10.31.147.211 with SMTP id v202mr3123622vkd.90.1488162065570; Sun, 26 Feb 2017 18:21:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.102.196 with HTTP; Sun, 26 Feb 2017 18:21:05 -0800 (PST) In-Reply-To: References: <90625ABD-48AE-41CC-AFE1-24BD57A62415@dericed.com> From: Matt Gruenke Date: Sun, 26 Feb 2017 21:21:05 -0500 Message-ID: To: Steve Lhomme Content-Type: multipart/alternative; boundary=001a1140f706496255054979bb3f Archived-At: Cc: Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] TrackTypes for non-standard data formats X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 02:21:08 -0000 --001a1140f706496255054979bb3f Content-Type: text/plain; charset=UTF-8 Where are the complex & ancillary TrackTypes described? If ancillary tracks can be named, that would probably be sufficient. I think the CodecID should describe only *how *the data is encoded, which might be insufficient to convey its meaning or relationship to the other tracks. In all of the examples I mentioned, I can foresee cases where these would need to be time-stamped frames that might have a different sampling rate than the video or audio streams, if present. In fact, this is the case for one camera I've used, where the depth sensor operates at a different rate than the primary image sensor. Matt On Sun, Feb 26, 2017 at 11:24 AM, Steve Lhomme wrote: > In general when there's something you want to multiplex there's always > the "complex" type in which you may put whatever you want. > > But it is recommended to use existing things or create what's missing. > > 2017-01-25 5:39 GMT+01:00 Matt Gruenke : > > If it'd help to deal with specifics, some examples I have in mind are > scene > > geometry (e.g. point clouds, polygonal meshes, Z-buffer), camera pose > (e.g. > > position & orientation as vector & quaternion pairs, GPS coordinates, > > compass readings), and various telemetry data (plenty of examples at > > https://en.wikipedia.org/wiki/Telemetry ). > > For things like camera position/GPS, if it doesn't change, a tag on a > chapter for that specific thing is probably better. It's easier to > lookup such information among files (theoretically). But obviously > there are lots of cases where this is not the case and we probably > need a kind of track specific for that (sport cameras like Go Pros > come to mind) with proper definition. Maybe the ancillary name is > generic enough to cover all these and then depending on the codec you > know what kind of information you would get. > > For the scene geometry I'm not familiar with this. Does it need to be > interleaved with the audio/video things ? A chapter tag is not enough > ? > > > Although nothing specific comes to mind that wouldn't have a stream-like > > structure, one might allow for more such things as menus and button > tracks. > > Perhaps a game streaming application might use a track for player > > information and statistics. > > > > In considering the utility & possible necessity of multiple, > > application-defined TrackTypes, perhaps it's worth reviewing the purposes > > they serve. One function of TrackType is certainly to simplify semantic > > mapping of the available tracks. To this end, it can prove more reliable > > than CodecID, since it's certainly possible to use the same encoding for > > tracks with different semantics. > > > > Of course, TrackType also dictates the content model of TrackEntry. > Though, > > I don't know enough about EBML to have a sense of whether it's practical > and > > reasonable for applications to extend the schema to allow for custom > track > > metadata. > > > > I guess I'd ask why *not* allow ancillary data to have one of ~8 > TrackTypes? > > At the very least, I'd suggest using somewhere near the top of the range. > > Then, more values for ancillary data could be added, subsequently, while > > keeping the range contiguous. > > > > > > Matt > > > > > > On Tue, Jan 24, 2017 at 10:24 AM, Dave Rice wrote: > >> > >> > >> IIRC the proposal for ancillary tracks was to have Codec_IDs prefixed > with > >> "N_". If your binary data stream is wholly private with contents that > are > >> not intended to be known by the Matroska specification then perhaps a > >> private Codec ID prefix (such a "X_") would be worthwhile to define. On > the > >> other hand, if you could be more transparent you could also consider > >> defining your codec openly, perhaps the application specific use could > have > >> wider interest. > >> > >> Or could OggKate store the values you need? Perhaps it's worthwhile to > >> define storage for a time-based metadata track such as this. > >> > >> Dave Rice > > > > > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > -- > Steve Lhomme > Matroska association Chairman > --001a1140f706496255054979bb3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Where are the complex & ancillary TrackTypes described= ?=C2=A0 If ancillary tracks can be named, that would probably be sufficient= .=C2=A0 I think the CodecID should describe only how the data is enc= oded, which might be insufficient to convey its meaning or relationship to = the other tracks.

In all of the examples I mentioned, I = can foresee cases where these would need to be time-stamped frames that mig= ht have a different sampling rate than the video or audio streams, if prese= nt.=C2=A0 In fact, this is the case for one camera I've used, where the= depth sensor operates at a different rate than the primary image sensor.


Matt


On Sun, Feb 26, 2017 a= t 11:24 AM, Steve Lhomme <slhomme@matroska.org> wrote:
In general when there's something you w= ant to multiplex there's always
the "complex" type in which you may put whatever you want.

But it is recommended to use existing things or create what's missing.<= br>
2017-01-25 5:39 GMT+01:00 Matt Gruenke <matt.gruenke@gmail.com>:
> If it'd help to deal with specifics, some examples I have in mind = are scene
> geometry (e.g. point clouds, polygonal meshes, Z-buffer), camera pose = (e.g.
> position & orientation as vector & quaternion pairs, GPS coord= inates,
> compass readings), and various telemetry data (plenty of examples at > https://en.wikipedia.org/wiki/Telemetry ).

For things like camera position/GPS, if it doesn't change, a tag= on a
chapter for that specific thing is probably better. It's easier to
lookup such information among files (theoretically). But obviously
there are lots of cases where this is not the case and we probably
need a kind of track specific for that (sport cameras like Go Pros
come to mind) with proper definition. Maybe the ancillary name is
generic enough to cover all these and then depending on the codec you
know what kind of information you would get.

For the scene geometry I'm not familiar with this. Does it need to be interleaved with the audio/video things ? A chapter tag is not enough
?

> Although nothing specific comes to mind that wouldn't have a strea= m-like
> structure, one might allow for more such things as menus and button tr= acks.
> Perhaps a game streaming application might use a track for player
> information and statistics.
>
> In considering the utility & possible necessity of multiple,
> application-defined TrackTypes, perhaps it's worth reviewing the p= urposes
> they serve.=C2=A0 One function of TrackType is certainly to simplify s= emantic
> mapping of the available tracks.=C2=A0 To this end, it can prove more = reliable
> than CodecID, since it's certainly possible to use the same encodi= ng for
> tracks with different semantics.
>
> Of course, TrackType also dictates the content model of TrackEntry.=C2= =A0 Though,
> I don't know enough about EBML to have a sense of whether it's= practical and
> reasonable for applications to extend the schema to allow for custom t= rack
> metadata.
>
> I guess I'd ask why *not* allow ancillary data to have one of ~8 T= rackTypes?
> At the very least, I'd suggest using somewhere near the top of the= range.
> Then, more values for ancillary data could be added, subsequently, whi= le
> keeping the range contiguous.
>
>
> Matt
>
>
> On Tue, Jan 24, 2017 at 10:24 AM, Dave Rice <dave@dericed.com> wrote:
>>
>>
>> IIRC the proposal for ancillary tracks was to have Codec_IDs prefi= xed with
>> "N_". If your binary data stream is wholly private with = contents that are
>> not intended to be known by the Matroska specification then perhap= s a
>> private Codec ID prefix (such a "X_") would be worthwhil= e to define. On the
>> other hand, if you could be more transparent you could also consid= er
>> defining your codec openly, perhaps the application specific use c= ould have
>> wider interest.
>>
>> Or could OggKate store the values you need? Perhaps it's worth= while to
>> define storage for a time-based metadata track such as this.
>>
>> Dave Rice
>
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>



--
Steve Lhomme
Matroska association Chairman

--001a1140f706496255054979bb3f-- From nobody Sun Feb 26 19:05: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 8AD1D129634 for ; Sun, 26 Feb 2017 19:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qit_kZ19au0L for ; Sun, 26 Feb 2017 19:04:57 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D89129636 for ; Sun, 26 Feb 2017 19:04:57 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id 72so21235945uaf.3 for ; Sun, 26 Feb 2017 19:04:57 -0800 (PST) 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=9AOiF240nPPSOfkbbl+dWaUr08xv6dPdl6HB28TXq10=; b=ESedfTAdl31UXsHb2UBCsG+MstEt8WaPCJEfQ+s0Z7nFwlUdPwms4yLXNXTkvBHCne iyCljsCGe7ufgrz0f/2yw0z41sQ8c/nWkD+HAwOnh/xvaBxjaGBpqBLWOiCLbcGOGY6P MOGxtZ4MNUla3eIfcRqQVnyT56/WZRlu5euo01Q+SO3lrY6hHIJU6t8euqqd86eHLpX0 Is8Vmq64sOsWkKRNEkxUpShLi33W+m1UbeoTPMijYJWsNJ1oflwvD2cAJb+JzGA70y/8 iD0oF0X8//UywWf4q9RVeNG7z2aB3HhVKwAPdy5JbpmP6VXQt0mNlXyvaUVrsDB8ELZ5 WyWA== 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=9AOiF240nPPSOfkbbl+dWaUr08xv6dPdl6HB28TXq10=; b=XwxJnE7toEOhXVzzxVBxkw9r0sl1pOmQhvYIpcCL/aZlG+6fpDQxKXAlNz+5oiZmJW IYbgKLoNEftAVOzvmYf9hyfj7ePySM8swh5eRPcxH3u8j3Wjh3U05RsbsvIjn+sJQYwj oM7UjdSge46N1WaL11e8etrgr630isYSimhg9WirbSn5DNH+CiYKcUlgZhNAPzKanXC8 optoWTDHMYTbRFfHJTuSIOw0c4q2z13qheIX7+niJHLaASAblKJST2rBwYFq5Q+Kdbxa UUXWqXp5k8tZCJZVx8JjSey1fKUp8D6KYX92B8MMF73tHZvTXMOOPUbHzAJabtmUG7bv LSeQ== X-Gm-Message-State: AMke39lLPlr0ESckbhejtHTT/UyMRRXH+D/82knP7zs32EFyjZHoEc1VuAYrECH0UPAgba/5oVlk4hrm64sXgg== X-Received: by 10.176.64.129 with SMTP id i1mr5172250uad.7.1488164696408; Sun, 26 Feb 2017 19:04:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.102.196 with HTTP; Sun, 26 Feb 2017 19:04:56 -0800 (PST) In-Reply-To: References: From: Matt Gruenke Date: Sun, 26 Feb 2017 22:04:56 -0500 Message-ID: To: Steve Lhomme Content-Type: multipart/alternative; boundary=94eb2c1243d618ca1a05497a5853 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] CodecIDs for non-standard and unregistered data formats X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 03:04:59 -0000 --94eb2c1243d618ca1a05497a5853 Content-Type: text/plain; charset=UTF-8 Let's take this example of a camera having both a visible light sensor and a depth sensor, as well as a stereo microphone. For various reasons, its depth sensor captures frames at different times and a different rate than its color image sensor. I'd like to record a video file containing an audio track, a normal video track, and a depth track. I'd like the audio and video portions to be playable in normal video player apps. When using enhanced apps, the depth data may also be utilized. Today, most players I've tried will behave as I've described, if I simply write the depth data using an unspecified TrackType and having a custom CodecID. However, not all players handle it gracefully (or at all), and there's no guarantee that the others will continue to work. Having a dedicated TrackType (or range, thereof) would solve one potential problem. Perhaps the Ancillary TrackType already meets this need. Using nonstandard CodecIDs is another concern. I thought about schemes for doing this, but none seemed as sensible as trying to build upon what IANA already has. The private & vendor-specific trees provide a mechanism by which there's *at least* some record of a given format's origin, which is clearly better than it being completely ad hoc. The only downside I can see is that two apps might start using the same media type, but with different mappings to Matroska's syntactic structures (i.e. CodecPrivate and CodecState). Hopefully, any encoding common enough to have independent implementations by multiple apps would've already been promoted to have an official Matroska CodecID, whereupon such implementation details can be specified. > Although tempting I think it's better to avoid interleaving all kinds of stuff with audio/video. It's a valid and understandable position, but what attracted me to the Matroska format was my understanding that it's an open and extensible format. If it's too resistant to innovation, then developers might seek alternatives. This is how file formats get superseded and fall into disuse. Therefore, I think it's important for Matroska to offer extension mechanisms that strike the right balance between flexibility and compatibility. Matt On Sun, Feb 26, 2017 at 11:29 AM, Steve Lhomme wrote: > 2017-02-14 7:46 GMT+01:00 Matt Gruenke : > > Related to my recent query about TrackTypes for non-standard data > formats, > > I'd like to discuss CodecIDs. I had previously raised this issue, on the > > matroska-devel list, and was advised to take it up, here. In the > interim, > > my thinking on the matter has evolved. > > > > I wonder why not allow IANA Media Types (aka MIME types), as a sub-class > of > > CodecIDs? Of course, the official Matroska CodecID would be preferred, > for > > all formats for which one has been designated. However, this would > enable > > broader use of Matroska files, including for private, > application-specific > > data stream formats. > > The main goal of Matroska is multimedia interleaved/timestamped data. > It's possible to have "complex" track and put in it whatever you want. > If a timestamp is required. If it's not, using attachment is what you > want and it already has a MIME type. > > > Perhaps a prefix like 'X_MEDIATYPE/' could simply be prepended to media > type > > names conforming with RFC 6838. The value of TrackType would still > > determine whether video, audio, or any other type-specific elements can > be > > used in such tracks. > > Although tempting I think it's better to avoid interleaving all kinds > of stuff with audio/video. You could want to embed a "video/quicktime" > but it would not be interleaved, or you'd need to parse/mux the data > and then it's not a clean "video/quicktime" you get anymore. > > > Thank you for considering my suggestion. > > > > > > Matt > > > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > -- > Steve Lhomme > Matroska association Chairman > --94eb2c1243d618ca1a05497a5853 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let's take this example of a camera having both a visi= ble light sensor and a depth sensor, as well as a stereo microphone.=C2=A0 = For various reasons, its depth sensor captures frames at different times an= d a different rate than its color image sensor.=C2=A0 I'd like to recor= d a video file containing an audio track, a normal video track, and a depth= track.=C2=A0 I'd like the audio and video portions to be playable in n= ormal video player apps.=C2=A0 When using enhanced apps, the depth data may= also be utilized.

Today, most players I've tried wi= ll behave as I've described, if I simply write the depth data using an = unspecified TrackType and having= a custom CodecID.=C2=A0 However= , not all players handle it gracefully (or at all), and there's no guar= antee that the others will continue to work.

Havin= g a dedicated TrackType (or rang= e, thereof) would solve one potential problem.=C2=A0 Perhaps the Ancillary = TrackType already meets this nee= d.

Using nonstandard CodecIDs is another concern.=C2=A0 I thought about schemes fo= r doing this, but none seemed as sensible as trying to build upon what IANA= already has.=C2=A0 The private & vendor-specific trees provide a mecha= nism by which there's at least some record of a given format'= ;s origin, which is clearly better than it being completely ad hoc.=C2=A0 T= he only downside I can see is that two apps might start using the same medi= a type, but with different mappings to Matroska's syntactic structures = (i.e. CodecPrivate and CodecState).=C2=A0 Hopefully, any encodin= g common enough to have independent implementations by multiple apps would&= #39;ve already been promoted to have an official Matroska CodecID, whereupon such implementation details ca= n be specified.


>=C2=A0Although tempting I think it's better to avoid = interleaving all kinds=C2=A0of stuf= f with audio/video.

It's a valid and un= derstandable position, but what attracted me to the Matroska format was my = understanding that it's an open and extensible format.=C2=A0 If it'= s too resistant to innovation, then developers might seek alternatives.=C2= =A0 This is how file formats get superseded and fall into disuse.=C2=A0 The= refore, I think it's important for Matroska to offer extension mechanis= ms that strike the right balance between flexibility and compatibility.


Matt


On Sun, Feb 26, 2017 at = 11:29 AM, Steve Lhomme <slhomme@matroska.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">2017-02-14 7:46 GMT+01:00 Ma= tt Gruenke <matt.gruenke@gmail= .com>:
> Related to my recent query about TrackTypes for non-standard data form= ats,
> I'd like to discuss CodecIDs.=C2=A0 I had previously raised this i= ssue, on the
> matroska-devel list, and was advised to take it up, here.=C2=A0 In the= interim,
> my thinking on the matter has evolved.
>
> I wonder why not allow IANA Media Types (aka MIME types), as a sub-cla= ss of
> CodecIDs?=C2=A0 Of course, the official Matroska CodecID would be pref= erred, for
> all formats for which one has been designated.=C2=A0 However, this wou= ld enable
> broader use of Matroska files, including for private, application-spec= ific
> data stream formats.

The main goal of Matroska is multimedia interleaved/timestamped data= .
It's possible to have "complex" track and put in it whatever = you want.
If a timestamp is required. If it's not, using attachment is what you want and it already has a MIME type.

> Perhaps a prefix like 'X_MEDIATYPE/' could simply be prepended= to media type
> names conforming with RFC 6838.=C2=A0 The value of TrackType would sti= ll
> determine whether video, audio, or any other type-specific elements ca= n be
> used in such tracks.

Although tempting I think it's better to avoid interleaving all = kinds
of stuff with audio/video. You could want to embed a "video/quicktime&= quot;
but it would not be interleaved, or you'd need to parse/mux the data and then it's not a clean "video/quicktime" you get anymore.<= br>
> Thank you for considering my suggestion.
>
>
> Matt
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>



--
Steve Lhomme
Matroska association Chairman

--94eb2c1243d618ca1a05497a5853-- From nobody Mon Feb 27 05:31: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 C0337129F99 for ; Mon, 27 Feb 2017 05:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNMlvF6GOh-x for ; Mon, 27 Feb 2017 05:31:15 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C69129F97 for ; Mon, 27 Feb 2017 05:31:14 -0800 (PST) Received: from [10.0.0.11] (1360030002.d-dsl.at [::ffff:81.16.105.50]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Mon, 27 Feb 2017 14:31:13 +0100 id 000000000000002A.0000000058B42A21.0000474D Message-ID: <58B42A1F.5040904@das-werkstatt.com> Date: Mon, 27 Feb 2017 14:31:11 +0100 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] Anyone heard of "MagicYUV"? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 13:31:17 -0000 Just stumbled over "MagicYUV": "A high-performance, ultra-fast, mathematically lossless video codec for recording, archiving, post-production and editing at high resolutions." https://www.magicyuv.com/ Seems to have originated in 2014, and it seems quite proprietary. Speed and compression ratio seems to be comparable to HuffYUV. Here's the Doom9 Forum thread about it: http://forum.doom9.org/showthread.php?t=170227 Thought it's worth knowing what else is out there :) Regards, Pb From nobody Mon Feb 27 07:51:07 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208D012A17B for ; Mon, 27 Feb 2017 07:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pu5_8JOxMS61 for ; Mon, 27 Feb 2017 07:51:03 -0800 (PST) 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 DC7DA12A168 for ; Mon, 27 Feb 2017 07:51:02 -0800 (PST) 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 v1RFp0un012476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 27 Feb 2017 16:51:01 +0100 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 v1RFp0CP038428 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2017 16:51:00 +0100 Date: Mon, 27 Feb 2017 16:51:00 +0100 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: <58B42A1F.5040904@das-werkstatt.com> 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] Anyone heard of "MagicYUV"? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 15:51:05 -0000 Peter B. wrote: >and it seems quite >proprietary. Yes, it is. I have an SDK (not the current version 2), but they keep the codec itself "secret" and I didn't had the energy so far for doing some reverse engineering. I suspect HuffYUV has been the starting point, as many of us did. I could perform some tests with resonance patterns that hurt HuffYUV which would give a clue, if needed. Best regards, Reto AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: https://reto.ch | Twitter: @retoch From nobody Tue Feb 28 00:03:40 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 AE1D7128B44 for ; Tue, 28 Feb 2017 00:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TepznJCRdtga for ; Tue, 28 Feb 2017 00:03:38 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F73B1289B0 for ; Tue, 28 Feb 2017 00:03:38 -0800 (PST) Received: from [10.0.0.11] (1360030002.d-dsl.at [::ffff:81.16.105.50]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 28 Feb 2017 09:03:36 +0100 id 0000000000000032.0000000058B52ED9.00007D9E Message-ID: <58B52ED8.50208@das-werkstatt.com> Date: Tue, 28 Feb 2017 09:03:36 +0100 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Anyone heard of "MagicYUV"? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 08:03:39 -0000 On 02/27/2017 04:51 PM, Reto Kromer wrote: > Peter B. wrote: > >> and it seems quite >> proprietary. > Yes, it is. I have an SDK (not the current version 2), but > they keep the codec itself "secret" and I didn't had the > energy so far for doing some reverse engineering. > > I suspect HuffYUV has been the starting point, as many of us > did. I could perform some tests with resonance patterns that > hurt HuffYUV which would give a clue, if needed. Thanksalot for your input! But don't bother doing anything with MagicYUV. Since its author doesn't want it to be open and accessible, I don't see any need in further investigating this codec. Just posted it here so we know what else "exists" ;) Nice greetings, Pb