[FFmpeg-devel] [PATCH] avformat/file: seek back to initial position for fd protocol

2023-12-18 Thread Zhao Zhili
From: Zhao Zhili 

So user's fd can be passed to libavformat multiple times in sequence
without changing the position.

Signed-off-by: Zhao Zhili 
---
 libavformat/file.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/libavformat/file.c b/libavformat/file.c
index cbdf48de0a..64df7ff6fb 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -98,6 +98,7 @@ typedef struct FileContext {
 #if HAVE_DIRENT_H
 DIR *dir;
 #endif
+int64_t initial_pos;
 } FileContext;
 
 static const AVOption file_options[] = {
@@ -218,7 +219,12 @@ static int fd_dup(URLContext *h, int oldfd)
 static int file_close(URLContext *h)
 {
 FileContext *c = h->priv_data;
-int ret = close(c->fd);
+int ret;
+
+if (c->initial_pos >= 0 && !h->is_streamed)
+lseek(c->fd, c->initial_pos, SEEK_SET);
+
+ret = close(c->fd);
 return (ret == -1) ? AVERROR(errno) : 0;
 }
 
@@ -286,6 +292,7 @@ static int file_open(URLContext *h, const char *filename, 
int flags)
 
 av_strstart(filename, "file:", &filename);
 
+c->initial_pos = -1;
 if (flags & AVIO_FLAG_WRITE && flags & AVIO_FLAG_READ) {
 access = O_CREAT | O_RDWR;
 if (c->trunc)
@@ -494,6 +501,11 @@ static int fd_open(URLContext *h, const char *filename, 
int flags)
 if (c->fd == -1)
 return AVERROR(errno);
 
+if (h->is_streamed)
+c->initial_pos = -1;
+else
+c->initial_pos = lseek(c->fd, 0, SEEK_CUR);
+
 return 0;
 }
 
-- 
2.25.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] gdigrab: Fix hwnd parameter issues

2023-12-18 Thread Martin Storsjö
Converting from an integer to HWND (which is a pointer) requires
an explicit cast, otherwise Clang errors out like this:

src/libavdevice/gdigrab.c:280:14: error: incompatible integer to pointer 
conversion assigning to 'HWND' (aka 'struct HWND__ *') from 'long' 
[-Wint-conversion]
  280 | hwnd = strtol(name, &p, 0);
  |  ^ ~~~

(With GCC and MSVC, this was a mere warning, but with recent Clang,
this is an error.)

After adding a cast, all compilers also warn something like this:

src/libavdevice/gdigrab.c:280:16: warning: cast to 'HWND' (aka 'struct 
HWND__ *') from smaller integer type 'long' [-Wint-to-pointer-cast]
  280 | hwnd = (HWND) strtol(name, &p, 0);
  |^~

On Windows, long types are 32 bit, so to get a usable pointer, we
need to use long long. And interpret it as unsigned long long
while at it - i.e. using strtoull.

Finally, right above it, the code triggered the following warning:

src/libavdevice/gdigrab.c:278:15: warning: mixing declarations and code is 
incompatible with standards before C99 [-Wdeclaration-after-statement]
  278 | char *p;
  |   ^
---
 libavdevice/gdigrab.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index 41ef370f2b..b2858ecd89 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -274,10 +274,10 @@ gdigrab_read_header(AVFormatContext *s1)
 } else if (!strcmp(filename, "desktop")) {
 hwnd = NULL;
 } else if (!strncmp(filename, "hwnd=", 5)) {
-name = filename + 5;
 char *p;
+name = filename + 5;
 
-hwnd = strtol(name, &p, 0);
+hwnd = (HWND) strtoull(name, &p, 0);
 
 if (p == NULL || p == name || p[0] == '\0')
 {
-- 
2.34.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 04/20] fftools/ffmpeg_opt: move deprecated options to the end of the list

2023-12-18 Thread Anton Khirnov
This way they don't clutter this already-cluttered code even further.
---
 fftools/ffmpeg_opt.c | 44 +++-
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index aed20032a8..b545c42818 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1452,10 +1452,6 @@ const OptionDef options[] = {
 OPT_OUTPUT,  { 
.func_arg = opt_map },
 "set input stream mapping",
 
"[-]input_file_id[:stream_specifier][,sync_file_id[:stream_specifier]]" },
-#if FFMPEG_OPT_MAP_CHANNEL
-{ "map_channel",HAS_ARG | OPT_EXPERT | OPT_PERFILE | OPT_OUTPUT, { 
.func_arg = opt_map_channel },
-"map an audio channel from one stream to another (deprecated)", 
"file.stream.channel[:syncfile.syncstream]" },
-#endif
 { "map_metadata",   OPT_STRING | OPT_SPEC |
 OPT_OUTPUT,  { .off
   = OFFSET(metadata_map) },
 "set metadata information of outfile from infile",
@@ -1531,10 +1527,6 @@ const OptionDef options[] = {
 "set video sync method globally; deprecated, use -fps_mode", "" },
 { "frame_drop_threshold", OPT_FLOAT | OPT_EXPERT,  { 
&frame_drop_threshold },
 "frame drop threshold", "" },
-#if FFMPEG_OPT_ADRIFT_THRESHOLD
-{ "adrift_threshold", HAS_ARG | OPT_EXPERT,  { 
.func_arg = opt_adrift_threshold },
-"deprecated, does nothing", "threshold" },
-#endif
 { "copyts", OPT_BOOL | OPT_EXPERT,   { 
©_ts },
 "copy timestamps" },
 { "start_at_zero",  OPT_BOOL | OPT_EXPERT,   { 
&start_at_zero },
@@ -1683,10 +1675,6 @@ const OptionDef options[] = {
 { "passlogfile",  OPT_VIDEO | OPT_STRING | OPT_EXPERT | OPT_SPEC |
   OPT_OUTPUT,  
  { .off = OFFSET(passlogfiles) },
 "select two pass log file name prefix", "prefix" },
-#if FFMPEG_OPT_PSNR
-{ "psnr", OPT_VIDEO | OPT_BOOL | OPT_EXPERT,   
  { &do_psnr },
-"calculate PSNR of compressed frames (deprecated, use -flags +psnr)" },
-#endif
 { "vstats",   OPT_VIDEO | OPT_EXPERT , 
  { .func_arg = opt_vstats },
 "dump video coding statistics to file" },
 { "vstats_file",  OPT_VIDEO | HAS_ARG | OPT_EXPERT ,   
  { .func_arg = opt_vstats_file },
@@ -1704,18 +1692,9 @@ const OptionDef options[] = {
 { "chroma_intra_matrix", OPT_VIDEO | OPT_EXPERT  | OPT_STRING | OPT_SPEC |
   OPT_OUTPUT,  
  { .off = OFFSET(chroma_intra_matrices) },
 "specify intra matrix coeffs", "matrix" },
-#if FFMPEG_OPT_TOP
-{ "top",  OPT_VIDEO | OPT_EXPERT  | OPT_INT| OPT_SPEC |
-  OPT_INPUT | OPT_OUTPUT,  
  { .off = OFFSET(top_field_first) },
-"deprecated, use the setfield video filter", "" },
-#endif
 { "vtag", OPT_VIDEO | HAS_ARG | OPT_EXPERT  | OPT_PERFILE |
   OPT_INPUT | OPT_OUTPUT,  
  { .func_arg = opt_old2new },
 "force video tag/fourcc", "fourcc/tag" },
-#if FFMPEG_OPT_QPHIST
-{ "qphist",   OPT_VIDEO | OPT_EXPERT ,{ 
.func_arg = opt_qphist },
-"deprecated, does nothing" },
-#endif
 { "fps_mode", OPT_VIDEO | OPT_STRING | OPT_EXPERT |
   OPT_SPEC | OPT_OUTPUT,   
  { .off = OFFSET(fps_mode) },
 "set framerate mode for matching video streams; overrides vsync" },
@@ -1856,5 +1835,28 @@ const OptionDef options[] = {
 { "filter_hw_device", HAS_ARG | OPT_EXPERT, { .func_arg = 
opt_filter_hw_device },
 "set hardware device used when filtering", "device" },
 
+// deprecated options
+#if FFMPEG_OPT_MAP_CHANNEL
+{ "map_channel",HAS_ARG | OPT_EXPERT | OPT_PERFILE | OPT_OUTPUT, { 
.func_arg = opt_map_channel },
+"map an audio channel from one stream to another (deprecated)", 
"file.stream.channel[:syncfile.syncstream]" },
+#endif
+#if FFMPEG_OPT_ADRIFT_THRESHOLD
+{ "adrift_threshold", HAS_ARG | OPT_EXPERT,  { 
.func_arg = opt_adrift_threshold },
+"deprecated, does nothing", "threshold" },
+#endif
+#if FFMPEG_OPT_PSNR
+{ "psnr", OPT_VIDEO | OPT_BOOL | OPT_EXPERT,   
  { &do_psnr },
+"calculate PSNR of compressed frames (deprecated, use -flags +psnr)" },
+#endif
+#if FFMPEG_OPT_TOP
+{ "top",  OPT_VIDEO | OPT_EXPERT  | OPT_INT| OPT_SPEC |
+  OPT_INPUT | OPT_OUTPUT,  
  { .off = OFFSET(top_field_first) },
+"deprecated, use the setfield video filter", "" },
+#endif
+#if FFMPEG_OPT_QPHIST
+  

[FFmpeg-devel] [PATCH 01/20] fftools/ffmpeg_filter: only set framerate for video

2023-12-18 Thread Anton Khirnov
Otherwise an unitialized stack value would be copied to FPSConvContext.
As it's then never used, it tends not to be a problem in practice,
however it is UB and some compilers warn about it.
---
 fftools/ffmpeg_filter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 9fc877b437..e219594a4a 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -2017,9 +2017,9 @@ static int choose_out_timebase(OutputFilterPriv *ofp, 
AVFrame *frame)
 if (!(tb.num > 0 && tb.den > 0))
 tb = frame->time_base;
 
+fps->framerate = fr;
 finish:
 ofp->tb_out= tb;
-fps->framerate = fr;
 ofp->tb_out_locked = 1;
 
 return 0;
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 03/20] fftools/cmdutils: simplify handling of the HAS_ARG option flag

2023-12-18 Thread Anton Khirnov
This option flag only carries nontrivial information for options that
call a function, in all other cases its presence can be inferred from
the option type (bool options do not have arguments, all other types do)
and is thus nothing but useless clutter.

Change the option parsing code to infer its value when it can, and drop
the flag from options where it's not needed.
---
 fftools/cmdutils.c   |  19 --
 fftools/ffmpeg_opt.c | 158 +--
 fftools/ffplay.c |  44 ++--
 fftools/ffprobe.c|  12 ++--
 4 files changed, 122 insertions(+), 111 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 86cd3bddb4..f5b3dc7346 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -223,6 +223,17 @@ static inline void prepare_app_arguments(int *argc_ptr, 
char ***argv_ptr)
 }
 #endif /* HAVE_COMMANDLINETOARGVW */
 
+static int opt_has_arg(const OptionDef *o)
+{
+if (o->flags & OPT_BOOL)
+return 0;
+if (o->flags &
+(OPT_STRING | OPT_INT  | OPT_FLOAT  | OPT_INT64 |
+ OPT_SPEC   | OPT_TIME | OPT_DOUBLE))
+return 1;
+return !!(o->flags & HAS_ARG);
+}
+
 static int write_option(void *optctx, const OptionDef *po, const char *opt,
 const char *arg)
 {
@@ -331,7 +342,7 @@ int parse_option(void *optctx, const char *opt, const char 
*arg,
 av_log(NULL, AV_LOG_ERROR, "Unrecognized option '%s'\n", opt);
 return AVERROR(EINVAL);
 }
-if (po->flags & HAS_ARG && !arg) {
+if (opt_has_arg(po) && !arg) {
 av_log(NULL, AV_LOG_ERROR, "Missing argument for option '%s'\n", opt);
 return AVERROR(EINVAL);
 }
@@ -340,7 +351,7 @@ int parse_option(void *optctx, const char *opt, const char 
*arg,
 if (ret < 0)
 return ret;
 
-return !!(po->flags & HAS_ARG);
+return opt_has_arg(po);
 }
 
 int parse_options(void *optctx, int argc, char **argv, const OptionDef 
*options,
@@ -432,7 +443,7 @@ int locate_option(int argc, char **argv, const OptionDef 
*options,
  (po->name && !strcmp(optname, po->name)))
 return i;
 
-if (!po->name || po->flags & HAS_ARG)
+if (!po->name || opt_has_arg(po))
 i++;
 }
 return 0;
@@ -770,7 +781,7 @@ do {
   \
 if (po->flags & OPT_EXIT) {
 /* optional argument, e.g. -h */
 arg = argv[optindex++];
-} else if (po->flags & HAS_ARG) {
+} else if (opt_has_arg(po)) {
 GET_ARG(arg);
 } else {
 arg = "1";
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 295a393eba..aed20032a8 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1426,7 +1426,7 @@ static int opt_adrift_threshold(void *optctx, const char 
*opt, const char *arg)
 const OptionDef options[] = {
 /* main options */
 CMDUTILS_COMMON_OPTIONS
-{ "f",  HAS_ARG | OPT_STRING | OPT_OFFSET |
+{ "f",  OPT_STRING | OPT_OFFSET |
 OPT_INPUT | OPT_OUTPUT,  { .off
   = OFFSET(format) },
 "force format", "fmt" },
 { "y",  OPT_BOOL,{ 
 &file_overwrite },
@@ -1439,13 +1439,13 @@ const OptionDef options[] = {
 "Copy unknown stream types" },
 { "recast_media",   OPT_BOOL | OPT_EXPERT,   { 
 &recast_media },
 "allow recasting stream type in order to force a decoder of different 
media type" },
-{ "c",  HAS_ARG | OPT_STRING | OPT_SPEC |
+{ "c",  OPT_STRING | OPT_SPEC |
 OPT_INPUT | OPT_OUTPUT,  { .off
   = OFFSET(codec_names) },
 "codec name", "codec" },
-{ "codec",  HAS_ARG | OPT_STRING | OPT_SPEC |
+{ "codec",  OPT_STRING | OPT_SPEC |
 OPT_INPUT | OPT_OUTPUT,  { .off
   = OFFSET(codec_names) },
 "codec name", "codec" },
-{ "pre",HAS_ARG | OPT_STRING | OPT_SPEC |
+{ "pre",OPT_STRING | OPT_SPEC |
 OPT_OUTPUT,  { .off
   = OFFSET(presets) },
 "preset name", "preset" },
 { "map",HAS_ARG | OPT_EXPERT | OPT_PERFILE |
@@ -1456,47 +1456,47 @@ const OptionDef options[] = {
 { "map_channel",HAS_ARG | OPT_EXPERT | OPT_PERFILE | OPT_OUTPUT, { 
.func_arg = opt_map_channel },
 "map an audio channel from one stream to another (deprecated)", 
"file.stream.channel[:syncfile.syncstream]" },
 #endif
-{ "map_metadata",   HAS_ARG | OPT_STRING | OPT_SPEC |
+{ "map_metadata",   OPT_STRING | OPT_SPEC |
 OPT_OUTPUT,  { .off
   = OFFSET(metadata_map) },
 "set metadata 

[FFmpeg-devel] [PATCH 06/20] fftools/cmdutils: rename HAS_ARG to OPT_FUNC_ARG

2023-12-18 Thread Anton Khirnov
For consistent namespacing with other option flags. Also, document and
enforce that it can only be set for func-type options.
---
 fftools/cmdutils.c   |  8 +++-
 fftools/cmdutils.h   |  8 +++-
 fftools/ffmpeg_opt.c | 92 ++--
 fftools/ffplay.c | 14 +++
 fftools/ffprobe.c| 14 +++
 fftools/opt_common.h | 14 +++
 6 files changed, 80 insertions(+), 70 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 8ff69cabf5..38f4f542d3 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -228,7 +228,7 @@ static int opt_has_arg(const OptionDef *o)
 if (o->type == OPT_TYPE_BOOL)
 return 0;
 if (o->type == OPT_TYPE_FUNC)
-return !!(o->flags & HAS_ARG);
+return !!(o->flags & OPT_FUNC_ARG);
 return 1;
 }
 
@@ -323,7 +323,7 @@ int parse_option(void *optctx, const char *opt, const char 
*arg,
 static const OptionDef opt_avoptions = {
 .name   = "AVOption passthrough",
 .type   = OPT_TYPE_FUNC,
-.flags  = HAS_ARG,
+.flags  = OPT_FUNC_ARG,
 .u.func_arg = opt_default,
 };
 
@@ -481,6 +481,10 @@ static void check_options(const OptionDef *po)
 while (po->name) {
 if (po->flags & OPT_PERFILE)
 av_assert0(po->flags & (OPT_INPUT | OPT_OUTPUT));
+
+// OPT_FUNC_ARG can only be ser for OPT_TYPE_FUNC
+av_assert0((po->type == OPT_TYPE_FUNC) || !(po->flags & OPT_FUNC_ARG));
+
 po++;
 }
 }
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index b9ef8b5c15..d0242dc6ab 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -118,7 +118,13 @@ typedef struct OptionDef {
 const char *name;
 enum OptionType type;
 int flags;
-#define HAS_ARG (1 << 0)
+
+/* The OPT_TYPE_FUNC option takes an argument.
+ * Must not be used with other option types, as for those it holds:
+ * - OPT_TYPE_BOOL do not take an argument
+ * - all other types do
+ */
+#define OPT_FUNC_ARG(1 << 0)
 #define OPT_EXPERT  (1 << 2)
 #define OPT_VIDEO   (1 << 4)
 #define OPT_AUDIO   (1 << 5)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 752d5980b7..cf382759d8 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1453,7 +1453,7 @@ const OptionDef options[] = {
 { "pre",OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT,
 { .off   = OFFSET(presets) },
 "preset name", "preset" },
-{ "map",OPT_TYPE_FUNC, HAS_ARG | OPT_EXPERT | 
OPT_PERFILE | OPT_OUTPUT,
+{ "map",OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_EXPERT | 
OPT_PERFILE | OPT_OUTPUT,
 { .func_arg = opt_map },
 "set input stream mapping",
 
"[-]input_file_id[:stream_specifier][,sync_file_id[:stream_specifier]]" },
@@ -1495,7 +1495,7 @@ const OptionDef options[] = {
 { "itsscale",   OPT_TYPE_DOUBLE, OPT_SPEC | OPT_EXPERT | 
OPT_INPUT,
 { .off = OFFSET(ts_scale) },
 "set the input ts scale", "scale" },
-{ "timestamp",  OPT_TYPE_FUNC,   HAS_ARG | OPT_PERFILE | 
OPT_OUTPUT,
+{ "timestamp",  OPT_TYPE_FUNC,   OPT_FUNC_ARG | OPT_PERFILE | 
OPT_OUTPUT,
 { .func_arg = opt_recording_timestamp },
 "set the recording timestamp ('now' to set the current time)", "time" 
},
 { "metadata",   OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT,
@@ -1504,7 +1504,7 @@ const OptionDef options[] = {
 { "program",OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT,
 { .off = OFFSET(program) },
 "add program with specified streams", "title=string:st=number..." },
-{ "dframes",OPT_TYPE_FUNC, HAS_ARG | OPT_PERFILE | 
OPT_EXPERT | OPT_OUTPUT,
+{ "dframes",OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_PERFILE | 
OPT_EXPERT | OPT_OUTPUT,
 { .func_arg = opt_data_frames },
 "set the number of data frames to output", "number" },
 { "benchmark",  OPT_TYPE_BOOL, OPT_EXPERT,
@@ -1513,13 +1513,13 @@ const OptionDef options[] = {
 { "benchmark_all",  OPT_TYPE_BOOL, OPT_EXPERT,
 { &do_benchmark_all },
   "add timings for each task" },
-{ "progress",   OPT_TYPE_FUNC, HAS_ARG | OPT_EXPERT,
+{ "progress",   OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_EXPERT,
 { .func_arg = opt_progress },
   "write program-readable progress information", "url" },
 { "stdin",  OPT_TYPE_BOOL, OPT_EXPERT,
 { &stdin_interaction },
   "enable or disable interaction on standard input" },
-{ "timelimit",  OPT_TYPE_FUNC, HAS_ARG | OPT_EXPERT,
+{ "timelimit",  OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_EXPERT,
 { .func_arg = opt_timelimit },
 "set max runtime in seconds in CPU user time", "limit" },
 { "dump",   OPT_TYPE_BOOL, OPT_EXPERT,
@@ -1537,11 +1537,11 @@ const OptionDef options[] =

[FFmpeg-devel] [PATCH 05/20] fftools: split off option types from other flags

2023-12-18 Thread Anton Khirnov
These values are not actually flags, as only one of them can be
meaningfully set.
---
 fftools/cmdutils.c   |  51 ++--
 fftools/cmdutils.h   |  21 +-
 fftools/ffmpeg_opt.c | 557 +--
 fftools/ffplay.c | 102 
 fftools/ffprobe.c|  76 +++---
 fftools/opt_common.h |  62 ++---
 6 files changed, 488 insertions(+), 381 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index f5b3dc7346..8ff69cabf5 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -83,7 +83,7 @@ void init_dynload(void)
 #endif
 }
 
-int parse_number(const char *context, const char *numstr, int type,
+int parse_number(const char *context, const char *numstr, enum OptionType type,
  double min, double max, double *dst)
 {
 char *tail;
@@ -93,9 +93,9 @@ int parse_number(const char *context, const char *numstr, int 
type,
 error = "Expected number for %s but found: %s\n";
 else if (d < min || d > max)
 error = "The value for %s was %s which is not within %f - %f\n";
-else if (type == OPT_INT64 && (int64_t)d != d)
+else if (type == OPT_TYPE_INT64 && (int64_t)d != d)
 error = "Expected int64 for %s but found %s\n";
-else if (type == OPT_INT && (int)d != d)
+else if (type == OPT_TYPE_INT && (int)d != d)
 error = "Expected int for %s but found %s\n";
 else {
 *dst = d;
@@ -225,13 +225,11 @@ static inline void prepare_app_arguments(int *argc_ptr, 
char ***argv_ptr)
 
 static int opt_has_arg(const OptionDef *o)
 {
-if (o->flags & OPT_BOOL)
+if (o->type == OPT_TYPE_BOOL)
 return 0;
-if (o->flags &
-(OPT_STRING | OPT_INT  | OPT_FLOAT  | OPT_INT64 |
- OPT_SPEC   | OPT_TIME | OPT_DOUBLE))
-return 1;
-return !!(o->flags & HAS_ARG);
+if (o->type == OPT_TYPE_FUNC)
+return !!(o->flags & HAS_ARG);
+return 1;
 }
 
 static int write_option(void *optctx, const OptionDef *po, const char *opt,
@@ -262,46 +260,50 @@ static int write_option(void *optctx, const OptionDef 
*po, const char *opt,
 dst = &(*so)[*dstcount - 1].u;
 }
 
-if (po->flags & OPT_STRING) {
+if (po->type == OPT_TYPE_STRING) {
 char *str;
 str = av_strdup(arg);
 av_freep(dst);
 if (!str)
 return AVERROR(ENOMEM);
 *(char **)dst = str;
-} else if (po->flags & OPT_BOOL || po->flags & OPT_INT) {
-ret = parse_number(opt, arg, OPT_INT64, INT_MIN, INT_MAX, &num);
+} else if (po->type == OPT_TYPE_BOOL || po->type == OPT_TYPE_INT) {
+ret = parse_number(opt, arg, OPT_TYPE_INT64, INT_MIN, INT_MAX, &num);
 if (ret < 0)
 return ret;
 
 *(int *)dst = num;
-} else if (po->flags & OPT_INT64) {
-ret = parse_number(opt, arg, OPT_INT64, INT64_MIN, INT64_MAX, &num);
+} else if (po->type == OPT_TYPE_INT64) {
+ret = parse_number(opt, arg, OPT_TYPE_INT64, INT64_MIN, INT64_MAX, 
&num);
 if (ret < 0)
 return ret;
 
 *(int64_t *)dst = num;
-} else if (po->flags & OPT_TIME) {
+} else if (po->type == OPT_TYPE_TIME) {
 ret = av_parse_time(dst, arg, 1);
 if (ret < 0) {
 av_log(NULL, AV_LOG_ERROR, "Invalid duration for option %s: %s\n",
opt, arg);
 return ret;
 }
-} else if (po->flags & OPT_FLOAT) {
-ret = parse_number(opt, arg, OPT_FLOAT, -INFINITY, INFINITY, &num);
+} else if (po->type == OPT_TYPE_FLOAT) {
+ret = parse_number(opt, arg, OPT_TYPE_FLOAT, -INFINITY, INFINITY, 
&num);
 if (ret < 0)
 return ret;
 
 *(float *)dst = num;
-} else if (po->flags & OPT_DOUBLE) {
-ret = parse_number(opt, arg, OPT_DOUBLE, -INFINITY, INFINITY, &num);
+} else if (po->type == OPT_TYPE_DOUBLE) {
+ret = parse_number(opt, arg, OPT_TYPE_DOUBLE, -INFINITY, INFINITY, 
&num);
 if (ret < 0)
 return ret;
 
 *(double *)dst = num;
-} else if (po->u.func_arg) {
-int ret = po->u.func_arg(optctx, opt, arg);
+} else {
+int ret;
+
+av_assert0(po->type == OPT_TYPE_FUNC && po->u.func_arg);
+
+ret = po->u.func_arg(optctx, opt, arg);
 if (ret < 0) {
 av_log(NULL, AV_LOG_ERROR,
"Failed to set value '%s' for option '%s': %s\n",
@@ -320,6 +322,7 @@ int parse_option(void *optctx, const char *opt, const char 
*arg,
 {
 static const OptionDef opt_avoptions = {
 .name   = "AVOption passthrough",
+.type   = OPT_TYPE_FUNC,
 .flags  = HAS_ARG,
 .u.func_arg = opt_default,
 };
@@ -331,9 +334,9 @@ int parse_option(void *optctx, const char *opt, const char 
*arg,
 if (!po->name && opt[0] == 'n' && opt[1] == 'o') {
 /* handle 'no' bool option */
 po = find_option(options, opt + 2);
-if ((po->name && (po->flags & OPT_BOOL)))
+if ((po->name && po->

[FFmpeg-devel] [PATCH 12/20] fftools/ffmpeg: improve WARN_MULTIPLE_OPT_USAGE()

2023-12-18 Thread Anton Khirnov
Currently it requires every single OPT_SPEC option to be accompanied by
an array of alternate names for this option. The vast majority of
options have no alternate names, resulting in a large numbers of
unnecessary single-element arrays that merely contain the option name.

Extend the option parsing API to allow marking options as having
alternate names, or as being the canonical name for some existing
alternatives. Use this new information to avoid the need for
abovementioned unnecessary single-element arrays.
---
 fftools/cmdutils.c|  13 +--
 fftools/cmdutils.h|  21 -
 fftools/ffmpeg.h  |  29 +++
 fftools/ffmpeg_demux.c|  14 
 fftools/ffmpeg_mux_init.c |  41 --
 fftools/ffmpeg_opt.c  | 165 ++
 6 files changed, 139 insertions(+), 144 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 26e5e6e986..44228ea637 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -233,7 +233,7 @@ static int opt_has_arg(const OptionDef *o)
 }
 
 static int write_option(void *optctx, const OptionDef *po, const char *opt,
-const char *arg)
+const char *arg, const OptionDef *defs)
 {
 /* new-style options contain an offset into optctx, old-style address of
  * a global var*/
@@ -313,8 +313,11 @@ static int write_option(void *optctx, const OptionDef *po, 
const char *opt,
 if (po->flags & OPT_EXIT)
 return AVERROR_EXIT;
 
-if (sol)
+if (sol) {
 sol->type = po->type;
+sol->opt_canon = (po->flags & OPT_HAS_CANON) ?
+ find_option(defs, po->u1.name_canon) : po;
+}
 
 return 0;
 }
@@ -352,7 +355,7 @@ int parse_option(void *optctx, const char *opt, const char 
*arg,
 return AVERROR(EINVAL);
 }
 
-ret = write_option(optctx, po, opt, arg);
+ret = write_option(optctx, po, opt, arg, options);
 if (ret < 0)
 return ret;
 
@@ -395,7 +398,7 @@ int parse_options(void *optctx, int argc, char **argv, 
const OptionDef *options,
 return 0;
 }
 
-int parse_optgroup(void *optctx, OptionGroup *g)
+int parse_optgroup(void *optctx, OptionGroup *g, const OptionDef *defs)
 {
 int i, ret;
 
@@ -418,7 +421,7 @@ int parse_optgroup(void *optctx, OptionGroup *g)
 av_log(NULL, AV_LOG_DEBUG, "Applying option %s (%s) with argument 
%s.\n",
o->key, o->opt->help, o->val);
 
-ret = write_option(optctx, o->opt, o->key, o->val);
+ret = write_option(optctx, o->opt, o->key, o->val, defs);
 if (ret < 0)
 return ret;
 }
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index db91b788f8..53227abb47 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -118,6 +118,8 @@ typedef struct SpecifierOptList {
 SpecifierOpt*opt;
 int   nb_opt;
 
+/* Canonical option definition that was parsed into this list. */
+const struct OptionDef *opt_canon;
 enum OptionType type;
 } SpecifierOptList;
 
@@ -160,6 +162,14 @@ typedef struct OptionDef {
  * output, or both. */
 #define OPT_INPUT   (1 << 10)
 #define OPT_OUTPUT  (1 << 11)
+
+/* This option is a "canonical" form, to which one or more alternatives
+ * exist. These alternatives are listed in u1.names_alt. */
+#define OPT_HAS_ALT (1 << 12)
+/* This option is an alternative form of some other option, whose
+ * name is stored in u1.name_canon */
+#define OPT_HAS_CANON   (1 << 13)
+
  union {
 void *dst_ptr;
 int (*func_arg)(void *, const char *, const char *);
@@ -167,6 +177,15 @@ typedef struct OptionDef {
 } u;
 const char *help;
 const char *argname;
+
+union {
+/* Name of the canonical form of this option.
+ * Is valid when OPT_HAS_CANON is set. */
+const char *name_canon;
+/* A NULL-terminated list of alternate forms of this option.
+ * Is valid when OPT_HAS_ALT is set. */
+const char * const *names_alt;
+} u1;
 } OptionDef;
 
 /**
@@ -281,7 +300,7 @@ typedef struct OptionParseContext {
  *
  * @param optctx an app-specific options context. NULL for global options group
  */
-int parse_optgroup(void *optctx, OptionGroup *g);
+int parse_optgroup(void *optctx, OptionGroup *g, const OptionDef *defs);
 
 /**
  * Split the commandline into an intermediate form convenient for further
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 9905d16095..1a8254d422 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -775,43 +775,40 @@ void update_benchmark(const char *fmt, ...);
 #define SPECIFIER_OPT_FMT_f"%f"
 #define SPECIFIER_OPT_FMT_dbl  "%lf"
 
-#define WARN_MULTIPLE_OPT_USAGE(name, type, so, st)\
+#define WARN_MULTIPLE_OPT_USAGE(optname, type, idx, st)\
 {\
 char namestr[128] = "";\
+const SpecifierOpt *so = &o->optname.opt[idx];\
 const char *spec = so->specifier && so->specifier[0] ? so->specifier : "";\
-for (int _i = 0; opt_name_##n

[FFmpeg-devel] [PATCH 15/20] fftools/ffmpeg_opt: mark more options as OPT_EXPERT

2023-12-18 Thread Anton Khirnov
Reduces the basic help output to a reasonable size and stops confusing
users with options the vast majority will not need.
---
 fftools/ffmpeg_opt.c | 56 ++--
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index eee12df893..6656aa631c 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1445,7 +1445,7 @@ const OptionDef options[] = {
 { "n",  OPT_TYPE_BOOL, 0,
 {  &no_file_overwrite },
 "never overwrite output files" },
-{ "ignore_unknown", OPT_TYPE_BOOL, 0,
+{ "ignore_unknown", OPT_TYPE_BOOL, OPT_EXPERT,
 {  &ignore_unknown_streams },
 "Ignore unknown stream types" },
 { "copy_unknown",   OPT_TYPE_BOOL, OPT_EXPERT,
@@ -1458,11 +1458,11 @@ const OptionDef options[] = {
 { .off   = OFFSET(codec_names) },
 "codec name", "codec",
 .u1.name_canon = "codec", },
-{ "codec",  OPT_TYPE_STRING, OPT_SPEC | OPT_INPUT | 
OPT_OUTPUT | OPT_HAS_ALT,
+{ "codec",  OPT_TYPE_STRING, OPT_SPEC | OPT_INPUT | 
OPT_OUTPUT | OPT_EXPERT | OPT_HAS_ALT,
 { .off   = OFFSET(codec_names) },
 "codec name", "codec",
 .u1.names_alt = alt_codec, },
-{ "pre",OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT | 
OPT_HAS_ALT,
+{ "pre",OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT | 
OPT_EXPERT | OPT_HAS_ALT,
 { .off   = OFFSET(presets) },
 "preset name", "preset",
 .u1.names_alt = alt_pre, },
@@ -1470,7 +1470,7 @@ const OptionDef options[] = {
 { .func_arg = opt_map },
 "set input stream mapping",
 
"[-]input_file_id[:stream_specifier][,sync_file_id[:stream_specifier]]" },
-{ "map_metadata",   OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT,
+{ "map_metadata",   OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT | 
OPT_EXPERT,
 { .off   = OFFSET(metadata_map) },
 "set metadata information of outfile from infile",
 "outfile[,metadata]:infile[,metadata]" },
@@ -1484,16 +1484,16 @@ const OptionDef options[] = {
 { "to", OPT_TYPE_TIME, OPT_OFFSET | OPT_INPUT | 
OPT_OUTPUT,
 { .off = OFFSET(stop_time) },
 "record or transcode stop time", "time_stop" },
-{ "fs", OPT_TYPE_INT64, OPT_OFFSET | OPT_OUTPUT,
+{ "fs", OPT_TYPE_INT64, OPT_OFFSET | OPT_OUTPUT | 
OPT_EXPERT,
 { .off = OFFSET(limit_filesize) },
 "set the limit file size in bytes", "limit_size" },
 { "ss", OPT_TYPE_TIME, OPT_OFFSET | OPT_INPUT | 
OPT_OUTPUT,
 { .off = OFFSET(start_time) },
 "set the start time offset", "time_off" },
-{ "sseof",  OPT_TYPE_TIME, OPT_OFFSET | OPT_INPUT,
+{ "sseof",  OPT_TYPE_TIME, OPT_OFFSET | OPT_INPUT | 
OPT_EXPERT,
 { .off = OFFSET(start_time_eof) },
 "set the start time offset relative to EOF", "time_off" },
-{ "seek_timestamp", OPT_TYPE_INT, OPT_OFFSET | OPT_INPUT,
+{ "seek_timestamp", OPT_TYPE_INT, OPT_OFFSET | OPT_INPUT | 
OPT_EXPERT,
 { .off = OFFSET(seek_timestamp) },
 "enable/disable seeking by timestamp with -ss" },
 { "accurate_seek",  OPT_TYPE_BOOL, OPT_OFFSET | OPT_EXPERT | 
OPT_INPUT,
@@ -1508,13 +1508,13 @@ const OptionDef options[] = {
 { "itsscale",   OPT_TYPE_DOUBLE, OPT_SPEC | OPT_EXPERT | 
OPT_INPUT,
 { .off = OFFSET(ts_scale) },
 "set the input ts scale", "scale" },
-{ "timestamp",  OPT_TYPE_FUNC,   OPT_FUNC_ARG | OPT_PERFILE | 
OPT_OUTPUT,
+{ "timestamp",  OPT_TYPE_FUNC,   OPT_FUNC_ARG | OPT_PERFILE | 
OPT_EXPERT | OPT_OUTPUT,
 { .func_arg = opt_recording_timestamp },
 "set the recording timestamp ('now' to set the current time)", "time" 
},
 { "metadata",   OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT,
 { .off = OFFSET(metadata) },
 "add metadata", "string=string" },
-{ "program",OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT,
+{ "program",OPT_TYPE_STRING, OPT_SPEC | OPT_EXPERT | 
OPT_OUTPUT,
 { .off = OFFSET(program) },
 "add program with specified streams", "title=string:st=number..." },
 { "dframes",OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_PERFILE | 
OPT_EXPERT | OPT_OUTPUT | OPT_HAS_CANON,
@@ -1551,7 +1551,7 @@ const OptionDef options[] = {
 { "readrate_initial_burst", OPT_TYPE_DOUBLE, OPT_OFFSET | OPT_EXPERT | 
OPT_INPUT,
 { .off = OFFSET(readrate_initial_burst) },
 "The initial amount of input to burst read before imposing any 
readrate", "seconds" },
-{ "target", OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_PERFILE | 
OPT_OUTPUT,
+{ "target", OP

[FFmpeg-devel] [PATCH 17/20] fftools/ffmpeg_opt: print a section for data-stream options

2023-12-18 Thread Anton Khirnov
Only show it with show_advanced (triggered by -h long), since data
streams themselves are an advanced topic.
---
 fftools/ffmpeg_opt.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index c8fb9d03e4..87357e8b64 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1239,6 +1239,10 @@ void show_help_default(const char *opt, const char *arg)
 if (show_advanced)
 show_help_options(options, "Advanced Subtitle options:",
   OPT_EXPERT | OPT_SUBTITLE, OPT_VIDEO | OPT_AUDIO | 
OPT_DATA, 0);
+
+if (show_advanced)
+show_help_options(options, "Data stream options:",
+  OPT_DATA, OPT_VIDEO | OPT_AUDIO | OPT_SUBTITLE, 0);
 printf("\n");
 
 if (show_avoptions) {
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 16/20] fftools/ffmpeg_opt: refine printing type-specific options

2023-12-18 Thread Anton Khirnov
* filter subtitle/data options out of main, video and audio sections
* add filters that were missing entirely from the subtitle section
* add a missing section for advanced subtitle options
---
 fftools/ffmpeg_opt.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 6656aa631c..c8fb9d03e4 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1216,25 +1216,29 @@ void show_help_default(const char *opt, const char *arg)
   OPT_PERFILE | OPT_EXIT, 0);
 
 show_help_options(options, "Per-file main options:", 0,
-  OPT_EXPERT | OPT_AUDIO | OPT_VIDEO | OPT_SUBTITLE |
+  OPT_EXPERT | OPT_AUDIO | OPT_VIDEO | OPT_SUBTITLE | 
OPT_DATA |
   OPT_EXIT, OPT_PERFILE);
 if (show_advanced)
 show_help_options(options, "Advanced per-file options:",
   OPT_EXPERT, OPT_AUDIO | OPT_VIDEO | OPT_SUBTITLE, 
OPT_PERFILE);
 
 show_help_options(options, "Video options:",
-  OPT_VIDEO, OPT_EXPERT | OPT_AUDIO, 0);
+  OPT_VIDEO, OPT_EXPERT | OPT_AUDIO | OPT_SUBTITLE | 
OPT_DATA, 0);
 if (show_advanced)
 show_help_options(options, "Advanced Video options:",
-  OPT_EXPERT | OPT_VIDEO, OPT_AUDIO, 0);
+  OPT_EXPERT | OPT_VIDEO, OPT_AUDIO | OPT_SUBTITLE | 
OPT_DATA, 0);
 
 show_help_options(options, "Audio options:",
-  OPT_AUDIO, OPT_EXPERT | OPT_VIDEO, 0);
+  OPT_AUDIO, OPT_EXPERT | OPT_VIDEO | OPT_SUBTITLE | 
OPT_DATA, 0);
 if (show_advanced)
 show_help_options(options, "Advanced Audio options:",
-  OPT_EXPERT | OPT_AUDIO, OPT_VIDEO, 0);
+  OPT_EXPERT | OPT_AUDIO, OPT_VIDEO | OPT_SUBTITLE | 
OPT_DATA, 0);
+
 show_help_options(options, "Subtitle options:",
-  OPT_SUBTITLE, 0, 0);
+  OPT_SUBTITLE, OPT_EXPERT | OPT_VIDEO | OPT_AUDIO | 
OPT_DATA, 0);
+if (show_advanced)
+show_help_options(options, "Advanced Subtitle options:",
+  OPT_EXPERT | OPT_SUBTITLE, OPT_VIDEO | OPT_AUDIO | 
OPT_DATA, 0);
 printf("\n");
 
 if (show_avoptions) {
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 20/20] fftools/ffmpeg: remove deprecated -[av]bsf

2023-12-18 Thread Anton Khirnov
They were marked as deprecated over 10 years ago.
---
 doc/ffmpeg.texi  |  4 
 fftools/ffmpeg_opt.c | 13 ++---
 2 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6ecd5f3cfe..bbe70a4f85 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1054,8 +1054,6 @@ Specify which version of the vstats format to use. 
Default is @code{2}. See the
 
 @item -vtag @var{fourcc/tag} (@emph{output})
 Force video tag/fourcc. This is an alias for @code{-tag:v}.
-@item -vbsf @var{bitstream_filter}
-Deprecated see -bsf
 
 @item -force_key_frames[:@var{stream_specifier}] @var{time}[,@var{time}...] 
(@emph{output,per-stream})
 @item -force_key_frames[:@var{stream_specifier}] expr:@var{expr} 
(@emph{output,per-stream})
@@ -1424,8 +1422,6 @@ This is an alias for @code{-filter:a}, see the 
@ref{filter_option,,-filter optio
 @table @option
 @item -atag @var{fourcc/tag} (@emph{output})
 Force audio tag/fourcc. This is an alias for @code{-tag:a}.
-@item -absf @var{bitstream_filter}
-Deprecated, see -bsf
 @item -guess_layout_max @var{channels} (@emph{input,per-stream})
 If some input channel layout is not known, try to guess only if it
 corresponds to at most the specified number of channels. For example, 2
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 2984c494cd..b7d636f16f 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1917,18 +1917,9 @@ const OptionDef options[] = {
 "0 = use frame rate (video) or sample rate (audio),"
 "-1 = match source time base", "ratio" },
 
-{ "bsf", OPT_TYPE_STRING, OPT_SPEC | OPT_EXPERT | OPT_OUTPUT | OPT_HAS_ALT,
+{ "bsf", OPT_TYPE_STRING, OPT_SPEC | OPT_EXPERT | OPT_OUTPUT,
 { .off = OFFSET(bitstream_filters) },
-"A comma-separated list of bitstream filters", "bitstream_filters",
-.u1.names_alt = alt_bsf, },
-{ "absf", OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_AUDIO | OPT_EXPERT| 
OPT_PERFILE | OPT_OUTPUT | OPT_HAS_CANON,
-{ .func_arg = opt_old2new },
-"deprecated", "audio bitstream_filters",
-.u1.name_canon = "bsf", },
-{ "vbsf", OPT_TYPE_FUNC, OPT_VIDEO | OPT_FUNC_ARG | OPT_EXPERT| 
OPT_PERFILE | OPT_OUTPUT | OPT_HAS_CANON,
-{ .func_arg = opt_old2new },
-"deprecated", "video bitstream_filters",
-.u1.name_canon = "bsf", },
+"A comma-separated list of bitstream filters", "bitstream_filters", },
 
 { "apre", OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_AUDIO | OPT_EXPERT| 
OPT_PERFILE | OPT_OUTPUT | OPT_HAS_CANON,
 { .func_arg = opt_preset },
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 02/20] fftools/ffmpeg_opt: drop HAS_ARG from auto{scale, rotate}

2023-12-18 Thread Anton Khirnov
It causes those options to be parsed as either
* -autofoo 0/1 (with an argument)
* -noautofoo   (without an argument)
This is unnecessary, confusing, and against the documentation; these are
also the only two bool options that take an argument.

This should not affect the users, as these options are on by default,
and are supposed to be used as -nofoo per the documentation.
---
 fftools/ffmpeg_opt.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 96d3c56fd7..295a393eba 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1741,11 +1741,9 @@ const OptionDef options[] = {
 "select output format used with HW accelerated decoding", "format" },
 { "hwaccels", OPT_EXIT,
  { .func_arg = show_hwaccels },
 "show available HW acceleration methods" },
-{ "autorotate",   HAS_ARG | OPT_BOOL | OPT_SPEC |
-  OPT_EXPERT | OPT_INPUT,  
  { .off = OFFSET(autorotate) },
+{ "autorotate",   OPT_BOOL | OPT_SPEC | OPT_EXPERT | OPT_INPUT,
  { .off = OFFSET(autorotate) },
 "automatically insert correct rotate filters" },
-{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
-  OPT_EXPERT | OPT_OUTPUT, 
  { .off = OFFSET(autoscale) },
+{ "autoscale",OPT_BOOL | OPT_SPEC | OPT_EXPERT | OPT_OUTPUT,   
  { .off = OFFSET(autoscale) },
 "automatically insert a scale filter at the end of the filter graph" },
 { "fix_sub_duration_heartbeat", OPT_VIDEO | OPT_BOOL | OPT_EXPERT |
 OPT_SPEC | OPT_OUTPUT, 
  { .off = OFFSET(fix_sub_duration_heartbeat) },
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 19/20] fftools/ffmpeg: mark -vsync for future removal

2023-12-18 Thread Anton Khirnov
It has already been deprecated over a year ago.
---
 fftools/ffmpeg.h  |  1 +
 fftools/ffmpeg_mux_init.c |  4 
 fftools/ffmpeg_opt.c  | 15 ---
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 1a8254d422..7d55e384d3 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -61,6 +61,7 @@
 #define FFMPEG_OPT_TOP 1
 #define FFMPEG_OPT_FORCE_KF_SOURCE_NO_DROP 1
 #define FFMPEG_OPT_VSYNC_DROP 1
+#define FFMPEG_OPT_VSYNC 1
 
 #define FFMPEG_ERROR_RATE_EXCEEDED FFERRTAG('E', 'R', 'E', 'D')
 
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 5ab3f14a01..f5e92de8a9 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -755,7 +755,11 @@ static int new_stream_video(Muxer *mux, const 
OptionsContext *o,
 av_log(ost, AV_LOG_WARNING, "-top is deprecated, use the setfield 
filter instead\n");
 #endif
 
+#if FFMPEG_OPT_VSYNC
 ost->vsync_method = video_sync_method;
+#else
+ost->vsync_method = VSYNC_AUTO;
+#endif
 MATCH_PER_STREAM_OPT(fps_mode, str, fps_mode, oc, st);
 if (fps_mode) {
 ret = parse_and_set_vsync(fps_mode, &ost->vsync_method, 
ost->file->index, ost->index, 0);
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index d6de997af8..2984c494cd 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -62,7 +62,9 @@ float audio_drift_threshold = 0.1;
 float dts_delta_threshold   = 10;
 float dts_error_threshold   = 3600*30;
 
+#if FFMPEG_OPT_VSYNC
 enum VideoSyncMethod video_sync_method = VSYNC_AUTO;
+#endif
 float frame_drop_threshold = 0;
 int do_benchmark  = 0;
 int do_benchmark_all  = 0;
@@ -205,6 +207,7 @@ int parse_and_set_vsync(const char *arg, int *vsync_var, 
int file_idx, int st_id
 return AVERROR(EINVAL);
 }
 
+#if FFMPEG_OPT_VSYNC
 if (is_global && *vsync_var == VSYNC_AUTO) {
 int ret;
 double num;
@@ -217,6 +220,8 @@ int parse_and_set_vsync(const char *arg, int *vsync_var, 
int file_idx, int st_id
 av_log(NULL, AV_LOG_WARNING, "Passing a number to -vsync is 
deprecated,"
" use a string argument as described in the manual.\n");
 }
+#endif
+
 return 0;
 }
 
@@ -1136,11 +1141,13 @@ static int opt_audio_filters(void *optctx, const char 
*opt, const char *arg)
 return parse_option(o, "filter:a", arg, options);
 }
 
+#if FFMPEG_OPT_VSYNC
 static int opt_vsync(void *optctx, const char *opt, const char *arg)
 {
 av_log(NULL, AV_LOG_WARNING, "-vsync is deprecated. Use -fps_mode\n");
 return parse_and_set_vsync(arg, &video_sync_method, -1, -1, 1);
 }
+#endif
 
 static int opt_timecode(void *optctx, const char *opt, const char *arg)
 {
@@ -1563,9 +1570,6 @@ const OptionDef options[] = {
 { .func_arg = opt_target },
 "specify target file type (\"vcd\", \"svcd\", \"dvd\", \"dv\" or 
\"dv50\" "
 "with optional prefixes \"pal-\", \"ntsc-\" or \"film-\")", "type" },
-{ "vsync",  OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_EXPERT,
-{ .func_arg = opt_vsync },
-"set video sync method globally; deprecated, use -fps_mode", "" },
 { "frame_drop_threshold",   OPT_TYPE_FLOAT, OPT_EXPERT,
 { &frame_drop_threshold },
 "frame drop threshold", "" },
@@ -2003,6 +2007,11 @@ const OptionDef options[] = {
 { .func_arg = opt_qphist },
 "deprecated, does nothing" },
 #endif
+#if FFMPEG_OPT_VSYNC
+{ "vsync",  OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_EXPERT,
+{ .func_arg = opt_vsync },
+"set video sync method globally; deprecated, use -fps_mode", "" },
+#endif
 
 { NULL, },
 };
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 07/20] fftools/cmdutils: renumber option flags sequentially

2023-12-18 Thread Anton Khirnov
Also, document them.
---
 fftools/cmdutils.h | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index d0242dc6ab..8e22560fc6 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -125,23 +125,31 @@ typedef struct OptionDef {
  * - all other types do
  */
 #define OPT_FUNC_ARG(1 << 0)
+/* Program will immediately exit after processing this option */
+#define OPT_EXIT(1 << 1)
+/* Option is intended for advanced users. Only affects
+ * help output.
+ */
 #define OPT_EXPERT  (1 << 2)
-#define OPT_VIDEO   (1 << 4)
-#define OPT_AUDIO   (1 << 5)
-#define OPT_SUBTITLE(1 << 8)
-#define OPT_EXIT(1 << 10)
-#define OPT_DATA(1 << 11)
-/* The option is per-file (currently ffmpeg-only).
-   implied by OPT_OFFSET or OPT_SPEC */
-#define OPT_PERFILE (1 << 12)
+#define OPT_VIDEO   (1 << 3)
+#define OPT_AUDIO   (1 << 4)
+#define OPT_SUBTITLE(1 << 5)
+#define OPT_DATA(1 << 6)
+/* The option is per-file (currently ffmpeg-only). Implied by OPT_OFFSET or
+ * OPT_SPEC. At least one of OPT_INPUT or OPT_OUTPUT must be set when this flag
+ * is in use.
+   */
+#define OPT_PERFILE (1 << 7)
 /* Option is specified as an offset in a passed optctx */
-#define OPT_OFFSET  (1 << 13)
+#define OPT_OFFSET  (1 << 8)
 /* Option is to be stored in an array of SpecifierOpt. Implies OPT_OFFSET.
Next element after the offset is an int containing element count in the
array. */
-#define OPT_SPEC(1 << 14)
-#define OPT_INPUT   (1 << 17)
-#define OPT_OUTPUT  (1 << 18)
+#define OPT_SPEC(1 << 9)
+/* ffmpeg-only - specifies whether an OPT_PERFILE option applies to input,
+ * output, or both. */
+#define OPT_INPUT   (1 << 10)
+#define OPT_OUTPUT  (1 << 11)
  union {
 void *dst_ptr;
 int (*func_arg)(void *, const char *, const char *);
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 10/20] fftools/cmdutils: add a struct for a list of SpecifierOpt

2023-12-18 Thread Anton Khirnov
Significantly simplifies the code dealing with OPT_SPEC.
---
 fftools/cmdutils.c|  10 +-
 fftools/cmdutils.h|   9 +-
 fftools/ffmpeg.h  | 197 +-
 fftools/ffmpeg_demux.c|  30 +++---
 fftools/ffmpeg_mux_init.c |  32 +++
 fftools/ffmpeg_opt.c  |  13 ++-
 6 files changed, 115 insertions(+), 176 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index a52c7c5ae4..f53c4b7aec 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -239,25 +239,23 @@ static int write_option(void *optctx, const OptionDef 
*po, const char *opt,
  * a global var*/
 void *dst = po->flags & OPT_FLAG_OFFSET ?
 (uint8_t *)optctx + po->u.off : po->u.dst_ptr;
-int *dstcount;
 double num;
 int ret;
 
 if (po->flags & OPT_FLAG_SPEC) {
-SpecifierOpt **so = dst;
+SpecifierOptList *sol = dst;
 char *p = strchr(opt, ':');
 char *str;
 
-dstcount = (int *)(so + 1);
-ret = grow_array((void**)so, sizeof(**so), dstcount, *dstcount + 1);
+ret = GROW_ARRAY(sol->opt, sol->nb_opt);
 if (ret < 0)
 return ret;
 
 str = av_strdup(p ? p + 1 : "");
 if (!str)
 return AVERROR(ENOMEM);
-(*so)[*dstcount - 1].specifier = str;
-dst = &(*so)[*dstcount - 1].u;
+sol->opt[sol->nb_opt - 1].specifier = str;
+dst = &sol->opt[sol->nb_opt - 1].u;
 }
 
 if (po->type == OPT_TYPE_STRING) {
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index dc99573d80..8ef9a07e9e 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -114,6 +114,11 @@ typedef struct SpecifierOpt {
 } u;
 } SpecifierOpt;
 
+typedef struct SpecifierOptList {
+SpecifierOpt*opt;
+int   nb_opt;
+} SpecifierOptList;
+
 typedef struct OptionDef {
 const char *name;
 enum OptionType type;
@@ -145,9 +150,7 @@ typedef struct OptionDef {
 #define OPT_FLAG_OFFSET (1 << 8)
 #define OPT_OFFSET  (OPT_FLAG_OFFSET | OPT_PERFILE)
 
-/* Option is to be stored in an array of SpecifierOpt.
-   Next element after the offset is an int containing element count in the
-   array.
+/* Option is to be stored in a SpecifierOptList.
Always use as OPT_SPEC in option definitions. */
 #define OPT_FLAG_SPEC   (1 << 9)
 #define OPT_SPEC(OPT_FLAG_SPEC | OPT_OFFSET)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 33a29b316f..94f70f7efb 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -138,22 +138,14 @@ typedef struct OptionsContext {
 int seek_timestamp;
 const char *format;
 
-SpecifierOpt *codec_names;
-intnb_codec_names;
-SpecifierOpt *audio_ch_layouts;
-intnb_audio_ch_layouts;
-SpecifierOpt *audio_channels;
-intnb_audio_channels;
-SpecifierOpt *audio_sample_rate;
-intnb_audio_sample_rate;
-SpecifierOpt *frame_rates;
-intnb_frame_rates;
-SpecifierOpt *max_frame_rates;
-intnb_max_frame_rates;
-SpecifierOpt *frame_sizes;
-intnb_frame_sizes;
-SpecifierOpt *frame_pix_fmts;
-intnb_frame_pix_fmts;
+SpecifierOptList codec_names;
+SpecifierOptList audio_ch_layouts;
+SpecifierOptList audio_channels;
+SpecifierOptList audio_sample_rate;
+SpecifierOptList frame_rates;
+SpecifierOptList max_frame_rates;
+SpecifierOptList frame_sizes;
+SpecifierOptList frame_pix_fmts;
 
 /* input options */
 int64_t input_ts_offset;
@@ -166,18 +158,12 @@ typedef struct OptionsContext {
 int input_sync_ref;
 int find_stream_info;
 
-SpecifierOpt *ts_scale;
-intnb_ts_scale;
-SpecifierOpt *dump_attachment;
-intnb_dump_attachment;
-SpecifierOpt *hwaccels;
-intnb_hwaccels;
-SpecifierOpt *hwaccel_devices;
-intnb_hwaccel_devices;
-SpecifierOpt *hwaccel_output_formats;
-intnb_hwaccel_output_formats;
-SpecifierOpt *autorotate;
-intnb_autorotate;
+SpecifierOptList ts_scale;
+SpecifierOptList dump_attachment;
+SpecifierOptList hwaccels;
+SpecifierOptList hwaccel_devices;
+SpecifierOptList hwaccel_output_formats;
+SpecifierOptList autorotate;
 
 /* output options */
 StreamMap *stream_maps;
@@ -208,102 +194,55 @@ typedef struct OptionsContext {
 // keys are stream indices
 AVDictionary *streamid;
 
-SpecifierOpt *metadata;
-intnb_metadata;
-SpecifierOpt *max_frames;
-intnb_max_frames;
-SpecifierOpt *bitstream_filters;
-intnb_bitstream_filters;
-SpecifierOpt *codec_tags;
-intnb_codec_tags;
-SpecifierOpt *sample_fmts;
-intnb_sample_fmts;
-SpecifierOpt *qscale;
-intnb_qscale;
-SpecifierOpt *forced_key_frames;
-intnb_forced_key_frames;
-SpecifierOpt *fps_mode;
-intnb_fps_mode;
-SpecifierOpt *force_fp

[FFmpeg-devel] [PATCH 09/20] fftools/cmdutils: check valid flags for OPT_TYPE_FUNC

2023-12-18 Thread Anton Khirnov
SPEC and OFFSET do not make sense for functions.
---
 fftools/cmdutils.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 6ca2efef4a..a52c7c5ae4 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -482,6 +482,9 @@ static void check_options(const OptionDef *po)
 if (po->flags & OPT_PERFILE)
 av_assert0(po->flags & (OPT_INPUT | OPT_OUTPUT));
 
+if (po->type == OPT_TYPE_FUNC)
+av_assert0(!(po->flags & (OPT_FLAG_OFFSET | OPT_FLAG_SPEC)));
+
 // OPT_FUNC_ARG can only be ser for OPT_TYPE_FUNC
 av_assert0((po->type == OPT_TYPE_FUNC) || !(po->flags & OPT_FUNC_ARG));
 
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 11/20] fftools/ffmpeg: change the MATCH_PER_TYPE_OPT macro into a function

2023-12-18 Thread Anton Khirnov
There is no reason for it to be a macro anymore, this makes the code
using it cleaner and simpler.
---
 fftools/cmdutils.c|  6 +-
 fftools/cmdutils.h|  2 ++
 fftools/ffmpeg.h  | 11 ++-
 fftools/ffmpeg_demux.c| 16 
 fftools/ffmpeg_mux_init.c |  4 ++--
 fftools/ffmpeg_opt.c  | 17 ++---
 6 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index f53c4b7aec..26e5e6e986 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -239,14 +239,15 @@ static int write_option(void *optctx, const OptionDef 
*po, const char *opt,
  * a global var*/
 void *dst = po->flags & OPT_FLAG_OFFSET ?
 (uint8_t *)optctx + po->u.off : po->u.dst_ptr;
+SpecifierOptList *sol = NULL;
 double num;
 int ret;
 
 if (po->flags & OPT_FLAG_SPEC) {
-SpecifierOptList *sol = dst;
 char *p = strchr(opt, ':');
 char *str;
 
+sol = dst;
 ret = GROW_ARRAY(sol->opt, sol->nb_opt);
 if (ret < 0)
 return ret;
@@ -312,6 +313,9 @@ static int write_option(void *optctx, const OptionDef *po, 
const char *opt,
 if (po->flags & OPT_EXIT)
 return AVERROR_EXIT;
 
+if (sol)
+sol->type = po->type;
+
 return 0;
 }
 
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index 8ef9a07e9e..db91b788f8 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -117,6 +117,8 @@ typedef struct SpecifierOpt {
 typedef struct SpecifierOptList {
 SpecifierOpt*opt;
 int   nb_opt;
+
+enum OptionType type;
 } SpecifierOptList;
 
 typedef struct OptionDef {
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 94f70f7efb..9905d16095 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -802,15 +802,8 @@ void update_benchmark(const char *fmt, ...);
WARN_MULTIPLE_OPT_USAGE(name, type, so, st);\
 }
 
-#define MATCH_PER_TYPE_OPT(name, type, outvar, fmtctx, mediatype)\
-{\
-int i;\
-for (i = 0; i < o->name.nb_opt; i++) {\
-char *spec = o->name.opt[i].specifier;\
-if (!strcmp(spec, mediatype))\
-outvar = o->name.opt[i].u.type;\
-}\
-}
+const char *opt_match_per_type_str(const SpecifierOptList *sol,
+   char mediatype);
 
 extern const char * const opt_name_codec_names[];
 extern const char * const opt_name_codec_tags[];
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 6672113bca..5594286a79 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -1334,10 +1334,10 @@ int ifile_open(const OptionsContext *o, const char 
*filename, Scheduler *sch)
 int64_t timestamp;
 AVDictionary *unused_opts = NULL;
 const AVDictionaryEntry *e = NULL;
-char *   video_codec_name = NULL;
-char *   audio_codec_name = NULL;
-char *subtitle_codec_name = NULL;
-char *data_codec_name = NULL;
+const char*video_codec_name = NULL;
+const char*audio_codec_name = NULL;
+const char* subtitle_codec_name = NULL;
+const char* data_codec_name = NULL;
 int scan_all_pmts_set = 0;
 
 int64_t start_time = o->start_time;
@@ -1427,10 +1427,10 @@ int ifile_open(const OptionsContext *o, const char 
*filename, Scheduler *sch)
 if (o->frame_pix_fmts.nb_opt)
 av_dict_set(&o->g->format_opts, "pixel_format", 
o->frame_pix_fmts.opt[o->frame_pix_fmts.nb_opt - 1].u.str, 0);
 
-MATCH_PER_TYPE_OPT(codec_names, str,video_codec_name, ic, "v");
-MATCH_PER_TYPE_OPT(codec_names, str,audio_codec_name, ic, "a");
-MATCH_PER_TYPE_OPT(codec_names, str, subtitle_codec_name, ic, "s");
-MATCH_PER_TYPE_OPT(codec_names, str, data_codec_name, ic, "d");
+video_codec_name= opt_match_per_type_str(&o->codec_names, 'v');
+audio_codec_name= opt_match_per_type_str(&o->codec_names, 'a');
+subtitle_codec_name = opt_match_per_type_str(&o->codec_names, 's');
+data_codec_name = opt_match_per_type_str(&o->codec_names, 'd');
 
 if (video_codec_name)
 ret = err_merge(ret, find_codec(NULL, video_codec_name   , 
AVMEDIA_TYPE_VIDEO   , 0,
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 6e6e8b8b6a..6dbee50d1c 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -1611,10 +1611,10 @@ static int map_auto_audio(Muxer *mux, const 
OptionsContext *o)
 static int map_auto_subtitle(Muxer *mux, const OptionsContext *o)
 {
 AVFormatContext *oc = mux->fc;
-char *subtitle_codec_name = NULL;
+const char *subtitle_codec_name = NULL;
 
 /* subtitles: pick first */
-MATCH_PER_TYPE_OPT(codec_names, str, subtitle_codec_name, oc, "s");
+subtitle_codec_name = opt_match_per_type_str(&o->codec_names, 's');
 if (!avcodec_find_encoder(oc->oformat->subtitle_codec) && 
!subtitle_codec_name)
 return 0;
 
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 653f62770e..56

[FFmpeg-devel] [PATCH 13/20] fftools/ffmpeg_opt: update program description to match manpage

2023-12-18 Thread Anton Khirnov
Cf. 2244722f1f3
---
 fftools/ffmpeg_opt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 8b2c30e2e6..eee12df893 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1254,7 +1254,7 @@ void show_help_default(const char *opt, const char *arg)
 
 void show_usage(void)
 {
-av_log(NULL, AV_LOG_INFO, "Hyper fast Audio and Video encoder\n");
+av_log(NULL, AV_LOG_INFO, "Universal media converter\n");
 av_log(NULL, AV_LOG_INFO, "usage: %s [options] [[infile options] -i 
infile]... {[outfile options] outfile}...\n", program_name);
 av_log(NULL, AV_LOG_INFO, "\n");
 }
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 14/20] fftools/opt_common: mark some options as OPT_EXPERT

2023-12-18 Thread Anton Khirnov
So they don't clutter the standard help output.

-loglevel is marked because there is no need to show two options (-v and
-loglevel) that do the same thing.
---
 fftools/opt_common.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fftools/opt_common.h b/fftools/opt_common.h
index e82ada5581..36c591cc94 100644
--- a/fftools/opt_common.h
+++ b/fftools/opt_common.h
@@ -219,10 +219,10 @@ int opt_cpucount(void *optctx, const char *opt, const 
char *arg);
 { "sample_fmts",  OPT_TYPE_FUNC, OPT_EXIT,  { .func_arg = 
show_sample_fmts }, "show available audio sample formats" },   \
 { "dispositions", OPT_TYPE_FUNC, OPT_EXIT,  { .func_arg = 
show_dispositions}, "show available stream dispositions" },\
 { "colors",   OPT_TYPE_FUNC, OPT_EXIT,  { .func_arg = 
show_colors },  "show available color names" },\
-{ "loglevel", OPT_TYPE_FUNC, OPT_FUNC_ARG,  { .func_arg = 
opt_loglevel }, "set logging level", "loglevel" }, \
+{ "loglevel", OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_EXPERT, { .func_arg = 
opt_loglevel }, "set logging level", "loglevel" }, \
 { "v",OPT_TYPE_FUNC, OPT_FUNC_ARG,  { .func_arg = 
opt_loglevel }, "set logging level", "loglevel" }, \
-{ "report",   OPT_TYPE_FUNC, 0, { .func_arg = 
opt_report },   "generate a report" }, \
-{ "max_alloc",OPT_TYPE_FUNC, OPT_FUNC_ARG,  { .func_arg = 
opt_max_alloc },"set maximum size of a single allocated block", "bytes" }, \
+{ "report",   OPT_TYPE_FUNC, OPT_EXPERT,{ .func_arg = 
opt_report },   "generate a report" }, \
+{ "max_alloc",OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_EXPERT, { .func_arg = 
opt_max_alloc },"set maximum size of a single allocated block", "bytes" }, \
 { "cpuflags", OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_EXPERT, { .func_arg = 
opt_cpuflags }, "force specific cpu flags", "flags" }, \
 { "cpucount", OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_EXPERT, { .func_arg = 
opt_cpucount }, "force specific cpu count", "count" }, \
 { "hide_banner",  OPT_TYPE_BOOL, OPT_EXPERT,{&hide_banner},
   "do not show program banner", "hide_banner" }, \
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 08/20] fftools/cmdutils: include OPT_PERFILE in OPT_OFFSET

2023-12-18 Thread Anton Khirnov
And analogously OPT_OFFSET in OPT_SPEC. Previously the inclusion would
be implicit and required all code to remember this.
---
 fftools/cmdutils.c   |  6 +++---
 fftools/cmdutils.h   | 21 +
 fftools/ffmpeg_opt.c | 14 ++
 3 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 38f4f542d3..6ca2efef4a 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -237,13 +237,13 @@ static int write_option(void *optctx, const OptionDef 
*po, const char *opt,
 {
 /* new-style options contain an offset into optctx, old-style address of
  * a global var*/
-void *dst = po->flags & (OPT_OFFSET | OPT_SPEC) ?
+void *dst = po->flags & OPT_FLAG_OFFSET ?
 (uint8_t *)optctx + po->u.off : po->u.dst_ptr;
 int *dstcount;
 double num;
 int ret;
 
-if (po->flags & OPT_SPEC) {
+if (po->flags & OPT_FLAG_SPEC) {
 SpecifierOpt **so = dst;
 char *p = strchr(opt, ':');
 char *str;
@@ -660,7 +660,7 @@ static int finish_group(OptionParseContext *octx, int 
group_idx,
 static int add_opt(OptionParseContext *octx, const OptionDef *opt,
const char *key, const char *val)
 {
-int global = !(opt->flags & (OPT_PERFILE | OPT_SPEC | OPT_OFFSET));
+int global = !(opt->flags & OPT_PERFILE);
 OptionGroup *g = global ? &octx->global_opts : &octx->cur_group;
 int ret;
 
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index 8e22560fc6..dc99573d80 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -135,17 +135,22 @@ typedef struct OptionDef {
 #define OPT_AUDIO   (1 << 4)
 #define OPT_SUBTITLE(1 << 5)
 #define OPT_DATA(1 << 6)
-/* The option is per-file (currently ffmpeg-only). Implied by OPT_OFFSET or
- * OPT_SPEC. At least one of OPT_INPUT or OPT_OUTPUT must be set when this flag
- * is in use.
+/* The option is per-file (currently ffmpeg-only). At least one of OPT_INPUT or
+ * OPT_OUTPUT must be set when this flag is in use.
*/
 #define OPT_PERFILE (1 << 7)
-/* Option is specified as an offset in a passed optctx */
-#define OPT_OFFSET  (1 << 8)
-/* Option is to be stored in an array of SpecifierOpt. Implies OPT_OFFSET.
+
+/* Option is specified as an offset in a passed optctx.
+ * Always use as OPT_OFFSET in option definitions. */
+#define OPT_FLAG_OFFSET (1 << 8)
+#define OPT_OFFSET  (OPT_FLAG_OFFSET | OPT_PERFILE)
+
+/* Option is to be stored in an array of SpecifierOpt.
Next element after the offset is an int containing element count in the
-   array. */
-#define OPT_SPEC(1 << 9)
+   array.
+   Always use as OPT_SPEC in option definitions. */
+#define OPT_FLAG_SPEC   (1 << 9)
+#define OPT_SPEC(OPT_FLAG_SPEC | OPT_OFFSET)
 /* ffmpeg-only - specifies whether an OPT_PERFILE option applies to input,
  * output, or both. */
 #define OPT_INPUT   (1 << 10)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index cf382759d8..6f997a803a 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -109,7 +109,7 @@ static void uninit_options(OptionsContext *o)
 while (po->name) {
 void *dst = (uint8_t*)o + po->u.off;
 
-if (po->flags & OPT_SPEC) {
+if (po->flags & OPT_FLAG_SPEC) {
 SpecifierOpt **so = dst;
 int i, *count = (int*)(so + 1);
 for (i = 0; i < *count; i++) {
@@ -119,7 +119,7 @@ static void uninit_options(OptionsContext *o)
 }
 av_freep(so);
 *count = 0;
-} else if (po->flags & OPT_OFFSET && po->type == OPT_TYPE_STRING)
+} else if (po->flags & OPT_FLAG_OFFSET && po->type == OPT_TYPE_STRING)
 av_freep(dst);
 po++;
 }
@@ -1181,8 +1181,6 @@ static int opt_filter_complex_script(void *optctx, const 
char *opt, const char *
 
 void show_help_default(const char *opt, const char *arg)
 {
-/* per-file options have at least one of those set */
-const int per_file = OPT_SPEC | OPT_OFFSET | OPT_PERFILE;
 int show_advanced = 0, show_avoptions = 0;
 
 if (opt && *opt) {
@@ -1209,17 +1207,17 @@ void show_help_default(const char *opt, const char *arg)
 
 show_help_options(options, "Global options (affect whole program "
   "instead of just one file):",
-  0, per_file | OPT_EXIT | OPT_EXPERT, 0);
+  0, OPT_PERFILE | OPT_EXIT | OPT_EXPERT, 0);
 if (show_advanced)
 show_help_options(options, "Advanced global options:", OPT_EXPERT,
-  per_file | OPT_EXIT, 0);
+  OPT_PERFILE | OPT_EXIT, 0);
 
 show_help_options(options, "Per-file main options:", 0,
   OPT_EXPERT | OPT_AUDIO | OPT_VIDEO | OPT_SUBTITLE |
-  OPT_EXIT, per_file);
+  OPT_EXIT, OPT_PERFILE);
 if (show_advanced)
 show_help_options(options, "Advanced per-file options:",
-   

[FFmpeg-devel] [PATCH 18/20] fftools/ffmpeg_opt: fix -dn flags

2023-12-18 Thread Anton Khirnov
It's a data, not video option.
---
 fftools/ffmpeg_opt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 87357e8b64..d6de997af8 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1955,7 +1955,7 @@ const OptionDef options[] = {
 { .func_arg = opt_data_codec },
 "force data codec ('copy' to copy stream)", "codec",
 .u1.name_canon = "codec", },
-{ "dn", OPT_TYPE_BOOL, OPT_VIDEO | OPT_OFFSET | OPT_INPUT | OPT_OUTPUT,
+{ "dn", OPT_TYPE_BOOL, OPT_DATA | OPT_OFFSET | OPT_INPUT | OPT_OUTPUT,
 { .off = OFFSET(data_disable) }, "disable data" },
 
 #if CONFIG_VAAPI
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v3] swr/swresample: avoid reapplication of firstpts

2023-12-18 Thread Gyan Doshi




On 2023-12-18 09:31 am, Gyan Doshi wrote:



On 2023-12-16 03:44 pm, Gyan Doshi wrote:

During a resampling operation where

1) user has specified first_pts
2) SWR_FLAG_RESAMPLE is not set initially (directly or otherwise)
3) first_pts has been fulfilled (always using hard compensation)

then upon first encountering a delay where a soft compensation is
required, swr_set_compensation will lead to another init of swr which
will reset outpts to the specified firstpts thus leading to an output
frame having its pts = firstpts. When the next input frame is received,
swr will see a large delay and inject silence from firstpts to the
current frame's pts. This can lead to severe desync and in worst case,
loss of audio playback.

Parameter firstpts initialized to AV_NOPTS_VALUE in swr_alloc and then
checked in swr_init to avoid resetting outpts, thus avoiding 
reapplication

of firstpts.

Fixes #4131.
---
Added fate test


Plan to push soon.


Pushed as be8a4f80b97222d99b4262c9230ca8a1db28973a

Regards,
Gyan

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v3 1/2] avfilter: Add fsync filter

2023-12-18 Thread Thilo Borgmann via ffmpeg-devel

Am 17.12.23 um 23:51 schrieb Michael Niedermayer:

On Sat, Dec 16, 2023 at 09:13:21AM +0100, Thilo Borgmann via ffmpeg-devel wrote:
[...]


+// get number of bytes from cur to '\0'
+static int buf_get_zero(FsyncContext *ctx)


maybe doxygen syntax would make sense for comments descrining functions
its not public api but still maybe


Better still. Done.



+{
+return av_strnlen(ctx->cur, ctx->end - ctx->cur);
+}
+

[...]

+if (s->last_frame) {
+ret = av_sscanf(s->cur, "%"PRId64" %"PRId64" %d/%d", &s->ptsi, &s->pts, 
&s->tb_num, &s->tb_den);
+if (ret != 4) {
+av_log(ctx, AV_LOG_ERROR, "Unexpected format found (%i / 4).\n", 
ret);
+ff_outlink_set_status(outlink, AVERROR_INVALIDDATA, 
AV_NOPTS_VALUE);
+return AVERROR_INVALIDDATA;
+}
+
+av_log(ctx, AV_LOG_DEBUG, "frame %lli ", s->last_frame->pts);


warning: format ‘%lli’ expects argument of type ‘long long int’, but argument 4 
has type ‘int64_t {aka long int}’ [-Wformat=]

"%"PRIi64 / "%"PRId64 / "%"PRIu64 / "%"PRIx64


"%"PRId64 it shall be here and for the other DEBUG logs.

All done locally, I'd appreciate if someone could test this on Windows, I'm 
curious about line endings in the map file...

Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v3 1/2] avfilter: Add fsync filter

2023-12-18 Thread Thilo Borgmann via ffmpeg-devel

Am 18.12.23 um 02:04 schrieb Stefano Sabatini:

On date Saturday 2023-12-16 09:13:21 +0100, ffmpeg-devel Mailing List wrote:

---
  Changelog|   1 +
  MAINTAINERS  |   1 +
  configure|   2 +
  doc/filters.texi |  33 +
  libavfilter/Makefile |   1 +
  libavfilter/allfilters.c |   1 +
  libavfilter/version.h|   2 +-
  libavfilter/vf_fsync.c   | 286 +++
  8 files changed, 326 insertions(+), 1 deletion(-)
  create mode 100644 libavfilter/vf_fsync.c

[...]
@@ -14681,6 +14681,39 @@ option may cause flicker since the B-Frames have often 
larger QP. Default is
  
  @end table
  
+@anchor{fsync}

+@section fsync
+
+Synchronize video frames with an external mapping from a file.
+
+For each input PTS given in the map file it either drops or creates as many 
frames as necessary to recreate the sequence of output frames given in the map 
file.
+
+This filter is useful to recreate the output frames of a framerate conversion 
by the @ref{fps} filter, recorded into a map file using the ffmpeg option 
@code{-stats_mux_pre}, and do further processing to the corresponding frames 
e.g. quality comparison.


wrap around 80 chars, here and below


All wrapped locally, except in the examples where it would mangle the HTML 
output.

Thanks,
Thilo

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/8] avutil: introduce an Immersive Audio Model and Formats API

2023-12-18 Thread Anton Khirnov
Quoting James Almer (2023-12-14 21:14:26)
> +/**
> + * Mix Gain Parameter Data as defined in section 3.8.1 of IAMF.
> + */
> +typedef struct AVIAMFMixGain {
> +const AVClass *av_class;
> +
> +/**
> + * Duration for the given subblock. It must not be 0.

In what units? Same for all durations in this patch.

> +typedef struct AVIAMFParamDefinition {
> +const AVClass *av_class;
> +
> +/**
> + * Offset in bytes from the start of this struct, at which the subblocks
> + * array is located.
> + */
> +size_t subblocks_offset;
> +/**
> + * Size in bytes of each element in the subblocks array.
> + */
> +size_t subblock_size;
> +/**
> + * Number of subblocks in the array.
> + *
> + * Must be 0 if @ref constant_subblock_duration is not 0.
> + */
> +unsigned int nb_subblocks;
> +
> +/**
> + * Parameters type. Determines the type of the subblock elements.
> + */
> +enum AVIAMFParamDefinitionType type;
> +
> +/**
> + * Identifier for the paremeter substream.
> + */
> +unsigned int parameter_id;
> +/**
> + * Sample rate for the paremeter substream. It must not be 0.
> + */
> +unsigned int parameter_rate;
> +
> +/**
> + * The duration of the all subblocks in this parameter definition.
> + *
> + * May be 0, in which case all duration values should be specified in
> + * another parameter definition referencing the same parameter_id.
> + */
> +unsigned int duration;
> +/**
> + * The duration of every subblock in the case where all subblocks, with
> + * the optional exception of the last subblock, have equal durations.
> + *
> + * Must be 0 if subblocks have different durations.
> + */
> +unsigned int constant_subblock_duration;

This also seems like should be a flags field.

Otherwise looks good.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v1] avcodec/cbs_vp8: Apply clang-format and fix typos.

2023-12-18 Thread Dai, Jianhui J


> -Original Message-
> From: ffmpeg-devel  On Behalf Of Dai,
> Jianhui J
> Sent: Monday, December 18, 2023 3:59 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v1] avcodec/cbs_vp8: Apply clang-format and
> fix typos.
> 
> This commit applies clang-format to the source and fixes typos.
> 
> TETS: ffmpeg -i fate-suite/vp8-test-vectors-r1/* -vcodec copy -bsf:v
> trace_headers -f null -
> 
> Signed-off-by: Jianhui Dai 
> ---
>  libavcodec/cbs_vp8.c | 54 ++--
>  1 file changed, 37 insertions(+), 17 deletions(-)
> 
> diff --git a/libavcodec/cbs_vp8.c b/libavcodec/cbs_vp8.c index
> 01d4b9cefe..5e6468d1b4 100644
> --- a/libavcodec/cbs_vp8.c
> +++ b/libavcodec/cbs_vp8.c
> @@ -33,22 +33,22 @@ extern const uint8_t
> ff_vp8_token_update_probs[4][8][3][11];
>  typedef struct CBSVP8BoolDecoder {
>  GetBitContext *gbc;
> 
> -uint8_t value;
>  uint8_t range;
> 
> -uint8_t count; // Store the number of bits in the `value` buffer.
> -
> +uint8_t value;
> +// Store the number of bits in the `value` buffer.
> +uint8_t count;
>  } CBSVP8BoolDecoder;
> 
> -static int cbs_vp8_bool_decoder_init(CBSVP8BoolDecoder *decoder,
> GetBitContext *gbc)
> +static int cbs_vp8_bool_decoder_init(CBSVP8BoolDecoder *decoder,
> + GetBitContext *gbc)
>  {
>  av_assert0(decoder);
>  av_assert0(gbc);
> 
>  decoder->gbc = gbc;
> -decoder->value = 0;
>  decoder->range = 255;
> -
> +decoder->value = 0;
>  decoder->count = 0;
> 
>  return 0;
> @@ -60,7 +60,7 @@ static bool
> cbs_vp8_bool_decoder_fill_value(CBSVP8BoolDecoder *decoder)
> 
>  av_assert0(decoder->count <= 8);
>  if (decoder->count == 8) {
> -  return true;
> +return true;
>  }
> 
>  if (get_bits_left(decoder->gbc) >= bits) { @@ -141,7 +141,7 @@ static int
> cbs_vp8_bool_decoder_read_unsigned(
>  }
> 
>  if (trace_enable) {
> -  CBS_TRACE_READ_END();
> +CBS_TRACE_READ_END();
>  }
> 
>  *write_to = value;
> @@ -181,9 +181,11 @@ static int cbs_vp8_bool_decoder_read_signed(
>  return 0;
>  }
> 
> -static int cbs_vp8_read_unsigned_le(CodedBitstreamContext *ctx,
> GetBitContext *gbc,
> - int width, const char *name,
> - const int *subscripts, uint32_t *write_to)
> +static int cbs_vp8_read_unsigned_le(CodedBitstreamContext *ctx,
> +GetBitContext *gbc, int width,
> +const char *name, const int *subscripts,
> +uint32_t *write_to, uint32_t range_min,
> +uint32_t range_max)
>  {
>  int32_t value;
> 
> @@ -200,6 +202,14 @@ static int
> cbs_vp8_read_unsigned_le(CodedBitstreamContext *ctx, GetBitContext *g
> 
>  CBS_TRACE_READ_END();
> 
> +if (value < range_min || value > range_max) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR,
> +   "%s out of range: "
> +   "%" PRIu32 ", but must be in [%" PRIu32 ",%" PRIu32 "].\n",
> +   name, value, range_min, range_max);
> +return AVERROR_INVALIDDATA;
> +}
> +
>  *write_to = value;
>  return 0;
>  }
> @@ -246,15 +256,16 @@ static int
> cbs_vp8_read_unsigned_le(CodedBitstreamContext *ctx, GetBitContext *g
>  do { \
>  uint32_t value; \
>  CHECK(cbs_vp8_read_unsigned_le(ctx, rw, width, #name, \
> -SUBSCRIPTS(subs, __VA_ARGS__), &value)); 
> \
> +   SUBSCRIPTS(subs, __VA_ARGS__), 
> &value, \
> +   0, MAX_UINT_BITS(width))); \
>  current->name = value; \
>  } while (0)
> 
>  #define fixed(width, name, value) \
>  do { \
>  uint32_t fixed_value; \
> -CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, 0, &fixed_value, \
> -   value, value)); \
> +CHECK(cbs_vp8_read_unsigned_le(ctx, rw, width, #name, 0,
> &fixed_value, \
> +   value, value)); \
>  } while (0)
> 
>  #define bc_unsigned_subs(width, prob, enable_trace, name, subs, ...) \ @@ -
> 277,6 +288,15 @@ static int
> cbs_vp8_read_unsigned_le(CodedBitstreamContext *ctx, GetBitContext *g
> 
>  #include "cbs_vp8_syntax_template.c"
> 
> +#undef READ
> +#undef READWRITE
> +#undef RWContext
> +#undef CBSVP8BoolCodingRW
> +#undef xf
> +#undef fixed
> +#undef bc_unsigned_subs
> +#undef bc_signed_subs
> +
>  static int cbs_vp8_split_fragment(CodedBitstreamContext *ctx,
>CodedBitstreamFragment *frag, int header)  
> { @@ -307,7
> +327,7 @@ static int cbs_vp8_read_unit(CodedBitstreamContext *ctx,
>  frame = unit->content;
> 
>  // Create GetBitContext for uncompressed header.
> -err = init_get_bits8_le(&gbc, unit->data, 8 * unit->data_size);
> +err =

Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg_filter: fix null pointer dereference

2023-12-18 Thread Anton Khirnov
Quoting Zhao Zhili (2023-12-17 12:01:08)
> From: Zhao Zhili 
> 
> A dummy frame is created with format NONE passed to enc_open(),
> which doesn't prepare for it. The null pointer dereference happened
> at av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth.
> 
> frame #0: 0x00bc34a4 ffmpeg_g`enc_open(opaque=0xb47efe2db690, 
> frame=0xb47efe2d9f70) at ffmpeg_enc.c:235:44
> frame #1: 0x00bef250 ffmpeg_g`enc_open(sch=0xb47dde2d4090, 
> enc=0xb47e4e2daad0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:1462:11
> frame #2: 0x00bee094 ffmpeg_g`send_to_enc(sch=0xb47dde2d4090, 
> enc=0xb47e4e2daad0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:1571:19
> frame #3: 0x00bee01c ffmpeg_g`sch_filter_send(sch=0xb47dde2d4090, 
> fg_idx=0, out_idx=0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:2154:12
> frame #4: 0x00bcf124 ffmpeg_g`close_output(ofp=0xb47e4e2d85b0, 
> fgt=0x007d1790eb08) at ffmpeg_filter.c:2225:15
> frame #5: 0x00bcb000 ffmpeg_g`fg_output_frame(ofp=0xb47e4e2d85b0, 
> fgt=0x007d1790eb08, frame=0x) at ffmpeg_filter.c:2317:16
> frame #6: 0x00bc7e48 ffmpeg_g`filter_thread(arg=0xb47eae2ce7a0) 
> at ffmpeg_filter.c:2836:15
> frame #7: 0x00bee568 ffmpeg_g`task_wrapper(arg=0xb47d8e2db478) at 
> ffmpeg_sched.c:2200:21
> 
> Signed-off-by: Zhao Zhili 
> ---
> This bug is trigged by 10bit H.264 which doesn't supported by mediacodec.
> There is some misleading error messages from ffmpeg cli:
> 
> [h264_mediacodec @ 0xb47513788010] Failed to dequeue output buffer 
> (status=-1)
> [vist#0:0/h264 @ 0xb474a3786b30] Error submitting packet to decoder: 
> Generic error in an external library
> [h264_mediacodec @ 0xb47513788010] Failed to dequeue output buffer 
> (status=-1)
> [vist#0:0/h264 @ 0xb474a3786b30] Error submitting packet to decoder: 
> Generic error in an external library
> [vist#0:0/h264 @ 0xb474a3786b30] A decoder returned an unexpected error 
> code. This is a bug, please report it.
> [vist#0:0/h264 @ 0xb474a3786b30] Error processing packet in decoder: 
> Internal bug, should not have happened
> 
>  fftools/ffmpeg_filter.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index bb755d7bb4..9dc47f9d90 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -2192,7 +2192,7 @@ static int close_output(OutputFilterPriv *ofp, 
> FilterGraphThread *fgt)
>  
>  // we are finished and no frames were ever seen at this output,
>  // at least initialize the encoder with a dummy frame
> -if (!fgt->got_frame) {
> +if (!fgt->got_frame && ofp->format != -1) {

I don't quite understand how precisely does this happen.

This code should only be reachable if the filtergraph was configured at
least once, then configure_filtergraph() should set ofp->format to the
format reported by the lavfi buffersink. Does this then mean that lavfi
is configured with AV_PIX_FMT_NONE? Or that this is somehow triggered
without the filtergraph being configured?

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 2/2] fftools/ffmpeg_enc: assert frame->format isn't NONE before use

2023-12-18 Thread Anton Khirnov
Quoting Zhao Zhili (2023-12-17 12:01:09)
> From: Zhao Zhili 
> 
> Signed-off-by: Zhao Zhili 
> ---
>  fftools/ffmpeg_enc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
> index 9141dab6a4..ac38e8db75 100644
> --- a/fftools/ffmpeg_enc.c
> +++ b/fftools/ffmpeg_enc.c
> @@ -206,6 +206,7 @@ int enc_open(void *opaque, const AVFrame *frame)
>  
>  switch (enc_ctx->codec_type) {
>  case AVMEDIA_TYPE_AUDIO:
> +av_assert0(frame->format != AV_SAMPLE_FMT_NONE);
>  enc_ctx->sample_fmt = frame->format;
>  enc_ctx->sample_rate= frame->sample_rate;
>  ret = av_channel_layout_copy(&enc_ctx->ch_layout, &frame->ch_layout);
> @@ -227,6 +228,7 @@ int enc_open(void *opaque, const AVFrame *frame)
>  av_mul_q(ost->frame_aspect_ratio, (AVRational){ enc_ctx->height, 
> enc_ctx->width }) :
>  frame->sample_aspect_ratio;
>  
> +av_assert0(frame->format != AV_PIX_FMT_NONE);

I'd prefer if you did this at the top of the block, right after case.
Can also check dimensions for video and sample rate/channel layout for
audio.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] avformat/file: seek back to initial position for fd protocol

2023-12-18 Thread Anton Khirnov
Quoting Zhao Zhili (2023-12-18 17:42:39)
> From: Zhao Zhili 
> 
> So user's fd can be passed to libavformat multiple times in sequence
> without changing the position.
> 
> Signed-off-by: Zhao Zhili 
> ---
>  libavformat/file.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)

Looks ok.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] avcodec/cbs_vp8: fix GetBitContext setup

2023-12-18 Thread Dai, Jianhui J



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Michael
> Niedermayer
> Sent: Sunday, December 17, 2023 9:19 PM
> To: FFmpeg development discussions and patches 
> Subject: [FFmpeg-devel] [PATCH] avcodec/cbs_vp8: fix GetBitContext setup
> 
> Fixes: abort()
> Fixes: 64232/clusterfuzz-testcase-minimized-
> ffmpeg_BSF_TRACE_HEADERS_fuzzer-5417957987319808
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-
> fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/cbs_vp8.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/cbs_vp8.c b/libavcodec/cbs_vp8.c index
> 01d4b9cefef..065156c2485 100644
> --- a/libavcodec/cbs_vp8.c
> +++ b/libavcodec/cbs_vp8.c
> @@ -307,7 +307,7 @@ static int cbs_vp8_read_unit(CodedBitstreamContext
> *ctx,
>  frame = unit->content;
> 
>  // Create GetBitContext for uncompressed header.
> -err = init_get_bits8_le(&gbc, unit->data, 8 * unit->data_size);
> +err = init_get_bits8_le(&gbc, unit->data, unit->data_size);
>  if (err < 0)
>  return err;
> 

My bad. Thank for fixing it.

> --
> 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 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 v7 06/11] avformat: add demuxer and probe support for H266/VVC

2023-12-18 Thread Zhao Zhili


> On Mar 21, 2023, at 23:01, Thomas Siedel  wrote:
> 
> Add demuxer to probe raw vvc and parse vvcc byte stream format.
> 
> Co-authored-by: Nuo Mi 
> ---
> 


> +
> +static int h266_probe(const AVProbeData *p)
> +{
> +uint32_t code = -1;
> +int sps = 0, pps = 0, irap = 0;
> +int i;
> +
> +for (i = 0; i < p->buf_size - 1; i++) {
> +code = (code << 8) + p->buf[i];
> +if ((code & 0xff00) == 0x100) {
> +uint8_t nal2 = p->buf[i + 1];
> +int type = (nal2 & 0xF8) >> 3;
> +
> +if (code & 0x80) // forbidden_zero_bit
> +return 0;
> +
> +if ((nal2 & 0x7) == 0) // nuh_temporal_id_plus1
> +return 0;
> +
> +switch (type) {
> +case VVC_SPS_NUT:   sps++;  break;
> +case VVC_PPS_NUT:   pps++;  break;
> +case VVC_IDR_N_LP:
> +case VVC_IDR_W_RADL:
> +case VVC_CRA_NUT:
> +case VVC_GDR_NUT:   irap++; break;
> +}
> +}
> +}
> +
> +if (sps && pps && irap)
> +return AVPROBE_SCORE_EXTENSION + 1; // 1 more than .mpg

The probe isn’t reliable enough. It mistreated an TS as vvc,

https://trac.ffmpeg.org/ticket/10731#comment:1

Any idea to reduce false positive?

> +return 0;
> +}
> +
> +FF_DEF_RAWVIDEO_DEMUXER(h266, "raw H.266/VVC video", h266_probe, 
> "h266,266,vvc", AV_CODEC_ID_VVC)
> -- 
> 2.25.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 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/4] avcodec/cbs_vp8: Do not use assert to check for end

2023-12-18 Thread Dai, Jianhui J



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Michael
> Niedermayer
> Sent: Saturday, December 16, 2023 8:16 PM
> To: FFmpeg development discussions and patches 
> Subject: [FFmpeg-devel] [PATCH 2/4] avcodec/cbs_vp8: Do not use assert to
> check for end
> 
> Fixes: abort()
> Fixes: 64232/clusterfuzz-testcase-minimized-
> ffmpeg_BSF_TRACE_HEADERS_fuzzer-5417957987319808
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-
> fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/cbs_vp8.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/cbs_vp8.c b/libavcodec/cbs_vp8.c index
> 01d4b9cefef..b76cde98517 100644
> --- a/libavcodec/cbs_vp8.c
> +++ b/libavcodec/cbs_vp8.c
> @@ -329,7 +329,9 @@ static int cbs_vp8_read_unit(CodedBitstreamContext
> *ctx,
> 
>  pos = get_bits_count(&gbc);
>  pos /= 8;
> -av_assert0(pos <= unit->data_size);
> +
> +if (pos > unit->data_size)
> +return AVERROR_INVALIDDATA;
> 

This is a potentially fatal error caused by the parser overreading past the 
expected data. This should not occur after the fix GetBitContext setup patch 
was applied.
BTW, the VP8 compressed header does not guarantee 8-bit alignment according to 
the SPEC.
It could be better to check the bit pos.

```
pos = get_bits_count(&gbc);
av_assert0(pos <= unit->data_size * 8);
```

>  frame->data_ref = av_buffer_ref(unit->data_ref);
>  if (!frame->data_ref)
> --
> 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 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] fftools/ffmpeg_filter: fix null pointer dereference

2023-12-18 Thread Zhao Zhili


> On Dec 18, 2023, at 19:19, Anton Khirnov  wrote:
> 
> Quoting Zhao Zhili (2023-12-17 12:01:08)
>> From: Zhao Zhili 
>> 
>> A dummy frame is created with format NONE passed to enc_open(),
>> which doesn't prepare for it. The null pointer dereference happened
>> at av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth.
>> 
>> frame #0: 0x00bc34a4 ffmpeg_g`enc_open(opaque=0xb47efe2db690, 
>> frame=0xb47efe2d9f70) at ffmpeg_enc.c:235:44
>> frame #1: 0x00bef250 ffmpeg_g`enc_open(sch=0xb47dde2d4090, 
>> enc=0xb47e4e2daad0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:1462:11
>> frame #2: 0x00bee094 ffmpeg_g`send_to_enc(sch=0xb47dde2d4090, 
>> enc=0xb47e4e2daad0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:1571:19
>> frame #3: 0x00bee01c 
>> ffmpeg_g`sch_filter_send(sch=0xb47dde2d4090, fg_idx=0, out_idx=0, 
>> frame=0xb47efe2d9f70) at ffmpeg_sched.c:2154:12
>> frame #4: 0x00bcf124 ffmpeg_g`close_output(ofp=0xb47e4e2d85b0, 
>> fgt=0x007d1790eb08) at ffmpeg_filter.c:2225:15
>> frame #5: 0x00bcb000 
>> ffmpeg_g`fg_output_frame(ofp=0xb47e4e2d85b0, fgt=0x007d1790eb08, 
>> frame=0x) at ffmpeg_filter.c:2317:16
>> frame #6: 0x00bc7e48 ffmpeg_g`filter_thread(arg=0xb47eae2ce7a0) 
>> at ffmpeg_filter.c:2836:15
>> frame #7: 0x00bee568 ffmpeg_g`task_wrapper(arg=0xb47d8e2db478) 
>> at ffmpeg_sched.c:2200:21
>> 
>> Signed-off-by: Zhao Zhili 
>> ---
>> This bug is trigged by 10bit H.264 which doesn't supported by mediacodec.
>> There is some misleading error messages from ffmpeg cli:
>> 
>> [h264_mediacodec @ 0xb47513788010] Failed to dequeue output buffer 
>> (status=-1)
>> [vist#0:0/h264 @ 0xb474a3786b30] Error submitting packet to decoder: 
>> Generic error in an external library
>> [h264_mediacodec @ 0xb47513788010] Failed to dequeue output buffer 
>> (status=-1)
>> [vist#0:0/h264 @ 0xb474a3786b30] Error submitting packet to decoder: 
>> Generic error in an external library
>> [vist#0:0/h264 @ 0xb474a3786b30] A decoder returned an unexpected error 
>> code. This is a bug, please report it.
>> [vist#0:0/h264 @ 0xb474a3786b30] Error processing packet in decoder: 
>> Internal bug, should not have happened
>> 
>> fftools/ffmpeg_filter.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
>> index bb755d7bb4..9dc47f9d90 100644
>> --- a/fftools/ffmpeg_filter.c
>> +++ b/fftools/ffmpeg_filter.c
>> @@ -2192,7 +2192,7 @@ static int close_output(OutputFilterPriv *ofp, 
>> FilterGraphThread *fgt)
>> 
>> // we are finished and no frames were ever seen at this output,
>> // at least initialize the encoder with a dummy frame
>> -if (!fgt->got_frame) {
>> +if (!fgt->got_frame && ofp->format != -1) {
> 
> I don't quite understand how precisely does this happen.
> 
> This code should only be reachable if the filtergraph was configured at
> least once, then configure_filtergraph() should set ofp->format to the
> format reported by the lavfi buffersink. Does this then mean that lavfi
> is configured with AV_PIX_FMT_NONE? Or that this is somehow triggered
> without the filtergraph being configured?


Can reproduced with:

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 559f63698a..af4ea37812 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -1050,6 +1050,7 @@ static int qsv_decode_frame(AVCodecContext *avctx, 
AVFrame *frame,
 QSVDecContext *s = avctx->priv_data;
 int ret;
 
+return AVERROR_EXTERNAL;
 /* buffer the input packet */
 if (avpkt->size) {
 AVPacket input_ref;

Then
./ffmpeg -c:v h264_qsv -xerror  -I input.mp4 -c:a copy  -c:v libx264  
output.mp4 

Looks like filtergraph isn’t being configured.

> 
> -- 
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org  with 
> subject "unsubscribe".

___
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 v7 06/11] avformat: add demuxer and probe support for H266/VVC

2023-12-18 Thread Nuo Mi
On Mon, Dec 18, 2023 at 7:43 PM Zhao Zhili  wrote:

>
>
> > On Mar 21, 2023, at 23:01, Thomas Siedel 
> wrote:
> >
> > Add demuxer to probe raw vvc and parse vvcc byte stream format.
> >
> > Co-authored-by: Nuo Mi 
> > ---
> >
>
>
> > +
> > +static int h266_probe(const AVProbeData *p)
> > +{
> > +uint32_t code = -1;
> > +int sps = 0, pps = 0, irap = 0;
> > +int i;
> > +
> > +for (i = 0; i < p->buf_size - 1; i++) {
> > +code = (code << 8) + p->buf[i];
> > +if ((code & 0xff00) == 0x100) {
> > +uint8_t nal2 = p->buf[i + 1];
> > +int type = (nal2 & 0xF8) >> 3;
> > +
> > +if (code & 0x80) // forbidden_zero_bit
> > +return 0;
> > +
> > +if ((nal2 & 0x7) == 0) // nuh_temporal_id_plus1
> > +return 0;
> > +
> > +switch (type) {
> > +case VVC_SPS_NUT:   sps++;  break;
> > +case VVC_PPS_NUT:   pps++;  break;
> > +case VVC_IDR_N_LP:
> > +case VVC_IDR_W_RADL:
> > +case VVC_CRA_NUT:
> > +case VVC_GDR_NUT:   irap++; break;
> > +}
> > +}
> > +}
> > +
> > +if (sps && pps && irap)
> > +return AVPROBE_SCORE_EXTENSION + 1; // 1 more than .mpg
>
> The probe isn’t reliable enough. It mistreated an TS as vvc,
>
> https://trac.ffmpeg.org/ticket/10731#comment:1
>
> Any idea to reduce false positive?
>
> > +return 0;
> > +}
> > +
> > +FF_DEF_RAWVIDEO_DEMUXER(h266, "raw H.266/VVC video", h266_probe,
> "h266,266,vvc", AV_CODEC_ID_VVC)
> > --
> > 2.25.1

It will fix by
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231205094038.12293-1-p...@frankplowman.com/
Could you help merge and backport to 6.1
https://trac.ffmpeg.org/ticket/10703

thank you.


> >
> > ___
> > 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 1/2] fftools/ffmpeg_filter: fix null pointer dereference

2023-12-18 Thread Zhao Zhili


> On Dec 18, 2023, at 20:04, Zhao Zhili  wrote:
> 
> 
> 
>> On Dec 18, 2023, at 19:19, Anton Khirnov  wrote:
>> 
>> Quoting Zhao Zhili (2023-12-17 12:01:08)
>>> From: Zhao Zhili 
>>> 
>>> A dummy frame is created with format NONE passed to enc_open(),
>>> which doesn't prepare for it. The null pointer dereference happened
>>> at av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth.
>>> 
>>> frame #0: 0x00bc34a4 ffmpeg_g`enc_open(opaque=0xb47efe2db690, 
>>> frame=0xb47efe2d9f70) at ffmpeg_enc.c:235:44
>>> frame #1: 0x00bef250 ffmpeg_g`enc_open(sch=0xb47dde2d4090, 
>>> enc=0xb47e4e2daad0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:1462:11
>>> frame #2: 0x00bee094 ffmpeg_g`send_to_enc(sch=0xb47dde2d4090, 
>>> enc=0xb47e4e2daad0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:1571:19
>>> frame #3: 0x00bee01c 
>>> ffmpeg_g`sch_filter_send(sch=0xb47dde2d4090, fg_idx=0, out_idx=0, 
>>> frame=0xb47efe2d9f70) at ffmpeg_sched.c:2154:12
>>> frame #4: 0x00bcf124 ffmpeg_g`close_output(ofp=0xb47e4e2d85b0, 
>>> fgt=0x007d1790eb08) at ffmpeg_filter.c:2225:15
>>> frame #5: 0x00bcb000 
>>> ffmpeg_g`fg_output_frame(ofp=0xb47e4e2d85b0, fgt=0x007d1790eb08, 
>>> frame=0x) at ffmpeg_filter.c:2317:16
>>> frame #6: 0x00bc7e48 ffmpeg_g`filter_thread(arg=0xb47eae2ce7a0) 
>>> at ffmpeg_filter.c:2836:15
>>> frame #7: 0x00bee568 ffmpeg_g`task_wrapper(arg=0xb47d8e2db478) 
>>> at ffmpeg_sched.c:2200:21
>>> 
>>> Signed-off-by: Zhao Zhili 
>>> ---
>>> This bug is trigged by 10bit H.264 which doesn't supported by mediacodec.
>>> There is some misleading error messages from ffmpeg cli:
>>> 
>>> [h264_mediacodec @ 0xb47513788010] Failed to dequeue output buffer 
>>> (status=-1)
>>> [vist#0:0/h264 @ 0xb474a3786b30] Error submitting packet to decoder: 
>>> Generic error in an external library
>>> [h264_mediacodec @ 0xb47513788010] Failed to dequeue output buffer 
>>> (status=-1)
>>> [vist#0:0/h264 @ 0xb474a3786b30] Error submitting packet to decoder: 
>>> Generic error in an external library
>>> [vist#0:0/h264 @ 0xb474a3786b30] A decoder returned an unexpected error 
>>> code. This is a bug, please report it.
>>> [vist#0:0/h264 @ 0xb474a3786b30] Error processing packet in decoder: 
>>> Internal bug, should not have happened
>>> 
>>> fftools/ffmpeg_filter.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
>>> index bb755d7bb4..9dc47f9d90 100644
>>> --- a/fftools/ffmpeg_filter.c
>>> +++ b/fftools/ffmpeg_filter.c
>>> @@ -2192,7 +2192,7 @@ static int close_output(OutputFilterPriv *ofp, 
>>> FilterGraphThread *fgt)
>>> 
>>>// we are finished and no frames were ever seen at this output,
>>>// at least initialize the encoder with a dummy frame
>>> -if (!fgt->got_frame) {
>>> +if (!fgt->got_frame && ofp->format != -1) {
>> 
>> I don't quite understand how precisely does this happen.
>> 
>> This code should only be reachable if the filtergraph was configured at
>> least once, then configure_filtergraph() should set ofp->format to the
>> format reported by the lavfi buffersink. Does this then mean that lavfi
>> is configured with AV_PIX_FMT_NONE? Or that this is somehow triggered
>> without the filtergraph being configured?
> 
> 
> Can reproduced with:
> 
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 559f63698a..af4ea37812 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -1050,6 +1050,7 @@ static int qsv_decode_frame(AVCodecContext *avctx, 
> AVFrame *frame,
> QSVDecContext *s = avctx->priv_data;
> int ret;
> 
> +return AVERROR_EXTERNAL;
> /* buffer the input packet */
> if (avpkt->size) {
> AVPacket input_ref;
> 
> Then
> ./ffmpeg -c:v h264_qsv -xerror  -I input.mp4 -c:a copy  -c:v libx264  
> output.mp4 
> 
> Looks like filtergraph isn’t being configured.

By the way, this issue is related to trac 
https://trac.ffmpeg.org/ticket/10671

User reported different behavior on 6.1, like does exit with -xerror but 
continue with audio stream.

> 
>> 
>> -- 
>> Anton Khirnov
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org  
>> 
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org  
>>  with subject "unsubscribe".
> 
> ___
> 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] fftools/ffmpeg_filter: fix null pointer dereference

2023-12-18 Thread Anton Khirnov
Quoting Zhao Zhili (2023-12-18 13:04:24)
> 
> 
> > On Dec 18, 2023, at 19:19, Anton Khirnov  wrote:
> > 
> > Quoting Zhao Zhili (2023-12-17 12:01:08)
> >> From: Zhao Zhili 
> >> 
> >> A dummy frame is created with format NONE passed to enc_open(),
> >> which doesn't prepare for it. The null pointer dereference happened
> >> at av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth.
> >> 
> >> frame #0: 0x00bc34a4 ffmpeg_g`enc_open(opaque=0xb47efe2db690, 
> >> frame=0xb47efe2d9f70) at ffmpeg_enc.c:235:44
> >> frame #1: 0x00bef250 ffmpeg_g`enc_open(sch=0xb47dde2d4090, 
> >> enc=0xb47e4e2daad0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:1462:11
> >> frame #2: 0x00bee094 ffmpeg_g`send_to_enc(sch=0xb47dde2d4090, 
> >> enc=0xb47e4e2daad0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:1571:19
> >> frame #3: 0x00bee01c 
> >> ffmpeg_g`sch_filter_send(sch=0xb47dde2d4090, fg_idx=0, out_idx=0, 
> >> frame=0xb47efe2d9f70) at ffmpeg_sched.c:2154:12
> >> frame #4: 0x00bcf124 ffmpeg_g`close_output(ofp=0xb47e4e2d85b0, 
> >> fgt=0x007d1790eb08) at ffmpeg_filter.c:2225:15
> >> frame #5: 0x00bcb000 
> >> ffmpeg_g`fg_output_frame(ofp=0xb47e4e2d85b0, fgt=0x007d1790eb08, 
> >> frame=0x) at ffmpeg_filter.c:2317:16
> >> frame #6: 0x00bc7e48 
> >> ffmpeg_g`filter_thread(arg=0xb47eae2ce7a0) at ffmpeg_filter.c:2836:15
> >> frame #7: 0x00bee568 ffmpeg_g`task_wrapper(arg=0xb47d8e2db478) 
> >> at ffmpeg_sched.c:2200:21
> >> 
> >> Signed-off-by: Zhao Zhili 
> >> ---
> >> This bug is trigged by 10bit H.264 which doesn't supported by mediacodec.
> >> There is some misleading error messages from ffmpeg cli:
> >> 
> >> [h264_mediacodec @ 0xb47513788010] Failed to dequeue output buffer 
> >> (status=-1)
> >> [vist#0:0/h264 @ 0xb474a3786b30] Error submitting packet to decoder: 
> >> Generic error in an external library
> >> [h264_mediacodec @ 0xb47513788010] Failed to dequeue output buffer 
> >> (status=-1)
> >> [vist#0:0/h264 @ 0xb474a3786b30] Error submitting packet to decoder: 
> >> Generic error in an external library
> >> [vist#0:0/h264 @ 0xb474a3786b30] A decoder returned an unexpected 
> >> error code. This is a bug, please report it.
> >> [vist#0:0/h264 @ 0xb474a3786b30] Error processing packet in decoder: 
> >> Internal bug, should not have happened
> >> 
> >> fftools/ffmpeg_filter.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> >> index bb755d7bb4..9dc47f9d90 100644
> >> --- a/fftools/ffmpeg_filter.c
> >> +++ b/fftools/ffmpeg_filter.c
> >> @@ -2192,7 +2192,7 @@ static int close_output(OutputFilterPriv *ofp, 
> >> FilterGraphThread *fgt)
> >> 
> >> // we are finished and no frames were ever seen at this output,
> >> // at least initialize the encoder with a dummy frame
> >> -if (!fgt->got_frame) {
> >> +if (!fgt->got_frame && ofp->format != -1) {
> > 
> > I don't quite understand how precisely does this happen.
> > 
> > This code should only be reachable if the filtergraph was configured at
> > least once, then configure_filtergraph() should set ofp->format to the
> > format reported by the lavfi buffersink. Does this then mean that lavfi
> > is configured with AV_PIX_FMT_NONE? Or that this is somehow triggered
> > without the filtergraph being configured?
> 
> 
> Can reproduced with:
> 
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 559f63698a..af4ea37812 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -1050,6 +1050,7 @@ static int qsv_decode_frame(AVCodecContext *avctx, 
> AVFrame *frame,
>  QSVDecContext *s = avctx->priv_data;
>  int ret;
>  
> +return AVERROR_EXTERNAL;
>  /* buffer the input packet */
>  if (avpkt->size) {
>  AVPacket input_ref;
> 
> Then
> ./ffmpeg -c:v h264_qsv -xerror  -I input.mp4 -c:a copy  -c:v libx264  
> output.mp4 
> 
> Looks like filtergraph isn’t being configured.

I see, then seems to me it'd be better to run the final loop in
filter_thread() (the one calling fg_output_frame(, NULL)) only when
fgt->graph is non-NULL. That should fix this issue as well.

Thanks,
-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 0/1] fftools/ffprobe: dump contents of the AV_FRAME_DATA_SEI_UNREGISTERED

2023-12-18 Thread Petr Matousek
Before this patch being applied the ffprobe just tells the user whether
the H.26[45] User Data Unregistered SEI message is present in the frame side 
data
or not. After the patch being appliend it also dumps the contents of the data
similar way as for the other already supported frame side data types.

Petr Matousek (1):
  fftools/ffprobe: dump contents of the AV_FRAME_DATA_SEI_UNREGISTERED

 fftools/ffprobe.c  |  15 +++
 tests/ref/fate/hevc-dv-rpu |   4 +
 tests/ref/fate/hevc-hdr-vivid-metadata |   4 +
 tests/ref/fate/hevc-monochrome-crop|   4 +
 tests/ref/fate/mov-zombie  | 130 -
 5 files changed, 92 insertions(+), 65 deletions(-)

-- 
2.34.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/6] checkasm/takdsp: add decorrelate_ls test

2023-12-18 Thread flow gg

From 960f70964521e1dc94647d70e2631351c0bb51bb Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Mon, 18 Dec 2023 22:39:13 +0800
Subject: [PATCH 1/6] checkasm/takdsp: add decorrelate_ls test

---
 tests/checkasm/Makefile   |  1 +
 tests/checkasm/checkasm.c |  3 ++
 tests/checkasm/checkasm.h |  1 +
 tests/checkasm/takdsp.c   | 68 +++
 tests/fate/checkasm.mak   |  1 +
 5 files changed, 74 insertions(+)
 create mode 100644 tests/checkasm/takdsp.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index a46c32926b..e6d732d8de 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -33,6 +33,7 @@ AVCODECOBJS-$(CONFIG_JPEG2000_DECODER)  += jpeg2000dsp.o
 AVCODECOBJS-$(CONFIG_OPUS_DECODER)  += opusdsp.o
 AVCODECOBJS-$(CONFIG_PIXBLOCKDSP)   += pixblockdsp.o
 AVCODECOBJS-$(CONFIG_HEVC_DECODER)  += hevc_add_res.o hevc_deblock.o hevc_idct.o hevc_sao.o hevc_pel.o
+AVCODECOBJS-$(CONFIG_TAK_DECODER)   += takdsp.o
 AVCODECOBJS-$(CONFIG_UTVIDEO_DECODER)   += utvideodsp.o
 AVCODECOBJS-$(CONFIG_V210_DECODER)  += v210dec.o
 AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 6318d9296b..51a8cdf3a0 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -159,6 +159,9 @@ static const struct {
 #if CONFIG_PIXBLOCKDSP
 { "pixblockdsp", checkasm_check_pixblockdsp },
 #endif
+#if CONFIG_TAK_DECODER
+{ "takdsp", checkasm_check_takdsp },
+#endif
 #if CONFIG_UTVIDEO_DECODER
 { "utvideodsp", checkasm_check_utvideodsp },
 #endif
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index e3c19510fa..cb57eeeddf 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -85,6 +85,7 @@ void checkasm_check_synth_filter(void);
 void checkasm_check_sw_gbrp(void);
 void checkasm_check_sw_rgb(void);
 void checkasm_check_sw_scale(void);
+void checkasm_check_takdsp(void);
 void checkasm_check_utvideodsp(void);
 void checkasm_check_v210dec(void);
 void checkasm_check_v210enc(void);
diff --git a/tests/checkasm/takdsp.c b/tests/checkasm/takdsp.c
new file mode 100644
index 00..4c7442f922
--- /dev/null
+++ b/tests/checkasm/takdsp.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright (c) 2023 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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 
+
+#include "libavutil/mem.h"
+#include "libavutil/mem_internal.h"
+
+#include "libavcodec/takdsp.h"
+
+#include "checkasm.h"
+
+#define randomize(buf, len) \
+do { \
+for (int i = 0; i < len; i++) \
+buf[i] = rnd(); \
+} while (0)
+
+static void test_decorrelate_ls(TAKDSPContext *s) {
+#define BUF_SIZE 1024
+declare_func(void, int32_t *, int32_t *, int);
+
+if (check_func(s->decorrelate_ls, "decorrelate_ls")) {
+LOCAL_ALIGNED_32(int32_t, p1, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, p2, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, p2_2, [BUF_SIZE]);
+
+randomize(p1, BUF_SIZE);
+randomize(p2, BUF_SIZE);
+memcpy(p2_2, p2, BUF_SIZE);
+
+call_ref(p1, p2, BUF_SIZE);
+call_new(p1, p2_2, BUF_SIZE);
+
+if (memcmp(p2, p2_2, BUF_SIZE) != 0){
+fail();
+}
+
+bench_new(p1, p2, BUF_SIZE);
+}
+
+report("decorrelate_ls");
+}
+
+void checkasm_check_takdsp(void)
+{
+TAKDSPContext s = { 0 };
+ff_takdsp_init(&s);
+
+test_decorrelate_ls(&s);
+}
diff --git a/tests/fate/checkasm.mak b/tests/fate/checkasm.mak
index 65bace892b..34e1a0a048 100644
--- a/tests/fate/checkasm.mak
+++ b/tests/fate/checkasm.mak
@@ -37,6 +37,7 @@ FATE_CHECKASM = fate-checkasm-aacencdsp \
 fate-checkasm-sw_gbrp   \
 fate-checkasm-sw_rgb\
 fate-checkasm-sw_scale  \
+fate-checkasm-takdsp\
 fate-checkasm-utvideodsp\
 fate-checkasm-v210dec   \
 fate-checkasm-v210enc   

[FFmpeg-devel] [PATCH 2/6] checkasm/takdsp: add decorrelate_sr test

2023-12-18 Thread flow gg

From 9254ae1f72498568857357059eb514e8cb90b5f1 Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Mon, 18 Dec 2023 22:47:29 +0800
Subject: [PATCH 2/6] checkasm/takdsp: add decorrelate_sr test

---
 tests/checkasm/takdsp.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/tests/checkasm/takdsp.c b/tests/checkasm/takdsp.c
index 4c7442f922..2fa639bfc1 100644
--- a/tests/checkasm/takdsp.c
+++ b/tests/checkasm/takdsp.c
@@ -59,10 +59,37 @@ static void test_decorrelate_ls(TAKDSPContext *s) {
 report("decorrelate_ls");
 }
 
+static void test_decorrelate_sr(TAKDSPContext *s) {
+#define BUF_SIZE 1024
+declare_func(void, int32_t *, int32_t *, int);
+
+if (check_func(s->decorrelate_sr, "decorrelate_sr")) {
+LOCAL_ALIGNED_32(int32_t, p1, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, p2, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, p2_2, [BUF_SIZE]);
+
+randomize(p1, BUF_SIZE);
+randomize(p2, BUF_SIZE);
+memcpy(p2_2, p2, BUF_SIZE);
+
+call_ref(p1, p2, BUF_SIZE);
+call_new(p1, p2_2, BUF_SIZE);
+
+if (memcmp(p2, p2_2, BUF_SIZE) != 0){
+fail();
+}
+
+bench_new(p1, p2, BUF_SIZE);
+}
+
+report("decorrelate_sr");
+}
+
 void checkasm_check_takdsp(void)
 {
 TAKDSPContext s = { 0 };
 ff_takdsp_init(&s);
 
 test_decorrelate_ls(&s);
+test_decorrelate_sr(&s);
 }
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 3/6] checkasm/takdsp: add decorrelate_sm test

2023-12-18 Thread flow gg

From 9e09f52403058e1bc87653bfd9980c7d5a6ce33c Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Mon, 18 Dec 2023 22:48:09 +0800
Subject: [PATCH 3/6] checkasm/takdsp: add decorrelate_sm test

---
 tests/checkasm/takdsp.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/tests/checkasm/takdsp.c b/tests/checkasm/takdsp.c
index 2fa639bfc1..495b7242c5 100644
--- a/tests/checkasm/takdsp.c
+++ b/tests/checkasm/takdsp.c
@@ -85,6 +85,34 @@ static void test_decorrelate_sr(TAKDSPContext *s) {
 report("decorrelate_sr");
 }
 
+static void test_decorrelate_sm(TAKDSPContext *s) {
+#define BUF_SIZE 1024
+declare_func(void, int32_t *, int32_t *, int);
+
+if (check_func(s->decorrelate_sm, "decorrelate_sm")) {
+LOCAL_ALIGNED_32(int32_t, p1, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, p1_2, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, p2, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, p2_2, [BUF_SIZE]);
+
+randomize(p1, BUF_SIZE);
+memcpy(p1, p1_2, BUF_SIZE);
+randomize(p2, BUF_SIZE);
+memcpy(p2_2, p2, BUF_SIZE);
+
+call_ref(p1, p2, BUF_SIZE);
+call_new(p1_2, p2_2, BUF_SIZE);
+
+if (memcmp(p2, p2_2, BUF_SIZE) != 0){
+fail();
+}
+
+bench_new(p1, p2, BUF_SIZE);
+}
+
+report("decorrelate_sm");
+}
+
 void checkasm_check_takdsp(void)
 {
 TAKDSPContext s = { 0 };
@@ -92,4 +120,5 @@ void checkasm_check_takdsp(void)
 
 test_decorrelate_ls(&s);
 test_decorrelate_sr(&s);
+test_decorrelate_sm(&s);
 }
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 4/6] lavc/takdsp: R-V V decorrelate_ls

2023-12-18 Thread flow gg
C908:
decorrelate_ls_c: 69.7
decorrelate_ls_rvv_i32: 27.2
From 03fad46e6db1846596c31918fc4e34b58246efc4 Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Mon, 18 Dec 2023 22:49:21 +0800
Subject: [PATCH 4/6] lavc/takdsp: R-V V decorrelate_ls

C908:
decorrelate_ls_c: 69.7
decorrelate_ls_rvv_i32: 27.2
---
 libavcodec/riscv/Makefile  |  2 ++
 libavcodec/riscv/takdsp_init.c | 39 ++
 libavcodec/riscv/takdsp_rvv.S  | 35 ++
 libavcodec/takdsp.c|  4 +++-
 libavcodec/takdsp.h|  1 +
 5 files changed, 80 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/riscv/takdsp_init.c
 create mode 100644 libavcodec/riscv/takdsp_rvv.S

diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 6f7cb8791f..aa758eba1c 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -42,6 +42,8 @@ RVV-OBJS-$(CONFIG_OPUS_DECODER) += riscv/opusdsp_rvv.o
 OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_init.o
 RV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvi.o
 RVV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvv.o
+OBJS-$(CONFIG_TAK_DECODER) += riscv/takdsp_init.o
+RVV-OBJS-$(CONFIG_TAK_DECODER) += riscv/takdsp_rvv.o
 OBJS-$(CONFIG_UTVIDEO_DECODER) += riscv/utvideodsp_init.o
 RVV-OBJS-$(CONFIG_UTVIDEO_DECODER) += riscv/utvideodsp_rvv.o
 OBJS-$(CONFIG_VC1DSP) += riscv/vc1dsp_init.o
diff --git a/libavcodec/riscv/takdsp_init.c b/libavcodec/riscv/takdsp_init.c
new file mode 100644
index 00..fcf0c5f37b
--- /dev/null
+++ b/libavcodec/riscv/takdsp_init.c
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2023 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * 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 
+
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavutil/riscv/cpu.h"
+#include "libavcodec/takdsp.h"
+
+void ff_decorrelate_ls_rvv(int32_t *p1, int32_t *p2, int length);
+
+av_cold void ff_takdsp_init_riscv(TAKDSPContext *dsp)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+dsp->decorrelate_ls = ff_decorrelate_ls_rvv;
+}
+#endif
+}
diff --git a/libavcodec/riscv/takdsp_rvv.S b/libavcodec/riscv/takdsp_rvv.S
new file mode 100644
index 00..00e8e38fdf
--- /dev/null
+++ b/libavcodec/riscv/takdsp_rvv.S
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2023 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * 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/riscv/asm.S"
+
+func ff_decorrelate_ls_rvv, zve32x
+1:
+vsetvli  t0, a2, e32, m8, ta, ma
+vle32.v  v0, (a0)
+sub  a2, a2, t0
+vle32.v  v8, (a1)
+vadd.vv  v16, v0, v8
+vse32.v  v16, (a1)
+sh2add   a0, t0, a0
+sh2add   a1, t0, a1
+bnez a2, 1b
+ret
+endfunc
diff --git a/libavcodec/takdsp.c b/libavcodec/takdsp.c
index b646a063db..25cac558ce 100644
--- a/libavcodec/takdsp.c
+++ b/libavcodec/takdsp.c
@@ -77,7 +77,9 @@ av_cold void ff_takdsp_init(TAKDSPContext *c)
 c->decorrelate_sm = decorrelate_sm;
 c->decorrelate_sf = decorrelate_sf;
 
-#if ARCH_X86
+#if ARCH_RISCV
+ff_takdsp_init_riscv(c);
+#elif ARCH_X86
 ff_takdsp_init_x86(c);
 #endif
 }
diff --git a/libavcodec/takdsp.h b/libavcodec/takdsp.h
index c05b5741a4..55f1a10cd3 100644
--- a/libavcodec/takdsp.h
+++ b/libavcodec/takdsp.h
@@ -29,6 +29,7 @@ typedef struct TAKDSPContext {
 } TAKDSPContext;
 
 void ff_takdsp_init(TAKDSPC

[FFmpeg-devel] [PATCH 5/6] lavc/takdsp: R-V V decorrelate_sr

2023-12-18 Thread flow gg
C908:
decorrelate_sr_c: 95.5
decorrelate_sr_rvv_i32: 28.2
From fa1a84337a7cd2a62c26a9d5f8d707a97e917f77 Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Mon, 18 Dec 2023 22:52:20 +0800
Subject: [PATCH 5/6] lavc/takdsp: R-V V decorrelate_sr

C908:
decorrelate_sr_c: 95.5
decorrelate_sr_rvv_i32: 28.2
---
 libavcodec/riscv/takdsp_init.c |  2 ++
 libavcodec/riscv/takdsp_rvv.S  | 14 ++
 2 files changed, 16 insertions(+)

diff --git a/libavcodec/riscv/takdsp_init.c b/libavcodec/riscv/takdsp_init.c
index fcf0c5f37b..0b4ec18086 100644
--- a/libavcodec/riscv/takdsp_init.c
+++ b/libavcodec/riscv/takdsp_init.c
@@ -26,6 +26,7 @@
 #include "libavcodec/takdsp.h"
 
 void ff_decorrelate_ls_rvv(int32_t *p1, int32_t *p2, int length);
+void ff_decorrelate_sr_rvv(int32_t *p1, int32_t *p2, int length);
 
 av_cold void ff_takdsp_init_riscv(TAKDSPContext *dsp)
 {
@@ -34,6 +35,7 @@ av_cold void ff_takdsp_init_riscv(TAKDSPContext *dsp)
 
 if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
 dsp->decorrelate_ls = ff_decorrelate_ls_rvv;
+dsp->decorrelate_sr = ff_decorrelate_sr_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/takdsp_rvv.S b/libavcodec/riscv/takdsp_rvv.S
index 00e8e38fdf..65c79e1aa9 100644
--- a/libavcodec/riscv/takdsp_rvv.S
+++ b/libavcodec/riscv/takdsp_rvv.S
@@ -33,3 +33,17 @@ func ff_decorrelate_ls_rvv, zve32x
 bnez a2, 1b
 ret
 endfunc
+
+func ff_decorrelate_sr_rvv, zve32x
+1:
+vsetvli  t0, a2, e32, m8, ta, ma
+vle32.v  v0, (a0)
+sub  a2, a2, t0
+vle32.v  v8, (a1)
+sh2add   a1, t0, a1
+vsub.vv  v16, v8, v0
+vse32.v  v16, (a0)
+sh2add   a0, t0, a0
+bnez a2, 1b
+ret
+endfunc
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 6/6] lavc/takdsp: R-V V decorrelate_sm

2023-12-18 Thread flow gg
C908:
decorrelate_sm_c: 130.0
decorrelate_sm_rvv_i32: 43.7
From 3dc613feaa6c38a7df47a3fc385e2140716e0ae2 Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Mon, 18 Dec 2023 22:53:39 +0800
Subject: [PATCH 6/6] lavc/takdsp: R-V V decorrelate_sm

C908:
decorrelate_sm_c: 130.0
decorrelate_sm_rvv_i32: 43.7
---
 libavcodec/riscv/takdsp_init.c |  2 ++
 libavcodec/riscv/takdsp_rvv.S  | 17 +
 2 files changed, 19 insertions(+)

diff --git a/libavcodec/riscv/takdsp_init.c b/libavcodec/riscv/takdsp_init.c
index 0b4ec18086..85634d6db6 100644
--- a/libavcodec/riscv/takdsp_init.c
+++ b/libavcodec/riscv/takdsp_init.c
@@ -27,6 +27,7 @@
 
 void ff_decorrelate_ls_rvv(int32_t *p1, int32_t *p2, int length);
 void ff_decorrelate_sr_rvv(int32_t *p1, int32_t *p2, int length);
+void ff_decorrelate_sm_rvv(int32_t *p1, int32_t *p2, int length);
 
 av_cold void ff_takdsp_init_riscv(TAKDSPContext *dsp)
 {
@@ -36,6 +37,7 @@ av_cold void ff_takdsp_init_riscv(TAKDSPContext *dsp)
 if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
 dsp->decorrelate_ls = ff_decorrelate_ls_rvv;
 dsp->decorrelate_sr = ff_decorrelate_sr_rvv;
+dsp->decorrelate_sm = ff_decorrelate_sm_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/takdsp_rvv.S b/libavcodec/riscv/takdsp_rvv.S
index 65c79e1aa9..816e765039 100644
--- a/libavcodec/riscv/takdsp_rvv.S
+++ b/libavcodec/riscv/takdsp_rvv.S
@@ -47,3 +47,20 @@ func ff_decorrelate_sr_rvv, zve32x
 bnez a2, 1b
 ret
 endfunc
+
+func ff_decorrelate_sm_rvv, zve32x
+1:
+vsetvli  t0, a2, e32, m8, ta, ma
+vle32.v  v0, (a0)
+sub a2,  a2, t0
+vle32.v  v8, (a1)
+vsra.vi  v16, v8, 1
+vsub.vv  v0, v0, v16
+vse32.v  v0, (a0)
+sh2add   a0, t0, a0
+vadd.vv  v0, v0, v8
+vse32.v  v0, (a1)
+sh2add   a1, t0, a1
+bnez a2, 1b
+ret
+endfunc
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 4/6] lavc/takdsp: R-V V decorrelate_ls

2023-12-18 Thread flow gg
A 'shnadd' should be moved to the front, updated in this reply.

flow gg  于2023年12月18日周一 23:15写道:

> C908:
> decorrelate_ls_c: 69.7
> decorrelate_ls_rvv_i32: 27.2
>
From fdee02eae64ced9a65781fbbeef32c6b8ee2fdce Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Mon, 18 Dec 2023 22:49:21 +0800
Subject: [PATCH 4/6] lavc/takdsp: R-V V decorrelate_ls

C908:
decorrelate_ls_c: 69.7
decorrelate_ls_rvv_i32: 27.2
---
 libavcodec/riscv/Makefile  |  2 ++
 libavcodec/riscv/takdsp_init.c | 39 ++
 libavcodec/riscv/takdsp_rvv.S  | 35 ++
 libavcodec/takdsp.c|  4 +++-
 libavcodec/takdsp.h|  1 +
 5 files changed, 80 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/riscv/takdsp_init.c
 create mode 100644 libavcodec/riscv/takdsp_rvv.S

diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 6f7cb8791f..aa758eba1c 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -42,6 +42,8 @@ RVV-OBJS-$(CONFIG_OPUS_DECODER) += riscv/opusdsp_rvv.o
 OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_init.o
 RV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvi.o
 RVV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvv.o
+OBJS-$(CONFIG_TAK_DECODER) += riscv/takdsp_init.o
+RVV-OBJS-$(CONFIG_TAK_DECODER) += riscv/takdsp_rvv.o
 OBJS-$(CONFIG_UTVIDEO_DECODER) += riscv/utvideodsp_init.o
 RVV-OBJS-$(CONFIG_UTVIDEO_DECODER) += riscv/utvideodsp_rvv.o
 OBJS-$(CONFIG_VC1DSP) += riscv/vc1dsp_init.o
diff --git a/libavcodec/riscv/takdsp_init.c b/libavcodec/riscv/takdsp_init.c
new file mode 100644
index 00..fcf0c5f37b
--- /dev/null
+++ b/libavcodec/riscv/takdsp_init.c
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2023 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * 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 
+
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavutil/riscv/cpu.h"
+#include "libavcodec/takdsp.h"
+
+void ff_decorrelate_ls_rvv(int32_t *p1, int32_t *p2, int length);
+
+av_cold void ff_takdsp_init_riscv(TAKDSPContext *dsp)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+dsp->decorrelate_ls = ff_decorrelate_ls_rvv;
+}
+#endif
+}
diff --git a/libavcodec/riscv/takdsp_rvv.S b/libavcodec/riscv/takdsp_rvv.S
new file mode 100644
index 00..b2869f1090
--- /dev/null
+++ b/libavcodec/riscv/takdsp_rvv.S
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2023 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * 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/riscv/asm.S"
+
+func ff_decorrelate_ls_rvv, zve32x
+1:
+vsetvli  t0, a2, e32, m8, ta, ma
+vle32.v  v0, (a0)
+sh2add   a0, t0, a0
+sub  a2, a2, t0
+vle32.v  v8, (a1)
+vadd.vv  v16, v0, v8
+vse32.v  v16, (a1)
+sh2add   a1, t0, a1
+bnez a2, 1b
+ret
+endfunc
diff --git a/libavcodec/takdsp.c b/libavcodec/takdsp.c
index b646a063db..25cac558ce 100644
--- a/libavcodec/takdsp.c
+++ b/libavcodec/takdsp.c
@@ -77,7 +77,9 @@ av_cold void ff_takdsp_init(TAKDSPContext *c)
 c->decorrelate_sm = decorrelate_sm;
 c->decorrelate_sf = decorrelate_sf;
 
-#if ARCH_X86
+#if ARCH_RISCV
+ff_takdsp_init_riscv(c);
+#elif ARCH_X86
 ff_takdsp_init_x86(c);
 #endif
 }
diff --git a/libavcodec/takdsp.h b/libavcodec/takdsp.h
index c05b5741a4..55f1a10cd3 100644
--- a/libavcodec/takdsp.h
+++ b/libavcodec

Re: [FFmpeg-devel] [PATCH 4/6] lavc/takdsp: R-V V decorrelate_ls

2023-12-18 Thread Rémi Denis-Courmont
Le maanantaina 18. joulukuuta 2023, 17.26.58 EET flow gg a écrit :
> A 'shnadd' should be moved to the front, updated in this reply.

Indeed, but please try to interleave scalar and vector instructions. The C908 
IP does not really care, but apparently, in-order vector processor are going 
to be happening next year.

-- 
Rémi Denis-Courmont
http://www.remlab.net/



___
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] [PATCHv2 1/1] checkasm/lpc: test compute_autocorr

2023-12-18 Thread Rémi Denis-Courmont
Le sunnuntaina 17. joulukuuta 2023, 23.57.50 EET Martin Storsjö a écrit :
> > Rounding errors would not cause a constant gap across the different test
> > cases. This is most likely an off-by-one in the x86 code. I don't know if
> > this is a bug in the x86 code, or the test case being a little loose with
> > input parameters, and I have neither time, nor motivation not to mention
> > skills to figure that out, so there will be no test cases for this
> > function form me afterall.
> 
> FWIW, we've had these situations elsewhere before as well, in swscale,
> where the existing x86 assembly mismatches the C code in nontrivial ways,
> and we have new assembly (aarch64 in that case) that is missing a test
> (even if one was written) due to this.
> 
> First I considered if we should collect these extra checkasm tests in some
> branch somewhere, so they aren't lost, as they are useful when working on
> assembly on other architectures.
> 
> But rather than having the code rot, forgotten in a stray branch
> somewhere, I wonder if we should just go ahead and merge it with an #if
> !ARCH_X86 or something, together with a notable FIXME comment.

I'd certainly welcome more checkasm that literally anyone other than me wrote. 
If the divergence in the X86 code is simply due to optimising an inexact 
algorithm differently, that seems fine. 

But if it is a case that the X86 code is demonstrably buggy, I think that it 
should be commented out or removed. That would not only fix a bug, but also put 
stronger incentives for X68 fanboys to actually fix it. Worst case, the 
optimisation has become meaningless and we have actually fixed a bug.

Though I don't know which case this nor your swscale tests are.

-- 
レミ・デニ-クールモン
http://www.remlab.net/



___
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 4/6] lavc/takdsp: R-V V decorrelate_ls

2023-12-18 Thread flow gg
Okay, updated in the reply.

Rémi Denis-Courmont  于2023年12月19日周二 00:25写道:

> Le maanantaina 18. joulukuuta 2023, 17.26.58 EET flow gg a écrit :
> > A 'shnadd' should be moved to the front, updated in this reply.
>
> Indeed, but please try to interleave scalar and vector instructions. The
> C908
> IP does not really care, but apparently, in-order vector processor are
> going
> to be happening next year.
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>
>
>
> ___
> 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".
>
From 0b29172cfa684906868ef9d185ae2f96ab4ed598 Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Mon, 18 Dec 2023 22:49:21 +0800
Subject: [PATCH 4/6] lavc/takdsp: R-V V decorrelate_ls

C908:
decorrelate_ls_c: 69.7
decorrelate_ls_rvv_i32: 27.2
---
 libavcodec/riscv/Makefile  |  2 ++
 libavcodec/riscv/takdsp_init.c | 39 ++
 libavcodec/riscv/takdsp_rvv.S  | 35 ++
 libavcodec/takdsp.c|  4 +++-
 libavcodec/takdsp.h|  1 +
 5 files changed, 80 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/riscv/takdsp_init.c
 create mode 100644 libavcodec/riscv/takdsp_rvv.S

diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 6f7cb8791f..aa758eba1c 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -42,6 +42,8 @@ RVV-OBJS-$(CONFIG_OPUS_DECODER) += riscv/opusdsp_rvv.o
 OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_init.o
 RV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvi.o
 RVV-OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_rvv.o
+OBJS-$(CONFIG_TAK_DECODER) += riscv/takdsp_init.o
+RVV-OBJS-$(CONFIG_TAK_DECODER) += riscv/takdsp_rvv.o
 OBJS-$(CONFIG_UTVIDEO_DECODER) += riscv/utvideodsp_init.o
 RVV-OBJS-$(CONFIG_UTVIDEO_DECODER) += riscv/utvideodsp_rvv.o
 OBJS-$(CONFIG_VC1DSP) += riscv/vc1dsp_init.o
diff --git a/libavcodec/riscv/takdsp_init.c b/libavcodec/riscv/takdsp_init.c
new file mode 100644
index 00..fcf0c5f37b
--- /dev/null
+++ b/libavcodec/riscv/takdsp_init.c
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2023 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * 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 
+
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavutil/riscv/cpu.h"
+#include "libavcodec/takdsp.h"
+
+void ff_decorrelate_ls_rvv(int32_t *p1, int32_t *p2, int length);
+
+av_cold void ff_takdsp_init_riscv(TAKDSPContext *dsp)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+dsp->decorrelate_ls = ff_decorrelate_ls_rvv;
+}
+#endif
+}
diff --git a/libavcodec/riscv/takdsp_rvv.S b/libavcodec/riscv/takdsp_rvv.S
new file mode 100644
index 00..c662049f3d
--- /dev/null
+++ b/libavcodec/riscv/takdsp_rvv.S
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2023 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * 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/riscv/asm.S"
+
+func ff_decorrelate_ls_rvv, zve32x
+1:
+vsetvli  t0, a2, e32, m8, ta, ma
+sub  a2, a2, t0
+vle32.v  v0, (a0)
+sh2add   a0, t0, a0
+vle32.v  v8, (a1)
+vadd.vv  v16, v0, v8
+vse32.v  v16, (a1)
+sh2add   a1, t0, a1
+bnez a

Re: [FFmpeg-devel] [PATCHv2 1/1] checkasm/lpc: test compute_autocorr

2023-12-18 Thread Anton Khirnov
Quoting Martin Storsjö (2023-12-17 22:57:50)
> 
> FWIW, we've had these situations elsewhere before as well, in swscale, 
> where the existing x86 assembly mismatches the C code in nontrivial ways, 
> and we have new assembly (aarch64 in that case) that is missing a test 
> (even if one was written) due to this.
> 
> First I considered if we should collect these extra checkasm tests in some 
> branch somewhere, so they aren't lost, as they are useful when working on 
> assembly on other architectures.
> 
> But rather than having the code rot, forgotten in a stray branch 
> somewhere, I wonder if we should just go ahead and merge it with an #if 
> !ARCH_X86 or something, together with a notable FIXME comment.
> 
> That would keep the test coverage for new asm implementations, avoid code 
> rot, and leave the opportunity to sort things out easily available for 
> whoever wants to dissect the old existing x86 assembly implementations.
> 
> That's clearly not ideal, but would pragmatically be better than to just 
> not merge the new checkasm test at all. What do others think?

FWIW what you propose sounds good to me.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] avcodec/libjxldec: emit proper PTS to decoded AVFrame

2023-12-18 Thread Anton Khirnov
Quoting Leo Izen (2023-12-15 00:33:33)
> On 12/14/23 03:28, Anton Khirnov wrote:
> > This logic seems shady to me.
> 
> Which part, specifically? The animated logic, or the non-animated logic?

Aspects of both looked questionable to me (which doesn't necessarily
means it's wrong)

> > The decoder should mess with pts as little
> > as possible and whenever it can just copy the packet value to the frame.
> > Any codec-level timestamps should not be trusted.
> 
> In the case of animated JXL, codec-level timestamps are all that's 
> available because the only demuxer is jpegxl_anim, which doesn't 
> packetize the individual frames.

That may change in the future. And you shouldn't assume the caller is
necessarily using lavf for demuxing, if you can help it.

> > 
> > Now this does not work when a single packet decodes into multiple
> > frames, then you have to add increments of frame duration to the
> > original packet pts. But you should still preserve the original value as
> > the base - it might not start at 0.
> 
> I see what you're saying, but in the case where one packet decodes into 
> multiple frames in the non-animated stream, we don't have any way to 
> properly differentiate the PTS of those frames.

When does that happen?

And sure, I accept that when there's no other option you might have to
take some liberties. I'm just saying it should be done as little as
possible.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCHv2 1/1] checkasm/lpc: test compute_autocorr

2023-12-18 Thread Michael Niedermayer
On Sun, Dec 17, 2023 at 11:57:50PM +0200, Martin Storsjö wrote:
[...]
> FWIW, we've had these situations elsewhere before as well, in swscale, where
> the existing x86 assembly mismatches the C code in nontrivial ways, and we
> have new assembly (aarch64 in that case) that is missing a test (even if one
> was written) due to this.
> 
> First I considered if we should collect these extra checkasm tests in some
> branch somewhere, so they aren't lost, as they are useful when working on
> assembly on other architectures.
> 

> But rather than having the code rot, forgotten in a stray branch somewhere,
> I wonder if we should just go ahead and merge it with an #if !ARCH_X86 or
> something, together with a notable FIXME comment.

+1
i suggest, if its easy rather than disabling, adjust the threshold

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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] [PATCHv2 1/1] checkasm/lpc: test compute_autocorr

2023-12-18 Thread James Almer

On 12/18/2023 1:34 PM, Rémi Denis-Courmont wrote:

Le sunnuntaina 17. joulukuuta 2023, 23.57.50 EET Martin Storsjö a écrit :

Rounding errors would not cause a constant gap across the different test
cases. This is most likely an off-by-one in the x86 code. I don't know if
this is a bug in the x86 code, or the test case being a little loose with
input parameters, and I have neither time, nor motivation not to mention
skills to figure that out, so there will be no test cases for this
function form me afterall.


FWIW, we've had these situations elsewhere before as well, in swscale,
where the existing x86 assembly mismatches the C code in nontrivial ways,
and we have new assembly (aarch64 in that case) that is missing a test
(even if one was written) due to this.

First I considered if we should collect these extra checkasm tests in some
branch somewhere, so they aren't lost, as they are useful when working on
assembly on other architectures.

But rather than having the code rot, forgotten in a stray branch
somewhere, I wonder if we should just go ahead and merge it with an #if
!ARCH_X86 or something, together with a notable FIXME comment.


I'd certainly welcome more checkasm that literally anyone other than me wrote.
If the divergence in the X86 code is simply due to optimising an inexact
algorithm differently, that seems fine.

But if it is a case that the X86 code is demonstrably buggy, I think that it
should be commented out or removed. That would not only fix a bug, but also put
stronger incentives for X68 fanboys to actually fix it. Worst case, the
optimisation has become meaningless and we have actually fixed a bug.


I looked at the sse2 implementation briefly and it may in fact be buggy.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

2023-12-18 Thread Anton Khirnov
Quoting Stefano Sabatini (2023-12-16 16:18:07)
> On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
> > Anton Khirnov (12023-12-14):
> [...]
> > > I have to strongly disagree. This is neither practically workable,
> > > nor a good goal to aim at.
> > 
> > And I strongly agree with Stefano. Having the tools just thin wrappers
> > around the libraries is the only way to ensure the libraries are
> > maximally useful for other applications. Otherwise, useful code will
> > only reside in the tools and be only available through a clumsy
> > command-line interface.
> > 
> > >This mindset IMO inevitably leads to (among
> > > other problems):
> 
> > > * endless scope creep
> 
> Scope creep is a general tendency in software, as it tends to grow
> with more functionality and use cases in mind (FFmpeg itself started
> as an MPEG decoder). OTOH there is good and bad scope creep, it is bad
> if the functionality goes beyond the original design and core use
> case, or if the extension is not carefully designed and suffers from
> assumptions which limit how the software can be used. For example,
> making constraints about where the main thread can be executed.
> 
> (Unrelated note: I greatly appreciate Anton's threaded architecture
> endeavor, and I'm fine with the idea that something can result broken
> as a consequence of a major redesign, but I also think we should fix
> what can be fixed rather than just dismiss that as "not useful".

The entire question here is whether SDL muxing is useful enough to
warrant massive hacks in ffmpeg CLI.

> > > * bloated, inefficient, and buggy libraries, trying (and failing) to
> > >   support every use case under the sun
> 
> > > * myopic API design aimed at fulfilling the needs of precisely one
> > >   caller; this is a problem e.g avfilter badly suffers from, and to a
> > >   lesser extent avformat
> 
> Note that these two statements conflicting. If you try to support most
> of the use cases, it will be flexible by definition. For example, if
> we design the API to be only usable from ffmpeg.c, it will be limited
> in scope and usefullness.

There is a subtle but important difference between
* an interface that goes out of its way to explicitly support a large
  number of specific usecases
* an interface that is generic and flexible enough to be applicable to a
  wide range of cases

The crucial distinction is that the first case is about your code doing
MORE, while the second is about doing LESS.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/8] avutil: introduce an Immersive Audio Model and Formats API

2023-12-18 Thread James Almer

On 12/18/2023 8:04 AM, Anton Khirnov wrote:

Quoting James Almer (2023-12-14 21:14:26)

+/**
+ * Mix Gain Parameter Data as defined in section 3.8.1 of IAMF.
+ */
+typedef struct AVIAMFMixGain {
+const AVClass *av_class;
+
+/**
+ * Duration for the given subblock. It must not be 0.


In what units? Same for all durations in this patch.


parameter_rate. Amended.




+typedef struct AVIAMFParamDefinition {
+const AVClass *av_class;
+
+/**
+ * Offset in bytes from the start of this struct, at which the subblocks
+ * array is located.
+ */
+size_t subblocks_offset;
+/**
+ * Size in bytes of each element in the subblocks array.
+ */
+size_t subblock_size;
+/**
+ * Number of subblocks in the array.
+ *
+ * Must be 0 if @ref constant_subblock_duration is not 0.


Removed this line as it's bogus.


+ */
+unsigned int nb_subblocks;
+
+/**
+ * Parameters type. Determines the type of the subblock elements.
+ */
+enum AVIAMFParamDefinitionType type;
+
+/**
+ * Identifier for the paremeter substream.
+ */
+unsigned int parameter_id;
+/**
+ * Sample rate for the paremeter substream. It must not be 0.
+ */
+unsigned int parameter_rate;
+
+/**
+ * The duration of the all subblocks in this parameter definition.
+ *
+ * May be 0, in which case all duration values should be specified in
+ * another parameter definition referencing the same parameter_id.
+ */
+unsigned int duration;
+/**
+ * The duration of every subblock in the case where all subblocks, with
+ * the optional exception of the last subblock, have equal durations.
+ *
+ * Must be 0 if subblocks have different durations.
+ */
+unsigned int constant_subblock_duration;


This also seems like should be a flags field.


No, duration and subblock duration are not the same thing. The former is 
the accumulated duration of all subblocks in a given parameter 
definition. subblock durations can be smaller, and only if they are 
constant will constant_subblock_duration be set to a value other than 0.




Otherwise looks good.



Pushed. Thanks a lot for looking at it.
___
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] mlp: move pack_output pointer to decoder context

2023-12-18 Thread Rémi Denis-Courmont
The current pack_output function pointer is a property of the decoder,
rather than a constant method provided by the DSP code. Indeed, except
for an unused initialisation, the field is never used in DSP code.
---
 libavcodec/mlpdec.c | 48 ++---
 libavcodec/mlpdsp.c |  1 -
 libavcodec/mlpdsp.h |  8 
 3 files changed, 28 insertions(+), 29 deletions(-)

diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
index 18e0f47864..ead5ecee76 100644
--- a/libavcodec/mlpdec.c
+++ b/libavcodec/mlpdec.c
@@ -173,6 +173,14 @@ typedef struct MLPDecodeContext {
 DECLARE_ALIGNED(32, int32_t, sample_buffer)[MAX_BLOCKSIZE][MAX_CHANNELS];
 
 MLPDSPContext dsp;
+int32_t (*pack_output)(int32_t lossless_check_data,
+   uint16_t blockpos,
+   int32_t (*sample_buffer)[MAX_CHANNELS],
+   void *data,
+   uint8_t *ch_assign,
+   int8_t *output_shift,
+   uint8_t max_matrix_channel,
+   int is32);
 } MLPDecodeContext;
 
 static const enum AVChannel thd_channel_order[] = {
@@ -422,10 +430,10 @@ static int read_major_sync(MLPDecodeContext *m, 
GetBitContext *gb)
 m->avctx->sample_fmt = AV_SAMPLE_FMT_S32;
 else
 m->avctx->sample_fmt = AV_SAMPLE_FMT_S16;
-m->dsp.mlp_pack_output = 
m->dsp.mlp_select_pack_output(m->substream[m->max_decoded_substream].ch_assign,
-   
m->substream[m->max_decoded_substream].output_shift,
-   
m->substream[m->max_decoded_substream].max_matrix_channel,
-   
m->avctx->sample_fmt == AV_SAMPLE_FMT_S32);
+m->pack_output = 
m->dsp.mlp_select_pack_output(m->substream[m->max_decoded_substream].ch_assign,
+   
m->substream[m->max_decoded_substream].output_shift,
+   
m->substream[m->max_decoded_substream].max_matrix_channel,
+   m->avctx->sample_fmt == 
AV_SAMPLE_FMT_S32);
 
 m->params_valid = 1;
 for (substr = 0; substr < MAX_SUBSTREAMS; substr++)
@@ -663,10 +671,10 @@ static int read_restart_header(MLPDecodeContext *m, 
GetBitContext *gbp,
 if (substr == m->max_decoded_substream) {
 av_channel_layout_uninit(&m->avctx->ch_layout);
 av_channel_layout_from_mask(&m->avctx->ch_layout, s->mask);
-m->dsp.mlp_pack_output = m->dsp.mlp_select_pack_output(s->ch_assign,
-   s->output_shift,
-   
s->max_matrix_channel,
-   
m->avctx->sample_fmt == AV_SAMPLE_FMT_S32);
+m->pack_output = m->dsp.mlp_select_pack_output(s->ch_assign,
+   s->output_shift,
+   s->max_matrix_channel,
+   m->avctx->sample_fmt == 
AV_SAMPLE_FMT_S32);
 
 if (m->avctx->codec_id == AV_CODEC_ID_MLP && m->needs_reordering) {
 if (s->mask == (AV_CH_LAYOUT_QUAD|AV_CH_LOW_FREQUENCY) ||
@@ -925,10 +933,10 @@ static int read_decoding_params(MLPDecodeContext *m, 
GetBitContext *gbp,
 }
 }
 if (substr == m->max_decoded_substream)
-m->dsp.mlp_pack_output = 
m->dsp.mlp_select_pack_output(s->ch_assign,
-   
s->output_shift,
-   
s->max_matrix_channel,
-   
m->avctx->sample_fmt == AV_SAMPLE_FMT_S32);
+m->pack_output = m->dsp.mlp_select_pack_output(s->ch_assign,
+   s->output_shift,
+   
s->max_matrix_channel,
+   
m->avctx->sample_fmt == AV_SAMPLE_FMT_S32);
 }
 
 if (s->param_presence_flags & PARAM_QUANTSTEP)
@@ -1155,14 +1163,14 @@ static int output_data(MLPDecodeContext *m, unsigned 
int substr,
 frame->nb_samples = s->blockpos;
 if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
 return ret;
-s->lossless_check_data = m->dsp.mlp_pack_output(s->lossless_check_data,
-s->blockpos,
-m->sample_buffer,
-frame->data[0],
-s->ch_assign,
-   

Re: [FFmpeg-devel] [PATCH 0/1] fftools/ffprobe: dump contents of the AV_FRAME_DATA_SEI_UNREGISTERED

2023-12-18 Thread Kieran Kunhya
On Mon, 18 Dec 2023 at 14:59, Petr Matousek 
wrote:

> Before this patch being applied the ffprobe just tells the user whether
> the H.26[45] User Data Unregistered SEI message is present in the frame
> side data
> or not. After the patch being appliend it also dumps the contents of the
> data
> similar way as for the other already supported frame side data types.
>
> Petr Matousek (1):
>   fftools/ffprobe: dump contents of the AV_FRAME_DATA_SEI_UNREGISTERED
>

I don't think ffprobe should be dumping potentially large amounts of random
SEI data to the terminal. Some encoders use this space for their own data
and it's annoying to see it spam the terminal.

Kieran
___
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] fftools/ffmpeg_demux: set discard on the AVStream directly

2023-12-18 Thread Anton Khirnov
Avoid taking an ugly detour through the decoder AVCodecContext.
---
 fftools/ffmpeg_demux.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index eca3de709c..a28a94b5ed 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -1141,7 +1141,6 @@ static int ist_add(const OptionsContext *o, Demuxer *d, 
AVStream *st)
 ist->reinit_filters = -1;
 MATCH_PER_STREAM_OPT(reinit_filters, i, ist->reinit_filters, ic, st);
 
-MATCH_PER_STREAM_OPT(discard, str, discard_str, ic, st);
 ist->user_set_discard = AVDISCARD_NONE;
 
 if ((o->video_disable && ist->st->codecpar->codec_type == 
AVMEDIA_TYPE_VIDEO) ||
@@ -1150,20 +1149,20 @@ static int ist_add(const OptionsContext *o, Demuxer *d, 
AVStream *st)
 (o->data_disable && ist->st->codecpar->codec_type == 
AVMEDIA_TYPE_DATA))
 ist->user_set_discard = AVDISCARD_ALL;
 
-ist->dec_ctx = avcodec_alloc_context3(ist->dec);
-if (!ist->dec_ctx)
-return AVERROR(ENOMEM);
-
+MATCH_PER_STREAM_OPT(discard, str, discard_str, ic, st);
 if (discard_str) {
-const AVOption *discard_opt = av_opt_find(ist->dec_ctx, "skip_frame",
-  NULL, 0, 0);
-ret = av_opt_eval_int(ist->dec_ctx, discard_opt, discard_str, 
&ist->user_set_discard);
+ret = av_opt_set(ist->st, "discard", discard_str, 0);
 if (ret  < 0) {
 av_log(ist, AV_LOG_ERROR, "Error parsing discard %s.\n", 
discard_str);
 return ret;
 }
+ist->user_set_discard = ist->st->discard;
 }
 
+ist->dec_ctx = avcodec_alloc_context3(ist->dec);
+if (!ist->dec_ctx)
+return AVERROR(ENOMEM);
+
 ret = avcodec_parameters_to_context(ist->dec_ctx, par);
 if (ret < 0) {
 av_log(ist, AV_LOG_ERROR, "Error initializing the decoder context.\n");
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 1/2] lavf: allow setting AVStream.discard as an AVOption

2023-12-18 Thread Anton Khirnov
---
 libavformat/options.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavformat/options.c b/libavformat/options.c
index bf6113ca95..cc89dd6c72 100644
--- a/libavformat/options.c
+++ b/libavformat/options.c
@@ -229,6 +229,16 @@ static const AVOption stream_options[] = {
 { "metadata",   .type = AV_OPT_TYPE_CONST, { .i64 = 
AV_DISPOSITION_METADATA  },.unit = "disposition" },
 { "dependent",  .type = AV_OPT_TYPE_CONST, { .i64 = 
AV_DISPOSITION_DEPENDENT },.unit = "disposition" },
 { "still_image",.type = AV_OPT_TYPE_CONST, { .i64 = 
AV_DISPOSITION_STILL_IMAGE   },.unit = "disposition" },
+
+{ "discard", NULL, offsetof(AVStream, discard), AV_OPT_TYPE_INT, { .i64 = 
AVDISCARD_DEFAULT }, INT_MIN, INT_MAX,
+.flags = AV_OPT_FLAG_DECODING_PARAM, .unit = "avdiscard" },
+{ "none",   .type = AV_OPT_TYPE_CONST, {.i64 = 
AVDISCARD_NONE }, .unit = "avdiscard" },
+{ "default",.type = AV_OPT_TYPE_CONST, {.i64 = 
AVDISCARD_DEFAULT  }, .unit = "avdiscard" },
+{ "noref",  .type = AV_OPT_TYPE_CONST, {.i64 = 
AVDISCARD_NONREF   }, .unit = "avdiscard" },
+{ "bidir",  .type = AV_OPT_TYPE_CONST, {.i64 = 
AVDISCARD_BIDIR}, .unit = "avdiscard" },
+{ "nointra",.type = AV_OPT_TYPE_CONST, {.i64 = 
AVDISCARD_NONINTRA }, .unit = "avdiscard" },
+{ "nokey",  .type = AV_OPT_TYPE_CONST, {.i64 = 
AVDISCARD_NONKEY   }, .unit = "avdiscard" },
+{ "all",.type = AV_OPT_TYPE_CONST, {.i64 = 
AVDISCARD_ALL  }, .unit = "avdiscard" },
 { NULL }
 };
 
-- 
2.42.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/2] lavf: allow setting AVStream.discard as an AVOption

2023-12-18 Thread James Almer

On 12/18/2023 4:19 PM, Anton Khirnov wrote:

---
  libavformat/options.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/libavformat/options.c b/libavformat/options.c
index bf6113ca95..cc89dd6c72 100644
--- a/libavformat/options.c
+++ b/libavformat/options.c
@@ -229,6 +229,16 @@ static const AVOption stream_options[] = {
  { "metadata",   .type = AV_OPT_TYPE_CONST, { .i64 = 
AV_DISPOSITION_METADATA  },.unit = "disposition" },
  { "dependent",  .type = AV_OPT_TYPE_CONST, { .i64 = 
AV_DISPOSITION_DEPENDENT },.unit = "disposition" },
  { "still_image",.type = AV_OPT_TYPE_CONST, { .i64 = 
AV_DISPOSITION_STILL_IMAGE   },.unit = "disposition" },
+
+{ "discard", NULL, offsetof(AVStream, discard), AV_OPT_TYPE_INT, { .i64 = 
AVDISCARD_DEFAULT }, INT_MIN, INT_MAX,
+.flags = AV_OPT_FLAG_DECODING_PARAM, .unit = "avdiscard" },
+{ "none",   .type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONE }, 
.unit = "avdiscard" },
+{ "default",.type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_DEFAULT  }, 
.unit = "avdiscard" },
+{ "noref",  .type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONREF   }, 
.unit = "avdiscard" },
+{ "bidir",  .type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_BIDIR}, 
.unit = "avdiscard" },
+{ "nointra",.type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONINTRA }, 
.unit = "avdiscard" },
+{ "nokey",  .type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONKEY   }, 
.unit = "avdiscard" },
+{ "all",.type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_ALL  }, 
.unit = "avdiscard" },
  { NULL }
  };


Should be ok.

Maybe also add "id" like i did for AVStreamGroup while at it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

2023-12-18 Thread Michael Niedermayer
On Mon, Dec 18, 2023 at 06:33:45PM +0100, Anton Khirnov wrote:
> Quoting Stefano Sabatini (2023-12-16 16:18:07)
> > On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
> > > Anton Khirnov (12023-12-14):
> > [...]
> > > > I have to strongly disagree. This is neither practically workable,
> > > > nor a good goal to aim at.
> > > 
> > > And I strongly agree with Stefano. Having the tools just thin wrappers
> > > around the libraries is the only way to ensure the libraries are
> > > maximally useful for other applications. Otherwise, useful code will
> > > only reside in the tools and be only available through a clumsy
> > > command-line interface.
> > > 
> > > >  This mindset IMO inevitably leads to (among
> > > > other problems):
> > 
> > > > * endless scope creep
> > 
> > Scope creep is a general tendency in software, as it tends to grow
> > with more functionality and use cases in mind (FFmpeg itself started
> > as an MPEG decoder). OTOH there is good and bad scope creep, it is bad
> > if the functionality goes beyond the original design and core use
> > case, or if the extension is not carefully designed and suffers from
> > assumptions which limit how the software can be used. For example,
> > making constraints about where the main thread can be executed.
> > 
> > (Unrelated note: I greatly appreciate Anton's threaded architecture
> > endeavor, and I'm fine with the idea that something can result broken
> > as a consequence of a major redesign, but I also think we should fix
> > what can be fixed rather than just dismiss that as "not useful".
> 
> The entire question here is whether SDL muxing is useful enough to
> warrant massive hacks in ffmpeg CLI.

I think the first question is, does this actually need
"massive hacks in ffmpeg CLI" ?

If you ignore the recommandition that SDL should be run from the main
thread then iam not sure what change would be needed in ffmpeg CLI at all.

If you do want to run it in the main thread, well theres the option
for the muxer to launch a seperate process by some way internally.
then it has its own main thread (not great but its a clean solution)

teh 2nd question is, is SDL the only thing requireing "main thread" or
some "single thread" or other limitation ?
does any other decoder, encoder, muxer, demuxer, filter ... use an
external lib thats not fully thread safe ? or has funny limitations ?

The last option would maybe be to run some sort of AVExecutor on the
main thread and allow things like muxers to que operations on it.
The  muxers would totally unchanged be running on a random thread
but que some operation on the main thread if an external lib, driver or
other needs it.
Naively that feels relatively clean to me

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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] [RFC] fftools/ffmpeg and libavdevice/sdl issue

2023-12-18 Thread Nicolas George
Michael Niedermayer (12023-12-18):
> I think the first question is, does this actually need
> "massive hacks in ffmpeg CLI" ?

Thank you for bringing some sanity.

> If you ignore the recommandition that SDL should be run from the main
> thread then iam not sure what change would be needed in ffmpeg CLI at all.

I must say, I am very dubious about the statement. It is probably an
over-simplification for “in the same thread” with caveats.

> The last option would maybe be to run some sort of AVExecutor on the
> main thread and allow things like muxers to que operations on it.
> The  muxers would totally unchanged be running on a random thread
> but que some operation on the main thread if an external lib, driver or
> other needs it.
> Naively that feels relatively clean to me

Of course. Having that kind of mechanism is obviously necessary anyway.

Regards,

-- 
  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] gdigrab: Fix hwnd parameter issues

2023-12-18 Thread James Almer

On 12/18/2023 5:54 AM, Martin Storsjö wrote:

Converting from an integer to HWND (which is a pointer) requires
an explicit cast, otherwise Clang errors out like this:

 src/libavdevice/gdigrab.c:280:14: error: incompatible integer to pointer 
conversion assigning to 'HWND' (aka 'struct HWND__ *') from 'long' 
[-Wint-conversion]
   280 | hwnd = strtol(name, &p, 0);
   |  ^ ~~~

(With GCC and MSVC, this was a mere warning, but with recent Clang,
this is an error.)

After adding a cast, all compilers also warn something like this:

 src/libavdevice/gdigrab.c:280:16: warning: cast to 'HWND' (aka 'struct 
HWND__ *') from smaller integer type 'long' [-Wint-to-pointer-cast]
   280 | hwnd = (HWND) strtol(name, &p, 0);
   |^~

On Windows, long types are 32 bit, so to get a usable pointer, we
need to use long long. And interpret it as unsigned long long
while at it - i.e. using strtoull.

Finally, right above it, the code triggered the following warning:

 src/libavdevice/gdigrab.c:278:15: warning: mixing declarations and code is 
incompatible with standards before C99 [-Wdeclaration-after-statement]
   278 | char *p;
   |   ^
---
  libavdevice/gdigrab.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index 41ef370f2b..b2858ecd89 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -274,10 +274,10 @@ gdigrab_read_header(AVFormatContext *s1)
  } else if (!strcmp(filename, "desktop")) {
  hwnd = NULL;
  } else if (!strncmp(filename, "hwnd=", 5)) {
-name = filename + 5;
  char *p;
+name = filename + 5;
  
-hwnd = strtol(name, &p, 0);

+hwnd = (HWND) strtoull(name, &p, 0);
  
  if (p == NULL || p == name || p[0] == '\0')

  {


Should be ok.
___
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] gdigrab: Fix hwnd parameter issues

2023-12-18 Thread Stefano Sabatini
On date Monday 2023-12-18 19:05:17 -0300, James Almer wrote:
> On 12/18/2023 5:54 AM, Martin Storsjö wrote:
> > Converting from an integer to HWND (which is a pointer) requires
> > an explicit cast, otherwise Clang errors out like this:
> > 
> >  src/libavdevice/gdigrab.c:280:14: error: incompatible integer to 
> > pointer conversion assigning to 'HWND' (aka 'struct HWND__ *') from 'long' 
> > [-Wint-conversion]
> >280 | hwnd = strtol(name, &p, 0);
> >|  ^ ~~~
> > 
> > (With GCC and MSVC, this was a mere warning, but with recent Clang,
> > this is an error.)
> > 
> > After adding a cast, all compilers also warn something like this:
> > 
> >  src/libavdevice/gdigrab.c:280:16: warning: cast to 'HWND' (aka 'struct 
> > HWND__ *') from smaller integer type 'long' [-Wint-to-pointer-cast]
> >280 | hwnd = (HWND) strtol(name, &p, 0);
> >|^~
> > 
> > On Windows, long types are 32 bit, so to get a usable pointer, we
> > need to use long long. And interpret it as unsigned long long
> > while at it - i.e. using strtoull.
> > 
> > Finally, right above it, the code triggered the following warning:
> > 
> >  src/libavdevice/gdigrab.c:278:15: warning: mixing declarations and 
> > code is incompatible with standards before C99 
> > [-Wdeclaration-after-statement]
> >278 | char *p;
> >|   ^
> > ---
> >   libavdevice/gdigrab.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
> > index 41ef370f2b..b2858ecd89 100644
> > --- a/libavdevice/gdigrab.c
> > +++ b/libavdevice/gdigrab.c
> > @@ -274,10 +274,10 @@ gdigrab_read_header(AVFormatContext *s1)
> >   } else if (!strcmp(filename, "desktop")) {
> >   hwnd = NULL;
> >   } else if (!strncmp(filename, "hwnd=", 5)) {
> > -name = filename + 5;
> >   char *p;
> > +name = filename + 5;
> > -hwnd = strtol(name, &p, 0);
> > +hwnd = (HWND) strtoull(name, &p, 0);
> >   if (p == NULL || p == name || p[0] == '\0')
> >   {
> 
> Should be ok.

Also LGTM, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] lavc/libopenh264: Drop openh264 runtime version checks

2023-12-18 Thread Martin Storsjö

On Sat, 9 Dec 2023, Kalev Lember wrote:


With the way the runtime checks are currently set up, every single
openh264 release, no matter how minor, is considered an ABI break and
requires ffmpeg recompilation. This is unnecessarily strict because it
doesn't allow downstream distributions to ship any openh264 bug fix
version updates without breaking ffmpeg's openh264 support.

Years ago, at the time when ffmpeg's openh264 support was merged,
openh264 releases were done without a versioned soname (the library was
just libopenh264.so, unversioned). Since then, starting with version
1.3.0, openh264 has started using versioned sonames and the intent has
been to bump the soname every time there's a new release with an ABI
change.

This patch drops the exact version check and instead adds a minimum
requirement on 1.3.0 to the configure script.

Signed-off-by: Kalev Lember 
---


Thanks, pushed now!

// Martin

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] gdigrab: Fix hwnd parameter issues

2023-12-18 Thread Martin Storsjö

On Mon, 18 Dec 2023, Stefano Sabatini wrote:


On date Monday 2023-12-18 19:05:17 -0300, James Almer wrote:

On 12/18/2023 5:54 AM, Martin Storsjö wrote:

Converting from an integer to HWND (which is a pointer) requires
an explicit cast, otherwise Clang errors out like this:

 src/libavdevice/gdigrab.c:280:14: error: incompatible integer to pointer 
conversion assigning to 'HWND' (aka 'struct HWND__ *') from 'long' 
[-Wint-conversion]
   280 | hwnd = strtol(name, &p, 0);
   |  ^ ~~~

(With GCC and MSVC, this was a mere warning, but with recent Clang,
this is an error.)

After adding a cast, all compilers also warn something like this:

 src/libavdevice/gdigrab.c:280:16: warning: cast to 'HWND' (aka 'struct 
HWND__ *') from smaller integer type 'long' [-Wint-to-pointer-cast]
   280 | hwnd = (HWND) strtol(name, &p, 0);
   |^~

On Windows, long types are 32 bit, so to get a usable pointer, we
need to use long long. And interpret it as unsigned long long
while at it - i.e. using strtoull.

Finally, right above it, the code triggered the following warning:

 src/libavdevice/gdigrab.c:278:15: warning: mixing declarations and code is 
incompatible with standards before C99 [-Wdeclaration-after-statement]
   278 | char *p;
   |   ^
---
  libavdevice/gdigrab.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index 41ef370f2b..b2858ecd89 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -274,10 +274,10 @@ gdigrab_read_header(AVFormatContext *s1)
  } else if (!strcmp(filename, "desktop")) {
  hwnd = NULL;
  } else if (!strncmp(filename, "hwnd=", 5)) {
-name = filename + 5;
  char *p;
+name = filename + 5;
-hwnd = strtol(name, &p, 0);
+hwnd = (HWND) strtoull(name, &p, 0);
  if (p == NULL || p == name || p[0] == '\0')
  {


Should be ok.


Also LGTM, thanks.


Pushed now, thanks!

// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 22/35] avcodec/proresenc_anatoliy: remove IS_NEGATIVE() macro

2023-12-18 Thread Stefano Sabatini
On date Monday 2023-12-11 02:35:23 +0100, Clément Bœsch wrote:
> This makes the function closer to encode_acs() in proresenc_kostya.
> ---
>  libavcodec/proresenc_anatoliy.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
> index 4ea3d89126..43dee7f79b 100644
> --- a/libavcodec/proresenc_anatoliy.c
> +++ b/libavcodec/proresenc_anatoliy.c
> @@ -257,7 +257,6 @@ static void encode_vlc_codeword(PutBitContext *pb, 
> unsigned codebook, int val)
>  
>  #define GET_SIGN(x)  ((x) >> 31)
>  #define TO_GOLOMB(val) (((val) * 2) ^ GET_SIGN(val))
> -#define IS_NEGATIVE(val) ((GET_SIGN(val) ^ -1) + 1)
>  #define TO_GOLOMB2(val,sign) ((val)==0 ? 0 : ((val) << 1) + (sign))
>  
>  static av_always_inline int get_level(int val)
> @@ -318,7 +317,7 @@ static void encode_ac_coeffs(PutBitContext *pb,
>  
>  prev_level = level;
>  
> -put_bits(pb, 1, IS_NEGATIVE(val));
> +put_sbits(pb, 1, GET_SIGN(val));

Should be good.
___
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 23/35] avcodec/proresenc_kostya: add Anatoliy copyright

2023-12-18 Thread Stefano Sabatini
On date Monday 2023-12-11 02:35:24 +0100, Clément Bœsch wrote:
> Both encoders share a lot of code from both authors.
> ---
>  libavcodec/proresenc_kostya.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
> index e0aa7cf47a..c6c045be73 100644
> --- a/libavcodec/proresenc_kostya.c
> +++ b/libavcodec/proresenc_kostya.c
> @@ -1,6 +1,7 @@
>  /*
>   * Apple ProRes encoder
>   *
> + * Copyright (c) 2011 Anatoliy Wasserman
>   * Copyright (c) 2012 Konstantin Shishkov
>   *
>   * This encoder appears to be based on Anatoliy Wassermans considering
> -- 
> 2.43.0

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".


Re: [FFmpeg-devel] [PATCH 24/35] avcodec/proresenc_anatoliy: rename TO_GOLOMB() to MAKE_CODE()

2023-12-18 Thread Stefano Sabatini
On date Monday 2023-12-11 02:35:25 +0100, Clément Bœsch wrote:
> This matches the name in proresenc_kostya.
> ---
>  libavcodec/proresenc_anatoliy.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
> index 43dee7f79b..4b72798689 100644
> --- a/libavcodec/proresenc_anatoliy.c
> +++ b/libavcodec/proresenc_anatoliy.c
> @@ -256,7 +256,7 @@ static void encode_vlc_codeword(PutBitContext *pb, 
> unsigned codebook, int val)
>  }
>  
>  #define GET_SIGN(x)  ((x) >> 31)
> -#define TO_GOLOMB(val) (((val) * 2) ^ GET_SIGN(val))
> +#define MAKE_CODE(x) (((x) * 2) ^ GET_SIGN(x))
>  #define TO_GOLOMB2(val,sign) ((val)==0 ? 0 : ((val) << 1) + (sign))

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".


Re: [FFmpeg-devel] [PATCH 25/35] avcodec/proresenc_anatoliy: shuffle declarations around in encode_dcs()

2023-12-18 Thread Stefano Sabatini
On date Monday 2023-12-11 02:35:26 +0100, Clément Bœsch wrote:
> This makes the function closer to the same function in proresenc_kostya.
> ---
>  libavcodec/proresenc_anatoliy.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)

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".


Re: [FFmpeg-devel] [PATCH 26/35] avcodec/proresenc_anatoliy: only pass down the first scale to encode_dcs()

2023-12-18 Thread Stefano Sabatini
On date Monday 2023-12-11 02:35:27 +0100, Clément Bœsch wrote:
> This matches encode_dcs() prototype from proresenc_kostya.
> ---
>  libavcodec/proresenc_anatoliy.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

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".


Re: [FFmpeg-devel] [PATCH] avcodec/v4l2_m2m: Remove unnecessary unref before frame_free

2023-12-18 Thread Andreas Rheinhardt
Zhao Zhili:
> From: Zhao Zhili 
> 
> Signed-off-by: Zhao Zhili 
> ---
>  libavcodec/v4l2_m2m.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
> index 602efb7a16..bac3eb0588 100644
> --- a/libavcodec/v4l2_m2m.c
> +++ b/libavcodec/v4l2_m2m.c
> @@ -255,7 +255,6 @@ static void v4l2_m2m_destroy_context(void *opaque, 
> uint8_t *context)
>  
>  if (s->fd >= 0)
>  close(s->fd);
> -av_frame_unref(s->frame);
>  av_frame_free(&s->frame);
>  av_packet_unref(&s->buf_pkt);
>  

Reminds me of
https://patchwork.ffmpeg.org/project/ffmpeg/patch/as8p250mb07441537d335e4657926df368f...@as8p250mb0744.eurp250.prod.outlook.com/

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 0/1] fftools/ffprobe: dump contents of the AV_FRAME_DATA_SEI_UNREGISTERED

2023-12-18 Thread Stefano Sabatini
On date Monday 2023-12-18 14:58:58 +, Petr Matousek wrote:
> Before this patch being applied the ffprobe just tells the user whether
> the H.26[45] User Data Unregistered SEI message is present in the frame side 
> data

> or not. After the patch being appliend it also dumps the contents of the data

appliend typo

> similar way as for the other already supported frame side data types.

What's the use case for this?

I wonder if we should employ some more generic mechanism, e.g. a
filter moving side data to metadata for display.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH] fftools/ffplay: split filters & show modes cycling into separate keys

2023-12-18 Thread Ondřej Fiala
---
It's annoying to have to go through the audio visualization modes when you
just want to switch back-and-forth between two video filters. It also makes
the code simpler.

 doc/ffplay.texi  |  5 -
 fftools/ffplay.c | 10 --
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index 93f77eeece..91d138a974 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -241,8 +241,11 @@ Cycle subtitle channel in the current program.
 @item c
 Cycle program.
 
+@item d
+Cycle show modes.
+
 @item w
-Cycle video filters or show modes.
+Cycle video filters.
 
 @item s
 Step to the next frame.
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 873ee8cc74..2eb616a88a 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -3370,14 +3370,12 @@ static void event_loop(VideoState *cur_stream)
 case SDLK_t:
 stream_cycle_channel(cur_stream, AVMEDIA_TYPE_SUBTITLE);
 break;
+case SDLK_d:
+toggle_audio_display(cur_stream);
+break;
 case SDLK_w:
-if (cur_stream->show_mode == SHOW_MODE_VIDEO && 
cur_stream->vfilter_idx < nb_vfilters - 1) {
-if (++cur_stream->vfilter_idx >= nb_vfilters)
-cur_stream->vfilter_idx = 0;
-} else {
+if (++cur_stream->vfilter_idx >= nb_vfilters)
 cur_stream->vfilter_idx = 0;
-toggle_audio_display(cur_stream);
-}
 break;
 case SDLK_PAGEUP:
 if (cur_stream->ic->nb_chapters <= 1) {
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] avcodec/v4l2_m2m: Remove unnecessary unref before frame_free

2023-12-18 Thread Zhao Zhili



> On Dec 19, 2023, at 06:33, Andreas Rheinhardt 
>  wrote:
> 
> Zhao Zhili:
>> From: Zhao Zhili 
>> 
>> Signed-off-by: Zhao Zhili 
>> ---
>> libavcodec/v4l2_m2m.c | 1 -
>> 1 file changed, 1 deletion(-)
>> 
>> diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
>> index 602efb7a16..bac3eb0588 100644
>> --- a/libavcodec/v4l2_m2m.c
>> +++ b/libavcodec/v4l2_m2m.c
>> @@ -255,7 +255,6 @@ static void v4l2_m2m_destroy_context(void *opaque, 
>> uint8_t *context)
>> 
>> if (s->fd >= 0)
>> close(s->fd);
>> -av_frame_unref(s->frame);
>> av_frame_free(&s->frame);
>> av_packet_unref(&s->buf_pkt);
>> 
> 
> Reminds me of
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/as8p250mb07441537d335e4657926df368f...@as8p250mb0744.eurp250.prod.outlook.com/

Then please push.

> 
> - Andreas
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org 
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org  with 
> subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] fftools/ffplay: split filters & show modes cycling into separate keys

2023-12-18 Thread Zhao Zhili

> On Dec 19, 2023, at 10:02, Ondřej Fiala  wrote:
> 
> ---
> It's annoying to have to go through the audio visualization modes when you
> just want to switch back-and-forth between two video filters. It also makes
> the code simpler.
> 
> doc/ffplay.texi  |  5 -
> fftools/ffplay.c | 10 --
> 2 files changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/ffplay.texi b/doc/ffplay.texi
> index 93f77eeece..91d138a974 100644
> --- a/doc/ffplay.texi
> +++ b/doc/ffplay.texi
> @@ -241,8 +241,11 @@ Cycle subtitle channel in the current program.
> @item c
> Cycle program.
> 
> +@item d
> +Cycle show modes.
> +
> @item w
> -Cycle video filters or show modes.
> +Cycle video filters.
> 
> @item s
> Step to the next frame.
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index 873ee8cc74..2eb616a88a 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -3370,14 +3370,12 @@ static void event_loop(VideoState *cur_stream)
> case SDLK_t:
> stream_cycle_channel(cur_stream, AVMEDIA_TYPE_SUBTITLE);
> break;
> +case SDLK_d:
> +toggle_audio_display(cur_stream);
> +break;
> case SDLK_w:
> -if (cur_stream->show_mode == SHOW_MODE_VIDEO && 
> cur_stream->vfilter_idx < nb_vfilters - 1) {
> -if (++cur_stream->vfilter_idx >= nb_vfilters)
> -cur_stream->vfilter_idx = 0;
> -} else {
> +if (++cur_stream->vfilter_idx >= nb_vfilters)
> cur_stream->vfilter_idx = 0;
> -toggle_audio_display(cur_stream);
> -}

Now it could be simplified as cur_stream->vfilter_idx = 
(cur_stream->vfilter_idx + 1) % nb_vfilters.

> break;
> case SDLK_PAGEUP:
> if (cur_stream->ic->nb_chapters <= 1) {
> -- 
> 2.43.0
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel 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] libavfilter/af_afir: R-V V dcmul_add

2023-12-18 Thread flow gg
c908:
dcmul_add_c: 88.0
dcmul_add_rvv_f64: 46.2

Did not use vlseg2e64, because it is much slower than vlse64
Did not use vsseg2e64, because it is slightly slower than vsse64
From 80b6694bc29ed1c37852dc079a6d91a24dd6f18e Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Tue, 19 Dec 2023 09:11:28 +0800
Subject: [PATCH] libavfilter/af_afir: R-V V dcmul_add

c908:
dcmul_add_c: 88.0
dcmul_add_rvv_f64: 46.2
---
 libavfilter/riscv/af_afir_init.c |  3 +++
 libavfilter/riscv/af_afir_rvv.S  | 41 
 2 files changed, 44 insertions(+)

diff --git a/libavfilter/riscv/af_afir_init.c b/libavfilter/riscv/af_afir_init.c
index 52aa18c126..f9a76f108b 100644
--- a/libavfilter/riscv/af_afir_init.c
+++ b/libavfilter/riscv/af_afir_init.c
@@ -27,6 +27,8 @@
 
 void ff_fcmul_add_rvv(float *sum, const float *t, const float *c,
ptrdiff_t len);
+void ff_dcmul_add_rvv(double *sum, const double *t, const double *c,
+   ptrdiff_t len);
 
 av_cold void ff_afir_init_riscv(AudioFIRDSPContext *s)
 {
@@ -36,6 +38,7 @@ av_cold void ff_afir_init_riscv(AudioFIRDSPContext *s)
 if (flags & AV_CPU_FLAG_RVV_F64) {
 if (flags & AV_CPU_FLAG_RVB_ADDR) {
 s->fcmul_add = ff_fcmul_add_rvv;
+s->dcmul_add = ff_dcmul_add_rvv;
 }
 }
 #endif
diff --git a/libavfilter/riscv/af_afir_rvv.S b/libavfilter/riscv/af_afir_rvv.S
index 04ec2e50d8..d1fa6e22e5 100644
--- a/libavfilter/riscv/af_afir_rvv.S
+++ b/libavfilter/riscv/af_afir_rvv.S
@@ -53,3 +53,44 @@ func ff_fcmul_add_rvv, zve64f
 
 ret
 endfunc
+
+func ff_dcmul_add_rvv, zve64f
+1:
+vsetvli   t0, a3, e64, m4, ta, ma
+lit1, 16
+lit2, 8
+vlse64.v  v0, (a1), t1
+add   a1, a1, t2
+vlse64.v  v4, (a2), t1
+add   a2, a2, t2
+vlse64.v  v12, (a0), t1
+add   a0, a0, t2
+vfmacc.vv v12, v0, v4
+sub   a3, a3, t0
+vlse64.v  v8, (a2), t1
+sub   a2, a2, t2
+sh3adda2, t0, a2
+vlse64.v  v16, (a0), t1
+sub   a0, a0, t2
+vfmacc.vv v16, v0, v8
+sh3adda2, t0, a2
+vlse64.v  v0, (a1), t1
+sub   a1, a1, t2
+sh3adda1, t0, a1
+vfnmsac.vvv12, v0, v8
+sh3adda1, t0, a1
+vfmacc.vv v16, v0, v4
+vsse64.v  v12, (a0), t1
+add   a0, a0, t2
+vsse64.v  v16, (a0), t1
+sub   a0, a0, t2
+sh3adda0, t0, a0
+sh3adda0, t0, a0
+bgtz  a3, 1b
+fld   fa0, 0(a1)
+fld   fa1, 0(a2)
+fld   fa2, 0(a0)
+fmadd.d   fa2, fa0, fa1, fa2
+fsd   fa2, 0(a0)
+ret
+endfunc
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v7 06/11] avformat: add demuxer and probe support for H266/VVC

2023-12-18 Thread Zhao Zhili


> On Dec 18, 2023, at 20:25, Nuo Mi  wrote:
> 
> On Mon, Dec 18, 2023 at 7:43 PM Zhao Zhili  wrote:
> 
>> 
>> 
>>> On Mar 21, 2023, at 23:01, Thomas Siedel 
>> wrote:
>>> 
>>> Add demuxer to probe raw vvc and parse vvcc byte stream format.
>>> 
>>> Co-authored-by: Nuo Mi 
>>> ---
>>> 
>> 
> 
> It will fix by
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231205094038.12293-1-p...@frankplowman.com/
> Could you help merge and backport to 6.1
> https://trac.ffmpeg.org/ticket/10703

Applied on master branch and cherry-picked to 6.1.

> 
> thank you.
> 
> 
>>> 
>>> ___
>>> 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".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v1] lavc/vaapi_encode_av1: Add qp option explicitly to set base q index

2023-12-18 Thread Wang, Fei W
On Tue, 2023-11-28 at 03:15 +, Xiang, Haihao wrote:
> On Ma, 2023-11-27 at 13:36 +, Mark Thompson wrote:
> > On 27/11/2023 00:58, fei.w.wang-at-intel@ffmpeg.org wrote:
> > > From: Fei Wang 
> > > 
> > > Keep same way with librav1e/libsvtav1/qsv_av1.. to make it more
> > > acceptable instead of using global option "-global_quality".
> > > 
> > > Fix #10615
> > > 
> > > Signed-off-by: Fei Wang 
> > > ---
> > >   doc/encoders.texi | 1 +
> > >   libavcodec/vaapi_encode_av1.c | 6 ++
> > >   2 files changed, 7 insertions(+)
> > > 
> > > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > > index 27a9acf076..2cffc32daf 100644
> > > --- a/doc/encoders.texi
> > > +++ b/doc/encoders.texi
> > > @@ -4079,6 +4079,7 @@ Each encoder also has its own specific
> > > options:
> > >   @table @option
> > >   
> > >   @item av1_vaapi
> > > +@option{qp} sets the value of @emph{base_q_index}.
> > >   @option{profile} sets the value of @emph{seq_profile}.
> > >   @option{tier} sets the value of @emph{seq_tier}.
> > >   @option{level} sets the value of @emph{seq_level_idx}.
> > > diff --git a/libavcodec/vaapi_encode_av1.c
> > > b/libavcodec/vaapi_encode_av1.c
> > > index 5a9ff0f798..2e327fec5a 100644
> > > --- a/libavcodec/vaapi_encode_av1.c
> > > +++ b/libavcodec/vaapi_encode_av1.c
> > > @@ -79,6 +79,7 @@ typedef struct VAAPIEncodeAV1Context {
> > >   int cdef_param_size;
> > >   
> > >   /** user options */
> > > +int qp;
> > >   int profile;
> > >   int level;
> > >   int tier;
> > > @@ -786,6 +787,9 @@ static av_cold int
> > > vaapi_encode_av1_init(AVCodecContext
> > > *avctx)
> > >   return AVERROR(EINVAL);
> > >   }
> > >   
> > > +if (priv->qp > 0)
> > > +ctx->explicit_qp = priv->qp;
> > > +
> > >   ret = ff_vaapi_encode_init(avctx);
> > >   if (ret < 0)
> > >   return ret;
> > > @@ -864,6 +868,8 @@ static av_cold int
> > > vaapi_encode_av1_close(AVCodecContext
> > > *avctx)
> > >   static const AVOption vaapi_encode_av1_options[] = {
> > >   VAAPI_ENCODE_COMMON_OPTIONS,
> > >   VAAPI_ENCODE_RC_OPTIONS,
> > > +{ "qp", "Base q index (for P-frames; scaled by
> > > qfactor/qoffset for
> > > I/B)",
> > > +  OFFSET(qp), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 255, FLAGS
> > > },
> > >   { "profile", "Set profile (seq_profile)",
> > > OFFSET(profile), AV_OPT_TYPE_INT,
> > > { .i64 = AV_PROFILE_UNKNOWN }, AV_PROFILE_UNKNOWN, 0xff,
> > > FLAGS,
> > > "profile" },
> > 
> > Disagree; QP is not a concept in AV1. 
> 
> Yes, it not a concept in AV1.
> 
> nvenc h264/hevc/av1 encoders provide the same qp option:
> 
> libavcodec/nvenc_av1.c:{ "qp",   "Constant quantization
> parameter
> rate control method",
> libavcodec/nvenc_h264.c:{ "qp",   "Constant quantization
> parameter
> rate control method",
> libavcodec/nvenc_hevc.c:{ "qp",   "Constant quantization
> parameter
> rate control method",
> 
> May we provide the same qp option for vaapi h264/hevc/av1 encoders
> too? User
> will be able to use same options when using these encoders.
> 
> Thanks
> Haihao
> 
> 
> >  Further, your examples from other encoders do not have a
> > consistent view of
> > what it should mean.

We may also assign different meaning for different VAAPI encoder in its
individual option description. And it may be more reasonable to use
"-qp" together with "-rc_mode CQP" and "-i/b_qfactor/qoffset" options.

Thanks
Fei


> > 
> > librav1e.c:
> > 
> >  { "qp", "use constant quantizer mode", OFFSET(quantizer),
> > AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 255, VE },
> > 
> > 0-255 is presumably the base_q_idx scale.
> > 
> > libsvtav1.c:
> > 
> >  { "qp", "Initial Quantizer level value", OFFSET(qp), 
> > AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 63, VE },
> > 
> > 0-63 is presumably the H.26x-qp-ish scale used by some VP9/AV1
> > encoders which
> > maps nonlinearly to the internal scale.
> > 
> > qsv_av1 doesn't seem to have such an option.
> > 
> > Thanks,
> > 
> > - Mark
> > ___
> > 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] [RFC] fftools/ffmpeg and libavdevice/sdl issue

2023-12-18 Thread Rémi Denis-Courmont


Le 18 décembre 2023 21:58:39 GMT+02:00, Michael Niedermayer 
 a écrit :
>On Mon, Dec 18, 2023 at 06:33:45PM +0100, Anton Khirnov wrote:
>> Quoting Stefano Sabatini (2023-12-16 16:18:07)
>> > On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
>> > > Anton Khirnov (12023-12-14):
>> > [...]
>> > > > I have to strongly disagree. This is neither practically workable,
>> > > > nor a good goal to aim at.
>> > > 
>> > > And I strongly agree with Stefano. Having the tools just thin wrappers
>> > > around the libraries is the only way to ensure the libraries are
>> > > maximally useful for other applications. Otherwise, useful code will
>> > > only reside in the tools and be only available through a clumsy
>> > > command-line interface.
>> > > 
>> > > > This mindset IMO inevitably leads to (among
>> > > > other problems):
>> > 
>> > > > * endless scope creep
>> > 
>> > Scope creep is a general tendency in software, as it tends to grow
>> > with more functionality and use cases in mind (FFmpeg itself started
>> > as an MPEG decoder). OTOH there is good and bad scope creep, it is bad
>> > if the functionality goes beyond the original design and core use
>> > case, or if the extension is not carefully designed and suffers from
>> > assumptions which limit how the software can be used. For example,
>> > making constraints about where the main thread can be executed.
>> > 
>> > (Unrelated note: I greatly appreciate Anton's threaded architecture
>> > endeavor, and I'm fine with the idea that something can result broken
>> > as a consequence of a major redesign, but I also think we should fix
>> > what can be fixed rather than just dismiss that as "not useful".
>> 
>> The entire question here is whether SDL muxing is useful enough to
>> warrant massive hacks in ffmpeg CLI.
>
>I think the first question is, does this actually need
>"massive hacks in ffmpeg CLI" ?

>If you ignore the recommandition that SDL should be run from the main
>thread then iam not sure what change would be needed in ffmpeg CLI at all.

As others noted earlier, that won't work for Mac and Windows.

>If you do want to run it in the main thread, well theres the option
>for the muxer to launch a seperate process by some way internally.

Starting a process from a library is not very practical. You need to locate the 
executable and the way to do that is different if you're working with a proper 
installation, or testing in the development tree.

I reckon that testing is a big motivation for the SDL code, so this can't be 
simply ignored.

And then you need an IPC, which is not portable, and not very different from 
the piping alternative proposal up-thread.

>then it has its own main thread (not great but its a clean solution)
>
>teh 2nd question is, is SDL the only thing requireing "main thread" or
>some "single thread" or other limitation ?

On Windows, it requires its own thread to use a single-threaded COM apartment. 
On Mac, it must run on the main thread to access GUI functionality. Main thread 
here means the initial thread in the address space.

>does any other decoder, encoder, muxer, demuxer, filter ... use an
>external lib thats not fully thread safe ? or has funny limitations ?

>The last option would maybe be to run some sort of AVExecutor on the
>main thread and allow things like muxers to que operations on it.
>The  muxers would totally unchanged be running on a random thread
>but que some operation on the main thread if an external lib, driver or
>other needs it.

To me, that counts as a horrible hack for a library to have, TBH. And if 
nothing other than SDL on Mac would even need this, then it's very much an 
ad-hoc kludge.

>Naively that feels relatively clean to me
>
>thx
>
>[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH v2 1/3] fftools/ffmpeg_filter: fix NULL pointer dereference

2023-12-18 Thread Zhao Zhili
From: Zhao Zhili 

In close_output(), a dummy frame is created with format NONE passed
to enc_open(), which doesn't prepare for it. The NULL pointer
dereference happened at
av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth.

When fgt.graph is NULL, skip fg_output_frame() since there is
nothing to output.

frame #0: 0x00bc34a4 ffmpeg_g`enc_open(opaque=0xb47efe2db690, 
frame=0xb47efe2d9f70) at ffmpeg_enc.c:235:44
frame #1: 0x00bef250 ffmpeg_g`enc_open(sch=0xb47dde2d4090, 
enc=0xb47e4e2daad0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:1462:11
frame #2: 0x00bee094 ffmpeg_g`send_to_enc(sch=0xb47dde2d4090, 
enc=0xb47e4e2daad0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:1571:19
frame #3: 0x00bee01c ffmpeg_g`sch_filter_send(sch=0xb47dde2d4090, 
fg_idx=0, out_idx=0, frame=0xb47efe2d9f70) at ffmpeg_sched.c:2154:12
frame #4: 0x00bcf124 ffmpeg_g`close_output(ofp=0xb47e4e2d85b0, 
fgt=0x007d1790eb08) at ffmpeg_filter.c:2225:15
frame #5: 0x00bcb000 ffmpeg_g`fg_output_frame(ofp=0xb47e4e2d85b0, 
fgt=0x007d1790eb08, frame=0x) at ffmpeg_filter.c:2317:16
frame #6: 0x00bc7e48 ffmpeg_g`filter_thread(arg=0xb47eae2ce7a0) at 
ffmpeg_filter.c:2836:15
frame #7: 0x00bee568 ffmpeg_g`task_wrapper(arg=0xb47d8e2db478) at 
ffmpeg_sched.c:2200:21
---
 fftools/ffmpeg_filter.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 9fc877b437..69a49a071e 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -2335,10 +2335,7 @@ static int fg_output_step(OutputFilterPriv *ofp, 
FilterGraphThread *fgt,
 
 ret = av_buffersink_get_frame_flags(filter, frame,
 AV_BUFFERSINK_FLAG_NO_REQUEST);
-if (ret == AVERROR_EOF && !fgt->eof_out[ofp->index]) {
-ret = fg_output_frame(ofp, fgt, NULL);
-return (ret < 0) ? ret : 1;
-} else if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF) {
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF) {
 return 1;
 } else if (ret < 0) {
 av_log(fgp, AV_LOG_WARNING,
@@ -2835,7 +2832,7 @@ read_frames:
 for (unsigned i = 0; i < fg->nb_outputs; i++) {
 OutputFilterPriv *ofp = ofp_from_ofilter(fg->outputs[i]);
 
-if (fgt.eof_out[i])
+if (fgt.eof_out[i] || !fgt.graph)
 continue;
 
 ret = fg_output_frame(ofp, &fgt, NULL);
-- 
2.25.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 2/3] fftools/ffmpeg_filter: remove semicolon after code block

2023-12-18 Thread Zhao Zhili
From: Zhao Zhili 

---
 fftools/ffmpeg_filter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 69a49a071e..7cc7abba64 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -2456,7 +2456,7 @@ static int read_frames(FilterGraph *fg, FilterGraphThread 
*fgt,
 }
 }
 did_step = 1;
-};
+}
 
 return (fgp->nb_outputs_done == fg->nb_outputs) ? AVERROR_EOF : 0;
 }
-- 
2.25.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 3/3] fftools/ffmpeg_enc: assert necessary frame fields before create encoder

2023-12-18 Thread Zhao Zhili
From: Zhao Zhili 

---
 fftools/ffmpeg_enc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index 57590a43a3..2a7fba0c51 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -206,6 +206,9 @@ int enc_open(void *opaque, const AVFrame *frame)
 
 switch (enc_ctx->codec_type) {
 case AVMEDIA_TYPE_AUDIO:
+av_assert0(frame->format != AV_SAMPLE_FMT_NONE &&
+   frame->sample_rate > 0 &&
+   frame->ch_layout.nb_channels > 0);
 enc_ctx->sample_fmt = frame->format;
 enc_ctx->sample_rate= frame->sample_rate;
 ret = av_channel_layout_copy(&enc_ctx->ch_layout, &frame->ch_layout);
@@ -220,6 +223,9 @@ int enc_open(void *opaque, const AVFrame *frame)
 break;
 
 case AVMEDIA_TYPE_VIDEO: {
+av_assert0(frame->format != AV_PIX_FMT_NONE &&
+   frame->width > 0 &&
+   frame->height > 0);
 enc_ctx->width  = frame->width;
 enc_ctx->height = frame->height;
 enc_ctx->sample_aspect_ratio = ost->st->sample_aspect_ratio =
-- 
2.25.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 0/1] fftools/ffprobe: dump contents of the AV_FRAME_DATA_SEI_UNREGISTERED

2023-12-18 Thread Petr Matoušek

Dne 19/12/2023 v 00:01 Stefano Sabatini napsal(a):

On date Monday 2023-12-18 14:58:58 +, Petr Matousek wrote:

Before this patch being applied the ffprobe just tells the user whether
the H.26[45] User Data Unregistered SEI message is present in the frame side 
data



or not. After the patch being appliend it also dumps the contents of the data


appliend typo


similar way as for the other already supported frame side data types.


What's the use case for this?

I wonder if we should employ some more generic mechanism, e.g. a
filter moving side data to metadata for display.


We needed to verify that our implementation of the MISB ST 0604 produces 
correct contents of the SEI data. Using ffprobe for that was very useful 
as we were able to pair the SEI data with other frame data like the PTS etc.

___
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".