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

Jerome Martinez <jerome@mediaarea.net> Mon, 05 November 2018 11:20 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 683CC128DFD for <cellar@ietfa.amsl.com>; Mon, 5 Nov 2018 03:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 D1zGcxLdUFqi for <cellar@ietfa.amsl.com>; Mon, 5 Nov 2018 03:20:11 -0800 (PST)
Received: from 18.mo3.mail-out.ovh.net (18.mo3.mail-out.ovh.net [87.98.172.162]) (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 9F660127133 for <cellar@ietf.org>; Mon, 5 Nov 2018 03:20:11 -0800 (PST)
Received: from player798.ha.ovh.net (unknown [10.109.160.12]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id 9EBB31E70F4 for <cellar@ietf.org>; Mon, 5 Nov 2018 12:20:09 +0100 (CET)
Received: from mediaarea.net (p3EE2DA4D.dip0.t-ipconnect.de [62.226.218.77]) (Authenticated sender: jerome@mediaarea.net) by player798.ha.ovh.net (Postfix) with ESMTPSA id 60E045400AA for <cellar@ietf.org>; Mon, 5 Nov 2018 12:20:08 +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> <87r2fz7u01.fsf@bunkus.org>
From: Jerome Martinez <jerome@mediaarea.net>
Message-ID: <2c9da243-26b0-6ae5-1fb8-0f0448e8728d@mediaarea.net>
Date: Mon, 5 Nov 2018 12:20:09 +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: <87r2fz7u01.fsf@bunkus.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Ovh-Tracer-Id: 2839801043706908817
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrjeehgddvkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecu
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/ZM_U3nay_skEFVjYuflSFQD48cs>
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:20:13 -0000

On 05/11/2018 10:29, Moritz Bunkus wrote:
> Hey,
>
>> In other thoughts on this suggestion, I think it could make it difficult
>> to easily understand if a file has a particular type of side data. For
>> instance if only a few Clusters somewhere in the Segment contain a
>> certain type of side data, it would require parsing every Cluster to know
>> what types of side data are available. This uncertainly wouldn’t be the
>> same issue if the side data was itself a Track.
> It's not entirely necessary to use a full track for side data. We can simply
> signal the presence of side data in the track headers and refer to it from
> the side data in the block groups. This would also mean we only have to
> store the string identifying the side data type once (in the track headers)
> instead of in each block.


It would permit more efficient storage, but IMO it should be optional 
only, because if we do real time transcoding to MKV we don't have always 
all sidecar info. I have in mind some A/V content with ancillary data 
coming only after few minutes, without any change in A/V part.


>
> (I'll use "BlockMetadata" as the basis for all element names
> here. Initially I proposed "FrameMetadata", but "BlockMetadata" is fine
> with me, too.)

I prefer also "BlockMetadata" due to here is located the element.


>
> For example:
>
> Tracks
> +- TrackEntry
>   +- TrackBlockMetadata (Master)
>    +- TrackBlockMetadataType (String, required)
>    +- TrackBlockMetadataID (Unsigned Integer, required)

Please add:
  +- TrackBlockMetadataPrivate (Binary, optional)

Would have the same usage as CodecPrivate but for metadata.


>
> …
>
> Cluster
> +- BlockGroup
>   +- BlockMetadata (Master)
>    +- BlockMetadataID (Unsigned Integer, required, refers to existing
>       TrackBlockMetadataID in track headers)

Here I suggest to keep something like current PR "BlockMetadataName" and 
the restriction that  that exactly one of (BlockMetadataID ,
BlockMetadataName) must exist.

This would be even more complex but IMO more versatile.


> [...]