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 E868E43050 for ; Mon, 17 Oct 2022 20:39:04 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D7EC168BCCA; Mon, 17 Oct 2022 23:39:01 +0300 (EEST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E263E68BBDE for ; Mon, 17 Oct 2022 23:38:55 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 8410D1C0004 for ; Mon, 17 Oct 2022 20:38:54 +0000 (UTC) Date: Mon, 17 Oct 2022 22:38:53 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20221017203853.GA907335@pb2> References: MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] avcodec/svq1: fix interframe mean VLC symbols 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: multipart/mixed; boundary="===============1043479522111865790==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1043479522111865790== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 17, 2022 at 08:33:28PM +1100, Peter Ross wrote: > On Mon, Oct 17, 2022 at 05:04:29AM +0200, Andreas Rheinhardt wrote: > > Peter Ross: > > > Fixes ticket #128. > > >=20 > > > The SVQ1 interframe mean VLC symbols -128 and 128 are incorrectly swa= pped > > > in our SVQ1 implementation, resulting in visible artifacts for some v= ideos. > > > This patch unswaps the order of these two symbols. > > >=20 > > > The most noticable example of the artiacts caused by this error can b= e observed in > > > https://trac.ffmpeg.org/attachment/ticket/128/svq1_set.7z '352_288_k_= 50.mov'. > > > The artifacts are not observed when using the reference decoder > > > (QuickTime 7.7.9 x86 binary). > > >=20 > > > As a result of this patch, the reference data for the fate-svq1 test > > > ($SAMPLES/svq1/marymary-shackles.mov) must be modified. For this file= , our > > > decoder output is now bitwise identical to the reference decoder. I h= ave > > > tested patch with various other samples and they are all now bitwise = identical. > >=20 > > Seems like this is not the only test whose reference needs to be > > updated. There are also the fate-vsynth%-svq1 tests. >=20 > Right, the encoder. This change will cause previous videos created by the= FFmpeg > encoder to playback *with* artifacts in newer builds of FFmpeg with this = patch > applied. There is not much we can do about this, since there isn't place = for a > version string in the SVQ3 bitstream (unlike MPEG-4 etc). it is possible i think to avoid this we just need anything that differs reasonably consistently between the bina= ry encoder and the ffmpeg encoder the first thing that comes to mind is the temporal reference values, we seem to always store 0 but there may be other things we do that differ This fix will need some caution so everything keeps working=20 1. we need the decoder to detect the official and our old buggy encoder and= =20 handle each appropriately 2. when we fix our encoder there are at least 3 ways 2a. avoid the ambigous codes, these will decode fine in all cases 2b. whatever we used to detect the official encoder we can mimic that too while fixing this. but that may be a one shot opertunity 2c. find a cleaner way to store our version first, implment that in the decoder and then use it in the encoder when we fix this. This would need some testing to make sure it works with the official decoder I see a few things that might work for the version. the decoder decodes some "embedded message", theres the temporal reference which seems not mattering there are various encoder choices that allow embeding some message if o= ne really wanted thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCY029VQAKCRBhHseHBAsP qwZnAKCQWPfGY6xn6r+B9cBcnf4zw4V59gCcC0FWNVVn8kY8WaUn7YbaqgFqjxY= =0Gcf -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- --===============1043479522111865790== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============1043479522111865790==--