From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 54EB246DA0 for ; Wed, 8 Nov 2023 20:46:06 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3F6FF68CAFA; Wed, 8 Nov 2023 22:46:04 +0200 (EET) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5C47168C92E for ; Wed, 8 Nov 2023 22:45:58 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1699476357; x=1700081157; i=eclipse7@gmx.net; bh=HEMIF36htfOHkpE2qFZJD6jnCcu3wnipkRYIGVdQnCw=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=Y+BURVskjQoaZ3NeqfuXr+W1SFIDOw2muJXCX5MMDFQPLhfY8+WNSFqUyjOaNKW1 qkWk0uNxR0mNof60tk0mIPlaLWyaPtBR93EX3AS6S5IuOgVvUku0H62aZbGWgJelZ TtWiP0H4FqMJsRMxVUHFqWkM/vYcmwUNSyJREx+lFulGeZgoyuJj4g6DUK9yEV5tw M0kYZD+hkkVNP3lO+raLZYTJ1zPBxgLt11TlHxehi+pK/3E91aZAmCYC9LthBlFgG 9v4vdQsYB816Ezlz7NHZE0megfYkMnRYPwdFkL/ikOAGjr8MZ4reo7wBKkOxk+G36 ZNT7s9u0/ggjwK6zHg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from metallschleimette ([91.12.124.168]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M5QFB-1r1emO34w1-001P8B for ; Wed, 08 Nov 2023 21:45:57 +0100 Date: Wed, 8 Nov 2023 21:55:10 +0100 From: Alexander Strasser To: FFmpeg development discussions and patches Message-ID: References: <20231031084044.GQ3543730@pb2> <169944363034.11195.830944857438126327@lain.khirnov.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <169944363034.11195.830944857438126327@lain.khirnov.net> X-Provags-ID: V03:K1:GDOnabJkAinwkBp1PuCXXV9FujoUAUQV8gSIhc+ZQaQIy6bKQI5 21WwsQe7nURQ/puctaTyFb95Ogw84EP/yT4k9nsoKQIJK/wa0Gl4QNelOWD7onAZAfjEEbb cOI4XduzrR94eq8x0eCxoJvaZrpPTQ0uCbWFcHkTBSOQYZkXOZyDIAINwfH4JO1coWum4CC AMFymfFrLXrB4p6KA2a3Q== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:3CICNaUq5pk=;LHUY8nctLeJuwx2vhlqaGnKh1Si n9raEs+IxO+jgnhPB4h2Rs/tRHCW3qAVt3FSbylpufQ/ddJ83+riOfXMM9Q+0kLlydZKJlNr0 8xCTWnC+YESsO02NiZiBFMf0spiNH78MG7c/NX3Fr1ZZSrREWSu9Kg1U0gs2HpBWi1Wt9Xf3/ E07b616gJWFBaNmzV5GsE4KZ6Md3uF9yk3WbQX+jMSp6v6Qq507trTXqKhatE8fuReKzZRQL/ N4VufN1zRNjrhbHXgvllfVXd+gWPKNI/oV6nTU16lO+syCCNQpxEB4vw6pd0u2LVlrkYmM4ZL hG02Bb1a8LF0cOAlLsfi2/SZ31bjl5RWZXCqDYVPcBTdJNW4KgR9YtXQ4gHT5hYs9omXVMJuW fnflNBpXMROYZur9Kr3vE+IHtT4Eyg0/OZiGvXvMbuLcWx1vVV71xa4dgwvj5CUM5smt1aQbI 7mnPdpCf5md0/y24hGTt/8IebW1RcXCIrTHqUjGF2YAxH4Csj26Vqa/lvIFD8zJavZJ5OUwyt 49n1kAqbLjq8DLj1sXYxfIxkaFTB+eKKkhl91SHt+SYaHqZZkc4tvqBl5DCNjb+yszFF+OU+5 VvXNnUk1AsrtXyNiTrbyFJ1jKubQu4kaefFpkM6s/NbObuxeU7vh7atvAafajJuO14yj1IOoy 9KqmcsJJei8fD/u3zzJ0R5qvd1zFgkvwEmw2ZSpX+EzDqqwg34H35cOPjF9LtdVHNZhxw6T61 fbP8zfMyM4h/kTBwE2HdpL8QhE0gXaea4hoKNUHr0Ko8zKfqDa+sdSuu3Rz57cx0EM18xQPtd dW87J6+rijQDotWbArJKioHHFT9+siUNq8ceF/jUtMg4fP76Xw6J4vdqtD9DaaGJoz66dCQQt jfa9WgBoa4csb2RnH1DvyazJo+7BkIw6Ra9ZWTw2bD03wubVvBscyar/MhypqN2J3zX9JuMBz xyrc/Q== Subject: Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: Remove spec-incompliant inverse quantisation X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 2023-11-08 12:40 +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-10-31 09:40:44) > > On Mon, Oct 30, 2023 at 02:11:27PM +0100, Andreas Rheinhardt wrote: > > > Section 7.4.4 of the MPEG-2 specifications requires that the > > > last bit of the last coefficient be toggled so that the sum > > > of all coefficients is odd; both our decoder and encoder > > > did this only if the bitexact flag has been set (although > > > stuff like this should be behind AV_CODEC_FLAG2_FAST). > > > This patch changes this by removing the spec-incompliant > > > functions. > > > > This commit message should include benchamarks documenting the speed loss > > (of the unquantize, the IDCT and overall) > > It is expected that the speed of some IDCTs will be impacted negativly > > as the non zero terms will prevent the skiping of some significant code > > > > as well as information about how much PSNR improves (to the encoder input) > > > > Also the change is a +-1 in one spot before the IDCT, the IDCT is not bitexactly > > specified in MPEG-2 so one could think of this as a > > correct implementation followed by a IDCT that was sometimes +-1 off > > instead of spec non compliance > > > > Only after the benchmarks and PSNR is presented should we decide if this > > is a change we want > > I disagree that the burden of proof should be on Andreas here. It should > be up to whoever wants to keep this code to show that it is useful. There was an argument presented. That argument could be challenged or otherwise explained why it more important to have this always behave like with bitexact. This could lead to "OK, I think removal is better" or if not benchmarks could lead to one or the other decision. Saying the burden is on whoever wants to keep the code sounds like a way for arbitrary code removal. While I agree getting rid of code can be a good thing, this would definitely take it too far. Best regards, Alexander _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".