[FFmpeg-devel] [PATCH v2] avutil/mem: Mark DECLARE_ASM_ALIGNED as visibility("hidden") for __GNUC__
Inline asm code assumes these DECLARE_ASM_ALIGNED declared global
constants are non-preemptive, e.g.
libavcodec/x86/cabac.h
"lea"MANGLE(ff_h264_cabac_tables)", %0 \n\t"
These constants are currently defined in C files with default
visibility. Such object files require either -Wl,-Bsymbolic or
-Wl,--version-script,libavcodec/libavcodec.ver to link into a shared
object. However, there are good reasons that the user wants to specify
neither option:
* -Bsymbolic is dangerous as it breaks C++ semantics about address
uniqueness of inline functions, type_info, ...
* --version-script applies to all exported symbols and can thus affect
program code. If the program code doesn't want all of its symbols to be
marked local, it needs to define its own version script combining
FFmpeg's version scripts. This is cumbersome.
If neither -Bsymbolic nor --version-script is specified, there will be
linker errors like:
ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol
ff_h264_cabac_tables; recompile with -fPIC
It is better to express the intention explicitly and mark such global
constants hidden. This patch marks a large number of such constants
(accessible from assembly) hidden.
Signed-off-by: Fangrui Song
---
Changes in v2:
* Rewrote description
* Used av_ prefixed av_visibility_hidden
* The patch is a re-send of
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241054.html
---
libavutil/mem.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavutil/mem.h b/libavutil/mem.h
index 5fb1a02dd9..98a14b826b 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -100,6 +100,12 @@
* @param v Name of the variable
*/
+#if defined(__GNUC__) && !(defined(_WIN32) || defined(__CYGWIN__))
+#define av_visibility_hidden __attribute__ ((visibility ("hidden")))
+#else
+#define av_visibility_hidden
+#endif
+
#if defined(__INTEL_COMPILER) && __INTEL_COMPILER < 1110 || defined(__SUNPRO_C)
#define DECLARE_ALIGNED(n,t,v) t __attribute__ ((aligned (n))) v
#define DECLARE_ASM_ALIGNED(n,t,v) t __attribute__ ((aligned (n))) v
@@ -110,7 +116,7 @@
#define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__
((aligned (FFMIN(n, 16 v
#elif defined(__GNUC__) || defined(__clang__)
#define DECLARE_ALIGNED(n,t,v) t __attribute__ ((aligned (n))) v
-#define DECLARE_ASM_ALIGNED(n,t,v) t av_used __attribute__ ((aligned
(n))) v
+#define DECLARE_ASM_ALIGNED(n,t,v) t av_used __attribute__ ((aligned
(n))) av_visibility_hidden v
#define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__
((aligned (n))) v
#elif defined(_MSC_VER)
#define DECLARE_ALIGNED(n,t,v) __declspec(align(n)) t v
--
2.28.0.297.g1956fa8f8d-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/1] libavformat/nut: Support SSA and ASS subtitles
ffmpeg documentation says the NUT container supports SubStation Alpha
This brings actual functionality in line with documentation.
---
libavformat/nut.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/nut.c b/libavformat/nut.c
index d6993239a3..47ed152529 100644
--- a/libavformat/nut.c
+++ b/libavformat/nut.c
@@ -27,6 +27,8 @@
const AVCodecTag ff_nut_subtitle_tags[] = {
{ AV_CODEC_ID_TEXT, MKTAG('U', 'T', 'F', '8') },
+{ AV_CODEC_ID_ASS, MKTAG('S', 'S', 'A', 0 ) },
+{ AV_CODEC_ID_ASS, MKTAG('A', 'S', 'S', 0 ) },
{ AV_CODEC_ID_DVD_SUBTITLE, MKTAG('D', 'V', 'D', 'S') },
{ AV_CODEC_ID_DVB_SUBTITLE, MKTAG('D', 'V', 'B', 'S') },
{ AV_CODEC_ID_DVB_TELETEXT, MKTAG('D', 'V', 'B', 'T') },
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Documentation: proposed changes in the structure
On Sat, Aug 22, 2020 at 01:15:14AM +0200, Clément Bœsch wrote: [...] > But I think we have it wrong with the documentation approach. What is > currently described within the code corresponds to the "technical > documentation". While all the extra information on the filters may enter > within the "explanation" and "tutorial" realm. This means that we could > have a filter documentation that starts with the technical documentation > (generated from the code) followed by all the "extra" detailed info on the > filter themselves. To clarify just a little here: the non technical documentation would be written manually outside of the code, just like currently (except we would strip out all the redundant info with the tech doc). -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Documentation: proposed changes in the structure
On Fri, Aug 21, 2020 at 11:40:20PM +0200, Nicolas George wrote:
> Clement Boesch (12020-08-21):
> > The split is probably not a bad idea, but can we discuss having the
> > documentation within the C code to prevent duplication/redundancy?
> >
> > We could write a tool to generate the documentation file, or maybe part of
> > it for a start (the options). Having to document twice leads to many
> > inconsistencies.
>
> I do not understand what you mean, especially about "document twice".
>
AVOption.help and AVFilter.description (as well as AVCodec.description
etc) do contain redundant information with the documentation.
Additionally, we sometimes document manually the default, all the
constants, sometimes the ranges, which are already held within the
AVOption.
So yes I'd rather have the AVOption.help extended to contain more and have
a tool which is basically `ffmpeg -h filter=xxx` in the choosen markup.
> In my mind, if we want to make the doc part of the library, there is a
> step during compilation where all the $SRCDIR/libav*/doc/*.texi or
> $SRCDIR/libav*/doc/*.md are converted into $BUILDDIR/libav*/doc/*.c or
> one single C file whatever is more convenient, and then compiled into
> the library. There is never any duplication in the source tree, the doc
> is written once and only once.
I meant the other way around: you have a gen-doc.c which you compile and
link against the library, which generates the .md (integration within the
make is easy).
>
> How would you include the documentation in the C source file directly?
> Write directly the structures:
>
> static const AVDocumentation doc = {
> .name = "scale",
> .title = "scaling and pixel format conversion filter",
> .description = "Scale (resize) the input video, using the libswscale"
> " library.\nThe scale filter forces the output display aspect ratio"
> " to be the same of the input, by changing the output sample aspect"
> " ratio. ...";
> };
>
> Or in Doxygen? Or in something like Doxygen that we invent ourselves?
> None of them feels convenient. Or did I completely misunderstand you.
>
Yes, for long documentations might be annoying (and we also need to wrap
it with NULL_IF_CONFIG_SMALL).
But I think we have it wrong with the documentation approach. What is
currently described within the code corresponds to the "technical
documentation". While all the extra information on the filters may enter
within the "explanation" and "tutorial" realm. This means that we could
have a filter documentation that starts with the technical documentation
(generated from the code) followed by all the "extra" detailed info on the
filter themselves.
It might get clumsy but at least we wouldn't have to paraphrase with a
different formatting every single option, and miss half of them on a
regular basis.
You may want to read https://documentation.divio.com/ to understand better
the separation I'm making.
> > > 2. What would you think about switching from texinfo to a small basic
> > >subset of HTML for new documentation?
> > >
> > >I think most of us are much more familiar with HTML syntax than with
> > >texinfo.
> >
> > Anything but HTML please... It's verbose, there are many different
> > versions, and it's too lax IMO (capitalized tags or not? do you use ending
> > slashes for single tags? what are all the indentation rules? ...)
>
> That's why I did not say "HTML" but "a small basic subset of HTML": we
> answer these questions as we want, and we make a pre-commit hook to
> enforce the rules.
Yeah well, I guess I have PTSD from the dealing with SubRip. Nevertheless,
I believe markdown, asciidoc etc are much more expressive text wise.
[...]
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libaomdec: Set SAR based on RenderWidth and RenderHeight
On 21/08/2020 17:36, James Almer wrote: > Should probably also add a ff_set_sar(avctx, > picture->sample_aspect_ratio) call after this. I'll do the same for > libdav1d. > > LGTM in any case. Done and pushed. - Derek ___ ffmpeg-devel 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/rzpaenc: Remove set-but-unused variable
Signed-off-by: Andreas Rheinhardt
---
libavcodec/rpzaenc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/rpzaenc.c b/libavcodec/rpzaenc.c
index 2d3876743f..baf067c205 100644
--- a/libavcodec/rpzaenc.c
+++ b/libavcodec/rpzaenc.c
@@ -643,8 +643,7 @@ post_skip :
if (update_block_stats(s, &bi, &src_pixels[block_offset],
min_color, max_color,
total_rgb, &pixel_count, avg_color, 1)) {
-int first_block_offset;
-first_block_offset = prev_block_offset = block_offset;
+prev_block_offset = block_offset;
n_blocks = 1;
--
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] avcodec/proresenc: infer array lengths
On Fri, Aug 21, 2020 at 11:07:51AM -0700, Michael Bradshaw wrote: > Signed-off-by: Michael Bradshaw > --- > libavcodec/proresenc_anatoliy.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle 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".
[FFmpeg-devel] [PATCH 3/3] avcodec/aacdec_template: log the element order before/after reordering
This was quite useful to verify that 22.2 got properly handled,
among other things.
---
libavcodec/aacdec_template.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 63604d39fd..b9b9ae5324 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -266,6 +266,22 @@ static int count_paired_channels(uint8_t (*layout_map)[3],
int tags, int pos,
return num_pos_channels;
}
+static void log_e2c(int num, struct elem_to_channel e2c) {
+char buf[128] = { 0 };
+
+av_get_channel_layout_string(buf, sizeof(buf), -1, e2c.av_position);
+
+av_log(NULL, AV_LOG_DEBUG,
+ "tag %d = { position(s): %s (0x%"PRIx64"), syn_elem: %s, elem_id:
%"PRIu8" }\n",
+ num,
+ e2c.av_position == UINT64_MAX ? "Unset/Ignored" : buf,
+ e2c.av_position,
+ e2c.syn_ele == TYPE_SCE ? "SCE" :
+ e2c.syn_ele == TYPE_CPE ? "CPE" :
+ e2c.syn_ele == TYPE_LFE ? "LFE" : "",
+ e2c.elem_id);
+}
+
#define PREFIX_FOR_22POINT2
(AV_CH_LAYOUT_7POINT1_WIDE_BACK|AV_CH_BACK_CENTER|AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT|AV_CH_LOW_FREQUENCY_2)
static uint64_t sniff_channel_order(uint8_t (*layout_map)[3], int tags)
{
@@ -494,6 +510,11 @@ end_of_layout_definition:
total_non_cc_elements = n = i;
+av_log(NULL, AV_LOG_DEBUG, "Element order before reorder:\n");
+for (i = 0; i < n; i++) {
+log_e2c(i, e2c_vec[i]);
+}
+
if (layout == AV_CH_LAYOUT_22POINT2) {
// For 22.2 reorder the result as needed
FFSWAP(struct elem_to_channel, e2c_vec[2], e2c_vec[0]); // FL & FR
first (final), FC third
@@ -520,6 +541,11 @@ end_of_layout_definition:
}
+av_log(NULL, AV_LOG_DEBUG, "Element order after reorder:\n");
+for (i = 0; i < total_non_cc_elements; i++) {
+log_e2c(i, e2c_vec[i]);
+}
+
for (i = 0; i < total_non_cc_elements; i++) {
layout_map[i][0] = e2c_vec[i].syn_ele;
layout_map[i][1] = e2c_vec[i].elem_id;
--
2.26.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".
[FFmpeg-devel] [PATCH 2/3 v2] avcodec/aacdec_template: add more checks to make sure only 22.2 gets to 22.2
This way we can check that we have exactly the required things for 22.2.
Fixes #8845
---
libavcodec/aacdec_template.c | 47 ++--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 9f7016790e..63604d39fd 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -266,6 +266,7 @@ static int count_paired_channels(uint8_t (*layout_map)[3],
int tags, int pos,
return num_pos_channels;
}
+#define PREFIX_FOR_22POINT2
(AV_CH_LAYOUT_7POINT1_WIDE_BACK|AV_CH_BACK_CENTER|AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT|AV_CH_LOW_FREQUENCY_2)
static uint64_t sniff_channel_order(uint8_t (*layout_map)[3], int tags)
{
int i, n, total_non_cc_elements;
@@ -402,46 +403,86 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3], int tags)
}
// The previous checks would end up at 8 at this point for 22.2
-if (tags == 16 && i == 8) {
+if (layout == PREFIX_FOR_22POINT2 && tags == 16 && i == 8) {
+if (layout_map[i][0] != TYPE_SCE ||
+layout_map[i][2] != AAC_CHANNEL_FRONT)
+goto end_of_layout_definition;
+
e2c_vec[i] = (struct elem_to_channel) {
.av_position = AV_CH_TOP_FRONT_CENTER,
.syn_ele = layout_map[i][0],
.elem_id = layout_map[i][1],
.aac_position = layout_map[i][2]
}; layout |= e2c_vec[i].av_position; i++;
+
+if (layout_map[i][0] != TYPE_CPE ||
+layout_map[i][2] != AAC_CHANNEL_FRONT)
+goto end_of_layout_definition;
+
i += assign_pair(e2c_vec, layout_map, i,
AV_CH_TOP_FRONT_LEFT,
AV_CH_TOP_FRONT_RIGHT,
AAC_CHANNEL_FRONT,
&layout);
+
+if (layout_map[i][0] != TYPE_CPE ||
+layout_map[i][2] != AAC_CHANNEL_SIDE)
+goto end_of_layout_definition;
+
i += assign_pair(e2c_vec, layout_map, i,
AV_CH_TOP_SIDE_LEFT,
AV_CH_TOP_SIDE_RIGHT,
AAC_CHANNEL_SIDE,
&layout);
+
+if (layout_map[i][0] != TYPE_SCE ||
+layout_map[i][2] != AAC_CHANNEL_FRONT)
+goto end_of_layout_definition;
+
e2c_vec[i] = (struct elem_to_channel) {
.av_position = AV_CH_TOP_CENTER,
.syn_ele = layout_map[i][0],
.elem_id = layout_map[i][1],
.aac_position = layout_map[i][2]
}; layout |= e2c_vec[i].av_position; i++;
+
+if (layout_map[i][0] != TYPE_CPE ||
+layout_map[i][2] != AAC_CHANNEL_BACK)
+goto end_of_layout_definition;
+
i += assign_pair(e2c_vec, layout_map, i,
AV_CH_TOP_BACK_LEFT,
AV_CH_TOP_BACK_RIGHT,
AAC_CHANNEL_BACK,
&layout);
+
+if (layout_map[i][0] != TYPE_SCE ||
+layout_map[i][2] != AAC_CHANNEL_BACK)
+goto end_of_layout_definition;
+
e2c_vec[i] = (struct elem_to_channel) {
.av_position = AV_CH_TOP_BACK_CENTER,
.syn_ele = layout_map[i][0],
.elem_id = layout_map[i][1],
.aac_position = layout_map[i][2]
}; layout |= e2c_vec[i].av_position; i++;
+
+
+if (layout_map[i][0] != TYPE_SCE ||
+layout_map[i][2] != AAC_CHANNEL_FRONT)
+goto end_of_layout_definition;
+
e2c_vec[i] = (struct elem_to_channel) {
.av_position = AV_CH_BOTTOM_FRONT_CENTER,
.syn_ele = layout_map[i][0],
.elem_id = layout_map[i][1],
.aac_position = layout_map[i][2]
}; layout |= e2c_vec[i].av_position; i++;
+
+if (layout_map[i][0] != TYPE_CPE ||
+layout_map[i][2] != AAC_CHANNEL_FRONT)
+goto end_of_layout_definition;
+
i += assign_pair(e2c_vec, layout_map, i,
AV_CH_BOTTOM_FRONT_LEFT,
AV_CH_BOTTOM_FRONT_RIGHT,
@@ -449,9 +490,11 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3], int tags)
&layout);
}
+end_of_layout_definition:
+
total_non_cc_elements = n = i;
-if (tags == 16 && total_non_cc_elements == 16) {
+if (layout == AV_CH_LAYOUT_22POINT2) {
// For 22.2 reorder the result as needed
FFSWAP(struct elem_to_channel, e2c_vec[2], e2c_vec[0]); // FL & FR
first (final), FC third
FFSWAP(struct elem_to_channel, e2c_vec[2], e2c_vec[1]); // FC second
(final), FLc & FRc third
--
2.26.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.o
[FFmpeg-devel] [PATCH 1/3 v2] avcodec/aacdec_template: keep tabs on layout in sniff_channel_order
This way the layout set at various points can be checked instead
of only having the layout at the end.
---
libavcodec/aacdec_template.c | 56 ++--
1 file changed, 35 insertions(+), 21 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 8c5048cc13..9f7016790e 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -198,7 +198,7 @@ struct elem_to_channel {
static int assign_pair(struct elem_to_channel e2c_vec[MAX_ELEM_ID],
uint8_t (*layout_map)[3], int offset, uint64_t left,
- uint64_t right, int pos)
+ uint64_t right, int pos, uint64_t *layout)
{
if (layout_map[offset][0] == TYPE_CPE) {
e2c_vec[offset] = (struct elem_to_channel) {
@@ -207,6 +207,9 @@ static int assign_pair(struct elem_to_channel
e2c_vec[MAX_ELEM_ID],
.elem_id = layout_map[offset][1],
.aac_position = pos
};
+if (e2c_vec[offset].av_position != UINT64_MAX)
+*layout |= e2c_vec[offset].av_position;
+
return 1;
} else {
e2c_vec[offset] = (struct elem_to_channel) {
@@ -221,6 +224,12 @@ static int assign_pair(struct elem_to_channel
e2c_vec[MAX_ELEM_ID],
.elem_id = layout_map[offset + 1][1],
.aac_position = pos
};
+if (left != UINT64_MAX)
+*layout |= left;
+
+if (right != UINT64_MAX)
+*layout |= right;
+
return 2;
}
}
@@ -262,7 +271,7 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3], int tags)
int i, n, total_non_cc_elements;
struct elem_to_channel e2c_vec[4 * MAX_ELEM_ID] = { { 0 } };
int num_front_channels, num_side_channels, num_back_channels;
-uint64_t layout;
+uint64_t layout = 0;
if (FF_ARRAY_ELEMS(e2c_vec) < tags)
return 0;
@@ -294,6 +303,7 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3], int tags)
.elem_id = layout_map[i][1],
.aac_position = AAC_CHANNEL_FRONT
};
+layout |= e2c_vec[i].av_position;
i++;
num_front_channels--;
}
@@ -301,21 +311,21 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3], int tags)
i += assign_pair(e2c_vec, layout_map, i,
AV_CH_FRONT_LEFT_OF_CENTER,
AV_CH_FRONT_RIGHT_OF_CENTER,
- AAC_CHANNEL_FRONT);
+ AAC_CHANNEL_FRONT, &layout);
num_front_channels -= 2;
}
if (num_front_channels >= 2) {
i += assign_pair(e2c_vec, layout_map, i,
AV_CH_FRONT_LEFT,
AV_CH_FRONT_RIGHT,
- AAC_CHANNEL_FRONT);
+ AAC_CHANNEL_FRONT, &layout);
num_front_channels -= 2;
}
while (num_front_channels >= 2) {
i += assign_pair(e2c_vec, layout_map, i,
UINT64_MAX,
UINT64_MAX,
- AAC_CHANNEL_FRONT);
+ AAC_CHANNEL_FRONT, &layout);
num_front_channels -= 2;
}
@@ -323,14 +333,14 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3], int tags)
i += assign_pair(e2c_vec, layout_map, i,
AV_CH_SIDE_LEFT,
AV_CH_SIDE_RIGHT,
- AAC_CHANNEL_FRONT);
+ AAC_CHANNEL_FRONT, &layout);
num_side_channels -= 2;
}
while (num_side_channels >= 2) {
i += assign_pair(e2c_vec, layout_map, i,
UINT64_MAX,
UINT64_MAX,
- AAC_CHANNEL_SIDE);
+ AAC_CHANNEL_SIDE, &layout);
num_side_channels -= 2;
}
@@ -338,14 +348,14 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3], int tags)
i += assign_pair(e2c_vec, layout_map, i,
UINT64_MAX,
UINT64_MAX,
- AAC_CHANNEL_BACK);
+ AAC_CHANNEL_BACK, &layout);
num_back_channels -= 2;
}
if (num_back_channels >= 2) {
i += assign_pair(e2c_vec, layout_map, i,
AV_CH_BACK_LEFT,
AV_CH_BACK_RIGHT,
- AAC_CHANNEL_BACK);
+ AAC_CHANNEL_BACK, &layout);
num_back_channels -= 2;
}
if (num_back_channels) {
@@ -355,6 +365,7 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3], int tags)
.elem_id = layout_map[i][1],
.aac_position = AAC_CHANNEL_BACK
};
+layout |= e2c_vec[i].av_position;
i++;
num_back_channels--;
}
@@ -366,6 +377,7 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3
[FFmpeg-devel] [PATCH 0/3 v2] avcodec/aacdec_template: improvements to 22.2 layout logic
Compared to v1: * Left and right are being handled separately in case of assign_pair()'s 2x SCE mode. (patch 1/3) * Exact coding element is also checked instead of just coding element channel type in sniff_channel_order()'s 22.2 specific if statement. (patch 2/3) * Last check in sniff_channel_order() for 22.2 is simplified to just the channel layout. The if already does enough checking and if the input ended up getting the full 22.2 layout, we are good to go. (patch 2/3) The first two commits fix both of the fuzzing samples I have on hand. One being from #8845, and another provided privately by Michael. Changes have been tested both with clang 10's ASAN as well as standard valgrind. The last commit is general debug logging that I found helpful during adding support of 22.2 by logging the element order before/after reorder. This one, if found non-interesting, can just be ignored. I decided to post it as it was part of my verification. Jan Ekström (3): avcodec/aacdec_template: keep tabs on layout in sniff_channel_order avcodec/aacdec_template: add more checks to make sure only 22.2 gets to 22.2 avcodec/aacdec_template: log the element order before/after reordering libavcodec/aacdec_template.c | 129 --- 1 file changed, 106 insertions(+), 23 deletions(-) -- 2.26.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 1/2] avcodec: add av1 hardware acceleration decoder
On 8/21/2020 11:42 AM, James Almer wrote:
>> +static int set_output_frame(AVFrame *srcframe, AVFrame *frame, AVPacket
>> *pkt)
>> +{
>> +int ret = 0;
>> +if ((ret = av_frame_ref(frame, srcframe)) < 0) {
>> +return ret;
>> +}
>> +
>> +frame->pts = pkt->pts;
>> +frame->pkt_dts = pkt->dts;
> Did you add this because you saw bogus timestamps filled by
> ff_thread_get_buffer? If so, could you try applying
> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2057 and
> removing this chunk, to see if it fixes it?
Actually no, it wont help. The decoder as is lacks the DELAY flag, so
it's a 1:1 decoder. Guess this is correct.
If you set frame->pkt_dts however, you need to signal it with the
FF_CODEC_CAP_SETS_PKT_DTS AVCodec.caps_internal flag.
___
ffmpeg-devel 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] Documentation: proposed changes in the structure
Clement Boesch (12020-08-21):
> The split is probably not a bad idea, but can we discuss having the
> documentation within the C code to prevent duplication/redundancy?
>
> We could write a tool to generate the documentation file, or maybe part of
> it for a start (the options). Having to document twice leads to many
> inconsistencies.
I do not understand what you mean, especially about "document twice".
In my mind, if we want to make the doc part of the library, there is a
step during compilation where all the $SRCDIR/libav*/doc/*.texi or
$SRCDIR/libav*/doc/*.md are converted into $BUILDDIR/libav*/doc/*.c or
one single C file whatever is more convenient, and then compiled into
the library. There is never any duplication in the source tree, the doc
is written once and only once.
How would you include the documentation in the C source file directly?
Write directly the structures:
static const AVDocumentation doc = {
.name = "scale",
.title = "scaling and pixel format conversion filter",
.description = "Scale (resize) the input video, using the libswscale"
" library.\nThe scale filter forces the output display aspect ratio"
" to be the same of the input, by changing the output sample aspect"
" ratio. ...";
};
Or in Doxygen? Or in something like Doxygen that we invent ourselves?
None of them feels convenient. Or did I completely misunderstand you.
> > 2. What would you think about switching from texinfo to a small basic
> >subset of HTML for new documentation?
> >
> >I think most of us are much more familiar with HTML syntax than with
> >texinfo.
>
> Anything but HTML please... It's verbose, there are many different
> versions, and it's too lax IMO (capitalized tags or not? do you use ending
> slashes for single tags? what are all the indentation rules? ...)
That's why I did not say "HTML" but "a small basic subset of HTML": we
answer these questions as we want, and we make a pre-commit hook to
enforce the rules.
But apparently the consensus is for something simpler. Although Markdown
can contain HTML, so we still have the issue.
> Pandoc is great, but it has a haskell dependency, it's actually a pretty
> huge distribution. It's not yet to the level of a LaTeX distribution, but
> it's still pretty large; here it's about 240M with all its dependencies.
I downloaded the static binary from the site, unpacked it takes 112 Mo,
that is big, but not monstrous. On a Debian oldstable (I need to
upgrade!) where nothing related was installed, I get liblua5.1-0
libluajit-5.1-2 libluajit-5.1-common pandoc pandoc-data and "After this
operation, 72.6 MB of additional disk space will be used.", which
matches the size of the static binary without citeproc.
One of the benefits of pandoc is that it is possible to write a custom
writer, we can use that to generate the C files for inclusion in the
library. Otherwise, we would have another build-dependency, a language
interpreter to write the conversion, unless somebody intends to
implement it in C.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 1/3] [RFC] lavc: add FLIF decoding support
August 21, 2020 8:27 PM, "Paul B Mahol" wrote: > On 8/20/20, Anamitra Ghorui wrote: > >> Hello, >> >> On Wed, 19 Aug 2020 21:05:41 +0200 >> Paul B Mahol wrote: >> >> [...] >> All these corrections have been made by me locally, but I would like to wait for some further review (self and otherwise) before posting again. >>> >>> Please make use of av_clip and FFMIN/FFMAX macros. >> >> We have looked through the code again and have not been able to notice a >> situation where these macros will be required aside from where they are >> already used. They have been largely used in the transform code and >> sparsely used everywhere else. Can you please point to a portion where >> their use is warranted? > > ff_bound_snap. Thanks for the pointer. Didn't see that most of these patterns such as: if (a < b) a = b; could be converted into a = FFMAX(a, b). > Also av_freep() is inconsistently used in code. You do not need to > check for NULL, prior to calling it. Ah. I don't know why I didn't check all the code for it after Nicolas George's prompting. Fixed locally. Thanks. A few more things noticed: * A few av_assert0()s in transform reverse functions should be rewritten to av_assert1() as they are speed critical. * ff_static_snap calls minmax functions, a lot of which use av_assert0. Snapping functions are called in speed critical code therefore they should likely be converted into av_assert1()s. * There is some cosmetic asymmetry between flif16_ni_predict_calcprops and flif16_predict_calcprops (variable aliases used). Fixed locally. Regards, Anamitra ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavfi: regroup formats lists in a single structure.
Nicolas George: > Andreas Rheinhardt (12020-08-18): >> 1. Adding this struct has also another benefit besides the ones in your >> two other patches: One can simplify the freeing process by adding a new >> ff_formatscfg_unref() (I'm not sure on the name). This could also be >> used in the uninit function of the aformat filter. If I am not mistaken, >> the only place outside of formats.c where one needs to unref an >> AVFilterContext/AVFilterChannelLayout is in hwdownload where one only >> needs ff_formats_unref() -- ff_channel_layouts_unref() can therefore be >> made static. (This presumes that redundant ff_*_unref() have been >> removed as is done in [1].) > > Actually, I find the use of ff_formats_unref() in filter somewhat > suspicious. The functions are designed to free their arguments if > something fails, so as not to leak anything. > This only works if one only works with one list without owner at a time; if one has several such lists at the same time and an error happens when working with one of these lists, one has to free the other lists. This scenario can of course usually be avoided by making sure that one only has one list without owner at any given time. I used this method in my patches a lot. I have also rewritten the hwdownload patch [1] to avoid explicit ff_formats_unref() in it. This means that ff_formats_unref() can become static, too. [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/268429.html >> 2. For the ease of backportability the double-frees/memleaks ([2] and >> the other patches from that patchset) should be applied before this one. > > What is missing before applying this? > What does "this" refer to here? If it refers to my patches, then nothing is missing (except a review). They can be applied at once and then they can also be directly backported and you can then apply your big patch on top of it; of course, there will be trivial conflicts in the few files that I touch. If "this" refers to your patches: Applying them before fixing the leaks/double-frees will make backporting the fixes much more troublesome. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/ffmetadecc.c: Fix Use-of-uninitialized-value
On Thu, Aug 20, 2020 at 12:14:52PM -0700, Thierry Foucu wrote: > Check the return value of sscanf as it can return -1(EOF), for example > when the first char in the line is 0x00 > --- > libavformat/ffmetadec.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) will apply thx [...] -- 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.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/aacdec_template: add more checks to make sure only 22.2 gets to 22.2
On Tue, Aug 18, 2020 at 10:25 PM Jan Ekström wrote:
>
> This way we can check that we have exactly the required things for 22.2.
>
> Fixes #8845
> ---
> libavcodec/aacdec_template.c | 40 ++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index 9eef1c0158..1e112ccf76 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -263,6 +263,7 @@ static int count_paired_channels(uint8_t
> (*layout_map)[3], int tags, int pos,
> return num_pos_channels;
> }
>
> +#define PREFIX_FOR_22POINT2
> (AV_CH_LAYOUT_7POINT1_WIDE_BACK|AV_CH_BACK_CENTER|AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT|AV_CH_LOW_FREQUENCY_2)
> static uint64_t sniff_channel_order(uint8_t (*layout_map)[3], int tags)
> {
> int i, n, total_non_cc_elements;
> @@ -399,46 +400,78 @@ static uint64_t sniff_channel_order(uint8_t
> (*layout_map)[3], int tags)
> }
>
> // The previous checks would end up at 8 at this point for 22.2
> -if (tags == 16 && i == 8) {
> +if (layout == PREFIX_FOR_22POINT2 && tags == 16 && i == 8) {
> +if (layout_map[i][2] != AAC_CHANNEL_FRONT)
> +goto end_of_layout_definition;
> +
After giving this another look, will add syntax element check here as
well (SCE or CPE).
This will then make sure that when assign_pair is called, only
TYPE_CPE elements are passed to it.
> e2c_vec[i] = (struct elem_to_channel) {
> .av_position = AV_CH_TOP_FRONT_CENTER,
> .syn_ele = layout_map[i][0],
> .elem_id = layout_map[i][1],
> .aac_position = layout_map[i][2]
> }; layout |= e2c_vec[i].av_position; i++;
> +
> +if (layout_map[i][2] != AAC_CHANNEL_FRONT)
> +goto end_of_layout_definition;
> +
> i += assign_pair(e2c_vec, layout_map, i,
> AV_CH_TOP_FRONT_LEFT,
> AV_CH_TOP_FRONT_RIGHT,
> AAC_CHANNEL_FRONT,
> &layout);
> +
> +if (layout_map[i][2] != AAC_CHANNEL_SIDE)
> +goto end_of_layout_definition;
> +
> i += assign_pair(e2c_vec, layout_map, i,
> AV_CH_TOP_SIDE_LEFT,
> AV_CH_TOP_SIDE_RIGHT,
> AAC_CHANNEL_SIDE,
> &layout);
> +
> +if (layout_map[i][2] != AAC_CHANNEL_FRONT)
> +goto end_of_layout_definition;
> +
> e2c_vec[i] = (struct elem_to_channel) {
> .av_position = AV_CH_TOP_CENTER,
> .syn_ele = layout_map[i][0],
> .elem_id = layout_map[i][1],
> .aac_position = layout_map[i][2]
> }; layout |= e2c_vec[i].av_position; i++;
> +
> +if (layout_map[i][2] != AAC_CHANNEL_BACK)
> +goto end_of_layout_definition;
> +
> i += assign_pair(e2c_vec, layout_map, i,
> AV_CH_TOP_BACK_LEFT,
> AV_CH_TOP_BACK_RIGHT,
> AAC_CHANNEL_BACK,
> &layout);
> +
> +if (layout_map[i][2] != AAC_CHANNEL_BACK)
> +goto end_of_layout_definition;
> +
> e2c_vec[i] = (struct elem_to_channel) {
> .av_position = AV_CH_TOP_BACK_CENTER,
> .syn_ele = layout_map[i][0],
> .elem_id = layout_map[i][1],
> .aac_position = layout_map[i][2]
> }; layout |= e2c_vec[i].av_position; i++;
> +
> +
> +if (layout_map[i][2] != AAC_CHANNEL_FRONT)
> +goto end_of_layout_definition;
> +
> e2c_vec[i] = (struct elem_to_channel) {
> .av_position = AV_CH_BOTTOM_FRONT_CENTER,
> .syn_ele = layout_map[i][0],
> .elem_id = layout_map[i][1],
> .aac_position = layout_map[i][2]
> }; layout |= e2c_vec[i].av_position; i++;
> +
> +if (layout_map[i][2] != AAC_CHANNEL_FRONT)
> +goto end_of_layout_definition;
> +
> i += assign_pair(e2c_vec, layout_map, i,
> AV_CH_BOTTOM_FRONT_LEFT,
> AV_CH_BOTTOM_FRONT_RIGHT,
> @@ -446,9 +479,12 @@ static uint64_t sniff_channel_order(uint8_t
> (*layout_map)[3], int tags)
> &layout);
> }
>
> +end_of_layout_definition:
> +
> total_non_cc_elements = n = i;
>
> -if (tags == 16 && total_non_cc_elements == 16) {
> +if (layout == AV_CH_LAYOUT_22POINT2 &&
> +tags == 16 && total_non_cc_elements == 16) {
Will simplify this check to just the layout. The numeric checks are
already taken care of earlier, and this eases reading of the check
since it just checks if the layout has ended up 22.2 (which is what it
ends up at if all the checks of that if statement succeed).
> // For 22.2 reorder the result as needed
> FF
[FFmpeg-devel] [PATCH v2 18/21] avfilter/vf_hwdownload: Fix leak of formats list upon error
If adding the list of input formats to its AVFilterLink fails, the list
of output formats (which has not been attached to permanent storage yet)
leaks. This has been fixed by not creating the lists of in- and output
formats simultaneously. Instead creating said lists is relegated to
ff_formats_pixdesc_filter() (this also avoids the reallocations implicit
in using ff_add_format()) and the second list is only created after (and
if) the first list has been permanently attached to ist AVFilterLink.
Signed-off-by: Andreas Rheinhardt
---
ff_formats_pixdesc_filter() uses av_pix_fmt_desc_get() under the hood;
but both av_pix_fmt_desc_get() and av_pix_fmt_desc_next() lead
(currently) to the same order of pixel formats (it coincides with the
natural order) and given that this filter doesn't seem to have any
preferred order at all, it wouldn't even matter if these two methods
yielded different results one day.
libavfilter/vf_hwdownload.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/libavfilter/vf_hwdownload.c b/libavfilter/vf_hwdownload.c
index 33af30cf40..faf2ea8c0e 100644
--- a/libavfilter/vf_hwdownload.c
+++ b/libavfilter/vf_hwdownload.c
@@ -37,26 +37,13 @@ typedef struct HWDownloadContext {
static int hwdownload_query_formats(AVFilterContext *avctx)
{
-AVFilterFormats *infmts = NULL;
-AVFilterFormats *outfmts = NULL;
-const AVPixFmtDescriptor *desc;
+AVFilterFormats *fmts;
int err;
-for (desc = av_pix_fmt_desc_next(NULL); desc;
- desc = av_pix_fmt_desc_next(desc)) {
-if (desc->flags & AV_PIX_FMT_FLAG_HWACCEL)
-err = ff_add_format(&infmts, av_pix_fmt_desc_get_id(desc));
-else
-err = ff_add_format(&outfmts, av_pix_fmt_desc_get_id(desc));
-if (err) {
-ff_formats_unref(&infmts);
-ff_formats_unref(&outfmts);
-return err;
-}
-}
-
-if ((err = ff_formats_ref(infmts, &avctx->inputs[0]->out_formats)) < 0 ||
-(err = ff_formats_ref(outfmts, &avctx->outputs[0]->in_formats)) < 0)
+if ((err = ff_formats_pixdesc_filter(&fmts, AV_PIX_FMT_FLAG_HWACCEL, 0)) ||
+(err = ff_formats_ref(fmts, &avctx->inputs[0]->out_formats)) ||
+(err = ff_formats_pixdesc_filter(&fmts, 0, AV_PIX_FMT_FLAG_HWACCEL)) ||
+(err = ff_formats_ref(fmts, &avctx->outputs[0]->in_formats)))
return err;
return 0;
--
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] fate: add fate-sub-dvb test
On Fri, Aug 21, 2020 at 06:24:58PM +0200, Alexander Strasser wrote: > On 2020-08-21 14:32 +0200, Clément Bœsch wrote: > > On Tue, Aug 18, 2020 at 11:43:29PM +0200, Michael Niedermayer wrote: > > > On Tue, Aug 18, 2020 at 10:45:50PM +0200, Clément Bœsch wrote: > > > > On Tue, Aug 11, 2020 at 02:19:01PM +0200, Clément Bœsch wrote: > > > > [...] > > > > > +FATE_SUBTITLES-$(call ALLYES, MPEGTS_DEMUXER DVBSUB_DECODER > > > > > DVBSUB_ENCODER) += fate-sub-dvb > > > > > +fate-sub-dvb: CMD = framecrc -i > > > > > $(TARGET_SAMPLES)/sub/dvbsubtest_filter.ts -map s:0 -c dvbsub > > > > > > > > Can someone upload that sample¹ to fate-samples/sub/dvbsubtest_filter.ts > > > > so we can apply this patch now that JEEB fixed MPEG-TS DVB demuxing? > > > > > > > > [1]: > > > > https://trac.ffmpeg.org/raw-attachment/ticket/8844/dvbsubtest_filter.ts > > > > > > Uplaod requests are best sent to or CC-ed to samples-requ...@ffmpeg.org > > > (already added to CC) > > > > > > > ping > > > > I'm waiting for this to push a bunch of DVB patches because I want the > > FATE test first. > > Uploaded into sub/dvbsubtest_filter.ts : > > 93ad6d0be649bb29697275ff522a983d475a1e58ab070271f912b86799e04a86 > dvbsubtest_filter.ts > Thanks, will push the patch tomorrow, along with the other DVB sub cleanups from the other thread. [...] Regards, -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user plugin since libmfx 1.28
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Friday, August 21, 2020 9:45 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user plugin
> since libmfx 1.28
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Xiang, Haihao
> > Sent: Friday, August 21, 2020 9:29 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user
> > plugin since libmfx 1.28
> >
> > On Fri, 2020-08-21 at 05:48 +, Soft Works wrote:
> > > > -Original Message-
> > > > From: ffmpeg-devel On Behalf
> Of
> > > > Haihao Xiang
> > > > Sent: Friday, August 21, 2020 7:23 AM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Cc: Haihao Xiang
> > > > Subject: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user
> > > > plugin since libmfx 1.28
> > > >
> > > > MFXVideoUSER_Load call is redundant since libmfx 1.28
> > > > ---
> > > > Fixed merge conflict when applying this patch by 'git am'
> > > >
> > > > libavcodec/qsv.c | 9 -
> > > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index
> > > > 17720070f1..56a30ad642 100644
> > > > --- a/libavcodec/qsv.c
> > > > +++ b/libavcodec/qsv.c
> > > > @@ -19,7 +19,6 @@
> > > > */
> > > >
> > > > #include
> > > > -#include
> > > > #include
> > > >
> > > > #include
> > > > @@ -36,6 +35,10 @@
> > > > #include "avcodec.h"
> > > > #include "qsv_internal.h"
> > > >
> > > > +#if !QSV_VERSION_ATLEAST(1, 28)
> > > > +#include
> > > > +#endif
> > > > +
> > > > #if QSV_VERSION_ATLEAST(1, 12)
> > > > #include "mfx/mfxvp8.h"
> > > > #endif
> > > > @@ -295,6 +298,9 @@ enum AVPictureType ff_qsv_map_pictype(int
> > > > mfx_pic_type) static int qsv_load_plugins(mfxSession session,
> > > > const char *load_plugins,
> > > > void *logctx) {
> > > > +#if QSV_VERSION_ATLEAST(1, 28)
> > > > +return 0;
> > > > +#else
> > > > if (!load_plugins || !*load_plugins)
> > > > return 0;
> > > >
> > > > @@ -340,6 +346,7 @@ load_plugin_fail:
> > > > }
> > > >
> > > > return 0;
> > > > +#endif
> > > >
> > > > }
> > >
> > >
> > > Hi,
> > >
> > > Are you sure this check is right? You are checking the libmfx
> > > version against which ffmpeg is compiled.
> > >
> > > What happens, when a graphics driver supports only API level 1.21?
> > >
> >
> > I understand your concern, however lots of features in FFmpeg are
> > disabled/enabled against api version at compile-time.
>
> That is in no way an argument to break compatibility with downlevel drivers
> without any need. Things are working fine without that patch for all API
> versions.
>
> If you really want to avoid the plugin-load, then you should check the
> driver's
> API level at runtime.
Haihao,
let me add a few more points to this subject:
- Backwards-Compatibility is a key feature of the Intel Media SDK
Your colleagues which are doing the MSDK development are continuously
taking care to make that possible
- When you look at the latest release notes (MSDK 2020 R1, API 1.32),
you can see that 3rd, 4th and 5th gen CPUs are still supported
The latest 3rd gen drivers are API level 1.11
The latest 4th and 5th gen drivers are API level 1.20
Also later CPUs do not always have the latest drivers (> 1.28) installed
- Even with libmfx 1.32, it is still possible to use those CPUs or older
driver versions, and that applies to ffmpeg as well, when it's compiled
against libmfx 1.32
- Your change would only be legitimate if there would have been a change
In the dispatcher code since API 1.28 that would automatically handle the
Plugin loading for drivers < 1.28.
But I have just gone through the recent changes to the dispatcher code
And there doesn't exist such functionality.
- For those reasons, your commit is not acceptable as it would break
HEVC encoding for all 3,4,5 gen CPUs and later CPUs with downlevel
Drivers
What remains is the question whether there's any benefit at all in
Avoiding the plugin load call.
Does it cost time in cases when it would not be needed (driver level >= 1.28)?
- If yes, then the driver API level can be checked at runtime to avoid the
Plugin load.
- Otherwise, I can't imagine any reason to make any change at all
What are yours?
Kind regards,
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Documentation: proposed changes in the structure
On Fri, Aug 21, 2020 at 02:35:38PM +0200, Nicolas George wrote: > 1. What would you think about putting the documentation for >libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi instead >of into huge doc/filters.texi (25k lines!)? And same for codecs, >formats, etc. > >We can adopt this for new documentation and move progressively >existing components. The split is probably not a bad idea, but can we discuss having the documentation within the C code to prevent duplication/redundancy? We could write a tool to generate the documentation file, or maybe part of it for a start (the options). Having to document twice leads to many inconsistencies. > 2. What would you think about switching from texinfo to a small basic >subset of HTML for new documentation? > >I think most of us are much more familiar with HTML syntax than with >texinfo. Anything but HTML please... It's verbose, there are many different versions, and it's too lax IMO (capitalized tags or not? do you use ending slashes for single tags? what are all the indentation rules? ...) > > > 3. What would you think about using pandoc for processing the >documentation? > Pandoc is great, but it has a haskell dependency, it's actually a pretty huge distribution. It's not yet to the level of a LaTeX distribution, but it's still pretty large; here it's about 240M with all its dependencies. [...] -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Documentation: proposed changes in the structure
On Fri, Aug 21, 2020 at 09:42:57PM +0200, Oneric wrote: > On Fri, Aug 21, 2020 at 14:46:53 +0200, Timo Rothenpieler wrote: > > Something like Markdown would come to mind. It should have all formatting > > tools one needs for documentation. > > Imho ReStructuredText would be better suited for documentation than Markdown, > while being similarly "text-like". > Unlike Markdown, RST has a clear spec, supports automatic table of contents > and citations etc. While this might be a matter of preference, RST's tables > and hyperlinks are also better than Markdown's imho. Markdown has a spec: https://spec.commonmark.org/ But you are correct that there are as many flavour as there are implementations in practice. [...] Regards, -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: add RPZA encoder
On 8/21/20, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > Changelog | 1 + > doc/general.texi | 2 +- > libavcodec/Makefile| 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/rpzaenc.c | 860 + > libavcodec/version.h | 2 +- > 6 files changed, 865 insertions(+), 2 deletions(-) > create mode 100644 libavcodec/rpzaenc.c Sent because of request on irc, gonna push little improved patch soon. ___ ffmpeg-devel 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] Documentation: proposed changes in the structure
On Fri, Aug 21, 2020 at 14:46:53 +0200, Timo Rothenpieler wrote: > Something like Markdown would come to mind. It should have all formatting > tools one needs for documentation. Imho ReStructuredText would be better suited for documentation than Markdown, while being similarly "text-like". Unlike Markdown, RST has a clear spec, supports automatic table of contents and citations etc. While this might be a matter of preference, RST's tables and hyperlinks are also better than Markdown's imho. I don't know how RST compares to texinfo though. Current users of RST are Python and the Linux Kernel among others. As for rendering support: Rendering RST is supported by GitHub and afaik also GitLab. Gitea can support rendering rst, but it needs an external renderer and a bit of configuration. (I'm mostly following the ML (-or some parts of it at least-) out of interest; if you decide on Markdown that's fine by me. I just thought it might be worth to point out RST as an option.) ___ ffmpeg-devel 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: add RPZA encoder
Signed-off-by: Paul B Mahol
---
Changelog | 1 +
doc/general.texi | 2 +-
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/rpzaenc.c | 860 +
libavcodec/version.h | 2 +-
6 files changed, 865 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/rpzaenc.c
diff --git a/Changelog b/Changelog
index 1efc768387..7467e73306 100644
--- a/Changelog
+++ b/Changelog
@@ -14,6 +14,7 @@ version :
- ADPCM Argonaut Games encoder
- Argonaut Games ASF muxer
- AV1 Low overhead bitstream format demuxer
+- RPZA video encoder
version 4.3:
diff --git a/doc/general.texi b/doc/general.texi
index fac5377504..d618565347 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1008,7 +1008,7 @@ following image formats are supported:
@tab fourcc: 'rle '
@item QuickTime Graphics (SMC) @tab @tab X
@tab fourcc: 'smc '
-@item QuickTime video (RPZA) @tab @tab X
+@item QuickTime video (RPZA) @tab X @tab X
@tab fourcc: rpza
@item R10K AJA Kona 10-bit RGB Codec @tab X @tab X
@item R210 Quicktime Uncompressed RGB 10-bit @tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a770198475..c72f21d915 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -580,6 +580,7 @@ OBJS-$(CONFIG_ROQ_ENCODER) += roqvideoenc.o
roqvideo.o elbg.o
OBJS-$(CONFIG_ROQ_DPCM_DECODER)+= dpcm.o
OBJS-$(CONFIG_ROQ_DPCM_ENCODER)+= roqaudioenc.o
OBJS-$(CONFIG_RPZA_DECODER)+= rpza.o
+OBJS-$(CONFIG_RPZA_ENCODER)+= rpzaenc.o
OBJS-$(CONFIG_RSCC_DECODER)+= rscc.o
OBJS-$(CONFIG_RV10_DECODER)+= rv10.o
OBJS-$(CONFIG_RV10_ENCODER)+= rv10enc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 4bd830e5d0..729d2fd9ad 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -267,6 +267,7 @@ extern AVCodec ff_rawvideo_decoder;
extern AVCodec ff_rl2_decoder;
extern AVCodec ff_roq_encoder;
extern AVCodec ff_roq_decoder;
+extern AVCodec ff_rpza_encoder;
extern AVCodec ff_rpza_decoder;
extern AVCodec ff_rscc_decoder;
extern AVCodec ff_rv10_encoder;
diff --git a/libavcodec/rpzaenc.c b/libavcodec/rpzaenc.c
new file mode 100644
index 00..de0517a16b
--- /dev/null
+++ b/libavcodec/rpzaenc.c
@@ -0,0 +1,860 @@
+/*
+ * QuickTime RPZA Video Encoder
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file rpzaenc.c
+ * QT RPZA Video Encoder by Todd Kirby and David Adler
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+
+#include "avcodec.h"
+#include "internal.h"
+#include "put_bits.h"
+
+typedef struct RpzaContext {
+AVClass *avclass;
+
+int skip_frame_thresh;
+int start_one_color_thresh;
+int continue_one_color_thresh;
+int sixteen_color_thresh;
+
+AVFrame *prev_frame;// buffer for previous source frame
+PutBitContext pb; // buffer for encoded frame data.
+
+int frame_width;// width in pixels of source frame
+int frame_height; // height in pixesl of source frame
+
+int first_frame;// flag set to one when the first frame is being
processed
+// so that comparisons with previous frame data in
not attempted
+} RpzaContext;
+
+typedef enum channel_offset {
+RED = 2,
+GREEN = 1,
+BLUE = 0,
+} channel_offset;
+
+typedef struct rgb {
+uint8_t r;
+uint8_t g;
+uint8_t b;
+} rgb;
+
+#define SQR(x) ((x) * (x))
+
+/* 15 bit components */
+#define GET_CHAN(color, chan) ((color) >> ((chan) * 5) & 0x1F)
+#define R(color) GET_CHAN(color, RED)
+#define G(color) GET_CHAN(color, GREEN)
+#define B(color) GET_CHAN(color, BLUE)
+
+typedef struct BlockInfo {
+int row;
+int col;
+int block_width;
+int block_height;
+int image_width;
+int image_height;
+int block_index;
+uint16_t start;
+int rowstride;
+int blocks_per_row;
+int total_blocks;
+} BlockInfo;
+
+static void get_colors(uint8_t *min, uint8_t *max, uint8_t color4[4][3])
+{
+uint8_t step;
+
+color4[0][0] = min[0];
+color4[0][1] = min[1];
+color4[0][2] = min[2];
+
+color4[3][0] = max[0]
Re: [FFmpeg-devel] [PATCH] avcodec/proresenc: add support for PQ and HLG
On Thu, Aug 20, 2020 at 10:45 AM Michael Bradshaw
wrote:
> On Wed, Aug 19, 2020 at 9:23 PM zhilizhao wrote:
>
>> > -static const int valid_trc[4]= { AVCOL_TRC_RESERVED0,
>> AVCOL_TRC_BT709, AVCOL_TRC_UNSPECIFIED, INT_MAX };
>> > +static const int valid_trc[6]= { AVCOL_TRC_RESERVED0,
>> AVCOL_TRC_BT709, AVCOL_TRC_UNSPECIFIED, AVCOL_TRC_SMPTE2084,
>> > + AVCOL_TRC_ARIB_STD_B67,
>> INT_MAX };
>>
>> For future-proof, how about remove the array size?
>
>
> Sure, but maybe as a follow-up patch? I'd like to remove the array size
> from all of the arrays, but I don't want this particular patch to grow
> beyond its original scope.
>
Pushed this patch. I sent out another patch to remove the array size and
instead infer it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/proresenc: infer array lengths
Signed-off-by: Michael Bradshaw
---
libavcodec/proresenc_anatoliy.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
index 1128978330..d1623e142c 100644
--- a/libavcodec/proresenc_anatoliy.c
+++ b/libavcodec/proresenc_anatoliy.c
@@ -49,15 +49,15 @@ static const AVProfile profiles[] = {
{ FF_PROFILE_UNKNOWN }
};
-static const int qp_start_table[6] = { 8, 3, 2, 1, 1, 1};
-static const int qp_end_table[6] = { 13, 9, 6, 6, 5, 4};
-static const int bitrate_table[6] = { 1000, 2100, 3500, 5400, 7000, 1};
-
-static const int valid_primaries[9] = { AVCOL_PRI_RESERVED0, AVCOL_PRI_BT709,
AVCOL_PRI_UNSPECIFIED, AVCOL_PRI_BT470BG,
- AVCOL_PRI_SMPTE170M,
AVCOL_PRI_BT2020, AVCOL_PRI_SMPTE431, AVCOL_PRI_SMPTE432,INT_MAX };
-static const int valid_trc[4]= { AVCOL_TRC_RESERVED0, AVCOL_TRC_BT709,
AVCOL_TRC_UNSPECIFIED, INT_MAX };
-static const int valid_colorspace[5] = { AVCOL_SPC_BT709,
AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_SMPTE170M,
- AVCOL_SPC_BT2020_NCL, INT_MAX };
+static const int qp_start_table[] = { 8, 3, 2, 1, 1, 1};
+static const int qp_end_table[] = { 13, 9, 6, 6, 5, 4};
+static const int bitrate_table[] = { 1000, 2100, 3500, 5400, 7000, 1};
+
+static const int valid_primaries[] = { AVCOL_PRI_RESERVED0, AVCOL_PRI_BT709,
AVCOL_PRI_UNSPECIFIED, AVCOL_PRI_BT470BG,
+AVCOL_PRI_SMPTE170M, AVCOL_PRI_BT2020,
AVCOL_PRI_SMPTE431, AVCOL_PRI_SMPTE432, INT_MAX };
+static const int valid_trc[]= { AVCOL_TRC_RESERVED0, AVCOL_TRC_BT709,
AVCOL_TRC_UNSPECIFIED, INT_MAX };
+static const int valid_colorspace[] = { AVCOL_SPC_BT709,
AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_SMPTE170M,
+AVCOL_SPC_BT2020_NCL, INT_MAX };
static const uint8_t QMAT_LUMA[6][64] = {
{
--
2.28.0.297.g1956fa8f8d-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add av1 hardware acceleration decoder
On 8/21/2020 2:05 PM, Derek Buitenhuis wrote: > On 21/08/2020 16:00, James Almer wrote: >> If you actually look at the patch, you'll notice that this is basically >> the template of what eventually will become the native decoder, that for >> now only includes the high level bitstream parsing and the hwaccel hooks >> (And thus will only output frames if one is plugged in). So the names >> are fine. > > Isn't there overlap with the parser here (global motion params)? cbs_av1 parses global motion params, yes. I'm not sure why this decoder attempts to do it too, but it acknowledges the fact it's also done by CBS. Maybe Fei Wang can explain why the duplication. The cbs_av1 gm params parsing code should be fixed, in any case. > > - Derek > ___ > ffmpeg-devel 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] Documentation: proposed changes in the structure
Timo Rothenpieler (12020-08-21):
> That seems long overdue to me.
> The current approach to documentation has become very hard to properly
> maintain.
This seems to get some approval.
I think it would probably not be very hard to convert existing
components in bulk.
I'll see if I can wrangle some perl.
> Something like Markdown would come to mind. It should have all formatting
> tools one needs for documentation.
There seem to be unanimity for Markdown, which is an excellent choice
too.
Markdown does not seem to have built-in syntax for @var{} / or
@samp{} / or @opt{}, but this small loss of precision is probably
acceptable, or we can consider using inline HTML. To be decided later.
> Not really any strong opinion there. It'd increase the size of the binaries,
> but if its compressed not by a whole lot, and I can see it being useful
> specially for CLI users.
I do not think compression would be a good idea. It would reside mostly
in the .rodata section of the binary, using up space on disk which
almost nobody worries about, and being loaded into memory only on
demand. Compression would be more complex, and could end up costing more
memory in practice. But again, to be decided later.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add av1 hardware acceleration decoder
On 21/08/2020 16:00, James Almer wrote: > If you actually look at the patch, you'll notice that this is basically > the template of what eventually will become the native decoder, that for > now only includes the high level bitstream parsing and the hwaccel hooks > (And thus will only output frames if one is plugged in). So the names > are fine. Isn't there overlap with the parser here (global motion params)? - Derek ___ ffmpeg-devel 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: write the colr atom by default
On Wed, Aug 19, 2020 at 2:19 PM Paul B Mahol wrote: > On 8/19/20, Michael Bradshaw wrote: > > I completely forgot about this patch. If no one objects over the next few > > days I plan on pushing this. FATE still passes. > > Fine by me. Thanks. Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add av1 hardware acceleration decoder
On Fri, Aug 21, 2020 at 4:43 PM James Almer wrote:
> > +s->tile_num =
> > +raw_frame_header->tile_cols * raw_frame_header->tile_rows;
> > +tile_group_offset = raw_tile_group->tile_data.data - pkt->data;
> > +get_tiles_info(avctx, raw_tile_group, tile_group_offset);
> > +
> > +ret = get_current_frame(avctx);
> > +if (ret < 0) {
> > +av_log(avctx, AV_LOG_DEBUG, "Get current frame
> > error:%d.\n",
> > + ret);
> > +goto end;
> > +}
> > +if (avctx->hwaccel) {
> > +ret = avctx->hwaccel->decode_slice(avctx, pkt->data,
> > pkt->size);
>
> Can't you pass raw_tile_group->tile_data.data or something less broad
> than the entire packet?
>
This should match whatever the most common hwaccel APIs want, that
said decode_slice should usually take actual slice/tile data, while
start_frame can be passed an entire packet. Thats how other APIs
currently work.
DXVA2 AV1 takes tile data, so I would assume that VAAPI does as well..
In fact, looking at the VAAPI AV1 mappings in the other patch, it
takes that packet and then breaks it apart into tiles. Ideally that
should be handled in the decoder and tiles passed to decode_slice
ready for the hardware.
- Hendrik
___
ffmpeg-devel 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] Documentation: proposed changes in the structure
On 2020-08-21 14:35 +0200, Nicolas George wrote: > 1. What would you think about putting the documentation for >libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi instead >of into huge doc/filters.texi (25k lines!)? And same for codecs, >formats, etc. > >We can adopt this for new documentation and move progressively >existing components. IMHO it's the right thing to do. > 2. What would you think about switching from texinfo to a small basic >subset of HTML for new documentation? > >I think most of us are much more familiar with HTML syntax than with >texinfo. I would prefer Markdown or similar text like formats. Writing HTML by hand isn't so nice and reading the source is also a bit harder because of the tag syntax. > 3. What would you think about using pandoc for processing the >documentation? Would be an option. My experience withe pandoc is a bit dated, but it was working fine back then. IIRC the major advantage is, that it supports many output formats. When we have settled on a source format, we could maybe compare some alternatives. > 4. What would you think about including the documentation for components >into the libraries? It would allow GUI applications to present it in >dialog boxes, like spreadsheets do with their math functions. > > > (4 certainly depends on 2, because texinfo is nos suited for that use; > and probably in part on 1.) If we can efficiently embed it, that would cool. Even for CLI apps too. Alexander ___ ffmpeg-devel 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] Documentation: proposed changes in the structure
On 2020-08-21 15:02 +0200, Jean-Baptiste Kempf wrote: > > > On Fri, 21 Aug 2020, at 14:35, Nicolas George wrote: > > 2. What would you think about switching from texinfo to a small basic > >subset of HTML for new documentation? > > > >I think most of us are much more familiar with HTML syntax than with > >texinfo. > > Use Markdown. > It's defined, spec'd and used in all OSS projects. It's supported by most > editors and most source repositories. It's specs are ambiguous and thus there is a wide range of differing behavior in the numerous implementations. So if we decide for Markdown it might make sense to document which spec to follow or which things not to do. Also documenting which extensions are allowed if any, would be a good thing. Otherwise I have had good experience with Markdown. I wrote almost all documents, that needed more than plain text in Markdown for the last 2 years. Indeed it is widely supported by web source-code browsers, which is a nice bonus to also get rendered documents while browsing the source tree online. Alexander ___ ffmpeg-devel 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/libaomdec: Set SAR based on RenderWidth and RenderHeight
On 8/21/2020 12:29 PM, Derek Buitenhuis wrote: > This is the same thing we do in libdav1d.c > > Signed-off-by: Derek Buitenhuis > --- > libavcodec/libaomdec.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c > index a72ac984e7..1b0f35936e 100644 > --- a/libavcodec/libaomdec.c > +++ b/libavcodec/libaomdec.c > @@ -197,6 +197,13 @@ static int aom_decode(AVCodecContext *avctx, void *data, > int *got_frame, > } > if ((ret = ff_get_buffer(avctx, picture, 0)) < 0) > return ret; > + > +av_reduce(&picture->sample_aspect_ratio.num, > + &picture->sample_aspect_ratio.den, > + picture->height * img->r_w, > + picture->width * img->r_h, > + INT_MAX); Should probably also add a ff_set_sar(avctx, picture->sample_aspect_ratio) call after this. I'll do the same for libdav1d. LGTM in any case. > + > if ((img->fmt & AOM_IMG_FMT_HIGHBITDEPTH) && img->bit_depth == 8) > image_copy_16_to_8(picture, img); > else > ___ ffmpeg-devel 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: add fate-sub-dvb test
On 2020-08-21 14:32 +0200, Clément Bœsch wrote: > On Tue, Aug 18, 2020 at 11:43:29PM +0200, Michael Niedermayer wrote: > > On Tue, Aug 18, 2020 at 10:45:50PM +0200, Clément Bœsch wrote: > > > On Tue, Aug 11, 2020 at 02:19:01PM +0200, Clément Bœsch wrote: > > > [...] > > > > +FATE_SUBTITLES-$(call ALLYES, MPEGTS_DEMUXER DVBSUB_DECODER > > > > DVBSUB_ENCODER) += fate-sub-dvb > > > > +fate-sub-dvb: CMD = framecrc -i > > > > $(TARGET_SAMPLES)/sub/dvbsubtest_filter.ts -map s:0 -c dvbsub > > > > > > Can someone upload that sample¹ to fate-samples/sub/dvbsubtest_filter.ts > > > so we can apply this patch now that JEEB fixed MPEG-TS DVB demuxing? > > > > > > [1]: > > > https://trac.ffmpeg.org/raw-attachment/ticket/8844/dvbsubtest_filter.ts > > > > Uplaod requests are best sent to or CC-ed to samples-requ...@ffmpeg.org > > (already added to CC) > > > > ping > > I'm waiting for this to push a bunch of DVB patches because I want the > FATE test first. Uploaded into sub/dvbsubtest_filter.ts : 93ad6d0be649bb29697275ff522a983d475a1e58ab070271f912b86799e04a86 dvbsubtest_filter.ts Hope it's fine. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/audio: Remove unused array, move used-only-once array
Andreas Rheinhardt (12020-08-21): > ff_planar_sample_fmts_array is unused (and was unused since it was added > in 4d4098da009c8340997b8d1abedbf2062e4aa991) and therefore this commit > removes it; ff_packed_sample_fmts_array meanwhile is used only once (in > the amerge filter) and therefore it has been moved to this place. > > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/af_amerge.c | 10 +- > libavfilter/audio.h | 18 -- > 2 files changed, 9 insertions(+), 19 deletions(-) LGTM to both, thanks. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/libaomdec: Set SAR based on RenderWidth and RenderHeight
This is the same thing we do in libdav1d.c Signed-off-by: Derek Buitenhuis --- libavcodec/libaomdec.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c index a72ac984e7..1b0f35936e 100644 --- a/libavcodec/libaomdec.c +++ b/libavcodec/libaomdec.c @@ -197,6 +197,13 @@ static int aom_decode(AVCodecContext *avctx, void *data, int *got_frame, } if ((ret = ff_get_buffer(avctx, picture, 0)) < 0) return ret; + +av_reduce(&picture->sample_aspect_ratio.num, + &picture->sample_aspect_ratio.den, + picture->height * img->r_w, + picture->width * img->r_h, + INT_MAX); + if ((img->fmt & AOM_IMG_FMT_HIGHBITDEPTH) && img->bit_depth == 8) image_copy_16_to_8(picture, img); else -- 2.28.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add av1 hardware acceleration decoder
On 8/21/2020 11:47 AM, Paul B Mahol wrote: > On 8/21/20, Fei Wang wrote: >> This av1 decoder is now only used for av1 hardware acceleration >> decoder. Consider it can be extend to a local decoder like hevc >> or vp9 in the future, so define its name as "av1" and put it into >> external libraries codec list. >> >> Signed-off-by: Fei Wang >> --- >> Changelog | 1 + >> configure | 1 + >> libavcodec/Makefile| 1 + >> libavcodec/allcodecs.c | 1 + >> libavcodec/av1dec.c| 746 + >> libavcodec/av1dec.h| 89 + > Sorry but those names are reserved for real native AV1 decoder. If you actually look at the patch, you'll notice that this is basically the template of what eventually will become the native decoder, that for now only includes the high level bitstream parsing and the hwaccel hooks (And thus will only output frames if one is plugged in). So the names are fine. ___ ffmpeg-devel 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] dnn_backend_native_layer_avgpool: Fix invalid assignment, use av_assert
Guo, Yejun:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Andreas Rheinhardt
>> Sent: 2020年8月21日 22:21
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH] dnn_backend_native_layer_avgpool: Fix
>> invalid assignment, use av_assert
>>
>> Guo, Yejun:
>>>
>>>
-Original Message-
From: ffmpeg-devel On Behalf Of
Andreas Rheinhardt
Sent: 2020年8月21日 19:47
To: ffmpeg-devel@ffmpeg.org
Cc: Andreas Rheinhardt
Subject: [FFmpeg-devel] [PATCH] dnn_backend_native_layer_avgpool: Fix
invalid assignment, use av_assert
dnn_execute_layer_avg_pool() contains the following line:
assert(avgpool_params->padding_method = VALID);
This statement contains an assignment where obviously a comparison
was intended. Furthermore, *avgpool_params is const, so that the
attempted assignment leads to a compilation failure if asserts are
enabled (i.e. if DEBUG is defined which leads libavutil/internal.h to
not define NDEBUG). Moreover, the enumeration constant VALID actually
has the value 0, so that the assert would be triggered if a compiler
compiles this with asserts enabled. Finally, the statement uses assert()
>> directly instead of av_assert*().
All these errors have been fixed.
Thanks to ubitux for providing a FATE-box [1] where DEBUG is defined.
[1]:
http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-ddebug
Signed-off-by: Andreas Rheinhardt
---
I was unsure which assert level to use and therefore simply opted for 0.
libavfilter/dnn/dnn_backend_native_layer_avgpool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
b/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
index d745c35b4a..8d4d8db98c 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
@@ -91,7 +91,7 @@ int dnn_execute_layer_avg_pool(DnnOperand
*operands, const int32_t *input_operan
output_height = ceil(height / (kernel_strides * 1.0));
output_width = ceil(width / (kernel_strides * 1.0));
} else {
-assert(avgpool_params->padding_method = VALID);
+av_assert0(avgpool_params->padding_method == VALID);
height_end = height - avgpool_params->kernel_size + 1;
width_end = width - avgpool_params->kernel_size + 1;
height_radius = 0;
>>>
>>> thanks for the patch, will push now.
>>
>> I actually push my patches myself. Too late now.
>>
>
> sure, no problem for the push.
>
> Just found that my push command works, so I checked the repo at
> https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/128e6df1cd79076e3d5f51bbc88607b3d1c62689,
> looks that your push does not work for some reason. just fyi.
I had no problem with my push; it's just that you had already pushed
before I realized your approval and then it was of course too late (so I
never attempted to push this). But as has already been said: Too late now.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 1/3] [RFC] lavc: add FLIF decoding support
On 8/20/20, Anamitra Ghorui wrote: > Hello, > > On Wed, 19 Aug 2020 21:05:41 +0200 > Paul B Mahol wrote: > > [...] > >> > >> > >> > All these corrections have been made by me locally, but I would >> > like to wait for some further review (self and otherwise) before >> > posting again. >> >> Please make use of av_clip and FFMIN/FFMAX macros. >> > > We have looked through the code again and have not been able to notice a > situation where these macros will be required aside from where they are > already used. They have been largely used in the transform code and > sparsely used everywhere else. Can you please point to a portion where > their use is warranted? ff_bound_snap. Also av_freep() is inconsistently used in code. You do not need to check for NULL, prior to calling it. > > Thanks, > Anamitra > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add av1 hardware acceleration decoder
On 8/21/20, Fei Wang wrote:
> This av1 decoder is now only used for av1 hardware acceleration
> decoder. Consider it can be extend to a local decoder like hevc
> or vp9 in the future, so define its name as "av1" and put it into
> external libraries codec list.
>
> Signed-off-by: Fei Wang
> ---
> Changelog | 1 +
> configure | 1 +
> libavcodec/Makefile| 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/av1dec.c| 746 +
> libavcodec/av1dec.h| 89 +
Sorry but those names are reserved for real native AV1 decoder.
> libavcodec/version.h | 2 +-
> 7 files changed, 840 insertions(+), 1 deletion(-)
> create mode 100644 libavcodec/av1dec.c
> create mode 100644 libavcodec/av1dec.h
>
> diff --git a/Changelog b/Changelog
> index 1efc768387..3ff88cc12f 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -14,6 +14,7 @@ version :
> - ADPCM Argonaut Games encoder
> - Argonaut Games ASF muxer
> - AV1 Low overhead bitstream format demuxer
> +- AV1 decoder (Hardware acceleration used only)
>
>
> version 4.3:
> diff --git a/configure b/configure
> index 6faff9bc7b..ef71e47c4e 100755
> --- a/configure
> +++ b/configure
> @@ -2685,6 +2685,7 @@ atrac3al_decoder_select="mdct"
> atrac3p_decoder_select="mdct sinewin"
> atrac3pal_decoder_select="mdct sinewin"
> atrac9_decoder_select="mdct"
> +av1_decoder_select="cbs_av1"
> avrn_decoder_select="exif jpegtables"
> bink_decoder_select="blockdsp hpeldsp"
> binkaudio_dct_decoder_select="mdct rdft dct sinewin wma_freqs"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 3431ba2dca..2371039bd2 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -764,6 +764,7 @@ OBJS-$(CONFIG_ZLIB_DECODER)+= lcldec.o
> OBJS-$(CONFIG_ZLIB_ENCODER)+= lclenc.o
> OBJS-$(CONFIG_ZMBV_DECODER)+= zmbv.o
> OBJS-$(CONFIG_ZMBV_ENCODER)+= zmbvenc.o
> +OBJS-$(CONFIG_AV1_DECODER) += av1dec.o
>
> # (AD)PCM decoders/encoders
> OBJS-$(CONFIG_PCM_ALAW_DECODER) += pcm.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 4bd830e5d0..00799d3431 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -761,6 +761,7 @@ extern AVCodec ff_idf_decoder;
> * above is available */
> extern AVCodec ff_aac_mf_encoder;
> extern AVCodec ff_ac3_mf_encoder;
> +extern AVCodec ff_av1_decoder;
> extern AVCodec ff_h263_v4l2m2m_encoder;
> extern AVCodec ff_libaom_av1_decoder;
> extern AVCodec ff_libopenh264_encoder;
> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> new file mode 100644
> index 00..ab88ed987a
> --- /dev/null
> +++ b/libavcodec/av1dec.c
> @@ -0,0 +1,746 @@
> +/*
> + * AV1video decoder
> + *
> + * 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 "avcodec.h"
> +#include "get_bits.h"
> +#include "hwconfig.h"
> +#include "internal.h"
> +#include "profiles.h"
> +#include "thread.h"
> +#include "videodsp.h"
> +#include "libavutil/avassert.h"
> +#include "libavutil/pixdesc.h"
> +
> +#include "av1dec.h"
> +#include "libavformat/av1.h"
> +
> +static void setup_past_independence(AV1Frame *f)
> +{
> +f->loop_filter_delta_enabled = 1;
> +
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_INTRA] = 1;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_LAST] = 0;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_LAST2] = 0;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_LAST3] = 0;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_GOLDEN] = -1;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_BWDREF] = 0;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_ALTREF2] = -1;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_ALTREF] = -1;
> +
> +f->loop_filter_mode_deltas[0] = 0;
> +f->loop_filter_mode_deltas[1] = 0;
> +}
> +
> +static void load_previous_and_update(AV1DecContext *s)
> +{
> +int i;
> +
> +memcpy(s->cur_frame.loop_filter_ref_deltas,
> +
> s->ref[s->raw_frame_header.primary_ref_frame].loop_filter_ref_deltas,
> + AV1_TOTAL_REFS_PER_FRAME * sizeof(int8_t));
> +memcpy(s->cur_frame.loop_filter_mode_deltas,
> +
> s->ref[s->raw_frame_header.primary_ref_frame].loop_filter_mode_deltas,
> + 2 * sizeo
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add av1 hardware acceleration decoder
On 8/21/2020 2:29 AM, Fei Wang wrote:
> This av1 decoder is now only used for av1 hardware acceleration
> decoder. Consider it can be extend to a local decoder like hevc
> or vp9 in the future, so define its name as "av1" and put it into
> external libraries codec list.
>
> Signed-off-by: Fei Wang
> ---
> Changelog | 1 +
> configure | 1 +
> libavcodec/Makefile| 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/av1dec.c| 746 +
> libavcodec/av1dec.h| 89 +
> libavcodec/version.h | 2 +-
> 7 files changed, 840 insertions(+), 1 deletion(-)
> create mode 100644 libavcodec/av1dec.c
> create mode 100644 libavcodec/av1dec.h
>
> diff --git a/Changelog b/Changelog
> index 1efc768387..3ff88cc12f 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -14,6 +14,7 @@ version :
> - ADPCM Argonaut Games encoder
> - Argonaut Games ASF muxer
> - AV1 Low overhead bitstream format demuxer
> +- AV1 decoder (Hardware acceleration used only)
>
>
> version 4.3:
> diff --git a/configure b/configure
> index 6faff9bc7b..ef71e47c4e 100755
> --- a/configure
> +++ b/configure
> @@ -2685,6 +2685,7 @@ atrac3al_decoder_select="mdct"
> atrac3p_decoder_select="mdct sinewin"
> atrac3pal_decoder_select="mdct sinewin"
> atrac9_decoder_select="mdct"
> +av1_decoder_select="cbs_av1"
> avrn_decoder_select="exif jpegtables"
> bink_decoder_select="blockdsp hpeldsp"
> binkaudio_dct_decoder_select="mdct rdft dct sinewin wma_freqs"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 3431ba2dca..2371039bd2 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -764,6 +764,7 @@ OBJS-$(CONFIG_ZLIB_DECODER)+= lcldec.o
> OBJS-$(CONFIG_ZLIB_ENCODER)+= lclenc.o
> OBJS-$(CONFIG_ZMBV_DECODER)+= zmbv.o
> OBJS-$(CONFIG_ZMBV_ENCODER)+= zmbvenc.o
> +OBJS-$(CONFIG_AV1_DECODER) += av1dec.o
>
> # (AD)PCM decoders/encoders
> OBJS-$(CONFIG_PCM_ALAW_DECODER) += pcm.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 4bd830e5d0..00799d3431 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -761,6 +761,7 @@ extern AVCodec ff_idf_decoder;
> * above is available */
> extern AVCodec ff_aac_mf_encoder;
> extern AVCodec ff_ac3_mf_encoder;
> +extern AVCodec ff_av1_decoder;
> extern AVCodec ff_h263_v4l2m2m_encoder;
> extern AVCodec ff_libaom_av1_decoder;
> extern AVCodec ff_libopenh264_encoder;
> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> new file mode 100644
> index 00..ab88ed987a
> --- /dev/null
> +++ b/libavcodec/av1dec.c
> @@ -0,0 +1,746 @@
> +/*
> + * AV1video decoder
> + *
> + * 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 "avcodec.h"
> +#include "get_bits.h"
> +#include "hwconfig.h"
> +#include "internal.h"
> +#include "profiles.h"
> +#include "thread.h"
> +#include "videodsp.h"
> +#include "libavutil/avassert.h"
> +#include "libavutil/pixdesc.h"
> +
> +#include "av1dec.h"
> +#include "libavformat/av1.h"
> +
> +static void setup_past_independence(AV1Frame *f)
> +{
> +f->loop_filter_delta_enabled = 1;
> +
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_INTRA] = 1;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_LAST] = 0;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_LAST2] = 0;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_LAST3] = 0;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_GOLDEN] = -1;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_BWDREF] = 0;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_ALTREF2] = -1;
> +f->loop_filter_ref_deltas[AV1_REF_FRAME_ALTREF] = -1;
> +
> +f->loop_filter_mode_deltas[0] = 0;
> +f->loop_filter_mode_deltas[1] = 0;
> +}
> +
> +static void load_previous_and_update(AV1DecContext *s)
> +{
> +int i;
> +
> +memcpy(s->cur_frame.loop_filter_ref_deltas,
> +
> s->ref[s->raw_frame_header.primary_ref_frame].loop_filter_ref_deltas,
> + AV1_TOTAL_REFS_PER_FRAME * sizeof(int8_t));
> +memcpy(s->cur_frame.loop_filter_mode_deltas,
> +
> s->ref[s->raw_frame_header.primary_ref_frame].loop_filter_mode_deltas,
> + 2 * sizeof(int8_t));
> +
> +if
Re: [FFmpeg-devel] [PATCH] dnn_backend_native_layer_avgpool: Fix invalid assignment, use av_assert
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2020年8月21日 22:21
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] dnn_backend_native_layer_avgpool: Fix
> invalid assignment, use av_assert
>
> Guo, Yejun:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: 2020年8月21日 19:47
> >> To: ffmpeg-devel@ffmpeg.org
> >> Cc: Andreas Rheinhardt
> >> Subject: [FFmpeg-devel] [PATCH] dnn_backend_native_layer_avgpool: Fix
> >> invalid assignment, use av_assert
> >>
> >> dnn_execute_layer_avg_pool() contains the following line:
> >>
> >> assert(avgpool_params->padding_method = VALID);
> >>
> >> This statement contains an assignment where obviously a comparison
> >> was intended. Furthermore, *avgpool_params is const, so that the
> >> attempted assignment leads to a compilation failure if asserts are
> >> enabled (i.e. if DEBUG is defined which leads libavutil/internal.h to
> >> not define NDEBUG). Moreover, the enumeration constant VALID actually
> >> has the value 0, so that the assert would be triggered if a compiler
> >> compiles this with asserts enabled. Finally, the statement uses assert()
> directly instead of av_assert*().
> >>
> >> All these errors have been fixed.
> >>
> >> Thanks to ubitux for providing a FATE-box [1] where DEBUG is defined.
> >>
> >> [1]:
> >> http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-ddebug
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> I was unsure which assert level to use and therefore simply opted for 0.
> >>
> >> libavfilter/dnn/dnn_backend_native_layer_avgpool.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
> >> b/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
> >> index d745c35b4a..8d4d8db98c 100644
> >> --- a/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
> >> +++ b/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
> >> @@ -91,7 +91,7 @@ int dnn_execute_layer_avg_pool(DnnOperand
> >> *operands, const int32_t *input_operan
> >> output_height = ceil(height / (kernel_strides * 1.0));
> >> output_width = ceil(width / (kernel_strides * 1.0));
> >> } else {
> >> -assert(avgpool_params->padding_method = VALID);
> >> +av_assert0(avgpool_params->padding_method == VALID);
> >> height_end = height - avgpool_params->kernel_size + 1;
> >> width_end = width - avgpool_params->kernel_size + 1;
> >> height_radius = 0;
> >
> > thanks for the patch, will push now.
>
> I actually push my patches myself. Too late now.
>
sure, no problem for the push.
Just found that my push command works, so I checked the repo at
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/128e6df1cd79076e3d5f51bbc88607b3d1c62689,
looks that your push does not work for some reason. just fyi.
___
ffmpeg-devel 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] dnn_backend_native_layer_avgpool: Fix invalid assignment, use av_assert
Guo, Yejun:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Andreas Rheinhardt
>> Sent: 2020年8月21日 19:47
>> To: ffmpeg-devel@ffmpeg.org
>> Cc: Andreas Rheinhardt
>> Subject: [FFmpeg-devel] [PATCH] dnn_backend_native_layer_avgpool: Fix invalid
>> assignment, use av_assert
>>
>> dnn_execute_layer_avg_pool() contains the following line:
>>
>> assert(avgpool_params->padding_method = VALID);
>>
>> This statement contains an assignment where obviously a comparison was
>> intended. Furthermore, *avgpool_params is const, so that the attempted
>> assignment leads to a compilation failure if asserts are enabled (i.e. if
>> DEBUG is
>> defined which leads libavutil/internal.h to not define NDEBUG). Moreover, the
>> enumeration constant VALID actually has the value 0, so that the assert would
>> be triggered if a compiler compiles this with asserts enabled. Finally, the
>> statement uses assert() directly instead of av_assert*().
>>
>> All these errors have been fixed.
>>
>> Thanks to ubitux for providing a FATE-box [1] where DEBUG is defined.
>>
>> [1]: http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-ddebug
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> I was unsure which assert level to use and therefore simply opted for 0.
>>
>> libavfilter/dnn/dnn_backend_native_layer_avgpool.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
>> b/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
>> index d745c35b4a..8d4d8db98c 100644
>> --- a/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
>> +++ b/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
>> @@ -91,7 +91,7 @@ int dnn_execute_layer_avg_pool(DnnOperand *operands,
>> const int32_t *input_operan
>> output_height = ceil(height / (kernel_strides * 1.0));
>> output_width = ceil(width / (kernel_strides * 1.0));
>> } else {
>> -assert(avgpool_params->padding_method = VALID);
>> +av_assert0(avgpool_params->padding_method == VALID);
>> height_end = height - avgpool_params->kernel_size + 1;
>> width_end = width - avgpool_params->kernel_size + 1;
>> height_radius = 0;
>
> thanks for the patch, will push now.
I actually push my patches myself. Too late now.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] dnn_backend_native_layer_avgpool: Fix invalid assignment, use av_assert
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: 2020年8月21日 19:47
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt
> Subject: [FFmpeg-devel] [PATCH] dnn_backend_native_layer_avgpool: Fix invalid
> assignment, use av_assert
>
> dnn_execute_layer_avg_pool() contains the following line:
>
> assert(avgpool_params->padding_method = VALID);
>
> This statement contains an assignment where obviously a comparison was
> intended. Furthermore, *avgpool_params is const, so that the attempted
> assignment leads to a compilation failure if asserts are enabled (i.e. if
> DEBUG is
> defined which leads libavutil/internal.h to not define NDEBUG). Moreover, the
> enumeration constant VALID actually has the value 0, so that the assert would
> be triggered if a compiler compiles this with asserts enabled. Finally, the
> statement uses assert() directly instead of av_assert*().
>
> All these errors have been fixed.
>
> Thanks to ubitux for providing a FATE-box [1] where DEBUG is defined.
>
> [1]: http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-ddebug
>
> Signed-off-by: Andreas Rheinhardt
> ---
> I was unsure which assert level to use and therefore simply opted for 0.
>
> libavfilter/dnn/dnn_backend_native_layer_avgpool.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
> b/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
> index d745c35b4a..8d4d8db98c 100644
> --- a/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
> +++ b/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
> @@ -91,7 +91,7 @@ int dnn_execute_layer_avg_pool(DnnOperand *operands,
> const int32_t *input_operan
> output_height = ceil(height / (kernel_strides * 1.0));
> output_width = ceil(width / (kernel_strides * 1.0));
> } else {
> -assert(avgpool_params->padding_method = VALID);
> +av_assert0(avgpool_params->padding_method == VALID);
> height_end = height - avgpool_params->kernel_size + 1;
> width_end = width - avgpool_params->kernel_size + 1;
> height_radius = 0;
thanks for the patch, will push now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/audio: Remove unused array, move used-only-once array
On 8/21/20, Andreas Rheinhardt wrote:
> ff_planar_sample_fmts_array is unused (and was unused since it was added
> in 4d4098da009c8340997b8d1abedbf2062e4aa991) and therefore this commit
> removes it; ff_packed_sample_fmts_array meanwhile is used only once (in
> the amerge filter) and therefore it has been moved to this place.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/af_amerge.c | 10 +-
> libavfilter/audio.h | 18 --
> 2 files changed, 9 insertions(+), 19 deletions(-)
>
LGTM, but please wait for others comments.
> diff --git a/libavfilter/af_amerge.c b/libavfilter/af_amerge.c
> index 567f25982d..ca94a224af 100644
> --- a/libavfilter/af_amerge.c
> +++ b/libavfilter/af_amerge.c
> @@ -69,6 +69,14 @@ static av_cold void uninit(AVFilterContext *ctx)
>
> static int query_formats(AVFilterContext *ctx)
> {
> +static const enum AVSampleFormat packed_sample_fmts[] = {
> +AV_SAMPLE_FMT_U8,
> +AV_SAMPLE_FMT_S16,
> +AV_SAMPLE_FMT_S32,
> +AV_SAMPLE_FMT_FLT,
> +AV_SAMPLE_FMT_DBL,
> +AV_SAMPLE_FMT_NONE
> +};
> AMergeContext *s = ctx->priv;
> int64_t inlayout[SWR_CH_MAX], outlayout = 0;
> AVFilterFormats *formats;
> @@ -124,7 +132,7 @@ static int query_formats(AVFilterContext *ctx)
> if ((inlayout[i] >> c) & 1)
> *(route[i]++) = out_ch_number++;
> }
> -formats = ff_make_format_list(ff_packed_sample_fmts_array);
> +formats = ff_make_format_list(packed_sample_fmts);
> if ((ret = ff_set_common_formats(ctx, formats)) < 0)
> return ret;
> for (i = 0; i < s->nb_inputs; i++) {
> diff --git a/libavfilter/audio.h b/libavfilter/audio.h
> index 6adc82dc81..6bbe6ee9ef 100644
> --- a/libavfilter/audio.h
> +++ b/libavfilter/audio.h
> @@ -25,24 +25,6 @@
> #include "avfilter.h"
> #include "internal.h"
>
> -static const enum AVSampleFormat ff_packed_sample_fmts_array[] = {
> -AV_SAMPLE_FMT_U8,
> -AV_SAMPLE_FMT_S16,
> -AV_SAMPLE_FMT_S32,
> -AV_SAMPLE_FMT_FLT,
> -AV_SAMPLE_FMT_DBL,
> -AV_SAMPLE_FMT_NONE
> -};
> -
> -static const enum AVSampleFormat ff_planar_sample_fmts_array[] = {
> -AV_SAMPLE_FMT_U8P,
> -AV_SAMPLE_FMT_S16P,
> -AV_SAMPLE_FMT_S32P,
> -AV_SAMPLE_FMT_FLTP,
> -AV_SAMPLE_FMT_DBLP,
> -AV_SAMPLE_FMT_NONE
> -};
> -
> /** default handler for get_audio_buffer() for audio inputs */
> AVFrame *ff_default_get_audio_buffer(AVFilterLink *link, int nb_samples);
>
> --
> 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".
___
ffmpeg-devel 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] avfilter/audio: Remove unused array, move used-only-once array
ff_planar_sample_fmts_array is unused (and was unused since it was added
in 4d4098da009c8340997b8d1abedbf2062e4aa991) and therefore this commit
removes it; ff_packed_sample_fmts_array meanwhile is used only once (in
the amerge filter) and therefore it has been moved to this place.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/af_amerge.c | 10 +-
libavfilter/audio.h | 18 --
2 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/libavfilter/af_amerge.c b/libavfilter/af_amerge.c
index 567f25982d..ca94a224af 100644
--- a/libavfilter/af_amerge.c
+++ b/libavfilter/af_amerge.c
@@ -69,6 +69,14 @@ static av_cold void uninit(AVFilterContext *ctx)
static int query_formats(AVFilterContext *ctx)
{
+static const enum AVSampleFormat packed_sample_fmts[] = {
+AV_SAMPLE_FMT_U8,
+AV_SAMPLE_FMT_S16,
+AV_SAMPLE_FMT_S32,
+AV_SAMPLE_FMT_FLT,
+AV_SAMPLE_FMT_DBL,
+AV_SAMPLE_FMT_NONE
+};
AMergeContext *s = ctx->priv;
int64_t inlayout[SWR_CH_MAX], outlayout = 0;
AVFilterFormats *formats;
@@ -124,7 +132,7 @@ static int query_formats(AVFilterContext *ctx)
if ((inlayout[i] >> c) & 1)
*(route[i]++) = out_ch_number++;
}
-formats = ff_make_format_list(ff_packed_sample_fmts_array);
+formats = ff_make_format_list(packed_sample_fmts);
if ((ret = ff_set_common_formats(ctx, formats)) < 0)
return ret;
for (i = 0; i < s->nb_inputs; i++) {
diff --git a/libavfilter/audio.h b/libavfilter/audio.h
index 6adc82dc81..6bbe6ee9ef 100644
--- a/libavfilter/audio.h
+++ b/libavfilter/audio.h
@@ -25,24 +25,6 @@
#include "avfilter.h"
#include "internal.h"
-static const enum AVSampleFormat ff_packed_sample_fmts_array[] = {
-AV_SAMPLE_FMT_U8,
-AV_SAMPLE_FMT_S16,
-AV_SAMPLE_FMT_S32,
-AV_SAMPLE_FMT_FLT,
-AV_SAMPLE_FMT_DBL,
-AV_SAMPLE_FMT_NONE
-};
-
-static const enum AVSampleFormat ff_planar_sample_fmts_array[] = {
-AV_SAMPLE_FMT_U8P,
-AV_SAMPLE_FMT_S16P,
-AV_SAMPLE_FMT_S32P,
-AV_SAMPLE_FMT_FLTP,
-AV_SAMPLE_FMT_DBLP,
-AV_SAMPLE_FMT_NONE
-};
-
/** default handler for get_audio_buffer() for audio inputs */
AVFrame *ff_default_get_audio_buffer(AVFilterLink *link, int nb_samples);
--
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".
[FFmpeg-devel] [PATCH 2/2] avfilter/formats: Remove unused functions
This commit removes ff_parse_sample_format(), ff_parse_time_base() and
ff_query_formats_all_layouts() from libavfilter/formats.c. All of these
functions were completely unused. ff_parse_time_base() has not been used
at all since it had been added in 3448404a707b6e236a2ffa7b0453b3300de41b7b;
the last caller of ff_parse_sample_format has been removed in commit
d1c49bcae9b7fd41df5c6804ac7f6a5c271a7c2e. And the one and only caller of
ff_query_formats_all_layouts() (the asyncts filter) has been removed in
commit a8fe8d6b4a35c95aa94fccde5f001041278d197c.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/formats.c | 42 ++
libavfilter/formats.h | 8
libavfilter/internal.h | 22 --
3 files changed, 2 insertions(+), 70 deletions(-)
diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 8918118b8e..d2edf832e9 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -24,7 +24,6 @@
#include "libavutil/common.h"
#include "libavutil/eval.h"
#include "libavutil/pixdesc.h"
-#include "libavutil/parseutils.h"
#include "avfilter.h"
#include "internal.h"
#include "formats.h"
@@ -604,8 +603,7 @@ int ff_set_common_formats(AVFilterContext *ctx,
AVFilterFormats *formats)
ff_formats_ref, ff_formats_unref, formats);
}
-static int default_query_formats_common(AVFilterContext *ctx,
-AVFilterChannelLayouts
*(layouts)(void))
+int ff_default_query_formats(AVFilterContext *ctx)
{
int ret;
enum AVMediaType type = ctx->inputs && ctx->inputs [0] ? ctx->inputs
[0]->type :
@@ -616,7 +614,7 @@ static int default_query_formats_common(AVFilterContext
*ctx,
if (ret < 0)
return ret;
if (type == AVMEDIA_TYPE_AUDIO) {
-ret = ff_set_common_channel_layouts(ctx, layouts());
+ret = ff_set_common_channel_layouts(ctx, ff_all_channel_counts());
if (ret < 0)
return ret;
ret = ff_set_common_samplerates(ctx, ff_all_samplerates());
@@ -627,16 +625,6 @@ static int default_query_formats_common(AVFilterContext
*ctx,
return 0;
}
-int ff_default_query_formats(AVFilterContext *ctx)
-{
-return default_query_formats_common(ctx, ff_all_channel_counts);
-}
-
-int ff_query_formats_all_layouts(AVFilterContext *ctx)
-{
-return default_query_formats_common(ctx, ff_all_channel_layouts);
-}
-
/* internal functions for parsing audio format arguments */
int ff_parse_pixel_format(enum AVPixelFormat *ret, const char *arg, void
*log_ctx)
@@ -654,32 +642,6 @@ int ff_parse_pixel_format(enum AVPixelFormat *ret, const
char *arg, void *log_ct
return 0;
}
-int ff_parse_sample_format(int *ret, const char *arg, void *log_ctx)
-{
-char *tail;
-int sfmt = av_get_sample_fmt(arg);
-if (sfmt == AV_SAMPLE_FMT_NONE) {
-sfmt = strtol(arg, &tail, 0);
-if (*tail || av_get_bytes_per_sample(sfmt)<=0) {
-av_log(log_ctx, AV_LOG_ERROR, "Invalid sample format '%s'\n", arg);
-return AVERROR(EINVAL);
-}
-}
-*ret = sfmt;
-return 0;
-}
-
-int ff_parse_time_base(AVRational *ret, const char *arg, void *log_ctx)
-{
-AVRational r;
-if(av_parse_ratio(&r, arg, INT_MAX, 0, log_ctx) < 0 ||r.num<=0
||r.den<=0) {
-av_log(log_ctx, AV_LOG_ERROR, "Invalid time base '%s'\n", arg);
-return AVERROR(EINVAL);
-}
-*ret = r;
-return 0;
-}
-
int ff_parse_sample_rate(int *ret, const char *arg, void *log_ctx)
{
char *tail;
diff --git a/libavfilter/formats.h b/libavfilter/formats.h
index dd0cbca6d5..a06e88722e 100644
--- a/libavfilter/formats.h
+++ b/libavfilter/formats.h
@@ -202,14 +202,6 @@ void ff_channel_layouts_changeref(AVFilterChannelLayouts
**oldref,
av_warn_unused_result
int ff_default_query_formats(AVFilterContext *ctx);
- /**
- * Set the formats list to all known channel layouts. This function behaves
- * like ff_default_query_formats(), except it only accepts known channel
- * layouts. It should only be used with audio filters.
- */
-av_warn_unused_result
-int ff_query_formats_all_layouts(AVFilterContext *ctx);
-
/**
* Create a list of supported formats. This is intended for use in
* AVFilter->query_formats().
diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index cc208f8e3a..183215d152 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -171,28 +171,6 @@ int ff_parse_pixel_format(enum AVPixelFormat *ret, const
char *arg, void *log_ct
av_warn_unused_result
int ff_parse_sample_rate(int *ret, const char *arg, void *log_ctx);
-/**
- * Parse a time base.
- *
- * @param ret unsigned AVRational pointer to where the value should be written
- * @param arg string to parse
- * @param log_ctx log context
- * @return >= 0 in case of success, a negative AVERROR code on error
- */
-av_warn_unused_result
-int ff_parse_time_base(AVRational *ret, const char *arg, void *log_ctx);
-
-/**
- * Parse a sample
Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: add x86 SIMD
On Fri, Aug 21, 2020 at 15:10:09 +0200, Moritz Barsnick wrote: > Let me add my promised benchmarks. I have nothing modern here (these > CPUs are 10, 18 and 6 years old), but I can confirm the impressive > improvements: > > Intel Atom D525 Intel Pentium 4 Intel Haswell > i5-4200U > > MT_BeartoothHighwavi: 0.489x -> 0.835x 0.23x -> 0.55x 2.13x -> 3.07x > bigger_res.mov: 0.057x -> 0.069x 0.02x -> 0.058x 0.174x -> 0.237x > timelapse-pt-momsapt.avi: 1.11x -> 1.9x0.53x -> 1.37x 4.3x -> 6.2x This is a more modern one, very skewed by running in a VM restricted to 2 CPUs and 95% of the host CPU (yeah, shouldn't do that). But at least the speed-up is shown. Intel Kaby Lake i7-7500U MT_BeartoothHighwavi: 2.0x -> 3.4x bigger_res.mov: 0.21x -> 0.27x timelapse-pt-momsapt.avi: 3.5x -> 6.6x Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Documentation: proposed changes in the structure
On 21-08-2020 06:05 pm, Nicolas George wrote: 1. What would you think about putting the documentation for libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi instead of into huge doc/filters.texi (25k lines!)? And same for codecs, formats, etc. We can adopt this for new documentation and move progressively existing components. Sounds fine. 2. What would you think about switching from texinfo to a small basic subset of HTML for new documentation? I think most of us are much more familiar with HTML syntax than with texinfo. Markdown is preferred. 3. What would you think about using pandoc for processing the documentation? 4. What would you think about including the documentation for components into the libraries? It would allow GUI applications to present it in dialog boxes, like spreadsheets do with their math functions. (4 certainly depends on 2, because texinfo is nos suited for that use; and probably in part on 1.) Another aspect is to preserve version-specific documentation in addition to the version-less (effectively git master) docs that we currently have. It's too much effort to retroactively generate this for past releases, but it can be can be done starting with 4.3 and current major versions of the libs. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V4 2/2] dnn_backend_native_layer_mathbinary: add floormod support
Signed-off-by: Mingyu Yin
---
libavfilter/dnn/dnn_backend_native_layer_mathbinary.c | 7 +++
libavfilter/dnn/dnn_backend_native_layer_mathbinary.h | 1 +
tests/dnn/dnn-layer-mathbinary-test.c | 5 +
tools/python/convert_from_tensorflow.py | 2 +-
tools/python/convert_header.py| 2 +-
5 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
index 4373f82543..439d6f7b4a 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
@@ -50,6 +50,10 @@ static float minimum(float src0, float src1)
{
return FFMIN(src0, src1);
}
+static float floormod(float src0, float src1)
+{
+return (float)((int)(src0) % (int)(src1));
+}
static void math_binary_commutative(FunType pfun, const
DnnLayerMathBinaryParams *params, const DnnOperand *input, DnnOperand *output,
DnnOperand *operands, const int32_t *input_operand_indexes)
{
@@ -181,6 +185,9 @@ int dnn_execute_layer_math_binary(DnnOperand *operands,
const int32_t *input_ope
case DMBO_MINIMUM:
math_binary_commutative(minimum, params, input, output, operands,
input_operand_indexes);
return 0;
+case DMBO_FLOORMOD:
+math_binary_not_commutative(floormod, params, input, output, operands,
input_operand_indexes);
+return 0;
default:
return -1;
}
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.h
b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.h
index 0acf3b0ea0..9525685afa 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.h
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.h
@@ -36,6 +36,7 @@ typedef enum {
DMBO_MUL = 2,
DMBO_REALDIV = 3,
DMBO_MINIMUM = 4,
+DMBO_FLOORMOD = 5,
DMBO_COUNT
} DNNMathBinaryOperation;
diff --git a/tests/dnn/dnn-layer-mathbinary-test.c
b/tests/dnn/dnn-layer-mathbinary-test.c
index e7f8f8557c..5422b2a207 100644
--- a/tests/dnn/dnn-layer-mathbinary-test.c
+++ b/tests/dnn/dnn-layer-mathbinary-test.c
@@ -40,6 +40,8 @@ static float get_expected(float f1, float f2,
DNNMathBinaryOperation op)
return f1 / f2;
case DMBO_MINIMUM:
return (f1 < f2) ? f1 : f2;
+case DMBO_FLOORMOD:
+return (float)((int)(f1) % (int)(f2));
default:
av_assert0(!"not supported yet");
return 0.f;
@@ -205,5 +207,8 @@ int main(int argc, char **argv)
if (test(DMBO_MINIMUM))
return 1;
+if (test(DMBO_FLOORMOD))
+return 1;
+
return 0;
}
diff --git a/tools/python/convert_from_tensorflow.py
b/tools/python/convert_from_tensorflow.py
index 3c14bed487..1762091fdd 100644
--- a/tools/python/convert_from_tensorflow.py
+++ b/tools/python/convert_from_tensorflow.py
@@ -73,7 +73,7 @@ class TFConverter:
self.conv2d_scopename_inputname_dict = {}
self.op2code = {'Conv2D':1, 'DepthToSpace':2, 'MirrorPad':3,
'Maximum':4,
'MathBinary':5, 'MathUnary':6, 'AvgPool':7}
-self.mathbin2code = {'Sub':0, 'Add':1, 'Mul':2, 'RealDiv':3,
'Minimum':4}
+self.mathbin2code = {'Sub':0, 'Add':1, 'Mul':2, 'RealDiv':3,
'Minimum':4, 'FloorMod':5}
self.mathun2code = {'Abs':0, 'Sin':1, 'Cos':2, 'Tan':3, 'Asin':4,
'Acos':5, 'Atan':6, 'Sinh':7, 'Cosh':8, 'Tanh':9, 'Asinh':10,
'Acosh':11, 'Atanh':12, 'Ceil':13, 'Floor':14, 'Round':15}
diff --git a/tools/python/convert_header.py b/tools/python/convert_header.py
index 747c8776eb..782a6341f9 100644
--- a/tools/python/convert_header.py
+++ b/tools/python/convert_header.py
@@ -23,4 +23,4 @@ str = 'FFMPEGDNNNATIVE'
major = 1
# increase minor when we don't have to re-convert the model file
-minor = 21
+minor = 22
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V4 1/2] dnn_backend_native_layer_mathbinary: change to function pointer
Signed-off-by: Mingyu Yin
---
.../dnn/dnn_backend_native_layer_mathbinary.c | 140 +-
1 file changed, 73 insertions(+), 67 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
index dd42c329a9..4373f82543 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
@@ -27,6 +27,74 @@
#include "libavutil/avassert.h"
#include "dnn_backend_native_layer_mathbinary.h"
+typedef float (*FunType)(const float src0, float src1);
+FunType pfun;
+
+static float sub(float src0, float src1)
+{
+return src0 - src1;
+}
+static float add(float src0, float src1)
+{
+return src0 + src1;
+}
+static float mul(float src0, float src1)
+{
+return src0 * src1;
+}
+static float realdiv(float src0, float src1)
+{
+return src0 / src1;
+}
+static float minimum(float src0, float src1)
+{
+return FFMIN(src0, src1);
+}
+
+static void math_binary_commutative(FunType pfun, const
DnnLayerMathBinaryParams *params, const DnnOperand *input, DnnOperand *output,
DnnOperand *operands, const int32_t *input_operand_indexes)
+{
+int dims_count;
+const float *src;
+float *dst;
+dims_count = calculate_operand_dims_count(output);
+src = input->data;
+dst = output->data;
+if (params->input0_broadcast || params->input1_broadcast) {
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(params->v, src[i]);
+}
+} else {
+const DnnOperand *input1 = &operands[input_operand_indexes[1]];
+const float *src1 = input1->data;
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(src[i], src1[i]);
+}
+}
+}
+static void math_binary_not_commutative(FunType pfun, const
DnnLayerMathBinaryParams *params, const DnnOperand *input, DnnOperand *output,
DnnOperand *operands, const int32_t *input_operand_indexes)
+{
+int dims_count;
+const float *src;
+float *dst;
+dims_count = calculate_operand_dims_count(output);
+src = input->data;
+dst = output->data;
+if (params->input0_broadcast) {
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(params->v, src[i]);
+}
+} else if (params->input1_broadcast) {
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(src[i], params->v);
+}
+} else {
+const DnnOperand *input1 = &operands[input_operand_indexes[1]];
+const float *src1 = input1->data;
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(src[i], src1[i]);
+}
+}
+}
int dnn_load_layer_math_binary(Layer *layer, AVIOContext *model_file_context,
int file_size, int operands_num)
{
DnnLayerMathBinaryParams *params;
@@ -97,83 +165,21 @@ int dnn_execute_layer_math_binary(DnnOperand *operands,
const int32_t *input_ope
if (!output->data)
return DNN_ERROR;
-dims_count = calculate_operand_dims_count(output);
-src = input->data;
-dst = output->data;
-
switch (params->bin_op) {
case DMBO_SUB:
-if (params->input0_broadcast) {
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = params->v - src[i];
-}
-} else if (params->input1_broadcast) {
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = src[i] - params->v;
-}
-} else {
-const DnnOperand *input1 = &operands[input_operand_indexes[1]];
-const float *src1 = input1->data;
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = src[i] - src1[i];
-}
-}
+math_binary_not_commutative(sub, params, input, output, operands,
input_operand_indexes);
return 0;
case DMBO_ADD:
-if (params->input0_broadcast || params->input1_broadcast) {
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = params->v + src[i];
-}
-} else {
-const DnnOperand *input1 = &operands[input_operand_indexes[1]];
-const float *src1 = input1->data;
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = src[i] + src1[i];
-}
-}
+math_binary_commutative(add, params, input, output, operands,
input_operand_indexes);
return 0;
case DMBO_MUL:
-if (params->input0_broadcast || params->input1_broadcast) {
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = params->v * src[i];
-}
-} else {
-const DnnOperand *input1 = &operands[input_operand_indexes[1]];
-const float *src1 = input1->data;
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = src[i] * src1[i];
-}
-}
+math_binary_commutative(mul, params, input, output, operands,
input_operand_indexes);
Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: add x86 SIMD
On Fri, Aug 21, 2020 at 13:13:29 +0200, Paul B Mahol wrote: > Overall speed changes for 1920x1080, yuv422p10le, 60fps from: 0.19x to 0.343x Let me add my promised benchmarks. I have nothing modern here (these CPUs are 10, 18 and 6 years old), but I can confirm the impressive improvements: Intel Atom D525 Intel Pentium 4 Intel Haswell i5-4200U MT_BeartoothHighwavi: 0.489x -> 0.835x 0.23x -> 0.55x 2.13x -> 3.07x bigger_res.mov: 0.057x -> 0.069x 0.02x -> 0.058x 0.174x -> 0.237x timelapse-pt-momsapt.avi: 1.11x -> 1.9x0.53x -> 1.37x 4.3x -> 6.2x No more crashes with this patch, on any of the three platforms. Cheers, Moritz P.S.: Both timelapse-pt-momsapt.avi and MT_BeartoothHighway_1min_Cineform.avi end with corrupt AVI packets, resulting in [cfhd @ 0xb2428c0] Escape codeword not found, probably corrupt data Unrelated, certainly. ___ ffmpeg-devel 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] Documentation: proposed changes in the structure
On Fri, 21 Aug 2020, at 14:35, Nicolas George wrote: > 2. What would you think about switching from texinfo to a small basic >subset of HTML for new documentation? > >I think most of us are much more familiar with HTML syntax than with >texinfo. Use Markdown. It's defined, spec'd and used in all OSS projects. It's supported by most editors and most source repositories. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel 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] Documentation: proposed changes in the structure
On 21.08.2020 14:35, Nicolas George wrote: 1. What would you think about putting the documentation for libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi instead of into huge doc/filters.texi (25k lines!)? And same for codecs, formats, etc. We can adopt this for new documentation and move progressively existing components. That seems long overdue to me. The current approach to documentation has become very hard to properly maintain. 2. What would you think about switching from texinfo to a small basic subset of HTML for new documentation? I think most of us are much more familiar with HTML syntax than with texinfo. Something like Markdown would come to mind. It should have all formatting tools one needs for documentation. 3. What would you think about using pandoc for processing the documentation? Seems like a common choice for processing Markdown to me, so would go well with Markdown. 4. What would you think about including the documentation for components into the libraries? It would allow GUI applications to present it in dialog boxes, like spreadsheets do with their math functions. Not really any strong opinion there. It'd increase the size of the binaries, but if its compressed not by a whole lot, and I can see it being useful specially for CLI users. ___ ffmpeg-devel 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] Documentation: proposed changes in the structure
1. What would you think about putting the documentation for libavfilter/vf_foobar.c into libavfilter/doc/vf_foobar.texi instead of into huge doc/filters.texi (25k lines!)? And same for codecs, formats, etc. We can adopt this for new documentation and move progressively existing components. 2. What would you think about switching from texinfo to a small basic subset of HTML for new documentation? I think most of us are much more familiar with HTML syntax than with texinfo. 3. What would you think about using pandoc for processing the documentation? 4. What would you think about including the documentation for components into the libraries? It would allow GUI applications to present it in dialog boxes, like spreadsheets do with their math functions. (4 certainly depends on 2, because texinfo is nos suited for that use; and probably in part on 1.) Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate: add fate-sub-dvb test
On Tue, Aug 18, 2020 at 11:43:29PM +0200, Michael Niedermayer wrote: > On Tue, Aug 18, 2020 at 10:45:50PM +0200, Clément Bœsch wrote: > > On Tue, Aug 11, 2020 at 02:19:01PM +0200, Clément Bœsch wrote: > > [...] > > > +FATE_SUBTITLES-$(call ALLYES, MPEGTS_DEMUXER DVBSUB_DECODER > > > DVBSUB_ENCODER) += fate-sub-dvb > > > +fate-sub-dvb: CMD = framecrc -i > > > $(TARGET_SAMPLES)/sub/dvbsubtest_filter.ts -map s:0 -c dvbsub > > > > Can someone upload that sample¹ to fate-samples/sub/dvbsubtest_filter.ts > > so we can apply this patch now that JEEB fixed MPEG-TS DVB demuxing? > > > > [1]: https://trac.ffmpeg.org/raw-attachment/ticket/8844/dvbsubtest_filter.ts > > Uplaod requests are best sent to or CC-ed to samples-requ...@ffmpeg.org > (already added to CC) > ping I'm waiting for this to push a bunch of DVB patches because I want the FATE test first. Regards, -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] dnn_backend_native_layer_avgpool: Fix invalid assignment, use av_assert
dnn_execute_layer_avg_pool() contains the following line:
assert(avgpool_params->padding_method = VALID);
This statement contains an assignment where obviously a comparison was
intended. Furthermore, *avgpool_params is const, so that the attempted
assignment leads to a compilation failure if asserts are enabled
(i.e. if DEBUG is defined which leads libavutil/internal.h to not define
NDEBUG). Moreover, the enumeration constant VALID actually has the value 0,
so that the assert would be triggered if a compiler compiles this with
asserts enabled. Finally, the statement uses assert() directly instead
of av_assert*().
All these errors have been fixed.
Thanks to ubitux for providing a FATE-box [1] where DEBUG is defined.
[1]: http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-ddebug
Signed-off-by: Andreas Rheinhardt
---
I was unsure which assert level to use and therefore simply opted for 0.
libavfilter/dnn/dnn_backend_native_layer_avgpool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
b/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
index d745c35b4a..8d4d8db98c 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_avgpool.c
@@ -91,7 +91,7 @@ int dnn_execute_layer_avg_pool(DnnOperand *operands, const
int32_t *input_operan
output_height = ceil(height / (kernel_strides * 1.0));
output_width = ceil(width / (kernel_strides * 1.0));
} else {
-assert(avgpool_params->padding_method = VALID);
+av_assert0(avgpool_params->padding_method == VALID);
height_end = height - avgpool_params->kernel_size + 1;
width_end = width - avgpool_params->kernel_size + 1;
height_radius = 0;
--
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 2/2] avfilter/vf_overlay: Remove superfluous ;
On 8/21/20, Andreas Rheinhardt wrote: > In a function body, a redundant ; is just a null statement that does > nothing. Yet outside a function body, a superfluous ';' like one that > exists if one adds a ';' immediately after a function body's closing > brace is actually invalid C that compilers happen to accept. Yet when > compiled in -pedantic mode, both GCC as well as Clang emit warnings for > this like "ISO C does not allow extra ‘;’ outside of a function > [-Wpedantic]". > > The scenario described above existed in vf_overlay.c as a result of > macro expansion. This commit fixes it. > LGTM > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/vf_overlay.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c > index b3a1ac1a09..79c654bb2d 100644 > --- a/libavfilter/vf_overlay.c > +++ b/libavfilter/vf_overlay.c > @@ -595,8 +595,8 @@ static av_always_inline void > blend_plane_##depth##_##nbits##bits(AVFilterContext > dap += (1 << vsub) * dst->linesize[3] / bytes; >\ > } >\ > } > -DEFINE_BLEND_PLANE(8, 8); > -DEFINE_BLEND_PLANE(16, 10); > +DEFINE_BLEND_PLANE(8, 8) > +DEFINE_BLEND_PLANE(16, 10) > > #define DEFINE_ALPHA_COMPOSITE(depth, nbits) >\ > static inline void alpha_composite_##depth##_##nbits##bits(const AVFrame > *src, const AVFrame *dst, \ > @@ -647,8 +647,8 @@ static inline void > alpha_composite_##depth##_##nbits##bits(const AVFrame *src, c > sa += src->linesize[3] / bytes; >\ > } >\ > } > -DEFINE_ALPHA_COMPOSITE(8, 8); > -DEFINE_ALPHA_COMPOSITE(16, 10); > +DEFINE_ALPHA_COMPOSITE(8, 8) > +DEFINE_ALPHA_COMPOSITE(16, 10) > > #define DEFINE_BLEND_SLICE_YUV(depth, nbits) >\ > static av_always_inline void > blend_slice_yuv_##depth##_##nbits##bits(AVFilterContext *ctx, > \ > @@ -679,8 +679,8 @@ static av_always_inline void > blend_slice_yuv_##depth##_##nbits##bits(AVFilterCon > alpha_composite_##depth##_##nbits##bits(src, dst, src_w, src_h, > dst_w, dst_h, x, y,\ > jobnr, nb_jobs); >\ > } > -DEFINE_BLEND_SLICE_YUV(8, 8); > -DEFINE_BLEND_SLICE_YUV(16, 10); > +DEFINE_BLEND_SLICE_YUV(8, 8) > +DEFINE_BLEND_SLICE_YUV(16, 10) > > static av_always_inline void blend_slice_planar_rgb(AVFilterContext *ctx, > AVFrame *dst, const > AVFrame *src, > -- > 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". ___ ffmpeg-devel 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/cfhd: add x86 SIMD
Overall speed changes for 1920x1080, yuv422p10le, 60fps from: 0.19x to 0.343x
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 2 +-
libavcodec/cfhd.c | 337 --
libavcodec/cfhd.h | 3 +
libavcodec/cfhddsp.c | 118 +++
libavcodec/cfhddsp.h | 44 +++
libavcodec/x86/Makefile | 2 +
libavcodec/x86/cfhddsp.asm| 619 ++
libavcodec/x86/cfhddsp_init.c | 52 +++
8 files changed, 903 insertions(+), 274 deletions(-)
create mode 100644 libavcodec/cfhddsp.c
create mode 100644 libavcodec/cfhddsp.h
create mode 100644 libavcodec/x86/cfhddsp.asm
create mode 100644 libavcodec/x86/cfhddsp_init.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3431ba2dca..a770198475 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -255,7 +255,7 @@ OBJS-$(CONFIG_CCAPTION_DECODER)+= ccaption_dec.o
ass.o
OBJS-$(CONFIG_CDGRAPHICS_DECODER) += cdgraphics.o
OBJS-$(CONFIG_CDTOONS_DECODER) += cdtoons.o
OBJS-$(CONFIG_CDXL_DECODER)+= cdxl.o
-OBJS-$(CONFIG_CFHD_DECODER)+= cfhd.o cfhddata.o
+OBJS-$(CONFIG_CFHD_DECODER)+= cfhd.o cfhddata.o cfhddsp.o
OBJS-$(CONFIG_CFHD_ENCODER)+= cfhdenc.o cfhddata.o
OBJS-$(CONFIG_CINEPAK_DECODER) += cinepak.o
OBJS-$(CONFIG_CINEPAK_ENCODER) += cinepakenc.o elbg.o
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 2b1db0ed8d..291d53e02e 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -190,47 +190,6 @@ static inline void process_bayer(AVFrame *frame, int bpc)
}
}
-static inline void filter(int16_t *output, ptrdiff_t out_stride,
- int16_t *low, ptrdiff_t low_stride,
- int16_t *high, ptrdiff_t high_stride,
- int len, int clip)
-{
-int16_t tmp;
-int i;
-
-tmp = (11*low[0*low_stride] - 4*low[1*low_stride] + low[2*low_stride] + 4)
>> 3;
-output[(2*0+0)*out_stride] = (tmp + high[0*high_stride]) >> 1;
-if (clip)
-output[(2*0+0)*out_stride] =
av_clip_uintp2_c(output[(2*0+0)*out_stride], clip);
-
-tmp = ( 5*low[0*low_stride] + 4*low[1*low_stride] - low[2*low_stride] + 4)
>> 3;
-output[(2*0+1)*out_stride] = (tmp - high[0*high_stride]) >> 1;
-if (clip)
-output[(2*0+1)*out_stride] =
av_clip_uintp2_c(output[(2*0+1)*out_stride], clip);
-
-for (i = 1; i < len - 1; i++) {
-tmp = (low[(i-1)*low_stride] - low[(i+1)*low_stride] + 4) >> 3;
-output[(2*i+0)*out_stride] = (tmp + low[i*low_stride] +
high[i*high_stride]) >> 1;
-if (clip)
-output[(2*i+0)*out_stride] =
av_clip_uintp2_c(output[(2*i+0)*out_stride], clip);
-
-tmp = (low[(i+1)*low_stride] - low[(i-1)*low_stride] + 4) >> 3;
-output[(2*i+1)*out_stride] = (tmp + low[i*low_stride] -
high[i*high_stride]) >> 1;
-if (clip)
-output[(2*i+1)*out_stride] =
av_clip_uintp2_c(output[(2*i+1)*out_stride], clip);
-}
-
-tmp = ( 5*low[i*low_stride] + 4*low[(i-1)*low_stride] -
low[(i-2)*low_stride] + 4) >> 3;
-output[(2*i+0)*out_stride] = (tmp + high[i*high_stride]) >> 1;
-if (clip)
-output[(2*i+0)*out_stride] =
av_clip_uintp2_c(output[(2*i+0)*out_stride], clip);
-
-tmp = (11*low[i*low_stride] - 4*low[(i-1)*low_stride] +
low[(i-2)*low_stride] + 4) >> 3;
-output[(2*i+1)*out_stride] = (tmp - high[i*high_stride]) >> 1;
-if (clip)
-output[(2*i+1)*out_stride] =
av_clip_uintp2_c(output[(2*i+1)*out_stride], clip);
-}
-
static inline void interlaced_vertical_filter(int16_t *output, int16_t *low,
int16_t *high,
int width, int linesize, int plane)
{
@@ -244,8 +203,7 @@ static inline void interlaced_vertical_filter(int16_t
*output, int16_t *low, int
}
}
-static inline void inverse_temporal_filter(int16_t *output, int16_t *low,
int16_t *high,
- int width)
+static inline void inverse_temporal_filter(int16_t *low, int16_t *high, int
width)
{
for (int i = 0; i < width; i++) {
int even = (low[i] - high[i]) / 2;
@@ -256,31 +214,6 @@ static inline void inverse_temporal_filter(int16_t
*output, int16_t *low, int16_
}
}
-static void horiz_filter(int16_t *output, int16_t *low, int16_t *high,
- int width)
-{
-filter(output, 1, low, 1, high, 1, width, 0);
-}
-
-static void horiz_filter_clip(int16_t *output, int16_t *low, int16_t *high,
- int width, int clip)
-{
-filter(output, 1, low, 1, high, 1, width, clip);
-}
-
-static void horiz_filter_clip_bayer(int16_t *output, int16_t *low, int16_t
*high,
-int width, int clip)
-{
-filter(output, 2, low, 1, high, 1, width, clip);
-}
-
-static void vert_filter(int16_t *output, ptrdiff_t out_stride,
-int16_t *low, ptrdiff_t low_stride,
-
Re: [FFmpeg-devel] [PATCH 3/5] lavc/libkvazaar: export encoded frame stats
On Fri, Aug 21, 2020 at 7:15 AM James Almer wrote:
>
> On 8/15/2020 5:48 AM, myp...@gmail.com wrote:
> > On Sun, Aug 9, 2020 at 6:07 AM Mark Thompson wrote:
> >>
> >> On 26/07/2020 13:26, Jun Zhao wrote:
> >>> From: Jun Zhao
> >>>
> >>> Export choosen pict_type and qp.
> >>>
> >>> Signed-off-by: Jun Zhao
> >>> ---
> >>> libavcodec/libkvazaar.c | 30 ++
> >>> 1 file changed, 30 insertions(+)
> >>>
> >>> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> >>> index 71c9c8f..9032547 100644
> >>> --- a/libavcodec/libkvazaar.c
> >>> +++ b/libavcodec/libkvazaar.c
> >>> @@ -37,6 +37,7 @@
> >>>
> >>> #include "avcodec.h"
> >>> #include "internal.h"
> >>> +#include "packet_internal.h"
> >>>
> >>> typedef struct LibkvazaarContext {
> >>> const AVClass *class;
> >>> @@ -170,6 +171,7 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >>> kvz_data_chunk *data_out = NULL;
> >>> uint32_t len_out = 0;
> >>> int retval = 0;
> >>> +int pict_type;
> >>>
> >>> *got_packet_ptr = 0;
> >>>
> >>> @@ -257,6 +259,34 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >>> avpkt->flags |= AV_PKT_FLAG_KEY;
> >>> }
> >>>
> >>> +switch (frame_info.slice_type) {
> >>> +case KVZ_SLICE_I:
> >>> +pict_type = AV_PICTURE_TYPE_I;
> >>> +break;
> >>> +case KVZ_SLICE_P:
> >>> +pict_type = AV_PICTURE_TYPE_P;
> >>> +break;
> >>> +case KVZ_SLICE_B:
> >>> +pict_type = AV_PICTURE_TYPE_B;
> >>> +break;
> >>> +default:
> >>> +av_log(avctx, AV_LOG_ERROR, "Unknown picture type
> >>> encountered.\n");
> >>> +return AVERROR_EXTERNAL;
> >>> +}
> >>> +#if FF_API_CODED_FRAME
> >>> +FF_DISABLE_DEPRECATION_WARNINGS
> >>> +avctx->coded_frame->pict_type = pict_type;
> >>> +FF_ENABLE_DEPRECATION_WARNINGS
> >>> +#endif
> >>
> >> Is there some value to setting the deprecated fields? They will disappear
> >> on the next version bump, which probably isn't very far away.
> >>
> > I think we can keep this part, if we want to remove the
> > avctx->coded_frame->pict_type from next version bump, we can drop this
> > part from all codec one-time
>
> No, the usage of deprecated features should not be expanded. It's kept
> in old encoders for compatibility reasons, but new ones should not use
> it at all. So please remove it.
>
Will remove it, thx
> >>> +
> >>> +ff_side_data_set_encoder_stats(avpkt, frame_info.qp *
> >>> FF_QP2LAMBDA, NULL, 0, pict_type);
> >>
> >> I'm not familiar with kvazaar - is the QP value here actually reflective
> >> of the global quality in a useful way? The documentation is not very
> >> good...
> >>
> > Yes, it's a global quality based on Frame in kvazaar
> >
> >> (Your following patch for OpenH264 uses a field "AverageFrameQP", which
> >> has an much more usefully-suggestive name.)
> >>
> >> Zero is a valid QP value, but you shouldn't be passing it here. Possibly
> >> it needs some more scaling to get the range to [1, FF_LAMDBA_MAX].
> >>
> > I know vpx encoder wrapper used the zero QP value in side data, maybe
> > we can keep the same action
> >>> +
> >>> +#if FF_API_CODED_FRAME
> >>> +FF_DISABLE_DEPRECATION_WARNINGS
> >>> +avctx->coded_frame->quality = frame_info.qp * FF_QP2LAMBDA;
> >>> +FF_ENABLE_DEPRECATION_WARNINGS
> >>> +#endif
> >>> +
> >>> *got_packet_ptr = 1;
> >>> }
> >>>
> >>>
> >> - Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] lavc/libkvazaar: export encoded frame stats
On Fri, Aug 21, 2020 at 7:03 AM Mark Thompson wrote:
>
> On 15/08/2020 09:48, myp...@gmail.com wrote:
> > On Sun, Aug 9, 2020 at 6:07 AM Mark Thompson wrote:
> >>
> >> On 26/07/2020 13:26, Jun Zhao wrote:
> >>> From: Jun Zhao
> >>>
> >>> Export choosen pict_type and qp.
> >>>
> >>> Signed-off-by: Jun Zhao
> >>> ---
> >>>libavcodec/libkvazaar.c | 30 ++
> >>>1 file changed, 30 insertions(+)
> >>>
> >>> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> >>> index 71c9c8f..9032547 100644
> >>> --- a/libavcodec/libkvazaar.c
> >>> +++ b/libavcodec/libkvazaar.c
> >>> @@ -37,6 +37,7 @@
> >>>
> >>>#include "avcodec.h"
> >>>#include "internal.h"
> >>> +#include "packet_internal.h"
> >>>
> >>>typedef struct LibkvazaarContext {
> >>>const AVClass *class;
> >>> @@ -170,6 +171,7 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >>>kvz_data_chunk *data_out = NULL;
> >>>uint32_t len_out = 0;
> >>>int retval = 0;
> >>> +int pict_type;
> >>>
> >>>*got_packet_ptr = 0;
> >>>
> >>> @@ -257,6 +259,34 @@ static int libkvazaar_encode(AVCodecContext *avctx,
> >>>avpkt->flags |= AV_PKT_FLAG_KEY;
> >>>}
> >>>
> >>> +switch (frame_info.slice_type) {
> >>> +case KVZ_SLICE_I:
> >>> +pict_type = AV_PICTURE_TYPE_I;
> >>> +break;
> >>> +case KVZ_SLICE_P:
> >>> +pict_type = AV_PICTURE_TYPE_P;
> >>> +break;
> >>> +case KVZ_SLICE_B:
> >>> +pict_type = AV_PICTURE_TYPE_B;
> >>> +break;
> >>> +default:
> >>> +av_log(avctx, AV_LOG_ERROR, "Unknown picture type
> >>> encountered.\n");
> >>> +return AVERROR_EXTERNAL;
> >>> +}
> >>> +#if FF_API_CODED_FRAME
> >>> +FF_DISABLE_DEPRECATION_WARNINGS
> >>> +avctx->coded_frame->pict_type = pict_type;
> >>> +FF_ENABLE_DEPRECATION_WARNINGS
> >>> +#endif
> >>
> >> Is there some value to setting the deprecated fields? They will disappear
> >> on the next version bump, which probably isn't very far away.
> >>
> > I think we can keep this part, if we want to remove the
> > avctx->coded_frame->pict_type from next version bump, we can drop this
> > part from all codec one-time
> >>> +
> >>> +ff_side_data_set_encoder_stats(avpkt, frame_info.qp *
> >>> FF_QP2LAMBDA, NULL, 0, pict_type);
> >>
> >> I'm not familiar with kvazaar - is the QP value here actually reflective
> >> of the global quality in a useful way? The documentation is not very
> >> good...
> >>
> > Yes, it's a global quality based on Frame in kvazaar
> >
> >> (Your following patch for OpenH264 uses a field "AverageFrameQP", which
> >> has an much more usefully-suggestive name.)
> >>
> >> Zero is a valid QP value, but you shouldn't be passing it here. Possibly
> >> it needs some more scaling to get the range to [1, FF_LAMDBA_MAX].
> >>
> > I know vpx encoder wrapper used the zero QP value in side data, maybe
> > we can keep the same action
>
> So the libvpx wrapper is also broken? This all seems very inconsistent - the
> documentation requires that the number be in [1, FF_LAMBDA_MAX], but codecs
> are using random numbers which include zero.
>
> libx264 is applying some sort of offset so that the returned qpplus1 field is
> actually qpplussomewherebetween1and30 (with 10-bit input qp == -12 gives
> qpplus1 == 1 and qp == 51 gives qpplus1 == 81), but we still subtract 1 so
> the result includes zero.
>
> libx265 doesn't seem to support negative QPs so it's always in the 8-bit
> range, but that still includes zero.
>
> nvenc has frameAvgQP - 1, which seems bizarre. I guess it would work if it
> doesn't support QP < 2, but given that it allows 12-bit inputs (range -24 to
> 51) that seems unlikely.
>
> Scaling to match what the documentation actually says seems like the sanest
> way to fix this - we can't change the range because zero is the "unused"
> value.
>
I believe the parameter int quality in function int
ff_side_data_set_encoder_stats(AVPacket *pkt, int quality, int64_t
*error, int error_count, int pict_type) is inconsistent, I think need
to more check/clarification in different codec
___
ffmpeg-devel 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: remove "-v 0" from ffprobe tests.
Michael Niedermayer (12016-05-05):
> On Thu, May 05, 2016 at 11:59:19AM +0200, Nicolas George wrote:
> > The FATE scripts separate stdout from stderr.
> > Having a first idea about what went wrong in the log file
> > is more convenient.
> >
> > Signed-off-by: Nicolas George
> > ---
> > tests/fate-run.sh | 16
> > 1 file changed, 8 insertions(+), 8 deletions(-)
>
> LGTM
Wow, I had not realized it was that old.
It does not apply, I will apply this new one, hopefully before 2024, if
nobody objects.
Regards,
--
Nicolas George
From e3a3ad20b1ecb2c167ba30ed6b6ced36f146f4b5 Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Fri, 21 Aug 2020 13:03:50 +0200
Subject: [PATCH] fate: remove "-v 0" from ffprobe tests.
Signed-off-by: Nicolas George
---
tests/fate-run.sh | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 414ac6f825..071602ff4c 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -86,15 +86,15 @@ runecho(){
}
probefmt(){
-run ffprobe${PROGSUF}${EXECSUF} -show_entries format=format_name -print_format default=nw=1:nk=1 -v 0 "$@"
+run ffprobe${PROGSUF}${EXECSUF} -show_entries format=format_name -print_format default=nw=1:nk=1 "$@"
}
probeaudiostream(){
-run ffprobe${PROGSUF}${EXECSUF} -show_entries stream=codec_name,codec_time_base,sample_fmt,channels,channel_layout -v 0 "$@"
+run ffprobe${PROGSUF}${EXECSUF} -show_entries stream=codec_name,codec_time_base,sample_fmt,channels,channel_layout "$@"
}
probetags(){
-run ffprobe${PROGSUF}${EXECSUF} -show_entries format_tags -v 0 "$@"
+run ffprobe${PROGSUF}${EXECSUF} -show_entries format_tags "$@"
}
runlocal(){
@@ -103,24 +103,24 @@ runlocal(){
}
probeframes(){
-run ffprobe${PROGSUF}${EXECSUF} -show_frames -v 0 "$@"
+run ffprobe${PROGSUF}${EXECSUF} -show_frames "$@"
}
probechapters(){
-run ffprobe${PROGSUF}${EXECSUF} -show_chapters -v 0 "$@"
+run ffprobe${PROGSUF}${EXECSUF} -show_chapters "$@"
}
probegaplessinfo(){
filename="$1"
shift
-run ffprobe${PROGSUF}${EXECSUF} -bitexact -select_streams a -show_entries format=start_time,duration:stream=index,start_pts,duration_ts -v 0 "$filename" "$@"
+run ffprobe${PROGSUF}${EXECSUF} -bitexact -select_streams a -show_entries format=start_time,duration:stream=index,start_pts,duration_ts "$filename" "$@"
pktfile1="${outdir}/${test}.pkts"
framefile1="${outdir}/${test}.frames"
cleanfiles="$cleanfiles $pktfile1 $framefile1"
-run ffprobe${PROGSUF}${EXECSUF} -bitexact -select_streams a -of compact -count_packets -show_entries packet=pts,dts,duration,flags:stream=nb_read_packets -v 0 "$filename" "$@" > "$pktfile1"
+run ffprobe${PROGSUF}${EXECSUF} -bitexact -select_streams a -of compact -count_packets -show_entries packet=pts,dts,duration,flags:stream=nb_read_packets "$filename" "$@" > "$pktfile1"
head -n 8 "$pktfile1"
tail -n 9 "$pktfile1"
-run ffprobe${PROGSUF}${EXECSUF} -bitexact -select_streams a -of compact -count_frames -show_entries frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples:stream=nb_read_frames -v 0 "$filename" "$@" > "$framefile1"
+run ffprobe${PROGSUF}${EXECSUF} -bitexact -select_streams a -of compact -count_frames -show_entries frame=pkt_pts,pkt_dts,best_effort_timestamp,pkt_duration,nb_samples:stream=nb_read_frames "$filename" "$@" > "$framefile1"
head -n 8 "$framefile1"
tail -n 9 "$framefile1"
}
@@ -213,7 +213,7 @@ enc_dec(){
do_md5sum $decfile
tests/tiny_psnr${HOSTEXECSUF} $srcfile $decfile $cmp_unit $cmp_shift
test -z $ffprobe_opts || \
-run ffprobe${PROGSUF}${EXECSUF} $ffprobe_opts -v 0 $tencfile || return
+run ffprobe${PROGSUF}${EXECSUF} $ffprobe_opts $tencfile || return
}
transcode(){
@@ -234,7 +234,7 @@ transcode(){
ffmpeg $DEC_OPTS -i $tencfile $ENC_OPTS $FLAGS $final_decode \
-f framecrc - || return
test -z $ffprobe_opts || \
-run ffprobe${PROGSUF}${EXECSUF} $ffprobe_opts -v 0 $tencfile || return
+run ffprobe${PROGSUF}${EXECSUF} $ffprobe_opts $tencfile || return
}
stream_remux(){
@@ -253,7 +253,7 @@ stream_remux(){
ffmpeg $DEC_OPTS -i $tencfile $ENC_OPTS $FLAGS $final_decode \
-f framecrc - || return
test -z $ffprobe_opts || \
-run ffprobe${PROGSUF}${EXECSUF} $ffprobe_opts -v 0 $tencfile || return
+run ffprobe${PROGSUF}${EXECSUF} $ffprobe_opts $tencfile || return
}
# FIXME: There is a certain duplication between the avconv-related helper
@@ -484,10 +484,10 @@ concat(){
awk "{gsub(/%SRCFILE%/, \"$sample\"); print}" $template > $concatfile
if [ "$mode" = "md5" ]; then
-run ffprobe${PROGSUF}${EXECSUF} -bitexact -show_streams -show_packets -v 0 -safe 0 $extra_args $(target_path $concatfile) | tr -d '\r' > $packetfile
+run ffprobe${PROGSUF}${EXECSUF} -bitexact -show_streams -show_packets -safe 0
Re: [FFmpeg-devel] [PATCH] libavfilter/vf_overlay_cuda: Pass the main frame to the output if secondary frame is not available. now filter fails if secondary frame is not available due to e.g secondary
Alex Pokotilo (12020-08-21): > I'm sorry. I'm a newbie. Am I right I just need to commit in following format: No need to apologize. > first line: short description.. > LF > more details here Exactly. > Should I send a new patch as a separate email or reply to this one ? It does not matter. > I create a filter graph with vf_cuda_overlay in my application. I > start sending frames into a "main" stream link using > av_buffersrc_write_frame. > I start sending frames into a "secondary" stream too almost > immediately. I have one output sink in my filter graph. What are the timestamps (and corresponding time bases) of the first frame you send on each input? > After each write I call av_buffersink_get_frame and get AVERROR_BUG > from vf_overlay_cuda for some time initially but after several frames > it starts returning mixed frame. > I've checked vf_blend and other framesync filters. They do the same as > I did in the fix. The fix is probably right, but I would like to make 100% sure, and I do not have a CUDA setup. Plus, it would help check the code of your application is right. > Maybe the problem In my application I cannot guarantee that both > streams have the same timeline. > Could you please point me to the place where framesync checks second > stream availability before it calls it's filter(overlay_cuda_blend in > my case). > This topic is very complex to me now so any help from your side can > really help me. The code in framesync is rather complex because it is designed to handle a wide variety of cases. If you are willing to make a quick test, this would be interesting: in libavfilter/framesync.c, in the function ff_framesync_init_dualinput, replace fs->in[1].before = EXT_NULL; with EXT_INFINITY and see if it changes something. But most importantly, seeing the timestamps of the frames would let me know if the issue is exactly what I think it is. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3 2/2] dnn/native: add log error message
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ting Fu
> Sent: 2020年8月21日 11:47
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH V3 2/2] dnn/native: add log error message
>
> Signed-off-by: Ting Fu
> ---
> V3:
> 1. modify log_ctx of NativeModel to non-pointer
> 2. modify log_ctx of NativeModel to ctx
> 3. delete empty line
>
> libavfilter/dnn/dnn_backend_native.c | 67 ++-
> libavfilter/dnn/dnn_backend_native.h | 5 ++
> .../dnn/dnn_backend_native_layer_avgpool.c| 10 ++-
> .../dnn/dnn_backend_native_layer_avgpool.h| 2 +-
> .../dnn/dnn_backend_native_layer_conv2d.c | 10 ++-
> .../dnn/dnn_backend_native_layer_conv2d.h | 2 +-
> .../dnn_backend_native_layer_depth2space.c| 10 ++-
> .../dnn_backend_native_layer_depth2space.h| 2 +-
> .../dnn/dnn_backend_native_layer_mathbinary.c | 11 ++-
> .../dnn/dnn_backend_native_layer_mathbinary.h | 2 +-
> .../dnn/dnn_backend_native_layer_mathunary.c | 11 ++-
> .../dnn/dnn_backend_native_layer_mathunary.h | 2 +-
> .../dnn/dnn_backend_native_layer_maximum.c| 10 ++-
> .../dnn/dnn_backend_native_layer_maximum.h| 2 +-
> .../dnn/dnn_backend_native_layer_pad.c| 10 ++-
> .../dnn/dnn_backend_native_layer_pad.h| 2 +-
> libavfilter/dnn/dnn_backend_native_layers.h | 2 +-
> tests/dnn/dnn-layer-avgpool-test.c| 4 +-
> tests/dnn/dnn-layer-conv2d-test.c | 4 +-
> tests/dnn/dnn-layer-depth2space-test.c| 2 +-
> tests/dnn/dnn-layer-mathbinary-test.c | 6 +-
> tests/dnn/dnn-layer-mathunary-test.c | 2 +-
> tests/dnn/dnn-layer-maximum-test.c| 2 +-
> tests/dnn/dnn-layer-pad-test.c| 6 +-
> 24 files changed, 130 insertions(+), 56 deletions(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_native.c
> b/libavfilter/dnn/dnn_backend_native.c
> index 0be9c0b53c..b7de27c709 100644
> --- a/libavfilter/dnn/dnn_backend_native.c
> +++ b/libavfilter/dnn/dnn_backend_native.c
> @@ -28,15 +28,26 @@
> #include "dnn_backend_native_layer_conv2d.h"
> #include "dnn_backend_native_layers.h"
>
> +static const AVClass dnn_native_class = {
> +.class_name = "dnn_native",
> +.item_name = av_default_item_name,
> +.option = NULL,
> +.version= LIBAVUTIL_VERSION_INT,
> +.category = AV_CLASS_CATEGORY_FILTER,
> +};
> +
> static DNNReturnType get_input_native(void *model, DNNData *input, const
> char *input_name)
> {
> NativeModel *native_model = (NativeModel *)model;
> +NetworkContext *ctx = &native_model->ctx;
as a unify name, we'd better use NativeContext, instead of NetworkContext.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3 1/2] dnn/native: unify error return to DNN_ERROR
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ting Fu
> Sent: 2020年8月21日 11:47
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH V3 1/2] dnn/native: unify error return to
> DNN_ERROR
>
> Unify all error return as DNN_ERROR, in order to cease model executing
> when return error in ff_dnn_execute_model_native layer_func.pf_exec
>
> Signed-off-by: Ting Fu
> ---
> libavfilter/dnn/dnn_backend_native_layer_avgpool.c | 2 +-
> libavfilter/dnn/dnn_backend_native_layer_conv2d.c | 4 ++--
> libavfilter/dnn/dnn_backend_native_layer_depth2space.c | 4 ++--
> libavfilter/dnn/dnn_backend_native_layer_mathbinary.c | 2 +-
> libavfilter/dnn/dnn_backend_native_layer_mathunary.c | 2 +-
> libavfilter/dnn/dnn_backend_native_layer_pad.c | 4 ++--
> 6 files changed, 9 insertions(+), 9 deletions(-)
>
we'd better move the following change to patch 1/2 from patch 2/2, so this
patch is complete.
-layer_funcs[layer_type].pf_exec(native_model->operands,
-
native_model->layers[layer].input_operand_indexes,
-
native_model->layers[layer].output_operand_index,
-native_model->layers[layer].params);
+if (layer_funcs[layer_type].pf_exec(native_model->operands,
+
native_model->layers[layer].input_operand_indexes,
+
native_model->layers[layer].output_operand_index,
+
native_model->layers[layer].params) == DNN_ERROR) {
+return DNN_ERROR;
+}
___
ffmpeg-devel 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] libavfilter/vf_overlay_cuda: Pass the main frame to the output if secondary frame is not available. now filter fails if secondary frame is not available due to e.g secondary
On 2020-08-21 20:46 +1000, Alex Pokotilo wrote: > On Fri, Aug 21, 2020 at 7:54 PM Nicolas George wrote: > > > > Alex Pokotilo (12020-08-21): > > > From b3739e33fa04a9292dc6584bd2f31460aa53d478 Mon Sep 17 00:00:00 2001 > > > From: Alex Pokotilo > > > Date: Fri, 21 Aug 2020 09:14:37 + > > > Subject: [PATCH] libavfilter/vf_overlay_cuda: Pass the main frame to the > > > output if secondary frame is not > > > available. now filter fails if secondary frame is not available due to > > > e.g secondary source delay. > > > > Your Git commit message is badly formatted. The format is: > > > > context: short summary on one line > > > > After an empty line, details if necessary, on several lines and > > wrapped at a reasonable line length. > > > > I'm sorry. I'm a newbie. Am I right I just need to commit in following format: > > first line: short description.. > LF > more details here Yes, that should do the trick. Please don't forget to mention the "Why" part in the commit message body (the "more details here" part), if you re-do the patch. At the moment it would probably best to first wait for feed back on your explanation below. Alexander > Should I send a new patch as a separate email or reply to this one ? > Sorry again. > > The fix may be correct, but your analysis of the problem does not prove > > it. Unless there is a serious bug in framesync, it will not call > > overlay_cuda_blend() without a secondary frame "due to e.g secondary > > source delay.", it will only do so if the stream has not yet begun or > > has ended. > > > > Please give more details on the exact circumstances you observe the > > issue. > > I create a filter graph with vf_cuda_overlay in my application. I > start sending frames into a "main" stream link using > av_buffersrc_write_frame. > I start sending frames into a "secondary" stream too almost > immediately. I have one output sink in my filter graph. > After each write I call av_buffersink_get_frame and get AVERROR_BUG > from vf_overlay_cuda for some time initially but after several frames > it starts returning mixed frame. > I've checked vf_blend and other framesync filters. They do the same as > I did in the fix. > > Maybe the problem In my application I cannot guarantee that both > streams have the same timeline. > Could you please point me to the place where framesync checks second > stream availability before it calls it's filter(overlay_cuda_blend in > my case). > This topic is very complex to me now so any help from your side can > really help me. ___ ffmpeg-devel 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] Curly braces around single statements (was avformat/avidec: Fix memleak when error) happens after creating DV stream
Hi Mark,
thanks for your opinion on this!
On 2020-08-20 23:35 +0100, Mark Thompson wrote:
> On 20/08/2020 22:20, Alexander Strasser wrote:
> > Please pardon me for bringing this up in the context of this patch.
> > No objections or particular opinion regarding this instance of the
> > problem.
> >
> > Though thinking more globally, I believe it would have a beneficial
> > impact to add the curly braces everywhere; even where they would not
> > be required because of the one-statement exception.
> >
> > It might be a bit longer regarding vertical space consumption, but
> > I'm sure the advantages would outweigh this disadvantage over time.
> > Also because we don't put the opening brace on a line of its own,
> > it would not consume so much more vertical space.
> >
> > Advantages I see are:
> >
> > 1. enables easier experimentation and debugging
>
> In my opinion this is not a significant benefit, the overhead of any edits
> while doing this is trivial. (Others may disagree, but it seems worth noting
> which parts I agree with.)
I obviously disagree here, but it's sure a subjective topic.
> > 2. future changes are easier to write and create smaller diffs
>
> I agree that this is a point in favour.
>
> > 3. completely eliminates dangling-else problems
>
> I think this is irrelevant, because compilers have already solved it:
>
> $ cat test-dangling-else.c
>
> int f(int a, int b)
> {
> if (a)
> if (b)
> return 1;
> else
> return 2;
>
> return 0;
> }
> $ gcc -c -Wall test-dangling-else.c
> test-dangling-else.c: In function ‘f’:
> test-dangling-else.c:4:8: warning: suggest explicit braces to avoid ambiguous
> ‘else’ [-Wdangling-else]
> 4 | if (a)
> |^
Agreed, compilers warn about this. I still think there is merit in
being able sort it out, before compiling, especially when doing code
reviews on the mailing list.
> > Just wanted to hear how other developers currently feel about this.
>
> The freeform nature of C is often helpful to make code look nicer and such a
> requirement would make some useful patterns worse, so I oppose such a change.
>
> To offer an example, consider the commonish code pattern:
>
> if (a) p = x;
> else if (b) q = y;
> else if (c) r = z;
I think this sort of alignment is another practice that didn't stand
the test of time.
I know it is very tempting to use when initially adding some code,
but it is often subjective and hard to keep in shape after (multiple)
change over times. You need to follow up with cosmetics and I assume
more often than not it will be overseen or forgotten, which makes
that code weird to read.
I know this sort of alignment is used often throughout FFmpeg's
code base. If you want I can try to dig out examples where it has
gone wrong, stumbled over this every now and then.
Alexander
>
> with some alignment of related subexpressions. Making uniform use of braces
> and newlines mandatory makes this actively worse however you do it.
>
> (Some randomly-chosen similar examples:
> ,
>
> .)
___
ffmpeg-devel 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] libavfilter/vf_overlay_cuda: Pass the main frame to the output if secondary frame is not available. now filter fails if secondary frame is not available due to e.g secondary
On Fri, Aug 21, 2020 at 7:54 PM Nicolas George wrote: > > Alex Pokotilo (12020-08-21): > > From b3739e33fa04a9292dc6584bd2f31460aa53d478 Mon Sep 17 00:00:00 2001 > > From: Alex Pokotilo > > Date: Fri, 21 Aug 2020 09:14:37 + > > Subject: [PATCH] libavfilter/vf_overlay_cuda: Pass the main frame to the > > output if secondary frame is not > > available. now filter fails if secondary frame is not available due to e.g > > secondary source delay. > > Your Git commit message is badly formatted. The format is: > > context: short summary on one line > > After an empty line, details if necessary, on several lines and > wrapped at a reasonable line length. > I'm sorry. I'm a newbie. Am I right I just need to commit in following format: first line: short description.. LF more details here Should I send a new patch as a separate email or reply to this one ? Sorry again. > The fix may be correct, but your analysis of the problem does not prove > it. Unless there is a serious bug in framesync, it will not call > overlay_cuda_blend() without a secondary frame "due to e.g secondary > source delay.", it will only do so if the stream has not yet begun or > has ended. > > Please give more details on the exact circumstances you observe the > issue. I create a filter graph with vf_cuda_overlay in my application. I start sending frames into a "main" stream link using av_buffersrc_write_frame. I start sending frames into a "secondary" stream too almost immediately. I have one output sink in my filter graph. After each write I call av_buffersink_get_frame and get AVERROR_BUG from vf_overlay_cuda for some time initially but after several frames it starts returning mixed frame. I've checked vf_blend and other framesync filters. They do the same as I did in the fix. Maybe the problem In my application I cannot guarantee that both streams have the same timeline. Could you please point me to the place where framesync checks second stream availability before it calls it's filter(overlay_cuda_blend in my case). This topic is very complex to me now so any help from your side can really help me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3 1/2] dnn_backend_native_layer_mathbinary: add floormod support
> -Original Message- > From: ffmpeg-devel On Behalf Of Mingyu > Yin > Sent: 2020年8月21日 16:52 > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH V3 1/2] dnn_backend_native_layer_mathbinary: > add floormod support > > Signed-off-by: Mingyu Yin > --- > .../dnn/dnn_backend_native_layer_mathbinary.c | 17 + > .../dnn/dnn_backend_native_layer_mathbinary.h | 1 + > tests/dnn/dnn-layer-mathbinary-test.c | 5 + > tools/python/convert_from_tensorflow.py | 2 +- > tools/python/convert_header.py | 2 +- > 5 files changed, 25 insertions(+), 2 deletions(-) I would prefer this patch after your function pointer patch. ___ ffmpeg-devel 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 2/2] dnn_backend_native_layer_mathbinary: change to function pointer
> -Original Message-
> From: ffmpeg-devel On Behalf Of Mingyu
> Yin
> Sent: 2020年8月21日 16:52
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH V3 2/2] dnn_backend_native_layer_mathbinary:
> change to function pointer
>
> Signed-off-by: Mingyu Yin
> ---
> .../dnn/dnn_backend_native_layer_mathbinary.c | 166 +-
> 1 file changed, 80 insertions(+), 86 deletions(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
> b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
> index 6876aaf2c6..6738acc6ce 100644
> --- a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
> +++ b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
> @@ -27,6 +27,79 @@
> #include "libavutil/avassert.h"
> #include "dnn_backend_native_layer_mathbinary.h"
>
> +typedef float (*FunType)(const float src, float dst);
> +FunType pfun;
> +
> +static float sub(float src, float dst)
> +{
> +return src - dst;
> +}
> +static float add(float src, float dst)
> +{
> +return src + dst;
> +}
> +static float mul(float src, float dst)
> +{
> +return src * dst;
> +}
> +static float realdiv(float src, float dst)
> +{
> +return src / dst;
> +}
> +static float minimum(float src, float dst)
> +{
> +return FFMIN(src, dst);
> +}
> +static float floormod(float src, float dst)
> +{
> +return (float)((int)(src) % (int)(dst));
> +}
the function parameter is not src/dst, we can use src0 and src1.
> +
> +static void math_binary_commutative(FunType pfun, const
> DnnLayerMathBinaryParams *params, const DnnOperand *input, DnnOperand
> *output, DnnOperand *operands, const int32_t *input_operand_indexes)
> +{
> +int dims_count;
> +const float *src;
> +float *dst;
> +dims_count = calculate_operand_dims_count(output);
> +src = input->data;
> +dst = output->data;
> +if (params->input0_broadcast || params->input1_broadcast) {
> +for (int i = 0; i < dims_count; ++i) {
> +dst[i] = pfun(params->v, src[i]);
> +}
> +} else {
> +const DnnOperand *input1 = &operands[input_operand_indexes[1]];
> +const float *src1 = input1->data;
> +for (int i = 0; i < dims_count; ++i) {
> +dst[i] = pfun(src[i], src1[i]);
> +}
> +}
> +}
> +static void math_binary_not_commutative(FunType pfun, const
> DnnLayerMathBinaryParams *params, const DnnOperand *input, DnnOperand
> *output, DnnOperand *operands, const int32_t *input_operand_indexes)
> +{
> +int dims_count;
> +const float *src;
> +float *dst;
> +dims_count = calculate_operand_dims_count(output);
> +src = input->data;
> +dst = output->data;
> +if (params->input0_broadcast) {
> +for (int i = 0; i < dims_count; ++i) {
> +dst[i] = pfun(params->v, src[i]);
> +}
> +} else if (params->input1_broadcast) {
> +for (int i = 0; i < dims_count; ++i) {
> +dst[i] = pfun(src[i], params->v);
> +}
> +} else {
> +const DnnOperand *input1 = &operands[input_operand_indexes[1]];
> +const float *src1 = input1->data;
> +for (int i = 0; i < dims_count; ++i) {
> +dst[i] = pfun(src[i], src1[i]);
> +}
> +}
> +}
> +
> int dnn_load_layer_math_binary(Layer *layer, AVIOContext
> *model_file_context, int file_size, int operands_num)
> {
> DnnLayerMathBinaryParams *params;
> @@ -82,9 +155,6 @@ int dnn_execute_layer_math_binary(DnnOperand
> *operands, const int32_t *input_ope
> const DnnOperand *input = &operands[input_operand_indexes[0]];
> DnnOperand *output = &operands[output_operand_index];
> const DnnLayerMathBinaryParams *params = (const
> DnnLayerMathBinaryParams *)parameters;
> -int dims_count;
> -const float *src;
> -float *dst;
>
> for (int i = 0; i < 4; ++i)
> output->dims[i] = input->dims[i];
> @@ -97,100 +167,24 @@ int dnn_execute_layer_math_binary(DnnOperand
> *operands, const int32_t *input_ope
> if (!output->data)
> return DNN_ERROR;
>
> -dims_count = calculate_operand_dims_count(output);
> -src = input->data;
> -dst = output->data;
> -
> -switch (params->bin_op) {
> +switch (params->bin_op){
you've removed a space between ) and {, and added a new space at the end of the
line.
Do not change this line.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/APIchanges: Remove version conflict separator
Andreas Rheinhardt (12020-08-21): > Added in 06f26512046de1a84e045d219e7fa211c37ad0e4. Sorry, thanks. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/APIchanges: Remove version conflict separator
Added in 06f26512046de1a84e045d219e7fa211c37ad0e4. Signed-off-by: Andreas Rheinhardt --- doc/APIchanges | 1 - 1 file changed, 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index c4a4471ecc..0054908e1e 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,7 +15,6 @@ libavutil: 2017-10-21 API changes, most recent first: -=== 2020-08-21 - xx - lavu 56.58.100 - avstring.h Deprecate av_d2str(). Use av_asprintf() instead. -- 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] avcodec/cfhd: add x86 SIMD
On Thu, Aug 20, 2020 at 12:53:05 +0200, Moritz Barsnick wrote: > Alas, with the patchset, the following command quickly terminates with > Illegal instruction in ff_cfhd_horiz_filter_clip10_sse2 (): The same on this CPU, obviously, because it also doesn't support SSE4.1: [barsnick@paradise ffmpeg]$ hwinfo --cpu 01: None 00.0: 10103 CPU [Created at cpu.462] Unique ID: rdCR.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "GenuineIntel" Model: 6.28.10 "Intel(R) Atom(TM) CPU D525 @ 1.80GHz" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,t m,pbe,syscall,nx,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,cpuid,aperfmperf,pni,dtes64,monitor,ds_cpl,tm2,ssse3,cx16 ,xtpr,pdcm,movbe,lahf_lm,dtherm Clock: 1800 MHz BogoMips: 3599.75 Cache: 512 kb Units/Processor: 4 Config Status: cfg=new, avail=yes, need=no, active=unknown [... x4] Additionally, with bigger_res.mov, I get a double-free: Compiler: gcc-10.2.1 Assembler: nasm-2.14.02 glibc-2.31 [barsnick@paradise ffmpeg]$ gdb -ex r --args ./ffmpeg_g -i bigger_res.mov -map 0:v -f null - GNU gdb (GDB) Fedora 9.1-5.fc32 [...] Reading symbols from ./ffmpeg_g... Starting program: /home/barsnick/Development/ffmpeg-stuff/ffmpeg/ffmpeg_g -i bigger_res.mov -map 0:v -f null - [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". ffmpeg version N-98786-g9ed82ca732 Copyright (c) 2000-2020 the FFmpeg developers built with gcc 10 (GCC) configuration: --disable-doc --disable-everything --disable-network --disable-vdpau --enable-indev=lavfi --enable-muxer=null --enable-demuxer='avi,mov' --enable-encoder='wrapped_avframe,rawvideo,pcm_s16le' --enable-decoder='rawvideo,pcm_f64le,cfhd,pc m_s16le' --enable-filter='color,testsrc,anoisesrc,null,aresample,scale' --enable-protocol='pipe,file' libavutil 56. 58.100 / 56. 58.100 libavcodec 58.100.100 / 58.100.100 libavformat58. 51.100 / 58. 51.100 libavdevice58. 11.101 / 58. 11.101 libavfilter 7. 87.100 / 7. 87.100 libswscale 5. 8.100 / 5. 8.100 libswresample 3. 8.100 / 3. 8.100 double free or corruption (out) Program received signal SIGABRT, Aborted. 0x77c939e5 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: dnf debuginfo-install glibc-2.31-4.fc32.x86_64 zlib-1.2.11-21.fc32.x86_64 (gdb) bt #0 0x77c939e5 in raise () from /lib64/libc.so.6 #1 0x77c7c895 in abort () from /lib64/libc.so.6 #2 0x77cd7857 in __libc_message () from /lib64/libc.so.6 #3 0x77cded7c in malloc_printerr () from /lib64/libc.so.6 #4 0x77ce03c0 in _int_free () from /lib64/libc.so.6 #5 0x00404ea0 in free_buffers (s=0x5fc6c0) at libavcodec/cfhd.c:222 #6 cfhd_close (avctx=) at libavcodec/cfhd.c:1331 #7 0x0040585b in avcodec_close (avctx=0x5ee180) at libavcodec/utils.c:1143 #8 0x00485453 in avformat_find_stream_info (ic=, options=) at libavformat/utils.c:4212 #9 0x0041954d in open_input_file (o=o@entry=0x7fffd480, filename=) at fftools/ffmpeg_opt.c:1186 #10 0x0041cbb8 in open_files (open_file=0x4189e0 , inout=0x58a603 "input", l=0x5eb058) at fftools/ffmpeg_opt.c:3303 #11 ffmpeg_parse_options (argc=argc@entry=8, argv=argv@entry=0x7fffd9a8) at fftools/ffmpeg_opt.c:3343 #12 0x00411c18 in main (argc=8, argv=0x7fffd9a8) at fftools/ffmpeg.c:4850 (gdb) disass $pc-32,$pc+32 Dump of assembler code from 0x77c939c5 to 0x77c93a05: 0x77c939c5 : add%dh,%al 0x77c939c7 : (bad) 0x77c939c8 : pushq 0x3d(%rdi) 0x77c939cb : mov%eax,%r8d 0x77c939ce : mov$0x8,%r10d 0x77c939d4 : xor%edx,%edx 0x77c939d6 : mov%r9,%rsi 0x77c939d9 : mov$0x2,%edi 0x77c939de : mov$0xe,%eax 0x77c939e3 : syscall => 0x77c939e5 : mov0x108(%rsp),%rax 0x77c939ed : sub%fs:0x28,%rax 0x77c939f6 : jne0x77c93a1c 0x77c939f8 : mov%r8d,%eax 0x77c939fb : add$0x118,%rsp 0x77c93a02 : retq 0x77c93a03 : nopl 0x0(%rax,%rax,1) End of assembler dump. (gdb) up 5 #5 0x00404ea0 in free_buffers (s=0x5fc6c0) at libavcodec/cfhd.c:222 222 av_freep(&s->plane[i].idwt_buf); (gdb) p &s->plane[i].idwt_buf $1 = (int16_t **) 0x606ba8 (gdb) p s->plane[i].idwt_buf $2 = (int16_t *) 0x0 No benchmarks here. :-( If you're still interested in benchmarks, my next try will be on Haswell. Cheers, Moritz _
[FFmpeg-devel] [PATCH 2/2] avfilter/vf_overlay: Remove superfluous ;
In a function body, a redundant ; is just a null statement that does nothing. Yet outside a function body, a superfluous ';' like one that exists if one adds a ';' immediately after a function body's closing brace is actually invalid C that compilers happen to accept. Yet when compiled in -pedantic mode, both GCC as well as Clang emit warnings for this like "ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]". The scenario described above existed in vf_overlay.c as a result of macro expansion. This commit fixes it. Signed-off-by: Andreas Rheinhardt --- libavfilter/vf_overlay.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c index b3a1ac1a09..79c654bb2d 100644 --- a/libavfilter/vf_overlay.c +++ b/libavfilter/vf_overlay.c @@ -595,8 +595,8 @@ static av_always_inline void blend_plane_##depth##_##nbits##bits(AVFilterContext dap += (1 << vsub) * dst->linesize[3] / bytes; \ } \ } -DEFINE_BLEND_PLANE(8, 8); -DEFINE_BLEND_PLANE(16, 10); +DEFINE_BLEND_PLANE(8, 8) +DEFINE_BLEND_PLANE(16, 10) #define DEFINE_ALPHA_COMPOSITE(depth, nbits) \ static inline void alpha_composite_##depth##_##nbits##bits(const AVFrame *src, const AVFrame *dst, \ @@ -647,8 +647,8 @@ static inline void alpha_composite_##depth##_##nbits##bits(const AVFrame *src, c sa += src->linesize[3] / bytes; \ } \ } -DEFINE_ALPHA_COMPOSITE(8, 8); -DEFINE_ALPHA_COMPOSITE(16, 10); +DEFINE_ALPHA_COMPOSITE(8, 8) +DEFINE_ALPHA_COMPOSITE(16, 10) #define DEFINE_BLEND_SLICE_YUV(depth, nbits) \ static av_always_inline void blend_slice_yuv_##depth##_##nbits##bits(AVFilterContext *ctx, \ @@ -679,8 +679,8 @@ static av_always_inline void blend_slice_yuv_##depth##_##nbits##bits(AVFilterCon alpha_composite_##depth##_##nbits##bits(src, dst, src_w, src_h, dst_w, dst_h, x, y,\ jobnr, nb_jobs); \ } -DEFINE_BLEND_SLICE_YUV(8, 8); -DEFINE_BLEND_SLICE_YUV(16, 10); +DEFINE_BLEND_SLICE_YUV(8, 8) +DEFINE_BLEND_SLICE_YUV(16, 10) static av_always_inline void blend_slice_planar_rgb(AVFilterContext *ctx, AVFrame *dst, const AVFrame *src, -- 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".
[FFmpeg-devel] [PATCH 1/2] avcodec/cfhd: Remove unused-but-set variable
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cfhd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 2b1db0ed8d..adfbcc460d 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -1463,7 +1463,7 @@ finish:
if (s->transform_type == 2 && s->sample_type == 1) {
int16_t *low, *high, *dst;
-int lowpass_height, lowpass_width, highpass_stride;
+int lowpass_height, lowpass_width;
ptrdiff_t dst_linesize;
for (plane = 0; plane < s->planes; plane++) {
@@ -1478,7 +1478,6 @@ finish:
lowpass_height = s->plane[plane].band[4][1].height;
lowpass_width = s->plane[plane].band[4][1].width;
-highpass_stride = s->plane[plane].band[4][1].stride;
if (s->progressive) {
dst = (int16_t *)pic->data[act_plane];
--
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] lavu/buffer: forward av_buffer_realloc() error code.
Nicolas George (12020-08-09): > Ping? Will apply next time I think about it if nobody objects and it > still applies. Pushed. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] dnn: move output name from DNNModel.set_input_output to DNNModule.execute_model
> -Original Message- > From: ffmpeg-devel On Behalf Of Guo, > Yejun > Sent: Friday, August 21, 2020 01:34 PM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [PATCH V2] dnn: move output name from > DNNModel.set_input_output to DNNModule.execute_model > > currently, output is set both at DNNModel.set_input_output and > DNNModule.execute_model, it makes sense that the output name is provided at > model inference time so all the output info is set at a single place. > > and so DNNModel.set_input_output is renamed to DNNModel.set_input > > Signed-off-by: Guo, Yejun > --- > v2: rebase with master > > libavfilter/dnn/dnn_backend_native.c | 44 +++-- > libavfilter/dnn/dnn_backend_native.h | 4 +- > libavfilter/dnn/dnn_backend_openvino.c | 50 +-- > libavfilter/dnn/dnn_backend_openvino.h | 2 +- > libavfilter/dnn/dnn_backend_tf.c | 87 > ++ > libavfilter/dnn/dnn_backend_tf.h | 2 +- > libavfilter/dnn_interface.h| 4 +- > libavfilter/vf_derain.c| 6 +-- > libavfilter/vf_dnn_processing.c| 9 ++-- > libavfilter/vf_sr.c| 11 +++-- > 10 files changed, 82 insertions(+), 137 deletions(-) > [...] > -- > 2.7.4 LGTM, all three backends(Native/TF/OV) function well. > > ___ > ffmpeg-devel 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] libavfilter/vf_overlay_cuda: Pass the main frame to the output if secondary frame is not available. now filter fails if secondary frame is not available due to e.g secondary
Alex Pokotilo (12020-08-21): > From b3739e33fa04a9292dc6584bd2f31460aa53d478 Mon Sep 17 00:00:00 2001 > From: Alex Pokotilo > Date: Fri, 21 Aug 2020 09:14:37 + > Subject: [PATCH] libavfilter/vf_overlay_cuda: Pass the main frame to the > output if secondary frame is not > available. now filter fails if secondary frame is not available due to e.g > secondary source delay. Your Git commit message is badly formatted. The format is: context: short summary on one line After an empty line, details if necessary, on several lines and wrapped at a reasonable line length. The fix may be correct, but your analysis of the problem does not prove it. Unless there is a serious bug in framesync, it will not call overlay_cuda_blend() without a secondary frame "due to e.g secondary source delay.", it will only do so if the stream has not yet begun or has ended. Please give more details on the exact circumstances you observe the issue. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/fifo: Remove unused functions and headers
Andreas Rheinhardt (12020-08-21): > Forgotten in 03c8fe49ea3f2a2444607e541dff15a1ccd7f0c2. > > Signed-off-by: Andreas Rheinhardt > --- > Two more headers in this file are unnecessary: > libavutil/channel_layout.h and video.h, but they were already > unnecessary before the last patch. Should I remove them in this commit > or in a separate commit? I think it is ok to remove them all at once. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avfilter/fifo: Remove unused functions and headers
Forgotten in 03c8fe49ea3f2a2444607e541dff15a1ccd7f0c2.
Signed-off-by: Andreas Rheinhardt
---
Two more headers in this file are unnecessary:
libavutil/channel_layout.h and video.h, but they were already
unnecessary before the last patch. Should I remove them in this commit
or in a separate commit?
libavfilter/fifo.c | 47 --
1 file changed, 47 deletions(-)
diff --git a/libavfilter/fifo.c b/libavfilter/fifo.c
index 70f4876a50..2e79c7ff55 100644
--- a/libavfilter/fifo.c
+++ b/libavfilter/fifo.c
@@ -23,11 +23,9 @@
* FIFO buffering filter
*/
-#include "libavutil/avassert.h"
#include "libavutil/channel_layout.h"
#include "libavutil/common.h"
#include "libavutil/mathematics.h"
-#include "libavutil/samplefmt.h"
#include "audio.h"
#include "avfilter.h"
@@ -98,51 +96,6 @@ static void queue_pop(FifoContext *s)
s->root.next = tmp;
}
-/**
- * Move data pointers and pts offset samples forward.
- */
-static void buffer_offset(AVFilterLink *link, AVFrame *frame,
- int offset)
-{
-int nb_channels = link->channels;
-int planar = av_sample_fmt_is_planar(link->format);
-int planes = planar ? nb_channels : 1;
-int block_align = av_get_bytes_per_sample(link->format) * (planar ? 1 :
nb_channels);
-int i;
-
-av_assert0(frame->nb_samples > offset);
-
-for (i = 0; i < planes; i++)
-frame->extended_data[i] += block_align * offset;
-if (frame->data != frame->extended_data)
-memcpy(frame->data, frame->extended_data,
- FFMIN(planes, FF_ARRAY_ELEMS(frame->data)) *
sizeof(*frame->data));
-frame->linesize[0] -= block_align*offset;
-frame->nb_samples -= offset;
-
-if (frame->pts != AV_NOPTS_VALUE) {
-frame->pts += av_rescale_q(offset, (AVRational){1, link->sample_rate},
- link->time_base);
-}
-}
-
-static int calc_ptr_alignment(AVFrame *frame)
-{
-int planes = av_sample_fmt_is_planar(frame->format) ?
- frame->channels : 1;
-int min_align = 128;
-int p;
-
-for (p = 0; p < planes; p++) {
-int cur_align = 128;
-while ((intptr_t)frame->extended_data[p] % cur_align)
-cur_align >>= 1;
-if (cur_align < min_align)
-min_align = cur_align;
-}
-return min_align;
-}
-
static int request_frame(AVFilterLink *outlink)
{
FifoContext *s = outlink->src->priv;
--
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".
[FFmpeg-devel] [PATCH] libavfilter/vf_overlay_cuda: Pass the main frame to the output if secondary frame is not available. now filter fails if secondary frame is not available due to e.g secondary sou
From b3739e33fa04a9292dc6584bd2f31460aa53d478 Mon Sep 17 00:00:00 2001
From: Alex Pokotilo
Date: Fri, 21 Aug 2020 09:14:37 +
Subject: [PATCH] libavfilter/vf_overlay_cuda: Pass the main frame to the output if secondary frame is not
available. now filter fails if secondary frame is not available due to e.g secondary source delay.
---
libavfilter/vf_overlay_cuda.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_overlay_cuda.c b/libavfilter/vf_overlay_cuda.c
index 2f0f860e50..355cb39019 100644
--- a/libavfilter/vf_overlay_cuda.c
+++ b/libavfilter/vf_overlay_cuda.c
@@ -157,8 +157,8 @@ static int overlay_cuda_blend(FFFrameSync *fs)
if (ret < 0)
return ret;
-if (!input_main || !input_overlay)
-return AVERROR_BUG;
+if (!input_overlay)
+return ff_filter_frame(outlink, input_main);
ret = av_frame_make_writable(input_main);
if (ret < 0) {
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavu/avstring: deprecate av_d2str().
Nicolas George (12020-08-09): > I never pushed this. I will next time I think about it. Pushed. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/fifo: Remove unused functions and header
Andreas Rheinhardt (12020-08-21): > Forgotten in 03c8fe49ea3f2a2444607e541dff15a1ccd7f0c2. > > Signed-off-by: Andreas Rheinhardt Good catch, thank you. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/fifo: Remove unused functions and header
Forgotten in 03c8fe49ea3f2a2444607e541dff15a1ccd7f0c2.
Signed-off-by: Andreas Rheinhardt
---
Patchwork warned about this [1].
[1]:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200812172558.262021-4-geo...@nsup.org/
libavfilter/fifo.c | 46 --
1 file changed, 46 deletions(-)
diff --git a/libavfilter/fifo.c b/libavfilter/fifo.c
index 70f4876a50..9cccbbebaa 100644
--- a/libavfilter/fifo.c
+++ b/libavfilter/fifo.c
@@ -23,7 +23,6 @@
* FIFO buffering filter
*/
-#include "libavutil/avassert.h"
#include "libavutil/channel_layout.h"
#include "libavutil/common.h"
#include "libavutil/mathematics.h"
@@ -98,51 +97,6 @@ static void queue_pop(FifoContext *s)
s->root.next = tmp;
}
-/**
- * Move data pointers and pts offset samples forward.
- */
-static void buffer_offset(AVFilterLink *link, AVFrame *frame,
- int offset)
-{
-int nb_channels = link->channels;
-int planar = av_sample_fmt_is_planar(link->format);
-int planes = planar ? nb_channels : 1;
-int block_align = av_get_bytes_per_sample(link->format) * (planar ? 1 :
nb_channels);
-int i;
-
-av_assert0(frame->nb_samples > offset);
-
-for (i = 0; i < planes; i++)
-frame->extended_data[i] += block_align * offset;
-if (frame->data != frame->extended_data)
-memcpy(frame->data, frame->extended_data,
- FFMIN(planes, FF_ARRAY_ELEMS(frame->data)) *
sizeof(*frame->data));
-frame->linesize[0] -= block_align*offset;
-frame->nb_samples -= offset;
-
-if (frame->pts != AV_NOPTS_VALUE) {
-frame->pts += av_rescale_q(offset, (AVRational){1, link->sample_rate},
- link->time_base);
-}
-}
-
-static int calc_ptr_alignment(AVFrame *frame)
-{
-int planes = av_sample_fmt_is_planar(frame->format) ?
- frame->channels : 1;
-int min_align = 128;
-int p;
-
-for (p = 0; p < planes; p++) {
-int cur_align = 128;
-while ((intptr_t)frame->extended_data[p] % cur_align)
-cur_align >>= 1;
-if (cur_align < min_align)
-min_align = cur_align;
-}
-return min_align;
-}
-
static int request_frame(AVFilterLink *outlink)
{
FifoContext *s = outlink->src->priv;
--
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 v2] avformat/http, tls: honor http_proxy command line variable for HTTPS
Hej Moritz,
On Fri, 21 Aug 2020, Moritz Barsnick wrote:
Patch version 2 attached, with added documentation.
LGTM, with one small nit:
@@ -49,6 +50,7 @@ typedef struct TLSShared {
{"cert_file", "Certificate file",offsetof(pstruct,
options_field . cert_file), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
{"key_file", "Private key file",offsetof(pstruct,
options_field . key_file), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
{"listen", "Listen for incoming connections", offsetof(pstruct,
options_field . listen),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags = TLS_OPTFL }, \
+{"http_proxy", "set proxy to tunnel through when using HTTPS",
offsetof(pstruct, options_field . http_proxy), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
{"verifyhost", "Verify against a specific hostname", offsetof(pstruct,
options_field . host), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }
I'd remove the "when using HTTPS" bit here.
// 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] [PATCH V3 2/2] dnn_backend_native_layer_mathbinary: change to function pointer
Signed-off-by: Mingyu Yin
---
.../dnn/dnn_backend_native_layer_mathbinary.c | 166 +-
1 file changed, 80 insertions(+), 86 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
index 6876aaf2c6..6738acc6ce 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
@@ -27,6 +27,79 @@
#include "libavutil/avassert.h"
#include "dnn_backend_native_layer_mathbinary.h"
+typedef float (*FunType)(const float src, float dst);
+FunType pfun;
+
+static float sub(float src, float dst)
+{
+return src - dst;
+}
+static float add(float src, float dst)
+{
+return src + dst;
+}
+static float mul(float src, float dst)
+{
+return src * dst;
+}
+static float realdiv(float src, float dst)
+{
+return src / dst;
+}
+static float minimum(float src, float dst)
+{
+return FFMIN(src, dst);
+}
+static float floormod(float src, float dst)
+{
+return (float)((int)(src) % (int)(dst));
+}
+
+static void math_binary_commutative(FunType pfun, const
DnnLayerMathBinaryParams *params, const DnnOperand *input, DnnOperand *output,
DnnOperand *operands, const int32_t *input_operand_indexes)
+{
+int dims_count;
+const float *src;
+float *dst;
+dims_count = calculate_operand_dims_count(output);
+src = input->data;
+dst = output->data;
+if (params->input0_broadcast || params->input1_broadcast) {
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(params->v, src[i]);
+}
+} else {
+const DnnOperand *input1 = &operands[input_operand_indexes[1]];
+const float *src1 = input1->data;
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(src[i], src1[i]);
+}
+}
+}
+static void math_binary_not_commutative(FunType pfun, const
DnnLayerMathBinaryParams *params, const DnnOperand *input, DnnOperand *output,
DnnOperand *operands, const int32_t *input_operand_indexes)
+{
+int dims_count;
+const float *src;
+float *dst;
+dims_count = calculate_operand_dims_count(output);
+src = input->data;
+dst = output->data;
+if (params->input0_broadcast) {
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(params->v, src[i]);
+}
+} else if (params->input1_broadcast) {
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(src[i], params->v);
+}
+} else {
+const DnnOperand *input1 = &operands[input_operand_indexes[1]];
+const float *src1 = input1->data;
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(src[i], src1[i]);
+}
+}
+}
+
int dnn_load_layer_math_binary(Layer *layer, AVIOContext *model_file_context,
int file_size, int operands_num)
{
DnnLayerMathBinaryParams *params;
@@ -82,9 +155,6 @@ int dnn_execute_layer_math_binary(DnnOperand *operands,
const int32_t *input_ope
const DnnOperand *input = &operands[input_operand_indexes[0]];
DnnOperand *output = &operands[output_operand_index];
const DnnLayerMathBinaryParams *params = (const DnnLayerMathBinaryParams
*)parameters;
-int dims_count;
-const float *src;
-float *dst;
for (int i = 0; i < 4; ++i)
output->dims[i] = input->dims[i];
@@ -97,100 +167,24 @@ int dnn_execute_layer_math_binary(DnnOperand *operands,
const int32_t *input_ope
if (!output->data)
return DNN_ERROR;
-dims_count = calculate_operand_dims_count(output);
-src = input->data;
-dst = output->data;
-
-switch (params->bin_op) {
+switch (params->bin_op){
case DMBO_SUB:
-if (params->input0_broadcast) {
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = params->v - src[i];
-}
-} else if (params->input1_broadcast) {
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = src[i] - params->v;
-}
-} else {
-const DnnOperand *input1 = &operands[input_operand_indexes[1]];
-const float *src1 = input1->data;
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = src[i] - src1[i];
-}
-}
+math_binary_not_commutative(sub, params, input, output, operands,
input_operand_indexes);
return 0;
case DMBO_ADD:
-if (params->input0_broadcast || params->input1_broadcast) {
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = params->v + src[i];
-}
-} else {
-const DnnOperand *input1 = &operands[input_operand_indexes[1]];
-const float *src1 = input1->data;
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = src[i] + src1[i];
-}
-}
+math_binary_commutative(add, params, input, output, operands,
input_operand_indexes);
return 0
[FFmpeg-devel] [PATCH V3 1/2] dnn_backend_native_layer_mathbinary: add floormod support
Signed-off-by: Mingyu Yin
---
.../dnn/dnn_backend_native_layer_mathbinary.c | 17 +
.../dnn/dnn_backend_native_layer_mathbinary.h | 1 +
tests/dnn/dnn-layer-mathbinary-test.c | 5 +
tools/python/convert_from_tensorflow.py | 2 +-
tools/python/convert_header.py | 2 +-
5 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
index dd42c329a9..6876aaf2c6 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
@@ -175,6 +175,23 @@ int dnn_execute_layer_math_binary(DnnOperand *operands,
const int32_t *input_ope
}
}
return 0;
+case DMBO_FLOORMOD:
+if (params->input0_broadcast) {
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = (int)(params->v) % (int)(src[i]);
+}
+} else if (params->input1_broadcast) {
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = (int)(src[i]) % (int)(params->v);
+}
+} else {
+const DnnOperand *input1 = &operands[input_operand_indexes[1]];
+const float *src1 = input1->data;
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = (int)(src[i]) % (int)(src1[i]);
+}
+}
+return 0;
default:
return -1;
}
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.h
b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.h
index 0acf3b0ea0..9525685afa 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.h
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.h
@@ -36,6 +36,7 @@ typedef enum {
DMBO_MUL = 2,
DMBO_REALDIV = 3,
DMBO_MINIMUM = 4,
+DMBO_FLOORMOD = 5,
DMBO_COUNT
} DNNMathBinaryOperation;
diff --git a/tests/dnn/dnn-layer-mathbinary-test.c
b/tests/dnn/dnn-layer-mathbinary-test.c
index e7f8f8557c..e5f6a12939 100644
--- a/tests/dnn/dnn-layer-mathbinary-test.c
+++ b/tests/dnn/dnn-layer-mathbinary-test.c
@@ -40,6 +40,8 @@ static float get_expected(float f1, float f2,
DNNMathBinaryOperation op)
return f1 / f2;
case DMBO_MINIMUM:
return (f1 < f2) ? f1 : f2;
+case DMBO_FLOORMOD:
+return (int)(f1) % (int)(f2);
default:
av_assert0(!"not supported yet");
return 0.f;
@@ -205,5 +207,8 @@ int main(int argc, char **argv)
if (test(DMBO_MINIMUM))
return 1;
+if (test(DMBO_FLOORMOD))
+return 1;
+
return 0;
}
diff --git a/tools/python/convert_from_tensorflow.py
b/tools/python/convert_from_tensorflow.py
index 3c14bed487..1762091fdd 100644
--- a/tools/python/convert_from_tensorflow.py
+++ b/tools/python/convert_from_tensorflow.py
@@ -73,7 +73,7 @@ class TFConverter:
self.conv2d_scopename_inputname_dict = {}
self.op2code = {'Conv2D':1, 'DepthToSpace':2, 'MirrorPad':3,
'Maximum':4,
'MathBinary':5, 'MathUnary':6, 'AvgPool':7}
-self.mathbin2code = {'Sub':0, 'Add':1, 'Mul':2, 'RealDiv':3,
'Minimum':4}
+self.mathbin2code = {'Sub':0, 'Add':1, 'Mul':2, 'RealDiv':3,
'Minimum':4, 'FloorMod':5}
self.mathun2code = {'Abs':0, 'Sin':1, 'Cos':2, 'Tan':3, 'Asin':4,
'Acos':5, 'Atan':6, 'Sinh':7, 'Cosh':8, 'Tanh':9, 'Asinh':10,
'Acosh':11, 'Atanh':12, 'Ceil':13, 'Floor':14, 'Round':15}
diff --git a/tools/python/convert_header.py b/tools/python/convert_header.py
index 747c8776eb..782a6341f9 100644
--- a/tools/python/convert_header.py
+++ b/tools/python/convert_header.py
@@ -23,4 +23,4 @@ str = 'FFMPEGDNNNATIVE'
major = 1
# increase minor when we don't have to re-convert the model file
-minor = 21
+minor = 22
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: add RPZA encoder
On 7/19/20, James Almer wrote:
> On 7/16/2020 11:54 AM, Paul B Mahol wrote:
>> +if (!s->prev_frame->data[0]) {
>> +s->first_frame = 1;
>> +ret = ff_get_buffer(avctx, s->prev_frame, 0);
>
> This is for decoders only. Fill format, width and height on
> s->prev_frame then call av_frame_get_buffer() instead.
Fixed locally. Gonna apply soon.
>
>> +if (ret < 0)
>> +return ret;
>> +} else {
>> +s->first_frame = 0;
>> +}
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avformat/http, tls: honor http_proxy command line variable for HTTPS
Patch version 2 attached, with added documentation.
Moritz
From 2f2a43e4c684cd4bfda420bbedf5125dd78b3b34 Mon Sep 17 00:00:00 2001
From: Moritz Barsnick
Date: Thu, 20 Aug 2020 17:49:14 +0200
Subject: [PATCH] avformat/http,tls: honor http_proxy command line variable for
HTTPS
Add the "http_proxy" option and its handling to the "tls" protocol,
pass the option from the "https" protocol.
The "https" protocol already defines the "http_proxy" command line
option, like the "http" protocol does. The "http" protocol properly
honors that command line option in addition to the environment
variable. The "https" protocol doesn't, because the proxy is
evaluated in the underlying "tls" protocol, which doesn't have this
option, and thus only handles the environment variable, which it
has access to.
Fixes #7223.
Signed-off-by: Moritz Barsnick
---
doc/protocols.texi | 4
libavformat/http.c | 6 ++
libavformat/tls.c | 2 +-
libavformat/tls.h | 2 ++
4 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 7b3df96fda..603943023c 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1708,6 +1708,10 @@ A file containing the private key for the certificate.
If enabled, listen for connections on the provided port, and assume
the server role in the handshake instead of the client role.
+@item http_proxy
+The HTTP proxy to tunnel through, e.g. @code{http://example.com:1234}.
+The proxy must support the CONNECT method.
+
@end table
Example command lines:
diff --git a/libavformat/http.c b/libavformat/http.c
index 6c39da1a8b..21584bdce9 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -213,6 +213,12 @@ static int http_open_cnx_internal(URLContext *h,
AVDictionary **options)
use_proxy = 0;
if (port < 0)
port = 443;
+/* pass http_proxy to underlying protocol */
+if (s->http_proxy) {
+err = av_dict_set(options, "http_proxy", s->http_proxy, 0);
+if (err < 0)
+return err;
+}
}
if (port < 0)
port = 80;
diff --git a/libavformat/tls.c b/libavformat/tls.c
index 10e0792e29..302c0f8d59 100644
--- a/libavformat/tls.c
+++ b/libavformat/tls.c
@@ -89,7 +89,7 @@ int ff_tls_open_underlying(TLSShared *c, URLContext *parent,
const char *uri, AV
if (!c->host && !(c->host = av_strdup(c->underlying_host)))
return AVERROR(ENOMEM);
-proxy_path = getenv("http_proxy");
+proxy_path = c->http_proxy ? c->http_proxy : getenv("http_proxy");
use_proxy = !ff_http_match_no_proxy(getenv("no_proxy"),
c->underlying_host) &&
proxy_path && av_strstart(proxy_path, "http://";, NULL);
diff --git a/libavformat/tls.h b/libavformat/tls.h
index beb19d6d55..0c52ff3be6 100644
--- a/libavformat/tls.h
+++ b/libavformat/tls.h
@@ -34,6 +34,7 @@ typedef struct TLSShared {
int listen;
char *host;
+char *http_proxy;
char underlying_host[200];
int numerichost;
@@ -49,6 +50,7 @@ typedef struct TLSShared {
{"cert_file", "Certificate file",offsetof(pstruct,
options_field . cert_file), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
{"key_file", "Private key file",offsetof(pstruct,
options_field . key_file), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
{"listen", "Listen for incoming connections", offsetof(pstruct,
options_field . listen),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags =
TLS_OPTFL }, \
+{"http_proxy", "set proxy to tunnel through when using HTTPS",
offsetof(pstruct, options_field . http_proxy), AV_OPT_TYPE_STRING, .flags =
TLS_OPTFL }, \
{"verifyhost", "Verify against a specific hostname", offsetof(pstruct,
options_field . host), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }
int ff_tls_open_underlying(TLSShared *c, URLContext *parent, const char *uri,
AVDictionary **options);
--
2.26.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 v2 1/2] qsv: needn't load user plugin since libmfx 1.28
On Fri, Aug 21, 2020 at 9:29 AM Xiang, Haihao
wrote:
> On Fri, 2020-08-21 at 05:48 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Haihao Xiang
> > > Sent: Friday, August 21, 2020 7:23 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Haihao Xiang
> > > Subject: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user plugin
> since
> > > libmfx 1.28
> > >
> > > MFXVideoUSER_Load call is redundant since libmfx 1.28
> > > ---
> > > Fixed merge conflict when applying this patch by 'git am'
> > >
> > > libavcodec/qsv.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index
> > > 17720070f1..56a30ad642 100644
> > > --- a/libavcodec/qsv.c
> > > +++ b/libavcodec/qsv.c
> > > @@ -19,7 +19,6 @@
> > > */
> > >
> > > #include
> > > -#include
> > > #include
> > >
> > > #include
> > > @@ -36,6 +35,10 @@
> > > #include "avcodec.h"
> > > #include "qsv_internal.h"
> > >
> > > +#if !QSV_VERSION_ATLEAST(1, 28)
> > > +#include
> > > +#endif
> > > +
> > > #if QSV_VERSION_ATLEAST(1, 12)
> > > #include "mfx/mfxvp8.h"
> > > #endif
> > > @@ -295,6 +298,9 @@ enum AVPictureType ff_qsv_map_pictype(int
> > > mfx_pic_type) static int qsv_load_plugins(mfxSession session, const
> char
> > > *load_plugins,
> > > void *logctx) {
> > > +#if QSV_VERSION_ATLEAST(1, 28)
> > > +return 0;
> > > +#else
> > > if (!load_plugins || !*load_plugins)
> > > return 0;
> > >
> > > @@ -340,6 +346,7 @@ load_plugin_fail:
> > > }
> > >
> > > return 0;
> > > +#endif
> > >
> > > }
> >
> >
> > Hi,
> >
> > Are you sure this check is right? You are checking the libmfx version
> > against which ffmpeg is compiled.
> >
> > What happens, when a graphics driver supports only API level 1.21?
> >
>
> I understand your concern, however lots of features in FFmpeg are
> disabled/enabled against api version at compile-time.
>
>
have you checked if runtime checks with QSV_RUNTIME_VERSION_ATLEAST can be
avoided?
regards
Max
___
ffmpeg-devel 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] qsv: remove audio error code
>
>
> On Thu, 2020-08-20 at 02:26 +0200, Thilo Borgmann wrote:
>> Am 20.08.20 um 02:13 schrieb Xiang, Haihao:
>>> On Wed, 2020-08-19 at 13:53 +0200, Nicolas George wrote:
Haihao Xiang (12020-08-19):
> ---
> libavcodec/qsv.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index faa424bb68..6776b745b9 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -143,8 +143,6 @@ static const struct {
> { MFX_ERR_INVALID_VIDEO_PARAM, AVERROR(EINVAL), "invalid video
> parameters" },
> { MFX_ERR_UNDEFINED_BEHAVIOR, AVERROR_BUG, "undefined
> behavior" },
> { MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device
> failed"},
> -{ MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL), "incompatible
> audio parameters"},
> -{ MFX_ERR_INVALID_AUDIO_PARAM, AVERROR(EINVAL), "invalid audio
> parameters" },
>
> { MFX_WRN_IN_EXECUTION, 0, "operation in
> execution" },
> { MFX_WRN_DEVICE_BUSY, 0, "device
> busy" },
> @@ -154,7 +152,6 @@ static const struct {
> { MFX_WRN_VALUE_NOT_CHANGED,0, "value is
> saturated" },
> { MFX_WRN_OUT_OF_RANGE, 0, "value out of
> range" },
> { MFX_WRN_FILTER_SKIPPED, 0, "filter
> skipped" },
> -{ MFX_WRN_INCOMPATIBLE_AUDIO_PARAM, 0, "incompatible
> audio parameters"},
> };
>
> int ff_qsv_map_error(mfxStatus mfx_err, const char **desc)
Why?
>>>
>>> qsv in FFmpeg is for video only, actually the SDK is for HW accelerated
>>> video
>>> decode, encode and filtering now, see
>>> https://github.com/Intel-Media-SDK/MediaSDK#intel-media-sdk.
>>
>> This seems like a generic translation from the library errors to FF error
>> codes. So even if we'll never touch the audio functionality of it, I'd prefer
>> to have that struct complete already.
>>
>
> In general, I agree with you. But the SDK no longer support audio and the
> corresponding code might be deprecated or removed in the future, so I'd prefer
> to do a clean up (of course we may add some #ifdef.. #endif)
Hm it's ugly yet used in other places in qsv.c already to do the same. So you
should also make use of it there IMHO.
> BTW did you not reply the mailing list? I didn't see your comment in the
> patchwork (
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200819061023.443304-2-haihao.xi...@intel.com/
> )
Oh sorry I messed that up, so I included the short history now, thx!
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user plugin since libmfx 1.28
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Xiang, Haihao
> Sent: Friday, August 21, 2020 9:29 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user plugin
> since libmfx 1.28
>
> On Fri, 2020-08-21 at 05:48 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Haihao Xiang
> > > Sent: Friday, August 21, 2020 7:23 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Haihao Xiang
> > > Subject: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user plugin
> > > since libmfx 1.28
> > >
> > > MFXVideoUSER_Load call is redundant since libmfx 1.28
> > > ---
> > > Fixed merge conflict when applying this patch by 'git am'
> > >
> > > libavcodec/qsv.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index
> > > 17720070f1..56a30ad642 100644
> > > --- a/libavcodec/qsv.c
> > > +++ b/libavcodec/qsv.c
> > > @@ -19,7 +19,6 @@
> > > */
> > >
> > > #include
> > > -#include
> > > #include
> > >
> > > #include
> > > @@ -36,6 +35,10 @@
> > > #include "avcodec.h"
> > > #include "qsv_internal.h"
> > >
> > > +#if !QSV_VERSION_ATLEAST(1, 28)
> > > +#include
> > > +#endif
> > > +
> > > #if QSV_VERSION_ATLEAST(1, 12)
> > > #include "mfx/mfxvp8.h"
> > > #endif
> > > @@ -295,6 +298,9 @@ enum AVPictureType ff_qsv_map_pictype(int
> > > mfx_pic_type) static int qsv_load_plugins(mfxSession session, const
> > > char *load_plugins,
> > > void *logctx) {
> > > +#if QSV_VERSION_ATLEAST(1, 28)
> > > +return 0;
> > > +#else
> > > if (!load_plugins || !*load_plugins)
> > > return 0;
> > >
> > > @@ -340,6 +346,7 @@ load_plugin_fail:
> > > }
> > >
> > > return 0;
> > > +#endif
> > >
> > > }
> >
> >
> > Hi,
> >
> > Are you sure this check is right? You are checking the libmfx version
> > against which ffmpeg is compiled.
> >
> > What happens, when a graphics driver supports only API level 1.21?
> >
>
> I understand your concern, however lots of features in FFmpeg are
> disabled/enabled against api version at compile-time.
That is in no way an argument to break compatibility with downlevel
drivers without any need. Things are working fine without that patch
for all API versions.
If you really want to avoid the plugin-load, then you should check the
driver's API level at runtime.
Kind regards,
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user plugin since libmfx 1.28
On Fri, 2020-08-21 at 05:48 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Haihao Xiang
> > Sent: Friday, August 21, 2020 7:23 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Haihao Xiang
> > Subject: [FFmpeg-devel] [PATCH v2 1/2] qsv: needn't load user plugin since
> > libmfx 1.28
> >
> > MFXVideoUSER_Load call is redundant since libmfx 1.28
> > ---
> > Fixed merge conflict when applying this patch by 'git am'
> >
> > libavcodec/qsv.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index
> > 17720070f1..56a30ad642 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -19,7 +19,6 @@
> > */
> >
> > #include
> > -#include
> > #include
> >
> > #include
> > @@ -36,6 +35,10 @@
> > #include "avcodec.h"
> > #include "qsv_internal.h"
> >
> > +#if !QSV_VERSION_ATLEAST(1, 28)
> > +#include
> > +#endif
> > +
> > #if QSV_VERSION_ATLEAST(1, 12)
> > #include "mfx/mfxvp8.h"
> > #endif
> > @@ -295,6 +298,9 @@ enum AVPictureType ff_qsv_map_pictype(int
> > mfx_pic_type) static int qsv_load_plugins(mfxSession session, const char
> > *load_plugins,
> > void *logctx) {
> > +#if QSV_VERSION_ATLEAST(1, 28)
> > +return 0;
> > +#else
> > if (!load_plugins || !*load_plugins)
> > return 0;
> >
> > @@ -340,6 +346,7 @@ load_plugin_fail:
> > }
> >
> > return 0;
> > +#endif
> >
> > }
>
>
> Hi,
>
> Are you sure this check is right? You are checking the libmfx version
> against which ffmpeg is compiled.
>
> What happens, when a graphics driver supports only API level 1.21?
>
I understand your concern, however lots of features in FFmpeg are
disabled/enabled against api version at compile-time.
Thanks
Haihao
> Regards,
> softworkz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@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] dnn_backend_native_layer_mathbinary: change to function pointer
Signed-off-by: Mingyu Yin
---
.../dnn/dnn_backend_native_layer_mathbinary.c | 166 +-
1 file changed, 80 insertions(+), 86 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
index 6876aaf2c6..6738acc6ce 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathbinary.c
@@ -27,6 +27,79 @@
#include "libavutil/avassert.h"
#include "dnn_backend_native_layer_mathbinary.h"
+typedef float (*FunType)(const float src, float dst);
+FunType pfun;
+
+static float sub(float src, float dst)
+{
+return src - dst;
+}
+static float add(float src, float dst)
+{
+return src + dst;
+}
+static float mul(float src, float dst)
+{
+return src * dst;
+}
+static float realdiv(float src, float dst)
+{
+return src / dst;
+}
+static float minimum(float src, float dst)
+{
+return FFMIN(src, dst);
+}
+static float floormod(float src, float dst)
+{
+return (float)((int)(src) % (int)(dst));
+}
+
+static void math_binary_commutative(FunType pfun, const
DnnLayerMathBinaryParams *params, const DnnOperand *input, DnnOperand *output,
DnnOperand *operands, const int32_t *input_operand_indexes)
+{
+int dims_count;
+const float *src;
+float *dst;
+dims_count = calculate_operand_dims_count(output);
+src = input->data;
+dst = output->data;
+if (params->input0_broadcast || params->input1_broadcast) {
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(params->v, src[i]);
+}
+} else {
+const DnnOperand *input1 = &operands[input_operand_indexes[1]];
+const float *src1 = input1->data;
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(src[i], src1[i]);
+}
+}
+}
+static void math_binary_not_commutative(FunType pfun, const
DnnLayerMathBinaryParams *params, const DnnOperand *input, DnnOperand *output,
DnnOperand *operands, const int32_t *input_operand_indexes)
+{
+int dims_count;
+const float *src;
+float *dst;
+dims_count = calculate_operand_dims_count(output);
+src = input->data;
+dst = output->data;
+if (params->input0_broadcast) {
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(params->v, src[i]);
+}
+} else if (params->input1_broadcast) {
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(src[i], params->v);
+}
+} else {
+const DnnOperand *input1 = &operands[input_operand_indexes[1]];
+const float *src1 = input1->data;
+for (int i = 0; i < dims_count; ++i) {
+dst[i] = pfun(src[i], src1[i]);
+}
+}
+}
+
int dnn_load_layer_math_binary(Layer *layer, AVIOContext *model_file_context,
int file_size, int operands_num)
{
DnnLayerMathBinaryParams *params;
@@ -82,9 +155,6 @@ int dnn_execute_layer_math_binary(DnnOperand *operands,
const int32_t *input_ope
const DnnOperand *input = &operands[input_operand_indexes[0]];
DnnOperand *output = &operands[output_operand_index];
const DnnLayerMathBinaryParams *params = (const DnnLayerMathBinaryParams
*)parameters;
-int dims_count;
-const float *src;
-float *dst;
for (int i = 0; i < 4; ++i)
output->dims[i] = input->dims[i];
@@ -97,100 +167,24 @@ int dnn_execute_layer_math_binary(DnnOperand *operands,
const int32_t *input_ope
if (!output->data)
return DNN_ERROR;
-dims_count = calculate_operand_dims_count(output);
-src = input->data;
-dst = output->data;
-
-switch (params->bin_op) {
+switch (params->bin_op){
case DMBO_SUB:
-if (params->input0_broadcast) {
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = params->v - src[i];
-}
-} else if (params->input1_broadcast) {
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = src[i] - params->v;
-}
-} else {
-const DnnOperand *input1 = &operands[input_operand_indexes[1]];
-const float *src1 = input1->data;
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = src[i] - src1[i];
-}
-}
+math_binary_not_commutative(sub, params, input, output, operands,
input_operand_indexes);
return 0;
case DMBO_ADD:
-if (params->input0_broadcast || params->input1_broadcast) {
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = params->v + src[i];
-}
-} else {
-const DnnOperand *input1 = &operands[input_operand_indexes[1]];
-const float *src1 = input1->data;
-for (int i = 0; i < dims_count; ++i) {
-dst[i] = src[i] + src1[i];
-}
-}
+math_binary_commutative(add, params, input, output, operands,
input_operand_indexes);
return 0
Re: [FFmpeg-devel] [PATCH] fix memory leak in qsvenc.c
> Seems reasonable, any special reason to reorder av_freep(&sync)?
I want to combine "bs" and it's children structures disposal in the same
order as in
ff_qsv_encode where we have
#if QSV_VERSION_ATLEAST(1, 26)
if (avctx->codec_id == AV_CODEC_ID_H264) {
enc_buf = bs->ExtParam;
enc_info = (mfxExtAVCEncodedFrameInfo *)(*bs->ExtParam);
ff_side_data_set_encoder_stats(&new_pkt,
enc_info->QP * FF_QP2LAMBDA, NULL, 0, pict_type);
av_freep(&enc_info);
av_freep(&enc_buf);
}
#endif
av_freep(&bs);
av_freep(&sync);
On Fri, Aug 21, 2020 at 11:59 AM Xiang, Haihao
wrote:
>
> Thanks for fixing the memory leak in qsv, it looks good to me.
>
> Thanks for review
___
ffmpeg-devel 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".
