Re: [FFmpeg-devel] [PATCH 2/2] lavf/movenc: sort options by name
On 2024-01-08 08:23 am, Zhao Zhili wrote: On Jan 7, 2024, at 20:05, Stefano Sabatini wrote: On date Sunday 2024-01-07 13:10:44 +0800, Zhao Zhili wrote: [...] I'm not blocking the patch, however, I'm not sure whether the gain outweighs the effort for such large code changes. It's very unlikely to introduce new issues, but possible (e.g., typo while do copy paste), and it's hard to check while review. It's true that it's hard to review, but in case of typos we should notice almost immediately (e.g. because compilation fails). Typo doesn’t always lead to compilation fail, especially in AVOption tables. In this case, patchwork shows fate passing, so there's no meaningful typos, if any. This change improves 'scanability', so LGTM. 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 2/2] lavf/movenc: sort options by name
> On Jan 7, 2024, at 20:05, Stefano Sabatini wrote: > > On date Sunday 2024-01-07 13:10:44 +0800, Zhao Zhili wrote: > [...] >> I'm not blocking the patch, however, I'm not sure whether the gain >> outweighs the effort for such large code changes. It's very >> unlikely to introduce new issues, but possible (e.g., typo while do >> copy paste), and it's hard to check while review. > > It's true that it's hard to review, but in case of typos we should > notice almost immediately (e.g. because compilation fails). Typo doesn’t always lead to compilation fail, especially in AVOption tables. > > And the readability boost it gives (sorted options means you don't > need to read through all the options to find a given one) is well > worth it. For user oriented documentation, sure. For AVOption tables, I use keyword search most of times. It’s kind of like formatting source code with clang-format. It do improve readability, but there are various reasons not to apply clang-format on whole file or whole project. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] fftools/ffmpeg_opt: add a stream_group_script option
On 1/7/2024 10:43 PM, Steven Liu wrote:
James Almer 于2024年1月8日周一 05:31写道：
Hi James,
Similar to filter_complex_script. Should make setting stream groups
easier.
Signed-off-by: James Almer
---
fftools/ffmpeg_mux_init.c | 2 +-
fftools/ffmpeg_opt.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 80109df0ae..1b42ac9a1d 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -2301,7 +2301,7 @@ static int of_add_groups(Muxer *mux, const OptionsContext
*o)
char *str, *ptr = NULL;
int ret = 0;
-str = av_strdup(o->stream_groups.opt[i].u.str);
+str = av_strireplace(o->stream_groups.opt[i].u.str, "\n", "");
if (!str)
return ret;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 7ae1b55cf0..7347fcbd31 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1508,6 +1508,9 @@ const OptionDef options[] = {
{ "stream_group", OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT,
{ .off = OFFSET(stream_groups) },
"add stream group with specified streams and group type-specific arguments",
"id=number:st=number..." },
+{ "stream_group_script", OPT_TYPE_FILE, OPT_SPEC | OPT_OUTPUT,
added documentation about this option yet?
Will add before pushing.
+{ .off = OFFSET(stream_groups) },
+"read stream group with specified streams and group type-specific arguments from a
file", "filename" },
{ "dframes",OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_PERFILE |
OPT_EXPERT | OPT_OUTPUT | OPT_HAS_CANON,
{ .func_arg = opt_data_frames },
"set the number of data frames to output", "number",
--
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".
Thanks
Steven
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] fftools/ffmpeg_opt: add a stream_group_script option
James Almer 于2024年1月8日周一 05:31写道：
Hi James,
>
> Similar to filter_complex_script. Should make setting stream groups
> easier.
>
> Signed-off-by: James Almer
> ---
> fftools/ffmpeg_mux_init.c | 2 +-
> fftools/ffmpeg_opt.c | 3 +++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
> index 80109df0ae..1b42ac9a1d 100644
> --- a/fftools/ffmpeg_mux_init.c
> +++ b/fftools/ffmpeg_mux_init.c
> @@ -2301,7 +2301,7 @@ static int of_add_groups(Muxer *mux, const
> OptionsContext *o)
> char *str, *ptr = NULL;
> int ret = 0;
>
> -str = av_strdup(o->stream_groups.opt[i].u.str);
> +str = av_strireplace(o->stream_groups.opt[i].u.str, "\n", "");
> if (!str)
> return ret;
>
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index 7ae1b55cf0..7347fcbd31 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -1508,6 +1508,9 @@ const OptionDef options[] = {
> { "stream_group", OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT,
> { .off = OFFSET(stream_groups) },
> "add stream group with specified streams and group type-specific
> arguments", "id=number:st=number..." },
> +{ "stream_group_script", OPT_TYPE_FILE, OPT_SPEC | OPT_OUTPUT,
added documentation about this option yet?
> +{ .off = OFFSET(stream_groups) },
> +"read stream group with specified streams and group type-specific
> arguments from a file", "filename" },
> { "dframes",OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_PERFILE |
> OPT_EXPERT | OPT_OUTPUT | OPT_HAS_CANON,
> { .func_arg = opt_data_frames },
> "set the number of data frames to output", "number",
> --
> 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".
Thanks
Steven
___
ffmpeg-devel mailing list
ffmpeg-devel@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 27/35] avcodec/proresenc_anatoliy: remove TO_GOLOMB2()
On Sun, Dec 24, 2023 at 12:43:32AM +0100, Stefano Sabatini wrote:
> On date Monday 2023-12-11 02:35:28 +0100, Clément Bœsch wrote:
> > A few cosmetics aside, this makes the function identical to the one with
> > the same name in proresenc_kostya.
> > ---
> > libavcodec/proresenc_anatoliy.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/proresenc_anatoliy.c
> > b/libavcodec/proresenc_anatoliy.c
> > index bdf7bface4..aed5c68b1b 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 MAKE_CODE(x) (((x) * 2) ^ GET_SIGN(x))
> > -#define TO_GOLOMB2(val,sign) ((val)==0 ? 0 : ((val) << 1) + (sign))
> >
> > static av_always_inline int get_level(int val)
> > {
> > @@ -271,7 +270,6 @@ static void encode_dcs(PutBitContext *pb, int16_t
> > *blocks,
> > {
> > int i;
> > int codebook = 5, code, dc, prev_dc, delta, sign, new_sign;
> > -int diff_sign;
> >
> > prev_dc = (blocks[0] - 0x4000) / scale;
> > encode_vlc_codeword(pb, FIRST_DC_CB, MAKE_CODE(prev_dc));
> > @@ -282,8 +280,8 @@ static void encode_dcs(PutBitContext *pb, int16_t
> > *blocks,
> > dc= (blocks[0] - 0x4000) / scale;
> > delta = dc - prev_dc;
> > new_sign = GET_SIGN(delta);
>
> > -diff_sign = new_sign ^ sign;
> > -code = TO_GOLOMB2(get_level(delta), diff_sign);
> > +delta = (delta ^ sign) - sign;
> > +code = MAKE_CODE(delta);
>
> These don't look equivalent,
>
> MAKE_CODE((delta ^ sign) - sign) is equivalent to
> TO_GOLOMB2(get_level(delta), sign)
>
> not to
> TO_GOLOMB2(get_level(delta), diff_sign)
OK so this one is a bit tricky.
Let's start from the specs, which states that the signed integer to symbol
(code) mapping should be:
2|n|if n>=0
2|n|-1 if n<0
We also know that n>>31 is -1 if n < 0, and 0 if n>=0, which means the
above condition can be simplified to:
2|n| + (n>>31)
With prores_aw we have:
s = -1 if different sign, 0 otherwise
2|n| + s
Because:
- get_level() is an absolute function¹
- the val==0 case doesn't matter because in this case s will also be 0
In prores_ks we have:
n'=-n if different sign, n otherwise
(2n')^sign(n') <=> 2|n'|-(n'>>31)
So basically, aw does use the comparison with the previous delta and
encodes it accordingly, while ks decides to swap the sign of n according
to that previous delta, then encode it using its new sign.
I wouldn't mind a third pair of eyes on the matter, but these look
equivalent to me.
Note that in practice I also tried to encode a bunch of frames from
testsrc2 with and without the patch, and they are bit identical.
¹ I mis-replied earlier directly to Stefano in the get_level() patch, so
the explanation for why get_leve() is equivalent to the absolute value:
sign can only be -1 (if val < 0) or 0 (if val >= 0). Which means val^sign
will either swap all bits or do nothing. And then it's pretty much what
can be found here:
https://graphics.stanford.edu/~seander/bithacks.html#IntegerAbs
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] fate: add raw IAMF tests
Covers muxing from raw pcm audio input into FLAC, using several scalable layouts, and demuxing the result. Signed-off-by: James Almer --- tests/Makefile | 7 +- tests/fate/iamf.mak| 31 ++ tests/filtergraphs/iamf_5_1| 4 + tests/filtergraphs/iamf_5_1_2 | 5 + tests/filtergraphs/iamf_5_1_4 | 6 ++ tests/filtergraphs/iamf_7_1_4 | 7 ++ tests/ref/fate/iamf-5_1_4 | 98 ++ tests/ref/fate/iamf-7_1_4 | 114 + tests/ref/fate/iamf-stereo | 18 tests/streamgroups/audio_element-5_1_4 | 7 ++ tests/streamgroups/audio_element-7_1_4 | 6 ++ tests/streamgroups/audio_element-stereo| 3 + tests/streamgroups/mix_presentation-5_1_4 | 2 + tests/streamgroups/mix_presentation-7_1_4 | 2 + tests/streamgroups/mix_presentation-stereo | 3 + 15 files changed, 312 insertions(+), 1 deletion(-) create mode 100644 tests/fate/iamf.mak create mode 100644 tests/filtergraphs/iamf_5_1 create mode 100644 tests/filtergraphs/iamf_5_1_2 create mode 100644 tests/filtergraphs/iamf_5_1_4 create mode 100644 tests/filtergraphs/iamf_7_1_4 create mode 100644 tests/ref/fate/iamf-5_1_4 create mode 100644 tests/ref/fate/iamf-7_1_4 create mode 100644 tests/ref/fate/iamf-stereo create mode 100644 tests/streamgroups/audio_element-5_1_4 create mode 100644 tests/streamgroups/audio_element-7_1_4 create mode 100644 tests/streamgroups/audio_element-stereo create mode 100644 tests/streamgroups/mix_presentation-5_1_4 create mode 100644 tests/streamgroups/mix_presentation-7_1_4 create mode 100644 tests/streamgroups/mix_presentation-stereo diff --git a/tests/Makefile b/tests/Makefile index e89ce7f8e6..e76163acf3 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -23,7 +23,7 @@ FFMPEG=ffmpeg$(PROGSSUF)$(EXESUF) $(AREF): CMP= APITESTSDIR := tests/api -FATE_OUTDIRS = tests/data tests/data/fate tests/data/filtergraphs tests/data/maps tests/data/lavf tests/data/lavf-fate tests/data/pixfmt tests/vsynth1 $(APITESTSDIR) +FATE_OUTDIRS = tests/data tests/data/fate tests/data/filtergraphs tests/data/maps tests/data/streamgroups tests/data/lavf tests/data/lavf-fate tests/data/pixfmt tests/vsynth1 $(APITESTSDIR) OUTDIRS += $(FATE_OUTDIRS) $(VREF): tests/videogen$(HOSTEXESUF) | tests/vsynth1 @@ -70,6 +70,10 @@ tests/data/maps/%: TAG = COPY tests/data/maps/%: $(SRC_PATH)/tests/maps/% | tests/data/maps $(M)cp $< $@ +tests/data/streamgroups/%: TAG = COPY +tests/data/streamgroups/%: $(SRC_PATH)/tests/streamgroups/% | tests/data/streamgroups + $(M)cp $< $@ + RUNNING_FATE := $(filter check fate%,$(filter-out fate-rsync,$(MAKECMDGOALS))) # Check sanity of dependencies when running FATE tests. @@ -199,6 +203,7 @@ include $(SRC_PATH)/tests/fate/hap.mak include $(SRC_PATH)/tests/fate/hevc.mak include $(SRC_PATH)/tests/fate/hlsenc.mak include $(SRC_PATH)/tests/fate/hw.mak +include $(SRC_PATH)/tests/fate/iamf.mak include $(SRC_PATH)/tests/fate/id3v2.mak include $(SRC_PATH)/tests/fate/image.mak include $(SRC_PATH)/tests/fate/imf.mak diff --git a/tests/fate/iamf.mak b/tests/fate/iamf.mak new file mode 100644 index 00..a1ba5916ba --- /dev/null +++ b/tests/fate/iamf.mak @@ -0,0 +1,31 @@ +FATE_IAMF += fate-iamf-stereo +fate-iamf-stereo: tests/data/asynth-44100-2.wav tests/data/streamgroups/audio_element-stereo tests/data/streamgroups/mix_presentation-stereo +fate-iamf-stereo: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav +fate-iamf-stereo: CMD = transcode wav $(SRC) iamf " \ + -stream_group_script $(TARGET_PATH)/tests/data/streamgroups/audio_element-stereo \ + -stream_group_script $(TARGET_PATH)/tests/data/streamgroups/mix_presentation-stereo \ + -streamid 0:0 -c:a flac -t 1" "-c:a copy -map 0" + +FATE_IAMF += fate-iamf-5_1_4 +fate-iamf-5_1_4: tests/data/asynth-44100-10.wav tests/data/filtergraphs/iamf_5_1_4 tests/data/streamgroups/audio_element-5_1_4 tests/data/streamgroups/mix_presentation-5_1_4 +fate-iamf-5_1_4: SRC = $(TARGET_PATH)/tests/data/asynth-44100-10.wav +fate-iamf-5_1_4: CMD = transcode wav $(SRC) iamf "-auto_conversion_filters \ + -filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/iamf_5_1_4 \ + -stream_group_script $(TARGET_PATH)/tests/data/streamgroups/audio_element-5_1_4 \ + -stream_group_script $(TARGET_PATH)/tests/data/streamgroups/mix_presentation-5_1_4 \ + -streamid 0:0 -streamid 1:1 -streamid 2:2 -streamid 3:3 -streamid 4:4 -streamid 5:5 -map [FRONT] -map [BACK] -map [CENTER] -map [LFE] -map [TOP_FRONT] -map [TOP_BACK] -c:a flac -t 1" "-c:a copy -map 0" + +FATE_IAMF += fate-iamf-7_1_4 +fate-iamf-7_1_4: tests/data/asynth-44100-12.wav tests/data/filtergraphs/iamf_7_1_4 tests/data/streamgroups/audio_element-7_1_4 tests/data/streamgroups/mix_presentation-7_1_4 +fate-iamf-7_1_4: SRC = $(TARGET_PATH)/tests/data/asynth-44100-12.wav
[FFmpeg-devel] [PATCH 3/4] fftools/ffmpeg_opt: add a stream_group_script option
Similar to filter_complex_script. Should make setting stream groups
easier.
Signed-off-by: James Almer
---
fftools/ffmpeg_mux_init.c | 2 +-
fftools/ffmpeg_opt.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 80109df0ae..1b42ac9a1d 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -2301,7 +2301,7 @@ static int of_add_groups(Muxer *mux, const OptionsContext
*o)
char *str, *ptr = NULL;
int ret = 0;
-str = av_strdup(o->stream_groups.opt[i].u.str);
+str = av_strireplace(o->stream_groups.opt[i].u.str, "\n", "");
if (!str)
return ret;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 7ae1b55cf0..7347fcbd31 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1508,6 +1508,9 @@ const OptionDef options[] = {
{ "stream_group", OPT_TYPE_STRING, OPT_SPEC | OPT_OUTPUT,
{ .off = OFFSET(stream_groups) },
"add stream group with specified streams and group type-specific
arguments", "id=number:st=number..." },
+{ "stream_group_script", OPT_TYPE_FILE, OPT_SPEC | OPT_OUTPUT,
+{ .off = OFFSET(stream_groups) },
+"read stream group with specified streams and group type-specific
arguments from a file", "filename" },
{ "dframes",OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_PERFILE |
OPT_EXPERT | OPT_OUTPUT | OPT_HAS_CANON,
{ .func_arg = opt_data_frames },
"set the number of data frames to output", "number",
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] fftools/cmdutils: add OPT_TYPE_FILE
Same as OPT_TYPE_STRING, except it takes a file argument whose contents
are read as a string.
Signed-off-by: James Almer
---
fftools/cmdutils.c | 34 ++
fftools/cmdutils.h | 3 +++
fftools/ffmpeg.h | 1 -
fftools/ffmpeg_opt.c | 32 +++-
4 files changed, 40 insertions(+), 30 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 44228ea637..40623a9ace 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -37,6 +37,7 @@
#include "libswresample/swresample.h"
#include "libavutil/avassert.h"
#include "libavutil/avstring.h"
+#include "libavutil/bprint.h"
#include "libavutil/channel_layout.h"
#include "libavutil/display.h"
#include "libavutil/getenv_utf8.h"
@@ -266,6 +267,13 @@ static int write_option(void *optctx, const OptionDef *po,
const char *opt,
if (!str)
return AVERROR(ENOMEM);
*(char **)dst = str;
+} else if (po->type == OPT_TYPE_FILE) {
+char *str;
+str = file_read(arg);
+av_freep(dst);
+if (!str)
+return AVERROR(ENOMEM);
+*(char **)dst = str;
} else if (po->type == OPT_TYPE_BOOL || po->type == OPT_TYPE_INT) {
ret = parse_number(opt, arg, OPT_TYPE_INT64, INT_MIN, INT_MAX, );
if (ret < 0)
@@ -1088,3 +1096,29 @@ double get_rotation(const int32_t *displaymatrix)
return theta;
}
+
+/* read file contents into a string */
+char *file_read(const char *filename)
+{
+AVIOContext *pb = NULL;
+int ret = avio_open(, filename, AVIO_FLAG_READ);
+AVBPrint bprint;
+char *str;
+
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error opening file %s.\n", filename);
+return NULL;
+}
+
+av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
+ret = avio_read_to_bprint(pb, , SIZE_MAX);
+avio_closep();
+if (ret < 0) {
+av_bprint_finalize(, NULL);
+return NULL;
+}
+ret = av_bprint_finalize(, );
+if (ret < 0)
+return NULL;
+return str;
+}
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index 53227abb47..016ee325b9 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -81,6 +81,7 @@ enum OptionType {
OPT_TYPE_FUNC,
OPT_TYPE_BOOL,
OPT_TYPE_STRING,
+OPT_TYPE_FILE,
OPT_TYPE_INT,
OPT_TYPE_INT64,
OPT_TYPE_FLOAT,
@@ -470,4 +471,6 @@ void *allocate_array_elem(void *array, size_t elem_size,
int *nb_elems);
double get_rotation(const int32_t *displaymatrix);
+char *file_read(const char *filename);
+
#endif /* FFTOOLS_CMDUTILS_H */
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 6137ac991e..cdde3c2c03 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -652,7 +652,6 @@ void remove_avoptions(AVDictionary **a, AVDictionary *b);
int check_avoptions(AVDictionary *m);
int assert_file_overwrite(const char *filename);
-char *file_read(const char *filename);
AVDictionary *strip_specifiers(const AVDictionary *dict);
int find_codec(void *logctx, const char *name,
enum AVMediaType type, int encoder, const AVCodec **codec);
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index c189cf373b..7ae1b55cf0 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -43,7 +43,6 @@
#include "libavutil/avassert.h"
#include "libavutil/avstring.h"
#include "libavutil/avutil.h"
-#include "libavutil/bprint.h"
#include "libavutil/channel_layout.h"
#include "libavutil/display.h"
#include "libavutil/intreadwrite.h"
@@ -108,12 +107,13 @@ static void uninit_options(OptionsContext *o)
SpecifierOptList *so = dst;
for (int i = 0; i < so->nb_opt; i++) {
av_freep(>opt[i].specifier);
-if (po->type == OPT_TYPE_STRING)
+if (po->type == OPT_TYPE_STRING || po->type == OPT_TYPE_FILE)
av_freep(>opt[i].u.str);
}
av_freep(>opt);
so->nb_opt = 0;
-} else if (po->flags & OPT_FLAG_OFFSET && po->type == OPT_TYPE_STRING)
+} else if (po->flags & OPT_FLAG_OFFSET && ( po->type ==
OPT_TYPE_STRING
+ || po->type ==
OPT_TYPE_FILE))
av_freep(dst);
po++;
}
@@ -759,32 +759,6 @@ int assert_file_overwrite(const char *filename)
return 0;
}
-/* read file contents into a string */
-char *file_read(const char *filename)
-{
-AVIOContext *pb = NULL;
-int ret = avio_open(, filename, AVIO_FLAG_READ);
-AVBPrint bprint;
-char *str;
-
-if (ret < 0) {
-av_log(NULL, AV_LOG_ERROR, "Error opening file %s.\n", filename);
-return NULL;
-}
-
-av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
-ret = avio_read_to_bprint(pb, , SIZE_MAX);
-avio_closep();
-if (ret < 0) {
-av_bprint_finalize(, NULL);
-return NULL;
-}
-ret = av_bprint_finalize(, );
-if (ret < 0)
-return NULL;
-return
[FFmpeg-devel] [PATCH 1/4] avformat/iamfenc: don't write empty packets
And return an error if they are not side data only packets.
Signed-off-by: James Almer
---
libavformat/iamfenc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavformat/iamfenc.c b/libavformat/iamfenc.c
index 1de416b663..a02f84035a 100644
--- a/libavformat/iamfenc.c
+++ b/libavformat/iamfenc.c
@@ -278,6 +278,16 @@ static int iamf_write_packet(AVFormatContext *s, AVPacket
*pkt)
int dyn_size, type = st->id <= 17 ? st->id + IAMF_OBU_IA_AUDIO_FRAME_ID0 :
IAMF_OBU_IA_AUDIO_FRAME;
int ret;
+if (!pkt->size) {
+uint8_t *new_extradata = av_packet_get_side_data(pkt,
AV_PKT_DATA_NEW_EXTRADATA, NULL);
+
+if (!new_extradata)
+return AVERROR_INVALIDDATA;
+
+// TODO: update FLAC Streaminfo on seekable output
+return 0;
+}
+
if (s->nb_stream_groups && st->id == c->first_stream_id) {
AVIAMFParamDefinition *mix =
(AVIAMFParamDefinition *)av_packet_get_side_data(pkt,
AV_PKT_DATA_IAMF_MIX_GAIN_PARAM, NULL);
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Revert "doc/faq: replace non-breaking spaces (0xA0) with normal space"
On 1/7/2024 3:46 PM, Marton Balint wrote:
On Sun, 7 Jan 2024, Stefano Sabatini wrote:
On date Saturday 2024-01-06 15:49:56 -0600, Marth64 wrote:
This reverts commit 6442d1ddd62160e96c686c30648b6111e3e0c264.
A valid point was made, that the non-breaking space will cause this text
to render better by ensuring the unit never seperates from the number.
I'm not convinced the non-breaking space was a good idea in the first
place, the fact that there is a single instance in the whole
documentation confirms this.
In fact even if the unit and value are not on the same line we don't
miss much in terms of readability.
On the other hand it is very hard to edit such non-printable
characters, and you can bet what as much as you can that most
contributors will not get it right or consistent.
Hard to edit how? It is not like we are in the 80s using ASCII charset
and editors with 80x25 text console to edit the files...
The whole topic is kind of bikesheddy, so I don't really mind either
way, I just don't see the benefit of using @tie{} or whatever instead of
proper utf8 chars any half decent editor would support.
0xA0 is invisible in .texi files if you use a text editor that supports
it, whereas @tie{} obviously isn't. The latter clearly conveys the
intention (no splitting) for the reader with a quick glance, and it
probably is the preferred method for the interpreter to handle this, so
IMO it's better.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Revert "doc/faq: replace non-breaking spaces (0xA0) with normal space"
On Sun, 7 Jan 2024, Stefano Sabatini wrote:
On date Saturday 2024-01-06 15:49:56 -0600, Marth64 wrote:
This reverts commit 6442d1ddd62160e96c686c30648b6111e3e0c264.
A valid point was made, that the non-breaking space will cause this text
to render better by ensuring the unit never seperates from the number.
I'm not convinced the non-breaking space was a good idea in the first
place, the fact that there is a single instance in the whole
documentation confirms this.
In fact even if the unit and value are not on the same line we don't
miss much in terms of readability.
On the other hand it is very hard to edit such non-printable
characters, and you can bet what as much as you can that most
contributors will not get it right or consistent.
Hard to edit how? It is not like we are in the 80s using ASCII charset and
editors with 80x25 text console to edit the files...
The whole topic is kind of bikesheddy, so I don't really mind either way,
I just don't see the benefit of using @tie{} or whatever instead of proper
utf8 chars any half decent editor would support.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] avcodec/proresenc_kostya: do not write into alpha reserved bitfields
On Wed, Dec 13, 2023 at 12:16:56AM +0100, Michael Niedermayer wrote: > On Wed, Dec 13, 2023 at 12:13:36AM +0100, Michael Niedermayer wrote: > > On Mon, Dec 11, 2023 at 08:06:53PM +0100, Clément Bœsch wrote: > > > This byte represents 4 reserved bits followed by 4 alpha_channel_type > > > bits. > > > > > > alpha_channel_type currently has 3 differents defined values: 0 (no > > > alpha), 1 (8b alpha), and 2 (16b alpha), all the other values are > > > reserved. This part is correctly written (alpha_bits>>3 does the correct > > > thing), but the 4 initial bits are reserved. > > > --- > > > libavcodec/proresenc_kostya.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > This breaks fate (not just changing the value but actually breaking it) > > This is about the next patch "avcodec/proresenc_anatoliy: do not write into > alpha reserved bitfields" > I used a too short search string for the subject i replied to ... > (so issue is real but its the next patch) > Just resent a patchset addressing the FATE issue for all the commits individually (sorry, I only tested with fate-prores initially) I also fixed "do not write into alpha reserved bitfields" which wasn't writing the alpha byte unconditionally. Sorry about the missing v2 in the patchset btw, forgot about it. [...] -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/5] avcodec/proresenc_anatoliy: do not write into chroma reserved bitfields
The layout for the frame flags is as follow:
chroma_format u(2)
reserved u(2)
interlace_mode u(2)
reserved u(2)
chroma_format has 2 allowed values:
0: reserved
1: reserved
2: 4:2:2
3: 4:4:4
interlace_mode has 3 allowed values:
0: progressive
1: tff
2: bff
3: reserved
0x80 is what we expect for "422 not interlaced", and the extra 0x2 from
0x82 is actually writting into the reserved bits.
---
libavcodec/proresenc_anatoliy.c | 2 +-
tests/ref/vsynth/vsynth1-prores | 2 +-
tests/ref/vsynth/vsynth1-prores_444 | 2 +-
tests/ref/vsynth/vsynth1-prores_444_int | 2 +-
tests/ref/vsynth/vsynth1-prores_int | 2 +-
tests/ref/vsynth/vsynth2-prores | 2 +-
tests/ref/vsynth/vsynth2-prores_444 | 2 +-
tests/ref/vsynth/vsynth2-prores_444_int | 2 +-
tests/ref/vsynth/vsynth2-prores_int | 2 +-
tests/ref/vsynth/vsynth3-prores | 2 +-
tests/ref/vsynth/vsynth3-prores_444 | 2 +-
tests/ref/vsynth/vsynth3-prores_444_int | 2 +-
tests/ref/vsynth/vsynth3-prores_int | 2 +-
tests/ref/vsynth/vsynth_lena-prores | 2 +-
tests/ref/vsynth/vsynth_lena-prores_444 | 2 +-
tests/ref/vsynth/vsynth_lena-prores_444_int | 2 +-
tests/ref/vsynth/vsynth_lena-prores_int | 2 +-
17 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
index 1112cb26f1..bee4a14181 100644
--- a/libavcodec/proresenc_anatoliy.c
+++ b/libavcodec/proresenc_anatoliy.c
@@ -769,7 +769,7 @@ static int prores_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
bytestream_put_buffer(, ctx->vendor, 4);
bytestream_put_be16(, avctx->width);
bytestream_put_be16(, avctx->height);
-frame_flags = 0x82; /* 422 not interlaced */
+frame_flags = 0x80; /* 422 not interlaced */
if (avctx->profile >= AV_PROFILE_PRORES_) /* or Xq */
frame_flags |= 0x40; /* 444 chroma */
if (ctx->is_interlaced) {
diff --git a/tests/ref/vsynth/vsynth1-prores b/tests/ref/vsynth/vsynth1-prores
index 52ac4e250a..f143611c35 100644
--- a/tests/ref/vsynth/vsynth1-prores
+++ b/tests/ref/vsynth/vsynth1-prores
@@ -1,4 +1,4 @@
-816d6e42260509681c49398cd4aa38a4 *tests/data/fate/vsynth1-prores.mov
+e7c8db829626fdcf30eb9d78cd26b188 *tests/data/fate/vsynth1-prores.mov
5022821 tests/data/fate/vsynth1-prores.mov
fb4a9e025d12afc0dbbca8d82831858f *tests/data/fate/vsynth1-prores.out.rawvideo
stddev:2.47 PSNR: 40.27 MAXDIFF: 31 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth1-prores_444
b/tests/ref/vsynth/vsynth1-prores_444
index d4a8c4d33d..38ca52b7f7 100644
--- a/tests/ref/vsynth/vsynth1-prores_444
+++ b/tests/ref/vsynth/vsynth1-prores_444
@@ -1,4 +1,4 @@
-722dde50fce82923b81748ad8c64ca8d *tests/data/fate/vsynth1-prores_444.mov
+61238212a797d14763431c346e896277 *tests/data/fate/vsynth1-prores_444.mov
7778954 tests/data/fate/vsynth1-prores_444.mov
e0da52b5d58171294d1b299539801ae0
*tests/data/fate/vsynth1-prores_444.out.rawvideo
stddev:2.80 PSNR: 39.17 MAXDIFF: 44 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth1-prores_444_int
b/tests/ref/vsynth/vsynth1-prores_444_int
index 9443e5e5a7..76db62d4e9 100644
--- a/tests/ref/vsynth/vsynth1-prores_444_int
+++ b/tests/ref/vsynth/vsynth1-prores_444_int
@@ -1,4 +1,4 @@
-c7e7c65147f68893d735b650efec9ed3 *tests/data/fate/vsynth1-prores_444_int.mov
+fd2a2f49c61817c2338f39d5736d5fd2 *tests/data/fate/vsynth1-prores_444_int.mov
9940947 tests/data/fate/vsynth1-prores_444_int.mov
732ceeb6887524e0aee98762fe50578b
*tests/data/fate/vsynth1-prores_444_int.out.rawvideo
stddev:2.83 PSNR: 39.08 MAXDIFF: 45 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth1-prores_int
b/tests/ref/vsynth/vsynth1-prores_int
index 46c9b2ff4e..3e2bbeff2a 100644
--- a/tests/ref/vsynth/vsynth1-prores_int
+++ b/tests/ref/vsynth/vsynth1-prores_int
@@ -1,4 +1,4 @@
-3ffa73e7ecd5c2f9a2bd2098499e22a5 *tests/data/fate/vsynth1-prores_int.mov
+1f1b246dfabe028f04c78887e5da51ed *tests/data/fate/vsynth1-prores_int.mov
6308688 tests/data/fate/vsynth1-prores_int.mov
164a4ca890695cf594293d1acec9463c
*tests/data/fate/vsynth1-prores_int.out.rawvideo
stddev:2.66 PSNR: 39.62 MAXDIFF: 34 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth2-prores b/tests/ref/vsynth/vsynth2-prores
index 37d0bd923d..f170d0 100644
--- a/tests/ref/vsynth/vsynth2-prores
+++ b/tests/ref/vsynth/vsynth2-prores
@@ -1,4 +1,4 @@
-a3815327670b2c893045d0bf1b1da9b5 *tests/data/fate/vsynth2-prores.mov
+eb1e43e2f323ef3577f43d415a7ede28 *tests/data/fate/vsynth2-prores.mov
3260123 tests/data/fate/vsynth2-prores.mov
416fa8773615889c70491452428d6710 *tests/data/fate/vsynth2-prores.out.rawvideo
stddev:1.38 PSNR: 45.29 MAXDIFF: 12 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth2-prores_444
b/tests/ref/vsynth/vsynth2-prores_444
index d0a033de40..f286fe6701
[FFmpeg-devel] [PATCH 4/5] avcodec/proresenc_anatoliy: do not write into alpha reserved bitfields
This byte represents 4 reserved bits followed by 4 alpha_channel_type bits.
alpha_channel_type currently has 3 differents defined values: 0 (no
alpha), 1 (8b alpha), and 2 (16b alpha), all the other values are
reserved. The 4 initial reserved bits are expected to be 0.
---
libavcodec/proresenc_anatoliy.c | 10 +-
tests/ref/vsynth/vsynth1-prores | 2 +-
tests/ref/vsynth/vsynth1-prores_444 | 2 +-
tests/ref/vsynth/vsynth1-prores_444_int | 2 +-
tests/ref/vsynth/vsynth1-prores_int | 2 +-
tests/ref/vsynth/vsynth2-prores | 2 +-
tests/ref/vsynth/vsynth2-prores_444 | 2 +-
tests/ref/vsynth/vsynth2-prores_444_int | 2 +-
tests/ref/vsynth/vsynth2-prores_int | 2 +-
tests/ref/vsynth/vsynth3-prores | 2 +-
tests/ref/vsynth/vsynth3-prores_444 | 2 +-
tests/ref/vsynth/vsynth3-prores_444_int | 2 +-
tests/ref/vsynth/vsynth3-prores_int | 2 +-
tests/ref/vsynth/vsynth_lena-prores | 2 +-
tests/ref/vsynth/vsynth_lena-prores_444 | 2 +-
tests/ref/vsynth/vsynth_lena-prores_444_int | 2 +-
tests/ref/vsynth/vsynth_lena-prores_int | 2 +-
17 files changed, 17 insertions(+), 25 deletions(-)
diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
index 2223721aa0..1112cb26f1 100644
--- a/libavcodec/proresenc_anatoliy.c
+++ b/libavcodec/proresenc_anatoliy.c
@@ -794,15 +794,7 @@ static int prores_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
pict->color_trc, valid_trc, 0);
*buf++ = int_from_list_or_default(avctx, "frame colorspace",
pict->colorspace, valid_colorspace, 0);
-if (avctx->profile >= AV_PROFILE_PRORES_) {
-if (avctx->pix_fmt == AV_PIX_FMT_YUV444P10) {
-*buf++ = 0xA0;/* src b64a and no alpha */
-} else {
-*buf++ = 0xA2;/* src b64a and 16b alpha */
-}
-} else {
-*buf++ = 32;/* src v210 and no alpha */
-}
+*buf++ = ctx->need_alpha ? 0x2 /* 16-bit alpha */ : 0;
*buf++ = 0; /* reserved */
*buf++ = 3; /* luma and chroma matrix present */
diff --git a/tests/ref/vsynth/vsynth1-prores b/tests/ref/vsynth/vsynth1-prores
index 3c59eb71a8..52ac4e250a 100644
--- a/tests/ref/vsynth/vsynth1-prores
+++ b/tests/ref/vsynth/vsynth1-prores
@@ -1,4 +1,4 @@
-460f69344752e6af2dc46b00169b78a3 *tests/data/fate/vsynth1-prores.mov
+816d6e42260509681c49398cd4aa38a4 *tests/data/fate/vsynth1-prores.mov
5022821 tests/data/fate/vsynth1-prores.mov
fb4a9e025d12afc0dbbca8d82831858f *tests/data/fate/vsynth1-prores.out.rawvideo
stddev:2.47 PSNR: 40.27 MAXDIFF: 31 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth1-prores_444
b/tests/ref/vsynth/vsynth1-prores_444
index 54a63348ad..d4a8c4d33d 100644
--- a/tests/ref/vsynth/vsynth1-prores_444
+++ b/tests/ref/vsynth/vsynth1-prores_444
@@ -1,4 +1,4 @@
-17c5652215ee8213319f58bc6bbcc505 *tests/data/fate/vsynth1-prores_444.mov
+722dde50fce82923b81748ad8c64ca8d *tests/data/fate/vsynth1-prores_444.mov
7778954 tests/data/fate/vsynth1-prores_444.mov
e0da52b5d58171294d1b299539801ae0
*tests/data/fate/vsynth1-prores_444.out.rawvideo
stddev:2.80 PSNR: 39.17 MAXDIFF: 44 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth1-prores_444_int
b/tests/ref/vsynth/vsynth1-prores_444_int
index 9268099c7b..9443e5e5a7 100644
--- a/tests/ref/vsynth/vsynth1-prores_444_int
+++ b/tests/ref/vsynth/vsynth1-prores_444_int
@@ -1,4 +1,4 @@
-41cc25faabf5545b84983d43cc46aded *tests/data/fate/vsynth1-prores_444_int.mov
+c7e7c65147f68893d735b650efec9ed3 *tests/data/fate/vsynth1-prores_444_int.mov
9940947 tests/data/fate/vsynth1-prores_444_int.mov
732ceeb6887524e0aee98762fe50578b
*tests/data/fate/vsynth1-prores_444_int.out.rawvideo
stddev:2.83 PSNR: 39.08 MAXDIFF: 45 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth1-prores_int
b/tests/ref/vsynth/vsynth1-prores_int
index 16a66874af..46c9b2ff4e 100644
--- a/tests/ref/vsynth/vsynth1-prores_int
+++ b/tests/ref/vsynth/vsynth1-prores_int
@@ -1,4 +1,4 @@
-3711e22aa5052f39dabfcb9ee3a42045 *tests/data/fate/vsynth1-prores_int.mov
+3ffa73e7ecd5c2f9a2bd2098499e22a5 *tests/data/fate/vsynth1-prores_int.mov
6308688 tests/data/fate/vsynth1-prores_int.mov
164a4ca890695cf594293d1acec9463c
*tests/data/fate/vsynth1-prores_int.out.rawvideo
stddev:2.66 PSNR: 39.62 MAXDIFF: 34 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth2-prores b/tests/ref/vsynth/vsynth2-prores
index 8e48cb041c..37d0bd923d 100644
--- a/tests/ref/vsynth/vsynth2-prores
+++ b/tests/ref/vsynth/vsynth2-prores
@@ -1,4 +1,4 @@
-a38660faa093dbc8a1ae8e570b6e595b *tests/data/fate/vsynth2-prores.mov
+a3815327670b2c893045d0bf1b1da9b5 *tests/data/fate/vsynth2-prores.mov
3260123 tests/data/fate/vsynth2-prores.mov
416fa8773615889c70491452428d6710 *tests/data/fate/vsynth2-prores.out.rawvideo
stddev:1.38 PSNR: 45.29
[FFmpeg-devel] [PATCH 3/5] avcodec/proresenc_kostya: do not write into alpha reserved bitfields
This byte represents 4 reserved bits followed by 4 alpha_channel_type bits.
alpha_channel_type currently has 3 differents defined values: 0 (no
alpha), 1 (8b alpha), and 2 (16b alpha), all the other values are
reserved. This part is correctly written (alpha_bits>>3 does the correct
thing), but the 4 initial bits are reserved.
---
libavcodec/proresenc_kostya.c | 2 +-
tests/ref/vsynth/vsynth1-prores_ks | 2 +-
tests/ref/vsynth/vsynth2-prores_ks | 2 +-
tests/ref/vsynth/vsynth3-prores_ks | 2 +-
tests/ref/vsynth/vsynth_lena-prores_ks | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index de63127192..f6c71c2b86 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -1051,7 +1051,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
bytestream_put_byte (, pic->color_primaries);
bytestream_put_byte (, pic->color_trc);
bytestream_put_byte (, pic->colorspace);
-bytestream_put_byte (, 0x40 | (ctx->alpha_bits >> 3));
+bytestream_put_byte (, ctx->alpha_bits >> 3);
bytestream_put_byte (, 0); // reserved
if (ctx->quant_sel != QUANT_MAT_DEFAULT) {
bytestream_put_byte (, 0x03); // matrix flags - both
matrices are present
diff --git a/tests/ref/vsynth/vsynth1-prores_ks
b/tests/ref/vsynth/vsynth1-prores_ks
index 22c248909c..a9aa6e41ba 100644
--- a/tests/ref/vsynth/vsynth1-prores_ks
+++ b/tests/ref/vsynth/vsynth1-prores_ks
@@ -1,4 +1,4 @@
-5b0970bacd4b03d70f7648fee2f0c85f *tests/data/fate/vsynth1-prores_ks.mov
+fad50b4a0fb706fb2e282678ed962281 *tests/data/fate/vsynth1-prores_ks.mov
3858911 tests/data/fate/vsynth1-prores_ks.mov
100eb002413fe7a632d440dfbdf7e3ff
*tests/data/fate/vsynth1-prores_ks.out.rawvideo
stddev:3.17 PSNR: 38.09 MAXDIFF: 39 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth2-prores_ks
b/tests/ref/vsynth/vsynth2-prores_ks
index 5186f55b4f..75289491ed 100644
--- a/tests/ref/vsynth/vsynth2-prores_ks
+++ b/tests/ref/vsynth/vsynth2-prores_ks
@@ -1,4 +1,4 @@
-abde4f84a5e4060492e3d8fcb56f2467 *tests/data/fate/vsynth2-prores_ks.mov
+2f909bf4f1262da79dd2fa502cb41853 *tests/data/fate/vsynth2-prores_ks.mov
3868162 tests/data/fate/vsynth2-prores_ks.mov
fe7ad707205c6100e9a3956d4e1c300e
*tests/data/fate/vsynth2-prores_ks.out.rawvideo
stddev:1.17 PSNR: 46.72 MAXDIFF: 14 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth3-prores_ks
b/tests/ref/vsynth/vsynth3-prores_ks
index 561ee48dee..f859c9e5f8 100644
--- a/tests/ref/vsynth/vsynth3-prores_ks
+++ b/tests/ref/vsynth/vsynth3-prores_ks
@@ -1,4 +1,4 @@
-f6ce1e8e2272cea0592d3f969d48c1de *tests/data/fate/vsynth3-prores_ks.mov
+3703ae6dea89c9d8b5a8872d8167ca42 *tests/data/fate/vsynth3-prores_ks.mov
95053 tests/data/fate/vsynth3-prores_ks.mov
9ab6d3e3cc7749796cd9fa984c60d890
*tests/data/fate/vsynth3-prores_ks.out.rawvideo
stddev:4.09 PSNR: 35.88 MAXDIFF: 35 bytes:86700/86700
diff --git a/tests/ref/vsynth/vsynth_lena-prores_ks
b/tests/ref/vsynth/vsynth_lena-prores_ks
index 333578bc1e..c3f91de2c0 100644
--- a/tests/ref/vsynth/vsynth_lena-prores_ks
+++ b/tests/ref/vsynth/vsynth_lena-prores_ks
@@ -1,4 +1,4 @@
-86b9932d5f78d0b5836533e972a37a65 *tests/data/fate/vsynth_lena-prores_ks.mov
+e0822c5ba6ce8825052dfb8dbf98d939 *tests/data/fate/vsynth_lena-prores_ks.mov
3884596 tests/data/fate/vsynth_lena-prores_ks.mov
6cfe987de99cf8ac9d43bdc5cd150838
*tests/data/fate/vsynth_lena-prores_ks.out.rawvideo
stddev:0.92 PSNR: 48.78 MAXDIFF: 10 bytes: 7603200/ 7603200
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/5] avcodec/proresenc_kostya: use a compatible bitstream version
Quoting SMPTE RDD 36:2015: A decoder shall abort if it encounters a bitstream with an unsupported bitstream_version value. If 0, the value of the chroma_format syntax element shall be 2 (4:2:2 sampling) and the value of the alpha_channel_type element shall be 0 (no encoded alpha); if 1, any permissible value may be used for those syntax elements. So if we're not in 4:2:2 or if there is alpha, we are not allowed to use version 0. --- libavcodec/proresenc_kostya.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c index 8d45e42d1a..de63127192 100644 --- a/libavcodec/proresenc_kostya.c +++ b/libavcodec/proresenc_kostya.c @@ -1037,7 +1037,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt, // frame header tmp = buf; buf += 2; // frame header size will be stored here -bytestream_put_be16 (, 0); // version 1 +bytestream_put_be16 (, ctx->chroma_factor != CFACTOR_Y422 || ctx->alpha_bits ? 1 : 0); bytestream_put_buffer(, ctx->vendor, 4); bytestream_put_be16 (, avctx->width); bytestream_put_be16 (, avctx->height); -- 2.43.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/5] avcodec/proresenc_anatoliy: use a compatible bitstream version
Quoting SMPTE RDD 36:2015: A decoder shall abort if it encounters a bitstream with an unsupported bitstream_version value. If 0, the value of the chroma_format syntax element shall be 2 (4:2:2 sampling) and the value of the alpha_channel_type element shall be 0 (no encoded alpha); if 1, any permissible value may be used for those syntax elements. So if we're not in 4:2:2 or if there is alpha, we are not allowed to use version 0. --- libavcodec/proresenc_anatoliy.c | 2 +- tests/ref/vsynth/vsynth1-prores_444 | 2 +- tests/ref/vsynth/vsynth1-prores_444_int | 2 +- tests/ref/vsynth/vsynth2-prores_444 | 2 +- tests/ref/vsynth/vsynth2-prores_444_int | 2 +- tests/ref/vsynth/vsynth3-prores_444 | 2 +- tests/ref/vsynth/vsynth3-prores_444_int | 2 +- tests/ref/vsynth/vsynth_lena-prores_444 | 2 +- tests/ref/vsynth/vsynth_lena-prores_444_int | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c index 9b9ffa03be..2223721aa0 100644 --- a/libavcodec/proresenc_anatoliy.c +++ b/libavcodec/proresenc_anatoliy.c @@ -765,7 +765,7 @@ static int prores_encode_frame(AVCodecContext *avctx, AVPacket *pkt, bytestream_put_buffer(, "icpf", 4); bytestream_put_be16(, header_size); -bytestream_put_be16(, 0); /* version */ +bytestream_put_be16(, avctx->pix_fmt != AV_PIX_FMT_YUV422P10 || ctx->need_alpha ? 1 : 0); /* version */ bytestream_put_buffer(, ctx->vendor, 4); bytestream_put_be16(, avctx->width); bytestream_put_be16(, avctx->height); diff --git a/tests/ref/vsynth/vsynth1-prores_444 b/tests/ref/vsynth/vsynth1-prores_444 index f7f8e9033d..54a63348ad 100644 --- a/tests/ref/vsynth/vsynth1-prores_444 +++ b/tests/ref/vsynth/vsynth1-prores_444 @@ -1,4 +1,4 @@ -509e0407dff118c775dcaa4f509a4aae *tests/data/fate/vsynth1-prores_444.mov +17c5652215ee8213319f58bc6bbcc505 *tests/data/fate/vsynth1-prores_444.mov 7778954 tests/data/fate/vsynth1-prores_444.mov e0da52b5d58171294d1b299539801ae0 *tests/data/fate/vsynth1-prores_444.out.rawvideo stddev:2.80 PSNR: 39.17 MAXDIFF: 44 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth1-prores_444_int b/tests/ref/vsynth/vsynth1-prores_444_int index 9515887212..9268099c7b 100644 --- a/tests/ref/vsynth/vsynth1-prores_444_int +++ b/tests/ref/vsynth/vsynth1-prores_444_int @@ -1,4 +1,4 @@ -1d5e484fa8ca08781ef2ed8428963d12 *tests/data/fate/vsynth1-prores_444_int.mov +41cc25faabf5545b84983d43cc46aded *tests/data/fate/vsynth1-prores_444_int.mov 9940947 tests/data/fate/vsynth1-prores_444_int.mov 732ceeb6887524e0aee98762fe50578b *tests/data/fate/vsynth1-prores_444_int.out.rawvideo stddev:2.83 PSNR: 39.08 MAXDIFF: 45 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth2-prores_444 b/tests/ref/vsynth/vsynth2-prores_444 index c6084f5908..c1e8109cc8 100644 --- a/tests/ref/vsynth/vsynth2-prores_444 +++ b/tests/ref/vsynth/vsynth2-prores_444 @@ -1,4 +1,4 @@ -21f973c4c6076ea21f82d5fe486c0c98 *tests/data/fate/vsynth2-prores_444.mov +9b2e73b60b1809754390f3d6bcd65218 *tests/data/fate/vsynth2-prores_444.mov 5219722 tests/data/fate/vsynth2-prores_444.mov e425b6af7afa51b5e64fc529528b3691 *tests/data/fate/vsynth2-prores_444.out.rawvideo stddev:0.88 PSNR: 49.18 MAXDIFF: 14 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth2-prores_444_int b/tests/ref/vsynth/vsynth2-prores_444_int index a727bb2d23..968a4ed7e1 100644 --- a/tests/ref/vsynth/vsynth2-prores_444_int +++ b/tests/ref/vsynth/vsynth2-prores_444_int @@ -1,4 +1,4 @@ -500a8249bc63ec6bb79f816bce5b6db1 *tests/data/fate/vsynth2-prores_444_int.mov +dbb3038d8fc88d7261a7aad315196600 *tests/data/fate/vsynth2-prores_444_int.mov 6420787 tests/data/fate/vsynth2-prores_444_int.mov 33a5db4f0423168d4ae4f1db3610928e *tests/data/fate/vsynth2-prores_444_int.out.rawvideo stddev:0.93 PSNR: 48.73 MAXDIFF: 14 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth3-prores_444 b/tests/ref/vsynth/vsynth3-prores_444 index f05894b33e..5a1614ef5a 100644 --- a/tests/ref/vsynth/vsynth3-prores_444 +++ b/tests/ref/vsynth/vsynth3-prores_444 @@ -1,4 +1,4 @@ -3070da65c30c1a9905ee31c7ede1cf57 *tests/data/fate/vsynth3-prores_444.mov +07d2ba443bd0a2ae090dd85cc8d9423e *tests/data/fate/vsynth3-prores_444.mov 159127 tests/data/fate/vsynth3-prores_444.mov 025b48feb3d9a9652983ef71e6cb7e7c *tests/data/fate/vsynth3-prores_444.out.rawvideo stddev:3.21 PSNR: 37.98 MAXDIFF: 41 bytes:86700/86700 diff --git a/tests/ref/vsynth/vsynth3-prores_444_int b/tests/ref/vsynth/vsynth3-prores_444_int index f6ba6bc282..d9127ffd17 100644 --- a/tests/ref/vsynth/vsynth3-prores_444_int +++ b/tests/ref/vsynth/vsynth3-prores_444_int @@ -1,4 +1,4 @@ -c6279e0584575ffa1e2e13047cc7ecec *tests/data/fate/vsynth3-prores_444_int.mov +a97bdacf54af3f81610861f2ba613bc7 *tests/data/fate/vsynth3-prores_444_int.mov 184397 tests/data/fate/vsynth3-prores_444_int.mov
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: add new unsafe_output hwaccel_flag
On Sat, Dec 10, 2022 at 12:00:09AM +, Timo Rothenpieler wrote: > ffmpeg | branch: master | Timo Rothenpieler | Mon Dec > 5 22:32:46 2022 +0100| [7a8d78f7e358e5544395ba6084b83dfe18b4a84e] | > committer: Timo Rothenpieler > > lavc: add new unsafe_output hwaccel_flag > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=7a8d78f7e358e5544395ba6084b83dfe18b4a84e > --- > > doc/APIchanges | 3 +++ > libavcodec/avcodec.h | 16 > libavcodec/options_table.h | 1 + > libavcodec/version.h | 4 ++-- > 4 files changed, 22 insertions(+), 2 deletions(-) This should be documented in doc/* too i think thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/muxers: extend documentation for MOV muxers
Update to that paragraph LGTM. Thanks! On Sun, Jan 7, 2024 at 9:05 AM Stefano Sabatini wrote: > On date Saturday 2024-01-06 14:43:47 -0600, Marth64 wrote: > > +This section covers formats belonging to the QuickTime / MOV family, > > +also named after the MPEG-4 Part 14 format, also named after the ISO > > +base media file format (ISOBMFF). > > + > > +The MOV format was originally developed for the Apple QuickTime > > +container format. Then it was later used as basis for the MPEG MPEG-4 > > +Part 1 (later Part 14) format, also named after ISO/IEC 14496-1. > > + > > +The format was later generalized into the ISO base media file format, > > +also named MPEG-4 Part 12 format or ISO/IEC 14496-12 or ISO/IEC > > +15444-12. > > + > > > > The word "also" is very prominent in this part (and a duplicate MPEG). I > > admit it feels confusing to read. Maybe something like this? > > > > This section covers formats belonging to the QuickTime / MOV family, > > including the MPEG-4 Part 14 format. These formats share a common > structure > > based on the ISO base media file format (ISOBMFF). ISOBMFF is also known > as > > MPEG-4 Part 12, ISO/IEC 14496-12, or ISO/IEC 15444-12. > > > > The MOV format was originally developed for use with Apple QuickTime. > > It was later used as the basis for MPEG-4 Part 1 (later Part 14), also > > known as > > ISO/IEC 14496-1. That format was then generalized into ISOBMFF. > > Thanks, shortened and updated with some of the suggested changes. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] doc/faq: Use texi's @tie instead of 0xA0 for non-breaking space
Nice find! Updated. Looks good here when rendered to HTML.
Signed-off-by: Marth64
---
doc/faq.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/faq.texi b/doc/faq.texi
index 5998e0d000..477cc60533 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -450,7 +450,7 @@ work with streams that were detected during the initial
scan; streams that
are detected later are ignored.
The size of the initial scan is controlled by two options: @code{probesize}
-(default ~5 Mo) and @code{analyzeduration} (default 5,000,000 µs = 5 s). For
+(default ~5@tie{}Mo) and @code{analyzeduration} (default 5,000,000@tie{}µs =
5@tie{}s). For
the subtitle stream to be detected, both values must be large enough.
@section Why was the @command{ffmpeg} @option{-sameq} option removed? What to
use instead?
--
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".
Re: [FFmpeg-devel] [PATCH v3] libavformat: add RCWT closed caption muxer
On date Sunday 2024-01-07 09:07:01 -0600, Marth64 wrote: > Thanks, long night. Should come together nicer now. > > Signed-off-by: Marth64 > --- > Changelog| 1 + > doc/muxers.texi | 22 + > libavformat/Makefile | 1 + > libavformat/allformats.c | 1 + > libavformat/rcwtenc.c| 202 +++ > tests/fate/subtitles.mak | 3 + > tests/ref/fate/sub-rcwt | 1 + > 7 files changed, 231 insertions(+) > create mode 100644 libavformat/rcwtenc.c > create mode 100644 tests/ref/fate/sub-rcwt LGTM, I'll wait a few days to see if there are more comments before pushing (if I forget please ping). Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/muxers: add argo_asf
---
doc/muxers.texi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 1bafea0d12..5e4fbeb883 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -692,6 +692,24 @@ ffmpeg -i INPUT -final_delay 0.5 -plays 2 out.apng
@end example
@end itemize
+@section argo_asf
+Argonaut Games ASF.
+
+@subsection Options
+@table @option
+@item version_major @var{version}
+override file major version, specified as an integer, default value is
+@code{2}
+
+@item version_minor @var{version}
+override file minor version, specified as an integer, default value is
+@code{1}
+
+@item name @var{name}
+Embed file name into file, if not specified use the output file
+name. The name is truncated to 8 characters.
+@end table
+
@anchor{asf}
@section asf
--
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 v3] libavformat: add RCWT closed caption muxer
Thanks, long night. Should come together nicer now.
Signed-off-by: Marth64
---
Changelog| 1 +
doc/muxers.texi | 22 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/rcwtenc.c| 202 +++
tests/fate/subtitles.mak | 3 +
tests/ref/fate/sub-rcwt | 1 +
7 files changed, 231 insertions(+)
create mode 100644 libavformat/rcwtenc.c
create mode 100644 tests/ref/fate/sub-rcwt
diff --git a/Changelog b/Changelog
index 5b2899d05b..4e7c1ce2c1 100644
--- a/Changelog
+++ b/Changelog
@@ -18,6 +18,7 @@ version :
- lavu/eval: introduce randomi() function in expressions
- VVC decoder
- fsync filter
+- Raw Captions with Time (RCWT) closed caption muxer
version 6.1:
- libaribcaption decoder
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 7b705b6a9e..9cacbfc23e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2232,6 +2232,28 @@ Extensions: thd
SMPTE 421M / VC-1 video.
+@anchor{rcwt}
+@section rcwt
+
+Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
+used open source tool for processing 608/708 closed caption (CC) sources.
+It can be used to archive the original, raw CC bitstream and to produce
+a source file for later CC processing or conversion. As a result,
+it also allows for interopability with ccextractor for processing CC data
+extracted via ffmpeg. The format is simple to parse and can be used
+to retain all lines and variants of CC.
+
+This muxer implements the specification as of 2024-01-05, which has
+been stable and unchanged for 10 years as of this writing.
+
+This muxer will have some nuances from the way that ccextractor muxes RCWT.
+No compatibility issues when processing the output with ccextractor
+have been observed as a result of this so far, but mileage may vary
+and outputs will not be a bit-exact match.
+
+A free specification of RCWT can be found here:
+@url{https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT}
+
@anchor{segment}
@section segment, stream_segment, ssegment
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 581e378d95..dcc99eeac4 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -490,6 +490,7 @@ OBJS-$(CONFIG_QOA_DEMUXER) += qoadec.o
OBJS-$(CONFIG_R3D_DEMUXER) += r3d.o
OBJS-$(CONFIG_RAWVIDEO_DEMUXER) += rawvideodec.o
OBJS-$(CONFIG_RAWVIDEO_MUXER)+= rawenc.o
+OBJS-$(CONFIG_RCWT_MUXER)+= rcwtenc.o subtitles.o
OBJS-$(CONFIG_REALTEXT_DEMUXER) += realtextdec.o subtitles.o
OBJS-$(CONFIG_REDSPARK_DEMUXER) += redspark.o
OBJS-$(CONFIG_RKA_DEMUXER) += rka.o apetag.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index ce6be5f04d..b04b43cab3 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -389,6 +389,7 @@ extern const AVInputFormat ff_qoa_demuxer;
extern const AVInputFormat ff_r3d_demuxer;
extern const AVInputFormat ff_rawvideo_demuxer;
extern const FFOutputFormat ff_rawvideo_muxer;
+extern const FFOutputFormat ff_rcwt_muxer;
extern const AVInputFormat ff_realtext_demuxer;
extern const AVInputFormat ff_redspark_demuxer;
extern const AVInputFormat ff_rka_demuxer;
diff --git a/libavformat/rcwtenc.c b/libavformat/rcwtenc.c
new file mode 100644
index 00..839436ce84
--- /dev/null
+++ b/libavformat/rcwtenc.c
@@ -0,0 +1,202 @@
+/*
+ * Raw Captions With Time (RCWT) muxer
+ * Author: Marth64
+ *
+ * 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
+ */
+
+/*
+ * Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
+ * used open source tool for processing 608/708 closed caption (CC) sources.
+ * It can be used to archive the original, raw CC bitstream and to produce
+ * a source file for later CC processing or conversion. As a result,
+ * it also allows for interopability with ccextractor for processing CC data
+ * extracted via ffmpeg. The format is simple to parse and can be used
+ * to retain all lines and variants of CC.
+ *
+ * This muxer implements the specification as of 2024-01-05, which has
+ * been stable and unchanged for 10 years as of this writing.
+ *
+ * This muxer will have some
Re: [FFmpeg-devel] [PATCH 1/2] doc/muxers: extend documentation for MOV muxers
On date Saturday 2024-01-06 14:43:47 -0600, Marth64 wrote:
> +This section covers formats belonging to the QuickTime / MOV family,
> +also named after the MPEG-4 Part 14 format, also named after the ISO
> +base media file format (ISOBMFF).
> +
> +The MOV format was originally developed for the Apple QuickTime
> +container format. Then it was later used as basis for the MPEG MPEG-4
> +Part 1 (later Part 14) format, also named after ISO/IEC 14496-1.
> +
> +The format was later generalized into the ISO base media file format,
> +also named MPEG-4 Part 12 format or ISO/IEC 14496-12 or ISO/IEC
> +15444-12.
> +
>
> The word "also" is very prominent in this part (and a duplicate MPEG). I
> admit it feels confusing to read. Maybe something like this?
>
> This section covers formats belonging to the QuickTime / MOV family,
> including the MPEG-4 Part 14 format. These formats share a common structure
> based on the ISO base media file format (ISOBMFF). ISOBMFF is also known as
> MPEG-4 Part 12, ISO/IEC 14496-12, or ISO/IEC 15444-12.
>
> The MOV format was originally developed for use with Apple QuickTime.
> It was later used as the basis for MPEG-4 Part 1 (later Part 14), also
> known as
> ISO/IEC 14496-1. That format was then generalized into ISOBMFF.
Thanks, shortened and updated with some of the suggested changes.
>From 9d076e4945420dc1e36d7a681431da495d6bbcfc Mon Sep 17 00:00:00 2001
From: Stefano Sabatini
Date: Sat, 6 Jan 2024 17:45:35 +0100
Subject: [PATCH] doc/muxers: extend documentation for MOV muxers
---
doc/muxers.texi | 464 +---
1 file changed, 317 insertions(+), 147 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 7b705b6a9e..ee6edd6f43 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -19,6 +19,323 @@ enabled demuxers and muxers.
A description of some of the currently available muxers follows.
+@section MOV/MPEG-4/ISOMBFF muxers
+
+This section covers formats belonging to the QuickTime / MOV family,
+including the MPEG-4 Part 14 format and ISO base media file format
+(ISOBMFF). These formats share a common structure based on the ISO
+base media file format (ISOBMFF).
+
+The MOV format was originally developed for use with Apple QuickTime.
+It was later used as the basis for the MPEG-4 Part 1 (later Part 14)
+format, also known as ISO/IEC 14496-1. That format was then
+generalized into ISOBMFF, also named MPEG-4 Part 12 format, ISO/IEC
+14496-12, or ISO/IEC 15444-12.
+
+It comprises the following muxers.
+
+@table @samp
+@item 3gp
+Third Generation Partnership Project (3GPP) format for 3G UMTS
+multimedia services
+
+@item 3g2
+Third Generation Partnership Project 2 (3GP2 or 3GPP2) format for 3G
+CDMA2000 multimedia services, similar to @samp{3gp} with extensions
+and limitations
+
+@item f4v
+Adobe Flash Video format
+
+@item ipod
+MPEG-4 audio file format, as MOV/MP4 but limited to contain only audio
+streams, typically played with the Apple ipod device
+
+@item ismv
+Microsoft IIS (Internet Information Services) Smooth Streaming
+Audio/Video (ISMV or ISMA) format. This is based on MPEG-4 Part 14
+format with a few incompatible variants, used to stream media files
+for the Microsoft IIS server.
+
+@item mov
+QuickTime player format identified by the @code{.mov} extension
+
+@item mp4
+MP4 or MPEG-4 Part 14 format
+
+@item psp
+PlayStation Portable MP4/MPEG-4 Part 14 format variant. This is based
+on MPEG-4 Part 14 format with a few incompatible variants, used to
+play files on PlayStation devices.
+@end table
+
+@subsection Fragmentation
+
+The @samp{mov}, @samp{mp4}, and @samp{ismv} muxers support
+fragmentation. Normally, a MOV/MP4 file has all the metadata about all
+packets stored in one location.
+
+This data is usually written at the end of the file, but it can be
+moved to the start for better playback by adding @code{+faststart} to
+the @code{-movflags}, or using the @command{qt-faststart} tool).
+
+A fragmented file consists of a number of fragments, where packets and
+metadata about these packets are stored together. Writing a fragmented
+file has the advantage that the file is decodable even if the writing
+is interrupted (while a normal MOV/MP4 is undecodable if it is not
+properly finished), and it requires less memory when writing very long
+files (since writing normal MOV/MP4 files stores info about every
+single packet in memory until the file is closed). The downside is
+that it is less compatible with other applications.
+
+Fragmentation is enabled by setting one of the options that define
+how to cut the file into fragments:
+@table @option
+@item frag_duration
+@item frag_size
+@item min_frag_duration
+@item movflags +frag_keyframe
+@item movflags +frag_custom
+@end table
+
+If more than one condition is specified, fragments are cut when one of
+the specified conditions is fulfilled. The exception to this is the
+option @option{min_frag_duration}, which has to be fulfilled for any
+of the other
Re: [FFmpeg-devel] Fix incomplete implementation of framesync options for overlay filter
On date Friday 2024-01-05 11:36:21 +, Howard Peacock wrote: > Hi - first time posting, so apologies in advance if this breaks an etiquette > rule. > > Just a request / suggestion that the 'overlay' filter be updated to implement > all the framesync options - including ts_sync_mode. Currently - although > https://ffmpeg.org/ffmpeg-filters.html#overlay-1 states that 'This filter > also supports the framesync options' - attempting to set ts_sync_mode results > in an error - for example: > > $ ffmpeg -f v4l2 -i /dev/video0 -filter_complex > "[0:v][0:]overlay=x=20:y=20:ts_sync_mode=nearest" -f flv - | ffplay - > > Error initializing complex filters. > Option not found > > Running ffmpeg -h filter=overlay (and looking at latest source code) confirms > that the ts_sync_mode framesync option is not currently implemented in the > overlay filter. > > The reason for asking is that I'm in a programming context with multiple > livestreams (with different start times) and multiple overlays where the > second overlay needs to use the 'nearest' rather than 'default' sync > behaviour to keep everything in sync, and it's not currently possible - I > have to dial in delays manually. > > I was thinking of posting as a bug because of the mismatch between > documentation and implementation but it's probably a feature request in > fairness! Please create a ticket on trac: http://trac.ffmpeg.org/query?status=new=open=reopened=id=summary=status=type=component=version=time=changetime=priority=1 or this request might be lost (or even better send a patch). 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] doc/encoders: fix opus typo
On date Saturday 2024-01-06 16:24:54 -0600, Marth64 wrote: > Signed-off-by: Marth64 > --- > doc/encoders.texi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/encoders.texi b/doc/encoders.texi > index f65389f2a0..c9fe6d6143 100644 > --- a/doc/encoders.texi > +++ b/doc/encoders.texi > @@ -615,7 +615,7 @@ and slightly improves compression. > > Opus encoder. > > -This is a native FFmpeg encoder for the Opus format. Currently its in > development and > +This is a native FFmpeg encoder for the Opus format. Currently, it's in > development and > only implements the CELT part of the codec. Its quality is usually worse and > at best > is equal to the libopus encoder. Thanks, will apply. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] doc/filters: add idet example
On date Saturday 2024-01-06 16:18:39 -0600, Marth64 wrote: > Thanks all, this should be much better now. > > Signed-off-by: Marth64 > --- > doc/filters.texi | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/doc/filters.texi b/doc/filters.texi > index 09fa3264ea..20c91bab3a 100644 > --- a/doc/filters.texi > +++ b/doc/filters.texi > @@ -15968,6 +15968,15 @@ further computations. This allows inserting the idet > filter as a low computation > method to clean up the interlaced flag > @end table > > +@subsection Examples > + > +Inspect the field order of the first 360 frames in a video, in verbose > detail: > +@example > +ffmpeg -i INPUT -filter:v idet,metadata=mode=print -frames:v 360 -an -f null > - > +@end example > +The idet filter will add analysis metadata to each frame, which will then be > +discarded. At the end, the filter will also print a final report with > statistics. > + Thanks, will apply. ___ ffmpeg-devel mailing list ffmpeg-devel@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] Revert "doc/faq: replace non-breaking spaces (0xA0) with normal space"
On date Sunday 2024-01-07 14:16:23 +0100, ffmpeg-devel Mailing List wrote:
> Am 07.01.24 um 13:12 schrieb Stefano Sabatini:
> > On date Saturday 2024-01-06 15:49:56 -0600, Marth64 wrote:
> > > This reverts commit 6442d1ddd62160e96c686c30648b6111e3e0c264.
> > >
> > > A valid point was made, that the non-breaking space will cause this text
> > > to render better by ensuring the unit never seperates from the number.
> >
> > I'm not convinced the non-breaking space was a good idea in the first
> > place, the fact that there is a single instance in the whole
> > documentation confirms this.
> >
> > In fact even if the unit and value are not on the same line we don't
> > miss much in terms of readability.
> >
> > On the other hand it is very hard to edit such non-printable
> > characters, and you can bet as much as you can that most
> > contributors will not get it right or consistent.
>
> I think we could use @tie{} instead of an invisible 0xA0 wherever we want
> non-breaking spaces.
+1, this would be better than 0xA0.
> Even if we seem not to care much about these in the docs.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Revert "doc/faq: replace non-breaking spaces (0xA0) with normal space"
Am 07.01.24 um 13:12 schrieb Stefano Sabatini:
On date Saturday 2024-01-06 15:49:56 -0600, Marth64 wrote:
This reverts commit 6442d1ddd62160e96c686c30648b6111e3e0c264.
A valid point was made, that the non-breaking space will cause this text
to render better by ensuring the unit never seperates from the number.
I'm not convinced the non-breaking space was a good idea in the first
place, the fact that there is a single instance in the whole
documentation confirms this.
In fact even if the unit and value are not on the same line we don't
miss much in terms of readability.
On the other hand it is very hard to edit such non-printable
characters, and you can bet what as much as you can that most
contributors will not get it right or consistent.
I think we could use @tie{} instead of an invisible 0xA0 wherever we want
non-breaking spaces.
Even if we seem not to care much about these in the docs.
-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
Am 06.01.24 um 18:39 schrieb James Almer:
On 12/16/2023 5:13 AM, Thilo Borgmann via ffmpeg-devel 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
[...]
+static int activate(AVFilterContext *ctx)
+{
+ FsyncContext *s = ctx->priv;
+ AVFilterLink *inlink = ctx->inputs[0];
+ AVFilterLink *outlink = ctx->outputs[0];
+
+ int ret, line_count;
+ AVFrame *frame;
+
+ FF_FILTER_FORWARD_STATUS_BACK(outlink, inlink);
+
+ buf_skip_eol(s);
+ line_count = buf_get_line_count(s);
+ if (line_count < 0) {
+ line_count = buf_reload(s);
+ if (line_count < 0)
+ return line_count;
+ line_count = buf_get_line_count(s);
+ if (line_count < 0)
+ return line_count;
+ }
+
+ if (avio_feof(s->avio_ctx) && buf_get_zero(s) < 3) {
+ av_log(ctx, AV_LOG_DEBUG, "End of file. To zero = %i\n",
buf_get_zero(s));
+ goto end;
+ }
+
+ if (s->last_frame) {
+ ret = av_sscanf(s->cur, "%"PRId64" %"PRId64" %d/%d", >ptsi, >pts,
>tb_num, >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);
+
+ if (s->last_frame->pts >= s->ptsi) {
+ av_log(ctx, AV_LOG_DEBUG, ">= %lli: DUP LAST with pts = %lli\n",
s->ptsi, s->pts);
+
+ // clone frame
+ frame = av_frame_clone(s->last_frame);
+ if (!frame) {
+ ff_outlink_set_status(outlink, AVERROR(ENOMEM),
AV_NOPTS_VALUE);
+ return AVERROR(ENOMEM);
+ }
+
+ // set output pts and timebase
+ frame->pts = s->pts;
+ frame->time_base = av_make_q((int)s->tb_num, (int)s->tb_den);
+
+ // advance cur to eol, skip over eol in the next call
+ s->cur += line_count;
+
+ // call again
+ if (ff_inoutlink_check_flow(inlink, outlink))
+ ff_filter_set_ready(ctx, 100);
+
+ // filter frame
+ return ff_filter_frame(outlink, frame);
+ } else if (s->last_frame->pts < s->ptsi) {
+ av_log(ctx, AV_LOG_DEBUG, "< %lli: DROP\n", s->ptsi);
+ av_frame_free(>last_frame);
+
+ // call again
+ if (ff_inoutlink_check_flow(inlink, outlink))
+ ff_filter_set_ready(ctx, 100);
+
+ return 0;
+ }
+ }
+
+end:
+ ret = ff_inlink_consume_frame(inlink, >last_frame);
There's a leak in this filter, and i suspect it's here. If s->last_frame is not
NULL, the pointer will be rewritten and the frame will leak.
http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-valgrind-no-undef
Indeed - fixed & pushed.
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] Revert "doc/faq: replace non-breaking spaces (0xA0) with normal space"
On date Saturday 2024-01-06 15:49:56 -0600, Marth64 wrote:
> This reverts commit 6442d1ddd62160e96c686c30648b6111e3e0c264.
>
> A valid point was made, that the non-breaking space will cause this text
> to render better by ensuring the unit never seperates from the number.
I'm not convinced the non-breaking space was a good idea in the first
place, the fact that there is a single instance in the whole
documentation confirms this.
In fact even if the unit and value are not on the same line we don't
miss much in terms of readability.
On the other hand it is very hard to edit such non-printable
characters, and you can bet what as much as you can that most
contributors will not get it right or consistent.
> Signed-off-by: Marth64
> ---
> doc/faq.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/faq.texi b/doc/faq.texi
> index 5998e0d000..39f28eef08 100644
> --- a/doc/faq.texi
> +++ b/doc/faq.texi
> @@ -450,7 +450,7 @@ work with streams that were detected during the initial
> scan; streams that
> are detected later are ignored.
>
> The size of the initial scan is controlled by two options: @code{probesize}
> -(default ~5 Mo) and @code{analyzeduration} (default 5,000,000 µs = 5 s). For
> +(default ~5 Mo) and @code{analyzeduration} (default 5,000,000 µs = 5 s). For
> the subtitle stream to be detected, both values must be large enough.
>
> @section Why was the @command{ffmpeg} @option{-sameq} option removed? What
> to use instead?
> --
> 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 mailing list
ffmpeg-devel@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] lavf/movenc: sort options by name
On date Sunday 2024-01-07 13:10:44 +0800, Zhao Zhili wrote: [...] > I'm not blocking the patch, however, I'm not sure whether the gain > outweighs the effort for such large code changes. It's very > unlikely to introduce new issues, but possible (e.g., typo while do > copy paste), and it's hard to check while review. It's true that it's hard to review, but in case of typos we should notice almost immediately (e.g. because compilation fails). And the readability boost it gives (sorted options means you don't need to read through all the options to find a given one) is well worth 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] [PATCH v2] libavformat: add RCWT closed caption muxer
On date Saturday 2024-01-06 15:41:05 -0600, Marth64 wrote:
> Signed-off-by: Marth64
>
> Thank you for the good feedback and review. Most feedback is addressed.
>
> > nit: no need to shift
> I left this alone only since I see it being done this way in lavf/ccfifo
> and other documentation. I assumed it could be doing the shift for a reason,
> but I can study further why if you think it shouldn't shift.
>
> > I don't remember if new elements addition entails a minor library bump
> > (probably it should)
> I reviewed APIchangelog and didn't see similar type of bumps for adding to
> allformats.
> The publically exposed codec ID has been in ffmpeg for a long time.
> But I am happy to patch in a version bump with your confirmation.
>
> Much appreciated,
> Marth64
>
> ---
> Changelog| 1 +
> doc/muxers.texi | 40 ++
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/rcwtenc.c| 166 +++
> tests/fate/subtitles.mak | 3 +
> tests/ref/fate/sub-rcwt | 1 +
> 7 files changed, 213 insertions(+)
> create mode 100644 libavformat/rcwtenc.c
> create mode 100644 tests/ref/fate/sub-rcwt
>
> diff --git a/Changelog b/Changelog
> index 5b2899d05b..3d60f688ca 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -18,6 +18,7 @@ version :
> - lavu/eval: introduce randomi() function in expressions
> - VVC decoder
> - fsync filter
> +- Raw Captions with Time (RCWT) closed caption demuxer
demuxer -> muxer?
>
> version 6.1:
> - libaribcaption decoder
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 7b705b6a9e..0bdeaeeaf3 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -2232,6 +2232,46 @@ Extensions: thd
>
> SMPTE 421M / VC-1 video.
>
> +@anchor{rcwt}
> +@section rcwt
> +
> +Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
> +used open source tool for processing 608/708 closed caption (CC) sources.
> +It can be used to archive the original, raw CC bitstream and to produce
> +a source file for later CC processing or conversion. As a result,
> +it also allows for interopability with ccextractor for processing CC data
> +extracted via ffmpeg. The format is simple to parse and can be used
> +to retain all lines and variants of CC.
> +This muxer implements the specification as of 2024-01-05, which has
> +been stable and unchanged for 10 years as of this writing.
> +
> +This muxer will have some nuances from the way that ccextractor muxes RCWT.
> +No compatibility issues when processing the output with ccextractor
> +have been observed as a result of this so far, but mileage may vary
> +and outputs will not be a bit-exact match.
> +
> +Specifically, the differences are:
> +@enumerate
> +@item
> +This muxer will identify as "FF" as the writing program identifier, so
> +as to be honest about the output's origin.
> +@item
> +ffmpeg's MPEG-1/2, H264, HEVC, etc. decoders extract closed captioning
> +data differently than ccextractor from embedded SEI/user data.
> +For example, DVD captioning bytes will be translated to ATSC A53 format.
> +This allows ffmpeg to handle 608/708 in a consistant way downstream.
> +This is a lossless conversion and the meaningful data is retained.
> +@item
> +This muxer will not alter the extracted data except to remove invalid
> +packets in between valid CC blocks. On the other hand, ccextractor
> +will by default remove mid-stream padding, and add padding at the end
> +of the stream (in order to convey the end time of the source video).
> +@end enumerate
This part is probably a bit too technical for user documentation,
especially for the details related to the implmentation (which might
change), so probably can/should be left out.
You might keep the link to the file format below though.
[...]
LGTM otherwise.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/buffersrc: add color_space/range parameters
On Sun, Dec 31, 2023 at 09:49:43PM +, Niklas Haas wrote: > ffmpeg | branch: master | Niklas Haas | Fri Oct 20 16:55:43 > 2023 +0200| [2d555dc82d4ccd3c54c76e2fb3c861a8652de1c6] | committer: Niklas > Haas > > avfilter/buffersrc: add color_space/range parameters > > To allow adding proper negotiation, in particular, to fftools. > > These values will simply be negotiated downstream for YUV formats, and > ignored otherwise. > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=2d555dc82d4ccd3c54c76e2fb3c861a8652de1c6 > --- > > doc/filters.texi| 10 +++ > libavfilter/buffersrc.c | 75 > +++-- > libavfilter/buffersrc.h | 6 > 3 files changed, 83 insertions(+), 8 deletions(-) After this the command line tools print tons of warnings ./ffplay file-j2k.mxf [ffplay_buffer @ 0x7f8b90001940] filter context - w: 320 h: 240 fmt: 2 csp: unknown range: unknown, incoming frame - w: 320 h: 240 fmt: 2 csp: gbr range: pc pts_time: 0 [ffplay_buffer @ 0x7f8b90001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7f8b90001940] filter context - w: 320 h: 240 fmt: 2 csp: unknown range: unknown, incoming frame - w: 320 h: 240 fmt: 2 csp: gbr range: pc pts_time: 0.04 [ffplay_buffer @ 0x7f8b90001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7f8b90001940] filter context - w: 320 h: 240 fmt: 2 csp: unknown range: unknown, incoming frame - w: 320 h: 240 fmt: 2 csp: gbr range: pc pts_time: 0.08 [ffplay_buffer @ 0x7f8b90001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7f8b90001940] filter context - w: 320 h: 240 fmt: 2 csp: unknown range: unknown, incoming frame - w: 320 h: 240 fmt: 2 csp: gbr range: pc pts_time: 0.12 [ffplay_buffer @ 0x7f8b90001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7f8b90001940] filter context - w: 320 h: 240 fmt: 2 csp: unknown range: unknown, incoming frame - w: 320 h: 240 fmt: 2 csp: gbr range: pc pts_time: 0.16 [ffplay_buffer @ 0x7f8b90001940] Changing video frame properties on the fly is not supported by all filters. heres it with a random file from fate ./ffplay fate-suite/mxf/track_01_v02.mxf [ffplay_buffer @ 0x7fd610001940] filter context - w: 1280 h: 720 fmt: 4 csp: unknown range: unknown, incoming frame - w: 1280 h: 720 fmt: 4 csp: bt709 range: tv pts_time: 0 [ffplay_buffer @ 0x7fd610001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7fd610001940] filter context - w: 1280 h: 720 fmt: 4 csp: unknown range: unknown, incoming frame - w: 1280 h: 720 fmt: 4 csp: bt709 range: tv pts_time: 0.0417083 [ffplay_buffer @ 0x7fd610001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7fd610001940] filter context - w: 1280 h: 720 fmt: 4 csp: unknown range: unknown, incoming frame - w: 1280 h: 720 fmt: 4 csp: bt709 range: tv pts_time: 0.0834167 [ffplay_buffer @ 0x7fd610001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7fd610001940] filter context - w: 1280 h: 720 fmt: 4 csp: unknown range: unknown, incoming frame - w: 1280 h: 720 fmt: 4 csp: bt709 range: tv pts_time: 0.125125 [ffplay_buffer @ 0x7fd610001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7fd610001940] filter context - w: 1280 h: 720 fmt: 4 csp: unknown range: unknown, incoming frame - w: 1280 h: 720 fmt: 4 csp: bt709 range: tv pts_time: 0.166833 [ffplay_buffer @ 0x7fd610001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7fd610001940] filter context - w: 1280 h: 720 fmt: 4 csp: unknown range: unknown, incoming frame - w: 1280 h: 720 fmt: 4 csp: bt709 range: tv pts_time: 0.208542 [ffplay_buffer @ 0x7fd610001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7fd610001940] filter context - w: 1280 h: 720 fmt: 4 csp: unknown range: unknown, incoming frame - w: 1280 h: 720 fmt: 4 csp: bt709 range: tv pts_time: 0.25025 [ffplay_buffer @ 0x7fd610001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7fd610001940] filter context - w: 1280 h: 720 fmt: 4 csp: unknown range: unknown, incoming frame - w: 1280 h: 720 fmt: 4 csp: bt709 range: tv pts_time: 0.291958 [ffplay_buffer @ 0x7fd610001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7fd610001940] filter context - w: 1280 h: 720 fmt: 4 csp: unknown range: unknown, incoming frame - w: 1280 h: 720 fmt: 4 csp: bt709 range: tv pts_time: 0.333667 [ffplay_buffer @ 0x7fd610001940] Changing video frame properties on the fly is not supported by all filters. [ffplay_buffer @ 0x7fd610001940]
Re: [FFmpeg-devel] [PATCH 3/3] lavc/svq1enc: R-V V ssd_int8_vs_int16
Alright, I learned a bit more, so should we not consider the internal
implementation?
I've added this version that reduces one vset in this reply.
Rémi Denis-Courmont 于2024年1月7日周日 16:03写道：
> Le sunnuntaina 7. tammikuuta 2024, 3.33.39 EET flow gg a écrit :
> > I tested it, and indeed using vwsub is faster. Updated it in the reply.
> >
> > ---
> >
> > I have a question: if I tweak the load order a bit, using one less vset,
> it
> > leads to being slower (the patch I submitted is 13.2, if I make the
> > following change, the time would be 15.2).
> > But I thought it would be faster.
>
> I would guess that v0 is needed before v8 in the internal implementation
> of
> vwsub. This kind of makes sense as the element still need to be
> sign-extended.
> Thus vwsub ends up stalling the pipeline in wait for vle8 to complete.
> That's
> just a guess though, as I don't have internal cycle timing documentation.
>
> > - vsetvli t0, a2, e8, m2, tu, ma
> > - vle8.v v0, (a0)
> > - sub a2, a2, t0
> > - vsetvli zero, t0, e16, m4, tu, ma
> > - vle16.v v8, (a1)
> > - vsetvli zero, t0, e8, m2, tu, ma
> > - vwsub.wv v16, v8, v0
> >
> > + vsetvli t0, a2, e16, m4, tu, ma
> > + vle16.v v8, (a1)
> > + sub a2, a2, t0
> > + vsetvli zero, t0, e8, m2, tu, ma
> > + vle8.v v0, (a0)
> > + vwsub.wv v16, v8, v0
>
> --
> 雷米‧德尼-库尔蒙
> 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 786c28b1c83b3cf033644c54ff32240f07b8082b Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Fri, 29 Dec 2023 13:27:31 +0800
Subject: [PATCH 3/3] lavc/svq1enc: R-V V ssd_int8_vs_int16
C908
ssd_int8_vs_int16_c: 207.7
ssd_int8_vs_int16_rvv_i32: 15.2
---
libavcodec/riscv/Makefile | 2 ++
libavcodec/riscv/svqenc_init.c | 41 +++
libavcodec/riscv/svqenc_rvv.S | 44 ++
libavcodec/svq1enc.c | 2 ++
libavcodec/svq1encdsp.h| 1 +
5 files changed, 90 insertions(+)
create mode 100644 libavcodec/riscv/svqenc_init.c
create mode 100644 libavcodec/riscv/svqenc_rvv.S
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 7f253bba12..4e14c3d094 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -46,6 +46,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_SVQ1_ENCODER) += riscv/svqenc_init.o
+RVV-OBJS-$(CONFIG_SVQ1_ENCODER) += riscv/svqenc_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
diff --git a/libavcodec/riscv/svqenc_init.c b/libavcodec/riscv/svqenc_init.c
new file mode 100644
index 00..f4c398960c
--- /dev/null
+++ b/libavcodec/riscv/svqenc_init.c
@@ -0,0 +1,41 @@
+/*
+ * 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 "config.h"
+
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavcodec/svq1encdsp.h"
+
+int ff_ssd_int8_vs_int16_rvv(const int8_t *pix1, const int16_t *pix2,
+ intptr_t size);
+
+av_cold void ff_svq1enc_init_riscv(SVQ1EncDSPContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if (flags & AV_CPU_FLAG_RVV_I32) {
+if (flags & AV_CPU_FLAG_RVB_ADDR) {
+c->ssd_int8_vs_int16 = ff_ssd_int8_vs_int16_rvv;
+}
+}
+#endif
+}
diff --git a/libavcodec/riscv/svqenc_rvv.S b/libavcodec/riscv/svqenc_rvv.S
new file mode 100644
index 00..b632eb39a9
--- /dev/null
+++ b/libavcodec/riscv/svqenc_rvv.S
@@ -0,0 +1,44 @@
+/*
+ * 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
+
Re: [FFmpeg-devel] [PATCH 3/3] lavc/svq1enc: R-V V ssd_int8_vs_int16
Le sunnuntaina 7. tammikuuta 2024, 3.33.39 EET flow gg a écrit : > I tested it, and indeed using vwsub is faster. Updated it in the reply. > > --- > > I have a question: if I tweak the load order a bit, using one less vset, it > leads to being slower (the patch I submitted is 13.2, if I make the > following change, the time would be 15.2). > But I thought it would be faster. I would guess that v0 is needed before v8 in the internal implementation of vwsub. This kind of makes sense as the element still need to be sign-extended. Thus vwsub ends up stalling the pipeline in wait for vle8 to complete. That's just a guess though, as I don't have internal cycle timing documentation. > - vsetvli t0, a2, e8, m2, tu, ma > - vle8.v v0, (a0) > - sub a2, a2, t0 > - vsetvli zero, t0, e16, m4, tu, ma > - vle16.v v8, (a1) > - vsetvli zero, t0, e8, m2, tu, ma > - vwsub.wv v16, v8, v0 > > + vsetvli t0, a2, e16, m4, tu, ma > + vle16.v v8, (a1) > + sub a2, a2, t0 > + vsetvli zero, t0, e8, m2, tu, ma > + vle8.v v0, (a0) > + vwsub.wv v16, v8, v0 -- 雷米‧德尼-库尔蒙 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".
