[FFmpeg-devel] [PATCH] avformat/file: Fix file delete for Windows
From: Karthick Jeyapal Fixes bug id : 7638 --- libavformat/file.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/libavformat/file.c b/libavformat/file.c index 1d321c4..e613b91 100644 --- a/libavformat/file.c +++ b/libavformat/file.c @@ -173,7 +173,11 @@ static int file_delete(URLContext *h) av_strstart(filename, "file:", ); ret = rmdir(filename); -if (ret < 0 && errno == ENOTDIR) +if (ret < 0 && (errno == ENOTDIR +# ifdef _WIN32 +|| errno == EINVAL +# endif +)) ret = unlink(filename); if (ret < 0) return AVERROR(errno); -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: skip disabled streams
On 31-12-2018 06:50 AM, Michael Niedermayer wrote:
On Sat, Dec 29, 2018 at 04:39:18PM +0530, Gyan wrote:
At Michael's suggestion, earlier patch broken into two. This one stops
discarded streams from being processed. A few more checks added.
Gyan
[...]
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index d4851a2cd8..4ee7dbbe01 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -268,7 +268,7 @@ static int opt_map(void *optctx, const char *opt, const
char *arg)
{
OptionsContext *o = optctx;
StreamMap *m = NULL;
-int i, negative = 0, file_idx;
+int i, negative = 0, file_idx, disabled;
int sync_file_idx = -1, sync_stream_idx = 0;
char *p, *sync;
char *map;
@@ -303,6 +303,11 @@ static int opt_map(void *optctx, const char *opt, const
char *arg)
"match any streams.\n", arg);
exit_program(1);
}
+if (input_streams[input_files[sync_file_idx]->ist_index +
sync_stream_idx]->user_set_discard == AVDISCARD_ALL) {
+av_log(NULL, AV_LOG_FATAL, "Sync stream specification in map %s matches
a disabled input "
+ "stream.\n", arg);
+exit_program(1);
+}
}
@@ -339,6 +344,10 @@ static int opt_map(void *optctx, const char *opt, const char *arg)
if (check_stream_specifier(input_files[file_idx]->ctx,
input_files[file_idx]->ctx->streams[i],
*p == ':' ? p + 1 : p) <= 0)
continue;
+if (input_streams[input_files[file_idx]->ist_index +
i]->user_set_discard == AVDISCARD_ALL) {
+disabled = 1;
+continue;
+}
GROW_ARRAY(o->stream_maps, o->nb_stream_maps);
m = >stream_maps[o->nb_stream_maps - 1];
@@ -358,6 +367,10 @@ static int opt_map(void *optctx, const char *opt, const char *arg)
if (!m) {
if (allow_unused) {
av_log(NULL, AV_LOG_VERBOSE, "Stream map '%s' matches no streams;
ignoring.\n", arg);
+} else if (disabled) {
disabled is set to 1 and otherwise is uninitialized, this doesnt look intended
Revised.
From b6a32a981d8bd0d77b7607a2ca61989e5bbc79cc Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Sat, 29 Dec 2018 16:17:05 +0530
Subject: [PATCH v2 1/2] ffmpeg: skip disabled streams
Fully discarded streams can't be selected for output or mapped or filtered.
Previously, a few packets from such streams, probably buffered for
stream probing, would get smuggled into output files.
---
fftools/ffmpeg_filter.c | 7 +++
fftools/ffmpeg_opt.c| 31 +--
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 6518d50870..8c0ff99dd9 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -293,10 +293,17 @@ static void init_input_filter(FilterGraph *fg,
AVFilterInOut *in)
exit_program(1);
}
ist = input_streams[input_files[file_idx]->ist_index + st->index];
+if (ist->user_set_discard == AVDISCARD_ALL) {
+av_log(NULL, AV_LOG_FATAL, "Stream specifier '%s' in filtergraph
description %s "
+ "matches a disabled input stream.\n", p, fg->graph_desc);
+exit_program(1);
+}
} else {
/* find the first unused stream of corresponding type */
for (i = 0; i < nb_input_streams; i++) {
ist = input_streams[i];
+if (ist->user_set_discard == AVDISCARD_ALL)
+continue;
if (ist->dec_ctx->codec_type == type && ist->discard)
break;
}
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index d4851a2cd8..050a65c2c1 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -268,7 +268,7 @@ static int opt_map(void *optctx, const char *opt, const
char *arg)
{
OptionsContext *o = optctx;
StreamMap *m = NULL;
-int i, negative = 0, file_idx;
+int i, negative = 0, file_idx, disabled = 0;
int sync_file_idx = -1, sync_stream_idx = 0;
char *p, *sync;
char *map;
@@ -303,6 +303,11 @@ static int opt_map(void *optctx, const char *opt, const
char *arg)
"match any streams.\n", arg);
exit_program(1);
}
+if (input_streams[input_files[sync_file_idx]->ist_index +
sync_stream_idx]->user_set_discard == AVDISCARD_ALL) {
+av_log(NULL, AV_LOG_FATAL, "Sync stream specification in map %s
matches a disabled input "
+ "stream.\n", arg);
+exit_program(1);
+}
}
@@ -339,6 +344,10 @@ static int opt_map(void *optctx, const char *opt, const
char *arg)
if (check_stream_specifier(input_files[file_idx]->ctx,
input_files[file_idx]->ctx->streams[i],
Re: [FFmpeg-devel] [PATCH] avcodec/prores_ks reduce twice fdct calls
On Sun, Dec 30, 2018 at 10:57:23PM +0200, Alex Mogurenko wrote: > fdct done twice for each block. first time during quant calculation, second > during slice encoding. so if we pre-save dct coefficients no need to do fdct > second time. > disadvantages: requires more memory > advantages: improves performance ~4-5% > --- > libavcodec/proresenc_kostya.c | 74 --- > 1 file changed, 52 insertions(+), 22 deletions(-) breaks fate TESTvsynth1-prores_ks --- ./tests/ref/vsynth/vsynth1-prores_ks2018-12-28 17:54:41.361383177 +0100 +++ tests/data/fate/vsynth1-prores_ks 2018-12-31 03:45:17.207673799 +0100 @@ -1,4 +1,4 @@ -fe41a284da97ea5ec8866ca9a55b84da *tests/data/fate/vsynth1-prores_ks.mov -3858911 tests/data/fate/vsynth1-prores_ks.mov -100eb002413fe7a632d440dfbdf7e3ff *tests/data/fate/vsynth1-prores_ks.out.rawvideo -stddev:3.17 PSNR: 38.09 MAXDIFF: 39 bytes: 7603200/ 7603200 +ba6294d95b96f032b90f804f112ab98a *tests/data/fate/vsynth1-prores_ks.mov +3867422 tests/data/fate/vsynth1-prores_ks.mov +e85510eadb1ff115e85c480d8e1011a4 *tests/data/fate/vsynth1-prores_ks.out.rawvideo +stddev: 19.38 PSNR: 22.38 MAXDIFF: 210 bytes: 7603200/ 7603200 Test vsynth1-prores_ks failed. Look at tests/data/fate/vsynth1-prores_ks.err for details. make: *** [fate-vsynth1-prores_ks] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: ole32 is needed for shared libavcodec linking with dxva2.
On 12/30/2018 5:52 PM, Carl Eugen Hoyos wrote: > 2018-12-30 21:37 GMT+01:00, Hendrik Leppkes : >> On Sun, Dec 30, 2018 at 9:16 PM Carl Eugen Hoyos wrote: > >>> Attached patch fixes a Windows linking issue described in ticket #7642, >>> only shared linking was tested so far. >> >> ole32 is a dependency of dxva2 already, it should already be pulled in >> through that, shouldn't it? > > Please test this... > > Carl Eugen The issue here is that dxva2 is enabled (thus compiling dxva2.c), but every dxva2 module isn't, which means the dependency generator in configure will not pull dxva2 dependencies for avcodec. I think the more correct solution would be to add dxva2_extralibs to avcodec_extralibs. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] ffmpeg: skip disabled streams
On Sat, Dec 29, 2018 at 04:39:18PM +0530, Gyan wrote:
> At Michael's suggestion, earlier patch broken into two. This one stops
> discarded streams from being processed. A few more checks added.
>
> Gyan
>
[...]
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index d4851a2cd8..4ee7dbbe01 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -268,7 +268,7 @@ static int opt_map(void *optctx, const char *opt, const
> char *arg)
> {
> OptionsContext *o = optctx;
> StreamMap *m = NULL;
> -int i, negative = 0, file_idx;
> +int i, negative = 0, file_idx, disabled;
> int sync_file_idx = -1, sync_stream_idx = 0;
> char *p, *sync;
> char *map;
> @@ -303,6 +303,11 @@ static int opt_map(void *optctx, const char *opt, const
> char *arg)
> "match any streams.\n", arg);
> exit_program(1);
> }
> +if (input_streams[input_files[sync_file_idx]->ist_index +
> sync_stream_idx]->user_set_discard == AVDISCARD_ALL) {
> +av_log(NULL, AV_LOG_FATAL, "Sync stream specification in map %s
> matches a disabled input "
> + "stream.\n", arg);
> +exit_program(1);
> +}
> }
>
>
> @@ -339,6 +344,10 @@ static int opt_map(void *optctx, const char *opt, const
> char *arg)
> if (check_stream_specifier(input_files[file_idx]->ctx,
> input_files[file_idx]->ctx->streams[i],
> *p == ':' ? p + 1 : p) <= 0)
> continue;
> +if (input_streams[input_files[file_idx]->ist_index +
> i]->user_set_discard == AVDISCARD_ALL) {
> +disabled = 1;
> +continue;
> +}
> GROW_ARRAY(o->stream_maps, o->nb_stream_maps);
> m = >stream_maps[o->nb_stream_maps - 1];
>
> @@ -358,6 +367,10 @@ static int opt_map(void *optctx, const char *opt, const
> char *arg)
> if (!m) {
> if (allow_unused) {
> av_log(NULL, AV_LOG_VERBOSE, "Stream map '%s' matches no
> streams; ignoring.\n", arg);
> +} else if (disabled) {
disabled is set to 1 and otherwise is uninitialized, this doesnt look intended
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: ole32 is needed for shared libavcodec linking with dxva2.
2018-12-30 21:16 GMT+01:00, Carl Eugen Hoyos : > Attached patch fixes a Windows linking issue described in ticket #7642, > only shared linking was tested so far. Works fine with both static and dynamic linking. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec: Remove dynamic relocs from aarch64/h264idct_neon.S
2018-12-29 17:17 GMT+01:00, Manoj Gupta : > On Sat, Dec 29, 2018 at 2:32 AM Carl Eugen Hoyos wrote: >> >> 2018-12-29 0:12 GMT+01:00, Manoj Gupta : >> >> > I recently had a problem building ffmpeg for AArch64 where lld >> > linker complained about text relocations in readonly segment. >> > The following patch fixes the linker complains by referring to a >> > local label instead of function name. >> >> Do you know why this issue wasn't found when the previously >> fixed occurrences were seen? >> > This fixes the linking issues on AArch64. The previous fix I found > was for ARM32/Thumb whereas this file is AArch64 specific. Understood. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2 4/4] avformat/concatdec: always re-calculate start time and duration
This allows the underlying files to change their duration on subsequent
avformat context opens.
An example use case where this matters:
ffconcat version 1.0
file dummy.mxf
file dummy.mxf
ffmpeg -re -stream_loop -1 -i dummy.ffconcat -f sdl2 none
The user can seamlessly change the input by atomically replacing dummy.mxf.
v2: Set ConcatFile duration in read_header for all segments with known
durations because from now on we always recalculate the start time in
open_file, and an instant seek could have caused unset ConcatFile durations.
Signed-off-by: Marton Balint
---
libavformat/concatdec.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 890a220a89..d65da553e1 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -355,14 +355,12 @@ static int open_file(AVFormatContext *avf, unsigned
fileno)
return ret;
}
cat->cur_file = file;
-if (file->start_time == AV_NOPTS_VALUE)
-file->start_time = !fileno ? 0 :
- cat->files[fileno - 1].start_time +
- cat->files[fileno - 1].duration;
+file->start_time = !fileno ? 0 :
+ cat->files[fileno - 1].start_time +
+ cat->files[fileno - 1].duration;
file->file_start_time = (cat->avf->start_time == AV_NOPTS_VALUE) ? 0 :
cat->avf->start_time;
file->file_inpoint = (file->inpoint == AV_NOPTS_VALUE) ?
file->file_start_time : file->inpoint;
-if (file->duration == AV_NOPTS_VALUE)
-file->duration = get_best_effort_duration(file, cat->avf);
+file->duration = get_best_effort_duration(file, cat->avf);
if (cat->segment_time_metadata) {
av_dict_set_int(>metadata, "lavf.concatdec.start_time",
file->start_time, 0);
@@ -504,6 +502,7 @@ static int concat_read_header(AVFormatContext *avf)
break;
cat->files[i].user_duration = cat->files[i].outpoint -
cat->files[i].inpoint;
}
+cat->files[i].duration = cat->files[i].user_duration;
time += cat->files[i].user_duration;
}
if (i == cat->nb_files) {
@@ -529,8 +528,7 @@ static int open_next_file(AVFormatContext *avf)
ConcatContext *cat = avf->priv_data;
unsigned fileno = cat->cur_file - cat->files;
-if (cat->cur_file->duration == AV_NOPTS_VALUE)
-cat->cur_file->duration = get_best_effort_duration(cat->cur_file,
cat->avf);
+cat->cur_file->duration = get_best_effort_duration(cat->cur_file,
cat->avf);
if (++fileno >= cat->nb_files) {
cat->eof = 1;
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/prores_ks reduce twice fdct calls
fdct done twice for each block. first time during quant calculation, second
during slice encoding. so if we pre-save dct coefficients no need to do fdct
second time.
disadvantages: requires more memory
advantages: improves performance ~4-5%
---
libavcodec/proresenc_kostya.c | 74 ---
1 file changed, 52 insertions(+), 22 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index e045a972f1..4d49d6521a 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -219,7 +219,6 @@ struct TrellisNode {
#define MAX_STORED_Q 16
typedef struct ProresThreadData {
-DECLARE_ALIGNED(16, int16_t, blocks)[MAX_PLANES][64 * 4 *
MAX_MBS_PER_SLICE];
DECLARE_ALIGNED(16, uint16_t, emu_buf)[16 * 16];
int16_t custom_q[64];
int16_t custom_chroma_q[64];
@@ -228,7 +227,6 @@ typedef struct ProresThreadData {
typedef struct ProresContext {
AVClass *class;
-DECLARE_ALIGNED(16, int16_t, blocks)[MAX_PLANES][64 * 4 *
MAX_MBS_PER_SLICE];
DECLARE_ALIGNED(16, uint16_t, emu_buf)[16*16];
int16_t quants[MAX_STORED_Q][64];
int16_t quants_chroma[MAX_STORED_Q][64];
@@ -237,6 +235,7 @@ typedef struct ProresContext {
const uint8_t *quant_mat;
const uint8_t *quant_chroma_mat;
const uint8_t *scantable;
+int16_t *blocks[MAX_PLANES];
void (*fdct)(FDCTDSPContext *fdsp, const uint16_t *src,
ptrdiff_t linesize, int16_t *block);
@@ -562,6 +561,8 @@ static int encode_slice(AVCodecContext *avctx, const
AVFrame *pic,
int plane_factor, is_chroma;
uint16_t *qmat;
uint16_t *qmat_chroma;
+int16_t *blocks;
+DECLARE_ALIGNED(16, int16_t, dct_blocks)[16 * 16 * MAX_MBS_PER_SLICE];
if (ctx->pictures_per_frame == 1)
line_add = 0;
@@ -604,28 +605,38 @@ static int encode_slice(AVCodecContext *avctx, const
AVFrame *pic,
src = (const uint16_t*)(pic->data[i] + yp * linesize +
line_add * pic->linesize[i]) + xp;
+if (!ctx->force_quant) {
+blocks = ctx->blocks[i] + (y * ctx->slices_width + x /
ctx->mbs_per_slice) * 16 * 16 * ctx->mbs_per_slice;
+} else {
+blocks = dct_blocks;
+}
+
if (i < 3) {
-get_slice_data(ctx, src, linesize, xp, yp,
- pwidth, avctx->height / ctx->pictures_per_frame,
- ctx->blocks[0], ctx->emu_buf,
- mbs_per_slice, num_cblocks, is_chroma);
+if (ctx->force_quant) {
+get_slice_data(ctx, src, linesize, xp, yp,
+ pwidth, avctx->height / ctx->pictures_per_frame,
+ blocks, ctx->emu_buf,
+ mbs_per_slice, num_cblocks, is_chroma);
+}
if (!is_chroma) {/* luma quant */
sizes[i] = encode_slice_plane(ctx, pb, src, linesize,
- mbs_per_slice, ctx->blocks[0],
+ mbs_per_slice, blocks,
num_cblocks, plane_factor,
qmat);
} else { /* chroma plane */
sizes[i] = encode_slice_plane(ctx, pb, src, linesize,
- mbs_per_slice, ctx->blocks[0],
+ mbs_per_slice, blocks,
num_cblocks, plane_factor,
qmat_chroma);
}
} else {
-get_alpha_data(ctx, src, linesize, xp, yp,
- pwidth, avctx->height / ctx->pictures_per_frame,
- ctx->blocks[0], mbs_per_slice, ctx->alpha_bits);
+if (ctx->force_quant) {
+get_alpha_data(ctx, src, linesize, xp, yp,
+ pwidth, avctx->height / ctx->pictures_per_frame,
+ blocks, mbs_per_slice, ctx->alpha_bits);
+}
sizes[i] = encode_alpha_plane(ctx, pb, mbs_per_slice,
- ctx->blocks[0], quant);
+ blocks, quant);
}
total_size += sizes[i];
if (put_bits_left(pb) < 0) {
@@ -730,15 +741,15 @@ static int estimate_slice_plane(ProresContext *ctx, int
*error, int plane,
const uint16_t *src, ptrdiff_t linesize,
int mbs_per_slice,
int blocks_per_mb, int plane_size_factor,
-const int16_t *qmat, ProresThreadData *td)
+const int16_t *qmat, int16_t *blocks)
{
int blocks_per_slice;
int bits;
blocks_per_slice = mbs_per_slice * blocks_per_mb;
-bits
Re: [FFmpeg-devel] [PATCH]configure: ole32 is needed for shared libavcodec linking with dxva2.
2018-12-30 21:37 GMT+01:00, Hendrik Leppkes : > On Sun, Dec 30, 2018 at 9:16 PM Carl Eugen Hoyos wrote: >> Attached patch fixes a Windows linking issue described in ticket #7642, >> only shared linking was tested so far. > > ole32 is a dependency of dxva2 already, it should already be pulled in > through that, shouldn't it? Please test this... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: ole32 is needed for shared libavcodec linking with dxva2.
On Sun, Dec 30, 2018 at 9:16 PM Carl Eugen Hoyos wrote: > > Hi! > > Attached patch fixes a Windows linking issue described in ticket #7642, > only shared linking was tested so far. > ole32 is a dependency of dxva2 already, it should already be pulled in through that, shouldn't it? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 1/4] avformat/concatdec: always allow seeking to start
On Sun, 30 Dec 2018, Nicolas George wrote: Marton Balint (2018-12-23): Signed-off-by: Marton Balint --- libavformat/concatdec.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) Looks good to me, thanks. Applied, thanks. Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]configure: ole32 is needed for shared libavcodec linking with dxva2.
Hi! Attached patch fixes a Windows linking issue described in ticket #7642, only shared linking was tested so far. Please comment, Carl Eugen From f01b6c216b5fc970b374160efdc0f834d99d328d Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Sun, 30 Dec 2018 21:04:14 +0100 Subject: [PATCH] configure: ole32 is needed for shared libavcodec linking with dxva2. Fixes ticket #7642. Tested-by: Stephen Baker --- configure |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 04d3417..a636939 100755 --- a/configure +++ b/configure @@ -3527,7 +3527,7 @@ cws2fws_extralibs="zlib_extralibs" # libraries, in any order avcodec_deps="avutil" -avcodec_suggest="libm" +avcodec_suggest="libm ole32" avcodec_select="null_bsf" avdevice_deps="avformat avcodec avutil" avdevice_suggest="libm" @@ -3554,7 +3554,7 @@ ffmpeg_deps="avcodec avfilter avformat" ffmpeg_select="aformat_filter anull_filter atrim_filter format_filter null_filter trim_filter" -ffmpeg_suggest="ole32 psapi shell32" +ffmpeg_suggest="psapi shell32" ffplay_deps="avcodec avformat swscale swresample sdl2" ffplay_select="rdft crop_filter transpose_filter hflip_filter vflip_filter rotate_filter" ffplay_suggest="shell32" -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_asetnsamples: fix last frame props
On Sun, 30 Dec 2018, Nicolas George wrote: Marton Balint (2018-12-25): Frame properties were not copied, so e.g. PTS was not set for the last frame. Regression since ef3babb2c70f564dc1634b3f29c6e35a2b2dc239. Signed-off-by: Marton Balint --- libavfilter/af_asetnsamples.c | 6 ++ 1 file changed, 6 insertions(+) Sorry, it slipped my mind. LGTM, but I do not maintain that file. Thanks, applied with an additional fix to free pad_frame as well on error. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 1/2] lavfi/vaapi: Improve support for colour properties
Attempts to pick the set of supported colour properties best matching the
input. Output is then set with the same values, except for the colour
matrix which may change when converting between RGB and YUV.
---
On 30/12/2018 19:14, Michael Niedermayer wrote:> On Sun, Dec 30, 2018 at
06:45:17PM +, Mark Thompson wrote:
>> Attempts to pick the set of supported colour properties best matching the
>> input. Output is then set with the same values, except for the colour
>> matrix which may change when converting between RGB and YUV.
>> ---
>> libavfilter/vaapi_vpp.c| 265 -
>> libavfilter/vaapi_vpp.h| 5 +-
>> libavfilter/vf_deinterlace_vaapi.c | 16 +-
>> libavfilter/vf_misc_vaapi.c| 13 +-
>> libavfilter/vf_procamp_vaapi.c | 13 +-
>> libavfilter/vf_scale_vaapi.c | 12 +-
>> 6 files changed, 292 insertions(+), 32 deletions(-)
>
> breaks build:
>
> CClibavfilter/vaapi_vpp.o
> libavfilter/vaapi_vpp.c: In function ‘vaapi_vpp_fill_chroma_sample_location’:
> libavfilter/vaapi_vpp.c:348:37: error: ‘VA_CHROMA_SITING_UNKNOWN’ undeclared
> (first use in this function)
> { AVCHROMA_LOC_UNSPECIFIED, VA_CHROMA_SITING_UNKNOWN },
> ^
> libavfilter/vaapi_vpp.c:348:37: note: each undeclared identifier is reported
> only once for each function it appears in
> libavfilter/vaapi_vpp.c:349:30: error: ‘VA_CHROMA_SITING_VERTICAL_CENTER’
> undeclared (first use in this function)
> { AVCHROMA_LOC_LEFT,VA_CHROMA_SITING_VERTICAL_CENTER |
> ^
> libavfilter/vaapi_vpp.c:350:37: error: ‘VA_CHROMA_SITING_HORIZONTAL_LEFT’
> undeclared (first use in this function)
> VA_CHROMA_SITING_HORIZONTAL_LEFT },
> ^
> libavfilter/vaapi_vpp.c:352:37: error: ‘VA_CHROMA_SITING_HORIZONTAL_CENTER’
> undeclared (first use in this function)
> VA_CHROMA_SITING_HORIZONTAL_CENTER },
> ^
> libavfilter/vaapi_vpp.c:353:33: error: ‘VA_CHROMA_SITING_VERTICAL_TOP’
> undeclared (first use in this function)
> { AVCHROMA_LOC_TOPLEFT, VA_CHROMA_SITING_VERTICAL_TOP |
> ^
> libavfilter/vaapi_vpp.c:357:36: error: ‘VA_CHROMA_SITING_VERTICAL_BOTTOM’
> undeclared (first use in this function)
> { AVCHROMA_LOC_BOTTOMLEFT, VA_CHROMA_SITING_VERTICAL_BOTTOM |
> ^
> libavfilter/vaapi_vpp.c:370:38: warning: assignment makes integer from
> pointer without a cast [enabled by default]
> props->va_chroma_sample_location = VA_CHROMA_SITING_UNKNOWN;
> ^
> libavfilter/vaapi_vpp.c: In function ‘vaapi_vpp_fill_colour_range’:
> libavfilter/vaapi_vpp.c:377:33: error: ‘VA_SOURCE_RANGE_REDUCED’ undeclared
> (first use in this function)
> props->va_color_range = VA_SOURCE_RANGE_REDUCED;
> ^
> libavfilter/vaapi_vpp.c:377:31: warning: assignment makes integer from
> pointer without a cast [enabled by default]
> props->va_color_range = VA_SOURCE_RANGE_REDUCED;
>^
> libavfilter/vaapi_vpp.c:380:33: error: ‘VA_SOURCE_RANGE_FULL’ undeclared
> (first use in this function)
> props->va_color_range = VA_SOURCE_RANGE_FULL;
> ^
> libavfilter/vaapi_vpp.c:380:31: warning: assignment makes integer from
> pointer without a cast [enabled by default]
> props->va_color_range = VA_SOURCE_RANGE_FULL;
>^
> libavfilter/vaapi_vpp.c:384:33: error: ‘VA_SOURCE_RANGE_UNKNOWN’ undeclared
> (first use in this function)
> props->va_color_range = VA_SOURCE_RANGE_UNKNOWN;
> ^
> libavfilter/vaapi_vpp.c:384:31: warning: assignment makes integer from
> pointer without a cast [enabled by default]
> props->va_color_range = VA_SOURCE_RANGE_UNKNOWN;
>^
> make: *** [libavfilter/vaapi_vpp.o] Error 1
> make: Target `all' not remade because of errors.
Added version guards for these fields as well.
Thanks,
- Mark
libavfilter/vaapi_vpp.c| 273 -
libavfilter/vaapi_vpp.h| 5 +-
libavfilter/vf_deinterlace_vaapi.c | 16 +-
libavfilter/vf_misc_vaapi.c| 13 +-
libavfilter/vf_procamp_vaapi.c | 13 +-
libavfilter/vf_scale_vaapi.c | 12 +-
6 files changed, 300 insertions(+), 32 deletions(-)
diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
index c5bbc3b85b..f4ee622a2b 100644
--- a/libavfilter/vaapi_vpp.c
+++ b/libavfilter/vaapi_vpp.c
@@ -234,18 +234,273 @@ fail:
return err;
}
-int ff_vaapi_vpp_colour_standard(enum AVColorSpace av_cs)
+typedef struct VAAPIColourProperties {
+VAProcColorStandardType va_color_standard;
+
+enum
Re: [FFmpeg-devel] [PATCH V3] avfilter: Add tonemap vaapi filter
On 29/12/2018 07:02, Zachary Zhou wrote: > It supports ICL platform. When will this hardware be available? Is this a new fixed-function feature, or will it be available on current hardware as well? > H2H (HDR to HDR): P010 -> RGB10 > H2S (HDR to SDR): P010 -> RGB8 > > libva commit for HDR10 > https://github.com/intel/libva/commit/cf11abe5e1b9c93ee75cf974076957162c1605b9 > > Signed-off-by: Zachary Zhou > --- > configure | 2 + > doc/filters.texi | 63 > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vaapi_vpp.c| 29 ++ > libavfilter/vaapi_vpp.h| 8 + > libavfilter/vf_tonemap_vaapi.c | 542 + > libavutil/hwcontext_vaapi.c| 3 + > 8 files changed, 649 insertions(+) > create mode 100644 libavfilter/vf_tonemap_vaapi.c > > diff --git a/configure b/configure > index be49c19b88..baf70d03fc 100755 > --- a/configure > +++ b/configure > @@ -3480,6 +3480,7 @@ tinterlace_merge_test_deps="tinterlace_filter" > tinterlace_pad_test_deps="tinterlace_filter" > tonemap_filter_deps="const_nan" > tonemap_opencl_filter_deps="opencl const_nan" > +tonemap_vaapi_filter_deps="vaapi VAProcFilterParameterBufferHDRToneMapping" > transpose_opencl_filter_deps="opencl" > unsharp_opencl_filter_deps="opencl" > uspp_filter_deps="gpl avcodec" > @@ -5984,6 +5985,7 @@ check_type "d3d9.h dxva2api.h" > DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602 > > check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC" > check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth > +check_type "va/va.h va/va_vpp.h" "VAProcFilterParameterBufferHDRToneMapping" > check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC" > check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG" > check_type "va/va.h va/va_enc_vp8.h" "VAEncPictureParameterBufferVP8" > diff --git a/doc/filters.texi b/doc/filters.texi > index ac4c9b44d8..9ed53a1008 100644 > --- a/doc/filters.texi > +++ b/doc/filters.texi > @@ -19130,6 +19130,69 @@ Convert HDR(PQ/HLG) video to > bt2020-transfer-characteristic p010 format using li > @end example > @end itemize > > +@section tonemap_vappi > + > +Perform HDR(High Dynamic Range) to HDR and HDR to SDR conversion with > tone-mapping. > + > +It accepts the following parameters: > + > +@table @option > +@item type > +Specify the tone-mapping operator to be used. > + > +Possible values are: > +@table @var > +@item h2h > +Perform H2H(HDR to HDR), convert from p010 to rgb10 > +@item h2s > +Perform H2S(HDR to SDR), convert from p010 to rgb8 > +@end table What are RGB10 and RGB8? > + > +@item display > +Set mastering display metadata for H2H > + > +Can assume the following values: > +@table @var > +@item G > +Green primary G(x|y) > +@item B > +Blue primary B(x|y) > +@item R > +Red primary R(x|y) > +@item WP > +White point WP(x|y) > +@item L > +Display mastering luminance L(max|min) > +@end table > + > +@item light > +Set content light level for H2H > + > +Can assume the following values: > +@table @var > +@item CLL > +Max content light level > +@item FALL > +Max average light level per frame > +@end table What units are all of these values in? > + > +@end table > + > +@subsection Example > + > +@itemize > +@item > +Convert HDR video to HDR video from p010 format to rgb10 format. > +@example > +-i INPUT -vf > "tonemap_vaapi=h2h:display=G(13250|34500)B(7500|3000)R(34000|16000)WP(15635|16450)L(2000|2000):light=CLL(1)FALL(1000)" > OUTPUT > +@end example > +@item > +Convert HDR video to SDR video from p010 format to rgb8 format. > +@example > +-i INPUT -vf "tonemap_vaapi=h2s" OUTPUT > +@end example > +@end itemize > + > @section unsharp_opencl > > Sharpen or blur the input video. > diff --git a/libavfilter/Makefile b/libavfilter/Makefile > index 6e2658186d..f6894209d1 100644 > --- a/libavfilter/Makefile > +++ b/libavfilter/Makefile > @@ -390,6 +390,7 @@ OBJS-$(CONFIG_TMIX_FILTER) += vf_mix.o > framesync.o > OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o colorspace.o > OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER) += vf_tonemap_opencl.o > colorspace.o opencl.o \ > opencl/tonemap.o > opencl/colorspace_common.o > +OBJS-$(CONFIG_TONEMAP_VAAPI_FILTER) += vf_tonemap_vaapi.o > vaapi_vpp.o > OBJS-$(CONFIG_TPAD_FILTER) += vf_tpad.o > OBJS-$(CONFIG_TRANSPOSE_FILTER) += vf_transpose.o > OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER) += vf_transpose_npp.o > cuda_check.o > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c > index a600069500..754b84819d 100644 > --- a/libavfilter/allfilters.c > +++ b/libavfilter/allfilters.c > @@ -369,6 +369,7 @@ extern AVFilter ff_vf_tlut2; > extern AVFilter ff_vf_tmix; > extern AVFilter ff_vf_tonemap; > extern AVFilter ff_vf_tonemap_opencl; > +extern AVFilter
Re: [FFmpeg-devel] [PATCH 1/2] lavfi/vaapi: Improve support for colour properties
On Sun, Dec 30, 2018 at 06:45:17PM +, Mark Thompson wrote:
> Attempts to pick the set of supported colour properties best matching the
> input. Output is then set with the same values, except for the colour
> matrix which may change when converting between RGB and YUV.
> ---
> libavfilter/vaapi_vpp.c| 265 -
> libavfilter/vaapi_vpp.h| 5 +-
> libavfilter/vf_deinterlace_vaapi.c | 16 +-
> libavfilter/vf_misc_vaapi.c| 13 +-
> libavfilter/vf_procamp_vaapi.c | 13 +-
> libavfilter/vf_scale_vaapi.c | 12 +-
> 6 files changed, 292 insertions(+), 32 deletions(-)
breaks build:
CC libavfilter/vaapi_vpp.o
libavfilter/vaapi_vpp.c: In function ‘vaapi_vpp_fill_chroma_sample_location’:
libavfilter/vaapi_vpp.c:348:37: error: ‘VA_CHROMA_SITING_UNKNOWN’ undeclared
(first use in this function)
{ AVCHROMA_LOC_UNSPECIFIED, VA_CHROMA_SITING_UNKNOWN },
^
libavfilter/vaapi_vpp.c:348:37: note: each undeclared identifier is reported
only once for each function it appears in
libavfilter/vaapi_vpp.c:349:30: error: ‘VA_CHROMA_SITING_VERTICAL_CENTER’
undeclared (first use in this function)
{ AVCHROMA_LOC_LEFT,VA_CHROMA_SITING_VERTICAL_CENTER |
^
libavfilter/vaapi_vpp.c:350:37: error: ‘VA_CHROMA_SITING_HORIZONTAL_LEFT’
undeclared (first use in this function)
VA_CHROMA_SITING_HORIZONTAL_LEFT },
^
libavfilter/vaapi_vpp.c:352:37: error: ‘VA_CHROMA_SITING_HORIZONTAL_CENTER’
undeclared (first use in this function)
VA_CHROMA_SITING_HORIZONTAL_CENTER },
^
libavfilter/vaapi_vpp.c:353:33: error: ‘VA_CHROMA_SITING_VERTICAL_TOP’
undeclared (first use in this function)
{ AVCHROMA_LOC_TOPLEFT, VA_CHROMA_SITING_VERTICAL_TOP |
^
libavfilter/vaapi_vpp.c:357:36: error: ‘VA_CHROMA_SITING_VERTICAL_BOTTOM’
undeclared (first use in this function)
{ AVCHROMA_LOC_BOTTOMLEFT, VA_CHROMA_SITING_VERTICAL_BOTTOM |
^
libavfilter/vaapi_vpp.c:370:38: warning: assignment makes integer from pointer
without a cast [enabled by default]
props->va_chroma_sample_location = VA_CHROMA_SITING_UNKNOWN;
^
libavfilter/vaapi_vpp.c: In function ‘vaapi_vpp_fill_colour_range’:
libavfilter/vaapi_vpp.c:377:33: error: ‘VA_SOURCE_RANGE_REDUCED’ undeclared
(first use in this function)
props->va_color_range = VA_SOURCE_RANGE_REDUCED;
^
libavfilter/vaapi_vpp.c:377:31: warning: assignment makes integer from pointer
without a cast [enabled by default]
props->va_color_range = VA_SOURCE_RANGE_REDUCED;
^
libavfilter/vaapi_vpp.c:380:33: error: ‘VA_SOURCE_RANGE_FULL’ undeclared (first
use in this function)
props->va_color_range = VA_SOURCE_RANGE_FULL;
^
libavfilter/vaapi_vpp.c:380:31: warning: assignment makes integer from pointer
without a cast [enabled by default]
props->va_color_range = VA_SOURCE_RANGE_FULL;
^
libavfilter/vaapi_vpp.c:384:33: error: ‘VA_SOURCE_RANGE_UNKNOWN’ undeclared
(first use in this function)
props->va_color_range = VA_SOURCE_RANGE_UNKNOWN;
^
libavfilter/vaapi_vpp.c:384:31: warning: assignment makes integer from pointer
without a cast [enabled by default]
props->va_color_range = VA_SOURCE_RANGE_UNKNOWN;
^
make: *** [libavfilter/vaapi_vpp.o] Error 1
make: Target `all' not remade because of errors.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
On 12/30/18, Nicolas George wrote: > Paul B Mahol (2018-12-30): >> I will use +. > > That was my suggestion in the beginning, so I am obviously for. But what > happened to your reasons for rejecting it? I thought that adapted patch by me had this issue already resolved. I did not carefully read full patch. Anyway I would spot this issue for sure at later point. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_asetnsamples: fix last frame props
Marton Balint (2018-12-25): > Frame properties were not copied, so e.g. PTS was not set for the last frame. > > Regression since ef3babb2c70f564dc1634b3f29c6e35a2b2dc239. > > Signed-off-by: Marton Balint > --- > libavfilter/af_asetnsamples.c | 6 ++ > 1 file changed, 6 insertions(+) Sorry, it slipped my mind. LGTM, but I do not maintain that file. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_asetnsamples: fix last frame props
On Tue, 25 Dec 2018, Marton Balint wrote:
Frame properties were not copied, so e.g. PTS was not set for the last frame.
Regression since ef3babb2c70f564dc1634b3f29c6e35a2b2dc239.
Signed-off-by: Marton Balint
---
libavfilter/af_asetnsamples.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/af_asetnsamples.c b/libavfilter/af_asetnsamples.c
index e8daec8d8f..ea20d66ac5 100644
--- a/libavfilter/af_asetnsamples.c
+++ b/libavfilter/af_asetnsamples.c
@@ -76,6 +76,12 @@ static int activate(AVFilterContext *ctx)
return AVERROR(ENOMEM);
}
+ret = av_frame_copy_props(pad_frame, frame);
+if (ret < 0) {
+av_frame_free();
+return ret;
+}
+
av_samples_copy(pad_frame->extended_data, frame->extended_data,
0, 0, frame->nb_samples, frame->channels,
frame->format);
av_samples_set_silence(pad_frame->extended_data, frame->nb_samples,
Ping, will apply soon.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avutil/imgutils: Optimize writing 4 bytes in memset_bytes()
On Sun, Dec 30, 2018 at 07:15:49PM +0100, Marton Balint wrote:
>
>
> On Fri, 28 Dec 2018, Michael Niedermayer wrote:
>
> >On Wed, Dec 26, 2018 at 10:16:47PM +0100, Marton Balint wrote:
> >>
> >>
> >>On Wed, 26 Dec 2018, Paul B Mahol wrote:
> >>
> >>>On 12/26/18, Michael Niedermayer wrote:
> On Wed, Dec 26, 2018 at 04:32:17PM +0100, Paul B Mahol wrote:
> >On 12/25/18, Michael Niedermayer wrote:
> >>Fixes: Timeout
> >>Fixes:
> >>11502/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
> >>Before: Executed
> >>clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
> >>in 11294 ms
> >>After : Executed
> >>clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
> >>in 4249 ms
> >>
> >>Found-by: continuous fuzzing process
> >>https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>Signed-off-by: Michael Niedermayer
> >>---
> >> libavutil/imgutils.c | 6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >>diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
> >>index 4938a7ef67..cc38f1e878 100644
> >>--- a/libavutil/imgutils.c
> >>+++ b/libavutil/imgutils.c
> >>@@ -529,6 +529,12 @@ static void memset_bytes(uint8_t *dst, size_t
> >>dst_size,
> >>uint8_t *clear,
> >> }
> >> } else if (clear_size == 4) {
> >> uint32_t val = AV_RN32(clear);
> >>+uint64_t val8 = val * 0x10001ULL;
> >>+for (; dst_size >= 32; dst_size -= 32) {
> >>+AV_WN64(dst , val8); AV_WN64(dst+ 8, val8);
> >>+AV_WN64(dst+16, val8); AV_WN64(dst+24, val8);
> >>+dst += 32;
> >>+}
> >> for (; dst_size >= 4; dst_size -= 4) {
> >> AV_WN32(dst, val);
> >> dst += 4;
> >>--
> >>2.20.1
> >>
> >
> >NAK, implement special memset function instead.
>
> I can move the added loop into a seperate function, if thats what you
> suggest ?
> >>>
> >>>No, don't do that.
> >>>
> All the code is already in a "special" memset though, this is
> memset_bytes()
>
> >>>
> >>>I guess function is less useful if its static. So any duplicate should
> >>>be avoided in codebase.
> >>
> >>Isn't av_memcpy_backptr does almost exactly what is needed here? That can
> >>also be optimized further if needed.
> >
> >av_memcpy_backptr() copies data with overlap, its more like a recursive
> >memmove().
>
> So? As far as I see the memset_bytes function in imgutils.c can be replaced
> with this:
>
> if (clear_size > dst_size)
> clear_size = dst_size;
> memcpy(dst, clear, clear_size);
> av_memcpy_backptr(dst + clear_size, clear_size, dst_size - clear_size);
>
> I am not against an av_memset_bytes API addition, but I believe it should
> share code with av_memcpy_backptr to avoid duplication.
Iam a bit concerned that combining them could result in lower speed
but i can surely combine them if people prefer?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
Paul B Mahol (2018-12-30): > I will use +. That was my suggestion in the beginning, so I am obviously for. But what happened to your reasons for rejecting it? (Once again, too little information in your mail => wasted time for both of us.) -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
On 12/30/18, Nicolas George wrote: > Paul B Mahol (2018-12-30): >> http://ffmpeg.org/ffmpeg-filters.html#aformat-1http://ffmpeg.org/ffmpeg-filters.html#aformat-1 > > Your link was slightly broken. > >> Do you want to change above thing too? > > No, but I would have objected if I had noticed at the time. > > But thanks for finding that example: that shows that | cannot be used in > channel layout descriptions, since aformat splits on |. You have to use > another character, there is no choice about it. I will use +. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
Paul B Mahol (2018-12-30): > http://ffmpeg.org/ffmpeg-filters.html#aformat-1http://ffmpeg.org/ffmpeg-filters.html#aformat-1 Your link was slightly broken. > Do you want to change above thing too? No, but I would have objected if I had noticed at the time. But thanks for finding that example: that shows that | cannot be used in channel layout descriptions, since aformat splits on |. You have to use another character, there is no choice about it. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] delogo filter: new "uglarm" interpolation mode added
2018-12-30 14:02 GMT+01:00, Nicolas George : > Uwe Freese (2018-12-29): >> +(double*)av_malloc((logo_w - 1) * (logo_h - 1) * >> sizeof(double)); > > No casting of malloc returns in C, this is a c++ thing. Also, use > av_malloc_array(). While there, please don't use sizeof(type) but sizeof(variable), same below. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] vf_scale_vaapi: Add options to configure output colour properties
The "out_color_matrix" and "out_range" properties match the same options
in vf_scale; the others attempt to follow the same pattern.
---
libavfilter/vf_scale_vaapi.c | 70
1 file changed, 70 insertions(+)
diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index b56217c56d..24d72ed82a 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -39,6 +39,17 @@ typedef struct ScaleVAAPIContext {
char *w_expr; // width expression string
char *h_expr; // height expression string
+
+char *colour_primaries_string;
+char *colour_transfer_string;
+char *colour_matrix_string;
+int colour_range;
+char *chroma_location_string;
+
+enum AVColorPrimaries colour_primaries;
+enum AVColorTransferCharacteristic colour_transfer;
+enum AVColorSpace colour_matrix;
+enum AVChromaLocation chroma_location;
} ScaleVAAPIContext;
static const char *scale_vaapi_mode_name(int mode)
@@ -116,6 +127,17 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
AVFrame *input_frame)
if (err < 0)
goto fail;
+if (ctx->colour_primaries != AVCOL_PRI_UNSPECIFIED)
+output_frame->color_primaries = ctx->colour_primaries;
+if (ctx->colour_transfer != AVCOL_TRC_UNSPECIFIED)
+output_frame->color_trc = ctx->colour_transfer;
+if (ctx->colour_matrix != AVCOL_SPC_UNSPECIFIED)
+output_frame->colorspace = ctx->colour_matrix;
+if (ctx->colour_range != AVCOL_RANGE_UNSPECIFIED)
+output_frame->color_range = ctx->colour_range;
+if (ctx->chroma_location != AVCHROMA_LOC_UNSPECIFIED)
+output_frame->chroma_location = ctx->chroma_location;
+
output_surface = (VASurfaceID)(uintptr_t)output_frame->data[3];
av_log(avctx, AV_LOG_DEBUG, "Using surface %#x for scale output.\n",
output_surface);
@@ -183,6 +205,24 @@ static av_cold int scale_vaapi_init(AVFilterContext *avctx)
vpp_ctx->output_format = AV_PIX_FMT_NONE;
}
+#define STRING_OPTION(var_name, func_name, default_value) do { \
+if (ctx->var_name ## _string) { \
+int var = av_ ## func_name ## _from_name(ctx->var_name ##
_string); \
+if (var < 0) { \
+av_log(avctx, AV_LOG_ERROR, "Invalid %s.\n", #var_name); \
+return AVERROR(EINVAL); \
+} \
+ctx->var_name = var; \
+} else { \
+ctx->var_name = default_value; \
+} \
+} while (0)
+
+STRING_OPTION(colour_primaries, color_primaries, AVCOL_PRI_UNSPECIFIED);
+STRING_OPTION(colour_transfer, color_transfer, AVCOL_TRC_UNSPECIFIED);
+STRING_OPTION(colour_matrix,color_space, AVCOL_SPC_UNSPECIFIED);
+STRING_OPTION(chroma_location, chroma_location, AVCHROMA_LOC_UNSPECIFIED);
+
return 0;
}
@@ -206,6 +246,36 @@ static const AVOption scale_vaapi_options[] = {
0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_HQ }, 0, 0, FLAGS,
"mode" },
{ "nl_anamorphic", "Use nolinear anamorphic scaling algorithm",
0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_NL_ANAMORPHIC }, 0,
0, FLAGS, "mode" },
+
+// These colour properties match the ones of the same name in vf_scale.
+{ "out_color_matrix", "Output colour matrix coefficient set",
+ OFFSET(colour_matrix_string), AV_OPT_TYPE_STRING, { .str = NULL },
.flags = FLAGS },
+{ "out_range", "Output colour range",
+ OFFSET(colour_range), AV_OPT_TYPE_INT, { .i64 = AVCOL_RANGE_UNSPECIFIED
},
+ AVCOL_RANGE_UNSPECIFIED, AVCOL_RANGE_JPEG, FLAGS, "range" },
+{ "full","Full range",
+ 0, AV_OPT_TYPE_CONST, { .i64 = AVCOL_RANGE_JPEG }, 0, 0, FLAGS, "range"
},
+{ "limited", "Limited range",
+ 0, AV_OPT_TYPE_CONST, { .i64 = AVCOL_RANGE_MPEG }, 0, 0, FLAGS, "range"
},
+{ "jpeg","Full range",
+ 0, AV_OPT_TYPE_CONST, { .i64 = AVCOL_RANGE_JPEG }, 0, 0, FLAGS, "range"
},
+{ "mpeg","Limited range",
+ 0, AV_OPT_TYPE_CONST, { .i64 = AVCOL_RANGE_MPEG }, 0, 0, FLAGS, "range"
},
+{ "tv", "Limited range",
+ 0, AV_OPT_TYPE_CONST, { .i64 = AVCOL_RANGE_MPEG }, 0, 0, FLAGS, "range"
},
+{ "pc", "Full range",
+ 0, AV_OPT_TYPE_CONST, { .i64 = AVCOL_RANGE_JPEG }, 0, 0, FLAGS, "range"
},
+// These colour properties are new here.
+{ "out_color_primaries", "Output colour primaries",
+ OFFSET(colour_primaries_string), AV_OPT_TYPE_STRING,
+ { .str = NULL }, .flags = FLAGS },
+{ "out_color_transfer", "Output colour transfer characteristics",
+ OFFSET(colour_transfer_string), AV_OPT_TYPE_STRING,
+ { .str = NULL }, .flags = FLAGS },
+{ "out_chroma_location", "Output chroma sample location",
+ OFFSET(chroma_location_string), AV_OPT_TYPE_STRING,
+ { .str = NULL }, .flags = FLAGS },
+
{ NULL },
};
--
2.19.2
___
ffmpeg-devel mailing list
[FFmpeg-devel] [PATCH 1/2] lavfi/vaapi: Improve support for colour properties
Attempts to pick the set of supported colour properties best matching the
input. Output is then set with the same values, except for the colour
matrix which may change when converting between RGB and YUV.
---
libavfilter/vaapi_vpp.c| 265 -
libavfilter/vaapi_vpp.h| 5 +-
libavfilter/vf_deinterlace_vaapi.c | 16 +-
libavfilter/vf_misc_vaapi.c| 13 +-
libavfilter/vf_procamp_vaapi.c | 13 +-
libavfilter/vf_scale_vaapi.c | 12 +-
6 files changed, 292 insertions(+), 32 deletions(-)
diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
index c5bbc3b85b..ee1075fd90 100644
--- a/libavfilter/vaapi_vpp.c
+++ b/libavfilter/vaapi_vpp.c
@@ -234,20 +234,267 @@ fail:
return err;
}
-int ff_vaapi_vpp_colour_standard(enum AVColorSpace av_cs)
+typedef struct VAAPIColourProperties {
+VAProcColorStandardType va_color_standard;
+
+enum AVColorPrimaries color_primaries;
+enum AVColorTransferCharacteristic color_trc;
+enum AVColorSpace colorspace;
+
+uint8_t va_chroma_sample_location;
+uint8_t va_color_range;
+
+enum AVColorRange color_range;
+enum AVChromaLocation chroma_sample_location;
+} VAAPIColourProperties;
+
+static const VAAPIColourProperties*
+vaapi_vpp_find_colour_props(VAProcColorStandardType vacs)
+{
+static const VAAPIColourProperties cs_map[] = {
+{ VAProcColorStandardBT601, 5, 6, 5 },
+{ VAProcColorStandardBT601, 6, 6, 6 },
+{ VAProcColorStandardBT709, 1, 1, 1 },
+{ VAProcColorStandardBT470M, 4, 4, 4 },
+{ VAProcColorStandardBT470BG, 5, 5, 5 },
+{ VAProcColorStandardSMPTE170M, 6, 6, 6 },
+{ VAProcColorStandardSMPTE240M, 7, 7, 7 },
+{ VAProcColorStandardGenericFilm, 8, 1, 1 },
+#if VA_CHECK_VERSION(1, 1, 0)
+{ VAProcColorStandardSRGB,1, 13, 0 },
+{ VAProcColorStandardXVYCC601,1, 11, 5 },
+{ VAProcColorStandardXVYCC709,1, 11, 1 },
+{ VAProcColorStandardBT2020, 9, 14, 9 },
+#endif
+};
+int i;
+for (i = 0; i < FF_ARRAY_ELEMS(cs_map); i++) {
+if (vacs == cs_map[i].va_color_standard)
+return _map[i];
+}
+return NULL;
+}
+
+static void vaapi_vpp_fill_colour_standard(VAAPIColourProperties *props,
+ VAProcColorStandardType *vacs,
+ int nb_vacs)
+{
+const VAAPIColourProperties *t;
+int i, k, score, best_score, worst_score;
+
+// If the driver supports explicit use of the standard values then just
+// use them and avoid doing any mapping. (The driver may not support
+// some particular code point, but it still has enough information to
+// make a better fallback choice than we do in that case.)
+#if VA_CHECK_VERSION(1, 1, 0)
+for (i = 0; i < nb_vacs; i++) {
+if (vacs[i] == VAProcColorStandardExplicit) {
+props->va_color_standard = VAProcColorStandardExplicit;
+return;
+}
+}
+#endif
+
+// Give scores to the possible options and choose the lowest one.
+// An exact match will score zero and therefore always be chosen, as
+// will a partial match where all unmatched elements are explicitly
+// unspecified. (If all elements are unspecified this will use the
+// first available value.) If no options match at all then just
+// pass "none" to the driver and let it make its own choice.
+best_score = -1;
+worst_score = 4 * (props->colorspace != AVCOL_SPC_UNSPECIFIED) +
+ 2 * (props->color_trc != AVCOL_TRC_UNSPECIFIED) +
+ (props->color_primaries != AVCOL_PRI_UNSPECIFIED);
+for (k = 0; k < 2; k++) {
+for (i = 0; i < nb_vacs; i++) {
+t = vaapi_vpp_find_colour_props(vacs[i]);
+if (!t)
+continue;
+
+score = 0;
+if (props->colorspace != AVCOL_SPC_UNSPECIFIED &&
+props->colorspace != AVCOL_SPC_RGB)
+score += 4 * (props->colorspace != t->colorspace);
+if (props->color_trc != AVCOL_TRC_UNSPECIFIED)
+score += 2 * (props->color_trc != t->color_trc);
+if (props->color_primaries != AVCOL_PRI_UNSPECIFIED)
+score += (props->color_primaries != t->color_primaries);
+
+if (k == 0) {
+// Only include things which matched something.
+if ((worst_score == 0 || score < worst_score) &&
+(best_score == -1 || score < best_score))
+best_score = score;
+} else {
+if (score == best_score) {
+props->va_color_standard = t->va_color_standard;
+return;
+}
+}
+}
+
+if (best_score == -1)
+break;
+}
+props->va_color_standard =
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
On 12/30/18, Nicolas George wrote: > Paul B Mahol (2018-12-30): >> aformat for example use | to split channel layouts. > > Where? http://ffmpeg.org/ffmpeg-filters.html#aformat-1http://ffmpeg.org/ffmpeg-filters.html#aformat-1 Do you want to change above thing too? What you propose instead? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
Paul B Mahol (2018-12-30): > aformat for example use | to split channel layouts. Where? > Documentation follows old legacy usage. I am talking about the documentation of the patch you are proposing. > Can you please stop bikeshedding and arguing with me just because > you enjoy it? Can you refrain from making baseless accusations? I am concerned about the quality of a new API. Mistakes done now will bother us for a long time; it is therefore a good idea to take the time to think things through. Please assume that everybody has at least as much goodwill as yourself. If you want the discussion to go faster, I would suggest you change your habit of giving half a bit of information per mail: explain your point in details, with examples, and you will need to do it only once. If you keep this style of posting, each question will take a dozen mails: you are wasting your own time like that as well as the time of everybody else. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
On 12/30/18, Nicolas George wrote: > Paul B Mahol (2018-12-30): >> Please no, | is used in bunch of scripts. > > What scripts? How can they use an API that is still in early discussion? aformat for example use | to split channel layouts. > > Also, discussing this is moot until you rephrase the documentation. Documentation follows old legacy usage. Can you please stop bikeshedding and arguing with me just because you enjoy it? I'm kindly asking you, whichever agenda you follow, please stop. I'm doing this to add support for ambisonics and you just stopped it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
Paul B Mahol (2018-12-30): > Please no, | is used in bunch of scripts. What scripts? How can they use an API that is still in early discussion? Also, discussing this is moot until you rephrase the documentation. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
On 12/30/18, Nicolas George wrote: > Paul B Mahol (2018-12-30): >> >> Input #0, wv, from >> >> '/home/computer/Downloads/Run_The_Race_-_3rd_Order_Ambisonic_SN3D.wv': >> >> Duration: 00:11:07.67, start: 0.00, bitrate: 6084 kb/s >> >> Stream #0:0: Audio: wavpack, 44100 Hz, 16 channels >> >> (FL+FR+FC+LFE+BL+BR+FLC+FRC+BC+SL+SR+TC+TFL+TFC+TFR+TBL), s16p >> > >> > Yes... and...? >> >> From this is obvious that user can not use '+' to separate channel >> layouts if it is already used to define channel layouts. >> >> Do you need better explanation now? > > Well, quoting the original patch: > > + * The input string can be represented by: > + * - the formal channel layout name (returned by > av_channel_layout_describe()) > + * - single or multiple channel names (returned by av_channel_name() > + *or concatenated with "|") > + * - a hexadecimal value of a channel layout (eg. "0x4") > + * - the number of channels with default layout (eg. "5") > + * - the number of unordered channels (eg. "4 channels") > > There is no mention about '+'. So I guess this paragraph needs to be > rewritten to actually match what is being done. > > And if + is not possible, | is still a bad choice. Use a character that > is not special for standard shells, I am sure we can find some; maybe /. > Please no, | is used in bunch of scripts. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
Paul B Mahol (2018-12-30): > >> Input #0, wv, from > >> '/home/computer/Downloads/Run_The_Race_-_3rd_Order_Ambisonic_SN3D.wv': > >> Duration: 00:11:07.67, start: 0.00, bitrate: 6084 kb/s > >> Stream #0:0: Audio: wavpack, 44100 Hz, 16 channels > >> (FL+FR+FC+LFE+BL+BR+FLC+FRC+BC+SL+SR+TC+TFL+TFC+TFR+TBL), s16p > > > > Yes... and...? > > From this is obvious that user can not use '+' to separate channel > layouts if it is already used to define channel layouts. > > Do you need better explanation now? Well, quoting the original patch: + * The input string can be represented by: + * - the formal channel layout name (returned by av_channel_layout_describe()) + * - single or multiple channel names (returned by av_channel_name() + *or concatenated with "|") + * - a hexadecimal value of a channel layout (eg. "0x4") + * - the number of channels with default layout (eg. "5") + * - the number of unordered channels (eg. "4 channels") There is no mention about '+'. So I guess this paragraph needs to be rewritten to actually match what is being done. And if + is not possible, | is still a bad choice. Use a character that is not special for standard shells, I am sure we can find some; maybe /. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avutil/imgutils: Optimize writing 4 bytes in memset_bytes()
On Fri, 28 Dec 2018, Michael Niedermayer wrote:
On Wed, Dec 26, 2018 at 10:16:47PM +0100, Marton Balint wrote:
On Wed, 26 Dec 2018, Paul B Mahol wrote:
On 12/26/18, Michael Niedermayer wrote:
On Wed, Dec 26, 2018 at 04:32:17PM +0100, Paul B Mahol wrote:
On 12/25/18, Michael Niedermayer wrote:
Fixes: Timeout
Fixes:
11502/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
Before: Executed
clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
in 11294 ms
After : Executed
clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664893810769920
in 4249 ms
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavutil/imgutils.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index 4938a7ef67..cc38f1e878 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -529,6 +529,12 @@ static void memset_bytes(uint8_t *dst, size_t
dst_size,
uint8_t *clear,
}
} else if (clear_size == 4) {
uint32_t val = AV_RN32(clear);
+uint64_t val8 = val * 0x10001ULL;
+for (; dst_size >= 32; dst_size -= 32) {
+AV_WN64(dst , val8); AV_WN64(dst+ 8, val8);
+AV_WN64(dst+16, val8); AV_WN64(dst+24, val8);
+dst += 32;
+}
for (; dst_size >= 4; dst_size -= 4) {
AV_WN32(dst, val);
dst += 4;
--
2.20.1
NAK, implement special memset function instead.
I can move the added loop into a seperate function, if thats what you
suggest ?
No, don't do that.
All the code is already in a "special" memset though, this is
memset_bytes()
I guess function is less useful if its static. So any duplicate should
be avoided in codebase.
Isn't av_memcpy_backptr does almost exactly what is needed here? That can
also be optimized further if needed.
av_memcpy_backptr() copies data with overlap, its more like a recursive
memmove().
So? As far as I see the memset_bytes function in imgutils.c can be
replaced with this:
if (clear_size > dst_size)
clear_size = dst_size;
memcpy(dst, clear, clear_size);
av_memcpy_backptr(dst + clear_size, clear_size, dst_size - clear_size);
I am not against an av_memset_bytes API addition, but I believe it should
share code with av_memcpy_backptr to avoid duplication.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V7] libavfilter: add transpose_vaapi filter
On 25/12/2018 06:16, Zachary Zhou wrote:
> Swap width and height when do clock/cclock rotation
> Add reversal/reversal_flip options
>
> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> -hwaccel_output_format vaapi -i input.264 -vf "transpose_vaapi=clock_flip"
> -c:v h264_vaapi output.h264
>
> Signed-off-by: Zachary Zhou
> ---
> configure| 2 +
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/transpose.h | 2 +
> libavfilter/vf_transpose_vaapi.c | 338 +++
> 5 files changed, 344 insertions(+)
> create mode 100644 libavfilter/vf_transpose_vaapi.c
>
> diff --git a/configure b/configure
> index be49c19b88..04ee671a60 100755
> --- a/configure
> +++ b/configure
> @@ -3481,6 +3481,7 @@ tinterlace_pad_test_deps="tinterlace_filter"
> tonemap_filter_deps="const_nan"
> tonemap_opencl_filter_deps="opencl const_nan"
> transpose_opencl_filter_deps="opencl"
> +transpose_vaapi_filter_deps="vaapi VAProcPipelineCaps_rotation_flags"
> unsharp_opencl_filter_deps="opencl"
> uspp_filter_deps="gpl avcodec"
> vaguedenoiser_filter_deps="gpl"
> @@ -5984,6 +5985,7 @@ check_type "d3d9.h dxva2api.h"
> DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602
>
> check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
> check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
> check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
> check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
> check_type "va/va.h va/va_enc_vp8.h" "VAEncPictureParameterBufferVP8"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 6e2658186d..4246d3480f 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -394,6 +394,7 @@ OBJS-$(CONFIG_TPAD_FILTER) += vf_tpad.o
> OBJS-$(CONFIG_TRANSPOSE_FILTER) += vf_transpose.o
> OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER) += vf_transpose_npp.o
> cuda_check.o
> OBJS-$(CONFIG_TRANSPOSE_OPENCL_FILTER) += vf_transpose_opencl.o
> opencl.o opencl/transpose.o
> +OBJS-$(CONFIG_TRANSPOSE_VAAPI_FILTER)+= vf_transpose_vaapi.o
> vaapi_vpp.o
> OBJS-$(CONFIG_TRIM_FILTER) += trim.o
> OBJS-$(CONFIG_UNPREMULTIPLY_FILTER) += vf_premultiply.o framesync.o
> OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index a600069500..0b82ff7ced 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -373,6 +373,7 @@ extern AVFilter ff_vf_tpad;
> extern AVFilter ff_vf_transpose;
> extern AVFilter ff_vf_transpose_npp;
> extern AVFilter ff_vf_transpose_opencl;
> +extern AVFilter ff_vf_transpose_vaapi;
> extern AVFilter ff_vf_trim;
> extern AVFilter ff_vf_unpremultiply;
> extern AVFilter ff_vf_unsharp;
> diff --git a/libavfilter/transpose.h b/libavfilter/transpose.h
> index d4bb4da1ae..87936d0512 100644
> --- a/libavfilter/transpose.h
> +++ b/libavfilter/transpose.h
> @@ -29,6 +29,8 @@ enum TransposeDir {
> TRANSPOSE_CLOCK,
> TRANSPOSE_CCLOCK,
> TRANSPOSE_CLOCK_FLIP,
> +TRANSPOSE_REVERSAL,
> +TRANSPOSE_REVERSAL_FLIP,
Add the missing element of D_4 here.
It's not obvious that reversal is "rotate by half-turn" rather than some sort
of flip, maybe a comment.
I think calling the others "HFLIP"/"VFLIP" to match the standalone filters
would be clearer, too.
> };
>
> #endif
> diff --git a/libavfilter/vf_transpose_vaapi.c
> b/libavfilter/vf_transpose_vaapi.c
> new file mode 100644
> index 00..1c7bb0c1a7
> --- /dev/null
> +++ b/libavfilter/vf_transpose_vaapi.c
> @@ -0,0 +1,338 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +#include
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/mem.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
> +
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "vaapi_vpp.h"
> +#include "transpose.h"
> +
> +typedef struct TransposeVAAPIContext {
> +VAAPIVPPContext vpp_ctx; // must be
Re: [FFmpeg-devel] [PATCH V1] avfilter: Add constant VAAPI_VPP_BACKGROUND_BLACK
On 25/12/2018 06:03, Zachary Zhou wrote:
> Signed-off-by: Zachary Zhou
> ---
> libavfilter/vaapi_vpp.h| 2 ++
> libavfilter/vf_deinterlace_vaapi.c | 2 +-
> libavfilter/vf_misc_vaapi.c| 2 +-
> libavfilter/vf_procamp_vaapi.c | 2 +-
> libavfilter/vf_scale_vaapi.c | 2 +-
> 5 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/vaapi_vpp.h b/libavfilter/vaapi_vpp.h
> index 0bc31018d4..bdf3bbaccc 100644
> --- a/libavfilter/vaapi_vpp.h
> +++ b/libavfilter/vaapi_vpp.h
> @@ -27,6 +27,8 @@
>
> #include "avfilter.h"
>
> +#define VAAPI_VPP_BACKGROUND_BLACK 0xff00 //Black in ARGB format
> +
> typedef struct VAAPIVPPContext {
> const AVClass *class;
>
> diff --git a/libavfilter/vf_deinterlace_vaapi.c
> b/libavfilter/vf_deinterlace_vaapi.c
> index f7a262d0c6..97aee6588f 100644
> --- a/libavfilter/vf_deinterlace_vaapi.c
> +++ b/libavfilter/vf_deinterlace_vaapi.c
> @@ -256,7 +256,7 @@ static int deint_vaapi_filter_frame(AVFilterLink *inlink,
> AVFrame *input_frame)
> ff_vaapi_vpp_colour_standard(input_frame->colorspace);
>
> params.output_region = NULL;
> -params.output_background_color = 0xff00;
> +params.output_background_color = VAAPI_VPP_BACKGROUND_BLACK;
> params.output_color_standard = params.surface_color_standard;
>
> params.pipeline_flags = 0;
> diff --git a/libavfilter/vf_misc_vaapi.c b/libavfilter/vf_misc_vaapi.c
> index 30b808a993..e227c9ff6b 100644
> --- a/libavfilter/vf_misc_vaapi.c
> +++ b/libavfilter/vf_misc_vaapi.c
> @@ -174,7 +174,7 @@ static int misc_vaapi_filter_frame(AVFilterLink *inlink,
> AVFrame *input_frame)
> ff_vaapi_vpp_colour_standard(input_frame->colorspace);
>
> params.output_region = NULL;
> -params.output_background_color = 0xff00;
> +params.output_background_color = VAAPI_VPP_BACKGROUND_BLACK;
> params.output_color_standard = params.surface_color_standard;
>
> params.pipeline_flags = 0;
> diff --git a/libavfilter/vf_procamp_vaapi.c b/libavfilter/vf_procamp_vaapi.c
> index 10eccbe97d..46f3ab6465 100644
> --- a/libavfilter/vf_procamp_vaapi.c
> +++ b/libavfilter/vf_procamp_vaapi.c
> @@ -171,7 +171,7 @@ static int procamp_vaapi_filter_frame(AVFilterLink
> *inlink, AVFrame *input_frame
> ff_vaapi_vpp_colour_standard(input_frame->colorspace);
>
> params.output_region = NULL;
> -params.output_background_color = 0xff00;
> +params.output_background_color = VAAPI_VPP_BACKGROUND_BLACK;
> params.output_color_standard = params.surface_color_standard;
>
> params.pipeline_flags = 0;
> diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
> index b06ae764bf..3699363140 100644
> --- a/libavfilter/vf_scale_vaapi.c
> +++ b/libavfilter/vf_scale_vaapi.c
> @@ -133,7 +133,7 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
> AVFrame *input_frame)
> ff_vaapi_vpp_colour_standard(input_frame->colorspace);
>
> params.output_region = 0;
> -params.output_background_color = 0xff00;
> +params.output_background_color = VAAPI_VPP_BACKGROUND_BLACK;
> params.output_color_standard = params.surface_color_standard;
>
> params.pipeline_flags = 0;
>
I added to the comment to include the intended use, then applied.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V1 3/4] lavc/libxavs2: Rename option speed_level to preset
On 30/12/2018 08:39, Jun Zhao wrote:
> preset used in more in line with similar encoders.
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/libxavs2.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
> index 41c0b63..2ade923 100644
> --- a/libavcodec/libxavs2.c
> +++ b/libavcodec/libxavs2.c
> @@ -256,7 +256,7 @@ static const AVOption options[] = {
> { "qp" , "Quantization parameter" ,
> OFFSET(qp) , AV_OPT_TYPE_INT, {.i64 = 34 }, 1, 63, VE },
> { "max_qp" , "max qp for rate control" ,
> OFFSET(max_qp) , AV_OPT_TYPE_INT, {.i64 = 55 }, 0, 63, VE },
> { "min_qp" , "min qp for rate control" ,
> OFFSET(min_qp) , AV_OPT_TYPE_INT, {.i64 = 20 }, 0, 63, VE },
> -{ "speed_level" , "Speed level, higher is better but slower",
> OFFSET(preset_level), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 9, VE },
> +{ "preset" ,"Set the encoding preset, higher is better but
> slower", OFFSET(preset_level), AV_OPT_TYPE_INT, {.i64 = 0 }, 0,
> 9, VE },
> { "log_level" , "log level: -1: none, 0: error, 1: warning, 2:
> info, 3: debug", OFFSET(log_level), AV_OPT_TYPE_INT, {.i64 = 0 }, -1,
> 3, VE },
> { "xavs2-params", "set the xavs2 configuration using a :-separated
> list of key=value parameters", OFFSET(xavs2_opts), AV_OPT_TYPE_STRING, { 0 },
> 0, 0, VE },
> { NULL },
>
Seems unhelpful? The explicit "speed_level" option is much clearer about what
it does.
The name "preset" comes from it generally being a combination of individual
options which together invoke some effect appropriate to the name. E.g. in
libwebp each of the presets configures the encoder appropriately for various
different named styles of input (such as "photo" or "drawing"), which in
libx264 each contains a set of options which combine to change the speed of the
encoder in a way matching the named level (such as "slow" or "veryfast").
Given that, it seems nonsensical to set numbered presets - if you set it to 3,
how would the encoder act threely?
(Also note that this named option was in the 4.1 release, so you may need to
keep the old option with a deprecation period, etc.)
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/x86/af_afir: add avx version of fcmul_add
Signed-off-by: Paul B Mahol
---
libavfilter/x86/af_afir.asm| 15 ---
libavfilter/x86/af_afir_init.c | 6 ++
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/libavfilter/x86/af_afir.asm b/libavfilter/x86/af_afir.asm
index 849d85e70f..e770420a21 100644
--- a/libavfilter/x86/af_afir.asm
+++ b/libavfilter/x86/af_afir.asm
@@ -27,7 +27,7 @@ SECTION .text
; void ff_fcmul_add(float *sum, const float *t, const float *c, int len)
;--
-INIT_XMM sse3
+%macro VECTOR_FCMUL_ADD 0
cglobal fcmul_add, 4,4,6, sum, t, c, len
shl lend, 3
add lend, mmsize*2
@@ -43,8 +43,8 @@ ALIGN 16
movapsm4, [cq + lenq+mmsize]
mulps m0, m1
mulps m3, m4
-shufpsm1, m1, 0xb1
-shufpsm4, m4, 0xb1
+shufpsm1, m1, m1, 0xb1
+shufpsm4, m4, m4, 0xb1
movshdup m2, [tq + lenq]
movshdup m5, [tq + lenq+mmsize]
mulps m2, m1
@@ -58,3 +58,12 @@ ALIGN 16
add lenq, mmsize*2
jl .loop
REP_RET
+%endmacro
+
+INIT_XMM sse3
+VECTOR_FCMUL_ADD
+
+%if HAVE_AVX_EXTERNAL
+INIT_YMM avx
+VECTOR_FCMUL_ADD
+%endif
diff --git a/libavfilter/x86/af_afir_init.c b/libavfilter/x86/af_afir_init.c
index 6a652b9b83..214aaf9719 100644
--- a/libavfilter/x86/af_afir_init.c
+++ b/libavfilter/x86/af_afir_init.c
@@ -25,6 +25,9 @@
void ff_fcmul_add_sse3(float *sum, const float *t, const float *c,
ptrdiff_t len);
+void ff_fcmul_add_avx(float *sum, const float *t, const float *c,
+ ptrdiff_t len);
+
av_cold void ff_afir_init_x86(AudioFIRContext *s)
{
int cpu_flags = av_get_cpu_flags();
@@ -32,4 +35,7 @@ av_cold void ff_afir_init_x86(AudioFIRContext *s)
if (EXTERNAL_SSE3(cpu_flags)) {
s->fcmul_add = ff_fcmul_add_sse3;
}
+if (EXTERNAL_AVX_FAST(cpu_flags)) {
+s->fcmul_add = ff_fcmul_add_avx;
+}
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] avcodec/mjpegbdec: Propagate error codes
On 28/12/2018 21:22, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/mjpegbdec.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) OK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/6] avcodec/mjpegbdec: Fix some misplaced {} and spaces
On 28/12/2018 21:22, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/mjpegbdec.c | 24 +--- > 1 file changed, 9 insertions(+), 15 deletions(-) OK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/prores_ks: fixed luma quantize if q >= MAX_STORED_Q
On 29/12/2018 16:34, Derek Buitenhuis wrote: > I think it's OK. > > I'll push it in 24 hours if noone else objects. Pushed. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
On 12/30/18, Nicolas George wrote: > Paul B Mahol (2018-12-30): >> >> > av_get_channel_layout() used to use '+' instead of '|', and I think >> >> > it >> >> > is better. For once, '+' is not a special character for shells. >> >> >> >> Can not work if user wants to define custom channel layout from >> >> already available channels. >> > >> > Please explain why. >> >> Input #0, wv, from >> '/home/computer/Downloads/Run_The_Race_-_3rd_Order_Ambisonic_SN3D.wv': >> Duration: 00:11:07.67, start: 0.00, bitrate: 6084 kb/s >> Stream #0:0: Audio: wavpack, 44100 Hz, 16 channels >> (FL+FR+FC+LFE+BL+BR+FLC+FRC+BC+SL+SR+TC+TFL+TFC+TFR+TBL), s16p > > Yes... and...? From this is obvious that user can not use '+' to separate channel layouts if it is already used to define channel layouts. Do you need better explanation now? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
Paul B Mahol (2018-12-30): > >> > av_get_channel_layout() used to use '+' instead of '|', and I think it > >> > is better. For once, '+' is not a special character for shells. > >> > >> Can not work if user wants to define custom channel layout from > >> already available channels. > > > > Please explain why. > > Input #0, wv, from > '/home/computer/Downloads/Run_The_Race_-_3rd_Order_Ambisonic_SN3D.wv': > Duration: 00:11:07.67, start: 0.00, bitrate: 6084 kb/s > Stream #0:0: Audio: wavpack, 44100 Hz, 16 channels > (FL+FR+FC+LFE+BL+BR+FLC+FRC+BC+SL+SR+TC+TFL+TFC+TFR+TBL), s16p Yes... and...? signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
On 12/30/18, Nicolas George wrote: > Paul B Mahol (2018-12-30): >> On 12/26/18, Nicolas George wrote: >> >> + * The input string can be represented by: >> >> + * - the formal channel layout name (returned by >> >> av_channel_layout_describe()) >> >> + * - single or multiple channel names (returned by av_channel_name() >> >> + *or concatenated with "|") >> >> + * - a hexadecimal value of a channel layout (eg. "0x4") >> >> + * - the number of channels with default layout (eg. "5") >> >> + * - the number of unordered channels (eg. "4 channels") >> > >> > av_get_channel_layout() used to use '+' instead of '|', and I think it >> > is better. For once, '+' is not a special character for shells. >> >> Can not work if user wants to define custom channel layout from >> already available channels. > > Please explain why. Input #0, wv, from '/home/computer/Downloads/Run_The_Race_-_3rd_Order_Ambisonic_SN3D.wv': Duration: 00:11:07.67, start: 0.00, bitrate: 6084 kb/s Stream #0:0: Audio: wavpack, 44100 Hz, 16 channels (FL+FR+FC+LFE+BL+BR+FLC+FRC+BC+SL+SR+TC+TFL+TFC+TFR+TBL), s16p ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
Paul B Mahol (2018-12-30): > On 12/26/18, Nicolas George wrote: > >> + * The input string can be represented by: > >> + * - the formal channel layout name (returned by > >> av_channel_layout_describe()) > >> + * - single or multiple channel names (returned by av_channel_name() > >> + *or concatenated with "|") > >> + * - a hexadecimal value of a channel layout (eg. "0x4") > >> + * - the number of channels with default layout (eg. "5") > >> + * - the number of unordered channels (eg. "4 channels") > > > > av_get_channel_layout() used to use '+' instead of '|', and I think it > > is better. For once, '+' is not a special character for shells. > > Can not work if user wants to define custom channel layout from > already available channels. Please explain why. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
On 12/26/18, Nicolas George wrote: >> + * The input string can be represented by: >> + * - the formal channel layout name (returned by >> av_channel_layout_describe()) >> + * - single or multiple channel names (returned by av_channel_name() >> + *or concatenated with "|") >> + * - a hexadecimal value of a channel layout (eg. "0x4") >> + * - the number of channels with default layout (eg. "5") >> + * - the number of unordered channels (eg. "4 channels") > > av_get_channel_layout() used to use '+' instead of '|', and I think it > is better. For once, '+' is not a special character for shells. Can not work if user wants to define custom channel layout from already available channels. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] delogo filter: new "uglarm" interpolation mode added
On 12/30/18, Nicolas George wrote:
> Uwe Freese (2018-12-29):
>> The downside is that the term "power" (or "strength") would be more
>> generic
>> and would probably be better reusable for other modes.
>>
>> What do you think? Is "exponent" now ok, or should I change it back to
>> "power", "strength" or something alike?
>
> I would say: do not bother. This can be decided when a new mode is
> added, and options can have several names.
>
> By the way, you would not be interested in developing a logo-detection
> filter, per chance? Something that detects is a certain rectangle is
> likely to contain a logo and computes its bounding box.
>
>> Again, I would be glad about comments and reviews. - Let me know what
>> should
>> be changed and I'll create a new patch in some days.
>
> Here is a more in-depth review from me:
>
>> >From 83e79abb3311eb2dd92c63e8e15e0476af2f2891 Mon Sep 17 00:00:00 2001
>> From: breaker27
>> Date: Wed, 26 Dec 2018 18:16:48 +0100
>> Subject: [PATCH] avfilter/vf_delogo: add uglarm interpolation mode
>>
>> ---
>> doc/filters.texi| 28 +++
>> libavfilter/vf_delogo.c | 189
>> +---
>> 2 files changed, 208 insertions(+), 9 deletions(-)
>>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 65ce25bc18..792560ad79 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -7952,6 +7952,34 @@ Specify the thickness of the fuzzy edge of the
>> rectangle (added to
>> deprecated, setting higher values should no longer be necessary and
>> is not recommended.
>>
>> +@item mode
>> +Specify the interpolation mode used to remove the logo.
>> +It accepts the following values:
>> +@table @option
>> +@item xy
>> +Only the border pixels in straight x and y direction are considered
>> +to replace any logo pixel. This mode tends to flicker and to show
>> +horizontal and vertical lines.
>> +@item uglarm
>> +Consider the whole border for every logo pixel to replace. This mode
>> +uses the distance raised to the power of the given @var{exponent} as
>> +weight that decides to which amount every border pixel is taken into
>> +account. This results in a more blurred area, which tends to be less
>> +distracting. The uglarm mode was first implemented in VirtualDub's
>> +LogoAway filter and is also known from ffdshow and is the
>> +abbreviation for "Uwe's Great LogoAway Remove Mode".
>> +@end table
>> +The default value is @code{xy}.
>> +
>> +@item exponent
>> +Specify the exponent used to calculate the weight out of the
>> +distance in @code{uglarm} mode (weight = distance ^ @var{exponent}).
>> +The value @code{0} results in a logo area which has
>> +the same average color everywhere. The higher the value, the more
>> +relevant a near border pixel will get, meaning that the borders of
>> +the logo area are more similar to the surrounding pixels. The default
>> +value is @code{3}.
>> +
>> @item show
>> When set to 1, a green rectangle is drawn on the screen to simplify
>> finding the right @var{x}, @var{y}, @var{w}, and @var{h} parameters.
>> diff --git a/libavfilter/vf_delogo.c b/libavfilter/vf_delogo.c
>> index 065d093641..dcb0366e63 100644
>> --- a/libavfilter/vf_delogo.c
>> +++ b/libavfilter/vf_delogo.c
>> @@ -2,6 +2,7 @@
>> * Copyright (c) 2002 Jindrich Makovicka
>> * Copyright (c) 2011 Stefano Sabatini
>> * Copyright (c) 2013, 2015 Jean Delvare
>> + * Copyright (c) 2018 Uwe Freese
>> *
>> * This file is part of FFmpeg.
>> *
>> @@ -25,12 +26,16 @@
>> * A very simple tv station logo remover
>> * Originally imported from MPlayer libmpcodecs/vf_delogo.c,
>> * the algorithm was later improved.
>> + * The "UGLARM" mode was first implemented 2001 by Uwe Freese for
>> Virtual
>> + * Dub's LogoAway filter (by Krzysztof Wojdon), taken over into
>> ffdshow's
>> + * logoaway filter (by Milan Cutka), from where it was ported to ffmpeg.
>> */
>>
>> #include "libavutil/common.h"
>> #include "libavutil/imgutils.h"
>> #include "libavutil/opt.h"
>> #include "libavutil/pixdesc.h"
>
>> +#include "libavutil/avassert.h"
>
> We try to keep the includes in alphabetical order.
>
>> #include "avfilter.h"
>> #include "formats.h"
>> #include "internal.h"
>> @@ -50,6 +55,10 @@
>> * @param logo_w width of the logo
>> * @param logo_h height of the logo
>> * @param band the size of the band around the processed area
>> + * @param *uglarmtable pointer to weight table in UGLARM
>> interpolation mode,
>> + * zero when x-y mode is used
>> + * @param *uglarmweightsum pointer to weight sum table in UGLARM
>> interpolation mode,
>> + * zero when x-y mode is used
>> * @param show show a rectangle around the processed area, useful for
>> * parameters tweaking
>> * @param direct if non-zero perform in-place processing
>> @@ -58,7 +67,8 @@ static void apply_delogo(uint8_t *dst, int
>> dst_linesize,
>> uint8_t *src, int src_linesize,
>>
Re: [FFmpeg-devel] [PATCH] delogo filter: new "uglarm" interpolation mode added
Helmut K. C. Tessarek (2018-12-30): > > pow(sqrt(x * x * aspect2 + y * y), exponent / 2); > There seems to be a mistake. You are taking the square root twice. > > Or am I missing something here? Thanks, I wanted to remove the sqrt() and replace it with the /2, not just add the /2. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] delogo filter: new "uglarm" interpolation mode added
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-12-30 08:02, Nicolas George wrote: >> +double d = pow(sqrt(x * x * aspect * aspect + y >> * y), exponent); > pow(sqrt(x * x * aspect2 + y * y), exponent / 2); > There seems to be a mistake. You are taking the square root twice. Or am I missing something here? Cheers, K. C. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE191csiqpm8f5Ln9WvgmFNJ1E3QAFAlwozUAACgkQvgmFNJ1E 3QBvzw/+I6NXL7R+ugiDAmqUxUPwzvv/yJ+Vkbbp7Pl/XGApTol1Odee1P6QYs2t e0Rs93w66+GjPZIMk7dWzl7EdX2GfUl+xPkdGzFOjLvw12nenEf8EoSXuld2Ggx8 b7algcvHeUp1orG3/c98TAjUe2zLwN2oEfHq59v5lShwK9KeThtNOsxQjz08iKfx 41SNqHKYtuz5wo2Ez7BKHZ0iBPrRr4EBJ2BPINbvAUPsELfhblUtGFFX0pumRAaJ skLoPpaJuW3W1uK1/j0DpCNvHQzqrU0rM4hecBT8FaC0jQk6Kbi5RfS3u7xs8Gbq snvPrRUF3UEpp1BILWWPOfG+pnytvOoKdK3j0cv74ImTYBpO7mniUKl9IZbmN1rK 2AbDI/1EH0Vgt44koqOL1hn9/zEZRbnfNrLO4rp9J/SH8+AX1a17Ts7XP/K/G88M +pVq0u11B0/DnwrmnP11W+h6PT2ab6MNm+f57isu047j3ug9f56XvxZh56MDRzBg RXuFqj/qu8p7tymdXfcQOzFQfQQp6pJearzd/pKImfyI/ay1cyT8XjnGKr+VC3NV olT9lEQ13Qb7XBG/ASg6VlDuxyJqY4VRGNVx89/P3ApE406lNRpzgnK8G6XWvTQV swN8f1qxwARqiimhN2iSPCCYDu0svt0DOwymSVUPXhDZNDGqYOQ= =HEMW -END PGP SIGNATURE- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/f_realtime: add option to scale speed
Moritz Barsnick (2018-12-27): > So the limit shall be in "real" realtime? In other words, if the max > sleep time limit is 2 seconds (default), it shall stay there, even if a > speed < 1 slowdown extends all sleep times? That was my point, but it is only an opinion. > (The use case is, for example: Slowdown a 25 fps stream with 0.01, all > sleep times will be around 4 seconds, and therefore be skipped, which > is not quite intended. The user would need to adapt the limit > explicitly.) I had not realized you wanted to slow things down that much. > I can do so. Who decides whether the hunks stays or goes? I'm > indecisive. I think since you made the effort of implementing this, you get to decide that kind of fine details. The preference I have expressed is very minor, both solutions are ok with me. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 1/4] avformat/concatdec: always allow seeking to start
Marton Balint (2018-12-23): > Signed-off-by: Marton Balint > --- > libavformat/concatdec.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) Looks good to me, thanks. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] delogo filter: new "uglarm" interpolation mode added
Uwe Freese (2018-12-29):
> The downside is that the term "power" (or "strength") would be more generic
> and would probably be better reusable for other modes.
>
> What do you think? Is "exponent" now ok, or should I change it back to
> "power", "strength" or something alike?
I would say: do not bother. This can be decided when a new mode is
added, and options can have several names.
By the way, you would not be interested in developing a logo-detection
filter, per chance? Something that detects is a certain rectangle is
likely to contain a logo and computes its bounding box.
> Again, I would be glad about comments and reviews. - Let me know what should
> be changed and I'll create a new patch in some days.
Here is a more in-depth review from me:
> >From 83e79abb3311eb2dd92c63e8e15e0476af2f2891 Mon Sep 17 00:00:00 2001
> From: breaker27
> Date: Wed, 26 Dec 2018 18:16:48 +0100
> Subject: [PATCH] avfilter/vf_delogo: add uglarm interpolation mode
>
> ---
> doc/filters.texi| 28 +++
> libavfilter/vf_delogo.c | 189
> +---
> 2 files changed, 208 insertions(+), 9 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 65ce25bc18..792560ad79 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -7952,6 +7952,34 @@ Specify the thickness of the fuzzy edge of the
> rectangle (added to
> deprecated, setting higher values should no longer be necessary and
> is not recommended.
>
> +@item mode
> +Specify the interpolation mode used to remove the logo.
> +It accepts the following values:
> +@table @option
> +@item xy
> +Only the border pixels in straight x and y direction are considered
> +to replace any logo pixel. This mode tends to flicker and to show
> +horizontal and vertical lines.
> +@item uglarm
> +Consider the whole border for every logo pixel to replace. This mode
> +uses the distance raised to the power of the given @var{exponent} as
> +weight that decides to which amount every border pixel is taken into
> +account. This results in a more blurred area, which tends to be less
> +distracting. The uglarm mode was first implemented in VirtualDub's
> +LogoAway filter and is also known from ffdshow and is the
> +abbreviation for "Uwe's Great LogoAway Remove Mode".
> +@end table
> +The default value is @code{xy}.
> +
> +@item exponent
> +Specify the exponent used to calculate the weight out of the
> +distance in @code{uglarm} mode (weight = distance ^ @var{exponent}).
> +The value @code{0} results in a logo area which has
> +the same average color everywhere. The higher the value, the more
> +relevant a near border pixel will get, meaning that the borders of
> +the logo area are more similar to the surrounding pixels. The default
> +value is @code{3}.
> +
> @item show
> When set to 1, a green rectangle is drawn on the screen to simplify
> finding the right @var{x}, @var{y}, @var{w}, and @var{h} parameters.
> diff --git a/libavfilter/vf_delogo.c b/libavfilter/vf_delogo.c
> index 065d093641..dcb0366e63 100644
> --- a/libavfilter/vf_delogo.c
> +++ b/libavfilter/vf_delogo.c
> @@ -2,6 +2,7 @@
> * Copyright (c) 2002 Jindrich Makovicka
> * Copyright (c) 2011 Stefano Sabatini
> * Copyright (c) 2013, 2015 Jean Delvare
> + * Copyright (c) 2018 Uwe Freese
> *
> * This file is part of FFmpeg.
> *
> @@ -25,12 +26,16 @@
> * A very simple tv station logo remover
> * Originally imported from MPlayer libmpcodecs/vf_delogo.c,
> * the algorithm was later improved.
> + * The "UGLARM" mode was first implemented 2001 by Uwe Freese for Virtual
> + * Dub's LogoAway filter (by Krzysztof Wojdon), taken over into ffdshow's
> + * logoaway filter (by Milan Cutka), from where it was ported to ffmpeg.
> */
>
> #include "libavutil/common.h"
> #include "libavutil/imgutils.h"
> #include "libavutil/opt.h"
> #include "libavutil/pixdesc.h"
> +#include "libavutil/avassert.h"
We try to keep the includes in alphabetical order.
> #include "avfilter.h"
> #include "formats.h"
> #include "internal.h"
> @@ -50,6 +55,10 @@
> * @param logo_w width of the logo
> * @param logo_h height of the logo
> * @param band the size of the band around the processed area
> + * @param *uglarmtable pointer to weight table in UGLARM interpolation
> mode,
> + * zero when x-y mode is used
> + * @param *uglarmweightsum pointer to weight sum table in UGLARM
> interpolation mode,
> + * zero when x-y mode is used
> * @param show show a rectangle around the processed area, useful for
> * parameters tweaking
> * @param direct if non-zero perform in-place processing
> @@ -58,7 +67,8 @@ static void apply_delogo(uint8_t *dst, int dst_linesize,
> uint8_t *src, int src_linesize,
> int w, int h, AVRational sar,
> int logo_x, int logo_y, int logo_w, int logo_h,
> -
[FFmpeg-devel] [PATCH V1 3/4] lavc/libxavs2: Rename option speed_level to preset
preset used in more in line with similar encoders.
Signed-off-by: Jun Zhao
---
libavcodec/libxavs2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
index 41c0b63..2ade923 100644
--- a/libavcodec/libxavs2.c
+++ b/libavcodec/libxavs2.c
@@ -256,7 +256,7 @@ static const AVOption options[] = {
{ "qp" , "Quantization parameter" ,
OFFSET(qp) , AV_OPT_TYPE_INT, {.i64 = 34 }, 1, 63, VE },
{ "max_qp" , "max qp for rate control" ,
OFFSET(max_qp) , AV_OPT_TYPE_INT, {.i64 = 55 }, 0, 63, VE },
{ "min_qp" , "min qp for rate control" ,
OFFSET(min_qp) , AV_OPT_TYPE_INT, {.i64 = 20 }, 0, 63, VE },
-{ "speed_level" , "Speed level, higher is better but slower",
OFFSET(preset_level), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 9, VE },
+{ "preset" ,"Set the encoding preset, higher is better but
slower", OFFSET(preset_level), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 9,
VE },
{ "log_level" , "log level: -1: none, 0: error, 1: warning, 2:
info, 3: debug", OFFSET(log_level), AV_OPT_TYPE_INT, {.i64 = 0 }, -1,
3, VE },
{ "xavs2-params", "set the xavs2 configuration using a :-separated
list of key=value parameters", OFFSET(xavs2_opts), AV_OPT_TYPE_STRING, { 0 },
0, 0, VE },
{ NULL },
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V1 4/4] doc/encoders: Update docs for libxavs2
Update standard libavcodec options for libxavs2
Signed-off-by: Jun Zhao
---
doc/encoders.texi | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index c6fe923..b6f477d 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2335,6 +2335,17 @@ This encoder requires the presence of the libxavs2
headers and library
during configuration. You need to explicitly configure the build with
@option{--enable-libxavs2}.
+The following standard libavcodec options are used:
+@itemize
+@item
+@option{b} / @option{bit_rate}
+@item
+@option{g} / @option{gop_size}
+@item
+@option{bf} / @option{max_b_frames}
+@end itemize
+
+The encoder also has its own specific options:
@subsection Options
@table @option
@@ -2355,8 +2366,8 @@ Set the max qp for rate control from 1 to 63 (default 55).
@item min_qp
Set the min qp for rate control from 1 to 63 (default 20).
-@item speed_level
-Set the Speed level from 0 to 9 (default 0). Higher is better but slower.
+@item preset
+Set the preset level from 0 to 9 (default 0). Higher is better but slower.
@item log_level
Set the log level from -1 to 3 (default 0). -1: none, 0: error,
@@ -2369,7 +2380,7 @@ by ":".
For example to specify libxavs2 encoding options with @option{-xavs2-params}:
@example
-ffmpeg -i input -c:v libxavs2 -xavs2-params preset_level=5 output.avs2
+ffmpeg -i input -c:v libxavs2 -xavs2-params RdoqLevel=0 output.avs2
@end example
@end table
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V1 0/4] XAVS2 update
V1: - Cosmetics: Fix indentation for switch statement in davs2/xavs2 - Rename option speed_level to preset - Update standard libavcodec options in docs part for libxavs2 Jun Zhao (4): lavc/libdavs2: Cosmetics: Fix indentation for switch statement lavc/libxavs2: Cosmetics: Fix indentation for switch statement lavc/libxavs2: Rename option speed_level to preset doc/encoders: Update docs for libxavs2 doc/encoders.texi | 17 ++--- libavcodec/libdavs2.c | 34 +- libavcodec/libxavs2.c | 34 +- 3 files changed, 48 insertions(+), 37 deletions(-) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V1 1/4] lavc/libdavs2: Cosmetics: Fix indentation for switch statement
Cosmetics: Fix indentation for switch statement like the Linux
kerenl style.
Signed-off-by: Jun Zhao
---
libavcodec/libdavs2.c | 34 +-
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 2846ecf..cf75656 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -83,23 +83,23 @@ static int davs2_dump_frames(AVCodecContext *avctx,
davs2_picture_t *pic, int *g
}
switch (pic->type) {
-case DAVS2_PIC_I:
-case DAVS2_PIC_G:
-frame->pict_type = AV_PICTURE_TYPE_I;
-break;
-case DAVS2_PIC_P:
-case DAVS2_PIC_S:
-frame->pict_type = AV_PICTURE_TYPE_P;
-break;
-case DAVS2_PIC_B:
-frame->pict_type = AV_PICTURE_TYPE_B;
-break;
-case DAVS2_PIC_F:
-frame->pict_type = AV_PICTURE_TYPE_S;
-break;
-default:
-av_log(avctx, AV_LOG_ERROR, "Decoder error: unknown frame type\n");
-return AVERROR_EXTERNAL;
+case DAVS2_PIC_I:
+case DAVS2_PIC_G:
+frame->pict_type = AV_PICTURE_TYPE_I;
+break;
+case DAVS2_PIC_P:
+case DAVS2_PIC_S:
+frame->pict_type = AV_PICTURE_TYPE_P;
+break;
+case DAVS2_PIC_B:
+frame->pict_type = AV_PICTURE_TYPE_B;
+break;
+case DAVS2_PIC_F:
+frame->pict_type = AV_PICTURE_TYPE_S;
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Decoder error: unknown frame type\n");
+return AVERROR_EXTERNAL;
}
for (plane = 0; plane < 3; ++plane) {
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V1 2/4] lavc/libxavs2: Cosmetics: Fix indentation for switch statement
Cosmetics: Fix indentation for switch statement like the Linux
kerenl style.
Signed-off-by: Jun Zhao
---
libavcodec/libxavs2.c | 32
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
index 1df4148..41c0b63 100644
--- a/libavcodec/libxavs2.c
+++ b/libavcodec/libxavs2.c
@@ -175,22 +175,22 @@ static int xavs2_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
}
if (frame) {
switch (frame->format) {
-case AV_PIX_FMT_YUV420P:
-if (pic.img.in_sample_size == pic.img.enc_sample_size) {
-xavs2_copy_frame(, frame);
-} else {
-const int shift_in = atoi(cae->api->opt_get(cae->param,
"SampleShift"));
-xavs2_copy_frame_with_shift(, frame, shift_in);
-}
+case AV_PIX_FMT_YUV420P:
+if (pic.img.in_sample_size == pic.img.enc_sample_size) {
+xavs2_copy_frame(, frame);
+} else {
+const int shift_in = atoi(cae->api->opt_get(cae->param,
"SampleShift"));
+xavs2_copy_frame_with_shift(, frame, shift_in);
+}
break;
-case AV_PIX_FMT_YUV420P10:
-if (pic.img.in_sample_size == pic.img.enc_sample_size) {
-xavs2_copy_frame(, frame);
-break;
-}
-default:
-av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format\n");
-return AVERROR(EINVAL);
+case AV_PIX_FMT_YUV420P10:
+if (pic.img.in_sample_size == pic.img.enc_sample_size) {
+xavs2_copy_frame(, frame);
+break;
+}
+default:
+av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format\n");
+return AVERROR(EINVAL);
break;
}
@@ -271,7 +271,7 @@ static const AVClass libxavs2 = {
static const AVCodecDefault xavs2_defaults[] = {
{ "b","0" },
-{ "g","48" },
+{ "g","48"},
{ "bf", "7" },
{ NULL },
};
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
