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