Re: [Cellar] matroska and side data vs timecode

Dave Rice <dave@dericed.com> Wed, 30 October 2019 16:08 UTC

Return-Path: <dave@dericed.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 725DC1200B4 for <cellar@ietfa.amsl.com>; Wed, 30 Oct 2019 09:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level:
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4dEZKe-DJ3b for <cellar@ietfa.amsl.com>; Wed, 30 Oct 2019 09:08:39 -0700 (PDT)
Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2E4120113 for <cellar@ietf.org>; Wed, 30 Oct 2019 09:08:39 -0700 (PDT)
Received: from [146.96.19.240] (port=7306 helo=[10.10.201.21]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <dave@dericed.com>) id 1iPqWO-002MYX-HK; Wed, 30 Oct 2019 12:08:37 -0400
From: Dave Rice <dave@dericed.com>
Message-Id: <A77D1DA7-B855-47E9-82A6-29BCC9238159@dericed.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_319CA198-99FB-44C5-95C9-A0CBFFBFC262"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 30 Oct 2019 12:08:25 -0400
In-Reply-To: <c82b22b1-44f9-a73b-ae4d-db52d8bd46d4@gmail.com>
Cc: Kieran O Leary <kieran.o.leary@gmail.com>, cellar@ietf.org
To: Derek Buitenhuis <derek.buitenhuis@gmail.com>
References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> <40b8c32e-9136-af70-e844-b9e9f2e1c75a@gmail.com> <CAO7v-1SkBrN33Y7NgY5GuSnYewfEhkW7f0o4LSkDP4raVA77Kg@mail.gmail.com> <c82b22b1-44f9-a73b-ae4d-db52d8bd46d4@gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server172.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dericed.com
X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com
X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/2taJ5yuLalilbm3WJ_U-cYd6ack>
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 16:08:41 -0000

> On Oct 30, 2019, at 11:49 AM, Derek Buitenhuis <derek.buitenhuis@gmail.com> wrote:
> 
> On 30/10/2019 15:39, Kieran O Leary wrote:
>> Kind of, but all tape capture software that I've encountered just stores the starting timecode value along with framerate and all other timecodes are based on this starting value.

This is most of my experience as well when transferring as well, but to QuickTime files, where a timecode track stores a single sample value and some properties to define the incrementation. These timecode tracks are limited since they are based upon a single value but very easy to edit, whereas storing timecode per frame would require edits throughout the file to (for instance) apply an offset to the entire timecode track.

Still I like the idea of formalizing support for continuous timecode based upon a single value within a tag (as an alternate option to timecode as side data), as it would be very easy to add or manipulate. Also it is what is already done when ffmpeg rewraps a video with timecode to Matroska.

>> So it won't represent the source videotape if there's a timecode jump or reset. But the method that Dave outlines here would at least allow Matroska to mirror what happens with Aja/blackmagic capture tools using v210/mov as the capture format.
>> It's very difficult to find tools or examples of noncontinuous timecode tracks..
> An example would be a digitally produced (in an NLE) mezzanine from a number of ingested sources, where its timecodes map to the timecods in the original sources - I've seen this used fairly often to facilitate figuring out where a particular edit may come from in a final export or mezzanine.
> 
I’ve seen some of these too. In QuickTime the timecode track will still store a single value but then the track has an edit list to manage the offsets at the points of discontinuity. Also in stream based tape transfers like dv and m2ts from DV or HDV tape, non-continuous timecode is rather common. Still IIUC support for timecode as side data in ffmpeg is limited to a few formats and devices, so getting an input from decklink would pass along timecode strings as side data, but the dv decoder currently would not pass along such data.
> I would need to dig up which NLEs, specifically, produce these.
> 
> Cheers,
> - Derek
> 

Thanks,
Dave