Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
Jerome Martinez <jerome@mediaarea.net> Mon, 05 February 2018 21:20 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 C45D612D958 for <cellar@ietfa.amsl.com>; Mon, 5 Feb 2018 13:20:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 uekmpWX2Apqw for <cellar@ietfa.amsl.com>; Mon, 5 Feb 2018 13:20:53 -0800 (PST)
Received: from 8.mo5.mail-out.ovh.net (8.mo5.mail-out.ovh.net [178.32.116.78]) (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 B209212711E for <cellar@ietf.org>; Mon, 5 Feb 2018 13:20:53 -0800 (PST)
Received: from player786.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id 50314185EC5 for <cellar@ietf.org>; Mon, 5 Feb 2018 22:20:51 +0100 (CET)
Received: from [192.168.2.120] (p5DDB56EF.dip0.t-ipconnect.de [93.219.86.239]) (Authenticated sender: zen-lists@mediaarea.net) by player786.ha.ovh.net (Postfix) with ESMTPSA id C24D18007E; Mon, 5 Feb 2018 22:20:49 +0100 (CET)
References: <20180203120734.GL3129@michaelspb> <r470Ps-10116i-366B8B5E9B0C48B78A66399443F70F73@Castor.local> <20180203134824.GM3129@michaelspb>
From: Jerome Martinez <jerome@mediaarea.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>, Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Message-ID: <40210041-ca4b-969e-eba1-2cfd6a11819d@mediaarea.net>
Date: Mon, 05 Feb 2018 22:20:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180203134824.GM3129@michaelspb>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-Ovh-Tracer-Id: 14606018017724272785
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtfedruddvgdduheduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/ju_qGcJYmlzEP4SX--UNFohcY_U>
Subject: Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.22
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, 05 Feb 2018 21:20:56 -0000
On 03/02/2018 14:48, Michael Niedermayer wrote: > > I hope this will not reduce interrest in working on a improved > 9-16bit mode in v4. I don't like to put politics in technical stuff, but here this is politics, and I think that blocking an easy improvement of FFV1 v3 encoding/decoding in FFmpeg (actually just using the current FFV1 v3, and also v1 actually, specification without having artificial limitations about bit depths for a specific color space, i.e. 16-bit support was already there for YUV before I work on FFV1) just for forcing people to do a completely different work (e.g. working on FFV1 v4) is not fair and IMO is not in the idea behind open source. IMO if interest for 9-16bit (side note: I don't see why 8-bit should not be in the range, some ideas I have for v4 are useful also for 8-bit) mode in v4 is reduced, that would only mean that v3 is already so great and/or just that people have no better idea right now, it is not bad, and both works (using v3 at the maximum of its possibilities and working on v4) are separate works. FYI criticism I saw about FFV1 is not compression ratio but speed (playing a 4K stream is just impossible on a "normal" machine, you need a very expensive CPU for that) so my plan is to focus on speed improvement in priority. It could be v4 stuff (incompatible changes), or v3 (encoder/decoder optimization), depending of what I find. > > > [...] > >> Last but not least, since almost two years now it's impossible >> to work on the development of FFV1 v4. It's always the wrong >> time and/or the wrong place every time I am doing something for >> this cause. Why? This is extremely frustrating. > I want to understand this too. IMO v4 development should be more > important than or at least equally to the v3 draft polishing and neither > should block the other. Also politics, but I don't understand who is blocking v4 from your point of view. "impossible to work on v4"? Where? As far as I see 1 person (me) said his priority is having FFV1 v3 becoming a standard (so IETF related work) and widely used (so any bit depth for any supported color space in v3 because it is an easy demonstration that FFV1 is versatile without having to wait for v4 R&D, especially because v3 bitstream design is already pretty good and versatile) because this is what I need, and my personal case is not blocking anyone else for sending patches for either FFV1 specifications or FFmpeg code about v4. Eager to see patch proposals for v4 (and v3 if it does not break support of files in the wild), whoever feeling blocked with his patches should send patch proposals to either FFmpeg (code) or CELLAR mailing list (bitstream format). That said, I plan to add more pix_fmt support for FFV1 v3 (which is already a good format!) support in FFmpeg and some optimization ideas beside my work for IETF spec, with the hope we could speak about technical issues (e.g. more optimization hints or info about wrong code or warning about that it breaks the bitstream specs as currently written), leaving aside politics.
- Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1:… Jerome Martinez
- Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1:… Michael Niedermayer
- Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1:… Reto Kromer
- Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1:… Michael Niedermayer
- Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1:… Jean-Christophe Kummer
- Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1:… Jerome Martinez
- Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1:… Dave Rice