Re: [Cellar] matroska and side data vs timecode

Tobias Rapp <t.rapp@noa-archive.com> Wed, 30 October 2019 16:29 UTC

Return-Path: <t.rapp@noa-archive.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 D56F312087B for <cellar@ietfa.amsl.com>; Wed, 30 Oct 2019 09:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj93TfFb23or for <cellar@ietfa.amsl.com>; Wed, 30 Oct 2019 09:29:00 -0700 (PDT)
Received: from mx02.mail.netstorage.at (mx02.mail.netstorage.at [89.207.146.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F09120802 for <cellar@ietf.org>; Wed, 30 Oct 2019 09:28:58 -0700 (PDT)
Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx02.mail.netstorage.at (Postfix) with ESMTPS id 571AAAF599 for <cellar@ietf.org>; Wed, 30 Oct 2019 17:28:55 +0100 (CET)
Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id CFCBA80ED8 for <cellar@ietf.org>; Wed, 30 Oct 2019 17:28:54 +0100 (CET)
Received: from [192.168.0.107] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Wed, 30 Oct 2019 17:28:54 +0100
To: cellar@ietf.org
References: <00F6A0BF-2922-4BAC-AC73-EB888767886F@dericed.com> <40b8c32e-9136-af70-e844-b9e9f2e1c75a@gmail.com> <CAO7v-1SkBrN33Y7NgY5GuSnYewfEhkW7f0o4LSkDP4raVA77Kg@mail.gmail.com>
From: Tobias Rapp <t.rapp@noa-archive.com>
Organization: NOA GmbH
Message-ID: <6cd23d59-f9d7-0ab8-3a0d-729f9f106de7@noa-archive.com>
Date: Wed, 30 Oct 2019 17:28:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAO7v-1SkBrN33Y7NgY5GuSnYewfEhkW7f0o4LSkDP4raVA77Kg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-PPP-Message-ID: <20191030162855.25210.93520@p1002.netstorage.at>
X-PPP-Vhost: noa-archive.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/SZZZmF_FCweLZejaxxhccps_2DU>
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:29:03 -0000

On 30.10.2019 16: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. So it won't represent the source 
> videotape if there's a timecode jump or reset.

Our NOA FrameLector software stores timecode start offset and jumps 
during the capturing process. It is using VITC and/or LTC as sources, 
depending on what is available. The timecode values are stored in an XML 
alongside the media file. When exporting the media file into other 
systems currently only the initial timecode offset is embedded into the 
MXF/MOV output file.

The method of storing timecode as side-data for each frame has the 
disadvantage that all frame side-data must be read when building a 
timecode-to-playtime seeking table in players. Also the timecode 
information is lost when writing an audio-only variant of the file. Thus 
I think it would be better to store timecode data as a separate track, 
similar to how it could be done in MOV.

Best regards,
Tobias