Re: [FFmpeg-devel] [PATCH v3 1/1] avcodec/vp6: return value check for init_get_bits
On Thu, Aug 26, 2021 at 05:08:15AM +, Maryam Ebrahimzadeh wrote: > Thanks, > So when will you apply this? applied. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] h274: remove optimization pragma
LGTM ___ 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] [RFC] Add option for writing detailed filtergraph information to file or stdout
This is a more complete and more flexible alternative to the recently submitted
patch "fftools: add -lavfi_dump option"
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210823094504.100789-2-geo...@nsup.org/
I'm tagging this patch as 'RFC'. There's no need to tell that this is
duplicating
code from ffprobe. It does, because that's the most efficient way for the code
to
live at my side (unaffected and safe from regressions by upstream changes).
Should it be considered for merging into main, it will likely make sense to
merge
and or re-use ffprobe output writers.
The key benefits of this implementation are:
- Other than graph2dot and other means for printing filter graphs, this is
outputting:
- all graphs with runtime state
(including auto-inserted filters)
- each graph with its inputs and outputs
- all filters with their in- and output pads
- all connections between all input- and output pads
- for each connection:
- the runtime-negotiated format and media type
- the hw context
- if video hw context, both: hw pixfmt + sw pixfmt
- Output can either be printed to stdout or written to specified file
- Output is machine-readable
- Can output in all the same formats like ffprobe (default, compact, flat,
ini, json, xml)
Signed-off-by: softworkz
---
fftools/Makefile|2 +-
fftools/ffmpeg.c| 15 +
fftools/ffmpeg.h|3 +
fftools/ffmpeg_opt.c|9 +
fftools/filterwriters.c | 1547 +++
fftools/filterwriters.h | 193 +
libavcodec/allcodecs.c |1 -
7 files changed, 1768 insertions(+), 2 deletions(-)
create mode 100644 fftools/filterwriters.c
create mode 100644 fftools/filterwriters.h
diff --git a/fftools/Makefile b/fftools/Makefile
index 5234932ab0..384b340018 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -9,7 +9,7 @@ AVBASENAMES = ffmpeg ffplay ffprobe
ALLAVPROGS = $(AVBASENAMES:%=%$(PROGSSUF)$(EXESUF))
ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF))
-OBJS-ffmpeg+= fftools/ffmpeg_opt.o
fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o
+OBJS-ffmpeg+= fftools/ffmpeg_opt.o
fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o fftools/filterwriters.o
ifndef CONFIG_VIDEOTOOLBOX
OBJS-ffmpeg-$(CONFIG_VDA) += fftools/ffmpeg_videotoolbox.o
endif
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index b0ce7c7c32..7ffdc5250c 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -103,6 +103,7 @@
#include "ffmpeg.h"
#include "cmdutils.h"
+#include "filterwriters.h"
#include "libavutil/avassert.h"
@@ -139,6 +140,7 @@ static int64_t decode_error_stat[2];
static unsigned nb_output_dumped = 0;
static int want_sdp = 1;
+static int filtergraphs_printed = 0;
static BenchmarkTimeStamps current_time;
AVIOContext *progress_avio = NULL;
@@ -512,10 +514,23 @@ static int decode_interrupt_cb(void *ctx)
const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL };
+static void check_print_graphs(void)
+{
+if (filtergraphs_printed)
+return;
+
+if (print_graphs || print_graphs_file)
+print_filtergraphs(filtergraphs, nb_filtergraphs);
+
+filtergraphs_printed = 1;
+}
+
static void ffmpeg_cleanup(int ret)
{
int i, j;
+check_print_graphs();
+
if (do_benchmark) {
int maxrss = getmaxrss() / 1024;
av_log(NULL, AV_LOG_INFO, "bench: maxrss=%ikB\n", maxrss);
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index d2dd7ca092..1697f42028 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -636,6 +636,9 @@ extern char *videotoolbox_pixfmt;
extern int filter_nbthreads;
extern int filter_complex_nbthreads;
extern int vstats_version;
+extern int print_graphs;
+extern char* print_graphs_file;
+extern char* print_graphs_format;
extern int auto_conversion_filters;
extern const AVIOInterruptCB int_cb;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 428934a3d8..6ffded5f9d 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -172,6 +172,9 @@ float max_error_rate = 2.0/3;
int filter_nbthreads = 0;
int filter_complex_nbthreads = 0;
int vstats_version = 2;
+int print_graphs = 0;
+char* print_graphs_file = NULL;
+char* print_graphs_format = NULL;
int auto_conversion_filters = 1;
int64_t stats_period = 50;
@@ -3634,6 +3637,12 @@ const OptionDef options[] = {
"create a complex filtergraph", "graph_description" },
{ "filter_complex_script", HAS_ARG | OPT_EXPERT, {
.func_arg = opt_filter_complex_script },
"read complex filtergraph description from a file", "filename" },
+{ "print_graphs", OPT_BOOL,{
&print_graphs },
+"prints filtergraph details to stderr" },
+{ "print_graphs_file", HAS_ARG | OPT_STRING, {
&print_graphs_file },
+"writes graph details to a file", "filename" },
+{ "print_graphs_format", OPT_STRING | HAS_ARG
Re: [FFmpeg-devel] [PATCH] avcodec/truemotion1: Cleanup prediction code in truemotion1_decode_16bit and truemotion1_decode_24bit
On Sat, Aug 14, 2021 at 11:29:40 +, ffmpegandmahanstreamer@e.email wrote:
Just formal stuff:
> /* if macroblock width is 2, apply C-Y-C-Y; else
> * apply C-Y-Y */
> +APPLY_C_PREDICTOR();
> +APPLY_Y_PREDICTOR();
> +OUTPUT_PIXEL_PAIR();
> if (s->block_width == 2) {
Devs prefer that you omit the curly brackets, if the block only
contains one line. (I don't personally agree fully, but that doesn't
matter.)
> -OUTPUT_PIXEL_PAIR();
> + APPLY_C_PREDICTOR();
Indentation seems wrong.
> +OUTPUT_PIXEL_PAIR();
> break;
>
> +
> case 1:
You added an additional empty line.
As much as you praise the "graphical stuff" over the mailing list
approach: Was your graphical editor not capable of showing you these
issues? Hint: Review your commit (git diff before commit, git show
afterwards) before submitting it. (And whether "graphical stuff" is
greater or not, you would still have to correct errors by creating a
modified commit. And with github pull requests, you'd need to re-branch
or to force-push. Not much ease in the process there.)
Moritz
___
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] [RFC] Add option for writing detailed filtergraph information to file or stdout
Soft Works (12021-08-26): > This is a more complete and more flexible alternative to the recently > submitted > patch "fftools: add -lavfi_dump option" > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210823094504.100789-2-geo...@nsup.org/ > > I'm tagging this patch as 'RFC'. There's no need to tell that this is > duplicating > code from ffprobe. It does, because that's the most efficient way for the > code to > live at my side (unaffected and safe from regressions by upstream changes). > > Should it be considered for merging into main, it will likely make sense to > merge > and or re-use ffprobe output writers. > > The key benefits of this implementation are: > > - Other than graph2dot and other means for printing filter graphs, this is > outputting: > - all graphs with runtime state > (including auto-inserted filters) > - each graph with its inputs and outputs > - all filters with their in- and output pads > - all connections between all input- and output pads > - for each connection: > - the runtime-negotiated format and media type > - the hw context > - if video hw context, both: hw pixfmt + sw pixfmt > - Output can either be printed to stdout or written to specified file > - Output is machine-readable > - Can output in all the same formats like ffprobe (default, compact, flat, > ini, json, xml) What is the practical purpose of this feature? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/truemotion1: Cleanup prediction code in truemotion1_decode_16bit and truemotion1_decode_24bit
> -Original Message- > From: ffmpeg-devel On Behalf Of > Moritz Barsnick > Sent: Thursday, 26 August 2021 09:25 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/truemotion1: Cleanup > prediction code in truemotion1_decode_16bit and > truemotion1_decode_24bit > > As much as you praise the "graphical stuff" over the mailing list > approach: Was your graphical editor not capable of showing you these > issues? Hint: Review your commit (git diff before commit, git show > afterwards) before submitting it. (And whether "graphical stuff" is > greater or not, you would still have to correct errors by creating a > modified commit. And with github pull requests, you'd need to re- > branch > or to force-push. Not much ease in the process there.) Force-pushing to the PR branch is nicely easing the process IMO. softworkz ___ 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] [RFC] Add option for writing detailed filtergraph information to file or stdout
Unacceptable, NACK. ___ 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] [RFC] Add option for writing detailed filtergraph information to file or stdout
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Thursday, 26 August 2021 09:34 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing > detailed filtergraph information to file or stdout > > Soft Works (12021-08-26): > > This is a more complete and more flexible alternative to the > recently submitted > > patch "fftools: add -lavfi_dump option" > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210823094504.1007 > 89-2-geo...@nsup.org/ > > > > I'm tagging this patch as 'RFC'. There's no need to tell that this > is duplicating > > code from ffprobe. It does, because that's the most efficient way > for the code to > > live at my side (unaffected and safe from regressions by upstream > changes). > > > > Should it be considered for merging into main, it will likely make > sense to merge > > and or re-use ffprobe output writers. > > > > The key benefits of this implementation are: > > > > - Other than graph2dot and other means for printing filter graphs, > this is > > outputting: > > - all graphs with runtime state > > (including auto-inserted filters) > > - each graph with its inputs and outputs > > - all filters with their in- and output pads > > - all connections between all input- and output pads > > - for each connection: > > - the runtime-negotiated format and media type > > - the hw context > > - if video hw context, both: hw pixfmt + sw pixfmt > > - Output can either be printed to stdout or written to specified > file > > - Output is machine-readable > > - Can output in all the same formats like ffprobe (default, > compact, flat, > > ini, json, xml) > > What is the practical purpose of this feature? The purpose is to get a precise and detailed view of the filtergraphs at runtime including all connections with their negotiated formats and media types. sw ___ 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] [RFC] Add option for writing detailed filtergraph information to file or stdout
Soft Works (12021-08-26): > The purpose is to get a precise and detailed view of the filtergraphs > at runtime including all connections with their negotiated formats and > media types. I asked the purpose, you are rephrasing what the patch does. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing detailed filtergraph information to file or stdout
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Thursday, 26 August 2021 09:40 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing > detailed filtergraph information to file or stdout > > Soft Works (12021-08-26): > > The purpose is to get a precise and detailed view of the > filtergraphs > > at runtime including all connections with their negotiated formats > and > > media types. > > I asked the purpose, you are rephrasing what the patch does. Okay, then let's go back a few years and I'll tell you about my original motivation. I often did not understand why filters couldn't connect to each other or when they did - how they actually connected and which format was actually used between them. In many cases, this wasn't clear from the log output. I've also seen that the format filter got inserted quite often, but I wanted to know exactly where it gets inserted and from which to which format it converts in each case. Another aspect that I needed to understand precisely was the use of formats in case of hw acceleration (sw pixel format); there was no way to see what was being used and negotiated. We are covering a wide range of platforms and hardware accelerations and the requirements are complex: deinterlacing, scaling, color conversion, tone mapping, overlay of graphical and textual subtitles, etc. and all that in arbitrary combinations with almost all ffmpeg-supported hwas. All that needs to work as good as possible on all older and newer hardware, which is not a trivial task. I'm using the output that this patch is creating either for diagnosing, either by manual review or in combination with another tool that allows to visualize those filtergraphs like I had shown last year: https://github.com/softworkz/ffmpegfiltergraphs/issues/1 Does that answer your question? Kind regards, softworkz ___ 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] [RFC] Add option for writing detailed filtergraph information to file or stdout
Soft Works (12021-08-26): > Does that answer your question? Yes. It is almost exactly what I had guessed. And therefore my answer is what I expected it do be: that does not justify thousands, or even hundreds, of lines of code in the core library and tools. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing detailed filtergraph information to file or stdout
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Thursday, 26 August 2021 10:05 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing > detailed filtergraph information to file or stdout > > Soft Works (12021-08-26): > > Does that answer your question? > > Yes. It is almost exactly what I had guessed. And therefore my answer > is > what I expected it do be: that does not justify thousands, or even > hundreds, of lines of code in the core library and tools. Did you actually read the patch message? I just didn't want to waste time for merging the code with the ffprobe writers. The question is whether we could agree about the actual output which is just line 1185-1518 in filterwriters.c. All the rest is just duplicated. softworkz ___ 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] [RFC] Add option for writing detailed filtergraph information to file or stdout
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Thursday, 26 August 2021 10:05 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing > detailed filtergraph information to file or stdout > > Soft Works (12021-08-26): > > Does that answer your question? > > Yes. It is almost exactly what I had guessed. And therefore my answer > is > what I expected it do be: that does not justify thousands, or even > hundreds, of lines of code in the core library and tools. To be clear: I didn't submit this to end up in a LOC count discussion. My point is that there's much more relevant and important information that a filtergraph-information feature should provide than what your proposed patch is outputting. It doesn't make sense to me to add once another half-baked graph-output functionality that provides just a fraction of the relevant information, consisting of just two or three values that a developer is currently interested in (and then praising it for its low LOC count). A new feature for outputting filtergraph information should be complete, comprehensive and provide machine readable output. It doesn't have to be my code, but it should provide similar information (ideally even more). softworkz ___ 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] [RFC] Add option for writing detailed filtergraph information to file or stdout
Soft Works (12021-08-26): > To be clear: I didn't submit this to end up in a LOC count discussion. Good. > My point is that there's much more relevant and important information > that a filtergraph-information feature should provide than what your > proposed patch is outputting. Which one? > comprehensive and provide machine readable output. You are wrong on the "machine readable" point, especially if it means adding a lot of code in the library and more importantly ensuring long-term compatibility. What you want to print is internal information. It is useful for debugging and testing purposes but should not be accessed by regular tools. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/5] libavfilter/x86/vf_gblur: add ff_postscale_slice_avx512()
Paul B Mahol Wrote: > > will apply shortly > Gotcha. Much appreciated. 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] [RFC] Add option for writing detailed filtergraph information to file or stdout
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Thursday, 26 August 2021 11:03 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing > detailed filtergraph information to file or stdout > > Soft Works (12021-08-26): > > To be clear: I didn't submit this to end up in a LOC count > discussion. > > Good. > > > My point is that there's much more relevant and important > information > > that a filtergraph-information feature should provide than what > your > > proposed patch is outputting. > > Which one? All of what my patch is outputting (and ideally even more). Please see here for an example: https://gist.github.com/softworkz/08cd593cebdfb5da3bbe1f6e5683320e > > comprehensive and provide machine readable output. > > You are wrong on the "machine readable" point, No - you are wrong! I do not "want" to print that. I have that in place for years and I'm using this information regularly for diagnosing user issues. > more importantly ensuring long-term compatibility. When you don't change it, it won't break. As simple as that. > What you want to print is internal information. How do you come to that idea? When I specify a filter graph and perform format conversions, I specify the formats to which I want to convert between filters. And now you want to tell me that the actual formats that have been negotiated between filters are "internal"? Like an implementation detail? No. Those are not implementation details. I set up a filtergraph with a specific intention and formats for the individual connections and that means that knowing about the actually negotiated formats cannot be considered "internal". softworkz > It is useful for debugging and testing purposes but should not be > accessed by regular tools. ___ 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] lavfi/graphdump: add plain listing output
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Monday, 23 August 2021 11:45 > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH 1/2] lavfi/graphdump: add plain > listing output > > Signed-off-by: Nicolas George > --- > libavfilter/avfilter.h | 5 ++- > libavfilter/graphdump.c | 79 > +++-- > 2 files changed, 80 insertions(+), 4 deletions(-) > > diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h > index 69ecb0186d..2a3c1e79a8 100644 > --- a/libavfilter/avfilter.h > +++ b/libavfilter/avfilter.h For reference - related discussion: https://patchwork.ffmpeg.org/project/ffmpeg/patch/mn2pr04mb59819ad807350499bd5e94f5ba...@mn2pr04mb5981.namprd04.prod.outlook.com/ http://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/284343.html ___ 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] [RFC] Add option for writing detailed filtergraph information to file or stdout
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Thursday, 26 August 2021 10:05 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing > detailed filtergraph information to file or stdout > > Soft Works (12021-08-26): > > Does that answer your question? > > Yes. It is almost exactly what I had guessed. And therefore my answer > is > what I expected it do be: that does not justify thousands, or even > hundreds, of lines of code in the core library and tools. I'm getting confused. While I've been going through your recent submissions, I noticed your proposals from April: - lavu: new AVWriter API - lavu: add a JSON writer API - et. al. There's no doubt for me that this proposal is a good thing, especially when it would be able to replace the ffprobe writers eventually. (I have once another project where I just duplicated the ffprobe writers because they weren't easily reusable). So, nice work, I really appreciate that. What makes me wonder a bit: - I had written in the commit message that the output writers would need to be merged with the ffprobe writers - But you didn’t tell that you already got the solution "in your pocket" - Instead you criticized my patch for its LOC count, even though that is just made up from the output writers code duplication... I'm confused... softworkz ___ 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/wma: handle run_level_decode error
On Tue, Aug 24, 2021 at 09:43:43AM -0400, Olivier Crête wrote:
> From: Stéphane Cerveau
>
> Consider data as invalid if ff_wma_run_level_decode
> gets out with an error.
>
> It avoids an unpleasant sound distorsion.
>
> See http://trac.ffmpeg.org/ticket/9358
> ---
> libavcodec/wmadec.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/wmadec.c b/libavcodec/wmadec.c
> index d627bbe50e..d43fe239ce 100644
> --- a/libavcodec/wmadec.c
> +++ b/libavcodec/wmadec.c
> @@ -601,15 +601,18 @@ static int wma_decode_block(WMACodecContext *s)
> if (s->channel_coded[ch]) {
> int tindex;
> WMACoef *ptr = &s->coefs1[ch][0];
> +int ret;
>
> /* special VLC tables are used for ms stereo because
> * there is potentially less energy there */
> tindex = (ch == 1 && s->ms_stereo);
> memset(ptr, 0, s->block_len * sizeof(WMACoef));
> -ff_wma_run_level_decode(s->avctx, &s->gb, &s->coef_vlc[tindex],
> -s->level_table[tindex],
> s->run_table[tindex],
> -0, ptr, 0, nb_coefs[ch],
> -s->block_len, s->frame_len_bits,
> coef_nb_bits);
> +ret = ff_wma_run_level_decode(s->avctx, &s->gb,
> &s->coef_vlc[tindex],
> + s->level_table[tindex],
> s->run_table[tindex],
> + 0, ptr, 0, nb_coefs[ch],
> + s->block_len, s->frame_len_bits,
> coef_nb_bits);
> + if (ret < 0)
> +return ret;
> }
> if (s->version == 1 && s->avctx->channels >= 2)
> align_get_bits(&s->gb);
Does this just discard the packet or replace by silence ?
if it discards it, it can cause problems with av-sync
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/signature: fix integer rounding cast precedence
On Fri, Aug 20, 2021, at 4:24 PM, Jai Luthra wrote:
> Co-authored-by: Oscar
> Signed-off-by: Jai Luthra
> ---
> libavfilter/signature_lookup.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/signature_lookup.c
> b/libavfilter/signature_lookup.c
> index 977f898049..86dd0c6675 100644
> --- a/libavfilter/signature_lookup.c
> +++ b/libavfilter/signature_lookup.c
> @@ -244,9 +244,9 @@ static MatchingInfo*
> get_matching_parameters(AVFilterContext *ctx, SignatureCont
> if (pairs[i].b[j] != pairs[k].b[l]) {
> /* linear regression */
> m = (pairs[k].b_pos[l]-pairs[i].b_pos[j]) /
> (k-i); /* good value between 0.0 - 2.0 */
> -framerate = (int) m*30 + 0.5; /* round up to 0
> - 60 */
> +framerate = (int) (m*30 + 0.5); /* round up to
> 0 - 60 */
> if (framerate>0 && framerate <= MAX_FRAMERATE)
> {
> -offset = pairs[i].b_pos[j] - ((int) m*i +
> 0.5); /* only second part has to be rounded up */
> +offset = pairs[i].b_pos[j] - ((int) (m*i +
> 0.5)); /* only second part has to be rounded up */
> if (offset > -HOUGH_MAX_OFFSET && offset <
> HOUGH_MAX_OFFSET) {
> if (pairs[i].dist < pairs[k].dist) {
> if (pairs[i].dist <
> hspace[framerate-1][offset+HOUGH_MAX_OFFSET].dist) {
> --
> 2.32.0
>
Will push in 24h, if no objections.
___
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] [RFC] Add option for writing detailed filtergraph information to file or stdout
Soft Works (12021-08-26): > - Instead you criticized my patch for its LOC count, even though that is > just made up from the output writers code duplication... You are mistaken here too. Unlike what you seem to think, I factored your saying that the writers would have to be de-duplicated in my accounting of the amount of code required. The feature you propose is of dubious usefulness, if not harmful, it would be only acceptable if it took very very little code. This is the end of the discussion from my side until you start to take maintenance and general usefulness into consideration in your discussion. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing detailed filtergraph information to file or stdout
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Thursday, 26 August 2021 13:12 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing > detailed filtergraph information to file or stdout > > Soft Works (12021-08-26): > > - Instead you criticized my patch for its LOC count, even though > that is > > just made up from the output writers code duplication... > > You are mistaken here too. Unlike what you seem to think, I factored > your saying that the writers would have to be de-duplicated in my > accounting of the amount of code required. > > The feature you propose is of dubious usefulness ?? > if not harmful, Seriously? > would be only acceptable if it took very very little code. I'm sure I could squeeze it into a few weird one-liners, LOL > This is the end of the discussion from my side until you start to > take > maintenance and general usefulness into consideration in your > discussion. I do take "general usefulness" into account. That's actually my primary motivation which originated from the fact that I find the patch that you have submitted not much useful in that form because it targets only a very specific and limited niche that you're intending to use it for. While I agree that it is useful for your specific task, that change is not of "general usefulness". Instead of setting up and raising demands upon your patch, I have submitted an alternative that I'm considering more useful for general use than yours; without going into details, simply because it provides a lot more important information that is lacking from your approach. softworkz ___ 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] Missing sudo on make install in INSTALL.md
On 26.08.2021 06:34, "zhilizhao(赵志立)" wrote: I tried try `make install` on my machine and I got: install: cannot create regular file '/usr/local/share/man/man1/ffmpeg.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffprobe.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffmpeg-all.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffprobe-all.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffmpeg-utils.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffmpeg-scaler.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffmpeg-resampler.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffmpeg-codecs.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffmpeg-bitstream-filters.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffmpeg-formats.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffmpeg-protocols.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffmpeg-devices.1': Permission denied install: cannot create regular file '/usr/local/share/man/man1/ffmpeg-filters.1': Permission denied make: *** [doc/Makefile:126: install-man] Error 1 By doing `sudo make install` it fixs the problem. User are not on root all the time. Nope. sudo is unnecessary or unavailable on some platform. You can install it to other directories without the need of root permission. Most importantly, sudo is a dangerous advice for novice. On the other hand, for anyone who already know what sudo is he/she doesn’t need such advice. I'd even go so far to say that recommending sudo is outright dangerous. Installing an incompatible version of libav* into the system can break a whole lot of things. smime.p7s Description: S/MIME Cryptographic 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 1/2] libavdevice: Fix a potential deadlock issue on the lock ctx->frame_lock in function get_audio_config
The problem here is that the lock ctx->frame_lock will become an unreleased
lock if the program returns at line 697, line 735 and line744
Cc: cy...@connect.ust.hk
Bug tracker link: https://trac.ffmpeg.org/ticket/9385\#ticket
Signed-off-by: Chengfeng Ye
---
libavdevice/avfoundation.m | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 1d108417be..0953a8b11e 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -694,6 +694,7 @@ static int get_audio_config(AVFormatContext *s)
if (!basic_desc) {
av_log(s, AV_LOG_ERROR, "audio format not available\n");
+ unlock_frames(ctx);
return 1;
}
@@ -732,6 +733,7 @@ static int get_audio_config(AVFormatContext *s)
stream->codecpar->codec_id = ctx->audio_be ? AV_CODEC_ID_PCM_S32BE :
AV_CODEC_ID_PCM_S32LE;
} else {
av_log(s, AV_LOG_ERROR, "audio format is not supported\n");
+ unlock_frames(ctx);
return 1;
}
@@ -741,6 +743,7 @@ static int get_audio_config(AVFormatContext *s)
ctx->audio_buffer = av_malloc(ctx->audio_buffer_size);
if (!ctx->audio_buffer) {
av_log(s, AV_LOG_ERROR, "error allocating audio buffer\n");
+ unlock_frames(ctx);
return 1;
}
}
--
2.17.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 2/2] libavdevice: Fix a potential deadlock issue on the lock ctx->frame_lock in function avf_read_packet
The problem here is that the lock ctx->frame_lock will become an unreleased
lock if the program returns at line 1067, line 1071, line 1098, line 1104, line
1108, line 1112, line 1131, line 1142 and line 1162.
Depends-on: series-0001 (libavdevice: Fix a potential deadlock issue on the
lock ctx->frame_lock in function get_audio_config)
Cc: cy...@connect.ust.hk
Bug tracker link: https://trac.ffmpeg.org/ticket/9386\#ticket
Signed-off-by: Chengfeng Ye
---
libavdevice/avfoundation.m | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 0953a8b11e..a461cf7d3b 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -1067,10 +1067,12 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
} else if (block_buffer != nil) {
length = (int)CMBlockBufferGetDataLength(block_buffer);
} else {
+ unlock_frames(ctx);
return AVERROR(EINVAL);
}
if (av_new_packet(pkt, length) < 0) {
+ unlock_frames(ctx);
return AVERROR(EIO);
}
@@ -1097,21 +1099,26 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
CFRelease(ctx->current_frame);
ctx->current_frame = nil;
-if (status < 0)
+if (status < 0) {
+ unlock_frames(ctx);
return status;
+ }
} else if (ctx->current_audio_frame != nil) {
CMBlockBufferRef block_buffer =
CMSampleBufferGetDataBuffer(ctx->current_audio_frame);
int block_buffer_size =
CMBlockBufferGetDataLength(block_buffer);
if (!block_buffer || !block_buffer_size) {
+ unlock_frames(ctx);
return AVERROR(EIO);
}
if (ctx->audio_non_interleaved && block_buffer_size >
ctx->audio_buffer_size) {
+ unlock_frames(ctx);
return AVERROR_BUFFER_TOO_SMALL;
}
if (av_new_packet(pkt, block_buffer_size) < 0) {
+ unlock_frames(ctx);
return AVERROR(EIO);
}
@@ -1131,6 +1138,7 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
OSStatus ret = CMBlockBufferCopyDataBytes(block_buffer, 0,
pkt->size, ctx->audio_buffer);
if (ret != kCMBlockBufferNoErr) {
+ unlock_frames(ctx);
return AVERROR(EIO);
}
@@ -1140,9 +1148,12 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
#define INTERLEAVE_OUTPUT(bps)
\
{
\
int##bps##_t **src;
\
-int##bps##_t *dest;
\
+int##bps##_t *dest;
\
src = av_malloc(ctx->audio_channels *
sizeof(int##bps##_t*)); \
-if (!src) return AVERROR(EIO);
\
+if (!src) {
\
+ unlock_frames(ctx);
\
+ return AVERROR(EIO);
\
+ }
\
for (c = 0; c < ctx->audio_channels; c++) {
\
src[c] = ((int##bps##_t*)ctx->audio_buffer) + c *
num_samples; \
}
\
@@ -1162,6 +1173,7 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
} else {
OSStatus ret = CMBlockBufferCopyDataBytes(block_buffer, 0,
pkt->size, pkt->data);
if (ret != kCMBlockBufferNoErr) {
+ unlock_frames(ctx);
return AVERROR(EIO);
}
}
--
2.17.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
Re: [FFmpeg-devel] [PATCH v2] avfilter: add libdewobble_opencl filter
On Tue, Aug 24, 2021 at 11:42 PM Mapul Bhola wrote: > I agree with Mahol here. It's good to make sure all the code in FFmpeg meets > a certain quality. > I thought there were OpenCV filters in ffmpeg already? I'm more than happy to address any issues of code quality in this filter to go into FFmpeg - please let me know if you can see something specific that I haven't addressed. I don't think using OpenCV is a quality issue. OpenCV is an established and well maintained library, and the specific algorithms used from it in Dewobble are well used and tested. Within Dewobble there are some functionalities that are implemented natively and others that use OpenCV implementations. My choices have depended on how much specialisation is needed and the relative difficulty of implementing the algorithms. For example, I wrote my own OpenCL kernels to build the final map for warping and for colour conversion. But I didn't write my own implementation of warping/interpolation, Shi-Tomasi corner detection, Lucas-Kanade optical flow, RANSAC, etc. There is no point IMO making such a huge effort to recreate what is already there in OpenCV, unless there is a good reason to think the result would be better. There are also alternative algorithms for video stabilization, many of which are also implemented in OpenCV. So it's easy to experiment with different methods without having to implement complex computer vision algorithms each time. For those parts that don't change so much, which are customised more, or which could be done better than by using OpenCV, I will probably slowly implement algorithms in Dewobble (and any help is welcome). And yes, there is an existing filter "ocv" (vf_libopencv.c) which wraps a very specific set of functionalities in OpenCV, from its image filtering category. These functionalities are unrelated to this filter or to Dewobble. There is also a filter "deshake_opencl" which doesn't depend on OpenCV but contains code copied from some of it's OpenCL kernels. > And if you are the writer of this plugin as well, you should consider > relicensing it to LGPL for its usage in ffmpeg. I considered this but I've decided to license Dewobble as GPL. I realise this prevents it from being used in closed source or permissively licensed libraries that links to it, but it can still be usable for end users of FFmpeg and within other GPL software. FFmpeg already has build infrastructure to support this, as well as multiple existing filters which are also licensed under GPL. ___ 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] libavdevice: Fix a potential deadlock issue on the lock ctx->frame_lock in function avf_read_packet
Chengfeng Ye (12021-08-26):
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] libavdevice: Fix a potential deadlock
> issue on the lock ctx->frame_lock in function avf_read_packet
"libavdevice/avfoundation"
> The problem here is that the lock ctx->frame_lock will become an unreleased
> lock if the program returns at line 1067, line 1071, line 1098, line 1104,
> line 1108, line 1112, line 1131, line 1142 and line 1162.
Please wrap the lines below 72 characters.
>
> Depends-on: series-0001 (libavdevice: Fix a potential deadlock issue on the
> lock ctx->frame_lock in function get_audio_config)
> Cc: cy...@connect.ust.hk
> Bug tracker link: https://trac.ffmpeg.org/ticket/9386\#ticket
>
> Signed-off-by: Chengfeng Ye
> ---
> libavdevice/avfoundation.m | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
> index 0953a8b11e..a461cf7d3b 100644
> --- a/libavdevice/avfoundation.m
> +++ b/libavdevice/avfoundation.m
> @@ -1067,10 +1067,12 @@ static int avf_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> } else if (block_buffer != nil) {
> length = (int)CMBlockBufferGetDataLength(block_buffer);
> } else {
> + unlock_frames(ctx);
Tabs are not allowed.
> return AVERROR(EINVAL);
> }
>
> if (av_new_packet(pkt, length) < 0) {
> + unlock_frames(ctx);
> return AVERROR(EIO);
> }
>
> @@ -1097,21 +1099,26 @@ static int avf_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> CFRelease(ctx->current_frame);
> ctx->current_frame = nil;
>
> -if (status < 0)
> +if (status < 0) {
> + unlock_frames(ctx);
> return status;
> + }
> } else if (ctx->current_audio_frame != nil) {
> CMBlockBufferRef block_buffer =
> CMSampleBufferGetDataBuffer(ctx->current_audio_frame);
> int block_buffer_size =
> CMBlockBufferGetDataLength(block_buffer);
>
> if (!block_buffer || !block_buffer_size) {
> + unlock_frames(ctx);
> return AVERROR(EIO);
> }
>
> if (ctx->audio_non_interleaved && block_buffer_size >
> ctx->audio_buffer_size) {
> + unlock_frames(ctx);
> return AVERROR_BUFFER_TOO_SMALL;
> }
>
> if (av_new_packet(pkt, block_buffer_size) < 0) {
> + unlock_frames(ctx);
> return AVERROR(EIO);
> }
>
> @@ -1131,6 +1138,7 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
> *pkt)
>
> OSStatus ret = CMBlockBufferCopyDataBytes(block_buffer, 0,
> pkt->size, ctx->audio_buffer);
> if (ret != kCMBlockBufferNoErr) {
> + unlock_frames(ctx);
> return AVERROR(EIO);
> }
>
> @@ -1140,9 +1148,12 @@ static int avf_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> #define INTERLEAVE_OUTPUT(bps)
> \
> {
> \
> int##bps##_t **src;
> \
> -int##bps##_t *dest;
> \
> +int##bps##_t *dest;
>\
> src = av_malloc(ctx->audio_channels *
> sizeof(int##bps##_t*)); \
> -if (!src) return AVERROR(EIO);
> \
> +if (!src) {
>\
> + unlock_frames(ctx);
>\
> + return AVERROR(EIO);
>\
> + }
>
> \
> for (c = 0; c < ctx->audio_channels; c++) {
> \
> src[c] = ((int##bps##_t*)ctx->audio_buffer) + c *
> num_samples; \
> }
> \
> @@ -1162,6 +1173,7 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
> *pkt)
> } else {
> OSStatus ret = CMBlockBufferCopyDataBytes
[FFmpeg-devel] [PATCH v3] avfilter: add libdewobble filter
All of the existing filters for video stabilization use an affine model
(or a limited version of it) to represent the movement of the camera. When
used with cameras with a very wide field of view and/or where the camera
shaking is severe, the corrections result in significant geometric
distortion ("wobbling").
Dewobble (https://git.sr.ht/~hedgepigdaniel/dewobble) is a library built
to solve this problem. It requires knowledge of the projection used by
the input camera, and it performs stabilization using a homography
model, which is limited to include only changes in camera orientation.
Additionally, it can perform projection change by specifying a different
projection for the output camera. This is more efficient and results in
less loss of information than using separate filters to perform
stabilization and projection change.
The libdewobble filter is a wrapper for Dewobble. Dewobble supports
input and output in OpenCL buffers containing NV12 frames. Hence, the
filter has the same limitations. Currently
all of the options of Dewobble are supported. Of the two types of filter
available in Dewobble (FilterSync and FilterThreaded), FilterThreaded is
used. The API is synchronous, but the transformations are done in a
separate thread. The purpose of this is to isolate the global per thread
OpenCL context used by OpenCV, which Dewobble uses internally. This
prevents dewobble_opencl from interfering with any other usage of OpenCV
from within FFmpeg.
Signed-off-by: Daniel Playfair Cal
---
Changelog v3:
- rename filter to "libdewobble"
- capitalize first word of filter description
---
Changelog|1 +
LICENSE.md |2 +-
configure|4 +
doc/filters.texi | 149
libavfilter/Makefile |1 +
libavfilter/allfilters.c |1 +
libavfilter/vf_libdewobble.c | 1273 ++
7 files changed, 1430 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vf_libdewobble.c
diff --git a/Changelog b/Changelog
index 20d71bed88..b4e0a4f4f9 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
- audio and video segment filters
- Apple Graphics (SMC) encoder
- hsvkey and hsvhold video filters
+- libdewobble video filter
version 4.4:
diff --git a/LICENSE.md b/LICENSE.md
index 613070e1b6..dfdf010d8e 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -112,7 +112,7 @@ The VMAF, mbedTLS, RK MPI, OpenCORE and VisualOn libraries
are under the Apache
version 3 of those licenses. So to combine these libraries with FFmpeg, the
license version needs to be upgraded by passing `--enable-version3` to
configure.
-The smbclient library is under the GPL v3, to combine it with FFmpeg,
+The dewobble and smbclient libraries are under the GPL v3, to combine them
with FFmpeg,
the options `--enable-gpl` and `--enable-version3` have to be passed to
configure to upgrade FFmpeg to the GPL v3.
diff --git a/configure b/configure
index 9249254b70..00f3e8deea 100755
--- a/configure
+++ b/configure
@@ -230,6 +230,7 @@ External library support:
--enable-libdavs2enable AVS2 decoding via libdavs2 [no]
--enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
and libraw1394 [no]
+ --enable-libdewobble enable video stabilization via libdewobble [no]
--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]
@@ -1781,6 +1782,7 @@ EXTERNAL_LIBRARY_VERSION3_LIST="
"
EXTERNAL_LIBRARY_GPLV3_LIST="
+libdewobble
libsmbclient
"
@@ -3606,6 +3608,7 @@ interlace_filter_deps="gpl"
kerndeint_filter_deps="gpl"
ladspa_filter_deps="ladspa libdl"
lensfun_filter_deps="liblensfun version3"
+libdewobble_filter_deps="libdewobble opencl"
lv2_filter_deps="lv2"
mcdeint_filter_deps="avcodec gpl"
metadata_filter_deps="avformat"
@@ -6406,6 +6409,7 @@ enabled libcodec2 && require libcodec2
codec2/codec2.h codec2_create -lc
enabled libdav1d && require_pkg_config libdav1d "dav1d >= 0.5.0"
"dav1d/dav1d.h" dav1d_version
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 libdewobble && require_pkg_config libdewobble dewobble
dewobble/filter.h dewobble_filter_create_threaded
enabled libdrm&& require_pkg_config libdrm libdrm xf86drm.h
drmGetVersion
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 &&
diff --git a/doc/filters.texi b/doc/filters.texi
index 47ceeb18c6..7e5038018e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14213,6
[FFmpeg-devel] [PATCH v4] avfilter: add libdewobble filter
All of the existing filters for video stabilization use an affine model
(or a limited version of it) to represent the movement of the camera. When
used with cameras with a very wide field of view and/or where the camera
shaking is severe, the corrections result in significant geometric
distortion ("wobbling").
Dewobble (https://git.sr.ht/~hedgepigdaniel/dewobble) is a library built
to solve this problem. It requires knowledge of the projection used by
the input camera, and it performs stabilization using a homography
model, which is limited to include only changes in camera orientation.
Additionally, it can perform projection change by specifying a different
projection for the output camera. This is more efficient and results in
less loss of information than using separate filters to perform
stabilization and projection change.
The libdewobble filter is a wrapper for Dewobble. Dewobble supports
input and output in OpenCL buffers containing NV12 frames. Hence, the
filter has the same limitations. Currently
all of the options of Dewobble are supported. Of the two types of filter
available in Dewobble (FilterSync and FilterThreaded), FilterThreaded is
used. The API is synchronous, but the transformations are done in a
separate thread. The purpose of this is to isolate the global per thread
OpenCL context used by OpenCV, which Dewobble uses internally. This
prevents dewobble_opencl from interfering with any other usage of OpenCV
from within FFmpeg.
Signed-off-by: Daniel Playfair Cal
---
Changelog v4:
- correct rename in documentation
- update examples to include hwupload/hwdownload, now that name does
not contain _opencl postfix.
---
Changelog|1 +
LICENSE.md |2 +-
configure|4 +
doc/filters.texi | 149
libavfilter/Makefile |1 +
libavfilter/allfilters.c |1 +
libavfilter/vf_libdewobble.c | 1273 ++
7 files changed, 1430 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vf_libdewobble.c
diff --git a/Changelog b/Changelog
index 20d71bed88..b4e0a4f4f9 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
- audio and video segment filters
- Apple Graphics (SMC) encoder
- hsvkey and hsvhold video filters
+- libdewobble video filter
version 4.4:
diff --git a/LICENSE.md b/LICENSE.md
index 613070e1b6..dfdf010d8e 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -112,7 +112,7 @@ The VMAF, mbedTLS, RK MPI, OpenCORE and VisualOn libraries
are under the Apache
version 3 of those licenses. So to combine these libraries with FFmpeg, the
license version needs to be upgraded by passing `--enable-version3` to
configure.
-The smbclient library is under the GPL v3, to combine it with FFmpeg,
+The dewobble and smbclient libraries are under the GPL v3, to combine them
with FFmpeg,
the options `--enable-gpl` and `--enable-version3` have to be passed to
configure to upgrade FFmpeg to the GPL v3.
diff --git a/configure b/configure
index 9249254b70..00f3e8deea 100755
--- a/configure
+++ b/configure
@@ -230,6 +230,7 @@ External library support:
--enable-libdavs2enable AVS2 decoding via libdavs2 [no]
--enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
and libraw1394 [no]
+ --enable-libdewobble enable video stabilization via libdewobble [no]
--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]
@@ -1781,6 +1782,7 @@ EXTERNAL_LIBRARY_VERSION3_LIST="
"
EXTERNAL_LIBRARY_GPLV3_LIST="
+libdewobble
libsmbclient
"
@@ -3606,6 +3608,7 @@ interlace_filter_deps="gpl"
kerndeint_filter_deps="gpl"
ladspa_filter_deps="ladspa libdl"
lensfun_filter_deps="liblensfun version3"
+libdewobble_filter_deps="libdewobble opencl"
lv2_filter_deps="lv2"
mcdeint_filter_deps="avcodec gpl"
metadata_filter_deps="avformat"
@@ -6406,6 +6409,7 @@ enabled libcodec2 && require libcodec2
codec2/codec2.h codec2_create -lc
enabled libdav1d && require_pkg_config libdav1d "dav1d >= 0.5.0"
"dav1d/dav1d.h" dav1d_version
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 libdewobble && require_pkg_config libdewobble dewobble
dewobble/filter.h dewobble_filter_create_threaded
enabled libdrm&& require_pkg_config libdrm libdrm xf86drm.h
drmGetVersion
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 &&
diff --git a/doc/filters.texi b/doc/filters.texi
index 47ceeb18c6..1a41f0dd0a 100644
-
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/wma: handle run_level_decode error
On Thu, 2021-08-26 at 12:33 +0200, Michael Niedermayer wrote:
> On Tue, Aug 24, 2021 at 09:43:43AM -0400, Olivier Crête wrote:
> > From: Stéphane Cerveau
> >
> > Consider data as invalid if ff_wma_run_level_decode
> > gets out with an error.
> >
> > It avoids an unpleasant sound distorsion.
> >
> > See http://trac.ffmpeg.org/ticket/9358
> > ---
> > libavcodec/wmadec.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/wmadec.c b/libavcodec/wmadec.c
> > index d627bbe50e..d43fe239ce 100644
> > --- a/libavcodec/wmadec.c
> > +++ b/libavcodec/wmadec.c
> > @@ -601,15 +601,18 @@ static int wma_decode_block(WMACodecContext *s)
> > if (s->channel_coded[ch]) {
> > int tindex;
> > WMACoef *ptr = &s->coefs1[ch][0];
> > +int ret;
> >
> > /* special VLC tables are used for ms stereo because
> > * there is potentially less energy there */
> > tindex = (ch == 1 && s->ms_stereo);
> > memset(ptr, 0, s->block_len * sizeof(WMACoef));
> > -ff_wma_run_level_decode(s->avctx, &s->gb, &s->coef_vlc[tindex],
> > -s->level_table[tindex],
> > s->run_table[tindex],
> > -0, ptr, 0, nb_coefs[ch],
> > -s->block_len, s->frame_len_bits,
> > coef_nb_bits);
> > +ret = ff_wma_run_level_decode(s->avctx, &s->gb,
> > &s->coef_vlc[tindex],
> > + s->level_table[tindex],
> > s->run_table[tindex],
> > + 0, ptr, 0, nb_coefs[ch],
> > + s->block_len, s->frame_len_bits,
> > coef_nb_bits);
> > + if (ret < 0)
> > +return ret;
> > }
> > if (s->version == 1 && s->avctx->channels >= 2)
> > align_get_bits(&s->gb);
>
> Does this just discard the packet or replace by silence ?
> if it discards it, it can cause problems with av-sync
It just discards it, but it seems that the Microsoft implementation has
the same behaviour, so I think it's better to be bug compatible with
them.
--
Olivier Crête
olivier.cr...@collabora.com
___
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] libavdevice/avfoundation.m: fix protential unreleased lock issue
The problem here is that the lock ctx->frame_lock will
become an unreleased lock if the program returns at
line 697, line 735 and line744.
Cc: cy...@connect.ust.hk
Bug tracker link: https://trac.ffmpeg.org/ticket/9385\#ticket
Signed-off-by: Chengfeng Ye
---
libavdevice/avfoundation.m | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 1d108417be..8ce3d064c5 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -693,6 +693,7 @@ static int get_audio_config(AVFormatContext *s)
const AudioStreamBasicDescription *basic_desc =
CMAudioFormatDescriptionGetStreamBasicDescription(format_desc);
if (!basic_desc) {
+unlock_frames(ctx);
av_log(s, AV_LOG_ERROR, "audio format not available\n");
return 1;
}
@@ -731,6 +732,7 @@ static int get_audio_config(AVFormatContext *s)
ctx->audio_packed) {
stream->codecpar->codec_id = ctx->audio_be ? AV_CODEC_ID_PCM_S32BE :
AV_CODEC_ID_PCM_S32LE;
} else {
+unlock_frames(ctx);
av_log(s, AV_LOG_ERROR, "audio format is not supported\n");
return 1;
}
@@ -740,6 +742,7 @@ static int get_audio_config(AVFormatContext *s)
ctx->audio_buffer_size=
CMBlockBufferGetDataLength(block_buffer);
ctx->audio_buffer = av_malloc(ctx->audio_buffer_size);
if (!ctx->audio_buffer) {
+unlock_frames(ctx);
av_log(s, AV_LOG_ERROR, "error allocating audio buffer\n");
return 1;
}
--
2.17.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 2/2] libavdevice/avfoundation.m: fix potential unreleased lock issue
The problem here is that the lock ctx->frame_lock will become
an unreleased lock if the program returns at patched lines.
Depends-on: series-0001
Cc: cy...@connect.ust.hk
Bug tracker link: https://trac.ffmpeg.org/ticket/9386\#ticket
Signed-off-by: Chengfeng Ye
---
libavdevice/avfoundation.m | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 8ce3d064c5..0cd6e646d5 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -1067,10 +1067,12 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
} else if (block_buffer != nil) {
length = (int)CMBlockBufferGetDataLength(block_buffer);
} else {
+unlock_frames(ctx);
return AVERROR(EINVAL);
}
if (av_new_packet(pkt, length) < 0) {
+unlock_frames(ctx);
return AVERROR(EIO);
}
@@ -1097,21 +1099,26 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
CFRelease(ctx->current_frame);
ctx->current_frame = nil;
-if (status < 0)
+if (status < 0) {
+unlock_frames(ctx);
return status;
+}
} else if (ctx->current_audio_frame != nil) {
CMBlockBufferRef block_buffer =
CMSampleBufferGetDataBuffer(ctx->current_audio_frame);
int block_buffer_size =
CMBlockBufferGetDataLength(block_buffer);
if (!block_buffer || !block_buffer_size) {
+unlock_frames(ctx);
return AVERROR(EIO);
}
if (ctx->audio_non_interleaved && block_buffer_size >
ctx->audio_buffer_size) {
+unlock_frames(ctx);
return AVERROR_BUFFER_TOO_SMALL;
}
if (av_new_packet(pkt, block_buffer_size) < 0) {
+unlock_frames(ctx);
return AVERROR(EIO);
}
@@ -1131,6 +1138,7 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
OSStatus ret = CMBlockBufferCopyDataBytes(block_buffer, 0,
pkt->size, ctx->audio_buffer);
if (ret != kCMBlockBufferNoErr) {
+unlock_frames(ctx);
return AVERROR(EIO);
}
@@ -1142,7 +1150,11 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
int##bps##_t **src;
\
int##bps##_t *dest;
\
src = av_malloc(ctx->audio_channels *
sizeof(int##bps##_t*)); \
-if (!src) return AVERROR(EIO);
\
+if (!src) {
\
+unlock_frames(ctx);
\
+return AVERROR(EIO);
\
+}
\
+
\
for (c = 0; c < ctx->audio_channels; c++) {
\
src[c] = ((int##bps##_t*)ctx->audio_buffer) + c *
num_samples; \
}
\
@@ -1162,6 +1174,7 @@ static int avf_read_packet(AVFormatContext *s, AVPacket
*pkt)
} else {
OSStatus ret = CMBlockBufferCopyDataBytes(block_buffer, 0,
pkt->size, pkt->data);
if (ret != kCMBlockBufferNoErr) {
+unlock_frames(ctx);
return AVERROR(EIO);
}
}
--
2.17.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] webp: fix transforms after a palette with pixel packing.
We've just added a file to libwebp-test-data that covers this case: https://chromium.googlesource.com/webm/libwebp-test-data/+/refs/heads/main/dual_transform.webp FFmpeg currently fails to decode it, but it works with this patch. My understanding is that an ffmpeg developer needs to upload the file to fate, and then I can add a fate test to the patch? On Fri, Aug 20, 2021 at 7:07 PM James Zern wrote: > On Thu, Aug 19, 2021 at 12:56 AM Maryla > wrote: > > > > When a color indexing transform with 16 or fewer colors is used, > > WebP uses "pixel packing", i.e. storing several pixels in one byte, > > which virtually reduces the width of the image (see WebPContext's > > reduced_width field). This reduced_width should always be used when > > reading and applying subsequent transforms. > > > > Fixes: 9368 > > Is there anything in > https://chromium.googlesource.com/webm/libwebp-test-data that covers > this or can you add the file from the ticket to fate? > ___ > 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".
[FFmpeg-devel] [PATCH v2 0/1] avfilter: Add Grayworld color correction filter
Implementation of a grayworld color correction filter Paul Buxton (1): Implement gray world color correction uses log LAB colorspace doc/filters.texi | 12 ++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/version.h | 2 +- libavfilter/vf_grayworld.c | 368 + 5 files changed, 383 insertions(+), 1 deletion(-) create mode 100644 libavfilter/vf_grayworld.c -- 2.17.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 1/1] Implement gray world color correction uses log LAB colorspace
Signed-off-by: Paul Buxton
---
doc/filters.texi | 12 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vf_grayworld.c | 368 +
5 files changed, 383 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vf_grayworld.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 47ceeb18c6..0f334c3d2a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -13046,6 +13046,18 @@ Set upper limit for video rate of output stream,
Default value is @var{25}.
This guarantee that output video frame rate will not be higher than this value.
@end table
+@section grayworld
+A color constancy filter that applies color correction based on the grayworld
assumption
+
+See:
@url{https://www.researchgate.net/publication/275213614_A_New_Color_Correction_Method_for_Underwater_Imaging}
+
+The algorithm uses linear light, so input
+data should be linearized beforehand (and possibly correctly tagged).
+
+@example
+ffmpeg -i INPUT -vf
zscale=transfer=linear,grayworld,zscale=transfer=bt709,format=yuv420p OUTPUT
+@end example
+
@section greyedge
A color constancy variation filter which estimates scene illumination via grey
edge algorithm
and corrects the scene colors accordingly.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3166e70b58..1d86110d6b 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -287,6 +287,7 @@ OBJS-$(CONFIG_GBLUR_FILTER) += vf_gblur.o
OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o
OBJS-$(CONFIG_GRADFUN_FILTER)+= vf_gradfun.o
OBJS-$(CONFIG_GRAPHMONITOR_FILTER) += f_graphmonitor.o
+OBJS-$(CONFIG_GRAYWORLD_FILTER) += vf_grayworld.o
OBJS-$(CONFIG_GREYEDGE_FILTER) += vf_colorconstancy.o
OBJS-$(CONFIG_GUIDED_FILTER) += vf_guided.o
OBJS-$(CONFIG_HALDCLUT_FILTER) += vf_lut3d.o framesync.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index c49c831203..73e5fe1a41 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -272,6 +272,7 @@ extern const AVFilter ff_vf_gblur;
extern const AVFilter ff_vf_geq;
extern const AVFilter ff_vf_gradfun;
extern const AVFilter ff_vf_graphmonitor;
+extern const AVFilter ff_vf_grayworld;
extern const AVFilter ff_vf_greyedge;
extern const AVFilter ff_vf_guided;
extern const AVFilter ff_vf_haldclut;
diff --git a/libavfilter/version.h b/libavfilter/version.h
index e9a76c5ac3..e3a86d9b01 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -30,7 +30,7 @@
#include "libavutil/version.h"
#define LIBAVFILTER_VERSION_MAJOR 8
-#define LIBAVFILTER_VERSION_MINOR 4
+#define LIBAVFILTER_VERSION_MINOR 5
#define LIBAVFILTER_VERSION_MICRO 100
diff --git a/libavfilter/vf_grayworld.c b/libavfilter/vf_grayworld.c
new file mode 100644
index 00..c33e5c8c21
--- /dev/null
+++ b/libavfilter/vf_grayworld.c
@@ -0,0 +1,368 @@
+/*
+ * Copyright (c) 2021 Paul Buxton
+ *
+ * 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
+ * Color correction filter based on
+ *
https://www.researchgate.net/publication/275213614_A_New_Color_Correction_Method_for_Underwater_Imaging
+ *
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/intreadwrite.h"
+
+#include "avfilter.h"
+#include "drawutils.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct ThreadData {
+AVFrame *in, *out;
+float l_avg;
+float a_avg;
+float b_avg;
+const AVPixFmtDescriptor *desc;
+const AVPixFmtDescriptor *odesc;
+} ThreadData;
+
+typedef struct GrayWorldContext {
+const AVClass* class;
+float *tmpplab;
+int *line_count_pels;
+float *line_sum;
+
+} GrayWorldContext;
+
+#define OFFSET(x) offsetof(GrayWorldContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM | AV_OPT_FLAG_VIDEO_PARAM |
AV_OPT_FLAG_RUNTIME_PARAM
+static const AVOption grayworld_options[] = {};
+
+AVFILTER_DEFINE_CLASS(grayworld);
+
+void compute_correction(GrayWorldContext *s, ThreadData *td);
+void apply_matrix(float matrix[3][3], float input[3], float output[3]);
+void rg
Re: [FFmpeg-devel] [PATCH 1/1] Implement gray world color correction uses log LAB colorspace
On Thu, Aug 26, 2021 at 7:53 PM Paul Buxton
wrote:
> Signed-off-by: Paul Buxton
> ---
> doc/filters.texi | 12 ++
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/version.h | 2 +-
> libavfilter/vf_grayworld.c | 368 +
> 5 files changed, 383 insertions(+), 1 deletion(-)
> create mode 100644 libavfilter/vf_grayworld.c
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 47ceeb18c6..0f334c3d2a 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -13046,6 +13046,18 @@ Set upper limit for video rate of output stream,
> Default value is @var{25}.
> This guarantee that output video frame rate will not be higher than this
> value.
> @end table
>
> +@section grayworld
> +A color constancy filter that applies color correction based on the
> grayworld assumption
> +
> +See: @url{
> https://www.researchgate.net/publication/275213614_A_New_Color_Correction_Method_for_Underwater_Imaging
> }
> +
> +The algorithm uses linear light, so input
> +data should be linearized beforehand (and possibly correctly tagged).
> +
> +@example
> +ffmpeg -i INPUT -vf
> zscale=transfer=linear,grayworld,zscale=transfer=bt709,format=yuv420p OUTPUT
> +@end example
> +
> @section greyedge
> A color constancy variation filter which estimates scene illumination via
> grey edge algorithm
> and corrects the scene colors accordingly.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 3166e70b58..1d86110d6b 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -287,6 +287,7 @@ OBJS-$(CONFIG_GBLUR_FILTER) +=
> vf_gblur.o
> OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o
> OBJS-$(CONFIG_GRADFUN_FILTER)+= vf_gradfun.o
> OBJS-$(CONFIG_GRAPHMONITOR_FILTER) += f_graphmonitor.o
> +OBJS-$(CONFIG_GRAYWORLD_FILTER) += vf_grayworld.o
> OBJS-$(CONFIG_GREYEDGE_FILTER) += vf_colorconstancy.o
> OBJS-$(CONFIG_GUIDED_FILTER) += vf_guided.o
> OBJS-$(CONFIG_HALDCLUT_FILTER) += vf_lut3d.o framesync.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index c49c831203..73e5fe1a41 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -272,6 +272,7 @@ extern const AVFilter ff_vf_gblur;
> extern const AVFilter ff_vf_geq;
> extern const AVFilter ff_vf_gradfun;
> extern const AVFilter ff_vf_graphmonitor;
> +extern const AVFilter ff_vf_grayworld;
> extern const AVFilter ff_vf_greyedge;
> extern const AVFilter ff_vf_guided;
> extern const AVFilter ff_vf_haldclut;
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index e9a76c5ac3..e3a86d9b01 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -30,7 +30,7 @@
> #include "libavutil/version.h"
>
> #define LIBAVFILTER_VERSION_MAJOR 8
> -#define LIBAVFILTER_VERSION_MINOR 4
> +#define LIBAVFILTER_VERSION_MINOR 5
> #define LIBAVFILTER_VERSION_MICRO 100
>
>
> diff --git a/libavfilter/vf_grayworld.c b/libavfilter/vf_grayworld.c
> new file mode 100644
> index 00..c33e5c8c21
> --- /dev/null
> +++ b/libavfilter/vf_grayworld.c
> @@ -0,0 +1,368 @@
> +/*
> + * Copyright (c) 2021 Paul Buxton
> + *
> + * 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
> + * Color correction filter based on
> + *
> https://www.researchgate.net/publication/275213614_A_New_Color_Correction_Method_for_Underwater_Imaging
> + *
> + */
> +
> +#include "libavutil/imgutils.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavutil/intreadwrite.h"
> +
> +#include "avfilter.h"
> +#include "drawutils.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "video.h"
> +
> +typedef struct ThreadData {
> +AVFrame *in, *out;
> +float l_avg;
> +float a_avg;
> +float b_avg;
> +const AVPixFmtDescriptor *desc;
> +const AVPixFmtDescriptor *odesc;
> +} ThreadData;
> +
> +typedef struct GrayWorldContext {
> +const AVClass* class;
> +float *tmpplab;
> +int *line_count_pels;
> +float *line_sum;
> +
> +} GrayWorldContext;
> +
> +#define OFFSET(x) offsetof(GrayWorldContext, x)
> +#defi
Re: [FFmpeg-devel] [PATCH v2] DXVA2: Add ARGB format
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Saturday, 7 August 2021 07:02
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2] DXVA2: Add ARGB format
>
> Required for uploading frames with alpha for qsv_overlay
> (v2: remove tab indent)
>
> Signed-off-by: softworkz
> ---
> libavutil/hwcontext_dxva2.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavutil/hwcontext_dxva2.c
> b/libavutil/hwcontext_dxva2.c
> index 63b037da4a..9987cdc578 100644
> --- a/libavutil/hwcontext_dxva2.c
> +++ b/libavutil/hwcontext_dxva2.c
> @@ -83,6 +83,7 @@ static const struct {
> { MKTAG('N', 'V', '1', '2'), AV_PIX_FMT_NV12 },
> { MKTAG('P', '0', '1', '0'), AV_PIX_FMT_P010 },
> { D3DFMT_P8, AV_PIX_FMT_PAL8 },
> +{ D3DFMT_A8R8G8B8, AV_PIX_FMT_BGRA },
> };
>
> DEFINE_GUID(video_decoder_service, 0xfc51a551, 0xd5e7, 0x11d9,
> 0xaf, 0x55, 0x00, 0x05, 0x4e, 0x43, 0xff, 0x02);
> --
Could somebody push this please?
Thanks,
softworkz
___
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/mov: Check dts for overflow in mov_read_trun()
Fixes: signed integer overflow: 9223372034248226491 + 3275247799 cannot be represented in type 'long' Fixes: clusterfuzz-testcase-minimized-audio_decoder_fuzzer-4538729166077952 Reported-by: Matt Wolenetz Signed-off-by: Michael Niedermayer --- libavformat/mov.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/mov.c b/libavformat/mov.c index da4c5d60f8..c5583e07c7 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -4953,6 +4953,8 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, MOVAtom atom) "size %u, distance %d, keyframe %d\n", st->index, index_entry_pos, offset, dts, sample_size, distance, keyframe); distance++; +if (av_sat_add64(dts, sample_duration) != dts + (uint64_t)sample_duration) +return AVERROR_INVALIDDATA; dts += sample_duration; offset += sample_size; sc->data_size += sample_size; -- 2.17.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] avfilter: add atilt filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 29
libavfilter/Makefile | 1 +
libavfilter/af_atilt.c | 287 +++
libavfilter/allfilters.c | 1 +
4 files changed, 318 insertions(+)
create mode 100644 libavfilter/af_atilt.c
diff --git a/doc/filters.texi b/doc/filters.texi
index fb3a683027..f160d70419 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2989,6 +2989,35 @@ Change filter tempo scale factor.
Syntax for the command is : "@var{tempo}"
@end table
+@section atilt
+Apply spectral tilt filter to audio stream.
+
+This filter apply any spectral roll-off slope over any specified frequency
band.
+
+The filter accepts the following options:
+
+@table @option
+@item freq
+Set central frequency of tilt in Hz. Default is 1 Hz.
+
+@item slope
+Set slope direction of tilt. Default is 0. Allowed range is from -1 to 1.
+
+@item width
+Set width of tilt. Default is 1000. Allowed range is from 100 to 1.
+
+@item order
+Set order of tilt filter.
+
+@item level
+Set input volume level. Allowed range is from 0 to 4.
+Defalt is 1.
+@end table
+
+@subsection Commands
+
+This filter supports the all above options as @ref{commands}.
+
@section atrim
Trim the input so that the output contains one continuous subpart of the input.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 399a4a5083..2b58325fee 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -99,6 +99,7 @@ OBJS-$(CONFIG_ASUPERCUT_FILTER) += af_asupercut.o
OBJS-$(CONFIG_ASUPERPASS_FILTER) += af_asupercut.o
OBJS-$(CONFIG_ASUPERSTOP_FILTER) += af_asupercut.o
OBJS-$(CONFIG_ATEMPO_FILTER) += af_atempo.o
+OBJS-$(CONFIG_ATILT_FILTER) += af_atilt.o
OBJS-$(CONFIG_ATRIM_FILTER) += trim.o
OBJS-$(CONFIG_AXCORRELATE_FILTER)+= af_axcorrelate.o
OBJS-$(CONFIG_AZMQ_FILTER) += f_zmq.o
diff --git a/libavfilter/af_atilt.c b/libavfilter/af_atilt.c
new file mode 100644
index 00..833e0c571b
--- /dev/null
+++ b/libavfilter/af_atilt.c
@@ -0,0 +1,287 @@
+/*
+ * 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 "libavutil/channel_layout.h"
+#include "libavutil/ffmath.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "formats.h"
+
+#define MAX_ORDER 30
+
+typedef struct Coeffs {
+double g;
+double a1;
+double b0, b1;
+} Coeffs;
+
+typedef struct ATiltContext {
+const AVClass *class;
+
+double freq;
+double level;
+double slope;
+double width;
+int order;
+
+Coeffs coeffs[MAX_ORDER];
+
+AVFrame *w;
+
+int (*filter_channels)(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs);
+} ATiltContext;
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVSampleFormat sample_fmts[] = {
+AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_DBLP,
+AV_SAMPLE_FMT_NONE
+};
+int ret;
+
+ret = ff_set_common_formats_from_list(ctx, sample_fmts);
+if (ret < 0)
+return ret;
+
+ret = ff_set_common_all_channel_counts(ctx);
+if (ret < 0)
+return ret;
+
+return ff_set_common_all_samplerates(ctx);
+}
+
+static double prewarp(double w, double T, double wp)
+{
+return wp * tan(w * T * 0.5) / tan(wp * T * 0.5);
+}
+
+static double mz(int i, double w0, double r, double alpha)
+{
+return w0 * pow(r, -alpha + i);
+}
+
+static double mp(int i, double w0, double r)
+{
+return w0 * pow(r, i);
+}
+
+static double mzh(int i, double T, double w0, double r, double alpha)
+{
+return prewarp(mz(i, w0, r, alpha), T, w0);
+}
+
+static double mph(int i, double T, double w0, double r)
+{
+return prewarp(mp(i, w0, r), T, w0);
+}
+
+static void set_tf1s(Coeffs *coeffs, double b1, double b0, double a0,
+ double w1, double sr, double alpha)
+{
+double c = 1.0 / tan(w1 * 0.5 / sr);
+double d = a0 + c;
+
+coeffs->b1 = (b0 - b1 * c) / d;
+coeffs->b0 = (b0 + b1 * c) / d;
+coeffs->a1 = (a0 - c) / d;
+coeffs->g = a0 / b0;
+}
+
+static void set_filter(AVFilterContext *ctx,
+ int order, double sr, double f0,
+ double bw, double alp
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/libx264: add support for setting chroma sample location
On Tue, Aug 24, 2021 at 12:47 AM Jan Ekström wrote:
>
> ---
> libavcodec/libx264.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index d48e142e41..379c167e6f 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -870,6 +870,8 @@ static av_cold int X264_init(AVCodecContext *avctx)
> x4->params.vui.i_colorprim = avctx->color_primaries;
> if (avctx->color_trc != AVCOL_TRC_UNSPECIFIED)
> x4->params.vui.i_transfer = avctx->color_trc;
> +if (avctx->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED)
> +x4->params.vui.i_chroma_loc = avctx->chroma_sample_location - 1;
>
> if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER)
> x4->params.b_repeat_headers = 0;
> --
> 2.31.1
>
I have re-tested these changes (for both x264 and x265), and BT.2100
content that was marked with topleft chroma location now gets that
information passed onto the output (whereas previously the content
would get interpreted as with the implicit "left" value). Thus, unless
there are objections, I will pull this set in soon.
The only difference in default would be with unlabeled H.264/HEVC with
streams that get that default value ("left") interpreted. Previously,
as there was no support for writing the data, those streams would stay
without any metadata on the output side, while now, as libavcodec
doesn't differentiate between implicit and explicit values, the value
gets written into the output, making an implicit value explicit. As
far as whether this is a problem, I would consider it a "no", as the
decoding result should be the same (due to the implicit default).
Best regards,
Jan
___
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/vf_scale: reset color matrix in case of identity & non-RGB
On Sun, Aug 22, 2021 at 11:55 PM Jan Ekström wrote: > > Fixes passing through mismatching metadata from the input side > when RGB input (from f.ex. H.264 or HEVC) gets converted to YCbCr. > > Fixes #9132 > --- > libavfilter/vf_scale.c | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c > index ce39217515..7ca833bbb1 100644 > --- a/libavfilter/vf_scale.c > +++ b/libavfilter/vf_scale.c > @@ -738,6 +738,15 @@ scale: > out->width = outlink->w; > out->height = outlink->h; > > +// Sanity check: If we've got the RGB/XYZ (identity) matrix configured, > and > +// the output is no longer RGB, unset the matrix. > +// In theory this should be in swscale itself as the > AVFrame > +// based API gets in, so that not every swscale API user > has > +// to go through duplicating such sanity checks. > +if (out->colorspace == AVCOL_SPC_RGB && > +!(av_pix_fmt_desc_get(out->format)->flags & AV_PIX_FMT_FLAG_RGB)) > +out->colorspace = AVCOL_SPC_UNSPECIFIED; > + > if (scale->output_is_pal) > avpriv_set_systematic_pal2((uint32_t*)out->data[1], outlink->format > == AV_PIX_FMT_PAL8 ? AV_PIX_FMT_BGR8 : outlink->format); > > -- > 2.31.1 > Unless there are objections, I will pull this in soon. I will also attempt to see if I can add a programmatic FATE test for all of the allowed configurations of vf_scale, to see if there are any other clear-cut cases where not all metadata from the input AVFrame can be passed on as-is and has to be reset. Jan ___ 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] [RFC] Add option for writing detailed filtergraph information to file or stdout
> -Original Message- > From: ffmpeg-devel On Behalf Of > Paul B Mahol > Sent: Thursday, 26 August 2021 09:36 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing > detailed filtergraph information to file or stdout > > Unacceptable, NACK. Sounds like your new hit single? I prefer classics though, like: - NACK around the clock - We will NACK you! - NACKING on heaven's door.. :-) ___ 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] avutil/twofish: Fixed decryption
ping
On Mon, Aug 09, 2021 at 03:26:20AM +0200, Sebastian Kirmayer wrote:
> The previous implementation swapped the two halves of the plaintext. The
> existing tests only decrypted data with a plaintext of all zeroes, which is
> not affected by swapping the halves. Tests which detect the old buggy behavior
> have been added.
>
> Signed-off-by: Sebastian Kirmayer
> ---
> libavutil/tests/twofish.c | 15 ---
> libavutil/twofish.c | 8
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/libavutil/tests/twofish.c b/libavutil/tests/twofish.c
> index 74e0926e..7e8b1292 100644
> --- a/libavutil/tests/twofish.c
> +++ b/libavutil/tests/twofish.c
> @@ -39,7 +39,7 @@ int main(int argc, char *argv[])
> };
> uint8_t temp[32], iv[16], rpt[32] = {0};
> const int kbits[3] = {128, 192, 256};
> -int i, j, err = 0;
> +int i, j, k, err = 0;
> struct AVTWOFISH *cs;
> cs = av_twofish_alloc();
> if (!cs)
> @@ -70,10 +70,19 @@ int main(int argc, char *argv[])
> memcpy(Key+16,Key,(kbits[j]-128) >> 3);
> memcpy(Key,rpt,16);
> memcpy(rpt,temp,16);
> +av_twofish_crypt(cs, temp, temp, 1, NULL, 1);
> +for (k = 0; k < 16; k++) {
> +// Need to compare to Key here, because the plaintext comes
> +// from rpt but was moved over to Key.
> +if (Key[k] != temp[k]) {
> +av_log(NULL, AV_LOG_ERROR, "%d %02x %02x\n", k, Key[k],
> temp[k]);
> +err = 1;
> +}
> +}
> }
> for (i = 0; i < 16; i++) {
> -if (rct[3 + j][i] != temp[i]) {
> -av_log(NULL, AV_LOG_ERROR, "%d %02x %02x\n", i, rct[3 +
> j][i], temp[i]);
> +if (rct[3 + j][i] != rpt[i]) {
> +av_log(NULL, AV_LOG_ERROR, "%d %02x %02x\n", i, rct[3 +
> j][i], rpt[i]);
> err = 1;
> }
> }
> diff --git a/libavutil/twofish.c b/libavutil/twofish.c
> index d84fa4f3..649b4bc4 100644
> --- a/libavutil/twofish.c
> +++ b/libavutil/twofish.c
> @@ -260,10 +260,10 @@ static void twofish_decrypt(AVTWOFISH *cs, uint8_t
> *dst, const uint8_t *src, uin
> P[3] ^= AV_RL32(iv + 12);
> memcpy(iv, src, 16);
> }
> -AV_WL32(dst, P[2]);
> -AV_WL32(dst + 4, P[3]);
> -AV_WL32(dst + 8, P[0]);
> -AV_WL32(dst + 12, P[1]);
> +AV_WL32(dst, P[0]);
> +AV_WL32(dst + 4, P[1]);
> +AV_WL32(dst + 8, P[2]);
> +AV_WL32(dst + 12, P[3]);
> }
>
> av_cold int av_twofish_init(AVTWOFISH *cs, const uint8_t *key, int key_bits)
> --
> 2.27.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 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] webp: fix transforms after a palette with pixel packing.
Hi, On Thu, Aug 26, 2021 at 9:06 AM Maryla Ustarroz wrote: > Note top posting is discouraged here [1]. > We've just added a file to libwebp-test-data that covers this case: > https://chromium.googlesource.com/webm/libwebp-test-data/+/refs/heads/main/dual_transform.webp > FFmpeg currently fails to decode it, but it works with this patch. > > My understanding is that an ffmpeg developer needs to upload the file to > fate, and then I can add a fate test to the patch? > Yes, a link to the file is all that's needed [2][3]. You may include this as a reply to the initial patch or in the commit message for visibility. [1] https://ffmpeg.org/contact.html#MailingLists [2] https://ffmpeg.org/developer.html#Adding-files-to-the-fate_002dsuite-dataset [3] https://ffmpeg.org/fate.html#Uploading-new-samples-to-the-fate-suite > > > On Fri, Aug 20, 2021 at 7:07 PM James Zern > wrote: > > > On Thu, Aug 19, 2021 at 12:56 AM Maryla > > wrote: > > > > > > When a color indexing transform with 16 or fewer colors is used, > > > WebP uses "pixel packing", i.e. storing several pixels in one byte, > > > which virtually reduces the width of the image (see WebPContext's > > > reduced_width field). This reduced_width should always be used when > > > reading and applying subsequent transforms. > > > > > > Fixes: 9368 > > > > Is there anything in > > https://chromium.googlesource.com/webm/libwebp-test-data that covers > > this or can you add the file from the ticket to fate? > > ___ > > 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". ___ 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] lavfi/formats: document the negotiation process
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Thursday, 19 August 2021 17:31 > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH 3/3] lavfi/formats: document the > negotiation process > > Signed-off-by: Nicolas George > --- > libavfilter/formats.h | 85 > +++ > 1 file changed, 85 insertions(+) Hi Nicolas, I finally came to review your proposed changes as documented in this patch and I also watched your presentation: https://www.normalesup.org/~george/articles/format_negotiation_in_libavfilter/#0 >From a general point of view, most of your ideas make sense to me - probably even all of them when viewed individually. But in the moment when you are putting this all together, I'm getting a bit scared. The one concern I have about this is the possibility of loosing - control of negotiated formats and - deterministic filter behavior The whole process (e.g. a single ffmpeg run) will probably remain to be deterministic (same input will always produce the same output), but that would no longer apply to individual filters in a graph. What I mean is that - at least as far as I have understood the proposal, every single change that you make to a filter graph could completely change the formats that are negotiated between individual filters. This can surely provide better results than the current implementation, but it can also make things worse in cases like mine, where I am building filter graphs in a way that relies on precisely predicting/knowing the negotiated formats of all filter connections in advance. I don't want get too far at this point; maybe I misunderstood something, or you already have a plan for addressing these concerns? PS: I'll respond separately on the subtitles subject Kind regards, softworkz ___ 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] Add option for writing detailed filtergraph information to file or stdout
This is a more complete and more flexible alternative to the recently submitted
patch "fftools: add -lavfi_dump option"
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210823094504.100789-2-geo...@nsup.org/
I'm tagging this patch as 'RFC'. There's no need to tell that this is
duplicating
code from ffprobe. It does, because that's the most efficient way for the code
to
live at my side (unaffected and safe from regressions by upstream changes).
Should it be considered for merging into main, it will likely make sense to
merge
and or re-use ffprobe output writers.
The key benefits of this implementation are:
- Other than graph2dot and other means for printing filter graphs, this is
outputting:
- all graphs with runtime state
(including auto-inserted filters)
- each graph with its inputs and outputs
- all filters with their in- and output pads
- all connections between all input- and output pads
- for each connection:
- the runtime-negotiated format and media type
- the hw context
- if video hw context, both: hw pixfmt + sw pixfmt
- Output can either be printed to stdout or written to specified file
- Output is machine-readable
- Can output in all the same formats like ffprobe (default, compact, flat,
ini, json, xml)
Signed-off-by: softworkz
---
v2: Fix Fate
fftools/Makefile|2 +-
fftools/ffmpeg.c| 15 +
fftools/ffmpeg.h|3 +
fftools/ffmpeg_opt.c|9 +
fftools/filterwriters.c | 1559 +++
fftools/filterwriters.h | 205 +
6 files changed, 1792 insertions(+), 1 deletion(-)
create mode 100644 fftools/filterwriters.c
create mode 100644 fftools/filterwriters.h
diff --git a/fftools/Makefile b/fftools/Makefile
index 5234932ab0..384b340018 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -9,7 +9,7 @@ AVBASENAMES = ffmpeg ffplay ffprobe
ALLAVPROGS = $(AVBASENAMES:%=%$(PROGSSUF)$(EXESUF))
ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF))
-OBJS-ffmpeg+= fftools/ffmpeg_opt.o
fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o
+OBJS-ffmpeg+= fftools/ffmpeg_opt.o
fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o fftools/filterwriters.o
ifndef CONFIG_VIDEOTOOLBOX
OBJS-ffmpeg-$(CONFIG_VDA) += fftools/ffmpeg_videotoolbox.o
endif
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index b0ce7c7c32..7ffdc5250c 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -103,6 +103,7 @@
#include "ffmpeg.h"
#include "cmdutils.h"
+#include "filterwriters.h"
#include "libavutil/avassert.h"
@@ -139,6 +140,7 @@ static int64_t decode_error_stat[2];
static unsigned nb_output_dumped = 0;
static int want_sdp = 1;
+static int filtergraphs_printed = 0;
static BenchmarkTimeStamps current_time;
AVIOContext *progress_avio = NULL;
@@ -512,10 +514,23 @@ static int decode_interrupt_cb(void *ctx)
const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL };
+static void check_print_graphs(void)
+{
+if (filtergraphs_printed)
+return;
+
+if (print_graphs || print_graphs_file)
+print_filtergraphs(filtergraphs, nb_filtergraphs);
+
+filtergraphs_printed = 1;
+}
+
static void ffmpeg_cleanup(int ret)
{
int i, j;
+check_print_graphs();
+
if (do_benchmark) {
int maxrss = getmaxrss() / 1024;
av_log(NULL, AV_LOG_INFO, "bench: maxrss=%ikB\n", maxrss);
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index d2dd7ca092..1697f42028 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -636,6 +636,9 @@ extern char *videotoolbox_pixfmt;
extern int filter_nbthreads;
extern int filter_complex_nbthreads;
extern int vstats_version;
+extern int print_graphs;
+extern char* print_graphs_file;
+extern char* print_graphs_format;
extern int auto_conversion_filters;
extern const AVIOInterruptCB int_cb;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 428934a3d8..6ffded5f9d 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -172,6 +172,9 @@ float max_error_rate = 2.0/3;
int filter_nbthreads = 0;
int filter_complex_nbthreads = 0;
int vstats_version = 2;
+int print_graphs = 0;
+char* print_graphs_file = NULL;
+char* print_graphs_format = NULL;
int auto_conversion_filters = 1;
int64_t stats_period = 50;
@@ -3634,6 +3637,12 @@ const OptionDef options[] = {
"create a complex filtergraph", "graph_description" },
{ "filter_complex_script", HAS_ARG | OPT_EXPERT, {
.func_arg = opt_filter_complex_script },
"read complex filtergraph description from a file", "filename" },
+{ "print_graphs", OPT_BOOL,{
&print_graphs },
+"prints filtergraph details to stderr" },
+{ "print_graphs_file", HAS_ARG | OPT_STRING, {
&print_graphs_file },
+"writes graph details to a file", "filename" },
+{ "print_graphs_format", OPT_STRING | HAS_ARG, {
Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error output
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Thursday, August 26, 2021 5:12 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error
> output
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Wang, Fei W
> > Sent: Tuesday, 24 August 2021 07:32
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect
> > error output
> >
> > On Tue, 2021-08-24 at 02:45 +, Soft Works wrote:
> > > > -Original Message-
> > > > From: ffmpeg-devel On Behalf Of
> > > > Ronald S. Bultje
> > > > Sent: Tuesday, 24 August 2021 04:34
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > > > incorrect error output
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Aug 23, 2021 at 9:39 PM Soft Works
> >
> > > > wrote:
> > > >
> > > > > The current message "Your platform doesn't suppport hardware
> > > > > accelerated AV1 decoding." is inaccurate and misleading. When a
> > > > > user doesn't specify a hwcaccel, this doesn't tell anything
> > > > > about what is actually supported on that platform.
> > > > >
> > > > > Signed-off-by: softworkz
> > > > > ---
> > > > > libavcodec/av1dec.c | 4 ++--
> > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c index
> > > > > a75d6744d3..8dfcd26cb6 100644
> > > > > --- a/libavcodec/av1dec.c
> > > > > +++ b/libavcodec/av1dec.c
> > > > > @@ -462,8 +462,8 @@ static int get_pixel_format(AVCodecContext
> > > >
> > > > *avctx)
> > > > > * implemented in the future, need remove this check.
> > > > > */
> > > > > if (!avctx->hwaccel) {
> > > > > -av_log(avctx, AV_LOG_ERROR, "Your platform doesn't
> > > >
> > > > suppport"
> > > > > - " hardware accelerated AV1 decoding.\n");
> > > > > +av_log(avctx, AV_LOG_ERROR, "AV1 decoding requires a
> > hw
> > > > > acceleration"
> > > > > + " to be specified.\n");
> > > > >
> > > >
> > > > This is misleading.
> > > >
> > > > This error message (for me) happens when I accidentally compile
> > > > FFmpeg without aom/dav1d support, and try to play AV1 content.
> > >
> > > It also happens to me when I specify:
> > >
> > > ffmpeg -c:v av1 -i INPUT OUTPUT
> > >
> > > (e.g. like when I'd have forgotten to specify the hwaccel)
> > >
> > > > AV1 decoding
> > > > does
> > > > not require hw decoding - it simply requires an external library.
> > > >
> > > > Will the hwaccel be autodetected when AV1 hw decoding is
> > supported
> > > > by
> > > > the
> > > > platform?
> > >
> > > No.
> > >
> > > How about this: "The AV1 decoder requires a hw acceleration to be
> > > specified." ?
> >
> > This will bring new misleading if user specify the hw acceleration but
> > the hardware itself doesn't support av1 dec.
>
> Such situations may happen, but this is not subject of this patch.
> This patch is about the error that is printed when no hw acceleration has been
> specified.
Yes, I understand your purpose. But here avctx->hwaccel==NULL does not
stands for hw acceleration has not been specified in a hundred percent. If
specificed hw
acceleration init fail in ff_thread_get_format which is just 1 line above your
modify,
then avctx->hwaccel will be NULL too. And even the hw init fail, return value
of
ff_thread_get_format may 0 with some error log printed. For example run the cmd
on Skylake:
$ ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose -i
av1.ivf -pix_fmt yuv420p -vsync passthrough -f null -
Output log will be:
[av1 @ 0x556613499fc0] No support for codec av1 profile 0.
[av1 @ 0x556613499fc0] Failed setup for format vaapi: hwaccel initialisation
returned error.
[av1 @ 0x556613499fc0] Your platform doesn't suppport hardware accelerated AV1
decoding.
[av1 @ 0x556613499fc0] Failed to get pixel format.
If you just want to make sure weather hw is specified, maybe can use
avctx->hw_device_ctx instead of avctx->hwaccel. And better to put the check
before
calling ff_thread_get_format.
>
> If the specified hw accel is not available or cannot be initialized, then
> there will
> be an error reported at an earlier stage.
>
> If the specified hw accel has been initialized successfully but the hwaccel
> doesn't
> support AV1, this check won't catch it anyway.
This will not happen for VAAPI. If hwaccel doesn't support AV1, the hw accel
init
will not success.
Fei
Thanks
>
> Kind regards,
> softworkz
> ___
> 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] [PATCH v3] fftools: Add option for writing detailed filtergraph information to file or stdout
This is a more complete and more flexible alternative to the recently submitted
patch "fftools: add -lavfi_dump option"
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210823094504.100789-2-geo...@nsup.org/
I'm tagging this patch as 'RFC'. There's no need to tell that this is
duplicating
code from ffprobe. It does, because that's the most efficient way for the code
to
live at my side (unaffected and safe from regressions by upstream changes).
Should it be considered for merging into main, it will likely make sense to
merge
and or re-use ffprobe output writers.
The key benefits of this implementation are:
- Other than graph2dot and other means for printing filter graphs, this is
outputting:
- all graphs with runtime state
(including auto-inserted filters)
- each graph with its inputs and outputs
- all filters with their in- and output pads
- all connections between all input- and output pads
- for each connection:
- the runtime-negotiated format and media type
- the hw context
- if video hw context, both: hw pixfmt + sw pixfmt
- Output can either be printed to stdout or written to specified file
- Output is machine-readable
- Can output in all the same formats like ffprobe (default, compact, flat,
ini, json, xml)
Signed-off-by: softworkz
---
v3: adjust commit message (add context)
fftools/Makefile|2 +-
fftools/ffmpeg.c| 15 +
fftools/ffmpeg.h|3 +
fftools/ffmpeg_opt.c|9 +
fftools/filterwriters.c | 1559 +++
fftools/filterwriters.h | 205 +
6 files changed, 1792 insertions(+), 1 deletion(-)
create mode 100644 fftools/filterwriters.c
create mode 100644 fftools/filterwriters.h
diff --git a/fftools/Makefile b/fftools/Makefile
index 5234932ab0..384b340018 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -9,7 +9,7 @@ AVBASENAMES = ffmpeg ffplay ffprobe
ALLAVPROGS = $(AVBASENAMES:%=%$(PROGSSUF)$(EXESUF))
ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF))
-OBJS-ffmpeg+= fftools/ffmpeg_opt.o
fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o
+OBJS-ffmpeg+= fftools/ffmpeg_opt.o
fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o fftools/filterwriters.o
ifndef CONFIG_VIDEOTOOLBOX
OBJS-ffmpeg-$(CONFIG_VDA) += fftools/ffmpeg_videotoolbox.o
endif
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index b0ce7c7c32..7ffdc5250c 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -103,6 +103,7 @@
#include "ffmpeg.h"
#include "cmdutils.h"
+#include "filterwriters.h"
#include "libavutil/avassert.h"
@@ -139,6 +140,7 @@ static int64_t decode_error_stat[2];
static unsigned nb_output_dumped = 0;
static int want_sdp = 1;
+static int filtergraphs_printed = 0;
static BenchmarkTimeStamps current_time;
AVIOContext *progress_avio = NULL;
@@ -512,10 +514,23 @@ static int decode_interrupt_cb(void *ctx)
const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL };
+static void check_print_graphs(void)
+{
+if (filtergraphs_printed)
+return;
+
+if (print_graphs || print_graphs_file)
+print_filtergraphs(filtergraphs, nb_filtergraphs);
+
+filtergraphs_printed = 1;
+}
+
static void ffmpeg_cleanup(int ret)
{
int i, j;
+check_print_graphs();
+
if (do_benchmark) {
int maxrss = getmaxrss() / 1024;
av_log(NULL, AV_LOG_INFO, "bench: maxrss=%ikB\n", maxrss);
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index d2dd7ca092..1697f42028 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -636,6 +636,9 @@ extern char *videotoolbox_pixfmt;
extern int filter_nbthreads;
extern int filter_complex_nbthreads;
extern int vstats_version;
+extern int print_graphs;
+extern char* print_graphs_file;
+extern char* print_graphs_format;
extern int auto_conversion_filters;
extern const AVIOInterruptCB int_cb;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 428934a3d8..6ffded5f9d 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -172,6 +172,9 @@ float max_error_rate = 2.0/3;
int filter_nbthreads = 0;
int filter_complex_nbthreads = 0;
int vstats_version = 2;
+int print_graphs = 0;
+char* print_graphs_file = NULL;
+char* print_graphs_format = NULL;
int auto_conversion_filters = 1;
int64_t stats_period = 50;
@@ -3634,6 +3637,12 @@ const OptionDef options[] = {
"create a complex filtergraph", "graph_description" },
{ "filter_complex_script", HAS_ARG | OPT_EXPERT, {
.func_arg = opt_filter_complex_script },
"read complex filtergraph description from a file", "filename" },
+{ "print_graphs", OPT_BOOL,{
&print_graphs },
+"prints filtergraph details to stderr" },
+{ "print_graphs_file", HAS_ARG | OPT_STRING, {
&print_graphs_file },
+"writes graph details to a file", "filename" },
+{ "print_graphs_format", OPT_STRING | HAS
Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error output
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Wang, Fei W
> Sent: Friday, 27 August 2021 05:05
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect
> error output
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> Soft
> > Works
> > Sent: Thursday, August 26, 2021 5:12 AM
> > To: FFmpeg development discussions and patches de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> incorrect error
> > output
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Wang, Fei W
> > > Sent: Tuesday, 24 August 2021 07:32
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> incorrect
> > > error output
> > >
> > > On Tue, 2021-08-24 at 02:45 +, Soft Works wrote:
> > > > > -Original Message-
> > > > > From: ffmpeg-devel On
> Behalf Of
> > > > > Ronald S. Bultje
> > > > > Sent: Tuesday, 24 August 2021 04:34
> > > > > To: FFmpeg development discussions and patches > > > > de...@ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > > > > incorrect error output
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Mon, Aug 23, 2021 at 9:39 PM Soft Works
> > >
> > > > > wrote:
> > > > >
> > > > > > The current message "Your platform doesn't suppport
> hardware
> > > > > > accelerated AV1 decoding." is inaccurate and misleading.
> When a
> > > > > > user doesn't specify a hwcaccel, this doesn't tell anything
> > > > > > about what is actually supported on that platform.
> > > > > >
> > > > > > Signed-off-by: softworkz
> > > > > > ---
> > > > > > libavcodec/av1dec.c | 4 ++--
> > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> index
> > > > > > a75d6744d3..8dfcd26cb6 100644
> > > > > > --- a/libavcodec/av1dec.c
> > > > > > +++ b/libavcodec/av1dec.c
> > > > > > @@ -462,8 +462,8 @@ static int
> get_pixel_format(AVCodecContext
> > > > >
> > > > > *avctx)
> > > > > > * implemented in the future, need remove this check.
> > > > > > */
> > > > > > if (!avctx->hwaccel) {
> > > > > > -av_log(avctx, AV_LOG_ERROR, "Your platform doesn't
> > > > >
> > > > > suppport"
> > > > > > - " hardware accelerated AV1 decoding.\n");
> > > > > > +av_log(avctx, AV_LOG_ERROR, "AV1 decoding requires
> a
> > > hw
> > > > > > acceleration"
> > > > > > + " to be specified.\n");
> > > > > >
> > > > >
> > > > > This is misleading.
> > > > >
> > > > > This error message (for me) happens when I accidentally
> compile
> > > > > FFmpeg without aom/dav1d support, and try to play AV1
> content.
> > > >
> > > > It also happens to me when I specify:
> > > >
> > > > ffmpeg -c:v av1 -i INPUT OUTPUT
> > > >
> > > > (e.g. like when I'd have forgotten to specify the hwaccel)
> > > >
> > > > > AV1 decoding
> > > > > does
> > > > > not require hw decoding - it simply requires an external
> library.
> > > > >
> > > > > Will the hwaccel be autodetected when AV1 hw decoding is
> > > supported
> > > > > by
> > > > > the
> > > > > platform?
> > > >
> > > > No.
> > > >
> > > > How about this: "The AV1 decoder requires a hw acceleration to
> be
> > > > specified." ?
> > >
> > > This will bring new misleading if user specify the hw
> acceleration but
> > > the hardware itself doesn't support av1 dec.
> >
> > Such situations may happen, but this is not subject of this patch.
> > This patch is about the error that is printed when no hw
> acceleration has been
> > specified.
>
> Yes, I understand your purpose. But here avctx->hwaccel==NULL does
> not
> stands for hw acceleration has not been specified in a hundred
> percent. If specificed hw
> acceleration init fail in ff_thread_get_format which is just 1 line
> above your modify,
> then avctx->hwaccel will be NULL too. And even the hw init fail,
> return value of
> ff_thread_get_format may 0 with some error log printed. For example
> run the cmd
> on Skylake:
> $ ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v
> verbose -i av1.ivf -pix_fmt yuv420p -vsync passthrough -f null -
>
> Output log will be:
> [av1 @ 0x556613499fc0] No support for codec av1 profile 0.
> [av1 @ 0x556613499fc0] Failed setup for format vaapi: hwaccel
> initialisation returned error.
> [av1 @ 0x556613499fc0] Your platform doesn't suppport hardware
> accelerated AV1 decoding.
Ok, now let's take your output and replace the message with the
proposed one:
[av1 @ 0x556613499fc0] No support for codec av1 profile 0.
[av1 @ 0x556613499fc0] Failed setup for format vaapi: hwaccel initialisation
returned error.
[av1 @ 0x556613499fc0] The AV1 decoder requires a hw acceleration to be
specified.
[av1 @ 0x556613499fc0] Failed to get pixel format.
Isn't this still clear enough?
softworkz
___
Re: [FFmpeg-devel] [PATCH v3] fftools: Add option for writing detailed filtergraph information to file or stdout
> -Original Message- > From: ffmpeg-devel On Behalf Of > Soft Works > Sent: Friday, 27 August 2021 05:14 > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH v3] fftools: Add option for writing > detailed filtergraph information to file or stdout > > This is a more complete and more flexible alternative to the recently > submitted > patch "fftools: add -lavfi_dump option" > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210823094504.1007 > 89-2-geo...@nsup.org/ I'm submitting this updated version (fixes Fate) as I'm still convinced that this is a better alternative to the patch referenced above. What remains is the issue that this patch includes code that is duplicated from ffprobe.c The problem is that the code from ffprobe.c is not re-usable. At this point I'd like to ask what is expected from me to do about it? (for the hypothetical case that the patch would be agreeable) Is it my responsibility to refactor the ffprobe code to make it re-usable? - If no, what should I do? - Wait until somebody does this (or in this case, e.g. Nicolas' code gets merged) (which would mean that it's impossible to submit the patch) - Or can the patch with the duplicated be merged and the unification be done later? - If yes, in which order should it be done? - Merge patch first and do the unification afterwards? - Perform the ffprobe-refactoring as part of my patch?` - Submit another patch first which does the ffprobe refactoring? Thanks, softworkz ___ 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/av1dec: Adjust incorrect error output
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Friday, August 27, 2021 12:18 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error
> output
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Wang, Fei W
> > Sent: Friday, 27 August 2021 05:05
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect
> > error output
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > Soft
> > > Works
> > > Sent: Thursday, August 26, 2021 5:12 AM
> > > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > incorrect error
> > > output
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel On Behalf Of
> > > > Wang, Fei W
> > > > Sent: Tuesday, 24 August 2021 07:32
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > incorrect
> > > > error output
> > > >
> > > > On Tue, 2021-08-24 at 02:45 +, Soft Works wrote:
> > > > > > -Original Message-
> > > > > > From: ffmpeg-devel On
> > Behalf Of
> > > > > > Ronald S. Bultje
> > > > > > Sent: Tuesday, 24 August 2021 04:34
> > > > > > To: FFmpeg development discussions and patches > > > > > de...@ffmpeg.org>
> > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > > > > > incorrect error output
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Mon, Aug 23, 2021 at 9:39 PM Soft Works
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > The current message "Your platform doesn't suppport
> > hardware
> > > > > > > accelerated AV1 decoding." is inaccurate and misleading.
> > When a
> > > > > > > user doesn't specify a hwcaccel, this doesn't tell anything
> > > > > > > about what is actually supported on that platform.
> > > > > > >
> > > > > > > Signed-off-by: softworkz
> > > > > > > ---
> > > > > > > libavcodec/av1dec.c | 4 ++--
> > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > index
> > > > > > > a75d6744d3..8dfcd26cb6 100644
> > > > > > > --- a/libavcodec/av1dec.c
> > > > > > > +++ b/libavcodec/av1dec.c
> > > > > > > @@ -462,8 +462,8 @@ static int
> > get_pixel_format(AVCodecContext
> > > > > >
> > > > > > *avctx)
> > > > > > > * implemented in the future, need remove this check.
> > > > > > > */
> > > > > > > if (!avctx->hwaccel) {
> > > > > > > -av_log(avctx, AV_LOG_ERROR, "Your platform doesn't
> > > > > >
> > > > > > suppport"
> > > > > > > - " hardware accelerated AV1 decoding.\n");
> > > > > > > +av_log(avctx, AV_LOG_ERROR, "AV1 decoding requires
> > a
> > > > hw
> > > > > > > acceleration"
> > > > > > > + " to be specified.\n");
> > > > > > >
> > > > > >
> > > > > > This is misleading.
> > > > > >
> > > > > > This error message (for me) happens when I accidentally
> > compile
> > > > > > FFmpeg without aom/dav1d support, and try to play AV1
> > content.
> > > > >
> > > > > It also happens to me when I specify:
> > > > >
> > > > > ffmpeg -c:v av1 -i INPUT OUTPUT
> > > > >
> > > > > (e.g. like when I'd have forgotten to specify the hwaccel)
> > > > >
> > > > > > AV1 decoding
> > > > > > does
> > > > > > not require hw decoding - it simply requires an external
> > library.
> > > > > >
> > > > > > Will the hwaccel be autodetected when AV1 hw decoding is
> > > > supported
> > > > > > by
> > > > > > the
> > > > > > platform?
> > > > >
> > > > > No.
> > > > >
> > > > > How about this: "The AV1 decoder requires a hw acceleration to
> > be
> > > > > specified." ?
> > > >
> > > > This will bring new misleading if user specify the hw
> > acceleration but
> > > > the hardware itself doesn't support av1 dec.
> > >
> > > Such situations may happen, but this is not subject of this patch.
> > > This patch is about the error that is printed when no hw
> > acceleration has been
> > > specified.
> >
> > Yes, I understand your purpose. But here avctx->hwaccel==NULL does not
> > stands for hw acceleration has not been specified in a hundred
> > percent. If specificed hw acceleration init fail in
> > ff_thread_get_format which is just 1 line above your modify, then
> > avctx->hwaccel will be NULL too. And even the hw init fail, return
> > value of ff_thread_get_format may 0 with some error log printed. For
> > example run the cmd on Skylake:
> > $ ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose
> > -i av1.ivf -pix_fmt yuv420p -vsync passthrough -f null -
> >
> > Output log will be:
> > [av1 @ 0x556613499fc0] No support for codec av1 profile 0.
> > [av1 @ 0x556613499fc0] Failed setup for format vaapi: hwaccel
> > initialisation returned error.
> > [av1 @ 0x556613499f
[FFmpeg-devel] [PATCH 1/4] libavfilter/x86/vf_hflip: add ff_flip_byte/short_avx512()
Performance(Less is better):
8bit:
ff_hflip_byte_ssse3 0.61
ff_hflip_byte_avx20.37
ff_hflip_byte_avx512 0.19
16bit:
ff_hflip_short_ssse3 1.27
ff_hflip_short_avx2 0.76
ff_hflip_short_avx512 0.40
Signed-off-by: Wu Jianhua
---
libavfilter/x86/vf_hflip.asm| 23 ++-
libavfilter/x86/vf_hflip_init.c | 8
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/libavfilter/x86/vf_hflip.asm b/libavfilter/x86/vf_hflip.asm
index 285618954f..c2237217f7 100644
--- a/libavfilter/x86/vf_hflip.asm
+++ b/libavfilter/x86/vf_hflip.asm
@@ -26,12 +26,16 @@ SECTION_RODATA
pb_flip_byte: db 15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0
pb_flip_short: db 14,15,12,13,10,11,8,9,6,7,4,5,2,3,0,1
+pd_flip_indicies: dd 12,13,14,15,8,9,10,11,4,5,6,7,0,1,2,3
SECTION .text
;%1 byte or short, %2 b or w, %3 size in byte (1 for byte, 2 for short)
%macro HFLIP 3
cglobal hflip_%1, 3, 5, 3, src, dst, w, r, x
+%if mmsize == 64
+movu m3, [pd_flip_indicies]
+%endif
VBROADCASTI128m0, [pb_flip_%1]
xor xq, xq
%if %3 == 1
@@ -47,12 +51,15 @@ cglobal hflip_%1, 3, 5, 3, src, dst, w, r, x
.loop0:
neg xq
-%if mmsize == 32
-vpermq m1, [srcq + xq - mmsize + %3], 0x4e; flip each lane at load
-vpermq m2, [srcq + xq - 2 * mmsize + %3], 0x4e; flip each lane at load
+%if mmsize == 64
+vpermd m1, m3, [srcq + xq - mmsize + %3]
+vpermd m2, m3, [srcq + xq - 2 * mmsize + %3]
+%elif mmsize == 32
+vpermq m1, [srcq + xq - mmsize + %3], 0x4e; flip each lane at
load
+vpermq m2, [srcq + xq - 2 * mmsize + %3], 0x4e; flip each lane at
load
%else
-movum1, [srcq + xq - mmsize + %3]
-movum2, [srcq + xq - 2 * mmsize + %3]
+movum1, [srcq + xq - mmsize + %3]
+movum2, [srcq + xq - 2 * mmsize + %3]
%endif
pshufb m1, m0
pshufb m2, m0
@@ -88,3 +95,9 @@ INIT_YMM avx2
HFLIP byte, b, 1
HFLIP short, w, 2
%endif
+
+%if HAVE_AVX512_EXTERNAL
+INIT_ZMM avx512
+HFLIP byte, b, 1
+HFLIP short, w, 2
+%endif
diff --git a/libavfilter/x86/vf_hflip_init.c b/libavfilter/x86/vf_hflip_init.c
index 0ac399b0d4..25fc40f7b0 100644
--- a/libavfilter/x86/vf_hflip_init.c
+++ b/libavfilter/x86/vf_hflip_init.c
@@ -25,8 +25,10 @@
void ff_hflip_byte_ssse3(const uint8_t *src, uint8_t *dst, int w);
void ff_hflip_byte_avx2(const uint8_t *src, uint8_t *dst, int w);
+void ff_hflip_byte_avx512(const uint8_t *src, uint8_t *dst, int w);
void ff_hflip_short_ssse3(const uint8_t *src, uint8_t *dst, int w);
void ff_hflip_short_avx2(const uint8_t *src, uint8_t *dst, int w);
+void ff_hflip_short_avx512(const uint8_t *src, uint8_t *dst, int w);
av_cold void ff_hflip_init_x86(FlipContext *s, int step[4], int nb_planes)
{
@@ -41,6 +43,9 @@ av_cold void ff_hflip_init_x86(FlipContext *s, int step[4],
int nb_planes)
if (EXTERNAL_AVX2_FAST(cpu_flags)) {
s->flip_line[i] = ff_hflip_byte_avx2;
}
+if (EXTERNAL_AVX512(cpu_flags)) {
+s->flip_line[i] = ff_hflip_byte_avx512;
+}
} else if (step[i] == 2) {
if (EXTERNAL_SSSE3(cpu_flags)) {
s->flip_line[i] = ff_hflip_short_ssse3;
@@ -48,6 +53,9 @@ av_cold void ff_hflip_init_x86(FlipContext *s, int step[4],
int nb_planes)
if (EXTERNAL_AVX2_FAST(cpu_flags)) {
s->flip_line[i] = ff_hflip_short_avx2;
}
+if (EXTERNAL_AVX512(cpu_flags)) {
+s->flip_line[i] = ff_hflip_short_avx512;
+}
}
}
}
--
2.17.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 2/4] libavfilter/x86/vf_threshold_init: remove condition s->depth == 16
As we all know the 10bit samples would also be stored as a 16bits type,
the condition judgment will lead the SIMD optimizations to be uninitialized
when the depth is 10.
Signed-off-by: Wu Jianhua
---
libavfilter/x86/vf_threshold_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/x86/vf_threshold_init.c
b/libavfilter/x86/vf_threshold_init.c
index 8e42296791..71bde15097 100644
--- a/libavfilter/x86/vf_threshold_init.c
+++ b/libavfilter/x86/vf_threshold_init.c
@@ -48,7 +48,7 @@ av_cold void ff_threshold_init_x86(ThresholdContext *s)
if (EXTERNAL_AVX2_FAST(cpu_flags)) {
s->threshold = ff_threshold8_avx2;
}
-} else if (s->depth == 16) {
+} else {
if (EXTERNAL_SSE4(cpu_flags)) {
s->threshold = ff_threshold16_sse4;
}
--
2.17.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 3/4] libavfilter/x86/vf_threshold: add ff_threshold8/16_avx512
Performance(Less is better)
8bit:
ff_threshold8_sse432.7555351
ff_threshold8_avx232.1713562
ff_threshold8_avx512 32.0103531
16bit:
ff_threshold16_sse4 37.7713432
ff_threshold16_avx2 35.3348312
ff_threshold16_avx512 32.6976166
Signed-off-by: Wu Jianhua
---
libavfilter/x86/vf_threshold.asm| 44 +
libavfilter/x86/vf_threshold_init.c | 8 ++
2 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/libavfilter/x86/vf_threshold.asm b/libavfilter/x86/vf_threshold.asm
index 098069b083..dc4126c7af 100644
--- a/libavfilter/x86/vf_threshold.asm
+++ b/libavfilter/x86/vf_threshold.asm
@@ -29,6 +29,15 @@ pb_128_0 : times 8 db 0, 128
SECTION .text
+%macro DECL_MASK 2
+%if mmsize < 64
+%xdefine %1 m%2
+%else
+%assign %%i %2 + 1
+%xdefine %1 k %+ %%i
+%endif
+%endmacro
+
;%1 depth (8 or 16) ; %2 b or w ; %3 constant
%macro THRESHOLD 3
%if ARCH_X86_64
@@ -58,17 +67,24 @@ cglobal threshold%1, 5, 7, 5, in, threshold, min, max, out,
w, x
.nextrow:
mov xq, wq
-.loop:
-movum1, [inq + xq]
-movum0, [thresholdq + xq]
-movum2, [minq + xq]
-movum3, [maxq + xq]
-pxorm0, m4
-pxorm1, m4
-pcmpgt%2m0, m1
-PBLENDVBm3, m2, m0
-movu [outq + xq], m3
-add xq, mmsize
+.loop:
+movu m1, [inq + xq]
+movu m0, [thresholdq + xq]
+movu m2, [minq + xq]
+movu m3, [maxq + xq]
+pxor m0, m4
+pxor m1, m4
+DECL_MASK mask, 0
+pcmpgt%2mask, m0, m1
+
+%if mmsize == 64
+vpblendm%2 m3{mask}, m3, m2
+%else
+PBLENDVB m3, m2, mask
+%endif
+
+movu [outq + xq], m3
+add xq, mmsize
jl .loop
add inq, ilinesizeq
@@ -90,3 +106,9 @@ INIT_YMM avx2
THRESHOLD 8, b, pb_128
THRESHOLD 16, w, pb_128_0
%endif
+
+%if HAVE_AVX512_EXTERNAL
+INIT_ZMM avx512
+THRESHOLD 8, b, pb_128
+THRESHOLD 16, w, pb_128_0
+%endif
diff --git a/libavfilter/x86/vf_threshold_init.c
b/libavfilter/x86/vf_threshold_init.c
index 71bde15097..23500ea1bf 100644
--- a/libavfilter/x86/vf_threshold_init.c
+++ b/libavfilter/x86/vf_threshold_init.c
@@ -34,8 +34,10 @@ void ff_threshold##depth##_##opt(const uint8_t *in, const
uint8_t *threshold,\
THRESHOLD_FUNC(8, sse4)
THRESHOLD_FUNC(8, avx2)
+THRESHOLD_FUNC(8, avx512)
THRESHOLD_FUNC(16, sse4)
THRESHOLD_FUNC(16, avx2)
+THRESHOLD_FUNC(16, avx512)
av_cold void ff_threshold_init_x86(ThresholdContext *s)
{
@@ -48,6 +50,9 @@ av_cold void ff_threshold_init_x86(ThresholdContext *s)
if (EXTERNAL_AVX2_FAST(cpu_flags)) {
s->threshold = ff_threshold8_avx2;
}
+if (EXTERNAL_AVX512(cpu_flags)) {
+s->threshold = ff_threshold8_avx512;
+}
} else {
if (EXTERNAL_SSE4(cpu_flags)) {
s->threshold = ff_threshold16_sse4;
@@ -55,5 +60,8 @@ av_cold void ff_threshold_init_x86(ThresholdContext *s)
if (EXTERNAL_AVX2_FAST(cpu_flags)) {
s->threshold = ff_threshold16_avx2;
}
+if (EXTERNAL_AVX512(cpu_flags)) {
+s->threshold = ff_threshold16_avx512;
+}
}
}
--
2.17.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 4/4] libavfilter/vf_avgblur_vulkan: fix incorrect conditional judgement
Signed-off-by: Wu Jianhua
---
libavfilter/vf_avgblur_vulkan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_avgblur_vulkan.c b/libavfilter/vf_avgblur_vulkan.c
index 1e485061cd..2dbfc947a8 100644
--- a/libavfilter/vf_avgblur_vulkan.c
+++ b/libavfilter/vf_avgblur_vulkan.c
@@ -333,7 +333,7 @@ static int avgblur_vulkan_filter_frame(AVFilterLink *link,
AVFrame *in)
}
tmp = ff_get_video_buffer(outlink, outlink->w, outlink->h);
-if (!out) {
+if (!tmp) {
err = AVERROR(ENOMEM);
goto fail;
}
--
2.17.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] avcodec/av1dec: Adjust incorrect error output
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Wang, Fei W
> Sent: Friday, 27 August 2021 06:39
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect
> error output
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> Soft
> > Works
> > Sent: Friday, August 27, 2021 12:18 PM
> > To: FFmpeg development discussions and patches de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> incorrect error
> > output
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Wang, Fei W
> > > Sent: Friday, 27 August 2021 05:05
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> incorrect
> > > error output
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel On Behalf
> Of
> > > Soft
> > > > Works
> > > > Sent: Thursday, August 26, 2021 5:12 AM
> > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > > incorrect error
> > > > output
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: ffmpeg-devel On
> Behalf Of
> > > > > Wang, Fei W
> > > > > Sent: Tuesday, 24 August 2021 07:32
> > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > > incorrect
> > > > > error output
> > > > >
> > > > > On Tue, 2021-08-24 at 02:45 +, Soft Works wrote:
> > > > > > > -Original Message-
> > > > > > > From: ffmpeg-devel On
> > > Behalf Of
> > > > > > > Ronald S. Bultje
> > > > > > > Sent: Tuesday, 24 August 2021 04:34
> > > > > > > To: FFmpeg development discussions and patches > > > > > > de...@ffmpeg.org>
> > > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec:
> Adjust
> > > > > > > incorrect error output
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Mon, Aug 23, 2021 at 9:39 PM Soft Works
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > The current message "Your platform doesn't suppport
> > > hardware
> > > > > > > > accelerated AV1 decoding." is inaccurate and
> misleading.
> > > When a
> > > > > > > > user doesn't specify a hwcaccel, this doesn't tell
> anything
> > > > > > > > about what is actually supported on that platform.
> > > > > > > >
> > > > > > > > Signed-off-by: softworkz
> > > > > > > > ---
> > > > > > > > libavcodec/av1dec.c | 4 ++--
> > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > > index
> > > > > > > > a75d6744d3..8dfcd26cb6 100644
> > > > > > > > --- a/libavcodec/av1dec.c
> > > > > > > > +++ b/libavcodec/av1dec.c
> > > > > > > > @@ -462,8 +462,8 @@ static int
> > > get_pixel_format(AVCodecContext
> > > > > > >
> > > > > > > *avctx)
> > > > > > > > * implemented in the future, need remove this
> check.
> > > > > > > > */
> > > > > > > > if (!avctx->hwaccel) {
> > > > > > > > -av_log(avctx, AV_LOG_ERROR, "Your platform
> doesn't
> > > > > > >
> > > > > > > suppport"
> > > > > > > > - " hardware accelerated AV1
> decoding.\n");
> > > > > > > > +av_log(avctx, AV_LOG_ERROR, "AV1 decoding
> requires
> > > a
> > > > > hw
> > > > > > > > acceleration"
> > > > > > > > + " to be specified.\n");
> > > > > > > >
> > > > > > >
> > > > > > > This is misleading.
> > > > > > >
> > > > > > > This error message (for me) happens when I accidentally
> > > compile
> > > > > > > FFmpeg without aom/dav1d support, and try to play AV1
> > > content.
> > > > > >
> > > > > > It also happens to me when I specify:
> > > > > >
> > > > > > ffmpeg -c:v av1 -i INPUT OUTPUT
> > > > > >
> > > > > > (e.g. like when I'd have forgotten to specify the hwaccel)
> > > > > >
> > > > > > > AV1 decoding
> > > > > > > does
> > > > > > > not require hw decoding - it simply requires an external
> > > library.
> > > > > > >
> > > > > > > Will the hwaccel be autodetected when AV1 hw decoding is
> > > > > supported
> > > > > > > by
> > > > > > > the
> > > > > > > platform?
> > > > > >
> > > > > > No.
> > > > > >
> > > > > > How about this: "The AV1 decoder requires a hw acceleration
> to
> > > be
> > > > > > specified." ?
> > > > >
> > > > > This will bring new misleading if user specify the hw
> > > acceleration but
> > > > > the hardware itself doesn't support av1 dec.
> > > >
> > > > Such situations may happen, but this is not subject of this
> patch.
> > > > This patch is about the error that is printed when no hw
> > > acceleration has been
> > > > specified.
> > >
> > > Yes, I understand your purpose. But here avctx->hwaccel==NULL
> does not
> > > stands for hw acceleration has not been specified in a hundred
> > > percent. If specificed hw acceleration init fail in
> > > ff
Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error output
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Friday, August 27, 2021 1:25 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error
> output
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Wang, Fei W
> > Sent: Friday, 27 August 2021 06:39
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect
> > error output
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > Soft
> > > Works
> > > Sent: Friday, August 27, 2021 12:18 PM
> > > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > incorrect error
> > > output
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel On Behalf Of
> > > > Wang, Fei W
> > > > Sent: Friday, 27 August 2021 05:05
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > incorrect
> > > > error output
> > > >
> > > > > -Original Message-
> > > > > From: ffmpeg-devel On Behalf
> > Of
> > > > Soft
> > > > > Works
> > > > > Sent: Thursday, August 26, 2021 5:12 AM
> > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > > > incorrect error
> > > > > output
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: ffmpeg-devel On
> > Behalf Of
> > > > > > Wang, Fei W
> > > > > > Sent: Tuesday, 24 August 2021 07:32
> > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > > > incorrect
> > > > > > error output
> > > > > >
> > > > > > On Tue, 2021-08-24 at 02:45 +, Soft Works wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: ffmpeg-devel On
> > > > Behalf Of
> > > > > > > > Ronald S. Bultje
> > > > > > > > Sent: Tuesday, 24 August 2021 04:34
> > > > > > > > To: FFmpeg development discussions and patches > > > > > > > de...@ffmpeg.org>
> > > > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec:
> > Adjust
> > > > > > > > incorrect error output
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Mon, Aug 23, 2021 at 9:39 PM Soft Works
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > The current message "Your platform doesn't suppport
> > > > hardware
> > > > > > > > > accelerated AV1 decoding." is inaccurate and
> > misleading.
> > > > When a
> > > > > > > > > user doesn't specify a hwcaccel, this doesn't tell
> > anything
> > > > > > > > > about what is actually supported on that platform.
> > > > > > > > >
> > > > > > > > > Signed-off-by: softworkz
> > > > > > > > > ---
> > > > > > > > > libavcodec/av1dec.c | 4 ++--
> > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > > > index
> > > > > > > > > a75d6744d3..8dfcd26cb6 100644
> > > > > > > > > --- a/libavcodec/av1dec.c
> > > > > > > > > +++ b/libavcodec/av1dec.c
> > > > > > > > > @@ -462,8 +462,8 @@ static int
> > > > get_pixel_format(AVCodecContext
> > > > > > > >
> > > > > > > > *avctx)
> > > > > > > > > * implemented in the future, need remove this
> > check.
> > > > > > > > > */
> > > > > > > > > if (!avctx->hwaccel) {
> > > > > > > > > -av_log(avctx, AV_LOG_ERROR, "Your platform
> > doesn't
> > > > > > > >
> > > > > > > > suppport"
> > > > > > > > > - " hardware accelerated AV1
> > decoding.\n");
> > > > > > > > > +av_log(avctx, AV_LOG_ERROR, "AV1 decoding
> > requires
> > > > a
> > > > > > hw
> > > > > > > > > acceleration"
> > > > > > > > > + " to be specified.\n");
> > > > > > > > >
> > > > > > > >
> > > > > > > > This is misleading.
> > > > > > > >
> > > > > > > > This error message (for me) happens when I accidentally
> > > > compile
> > > > > > > > FFmpeg without aom/dav1d support, and try to play AV1
> > > > content.
> > > > > > >
> > > > > > > It also happens to me when I specify:
> > > > > > >
> > > > > > > ffmpeg -c:v av1 -i INPUT OUTPUT
> > > > > > >
> > > > > > > (e.g. like when I'd have forgotten to specify the hwaccel)
> > > > > > >
> > > > > > > > AV1 decoding
> > > > > > > > does
> > > > > > > > not require hw decoding - it simply requires an external
> > > > library.
> > > > > > > >
> > > > > > > > Will the hwaccel be autodetected when AV1 hw decoding is
> > > > > > supported
> > > > > > > > by
> > > > > > > > the
> > > > > > > > platform?
> > > > > > >
> > > > > > > No.
> > > > > > >
> > > > > > > How about this: "The AV1 decoder requires a hw acceleration
> > to
> > > > be
> > > > > > > specified." ?
> > > > > >
> >
[FFmpeg-devel] [PATCH v2 1/1] avcodec/wmaprodec: return value check for init_get_bits
avcodec/wmaprodec: Return value check for init_get_bits
Similar to CVE-2021-38171 as the second argument for init_get_bits(avpkt and
buf) can be crafted,
a return value check for this function call is necessary.
Also replace init_get_bits with init_get_bits8.
---
libavcodec/wmaprodec.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
index e0d00d2d37..0e229b258d 100644
--- a/libavcodec/wmaprodec.c
+++ b/libavcodec/wmaprodec.c
@@ -1615,6 +1615,7 @@ static int decode_packet(AVCodecContext *avctx,
WMAProDecodeCtx *s,
int buf_size = avpkt->size;
int num_bits_prev_frame;
int packet_sequence_number;
+int ret;
*got_frame_ptr = 0;
@@ -1666,7 +1667,9 @@ static int decode_packet(AVCodecContext *avctx,
WMAProDecodeCtx *s,
s->buf_bit_size = buf_size << 3;
/** parse packet header */
-init_get_bits(gb, buf, s->buf_bit_size);
+ret = init_get_bits8(gb, buf, buf_size);
+if (ret < 0)
+return ret;
if (avctx->codec_id != AV_CODEC_ID_XMA2) {
packet_sequence_number = get_bits(gb, 4);
skip_bits(gb, 2);
@@ -1734,7 +1737,9 @@ static int decode_packet(AVCodecContext *avctx,
WMAProDecodeCtx *s,
}
s->buf_bit_size = (avpkt->size - s->next_packet_start) << 3;
-init_get_bits(gb, avpkt->data, s->buf_bit_size);
+ret = init_get_bits8(gb, avpkt->data, (avpkt->size -
s->next_packet_start));
+if (ret < 0)
+return ret;
skip_bits(gb, s->packet_offset);
if (s->len_prefix && remaining_bits(s, gb) > s->log2_frame_size &&
(frame_size = show_bits(gb, s->log2_frame_size)) &&
--
2.17.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 v2 1/1] avcodec/wmalosslessdec: return value check for init_get_bits
Similar to CVE-2021-38171 as the second argument for init_get_bits(avpkt and bu$ a return value check for this function call is necessary. Also replace init_get_bits with init_get_bits8. --- libavcodec/wmalosslessdec.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c index 74c91f4f7e..1173ef62c2 100644 --- a/libavcodec/wmalosslessdec.c +++ b/libavcodec/wmalosslessdec.c @@ -1187,6 +1187,7 @@ static int decode_packet(AVCodecContext *avctx, void *data, int *got_frame_ptr, const uint8_t* buf = avpkt->data; int buf_size = avpkt->size; int num_bits_prev_frame, packet_sequence_number, spliced_packet; +int ret; s->frame->nb_samples = 0; @@ -1205,7 +1206,9 @@ static int decode_packet(AVCodecContext *avctx, void *data, int *got_frame_ptr, s->buf_bit_size = buf_size << 3; /* parse packet header */ -init_get_bits(gb, buf, s->buf_bit_size); +ret = init_get_bits8(gb, buf, buf_size); +if (ret < 0) +return ret; packet_sequence_number = get_bits(gb, 4); skip_bits(gb, 1); // Skip seekable_frame_in_packet, currently unused spliced_packet = get_bits1(gb); @@ -1256,7 +1259,9 @@ static int decode_packet(AVCodecContext *avctx, void *data, int *got_frame_ptr, int frame_size; s->buf_bit_size = (avpkt->size - s->next_packet_start) << 3; -init_get_bits(gb, avpkt->data, s->buf_bit_size); +init_get_bits8(gb, avpkt->data, (avpkt->size - s->next_packet_start)); +if (ret < 0) +return ret; skip_bits(gb, s->packet_offset); if (s->len_prefix && remaining_bits(s, gb) > s->log2_frame_size && -- 2.17.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".
