On Mon, 26 May 2025, Andreas Rheinhardt wrote:
ffmpeg | branch: master | Andreas Rheinhardt <andreas.rheinha...@outlook.com> |
Thu May 22 15:57:13 2025 +0200| [0401ca714a2714743573e27c384ffa810fd31a92] |
committer: Andreas Rheinhardt
avcodec/asvenc: Don't waste bits encoding non-visible part
Up until now, the encoder replicated all the border pixels
for incomplete 16x16 macroblocks. In case the available width
or height is <= 8, some of the luma blocks of the MB
do not correspond to actual input, so that we should encode
them using the least amount of bits. Zeroing the block coefficients
(as this commit does) achieves this, replicating the pixels
and performing an FDCT does not.
This commit also removes the frame copying code for insufficiently
aligned dimensions.
The vsynth3-asv[12] FATE tests use a 34x34 input file and are
therefore affected by this. As the ref updates show, the size
and checksum of the encoded changes, yet the decoded output
stays the same.
Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com>
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=0401ca714a2714743573e27c384ffa810fd31a92
---
libavcodec/asvenc.c | 131 ++++++++++++++++++++++++++----------------
tests/ref/vsynth/vsynth3-asv1 | 4 +-
tests/ref/vsynth/vsynth3-asv2 | 4 +-
3 files changed, 84 insertions(+), 55 deletions(-)
As noted on irc, this broke the fate-vsynth3-asv1 and fate-vsynth3-asv2
tests on arm.
The issue is not AV_COPY128 as Andreas wondered on irc; the reason is
a->pdsp.get_pixels. We have a backtrace like this:
#0 0x00cfdd2a in ff_get_pixels_neon ()
at src/libavcodec/arm/pixblockdsp_neon.S:47
#1 0x0082ea54 in dct_get (mb_y=0, mb_x=0, frame=0xf6202f40, a=0x297f450)
at src/libavcodec/asvenc.c:222
#2 encode_frame (avctx=0x297f150, pkt=0xf6202ec0, pict=0xf6202f40,
got_packet=0xf7df4af0) at src/libavcodec/asvenc.c:304
The arguments to a->pdsp.get_pixels are this on entry:
(gdb) info registers r0 r1 r2
r0 0x297f4a0 43512992
r1 0x297caa0 43502240
r2 0x22 34
After one iteration, it hits the bus error due to unaligned reads from the
source, which was expected to stay aligned after incrementing by the
stride.
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
