Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16
Jerome Martinez <jerome@mediaarea.net> Sat, 03 February 2018 09:57 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 D6D7A1270AB for <cellar@ietfa.amsl.com>; Sat, 3 Feb 2018 01:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ef8-s2EjbNmC for <cellar@ietfa.amsl.com>; Sat, 3 Feb 2018 01:57:49 -0800 (PST)
Received: from 4.mo5.mail-out.ovh.net (4.mo5.mail-out.ovh.net [178.33.111.247]) (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 206711200FC for <cellar@ietf.org>; Sat, 3 Feb 2018 01:57:48 -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 BE059186F35 for <cellar@ietf.org>; Sat, 3 Feb 2018 10:57:46 +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 D3A558008A; Sat, 3 Feb 2018 10:57:44 +0100 (CET)
To: ffmpeg-devel@ffmpeg.org
References: <63dcf4c8-53bf-ef81-140a-025d6181818c@mediaarea.net> <20180202231056.GZ3063@michaelspb>
Cc: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
From: Jerome Martinez <jerome@mediaarea.net>
Message-ID: <0a425851-80b5-70b8-41a2-14e16d928ec3@mediaarea.net>
Date: Sat, 03 Feb 2018 10:57:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180202231056.GZ3063@michaelspb>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-Ovh-Tracer-Id: 9771122344503087249
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtfedrtdekgdduvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/UdWzdgQo3zMIezvVv191MClXHrM>
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: Sat, 03 Feb 2018 09:57:52 -0000
On 03/02/2018 00:10, Michael Niedermayer wrote: > On Thu, Feb 01, 2018 at 01:43:00PM +0100, Jerome Martinez wrote: >> Add support for 16-bit/component RGB with Alpha encoding and decoding in >> FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding. >> >> Resulting bitstream was tested about lossless encoding/decoding by the >> compression from DPX to FFV1 then decompression from FFV1 to DPX, see >> commands below (resulting framemd5 hashes are all same). >> Resulting bitstream is decodable by another decoder (with same resulting >> framemd5 hash). >> Resulting bitstream passed through a conformance checker compared to current >> FFV1 specification IETF draft. >> >> About the patch: >> - some modified lines are not used (the ones not used when f->use32bit is >> 1), but it makes the code more coherent (especially because decode_rgb_frame >> signature is same for both 16-bit and 32-bit version) and prepares the >> support of RGBA with 10/12/14 bits/component. >> - GBRAP16 was chosen for decoding because GBRP16 is already used when no >> alpha, and the code is more prepared for planar pix_fmt when bit depth is >>> 8. >> - "s->transparency = desc->nb_components == 4 || desc->nb_components == 2;" >> is a copy of a line a bit above about the detection of transparency, I >> preferred to reuse it as is even if "YA" 16-bit/component is not (yet) >> supported. >> >> FFmpeg commands used for tests: >> ./ffmpeg -i in.dpx -c:v ffv1 out.mkv >> ./ffmpeg -i in.dpx -pix_fmt gbrap16 -strict -2 -c:v ffv1 out2.mkv >> ./ffmpeg -i out.mkv out.dpx >> >> ./ffmpeg -i in.dpx -f framemd5 in.dpx.framemd5 >> ./ffmpeg -i out.mkv -pix_fmt rgba64be -f framemd5 out.mkv.framemd5 >> ./ffmpeg -i out2.mkv -pix_fmt rgba64be -f framemd5 out2.mkv.framemd5 >> ./ffmpeg -i out.dpx -f framemd5 out.dpx.framemd5 >> >> Test file used (renamed to in.dpx): >> https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx > I would prefer if the algorithm would be tuned to 16bit data before > adding more formats to the encoder which require all decoders to support > them. > > Dont you agree that this would be the better strategy ? ccing CELLAR. My remarks are the same as with RGB48 support (including that the compression performance of RGB48 so RGBA64 is already very good without touching on the algorithm, and IMO tuning should be for v4 for all bit depths), with addition that since the last debate on that on ffmpeg-devel there was no patch proposal so no consensus on CELLAR for limiting the specifications to what exists in FFmpeg implementation (so current consensus is that FFV1 specs are for all bit depths for all supported color spaces), and since the last debate FFV1 specs draft were sent to IETF tracker so it is close to the end. This patch is just adding the support of RGBA64 conforming to the current specs and without big changes (no complex stuff, just mapping to the right pix_fmt), and the current specs are the ones with very high chances to be the standard (up to now nobody suggested on CELLAR, the place for the spec, to limit the support to a set of bit depths / color spaces, and nobody suggested a tuning for some bit depths), with the main advantage that the specs are clear about all bit depths for all color spaces supported (it is good that it is generic). Will this patch be accepted after the IETF flags the current specs as stable if there is no changes on the wording about the support of all bit depths? on my side, I can not spend time on FFV1 v4 R&D (tuning and more) when I spend time with such blocking (for me) issue about v3 (i.e. agreement in specs draft on all bit depths for all supported color spaces but no agreement in practice on all bit depths for all supported color spaces). So for answering directly to the question, no I don't agree that changing v3 bitstream with specific tuning of the bitstream depending of the bit depth is a better strategy, actually this is the opposite (I think that the best strategy is to support as many bit depths as possible in implementations with current v3 specs and that all tuning should be in the version flagged as experimental, not the one flagged as stable even before working on IETF version, if we change a bitstream marked as stable we break the trust in the spec being stable, IMO any tuning of the bitstream should be done in v4, and any performance improvement without breaking the bitstream could be done after this patch without problem). Jérôme
- 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