From: James Almer <jamrial@gmail.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v4 4/4] fate/jpegxl_anim: add demuxer fate test for jpegxl_anim
Date: Tue, 27 Jun 2023 20:25:28 -0300
Message-ID: <4be8b6e4-9829-ad1e-726f-0e459203f313@gmail.com> (raw)
In-Reply-To: <20230626154922.66550-5-leo.izen@gmail.com>
On 6/26/2023 12:49 PM, Leo Izen wrote:
> Adds a fate test for the jpegxl_anim demuxer, that should allow testing
> for true positives and false positives for animated jpegxl files. Note
> that two of the test cases are not animated, in order to help sort out
> false positives.
>
> Signed-off-by: <leo.izen@gmail.com>
> ---
> tests/Makefile | 1 +
> tests/fate/jxl.mak | 16 ++++++++++++++++
> tests/ref/fate/jxl-anim-demux-belgium | 6 ++++++
> tests/ref/fate/jxl-anim-demux-icos4d | 6 ++++++
> tests/ref/fate/jxl-anim-demux-lenna256 | 7 +++++++
> tests/ref/fate/jxl-anim-demux-newton | 6 ++++++
> 6 files changed, 42 insertions(+)
> create mode 100644 tests/fate/jxl.mak
> create mode 100644 tests/ref/fate/jxl-anim-demux-belgium
> create mode 100644 tests/ref/fate/jxl-anim-demux-icos4d
> create mode 100644 tests/ref/fate/jxl-anim-demux-lenna256
> create mode 100644 tests/ref/fate/jxl-anim-demux-newton
>
> diff --git a/tests/Makefile b/tests/Makefile
> index e09f30a0fc..7b80762e81 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -201,6 +201,7 @@ include $(SRC_PATH)/tests/fate/image.mak
> include $(SRC_PATH)/tests/fate/imf.mak
> include $(SRC_PATH)/tests/fate/indeo.mak
> include $(SRC_PATH)/tests/fate/jpeg2000.mak
> +include $(SRC_PATH)/tests/fate/jxl.mak
> include $(SRC_PATH)/tests/fate/libavcodec.mak
> include $(SRC_PATH)/tests/fate/libavdevice.mak
> include $(SRC_PATH)/tests/fate/libavformat.mak
> diff --git a/tests/fate/jxl.mak b/tests/fate/jxl.mak
> new file mode 100644
> index 0000000000..057d3be0e1
> --- /dev/null
> +++ b/tests/fate/jxl.mak
> @@ -0,0 +1,16 @@
> +# These two are animated JXL files
> +FATE_JPEGXL_ANIM_DEMUX += fate-jxl-anim-demux-newton
> +fate-jxl-anim-demux-newton: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/newton.jxl -c copy
> +FATE_JPEGXL_ANIM_DEMUX += fate-jxl-anim-demux-icos4d
> +fate-jxl-anim-demux-icos4d: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/icos4d.jxl -c copy
> +
> +# These two are not animated JXL. They are here to check false positives.
> +FATE_JPEGXL_ANIM_DEMUX += fate-jxl-anim-demux-belgium
> +fate-jxl-anim-demux-belgium: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/belgium.jxl -c copy
> +FATE_JPEGXL_ANIM_DEMUX += fate-jxl-anim-demux-lenna256
> +fate-jxl-anim-demux-lenna256: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/lenna-256.jxl -c copy
> +
> +FATE_JPEGXL_ANIM_DEMUX += $(FATE_JPEGXL_ANIM_DEMUX-yes)
> +
> +FATE_SAMPLES_FFMPEG-$(call FRAMECRC, JPEGXL_ANIM) += $(FATE_JPEGXL_ANIM_DEMUX)
> +fate-jxl-anim-demux: $(FATE_JPEGXL_ANIM_DEMUX)
> diff --git a/tests/ref/fate/jxl-anim-demux-belgium b/tests/ref/fate/jxl-anim-demux-belgium
> new file mode 100644
> index 0000000000..b2fe5035ac
> --- /dev/null
> +++ b/tests/ref/fate/jxl-anim-demux-belgium
> @@ -0,0 +1,6 @@
> +#tb 0: 1/25
> +#media_type 0: video
> +#codec_id 0: jpegxl
> +#dimensions 0: 768x512
> +#sar 0: 0/1
> +0, 0, 0, 1, 32, 0xa2930a20
> diff --git a/tests/ref/fate/jxl-anim-demux-icos4d b/tests/ref/fate/jxl-anim-demux-icos4d
> new file mode 100644
> index 0000000000..eff6ff1f1b
> --- /dev/null
> +++ b/tests/ref/fate/jxl-anim-demux-icos4d
> @@ -0,0 +1,6 @@
> +#tb 0: 1/1000
> +#media_type 0: video
> +#codec_id 0: jpegxl
> +#dimensions 0: 48x48
> +#sar 0: 0/1
> +0, 0, 0, 0, 67898, 0x53b6516b
> diff --git a/tests/ref/fate/jxl-anim-demux-lenna256 b/tests/ref/fate/jxl-anim-demux-lenna256
> new file mode 100644
> index 0000000000..0bd286a451
> --- /dev/null
> +++ b/tests/ref/fate/jxl-anim-demux-lenna256
> @@ -0,0 +1,7 @@
> +#tb 0: 1/25
> +#media_type 0: video
> +#codec_id 0: jpegxl
> +#dimensions 0: 256x256
> +#sar 0: 0/1
> +0, 0, 0, 1, 4096, 0x2409e9e3
> +0, 1, 1, 1, 3992, 0x966dbfcb
What this tells me is that the parser needs to do bitstream assembly
after all. Image2 should not propagate a single image split in two
packets like this, at the arbitrary limit of 4kb.
Since this format seems to have actual delimiters
(FF_JPEGXL_CODESTREAM_SIGNATURE_LE and FF_JPEGXL_CONTAINER_SIGNATURE_LE)
and even buffer bytes with ff_jpegxl_collect_codestream_header(), you
should then do the assembly in the parser, much like it's done for bmp,
jpg and many other image formats.
The anim demuxer can remain as PARSE_HEADERS so it doesn't run the frame
assembly code.
> diff --git a/tests/ref/fate/jxl-anim-demux-newton b/tests/ref/fate/jxl-anim-demux-newton
> new file mode 100644
> index 0000000000..6fcb85c41e
> --- /dev/null
> +++ b/tests/ref/fate/jxl-anim-demux-newton
> @@ -0,0 +1,6 @@
> +#tb 0: 1/1000
> +#media_type 0: video
> +#codec_id 0: jpegxl
> +#dimensions 0: 128x96
> +#sar 0: 0/1
> +0, 0, 0, 0, 43376, 0xb2296182
_______________________________________________
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".
next prev parent reply other threads:[~2023-06-27 23:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-26 15:49 [FFmpeg-devel] [PATCH v4 0/4] JPEG XL Parser Leo Izen
2023-06-26 15:49 ` [FFmpeg-devel] [PATCH v4 1/4] avcodec/libjxldec: use internal AVFrame as buffered space Leo Izen
2023-06-27 20:08 ` Andreas Rheinhardt
2023-06-26 15:49 ` [FFmpeg-devel] [PATCH v4 2/4] avcodec/jpegxl_parser: add JPEG XL parser Leo Izen
2023-06-27 22:58 ` James Almer
2023-06-27 23:18 ` Leo Izen
2023-06-27 23:20 ` James Almer
2023-06-26 15:49 ` [FFmpeg-devel] [PATCH v4 3/4] avformat/jpegxl: remove jpegxl_probe, instead call avcodec/jpegxl_parse Leo Izen
2023-06-26 15:49 ` [FFmpeg-devel] [PATCH v4 4/4] fate/jpegxl_anim: add demuxer fate test for jpegxl_anim Leo Izen
2023-06-27 23:25 ` James Almer [this message]
2023-06-27 23:32 ` Leo Izen
2023-06-27 23:46 ` James Almer
2023-06-28 0:33 ` Leo Izen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4be8b6e4-9829-ad1e-726f-0e459203f313@gmail.com \
--to=jamrial@gmail.com \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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