[FFmpeg-devel] [PATCH] dashdec: Fix segfault on decoding segment timeline
If first_seq_no is not within the bounds of timelines then a segfault
will occur.
This patch removes the use of first_seq_no within the timelines array
It also adds first_seq_no to the value returned by
calc_next_seg_no_from_timelines
(which allows for different values of 'startNumber')
Signed-off-by: Brendan McGrath
---
This can be reproduced by creating a dash file with the following command:
ffmpeg -i in.ts -f dash -window_size 2 out.mpd
and then after about 10 seconds run ffprobe against it.
The SegementTemplatei of out.mpd will look something like this:
So the code was trying to access the 7th element within the timeline
array (which only had one element).
The patch doesn't worry about checking for a negative value after deducting the
60
seconds as calc_next_seg_no_from_timelines accepts a signed int and works
correctly with
negative values.
libavformat/dashdec.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 2492f1d..cdb7ba5 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1083,15 +1083,12 @@ static int64_t calc_cur_seg_no(AVFormatContext *s,
struct representation *pls)
if (pls->n_fragments) {
num = pls->first_seq_no;
} else if (pls->n_timelines) {
-start_time_offset = get_segment_start_time_based_on_timeline(pls,
0x) - pls->timelines[pls->first_seq_no]->starttime; // total duration
of playlist
-if (start_time_offset < 60 * pls->fragment_timescale)
-start_time_offset = 0;
-else
-start_time_offset = start_time_offset - 60 *
pls->fragment_timescale;
-
-num = calc_next_seg_no_from_timelines(pls,
pls->timelines[pls->first_seq_no]->starttime + start_time_offset);
+start_time_offset = get_segment_start_time_based_on_timeline(pls,
0x) - 60 * pls->fragment_timescale; // 60 seconds before end
+num = calc_next_seg_no_from_timelines(pls, start_time_offset);
if (num == -1)
num = pls->first_seq_no;
+else
+num += pls->first_seq_no;
} else if (pls->fragment_duration){
if (pls->presentation_timeoffset) {
num = pls->presentation_timeoffset * pls->fragment_timescale /
pls->fragment_duration;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool
On Sat, Jan 20, 2018 at 11:49 AM, James Almer wrote:
> On 1/20/2018 1:29 AM, Muhammad Faiz wrote:
>> Help avoiding malloc-free cycles when allocating-freeing common
>> structures.
>>
>> Signed-off-by: Muhammad Faiz
>> ---
>> libavutil/staticpool.h | 117
>> +
>> 1 file changed, 117 insertions(+)
>> create mode 100644 libavutil/staticpool.h
>>
>> diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
>> new file mode 100644
>> index 00..9c9b2784bc
>> --- /dev/null
>> +++ b/libavutil/staticpool.h
>> @@ -0,0 +1,117 @@
>> +/*
>> + * 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 AVUTIL_STATICPOOL_H
>> +#define AVUTIL_STATICPOOL_H
>> +
>> +#include
>> +#include "avassert.h"
>> +#include "mem.h"
>> +
>> +/**
>> + * FF_STATICPOOL allocate memory without av_malloc if possible
>> + * @param size must be 2^n between 64 and 4096
>> + */
>> +#define FF_STATICPOOL_DECLARE(type, size)
>> \
>> +typedef struct type##_StaticPoolWrapper {
>> \
>> +typebuf;
>> \
>> +unsignedindex;
>> \
>> +atomic_uint next;
>> \
>> +} type##_StaticPoolWrapper;
>> \
>> +
>> \
>> +static atomic_uint type##_staticpool_next;
>> \
>> +static atomic_uint type##_staticpool_last;
>> \
>> +static type##_StaticPoolWrapper type##_staticpool_table[size];
>> \
>> +
>> \
>> +static type *type##_staticpool_malloc(void)
>> \
>> +{
>> \
>> +unsigned val, index, serial, new_val;
>> \
>> +
>> \
>> +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 1)));
>> \
>> +
>> \
>> +/* use serial, avoid spinlock */
>> \
>> +/* acquire, so we don't get stalled table[index].next */
>> \
>> +val = atomic_load_explicit(&type##_staticpool_next,
>> memory_order_acquire); \
>> +do {
>> \
>> +index = val & ((size) - 1);
>> \
>> +serial = val & ~((size) - 1);
>> \
>> +new_val =
>> atomic_load_explicit(&type##_staticpool_table[index].next,
>> memory_order_relaxed) | (serial + (size)); \
>> +} while
>> (!atomic_compare_exchange_strong_explicit(&type##_staticpool_next, &val,
>> new_val, \
>
> The wrappers for atomic_compare_exchange_* in the compat folder are not
> really working and fixing them is supposedly not trivial, so this will
> only work with GCC and Clang but not with for example MSVC or SunCC.
What's the problem? I only see that stdatomic compat make typedef
every atomic type to intptr_t, so atomic_*64_t won't work if
sizeof(intptr_t) == 32.
Here I use atomic_uint, so I guess it will work.
Note that if atomic_compare_exchange_* is broken then atomic_fetch_*
will also be broken because atomic_fetch_* call
atomic_compare_exchange_* on suncc compat.
>
> Can you implement this using mutexes instead, or otherwise avoid using
> atomic_compare_exchange_*? You can even use static mutex initialization
> now for all targets, and not just native pthreads.
Using mutex makes implementation slower.
Using atomic_exchange requires spin lock.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailm
Re: [FFmpeg-devel] [PATCH 1/3] avutil: add staticpool
On 1/20/2018 1:29 AM, Muhammad Faiz wrote:
> Help avoiding malloc-free cycles when allocating-freeing common
> structures.
>
> Signed-off-by: Muhammad Faiz
> ---
> libavutil/staticpool.h | 117
> +
> 1 file changed, 117 insertions(+)
> create mode 100644 libavutil/staticpool.h
>
> diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
> new file mode 100644
> index 00..9c9b2784bc
> --- /dev/null
> +++ b/libavutil/staticpool.h
> @@ -0,0 +1,117 @@
> +/*
> + * 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 AVUTIL_STATICPOOL_H
> +#define AVUTIL_STATICPOOL_H
> +
> +#include
> +#include "avassert.h"
> +#include "mem.h"
> +
> +/**
> + * FF_STATICPOOL allocate memory without av_malloc if possible
> + * @param size must be 2^n between 64 and 4096
> + */
> +#define FF_STATICPOOL_DECLARE(type, size)
>\
> +typedef struct type##_StaticPoolWrapper {
>\
> +typebuf;
>\
> +unsignedindex;
>\
> +atomic_uint next;
>\
> +} type##_StaticPoolWrapper;
>\
> +
>\
> +static atomic_uint type##_staticpool_next;
>\
> +static atomic_uint type##_staticpool_last;
>\
> +static type##_StaticPoolWrapper type##_staticpool_table[size];
>\
> +
>\
> +static type *type##_staticpool_malloc(void)
>\
> +{
>\
> +unsigned val, index, serial, new_val;
>\
> +
>\
> +av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 1)));
>\
> +
>\
> +/* use serial, avoid spinlock */
>\
> +/* acquire, so we don't get stalled table[index].next */
>\
> +val = atomic_load_explicit(&type##_staticpool_next,
> memory_order_acquire); \
> +do {
>\
> +index = val & ((size) - 1);
>\
> +serial = val & ~((size) - 1);
>\
> +new_val = atomic_load_explicit(&type##_staticpool_table[index].next,
> memory_order_relaxed) | (serial + (size)); \
> +} while
> (!atomic_compare_exchange_strong_explicit(&type##_staticpool_next, &val,
> new_val, \
The wrappers for atomic_compare_exchange_* in the compat folder are not
really working and fixing them is supposedly not trivial, so this will
only work with GCC and Clang but not with for example MSVC or SunCC.
Can you implement this using mutexes instead, or otherwise avoid using
atomic_compare_exchange_*? You can even use static mutex initialization
now for all targets, and not just native pthreads.
> + memory_order_acquire,
> memory_order_acquire)); \
> +
>\
> +index = val & ((size) - 1);
>\
> +if (index)
>\
> +return &type##_staticpool_table[index].buf;
>\
> +
>\
> +index = atomic_fetch_add_explicit(&type##_staticpool_last, 1,
> memory_order_relaxed) + 1; \
> +if (index < (size)) {
>\
[FFmpeg-devel] [PATCH 1/3] avutil: add staticpool
Help avoiding malloc-free cycles when allocating-freeing common
structures.
Signed-off-by: Muhammad Faiz
---
libavutil/staticpool.h | 117 +
1 file changed, 117 insertions(+)
create mode 100644 libavutil/staticpool.h
diff --git a/libavutil/staticpool.h b/libavutil/staticpool.h
new file mode 100644
index 00..9c9b2784bc
--- /dev/null
+++ b/libavutil/staticpool.h
@@ -0,0 +1,117 @@
+/*
+ * 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 AVUTIL_STATICPOOL_H
+#define AVUTIL_STATICPOOL_H
+
+#include
+#include "avassert.h"
+#include "mem.h"
+
+/**
+ * FF_STATICPOOL allocate memory without av_malloc if possible
+ * @param size must be 2^n between 64 and 4096
+ */
+#define FF_STATICPOOL_DECLARE(type, size)
\
+typedef struct type##_StaticPoolWrapper {
\
+typebuf;
\
+unsignedindex;
\
+atomic_uint next;
\
+} type##_StaticPoolWrapper;
\
+
\
+static atomic_uint type##_staticpool_next;
\
+static atomic_uint type##_staticpool_last;
\
+static type##_StaticPoolWrapper type##_staticpool_table[size];
\
+
\
+static type *type##_staticpool_malloc(void)
\
+{
\
+unsigned val, index, serial, new_val;
\
+
\
+av_assert0((size) >= 64 && (size) <= 4096 && !((size) & ((size) - 1)));
\
+
\
+/* use serial, avoid spinlock */
\
+/* acquire, so we don't get stalled table[index].next */
\
+val = atomic_load_explicit(&type##_staticpool_next, memory_order_acquire);
\
+do {
\
+index = val & ((size) - 1);
\
+serial = val & ~((size) - 1);
\
+new_val = atomic_load_explicit(&type##_staticpool_table[index].next,
memory_order_relaxed) | (serial + (size)); \
+} while (!atomic_compare_exchange_strong_explicit(&type##_staticpool_next,
&val, new_val, \
+ memory_order_acquire,
memory_order_acquire)); \
+
\
+index = val & ((size) - 1);
\
+if (index)
\
+return &type##_staticpool_table[index].buf;
\
+
\
+index = atomic_fetch_add_explicit(&type##_staticpool_last, 1,
memory_order_relaxed) + 1; \
+if (index < (size)) {
\
+type##_staticpool_table[index].index = index;
\
+return &type##_staticpool_table[index].buf;
\
+}
\
+
\
+atomic_fetch_add_explicit(&type##_staticpool_last, -1,
memory_order_relaxed); \
+return av_malloc(sizeof(type));
\
+}
\
+
\
+stati
[FFmpeg-devel] [PATCH 2/3] avutil/buffer: use staticpool
Use default size 1024.
Benchmark:
time ./ffmpeg -f s16le -ac 5 -ar 48000 -t 1 -i /dev/zero \
-af "aformat=s16p, asetnsamples=256" -f null -
old: 27.616s
new: 22.079s
Signed-off-by: Muhammad Faiz
---
libavutil/buffer.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 8d1aa5fa84..6dd3f0441b 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -24,6 +24,11 @@
#include "common.h"
#include "mem.h"
#include "thread.h"
+#include "staticpool.h"
+
+FF_STATICPOOL_DECLARE(AVBufferRef, 1024)
+FF_STATICPOOL_DECLARE(AVBuffer, 1024)
+FF_STATICPOOL_DECLARE(BufferPoolEntry, 1024)
AVBufferRef *av_buffer_create(uint8_t *data, int size,
void (*free)(void *opaque, uint8_t *data),
@@ -32,7 +37,7 @@ AVBufferRef *av_buffer_create(uint8_t *data, int size,
AVBufferRef *ref = NULL;
AVBuffer*buf = NULL;
-buf = av_mallocz(sizeof(*buf));
+buf = FF_STATICPOOL_MALLOCZ(AVBuffer);
if (!buf)
return NULL;
@@ -46,9 +51,9 @@ AVBufferRef *av_buffer_create(uint8_t *data, int size,
if (flags & AV_BUFFER_FLAG_READONLY)
buf->flags |= BUFFER_FLAG_READONLY;
-ref = av_mallocz(sizeof(*ref));
+ref = FF_STATICPOOL_MALLOCZ(AVBufferRef);
if (!ref) {
-av_freep(&buf);
+FF_STATICPOOL_FREEP(AVBuffer, &buf);
return NULL;
}
@@ -92,7 +97,7 @@ AVBufferRef *av_buffer_allocz(int size)
AVBufferRef *av_buffer_ref(AVBufferRef *buf)
{
-AVBufferRef *ret = av_mallocz(sizeof(*ret));
+AVBufferRef *ret = FF_STATICPOOL_MALLOCZ(AVBufferRef);
if (!ret)
return NULL;
@@ -112,13 +117,13 @@ static void buffer_replace(AVBufferRef **dst, AVBufferRef
**src)
if (src) {
**dst = **src;
-av_freep(src);
+FF_STATICPOOL_FREEP(AVBufferRef, src);
} else
-av_freep(dst);
+FF_STATICPOOL_FREEP(AVBufferRef, dst);
if (atomic_fetch_add_explicit(&b->refcount, -1, memory_order_acq_rel) ==
1) {
b->free(b->opaque, b->data);
-av_freep(&b);
+FF_STATICPOOL_FREEP(AVBuffer, &b);
}
}
@@ -262,7 +267,7 @@ static void buffer_pool_free(AVBufferPool *pool)
pool->pool = buf->next;
buf->free(buf->opaque, buf->data);
-av_freep(&buf);
+FF_STATICPOOL_FREEP(BufferPoolEntry, &buf);
}
ff_mutex_destroy(&pool->mutex);
@@ -314,7 +319,7 @@ static AVBufferRef *pool_alloc_buffer(AVBufferPool *pool)
if (!ret)
return NULL;
-buf = av_mallocz(sizeof(*buf));
+buf = FF_STATICPOOL_MALLOCZ(BufferPoolEntry);
if (!buf) {
av_buffer_unref(&ret);
return NULL;
--
2.13.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avutil/frame: use staticpool
Use default size 256.
Benchmark:
time ./ffmpeg -f s16le -ac 5 -ar 48000 -t 1 -i /dev/zero \
-af "aformat=s16p, asetnsamples=256" -f null -
old: 22.079s
new: 21.180s
Signed-off-by: Muhammad Faiz
---
libavutil/frame.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 662a7e5ab5..dd13d2b67b 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -25,8 +25,11 @@
#include "imgutils.h"
#include "mem.h"
#include "samplefmt.h"
+#include "staticpool.h"
+FF_STATICPOOL_DECLARE(AVFrame, 256)
+
static AVFrameSideData *frame_new_side_data(AVFrame *frame,
enum AVFrameSideDataType type,
AVBufferRef *buf);
@@ -149,7 +152,7 @@ static void wipe_side_data(AVFrame *frame)
AVFrame *av_frame_alloc(void)
{
-AVFrame *frame = av_mallocz(sizeof(*frame));
+AVFrame *frame = FF_STATICPOOL_MALLOCZ(AVFrame);
if (!frame)
return NULL;
@@ -166,7 +169,7 @@ void av_frame_free(AVFrame **frame)
return;
av_frame_unref(*frame);
-av_freep(frame);
+FF_STATICPOOL_FREEP(AVFrame, frame);
}
static int get_video_buffer(AVFrame *frame, int align)
--
2.13.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/hevc_parser: use ff_hevc_decode_extradata() to parse extradata
Signed-off-by: James Almer
---
libavcodec/hevc_parser.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index ff7e8a49d6..a3a9098c7c 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -24,6 +24,7 @@
#include "golomb.h"
#include "hevc.h"
+#include "hevc_parse.h"
#include "hevc_ps.h"
#include "hevc_sei.h"
#include "h2645_parse.h"
@@ -43,6 +44,8 @@ typedef struct HEVCParserContext {
HEVCSEI sei;
SliceHeader sh;
+int is_avc;
+int nal_length_size;
int parsed_extradata;
int poc;
@@ -181,7 +184,6 @@ static int parse_nal_units(AVCodecParserContext *s, const
uint8_t *buf,
HEVCParserContext *ctx = s->priv_data;
HEVCParamSets *ps = &ctx->ps;
HEVCSEI *sei = &ctx->sei;
-int is_global = buf == avctx->extradata;
int ret, i;
/* set some sane default values */
@@ -191,8 +193,8 @@ static int parse_nal_units(AVCodecParserContext *s, const
uint8_t *buf,
ff_hevc_reset_sei(sei);
-ret = ff_h2645_packet_split(&ctx->pkt, buf, buf_size, avctx, 0, 0,
-AV_CODEC_ID_HEVC, 1);
+ret = ff_h2645_packet_split(&ctx->pkt, buf, buf_size, avctx, ctx->is_avc,
+ctx->nal_length_size, AV_CODEC_ID_HEVC, 1);
if (ret < 0)
return ret;
@@ -230,12 +232,6 @@ static int parse_nal_units(AVCodecParserContext *s, const
uint8_t *buf,
case HEVC_NAL_RADL_R:
case HEVC_NAL_RASL_N:
case HEVC_NAL_RASL_R:
-
-if (is_global) {
-av_log(avctx, AV_LOG_ERROR, "Invalid NAL unit: %d\n",
nal->type);
-return AVERROR_INVALIDDATA;
-}
-
ret = hevc_parse_slice_header(s, nal, avctx);
if (ret)
return ret;
@@ -243,8 +239,7 @@ static int parse_nal_units(AVCodecParserContext *s, const
uint8_t *buf,
}
}
/* didn't find a picture! */
-if (!is_global)
-av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
+av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
return -1;
}
@@ -301,7 +296,9 @@ static int hevc_parse(AVCodecParserContext *s,
AVCodecContext *avctx,
ParseContext *pc = &ctx->pc;
if (avctx->extradata && !ctx->parsed_extradata) {
-parse_nal_units(s, avctx->extradata, avctx->extradata_size, avctx);
+ff_hevc_decode_extradata(buf, buf_size, &ctx->ps, &ctx->sei,
&ctx->is_avc,
+ &ctx->nal_length_size, avctx->err_recognition,
+ 1, avctx);
ctx->parsed_extradata = 1;
}
--
2.15.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/truemotion2: Fix integer overflow in TM2_RECALC_BLOCK()
Fixes: signed integer overflow: 1477974040 - -1877995504 cannot be represented
in type 'int'
Fixes: 4861/clusterfuzz-testcase-minimized-4570316383715328
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/truemotion2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/truemotion2.c b/libavcodec/truemotion2.c
index f077f0e4bd..97c38f7f08 100644
--- a/libavcodec/truemotion2.c
+++ b/libavcodec/truemotion2.c
@@ -441,8 +441,8 @@ static inline int GET_TOK(TM2Context *ctx,int type)
/* recalculate last and delta values for next blocks */
#define TM2_RECALC_BLOCK(CHR, stride, last, CD) {\
-CD[0] = CHR[1] - last[1];\
-CD[1] = (int)CHR[stride + 1] - (int)CHR[1];\
+CD[0] = (unsigned)CHR[ 1] - (unsigned)last[1];\
+CD[1] = (unsigned)CHR[stride + 1] - (unsigned) CHR[1];\
last[0] = (int)CHR[stride + 0];\
last[1] = (int)CHR[stride + 1];}
--
2.15.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix memory leak in lrcdec.c
2018-01-20 3:10 GMT+01:00 Michael Niedermayer : > On Sat, Jan 20, 2018 at 02:39:02AM +0100, Carl Eugen Hoyos wrote: >> 2018-01-20 1:57 GMT+01:00 Michael Niedermayer : >> > On Fri, Jan 19, 2018 at 01:17:07PM -0800, Nikolas Bowe wrote: >> >> --- >> >> libavformat/lrcdec.c | 1 + >> >> 1 file changed, 1 insertion(+) >> >> >> >> diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c >> >> index 12f74b22a0..f4e9a4efa9 100644 >> >> --- a/libavformat/lrcdec.c >> >> +++ b/libavformat/lrcdec.c >> >> @@ -212,6 +212,7 @@ static int lrc_read_header(AVFormatContext *s) >> >> } >> >> ff_subtitles_queue_finalize(s, &lrc->q); >> >> ff_metadata_conv_ctx(s, NULL, ff_lrc_metadata_conv); >> >> +av_bprint_finalize(&line, NULL); >> >> return 0; >> >> } >> > >> > How did you find this ? >> > >> > iam asking because ideally all fuzzing stuff should be run by >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> > while currently thats not the case and disk space restrictions >> >> > togther with "no shared libs allowed" and a few other things >> >> (Sorry if I misread this) >> Why is "no shared libs" an issue with FFmpeg? What I actually meant was: Is there a dependency for which static linking does not work... > its an issue for the oss fuzz testcases it seems. > all code is statically linked even libs which on a modern system > are linked as shared libs normally > dont ask me why. I very much would love to switch to shared linking > also i would be very happy to find out this is a misunderstanding > somehow and we can use shared linking ... > > that together with one binary per tested codec causes space issues > which should not come as much of a surprise. Duplicating libavcodec > for each test is not great. > On top of that fate samples are partly duplicated too > > also see: > https://github.com/google/oss-fuzz/issues/567 ... but thank you for this explanation! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Check that data is set
On 1/20/18 6:29 AM, Brendan McGrath wrote:
> If codecpar->extradata is not set (for example, when the stream goes
> through the 'tee' muxer), then a segfault occurs.
>
> This patch ensures the data variable is not null before attempting
> to access it
>
> Signed-off-by: Brendan McGrath
> ---
> Before the var_stream_map option was available - I was using the tee
> muxer to create each resolution as an individual stream.
>
> When running this configuration after the most recent hlsenc change
> I hit a segfault
>
> The most simple command which recreates the segfault is:
> ffmpeg -i in.ts -map 0:a -map 0:v -c:a aac -c:v h264 \
> -f tee [select=\'a,v\':f=hls]tv_hls_hd.m3u8
>
> libavformat/hlsenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 8ad906a..42e437f 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -308,7 +308,7 @@ static void write_codec_attr(AVStream *st, VariantStream
> *vs) {
>
> if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
> uint8_t *data = st->codecpar->extradata;
> -if ((data[0] | data[1] | data[2]) == 0 && data[3] == 1 && (data[4] &
> 0x1F) == 7) {
> +if (data && (data[0] | data[1] | data[2]) == 0 && data[3] == 1 &&
> (data[4] & 0x1F) == 7) {
> snprintf(attr, sizeof(attr),
> "avc1.%02x%02x%02x", data[5], data[6], data[7]);
> } else {
LGTM. Thanks for the fix.
Regards,
Kaarthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Fix integer overflow before htaps check
On Mon, Jan 15, 2018 at 03:27:16AM +0100, Michael Niedermayer wrote: > Fixes: runtime error: signed integer overflow: -1094995529 * 2 cannot be > represented in type 'int' > Fixes: 4828/clusterfuzz-testcase-minimized-5100849937252352 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/snowdec.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/swfdec: Reduce score when auto-detecting swf files
On Sat, Jan 20, 2018 at 02:36:08AM +0100, Carl Eugen Hoyos wrote: > 2018-01-19 23:42 GMT+01:00 Michael Niedermayer : > > On Fri, Jan 19, 2018 at 07:25:43PM +0100, Carl Eugen Hoyos wrote: > >> 2018-01-19 18:51 GMT+01:00 Michael Niedermayer : > >> > On Thu, Jan 18, 2018 at 09:28:40PM +0100, Carl Eugen Hoyos wrote: > >> >> Hi! > >> >> > >> >> The probe score for swf files (with uncompressed headers) is currently > >> >> very high after testing a little more than 24bit, attached patch > >> >> reduces the score. > >> > > >> > hmm > >> > the first 24 bits are tested and all but 2 values are rejected > >> > > >> > thats 23 bits that must match > >> > >> Ok. > >> > >> > then 4 values are tested which can be from 1 to 31 bits each > >> > the tests are each either == 0 or != 0 so they are a bit weak > >> > but its at least adding 4 bits that must match and also len > >> > >> I was sure this is not equivalent to four bits on a specific > >> position (but for the patch I assumed a "best case scenario" > >> where this actually were the case). > >> > >> > itself has to be smallish so we could argue that this gets us to > >> > about 28 bits > >> > >> > and then buf[3] is checked to be < 20 > >> > at this point we need about 32bits to be matching, still not huge but > >> > id think this is stronger than what file extensions prove which are > >> > MAX/2 > >> > >> We return MAX/2 for many "initial 32 bits" tests and I believe > >> we made good experience (and for MAX/2 the extension is > >> ignored or do I misremember?) > >> > > > >> > The test is weakened by using 0 / not 0 / ascii as values though > >> > > >> > Have you seen an actual probe failure ? > >> > >> No, I was looking at another issue. > > > > we have many files with wrong extensions, its not uncommon > > Yes, I misremembered how extensions are rated, I actually > wanted to set the return value to "AVPROBE_SCORE_EXTENSION + 1". > Would that be ok? yes thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix memory leak in lrcdec.c
On Sat, Jan 20, 2018 at 02:39:02AM +0100, Carl Eugen Hoyos wrote: > 2018-01-20 1:57 GMT+01:00 Michael Niedermayer : > > On Fri, Jan 19, 2018 at 01:17:07PM -0800, Nikolas Bowe wrote: > >> --- > >> libavformat/lrcdec.c | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c > >> index 12f74b22a0..f4e9a4efa9 100644 > >> --- a/libavformat/lrcdec.c > >> +++ b/libavformat/lrcdec.c > >> @@ -212,6 +212,7 @@ static int lrc_read_header(AVFormatContext *s) > >> } > >> ff_subtitles_queue_finalize(s, &lrc->q); > >> ff_metadata_conv_ctx(s, NULL, ff_lrc_metadata_conv); > >> +av_bprint_finalize(&line, NULL); > >> return 0; > >> } > > > > How did you find this ? > > > > iam asking because ideally all fuzzing stuff should be run by > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > while currently thats not the case and disk space restrictions > > > togther with "no shared libs allowed" and a few other things > > (Sorry if I misread this) > Why is "no shared libs" an issue with FFmpeg? its an issue for the oss fuzz testcases it seems. all code is statically linked even libs which on a modern system are linked as shared libs normally dont ask me why. I very much would love to switch to shared linking also i would be very happy to find out this is a misunderstanding somehow and we can use shared linking ... that together with one binary per tested codec causes space issues which should not come as much of a surprise. Duplicating libavcodec for each test is not great. On top of that fate samples are partly duplicated too also see: https://github.com/google/oss-fuzz/issues/567 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix memory leak in lrcdec.c
2018-01-20 1:57 GMT+01:00 Michael Niedermayer : > On Fri, Jan 19, 2018 at 01:17:07PM -0800, Nikolas Bowe wrote: >> --- >> libavformat/lrcdec.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c >> index 12f74b22a0..f4e9a4efa9 100644 >> --- a/libavformat/lrcdec.c >> +++ b/libavformat/lrcdec.c >> @@ -212,6 +212,7 @@ static int lrc_read_header(AVFormatContext *s) >> } >> ff_subtitles_queue_finalize(s, &lrc->q); >> ff_metadata_conv_ctx(s, NULL, ff_lrc_metadata_conv); >> +av_bprint_finalize(&line, NULL); >> return 0; >> } > > How did you find this ? > > iam asking because ideally all fuzzing stuff should be run by > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > while currently thats not the case and disk space restrictions > togther with "no shared libs allowed" and a few other things (Sorry if I misread this) Why is "no shared libs" an issue with FFmpeg? > like one seperate tool for each test make it hard to extend it. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/swfdec: Reduce score when auto-detecting swf files
2018-01-19 23:42 GMT+01:00 Michael Niedermayer : > On Fri, Jan 19, 2018 at 07:25:43PM +0100, Carl Eugen Hoyos wrote: >> 2018-01-19 18:51 GMT+01:00 Michael Niedermayer : >> > On Thu, Jan 18, 2018 at 09:28:40PM +0100, Carl Eugen Hoyos wrote: >> >> Hi! >> >> >> >> The probe score for swf files (with uncompressed headers) is currently >> >> very high after testing a little more than 24bit, attached patch >> >> reduces the score. >> > >> > hmm >> > the first 24 bits are tested and all but 2 values are rejected >> > >> > thats 23 bits that must match >> >> Ok. >> >> > then 4 values are tested which can be from 1 to 31 bits each >> > the tests are each either == 0 or != 0 so they are a bit weak >> > but its at least adding 4 bits that must match and also len >> >> I was sure this is not equivalent to four bits on a specific >> position (but for the patch I assumed a "best case scenario" >> where this actually were the case). >> >> > itself has to be smallish so we could argue that this gets us to >> > about 28 bits >> >> > and then buf[3] is checked to be < 20 >> > at this point we need about 32bits to be matching, still not huge but >> > id think this is stronger than what file extensions prove which are >> > MAX/2 >> >> We return MAX/2 for many "initial 32 bits" tests and I believe >> we made good experience (and for MAX/2 the extension is >> ignored or do I misremember?) >> > >> > The test is weakened by using 0 / not 0 / ascii as values though >> > >> > Have you seen an actual probe failure ? >> >> No, I was looking at another issue. > > we have many files with wrong extensions, its not uncommon Yes, I misremembered how extensions are rated, I actually wanted to set the return value to "AVPROBE_SCORE_EXTENSION + 1". Would that be ok? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2] dashdec: Only free url string if being reused
If no representation bandwidth value is set, the url value returned
by get_content_url is corrupt (as it has been freed).
This change ensures the url string is not freed unless it is about
to be reused
Signed-off-by: Brendan McGrath
---
Changes since v1:
- removed the unneeded 'if' statement (as pointed out by Michael Niedermayer
- added comment to make it clear why the av_free was required
libavformat/dashdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 2492f1d..6380318 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -482,9 +482,10 @@ static char *get_content_url(xmlNodePtr *baseurl_nodes,
return NULL;
}
av_strlcpy(tmp_str, url, sizeof(tmp_str));
-av_free(url);
}
if (rep_bandwidth_val && tmp_str[0] != '\0') {
+// free any previously assigned url before reassigning
+av_free(url);
url = av_strireplace(tmp_str, "$Bandwidth$", (const
char*)rep_bandwidth_val);
if (!url) {
return NULL;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp9_parser: parse size and colorspace values from frame headers
On 1/19/2018 9:36 PM, Michael Niedermayer wrote:
> On Fri, Jan 19, 2018 at 09:33:46PM -0300, James Almer wrote:
>> On 1/19/2018 8:56 PM, Michael Niedermayer wrote:
>>> On Fri, Jan 19, 2018 at 12:51:21AM -0300, James Almer wrote:
Improves remuxing support when vp9 decoder is not compiled in.
Signed-off-by: James Almer
---
libavcodec/vp9_parser.c | 98
-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
index 9531f34a32..b059477747 100644
--- a/libavcodec/vp9_parser.c
+++ b/libavcodec/vp9_parser.c
@@ -23,15 +23,69 @@
#include "libavutil/intreadwrite.h"
#include "libavcodec/get_bits.h"
+#include "libavcodec/internal.h"
#include "parser.h"
+#define VP9_SYNCCODE 0x498342
+
+static int read_colorspace_details(AVCodecParserContext *ctx,
AVCodecContext *avctx,
+ GetBitContext *gb)
+{
+static const enum AVColorSpace colorspaces[8] = {
+AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
AVCOL_SPC_SMPTE170M,
+AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
AVCOL_SPC_RGB,
+};
+int bits = avctx->profile <= 1 ? 0 : 1 + get_bits1(gb); // 0:8, 1:10,
2:12
+
+avctx->colorspace = colorspaces[get_bits(gb, 3)];
+if (avctx->colorspace == AVCOL_SPC_RGB) { // RGB = profile 1
+static const enum AVPixelFormat pix_fmt_rgb[3] = {
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
+};
+if (avctx->profile & 1) {
+if (get_bits1(gb)) // reserved bit
+return AVERROR_INVALIDDATA;
+} else
+return AVERROR_INVALIDDATA;
+avctx->color_range = AVCOL_RANGE_JPEG;
+ctx->format = pix_fmt_rgb[bits];
+} else {
+static const enum AVPixelFormat pix_fmt_for_ss[3][2 /* v */][2 /*
h */] = {
+{ { AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P },
+ { AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV420P } },
+{ { AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10 },
+ { AV_PIX_FMT_YUV440P10, AV_PIX_FMT_YUV420P10 } },
+{ { AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12 },
+ { AV_PIX_FMT_YUV440P12, AV_PIX_FMT_YUV420P12 } }
+};
+avctx->color_range = get_bits1(gb) ? AVCOL_RANGE_JPEG :
AVCOL_RANGE_MPEG;
+if (avctx->profile & 1) {
+int ss_h, ss_v, format;
+
+ss_h = get_bits1(gb);
+ss_v = get_bits1(gb);
+format = pix_fmt_for_ss[bits][ss_v][ss_h];
+if (format == AV_PIX_FMT_YUV420P)
+// YUV 4:2:0 not supported in profiles 1 and 3
+return AVERROR_INVALIDDATA;
+else if (get_bits1(gb)) // color details reserved bit
+return AVERROR_INVALIDDATA;
+ctx->format = format;
+} else {
+ctx->format = pix_fmt_for_ss[bits][1][1];
+}
+}
+
+return 0;
+}
+
static int parse(AVCodecParserContext *ctx,
AVCodecContext *avctx,
const uint8_t **out_data, int *out_size,
const uint8_t *data, int size)
{
GetBitContext gb;
-int res, profile, keyframe;
+int res, profile, keyframe, invisible, errorres;
*out_data = data;
*out_size = size;
@@ -42,21 +96,63 @@ static int parse(AVCodecParserContext *ctx,
profile = get_bits1(&gb);
profile |= get_bits1(&gb) << 1;
if (profile == 3) profile += get_bits1(&gb);
+if (profile > 3)
+return size;
if (get_bits1(&gb)) {
keyframe = 0;
+skip_bits(&gb, 3);
} else {
keyframe = !get_bits1(&gb);
}
+invisible = !get_bits1(&gb);
+errorres = get_bits1(&gb);
+
if (!keyframe) {
+int intraonly = invisible ? get_bits1(&gb) : 0;
+if (!errorres)
+skip_bits(&gb, 2);
+if (intraonly) {
+if (get_bits_long(&gb, 24) != VP9_SYNCCODE) // synccode
+return size;
+avctx->profile = profile;
+if (profile >= 1) {
+if ((read_colorspace_details(ctx, avctx, &gb)) < 0)
+return size;
+} else {
+ctx->format= AV_PIX_FMT_YUV420P;
+avctx->colorspace = AVCOL_SPC_BT470BG;
+avctx->color_range = A
Re: [FFmpeg-devel] [PATCH] avfilter/drawtext - implement fix_bounds
On Fri, Jan 19, 2018 at 03:46:57PM -0800, Kyle Swanson wrote: > Hi, > > > > > Ping. Unless text needs to be rescaled as well, this patch is ready for > > review. > > > > > > Regards, > > Gyan > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > LGTM as-is. I'll push this sometime in the next 24 hours unless > someone else has anything to add. nothing to add, just wanted to test & push myself but as i saw your mail and my todo is long i gladly leave that to you :) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hlsenc: Check that data is set
If codecpar->extradata is not set (for example, when the stream goes
through the 'tee' muxer), then a segfault occurs.
This patch ensures the data variable is not null before attempting
to access it
Signed-off-by: Brendan McGrath
---
Before the var_stream_map option was available - I was using the tee
muxer to create each resolution as an individual stream.
When running this configuration after the most recent hlsenc change
I hit a segfault
The most simple command which recreates the segfault is:
ffmpeg -i in.ts -map 0:a -map 0:v -c:a aac -c:v h264 \
-f tee [select=\'a,v\':f=hls]tv_hls_hd.m3u8
libavformat/hlsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 8ad906a..42e437f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -308,7 +308,7 @@ static void write_codec_attr(AVStream *st, VariantStream
*vs) {
if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
uint8_t *data = st->codecpar->extradata;
-if ((data[0] | data[1] | data[2]) == 0 && data[3] == 1 && (data[4] &
0x1F) == 7) {
+if (data && (data[0] | data[1] | data[2]) == 0 && data[3] == 1 &&
(data[4] & 0x1F) == 7) {
snprintf(attr, sizeof(attr),
"avc1.%02x%02x%02x", data[5], data[6], data[7]);
} else {
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix memory leak in lrcdec.c
On Fri, Jan 19, 2018 at 01:17:07PM -0800, Nikolas Bowe wrote: > --- > libavformat/lrcdec.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c > index 12f74b22a0..f4e9a4efa9 100644 > --- a/libavformat/lrcdec.c > +++ b/libavformat/lrcdec.c > @@ -212,6 +212,7 @@ static int lrc_read_header(AVFormatContext *s) > } > ff_subtitles_queue_finalize(s, &lrc->q); > ff_metadata_conv_ctx(s, NULL, ff_lrc_metadata_conv); > +av_bprint_finalize(&line, NULL); > return 0; > } How did you find this ? iam asking because ideally all fuzzing stuff should be run by https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg while currently thats not the case and disk space restrictions togther with "no shared libs allowed" and a few other things like one seperate tool for each test make it hard to extend it. None the less, if some restriction could be lifted or some other thing could be done to run more complete fuzzing in FFmpeg oss-fuzz that would be great. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix signed integer overflow undefined behavior
On Fri, Jan 19, 2018 at 03:56:19PM -0800, Niki Bowe wrote: > On Fri, Jan 19, 2018 at 3:00 PM, Michael Niedermayer > wrote: > > > On Fri, Jan 19, 2018 at 02:48:08PM -0800, Nikolas Bowe wrote: > > > Found via fuzzing > > > --- > > > libavformat/rpl.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/libavformat/rpl.c b/libavformat/rpl.c > > > index d373600478..df449bfc29 100644 > > > --- a/libavformat/rpl.c > > > +++ b/libavformat/rpl.c > > > @@ -194,7 +194,7 @@ static int rpl_read_header(AVFormatContext *s) > > > if (ast->codecpar->bits_per_coded_sample == 0) > > > ast->codecpar->bits_per_coded_sample = 4; > > > > > > -ast->codecpar->bit_rate = ast->codecpar->sample_rate * > > > +ast->codecpar->bit_rate = (uint64_t)ast->codecpar->sample_rate > > * > > >ast->codecpar->bits_per_coded_sample > > * > > >ast->codecpar->channels; > > > > uint64_t is the wrong type, bit_rate is int64_t > > > > > That is true, but wouldn't fix the overflow > signed int64_t can still overflow eg if sample_rate, bits_per_coded_sample, > and channels are all INT_MAX. > By using uint64_t, the overflow is at least defined behavior. > > It might be better to range check these values, but I could not find a > comprehensive spec. > I could use reasonably lenient values of say 384 khz and 32 bits per coded > sample. > Would you prefer that? correct range checks would be ideal. if that is not possible then at least bit_rate should not be set "randomly" in case of an overflow thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3 4/4] avfilter/vf_framerate: add SIMD functions for frame blending
Blend function speedups on x86_64 Core i5 4460:
ffmpeg -f lavfi -i allyuv -vf framerate=60:threads=1 -f null none
C: 447548411 decicycles in Blend,2048 runs, 0 skips
SSSE3: 130020087 decicycles in Blend,2048 runs, 0 skips
AVX2: 128508221 decicycles in Blend,2048 runs, 0 skips
ffmpeg -f lavfi -i allyuv -vf format=yuv420p12,framerate=60:threads=1 -f null
none
C: 228932745 decicycles in Blend,2048 runs, 0 skips
SSE4: 123357781 decicycles in Blend,2048 runs, 0 skips
AVX2: 121215353 decicycles in Blend,2048 runs, 0 skips
Signed-off-by: Marton Balint
---
libavfilter/framerate.h | 74
libavfilter/vf_framerate.c | 70 +--
libavfilter/x86/Makefile| 2 +
libavfilter/x86/vf_framerate.asm| 134
libavfilter/x86/vf_framerate_init.c | 43
5 files changed, 269 insertions(+), 54 deletions(-)
create mode 100644 libavfilter/framerate.h
create mode 100644 libavfilter/x86/vf_framerate.asm
create mode 100644 libavfilter/x86/vf_framerate_init.c
diff --git a/libavfilter/framerate.h b/libavfilter/framerate.h
new file mode 100644
index 00..d6b6f5f649
--- /dev/null
+++ b/libavfilter/framerate.h
@@ -0,0 +1,74 @@
+/*
+ * 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_FRAMERATE_H
+#define AVFILTER_FRAMERATE_H
+
+#include "libavutil/pixelutils.h"
+#include "avfilter.h"
+
+#define BLEND_FUNC_PARAMS const uint8_t *src1, ptrdiff_t src1_linesize, \
+ const uint8_t *src2, ptrdiff_t src2_linesize, \
+ uint8_t *dst, ptrdiff_t dst_linesize, \
+ ptrdiff_t width, ptrdiff_t height, \
+ int factor1, int factor2, int half
+
+#define BLEND_FACTOR_DEPTH8 7
+#define BLEND_FACTOR_DEPTH16 15
+
+typedef void (*blend_func)(BLEND_FUNC_PARAMS);
+
+typedef struct FrameRateContext {
+const AVClass *class;
+// parameters
+AVRational dest_frame_rate; ///< output frames per second
+int flags; ///< flags affecting frame rate
conversion algorithm
+double scene_score; ///< score that denotes a scene change
has happened
+int interp_start; ///< start of range to apply linear
interpolation
+int interp_end; ///< end of range to apply linear
interpolation
+
+int line_size[4]; ///< bytes of pixel data per line for
each plane
+int vsub;
+
+AVRational srce_time_base; ///< timebase of source
+AVRational dest_time_base; ///< timebase of destination
+
+av_pixelutils_sad_fn sad; ///< Sum of the absolute difference
function (scene detect only)
+double prev_mafd; ///< previous MAFD
(scene detect only)
+
+int blend_factor_max;
+int bitdepth;
+AVFrame *work;
+
+AVFrame *f0;///< last frame
+AVFrame *f1;///< current frame
+int64_t pts0; ///< last frame pts in dest_time_base
+int64_t pts1; ///< current frame pts in
dest_time_base
+int64_t delta; ///< pts1 to pts0 delta
+double score; ///< scene change score (f0 to f1)
+int flush; ///< 1 if the filter is being flushed
+int64_t start_pts; ///< pts of the first output frame
+int64_t n; ///< output frame counter
+
+blend_func blend;
+} FrameRateContext;
+
+void ff_framerate_init(FrameRateContext *s);
+void ff_framerate_init_x86(FrameRateContext *s);
+
+#endif /* AVFILTER_BLEND_H */
diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index d315ef5d09..a1684e1b15 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@@ -38,52 +38,7 @@
#include "avfilter.h"
#include "internal.h"
#include "video.h"
-
-#define BLEND_FUNC_PARAMS const uint8_t *src1, ptrdiff_t src1_linesize, \
- const uint8_t *src2, ptrdiff_t src2_linesize, \
- uint8_t
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mlp_parser: don't try to combine frames when full frames are provided
On Fri, Jan 19, 2018 at 08:30:59PM -0300, James Almer wrote:
> On 1/19/2018 5:06 PM, wm4 wrote:
> > On Fri, 19 Jan 2018 16:51:45 -0300
> > James Almer wrote:
> >
> >> Attempting full frame reconstruction is unnecessary for containers
> >> like Matroska, so just skip it altogether.
> >>
> >> Signed-off-by: James Almer
> >> ---
> >> libavcodec/mlp_parser.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
> >> index 3c0330f777..4827354f18 100644
> >> --- a/libavcodec/mlp_parser.c
> >> +++ b/libavcodec/mlp_parser.c
> >> @@ -256,6 +256,9 @@ static int mlp_parse(AVCodecParserContext *s,
> >> if (buf_size == 0)
> >> return 0;
> >>
> >> +if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
> >> +next = buf_size;
> >> +} else {
> >> if (!mp->in_sync) {
> >> // Not in sync - find a major sync header
> >>
> >> @@ -315,6 +318,7 @@ static int mlp_parse(AVCodecParserContext *s,
> >> }
> >>
> >> mp->bytes_left = 0;
> >> +}
> >>
> >> sync_present = (AV_RB32(buf + 4) & 0xfffe) == 0xf8726fba;
> >>
> >
> > Not so sure about this. I think some mkv TrueHD files contain packets
> > that are not properly starting on frame boundaries. But I don't really
> > remember.
>
> As in badly muxed files? Couldn't the same thing happen with any other
> codec? We're not bothering to consider such cases in other parses as far
> as i could see.
I agree, also IIRC we generally put workarounds for this kind of thing in
demuxers. there both demmuxer and codec is known
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp9_parser: parse size and colorspace values from frame headers
On Fri, Jan 19, 2018 at 09:33:46PM -0300, James Almer wrote:
> On 1/19/2018 8:56 PM, Michael Niedermayer wrote:
> > On Fri, Jan 19, 2018 at 12:51:21AM -0300, James Almer wrote:
> >> Improves remuxing support when vp9 decoder is not compiled in.
> >>
> >> Signed-off-by: James Almer
> >> ---
> >> libavcodec/vp9_parser.c | 98
> >> -
> >> 1 file changed, 97 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
> >> index 9531f34a32..b059477747 100644
> >> --- a/libavcodec/vp9_parser.c
> >> +++ b/libavcodec/vp9_parser.c
> >> @@ -23,15 +23,69 @@
> >>
> >> #include "libavutil/intreadwrite.h"
> >> #include "libavcodec/get_bits.h"
> >> +#include "libavcodec/internal.h"
> >> #include "parser.h"
> >>
> >> +#define VP9_SYNCCODE 0x498342
> >> +
> >> +static int read_colorspace_details(AVCodecParserContext *ctx,
> >> AVCodecContext *avctx,
> >> + GetBitContext *gb)
> >> +{
> >> +static const enum AVColorSpace colorspaces[8] = {
> >> +AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
> >> AVCOL_SPC_SMPTE170M,
> >> +AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
> >> AVCOL_SPC_RGB,
> >> +};
> >> +int bits = avctx->profile <= 1 ? 0 : 1 + get_bits1(gb); // 0:8, 1:10,
> >> 2:12
> >> +
> >> +avctx->colorspace = colorspaces[get_bits(gb, 3)];
> >> +if (avctx->colorspace == AVCOL_SPC_RGB) { // RGB = profile 1
> >> +static const enum AVPixelFormat pix_fmt_rgb[3] = {
> >> +AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
> >> +};
> >> +if (avctx->profile & 1) {
> >> +if (get_bits1(gb)) // reserved bit
> >> +return AVERROR_INVALIDDATA;
> >> +} else
> >> +return AVERROR_INVALIDDATA;
> >> +avctx->color_range = AVCOL_RANGE_JPEG;
> >> +ctx->format = pix_fmt_rgb[bits];
> >> +} else {
> >> +static const enum AVPixelFormat pix_fmt_for_ss[3][2 /* v */][2 /*
> >> h */] = {
> >> +{ { AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P },
> >> + { AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV420P } },
> >> +{ { AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10 },
> >> + { AV_PIX_FMT_YUV440P10, AV_PIX_FMT_YUV420P10 } },
> >> +{ { AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12 },
> >> + { AV_PIX_FMT_YUV440P12, AV_PIX_FMT_YUV420P12 } }
> >> +};
> >> +avctx->color_range = get_bits1(gb) ? AVCOL_RANGE_JPEG :
> >> AVCOL_RANGE_MPEG;
> >> +if (avctx->profile & 1) {
> >> +int ss_h, ss_v, format;
> >> +
> >> +ss_h = get_bits1(gb);
> >> +ss_v = get_bits1(gb);
> >> +format = pix_fmt_for_ss[bits][ss_v][ss_h];
> >> +if (format == AV_PIX_FMT_YUV420P)
> >> +// YUV 4:2:0 not supported in profiles 1 and 3
> >> +return AVERROR_INVALIDDATA;
> >> +else if (get_bits1(gb)) // color details reserved bit
> >> +return AVERROR_INVALIDDATA;
> >> +ctx->format = format;
> >> +} else {
> >> +ctx->format = pix_fmt_for_ss[bits][1][1];
> >> +}
> >> +}
> >> +
> >> +return 0;
> >> +}
> >> +
> >> static int parse(AVCodecParserContext *ctx,
> >> AVCodecContext *avctx,
> >> const uint8_t **out_data, int *out_size,
> >> const uint8_t *data, int size)
> >> {
> >> GetBitContext gb;
> >> -int res, profile, keyframe;
> >> +int res, profile, keyframe, invisible, errorres;
> >>
> >> *out_data = data;
> >> *out_size = size;
> >> @@ -42,21 +96,63 @@ static int parse(AVCodecParserContext *ctx,
> >> profile = get_bits1(&gb);
> >> profile |= get_bits1(&gb) << 1;
> >> if (profile == 3) profile += get_bits1(&gb);
> >> +if (profile > 3)
> >> +return size;
> >>
> >> if (get_bits1(&gb)) {
> >> keyframe = 0;
> >> +skip_bits(&gb, 3);
> >> } else {
> >> keyframe = !get_bits1(&gb);
> >> }
> >>
> >> +invisible = !get_bits1(&gb);
> >> +errorres = get_bits1(&gb);
> >> +
> >> if (!keyframe) {
> >> +int intraonly = invisible ? get_bits1(&gb) : 0;
> >> +if (!errorres)
> >> +skip_bits(&gb, 2);
> >> +if (intraonly) {
> >> +if (get_bits_long(&gb, 24) != VP9_SYNCCODE) // synccode
> >> +return size;
> >> +avctx->profile = profile;
> >> +if (profile >= 1) {
> >> +if ((read_colorspace_details(ctx, avctx, &gb)) < 0)
> >> +return size;
> >> +} else {
> >> +ctx->format= AV_PIX_FMT_YUV420P;
> >> +avctx->colorspace = AVCOL_SPC_BT470BG;
> >> +avctx->color_range = AVCOL_RANGE_MPEG;
> >> +}
> >> +
Re: [FFmpeg-devel] [PATCH] avcodec/vp9_parser: parse size and colorspace values from frame headers
On 1/19/2018 8:56 PM, Michael Niedermayer wrote:
> On Fri, Jan 19, 2018 at 12:51:21AM -0300, James Almer wrote:
>> Improves remuxing support when vp9 decoder is not compiled in.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/vp9_parser.c | 98
>> -
>> 1 file changed, 97 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
>> index 9531f34a32..b059477747 100644
>> --- a/libavcodec/vp9_parser.c
>> +++ b/libavcodec/vp9_parser.c
>> @@ -23,15 +23,69 @@
>>
>> #include "libavutil/intreadwrite.h"
>> #include "libavcodec/get_bits.h"
>> +#include "libavcodec/internal.h"
>> #include "parser.h"
>>
>> +#define VP9_SYNCCODE 0x498342
>> +
>> +static int read_colorspace_details(AVCodecParserContext *ctx,
>> AVCodecContext *avctx,
>> + GetBitContext *gb)
>> +{
>> +static const enum AVColorSpace colorspaces[8] = {
>> +AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
>> AVCOL_SPC_SMPTE170M,
>> +AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
>> AVCOL_SPC_RGB,
>> +};
>> +int bits = avctx->profile <= 1 ? 0 : 1 + get_bits1(gb); // 0:8, 1:10,
>> 2:12
>> +
>> +avctx->colorspace = colorspaces[get_bits(gb, 3)];
>> +if (avctx->colorspace == AVCOL_SPC_RGB) { // RGB = profile 1
>> +static const enum AVPixelFormat pix_fmt_rgb[3] = {
>> +AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
>> +};
>> +if (avctx->profile & 1) {
>> +if (get_bits1(gb)) // reserved bit
>> +return AVERROR_INVALIDDATA;
>> +} else
>> +return AVERROR_INVALIDDATA;
>> +avctx->color_range = AVCOL_RANGE_JPEG;
>> +ctx->format = pix_fmt_rgb[bits];
>> +} else {
>> +static const enum AVPixelFormat pix_fmt_for_ss[3][2 /* v */][2 /* h
>> */] = {
>> +{ { AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P },
>> + { AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV420P } },
>> +{ { AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10 },
>> + { AV_PIX_FMT_YUV440P10, AV_PIX_FMT_YUV420P10 } },
>> +{ { AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12 },
>> + { AV_PIX_FMT_YUV440P12, AV_PIX_FMT_YUV420P12 } }
>> +};
>> +avctx->color_range = get_bits1(gb) ? AVCOL_RANGE_JPEG :
>> AVCOL_RANGE_MPEG;
>> +if (avctx->profile & 1) {
>> +int ss_h, ss_v, format;
>> +
>> +ss_h = get_bits1(gb);
>> +ss_v = get_bits1(gb);
>> +format = pix_fmt_for_ss[bits][ss_v][ss_h];
>> +if (format == AV_PIX_FMT_YUV420P)
>> +// YUV 4:2:0 not supported in profiles 1 and 3
>> +return AVERROR_INVALIDDATA;
>> +else if (get_bits1(gb)) // color details reserved bit
>> +return AVERROR_INVALIDDATA;
>> +ctx->format = format;
>> +} else {
>> +ctx->format = pix_fmt_for_ss[bits][1][1];
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> static int parse(AVCodecParserContext *ctx,
>> AVCodecContext *avctx,
>> const uint8_t **out_data, int *out_size,
>> const uint8_t *data, int size)
>> {
>> GetBitContext gb;
>> -int res, profile, keyframe;
>> +int res, profile, keyframe, invisible, errorres;
>>
>> *out_data = data;
>> *out_size = size;
>> @@ -42,21 +96,63 @@ static int parse(AVCodecParserContext *ctx,
>> profile = get_bits1(&gb);
>> profile |= get_bits1(&gb) << 1;
>> if (profile == 3) profile += get_bits1(&gb);
>> +if (profile > 3)
>> +return size;
>>
>> if (get_bits1(&gb)) {
>> keyframe = 0;
>> +skip_bits(&gb, 3);
>> } else {
>> keyframe = !get_bits1(&gb);
>> }
>>
>> +invisible = !get_bits1(&gb);
>> +errorres = get_bits1(&gb);
>> +
>> if (!keyframe) {
>> +int intraonly = invisible ? get_bits1(&gb) : 0;
>> +if (!errorres)
>> +skip_bits(&gb, 2);
>> +if (intraonly) {
>> +if (get_bits_long(&gb, 24) != VP9_SYNCCODE) // synccode
>> +return size;
>> +avctx->profile = profile;
>> +if (profile >= 1) {
>> +if ((read_colorspace_details(ctx, avctx, &gb)) < 0)
>> +return size;
>> +} else {
>> +ctx->format= AV_PIX_FMT_YUV420P;
>> +avctx->colorspace = AVCOL_SPC_BT470BG;
>> +avctx->color_range = AVCOL_RANGE_MPEG;
>> +}
>> +skip_bits(&gb, 8); // refreshrefmask
>> +ctx->width = get_bits(&gb, 16) + 1;
>> +ctx->height = get_bits(&gb, 16) + 1;
>> +if (get_bits1(&gb)) // display size
>> +skip_bits(&gb, 32);
>> +}
>> +
>> ctx->pict_type = AV_PICTURE_TYPE_P;
>>
Re: [FFmpeg-devel] [PATCH] Fix signed integer overflow undefined behavior
On Fri, Jan 19, 2018 at 3:00 PM, Michael Niedermayer wrote: > On Fri, Jan 19, 2018 at 02:48:08PM -0800, Nikolas Bowe wrote: > > Found via fuzzing > > --- > > libavformat/rpl.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavformat/rpl.c b/libavformat/rpl.c > > index d373600478..df449bfc29 100644 > > --- a/libavformat/rpl.c > > +++ b/libavformat/rpl.c > > @@ -194,7 +194,7 @@ static int rpl_read_header(AVFormatContext *s) > > if (ast->codecpar->bits_per_coded_sample == 0) > > ast->codecpar->bits_per_coded_sample = 4; > > > > -ast->codecpar->bit_rate = ast->codecpar->sample_rate * > > +ast->codecpar->bit_rate = (uint64_t)ast->codecpar->sample_rate > * > >ast->codecpar->bits_per_coded_sample > * > >ast->codecpar->channels; > > uint64_t is the wrong type, bit_rate is int64_t > > That is true, but wouldn't fix the overflow signed int64_t can still overflow eg if sample_rate, bits_per_coded_sample, and channels are all INT_MAX. By using uint64_t, the overflow is at least defined behavior. It might be better to range check these values, but I could not find a comprehensive spec. I could use reasonably lenient values of say 384 khz and 32 bits per coded sample. Would you prefer that? > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I know you won't believe me, but the highest form of Human Excellence is > to question oneself and others. -- Socrates > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > -- Nikolas Bowe | SWE | nb...@google.com | 408-565-5137 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp9_parser: parse size and colorspace values from frame headers
On Fri, Jan 19, 2018 at 12:51:21AM -0300, James Almer wrote:
> Improves remuxing support when vp9 decoder is not compiled in.
>
> Signed-off-by: James Almer
> ---
> libavcodec/vp9_parser.c | 98
> -
> 1 file changed, 97 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
> index 9531f34a32..b059477747 100644
> --- a/libavcodec/vp9_parser.c
> +++ b/libavcodec/vp9_parser.c
> @@ -23,15 +23,69 @@
>
> #include "libavutil/intreadwrite.h"
> #include "libavcodec/get_bits.h"
> +#include "libavcodec/internal.h"
> #include "parser.h"
>
> +#define VP9_SYNCCODE 0x498342
> +
> +static int read_colorspace_details(AVCodecParserContext *ctx, AVCodecContext
> *avctx,
> + GetBitContext *gb)
> +{
> +static const enum AVColorSpace colorspaces[8] = {
> +AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
> AVCOL_SPC_SMPTE170M,
> +AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
> AVCOL_SPC_RGB,
> +};
> +int bits = avctx->profile <= 1 ? 0 : 1 + get_bits1(gb); // 0:8, 1:10,
> 2:12
> +
> +avctx->colorspace = colorspaces[get_bits(gb, 3)];
> +if (avctx->colorspace == AVCOL_SPC_RGB) { // RGB = profile 1
> +static const enum AVPixelFormat pix_fmt_rgb[3] = {
> +AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
> +};
> +if (avctx->profile & 1) {
> +if (get_bits1(gb)) // reserved bit
> +return AVERROR_INVALIDDATA;
> +} else
> +return AVERROR_INVALIDDATA;
> +avctx->color_range = AVCOL_RANGE_JPEG;
> +ctx->format = pix_fmt_rgb[bits];
> +} else {
> +static const enum AVPixelFormat pix_fmt_for_ss[3][2 /* v */][2 /* h
> */] = {
> +{ { AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P },
> + { AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV420P } },
> +{ { AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10 },
> + { AV_PIX_FMT_YUV440P10, AV_PIX_FMT_YUV420P10 } },
> +{ { AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12 },
> + { AV_PIX_FMT_YUV440P12, AV_PIX_FMT_YUV420P12 } }
> +};
> +avctx->color_range = get_bits1(gb) ? AVCOL_RANGE_JPEG :
> AVCOL_RANGE_MPEG;
> +if (avctx->profile & 1) {
> +int ss_h, ss_v, format;
> +
> +ss_h = get_bits1(gb);
> +ss_v = get_bits1(gb);
> +format = pix_fmt_for_ss[bits][ss_v][ss_h];
> +if (format == AV_PIX_FMT_YUV420P)
> +// YUV 4:2:0 not supported in profiles 1 and 3
> +return AVERROR_INVALIDDATA;
> +else if (get_bits1(gb)) // color details reserved bit
> +return AVERROR_INVALIDDATA;
> +ctx->format = format;
> +} else {
> +ctx->format = pix_fmt_for_ss[bits][1][1];
> +}
> +}
> +
> +return 0;
> +}
> +
> static int parse(AVCodecParserContext *ctx,
> AVCodecContext *avctx,
> const uint8_t **out_data, int *out_size,
> const uint8_t *data, int size)
> {
> GetBitContext gb;
> -int res, profile, keyframe;
> +int res, profile, keyframe, invisible, errorres;
>
> *out_data = data;
> *out_size = size;
> @@ -42,21 +96,63 @@ static int parse(AVCodecParserContext *ctx,
> profile = get_bits1(&gb);
> profile |= get_bits1(&gb) << 1;
> if (profile == 3) profile += get_bits1(&gb);
> +if (profile > 3)
> +return size;
>
> if (get_bits1(&gb)) {
> keyframe = 0;
> +skip_bits(&gb, 3);
> } else {
> keyframe = !get_bits1(&gb);
> }
>
> +invisible = !get_bits1(&gb);
> +errorres = get_bits1(&gb);
> +
> if (!keyframe) {
> +int intraonly = invisible ? get_bits1(&gb) : 0;
> +if (!errorres)
> +skip_bits(&gb, 2);
> +if (intraonly) {
> +if (get_bits_long(&gb, 24) != VP9_SYNCCODE) // synccode
> +return size;
> +avctx->profile = profile;
> +if (profile >= 1) {
> +if ((read_colorspace_details(ctx, avctx, &gb)) < 0)
> +return size;
> +} else {
> +ctx->format= AV_PIX_FMT_YUV420P;
> +avctx->colorspace = AVCOL_SPC_BT470BG;
> +avctx->color_range = AVCOL_RANGE_MPEG;
> +}
> +skip_bits(&gb, 8); // refreshrefmask
> +ctx->width = get_bits(&gb, 16) + 1;
> +ctx->height = get_bits(&gb, 16) + 1;
> +if (get_bits1(&gb)) // display size
> +skip_bits(&gb, 32);
> +}
> +
> ctx->pict_type = AV_PICTURE_TYPE_P;
> ctx->key_frame = 0;
> } else {
> +if (get_bits_long(&gb, 24) != VP9_SYNCCODE) // synccode
> +return size;
> +avctx->profile = profile;
> +
Re: [FFmpeg-devel] [PATCH] avfilter/drawtext - implement fix_bounds
Hi, > > Ping. Unless text needs to be rescaled as well, this patch is ready for > review. > > > Regards, > Gyan > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel LGTM as-is. I'll push this sometime in the next 24 hours unless someone else has anything to add. Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mlp_parser: don't try to combine frames when full frames are provided
On 1/19/2018 5:06 PM, wm4 wrote:
> On Fri, 19 Jan 2018 16:51:45 -0300
> James Almer wrote:
>
>> Attempting full frame reconstruction is unnecessary for containers
>> like Matroska, so just skip it altogether.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/mlp_parser.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
>> index 3c0330f777..4827354f18 100644
>> --- a/libavcodec/mlp_parser.c
>> +++ b/libavcodec/mlp_parser.c
>> @@ -256,6 +256,9 @@ static int mlp_parse(AVCodecParserContext *s,
>> if (buf_size == 0)
>> return 0;
>>
>> +if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
>> +next = buf_size;
>> +} else {
>> if (!mp->in_sync) {
>> // Not in sync - find a major sync header
>>
>> @@ -315,6 +318,7 @@ static int mlp_parse(AVCodecParserContext *s,
>> }
>>
>> mp->bytes_left = 0;
>> +}
>>
>> sync_present = (AV_RB32(buf + 4) & 0xfffe) == 0xf8726fba;
>>
>
> Not so sure about this. I think some mkv TrueHD files contain packets
> that are not properly starting on frame boundaries. But I don't really
> remember.
As in badly muxed files? Couldn't the same thing happen with any other
codec? We're not bothering to consider such cases in other parses as far
as i could see.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add muxing/demuxing of RMHD
On Fri, Jan 19, 2018 at 09:45:44PM +0100, Moritz Barsnick wrote: > On Fri, Jan 19, 2018 at 18:16:01 +0100, Michael Niedermayer wrote: > > > Patches are not made to be applyable on their own. If that is the only > > > thing > > > missing I might move it to 1/3. > > > > code must build after each commit when its pushed. > > so if the patches represent future commits 1:1 then please move what is > > needed > > so it builds > > Well, Thilo did point out: > > I split it up in separate patches for easier review only, > > non-functional if applied separately. Will be stashed after review or > > split in a sane way. and i didnt fully read the intro mail it seems ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix signed integer overflow undefined behavior
On Fri, Jan 19, 2018 at 02:48:08PM -0800, Nikolas Bowe wrote: > Found via fuzzing > --- > libavformat/rpl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/rpl.c b/libavformat/rpl.c > index d373600478..df449bfc29 100644 > --- a/libavformat/rpl.c > +++ b/libavformat/rpl.c > @@ -194,7 +194,7 @@ static int rpl_read_header(AVFormatContext *s) > if (ast->codecpar->bits_per_coded_sample == 0) > ast->codecpar->bits_per_coded_sample = 4; > > -ast->codecpar->bit_rate = ast->codecpar->sample_rate * > +ast->codecpar->bit_rate = (uint64_t)ast->codecpar->sample_rate * >ast->codecpar->bits_per_coded_sample * >ast->codecpar->channels; uint64_t is the wrong type, bit_rate is int64_t [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix signed integer overflow undefined behavior
Found via fuzzing --- libavformat/rpl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/rpl.c b/libavformat/rpl.c index d373600478..df449bfc29 100644 --- a/libavformat/rpl.c +++ b/libavformat/rpl.c @@ -194,7 +194,7 @@ static int rpl_read_header(AVFormatContext *s) if (ast->codecpar->bits_per_coded_sample == 0) ast->codecpar->bits_per_coded_sample = 4; -ast->codecpar->bit_rate = ast->codecpar->sample_rate * +ast->codecpar->bit_rate = (uint64_t)ast->codecpar->sample_rate * ast->codecpar->bits_per_coded_sample * ast->codecpar->channels; -- 2.16.0.rc1.238.g530d649a79-goog ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/swfdec: Reduce score when auto-detecting swf files
On Fri, Jan 19, 2018 at 07:25:43PM +0100, Carl Eugen Hoyos wrote: > 2018-01-19 18:51 GMT+01:00 Michael Niedermayer : > > On Thu, Jan 18, 2018 at 09:28:40PM +0100, Carl Eugen Hoyos wrote: > >> Hi! > >> > >> The probe score for swf files (with uncompressed headers) is currently > >> very high after testing a little more than 24bit, attached patch > >> reduces the score. > > > > hmm > > the first 24 bits are tested and all but 2 values are rejected > > > > thats 23 bits that must match > > Ok. > > > then 4 values are tested which can be from 1 to 31 bits each > > the tests are each either == 0 or != 0 so they are a bit weak > > but its at least adding 4 bits that must match and also len > > I was sure this is not equivalent to four bits on a specific > position (but for the patch I assumed a "best case scenario" > where this actually were the case). > > > itself has to be smallish so we could argue that this gets us to > > about 28 bits > > > and then buf[3] is checked to be < 20 > > at this point we need about 32bits to be matching, still not huge but > > id think this is stronger than what file extensions prove which are > > MAX/2 > > We return MAX/2 for many "initial 32 bits" tests and I believe > we made good experience (and for MAX/2 the extension is > ignored or do I misremember?) > > > The test is weakened by using 0 / not 0 / ascii as values though > > > > Have you seen an actual probe failure ? > > No, I was looking at another issue. we have many files with wrong extensions, its not uncommon so if we have no example of this failing then it is clearly a stronger check than file extension checking which is at score 50 so the score should be higher [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cuvid : add support to force intra frames as in input source
Am 19.01.2018 um 19:47 schrieb Michael Niedermayer: On Fri, Jan 19, 2018 at 11:09:51AM +0100, Timo Rothenpieler wrote: Am 18.01.2018 um 07:52 schrieb Yogender Gupta: Improved the patch by dynamic allocation. Thanks, Yogender @@ -1072,6 +1083,8 @@ static void cuvid_flush(AVCodecContext *avctx) if (ret < 0) goto error; +av_free(ctx->key_frame); this should probably be av_freep() unless the place where it resides is before some code unconditionally overwriting it afterwards Yeah, it should. Changed and applied. smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix memory leak in lrcdec.c
--- libavformat/lrcdec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c index 12f74b22a0..f4e9a4efa9 100644 --- a/libavformat/lrcdec.c +++ b/libavformat/lrcdec.c @@ -212,6 +212,7 @@ static int lrc_read_header(AVFormatContext *s) } ff_subtitles_queue_finalize(s, &lrc->q); ff_metadata_conv_ctx(s, NULL, ff_lrc_metadata_conv); +av_bprint_finalize(&line, NULL); return 0; } -- 2.16.0.rc1.238.g530d649a79-goog ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add muxing/demuxing of RMHD
On Fri, Jan 19, 2018 at 18:16:01 +0100, Michael Niedermayer wrote: > > Patches are not made to be applyable on their own. If that is the only thing > > missing I might move it to 1/3. > > code must build after each commit when its pushed. > so if the patches represent future commits 1:1 then please move what is needed > so it builds Well, Thilo did point out: > I split it up in separate patches for easier review only, > non-functional if applied separately. Will be stashed after review or > split in a sane way. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mlp_parser: don't try to combine frames when full frames are provided
On Fri, 19 Jan 2018 16:51:45 -0300
James Almer wrote:
> Attempting full frame reconstruction is unnecessary for containers
> like Matroska, so just skip it altogether.
>
> Signed-off-by: James Almer
> ---
> libavcodec/mlp_parser.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
> index 3c0330f777..4827354f18 100644
> --- a/libavcodec/mlp_parser.c
> +++ b/libavcodec/mlp_parser.c
> @@ -256,6 +256,9 @@ static int mlp_parse(AVCodecParserContext *s,
> if (buf_size == 0)
> return 0;
>
> +if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
> +next = buf_size;
> +} else {
> if (!mp->in_sync) {
> // Not in sync - find a major sync header
>
> @@ -315,6 +318,7 @@ static int mlp_parse(AVCodecParserContext *s,
> }
>
> mp->bytes_left = 0;
> +}
>
> sync_present = (AV_RB32(buf + 4) & 0xfffe) == 0xf8726fba;
>
Not so sure about this. I think some mkv TrueHD files contain packets
that are not properly starting on frame boundaries. But I don't really
remember.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mlp_parser: don't try to combine frames when full frames are provided
On 19 January 2018 at 19:51, James Almer wrote:
> Attempting full frame reconstruction is unnecessary for containers
> like Matroska, so just skip it altogether.
>
> Signed-off-by: James Almer
> ---
> libavcodec/mlp_parser.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
> index 3c0330f777..4827354f18 100644
> --- a/libavcodec/mlp_parser.c
> +++ b/libavcodec/mlp_parser.c
> @@ -256,6 +256,9 @@ static int mlp_parse(AVCodecParserContext *s,
> if (buf_size == 0)
> return 0;
>
> +if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
> +next = buf_size;
> +} else {
> if (!mp->in_sync) {
> // Not in sync - find a major sync header
>
> @@ -315,6 +318,7 @@ static int mlp_parse(AVCodecParserContext *s,
> }
>
> mp->bytes_left = 0;
> +}
>
> sync_present = (AV_RB32(buf + 4) & 0xfffe) == 0xf8726fba;
>
> --
> 2.15.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Makes sense to me, both commits look fine
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/mlp_parser: reindent after last commit
Signed-off-by: James Almer
---
libavcodec/mlp_parser.c | 92 -
1 file changed, 46 insertions(+), 46 deletions(-)
diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
index 4827354f18..185bd4d667 100644
--- a/libavcodec/mlp_parser.c
+++ b/libavcodec/mlp_parser.c
@@ -259,65 +259,65 @@ static int mlp_parse(AVCodecParserContext *s,
if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
next = buf_size;
} else {
-if (!mp->in_sync) {
-// Not in sync - find a major sync header
-
-for (i = 0; i < buf_size; i++) {
-mp->pc.state = (mp->pc.state << 8) | buf[i];
-if ((mp->pc.state & 0xfffe) == 0xf8726fba &&
-// ignore if we do not have the data for the start of header
-mp->pc.index + i >= 7) {
-mp->in_sync = 1;
-mp->bytes_left = 0;
-break;
+if (!mp->in_sync) {
+// Not in sync - find a major sync header
+
+for (i = 0; i < buf_size; i++) {
+mp->pc.state = (mp->pc.state << 8) | buf[i];
+if ((mp->pc.state & 0xfffe) == 0xf8726fba &&
+// ignore if we do not have the data for the start of
header
+mp->pc.index + i >= 7) {
+mp->in_sync = 1;
+mp->bytes_left = 0;
+break;
+}
}
-}
-if (!mp->in_sync) {
-if (ff_combine_frame(&mp->pc, END_NOT_FOUND, &buf, &buf_size) !=
-1)
+if (!mp->in_sync) {
+if (ff_combine_frame(&mp->pc, END_NOT_FOUND, &buf, &buf_size)
!= -1)
+av_log(avctx, AV_LOG_WARNING, "ff_combine_frame failed\n");
+return buf_size;
+}
+
+if ((ret = ff_combine_frame(&mp->pc, i - 7, &buf, &buf_size)) < 0)
{
av_log(avctx, AV_LOG_WARNING, "ff_combine_frame failed\n");
-return buf_size;
-}
+return ret;
+}
-if ((ret = ff_combine_frame(&mp->pc, i - 7, &buf, &buf_size)) < 0) {
-av_log(avctx, AV_LOG_WARNING, "ff_combine_frame failed\n");
-return ret;
+return i - 7;
}
-return i - 7;
-}
+if (mp->bytes_left == 0) {
+// Find length of this packet
-if (mp->bytes_left == 0) {
-// Find length of this packet
-
-/* Copy overread bytes from last frame into buffer. */
-for(; mp->pc.overread>0; mp->pc.overread--) {
-mp->pc.buffer[mp->pc.index++]=
mp->pc.buffer[mp->pc.overread_index++];
-}
+/* Copy overread bytes from last frame into buffer. */
+for(; mp->pc.overread>0; mp->pc.overread--) {
+mp->pc.buffer[mp->pc.index++]=
mp->pc.buffer[mp->pc.overread_index++];
+}
-if (mp->pc.index + buf_size < 2) {
-if (ff_combine_frame(&mp->pc, END_NOT_FOUND, &buf, &buf_size) !=
-1)
-av_log(avctx, AV_LOG_WARNING, "ff_combine_frame failed\n");
-return buf_size;
-}
+if (mp->pc.index + buf_size < 2) {
+if (ff_combine_frame(&mp->pc, END_NOT_FOUND, &buf, &buf_size)
!= -1)
+av_log(avctx, AV_LOG_WARNING, "ff_combine_frame failed\n");
+return buf_size;
+}
-mp->bytes_left = ((mp->pc.index > 0 ? mp->pc.buffer[0] : buf[0]) << 8)
- | (mp->pc.index > 1 ? mp->pc.buffer[1] :
buf[1-mp->pc.index]);
-mp->bytes_left = (mp->bytes_left & 0xfff) * 2;
-if (mp->bytes_left <= 0) { // prevent infinite loop
-goto lost_sync;
+mp->bytes_left = ((mp->pc.index > 0 ? mp->pc.buffer[0] : buf[0])
<< 8)
+ | (mp->pc.index > 1 ? mp->pc.buffer[1] :
buf[1-mp->pc.index]);
+mp->bytes_left = (mp->bytes_left & 0xfff) * 2;
+if (mp->bytes_left <= 0) { // prevent infinite loop
+goto lost_sync;
+}
+mp->bytes_left -= mp->pc.index;
}
-mp->bytes_left -= mp->pc.index;
-}
-next = (mp->bytes_left > buf_size) ? END_NOT_FOUND : mp->bytes_left;
+next = (mp->bytes_left > buf_size) ? END_NOT_FOUND : mp->bytes_left;
-if (ff_combine_frame(&mp->pc, next, &buf, &buf_size) < 0) {
-mp->bytes_left -= buf_size;
-return buf_size;
-}
+if (ff_combine_frame(&mp->pc, next, &buf, &buf_size) < 0) {
+mp->bytes_left -= buf_size;
+return buf_size;
+}
-mp->bytes_left = 0;
+mp->bytes_left = 0;
}
sync_present = (AV_RB32(buf + 4) & 0xfffe) == 0xf8726fba;
--
2.15.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/mlp_parser: don't try to combine frames when full frames are provided
Attempting full frame reconstruction is unnecessary for containers
like Matroska, so just skip it altogether.
Signed-off-by: James Almer
---
libavcodec/mlp_parser.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
index 3c0330f777..4827354f18 100644
--- a/libavcodec/mlp_parser.c
+++ b/libavcodec/mlp_parser.c
@@ -256,6 +256,9 @@ static int mlp_parse(AVCodecParserContext *s,
if (buf_size == 0)
return 0;
+if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
+next = buf_size;
+} else {
if (!mp->in_sync) {
// Not in sync - find a major sync header
@@ -315,6 +318,7 @@ static int mlp_parse(AVCodecParserContext *s,
}
mp->bytes_left = 0;
+}
sync_present = (AV_RB32(buf + 4) & 0xfffe) == 0xf8726fba;
--
2.15.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cuvid : add support to force intra frames as in input source
On Fri, Jan 19, 2018 at 11:09:51AM +0100, Timo Rothenpieler wrote: > Am 18.01.2018 um 07:52 schrieb Yogender Gupta: > >Improved the patch by dynamic allocation. > > > >Thanks, > >Yogender > > > > > @@ -1072,6 +1083,8 @@ static void cuvid_flush(AVCodecContext *avctx) > > if (ret < 0) > > goto error; > > > > +av_free(ctx->key_frame); this should probably be av_freep() unless the place where it resides is before some code unconditionally overwriting it afterwards [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dashdec: Only free url string if being reused
On Thu, Jan 18, 2018 at 09:15:49PM +1100, Brendan McGrath wrote:
> If no representation bandwidth value is set, the url value returned
> by get_content_url is corrupt (as the memory has been freed).
>
> This change ensures the url string is not freed unless it is about
> to be reused
>
> Signed-off-by: Brendan McGrath
> ---
> libavformat/dashdec.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 2492f1d..83980b9 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -482,9 +482,11 @@ static char *get_content_url(xmlNodePtr *baseurl_nodes,
> return NULL;
> }
> av_strlcpy(tmp_str, url, sizeof(tmp_str));
> -av_free(url);
> }
> if (rep_bandwidth_val && tmp_str[0] != '\0') {
> +if (url) {
> +av_free(url);
> +}
The if() is unneeded
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/swfdec: Reduce score when auto-detecting swf files
2018-01-19 18:51 GMT+01:00 Michael Niedermayer : > On Thu, Jan 18, 2018 at 09:28:40PM +0100, Carl Eugen Hoyos wrote: >> Hi! >> >> The probe score for swf files (with uncompressed headers) is currently >> very high after testing a little more than 24bit, attached patch >> reduces the score. > > hmm > the first 24 bits are tested and all but 2 values are rejected > > thats 23 bits that must match Ok. > then 4 values are tested which can be from 1 to 31 bits each > the tests are each either == 0 or != 0 so they are a bit weak > but its at least adding 4 bits that must match and also len I was sure this is not equivalent to four bits on a specific position (but for the patch I assumed a "best case scenario" where this actually were the case). > itself has to be smallish so we could argue that this gets us to > about 28 bits > and then buf[3] is checked to be < 20 > at this point we need about 32bits to be matching, still not huge but > id think this is stronger than what file extensions prove which are > MAX/2 We return MAX/2 for many "initial 32 bits" tests and I believe we made good experience (and for MAX/2 the extension is ignored or do I misremember?) > The test is weakened by using 0 / not 0 / ascii as values though > > Have you seen an actual probe failure ? No, I was looking at another issue. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/swfdec: Reduce score when auto-detecting swf files
2018-01-19 18:33 GMT+01:00 Michael Niedermayer : > On Fri, Jan 19, 2018 at 04:21:54PM +0100, Tomas Härdin wrote: >> On 2018-01-18 21:28, Carl Eugen Hoyos wrote: >> >Hi! >> > >> >The probe score for swf files (with uncompressed headers) is currently >> >very high after testing a little more than 24bit, attached patch >> >reduces the score. >> > >> >Please comment, Carl Eugen >> >> Would be consistent with the discussion about .c2 files. Could we document >> this in avformat.h? Something like: >> > >> // Score should be no more than AVPROBE_SCORE_MAX * identifying_bits/64 >> // if the number of identifying "magic" bits are less than 64 > > this is a bit oversimplifying it i think I don't disagree. > its more a question of "entropy" than bits > 24bits tested for at one location is much stronger than 24 bits found at any > location in 20mb. (later is in fact close to telling us nothing) Of course. I believe that for ~64 initial bits, we should return MAX - 1. But for many formats, "initial bits" is of no relevance. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/svq3: Do not write into const memory
2018-01-19 16:54 GMT+01:00 Tomas Härdin :
> On 2018-01-18 23:34, Carl Eugen Hoyos wrote:
>>
>> Hi!
>>
>> Attached patch fixes a warning, I suspect it makes the code more correct.
>>
>> Please comment, Carl Eugen
>>
>
>> --- a/libavcodec/svq3.c
>> +++ b/libavcodec/svq3.c
>> @@ -1048,12 +1048,12 @@ static int svq3_decode_slice_header(AVCodecContext
>> *avctx)
>> }
>> memcpy(s->slice_buf, s->gb.buffer + s->gb.index / 8,
>> slice_bytes);
>> -init_get_bits(&s->gb_slice, s->slice_buf, slice_bits);
>
> Unrelated change?
No, it is an intended move.
>> if (s->watermark_key) {
>> -uint32_t header = AV_RL32(&s->gb_slice.buffer[1]);
>> -AV_WL32(&s->gb_slice.buffer[1], header ^ s->watermark_key);
>
> Strange that this didn't manage to break anything, or that the compiler
> let it through
A compiler's warning that gets fixed is the reason for this patch but
I apparently misunderstand your comment.
>> +uint32_t header = AV_RL32(&s->slice_buf[1]);
>> +AV_WL32(&s->slice_buf[1], header ^ s->watermark_key);
>
> Considering the memcpy() above, either this or the old code must be wrong.
Why do you think so?
(I do consider the old code "wrong", that is why I sent this patch.)
> My guess is the old code must have been wrong, since to fiddle
> the same bits this AV_WL32() would need to set
> &s->slice_buf[1 - s->gb.index / 8]...
I was hoping that the same bits get fiddled given that I call the
same macro / function...
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp9_parser: parse size and colorspace values from frame headers
2018-01-19 17:09 GMT+01:00 James Almer : > On 1/19/2018 8:19 AM, Carl Eugen Hoyos wrote: >> 2018-01-19 4:51 GMT+01:00 James Almer : >>> Improves remuxing support when vp9 decoder is not compiled in. >> >>> +static int read_colorspace_details(AVCodecParserContext *ctx, >>> AVCodecContext *avctx, >>> + GetBitContext *gb) >> >> Isn't this a duplicate of an existing, non-trivial function? >> >> Carl Eugen > > Yes, but just like how h264/hevc have duplicate NAL parsing code all > across the codebase, it's different enough that making it shared would > be too complex/dirty to be worth the hassle. I wish this argument would count more often. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/swfdec: Reduce score when auto-detecting swf files
On Thu, Jan 18, 2018 at 09:28:40PM +0100, Carl Eugen Hoyos wrote: > Hi! > > The probe score for swf files (with uncompressed headers) is currently > very high after testing a little more than 24bit, attached patch > reduces the score. hmm the first 24 bits are tested and all but 2 values are rejected thats 23 bits that must match then 4 values are tested which can be from 1 to 31 bits each the tests are each either == 0 or != 0 so they are a bit weak but its at least adding 4 bits that must match and also len itself has to be smallish so we could argue that this gets us to about 28 bits and then buf[3] is checked to be < 20 at this point we need about 32bits to be matching, still not huge but id think this is stronger than what file extensions prove which are MAX/2 The test is weakened by using 0 / not 0 / ascii as values though Have you seen an actual probe failure ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/swfdec: Reduce score when auto-detecting swf files
On Fri, Jan 19, 2018 at 04:21:54PM +0100, Tomas Härdin wrote: > On 2018-01-18 21:28, Carl Eugen Hoyos wrote: > >Hi! > > > >The probe score for swf files (with uncompressed headers) is currently > >very high after testing a little more than 24bit, attached patch > >reduces the score. > > > >Please comment, Carl Eugen > > Would be consistent with the discussion about .c2 files. Could we document > this in avformat.h? Something like: > > // Score should be no more than AVPROBE_SCORE_MAX * identifying_bits/64 > // if the number of identifying "magic" bits are less than 64 this is a bit oversimplifying it i think its more a question of "entropy" than bits 24bits tested for at one location is much stronger than 24 bits found at any location in 20mb. (later is in fact close to telling us nothing) If we want to define a limit then one way we might define it somehow based on how often a large random input would cause probe to trigger with that or a higher score. (this is also testable) Care has to be taken that this works with existing probe functions. It would be bad if a rule is added that when followed breaks existing probe code or doesnt interoperate well with it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add muxing/demuxing of RMHD
On Fri, Jan 19, 2018 at 01:39:31PM +0100, Thilo Borgmann wrote: > Am 19.01.18 um 01:02 schrieb Michael Niedermayer: > > On Thu, Jan 18, 2018 at 07:39:07PM +0100, Thilo Borgmann wrote: > >> This time including the patch... > > > >> fftools/ffmpeg.c | 28 +++ > >> fftools/ffmpeg_opt.c |2 > >> libavformat/Makefile |2 > >> libavformat/allformats.c |1 > >> libavformat/rm.c |1 > >> libavformat/rm.h |7 > >> libavformat/rmdec.c | 96 +-- > >> libavformat/rmenc.c | 395 > >> ++- > >> libavformat/utils.c |5 > >> 9 files changed, 438 insertions(+), 99 deletions(-) > >> b65cfa6fc05b6199324118ef1b40d9737cd70272 > >> 0001-Add-muxing-demuxing-of-RMHD.patch > >> From aaeaf7721ba5e9afd79ee13dbb9cc7c3226027b3 Mon Sep 17 00:00:00 2001 > >> From: Thilo Borgmann > >> Date: Wed, 17 Jan 2018 23:09:03 +0100 > >> Subject: [PATCH 1/3] Add muxing/demuxing of RMHD > > > > This is missing AV_CODEC_ID_RV60 > > Patches are not made to be applyable on their own. If that is the only thing > missing I might move it to 1/3. code must build after each commit when its pushed. so if the patches represent future commits 1:1 then please move what is needed so it builds thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/5] x86inc: Sync changes from x264
On Fri, Jan 19, 2018 at 12:06:10AM +0100, Henrik Gramner wrote: > Henrik Gramner (5): > x86inc: Enable AVX emulation for floating-point pseudo-instructions > x86inc: Use .rdata instead of .rodata on Windows > x86inc: Support creating global symbols from local labels > x86inc: Correctly set mmreg variables > x86inc: Drop cpuflags_slowctz > > libavutil/x86/x86inc.asm | 140 > --- > 1 file changed, 85 insertions(+), 55 deletions(-) seems not to break build in any environment i can _easily_ test fate also passes but that wont use much of the changes i guess and as this is a sync from upstream it should be ok thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix float-cast-overflow undefined behavior in matroskadec
On Thu, Jan 18, 2018 at 03:21:56PM -0800, Nikolas Bowe wrote: > --- > libavformat/matroskadec.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) will apply with the indention and commit message fixed thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] MAINTAINERS: add myself for avcodec/v4l2_
--- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index e583926..d0de26c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -240,6 +240,7 @@ Codecs: tta.c Alex Beregszaszi, Jaikrishnan Menon ttaenc.c Paul B Mahol txd.c Ivo van Poorten + v4l2_*Jorge Ramirez-Ortiz vc2* Rostislav Pehlivanov vcr1.cMichael Niedermayer videotoolboxenc.c Rick Kern, Aman Gupta -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v1 1/3] avcodec: v4l2_m2m: fix races around freeing data on close
On 01/19/2018 12:30 AM, Michael Niedermayer wrote: On Thu, Jan 18, 2018 at 09:24:20AM +0100, Jorge Ramirez-Ortiz wrote: On 01/09/2018 11:56 PM, Jorge Ramirez-Ortiz wrote: From: Mark Thompson Refcount all of the context information. This also fixes a potential segmentation fault when accessing freed memory (buffer returned after the codec has been closed). just a follow up on the patchset (patches 1 to 3) any feedback? shall I resend? Who is the maintainer of this code ? noone is listed for it MAINTAINERS if someone volunteers to maintain it and there are no objections then that person would get git write access and could push patches and then bugfixes wont be stuck so long ... If someone wants to volunteer in that sense, then please send a patch for the MAINTAINER file sure I can send such a patch ( unless Mark Thompson has an interest in maintaining it -since he did most of the reviews of the whole patchset IIRC- Baylibre will give me time to maintain this code) [...] ___ 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 1/2] lavc: Add coded_w/h to AVCodecParameters
On 1/19/2018 7:12 AM, Hendrik Leppkes wrote:
> On Fri, Jan 19, 2018 at 4:19 AM, Li, Zhong wrote:
>>> -Original Message-
>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>>> Of James Almer
>>> Sent: Thursday, January 18, 2018 1:15 PM
>>> To: ffmpeg-devel@ffmpeg.org
>>> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc: Add coded_w/h to
>>> AVCodecParameters
>>>
>>> On 1/18/2018 2:03 AM, Zhong Li wrote:
coded_width/height may be different from width/height sometimes
>>>
(e.g, crop or lowres cases).
>>>
>>> Which is why it's not a field that belongs to AVCodecParameters.
>>>
>>> Codec level cropping has nothing to do with containers. Same with lowres,
>>> which is an internal feature, and scheduled for removal.
>>
>> Got it. How about fixing ticket #6958 as below?
>>
>> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
>> index 0e7a771..233760d 100644
>> --- a/fftools/ffprobe.c
>> +++ b/fftools/ffprobe.c
>> @@ -2512,10 +2512,12 @@ static int show_stream(WriterContext *w,
>> AVFormatContext *fmt_ctx, int stream_id
>> case AVMEDIA_TYPE_VIDEO:
>> print_int("width",par->width);
>> print_int("height", par->height);
>> +#if FF_API_LAVF_AVCTX
>> if (dec_ctx) {
>> print_int("coded_width", dec_ctx->coded_width);
>> print_int("coded_height", dec_ctx->coded_height);
>> }
>> +#endif
>> print_int("has_b_frames", par->video_delay);
>> sar = av_guess_sample_aspect_ratio(fmt_ctx, stream, NULL);
>> if (sar.den) {
>> @@ -2912,6 +2914,10 @@ static int open_input_file(InputFile *ifile, const
>> char *filename)
>>
>> ist->dec_ctx->pkt_timebase = stream->time_base;
>> ist->dec_ctx->framerate = stream->avg_frame_rate;
>> +#if FF_API_LAVF_AVCTX
>> +ist->dec_ctx->coded_width = stream->codec->coded_width;
>> +ist->dec_ctx->coded_height = stream->codec->coded_height;
>> +#endif
>>
>
> As mentioned in the thread for that patch already, writing new code
> using deprecated API should really be avoided.
>
> The way I see it, if someone really needs to know coded w/h (which is
> typically an internal technical detail of no relevance to users), they
> should decode a frame and get it from the decoder.
>
> - Hendrik
This specific approach is IMO acceptable. It basically recovers the
pre-codecpar behavior until AVStream->codec is removed, and effectively
fixes the "regression".
Once that's gone, ffprobe will stop reporting coded_width/height
altogether instead of doing so with a bogus value, as everything is
being wrapped in the proper checks.
The alternative is to remove the two print_int() lines right now, of
course, but i don't think it's the best approach when the above patch is
simple, clean, and local to ffprobe.c (unlike the original suggestion).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp9_parser: parse size and colorspace values from frame headers
On 1/19/2018 8:19 AM, Carl Eugen Hoyos wrote: > 2018-01-19 4:51 GMT+01:00 James Almer : >> Improves remuxing support when vp9 decoder is not compiled in. > >> +static int read_colorspace_details(AVCodecParserContext *ctx, >> AVCodecContext *avctx, >> + GetBitContext *gb) > > Isn't this a duplicate of an existing, non-trivial function? > > Carl Eugen Yes, but just like how h264/hevc have duplicate NAL parsing code all across the codebase, it's different enough that making it shared would be too complex/dirty to be worth the hassle. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/svq3: Do not write into const memory
On 2018-01-18 23:34, Carl Eugen Hoyos wrote:
Hi!
Attached patch fixes a warning, I suspect it makes the code more correct.
Please comment, Carl Eugen
--- a/libavcodec/svq3.c
+++ b/libavcodec/svq3.c
@@ -1048,12 +1048,12 @@ static int svq3_decode_slice_header(AVCodecContext
*avctx)
}
memcpy(s->slice_buf, s->gb.buffer + s->gb.index / 8, slice_bytes);
-init_get_bits(&s->gb_slice, s->slice_buf, slice_bits);
Unrelated change?
if (s->watermark_key) {
-uint32_t header = AV_RL32(&s->gb_slice.buffer[1]);
-AV_WL32(&s->gb_slice.buffer[1], header ^ s->watermark_key);
Strange that this didn't manage to break anything, or that the compiler
let it through
+uint32_t header = AV_RL32(&s->slice_buf[1]);
+AV_WL32(&s->slice_buf[1], header ^ s->watermark_key);
Considering the memcpy() above, either this or the old code must be
wrong. My guess is the old code must have been wrong, since to fiddle
the same bits this AV_WL32() would need to set &s->slice_buf[1 -
s->gb.index / 8]...
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/swfdec: Reduce score when auto-detecting swf files
On 2018-01-18 21:28, Carl Eugen Hoyos wrote: Hi! The probe score for swf files (with uncompressed headers) is currently very high after testing a little more than 24bit, attached patch reduces the score. Please comment, Carl Eugen Would be consistent with the discussion about .c2 files. Could we document this in avformat.h? Something like: // Score should be no more than AVPROBE_SCORE_MAX * identifying_bits/64 // if the number of identifying "magic" bits are less than 64 /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add muxing/demuxing of RMHD
Am 19.01.18 um 01:02 schrieb Michael Niedermayer: > On Thu, Jan 18, 2018 at 07:39:07PM +0100, Thilo Borgmann wrote: >> This time including the patch... > >> fftools/ffmpeg.c | 28 +++ >> fftools/ffmpeg_opt.c |2 >> libavformat/Makefile |2 >> libavformat/allformats.c |1 >> libavformat/rm.c |1 >> libavformat/rm.h |7 >> libavformat/rmdec.c | 96 +-- >> libavformat/rmenc.c | 395 >> ++- >> libavformat/utils.c |5 >> 9 files changed, 438 insertions(+), 99 deletions(-) >> b65cfa6fc05b6199324118ef1b40d9737cd70272 >> 0001-Add-muxing-demuxing-of-RMHD.patch >> From aaeaf7721ba5e9afd79ee13dbb9cc7c3226027b3 Mon Sep 17 00:00:00 2001 >> From: Thilo Borgmann >> Date: Wed, 17 Jan 2018 23:09:03 +0100 >> Subject: [PATCH 1/3] Add muxing/demuxing of RMHD > > This is missing AV_CODEC_ID_RV60 Patches are not made to be applyable on their own. If that is the only thing missing I might move it to 1/3. Thanks for all the feedback by now, I'll update the patches as soon as I can! -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/h264_slice: use the new SAR early when setting the decoder
If we don't do that get_format might not be called for a while and the proper
SAR not used.
See the sample mentioned here: https://trac.videolan.org/vlc/ticket/19435
---
libavcodec/h264_slice.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index e6b7998834..319a37f5b6 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1050,8 +1050,10 @@ static int h264_init_ps(H264Context *h, const
H264SliceContext *sl, int first_sl
|| (non_j_pixfmt(h->avctx->pix_fmt) !=
non_j_pixfmt(get_pixel_format(h, 0
must_reinit = 1;
-if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio))
+if (first_slice && av_cmp_q(sps->sar, h->avctx->sample_aspect_ratio)) {
must_reinit = 1;
+ff_set_sar(h->avctx, sps->sar);
+}
if (!h->setup_finished) {
h->avctx->profile = ff_h264_get_profile(sps);
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix float-cast-overflow undefined behavior in matroskadec
2018-01-19 2:06 GMT+01:00 Niki Bowe : > In the file the fuzzer produced the frame rate is incredibly small > (7.29112e-304). And the msvc documentation seems to indicate it is supported. No more comments from me, please avoid top-posting here. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp9_parser: parse size and colorspace values from frame headers
2018-01-19 4:51 GMT+01:00 James Almer : > Improves remuxing support when vp9 decoder is not compiled in. > +static int read_colorspace_details(AVCodecParserContext *ctx, AVCodecContext > *avctx, > + GetBitContext *gb) Isn't this a duplicate of an existing, non-trivial function? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2 2/2] Don't overwrite previously setup dimensions for all codecs
2018-01-19 4:28 GMT+01:00 Li, Zhong : >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Carl Eugen Hoyos >> Sent: Thursday, January 18, 2018 5:26 PM >> To: FFmpeg development discussions and patches >> >> Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] Don't overwrite previously setup >> dimensions for all codecs >> >> 2018-01-18 6:03 GMT+01:00 Zhong Li : >> > Currently a hacky way is used for some specific codecs such as >> > H264/VP6F/DXV >> >> > (and "lowres" case is broken now). >> >> How can I reproduce this? > > Just infer from the code. Sadly, I am not so good at this, I prefer to test actual command lines. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: Add CODECS attribute to master playlist
2017-12-29 15:05 GMT+08:00 Jeyapal, Karthick :
>
>
> On 12/28/17 5:17 PM, Karthick J wrote:
>> From: Karthick Jeyapal
>>
>> ---
>> libavformat/dashenc.c | 2 +-
>> libavformat/hlsenc.c | 67
>> ++-
>> libavformat/hlsplaylist.c | 5 +++-
>> libavformat/hlsplaylist.h | 3 ++-
>> 4 files changed, 73 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index 478a384..8797959 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -760,7 +760,7 @@ static int write_manifest(AVFormatContext *s, int final)
>> AVStream *st = s->streams[i];
>> get_hls_playlist_name(playlist_file, sizeof(playlist_file),
>> NULL, i);
>> ff_hls_write_stream_info(st, out, st->codecpar->bit_rate,
>> -playlist_file, NULL);
>> +playlist_file, NULL, NULL);
>> }
>> avio_close(out);
>> if (use_rename)
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 74f66ce..bb442f5 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -58,6 +58,11 @@ typedef enum {
>>HLS_START_SEQUENCE_AS_FORMATTED_DATETIME = 2, // MMDDhhmmss
>> } StartSequenceSourceType;
>>
>> +typedef enum {
>> +CODEC_ATTRIBUTE_WRITTEN = 0,
>> +CODEC_ATTRIBUTE_WILL_NOT_BE_WRITTEN,
>> +} CodecAttributeStatus;
>> +
>> #define KEYSIZE 16
>> #define LINE_BUFFER_SIZE 1024
>> #define HLS_MICROSECOND_UNIT 100
>> @@ -142,6 +147,8 @@ typedef struct VariantStream {
>> int fmp4_init_mode;
>>
>> AVStream **streams;
>> +char codec_attr[128];
>> +CodecAttributeStatus attr_status;
>> unsigned int nb_streams;
>> int m3u8_created; /* status of media play-list creation */
>> char *agroup; /* audio group name */
>> @@ -296,6 +303,51 @@ static void set_http_options(AVFormatContext *s,
>> AVDictionary **options, HLSCont
>>
>> }
>>
>> +static void write_codec_attr(AVStream *st, VariantStream *vs) {
>> +int codec_strlen = strlen(vs->codec_attr);
>> +char attr[32];
>> +
>> +if (st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE)
>> +return;
>> +if (vs->attr_status == CODEC_ATTRIBUTE_WILL_NOT_BE_WRITTEN)
>> +return;
>> +
>> +if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
>> +uint8_t *data = st->codecpar->extradata;
>> +if ((data[0] | data[1] | data[2]) == 0 && data[3] == 1 && (data[4]
>> & 0x1F) == 7) {
>> +snprintf(attr, sizeof(attr),
>> + "avc1.%02x%02x%02x", data[5], data[6], data[7]);
>> +} else {
>> +goto fail;
>> +}
>> +} else if (st->codecpar->codec_id == AV_CODEC_ID_MP2) {
>> +snprintf(attr, sizeof(attr), "mp4a.40.33");
>> +} else if (st->codecpar->codec_id == AV_CODEC_ID_MP3) {
>> +snprintf(attr, sizeof(attr), "mp4a.40.34");
>> +} else if (st->codecpar->codec_id == AV_CODEC_ID_AAC) {
>> +/* TODO : For HE-AAC, HE-AACv2, the last digit needs to be set to 5
>> and 29 respectively */
>> +snprintf(attr, sizeof(attr), "mp4a.40.2");
>> +} else if (st->codecpar->codec_id == AV_CODEC_ID_AC3) {
>> +snprintf(attr, sizeof(attr), "ac-3");
>> +} else if (st->codecpar->codec_id == AV_CODEC_ID_EAC3) {
>> +snprintf(attr, sizeof(attr), "ec-3");
>> +} else {
>> +goto fail;
>> +}
>> +// Don't write the same attribute multiple times
>> +if (!av_stristr(vs->codec_attr, attr)) {
>> +snprintf(vs->codec_attr + codec_strlen,
>> + sizeof(vs->codec_attr) - codec_strlen,
>> + "%s%s", codec_strlen ? "," : "", attr);
>> +}
>> +return;
>> +
>> +fail:
>> +vs->codec_attr[0] = '\0';
>> +vs->attr_status = CODEC_ATTRIBUTE_WILL_NOT_BE_WRITTEN;
>> +return;
>> +}
>> +
>> static int replace_int_data_in_filename(char *buf, int buf_size, const char
>> *filename, char placeholder, int64_t number)
>> {
>> const char *p;
>> @@ -1235,7 +1287,7 @@ static int create_master_playlist(AVFormatContext *s,
>> bandwidth += bandwidth / 10;
>>
>> ff_hls_write_stream_info(vid_st, hls->m3u8_out, bandwidth,
>> m3u8_rel_name,
>> -aud_st ? vs->agroup : NULL);
>> +aud_st ? vs->agroup : NULL, vs->codec_attr);
>>
>> av_freep(&m3u8_rel_name);
>> }
>> @@ -1764,6 +1816,19 @@ static int hls_write_header(AVFormatContext *s)
>> continue;
>> }
>> avpriv_set_pts_info(outer_st, inner_st->pts_wrap_bits,
>> inner_st->time_base.num, inner_st->time_base.den);
>> +write_codec_attr(outer_st, vs);
>> +
>> +}
>> +/* Update the Codec Attr string for the mapped audio groups */
>> +if (vs->has_video && vs->agroup) {
>> +for (j = 0; j < hls->nb_varstreams; j++) {
>> +VariantStream *vs_agroup = &(hls->var_streams[j]);
>> +
Re: [FFmpeg-devel] [PATCH 1/2] lavc: Add coded_w/h to AVCodecParameters
On Fri, Jan 19, 2018 at 4:19 AM, Li, Zhong wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of James Almer
>> Sent: Thursday, January 18, 2018 1:15 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc: Add coded_w/h to
>> AVCodecParameters
>>
>> On 1/18/2018 2:03 AM, Zhong Li wrote:
>> > coded_width/height may be different from width/height sometimes
>>
>> > (e.g, crop or lowres cases).
>>
>> Which is why it's not a field that belongs to AVCodecParameters.
>>
>> Codec level cropping has nothing to do with containers. Same with lowres,
>> which is an internal feature, and scheduled for removal.
>
> Got it. How about fixing ticket #6958 as below?
>
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 0e7a771..233760d 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -2512,10 +2512,12 @@ static int show_stream(WriterContext *w,
> AVFormatContext *fmt_ctx, int stream_id
> case AVMEDIA_TYPE_VIDEO:
> print_int("width",par->width);
> print_int("height", par->height);
> +#if FF_API_LAVF_AVCTX
> if (dec_ctx) {
> print_int("coded_width", dec_ctx->coded_width);
> print_int("coded_height", dec_ctx->coded_height);
> }
> +#endif
> print_int("has_b_frames", par->video_delay);
> sar = av_guess_sample_aspect_ratio(fmt_ctx, stream, NULL);
> if (sar.den) {
> @@ -2912,6 +2914,10 @@ static int open_input_file(InputFile *ifile, const
> char *filename)
>
> ist->dec_ctx->pkt_timebase = stream->time_base;
> ist->dec_ctx->framerate = stream->avg_frame_rate;
> +#if FF_API_LAVF_AVCTX
> +ist->dec_ctx->coded_width = stream->codec->coded_width;
> +ist->dec_ctx->coded_height = stream->codec->coded_height;
> +#endif
>
As mentioned in the thread for that patch already, writing new code
using deprecated API should really be avoided.
The way I see it, if someone really needs to know coded w/h (which is
typically an internal technical detail of no relevance to users), they
should decode a frame and get it from the decoder.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cuvid : add support to force intra frames as in input source
Am 18.01.2018 um 07:52 schrieb Yogender Gupta: Improved the patch by dynamic allocation. Thanks, Yogender > @@ -1072,6 +1083,8 @@ static void cuvid_flush(AVCodecContext *avctx) > if (ret < 0) > goto error; > > +av_free(ctx->key_frame); > + > ctx->prev_pts = INT64_MIN; > ctx->decoder_flushing = 0; > > -- > 2.10.1.windows.1 > I guess you meant to put that into cuvid_decode_end, and not cuvid_flush. Will push soonish with it moved there. Thanks, Timo smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffprobe: Initialize coded_width/height
On Fri, Jan 19, 2018 at 6:05 AM, Zhong Li wrote:
> coded_width/height are unnitialized and will be overwritten by
> dec_ctx->width/height in avcodec_open2()
>
> This fixes tiket #6958.
>
> Signed-off-by: Zhong Li
> ---
> fftools/ffprobe.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 0e7a771..233760d 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -2512,10 +2512,12 @@ static int show_stream(WriterContext *w,
> AVFormatContext *fmt_ctx, int stream_id
> case AVMEDIA_TYPE_VIDEO:
> print_int("width",par->width);
> print_int("height", par->height);
> +#if FF_API_LAVF_AVCTX
> if (dec_ctx) {
> print_int("coded_width", dec_ctx->coded_width);
> print_int("coded_height", dec_ctx->coded_height);
> }
> +#endif
> print_int("has_b_frames", par->video_delay);
> sar = av_guess_sample_aspect_ratio(fmt_ctx, stream, NULL);
> if (sar.den) {
> @@ -2912,6 +2914,10 @@ static int open_input_file(InputFile *ifile, const
> char *filename)
>
> ist->dec_ctx->pkt_timebase = stream->time_base;
> ist->dec_ctx->framerate = stream->avg_frame_rate;
> +#if FF_API_LAVF_AVCTX
> +ist->dec_ctx->coded_width = stream->codec->coded_width;
> +ist->dec_ctx->coded_height = stream->codec->coded_height;
> +#endif
>
> if (avcodec_open2(ist->dec_ctx, codec, &opts) < 0) {
> av_log(NULL, AV_LOG_WARNING, "Could not open codec for input
> stream %d\n",
Lets not write new code based on deprecated API.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Ignore SIGPIPE
Mark Thompson (2018-01-18): > On systems which deliver SIGPIPE (Unices), a broken pipe will currently > result in the immediate termination of the ffmpeg process (the default > disposition as required by POSIX). This is undesirable, because while > the broken pipe is likely fatal to useful cleanup of whatever component > is writing to it, there might be other components which can do useful > cleanup - for example, a muxer on another stream may still need to write > indexes to complete a file. Therefore, set the signal disposition for > SIGPIPE to ignore the signal - the call which caused the signal will > fail with EPIPE and the error will be propagated upwards like any other > I/O failure on a single stream. I think it is a bad idea to make this unconditional. But I am tired to fight uphill. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
