Re: [Cellar] Matroska support for closed captions?

Jerome Martinez <jerome@mediaarea.net> Mon, 27 April 2020 16:08 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 6CDB83A0E6B for <cellar@ietfa.amsl.com>; Mon, 27 Apr 2020 09:08:22 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 w78H8TzTE8uh for <cellar@ietfa.amsl.com>; Mon, 27 Apr 2020 09:08:19 -0700 (PDT)
Received: from 9.mo68.mail-out.ovh.net (9.mo68.mail-out.ovh.net [46.105.78.111]) (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 AED9C3A0E8B for <cellar@ietf.org>; Mon, 27 Apr 2020 09:08:17 -0700 (PDT)
Received: from player716.ha.ovh.net (unknown [10.110.208.43]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 84F01163DC6 for <cellar@ietf.org>; Mon, 27 Apr 2020 18:08:15 +0200 (CEST)
Received: from mediaarea.net (p548F9B78.dip0.t-ipconnect.de [84.143.155.120]) (Authenticated sender: jerome@mediaarea.net) by player716.ha.ovh.net (Postfix) with ESMTPSA id D411E11BB9AD6 for <cellar@ietf.org>; Mon, 27 Apr 2020 16:08:14 +0000 (UTC)
To: cellar@ietf.org
References: <CY4PR04MB072989A9F039E5DFCBBF1E40C9D20@CY4PR04MB0729.namprd04.prod.outlook.com> <514D57FC-BD77-45E7-846A-046363BED953@dericed.com>
From: Jerome Martinez <jerome@mediaarea.net>
Message-ID: <6e93c666-4414-abab-0f2e-fbe6beaec904@mediaarea.net>
Date: Mon, 27 Apr 2020 18:08:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <514D57FC-BD77-45E7-846A-046363BED953@dericed.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Ovh-Tracer-Id: 247416505558765713
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrheelgdelhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheplfgvrhhomhgvucforghrthhinhgviicuoehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkpheptddrtddrtddrtddpkeegrddugeefrdduheehrdduvddtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeduiedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvthdprhgtphhtthhopegtvghllhgrrhesihgvthhfrdhorhhg
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/GhpWr93F_QSZ8cXoCveKImKfgOw>
Subject: Re: [Cellar] Matroska support for closed captions?
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, 27 Apr 2020 16:08:29 -0000

On 27/04/2020 17:46, Dave Rice wrote:
>
> For EIA-608 and EIA-708 data I suppose, either a new type of Codec Mapping could be written (and then these would be a new type of subtitle track) or they could be support as side-data with a BlockAdditionalMapping as described at https://www.ietf.org/id/draft-ietf-cellar-codec-04.html#name-block-additional-mapping. I’m unsure which technique the community would recommend but curious for some discussion on it.


As MXF have JPEG-2000, I guess that captions are in a standalone 
ancillary data (SMPTE ST 291) track.
As a first shot, I would not be in favor of BlockAdditionalMapping 
because the track does not depend on data in another bistream.

then there would (at least) 2 choices:
- demux of the track from MXF and mux of this track as is; advantage is 
that we lose no other data inside the ancillary data, disadvantage is 
that lot of different content (several formats of captions, bar data, 
VBI, time codes, Acquisition Metadata...) are muxed in the "raw" stream, 
more difficult for a demuxer/player.
- demux of the captions from Ancillary data from MXF; advantage is that 
we have 1 track per content stream, disadvantage is that we may lose 
some other "opaque" data from the ancillary data.

That said, we could propose both.

Jérôme