[FFmpeg-devel] [PATCH] lavc/vda_h264_dec.c Fix NULL pointer dereference
From: Pavel Koshevoy
ps.sps_list entries may be NULL, so check before dereferencing
---
libavcodec/vda_h264_dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vda_h264_dec.c b/libavcodec/vda_h264_dec.c
index 92839e2..972bd6b 100644
--- a/libavcodec/vda_h264_dec.c
+++ b/libavcodec/vda_h264_dec.c
@@ -226,7 +226,7 @@ static av_cold int vdadec_init(AVCodecContext *avctx)
ctx->h264_initialized = 1;
for (i = 0; i < MAX_SPS_COUNT; i++) {
-const SPS *sps = (const SPS*)ctx->h264ctx.ps.sps_list[i]->data;
+const SPS *sps = ctx->h264ctx.ps.sps_list[i] ? (const
SPS*)ctx->h264ctx.ps.sps_list[i]->data : NULL;
if (sps && (sps->bit_depth_luma != 8 ||
sps->chroma_format_idc == 2 ||
sps->chroma_format_idc == 3)) {
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] aacsbr: Associate SBR data with AAC elements on init
2017-02-09 18:40 GMT+01:00 Alex Converse : > Quiets some log spam on pure upsampling mode. Please mention ticket #5163. For the whole patchset, I suggest you push as soon as everybody agrees on the function prefixes. Could you review my patch for ticket #1614? https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164080.html It seems to fix the second sample attached on trac, aac_broken.mp4. Did you see ticket #5722? Thank you for the important patches! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Avoid heap allocation wraps and OOB in mov_read_{senc, saiz, udta_string}()
I've separated and updated the mov_read_{senc,saiz}() patch, attached.
It avoids allocation wraps in those two functions.
On Wed, Feb 8, 2017 at 3:48 PM, Matthew Wolenetz
wrote:
> I've separated and updated the mov_read_udta_string() patch, attached.
> It prevents accessing MOVContext.meta_keys[0] in that method. That array
> is 1-based.
>
> On Wed, Dec 14, 2016 at 5:40 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> On 15.12.2016 00:37, Matthew Wolenetz wrote:
>> > From 8622f9398e7c89a664c4c2ceff9d35b89ff17bb5 Mon Sep 17 00:00:00 2001
>> > From: Matt Wolenetz
>> > Date: Tue, 6 Dec 2016 12:54:23 -0800
>> > Subject: [PATCH] lavf/mov.c: Avoid heap allocation wraps and OOB in
>> > mov_read_{senc,saiz,udta_string}()
>> >
>> > Core of patch is from p...@paulmehta.com
>> > Reference https://crbug.com/643952
>> > ---
>> > libavformat/mov.c | 11 ---
>> > 1 file changed, 8 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/libavformat/mov.c b/libavformat/mov.c
>> > index e506d20..87ad91a 100644
>> > --- a/libavformat/mov.c
>> > +++ b/libavformat/mov.c
>> > @@ -404,7 +404,7 @@ retry:
>> > return ret;
>> > } else if (!key && c->found_hdlr_mdta && c->meta_keys) {
>> > uint32_t index = AV_RB32(&atom.type);
>> > -if (index < c->meta_keys_count) {
>> > +if (index < c->meta_keys_count && index > 0) {
>>
>> This should be in a separate patch.
>>
>> > key = c->meta_keys[index];
>> > } else {
>> > av_log(c->fc, AV_LOG_WARNING,
>> > @@ -4502,8 +4502,8 @@ static int mov_read_senc(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>> >
>> > avio_rb32(pb);/* entries */
>> >
>> > -if (atom.size < 8) {
>> > -av_log(c->fc, AV_LOG_ERROR, "senc atom size %"PRId64" too
>> small\n", atom.size);
>> > +if (atom.size < 8 || atom.size > UINT_MAX) {
>> > +av_log(c->fc, AV_LOG_ERROR, "senc atom size %"PRId64"
>> invalid\n", atom.size);
>> > return AVERROR_INVALIDDATA;
>> > }
>> >
>> > @@ -4571,6 +4571,11 @@ static int mov_read_saiz(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>> > return 0;
>> > }
>> >
>> > +if (atom.size > UINT_MAX) {
>> > +av_log(c->fc, AV_LOG_ERROR, "saiz atom auxiliary_info_sizes
>> size %"PRId64" invalid\n", atom.size);
>> > +return AVERROR_INVALIDDATA;
>> > +}
>> > +
>> > /* save the auxiliary info sizes as is */
>> > data_size = atom.size - atom_header_size;
>> >
>>
>> And these should also check for SIZE_MAX.
>>
>> Best regards,
>> Andreas
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
From bba91f9adf4d875814ec4e418e02316cbcf63f6f Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Wed, 14 Dec 2016 15:27:49 -0800
Subject: [PATCH] lavf/mov.c: Avoid heap allocation wraps in
mov_read_{senc,saiz}()
Core of patch is from p...@paulmehta.com
Reference https://crbug.com/643952 (senc,saiz portions)
Signed-off-by: Matt Wolenetz
---
libavformat/mov.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index ca49786ea2..36b65b3b08 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4968,8 +4968,8 @@ static int mov_read_senc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
avio_rb32(pb);/* entries */
-if (atom.size < 8) {
-av_log(c->fc, AV_LOG_ERROR, "senc atom size %"PRId64" too small\n", atom.size);
+if (atom.size < 8 || atom.size > FFMIN(INT_MAX, SIZE_MAX)) {
+av_log(c->fc, AV_LOG_ERROR, "senc atom size %"PRId64" invalid\n", atom.size);
return AVERROR_INVALIDDATA;
}
@@ -5037,6 +5037,11 @@ static int mov_read_saiz(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return 0;
}
+if (atom.size > FFMIN(INT_MAX, SIZE_MAX)) {
+av_log(c->fc, AV_LOG_ERROR, "saiz atom auxiliary_info_sizes size %"PRId64" invalid\n", atom.size);
+return AVERROR_INVALIDDATA;
+}
+
/* save the auxiliary info sizes as is */
data_size = atom.size - atom_header_size;
--
2.11.0.483.g087da7b7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] aac_latm: Allow unaligned AudioSpecificConfig
On 2/9/2017 2:40 PM, Alex Converse wrote:
> diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
> index 5f85b64cb8..9fe257838c 100644
> --- a/libavcodec/mpeg4audio.c
> +++ b/libavcodec/mpeg4audio.c
> @@ -83,70 +83,62 @@ static inline int get_sample_rate(GetBitContext *gb, int
> *index)
> avpriv_mpeg4audio_sample_rates[*index];
> }
>
> -int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const uint8_t *buf,
> - int bit_size, int sync_extension)
> +int avpriv_mpeg4audio_get_config_gb(MPEG4AudioConfig *c, GetBitContext *gb,
> +int sync_extension)
Please, keep this new function internal (ff_ prefix) until it's actually
needed by libavformat.
> {
> -GetBitContext gb;
> int specific_config_bitindex, ret;
> -
> -if (bit_size <= 0)
> -return AVERROR_INVALIDDATA;
> -
> -ret = init_get_bits(&gb, buf, bit_size);
> -if (ret < 0)
> -return ret;
> -
> -c->object_type = get_object_type(&gb);
> -c->sample_rate = get_sample_rate(&gb, &c->sampling_index);
> -c->chan_config = get_bits(&gb, 4);
> +int start_bit_index = get_bits_count(gb);
> +c->object_type = get_object_type(gb);
> +c->sample_rate = get_sample_rate(gb, &c->sampling_index);
> +c->chan_config = get_bits(gb, 4);
> if (c->chan_config < FF_ARRAY_ELEMS(ff_mpeg4audio_channels))
> c->channels = ff_mpeg4audio_channels[c->chan_config];
> c->sbr = -1;
> c->ps = -1;
> if (c->object_type == AOT_SBR || (c->object_type == AOT_PS &&
> // check for W6132 Annex draft MP3onMP4
> -!(show_bits(&gb, 3) & 0x03 && !(show_bits(&gb, 9) & 0x3F {
> +!(show_bits(gb, 3) & 0x03 && !(show_bits(gb, 9) & 0x3F {
> if (c->object_type == AOT_PS)
> c->ps = 1;
> c->ext_object_type = AOT_SBR;
> c->sbr = 1;
> -c->ext_sample_rate = get_sample_rate(&gb, &c->ext_sampling_index);
> -c->object_type = get_object_type(&gb);
> +c->ext_sample_rate = get_sample_rate(gb, &c->ext_sampling_index);
> +c->object_type = get_object_type(gb);
> if (c->object_type == AOT_ER_BSAC)
> -c->ext_chan_config = get_bits(&gb, 4);
> +c->ext_chan_config = get_bits(gb, 4);
> } else {
> c->ext_object_type = AOT_NULL;
> c->ext_sample_rate = 0;
> }
> -specific_config_bitindex = get_bits_count(&gb);
> +specific_config_bitindex = get_bits_count(gb);
>
> if (c->object_type == AOT_ALS) {
> -skip_bits(&gb, 5);
> -if (show_bits_long(&gb, 24) != MKBETAG('\0','A','L','S'))
> -skip_bits_long(&gb, 24);
> +skip_bits(gb, 5);
> +if (show_bits_long(gb, 24) != MKBETAG('\0','A','L','S'))
> +skip_bits_long(gb, 24);
>
> -specific_config_bitindex = get_bits_count(&gb);
> +specific_config_bitindex = get_bits_count(gb);
>
> -ret = parse_config_ALS(&gb, c);
> +ret = parse_config_ALS(gb, c);
> if (ret < 0)
> return ret;
> }
>
> if (c->ext_object_type != AOT_SBR && sync_extension) {
> -while (get_bits_left(&gb) > 15) {
> -if (show_bits(&gb, 11) == 0x2b7) { // sync extension
> -get_bits(&gb, 11);
> -c->ext_object_type = get_object_type(&gb);
> -if (c->ext_object_type == AOT_SBR && (c->sbr =
> get_bits1(&gb)) == 1) {
> -c->ext_sample_rate = get_sample_rate(&gb,
> &c->ext_sampling_index);
> +while (get_bits_left(gb) > 15) {
> +if (show_bits(gb, 11) == 0x2b7) { // sync extension
> +get_bits(gb, 11);
> +c->ext_object_type = get_object_type(gb);
> +if (c->ext_object_type == AOT_SBR && (c->sbr =
> get_bits1(gb)) == 1) {
> +c->ext_sample_rate = get_sample_rate(gb,
> &c->ext_sampling_index);
> if (c->ext_sample_rate == c->sample_rate)
> c->sbr = -1;
> }
> -if (get_bits_left(&gb) > 11 && get_bits(&gb, 11) == 0x548)
> -c->ps = get_bits1(&gb);
> +if (get_bits_left(gb) > 11 && get_bits(gb, 11) == 0x548)
> +c->ps = get_bits1(gb);
> break;
> } else
> -get_bits1(&gb); // skip 1 bit
> +get_bits1(gb); // skip 1 bit
> }
> }
>
> @@ -157,7 +149,23 @@ int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c,
> const uint8_t *buf,
> if ((c->ps == -1 && c->object_type != AOT_AAC_LC) || c->channels & ~0x01)
> c->ps = 0;
>
> -return specific_config_bitindex;
> +return specific_config_bitindex - start_bit_index;
> +}
> +
> +int avpriv_mpeg4audio_get_config(MPEG4AudioConfig *c, const uint8_t *buf,
> + int bit_size, int sync_extension)
> +{
> +GetBit
Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.
On Thu, Feb 09, 2017 at 01:20:09PM +0100, Michael Niedermayer wrote:
[...]
> > int ff_mjpeg_encode_stuffing(MpegEncContext *s)
> > {
> > int i;
> > PutBitContext *pbc = &s->pb;
> > int mb_y = s->mb_y - !s->mb_x;
> >+int ret;
> >+MJpegContext *m;
> >+
> >+m = s->mjpeg_ctx;
> >+
> >+if (m->error)
> >+return m->error;
> >+
> >+if (s->huffman == HUFFMAN_TABLE_OPTIMAL) {
> >+ff_mjpeg_build_optimal_huffman(m);
> >+
> >+// Replace the VLCs with the optimal ones.
>
> >+// The default ones may be used for trellis during quantization.
> >+ff_init_uni_ac_vlc(m->huff_size_ac_luminance, m->uni_ac_vlc_len);
> >+ff_init_uni_ac_vlc(m->huff_size_ac_chrominance,
> >m->uni_chroma_ac_vlc_len);
>
> This is wrong and will break trellis with non default tables, trellis
> needs to use the same VLCs as are used for encoding. which if non
> default ones are used should be these non default ones
>
> the code generating the default tables wrote them in shared
> tables (uni*ac_vlc_len), now after the patch the default code is
> shared, called from 2 places and the tables moved into the context
> yet it still generates only the defau lt tables.
I did misread this part
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] omx: Add support for specifying H.264 profile [v3]
On 09/02/17 20:54, Mark Thompson wrote:
> On 08/02/17 19:21, Takayuki 'January June' Suwa wrote:
>> From: Takayuki 'January June' Suwa
>>
>> This adds "-profile[:v] profile_name"-style option IOW.
>>
>> Now default/unknown profile means FF_PROFILE_H264_HIGH strictly, for both
>> better coding style and preserving the original behavior.
>> ---
>> libavcodec/omx.c | 20
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/libavcodec/omx.c b/libavcodec/omx.c
>> index 16df50e..6ce71e9 100644
>> --- a/libavcodec/omx.c
>> +++ b/libavcodec/omx.c
>> @@ -226,6 +226,7 @@ typedef struct OMXCodecContext {
>> int output_buf_size;
>>
>> int input_zerocopy;
>> +int profile;
>> } OMXCodecContext;
>>
>> static void append_buffer(pthread_mutex_t *mutex, pthread_cond_t *cond,
>> @@ -523,6 +524,21 @@ static av_cold int omx_component_init(AVCodecContext
>> *avctx, const char *role)
>> CHECK(err);
>> avc.nBFrames = 0;
>> avc.nPFrames = avctx->gop_size - 1;
>> +switch (s->profile) {
>> +case FF_PROFILE_H264_BASELINE:
>> +avctx->profile = s->profile;
>
> AVCodecContext.profile is a user-set input field of AVCodecContext for
> encoders - you should only be reading it here, not writing to it (see
> ).
>
> I think the right thing to do here is to follow libx264 and do:
>
> if (s->profile is set) {
> use s->profile;
> } else if (avctx->profile is set) {
> use avctx->profile;
> } else {
> use the default profile (i.e. high);
> }
>
> See
>
> (the default is hidden inside libx264 by just not specifying the profile at
> all). While this ends up being equivalent for the ffmpeg utility, it makes
> it easier and more consistent for lavc users because they can use the common
> option to all encoders rather than having to set a private option for this
> encoder.
To clarify, since that was a bit unclear: if the user hasn't supplied any
particular profile then the default should be to not set the profile parameter
at all (i.e. let the OpenMAX implementation choose).
>> +avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
>> +break;
>> +case FF_PROFILE_H264_MAIN:
>> +avctx->profile = s->profile;
>> +avc.eProfile = OMX_VIDEO_AVCProfileMain;
>> +break;
>> +case FF_PROFILE_H264_HIGH:
>> +default:
>> +avctx->profile = s->profile;
>> +avc.eProfile = OMX_VIDEO_AVCProfileHigh;
>> +break;
>> +}
>> err = OMX_SetParameter(s->handle, OMX_IndexParamVideoAvc, &avc);
>> CHECK(err);
>> }
>> @@ -884,6 +900,10 @@ static const AVOption options[] = {
>> { "omx_libname", "OpenMAX library name", OFFSET(libname),
>> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
>> { "omx_libprefix", "OpenMAX library prefix", OFFSET(libprefix),
>> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
>> { "zerocopy", "Try to avoid copying input frames if possible",
>> OFFSET(input_zerocopy), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
>> +{ "profile", "Set the encoding profile", OFFSET(profile),
>> AV_OPT_TYPE_INT, { .i64 = 0 },0,
>> FF_PROFILE_H264_HIGH, VE, "profile" },
>> +{ "baseline", "", 0,
>> AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_BASELINE }, 0, 0, VE, "profile"
>> },
>> +{ "main", "", 0,
>> AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_MAIN }, 0, 0, VE, "profile"
>> },
>> +{ "high", "", 0,
>> AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_HIGH }, 0, 0, VE, "profile"
>> },
>> { NULL }
>> };
>
> The options look good to me now. (Slightly disappointed that it's baseline
> rather than constrained baseline, but I can see that that's an OpenMAX
> problem which we can't solve here.)
>
> Thanks,
>
> - Mark
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] rtpdec: fix negative missed packet count
Account for the RTP seq num restarting after 65535 when logging the
number of missed RTP packets.
Change-Id: I3510c2dfb830614e25f7b93de9b3b10aa724d00c
---
libavformat/rtpdec.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
index 53cdad7..c674060 100644
--- a/libavformat/rtpdec.c
+++ b/libavformat/rtpdec.c
@@ -748,9 +748,15 @@ static int rtp_parse_queued_packet(RTPDemuxContext *s,
AVPacket *pkt)
if (s->queue_len <= 0)
return -1;
-if (!has_next_packet(s))
+if (!has_next_packet(s)) {
+int missed = s->queue->seq - s->seq - 1;
+
+if (missed < 0)
+missed = UINT16_MAX - missed;
+
av_log(s->ic, AV_LOG_WARNING,
- "RTP: missed %d packets\n", s->queue->seq - s->seq - 1);
+ "RTP: missed %d packets\n", missed);
+}
/* Parse the first packet in the queue, and dequeue it */
rv = rtp_parse_packet_internal(s, pkt, s->queue->buf, s->queue->len);
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2017
Hi Pedro, On Thu, Feb 9, 2017 at 3:10 PM, Pedro Arthur wrote: > 2017-02-09 17:01 GMT-02:00 Ronald S. Bultje : > > > Before we get into adding new things to swscale: I will veto anything > that > > doesn't use the provided API in libavutil. So no new SWS_CS_*. > > > > Maybe is there something that doesn't use libavutil in swscale that can > be > turned in a qualification task? like port xxx to use libavutil? or yet a > full GSoC project? Just structure the new addition so it uses the libavutil API (AV_CSP_*). This isn't difficult. My condition is simply no new public API in swscale to deal with YCgCo, it should internally understand the external libavutil API. Applications should only need the (already-existing) libavutil API. Ideally a decoder can output ycgco and use swscale to convert this AVFrame and into a different AVFrame of any format (or size). As you see, conceptually no new API was needed, we just used avutil API (AVFrame with given colorspace). I just want to make sure we indeed implement it this way. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] omx: Add support for specifying H.264 profile [v3]
On 08/02/17 19:21, Takayuki 'January June' Suwa wrote:
> From: Takayuki 'January June' Suwa
>
> This adds "-profile[:v] profile_name"-style option IOW.
>
> Now default/unknown profile means FF_PROFILE_H264_HIGH strictly, for both
> better coding style and preserving the original behavior.
> ---
> libavcodec/omx.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/libavcodec/omx.c b/libavcodec/omx.c
> index 16df50e..6ce71e9 100644
> --- a/libavcodec/omx.c
> +++ b/libavcodec/omx.c
> @@ -226,6 +226,7 @@ typedef struct OMXCodecContext {
> int output_buf_size;
>
> int input_zerocopy;
> +int profile;
> } OMXCodecContext;
>
> static void append_buffer(pthread_mutex_t *mutex, pthread_cond_t *cond,
> @@ -523,6 +524,21 @@ static av_cold int omx_component_init(AVCodecContext
> *avctx, const char *role)
> CHECK(err);
> avc.nBFrames = 0;
> avc.nPFrames = avctx->gop_size - 1;
> +switch (s->profile) {
> +case FF_PROFILE_H264_BASELINE:
> +avctx->profile = s->profile;
AVCodecContext.profile is a user-set input field of AVCodecContext for encoders
- you should only be reading it here, not writing to it (see
).
I think the right thing to do here is to follow libx264 and do:
if (s->profile is set) {
use s->profile;
} else if (avctx->profile is set) {
use avctx->profile;
} else {
use the default profile (i.e. high);
}
See
(the default is hidden inside libx264 by just not specifying the profile at
all). While this ends up being equivalent for the ffmpeg utility, it makes it
easier and more consistent for lavc users because they can use the common
option to all encoders rather than having to set a private option for this
encoder.
(Apologies for missing this on the first read through.)
> +avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
> +break;
> +case FF_PROFILE_H264_MAIN:
> +avctx->profile = s->profile;
> +avc.eProfile = OMX_VIDEO_AVCProfileMain;
> +break;
> +case FF_PROFILE_H264_HIGH:
> +default:
> +avctx->profile = s->profile;
> +avc.eProfile = OMX_VIDEO_AVCProfileHigh;
> +break;
> +}
> err = OMX_SetParameter(s->handle, OMX_IndexParamVideoAvc, &avc);
> CHECK(err);
> }
> @@ -884,6 +900,10 @@ static const AVOption options[] = {
> { "omx_libname", "OpenMAX library name", OFFSET(libname),
> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
> { "omx_libprefix", "OpenMAX library prefix", OFFSET(libprefix),
> AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
> { "zerocopy", "Try to avoid copying input frames if possible",
> OFFSET(input_zerocopy), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
> +{ "profile", "Set the encoding profile", OFFSET(profile),
> AV_OPT_TYPE_INT, { .i64 = 0 },0,
> FF_PROFILE_H264_HIGH, VE, "profile" },
> +{ "baseline", "", 0,
> AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_BASELINE }, 0, 0, VE, "profile" },
> +{ "main", "", 0,
> AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_MAIN }, 0, 0, VE, "profile" },
> +{ "high", "", 0,
> AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_HIGH }, 0, 0, VE, "profile" },
> { NULL }
> };
The options look good to me now. (Slightly disappointed that it's baseline
rather than constrained baseline, but I can see that that's an OpenMAX problem
which we can't solve here.)
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cuvid: Always calculate second field PTS from frame rate
Dne 9.2.2017 v 07:49 wm4 napsal(a): On Wed, 8 Feb 2017 23:31:54 +0100 Miroslav Slugeň wrote: It is much more robust solution to always calculate second field (when deinterlacing) PTS from frame rate, then relating on previous PTS, because if there are B frames in input and some video frames are corrupted (dropped) it will calculate wrong PTS for second field and could hang on encoding in do_video_out. Seems more like it'd make it less robust, because many files don't have a useful framerate set. I'm not sure why encoding is hanging (?), but that sounds like a different problem. Also, such reasoning should go into the commit message, instead of just the mail. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I understand it now. I will try to find better solution, please ignore this patch. Primary reason is when using cuvid as decoder with copyts we had alotof audio/video sync issues when there was B frame in input stream and some data was missing (gape in PTS). M. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cuvid: Always calculate second field PTS from frame rate
Dne 8.2.2017 v 23:59 Carl Eugen Hoyos napsal(a): 2017-02-08 23:31 GMT+01:00 Miroslav Slugeň : It is much more robust solution to always calculate second field (when deinterlacing) PTS from frame rate Without looking at your patch, I would have guessed that not every stream has a useful frame rate. (It's 1000fps for asf input) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Ok, i didn't know that, so what about to calculate PTS diff only between non-B frames pictures? I also have patch for dropping second field when deinterlacing, should i commit it? M. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2017
2017-02-09 17:01 GMT-02:00 Ronald S. Bultje : > Before we get into adding new things to swscale: I will veto anything that > doesn't use the provided API in libavutil. So no new SWS_CS_*. > > Maybe is there something that doesn't use libavutil in swscale that can be turned in a qualification task? like port xxx to use libavutil? or yet a full GSoC project? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2017
On Thu, 9 Feb 2017 14:01:59 -0500 "Ronald S. Bultje" wrote: > Hi, > > On Wed, Feb 8, 2017 at 8:21 PM, Michael Niedermayer > wrote: > > > On Thu, Feb 09, 2017 at 01:03:06AM +0100, Michael Niedermayer wrote: > > > On Wed, Feb 08, 2017 at 09:07:09PM -0200, Pedro Arthur wrote: > > > > 2017-01-27 1:01 GMT-02:00 Michael Niedermayer : > > > > > > > > > we need more (backup) mentors, so yes, i think its needed > > > > > > > > > > also if you want to be mentor for a swscale related project i would > > > > > support that idea > > > > > > > > > > > > Hi, sorry for the late reply. > > > > I think implementing a cascade-less swscale could be a good project. > > > > If you think it is doable for a GSOC project, I'm fine with it. > > > > > > It depends on the student, it doesnt sound too complex but students > > > abilities varies alot and its quite possible there will be noone > > > interrested in any specific project > > > > > > > > > > I just doesn't know a good qualification task. > > > > > > Something which shows that the student can work with the swscale > > > codebase, not something that is just copy and paste work > > > > > > Either way, this can be added later > > > > also in absence of any other ideas, YCoCg support may be a > > qualification task. Maybe not the best choice but certainly usefull > > on its own > > > Before we get into adding new things to swscale: I will veto anything that > doesn't use the provided API in libavutil. So no new SWS_CS_*. > > And yes I'm serious about this. That should be self-evident and not an issue. Did anyone argue for it? (Also wondering if I should revive my ancient libswscale + AVFrame patch.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2017
Hi, On Wed, Feb 8, 2017 at 8:21 PM, Michael Niedermayer wrote: > On Thu, Feb 09, 2017 at 01:03:06AM +0100, Michael Niedermayer wrote: > > On Wed, Feb 08, 2017 at 09:07:09PM -0200, Pedro Arthur wrote: > > > 2017-01-27 1:01 GMT-02:00 Michael Niedermayer : > > > > > > > we need more (backup) mentors, so yes, i think its needed > > > > > > > > also if you want to be mentor for a swscale related project i would > > > > support that idea > > > > > > > > > Hi, sorry for the late reply. > > > I think implementing a cascade-less swscale could be a good project. > > > If you think it is doable for a GSOC project, I'm fine with it. > > > > It depends on the student, it doesnt sound too complex but students > > abilities varies alot and its quite possible there will be noone > > interrested in any specific project > > > > > > > I just doesn't know a good qualification task. > > > > Something which shows that the student can work with the swscale > > codebase, not something that is just copy and paste work > > > > Either way, this can be added later > > also in absence of any other ideas, YCoCg support may be a > qualification task. Maybe not the best choice but certainly usefull > on its own Before we get into adding new things to swscale: I will veto anything that doesn't use the provided API in libavutil. So no new SWS_CS_*. And yes I'm serious about this. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] omx: Add support for specifying H.264 profile [v3]
From: Takayuki 'January June' Suwa
This adds "-profile[:v] profile_name"-style option IOW.
Now default/unknown profile means FF_PROFILE_H264_HIGH strictly, for both
better coding style and preserving the original behavior.
---
libavcodec/omx.c | 20
1 file changed, 20 insertions(+)
diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index 16df50e..6ce71e9 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -226,6 +226,7 @@ typedef struct OMXCodecContext {
int output_buf_size;
int input_zerocopy;
+int profile;
} OMXCodecContext;
static void append_buffer(pthread_mutex_t *mutex, pthread_cond_t *cond,
@@ -523,6 +524,21 @@ static av_cold int omx_component_init(AVCodecContext
*avctx, const char *role)
CHECK(err);
avc.nBFrames = 0;
avc.nPFrames = avctx->gop_size - 1;
+switch (s->profile) {
+case FF_PROFILE_H264_BASELINE:
+avctx->profile = s->profile;
+avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
+break;
+case FF_PROFILE_H264_MAIN:
+avctx->profile = s->profile;
+avc.eProfile = OMX_VIDEO_AVCProfileMain;
+break;
+case FF_PROFILE_H264_HIGH:
+default:
+avctx->profile = s->profile;
+avc.eProfile = OMX_VIDEO_AVCProfileHigh;
+break;
+}
err = OMX_SetParameter(s->handle, OMX_IndexParamVideoAvc, &avc);
CHECK(err);
}
@@ -884,6 +900,10 @@ static const AVOption options[] = {
{ "omx_libname", "OpenMAX library name", OFFSET(libname),
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
{ "omx_libprefix", "OpenMAX library prefix", OFFSET(libprefix),
AV_OPT_TYPE_STRING, { 0 }, 0, 0, VDE },
{ "zerocopy", "Try to avoid copying input frames if possible",
OFFSET(input_zerocopy), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
+{ "profile", "Set the encoding profile", OFFSET(profile),
AV_OPT_TYPE_INT, { .i64 = 0 },0,
FF_PROFILE_H264_HIGH, VE, "profile" },
+{ "baseline", "", 0,
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_BASELINE }, 0, 0, VE, "profile" },
+{ "main", "", 0,
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_MAIN }, 0, 0, VE, "profile" },
+{ "high", "", 0,
AV_OPT_TYPE_CONST, { .i64 = FF_PROFILE_H264_HIGH }, 0, 0, VE, "profile" },
{ NULL }
};
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [community vote] add devs to -security alias
nevermind , bad idea. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [community vote] add devs to -security alias
On Thu, Feb 09, 2017 at 12:50:48PM -0500, Compn wrote: > as stated , this is a community issue, so heres the vote thread. > > vote to add kieran and wm4 to ffmpeg-security email alias. > > any votes for or against? > votes will be tallied in 2 weeks. active committers/contributors will be > counted. > > if you have ideas for how the -security should be handled, make a new > thread. > > if you have comments about anything else, please make a different > thread or talk on irc. > > this is the vote thread only. please oh please, just can we have one > simple vote thread with no off-topic or flames? just once? > > "i vote for kieran and wm4 to be added to the ffmpeg-security email" The vote should be on the rule not the people. As in what kind of people should be on the security list. I mean seriously, we dont discuss if everyone, all maintainers, everyone who wants to be, or only everyone who needs to be or ... should be there but we vote if 2 specific people should be added ?! thats like voting who should get a driving license instead of what tests one need to pass to get a driving license I think that would be really bad for driving saftey. and IMO it cannot be good for ffmpeg security if we do this [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] aac_latm: Copy whole AudioSpecificConfig when it is sized.
This preserves sync extensions.
---
libavcodec/aacdec.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index 709ac7cdf8..08d92fe145 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -289,17 +289,19 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
int sync_extension= 0;
int bits_consumed, esize, i;
-if (asclen) {
+if (asclen > 0) {
sync_extension = 1;
asclen = FFMIN(asclen, get_bits_left(gb));
-} else
-asclen = get_bits_left(gb);
-
-if (asclen <= 0)
+init_get_bits(&gbc, gb->buffer, config_start_bit + asclen);
+skip_bits_long(&gbc, config_start_bit);
+} else if (asclen == 0) {
+gbc = *gb;
+} else {
return AVERROR_INVALIDDATA;
+}
-init_get_bits(&gbc, gb->buffer, config_start_bit + asclen);
-skip_bits_long(&gbc, config_start_bit);
+if (get_bits_left(gb) <= 0)
+return AVERROR_INVALIDDATA;
bits_consumed = decode_audio_specific_config_gb(NULL, avctx, &m4ac,
&gbc, config_start_bit,
@@ -309,6 +311,9 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
return AVERROR_INVALIDDATA;
bits_consumed -= config_start_bit;
+if (asclen == 0)
+ asclen = bits_consumed;
+
if (!latmctx->initialized ||
ac->oc[1].m4ac.sample_rate != m4ac.sample_rate ||
ac->oc[1].m4ac.chan_config != m4ac.chan_config) {
@@ -320,7 +325,7 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
}
latmctx->initialized = 0;
-esize = (bits_consumed+7) / 8;
+esize = (asclen + 7) / 8;
if (avctx->extradata_size < esize) {
av_free(avctx->extradata);
@@ -336,9 +341,9 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
}
memset(avctx->extradata+esize, 0, AV_INPUT_BUFFER_PADDING_SIZE);
}
-skip_bits_long(gb, bits_consumed);
+skip_bits_long(gb, asclen);
-return bits_consumed;
+return 0;
}
static int read_stream_mux_config(struct LATMContext *latmctx,
@@ -379,8 +384,6 @@ static int read_stream_mux_config(struct LATMContext
*latmctx,
int ascLen = latm_get_value(gb);
if ((ret = latm_decode_audio_specific_config(latmctx, gb, ascLen))
< 0)
return ret;
-ascLen -= ret;
-skip_bits_long(gb, ascLen);
}
latmctx->frame_length_type = get_bits(gb, 3);
--
2.11.0.483.g087da7b7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [community vote] add devs to -security alias
as stated , this is a community issue, so heres the vote thread. vote to add kieran and wm4 to ffmpeg-security email alias. any votes for or against? votes will be tallied in 2 weeks. active committers/contributors will be counted. if you have ideas for how the -security should be handled, make a new thread. if you have comments about anything else, please make a different thread or talk on irc. this is the vote thread only. please oh please, just can we have one simple vote thread with no off-topic or flames? just once? "i vote for kieran and wm4 to be added to the ffmpeg-security email" -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] aac_latm: Align inband PCE to the start of the payload
A strict reading of the spec seems to imply that it should be aligned to
the start of the element instance tag, but that would break all of the
samples with PCEs.
It seems like a well formed LATM stream should have its PCE in the ASC
rather than inband.
Fixes ticket 4544
---
libavcodec/aacdec_template.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 6654416e69..1f14a1cbae 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -2949,6 +2949,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
int err, elem_id;
int samples = 0, multiplier, audio_found = 0, pce_found = 0;
int is_dmono, sce_count = 0;
+int payload_alignment;
ac->frame = data;
@@ -2971,6 +2972,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
// This may lead to an undefined profile being signaled
ac->avctx->profile = ac->oc[1].m4ac.object_type - 1;
+payload_alignment = get_bits_count(gb);
ac->tags_mapped = 0;
// parse
while ((elem_type = get_bits(gb, 3)) != TYPE_END) {
@@ -3025,7 +3027,8 @@ static int aac_decode_frame_int(AVCodecContext *avctx,
void *data,
uint8_t layout_map[MAX_ELEM_ID*4][3];
int tags;
push_output_configuration(ac);
-tags = decode_pce(avctx, &ac->oc[1].m4ac, layout_map, gb, 0);
+tags = decode_pce(avctx, &ac->oc[1].m4ac, layout_map, gb,
+ payload_alignment);
if (tags < 0) {
err = tags;
break;
--
2.11.0.483.g087da7b7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] aac_latm: Allow unaligned AudioSpecificConfig
Fixes ticket 4730
---
libavcodec/aacdec.c | 26 --
libavcodec/aacdec_template.c | 82
libavcodec/mpeg4audio.c | 76 ++--
libavcodec/mpeg4audio.h | 12 ++-
4 files changed, 120 insertions(+), 76 deletions(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index ee9b4eb45f..709ac7cdf8 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -284,9 +284,10 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
AACContext *ac= &latmctx->aac_ctx;
AVCodecContext *avctx = ac->avctx;
MPEG4AudioConfig m4ac = { 0 };
+GetBitContext gbc;
int config_start_bit = get_bits_count(gb);
int sync_extension= 0;
-int bits_consumed, esize;
+int bits_consumed, esize, i;
if (asclen) {
sync_extension = 1;
@@ -294,19 +295,19 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
} else
asclen = get_bits_left(gb);
-if (config_start_bit % 8) {
-avpriv_request_sample(latmctx->aac_ctx.avctx,
- "Non-byte-aligned audio-specific config");
-return AVERROR_PATCHWELCOME;
-}
if (asclen <= 0)
return AVERROR_INVALIDDATA;
-bits_consumed = decode_audio_specific_config(NULL, avctx, &m4ac,
- gb->buffer + (config_start_bit / 8),
- asclen, sync_extension);
-if (bits_consumed < 0)
+init_get_bits(&gbc, gb->buffer, config_start_bit + asclen);
+skip_bits_long(&gbc, config_start_bit);
+
+bits_consumed = decode_audio_specific_config_gb(NULL, avctx, &m4ac,
+&gbc, config_start_bit,
+sync_extension);
+
+if (bits_consumed < config_start_bit)
return AVERROR_INVALIDDATA;
+bits_consumed -= config_start_bit;
if (!latmctx->initialized ||
ac->oc[1].m4ac.sample_rate != m4ac.sample_rate ||
@@ -329,7 +330,10 @@ static int latm_decode_audio_specific_config(struct
LATMContext *latmctx,
}
avctx->extradata_size = esize;
-memcpy(avctx->extradata, gb->buffer + (config_start_bit/8), esize);
+gbc = *gb;
+for (i = 0; i < esize; i++) {
+ avctx->extradata[i] = get_bits(&gbc, 8);
+}
memset(avctx->extradata+esize, 0, AV_INPUT_BUFFER_PADDING_SIZE);
}
skip_bits_long(gb, bits_consumed);
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 83e9fb55ba..2a06f82efe 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -715,6 +715,13 @@ static void decode_channel_map(uint8_t layout_map[][3],
}
}
+static inline void relative_align_get_bits(GetBitContext *gb,
+ int reference_position) {
+int n = (reference_position - get_bits_count(gb) & 7);
+if (n)
+skip_bits(gb, n);
+}
+
/**
* Decode program configuration element; reference: table 4.2.
*
@@ -722,7 +729,7 @@ static void decode_channel_map(uint8_t layout_map[][3],
*/
static int decode_pce(AVCodecContext *avctx, MPEG4AudioConfig *m4ac,
uint8_t (*layout_map)[3],
- GetBitContext *gb)
+ GetBitContext *gb, int byte_align_ref)
{
int num_front, num_side, num_back, num_lfe, num_assoc_data, num_cc;
int sampling_index;
@@ -770,7 +777,7 @@ static int decode_pce(AVCodecContext *avctx,
MPEG4AudioConfig *m4ac,
decode_channel_map(layout_map + tags, AAC_CHANNEL_CC,gb, num_cc);
tags += num_cc;
-align_get_bits(gb);
+relative_align_get_bits(gb, byte_align_ref);
/* comment field, first byte is length */
comment_len = get_bits(gb, 8) * 8;
@@ -792,6 +799,7 @@ static int decode_pce(AVCodecContext *avctx,
MPEG4AudioConfig *m4ac,
*/
static int decode_ga_specific_config(AACContext *ac, AVCodecContext *avctx,
GetBitContext *gb,
+ int get_bit_alignment,
MPEG4AudioConfig *m4ac,
int channel_config)
{
@@ -815,7 +823,7 @@ static int decode_ga_specific_config(AACContext *ac,
AVCodecContext *avctx,
if (channel_config == 0) {
skip_bits(gb, 4); // element_instance_tag
-tags = decode_pce(avctx, m4ac, layout_map, gb);
+tags = decode_pce(avctx, m4ac, layout_map, gb, get_bit_alignment);
if (tags < 0)
return tags;
} else {
@@ -937,37 +945,25 @@ static int decode_eld_specific_config(AACContext *ac,
AVCodecContext *avctx,
* @param ac pointer to AACContext, may be null
* @param avctx pointer to AVCCodecContext, used for logging
* @param m4acpointer to MPEG4AudioCo
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/huffyuvencdsp: use an actual unsigned long constant
On Wed, Feb 08, 2017 at 01:13:57PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/huffyuvencdsp.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] aacsbr: Associate SBR data with AAC elements on init
Quiets some log spam on pure upsampling mode.
---
libavcodec/aacdec_template.c | 2 +-
libavcodec/aacsbr.h | 2 +-
libavcodec/aacsbr_template.c | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 2a06f82efe..6654416e69 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -134,7 +134,7 @@ static av_cold int che_configure(AACContext *ac,
if (!ac->che[type][id]) {
if (!(ac->che[type][id] = av_mallocz(sizeof(ChannelElement
return AVERROR(ENOMEM);
-AAC_RENAME(ff_aac_sbr_ctx_init)(ac, &ac->che[type][id]->sbr);
+AAC_RENAME(ff_aac_sbr_ctx_init)(ac, &ac->che[type][id]->sbr, type);
}
if (type != TYPE_CCE) {
if (*channels >= MAX_CHANNELS - (type == TYPE_CPE || (type ==
TYPE_SCE && ac->oc[1].m4ac.ps == 1))) {
diff --git a/libavcodec/aacsbr.h b/libavcodec/aacsbr.h
index 88c4d8a916..dd8b66c7bb 100644
--- a/libavcodec/aacsbr.h
+++ b/libavcodec/aacsbr.h
@@ -81,7 +81,7 @@ static const int8_t vlc_sbr_lav[10] =
/** Initialize SBR. */
void AAC_RENAME(ff_aac_sbr_init)(void);
/** Initialize one SBR context. */
-void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication
*sbr);
+void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac, SpectralBandReplication
*sbr, int id_aac);
/** Close one SBR context. */
void AAC_RENAME(ff_aac_sbr_ctx_close)(SpectralBandReplication *sbr);
/** Decode one SBR element. */
diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index 511054276a..f8aa4854df 100644
--- a/libavcodec/aacsbr_template.c
+++ b/libavcodec/aacsbr_template.c
@@ -81,11 +81,12 @@ static void sbr_turnoff(SpectralBandReplication *sbr) {
memset(&sbr->spectrum_params, -1, sizeof(SpectrumParameters));
}
-av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac,
SpectralBandReplication *sbr)
+av_cold void AAC_RENAME(ff_aac_sbr_ctx_init)(AACContext *ac,
SpectralBandReplication *sbr, int id_aac)
{
if(sbr->mdct.mdct_bits)
return;
sbr->kx[0] = sbr->kx[1];
+sbr->id_aac = id_aac;
sbr_turnoff(sbr);
sbr->data[0].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE
- (1280 - 128);
sbr->data[1].synthesis_filterbank_samples_offset = SBR_SYNTHESIS_BUF_SIZE
- (1280 - 128);
--
2.11.0.483.g087da7b7c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/huffyuvdsp: use an actual unsigned long constant
On Wed, Feb 08, 2017 at 01:13:56PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > Decent compilers are smart enough to truncate those ULL constants on targets > where long is 32 bits (and do things like shift+and/add instead of mul). > This is for those that are not. > > libavcodec/huffyuvdsp.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list
> > > > > > > I dont think we should give access to ffmpeg-security to everyone who > > > wants to be on the list. This is of course something the community > > > has to decide and not me, iam just err-ing on the safe side and am very > > > restrictive on who is added. > > > > > > > This is a bogus argument considering how many people have commit access > and > > can commit whatever. > > honestly with the fearmongering? are you saying the russian ffmpeg > developers can just commit whatever they want whenever they want?! also > there are some chinese ffmpeg developers! even the president says china > cant be trusted! the russians hacked the election and now they will put > backdoors in ffmpeg!?!?! > > (this email is satire btw... i do not believe russia affected the us > election, nor brexit. and china is cool with me.) > Your conspiracy theory emails are always a pleasure to read. (this email is also satire btw) Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] new videofilters and parellelization
Am 09.02.17 um 16:01 schrieb Daniel Oberhoff: > [...] > we would like to contribute this back to ffmpeg as it may be useful > for others. do you think so to? if so, should we send one big patch > or split it up somehow? Yes. Try to conform to our developer documentation at http://ffmpeg.org/developer.html and send separate patches for each logical change you've made to ffmpeg. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] dashenc: properly determine bandwidth
based on ligverds patch from
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199183.html
---
libavformat/dashenc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 534fa75..18c39c5 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -498,17 +498,15 @@ static int write_manifest(AVFormatContext *s, int final)
OutputStream *os = &c->streams[0];
int start_index = FFMAX(os->nb_segments - c->window_size, 0);
int64_t start_time = av_rescale_q(os->segments[start_index]->time,
s->streams[0]->time_base, AV_TIME_BASE_Q);
-avio_printf(out, "\t\n");
} else {
-avio_printf(out, "\t\n");
+avio_printf(out, "\t\n",final?"":"
id=\"0\"");
}
if (c->has_video) {
avio_printf(out, "\t\tmax_frame_rate.num && !c->ambiguous_frame_rate)
-avio_printf(out, " %s=\"%d/%d\"", (av_cmp_q(c->min_frame_rate,
c->max_frame_rate) < 0) ? "maxFrameRate" : "frameRate", c->max_frame_rate.num,
c->max_frame_rate.den);
avio_printf(out, ">\n");
for (i = 0; i < s->nb_streams; i++) {
@@ -594,11 +592,13 @@ static int dash_init(AVFormatContext *s)
AVDictionary *opts = NULL;
char filename[1024];
-os->bit_rate = s->streams[i]->codecpar->bit_rate;
+os->bit_rate = s->streams[i]->codecpar->bit_rate ?
s->streams[i]->codecpar->bit_rate : s->bit_rate;
if (os->bit_rate) {
snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
" bandwidth=\"%d\"", os->bit_rate);
} else {
+snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
+ " bandwidth=\"%d\"", 0);
int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ?
AV_LOG_ERROR : AV_LOG_WARNING;
av_log(s, level, "No bit rate set for stream %d\n", i);
--
2.9.3 (Apple Git-75)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] dashenc: add profile_identifier option
sets the MPEG-DASH profile identifier in the header (for example for
specifying on-demand vs default live profile)
Signed-off-by: Sol Bekic
---
libavformat/dashenc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 18c39c5..0c06474 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -96,6 +96,7 @@ typedef struct DASHContext {
const char *single_file_name;
const char *init_seg_name;
const char *media_seg_name;
+const char *profile_identifier;
AVRational min_frame_rate, max_frame_rate;
int ambiguous_frame_rate;
} DASHContext;
@@ -457,8 +458,8 @@ static int write_manifest(AVFormatContext *s, int final)
"\txmlns=\"urn:mpeg:dash:schema:mpd:2011\"\n"
"\txmlns:xlink=\"http://www.w3.org/1999/xlink\"\n";
"\txsi:schemaLocation=\"urn:mpeg:DASH:schema:MPD:2011
http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd\"\n";
-"\tprofiles=\"urn:mpeg:dash:profile:isoff-live:2011\"\n"
-"\ttype=\"%s\"\n", final ? "static" : "dynamic");
+"\tprofiles=\"%s\"\n", c->profile_identifier);
+avio_printf(out, "\ttype=\"%s\"\n", final ? "static" : "dynamic");
if (final) {
avio_printf(out, "\tmediaPresentationDuration=\"");
write_time(out, c->total_duration);
@@ -1028,6 +1029,7 @@ static const AVOption options[] = {
{ "single_file_name", "DASH-templated name to be used for baseURL. Implies
storing all segments in one file, accessed using byte ranges",
OFFSET(single_file_name), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
{ "init_seg_name", "DASH-templated name to used for the initialization
segment", OFFSET(init_seg_name), AV_OPT_TYPE_STRING, {.str =
"init-stream$RepresentationID$.m4s"}, 0, 0, E },
{ "media_seg_name", "DASH-templated name to used for the media segments",
OFFSET(media_seg_name), AV_OPT_TYPE_STRING, {.str =
"chunk-stream$RepresentationID$-$Number%05d$.m4s"}, 0, 0, E },
+{ "profile_identifier", "DASH profile identifier",
OFFSET(profile_identifier), AV_OPT_TYPE_STRING, {.str =
"urn:mpeg:dash:profile:isoff-live:2011"}, 0, 0, E },
{ NULL },
};
--
2.9.3 (Apple Git-75)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list
On 2/9/2017 10:24 AM, Kieran Kunhya wrote: >> >> I dont think we should give access to ffmpeg-security to everyone who >> wants to be on the list. This is of course something the community >> has to decide and not me, iam just err-ing on the safe side and am very >> restrictive on who is added. >> > > This is a bogus argument considering how many people have commit access and > can commit whatever. > > Kieran There's a big difference between git commit access, where bad or rogue commits can be easily undone, and access to the security email address, where 0 day exploits and full steps to reproduce may be available. You and wm4 should IMO be ok to be in it, but we really need to set some limits and requirements and not offer access like candy as we have been doing with git, otherwise the joke about running ffmpeg behind three layers of sandboxing will become an actually tempting idea to anyone wanting to use it from now on. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list
On Thu, Feb 09, 2017 at 03:29:40PM +0100, Paul B Mahol wrote: > On 2/9/17, Michael Niedermayer wrote: > > On Thu, Feb 09, 2017 at 08:25:43AM +0100, wm4 wrote: > >> On Wed, 8 Feb 2017 22:07:24 +0100 > >> Michael Niedermayer wrote: > >> > >> > Hi all > >> > > >> > On Sat, Aug 08, 2015 at 03:51:11AM +0200, Michael Niedermayer wrote: > >> > > On Fri, Aug 07, 2015 at 07:46:55PM -0400, compn wrote: > >> > > > hello, > >> > > > > >> > > > some of you know that we have a list for security / CVE issues. > >> > > > some of you did not know this. > >> > > > > >> > > > i think it is a private list due to not wanting people to make > >> > > > exploits > >> > > > before we have a chance to fix them. of course, if no one is > >> > > > subscribed > >> > > > to review/fix issues then they will never get fixed. > >> > > > > >> > > > so if you are a regular developer who wants access to this list, > >> > > > please > >> > > > speak up. > >> > > > > >> > > > i do not run nor admin the security email/list (nor do i know who > >> > > > does) > >> > > > so please dont ask me questions about it. > >> > > > >> > > I guess, i "de facto" admin the security "email/list". > >> > > if someone wants to help with security issues, mail me > >> > > > >> > > but there are no open security issues and if there was one i very > >> > > likely would fix it ASAP > >> > > >> > A small update due to never? before seen interrest in ffmpeg-security > >> > in the recent weeks/months > >> > > >> > How to get on the ffmpeg-security "list" > >> > > >> > People working on security in FFmpeg, thats maybe fixing many coverity > >> > issues, backporingt fixes to releases, maintaining FFmpeg releases, ... > >> > have an obsession with fixing bugs about undefined behavior or bugs > >> > about crashes and race conditions on trac. Or an obsession with testing > >> > every bugfix and who want and need access to ffmpeg-security should > >> > be on ffmpeg-security > >> > In short people on ffmpeg-security should need to be on ffmpeg-security > >> > If you fall in this kind of category, please mail me > >> > > >> > Or someone who reviews commits and obtains CVE#s for everything that > >> > could be exploitable ... > >> > > >> > I dont think we should give access to ffmpeg-security to everyone who > >> > wants to be on the list. This is of course something the community > >> > has to decide and not me, iam just err-ing on the safe side and am very > >> > restrictive on who is added. > >> > > >> > About the content i must warn you the list is really not very > >> > interresting as in trying to find together with debian someone at > >> > chromium who knows what the CVEs they registered about FFmpeg actually > >> > are about ... and then it embarassingly is a patch on ffmpeg-devel > >> > that is stuck in review and not applied and now i can redo the releases > >> > ... > >> > ... Where are the people caring about security ? why did they not > >> > pick these 2 public patches up, change what they felt needs changing > >> > and pushed them ? > >> > and there are the fuzz samples that need more than 20sec, these are > >> > the main type of reported issue recently after ive succeeded to stop > >> > the oom kind. > >> > > >> > Also there are no open security(*) issues i know of, and if there would > >> > be i likely would fix them ASAP. Not saying that help is unwelcome > >> > or that its impossible for me to make a mistake or miss something ... > >> > > >> > (*) I assume here that fuzz samples taking more than 20sec or integer > >> > overflows in DSP code arent security issues. Iam working on fixing > >> > these too but for this category there are open issues. > >> > > >> > PS: If you want access to the oss-fuzz reports, they all seem > >> > automatically public 7 days after being fixed > >> > > >> > [...] > >> > > >> > >> I'd like to get on the ffmpeg-security mailing list to review patches. > > > > Thats appreciated, though theres a problem, there rarely are patches > > on that "list". Besides there is no mailing list this is just a mail > > alias > > > > if i search for "~cffmpeg-security ~b\\+\\+\\+" i see only 54 matches > > in the whole history of the list in my inbox most of which are > > duplicates in quotes of replies > > so maybe there were less than 20 patches ever posted to that list. > > also patches tend to be CC-ed to developers knowing the code or commit > > related to a issue, like ronald and james for the http fix in december > > or paul and martin for the exr patch in august > > > > If the community wants me to add every FFmpeg maintainer who wants > > to be on the alias, i can do that. But in the absence of a clear > > community decission (poll/vote) on the inclusion criteria iam reluctant > > to add anyone without a strong reason. There occasionally is > > information or files posted that could be used in the construction of > > an exploit prior to everyone updating, so the fewer addresses it is > > sent to the better. > > So others are sending CVE r
[FFmpeg-devel] new videofilters and parellelization
Hello all, We do some performance critical processing with ffmpeg involving image scaling and warping. To support this we did implemented some new algorithms and parallelized one. 1. parallelize remap 2. implement remap_frac that interprets data as 13.3 fixed point (i.e. 3 bits for subpixel warping) 3. implement halve that makes the image exactly halve size and is faster than using scale we would like to contribute this back to ffmpeg as it may be useful for others. do you think so to? if so, should we send one big patch or split it up somehow? Best Daniel Oberhoff ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list
On Thu, Feb 09, 2017 at 09:07:39AM -0500, Compn wrote: > On Thu, 09 Feb 2017 13:24:53 +, Kieran Kunhya > wrote: > > > > > > > I dont think we should give access to ffmpeg-security to everyone who > > > wants to be on the list. This is of course something the community > > > has to decide and not me, iam just err-ing on the safe side and am very > > > restrictive on who is added. > > > > > > > This is a bogus argument considering how many people have commit access and > > can commit whatever. > > honestly with the fearmongering? are you saying the russian ffmpeg > developers can just commit whatever they want whenever they want?! also > there are some chinese ffmpeg developers! even the president says china > cant be trusted! the russians hacked the election and now they will put > backdoors in ffmpeg!?!?! > > (this email is satire btw... i do not believe russia affected the us > election, nor brexit. and china is cool with me.) > > if kierank and wm4 want on the -security list, please put them on the > security list. > i doubt anyone will vote against their inclusion on the > list. maybe, but does anyone really think thats how ffmpeg-security should be run ? I think FFmpeg has a very good security history, theres a "name" to loose here. My oppinion is that there should be a rule whatever that rule is, and the community should decide this rule. If the community wants only people who need access for their work in FFmpeg to have access to ffmpeg-security then thats the rule. If the community wants every FFmpeg maintainer who wants to be on the alias to be added, then thats the rule. We can do more or less or between these 2 but theres a relation between what we do and how professional this is. For example giving everyone access to security would likely be seen with some distrust by companies and security researchers. And the proportion of security mails being sent to ffmpeg-security might drop as a result of that. I mean if you were a company who has customers and has a warranty/ obligation toward them, would you post details about security issues to a semi public list ? Which if leaked before its fixed could cause massive damage to your customers and indirectly to your company? Also our users depend on security stuff staying private until issues are fixed ... All this is why iam for a very restrictive policy on who can access the ffmpeg-security stuff. -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list
On Thu, 9 Feb 2017 15:27:03 +0100 Michael Niedermayer wrote: > On Thu, Feb 09, 2017 at 08:25:43AM +0100, wm4 wrote: > > On Wed, 8 Feb 2017 22:07:24 +0100 > > Michael Niedermayer wrote: > > > > > Hi all > > > > > > On Sat, Aug 08, 2015 at 03:51:11AM +0200, Michael Niedermayer wrote: > > > > On Fri, Aug 07, 2015 at 07:46:55PM -0400, compn wrote: > > > > > hello, > > > > > > > > > > some of you know that we have a list for security / CVE issues. > > > > > some of you did not know this. > > > > > > > > > > i think it is a private list due to not wanting people to make > > > > > exploits > > > > > before we have a chance to fix them. of course, if no one is > > > > > subscribed > > > > > to review/fix issues then they will never get fixed. > > > > > > > > > > so if you are a regular developer who wants access to this list, > > > > > please > > > > > speak up. > > > > > > > > > > i do not run nor admin the security email/list (nor do i know who > > > > > does) > > > > > so please dont ask me questions about it. > > > > > > > > I guess, i "de facto" admin the security "email/list". > > > > if someone wants to help with security issues, mail me > > > > > > > > but there are no open security issues and if there was one i very > > > > likely would fix it ASAP > > > > > > A small update due to never? before seen interrest in ffmpeg-security > > > in the recent weeks/months > > > > > > How to get on the ffmpeg-security "list" > > > > > > People working on security in FFmpeg, thats maybe fixing many coverity > > > issues, backporingt fixes to releases, maintaining FFmpeg releases, ... > > > have an obsession with fixing bugs about undefined behavior or bugs > > > about crashes and race conditions on trac. Or an obsession with testing > > > every bugfix and who want and need access to ffmpeg-security should > > > be on ffmpeg-security > > > In short people on ffmpeg-security should need to be on ffmpeg-security > > > If you fall in this kind of category, please mail me > > > > > > Or someone who reviews commits and obtains CVE#s for everything that > > > could be exploitable ... > > > > > > I dont think we should give access to ffmpeg-security to everyone who > > > wants to be on the list. This is of course something the community > > > has to decide and not me, iam just err-ing on the safe side and am very > > > restrictive on who is added. > > > > > > About the content i must warn you the list is really not very > > > interresting as in trying to find together with debian someone at > > > chromium who knows what the CVEs they registered about FFmpeg actually > > > are about ... and then it embarassingly is a patch on ffmpeg-devel > > > that is stuck in review and not applied and now i can redo the releases > > > ... > > > ... Where are the people caring about security ? why did they not > > > pick these 2 public patches up, change what they felt needs changing > > > and pushed them ? > > > and there are the fuzz samples that need more than 20sec, these are > > > the main type of reported issue recently after ive succeeded to stop > > > the oom kind. > > > > > > Also there are no open security(*) issues i know of, and if there would > > > be i likely would fix them ASAP. Not saying that help is unwelcome > > > or that its impossible for me to make a mistake or miss something ... > > > > > > (*) I assume here that fuzz samples taking more than 20sec or integer > > > overflows in DSP code arent security issues. Iam working on fixing > > > these too but for this category there are open issues. > > > > > > PS: If you want access to the oss-fuzz reports, they all seem > > > automatically public 7 days after being fixed > > > > > > [...] > > > > > > > I'd like to get on the ffmpeg-security mailing list to review patches. > > Thats appreciated, though theres a problem, there rarely are patches > on that "list". Besides there is no mailing list this is just a mail > alias > > if i search for "~cffmpeg-security ~b\\+\\+\\+" i see only 54 matches > in the whole history of the list in my inbox most of which are > duplicates in quotes of replies > so maybe there were less than 20 patches ever posted to that list. > also patches tend to be CC-ed to developers knowing the code or commit > related to a issue, like ronald and james for the http fix in december > or paul and martin for the exr patch in august If every patch on ffmpeg-security is posted to ffmpeg-devel too, and if every such patch is clearly marked as security relevant, I won't insist on being added. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list
On 2/9/17, Michael Niedermayer wrote: > On Thu, Feb 09, 2017 at 08:25:43AM +0100, wm4 wrote: >> On Wed, 8 Feb 2017 22:07:24 +0100 >> Michael Niedermayer wrote: >> >> > Hi all >> > >> > On Sat, Aug 08, 2015 at 03:51:11AM +0200, Michael Niedermayer wrote: >> > > On Fri, Aug 07, 2015 at 07:46:55PM -0400, compn wrote: >> > > > hello, >> > > > >> > > > some of you know that we have a list for security / CVE issues. >> > > > some of you did not know this. >> > > > >> > > > i think it is a private list due to not wanting people to make >> > > > exploits >> > > > before we have a chance to fix them. of course, if no one is >> > > > subscribed >> > > > to review/fix issues then they will never get fixed. >> > > > >> > > > so if you are a regular developer who wants access to this list, >> > > > please >> > > > speak up. >> > > > >> > > > i do not run nor admin the security email/list (nor do i know who >> > > > does) >> > > > so please dont ask me questions about it. >> > > >> > > I guess, i "de facto" admin the security "email/list". >> > > if someone wants to help with security issues, mail me >> > > >> > > but there are no open security issues and if there was one i very >> > > likely would fix it ASAP >> > >> > A small update due to never? before seen interrest in ffmpeg-security >> > in the recent weeks/months >> > >> > How to get on the ffmpeg-security "list" >> > >> > People working on security in FFmpeg, thats maybe fixing many coverity >> > issues, backporingt fixes to releases, maintaining FFmpeg releases, ... >> > have an obsession with fixing bugs about undefined behavior or bugs >> > about crashes and race conditions on trac. Or an obsession with testing >> > every bugfix and who want and need access to ffmpeg-security should >> > be on ffmpeg-security >> > In short people on ffmpeg-security should need to be on ffmpeg-security >> > If you fall in this kind of category, please mail me >> > >> > Or someone who reviews commits and obtains CVE#s for everything that >> > could be exploitable ... >> > >> > I dont think we should give access to ffmpeg-security to everyone who >> > wants to be on the list. This is of course something the community >> > has to decide and not me, iam just err-ing on the safe side and am very >> > restrictive on who is added. >> > >> > About the content i must warn you the list is really not very >> > interresting as in trying to find together with debian someone at >> > chromium who knows what the CVEs they registered about FFmpeg actually >> > are about ... and then it embarassingly is a patch on ffmpeg-devel >> > that is stuck in review and not applied and now i can redo the releases >> > ... >> > ... Where are the people caring about security ? why did they not >> > pick these 2 public patches up, change what they felt needs changing >> > and pushed them ? >> > and there are the fuzz samples that need more than 20sec, these are >> > the main type of reported issue recently after ive succeeded to stop >> > the oom kind. >> > >> > Also there are no open security(*) issues i know of, and if there would >> > be i likely would fix them ASAP. Not saying that help is unwelcome >> > or that its impossible for me to make a mistake or miss something ... >> > >> > (*) I assume here that fuzz samples taking more than 20sec or integer >> > overflows in DSP code arent security issues. Iam working on fixing >> > these too but for this category there are open issues. >> > >> > PS: If you want access to the oss-fuzz reports, they all seem >> > automatically public 7 days after being fixed >> > >> > [...] >> > >> >> I'd like to get on the ffmpeg-security mailing list to review patches. > > Thats appreciated, though theres a problem, there rarely are patches > on that "list". Besides there is no mailing list this is just a mail > alias > > if i search for "~cffmpeg-security ~b\\+\\+\\+" i see only 54 matches > in the whole history of the list in my inbox most of which are > duplicates in quotes of replies > so maybe there were less than 20 patches ever posted to that list. > also patches tend to be CC-ed to developers knowing the code or commit > related to a issue, like ronald and james for the http fix in december > or paul and martin for the exr patch in august > > If the community wants me to add every FFmpeg maintainer who wants > to be on the alias, i can do that. But in the absence of a clear > community decission (poll/vote) on the inclusion criteria iam reluctant > to add anyone without a strong reason. There occasionally is > information or files posted that could be used in the construction of > an exploit prior to everyone updating, so the fewer addresses it is > sent to the better. So others are sending CVE reports directly to you? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list
On Thu, Feb 09, 2017 at 08:25:43AM +0100, wm4 wrote: > On Wed, 8 Feb 2017 22:07:24 +0100 > Michael Niedermayer wrote: > > > Hi all > > > > On Sat, Aug 08, 2015 at 03:51:11AM +0200, Michael Niedermayer wrote: > > > On Fri, Aug 07, 2015 at 07:46:55PM -0400, compn wrote: > > > > hello, > > > > > > > > some of you know that we have a list for security / CVE issues. > > > > some of you did not know this. > > > > > > > > i think it is a private list due to not wanting people to make exploits > > > > before we have a chance to fix them. of course, if no one is subscribed > > > > to review/fix issues then they will never get fixed. > > > > > > > > so if you are a regular developer who wants access to this list, please > > > > speak up. > > > > > > > > i do not run nor admin the security email/list (nor do i know who does) > > > > so please dont ask me questions about it. > > > > > > I guess, i "de facto" admin the security "email/list". > > > if someone wants to help with security issues, mail me > > > > > > but there are no open security issues and if there was one i very > > > likely would fix it ASAP > > > > A small update due to never? before seen interrest in ffmpeg-security > > in the recent weeks/months > > > > How to get on the ffmpeg-security "list" > > > > People working on security in FFmpeg, thats maybe fixing many coverity > > issues, backporingt fixes to releases, maintaining FFmpeg releases, ... > > have an obsession with fixing bugs about undefined behavior or bugs > > about crashes and race conditions on trac. Or an obsession with testing > > every bugfix and who want and need access to ffmpeg-security should > > be on ffmpeg-security > > In short people on ffmpeg-security should need to be on ffmpeg-security > > If you fall in this kind of category, please mail me > > > > Or someone who reviews commits and obtains CVE#s for everything that > > could be exploitable ... > > > > I dont think we should give access to ffmpeg-security to everyone who > > wants to be on the list. This is of course something the community > > has to decide and not me, iam just err-ing on the safe side and am very > > restrictive on who is added. > > > > About the content i must warn you the list is really not very > > interresting as in trying to find together with debian someone at > > chromium who knows what the CVEs they registered about FFmpeg actually > > are about ... and then it embarassingly is a patch on ffmpeg-devel > > that is stuck in review and not applied and now i can redo the releases ... > > ... Where are the people caring about security ? why did they not > > pick these 2 public patches up, change what they felt needs changing > > and pushed them ? > > and there are the fuzz samples that need more than 20sec, these are > > the main type of reported issue recently after ive succeeded to stop > > the oom kind. > > > > Also there are no open security(*) issues i know of, and if there would > > be i likely would fix them ASAP. Not saying that help is unwelcome > > or that its impossible for me to make a mistake or miss something ... > > > > (*) I assume here that fuzz samples taking more than 20sec or integer > > overflows in DSP code arent security issues. Iam working on fixing > > these too but for this category there are open issues. > > > > PS: If you want access to the oss-fuzz reports, they all seem > > automatically public 7 days after being fixed > > > > [...] > > > > I'd like to get on the ffmpeg-security mailing list to review patches. Thats appreciated, though theres a problem, there rarely are patches on that "list". Besides there is no mailing list this is just a mail alias if i search for "~cffmpeg-security ~b\\+\\+\\+" i see only 54 matches in the whole history of the list in my inbox most of which are duplicates in quotes of replies so maybe there were less than 20 patches ever posted to that list. also patches tend to be CC-ed to developers knowing the code or commit related to a issue, like ronald and james for the http fix in december or paul and martin for the exr patch in august If the community wants me to add every FFmpeg maintainer who wants to be on the alias, i can do that. But in the absence of a clear community decission (poll/vote) on the inclusion criteria iam reluctant to add anyone without a strong reason. There occasionally is information or files posted that could be used in the construction of an exploit prior to everyone updating, so the fewer addresses it is sent to the better. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list
On Thu, 09 Feb 2017 13:24:53 +, Kieran Kunhya wrote: > > > > I dont think we should give access to ffmpeg-security to everyone who > > wants to be on the list. This is of course something the community > > has to decide and not me, iam just err-ing on the safe side and am very > > restrictive on who is added. > > > > This is a bogus argument considering how many people have commit access and > can commit whatever. honestly with the fearmongering? are you saying the russian ffmpeg developers can just commit whatever they want whenever they want?! also there are some chinese ffmpeg developers! even the president says china cant be trusted! the russians hacked the election and now they will put backdoors in ffmpeg!?!?! (this email is satire btw... i do not believe russia affected the us election, nor brexit. and china is cool with me.) if kierank and wm4 want on the -security list, please put them on the security list. i doubt anyone will vote against their inclusion on the list. count this as my vote for any current regular developers (e.g. the ones on irc or the non-irc devs if they have more than 1 year committing) to be subscribed if they want. thanks for reading. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list
> > I dont think we should give access to ffmpeg-security to everyone who > wants to be on the list. This is of course something the community > has to decide and not me, iam just err-ing on the safe side and am very > restrictive on who is added. > This is a bogus argument considering how many people have commit access and can commit whatever. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.
On Thu, Feb 09, 2017 at 03:44:59AM +0100, Michael Niedermayer wrote:
> On Wed, Feb 01, 2017 at 11:23:04PM -0800, Jerry Jiang wrote:
[...]
> i sadly dont have time to do a more complete review ATM (need sleep)
> but this patch doesnt look like it was ready for being pushed
more reviewing related to what is in git + fixes
[...]
>+static inline void ff_mjpeg_encode_code(MJpegContext *s, uint8_t table_id,
>int code)
static functions dont need ff_ prefix
>+{
>+MJpegHuffmanCode *c = &s->huff_buffer[s->huff_ncode++];
>+av_assert0(s->huff_ncode < s->huff_capacity);
>+c->table_id = table_id;
>+c->code = code;
>+}
>+
>+/**
>+ * Add the coefficient's data to the JPEG buffer.
>+ *
>+ * @param s The MJpegContext which contains the JPEG buffer.
>+ * @param table_id Which Huffman table the code belongs to.
>+ * @param val The coefficient.
>+ * @param run The run-bits.
>+ */
>+static void ff_mjpeg_encode_coef(MJpegContext *s, uint8_t table_id, int val,
>int run)
static functions dont need ff_ prefix
[...]
>-void ff_mjpeg_encode_mb(MpegEncContext *s, int16_t block[12][64])
>+// Possibly reallocate the huffman code buffer, assuming blocks_per_mb.
>+// Set s->mjpeg_ctx->error on ENOMEM.
>+static void realloc_huffman(MpegEncContext *s, int blocks_per_mb)
> {
>-int i;
>+MJpegContext *m = s->mjpeg_ctx;
>+size_t num_mbs, num_blocks, num_codes;
>+MJpegHuffmanCode *new_buf;
>+if (m->error) return;
>+// Make sure we have enough space to hold this frame.
>+num_mbs = s->mb_width * s->mb_height;
>+num_blocks = num_mbs * blocks_per_mb;
>+av_assert0(m->huff_ncode <=
>+ (s->mb_y * s->mb_width + s->mb_x) * blocks_per_mb * 64);
>+num_codes = num_blocks * 64;
>+
>+new_buf = av_fast_realloc(m->huff_buffer, &m->huff_capacity,
>+ num_codes * sizeof(MJpegHuffmanCode));
this will always reallocate the buffer to its maximum, in fact it
will allocate a much larger buffer than the maximum as
av_fast_realloc() overallocates
so this is always slower and uses more memory than if the maximum
buffer size is allocated during init.
I understand the intent might have been to allocate only what is
needed but the code does not do that
>+if (!new_buf) {
>+m->error = AVERROR(ENOMEM);
>+} else {
>+m->huff_buffer = new_buf;
>+}
>+}
>+
>+int ff_mjpeg_encode_mb(MpegEncContext *s, int16_t block[12][64])
>+{
>+int i, is_chroma_420;
>+
>+// Number of bits used depends on future data.
>+// So, nothing that relies on encoding many times and taking the
>+// one with the fewest bits will work properly here.
>+if (s->i_tex_bits != MJPEG_HUFFMAN_EST_BITS_PER_CODE *
>+s->mjpeg_ctx->huff_ncode) {
>+av_log(s->avctx, AV_LOG_ERROR, "Unsupported encoding method\n");
>+return AVERROR(EINVAL);
>+}
>+
> if (s->chroma_format == CHROMA_444) {
>+realloc_huffman(s, 12);
> encode_block(s, block[0], 0);
> encode_block(s, block[2], 2);
> encode_block(s, block[4], 4);
>@@ -196,10 +302,12 @@ void ff_mjpeg_encode_mb(MpegEncContext *s, int16_t
>block[12][64])
> encode_block(s, block[11], 11);
> }
> } else {
>+is_chroma_420 = (s->chroma_format == CHROMA_420);
>+realloc_huffman(s, 5 + (is_chroma_420 ? 1 : 3));
> for(i=0;i<5;i++) {
> encode_block(s, block[i], i);
> }
>-if (s->chroma_format == CHROMA_420) {
>+if (is_chroma_420) {
> encode_block(s, block[5], 5);
> } else {
> encode_block(s, block[6], 6);
>@@ -207,8 +315,11 @@ void ff_mjpeg_encode_mb(MpegEncContext *s, int16_t
>block[12][64])
> encode_block(s, block[7], 7);
> }
> }
>+if (s->mjpeg_ctx->error)
>+return s->mjpeg_ctx->error;
>
>-s->i_tex_bits += get_bits_diff(s);
>+s->i_tex_bits = MJPEG_HUFFMAN_EST_BITS_PER_CODE *
>s->mjpeg_ctx->huff_ncode;
>+return 0;
i_tex_bits is for rate control, iam not sure what this use is trying to
do but the value its set to is not correct and i see nothing that
corrects it. This is likely what breaks 2pass
[...]
>@@ -372,14 +414,116 @@ void ff_mjpeg_escape_FF(PutBitContext *pb, int start)
> }
> }
>
>+/**
>+ * Builds all 4 optimal Huffman tables.
>+ *
>+ * Uses the data stored in the JPEG buffer to compute the tables.
>+ * Stores the Huffman tables in the bits_* and val_* arrays in the
>MJpegContext.
>+ *
>+ * @param m MJpegContext containing the JPEG buffer.
>+ */
>+static void ff_mjpeg_build_optimal_huffman(MJpegContext *m)
>+{
>+int i, ret, table_id, code;
>+
>+MJpegEncHuffmanContext dc_luminance_ctx;
>+MJpegEncHuffmanContext dc_chrominance_ctx;
>+MJpegEncHuffmanContext ac_luminance_ctx;
>+MJpegEncHuffmanContext ac_chrominance_ctx;
>+MJpegEncHuffmanContext *ctx[4] = {&dc_luminance_ctx,
>+ &dc_chrominance_ctx,
>+
[FFmpeg-devel] [PATCH v3] avformat/hlsenc: deprecate hls_wrap option
When user use the hls_wrap, there have many problem:
1. some platform refersh the old but usefull segment
2. CDN(Content Delivery Network) Deliver HLS not friendly
The hls_wrap is used to wrap segments for use little space,
now user can use hls_list_size and hls_flags delete_segments
instead it.
Reviewed-by: Michael Niedermayer
Reviewed-by: Carl Eugen Hoyos
Signed-off-by: Steven Liu
---
doc/muxers.texi | 5 ++---
libavformat/hlsenc.c | 26 +-
libavformat/version.h | 4
3 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index cb875a4..c00e296 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -441,9 +441,8 @@ parameters. Values containing @code{:} special characters
must be
escaped.
@item hls_wrap @var{wrap}
-Set the number after which the segment filename number (the number
-specified in each segment file) wraps. If set to 0 the number will be
-never wrapped. Default value is 0.
+This is a deprecated option, you can use @code {hls_list_size}
+and @code{hls_flags delete_segments} instead it
This option is useful to avoid to fill the disk with many segment
files, and limits the maximum number of segment files written to disk
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 17d4fe4..4076ccd 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -101,7 +101,9 @@ typedef struct HLSContext {
float time;// Set by a private option.
float init_time; // Set by a private option.
int max_nb_segments; // Set by a private option.
+#if FF_API_HLS_WRAP
int wrap; // Set by a private option.
+#endif
uint32_t flags;// enum HLSFlags
uint32_t pl_type; // enum PlaylistType
char *segment_filename;
@@ -566,7 +568,11 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls, double
hls->initial_prog_date_time += en->duration;
hls->segments = en->next;
if (en && hls->flags & HLS_DELETE_SEGMENTS &&
+#if FF_API_HLS_WRAP
!(hls->flags & HLS_SINGLE_FILE || hls->wrap)) {
+#else
+!(hls->flags & HLS_SINGLE_FILE)) {
+#endif
en->next = hls->old_segments;
hls->old_segments = en;
if ((ret = hls_delete_old_segments(hls)) < 0)
@@ -834,7 +840,11 @@ static int hls_start(AVFormatContext *s)
sizeof(vtt_oc->filename));
} else if (c->max_seg_size > 0) {
if (replace_int_data_in_filename(oc->filename, sizeof(oc->filename),
+#if FF_API_HLS_WRAP
c->basename, 'd', c->wrap ? c->sequence % c->wrap : c->sequence) <
1) {
+#else
+c->basename, 'd', c->sequence) < 1) {
+#endif
av_log(oc, AV_LOG_ERROR, "Invalid segment filename template
'%s', you can try to use -use_localtime 1 with it\n", c->basename);
return AVERROR(EINVAL);
}
@@ -853,7 +863,11 @@ static int hls_start(AVFormatContext *s)
if (!filename)
return AVERROR(ENOMEM);
if (replace_int_data_in_filename(oc->filename,
sizeof(oc->filename),
+#if FF_API_HLS_WRAP
filename, 'd', c->wrap ? c->sequence % c->wrap :
c->sequence) < 1) {
+#else
+filename, 'd', c->sequence) < 1) {
+#endif
av_log(c, AV_LOG_ERROR,
"Invalid second level segment filename template
'%s', "
"you can try to remove second_level_segment_index
flag\n",
@@ -910,13 +924,21 @@ static int hls_start(AVFormatContext *s)
av_free(fn_copy);
}
} else if (replace_int_data_in_filename(oc->filename,
sizeof(oc->filename),
+#if FF_API_HLS_WRAP
c->basename, 'd', c->wrap ? c->sequence % c->wrap :
c->sequence) < 1) {
+#else
+ c->basename, 'd', c->sequence) < 1) {
+#endif
av_log(oc, AV_LOG_ERROR, "Invalid segment filename template '%s'
you can try to use -use_localtime 1 with it\n", c->basename);
return AVERROR(EINVAL);
}
if( c->vtt_basename) {
if (replace_int_data_in_filename(vtt_oc->filename,
sizeof(vtt_oc->filename),
+#if FF_API_HLS_WRAP
c->vtt_basename, 'd', c->wrap ? c->sequence % c->wrap :
c->sequence) < 1) {
+#else
+c->vtt_basename, 'd', c->sequence) < 1) {
+#endif
av_log(vtt_oc, AV_LOG_ERROR, "Invalid segment filename
template '%s'\n", c->vtt_basename);
return AVERROR(EINVAL);
}
@@ -1421,7 +1443,9 @@ static const AVOption options[] = {
{"hls_list_size", "set maximum number of playlist entries",
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX, E},
{"hls_ts_options","set hls mpegts list of options for the container format
used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str = NULL},
0, 0,
Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: deprecate hls_wrap option
2017-02-09 18:53 GMT+08:00 Carl Eugen Hoyos :
> 2017-02-09 11:52 GMT+01:00 Steven Liu :
> > 2017-02-09 18:46 GMT+08:00 Carl Eugen Hoyos :
> >
> >> 2017-02-09 8:58 GMT+01:00 Steven Liu :
> >>
> >> > +#if FF_API_HLS_WRAP
> >> > {"hls_wrap", "set number after which the index wraps",
> >> OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
> >> > +#endif
> >>
> >> (Even if this is not done for other deprecated options:)
> >> Imo, either add the word deprecated, or even replace the whole
> >> description string with the word "deprecated".
> >>
> > Your mean: s/set number after which the index wraps/ this option is
> > deprecated/g
>
> I would suggest this, yes.
>
Apply your good suggest :)
> (Without having looked at other deprecated options)
>
> Carl Eugen
> ___
> 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 v2] avformat/hlsenc: deprecate hls_wrap option
2017-02-09 11:52 GMT+01:00 Steven Liu :
> 2017-02-09 18:46 GMT+08:00 Carl Eugen Hoyos :
>
>> 2017-02-09 8:58 GMT+01:00 Steven Liu :
>>
>> > +#if FF_API_HLS_WRAP
>> > {"hls_wrap", "set number after which the index wraps",
>> OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
>> > +#endif
>>
>> (Even if this is not done for other deprecated options:)
>> Imo, either add the word deprecated, or even replace the whole
>> description string with the word "deprecated".
>>
> Your mean: s/set number after which the index wraps/ this option is
> deprecated/g
I would suggest this, yes.
(Without having looked at other deprecated options)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: deprecate hls_wrap option
2017-02-09 18:46 GMT+08:00 Carl Eugen Hoyos :
> 2017-02-09 8:58 GMT+01:00 Steven Liu :
>
> > +#if FF_API_HLS_WRAP
> > {"hls_wrap", "set number after which the index wraps",
> OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
> > +#endif
>
> (Even if this is not done for other deprecated options:)
> Imo, either add the word deprecated, or even replace the whole
> description string with the word "deprecated".
>
Your mean: s/set number after which the index wraps/ this option is
deprecated/g
do i get your mean?
>
> Carl Eugen
> ___
> 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 v2] avformat/hlsenc: deprecate hls_wrap option
2017-02-09 8:58 GMT+01:00 Steven Liu :
> +#if FF_API_HLS_WRAP
> {"hls_wrap", "set number after which the index wraps",
> OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
> +#endif
(Even if this is not done for other deprecated options:)
Imo, either add the word deprecated, or even replace the whole
description string with the word "deprecated".
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] GSoC 2017
Michael Niedermayer wrote: >also in absence of any other ideas, YCoCg support may be a >qualification task. Maybe not the best choice but certainly >usefull on its own +1 Y'CoCg support would be useful indeed. Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 3/3] avfilter/f_setcmd: fix null pointer dereference on using dash as interval
On 2/9/17, Marton Balint wrote:
> Fixes Coverity CID 1396259.
>
> Signed-off-by: Marton Balint
> ---
> libavfilter/f_sendcmd.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavfilter/f_sendcmd.c b/libavfilter/f_sendcmd.c
> index fb30220..522d6ad 100644
> --- a/libavfilter/f_sendcmd.c
> +++ b/libavfilter/f_sendcmd.c
> @@ -268,6 +268,13 @@ static int parse_interval(Interval *interval, int
> interval_count,
> char *start, *end;
>
> start = av_strtok(intervalstr, "-", &end);
> +if (!start) {
> +ret = AVERROR(EINVAL);
> +av_log(log_ctx, AV_LOG_ERROR,
> + "Invalid interval specification '%s' in interval #%d\n",
> + intervalstr, interval_count);
> +goto end;
> +}
> if ((ret = av_parse_time(&interval->start_ts, start, 1)) < 0) {
> av_log(log_ctx, AV_LOG_ERROR,
> "Invalid start time specification '%s' in interval
> #%d\n",
> --
> 2.10.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
