Re: [Cellar] Timestamps again

"Timothy B. Terriberry" <tterribe@xiph.org> Mon, 21 June 2021 15:21 UTC

Return-Path: <tterribe@xiph.org>
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 5B1093A0AD5 for <cellar@ietfa.amsl.com>; Mon, 21 Jun 2021 08:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.338
X-Spam-Level:
X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.338, 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 HDNXiKVK9qUD for <cellar@ietfa.amsl.com>; Mon, 21 Jun 2021 08:21:41 -0700 (PDT)
Received: from mailfish.xiph.org (mailfish.xiph.osuosl.org [140.211.166.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F27F3A0AD4 for <cellar@ietf.org>; Mon, 21 Jun 2021 08:21:40 -0700 (PDT)
Received: from [172.17.0.87] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) by mailfish.xiph.org (Postfix) with ESMTPSA id D36839F707 for <cellar@ietf.org>; Mon, 21 Jun 2021 15:21:38 +0000 (UTC)
To: cellar@ietf.org
References: <1dee863c-3589-21f6-da13-db5beee25d8a@xiph.org> <524efcdc-c93e-1b3c-71b5-d10e1e11509c@matroska.org>
From: "Timothy B. Terriberry" <tterribe@xiph.org>
Message-ID: <0588f9af-9b43-21f9-1dd3-af5e0bc2f43b@xiph.org>
Date: Mon, 21 Jun 2021 08:21:36 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 SeaMonkey/2.53.1
MIME-Version: 1.0
In-Reply-To: <524efcdc-c93e-1b3c-71b5-d10e1e11509c@matroska.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/a4kJSpHBcspYI9sf3audCS1LJkk>
Subject: Re: [Cellar] Timestamps again
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: Mon, 21 Jun 2021 15:21:44 -0000

Steve Lhomme wrote:
> One possibility is to use the existing TrackTimestampScale element which 
> wasn't designed for that but works pretty well. It's backward compatible 
> although there is a high chance a lot of readers don't handle it properly.

There are some other questions I had about interactions of it with other 
features, but given that it was deprecated I was not too worried about 
them. If you are planning to use it for this, maybe I should be, though.

> A more solid solution would be to write the proper sampling rate of the 
> source (but that becomes complicated in case of Variable Frame Rate as 
> found nowadays in video games).

Complicated things might be complicated, but you still need a reliable, 
documented way for the 99% of usage that will not have those complications.

> I think the TrackTimecodeScale solves both these examples, because it 
> using a floating point estimation before rounding the numbers. It allows 

I think the issue here is not that there is insufficient precision. 
There are enough code points in the timestamp to uniquely identify each 
sample number, but the rounding rules are not constructed in such a way 
as to guarantee a reversible map between them. That problem could be 
exacerbated by introducing floating point if you are not very careful 
about defining how the truncation and rounding works, since not every 
floating point environment is implemented or configured the same way. It 
certainly becomes a lot harder to test exhaustively.

For what it is worth, the program I attached passes using strategy (b) 
if you choose the "slightly smaller value" for TimestampScale to be 1/2 
of the value recommended in the text, instead of the recommended value 
minus one.

> I think we should explain the possibilities and limits of both methods 
> (with and without TrackTimecodeScale) when solving issue #517. Both when 
> muxing and demuxing to explain what rounding should be used.

I agree. I look forward to seeing the rewrite of these sections.