Re: [Cellar] matroska and side data vs timecode

Derek Buitenhuis <derek.buitenhuis@gmail.com> Wed, 30 October 2019 15:03 UTC

Return-Path: <derek.buitenhuis@gmail.com>
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 E1A34120C4C for <cellar@ietfa.amsl.com>; Wed, 30 Oct 2019 08:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02vx-KS5oi5v for <cellar@ietfa.amsl.com>; Wed, 30 Oct 2019 08:02:58 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 A0B1B120C48 for <cellar@ietf.org>; Wed, 30 Oct 2019 08:02:50 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id s1so2717188wro.0 for <cellar@ietf.org>; Wed, 30 Oct 2019 08:02:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=nWvoEVQrGYdA2WtRtJHzDHWP7a2xw7fbb/UveXwHAKQ=; b=io395yPkIU80BMrLTmV62bhQMDZdN3xyG+c026gERnOLtjUIRPNpFLepwtUOAawQnI YVEqssuzyKc0hq2ljzgSsYtBPBBJBi0IBNOFTaw4toq9R1MAPJbjgsBHc8DMDUpiIITJ qpGdCTRtEFdtAozP47Ht2aEspDCJZzgYvdOTsX3O00PIMsZAmgC1biVrxJ9uAZQPrqDs BjT1E2mDN6BCDsy0n1uAVJdo2IoDmzCu0NxywCimDhZ5iGrbZP6gE4X9WVmJ9V3YLqZH r8JuffLTyR8ygwd37TxFqzKegUi7ARAQrdAIF8yoJwN2uq/YwrNIZ5tEcoO7Ut2mIoAV mpsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=nWvoEVQrGYdA2WtRtJHzDHWP7a2xw7fbb/UveXwHAKQ=; b=rITS2MA8dLTmEU2EAEwEH3Oy1SurR9tiLAgFuLiD/d0ANJERVJ1D19qw8ZKa/7n0jY 1I3PwrcSYOm4Nv6mSJSLq8c2qTXvkIf49NbEU9rFCp3eGgq5j7f3b+4xHfondwoTrZz+ Oxq57sCDv6zfHMVxAR4bl9ZI/EH/dz6vjtllWUm/qdqzml45X3xIkZaCr7Nq7OfkZus2 ol+GWHMbeWQYKz81Xam2hBMGXp30AljfPqJS5AKotMiQDoNAdDg+PvoQUJS11XzJuJ62 pS4w16Ibs1nTyM0Ey6Up4qeDeMAgrRy7SQBS1tr9QkhaLGgHn4oG8ShlVNuUZOXRCrCp UpYw==
X-Gm-Message-State: APjAAAXKKVDxMkZk0DZ7hEJ6CcNU32bfApiVyA46B4Fof2xg2dTaApDV ACBQsPN6vCzomu38uQpNwEco+6CD
X-Google-Smtp-Source: APXvYqyl4qiRvAh8Dx8sunUOohAHOOeyQm8nEn80YNuzMKl0/oUXuwZQaqUjxT8h9AqUGUsndyz5tQ==
X-Received: by 2002:adf:e651:: with SMTP id b17mr254390wrn.191.1572447768934; Wed, 30 Oct 2019 08:02:48 -0700 (PDT)
Received: from [192.168.1.106] ([82.129.88.112]) by smtp.googlemail.com with ESMTPSA id g10sm532110wrr.28.2019.10.30.08.02.48 for <cellar@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 08:02:48 -0700 (PDT)
To: cellar@ietf.org
References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com>
From: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Message-ID: <40b8c32e-9136-af70-e844-b9e9f2e1c75a@gmail.com>
Date: Wed, 30 Oct 2019 15:02:48 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com>
Content-Type: multipart/alternative; boundary="------------324CFAC324819F6C89E8A3BA"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/JOLp0VqjMnORQI6eQKZxZaDC_6Q>
Subject: Re: [Cellar] matroska and side data vs timecode
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2019 15:03:01 -0000

Comments inlined below.

On 29/10/2019 16:04, Dave Rice wrote:
> _Implementation Considerations:_
>
> Thinking ahead of this work, I think it would be worthwhile to add a dedicated section to the Matroska specification on timecode and describe two methods for adding a reference timecode to a Matroska Segment.
>
> 1. Using tags. Make an official tag “TIMECODE” to store a string of the timecode expression that correlates to the Matroska timestamp of 0. This approach is limited to storing timecode that is incremental and continuous. Defaults for the incrementation and the behavior of the timecode could be described as part of the tag definitions and feasibly another tag or tags could be reserved for timecode flags when the timecode behavior is not a default. Defining a use of a “TIMECODE” tag would provide the benefit of standardizing an existing practice in FFmpeg’s Matroska muxer, where rewrapping from a timecode-supportive format to Matroska carries the timecode value over as a tag.

To me, requiring timecodes to be incremental and continuous pretty much defeats a good chunk of the point of timecodes, no?

> 2. Using BlockAdditions as described above. This adds more overhead as each timecode value would be written, but would support non-continuous timecode. In FFmpeg, timecode is sometimes carried as side-data such as from the decklink device via https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/0946c0ec177dc48ef0677f890aa42d95e667c417. I’d be interested if the Block Addition Mapping described above could be used to carry the timecode side data from the decklink device (or other incoming stream with timecode side data) and store the result within the written Matroska BlockGroups.

As long as it's an optional element, I don't see a downside to the small overhead - especially considering the large size of many/most mezzanines that carry timecodes.

Unrelated to the above two comments: How do you intent to rectify the historical (and confusing) use of 'timecode' in Matroska to be timestamp with the newly introduced timecode functionality?

Cheers,
- Derek