Re: [Cellar] FFV1 Version 4

Kieran O Leary <kieran.o.leary@gmail.com> Wed, 06 January 2016 10:11 UTC

Return-Path: <kieran.o.leary@gmail.com>
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 1873F1ACDD2 for <cellar@ietfa.amsl.com>; Wed, 6 Jan 2016 02:11:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 c4ffVLOC1eei for <cellar@ietfa.amsl.com>; Wed, 6 Jan 2016 02:11:56 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7FCA1ACD97 for <cellar@ietf.org>; Wed, 6 Jan 2016 02:11:56 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id e32so208700137qgf.3 for <cellar@ietf.org>; Wed, 06 Jan 2016 02:11:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ThlOoB7C3HqcB5spgvEmCDOnbQRliYxT/HeP3ExfCBw=; b=st8gfCo2pQ819ND1NaV5pA01MtV45i7ZrNfdCb3TAkDqOadmRKFovLymnpf6CqRkCp sspzpJ+Bsf0zwpRnOCimPt3hJb/h5mUZE8YDCI00+GXAmobf5GjezTShlE6qarVW4riy XjDlsxuB0X6WiTaB7p/Hk9ccGGZv1JFoelvYLMn7OL0JKSO3xJmCzY+gOACVUFqH2Tv/ hy1gnGRJbIZFWkuboO+dpJM/XeqFUn0SYx+i1512Zpnb+EWK+7+7g/gEkG1amJReG8SF a1hpCDCkpy6cTs6YYBwSvOoJaCqE3RobVxMXJWooddKNiCo4vwEP+r7i7sjfLT8zq2iP 3H7w==
MIME-Version: 1.0
X-Received: by 10.140.237.74 with SMTP id i71mr72472938qhc.55.1452075115870; Wed, 06 Jan 2016 02:11:55 -0800 (PST)
Received: by 10.55.106.6 with HTTP; Wed, 6 Jan 2016 02:11:55 -0800 (PST)
In-Reply-To: <568C0516.3040605@mediaarea.net>
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>
Date: Wed, 6 Jan 2016 10:11:55 +0000
Message-ID: <CAO7v-1R44SDSZWZ_55SBT0vE+ka7e+s5V9suiW3emM-Z-ViS2A@mail.gmail.com>
From: Kieran O Leary <kieran.o.leary@gmail.com>
To: Jerome Martinez <jerome@mediaarea.net>
Content-Type: multipart/alternative; boundary=001a1135914c77fe550528a79549
Archived-At: <http://mailarchive.ietf.org/arch/msg/cellar/g8mLLjiNQI_KcVH-KtK_042cSz8>
Cc: Christoph Gerstbauer <christophgerstbauer@gmail.com>, cellar@ietf.org
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: Wed, 06 Jan 2016 10:11:59 -0000

Hi guys,

I'd like to propose the inclusion of Logarithmic information within the
FFV1 codec when transcoding from LOG RGB DPX.

This could be very beneficial to moving image archives who want to
losslessly compress their LOG DPX scans to FFV1. Currently if the FFV1
transcode is converted back to DPX, it is with Linear values, making it
unsuitable for preservation purposes.

It appears that ffmpeg doesn't support LOG in general (or maybe this lack
of support is just in DPX), from what I've gleaned from the mailing list,
so perhaps the LOG 'flag' within the FFV1 bitstream is only half the
battle? This conversation between Carl Eugen Hoyos and Dave Rice is my
source for this info, so apologies if I'm taking them up the wrong way :
https://ffmpeg.org/pipermail/ffmpeg-user/2015-March/025634.html

I would love to know if this is possible, or if anyone else would be
interested in this feature.
Here's some ffmpeg-user threads about the subject from the past year:
https://ffmpeg.org/pipermail/ffmpeg-user/2015-March/025625.html &
https://lists.mplayerhq.hu/pipermail/ffmpeg-user/2015-December/029536.html

Best regards,

Kieran O'Leary

On Tue, Jan 5, 2016 at 6:01 PM, Jerome Martinez <jerome@mediaarea.net>
wrote:

> Le 05/01/2016 18:44, Michael Niedermayer a écrit :
>
>> the global header / extradata / ConfigurationRecord can and should be
>> duplicated at the container level. repeating it at the codec level would
>> make finding a duplicate element relativly hard as one probably would have
>> to scan the whole file. A container could contain something like an index
>> to point to redundant copies, while at codec level this would not work so
>> easily
>>
>
> As far as I know, I never seen duplicated ConfigurationRecord.
> I guess we should add such option (e.g. in Matroska specs, there is
> already a discussion about duplicated parts) for people wanting to secure
> this important part.5
>
> [...]
>>
>> different picture_structures in 1 frame dont make sense or do i
>> misunderstand ?
>>
>
> Some people may be crazy enough for wanting and trying e.g.:
> - slice 0,0 top field first
> - slice 0,0 (the same as the line above) bottom field first
> - slice 0,1 progressive
> - slice 1,0 bottom field first
> - slice 1,0 (the same as the line above) top field first
> - slice 1,1 progressive
> (we have MABFF feature in AVC/H264, so I don't invent too much)
>
> and for the moment, I see nothing in the FFV1 specification forbidding
> that (did I miss something?)
> So either we are clear it is authorized (and the reference decoder can
> deal with it), or we explicitly forbid it (picture_structure is same in all
> slices of a frame)
>
>
>
>> Additionally, picture_structure, sar_num, sar_dem (and other?) do
>>> not use to change (or they change as often as  chroma_planes,
>>> h_chroma_subsample, alpha_plane...), so we may consider to put them
>>> in the ConfigurationRecord() too (and we may need to take care of
>>> duplicating it in the container?)
>>>
>> they could optionally be put in the global ConfigurationRecord
>> but it should stay possible for them to change if thats what the
>> source video we encode is doing
>>
>
> I like the idea to have such optional possibility. this is not a lot, but
> always some bits of compression.
> A candidate for FFV1 version 4 feature!
>
> Jérôme
>