Re: [Cellar] FFV1 Version 4

Jerome Martinez <jerome@mediaarea.net> Tue, 05 January 2016 18:02 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 959D51A8AF6 for <cellar@ietfa.amsl.com>; Tue, 5 Jan 2016 10:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iFPxGlrMXrBb for <cellar@ietfa.amsl.com>; Tue, 5 Jan 2016 10:02:03 -0800 (PST)
Received: from 10.mo69.mail-out.ovh.net (10.mo69.mail-out.ovh.net [46.105.73.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DC81A8AF4 for <cellar@ietf.org>; Tue, 5 Jan 2016 10:02:03 -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 CDE28FFC18B for <cellar@ietf.org>; Tue, 5 Jan 2016 19:02:01 +0100 (CET)
Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 5 Jan 2016 20:02:01 +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; 5 Jan 2016 20:01:59 +0200
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>
To: cellar@ietf.org
From: Jerome Martinez <jerome@mediaarea.net>
Message-ID: <568C0516.3040605@mediaarea.net>
Date: Tue, 05 Jan 2016 19:01:58 +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: <20160105174445.GC13213@nb4>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 366480421352181946
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: -100
X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedrieelucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekiedrieelgddutdehucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
Archived-At: <http://mailarchive.ietf.org/arch/msg/cellar/EDH5vX69WZpIFFVdwWmyBBUi-zs>
Cc: Kieran O Leary <kieran.o.leary@gmail.com>
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: Tue, 05 Jan 2016 18:02:05 -0000

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