Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
* [FFmpeg-devel] [PATCH v2] lavc/dxv: align to 4x4 blocks instead of 16x16
@ 2024-02-09 11:26 Connor Worley
  2024-02-09 19:47 ` Martin Storsjö
  0 siblings, 1 reply; 2+ messages in thread
From: Connor Worley @ 2024-02-09 11:26 UTC (permalink / raw)
  To: ffmpeg-devel; +Cc: Connor Worley

The previous assumption that DXV needs to be aligned to 16x16 was
erroneous. 4x4 works just as well, and FATE decoder tests pass for all
texture formats.

On the encoder side, we should reject input that isn't 4x4 aligned,
like the HAP encoder does, and stop aligning to 16x16. This both solves
the uninitialized reads causing current FATE tests to fail and produces
smaller encoded outputs.

With regard to correctness, I've checked the decoding path by encoding a
real-world sample with git master, and decoding it with
  ffmpeg -i dxt1-master.mov -c:v rawvideo -f framecrc -
The results are exactly the same between master and this patch.

On the encoding side, I've encoded a real-world sample with both master
and this patch, and decoded both versions with
  ffmpeg -i dxt1-{master,patch}.mov -c:v rawvideo -f framecrc -
Under this patch, results for both inputs are exactly the same.

In other words, the extra padding gained by 16x16 alignment over 4x4
alignment has no impact on decoded video.

Signed-off-by: Connor Worley <connorbworley@gmail.com>
---
 libavcodec/dxv.c            |  6 +++---
 libavcodec/dxvenc.c         | 14 +++++++++++---
 tests/ref/fate/dxv3enc-dxt1 |  2 +-
 3 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
index e1c7cee3e8..9261a5cac1 100644
--- a/libavcodec/dxv.c
+++ b/libavcodec/dxv.c
@@ -1238,9 +1238,9 @@ static int dxv_init(AVCodecContext *avctx)
         return ret;
     }

-    /* Codec requires 16x16 alignment. */
-    avctx->coded_width  = FFALIGN(avctx->width,  16);
-    avctx->coded_height = FFALIGN(avctx->height, 16);
+    /* Since codec is based on 4x4 blocks, size is aligned to 4 */
+    avctx->coded_width  = FFALIGN(avctx->width,  TEXTURE_BLOCK_W);
+    avctx->coded_height = FFALIGN(avctx->height, TEXTURE_BLOCK_H);

     ff_texturedsp_init(&ctx->texdsp);

diff --git a/libavcodec/dxvenc.c b/libavcodec/dxvenc.c
index b274175689..33a18d53d8 100644
--- a/libavcodec/dxvenc.c
+++ b/libavcodec/dxvenc.c
@@ -275,6 +275,14 @@ static av_cold int dxv_init(AVCodecContext *avctx)
         return ret;
     }

+    if (avctx->width % TEXTURE_BLOCK_W || avctx->height % TEXTURE_BLOCK_H) {
+        av_log(avctx,
+               AV_LOG_ERROR,
+               "Video size %dx%d is not multiple of "AV_STRINGIFY(TEXTURE_BLOCK_W)"x"AV_STRINGIFY(TEXTURE_BLOCK_H)".\n",
+               avctx->width, avctx->height);
+        return AVERROR_INVALIDDATA;
+    }
+
     ff_texturedspenc_init(&texdsp);

     switch (ctx->tex_fmt) {
@@ -288,10 +296,10 @@ static av_cold int dxv_init(AVCodecContext *avctx)
         return AVERROR_INVALIDDATA;
     }
     ctx->enc.raw_ratio = 16;
-    ctx->tex_size = FFALIGN(avctx->width, 16) / TEXTURE_BLOCK_W *
-                    FFALIGN(avctx->height, 16) / TEXTURE_BLOCK_H *
+    ctx->tex_size = avctx->width  / TEXTURE_BLOCK_W *
+                    avctx->height / TEXTURE_BLOCK_H *
                     ctx->enc.tex_ratio;
-    ctx->enc.slice_count = av_clip(avctx->thread_count, 1, FFALIGN(avctx->height, 16) / TEXTURE_BLOCK_H);
+    ctx->enc.slice_count = av_clip(avctx->thread_count, 1, avctx->height / TEXTURE_BLOCK_H);

     ctx->tex_data = av_malloc(ctx->tex_size);
     if (!ctx->tex_data) {
diff --git a/tests/ref/fate/dxv3enc-dxt1 b/tests/ref/fate/dxv3enc-dxt1
index 3cfd73397e..74849a8031 100644
--- a/tests/ref/fate/dxv3enc-dxt1
+++ b/tests/ref/fate/dxv3enc-dxt1
@@ -3,4 +3,4 @@
 #codec_id 0: dxv
 #dimensions 0: 1920x1080
 #sar 0: 1/1
-0,          0,          0,        1,    76767, 0x932ecbfa
+0,          0,          0,        1,    76521, 0xed387a5e
--
2.40.1
_______________________________________________
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".

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [FFmpeg-devel] [PATCH v2] lavc/dxv: align to 4x4 blocks instead of 16x16
  2024-02-09 11:26 [FFmpeg-devel] [PATCH v2] lavc/dxv: align to 4x4 blocks instead of 16x16 Connor Worley
@ 2024-02-09 19:47 ` Martin Storsjö
  0 siblings, 0 replies; 2+ messages in thread
From: Martin Storsjö @ 2024-02-09 19:47 UTC (permalink / raw)
  To: FFmpeg development discussions and patches; +Cc: Connor Worley

On Fri, 9 Feb 2024, Connor Worley wrote:

> The previous assumption that DXV needs to be aligned to 16x16 was
> erroneous. 4x4 works just as well, and FATE decoder tests pass for all
> texture formats.
>
> On the encoder side, we should reject input that isn't 4x4 aligned,
> like the HAP encoder does, and stop aligning to 16x16. This both solves
> the uninitialized reads causing current FATE tests to fail and produces
> smaller encoded outputs.
>
> With regard to correctness, I've checked the decoding path by encoding a
> real-world sample with git master, and decoding it with
>  ffmpeg -i dxt1-master.mov -c:v rawvideo -f framecrc -
> The results are exactly the same between master and this patch.
>
> On the encoding side, I've encoded a real-world sample with both master
> and this patch, and decoded both versions with
>  ffmpeg -i dxt1-{master,patch}.mov -c:v rawvideo -f framecrc -
> Under this patch, results for both inputs are exactly the same.
>
> In other words, the extra padding gained by 16x16 alignment over 4x4
> alignment has no impact on decoded video.
>
> Signed-off-by: Connor Worley <connorbworley@gmail.com>
> ---
> libavcodec/dxv.c            |  6 +++---
> libavcodec/dxvenc.c         | 14 +++++++++++---
> tests/ref/fate/dxv3enc-dxt1 |  2 +-
> 3 files changed, 15 insertions(+), 7 deletions(-)

LGTM, will push soon to get FATE back to green again.

// 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-request@ffmpeg.org with subject "unsubscribe".

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-02-09 19:47 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-09 11:26 [FFmpeg-devel] [PATCH v2] lavc/dxv: align to 4x4 blocks instead of 16x16 Connor Worley
2024-02-09 19:47 ` Martin Storsjö

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git