[FFmpeg-devel] FFmpeg 2.8.9, 3.1.6, 3.0.5
Hi I intend to make new releases for the 3.0, 3.1 and 2.8 branches if you want to backport something, do so soon Plan is 2.8 first as its longest since its last release -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.2.1
On Tue, Nov 22, 2016 at 12:58:07PM +0100, Michael Niedermayer wrote: > Hi all > > ill make 3.2.1 soon > if you want to backport something, do so now release made thanks everyone [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 2.8.9, 3.1.6, 3.0.5
Michael Niedermayer wrote: >I intend to make new releases for the 3.0, 3.1 and 2.8 >branches >if you want to backport something, do so soon >Plan is 2.8 first as its longest since its last release Thank you very much for maintaining these branches! May I suggest to move the 2.5 and 2.6 branches (and perhaps also 2.7 branch) to the "Old Releases" section? Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] vc1dec: support multiple slices in frame coded images with hwaccel
On Fri, Nov 25, 2016 at 10:30 PM, Hendrik Leppkes wrote: > On Sun, Nov 20, 2016 at 7:14 PM, Carl Eugen Hoyos wrote: >> 2016-11-20 17:50 GMT+01:00 Mark Thompson : >>> On 20/11/16 16:16, Carl Eugen Hoyos wrote: >> There is no API to read the version of the mesa driver? >>> >>> The one useful call is vaQueryVendorString(), which indeed returns useful >>> results for i965. Unfortunately, all mesa returns here is a fixed string: >>> >>> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/context.c#n176 >> >> Thank you both for explaining! >> >> Please consider to make sure mesa knows about the issue... >> > > Unless there are more comments I'll apply this tomorrow with changelog > and micro version bump. > And pushed. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC]MAINTAINERS: Add developers who have git write access but are otherwise not listed
On Fri, 25 Nov 2016 11:11:23 +0100 (CET) Marton Balint wrote: > > On Mon, 21 Nov 2016, Michael Niedermayer wrote: > > > I omitted developers who do not use their account and i felt would > > prefer not to be listed. > > I think everyone with access should be listed. If somebody does not > use his account for a year or so, his/her access should be revoked. any scientific reason why? -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC]MAINTAINERS: Add developers who have git write access but are otherwise not listed
On Sat, 26 Nov 2016, compn wrote: On Fri, 25 Nov 2016 11:11:23 +0100 (CET) Marton Balint wrote: On Mon, 21 Nov 2016, Michael Niedermayer wrote: > I omitted developers who do not use their account and i felt would > prefer not to be listed. I think everyone with access should be listed. If somebody does not use his account for a year or so, his/her access should be revoked. any scientific reason why? In an open source project, the list of people with commit rights should be public. Revoking unused accounts is a simple security measure against lost/compromised private keys. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC]MAINTAINERS: Add developers who have git write access but are otherwise not listed
On Sat, 26 Nov 2016 17:15:36 +0100 (CET) Marton Balint wrote: > > On Sat, 26 Nov 2016, compn wrote: > > > On Fri, 25 Nov 2016 11:11:23 +0100 (CET) > > Marton Balint wrote: > > > >> > >> On Mon, 21 Nov 2016, Michael Niedermayer wrote: > >> > >> > I omitted developers who do not use their account and i felt > >> > would prefer not to be listed. > >> > >> I think everyone with access should be listed. If somebody does not > >> use his account for a year or so, his/her access should be revoked. > > > > any scientific reason why? > > > > In an open source project, the list of people with commit rights > should be public. > no problem > Revoking unused accounts is a simple security measure against > lost/compromised private keys. so unlikely that i cannot even imagine the odds. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi/ebur128: relicense to LGPL
All copyright holders have agreed to the relicensing. Approved-by: Andreas Cadhalpun Approved-by: David Sedacca Approved-by: Ganesh Ajjanagadde Approved-by: Jean First Approved-by: Kyle Swanson Approved-by: Michael Niedermayer Approved-by: Nicolas George Approved-by: Paul B Mahol Approved-by: Thilo Borgmann --- I plan to push this soon. Thanks to all contributors for agreeing to the relicensing. --- LICENSE.md | 1 - configure | 1 - libavfilter/f_ebur128.c | 18 +- 3 files changed, 9 insertions(+), 11 deletions(-) diff --git a/LICENSE.md b/LICENSE.md index a384fa0..640633c 100644 --- a/LICENSE.md +++ b/LICENSE.md @@ -26,7 +26,6 @@ Specifically, the GPL parts of FFmpeg are: - `tests/checkasm/*` - `tests/tiny_ssim.c` - the following filters in libavfilter: -- `f_ebur128.c` - `vf_blackframe.c` - `vf_boxblur.c` - `vf_colormatrix.c` diff --git a/configure b/configure index d0c0056..a5e0a02 100755 --- a/configure +++ b/configure @@ -3036,7 +3036,6 @@ cropdetect_filter_deps="gpl" delogo_filter_deps="gpl" deshake_filter_select="pixelutils" drawtext_filter_deps="libfreetype" -ebur128_filter_deps="gpl" eq_filter_deps="gpl" fftfilt_filter_deps="avcodec" fftfilt_filter_select="rdft" diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c index 983c889..1fd85bb 100644 --- a/libavfilter/f_ebur128.c +++ b/libavfilter/f_ebur128.c @@ -3,19 +3,19 @@ * * This file is part of FFmpeg. * - * FFmpeg is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. + * 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 General Public License for more details. + * 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 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. + * 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 */ /** -- 2.10.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.2.1
...shared on Facebook: https://www.facebook.com/ffmpeg/ Best regards, Thomas. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC]MAINTAINERS: Add developers who have git write access but are otherwise not listed
Le sextidi 6 frimaire, an CCXXV, compn a écrit : > so unlikely that i cannot even imagine the odds. Any scientific reason why? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 2.8.9, 3.1.6, 3.0.5
On Sat, Nov 26, 2016 at 01:18:32PM +0100, Reto Kromer wrote: > Michael Niedermayer wrote: > > >I intend to make new releases for the 3.0, 3.1 and 2.8 > >branches > >if you want to backport something, do so soon > >Plan is 2.8 first as its longest since its last release > > Thank you very much for maintaining these branches! > > May I suggest to move the 2.5 and 2.6 branches (and perhaps > also 2.7 branch) to the "Old Releases" section? thats probably a good idea, ill wait a few days to see if anyone disagrees [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] matroskadec: partly revert "demux relevant subtitle packets after a seek" c16582579b1c6f66a86615c5808cd5b2bf17be73
From: Rainer Hochecker
Alternative patch. Revert the original code because it does more harm than any
good.
Signed-off-by: Rainer Hochecker
---
libavformat/matroskadec.c | 12
1 file changed, 12 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index f79511e..cf3de96 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3398,18 +3398,6 @@ static int matroska_read_seek(AVFormatContext *s, int
stream_index,
tracks[i].audio.sub_packet_cnt = 0;
tracks[i].audio.buf_timecode = AV_NOPTS_VALUE;
tracks[i].end_timecode = 0;
-if (tracks[i].type == MATROSKA_TRACK_TYPE_SUBTITLE &&
-tracks[i].stream &&
-tracks[i].stream->discard != AVDISCARD_ALL) {
-index_sub = av_index_search_timestamp(
-tracks[i].stream, st->index_entries[index].timestamp,
-AVSEEK_FLAG_BACKWARD);
-while (index_sub >= 0 &&
- index_min > 0 &&
- tracks[i].stream->index_entries[index_sub].pos <
st->index_entries[index_min].pos &&
- st->index_entries[index].timestamp -
tracks[i].stream->index_entries[index_sub].timestamp < 300 /
matroska->time_scale)
-index_min--;
-}
}
avio_seek(s->pb, st->index_entries[index_min].pos, SEEK_SET);
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pngdec: check if previous frame exists instead of trusting sequence_number
On 26.11.2016 01:53, Michael Niedermayer wrote:
> On Fri, Nov 25, 2016 at 10:13:06PM +0100, Andreas Cadhalpun wrote:
>> This fixes a segmentation fault caused by calling memcpy with NULL as
>> second argument in handle_p_frame_apng.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/pngdec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
>> index 36275ae..a7b330b 100644
>> --- a/libavcodec/pngdec.c
>> +++ b/libavcodec/pngdec.c
>> @@ -922,7 +922,7 @@ static int decode_fctl_chunk(AVCodecContext *avctx,
>> PNGDecContext *s,
>> return AVERROR_INVALIDDATA;
>> }
>>
>> -if (sequence_number == 0 && dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
>> +if (!s->previous_picture.f->data[0] && dispose_op ==
>> APNG_DISPOSE_OP_PREVIOUS) {
>> // No previous frame to revert to for the first frame
>> // Spec says to just treat it as a APNG_DISPOSE_OP_BACKGROUND
>> dispose_op = APNG_DISPOSE_OP_BACKGROUND;
>
> wont this be different when seeking back to the
> first frame ?
> is that intended ?
I don't think the apng demuxer supports seeking.
But it shouldn't hurt to check both sequence_number and the previous frame.
Updated patch is attached.
Best regards,
Andreas
>From 84125e5f32fd4b9146d9926d2f8a4467da7c8557 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Fri, 25 Nov 2016 22:09:51 +0100
Subject: [PATCH] pngdec: check if previous frame exists instead of trusting
sequence_number
This fixes a segmentation fault caused by calling memcpy with NULL as
second argument in handle_p_frame_apng.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/pngdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 36275ae..2f8d266 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -922,7 +922,8 @@ static int decode_fctl_chunk(AVCodecContext *avctx, PNGDecContext *s,
return AVERROR_INVALIDDATA;
}
-if (sequence_number == 0 && dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
+if ((sequence_number == 0 || !s->previous_picture.f->data[0]) &&
+dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
// No previous frame to revert to for the first frame
// Spec says to just treat it as a APNG_DISPOSE_OP_BACKGROUND
dispose_op = APNG_DISPOSE_OP_BACKGROUND;
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf: always forward codec_whitelist in avformat_find_stream_info
On 26.11.2016 01:54, Michael Niedermayer wrote: > On Fri, Nov 25, 2016 at 09:57:57PM +0100, Andreas Cadhalpun wrote: >> Signed-off-by: Andreas Cadhalpun >> --- >> libavformat/utils.c | 6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) > > LGTM Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] coverity testing of FFmpeg
Hi all The machine on which the coverity stuff is is old, both hw and OS. the OS will no longer get security updates in a few months and the hw does not always boot and its switched off most of the time. and it has no other use anymore than running coverity. Ive tried to find someone a while ago to take coverity testing over and i thought timothy would maybe do it but he seems to not have had any time to look into it ... and de facto ive not run it regularly in the recent months. So this is kinda a louder announcement that if you care about coverity testing, you need to do something ... thx PS: work would involve installing every optional dependancy of FFmpeg (and keep them updated as needed) and regularly either manually or automatically git pull, build with the coverity tools and upload Its not a huge amount of work but it is work -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vf_scale_npp: move aspect ratio correction after, av_frame_copy_props
Updating output aspect ratio before calling nppscale_scale has no effect
because nppscale_scale calls av_frame_copy_props which will overwrite
output aspect ratio based on source frame.
Simplest solution is to move aspect ratio update after nppscale_scale
function, but it is also possible to move aspect ratio update directly
to nppscale_scale function in future.
This should fix aspect ratio bug when using scale_npp for resolution
with different W/H than original resolution for example 1920x1080 ->
720x576 and codec which supports dynamic aspect ratio change which is
libx264, nvenc not yet, that is the reason why that bug was hidden.
--
Miroslav Slugeň
>From 6eb95f381add35de0ae83e826ee8fdeaccf6c31d Mon Sep 17 00:00:00 2001
From: Miroslav Slugen
Date: Sun, 27 Nov 2016 00:58:16 +0100
Subject: [PATCH 1/1] vf_scale_npp: move aspect ratio correction after
av_frame_copy_props
---
libavfilter/vf_scale_npp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_scale_npp.c b/libavfilter/vf_scale_npp.c
index 78f541e..3c1d1e9 100644
--- a/libavfilter/vf_scale_npp.c
+++ b/libavfilter/vf_scale_npp.c
@@ -586,11 +586,6 @@ static int nppscale_filter_frame(AVFilterLink *link, AVFrame *in)
goto fail;
}
-av_reduce(&out->sample_aspect_ratio.num, &out->sample_aspect_ratio.den,
- (int64_t)in->sample_aspect_ratio.num * outlink->h * link->w,
- (int64_t)in->sample_aspect_ratio.den * outlink->w * link->h,
- INT_MAX);
-
err = device_hwctx->internal->cuda_dl->cuCtxPushCurrent(device_hwctx->cuda_ctx);
if (err != CUDA_SUCCESS) {
ret = AVERROR_UNKNOWN;
@@ -603,6 +598,11 @@ static int nppscale_filter_frame(AVFilterLink *link, AVFrame *in)
if (ret < 0)
goto fail;
+av_reduce(&out->sample_aspect_ratio.num, &out->sample_aspect_ratio.den,
+ (int64_t)in->sample_aspect_ratio.num * outlink->h * link->w,
+ (int64_t)in->sample_aspect_ratio.den * outlink->w * link->h,
+ INT_MAX);
+
av_frame_free(&in);
return ff_filter_frame(outlink, out);
fail:
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] nvenc: always reduce DAR width and height
This patch will fix/change:
1. avctx->sample_aspect_ratio.num == 1 and
avctx->sample_aspect_ratio.den != 1:
There is bug in old comparison, so with this aspect ratio for example
1/2 old alghoritm will produce aspect ratio 1/1
2. Old algorithm also does compute with negative numbers, which should
not be used
3. Always reducing DAR width and height is very useful for future use
when we will be monitoring aspect ratio change for reseting encoder...
--
Miroslav Slugeň
>From 53bda222d1a3d4c461816d144dcecf792762da49 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen
Date: Sun, 27 Nov 2016 01:34:30 +0100
Subject: [PATCH 1/1] nvenc: always reduce DAR width and height
---
libavcodec/nvenc.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index d24d278..58dcc5c 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -940,18 +940,15 @@ static av_cold int nvenc_setup_encoder(AVCodecContext *avctx)
ctx->encode_config.version = NV_ENC_CONFIG_VER;
-if (avctx->sample_aspect_ratio.num && avctx->sample_aspect_ratio.den &&
-(avctx->sample_aspect_ratio.num != 1 || avctx->sample_aspect_ratio.num != 1)) {
-av_reduce(&dw, &dh,
- avctx->width * avctx->sample_aspect_ratio.num,
- avctx->height * avctx->sample_aspect_ratio.den,
- 1024 * 1024);
-ctx->init_encode_params.darHeight = dh;
-ctx->init_encode_params.darWidth = dw;
-} else {
-ctx->init_encode_params.darHeight = avctx->height;
-ctx->init_encode_params.darWidth = avctx->width;
-}
+dw = avctx->width;
+dh = avctx->height;
+if (avctx->sample_aspect_ratio.num > 0 && avctx->sample_aspect_ratio.den > 0) {
+dw*= avctx->sample_aspect_ratio.num;
+dh*= avctx->sample_aspect_ratio.den;
+}
+av_reduce(&dw, &dh, dw, dh, 1024 * 1024);
+ctx->init_encode_params.darHeight = dh;
+ctx->init_encode_params.darWidth = dw;
ctx->init_encode_params.frameRateNum = avctx->time_base.den;
ctx->init_encode_params.frameRateDen = avctx->time_base.num * avctx->ticks_per_frame;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC]MAINTAINERS: Add developers who have git write access but are otherwise not listed
On Sat, 26 Nov 2016 18:05:52 +0100 Nicolas George wrote: > Le sextidi 6 frimaire, an CCXXV, compn a écrit : > > so unlikely that i cannot even imagine the odds. > > Any scientific reason why? if one wants to be worried about security issues, there are bigger fish to fry. for one example, how about any and all patches applied to ffmpeg by various distros ? https://lists.debian.org/debian-security-announce/2008/msg00152.html because this is a real threat to our users' security. not some lost commit key. we should be analyzing all distro patches and making sure all CVE fixes get applied by distros as well. our other developer policies help to mitigate any lost/stolen commit keys anyway. public patch posting and mailing list review, static code analyzing etc. has any developer come back from the proverbial "dead" , like say fabrice, to make a new commit? no. would we take notice if he did? yes of course. have developers had write access, been hired by large multinational corporations, stopped developing ffmpeg as a hobby, and then come back years later to work on ffmpeg as part of their employment? yes! multiple times. just my personal opinion. theres really not much difference between keeping old author accounts or deleting old author accounts from a real world perspective. one plan just takes some precious time away from the busy developer. because he has to make a list, and check it twice, just to find out who is naughty and who is nice. he sees when you are active... he sees when you are inactive... -compn (help, i've had far too much eggnog.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] pngdec: check if previous frame exists instead of trusting sequence_number
On Sat, Nov 26, 2016 at 11:36:48PM +0100, Andreas Cadhalpun wrote:
> On 26.11.2016 01:53, Michael Niedermayer wrote:
> > On Fri, Nov 25, 2016 at 10:13:06PM +0100, Andreas Cadhalpun wrote:
> >> This fixes a segmentation fault caused by calling memcpy with NULL as
> >> second argument in handle_p_frame_apng.
> >>
> >> Signed-off-by: Andreas Cadhalpun
> >> ---
> >> libavcodec/pngdec.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> >> index 36275ae..a7b330b 100644
> >> --- a/libavcodec/pngdec.c
> >> +++ b/libavcodec/pngdec.c
> >> @@ -922,7 +922,7 @@ static int decode_fctl_chunk(AVCodecContext *avctx,
> >> PNGDecContext *s,
> >> return AVERROR_INVALIDDATA;
> >> }
> >>
> >> -if (sequence_number == 0 && dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
> >> +if (!s->previous_picture.f->data[0] && dispose_op ==
> >> APNG_DISPOSE_OP_PREVIOUS) {
> >> // No previous frame to revert to for the first frame
> >> // Spec says to just treat it as a APNG_DISPOSE_OP_BACKGROUND
> >> dispose_op = APNG_DISPOSE_OP_BACKGROUND;
> >
> > wont this be different when seeking back to the
> > first frame ?
> > is that intended ?
>
> I don't think the apng demuxer supports seeking.
> But it shouldn't hurt to check both sequence_number and the previous frame.
> Updated patch is attached.
>
> Best regards,
> Andreas
>
> pngdec.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 141d5230c97dbc47e0b291f660544cfe57abbf7c
> 0001-pngdec-check-if-previous-frame-exists-instead-of-tru.patch
> From 84125e5f32fd4b9146d9926d2f8a4467da7c8557 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun
> Date: Fri, 25 Nov 2016 22:09:51 +0100
> Subject: [PATCH] pngdec: check if previous frame exists instead of trusting
> sequence_number
>
> This fixes a segmentation fault caused by calling memcpy with NULL as
> second argument in handle_p_frame_apng.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/pngdec.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Avoid a single point of failure, be that a person or equipment.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
