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, 05 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).
- [Cellar] Matroska Elements to support frame side … Dave Rice
- Re: [Cellar] Matroska Elements to support frame s… Tobias Rapp
- Re: [Cellar] Matroska Elements to support frame s… Dave Rice
- Re: [Cellar] Matroska Elements to support frame s… Tobias Rapp
- Re: [Cellar] Matroska Elements to support frame s… Moritz Bunkus
- Re: [Cellar] Matroska Elements to support frame s… Jerome Martinez
- Re: [Cellar] Matroska Elements to support frame s… Jerome Martinez
- Re: [Cellar] Matroska Elements to support frame s… Moritz Bunkus
- Re: [Cellar] Matroska Elements to support frame s… Tobias Rapp
- Re: [Cellar] Matroska Elements to support frame s… Steve Lhomme
- Re: [Cellar] Matroska Elements to support frame s… Dave Rice
- Re: [Cellar] Matroska Elements to support frame s… Steve Lhomme
- Re: [Cellar] Matroska Elements to support frame s… Luca Barbato
- Re: [Cellar] Matroska Elements to support frame s… Michael Richardson
- Re: [Cellar] Matroska Elements to support frame s… Steve Lhomme
- Re: [Cellar] Matroska Elements to support frame s… Steve Lhomme
- [Cellar] IANA considerations text to reserve WebM… Michael Richardson
- Re: [Cellar] Matroska Elements to support frame s… Michael Bradshaw