Re: [Cellar] FFV1 Version 4

Jerome Martinez <jerome@mediaarea.net> Tue, 05 January 2016 16:56 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 17C621A9152 for <cellar@ietfa.amsl.com>; Tue, 5 Jan 2016 08:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-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 P47oJaGzR9fy for <cellar@ietfa.amsl.com>; Tue, 5 Jan 2016 08:56:01 -0800 (PST)
Received: from 1.mo69.mail-out.ovh.net (1.mo69.mail-out.ovh.net [178.33.251.173]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2DAB1A911A for <cellar@ietf.org>; Tue, 5 Jan 2016 08:56:00 -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 0BE24FFC316 for <cellar@ietf.org>; Tue, 5 Jan 2016 17:55:58 +0100 (CET)
Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 5 Jan 2016 18:55:58 +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 18:55:57 +0200
References: <CAO7v-1TCNOcqhv=JR5dMWhibD=kLyQwLztk8RG3v-rtegn7s7Q@mail.gmail.com> <E89E5459-836A-4FD7-BA52-6F75AFD67083@dericed.com> <20160105163439.GA13213@nb4>
To: cellar@ietf.org
From: Jerome Martinez <jerome@mediaarea.net>
Message-ID: <568BF59B.6050106@mediaarea.net>
Date: Tue, 05 Jan 2016 17:55:55 +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: <20160105163439.GA13213@nb4>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 17698302111477731514
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: gggruggvucftvghtrhhoucdtuddrfeekiedrieelgdelvdcutefuodetggdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm
Archived-At: <http://mailarchive.ietf.org/arch/msg/cellar/zgdGxV6Q70HNGiziiYMukzrGu6Y>
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 16:56:03 -0000

Le 05/01/2016 17:34, Michael Niedermayer a écrit :
> On Tue, Jan 05, 2016 at 11:08:16AM -0500, Dave Rice wrote:
> [...]
>
>> Some Header Adjustments
>> - currently some values such as bit depth, display aspect ratio, and chroma subsampling are set per slice rather than per frame. Perhaps there is a reason I am not considering, but possibly some adjustment could improve the logic of the frame and slice headers.
> the reason behind these being in slices is that slices should be
> independantly decodable
> If these would be in a single frame header and that frame header
> is lost then none of the slices would be decodable (unless the
> information is not needed to decode them)

We have problem about resilience in:
- the ConfigurationRecord(). Very important, and not duplicated. So if 
we want resilience, we should first focus in it.
- if the slice_size of the last slice is corrupted, we lose all slices 
(ok, we could decode each slice, let say slice_sizeof last slice and 
first byte of first slice). So there is not a so good resilience anyway.
So I am not sure it helps so much to have display aspect ratio, and 
picture_structure in a slice header, without more work on resilience 
(slice synchro? something else?). If keep them per slice, maybe we 
should say in spec that all slices must have the exact same display 
aspect ratio and picture_structure per frame (does the decoder support 
different picture_structures in 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?)

I guess such question should have its own topic.

PS: Dave, I see  colorspace_type, bits_per_raw_sample, chroma_plane,  
h_chroma_subsample, v_chroma_subsample, so bit depth and chroma 
subsampling in the ConfigurationRecord(), so per stream. Where so you 
see them per slice? I only see display aspect ratio per slice.