[FFmpeg-devel] [PATCH 4/4] lavc, lavd, lavf, lavfi, tests: remove several register() calls
From: Josh de Kock
---
doc/examples/filter_audio.c | 2 --
doc/examples/filtering_audio.c | 2 --
doc/examples/filtering_video.c | 2 --
doc/examples/transcoding.c | 2 --
fftools/ffmpeg.c | 6 --
fftools/ffplay.c | 7 ---
fftools/ffprobe.c| 4
libavcodec/tests/utils.c | 1 -
libavdevice/lavfi.c | 2 --
libavfilter/lavfutils.c | 2 --
libavfilter/src_movie.c | 2 --
libavfilter/tests/filtfmts.c | 2 --
libavformat/tests/movenc.c | 2 --
libavformat/tests/seek.c | 3 ---
tests/api/api-band-test.c| 2 --
tests/api/api-codec-param-test.c | 2 --
tests/api/api-flac-test.c| 2 --
tests/api/api-h264-test.c| 2 --
tests/api/api-seek-test.c| 2 --
tools/aviocat.c | 1 -
tools/enum_options.c | 2 --
tools/graph2dot.c| 2 --
tools/ismindex.c | 2 --
tools/pktdumper.c| 3 ---
tools/probetest.c| 3 ---
tools/seek_print.c | 1 -
tools/sidxindex.c| 2 --
tools/uncoded_frame.c| 4
28 files changed, 69 deletions(-)
diff --git a/doc/examples/filter_audio.c b/doc/examples/filter_audio.c
index 7467c21c30..1611e3d952 100644
--- a/doc/examples/filter_audio.c
+++ b/doc/examples/filter_audio.c
@@ -289,8 +289,6 @@ int main(int argc, char *argv[])
return 1;
}
-avfilter_register_all();
-
/* Allocate the frame we will be using to store the data. */
frame = av_frame_alloc();
if (!frame) {
diff --git a/doc/examples/filtering_audio.c b/doc/examples/filtering_audio.c
index 73a00e814c..b109dbcb96 100644
--- a/doc/examples/filtering_audio.c
+++ b/doc/examples/filtering_audio.c
@@ -228,8 +228,6 @@ int main(int argc, char **argv)
exit(1);
}
-avfilter_register_all();
-
if ((ret = open_input_file(argv[1])) < 0)
goto end;
if ((ret = init_filters(filter_descr)) < 0)
diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
index 01d6644620..ed4e7bbd81 100644
--- a/doc/examples/filtering_video.c
+++ b/doc/examples/filtering_video.c
@@ -222,8 +222,6 @@ int main(int argc, char **argv)
exit(1);
}
-avfilter_register_all();
-
if ((ret = open_input_file(argv[1])) < 0)
goto end;
if ((ret = init_filters(filter_descr)) < 0)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index ed1fd6411b..a83fa3a185 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -517,8 +517,6 @@ int main(int argc, char **argv)
return 1;
}
-avfilter_register_all();
-
if ((ret = open_input_file(argv[1])) < 0)
goto end;
if ((ret = open_output_file(argv[2])) < 0)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index ee7258fcd1..47236774ef 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4803,12 +4803,6 @@ int main(int argc, char **argv)
argv++;
}
-avcodec_register_all();
-#if CONFIG_AVDEVICE
-avdevice_register_all();
-#endif
-avfilter_register_all();
-av_register_all();
avformat_network_init();
show_banner(argc, argv, options);
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index f2028d4b13..05a1e7a68d 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -3652,13 +3652,6 @@ int main(int argc, char **argv)
parse_loglevel(argc, argv, options);
/* register all codecs, demux and protocols */
-#if CONFIG_AVDEVICE
-avdevice_register_all();
-#endif
-#if CONFIG_AVFILTER
-avfilter_register_all();
-#endif
-av_register_all();
avformat_network_init();
init_opts();
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index a4ac6972a2..540ad9f6fe 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -3567,12 +3567,8 @@ int main(int argc, char **argv)
options = real_options;
parse_loglevel(argc, argv, options);
-av_register_all();
avformat_network_init();
init_opts();
-#if CONFIG_AVDEVICE
-avdevice_register_all();
-#endif
show_banner(argc, argv, options);
parse_options(NULL, argc, argv, options, opt_input_file);
diff --git a/libavcodec/tests/utils.c b/libavcodec/tests/utils.c
index e2891fb389..f6ba7fe66e 100644
--- a/libavcodec/tests/utils.c
+++ b/libavcodec/tests/utils.c
@@ -21,7 +21,6 @@
int main(void){
AVCodec *codec = NULL;
int ret = 0;
-avcodec_register_all();
while (codec = av_codec_next(codec)) {
if (av_codec_is_encoder(codec)) {
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index 6f2ae958dc..ca8f05f3f7 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -130,8 +130,6 @@ av_cold static int lavfi_read_header(AVFormatContext *avctx)
if (!pix_fmts)
FAIL(AVERROR(ENOMEM));
-avfilter_register_all();
-
buffersink = avfilter_get_by_name("buffers
[FFmpeg-devel] [PATCH 1/4] checkasm/Makefile: add EXTRALIBS-libavformat
From: Josh de Kock --- tests/checkasm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile index 0520e264e2..ae7e810d25 100644 --- a/tests/checkasm/Makefile +++ b/tests/checkasm/Makefile @@ -61,7 +61,7 @@ tests/checkasm/checkasm.o: CFLAGS += -Umain CHECKASM := tests/checkasm/checkasm$(EXESUF) $(CHECKASM): $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS) - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter) $(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS) + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter) $(EXTRALIBS-avformat) $(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS) checkasm: $(CHECKASM) -- 2.14.3 (Apple Git-98) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] cmdutils: use new iteration APIs
From: Josh de Kock
---
fftools/cmdutils.c | 239 +
1 file changed, 112 insertions(+), 127 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 708a849f51..2da313cc0a 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1250,19 +1250,11 @@ int show_license(void *optctx, const char *opt, const
char *arg)
return 0;
}
-static int is_device(const AVClass *avclass)
-{
-if (!avclass)
-return 0;
-return AV_IS_INPUT_DEVICE(avclass->category) ||
AV_IS_OUTPUT_DEVICE(avclass->category);
-}
-
static int show_formats_devices(void *optctx, const char *opt, const char
*arg, int device_only, int muxdemuxers)
{
-AVInputFormat *ifmt = NULL;
-AVOutputFormat *ofmt = NULL;
+const AVInputFormat *ifmt = NULL;
+const AVOutputFormat *ofmt = NULL;
const char *last_name;
-int is_dev;
printf("%s\n"
" D. = Demuxing supported\n"
@@ -1270,46 +1262,38 @@ static int show_formats_devices(void *optctx, const
char *opt, const char *arg,
" --\n", device_only ? "Devices:" : "File formats:");
last_name = "000";
for (;;) {
-int decode = 0;
-int encode = 0;
+int is_ifmt = 0;
+int is_ofmt = 0;
const char *name = NULL;
const char *long_name = NULL;
-if (muxdemuxers !=SHOW_DEMUXERS) {
-while ((ofmt = av_oformat_next(ofmt))) {
-is_dev = is_device(ofmt->priv_class);
-if (!is_dev && device_only)
-continue;
-if ((!name || strcmp(ofmt->name, name) < 0) &&
-strcmp(ofmt->name, last_name) > 0) {
-name = ofmt->name;
-long_name = ofmt->long_name;
-encode= 1;
-}
-}
-}
-if (muxdemuxers != SHOW_MUXERS) {
-while ((ifmt = av_iformat_next(ifmt))) {
-is_dev = is_device(ifmt->priv_class);
-if (!is_dev && device_only)
-continue;
-if ((!name || strcmp(ifmt->name, name) < 0) &&
-strcmp(ifmt->name, last_name) > 0) {
-name = ifmt->name;
-long_name = ifmt->long_name;
-encode= 0;
-}
-if (name && strcmp(ifmt->name, name) == 0)
-decode = 1;
-}
-}
+#define x(func, type, condition) do { \
+void *i = 0;\
+if (condition) {\
+while ((type = func(&i))) { \
+if ((!name || strcmp(type->name, name) < 0) && \
+strcmp(type->name, last_name) > 0) {\
+name = type->name; \
+long_name = type->long_name;\
+is_ ## type = 1;\
+} \
+} \
+} } while(0)
+
+x(av_muxer_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS &&
!device_only);
+x(av_demuxer_iterate, ifmt, muxdemuxers != SHOW_MUXERS &&
!device_only);
+#if CONFIG_AVDEVICE
+x(av_outdev_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS);
+x(av_indev_iterate, ifmt, muxdemuxers != SHOW_MUXERS);
+#endif
+#undef x
if (!name)
break;
last_name = name;
printf(" %s%s %-15s %s\n",
- decode ? "D" : " ",
- encode ? "E" : " ",
+ is_ifmt ? "D" : " ",
+ is_ofmt ? "E" : " ",
name,
long_name ? long_name:" ");
}
@@ -1439,15 +1423,45 @@ static char get_media_type_char(enum AVMediaType type)
}
}
-static const AVCodec *next_codec_for_id(enum AVCodecID id, const AVCodec *prev,
-int encoder)
+
+static int compare_codec(const void *a, const void *b)
+{
+const AVCodec * const *ca = a;
+const AVCodec * const *cb = b;
+
+return strcmp((*ca)->name, (*cb)->name);
+}
+
+static unsigned get_codecs_sorted(enum AVCodecID id, const AVCodec ***rcodecs,
int encoder)
{
-while ((prev = av_codec_next(prev))) {
-if (prev->id == id &&
-(encoder ? av_codec_is_encoder(prev) : av_codec_is_decoder(prev)))
-return prev;
+const AVCodec *codec = NULL;
+const AVCodec **codecs;
[FFmpeg-devel] [PATCH 2/4] lavfi: add new iteration API
From: Josh de Kock
---
configure| 24 +-
doc/APIchanges | 4 +
doc/writing_filters.txt | 6 +-
libavfilter/allfilters.c | 818 +--
libavfilter/avfilter.c | 45 ---
libavfilter/avfilter.h | 29 +-
libavfilter/version.h| 3 +
7 files changed, 477 insertions(+), 452 deletions(-)
diff --git a/configure b/configure
index f09f48c54b..245b57d7cf 100755
--- a/configure
+++ b/configure
@@ -3557,15 +3557,6 @@ for v in "$@"; do
FFMPEG_CONFIGURATION="${FFMPEG_CONFIGURATION# } ${l}${r}"
done
-find_things(){
-thing=$1
-pattern=$2
-file=$source_path/$3
-sed -n "s/^[^#]*$pattern.*([^,]*, *\([^,]*\)\(,.*\)*).*/\1_$thing/p"
"$file"
-}
-
-FILTER_LIST=$(find_things filter FILTER libavfilter/allfilters.c)
-
find_things_extern(){
thing=$1
pattern=$2
@@ -3574,6 +3565,13 @@ find_things_extern(){
sed -n "s/^[^#]*extern.*$pattern *ff_\([^ ]*\)_$thing;/\1_$out/p" "$file"
}
+find_filters_extern(){
+file=$source_path/$1
+#sed -n "s/^extern AVFilter
ff_\([avfsinkrc]\{2,5\}\)_\(\w\+\);/\2_filter/p" $file
+sed -E -n "s/^extern AVFilter
ff_([avfsinkrc]{2,5})_([a-zA-Z0-9]+);/\2_filter/p" $file
+}
+
+FILTER_LIST=$(find_filters_extern libavfilter/allfilters.c)
OUTDEV_LIST=$(find_things_extern muxer AVOutputFormat libavdevice/alldevices.c
outdev)
INDEV_LIST=$(find_things_extern demuxer AVInputFormat libavdevice/alldevices.c
indev)
MUXER_LIST=$(find_things_extern muxer AVOutputFormat libavformat/allformats.c)
@@ -7083,6 +7081,10 @@ echo "#endif /* AVUTIL_AVCONFIG_H */" >> $TMPH
cp_if_changed $TMPH libavutil/avconfig.h
+full_filter_name(){
+sed -n "s/^extern AVFilter ff_\([avfsinkrc]\{2,5\}\)_$1;/\1_$1/p"
$source_path/libavfilter/allfilters.c
+}
+
# generate the lists of enabled components
print_enabled_components(){
file=$1
@@ -7093,6 +7095,9 @@ print_enabled_components(){
for c in $*; do
if enabled $c; then
case $name in
+filter_list)
+c=$(full_filter_name $(remove_suffix _filter $c))
+;;
indev_list)
c=$(add_suffix _demuxer $(remove_suffix _indev $c))
;;
@@ -7107,6 +7112,7 @@ print_enabled_components(){
cp_if_changed $TMPH $file
}
+print_enabled_components libavfilter/filter_list.c AVFilter filter_list
$FILTER_LIST
print_enabled_components libavcodec/codec_list.c AVCodec codec_list $CODEC_LIST
print_enabled_components libavcodec/parser_list.c AVCodecParser parser_list
$PARSER_LIST
print_enabled_components libavcodec/bsf_list.c AVBitStreamFilter
bitstream_filters $BSF_LIST
diff --git a/doc/APIchanges b/doc/APIchanges
index 4c0ee7147a..27cf2514d7 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
API changes, most recent first:
+2018-xx-xx - xxx - lavc 7.13.100 - avcodec.h
+ Deprecate use of avfilter_register(), avfilter_register_all(),
+ avfilter_next(). Add av_filter_iterate().
+
2018-03-18 - xxx - lavu 56.11.100 - frame.h
Add AV_FRAME_DATA_QP_TABLE_PROPERTIES and AV_FRAME_DATA_QP_TABLE_DATA.
diff --git a/doc/writing_filters.txt b/doc/writing_filters.txt
index 5cd4ecd6a4..98b9c6f3d2 100644
--- a/doc/writing_filters.txt
+++ b/doc/writing_filters.txt
@@ -31,10 +31,8 @@ If everything went right, you should get a foobar.png with
Lena edge-detected.
That's it, your new playground is ready.
Some little details about what's going on:
-libavfilter/allfilters.c:avfilter_register_all() is called at runtime to create
-a list of the available filters, but it's important to know that this file is
-also parsed by the configure script, which in turn will define variables for
-the build system and the C:
+libavfilter/allfilters.c:this file is parsed by the configure script, which in
turn
+will define variables for the build system and the C:
--- after running configure ---
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index cc423af738..23773aed09 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -23,409 +23,451 @@
#include "avfilter.h"
#include "config.h"
+extern AVFilter ff_af_abench;
+extern AVFilter ff_af_acompressor;
+extern AVFilter ff_af_acontrast;
+extern AVFilter ff_af_acopy;
+extern AVFilter ff_af_acrossfade;
+extern AVFilter ff_af_acrusher;
+extern AVFilter ff_af_adelay;
+extern AVFilter ff_af_aecho;
+extern AVFilter ff_af_aemphasis;
+extern AVFilter ff_af_aeval;
+extern AVFilter ff_af_afade;
+extern AVFilter ff_af_afftfilt;
+extern AVFilter ff_af_afir;
+extern AVFilter ff_af_aformat;
+extern AVFilter ff_af_agate;
+extern AVFilter ff_af_aiir;
+extern AVFilter ff_af_ainterleave;
+extern AVFilter ff_af_alimiter;
+extern AVFilter ff_af_allpass;
+extern AVFilter ff_af_alo
[FFmpeg-devel] [PATCH] avcodec/nvenc: Fix segfault with intra-only
In intra-only mode, frameIntervalP is 0, which means the frame data array is smaller than the number of surfaces. This causes a crash when closing the encoder. Fix this by making sure the frame data array is at least as big as the number of surfaces. --- libavcodec/nvenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index a9945355ba..93e87b21db 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -1021,7 +1021,7 @@ static av_cold int nvenc_recalc_surfaces(AVCodecContext *avctx) // Output in the worst case will only start when the surface buffer is completely full. // Hence we need to keep at least the max amount of surfaces plus the max reorder delay around. -ctx->frame_data_array_nb = ctx->nb_surfaces + ctx->encode_config.frameIntervalP - 1; +ctx->frame_data_array_nb = FFMAX(ctx->nb_surfaces, ctx->nb_surfaces + ctx->encode_config.frameIntervalP - 1); return 0; } -- 2.39.2 ___ ffmpeg-devel mailing list ffmpeg-devel@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/nvenc: Fix segfault with intra-only
On Thu, 20 Jun 2024 at 17:39, Josh Allmann wrote: > > In intra-only mode, frameIntervalP is 0, which means the frame > data array is smaller than the number of surfaces. This causes a > crash when closing the encoder. > > Fix this by making sure the frame data array is at least as big as > the number of surfaces. > --- > libavcodec/nvenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c > index a9945355ba..93e87b21db 100644 > --- a/libavcodec/nvenc.c > +++ b/libavcodec/nvenc.c > @@ -1021,7 +1021,7 @@ static av_cold int nvenc_recalc_surfaces(AVCodecContext > *avctx) > > // Output in the worst case will only start when the surface buffer is > completely full. > // Hence we need to keep at least the max amount of surfaces plus the > max reorder delay around. > -ctx->frame_data_array_nb = ctx->nb_surfaces + > ctx->encode_config.frameIntervalP - 1; > +ctx->frame_data_array_nb = FFMAX(ctx->nb_surfaces, ctx->nb_surfaces + > ctx->encode_config.frameIntervalP - 1); > > return 0; > } > -- > 2.39.2 > Hello, Ping for review. This patch fixes an easily triggered crash with nvenc in intra-only mode, eg ffmpeg -i -c:v h264_nvenc -g 0 Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] lavfi/vf_scale_cuda: Add format option
Makes certain usages of the lavfi API easier.
---
libavfilter/vf_scale_cuda.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index b7cdb81081..6b1ef2bb6f 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libavfilter/vf_scale_cuda.c
@@ -81,6 +81,7 @@ typedef struct CUDAScaleContext {
char *w_expr; ///< width expression string
char *h_expr; ///< height expression string
+char *format_str;
CUcontext cu_ctx;
CUmodulecu_module;
@@ -101,7 +102,15 @@ static av_cold int cudascale_init(AVFilterContext *ctx)
{
CUDAScaleContext *s = ctx->priv;
-s->format = AV_PIX_FMT_NONE;
+if (!strcmp(s->format_str, "same")) {
+s->format = AV_PIX_FMT_NONE;
+} else {
+s->format = av_get_pix_fmt(s->format_str);
+if (s->format == AV_PIX_FMT_NONE) {
+av_log(ctx, AV_LOG_ERROR, "Unrecognized pixel format: %s\n",
s->format_str);
+return AVERROR(EINVAL);
+}
+}
s->frame = av_frame_alloc();
if (!s->frame)
return AVERROR(ENOMEM);
@@ -533,6 +542,7 @@ fail:
static const AVOption options[] = {
{ "w", "Output video width", OFFSET(w_expr), AV_OPT_TYPE_STRING,
{ .str = "iw" }, .flags = FLAGS },
{ "h", "Output video height", OFFSET(h_expr), AV_OPT_TYPE_STRING,
{ .str = "ih" }, .flags = FLAGS },
+{ "format", "Output pixel format", OFFSET(format_str), AV_OPT_TYPE_STRING,
{ .str = "same" }, .flags = FLAGS },
{ NULL },
};
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi/vf_scale_cuda: Add format option
On Fri, 24 May 2019 at 06:00, Timo Rothenpieler wrote:
>
> On 24/05/2019 01:49, Josh Allmann wrote:
> > Makes certain usages of the lavfi API easier.
> > ---
> > libavfilter/vf_scale_cuda.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
> > index b7cdb81081..6b1ef2bb6f 100644
> > --- a/libavfilter/vf_scale_cuda.c
> > +++ b/libavfilter/vf_scale_cuda.c
> > @@ -81,6 +81,7 @@ typedef struct CUDAScaleContext {
> >
> > char *w_expr; ///< width expression string
> > char *h_expr; ///< height expression string
> > +char *format_str;
> >
> > CUcontext cu_ctx;
> > CUmodulecu_module;
> > @@ -101,7 +102,15 @@ static av_cold int cudascale_init(AVFilterContext *ctx)
> > {
> > CUDAScaleContext *s = ctx->priv;
> >
> > -s->format = AV_PIX_FMT_NONE;
> > +if (!strcmp(s->format_str, "same")) {
> > +s->format = AV_PIX_FMT_NONE;
> > +} else {
> > +s->format = av_get_pix_fmt(s->format_str);
> > +if (s->format == AV_PIX_FMT_NONE) {
> > +av_log(ctx, AV_LOG_ERROR, "Unrecognized pixel format: %s\n",
> > s->format_str);
> > +return AVERROR(EINVAL);
> > +}
> > +}
> > s->frame = av_frame_alloc();
> > if (!s->frame)
> > return AVERROR(ENOMEM);
> > @@ -533,6 +542,7 @@ fail:
> > static const AVOption options[] = {
> > { "w", "Output video width", OFFSET(w_expr),
> > AV_OPT_TYPE_STRING, { .str = "iw" }, .flags = FLAGS },
> > { "h", "Output video height", OFFSET(h_expr),
> > AV_OPT_TYPE_STRING, { .str = "ih" }, .flags = FLAGS },
> > +{ "format", "Output pixel format", OFFSET(format_str),
> > AV_OPT_TYPE_STRING, { .str = "same" }, .flags = FLAGS },
> > { NULL },
> > };
>
> I'm not sure what to think about a dummy option like this. It might be
> very confusing for users to see a format option, which only accepts a
> single value, "same", and effectively does nothing.
>
Not sure I understand the issue. "same" is the default (terminology
borrowed from the scale_npp filter), and it'll assign the format to
whatever is passed in (eg, format=yuv420p assigns that).
>
> Not strictly against it, since I can see the convenience it adds when
> building command lines, but I'd like some second opinions on this.
>
Actually I'm using the API, albeit with some of lavfi conveniences to
parse filter strings. This avoids "wiring in" the output format
manually when crossing the lavfi boundary.
Here's a example that demonstrates the issue via CLI (this may
actually be a bug elsewhere?):
Broken:
ffmpeg -loglevel verbose -hwaccel cuvid -c:v h264_cuvid -i input.ts
-an -lavfi scale_cuda=w=426:h=240,hwdownload,format=yuv420p -c:v
libx264 out.ts
Working:
ffmpeg -loglevel verbose -hwaccel cuvid -c:v h264_cuvid -i input.ts
-an -lavfi scale_cuda=w=426:h=240:format=yuv420p,hwdownload,format=yuv420p
-c:v libx264 out.ts
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavfi/vf_scale_cuda: Reset frame size after acquiring from hwframe.
The first frame is scaled correctly, and subsequent frames are over-scaled / cropped since the frame data is reset with the hwframe after each invocation of the scaler. The hwframe-allocated frame has a width/height that is 32-bit aligned. The scaler uses this aligned width / height as its target, leading to "over-scaling" and then cropping of the result. To generate a broken test sample: ffmpeg -hwaccel cuvid -c:v h264_cuvid -i -an \ -lavfi scale_cuda=w=426:h=240 -c:v h264_nvenc --- Tested with NV12 and 420P inputs. Noting that YUV444P seems generally broken - both before/after this patch. libavfilter/vf_scale_cuda.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c index 6b1ef2bb6f..13eb3ad24c 100644 --- a/libavfilter/vf_scale_cuda.c +++ b/libavfilter/vf_scale_cuda.c @@ -489,6 +489,8 @@ static int cudascale_scale(AVFilterContext *ctx, AVFrame *out, AVFrame *in) av_frame_move_ref(out, s->frame); av_frame_move_ref(s->frame, s->tmp_frame); +s->frame->width = s->planes_out[0].width; +s->frame->height= s->planes_out[0].height; ret = av_frame_copy_props(out, in); if (ret < 0) -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi/vf_scale_cuda: Add format option
On Fri, 24 May 2019 at 09:55, Timo Rothenpieler wrote:
>
> On 24.05.2019 18:27, Josh Allmann wrote:
> > On Fri, 24 May 2019 at 06:00, Timo Rothenpieler
> > wrote:
> >>
> >> On 24/05/2019 01:49, Josh Allmann wrote:
> >>> Makes certain usages of the lavfi API easier.
> >>> ---
> >>>libavfilter/vf_scale_cuda.c | 12 +++-
> >>>1 file changed, 11 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
> >>> index b7cdb81081..6b1ef2bb6f 100644
> >>> --- a/libavfilter/vf_scale_cuda.c
> >>> +++ b/libavfilter/vf_scale_cuda.c
> >>> @@ -81,6 +81,7 @@ typedef struct CUDAScaleContext {
> >>>
> >>>char *w_expr; ///< width expression string
> >>>char *h_expr; ///< height expression string
> >>> +char *format_str;
> >>>
> >>>CUcontext cu_ctx;
> >>>CUmodulecu_module;
> >>> @@ -101,7 +102,15 @@ static av_cold int cudascale_init(AVFilterContext
> >>> *ctx)
> >>>{
> >>>CUDAScaleContext *s = ctx->priv;
> >>>
> >>> -s->format = AV_PIX_FMT_NONE;
> >>> +if (!strcmp(s->format_str, "same")) {
> >>> +s->format = AV_PIX_FMT_NONE;
> >>> +} else {
> >>> +s->format = av_get_pix_fmt(s->format_str);
> >>> +if (s->format == AV_PIX_FMT_NONE) {
> >>> +av_log(ctx, AV_LOG_ERROR, "Unrecognized pixel format: %s\n",
> >>> s->format_str);
> >>> +return AVERROR(EINVAL);
> >>> +}
> >>> +}
> >>>s->frame = av_frame_alloc();
> >>>if (!s->frame)
> >>>return AVERROR(ENOMEM);
> >>> @@ -533,6 +542,7 @@ fail:
> >>>static const AVOption options[] = {
> >>>{ "w", "Output video width", OFFSET(w_expr),
> >>> AV_OPT_TYPE_STRING, { .str = "iw" }, .flags = FLAGS },
> >>>{ "h", "Output video height", OFFSET(h_expr),
> >>> AV_OPT_TYPE_STRING, { .str = "ih" }, .flags = FLAGS },
> >>> +{ "format", "Output pixel format", OFFSET(format_str),
> >>> AV_OPT_TYPE_STRING, { .str = "same" }, .flags = FLAGS },
> >>>{ NULL },
> >>>};
> >>
> >> I'm not sure what to think about a dummy option like this. It might be
> >> very confusing for users to see a format option, which only accepts a
> >> single value, "same", and effectively does nothing.
> >>
> >
> > Not sure I understand the issue. "same" is the default (terminology
> > borrowed from the scale_npp filter), and it'll assign the format to
> > whatever is passed in (eg, format=yuv420p assigns that).
>
> Oh, I misread that code as just always throwing an error if it's != "same".
>
> Unfortunately, that option is omitted for a reason.
> If you look at scalecuda_resize:
> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_scale_cuda.c;h=b7cdb81081ff4a34e7b641c533fc23a5714fed61;hb=HEAD#l380
>
> It has the assumption built into it that the output frame has the same
> format as the input frame. So if you were to set format=nv12 and then
> input a yuv420p frame, this will most likely crash or at least severely
> misbehave.
>
> I would not be opposed to scale_cuda gaining the ability to also change
> frame pix_fmts, we are lacking such a filter at the moment if one
> ignores scale_npp.
> But in its current state, it can't do that.
>
Ah! Makes sense now - thanks for the explanation.
> >>
> >> Not strictly against it, since I can see the convenience it adds when
> >> building command lines, but I'd like some second opinions on this.
> >>
> >
> > Actually I'm using the API, albeit with some of lavfi conveniences to
> > parse filter strings. This avoids "wiring in" the output format
> > manually when crossing the lavfi boundary.
> >
> > Here's a example that demonstrates the issue via CLI (this may
> > actually be a bug elsewhere?):
> >
> > Broken:
> > ffmpeg -loglevel verbose -hwaccel cuvid -c:v h264_cuvid -i input.ts
> > -an -lavfi scale_cuda=w=426:h=240,hwdownload,format=yuv420p -c:v
> > libx264 out.ts
> >
> > Working:
> > ffmpeg -loglevel verbose -hwaccel cuvid -c:v h264_cuvid -i input.ts
> > -an -lavfi scale_cuda=w=426:h=240:format=yuv420p,hwdownload,format=yuv420p
> > -c:v libx264 out.ts
>
> Is this actually working in a sense where the result looks sensible?
> Cause with how the code currently is, scale_cuda with format set to
> yuv420p and getting nv12 as input from h264_cuvid will produce a frame
> labeled as yuv420p but containing nv12 data.
>
You are correct - I didn't look at the output here.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavfi: add new iteration API
Hi, On Sat, 24 Mar 2018 at 14:40, Josh de Kock wrote: > > Signed-off-by: Josh de Kock > --- > configure| 29 +- > doc/APIchanges | 4 + > doc/writing_filters.txt | 6 +- > libavfilter/allfilters.c | 823 > +-- > libavfilter/avfilter.c | 50 +-- > libavfilter/avfilter.h | 29 +- > libavfilter/version.h| 3 + > 7 files changed, 489 insertions(+), 455 deletions(-) > This is a couple years too late, but wanted to drop a note that this particular API change was breaking : it made avfilter_register a no-op. The consequence is that it's much more difficult to maintain filters out-of-tree; preserving the old behavior without changes to user code requires a special build of ffmpeg that has the filter configured/compiled in. The recommended workaround of using avfilter_graph_alloc_filter requires more effort to wire the filter in explicitly. It also doesn't allow for conveniences such as using avfilter_graph_parse, since there doesn't seem to be a way to make filters accessible via avfilter_get_by_name outside of ffmpeg compile time. If there is another workaround that I'm missing, please let me know, or if there's some deeper rationale for the decision to disable this feature. Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avcodec: Add explicit capability flag for encoder flushing
On Mon, 13 Apr 2020 at 04:39, Anton Khirnov wrote: > > Quoting Philip Langdale (2020-04-11 01:47:43) > > We've been in this fuzzy situation where maybe you could call > > avcodec_flush_buffers() on an encoder but there weren't any encoders > > that supported it except maybe audiotoolboxenc. Then we added flush > > support to nvenc very intentionally, and it worked, but that was more a > > coincidence than anything else. And if you call avcodec_flush_buffers() > > on an encoder that doesn't support it, it'll leave the encoder in an > > undefined state, so that's not great. > > > > As part of cleaning this up, this change introduces a formal capability > > flag for encoders that support flushing and ensures a flush call is a > > no-op for any other encoder. This allows client code to check if it is > > meaningful to call flush on an encoder before actually doing it. > > > > I have not attempted to separate the steps taken inside > > avcodec_flush_buffers() because it's not doing anything that's wrong > > for an encoder. But I did add a sanity check to reject attempts to > > flush a frame threaded encoder because I couldn't wrap my head around > > whether that code path was actually safe or not. As this combination > > doesn't exist today, we'll deal with it if it ever comes up. > > > > Signed-off-by: Philip Langdale > > --- > > I'm missing two things here: > - motivation in the commit message (and possibly in the doxy too) - why > is this needed and how is it better than just closing the encoder and > creating a new one One use case is segmented encoding: processing one segment at a time, where closing and re-opening a new encoder is expensive (as is the case with HW / nvenc). The original writeup for the motivation leading up to "encoder flush" can be found here: https://patchwork.ffmpeg.org/project/ffmpeg/patch/1574125994-7782-1-git-send-email-joshua.allm...@gmail.com/ Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] lavfi: add new iteration API
On Tue, 14 Apr 2020 at 01:53, Josh de Kock wrote: > > Hi, > > On Mon, Apr 13, 2020, at 10:32 PM, Josh Allmann wrote: > > Hi, > > > > On Sat, 24 Mar 2018 at 14:40, Josh de Kock wrote: > > > > > > Signed-off-by: Josh de Kock > > > --- > > > configure| 29 +- > > > doc/APIchanges | 4 + > > > doc/writing_filters.txt | 6 +- > > > libavfilter/allfilters.c | 823 > > > +-- > > > libavfilter/avfilter.c | 50 +-- > > > libavfilter/avfilter.h | 29 +- > > > libavfilter/version.h| 3 + > > > 7 files changed, 489 insertions(+), 455 deletions(-) > > > > > > > This is a couple years too late, but wanted to drop a note that this > > particular API change was breaking : it made avfilter_register a > > no-op. The consequence is that it's much more difficult to maintain > > filters out-of-tree; preserving the old behavior without changes to > > user code requires a special build of ffmpeg that has the filter > > configured/compiled in. The recommended workaround of using > > avfilter_graph_alloc_filter requires more effort to wire the filter in > > explicitly. It also doesn't allow for conveniences such as using > > avfilter_graph_parse, since there doesn't seem to be a way to make > > filters accessible via avfilter_get_by_name outside of ffmpeg compile > > time. > > > > If there is another workaround that I'm missing, please let me know, > > or if there's some deeper rationale for the decision to disable this > > feature. > > This was actually an intentional change, there was some trouble with how > external codecs/filters/etc should be handled. > > Since this was an unsupported use-case which was quite sensitive to ABI the > change was there to explicitly prevent people (ab)using the API like this. It > was also to prepare for potentially a new API to implement this in a proper > fashion (but as you can see this was never completed). > > I did begin working on this again a little while back but due to an > unfortunate > data-loss I will have to start from scratch to continue working on it (yes, > yes > 'where's your backup?' I know). It's likely to be something I will be working > on in the future since I will be doing FFmpeg stuff again soon. > > There is also the discussion of 'do we want this?' from a more ideological > perspective which we will have to re-discuss, maybe something like gstreamer > is > more suited for the majority of the use-cases (?). > Thanks for the explanation Josh. For what it's worth, count me as being at least one API user for which out-of-tree filter capability would be very helpful. (And to preempt some other reactions, "use gstreamer" is not really helpful for us either...) Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] libavcodec/libx264: fix reference frame computation based on level
Hell, can someone please review this patch? It fixes a wrong reference frame
computation problem when using parameters such as "-level 31" instead of
"-level 3.1".
From 9f9dcb3cceebb360468fea762b01780f65764a47 Mon Sep 17 00:00:00 2001
From: Josh Brewster
Date: Thu, 16 Apr 2020 22:50:29 +0200
Subject: [PATCH] libavcodec/libx264: fix reference frame computation based on
level
The current implementation allows passing levels to libavcodec as
integers (such as "31" instead of "3.1").
However, in this case, the maximum reference frame value per level was
ignored because libavcodec converted the string to 310 instead of 31.
This commit changes the way levels are converted to int from strings,
following an algoritm similar to that of x264 (currently defined in
common/base.c).
Signed-off-by: Josh Brewster
---
libavcodec/libx264.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index a08fe0ce76..1149f2d668 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -701,11 +701,14 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (!strcmp(x4->level, "1b")) {
level_id = 9;
-} else if (strlen(x4->level) <= 3){
+} else if (av_strtod(x4->level, NULL) < 7){
level_id = av_strtod(x4->level, &tail) * 10 + 0.5;
if (*tail)
level_id = -1;
}
+else {
+level_id = av_strtod(x4->level, NULL);
+}
if (level_id <= 0)
av_log(avctx, AV_LOG_WARNING, "Failed to parse level\n");
--
2.26.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] libavcodec/libx264: fix reference frame computation based on level
> Hi,
>
> > From: ffmpeg-devel ffmpeg-devel-boun...@ffmpeg.org On Behalf Of
> > josh.brews...@protonmail.com
> > Sent: Friday, April 17, 2020 07:05
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH] libavcodec/libx264: fix reference frame
> > computation based on level
> > Hell, can someone please review this patch? It fixes a wrong reference frame
> > computation problem when using parameters such as "-level 31" instead of
> > "-level 3.1".
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> > index a08fe0ce76..1149f2d668 100644
> > --- a/libavcodec/libx264.c
> > +++ b/libavcodec/libx264.c
> > @@ -701,11 +701,14 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >
> > if (!strcmp(x4->level, "1b")) {
> > level_id = 9;
> >
> >
> > - } else if (strlen(x4->level) <= 3){
> >
> >
> >
> > - } else if (av_strtod(x4->level, NULL) < 7){
> >level_id = av_strtod(x4->level, &tail) * 10 + 0.5;
> >if (*tail)
> >level_id = -1;
> >}
> >
> >
> > - else {
> >
> >
>
> Wrong coding style for "else", should be "} else {"
>
> > - level_id = av_strtod(x4->level, NULL);
> >
> >
> > - }
> >if (level_id <= 0)
> >av_log(avctx, AV_LOG_WARNING, "Failed to parse level\\n");
> >
> >
>
> This part of code of parsing level_id seems redundant, since
> PARSE_X264_OPT("level", level) has
> been called and did the same thing inside libx264, which converts x4->level
> to x4->params.i_level_idc
> correctly (equals 31), regardless of "-level 3.1 or level 31".
>
> Hence it would be better to use x4->params.i_level_idc directly.
>
> - Linjie
>
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Hi Linjie, thanks for the feedback. I have changed the patch to use the right
parameter. I only made sure that the level was positive because its initial
value was -1.
> else if (x4->params.i_level_idc >= 0) {
Let me know if I need to reject 0 too. It seemed like premature optimization as
the level simply wouldn't be present in x264_levels.
From 98344809c22d574959eb4351a1cc03f431b4617c Mon Sep 17 00:00:00 2001
From: Josh Brewster
Date: Thu, 16 Apr 2020 22:50:29 +0200
Subject: [PATCH] libavcodec/libx264: fix reference frame computation based on
level
The current implementation allows passing levels to libavcodec as
integers (such as "31" instead of "3.1").
However, in this case, the maximum reference frame value per level was
ignored because libavcodec converted the string to 310 instead of 31.
Since libx264 has correctly parsed the level to int
(x4->params.i_level_idc), we should rely on this value instead of
attempting to parse the level string on our own.
Signed-off-by: Josh Brewster
---
libavcodec/libx264.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index a08fe0ce76..a4caa5b5db 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -692,25 +692,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
x4->params.rc.f_qcompress = avctx->qcompress; /* 0.0 => cbr, 1.0 => constant qp */
if (avctx->refs >= 0)
x4->params.i_frame_reference= avctx->refs;
-else if (x4->level) {
+else if (x4->params.i_level_idc >= 0) {
int i;
int mbn = AV_CEIL_RSHIFT(avctx->width, 4) * AV_CEIL_RSHIFT(avctx->height, 4);
-int level_id = -1;
-char *tail;
int scale = X264_BUILD < 129 ? 384 : 1;
-if (!strcmp(x4->level, "1b")) {
-level_id = 9;
-} else if (strlen(x4->level) <= 3){
-level_id = av_strtod(x4->level, &tail) * 10 + 0.5;
-if (*tail)
-level_id = -1;
-}
-if (level_id <= 0)
-av_log(avctx, AV_LOG_WARNING, "Failed to parse level\n");
-
for (i = 0; iparams.i_level_idc)
x4->params.i_frame_reference = av_clip(x264_levels[i].dpb / mbn / scale, 1, x4->params.i_frame_reference);
}
--
2.26.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference frame computation based on level
> >I only made sure that the level was positive because its initial
> > value was -1.
> >
> > > else if (x4->params.i_level_idc >= 0) {
> > > Let me know if I need to reject 0 too. It seemed like premature
> > > optimization
> > > as the level simply wouldn't be present in x264_levels.
>
> I'd say yes, level_idc = 0 is possible but invalid by PARSE_X264_OPT(), which
> seems
> make no sense to calculate refs from x264_levels[] table.
>
> - Linjie
Changed to > 0, thanks.
From af09a7c3d33db90092be3dea57ba449884003246 Mon Sep 17 00:00:00 2001
From: Josh Brewster
Date: Thu, 16 Apr 2020 22:50:29 +0200
Subject: [PATCH] libavcodec/libx264: fix reference frame computation based on
level
The current implementation allows passing levels to libavcodec as
integers (such as "31" instead of "3.1").
However, in this case, the maximum reference frame value per level was
ignored because libavcodec converted the string to 310 instead of 31.
Since libx264 has correctly parsed the level to int
(x4->params.i_level_idc), we should rely on this value instead of
attempting to parse the level string on our own.
Signed-off-by: Josh Brewster
---
libavcodec/libx264.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index a08fe0ce76..c6cce9ff80 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -692,25 +692,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
x4->params.rc.f_qcompress = avctx->qcompress; /* 0.0 => cbr, 1.0 => constant qp */
if (avctx->refs >= 0)
x4->params.i_frame_reference= avctx->refs;
-else if (x4->level) {
+else if (x4->params.i_level_idc > 0) {
int i;
int mbn = AV_CEIL_RSHIFT(avctx->width, 4) * AV_CEIL_RSHIFT(avctx->height, 4);
-int level_id = -1;
-char *tail;
int scale = X264_BUILD < 129 ? 384 : 1;
-if (!strcmp(x4->level, "1b")) {
-level_id = 9;
-} else if (strlen(x4->level) <= 3){
-level_id = av_strtod(x4->level, &tail) * 10 + 0.5;
-if (*tail)
-level_id = -1;
-}
-if (level_id <= 0)
-av_log(avctx, AV_LOG_WARNING, "Failed to parse level\n");
-
for (i = 0; iparams.i_level_idc)
x4->params.i_frame_reference = av_clip(x264_levels[i].dpb / mbn / scale, 1, x4->params.i_frame_reference);
}
--
2.26.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] libavcodec/libx264: fix reference frame computation based on level
> > > I only made sure that the level was positive because its initial
> > > value was -1.
> > >
> > > > else if (x4->params.i_level_idc >= 0) {
> > > > Let me know if I need to reject 0 too. It seemed like premature
> > > > optimization
> > > > as the level simply wouldn't be present in x264_levels.
> >
> > I'd say yes, level_idc = 0 is possible but invalid by PARSE_X264_OPT(),
> > which seems
> > make no sense to calculate refs from x264_levels[] table.
> >
> > - Linjie
>
> Changed to > 0, thanks.
Hi, is there anything else I need to do to have this merged?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/4] avcodec/aarch64/hevcdsp
Set pushed with all Martin's changes implemented. More NEON & updates soon. -- Josh On 2021-02-04 12:32, Josh Dekker wrote: Hi, Rebases the unpushed part of my patches on top of Reimar's set. Also implements Martin's suggestions except 'unrolling the loop' for SAO band function, will update the band function when I fix non 8x8 cases. ___ ffmpeg-devel mailing list ffmpeg-devel@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] checkasm: add (private) kperf timing for macOS
Signed-off-by: Josh Dekker
---
configure| 2 +
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c| 19 -
tests/checkasm/checkasm.h| 10 ++-
tests/checkasm/macos_kperf.c | 143 +++
tests/checkasm/macos_kperf.h | 23 ++
6 files changed, 195 insertions(+), 3 deletions(-)
create mode 100644 tests/checkasm/macos_kperf.c
create mode 100644 tests/checkasm/macos_kperf.h
diff --git a/configure b/configure
index d7a3f507e8..a47e3dea67 100755
--- a/configure
+++ b/configure
@@ -490,6 +490,7 @@ Developer options (useful when working on FFmpeg itself):
--ignore-tests=TESTS comma-separated list (without "fate-" prefix
in the name) of tests whose result is ignored
--enable-linux-perf enable Linux Performance Monitor API
+ --enable-macos-kperf enable macOS kperf (private) API
--disable-large-testsdisable tests that use a large amount of memory
NOTE: Object files are built at the place where configure is launched.
@@ -1949,6 +1950,7 @@ CONFIG_LIST="
fontconfig
large_tests
linux_perf
+macos_kperf
memory_poisoning
neon_clobber_test
ossfuzz
diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 1827a4e134..4abaef9c63 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -58,6 +58,7 @@ CHECKASMOBJS-$(CONFIG_AVUTIL) += $(AVUTILOBJS)
CHECKASMOBJS-$(ARCH_AARCH64)+= aarch64/checkasm.o
CHECKASMOBJS-$(HAVE_ARMV5TE_EXTERNAL) += arm/checkasm.o
CHECKASMOBJS-$(HAVE_X86ASM) += x86/checkasm.o
+CHECKASMOBJS-$(CONFIG_MACOS_KPERF) += macos_kperf.o
CHECKASMOBJS += $(CHECKASMOBJS-yes) checkasm.o
CHECKASMOBJS := $(sort $(CHECKASMOBJS:%=tests/checkasm/%))
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 8338e8ff58..4c42040244 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -26,6 +26,8 @@
# ifndef _GNU_SOURCE
# define _GNU_SOURCE // for syscall (performance monitoring API)
# endif
+#elif CONFIG_MACOS_KPERF
+#include "macos_kperf.h"
#endif
#include
@@ -637,9 +639,20 @@ static int bench_init_linux(void)
}
return 0;
}
-#endif
+#elif CONFIG_MACOS_KPERF
+static int bench_init_kperf(void)
+{
+if (ff_kperf_init() || ff_kperf_setup())
+return -1;
-#if !CONFIG_LINUX_PERF
+if (ff_kperf_cycles(NULL)) {
+fprintf(stderr, "checkasm must be run as root to use kperf on
macOS\n");
+return -1;
+}
+
+return 0;
+}
+#else
static int bench_init_ffmpeg(void)
{
#ifdef AV_READ_TIME
@@ -656,6 +669,8 @@ static int bench_init(void)
{
#if CONFIG_LINUX_PERF
int ret = bench_init_linux();
+#elif CONFIG_MACOS_KPERF
+int ret = bench_init_kperf();
#else
int ret = bench_init_ffmpeg();
#endif
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index ef6645e3a2..4127081d74 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -31,6 +31,8 @@
#include
#include
#include
+#elif CONFIG_MACOS_KPERF
+#include "macos_kperf.h"
#endif
#include "libavutil/avstring.h"
@@ -224,7 +226,7 @@ typedef struct CheckasmPerf {
int iterations;
} CheckasmPerf;
-#if defined(AV_READ_TIME) || CONFIG_LINUX_PERF
+#if defined(AV_READ_TIME) || CONFIG_LINUX_PERF || CONFIG_MACOS_KPERF
#if CONFIG_LINUX_PERF
#define PERF_START(t) do { \
@@ -235,6 +237,12 @@ typedef struct CheckasmPerf {
ioctl(sysfd, PERF_EVENT_IOC_DISABLE, 0);\
read(sysfd, &t, sizeof(t)); \
} while (0)
+#elif CONFIG_MACOS_KPERF
+#define PERF_START(t) do { \
+t = 0; \
+ff_kperf_cycles(&t);\
+} while (0)
+#define PERF_STOP(t) ff_kperf_cycles(&t)
#else
#define PERF_START(t) t = AV_READ_TIME()
#define PERF_STOP(t) t = AV_READ_TIME() - t
diff --git a/tests/checkasm/macos_kperf.c b/tests/checkasm/macos_kperf.c
new file mode 100644
index 00..e6ae316608
--- /dev/null
+++ b/tests/checkasm/macos_kperf.c
@@ -0,0 +1,143 @@
+/*
+ * 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 US
Re: [FFmpeg-devel] [PATCH v4 1/2] lavc/aarch64: change h264pred_init structure
Set applied. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] libavcodec/libx264: fix reference frame computation based on level
> > From: ffmpeg-devel ffmpeg-devel-boun...@ffmpeg.org On Behalf Of > > Josh de Kock > > Sent: Tuesday, April 28, 2020 23:47 > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference > > frame computation based on level > > On 26/04/2020 12:46, Josh Brewster wrote: > > > > > Hi, is there anything else I need to do to have this merged? > > > > From a precursory look at what x264 and we're doing here your patch is > > correct. It doesn't break from a quick test, and looks OK to me. Would > > rather someone else has a look at it too but I will again in a couple > > days if no one does. > > Should be ok IMHO, thx. > > - Linjie Thanks for the feedback, I'll wait for it to be merged then. ___ ffmpeg-devel mailing list ffmpeg-devel@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][DISCUSS] nvenc: Add encoder flush API.
This patch is meant to be an entry point for discussion around an
issue we are having with flushing the nvenc encoder while doing
segmented transcoding. Hopefully there will be a less kludgey
workaround than this.
First, some background some info on where this is coming from. We do
segmented transcoding on Nvidia GPUs using the libav* libraries [0].
The flow is roughly this:
1. Segment incoming stream
2. Send each segment to a transcoder
We've noticed a significant overhead around setting up new transcode
sessions / contexts for each segment, and this overhead is magnified
the more streams a given machine is processing, regardless of the
number of attached GPUs [1].
Now, the logical solution here would be to reuse the GPU sessions
for segments during a given stream. However, there is a problem
around flushing internal decode / encode buffers. Because we do
segmented transcoding [2], we need to ensure that all stages in the
transcode pipeline are completely flushed in between each segment.
Here is what we do for each stage of decode, filter and encode:
* Decoding : Cache the first packet of each segment. When the
IO layer EOFs, feed the cached packet with a sentinel pts of -1.
(This doesn't seem to cause issues with h264_cuvid.) Once a frame
is returned from the decoder with the sentinel pts set, we know
the decoder is flushed of legitimate input. For a typical 2-second
segment, this has typically added about 6 frames (~10%) of overhead
which is tolerable because decoding is typically less expensive than
encoding, No changes are required to FFmpeg itself, which is nice.
* Filtering : Close the filtergraph (via av_buffersrc_close) and re-
initialize the filter with each segment. Again, the overhead here
seems tolerable. Have not seen a straightforward way to drain the
filtergraph without also closing or re-opening it.
* Encoding : This patch.
We add a very special "av_nvenc_flush" API to signal end-of-stream
in the same way as `avcodec_send_packet(ctx, NULL)` but bypassing
all the higher-level libavcodec machinery before hitting nvenc.
This seems to successfully drain pending frames. Afterwards,
we can continue to send packets for the next segments via
`avcodec_send_packet` and the internal state will more-or-less
reinitialize as if nothing had happened.
Now, it is quite likely that this behavior is entirely accidental,
and should not be expected to be stable in the future.
While the nvenc encoder itself does seem to be "resumable" according
to the documentation around the `NV_ENC_FLAGS_EOS` flag (cf.
NVIDIA Video Encoder API Programming Guide), FFmpeg has no such
mode. So we've had to sort of inject one in here.
The questions here are:
* Are these workarounds reasonable for the problem of Nvidia GPU
sessions taking a long time to initialize when transcoding under
load?
* Is there an alternative to carrying around this patch to flush
the encoder in between segments?
* If there is no alternative, would you be open to a more formalized
addition to the avcodec API around "flushable" or "resumable"
encoders?
Thanks for your thoughts!
Josh
[0] https://github.com/livepeer/lpms
[1] https://gist.github.com/j0sh/ae9e5a97e794e364a6dfe513fa2591c2
[2] For historical reasons we cannot easily change right now
---
libavcodec/avcodec.h | 2 ++
libavcodec/nvenc.c | 5 +
2 files changed, 7 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index bcb931f0dd..763a557d82 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -6232,6 +6232,8 @@ const AVCodecDescriptor
*avcodec_descriptor_get_by_name(const char *name);
*/
AVCPBProperties *av_cpb_properties_alloc(size_t *size);
+int av_nvenc_flush(AVCodecContext *avctx);
+
/**
* @}
*/
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 111048d043..36134fa6a9 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -2071,6 +2071,11 @@ static void reconfig_encoder(AVCodecContext *avctx,
const AVFrame *frame)
}
}
+int attribute_align_arg av_nvenc_flush(AVCodecContext *avctx)
+{
+ return ff_nvenc_send_frame(avctx, NULL);
+}
+
int ff_nvenc_send_frame(AVCodecContext *avctx, const AVFrame *frame)
{
NVENCSTATUS nv_status;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH][DISCUSS] nvenc: Add encoder flush API.
On Fri, 20 Dec 2019 at 15:36, Philip Langdale wrote: > > On 2019-11-18 17:13, Josh Allmann wrote: > > This patch is meant to be an entry point for discussion around an > > issue we are having with flushing the nvenc encoder while doing > > segmented transcoding. Hopefully there will be a less kludgey > > workaround than this. > > Hi Josh, > > I happened to see your email recently, and took a quick look into > this. It seems that encoders are allowed to implement .flush() and > then avcodec_flush_buffers() can be called on them like on a > decoder. So I've posted a patch that does this (with the same impl > that you had). If that works for you, then that's all it takes - > no need for a new API call because there's already one you can use. That would be perfect - thought .flush() was decode-only for some reason. Thank you! Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] nvenc: implement flush to help allow an encoder to be re-used
On Fri, 20 Dec 2019 at 15:34, Philip Langdale wrote:
>
> It can be useful to re-use an encoder instance when doing segmented
> encodings, and this requires flushing the encoder at the start of
> each segment.
> ---
> libavcodec/nvenc.c | 5 +
> libavcodec/nvenc.h | 2 ++
> libavcodec/nvenc_h264.c | 1 +
> libavcodec/nvenc_hevc.c | 1 +
> 4 files changed, 9 insertions(+)
>
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 310e30805d..9a96bf2bba 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -2262,3 +2262,8 @@ int ff_nvenc_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
>
> return 0;
> }
> +
> +av_cold void ff_nvenc_encode_flush(AVCodecContext *avctx)
> +{
> +ff_nvenc_send_frame(avctx, NULL);
One concern I had was about the long-term stability of this behavior.
Right now, it works, but perhaps only coincidentally? Being flushable
and resumable like this isn't explicitly part of the "contract" for
nvenc, as far as I can see. Could future changes inadvertently
introduce state that isn't reset in between flushes, breaking the
resumable behavior? If so, is there a way to safeguard against that?
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@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] nvenc: implement flush to help allow an encoder to be re-used
On Mon, 30 Dec 2019 at 16:40, Philip Langdale wrote: > > On Sat, 21 Dec 2019 14:54:38 -0800 > Philip Langdale wrote: > > > On Fri, 20 Dec 2019 16:07:18 -0800 > > Josh Allmann wrote: > > > > > One concern I had was about the long-term stability of this > > > behavior. Right now, it works, but perhaps only coincidentally? > > > Being flushable and resumable like this isn't explicitly part of > > > the "contract" for nvenc, as far as I can see. Could future changes > > > inadvertently introduce state that isn't reset in between flushes, > > > breaking the resumable behavior? If so, is there a way to safeguard > > > against that? > > > > > > Josh > > > > So, the behaviour at the ffmpeg level is something you can view as > > stable. If it was to break, I'd expect us to fix it. For nvenc itself, > > that's harder to make any statements about. I wouldn't expect the > > nvidia folks to change thing casually, but until they document a > > specific flush behaviour, there's always going to be a risk - > > ultimately we just have to react if they change something. > > Hi Phil, Flushing and resumption is documented/supported in nvenc via NV_ENC_FLAGS_EOS, but I wasn't sure if this was a feature that ffmpeg's integration was intentionally designed for. But if you confirm we can expect this behavior to be supported going forward, then that's great news. > > In an ideal world, you'd have a test running for this, but we're not > > set up to exercise any hwaccels in our automated fate executions. > > We do have internal tests [1] that should catch the issue if anything changes, so that might be of some help as well, although we currently only update ffmpeg on an as-needed basis. [1] https://github.com/livepeer/lpms/blob/master/ffmpeg/nvidia_test.go > > Did this form of the patch work for you? > > > > Hi Josh, > > Did you get a chance to try it? > > --phil Was delayed on testing this due to the holidays, my apologies. Can confirm that this patch works very nicely in conjunction with avcodec_flush_buffers . Thanks so much! Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/2] ARM64 HEVC QPEL/EPEL
This is a patch originally, submitted in 2017 (author/date info left intact). At the time, it didn't get much attention I assume due to the sheer size of it. I have split the patch into only its QPEL/EPEL parts, rebasing, and doing some cleaning of the patches as much is reasonable for a 9001 line diff. I also have SAO band (non-working) and 32x32 IDCT (working but honestly in a worse state than these patches). This patch gives a large overall speedup roughly 30% in my testing. The only problem is that (as previously stated), 1) it's a lot of code, the original author didn't make use of macros. 2) it's only 8-bit. I will be writing 10-bit assembly, and whilst I do that will clean-up/macro-ify the current 8-bit assembly. Though there is still lots to be done. Our current IDCTs for HEVC aren't great either, I had a 40% speedup on the 16x16 one in testing. The assembly is far from 'done' but we're getting closer slowly at least. There were some suggestions for smaller improvements in the previous reviews and I have not applied those. The first course of action is to refractor it so that it is possible to work on the code without going insane. I think it's fine to use it whilst I'm working on refractoring it due to the large speedup: the code-weight in the binary should be relatively similar even after that anyway. Also, updated kperf patch as per Lynne's request. --. Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] lavu/checkasm: add (private) kperf timing for macOS
Signed-off-by: Josh Dekker
---
configure | 2 +
libavutil/Makefile| 1 +
libavutil/macos_kperf.c | 140 ++
libavutil/macos_kperf.h | 23 +++
libavutil/timer.h | 17 -
tests/checkasm/checkasm.c | 14 +++-
tests/checkasm/checkasm.h | 7 +-
7 files changed, 200 insertions(+), 4 deletions(-)
create mode 100644 libavutil/macos_kperf.c
create mode 100644 libavutil/macos_kperf.h
diff --git a/configure b/configure
index 820f719a32..a79052ad28 100755
--- a/configure
+++ b/configure
@@ -489,6 +489,7 @@ Developer options (useful when working on FFmpeg itself):
--ignore-tests=TESTS comma-separated list (without "fate-" prefix
in the name) of tests whose result is ignored
--enable-linux-perf enable Linux Performance Monitor API
+ --enable-macos-kperf enable macOS kperf (private) API
--disable-large-testsdisable tests that use a large amount of memory
NOTE: Object files are built at the place where configure is launched.
@@ -1947,6 +1948,7 @@ CONFIG_LIST="
fontconfig
large_tests
linux_perf
+macos_kperf
memory_poisoning
neon_clobber_test
ossfuzz
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 47efb718d2..18dc5f22d9 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -181,6 +181,7 @@ OBJS-$(CONFIG_D3D11VA) +=
hwcontext_d3d11va.o
OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
OBJS-$(CONFIG_LIBDRM) += hwcontext_drm.o
OBJS-$(CONFIG_LZO) += lzo.o
+OBJS-$(CONFIG_MACOS_KPERF) += macos_kperf.o
OBJS-$(CONFIG_MEDIACODEC) += hwcontext_mediacodec.o
OBJS-$(CONFIG_OPENCL) += hwcontext_opencl.o
OBJS-$(CONFIG_QSV) += hwcontext_qsv.o
diff --git a/libavutil/macos_kperf.c b/libavutil/macos_kperf.c
new file mode 100644
index 00..d5de491e12
--- /dev/null
+++ b/libavutil/macos_kperf.c
@@ -0,0 +1,140 @@
+/*
+ * 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 "macos_kperf.h"
+#include
+#include
+#include
+
+#define KPERF_LIST \
+F(int, kpc_get_counting, void) \
+F(int, kpc_force_all_ctrs_set, int)\
+F(int, kpc_set_counting, uint32_t) \
+F(int, kpc_set_thread_counting, uint32_t) \
+F(int, kpc_set_config, uint32_t, void *) \
+F(int, kpc_get_config, uint32_t, void *) \
+F(int, kpc_set_period, uint32_t, void *) \
+F(int, kpc_get_period, uint32_t, void *) \
+F(uint32_t, kpc_get_counter_count, uint32_t) \
+F(uint32_t, kpc_get_config_count, uint32_t)\
+F(int, kperf_sample_get, int *)\
+F(int, kpc_get_thread_counters, int, unsigned int, void *)
+
+#define F(ret, name, ...) \
+typedef ret name##proc(__VA_ARGS__); \
+static name##proc *name = NULL;
+KPERF_LIST
+#undef F
+
+#define CFGWORD_EL0A32EN_MASK (0x1)
+#define CFGWORD_EL0A64EN_MASK (0x2)
+#define CFGWORD_EL1EN_MASK(0x4)
+#define CFGWORD_EL3EN_MASK(0x8)
+#define CFGWORD_ALLMODES_MASK (0xf)
+
+#define CPMU_NONE 0
+#define CPMU_CORE_CYCLE 0x02
+#define CPMU_INST_A64 0x8c
+#define CPMU_INST_BRANCH 0x8d
+#define CPMU_SYNC_DC_LOAD_MISS 0xbf
+#define CPMU_SYNC_DC_STORE_MISS 0xc0
+#define CPMU_SYNC_DTLB_MISS 0xc1
+#define CPMU_SYNC_ST_HIT_YNGR_LD 0xc4
+#define CPMU_SYNC_BR_ANY_MISP 0xcb
+#define CPMU_FED_IC_MISS_DEM 0xd3
+#define CPMU_FED_ITLB_MISS 0xd4
+
+#define KPC_CLASS_FIXED_MASK(1 << 0)
+#define KPC_CLASS_CONFIGURABLE_MASK (1 << 1)
+#define KPC_CLASS_POWER_MASK(1 << 2)
+#define KPC_CLASS_RAWPMU_MASK (1 << 3)
+
+#define COUNTERS_COUNT 10
+#define CONFIG_COUNT 8
+#define KPC_MASK (KPC_CLASS_CONFIGURABLE_MASK | KPC_CLASS_FIXED_MASK)
+
+int ff_kperf_setup()
+{
+uint64_t config[COUNTERS_COUNT] = {0};
+config[0] = CPMU_CORE_CYCLE | CFGWORD_EL0A64EN_MASK;
+// con
[FFmpeg-devel] [PATCH] avformat/flvdec: Ignore the first two data/subtitle streams.
Previously, one or the other would have been ignored, but not both.
Since the probe terminates at three streams, it could exit
prematurely if both data and subtitles are present along with
slightly trailing media, usually video trailing audio.
Trailing media is common in RTMP, and encoders write strange metadata.
---
libavformat/flvdec.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 4b9f46902b..1be8d98618 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -134,18 +134,32 @@ static void add_keyframes_index(AVFormatContext *s)
}
}
+static int is_ignorable(enum AVMediaType codec_type)
+{
+switch(codec_type) {
+case AVMEDIA_TYPE_SUBTITLE:
+case AVMEDIA_TYPE_DATA:
+return 1;
+}
+return 0;
+}
+
static AVStream *create_stream(AVFormatContext *s, int codec_type)
{
+int streams_to_ignore = 0, nb_streams = 0;
FLVContext *flv = s->priv_data;
AVStream *st = avformat_new_stream(s, NULL);
if (!st)
return NULL;
st->codecpar->codec_type = codec_type;
-if (s->nb_streams>=3 ||( s->nb_streams==2
- && s->streams[0]->codecpar->codec_type !=
AVMEDIA_TYPE_SUBTITLE
- && s->streams[1]->codecpar->codec_type !=
AVMEDIA_TYPE_SUBTITLE
- && s->streams[0]->codecpar->codec_type !=
AVMEDIA_TYPE_DATA
- && s->streams[1]->codecpar->codec_type !=
AVMEDIA_TYPE_DATA))
+
+if (s->nb_streams >= 1)
+streams_to_ignore += is_ignorable(s->streams[0]->codecpar->codec_type);
+if (s->nb_streams >= 2)
+streams_to_ignore += is_ignorable(s->streams[1]->codecpar->codec_type);
+
+nb_streams = s->nb_streams - streams_to_ignore;
+if (nb_streams >= 2)
s->ctx_flags &= ~AVFMTCTX_NOHEADER;
if (codec_type == AVMEDIA_TYPE_AUDIO) {
st->codecpar->bit_rate = flv->audio_bit_rate;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: Ignore the first two data/subtitle streams.
On Thu, 13 May 2021 at 16:38, Josh Allmann wrote: > > Previously, one or the other would have been ignored, but not both. > Since the probe terminates at three streams, it could exit > prematurely if both data and subtitles are present along with > slightly trailing media, usually video trailing audio. > > Trailing media is common in RTMP, and encoders write strange metadata. > --- Here's a trac ticket with some more context: https://trac.ffmpeg.org/ticket/9241 And a sample that exhibits the problem: https://trac.ffmpeg.org/attachment/ticket/9241/flv-probe-missing-streams.flv Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] rtmp: Plug leak if sending bytes read report fails.
---
libavformat/rtmpproto.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index faf2a6f244..b741e421af 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2431,8 +2431,10 @@ static int get_packet(URLContext *s, int for_header)
rt->bytes_read += ret;
if (rt->bytes_read - rt->last_bytes_read > rt->receive_report_size) {
av_log(s, AV_LOG_DEBUG, "Sending bytes read report\n");
-if ((ret = gen_bytes_read(s, rt, rpkt.timestamp + 1)) < 0)
+if ((ret = gen_bytes_read(s, rt, rpkt.timestamp + 1)) < 0) {
+ff_rtmp_packet_destroy(&rpkt);
return ret;
+}
rt->last_bytes_read = rt->bytes_read;
}
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacenc: Free any extradata before re-allocating.
Fixes a leak that occurs if avctx->extradata contains any data
prior to opening the codec, eg left over from an initialization
call to avcodec_parameters_from_context.
---
libavcodec/aacenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 6d94c76905..f8fbe69d87 100644
--- a/libavcodec/aacenc.c
+++ b/libavcodec/aacenc.c
@@ -98,6 +98,10 @@ static int put_audio_specific_config(AVCodecContext *avctx)
int channels = (!s->needs_pce)*(s->channels - (s->channels == 8 ? 1 : 0));
const int max_size = 32;
+if (avctx->extradata) {
+av_freep(&avctx->extradata);
+avctx->extradata_size = 0;
+}
avctx->extradata = av_mallocz(max_size);
if (!avctx->extradata)
return AVERROR(ENOMEM);
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] aacenc: Free any extradata before re-allocating.
On 6 February 2018 at 03:16, Rostislav Pehlivanov
wrote:
> On 6 February 2018 at 06:56, Josh Allmann
> wrote:
>
> > Fixes a leak that occurs if avctx->extradata contains any data
> > prior to opening the codec, eg left over from an initialization
> > call to avcodec_parameters_from_context.
> > ---
> > libavcodec/aacenc.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
> > index 6d94c76905..f8fbe69d87 100644
> > --- a/libavcodec/aacenc.c
> > +++ b/libavcodec/aacenc.c
> > @@ -98,6 +98,10 @@ static int put_audio_specific_config(AVCodecContext
> > *avctx)
> > int channels = (!s->needs_pce)*(s->channels - (s->channels == 8 ? 1
> :
> > 0));
> > const int max_size = 32;
> >
> > +if (avctx->extradata) {
> > +av_freep(&avctx->extradata);
> > +avctx->extradata_size = 0;
> > +}
> > avctx->extradata = av_mallocz(max_size);
> > if (!avctx->extradata)
> > return AVERROR(ENOMEM);
> > --
> > 2.14.2
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> No, its not up to the encoder to free up the extradata. Its up to the API
> user to close the avctx for the encoder which will free the extradata, even
> if encoder init fails. Besides, if you don't, you'll have a dirty context
> from the previous encoder since they don't have to set the same avctx
> fields.
>
While many (all?) other encoders share the pattern of allocating extradata
without checking for previous allocations, the abstraction seems... leaky?
(Pun fully intended.) If the encoder has its avctx fields set by
avcodec_parameters_to_context, then the extradata is deep-copied. Even when
deep copying, we do take care to deallocate any existing avctx extradata,
to avoid introducing the same type of leak. Without this patch, the API
user would have to explicitly undo the work that
avcodec_parameters_to_context is trying to help with. Hence, the 'right'
workflow when using avcodec_parameters_to_context would be:
0. Allocate codec context
1. Copy codec params to context with avcodec_parameters_to_context
2. Check if extradata exists in context and deallocate from context if so.
3. Open codec.
...
4. Close codec.
These semantics don't seem clean to me, and I think we should strive to
avoid making the user deal with corner cases like these explicitly. If not,
we should at least document it.
Josh
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/noise_bsf: Add keyframes option.
---
doc/bitstream_filters.texi | 5 +
libavcodec/noise_bsf.c | 12
libavcodec/version.h | 2 +-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index cfd81fa12d..a9f17f32ec 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -399,6 +399,11 @@ every byte is modified.
A numeral string, whose value is related to how often packets will be dropped.
Therefore, values below or equal to 0 are forbidden, and the lower the more
frequent packets will be dropped, with 1 meaning every packet is dropped.
+@item keyframes
+A numeral string, whose value indicates the number of keyframe packets that
+will be dropped from the beginning of the stream. This option will not add
+noise to the source data. If used with stream copy, then -copyinkf should
+be added to the output options as well.
@end table
The following example applies the modification to every byte but does not drop
diff --git a/libavcodec/noise_bsf.c b/libavcodec/noise_bsf.c
index 84b94032ad..363ea4fc71 100644
--- a/libavcodec/noise_bsf.c
+++ b/libavcodec/noise_bsf.c
@@ -32,6 +32,7 @@ typedef struct NoiseContext {
const AVClass *class;
int amount;
int dropamount;
+int keyframes;
unsigned int state;
} NoiseContext;
@@ -49,6 +50,13 @@ static int noise(AVBSFContext *ctx, AVPacket *out)
if (ret < 0)
return ret;
+if (s->keyframes > 0 && in->flags & AV_PKT_FLAG_KEY) {
+ s->keyframes--;
+ if (!s->keyframes) s->keyframes = -1;
+ av_packet_free(&in);
+ return AVERROR(EAGAIN);
+}
+
if (s->dropamount > 0 && s->state % s->dropamount == 0) {
s->state++;
av_packet_free(&in);
@@ -65,6 +73,9 @@ static int noise(AVBSFContext *ctx, AVPacket *out)
memcpy(out->data, in->data, in->size);
+if (s->keyframes)
+ return ret;
+
for (i = 0; i < out->size; i++) {
s->state += out->data[i] + 1;
if (s->state % amount == 0)
@@ -81,6 +92,7 @@ fail:
static const AVOption options[] = {
{ "amount", NULL, OFFSET(amount), AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
INT_MAX },
{ "dropamount", NULL, OFFSET(dropamount), AV_OPT_TYPE_INT, { .i64 = 0 },
0, INT_MAX },
+{ "keyframes", NULL, OFFSET(keyframes), AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
INT_MAX },
{ NULL },
};
diff --git a/libavcodec/version.h b/libavcodec/version.h
index ca18ce6e8b..1e84410d68 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 58
#define LIBAVCODEC_VERSION_MINOR 13
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/noise_bsf: Add keyframes option.
On 7 March 2018 at 18:03, Michael Niedermayer wrote:
> On Tue, Mar 06, 2018 at 12:47:15PM -0800, Josh Allmann wrote:
>> ---
>> doc/bitstream_filters.texi | 5 +
>> libavcodec/noise_bsf.c | 12
>> libavcodec/version.h | 2 +-
>> 3 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
>> index cfd81fa12d..a9f17f32ec 100644
>> --- a/doc/bitstream_filters.texi
>> +++ b/doc/bitstream_filters.texi
>> @@ -399,6 +399,11 @@ every byte is modified.
>> A numeral string, whose value is related to how often packets will be
>> dropped.
>> Therefore, values below or equal to 0 are forbidden, and the lower the more
>> frequent packets will be dropped, with 1 meaning every packet is dropped.
>> +@item keyframes
>> +A numeral string, whose value indicates the number of keyframe packets that
>> +will be dropped from the beginning of the stream. This option will not add
>> +noise to the source data. If used with stream copy, then -copyinkf should
>> +be added to the output options as well.
>> @end table
>>
>> The following example applies the modification to every byte but does not
>> drop
>> diff --git a/libavcodec/noise_bsf.c b/libavcodec/noise_bsf.c
>> index 84b94032ad..363ea4fc71 100644
>> --- a/libavcodec/noise_bsf.c
>> +++ b/libavcodec/noise_bsf.c
>> @@ -32,6 +32,7 @@ typedef struct NoiseContext {
>> const AVClass *class;
>> int amount;
>> int dropamount;
>> +int keyframes;
>> unsigned int state;
>> } NoiseContext;
>>
>> @@ -49,6 +50,13 @@ static int noise(AVBSFContext *ctx, AVPacket *out)
>> if (ret < 0)
>> return ret;
>>
>> +if (s->keyframes > 0 && in->flags & AV_PKT_FLAG_KEY) {
>> + s->keyframes--;
>> + if (!s->keyframes) s->keyframes = -1;
>> + av_packet_free(&in);
>> + return AVERROR(EAGAIN);
>> +}
>
Thanks for the feedback.
> I think keyframe should work like dropamount, that is randomly.
>
> a non random droping could be added, maybe by the user specifying in
> a list what to drop.
> That would be more powerfull and flexible but probably not much harder
Something like this?
noise=keyframes=1,3,5,7
in order to drop the 1st, 3rd, 5th and 7th keyframes?
> also keeping keyframes and dropamount behave the same
> is more consistent
>
Do you mean more consistent with respect to the 'amount' param of added noise,
as opposed to the patch's behavior of skipping noise if the 'keyframes' param is
present?
> also the indention depth mismatches the surrounding code
>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Let us carefully observe those good qualities wherein our enemies excel us
> and endeavor to excel them, by avoiding what is faulty, and imitating what
> is excellent in them. -- Plutarch
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references the SPS, the SPS/PPS
needs to come first.
---
libavcodec/bsf/h264_mp4toannexb.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libavcodec/bsf/h264_mp4toannexb.c
b/libavcodec/bsf/h264_mp4toannexb.c
index 92af6a6881..6607f1e91a 100644
--- a/libavcodec/bsf/h264_mp4toannexb.c
+++ b/libavcodec/bsf/h264_mp4toannexb.c
@@ -363,6 +363,19 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
if (!new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] & 0x80))
new_idr = 1;
+/* If this is a buffering period SEI without a corresponding
sps/pps
+ * then prepend any existing sps/pps before the SEI */
+if (unit_type == H264_NAL_SEI && buf[1] == 0 && !sps_seen &&
!pps_seen) {
+if (s->sps_size) {
+count_or_copy(&out, &out_size, s->sps, s->sps_size,
PS_OUT_OF_BAND, j);
+sps_seen = 1;
+}
+if (s->pps_size) {
+count_or_copy(&out, &out_size, s->pps, s->pps_size,
PS_OUT_OF_BAND, j);
+pps_seen = 1;
+}
+}
+
/* prepend only to the first type 5 NAL unit of an IDR picture, if
no sps/pps are already present */
if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen &&
!pps_seen) {
if (s->sps_size)
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@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/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
On Sat, 6 Jul 2024 at 09:37, Michael Niedermayer wrote: > > On Wed, Jul 03, 2024 at 02:05:06PM -0700, Josh Allmann wrote: > > Encoders may emit a buffering period SEI without a corresponding > > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc. > > > > During Annex B conversion, this may result in the SPS/PPS being > > inserted *after* the buffering period SEI but before the IDR NAL. > > > > Since the buffering period SEI references the SPS, the SPS/PPS > > needs to come first. > > --- > > libavcodec/bsf/h264_mp4toannexb.c | 13 + > > 1 file changed, 13 insertions(+) > > breaks fate > > TESTh264-bsf-mp4toannexb > --- ./tests/ref/fate/h264-bsf-mp4toannexb 2024-07-01 23:30:40.656213791 > +0200 > +++ tests/data/fate/h264-bsf-mp4toannexb2024-07-06 12:13:56.491072296 > +0200 > @@ -1 +1 @@ > -5f04c27cc6ee8625fe2405fb0f7da9a3 > +ff2551123909f54c382294baa1bb4364 > Test h264-bsf-mp4toannexb failed. Look at > tests/data/fate/h264-bsf-mp4toannexb.err for details. > make: *** [tests/Makefile:311: fate-h264-bsf-mp4toannexb] Error 1 > Thanks for the heads up. Took a look into each of the failing fate tests from [0] and I think these changes are expected and OK. Each of the failing tests shows the problem that this patch fixes, which is that the SPS/PPS is written after the buffering period SEI. An easy way to eyeball the issue is that probing the Annex B output logs an error which says "non-existing SPS 0 referenced in buffering period" - in fact this is why I wrote this patch, to get to the bottom of that message. The NAL ordering can also be inspected with `bsf:v trace_headers`. There also seems to be a side benefit that makes segmenting more robust - details below. Some notes on each failing test: fate-segment-mp4-to-ts : Before this patch, the segments produced after 000.ts are not independently decodable, because only the first segment has any extradata [1]. After the patch, the segments can be decoded independently. Unless the intent of the test is to actually produce broken segments, this patch is probably correct in fixing that. Also see the `fate-h264-bsf-mp4toannexb` testcase. fate-h264-bsf-mp4toannexb : In the original version, the SPS/PPS is only written once - maybe because there are no true IDRs after the first frame, only recovery point SEIs. In the patched version, the SPS/PPS is written before each buffering period SEI, 6 times in total. I can see how this might be strictly unnecessary, but probably harmless from a spec standpoint. Also it seems to make segmented muxing more robust, since this testcase shares the same input as `fate-segment-mp4-to-ts` which produces broken segments without the patch. fate-h264_mp4toannexb_ticket2991 : This is a clean example of the problem that this patch solves: without it, a buffering period SEI comes before the SPS/PPS. Inspecting a diff of the NAL units [2], the only change is in the reordering of the NALs such that the SPS/PPS comes before the buffering period SEI, rather than after. If all that seems OK, then I can send another patch to update the fate references to match the new values. [0] https://patchwork.ffmpeg.org/check/104951/ [1] The first segment has extradata, but it is still in the wrong order without the patch. [2] https://gist.github.com/j0sh/c912056138822c4d8c9564f4062e1e7b Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references the SPS, the SPS/PPS
needs to come first.
---
Notes:
v2: Updated FATE test refs
libavcodec/bsf/h264_mp4toannexb.c | 13 +
tests/ref/fate/h264-bsf-mp4toannexb| 2 +-
tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +-
tests/ref/fate/segment-mp4-to-ts | 12 ++--
4 files changed, 29 insertions(+), 16 deletions(-)
diff --git a/libavcodec/bsf/h264_mp4toannexb.c
b/libavcodec/bsf/h264_mp4toannexb.c
index 92af6a6881..6607f1e91a 100644
--- a/libavcodec/bsf/h264_mp4toannexb.c
+++ b/libavcodec/bsf/h264_mp4toannexb.c
@@ -363,6 +363,19 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
if (!new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] & 0x80))
new_idr = 1;
+/* If this is a buffering period SEI without a corresponding
sps/pps
+ * then prepend any existing sps/pps before the SEI */
+if (unit_type == H264_NAL_SEI && buf[1] == 0 && !sps_seen &&
!pps_seen) {
+if (s->sps_size) {
+count_or_copy(&out, &out_size, s->sps, s->sps_size,
PS_OUT_OF_BAND, j);
+sps_seen = 1;
+}
+if (s->pps_size) {
+count_or_copy(&out, &out_size, s->pps, s->pps_size,
PS_OUT_OF_BAND, j);
+pps_seen = 1;
+}
+}
+
/* prepend only to the first type 5 NAL unit of an IDR picture, if
no sps/pps are already present */
if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen &&
!pps_seen) {
if (s->sps_size)
diff --git a/tests/ref/fate/h264-bsf-mp4toannexb
b/tests/ref/fate/h264-bsf-mp4toannexb
index 2049f39701..81ff568f3d 100644
--- a/tests/ref/fate/h264-bsf-mp4toannexb
+++ b/tests/ref/fate/h264-bsf-mp4toannexb
@@ -1 +1 @@
-5f04c27cc6ee8625fe2405fb0f7da9a3
+ff2551123909f54c382294baa1bb4364
diff --git a/tests/ref/fate/h264_mp4toannexb_ticket2991
b/tests/ref/fate/h264_mp4toannexb_ticket2991
index f8e3e920d4..9a1fbf2f8c 100644
--- a/tests/ref/fate/h264_mp4toannexb_ticket2991
+++ b/tests/ref/fate/h264_mp4toannexb_ticket2991
@@ -1,4 +1,4 @@
-05d66e60ab22ee004720e0051af0fe74
*tests/data/fate/h264_mp4toannexb_ticket2991.h264
+b6ff5910928ad0b2a7eec481dcc41594
*tests/data/fate/h264_mp4toannexb_ticket2991.h264
1985815 tests/data/fate/h264_mp4toannexb_ticket2991.h264
#extradata 0: 47, 0x3a590d55
#tb 0: 1/120
@@ -6,7 +6,7 @@
#codec_id 0: h264
#dimensions 0: 1280x720
#sar 0: 3/4
-0, 0, 0,40040,37126, 0xb020184c
+0, 0, 0,40040,37126, 0x515c184c
0, 40040, 40040,40040, 6920, 0x8512361a, F=0x0
0, 80081, 80081,40040, 7550, 0x1bc56ed4, F=0x0
0, 120121, 120121,40040, 8752, 0xb8c6f0a1, F=0x0
@@ -21,7 +21,7 @@
0, 480485, 480485,40040,11234, 0x83cbd9fd, F=0x0
0, 520525, 520525,40040,17616, 0xfdf95104, F=0x0
0, 560566, 560566,40040,10689, 0x9633d32b, F=0x0
-0, 600606, 600606,40040,45291, 0x543c2cf6
+0, 600606, 600606,40040,45291, 0xa8292cf6
0, 640646, 640646,40040,20837, 0x051abfab, F=0x0
0, 680687, 680687,40040,21418, 0xe2a59d70, F=0x0
0, 720727, 720727,40040,15643, 0x15cf2cec, F=0x0
@@ -36,7 +36,7 @@
0,1081091,1081091,40040,13130, 0xcbb6bb8e, F=0x0
0,1121131,1121131,40040,16180, 0x5d188a7a, F=0x0
0,1161172,1161172,40040,14961, 0x9ff2f463, F=0x0
-0,1201212,1201212,40040,54296, 0xe6ec30ed
+0,1201212,1201212,40040,54296, 0x3ae830ed
0,1241252,1241252,40040,11500, 0x8c4852c9, F=0x0
0,1281293,1281293,40040,12065, 0xfb7954c3, F=0x0
0,1321333,1321333,40040,12532, 0xf0a935d3, F=0x0
@@ -51,7 +51,7 @@
0,1681697,1681697,40040,13250, 0xfed0deb8, F=0x0
0,1721737,1721737,40040,13360, 0xbf92d476, F=0x0
0,1761778,1761778,40040,11749, 0x3041eaf1, F=0x0
-0,1801818,1801818,40040,23997, 0xdbe6d5c4
+0,1801818,1801818,40040,23997, 0x2fe2d5c4
0,1841858,1841858,40040,16065, 0xe8f715b7, F=0x0
0,1881899,1881899,40040,16441, 0x0a4e060f, F=0x0
0,1921939,1921939,40040,17395, 0xa8edecc2, F=0x0
@@ -66,7 +66,7 @@
0,2282303,2282303,40040,13748, 0xed26aeb4, F=0x0
0,2322343,2322343,40040,15092, 0x3c983538, F=0x0
0,2362384,2362384,40040,14636, 0x9b278a6c, F=0x0
-0,2402424,24024
Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
>
> Encoders may emit a buffering period SEI without a corresponding
> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
>
> During Annex B conversion, this may result in the SPS/PPS being
> inserted *after* the buffering period SEI but before the IDR NAL.
>
> Since the buffering period SEI references the SPS, the SPS/PPS
> needs to come first.
> ---
>
> Notes:
> v2: Updated FATE test refs
>
> libavcodec/bsf/h264_mp4toannexb.c | 13 +
> tests/ref/fate/h264-bsf-mp4toannexb| 2 +-
> tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +-
> tests/ref/fate/segment-mp4-to-ts | 12 ++--
> 4 files changed, 29 insertions(+), 16 deletions(-)
>
Ping for review. Looking at the FATE output, this patch fixes a number
of things - see [1] for details
[1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-July/330964.html
> diff --git a/libavcodec/bsf/h264_mp4toannexb.c
> b/libavcodec/bsf/h264_mp4toannexb.c
> index 92af6a6881..6607f1e91a 100644
> --- a/libavcodec/bsf/h264_mp4toannexb.c
> +++ b/libavcodec/bsf/h264_mp4toannexb.c
> @@ -363,6 +363,19 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
> AVPacket *opkt)
> if (!new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] &
> 0x80))
> new_idr = 1;
>
> +/* If this is a buffering period SEI without a corresponding
> sps/pps
> + * then prepend any existing sps/pps before the SEI */
> +if (unit_type == H264_NAL_SEI && buf[1] == 0 && !sps_seen &&
> !pps_seen) {
> +if (s->sps_size) {
> +count_or_copy(&out, &out_size, s->sps, s->sps_size,
> PS_OUT_OF_BAND, j);
> +sps_seen = 1;
> +}
> +if (s->pps_size) {
> +count_or_copy(&out, &out_size, s->pps, s->pps_size,
> PS_OUT_OF_BAND, j);
> +pps_seen = 1;
> +}
> +}
> +
> /* prepend only to the first type 5 NAL unit of an IDR picture,
> if no sps/pps are already present */
> if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen &&
> !pps_seen) {
> if (s->sps_size)
> diff --git a/tests/ref/fate/h264-bsf-mp4toannexb
> b/tests/ref/fate/h264-bsf-mp4toannexb
> index 2049f39701..81ff568f3d 100644
> --- a/tests/ref/fate/h264-bsf-mp4toannexb
> +++ b/tests/ref/fate/h264-bsf-mp4toannexb
> @@ -1 +1 @@
> -5f04c27cc6ee8625fe2405fb0f7da9a3
> +ff2551123909f54c382294baa1bb4364
> diff --git a/tests/ref/fate/h264_mp4toannexb_ticket2991
> b/tests/ref/fate/h264_mp4toannexb_ticket2991
> index f8e3e920d4..9a1fbf2f8c 100644
> --- a/tests/ref/fate/h264_mp4toannexb_ticket2991
> +++ b/tests/ref/fate/h264_mp4toannexb_ticket2991
> @@ -1,4 +1,4 @@
> -05d66e60ab22ee004720e0051af0fe74
> *tests/data/fate/h264_mp4toannexb_ticket2991.h264
> +b6ff5910928ad0b2a7eec481dcc41594
> *tests/data/fate/h264_mp4toannexb_ticket2991.h264
> 1985815 tests/data/fate/h264_mp4toannexb_ticket2991.h264
> #extradata 0: 47, 0x3a590d55
> #tb 0: 1/120
> @@ -6,7 +6,7 @@
> #codec_id 0: h264
> #dimensions 0: 1280x720
> #sar 0: 3/4
> -0, 0, 0,40040,37126, 0xb020184c
> +0, 0, 0,40040,37126, 0x515c184c
> 0, 40040, 40040,40040, 6920, 0x8512361a, F=0x0
> 0, 80081, 80081,40040, 7550, 0x1bc56ed4, F=0x0
> 0, 120121, 120121,40040, 8752, 0xb8c6f0a1, F=0x0
> @@ -21,7 +21,7 @@
> 0, 480485, 480485,40040,11234, 0x83cbd9fd, F=0x0
> 0, 520525, 520525,40040,17616, 0xfdf95104, F=0x0
> 0, 560566, 560566,40040,10689, 0x9633d32b, F=0x0
> -0, 600606, 600606,40040,45291, 0x543c2cf6
> +0, 600606, 600606,40040,45291, 0xa8292cf6
> 0, 640646, 640646,40040,20837, 0x051abfab, F=0x0
> 0, 680687, 680687,40040,21418, 0xe2a59d70, F=0x0
> 0, 720727, 720727,40040,15643, 0x15cf2cec, F=0x0
> @@ -36,7 +36,7 @@
> 0,1081091,1081091,40040,13130, 0xcbb6bb8e, F=0x0
> 0,1121131,1121131,40040,16180, 0x5d188a7a, F=0x0
> 0,1161172,1161172,40040,14961, 0x9ff2f463, F=0x0
> -0,1201212,1201212,40040,54296, 0xe6ec30ed
> +0,1201212,1201212,40040,54296, 0x3ae830ed
> 0,1241252,1241252,40040,11500, 0x8c4852c9, F=0x0
> 0,1281293,1281293,40040,12065, 0xfb7954c3, F=0x0
> 0,1
Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
On Mon, 15 Jul 2024 at 10:48, Josh Allmann wrote: > > On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote: > > > > Encoders may emit a buffering period SEI without a corresponding > > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc. > > > > During Annex B conversion, this may result in the SPS/PPS being > > inserted *after* the buffering period SEI but before the IDR NAL. > > > > Since the buffering period SEI references the SPS, the SPS/PPS > > needs to come first. > > --- > > > > Notes: > > v2: Updated FATE test refs > > > > libavcodec/bsf/h264_mp4toannexb.c | 13 + > > tests/ref/fate/h264-bsf-mp4toannexb| 2 +- > > tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +- > > tests/ref/fate/segment-mp4-to-ts | 12 ++-- > > 4 files changed, 29 insertions(+), 16 deletions(-) > > > > Ping for review. Looking at the FATE output, this patch fixes a number > of things - see [1] for details > > [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-July/330964.html Pasted the wrong link - please see this for a review of the FATE test changes https://ffmpeg.org//pipermail/ffmpeg-devel/2024-July/330912.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote: > > Encoders may emit a buffering period SEI without a corresponding > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc. > > During Annex B conversion, this may result in the SPS/PPS being > inserted *after* the buffering period SEI but before the IDR NAL. > > Since the buffering period SEI references the SPS, the SPS/PPS > needs to come first. > --- > > Notes: > v2: Updated FATE test refs > > libavcodec/bsf/h264_mp4toannexb.c | 13 + > tests/ref/fate/h264-bsf-mp4toannexb| 2 +- > tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +- > tests/ref/fate/segment-mp4-to-ts | 12 ++-- > 4 files changed, 29 insertions(+), 16 deletions(-) > Ping again for review. Looking at the FATE output, this patch fixes a number of things - see [1] for details [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-July/330912.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
On Mon, 22 Jul 2024 at 17:17, Timo Rothenpieler wrote: > > On 23/07/2024 01:01, Josh Allmann wrote: > > On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote: > >> > >> Encoders may emit a buffering period SEI without a corresponding > >> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc. > >> > >> During Annex B conversion, this may result in the SPS/PPS being > >> inserted *after* the buffering period SEI but before the IDR NAL. > >> > >> Since the buffering period SEI references the SPS, the SPS/PPS > >> needs to come first. > >> --- > >> > >> Notes: > >> v2: Updated FATE test refs > >> > >> libavcodec/bsf/h264_mp4toannexb.c | 13 + > >> tests/ref/fate/h264-bsf-mp4toannexb| 2 +- > >> tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +- > >> tests/ref/fate/segment-mp4-to-ts | 12 ++-- > >> 4 files changed, 29 insertions(+), 16 deletions(-) > >> > > > > Ping again for review. Looking at the FATE output, this patch fixes a number > > of things - see [1] for details > > patch generally looks good to me, but I'm not closely familiar with the > code there. > Thanks, is there anyone else more familiar with the code who can also sign off on this patch? Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references the SPS, the SPS/PPS
needs to come first.
---
libavcodec/bsf/h264_mp4toannexb.c | 15 +++
tests/ref/fate/h264-bsf-mp4toannexb| 2 +-
tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +-
tests/ref/fate/segment-mp4-to-ts | 12 ++--
4 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/libavcodec/bsf/h264_mp4toannexb.c
b/libavcodec/bsf/h264_mp4toannexb.c
index 92af6a6881..dda064287e 100644
--- a/libavcodec/bsf/h264_mp4toannexb.c
+++ b/libavcodec/bsf/h264_mp4toannexb.c
@@ -30,6 +30,7 @@
#include "bytestream.h"
#include "defs.h"
#include "h264.h"
+#include "sei.h"
typedef struct H264BSFContext {
uint8_t *sps;
@@ -363,6 +364,20 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *opkt)
if (!new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] & 0x80))
new_idr = 1;
+/* If this is a buffering period SEI without a corresponding
sps/pps
+ * then prepend any existing sps/pps before the SEI */
+if (unit_type == H264_NAL_SEI && buf[1] ==
SEI_TYPE_BUFFERING_PERIOD &&
+!sps_seen && !pps_seen) {
+if (s->sps_size) {
+count_or_copy(&out, &out_size, s->sps, s->sps_size,
PS_OUT_OF_BAND, j);
+sps_seen = 1;
+}
+if (s->pps_size) {
+count_or_copy(&out, &out_size, s->pps, s->pps_size,
PS_OUT_OF_BAND, j);
+pps_seen = 1;
+}
+}
+
/* prepend only to the first type 5 NAL unit of an IDR picture, if
no sps/pps are already present */
if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen &&
!pps_seen) {
if (s->sps_size)
diff --git a/tests/ref/fate/h264-bsf-mp4toannexb
b/tests/ref/fate/h264-bsf-mp4toannexb
index 2049f39701..81ff568f3d 100644
--- a/tests/ref/fate/h264-bsf-mp4toannexb
+++ b/tests/ref/fate/h264-bsf-mp4toannexb
@@ -1 +1 @@
-5f04c27cc6ee8625fe2405fb0f7da9a3
+ff2551123909f54c382294baa1bb4364
diff --git a/tests/ref/fate/h264_mp4toannexb_ticket2991
b/tests/ref/fate/h264_mp4toannexb_ticket2991
index f8e3e920d4..9a1fbf2f8c 100644
--- a/tests/ref/fate/h264_mp4toannexb_ticket2991
+++ b/tests/ref/fate/h264_mp4toannexb_ticket2991
@@ -1,4 +1,4 @@
-05d66e60ab22ee004720e0051af0fe74
*tests/data/fate/h264_mp4toannexb_ticket2991.h264
+b6ff5910928ad0b2a7eec481dcc41594
*tests/data/fate/h264_mp4toannexb_ticket2991.h264
1985815 tests/data/fate/h264_mp4toannexb_ticket2991.h264
#extradata 0: 47, 0x3a590d55
#tb 0: 1/120
@@ -6,7 +6,7 @@
#codec_id 0: h264
#dimensions 0: 1280x720
#sar 0: 3/4
-0, 0, 0,40040,37126, 0xb020184c
+0, 0, 0,40040,37126, 0x515c184c
0, 40040, 40040,40040, 6920, 0x8512361a, F=0x0
0, 80081, 80081,40040, 7550, 0x1bc56ed4, F=0x0
0, 120121, 120121,40040, 8752, 0xb8c6f0a1, F=0x0
@@ -21,7 +21,7 @@
0, 480485, 480485,40040,11234, 0x83cbd9fd, F=0x0
0, 520525, 520525,40040,17616, 0xfdf95104, F=0x0
0, 560566, 560566,40040,10689, 0x9633d32b, F=0x0
-0, 600606, 600606,40040,45291, 0x543c2cf6
+0, 600606, 600606,40040,45291, 0xa8292cf6
0, 640646, 640646,40040,20837, 0x051abfab, F=0x0
0, 680687, 680687,40040,21418, 0xe2a59d70, F=0x0
0, 720727, 720727,40040,15643, 0x15cf2cec, F=0x0
@@ -36,7 +36,7 @@
0,1081091,1081091,40040,13130, 0xcbb6bb8e, F=0x0
0,1121131,1121131,40040,16180, 0x5d188a7a, F=0x0
0,1161172,1161172,40040,14961, 0x9ff2f463, F=0x0
-0,1201212,1201212,40040,54296, 0xe6ec30ed
+0,1201212,1201212,40040,54296, 0x3ae830ed
0,1241252,1241252,40040,11500, 0x8c4852c9, F=0x0
0,1281293,1281293,40040,12065, 0xfb7954c3, F=0x0
0,1321333,1321333,40040,12532, 0xf0a935d3, F=0x0
@@ -51,7 +51,7 @@
0,1681697,1681697,40040,13250, 0xfed0deb8, F=0x0
0,1721737,1721737,40040,13360, 0xbf92d476, F=0x0
0,1761778,1761778,40040,11749, 0x3041eaf1, F=0x0
-0,1801818,1801818,40040,23997, 0xdbe6d5c4
+0,1801818,1801818,40040,23997, 0x2fe2d5c4
0,1841858,1841858,40040,16065, 0xe8f715b7, F=0x0
0,1881899,1881899,40040,16441, 0x0a4e060f, F=0x0
0,1921939,1921939,40040,17395, 0xa8edecc2, F=0x0
@@ -66,7 +66,7 @@
0,2282303,2282303,40040,13748, 0xed26aeb4, F=0x0
Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
On Thu, 1 Aug 2024 at 00:58, Anton Khirnov wrote:
>
Thanks for the review.
> Quoting Josh Allmann (2024-07-09 21:05:47)
> > Encoders may emit a buffering period SEI without a corresponding
> > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
> >
> > During Annex B conversion, this may result in the SPS/PPS being
> > inserted *after* the buffering period SEI but before the IDR NAL.
> >
> > Since the buffering period SEI references the SPS, the SPS/PPS
> > needs to come first.
> > ---
> >
> > Notes:
> > v2: Updated FATE test refs
> >
> > libavcodec/bsf/h264_mp4toannexb.c | 13 +
> > tests/ref/fate/h264-bsf-mp4toannexb| 2 +-
> > tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +-
> > tests/ref/fate/segment-mp4-to-ts | 12 ++--
> > 4 files changed, 29 insertions(+), 16 deletions(-)
> >
> > diff --git a/libavcodec/bsf/h264_mp4toannexb.c
> > b/libavcodec/bsf/h264_mp4toannexb.c
> > index 92af6a6881..6607f1e91a 100644
> > --- a/libavcodec/bsf/h264_mp4toannexb.c
> > +++ b/libavcodec/bsf/h264_mp4toannexb.c
> > @@ -363,6 +363,19 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
> > AVPacket *opkt)
> > if (!new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] &
> > 0x80))
> > new_idr = 1;
> >
> > +/* If this is a buffering period SEI without a corresponding
> > sps/pps
> > + * then prepend any existing sps/pps before the SEI */
> > +if (unit_type == H264_NAL_SEI && buf[1] == 0 && !sps_seen &&
> > !pps_seen) {
>
> That 0 should be SEI_TYPE_BUFFERING_PERIOD, right?
>
Yes - fixed
> > +if (s->sps_size) {
> > +count_or_copy(&out, &out_size, s->sps, s->sps_size,
> > PS_OUT_OF_BAND, j);
> > +sps_seen = 1;
> > +}
> > +if (s->pps_size) {
> > +count_or_copy(&out, &out_size, s->pps, s->pps_size,
> > PS_OUT_OF_BAND, j);
> > +pps_seen = 1;
> > +}
>
> Is there a reason to insert the PPS? IIUC only the SPS is needed.
>
I believe it would be needed if using this bsf with the segment muxer,
and segmentation happens on a recovery point (with a buffering
period), eg in the test fate-segment-mp4-to-ts . Granted it is kind of
incidental that this patch actually fixes that specific case. I have
never seen a SPS without a PPS though.
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@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/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
On Thu, 1 Aug 2024 at 14:37, Josh Allmann wrote:
>
> Encoders may emit a buffering period SEI without a corresponding
> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
>
> During Annex B conversion, this may result in the SPS/PPS being
> inserted *after* the buffering period SEI but before the IDR NAL.
>
> Since the buffering period SEI references the SPS, the SPS/PPS
> needs to come first.
> ---
> libavcodec/bsf/h264_mp4toannexb.c | 15 +++
> tests/ref/fate/h264-bsf-mp4toannexb| 2 +-
> tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +-
> tests/ref/fate/segment-mp4-to-ts | 12 ++--
> 4 files changed, 31 insertions(+), 16 deletions(-)
>
Ping for (re-)review on this patch which addresses comments from [1]
Explanation for the FATE changes here [2] - it turns out that several
of the FATE samples exhibit the same behavior that this patch fixes,
so it is a net improvement
[1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-August/331958.html
[2] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-July/330912.html
Josh
> diff --git a/libavcodec/bsf/h264_mp4toannexb.c
> b/libavcodec/bsf/h264_mp4toannexb.c
> index 92af6a6881..dda064287e 100644
> --- a/libavcodec/bsf/h264_mp4toannexb.c
> +++ b/libavcodec/bsf/h264_mp4toannexb.c
> @@ -30,6 +30,7 @@
> #include "bytestream.h"
> #include "defs.h"
> #include "h264.h"
> +#include "sei.h"
>
> typedef struct H264BSFContext {
> uint8_t *sps;
> @@ -363,6 +364,20 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
> AVPacket *opkt)
> if (!new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] &
> 0x80))
> new_idr = 1;
>
> +/* If this is a buffering period SEI without a corresponding
> sps/pps
> + * then prepend any existing sps/pps before the SEI */
> +if (unit_type == H264_NAL_SEI && buf[1] ==
> SEI_TYPE_BUFFERING_PERIOD &&
> +!sps_seen && !pps_seen) {
> +if (s->sps_size) {
> +count_or_copy(&out, &out_size, s->sps, s->sps_size,
> PS_OUT_OF_BAND, j);
> +sps_seen = 1;
> +}
> +if (s->pps_size) {
> +count_or_copy(&out, &out_size, s->pps, s->pps_size,
> PS_OUT_OF_BAND, j);
> +pps_seen = 1;
> +}
> +}
> +
> /* prepend only to the first type 5 NAL unit of an IDR picture,
> if no sps/pps are already present */
> if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen &&
> !pps_seen) {
> if (s->sps_size)
> diff --git a/tests/ref/fate/h264-bsf-mp4toannexb
> b/tests/ref/fate/h264-bsf-mp4toannexb
> index 2049f39701..81ff568f3d 100644
> --- a/tests/ref/fate/h264-bsf-mp4toannexb
> +++ b/tests/ref/fate/h264-bsf-mp4toannexb
> @@ -1 +1 @@
> -5f04c27cc6ee8625fe2405fb0f7da9a3
> +ff2551123909f54c382294baa1bb4364
> diff --git a/tests/ref/fate/h264_mp4toannexb_ticket2991
> b/tests/ref/fate/h264_mp4toannexb_ticket2991
> index f8e3e920d4..9a1fbf2f8c 100644
> --- a/tests/ref/fate/h264_mp4toannexb_ticket2991
> +++ b/tests/ref/fate/h264_mp4toannexb_ticket2991
> @@ -1,4 +1,4 @@
> -05d66e60ab22ee004720e0051af0fe74
> *tests/data/fate/h264_mp4toannexb_ticket2991.h264
> +b6ff5910928ad0b2a7eec481dcc41594
> *tests/data/fate/h264_mp4toannexb_ticket2991.h264
> 1985815 tests/data/fate/h264_mp4toannexb_ticket2991.h264
> #extradata 0: 47, 0x3a590d55
> #tb 0: 1/120
> @@ -6,7 +6,7 @@
> #codec_id 0: h264
> #dimensions 0: 1280x720
> #sar 0: 3/4
> -0, 0, 0,40040,37126, 0xb020184c
> +0, 0, 0,40040,37126, 0x515c184c
> 0, 40040, 40040,40040, 6920, 0x8512361a, F=0x0
> 0, 80081, 80081,40040, 7550, 0x1bc56ed4, F=0x0
> 0, 120121, 120121,40040, 8752, 0xb8c6f0a1, F=0x0
> @@ -21,7 +21,7 @@
> 0, 480485, 480485,40040,11234, 0x83cbd9fd, F=0x0
> 0, 520525, 520525,40040,17616, 0xfdf95104, F=0x0
> 0, 560566, 560566,40040,10689, 0x9633d32b, F=0x0
> -0, 600606, 600606,40040,45291, 0x543c2cf6
> +0, 600606, 600606,40040,45291, 0xa8292cf6
> 0, 640646, 640646,40040,20837, 0x051abfab, F=0x0
> 0, 680687, 680687,40040,21418, 0xe2a59d70, F=0x0
> 0, 720727, 720727,40040,15643, 0x15cf2cec, F=0x0
> @@ -36,7 +36,7 @@
> 0,1081091,1081091,40040,13130, 0xcbb6bb
Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
On Wed, 7 Aug 2024 at 09:13, Josh Allmann wrote: > > On Thu, 1 Aug 2024 at 14:37, Josh Allmann wrote: > > > > Encoders may emit a buffering period SEI without a corresponding > > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc. > > > > During Annex B conversion, this may result in the SPS/PPS being > > inserted *after* the buffering period SEI but before the IDR NAL. > > > > Since the buffering period SEI references the SPS, the SPS/PPS > > needs to come first. > > --- > > libavcodec/bsf/h264_mp4toannexb.c | 15 +++ > > tests/ref/fate/h264-bsf-mp4toannexb| 2 +- > > tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +- > > tests/ref/fate/segment-mp4-to-ts | 12 ++-- > > 4 files changed, 31 insertions(+), 16 deletions(-) > > > > Ping for (re-)review on this patch which addresses comments from [1] > > Explanation for the FATE changes here [2] - it turns out that several > of the FATE samples exhibit the same behavior that this patch fixes, > so it is a net improvement > > [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-August/331958.html > [2] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-July/330912.html > Gentle ping for re-review. Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] [IMPORTANT] Meeting Notes - December 2020
Hi all, Here are the notes from the FFmpeg developer meeting of the 5th of December 2020, 15:00 UTC: # Notes A recording of the call and IRC logs are available on YouTube and the Wiki respectively: - https://youtu.be/1EjIdYuWXEM - https://trac.ffmpeg.org/wiki/FFmeeting/2020-12 Some extra topics were discussed in the meeting. The notes are cleaned up to have actionable points. ## Proposed Agenda https://ffmpeg.org/pipermail/ffmpeg-devel/2020-November/272272.html - Tech / Comm committees, how-to in practice - GSoC adaptations for upcoming years - Splitting libraries (lavf->lavio) - Deprecating libpostproc - Writing down development rules - Switching to a merge request-like system - Propose FFmpeg/SPI purchase a Mac Mini ARM machine for development (and FATE if required). ## People Present (15) - Jean-Baptiste Kempf - Josh Dekker (Illya) - Jan Ekström - Michael Niedermayer - Gyan Doshi - Lynne - Kieran Kunhya - Mark Thompson - Anton Khirnov - Paul B Mahol - Steven Liu - Marvin Scholz - Andriy Gelman - Linjie Fu - James Almer ## Topics discussed ### Topic 1.0: Technical Comittee Clarify Technical Process on the mailing list -> vote in one week, in a Yes/No fashion. Question in 100 word Tech limit on the number of words * The question is limited to the one hundred words, so for example of the form "should we do X rather than Y?". * The background to the question will likely be complex and can be explained in detail elsewhere. * The intent of this restriction is to avoid an unclear question or any ambiguity in the answer. Action points - [Mark and Lynne] Submit an updated patch to clarify how the 100 word limit works. ### Topic 1.1: Community committees A Community Code of Conduct was written by j-b, needs review. The CoC MUST HAVE abuse limits of TC and CC. Action points * [Josh, JEEB, Kieran and Michael] Pre-review * [j-b] Post CoC on mailing list for general review * [GA] Vote on CoC in the same format as technical process **Goal: everything voted end of Dec 2020** ### Topic 2: GSoC GSoC was shortened to 5 weeks, project should take around 150 hours, overall time is halved. Small projects are generally more boring and less useful. Kieran and Lynne believe we should stop doing GSoC. Anton noted that GSoC is not a burden on people who don't care about it. Going forward projects would have to be restructured from the types of projects previously. They should be more integrated with community \& more specifically detailed. Suggestions included smaller optimisation projects (still lots of assembly unwritten). Action points - [Carl] Setup wiki page for *small*, *self-contained*, *specific* GSoC project ideas. ### Topic 3: splitting and merging libraries Topic 3.1 libavdevice Libavdevice is very tightly coupled to libavformat, so should be merged into it. Apparently nobody is against. Anton is working on the merge. Topic 3.2 merging all libraries into one Steven mentions it is useful for his use case to build a single libffmpeg.so JB replies this makes sense for some cases, but not for others, multiple separate libraries are preferable for many other cases. Discussion of various open source libraries moving to meson. # Action points - [Who?] More discussion on how to do a mega-library and if we should document it. Lynne suggests only this mega-library to be a static library. - [Requires further discussion] Do we support libffmpeg.a|.so in the build system? Topic 3.3 Splitting libavformat IO into libavio Some API users would prefer this functionality to be separate, as it involves network communication and such. Additionally, it would allow proper IO in other libraries, such as lavc and lavfi. Question whether IO can be moved to libavutil. Conclusion -> libavutil is big enough already # Action points - [Anton] Reflect on how to split IO out of lavf into libavio - [Requires further discussion] Point raised whether hwcontext should be split off from libavutil Topic 3.4 Splitting libavutil hwcontext into its own library Mark mentions that hardware context should move to a separate library? Anton says it is probably inconvenient for distros that lavu links to many hwaccel libs -> libavhwcontext makes sense. Nobody raises objections to this. # Action points - [Who?] Reflect on whether it makes sense to do, and if so split hardware contexts into separate library ## Topic 4: deprecating libpostproc Libpostproc does not have any external users (Kodi was thought to use it directly but was confirmed as not a user). There is no need for it to be a standalone library. A few options were suggested: - remove it all together - merge in libavfilter - move it to another repo Kieran wants to move to a different repo, Anton noted that libpostproc is already in external repo, the one from Libav. Michael wants to leave it as it is or integrate it into libavfilter. Action poin
[FFmpeg-devel] [RFC] Machines & Platforms of interest for testing
Hi, As discussed in the meeting, I'm starting a RFC for Machines & Platforms of interest for testing, developer access and FATE. These would be funded by SPI. The two platforms mentioned were a Mac Mini (M1 Apple Silicon platform) and a TALOS II (POWER9 platform). My personal suggestion would be a machine with both a modern nVidia GPU and AMD GPU for testing hardware acceleration integration. Kieran offered to host one Mac Mini, though I'm unsure what his capacity for hosting is. Any comments and suggestions welcome. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] Moves yuv2yuvX_sse3 to yasm, unrolls main loop and other small optimizations for ~20% speedup.
On 2020/12/09 11:19, Alan Kelly wrote:
---
Activates avx2 version of yuv2yuvX
Adds checkasm for yuv2yuvX
Modifies ff_yuv2yuvX_* signature to match yuv2yuvX_*
Replaces non-temporal stores with temporal stores
libswscale/x86/Makefile | 1 +
libswscale/x86/swscale.c| 106 +---
libswscale/x86/yuv2yuvX.asm | 118
tests/checkasm/sw_scale.c | 101 +-
4 files changed, 249 insertions(+), 77 deletions(-)
create mode 100644 libswscale/x86/yuv2yuvX.asm
[...]
diff --git a/tests/checkasm/sw_scale.c b/tests/checkasm/sw_scale.c
index 9efa2b4def..7009169361 100644
--- a/tests/checkasm/sw_scale.c
+++ b/tests/checkasm/sw_scale.c
[...]
+static void check_yuv2yuvX(void)
+{
+struct SwsContext *ctx;
+int fsi, osi;
+#define LARGEST_FILTER 8
+#define FILTER_SIZES 4
+static const int filter_sizes[FILTER_SIZES] = {1, 4, 8, 16};
+
+declare_func_emms(AV_CPU_FLAG_MMX, void, const int16_t *filter,
+ int filterSize, const int16_t **src, uint8_t *dest,
+ int dstW, const uint8_t *dither, int offset);
+
+int dstW = SRC_PIXELS;
+const int16_t **src;
+LOCAL_ALIGNED_32(int16_t, filter_coeff, [LARGEST_FILTER]);
+LOCAL_ALIGNED_32(uint8_t, dst0, [SRC_PIXELS]);
+LOCAL_ALIGNED_32(uint8_t, dst1, [SRC_PIXELS]);
+LOCAL_ALIGNED_32(uint8_t, dither, [SRC_PIXELS]);
+union VFilterData{
+const int16_t *src;
+uint16_t coeff[8];
+} *vFilterData;
+uint8_t d_val = rnd();
+randomize_buffers(filter_coeff, LARGEST_FILTER);
+ctx = sws_alloc_context();
+if (sws_init_context(ctx, NULL, NULL) < 0)
+fail();
+
+ff_sws_init_swscale_x86(ctx);
This should be ff_getSwsFunc() instead.
+for(int i = 0; i < SRC_PIXELS; ++i){
+dither[i] = d_val;
+}
[...]
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/movenc: Remove dts delay from duration.
A negative start_dts value (eg, delay from edit lists) typically yields
a duration larger than end_pts. During edit list processing, the
delay is removed again, yielding the correct duration within the elst.
However, other duration-carrying atoms (tkhd, mvhd, mdhd) still have
the delay incorporated into their durations. This is incorrect.
Fix this by withholding delay from the duration if edit lists are used.
This also simplifies edit-list processing a bit, since the delay
does not need to be removed from the calculated duration again.
---
The mov spec says that the tkhd duration is "derived from the track's
edits" [1] and the duratons of the other atoms (mvhd, mdhd) are in turn
taken from the longest track. So it seems that incorporating the delay
into the track duration is a bug in itself when the edit list has the
correct duration, and this propagates out tothe other top-level durations.
Unsure of how this change interacts with other modes that may expect
negative timestamps such as CMAF, so the patch errs on the side of
caution and only takes effect if edit lists are used. Can loosen that
up if necessary.
[1]
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP4939-CH204-BBCEIDFA
libavformat/movenc.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 7db2e28840..31441a9f6c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2831,7 +2831,14 @@ static int64_t calc_pts_duration(MOVMuxContext *mov,
MOVTrack *track)
if (track->end_pts != AV_NOPTS_VALUE &&
track->start_dts != AV_NOPTS_VALUE &&
track->start_cts != AV_NOPTS_VALUE) {
-return track->end_pts - (track->start_dts + track->start_cts);
+int64_t dur = track->end_pts, delay = track->start_dts +
track->start_cts;
+/* Note, this delay is calculated from the pts of the first sample,
+ * ensuring that we don't reduce the duration for cases with
+ * dts<0 pts=0. */
+if (delay > 0 || !mov->use_editlist) {
+ dur -= delay;
+}
+return dur;
}
return track->track_duration;
}
@@ -3118,10 +3125,6 @@ static int mov_write_edts_tag(AVIOContext *pb,
MOVMuxContext *mov,
* rounded to 0 when represented in MOV_TIMESCALE units. */
av_assert0(av_rescale_rnd(start_dts, MOV_TIMESCALE, track->timescale,
AV_ROUND_DOWN) <= 0);
start_ct = -FFMIN(start_dts, 0);
-/* Note, this delay is calculated from the pts of the first sample,
- * ensuring that we don't reduce the duration for cases with
- * dts<0 pts=0. */
-duration += delay;
}
/* For fragmented files, we don't know the full length yet. Setting
--
2.24.3 (Apple Git-128)
___
ffmpeg-devel mailing list
ffmpeg-devel@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/movenc: Remove dts delay from duration.
On Fri, 11 Dec 2020 at 14:07, Martin Storsjö wrote:
>
> On Fri, 11 Dec 2020, Josh Allmann wrote:
>
> > A negative start_dts value (eg, delay from edit lists) typically yields
> > a duration larger than end_pts. During edit list processing, the
> > delay is removed again, yielding the correct duration within the elst.
> >
> > However, other duration-carrying atoms (tkhd, mvhd, mdhd) still have
> > the delay incorporated into their durations. This is incorrect.
> >
> > Fix this by withholding delay from the duration if edit lists are used.
> > This also simplifies edit-list processing a bit, since the delay
> > does not need to be removed from the calculated duration again.
> > ---
> >
> > The mov spec says that the tkhd duration is "derived from the track's
> > edits" [1] and the duratons of the other atoms (mvhd, mdhd) are in turn
> > taken from the longest track. So it seems that incorporating the delay
> > into the track duration is a bug in itself when the edit list has the
> > correct duration, and this propagates out tothe other top-level durations.
> >
> > Unsure of how this change interacts with other modes that may expect
> > negative timestamps such as CMAF, so the patch errs on the side of
> > caution and only takes effect if edit lists are used. Can loosen that
> > up if necessary.
> >
> > [1]
> > https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP4939-CH204-BBCEIDFA
> >
> > libavformat/movenc.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> > index 7db2e28840..31441a9f6c 100644
> > --- a/libavformat/movenc.c
> > +++ b/libavformat/movenc.c
> > @@ -2831,7 +2831,14 @@ static int64_t calc_pts_duration(MOVMuxContext *mov,
> > MOVTrack *track)
> > if (track->end_pts != AV_NOPTS_VALUE &&
> > track->start_dts != AV_NOPTS_VALUE &&
> > track->start_cts != AV_NOPTS_VALUE) {
> > -return track->end_pts - (track->start_dts + track->start_cts);
> > +int64_t dur = track->end_pts, delay = track->start_dts +
> > track->start_cts;
> > +/* Note, this delay is calculated from the pts of the first sample,
> > + * ensuring that we don't reduce the duration for cases with
> > + * dts<0 pts=0. */
>
> If you have a stream starting with dts<0 pts=0, you'll have start_pts =
> start_dts + start_cts = 0. That gives delay=0 after your modification. But
> the comment says "don't reduce the duration for cases with pts=0" - where
> the delay variable would be zero anyway?
>
I'm not quite sure what you mean - that the comment is outdated?
Or that this modification would perhaps not behave as expected?
For what it's worth, the cases I'm concerned with have start_pts < 0.
>
>
> I don't manage to follow the reasoning and explanation in the commit
> message. To be able to concretely reason about this issue at all, we need
> to look at a concrete example. Can you provide a sample input file and a
> reproducible command, and point out which exact field in the muxer output
> of that case that you consider wrong?
>
Had to create a trac to find somewhere to host the sample. Tried to put
some details there but the formatting seems messed up and I can't figure
out how to edit, apologies. So here is some more info -
Input sample:
https://trac.ffmpeg.org/raw-attachment/ticket/9028/test-timecode.mp4
Run the following for a transmuxed clip from 3s for a 5s duration:
ffmpeg -ss 3 -i test-timecode.mp4 -t 5 -c copy out.mp4
Note that the actual cut location is mid-GOP, so there's a 1s pts delay
at the beginning of the output file with negative pts.
ffprobe shows:
ffprobe -show_streams -show_format out.mp4 2>&1 | grep duration=
duration=5.166992 # stream duration - correct
duration=6.167000 # format duration - incorrect
mp4dump'ing out.mp4 gives this:
# incorrect: duration should be sum of elst durations
[tkhd] size=12+80, flags=3
duration = 6167
# correct
[elst] size=12+16
entry_count = 1
entry/segment duration = 5167
# incorrect; derived from track duration (tkhd)
[mvhd] size=12+96
timescale = 1000
duration = 6167
> // Martin
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/movenc: Remove dts delay from duration.
Hi Martin,
On Sat, 19 Dec 2020 at 15:10, Martin Storsjö wrote:
>
> On Fri, 11 Dec 2020, Josh Allmann wrote:
>
> > On Fri, 11 Dec 2020 at 14:07, Martin Storsjö wrote:
> >>
> >> On Fri, 11 Dec 2020, Josh Allmann wrote:
> >>
> >> > A negative start_dts value (eg, delay from edit lists) typically yields
> >> > a duration larger than end_pts. During edit list processing, the
> >> > delay is removed again, yielding the correct duration within the elst.
> >> >
> >> > However, other duration-carrying atoms (tkhd, mvhd, mdhd) still have
> >> > the delay incorporated into their durations. This is incorrect.
> >> >
> >> > Fix this by withholding delay from the duration if edit lists are used.
> >> > This also simplifies edit-list processing a bit, since the delay
> >> > does not need to be removed from the calculated duration again.
> >> > ---
> >> >
> >> > The mov spec says that the tkhd duration is "derived from the track's
> >> > edits" [1] and the duratons of the other atoms (mvhd, mdhd) are in turn
> >> > taken from the longest track. So it seems that incorporating the delay
> >> > into the track duration is a bug in itself when the edit list has the
> >> > correct duration, and this propagates out tothe other top-level
> >> > durations.
> >> >
> >> > Unsure of how this change interacts with other modes that may expect
> >> > negative timestamps such as CMAF, so the patch errs on the side of
> >> > caution and only takes effect if edit lists are used. Can loosen that
> >> > up if necessary.
> >> >
> >> > [1]
> >> > https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP4939-CH204-BBCEIDFA
> >> >
> >> > libavformat/movenc.c | 13 -
> >> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> >> > index 7db2e28840..31441a9f6c 100644
> >> > --- a/libavformat/movenc.c
> >> > +++ b/libavformat/movenc.c
> >> > @@ -2831,7 +2831,14 @@ static int64_t calc_pts_duration(MOVMuxContext
> >> > *mov, MOVTrack *track)
> >> > if (track->end_pts != AV_NOPTS_VALUE &&
> >> > track->start_dts != AV_NOPTS_VALUE &&
> >> > track->start_cts != AV_NOPTS_VALUE) {
> >> > -return track->end_pts - (track->start_dts + track->start_cts);
> >> > +int64_t dur = track->end_pts, delay = track->start_dts +
> >> > track->start_cts;
> >> > +/* Note, this delay is calculated from the pts of the first
> >> > sample,
> >> > + * ensuring that we don't reduce the duration for cases with
> >> > + * dts<0 pts=0. */
> >>
> >> If you have a stream starting with dts<0 pts=0, you'll have start_pts =
> >> start_dts + start_cts = 0. That gives delay=0 after your modification. But
> >> the comment says "don't reduce the duration for cases with pts=0" - where
> >> the delay variable would be zero anyway?
> >>
> >
> > I'm not quite sure what you mean - that the comment is outdated?
> > Or that this modification would perhaps not behave as expected?
> >
> > For what it's worth, the cases I'm concerned with have start_pts < 0.
> >
> >>
> >>
> >> I don't manage to follow the reasoning and explanation in the commit
> >> message. To be able to concretely reason about this issue at all, we need
> >> to look at a concrete example. Can you provide a sample input file and a
> >> reproducible command, and point out which exact field in the muxer output
> >> of that case that you consider wrong?
> >>
> >
> > Had to create a trac to find somewhere to host the sample. Tried to put
> > some details there but the formatting seems messed up and I can't figure
> > out how to edit, apologies. So here is some more info -
> >
> > Input sample:
> >
> > https://trac.ffmpeg.org/raw-attachment/ticket/9028/test-timecode.mp4
> >
> > Run the following for a transmuxed clip from 3s for a 5s duration:
> >
> > ffmpeg -ss 3 -i test-timecode.mp4 -t 5 -c copy out.mp4
> >
> > Note that the actual cut location is mid-GOP, so there's a 1s
Re: [FFmpeg-devel] FFmpeg buying an Apple M1 Mac Mini
On 2021/01/03 20:18, Michael Niedermayer wrote: On Sun, Jan 03, 2021 at 06:32:11PM +0100, Kieran Kunhya wrote: Hello, As it's 2021 I would like to propose FFmpeg purchase one or more (e.g FATE + development) Apple M1 Mac Minis and provide access to developers. This is something I have done a few years ago when AVX2 was a new instruction set. I can host these in the UK 24/7 and provide access and label them as belonging to the project and not me. < To clarify these will be hosted in a proper datacentre, with proper < connectivity, cooling etc. I would propose buying and getting reimbursed one or more of: - Apple M1 chip with 8‑core CPU, 8‑core GPU and 16‑core Neural Engine - 16GB unified memory - 1TB SSD storage - Gigabit Ethernet This is £1,299.00 in the UK right now on the Apple Site. assuming noone has objections or better suggestions LGTM thx Ok from me too. I would suggest getting 2x, one for only FATE and the other for general access & development for FFmpeg developers. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] lavc/aarch64: add HEVC add_residual NEON
Signed-off-by: Josh Dekker
---
checkasm: all 648 tests passed
hevc_add_res_4x4_8_c: 49.7
hevc_add_res_4x4_8_neon: 20.5
hevc_add_res_4x4_10_c: 46.0
hevc_add_res_4x4_10_neon: 19.0
hevc_add_res_8x8_8_c: 209.0
hevc_add_res_8x8_8_neon: 24.5
hevc_add_res_8x8_10_c: 192.7
hevc_add_res_8x8_10_neon: 27.0
hevc_add_res_16x16_8_c: 791.5
hevc_add_res_16x16_8_neon: 79.0
hevc_add_res_16x16_10_c: 711.0
hevc_add_res_16x16_10_neon: 77.7
hevc_add_res_32x32_8_c: 3431.2
hevc_add_res_32x32_8_neon: 306.5
hevc_add_res_32x32_10_c: 3825.0
hevc_add_res_32x32_10_neon: 299.5
libavcodec/aarch64/Makefile | 3 +
libavcodec/aarch64/hevcdsp_add_res_neon.S | 298 ++
libavcodec/aarch64/hevcdsp_idct_neon.S| 24 ++
libavcodec/aarch64/hevcdsp_init.c | 59 +
libavcodec/hevcdsp.c | 2 +
libavcodec/hevcdsp.h | 1 +
6 files changed, 387 insertions(+)
create mode 100644 libavcodec/aarch64/hevcdsp_add_res_neon.S
create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S
create mode 100644 libavcodec/aarch64/hevcdsp_init.c
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index f6434e40da..0eaafce74b 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -17,6 +17,7 @@ OBJS-$(CONFIG_VP8DSP) +=
aarch64/vp8dsp_init_aarch64.o
OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_init_aarch64.o \
aarch64/sbrdsp_init_aarch64.o
OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_init.o
+OBJS-$(CONFIG_HEVC_DECODER) += aarch64/hevcdsp_init.o
OBJS-$(CONFIG_OPUS_DECODER) += aarch64/opusdsp_init.o
OBJS-$(CONFIG_RV40_DECODER) += aarch64/rv40dsp_init_aarch64.o
OBJS-$(CONFIG_VC1DSP) += aarch64/vc1dsp_init_aarch64.o
@@ -53,6 +54,8 @@ NEON-OBJS-$(CONFIG_VP8DSP) +=
aarch64/vp8dsp_neon.o
# decoders/encoders
NEON-OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_neon.o
NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_neon.o
+NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_add_res_neon.o
\
+ aarch64/hevcdsp_idct_neon.o
NEON-OBJS-$(CONFIG_OPUS_DECODER)+= aarch64/opusdsp_neon.o
NEON-OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_neon.o
NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o
\
diff --git a/libavcodec/aarch64/hevcdsp_add_res_neon.S
b/libavcodec/aarch64/hevcdsp_add_res_neon.S
new file mode 100644
index 00..dc7e8127b9
--- /dev/null
+++ b/libavcodec/aarch64/hevcdsp_add_res_neon.S
@@ -0,0 +1,298 @@
+/* -*-armv8-*-
+ *
+ * AArch64 NEON optimised add residual functions for HEVC decoding
+ *
+ * Copyright (c) 2020 Josh Dekker
+ *
+ * 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/aarch64/asm.S"
+
+.macro clip10 in1, in2, c1, c2
+smax \in1, \in1, \c1
+smax \in2, \in2, \c1
+smin \in1, \in1, \c2
+smin \in2, \in2, \c2
+.endm
+
+function ff_hevc_add_residual_4x4_8_neon, export=1
+mov x3, x0
+ld1 {v0.S}[0], [x3], x2
+ld1 {v0.S}[1], [x3], x2
+ld1 {v1.S}[0], [x3], x2
+ld1 {v1.S}[1], [x3], x2
+ld1 { v2.8H-v3.8H}, [x1]
+ushll v4.8H, v0.8B, #0
+ushll v5.8H, v1.8B, #0
+add v6.8H, v4.8H, v2.8H
+add v7.8H, v5.8H, v3.8H
+sqxtun v0.8B, v6.8H
+sqxtun v1.8B, v7.8H
+st1 {v0.S}[0], [x0], x2
+st1 {v0.S}[1], [x0], x2
+st1 {v1.S}[0], [x0], x2
+st1 {v1.S}[1], [x0], x2
+ret
+endfunc
+
+function ff_hevc_add_residual_4x4_10_neon, export=1
+mov x3, x0
+movi v4.8H, #0
+mvni v5.8H, #0xFC, lsl #8
+ld1 {v0.D}[0], [x3], x2
+ld1 {v0.D}[1], [x3], x2
+ld1 {v1.D}[0], [x3], x2
+ld1 {v1.D}[1], [x3], x2
+ld1 { v2.8H-v3.8H}, [x1]
+add v2.8H, v0.8H, v2.8H
+add v3.8H, v1.8H, v3.8H
+clip10 v2.8H, v3.8H, v4.8H, v5.8H
+st1 {v2.D}[0], [x0], x2
+st1 {v2.D}[1], [x0], x2
+st1 {v3.D}[0], [x0], x2
+st1 {v3.D}[1], [x0], x2
+ret
+endfunc
+
+function ff_hevc_add_residual_8x8_8_neon, export=1
+mov x3, x0
+ld1 {v0.8B}, [x3], x2
+ld1 {v1.8B}, [x3], x2
+ld1 {v2.8B}, [x3], x2
+
[FFmpeg-devel] [PATCH 0/4] AArch64 NEON for HEVC
checkasm: all 657 tests passed hevc_add_res_4x4_8_c: 49.7 hevc_add_res_4x4_8_neon: 20.5 hevc_add_res_4x4_10_c: 45.7 hevc_add_res_4x4_10_neon: 18.7 hevc_add_res_8x8_8_c: 211.0 hevc_add_res_8x8_8_neon: 24.5 hevc_add_res_8x8_10_c: 195.7 hevc_add_res_8x8_10_neon: 24.0 hevc_add_res_16x16_8_c: 787.2 hevc_add_res_16x16_8_neon: 79.0 hevc_add_res_16x16_10_c: 714.7 hevc_add_res_16x16_10_neon: 77.7 hevc_add_res_32x32_8_c: 3444.2 hevc_add_res_32x32_8_neon: 306.5 hevc_add_res_32x32_10_c: 3820.7 hevc_add_res_32x32_10_neon: 299.5 hevc_idct_4x4_dc_8_c: 16.2 hevc_idct_4x4_dc_8_neon: 13.7 hevc_idct_4x4_dc_10_c: 16.2 hevc_idct_4x4_dc_10_neon: 14.5 hevc_idct_8x8_dc_8_c: 40.7 hevc_idct_8x8_dc_8_neon: 18.5 hevc_idct_8x8_dc_10_c: 39.2 hevc_idct_8x8_dc_10_neon: 19.2 hevc_idct_16x16_dc_8_c: 136.7 hevc_idct_16x16_dc_8_neon: 35.7 hevc_idct_16x16_dc_10_c: 136.0 hevc_idct_16x16_dc_10_neon: 36.0 hevc_idct_32x32_dc_8_c: 1386.7 hevc_idct_32x32_dc_8_neon: 132.0 hevc_idct_32x32_dc_10_c: 1366.2 hevc_idct_32x32_dc_10_neon: 132.0 hevc_sao_band_8x8_8_c: 230.7 hevc_sao_band_8x8_8_neon: 92.7 Please disregard my previous email with subject 'lavc/aarch64: add HEVC add_residual NEON', the patch was split incorrectly. IDCT (first) and QPEL functions in the works, then SAO edge, and whatever is left for parity with ARM NEON. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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/4] lavc/aarch64: add HEVC add_residual NEON
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile | 2 +
libavcodec/aarch64/hevcdsp_add_res_neon.S | 298 ++
libavcodec/aarch64/hevcdsp_init.c | 59 +
libavcodec/hevcdsp.c | 2 +
libavcodec/hevcdsp.h | 1 +
5 files changed, 362 insertions(+)
create mode 100644 libavcodec/aarch64/hevcdsp_add_res_neon.S
create mode 100644 libavcodec/aarch64/hevcdsp_init.c
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index f6434e40da..4bdd554e7e 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -17,6 +17,7 @@ OBJS-$(CONFIG_VP8DSP) +=
aarch64/vp8dsp_init_aarch64.o
OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_init_aarch64.o \
aarch64/sbrdsp_init_aarch64.o
OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_init.o
+OBJS-$(CONFIG_HEVC_DECODER) += aarch64/hevcdsp_init.o
OBJS-$(CONFIG_OPUS_DECODER) += aarch64/opusdsp_init.o
OBJS-$(CONFIG_RV40_DECODER) += aarch64/rv40dsp_init_aarch64.o
OBJS-$(CONFIG_VC1DSP) += aarch64/vc1dsp_init_aarch64.o
@@ -53,6 +54,7 @@ NEON-OBJS-$(CONFIG_VP8DSP) +=
aarch64/vp8dsp_neon.o
# decoders/encoders
NEON-OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_neon.o
NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_neon.o
+NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_add_res_neon.o
NEON-OBJS-$(CONFIG_OPUS_DECODER)+= aarch64/opusdsp_neon.o
NEON-OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_neon.o
NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o
\
diff --git a/libavcodec/aarch64/hevcdsp_add_res_neon.S
b/libavcodec/aarch64/hevcdsp_add_res_neon.S
new file mode 100644
index 00..4005366192
--- /dev/null
+++ b/libavcodec/aarch64/hevcdsp_add_res_neon.S
@@ -0,0 +1,298 @@
+/* -*-arm64-*-
+ *
+ * AArch64 NEON optimised add residual functions for HEVC decoding
+ *
+ * Copyright (c) 2020 Josh Dekker
+ *
+ * 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/aarch64/asm.S"
+
+.macro clip10 in1, in2, c1, c2
+smax \in1, \in1, \c1
+smax \in2, \in2, \c1
+smin \in1, \in1, \c2
+smin \in2, \in2, \c2
+.endm
+
+function ff_hevc_add_residual_4x4_8_neon, export=1
+mov x3, x0
+ld1 {v0.S}[0], [x3], x2
+ld1 {v0.S}[1], [x3], x2
+ld1 {v1.S}[0], [x3], x2
+ld1 {v1.S}[1], [x3], x2
+ld1 { v2.8H-v3.8H}, [x1]
+ushll v4.8H, v0.8B, #0
+ushll v5.8H, v1.8B, #0
+add v6.8H, v4.8H, v2.8H
+add v7.8H, v5.8H, v3.8H
+sqxtun v0.8B, v6.8H
+sqxtun v1.8B, v7.8H
+st1 {v0.S}[0], [x0], x2
+st1 {v0.S}[1], [x0], x2
+st1 {v1.S}[0], [x0], x2
+st1 {v1.S}[1], [x0], x2
+ret
+endfunc
+
+function ff_hevc_add_residual_4x4_10_neon, export=1
+mov x3, x0
+movi v4.8H, #0
+mvni v5.8H, #0xFC, lsl #8
+ld1 {v0.D}[0], [x3], x2
+ld1 {v0.D}[1], [x3], x2
+ld1 {v1.D}[0], [x3], x2
+ld1 {v1.D}[1], [x3], x2
+ld1 { v2.8H-v3.8H}, [x1]
+add v2.8H, v0.8H, v2.8H
+add v3.8H, v1.8H, v3.8H
+clip10 v2.8H, v3.8H, v4.8H, v5.8H
+st1 {v2.D}[0], [x0], x2
+st1 {v2.D}[1], [x0], x2
+st1 {v3.D}[0], [x0], x2
+st1 {v3.D}[1], [x0], x2
+ret
+endfunc
+
+function ff_hevc_add_residual_8x8_8_neon, export=1
+mov x3, x0
+ld1 {v0.8B}, [x3], x2
+ld1 {v1.8B}, [x3], x2
+ld1 {v2.8B}, [x3], x2
+ld1 {v3.8B}, [x3], x2
+ld1 {v4.8B}, [x3], x2
+ld1 {v5.8B}, [x3], x2
+ld1 {v6.8B}, [x3], x2
+ld1 {v7.8B}, [x3], x2
+ld1 { v16.8H-v19.8H}, [x1], #64
+ld1 { v20.8H-v23.8H}, [x1]
+ushll v24.8H, v0.8B, #0
+ushll v25.8H, v1.8B, #0
+ushll v26.8H, v2.8B, #0
+ushll v27.8H, v3.8B, #0
+ushll v28.8H, v4.8B, #0
+ushll v29.8H, v5.8B, #0
+ushll v30.8H, v6.8B, #0
+ushll v31.8H, v7.8B, #0
+add v0.8H, v24.8H, v16.8H
+add v1.8H, v25.8H, v17.8H
+add v2.8H, v26.8H, v18.8H
+add v3.8H, v27.8H, v19.8H
+add v4.8H, v28.8H, v20.8H
+add v5.8H, v29.8H, v21.8H
+add v6.8H, v30.8H, v22.8H
+add v7.8H, v31.8H, v23.8H
+sqxtun v24.8B, v0.8H
+sqxtun v25
[FFmpeg-devel] [PATCH 2/4] lavc/aarch64: add HEVC idct_dc NEON
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile| 3 +-
libavcodec/aarch64/hevcdsp_idct_neon.S | 74 ++
libavcodec/aarch64/hevcdsp_init.c | 19 +++
3 files changed, 95 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 4bdd554e7e..42d80bf74c 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -54,7 +54,8 @@ NEON-OBJS-$(CONFIG_VP8DSP) +=
aarch64/vp8dsp_neon.o
# decoders/encoders
NEON-OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_neon.o
NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_neon.o
-NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_add_res_neon.o
+NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_add_res_neon.o
\
+ aarch64/hevcdsp_idct_neon.o
NEON-OBJS-$(CONFIG_OPUS_DECODER)+= aarch64/opusdsp_neon.o
NEON-OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_neon.o
NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o
\
diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S
b/libavcodec/aarch64/hevcdsp_idct_neon.S
new file mode 100644
index 00..cd886bb6dc
--- /dev/null
+++ b/libavcodec/aarch64/hevcdsp_idct_neon.S
@@ -0,0 +1,74 @@
+/* -*-arm64-*-
+ *
+ * AArch64 NEON optimised IDCT functions for HEVC decoding
+ *
+ * Copyright (c) 2020 Josh Dekker
+ *
+ * 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/aarch64/asm.S"
+
+.macro idct_dc size bitdepth
+function ff_hevc_idct_\size\()x\size\()_dc_\bitdepth\()_neon, export=1
+ldrsh w1, [x0]
+mov w2, #(1 << (13 - \bitdepth))
+add w1, w1, #1
+asr w1, w1, #1
+add w1, w1, w2
+asr w1, w1, #(14 - \bitdepth)
+dup v0.8h, w1
+dup v1.8h, w1
+.if \size > 4
+dup v2.8h, w1
+dup v3.8h, w1
+.if \size > 16 /* dc 32x32 */
+mov x2, #4
+1:
+subs x2, x2, #1
+.endif
+.if \size > 8 /* dc 16x16 */
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
+.endif /* dc 8x8 */
+st1 {v0.8h-v3.8h}, [x0], #64
+st1 {v0.8h-v3.8h}, [x0], #64
+.if \size > 16 /* dc 32x32 */
+bne 1b
+.endif
+.else /* dc 4x4 */
+st1 {v0.8h-v1.8h}, [x0]
+.endif
+ret
+endfunc
+.endm
+
+idct_dc 4 8
+idct_dc 4 10
+
+idct_dc 8 8
+idct_dc 8 10
+
+idct_dc 16 8
+idct_dc 16 10
+
+idct_dc 32 8
+idct_dc 32 10
diff --git a/libavcodec/aarch64/hevcdsp_init.c
b/libavcodec/aarch64/hevcdsp_init.c
index f0a617ab39..2cd7ef3a6c 100644
--- a/libavcodec/aarch64/hevcdsp_init.c
+++ b/libavcodec/aarch64/hevcdsp_init.c
@@ -23,6 +23,15 @@
#include "libavcodec/hevcdsp.h"
#include "libavcodec/avcodec.h"
+void ff_hevc_idct_4x4_dc_8_neon(int16_t *coeffs);
+void ff_hevc_idct_8x8_dc_8_neon(int16_t *coeffs);
+void ff_hevc_idct_16x16_dc_8_neon(int16_t *coeffs);
+void ff_hevc_idct_32x32_dc_8_neon(int16_t *coeffs);
+void ff_hevc_idct_4x4_dc_10_neon(int16_t *coeffs);
+void ff_hevc_idct_8x8_dc_10_neon(int16_t *coeffs);
+void ff_hevc_idct_16x16_dc_10_neon(int16_t *coeffs);
+void ff_hevc_idct_32x32_dc_10_neon(int16_t *coeffs);
+
void ff_hevc_add_residual_4x4_8_neon(uint8_t *_dst, int16_t *coeffs,
ptrdiff_t stride);
void ff_hevc_add_residual_4x4_10_neon(uint8_t *_dst, int16_t *coeffs,
@@ -48,6 +57,11 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
c->add_residual[1] = ff_hevc_add_residual_8x8_8_neon;
c->add_residual[2] = ff_hevc_add_residual_16x16_8_neon;
c->add_residual[3] = ff_hevc_add_residual_32x32_8_neon;
+
+c->idct_dc[0] = ff_hevc_idct_4x4_dc_8_neon;
+c->idct_dc[1] = ff_hevc_idct_8x8_dc_8_neon;
+c->idct_dc[2] = ff_hevc_idct_16x16_dc_8_neon;
+c->idct_dc[3] = ff_hevc_idct_32x32_dc_8_neon;
}
if (have_
[FFmpeg-devel] [PATCH 3/4] lavc/aarch64: add HEVC sao_band NEON
Only works for 8x8.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile | 3 +-
libavcodec/aarch64/hevcdsp_init.c | 7 +++
libavcodec/aarch64/hevcdsp_sao_neon.S | 87 +++
3 files changed, 96 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch64/hevcdsp_sao_neon.S
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 42d80bf74c..1f54fc31f4 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -55,7 +55,8 @@ NEON-OBJS-$(CONFIG_VP8DSP) +=
aarch64/vp8dsp_neon.o
NEON-OBJS-$(CONFIG_AAC_DECODER) += aarch64/aacpsdsp_neon.o
NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_neon.o
NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_add_res_neon.o
\
- aarch64/hevcdsp_idct_neon.o
+ aarch64/hevcdsp_idct_neon.o
\
+ aarch64/hevcdsp_sao_neon.o
NEON-OBJS-$(CONFIG_OPUS_DECODER)+= aarch64/opusdsp_neon.o
NEON-OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_neon.o
NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o
\
diff --git a/libavcodec/aarch64/hevcdsp_init.c
b/libavcodec/aarch64/hevcdsp_init.c
index 2cd7ef3a6c..8f0a923ab1 100644
--- a/libavcodec/aarch64/hevcdsp_init.c
+++ b/libavcodec/aarch64/hevcdsp_init.c
@@ -23,6 +23,11 @@
#include "libavcodec/hevcdsp.h"
#include "libavcodec/avcodec.h"
+void ff_hevc_sao_band_filter_8x8_8_neon(uint8_t *_dst, uint8_t *_src,
+ ptrdiff_t stride_dst, ptrdiff_t stride_src,
+ int16_t *sao_offset_val, int sao_left_class,
+ int width, int height);
+
void ff_hevc_idct_4x4_dc_8_neon(int16_t *coeffs);
void ff_hevc_idct_8x8_dc_8_neon(int16_t *coeffs);
void ff_hevc_idct_16x16_dc_8_neon(int16_t *coeffs);
@@ -53,6 +58,8 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
{
int cpu_flags = av_get_cpu_flags();
if (have_neon(cpu_flags) && bit_depth == 8) {
+c->sao_band_filter[0] = ff_hevc_sao_band_filter_8x8_8_neon;
+
c->add_residual[0] = ff_hevc_add_residual_4x4_8_neon;
c->add_residual[1] = ff_hevc_add_residual_8x8_8_neon;
c->add_residual[2] = ff_hevc_add_residual_16x16_8_neon;
diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S
b/libavcodec/aarch64/hevcdsp_sao_neon.S
new file mode 100644
index 00..25b6c25117
--- /dev/null
+++ b/libavcodec/aarch64/hevcdsp_sao_neon.S
@@ -0,0 +1,87 @@
+/* -*-arm64-*-
+ * vim: syntax=arm64asm
+ *
+ * AArch64 NEON optimised SAO functions for HEVC decoding
+ *
+ * Copyright (c) 2020 Josh Dekker
+ *
+ * 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/aarch64/asm.S"
+
+// void sao_band_filter(uint8_t *_dst, uint8_t *_src,
+// ptrdiff_t stride_dst, ptrdiff_t stride_src,
+// int16_t *sao_offset_val, int sao_left_class,
+// int width, int height)
+function ff_hevc_sao_band_filter_8x8_8_neon, export=1
+sub sp, sp, #64
+stp xzr, xzr, [sp]
+stp xzr, xzr, [sp, #16]
+stp xzr, xzr, [sp, #32]
+stp xzr, xzr, [sp, #48]
+mov w8, #4
+.setup:
+ldrsh x9, [x4, x8, lsl #1] // x9 = sao_offset_val[k+1]
+subs w8, w8, #1
+add w10, w8, w5 // x10 = k + sao_left_class
+and w10, w10, #0x1F
+strh w9, [sp, x10, lsl #1]
+bne .setup
+ld1 {v16.16B-v19.16B}, [sp], #64
+movi v20.8H, #1
+0: // beginning of line
+mov w8, w6
+8:
+// Simple layout for accessing 16bit values
+// with 8bit LUT.
+//
+// 00 01 02 03 04 05 06 07
+// +--->
+// |xDE#xAD|xCA#xFE|xBE#xEF|xFE#xED|
+// +--->
+//i-0 i-1 i-2 i-3
+// dst[x] = av_clip_pixel(src[x] + offset_table[src[x] >> shift]);
+ld1 {v2.8B}, [x1]
+// load src[x]
+ushll v0.8H, v2.8B, #0
+// >> shift
+ushr v2.8H, v0.8H, #3 // BIT_DEPTH
[FFmpeg-devel] [PATCH 4/4] checkasm: add hevc_pel tests
Co-authored-by: Niklas Haas
Signed-off-by: Josh Dekker
---
tests/checkasm/Makefile | 2 +-
tests/checkasm/checkasm.c | 10 +
tests/checkasm/checkasm.h | 10 +
tests/checkasm/hevc_pel.c | 523 ++
4 files changed, 544 insertions(+), 1 deletion(-)
create mode 100644 tests/checkasm/hevc_pel.c
diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 9e9569777b..1827a4e134 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -24,7 +24,7 @@ AVCODECOBJS-$(CONFIG_HUFFYUV_DECODER) += huffyuvdsp.o
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_idct.o
hevc_sao.o
+AVCODECOBJS-$(CONFIG_HEVC_DECODER) += hevc_add_res.o hevc_idct.o
hevc_sao.o hevc_pel.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 b3ac76c325..8338e8ff58 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -116,6 +116,16 @@ static const struct {
#if CONFIG_HEVC_DECODER
{ "hevc_add_res", checkasm_check_hevc_add_res },
{ "hevc_idct", checkasm_check_hevc_idct },
+{ "hevc_qpel", checkasm_check_hevc_qpel },
+{ "hevc_qpel_uni", checkasm_check_hevc_qpel_uni },
+{ "hevc_qpel_uni_w", checkasm_check_hevc_qpel_uni_w },
+{ "hevc_qpel_bi", checkasm_check_hevc_qpel_bi },
+{ "hevc_qpel_bi_w", checkasm_check_hevc_qpel_bi_w },
+{ "hevc_epel", checkasm_check_hevc_epel },
+{ "hevc_epel_uni", checkasm_check_hevc_epel_uni },
+{ "hevc_epel_uni_w", checkasm_check_hevc_epel_uni_w },
+{ "hevc_epel_bi", checkasm_check_hevc_epel_bi },
+{ "hevc_epel_bi_w", checkasm_check_hevc_epel_bi_w },
{ "hevc_sao", checkasm_check_hevc_sao },
#endif
#if CONFIG_HUFFYUV_DECODER
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index 0190bc912c..ef6645e3a2 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -58,6 +58,16 @@ void checkasm_check_h264pred(void);
void checkasm_check_h264qpel(void);
void checkasm_check_hevc_add_res(void);
void checkasm_check_hevc_idct(void);
+void checkasm_check_hevc_qpel(void);
+void checkasm_check_hevc_qpel_uni(void);
+void checkasm_check_hevc_qpel_uni_w(void);
+void checkasm_check_hevc_qpel_bi(void);
+void checkasm_check_hevc_qpel_bi_w(void);
+void checkasm_check_hevc_epel(void);
+void checkasm_check_hevc_epel_uni(void);
+void checkasm_check_hevc_epel_uni_w(void);
+void checkasm_check_hevc_epel_bi(void);
+void checkasm_check_hevc_epel_bi_w(void);
void checkasm_check_hevc_sao(void);
void checkasm_check_huffyuvdsp(void);
void checkasm_check_jpeg2000dsp(void);
diff --git a/tests/checkasm/hevc_pel.c b/tests/checkasm/hevc_pel.c
new file mode 100644
index 00..236404f8ff
--- /dev/null
+++ b/tests/checkasm/hevc_pel.c
@@ -0,0 +1,523 @@
+/*
+ * Copyright (c) 2015 Henrik Gramner
+ *
+ * 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 "checkasm.h"
+#include "libavcodec/hevcdsp.h"
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+
+static const uint32_t pixel_mask[] = { 0x, 0x01ff01ff, 0x03ff03ff,
0x07ff07ff, 0x0fff0fff };
+static const uint32_t pixel_mask16[] = { 0x00ff00ff, 0x01ff01ff, 0x03ff03ff,
0x07ff07ff, 0x0fff0fff };
+static const int sizes[] = { -1, 4, 6, 8, 12, 16, 24, 32, 48, 64 };
+static const int weights[] = { 0, 128, 255, -1 };
+static const int denoms[] = {0, 7, 12, -1 };
+static const int offsets[] = {0, 255, -1 };
+
+#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
+#define BUF_SIZE (2 * MAX_PB_SIZE * (2 * 4 + MAX_PB_SIZE))
+
+#define randomize_buffers() \
+do { \
+uint32_t mask = p
Re: [FFmpeg-devel] [PATCH] libavcodec/hevcdsp: port SIMD idct functions from 32-bit.
Hi, On 2021-01-08 21:36, reimar.doeffin...@gmx.de wrote: From: Reimar Döffinger Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth available on aarch64. For a UHD HDR (10 bit) sample video these were consuming the most time and this optimization reduced overall decode time from 19.4s to 16.4s, approximately 15% speedup. Test sample was the first 300 frames of "LG 4K HDR Demo - New York.ts", running on Apple M1. --- libavcodec/aarch64/Makefile | 2 + libavcodec/aarch64/hevcdsp_idct_neon.S| 426 ++ libavcodec/aarch64/hevcdsp_init_aarch64.c | 45 +++ libavcodec/hevcdsp.c | 2 + libavcodec/hevcdsp.h | 1 + 5 files changed, 476 insertions(+) create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c [...] AS libavcodec/aarch64/hevcdsp_idct_neon.o libavcodec/aarch64/hevcdsp_idct_neon.S: Assembler messages: libavcodec/aarch64/hevcdsp_idct_neon.S:418: Error: operand mismatch -- `mov v29.4S,v28.4S' libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:did you mean this? libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.8b, v28.8b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:other valid variant(s): libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.16b, v28.16b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Error: operand mismatch -- `mov v29.4S,v28.4S' libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:did you mean this? libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.8b, v28.8b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:other valid variant(s): libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.16b, v28.16b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Error: operand mismatch -- `mov v29.4S,v28.4S' libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:did you mean this? libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.8b, v28.8b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:other valid variant(s): libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.16b, v28.16b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Error: operand mismatch -- `mov v29.4S,v28.4S' libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:did you mean this? libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.8b, v28.8b libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info:other valid variant(s): libavcodec/aarch64/hevcdsp_idct_neon.S:418: Info: mov v29.16b, v28.16b This doesn't build on GNU assembler (GNU Binutils for Ubuntu) 2.34 (aarch64). Thanks for porting this, I was in the process of writing HEVC assembly (see my set on the ML) and would be interested to rebase this on top of that set. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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/movenc: Remove dts delay from duration.
Hi Martin, On Fri, 15 Jan 2021 at 04:59, Martin Storsjö wrote: > > Hi Josh, > > On Tue, 22 Dec 2020, Josh Allmann wrote: > > > Thank you for taking the time to look into this! Tested with your > > alternative patch and it does seem to be an improvement. I was able to > > find a case where it didn't seem to do the correct thing (described > > below), but this is not a regression; master doesn't do the correct > > thing, and neither does my patch. I haven't looked much at what the > > code is doing beyond running these tests, but could find some time to > > dig in early 2021 if it's not fixed by then. > > > > I think this issue isn't related to the mov muxer at least, but is more > related to how stream copy works at the ffmpeg.c level, and/or how the > seeking is done. > Thanks for the tip - still haven't had a chance to investigate the behavior. > As that's unrelated, and I haven't heard any objections to my version of > the patch, I think I'll go ahead and land it soon then. > The patch is certainly an improvement over the current behavior, no objections from me. Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] configure: add fallback to $arch in msvc assembler check.
On 2021-01-23 14:14, Martin Storsjö wrote:
On Sat, 23 Jan 2021, Reimar Döffinger wrote:
Setting the defaults for $arch happens only later, so
the current code would not set AS correctly if --arch
was not specified on the command-line.
Fix it by adding an explicit fallback to $arch_default.
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 54fbbd6b5f..df298b4b9b 100755
--- a/configure
+++ b/configure
@@ -4268,7 +4268,7 @@ case "$toolchain" in
ld_default="$source_path/compat/windows/mslink"
nm_default="dumpbin.exe -symbols"
ar_default="lib.exe"
- case "$arch" in
+ case "${arch:-$arch_default}" in
aarch64|arm64)
as_default="armasm64.exe"
;;
--
2.30.0
LGTM, thanks!
// Martin
Thanks, pushed.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@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/4] checkasm: add hevc_pel tests
On 2021-01-07 13:10, Josh Dekker wrote: Co-authored-by: Niklas Haas Signed-off-by: Josh Dekker --- tests/checkasm/Makefile | 2 +- tests/checkasm/checkasm.c | 10 + tests/checkasm/checkasm.h | 10 + tests/checkasm/hevc_pel.c | 523 ++ 4 files changed, 544 insertions(+), 1 deletion(-) create mode 100644 tests/checkasm/hevc_pel.c [...] Pushed (only this patch). -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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 for FFmpeg
On 2021-01-13 17:06, Robin Cooksey wrote: I’ve attached a patch which makes avformat handle the 308 Permanent Redirect HTTP status code – which is more recently defined in https://tools.ietf.org/html/rfc7538 The change just treats 308 in the same way as the other 30x status codes. Thanks. Applied with a slightly edited commit message to conform to our conventions & a small reference to the spec. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 0/4] avcodec/aarch64/hevcdsp
Hi, Rebases the unpushed part of my patches on top of Reimar's set. Also implements Martin's suggestions except 'unrolling the loop' for SAO band function, will update the band function when I fix non 8x8 cases. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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/4] avcodec/aarch64/hevcdsp: add idct_dc NEON
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/hevcdsp_idct_neon.S| 54 +++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 16 +++
2 files changed, 70 insertions(+)
diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S
b/libavcodec/aarch64/hevcdsp_idct_neon.S
index 329038a958..d3902a9e0f 100644
--- a/libavcodec/aarch64/hevcdsp_idct_neon.S
+++ b/libavcodec/aarch64/hevcdsp_idct_neon.S
@@ -5,6 +5,7 @@
*
* Ported from arm/hevcdsp_idct_neon.S by
* Copyright (c) 2020 Reimar Döffinger
+ * Copyright (c) 2020 Josh Dekker
*
* This file is part of FFmpeg.
*
@@ -568,3 +569,56 @@ tr_16x4 secondpass_10, 20 - 10, 512, 1
idct_16x16 8
idct_16x16 10
+
+// void ff_hevc_idct_NxN_dc_DEPTH_neon(int16_t *coeffs)
+.macro idct_dc size bitdepth
+function ff_hevc_idct_\size\()x\size\()_dc_\bitdepth\()_neon, export=1
+ldrsh w1, [x0]
+mov w2, #(1 << (13 - \bitdepth))
+add w1, w1, #1
+asr w1, w1, #1
+add w1, w1, w2
+asr w1, w1, #(14 - \bitdepth)
+dup v0.8h, w1
+dup v1.8h, w1
+.if \size > 4
+dup v2.8h, w1
+dup v3.8h, w1
+.if \size > 16 /* dc 32x32 */
+mov x2, #4
+1:
+subsx2, x2, #1
+.endif
+addx12, x0, #64
+movx13, #128
+.if \size > 8 /* dc 16x16 */
+st1 {v0.8h-v3.8h}, [ x0], x13
+st1 {v0.8h-v3.8h}, [x12], x13
+st1 {v0.8h-v3.8h}, [ x0], x13
+st1 {v0.8h-v3.8h}, [x12], x13
+st1 {v0.8h-v3.8h}, [ x0], x13
+st1 {v0.8h-v3.8h}, [x12], x13
+.endif /* dc 8x8 */
+st1 {v0.8h-v3.8h}, [ x0], x13
+st1 {v0.8h-v3.8h}, [x12], x13
+.if \size > 16 /* dc 32x32 */
+bne 1b
+.endif
+.else /* dc 4x4 */
+st1 {v0.8h-v1.8h}, [x0]
+.endif
+ret
+endfunc
+.endm
+
+idct_dc 4 8
+idct_dc 4 10
+
+idct_dc 8 8
+idct_dc 8 10
+
+idct_dc 16 8
+idct_dc 16 10
+
+idct_dc 32 8
+idct_dc 32 10
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index 4c29daa6d5..fe111bd1ac 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -45,6 +45,14 @@ void ff_hevc_idct_8x8_8_neon(int16_t *coeffs, int col_limit);
void ff_hevc_idct_8x8_10_neon(int16_t *coeffs, int col_limit);
void ff_hevc_idct_16x16_8_neon(int16_t *coeffs, int col_limit);
void ff_hevc_idct_16x16_10_neon(int16_t *coeffs, int col_limit);
+void ff_hevc_idct_4x4_dc_8_neon(int16_t *coeffs);
+void ff_hevc_idct_8x8_dc_8_neon(int16_t *coeffs);
+void ff_hevc_idct_16x16_dc_8_neon(int16_t *coeffs);
+void ff_hevc_idct_32x32_dc_8_neon(int16_t *coeffs);
+void ff_hevc_idct_4x4_dc_10_neon(int16_t *coeffs);
+void ff_hevc_idct_8x8_dc_10_neon(int16_t *coeffs);
+void ff_hevc_idct_16x16_dc_10_neon(int16_t *coeffs);
+void ff_hevc_idct_32x32_dc_10_neon(int16_t *coeffs);
av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, const int bit_depth)
{
@@ -57,6 +65,10 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
c->add_residual[3] = ff_hevc_add_residual_32x32_8_neon;
c->idct[1] = ff_hevc_idct_8x8_8_neon;
c->idct[2] = ff_hevc_idct_16x16_8_neon;
+c->idct_dc[0] = ff_hevc_idct_4x4_dc_8_neon;
+c->idct_dc[1] = ff_hevc_idct_8x8_dc_8_neon;
+c->idct_dc[2] = ff_hevc_idct_16x16_dc_8_neon;
+c->idct_dc[3] = ff_hevc_idct_32x32_dc_8_neon;
}
if (bit_depth == 10) {
c->add_residual[0] = ff_hevc_add_residual_4x4_10_neon;
@@ -65,5 +77,9 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
c->add_residual[3] = ff_hevc_add_residual_32x32_10_neon;
c->idct[1] = ff_hevc_idct_8x8_10_neon;
c->idct[2] = ff_hevc_idct_16x16_10_neon;
+c->idct_dc[0] = ff_hevc_idct_4x4_dc_10_neon;
+c->idct_dc[1] = ff_hevc_idct_8x8_dc_10_neon;
+c->idct_dc[2] = ff_hevc_idct_16x16_dc_10_neon;
+c->idct_dc[3] = ff_hevc_idct_32x32_dc_10_neon;
}
}
--
2.24.3 (Apple Git-128)
___
ffmpeg-devel mailing list
ffmpeg-devel@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/4] avcodec/aarch64/hevcdsp: port add_residual functions
From: Reimar Döffinger
Speedup is fairly small, around 1.5%, but these are fairly simple.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/hevcdsp_idct_neon.S| 190 ++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 24 +++
2 files changed, 214 insertions(+)
diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S
b/libavcodec/aarch64/hevcdsp_idct_neon.S
index c70d6a906d..329038a958 100644
--- a/libavcodec/aarch64/hevcdsp_idct_neon.S
+++ b/libavcodec/aarch64/hevcdsp_idct_neon.S
@@ -36,6 +36,196 @@ const trans, align=4
.short 31, 22, 13, 4
endconst
+.macro clip10 in1, in2, c1, c2
+smax\in1, \in1, \c1
+smax\in2, \in2, \c1
+smin\in1, \in1, \c2
+smin\in2, \in2, \c2
+.endm
+
+function ff_hevc_add_residual_4x4_8_neon, export=1
+ld1 {v0.8h-v1.8h}, [x1]
+ld1 {v2.s}[0], [x0], x2
+ld1 {v2.s}[1], [x0], x2
+ld1 {v2.s}[2], [x0], x2
+ld1 {v2.s}[3], [x0], x2
+sub x0, x0, x2, lsl #2
+uxtlv6.8h, v2.8B
+uxtl2 v7.8h, v2.16B
+sqadd v0.8h, v0.8h, v6.8h
+sqadd v1.8h, v1.8h, v7.8h
+sqxtun v0.8B, v0.8h
+sqxtun2 v0.16B, v1.8h
+st1 {v0.s}[0], [x0], x2
+st1 {v0.s}[1], [x0], x2
+st1 {v0.s}[2], [x0], x2
+st1 {v0.s}[3], [x0], x2
+ret
+endfunc
+
+function ff_hevc_add_residual_4x4_10_neon, export=1
+mov x12, x0
+ld1 {v0.8h-v1.8h}, [x1]
+ld1 {v2.d}[0], [x12], x2
+ld1 {v2.d}[1], [x12], x2
+ld1 {v3.d}[0], [x12], x2
+sqadd v0.8h, v0.8h, v2.8h
+ld1 {V3.d}[1], [x12], x2
+moviv4.8h, #0
+sqadd v1.8h, v1.8h, v3.8h
+mvniv5.8h, #0xFC, LSL #8 // movi #0x3FF
+clip10 v0.8h, v1.8h, v4.8h, v5.8h
+st1 {v0.d}[0], [x0], x2
+st1 {v0.d}[1], [x0], x2
+st1 {v1.d}[0], [x0], x2
+st1 {v1.d}[1], [x0], x2
+ret
+endfunc
+
+function ff_hevc_add_residual_8x8_8_neon, export=1
+add x12, x0, x2
+add x2, x2, x2
+mov x3, #8
+1: subsx3, x3, #2
+ld1 {v2.d}[0], [x0]
+ld1 {v2.d}[1], [x12]
+uxtlv3.8h, v2.8B
+ld1 {v0.8h-v1.8h}, [x1], #32
+uxtl2 v2.8h, v2.16B
+sqadd v0.8h, v0.8h, v3.8h
+sqadd v1.8h, v1.8h, v2.8h
+sqxtun v0.8B, v0.8h
+sqxtun2 v0.16B, v1.8h
+st1 {v0.d}[0], [x0], x2
+st1 {v0.d}[1], [x12], x2
+bne 1b
+ret
+endfunc
+
+function ff_hevc_add_residual_8x8_10_neon, export=1
+add x12, x0, x2
+add x2, x2, x2
+mov x3, #8
+moviv4.8h, #0
+mvniv5.8h, #0xFC, LSL #8 // movi #0x3FF
+1: subsx3, x3, #2
+ld1 {v0.8h-v1.8h}, [x1], #32
+ld1 {v2.8h},[x0]
+sqadd v0.8h, v0.8h, v2.8h
+ld1 {v3.8h},[x12]
+sqadd v1.8h, v1.8h, v3.8h
+clip10 v0.8h, v1.8h, v4.8h, v5.8h
+st1 {v0.8h}, [x0], x2
+st1 {v1.8h}, [x12], x2
+bne 1b
+ret
+endfunc
+
+function ff_hevc_add_residual_16x16_8_neon, export=1
+mov x3, #16
+add x12, x0, x2
+add x2, x2, x2
+1: subsx3, x3, #2
+ld1 {v16.16B}, [x0]
+ld1 {v0.8h-v3.8h}, [x1], #64
+ld1 {v19.16B},[x12]
+uxtlv17.8h, v16.8B
+uxtl2 v18.8h, v16.16B
+uxtlv20.8h, v19.8B
+uxtl2 v21.8h, v19.16B
+sqadd v0.8h, v0.8h, v17.8h
+sqadd v1.8h, v1.8h, v18.8h
+sqadd v2.8h, v2.8h, v20.8h
+sqadd v3.8h, v3.8h, v21.8h
+sqxtun v0.8B, v0.8h
+sqxtun2 v0.16B, v1.8h
+sqxtun v1.8B, v2.8h
+sqxtun2 v1.16B, v3.8h
+st1 {v0.16B}, [x0], x2
+st1 {v1.16B}, [x12], x2
+bne 1b
+ret
+endfunc
+
+function ff_hevc_add_residual_16x16_10_neon, export=1
+mov x3, #16
+moviv20.8h, #0
+mvniv21.8h, #0xFC, LSL #8 // movi #0x3FF
+add x12, x0, x2
+add
[FFmpeg-devel] [PATCH v2 1/4] avcodec/aarch64/hevcdsp: port SIMD idct functions
From: Reimar Döffinger Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth available on aarch64. For a UHD HDR (10 bit) sample video these were consuming the most time and this optimization reduced overall decode time from 19.4s to 16.4s, approximately 15% speedup. Test sample was the first 300 frames of "LG 4K HDR Demo - New York.ts", running on Apple M1. Signed-off-by: Josh Dekker --- libavcodec/aarch64/Makefile | 2 + libavcodec/aarch64/hevcdsp_idct_neon.S| 380 ++ libavcodec/aarch64/hevcdsp_init_aarch64.c | 45 +++ libavcodec/hevcdsp.c | 2 + libavcodec/hevcdsp.h | 1 + 5 files changed, 430 insertions(+) create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile index f6434e40da..2ea1d74a38 100644 --- a/libavcodec/aarch64/Makefile +++ b/libavcodec/aarch64/Makefile @@ -61,3 +61,5 @@ NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o \ aarch64/vp9lpf_neon.o \ aarch64/vp9mc_16bpp_neon.o \ aarch64/vp9mc_neon.o +NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_idct_neon.o \ + aarch64/hevcdsp_init_aarch64.o diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S b/libavcodec/aarch64/hevcdsp_idct_neon.S new file mode 100644 index 00..c70d6a906d --- /dev/null +++ b/libavcodec/aarch64/hevcdsp_idct_neon.S @@ -0,0 +1,380 @@ +/* + * ARM NEON optimised IDCT functions for HEVC decoding + * Copyright (c) 2014 Seppo Tomperi + * Copyright (c) 2017 Alexandra Hájková + * + * Ported from arm/hevcdsp_idct_neon.S by + * Copyright (c) 2020 Reimar Döffinger + * + * 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/aarch64/asm.S" + +const trans, align=4 +.short 64, 83, 64, 36 +.short 89, 75, 50, 18 +.short 90, 87, 80, 70 +.short 57, 43, 25, 9 +.short 90, 90, 88, 85 +.short 82, 78, 73, 67 +.short 61, 54, 46, 38 +.short 31, 22, 13, 4 +endconst + +.macro sum_sub out, in, c, op, p + .ifc \op, + +smlal\p \out, \in, \c + .else +smlsl\p \out, \in, \c + .endif +.endm + +.macro fixsqrshrn d, dt, n, m + .ifc \dt, .8h +sqrshrn2\d\dt, \n\().4s, \m + .else +sqrshrn \n\().4h, \n\().4s, \m +mov \d\().d[0], \n\().d[0] + .endif +.endm + +// uses and clobbers v28-v31 as temp registers +.macro tr_4x4_8 in0, in1, in2, in3, out0, out1, out2, out3, p1, p2 + sshll\p1 v28.4s, \in0, #6 + movv29.16b, v28.16b + smull\p1 v30.4s, \in1, v0.h[1] + smull\p1 v31.4s, \in1, v0.h[3] + smlal\p2 v28.4s, \in2, v0.h[0] //e0 + smlsl\p2 v29.4s, \in2, v0.h[0] //e1 + smlal\p2 v30.4s, \in3, v0.h[3] //o0 + smlsl\p2 v31.4s, \in3, v0.h[1] //o1 + + add\out0, v28.4s, v30.4s + add\out1, v29.4s, v31.4s + sub\out2, v29.4s, v31.4s + sub\out3, v28.4s, v30.4s +.endm + +.macro transpose8_4x4 r0, r1, r2, r3 +trn1v2.8h, \r0\().8h, \r1\().8h +trn2v3.8h, \r0\().8h, \r1\().8h +trn1v4.8h, \r2\().8h, \r3\().8h +trn2v5.8h, \r2\().8h, \r3\().8h +trn1\r0\().4s, v2.4s, v4.4s +trn2\r2\().4s, v2.4s, v4.4s +trn1\r1\().4s, v3.4s, v5.4s +trn2\r3\().4s, v3.4s, v5.4s +.endm + +.macro transpose_8x8 r0, r1, r2, r3, r4, r5, r6, r7 +transpose8_4x4 \r0, \r1, \r2, \r3 +transpose8_4x4 \r4, \r5, \r6, \r7 +.endm + +.macro tr_8x4 shift, in0,in0t, in1,in1t, in2,in2t, in3,in3t, in4,in4t, in5,in5t, in6,in6t, in7,in7t, p1, p2 +tr_4x4_8\in0\in0t, \in2\in2t, \in4\in4t, \in6\in6t, v24.4s, v25.4s, v26.4s, v27.4s, \p1, \p2 + +smull\p1
[FFmpeg-devel] [PATCH v2 4/4] avcodec/aarch64/hevcdsp: add sao_band NEON
Only works for 8x8.
Signed-off-by: Josh Dekker
---
libavcodec/aarch64/Makefile | 3 +-
libavcodec/aarch64/hevcdsp_init_aarch64.c | 7 ++
libavcodec/aarch64/hevcdsp_sao_neon.S | 87 +++
3 files changed, 96 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch64/hevcdsp_sao_neon.S
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 2ea1d74a38..954461f81d 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -62,4 +62,5 @@ NEON-OBJS-$(CONFIG_VP9_DECODER) +=
aarch64/vp9itxfm_16bpp_neon.o \
aarch64/vp9mc_16bpp_neon.o
\
aarch64/vp9mc_neon.o
NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_idct_neon.o
\
- aarch64/hevcdsp_init_aarch64.o
+ aarch64/hevcdsp_init_aarch64.o
\
+ aarch64/hevcdsp_sao_neon.o
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index fe111bd1ac..c785e46f79 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -53,6 +53,12 @@ void ff_hevc_idct_4x4_dc_10_neon(int16_t *coeffs);
void ff_hevc_idct_8x8_dc_10_neon(int16_t *coeffs);
void ff_hevc_idct_16x16_dc_10_neon(int16_t *coeffs);
void ff_hevc_idct_32x32_dc_10_neon(int16_t *coeffs);
+void ff_hevc_sao_band_filter_8x8_8_neon(uint8_t *_dst, uint8_t *_src,
+ ptrdiff_t stride_dst, ptrdiff_t stride_src,
+ int16_t *sao_offset_val, int sao_left_class,
+ int width, int height);
+
+
av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, const int bit_depth)
{
@@ -69,6 +75,7 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
c->idct_dc[1] = ff_hevc_idct_8x8_dc_8_neon;
c->idct_dc[2] = ff_hevc_idct_16x16_dc_8_neon;
c->idct_dc[3] = ff_hevc_idct_32x32_dc_8_neon;
+c->sao_band_filter[0] = ff_hevc_sao_band_filter_8x8_8_neon;
}
if (bit_depth == 10) {
c->add_residual[0] = ff_hevc_add_residual_4x4_10_neon;
diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S
b/libavcodec/aarch64/hevcdsp_sao_neon.S
new file mode 100644
index 00..f142c1e8c2
--- /dev/null
+++ b/libavcodec/aarch64/hevcdsp_sao_neon.S
@@ -0,0 +1,87 @@
+/* -*-arm64-*-
+ * vim: syntax=arm64asm
+ *
+ * AArch64 NEON optimised SAO functions for HEVC decoding
+ *
+ * Copyright (c) 2020 Josh Dekker
+ *
+ * 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/aarch64/asm.S"
+
+// void sao_band_filter(uint8_t *_dst, uint8_t *_src,
+// ptrdiff_t stride_dst, ptrdiff_t stride_src,
+// int16_t *sao_offset_val, int sao_left_class,
+// int width, int height)
+function ff_hevc_sao_band_filter_8x8_8_neon, export=1
+sub sp, sp, #64
+stp xzr, xzr, [sp]
+stp xzr, xzr, [sp, #16]
+stp xzr, xzr, [sp, #32]
+stp xzr, xzr, [sp, #48]
+mov w8, #4
+0:
+ldrsh x9, [x4, x8, lsl #1] // x9 = sao_offset_val[k+1]
+subs w8, w8, #1
+add w10, w8, w5 // x10 = k + sao_left_class
+and w10, w10, #0x1F
+strh w9, [sp, x10, lsl #1]
+bne 0b
+ld1 {v16.16b-v19.16b}, [sp], #64
+movi v20.8h, #1
+1: // beginning of line
+mov w8, w6
+2:
+// Simple layout for accessing 16bit values
+// with 8bit LUT.
+//
+// 00 01 02 03 04 05 06 07
+// +--->
+// |xDE#xAD|xCA#xFE|xBE#xEF|xFE#xED|
+// +--->
+//i-0 i-1 i-2 i-3
+// dst[x] = av_clip_pixel(src[x] + offset_table[src[x] >> shift]);
+ld1 {v2.8b}, [x1]
+// load src[x]
+uxtl v0.8h, v2.8b
+// >> shift
+ushr v2.8h, v0.8h, #3 // BIT_DEPTH - 3
+// x2 (access lower short)
+shl v1.8h, v2.8h, #1 // low (x2, accessing short)
+// +1 acces
Re: [FFmpeg-devel] [PATCH v4] fate: add api-h264-slice test
On 16/10/2018 12:33, Michael Niedermayer wrote: On Mon, Oct 15, 2018 at 01:32:03PM +0100, jos...@ob-encoder.com wrote: From: Josh de Kock This test ensures that you are able to send N number of slice NALUs in slice threaded mode to be decoded simultaneously --- Tested on Linux 32/64, MinGW + WINE 32/64. fails on qemu arm i suspect you are missing some condition on threads being enabled [h264 @ 0x130e080] Warning: not compiled with thread support, using thread emulation Couldn't activate slice threading: 0 [...] Well it obviously doesn't make sense to test this without threading, so how would I make sure that the test is only run with threading enabled? -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH vFINAL] fate: add api-h264-slice test
On 24/10/2018 19:02, jos...@ob-encoder.com wrote: From: Josh de Kock This test ensures that you are able to send N number of slice NALUs in slice threaded mode to be decoded simultaneously --- tests/api/Makefile | 1 + tests/api/api-h264-slice-test.c | 221 +++ tests/fate/api.mak | 4 + tests/ref/fate/api-h264-slice | 309 4 files changed, 535 insertions(+) create mode 100644 tests/api/api-h264-slice-test.c create mode 100644 tests/ref/fate/api-h264-slice [...] Pushed. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add .mailmap
Hi Steven,
On Mon, Feb 24, 2020, at 2:03 AM, Steven Liu wrote:
> [...]
> How can I get the script :D
>
> Thanks
>
> Steven
I won't be looking to upstream this script (the other one yes), but I will
share it here for you. You'll have to excuse my poor scripting :)
--
Josh
#!/usr/bin/env perl
use warnings;
use strict;
# cpan List::MoreUtils JSON
use Encode qw(decode);
use List::MoreUtils qw(uniq);
sub trim { my $s = shift; $s =~ s/^\s+|\s+$//g; return $s };
my @shortlog = split /\n/, decode('UTF-8', `git shortlog -sne --since="last 36
months"`, Encode::FB_CROAK);
my %assembly = ();
my %developers = ();
foreach my $line (@shortlog) {
my ($count, $name, $email) = $line =~ m/^ *(\d+) *(.*?) <(.*?)>/;
# ignore
$email =~ s/ at /@/;
$name = trim $name;
if (exists($developers{$name})) {
$developers{$name}{commit_count} += $count;
push @{$developers{$name}{email}}, $email;
} else {
$developers{$name} = {
commit_count => $count,
email => [$email],
};
}
}
foreach my $key (keys %developers) {
# many people with different emails, only care about frequent committers
if ($developers{$key}{commit_count} >= 20) {
$developers{$key}{email} = [uniq @{$developers{$key}{email}}];
if (scalar @{$developers{$key}{email}} > 1) {
foreach my $email (@{$developers{$key}{email}}) {
print "$email ";
}
print "\n";
}
}
}
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Add .mailmap
On Mon, Feb 24, 2020, at 11:19 AM, Thilo Borgmann wrote: > Am 23.02.20 um 21:40 schrieb Josh de Kock: > > On Sun, Feb 23, 2020, at 4:07 PM, Thilo Borgmann wrote: > >> [...] > >> > >> How is it automatically generated? > > > > I wrote a small script to parse author names/emails and group > > emails together based on names. In the future, additions should > > be added manually. > > Having that script in tools/ shouldn't hurt, manual updates can get out of > sync. > Also authors might be unaware of or forgetting about .mailmap. > > If you scriptify the group of people for a general assembly like > specified during some earlier meeting, that should be committed, > too. > > .mailmap patch itself LGTM. Pushed. I will send a patch to add the script to compute the general assembly soon. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] REMOTE JOB POST: FFMPEG EXPERT
On Tue, Mar 3, 2020, at 12:55 PM, sumaklos rembert wrote: > We are hiring a remote FFMPEG engineer > > [...] You already posted this a week ago, there is no need to spam the list with the same job multiple times. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] lavfi: add new iteration API
Hi, On Mon, Apr 13, 2020, at 10:32 PM, Josh Allmann wrote: > Hi, > > On Sat, 24 Mar 2018 at 14:40, Josh de Kock wrote: > > > > Signed-off-by: Josh de Kock > > --- > > configure| 29 +- > > doc/APIchanges | 4 + > > doc/writing_filters.txt | 6 +- > > libavfilter/allfilters.c | 823 > > +-- > > libavfilter/avfilter.c | 50 +-- > > libavfilter/avfilter.h | 29 +- > > libavfilter/version.h| 3 + > > 7 files changed, 489 insertions(+), 455 deletions(-) > > > > This is a couple years too late, but wanted to drop a note that this > particular API change was breaking : it made avfilter_register a > no-op. The consequence is that it's much more difficult to maintain > filters out-of-tree; preserving the old behavior without changes to > user code requires a special build of ffmpeg that has the filter > configured/compiled in. The recommended workaround of using > avfilter_graph_alloc_filter requires more effort to wire the filter in > explicitly. It also doesn't allow for conveniences such as using > avfilter_graph_parse, since there doesn't seem to be a way to make > filters accessible via avfilter_get_by_name outside of ffmpeg compile > time. > > If there is another workaround that I'm missing, please let me know, > or if there's some deeper rationale for the decision to disable this > feature. This was actually an intentional change, there was some trouble with how external codecs/filters/etc should be handled. Since this was an unsupported use-case which was quite sensitive to ABI the change was there to explicitly prevent people (ab)using the API like this. It was also to prepare for potentially a new API to implement this in a proper fashion (but as you can see this was never completed). I did begin working on this again a little while back but due to an unfortunate data-loss I will have to start from scratch to continue working on it (yes, yes 'where's your backup?' I know). It's likely to be something I will be working on in the future since I will be doing FFmpeg stuff again soon. There is also the discussion of 'do we want this?' from a more ideological perspective which we will have to re-discuss, maybe something like gstreamer is more suited for the majority of the use-cases (?). -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] cmdutils: stop using deprecated av_codec_next()
On Tue, Apr 14, 2020, at 9:09 AM, Anton Khirnov wrote: > --- > fftools/cmdutils.c | 33 +++-- > 1 file changed, 19 insertions(+), 14 deletions(-) > > [...] LGTM, thanks. I will apply this a bit later after my set (or you can if you want it sooner). -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] lavc: stop using deprecated av_codec_next()
Signed-off-by: Josh de Kock
---
libavcodec/options.c | 5 +++--
libavcodec/tests/utils.c | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/options.c b/libavcodec/options.c
index 35e8ac9313..babab599fc 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -55,15 +55,16 @@ static void *codec_child_next(void *obj, void *prev)
static const AVClass *codec_child_class_next(const AVClass *prev)
{
+void *iter = NULL;
AVCodec *c = NULL;
/* find the codec that corresponds to prev */
-while (prev && (c = av_codec_next(c)))
+while (prev && (c = av_codec_iterate(&iter)))
if (c->priv_class == prev)
break;
/* find next codec with priv options */
-while (c = av_codec_next(c))
+while (c = av_codec_iterate(&iter))
if (c->priv_class)
return c->priv_class;
return NULL;
diff --git a/libavcodec/tests/utils.c b/libavcodec/tests/utils.c
index f6ba7fe66e..5041a4085e 100644
--- a/libavcodec/tests/utils.c
+++ b/libavcodec/tests/utils.c
@@ -19,10 +19,11 @@
#include "libavcodec/avcodec.h"
int main(void){
+void *iter = NULL;
AVCodec *codec = NULL;
int ret = 0;
-while (codec = av_codec_next(codec)) {
+while (codec = av_codec_iterate(&iter)) {
if (av_codec_is_encoder(codec)) {
if (codec->type == AVMEDIA_TYPE_AUDIO) {
if (!codec->sample_fmts) {
--
2.24.1 (Apple Git-126)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] tools: stop using deprecated av_codec_next()
Signed-off-by: Josh de Kock
---
tools/enum_options.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/enum_options.c b/tools/enum_options.c
index 28631d1a6b..548e427b7a 100644
--- a/tools/enum_options.c
+++ b/tools/enum_options.c
@@ -113,13 +113,14 @@ static void show_format_opts(void)
static void show_codec_opts(void)
{
+void *iter = NULL;
AVCodec *c = NULL;
printf("@section Generic codec AVOptions\n");
show_opts(avcodec_get_class());
printf("@section Codec-specific AVOptions\n");
-while ((c = av_codec_next(c))) {
+while ((c = av_codec_iterate(&iter))) {
if (!c->priv_class)
continue;
printf("@subsection %s AVOptions\n", c->priv_class->class_name);
--
2.24.1 (Apple Git-126)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] lavf/utils: stop using deprecated av_codec_next()
Signed-off-by: Josh de Kock
---
libavformat/utils.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index a58e47fabc..4f777ba849 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -222,7 +222,8 @@ static const AVCodec *find_probe_decoder(AVFormatContext
*s, const AVStream *st,
if (codec->capabilities & AV_CODEC_CAP_AVOID_PROBING) {
const AVCodec *probe_codec = NULL;
-while (probe_codec = av_codec_next(probe_codec)) {
+void *iter = NULL;
+while ((probe_codec = av_codec_iterate(&iter))) {
if (probe_codec->id == codec_id &&
av_codec_is_decoder(probe_codec) &&
!(probe_codec->capabilities & (AV_CODEC_CAP_AVOID_PROBING
| AV_CODEC_CAP_EXPERIMENTAL))) {
--
2.24.1 (Apple Git-126)
___
ffmpeg-devel mailing list
ffmpeg-devel@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] configure: fix clang on macOS 10.15
Works around a bug in the newer Xcode 11's clang with -fstack-check
emitting bad code with misaligned call instructions.
---
configure | 5 +
1 file changed, 5 insertions(+)
diff --git a/configure b/configure
index 4d4c429be9..c872a2932d 100755
--- a/configure
+++ b/configure
@@ -5358,6 +5358,11 @@ case $target_os in
fi
version_script='-exported_symbols_list'
VERSION_SCRIPT_POSTPROCESS_CMD='tr " " "\n" | sed -n
/global:/,/local:/p | grep ";" | tr ";" "\n" | sed -E "s/(.+)/_\1/g" | sed -E
"s/(.+[^*])/\1*/"'
+# Workaround for Xcode 11 -fstack-check bug
+if enabled clang; then
+clang_version=$($cc -dumpversion)
+test ${clang_version%%.*} -ge 11 && add_cflags -fno-stack-check
+fi
;;
msys*)
die "Native MSYS builds are discouraged, please use the MINGW
environment."
--
2.24.1 (Apple Git-126)
___
ffmpeg-devel mailing list
ffmpeg-devel@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] configure: fix clang on macOS 10.15
Works around a bug in the newer Xcode 11's clang with -fstack-check
emitting bad code with misaligned call instructions.
This fixes Trac #8073
---
configure | 5 +
1 file changed, 5 insertions(+)
diff --git a/configure b/configure
index 4d4c429be9..2ede4e7163 100755
--- a/configure
+++ b/configure
@@ -5358,6 +5358,11 @@ case $target_os in
fi
version_script='-exported_symbols_list'
VERSION_SCRIPT_POSTPROCESS_CMD='tr " " "\n" | sed -n
/global:/,/local:/p | grep ";" | tr ";" "\n" | sed -E "s/(.+)/_\1/g" | sed -E
"s/(.+[^*])/\1*/"'
+# Workaround for Xcode 11 -fstack-check bug
+if enabled clang; then
+clang_version=$($cc -dumpversion)
+test ${clang_version%%.*} -eq 11 && add_cflags -fno-stack-check
+fi
;;
msys*)
die "Native MSYS builds are discouraged, please use the MINGW
environment."
--
2.24.1 (Apple Git-126)
___
ffmpeg-devel mailing list
ffmpeg-devel@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] configure: fix clang on macOS 10.15
On Wed, Apr 15, 2020, at 3:54 PM, Jan Ekström wrote: > [...] > > Thank you, LGTM from me. > > Jan Pushed. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] cmdutils: stop using deprecated av_codec_next()
On 14/04/2020 13:37, Josh de Kock wrote: On Tue, Apr 14, 2020, at 9:09 AM, Anton Khirnov wrote: --- fftools/cmdutils.c | 33 +++-- 1 file changed, 19 insertions(+), 14 deletions(-) [...] LGTM, thanks. I will apply this a bit later after my set (or you can if you want it sooner). Applied. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] tools: stop using deprecated av_codec_next()
On 14/04/2020 13:38, Josh de Kock wrote:
Signed-off-by: Josh de Kock
---
tools/enum_options.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/enum_options.c b/tools/enum_options.c
index 28631d1a6b..548e427b7a 100644
--- a/tools/enum_options.c
+++ b/tools/enum_options.c
@@ -113,13 +113,14 @@ static void show_format_opts(void)
static void show_codec_opts(void)
{
+void *iter = NULL;
AVCodec *c = NULL;
printf("@section Generic codec AVOptions\n");
show_opts(avcodec_get_class());
printf("@section Codec-specific AVOptions\n");
-while ((c = av_codec_next(c))) {
+while ((c = av_codec_iterate(&iter))) {
if (!c->priv_class)
continue;
printf("@subsection %s AVOptions\n", c->priv_class->class_name);
Set applied.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Add general_assembly_bootstrap.pl
This script aims to extract contributors who are eligible for the
general assembly.
Signed-off-by: Josh de Kock
---
Better late than never, this patch will continue to put in place the
voting systems for FFmpeg discussed at VDD 2019 and FOSDEM 2020.
There is probably a better way to do this, but the aim is just to
'bootstrap' and kickstart the process and commitees.
tools/general_assembly_bootstrap.pl | 48 +
1 file changed, 48 insertions(+)
create mode 100755 tools/general_assembly_bootstrap.pl
diff --git a/tools/general_assembly_bootstrap.pl
b/tools/general_assembly_bootstrap.pl
new file mode 100755
index 00..320fe76992
--- /dev/null
+++ b/tools/general_assembly_bootstrap.pl
@@ -0,0 +1,48 @@
+#!/usr/bin/env perl
+
+use warnings;
+use strict;
+
+use Encode qw(decode);
+use List::MoreUtils qw(uniq);
+# cpan List::MoreUtils
+use JSON::MaybeXS;
+# cpan JSON::MaybeXS
+
+use Data::Dumper;
+
+sub trim { my $s = shift; $s =~ s/^\s+|\s+$//g; return $s };
+
+my @shortlog = split /\n/, decode('UTF-8', `git shortlog -sne --since="last 36
months"`, Encode::FB_CROAK);
+
+my %assembly = ();
+
+foreach my $line (@shortlog) {
+my ($count, $name, $email) = $line =~ m/^ *(\d+) *(.*?) <(.*?)>/;
+
+if ($count < 20) {
+next;
+}
+
+# make sure name is trimmed
+$name = trim $name;
+
+# assume people with 50 commits have at least 20 source commits
+if ($count < 50) {
+my $true = 0;
+my @commits = split /(^|\n)commit [a-z0-9]{40}(\n|$)/, decode('UTF-8',
`git log --name-only --use-mailmap --author="$email" --since="last 36 months"`,
Encode::FB_CROAK);
+foreach my $commit (@commits) {
+if ($commit =~ /\n[\w\/]+\.(c|h|S|asm)/) {
+$true++;
+}
+}
+
+if ($true < 20) {
+next;
+}
+}
+
+$assembly{$name} = $email;
+}
+
+print encode_json(\%assembly);
--
2.24.1 (Apple Git-126)
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Add general_assembly_bootstrap.pl
On 24/04/2020 11:29, Nicolas George wrote: Josh de Kock (12020-04-24): This script aims to extract contributors who are eligible for the general assembly. Signed-off-by: Josh de Kock --- Better late than never, this patch will continue to put in place the voting systems for FFmpeg discussed at VDD 2019 and FOSDEM 2020. There is probably a better way to do this, but the aim is just to 'bootstrap' and kickstart the process and commitees. Since it is only useful once, is there a point in having it in the tree? There is no particular need for it to stay in the tree. Regardless, I wanted to send it to the mailing list to avoid any complications vs if I had just sent the output of the script (so that it can be reviewed and tested by others). My suggestion would be to actually commit it and then remove it later when we have another system properly setup so that it is in git history. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] Complete rewrite of the "fps" video filter section. More accurate.
fps to 24, using abbreviation and rounding method to round to nearest: +Emit a video with a frame rate of 24 frames per second, using an abbreviation, +and rounding method to round to nearest: @example fps=fps=film:round=near @end example + +@item +If an input video is supposed to have a frame rate of 29.97 frames per second +(NTSC standard), but the time base is 3003/9, and the PTS values increment +variably at slightly more and less than that rate, this emits a video with the +same frames, but with a new time base and PTS values that increment at exactly +the NTSC rate. If some frames were dropped by the recorder, but the PTS values +still reflect when the remaining frames were captured, this will also repeat +frames to fill the gaps from the dropped frames. +@example +fps=fps=30/1.001:round=near +@end example + @end itemize @section framepack Just a few nitpicks. Also your usage of `emit' may be confusing to non-native English speakers and I don't think your writing has those people in mind particularly. I would just s/emit/output/ for the most part (check first this works). Like Marton said, it's probably a bit on the verbose side, just have a read over and see if you can say the same thing with less words. I don't think being verbose is necessarily bad either, as you said there's less chance that a user would have to end up looking into code to know how to use it. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] libavcodec/libx264: fix reference frame computation based on level
On 26/04/2020 12:46, Josh Brewster wrote:
I only made sure that the level was positive because its initial
value was -1.
else if (x4->params.i_level_idc >= 0) {
Let me know if I need to reject 0 too. It seemed like premature optimization
as the level simply wouldn't be present in x264_levels.
I'd say yes, level_idc = 0 is possible but invalid by PARSE_X264_OPT(), which
seems
make no sense to calculate refs from x264_levels[] table.
- Linjie
Changed to > 0, thanks.
Hi, is there anything else I need to do to have this merged?
From a precursory look at what x264 and we're doing here your patch is
correct. It doesn't break from a quick test, and looks OK to me. Would
rather someone else has a look at it too but I will again in a couple
days if no one does.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@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] tools: fix const specifier for AVInputFormat
Signed-off-by: Josh de Kock
---
tools/probetest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Small fix for compiler warning caused by my earlier change.
diff --git a/tools/probetest.c b/tools/probetest.c
index cfa309cabd..6f0e002b74 100644
--- a/tools/probetest.c
+++ b/tools/probetest.c
@@ -66,7 +66,7 @@ static void probe(AVProbeData *pd, int type, int p, int size)
static void print_times(void)
{
int i = 0;
-AVInputFormat *fmt = NULL;
+const AVInputFormat *fmt = NULL;
void *fmt_opaque = NULL;
while ((fmt = av_demuxer_iterate(&fmt_opaque))) {
--
2.26.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hls: disable persistent HTTP connections by default w/ schannel
On 26/04/2020 20:43, Jan Ekström wrote:
This TLS implementation has always had issues with the way that
libavformat implemented persistency, yet nobody seemed to be able to
figure out why. It currently can lead to completely stuck playback,
so disable it by default.
Additionally, update the documentation to match the new behavior.
---
doc/demuxers.texi | 3 ++-
libavformat/hls.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 3c15ab9eee..35920af32d 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -337,7 +337,8 @@ Default value is 1000.
@item http_persistent
Use persistent HTTP connections. Applicable only for HTTP streams.
-Enabled by default.
+Enabled by default, except when the Windows schannel TLS implementation
+is utilized.
@item http_multiple
Use multiple HTTP connections for downloading HTTP segments.
diff --git a/libavformat/hls.c b/libavformat/hls.c
index fc45719d1c..f709f0c890 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2343,7 +2343,7 @@ static const AVOption hls_options[] = {
{"m3u8_hold_counters", "The maximum number of times to load m3u8 when it
refreshes without new segments",
OFFSET(m3u8_hold_counters), AV_OPT_TYPE_INT, {.i64 = 1000}, 0,
INT_MAX, FLAGS},
{"http_persistent", "Use persistent HTTP connections",
-OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
+OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = !CONFIG_SCHANNEL},
0, 1, FLAGS },
{"http_multiple", "Use multiple HTTP connections for fetching segments",
OFFSET(http_multiple), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, FLAGS},
{"http_seekable", "Use HTTP partial requests, 0 = disable, 1 = enable, -1 =
auto",
Whilst I'm not against a stop-gap change for this, did you already open
a ticket for this? I think it would be good to track it.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@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] fate: Skip the dnxhd-uhd-hr-sq tests of large tests are disabled
On 23/04/2020 08:14, Martin Storsjö wrote: These tests are also in the same size range as the previously skipped 2k and 4k tests. --- tests/fate/vcodec.mak | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index fc27da5456..ec2a9c339d 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -29,13 +29,14 @@ FATE_VCODEC-$(call ENCDEC, DNXHD, DNXHD) += dnxhd-720p \ dnxhd-720p-rd \ dnxhd-720p-10bit\ dnxhd-720p-hr-lb\ -dnxhd-uhd-hr-sq \ dnxhd-edge1-hr \ dnxhd-edge2-hr \ dnxhd-edge3-hr FATE_VCODEC-$(call ALLYES, DNXHD_ENCODER DNXHD_DECODER LARGE_TESTS) += dnxhd-4k-hr-lb \ - dnxhd-2k-hr-hq + dnxhd-2k-hr-hq \ + dnxhd-uhd-hr-sq + FATE_VCODEC-$(call ENCDEC, VC2 DIRAC, MOV) += vc2-420p vc2-420p10 vc2-420p12 \ vc2-422p vc2-422p10 vc2-422p12 \ This was applied. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] Add general_assembly_bootstrap.pl
On 24/04/2020 11:44, Josh de Kock wrote: On 24/04/2020 11:29, Nicolas George wrote: Josh de Kock (12020-04-24): This script aims to extract contributors who are eligible for the general assembly. Signed-off-by: Josh de Kock --- Better late than never, this patch will continue to put in place the voting systems for FFmpeg discussed at VDD 2019 and FOSDEM 2020. There is probably a better way to do this, but the aim is just to 'bootstrap' and kickstart the process and commitees. Since it is only useful once, is there a point in having it in the tree? There is no particular need for it to stay in the tree. Regardless, I wanted to send it to the mailing list to avoid any complications vs if I had just sent the output of the script (so that it can be reviewed and tested by others). My suggestion would be to actually commit it and then remove it later when we have another system properly setup so that it is in git history. Ping for further comments. This will affect all developers. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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/2] fix for seeking in HLS with TS/FMP4 media
On 25/04/2020 22:42, Carl Eugen Hoyos wrote: Am Fr., 24. Apr. 2020 um 17:21 Uhr schrieb vectronic : I am resubmitting a patch which fixes the following two tickets: Do you not want to commit with your name rather than a handle here? https://trac.ffmpeg.org/ticket/7359 https://trac.ffmpeg.org/ticket/7485 Are you Nick Ryan / did you write the attached patches? The LinkedIn on his website suggests he is. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] tests/api/api-h264-slice-test: remove unused bool header
On 29/04/2020 13:11, Fu, Linjie wrote: From: ffmpeg-devel On Behalf Of Carl Eugen Hoyos Sent: Thursday, April 2, 2020 03:23 To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] tests/api/api-h264-slice-test: remove unused bool header Am Mi., 1. Apr. 2020 um 06:58 Uhr schrieb Linjie Fu : Signed-off-by: Linjie Fu --- tests/api/api-h264-slice-test.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c index dee93b8..b7aa405 100644 --- a/tests/api/api-h264-slice-test.c +++ b/tests/api/api-h264-slice-test.c @@ -24,7 +24,6 @@ #include "config.h" -#include Good idea. Carl Eugen Ping for this, thx. - Linjie Thanks, applied. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] avfilter/vf_v360: adjustment out_pad and in_pad maximum value to 1/10
On 26/04/2020 15:43, Steven Liu wrote:
2020年4月21日 下午10:54，Steven Liu 写道：
Because not every user know about in_pad and out_pad reasonable value range
so maybe try to set 1.0, but setting 1.0 is so hugh to get an fatal error.
Suggested-by: Paul B Mahol
Signed-off-by: Steven Liu
---
doc/filters.texi | 1 +
libavfilter/vf_v360.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 80c33f5edb..740aba0642 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -18956,6 +18956,7 @@ No padding.
@end table
Default value is @b{@samp{0}}.
+Maximum value is @b{@samp{0.1}}.
@item fin_pad
@item fout_pad
diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
index ebc281dfca..e5b75c7226 100644
--- a/libavfilter/vf_v360.c
+++ b/libavfilter/vf_v360.c
@@ -133,8 +133,8 @@ static const AVOption v360_options[] = {
{"out_forder", "output cubemap face order", OFFSET(out_forder), AV_OPT_TYPE_STRING,
{.str="rludfb"},0, NB_DIRECTIONS-1, FLAGS, "out_forder"},
{ "in_frot", "input cubemap face rotation", OFFSET(in_frot), AV_OPT_TYPE_STRING,
{.str="00"},0, NB_DIRECTIONS-1, FLAGS, "in_frot"},
{ "out_frot", "output cubemap face rotation",OFFSET(out_frot), AV_OPT_TYPE_STRING,
{.str="00"},0, NB_DIRECTIONS-1, FLAGS, "out_frot"},
-{"in_pad", "percent input cubemap pads",OFFSET(in_pad), AV_OPT_TYPE_FLOAT,
{.dbl=0.f}, 0.f, 1.f,TFLAGS, "in_pad"},
-{ "out_pad", "percent output cubemap pads", OFFSET(out_pad), AV_OPT_TYPE_FLOAT,
{.dbl=0.f}, 0.f, 1.f,TFLAGS, "out_pad"},
+{"in_pad", "percent input cubemap pads",OFFSET(in_pad), AV_OPT_TYPE_FLOAT,
{.dbl=0.f}, 0.f, 0.1,TFLAGS, "in_pad"},
+{ "out_pad", "percent output cubemap pads", OFFSET(out_pad), AV_OPT_TYPE_FLOAT,
{.dbl=0.f}, 0.f, 0.1,TFLAGS, "out_pad"},
{ "fin_pad", "fixed input cubemap pads", OFFSET(fin_pad), AV_OPT_TYPE_INT,
{.i64=0}, 0, 100,TFLAGS, "fin_pad"},
{ "fout_pad", "fixed output cubemap pads", OFFSET(fout_pad), AV_OPT_TYPE_INT,
{.i64=0}, 0, 100,TFLAGS, "fout_pad"},
{ "yaw", "yaw rotation", OFFSET(yaw), AV_OPT_TYPE_FLOAT,
{.dbl=0.f},-180.f, 180.f,TFLAGS, "yaw"},
--
2.25.0
Ping
Thanks
Steven Liu
Applied.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Add general_assembly_bootstrap.pl
On 29/04/2020 14:00, Nicolas George wrote: Anton Khirnov (12020-04-29): Better late than never, this patch will continue to put in place the voting systems for FFmpeg discussed at VDD 2019 and FOSDEM 2020. There is probably a better way to do this, but the aim is just to 'bootstrap' and kickstart the process and commitees. ^ Since it is only useful once, is there a point in having it in the tree? Why would it only be useful once? I thought we'd use the same procedure for every vote. We did not yet agree on the procedure for all votes, AFAIK, we only agreed on the procedure for the first vote. Having a procedure already implemented and in the official Git source tree would be pretty disloyal. To add to this: We could decide to use this every time, but that would have to be done by a vote. But we can't vote on that with nothing, so hence we have this to begin somewhere. The community and technical committees will be decided by the bootstrapped general assembly, along with formalising the voting procedures and processes. Going forward from there it should be a pretty simple case of just continuing the methods which were chosen. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] tools: fix const specifier for AVInputFormat
On 29/04/2020 20:58, Michael Niedermayer wrote: On Wed, Apr 29, 2020 at 12:00:23PM +0100, Josh de Kock wrote: Signed-off-by: Josh de Kock --- tools/probetest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Small fix for compiler warning caused by my earlier change. LGTM Thanks, applied. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] [WIP PATCH 2/2] checkasm: add hscale test
This tests the hscale 8bpp to 14bpp functions with different filter
sizes.
Signed-off-by: Josh de Kock
---
Not quite ready to be committed but I wanted to submit it anyway so I
could get some comments. I still need to do the rest of the scale sizes
(such as 8bpp to 19bpp) and make the benchmarks work.
tests/checkasm/Makefile| 2 +-
tests/checkasm/checkasm.c | 1 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/sw_hscale.c | 108 +
4 files changed, 111 insertions(+), 1 deletion(-)
create mode 100644 tests/checkasm/sw_hscale.c
diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index de850c016e..c04c2a304e 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -45,7 +45,7 @@ AVFILTEROBJS-$(CONFIG_NLMEANS_FILTER)+= vf_nlmeans.o
CHECKASMOBJS-$(CONFIG_AVFILTER) += $(AVFILTEROBJS-yes)
# swscale tests
-SWSCALEOBJS += sw_rgb.o
+SWSCALEOBJS += sw_hscale.o sw_rgb.o
CHECKASMOBJS-$(CONFIG_SWSCALE) += $(SWSCALEOBJS)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index d67147ae6f..8bf32d5b65 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -182,6 +182,7 @@ static const struct {
#endif
#endif
#if CONFIG_SWSCALE
+{ "sw_scale", checkasm_check_sw_scale },
{ "sw_rgb", checkasm_check_sw_rgb },
#endif
#if CONFIG_AVUTIL
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index 0a7f9f25c4..98d59aedf7 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -68,6 +68,7 @@ void checkasm_check_opusdsp(void);
void checkasm_check_pixblockdsp(void);
void checkasm_check_sbrdsp(void);
void checkasm_check_synth_filter(void);
+void checkasm_check_sw_scale(void);
void checkasm_check_sw_rgb(void);
void checkasm_check_utvideodsp(void);
void checkasm_check_v210dec(void);
diff --git a/tests/checkasm/sw_hscale.c b/tests/checkasm/sw_hscale.c
new file mode 100644
index 00..f54ed72d81
--- /dev/null
+++ b/tests/checkasm/sw_hscale.c
@@ -0,0 +1,108 @@
+/*
+ *
+ * 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/common.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mem.h"
+
+#include "libswscale/swscale.h"
+#include "libswscale/swscale_internal.h"
+
+#include "checkasm.h"
+
+#define randomize_buffers(buf, size) \
+do { \
+int j;\
+for (j = 0; j < size; j+=4) \
+AV_WN32(buf + j, rnd()); \
+} while (0)
+
+#define MAX_WIDTH 128
+#define MAX_FILTER_WIDTH 40
+
+#define INIT_FILTER(bsrc, bdst, width) \
+ctx->srcBpc = bsrc; \
+ctx->dstBpc = bdst; \
+ctx->hLumFilterSize = ctx->hChrFilterSize = width; \
+for (i = 0; i < MAX_WIDTH; i++) { \
+filterPos[i] = i; \
+for (j = 0; j < width; j++) { \
+filter[i * width + j] = (1 << 14) / width; \
+} \
+} \
+\
+for (i = 0; i < MAX_FILTER_WIDTH; i++) { \
+filter[MAX_WIDTH * width + i] = (1 << 14) / width; \
+} \
+ff_getSwsFunc(ctx);
+
+#define CHECK_FILTER(width) \
+INIT_FILTER(8, 14, width) \
+if (check_func(ctx->hcScale, "hscale_8_to_15_width" #width)) { \
+memset(dst0, 0, MAX_WIDTH * sizeof(dst0[0])); \
+memset(dst1, 0, MAX_WIDTH * sizeof(dst1[0])); \
+\
+call_ref(NULL, dst0, MAX_WIDTH, src, filter, filterPos, width); \
+call_new(NULL, dst1, MAX_WIDTH, src, filter, filterPos, width); \
+if (memcmp(dst0, dst1, MAX_WIDTH)) \
+fail(); \
+/*bench_new();*/ \
+}
+
+static void check_hscale(void)
+{
+int i, j;
+struct SwsContext *ctx;
+
+// padded
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_WIDTH + MAX_FILTER_WIDTH - 1]);
+LOCAL_ALIGNED_32(uint16_t, dst0, [MAX_WIDTH]);
+LOCAL_ALIGNED_32(uint16_t, dst1, [MAX_WIDTH]);
+
+// padded
+LOCAL_ALIGNED_32(int16_t, filter, [MAX_WIDTH * MAX_FILTER_WIDTH +
MAX_FILTER_WIDTH]);
+LOCAL_ALIGNED_32(int32_t, filterPos, [MAX_WIDTH]);
+
+declare_func(void, void*c, int
[FFmpeg-devel] [PATCH 1/2] swscale: fix NEON hscale init
The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used.
Signed-off-by: Josh de Kock
---
libswscale/aarch64/swscale.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libswscale/aarch64/swscale.c b/libswscale/aarch64/swscale.c
index 54a3beabe8..eecbea88ca 100644
--- a/libswscale/aarch64/swscale.c
+++ b/libswscale/aarch64/swscale.c
@@ -34,7 +34,10 @@ av_cold void ff_sws_init_swscale_aarch64(SwsContext *c)
int cpu_flags = av_get_cpu_flags();
if (have_neon(cpu_flags)) {
-if (c->srcBpc == 8 && c->dstBpc <= 14) {
+if (c->srcBpc == 8 && c->dstBpc <= 14 &&
+(c->hLumFilterSize % 8) == 0 &&
+(c->hChrFilterSize % 8) == 0)
+{
c->hyScale = c->hcScale = ff_hscale_8_to_15_neon;
}
if (c->dstBpc == 8) {
--
2.20.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] libavcodec/libx264: fix reference frame computation based on level
On 05/05/2020 17:02, Fu, Linjie wrote: From: ffmpeg-devel On Behalf Of Josh Brewster Sent: Tuesday, May 5, 2020 23:52 To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference frame computation based on level From: ffmpeg-devel ffmpeg-devel-boun...@ffmpeg.org On Behalf Of Josh de Kock Sent: Tuesday, April 28, 2020 23:47 To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference frame computation based on level On 26/04/2020 12:46, Josh Brewster wrote: Hi, is there anything else I need to do to have this merged? From a precursory look at what x264 and we're doing here your patch is correct. It doesn't break from a quick test, and looks OK to me. Would rather someone else has a look at it too but I will again in a couple days if no one does. Should be ok IMHO, thx. - Linjie Thanks for the feedback, I'll wait for it to be merged then. FYI, already merged several days ago with the help of Josh in: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/79f001675a2bae16e243f30a3e7de9da6aeb3c2d Ah, it seems my 'Patch applied' email never came though. Yes, I merged this. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@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] checkasm: add hscale test
This tests the hscale 8bpp to 14bpp functions with different filter
sizes.
Signed-off-by: Josh de Kock
---
Should address all previous comments.
tests/checkasm/Makefile | 2 +-
tests/checkasm/checkasm.c | 1 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/sw_scale.c | 114 ++
4 files changed, 117 insertions(+), 1 deletion(-)
create mode 100644 tests/checkasm/sw_scale.c
diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index de850c016e..9e9569777b 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -45,7 +45,7 @@ AVFILTEROBJS-$(CONFIG_NLMEANS_FILTER)+= vf_nlmeans.o
CHECKASMOBJS-$(CONFIG_AVFILTER) += $(AVFILTEROBJS-yes)
# swscale tests
-SWSCALEOBJS += sw_rgb.o
+SWSCALEOBJS += sw_rgb.o sw_scale.o
CHECKASMOBJS-$(CONFIG_SWSCALE) += $(SWSCALEOBJS)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index d67147ae6f..91066514f6 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -183,6 +183,7 @@ static const struct {
#endif
#if CONFIG_SWSCALE
{ "sw_rgb", checkasm_check_sw_rgb },
+{ "sw_scale", checkasm_check_sw_scale },
#endif
#if CONFIG_AVUTIL
{ "fixed_dsp", checkasm_check_fixed_dsp },
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index 0a7f9f25c4..77e573774f 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -69,6 +69,7 @@ void checkasm_check_pixblockdsp(void);
void checkasm_check_sbrdsp(void);
void checkasm_check_synth_filter(void);
void checkasm_check_sw_rgb(void);
+void checkasm_check_sw_scale(void);
void checkasm_check_utvideodsp(void);
void checkasm_check_v210dec(void);
void checkasm_check_v210enc(void);
diff --git a/tests/checkasm/sw_scale.c b/tests/checkasm/sw_scale.c
new file mode 100644
index 00..52a15247d5
--- /dev/null
+++ b/tests/checkasm/sw_scale.c
@@ -0,0 +1,114 @@
+/*
+ *
+ * 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/common.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mem.h"
+
+#include "libswscale/swscale.h"
+#include "libswscale/swscale_internal.h"
+
+#include "checkasm.h"
+
+#define randomize_buffers(buf, size) \
+do { \
+int j;\
+for (j = 0; j < size; j+=4) \
+AV_WN32(buf + j, rnd()); \
+} while (0)
+
+#define MAX_WIDTH 128
+
+#define FILTER_SIZES 5
+int filter_sizes[FILTER_SIZES] = { 4, 8, 16, 32, 40 };
+#define MAX_FILTER_WIDTH 40
+
+#define HSCALE_PAIRS 2
+int hscale_pairs[HSCALE_PAIRS][2] = {
+{ 8, 14 },
+{ 8, 18 },
+};
+
+static void check_hscale(void)
+{
+int i, j, fsi, hpi, width;
+struct SwsContext *ctx;
+
+// padded
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_WIDTH + MAX_FILTER_WIDTH - 1]);
+LOCAL_ALIGNED_32(uint32_t, dst0, [MAX_WIDTH]);
+LOCAL_ALIGNED_32(uint32_t, dst1, [MAX_WIDTH]);
+
+// padded
+LOCAL_ALIGNED_32(int16_t, filter, [MAX_WIDTH * MAX_FILTER_WIDTH +
MAX_FILTER_WIDTH]);
+LOCAL_ALIGNED_32(int32_t, filterPos, [MAX_WIDTH]);
+
+// The dst parameter here is either int16_t or int32_t but we use void* to
+// just cover both cases.
+declare_func(void, void *c, void *dst, int dstW,
+ const uint8_t *src, const int16_t *filter,
+ const int32_t *filterPos, int filterSize);
+
+ctx = sws_alloc_context();
+if (sws_init_context(ctx, NULL, NULL) < 0)
+fail();
+
+randomize_buffers(src, MAX_WIDTH + MAX_FILTER_WIDTH - 1);
+
+for (hpi = 0; hpi < HSCALE_PAIRS; hpi++) {
+for (fsi = 0; fsi < FILTER_SIZES; fsi++) {
+width = filter_sizes[fsi];
+
+ctx->srcBpc = hscale_pairs[hpi][0];
+ctx->dstBpc = hscale_pairs[hpi][1];
+ctx->hLumFilterSize = ctx->hChrFilterSize = width;
+for (i = 0; i < MAX_WIDTH; i++) {
+filterPos[i] = i;
+for (j = 0; j < width; j++) {
+filter[i * width + j] = (1 << 14) / width;
+}
+
