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 6BD0B42C38 for ; Fri, 1 Jul 2022 20:15:24 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5D64368B7B3; Fri, 1 Jul 2022 23:15:22 +0300 (EEST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C492068B766 for ; Fri, 1 Jul 2022 23:15:15 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id ADCF4E0005 for ; Fri, 1 Jul 2022 20:15:14 +0000 (UTC) Date: Fri, 1 Jul 2022 22:15:13 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220701201513.GW396728@pb2> References: <20220701053434.2137992-1-wenbin.chen@intel.com> MIME-Version: 1.0 In-Reply-To: <20220701053434.2137992-1-wenbin.chen@intel.com> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/mpegvideo_enc: Fix a chroma mb size error in sse_mb() 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="===============2871272804520833028==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============2871272804520833028== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZM8KhnpE6nnHs8oN" Content-Disposition: inline --ZM8KhnpE6nnHs8oN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 01, 2022 at 01:34:34PM +0800, Wenbin Chen wrote: > For 422 frames we should not use hard coded 8 to calculate mb size for > uv plane. Chroma shift should be taken into consideration to be > compatiple with different sampling format. >=20 > The error is reported by fate test when av_cpu_max_align() return 64 > on the platform supporting AVX512. This is a hidden error and it is > exposed after commit 17a59a634c39b00a680c6ebbaea58db95594d13d. >=20 > mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum of > squared error) on current mb, reconstructed mb will be wrote to the > previous mb space, so that the memory can be saved. However if the align > is 64, the frame is shared in somewhere else, so the frame cannot be > reused and a new frame to store reconstrued data is created. Because the > height of mb is wrong when compute sse on 422 frame, starting from the > second line of macro block, changed data is read when frame is reused > (we need to read row 16 rather than row 8 if frame is 422), and unchanged > data is read when frame is not reused (a new frame is created so the > original frame will not be changed). >=20 > That is why commit 17a59a634c39b00a680c6ebbaea58db95594d13d exposes this > issue, because it add av_cpu_max_align() and this function return 64 on > platform supporting AVX512 which lead to creating a frame in mpeg2enc, > and this lead to the different outputs. >=20 > Signed-off-by: Wenbin Chen > --- > libavcodec/mpegvideo_enc.c | 29 +++++++++++++------ > tests/ref/seek/vsynth_lena-mpeg2-422 | 40 +++++++++++++------------- > tests/ref/vsynth/vsynth1-mpeg2-422 | 8 +++--- > tests/ref/vsynth/vsynth2-mpeg2-422 | 8 +++--- > tests/ref/vsynth/vsynth3-mpeg2-422 | 8 +++--- > tests/ref/vsynth/vsynth_lena-mpeg2-422 | 8 +++--- > 6 files changed, 56 insertions(+), 45 deletions(-) >=20 > diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c > index d6a85a037a..c9d9e2a764 100644 > --- a/libavcodec/mpegvideo_enc.c > +++ b/libavcodec/mpegvideo_enc.c > @@ -2558,24 +2558,35 @@ static int sse(MpegEncContext *s, uint8_t *src1, = uint8_t *src2, int w, int h, in > static int sse_mb(MpegEncContext *s){ > int w=3D 16; > int h=3D 16; > + int chroma_mb_w =3D w >> s->chroma_x_shift; > + int chroma_mb_h =3D h >> s->chroma_y_shift; > =20 > if(s->mb_x*16 + 16 > s->width ) w=3D s->width - s->mb_x*16; > if(s->mb_y*16 + 16 > s->height) h=3D s->height- s->mb_y*16; > =20 > if(w=3D=3D16 && h=3D=3D16) > if(s->avctx->mb_cmp =3D=3D FF_CMP_NSSE){ > - return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x * 16= + s->mb_y * s->linesize * 16, s->dest[0], s->linesize, 16) + > + return s->mecc.nsse[0](s, s->new_picture->data[0] + s->mb_x * 16= + s->mb_y * s->linesize * 16, > + s->dest[0], s->linesize, 16) + This doesnt belong in this patch, its not a functional change and makes it harder to see what is changed please seperate this in a seperate patch if you want to suggest this whites= pace change thx > - s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x * 8= + s->mb_y * s->uvlinesize * 8, s->dest[1], s->uvlinesize, 8) + > - s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x * 8= + s->mb_y * s->uvlinesize * 8, s->dest[2], s->uvlinesize, 8); > + s->mecc.nsse[1](s, s->new_picture->data[1] + s->mb_x * ch= roma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h, > + s->dest[1], s->uvlinesize, chroma_mb_h) + > + s->mecc.nsse[1](s, s->new_picture->data[2] + s->mb_x * ch= roma_mb_w + s->mb_y * s->uvlinesize * chroma_mb_h, > + s->dest[2], s->uvlinesize, chroma_mb_h); [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. --ZM8KhnpE6nnHs8oN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYr9VzQAKCRBhHseHBAsP q9ICAJ9cs0paaiFicOqyRwc6en6kSAj+zACePAp+vr1FfQzfDS531FlNGLwhaEo= =q8U/ -----END PGP SIGNATURE----- --ZM8KhnpE6nnHs8oN-- --===============2871272804520833028== 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". --===============2871272804520833028==--