Re: [Cellar] Matroska Elements to support frame side data

Jerome Martinez <jerome@mediaarea.net> Mon, 05 November 2018 11:10 UTC

Return-Path: <jerome@mediaarea.net>
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 47AC8128DFD for <cellar@ietfa.amsl.com>; Mon, 5 Nov 2018 03:10:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 5z3a_TE3lPfb for <cellar@ietfa.amsl.com>; Mon, 5 Nov 2018 03:10:19 -0800 (PST)
Received: from 3.mo178.mail-out.ovh.net (3.mo178.mail-out.ovh.net [46.105.44.197]) (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 B235712EB11 for <cellar@ietf.org>; Mon, 5 Nov 2018 03:10:19 -0800 (PST)
Received: from player157.ha.ovh.net (unknown [10.109.146.1]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id E36AB3CD92 for <cellar@ietf.org>; Mon, 5 Nov 2018 12:10:16 +0100 (CET)
Received: from mediaarea.net (p3EE2DA4D.dip0.t-ipconnect.de [62.226.218.77]) (Authenticated sender: jerome@mediaarea.net) by player157.ha.ovh.net (Postfix) with ESMTPSA id 2CCD4100086 for <cellar@ietf.org>; Mon, 5 Nov 2018 12:10:15 +0100 (CET)
To: cellar@ietf.org
References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <83069618-2f88-eb00-4479-83fee6a564ab@noa-archive.com>
From: Jerome Martinez <jerome@mediaarea.net>
Message-ID: <e209eb5d-3116-fdae-c963-74a501935680@mediaarea.net>
Date: Mon, 5 Nov 2018 12:10:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <83069618-2f88-eb00-4479-83fee6a564ab@noa-archive.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Ovh-Tracer-Id: 2672886379757441169
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrjeehgddvhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecu
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/xxvjd8o7PoVrDg1mYgFKsVRF68M>
Subject: Re: [Cellar] Matroska Elements to support frame side data
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, 05 Nov 2018 11:10:22 -0000

On 05/11/2018 10:07, Tobias Rapp wrote:
> I should clarify: Storing the timecode value as a _single_ number 
> makes processing a lot easier. [...]

It adds another complexity: you need to transport somewhere else the 
configuration of this time code value (DP/NDP, frame rate).
which is not always available, if I do e.g. realtime transcoding from 
SDI and catch SMPTE ST 12, I don't have immediately the frame rate (I 
need to wait for frame number going back to 0) so I would have to wait 
up to 1 second before writing the Matroska header if frame rate info is 
in track header.
For reference MP4/MOV or MXF time codes use numbered values, SMPTE ST 
12, SDTI in MXF or GXF use a format which is more like a string time 
code. strict conversion between time code format (especially keeping the 
user bytes) is not always doable.

In my opinion we should not debate here of the best time code format (it 
would be in a metadata format registry, and both string time code and 
numbered time code may exist), just permit any of them so I like the 
proposal from Moritz, especially because I would use it too for 
RAWcooked the same way as with time code configuration in the track 
header for DP/NDP and frame rate info (if I store some RAWcooked 
configuration in the track header, I can improve a lot the comrpession 
of RAWcooked metadata).