Re: [FFmpeg-devel] [PATCH v14 3/4] avcodec/libjxl: add Jpeg XL encoding via libjxl
On 4/14/22 13:49, Anton Khirnov wrote:
Quoting Leo Izen (2022-04-12 07:53:32)
+
+while (1) {
+jret = JxlEncoderProcessOutput(ctx->encoder, &next_out, &available);
+if (jret == JXL_ENC_ERROR) {
+av_log(avctx, AV_LOG_ERROR, "Unspecified libjxl error occurred\n");
+return AVERROR_EXTERNAL;
+}
+bytes_written = ctx->buffer_size - available;
+/* all data passed has been encoded */
+if (jret == JXL_ENC_SUCCESS)
+break;
+if (jret == JXL_ENC_NEED_MORE_OUTPUT) {
Is it possible for the encoder to return anything other than the three
codes you're handling? Won't you get into an infinite loop if it does?
It's just these three, according to the documentation.
https://libjxl.readthedocs.io/en/latest/api_encoder.html
-Leo Izen (thebombzen)
___
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] avfilter: add warp video filter
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_warp.c| 628 +++
3 files changed, 630 insertions(+)
create mode 100644 libavfilter/vf_warp.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 5eef334060..4bafa3b16b 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -519,6 +519,7 @@ OBJS-$(CONFIG_VMAFMOTION_FILTER) +=
vf_vmafmotion.o framesync.o
OBJS-$(CONFIG_VPP_QSV_FILTER)+= vf_vpp_qsv.o
OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o framesync.o
OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
+OBJS-$(CONFIG_WARP_FILTER) += vf_warp.o
OBJS-$(CONFIG_WAVEFORM_FILTER) += vf_waveform.o
OBJS-$(CONFIG_WEAVE_FILTER) += vf_weave.o
OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 26e4dbb92a..cbcdcabe24 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -495,6 +495,7 @@ extern const AVFilter ff_vf_vpp_qsv;
extern const AVFilter ff_vf_vstack;
extern const AVFilter ff_vf_w3fdif;
extern const AVFilter ff_vf_waveform;
+extern const AVFilter ff_vf_warp;
extern const AVFilter ff_vf_weave;
extern const AVFilter ff_vf_xbr;
extern const AVFilter ff_vf_xcorrelate;
diff --git a/libavfilter/vf_warp.c b/libavfilter/vf_warp.c
new file mode 100644
index 00..bada8f2d27
--- /dev/null
+++ b/libavfilter/vf_warp.c
@@ -0,0 +1,628 @@
+/*
+ * Copyright (c) 2021 Paul B Mahol
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * Pixel warp filter
+ */
+
+#include "libavutil/eval.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+enum WarpEdge {
+CLIP_EDGE,
+FIXED_EDGE,
+NB_WARPEDGE,
+};
+
+typedef struct WarpPoints {
+float x0, y0, x1, y1;
+} WarpPoints;
+
+typedef struct Matrix {
+int m, n;
+float *t;
+} Matrix;
+
+typedef struct WarpContext {
+const AVClass *class;
+char *points_str;
+
+int mode;
+int interpolation;
+int edge;
+int nb_points;
+int nb_planes;
+
+double *points;
+int points_size;
+
+int nb_warp_points;
+WarpPoints *warp_points;
+
+int black[4];
+
+int elements;
+int uv_linesize;
+int16_t *u, *v, *du, *dv;
+
+int (*warp_slice)(AVFilterContext *ctx, void *arg, int jobnr, int nb_jobs);
+
+void (*remap_line)(uint8_t *dst, int width, int height,
+ const uint8_t *const src, ptrdiff_t in_linesize,
+ const int16_t *const u, const int16_t *const v,
+ const int16_t *const du, const int16_t *const dv,
+ int fixed);
+} WarpContext;
+
+#define OFFSET(x) offsetof(WarpContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption warp_options[] = {
+{ "points", "set warp points", OFFSET(points_str), AV_OPT_TYPE_STRING,
{.str="0 0 0 0|1 0 0 0|0 1 0 0|1 1 0 0"}, 0, 0, FLAGS },
+{ "mode", "set warp mode", OFFSET(mode), AV_OPT_TYPE_INT, {.i64=2}, 0, 2,
FLAGS, "mode" },
+{ "abs", "absolute", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, FLAGS, "mode" },
+{ "absrel", "absolute + relative", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0,
FLAGS, "mode" },
+{ "rel", "relative", 0, AV_OPT_TYPE_CONST, {.i64=2}, 0, 0, FLAGS, "mode" },
+{ "interpolation", "set interpolation", OFFSET(interpolation),
AV_OPT_TYPE_INT, {.i64=0}, 0, 1, FLAGS, "interp" },
+{ "nearest", "set nearest", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 1, FLAGS,
"interp" },
+{ "bilinear", "set bilinear", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 1, FLAGS,
"interp" },
+{ "edge", "set edge mode", OFFSET(edge), AV_OPT_TYPE_INT,
{.i64=FIXED_EDGE}, 0, NB_WARPEDGE-1, FLAGS, "edge" },
+{ "clip", "clip edge", 0, AV_OPT_TYPE_CONST, {.i64=CLIP_EDGE}, 0, 1,
FLAGS, "edge" },
+{ "fixed", "fixed color", 0, AV_OPT_TYPE_CONST, {.i64=FIXED_EDGE}, 0, 1,
FLAGS, "edge" },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(warp);
+
+typedef struct Thread
Re: [FFmpeg-devel] [PATCH 6/7] avcodec: Make avcodec_decoder_subtitles2 accept a const AVPacket*
On Thu, Apr 14, 2022 at 9:33 PM Andreas Rheinhardt
wrote:
>
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2022-03-31 00:49:57)
> >> From: Andreas Rheinhardt
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> doc/APIchanges| 3 +++
> >> fftools/ffmpeg.c | 4 ++--
> >> fftools/ffprobe.c | 2 +-
> >> libavcodec/avcodec.h | 3 +--
> >> libavcodec/decode.c | 9 -
> >> libavcodec/version.h | 2 +-
> >> tools/target_dec_fuzzer.c | 4 ++--
> >> 7 files changed, 14 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/doc/APIchanges b/doc/APIchanges
> >> index 1a9f0a303e..326a3c721c 100644
> >> --- a/doc/APIchanges
> >> +++ b/doc/APIchanges
> >> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
> >>
> >> API changes, most recent first:
> >>
> >> +2022-03-30 - xx - lavc 59.26.100 - avcodec.h
> >> + avcodec_decode_subtitle2() now accepts const AVPacket*.
> >
> > I vaguely recall C++ having a problem with such changes. Anybody
> > remembers the details? Do we care?
> >
>
> You did something like this in 0a0f19b577d54ff2e72cc9a0fe027952db83f332
> without a major bump; IIRC there are more instances likes this.
>
> For C functions, the signature is not part of the exported symbol name
> (as zhilizhao already said) and the ABIs just presume that the caller
> and callee agree on the signature. Constifying this parameter does not
> break this, as "pointers to qualified or unqualified versions of
> compatible types shall have the same representation and alignment
> requirements" (C11 6.2.5/26).
>
> Ordinary API usage will be fine, because the conversion from AVPacket*
> to const AVPacket* is safe and therefore performed automatically; it
> requires no cast. API-wise there is only one thing that might cause
> problems: If one does not use avcodec_decode_subtitle2 directly, but
> via a function pointer like this:
>
> #include
>
> typedef int (*unconst)(AVCodecContext *, AVSubtitle *, int *, AVPacket *);
>
> void foo(void)
> {
> unconst funcptr = avcodec_decode_subtitle2;
>
> /* use funcptr */
> }
>
> Here the initialization of avcodec_decode_subtitle2 is not fine; for C
> compilers will by default emit a warning, for C++ it is common to fail.
> But avcodec_decode_subtitle2 is the only function with this signature
> at all, so it makes no sense to use function pointers instead of using
> this function directly. I don't think that anyone does and therefore my
> answer to your last question is: I don't really care given that ordinary
> usages are fine.
>
If one does manual dynamic loading (eg. for optional components), you
would use a function pointer .. for all functions, not just this one.
On the other hand, if you use C++ and you manually define the type for
every function pointer (as we don't define function pointer types),
its a rather fragile construct to begin with, especially as you could
just infer the types automatically using decltype constructs, in which
case there would be no issues as it just updates automatically.
In theory such a change can break someones code, but.. its not great
code to begin with and requires constant maintenance.
- Hendrik
___
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] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of Paul > B Mahol > Sent: Thursday, April 14, 2022 12:02 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > architecture > > On Wed, Apr 13, 2022 at 12:43 AM Soft Works > wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > Paul > > > B Mahol > > > Sent: Tuesday, April 12, 2022 11:29 AM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > > architecture > > > > > > On Mon, Apr 11, 2022 at 10:58 PM Soft Works > > > > wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > From: ffmpeg-devel On Behalf > Of > > > Paul > > > > > B Mahol > > > > > Sent: Monday, April 11, 2022 10:52 PM > > > > > To: FFmpeg development discussions and patches > > > > de...@ffmpeg.org> > > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a > threaded > > > > > architecture > > > > > > > > > > On Mon, Apr 11, 2022 at 10:10 PM Soft Works > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: ffmpeg-devel On > Behalf > > > Of > > > > > > > Anton Khirnov > > > > > > > Sent: Monday, April 11, 2022 10:29 AM > > > > > > > To: FFmpeg development discussions and patches > > > > > > de...@ffmpeg.org> > > > > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a > > > threaded > > > > > > > architecture > > > > > > > > > > > > > > Quoting Soft Works (2022-04-08 17:27:10) > > > > > > > > > Furthermore, remember that this is just the first > step. > > > There > > > > > will > > > > > > > be > > > > > > > > > further patchsets converting the other components. I > > > intend to > > > > > > > > > upstream > > > > > > > > > them gradually one after the other. Your suggestion > would > > > > > require > > > > > > > me > > > > > > > > > to > > > > > > > > > instead write the whole thing at once, fighting rebase > > > > > conflicts > > > > > > > all > > > > > > > > > the > > > > > > > > > way, and then submit it as a giant utterly > unreviewable > > > > > patchset. > > > > > > > > > > > > > > > > That's not what I meant, but anyway it's not worth > > > discussing > > > > > when > > > > > > > > it's a minority opinion. > > > > > > > > > > > > > > > > Just a practical question instead for planning purposes: > > > > > > > > > > > > > > > > Which timeframe do you expect for the whole process? > > > > > > > > When do you plan to start > > > > > > > > > > > > > > If you mean "start pushing the patches", then I intend to > do > > > that > > > > > as > > > > > > > they are reviewed and approved. I hope to send the > > > upstreamable > > > > > > > version > > > > > > > of this set this week, if nobody has strong objectsions > then I > > > > > might > > > > > > > push it after vacation, i.e. late April/early May. > > > > > > > > > > > > > > > and for how long do you think it will take until all > further > > > > > > > patchsets > > > > > > > > will be submitted/applied? > > > > > > > > > > > > > > This is very hard to estimate accurately. A pessimistic > guess > > > > > assuming > > > > > > > I > > > > > > > get stuck on every stupid thing would be end of this year, > but > > > I > > > > > hope > > > > > > > for things to go much faster. > > > > > > > > > > > > Thanks for the reply. I'm asking because I need to decide > about > > > the > > > > > > way I'm going to proceed with the subtitle filtering > patchset. > > > > > > > > > > > > I think I will have to keep and continue this in private > during > > > this > > > > > > procedure as I don't have the resources to regularly adapt > and > > > sync > > > > > > from my (5.0 based) working branch back to the master > branch. > > > > > > > > > > > > > > > > > That is big waste of resource when not implementing thing > > > properly. > > > > > > > > From my point of view, somebody who has never given any detailed > > > > reviews, didn't state what exactly(!) he would consider to be > > > "improper" > > > > and never made any suggestion how the implementation would need > to > > > > be changed to become "proper" - doesn't have the right to make > such > > > > claims. > > > > > > > > > > You never asked kindly. > > > > I have always asked you kindly, probably more kindly than many > > others do (going through history, I just found many very kind > > questions I've been asking you). > > > > For the specific issue about the subtitles patchset, you jumped > > in on IRC, saying "it's a hack". I had asked you (kindly!) what > > makes you think that it would be a hack and what you would think > needs > > to be changed. You never answered the question since that time, > > instead you kept labeling it in all those ways. > > > > > > I think the fundamental problem about the current situation is > > that there were discussions w
[FFmpeg-devel] [PATCH] avutil/cpu: #define _GNU_SOURCE before including any standard headers
Otherwise its effect might not work causing CPU_COUNT to not get defined. Fixes cpu count detection to actually use sched_getaffinity if available. Signed-off-by: Marton Balint --- libavutil/cpu.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/libavutil/cpu.c b/libavutil/cpu.c index 833c220192..24b99d2554 100644 --- a/libavutil/cpu.c +++ b/libavutil/cpu.c @@ -16,6 +16,15 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ +#include "config.h" + +#if HAVE_SCHED_GETAFFINITY +#ifndef _GNU_SOURCE +# define _GNU_SOURCE +#endif +#include +#endif + #include #include #include @@ -23,16 +32,9 @@ #include "attributes.h" #include "cpu.h" #include "cpu_internal.h" -#include "config.h" #include "opt.h" #include "common.h" -#if HAVE_SCHED_GETAFFINITY -#ifndef _GNU_SOURCE -# define _GNU_SOURCE -#endif -#include -#endif #if HAVE_GETPROCESSAFFINITYMASK || HAVE_WINRT #include #endif -- 2.31.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] avformat/rtmpproto: send proper status for response to play command
This fixes referencing the uninitialized filename variable.
Fixes ticket #9711.
Signed-off-by: Marton Balint
---
libavformat/rtmpproto.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index f97e3c3b8e..f0ef223f05 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -1857,11 +1857,10 @@ static int write_begin(URLContext *s)
}
static int write_status(URLContext *s, RTMPPacket *pkt,
-const char *status, const char *filename)
+const char *status, const char *description, const
char *details)
{
RTMPContext *rt = s->priv_data;
RTMPPacket spkt = { 0 };
-char statusmsg[128];
uint8_t *pp;
int ret;
@@ -1884,11 +1883,11 @@ static int write_status(URLContext *s, RTMPPacket *pkt,
ff_amf_write_field_name(&pp, "code");
ff_amf_write_string(&pp, status);
ff_amf_write_field_name(&pp, "description");
-snprintf(statusmsg, sizeof(statusmsg),
- "%s is now published", filename);
-ff_amf_write_string(&pp, statusmsg);
-ff_amf_write_field_name(&pp, "details");
-ff_amf_write_string(&pp, filename);
+ff_amf_write_string(&pp, description);
+if (details) {
+ff_amf_write_field_name(&pp, "details");
+ff_amf_write_string(&pp, details);
+}
ff_amf_write_object_end(&pp);
spkt.size = pp - spkt.data;
@@ -1964,20 +1963,22 @@ static int send_invoke_response(URLContext *s,
RTMPPacket *pkt)
pp = spkt.data;
ff_amf_write_string(&pp, "onFCPublish");
} else if (!strcmp(command, "publish")) {
+char statusmsg[128];
+snprintf(statusmsg, sizeof(statusmsg), "%s is now published",
filename);
ret = write_begin(s);
if (ret < 0)
return ret;
// Send onStatus(NetStream.Publish.Start)
return write_status(s, pkt, "NetStream.Publish.Start",
- filename);
+statusmsg, filename);
} else if (!strcmp(command, "play")) {
ret = write_begin(s);
if (ret < 0)
return ret;
rt->state = STATE_SENDING;
return write_status(s, pkt, "NetStream.Play.Start",
-filename);
+"playing stream", NULL);
} else {
if ((ret = ff_rtmp_packet_create(&spkt, RTMP_SYSTEM_CHANNEL,
RTMP_PT_INVOKE, 0,
--
2.31.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] swscale/aarch64: add hscale specializations
Hi, On Thu, Apr 14, 2022 at 04:25:19PM +, Swinney, Jonathan wrote: > Clement (and others), do you have any comments on this patch? > I'm sorry I won't have time to review the asm patches. Regards, -- Clément B. ___ 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 6/7] avcodec: Make avcodec_decoder_subtitles2 accept a const AVPacket*
Anton Khirnov:
> Quoting Andreas Rheinhardt (2022-03-31 00:49:57)
>> From: Andreas Rheinhardt
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> doc/APIchanges| 3 +++
>> fftools/ffmpeg.c | 4 ++--
>> fftools/ffprobe.c | 2 +-
>> libavcodec/avcodec.h | 3 +--
>> libavcodec/decode.c | 9 -
>> libavcodec/version.h | 2 +-
>> tools/target_dec_fuzzer.c | 4 ++--
>> 7 files changed, 14 insertions(+), 13 deletions(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index 1a9f0a303e..326a3c721c 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
>>
>> API changes, most recent first:
>>
>> +2022-03-30 - xx - lavc 59.26.100 - avcodec.h
>> + avcodec_decode_subtitle2() now accepts const AVPacket*.
>
> I vaguely recall C++ having a problem with such changes. Anybody
> remembers the details? Do we care?
>
You did something like this in 0a0f19b577d54ff2e72cc9a0fe027952db83f332
without a major bump; IIRC there are more instances likes this.
For C functions, the signature is not part of the exported symbol name
(as zhilizhao already said) and the ABIs just presume that the caller
and callee agree on the signature. Constifying this parameter does not
break this, as "pointers to qualified or unqualified versions of
compatible types shall have the same representation and alignment
requirements" (C11 6.2.5/26).
Ordinary API usage will be fine, because the conversion from AVPacket*
to const AVPacket* is safe and therefore performed automatically; it
requires no cast. API-wise there is only one thing that might cause
problems: If one does not use avcodec_decode_subtitle2 directly, but
via a function pointer like this:
#include
typedef int (*unconst)(AVCodecContext *, AVSubtitle *, int *, AVPacket *);
void foo(void)
{
unconst funcptr = avcodec_decode_subtitle2;
/* use funcptr */
}
Here the initialization of avcodec_decode_subtitle2 is not fine; for C
compilers will by default emit a warning, for C++ it is common to fail.
But avcodec_decode_subtitle2 is the only function with this signature
at all, so it makes no sense to use function pointers instead of using
this function directly. I don't think that anyone does and therefore my
answer to your last question is: I don't really care given that ordinary
usages are fine.
(Notice that the situation is different if one constified a level
further down, e.g. by changing const AVCodec *av_codec_iterate(void
**opaque) to const AVCodec *av_codec_iterate(const void **opaque) as
there is no implicit conversion in this case. So the ordinary API usage
would result in a warning or error. Might this be the reason for what
you vaguely remember?)
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v14 3/4] avcodec/libjxl: add Jpeg XL encoding via libjxl
Quoting Leo Izen (2022-04-12 07:53:32)
> +
> +while (1) {
> +jret = JxlEncoderProcessOutput(ctx->encoder, &next_out, &available);
> +if (jret == JXL_ENC_ERROR) {
> +av_log(avctx, AV_LOG_ERROR, "Unspecified libjxl error
> occurred\n");
> +return AVERROR_EXTERNAL;
> +}
> +bytes_written = ctx->buffer_size - available;
> +/* all data passed has been encoded */
> +if (jret == JXL_ENC_SUCCESS)
> +break;
> +if (jret == JXL_ENC_NEED_MORE_OUTPUT) {
Is it possible for the encoder to return anything other than the three
codes you're handling? Won't you get into an infinite loop if it does?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/mjpegdec: Don't create unnecessary AVFrame reference
James Almer:
>
>
> On 4/14/2022 1:43 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 4/14/2022 12:57 PM, Andreas Rheinhardt wrote:
MJPEG is an intra-codec, so it makes no sense to keep the reference.
It is basically unused lateron anyway.
>>>
>>> Wouldn't this mean you can remove the AV_GET_BUFFER_FLAG_REF flag from
>>> the ff_get_buffer() call?
>>>
>>
>> Not in case of SMV. The smv code keeps a reference and reuses it. See
>> smv_process_frame.
>
> Make it AV_GET_BUFFER_FLAG_REF * (s->avctx->codec_id ==
> AV_CODEC_ID_SMVJPEG) then.
>
Not worth the branch.
>>
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mjpegdec.c | 45
+--
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 0e76bf4c26..939dedce33 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2589,8 +2589,7 @@ eoi_parser:
av_freep(&s->hwaccel_picture_private);
}
- if ((ret = av_frame_ref(frame, s->picture_ptr)) < 0)
- return ret;
+ av_frame_move_ref(frame, s->picture_ptr);
s->got_picture = 0;
frame->pkt_dts = s->pkt->dts;
@@ -2675,9 +2674,9 @@ the_end:
if (ret)
return ret;
- av_assert0(s->nb_components ==
av_pix_fmt_count_planes(s->picture_ptr->format));
+ av_assert0(s->nb_components ==
av_pix_fmt_count_planes(frame->format));
for (p = 0; pnb_components; p++) {
- uint8_t *line = s->picture_ptr->data[p];
+ uint8_t *line = frame->data[p];
int w = s->width;
int h = s->height;
if (!s->upscale_h[p])
@@ -2737,7 +2736,7 @@ the_end:
if (ret)
return ret;
- av_assert0(s->nb_components ==
av_pix_fmt_count_planes(s->picture_ptr->format));
+ av_assert0(s->nb_components ==
av_pix_fmt_count_planes(frame->format));
for (p = 0; p < s->nb_components; p++) {
uint8_t *dst;
int w = s->width;
@@ -2748,10 +2747,10 @@ the_end:
w = AV_CEIL_RSHIFT(w, hshift);
h = AV_CEIL_RSHIFT(h, vshift);
}
- dst = &((uint8_t *)s->picture_ptr->data[p])[(h - 1) *
s->linesize[p]];
+ dst = &frame->data[p][(h - 1) * s->linesize[p]];
for (i = h - 1; i; i--) {
- uint8_t *src1 = &((uint8_t
*)s->picture_ptr->data[p])[i * s->upscale_v[p] / (s->upscale_v[p] + 1)
* s->linesize[p]];
- uint8_t *src2 = &((uint8_t
*)s->picture_ptr->data[p])[(i + 1) * s->upscale_v[p] /
(s->upscale_v[p] + 1) * s->linesize[p]];
+ uint8_t *src1 = &frame->data[p][ i *
s->upscale_v[p] / (s->upscale_v[p] + 1) * s->linesize[p]];
+ uint8_t *src2 = &frame->data[p][(i + 1) *
s->upscale_v[p] / (s->upscale_v[p] + 1) * s->linesize[p]];
if (s->upscale_v[p] != 2 && (src1 == src2 || i == h
- 1)) {
memcpy(dst, src1, w);
} else {
@@ -2768,36 +2767,36 @@ the_end:
if (ret)
return ret;
- av_assert0(s->nb_components ==
av_pix_fmt_count_planes(s->picture_ptr->format));
+ av_assert0(s->nb_components ==
av_pix_fmt_count_planes(frame->format));
for (index=0; indexnb_components; index++) {
- uint8_t *dst = s->picture_ptr->data[index];
- int w = s->picture_ptr->width;
- int h = s->picture_ptr->height;
+ uint8_t *dst = frame->data[index];
+ int w = frame->width;
+ int h = frame->height;
if(index && index<3){
w = AV_CEIL_RSHIFT(w, hshift);
h = AV_CEIL_RSHIFT(h, vshift);
}
if(dst){
- uint8_t *dst2 = dst +
s->picture_ptr->linesize[index]*(h-1);
+ uint8_t *dst2 = dst + frame->linesize[index]*(h-1);
for (i=0; i>>> for (j=0; j>>> FFSWAP(int, dst[j], dst2[j]);
- dst += s->picture_ptr->linesize[index];
- dst2 -= s->picture_ptr->linesize[index];
+ dst += frame->linesize[index];
+ dst2 -= frame->linesize[index];
}
}
}
}
if (s->adobe_transform == 0 && s->avctx->pix_fmt ==
AV_PIX_FMT_GBRAP) {
>>>
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/mjpegdec: Don't create unnecessary AVFrame reference
On 4/14/2022 1:43 PM, Andreas Rheinhardt wrote:
James Almer:
On 4/14/2022 12:57 PM, Andreas Rheinhardt wrote:
MJPEG is an intra-codec, so it makes no sense to keep the reference.
It is basically unused lateron anyway.
Wouldn't this mean you can remove the AV_GET_BUFFER_FLAG_REF flag from
the ff_get_buffer() call?
Not in case of SMV. The smv code keeps a reference and reuses it. See
smv_process_frame.
Make it AV_GET_BUFFER_FLAG_REF * (s->avctx->codec_id ==
AV_CODEC_ID_SMVJPEG) then.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mjpegdec.c | 45 +--
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 0e76bf4c26..939dedce33 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2589,8 +2589,7 @@ eoi_parser:
av_freep(&s->hwaccel_picture_private);
}
- if ((ret = av_frame_ref(frame, s->picture_ptr)) < 0)
- return ret;
+ av_frame_move_ref(frame, s->picture_ptr);
s->got_picture = 0;
frame->pkt_dts = s->pkt->dts;
@@ -2675,9 +2674,9 @@ the_end:
if (ret)
return ret;
- av_assert0(s->nb_components ==
av_pix_fmt_count_planes(s->picture_ptr->format));
+ av_assert0(s->nb_components ==
av_pix_fmt_count_planes(frame->format));
for (p = 0; pnb_components; p++) {
- uint8_t *line = s->picture_ptr->data[p];
+ uint8_t *line = frame->data[p];
int w = s->width;
int h = s->height;
if (!s->upscale_h[p])
@@ -2737,7 +2736,7 @@ the_end:
if (ret)
return ret;
- av_assert0(s->nb_components ==
av_pix_fmt_count_planes(s->picture_ptr->format));
+ av_assert0(s->nb_components ==
av_pix_fmt_count_planes(frame->format));
for (p = 0; p < s->nb_components; p++) {
uint8_t *dst;
int w = s->width;
@@ -2748,10 +2747,10 @@ the_end:
w = AV_CEIL_RSHIFT(w, hshift);
h = AV_CEIL_RSHIFT(h, vshift);
}
- dst = &((uint8_t *)s->picture_ptr->data[p])[(h - 1) *
s->linesize[p]];
+ dst = &frame->data[p][(h - 1) * s->linesize[p]];
for (i = h - 1; i; i--) {
- uint8_t *src1 = &((uint8_t
*)s->picture_ptr->data[p])[i * s->upscale_v[p] / (s->upscale_v[p] + 1)
* s->linesize[p]];
- uint8_t *src2 = &((uint8_t
*)s->picture_ptr->data[p])[(i + 1) * s->upscale_v[p] /
(s->upscale_v[p] + 1) * s->linesize[p]];
+ uint8_t *src1 = &frame->data[p][ i *
s->upscale_v[p] / (s->upscale_v[p] + 1) * s->linesize[p]];
+ uint8_t *src2 = &frame->data[p][(i + 1) *
s->upscale_v[p] / (s->upscale_v[p] + 1) * s->linesize[p]];
if (s->upscale_v[p] != 2 && (src1 == src2 || i == h
- 1)) {
memcpy(dst, src1, w);
} else {
@@ -2768,36 +2767,36 @@ the_end:
if (ret)
return ret;
- av_assert0(s->nb_components ==
av_pix_fmt_count_planes(s->picture_ptr->format));
+ av_assert0(s->nb_components ==
av_pix_fmt_count_planes(frame->format));
for (index=0; indexnb_components; index++) {
- uint8_t *dst = s->picture_ptr->data[index];
- int w = s->picture_ptr->width;
- int h = s->picture_ptr->height;
+ uint8_t *dst = frame->data[index];
+ int w = frame->width;
+ int h = frame->height;
if(index && index<3){
w = AV_CEIL_RSHIFT(w, hshift);
h = AV_CEIL_RSHIFT(h, vshift);
}
if(dst){
- uint8_t *dst2 = dst +
s->picture_ptr->linesize[index]*(h-1);
+ uint8_t *dst2 = dst + frame->linesize[index]*(h-1);
for (i=0; ipicture_ptr->linesize[index];
- dst2 -= s->picture_ptr->linesize[index];
+ dst += frame->linesize[index];
+ dst2 -= frame->linesize[index];
}
}
}
}
if (s->adobe_transform == 0 && s->avctx->pix_fmt ==
AV_PIX_FMT_GBRAP) {
- int w = s->picture_ptr->width;
- int h = s->picture_ptr->height;
+ int w = frame->width;
+ int h = frame->height;
av_assert0(s->nb_components == 4);
for (i=0; ipicture_ptr->data[index]
- + s->picture_ptr->linesize[index]*i;
+ dst[index] = frame->data[index]
+ + frame->linesize[index]*i;
}
for (j=0; jadobe_transform == 2 && s->avctx->pix_fmt ==
AV_PIX_FMT_YUVA444P) {
- int w = s->picture_ptr->width;
- int h = s->picture_ptr->height;
+ int w = frame->width;
+ int h = frame->height;
av_assert0(s->nb_co
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/mjpegdec: Don't create unnecessary AVFrame reference
James Almer:
> On 4/14/2022 12:57 PM, Andreas Rheinhardt wrote:
>> MJPEG is an intra-codec, so it makes no sense to keep the reference.
>> It is basically unused lateron anyway.
>
> Wouldn't this mean you can remove the AV_GET_BUFFER_FLAG_REF flag from
> the ff_get_buffer() call?
>
Not in case of SMV. The smv code keeps a reference and reuses it. See
smv_process_frame.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/mjpegdec.c | 45 +--
>> 1 file changed, 22 insertions(+), 23 deletions(-)
>>
>> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
>> index 0e76bf4c26..939dedce33 100644
>> --- a/libavcodec/mjpegdec.c
>> +++ b/libavcodec/mjpegdec.c
>> @@ -2589,8 +2589,7 @@ eoi_parser:
>> av_freep(&s->hwaccel_picture_private);
>> }
>> - if ((ret = av_frame_ref(frame, s->picture_ptr)) < 0)
>> - return ret;
>> + av_frame_move_ref(frame, s->picture_ptr);
>> s->got_picture = 0;
>> frame->pkt_dts = s->pkt->dts;
>> @@ -2675,9 +2674,9 @@ the_end:
>> if (ret)
>> return ret;
>> - av_assert0(s->nb_components ==
>> av_pix_fmt_count_planes(s->picture_ptr->format));
>> + av_assert0(s->nb_components ==
>> av_pix_fmt_count_planes(frame->format));
>> for (p = 0; pnb_components; p++) {
>> - uint8_t *line = s->picture_ptr->data[p];
>> + uint8_t *line = frame->data[p];
>> int w = s->width;
>> int h = s->height;
>> if (!s->upscale_h[p])
>> @@ -2737,7 +2736,7 @@ the_end:
>> if (ret)
>> return ret;
>> - av_assert0(s->nb_components ==
>> av_pix_fmt_count_planes(s->picture_ptr->format));
>> + av_assert0(s->nb_components ==
>> av_pix_fmt_count_planes(frame->format));
>> for (p = 0; p < s->nb_components; p++) {
>> uint8_t *dst;
>> int w = s->width;
>> @@ -2748,10 +2747,10 @@ the_end:
>> w = AV_CEIL_RSHIFT(w, hshift);
>> h = AV_CEIL_RSHIFT(h, vshift);
>> }
>> - dst = &((uint8_t *)s->picture_ptr->data[p])[(h - 1) *
>> s->linesize[p]];
>> + dst = &frame->data[p][(h - 1) * s->linesize[p]];
>> for (i = h - 1; i; i--) {
>> - uint8_t *src1 = &((uint8_t
>> *)s->picture_ptr->data[p])[i * s->upscale_v[p] / (s->upscale_v[p] + 1)
>> * s->linesize[p]];
>> - uint8_t *src2 = &((uint8_t
>> *)s->picture_ptr->data[p])[(i + 1) * s->upscale_v[p] /
>> (s->upscale_v[p] + 1) * s->linesize[p]];
>> + uint8_t *src1 = &frame->data[p][ i *
>> s->upscale_v[p] / (s->upscale_v[p] + 1) * s->linesize[p]];
>> + uint8_t *src2 = &frame->data[p][(i + 1) *
>> s->upscale_v[p] / (s->upscale_v[p] + 1) * s->linesize[p]];
>> if (s->upscale_v[p] != 2 && (src1 == src2 || i == h
>> - 1)) {
>> memcpy(dst, src1, w);
>> } else {
>> @@ -2768,36 +2767,36 @@ the_end:
>> if (ret)
>> return ret;
>> - av_assert0(s->nb_components ==
>> av_pix_fmt_count_planes(s->picture_ptr->format));
>> + av_assert0(s->nb_components ==
>> av_pix_fmt_count_planes(frame->format));
>> for (index=0; indexnb_components; index++) {
>> - uint8_t *dst = s->picture_ptr->data[index];
>> - int w = s->picture_ptr->width;
>> - int h = s->picture_ptr->height;
>> + uint8_t *dst = frame->data[index];
>> + int w = frame->width;
>> + int h = frame->height;
>> if(index && index<3){
>> w = AV_CEIL_RSHIFT(w, hshift);
>> h = AV_CEIL_RSHIFT(h, vshift);
>> }
>> if(dst){
>> - uint8_t *dst2 = dst +
>> s->picture_ptr->linesize[index]*(h-1);
>> + uint8_t *dst2 = dst + frame->linesize[index]*(h-1);
>> for (i=0; i> for (j=0; j> FFSWAP(int, dst[j], dst2[j]);
>> - dst += s->picture_ptr->linesize[index];
>> - dst2 -= s->picture_ptr->linesize[index];
>> + dst += frame->linesize[index];
>> + dst2 -= frame->linesize[index];
>> }
>> }
>> }
>> }
>> if (s->adobe_transform == 0 && s->avctx->pix_fmt ==
>> AV_PIX_FMT_GBRAP) {
>> - int w = s->picture_ptr->width;
>> - int h = s->picture_ptr->height;
>> + int w = frame->width;
>> + int h = frame->height;
>> av_assert0(s->nb_components == 4);
>> for (i=0; i> int j;
>> uint8_t *dst[4];
>> for (index=0; index<4; index++) {
>> - dst[index] = s->picture_ptr->data[index]
>> - + s->picture_ptr->linesize
Re: [FFmpeg-devel] [PATCH 2/5] avcodec/mjpegdec: Don't create unnecessary AVFrame reference
On 4/14/2022 12:57 PM, Andreas Rheinhardt wrote:
MJPEG is an intra-codec, so it makes no sense to keep the reference.
It is basically unused lateron anyway.
Wouldn't this mean you can remove the AV_GET_BUFFER_FLAG_REF flag from
the ff_get_buffer() call?
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mjpegdec.c | 45 +--
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 0e76bf4c26..939dedce33 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2589,8 +2589,7 @@ eoi_parser:
av_freep(&s->hwaccel_picture_private);
}
-if ((ret = av_frame_ref(frame, s->picture_ptr)) < 0)
-return ret;
+av_frame_move_ref(frame, s->picture_ptr);
s->got_picture = 0;
frame->pkt_dts = s->pkt->dts;
@@ -2675,9 +2674,9 @@ the_end:
if (ret)
return ret;
-av_assert0(s->nb_components == av_pix_fmt_count_planes(s->picture_ptr->format));
+av_assert0(s->nb_components == av_pix_fmt_count_planes(frame->format));
for (p = 0; pnb_components; p++) {
-uint8_t *line = s->picture_ptr->data[p];
+uint8_t *line = frame->data[p];
int w = s->width;
int h = s->height;
if (!s->upscale_h[p])
@@ -2737,7 +2736,7 @@ the_end:
if (ret)
return ret;
-av_assert0(s->nb_components == av_pix_fmt_count_planes(s->picture_ptr->format));
+av_assert0(s->nb_components == av_pix_fmt_count_planes(frame->format));
for (p = 0; p < s->nb_components; p++) {
uint8_t *dst;
int w = s->width;
@@ -2748,10 +2747,10 @@ the_end:
w = AV_CEIL_RSHIFT(w, hshift);
h = AV_CEIL_RSHIFT(h, vshift);
}
-dst = &((uint8_t *)s->picture_ptr->data[p])[(h - 1) *
s->linesize[p]];
+dst = &frame->data[p][(h - 1) * s->linesize[p]];
for (i = h - 1; i; i--) {
-uint8_t *src1 = &((uint8_t *)s->picture_ptr->data[p])[i *
s->upscale_v[p] / (s->upscale_v[p] + 1) * s->linesize[p]];
-uint8_t *src2 = &((uint8_t *)s->picture_ptr->data[p])[(i + 1) *
s->upscale_v[p] / (s->upscale_v[p] + 1) * s->linesize[p]];
+uint8_t *src1 = &frame->data[p][ i * s->upscale_v[p] /
(s->upscale_v[p] + 1) * s->linesize[p]];
+uint8_t *src2 = &frame->data[p][(i + 1) * s->upscale_v[p] /
(s->upscale_v[p] + 1) * s->linesize[p]];
if (s->upscale_v[p] != 2 && (src1 == src2 || i == h - 1)) {
memcpy(dst, src1, w);
} else {
@@ -2768,36 +2767,36 @@ the_end:
if (ret)
return ret;
-av_assert0(s->nb_components == av_pix_fmt_count_planes(s->picture_ptr->format));
+av_assert0(s->nb_components == av_pix_fmt_count_planes(frame->format));
for (index=0; indexnb_components; index++) {
-uint8_t *dst = s->picture_ptr->data[index];
-int w = s->picture_ptr->width;
-int h = s->picture_ptr->height;
+uint8_t *dst = frame->data[index];
+int w = frame->width;
+int h = frame->height;
if(index && index<3){
w = AV_CEIL_RSHIFT(w, hshift);
h = AV_CEIL_RSHIFT(h, vshift);
}
if(dst){
-uint8_t *dst2 = dst + s->picture_ptr->linesize[index]*(h-1);
+uint8_t *dst2 = dst + frame->linesize[index]*(h-1);
for (i=0; ipicture_ptr->linesize[index];
-dst2 -= s->picture_ptr->linesize[index];
+dst += frame->linesize[index];
+dst2 -= frame->linesize[index];
}
}
}
}
if (s->adobe_transform == 0 && s->avctx->pix_fmt == AV_PIX_FMT_GBRAP) {
-int w = s->picture_ptr->width;
-int h = s->picture_ptr->height;
+int w = frame->width;
+int h = frame->height;
av_assert0(s->nb_components == 4);
for (i=0; ipicture_ptr->data[index]
- + s->picture_ptr->linesize[index]*i;
+dst[index] = frame->data[index]
+ + frame->linesize[index]*i;
}
for (j=0; jadobe_transform == 2 && s->avctx->pix_fmt == AV_PIX_FMT_YUVA444P) {
-int w = s->picture_ptr->width;
-int h = s->picture_ptr->height;
+int w = frame->width;
+int h = frame->height;
av_assert0(s->nb_components == 4);
for (i=0; ipicture_ptr->data[index]
- + s->picture_ptr->linesize[index]*i;
+dst[index] = frame->data[index]
+ + frame->linesize[index]*i;
}
for (j=
[FFmpeg-devel] [PATCH 5/5] avcodec/mjpegbdec: Don't use GetBit-API for byte-aligned reads
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mjpegbdec.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/libavcodec/mjpegbdec.c b/libavcodec/mjpegbdec.c
index 46b9eb377e..50fff2562b 100644
--- a/libavcodec/mjpegbdec.c
+++ b/libavcodec/mjpegbdec.c
@@ -27,12 +27,15 @@
#include
#include "avcodec.h"
+#include "bytestream.h"
#include "codec_internal.h"
#include "mjpeg.h"
#include "mjpegdec.h"
-static uint32_t read_offs(AVCodecContext *avctx, GetBitContext *gb, uint32_t
size, const char *err_msg){
-uint32_t offs= get_bits_long(gb, 32);
+static uint32_t read_offs(AVCodecContext *avctx, GetByteContext *gb,
+ uint32_t size, const char *err_msg)
+{
+uint32_t offs = bytestream2_get_be32u(gb);
if(offs >= size){
av_log(avctx, AV_LOG_WARNING, err_msg, offs, size);
return 0;
@@ -47,7 +50,7 @@ static int mjpegb_decode_frame(AVCodecContext *avctx, AVFrame
*rframe,
int buf_size = avpkt->size;
MJpegDecodeContext *s = avctx->priv_data;
const uint8_t *buf_end, *buf_ptr;
-GetBitContext hgb; /* for the header */
+GetByteContext hgb; /* for the header */
uint32_t dqt_offs, dht_offs, sof_offs, sos_offs, second_field_offs;
uint32_t field_size, sod_offs;
int ret;
@@ -64,21 +67,22 @@ read_header:
s->restart_count = 0;
s->mjpb_skiptosod = 0;
-if (buf_end - buf_ptr >= 1 << 28)
+if (buf_end - buf_ptr >= 1 << 28 ||
+buf_end - buf_ptr < 40 /* header size */)
return AVERROR_INVALIDDATA;
-init_get_bits(&hgb, buf_ptr, /*buf_size*/(buf_end - buf_ptr)*8);
+bytestream2_init(&hgb, buf_ptr, buf_end - buf_ptr);
-skip_bits(&hgb, 32); /* reserved zeros */
+bytestream2_skipu(&hgb, 4); /* reserved zeros */
-if (get_bits_long(&hgb, 32) != MKBETAG('m','j','p','g')) {
+if (bytestream2_get_be32u(&hgb) != MKBETAG('m','j','p','g')) {
av_log(avctx, AV_LOG_WARNING, "not mjpeg-b (bad fourcc)\n");
return AVERROR_INVALIDDATA;
}
-field_size = get_bits_long(&hgb, 32); /* field size */
+field_size = bytestream2_get_be32u(&hgb); /* field size */
av_log(avctx, AV_LOG_DEBUG, "field size: 0x%"PRIx32"\n", field_size);
-skip_bits(&hgb, 32); /* padded field size */
+bytestream2_skipu(&hgb, 4); /* padded field size */
second_field_offs = read_offs(avctx, &hgb, buf_end - buf_ptr,
"second_field_offs is %d and size is %d\n");
av_log(avctx, AV_LOG_DEBUG, "second field offs: 0x%"PRIx32"\n",
second_field_offs);
--
2.32.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 3/5] avcodec/mjpegdec: Avoid copying data when flipping image
Basically reverts af15c17daa5d8d2940c0263ba4d3ecec761c11ee.
Flipping a picture by modifying the pointers is so common
that even users of direct rendering should take it into account.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mjpegdec.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 939dedce33..33beda12ea 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2762,28 +2762,18 @@ the_end:
}
}
if (s->flipped && !s->rgb) {
-int j;
ret = av_pix_fmt_get_chroma_sub_sample(s->avctx->pix_fmt, &hshift,
&vshift);
if (ret)
return ret;
av_assert0(s->nb_components == av_pix_fmt_count_planes(frame->format));
for (index=0; indexnb_components; index++) {
-uint8_t *dst = frame->data[index];
-int w = frame->width;
int h = frame->height;
-if(index && index<3){
-w = AV_CEIL_RSHIFT(w, hshift);
+if (index && index < 3)
h = AV_CEIL_RSHIFT(h, vshift);
-}
-if(dst){
-uint8_t *dst2 = dst + frame->linesize[index]*(h-1);
-for (i=0; ilinesize[index];
-dst2 -= frame->linesize[index];
-}
+if (frame->data[index]) {
+frame->data[index] += (h - 1) * frame->linesize[index];
+frame->linesize[index] *= -1;
}
}
}
--
2.32.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 4/5] avcodec/mjpegbdec: Don't create unnecessary AVFrame reference
MJPEG-B is an intra-codec, so it makes no sense to keep the reference.
It is unused lateron anyway.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mjpegbdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mjpegbdec.c b/libavcodec/mjpegbdec.c
index 8c1809e5fb..46b9eb377e 100644
--- a/libavcodec/mjpegbdec.c
+++ b/libavcodec/mjpegbdec.c
@@ -144,8 +144,8 @@ read_header:
return buf_size;
}
-if ((ret = av_frame_ref(rframe, s->picture_ptr)) < 0)
-return ret;
+av_frame_move_ref(rframe, s->picture_ptr);
+s->got_picture = 0;
*got_frame = 1;
if (!s->lossless && avctx->debug & FF_DEBUG_QP) {
--
2.32.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/5] avcodec/mjpegdec: Don't create unnecessary AVFrame reference
MJPEG is an intra-codec, so it makes no sense to keep the reference.
It is basically unused lateron anyway.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mjpegdec.c | 45 +--
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 0e76bf4c26..939dedce33 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2589,8 +2589,7 @@ eoi_parser:
av_freep(&s->hwaccel_picture_private);
}
-if ((ret = av_frame_ref(frame, s->picture_ptr)) < 0)
-return ret;
+av_frame_move_ref(frame, s->picture_ptr);
s->got_picture = 0;
frame->pkt_dts = s->pkt->dts;
@@ -2675,9 +2674,9 @@ the_end:
if (ret)
return ret;
-av_assert0(s->nb_components ==
av_pix_fmt_count_planes(s->picture_ptr->format));
+av_assert0(s->nb_components == av_pix_fmt_count_planes(frame->format));
for (p = 0; pnb_components; p++) {
-uint8_t *line = s->picture_ptr->data[p];
+uint8_t *line = frame->data[p];
int w = s->width;
int h = s->height;
if (!s->upscale_h[p])
@@ -2737,7 +2736,7 @@ the_end:
if (ret)
return ret;
-av_assert0(s->nb_components ==
av_pix_fmt_count_planes(s->picture_ptr->format));
+av_assert0(s->nb_components == av_pix_fmt_count_planes(frame->format));
for (p = 0; p < s->nb_components; p++) {
uint8_t *dst;
int w = s->width;
@@ -2748,10 +2747,10 @@ the_end:
w = AV_CEIL_RSHIFT(w, hshift);
h = AV_CEIL_RSHIFT(h, vshift);
}
-dst = &((uint8_t *)s->picture_ptr->data[p])[(h - 1) *
s->linesize[p]];
+dst = &frame->data[p][(h - 1) * s->linesize[p]];
for (i = h - 1; i; i--) {
-uint8_t *src1 = &((uint8_t *)s->picture_ptr->data[p])[i *
s->upscale_v[p] / (s->upscale_v[p] + 1) * s->linesize[p]];
-uint8_t *src2 = &((uint8_t *)s->picture_ptr->data[p])[(i + 1)
* s->upscale_v[p] / (s->upscale_v[p] + 1) * s->linesize[p]];
+uint8_t *src1 = &frame->data[p][ i * s->upscale_v[p] /
(s->upscale_v[p] + 1) * s->linesize[p]];
+uint8_t *src2 = &frame->data[p][(i + 1) * s->upscale_v[p] /
(s->upscale_v[p] + 1) * s->linesize[p]];
if (s->upscale_v[p] != 2 && (src1 == src2 || i == h - 1)) {
memcpy(dst, src1, w);
} else {
@@ -2768,36 +2767,36 @@ the_end:
if (ret)
return ret;
-av_assert0(s->nb_components ==
av_pix_fmt_count_planes(s->picture_ptr->format));
+av_assert0(s->nb_components == av_pix_fmt_count_planes(frame->format));
for (index=0; indexnb_components; index++) {
-uint8_t *dst = s->picture_ptr->data[index];
-int w = s->picture_ptr->width;
-int h = s->picture_ptr->height;
+uint8_t *dst = frame->data[index];
+int w = frame->width;
+int h = frame->height;
if(index && index<3){
w = AV_CEIL_RSHIFT(w, hshift);
h = AV_CEIL_RSHIFT(h, vshift);
}
if(dst){
-uint8_t *dst2 = dst + s->picture_ptr->linesize[index]*(h-1);
+uint8_t *dst2 = dst + frame->linesize[index]*(h-1);
for (i=0; ipicture_ptr->linesize[index];
-dst2 -= s->picture_ptr->linesize[index];
+dst += frame->linesize[index];
+dst2 -= frame->linesize[index];
}
}
}
}
if (s->adobe_transform == 0 && s->avctx->pix_fmt == AV_PIX_FMT_GBRAP) {
-int w = s->picture_ptr->width;
-int h = s->picture_ptr->height;
+int w = frame->width;
+int h = frame->height;
av_assert0(s->nb_components == 4);
for (i=0; ipicture_ptr->data[index]
- + s->picture_ptr->linesize[index]*i;
+dst[index] = frame->data[index]
+ + frame->linesize[index]*i;
}
for (j=0; jadobe_transform == 2 && s->avctx->pix_fmt == AV_PIX_FMT_YUVA444P) {
-int w = s->picture_ptr->width;
-int h = s->picture_ptr->height;
+int w = frame->width;
+int h = frame->height;
av_assert0(s->nb_components == 4);
for (i=0; ipicture_ptr->data[index]
- + s->picture_ptr->linesize[index]*i;
+dst[index] = frame->data[index]
+ + frame->linesize[index]*i;
}
for (j=0; jhttps://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/5] avcodec/mjpegdec: Always reset got_picture at the beginnig of decoding
Said field is set when parsing a SOF; yet a picture is only allocated
if skip_frame is != AVDISCARD_ALL. This leads to a crash in the
following case: If a jpeg is split into two parts, the first containing
everything before the scans including the SOF and the second part
containing the rest, and the first part is sent to the decoder with
skip_frame set to AVDISCARD_ALL, got_picture is set, yet no picture
is allocated. If the next part is sent with skip_frame set to
AVDISCARD_NONE, the code presumes that a picture has been allocated,
although it hasn't leading to segfaults.
Fix this by resetting got_picture at the beginning of decoding.
Signed-off-by: Andreas Rheinhardt
---
This patch presumes that there is not use-case for partitioning
the data corresponding to a single AVFrame accross multiple packets.
I am not certain whether this is actually true, in particular
wrt interlaced input where it might be common to put the data for
one field into one packet.
Anyway, no such use is covered by FATE.
libavcodec/mjpegdec.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 32874a5a19..0e76bf4c26 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2419,6 +2419,7 @@ int ff_mjpeg_receive_frame(AVCodecContext *avctx, AVFrame
*frame)
av_dict_free(&s->exif_metadata);
av_freep(&s->stereo3d);
s->adobe_transform = -1;
+s->got_picture = 0;
if (s->iccnum != 0)
reset_icc_profile(s);
@@ -2578,7 +2579,6 @@ eoi_parser:
break;
}
if (avctx->skip_frame == AVDISCARD_ALL) {
-s->got_picture = 0;
ret = AVERROR(EAGAIN);
goto the_end_no_picture;
}
@@ -2651,7 +2651,6 @@ skip:
av_log(avctx, AV_LOG_FATAL, "No JPEG data found in image\n");
return AVERROR_INVALIDDATA;
fail:
-s->got_picture = 0;
return ret;
the_end:
@@ -2987,10 +2986,9 @@ av_cold int ff_mjpeg_decode_end(AVCodecContext *avctx)
return 0;
}
-static void decode_flush(AVCodecContext *avctx)
+static void smv_decode_flush(AVCodecContext *avctx)
{
MJpegDecodeContext *s = avctx->priv_data;
-s->got_picture = 0;
s->smv_next_frame = 0;
av_frame_unref(s->smv_frame);
@@ -3021,7 +3019,6 @@ const FFCodec ff_mjpeg_decoder = {
.init = ff_mjpeg_decode_init,
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
-.flush = decode_flush,
.p.capabilities = AV_CODEC_CAP_DR1,
.p.max_lowres = 3,
.p.priv_class = &mjpegdec_class,
@@ -3049,7 +3046,6 @@ const FFCodec ff_thp_decoder = {
.init = ff_mjpeg_decode_init,
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
-.flush = decode_flush,
.p.capabilities = AV_CODEC_CAP_DR1,
.p.max_lowres = 3,
.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE | FF_CODEC_CAP_INIT_CLEANUP
|
@@ -3067,7 +3063,7 @@ const FFCodec ff_smvjpeg_decoder = {
.init = ff_mjpeg_decode_init,
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
-.flush = decode_flush,
+.flush = smv_decode_flush,
.p.capabilities = AV_CODEC_CAP_DR1,
.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE |
FF_CODEC_CAP_EXPORTS_CROPPING |
FF_CODEC_CAP_SETS_PKT_DTS | FF_CODEC_CAP_INIT_CLEANUP,
--
2.32.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 v1] avformat/ipfsgateway: define PATH_MAX
On Thu, Apr 14, 2022 at 3:41 PM Martin Storsjö wrote:
> On Thu, 14 Apr 2022, Mark Gaiser wrote:
>
> > On Thu, Apr 14, 2022 at 10:25 AM Martin Storsjö
> wrote:
> >
> >> On Wed, 13 Apr 2022, Mark Gaiser wrote:
> >>
> >> > On Wed, Apr 13, 2022 at 5:21 PM Mark Gaiser
> wrote:
> >> >
> >> >> PATH_MAX is posix. Some compilers (MSVC) don't define this
> >> >> thus failing to compile the ipfsgateway file.
> >> >> Defining it fixes the compile.
> >> >>
> >> >> Signed-off-by: Mark Gaiser
> >> >> ---
> >> >> libavformat/ipfsgateway.c | 6 ++
> >> >> 1 file changed, 6 insertions(+)
> >> >>
> >> >> diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c
> >> >> index ed37e552dd..9b0d3dea59 100644
> >> >> --- a/libavformat/ipfsgateway.c
> >> >> +++ b/libavformat/ipfsgateway.c
> >> >> @@ -25,6 +25,12 @@
> >> >> #include "os_support.h"
> >> >> #include "url.h"
> >> >>
> >> >> +// Define the posix PATH_MAX if not there already.
> >> >> +// This fixes a compile issue for MSVC.
> >> >> +#ifndef PATH_MAX
> >> >> +#define PATH_MAX 4096
> >> >> +#endif
> >> >> +
> >> >> typedef struct IPFSGatewayContext {
> >> >> AVClass *class;
> >> >> URLContext *inner;
> >> >> --
> >> >> 2.35.1
> >> >
> >> > I did verify the size of PATH_MAX. On my pc (arch with GCC compiler)
> >> > this value is defined as 4096. That seems enough to me. Another way to
> >> > fix this is to add it in os_support.h. I didn't add it there because
> >> > ipfsgateway.c is currently the only cross-platform code that makes use
> >> > of this.
> >> >
> >> > Lastly, I don't have an MSVC compiler and windows to test this on.
> >> > I hope someone else in that setup can verify that this does indeed fix
> >> the
> >> > ffmpeg master build?
> >>
> >> This looks like a reasonable fix to at least make things build correctly
> >> again (and it does fix the issue).
> >>
> >> FWIW, the corresponding Windows define is MAX_PATH, which usually is
> 260,
> >> so setting it to 4096 here is probably more than enough if a hardcoded
> >> value is needed.
> >>
> >> // Martin
> >>
> >
> > Glad it works! Thank you for testing.
> >
> > I don't have commit/merge powers so I leave that in the capable hands of
> > those that can.
>
> I already pushed this one - I forgot to explicitly spell that out in the
> previous message.
>
Awesome :) Thank you!
>
> // Martin
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-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 v1] avformat/ipfsgateway: define PATH_MAX
On Thu, 14 Apr 2022, Mark Gaiser wrote:
On Thu, Apr 14, 2022 at 10:25 AM Martin Storsjö wrote:
On Wed, 13 Apr 2022, Mark Gaiser wrote:
> On Wed, Apr 13, 2022 at 5:21 PM Mark Gaiser wrote:
>
>> PATH_MAX is posix. Some compilers (MSVC) don't define this
>> thus failing to compile the ipfsgateway file.
>> Defining it fixes the compile.
>>
>> Signed-off-by: Mark Gaiser
>> ---
>> libavformat/ipfsgateway.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c
>> index ed37e552dd..9b0d3dea59 100644
>> --- a/libavformat/ipfsgateway.c
>> +++ b/libavformat/ipfsgateway.c
>> @@ -25,6 +25,12 @@
>> #include "os_support.h"
>> #include "url.h"
>>
>> +// Define the posix PATH_MAX if not there already.
>> +// This fixes a compile issue for MSVC.
>> +#ifndef PATH_MAX
>> +#define PATH_MAX 4096
>> +#endif
>> +
>> typedef struct IPFSGatewayContext {
>> AVClass *class;
>> URLContext *inner;
>> --
>> 2.35.1
>
> I did verify the size of PATH_MAX. On my pc (arch with GCC compiler)
> this value is defined as 4096. That seems enough to me. Another way to
> fix this is to add it in os_support.h. I didn't add it there because
> ipfsgateway.c is currently the only cross-platform code that makes use
> of this.
>
> Lastly, I don't have an MSVC compiler and windows to test this on.
> I hope someone else in that setup can verify that this does indeed fix
the
> ffmpeg master build?
This looks like a reasonable fix to at least make things build correctly
again (and it does fix the issue).
FWIW, the corresponding Windows define is MAX_PATH, which usually is 260,
so setting it to 4096 here is probably more than enough if a hardcoded
value is needed.
// Martin
Glad it works! Thank you for testing.
I don't have commit/merge powers so I leave that in the capable hands of
those that can.
I already pushed this one - I forgot to explicitly spell that out in the
previous message.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avformat/ipfsgateway: define PATH_MAX
On Thu, Apr 14, 2022 at 10:25 AM Martin Storsjö wrote:
> On Wed, 13 Apr 2022, Mark Gaiser wrote:
>
> > On Wed, Apr 13, 2022 at 5:21 PM Mark Gaiser wrote:
> >
> >> PATH_MAX is posix. Some compilers (MSVC) don't define this
> >> thus failing to compile the ipfsgateway file.
> >> Defining it fixes the compile.
> >>
> >> Signed-off-by: Mark Gaiser
> >> ---
> >> libavformat/ipfsgateway.c | 6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c
> >> index ed37e552dd..9b0d3dea59 100644
> >> --- a/libavformat/ipfsgateway.c
> >> +++ b/libavformat/ipfsgateway.c
> >> @@ -25,6 +25,12 @@
> >> #include "os_support.h"
> >> #include "url.h"
> >>
> >> +// Define the posix PATH_MAX if not there already.
> >> +// This fixes a compile issue for MSVC.
> >> +#ifndef PATH_MAX
> >> +#define PATH_MAX 4096
> >> +#endif
> >> +
> >> typedef struct IPFSGatewayContext {
> >> AVClass *class;
> >> URLContext *inner;
> >> --
> >> 2.35.1
> >
> > I did verify the size of PATH_MAX. On my pc (arch with GCC compiler)
> > this value is defined as 4096. That seems enough to me. Another way to
> > fix this is to add it in os_support.h. I didn't add it there because
> > ipfsgateway.c is currently the only cross-platform code that makes use
> > of this.
> >
> > Lastly, I don't have an MSVC compiler and windows to test this on.
> > I hope someone else in that setup can verify that this does indeed fix
> the
> > ffmpeg master build?
>
> This looks like a reasonable fix to at least make things build correctly
> again (and it does fix the issue).
>
> FWIW, the corresponding Windows define is MAX_PATH, which usually is 260,
> so setting it to 4096 here is probably more than enough if a hardcoded
> value is needed.
>
> // Martin
>
Glad it works! Thank you for testing.
I don't have commit/merge powers so I leave that in the capable hands of
those that can.
>
> ___
> 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 5/5] avcodec/x86/hevc_mc: add qpel_h64_8_avx512icl
Ping! Wu Jianhua: >Henrik Gramner: >> Sent: Friday, March 11, 2022 10:51 PM >> To: FFmpeg development discussions and patches > devel at ffmpeg.org> >> Subject: Re: [FFmpeg-devel] [PATCH v2 5/5] avcodec/x86/hevc_mc: add >> qpel_h64_8_avx512icl >> >> All 5/5 LGTM. >> > >Hi there, > >Are there any more comments or objections here? >If not, could someone help push this patchset? > >Many thanks! >Jianhua > ___ 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] libavutil/hwcontext_vulkan: Fix VK_FORMAT_R8G8_UNORM and VK_FORMAT_R16G16_UNORM map problem on Vulkan
13 Apr 2022, 08:05 by haihao.xiang-at-intel@ffmpeg.org:
> On Wed, 2022-03-30 at 11:41 +0800, Wenbin Chen wrote:
>
>> Vulkan map both DRM_FORMAT_RG88 and DRM_FORMAT_GR88 to
>> VK_FORMAT_R8G8_UNORM. This cannot distinguish nv12/nv24 and nv21/nv42.
>> Vulkan also map both DRM_FORMAT_RG1616 and DRM_FORMAT_GR1616 to
>> VK_FORMAT_R16G16_UNORM. This causes issue when map back.
>> VK_FORMAT_R16G16 will be mapped to DRM_FORMAT_GR1616, while p010 need
>> DRM_FORMAT_RG1616.
>> Add sw_format check to vulkan_fmt_to_drm() to fix this problem.
>>
>> Signed-off-by: Wenbin Chen
>> ---
>> libavutil/hwcontext_vulkan.c | 13 +++--
>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
>> index 237caa4bc0..791649001f 100644
>> --- a/libavutil/hwcontext_vulkan.c
>> +++ b/libavutil/hwcontext_vulkan.c
>> @@ -3290,8 +3290,17 @@ static void vulkan_unmap_to_drm(AVHWFramesContext
>> *hwfc, HWMapDescriptor *hwmap)
>> av_free(drm_desc);
>> }
>>
>> -static inline uint32_t vulkan_fmt_to_drm(VkFormat vkfmt)
>> +static inline uint32_t vulkan_fmt_to_drm(VkFormat vkfmt,
>> + enum AVPixelFormat sw_format)
>> {
>> +if (vkfmt == VK_FORMAT_R8G8_UNORM &&
>> + (sw_format == AV_PIX_FMT_NV12 || sw_format == AV_PIX_FMT_NV24))
>> +return DRM_FORMAT_RG88;
>> +
>> +if (vkfmt == VK_FORMAT_R16G16_UNORM &&
>> + (sw_format == AV_PIX_FMT_P010 || sw_format == AV_PIX_FMT_P016))
>> +return DRM_FORMAT_RG1616;
>> +
>> for (int i = 0; i < FF_ARRAY_ELEMS(vulkan_drm_format_map); i++)
>> if (vulkan_drm_format_map[i].vk_format == vkfmt)
>> return vulkan_drm_format_map[i].drm_fourcc;
>> @@ -3373,7 +3382,7 @@ static int vulkan_map_to_drm(AVHWFramesContext *hwfc,
>> AVFrame *dst,
>> };
>> VkFormat plane_vkfmt = av_vkfmt_from_pixfmt(hwfc->sw_format)[i];
>>
>> -drm_desc->layers[i].format= vulkan_fmt_to_drm(plane_vkfmt);
>> +drm_desc->layers[i].format= vulkan_fmt_to_drm(plane_vkfmt, hwfc-
>> >sw_format);
>> drm_desc->layers[i].nb_planes = 1;
>>
>> if (drm_desc->layers[i].format == DRM_FORMAT_INVALID) {
>>
>
> Patchset LGTM
>
I'll hold off on pushing all of your and Wenbin's Vulkan patches for now.
Your hacks for cheap hardware have seriously broken image
and memory allocation for anyone who doesn't care about
your niche use cases, and of course it's up to me to salvage it.
What's worse, I don't know if it's your drivers that are at fault,
or if it's your patches that are at fault, or both.
I already had to rip all of your patches off just to get Vulkan
Video decoding working.
Pushing any more code will just create even more mess for me
to deal with, and I'm already knee-deep in it trying to work around
the Khronos user synchronized object madness.
You'll just have to wait for me to fix them, unless you think you
can fix them yourselves, which I doubt. I may have to partially
revert your patches too, because right now, everything's
pretty broken.
___
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] avfilter: add feedback video filter
Will apply soon, as there are no comments against. ___ 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] avfilter: add pixelize video filter
relatively trivial filter, gonna apply soon. ___ 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] [RFC] Switching ffmpeg.c to a threaded architecture
On Wed, Apr 13, 2022 at 12:43 AM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Paul > > B Mahol > > Sent: Tuesday, April 12, 2022 11:29 AM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > architecture > > > > On Mon, Apr 11, 2022 at 10:58 PM Soft Works > > wrote: > > > > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > Paul > > > > B Mahol > > > > Sent: Monday, April 11, 2022 10:52 PM > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > > > architecture > > > > > > > > On Mon, Apr 11, 2022 at 10:10 PM Soft Works > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: ffmpeg-devel On Behalf > > Of > > > > > > Anton Khirnov > > > > > > Sent: Monday, April 11, 2022 10:29 AM > > > > > > To: FFmpeg development discussions and patches > > > > > de...@ffmpeg.org> > > > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a > > threaded > > > > > > architecture > > > > > > > > > > > > Quoting Soft Works (2022-04-08 17:27:10) > > > > > > > > Furthermore, remember that this is just the first step. > > There > > > > will > > > > > > be > > > > > > > > further patchsets converting the other components. I > > intend to > > > > > > > > upstream > > > > > > > > them gradually one after the other. Your suggestion would > > > > require > > > > > > me > > > > > > > > to > > > > > > > > instead write the whole thing at once, fighting rebase > > > > conflicts > > > > > > all > > > > > > > > the > > > > > > > > way, and then submit it as a giant utterly unreviewable > > > > patchset. > > > > > > > > > > > > > > That's not what I meant, but anyway it's not worth > > discussing > > > > when > > > > > > > it's a minority opinion. > > > > > > > > > > > > > > Just a practical question instead for planning purposes: > > > > > > > > > > > > > > Which timeframe do you expect for the whole process? > > > > > > > When do you plan to start > > > > > > > > > > > > If you mean "start pushing the patches", then I intend to do > > that > > > > as > > > > > > they are reviewed and approved. I hope to send the > > upstreamable > > > > > > version > > > > > > of this set this week, if nobody has strong objectsions then I > > > > might > > > > > > push it after vacation, i.e. late April/early May. > > > > > > > > > > > > > and for how long do you think it will take until all further > > > > > > patchsets > > > > > > > will be submitted/applied? > > > > > > > > > > > > This is very hard to estimate accurately. A pessimistic guess > > > > assuming > > > > > > I > > > > > > get stuck on every stupid thing would be end of this year, but > > I > > > > hope > > > > > > for things to go much faster. > > > > > > > > > > Thanks for the reply. I'm asking because I need to decide about > > the > > > > > way I'm going to proceed with the subtitle filtering patchset. > > > > > > > > > > I think I will have to keep and continue this in private during > > this > > > > > procedure as I don't have the resources to regularly adapt and > > sync > > > > > from my (5.0 based) working branch back to the master branch. > > > > > > > > > > > > > > That is big waste of resource when not implementing thing > > properly. > > > > > > From my point of view, somebody who has never given any detailed > > > reviews, didn't state what exactly(!) he would consider to be > > "improper" > > > and never made any suggestion how the implementation would need to > > > be changed to become "proper" - doesn't have the right to make such > > > claims. > > > > > > > You never asked kindly. > > I have always asked you kindly, probably more kindly than many > others do (going through history, I just found many very kind > questions I've been asking you). > > For the specific issue about the subtitles patchset, you jumped > in on IRC, saying "it's a hack". I had asked you (kindly!) what > makes you think that it would be a hack and what you would think needs > to be changed. You never answered the question since that time, > instead you kept labeling it in all those ways. > > > I think the fundamental problem about the current situation is > that there were discussions with several other developers whose > arguments were based on theoretical considerations after reviewing > the code but without having actually worked with it and gone > through all the real-world situations that exist. > > My code though, is made to provision for all cases by providing > a high level of flexibility, which is done by having timing fields > that are redundant in some cases but are needed (and non-redundant) > in other cases. Full coverage of cases is elementary for me, though; > I can't drop it, like somebody had suggested. > > As a matter of fact, I see two chances:
Re: [FFmpeg-devel] [PATCH v1] avformat/ipfsgateway: define PATH_MAX
On Wed, 13 Apr 2022, Mark Gaiser wrote:
On Wed, Apr 13, 2022 at 5:21 PM Mark Gaiser wrote:
PATH_MAX is posix. Some compilers (MSVC) don't define this
thus failing to compile the ipfsgateway file.
Defining it fixes the compile.
Signed-off-by: Mark Gaiser
---
libavformat/ipfsgateway.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c
index ed37e552dd..9b0d3dea59 100644
--- a/libavformat/ipfsgateway.c
+++ b/libavformat/ipfsgateway.c
@@ -25,6 +25,12 @@
#include "os_support.h"
#include "url.h"
+// Define the posix PATH_MAX if not there already.
+// This fixes a compile issue for MSVC.
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
+
typedef struct IPFSGatewayContext {
AVClass *class;
URLContext *inner;
--
2.35.1
I did verify the size of PATH_MAX. On my pc (arch with GCC compiler)
this value is defined as 4096. That seems enough to me. Another way to
fix this is to add it in os_support.h. I didn't add it there because
ipfsgateway.c is currently the only cross-platform code that makes use
of this.
Lastly, I don't have an MSVC compiler and windows to test this on.
I hope someone else in that setup can verify that this does indeed fix the
ffmpeg master build?
This looks like a reasonable fix to at least make things build correctly
again (and it does fix the issue).
FWIW, the corresponding Windows define is MAX_PATH, which usually is 260,
so setting it to 4096 here is probably more than enough if a hardcoded
value is needed.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavcodec/videotoolboxenc.c: add option to hevc encoder to prioritize speed.
Hi,
Am 14.04.22 um 08:48 schrieb Simone Karin Lehmann:
Somehow it seems, that this patch never got onto the mailing list. So may I
kindly ask you to review it.
--
Stay hungry, stay foolish
Am 26.01.2022 um 17:31 schrieb Simone Karin Lehmann :
The patch adds an option to the hevc_videotoolbox encoder to prioritize speed
for Macs with Apple Silicon CPU.
This speeds up encodings up to 50% - 70%. In conjunction with the qcale option
-q, visible quality will be unchanged. The increase in file size is very
moderate, although still depending on the source material.
Signed-off-by: Simone Karin Lehmann
---
libavcodec/videotoolboxenc.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 418ff00b8d..ab0dad6cbc 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -236,6 +236,7 @@ typedef struct VTEncContext {
int allow_sw;
int require_sw;
double alpha_quality;
+int64_t prio_speed;
int64_t is definitely overkill.
bool flushing;
int has_b_frames;
@@ -1145,6 +1146,17 @@ static int vtenc_create_encoder(AVCodecContext *avctx,
return AVERROR_EXTERNAL;
}
+// prioritize speed over quality
+if (vtctx->prio_speed) {
+status = VTSessionSetProperty(vtctx->session,
+
kVTCompressionPropertyKey_PrioritizeEncodingSpeedOverQuality,
+ kCFBooleanTrue);
+if (status) {
+av_log(avctx, AV_LOG_ERROR, "Error setting
PrioritizeEncodingSpeedOverQuality property: %d\n", status);
+return AVERROR_EXTERNAL;
+}
If its called to priotize speed over qual, why not just print a warning and
continue without this option?
+}
+
if ((vtctx->codec_id == AV_CODEC_ID_H264 || vtctx->codec_id ==
AV_CODEC_ID_HEVC)
&& max_rate > 0) {
bytes_per_second_value = max_rate >> 3;
@@ -2744,6 +2756,7 @@ static const AVOption hevc_options[] = {
{ "main10", "Main10 Profile", 0, AV_OPT_TYPE_CONST, { .i64 = HEVC_PROF_MAIN10 },
INT_MIN, INT_MAX, VE, "profile" },
{ "alpha_quality", "Compression quality for the alpha channel",
OFFSET(alpha_quality), AV_OPT_TYPE_DOUBLE, { .dbl = 0.0 }, 0.0, 1.0, VE },
+{ "prio_speed", "prioritize encoding speed", OFFSET(prio_speed),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
Just use an int.
Thanks,
Thilo
___
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] lavfi: Add blurriness filter
Am 05.04.22 um 10:56 schrieb Thilo Borgmann: Hi, v3 updated to current HEAD. Named blurdetect filter now. Minor fixes on allocation and removed -f option. Please make this per plane filtering, with default to measure only first plane. done in v4. (Will add Changelog, version.h and fate test once the filter itself looks ok) Ping. -Thilo ___ 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".
