Re: [FFmpeg-devel] [PATCH v4 4/4] fate/jpegxl_anim: add demuxer fate test for jpegxl_anim
On 6/27/23 19:46, James Almer wrote: On 6/27/2023 8:32 PM, Leo Izen wrote: On 6/27/23 19:25, James Almer wrote: 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: --- 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 00..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 00..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 00..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 00..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. The codestream signature is 0xFF 0x0A, which can and frequently will occur unescaped in the middle of a valid file. Detecting the end of the file is also a Hard Problem as it requires an entropy decoder, which I believe you NAK'd for being overly complex for a parser in the first iteration of this a few months ago. Can you link that first iteration? https://patchwork.ffmpeg.org/project/ffmpeg/cover/20220401002006.44582-1-leo.i...@gmail.com/ If I choose to assemble a bitstream here with the parser, what will end up happening is that the entire sequence of all input frames will be one large AVPacket, as detecting the end of
Re: [FFmpeg-devel] [PATCH v4 4/4] fate/jpegxl_anim: add demuxer fate test for jpegxl_anim
On 6/27/2023 8:32 PM, Leo Izen wrote: On 6/27/23 19:25, James Almer wrote: 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: --- 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 00..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 00..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 00..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 00..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. The codestream signature is 0xFF 0x0A, which can and frequently will occur unescaped in the middle of a valid file. Detecting the end of the file is also a Hard Problem as it requires an entropy decoder, which I believe you NAK'd for being overly complex for a parser in the first iteration of this a few months ago. Can you link that first iteration? If I choose to assemble a bitstream here with the parser, what will end up happening is that the entire sequence of all input frames will be one large AVPacket, as detecting the end of the image is nontrivial. Is this behavior desirable, compared to what image2dec does, which is emit arbitrary 4k-sized packets? What
Re: [FFmpeg-devel] [PATCH v4 4/4] fate/jpegxl_anim: add demuxer fate test for jpegxl_anim
On 6/27/23 19:25, James Almer wrote: 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: --- 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 00..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 00..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 00..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 00..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. The codestream signature is 0xFF 0x0A, which can and frequently will occur unescaped in the middle of a valid file. Detecting the end of the file is also a Hard Problem as it requires an entropy decoder, which I believe you NAK'd for being overly complex for a parser in the first iteration of this a few months ago. If I choose to assemble a bitstream here with the parser, what will end up happening is that the entire sequence of all input frames will be one large AVPacket, as detecting the end of the image is nontrivial. Is this behavior desirable, compared to what image2dec does, which is emit arbitrary 4k-sized packets? If so, I can change it to assemble a packet, but I just want to make sure that
Re: [FFmpeg-devel] [PATCH v4 4/4] fate/jpegxl_anim: add demuxer fate test for jpegxl_anim
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: --- 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 00..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 00..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 00..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 00..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 00..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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 2/4] avcodec/jpegxl_parser: add JPEG XL parser
On 6/27/2023 8:18 PM, Leo Izen wrote:
On 6/27/23 18:58, James Almer wrote:
On 6/26/2023 12:49 PM, Leo Izen wrote:
+/*
+ * copies as much of the codestream into the buffer as possible
+ * pass a shorter buflen to request less
+ * returns the number of bytes consumed from input, may be greater
than input_len
+ * if the input doesn't end on an ISOBMFF-box boundary
+ */
+int ff_jpegxl_collect_codestream_header(const uint8_t *input_buffer,
int input_len,
+ uint8_t *buffer, int buflen,
int *copied)
+{
+ GetByteContext gb;
+ int pos = 0;
+ bytestream2_init(, input_buffer, input_len);
+
+ while (1) {
+ uint64_t size;
+ uint32_t tag;
+ int head_size = 8;
+
+ if (bytestream2_get_bytes_left() < 16)
+ break;
+
+ size = bytestream2_get_be32();
+ if (size == 1) {
+ size = bytestream2_get_be64();
+ head_size = 16;
+ }
+ /* invalid ISOBMFF size */
+ if (size && size <= head_size)
+ return AVERROR_INVALIDDATA;
ISOBMFF? Are you propagating container bytes as if they were part of
the bitstream from image2? Why is it not being handled by the mov/mp4
demuxer instead?
It's not actually ISOBMFF, it just uses the same style of box layout.
This is also how j2k works.
Ok.
+ if (ctx->meta.csp == JPEGXL_CS_GRAY) {
+ if (ctx->meta.bit_depth <= 8)
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_YA8 : AV_PIX_FMT_GRAY8;
+ else if (ctx->meta.bit_depth <= 16)
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_YA16 : AV_PIX_FMT_GRAY16;
+ else
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_NONE : AV_PIX_FMT_GRAYF32;
+ } else {
+ if (ctx->meta.bit_depth <= 8)
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_RGBA : AV_PIX_FMT_RGB24;
+ else if (ctx->meta.bit_depth <= 16)
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_RGBA64 : AV_PIX_FMT_RGB48;
+ else
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_RGBAF32 : AV_PIX_FMT_RGBF32;
Again, don't fill avctx->pix_fmt, fill s->format.
___
If I don't fill this, the CLI will not show the pixel format without the
external decoder library enabled. Should I consider this an ffmpeg.c bug?
That's expected, and it's not a bug. A given decoder can and many times
disagrees with the parser. In an scenario without a decoder, remuxing
still works as pix_fmt is not a container level parameter.
___
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".
Re: [FFmpeg-devel] [PATCH v4 2/4] avcodec/jpegxl_parser: add JPEG XL parser
On 6/27/23 18:58, James Almer wrote:
On 6/26/2023 12:49 PM, Leo Izen wrote:
+/*
+ * copies as much of the codestream into the buffer as possible
+ * pass a shorter buflen to request less
+ * returns the number of bytes consumed from input, may be greater
than input_len
+ * if the input doesn't end on an ISOBMFF-box boundary
+ */
+int ff_jpegxl_collect_codestream_header(const uint8_t *input_buffer,
int input_len,
+ uint8_t *buffer, int buflen,
int *copied)
+{
+ GetByteContext gb;
+ int pos = 0;
+ bytestream2_init(, input_buffer, input_len);
+
+ while (1) {
+ uint64_t size;
+ uint32_t tag;
+ int head_size = 8;
+
+ if (bytestream2_get_bytes_left() < 16)
+ break;
+
+ size = bytestream2_get_be32();
+ if (size == 1) {
+ size = bytestream2_get_be64();
+ head_size = 16;
+ }
+ /* invalid ISOBMFF size */
+ if (size && size <= head_size)
+ return AVERROR_INVALIDDATA;
ISOBMFF? Are you propagating container bytes as if they were part of the
bitstream from image2? Why is it not being handled by the mov/mp4
demuxer instead?
It's not actually ISOBMFF, it just uses the same style of box layout.
This is also how j2k works.
+ if (ctx->meta.csp == JPEGXL_CS_GRAY) {
+ if (ctx->meta.bit_depth <= 8)
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_YA8 : AV_PIX_FMT_GRAY8;
+ else if (ctx->meta.bit_depth <= 16)
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_YA16 : AV_PIX_FMT_GRAY16;
+ else
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_NONE : AV_PIX_FMT_GRAYF32;
+ } else {
+ if (ctx->meta.bit_depth <= 8)
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_RGBA : AV_PIX_FMT_RGB24;
+ else if (ctx->meta.bit_depth <= 16)
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_RGBA64 : AV_PIX_FMT_RGB48;
+ else
+ avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_RGBAF32 : AV_PIX_FMT_RGBF32;
Again, don't fill avctx->pix_fmt, fill s->format.
___
If I don't fill this, the CLI will not show the pixel format without the
external decoder library enabled. Should I consider this an ffmpeg.c bug?
- Leo Izen
___
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".
Re: [FFmpeg-devel] [PATCH v4 2/4] avcodec/jpegxl_parser: add JPEG XL parser
On 6/26/2023 12:49 PM, Leo Izen wrote:
+/*
+ * copies as much of the codestream into the buffer as possible
+ * pass a shorter buflen to request less
+ * returns the number of bytes consumed from input, may be greater than
input_len
+ * if the input doesn't end on an ISOBMFF-box boundary
+ */
+int ff_jpegxl_collect_codestream_header(const uint8_t *input_buffer, int
input_len,
+uint8_t *buffer, int buflen, int
*copied)
+{
+GetByteContext gb;
+int pos = 0;
+bytestream2_init(, input_buffer, input_len);
+
+while (1) {
+uint64_t size;
+uint32_t tag;
+int head_size = 8;
+
+if (bytestream2_get_bytes_left() < 16)
+break;
+
+size = bytestream2_get_be32();
+if (size == 1) {
+size = bytestream2_get_be64();
+head_size = 16;
+}
+/* invalid ISOBMFF size */
+if (size && size <= head_size)
+return AVERROR_INVALIDDATA;
ISOBMFF? Are you propagating container bytes as if they were part of the
bitstream from image2? Why is it not being handled by the mov/mp4
demuxer instead?
+if (ctx->meta.csp == JPEGXL_CS_GRAY) {
+if (ctx->meta.bit_depth <= 8)
+avctx->pix_fmt = s->format = ctx->meta.have_alpha ? AV_PIX_FMT_YA8
: AV_PIX_FMT_GRAY8;
+else if (ctx->meta.bit_depth <= 16)
+avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_YA16 : AV_PIX_FMT_GRAY16;
+else
+avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_NONE : AV_PIX_FMT_GRAYF32;
+} else {
+if (ctx->meta.bit_depth <= 8)
+avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_RGBA : AV_PIX_FMT_RGB24;
+else if (ctx->meta.bit_depth <= 16)
+avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_RGBA64 : AV_PIX_FMT_RGB48;
+else
+avctx->pix_fmt = s->format = ctx->meta.have_alpha ?
AV_PIX_FMT_RGBAF32 : AV_PIX_FMT_RGBF32;
Again, don't fill avctx->pix_fmt, fill s->format.
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/vlc: auto calculate depth
Paul B Mahol:
> On Tue, Jun 27, 2023 at 11:45 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Paul B Mahol:
>>> On Tue, Jun 27, 2023 at 11:05 PM Andreas Rheinhardt <
>>> andreas.rheinha...@outlook.com> wrote:
>>>
Paul B Mahol:
> On Tue, Jun 27, 2023 at 9:47 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Paul B Mahol:
>>> Patch attached.
>>>
>>
>> Where do you intend to use this? What is the point of it?
>> After all, using this value in GET_VLC makes no sense; only
>> compile-time
>> constants do.
>>
>
> It works when used in ac-4 as get_vlc2.
>
Could you please define "works"? Using a non-compile-time constant will
not benefit at all; it will only lead to more runtime checks.
>>>
>>> I do not follow your worries.
>>> I can not use compile time constant as its very complicated code.
>>>
>>
>> Let's take a look at GET_VLC:
>> #define GET_VLC(code, name, gb, table, bits, max_depth) \
>> do {\
>> int n, nb_bits; \
>> unsigned int index; \
>> \
>> index = SHOW_UBITS(name, gb, bits); \
>> code = table[index].sym; \
>> n = table[index].len; \
>> \
>> if (max_depth > 1 && n < 0) { \
>> LAST_SKIP_BITS(name, gb, bits); \
>> UPDATE_CACHE(name, gb); \
>> \
>> nb_bits = -n; \
>> \
>> index = SHOW_UBITS(name, gb, nb_bits) + code; \
>> code = table[index].sym; \
>> n = table[index].len; \
>> if (max_depth > 2 && n < 0) { \
>> LAST_SKIP_BITS(name, gb, nb_bits); \
>> UPDATE_CACHE(name, gb); \
>> \
>> nb_bits = -n; \
>> \
>> index = SHOW_UBITS(name, gb, nb_bits) + code; \
>> code = table[index].sym; \
>> n = table[index].len; \
>> } \
>> } \
>> SKIP_BITS(name, gb, n); \
>> } while (0)
>>
>> If max_depth is not a compile-time constant, then the compiler will have
>> to perform both of the max_depth > 1 && n < 0 checks; yet, this is not
>> useful: If the depth of a particular VLC is (say) 1, then none of the
>> possible bits read will lead to reloading at all, because the n < 0
>> condition will never be true; the only reason this condition exists is
>> to use a compile-time upper bound, so that one can eliminate the reload
>> code (and in particular, avoid the runtime checks).
>>
>>> Works means that vlc code is extracted correctly.
>>>
>>
>> If you have no upper bound about max_depth and it works, then use 3.
>>
>
> It does not work to use 3 all the time. And that one never worked in any
> codec so far.
>
I just ran FATE with the check for max_depth removed from GET_VLC and
from read_vlc for the cached API (effectively setting max_depth to 3
everywhere). It passed. So it "works" (but in a suboptimal way). At
least it does if you have ordinary VLCs (created by the vlc.c
functions). Are you doing anything special with them or so?
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/vlc: auto calculate depth
On Tue, Jun 27, 2023 at 11:45 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Paul B Mahol:
> > On Tue, Jun 27, 2023 at 11:05 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Paul B Mahol:
> >>> On Tue, Jun 27, 2023 at 9:47 PM Andreas Rheinhardt <
> >>> andreas.rheinha...@outlook.com> wrote:
> >>>
> Paul B Mahol:
> > Patch attached.
> >
>
> Where do you intend to use this? What is the point of it?
> After all, using this value in GET_VLC makes no sense; only
> compile-time
> constants do.
>
> >>>
> >>> It works when used in ac-4 as get_vlc2.
> >>>
> >>
> >> Could you please define "works"? Using a non-compile-time constant will
> >> not benefit at all; it will only lead to more runtime checks.
> >>
> >
> > I do not follow your worries.
> > I can not use compile time constant as its very complicated code.
> >
>
> Let's take a look at GET_VLC:
> #define GET_VLC(code, name, gb, table, bits, max_depth) \
> do {\
> int n, nb_bits; \
> unsigned int index; \
> \
> index = SHOW_UBITS(name, gb, bits); \
> code = table[index].sym; \
> n = table[index].len; \
> \
> if (max_depth > 1 && n < 0) { \
> LAST_SKIP_BITS(name, gb, bits); \
> UPDATE_CACHE(name, gb); \
> \
> nb_bits = -n; \
> \
> index = SHOW_UBITS(name, gb, nb_bits) + code; \
> code = table[index].sym; \
> n = table[index].len; \
> if (max_depth > 2 && n < 0) { \
> LAST_SKIP_BITS(name, gb, nb_bits); \
> UPDATE_CACHE(name, gb); \
> \
> nb_bits = -n; \
> \
> index = SHOW_UBITS(name, gb, nb_bits) + code; \
> code = table[index].sym; \
> n = table[index].len; \
> } \
> } \
> SKIP_BITS(name, gb, n); \
> } while (0)
>
> If max_depth is not a compile-time constant, then the compiler will have
> to perform both of the max_depth > 1 && n < 0 checks; yet, this is not
> useful: If the depth of a particular VLC is (say) 1, then none of the
> possible bits read will lead to reloading at all, because the n < 0
> condition will never be true; the only reason this condition exists is
> to use a compile-time upper bound, so that one can eliminate the reload
> code (and in particular, avoid the runtime checks).
>
> > Works means that vlc code is extracted correctly.
> >
>
> If you have no upper bound about max_depth and it works, then use 3.
>
It does not work to use 3 all the time. And that one never worked in any
codec so far.
>
> - Andreas
>
> ___
> 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".
>
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/vlc: auto calculate depth
Paul B Mahol:
> On Tue, Jun 27, 2023 at 11:05 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Paul B Mahol:
>>> On Tue, Jun 27, 2023 at 9:47 PM Andreas Rheinhardt <
>>> andreas.rheinha...@outlook.com> wrote:
>>>
Paul B Mahol:
> Patch attached.
>
Where do you intend to use this? What is the point of it?
After all, using this value in GET_VLC makes no sense; only compile-time
constants do.
>>>
>>> It works when used in ac-4 as get_vlc2.
>>>
>>
>> Could you please define "works"? Using a non-compile-time constant will
>> not benefit at all; it will only lead to more runtime checks.
>>
>
> I do not follow your worries.
> I can not use compile time constant as its very complicated code.
>
Let's take a look at GET_VLC:
#define GET_VLC(code, name, gb, table, bits, max_depth) \
do {\
int n, nb_bits; \
unsigned int index; \
\
index = SHOW_UBITS(name, gb, bits); \
code = table[index].sym; \
n = table[index].len; \
\
if (max_depth > 1 && n < 0) { \
LAST_SKIP_BITS(name, gb, bits); \
UPDATE_CACHE(name, gb); \
\
nb_bits = -n; \
\
index = SHOW_UBITS(name, gb, nb_bits) + code; \
code = table[index].sym; \
n = table[index].len; \
if (max_depth > 2 && n < 0) { \
LAST_SKIP_BITS(name, gb, nb_bits); \
UPDATE_CACHE(name, gb); \
\
nb_bits = -n; \
\
index = SHOW_UBITS(name, gb, nb_bits) + code; \
code = table[index].sym; \
n = table[index].len; \
} \
} \
SKIP_BITS(name, gb, n); \
} while (0)
If max_depth is not a compile-time constant, then the compiler will have
to perform both of the max_depth > 1 && n < 0 checks; yet, this is not
useful: If the depth of a particular VLC is (say) 1, then none of the
possible bits read will lead to reloading at all, because the n < 0
condition will never be true; the only reason this condition exists is
to use a compile-time upper bound, so that one can eliminate the reload
code (and in particular, avoid the runtime checks).
> Works means that vlc code is extracted correctly.
>
If you have no upper bound about max_depth and it works, then use 3.
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/vlc: auto calculate depth
On Tue, Jun 27, 2023 at 11:05 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Paul B Mahol: > > On Tue, Jun 27, 2023 at 9:47 PM Andreas Rheinhardt < > > andreas.rheinha...@outlook.com> wrote: > > > >> Paul B Mahol: > >>> Patch attached. > >>> > >> > >> Where do you intend to use this? What is the point of it? > >> After all, using this value in GET_VLC makes no sense; only compile-time > >> constants do. > >> > > > > It works when used in ac-4 as get_vlc2. > > > > Could you please define "works"? Using a non-compile-time constant will > not benefit at all; it will only lead to more runtime checks. > I do not follow your worries. I can not use compile time constant as its very complicated code. Works means that vlc code is extracted correctly. > > - Andreas > > ___ > 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". > ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/vlc: auto calculate depth
Paul B Mahol: > On Tue, Jun 27, 2023 at 9:47 PM Andreas Rheinhardt < > andreas.rheinha...@outlook.com> wrote: > >> Paul B Mahol: >>> Patch attached. >>> >> >> Where do you intend to use this? What is the point of it? >> After all, using this value in GET_VLC makes no sense; only compile-time >> constants do. >> > > It works when used in ac-4 as get_vlc2. > Could you please define "works"? Using a non-compile-time constant will not benefit at all; it will only lead to more runtime checks. - Andreas ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/vlc: auto calculate depth
On Tue, Jun 27, 2023 at 9:47 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Paul B Mahol: > > Patch attached. > > > > Where do you intend to use this? What is the point of it? > After all, using this value in GET_VLC makes no sense; only compile-time > constants do. > It works when used in ac-4 as get_vlc2. > > - Andreas > > ___ > 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". > ___ 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".
Re: [FFmpeg-devel] [PATCH v4 1/4] avcodec/libjxldec: use internal AVFrame as buffered space
Leo Izen:
> Before this commit, the decoder erroneously assumes that the AVFrame
> passed to the receive_frame is the same one each time. Now it keeps an
> internal AVFrame to write into, and copies it over when it's done.
> ---
> libavcodec/libjxldec.c | 38 ++
> 1 file changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
> index 50417bcb02..e516c29be5 100644
> --- a/libavcodec/libjxldec.c
> +++ b/libavcodec/libjxldec.c
> @@ -58,6 +58,7 @@ typedef struct LibJxlDecodeContext {
> int64_t frame_duration;
> int prev_is_last;
> AVRational timebase;
> +AVFrame *frame;
> } LibJxlDecodeContext;
>
> static int libjxl_init_jxl_decoder(AVCodecContext *avctx)
> @@ -104,6 +105,9 @@ static av_cold int libjxl_decode_init(AVCodecContext
> *avctx)
>
> ctx->avpkt = avctx->internal->in_pkt;
> ctx->pts = 0;
> +ctx->frame = av_frame_alloc();
> +if (!ctx->frame)
> +return AVERROR(ENOMEM);
>
> return libjxl_init_jxl_decoder(avctx);
> }
> @@ -351,10 +355,12 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
> AVFrame *frame)
> size_t remaining;
>
> if (!pkt->size) {
> +av_log(avctx, AV_LOG_DEBUG, "Fetching new packet\n");
> av_packet_unref(pkt);
> ret = ff_decode_get_packet(avctx, pkt);
> if (ret < 0 && ret != AVERROR_EOF)
> return ret;
> +av_log(avctx, AV_LOG_DEBUG, "Fetched packet of size: %d\n",
> pkt->size);
These logs have nothing to do with what the patch is supposed to do (and
they would belong in ff_decode_get_packet() anyway instead of in a
single user).
> if (!pkt->size) {
> /* jret set by the last iteration of the loop */
> if (jret == JXL_DEC_NEED_MORE_INPUT) {
> @@ -389,10 +395,6 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
> AVFrame *frame)
> return AVERROR_INVALIDDATA;
> case JXL_DEC_NEED_MORE_INPUT:
> av_log(avctx, AV_LOG_DEBUG, "NEED_MORE_INPUT event emitted\n");
> -if (!pkt->size) {
> -av_packet_unref(pkt);
> -return AVERROR(EAGAIN);
> -}
> continue;
> case JXL_DEC_BASIC_INFO:
> av_log(avctx, AV_LOG_DEBUG, "BASIC_INFO event emitted\n");
> @@ -421,16 +423,18 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
> AVFrame *frame)
> continue;
> case JXL_DEC_COLOR_ENCODING:
> av_log(avctx, AV_LOG_DEBUG, "COLOR_ENCODING event emitted\n");
> -if ((ret = libjxl_color_encoding_event(avctx, frame)) < 0)
> +if ((ret = libjxl_color_encoding_event(avctx, ctx->frame)) < 0)
> return ret;
> continue;
> case JXL_DEC_NEED_IMAGE_OUT_BUFFER:
> av_log(avctx, AV_LOG_DEBUG, "NEED_IMAGE_OUT_BUFFER event
> emitted\n");
> -if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
> +ret = ff_get_buffer(avctx, ctx->frame, 0);
> +if (ret < 0)
> return ret;
> -ctx->jxl_pixfmt.align = frame->linesize[0];
> -if (JxlDecoderSetImageOutBuffer(ctx->decoder, >jxl_pixfmt,
> frame->data[0], frame->buf[0]->size)
> -!= JXL_DEC_SUCCESS) {
> +ctx->jxl_pixfmt.align = ctx->frame->linesize[0];
> +if (JxlDecoderSetImageOutBuffer(ctx->decoder, >jxl_pixfmt,
> +ctx->frame->data[0], ctx->frame->buf[0]->size)
> +!= JXL_DEC_SUCCESS) {
> av_log(avctx, AV_LOG_ERROR, "Bad libjxl dec need image out
> buffer event\n");
> return AVERROR_EXTERNAL;
> }
> @@ -444,8 +448,8 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
> AVFrame *frame)
> case JXL_DEC_FRAME:
> av_log(avctx, AV_LOG_DEBUG, "FRAME event emitted\n");
> if (!ctx->basic_info.have_animation || ctx->prev_is_last) {
> -frame->pict_type = AV_PICTURE_TYPE_I;
> -frame->flags |= AV_FRAME_FLAG_KEY;
> +ctx->frame->pict_type = AV_PICTURE_TYPE_I;
> +ctx->frame->flags |= AV_FRAME_FLAG_KEY;
> }
> if (ctx->basic_info.have_animation) {
> JxlFrameHeader header;
> @@ -464,20 +468,21 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
> AVFrame *frame)
> /* full image is one frame, even if animated */
> av_log(avctx, AV_LOG_DEBUG, "FULL_IMAGE event emitted\n");
> if (ctx->iccp) {
> -AVFrameSideData *sd = av_frame_new_side_data_from_buf(frame,
> AV_FRAME_DATA_ICC_PROFILE, ctx->iccp);
> +AVFrameSideData *sd =
> av_frame_new_side_data_from_buf(ctx->frame, AV_FRAME_DATA_ICC_PROFILE,
> ctx->iccp);
> if (!sd)
>
Re: [FFmpeg-devel] [PATCH] avcodec/vlc: auto calculate depth
Paul B Mahol: > Patch attached. > Where do you intend to use this? What is the point of it? After all, using this value in GET_VLC makes no sense; only compile-time constants do. - Andreas ___ 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".
[FFmpeg-devel] [PATCH] avcodec/mpeg12dec: ignore picture start code in extradata for AVID mpeg2 files
AVID IMX MPEG2 files in MOV seems to have extradata like this:
: 0018 4143 4c52 4143 4c52 3030 3031 ACLRACLR0001
0010: 0001
Signed-off-by: Marton Balint
---
libavcodec/mpeg12dec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 27c862ffb2..27b45c6fc4 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2522,6 +2522,11 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame
*picture,
}
picture_start_code_seen = 1;
+if (buf == avctx->extradata && avctx->codec_tag ==
AV_RL32("AVmp")) {
+av_log(avctx, AV_LOG_WARNING, "ignoring picture start code in
AVmp extradata\n");
+break;
+}
+
if (s2->width <= 0 || s2->height <= 0) {
av_log(avctx, AV_LOG_ERROR, "Invalid frame dimensions
%dx%d.\n",
s2->width, s2->height);
--
2.35.3
___
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".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
Le sunnuntaina 25. kesäkuuta 2023, 1.19.04 EEST Nicolas George a écrit : > Michael Niedermayer (12023-06-23): > > * What iam interrested in was working with the signals at a low level, why > > because i find it interresting and fun. > > Then this is what you should be spending your time on, and to hell with > anybody who says otherwise. Straw man much? The argument is that SDR does not belong in FFmpeg master, not that Michael cannot do SDR in his free time. > Unless you have commitments that we are not privy of, nobody can tell > you how you are supposed to be spending your time and skills. FYI https://fflabs.eu/about/ > Nobody can force you to manage releases and fix fuzzing bugs and do all the > things you do that are necessary to the project. Necessary to a conception > of the good of the project that is not even your own I think. Same straw man argument. > Nobody can prevent you from hacking the things that motivate you. At > worst, they can prevent you from committing the resulting code into > official FFmpeg. That would be the project's loss, Not cluttering an open-source project is generally considered to be a win, not a loss. Less maintainance work and smaller code size. > and you can still > publish it on a private branch. But they do not have the power to block > you from pushing. > It is not even clear they have the authority do block > you, more so if the code is really good and fits FFmpeg well. ...which it doesn't. "A complete, cross-platform solution to record, convert and stream audio and video" is how the official website defines FFmpeg... Radio waves (outside the visibible spectrum) are neither audio nor video. [Gratuitous slander removed] > I am especially annoyed by the “it's too hard” naysayers Nobody said that it was too hard. The complexity argument was that DAB & DVB is much more complicated than AM and FM, which they indeed are by any reasonable objective metric, not that Michael wouldn't be able to implement them. > They do not realize they reveal more about their own skills than anybody > else. It only tells that they have (at least) a rudimentary understanding of radio waves to figure out that DAB or DVB are much more complex signals than FM or AM. Maybe among the general public that would be telling some. Among ffmpeg-devel, I think it really tells nothing because just about everybody here would know or be able to guess that much. > But the whole attitude who wants FFmpeg to be a Serious OpenSource TM > Project, who needs to make releases and worry above all about ABI > stability, is really the attitude who is killing all the fun in working > on FFmpeg. Michael, you or really anyone is more than welcome to fork and have their fun coding on FFmpeg *outside* the community project, if they cannot have it within the framework that is that community. Meanwhile, they are dozens of people, ostensibly including Michael himself, that depend on FFmpeg being "Serious OpenSource TM" in some way, for their livelihood, and millions for their computer use. You don't get to ruin that, and if you try, you will first be blocked by the TC, and if you try harder, you will be kicked by the CC. It looks to me that some people need to learn that not every piece of code they write or intend to write belongs in upstream FFmpeg. > Hey, people, realize FFmpeg does not exist to be a Serious OpenSource TM > Project, FFmpeg does not exist to serve other projects, to serve > companies who benefit from it give the bare minimum back. It also does not exist to be your playground, especially not at the expense of other people. And it has certainly not evolved that way for the past 20 or so years. > FFmpeg exists because some day a dude thought it would be fun to write a > MPEG decoder. > And everybody else told him it would be too hard, > everybody else told him to use an existing library and to leave it to > the professionals. He did not believe them and proved them utterly > wrong, and the rest, as the saying goes, is history. And? That is completely irrelevant to the question whether (and if so how) SDR should be integrated in FFmpeg. > So I will say it explicitly. We — me, and everybody who agrees with me — > do not want to just maintain a bunch of wrappers for the convenience of > others, we want to have fun writing interesting code, trying new ways of > doing things, inventing original optimizations. We can find a balance > and work on useful things too. But if you want us to work only on the > boring useful things, if you want to bar us from working on fun things, > then just fork you. To paraphrase you, the fact that you can throw such an argument with a straight face tells a lot. So what if, for the sake of the argument, people's subjective notion of discretionary fun is writing FFmpeg code in a project that excludes you? This is tiring, I'll leave it at that. -- レミ・デニ-クールモン http://www.remlab.net/
Re: [FFmpeg-devel] [PATCH] libsvtav1: Add workaround for gop_size == 1
Hi Vignesh, On Tue, Jun 27, 2023 at 1:55 PM Vignesh Venkat < vigneshv-at-google@ffmpeg.org> wrote: > > >>> In some versions of libsvtav1, setting intra_period_length to 0 > [..] > > >>> SVT-AV1 Bug: https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 > > >>> > > >>> Example command: ffmpeg -f lavfi -i > testsrc=duration=1:size=64x64:rate=30 -c:v libsvtav1 -g 1 -y test.webm > > >>> > > >>> Before: Only first frame is keyframe. > > >>> After: All frames are keyframes. > [..] > From what i tested, it seems to be there on the tip of tree SVT-AV1 as > well. So we can't guard it with macros until the issue is fixed. > Isn't this the expected behaviour, btw? See https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md "Keyint --keyint [-2-(2^31)-1] -2 GOP size (frames), use s suffix for seconds (SvtAv1EncApp only) [-2: ~5 seconds, -1: "infinite" only for CRF, 0: == -1] " note the final parts: 0=-1, and -1 means "infinite" keyint (i.e. never insert a new KF). Since FFmpeg's wrapper sets keyint to "gopsize value minus 1", "-g 1" seems to become equivalent to "--keyint 0" on the SVT-AV1 commandline, unless there's some discrepancy between API and CLI interface. (I admit that if I set it to 1, I don't actually get keyframes, but rather intraonly frames for all except the first frame. --keyint 2 correctly uses key - inter pairs. But your "before" statement above appeared to suggest that the first keyframe is followed by inter frames, not intraonly frames. If you meant "intraonly after key" instead of "inter after key", you should probably note that more explicitly. This may also help upstream reproduce in #2076 so they can fix it going forward.) Ronald ___ 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".
Re: [FFmpeg-devel] [PATCH] libsvtav1: Add workaround for gop_size == 1
On Mon, Jun 26, 2023 at 4:53 PM James Almer wrote: > > On 6/26/2023 7:32 PM, Vignesh Venkat wrote: > > On Mon, Jun 26, 2023 at 3:17 PM Ronald S. Bultje wrote: > >> > >> Hi, > >> > >> On Mon, Jun 26, 2023 at 1:47 PM Vignesh Venkatasubramanian > >> wrote: > >>> > >>> In some versions of libsvtav1, setting intra_period_length to 0 > >>> does not produce the intended result (i.e.) all frames produced > >>> are not keyframes. > >>> > >>> Instead handle the gop_size == 1 as a special case by setting > >>> the pic_type to EB_AV1_KEY_PICTURE when encoding each frame so > >>> that all the output frames are keyframes. > >>> > >>> SVT-AV1 Bug: https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 > >>> > >>> Example command: ffmpeg -f lavfi -i testsrc=duration=1:size=64x64:rate=30 > >>> -c:v libsvtav1 -g 1 -y test.webm > >>> > >>> Before: Only first frame is keyframe. > >>> After: All frames are keyframes. > >>> > >>> Signed-off-by: Vignesh Venkatasubramanian > >>> --- > >>> libavcodec/libsvtav1.c | 16 +++- > >>> 1 file changed, 15 insertions(+), 1 deletion(-) > >> > >> > >> It feels a bit dirty to add workarounds in ffmpeg library wrappers for > >> bugs in these libraries. Not 100% against it, but it's not particularly > >> great. > >> > > > > Yeah I agree that it's not ideal. But minor changes like this that are > > commented/documented is okay i believe. > > What are the buggy svt-av1 versions? Can this be wrapped in a > preprocessor check, so that if we bump the minimum required version in > the future and it's newer, this change can be removed/undone? > From what i tested, it seems to be there on the tip of tree SVT-AV1 as well. So we can't guard it with macros until the issue is fixed. ___ > 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". -- Vignesh ___ 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".
Re: [FFmpeg-devel] [PATCH] enable 'dvh1' FourCC in MP4
On Tuesday, 27 June 2023 at 19:23, Dominik 'Rathann' Mierzejewski wrote: > Hi! > I'm forwarding this patch from HandBrake. Original author is > Damiano Galassi (galad87@github). > > Apparently, this is required to pass through Dolby Vision metadata > to x265. Author's comment says: 'Profile 5 seems to require the "dvh1" > fourcc.' See https://github.com/HandBrake/HandBrake/pull/4838 for more > details. It looks like this might fix https://trac.ffmpeg.org/ticket/10257 . Regards, Dominik -- Fedora https://fedoraproject.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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".
[FFmpeg-devel] [PATCH] enable 'dvh1' FourCC in MP4
Hi!
I'm forwarding this patch from HandBrake. Original author is
Damiano Galassi (galad87@github).
Apparently, this is required to pass through Dolby Vision metadata
to x265. Author's comment says: 'Profile 5 seems to require the "dvh1"
fourcc.' See https://github.com/HandBrake/HandBrake/pull/4838 for more
details.
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 5608afd..f46df18 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7689,6 +7689,7 @@ static const AVCodecTag codec_mp4_tags[] = {
{ AV_CODEC_ID_H264,MKTAG('a', 'v', 'c', '3') },
{ AV_CODEC_ID_HEVC,MKTAG('h', 'e', 'v', '1') },
{ AV_CODEC_ID_HEVC,MKTAG('h', 'v', 'c', '1') },
+{ AV_CODEC_ID_HEVC,MKTAG('d', 'v', 'h', '1') },
{ AV_CODEC_ID_MPEG2VIDEO, MKTAG('m', 'p', '4', 'v') },
{ AV_CODEC_ID_MPEG1VIDEO, MKTAG('m', 'p', '4', 'v') },
{ AV_CODEC_ID_MJPEG, MKTAG('m', 'p', '4', 'v') },
Regards,
Dominik
--
Fedora https://fedoraproject.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
Tomas Härdin (12023-06-27): > I propose we add the ability for ffmpeg to send email. After all some > users might find that useful. And because many users use webmail we > should also implement HTML parsing. If you like to work on it and manage to produce something that integrates elegantly in the framework, then by all means, go ahead. Please, do it. -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
tis 2023-06-27 klockan 12:57 +0200 skrev Nicolas George: > Tomas Härdin (12023-06-27): > > Yes those are all fine use cases. But that doesn't explain why they > > belong in FFmpeg rather than say a driver that turns generic SDRs > > into > > V4L FM devices, or a dedicated GUI application. > > They can be implemented in any of these pieces of software, including > FFmpeg, and each solution will have its own set of benefits and > drawbacks in terms of performance, features, user interaction, etc. > > In other words, a simple point of logic: X can Y does not imply X > cannot > Z for all Z not equal to Y. I propose we add the ability for ffmpeg to send email. After all some users might find that useful. And because many users use webmail we should also implement HTML parsing. /Tomas ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/packet: add a define for the max buffer size a packet can hold
On 6/27/2023 4:23 AM, Anton Khirnov wrote:
Quoting James Almer (2023-06-21 22:46:56)
Signed-off-by: James Almer
---
TODO: Version bump and APIchanges entry.
libavcodec/packet.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index f28e7e7011..f7dd687c23 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -418,6 +418,11 @@ typedef struct AVPacket {
AVRational time_base;
} AVPacket;
+/**
+ * Max size for an AVPacket data buffer.
+ */
+#define AV_PKT_MAX_PAYLOAD_SIZE ((size_t)(INT_MAX -
AV_INPUT_BUFFER_PADDING_SIZE))
Maybe just AV_PKT_SIZE_MAX to be consistent with other FOO_MAX in C?
Otherwise the set seems like a good idea.
Will apply with that change then. Thanks.
___
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".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
Tomas Härdin (12023-06-27): > Yes those are all fine use cases. But that doesn't explain why they > belong in FFmpeg rather than say a driver that turns generic SDRs into > V4L FM devices, or a dedicated GUI application. They can be implemented in any of these pieces of software, including FFmpeg, and each solution will have its own set of benefits and drawbacks in terms of performance, features, user interaction, etc. In other words, a simple point of logic: X can Y does not imply X cannot Z for all Z not equal to Y. -- Nicolas George ___ 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".
Re: [FFmpeg-devel] [WIP] [PATCH v5 0/1] add Software Defined Radio support
On Tue, Jun 27, 2023 at 02:16:50PM +1000, Peter Ross wrote: > On Tue, Jun 27, 2023 at 01:53:01AM +0200, Michael Niedermayer wrote: > > Changes since v4: > > * vissualization shows modulation and frequency > > * limit station search to AM shortwave and FM broadcast band > > * enable FM Probing with some minor adjustments, it seems good enough > > * FM Mono demodulation > > fantastic work! > > is the fm demodulator supposed to work automagically? > i don't seem to discover anything with this command: > > ffplay -sdr_freq 105.5M -station_freq 107.5M -f sdr foo I used this: ./ffplay -sdr_freq 89M -f sdr abc -video_size 1600x600 (that was with a rtlsdr blog v3) should be all automatic except right and left arrow keys to switch stations but iam sure there are bugs This also needs these patches that are unchanged from my previous submission: commit feecac41f63a951b151c95a476d9c3ae17af6f48 Author: Michael Niedermayer Date: Fri Jun 16 19:22:49 2023 +0200 avcodec: Rename ff_kbd_window_init() as it will be needed from outside libavcodec commit 9780472946a34bb67eeb4c5aa8acc627e9e6bf68 Author: Michael Niedermayer Date: Wed Jun 14 17:22:55 2023 +0200 avcodec/kbdwin: Support arbitrary sized windows Signed-off-by: Michael Niedermayer commit fa7d5f46f6b7cdafef0dc2d57bb8480ae67778be Author: Michael Niedermayer Date: Mon Jun 5 15:56:58 2023 +0200 avcodec/pcm: allow Changing parameters SDR needs this for switching between mono and stereo stations Signed-off-by: Michael Niedermayer commit 2ec856e06b3fda5aff6005439415e5ad0d691f66 Author: Michael Niedermayer Date: Tue May 30 02:59:11 2023 +0200 avutil/tx_template: extend to 2M Signed-off-by: Michael Niedermayer thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 1/5] avcodec/evc_frame_merge: ensure the assembled buffer fits in an AVPacket
Hi James, I would like to thank you for the thorough review and merging of the majority of the 10-patchset into the FFmpeg master branch. Your personal dedication to making numerous valuable and impactful improvements to the code has been remarkable. I am really grateful for your work and your time devoted to merging the EVC implementation into FFmpeg master branch. While the progress made so far has been significant, there are still two remaining patches. I mean the implementation of wrappers for the EVC encoder and decoder. I wanted to inquire about merging these two patches into the master branch. We are looking forward to seeing the complete integration of these essential components. Furthermore, I wanted to ask if there is anything we can do to facilitate the integration of our patchset with the FFmpeg project. Whether it involves providing additional changes, conducting further testing, or assisting in the code review process, we are more than willing to collaborate and contribute in any way we can. Let us know what we can do to enhance the overall integration process. Once again, I would like to express my deep appreciation for your invaluable contributions, thorough review, and the multitude of changes you have made to the code. Thank you for your time, contribution, and consideration. I look forward to your response. Kind regards Dawid > -Original Message- > From: ffmpeg-devel On Behalf Of James > Almer > Sent: piątek, 23 czerwca 2023 13:43 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 1/5] avcodec/evc_frame_merge: ensure > the assembled buffer fits in an AVPacket > > On 6/22/2023 4:29 PM, James Almer wrote: > > Signed-off-by: James Almer > > --- > > libavcodec/evc_frame_merge_bsf.c | 12 ++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > Will apply set. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://protect2.fireeye.com/v1/url?k=322c563f-53a74374-322ddd70- > 74fe485fb305-d0a347f67d0a53df=1=5018ca25-0c81-4d7a-8598- > 9876a225f78c=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp > eg-devel > > To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org > with subject "unsubscribe". ___ 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".
Re: [FFmpeg-devel] [PATCH v2] avformat: add Software Defined Radio support
sön 2023-06-25 klockan 11:54 +0200 skrev Michael Niedermayer: > On Sun, Jun 25, 2023 at 12:01:07AM +0200, Tomas Härdin wrote: > > lör 2023-06-24 klockan 23:01 +0200 skrev Michael Niedermayer: > > > On Sat, Jun 24, 2023 at 11:51:57AM +0200, Tomas Härdin wrote: > > > > fre 2023-06-23 klockan 23:18 +0200 skrev Michael Niedermayer: > > > > > > > > > > Are you planing to add SDR support through some library like > > > > > GNU > > > > > radio > > > > > to FFmpeg ? > > > > > > > > This is begging the question. I don't care what you think is > > > > fun, > > > > this > > > > is outside the scope of the project. Not everything needs to be > > > > shoveled into FFmpeg master. The UNIX pipe was invented for a > > > > reason. > > > > Use radio tools to do radio stuff, then pipe the resulting > > > > bitstream or > > > > audio stream into FFmpeg if you need to say transcode DAB to > > > > Opus > > > > for > > > > streaming on the Web or something. > > > > > > We will have to agree to disagree here. > > > all other sources of audio and video work conveniently in FFmpeg > > > I can also play a video and switch subtitle and audio streams > > > with a > > > button not have to use a external demultiplxer and choose the > > > streams > > > before starting the player. > > > > If you want to listen to AM broadcasts then there are already > > plenty of > > programs to do that. If you want to skim the bands for interesting > > broadcasts there are tools for that as well. Have you even done > > basic > > research to see what is out there? > > Ive looked a bit, i found CubicSDR and SDR++ i like these tools they > are cool. But they dont seem to do many demodulations, just analog > also they are very manual which is cool sure but what iam missing > is a "iphone" like experience. Something with 2 buttons > > as in next station, previous station, hold one to record, hold both > to record everything, double click to switch between audio and viddeo > ;) > not exacty like that of course but the idea of simple convenient and > 99.99% working, no tool i saw or heared of does this. > > you know, not i have to select the frequency i have to select the > demodulation > i have to figure out what the song name is. Something when i hear a > song i like > i press record and it figures out what song this is (RDS has the > info) > figures out when the song started and goes back in some cache and > stores > that from the past > Thats one use case like i said. Theres surely a lot more. like > dumping everything > from the whole DAB or FM band into a properly sorted "mp3/aac" > library Yes those are all fine use cases. But that doesn't explain why they belong in FFmpeg rather than say a driver that turns generic SDRs into V4L FM devices, or a dedicated GUI application. The latter would be a fine project on its own, and having it exec() ffmpeg for recording would no doubt also be useful. But it seems that you've decided beforehand that ffmpeg should do this. Why I do not know. gqrx can do some of what you describe, including displaying your SDR's input bandwidth in a waterfall. I wouldn't be surprised if there are more novice friendly programs. > > > > > somehow you swing between extreems here > > > first its pipes or nothing now we need FPGAs > > > > Yeah because different applications call for different tools. You > > cannot do RADAR or WiFi on the CPU. > > we are drifting off topic. But "You cannot do" triggers me a bit > reminds be of "you cannot break videocrypt without FFTs on FPGAs" > I did that on the CPU of my average desktop in 1997 > https://guru.multimedia.cx/index.php?s=videocrypt > > so now we cannot do RADAR on the CPU ? > why exactly would that be so ? > RADAR is not one thing btw, theres alot of different RADAR systems > some i do belive worked with vaccuum tubes i do guess you dont > mean these > > with wifi theres also different iterations. I guess as bandwidth > increases we need more processing Processing isn't the issue, latency is. But yes it is a bit off-topic, sorry. > > > I think we somehow are not talking on the same frequency ;) > > > if i want just AM/FM i need 10 pages of code max and writing > > > these > > > pages is a fun thing to do for me. > > > > Fun for you is technical debt for everyone else. > > how is a self contained module affecting anyone excpet who works on > it? Because radio begets its own requirements as far as DSP and other tooling is concerned, which will inevitably spill over into other parts of the project. Just one example is that sample rates are no longer within the range of human hearing, but could range in the GHz, thus causing all kinds of fun problems as sample_rate approaches INT_MAX. > > > autodetecting modulations and demodulating the selected station. > > > > lol > > whats funny ? I would suggest reading https://www.sigidwiki.com/wiki/Signal_Identification_Guide and then come back to me what the prospects of automatically identifying transmissions are. > > > 2.
Re: [FFmpeg-devel] [PATCH v24 6/9] avformat/mov_muxer: Extended MOV muxer to handle EVC video content
James Almer 于2023年6月19日周一 10:43写道： > On 6/18/2023 11:27 PM, Wang Bin wrote: > > - Changes in mov_write_video_tag function to handle EVC elementary stream > >> - Provided structure EVCDecoderConfigurationRecord that specifies the > >> decoder configuration information for ISO/IEC 23094-1 video content > >> > >> Signed-off-by: Dawid Kozinski > >> --- > >> libavformat/Makefile| 2 +- > >> libavformat/evc.c | 422 > >> libavformat/evc.h | 44 + > >> libavformat/isom_tags.c | 2 + > >> libavformat/movenc.c| 33 > >> 5 files changed, 502 insertions(+), 1 deletion(-) > >> create mode 100644 libavformat/evc.c > >> create mode 100644 libavformat/evc.h > >> > >> diff --git a/libavformat/Makefile b/libavformat/Makefile > >> index 6e4231fda2..d3503196e3 100644 > >> --- a/libavformat/Makefile > >> +++ b/libavformat/Makefile > >> @@ -364,7 +364,7 @@ OBJS-$(CONFIG_MOV_DEMUXER) += mov.o > >> mov_chan.o mov_esds.o \ > >> OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o > hevc.o > >> vpcc.o \ > >> movenchint.o mov_chan.o > rtp.o > >> \ > >> movenccenc.o movenc_ttml.o > >> rawutils.o \ > >> -dovi_isom.o > >> +dovi_isom.o evc.o > >> OBJS-$(CONFIG_MP2_MUXER) += rawenc.o > >> OBJS-$(CONFIG_MP3_DEMUXER) += mp3dec.o replaygain.o > >> OBJS-$(CONFIG_MP3_MUXER) += mp3enc.o rawenc.o > id3v2enc.o > >> > > > > This breaks msvc build. golomb_tab.o is required in > > OBJS-$(CONFIG_MOV_MUXER). otherwise i get this error > > > > 2023-06-18T12:48:08.5213414Z LD libavformat/avformat-60.dll > > 2023-06-18T12:48:08.6503045Z LINK : warning LNK4044: unrecognized > > option '/-icf=safe'; ignored > > 2023-06-18T12:48:08.8081443ZCreating library > > libavformat/avformat.lib and object libavformat/avformat.exp > > 2023-06-18T12:48:08.8219530Z evc.o : error LNK2001: unresolved > > external symbol ff_golomb_vlc_len > > 2023-06-18T12:48:08.8267361Z evc.o : error LNK2001: unresolved > > external symbol ff_ue_golomb_vlc_code > > 2023-06-18T12:48:09.0122434Z libavformat\avformat-60.dll : fatal error > > LNK1120: 2 unresolved externals > > 2023-06-18T12:48:09.0517997Z make: *** > > [/d/a/avbuild/avbuild/ffmpeg-***/ffbuild/library.mak:119: > > libavformat/avformat-60.dll] Error 96 > > > > > > full build log: > > > https://github.com/wang-bin/avbuild/actions/runs/5303646918/jobs/9599433665 > > Should be fixed. > broken again, in commit d0fc1b3. why not adding golomb_tab.o in makefile? 2023-06-27T02:21:02.4793190Z Undefined symbols for architecture x86_64: 2023-06-27T02:21:02.4793570Z "_ff_golomb_vlc_len", referenced from: 2023-06-27T02:21:02.4793850Z _get_ue_golomb_31 in evc.o 2023-06-27T02:21:02.4822020Z "_ff_ue_golomb_vlc_code", referenced from: 2023-06-27T02:21:02.4822390Z _get_ue_golomb_31 in evc.o 2023-06-27T02:21:02.4849070Z ld: symbol(s) not found for architecture x86_64 Regards ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/packet: add a define for the max buffer size a packet can hold
Quoting James Almer (2023-06-21 22:46:56)
> Signed-off-by: James Almer
> ---
> TODO: Version bump and APIchanges entry.
>
> libavcodec/packet.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/packet.h b/libavcodec/packet.h
> index f28e7e7011..f7dd687c23 100644
> --- a/libavcodec/packet.h
> +++ b/libavcodec/packet.h
> @@ -418,6 +418,11 @@ typedef struct AVPacket {
> AVRational time_base;
> } AVPacket;
>
> +/**
> + * Max size for an AVPacket data buffer.
> + */
> +#define AV_PKT_MAX_PAYLOAD_SIZE ((size_t)(INT_MAX -
> AV_INPUT_BUFFER_PADDING_SIZE))
Maybe just AV_PKT_SIZE_MAX to be consistent with other FOO_MAX in C?
Otherwise the set seems like a good idea.
--
Anton Khirnov
___
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".
