Re: [FFmpeg-devel] [PATCH] RELEASE_NOTES: Based on the version from 5.0
On Sat, Jul 16, 2022 at 11:02:48PM +0200, Martijn van Beurden wrote: > Op za 16 jul. 2022 om 22:36 schreef Michael Niedermayer < > mich...@niedermayer.cc>: > > > > > something like this: ? > > > > + The FFmpeg Project proudly presents FFmpeg 5.1 "Riemann" LTS, about 6 > > + months after the release of FFmpeg 5.0, our first Long Term Support > > + release. > > > > > Yes, that probably helps avoid any confusion on whether LTS here might mean > something different. > > > > > > About guidance, i really dont know what to write > > > > > I don't know what the reason was to call this release LTS. I know most > people using ffmpeg are using the latest git anyway, but if I were to value > stable releases and seeing that this release is LTS, I would wonder: how > long is long term in this context (2 year, 5 years) and does it just mean > long term security updates or can I expect backports as well? Without any > detail, I think the designation LTS raises more questions than it answers. > I think it is important to manage expectations here, people might expect > certain aspects of this release to be kept up-to-date which were never > intended to be part of the 'support'. > > I know this is all quite vague, but repeating myself: I don't know the > rationale for this release being designated LTS, so I can't come up with > something either. > > I see there are 9 releases that got updates in the last 2 months. If the > LTS designation is meant to, going forward, lower the number of releases > that get support for such a long time, this is something that can be stated > as well. Something like: "to keep the amount of work to maintain releases > reasonable, going forward only LTS releases can be expected to get security > updates for more than 1 year." > > Just some thoughts. ATM we have to maintain many releases because each is used by some distro the LTS designation might cause distros to coalescence onto fewer releases This may also make life easier to distro maintainers I dont think ita a big effect for anyone though. Also people asked for calling some releases "LTS". I mean the impact of maintaining lets say 4.2 if you maintain 4.1 and 4.3 already is small. a 4.2 rarely really needs something that isnt also needed by either 4.1 or 4.3 I cant say what others are doing or planing to do. I dont plan to do more or different things with releases actually used by distros. It just seems we will have fewer non LTS releases which will require long term support from us thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] lavfi/cropdetect: Add new mode to detect crop-area based on motion vectors and edges
Am 11.07.22 um 10:54 schrieb Thilo Borgmann:
$subject
v3.
-ThiloFrom 763c169d82395ec3fd59fa66ebc78c676f0f186d Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Sat, 16 Jul 2022 23:01:14 +0200
Subject: [PATCH v3 2/2] lavfi/cropdetect: Add new mode to detect crop-area
based on motion vectors and edges
This filter allows crop detection even if the video is embedded in non-black
areas.
---
doc/filters.texi | 42 +++-
libavfilter/vf_cropdetect.c| 211 -
tests/fate/filter-video.mak| 8 +-
tests/ref/fate/filter-metadata-cropdetect1 | 9 +
tests/ref/fate/filter-metadata-cropdetect2 | 9 +
5 files changed, 276 insertions(+), 3 deletions(-)
create mode 100644 tests/ref/fate/filter-metadata-cropdetect1
create mode 100644 tests/ref/fate/filter-metadata-cropdetect2
diff --git a/doc/filters.texi b/doc/filters.texi
index d65e83d4d0..bd2d2429d7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10075,7 +10075,7 @@ Auto-detect the crop size.
It calculates the necessary cropping parameters and prints the
recommended parameters via the logging system. The detected dimensions
-correspond to the non-black area of the input video.
+correspond to the non-black or video area of the input video according to
@var{mode}.
It accepts the following parameters:
@@ -10106,8 +10106,48 @@ detect the current optimal crop area. Default value is
0.
This can be useful when channel logos distort the video area. 0
indicates 'never reset', and returns the largest area encountered during
playback.
+
+@item mv_threshold
+Set motion in pixel units as threshold for motion detection. It defaults to 8.
+
+@item low
+@item high
+Set low and high threshold values used by the Canny thresholding
+algorithm.
+
+The high threshold selects the "strong" edge pixels, which are then
+connected through 8-connectivity with the "weak" edge pixels selected
+by the low threshold.
+
+@var{low} and @var{high} threshold values must be chosen in the range
+[0,1], and @var{low} should be lesser or equal to @var{high}.
+
+Default value for @var{low} is @code{5/255}, and default value for @var{high}
+is @code{15/255}.
@end table
+@subsection Examples
+
+@itemize
+@item
+Find video area surrounded by black borders:
+@example
+ffmpeg -i file.mp4 -vf cropdetect,metadata=mode=print -f null -
+@end example
+
+@item
+Find an embedded video area, generate motion vectors beforehand:
+@example
+ffmpeg -i file.mp4 -vf mestimate,cropdetect=mode=mvedges,metadata=mode=print
-f null -
+@end example
+
+@item
+Find an embedded video area, use motion vectors from decoder:
+@example
+ffmpeg -flags2 +export_mvs -i file.mp4 -vf
cropdetect=mode=mvedges,metadata=mode=print -f null -
+@end example
+@end itemize
+
@anchor{cue}
@section cue
diff --git a/libavfilter/vf_cropdetect.c b/libavfilter/vf_cropdetect.c
index b887b9ecb1..5e9e99ab17 100644
--- a/libavfilter/vf_cropdetect.c
+++ b/libavfilter/vf_cropdetect.c
@@ -26,11 +26,14 @@
#include "libavutil/imgutils.h"
#include "libavutil/internal.h"
#include "libavutil/opt.h"
+#include "libavutil/motion_vector.h"
+#include "libavutil/qsort.h"
#include "avfilter.h"
#include "formats.h"
#include "internal.h"
#include "video.h"
+#include "edge_common.h"
typedef struct CropDetectContext {
const AVClass *class;
@@ -42,6 +45,16 @@ typedef struct CropDetectContext {
int frame_nb;
int max_pixsteps[4];
int max_outliers;
+int mode;
+int window_size;
+int mv_threshold;
+float low, high;
+uint8_t low_u8, high_u8;
+uint8_t *filterbuf;
+uint8_t *tmpbuf;
+uint16_t *gradients;
+char *directions;
+int *bboxes[4];
} CropDetectContext;
static const enum AVPixelFormat pix_fmts[] = {
@@ -61,6 +74,17 @@ static const enum AVPixelFormat pix_fmts[] = {
AV_PIX_FMT_NONE
};
+enum CropMode {
+MODE_BLACK,
+MODE_MV_EDGES,
+MODE_NB
+};
+
+static int comp(const int *a,const int *b)
+{
+return FFDIFFSIGN(*a, *b);
+}
+
static int checkline(void *ctx, const unsigned char *src, int stride, int len,
int bpp)
{
int total = 0;
@@ -116,11 +140,43 @@ static int checkline(void *ctx, const unsigned char *src,
int stride, int len, i
return total;
}
+static int checkline_edge(void *ctx, const unsigned char *src, int stride, int
len, int bpp)
+{
+const uint16_t *src16 = (const uint16_t *)src;
+
+switch (bpp) {
+case 1:
+while (--len >= 0) {
+if(src[0]) return 0;
+src += stride;
+}
+break;
+case 2:
+stride >>= 1;
+while (--len >= 0) {
+if(src16[0]) return 0;
+src16 += stride;
+}
+break;
+case 3:
+case 4:
+while (--len >= 0) {
+if(src[0] || src[1] || src[2]) return 0;
+src += stride;
+}
+break;
+}
+
+return 1;
+}
+
static av_cold int init(AVFilterContext *ctx)
{
Re: [FFmpeg-devel] [PATCH v2 1/2] lavfi/edge_common: Add 16bit versions of gaussian_blur and sobel
Hi,
1/2 adds 16 bit versions of ff_gaussian_blur and ff_sobel.
2/2 adds new mode to cropdetect.
v3 does it the template way for 1/2 as requested on IRC.
-ThiloFrom 5453c0e27cd2c54931b012d663178a7c0b5a9f5f Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Sat, 16 Jul 2022 22:59:57 +0200
Subject: [PATCH v3 1/2] lavfi/edge_common: Templatify ff_gaussian_blur and
ff_sobel
---
libavfilter/edge_common.c | 74 ++
libavfilter/edge_common.h | 22 ---
libavfilter/edge_template.c | 120
libavfilter/vf_blurdetect.c | 8 +--
libavfilter/vf_edgedetect.c | 14 ++---
5 files changed, 152 insertions(+), 86 deletions(-)
create mode 100644 libavfilter/edge_template.c
diff --git a/libavfilter/edge_common.c b/libavfilter/edge_common.c
index d72e8521cd..ebd47d7c53 100644
--- a/libavfilter/edge_common.c
+++ b/libavfilter/edge_common.c
@@ -46,33 +46,13 @@ static int get_rounded_direction(int gx, int gy)
return DIRECTION_VERTICAL;
}
-// Simple sobel operator to get rounded gradients
-void ff_sobel(int w, int h,
-uint16_t *dst, int dst_linesize,
-int8_t *dir, int dir_linesize,
-const uint8_t *src, int src_linesize)
-{
-int i, j;
-
-for (j = 1; j < h - 1; j++) {
-dst += dst_linesize;
-dir += dir_linesize;
-src += src_linesize;
-for (i = 1; i < w - 1; i++) {
-const int gx =
--1*src[-src_linesize + i-1] + 1*src[-src_linesize + i+1]
--2*src[i-1] + 2*src[i+1]
--1*src[ src_linesize + i-1] + 1*src[ src_linesize + i+1];
-const int gy =
--1*src[-src_linesize + i-1] + 1*src[ src_linesize + i-1]
--2*src[-src_linesize + i ] + 2*src[ src_linesize + i ]
--1*src[-src_linesize + i+1] + 1*src[ src_linesize + i+1];
+#undef DEPTH
+#define DEPTH 8
+#include "edge_template.c"
-dst[i] = FFABS(gx) + FFABS(gy);
-dir[i] = get_rounded_direction(gx, gy);
-}
-}
-}
+#undef DEPTH
+#define DEPTH 16
+#include "edge_template.c"
// Filters rounded gradients to drop all non-maxima
// Expects gradients generated by ff_sobel()
@@ -137,45 +117,3 @@ void ff_double_threshold(int low, int high, int w, int h,
src += src_linesize;
}
}
-
-// Applies gaussian blur, using 5x5 kernels, sigma = 1.4
-void ff_gaussian_blur(int w, int h,
- uint8_t *dst, int dst_linesize,
- const uint8_t *src, int src_linesize)
-{
-int i, j;
-
-memcpy(dst, src, w); dst += dst_linesize; src += src_linesize;
-memcpy(dst, src, w); dst += dst_linesize; src += src_linesize;
-for (j = 2; j < h - 2; j++) {
-dst[0] = src[0];
-dst[1] = src[1];
-for (i = 2; i < w - 2; i++) {
-/* Gaussian mask of size 5x5 with sigma = 1.4 */
-dst[i] = ((src[-2*src_linesize + i-2] + src[2*src_linesize + i-2])
* 2
-+ (src[-2*src_linesize + i-1] + src[2*src_linesize + i-1])
* 4
-+ (src[-2*src_linesize + i ] + src[2*src_linesize + i ])
* 5
-+ (src[-2*src_linesize + i+1] + src[2*src_linesize + i+1])
* 4
-+ (src[-2*src_linesize + i+2] + src[2*src_linesize + i+2])
* 2
-
-+ (src[ -src_linesize + i-2] + src[ src_linesize + i-2])
* 4
-+ (src[ -src_linesize + i-1] + src[ src_linesize + i-1])
* 9
-+ (src[ -src_linesize + i ] + src[ src_linesize + i ])
* 12
-+ (src[ -src_linesize + i+1] + src[ src_linesize + i+1])
* 9
-+ (src[ -src_linesize + i+2] + src[ src_linesize + i+2])
* 4
-
-+ src[i-2] * 5
-+ src[i-1] * 12
-+ src[i ] * 15
-+ src[i+1] * 12
-+ src[i+2] * 5) / 159;
-}
-dst[i] = src[i];
-dst[i + 1] = src[i + 1];
-
-dst += dst_linesize;
-src += src_linesize;
-}
-memcpy(dst, src, w); dst += dst_linesize; src += src_linesize;
-memcpy(dst, src, w);
-}
diff --git a/libavfilter/edge_common.h b/libavfilter/edge_common.h
index 87c143f2b8..cff4febd70 100644
--- a/libavfilter/edge_common.h
+++ b/libavfilter/edge_common.h
@@ -48,10 +48,14 @@ enum AVRoundedDirection {
* @param src data pointers to source image
* @param src_linesize linesizes for the source image
*/
-void ff_sobel(int w, int h,
- uint16_t *dst, int dst_linesize,
- int8_t *dir, int dir_linesize,
- const uint8_t *src, int src_linesize);
+#define PROTO_SOBEL(depth) \
+void ff_sobel_##depth(int w, int h, \
+ uint16_t *dst, int dst_linesize, \
+ int8_t *dir, int dir_
Re: [FFmpeg-devel] [PATCH] RELEASE_NOTES: Based on the version from 5.0
Op za 16 jul. 2022 om 22:36 schreef Michael Niedermayer < mich...@niedermayer.cc>: > > something like this: ? > > + The FFmpeg Project proudly presents FFmpeg 5.1 "Riemann" LTS, about 6 > + months after the release of FFmpeg 5.0, our first Long Term Support > + release. > > Yes, that probably helps avoid any confusion on whether LTS here might mean something different. > > About guidance, i really dont know what to write > > I don't know what the reason was to call this release LTS. I know most people using ffmpeg are using the latest git anyway, but if I were to value stable releases and seeing that this release is LTS, I would wonder: how long is long term in this context (2 year, 5 years) and does it just mean long term security updates or can I expect backports as well? Without any detail, I think the designation LTS raises more questions than it answers. I think it is important to manage expectations here, people might expect certain aspects of this release to be kept up-to-date which were never intended to be part of the 'support'. I know this is all quite vague, but repeating myself: I don't know the rationale for this release being designated LTS, so I can't come up with something either. I see there are 9 releases that got updates in the last 2 months. If the LTS designation is meant to, going forward, lower the number of releases that get support for such a long time, this is something that can be stated as well. Something like: "to keep the amount of work to maintain releases reasonable, going forward only LTS releases can be expected to get security updates for more than 1 year." Just some thoughts. ___ ffmpeg-devel mailing list ffmpeg-devel@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] RELEASE_NOTES: Based on the version from 5.0
On Sat, Jul 16, 2022 at 10:05:15PM +0200, Martijn van Beurden wrote: > Op za 16 jul. 2022 om 17:09 schreef Michael Niedermayer < > mich...@niedermayer.cc>: > > > +┌┐ > > +│ RELEASE NOTES for FFmpeg 5.1 "Riemann" LTS │ > > +└┘ > > + > > > > Should there perhaps be an explanation on what the LTS designation means in > practice? Maybe at least mention that it is an abbreviation for long term > support? I see that 2.8 still gets updates while it was first released > almost 7 years ago, without any explanation people might expect LTS to mean > (much) longer than that. Even if no definitive dates can be supplied, it > might be possible to provide some guidance on this. something like this: ? + The FFmpeg Project proudly presents FFmpeg 5.1 "Riemann" LTS, about 6 + months after the release of FFmpeg 5.0, our first Long Term Support + release. About guidance, i really dont know what to write thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] RELEASE_NOTES: Based on the version from 5.0
Op za 16 jul. 2022 om 17:09 schreef Michael Niedermayer < mich...@niedermayer.cc>: > +┌┐ > +│ RELEASE NOTES for FFmpeg 5.1 "Riemann" LTS │ > +└┘ > + > Should there perhaps be an explanation on what the LTS designation means in practice? Maybe at least mention that it is an abbreviation for long term support? I see that 2.8 still gets updates while it was first released almost 7 years ago, without any explanation people might expect LTS to mean (much) longer than that. Even if no definitive dates can be supplied, it might be possible to provide some guidance on this. ___ ffmpeg-devel mailing list ffmpeg-devel@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 5/5] aarch64: me_cmp: Don't do uaddlv once per iteration
On Sat, 16 Jul 2022, Michael Niedermayer wrote:
On Sat, Jul 16, 2022 at 03:30:23PM +0300, Martin Storsjö wrote:
On Sat, 16 Jul 2022, Michael Niedermayer wrote:
On Sat, Jul 16, 2022 at 12:25:37AM +0300, Martin Storsjö wrote:
On Fri, 15 Jul 2022, Michael Niedermayer wrote:
On Fri, Jul 15, 2022 at 10:56:03PM +0300, Martin Storsjö wrote:
On Fri, 15 Jul 2022, Swinney, Jonathan wrote:
If the max height is just 16, then this should be fine. I assumed that h
could have a much higher value (>1024), but if that is not the case,
then this is a useful optimization.
At least according to the me_cmp.h header, which says:
/* Motion estimation:
* h is limited to { width / 2, width, 2 * width },
* but never larger than 16 and never smaller than 2.
* Although currently h < 4 is not used as functions with
* width < 8 are neither used nor implemented. */
These rules where written with support for encoding of all
standard formats in mind at the time that was written.
today it may make sense to extend these rules to cover the
things which where created since then
Right, but if that suddenly changes, such a change also must expect that it
might need updates to all assembly implementations that implement that
interface currently. Right now, both the defacto case (any callers in the
codebase) and the explicit documentation says that it can't be called with
parameters outside of that range.
What i meant was that newly added functions should be more flexible than
these old rules. That is 2 sets of rules
1. What a caller ATM can do and expect to work (thats whats written there)
2. What an implementor of new functions should make sure is supported
With 2., do you mean if adding a new function into the same struct, or if
implementing the existing pix_abs[0][..] functions?
i would say both
If you mean new implementations of the existing function interface, you say
they "should be more flexible". How flexible must they be? Is it ok to
assume h<=256 for the w=16 functions?
i think thats fine
Ok, I'll go ahead and push this then.
Gradually increasing the requirements for existing function interfaces like
you suggest is really problematic.
why ?
iam really just saying
"when you add new code, dont base it on old limitations"
For this case, I just quoted what the header said, which seemed
authoritative to me - but it's fine for me with a wider spec too, up to
h=256. But saying arbitrarily "any height" really inhibits what you can do
in asm.
Also if I shouldn't reference that limitation in the header, please
update/reword it, as it's actively misleading for anyone working on
this right now.
And in general, we can design for an intended use case and calculate
whether it should work or not - but as long as it's not tested, those
cases will often have hidden bugs - see e.g. patch 1/5 in this series.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avformat/flvdec: make key frame timestamps more accurate
On Thu, Jul 14, 2022 at 12:48:14PM +0800, Zhao Zhili wrote:
> From: Zhao Zhili
>
> There is an implicit cast from double to int64_t in time unit of
> second.
> ---
> libavformat/flvdec.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index c5d3c63bd0..a78d720295 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -146,9 +146,9 @@ static void add_keyframes_index(AVFormatContext *s)
> if (ffstream(stream)->nb_index_entries == 0) {
> for (i = 0; i < flv->keyframe_count; i++) {
> av_log(s, AV_LOG_TRACE, "keyframe filepositions = %"PRId64"
> times = %"PRId64"\n",
> - flv->keyframe_filepositions[i], flv->keyframe_times[i] *
> 1000);
> + flv->keyframe_filepositions[i], flv->keyframe_times[i]);
> av_add_index_entry(stream, flv->keyframe_filepositions[i],
> -flv->keyframe_times[i] * 1000, 0, 0, AVINDEX_KEYFRAME);
> +flv->keyframe_times[i], 0, 0, AVINDEX_KEYFRAME);
> }
> } else
> av_log(s, AV_LOG_WARNING, "Skipping duplicate index\n");
> @@ -461,9 +461,13 @@ static int parse_keyframes_index(AVFormatContext *s,
> AVIOContext *ioc, int64_t m
> d = av_int2double(avio_rb64(ioc));
> if (isnan(d) || d < INT64_MIN || d > INT64_MAX)
> goto invalid;
> -if (current_array == × && (d <= INT64_MIN / 1000 || d >=
> INT64_MAX / 1000))
> -goto invalid;
> -current_array[0][i] = d;
> +if (current_array == ×) {
> +if (d <= INT64_MIN / 1000 || d >= INT64_MAX / 1000)
> +goto invalid;
> +current_array[0][i] = d * 1000;
> +} else {
> +current_array[0][i] = d;
> +}
> }
> if (times && filepositions) {
> // All done, exiting at a position allowing amf_parse_object
> @@ -476,7 +480,7 @@ static int parse_keyframes_index(AVFormatContext *s,
> AVIOContext *ioc, int64_t m
> if (timeslen == fileposlen && fileposlen>1 && max_pos <=
> filepositions[0]) {
> for (i = 0; i < FFMIN(2,fileposlen); i++) {
> flv->validate_index[i].pos = filepositions[i];
> -flv->validate_index[i].dts = times[i] * 1000;
> +flv->validate_index[i].dts = times[i];
> flv->validate_count= i + 1;
> }
> flv->keyframe_times = times;
can be simplified like this:
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index a78d720295..3155b2a517 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -428,6 +428,7 @@ static int parse_keyframes_index(AVFormatContext *s,
AVIOContext *ioc, int64_t m
amf_get_string(ioc, str_val, sizeof(str_val)) > 0) {
int64_t **current_array;
unsigned int arraylen;
+int factor;
// Expect array object in context
if (avio_r8(ioc) != AMF_DATA_TYPE_ARRAY)
@@ -440,10 +441,12 @@ static int parse_keyframes_index(AVFormatContext *s,
AVIOContext *ioc, int64_t m
if (!strcmp(KEYFRAMES_TIMESTAMP_TAG , str_val) && !times) {
current_array = ×
timeslen = arraylen;
+factor= 1000;
} else if (!strcmp(KEYFRAMES_BYTEOFFSET_TAG, str_val) &&
!filepositions) {
current_array = &filepositions;
fileposlen= arraylen;
+factor= 1;
} else
// unexpected metatag inside keyframes, will not use such
// metadata for indexing
@@ -458,16 +461,10 @@ static int parse_keyframes_index(AVFormatContext *s,
AVIOContext *ioc, int64_t m
double d;
if (avio_r8(ioc) != AMF_DATA_TYPE_NUMBER)
goto invalid;
-d = av_int2double(avio_rb64(ioc));
+d = av_int2double(avio_rb64(ioc)) * factor;
if (isnan(d) || d < INT64_MIN || d > INT64_MAX)
goto invalid;
-if (current_array == ×) {
-if (d <= INT64_MIN / 1000 || d >= INT64_MAX / 1000)
-goto invalid;
-current_array[0][i] = d * 1000;
-} else {
-current_array[0][i] = d;
-}
+current_array[0][i] = d;
}
if (times && filepositions) {
// All done, exiting at a position allowing amf_parse_object
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg
Re: [FFmpeg-devel] [PATCH 5/5] aarch64: me_cmp: Don't do uaddlv once per iteration
On Sat, Jul 16, 2022 at 03:30:23PM +0300, Martin Storsjö wrote:
> On Sat, 16 Jul 2022, Michael Niedermayer wrote:
>
> > On Sat, Jul 16, 2022 at 12:25:37AM +0300, Martin Storsjö wrote:
> > > On Fri, 15 Jul 2022, Michael Niedermayer wrote:
> > >
> > > > On Fri, Jul 15, 2022 at 10:56:03PM +0300, Martin Storsjö wrote:
> > > > > On Fri, 15 Jul 2022, Swinney, Jonathan wrote:
> > > > >
> > > > > > If the max height is just 16, then this should be fine. I assumed
> > > > > > that h
> > > > > > could have a much higher value (>1024), but if that is not the case,
> > > > > > then this is a useful optimization.
> > > > >
> > > > > At least according to the me_cmp.h header, which says:
> > > > >
> > > > > /* Motion estimation:
> > > > > * h is limited to { width / 2, width, 2 * width },
> > > > > * but never larger than 16 and never smaller than 2.
> > > > > * Although currently h < 4 is not used as functions with
> > > > > * width < 8 are neither used nor implemented. */
> > > >
> > > > These rules where written with support for encoding of all
> > > > standard formats in mind at the time that was written.
> > > > today it may make sense to extend these rules to cover the
> > > > things which where created since then
> > >
> > > Right, but if that suddenly changes, such a change also must expect that
> > > it
> > > might need updates to all assembly implementations that implement that
> > > interface currently. Right now, both the defacto case (any callers in the
> > > codebase) and the explicit documentation says that it can't be called with
> > > parameters outside of that range.
> >
> > What i meant was that newly added functions should be more flexible than
> > these old rules. That is 2 sets of rules
> > 1. What a caller ATM can do and expect to work (thats whats written there)
> > 2. What an implementor of new functions should make sure is supported
>
> With 2., do you mean if adding a new function into the same struct, or if
> implementing the existing pix_abs[0][..] functions?
i would say both
>
> If you mean new implementations of the existing function interface, you say
> they "should be more flexible". How flexible must they be? Is it ok to
> assume h<=256 for the w=16 functions?
i think thats fine
>
> Gradually increasing the requirements for existing function interfaces like
> you suggest is really problematic.
why ?
iam really just saying
"when you add new code, dont base it on old limitations"
And i suggest this because its much easier to do when a function is added than
when later one wants to use it
When i originally wrote this list of restrictions it didnt list what our
code actually used but tried to look ahead to what we would need when we
write encoders for all standard formats at that time. We never wrote a
h264 encoder but this API was designed to support it.
>
> If we want to require more of the functions, we should document it, and
> extend the checkasm test to test that new requirement - which also extends
> the requirement to the existing functions. If we don't have a checkasm test
> for the required behaviour, we can pretty much assume it's broken, even in
> new implementations.
yes
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- Voltaire
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/5] aarch64: me_cmp: Don't do uaddlv once per iteration
On Sat, Jul 16, 2022 at 08:50:24PM +0800, Ronald S. Bultje wrote: > Hi, > > On Sat, Jul 16, 2022 at 7:23 PM Michael Niedermayer > wrote: > > > What i meant was that newly added functions should be more flexible than > > these old rules. That is 2 sets of rules > > 1. What a caller ATM can do and expect to work (thats whats written there) > > 2. What an implementor of new functions should make sure is supported > > > > What's the use case exactly that you'd like to support that we currently > don't? The idea is to have general purpose functions which can be used if someone wants to write a new encoder. (this is kind of not a different goal, its rather that the original limitations where based on mpeg2/mpeg4/h264 which was the most flexible at the time) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present
On 7/14/2022 9:10 AM, Andreas Rheinhardt wrote:
James Almer:
Should fix ticket #3361
Signed-off-by: James Almer
---
This also needs an update to some fate ref samples i'll upload before pushing
(fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which are now decoded
properly as he_aac mono, so the .s16 files need to be replaced).
We have both a fixed-point AAC as well as a floating point AAC decoder.
Is there actually a test that tests that the output they produce is
reasonably close? If not, could we make the test so that the same file
is decoded once with the fixed-point and once with the floating-point
decoder and then compared?
That wouldn't help much, i think. Almost all changes to *_template.c
files are going to affect both decoders, so a breakage would not be
detected if you compare their output with each other as they would both
exhibit it.
libavcodec/aacdec_template.c | 15 ++-
libavcodec/aacsbr_template.c | 1 +
tests/fate/gapless.mak| 14 +++---
.../audiomatch-afconvert-16000-stereo-he2-adts| 2 +-
4 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 10fba3d3b2..15c20c07d6 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -967,8 +967,7 @@ static int decode_ga_specific_config(AACContext *ac,
AVCodecContext *avctx,
if (count_channels(layout_map, tags) > 1) {
m4ac->ps = 0;
-} else if (m4ac->sbr == 1 && m4ac->ps == -1)
-m4ac->ps = 1;
+}
if (ac && (ret = output_configure(ac, layout_map, tags, OC_GLOBAL_HDR, 0)))
return ret;
@@ -2572,18 +2571,16 @@ static int decode_extension_payload(AACContext *ac,
GetBitContext *gb, int cnt,
av_log(ac->avctx, AV_LOG_ERROR, "Implicit SBR was found with a first
occurrence after the first frame.\n");
skip_bits_long(gb, 8 * cnt - 4);
return res;
-} else if (ac->oc[1].m4ac.ps == -1 && ac->oc[1].status < OC_LOCKED &&
- ac->avctx->ch_layout.nb_channels == 1) {
-ac->oc[1].m4ac.sbr = 1;
-ac->oc[1].m4ac.ps = 1;
-ac->avctx->profile = FF_PROFILE_AAC_HE_V2;
-output_configure(ac, ac->oc[1].layout_map,
ac->oc[1].layout_map_tags,
- ac->oc[1].status, 1);
} else {
ac->oc[1].m4ac.sbr = 1;
ac->avctx->profile = FF_PROFILE_AAC_HE;
}
res = AAC_RENAME(ff_decode_sbr_extension)(ac, &che->sbr, gb,
crc_flag, cnt, elem_type);
+if (ac->oc[1].m4ac.ps == 1 && ac->oc[1].status < OC_LOCKED &&
+ac->avctx->ch_layout.nb_channels == 1) {
+output_configure(ac, ac->oc[1].layout_map,
ac->oc[1].layout_map_tags,
+ ac->oc[1].status, 1);
+}
break;
case EXT_DYNAMIC_RANGE:
res = decode_dynamic_range(&ac->che_drc, gb);
diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index b72c94b76d..f9925b40e5 100644
--- a/libavcodec/aacsbr_template.c
+++ b/libavcodec/aacsbr_template.c
@@ -954,6 +954,7 @@ static void read_sbr_extension(AACContext *ac,
SpectralBandReplication *sbr,
*num_bits_left = 0;
} else {
*num_bits_left -= ff_ps_read_data(ac->avctx, gb, &sbr->ps.common,
*num_bits_left);
+ac->oc[1].m4ac.ps = 1;
ac->avctx->profile = FF_PROFILE_AAC_HE_V2;
}
break;
diff --git a/tests/fate/gapless.mak b/tests/fate/gapless.mak
index 68a396e187..7dd8ceb142 100644
--- a/tests/fate/gapless.mak
+++ b/tests/fate/gapless.mak
@@ -47,27 +47,27 @@ fate-audiomatch-square-aac: CMD = audio_match
$(TARGET_SAMPLES)/audiomatch/squar
fate-audiomatch-afconvert-16000-mono-lc-adts: CMD = audio_match $(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.adts $(SAMPLES)/audiomatch/tones_16000_mono.wav
fate-audiomatch-afconvert-16000-mono-lc-m4a: CMD = audio_match
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.m4a
$(SAMPLES)/audiomatch/tones_16000_mono.wav
-fate-audiomatch-afconvert-16000-mono-he-adts: CMD = audio_match
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_he.adts
$(SAMPLES)/audiomatch/tones_16000_mono.wav "-ac 1 -ar 16000"
-fate-audiomatch-afconvert-16000-mono-he-m4a: CMD = audio_match
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_he.m4a
$(SAMPLES)/audiomatch/tones_16000_mono.wav "-ac 1 -ar 16000"
+fate-audiomatch-afconvert-16000-mono-he-adts: CMD = audio_match
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_he.adts
$(SAMPLES)/audiomatch/tones_16000_mono.wav "-ar 16000"
+fate-audiomatch-afconvert-16000-mono-he-m4a: CMD = audio_match
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_he.m4a
$(SAMPLES)/audiomatch/tones_16000_mono.wav "-ar 16000"
fate-a
Re: [FFmpeg-devel] [PATCH 5/5] aarch64: me_cmp: Don't do uaddlv once per iteration
Hi, On Sat, Jul 16, 2022 at 7:23 PM Michael Niedermayer wrote: > What i meant was that newly added functions should be more flexible than > these old rules. That is 2 sets of rules > 1. What a caller ATM can do and expect to work (thats whats written there) > 2. What an implementor of new functions should make sure is supported > What's the use case exactly that you'd like to support that we currently don't? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@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 5/5] aarch64: me_cmp: Don't do uaddlv once per iteration
On Sat, 16 Jul 2022, Michael Niedermayer wrote:
On Sat, Jul 16, 2022 at 12:25:37AM +0300, Martin Storsjö wrote:
On Fri, 15 Jul 2022, Michael Niedermayer wrote:
On Fri, Jul 15, 2022 at 10:56:03PM +0300, Martin Storsjö wrote:
On Fri, 15 Jul 2022, Swinney, Jonathan wrote:
If the max height is just 16, then this should be fine. I assumed that h
could have a much higher value (>1024), but if that is not the case,
then this is a useful optimization.
At least according to the me_cmp.h header, which says:
/* Motion estimation:
* h is limited to { width / 2, width, 2 * width },
* but never larger than 16 and never smaller than 2.
* Although currently h < 4 is not used as functions with
* width < 8 are neither used nor implemented. */
These rules where written with support for encoding of all
standard formats in mind at the time that was written.
today it may make sense to extend these rules to cover the
things which where created since then
Right, but if that suddenly changes, such a change also must expect that it
might need updates to all assembly implementations that implement that
interface currently. Right now, both the defacto case (any callers in the
codebase) and the explicit documentation says that it can't be called with
parameters outside of that range.
What i meant was that newly added functions should be more flexible than
these old rules. That is 2 sets of rules
1. What a caller ATM can do and expect to work (thats whats written there)
2. What an implementor of new functions should make sure is supported
With 2., do you mean if adding a new function into the same struct, or if
implementing the existing pix_abs[0][..] functions?
If you mean new implementations of the existing function interface, you
say they "should be more flexible". How flexible must they be? Is it ok to
assume h<=256 for the w=16 functions?
Gradually increasing the requirements for existing function interfaces
like you suggest is really problematic.
If we want to require more of the functions, we should document it, and
extend the checkasm test to test that new requirement - which also extends
the requirement to the existing functions. If we don't have a checkasm
test for the required behaviour, we can pretty much assume it's broken,
even in new implementations.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/5] aarch64: me_cmp: Don't do uaddlv once per iteration
On Sat, Jul 16, 2022 at 12:25:37AM +0300, Martin Storsjö wrote:
> On Fri, 15 Jul 2022, Michael Niedermayer wrote:
>
> > On Fri, Jul 15, 2022 at 10:56:03PM +0300, Martin Storsjö wrote:
> > > On Fri, 15 Jul 2022, Swinney, Jonathan wrote:
> > >
> > > > If the max height is just 16, then this should be fine. I assumed that h
> > > > could have a much higher value (>1024), but if that is not the case,
> > > > then this is a useful optimization.
> > >
> > > At least according to the me_cmp.h header, which says:
> > >
> > > /* Motion estimation:
> > > * h is limited to { width / 2, width, 2 * width },
> > > * but never larger than 16 and never smaller than 2.
> > > * Although currently h < 4 is not used as functions with
> > > * width < 8 are neither used nor implemented. */
> >
> > These rules where written with support for encoding of all
> > standard formats in mind at the time that was written.
> > today it may make sense to extend these rules to cover the
> > things which where created since then
>
> Right, but if that suddenly changes, such a change also must expect that it
> might need updates to all assembly implementations that implement that
> interface currently. Right now, both the defacto case (any callers in the
> codebase) and the explicit documentation says that it can't be called with
> parameters outside of that range.
What i meant was that newly added functions should be more flexible than
these old rules. That is 2 sets of rules
1. What a caller ATM can do and expect to work (thats whats written there)
2. What an implementor of new functions should make sure is supported
>
> Even if it's raised from the current <= 16, this particular optimization
> should be fine as long as h <= 256 - which should be fine for at least all
> current-gen mainstream codecs since, I think?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 4/5] libswscale: Enable hscale_avx2 for all input sizes.
On Fri, Jul 15, 2022 at 05:03:56PM +0200, Alan Kelly wrote: > Hi Michael, > > Thanks for looking at this. I fixed the test issue. seems to be still failing here: make distclean ; ./configure && make -j32 tests/checkasm/checkasm && tests/checkasm/checkasm --test=sw_scale checkasm: using random seed 1328711543 MMXEXT: - sw_scale.yuv2yuvX [OK] SSE2: - sw_scale.hscale [OK] SSE3: - sw_scale.yuv2yuvX [OK] SSSE3: - sw_scale.hscale [OK] SSE4.1: - sw_scale.hscale [OK] AVX2: hscale_8_to_15__fs_4_dstW_8_avx2 (sw_scale.c:235) hscale_8_to_15__fs_4_dstW_24_avx2 (sw_scale.c:235) hscale_8_to_15__fs_8_dstW_8_avx2 (sw_scale.c:235) hscale_8_to_15__fs_8_dstW_24_avx2 (sw_scale.c:235) hscale_8_to_15__fs_12_dstW_8_avx2 (sw_scale.c:235) hscale_8_to_15__fs_12_dstW_24_avx2 (sw_scale.c:235) hscale_8_to_15__fs_16_dstW_8_avx2 (sw_scale.c:235) hscale_8_to_15__fs_16_dstW_24_avx2 (sw_scale.c:235) hscale_8_to_15__fs_32_dstW_8_avx2 (sw_scale.c:235) hscale_8_to_15__fs_32_dstW_24_avx2 (sw_scale.c:235) hscale_8_to_15__fs_40_dstW_8_avx2 (sw_scale.c:235) hscale_8_to_15__fs_40_dstW_24_avx2 (sw_scale.c:235) - sw_scale.hscale [FAILED] - sw_scale.yuv2yuvX [OK] checkasm: 12 of 504 tests have failed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is a danger to trust the dream we wish for rather than the science we have, -- Dr. Kenneth Brown signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libspeexdec: initialize channels
On 16.07.2022 12:50, Paul B Mahol wrote: Please fix native decoder instead. Both decoders should be fixed if they have issues decoding valid files. ___ ffmpeg-devel mailing list ffmpeg-devel@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/libspeexdec: initialize channels
Please fix native decoder instead. ___ ffmpeg-devel mailing list ffmpeg-devel@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/libspeexdec: initialize channels
Thanks for your advice. But native speex decoder also has its own issue when decoding speex packet which contains multiple frames. ffmpeg -i someaudio -ac 1 -ar 16000 -c:a libspeex -frames_per_packets 3 -f flv xx.flv ffplay xx.flv native speed decoder only get the first frame of every packet as speex in flv has no header. so I prefer use libspeexdec as an alternative before the native speex decoder issue is fixed and send this patch for libspeexdec. Paul B Mahol 于2022年7月16日周六 15:24写道： > use native decoder > ___ ffmpeg-devel mailing list ffmpeg-devel@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 5/5] aarch64: me_cmp: Don't do uaddlv once per iteration
On Fri, 15 Jul 2022, Michael Niedermayer wrote:
On Fri, Jul 15, 2022 at 10:56:03PM +0300, Martin Storsjö wrote:
On Fri, 15 Jul 2022, Swinney, Jonathan wrote:
If the max height is just 16, then this should be fine. I assumed that h
could have a much higher value (>1024), but if that is not the case,
then this is a useful optimization.
At least according to the me_cmp.h header, which says:
/* Motion estimation:
* h is limited to { width / 2, width, 2 * width },
* but never larger than 16 and never smaller than 2.
* Although currently h < 4 is not used as functions with
* width < 8 are neither used nor implemented. */
These rules where written with support for encoding of all
standard formats in mind at the time that was written.
today it may make sense to extend these rules to cover the
things which where created since then
Also - if extending this, I would expect that you want other widths too.
Right now, most of the functions seem to be arranged such as [0] is w=16
and [0] is w=8. For those, for w=8, it seems to be mostly hardcoded to
only assume h=8, while the w=16 functions actually honor the h parameter.
If it ever would be relevant with h>256, that wouldn't be for the existing
w=8 or w=16 functions, but for newer functions with a larger width too.
So I think this patch is safe (which works for h up to 256), and if
someone wants to extend the interface later, that can be done.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libspeexdec: initialize channels
use native decoder ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
