IETF Logo Mail Archive

[Cellar] Rationale Numbers for timestamps

Steve Lhomme <slhomme@matroska.org> Tue, 26 July 2016 19:35 UTC

Return-Path: <slhomme@matroska.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 8385412D51F for <cellar@ietfa.amsl.com>; Tue, 26 Jul 2016 12:35:19 -0700 (PDT)
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, 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 NGHIPit_nWua for <cellar@ietfa.amsl.com>; Tue, 26 Jul 2016 12:35:16 -0700 (PDT)
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 AC2FE12D513 for <cellar@ietf.org>; Tue, 26 Jul 2016 12:35:16 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id u134so29347327ywg.3 for <cellar@ietf.org>; Tue, 26 Jul 2016 12:35:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=brU1Q7kl3CbrTPiMY1Bu7JTEnq1JIVzo5f6Gh+qqEhY=; b=B6zBV9xc5ni5uAfgTI4GgOM65OLCnRuq/Q3JNvOOTjgH/7Y0ItXD1MHyK/k9RihVKw IK2ltuOq+41dMkN7lwSXhjr8kWYY6e3fPAmiDiwX6bGKORsxEjLHF1xLEPMirbtOxd/m 8Nal7SrF+OUs3m3fzSrho/8qskRI+eVHdthzJHep7x3KSFbxI80madSgmGmyj8qVsKBp Q5NX+l/u02mOCI85VZzPqFGXNJqtgXyrdgOhalb/or8ijg5+B5MyK3DKb7Am+Pl3B3e/ LtCeMw2tn1JVuAKLUju4sb2xJHCkcrV4GxFziapvaglSdc/F+DgOdKB0crE3x+GmCDu8 s6xA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=brU1Q7kl3CbrTPiMY1Bu7JTEnq1JIVzo5f6Gh+qqEhY=; b=fEym2+h1nfqOnb7MQY5/qlAjmUiHANEPuH7cvNSXhrs9FILAT1PPM1sBlqvs2Jp4bE 5ix9KScf4knhGxEV2L+hKwfUq6m/xIsDyDnDfrPPW1kYet6ro6TK1t58Jze5sk4yzTVw iFyere0D0r6Smqdz/cTr06xwsqoylS6bX7Lcg8A6Rl2j2s+dF/GpsHn4AN0K0pl7yCOI 8AA497ILsoi0CxFf92qxTfUxaVQsP/aTxELep+UkMCmVGamKJuhYhSZT0a09QDusGpwC Z/lfufhZolYcYIDoS6uv5e07m6wYDSGYSGeH7U0br6TAxXRb1MpBN227eRDVk5gLKqoc x2sA==
X-Gm-Message-State: AEkooutT7jdLoZMCHSNWjXUE71J5GjKS6RdIliyRqYctgy+2Azw6oE0I8DGXtG6ke51SwRy4C7MeViKuUQ2XSw==
X-Received: by 10.37.104.11 with SMTP id d11mr20687107ybc.77.1469561715768; Tue, 26 Jul 2016 12:35:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.83.20.70 with HTTP; Tue, 26 Jul 2016 12:35:15 -0700 (PDT)
From: Steve Lhomme <slhomme@matroska.org>
Date: Tue, 26 Jul 2016 21:35:15 +0200
Message-ID: <CAOXsMFKNXNcvRzsYkQw23dz=5e6A4TGbq=rO=3KW8rokLUOeEQ@mail.gmail.com>
To: cellar@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/djSrMeFSACIYQkafoS8At3jR4fI>
Subject: [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 <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: Tue, 26 Jul 2016 19:35:19 -0000

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/004294.html
https://lists.matroska.org/pipermail/matroska-devel/2012-October/004295.html
https://lists.matroska.org/pipermail/matroska-devel/2012-October/004296.html
https://lists.matroska.org/pipermail/matroska-devel/2012-October/004299.html

An element to handle it was added (still in specdata.xml but commented)
https://lists.matroska.org/pipermail/matroska-devel/2012-September/004289.html
and later removed
https://lists.matroska.org/pipermail/matroska-devel/2012-December/004317.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.

-- 
Steve Lhomme
Matroska association Chairman

v2.23.0 | Report a Bug | By Email