[FFmpeg-devel] [PATCH 3/3] avformat/dashenc: add avpriv_io_move return value check
fix cid: 1424883
Signed-off-by: Steven Liu
---
libavformat/dashenc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 22ef3103dc..bd0a98da4d 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -384,7 +384,9 @@ static void output_segment_list(OutputStream *os,
AVIOContext *out, DASHContext
avio_close(out_hls);
if (use_rename)
-avpriv_io_move(temp_filename_hls, filename_hls);
+if (avpriv_io_move(temp_filename_hls, filename_hls) < 0) {
+av_log(os->ctx, AV_LOG_WARNING, "rename file from %s to %s
faild\n", temp_filename_hls, filename_hls);
+}
}
}
--
2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avformat/hlsplaylist: add return value check of strftime
fix CID: 1424884
Signed-off-by: Steven Liu
---
libavformat/hlsplaylist.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/hlsplaylist.c b/libavformat/hlsplaylist.c
index 96a8afbe1d..3349eb7ee3 100644
--- a/libavformat/hlsplaylist.c
+++ b/libavformat/hlsplaylist.c
@@ -109,7 +109,10 @@ int ff_hls_write_file_entry(AVIOContext *out, int
insert_discont,
tt = (int64_t)*prog_date_time;
milli = av_clip(lrint(1000*(*prog_date_time - tt)), 0, 999);
tm = localtime_r(&tt, &tmpbuf);
-strftime(buf0, sizeof(buf0), "%Y-%m-%dT%H:%M:%S", tm);
+if (!strftime(buf0, sizeof(buf0), "%Y-%m-%dT%H:%M:%S", tm)) {
+av_log(NULL, AV_LOG_DEBUG, "strftime error in
ff_hls_write_file_entry\n");
+return AVERROR_UNKNOWN;
+}
if (!strftime(buf1, sizeof(buf1), "%z", tm) || buf1[1]<'0'
||buf1[1]>'2') {
int tz_min, dst = tm->tm_isdst;
tm = gmtime_r(&tt, &tmpbuf);
--
2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avformat/hlsplaylist: add int type of API ff_hls_write_file_entry
Signed-off-by: Steven Liu
---
libavformat/dashenc.c | 6 +-
libavformat/hlsenc.c | 12
libavformat/hlsplaylist.c | 6 --
libavformat/hlsplaylist.h | 2 +-
4 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 1783675d00..22ef3103dc 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -342,6 +342,7 @@ static void output_segment_list(OutputStream *os,
AVIOContext *out, DASHContext
AVIOContext *out_hls = NULL;
AVDictionary *http_opts = NULL;
int target_duration = 0;
+int ret = 0;
const char *proto = avio_find_protocol_name(c->dirname);
int use_rename = proto && !strcmp(proto, "file");
@@ -368,11 +369,14 @@ static void output_segment_list(OutputStream *os,
AVIOContext *out, DASHContext
for (i = start_index; i < os->nb_segments; i++) {
Segment *seg = os->segments[i];
-ff_hls_write_file_entry(out_hls, 0, c->single_file,
+ret = ff_hls_write_file_entry(out_hls, 0, c->single_file,
(double) seg->duration / timescale, 0,
seg->range_length, seg->start_pos, NULL,
c->single_file ? os->initfile : seg->file,
NULL);
+if (ret < 0) {
+av_log(os->ctx, AV_LOG_WARNING, "ff_hls_write_file_entry get
error\n");
+}
}
if (final)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index cdfbf45823..3cb636c4c2 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1236,11 +1236,13 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
hls->flags & HLS_SINGLE_FILE, en->size,
en->pos);
}
-ff_hls_write_file_entry(out, en->discont, byterange_mode,
+ret = ff_hls_write_file_entry(out, en->discont, byterange_mode,
en->duration, hls->flags & HLS_ROUND_DURATIONS,
en->size, en->pos, vs->baseurl,
en->filename, prog_date_time_p);
-
+if (ret < 0) {
+av_log(s, AV_LOG_WARNING, "ff_hls_write_file_entry get error\n");
+}
}
if (last && (hls->flags & HLS_OMIT_ENDLIST)==0)
@@ -1251,11 +1253,13 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
goto fail;
ff_hls_write_playlist_header(sub_out, hls->version, hls->allowcache,
target_duration, sequence,
PLAYLIST_TYPE_NONE);
-
for (en = vs->segments; en; en = en->next) {
-ff_hls_write_file_entry(sub_out, 0, byterange_mode,
+ret = ff_hls_write_file_entry(sub_out, 0, byterange_mode,
en->duration, 0, en->size, en->pos,
vs->baseurl, en->sub_filename, NULL);
+if (ret < 0) {
+av_log(s, AV_LOG_WARNING, "ff_hls_write_file_entry get
error\n");
+}
}
if (last)
diff --git a/libavformat/hlsplaylist.c b/libavformat/hlsplaylist.c
index 235e519a9e..96a8afbe1d 100644
--- a/libavformat/hlsplaylist.c
+++ b/libavformat/hlsplaylist.c
@@ -82,14 +82,14 @@ void ff_hls_write_init_file(AVIOContext *out, char
*filename,
avio_printf(out, "\n");
}
-void ff_hls_write_file_entry(AVIOContext *out, int insert_discont,
+int ff_hls_write_file_entry(AVIOContext *out, int insert_discont,
int byterange_mode,
double duration, int round_duration,
int64_t size, int64_t pos, //Used only if
HLS_SINGLE_FILE flag is set
char *baseurl, //Ignored if NULL
char *filename, double *prog_date_time) {
if (!out || !filename)
-return;
+return AVERROR(EINVAL);
if (insert_discont) {
avio_printf(out, "#EXT-X-DISCONTINUITY\n");
@@ -128,6 +128,8 @@ void ff_hls_write_file_entry(AVIOContext *out, int
insert_discont,
if (baseurl)
avio_printf(out, "%s", baseurl);
avio_printf(out, "%s\n", filename);
+
+return 0;
}
void ff_hls_write_end_list (AVIOContext *out) {
diff --git a/libavformat/hlsplaylist.h b/libavformat/hlsplaylist.h
index 4cbc8cacc9..48d71b7c77 100644
--- a/libavformat/hlsplaylist.h
+++ b/libavformat/hlsplaylist.h
@@ -49,7 +49,7 @@ void ff_hls_write_playlist_header(AVIOContext *out, int
version, int allowcache,
uint32_t playlist_type);
void ff_hls_write_init_file(AVIOContext *out, char *filename,
int byterange_mode, int64_t size, int64_t pos);
-void ff_hls_write_file_entry(AVIOContext *out, int insert_discont,
+int ff_hls_write_file_entry(AVIOContext *out, int insert_discont,
Re: [FFmpeg-devel] [PATCH] avfilter: add hflip x86 SIMD
On 12/1/2017 7:02 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/hflip.h | 38 +
> libavfilter/vf_hflip.c | 30 ++--
> libavfilter/x86/Makefile| 2 ++
> libavfilter/x86/vf_hflip.asm| 61
> +
> libavfilter/x86/vf_hflip_init.c | 38 +
> 5 files changed, 160 insertions(+), 9 deletions(-)
> create mode 100644 libavfilter/hflip.h
> create mode 100644 libavfilter/x86/vf_hflip.asm
> create mode 100644 libavfilter/x86/vf_hflip_init.c
>
> diff --git a/libavfilter/hflip.h b/libavfilter/hflip.h
> new file mode 100644
> index 00..138380427c
> --- /dev/null
> +++ b/libavfilter/hflip.h
> @@ -0,0 +1,38 @@
> +/*
> + * Copyright (c) 2007 Benoit Fouet
> + * Copyright (c) 2010 Stefano Sabatini
> + *
> + * 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
> + */
> +
> +#ifndef AVFILTER_HFLIP_H
> +#define AVFILTER_HFLIP_H
> +
> +#include "avfilter.h"
> +
> +typedef struct FlipContext {
> +const AVClass *class;
> +int max_step[4];///< max pixel step for each plane, expressed as a
> number of bytes
> +int planewidth[4]; ///< width of each plane
> +int planeheight[4]; ///< height of each plane
> +
> +void (*flip_line[4])(const uint8_t *src, uint8_t *dst, int w);
> +} FlipContext;
> +
> +void ff_hflip_init_x86(FlipContext *s, int step[4]);
> +
> +#endif /* AVFILTER_HFLIP_H */
> diff --git a/libavfilter/vf_hflip.c b/libavfilter/vf_hflip.c
> index cf20c193f7..65cf7c5cd1 100644
> --- a/libavfilter/vf_hflip.c
> +++ b/libavfilter/vf_hflip.c
> @@ -29,6 +29,7 @@
> #include "libavutil/opt.h"
> #include "avfilter.h"
> #include "formats.h"
> +#include "hflip.h"
> #include "internal.h"
> #include "video.h"
> #include "libavutil/pixdesc.h"
> @@ -36,13 +37,6 @@
> #include "libavutil/intreadwrite.h"
> #include "libavutil/imgutils.h"
>
> -typedef struct FlipContext {
> -const AVClass *class;
> -int max_step[4];///< max pixel step for each plane, expressed as a
> number of bytes
> -int planewidth[4]; ///< width of each plane
> -int planeheight[4]; ///< height of each plane
> -} FlipContext;
> -
> static const AVOption hflip_options[] = {
> { NULL }
> };
> @@ -67,12 +61,21 @@ static int query_formats(AVFilterContext *ctx)
> return ff_set_common_formats(ctx, pix_fmts);
> }
>
> +static void hflip_byte_c(const uint8_t *src, uint8_t *dst, int w)
> +{
> +int j;
> +
> +for (j = 0; j < w; j++)
> +dst[j] = src[-j];
> +}
> +
> static int config_props(AVFilterLink *inlink)
> {
> FlipContext *s = inlink->dst->priv;
> const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(inlink->format);
> const int hsub = pix_desc->log2_chroma_w;
> const int vsub = pix_desc->log2_chroma_h;
> +int i;
>
> av_image_fill_max_pixsteps(s->max_step, NULL, pix_desc);
> s->planewidth[0] = s->planewidth[3] = inlink->w;
> @@ -80,6 +83,16 @@ static int config_props(AVFilterLink *inlink)
> s->planeheight[0] = s->planeheight[3] = inlink->h;
> s->planeheight[1] = s->planeheight[2] = AV_CEIL_RSHIFT(inlink->h, vsub);
>
> +for (i = 0; i < 4; i++) {
> +switch (s->max_step[i]) {
> +case 1:
> +s->flip_line[i] = hflip_byte_c;
> +}
> +}
> +
> +if (ARCH_X86)
> +ff_hflip_init_x86(s, s->max_step);
> +
> return 0;
> }
>
> @@ -109,8 +122,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
> int job, int nb_jobs)
> for (i = start; i < end; i++) {
> switch (step) {
> case 1:
> -for (j = 0; j < width; j++)
> -outrow[j] = inrow[-j];
> +s->flip_line[plane](inrow, outrow, width);
> break;
>
> case 2:
> diff --git a/libavfilter/x86/Makefile b/libavfilter/x86/Makefile
> index 3431625883..1420954f62 100644
> --- a/libavfilter/x86/Makefile
> +++ b/libavfilter/x86/Makefile
> @@ -5,6 +5,7 @@ OBJS-$(CONFIG_COLORSPACE_FILTER) +=
> x86/colorspacedsp_init.o
> OBJS-$(CONFIG_EQ_FILTER) += x86/vf_eq.o
> OBJS-$(CONFIG_FSPP_FILTER) +
Re: [FFmpeg-devel] [PATCH] avfilter: add hflip x86 SIMD
On 12/1/2017 11:13 PM, Michael Niedermayer wrote: > On Fri, Dec 01, 2017 at 11:02:43PM +0100, Paul B Mahol wrote: >> Signed-off-by: Paul B Mahol >> --- >> libavfilter/hflip.h | 38 + >> libavfilter/vf_hflip.c | 30 ++-- >> libavfilter/x86/Makefile| 2 ++ >> libavfilter/x86/vf_hflip.asm| 61 >> + >> libavfilter/x86/vf_hflip_init.c | 38 + >> 5 files changed, 160 insertions(+), 9 deletions(-) >> create mode 100644 libavfilter/hflip.h >> create mode 100644 libavfilter/x86/vf_hflip.asm >> create mode 100644 libavfilter/x86/vf_hflip_init.c > > fails to build on x86-32 linux > > libavfilter/libavfilter.a(vf_hflip_init.o): In function `ff_hflip_init_x86': > src/libavfilter/x86/vf_hflip_init.c:35: undefined reference to > `ff_hflip_byte_ssse3' > collect2: error: ld returned 1 exit status > make: *** [ffmpeg_g] Error 1 > make: *** Waiting for unfinished jobs > libavfilter/libavfilter.a(vf_hflip_init.o): In function `ff_hflip_init_x86': > src/libavfilter/x86/vf_hflip_init.c:35: undefined reference to > `ff_hflip_byte_ssse3' > collect2: error: ld returned 1 exit status > make: *** [ffprobe_g] Error 1 For some reason the whole asm function is wrapped in a x86_64 check even though it's not needed. Guess it was a copy paste mistake. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add hflip x86 SIMD
On Fri, Dec 01, 2017 at 11:02:43PM +0100, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libavfilter/hflip.h | 38 + > libavfilter/vf_hflip.c | 30 ++-- > libavfilter/x86/Makefile| 2 ++ > libavfilter/x86/vf_hflip.asm| 61 > + > libavfilter/x86/vf_hflip_init.c | 38 + > 5 files changed, 160 insertions(+), 9 deletions(-) > create mode 100644 libavfilter/hflip.h > create mode 100644 libavfilter/x86/vf_hflip.asm > create mode 100644 libavfilter/x86/vf_hflip_init.c fails to build on x86-32 linux libavfilter/libavfilter.a(vf_hflip_init.o): In function `ff_hflip_init_x86': src/libavfilter/x86/vf_hflip_init.c:35: undefined reference to `ff_hflip_byte_ssse3' collect2: error: ld returned 1 exit status make: *** [ffmpeg_g] Error 1 make: *** Waiting for unfinished jobs libavfilter/libavfilter.a(vf_hflip_init.o): In function `ff_hflip_init_x86': src/libavfilter/x86/vf_hflip_init.c:35: undefined reference to `ff_hflip_byte_ssse3' collect2: error: ld returned 1 exit status make: *** [ffprobe_g] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hls: fix baseurl missing last char
2017-12-02 8:59 GMT+08:00 Michael Niedermayer :
> On Fri, Dec 01, 2017 at 11:06:07AM +0100, Robert Nagy wrote:
>> ---
>> libavformat/hlsenc.c | 5 +
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index cdfbf45823..dc8bf48791 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1921,14 +1921,11 @@ static int hls_write_header(AVFormatContext *s)
>> }
>>
>> if (hls->baseurl) {
>> -int baseurl_len;
>> -baseurl_len = strlen(hls->baseurl);
>> -vs->baseurl = av_malloc(baseurl_len);
>> +vs->baseurl = av_strdup(hls->baseurl);
>> if (!vs->baseurl) {
>> ret = AVERROR(ENOMEM);
>> goto fail;
>> }
>> -av_strlcpy(vs->baseurl, hls->baseurl, baseurl_len);
>> }
>>
>> if ((hls->flags & HLS_SINGLE_FILE) && (hls->segment_type ==
>> SEGMENT_TYPE_FMP4)) {
>
> this looks like a stray linebreak
> this wont apply automatically
Ok, let me apply it manually.
Thanks
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hls: fix baseurl missing last char
On Fri, Dec 01, 2017 at 11:06:07AM +0100, Robert Nagy wrote:
> ---
> libavformat/hlsenc.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index cdfbf45823..dc8bf48791 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1921,14 +1921,11 @@ static int hls_write_header(AVFormatContext *s)
> }
>
> if (hls->baseurl) {
> -int baseurl_len;
> -baseurl_len = strlen(hls->baseurl);
> -vs->baseurl = av_malloc(baseurl_len);
> +vs->baseurl = av_strdup(hls->baseurl);
> if (!vs->baseurl) {
> ret = AVERROR(ENOMEM);
> goto fail;
> }
> -av_strlcpy(vs->baseurl, hls->baseurl, baseurl_len);
> }
>
> if ((hls->flags & HLS_SINGLE_FILE) && (hls->segment_type ==
> SEGMENT_TYPE_FMP4)) {
this looks like a stray linebreak
this wont apply automatically
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avutil/reverse: make ff_reverse shared
On Thu, Nov 30, 2017 at 10:19:36PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > Pros: > Removes duplicate arrays and ugly c file including c files > > Cons: > Makes the array in libavutil effectively part of the ABI. > Might not be worth doing for 256 bytes if iam not mistaken Accessing symbols accross libs cannot avoid indirection easily. within a lib one can point to the table directly so depending on platform this should be slower with shared libs (this is all of course not strictly unavoidable, it could be done differently but its the way it works on linux if i dont misremember) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix for ticket 6796 (ffprobe show_frames ts dvbsubs infinate loop)
---
fftools/ffprobe.c | 2 ++
libavcodec/dvbsubdec.c | 10 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 0e7a771..6ddd81e 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2280,6 +2280,7 @@ static av_always_inline int process_frame(WriterContext
*w,
break;
default:
*packet_new = 0;
+break;
}
} else {
*packet_new = 0;
@@ -2290,6 +2291,7 @@ static av_always_inline int process_frame(WriterContext
*w,
if (got_frame) {
int is_sub = (par->codec_type == AVMEDIA_TYPE_SUBTITLE);
nb_streams_frames[pkt->stream_index]++;
+got_frame = (par->codec_type == AVMEDIA_TYPE_SUBTITLE) ? 0: got_frame;
if (do_show_frames)
if (is_sub)
show_subtitle(w, &sub, ifile->streams[pkt->stream_index].st,
fmt_ctx);
diff --git a/libavcodec/dvbsubdec.c b/libavcodec/dvbsubdec.c
index a657b1d..29997a2 100644
--- a/libavcodec/dvbsubdec.c
+++ b/libavcodec/dvbsubdec.c
@@ -1596,7 +1596,7 @@ static int dvbsub_display_end_segment(AVCodecContext
*avctx, const uint8_t *buf,
}
static int dvbsub_decode(AVCodecContext *avctx,
- void *data, int *data_size,
+ void *data, int *got_output,
AVPacket *avpkt)
{
const uint8_t *buf = avpkt->data;
@@ -1654,7 +1654,7 @@ static int dvbsub_decode(AVCodecContext *avctx,
int ret = 0;
switch (segment_type) {
case DVBSUB_PAGE_SEGMENT:
-ret = dvbsub_parse_page_segment(avctx, p, segment_length, sub,
data_size);
+ret = dvbsub_parse_page_segment(avctx, p, segment_length, sub,
got_output);
got_segment |= 1;
break;
case DVBSUB_REGION_SEGMENT:
@@ -1676,7 +1676,7 @@ static int dvbsub_decode(AVCodecContext *avctx,
got_dds = 1;
break;
case DVBSUB_DISPLAY_SEGMENT:
-ret = dvbsub_display_end_segment(avctx, p, segment_length,
sub, data_size);
+ret = dvbsub_display_end_segment(avctx, p, segment_length,
sub, got_output);
if (got_segment == 15 && !got_dds && !avctx->width &&
!avctx->height) {
// Default from ETSI EN 300 743 V1.3.1 (7.2.1)
avctx->width = 720;
@@ -1699,12 +1699,12 @@ static int dvbsub_decode(AVCodecContext *avctx,
// segments then we need no further data.
if (got_segment == 15) {
av_log(avctx, AV_LOG_DEBUG, "Missing display_end_segment,
emulating\n");
-dvbsub_display_end_segment(avctx, p, 0, sub, data_size);
+dvbsub_display_end_segment(avctx, p, 0, sub, got_output);
}
end:
if(ret < 0) {
-*data_size = 0;
+*got_output = 0;
avsubtitle_free(sub);
return ret;
} else {
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix for ticket 6796 (ffprobe show_frames ts dvbsubs infinate loop)
On Sat, Dec 2, 2017 at 1:05 AM, Hendrik Leppkes wrote:
>
>> @@ -2290,6 +2294,7 @@ static av_always_inline int
>> process_frame(WriterContext *w,
>> if (got_frame) {
>> int is_sub = (par->codec_type == AVMEDIA_TYPE_SUBTITLE);
>> nb_streams_frames[pkt->stream_index]++;
>> +got_frame = 0;
Having looked at the logic some more, this part seems to be the key
(although implemented too broadly). We don't want to repeat the loop
for subtitles, so you set got_frame = 0 here - but you should only do
it for subtitles, not for everyhting.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix for ticket 6796 (ffprobe show_frames ts dvbsubs infinate loop)
On Sat, Dec 2, 2017 at 12:55 AM, Colin NG wrote:
> ---
> fftools/ffprobe.c | 5 +
> libavcodec/decode.c | 5 -
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 0e7a771..20b64ef 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -2276,10 +2276,14 @@ static av_always_inline int
> process_frame(WriterContext *w,
>
> case AVMEDIA_TYPE_SUBTITLE:
> ret = avcodec_decode_subtitle2(dec_ctx, &sub, &got_frame, pkt);
> +if (ret == AVERROR(EINVAL) || ret == AVERROR_INVALIDDATA) {
> +ret = 0;
> +}
Ignoring certain error codes doesn't seem correct. If decoding of a
subtitle fails, it should be handled somewhere, not just ignored.
> @@ -2290,6 +2294,7 @@ static av_always_inline int process_frame(WriterContext
> *w,
> if (got_frame) {
> int is_sub = (par->codec_type == AVMEDIA_TYPE_SUBTITLE);
> nb_streams_frames[pkt->stream_index]++;
> +got_frame = 0;
> if (do_show_frames)
> if (is_sub)
> show_subtitle(w, &sub, ifile->streams[pkt->stream_index].st,
> fmt_ctx);
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 3f5b086..d6cc671 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1024,7 +1024,10 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx,
> AVSubtitle *sub,
> if (avctx->pkt_timebase.num && avpkt->pts != AV_NOPTS_VALUE)
> sub->pts = av_rescale_q(avpkt->pts,
> avctx->pkt_timebase, AV_TIME_BASE_Q);
> -ret = avctx->codec->decode(avctx, sub, got_sub_ptr,
> &pkt_recoded);
> +ret = avctx->codec->decode(avctx, sub, &pkt_recoded.size,
> &pkt_recoded);
> +if (ret == avpkt->size) {
> + *got_sub_ptr = 1;
> +}
> av_assert1((ret >= 0) >= !!*got_sub_ptr &&
> !!*got_sub_ptr >= !!sub->num_rects);
>
This looks definitely wrong. The decode API has a "*got_frame" ptr
there, not any size parameter, and additionally just because it
consumed data it does not mean any data was actually output.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix for ticket 6796 (ffprobe show_frames ts dvbsubs infinate loop)
---
fftools/ffprobe.c | 5 +
libavcodec/decode.c | 5 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 0e7a771..20b64ef 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2276,10 +2276,14 @@ static av_always_inline int process_frame(WriterContext
*w,
case AVMEDIA_TYPE_SUBTITLE:
ret = avcodec_decode_subtitle2(dec_ctx, &sub, &got_frame, pkt);
+if (ret == AVERROR(EINVAL) || ret == AVERROR_INVALIDDATA) {
+ret = 0;
+}
*packet_new = 0;
break;
default:
*packet_new = 0;
+break;
}
} else {
*packet_new = 0;
@@ -2290,6 +2294,7 @@ static av_always_inline int process_frame(WriterContext
*w,
if (got_frame) {
int is_sub = (par->codec_type == AVMEDIA_TYPE_SUBTITLE);
nb_streams_frames[pkt->stream_index]++;
+got_frame = 0;
if (do_show_frames)
if (is_sub)
show_subtitle(w, &sub, ifile->streams[pkt->stream_index].st,
fmt_ctx);
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 3f5b086..d6cc671 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1024,7 +1024,10 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx,
AVSubtitle *sub,
if (avctx->pkt_timebase.num && avpkt->pts != AV_NOPTS_VALUE)
sub->pts = av_rescale_q(avpkt->pts,
avctx->pkt_timebase, AV_TIME_BASE_Q);
-ret = avctx->codec->decode(avctx, sub, got_sub_ptr, &pkt_recoded);
+ret = avctx->codec->decode(avctx, sub, &pkt_recoded.size,
&pkt_recoded);
+if (ret == avpkt->size) {
+ *got_sub_ptr = 1;
+}
av_assert1((ret >= 0) >= !!*got_sub_ptr &&
!!*got_sub_ptr >= !!sub->num_rects);
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_threshold: add x86 SIMD
On 12/1/2017 3:41 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/threshold.h | 51 +++
> libavfilter/vf_threshold.c | 28 ---
> libavfilter/x86/Makefile| 2 ++
> libavfilter/x86/vf_threshold.asm| 69
> +
> libavfilter/x86/vf_threshold_init.c | 41 ++
> 5 files changed, 169 insertions(+), 22 deletions(-)
> create mode 100644 libavfilter/threshold.h
> create mode 100644 libavfilter/x86/vf_threshold.asm
> create mode 100644 libavfilter/x86/vf_threshold_init.c
[..]
> diff --git a/libavfilter/x86/vf_threshold_init.c
> b/libavfilter/x86/vf_threshold_init.c
> new file mode 100644
> index 00..e2bbae11d5
> --- /dev/null
> +++ b/libavfilter/x86/vf_threshold_init.c
> @@ -0,0 +1,41 @@
> +/*
> + * Copyright (c) 2015 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "libavutil/attributes.h"
> +#include "libavutil/cpu.h"
> +#include "libavutil/x86/cpu.h"
> +#include "libavfilter/threshold.h"
> +
> +void ff_threshold8_sse4(const uint8_t *in, const uint8_t *threshold,
> +const uint8_t *min, const uint8_t *max,
> +uint8_t *out,
> +ptrdiff_t ilinesize, ptrdiff_t tlinesize,
> +ptrdiff_t flinesize, ptrdiff_t slinesize,
> +ptrdiff_t olinesize,
> +int w, int h);
> +
> +av_cold void ff_threshold_init_x86(ThresholdContext *s)
> +{
> +int cpu_flags = av_get_cpu_flags();
> +
> +if (ARCH_X86_64 && EXTERNAL_SSE4(cpu_flags) && s->depth == 8) {
> +s->threshold = ff_threshold8_sse4;
> +}
> +}
>
Can you add a checkasm test for this function, or at least a normal test
for the filter that covers it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] rkmpp: Add hardware config information
This is not strictly required here because the rkmpp decoder does not
call ff_get_format(), but it may be helpful metadata for users.
---
libavcodec/rkmppdec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/rkmppdec.c b/libavcodec/rkmppdec.c
index bdf4dc4208..4ec61cbb35 100644
--- a/libavcodec/rkmppdec.c
+++ b/libavcodec/rkmppdec.c
@@ -28,6 +28,7 @@
#include "avcodec.h"
#include "decode.h"
+#include "hwaccel.h"
#include "internal.h"
#include "libavutil/buffer.h"
#include "libavutil/common.h"
@@ -563,6 +564,10 @@ static void rkmpp_flush(AVCodecContext *avctx)
av_log(avctx, AV_LOG_ERROR, "Failed to reset MPI (code = %d)\n", ret);
}
+static const AVCodecHWConfigInternal *rkmpp_hw_configs[] = {
+HW_CONFIG_INTERNAL(DRM_PRIME),
+NULL
+};
#define RKMPP_DEC_CLASS(NAME) \
static const AVClass rkmpp_##NAME##_dec_class = { \
@@ -587,6 +592,7 @@ static void rkmpp_flush(AVCodecContext *avctx)
.caps_internal = AV_CODEC_CAP_AVOID_PROBING, \
.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_DRM_PRIME,
\
AV_PIX_FMT_NONE}, \
+.hw_configs = rkmpp_hw_configs, \
.bsfs = BSFS, \
};
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/huffyuvenc : try to call dsp with aligned data, and remove code duplication
On Sun, Nov 26, 2017 at 07:07:41PM +0100, Martin Vignali wrote:
> Hello,
>
> in attach patchs
>
> 0001-avcodec-huffyuvenc-increase-scalar-loop-count
> and
> 0003-avcodec-huffyuvenc-sub_left_prediction_bgr32-call-ds
>
> like diff_bytes and diff_bytes16, have AVX2 version, increase the scalar
> loop
> to call the aligned version in most case
>
>
>
> 0002-avcodec-huffyuvenc-remove-code-duplication-in
> remove some code duplication, for width < 32 and for the initial scalar loop
>
>
> pass fate test for me (x86_64, mac os 10.12)
>
> Martin
> huffyuvenc.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 32eecc99e666808926e1dec4ff35c17a94f5f86e
> 0001-avcodec-huffyuvenc-increase-scalar-loop-count.patch
> From 9477be212247012ac386beeff009a2edb78abb31 Mon Sep 17 00:00:00 2001
> From: Martin Vignali
> Date: Sun, 26 Nov 2017 19:01:29 +0100
> Subject: [PATCH 1/3] avcodec/huffyuvenc : increase scalar loop count
>
> in order to try to call dsp in aligned mode
> (diff_int16 have AVX2 now)
> ---
> libavcodec/huffyuvenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
> index 89639b75df..4f3a28e033 100644
> --- a/libavcodec/huffyuvenc.c
> +++ b/libavcodec/huffyuvenc.c
> @@ -80,12 +80,12 @@ static inline int sub_left_prediction(HYuvContext *s,
> uint8_t *dst,
> }
> return left;
> } else {
> -for (i = 0; i < 16; i++) {
> +for (i = 0; i < 32; i++) {
> const int temp = src16[i];
> dst16[i] = temp - left;
> left = temp;
> }
> -s->hencdsp.diff_int16(dst16 + 16, src16 + 16, src16 + 15, s->n -
> 1, w - 16);
> +s->hencdsp.diff_int16(dst16 + 32, src16 + 32, src16 + 31, s->n -
> 1, w - 32);
> return src16[w-1];
> }
> }
> --
> 2.11.0 (Apple Git-81)
>
> huffyuvenc.c | 46 --
> 1 file changed, 16 insertions(+), 30 deletions(-)
> ba80747db2582141ec0faefc5ccd04fba65c7d72
> 0002-avcodec-huffyuvenc-remove-code-duplication-in.patch
> From 7fa991ae72c97f4d1f74789e543cf01dcb93adb9 Mon Sep 17 00:00:00 2001
> From: Martin Vignali
> Date: Sun, 26 Nov 2017 19:02:10 +0100
> Subject: [PATCH 2/3] avcodec/huffyuvenc : remove code duplication in
> sub_left_prediction
>
> start of the line (before dsp call), can be merge with width < 32 part
> ---
> libavcodec/huffyuvenc.c | 46 --
> 1 file changed, 16 insertions(+), 30 deletions(-)
>
> diff --git a/libavcodec/huffyuvenc.c b/libavcodec/huffyuvenc.c
> index 4f3a28e033..59da49212e 100644
> --- a/libavcodec/huffyuvenc.c
> +++ b/libavcodec/huffyuvenc.c
> @@ -53,41 +53,27 @@ static inline int sub_left_prediction(HYuvContext *s,
> uint8_t *dst,
> {
> int i;
> if (s->bps <= 8) {
> -if (w < 32) {
> -for (i = 0; i < w; i++) {
> -const int temp = src[i];
> -dst[i] = temp - left;
> -left = temp;
> -}
> -return left;
> -} else {
> -for (i = 0; i < 32; i++) {
> -const int temp = src[i];
> -dst[i] = temp - left;
> -left = temp;
> -}
> -s->llvidencdsp.diff_bytes(dst + 32, src + 32, src + 31, w - 32);
> -return src[w-1];
> +for (i = 0; i < FFMIN(w, 32); i++) { /* scalar loop before dsp call
> */
> +const int temp = src[i];
> +dst[i] = temp - left;
> +left = temp;
requiring FFMIN() to be evaluated per iteration could be slower
if the compiler fails to factor it out
no other comments from me, the patches should be ok otherwise
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add hflip x86 SIMD
Signed-off-by: Paul B Mahol
---
libavfilter/hflip.h | 38 +
libavfilter/vf_hflip.c | 30 ++--
libavfilter/x86/Makefile| 2 ++
libavfilter/x86/vf_hflip.asm| 61 +
libavfilter/x86/vf_hflip_init.c | 38 +
5 files changed, 160 insertions(+), 9 deletions(-)
create mode 100644 libavfilter/hflip.h
create mode 100644 libavfilter/x86/vf_hflip.asm
create mode 100644 libavfilter/x86/vf_hflip_init.c
diff --git a/libavfilter/hflip.h b/libavfilter/hflip.h
new file mode 100644
index 00..138380427c
--- /dev/null
+++ b/libavfilter/hflip.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2007 Benoit Fouet
+ * Copyright (c) 2010 Stefano Sabatini
+ *
+ * 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
+ */
+
+#ifndef AVFILTER_HFLIP_H
+#define AVFILTER_HFLIP_H
+
+#include "avfilter.h"
+
+typedef struct FlipContext {
+const AVClass *class;
+int max_step[4];///< max pixel step for each plane, expressed as a
number of bytes
+int planewidth[4]; ///< width of each plane
+int planeheight[4]; ///< height of each plane
+
+void (*flip_line[4])(const uint8_t *src, uint8_t *dst, int w);
+} FlipContext;
+
+void ff_hflip_init_x86(FlipContext *s, int step[4]);
+
+#endif /* AVFILTER_HFLIP_H */
diff --git a/libavfilter/vf_hflip.c b/libavfilter/vf_hflip.c
index cf20c193f7..65cf7c5cd1 100644
--- a/libavfilter/vf_hflip.c
+++ b/libavfilter/vf_hflip.c
@@ -29,6 +29,7 @@
#include "libavutil/opt.h"
#include "avfilter.h"
#include "formats.h"
+#include "hflip.h"
#include "internal.h"
#include "video.h"
#include "libavutil/pixdesc.h"
@@ -36,13 +37,6 @@
#include "libavutil/intreadwrite.h"
#include "libavutil/imgutils.h"
-typedef struct FlipContext {
-const AVClass *class;
-int max_step[4];///< max pixel step for each plane, expressed as a
number of bytes
-int planewidth[4]; ///< width of each plane
-int planeheight[4]; ///< height of each plane
-} FlipContext;
-
static const AVOption hflip_options[] = {
{ NULL }
};
@@ -67,12 +61,21 @@ static int query_formats(AVFilterContext *ctx)
return ff_set_common_formats(ctx, pix_fmts);
}
+static void hflip_byte_c(const uint8_t *src, uint8_t *dst, int w)
+{
+int j;
+
+for (j = 0; j < w; j++)
+dst[j] = src[-j];
+}
+
static int config_props(AVFilterLink *inlink)
{
FlipContext *s = inlink->dst->priv;
const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(inlink->format);
const int hsub = pix_desc->log2_chroma_w;
const int vsub = pix_desc->log2_chroma_h;
+int i;
av_image_fill_max_pixsteps(s->max_step, NULL, pix_desc);
s->planewidth[0] = s->planewidth[3] = inlink->w;
@@ -80,6 +83,16 @@ static int config_props(AVFilterLink *inlink)
s->planeheight[0] = s->planeheight[3] = inlink->h;
s->planeheight[1] = s->planeheight[2] = AV_CEIL_RSHIFT(inlink->h, vsub);
+for (i = 0; i < 4; i++) {
+switch (s->max_step[i]) {
+case 1:
+s->flip_line[i] = hflip_byte_c;
+}
+}
+
+if (ARCH_X86)
+ff_hflip_init_x86(s, s->max_step);
+
return 0;
}
@@ -109,8 +122,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
int job, int nb_jobs)
for (i = start; i < end; i++) {
switch (step) {
case 1:
-for (j = 0; j < width; j++)
-outrow[j] = inrow[-j];
+s->flip_line[plane](inrow, outrow, width);
break;
case 2:
diff --git a/libavfilter/x86/Makefile b/libavfilter/x86/Makefile
index 3431625883..1420954f62 100644
--- a/libavfilter/x86/Makefile
+++ b/libavfilter/x86/Makefile
@@ -5,6 +5,7 @@ OBJS-$(CONFIG_COLORSPACE_FILTER) +=
x86/colorspacedsp_init.o
OBJS-$(CONFIG_EQ_FILTER) += x86/vf_eq.o
OBJS-$(CONFIG_FSPP_FILTER) += x86/vf_fspp_init.o
OBJS-$(CONFIG_GRADFUN_FILTER)+= x86/vf_gradfun_init.o
+OBJS-$(CONFIG_HFLIP_FILTER) += x86/vf_hflip_init.o
OBJS-$(CONFIG_HQDN3D_FILTER) += x86/vf_hqdn3d_init.o
OBJS-$(CONFIG_IDET_FILTER) += x86/vf_idet_init.o
OBJS-$(CONFIG_INTERLACE_FILTER)
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/hevcdsp_template: Fix undefined shift in put_hevc_epel_bi_w_h()
On Thu, Nov 30, 2017 at 11:58:09PM +0100, Michael Niedermayer wrote: > Fixes: runtime error: left shift of negative value -127 > Fixes: 4397/clusterfuzz-testcase-minimized-4779061080489984 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/hevcdsp_template.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) patchset applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] rtsp: only break on parse_rtsp_message on error
Fix suggested by Luca Barbato.
This was causing spurious EOFs when using -rtsp_transport udp, as
reported in https://bugzilla.libav.org/show_bug.cgi?id=1103
---
libavformat/rtsp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index b6da61b95e..cf7cdb2f2b 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -2009,7 +2009,9 @@ static int udp_read_packet(AVFormatContext *s, RTSPStream
**prtsp_st,
}
#if CONFIG_RTSP_DEMUXER
if (rt->rtsp_hd && p[0].revents & POLLIN) {
-return parse_rtsp_message(s);
+if ((ret = parse_rtsp_message(s)) < 0) {
+return ret;
+}
}
#endif
} else if (n == 0 && ++timeout_cnt >= MAX_TIMEOUTS) {
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_threshold: add x86 SIMD
> >> > > Do you need pxor m0, m4 and pxor m1, m4 ? > > Yes, > I need it. > > Yes, you're right, sorry for the noise Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mediacodecdec: fix build by including hwaccel.h
On Fri, Dec 1, 2017 at 10:44 PM, Mark Thompson wrote: > > LGTM. > > (Apologies for breaking that.) > Thanks for the LGTM. Pushed with the header include added in its alphabetically ordered position as recommended on IRC. And no problem, we all miss things :) . Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] lavc/arm/hevcdsp_idct_neon: build failure with clang + gas-preprocessor
Hi, I have been testing FFmpeg with the Android NDK (R15)'s clang, and recently (a few weeks ago) the build has broken at libavcodec/arm/hevcdsp_idct_neon. It should be enough to test this with --cc=arm-linux-androideabi-clang (or any other ARM clang compiler) and the latest gas-preprocessor.pl in PATH for NEON SIMD (https://git.libav.org/?p=gas-preprocessor.git;a=summary). The errors are as follows: > AS libavcodec/arm/hevcdsp_idct_neon.o > :356:10: error: out of range pc-relative fixup value > ldr r3, Literal_0 > ^ > :358:10: error: out of range pc-relative fixup value > ldr r3, Literal_1 > ^ > :360:10: error: out of range pc-relative fixup value > ldr r3, Literal_2 > ^ Best regards, Jan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mediacodecdec: fix build by including hwaccel.h
On 01/12/17 20:30, Jan Ekström wrote:
> Enables the decoder to utilize the type AVCodecHWConfigInternal.
> ---
> libavcodec/mediacodecdec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 6d392adb3a..63209f52ac 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -36,6 +36,7 @@
> #include "internal.h"
> #include "mediacodec_wrapper.h"
> #include "mediacodecdec_common.h"
> +#include "hwaccel.h"
>
> typedef struct MediaCodecH264DecContext {
>
>
LGTM.
(Apologies for breaking that.)
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_threshold: add x86 SIMD
On 12/1/2017 5:00 PM, Martin Vignali wrote: > Hello, > > + >> +INIT_XMM sse4 >> > Maybe use a macro (AVX2 can probably, be easy to add) > > >> +cglobal threshold8, 10, 13, 5, in, threshold, min, max, out, ilinesize, >> tlinesize, flinesize, slinesize, olinesize, w, h, x >> +mov wd, dword wm >> +mov hd, dword hm >> > Maybe you can use ptrdiff_t for w and h, so you can directly use it, using > wq, hq It makes no difference in practice. w and h need to be loaded from memory no matter what. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mediacodecdec: fix build by including hwaccel.h
Enables the decoder to utilize the type AVCodecHWConfigInternal.
---
libavcodec/mediacodecdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 6d392adb3a..63209f52ac 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -36,6 +36,7 @@
#include "internal.h"
#include "mediacodec_wrapper.h"
#include "mediacodecdec_common.h"
+#include "hwaccel.h"
typedef struct MediaCodecH264DecContext {
--
2.14.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Recent regression in VA-API compatibility (assertion in H.264 encode)
On 01/12/17 18:37, Devin Heitmueller wrote: > Hi Mark, > >>> >>> Here’s the vainfo output which provides the version info for the driver, >>> va-api version, etc. This is on a Haswell system running Centos 7. >>> >>> libva info: VA-API version 0.34.0 >>> libva info: va_getDriverName() returns 0 >>> libva info: Trying to open /usr/lib64/dri/i965_drv_video.so >>> libva info: Found init function __vaDriverInit_0_34 >>> libva info: va_openDriver() returns 0 >>> vainfo: VA-API version: 0.34 (libva 1.2.1) >>> vainfo: Driver version: Intel i965 driver - 1.2.2 >> >> Upgrading to a version less than four years old might be a plan - I admit we >> do notionally support that version because of old RHEL/CentOS, but it is not >> well tested (as you are finding). > > This is actually what you get with the very latest release of Centos 7.4 > (downloaded yesterday). Hence while we could certainly argue that perhaps > they’re shipping versions that are too old, it’s not like I’m running some > archaic five-year-old copy of Centos I found a DVD for in the bottom of a > drawer. :-) Yeah, I'm aware that it is still current despite the archaic packages - if it weren't we would probably have dropped it already, at least for encode. > And don’t misunderstand, I’m not against saying “Centos is dumb and should > bundle newer versions of the library/driver/whatever” - I’m just trying to > make clear that this is what the experience will be of any non-technical user > who just does a binary install from the most recent versions of one of the > more popular distros. I'm not sure that's quite accurate - if you install on current hardware it will refuse to run at all because that version of the driver doesn't support anything newer than Haswell :P But yes, it should definitely be fixed somehow. At some point that "fix" is to drop support for it, though. - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Recent regression in VA-API compatibility (assertion in H.264 encode)
On 01/12/17 18:47, Devin Heitmueller wrote:
>
>>> Try this? (Not tested, hardware which can run a version that old isn't
>>> immediately to hand.)
>>>
>>> --- a/libavcodec/vaapi_encode_h264.c
>>> +++ b/libavcodec/vaapi_encode_h264.c
>>> @@ -261,7 +261,8 @@ static int
>>> vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
>>>return 0;
>>>
>>> #if !CONFIG_VAAPI_1
>>> -} else if (priv->sei_cbr_workaround_needed) {
>>> +} else if (priv->sei_cbr_workaround_needed &&
>>> + ctx->va_packed_headers & VA_ENC_PACKED_HEADER_SLICE) {
>>>// Insert a zero-length header using the old SEI type. This is
>>>// required to avoid triggering broken behaviour on Intel platforms
>>>// in CBR mode where an invalid SEI message is generated by the
>>>
>>
>> Ok, will give this a try tonight and report back on my findings.
>
> FYI: this doesn’t appear to have had any effect - I still get the same
> assert message.
Urgh, right. It's the SEI it doesn't like rather than the workaround.
"-sei 0" will make it work, I think? Something further would likely need a
specific test for old versions of the Intel driver.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_threshold: add x86 SIMD
On 12/1/17, Martin Vignali wrote: > Hello, > > + >> +INIT_XMM sse4 >> > Maybe use a macro (AVX2 can probably, be easy to add) Not now. > > >> +cglobal threshold8, 10, 13, 5, in, threshold, min, max, out, ilinesize, >> tlinesize, flinesize, slinesize, olinesize, w, h, x >> +mov wd, dword wm >> +mov hd, dword hm >> > Maybe you can use ptrdiff_t for w and h, so you can directly use it, using > wq, hq Feel free to change that later. > > >> +movam4, [pb_128] >> +addinq, wq >> +add thresholdq, wq >> +add minq, wq >> +add maxq, wq >> +add outq, wq >> +neg wq >> +.nextrow: >> +mov xq, wq >> + >> +.loop: >> +movum1, [inq + xq] >> +movum0, [thresholdq + xq] >> +movum2, [minq + xq] >> +movum3, [maxq + xq] >> +pxorm0, m4 >> +pxorm1, m4 >> > Do you need pxor m0, m4 and pxor m1, m4 ? Yes, I need it. > > >> +pcmpgtb m0, m1 >> +pblendvbm3, m2, m0 >> +movu [outq + xq], m3 >> +add xq, mmsize >> +jl .loop >> + >> +add inq, ilinesizeq >> +add thresholdq, tlinesizeq >> +add minq, flinesizeq >> +add maxq, slinesizeq >> +add outq, olinesizeq >> +sub hd, 1 >> +jg .nextrow >> +RET >> > > > Martin > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_threshold: add x86 SIMD
Hello, + > +INIT_XMM sse4 > Maybe use a macro (AVX2 can probably, be easy to add) > +cglobal threshold8, 10, 13, 5, in, threshold, min, max, out, ilinesize, > tlinesize, flinesize, slinesize, olinesize, w, h, x > +mov wd, dword wm > +mov hd, dword hm > Maybe you can use ptrdiff_t for w and h, so you can directly use it, using wq, hq > +movam4, [pb_128] > +addinq, wq > +add thresholdq, wq > +add minq, wq > +add maxq, wq > +add outq, wq > +neg wq > +.nextrow: > +mov xq, wq > + > +.loop: > +movum1, [inq + xq] > +movum0, [thresholdq + xq] > +movum2, [minq + xq] > +movum3, [maxq + xq] > +pxorm0, m4 > +pxorm1, m4 > Do you need pxor m0, m4 and pxor m1, m4 ? > +pcmpgtb m0, m1 > +pblendvbm3, m2, m0 > +movu [outq + xq], m3 > +add xq, mmsize > +jl .loop > + > +add inq, ilinesizeq > +add thresholdq, tlinesizeq > +add minq, flinesizeq > +add maxq, slinesizeq > +add outq, olinesizeq > +sub hd, 1 > +jg .nextrow > +RET > Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/huffyuvenc : try to call dsp with aligned data, and remove code duplication
2017-11-26 19:07 GMT+01:00 Martin Vignali : > Hello, > > in attach patchs > > 0001-avcodec-huffyuvenc-increase-scalar-loop-count > and > 0003-avcodec-huffyuvenc-sub_left_prediction_bgr32-call-ds > > like diff_bytes and diff_bytes16, have AVX2 version, increase the scalar > loop > to call the aligned version in most case > > > > 0002-avcodec-huffyuvenc-remove-code-duplication-in > remove some code duplication, for width < 32 and for the initial scalar > loop > > > pass fate test for me (x86_64, mac os 10.12) > > Martin > Ping. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avutil/x86util : add macro for 128 bits constant load
2017-11-28 21:04 GMT+01:00 Henrik Gramner : > On Mon, Nov 27, 2017 at 11:37 PM, James Almer wrote: > > On 11/27/2017 7:33 PM, James Darnley wrote: > >> If the condition was made "mmsize > 16" would this work correctly for > >> zmm registers? (Assume I finally push my AVX-512 patches). > > > > No, there's no EVEX variant of vbroadcasti128. For that you would need > > to use vbroadcasti32x4 or vbroadcasti64x2. > > x86inc handles that. > If no one have objections, i will push these patch tomorrow. Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/mem: define DECLARE_ASM_ALIGNED for DJGPP
This was apparently missed in 43171a2a738f5114768d34a7278e56e5fde714bc Signed-off-by: James Almer --- libavutil/mem.h | 1 + 1 file changed, 1 insertion(+) diff --git a/libavutil/mem.h b/libavutil/mem.h index 9e344bd2c3..6f72498890 100644 --- a/libavutil/mem.h +++ b/libavutil/mem.h @@ -106,6 +106,7 @@ #define DECLARE_ASM_CONST(n,t,v)const t __attribute__ ((aligned (n))) v #elif defined(__DJGPP__) #define DECLARE_ALIGNED(n,t,v) t __attribute__ ((aligned (FFMIN(n, 16 v +#define DECLARE_ASM_ALIGNED(n,t,v) t __attribute__ ((aligned (FFMIN(n, 16 v #define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ ((aligned (FFMIN(n, 16 v #elif defined(__GNUC__) || defined(__clang__) #define DECLARE_ALIGNED(n,t,v) t __attribute__ ((aligned (n))) v -- 2.15.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [ogg] Respect AVERROR codes returned by ogg header parsing.
On Thu, Nov 30, 2017 at 5:49 PM, Michael Niedermayer wrote:
> I dont see anything really wrong with the file
>
For kicks, I tried running it through oggz-validate, but it doesn't know
how to handle ogm. Which TIL, is distinct from ogv.
>
> it seems what happens is that theres a data packet in one stream that
> preceeds the headers on the other streams, technically that data packet
> likely contains the video headers so its kind of a header too.
>
> The demuxer stops header parsing prematurly due to this.
> from there on it gets confused reading the same header twice
> while it determines the duration of the file which triggers the error
>
> There are a few differnt ways to fix this, iam not sure which is the
> simplest but i dont think the demuxer should fail in this case
>
>
Applying a workaround similar to what you did here works:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=c04c43b3e423d0426162828e7b180e4d0014a3f7
I.e. condition AVERROR_INVALIDATA based on priv->vp being incomplete here:
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/oggparsevorbis.c;h=65b1998a02d92d0fcaeb740d8f4523641502dbea;hb=HEAD#l319
WDYT? Here's a patch to do this and fail on AVERROR w/o the AV_EF_EXPLODE
restriction.
- dale
From a6f5e47b54a08ac0ab2461b5e5189748059c7a9f Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Tue, 28 Nov 2017 13:40:20 -0800
Subject: [PATCH] Respect AVERROR codes returned by ogg parsers.
Fixes ticket #6804. All of the ogg header and packet parsers may
return standard AVERROR codes; these return values should not be
treated as success.
Additionally changes oggparsevorbis, to not give up too early
with certain types of poorly muxed files.
Signed-off-by: Dale Curtis
---
libavformat/oggdec.c | 14 +++---
libavformat/oggparsevorbis.c | 2 +-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
index 193a286e43..38f60653f9 100644
--- a/libavformat/oggdec.c
+++ b/libavformat/oggdec.c
@@ -543,7 +543,11 @@ static int ogg_packet(AVFormatContext *s, int *sid, int *dstart, int *dsize,
os->incomplete = 0;
if (os->header) {
-os->header = os->codec->header(s, idx);
+if ((ret = os->codec->header(s, idx)) < 0) {
+av_log(s, AV_LOG_ERROR, "Header processing failed: %s\n", av_err2str(ret));
+return ret;
+}
+os->header = ret;
if (!os->header) {
os->segp = segp;
os->psize = psize;
@@ -574,8 +578,12 @@ static int ogg_packet(AVFormatContext *s, int *sid, int *dstart, int *dsize,
} else {
os->pflags= 0;
os->pduration = 0;
-if (os->codec && os->codec->packet)
-os->codec->packet(s, idx);
+if (os->codec && os->codec->packet) {
+if ((ret = os->codec->packet(s, idx)) < 0) {
+av_log(s, AV_LOG_ERROR, "Packet processing failed: %s\n", av_err2str(ret));
+return ret;
+}
+}
if (sid)
*sid = idx;
if (dstart)
diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
index 65b1998a02..29b1ab514e 100644
--- a/libavformat/oggparsevorbis.c
+++ b/libavformat/oggparsevorbis.c
@@ -317,7 +317,7 @@ static int vorbis_header(AVFormatContext *s, int idx)
if (priv->packet[pkt_type >> 1])
return AVERROR_INVALIDDATA;
if (pkt_type > 1 && !priv->packet[0] || pkt_type > 3 && !priv->packet[1])
-return AVERROR_INVALIDDATA;
+return priv->vp ? 0 : AVERROR_INVALIDDATA;
priv->len[pkt_type >> 1]= os->psize;
priv->packet[pkt_type >> 1] = av_mallocz(os->psize);
--
2.15.0.531.g2ccb3012c9-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swscale/utils: Remove bpc==8 gating init_range_convert
On Thu, Nov 30, 2017 at 9:52 AM, Michael Niedermayer wrote: > > > Perfect, thanks Michael. Let me check those samples out. > > there are 2 more in 2939 which change: > https://trac.ffmpeg.org/ticket/2939 > It seems the swscale_unscaled code paths do not get reconfigured when sws_setColorSpaceDetails is called. The unscaled code path also seems to get called for yuv420p16le->yuv420p, so the patch only affected those samples when doing some scaling. But the newer results looks consistent with direct conversion to rgb (and is consistent when I decode the samples in matlab). > > > > > For that sample, I feel like it may be incorrectly tagged as pc/full. > > is it stored in the file or taken from: > ff_generate_avci_extradata() > maybe theres a bug in the AVCIntra handling > > It seems avci100_1080i_extradata may be the one that is signalling full range for the AVCI100.mov sample. I tested changing the range flag: -0x3c, 0x60, 0x20, 0x20, 0x28, 0x00, 0x00, 0x03, +0x3c, 0x20, 0x20, 0x20, 0x28, 0x00, 0x00, 0x03, There is an unused ACLR atom in the mov that also appears to signal full range (parsing of that atom is skipped for h264) > > > > Report generated with: > > > https://raw.githubusercontent.com/nbirkbeck/ffmpeg-test- > > > samples/master/color-range/run.sh > > Can you turn this into a fate test ? > Will do. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data
On Fri, Dec 01, 2017 at 07:23:00PM +0100, Nicolas George wrote: > Michael Niedermayer (2017-12-01): > > As the one who tried implementing changing frame parameters like > > dimension long time ago, the only real problem i encountered was > > bikeshedding, i dont rememer a technical problem. > > "not easy" != "tremendously hard". I said it would not be easy, i.e. it > will require work and careful testing, but it is doable. > > But what you did was wrong, too simple, and results in our libraries > outputting inconsistent data. Do you think this comment will fix any issue or improve anything ? First i do not even know what you speak of exactly and as this is supposedly about code i wrote, i doubt others will have a better idea. And there is possibly a difference in goals. Reinitializing filters would loose filter state, so avoiding reinit unless really needed was a big goal. Last but not least what i had envissioned is just in my head, i never implemeted it. (the bikeshedding made me loose interrest back then as i already mentioned) what is in git is a small part of it, that alone certainly is not that great. and "too simple" yes my vission of this was and is simple > > No time to say more today. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Recent regression in VA-API compatibility (assertion in H.264 encode)
>> Try this? (Not tested, hardware which can run a version that old isn't
>> immediately to hand.)
>>
>> --- a/libavcodec/vaapi_encode_h264.c
>> +++ b/libavcodec/vaapi_encode_h264.c
>> @@ -261,7 +261,8 @@ static int
>> vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
>>return 0;
>>
>> #if !CONFIG_VAAPI_1
>> -} else if (priv->sei_cbr_workaround_needed) {
>> +} else if (priv->sei_cbr_workaround_needed &&
>> + ctx->va_packed_headers & VA_ENC_PACKED_HEADER_SLICE) {
>>// Insert a zero-length header using the old SEI type. This is
>>// required to avoid triggering broken behaviour on Intel platforms
>>// in CBR mode where an invalid SEI message is generated by the
>>
>
> Ok, will give this a try tonight and report back on my findings.
FYI: this doesn’t appear to have had any effect - I still get the same assert
message.
Devin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_threshold: add x86 SIMD
Signed-off-by: Paul B Mahol
---
libavfilter/threshold.h | 51 +++
libavfilter/vf_threshold.c | 28 ---
libavfilter/x86/Makefile| 2 ++
libavfilter/x86/vf_threshold.asm| 69 +
libavfilter/x86/vf_threshold_init.c | 41 ++
5 files changed, 169 insertions(+), 22 deletions(-)
create mode 100644 libavfilter/threshold.h
create mode 100644 libavfilter/x86/vf_threshold.asm
create mode 100644 libavfilter/x86/vf_threshold_init.c
diff --git a/libavfilter/threshold.h b/libavfilter/threshold.h
new file mode 100644
index 00..8b55ad6ba1
--- /dev/null
+++ b/libavfilter/threshold.h
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2016 Paul B Mahol
+ *
+ * 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
+ */
+
+#ifndef AVFILTER_THRESHOLD_H
+#define AVFILTER_THRESHOLD_H
+
+#include "avfilter.h"
+#include "framesync.h"
+
+typedef struct ThresholdContext {
+const AVClass *class;
+
+int depth;
+int planes;
+int bpc;
+
+int nb_planes;
+int width[4], height[4];
+
+void (*threshold)(const uint8_t *in, const uint8_t *threshold,
+ const uint8_t *min, const uint8_t *max,
+ uint8_t *out,
+ ptrdiff_t ilinesize, ptrdiff_t tlinesize,
+ ptrdiff_t flinesize, ptrdiff_t slinesize,
+ ptrdiff_t olinesize,
+ int w, int h);
+
+AVFrame *frames[4];
+FFFrameSync fs;
+} ThresholdContext;
+
+void ff_threshold_init_x86(ThresholdContext *s);
+
+#endif /* AVFILTER_THRESHOLD_H */
diff --git a/libavfilter/vf_threshold.c b/libavfilter/vf_threshold.c
index 76c3ddb892..4183b353d2 100644
--- a/libavfilter/vf_threshold.c
+++ b/libavfilter/vf_threshold.c
@@ -31,27 +31,7 @@
#include "framesync.h"
#include "internal.h"
#include "video.h"
-
-typedef struct ThresholdContext {
-const AVClass *class;
-
-int planes;
-int bpc;
-
-int nb_planes;
-int width[4], height[4];
-
-void (*threshold)(const uint8_t *in, const uint8_t *threshold,
- const uint8_t *min, const uint8_t *max,
- uint8_t *out,
- ptrdiff_t ilinesize, ptrdiff_t tlinesize,
- ptrdiff_t flinesize, ptrdiff_t slinesize,
- ptrdiff_t olinesize,
- int w, int h);
-
-AVFrame *frames[4];
-FFFrameSync fs;
-} ThresholdContext;
+#include "threshold.h"
#define OFFSET(x) offsetof(ThresholdContext, x)
#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
@@ -203,8 +183,9 @@ static int config_input(AVFilterLink *inlink)
s->height[0] = s->height[3] = inlink->h;
s->width[1] = s->width[2] = AV_CEIL_RSHIFT(inlink->w, hsub);
s->width[0] = s->width[3] = inlink->w;
+s->depth = desc->comp[0].depth;
-if (desc->comp[0].depth == 8) {
+if (s->depth == 8) {
s->threshold = threshold8;
s->bpc = 1;
} else {
@@ -212,6 +193,9 @@ static int config_input(AVFilterLink *inlink)
s->bpc = 2;
}
+if (ARCH_X86)
+ff_threshold_init_x86(s);
+
return 0;
}
diff --git a/libavfilter/x86/Makefile b/libavfilter/x86/Makefile
index 3431625883..c10f4d5538 100644
--- a/libavfilter/x86/Makefile
+++ b/libavfilter/x86/Makefile
@@ -20,6 +20,7 @@ OBJS-$(CONFIG_SPP_FILTER)+= x86/vf_spp.o
OBJS-$(CONFIG_SSIM_FILTER) += x86/vf_ssim_init.o
OBJS-$(CONFIG_STEREO3D_FILTER) += x86/vf_stereo3d_init.o
OBJS-$(CONFIG_TBLEND_FILTER) += x86/vf_blend_init.o
+OBJS-$(CONFIG_THRESHOLD_FILTER) += x86/vf_threshold_init.o
OBJS-$(CONFIG_TINTERLACE_FILTER) += x86/vf_tinterlace_init.o
OBJS-$(CONFIG_VOLUME_FILTER) += x86/af_volume_init.o
OBJS-$(CONFIG_W3FDIF_FILTER) += x86/vf_w3fdif_init.o
@@ -46,6 +47,7 @@ X86ASM-OBJS-$(CONFIG_SHOWCQT_FILTER) +=
x86/avf_showcqt.o
X86ASM-OBJS-$(CONFIG_SSIM_FILTER)+= x86/vf_ssim.o
X86ASM-OBJS-$(CONFIG_STEREO3D_FILTER)+= x86/vf_stereo3d.o
X86ASM-OBJS-$(CONFIG_TBLEND_FILTER) += x86/vf_blend.o
+X86ASM-OBJS-$(CONFIG_THRESHOLD_FILTER)
Re: [FFmpeg-devel] Recent regression in VA-API compatibility (assertion in H.264 encode)
Hi Mark,
>>
>> Here’s the vainfo output which provides the version info for the driver,
>> va-api version, etc. This is on a Haswell system running Centos 7.
>>
>> libva info: VA-API version 0.34.0
>> libva info: va_getDriverName() returns 0
>> libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
>> libva info: Found init function __vaDriverInit_0_34
>> libva info: va_openDriver() returns 0
>> vainfo: VA-API version: 0.34 (libva 1.2.1)
>> vainfo: Driver version: Intel i965 driver - 1.2.2
>
> Upgrading to a version less than four years old might be a plan - I admit we
> do notionally support that version because of old RHEL/CentOS, but it is not
> well tested (as you are finding).
This is actually what you get with the very latest release of Centos 7.4
(downloaded yesterday). Hence while we could certainly argue that perhaps
they’re shipping versions that are too old, it’s not like I’m running some
archaic five-year-old copy of Centos I found a DVD for in the bottom of a
drawer. :-)
And don’t misunderstand, I’m not against saying “Centos is dumb and should
bundle newer versions of the library/driver/whatever” - I’m just trying to make
clear that this is what the experience will be of any non-technical user who
just does a binary install from the most recent versions of one of the more
popular distros.
>
> Try this? (Not tested, hardware which can run a version that old isn't
> immediately to hand.)
>
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -261,7 +261,8 @@ static int
> vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
> return 0;
>
> #if !CONFIG_VAAPI_1
> -} else if (priv->sei_cbr_workaround_needed) {
> +} else if (priv->sei_cbr_workaround_needed &&
> + ctx->va_packed_headers & VA_ENC_PACKED_HEADER_SLICE) {
> // Insert a zero-length header using the old SEI type. This is
> // required to avoid triggering broken behaviour on Intel platforms
> // in CBR mode where an invalid SEI message is generated by the
>
Ok, will give this a try tonight and report back on my findings.
Thanks!
Devin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_overlay: add premultiplied alpha mode
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 4 ++
libavfilter/vf_overlay.c | 160 ---
2 files changed, 140 insertions(+), 24 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index f7c371592f..0699728b7e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11328,6 +11328,10 @@ Default value is @samp{yuv420}.
@item repeatlast
See @ref{framesync}.
+
+@item alpha
+Set format of alpha, it can be @var{straight} or @var{premultiplied}.
+Default is @var{straight}.
@end table
The @option{x}, and @option{y} expressions can contain the following
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index 5bf3d66cf1..8206dae454 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -109,6 +109,7 @@ typedef struct OverlayContext {
uint8_t overlay_rgba_map[4];
uint8_t overlay_has_alpha;
int format; ///< OverlayFormat
+int alpha_format;
int eval_mode; ///< EvalMode
FFFrameSync fs;
@@ -403,7 +404,8 @@ static int config_output(AVFilterLink *outlink)
static void blend_image_packed_rgb(AVFilterContext *ctx,
AVFrame *dst, const AVFrame *src,
- int main_has_alpha, int x, int y)
+ int main_has_alpha, int x, int y,
+ int is_straight)
{
OverlayContext *s = ctx->priv;
int i, imax, j, jmax;
@@ -454,9 +456,9 @@ static void blend_image_packed_rgb(AVFilterContext *ctx,
default:
// main_value = main_value * (1 - alpha) + overlay_value *
alpha
// since alpha is in the range 0-255, the result must divided
by 255
-d[dr] = FAST_DIV255(d[dr] * (255 - alpha) + S[sr] * alpha);
-d[dg] = FAST_DIV255(d[dg] * (255 - alpha) + S[sg] * alpha);
-d[db] = FAST_DIV255(d[db] * (255 - alpha) + S[sb] * alpha);
+d[dr] = is_straight ? FAST_DIV255(d[dr] * (255 - alpha) +
S[sr] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
+d[dg] = is_straight ? FAST_DIV255(d[dg] * (255 - alpha) +
S[sg] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
+d[db] = is_straight ? FAST_DIV255(d[db] * (255 - alpha) +
S[sb] * alpha) : FAST_DIV255(d[dr] * (255 - alpha) + S[sr]);
}
if (main_has_alpha) {
switch (alpha) {
@@ -487,7 +489,9 @@ static av_always_inline void blend_plane(AVFilterContext
*ctx,
int main_has_alpha,
int dst_plane,
int dst_offset,
- int dst_step)
+ int dst_step,
+ int straight,
+ int yuv)
{
int src_wp = AV_CEIL_RSHIFT(src_w, hsub);
int src_hp = AV_CEIL_RSHIFT(src_h, vsub);
@@ -546,7 +550,14 @@ static av_always_inline void blend_plane(AVFilterContext
*ctx,
alpha_d = da[0];
alpha = UNPREMULTIPLY_ALPHA(alpha, alpha_d);
}
-*d = FAST_DIV255(*d * (255 - alpha) + *s * alpha);
+if (straight) {
+*d = FAST_DIV255(*d * (255 - alpha) + *s * alpha);
+} else {
+if (i && yuv)
+*d = av_clip(FAST_DIV255((*d - 128) * (255 - alpha)) + *s
- 128, -128, 128) + 128;
+else
+*d = FFMIN(FAST_DIV255(*d * (255 - alpha)) + *s, 255);
+}
s++;
d += dst_step;
da += 1 << hsub;
@@ -605,7 +616,8 @@ static av_always_inline void
blend_image_yuv(AVFilterContext *ctx,
AVFrame *dst, const AVFrame *src,
int hsub, int vsub,
int main_has_alpha,
- int x, int y)
+ int x, int y,
+ int is_straight)
{
OverlayContext *s = ctx->priv;
const int src_w = src->width;
@@ -614,11 +626,11 @@ static av_always_inline void
blend_image_yuv(AVFilterContext *ctx,
const int dst_h = dst->height;
blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 0, 0, 0, x,
y, main_has_alpha,
-s->main_desc->comp[0].plane, s->main_desc->comp[0].offset,
s->main_desc->comp[0].step);
+s->main_desc->comp[0].plane, s->main_desc->comp[0].offset,
s->main_desc->comp[0].step, is_straight, 1);
blend_plane(ctx, dst, src, src_w, src_h, dst_w, dst_h, 1, hsub, vsub, x,
y, main_has_alpha,
-s->main_desc->comp[1].plane, s->main_desc->comp[1].offset,
s->main_desc->comp[1
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data
On 12/1/17, Nicolas George wrote: > Michael Niedermayer (2017-12-01): >> As the one who tried implementing changing frame parameters like >> dimension long time ago, the only real problem i encountered was >> bikeshedding, i dont rememer a technical problem. > > "not easy" != "tremendously hard". I said it would not be easy, i.e. it > will require work and careful testing, but it is doable. > > But what you did was wrong, too simple, and results in our libraries > outputting inconsistent data. > > No time to say more today. If you do not have "time" to speak than do not speak at all. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Recent regression in VA-API compatibility (assertion in H.264 encode)
The vainfo shows that you're running very old versions. You may be able to resolve the issues you're facing by first removing stale versions of libva, libva-utils and intel-vaapi-driver, then reinstalling with the latest: https://github.com/01org/libva https://github.com/01org/libva-utils https://github.com/01org/intel-vaapi-driver -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Devin Heitmueller Sent: Friday, December 1, 2017 8:49 AM To: FFmpeg development discussions and patches Subject: [FFmpeg-devel] Recent regression in VA-API compatibility (assertion in H.264 encode) Hello, It looks like a recent patch causes VA-API H.264 encode to stop working and an assertion to be thrown. I ran a git bisect and narrowed it down to the following commit: 32a618a948c20f18db102d0b0976790222a57105 is the first bad commit commit 32a618a948c20f18db102d0b0976790222a57105 Author: Mark Thompson Date: Wed Oct 18 19:46:53 2017 +0100 vaapi_h264: Do not use deprecated header type SEI headers should be inserted as generic raw data (the old specific type has been deprecated in libva2). When run with the above patch, I get the following output: [h264_vaapi @ 0x37d0a20] Warning: some packed headers are not supported (want 0xd, got 0xb). [h264_vaapi @ 0x37d0a20] The encode compression level option is not supported with this VAAPI version. ffmpeg: i965_drv_video.c:352: va_enc_packed_type_to_idx: Assertion `0' failed. Here’s the vainfo output which provides the version info for the driver, va-api version, etc. This is on a Haswell system running Centos 7. libva info: VA-API version 0.34.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_34 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.34 (libva 1.2.1) vainfo: Driver version: Intel i965 driver - 1.2.2 I’m using the following command line for testing: ./ffmpeg -y -vaapi_device /dev/dri/card0 -i /home/devin/inputfile.ts -vf 'format=nv12,hwupload' -c:v h264_vaapi out.mp4 Any suggestions that could be offered would be greatly appreciated. Likewise please let me know if there is any other information I can provide that would assist in getting this resolved. Thanks, Devin Heitmueller ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data
Michael Niedermayer (2017-12-01): > As the one who tried implementing changing frame parameters like > dimension long time ago, the only real problem i encountered was > bikeshedding, i dont rememer a technical problem. "not easy" != "tremendously hard". I said it would not be easy, i.e. it will require work and careful testing, but it is doable. But what you did was wrong, too simple, and results in our libraries outputting inconsistent data. No time to say more today. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Recent regression in VA-API compatibility (assertion in H.264 encode)
On 01/12/17 16:48, Devin Heitmueller wrote:
> Hello,
>
> It looks like a recent patch causes VA-API H.264 encode to stop working and
> an assertion to be thrown. I ran a git bisect and narrowed it down to the
> following commit:
>
> 32a618a948c20f18db102d0b0976790222a57105 is the first bad commit
> commit 32a618a948c20f18db102d0b0976790222a57105
> Author: Mark Thompson
> Date: Wed Oct 18 19:46:53 2017 +0100
>
> vaapi_h264: Do not use deprecated header type
>
> SEI headers should be inserted as generic raw data (the old specific
> type has been deprecated in libva2).
>
>
> When run with the above patch, I get the following output:
>
> [h264_vaapi @ 0x37d0a20] Warning: some packed headers are not supported (want
> 0xd, got 0xb).
> [h264_vaapi @ 0x37d0a20] The encode compression level option is not supported
> with this VAAPI version.
> ffmpeg: i965_drv_video.c:352: va_enc_packed_type_to_idx: Assertion `0' failed.
>
> Here’s the vainfo output which provides the version info for the driver,
> va-api version, etc. This is on a Haswell system running Centos 7.
>
> libva info: VA-API version 0.34.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
> libva info: Found init function __vaDriverInit_0_34
> libva info: va_openDriver() returns 0
> vainfo: VA-API version: 0.34 (libva 1.2.1)
> vainfo: Driver version: Intel i965 driver - 1.2.2
Upgrading to a version less than four years old might be a plan - I admit we do
notionally support that version because of old RHEL/CentOS, but it is not well
tested (as you are finding).
>
> I’m using the following command line for testing:
>
> ./ffmpeg -y -vaapi_device /dev/dri/card0 -i /home/devin/inputfile.ts -vf
> 'format=nv12,hwupload' -c:v h264_vaapi out.mp4
>
> Any suggestions that could be offered would be greatly appreciated. Likewise
> please let me know if there is any other information I can provide that would
> assist in getting this resolved.
Try this? (Not tested, hardware which can run a version that old isn't
immediately to hand.)
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -261,7 +261,8 @@ static int
vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
return 0;
#if !CONFIG_VAAPI_1
-} else if (priv->sei_cbr_workaround_needed) {
+} else if (priv->sei_cbr_workaround_needed &&
+ ctx->va_packed_headers & VA_ENC_PACKED_HEADER_SLICE) {
// Insert a zero-length header using the old SEI type. This is
// required to avoid triggering broken behaviour on Intel platforms
// in CBR mode where an invalid SEI message is generated by the
(Probably wants a comment pointing at the driver code to explain why that
condition, too.)
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data
On Fri, Dec 01, 2017 at 06:10:02PM +0100, wm4 wrote:
> On Fri, 1 Dec 2017 18:02:52 +0100
> Michael Niedermayer wrote:
>
> > On Fri, Dec 01, 2017 at 10:01:42AM +0100, Nicolas George wrote:
> > > Paul B Mahol (2017-11-30):
> > > > +static int reset_links(AVFilterContext *filter)
> > > > +{
> > > > +int i, ret;
> > > > +
> > > > +if (!filter)
> > > > +return 0;
> > > > +
> > > > +for (i = 0; i < filter->nb_outputs; i++) {
> > > > +AVFilterLink *link = filter->outputs[i];
> > > > +
> > > > +link->init_state = AVLINK_UNINIT;
> > > > +link->frame_rate.num = link->frame_rate.den = 0;
> > > > +link->w = link->h = 0;
> > > > +
> > > > +ret = reset_links(link->dst);
> > > > +if (ret < 0)
> > > > +return ret;
> > > > +}
> > > > +
> > > > +if (!i)
> > > > +return avfilter_config_links(filter);
> > > > +
> > > > +return 0;
> > > > +}
> > >
> > > Sorry, but no. All filters are currently written with the assumption
> > > that config_props is called only once. Not all of them actually rely on
> > > this assumption, but some do, and expect the fields of the private
> > > context to be in their initial state. Violating that assumption would
> > > result in a lot of memory leaks and probably a few crashes, some of them
> > > security relevant.
> > >
> > > Plus, the public API of buffersink does not document params changes and
> > > does not provide a good way of reacting to it, so enabling params
> > > changes like that would have problematic results on applications that
> > > expect frames with all the same size.
> > >
> > > (By the way, I am quite worried to see that Michael weakened the
> > > protections for that last point in 5d859e59809.)
> > >
> >
> > > Filters reconfiguration has been wanted for a lot of time. If it was
> > > that simple, it would have been done already. If you want to implement
> > > it, please go ahead, but it will not be an easy task.
> >
> > As the one who tried implementing changing frame parameters like
> > dimension long time ago, the only real problem i encountered was
> > bikeshedding, i dont rememer a technical problem. The bikeshedding in
> > fact resolved itself but by the time i had lost interrest ...
> >
> > And in fact many filters should just be able to handle changing frame
> > parameters as they are or with minimal changes.
>
> Well, the result is that at least the vf_scale filter appears to
> blatantly violate the API and crashes my software.
This sounds unlikely but
Which ticket on trac is that ?
And what part of which API do you speak about ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data
On 12/1/17, wm4 wrote:
> On Fri, 1 Dec 2017 18:02:52 +0100
> Michael Niedermayer wrote:
>
>> On Fri, Dec 01, 2017 at 10:01:42AM +0100, Nicolas George wrote:
>> > Paul B Mahol (2017-11-30):
>> > > +static int reset_links(AVFilterContext *filter)
>> > > +{
>> > > +int i, ret;
>> > > +
>> > > +if (!filter)
>> > > +return 0;
>> > > +
>> > > +for (i = 0; i < filter->nb_outputs; i++) {
>> > > +AVFilterLink *link = filter->outputs[i];
>> > > +
>> > > +link->init_state = AVLINK_UNINIT;
>> > > +link->frame_rate.num = link->frame_rate.den = 0;
>> > > +link->w = link->h = 0;
>> > > +
>> > > +ret = reset_links(link->dst);
>> > > +if (ret < 0)
>> > > +return ret;
>> > > +}
>> > > +
>> > > +if (!i)
>> > > +return avfilter_config_links(filter);
>> > > +
>> > > +return 0;
>> > > +}
>> >
>> > Sorry, but no. All filters are currently written with the assumption
>> > that config_props is called only once. Not all of them actually rely on
>> > this assumption, but some do, and expect the fields of the private
>> > context to be in their initial state. Violating that assumption would
>> > result in a lot of memory leaks and probably a few crashes, some of them
>> > security relevant.
>> >
>> > Plus, the public API of buffersink does not document params changes and
>> > does not provide a good way of reacting to it, so enabling params
>> > changes like that would have problematic results on applications that
>> > expect frames with all the same size.
>> >
>> > (By the way, I am quite worried to see that Michael weakened the
>> > protections for that last point in 5d859e59809.)
>> >
>>
>> > Filters reconfiguration has been wanted for a lot of time. If it was
>> > that simple, it would have been done already. If you want to implement
>> > it, please go ahead, but it will not be an easy task.
>>
>> As the one who tried implementing changing frame parameters like
>> dimension long time ago, the only real problem i encountered was
>> bikeshedding, i dont rememer a technical problem. The bikeshedding in
>> fact resolved itself but by the time i had lost interrest ...
>>
>> And in fact many filters should just be able to handle changing frame
>> parameters as they are or with minimal changes.
>
> Well, the result is that at least the vf_scale filter appears to
> blatantly violate the API and crashes my software.
How?
The current "support" works only with some filters and when input itself
have parameter changes, using other filters in same filtergraph will just
crash.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data
On Fri, 1 Dec 2017 18:02:52 +0100
Michael Niedermayer wrote:
> On Fri, Dec 01, 2017 at 10:01:42AM +0100, Nicolas George wrote:
> > Paul B Mahol (2017-11-30):
> > > +static int reset_links(AVFilterContext *filter)
> > > +{
> > > +int i, ret;
> > > +
> > > +if (!filter)
> > > +return 0;
> > > +
> > > +for (i = 0; i < filter->nb_outputs; i++) {
> > > +AVFilterLink *link = filter->outputs[i];
> > > +
> > > +link->init_state = AVLINK_UNINIT;
> > > +link->frame_rate.num = link->frame_rate.den = 0;
> > > +link->w = link->h = 0;
> > > +
> > > +ret = reset_links(link->dst);
> > > +if (ret < 0)
> > > +return ret;
> > > +}
> > > +
> > > +if (!i)
> > > +return avfilter_config_links(filter);
> > > +
> > > +return 0;
> > > +}
> >
> > Sorry, but no. All filters are currently written with the assumption
> > that config_props is called only once. Not all of them actually rely on
> > this assumption, but some do, and expect the fields of the private
> > context to be in their initial state. Violating that assumption would
> > result in a lot of memory leaks and probably a few crashes, some of them
> > security relevant.
> >
> > Plus, the public API of buffersink does not document params changes and
> > does not provide a good way of reacting to it, so enabling params
> > changes like that would have problematic results on applications that
> > expect frames with all the same size.
> >
> > (By the way, I am quite worried to see that Michael weakened the
> > protections for that last point in 5d859e59809.)
> >
>
> > Filters reconfiguration has been wanted for a lot of time. If it was
> > that simple, it would have been done already. If you want to implement
> > it, please go ahead, but it will not be an easy task.
>
> As the one who tried implementing changing frame parameters like
> dimension long time ago, the only real problem i encountered was
> bikeshedding, i dont rememer a technical problem. The bikeshedding in
> fact resolved itself but by the time i had lost interrest ...
>
> And in fact many filters should just be able to handle changing frame
> parameters as they are or with minimal changes.
Well, the result is that at least the vf_scale filter appears to
blatantly violate the API and crashes my software.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data
On Fri, Dec 01, 2017 at 10:01:42AM +0100, Nicolas George wrote:
> Paul B Mahol (2017-11-30):
> > +static int reset_links(AVFilterContext *filter)
> > +{
> > +int i, ret;
> > +
> > +if (!filter)
> > +return 0;
> > +
> > +for (i = 0; i < filter->nb_outputs; i++) {
> > +AVFilterLink *link = filter->outputs[i];
> > +
> > +link->init_state = AVLINK_UNINIT;
> > +link->frame_rate.num = link->frame_rate.den = 0;
> > +link->w = link->h = 0;
> > +
> > +ret = reset_links(link->dst);
> > +if (ret < 0)
> > +return ret;
> > +}
> > +
> > +if (!i)
> > +return avfilter_config_links(filter);
> > +
> > +return 0;
> > +}
>
> Sorry, but no. All filters are currently written with the assumption
> that config_props is called only once. Not all of them actually rely on
> this assumption, but some do, and expect the fields of the private
> context to be in their initial state. Violating that assumption would
> result in a lot of memory leaks and probably a few crashes, some of them
> security relevant.
>
> Plus, the public API of buffersink does not document params changes and
> does not provide a good way of reacting to it, so enabling params
> changes like that would have problematic results on applications that
> expect frames with all the same size.
>
> (By the way, I am quite worried to see that Michael weakened the
> protections for that last point in 5d859e59809.)
>
> Filters reconfiguration has been wanted for a lot of time. If it was
> that simple, it would have been done already. If you want to implement
> it, please go ahead, but it will not be an easy task.
As the one who tried implementing changing frame parameters like
dimension long time ago, the only real problem i encountered was
bikeshedding, i dont rememer a technical problem. The bikeshedding in
fact resolved itself but by the time i had lost interrest ...
And in fact many filters should just be able to handle changing frame
parameters as they are or with minimal changes.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Recent regression in VA-API compatibility (assertion in H.264 encode)
Hello, It looks like a recent patch causes VA-API H.264 encode to stop working and an assertion to be thrown. I ran a git bisect and narrowed it down to the following commit: 32a618a948c20f18db102d0b0976790222a57105 is the first bad commit commit 32a618a948c20f18db102d0b0976790222a57105 Author: Mark Thompson Date: Wed Oct 18 19:46:53 2017 +0100 vaapi_h264: Do not use deprecated header type SEI headers should be inserted as generic raw data (the old specific type has been deprecated in libva2). When run with the above patch, I get the following output: [h264_vaapi @ 0x37d0a20] Warning: some packed headers are not supported (want 0xd, got 0xb). [h264_vaapi @ 0x37d0a20] The encode compression level option is not supported with this VAAPI version. ffmpeg: i965_drv_video.c:352: va_enc_packed_type_to_idx: Assertion `0' failed. Here’s the vainfo output which provides the version info for the driver, va-api version, etc. This is on a Haswell system running Centos 7. libva info: VA-API version 0.34.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_34 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.34 (libva 1.2.1) vainfo: Driver version: Intel i965 driver - 1.2.2 I’m using the following command line for testing: ./ffmpeg -y -vaapi_device /dev/dri/card0 -i /home/devin/inputfile.ts -vf 'format=nv12,hwupload' -c:v h264_vaapi out.mp4 Any suggestions that could be offered would be greatly appreciated. Likewise please let me know if there is any other information I can provide that would assist in getting this resolved. Thanks, Devin Heitmueller ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/hevc_filter: support for all skip_loop_filter levels
On Thu, Nov 30, 2017 at 11:22:41PM +, Stefan _ wrote:
> Hi,
>
> Attached patch adds full support for skip_loop_filter (all levels) to
> the hevc decoder.
>
> I'm not too sure about the implementation of "nonref", since this email
> (http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176116.html)
> mentions looking at nal_unit_type and temporal_id instead. Some help
> would be appreciated.
>
> The 'make fate' test suite passed.
>
> doc/decoders.texi|7 ---
> libavcodec/hevc_filter.c | 12 +++-
> 2 files changed, 11 insertions(+), 8 deletions(-)
> 3d17844176bdd364e689212417b7857fe46fd3bb
> 0001-libavcodec-hevc_filter-support-for-all-skip_loop_fil.patch
> From 3e2f7152e3dab1f6cfe7c7e14f2ba1cee519978c Mon Sep 17 00:00:00 2001
> From: sfan5
> Date: Thu, 30 Nov 2017 23:58:02 +0100
> Subject: [PATCH] libavcodec/hevc_filter: support for all skip_loop_filter
> levels.
>
> Continues where commit 52c75d486ed5f75cbb79e5dbd07b7aef24f3071f left off.
> ---
> doc/decoders.texi| 7 ---
> libavcodec/hevc_filter.c | 12 +++-
> 2 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/doc/decoders.texi b/doc/decoders.texi
> index d149d2bea5..a9510bdf02 100644
> --- a/doc/decoders.texi
> +++ b/doc/decoders.texi
> @@ -25,13 +25,6 @@ enabled decoders.
> A description of some of the currently available video decoders
> follows.
>
> -@section hevc
> -
> -HEVC / H.265 decoder.
> -
> -Note: the @option{skip_loop_filter} option has effect only at level
> -@code{all}.
> -
> @section rawvideo
>
> Raw video decoder.
> diff --git a/libavcodec/hevc_filter.c b/libavcodec/hevc_filter.c
> index b53f4cc721..17ec59619f 100644
> --- a/libavcodec/hevc_filter.c
> +++ b/libavcodec/hevc_filter.c
> @@ -842,7 +842,17 @@ void ff_hevc_deblocking_boundary_strengths(HEVCContext
> *s, int x0, int y0,
> void ff_hevc_hls_filter(HEVCContext *s, int x, int y, int ctb_size)
> {
> int x_end = x >= s->ps.sps->width - ctb_size;
> -if (s->avctx->skip_loop_filter < AVDISCARD_ALL)
> +int deblock = 1;
> +if (s->avctx->skip_loop_filter >= AVDISCARD_ALL ||
> +(s->avctx->skip_loop_filter >= AVDISCARD_NONKEY && !IS_IDR(s)) ||
> +(s->avctx->skip_loop_filter >= AVDISCARD_NONINTRA &&
> + s->sh.slice_type != HEVC_SLICE_I) ||
> +(s->avctx->skip_loop_filter >= AVDISCARD_BIDIR &&
> + s->sh.slice_type == HEVC_SLICE_B) ||
> +(s->avctx->skip_loop_filter >= AVDISCARD_NONREF &&
> + ff_hevc_frame_nb_refs(s) == 0))
AVDISCARD_NONREF is about frames which are not referenced by any other
doesnt ff_hevc_frame_nb_refs() produce the number of references curently
aka the other end of the reference arrows ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] ffplay: use AV_PKT_FLAG_DISPOSABLE in frame drop logic
On 12/01/2017 08:25 AM, wm4 wrote:
> On Thu, 30 Nov 2017 16:27:01 -0800
> John Stebbins wrote:
>
>> ---
>> fftools/ffplay.c | 21 -
>> 1 file changed, 16 insertions(+), 5 deletions(-)
>>
>> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
>> index 10a917194d..152d220cdb 100644
>> --- a/fftools/ffplay.c
>> +++ b/fftools/ffplay.c
>> @@ -198,6 +198,8 @@ typedef struct Decoder {
>> int64_t next_pts;
>> AVRational next_pts_tb;
>> SDL_Thread *decoder_tid;
>> +int drop_disposable;
>> +int frame_drops_disposable;
>> } Decoder;
>>
>> typedef struct VideoState {
>> @@ -660,10 +662,16 @@ static int decoder_decode_frame(Decoder *d, AVFrame
>> *frame, AVSubtitle *sub) {
>> ret = got_frame ? 0 : (pkt.data ? AVERROR(EAGAIN) :
>> AVERROR_EOF);
>> }
>> } else {
>> -if (avcodec_send_packet(d->avctx, &pkt) == AVERROR(EAGAIN))
>> {
>> -av_log(d->avctx, AV_LOG_ERROR, "Receive_frame and
>> send_packet both returned EAGAIN, which is an API violation.\n");
>> -d->packet_pending = 1;
>> -av_packet_move_ref(&d->pkt, &pkt);
>> +if (d->avctx->codec_type == AVMEDIA_TYPE_VIDEO &&
>> +d->drop_disposable &&
>> +(pkt.flags & AV_PKT_FLAG_DISPOSABLE)) {
>> +d->frame_drops_disposable++;
>> +} else {
>> +if (avcodec_send_packet(d->avctx, &pkt) ==
>> AVERROR(EAGAIN)) {
>> +av_log(d->avctx, AV_LOG_ERROR, "Receive_frame and
>> send_packet both returned EAGAIN, which is an API violation.\n");
>> +d->packet_pending = 1;
>> +av_packet_move_ref(&d->pkt, &pkt);
>> +}
>> }
>> }
>> av_packet_unref(&pkt);
>> @@ -1622,6 +1630,7 @@ retry:
>> frame_queue_next(&is->pictq);
>> goto retry;
>> }
>> +is->viddec.drop_disposable = 0;
>> }
>>
>> if (is->subtitle_st) {
>> @@ -1699,7 +1708,8 @@ display:
>> get_master_clock(is),
>> (is->audio_st && is->video_st) ? "A-V" : (is->video_st ?
>> "M-V" : (is->audio_st ? "M-A" : " ")),
>> av_diff,
>> - is->frame_drops_early + is->frame_drops_late,
>> + is->frame_drops_early + is->frame_drops_late +
>> +
>> is->viddec.frame_drops_disposable,
>> aqsize / 1024,
>> vqsize / 1024,
>> sqsize,
>> @@ -1767,6 +1777,7 @@ static int get_video_frame(VideoState *is, AVFrame
>> *frame)
>> is->frame_drops_early++;
>> av_frame_unref(frame);
>> got_picture = 0;
>> +is->viddec.drop_disposable = 1;
>> }
>> }
>> }
> Why not just make libavcodec drop disposable frames?
>
libavcodec doesn't know anything about the current playback timeline. I.e. it
doesn't know if a frame is late.
--
John GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01 83F0 49F1 D7B2 60D4 D0F7
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] ffplay: use AV_PKT_FLAG_DISPOSABLE in frame drop logic
On Thu, 30 Nov 2017 16:27:01 -0800
John Stebbins wrote:
> ---
> fftools/ffplay.c | 21 -
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index 10a917194d..152d220cdb 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -198,6 +198,8 @@ typedef struct Decoder {
> int64_t next_pts;
> AVRational next_pts_tb;
> SDL_Thread *decoder_tid;
> +int drop_disposable;
> +int frame_drops_disposable;
> } Decoder;
>
> typedef struct VideoState {
> @@ -660,10 +662,16 @@ static int decoder_decode_frame(Decoder *d, AVFrame
> *frame, AVSubtitle *sub) {
> ret = got_frame ? 0 : (pkt.data ? AVERROR(EAGAIN) :
> AVERROR_EOF);
> }
> } else {
> -if (avcodec_send_packet(d->avctx, &pkt) == AVERROR(EAGAIN)) {
> -av_log(d->avctx, AV_LOG_ERROR, "Receive_frame and
> send_packet both returned EAGAIN, which is an API violation.\n");
> -d->packet_pending = 1;
> -av_packet_move_ref(&d->pkt, &pkt);
> +if (d->avctx->codec_type == AVMEDIA_TYPE_VIDEO &&
> +d->drop_disposable &&
> +(pkt.flags & AV_PKT_FLAG_DISPOSABLE)) {
> +d->frame_drops_disposable++;
> +} else {
> +if (avcodec_send_packet(d->avctx, &pkt) ==
> AVERROR(EAGAIN)) {
> +av_log(d->avctx, AV_LOG_ERROR, "Receive_frame and
> send_packet both returned EAGAIN, which is an API violation.\n");
> +d->packet_pending = 1;
> +av_packet_move_ref(&d->pkt, &pkt);
> +}
> }
> }
> av_packet_unref(&pkt);
> @@ -1622,6 +1630,7 @@ retry:
> frame_queue_next(&is->pictq);
> goto retry;
> }
> +is->viddec.drop_disposable = 0;
> }
>
> if (is->subtitle_st) {
> @@ -1699,7 +1708,8 @@ display:
> get_master_clock(is),
> (is->audio_st && is->video_st) ? "A-V" : (is->video_st ?
> "M-V" : (is->audio_st ? "M-A" : " ")),
> av_diff,
> - is->frame_drops_early + is->frame_drops_late,
> + is->frame_drops_early + is->frame_drops_late +
> + is->viddec.frame_drops_disposable,
> aqsize / 1024,
> vqsize / 1024,
> sqsize,
> @@ -1767,6 +1777,7 @@ static int get_video_frame(VideoState *is, AVFrame
> *frame)
> is->frame_drops_early++;
> av_frame_unref(frame);
> got_picture = 0;
> +is->viddec.drop_disposable = 1;
> }
> }
> }
Why not just make libavcodec drop disposable frames?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat: add NSP demuxer
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/nspdec.c | 101 +++
3 files changed, 103 insertions(+)
create mode 100644 libavformat/nspdec.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 4bffdf2205..734b703862 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -331,6 +331,7 @@ OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o
audiointerleave.o
OBJS-$(CONFIG_MXG_DEMUXER) += mxg.o
OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
+OBJS-$(CONFIG_NSP_DEMUXER) += nspdec.o
OBJS-$(CONFIG_NSV_DEMUXER) += nsvdec.o
OBJS-$(CONFIG_NULL_MUXER)+= nullenc.o
OBJS-$(CONFIG_NUT_DEMUXER) += nutdec.o nut.o isom.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 9213af9301..6a9b9883c9 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -224,6 +224,7 @@ static void register_all(void)
REGISTER_DEMUXER (MXG, mxg);
REGISTER_DEMUXER (NC, nc);
REGISTER_DEMUXER (NISTSPHERE, nistsphere);
+REGISTER_DEMUXER (NSP, nsp);
REGISTER_DEMUXER (NSV, nsv);
REGISTER_MUXER (NULL, null);
REGISTER_MUXDEMUX(NUT, nut);
diff --git a/libavformat/nspdec.c b/libavformat/nspdec.c
new file mode 100644
index 00..d2ff779732
--- /dev/null
+++ b/libavformat/nspdec.c
@@ -0,0 +1,101 @@
+/*
+ * NSP demuxer
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/intreadwrite.h"
+#include "avformat.h"
+#include "internal.h"
+#include "pcm.h"
+
+static int nsp_probe(AVProbeData *p)
+{
+if (AV_RB32(p->buf) == AV_RB32("FORM") &&
+AV_RB32(p->buf + 4) == AV_RB32("DS16"))
+return AVPROBE_SCORE_MAX;
+return 0;
+}
+
+static int nsp_read_header(AVFormatContext *s)
+{
+int rate = 0, channels = 0;
+uint32_t chunk, size;
+AVStream *st;
+int64_t pos;
+
+avio_skip(s->pb, 12);
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+while (!avio_feof(s->pb)) {
+chunk = avio_rb32(s->pb);
+size = avio_rl32(s->pb);
+pos = avio_tell(s->pb);
+
+if (chunk == MKBETAG('H', 'D', 'R', '8') ||
+chunk == MKBETAG('H', 'E', 'D', 'R')) {
+if (size < 32)
+return AVERROR_INVALIDDATA;
+avio_skip(s->pb, 20);
+rate = avio_rl32(s->pb);
+avio_skip(s->pb, size - (avio_tell(s->pb) - pos));
+} else if (chunk == MKBETAG('N', 'O', 'T', 'E')) {
+char value[1024];
+
+avio_get_str(s->pb, size, value, sizeof(value));
+av_dict_set(&s->metadata, "Note", value, 0);
+avio_skip(s->pb, 1);
+} else if (chunk == MKBETAG('S', 'D', 'A', 'B')) {
+channels = 2;
+break;
+} else if (chunk == MKBETAG('S', 'D', 'A', '_') ||
+ chunk == MKBETAG('S', 'D', '_', 'A') ||
+ chunk == MKBETAG('S', 'D', '_', '2') ||
+ chunk == MKBETAG('S', 'D', '_', '3') ||
+ chunk == MKBETAG('S', 'D', '_', '4') ||
+ chunk == MKBETAG('S', 'D', '_', '5') ||
+ chunk == MKBETAG('S', 'D', '_', '6') ||
+ chunk == MKBETAG('S', 'D', '_', '7') ||
+ chunk == MKBETAG('S', 'D', '_', '8')) {
+channels = 1;
+break;
+}
+}
+
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+st->codecpar->channels = channels;
+st->codecpar->sample_rate = rate;
+st->codecpar->codec_id = AV_CODEC_ID_PCM_S16LE;
+st->codecpar->block_align = 2 * channels;
+
+return 0;
+}
+
+AVInputFormat ff_nsp_demuxer = {
+.name = "nsp",
+.long_name = NULL_IF_CONFIG_SMALL("Computerized Speech Lab NSP"),
+.read_probe = nsp_probe,
+.read_header= nsp_read_header,
+.read_packet= ff_pcm_read_packet,
+.read_seek
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data
On Fri, 1 Dec 2017 10:35:34 +0100
Paul B Mahol wrote:
> On 12/1/17, Nicolas George wrote:
> > Paul B Mahol (2017-11-30):
> >> +static int reset_links(AVFilterContext *filter)
> >> +{
> >> +int i, ret;
> >> +
> >> +if (!filter)
> >> +return 0;
> >> +
> >> +for (i = 0; i < filter->nb_outputs; i++) {
> >> +AVFilterLink *link = filter->outputs[i];
> >> +
> >> +link->init_state = AVLINK_UNINIT;
> >> +link->frame_rate.num = link->frame_rate.den = 0;
> >> +link->w = link->h = 0;
> >> +
> >> +ret = reset_links(link->dst);
> >> +if (ret < 0)
> >> +return ret;
> >> +}
> >> +
> >> +if (!i)
> >> +return avfilter_config_links(filter);
> >> +
> >> +return 0;
> >> +}
> >
> > Sorry, but no. All filters are currently written with the assumption
> > that config_props is called only once. Not all of them actually rely on
> > this assumption, but some do, and expect the fields of the private
> > context to be in their initial state. Violating that assumption would
> > result in a lot of memory leaks and probably a few crashes, some of them
> > security relevant.
>
> Not all filters are written with such assumption. And I would like to fix
> those
> who rely on this assumption.
SGTM
> >
> > Plus, the public API of buffersink does not document params changes and
> > does not provide a good way of reacting to it, so enabling params
> > changes like that would have problematic results on applications that
> > expect frames with all the same size.
>
> Well for that point one can always autoinsert scale filter if user does
> not set some flag when calling buffersink function.
Also SGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [vorbis] Fix another 1 << 31 > int32_t::max() with 1u.
On Thu, Nov 30, 2017 at 12:22:46PM -0800, Dale Curtis wrote: > Didn't notice this one when 9648cc6d was landed. > > Signed-off-by: Dale Curtis > vorbis.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > c86adca961a08a6f7cd4a8233d0cef4b971073d8 fix_vorbis_v1.patch > From 2f7c0ee007cb28b8f3bf201279d7f17ca671728d Mon Sep 17 00:00:00 2001 > From: Dale Curtis > Date: Thu, 30 Nov 2017 12:20:36 -0800 > Subject: [PATCH] [vorbis] Fix another 1 << 31 > int32_t::max() with 1u. > > Didn't notice this one when 9648cc6d was landed. will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hls: fix baseurl missing last char
2017-12-01 18:06 GMT+08:00 Robert Nagy :
> ---
> libavformat/hlsenc.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index cdfbf45823..dc8bf48791 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1921,14 +1921,11 @@ static int hls_write_header(AVFormatContext *s)
> }
>
> if (hls->baseurl) {
> -int baseurl_len;
> -baseurl_len = strlen(hls->baseurl);
> -vs->baseurl = av_malloc(baseurl_len);
> +vs->baseurl = av_strdup(hls->baseurl);
> if (!vs->baseurl) {
> ret = AVERROR(ENOMEM);
> goto fail;
> }
> -av_strlcpy(vs->baseurl, hls->baseurl, baseurl_len);
> }
>
> if ((hls->flags & HLS_SINGLE_FILE) && (hls->segment_type ==
> SEGMENT_TYPE_FMP4)) {
> --
> 2.15.0
LGTM
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hls: fix baseurl missing last char
---
libavformat/hlsenc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index cdfbf45823..dc8bf48791 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1921,14 +1921,11 @@ static int hls_write_header(AVFormatContext *s)
}
if (hls->baseurl) {
-int baseurl_len;
-baseurl_len = strlen(hls->baseurl);
-vs->baseurl = av_malloc(baseurl_len);
+vs->baseurl = av_strdup(hls->baseurl);
if (!vs->baseurl) {
ret = AVERROR(ENOMEM);
goto fail;
}
-av_strlcpy(vs->baseurl, hls->baseurl, baseurl_len);
}
if ((hls->flags & HLS_SINGLE_FILE) && (hls->segment_type ==
SEGMENT_TYPE_FMP4)) {
--
2.15.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data
On 12/1/17, Nicolas George wrote:
> Paul B Mahol (2017-11-30):
>> +static int reset_links(AVFilterContext *filter)
>> +{
>> +int i, ret;
>> +
>> +if (!filter)
>> +return 0;
>> +
>> +for (i = 0; i < filter->nb_outputs; i++) {
>> +AVFilterLink *link = filter->outputs[i];
>> +
>> +link->init_state = AVLINK_UNINIT;
>> +link->frame_rate.num = link->frame_rate.den = 0;
>> +link->w = link->h = 0;
>> +
>> +ret = reset_links(link->dst);
>> +if (ret < 0)
>> +return ret;
>> +}
>> +
>> +if (!i)
>> +return avfilter_config_links(filter);
>> +
>> +return 0;
>> +}
>
> Sorry, but no. All filters are currently written with the assumption
> that config_props is called only once. Not all of them actually rely on
> this assumption, but some do, and expect the fields of the private
> context to be in their initial state. Violating that assumption would
> result in a lot of memory leaks and probably a few crashes, some of them
> security relevant.
Not all filters are written with such assumption. And I would like to fix those
who rely on this assumption.
>
> Plus, the public API of buffersink does not document params changes and
> does not provide a good way of reacting to it, so enabling params
> changes like that would have problematic results on applications that
> expect frames with all the same size.
Well for that point one can always autoinsert scale filter if user does
not set some flag when calling buffersink function.
>
> (By the way, I am quite worried to see that Michael weakened the
> protections for that last point in 5d859e59809.)
>
> Filters reconfiguration has been wanted for a lot of time. If it was
> that simple, it would have been done already. If you want to implement
> it, please go ahead, but it will not be an easy task.
I would like to proceed but I can't guess what is in your mind.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_tile: add init_padding option
Paul B Mahol (2017-11-30): > I like nano-optimizations! If it makes the code negligibly faster at the cost of making it more complex, it is a nano-optimization. In this case, since it makes the code both simpler and faster, it is just better coding. > Should I commit with that changed or send another one for review? Go ahead. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V2] lavc/qsvenc: set HRD buffer size
Hypothetical Reference Decoding (HRD) model assumes that data flows into a buffer of the fixed size BufferSizeInKB with a constant bitrate. Smaller BufferSizeInKB means smaller frame size variations, but more difficult to maintain HRD. Signed-off-by: Zhong Li --- libavcodec/qsvenc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index 57f78c4..96c8fb5 100644 --- a/libavcodec/qsvenc.c +++ b/libavcodec/qsvenc.c @@ -495,6 +495,7 @@ static int init_video_param(AVCodecContext *avctx, QSVEncContext *q) #if QSV_HAVE_VCM case MFX_RATECONTROL_VCM: #endif +q->param.mfx.BufferSizeInKB = avctx->rc_buffer_size / 8000; q->param.mfx.InitialDelayInKB = avctx->rc_initial_buffer_occupancy / 1000; q->param.mfx.TargetKbps = avctx->bit_rate / 1000; q->param.mfx.MaxKbps = avctx->rc_max_rate / 1000; -- 1.8.3.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data
Paul B Mahol (2017-11-30):
> +static int reset_links(AVFilterContext *filter)
> +{
> +int i, ret;
> +
> +if (!filter)
> +return 0;
> +
> +for (i = 0; i < filter->nb_outputs; i++) {
> +AVFilterLink *link = filter->outputs[i];
> +
> +link->init_state = AVLINK_UNINIT;
> +link->frame_rate.num = link->frame_rate.den = 0;
> +link->w = link->h = 0;
> +
> +ret = reset_links(link->dst);
> +if (ret < 0)
> +return ret;
> +}
> +
> +if (!i)
> +return avfilter_config_links(filter);
> +
> +return 0;
> +}
Sorry, but no. All filters are currently written with the assumption
that config_props is called only once. Not all of them actually rely on
this assumption, but some do, and expect the fields of the private
context to be in their initial state. Violating that assumption would
result in a lot of memory leaks and probably a few crashes, some of them
security relevant.
Plus, the public API of buffersink does not document params changes and
does not provide a good way of reacting to it, so enabling params
changes like that would have problematic results on applications that
expect frames with all the same size.
(By the way, I am quite worried to see that Michael weakened the
protections for that last point in 5d859e59809.)
Filters reconfiguration has been wanted for a lot of time. If it was
that simple, it would have been done already. If you want to implement
it, please go ahead, but it will not be an easy task.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avutil/reverse: make ff_reverse shared
On Fri, Dec 1, 2017 at 9:42 AM, Nicolas George wrote: > James Almer (2017-11-30): >> Signed-off-by: James Almer >> --- >> Pros: >> Removes duplicate arrays and ugly c file including c files >> >> Cons: >> Makes the array in libavutil effectively part of the ABI. >> Might not be worth doing for 256 bytes >> >> >> Something like this was probably sent before, so i guess it >> will be rejected again. > > I think it is worse than that: the opposite was done on purpose. > > I believe the rationale was that shared data object do not work > correctly with shared libraries on windows. > That problem was fixed recently. But in any case, this creates a lot of noise for very marginal gains, not sure its really worth it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avutil/reverse: make ff_reverse shared
James Almer (2017-11-30): > Signed-off-by: James Almer > --- > Pros: > Removes duplicate arrays and ugly c file including c files > > Cons: > Makes the array in libavutil effectively part of the ABI. > Might not be worth doing for 256 bytes > > > Something like this was probably sent before, so i guess it > will be rejected again. I think it is worse than that: the opposite was done on purpose. I believe the rationale was that shared data object do not work correctly with shared libraries on windows. IMHO, it is yet another argument for merging the libraries. (And to drop windows support. Only kidding.) Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AMD external header
On 01.12.2017 00:32, Marton Balint wrote: On Wed, 29 Nov 2017, Mironov, Mikhail wrote: Hi, This conversation is very entertaining but leads us nowhere. May I suggest to go down to business of enabling HW encoders by default? Yesterday Mark submitted the initial implementation and I really want to thank him for his mentoring and participation - it was very useful. The submission doesn't have AMD header so AMD encoder is off in any default build. I counted responses to my posts and found six people are for the default enabling of HW blocks one way or another: by including headers or pulling them out automatically using git (I guess via submodules?). Two people want to remove external headers and disable default HW acceleration. Question is: how to move forward on practical terms? I really don’t know how this team makes such decisions. Or maybe it is impasse case and all want to keep things the way they are today? The project has a voting system which was used in the past for issues where no consensus was reached. A voting however is a tedious process which usually leaves a few frustrated people on the losing side, so I'd say that is a last resort. +1 An alternative solution to adding AMD or removing Nvidia headers might be to simply disable the Nvidia hwaccel autodetection, and require the user to explicitly enable it. That seems mostly fair to me, and keeps the current status of the headers. Still some decision about these external headers should be made but the outcome would have less impact on user experience. What is the current policy for adding a library on the HWACCEL_AUTODETECT_LIBRARY_LIST versus putting it on HWACCEL_LIBRARY_LIST? Is it different from EXTERNAL_AUTODETECT_LIBRARY_LIST / EXTERNAL_LIBRARY_LIST? Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
