Re: [Cellar] FFV1 Version 4

Jerome Martinez <jerome@mediaarea.net> Thu, 07 January 2016 18:34 UTC

Return-Path: <jerome@mediaarea.net>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B42A1A92B1 for <cellar@ietfa.amsl.com>; Thu, 7 Jan 2016 10:34:54 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 FyViitrLSean for <cellar@ietfa.amsl.com>; Thu, 7 Jan 2016 10:34:52 -0800 (PST)
Received: from 2.mo69.mail-out.ovh.net (2.mo69.mail-out.ovh.net [178.33.251.80]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7CA1A92B0 for <cellar@ietf.org>; Thu, 7 Jan 2016 10:34:52 -0800 (PST)
Received: from mail433.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo69.mail-out.ovh.net (Postfix) with SMTP id E5DDDFFCADC for <cellar@ietf.org>; Thu, 7 Jan 2016 19:34:50 +0100 (CET)
Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 7 Jan 2016 20:34:49 +0200
Received: from p5ddb663f.dip0.t-ipconnect.de (HELO ?192.168.2.101?) (jerome@francoallemand.eu@93.219.102.63) by ns0.ovh.net with SMTP; 7 Jan 2016 20:34:47 +0200
To: cellar@ietf.org
References: <CAO7v-1TCNOcqhv=JR5dMWhibD=kLyQwLztk8RG3v-rtegn7s7Q@mail.gmail.com> <E89E5459-836A-4FD7-BA52-6F75AFD67083@dericed.com> <20160105163439.GA13213@nb4> <568BF59B.6050106@mediaarea.net> <20160105174445.GC13213@nb4> <568C0516.3040605@mediaarea.net> <CAO7v-1R44SDSZWZ_55SBT0vE+ka7e+s5V9suiW3emM-Z-ViS2A@mail.gmail.com> <568EA7D2.50503@das-werkstatt.com>
From: Jerome Martinez <jerome@mediaarea.net>
Message-ID: <568EAFC3.1000202@mediaarea.net>
Date: Thu, 07 Jan 2016 19:34:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <568EA7D2.50503@das-werkstatt.com>
Content-Type: multipart/alternative; boundary="------------080505070406070305050905"
X-Ovh-Tracer-Id: 12666092477052817554
X-Ovh-Remote: 93.219.102.63 (p5ddb663f.dip0.t-ipconnect.de)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-OVH-SPAMSTATE: OK
X-OVH-SPAMSCORE: 0
X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedrjeefucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedrjeefgdduuddvucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: <http://mailarchive.ietf.org/arch/msg/cellar/DYGOo1_jMGrL_lkWZX-BtvRILBg>
Subject: Re: [Cellar] FFV1 Version 4
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 07 Jan 2016 18:34:54 -0000

Le 07/01/2016 19:00, Peter B. a écrit :
> On 01/06/2016 11:11 AM, Kieran O Leary wrote:
>> I'd like to propose the inclusion of Logarithmic information within the
>> FFV1 codec when transcoding from LOG RGB DPX
> I just wanted to mention that as well.
> Thanks Kieran :)
>
> I was already asked several times (mainly by film archives) if that is
> possible.
> Currently, "logarithmic-DPX-to-FFV1-and-back" is reported to be doable,
> but requires to manually set the output DPX to be non-linear...
>
> I'm not too experienced with non-linear color encoding, but in a recent
> presentation by Reto Kromer, he mentioned that "logarithmic" often just
> means "logarithmic-ish".
>
> Therefore it might be good (or necessary) to also store and handle
> information about what type of non-linear color values are used?
>

I am not an expert, I just see that "Logarithmic" is in the list of DPX 
transfer characteristics. so it looks like it is an unique value to store.

On my side, I tried to map DPX transfer characteristics to MPEG transfer 
characteristics, but it is not obvious.
For example, DPX transfer characteristics 5 is "SMPTE 274M", 6 is "BT.709"
They are actually same, and can be mapped to MPEG transfer 
characteristics 1, 6, 14 or 15 (several values for the same function)

List from each spec is not bidirectional, this is the reason I am 
thinking to have a code for the source of the value + the value from 
this source.
This is the only possibility if we want to be let people keep the exact 
metadata from the source (and being able to "revert" this compression).

We could do our own list for Matroska, but in that case we need to 
maintain it (for example, SMPTE added a new transfer characteristic 
value "ADX" in 2014 so we need to add a value in our list too) and take 
values from different specs in order to have an exhaustive list.
(and "reverting" it will not be with the exact same value: DPX 5 or 6 
will be mapped to MKV value X and "revert" will have to decide to put 
value 5 or  arbitrary).

I guess we first need to be clear about what we want to do (keep the 
exact value from the source or not, maintain a list...)

PS: just to be clear, when you speak about "logarithmic", you speak 
about DPX transfer characteristic value 3 "Logarithmic [to be defined by 
SMPTE I23 Technology Committee,
sub-group on “Transfer Characteristics”]", right?
(note: the "to be defined" is in the spec from 2003 as well from the 
spec from 2014 :), without further description)

Jérôme