[FFmpeg-devel] [PATCH v2 1/1] avcodec, avformat/ffjni: fix duplicate JNI symbols
Use SHLIBOBJS and STLIBOBJS in the Makefiles for avcodec and avformat,
and add a stub ffjni.c to libavformat, which allows the symbols to be
duplicated for shared builds but not static builds.
Signed-off-by: Leo Izen
---
libavcodec/Makefile | 1 +
libavformat/Makefile | 1 +
libavformat/ffjni.c | 23 +++
libavformat/file.c | 2 +-
4 files changed, 26 insertions(+), 1 deletion(-)
create mode 100644 libavformat/ffjni.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 9ce6d445c1..113adb22d5 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1068,6 +1068,7 @@ STLIBOBJS-$(CONFIG_ISO_MEDIA) += mpegaudiotabs.o
STLIBOBJS-$(CONFIG_FLV_MUXER) += mpeg4audio_sample_rates.o
STLIBOBJS-$(CONFIG_HLS_DEMUXER)+= ac3_channel_layout_tab.o
STLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER) += jpegxl_parse.o
+STLIBOBJS-$(CONFIG_JNI)+= ffjni.o
STLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER) += jpegxl_parse.o
STLIBOBJS-$(CONFIG_MATROSKA_DEMUXER) += mpeg4audio_sample_rates.o
STLIBOBJS-$(CONFIG_MOV_DEMUXER)+= ac3_channel_layout_tab.o
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 44aa485029..a89df7e9a3 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -728,6 +728,7 @@ SHLIBOBJS-$(CONFIG_ISO_MEDIA)+= mpegaudiotabs.o
SHLIBOBJS-$(CONFIG_FLV_MUXER)+= mpeg4audio_sample_rates.o
SHLIBOBJS-$(CONFIG_HLS_DEMUXER) += ac3_channel_layout_tab.o
SHLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER)+= jpegxl_parse.o
+SHLIBOBJS-$(CONFIG_JNI) += ffjni.o
SHLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER) += jpegxl_parse.o
SHLIBOBJS-$(CONFIG_MATROSKA_DEMUXER) += mpeg4audio_sample_rates.o
SHLIBOBJS-$(CONFIG_MOV_DEMUXER) += ac3_channel_layout_tab.o
diff --git a/libavformat/ffjni.c b/libavformat/ffjni.c
new file mode 100644
index 00..2b1483cf42
--- /dev/null
+++ b/libavformat/ffjni.c
@@ -0,0 +1,23 @@
+/*
+ * JNI utility functions - included stub
+ *
+ * Copyright (c) 2024 Leo Izen
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavcodec/ffjni.c"
diff --git a/libavformat/file.c b/libavformat/file.c
index 182995717a..1f853e0e17 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -527,8 +527,8 @@ const URLProtocol ff_fd_protocol = {
#if CONFIG_ANDROID_CONTENT_PROTOCOL
#include
+#include "libavcodec/ffjni.h"
#include "libavcodec/jni.h"
-#include "libavcodec/ffjni.c"
typedef struct JFields {
jclass uri_class;
--
2.44.0
___
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 v2 0/1] avcodec, avformat/ffjni: fix duplicate JNI symbols
Changes since v1: - Rebased onto master I was unable to credit the original reporter with a Reported-by because the name used Chinese characters (and it translated to 'admin'). Leo Izen (1): avcodec,avformat/ffjni: fix duplicate JNI symbols libavcodec/Makefile | 1 + libavformat/Makefile | 1 + libavformat/ffjni.c | 23 +++ libavformat/file.c | 2 +- 4 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 libavformat/ffjni.c -- 2.44.0 ___ 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] doc: Add libtoch backend option to dnn_processing
On 3/25/24 07:16, Guo, Yejun wrote: -Original Message- From: ffmpeg-devel On Behalf Of wenbin.chen-at-intel@ffmpeg.org Sent: Monday, March 25, 2024 10:15 AM To: ffmpeg-devel@ffmpeg.org Subject: [FFmpeg-devel] [PATCH v2] doc: Add libtoch backend option to dnn_processing Typo in commit message, you want libtorch, not libtoch. - Leo Izen (Traneptora) ___ 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] avformat/dvdvideodec: add explicit inttypes.h include
On 3/23/24 22:24, Marth64 wrote: Since log statements printing int64 were made portable in 4464b7eeb194e98ac115f18d2b6be67361407c8a, let us include inttypes.h explicitly (as it is unclear where PRId64 and such are coming from now). Reported-by: Traneptora Signed-off-by: Marth64 --- libavformat/dvdvideodec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c index 761ac97ec6..959b267e69 100644 --- a/libavformat/dvdvideodec.c +++ b/libavformat/dvdvideodec.c @@ -30,6 +30,7 @@ * 7) Close the dvdnav VM, and free dvdread's IFO structures */ +#include #include #include #include I would add a space between the inttypes.h include and the dvdread include because inttypes is a standard C library and the others are an external library. If you don't want to do this you'll have to put it afterward in order to alphabetize it. - Leo Izen (Traneptora) ___ 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 2/2] avutil/film_grain_params: remove do loop in CHECK macro
The continue statement will break out of the do/while loop, not the
outer loop as intended. This is one (compound) statement anyway, so we
can remove the do/while entirely.
Signed-off-by: Leo Izen
---
libavutil/film_grain_params.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavutil/film_grain_params.c b/libavutil/film_grain_params.c
index b3fa37f527..8f8dcee569 100644
--- a/libavutil/film_grain_params.c
+++ b/libavutil/film_grain_params.c
@@ -70,10 +70,8 @@ const AVFilmGrainParams *av_film_grain_params_select(const
AVFrame *frame)
continue;
#define CHECK(a, b, unspec) \
-do {\
if ((a) != (unspec) && (b) != (unspec) && (a) != (b)) \
-continue; \
-} while (0)
+continue
CHECK(fgp->bit_depth_luma, bit_depth_luma, 0);
CHECK(fgp->bit_depth_chroma, bit_depth_chroma, 0);
--
2.44.0
___
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 1/2] avutil/film_grain_params: remove unused variables
These variables are never read from, so they trigger -Wunused-variables
Signed-off-by: Leo Izen
---
libavutil/film_grain_params.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavutil/film_grain_params.c b/libavutil/film_grain_params.c
index fff7252f2f..b3fa37f527 100644
--- a/libavutil/film_grain_params.c
+++ b/libavutil/film_grain_params.c
@@ -53,8 +53,6 @@ const AVFilmGrainParams *av_film_grain_params_select(const
AVFrame *frame)
{
const AVFilmGrainParams *fgp, *best = NULL;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
-const AVFilmGrainAOMParams *aom;
-const AVFilmGrainH274Params *h274;
int bit_depth_luma, bit_depth_chroma;
if (!desc)
return NULL;
@@ -88,7 +86,6 @@ const AVFilmGrainParams *av_film_grain_params_select(const
AVFrame *frame)
case AV_FILM_GRAIN_PARAMS_NONE:
continue;
case AV_FILM_GRAIN_PARAMS_AV1:
-aom = >codec.aom;
/* AOM FGS needs an exact match for the chroma resolution */
if (fgp->subsampling_x != desc->log2_chroma_w ||
fgp->subsampling_y != desc->log2_chroma_h)
--
2.44.0
___
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 0/2] Minor avutil/film_grain_params tweaks
A few minor tweaks to libavutil/film_grain_params.c. Leo Izen (2): avutil/film_grain_params: remove unused variables avutil/film_grain_params: remove do loop in CHECK macro libavutil/film_grain_params.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) -- 2.44.0 ___ 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] avformat/jpegxl_anim_dec: set pos for generic index
avpkt->pos needs to be set for generic indexing or features such as the stream_loop option will not work. Co-authored-by: Andreas Rheinhardt Signed-off-by: Leo Izen --- libavformat/jpegxl_anim_dec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/jpegxl_anim_dec.c b/libavformat/jpegxl_anim_dec.c index f749b378b3..78dc16017d 100644 --- a/libavformat/jpegxl_anim_dec.c +++ b/libavformat/jpegxl_anim_dec.c @@ -171,6 +171,8 @@ static int jpegxl_anim_read_packet(AVFormatContext *s, AVPacket *pkt) av_buffer_unref(>initial); } +pkt->pos = avio_tell(pb) - offset; + ret = avio_read(pb, pkt->data + offset, size - offset); if (ret < 0) return ret; -- 2.44.0 ___ 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/ccaption_dec: don't print multiple \pos tags per cue
On 3/11/24 17:48, Marth64 wrote: This breaks fate Looking into it - thanks. It is possible that the change is correct, and that the fate test needs to be changed to reflect the correct behavior. Not necessarily, but possibly. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital 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] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On 3/9/24 20:25, Michael Niedermayer wrote: Hi everyone Some members of the CC want to indefinitely ban Balling from trac. And as our doc/community.texi says: "Indefinite bans from the community must be confirmed by the General Assembly, in a majority vote." Thus some CC member wishes to involve the public here (really theres no other option, the GA cannot discuss/vote on what it doesnt know) Also people have asked for more transparency and i strongly agree with transparency. As reference, and to make it possible for the community to discuss this easily without too much google searching. Ive attached the list of all changes in trac done by Balling. I do not and never did support permanently banning contributors. In summary: since 2019 842 comment0' changed 389 comment1' changed 176 comment2' changed 87 comment3' changed 49 comment4' changed 24 comment5' changed 12 comment6' changed 6 comment7' changed 4 comment8' changed 3 comment9' changed 2194 comment' changed 10 component' changed 12 description' changed 29 keywords' changed 37 owner' changed 8 priority' changed 7 reproduced' changed 291 resolution' changed 537 status' changed 32 summary' changed 2 type' changed 11 version' changed If these are supposed to be ticket numbers on the left, I checked the first two and neither have comments from Balling. If these are summaries/counts on the left, could you please elaborate on how you generated this data? I'm not super familiar with the trac user interface, but iirc you can embed the search in a query string. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital 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 3/3] avformat/dvdvideodec: add menu demuxing support
On 3/9/24 13:27, Marth64 wrote:
Signed-off-by: Marth64
---
doc/demuxers.texi | 43 +-
libavformat/dvdvideodec.c | 314 --
2 files changed, 339 insertions(+), 18 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index f4bac8f3b3..b70f3a38d7 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -289,8 +289,10 @@ This demuxer accepts the following option:
DVD-Video demuxer, powered by libdvdnav and libdvdread.
-Can directly ingest DVD titles, specifically sequential PGCs,
-into a conversion pipeline. Menus and seeking are not supported at this time.
+Can directly ingest DVD titles, specifically sequential PGCs, into
+a conversion pipeline. Menu assets, such as background video or audio,
+can also be demuxed given the menu's coordinates (at best effort).
+Seeking is not supported at this time.
Block devices (DVD drives), ISO files, and directory structures are accepted.
Activate with @code{-f dvdvideo} in front of one of these inputs.
@@ -347,37 +349,56 @@ This demuxer accepts the following options:
@item title @var{int}
The title number to play. Must be set if @option{pgc} and @option{pg} are not
set.
+Not applicable to menus.
Default is 0 (auto), which currently only selects the first available title
(title 1)
and notifies the user about the implications.
@item chapter_start @var{int}
-The chapter, or PTT (part-of-title), number to start at. Default is 1.
+The chapter, or PTT (part-of-title), number to start at. Not applicable to
menus.
+Default is 1.
@item chapter_end @var{int}
-The chapter, or PTT (part-of-title), number to end at. Default is 0,
-which is a special value to signal end at the last possible chapter.
+The chapter, or PTT (part-of-title), number to end at. Not applicable to menus.
+Default is 0, which is a special value to signal end at the last possible
chapter.
@item angle @var{int}
The video angle number, referring to what is essentially an additional
video stream that is composed from alternate frames interleaved in the VOBs.
+Not applicable to menus.
Default is 1.
@item region @var{int}
The region code to use for playback. Some discs may use this to default
playback
at a particular angle in different regions. This option will not affect the
region code
-of a real DVD drive, if used as an input. Default is 0, "world".
+of a real DVD drive, if used as an input. Not applicable to menus.
+Default is 0, "world".
+
+@item menu @var{bool}
+Demux menu assets instead of navigating a title. Requires exact coordinates
+of the menu (@option{menu_lu}, @option{menu_vts}, @option{pgc}, @option{pg}).
+Default is false.
+
+@item menu_lu @var{int}
+The menu language to demux. In DVD, menus are grouped by language.
+Default is 0, the first language unit.
+
+@item menu_vts @var{int}
+The VTS where the menu lives, or 0 if it is a VMG menu (root-level).
+Default is 0, VMG menu.
@item pgc @var{int}
The entry PGC to start playback, in conjunction with @option{pg}.
Alternative to setting @option{title}.
Chapter markers are not supported at this time.
+Must be explicitly set for menus.
Default is 0, automatically resolve from value of @option{title}.
@item pg @var{int}
The entry PG to start playback, in conjunction with @option{pgc}.
Alternative to setting @option{title}.
Chapter markers are not supported at this time.
-Default is 0, automatically resolve from value of @option{title}.
+Default is 0, automatically resolve from value of @option{title}, or
+start from the beginning (PG 1) of the menu.
@item preindex @var{bool}
Enable this to have accurate chapter (PTT) markers and duration measurement,
@@ -385,6 +406,7 @@ which requires a slow second pass read in order to index
the chapter marker
timestamps from NAV packets. This is non-ideal extra work for real optical
drives.
It is recommended and faster to use this option with a backup of the DVD
structure
stored on a hard drive. Not compatible with @option{pgc} and @option{pg}.
+Not applicable to menus.
Default is 0, false.
@item trim @var{bool}
@@ -392,6 +414,7 @@ Skip padding cells (i.e. cells shorter than 1 second) from
the beginning.
There exist many discs with filler segments at the beginning of the PGC,
often with junk data intended for controlling a real DVD player's
buffering speed and with no other material data value.
+Not applicable to menus.
Default is 1, true.
@end table
@@ -416,6 +439,12 @@ Open only chapter 5 from title 1 from a given DVD
structure:
@example
ffmpeg -f dvdvideo -chapter_start 5 -chapter_end 5 -title 1 -i
...
@end example
+
+@item
+Demux menu with language 1 from VTS 1, PGC 1, starting at PG 1:
+@example
+ffmpeg -f dvdvideo -menu 1 -menu_lu 1 -menu_vts 1 -pgc 1 -pg 1 -i ...
+@end example
@end itemize
@section ea
diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index 6f626ce9a0..a182f95097
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio
On 2/29/24 20:13, Michael Niedermayer wrote: Every codec we develop is experimental and used by nobody then by nobody outside ffmpeg and if we dont allow this then we can never create a new codec. FFv1 would not exist if we could not have added it at ta time noone used it. FFv1 would not have become widely used if it was in someones personal repository and main FFmpeg did not support it thx This is true, but also the code hasn't been touched in more than ten years, which makes it a bit different than, say, ffv1 which was actively developed for a while and still is. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital 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] Fixes #10509
On 3/9/24 15:49, Poorva wrote: I have attached the git patch containing the changes for your review. This patch is submitted as part of my qualification task for Google Summer of Code (GSoC) Your editor appears to have stripped the newline at the end of the file. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital 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 3/3] avcodec/pngenc: write eXIf chunks
On 2/14/24 13:53, Andreas Rheinhardt wrote:
Leo Izen:
Write EXIF metadata exposed AV_FRAME_DATA_EXIF as an eXIf chunk
to PNG files, if present.
Signed-off-by: Leo Izen
---
libavcodec/pngenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 50689cb50c..a302c879da 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -413,6 +413,10 @@ static int encode_headers(AVCodecContext *avctx, const
AVFrame *pict)
}
}
+side_data = av_frame_get_side_data(pict, AV_FRAME_DATA_EXIF);
+if (side_data)
+png_write_chunk(>bytestream, MKTAG('e', 'X', 'I', 'f'),
side_data->data, FFMIN(side_data->size, INT_MAX));
+
side_data = av_frame_get_side_data(pict, AV_FRAME_DATA_ICC_PROFILE);
if ((ret = png_write_iccp(s, side_data)))
return ret;
If I see this correctly, then these patches can lead to a situation
where an input packet has rotation metadata in exif which gets exported
twice -- as displaymatrix and as exif metadata side data. If the user
changes the displaymatrix (e.g. applies the transformation to the image
data and removes the displaymatrix side data before reencoding), the
exif data (that the user would probably not be aware of) would still be
there and get propagated into the output, corrupting it.
Hm. This is true, but it's also currently how the mjpeg decoder
functions (i.e. it attaches displaymatrix side data).
There are no encoders that currently save EXIF metadata, so there's no
precedent.
How do you suggest this be reconciled?
- Leo Izen (Traneptora)
OpenPGP_signature.asc
Description: OpenPGP digital 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".
[FFmpeg-devel] [PATCH 3/3] avcodec/pngenc: write eXIf chunks
Write EXIF metadata exposed AV_FRAME_DATA_EXIF as an eXIf chunk
to PNG files, if present.
Signed-off-by: Leo Izen
---
libavcodec/pngenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 50689cb50c..a302c879da 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -413,6 +413,10 @@ static int encode_headers(AVCodecContext *avctx, const
AVFrame *pict)
}
}
+side_data = av_frame_get_side_data(pict, AV_FRAME_DATA_EXIF);
+if (side_data)
+png_write_chunk(>bytestream, MKTAG('e', 'X', 'I', 'f'),
side_data->data, FFMIN(side_data->size, INT_MAX));
+
side_data = av_frame_get_side_data(pict, AV_FRAME_DATA_ICC_PROFILE);
if ((ret = png_write_iccp(s, side_data)))
return ret;
--
2.43.0
___
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 2/3] avcodec/pngdec: parse eXIf chunk
Add support to parse eXIf chunks using the new EXIF framework.
Signed-off-by: Leo Izen
---
libavcodec/pngdec.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 026da30c25..e7951d1802 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -38,6 +38,7 @@
#include "bytestream.h"
#include "codec_internal.h"
#include "decode.h"
+#include "exif_internal.h"
#include "apng.h"
#include "png.h"
#include "pngdsp.h"
@@ -123,6 +124,7 @@ typedef struct PNGDecContext {
int pass_row_size; /* decompress row size of the current pass */
int y;
FFZStream zstream;
+AVBufferRef *exif_data;
} PNGDecContext;
/* Mask to determine which pixels are valid in a pass */
@@ -652,6 +654,26 @@ static int decode_phys_chunk(AVCodecContext *avctx,
PNGDecContext *s,
return 0;
}
+static int decode_exif_chunk(AVCodecContext *avctx, PNGDecContext *s,
+ GetByteContext *gb)
+{
+if (!(s->hdr_state & PNG_IHDR)) {
+av_log(avctx, AV_LOG_ERROR, "eXIf before IHDR\n");
+return AVERROR_INVALIDDATA;
+}
+if (s->pic_state & PNG_IDAT) {
+av_log(avctx, AV_LOG_ERROR, "eXIf after IDAT\n");
+return AVERROR_INVALIDDATA;
+}
+av_buffer_unref(>exif_data);
+s->exif_data = av_buffer_alloc(bytestream2_get_bytes_left(gb));
+if (!s->exif_data)
+return AVERROR(ENOMEM);
+bytestream2_get_buffer(gb, s->exif_data->data, s->exif_data->size);
+
+return 0;
+}
+
/*
* This populates AVCodecContext fields so it must be called before
* ff_thread_finish_setup() to avoid a race condition with respect to the
@@ -890,6 +912,12 @@ static int decode_idat_chunk(AVCodecContext *avctx,
PNGDecContext *s,
p->flags |= AV_FRAME_FLAG_KEY;
p->flags |= AV_FRAME_FLAG_INTERLACED * !!s->interlace_type;
+if (s->exif_data) {
+ret = ff_exif_attach(avctx, p, >exif_data);
+if (ret < 0)
+return ret;
+}
+
if ((ret = populate_avctx_color_fields(avctx, p)) < 0)
return ret;
ff_thread_finish_setup(avctx);
@@ -1571,6 +1599,12 @@ static int decode_frame_common(AVCodecContext *avctx,
PNGDecContext *s,
s->mdvc_max_lum = bytestream2_get_be32u(_chunk);
s->mdvc_min_lum = bytestream2_get_be32u(_chunk);
break;
+case MKTAG('e', 'X', 'I', 'f'): {
+ret = decode_exif_chunk(avctx, s, _chunk);
+if (ret < 0)
+goto fail;
+break;
+}
case MKTAG('I', 'E', 'N', 'D'):
if (!(s->pic_state & PNG_ALLIMAGE))
av_log(avctx, AV_LOG_ERROR, "IEND without all image\n");
@@ -1907,6 +1941,7 @@ static av_cold int png_dec_end(AVCodecContext *avctx)
s->tmp_row_size = 0;
av_freep(>iccp_data);
+av_buffer_unref(>exif_data);
av_dict_free(>frame_metadata);
ff_inflate_end(>zstream);
--
2.43.0
___
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 1/3] various: change EXIF metadata into AVFrameSideData
This patch centralizes much of the EXIF parsing and handling code for
libavcodec, and delegates its own AVFrameSideData type to containing
the buffer that holds EXIF metadata. This patch also adds exposes the
exif parsing routing so it can be called by ffprobe, and updates the
corresponding FATE tests to read the keys from the side data instead of
from the main frame metadata.
This commit also removes an avpriv_ function in exif.h, exposing the
parsing functionality as a public API in the exported libavcodec/exif.h
header file. As such, this commit requires an ABI break and can only be
applied during a major version bump.
Signed-off-by: Leo Izen
---
fftools/ffprobe.c | 27 ++-
libavcodec/Makefile| 1 +
libavcodec/exif.c | 267 +++--
libavcodec/exif.h | 21 ++-
libavcodec/exif_internal.h | 41 +
libavcodec/mjpegdec.c | 96 ++-
libavcodec/mjpegdec.h | 2 +-
libavcodec/tiff.c | 19 +-
libavcodec/tiff.h | 1 +
libavcodec/webp.c | 38 ++--
libavformat/avidec.c | 4 +-
libavutil/frame.c | 1 +
libavutil/frame.h | 6 +
tests/ref/fate/exif-image-embedded | 5 +-
tests/ref/fate/exif-image-jpg | 91 +-
tests/ref/fate/exif-image-webp | 91 +-
16 files changed, 482 insertions(+), 229 deletions(-)
create mode 100644 libavcodec/exif_internal.h
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index aa1153e709..7c3cd4a0ee 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -32,6 +32,7 @@
#include "libavformat/avformat.h"
#include "libavformat/version.h"
#include "libavcodec/avcodec.h"
+#include "libavcodec/exif.h"
#include "libavcodec/version.h"
#include "libavutil/ambient_viewing_environment.h"
#include "libavutil/avassert.h"
@@ -1982,19 +1983,30 @@ static void writer_register_all(void)
memset( (ptr) + (cur_n), 0, ((new_n) - (cur_n)) * sizeof(*(ptr)) ); \
}
-static inline int show_tags(WriterContext *w, AVDictionary *tags, int
section_id)
+static inline int show_dict(WriterContext *w, const AVDictionary *tags)
{
const AVDictionaryEntry *tag = NULL;
int ret = 0;
-
if (!tags)
return 0;
-writer_print_section_header(w, NULL, section_id);
-
while ((tag = av_dict_iterate(tags, tag))) {
-if ((ret = print_str_validate(tag->key, tag->value)) < 0)
+ret = print_str_validate(tag->key, tag->value);
+if (ret < 0)
break;
}
+return ret;
+}
+
+static inline int show_tags(WriterContext *w, const AVDictionary *tags, int
section_id)
+{
+int ret;
+
+if (!tags)
+return 0;
+writer_print_section_header(w, NULL, section_id);
+
+ret = show_dict(w, tags);
+
writer_print_section_footer(w);
return ret;
@@ -2700,6 +2712,11 @@ static void print_frame_side_data(WriterContext *w,
print_dynamic_hdr_vivid(w, metadata);
} else if (sd->type == AV_FRAME_DATA_AMBIENT_VIEWING_ENVIRONMENT) {
print_ambient_viewing_environment(w, (const
AVAmbientViewingEnvironment *)sd->data);
+} else if (sd->type == AV_FRAME_DATA_EXIF) {
+AVDictionary *dict = NULL;
+int ret = av_exif_parse_buffer(NULL, sd->data, sd->size, ,
AV_EXIF_PARSE_TIFF_HEADER);
+if (ret >= 0)
+show_dict(w, dict);
}
writer_print_section_footer(w);
}
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 470d7cb9b1..fea2f9b8b3 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -16,6 +16,7 @@ HEADERS = ac3_parser.h
\
dirac.h \
dv_profile.h \
dxva2.h \
+ exif.h\
jni.h \
mediacodec.h \
packet.h \
diff --git a/libavcodec/exif.c b/libavcodec/exif.c
index 959d114d09..0b7ad1c07c 100644
--- a/libavcodec/exif.c
+++ b/libavcodec/exif.c
@@ -1,6 +1,7 @@
/*
* EXIF metadata parser
* Copyright (c) 2013 Thilo Borgmann
+ * Copyright (c) 2024 Leo Izen
*
* This file is part of FFmpeg.
*
@@ -23,9 +24,12 @@
* @file
* EXIF metadata parser
* @author Thilo Borgmann
+ * @author Leo Izen
*/
-#include "exif.h"
+#include "libavutil/display.h"
+
+#include "exif_internal.h"
#include "tiff_common.h"
#define EXIF_TAG_NAME_
[FFmpeg-devel] [PATCH 0/3] [RFC] EXIF overhaul
A few notes: - This includes an avpriv_ removal, so it won't be able to be merged until the ABI is bumped. Alternatively, I could add that avipriv_ back in as a wrapper around the actual API so it's not a blocker, and then we can remove it when the time comes to bump the ABI. - MakerNote inside TIFF files are not handled by this patch. I don't have any samples that lets me reliably special-case them based on manufacturer. MakerNote is, by spec, a binary blob, but in practice it's often a TIFF IFD, with arbitrary data before the IFD starts and arbitrary semantics on whether its IFD-offsets are relative to the start of the TIFF header or the start of the MakerNote. The lack of samples makes this hard to work around. See [1] for more details. Note that [1] links [2] but [2] is a deadlink. - We attach the EXIF buffer as-is from mjpeg, webp, or other files that treat it as a blob, but we still need to parse it in order to determine the display matrix orientation side data. If there's a better way to handle this, please suggest one. - AVFrameSideData must be flat, so we can't parse it and store an AVDictionary * pointer in its place, as convenient as that would be. [1] https://exiv2.org/makernote.html [2] http://www.exif.org/samples.html Leo Izen (3): various: change EXIF metadata into AVFrameSideData avcodec/pngdec: parse eXIf chunk avcodec/pngenc: write eXIf chunks fftools/ffprobe.c | 27 ++- libavcodec/Makefile| 1 + libavcodec/exif.c | 267 +++-- libavcodec/exif.h | 21 ++- libavcodec/exif_internal.h | 41 + libavcodec/mjpegdec.c | 96 ++- libavcodec/mjpegdec.h | 2 +- libavcodec/pngdec.c| 35 libavcodec/pngenc.c| 4 + libavcodec/tiff.c | 19 +- libavcodec/tiff.h | 1 + libavcodec/webp.c | 38 ++-- libavformat/avidec.c | 4 +- libavutil/frame.c | 1 + libavutil/frame.h | 6 + tests/ref/fate/exif-image-embedded | 5 +- tests/ref/fate/exif-image-jpg | 91 +- tests/ref/fate/exif-image-webp | 91 +- 18 files changed, 521 insertions(+), 229 deletions(-) create mode 100644 libavcodec/exif_internal.h -- 2.43.0 ___ 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 v2 1/1] avcodec/libjxlenc: add option to disable xyb encoding
Add an AVOption to the libjxl encoder wrapper, which exposes the flag
uses_original_profile in libjxl. For highly unusual ICC profiles where
the target needs to stay in the original space, this can be useful.
Signed-off-by: Leo Izen
---
libavcodec/libjxlenc.c | 5 -
libavcodec/version.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index 5f5f9751dc..3f2c74097d 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -52,6 +52,7 @@ typedef struct LibJxlEncodeContext {
int effort;
float distance;
int modular;
+int xyb;
uint8_t *buffer;
size_t buffer_size;
} LibJxlEncodeContext;
@@ -303,7 +304,7 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
av_log(avctx, AV_LOG_WARNING, "Unknown color range, assuming full
(pc)\n");
/* bitexact lossless requires there to be no XYB transform */
-info.uses_original_profile = ctx->distance == 0.0;
+info.uses_original_profile = ctx->distance == 0.0 || !ctx->xyb;
info.orientation = frame->linesize[0] >= 0 ? JXL_ORIENT_IDENTITY :
JXL_ORIENT_FLIP_VERTICAL;
if (JxlEncoderSetBasicInfo(ctx->encoder, ) != JXL_ENC_SUCCESS) {
@@ -474,6 +475,8 @@ static const AVOption libjxl_encode_options[] = {
{ "distance", "Maximum Butteraugli distance (quality setting, "
"lower = better, zero = lossless, default 1.0)",
OFFSET(distance), AV_OPT_TYPE_FLOAT, { .dbl = -1.0 }, -1.0, 15.0, VE },
{ "modular", "Force modular mode",
OFFSET(modular),AV_OPT_TYPE_INT,{ .i64 =0 },0, 1, VE },
+{ "xyb", "Use XYB-encoding for lossy images",
OFFSET(xyb),
+AV_OPT_TYPE_INT, { .i64 =1 },0, 1, VE },
{ NULL },
};
diff --git a/libavcodec/version.h b/libavcodec/version.h
index f2f14eaed1..ecdbc51c74 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -30,7 +30,7 @@
#include "version_major.h"
#define LIBAVCODEC_VERSION_MINOR 39
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.43.0
___
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 v2 0/1] avcodec/libjxlenc: add option to disable xyb encoding
Changes since v1: - bump micro version, per policy - rebase onto master Leo Izen (1): avcodec/libjxlenc: add option to disable xyb encoding libavcodec/libjxlenc.c | 5 - libavcodec/version.h | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-) -- 2.43.0 ___ 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/tiff: pass arguments to bytestream2_seek in the right order
On 1/31/24 14:37, Leo Izen wrote: The function signature for bytestream2_seek is (gb, offset, whence); Before this patch, the code passed (gb, SEEK_SET, offset), which is incorrect. Siged-off-by: Leo Izen --- libavcodec/tiff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c index adb49e4525..3ce441aa2c 100644 --- a/libavcodec/tiff.c +++ b/libavcodec/tiff.c @@ -1701,7 +1701,7 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame) break; case TIFF_ICC_PROFILE: gb_temp = s->gb; -bytestream2_seek(_temp, SEEK_SET, off); +bytestream2_seek(_temp, off, SEEK_SET); if (bytestream2_get_bytes_left(_temp) < count) return AVERROR_INVALIDDATA; Will apply soon. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital 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 0/2] PNG cLLi and mDVc chunk support
On 2/4/24 04:35, Leo Izen wrote: This adds support for cLLi and mDVc chunks in the PNG specification[1]. [1]: https://www.w3.org/TR/png-3/ Changes from v1: - fix regression in cHRM writing, causing fate failure Leo Izen (2): avcodec/pngdec: read cLLi and mDVc chunks avcodec/pngenc: write cLLi and mDVc chunks libavcodec/pngdec.c | 63 + libavcodec/pngenc.c | 32 --- 2 files changed, 92 insertions(+), 3 deletions(-) Will apply soon. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital 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] FFmpeg 7.0 blocking issues
On 2/7/24 13:56, Andreas Rheinhardt wrote: Leo Izen: On 1/23/24 14:22, Michael Niedermayer wrote: Hi all As it was a little difficult for me to not loose track of what is blocking a release. I suggest that for all release blocking issues open a ticket and set Blocking to 7.0 that way this: https://trac.ffmpeg.org/query?blocking=~7.0 or for the ones not closed: https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 will list all blocking issues Ive added one, for testing that, i intend to add more if i see something What is blocking? (IMHO) * regressions (unless its non possible to fix before release) * crashes * security issues * data loss * privacy issues * anything the commuity agrees should be in the release thx My EXIF overhaul is going to be an ABI break so I'd like to get it in, if and only if we are doing an ABI break with the release. What EXIF overhaul? Since when is EXIF part of the ABI? - Andreas I'm working on a patch to centralize a lot of the exif logic and make it easier for decoders to attach it to an AVFrame as side data, rather than dumping all the key/value pairs into AVFrame.metadata and then hoping that an encoder can serialize them out properly. As for ABI, there's an avpriv in libavcodec/exif.c that is called by the AVI demuxer in avformat. My plan is to expose some of these exif parse routines as a proper av_ API, and replace that avpriv_ call with a call to the new API. I mentioned this to James on IRC and he said it would have to go in during an ABI flexibility period. - Leo Izen OpenPGP_signature.asc Description: OpenPGP digital 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] FFmpeg 7.0 blocking issues
On 1/23/24 14:22, Michael Niedermayer wrote: Hi all As it was a little difficult for me to not loose track of what is blocking a release. I suggest that for all release blocking issues open a ticket and set Blocking to 7.0 that way this: https://trac.ffmpeg.org/query?blocking=~7.0 or for the ones not closed: https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 will list all blocking issues Ive added one, for testing that, i intend to add more if i see something What is blocking? (IMHO) * regressions (unless its non possible to fix before release) * crashes * security issues * data loss * privacy issues * anything the commuity agrees should be in the release thx My EXIF overhaul is going to be an ABI break so I'd like to get it in, if and only if we are doing an ABI break with the release. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital 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".
[FFmpeg-devel] [PATCH v2 2/2] avcodec/pngenc: write cLLi and mDVc chunks
These chunks contain the Content Light Level Information and the
Mastering Display Color Volume information that FFmpeg already supports
as AVFrameSideData. This patch adds support for the png encoder to save
this metadata as the corresponding chunks in the PNG stream.
Signed-off-by: Leo Izen
---
libavcodec/pngenc.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index f0650962d2..50689cb50c 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -32,6 +32,7 @@
#include "libavutil/crc.h"
#include "libavutil/csp.h"
#include "libavutil/libm.h"
+#include "libavutil/mastering_display_metadata.h"
#include "libavutil/opt.h"
#include "libavutil/rational.h"
#include "libavutil/stereo3d.h"
@@ -294,8 +295,9 @@ static int png_write_row(AVCodecContext *avctx, const
uint8_t *data, int size)
return 0;
}
-#define AV_WB32_PNG(buf, n) AV_WB32(buf, lrint((n) * 10))
-#define AV_WB32_PNG_D(buf, d) AV_WB32_PNG(buf, av_q2d(d))
+#define PNG_LRINT(d, divisor) lrint((d) * (divisor))
+#define PNG_Q2D(q, divisor) PNG_LRINT(av_q2d(q), (divisor))
+#define AV_WB32_PNG_D(buf, q) AV_WB32(buf, PNG_Q2D(q, 10))
static int png_get_chrm(enum AVColorPrimaries prim, uint8_t *buf)
{
const AVColorPrimariesDesc *desc = av_csp_primaries_desc_from_id(prim);
@@ -320,7 +322,7 @@ static int png_get_gama(enum AVColorTransferCharacteristic
trc, uint8_t *buf)
if (gamma <= 1e-6)
return 0;
-AV_WB32_PNG(buf, 1.0 / gamma);
+AV_WB32(buf, PNG_LRINT(1.0 / gamma, 10));
return 1;
}
@@ -437,6 +439,30 @@ static int encode_headers(AVCodecContext *avctx, const
AVFrame *pict)
png_write_chunk(>bytestream, MKTAG('c', 'I', 'C', 'P'), s->buf, 4);
}
+side_data = av_frame_get_side_data(pict,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+if (side_data) {
+AVContentLightMetadata *clli = (AVContentLightMetadata *)
side_data->data;
+AV_WB32(s->buf, clli->MaxCLL * 1);
+AV_WB32(s->buf + 4, clli->MaxFALL * 1);
+png_write_chunk(>bytestream, MKTAG('c', 'L', 'L', 'i'), s->buf, 8);
+}
+
+side_data = av_frame_get_side_data(pict,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+if (side_data) {
+AVMasteringDisplayMetadata *mdvc = (AVMasteringDisplayMetadata *)
side_data->data;
+if (mdvc->has_luminance && mdvc->has_primaries) {
+for (int i = 0; i < 3; i++) {
+AV_WB16(s->buf + 2*i, PNG_Q2D(mdvc->display_primaries[i][0],
5));
+AV_WB16(s->buf + 2*i + 2,
PNG_Q2D(mdvc->display_primaries[i][1], 5));
+}
+AV_WB16(s->buf + 12, PNG_Q2D(mdvc->white_point[0], 5));
+AV_WB16(s->buf + 14, PNG_Q2D(mdvc->white_point[1], 5));
+AV_WB32(s->buf + 16, PNG_Q2D(mdvc->max_luminance, 1));
+AV_WB32(s->buf + 20, PNG_Q2D(mdvc->min_luminance, 1));
+png_write_chunk(>bytestream, MKTAG('m', 'D', 'V', 'c'), s->buf,
24);
+}
+}
+
if (png_get_chrm(pict->color_primaries, s->buf))
png_write_chunk(>bytestream, MKTAG('c', 'H', 'R', 'M'), s->buf, 32);
if (png_get_gama(pict->color_trc, s->buf))
--
2.43.0
___
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 v2 1/2] avcodec/pngdec: read cLLi and mDVc chunks
These chunks contain the Content Light Level Information and the
Mastering Display Color Volume information that FFmpeg already supports
as AVFrameSideData. This patch adds support for the png decoder to read
these chunks if present and attach the corresponding side data to the
decoded frame.
Signed-off-by: Leo Izen
---
libavcodec/pngdec.c | 63 +
1 file changed, 63 insertions(+)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index d1aae4c70e..026da30c25 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -29,6 +29,7 @@
#include "libavutil/csp.h"
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
+#include "libavutil/mastering_display_metadata.h"
#include "libavutil/pixfmt.h"
#include "libavutil/rational.h"
#include "libavutil/stereo3d.h"
@@ -81,6 +82,14 @@ typedef struct PNGDecContext {
enum AVColorPrimaries cicp_primaries;
enum AVColorTransferCharacteristic cicp_trc;
enum AVColorRange cicp_range;
+int have_clli;
+uint32_t clli_max;
+uint32_t clli_avg;
+int have_mdvc;
+uint16_t mdvc_primaries[3][2];
+uint16_t mdvc_white_point[2];
+uint32_t mdvc_max_lum;
+uint32_t mdvc_min_lum;
enum PNGHeaderState hdr_state;
enum PNGImageState pic_state;
@@ -731,6 +740,36 @@ static int populate_avctx_color_fields(AVCodecContext
*avctx, AVFrame *frame)
if (!s->has_trns && s->significant_bits > 0)
avctx->bits_per_raw_sample = s->significant_bits;
+if (s->have_clli) {
+AVContentLightMetadata *clli =
+av_content_light_metadata_create_side_data(frame);
+if (!clli)
+return AVERROR(ENOMEM);
+/*
+ * 0.0001 divisor value
+ * see: https://www.w3.org/TR/png-3/#cLLi-chunk
+ */
+clli->MaxCLL = s->clli_max / 1;
+clli->MaxFALL = s->clli_avg / 1;
+}
+
+if (s->have_mdvc) {
+AVMasteringDisplayMetadata *mdvc =
+av_mastering_display_metadata_create_side_data(frame);
+if (!mdvc)
+return AVERROR(ENOMEM);
+mdvc->has_primaries = 1;
+for (int i = 0; i < 3; i++) {
+mdvc->display_primaries[i][0] = av_make_q(s->mdvc_primaries[i][0],
5);
+mdvc->display_primaries[i][1] = av_make_q(s->mdvc_primaries[i][1],
5);
+}
+mdvc->white_point[0] = av_make_q(s->mdvc_white_point[0], 5);
+mdvc->white_point[1] = av_make_q(s->mdvc_white_point[1], 5);
+mdvc->has_luminance = 1;
+mdvc->max_luminance = av_make_q(s->mdvc_max_lum, 1);
+mdvc->min_luminance = av_make_q(s->mdvc_min_lum, 1);
+}
+
return 0;
}
@@ -1508,6 +1547,30 @@ static int decode_frame_common(AVCodecContext *avctx,
PNGDecContext *s,
break;
}
+case MKTAG('c', 'L', 'L', 'i'):
+if (bytestream2_get_bytes_left(_chunk) != 8) {
+av_log(avctx, AV_LOG_WARNING, "Invalid cLLi chunk size: %d\n",
bytestream2_get_bytes_left(_chunk));
+break;
+}
+s->have_clli = 1;
+s->clli_max = bytestream2_get_be32u(_chunk);
+s->clli_avg = bytestream2_get_be32u(_chunk);
+break;
+case MKTAG('m', 'D', 'V', 'c'):
+if (bytestream2_get_bytes_left(_chunk) != 24) {
+av_log(avctx, AV_LOG_WARNING, "Invalid mDVc chunk size: %d\n",
bytestream2_get_bytes_left(_chunk));
+break;
+}
+s->have_mdvc = 1;
+for (int i = 0; i < 3; i++) {
+s->mdvc_primaries[i][0] = bytestream2_get_be16u(_chunk);
+s->mdvc_primaries[i][1] = bytestream2_get_be16u(_chunk);
+}
+s->mdvc_white_point[0] = bytestream2_get_be16u(_chunk);
+s->mdvc_white_point[1] = bytestream2_get_be16u(_chunk);
+s->mdvc_max_lum = bytestream2_get_be32u(_chunk);
+s->mdvc_min_lum = bytestream2_get_be32u(_chunk);
+break;
case MKTAG('I', 'E', 'N', 'D'):
if (!(s->pic_state & PNG_ALLIMAGE))
av_log(avctx, AV_LOG_ERROR, "IEND without all image\n");
--
2.43.0
___
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 v2 0/2] PNG cLLi and mDVc chunk support
This adds support for cLLi and mDVc chunks in the PNG specification[1]. [1]: https://www.w3.org/TR/png-3/ Changes from v1: - fix regression in cHRM writing, causing fate failure Leo Izen (2): avcodec/pngdec: read cLLi and mDVc chunks avcodec/pngenc: write cLLi and mDVc chunks libavcodec/pngdec.c | 63 + libavcodec/pngenc.c | 32 --- 2 files changed, 92 insertions(+), 3 deletions(-) -- 2.43.0 ___ 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] avformat/nutenc: Fix indentation
On 2/3/24 14:20, Andreas Rheinhardt wrote:
Forgotten after 82beb46e65e5f820b187355bf757725c22a59c45.
Also use loop-scope for iterators while at it.
Signed-off-by: Andreas Rheinhardt
---
libavformat/nutenc.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index a5198c7ca9..5e0e36babe 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -1063,21 +1063,21 @@ static int nut_write_packet(AVFormatContext *s,
AVPacket *pkt)
ffio_free_dyn_buf(_bc);
if (nut->write_index) {
-if ((ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0 /*unused*/,
pkt->dts)) < 0)
-goto fail;
-
-if ((1ll<<60) % nut->sp_count == 0)
-for (i=0; inb_streams; i++) {
-int j;
-StreamContext *nus = >stream[i];
-av_reallocp_array(>keyframe_pts, 2*nut->sp_count,
sizeof(*nus->keyframe_pts));
-if (!nus->keyframe_pts) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-for (j=nut->sp_count == 1 ? 0 : nut->sp_count;
j<2*nut->sp_count; j++)
-nus->keyframe_pts[j] = AV_NOPTS_VALUE;
-}
+if ((ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0 /*unused*/,
pkt->dts)) < 0)
+goto fail;
+
+if ((1ll<<60) % nut->sp_count == 0)
+for (unsigned i = 0; i < s->nb_streams; i++) {
+StreamContext *nus = >stream[i];
+av_reallocp_array(>keyframe_pts, 2*nut->sp_count,
sizeof(*nus->keyframe_pts));
+if (!nus->keyframe_pts) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+for (int j = nut->sp_count == 1 ? 0 : nut->sp_count;
+ j < 2 * nut->sp_count; j++)
+nus->keyframe_pts[j] = AV_NOPTS_VALUE;
+}
}
}
av_assert0(nus->last_pts != AV_NOPTS_VALUE);
If we're changing this block of code anyway, could we possibly replace
this line:
if ((ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0
/*unused*/, pkt->dts)) < 0)
goto fail;
With something like this?
ret = ff_nut_add_sp(nut, nut->last_syncpoint_pos, 0 /*unused*/, pkt->dts);
if (ret < 0)
goto fail;
It's a bit cleaner.
OpenPGP_signature.asc
Description: OpenPGP digital 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 3/4] lavf/demux: stop calling avcodec_close()
On 2/1/24 03:29, Anton Khirnov wrote:
Replace it with recreating the codec context.
This is the last remaining blocker for deprecating avcodec_close().
---
libavformat/demux.c | 53 -
1 file changed, 48 insertions(+), 5 deletions(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 6f640b92b1..c1640c459c 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -1250,6 +1250,52 @@ static int64_t ts_to_samples(AVStream *st, int64_t ts)
return av_rescale(ts, st->time_base.num * st->codecpar->sample_rate,
st->time_base.den);
}
+static int codec_close(FFStream *sti)
+{
+AVCodecContext *avctx_new = NULL;
+AVCodecParameters *par_tmp = NULL;
+int ret = 0;
+
I believe we can drop the initialization from avctx_new and from ret,
because avctx_new is assigned immediately, and ret is assigned before
each goto before it's assigned properly.
+avctx_new = avcodec_alloc_context3(sti->avctx->codec);
+if (!avctx_new) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+par_tmp = avcodec_parameters_alloc();
+if (!par_tmp) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+ret = avcodec_parameters_from_context(par_tmp, sti->avctx);
+if (ret < 0)
+goto fail;
+
+ret = avcodec_parameters_to_context(avctx_new, par_tmp);
+if (ret < 0)
+goto fail;
+
+avctx_new->pkt_timebase = sti->avctx->pkt_timebase;
+
+#if FF_API_TICKS_PER_FRAME
+FF_DISABLE_DEPRECATION_WARNINGS
+avctx_new->ticks_per_frame = sti->avctx->ticks_per_frame;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+
+avcodec_free_context(>avctx);
+sti->avctx = avctx_new;
+
+avctx_new = NULL;
+
+fail:
+avcodec_free_context(_new);
+avcodec_parameters_free(_tmp);
+
+return ret;
+}
+
static int read_frame_internal(AVFormatContext *s, AVPacket *pkt)
{
FFFormatContext *const si = ffformatcontext(s);
@@ -1286,7 +1332,7 @@ static int read_frame_internal(AVFormatContext *s,
AVPacket *pkt)
if (sti->need_context_update) {
if (avcodec_is_open(sti->avctx)) {
av_log(s, AV_LOG_DEBUG, "Demuxer context update while decoder is
open, closing and trying to re-open\n");
-avcodec_close(sti->avctx);
+codec_close(sti);
sti->info->found_decoder = 0;
}
@@ -3017,10 +3063,7 @@ find_stream_info_err:
av_freep(>info->duration_error);
av_freep(>info);
}
-avcodec_close(sti->avctx);
-// FIXME: avcodec_close() frees AVOption settable fields which
includes ch_layout,
-//so we need to restore it.
-av_channel_layout_copy(>avctx->ch_layout,
>codecpar->ch_layout);
+codec_close(sti);
av_bsf_free(>extract_extradata.bsf);
}
if (ic->pb) {
OpenPGP_signature.asc
Description: OpenPGP digital 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".
[FFmpeg-devel] [PATCH 2/2] avcodec/pngenc: write cLLi and mDVc chunks
These chunks contain the Content Light Level Information and the
Mastering Display Color Volume information that FFmpeg already supports
as AVFrameSideData. This patch adds support for the png encoder to save
this metadata as the corresponding chunks in the PNG stream.
Signed-off-by: Leo Izen
---
libavcodec/pngenc.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index f0650962d2..aab56d6d07 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -32,6 +32,7 @@
#include "libavutil/crc.h"
#include "libavutil/csp.h"
#include "libavutil/libm.h"
+#include "libavutil/mastering_display_metadata.h"
#include "libavutil/opt.h"
#include "libavutil/rational.h"
#include "libavutil/stereo3d.h"
@@ -294,8 +295,9 @@ static int png_write_row(AVCodecContext *avctx, const
uint8_t *data, int size)
return 0;
}
-#define AV_WB32_PNG(buf, n) AV_WB32(buf, lrint((n) * 10))
-#define AV_WB32_PNG_D(buf, d) AV_WB32_PNG(buf, av_q2d(d))
+#define PNG_LRINT(d, divisor) lrint((d) * (divisor))
+#define PNG_Q2D(q, divisor) PNG_LRINT(av_q2d(q), (divisor))
+#define AV_WB32_PNG_D(buf, q) AV_WB32(buf, PNG_Q2D(q, 1))
static int png_get_chrm(enum AVColorPrimaries prim, uint8_t *buf)
{
const AVColorPrimariesDesc *desc = av_csp_primaries_desc_from_id(prim);
@@ -320,7 +322,7 @@ static int png_get_gama(enum AVColorTransferCharacteristic
trc, uint8_t *buf)
if (gamma <= 1e-6)
return 0;
-AV_WB32_PNG(buf, 1.0 / gamma);
+AV_WB32(buf, PNG_LRINT(1.0 / gamma, 1));
return 1;
}
@@ -437,6 +439,30 @@ static int encode_headers(AVCodecContext *avctx, const
AVFrame *pict)
png_write_chunk(>bytestream, MKTAG('c', 'I', 'C', 'P'), s->buf, 4);
}
+side_data = av_frame_get_side_data(pict,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+if (side_data) {
+AVContentLightMetadata *clli = (AVContentLightMetadata *)
side_data->data;
+AV_WB32(s->buf, clli->MaxCLL * 1);
+AV_WB32(s->buf + 4, clli->MaxFALL * 1);
+png_write_chunk(>bytestream, MKTAG('c', 'L', 'L', 'i'), s->buf, 8);
+}
+
+side_data = av_frame_get_side_data(pict,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+if (side_data) {
+AVMasteringDisplayMetadata *mdvc = (AVMasteringDisplayMetadata *)
side_data->data;
+if (mdvc->has_luminance && mdvc->has_primaries) {
+for (int i = 0; i < 3; i++) {
+AV_WB16(s->buf + 2*i, PNG_Q2D(mdvc->display_primaries[i][0],
5));
+AV_WB16(s->buf + 2*i + 2,
PNG_Q2D(mdvc->display_primaries[i][1], 5));
+}
+AV_WB16(s->buf + 12, PNG_Q2D(mdvc->white_point[0], 5));
+AV_WB16(s->buf + 14, PNG_Q2D(mdvc->white_point[1], 5));
+AV_WB32(s->buf + 16, PNG_Q2D(mdvc->max_luminance, 1));
+AV_WB32(s->buf + 20, PNG_Q2D(mdvc->min_luminance, 1));
+png_write_chunk(>bytestream, MKTAG('m', 'D', 'V', 'c'), s->buf,
24);
+}
+}
+
if (png_get_chrm(pict->color_primaries, s->buf))
png_write_chunk(>bytestream, MKTAG('c', 'H', 'R', 'M'), s->buf, 32);
if (png_get_gama(pict->color_trc, s->buf))
--
2.43.0
___
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 1/2] avcodec/pngdec: read cLLi and mDVc chunks
These chunks contain the Content Light Level Information and the
Mastering Display Color Volume information that FFmpeg already supports
as AVFrameSideData. This patch adds support for the png decoder to read
these chunks if present and attach the corresponding side data to the
decoded frame.
Signed-off-by: Leo Izen
---
libavcodec/pngdec.c | 63 +
1 file changed, 63 insertions(+)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index d1aae4c70e..026da30c25 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -29,6 +29,7 @@
#include "libavutil/csp.h"
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
+#include "libavutil/mastering_display_metadata.h"
#include "libavutil/pixfmt.h"
#include "libavutil/rational.h"
#include "libavutil/stereo3d.h"
@@ -81,6 +82,14 @@ typedef struct PNGDecContext {
enum AVColorPrimaries cicp_primaries;
enum AVColorTransferCharacteristic cicp_trc;
enum AVColorRange cicp_range;
+int have_clli;
+uint32_t clli_max;
+uint32_t clli_avg;
+int have_mdvc;
+uint16_t mdvc_primaries[3][2];
+uint16_t mdvc_white_point[2];
+uint32_t mdvc_max_lum;
+uint32_t mdvc_min_lum;
enum PNGHeaderState hdr_state;
enum PNGImageState pic_state;
@@ -731,6 +740,36 @@ static int populate_avctx_color_fields(AVCodecContext
*avctx, AVFrame *frame)
if (!s->has_trns && s->significant_bits > 0)
avctx->bits_per_raw_sample = s->significant_bits;
+if (s->have_clli) {
+AVContentLightMetadata *clli =
+av_content_light_metadata_create_side_data(frame);
+if (!clli)
+return AVERROR(ENOMEM);
+/*
+ * 0.0001 divisor value
+ * see: https://www.w3.org/TR/png-3/#cLLi-chunk
+ */
+clli->MaxCLL = s->clli_max / 1;
+clli->MaxFALL = s->clli_avg / 1;
+}
+
+if (s->have_mdvc) {
+AVMasteringDisplayMetadata *mdvc =
+av_mastering_display_metadata_create_side_data(frame);
+if (!mdvc)
+return AVERROR(ENOMEM);
+mdvc->has_primaries = 1;
+for (int i = 0; i < 3; i++) {
+mdvc->display_primaries[i][0] = av_make_q(s->mdvc_primaries[i][0],
5);
+mdvc->display_primaries[i][1] = av_make_q(s->mdvc_primaries[i][1],
5);
+}
+mdvc->white_point[0] = av_make_q(s->mdvc_white_point[0], 5);
+mdvc->white_point[1] = av_make_q(s->mdvc_white_point[1], 5);
+mdvc->has_luminance = 1;
+mdvc->max_luminance = av_make_q(s->mdvc_max_lum, 1);
+mdvc->min_luminance = av_make_q(s->mdvc_min_lum, 1);
+}
+
return 0;
}
@@ -1508,6 +1547,30 @@ static int decode_frame_common(AVCodecContext *avctx,
PNGDecContext *s,
break;
}
+case MKTAG('c', 'L', 'L', 'i'):
+if (bytestream2_get_bytes_left(_chunk) != 8) {
+av_log(avctx, AV_LOG_WARNING, "Invalid cLLi chunk size: %d\n",
bytestream2_get_bytes_left(_chunk));
+break;
+}
+s->have_clli = 1;
+s->clli_max = bytestream2_get_be32u(_chunk);
+s->clli_avg = bytestream2_get_be32u(_chunk);
+break;
+case MKTAG('m', 'D', 'V', 'c'):
+if (bytestream2_get_bytes_left(_chunk) != 24) {
+av_log(avctx, AV_LOG_WARNING, "Invalid mDVc chunk size: %d\n",
bytestream2_get_bytes_left(_chunk));
+break;
+}
+s->have_mdvc = 1;
+for (int i = 0; i < 3; i++) {
+s->mdvc_primaries[i][0] = bytestream2_get_be16u(_chunk);
+s->mdvc_primaries[i][1] = bytestream2_get_be16u(_chunk);
+}
+s->mdvc_white_point[0] = bytestream2_get_be16u(_chunk);
+s->mdvc_white_point[1] = bytestream2_get_be16u(_chunk);
+s->mdvc_max_lum = bytestream2_get_be32u(_chunk);
+s->mdvc_min_lum = bytestream2_get_be32u(_chunk);
+break;
case MKTAG('I', 'E', 'N', 'D'):
if (!(s->pic_state & PNG_ALLIMAGE))
av_log(avctx, AV_LOG_ERROR, "IEND without all image\n");
--
2.43.0
___
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 0/2] PNG cLLi and mDVc chunk support
This adds support for cLLi and mDVc chunks in the PNG specification[1]. [1]: https://www.w3.org/TR/png-3/ Leo Izen (2): avcodec/pngdec: read cLLi and mDVc chunks avcodec/pngenc: write cLLi and mDVc chunks libavcodec/pngdec.c | 63 + libavcodec/pngenc.c | 32 --- 2 files changed, 92 insertions(+), 3 deletions(-) -- 2.43.0 ___ 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/tiff: pass arguments to bytestream2_seek in the right order
The function signature for bytestream2_seek is (gb, offset, whence); Before this patch, the code passed (gb, SEEK_SET, offset), which is incorrect. Siged-off-by: Leo Izen --- libavcodec/tiff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c index adb49e4525..3ce441aa2c 100644 --- a/libavcodec/tiff.c +++ b/libavcodec/tiff.c @@ -1701,7 +1701,7 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame) break; case TIFF_ICC_PROFILE: gb_temp = s->gb; -bytestream2_seek(_temp, SEEK_SET, off); +bytestream2_seek(_temp, off, SEEK_SET); if (bytestream2_get_bytes_left(_temp) < count) return AVERROR_INVALIDDATA; -- 2.43.0 ___ 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 v3] avcodec/libjxlenc: support negative linesizes
On 1/30/24 10:24, Leo Izen wrote: +jxl_fmt.align = -frame->linesize[0]; +data = frame->data[0] + frame->linesize[0] * (info.ysize - 1); +} Something like this ^ is what you're requesting, right? - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital 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".
[FFmpeg-devel] [PATCH v3] avcodec/libjxlenc: support negative linesizes
libjxl doesn't support negative strides, but JPEG XL has an orientation
flag inside the codestream. We can use this to work around the library
limitation, by taking the absolute value of the negative row stride,
sending the image up-side-down, and telling the library that the image
has a vertical-flip orientation.
Signed-off-by: Leo Izen
---
libavcodec/libjxlenc.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index 67be8a01ca..5f5f9751dc 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -259,6 +259,7 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
size_t available = ctx->buffer_size;
size_t bytes_written = 0;
uint8_t *next_out = ctx->buffer;
+const uint8_t *data;
ret = libjxl_init_jxl_encoder(avctx);
if (ret) {
@@ -303,6 +304,7 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
/* bitexact lossless requires there to be no XYB transform */
info.uses_original_profile = ctx->distance == 0.0;
+info.orientation = frame->linesize[0] >= 0 ? JXL_ORIENT_IDENTITY :
JXL_ORIENT_FLIP_VERTICAL;
if (JxlEncoderSetBasicInfo(ctx->encoder, ) != JXL_ENC_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to set JxlBasicInfo\n");
@@ -383,9 +385,15 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
}
jxl_fmt.endianness = JXL_NATIVE_ENDIAN;
-jxl_fmt.align = frame->linesize[0];
+if (frame->linesize[0] >= 0) {
+jxl_fmt.align = frame->linesize[0];
+data = frame->data[0];
+} else {
+jxl_fmt.align = -frame->linesize[0];
+data = frame->data[0] + frame->linesize[0] * (info.ysize - 1);
+}
-if (JxlEncoderAddImageFrame(ctx->options, _fmt, frame->data[0],
jxl_fmt.align * info.ysize) != JXL_ENC_SUCCESS) {
+if (JxlEncoderAddImageFrame(ctx->options, _fmt, data, jxl_fmt.align *
info.ysize) != JXL_ENC_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to add Image Frame\n");
return AVERROR_EXTERNAL;
}
--
2.43.0
___
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] avcodec/libjxlenc: support negative linesizes
On 1/30/24 09:57, Andreas Rheinhardt wrote: Please don't rely on the type of jxl_fmt.align here (which is out of our control). E.g. in the future it may be that libjxl supports only 32bit align values (i.e. uses uint32_t or so for it), but that we support 64bit (ptrdiff_t) linesizes and allocations, so that jxl_fmt.align * (info.ysize - 1) may overflow this even when -linesize fits into jxl_fmt.align. (Very unlikely given that align is size_t and they will likely not go back from this, but it could happen.) This would be an ABI break though, wouldn't it? Why do we need to work around a potential future ABI break? OpenPGP_signature.asc Description: OpenPGP digital 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] avcodec/libjxlenc: support negative linesizes
On 1/30/24 09:46, Leo Izen wrote: libjxl doesn't support negative strides, but JPEG XL has an orientation flag inside the codestream. We can use this to work around the library limitation, by taking the absolute value of the negative row stride, sending the image up-side-down, and telling the library that the image has a vertical-flip orientation. Signed-off-by: Leo Izen --- Changes from v1: - constify uint8_t *data, per Andreas's request OpenPGP_signature.asc Description: OpenPGP digital 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".
[FFmpeg-devel] [PATCH v2] avcodec/libjxlenc: support negative linesizes
libjxl doesn't support negative strides, but JPEG XL has an orientation
flag inside the codestream. We can use this to work around the library
limitation, by taking the absolute value of the negative row stride,
sending the image up-side-down, and telling the library that the image
has a vertical-flip orientation.
Signed-off-by: Leo Izen
---
libavcodec/libjxlenc.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index 67be8a01ca..4ddd5f9f2c 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -259,6 +259,7 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
size_t available = ctx->buffer_size;
size_t bytes_written = 0;
uint8_t *next_out = ctx->buffer;
+const uint8_t *data;
ret = libjxl_init_jxl_encoder(avctx);
if (ret) {
@@ -303,6 +304,7 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
/* bitexact lossless requires there to be no XYB transform */
info.uses_original_profile = ctx->distance == 0.0;
+info.orientation = frame->linesize[0] >= 0 ? JXL_ORIENT_IDENTITY :
JXL_ORIENT_FLIP_VERTICAL;
if (JxlEncoderSetBasicInfo(ctx->encoder, ) != JXL_ENC_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to set JxlBasicInfo\n");
@@ -383,9 +385,15 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
}
jxl_fmt.endianness = JXL_NATIVE_ENDIAN;
-jxl_fmt.align = frame->linesize[0];
+if (frame->linesize[0] >= 0) {
+jxl_fmt.align = frame->linesize[0];
+data = frame->data[0];
+} else {
+jxl_fmt.align = -frame->linesize[0];
+data = frame->data[0] - jxl_fmt.align * (info.ysize - 1);
+}
-if (JxlEncoderAddImageFrame(ctx->options, _fmt, frame->data[0],
jxl_fmt.align * info.ysize) != JXL_ENC_SUCCESS) {
+if (JxlEncoderAddImageFrame(ctx->options, _fmt, data, jxl_fmt.align *
info.ysize) != JXL_ENC_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to add Image Frame\n");
return AVERROR_EXTERNAL;
}
--
2.43.0
___
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/libjxlenc: support negative linesizes
libjxl doesn't support negative strides, but JPEG XL has an orientation
flag inside the codestream. We can use this to work around the library
limitation, by taking the absolute value of the negative row stride,
sending the image up-side-down, and telling the library that the image
has a vertical-flip orientation.
Signed-off-by: Leo Izen
---
libavcodec/libjxlenc.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index 67be8a01ca..49020b1036 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -259,6 +259,7 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
size_t available = ctx->buffer_size;
size_t bytes_written = 0;
uint8_t *next_out = ctx->buffer;
+uint8_t *data;
ret = libjxl_init_jxl_encoder(avctx);
if (ret) {
@@ -303,6 +304,7 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
/* bitexact lossless requires there to be no XYB transform */
info.uses_original_profile = ctx->distance == 0.0;
+info.orientation = frame->linesize[0] >= 0 ? JXL_ORIENT_IDENTITY :
JXL_ORIENT_FLIP_VERTICAL;
if (JxlEncoderSetBasicInfo(ctx->encoder, ) != JXL_ENC_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to set JxlBasicInfo\n");
@@ -383,9 +385,15 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
}
jxl_fmt.endianness = JXL_NATIVE_ENDIAN;
-jxl_fmt.align = frame->linesize[0];
+if (frame->linesize[0] >= 0) {
+jxl_fmt.align = frame->linesize[0];
+data = frame->data[0];
+} else {
+jxl_fmt.align = -frame->linesize[0];
+data = frame->data[0] - jxl_fmt.align * (info.ysize - 1);
+}
-if (JxlEncoderAddImageFrame(ctx->options, _fmt, frame->data[0],
jxl_fmt.align * info.ysize) != JXL_ENC_SUCCESS) {
+if (JxlEncoderAddImageFrame(ctx->options, _fmt, data, jxl_fmt.align *
info.ysize) != JXL_ENC_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to add Image Frame\n");
return AVERROR_EXTERNAL;
}
--
2.43.0
___
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/libjxlenc: add option to disable xyb encoding
Add an AVOption to the libjxl encoder wrapper, which exposes the flag
uses_original_profile in libjxl. For highly unusual ICC profiles where
the target needs to stay in the original space, this can be useful.
Signed-off-by: Leo Izen
---
libavcodec/libjxlenc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index 67be8a01ca..5541fc2bb3 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -52,6 +52,7 @@ typedef struct LibJxlEncodeContext {
int effort;
float distance;
int modular;
+int xyb;
uint8_t *buffer;
size_t buffer_size;
} LibJxlEncodeContext;
@@ -302,7 +303,7 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
av_log(avctx, AV_LOG_WARNING, "Unknown color range, assuming full
(pc)\n");
/* bitexact lossless requires there to be no XYB transform */
-info.uses_original_profile = ctx->distance == 0.0;
+info.uses_original_profile = ctx->distance == 0.0 || !ctx->xyb;
if (JxlEncoderSetBasicInfo(ctx->encoder, ) != JXL_ENC_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to set JxlBasicInfo\n");
@@ -466,6 +467,8 @@ static const AVOption libjxl_encode_options[] = {
{ "distance", "Maximum Butteraugli distance (quality setting, "
"lower = better, zero = lossless, default 1.0)",
OFFSET(distance), AV_OPT_TYPE_FLOAT, { .dbl = -1.0 }, -1.0, 15.0, VE },
{ "modular", "Force modular mode",
OFFSET(modular),AV_OPT_TYPE_INT,{ .i64 =0 },0, 1, VE },
+{ "xyb", "Use XYB-encoding for lossy images",
OFFSET(xyb),
+AV_OPT_TYPE_INT, { .i64 =1 },0, 1, VE },
{ NULL },
};
--
2.43.0
___
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] h264 - Late SEI is not implemented
On 1/23/24 18:21, Harald Linden via ffmpeg-devel wrote: Is this interesting to you? Do you want me to upload the sample? It might be of dubious nature regarding copyright, depending on local legislation. regards Harald You can try to truncate the file to the smallest size that reproduces the issue, for example via something like: truncate --size=1024 input.mkv This will set the file size of input.mkv to 1024 bytes, discarding all data after it. This is destructive! Make a backup first. It's a good idea to truncate samples *anyway* regardless of legal ramifications. I am not a lawyer and this is not legal advice. However, as far as I understand, Tiny samples for the sake of reproducing technical errors, that were obtained legally, are likely to be covered by Fair Use in most jurisdictions. If you aren't sure, you can always double check with the third party that you obtained the file from. You can also host the sample elsewhere, such as your own website, or on a site like 0x0.st, if you are concerned about Videolan's jurisdiction. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital 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".
[FFmpeg-devel] [PATCH] avcodec/libjxl.h: include version.h
This file has been exported since our minimum required version (0.7.0), but it wasn't documented. Instead it was transitively included by (but not jxl/encode.h), which ffmpeg relied on. libjxl broke its API in libjxl/libjxl@66b959239355aef5255 by removing the transitive include of version.h, and they do not plan on adding it back. Instead they are choosing to leave the API backwards- incompatible with downstream callers written for some fairly recent versions of their API. As a result, we include to continue to build against more recent versions of libjxl. The version macros removed are also present in that file, so we no longer need to redefine them. Signed-off-by: Leo Izen --- libavcodec/libjxl.h | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/libavcodec/libjxl.h b/libavcodec/libjxl.h index e305b6e758..0b983a122f 100644 --- a/libavcodec/libjxl.h +++ b/libavcodec/libjxl.h @@ -27,19 +27,8 @@ #ifndef AVCODEC_LIBJXL_H #define AVCODEC_LIBJXL_H -#include #include - -/* - * libjxl version 0.7.0 and earlier doesn't contain these macros at all - * so to detect version 0.7.0 versus 0.8.0 we need to define them ourselves - */ -#ifndef JPEGXL_COMPUTE_NUMERIC_VERSION -#define JPEGXL_COMPUTE_NUMERIC_VERSION(major,minor,patch) ((major<<24) | (minor<<16) | (patch<<8) | 0) -#endif -#ifndef JPEGXL_NUMERIC_VERSION -#define JPEGXL_NUMERIC_VERSION JPEGXL_COMPUTE_NUMERIC_VERSION(0, 7, 0) -#endif +#include /** * Transform threadcount in ffmpeg to one used by libjxl. -- 2.43.0 ___ 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] avformat/mxfenc: remove unused variables
Produces a -Wunused-variables warning with -Wall.
Signed-off-by: Leo Izen
---
libavformat/mxfenc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 685c11b3a5..febc1ccf8c 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1487,7 +1487,6 @@ static void mxf_write_jpeg2000_subdesc(AVFormatContext
*s, AVStream *st)
AVIOContext *pb = s->pb;
int64_t pos;
int component_count = av_pix_fmt_count_planes(st->codecpar->format);
-int comp = 0;
/* JPEG2000 subdescriptor key */
avio_write(pb, mxf_jpeg2000_subdescriptor_key, 16);
@@ -2640,11 +2639,9 @@ static int mxf_parse_jpeg2000_frame(AVFormatContext *s,
AVStream *st, AVPacket *
{
MXFContext *mxf = s->priv_data;
MXFStreamContext *sc = st->priv_data;
-AVIOContext *pb = s->pb;
int component_count = av_pix_fmt_count_planes(st->codecpar->format);
GetByteContext g;
uint32_t j2k_ncomponents;
-int comp;
if (mxf->header_written)
return 1;
--
2.43.0
___
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] MAINTAINERS: add my new PGP key
Patch attached, this email signed with my previous key. - Leo Izen (Traneptora) From 09ee68f816d1d2c39097515cedca69031251aa4f Mon Sep 17 00:00:00 2001 From: Leo Izen Date: Mon, 8 Jan 2024 14:01:59 -0500 Subject: [PATCH] MAINTAINERS: add my new PGP key Adding my new gpg key that I will be using from now on. This key is ed25519, which is more secure than the old rsa4096. Signed-off-by: Leo Izen --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3f7098acf8..4677931211 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -619,6 +619,7 @@ Jaikrishnan Menon 61A1 F09F 01C9 2D45 78E1 C862 25DC 8831 AF70 D368 James Almer 7751 2E8C FD94 A169 57E6 9A7A 1463 01AD 7376 59E0 Jean Delvare 7CA6 9F44 60F1 BDC4 1FD2 C858 A552 6B9B B3CD 4E6A Leo Izen (Traneptora) B6FD 3CFC 7ACF 83FC 9137 6945 5A71 C331 FD2F A19A +Leo Izen (Traneptora) 1D83 0A0B CE46 709E 203B 26FC 764E 48EA 4822 1833 Loren Merritt ABD9 08F4 C920 3F65 D8BE 35D7 1540 DAA7 060F 56DE Lynne FE50 139C 6805 72CA FD52 1F8D A2FE A5F0 3F03 4464 Michael Niedermayer 9FF2 128B 147E F673 0BAD F133 611E C787 040B 0FAB -- 2.43.0 OpenPGP_0x5A71C331FD2FA19A.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital 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] avcodec/jpegxl_parser: check ANS cluster alphabet size vs bundle size
On 12/25/23 15:09, Michael Niedermayer wrote:
On Mon, Dec 25, 2023 at 12:04:17PM -0500, Leo Izen wrote:
The specification doesn't mention that clusters cannot have alphabet
sizes greater than 1 << bundle->log_alphabet_size, but the reference
implementation rejects these entropy streams as invalid, so we should
too. Refusing to do so can overflow a stack variable on line 556 that
should be large enough otherwise.
Fixes #10738.
Found-by: Zeng Yunxiang and Li Zeyuan
Signed-off-by: Leo Izen
---
libavcodec/jpegxl_parser.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 006eb6b295..f026fda9ac 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -64,26 +64,26 @@ typedef struct JXLSymbolDistribution {
int log_bucket_size;
/* this is the actual size of the alphabet */
int alphabet_size;
-/* ceil(log(alphabet_size)) */
-int log_alphabet_size;
/* for prefix code distributions */
VLC vlc;
/* in case bits == 0 */
uint32_t default_symbol;
+/* ceil(log(alphabet_size)) */
+int log_alphabet_size;
that seems unneeded
dist->log_alphaebet_size is only used for prefix code distributions so I
moved it for clarity. I can also remove this change from this commit if
you think it's off-topic.
In either case, is the commit okay, apart from this one change? If so
I'm going to merge it (after I remove this one change from the diff).
- Leo Izen (Traneptora)
___
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] lavc: remove the QOA decoder
On 12/21/23 21:32, Michael Niedermayer wrote: Can you think of a way to add some lines of code to this that makes it more maintainable ? if yes, then i think you proofed that adding code can reduce maintaince burden thx This is clearly not the point here. The point is that an in-house module has to be maintained, and removing that module removes the maintenance burden. An international obfuscated C contest entry isn't really on-topic. - Leo Izen (Traneptora) ___ 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 v2] avcodec/jpegxl_parser: check ANS cluster alphabet size vs bundle size
The specification doesn't mention that clusters cannot have alphabet
sizes greater than 1 << bundle->log_alphabet_size, but the reference
implementation rejects these entropy streams as invalid, so we should
too. Refusing to do so can overflow a stack variable on line 556 that
should be large enough otherwise.
Fixes #10738.
Found-by: Zeng Yunxiang and Li Zeyuan
Signed-off-by: Leo Izen
---
libavcodec/jpegxl_parser.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 006eb6b295..f026fda9ac 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -64,26 +64,26 @@ typedef struct JXLSymbolDistribution {
int log_bucket_size;
/* this is the actual size of the alphabet */
int alphabet_size;
-/* ceil(log(alphabet_size)) */
-int log_alphabet_size;
/* for prefix code distributions */
VLC vlc;
/* in case bits == 0 */
uint32_t default_symbol;
+/* ceil(log(alphabet_size)) */
+int log_alphabet_size;
/*
* each (1 << log_alphabet_size) length
* with log_alphabet_size <= 8
*/
/* frequencies associated with this Distribution */
-uint32_t freq[258];
+uint32_t freq[256];
/* cutoffs for using the symbol table */
-uint16_t cutoffs[258];
+uint16_t cutoffs[256];
/* the symbol table for this distribution */
-uint16_t symbols[258];
+uint16_t symbols[256];
/* the offset for symbols */
-uint16_t offsets[258];
+uint16_t offsets[256];
/* if this distribution contains only one symbol this is its index */
int uniq_pos;
@@ -382,13 +382,13 @@ static int populate_distribution(GetBitContext *gb,
JXLSymbolDistribution *dist,
int len = 0, shift, omit_log = -1, omit_pos = -1;
int prev = 0, num_same = 0;
uint32_t total_count = 0;
-uint8_t logcounts[258] = { 0 };
-uint8_t same[258] = { 0 };
+uint8_t logcounts[256] = { 0 };
+uint8_t same[256] = { 0 };
+const int table_size = 1 << log_alphabet_size;
dist->uniq_pos = -1;
if (get_bits1(gb)) {
/* simple code */
-dist->alphabet_size = 256;
if (get_bits1(gb)) {
uint8_t v1 = jxl_u8(gb);
uint8_t v2 = jxl_u8(gb);
@@ -398,17 +398,24 @@ static int populate_distribution(GetBitContext *gb,
JXLSymbolDistribution *dist,
dist->freq[v2] = (1 << 12) - dist->freq[v1];
if (!dist->freq[v1])
dist->uniq_pos = v2;
+dist->alphabet_size = 1 + FFMAX(v1, v2);
} else {
uint8_t x = jxl_u8(gb);
dist->freq[x] = 1 << 12;
dist->uniq_pos = x;
+dist->alphabet_size = 1 + x;
}
+if (dist->alphabet_size > table_size)
+return AVERROR_INVALIDDATA;
+
return 0;
}
if (get_bits1(gb)) {
/* flat code */
dist->alphabet_size = jxl_u8(gb) + 1;
+if (dist->alphabet_size > table_size)
+return AVERROR_INVALIDDATA;
for (int i = 0; i < dist->alphabet_size; i++)
dist->freq[i] = (1 << 12) / dist->alphabet_size;
for (int i = 0; i < (1 << 12) % dist->alphabet_size; i++)
@@ -426,6 +433,9 @@ static int populate_distribution(GetBitContext *gb,
JXLSymbolDistribution *dist,
return AVERROR_INVALIDDATA;
dist->alphabet_size = jxl_u8(gb) + 3;
+if (dist->alphabet_size > table_size)
+return AVERROR_INVALIDDATA;
+
for (int i = 0; i < dist->alphabet_size; i++) {
logcounts[i] = get_vlc2(gb, dist_prefix_table, 7, 1);
if (logcounts[i] == 13) {
--
2.43.0
___
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/2] avcodec/libjxlenc: Don't refer to decoder in comments
On 12/21/23 18:01, Andreas Rheinhardt wrote: Signed-off-by: Andreas Rheinhardt --- libavcodec/libjxlenc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c index d707f3a61b..055c9b7bb1 100644 --- a/libavcodec/libjxlenc.c +++ b/libavcodec/libjxlenc.c @@ -85,8 +85,8 @@ static float quality_to_distance(float quality) } Both of these LGTM. - Leo Izen (Traneptora) ___ 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/jpegxl_parser: check ANS cluster alphabet size vs bundle size
The specification doesn't mention that clusters cannot have alphabet
sizes greater than 1 << bundle->log_alphabet_size, but the reference
implementation rejects these entropy streams as invalid, so we should
too. Refusing to do so can overflow a stack variable on line 556 that
should be large enough otherwise.
Fixes #10738.
Reported-by: Michael Niedermayer
Signed-off-by: Leo Izen
---
libavcodec/jpegxl_parser.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 006eb6b295..c9832e4393 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -388,7 +388,6 @@ static int populate_distribution(GetBitContext *gb,
JXLSymbolDistribution *dist,
if (get_bits1(gb)) {
/* simple code */
-dist->alphabet_size = 256;
if (get_bits1(gb)) {
uint8_t v1 = jxl_u8(gb);
uint8_t v2 = jxl_u8(gb);
@@ -398,10 +397,12 @@ static int populate_distribution(GetBitContext *gb,
JXLSymbolDistribution *dist,
dist->freq[v2] = (1 << 12) - dist->freq[v1];
if (!dist->freq[v1])
dist->uniq_pos = v2;
+dist->alphabet_size = 1 + FFMAX(v1, v2);
} else {
uint8_t x = jxl_u8(gb);
dist->freq[x] = 1 << 12;
dist->uniq_pos = x;
+dist->alphabet_size= 1 + x;
}
return 0;
}
@@ -880,6 +881,8 @@ static int read_distribution_bundle(GetBitContext *gb,
JXLEntropyDecoder *dec,
ret = populate_distribution(gb, >dists[i],
bundle->log_alphabet_size);
if (ret < 0)
return ret;
+if (bundle->dists[i].alphabet_size > (1 <<
bundle->log_alphabet_size))
+return AVERROR_INVALIDDATA;
if (get_bits_left(gb) < 0)
return AVERROR_BUFFER_TOO_SMALL;
}
--
2.43.0
___
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 1/1] avcodec/libjxlenc: Add libjxl_animated encoder
On 12/15/23 16:31, Zsolt Vadász via ffmpeg-devel wrote:
On Friday, December 15th, 2023 at 10:12 PM, Leo Izen wrote:
On 12/15/23 11:40, Zsolt Vadász via ffmpeg-devel wrote:
On Friday, December 15th, 2023 at 12:20 AM, Leo Izen leo.i...@gmail.com wrote:
+ AVFrame *last;
I don't see the purpose of keeping this here.
The name is misleading, I should have named it `previous`, since it always
contains the previous frame.
I did it this way so I could call JxlEncoderCloseInput when the callback
received NULL.
This isn't needed to call JxlEncoderCloseInput, as it takes one
argument, which is JxlEncoder *.
Indeed, but according to the docs[0]:
"If the last frame or last box has been added, JxlEncoderCloseInput,
JxlEncoderCloseFrames
and/or JxlEncoderCloseBoxes must be called before the next
JxlEncoderProcessOutput call,
or the codestream won’t be encoded correctly."
When the encoder eventually receives NULL, there isn't anything left to add,
unless I store the previous frame,
is there?
You can always call JxlEncoderProcessOutput at the start of the loop,
rather than calling it after JxlEncoderAddImageFrame. (Except perhaps
the first loop.)
If you do this, you'll process the frame that was added last loop, and
then you can add another frame. If you receive NULL, you call
JxlEncoderCloseInput at the start of the loop, before you call
JxlEncoderProcessOutput. This saves you from having to store the AVFrame
in memory. libjxl will have a copy of it in memory anyway for reference
purposes so this allows us to reduce memory usage.
+
+ if(!ctx->last && !avctx->internal->draining) { > + ctx->last =
av_frame_clone(frame);
+ *got_packet = 0;
+ return AVERROR(EAGAIN);
It looks like you're trying to emit one packet per image, rather than
one packet per encoded frame. This is fine, but you should not be
calling av_frame_clone, and there's no reason to use
avctx->internal->draining here. If you are doing this, you also have no
reason to cache ctx->last at all.
It's the opposite, I'm trying to emit a packet for each frame of the animation.
Libjxl provides no promise of doing this meaningfully, by the way. You
may end up with arbitrary subdivisions, not subdivisions on frame
boundaries.
Well that's one thing I didn't account for, a real pity. Do you recommend
emitting a
single packet instead?
You can still accomplish what you're trying to do with libjxl but you
need to finesse it a little bit. You need to (1) disable the container
format, as its interaction with Frames is undefined, and you need to (2)
loop calls to JxlEncoderProcessOutput until it returns JXL_ENC_SUCCESS.
The docs specify "This encodes the frames and/or boxes added so far" so
it will end up flushing out the remaining frames if the container format
is disabled.
+const FFCodec ff_libjxl_animated_encoder = {
+ .p.name = "libjxl_animated",
+ CODEC_LONG_NAME("libjxl Animated JPEG XL"),
+ .p.type = AVMEDIA_TYPE_VIDEO,
+ .p.id = AV_CODEC_ID_JPEGXL,
+ .priv_data_size = sizeof(LibJxlEncodeContext),
+ .init = libjxl_animated_encode_init,
+ FF_CODEC_ENCODE_CB(libjxl_animated_encode_frame),
+ .close = libjxl_encode_close,
+ .p.capabilities = AV_CODEC_CAP_OTHER_THREADS |
+ AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
+ AV_CODEC_CAP_DELAY,
+ .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
+ FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP |
+ FF_CODEC_CAP_ICC_PROFILES | FF_CODEC_CAP_EOF_FLUSH,
Why FF_CODEC_CAP_EOF_FLUSH?
So the encoder receives a NULL after the last frame has been submitted,
so JxlEncoderCloseInput can be called and the final frame properly emitted.
Ah, that makes sense, 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".
[0]
https://libjxl.readthedocs.io/en/latest/api_encoder.html#_CPPv423JxlEncoderProcessOutputP10JxlEncoderPP7uint8_tP6size_t
___
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 v2 1/1] avcodec/libjxlenc: Add libjxl_animated encoder
On 12/15/23 11:40, Zsolt Vadász via ffmpeg-devel wrote:
On Friday, December 15th, 2023 at 12:20 AM, Leo Izen wrote:
+ AVFrame *last;
I don't see the purpose of keeping this here.
The name is misleading, I should have named it `previous`, since it always
contains the previous frame.
I did it this way so I could call JxlEncoderCloseInput when the callback
received NULL.
This isn't needed to call JxlEncoderCloseInput, as it takes one
argument, which is JxlEncoder *.
+
+ if(!ctx->last && !avctx->internal->draining) { > + ctx->last =
av_frame_clone(frame);
+ *got_packet = 0;
+ return AVERROR(EAGAIN);
It looks like you're trying to emit one packet per image, rather than
one packet per encoded frame. This is fine, but you should not be
calling av_frame_clone, and there's no reason to use
avctx->internal->draining here. If you are doing this, you also have no
reason to cache ctx->last at all.
It's the opposite, I'm trying to emit a packet for each frame of the animation.
Libjxl provides no promise of doing this meaningfully, by the way. You
may end up with arbitrary subdivisions, not subdivisions on frame
boundaries.
+const FFCodec ff_libjxl_animated_encoder = {
+ .p.name = "libjxl_animated",
+ CODEC_LONG_NAME("libjxl Animated JPEG XL"),
+ .p.type = AVMEDIA_TYPE_VIDEO,
+ .p.id = AV_CODEC_ID_JPEGXL,
+ .priv_data_size = sizeof(LibJxlEncodeContext),
+ .init = libjxl_animated_encode_init,
+ FF_CODEC_ENCODE_CB(libjxl_animated_encode_frame),
+ .close = libjxl_encode_close,
+ .p.capabilities = AV_CODEC_CAP_OTHER_THREADS |
+ AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
+ AV_CODEC_CAP_DELAY,
+ .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
+ FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP |
+ FF_CODEC_CAP_ICC_PROFILES | FF_CODEC_CAP_EOF_FLUSH,
Why FF_CODEC_CAP_EOF_FLUSH?
So the encoder receives a NULL after the last frame has been submitted,
so JxlEncoderCloseInput can be called and the final frame properly emitted.
Ah, that makes sense, 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".
[FFmpeg-devel] [PATCH v2] avcodec/libjxldec: emit proper PTS to decoded AVFrame
If a sequence of JXL images is encapsulated in a container that has PTS
information, we should use the PTS information from the container. At
this time there is no container that does this, but if JPEG XL support
is ever added to NUT, AVTransport, or some other container, this commit
should allow the PTS information those containers provide to work as
expected.
Signed-off-by: Leo Izen
---
libavcodec/libjxldec.c | 57 +-
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
index 002740d9c1..6e630fb1b0 100644
--- a/libavcodec/libjxldec.c
+++ b/libavcodec/libjxldec.c
@@ -54,10 +54,10 @@ typedef struct LibJxlDecodeContext {
JxlDecoderStatus events;
AVBufferRef *iccp;
AVPacket *avpkt;
-int64_t pts;
+int64_t accumulated_pts;
int64_t frame_duration;
int prev_is_last;
-AVRational timebase;
+AVRational anim_timebase;
AVFrame *frame;
} LibJxlDecodeContext;
@@ -80,7 +80,6 @@ static int libjxl_init_jxl_decoder(AVCodecContext *avctx)
memset(>basic_info, 0, sizeof(JxlBasicInfo));
memset(>jxl_pixfmt, 0, sizeof(JxlPixelFormat));
ctx->prev_is_last = 1;
-ctx->frame_duration = 1;
return 0;
}
@@ -104,7 +103,6 @@ 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);
@@ -370,12 +368,15 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
while (1) {
size_t remaining;
+JxlFrameHeader header;
if (!pkt->size) {
av_packet_unref(pkt);
ret = ff_decode_get_packet(avctx, pkt);
if (ret < 0 && ret != AVERROR_EOF)
return ret;
+ctx->accumulated_pts = 0;
+ctx->frame_duration = 0;
if (!pkt->size) {
/* jret set by the last iteration of the loop */
if (jret == JXL_DEC_NEED_MORE_INPUT) {
@@ -429,12 +430,8 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
if ((ret = ff_set_dimensions(avctx, ctx->basic_info.xsize,
ctx->basic_info.ysize)) < 0)
return ret;
if (ctx->basic_info.have_animation)
-ctx->timebase =
av_make_q(ctx->basic_info.animation.tps_denominator,
-
ctx->basic_info.animation.tps_numerator);
-else if (avctx->pkt_timebase.num)
-ctx->timebase = avctx->pkt_timebase;
-else
-ctx->timebase = AV_TIME_BASE_Q;
+ctx->anim_timebase =
av_make_q(ctx->basic_info.animation.tps_denominator,
+
ctx->basic_info.animation.tps_numerator);
continue;
case JXL_DEC_COLOR_ENCODING:
av_log(avctx, AV_LOG_DEBUG, "COLOR_ENCODING event emitted\n");
@@ -462,23 +459,24 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
#endif
continue;
case JXL_DEC_FRAME:
+/* Frame here refers to the Frame bundle, not a decoded picture */
av_log(avctx, AV_LOG_DEBUG, "FRAME event emitted\n");
-if (!ctx->basic_info.have_animation || ctx->prev_is_last) {
+if (ctx->prev_is_last) {
+/*
+ * The last frame sent was tagged as "is_last" which
+ * means this is a new image file altogether.
+ */
ctx->frame->pict_type = AV_PICTURE_TYPE_I;
ctx->frame->flags |= AV_FRAME_FLAG_KEY;
}
-if (ctx->basic_info.have_animation) {
-JxlFrameHeader header;
-if (JxlDecoderGetFrameHeader(ctx->decoder, ) !=
JXL_DEC_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Bad libjxl dec frame
event\n");
-return AVERROR_EXTERNAL;
-}
-ctx->prev_is_last = header.is_last;
-ctx->frame_duration = header.duration;
-} else {
-ctx->prev_is_last = 1;
-ctx->frame_duration = 1;
+if (JxlDecoderGetFrameHeader(ctx->decoder, ) !=
JXL_DEC_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Bad libjxl dec frame event\n");
+return AVERROR_EXTERNAL;
}
+ctx->prev_is_last = header.is_last;
+/* zero duration for animation means the frame is not presented */
+if (ctx->basic_info.have_animation && header.duration)
+ctx->frame_duration = header.duration;
Re: [FFmpeg-devel] [PATCH] avcodec/libjxldec: emit proper PTS to decoded AVFrame
On 12/14/23 03:28, Anton Khirnov wrote:
Quoting Leo Izen (2023-12-08 18:31:06)
If a sequence of JXL images is encapsulated in a container that has PTS
information, we should use the PTS information from the container. At
this time there is no container that does this, but if JPEG XL support
is ever added to NUT, AVTransport, or some other container, this commit
should allow the PTS information those containers provide to work as
expected.
Signed-off-by: Leo Izen
---
libavcodec/libjxldec.c | 77 +++---
1 file changed, 57 insertions(+), 20 deletions(-)
diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
index 002740d9c1..494060ac8c 100644
--- a/libavcodec/libjxldec.c
+++ b/libavcodec/libjxldec.c
@@ -370,6 +370,7 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
while (1) {
size_t remaining;
+JxlFrameHeader header;
if (!pkt->size) {
av_packet_unref(pkt);
@@ -428,13 +429,16 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
}
if ((ret = ff_set_dimensions(avctx, ctx->basic_info.xsize,
ctx->basic_info.ysize)) < 0)
return ret;
+/*
+ * If animation is present, we use the timebase provided by
+ *the animated image itself.
+ * If the image is not animated, we use ctx->pts
+ *to refer to the frame number, not an actual
+ *PTS value, thus we may leave ctx->timebase unset.
+ */
if (ctx->basic_info.have_animation)
ctx->timebase =
av_make_q(ctx->basic_info.animation.tps_denominator,
ctx->basic_info.animation.tps_numerator);
-else if (avctx->pkt_timebase.num)
-ctx->timebase = avctx->pkt_timebase;
-else
-ctx->timebase = AV_TIME_BASE_Q;
continue;
case JXL_DEC_COLOR_ENCODING:
av_log(avctx, AV_LOG_DEBUG, "COLOR_ENCODING event emitted\n");
@@ -462,23 +466,24 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
#endif
continue;
case JXL_DEC_FRAME:
+/* Frame here refers to the Frame bundle, not a decoded picture */
av_log(avctx, AV_LOG_DEBUG, "FRAME event emitted\n");
-if (!ctx->basic_info.have_animation || ctx->prev_is_last) {
+if (ctx->prev_is_last) {
+/*
+ * The last frame sent was tagged as "is_last" which
+ * means this is a new image file altogether.
+ */
ctx->frame->pict_type = AV_PICTURE_TYPE_I;
ctx->frame->flags |= AV_FRAME_FLAG_KEY;
}
-if (ctx->basic_info.have_animation) {
-JxlFrameHeader header;
-if (JxlDecoderGetFrameHeader(ctx->decoder, ) !=
JXL_DEC_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Bad libjxl dec frame
event\n");
-return AVERROR_EXTERNAL;
-}
-ctx->prev_is_last = header.is_last;
-ctx->frame_duration = header.duration;
-} else {
-ctx->prev_is_last = 1;
-ctx->frame_duration = 1;
+if (JxlDecoderGetFrameHeader(ctx->decoder, ) !=
JXL_DEC_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Bad libjxl dec frame event\n");
+return AVERROR_EXTERNAL;
}
+ctx->prev_is_last = header.is_last;
+/* zero duration for animation means the frame is not presented */
+if (ctx->basic_info.have_animation && header.duration)
+ctx->frame_duration = header.duration;
continue;
case JXL_DEC_FULL_IMAGE:
/* full image is one frame, even if animated */
@@ -490,12 +495,44 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
/* ownership is transfered, and it is not ref-ed */
ctx->iccp = NULL;
}
-if (avctx->pkt_timebase.num) {
-ctx->frame->pts = av_rescale_q(ctx->pts, ctx->timebase,
avctx->pkt_timebase);
-ctx->frame->duration = av_rescale_q(ctx->frame_duration,
ctx->timebase, avctx->pkt_timebase);
+if (ctx->basic_info.have_animation) {
+if (avctx->pkt_timebase.num) {
+/*
+ * ideally, the demuxer set avctx->pkt_timebase to equal
the animation's timebase
+ * or something strictly finer. This is true about the
jpegxl_anim demuxer.
+ */
+
Re: [FFmpeg-devel] [PATCH v2 1/1] avcodec/libjxlenc: Add libjxl_animated encoder
On 12/13/23 15:53, Zsolt Vadász via ffmpeg-devel wrote:
---
configure | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libjxlenc.c | 214 +
3 files changed, 177 insertions(+), 39 deletions(-)
diff --git a/configure b/configure
index 7d2ee66000..a334a9b1e0 100755
--- a/configure
+++ b/configure
@@ -3418,6 +3418,7 @@ libilbc_decoder_deps="libilbc"
libilbc_encoder_deps="libilbc"
libjxl_decoder_deps="libjxl libjxl_threads"
libjxl_encoder_deps="libjxl libjxl_threads"
+libjxl_animated_encoder_deps="libjxl libjxl_threads"
libkvazaar_encoder_deps="libkvazaar"
libmodplug_demuxer_deps="libmodplug"
libmp3lame_encoder_deps="libmp3lame"
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b0f004e15c..e6733b0d4f 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -784,6 +784,7 @@ extern const FFCodec ff_libilbc_encoder;
extern const FFCodec ff_libilbc_decoder;
extern const FFCodec ff_libjxl_decoder;
extern const FFCodec ff_libjxl_encoder;
+extern const FFCodec ff_libjxl_animated_encoder;
This should be called libjxl_anim for consistency. Compare with
libwebp_anim and jpegxl_anim demuxer.
extern const FFCodec ff_libmp3lame_encoder;
extern const FFCodec ff_libopencore_amrnb_encoder;
extern const FFCodec ff_libopencore_amrnb_decoder;
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index d707f3a61b..bf44307a34 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -39,6 +39,7 @@
#include "avcodec.h"
#include "encode.h"
#include "codec_internal.h"
+#include "internal.h"
#include
#include
@@ -49,11 +50,15 @@ typedef struct LibJxlEncodeContext {
void *runner;
JxlEncoder *encoder;
JxlEncoderFrameSettings *options;
+JxlPixelFormat jxl_fmt;
int effort;
float distance;
int modular;
uint8_t *buffer;
size_t buffer_size;
+/* Only used by libjxl_animated */
+int animated;
It's not actually true that ctx->animated is only used by libjxl_anim
because it's checked by the standard encoder as well.
+AVFrame *last;
I don't see the purpose of keeping this here.
} LibJxlEncodeContext;
/**
@@ -183,6 +188,8 @@ static av_cold int libjxl_encode_init(AVCodecContext *avctx)
return AVERROR(ENOMEM);
}
+ctx->animated = 0;
+
return 0;
}
@@ -237,28 +244,19 @@ static int libjxl_populate_primaries(void *avctx, JxlColorEncoding *jxl_color, e
return 0;
}
-/**
- * Encode an entire frame. Currently animation, is not supported by
- * this encoder, so this will always reinitialize a new still image
- * and encode a one-frame image (for image2 and image2pipe).
- */
-static int libjxl_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const
AVFrame *frame, int *got_packet)
+static int libjxl_encode_init_image(AVCodecContext *avctx, const AVFrame
*frame)
{
LibJxlEncodeContext *ctx = avctx->priv_data;
AVFrameSideData *sd;
const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(frame->format);
JxlBasicInfo info;
JxlColorEncoding jxl_color;
-JxlPixelFormat jxl_fmt;
+JxlPixelFormat *jxl_fmt = >jxl_fmt;
int bits_per_sample;
#if JPEGXL_NUMERIC_VERSION >= JPEGXL_COMPUTE_NUMERIC_VERSION(0, 8, 0)
JxlBitDepth jxl_bit_depth;
#endif
-JxlEncoderStatus jret;
int ret;
-size_t available = ctx->buffer_size;
-size_t bytes_written = 0;
-uint8_t *next_out = ctx->buffer;
ret = libjxl_init_jxl_encoder(avctx);
if (ret) {
@@ -268,23 +266,30 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
/* populate the basic info settings */
JxlEncoderInitBasicInfo();
-jxl_fmt.num_channels = pix_desc->nb_components;
+jxl_fmt->num_channels = pix_desc->nb_components;
info.xsize = frame->width;
info.ysize = frame->height;
-info.num_extra_channels = (jxl_fmt.num_channels + 1) % 2;
-info.num_color_channels = jxl_fmt.num_channels - info.num_extra_channels;
-bits_per_sample = av_get_bits_per_pixel(pix_desc) / jxl_fmt.num_channels;
+info.num_extra_channels = (jxl_fmt->num_channels + 1) % 2;
+info.num_color_channels = jxl_fmt->num_channels - info.num_extra_channels;
+bits_per_sample = av_get_bits_per_pixel(pix_desc) / jxl_fmt->num_channels;
info.bits_per_sample = avctx->bits_per_raw_sample > 0 && !(pix_desc->flags
& AV_PIX_FMT_FLAG_FLOAT)
? avctx->bits_per_raw_sample : bits_per_sample;
info.alpha_bits = (info.num_extra_channels > 0) * info.bits_per_sample;
if (pix_desc->flags & AV_PIX_FMT_FLAG_FLOAT) {
info.exponent_bits_per_sample = info.bits_per_sample > 16 ? 8 : 5;
info.alpha_exponent_bits = info.alpha_bits ?
info.exponent_bits_per_sample : 0;
-jxl_fmt.data_type = info.bits_per_sample > 16 ? JXL_TYPE_FLOAT :
JXL_TYPE_FLOAT16;
+
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/libjxlenc: Move image initialization code into libjxl_encode_init_image
On 12/11/23 12:05, Zsolt Vadász via ffmpeg-devel wrote: --- libavcodec/libjxlenc.c | 69 +++--- 1 file changed, 45 insertions(+), 24 deletions(-) diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c index 92a458d51a..6110c42a7c 100644 --- a/libavcodec/libjxlenc.c +++ b/libavcodec/libjxlenc.c If this is necessary for adding an animated encoder it needs to be in the commit, because this commit by itself doesn't do anything. - Leo Izen (Traneptora) ___ 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/libjxlenc: Move JxlBasicInfo to LibJxlEncodeContext
On 12/11/23 12:05, Zsolt Vadász via ffmpeg-devel wrote: --- libavcodec/libjxlenc.c | 45 +- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c index d707f3a61b..92a458d51a 100644 Why? ___ 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/pngdec: improve handling of bad cICP range tags
FFmpeg doesn't support tv-range RGB throughout most of its pipeline, so
we should keep the warning. However, in case something does support it
we should at least keep it tagged properly. Additionally, the encoder
writes this tag if the space is tagged as such so this makes a round
trip work as it should.
Also, PNG doesn't support nonzero matrices but we only warn and ignore
in that case, so we have no reason to error out for illegal cICP ranges
either (i.e. greater than 1).
Signed-off-by: Leo Izen
Reported-by: Kacper Michajłow
---
libavcodec/pngdec.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index d812ffd348..d1aae4c70e 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -661,8 +661,13 @@ static int populate_avctx_color_fields(AVCodecContext
*avctx, AVFrame *frame)
av_log(avctx, AV_LOG_WARNING, "unrecognized cICP transfer\n");
else
avctx->color_trc = frame->color_trc = s->cicp_trc;
-if (s->cicp_range == 0)
-av_log(avctx, AV_LOG_WARNING, "unsupported tv-range cICP chunk\n");
+if (s->cicp_range == 0) {
+av_log(avctx, AV_LOG_WARNING, "tv-range cICP tag found. Colors may
be wrong\n");
+avctx->color_range = frame->color_range = AVCOL_RANGE_MPEG;
+} else if (s->cicp_range != 1) {
+/* we already printed a warning when parsing the cICP chunk */
+avctx->color_range = frame->color_range = AVCOL_RANGE_UNSPECIFIED;
+}
} else if (s->iccp_data) {
AVFrameSideData *sd = av_frame_new_side_data(frame,
AV_FRAME_DATA_ICC_PROFILE, s->iccp_data_len);
if (!sd)
@@ -713,9 +718,10 @@ static int populate_avctx_color_fields(AVCodecContext
*avctx, AVFrame *frame)
avctx->color_trc = frame->color_trc = AVCOL_TRC_LINEAR;
}
-/* we only support pc-range RGB */
+/* PNG only supports RGB */
avctx->colorspace = frame->colorspace = AVCOL_SPC_RGB;
-avctx->color_range = frame->color_range = AVCOL_RANGE_JPEG;
+if (!s->have_cicp || s->cicp_range == 1)
+avctx->color_range = frame->color_range = AVCOL_RANGE_JPEG;
/*
* tRNS sets alpha depth to full, so we ignore sBIT if set.
@@ -1455,11 +1461,8 @@ static int decode_frame_common(AVCodecContext *avctx,
PNGDecContext *s,
if (bytestream2_get_byte(_chunk) != 0)
av_log(avctx, AV_LOG_WARNING, "nonzero cICP matrix\n");
s->cicp_range = bytestream2_get_byte(_chunk);
-if (s->cicp_range != 0 && s->cicp_range != 1) {
-av_log(avctx, AV_LOG_ERROR, "invalid cICP range: %d\n",
s->cicp_range);
-ret = AVERROR_INVALIDDATA;
-goto fail;
-}
+if (s->cicp_range != 0 && s->cicp_range != 1)
+av_log(avctx, AV_LOG_WARNING, "invalid cICP range: %d\n",
s->cicp_range);
s->have_cicp = 1;
break;
case MKTAG('s', 'R', 'G', 'B'):
@@ -1814,8 +1817,6 @@ static av_cold int png_dec_init(AVCodecContext *avctx)
{
PNGDecContext *s = avctx->priv_data;
-avctx->color_range = AVCOL_RANGE_JPEG;
-
s->avctx = avctx;
s->last_picture.f = av_frame_alloc();
s->picture.f = av_frame_alloc();
--
2.43.0
___
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 2/2] avcodec/libjxlenc: accept rgbf32 and rgbaf32 frames
These pixel formats have always been supported by libjxl, but at the
time this plugin was written, they were not in FFmpeg yet. Now that
they are in FFmpeg, we should support them.
Signed-off-by: Leo Izen
---
libavcodec/libjxlenc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index d707f3a61b..780dbb9e2e 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -493,6 +493,7 @@ const FFCodec ff_libjxl_encoder = {
.p.pix_fmts = (const enum AVPixelFormat[]) {
AV_PIX_FMT_RGB24, AV_PIX_FMT_RGBA,
AV_PIX_FMT_RGB48, AV_PIX_FMT_RGBA64,
+AV_PIX_FMT_RGBF32, AV_PIX_FMT_RGBAF32,
AV_PIX_FMT_GRAY8, AV_PIX_FMT_YA8,
AV_PIX_FMT_GRAY16, AV_PIX_FMT_YA16,
AV_PIX_FMT_GRAYF32,
--
2.43.0
___
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 1/2] avcodec/libjxldec: produce rgbf32 and rgbaf32 frames
These pixel formats have always been supported by libjxl, but at the
time this plugin was written, they were not in FFmpeg yet. Now that
they are in FFmpeg, we should support them.
Signed-off-by: Leo Izen
---
libavcodec/libjxldec.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
index 494060ac8c..f763294eee 100644
--- a/libavcodec/libjxldec.c
+++ b/libavcodec/libjxldec.c
@@ -130,10 +130,11 @@ static enum AVPixelFormat
libjxl_get_pix_fmt(AVCodecContext *avctx, LibJxlDecode
return basic_info->alpha_bits ? AV_PIX_FMT_YA8 : AV_PIX_FMT_GRAY8;
}
if (basic_info->exponent_bits_per_sample ||
basic_info->bits_per_sample > 16) {
-if (basic_info->alpha_bits)
-return AV_PIX_FMT_NONE;
-format->data_type = JXL_TYPE_FLOAT;
-return AV_PIX_FMT_GRAYF32;
+if (!basic_info->alpha_bits) {
+format->data_type = JXL_TYPE_FLOAT;
+return AV_PIX_FMT_GRAYF32;
+}
+av_log(avctx, AV_LOG_WARNING, "Downsampling gray+alpha float to
16-bit integer via libjxl\n");
}
format->data_type = JXL_TYPE_UINT16;
return basic_info->alpha_bits ? AV_PIX_FMT_YA16 : AV_PIX_FMT_GRAY16;
@@ -145,10 +146,10 @@ static enum AVPixelFormat
libjxl_get_pix_fmt(AVCodecContext *avctx, LibJxlDecode
format->data_type = JXL_TYPE_UINT8;
return basic_info->alpha_bits ? AV_PIX_FMT_RGBA : AV_PIX_FMT_RGB24;
}
-if (basic_info->exponent_bits_per_sample)
-av_log(avctx, AV_LOG_WARNING, "Downsampling float to 16-bit
integer via libjxl\n");
-else if (basic_info->bits_per_sample > 16)
-av_log(avctx, AV_LOG_WARNING, "Downsampling larger integer to
16-bit via libjxl\n");
+if (basic_info->exponent_bits_per_sample ||
basic_info->bits_per_sample > 16) {
+format->data_type = JXL_TYPE_FLOAT;
+return basic_info->alpha_bits ? AV_PIX_FMT_RGBAF32 :
AV_PIX_FMT_RGBF32;
+}
format->data_type = JXL_TYPE_UINT16;
return basic_info->alpha_bits ? AV_PIX_FMT_RGBA64 : AV_PIX_FMT_RGB48;
}
--
2.43.0
___
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] avcodec/pngdec: read colorspace info when decoding with AVDISCARD_ALL
On 12/10/23 23:20, Kacper Michajlow wrote: On Tue, 28 Feb 2023 at 20:46, Leo Izen wrote: On 2/27/23 11:34, Leo Izen wrote: On 2/21/23 17:35, Leo Izen wrote: These chunks are lightweight and it's useful information to have when running ffmpeg -i or ffprobe, for example. --- libavcodec/pngdec.c | 136 ++- tests/ref/fate/png-icc | 8 +-- tests/ref/fate/png-side-data | 2 +- 3 files changed, 91 insertions(+), 55 deletions(-) diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c I will push this soon-ish if there's no other objections. - Leo Izen (thebombzen) Pushed as fadfa147f812a3fe9e68723347d37b9cccd6222d. Hi, Sorry for digging this old patch, but I'm curious. What does "unsupported tv-range cICP chunk\n" and "we only support pc-range RGB" mean? Before this patch the range was properly set: avctx->color_range = f->color_range = s->cicp_range == 0 ? AVCOL_RANGE_MPEG : AVCOL_RANGE_JPEG; Now it is ignored with a warning. Neither commit message, nor the comments in the code explain why the cICP range is now ignored in the decoder and the frames are no longer tagged with proper color range. It means FFmpeg itself doesn't support tv-range RGB. The PNG format supports it but FFmpeg does not. Since the PNG spec specifies the matrix must equal zero (aka RGB), we can't support tv-range here and print a warning. - Leo Izen (Traneptora) ___ 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 0/1] fate/jpegxl: add multiframe permuted TOC image parser
On 12/10/23 09:07, Andreas Rheinhardt wrote: Leo Izen: This patch requires a sample that hasn't been uploaded yet. It can be found at [1] and it should be placed at jxl/orange.jxl once uploaded. It's 262k, which is not very large, but large enough that I did not want to attach it to this email. [1]: https://buzo.us/O.jxl sample sha256sum: 9288337dc0d37effd1f539d4e20083a8ffed757e486f4098121520c74e8de6f6 sample signature: https://buzo.us/A.asc Leo Izen (1): fate/jpegxl: add multiframe permuted TOC image parser test tests/fate/jxl.mak | 3 +++ tests/ref/fate/jxl-multiframe-permuted-toc | 11 +++ 2 files changed, 14 insertions(+) create mode 100644 tests/ref/fate/jxl-multiframe-permuted-toc I disagree with your assertion that 262k is not very large. Why do you use a 2400x2400 sample? It had to be larger than 2048x2048 to have multiple LF groups in a single frame, as that's the LF group size. The images themselves are monochrome. - Leo Izen (Traneptora) ___ 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] doc/bitstream_filters: add filter_units practical examples for removing closed captions
On 12/9/23 20:35, Marth64 wrote: --- doc/bitstream_filters.texi | 18 ++ 1 file changed, 18 insertions(+) Make sure when you generate the second version of a patch with git format-patch you pass the -v2 argument, e.g. git format-patch -v2 -o outgoing/ master Otherwise it can get a little bit difficult for reviewers to track the versions. I have no comments on the patch itself, in either direction. - Leo Izen (Traneptora) ___ 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] [WIP] [RFC] dvdvideo: initial contribution (DVD demuxer)
On 12/9/23 05:06, Marth64 wrote:
Hello, I am happy to share a DVD demuxer for ffmpeg powered by libdvdread and
libdvdnav.
I have been working on this on/off throughout the year and think it is in a
good spot
to share at the ML now. This was a major learning experience for me in many
ways and
am open to any feedback on how I could improve it to be better. In fact, there
is still
one issue I can't seem to figure out how to solve (in discussion below).
Regardless,
a good number of DVDs I have tried seem to work out of the box. This is a
full-service
demuxer with chapters, subtitles (and their palettes), as well as language
metadata.
At a high level, the demuxer uses libdvdread for metadata of the disc,
libdvdnav for
the actual playback, and the MPEG-PS demuxer for the underlying VOB stream.
First, the basic usage, is quite straightforward:
ffmpeg -f dvdvideo -title NN -i DVD.iso|/dev/srX|/path/to/DVD ...
Where NN can be replaced by your known title number in the disc
As the demuxer effectively works at a PGC level, multi-PGC titles are not
supported.
But to provide this flexibility as there are many weirdly authored DVDs out
there,
one can specify an exact PGC via -pgc option and an associated program (PG, can
start at 1).
I am hoping and willing to improve this to be a robust demuxer wherever
possible, but to
that extent there is still an issue I can't figure out how to solve: Dealing
with DTS discontinuities
and PTS generation.
Right now, as a band-aid, I am adding AVFMT_FLAG_GENPTS (line 1408)
to the MPEG-PS subdemuxer. This works with most discs and the output seems OK.
On discs with discontinuities, however,
this causes the demuxing to hang which is obviously unacceptable also. Removing
the flag causes the discs
to not hang, but then the output for all discs becomes choppy for obvious
reasons (invalid PTS).
It could be because I have some misunderstandings on how things work within
ffmpeg,
but I have tried to the point now where I thought it best to ask the experts
for help if you can spot
what I am doing wrong. I am really motivated to make this work and good quality.
Thank you!
---
configure |8 +
libavformat/Makefile |1 +
libavformat/allformats.c |1 +
libavformat/avlanguage.c | 10 +-
libavformat/dvdvideodec.c | 1599 +
5 files changed, 1617 insertions(+), 2 deletions(-)
create mode 100644 libavformat/dvdvideodec.c
diff --git a/configure b/configure
index d77c053226..65e5968194 100755
--- a/configure
+++ b/configure
@@ -227,6 +227,8 @@ External library support:
--enable-libdavs2enable AVS2 decoding via libdavs2 [no]
--enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
and libraw1394 [no]
+ --enable-libdvdnav enable libdvdnav, needed for DVD demuxing [no]
+ --enable-libdvdread enable libdvdread, needed for DVD demuxing [no]
Why do you need both of these? libdvdnav depends on libdvdread.
--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
--enable-libfliteenable flite (voice synthesis) support via
libflite [no]
--enable-libfontconfig enable libfontconfig, useful for drawtext filter
[no]
@@ -1802,6 +1804,8 @@ EXTERNAL_LIBRARY_GPL_LIST="
frei0r
libcdio
libdavs2
+libdvdnav
+libdvdread
librubberband
libvidstab
libx264
@@ -3494,6 +3498,8 @@ dts_demuxer_select="dca_parser"
dtshd_demuxer_select="dca_parser"
dv_demuxer_select="dvprofile"
dv_muxer_select="dvprofile"
+dvdvideo_demuxer_select="mpegps_demuxer"
+dvdvideo_demuxer_deps="libdvdnav libdvdread"
dxa_demuxer_select="riffdec"
eac3_demuxer_select="ac3_parser"
evc_demuxer_select="evc_frame_merge_bsf evc_parser"
@@ -6723,6 +6729,8 @@ enabled libdav1d && require_pkg_config libdav1d "dav1d >=
0.5.0" "dav1d
enabled libdavs2 && require_pkg_config libdavs2 "davs2 >= 1.6.0"
davs2.h davs2_decoder_open
enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2
dc1394/dc1394.h dc1394_new
enabled libdrm&& require_pkg_config libdrm libdrm xf86drm.h
drmGetVersion
+enabled libdvdnav && require_pkg_config libdvdnav "dvdnav >= 6.1.1"
dvdnav/dvdnav.h dvdnav_open2
+enabled libdvdread&& require_pkg_config libdvdread "dvdread >= 6.1.2"
dvdread/dvd_reader.h DVDOpen2 -ldvdread
enabled libfdk_aac&& { check_pkg_config libfdk_aac fdk-aac
"fdk-aac/aacenc_lib.h" aacEncOpen ||
{ require libfdk_aac fdk-aac/aacenc_lib.h aacEncOpen
-lfdk-aac &&
warn "using libfdk without pkg-config"; } }
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2db83aff81..45dba53044 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -192,6 +192,7 @@ OBJS-$(CONFIG_DTS_MUXER) += rawenc.o
OBJS-$(CONFIG_DV_MUXER) += dvenc.o
[FFmpeg-devel] [PATCH 1/1] fate/jpegxl: add multiframe permuted TOC image parser test
This test verifies the parser's handling of multiframe JXL files that have an entropy-encoded permuted table of contents for each frame. The testcase is actually six JXL codestreams concatenated together, and the parser needs to be able to find the boundaries. Signed-off-by: Leo Izen --- tests/fate/jxl.mak | 3 +++ tests/ref/fate/jxl-multiframe-permuted-toc | 11 +++ 2 files changed, 14 insertions(+) create mode 100644 tests/ref/fate/jxl-multiframe-permuted-toc diff --git a/tests/fate/jxl.mak b/tests/fate/jxl.mak index d653eb644a..1416b98f6d 100644 --- a/tests/fate/jxl.mak +++ b/tests/fate/jxl.mak @@ -19,6 +19,9 @@ fate-jxl-anim-demux: $(FATE_JPEGXL_ANIM_DEMUX) FATE_JPEGXL_PARSE += fate-jxl-small-ext-box fate-jxl-small-ext-box: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/l.jxl -c copy +FATE_JPEGXL_PARSE += fate-jxl-multiframe-permuted-toc +fate-jxl-multiframe-permuted-toc: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/orange.jxl -c copy + FATE_JPEGXL_PARSE += $(FATE_JPEGXL_PARSE-yes) FATE_SAMPLES_FFMPEG-$(call FRAMECRC, IMAGE_JPEGXL_PIPE, , JPEGXL_PARSER) += $(FATE_JPEGXL_PARSE) fate-jxl-parse: $(FATE_JPEGXL_PARSE) diff --git a/tests/ref/fate/jxl-multiframe-permuted-toc b/tests/ref/fate/jxl-multiframe-permuted-toc new file mode 100644 index 00..94fc008143 --- /dev/null +++ b/tests/ref/fate/jxl-multiframe-permuted-toc @@ -0,0 +1,11 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: jpegxl +#dimensions 0: 2400x2400 +#sar 0: 0/1 +0, 0, 0,1, 197602, 0x6f8fc984 +0, 1, 1,1,52335, 0x30421469 +0, 2, 2,1,20784, 0xaecb1df0 +0, 3, 3,1,11204, 0x6c7b0759 +0, 4, 4,1, 5653, 0xa2ac56da +0, 5, 5,1,11204, 0x6c7b0759 -- 2.43.0 ___ 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 0/1] fate/jpegxl: add multiframe permuted TOC image parser
This patch requires a sample that hasn't been uploaded yet. It can be found at [1] and it should be placed at jxl/orange.jxl once uploaded. It's 262k, which is not very large, but large enough that I did not want to attach it to this email. [1]: https://buzo.us/O.jxl sample sha256sum: 9288337dc0d37effd1f539d4e20083a8ffed757e486f4098121520c74e8de6f6 sample signature: https://buzo.us/A.asc Leo Izen (1): fate/jpegxl: add multiframe permuted TOC image parser test tests/fate/jxl.mak | 3 +++ tests/ref/fate/jxl-multiframe-permuted-toc | 11 +++ 2 files changed, 14 insertions(+) create mode 100644 tests/ref/fate/jxl-multiframe-permuted-toc -- 2.43.0 ___ 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/libjxldec: emit proper PTS to decoded AVFrame
If a sequence of JXL images is encapsulated in a container that has PTS
information, we should use the PTS information from the container. At
this time there is no container that does this, but if JPEG XL support
is ever added to NUT, AVTransport, or some other container, this commit
should allow the PTS information those containers provide to work as
expected.
Signed-off-by: Leo Izen
---
libavcodec/libjxldec.c | 77 +++---
1 file changed, 57 insertions(+), 20 deletions(-)
diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
index 002740d9c1..494060ac8c 100644
--- a/libavcodec/libjxldec.c
+++ b/libavcodec/libjxldec.c
@@ -370,6 +370,7 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
while (1) {
size_t remaining;
+JxlFrameHeader header;
if (!pkt->size) {
av_packet_unref(pkt);
@@ -428,13 +429,16 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
}
if ((ret = ff_set_dimensions(avctx, ctx->basic_info.xsize,
ctx->basic_info.ysize)) < 0)
return ret;
+/*
+ * If animation is present, we use the timebase provided by
+ *the animated image itself.
+ * If the image is not animated, we use ctx->pts
+ *to refer to the frame number, not an actual
+ *PTS value, thus we may leave ctx->timebase unset.
+ */
if (ctx->basic_info.have_animation)
ctx->timebase =
av_make_q(ctx->basic_info.animation.tps_denominator,
ctx->basic_info.animation.tps_numerator);
-else if (avctx->pkt_timebase.num)
-ctx->timebase = avctx->pkt_timebase;
-else
-ctx->timebase = AV_TIME_BASE_Q;
continue;
case JXL_DEC_COLOR_ENCODING:
av_log(avctx, AV_LOG_DEBUG, "COLOR_ENCODING event emitted\n");
@@ -462,23 +466,24 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
#endif
continue;
case JXL_DEC_FRAME:
+/* Frame here refers to the Frame bundle, not a decoded picture */
av_log(avctx, AV_LOG_DEBUG, "FRAME event emitted\n");
-if (!ctx->basic_info.have_animation || ctx->prev_is_last) {
+if (ctx->prev_is_last) {
+/*
+ * The last frame sent was tagged as "is_last" which
+ * means this is a new image file altogether.
+ */
ctx->frame->pict_type = AV_PICTURE_TYPE_I;
ctx->frame->flags |= AV_FRAME_FLAG_KEY;
}
-if (ctx->basic_info.have_animation) {
-JxlFrameHeader header;
-if (JxlDecoderGetFrameHeader(ctx->decoder, ) !=
JXL_DEC_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Bad libjxl dec frame
event\n");
-return AVERROR_EXTERNAL;
-}
-ctx->prev_is_last = header.is_last;
-ctx->frame_duration = header.duration;
-} else {
-ctx->prev_is_last = 1;
-ctx->frame_duration = 1;
+if (JxlDecoderGetFrameHeader(ctx->decoder, ) !=
JXL_DEC_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Bad libjxl dec frame event\n");
+return AVERROR_EXTERNAL;
}
+ctx->prev_is_last = header.is_last;
+/* zero duration for animation means the frame is not presented */
+if (ctx->basic_info.have_animation && header.duration)
+ctx->frame_duration = header.duration;
continue;
case JXL_DEC_FULL_IMAGE:
/* full image is one frame, even if animated */
@@ -490,12 +495,44 @@ static int libjxl_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
/* ownership is transfered, and it is not ref-ed */
ctx->iccp = NULL;
}
-if (avctx->pkt_timebase.num) {
-ctx->frame->pts = av_rescale_q(ctx->pts, ctx->timebase,
avctx->pkt_timebase);
-ctx->frame->duration = av_rescale_q(ctx->frame_duration,
ctx->timebase, avctx->pkt_timebase);
+if (ctx->basic_info.have_animation) {
+if (avctx->pkt_timebase.num) {
+/*
+ * ideally, the demuxer set avctx->pkt_timebase to equal
the animation's timebase
+ * or something strictly finer. This is true about the
jpegxl_anim demuxer.
+ */
+ctx->frame->pts = av_rescale_q(ctx->pts, ctx->timebase,
avctx->pkt_timebase);
+
Re: [FFmpeg-devel] [PATCH v3] avformat/hls: use av_strlcopy instead of strncpy
On 11/23/23 10:31, Leo Izen wrote: Avoids a -Wstringop-truncation warning by using av_strlcopy instead of strncpy. Additionally, prints a warning to the log context if this truncation occurred. Signed-off-by: Leo Izen --- Bump, thanks. - Leo Izen (Traneptora) ___ 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] MAINTAINERS: remove myself from FFmpeg
On 12/7/23 11:32, Nicolas George wrote: Leo Izen (12023-12-07): I believe the question was directed at Paul That does not make my answer any less relevant. I'm not going to have an argument with you about why a question to Paul about a decision Paul made should be answered by Paul, considering that he is the only one who can read his own thoughts. When you reply to this email with some off-topic paragraph about something something Libav something something, I'm not going to respond. - Leo Izen (Traneptora) ___ 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] MAINTAINERS: remove myself from FFmpeg
On 12/7/23 03:59, Nicolas George wrote: Jean-Baptiste Kempf (12023-12-07): Why? Because after twelve years libav has finally managed to take control and FFmpeg is now essentially dead. Thank you for your contribution in this. I believe the question was directed at Paul, who has not answered yet (as of writing this). - Leo Izen (Traneptora) ___ 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 0/3] JPEG XL parser bug fixes
On 11/27/23 09:10, Leo Izen wrote:
Two bug fixes related to the JPEG XL parser. They're not exactly related and
don't need to be applied in sequence.
v2 change: patches themselves are identical, but now there's a FATE test.
Leo Izen (3):
avcodec/jpegxl_parse{,r}: use correct ISOBMFF extended size location
avcodec/jpegxl_parser: fix parsing sequences of extremely small files
fate/jpegxl: add parser test for extboxes and small files
libavcodec/jpegxl_parse.c| 6 +++---
libavcodec/jpegxl_parser.c | 23 +++
tests/fate/jxl.mak | 8
tests/ref/fate/jxl-small-ext-box | 9 +
4 files changed, 35 insertions(+), 11 deletions(-)
create mode 100644 tests/ref/fate/jxl-small-ext-box
Will apply soon.
- 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".
[FFmpeg-devel] [PATCH v2 3/3] fate/jpegxl: add parser test for extboxes and small files
Add a fate test for the above commits fixing extremely small files or files with extended box sizes. Signed-off-by: Leo Izen --- tests/fate/jxl.mak | 8 tests/ref/fate/jxl-small-ext-box | 9 + 2 files changed, 17 insertions(+) create mode 100644 tests/ref/fate/jxl-small-ext-box diff --git a/tests/fate/jxl.mak b/tests/fate/jxl.mak index 057d3be0e1..d653eb644a 100644 --- a/tests/fate/jxl.mak +++ b/tests/fate/jxl.mak @@ -14,3 +14,11 @@ 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) + +# parser tests +FATE_JPEGXL_PARSE += fate-jxl-small-ext-box +fate-jxl-small-ext-box: CMD = framecrc -i $(TARGET_SAMPLES)/jxl/l.jxl -c copy + +FATE_JPEGXL_PARSE += $(FATE_JPEGXL_PARSE-yes) +FATE_SAMPLES_FFMPEG-$(call FRAMECRC, IMAGE_JPEGXL_PIPE, , JPEGXL_PARSER) += $(FATE_JPEGXL_PARSE) +fate-jxl-parse: $(FATE_JPEGXL_PARSE) diff --git a/tests/ref/fate/jxl-small-ext-box b/tests/ref/fate/jxl-small-ext-box new file mode 100644 index 00..0f9adfe075 --- /dev/null +++ b/tests/ref/fate/jxl-small-ext-box @@ -0,0 +1,9 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: jpegxl +#dimensions 0: 8x8 +#sar 0: 0/1 +0, 0, 0,1, 104, 0xd12d1d10 +0, 1, 1,1, 104, 0xd12d1d10 +0, 2, 2,1, 104, 0xd12d1d10 +0, 3, 3,1, 104, 0xd12d1d10 -- 2.43.0 ___ 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 v2 2/3] avcodec/jpegxl_parser: fix parsing sequences of extremely small files
This patch allows the JXL parser to parse sequences of extremely small
files concatenated together. (e.g. smaller than the parser buffer)
Signed-off-by: Leo Izen
---
libavcodec/jpegxl_parser.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 750872f17f..006eb6b295 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -1454,15 +1454,21 @@ static int jpegxl_parse(AVCodecParserContext *s,
AVCodecContext *avctx,
{
JXLParseContext *ctx = s->priv_data;
int next = END_NOT_FOUND, ret;
+const uint8_t *pbuf = ctx->pc.buffer;
+int pindex = ctx->pc.index;
*poutbuf_size = 0;
*poutbuf = NULL;
-if (!ctx->pc.index)
-goto flush;
+if (!ctx->pc.index) {
+if (ctx->pc.overread)
+goto flush;
+pbuf = buf;
+pindex = buf_size;
+}
if ((!ctx->container || !ctx->codestream_length) && !ctx->next) {
-ret = try_parse(s, avctx, ctx, ctx->pc.buffer, ctx->pc.index);
+ret = try_parse(s, avctx, ctx, pbuf, pindex);
if (ret < 0)
goto flush;
ctx->next = ret;
@@ -1471,7 +1477,7 @@ static int jpegxl_parse(AVCodecParserContext *s,
AVCodecContext *avctx,
}
if (ctx->container && ctx->next >= 0) {
-ret = skip_boxes(ctx, ctx->pc.buffer, ctx->pc.index);
+ret = skip_boxes(ctx, pbuf, pindex);
if (ret < 0) {
if (ret == AVERROR_INVALIDDATA)
ctx->next = -1;
--
2.43.0
___
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 v2 1/3] avcodec/jpegxl_parse{, r}: use correct ISOBMFF extended size location
According to ISO/IEC 14996-12, size == 1 means a 64-bit extended-size
field occurs *after* the 32-bit box type, not before. This fix should
allow correct parsing of JXL files with extended-size boxes.
Signed-off-by: Leo Izen
---
libavcodec/jpegxl_parse.c | 6 +++---
libavcodec/jpegxl_parser.c | 9 +
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavcodec/jpegxl_parse.c b/libavcodec/jpegxl_parse.c
index eb28e80867..7cfdd3e7d5 100644
--- a/libavcodec/jpegxl_parse.c
+++ b/libavcodec/jpegxl_parse.c
@@ -462,8 +462,10 @@ int ff_jpegxl_collect_codestream_header(const uint8_t
*input_buffer, int input_l
return AVERROR_BUFFER_TOO_SMALL;
size = bytestream2_get_be32();
+tag = bytestream2_get_le32();
+
if (size == 1) {
-if (bytestream2_get_bytes_left() < 12)
+if (bytestream2_get_bytes_left() < 8)
return AVERROR_BUFFER_TOO_SMALL;
size = bytestream2_get_be64();
head_size = 16;
@@ -474,8 +476,6 @@ int ff_jpegxl_collect_codestream_header(const uint8_t
*input_buffer, int input_l
if (size)
size -= head_size;
-tag = bytestream2_get_le32();
-
if (tag == MKTAG('j','x','l','p')) {
uint32_t idx;
if (bytestream2_get_bytes_left() < 4)
diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 630fc8a60b..750872f17f 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -1342,7 +1342,7 @@ static int skip_boxes(JXLParseContext *ctx, const uint8_t
*buf, int buf_size)
while (1) {
uint64_t size;
-int head_size = 4;
+int head_size = 8;
if (bytestream2_peek_le16() == FF_JPEGXL_CODESTREAM_SIGNATURE_LE)
break;
@@ -1353,16 +1353,17 @@ static int skip_boxes(JXLParseContext *ctx, const
uint8_t *buf, int buf_size)
return AVERROR_BUFFER_TOO_SMALL;
size = bytestream2_get_be32();
+bytestream2_skip(, 4); // tag
if (size == 1) {
-if (bytestream2_get_bytes_left() < 12)
+if (bytestream2_get_bytes_left() < 8)
return AVERROR_BUFFER_TOO_SMALL;
size = bytestream2_get_be64();
-head_size = 12;
+head_size = 16;
}
if (!size)
return AVERROR_INVALIDDATA;
/* invalid ISOBMFF size */
-if (size <= head_size + 4 || size > INT_MAX - ctx->skip)
+if (size <= head_size || size > INT_MAX - ctx->skip)
return AVERROR_INVALIDDATA;
ctx->skip += size;
--
2.43.0
___
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 v2 0/3] JPEG XL parser bug fixes
Two bug fixes related to the JPEG XL parser. They're not exactly related and
don't need to be applied in sequence.
v2 change: patches themselves are identical, but now there's a FATE test.
Leo Izen (3):
avcodec/jpegxl_parse{,r}: use correct ISOBMFF extended size location
avcodec/jpegxl_parser: fix parsing sequences of extremely small files
fate/jpegxl: add parser test for extboxes and small files
libavcodec/jpegxl_parse.c| 6 +++---
libavcodec/jpegxl_parser.c | 23 +++
tests/fate/jxl.mak | 8
tests/ref/fate/jxl-small-ext-box | 9 +
4 files changed, 35 insertions(+), 11 deletions(-)
create mode 100644 tests/ref/fate/jxl-small-ext-box
--
2.43.0
___
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 2/2] avcodec/jpegxl_parser: fix parsing sequences of extremely small files
On 11/26/23 13:07, Thilo Borgmann wrote: Am 26.11.2023 um 14:47 schrieb Leo Izen : On 11/26/23 05:56, Anton Khirnov wrote: Would be nice to have tests for these. I have a sample at: https://buzo.us/l.jxl It would test both of these patches. I can send a fate test for these to the ML if the sample gets uploaded. I CC'd samples-requ...@ffmpeg.org as well. Can do this in a bit. What about the file you‘d sent to samples-request in August, is there still a test to be pushed about it as well? -Thilo There is not, that sample from August was already uploaded and the fate test utilizing it has been merged. - Leo Izen (Traneptora) ___ 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 2/2] avcodec/jpegxl_parser: fix parsing sequences of extremely small files
On 11/26/23 05:56, Anton Khirnov wrote: Would be nice to have tests for these. I have a sample at: https://buzo.us/l.jxl It would test both of these patches. I can send a fate test for these to the ML if the sample gets uploaded. I CC'd samples-requ...@ffmpeg.org as well. - Leo Izen (Traneptora) ___ 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 2/9] avcodec/get_bits: add get_leb()
On 11/25/23 20:28, James Almer wrote: Signed-off-by: James Almer --- libavcodec/bitstream.h | 2 ++ libavcodec/bitstream_template.h | 22 ++ libavcodec/get_bits.h | 23 +++ 3 files changed, 47 insertions(+) Out of curiosity, why do this (and the avio version) have to be global? What are they used for other than the iamf demuxer? Would it make sense to have a static inline read_leb function defined in iamf.c? - Leo Izen (Traneptora) ___ 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 2/2] avcodec/jpegxl_parser: fix parsing sequences of extremely small files
This patch allows the JXL parser to parse sequences of extremely small
files concatenated together. (e.g. smaller than the parser buffer)
Signed-off-by: Leo Izen
---
libavcodec/jpegxl_parser.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 750872f17f..006eb6b295 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -1454,15 +1454,21 @@ static int jpegxl_parse(AVCodecParserContext *s,
AVCodecContext *avctx,
{
JXLParseContext *ctx = s->priv_data;
int next = END_NOT_FOUND, ret;
+const uint8_t *pbuf = ctx->pc.buffer;
+int pindex = ctx->pc.index;
*poutbuf_size = 0;
*poutbuf = NULL;
-if (!ctx->pc.index)
-goto flush;
+if (!ctx->pc.index) {
+if (ctx->pc.overread)
+goto flush;
+pbuf = buf;
+pindex = buf_size;
+}
if ((!ctx->container || !ctx->codestream_length) && !ctx->next) {
-ret = try_parse(s, avctx, ctx, ctx->pc.buffer, ctx->pc.index);
+ret = try_parse(s, avctx, ctx, pbuf, pindex);
if (ret < 0)
goto flush;
ctx->next = ret;
@@ -1471,7 +1477,7 @@ static int jpegxl_parse(AVCodecParserContext *s,
AVCodecContext *avctx,
}
if (ctx->container && ctx->next >= 0) {
-ret = skip_boxes(ctx, ctx->pc.buffer, ctx->pc.index);
+ret = skip_boxes(ctx, pbuf, pindex);
if (ret < 0) {
if (ret == AVERROR_INVALIDDATA)
ctx->next = -1;
--
2.43.0
___
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 0/2] JPEG XL parser bug fixes
Two bug fixes related to the JPEG XL parser. They're not exactly related and
don't need to be applied in sequence.
Leo Izen (2):
avcodec/jpegxl_parse{,r}: use correct ISOBMFF extended size location
avcodec/jpegxl_parser: fix parsing sequences of extremely small files
libavcodec/jpegxl_parse.c | 6 +++---
libavcodec/jpegxl_parser.c | 23 +++
2 files changed, 18 insertions(+), 11 deletions(-)
--
2.43.0
___
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 1/2] avcodec/jpegxl_parse{, r}: use correct ISOBMFF extended size location
According to ISO/IEC 14996-12, size == 1 means a 64-bit extended-size
field occurs *after* the 32-bit box type, not before. This fix should
allow correct parsing of JXL files with extended-size boxes.
Signed-off-by: Leo Izen
---
libavcodec/jpegxl_parse.c | 6 +++---
libavcodec/jpegxl_parser.c | 9 +
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavcodec/jpegxl_parse.c b/libavcodec/jpegxl_parse.c
index eb28e80867..7cfdd3e7d5 100644
--- a/libavcodec/jpegxl_parse.c
+++ b/libavcodec/jpegxl_parse.c
@@ -462,8 +462,10 @@ int ff_jpegxl_collect_codestream_header(const uint8_t
*input_buffer, int input_l
return AVERROR_BUFFER_TOO_SMALL;
size = bytestream2_get_be32();
+tag = bytestream2_get_le32();
+
if (size == 1) {
-if (bytestream2_get_bytes_left() < 12)
+if (bytestream2_get_bytes_left() < 8)
return AVERROR_BUFFER_TOO_SMALL;
size = bytestream2_get_be64();
head_size = 16;
@@ -474,8 +476,6 @@ int ff_jpegxl_collect_codestream_header(const uint8_t
*input_buffer, int input_l
if (size)
size -= head_size;
-tag = bytestream2_get_le32();
-
if (tag == MKTAG('j','x','l','p')) {
uint32_t idx;
if (bytestream2_get_bytes_left() < 4)
diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 630fc8a60b..750872f17f 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -1342,7 +1342,7 @@ static int skip_boxes(JXLParseContext *ctx, const uint8_t
*buf, int buf_size)
while (1) {
uint64_t size;
-int head_size = 4;
+int head_size = 8;
if (bytestream2_peek_le16() == FF_JPEGXL_CODESTREAM_SIGNATURE_LE)
break;
@@ -1353,16 +1353,17 @@ static int skip_boxes(JXLParseContext *ctx, const
uint8_t *buf, int buf_size)
return AVERROR_BUFFER_TOO_SMALL;
size = bytestream2_get_be32();
+bytestream2_skip(, 4); // tag
if (size == 1) {
-if (bytestream2_get_bytes_left() < 12)
+if (bytestream2_get_bytes_left() < 8)
return AVERROR_BUFFER_TOO_SMALL;
size = bytestream2_get_be64();
-head_size = 12;
+head_size = 16;
}
if (!size)
return AVERROR_INVALIDDATA;
/* invalid ISOBMFF size */
-if (size <= head_size + 4 || size > INT_MAX - ctx->skip)
+if (size <= head_size || size > INT_MAX - ctx->skip)
return AVERROR_INVALIDDATA;
ctx->skip += size;
--
2.43.0
___
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 v3] avformat/hls: use av_strlcopy instead of strncpy
Avoids a -Wstringop-truncation warning by using av_strlcopy instead of
strncpy. Additionally, prints a warning to the log context if this
truncation occurred.
Signed-off-by: Leo Izen
---
libavformat/hls.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f5f549b24d..61e2d67588 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -540,11 +540,16 @@ static struct rendition *new_rendition(HLSContext *c,
struct rendition_info *inf
}
if (info->assoc_language[0]) {
-int langlen = strlen(rend->language);
+size_t langlen = strlen(rend->language);
if (langlen < sizeof(rend->language) - 3) {
+size_t assoc_len;
rend->language[langlen] = ',';
-strncpy(rend->language + langlen + 1, info->assoc_language,
-sizeof(rend->language) - langlen - 2);
+assoc_len = av_strlcpy(rend->language + langlen + 1,
+ info->assoc_language,
+ sizeof(rend->language) - langlen - 1);
+if (langlen + assoc_len + 2 > sizeof(rend->language)) //
truncation occurred
+av_log(c->ctx, AV_LOG_WARNING, "Truncated rendition language:
%s\n",
+ info->assoc_language);
}
}
--
2.42.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-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffplay_renderer: declare function argument as const
Declaring the function argument as const fixes a warning down the line
that the const parameter is stripped. We don't modify this argument.
Signed-off-by: Leo Izen
---
fftools/ffplay_renderer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffplay_renderer.c b/fftools/ffplay_renderer.c
index a57e4980eb..45ca84fa95 100644
--- a/fftools/ffplay_renderer.c
+++ b/fftools/ffplay_renderer.c
@@ -133,7 +133,7 @@ static const char *optional_device_exts[] = {
"VK_MESA_video_decode_av1",
};
-static inline int enable_debug(AVDictionary *opt)
+static inline int enable_debug(const AVDictionary *opt)
{
AVDictionaryEntry *entry = av_dict_get(opt, "debug", NULL, 0);
int debug = entry && strtol(entry->value, NULL, 10);
--
2.42.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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avcodec/vp8: Export `vp8_token_update_probs` variable
On 11/12/23 20:44, Dai, Jianhui J wrote: This commit exports the `vp8_token_update_probs` variable to internal library scope to facilitate its reuse within the library. Where is this symbol actually needed elsewhere? If it is, perhaps an explanation in the commit message would be ideal. (I have no issues with the commit itself.) - Leo Izen (Traneptora) ___ 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/hls: use av_strlcopy instead of strncpy
On 10/30/23 09:55, Nicolas George wrote: Leo Izen (12023-10-30): difference: user data should not be silently truncated. There isn't really a bug here, just an extraneous compiler warning. Truncating user data silently is a bug. The warning is right and needs proper fix. Regards, The warning is not that truncation might occur, but that if it does occur, the buffer won't be nul-terminated. This is not actually the case because the size passed to strncpy is one smaller than the buffer size, and the buffer is zeroed. However, the compiler doesn't know this. Also, fwiw, info->assoc_language is the name of a language. It shouldn't actually ever be 63 characters long for real streams in the wild, and truncating it is just a memory-safety precaution. It's not a 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 v2] avformat/hls: use av_strlcopy instead of strncpy
On 10/30/23 03:51, Nicolas George wrote: Leo Izen (12023-10-29): But it will be nul-terminated in either case, so there's no real difference between the old and new code, other than the warning. No real difference = you are not fixing the bug. There should be a difference: user data should not be silently truncated. There isn't really a bug here, just an extraneous compiler warning. - Leo Izen (Traneptora) ___ 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] libavcodec/mpeg12: Remove "fast" mode
On 10/29/23 21:22, Lynne wrote: it can be argued that the error margins are small enough to permit bitexactness For what it's worth, the error margins for compliance are specified in 18181-3 and they're definitely within one pixel value for the various bit depths supported by the codestream 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 v2] avformat/hls: use av_strlcopy instead of strncpy
On 10/29/23 20:23, Andreas Rheinhardt wrote:
Leo Izen:
Avoids a -Wstringop-truncation warning by using av_strlcopy instead of
strncpy.
Signed-off-by: Leo Izen
---
libavformat/hls.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f5f549b24d..39440176c9 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -543,8 +543,8 @@ static struct rendition *new_rendition(HLSContext *c,
struct rendition_info *inf
int langlen = strlen(rend->language);
if (langlen < sizeof(rend->language) - 3) {
rend->language[langlen] = ',';
-strncpy(rend->language + langlen + 1, info->assoc_language,
-sizeof(rend->language) - langlen - 2);
+av_strlcpy(rend->language + langlen + 1, info->assoc_language,
+sizeof(rend->language) - langlen - 1);
}
}
As I said before: You are merely hiding the truncation issue instead of
fixing it.
I don't see how? It will only be truncated if info->assoc_language is
very very long, and in that case it won't fit inside a 64-byte buffer so
it will *have* to be truncated. But it will be nul-terminated in either
case, so there's no real difference between the old and new code, other
than the warning.
___
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] libavcodec/mpeg12: Remove "fast" mode
On 10/29/23 11:48, Lynne wrote: Oct 29, 2023, 16:43 by kier...@obe.tv: $subj as discussed at VDD Kieran This isn't Opus or JPEG-XL, there should be a single correct way of decoding something. Looks good to me. ___ I'm not sure I understand what you mean - JPEG XL is fully specified. Are you thinking of mjpeg? - 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 v2] avformat/hls: use av_strlcopy instead of strncpy
On 10/29/23 08:47, Leo Izen wrote: Avoids a -Wstringop-truncation warning by using av_strlcopy instead of strncpy. Changes from v1: - changed the length attribute, so now it has similar semantics to earlier. This patch has the same semantics with regard to the null-termination and the length of the string. However, it avoids a compiler warning because the compiler thinks strncpy is unsafe. - 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".
[FFmpeg-devel] [PATCH v2] avformat/hls: use av_strlcopy instead of strncpy
Avoids a -Wstringop-truncation warning by using av_strlcopy instead of
strncpy.
Signed-off-by: Leo Izen
---
libavformat/hls.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f5f549b24d..39440176c9 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -543,8 +543,8 @@ static struct rendition *new_rendition(HLSContext *c,
struct rendition_info *inf
int langlen = strlen(rend->language);
if (langlen < sizeof(rend->language) - 3) {
rend->language[langlen] = ',';
-strncpy(rend->language + langlen + 1, info->assoc_language,
-sizeof(rend->language) - langlen - 2);
+av_strlcpy(rend->language + langlen + 1, info->assoc_language,
+sizeof(rend->language) - langlen - 1);
}
}
--
2.42.0
___
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] avformat/hls: use av_strlcopy instead of strncpy
On 10/26/23 07:32, Andreas Rheinhardt wrote: This case can't happen here, because it only copies "sizeof(rend->language) - langlen - 2" bytes at most from position where sizeof(rend->language) - langlen - 1 are available, so the initial trailing \0 never gets touched. You did not touch the size part of the call, so you effectively only use sizeof(rend->language) - 1 bytes of the buffer, thereby making the truncation issue worse. And even if you fixed this part, you would still just have silenced the truncation instead of fixing it. - Andreas Truncation can happen if info->assoc_language is very long, i.e. uses the full buffer (63 chars plus a 64th for nul). In that case, strncpy will truncate, but because there's a -2 in the size argument, instead of -1, the resulting buffer will still be nul-terminated. The compiler doesn't know this, so it produces a warning. It seems the appropriate fix here is to change strncpy to av_strlcpy but also change the -2 to a -1. This will produce identical behavior to before, but it won't cause the compiler to produce a warning that the string might not be nul-terminated (cause it will always be). - Leo Izen (Traneptora) ___ 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] avformat/hls: use av_strlcopy instead of strncpy
On 10/26/23 06:54, Andreas Rheinhardt wrote:
Leo Izen:
Avoids a -Wstringop-truncation warning by using av_strlcopy instead of
strncpy.
Signed-off-by: Leo Izen
---
libavformat/hls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f5f549b24d..076f92ecfb 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -543,7 +543,7 @@ static struct rendition *new_rendition(HLSContext *c,
struct rendition_info *inf
int langlen = strlen(rend->language);
if (langlen < sizeof(rend->language) - 3) {
rend->language[langlen] = ',';
-strncpy(rend->language + langlen + 1, info->assoc_language,
+av_strlcpy(rend->language + langlen + 1, info->assoc_language,
sizeof(rend->language) - langlen - 2);
}
}
Doesn't this just silence the warning instead of fixing the potential
truncation?
- Andreas
The semantics of strlcpy and strncpy are slightly different. strlcopy
*always* nul-terminates the destination string. strncpy zeroes the
buffer and then runs memcpy, so if it would overflow the buffer the
string ends up without a nul-terminator. The warning triggers because
the compiler thinks that case can occur.
- 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".
[FFmpeg-devel] [PATCH] avformat/hls: use av_strlcopy instead of strncpy
Avoids a -Wstringop-truncation warning by using av_strlcopy instead of
strncpy.
Signed-off-by: Leo Izen
---
libavformat/hls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f5f549b24d..076f92ecfb 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -543,7 +543,7 @@ static struct rendition *new_rendition(HLSContext *c,
struct rendition_info *inf
int langlen = strlen(rend->language);
if (langlen < sizeof(rend->language) - 3) {
rend->language[langlen] = ',';
-strncpy(rend->language + langlen + 1, info->assoc_language,
+av_strlcpy(rend->language + langlen + 1, info->assoc_language,
sizeof(rend->language) - langlen - 2);
}
}
--
2.42.0
___
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/pngdec: various stylistic changes
Various parts of this file are restructured slightly for readability,
such as spacing in arithmetic operations, and putting `if (ret < 0)`
clauses on separate lines.
Signed-off-by: Leo Izen
---
libavcodec/pngdec.c | 241 +++-
1 file changed, 124 insertions(+), 117 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index d812ffd348..93b067a9be 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -128,7 +128,7 @@ static const uint8_t png_pass_dsp_ymask[NB_PASSES] = {
/* Mask to determine which pixels to overwrite while displaying */
static const uint8_t png_pass_dsp_mask[NB_PASSES] = {
-0xff, 0x0f, 0xff, 0x33, 0xff, 0x55, 0xff
+0xff, 0x0f, 0xff, 0x33, 0xff, 0x55, 0xff,
};
/* NOTE: we try to construct a good looking image at each pass. width
@@ -152,7 +152,7 @@ static void png_put_interlaced_row(uint8_t *dst, int width,
j = (x & 7);
if ((dsp_mask << j) & 0x80) {
b = (src[src_x >> 3] >> (7 - (src_x & 7))) & 1;
-dst[x >> 3] &= 0xFF7F>>j;
+dst[x >> 3] &= 0xff7f >> j;
dst[x >> 3] |= b << (7 - j);
}
if ((mask << j) & 0x80)
@@ -165,8 +165,8 @@ static void png_put_interlaced_row(uint8_t *dst, int width,
int j2 = 2 * (x & 3);
j = (x & 7);
if ((dsp_mask << j) & 0x80) {
-b = (src[src_x >> 2] >> (6 - 2*(src_x & 3))) & 3;
-dst[x >> 2] &= 0xFF3F>>j2;
+b = (src[src_x >> 2] >> (6 - 2 * (src_x & 3))) & 3;
+dst[x >> 2] &= 0xff3f >> j2;
dst[x >> 2] |= b << (6 - j2);
}
if ((mask << j) & 0x80)
@@ -176,11 +176,11 @@ static void png_put_interlaced_row(uint8_t *dst, int
width,
case 4:
src_x = 0;
for (x = 0; x < width; x++) {
-int j2 = 4*(x&1);
+int j2 = 4 * (x & 1);
j = (x & 7);
if ((dsp_mask << j) & 0x80) {
-b = (src[src_x >> 1] >> (4 - 4*(src_x & 1))) & 15;
-dst[x >> 1] &= 0xFF0F>>j2;
+b = (src[src_x >> 1] >> (4 - 4 * (src_x & 1))) & 15;
+dst[x >> 1] &= 0xff0f >> j2;
dst[x >> 1] |= b << (4 - j2);
}
if ((mask << j) & 0x80)
@@ -191,15 +191,14 @@ static void png_put_interlaced_row(uint8_t *dst, int
width,
bpp = bits_per_pixel >> 3;
d = dst;
s = src;
-for (x = 0; x < width; x++) {
-j = x & 7;
-if ((dsp_mask << j) & 0x80) {
-memcpy(d, s, bpp);
-}
-d += bpp;
-if ((mask << j) & 0x80)
-s += bpp;
-}
+for (x = 0; x < width; x++) {
+j = x & 7;
+if ((dsp_mask << j) & 0x80)
+memcpy(d, s, bpp);
+d += bpp;
+if ((mask << j) & 0x80)
+s += bpp;
+}
break;
}
}
@@ -207,8 +206,7 @@ static void png_put_interlaced_row(uint8_t *dst, int width,
void ff_add_png_paeth_prediction(uint8_t *dst, uint8_t *src, uint8_t *top,
int w, int bpp)
{
-int i;
-for (i = 0; i < w; i++) {
+for (int i = 0; i < w; i++) {
int a, b, c, p, pa, pb, pc;
a = dst[i - bpp];
@@ -233,7 +231,7 @@ void ff_add_png_paeth_prediction(uint8_t *dst, uint8_t
*src, uint8_t *top,
}
#define UNROLL1(bpp, op) \
-{ \
+do { \
r = dst[0]; \
if (bpp >= 2) \
g = dst[1]; \
@@ -253,21 +251,21 @@ void ff_add_png_paeth_prediction(uint8_t *dst, uint8_t
*src, uint8_t *top,
continue; \
dst[i + 3] = a = op(a, src[i + 3], last[i + 3]); \
} \
-}
-
-#define UNROLL_FILTER(op) \
-if (bpp == 1) { \
-UNROLL1(1, op)
Re: [FFmpeg-devel] [PATCH 5/9] avcodec/vlc: Pass VLC_MULTI_ELEM directly not by pointer
On 10/23/23 12:04, Michael Niedermayer wrote: On Mon, Oct 23, 2023 at 02:10:35AM -0400, Leo Izen wrote: On 10/22/23 17:51, Michael Niedermayer wrote: This makes the code more testable as uninitialized fields are 0 and not random values from the last call Signed-off-by: Michael Niedermayer --- libavcodec/vlc.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/libavcodec/vlc.c b/libavcodec/vlc.c index 9b7a42f79a3..4adec2da705 100644 --- a/libavcodec/vlc.c +++ b/libavcodec/vlc.c @@ -356,7 +356,7 @@ static void add_level(VLC_MULTI_ELEM *table, const int is16bit, uint32_t curcode, int curlen, int curlimit, int curlevel, const int minlen, const int max, - unsigned* levelcnt, VLC_MULTI_ELEM *info) + unsigned* levelcnt, VLC_MULTI_ELEM info) Is passing a struct by value advisable? Did you benchmark this? How does it compare to memset(info, 0, sizeof(*info))? The struct is 8 bytes, a pointer on 64bit arch is also 8byte I did not benchmark, I think this code doesnt run that many iterations (when its not buggy), I mean each iteration adds a entry to the table and the table will normally be designed to fit in cache and its only for initializing. do you still want me to bechmark this ? thx If the struct is only 8 bytes it's probably not necessary. - Leo Izen (Traneptora) ___ 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 5/9] avcodec/vlc: Pass VLC_MULTI_ELEM directly not by pointer
On 10/22/23 17:51, Michael Niedermayer wrote: This makes the code more testable as uninitialized fields are 0 and not random values from the last call Signed-off-by: Michael Niedermayer --- libavcodec/vlc.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/libavcodec/vlc.c b/libavcodec/vlc.c index 9b7a42f79a3..4adec2da705 100644 --- a/libavcodec/vlc.c +++ b/libavcodec/vlc.c @@ -356,7 +356,7 @@ static void add_level(VLC_MULTI_ELEM *table, const int is16bit, uint32_t curcode, int curlen, int curlimit, int curlevel, const int minlen, const int max, - unsigned* levelcnt, VLC_MULTI_ELEM *info) + unsigned* levelcnt, VLC_MULTI_ELEM info) Is passing a struct by value advisable? Did you benchmark this? How does it compare to memset(info, 0, sizeof(*info))? - Leo Izen (Traneptora) ___ 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/librsvgdec: fix memory leaks and deprecated functions
On 10/15/23 08:06, Leo Izen wrote: On 10/7/23 21:36, Leo Izen wrote: At various points through the function librsvg_decode_frame, errors are returned from immediately without deallocating any allocated structs. This patch both fixes those leaks, and also fixes the use of functions that are deprecated since librsvg version 2.52.0. The older calls are still used, guarded by #ifdefs while the newer replacements are used if librsvg >= 2.52.0. One of the deprecated functions is used as a check for the configure shell script, so it was replaced with a different function. Signed-off-by: Leo Izen --- Bumping, thanks. - Leo Izen (Traneptora) Pushed as 86ed68420d3b. - Leo Izen (Traneptora) ___ 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] avcodec/jpegxl_parser: fix OOB read regression
On 10/14/23 20:49, Leo Izen wrote: In f7ac3512f5b5cb8eb149f37300b43461d8e93af3 the size of the dynamically allocated buffer was shrunk, but it was made too small for very small alphabet sizes. This patch restores the size to prevent an OOB read. Reported-by: Cole Dilorenzo Signed-off-by: Leo Izen --- Will push soon as it fixes a fuzzer case. - 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] MAINTAINERS: add entry for jpegxl*
On 10/15/23 09:11, Lynne wrote: Oct 15, 2023, 14:14 by leo.i...@gmail.com: Adding myself for jpegxl* in avcodec as I'm the maintainer of this parser. Signed-off-by: Leo Izen --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b5c116c3d4..b66c3d09a6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -181,6 +181,7 @@ Codecs: interplayvideo.c Mike Melanson jni*, ffjni* Matthieu Bouron jpeg2000* Nicolas Bertrand + jpegxl* Leo Izen jvdec.c Peter Ross lcl*.cRoberto Togni, Reimar Doeffinger libcelt_dec.c Nicolas George @@ -434,8 +435,7 @@ Muxers/Demuxers: ipmovie.c Mike Melanson ircam*Paul B Mahol iss.c Stefan Gehrer - jpegxl_anim_dec.c Leo Izen - jpegxl_probe.*Leo Izen + jpegxl* Leo Izen jvdec.c Peter Ross kvag.cZane van Iperen libmodplug.c Clément Bœsch Would you mind using jpegxl_parse*? There's also jpegxl.h. If you add a decoder you can always change the MAINTAINERS entry then, at that time. - 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".
[FFmpeg-devel] [PATCH] MAINTAINERS: add entry for jpegxl*
Adding myself for jpegxl* in avcodec as I'm the maintainer of this parser. Signed-off-by: Leo Izen --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b5c116c3d4..b66c3d09a6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -181,6 +181,7 @@ Codecs: interplayvideo.c Mike Melanson jni*, ffjni* Matthieu Bouron jpeg2000* Nicolas Bertrand + jpegxl* Leo Izen jvdec.c Peter Ross lcl*.cRoberto Togni, Reimar Doeffinger libcelt_dec.c Nicolas George @@ -434,8 +435,7 @@ Muxers/Demuxers: ipmovie.c Mike Melanson ircam*Paul B Mahol iss.c Stefan Gehrer - jpegxl_anim_dec.c Leo Izen - jpegxl_probe.*Leo Izen + jpegxl* Leo Izen jvdec.c Peter Ross kvag.cZane van Iperen libmodplug.c Clément Bœsch -- 2.42.0 ___ 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".
