[FFmpeg-devel] [PATCH] libavcodec/vp9: fix ref-frame size judging method
From: Yan Cen
There is no need all reference frame demension is valid in libvpx.
So this change contains three part:
1. Change each judgement's loglevel from "ERROR" to "WARNING"
2. Make sure at least one of frames that this frame references has valid
dimension.
3. All judgements fail would report "ERROR".
Signed-off-by: Yan Cen
---
libavcodec/vp9.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index acf3ffc..8dd14e0 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -790,6 +790,7 @@ static int decode_frame_header(AVCodecContext *avctx,
/* check reference frames */
if (!s->s.h.keyframe && !s->s.h.intraonly) {
+int has_valid_ref_frame = 0;
for (i = 0; i < 3; i++) {
AVFrame *ref = s->s.refs[s->s.h.refidx[i]].f;
int refw = ref->width, refh = ref->height;
@@ -802,12 +803,14 @@ static int decode_frame_header(AVCodecContext *avctx,
return AVERROR_INVALIDDATA;
} else if (refw == w && refh == h) {
s->mvscale[i][0] = s->mvscale[i][1] = 0;
+has_valid_ref_frame = 1;
} else {
-if (w * 2 < refw || h * 2 < refh || w > 16 * refw || h > 16 *
refh) {
-av_log(avctx, AV_LOG_ERROR,
+int is_ref_frame_invalid = (w * 2 < refw || h * 2 < refh || w
> 16 * refw || h > 16 * refh);
+has_valid_ref_frame |= !is_ref_frame_invalid;
+if (is_ref_frame_invalid) {
+av_log(avctx, AV_LOG_WARNING,
"Invalid ref frame dimensions %dx%d for frame size
%dx%d\n",
refw, refh, w, h);
-return AVERROR_INVALIDDATA;
}
s->mvscale[i][0] = (refw << 14) / w;
s->mvscale[i][1] = (refh << 14) / h;
@@ -815,6 +818,11 @@ static int decode_frame_header(AVCodecContext *avctx,
s->mvstep[i][1] = 16 * s->mvscale[i][1] >> 14;
}
}
+if (!has_valid_ref_frame) {
+av_log(avctx, AV_LOG_ERROR,
+ "Referenced frame has invalid size\n");
+return AVERROR_INVALIDDATA;
+}
}
if (s->s.h.keyframe || s->s.h.errorres || (s->s.h.intraonly &&
s->s.h.resetctx == 3)) {
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data type support for dnn model input
Em seg, 29 de abr de 2019 às 22:21, Guo, Yejun escreveu: > > > > > -Original Message- > > From: Pedro Arthur [mailto:bygran...@gmail.com] > > Sent: Tuesday, April 30, 2019 1:47 AM > > To: FFmpeg development discussions and patches > > Cc: Guo, Yejun > > Subject: Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data > > type > > support for dnn model input > > > > Em qua, 24 de abr de 2019 às 23:15, Guo, Yejun > > escreveu: > > > > > > currently, only float is supported as model input, actually, there > > > are other data types, this patch adds uint8. > > > > > > Signed-off-by: Guo, Yejun > > > > > > LGTM. > > > > I think it would be valuable to add a few tests covering the features > > added by this patch series. > > thanks, good point. Do you mean FATE? Is there any previous test for DNN > module that I can refer to? thanks. I'll investigate it after my holiday, I'm > starting vacation today. Yes, I mean FATE, unfortunately there isn't any tests for DNN atm. Have a nice vacation! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data type support for dnn model input
> -Original Message- > From: Pedro Arthur [mailto:bygran...@gmail.com] > Sent: Tuesday, April 30, 2019 1:47 AM > To: FFmpeg development discussions and patches > Cc: Guo, Yejun > Subject: Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data type > support for dnn model input > > Em qua, 24 de abr de 2019 às 23:15, Guo, Yejun > escreveu: > > > > currently, only float is supported as model input, actually, there > > are other data types, this patch adds uint8. > > > > Signed-off-by: Guo, Yejun > > > LGTM. > > I think it would be valuable to add a few tests covering the features > added by this patch series. thanks, good point. Do you mean FATE? Is there any previous test for DNN module that I can refer to? thanks. I'll investigate it after my holiday, I'm starting vacation today. > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/h263dec: Fixed VA API, VDPAU, and VideoToolbox hardware acceleration due to missing `hw_configs` property.
On Mon, Apr 29, 2019 at 02:16:53PM -0700, fumoboy...@me.com wrote:
> Btw, what’s the difference between `h263` and `h263p`?
Its described probably best with the encoders:
.name = "h263p",
.long_name = NULL_IF_CONFIG_SMALL("H.263+ / H.263-1998 / H.263 version
2"),
vs.
.name = "h263",
.long_name = NULL_IF_CONFIG_SMALL("H.263 / H.263-1996"),
[...]
--
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: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in FFmpeg dnn native mode.
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Pedro Arthur > Sent: Monday, April 29, 2019 11:26 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports > in > FFmpeg dnn native mode. > > Em seg, 29 de abr de 2019 às 00:06, escreveu: > > > > > > > > > > > -原始邮件- > > > 发件人: "Pedro Arthur" > > > 发送时间: 2019-04-29 10:42:42 (星期一) > > > 收件人: "FFmpeg development discussions and patches" > > > > 抄送: > > > 主题: Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports > in FFmpeg dnn native mode. > > > > > > I think for training these filters the preferred method is VALID as it > > > uses only the data available (without filling the borders) and gives > > > the best possible result. > > > However for inference usually one expects to output an image with the > > > same size of the original (imagine the case of chained filters where > > > each one reduces the image by a few pixels, in the end one may have a > > > useless output). > > > Therefore it makes perfect sense to use different padding methods for > > > training/inference. > > > > > > The clamp_to_edge padding was introduced before the TF backend thus it > > > stayed in the native backend even after the introduction of the TF > > > backend. > > > Indeed the clamp_to_edge is simpler than the other padding methods and > > > also gives a slight better result, If I remember correct the student > > > which implemented the TF backend did not find an equivalent padding > > > method in TF, thats why it uses different paddings. > > > > > Yes, I think clamp_to_edge is a good method to keep the output with the > same size as input. However, I don't think "VALID" is the best method giving > best possible result. So, for "VALID" mode, maybe we can use the > clamp_to_edge method in the current dnn native mode? And then, we should > also add "SAME" option to support other filters. @xwmeng, We now can support 3 padding options for conv layer. - valid: the same definition as TF model. (the size of feature map changed). - same: the same definition as TF model. (zero filled for outside pixels). - same_clamp_to_edge: just like 'same' option, but edge filled for outside pixels. So we don't need change SR code for the padding. > > > > I think it is best to not make any assumptions like VALID => > clamp_to_edge, but you can keep it for now. > Ideally the model should have a padding layer which the backend > properly implements. Currently the TF backend when reading a native > model adds this padding layer implicitly, therefore it would be a > matter of changing it to have an explicity padding layer in the model. > > Maybe you can assume VALID => clamp_to_edge, so you can add what you > need without changing the SR code and later you implement the > explicity padding support and send a PR to the original repo > (https://github.com/HighVoltageRocknRoll/sr) properly modifying the > model. yes, the ideal solution to make native SR model the same as TF model, is to: - add explicit padding layer in SR native model. (the padding layer is explicitly added in TF model) - export 'valid' option for conv layer in SR native model. (the TF model uses 'valid' option) - add padding layer execution support in native mode. - add padding option support in conv layer in native mode. And, we can first keep most of SR code unchanged, by adding 'same_clamp_to_edge' option in conv layer in native mode. This can be our current choice. And the ideal solution can be our next choice, just as you mentioned. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/pafvideo: Check input space for decode_0() before slow operations
Fixes: Timeout (11sec -> 2sec) Fixes: 14403/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PAF_VIDEO_fuzzer-5697465698746368 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/pafvideo.c | 4 1 file changed, 4 insertions(+) diff --git a/libavcodec/pafvideo.c b/libavcodec/pafvideo.c index 7c5861dfaf..7bfd6815df 100644 --- a/libavcodec/pafvideo.c +++ b/libavcodec/pafvideo.c @@ -285,6 +285,10 @@ static int paf_video_decode(AVCodecContext *avctx, void *data, return AVERROR_INVALIDDATA; } +if ((code & 0xF) == 0 && +c->video_size / 32 - (int64_t)bytestream2_get_bytes_left(>gb) > c->video_size / 32 * (int64_t)avctx->discard_damaged_percentage / 100) +return AVERROR_INVALIDDATA; + if ((ret = ff_reget_buffer(avctx, c->pic)) < 0) return ret; -- 2.21.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/mov: Populate packet duration using `stts` atom instead of guessing.
Fixes #7855 (“Last subtitle in MP4 is displayed forever”).
---
libavformat/isom.h | 3 +
libavformat/mov.c | 158 +
2 files changed, 135 insertions(+), 26 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 69452cae8e..b83744ba09 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -162,6 +162,7 @@ typedef struct MOVStreamContext {
unsigned int chunk_count;
int64_t *chunk_offsets;
unsigned int stts_count;
+unsigned int stts_allocated_size;
MOVStts *stts_data;
unsigned int ctts_count;
unsigned int ctts_allocated_size;
@@ -174,6 +175,8 @@ typedef struct MOVStreamContext {
unsigned *stps_data; ///< partial sync sample for mpeg-2 open gop
MOVElst *elst_data;
unsigned int elst_count;
+int stts_index;
+int stts_sample;
int ctts_index;
int ctts_sample;
unsigned int sample_size; ///< may contain value calculated from stsd or
value from stsz atom
diff --git a/libavformat/mov.c b/libavformat/mov.c
index d0347b2970..3d5f5f7ab0 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2886,7 +2886,7 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
{
AVStream *st;
MOVStreamContext *sc;
-unsigned int i, entries, alloc_size = 0;
+unsigned int i, entries = 0;
int64_t duration=0;
int64_t total_sample_count=0;
@@ -2913,7 +2913,7 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
int sample_duration;
unsigned int sample_count;
unsigned int min_entries = FFMIN(FFMAX(i + 1, 1024 * 1024), entries);
-MOVStts *stts_data = av_fast_realloc(sc->stts_data, _size,
+MOVStts *stts_data = av_fast_realloc(sc->stts_data,
>stts_allocated_size,
min_entries *
sizeof(*sc->stts_data));
if (!stts_data) {
av_freep(>stts_data);
@@ -3130,11 +3130,15 @@ static int get_edit_list_entry(MOVContext *mov,
static int find_prev_closest_index(AVStream *st,
AVIndexEntry *e_old,
int nb_old,
+ MOVStts* stts_data,
+ int64_t stts_count,
MOVStts* ctts_data,
int64_t ctts_count,
int64_t timestamp_pts,
int flag,
int64_t* index,
+ int64_t* stts_index,
+ int64_t* stts_sample,
int64_t* ctts_index,
int64_t* ctts_sample)
{
@@ -3176,6 +3180,15 @@ static int find_prev_closest_index(AVStream *st,
// Find out the ctts_index for the found frame.
*ctts_index = 0;
*ctts_sample = 0;
+
+if (stts_data) {
+av_assert0(stts_index);
+av_assert0(stts_sample);
+
+*stts_index = 0;
+*stts_sample = 0;
+}
+
for (index_ctts_count = 0; index_ctts_count < *index;
index_ctts_count++) {
if (*ctts_index < ctts_count) {
(*ctts_sample)++;
@@ -3184,6 +3197,13 @@ static int find_prev_closest_index(AVStream *st,
*ctts_sample = 0;
}
}
+if (stts_data && *stts_index < stts_count) {
+(*stts_sample)++;
+if (*stts_sample == stts_data[*stts_index].count) {
+(*stts_index)++;
+*stts_sample = 0;
+}
+}
}
while (*index >= 0 && (*ctts_index) >= 0 && (*ctts_index) <
ctts_count) {
@@ -3203,6 +3223,16 @@ static int find_prev_closest_index(AVStream *st,
} else {
(*ctts_sample)--;
}
+if (stts_data) {
+if (*stts_sample == 0) {
+(*stts_index)--;
+if (*stts_index >= 0) {
+*stts_sample = stts_data[*stts_index].count - 1;
+}
+} else {
+(*stts_sample)--;
+}
+}
}
}
@@ -3275,34 +3305,44 @@ static void fix_index_entry_timestamps(AVStream* st,
int end_index, int64_t end_
}
/**
- * Append a new ctts entry to ctts_data.
- * Returns the new ctts_count if successful, else returns -1.
+ * Append a new stts entry to stts_data.
+ * Returns the new stts_count if successful, else returns -1.
*/
-static int64_t add_ctts_entry(MOVStts** ctts_data, unsigned int* ctts_count,
unsigned int* allocated_size,
+static int64_t add_stts_entry(MOVStts** stts_data, unsigned int* stts_count,
unsigned int* allocated_size,
int count, int duration)
{
-MOVStts *ctts_buf_new;
-
[FFmpeg-devel] [PATCH] avcodec/decode: Do not output subtitle frames if the packet is marked with `AV_PKT_FLAG_DISCARD`.
One situation where a subtitle packet can be marked for discard is when
demuxing an MOV file that has an edit list.
---
libavcodec/decode.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 6c31166ec2..204bd50fa3 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1149,8 +1149,14 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx,
AVSubtitle *sub,
}
}
-if (*got_sub_ptr)
-avctx->frame_number++;
+if (*got_sub_ptr) {
+if (avpkt->flags & AV_PKT_FLAG_DISCARD) {
+*got_sub_ptr = 0;
+avsubtitle_free(sub);
+} else {
+avctx->frame_number++;
+}
+}
}
return ret;
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/h263dec: Fixed VA API, VDPAU, and VideoToolbox hardware acceleration due to missing `hw_configs` property.
Btw, what’s the difference between `h263` and `h263p`?
> On Apr 29, 2019, at 2:12 PM, fumoboy007 wrote:
>
> Bug originally introduced in commit 758fbc54fef2f31957b5c5f22e05e5fd9b04f631.
> ---
> libavcodec/h263dec.c | 27 +++
> 1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
> index 8385ddfe2e..6f001f6d47 100644
> --- a/libavcodec/h263dec.c
> +++ b/libavcodec/h263dec.c
> @@ -743,6 +743,19 @@ const enum AVPixelFormat
> ff_h263_hwaccel_pixfmt_list_420[] = {
> AV_PIX_FMT_NONE
> };
>
> +const AVCodecHWConfigInternal *ff_h263_hw_config_list[] = {
> +#if CONFIG_H263_VAAPI_HWACCEL
> +HWACCEL_VAAPI(h263),
> +#endif
> +#if CONFIG_MPEG4_VDPAU_HWACCEL
> +HWACCEL_VDPAU(mpeg4),
> +#endif
> +#if CONFIG_H263_VIDEOTOOLBOX_HWACCEL
> +HWACCEL_VIDEOTOOLBOX(h263),
> +#endif
> +NULL
> +};
> +
> AVCodec ff_h263_decoder = {
> .name = "h263",
> .long_name = NULL_IF_CONFIG_SMALL("H.263 / H.263-1996, H.263+ /
> H.263-1998 / H.263 version 2"),
> @@ -758,6 +771,7 @@ AVCodec ff_h263_decoder = {
> .flush = ff_mpeg_flush,
> .max_lowres = 3,
> .pix_fmts = ff_h263_hwaccel_pixfmt_list_420,
> +.hw_configs = ff_h263_hw_config_list,
> };
>
> AVCodec ff_h263p_decoder = {
> @@ -775,16 +789,5 @@ AVCodec ff_h263p_decoder = {
> .flush = ff_mpeg_flush,
> .max_lowres = 3,
> .pix_fmts = ff_h263_hwaccel_pixfmt_list_420,
> -.hw_configs = (const AVCodecHWConfigInternal*[]) {
> -#if CONFIG_H263_VAAPI_HWACCEL
> -HWACCEL_VAAPI(h263),
> -#endif
> -#if CONFIG_MPEG4_VDPAU_HWACCEL
> -HWACCEL_VDPAU(mpeg4),
> -#endif
> -#if CONFIG_H263_VIDEOTOOLBOX_HWACCEL
> -HWACCEL_VIDEOTOOLBOX(h263),
> -#endif
> -NULL
> -},
> +.hw_configs = ff_h263_hw_config_list,
> };
> --
> 2.21.0
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/h263dec: Fixed VA API, VDPAU, and VideoToolbox hardware acceleration due to missing `hw_configs` property.
Bug originally introduced in commit 758fbc54fef2f31957b5c5f22e05e5fd9b04f631.
---
libavcodec/h263dec.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 8385ddfe2e..6f001f6d47 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -743,6 +743,19 @@ const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[]
= {
AV_PIX_FMT_NONE
};
+const AVCodecHWConfigInternal *ff_h263_hw_config_list[] = {
+#if CONFIG_H263_VAAPI_HWACCEL
+HWACCEL_VAAPI(h263),
+#endif
+#if CONFIG_MPEG4_VDPAU_HWACCEL
+HWACCEL_VDPAU(mpeg4),
+#endif
+#if CONFIG_H263_VIDEOTOOLBOX_HWACCEL
+HWACCEL_VIDEOTOOLBOX(h263),
+#endif
+NULL
+};
+
AVCodec ff_h263_decoder = {
.name = "h263",
.long_name = NULL_IF_CONFIG_SMALL("H.263 / H.263-1996, H.263+ /
H.263-1998 / H.263 version 2"),
@@ -758,6 +771,7 @@ AVCodec ff_h263_decoder = {
.flush = ff_mpeg_flush,
.max_lowres = 3,
.pix_fmts = ff_h263_hwaccel_pixfmt_list_420,
+.hw_configs = ff_h263_hw_config_list,
};
AVCodec ff_h263p_decoder = {
@@ -775,16 +789,5 @@ AVCodec ff_h263p_decoder = {
.flush = ff_mpeg_flush,
.max_lowres = 3,
.pix_fmts = ff_h263_hwaccel_pixfmt_list_420,
-.hw_configs = (const AVCodecHWConfigInternal*[]) {
-#if CONFIG_H263_VAAPI_HWACCEL
-HWACCEL_VAAPI(h263),
-#endif
-#if CONFIG_MPEG4_VDPAU_HWACCEL
-HWACCEL_VDPAU(mpeg4),
-#endif
-#if CONFIG_H263_VIDEOTOOLBOX_HWACCEL
-HWACCEL_VIDEOTOOLBOX(h263),
-#endif
-NULL
-},
+.hw_configs = ff_h263_hw_config_list,
};
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavfilter/f_select: response file support
Ping! :-) Thanks, Jonathan Gilbert On Wed, Apr 17, 2019 at 4:18 AM Jonathan Gilbert wrote: > I've changed the allocation functions and attached the output of `git > format-patch` to this e-mail. > > Thanks, > > Jonathan Gilbert > > On Tue, Apr 16, 2019 at 5:50 PM Carl Eugen Hoyos > wrote: > >> 2019-04-16 19:14 GMT+02:00, Jonathan Gilbert : >> > Hello :-) >> > >> > I had a project recently where I wanted to externally specify a list >> > of specific frame numbers to drop. I understand this can be done with >> > select expressions like "not(eq(n,45)+eq(n,47)+eq(n,75))", but in my >> > case I wanted to drop nearly 16,000 frames, which would have required >> > a command-line over 250 KB in size. I chose a different approach: I >> > have added functionality to f_select.c so that you can specify the >> > list of frames you want to include/exclude in an external response >> > file. I have successfully used this code for my project, and thought I >> > might submit it up to for consideration. :-) >> > >> > I've never submitted a patch in this format before, I hope I'm doing >> > this correctly. >> >> This is definitely not the only issue: >> Instead of using malloc() and friends, please see libavutil/mem.h >> for the appropriate functions. >> >> Carl Eugen >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Mon, Apr 29, 2019 at 8:35 PM Marton Balint wrote: > We can't really change this for the better unless there is a somewhat > "recognized" authority which has the power to make decisions, rules, and > enforce them. > > I hoped that this can be the voting comitte. The voting commitee is pretty much everyone, and as such way too many people. I would've preferred a small "steering board" of maybe 5 people or whatever you like to call it, but in the meeting this was decided in, a vote choose otherwise... :) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
2019-04-29 20:34 GMT+02:00, Marton Balint : > Voting is important, because people typically accept > majority decisions even if they don't agree with them. Sounds like an interesting argument. > I believe that this is why several people including > me expressed that NDI removal should only have > happened after a vote. This still sounds to me as if you believe there would have been an alternative to removing the library. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Marton Balint (12019-04-29): > At the moment, it looks to me that FFmpeg is a community without leadership, > enforced rules and consequences. In fact, I consider this the main reason > why people consider working in it an unfriendly experience. > > We can't really change this for the better unless there is a somewhat > "recognized" authority which has the power to make decisions, rules, and > enforce them. I fully agree with that analysis. > I hoped that this can be the voting comitte. But not that point: the voting committee is too large to ac as an executive body. It cannot act efficiently on small decisions. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote: 2019-04-29 1:02 GMT+02:00, Marton Balint : On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote: 2019-04-28 22:02 GMT+02:00, Marton Balint : 1) Should libNDI support be removed from the ffmpeg codebase? This sounds to me as if you know of an alternative to not endorsing a company that profits from FFmpeg while at the same time violating the copyright of the FFmpeg developers? What could this alternative be? We could list them on our webpage hall of shame, or whatever. Could you be more specific? Both about the "webpage" and about our suggested message of both endorsing and shaming a software company at the same time? To be frank, I consider this vote to be more important for our project/community to make sure everyone's voice is heard, than the actual outcome. I probably fail to parse this sentence as it makes no sense whatsoever to me;-( At the moment, it looks to me that FFmpeg is a community without leadership, enforced rules and consequences. In fact, I consider this the main reason why people consider working in it an unfriendly experience. We can't really change this for the better unless there is a somewhat "recognized" authority which has the power to make decisions, rules, and enforce them. I hoped that this can be the voting comitte. Voting is important, because people typically accept majority decisions even if they don't agree with them. I believe that this is why several people including me expressed that NDI removal should only have happened after a vote. If we don't vote about this, but simply accept that somebody pushed this without consensus, then it is a dangerous precedent, one that will only prove that you don't really have to play by the rules here. So that is what I mean, when I write that voting about this is important for the community. Because the NDI issue and the way it was handled is a manifestation of our bigger problems. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavfilter/af_astats: fix msvc compile error
On 4/29/19, Matthias Troffaes wrote: > MSVC requires an explicit cast from void * to void when applying the > ternary conditional operator to switch between methods that return > void. The attached patch fixes the problem. > > For information, log of failed build: > > https://ci.appveyor.com/project/mcmtroffaes/ffmpeg-msvc-build/builds/2414/job/bbeyhavgy4kmqu7k > > Kind regards, > Matthias > Applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2 2/7] libavfilter/vf_sr: refine code to remove keyword 'else'
2019-04-25 4:14 GMT+02:00, Guo, Yejun :
> +}
> +else{
Please try to fix this.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
2019-04-29 1:02 GMT+02:00, Marton Balint : > > On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote: > >> 2019-04-28 22:02 GMT+02:00, Marton Balint : >> >>> 1) Should libNDI support be removed from the ffmpeg codebase? >> >> This sounds to me as if you know of an alternative to not endorsing >> a company that profits from FFmpeg while at the same time >> violating the copyright of the FFmpeg developers? >> What could this alternative be? > > We could list them on our webpage hall of shame, or whatever. Could you be more specific? Both about the "webpage" and about our suggested message of both endorsing and shaming a software company at the same time? > To be frank, I consider this vote to be more important for our > project/community to make sure everyone's voice is heard, > than the actual outcome. I probably fail to parse this sentence as it makes no sense whatsoever to me;-( Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2 7/7] libavfilter/dnn: add more data type support for dnn model input
Em qua, 24 de abr de 2019 às 23:15, Guo, Yejun escreveu:
>
> currently, only float is supported as model input, actually, there
> are other data types, this patch adds uint8.
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/dnn_backend_native.c | 4 +++-
> libavfilter/dnn_backend_tf.c | 28
> libavfilter/dnn_interface.h | 10 +-
> libavfilter/vf_sr.c | 4 +++-
> 4 files changed, 39 insertions(+), 7 deletions(-)
>
> diff --git a/libavfilter/dnn_backend_native.c
> b/libavfilter/dnn_backend_native.c
> index 8a83c63..06fbdf3 100644
> --- a/libavfilter/dnn_backend_native.c
> +++ b/libavfilter/dnn_backend_native.c
> @@ -24,8 +24,9 @@
> */
>
> #include "dnn_backend_native.h"
> +#include "libavutil/avassert.h"
>
> -static DNNReturnType set_input_output_native(void *model, DNNData *input,
> const char *input_name, const char **output_names, uint32_t nb_output)
> +static DNNReturnType set_input_output_native(void *model, DNNInputData
> *input, const char *input_name, const char **output_names, uint32_t nb_output)
> {
> ConvolutionalNetwork *network = (ConvolutionalNetwork *)model;
> InputParams *input_params;
> @@ -45,6 +46,7 @@ static DNNReturnType set_input_output_native(void *model,
> DNNData *input, const
> if (input->data){
> av_freep(>data);
> }
> +av_assert0(input->dt == DNN_FLOAT);
> network->layers[0].output = input->data = av_malloc(cur_height *
> cur_width * cur_channels * sizeof(float));
> if (!network->layers[0].output){
> return DNN_ERROR;
> diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
> index ca6472d..ba959ae 100644
> --- a/libavfilter/dnn_backend_tf.c
> +++ b/libavfilter/dnn_backend_tf.c
> @@ -79,10 +79,31 @@ static TF_Buffer *read_graph(const char *model_filename)
> return graph_buf;
> }
>
> -static DNNReturnType set_input_output_tf(void *model, DNNData *input, const
> char *input_name, const char **output_names, uint32_t nb_output)
> +static TF_Tensor *allocate_input_tensor(const DNNInputData *input)
> {
> -TFModel *tf_model = (TFModel *)model;
> +TF_DataType dt;
> +size_t size;
> int64_t input_dims[] = {1, input->height, input->width, input->channels};
> +switch (input->dt) {
> +case DNN_FLOAT:
> +dt = TF_FLOAT;
> +size = sizeof(float);
> +break;
> +case DNN_UINT8:
> +dt = TF_UINT8;
> +size = sizeof(char);
> +break;
> +default:
> +av_assert0(!"should not reach here");
> +}
> +
> +return TF_AllocateTensor(dt, input_dims, 4,
> + input_dims[1] * input_dims[2] * input_dims[3] *
> size);
> +}
> +
> +static DNNReturnType set_input_output_tf(void *model, DNNInputData *input,
> const char *input_name, const char **output_names, uint32_t nb_output)
> +{
> +TFModel *tf_model = (TFModel *)model;
> TF_SessionOptions *sess_opts;
> const TF_Operation *init_op = TF_GraphOperationByName(tf_model->graph,
> "init");
>
> @@ -95,8 +116,7 @@ static DNNReturnType set_input_output_tf(void *model,
> DNNData *input, const char
> if (tf_model->input_tensor){
> TF_DeleteTensor(tf_model->input_tensor);
> }
> -tf_model->input_tensor = TF_AllocateTensor(TF_FLOAT, input_dims, 4,
> - input_dims[1] * input_dims[2]
> * input_dims[3] * sizeof(float));
> +tf_model->input_tensor = allocate_input_tensor(input);
> if (!tf_model->input_tensor){
> return DNN_ERROR;
> }
> diff --git a/libavfilter/dnn_interface.h b/libavfilter/dnn_interface.h
> index 73d226e..c24df0e 100644
> --- a/libavfilter/dnn_interface.h
> +++ b/libavfilter/dnn_interface.h
> @@ -32,6 +32,14 @@ typedef enum {DNN_SUCCESS, DNN_ERROR} DNNReturnType;
>
> typedef enum {DNN_NATIVE, DNN_TF} DNNBackendType;
>
> +typedef enum {DNN_FLOAT, DNN_UINT8} DNNDataType;
> +
> +typedef struct DNNInputData{
> +void *data;
> +DNNDataType dt;
> +int width, height, channels;
> +} DNNInputData;
> +
> typedef struct DNNData{
> float *data;
> int width, height, channels;
> @@ -42,7 +50,7 @@ typedef struct DNNModel{
> void *model;
> // Sets model input and output.
> // Should be called at least once before model execution.
> -DNNReturnType (*set_input_output)(void *model, DNNData *input, const
> char *input_name, const char **output_names, uint32_t nb_output);
> +DNNReturnType (*set_input_output)(void *model, DNNInputData *input,
> const char *input_name, const char **output_names, uint32_t nb_output);
> } DNNModel;
>
> // Stores pointers to functions for loading, executing, freeing DNN models
> for one of the backends.
> diff --git a/libavfilter/vf_sr.c b/libavfilter/vf_sr.c
> index b4d4165..c0d7126 100644
> --- a/libavfilter/vf_sr.c
> +++ b/libavfilter/vf_sr.c
> @@ -40,7 +40,8 @@ typedef struct SRContext {
>
Re: [FFmpeg-devel] [PATCH V2 6/7] libavfilter/dnn: support multiple outputs for tensorflow model
Em qua, 24 de abr de 2019 às 23:14, Guo, Yejun escreveu:
>
> some models such as ssd, yolo have more than one output.
>
> the clean up code in this patch is a little complex, it is because
> that set_input_output_tf could be called for many times together
> with ff_dnn_execute_model_tf, we have to clean resources for the
> case that the two interfaces are called interleaved.
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/dnn_backend_native.c | 15 +---
> libavfilter/dnn_backend_native.h | 2 +-
> libavfilter/dnn_backend_tf.c | 80
>
> libavfilter/dnn_backend_tf.h | 2 +-
> libavfilter/dnn_interface.h | 6 ++-
> libavfilter/vf_sr.c | 11 +++---
> 6 files changed, 85 insertions(+), 31 deletions(-)
>
> diff --git a/libavfilter/dnn_backend_native.c
> b/libavfilter/dnn_backend_native.c
> index 18735c0..8a83c63 100644
> --- a/libavfilter/dnn_backend_native.c
> +++ b/libavfilter/dnn_backend_native.c
> @@ -25,7 +25,7 @@
>
> #include "dnn_backend_native.h"
>
> -static DNNReturnType set_input_output_native(void *model, DNNData *input,
> const char *input_name, const char *output_name)
> +static DNNReturnType set_input_output_native(void *model, DNNData *input,
> const char *input_name, const char **output_names, uint32_t nb_output)
> {
> ConvolutionalNetwork *network = (ConvolutionalNetwork *)model;
> InputParams *input_params;
> @@ -275,7 +275,7 @@ static void depth_to_space(const float *input, float
> *output, int block_size, in
> }
> }
>
> -DNNReturnType ff_dnn_execute_model_native(const DNNModel *model, DNNData
> *output)
> +DNNReturnType ff_dnn_execute_model_native(const DNNModel *model, DNNData
> *outputs, uint32_t nb_output)
> {
> ConvolutionalNetwork *network = (ConvolutionalNetwork *)model->model;
> int cur_width, cur_height, cur_channels;
> @@ -317,10 +317,13 @@ DNNReturnType ff_dnn_execute_model_native(const
> DNNModel *model, DNNData *output
> }
> }
>
> -output->data = network->layers[network->layers_num - 1].output;
> -output->height = cur_height;
> -output->width = cur_width;
> -output->channels = cur_channels;
> +// native mode does not support multiple outputs yet
> +if (nb_output > 1)
> +return DNN_ERROR;
> +outputs[0].data = network->layers[network->layers_num - 1].output;
> +outputs[0].height = cur_height;
> +outputs[0].width = cur_width;
> +outputs[0].channels = cur_channels;
>
> return DNN_SUCCESS;
> }
> diff --git a/libavfilter/dnn_backend_native.h
> b/libavfilter/dnn_backend_native.h
> index adaf4a7..e13a68a 100644
> --- a/libavfilter/dnn_backend_native.h
> +++ b/libavfilter/dnn_backend_native.h
> @@ -63,7 +63,7 @@ typedef struct ConvolutionalNetwork{
>
> DNNModel *ff_dnn_load_model_native(const char *model_filename);
>
> -DNNReturnType ff_dnn_execute_model_native(const DNNModel *model, DNNData
> *output);
> +DNNReturnType ff_dnn_execute_model_native(const DNNModel *model, DNNData
> *outputs, uint32_t nb_output);
>
> void ff_dnn_free_model_native(DNNModel **model);
>
> diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
> index be8401e..ca6472d 100644
> --- a/libavfilter/dnn_backend_tf.c
> +++ b/libavfilter/dnn_backend_tf.c
> @@ -26,6 +26,7 @@
> #include "dnn_backend_tf.h"
> #include "dnn_backend_native.h"
> #include "libavformat/avio.h"
> +#include "libavutil/avassert.h"
>
> #include
>
> @@ -33,9 +34,11 @@ typedef struct TFModel{
> TF_Graph *graph;
> TF_Session *session;
> TF_Status *status;
> -TF_Output input, output;
> +TF_Output input;
> TF_Tensor *input_tensor;
> -TF_Tensor *output_tensor;
> +TF_Output *outputs;
> +TF_Tensor **output_tensors;
> +uint32_t nb_output;
> } TFModel;
>
> static void free_buffer(void *data, size_t length)
> @@ -76,7 +79,7 @@ static TF_Buffer *read_graph(const char *model_filename)
> return graph_buf;
> }
>
> -static DNNReturnType set_input_output_tf(void *model, DNNData *input, const
> char *input_name, const char *output_name)
> +static DNNReturnType set_input_output_tf(void *model, DNNData *input, const
> char *input_name, const char **output_names, uint32_t nb_output)
> {
> TFModel *tf_model = (TFModel *)model;
> int64_t input_dims[] = {1, input->height, input->width, input->channels};
> @@ -100,11 +103,38 @@ static DNNReturnType set_input_output_tf(void *model,
> DNNData *input, const char
> input->data = (float *)TF_TensorData(tf_model->input_tensor);
>
> // Output operation
> -tf_model->output.oper = TF_GraphOperationByName(tf_model->graph,
> output_name);
> -if (!tf_model->output.oper){
> +if (nb_output == 0)
> +return DNN_ERROR;
> +
> +av_freep(_model->outputs);
> +tf_model->outputs = av_malloc_array(nb_output,
> sizeof(*tf_model->outputs));
> +if (!tf_model->outputs)
> +return DNN_ERROR;
> +for (int i = 0; i < nb_output;
Re: [FFmpeg-devel] [PATCH V2 4/7] libavfilter/dnn: determine dnn output during execute_model instead of set_input_output
Em qua, 24 de abr de 2019 às 23:14, Guo, Yejun escreveu:
>
> Currently, within interface set_input_output, the dims/memory of the
> tensorflow
> dnn model output is determined by executing the model with zero input,
> actually, the output dims might vary with different input data for networks
> such as object detection models faster-rcnn, ssd and yolo.
>
> This patch moves the logic from set_input_output to execute_model which
> is suitable for all the cases. Since interface changed, and so
> dnn_backend_native
> also changes.
>
> In vf_sr.c, it knows it's srcnn or espcn by executing the model with zero
> input,
> so execute_model has to be called in function config_props
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/dnn_backend_native.c | 14 +-
> libavfilter/dnn_backend_native.h | 2 +-
> libavfilter/dnn_backend_tf.c | 56
>
> libavfilter/dnn_backend_tf.h | 2 +-
> libavfilter/dnn_interface.h | 6 ++---
> libavfilter/vf_sr.c | 20 +++---
> 6 files changed, 51 insertions(+), 49 deletions(-)
>
> diff --git a/libavfilter/dnn_backend_native.c
> b/libavfilter/dnn_backend_native.c
> index fe43116..18735c0 100644
> --- a/libavfilter/dnn_backend_native.c
> +++ b/libavfilter/dnn_backend_native.c
> @@ -25,7 +25,7 @@
>
> #include "dnn_backend_native.h"
>
> -static DNNReturnType set_input_output_native(void *model, DNNData *input,
> const char *input_name, DNNData *output, const char *output_name)
> +static DNNReturnType set_input_output_native(void *model, DNNData *input,
> const char *input_name, const char *output_name)
> {
> ConvolutionalNetwork *network = (ConvolutionalNetwork *)model;
> InputParams *input_params;
> @@ -81,11 +81,6 @@ static DNNReturnType set_input_output_native(void *model,
> DNNData *input, const
> }
> }
>
> -output->data = network->layers[network->layers_num - 1].output;
> -output->height = cur_height;
> -output->width = cur_width;
> -output->channels = cur_channels;
> -
> return DNN_SUCCESS;
> }
>
> @@ -280,7 +275,7 @@ static void depth_to_space(const float *input, float
> *output, int block_size, in
> }
> }
>
> -DNNReturnType ff_dnn_execute_model_native(const DNNModel *model)
> +DNNReturnType ff_dnn_execute_model_native(const DNNModel *model, DNNData
> *output)
> {
> ConvolutionalNetwork *network = (ConvolutionalNetwork *)model->model;
> int cur_width, cur_height, cur_channels;
> @@ -322,6 +317,11 @@ DNNReturnType ff_dnn_execute_model_native(const DNNModel
> *model)
> }
> }
>
> +output->data = network->layers[network->layers_num - 1].output;
> +output->height = cur_height;
> +output->width = cur_width;
> +output->channels = cur_channels;
> +
> return DNN_SUCCESS;
> }
>
> diff --git a/libavfilter/dnn_backend_native.h
> b/libavfilter/dnn_backend_native.h
> index 51d4cac..adaf4a7 100644
> --- a/libavfilter/dnn_backend_native.h
> +++ b/libavfilter/dnn_backend_native.h
> @@ -63,7 +63,7 @@ typedef struct ConvolutionalNetwork{
>
> DNNModel *ff_dnn_load_model_native(const char *model_filename);
>
> -DNNReturnType ff_dnn_execute_model_native(const DNNModel *model);
> +DNNReturnType ff_dnn_execute_model_native(const DNNModel *model, DNNData
> *output);
>
> void ff_dnn_free_model_native(DNNModel **model);
>
> diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
> index a838907..7bee45c 100644
> --- a/libavfilter/dnn_backend_tf.c
> +++ b/libavfilter/dnn_backend_tf.c
> @@ -35,7 +35,6 @@ typedef struct TFModel{
> TF_Status *status;
> TF_Output input, output;
> TF_Tensor *input_tensor;
> -DNNData *output_data;
> } TFModel;
>
> static void free_buffer(void *data, size_t length)
> @@ -76,13 +75,12 @@ static TF_Buffer *read_graph(const char *model_filename)
> return graph_buf;
> }
>
> -static DNNReturnType set_input_output_tf(void *model, DNNData *input, const
> char *input_name, DNNData *output, const char *output_name)
> +static DNNReturnType set_input_output_tf(void *model, DNNData *input, const
> char *input_name, const char *output_name)
> {
> TFModel *tf_model = (TFModel *)model;
> int64_t input_dims[] = {1, input->height, input->width, input->channels};
> TF_SessionOptions *sess_opts;
> const TF_Operation *init_op = TF_GraphOperationByName(tf_model->graph,
> "init");
> -TF_Tensor *output_tensor;
>
> // Input operation
> tf_model->input.oper = TF_GraphOperationByName(tf_model->graph,
> input_name);
> @@ -132,26 +130,6 @@ static DNNReturnType set_input_output_tf(void *model,
> DNNData *input, const char
> }
> }
>
> -// Execute network to get output height, width and number of channels
> -TF_SessionRun(tf_model->session, NULL,
> - _model->input, _model->input_tensor, 1,
> - _model->output, _tensor, 1,
> - NULL, 0, NULL, tf_model->status);
>
Re: [FFmpeg-devel] [PATCH V2 5/7] libavfilter/dnn: avoid memcpy for tensorflow dnn output
Em qua, 24 de abr de 2019 às 23:14, Guo, Yejun escreveu:
>
> use TF_Tensor's cpu address to avoid extra memcpy.
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/dnn_backend_tf.c | 36
> libavfilter/vf_sr.c | 3 ---
> 2 files changed, 12 insertions(+), 27 deletions(-)
>
> diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
> index 7bee45c..be8401e 100644
> --- a/libavfilter/dnn_backend_tf.c
> +++ b/libavfilter/dnn_backend_tf.c
> @@ -35,6 +35,7 @@ typedef struct TFModel{
> TF_Status *status;
> TF_Output input, output;
> TF_Tensor *input_tensor;
> +TF_Tensor *output_tensor;
> } TFModel;
>
> static void free_buffer(void *data, size_t length)
> @@ -460,13 +461,11 @@ DNNModel *ff_dnn_load_model_tf(const char
> *model_filename)
> return NULL;
> }
>
> -tf_model = av_malloc(sizeof(TFModel));
> +tf_model = av_mallocz(sizeof(TFModel));
> if (!tf_model){
> av_freep();
> return NULL;
> }
> -tf_model->session = NULL;
> -tf_model->input_tensor = NULL;
>
> if (load_tf_model(tf_model, model_filename) != DNN_SUCCESS){
> if (load_native_model(tf_model, model_filename) != DNN_SUCCESS){
> @@ -488,36 +487,22 @@ DNNModel *ff_dnn_load_model_tf(const char
> *model_filename)
> DNNReturnType ff_dnn_execute_model_tf(const DNNModel *model, DNNData *output)
> {
> TFModel *tf_model = (TFModel *)model->model;
> -TF_Tensor *output_tensor;
> -uint64_t count;
> -uint64_t old_count = output->height * output->width * output->channels *
> sizeof(float);
> +if (tf_model->output_tensor)
> +TF_DeleteTensor(tf_model->output_tensor);
>
> TF_SessionRun(tf_model->session, NULL,
>_model->input, _model->input_tensor, 1,
> - _model->output, _tensor, 1,
> + _model->output, _model->output_tensor, 1,
>NULL, 0, NULL, tf_model->status);
>
> if (TF_GetCode(tf_model->status) != TF_OK){
> return DNN_ERROR;
> }
>
> -output->height = TF_Dim(output_tensor, 1);
> -output->width = TF_Dim(output_tensor, 2);
> -output->channels = TF_Dim(output_tensor, 3);
> -count = output->height * output->width * output->channels *
> sizeof(float);
> -if (output->data) {
> -if (count > old_count) {
> -av_freep(>data);
> -}
> -}
> -if (!output->data) {
> -output->data = av_malloc(count);
> -if (!output->data){
> -return DNN_ERROR;
> -}
> -}
> -memcpy(output->data, TF_TensorData(output_tensor), count);
> -TF_DeleteTensor(output_tensor);
> +output->height = TF_Dim(tf_model->output_tensor, 1);
> +output->width = TF_Dim(tf_model->output_tensor, 2);
> +output->channels = TF_Dim(tf_model->output_tensor, 3);
> +output->data = TF_TensorData(tf_model->output_tensor);
>
> return DNN_SUCCESS;
> }
> @@ -541,6 +526,9 @@ void ff_dnn_free_model_tf(DNNModel **model)
> if (tf_model->input_tensor){
> TF_DeleteTensor(tf_model->input_tensor);
> }
> +if (tf_model->output_tensor){
> +TF_DeleteTensor(tf_model->output_tensor);
> +}
> av_freep(_model);
> av_freep(model);
> }
> diff --git a/libavfilter/vf_sr.c b/libavfilter/vf_sr.c
> index 7c92730..53bd8ea 100644
> --- a/libavfilter/vf_sr.c
> +++ b/libavfilter/vf_sr.c
> @@ -277,9 +277,6 @@ static av_cold void uninit(AVFilterContext *context)
> int i;
> SRContext *sr_context = context->priv;
>
> -if (sr_context->backend_type == DNN_TF)
> -av_freep(_context->output.data);
> -
> if (sr_context->dnn_module){
> (sr_context->dnn_module->free_model)(_context->model);
> av_freep(_context->dnn_module);
> --
> 2.7.4
>
LGTM.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2 3/7] libavfilter/dnn: remove limit for the name of DNN model input/output
Em qua, 24 de abr de 2019 às 23:14, Guo, Yejun escreveu:
>
> remove the requirment that the name of DNN model input/output
> should be "x"/"y",
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/dnn_backend_native.c | 2 +-
> libavfilter/dnn_backend_tf.c | 10 +-
> libavfilter/dnn_interface.h | 2 +-
> libavfilter/vf_sr.c | 4 ++--
> 4 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/libavfilter/dnn_backend_native.c
> b/libavfilter/dnn_backend_native.c
> index 70d857f..fe43116 100644
> --- a/libavfilter/dnn_backend_native.c
> +++ b/libavfilter/dnn_backend_native.c
> @@ -25,7 +25,7 @@
>
> #include "dnn_backend_native.h"
>
> -static DNNReturnType set_input_output_native(void *model, DNNData *input,
> DNNData *output)
> +static DNNReturnType set_input_output_native(void *model, DNNData *input,
> const char *input_name, DNNData *output, const char *output_name)
> {
> ConvolutionalNetwork *network = (ConvolutionalNetwork *)model;
> InputParams *input_params;
> diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
> index 9e0c127..a838907 100644
> --- a/libavfilter/dnn_backend_tf.c
> +++ b/libavfilter/dnn_backend_tf.c
> @@ -76,7 +76,7 @@ static TF_Buffer *read_graph(const char *model_filename)
> return graph_buf;
> }
>
> -static DNNReturnType set_input_output_tf(void *model, DNNData *input,
> DNNData *output)
> +static DNNReturnType set_input_output_tf(void *model, DNNData *input, const
> char *input_name, DNNData *output, const char *output_name)
> {
> TFModel *tf_model = (TFModel *)model;
> int64_t input_dims[] = {1, input->height, input->width, input->channels};
> @@ -84,8 +84,8 @@ static DNNReturnType set_input_output_tf(void *model,
> DNNData *input, DNNData *o
> const TF_Operation *init_op = TF_GraphOperationByName(tf_model->graph,
> "init");
> TF_Tensor *output_tensor;
>
> -// Input operation should be named 'x'
> -tf_model->input.oper = TF_GraphOperationByName(tf_model->graph, "x");
> +// Input operation
> +tf_model->input.oper = TF_GraphOperationByName(tf_model->graph,
> input_name);
> if (!tf_model->input.oper){
> return DNN_ERROR;
> }
> @@ -100,8 +100,8 @@ static DNNReturnType set_input_output_tf(void *model,
> DNNData *input, DNNData *o
> }
> input->data = (float *)TF_TensorData(tf_model->input_tensor);
>
> -// Output operation should be named 'y'
> -tf_model->output.oper = TF_GraphOperationByName(tf_model->graph, "y");
> +// Output operation
> +tf_model->output.oper = TF_GraphOperationByName(tf_model->graph,
> output_name);
> if (!tf_model->output.oper){
> return DNN_ERROR;
> }
> diff --git a/libavfilter/dnn_interface.h b/libavfilter/dnn_interface.h
> index e367343..0390e39 100644
> --- a/libavfilter/dnn_interface.h
> +++ b/libavfilter/dnn_interface.h
> @@ -40,7 +40,7 @@ typedef struct DNNModel{
> void *model;
> // Sets model input and output, while allocating additional memory for
> intermediate calculations.
> // Should be called at least once before model execution.
> -DNNReturnType (*set_input_output)(void *model, DNNData *input, DNNData
> *output);
> +DNNReturnType (*set_input_output)(void *model, DNNData *input, const
> char *input_name, DNNData *output, const char *output_name);
> } DNNModel;
>
> // Stores pointers to functions for loading, executing, freeing DNN models
> for one of the backends.
> diff --git a/libavfilter/vf_sr.c b/libavfilter/vf_sr.c
> index 9bb0fc5..085ac19 100644
> --- a/libavfilter/vf_sr.c
> +++ b/libavfilter/vf_sr.c
> @@ -122,7 +122,7 @@ static int config_props(AVFilterLink *inlink)
> sr_context->input.height = inlink->h * sr_context->scale_factor;
> sr_context->input.channels = 1;
>
> -result = (sr_context->model->set_input_output)(sr_context->model->model,
> _context->input, _context->output);
> +result = (sr_context->model->set_input_output)(sr_context->model->model,
> _context->input, "x", _context->output, "y");
> if (result != DNN_SUCCESS){
> av_log(context, AV_LOG_ERROR, "could not set input and output for
> the model\n");
> return AVERROR(EIO);
> @@ -131,7 +131,7 @@ static int config_props(AVFilterLink *inlink)
> if (sr_context->input.height != sr_context->output.height ||
> sr_context->input.width != sr_context->output.width){
> sr_context->input.width = inlink->w;
> sr_context->input.height = inlink->h;
> -result =
> (sr_context->model->set_input_output)(sr_context->model->model,
> _context->input, _context->output);
> +result =
> (sr_context->model->set_input_output)(sr_context->model->model,
> _context->input, "x", _context->output, "y");
> if (result != DNN_SUCCESS){
> av_log(context, AV_LOG_ERROR, "could not set input and output
> for the model\n");
> return AVERROR(EIO);
> --
> 2.7.4
>
LGTM.
>
Re: [FFmpeg-devel] [PATCH V2 2/7] libavfilter/vf_sr: refine code to remove keyword 'else'
Em qua, 24 de abr de 2019 às 23:14, Guo, Yejun escreveu:
>
> remove 'else' since there is always 'return' in 'if' scope,
> so the code will be clean for later maintenance
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/vf_sr.c | 143
> ++--
> 1 file changed, 71 insertions(+), 72 deletions(-)
>
> diff --git a/libavfilter/vf_sr.c b/libavfilter/vf_sr.c
> index 6423d2e..9bb0fc5 100644
> --- a/libavfilter/vf_sr.c
> +++ b/libavfilter/vf_sr.c
> @@ -127,88 +127,87 @@ static int config_props(AVFilterLink *inlink)
> av_log(context, AV_LOG_ERROR, "could not set input and output for
> the model\n");
> return AVERROR(EIO);
> }
> -else{
> -if (sr_context->input.height != sr_context->output.height ||
> sr_context->input.width != sr_context->output.width){
> -sr_context->input.width = inlink->w;
> -sr_context->input.height = inlink->h;
> -result =
> (sr_context->model->set_input_output)(sr_context->model->model,
> _context->input, _context->output);
> -if (result != DNN_SUCCESS){
> -av_log(context, AV_LOG_ERROR, "could not set input and
> output for the model\n");
> -return AVERROR(EIO);
> -}
> -sr_context->scale_factor = 0;
> +
> +if (sr_context->input.height != sr_context->output.height ||
> sr_context->input.width != sr_context->output.width){
> +sr_context->input.width = inlink->w;
> +sr_context->input.height = inlink->h;
> +result =
> (sr_context->model->set_input_output)(sr_context->model->model,
> _context->input, _context->output);
> +if (result != DNN_SUCCESS){
> +av_log(context, AV_LOG_ERROR, "could not set input and output
> for the model\n");
> +return AVERROR(EIO);
> }
> -outlink->h = sr_context->output.height;
> -outlink->w = sr_context->output.width;
> -sr_context->sws_contexts[1] =
> sws_getContext(sr_context->input.width, sr_context->input.height,
> AV_PIX_FMT_GRAY8,
> -
> sr_context->input.width, sr_context->input.height, AV_PIX_FMT_GRAYF32,
> - 0, NULL, NULL, NULL);
> -sr_context->sws_input_linesize = sr_context->input.width << 2;
> -sr_context->sws_contexts[2] =
> sws_getContext(sr_context->output.width, sr_context->output.height,
> AV_PIX_FMT_GRAYF32,
> -
> sr_context->output.width, sr_context->output.height, AV_PIX_FMT_GRAY8,
> - 0, NULL, NULL, NULL);
> -sr_context->sws_output_linesize = sr_context->output.width << 2;
> -if (!sr_context->sws_contexts[1] || !sr_context->sws_contexts[2]){
> -av_log(context, AV_LOG_ERROR, "could not create SwsContext for
> conversions\n");
> +sr_context->scale_factor = 0;
> +}
> +outlink->h = sr_context->output.height;
> +outlink->w = sr_context->output.width;
> +sr_context->sws_contexts[1] = sws_getContext(sr_context->input.width,
> sr_context->input.height, AV_PIX_FMT_GRAY8,
> + sr_context->input.width,
> sr_context->input.height, AV_PIX_FMT_GRAYF32,
> + 0, NULL, NULL, NULL);
> +sr_context->sws_input_linesize = sr_context->input.width << 2;
> +sr_context->sws_contexts[2] = sws_getContext(sr_context->output.width,
> sr_context->output.height, AV_PIX_FMT_GRAYF32,
> + sr_context->output.width,
> sr_context->output.height, AV_PIX_FMT_GRAY8,
> + 0, NULL, NULL, NULL);
> +sr_context->sws_output_linesize = sr_context->output.width << 2;
> +if (!sr_context->sws_contexts[1] || !sr_context->sws_contexts[2]){
> +av_log(context, AV_LOG_ERROR, "could not create SwsContext for
> conversions\n");
> +return AVERROR(ENOMEM);
> +}
> +if (sr_context->scale_factor){
> +sr_context->sws_contexts[0] = sws_getContext(inlink->w, inlink->h,
> inlink->format,
> + outlink->w, outlink->h,
> outlink->format,
> + SWS_BICUBIC, NULL,
> NULL, NULL);
> +if (!sr_context->sws_contexts[0]){
> +av_log(context, AV_LOG_ERROR, "could not create SwsContext for
> scaling\n");
> return AVERROR(ENOMEM);
> }
> -if (sr_context->scale_factor){
> -sr_context->sws_contexts[0] = sws_getContext(inlink->w,
> inlink->h, inlink->format,
> - outlink->w,
> outlink->h, outlink->format,
> +sr_context->sws_slice_h = inlink->h;
> +}
> +else{
> +if (inlink->format !=
Re: [FFmpeg-devel] [PATCH V2 1/7] libavfilter/dnn_backend_tf.c: set layer_add_res for input layer
Em qua, 24 de abr de 2019 às 23:14, Guo, Yejun escreveu:
>
> otherwise, the following check will return error if layer_add_res
> is randomly initialized.
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/dnn_backend_tf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
> index 5bc7f06..9e0c127 100644
> --- a/libavfilter/dnn_backend_tf.c
> +++ b/libavfilter/dnn_backend_tf.c
> @@ -440,6 +440,7 @@ static DNNReturnType load_native_model(TFModel *tf_model,
> const char *model_file
> for (layer = 0; layer < conv_network->layers_num; ++layer){
> switch (conv_network->layers[layer].type){
> case INPUT:
> +layer_add_res = DNN_SUCCESS;
> break;
> case CONV:
> layer_add_res = add_conv_layer(tf_model, transpose_op, ,
> --
> 2.7.4
LGTM.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: account for small frame sizes.
On Mon, Apr 29, 2019 at 3:34 PM Hendrik Leppkes wrote: > > On Mon, Apr 29, 2019 at 2:39 PM Menno de Gier wrote: > > > > Some ADTS files have a first frame that's shorter than the 10 bytes that > > are being read while checking for ID3 tags. > > > > Fixes #7271 > > > > James already send another patch for this issue - > https://patchwork.ffmpeg.org/patch/12913/ - which seems to get by > without seeks, which seems better. Maybe test that one? Ah thanks, I missed that. Looks like a better patch indeed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in FFmpeg dnn native mode.
Em seg, 29 de abr de 2019 às 00:06, escreveu: > > > > > > -原始邮件- > > 发件人: "Pedro Arthur" > > 发送时间: 2019-04-29 10:42:42 (星期一) > > 收件人: "FFmpeg development discussions and patches" > > 抄送: > > 主题: Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in > > FFmpeg dnn native mode. > > > > I think for training these filters the preferred method is VALID as it > > uses only the data available (without filling the borders) and gives > > the best possible result. > > However for inference usually one expects to output an image with the > > same size of the original (imagine the case of chained filters where > > each one reduces the image by a few pixels, in the end one may have a > > useless output). > > Therefore it makes perfect sense to use different padding methods for > > training/inference. > > > > The clamp_to_edge padding was introduced before the TF backend thus it > > stayed in the native backend even after the introduction of the TF > > backend. > > Indeed the clamp_to_edge is simpler than the other padding methods and > > also gives a slight better result, If I remember correct the student > > which implemented the TF backend did not find an equivalent padding > > method in TF, thats why it uses different paddings. > > > Yes, I think clamp_to_edge is a good method to keep the output with the same > size as input. However, I don't think "VALID" is the best method giving best > possible result. So, for "VALID" mode, maybe we can use the clamp_to_edge > method in the current dnn native mode? And then, we should also add "SAME" > option to support other filters. > I think it is best to not make any assumptions like VALID => clamp_to_edge, but you can keep it for now. Ideally the model should have a padding layer which the backend properly implements. Currently the TF backend when reading a native model adds this padding layer implicitly, therefore it would be a matter of changing it to have an explicity padding layer in the model. Maybe you can assume VALID => clamp_to_edge, so you can add what you need without changing the SR code and later you implement the explicity padding support and send a PR to the original repo (https://github.com/HighVoltageRocknRoll/sr) properly modifying the model. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 4/29/2019 4:23 AM, Reimar Döffinger wrote: > On 28.04.2019, at 22:02, Marton Balint wrote: > >> Hi All, >> >> There has been discussion on the mailing list several times about the >> inclusion of support for closed source components (codecs, formats, filters, >> etc) in the main ffmpeg codebase. >> >> Also the removal of libNDI happened without general consensus, so a vote is >> necessary to justify the removal. >> >> So here is a call to the voting committee [1] to decide on the following two >> questions: >> >> 1) Should libNDI support be removed from the ffmpeg codebase? > > I don't see myself qualified to vote You can vote if you want, you're on the list of allowed contributors. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/f_ebur128: use correct type for chl
On Mon, Apr 29, 2019 at 04:47:52PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/f_ebur128.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
> index f613d8def2..f25d5f096e 100644
> --- a/libavfilter/f_ebur128.c
> +++ b/libavfilter/f_ebur128.c
> @@ -420,7 +420,7 @@ static int config_audio_output(AVFilterLink *outlink)
>
> for (i = 0; i < nb_channels; i++) {
> /* channel weighting */
> -const uint16_t chl =
> av_channel_layout_extract_channel(outlink->channel_layout, i);
> +const uint64_t chl =
> av_channel_layout_extract_channel(outlink->channel_layout, i);
> if (chl & (AV_CH_LOW_FREQUENCY|AV_CH_LOW_FREQUENCY_2)) {
> ebur128->ch_weighting[i] = 0;
> } else if (chl & BACK_MASK) {
LGTM, thanks
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/f_ebur128: use correct type for chl
Signed-off-by: Paul B Mahol
---
libavfilter/f_ebur128.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index f613d8def2..f25d5f096e 100644
--- a/libavfilter/f_ebur128.c
+++ b/libavfilter/f_ebur128.c
@@ -420,7 +420,7 @@ static int config_audio_output(AVFilterLink *outlink)
for (i = 0; i < nb_channels; i++) {
/* channel weighting */
-const uint16_t chl =
av_channel_layout_extract_channel(outlink->channel_layout, i);
+const uint64_t chl =
av_channel_layout_extract_channel(outlink->channel_layout, i);
if (chl & (AV_CH_LOW_FREQUENCY|AV_CH_LOW_FREQUENCY_2)) {
ebur128->ch_weighting[i] = 0;
} else if (chl & BACK_MASK) {
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: account for small frame sizes.
On Mon, Apr 29, 2019 at 2:39 PM Menno de Gier wrote: > > Some ADTS files have a first frame that's shorter than the 10 bytes that > are being read while checking for ID3 tags. > > Fixes #7271 > James already send another patch for this issue - https://patchwork.ffmpeg.org/patch/12913/ - which seems to get by without seeks, which seems better. Maybe test that one? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/aacdec: account for small frame sizes.
Some ADTS files have a first frame that's shorter than the 10 bytes that
are being read while checking for ID3 tags.
Fixes #7271
Signed-off-by: Menno de Gier
---
libavformat/aacdec.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
index bd324a1420..25bccfbcb8 100644
--- a/libavformat/aacdec.c
+++ b/libavformat/aacdec.c
@@ -184,6 +184,15 @@ static int adts_aac_read_packet(AVFormatContext *s,
AVPacket *pkt)
return AVERROR_INVALIDDATA;
}
+if (fsize < pkt->size) {
+ret = avio_seek(s->pb, fsize - pkt->size, SEEK_CUR);
+if (ret < 0) {
+av_packet_unref(pkt);
+return ret;
+}
+av_shrink_packet(pkt, fsize);
+}
+
ret = av_append_packet(s->pb, pkt, fsize - pkt->size);
if (ret < 0)
av_packet_unref(pkt);
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: Fix the memory leak for enc_ctrl.Payload
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Monday, April 15, 2019 9:23 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: Fix the memory leak for
> enc_ctrl.Payload
>
> frame->enc_ctrl.Payload is malloced in get_free_frame, directly memset
> the whole structure of enc_ctrl to zero will cause the memory leak for
> enc_ctrl.Payload.
>
> frame->enc_ctrl as a structure will be malloc and init to zero by
> frame->calling
> frame = av_mallocz(sizeof(*frame)), so the memset is redundant and can be
> removed.
>
> Can be reproduced by #7830.
Patch LGTM now, but I can't see strong relationship between this patch and
tikect #7830.
IMHO this is a quite common issue even if you use qsv transcoding pipeline?
> Signed-off-by: Linjie Fu
> ---
> libavcodec/qsvenc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> 5aa020d47b..19953bd4ea 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1254,7 +1254,6 @@ static int encode_frame(AVCodecContext *avctx,
> QSVEncContext *q,
> if (qsv_frame) {
> surf = _frame->surface;
> enc_ctrl = _frame->enc_ctrl;
> -memset(enc_ctrl, 0, sizeof(mfxEncodeCtrl));
>
> if (frame->pict_type == AV_PICTURE_TYPE_I) {
> enc_ctrl->FrameType = MFX_FRAMETYPE_I |
> MFX_FRAMETYPE_REF;
> --
> 2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavfilter/af_astats: fix msvc compile error
MSVC requires an explicit cast from void * to void when applying the
ternary conditional operator to switch between methods that return
void. The attached patch fixes the problem.
For information, log of failed build:
https://ci.appveyor.com/project/mcmtroffaes/ffmpeg-msvc-build/builds/2414/job/bbeyhavgy4kmqu7k
Kind regards,
Matthias
diff --git a/libavfilter/af_astats.c b/libavfilter/af_astats.c
index 1ec56d72cc..bb9a23a017 100644
--- a/libavfilter/af_astats.c
+++ b/libavfilter/af_astats.c
@@ -496,7 +496,7 @@ static void set_metadata(AudioStatsContext *s, AVDictionary **metadata)
#define UPDATE_STATS(planar, type, sample, normalizer_suffix, int_sample) \
if ((s->measure_overall | s->measure_perchannel) & ~MEASURE_MINMAXPEAK) { \
-UPDATE_STATS_##planar(type, update_stat(s, p, sample, sample normalizer_suffix, int_sample), s->is_float ? update_float_stat(s, p, sample) : s->is_double ? update_double_stat(s, p, sample) : NULL, );\
+UPDATE_STATS_##planar(type, update_stat(s, p, sample, sample normalizer_suffix, int_sample), s->is_float ? update_float_stat(s, p, sample) : s->is_double ? update_double_stat(s, p, sample) : (void)NULL, ); \
} else { \
UPDATE_STATS_##planar(type, update_minmax(s, p, sample), , p->nmin = p->min normalizer_suffix; p->nmax = p->max normalizer_suffix;); \
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavcodec: QSV protect GPB code with CO3 define
> > But the CODE doesn't say that! > > > > The code uses: > > "#if QSV_HAVE_CO3" > > > > And then every use of the "co3" member needs to be protected by this > clausule. > > Futhermore, this is true in every part of the source code in > > "qsvenc.c"... except at two points (I need to review my patch, as I noticed > another block not protected). > > > > This is a must, even if "QSV_VERSION_ATLEAST(1, 18)" > > "QSV_VERSION_ATLEAST(1, 11)" > > > > Why? > > Because the option "QSV_HAVE_CO3" can be rewriten (for example, > disabled). I don't think so. It is pre-compile checking and should not be decided in FFmpeg level, indstead depended on MSDK API has defined it or not. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add bilateral filter
Hi Paul,
On Sun, Apr 28, 2019 at 16:42:45 +0200, Paul B Mahol wrote:
Cosmetic nits:
> +Alowed range is from 1 to 6.
^ Allowed
> +Alowed range is from 2 to 256.
^
Ditto.
> +float *bbufers[256];
^
I'm not sure of the intent, but would this be "buffers" or "bbuffers"?
> +static float lut_lookup(const float *lut, const int val1, const int val2)
> +{
> +return lut[val1 > val2 ? val1 - val2 : val2 - val1];
FFABS() may help for readability.
I can't judge on the rest, as always.
Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/5] avformat/mxfdec: fix and enhance RIP KLV length checks
sön 2019-04-28 klockan 22:17 +0200 skrev Marton Balint:
>
> On Sun, 14 Apr 2019, Tomas Härdin wrote:
>
> > fre 2019-04-12 klockan 01:09 +0200 skrev Marton Balint:
> > > KLV length is BER encoded (variable size), but the code assumed the
> > > encoding to
> > > always use 4 bytes.
> > >
> > > Fixes parsing Random Index Pack in
> > > samples/MXF/issue2160/PW0805A0V01.4C5B5636.EFA330.mxf.
> > >
> > > > Signed-off-by: Marton Balint
> > >
> > > ---
> > > libavformat/mxfdec.c | 7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index 6f0f87763d..a69f2f1996 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -3126,9 +3126,12 @@ static void
> > > mxf_read_random_index_pack(AVFormatContext *s)
> > > goto end;
> > > avio_seek(s->pb, file_size - length, SEEK_SET);
> > > if (klv_read_packet(, s->pb) < 0 ||
> > > -!IS_KLV_KEY(klv.key, mxf_random_index_pack_key) ||
> > > -klv.length != length - 20)
> > > +!IS_KLV_KEY(klv.key, mxf_random_index_pack_key))
> > > goto end;
> > > +if (klv.next_klv != file_size || klv.length <= 4 || (klv.length - 4)
> > > % 12) {
> > > +av_log(s, AV_LOG_WARNING, "Invalid RIP KLV length\n");
> > > +goto end;
> > > +}
> >
> > Looks OK.
>
> Thanks, applied.
>
> >
> > Aside: Looking at klv_read_packet(), I'm suspicious of its use of
> > mxf_read_sync(). That feels like something that only belongs in
> > mxf_read_header(), to deal with run-in. Baptiste added it in
> > cabe2527ef3. FATE passes without it.
>
> I wonder if it is there to allow some byte based seeking or handle damaged
> files more gracefully? I agree it is strange a bit, maybe Baptise can chip
> in...
I *suspect* it has something to do with seeking in frame wrapped files
with crappy or non-existing indexes. But then it would be best if it
were used only in mxf_read_seek()
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On 28.04.2019, at 22:02, Marton Balint wrote: > Hi All, > > There has been discussion on the mailing list several times about the > inclusion of support for closed source components (codecs, formats, filters, > etc) in the main ffmpeg codebase. > > Also the removal of libNDI happened without general consensus, so a vote is > necessary to justify the removal. > > So here is a call to the voting committee [1] to decide on the following two > questions: > > 1) Should libNDI support be removed from the ffmpeg codebase? I don't see myself qualified to vote, and I'd rather have this vote not happen, because I don't think this specific case justifies the divisions such discussions and votes encourage. In the end, why should we really care? Yes, we should respect our users, but those users are PAYING customers of a company. Why should we be taking responsibility for them and not the company that gets paid? They can maintain their own FFmpeg patches. And it's a case of a company that decided to go closed source and to violate the license. At some point it's "you made your bed, now you get to lie in it". That said, I am not truly arguing for the taken approach, but I argue it is a bad cause to create more divisions (for example I already see the "who gets to vote" thing coming up). I also feel that some people might have other concerns triggered by this. Maybe it would be better to discuss these instead and try to reach common ground. I hope I have not offended anyone, and I admit I don't even read emails on this list nowadays. So you are under no obligation to listen to me, but I still kind of love this project and wish for it to have as healthy a community as possible when people with different world views meet head-on, and hope you can discuss in that spirit :) Best regards, Reimar Döffinger ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: enforce PCR packets without payload
‐‐‐ Original Message ‐‐‐ On Thursday, 25 de April de 2019 11:07, Andreas Håkon wrote: > Hi, > > A patch for a new optional parameter for the mpegtsenc muxer. > > Regards. > A.H. > Hi Ali KIZIL, You do the validation tests? Hi Michael Niedermayer, Have you been able to review this new functionality? It is very useful and has no side effects. Regards. A.H. --- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat: forced PCR pid in mpegts muxer
‐‐‐ Original Message ‐‐‐ On Tuesday, 23 de April de 2019 14:03, Andreas Håkon wrote: > > Thank you Moritz! > All applied. > > In addition, one correction regarding the initialization. > Sorry, but first version has an error. This is clean! > > Regards. > A.H. > Hi Michael Niedermayer, All issues resolved now. Please review this patch about this new handy functionality. Regards. A.H. --- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
