Re: [FFmpeg-devel] [PATCH] avcodec/webp: Reinitilaize VP8 decoder on pixel format mismatch

[wm4]

On Wed, 10 May 2017 15:39:45 +0200
Michael Niedermayer  wrote:

> On Wed, May 10, 2017 at 08:10:23AM -0400, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Tue, May 9, 2017 at 9:24 PM, Michael Niedermayer 
> > wrote:
> >   
> > > On Tue, May 09, 2017 at 09:08:08PM -0400, Ronald S. Bultje wrote:  
> > > > Hi,
> > > >
> > > > On Tue, May 9, 2017 at 8:37 PM, Michael Niedermayer  
> > >   
> > > > wrote:
> > > >  
> > > > > Fixes: out of array access
> > > > > Fixes: 1434/clusterfuzz-testcase-minimized-6314998085189632
> > > > > Fixes: 1435/clusterfuzz-testcase-minimized-6483783723253760
> > > > >
> > > > > Found-by: continuous fuzzing process https://github.com/google/oss-
> > > > > fuzz/tree/master/targets/ffmpeg
> > > > > Signed-off-by: Michael Niedermayer 
> > > > > ---
> > > > >  libavcodec/webp.c | 9 +++--
> > > > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> > > > > index 16c3ae2662..23ed4bc26f 100644
> > > > > --- a/libavcodec/webp.c
> > > > > +++ b/libavcodec/webp.c
> > > > > @@ -1330,12 +1330,17 @@ static int vp8_lossy_decode_frame(  
> > > AVCodecContext  
> > > > > *avctx, AVFrame *p,
> > > > >  WebPContext *s = avctx->priv_data;
> > > > >  AVPacket pkt;
> > > > >  int ret;
> > > > > +enum AVPixelFormat wanted_pix_fmt = s->has_alpha ?
> > > > > AV_PIX_FMT_YUVA420P : AV_PIX_FMT_YUV420P;
> > > > > +
> > > > > +if (s->initialized && wanted_pix_fmt != avctx->pix_fmt) {
> > > > > +ff_vp8_decode_free(avctx);
> > > > > +s->initialized = 0;
> > > > > +}
> > > > >
> > > > >  if (!s->initialized) {
> > > > >  ff_vp8_decode_init(avctx);
> > > > >  s->initialized = 1;
> > > > > -if (s->has_alpha)
> > > > > -avctx->pix_fmt = AV_PIX_FMT_YUVA420P;
> > > > > +avctx->pix_fmt = wanted_pix_fmt;
> > > > >  }
> > > > >  s->lossless = 0;  
> > > >
> > > >
> > > > What is the out of array access? webp is intra only and the only thing  
> > > that  
> > > > is initialized with memory in that call is reference frames. What's 
> > > > going
> > > > on here?  
> > >
> > > webp uses the same context as VP8, and it changes the pixel format
> > > as it needs. Vp8 doesnt work if its format is changed under its feet  
> > 
> > 
> > I think what you're trying to say is that it doesn't work with RGBA as
> > pixel format (it shouldn't need a reset between yuv420p and yuv420pa). We
> > indeed don't set pix_fmt if has_alpha = 0, which seems like the core of the
> > issue. I'm not sure you need to call ff_vp8_decode_init() twice, in fact
> > I'm pretty sure you don't have to. It may also help to assert that pix_fmt
> > is yuv420p(a) when calling vp8 functions.  
> 
> The reason why i replied privatly is because the details of security
> issues should not be discussed in public before the fixes are available
> in releases. As these details are usefull not only to us understanding
> an issue but also to an attacker understanding and expoiting it
> 
> Ill reply privatly again to awnser your questions

Uh, just no.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: move old_filename free operation earlier

[Steven Liu]

2017-05-11 8:52 GMT+08:00 Aaron Levinson :

> On 5/10/2017 3:33 AM, Steven Liu wrote:
>
>> Suggested-by: Aaron Levinson 
>> Signed-off-by: Steven Liu 
>> ---
>>  libavformat/hlsenc.c |3 +--
>>  1 files changed, 1 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 221089c..7ed121a 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1549,14 +1549,13 @@ static int hls_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>>  sls_flag_file_rename(hls, old_filename);
>>  ret = hls_start(s);
>>  }
>> +av_free(old_filename);
>>
>>  if (ret < 0) {
>> -av_free(old_filename);
>>  return ret;
>>  }
>>
>>  if ((ret = hls_window(s, 0)) < 0) {
>> -av_free(old_filename);
>>  return ret;
>>  }
>>  }
>>
>>
> LGTM
>
> Aaron Levinson
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Applied


Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] h264dec: be more explicit in handling container cropping

[James Almer]

On 5/10/2017 9:55 PM, Michael Niedermayer wrote:
> On Wed, May 10, 2017 at 10:41:30AM -0300, James Almer wrote:
>> On 5/9/2017 11:56 PM, Michael Niedermayer wrote:
>>> On Mon, May 08, 2017 at 03:46:23PM -0300, James Almer wrote:
 From: Anton Khirnov 

 The current condition can trigger in cases where it shouldn't, with
 unexpected results.
 Make sure that:
 - container cropping is really based on the original dimensions from the
   caller
 - those dimenions are discarded on size change

 The code is still quite hacky and eventually should be deprecated and
 removed, with the decision about which cropping is used delegated to the
 caller.
 ---
 This merges commit 4fded0480f20f4d7ca5e776a85574de34dfead14 from libav

  libavcodec/h264_slice.c | 20 +---
  libavcodec/h264dec.c|  3 +++
  libavcodec/h264dec.h|  5 +
  3 files changed, 21 insertions(+), 7 deletions(-)

 diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
 index acf6a73f60..a7916e09ce 100644
 --- a/libavcodec/h264_slice.c
 +++ b/libavcodec/h264_slice.c
 @@ -378,6 +378,8 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
  h->avctx->coded_width   = h1->avctx->coded_width;
  h->avctx->width = h1->avctx->width;
  h->avctx->height= h1->avctx->height;
 +h->width_from_caller= h1->width_from_caller;
 +h->height_from_caller   = h1->height_from_caller;
  h->coded_picture_number = h1->coded_picture_number;
  h->first_field  = h1->first_field;
  h->picture_structure= h1->picture_structure;
>>>
 @@ -874,13 +876,17 @@ static int init_dimensions(H264Context *h)
  av_assert0(sps->crop_top + sps->crop_bottom < (unsigned)h->height);
  
  /* handle container cropping */
 -if (FFALIGN(h->avctx->width,  16) == FFALIGN(width,  16) &&
 -FFALIGN(h->avctx->height, 16) == FFALIGN(height, 16) &&
 -h->avctx->width  <= width &&
 -h->avctx->height <= height
 -) {
 -width  = h->avctx->width;
 -height = h->avctx->height;
 +if (h->width_from_caller > 0 && h->height_from_caller > 0 &&
 +!sps->crop_top && !sps->crop_left &&
 +FFALIGN(h->width_from_caller,  16) == FFALIGN(width,  16) &&
 +FFALIGN(h->height_from_caller, 16) == FFALIGN(height, 16) &&
 +h->width_from_caller  <= width &&
 +h->height_from_caller <= height) {
 +width  = h->width_from_caller;
 +height = h->height_from_caller;
 +} else {
 +h->width_from_caller  = 0;
 +h->height_from_caller = 0;
  }
>>>
>>> With this, seeking in a file could affect if croping is used
>>> would something break if croping was unaffected by what was priorly
>>> decoded ?
>>
>> I don't know. Do you have a test case where this could break that i can
>> check?
> 
> no, it was just an thought that came to my mind when looking at the
> code. I dont remember seeing this break anything, it changed some
> files output though unless these were caused by another patch i had
> locally

Could you try to confirm they weren't changed by this patch? Unless i'm
reading it wrong, this set afaik isn't supposed to change the output of
the decoder (at least not negatively), as reflected by fate, just move
the cropping logic to decode.c

I'd like to apply the set soon so we can resume the merges, so if there
are doubts about this patch i can skip it and add it to
unfortunately-still-growing skipped merges list to be implemented later.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_check_align().

[Michael Niedermayer]

On Wed, May 10, 2017 at 11:10:48PM +0200, Nicolas George wrote:
> Le primidi 21 floréal, an CCXXV, Hendrik Leppkes a écrit :
> > Everywhere I found where the align value is used, its used as (1 <<
> > alignment). In that case, I would prefer to pass the actual alignment
> > here (ie. 32 instead of 5), which is an easier value to understand and
> > matches the various alignment constants/values we already had before.
> 
> I can live with that, but here is my rationale for doing it that way:
> log2(align_mult) is a non-trivial function while 1< built-in.
> 
> I suggest we get a third opinion on the matter.

The direct value like 32 feels more natural to me too, but iam fine
with either.

The avoidance of log() might also favor the other in some cases btw
consider you have a 32 and need to call a fuction that needs a log2(32)

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] h264dec: be more explicit in handling container cropping

[Michael Niedermayer]

On Wed, May 10, 2017 at 10:41:30AM -0300, James Almer wrote:
> On 5/9/2017 11:56 PM, Michael Niedermayer wrote:
> > On Mon, May 08, 2017 at 03:46:23PM -0300, James Almer wrote:
> >> From: Anton Khirnov 
> >>
> >> The current condition can trigger in cases where it shouldn't, with
> >> unexpected results.
> >> Make sure that:
> >> - container cropping is really based on the original dimensions from the
> >>   caller
> >> - those dimenions are discarded on size change
> >>
> >> The code is still quite hacky and eventually should be deprecated and
> >> removed, with the decision about which cropping is used delegated to the
> >> caller.
> >> ---
> >> This merges commit 4fded0480f20f4d7ca5e776a85574de34dfead14 from libav
> >>
> >>  libavcodec/h264_slice.c | 20 +---
> >>  libavcodec/h264dec.c|  3 +++
> >>  libavcodec/h264dec.h|  5 +
> >>  3 files changed, 21 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> >> index acf6a73f60..a7916e09ce 100644
> >> --- a/libavcodec/h264_slice.c
> >> +++ b/libavcodec/h264_slice.c
> >> @@ -378,6 +378,8 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
> >>  h->avctx->coded_width   = h1->avctx->coded_width;
> >>  h->avctx->width = h1->avctx->width;
> >>  h->avctx->height= h1->avctx->height;
> >> +h->width_from_caller= h1->width_from_caller;
> >> +h->height_from_caller   = h1->height_from_caller;
> >>  h->coded_picture_number = h1->coded_picture_number;
> >>  h->first_field  = h1->first_field;
> >>  h->picture_structure= h1->picture_structure;
> > 
> >> @@ -874,13 +876,17 @@ static int init_dimensions(H264Context *h)
> >>  av_assert0(sps->crop_top + sps->crop_bottom < (unsigned)h->height);
> >>  
> >>  /* handle container cropping */
> >> -if (FFALIGN(h->avctx->width,  16) == FFALIGN(width,  16) &&
> >> -FFALIGN(h->avctx->height, 16) == FFALIGN(height, 16) &&
> >> -h->avctx->width  <= width &&
> >> -h->avctx->height <= height
> >> -) {
> >> -width  = h->avctx->width;
> >> -height = h->avctx->height;
> >> +if (h->width_from_caller > 0 && h->height_from_caller > 0 &&
> >> +!sps->crop_top && !sps->crop_left &&
> >> +FFALIGN(h->width_from_caller,  16) == FFALIGN(width,  16) &&
> >> +FFALIGN(h->height_from_caller, 16) == FFALIGN(height, 16) &&
> >> +h->width_from_caller  <= width &&
> >> +h->height_from_caller <= height) {
> >> +width  = h->width_from_caller;
> >> +height = h->height_from_caller;
> >> +} else {
> >> +h->width_from_caller  = 0;
> >> +h->height_from_caller = 0;
> >>  }
> > 
> > With this, seeking in a file could affect if croping is used
> > would something break if croping was unaffected by what was priorly
> > decoded ?
> 
> I don't know. Do you have a test case where this could break that i can
> check?

no, it was just an thought that came to my mind when looking at the
code. I dont remember seeing this break anything, it changed some
files output though unless these were caused by another patch i had
locally


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: move old_filename free operation earlier

[Aaron Levinson]

On 5/10/2017 3:33 AM, Steven Liu wrote:

Suggested-by: Aaron Levinson 
Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 221089c..7ed121a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1549,14 +1549,13 @@ static int hls_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 sls_flag_file_rename(hls, old_filename);
 ret = hls_start(s);
 }
+av_free(old_filename);

 if (ret < 0) {
-av_free(old_filename);
 return ret;
 }

 if ((ret = hls_window(s, 0)) < 0) {
-av_free(old_filename);
 return ret;
 }
 }



LGTM

Aaron Levinson
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.

[Michael Niedermayer]

On Wed, May 10, 2017 at 06:46:41PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, May 10, 2017 at 5:02 PM, Michael Niedermayer  > wrote:
> 
> > On Wed, May 10, 2017 at 10:28:22PM +0200, Nicolas George wrote:
> > > Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> > > > fixed, and now your patchset seems to cause a 1% slowdown of the
> > > > example above
> > >
> > > Thanks. The slowdown is to be expected, since this filter used
> > > non-aligned frames which are now realigned. I guess you can get back the
> > > previous speed by setting "avctx->alignment = 0" in snow_encoder.init().
> > >
> >
> > > The default in this patchset is 5 to fix all the alignment problems, at
> > > the cost of some slowdown in corner cases such as this one. I am not
> > > qualified to decide the best way of setting an optimal value to get
> > > speed without crashes. My opinion would be:
> > >
> > > - have avctx->alignment default to 0;
> > >
> > > - have all codecs with explicit assembly set avctx->alignment to the
> > >   required value;
> > >
> > > - have all codecs that use generic DSP code init it through a function
> > >   that sets the alignment accordingly.
> >
> > hmm
> > run fate with intentionally misaligned frames, and make a list of
> > all codecs that dont crash and work fine.
> 
> 
> That's generally arch-specific. Codecs using AVX2 need 32byte, SSE2/Neon
> only need 16, MMX need none (although 8 would probably be slightly faster).

yes

If a test is written to check codecs like described above. It should
be easy to run it on multiple archs to find out which codecs never
require alignment so as to find an initial default for each.


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_pan: ignore named channels not in current layout

[Ricardo Constantino]

On 11 May 2017 at 00:01, Marton Balint  wrote:

>
> On Wed, 10 May 2017, Ricardo Constantino wrote:
>
> instead of erroring out.
>>
>> af pan=stereo|FL=FL|FR=FR|FC=FC would error because there's no
>> Front Center in stereo layout.
>>
>> This allows just changing the output channel layout and keeping
>> the same channel configuration across more than one output.
>>
>> Example usecase
>> * changing balance to the right-side channels for stereo and 7.1
>>
>> before:
>> pan=stereo|FL=0.2*FL+0.8*FR|FR=0*FL+1*FR
>> pan=7.1|FL=0.2*FL+0.8*FR|FR=0.0*FL+1.0*FR|FC=FC|LFE=LFE|BL=0
>> .2*BL+0.8*BR|BR=0.0*BL+1.0*BR|SL=0.2*SL+0.8*SR|SR=0.0*SL+1.0*SR
>>
>> after:
>> pan=stereo|FL=0.2*FL+0.8*FR|FR=0.0*FL+1.0*FR|FC=FC|LFE=LFE|
>> BL=0.2*BL+0.8*BR|BR=0.0*BL+1.0*BR|SL=0.2*SL+0.8*SR|SR=0.0*SL+1.0*SR
>> pan=7.1|FL=0.2*FL+0.8*FR|FR=0.0*FL+1.0*FR|FC=FC|LFE=LFE|BL=0
>> .2*BL+0.8*BR|BR=0.0*BL+1.0*BR|SL=0.2*SL+0.8*SR|SR=0.0*SL+1.0*SR
>>
>
> You still have to use a different command line for stereo and 7.1, so I
> don't quite see how this simplifies your use case. Even if your use case
> were justified, I'd still think the current behaviour should be preserved
> as a default.
>

My usecase is a script that changes the balance from left to right
without having to assume a certain channel layout.

As is, the script needs to know which channels exist in which layout for
every single layout and change the left and right channels. If you happen to
give pan a channel that doesn't exist it'll fail instead of just ignoring
it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/xpmdec: Fix multiple pointer/memory issues

[Michael Niedermayer]

Most of these were found through code review in response to
fixing 1466/clusterfuzz-testcase-minimized-5961584419536896
There is thus no testcase for most of this.
The initial issue was Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg

Signed-off-by: Michael Niedermayer 
---
 libavcodec/xpmdec.c | 37 ++---
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/libavcodec/xpmdec.c b/libavcodec/xpmdec.c
index 9112d4cb5e..03172e4aad 100644
--- a/libavcodec/xpmdec.c
+++ b/libavcodec/xpmdec.c
@@ -29,6 +29,8 @@
 typedef struct XPMContext {
 uint32_t  *pixels;
 intpixels_size;
+uint8_t   *buf;
+intbuf_size;
 } XPMDecContext;
 
 typedef struct ColorEntry {
@@ -233,6 +235,8 @@ static uint32_t color_string_to_rgba(const char *p, int len)
 const ColorEntry *entry;
 char color_name[100];
 
+len = FFMIN(FFMAX(len, 0), sizeof(color_name) - 1);
+
 if (*p == '#') {
 p++;
 len--;
@@ -299,18 +303,25 @@ static int xpm_decode_frame(AVCodecContext *avctx, void 
*data,
 {
 XPMDecContext *x = avctx->priv_data;
 AVFrame *p=data;
-const uint8_t *end, *ptr = avpkt->data;
+const uint8_t *end, *ptr;
 int ncolors, cpp, ret, i, j;
 int64_t size;
 uint32_t *dst;
 
 avctx->pix_fmt = AV_PIX_FMT_BGRA;
 
-end = avpkt->data + avpkt->size;
-while (memcmp(ptr, "/* XPM */", 9) && ptr < end - 9)
+av_fast_padded_malloc(>buf, >buf_size, avpkt->size);
+if (!x->buf)
+return AVERROR(ENOMEM);
+memcpy(x->buf, avpkt->data, avpkt->size);
+x->buf[avpkt->size] = 0;
+
+ptr = x->buf;
+end = x->buf + avpkt->size;
+while (end - ptr > 9 && memcmp(ptr, "/* XPM */", 9))
 ptr++;
 
-if (ptr >= end) {
+if (end - ptr <= 9) {
 av_log(avctx, AV_LOG_ERROR, "missing signature\n");
 return AVERROR_INVALIDDATA;
 }
@@ -335,7 +346,7 @@ static int xpm_decode_frame(AVCodecContext *avctx, void 
*data,
 
 size = 1;
 for (i = 0; i < cpp; i++)
-size *= 94;
+size *= 95;
 
 if (ncolors <= 0 || ncolors > size) {
 av_log(avctx, AV_LOG_ERROR, "invalid number of colors: %d\n", ncolors);
@@ -349,12 +360,15 @@ static int xpm_decode_frame(AVCodecContext *avctx, void 
*data,
 return AVERROR(ENOMEM);
 
 ptr += mod_strcspn(ptr, ",") + 1;
+if (end - ptr < 1)
+return AVERROR_INVALIDDATA;
+
 for (i = 0; i < ncolors; i++) {
 const uint8_t *index;
 int len;
 
 ptr += mod_strcspn(ptr, "\"") + 1;
-if (ptr + cpp > end)
+if (end - ptr < cpp)
 return AVERROR_INVALIDDATA;
 index = ptr;
 ptr += cpp;
@@ -373,14 +387,20 @@ static int xpm_decode_frame(AVCodecContext *avctx, void 
*data,
 
 x->pixels[ret] = color_string_to_rgba(ptr, len);
 ptr += mod_strcspn(ptr, ",") + 1;
+if (end - ptr < 1)
+return AVERROR_INVALIDDATA;
 }
 
 for (i = 0; i < avctx->height; i++) {
 dst = (uint32_t *)(p->data[0] + i * p->linesize[0]);
+if (end - ptr < 1)
+return AVERROR_INVALIDDATA;
 ptr += mod_strcspn(ptr, "\"") + 1;
+if (end - ptr < 1)
+return AVERROR_INVALIDDATA;
 
 for (j = 0; j < avctx->width; j++) {
-if (ptr + cpp > end)
+if (end - ptr < cpp)
 return AVERROR_INVALIDDATA;
 
 if ((ret = ascii2index(ptr, cpp)) < 0)
@@ -405,6 +425,9 @@ static av_cold int xpm_decode_close(AVCodecContext *avctx)
 XPMDecContext *x = avctx->priv_data;
 av_freep(>pixels);
 
+av_freep(>buf);
+x->buf_size = 0;
+
 return 0;
 }
 
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: Enable MB rate control

[Jun Zhao]

Enable the MB level rate control, verified in i965 driver master branch with 
Skylake. 
From b32e4c9c1de47b3bf76327b0ecd11ccf9e3c693f Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 9 May 2017 08:19:16 +0800
Subject: [PATCH] lavc/vaapi_encode_h264: Enable MB rate control.

Enables macroblock-level bitrate control that generally improves
subjective visual quality. It may have a negative impact on
performance and objective visual quality metrics. Default is off
and can't compatible with Constant QP.

Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode_h264.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 92e29554ed..130a9302eb 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -168,6 +168,7 @@ typedef struct VAAPIEncodeH264Options {
 int qp;
 int quality;
 int low_power;
+int mbbrc;
 } VAAPIEncodeH264Options;
 
 
@@ -1157,6 +1158,12 @@ static av_cold int 
vaapi_encode_h264_configure(AVCodecContext *avctx)
 #endif
 }
 
+if (ctx->va_rc_mode == VA_RC_CQP && opt->mbbrc != 0)
+av_log(avctx, AV_LOG_WARNING, "The MB level bitrate control is not "
+   "compatible with Constant QP, it's will ignored it.\n");
+else
+ctx->rc_params.rc.rc_flags.bits.mb_rate_control = opt->mbbrc;
+
 return 0;
 }
 
@@ -1283,6 +1290,10 @@ static const AVOption vaapi_encode_h264_options[] = {
 { "low_power", "Use low-power encoding mode (experimental: only supported "
   "on some platforms, does not support all features)",
   OFFSET(low_power), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS },
+{ "mbbrc", "MB level bitrate control",
+  OFFSET(mbbrc), AV_OPT_TYPE_FLAGS, { .i64 = 0 }, 0, 1, FLAGS, "mbbrc" },
+{ "off", NULL, 0,  AV_OPT_TYPE_CONST, { .i64 = 0 }, 0, 0, FLAGS, 
"mbbrc"},
+{ "on", NULL, 0,  AV_OPT_TYPE_CONST, { .i64 = 1 }, 0, 0, FLAGS, 
"mbbrc"},
 { NULL },
 };
 
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_pan: ignore named channels not in current layout

[Marton Balint]

On Wed, 10 May 2017, Ricardo Constantino wrote:


instead of erroring out.

af pan=stereo|FL=FL|FR=FR|FC=FC would error because there's no
Front Center in stereo layout.

This allows just changing the output channel layout and keeping
the same channel configuration across more than one output.

Example usecase
* changing balance to the right-side channels for stereo and 7.1

before:
pan=stereo|FL=0.2*FL+0.8*FR|FR=0*FL+1*FR
pan=7.1|FL=0.2*FL+0.8*FR|FR=0.0*FL+1.0*FR|FC=FC|LFE=LFE|BL=0.2*BL+0.8*BR|BR=0.0*BL+1.0*BR|SL=0.2*SL+0.8*SR|SR=0.0*SL+1.0*SR

after:
pan=stereo|FL=0.2*FL+0.8*FR|FR=0.0*FL+1.0*FR|FC=FC|LFE=LFE|BL=0.2*BL+0.8*BR|BR=0.0*BL+1.0*BR|SL=0.2*SL+0.8*SR|SR=0.0*SL+1.0*SR
pan=7.1|FL=0.2*FL+0.8*FR|FR=0.0*FL+1.0*FR|FC=FC|LFE=LFE|BL=0.2*BL+0.8*BR|BR=0.0*BL+1.0*BR|SL=0.2*SL+0.8*SR|SR=0.0*SL+1.0*SR


You still have to use a different command line for stereo and 7.1, so I 
don't quite see how this simplifies your use case. Even if your use case 
were justified, I'd still think the current behaviour should be preserved 
as a default.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.

[Ronald S. Bultje]

Hi,

On Wed, May 10, 2017 at 5:02 PM, Michael Niedermayer  wrote:

> On Wed, May 10, 2017 at 10:28:22PM +0200, Nicolas George wrote:
> > Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> > > fixed, and now your patchset seems to cause a 1% slowdown of the
> > > example above
> >
> > Thanks. The slowdown is to be expected, since this filter used
> > non-aligned frames which are now realigned. I guess you can get back the
> > previous speed by setting "avctx->alignment = 0" in snow_encoder.init().
> >
>
> > The default in this patchset is 5 to fix all the alignment problems, at
> > the cost of some slowdown in corner cases such as this one. I am not
> > qualified to decide the best way of setting an optimal value to get
> > speed without crashes. My opinion would be:
> >
> > - have avctx->alignment default to 0;
> >
> > - have all codecs with explicit assembly set avctx->alignment to the
> >   required value;
> >
> > - have all codecs that use generic DSP code init it through a function
> >   that sets the alignment accordingly.
>
> hmm
> run fate with intentionally misaligned frames, and make a list of
> all codecs that dont crash and work fine.


That's generally arch-specific. Codecs using AVX2 need 32byte, SSE2/Neon
only need 16, MMX need none (although 8 would probably be slightly faster).

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/wavpack: Fix runtime error: signed integer overflow: 2147483642 + 512 cannot be represented in type 'int'

[Michael Niedermayer]

Fixed: 1453/clusterfuzz-testcase-minimized-5024976874766336

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/wavpack.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index d2ba97ee2c..87c065c1e7 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -433,8 +433,8 @@ static inline int wv_unpack_stereo(WavpackFrameContext *s, 
GetBitContext *gb,
 L2 = L + ((s->decorr[i].weightA * (int64_t)A + 512) >> 10);
 R2 = R + ((s->decorr[i].weightB * (int64_t)B + 512) >> 10);
 } else {
-L2 = L + ((s->decorr[i].weightA * A + 512) >> 10);
-R2 = R + ((s->decorr[i].weightB * B + 512) >> 10);
+L2 = L + ((int)(s->decorr[i].weightA * A + 512U) >> 10);
+R2 = R + ((int)(s->decorr[i].weightB * B + 512U) >> 10);
 }
 if (A && L)
 s->decorr[i].weightA -= L ^ A) >> 30) & 2) - 1) * 
s->decorr[i].delta;
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_check_align().

[Clément Bœsch]

On Wed, May 10, 2017 at 11:11:58PM +0200, Hendrik Leppkes wrote:
> On Wed, May 10, 2017 at 11:10 PM, Nicolas George  wrote:
> > Le primidi 21 floréal, an CCXXV, Hendrik Leppkes a écrit :
> >> Everywhere I found where the align value is used, its used as (1 <<
> >> alignment). In that case, I would prefer to pass the actual alignment
> >> here (ie. 32 instead of 5), which is an easier value to understand and
> >> matches the various alignment constants/values we already had before.
> >
> > I can live with that, but here is my rationale for doing it that way:
> > log2(align_mult) is a non-trivial function while 1< > built-in.
> >
> >
> 
> Perhaps, but its not used like that anywhere

it's used at least for the fft API afaik

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_check_align().

[Hendrik Leppkes]

On Wed, May 10, 2017 at 11:10 PM, Nicolas George  wrote:
> Le primidi 21 floréal, an CCXXV, Hendrik Leppkes a écrit :
>> Everywhere I found where the align value is used, its used as (1 <<
>> alignment). In that case, I would prefer to pass the actual alignment
>> here (ie. 32 instead of 5), which is an easier value to understand and
>> matches the various alignment constants/values we already had before.
>
> I can live with that, but here is my rationale for doing it that way:
> log2(align_mult) is a non-trivial function while 1< built-in.
>
>

Perhaps, but its not used like that anywhere, and I can't imagine
why/where we would. Anything you had in mind when that might be
needed?

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_check_align().

[Nicolas George]

Le primidi 21 floréal, an CCXXV, Hendrik Leppkes a écrit :
> Everywhere I found where the align value is used, its used as (1 <<
> alignment). In that case, I would prefer to pass the actual alignment
> here (ie. 32 instead of 5), which is an easier value to understand and
> matches the various alignment constants/values we already had before.

I can live with that, but here is my rationale for doing it that way:
log2(align_mult) is a non-trivial function while 1<

signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_check_align().

[Hendrik Leppkes]

On Tue, May 9, 2017 at 3:19 PM, Nicolas George  wrote:
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 26261d7e40..196d311e29 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -772,6 +772,14 @@ void av_frame_remove_side_data(AVFrame *frame, enum 
> AVFrameSideDataType type);
>  const char *av_frame_side_data_name(enum AVFrameSideDataType type);
>
>  /**
> + * Check if the data pointers of a frame are aligned enough.
> + * Test if all frame data pointers have the alignment lower bits cleared,
> + * i.e. are a multiple of 1< + * @return  >0 if aligned, 0 if not
> + */
> +int av_frame_check_align(const AVFrame *frame, unsigned align);
> +

Everywhere I found where the align value is used, its used as (1 <<
alignment). In that case, I would prefer to pass the actual alignment
here (ie. 32 instead of 5), which is an easier value to understand and
matches the various alignment constants/values we already had before.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.

[Hendrik Leppkes]

On Wed, May 10, 2017 at 10:28 PM, Nicolas George  wrote:
> Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
>> fixed, and now your patchset seems to cause a 1% slowdown of the
>> example above
>
> Thanks. The slowdown is to be expected, since this filter used
> non-aligned frames which are now realigned. I guess you can get back the
> previous speed by setting "avctx->alignment = 0" in snow_encoder.init().
>
> The default in this patchset is 5 to fix all the alignment problems, at
> the cost of some slowdown in corner cases such as this one. I am not
> qualified to decide the best way of setting an optimal value to get
> speed without crashes. My opinion would be:
>
> - have avctx->alignment default to 0;
>
> - have all codecs with explicit assembly set avctx->alignment to the
>   required value;
>
> - have all codecs that use generic DSP code init it through a function
>   that sets the alignment accordingly.
>

If you want to fix these problems, you should rather white-list codecs
which are known to be safe, instead of the other way around.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.

[Michael Niedermayer]

On Wed, May 10, 2017 at 10:28:22PM +0200, Nicolas George wrote:
> Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> > fixed, and now your patchset seems to cause a 1% slowdown of the
> > example above
> 
> Thanks. The slowdown is to be expected, since this filter used
> non-aligned frames which are now realigned. I guess you can get back the
> previous speed by setting "avctx->alignment = 0" in snow_encoder.init().
> 

> The default in this patchset is 5 to fix all the alignment problems, at
> the cost of some slowdown in corner cases such as this one. I am not
> qualified to decide the best way of setting an optimal value to get
> speed without crashes. My opinion would be:
> 
> - have avctx->alignment default to 0;
> 
> - have all codecs with explicit assembly set avctx->alignment to the
>   required value;
> 
> - have all codecs that use generic DSP code init it through a function
>   that sets the alignment accordingly.

hmm
run fate with intentionally misaligned frames, and make a list of
all codecs that dont crash and work fine.
These should not use realignment as they dont need it and would be
slowed down.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/webp: Fixes null pointer dereference

[Michael Niedermayer]

On Wed, May 10, 2017 at 02:19:48PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, May 10, 2017 at 2:11 PM, Ronald S. Bultje 
> wrote:
> 
> > - return 0, not AVERROR_INVALIDDATA, since alt-ref frames aren't decoding
> > errors.
> >
> 
> I'm also not sure if alt-ref frames in webp (since it's intra-only) make
> any sense. Hmm...

i would think that if the vp8 decoder doesnt produce a output frame
then thats invalid "AVERROR_INVALIDDATA" in webp independant of it
being valid in VP8

CC-ing skal as suggested

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/webp: Always set pix_fmt

[Michael Niedermayer]

On Wed, May 10, 2017 at 02:07:02PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, May 10, 2017 at 12:37 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
> 
> > Fixes: out of array access
> > Fixes: 1434/clusterfuzz-testcase-minimized-6314998085189632
> > Fixes: 1435/clusterfuzz-testcase-minimized-6483783723253760
> >
> > Found-by: continuous fuzzing process https://github.com/google/oss-
> > fuzz/tree/master/targets/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/vp8.c  | 2 ++
> >  libavcodec/webp.c | 3 +--
> >  2 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> > index fe7aa23491..5bf601a8ef 100644
> > --- a/libavcodec/vp8.c
> > +++ b/libavcodec/vp8.c
> > @@ -2550,6 +2550,8 @@ int vp78_decode_frame(AVCodecContext *avctx, void
> > *data, int *got_frame,
> >  enum AVDiscard skip_thresh;
> >  VP8Frame *av_uninit(curframe), *prev_frame;
> >
> > +av_assert0(avctx->pix_fmt == AV_PIX_FMT_YUVA420P || avctx->pix_fmt ==
> > AV_PIX_FMT_YUV420P);
> > +
> >  if (is_vp7)
> >  ret = vp7_decode_frame_header(s, avpkt->data, avpkt->size);
> >  else
> > diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> > index 16c3ae2662..e0cd72d03a 100644
> > --- a/libavcodec/webp.c
> > +++ b/libavcodec/webp.c
> > @@ -1334,9 +1334,8 @@ static int vp8_lossy_decode_frame(AVCodecContext
> > *avctx, AVFrame *p,
> >  if (!s->initialized) {
> >  ff_vp8_decode_init(avctx);
> >  s->initialized = 1;
> > -if (s->has_alpha)
> > -avctx->pix_fmt = AV_PIX_FMT_YUVA420P;
> >  }
> > +avctx->pix_fmt = s->has_alpha ? AV_PIX_FMT_YUVA420P :
> > AV_PIX_FMT_YUV420P;
> >  s->lossless = 0;
> >
> >  if (data_size > INT_MAX) {
> > --
> > 2.11.0
> 
> 
> lgtm, thanks.

applied

thx

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.

[Paul B Mahol]

On 5/10/17, Michael Niedermayer  wrote:
> On Wed, May 10, 2017 at 05:49:20PM +0200, Nicolas George wrote:
>> Le primidi 21 floreal, an CCXXV, Michael Niedermayer a ecrit :
>> > breaks (green stuff on edges)
>> >  ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -an -vframes 5  -vf uspp=4:8
>> > -qscale 1 -y file.avi
>>
>> It is a bug in vf_uspp:
>>
>> diff --git a/libavfilter/vf_uspp.c b/libavfilter/vf_uspp.c
>> index ef493b860f..6e378253a0 100644
>> --- a/libavfilter/vf_uspp.c
>> +++ b/libavfilter/vf_uspp.c
>> @@ -250,6 +250,9 @@ static void filter(USPPContext *p, uint8_t *dst[3],
>> uint8_t *src[3],
>>  p->frame->data[2] = p->src[2] + x1c  + y1c  *
>> p->frame->linesize[2];
>>  p->frame->format  = p->avctx_enc[i]->pix_fmt;
>>
>> +av_log(0, 16, "encode %d x %d with %d x %d\n",
>> +   p->frame->width, p->frame->height,
>> +   p->avctx_enc[i]->width, p->avctx_enc[i]->height);
>>  ret = avcodec_encode_video2(p->avctx_enc[i], , p->frame,
>> _pkt_ptr);
>>  if (ret < 0) {
>>  av_log(p->avctx_enc[i], AV_LOG_ERROR, "Encoding failed\n");
>>
>> gives:
>>
>>   Stream #0:1 -> #0:0 (mpeg2video (native) -> mpeg4 (native))
>> encode 720 x 576 with 736 x 592
>> zsh: segmentation fault  ./ffmpeg_g -nostdin -i
>> ~/tmp/samples/matrixbench_mpeg2.mpg -an -vframes 5 -vf
>>
>> vf_uspp is giving a 720 *576 frame to a 736 *592 encoder.
>>
>> I do not know how to fix that.
>
> fixed, and now your patchset seems to cause a 1% slowdown of the
> example above
>
> real0m2.182s
> user0m2.129s
> sys 0m0.064s
>
> real0m2.182s
> user0m2.131s
> sys 0m0.064s
>
> real0m2.182s
> user0m2.124s
> sys 0m0.072s
>
> vs:
> real0m2.204s
> user0m2.158s
> sys 0m0.056s
>
> real0m2.203s
> user0m2.151s
> sys 0m0.063s
>
> real0m2.204s
> user0m2.167s
> sys 0m0.048s

Of course it does. Your example exhibits unaligned behaviour.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.

[Nicolas George]

Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> fixed, and now your patchset seems to cause a 1% slowdown of the
> example above

Thanks. The slowdown is to be expected, since this filter used
non-aligned frames which are now realigned. I guess you can get back the
previous speed by setting "avctx->alignment = 0" in snow_encoder.init().

The default in this patchset is 5 to fix all the alignment problems, at
the cost of some slowdown in corner cases such as this one. I am not
qualified to decide the best way of setting an optimal value to get
speed without crashes. My opinion would be:

- have avctx->alignment default to 0;

- have all codecs with explicit assembly set avctx->alignment to the
  required value;

- have all codecs that use generic DSP code init it through a function
  that sets the alignment accordingly.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.

[Michael Niedermayer]

On Wed, May 10, 2017 at 05:49:20PM +0200, Nicolas George wrote:
> Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> > breaks (green stuff on edges)
> >  ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -an -vframes 5  -vf uspp=4:8 
> > -qscale 1 -y file.avi
> 
> It is a bug in vf_uspp: 
> 
> diff --git a/libavfilter/vf_uspp.c b/libavfilter/vf_uspp.c
> index ef493b860f..6e378253a0 100644
> --- a/libavfilter/vf_uspp.c
> +++ b/libavfilter/vf_uspp.c
> @@ -250,6 +250,9 @@ static void filter(USPPContext *p, uint8_t *dst[3], 
> uint8_t *src[3],
>  p->frame->data[2] = p->src[2] + x1c  + y1c  * p->frame->linesize[2];
>  p->frame->format  = p->avctx_enc[i]->pix_fmt;
>  
> +av_log(0, 16, "encode %d x %d with %d x %d\n",
> +   p->frame->width, p->frame->height,
> +   p->avctx_enc[i]->width, p->avctx_enc[i]->height);
>  ret = avcodec_encode_video2(p->avctx_enc[i], , p->frame, 
> _pkt_ptr);
>  if (ret < 0) {
>  av_log(p->avctx_enc[i], AV_LOG_ERROR, "Encoding failed\n");
> 
> gives:
> 
>   Stream #0:1 -> #0:0 (mpeg2video (native) -> mpeg4 (native))
> encode 720 x 576 with 736 x 592
> zsh: segmentation fault  ./ffmpeg_g -nostdin -i 
> ~/tmp/samples/matrixbench_mpeg2.mpg -an -vframes 5 -vf
> 
> vf_uspp is giving a 720×576 frame to a 736×592 encoder.
> 
> I do not know how to fix that.

fixed, and now your patchset seems to cause a 1% slowdown of the
example above

real0m2.182s
user0m2.129s
sys 0m0.064s

real0m2.182s
user0m2.131s
sys 0m0.064s

real0m2.182s
user0m2.124s
sys 0m0.072s

vs:
real0m2.204s
user0m2.158s
sys 0m0.056s

real0m2.203s
user0m2.151s
sys 0m0.063s

real0m2.204s
user0m2.167s
sys 0m0.048s


[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/af_pan: ignore named channels not in current layout

[Ricardo Constantino]

instead of erroring out.

af pan=stereo|FL=FL|FR=FR|FC=FC would error because there's no
Front Center in stereo layout.

This allows just changing the output channel layout and keeping
the same channel configuration across more than one output.

Example usecase
* changing balance to the right-side channels for stereo and 7.1

before:
pan=stereo|FL=0.2*FL+0.8*FR|FR=0*FL+1*FR
pan=7.1|FL=0.2*FL+0.8*FR|FR=0.0*FL+1.0*FR|FC=FC|LFE=LFE|BL=0.2*BL+0.8*BR|BR=0.0*BL+1.0*BR|SL=0.2*SL+0.8*SR|SR=0.0*SL+1.0*SR

after:
pan=stereo|FL=0.2*FL+0.8*FR|FR=0.0*FL+1.0*FR|FC=FC|LFE=LFE|BL=0.2*BL+0.8*BR|BR=0.0*BL+1.0*BR|SL=0.2*SL+0.8*SR|SR=0.0*SL+1.0*SR
pan=7.1|FL=0.2*FL+0.8*FR|FR=0.0*FL+1.0*FR|FC=FC|LFE=LFE|BL=0.2*BL+0.8*BR|BR=0.0*BL+1.0*BR|SL=0.2*SL+0.8*SR|SR=0.0*SL+1.0*SR
---
 libavfilter/af_pan.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavfilter/af_pan.c b/libavfilter/af_pan.c
index 63d7750f35..9c44ba1cda 100644
--- a/libavfilter/af_pan.c
+++ b/libavfilter/af_pan.c
@@ -136,10 +136,9 @@ static av_cold int init(AVFilterContext *ctx)
 }
 if (named) {
 if (!((pan->out_channel_layout >> out_ch_id) & 1)) {
-av_log(ctx, AV_LOG_ERROR,
-   "Channel \"%.8s\" does not exist in the chosen 
layout\n", arg0);
-ret = AVERROR(EINVAL);
-goto fail;
+av_log(ctx, AV_LOG_VERBOSE,
+   "Channel \"%.8s\" does not exist in the chosen layout, 
skipping\n", arg0);
+continue;
 }
 /* get the channel number in the output channel layout:
  * out_channel_layout & ((1 << out_ch_id) - 1) are all the
-- 
2.12.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc : Support Video Codec SDK 8.0

[Timo Rothenpieler]

CUVIDPROCPARAMS gained documentation for some raw YUV parameters.
Does this mean we could create a cuvid_vpp filter, which uses the cuvid scaler 
and deinterlacer without needing to decode something to use it?
I can't find anything about this in the SDK documentation pdfs included with it.


This is possible (was possible earlier too). We can create a raw decoder that 
will get input as raw YUV and apply postprocessing and get raw YUV 
postprocessed output.


Is there any documentation to be found on how to use that?
I tried a very naive approach, which doesn't yield anything good except 
errors and/or corrupted frames:

https://github.com/BtbN/FFmpeg/blob/master/libavfilter/vf_nvpp.c#L85


Regards,
Yogender

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v10] - Added Turing codec interface for ffmpeg

[Hendrik Leppkes]

On Wed, May 10, 2017 at 8:14 PM, Paul B Mahol  wrote:
> On 5/10/17, Saverio Blasi  wrote:
>> Dear Michael,
>>
>>  >> Why do you pass a single string of all options and then manually parse
>> all options out of it instead of specifying the options each in teh AVOption
>> array ?
>>
>> We prefer to pass a single string so that we can be more flexible how we
>> then parse it and what to do with it. This gives us more freedom in the
>> future in case we decide to change some of the codec APIs, so that we do not
>> need to change the interface with FFmpeg.
>
> That is unacceptable.

libx264 and 265 pass options the same way, what exactly is the problem
with that?

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/webp: Fixes null pointer dereference

[Ronald S. Bultje]

Hi,

On Wed, May 10, 2017 at 2:11 PM, Ronald S. Bultje 
wrote:

> - return 0, not AVERROR_INVALIDDATA, since alt-ref frames aren't decoding
> errors.
>

I'm also not sure if alt-ref frames in webp (since it's intra-only) make
any sense. Hmm...

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/aarch64/simple_idct: separate macro arguments with commas

[Matthieu Bouron]

On Tue, May 09, 2017 at 11:08:48PM +0200, Matthieu Bouron wrote:
> On Sun, May 7, 2017 at 11:05 AM, Matthieu Bouron 
> wrote:
> 
> >
> >
> > Le 2 mai 2017 12:01 PM, "Benoit Fouet"  a écrit :
> >
> > Hi,
> >
> >
> > On 28/04/2017 21:58, Matthieu Bouron wrote:
> > > Untested: fixes ticket #6324.
> > > ---
> > >  libavcodec/aarch64/simple_idct_neon.S | 12 ++--
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/libavcodec/aarch64/simple_idct_neon.S
> > b/libavcodec/aarch64/simple_idct_neon.S
> > > index 52273420f9..d31f72a609 100644
> > > --- a/libavcodec/aarch64/simple_idct_neon.S
> > > +++ b/libavcodec/aarch64/simple_idct_neon.S
> > > @@ -61,19 +61,19 @@ endconst
> > >  br  x10
> > >  .endm
> > >
> > > -.macro smull1 a b c
> > > +.macro smull1 a, b, c
> > >  smull   \a, \b, \c
> > >  .endm
> > >
> > > -.macro smlal1 a b c
> > > +.macro smlal1 a, b, c
> > >  smlal   \a, \b, \c
> > >  .endm
> > >
> > > -.macro smlsl1 a b c
> > > +.macro smlsl1 a, b, c
> > >  smlsl   \a, \b, \c
> > >  .endm
> > >
> > > -.macro idct_col4_top y1 y2 y3 y4 i l
> > > +.macro idct_col4_top y1, y2, y3, y4, i, l
> > >  smull\i v7.4S,  \y3\().\l, z2
> > >  smull\i v16.4S, \y3\().\l, z6
> > >  smull\i v17.4S, \y2\().\l, z1
> > > @@ -91,7 +91,7 @@ endconst
> > >  smlsl\i v6.4S,  \y4\().\l, z5
> > >  .endm
> > >
> > > -.macro idct_row4_neon y1 y2 y3 y4 pass
> > > +.macro idct_row4_neon y1, y2, y3, y4, pass
> > >  ld1 {\y1\().2D-\y2\().2D}, [x2], #32
> > >  moviv23.4S, #1<<2, lsl #8
> > >  orr v5.16B, \y1\().16B, \y2\().16B
> > > @@ -153,7 +153,7 @@ endconst
> > >  trn2\y4\().4S, v17.4S, v19.4S
> > >  .endm
> > >
> > > -.macro declare_idct_col4_neon i l
> > > +.macro declare_idct_col4_neon i, l
> > >  function idct_col4_neon\i
> > >  dup v23.4H, z4c
> > >  .if \i == 1
> >
> > Sounds sane, but shouldn't we be doing this for all instances of
> > multiple arguments macros without commas?
> >
> >
> > Sure, I may have missed some. I will work again on this patch on Tuesday
> > as I will have access to an apple machine (and hopefully fix the build
> > without gas-preprocessor).
> >
> > Sorry for the delay,
> > Matthieu
> >
> >
> Updated patch attached:
>   * add missing commas to separate macro arguments
>   * passes .4H/.8H as macro arguments instead of .4H/.8H (the later form
> being interpreted as an hexadecimal value, ie: 4/8).

> From e27ac0f3a8b6436a7530ee5c5c514bfdfac4a558 Mon Sep 17 00:00:00 2001
> From: Matthieu Bouron 
> Date: Fri, 28 Apr 2017 21:58:55 +0200
> Subject: [PATCH] lavc/aarch64/simple_idct: fix iOS build without
>  gas-preprocessor
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Separates macro arguments with commas and passes .4H/.8H as macro
> arguments instead of 4H/8H (the later form being interpreted as an
> hexadecimal value).
> 
> Fixes ticket #6324.
> 
> Suggested-by: Martin Storsjö 
> ---
>  libavcodec/aarch64/simple_idct_neon.S | 74 
> +--
>  1 file changed, 37 insertions(+), 37 deletions(-)
> 
> diff --git a/libavcodec/aarch64/simple_idct_neon.S 
> b/libavcodec/aarch64/simple_idct_neon.S
> index 52273420f9..92987985d2 100644
> --- a/libavcodec/aarch64/simple_idct_neon.S
> +++ b/libavcodec/aarch64/simple_idct_neon.S
> @@ -61,37 +61,37 @@ endconst
>  br  x10
>  .endm
>  
> -.macro smull1 a b c
> +.macro smull1 a, b, c
>  smull   \a, \b, \c
>  .endm
>  
> -.macro smlal1 a b c
> +.macro smlal1 a, b, c
>  smlal   \a, \b, \c
>  .endm
>  
> -.macro smlsl1 a b c
> +.macro smlsl1 a, b, c
>  smlsl   \a, \b, \c
>  .endm
>  
> -.macro idct_col4_top y1 y2 y3 y4 i l
> -smull\i v7.4S,  \y3\().\l, z2
> -smull\i v16.4S, \y3\().\l, z6
> -smull\i v17.4S, \y2\().\l, z1
> +.macro idct_col4_top y1, y2, y3, y4, i, l
> +smull\i v7.4S,  \y3\l, z1
> +smull\i v16.4S, \y3\l, z6
> +smull\i v17.4S, \y2\l, z1
>  add v19.4S, v23.4S, v7.4S
> -smull\i v18.4S, \y2\().\l, z3
> +smull\i v18.4S, \y2\l, z3
>  add v20.4S, v23.4S, v16.4S
> -smull\i v5.4S,  \y2\().\l, z5
> +smull\i v5.4S,  \y2\l, z5
>  sub v21.4S, v23.4S, v16.4S
> -smull\i v6.4S,  \y2\().\l, z7
> +smull\i v6.4S,  \y2\l, z7
>  sub v22.4S, v23.4S, v7.4S
>  
> -smlal\i v17.4S, \y4\().\l, z3
> -smlsl\i v18.4S, \y4\().\l, z7
> -smlsl\i v5.4S,  \y4\().\l, z1
> -

Re: [FFmpeg-devel] [PATCH v10] - Added Turing codec interface for ffmpeg

[Paul B Mahol]

On 5/10/17, Saverio Blasi  wrote:
> Dear Michael,
>
>  >> Why do you pass a single string of all options and then manually parse
> all options out of it instead of specifying the options each in teh AVOption
> array ?
>
> We prefer to pass a single string so that we can be more flexible how we
> then parse it and what to do with it. This gives us more freedom in the
> future in case we decide to change some of the codec APIs, so that we do not
> need to change the interface with FFmpeg.

That is unacceptable.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/webp: Fixes null pointer dereference

[Ronald S. Bultje]

Hi,

On Wed, May 10, 2017 at 12:37 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:

> Fixes: 1470/clusterfuzz-testcase-minimized-5404421666111488
> Fixes: 1472/clusterfuzz-testcase-minimized-5677426430443520
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/webp.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> index e0cd72d03a..1eebb8ccef 100644
> --- a/libavcodec/webp.c
> +++ b/libavcodec/webp.c
> @@ -1351,6 +1351,9 @@ static int vp8_lossy_decode_frame(AVCodecContext
> *avctx, AVFrame *p,
>  if (ret < 0)
>  return ret;
>
> +if (!*got_frame)
> +return AVERROR_INVALIDDATA;


This has real meaning - it suggests alt-ref frames don't have alpha planes.
Suggestions:
- please confirm that with @skal;
- return 0, not AVERROR_INVALIDDATA, since alt-ref frames aren't decoding
errors.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/hevc_sei: fix amount of bits skipped when reading picture timing SEI message

[James Almer]

On 5/10/2017 8:06 AM, Michael Niedermayer wrote:
> On Tue, May 09, 2017 at 12:29:55PM -0300, James Almer wrote:
>> The code was skipping the entire reported SEI message size regardless of 
>> the amount of bits read.
>> While in theory safe for NALU where the picture timing SEI message is alone
>> or at the end as we're using the checked bitstream reader, it isn't in any
>> other situation, where every SEI message in the NALU after the picture
>> timing one would potentially fail to parse.
>>
>> Change the function name to one more in line with the rest of file, and
>> remove the bogus "Skipped SEI" debug message while at it.
>>
>> Signed-off-by: James Almer 
>> ---
>> No test case, all the files i checked plus those in the FATE suite seem to
>> have one SEI message per NALU, or the Picture Timing SEI as the last one.
>>
>>  libavcodec/hevc_sei.c | 15 +++
>>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> I think the "skip to match the size" should be done in a single place
> for all SEI units and parsing should probably continue even if a SEI
> unit has a failure of some kind.

Might look into this later.

> 
> the patch is fine too ...

Pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/webp: Always set pix_fmt

[Ronald S. Bultje]

Hi,

On Wed, May 10, 2017 at 12:37 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:

> Fixes: out of array access
> Fixes: 1434/clusterfuzz-testcase-minimized-6314998085189632
> Fixes: 1435/clusterfuzz-testcase-minimized-6483783723253760
>
> Found-by: continuous fuzzing process https://github.com/google/oss-
> fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vp8.c  | 2 ++
>  libavcodec/webp.c | 3 +--
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> index fe7aa23491..5bf601a8ef 100644
> --- a/libavcodec/vp8.c
> +++ b/libavcodec/vp8.c
> @@ -2550,6 +2550,8 @@ int vp78_decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
>  enum AVDiscard skip_thresh;
>  VP8Frame *av_uninit(curframe), *prev_frame;
>
> +av_assert0(avctx->pix_fmt == AV_PIX_FMT_YUVA420P || avctx->pix_fmt ==
> AV_PIX_FMT_YUV420P);
> +
>  if (is_vp7)
>  ret = vp7_decode_frame_header(s, avpkt->data, avpkt->size);
>  else
> diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> index 16c3ae2662..e0cd72d03a 100644
> --- a/libavcodec/webp.c
> +++ b/libavcodec/webp.c
> @@ -1334,9 +1334,8 @@ static int vp8_lossy_decode_frame(AVCodecContext
> *avctx, AVFrame *p,
>  if (!s->initialized) {
>  ff_vp8_decode_init(avctx);
>  s->initialized = 1;
> -if (s->has_alpha)
> -avctx->pix_fmt = AV_PIX_FMT_YUVA420P;
>  }
> +avctx->pix_fmt = s->has_alpha ? AV_PIX_FMT_YUVA420P :
> AV_PIX_FMT_YUV420P;
>  s->lossless = 0;
>
>  if (data_size > INT_MAX) {
> --
> 2.11.0


lgtm, thanks.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] CUDA Scale Filter

[Yogender Gupta]

Please find attached a patch for CUDA Scale Filter. I have modified the 
makefiles as suggested during the previous reviews to have all PTX generated 
during compile time.

Common.mak has changes for PTX generation
Ptx2c.sh has been added in ffbuild folder. This is needed to covert PTX to C
Users would be required to only include .c and .cu files when adding new CUDA 
filters.

Was tested under MingW.

Thanks,
Yogender

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


0001-scale_cuda-CUDA-Scale-Filter.patch
Description: 0001-scale_cuda-CUDA-Scale-Filter.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avcodec/webp: Fixes null pointer dereference

[Michael Niedermayer]

Fixes: 1470/clusterfuzz-testcase-minimized-5404421666111488
Fixes: 1472/clusterfuzz-testcase-minimized-5677426430443520

Signed-off-by: Michael Niedermayer 
---
 libavcodec/webp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index e0cd72d03a..1eebb8ccef 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1351,6 +1351,9 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx, 
AVFrame *p,
 if (ret < 0)
 return ret;
 
+if (!*got_frame)
+return AVERROR_INVALIDDATA;
+
 update_canvas_size(avctx, avctx->width, avctx->height);
 
 if (s->has_alpha) {
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avcodec/webp: Always set pix_fmt

[Michael Niedermayer]

Fixes: out of array access
Fixes: 1434/clusterfuzz-testcase-minimized-6314998085189632
Fixes: 1435/clusterfuzz-testcase-minimized-6483783723253760

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/vp8.c  | 2 ++
 libavcodec/webp.c | 3 +--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index fe7aa23491..5bf601a8ef 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -2550,6 +2550,8 @@ int vp78_decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 enum AVDiscard skip_thresh;
 VP8Frame *av_uninit(curframe), *prev_frame;
 
+av_assert0(avctx->pix_fmt == AV_PIX_FMT_YUVA420P || avctx->pix_fmt == 
AV_PIX_FMT_YUV420P);
+
 if (is_vp7)
 ret = vp7_decode_frame_header(s, avpkt->data, avpkt->size);
 else
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 16c3ae2662..e0cd72d03a 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1334,9 +1334,8 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx, 
AVFrame *p,
 if (!s->initialized) {
 ff_vp8_decode_init(avctx);
 s->initialized = 1;
-if (s->has_alpha)
-avctx->pix_fmt = AV_PIX_FMT_YUVA420P;
 }
+avctx->pix_fmt = s->has_alpha ? AV_PIX_FMT_YUVA420P : AV_PIX_FMT_YUV420P;
 s->lossless = 0;
 
 if (data_size > INT_MAX) {
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.

[Nicolas George]

Le primidi 21 floréal, an CCXXV, Michael Niedermayer a écrit :
> breaks (green stuff on edges)
>  ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -an -vframes 5  -vf uspp=4:8 
> -qscale 1 -y file.avi

It is a bug in vf_uspp: 

diff --git a/libavfilter/vf_uspp.c b/libavfilter/vf_uspp.c
index ef493b860f..6e378253a0 100644
--- a/libavfilter/vf_uspp.c
+++ b/libavfilter/vf_uspp.c
@@ -250,6 +250,9 @@ static void filter(USPPContext *p, uint8_t *dst[3], uint8_t 
*src[3],
 p->frame->data[2] = p->src[2] + x1c  + y1c  * p->frame->linesize[2];
 p->frame->format  = p->avctx_enc[i]->pix_fmt;
 
+av_log(0, 16, "encode %d x %d with %d x %d\n",
+   p->frame->width, p->frame->height,
+   p->avctx_enc[i]->width, p->avctx_enc[i]->height);
 ret = avcodec_encode_video2(p->avctx_enc[i], , p->frame, 
_pkt_ptr);
 if (ret < 0) {
 av_log(p->avctx_enc[i], AV_LOG_ERROR, "Encoding failed\n");

gives:

  Stream #0:1 -> #0:0 (mpeg2video (native) -> mpeg4 (native))
encode 720 x 576 with 736 x 592
zsh: segmentation fault  ./ffmpeg_g -nostdin -i 
~/tmp/samples/matrixbench_mpeg2.mpg -an -vframes 5 -vf

vf_uspp is giving a 720×576 frame to a 736×592 encoder.

I do not know how to fix that.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc:Add Fractional CQ Support

[Timo Rothenpieler]

Am 10.05.2017 um 16:18 schrieb Moritz Barsnick:
> On Wed, May 10, 2017 at 10:31:59 +0200, Timo Rothenpieler wrote:
>> applied, thanks!
> 
> Did you notice that the patch has Windows line endings in the
> changed/added lines? I'm not sure whether that leaks into git when you
> apply/push it, and I haven't managed to check. (tools/patcheck doesn't
> seem to notice, while it does report trailing whitespace on _some_
> lines.)

Didn't notice that, and git am also doesn't seem to care and do the
right thing, so all is fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc:Add Fractional CQ Support

[Moritz Barsnick]

On Wed, May 10, 2017 at 10:31:59 +0200, Timo Rothenpieler wrote:
> applied, thanks!

Did you notice that the patch has Windows line endings in the
changed/added lines? I'm not sure whether that leaks into git when you
apply/push it, and I haven't managed to check. (tools/patcheck doesn't
seem to notice, while it does report trailing whitespace on _some_
lines.)

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] h264dec: be more explicit in handling container cropping

[James Almer]

On 5/9/2017 11:56 PM, Michael Niedermayer wrote:
> On Mon, May 08, 2017 at 03:46:23PM -0300, James Almer wrote:
>> From: Anton Khirnov 
>>
>> The current condition can trigger in cases where it shouldn't, with
>> unexpected results.
>> Make sure that:
>> - container cropping is really based on the original dimensions from the
>>   caller
>> - those dimenions are discarded on size change
>>
>> The code is still quite hacky and eventually should be deprecated and
>> removed, with the decision about which cropping is used delegated to the
>> caller.
>> ---
>> This merges commit 4fded0480f20f4d7ca5e776a85574de34dfead14 from libav
>>
>>  libavcodec/h264_slice.c | 20 +---
>>  libavcodec/h264dec.c|  3 +++
>>  libavcodec/h264dec.h|  5 +
>>  3 files changed, 21 insertions(+), 7 deletions(-)
>>
>> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
>> index acf6a73f60..a7916e09ce 100644
>> --- a/libavcodec/h264_slice.c
>> +++ b/libavcodec/h264_slice.c
>> @@ -378,6 +378,8 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
>>  h->avctx->coded_width   = h1->avctx->coded_width;
>>  h->avctx->width = h1->avctx->width;
>>  h->avctx->height= h1->avctx->height;
>> +h->width_from_caller= h1->width_from_caller;
>> +h->height_from_caller   = h1->height_from_caller;
>>  h->coded_picture_number = h1->coded_picture_number;
>>  h->first_field  = h1->first_field;
>>  h->picture_structure= h1->picture_structure;
> 
>> @@ -874,13 +876,17 @@ static int init_dimensions(H264Context *h)
>>  av_assert0(sps->crop_top + sps->crop_bottom < (unsigned)h->height);
>>  
>>  /* handle container cropping */
>> -if (FFALIGN(h->avctx->width,  16) == FFALIGN(width,  16) &&
>> -FFALIGN(h->avctx->height, 16) == FFALIGN(height, 16) &&
>> -h->avctx->width  <= width &&
>> -h->avctx->height <= height
>> -) {
>> -width  = h->avctx->width;
>> -height = h->avctx->height;
>> +if (h->width_from_caller > 0 && h->height_from_caller > 0 &&
>> +!sps->crop_top && !sps->crop_left &&
>> +FFALIGN(h->width_from_caller,  16) == FFALIGN(width,  16) &&
>> +FFALIGN(h->height_from_caller, 16) == FFALIGN(height, 16) &&
>> +h->width_from_caller  <= width &&
>> +h->height_from_caller <= height) {
>> +width  = h->width_from_caller;
>> +height = h->height_from_caller;
>> +} else {
>> +h->width_from_caller  = 0;
>> +h->height_from_caller = 0;
>>  }
> 
> With this, seeking in a file could affect if croping is used
> would something break if croping was unaffected by what was priorly
> decoded ?

I don't know. Do you have a test case where this could break that i can
check?

I could skip this patch, seeing it's one of the points where it didn't
apply cleanly. Perhaps the faulty condition the commit message mentioned
was already dealt with on our side.
The next patch still works and fate passes if i only add the
"!sps->crop_top && !sps->crop_left" checks from this patch (it fails
without them).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/webp: Reinitilaize VP8 decoder on pixel format mismatch

[Michael Niedermayer]

On Wed, May 10, 2017 at 08:10:23AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Tue, May 9, 2017 at 9:24 PM, Michael Niedermayer 
> wrote:
> 
> > On Tue, May 09, 2017 at 09:08:08PM -0400, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Tue, May 9, 2017 at 8:37 PM, Michael Niedermayer
> > 
> > > wrote:
> > >
> > > > Fixes: out of array access
> > > > Fixes: 1434/clusterfuzz-testcase-minimized-6314998085189632
> > > > Fixes: 1435/clusterfuzz-testcase-minimized-6483783723253760
> > > >
> > > > Found-by: continuous fuzzing process https://github.com/google/oss-
> > > > fuzz/tree/master/targets/ffmpeg
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavcodec/webp.c | 9 +++--
> > > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> > > > index 16c3ae2662..23ed4bc26f 100644
> > > > --- a/libavcodec/webp.c
> > > > +++ b/libavcodec/webp.c
> > > > @@ -1330,12 +1330,17 @@ static int vp8_lossy_decode_frame(
> > AVCodecContext
> > > > *avctx, AVFrame *p,
> > > >  WebPContext *s = avctx->priv_data;
> > > >  AVPacket pkt;
> > > >  int ret;
> > > > +enum AVPixelFormat wanted_pix_fmt = s->has_alpha ?
> > > > AV_PIX_FMT_YUVA420P : AV_PIX_FMT_YUV420P;
> > > > +
> > > > +if (s->initialized && wanted_pix_fmt != avctx->pix_fmt) {
> > > > +ff_vp8_decode_free(avctx);
> > > > +s->initialized = 0;
> > > > +}
> > > >
> > > >  if (!s->initialized) {
> > > >  ff_vp8_decode_init(avctx);
> > > >  s->initialized = 1;
> > > > -if (s->has_alpha)
> > > > -avctx->pix_fmt = AV_PIX_FMT_YUVA420P;
> > > > +avctx->pix_fmt = wanted_pix_fmt;
> > > >  }
> > > >  s->lossless = 0;
> > >
> > >
> > > What is the out of array access? webp is intra only and the only thing
> > that
> > > is initialized with memory in that call is reference frames. What's going
> > > on here?
> >
> > webp uses the same context as VP8, and it changes the pixel format
> > as it needs. Vp8 doesnt work if its format is changed under its feet
> 
> 
> I think what you're trying to say is that it doesn't work with RGBA as
> pixel format (it shouldn't need a reset between yuv420p and yuv420pa). We
> indeed don't set pix_fmt if has_alpha = 0, which seems like the core of the
> issue. I'm not sure you need to call ff_vp8_decode_init() twice, in fact
> I'm pretty sure you don't have to. It may also help to assert that pix_fmt
> is yuv420p(a) when calling vp8 functions.

The reason why i replied privatly is because the details of security
issues should not be discussed in public before the fixes are available
in releases. As these details are usefull not only to us understanding
an issue but also to an attacker understanding and expoiting it

Ill reply privatly again to awnser your questions

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v10] - Added Turing codec interface for ffmpeg

[Saverio Blasi]

Dear Michael,

 >> Why do you pass a single string of all options and then manually parse all 
 >> options out of it instead of specifying the options each in teh AVOption 
 >> array ?

We prefer to pass a single string so that we can be more flexible how we then 
parse it and what to do with it. This gives us more freedom in the future in 
case we decide to change some of the codec APIs, so that we do not need to 
change the interface with FFmpeg.

Thanks,
Saverio


-
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless 
specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/vp8dsp: vp7_luma_dc_wht_c: Fix multiple runtime error: signed integer overflow: -1366381240 + -1262413604 cannot be represented in type 'int'

[Michael Niedermayer]

Fixes: 1440/clusterfuzz-testcase-minimized-5785716111966208

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/vp8dsp.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/libavcodec/vp8dsp.c b/libavcodec/vp8dsp.c
index 7d9cfa8278..fed5c67a90 100644
--- a/libavcodec/vp8dsp.c
+++ b/libavcodec/vp8dsp.c
@@ -53,7 +53,8 @@ static void name ## _idct_dc_add4y_c(uint8_t *dst, int16_t 
block[4][16],  \
 #if CONFIG_VP7_DECODER
 static void vp7_luma_dc_wht_c(int16_t block[4][4][16], int16_t dc[16])
 {
-int i, a1, b1, c1, d1;
+int i;
+unsigned a1, b1, c1, d1;
 int16_t tmp[16];
 
 for (i = 0; i < 4; i++) {
@@ -61,10 +62,10 @@ static void vp7_luma_dc_wht_c(int16_t block[4][4][16], 
int16_t dc[16])
 b1 = (dc[i * 4 + 0] - dc[i * 4 + 2]) * 23170;
 c1 = dc[i * 4 + 1] * 12540 - dc[i * 4 + 3] * 30274;
 d1 = dc[i * 4 + 1] * 30274 + dc[i * 4 + 3] * 12540;
-tmp[i * 4 + 0] = (a1 + d1) >> 14;
-tmp[i * 4 + 3] = (a1 - d1) >> 14;
-tmp[i * 4 + 1] = (b1 + c1) >> 14;
-tmp[i * 4 + 2] = (b1 - c1) >> 14;
+tmp[i * 4 + 0] = (int)(a1 + d1) >> 14;
+tmp[i * 4 + 3] = (int)(a1 - d1) >> 14;
+tmp[i * 4 + 1] = (int)(b1 + c1) >> 14;
+tmp[i * 4 + 2] = (int)(b1 - c1) >> 14;
 }
 
 for (i = 0; i < 4; i++) {
@@ -73,10 +74,10 @@ static void vp7_luma_dc_wht_c(int16_t block[4][4][16], 
int16_t dc[16])
 c1 = tmp[i + 4] * 12540 - tmp[i + 12] * 30274;
 d1 = tmp[i + 4] * 30274 + tmp[i + 12] * 12540;
 AV_ZERO64(dc + i * 4);
-block[0][i][0] = (a1 + d1 + 0x2) >> 18;
-block[3][i][0] = (a1 - d1 + 0x2) >> 18;
-block[1][i][0] = (b1 + c1 + 0x2) >> 18;
-block[2][i][0] = (b1 - c1 + 0x2) >> 18;
+block[0][i][0] = (int)(a1 + d1 + 0x2) >> 18;
+block[3][i][0] = (int)(a1 - d1 + 0x2) >> 18;
+block[1][i][0] = (int)(b1 + c1 + 0x2) >> 18;
+block[2][i][0] = (int)(b1 - c1 + 0x2) >> 18;
 }
 }
 
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/webp: Reinitilaize VP8 decoder on pixel format mismatch

[Ronald S. Bultje]

Hi,

On Tue, May 9, 2017 at 9:24 PM, Michael Niedermayer 
wrote:

> On Tue, May 09, 2017 at 09:08:08PM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Tue, May 9, 2017 at 8:37 PM, Michael Niedermayer
> 
> > wrote:
> >
> > > Fixes: out of array access
> > > Fixes: 1434/clusterfuzz-testcase-minimized-6314998085189632
> > > Fixes: 1435/clusterfuzz-testcase-minimized-6483783723253760
> > >
> > > Found-by: continuous fuzzing process https://github.com/google/oss-
> > > fuzz/tree/master/targets/ffmpeg
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/webp.c | 9 +++--
> > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> > > index 16c3ae2662..23ed4bc26f 100644
> > > --- a/libavcodec/webp.c
> > > +++ b/libavcodec/webp.c
> > > @@ -1330,12 +1330,17 @@ static int vp8_lossy_decode_frame(
> AVCodecContext
> > > *avctx, AVFrame *p,
> > >  WebPContext *s = avctx->priv_data;
> > >  AVPacket pkt;
> > >  int ret;
> > > +enum AVPixelFormat wanted_pix_fmt = s->has_alpha ?
> > > AV_PIX_FMT_YUVA420P : AV_PIX_FMT_YUV420P;
> > > +
> > > +if (s->initialized && wanted_pix_fmt != avctx->pix_fmt) {
> > > +ff_vp8_decode_free(avctx);
> > > +s->initialized = 0;
> > > +}
> > >
> > >  if (!s->initialized) {
> > >  ff_vp8_decode_init(avctx);
> > >  s->initialized = 1;
> > > -if (s->has_alpha)
> > > -avctx->pix_fmt = AV_PIX_FMT_YUVA420P;
> > > +avctx->pix_fmt = wanted_pix_fmt;
> > >  }
> > >  s->lossless = 0;
> >
> >
> > What is the out of array access? webp is intra only and the only thing
> that
> > is initialized with memory in that call is reference frames. What's going
> > on here?
>
> webp uses the same context as VP8, and it changes the pixel format
> as it needs. Vp8 doesnt work if its format is changed under its feet


I think what you're trying to say is that it doesn't work with RGBA as
pixel format (it shouldn't need a reset between yuv420p and yuv420pa). We
indeed don't set pix_fmt if has_alpha = 0, which seems like the core of the
issue. I'm not sure you need to call ff_vp8_decode_init() twice, in fact
I'm pretty sure you don't have to. It may also help to assert that pix_fmt
is yuv420p(a) when calling vp8 functions.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Match source video timestamp

[Michael Niedermayer]

On Wed, May 10, 2017 at 01:21:46PM +0200, Michael Niedermayer wrote:
> On Mon, May 08, 2017 at 02:45:55PM +, Eran Kornblau wrote:
> > Ping
> 
> applied
> 
> thx

btw, can you add a fate test for this option ?

thx


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v10] - Added Turing codec interface for ffmpeg

[Michael Niedermayer]

On Tue, May 09, 2017 at 10:08:17AM +, Saverio Blasi wrote:
> - This patch contains the changes to interface the Turing codec 
> (http://turingcodec.org/) with ffmpeg. The patch was modified to address the 
> comments in the review as follows:
>   - Added a pkg-config file to list all dependencies required by libturing. 
> This should address the issue pointed out by Hendrik Leppkes on Fri 18/11/2016
>   - As per suggestions of wm4, two functions (add_option and 
> finalise_options) have been created. The former appends new options while the 
> latter sets up the argv array of pointers to char* accordingly. add_option 
> re-allocates the buffer for options using av_realloc
>   - Additionally, both these functions handle the errors in case the memory 
> wasn't allocated correctly
>   - malloc|free|realloc have been substituted with their corresponding 
> av_{malloc|free|realloc} version
>   - Check on bit-depth has been removed since the ffmpeg already casts the 
> right pix_fmt and bit depth
>   - pix_fmts is now set in ff_libturing_encoder as in h264dec.c.
>   - Changed usage of av_free with av_freep and fixed calls to free arrays
>   - Added brackets to all if and for statements
>   - Avoid repetition of code to free arrays in case of failure to initialise 
> the libturing encoder
>   - Some fixes to address the review from wm4 and Mark Thompson received on 
> Wed 08/02/2017
>   - Fixed indentation
> ---
>  LICENSE.md |   1 +
>  configure  |   6 +
>  libavcodec/Makefile|   1 +
>  libavcodec/allcodecs.c |   1 +
>  libavcodec/libturing.c | 313 
> +
>  5 files changed, 322 insertions(+)
>  create mode 100755 libavcodec/libturing.c
> 
> diff --git a/LICENSE.md b/LICENSE.md
> index ba65b05..03787c0 100644
> --- a/LICENSE.md
> +++ b/LICENSE.md
> @@ -84,6 +84,7 @@ The following libraries are under GPL:
>  - frei0r
>  - libcdio
>  - librubberband
> +- libturing
>  - libvidstab
>  - libx264
>  - libx265
> diff --git a/configure b/configure
> index 2e1786a..0adc4da 100755
> --- a/configure
> +++ b/configure
> @@ -256,6 +256,7 @@ External library support:
>--enable-libssh  enable SFTP protocol via libssh [no]
>--enable-libtesseractenable Tesseract, needed for ocr filter [no]
>--enable-libtheora   enable Theora encoding via libtheora [no]
> +  --enable-libturing   enable H.265/HEVC encoding via libturing [no]
>--enable-libtwolame  enable MP2 encoding via libtwolame [no]
>--enable-libv4l2 enable libv4l2/v4l-utils [no]
>--enable-libvidstab  enable video stabilization using vid.stab [no]
> @@ -1497,6 +1498,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
>  frei0r
>  libcdio
>  librubberband
> +libturing
>  libvidstab
>  libx264
>  libx265
> @@ -2875,6 +2877,7 @@ libspeex_decoder_deps="libspeex"
>  libspeex_encoder_deps="libspeex"
>  libspeex_encoder_select="audio_frame_queue"
>  libtheora_encoder_deps="libtheora"
> +libturing_encoder_deps="libturing"
>  libtwolame_encoder_deps="libtwolame"
>  libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
>  libvorbis_decoder_deps="libvorbis"
> @@ -5831,6 +5834,9 @@ enabled libssh&& require_pkg_config libssh 
> libssh/sftp.h sftp_init
>  enabled libspeex  && require_pkg_config speex speex/speex.h 
> speex_decoder_init -lspeex
>  enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h 
> TessBaseAPICreate
>  enabled libtheora && require libtheora theora/theoraenc.h 
> th_info_init -ltheoraenc -ltheoradec -logg
> +enabled libturing && require_pkg_config libturing turing.h 
> turing_version &&
> + { check_cpp_condition turing.h 
> "TURING_API_VERSION > 1" ||
> + die "ERROR: libturing requires turing api 
> version 2 or greater."; }
>  enabled libtwolame&& require libtwolame twolame.h twolame_init 
> -ltwolame &&
>   { check_lib libtwolame twolame.h 
> twolame_encode_buffer_float32_interleaved -ltwolame ||
> die "ERROR: libtwolame must be installed and 
> version must be >= 0.3.10"; }
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 44acc95..0a11a6b 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -909,6 +909,7 @@ OBJS-$(CONFIG_LIBSHINE_ENCODER)   += libshine.o
>  OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
>  OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
>  OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
> +OBJS-$(CONFIG_LIBTURING_ENCODER)  += libturing.o
>  OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
>  OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
>  OBJS-$(CONFIG_LIBVORBIS_DECODER)  += libvorbisdec.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 7fcc26f..c729b8d 100644
> --- a/libavcodec/allcodecs.c
> +++ 

Re: [FFmpeg-devel] Match source video timestamp

[Michael Niedermayer]

On Mon, May 08, 2017 at 02:45:55PM +, Eran Kornblau wrote:
> Ping

applied

thx

[...]

-- 
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] fate/exr : add test for Y, B44A negative, datawindow != display window

[Michael Niedermayer]

On Tue, May 09, 2017 at 03:36:46PM +0200, Martin Vignali wrote:
> 2017-05-05 4:22 GMT+02:00 Michael Niedermayer :
> 
> > On Mon, May 01, 2017 at 02:31:28PM +0200, Martin Vignali wrote:
> > > Hello,
> > >
> > > In attach a patch to add fate tests for exr
> > >
> > > samples can be found here
> > > https://we.tl/ItuIX0BMfk
> >
> > uploaded
> >
> > Ping for patch apply
> 
> Martin

applied

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] libavformat/tcp: fix return code for tcp_accept

[Michael Niedermayer]

On Mon, May 08, 2017 at 10:58:35AM +0200, Simon Thelen wrote:
> On 17-04-20 at 05:01, Simon Thelen wrote:
> > On 17-04-08 at 14:21, Simon Thelen wrote:
> > > ff_accept can return AVERROR(ETIMEDOUT) and errno will be 0 (or
> > > undefined), return ret instead and return ff_neterror() in
> > > ff_poll_interrupt instead of AVERROR(errno) to parse WSAGetLastError on
> > > Windows.
> > > ---
> > > v2 rewords the commit message to better elucidate the issue.
> > > 
> > >  libavformat/network.c | 2 +-
> > >  libavformat/tcp.c | 2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/libavformat/network.c b/libavformat/network.c
> > > index 2fb1c8b02a..b3987a4d11 100644
> > > --- a/libavformat/network.c
> > > +++ b/libavformat/network.c
> > > @@ -159,7 +159,7 @@ static int ff_poll_interrupt(struct pollfd *p, nfds_t 
> > > nfds, int timeout,
> > >  if (!ret)
> > >  return AVERROR(ETIMEDOUT);
> > >  if (ret < 0)
> > > -return AVERROR(errno);
> > > +return ff_neterrno();
> > >  return ret;
> > >  }
> > >  
> > > diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> > > index 3055e48015..07b4ed9fa3 100644
> > > --- a/libavformat/tcp.c
> > > +++ b/libavformat/tcp.c
> > > @@ -204,7 +204,7 @@ static int tcp_accept(URLContext *s, URLContext **c)
> > >  cc = (*c)->priv_data;
> > >  ret = ff_accept(sc->fd, sc->listen_timeout, s);
> > >  if (ret < 0)
> > > -return ff_neterrno();
> > > +return ret;
> > >  cc->fd = ret;
> > >  return 0;
> > >  }
> > > -- 
> > > 2.12.2
> > > 
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > 
> > ping
> > 
> ping?

applied

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/codecs: Add missing documentation for apply_cropping

[Michael Niedermayer]

On Tue, May 09, 2017 at 06:15:25PM -0800, Lou Logan wrote:
> On Tue,  9 May 2017 17:23:35 +0200
> Michael Niedermayer  wrote:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  doc/codecs.texi | 10 ++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/doc/codecs.texi b/doc/codecs.texi
> > index 1f74c83554..1d8a4e38a4 100644
> > --- a/doc/codecs.texi
> > +++ b/doc/codecs.texi
> > @@ -1279,6 +1279,16 @@ ffprobe -dump_separator "
> >  Maximum number of pixels per image. This value can be used to avoid out of
> >  memory failures due to large images.
> >  
> > +@item apply_cropping @var{integer} (@emph{decoding,video})
> > +Enable cropping if cropping parameters are a multiply of the required
> 
> s/a multiply/multiples
> 
> > +alignment for the left and top parameters. If the alignment is not met the
> > +cropping will be partially applied to maintain alignment.
> > +1(Enabled) by default.
> 
> Default is 1 (enabled).
> 
> > +Note: The required alignment depends on if CODEC_FLAG_UNALIGNED is set and 
> > the
> 
> @code{CODEC_FLAG_UNALIGNED}
> 
> > +CPU. CODEC_FLAG_UNALIGNED cannot be chanaged from the command line. Also hw
> > +decoders will not apply left/top croping.
> 
> hardware

chanegs made

thx

[...9
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/hevc_sei: fix amount of bits skipped when reading picture timing SEI message

[Michael Niedermayer]

On Tue, May 09, 2017 at 12:29:55PM -0300, James Almer wrote:
> The code was skipping the entire reported SEI message size regardless of 
> the amount of bits read.
> While in theory safe for NALU where the picture timing SEI message is alone
> or at the end as we're using the checked bitstream reader, it isn't in any
> other situation, where every SEI message in the NALU after the picture
> timing one would potentially fail to parse.
> 
> Change the function name to one more in line with the rest of file, and
> remove the bogus "Skipped SEI" debug message while at it.
> 
> Signed-off-by: James Almer 
> ---
> No test case, all the files i checked plus those in the FATE suite seem to
> have one SEI message per NALU, or the Picture Timing SEI as the last one.
> 
>  libavcodec/hevc_sei.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)

I think the "skip to match the size" should be done in a single place
for all SEI units and parsing should probably continue even if a SEI
unit has a failure of some kind.

the patch is fine too ...

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc:Add Fractional CQ Support

[Timo Rothenpieler]

Am 10.05.2017 um 10:38 schrieb Hendrik Leppkes:
> On Wed, May 10, 2017 at 10:31 AM, Timo Rothenpieler
>  wrote:
>> Am 10.05.2017 um 08:49 schrieb Yogender Gupta:
>>>
>>> CQ rate control in NVENC now supports fractional values (SDK 8.0). Please
>>> find patch attached for the same.
>>>
>>> Thanks,
>>> Yogender
>>
>>
>> applied, thanks!
>>
>> I'm wondering what the difference between this and constqp mode is, does
>> this set a constant quality in otherwise vbr mode?
> 
> Sounds to me like this doesn't change or introduce a new RC mode, just
> allows the existing CQ modes to use fractional values, ie. more
> precision?

Yes, this patch only enhances that parameter. Was more meant in general,
as I never fully understood what that parameter does.

The constqp rc mode uses the -qp parameter to set its constant quality.
This is something different, and from my observation is fully
independent, at least I see no difference when setting this parameter in
constqp mode.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc:Add Fractional CQ Support

[Yogender Gupta]

>> I'm wondering what the difference between this and constqp mode is, does 
>> this set a constant quality in otherwise vbr mode?

Yes, something similar.

Thanks,
Yogender

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc:Add Fractional CQ Support

[Hendrik Leppkes]

On Wed, May 10, 2017 at 10:31 AM, Timo Rothenpieler
 wrote:
> Am 10.05.2017 um 08:49 schrieb Yogender Gupta:
>>
>> CQ rate control in NVENC now supports fractional values (SDK 8.0). Please
>> find patch attached for the same.
>>
>> Thanks,
>> Yogender
>
>
> applied, thanks!
>
> I'm wondering what the difference between this and constqp mode is, does
> this set a constant quality in otherwise vbr mode?

Sounds to me like this doesn't change or introduce a new RC mode, just
allows the existing CQ modes to use fractional values, ie. more
precision?

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc:Add Fractional CQ Support

[Timo Rothenpieler]

Am 10.05.2017 um 08:49 schrieb Yogender Gupta:

CQ rate control in NVENC now supports fractional values (SDK 8.0). Please find 
patch attached for the same.

Thanks,
Yogender


applied, thanks!

I'm wondering what the difference between this and constqp mode is, does 
this set a constant quality in otherwise vbr mode?

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc:Add Weighted Prediction Support

[Timo Rothenpieler]

Am 10.05.2017 um 09:38 schrieb Yogender Gupta:

Weighted Prediction Support for NVENC (SDK 8.0). Please find patch attached for 
the same.

Thanks,
Yogender


applied, thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/mlv: Fix an snprintf() truncation

[Clément Bœsch]

On Wed, May 10, 2017 at 09:49:50AM +0200, Carl Eugen Hoyos wrote:
> 2017-05-09 16:40 GMT+02:00 Clément Bœsch :
> > On Tue, May 09, 2017 at 03:32:36PM +0200, Carl Eugen Hoyos wrote:
> >> Hi!
> >>
> >> Attached patch fixes a warning when compiling with gcc 7:
> >> libavformat/mlvdec.c: In function ‘read_header’:
> >> libavformat/mlvdec.c:353:58: warning: ‘snprintf’ output may be truncated
> >> before the last format character [-Wformat-truncation=]
> >>  snprintf(filename + strlen(filename) - 2, 3, "%02d", i);
> >>
> >> Please comment, Carl Eugen
> >
> >> From f56bf75b2b8b99cbbe99da8d2e33e46bf50be92d Mon Sep 17 00:00:00 2001
> >> From: Carl Eugen Hoyos 
> >> Date: Tue, 9 May 2017 15:27:44 +0200
> >> Subject: [PATCH] lavf/mlvdec: Avoid snprintf() output truncation.
> >>
> >> Fixes a gcc warning:
> >> 'snprintf' output may be truncated before the last format character
> >> ---
> >>  libavformat/mlvdec.c |2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c
> >> index 319cd26..372acbe 100644
> >> --- a/libavformat/mlvdec.c
> >> +++ b/libavformat/mlvdec.c
> >> @@ -349,7 +349,7 @@ static int read_header(AVFormatContext *avctx)
> >>  if (!filename)
> >>  return AVERROR(ENOMEM);
> >>
> >> -for (i = 0; i < 100; i++) {
> >> +for (i = 0; i < 99; i++) {
> >>  snprintf(filename + strlen(filename) - 2, 3, "%02d", i);
> >>  if (avctx->io_open(avctx, >pb[i], filename, 
> >> AVIO_FLAG_READ, NULL) < 0)
> >>  break;
> >
> > can you explain?
> 
> No, the following allows to reproduce the warning with "-O3 -Wformat"
> and gcc 7 both
> with and without the commented code:
> 
> void foo()
> {
> unsigned i = 0;
> char filename[]="ab";
> while (++i < 100)
> snprintf(filename /*+ strlen(filename) - 2*/, 3, "%02u", i);
> }

it sounds like a GCC bug then, the patch is wrong.

note: this is not the same loop as mlvdec, your example is [1:99], pre
patch mlvdec is [0:99].

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] img2dec: jpeg_probe logic

[Carl Eugen Hoyos]

2017-05-08 22:25 GMT+02:00 Vadim Kalinsky :

> Shouldn't it be something like this?

No, it tries not to beat the mjpeg probe.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/mlv: Fix an snprintf() truncation

[Carl Eugen Hoyos]

2017-05-09 16:40 GMT+02:00 Clément Bœsch :
> On Tue, May 09, 2017 at 03:32:36PM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes a warning when compiling with gcc 7:
>> libavformat/mlvdec.c: In function ‘read_header’:
>> libavformat/mlvdec.c:353:58: warning: ‘snprintf’ output may be truncated
>> before the last format character [-Wformat-truncation=]
>>  snprintf(filename + strlen(filename) - 2, 3, "%02d", i);
>>
>> Please comment, Carl Eugen
>
>> From f56bf75b2b8b99cbbe99da8d2e33e46bf50be92d Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Tue, 9 May 2017 15:27:44 +0200
>> Subject: [PATCH] lavf/mlvdec: Avoid snprintf() output truncation.
>>
>> Fixes a gcc warning:
>> 'snprintf' output may be truncated before the last format character
>> ---
>>  libavformat/mlvdec.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c
>> index 319cd26..372acbe 100644
>> --- a/libavformat/mlvdec.c
>> +++ b/libavformat/mlvdec.c
>> @@ -349,7 +349,7 @@ static int read_header(AVFormatContext *avctx)
>>  if (!filename)
>>  return AVERROR(ENOMEM);
>>
>> -for (i = 0; i < 100; i++) {
>> +for (i = 0; i < 99; i++) {
>>  snprintf(filename + strlen(filename) - 2, 3, "%02d", i);
>>  if (avctx->io_open(avctx, >pb[i], filename, 
>> AVIO_FLAG_READ, NULL) < 0)
>>  break;
>
> can you explain?

No, the following allows to reproduce the warning with "-O3 -Wformat"
and gcc 7 both
with and without the commented code:

void foo()
{
unsigned i = 0;
char filename[]="ab";
while (++i < 100)
snprintf(filename /*+ strlen(filename) - 2*/, 3, "%02u", i);
}

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/avio: fix fill_buffer return error eof when offset1 == buffer_size

[raymond zheng]

ping...

2017-05-08 18:57 GMT+08:00 raymondzheng :

> ---
>  libavformat/aviobuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 0a7c39eacd..20d3b7a02a 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -270,7 +270,7 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int
> whence)
>
>  offset1 = offset - pos; // "offset1" is the relative offset from the
> beginning of s->buffer
>  if (!s->must_flush && (!s->direct || !s->seek) &&
> -offset1 >= 0 && offset1 <= buffer_size - s->write_flag) {
> +offset1 >= 0 && offset1 < buffer_size - s->write_flag) {
>  /* can do the seek inside the buffer */
>  s->buf_ptr = s->buffer + offset1;
>  } else if ((!(s->seekable & AVIO_SEEKABLE_NORMAL) ||
> --
> 2.11.0 (Apple Git-81)
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] nvenc:Add Weighted Prediction Support

[Yogender Gupta]

Weighted Prediction Support for NVENC (SDK 8.0). Please find patch attached for 
the same.

Thanks,
Yogender

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


0001-Add-NVENC-weighted-prediction-support.patch
Description: 0001-Add-NVENC-weighted-prediction-support.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add arbitrary audio FIR filter

[Tobias Rapp]

On 10.05.2017 09:12, Muhammad Faiz wrote:

On Wed, May 10, 2017 at 1:55 AM, Paul B Mahol  wrote:

ffmpeg | branch: master | Paul B Mahol  | Thu Jan 26 17:03:08 
2017 +0100| [49bbfb9d13936ee8bb7fee9983ca3710dc683a2e] | committer: Paul B Mahol

avfilter: add arbitrary audio FIR filter

Signed-off-by: Paul B Mahol 


http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=49bbfb9d13936ee8bb7fee9983ca3710dc683a2e

---

 configure  |   3 +
 doc/filters.texi   |  43 
 libavfilter/Makefile   |   1 +
 libavfilter/af_afir.c  | 535 +
 libavfilter/af_afir.h  |  83 +++
 libavfilter/allfilters.c   |   1 +
 libavfilter/version.h  |   2 +-
 libavfilter/x86/Makefile   |   2 +
 libavfilter/x86/af_afir.asm|  60 +
 libavfilter/x86/af_afir_init.c |  35 +++
 10 files changed, 764 insertions(+), 1 deletion(-)

 [...]


segfault with this filtergraph

aevalsrc= 'if(n, 0, 1)',
firequalizer=
delay   = 0.023:
fixed   = off:
wfunc   = nuttall:
gain= 'if(between(f, 1000, 5000), -INF, 0)',
atrim = end_sample = 2048 [ir];

aevalsrc='0.5*sin(3000*t*t)':d=10.3 [data];

[data][ir]
afir


Not really related to this report, but in general it would be nice to 
have some fate tests for the afir filter.


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add arbitrary audio FIR filter

[Muhammad Faiz]

On Wed, May 10, 2017 at 1:55 AM, Paul B Mahol  wrote:
> ffmpeg | branch: master | Paul B Mahol  | Thu Jan 26 
> 17:03:08 2017 +0100| [49bbfb9d13936ee8bb7fee9983ca3710dc683a2e] | committer: 
> Paul B Mahol
>
> avfilter: add arbitrary audio FIR filter
>
> Signed-off-by: Paul B Mahol 
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=49bbfb9d13936ee8bb7fee9983ca3710dc683a2e
> ---
>
>  configure  |   3 +
>  doc/filters.texi   |  43 
>  libavfilter/Makefile   |   1 +
>  libavfilter/af_afir.c  | 535 
> +
>  libavfilter/af_afir.h  |  83 +++
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/version.h  |   2 +-
>  libavfilter/x86/Makefile   |   2 +
>  libavfilter/x86/af_afir.asm|  60 +
>  libavfilter/x86/af_afir_init.c |  35 +++
>  10 files changed, 764 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index e797567780..5ae5227868 100755
> --- a/configure
> +++ b/configure
> @@ -3083,6 +3083,8 @@ unix_protocol_select="network"
>  # filters
>  afftfilt_filter_deps="avcodec"
>  afftfilt_filter_select="fft"
> +afir_filter_deps="avcodec"
> +afir_filter_select="fft"
>  amovie_filter_deps="avcodec avformat"
>  aresample_filter_deps="swresample"
>  ass_filter_deps="libass"
> @@ -6476,6 +6478,7 @@ enabled zlib && add_cppflags -DZLIB_CONST
>
>  # conditional library dependencies, in linking order
>  enabled afftfilt_filter && prepend avfilter_deps "avcodec"
> +enabled afir_filter && prepend avfilter_deps "avcodec"
>  enabled amovie_filter   && prepend avfilter_deps "avformat avcodec"
>  enabled aresample_filter&& prepend avfilter_deps "swresample"
>  enabled atempo_filter   && prepend avfilter_deps "avcodec"
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 3739fbcc04..c54f5f2dcd 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -878,6 +878,49 @@ afftfilt="1-clip((b/nb)*b,0,1)"
>  @end example
>  @end itemize
>
> +@section afir
> +
> +Apply an arbitrary Frequency Impulse Response filter.
> +
> +This filter is designed for applying long FIR filters,
> +up to 30 seconds long.
> +
> +It can be used as component for digital crossover filters,
> +room equalization, cross talk cancellation, wavefield synthesis,
> +auralization, ambiophonics and ambisonics.
> +
> +This filter uses second stream as FIR coefficients.
> +If second stream holds single channel, it will be used
> +for all input channels in first stream, otherwise
> +number of channels in second stream must be same as
> +number of channels in first stream.
> +
> +It accepts the following parameters:
> +
> +@table @option
> +@item dry
> +Set dry gain. This sets input gain.
> +
> +@item wet
> +Set wet gain. This sets final output gain.
> +
> +@item length
> +Set Impulse Response filter length. Default is 1, which means whole IR is 
> processed.
> +
> +@item again
> +Enable applying gain measured from power of IR.
> +@end table
> +
> +@subsection Examples
> +
> +@itemize
> +@item
> +Apply reverb to stream using mono IR file as second input, complete command 
> using ffmpeg:
> +@example
> +ffmpeg -i input.wav -i middle_tunnel_1way_mono.wav -lavfi afir output.wav
> +@end example
> +@end itemize
> +
>  @anchor{aformat}
>  @section aformat
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 0f990866e8..de5f992795 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -37,6 +37,7 @@ OBJS-$(CONFIG_AEMPHASIS_FILTER)  += 
> af_aemphasis.o
>  OBJS-$(CONFIG_AEVAL_FILTER)  += aeval.o
>  OBJS-$(CONFIG_AFADE_FILTER)  += af_afade.o
>  OBJS-$(CONFIG_AFFTFILT_FILTER)   += af_afftfilt.o window_func.o
> +OBJS-$(CONFIG_AFIR_FILTER)   += af_afir.o
>  OBJS-$(CONFIG_AFORMAT_FILTER)+= af_aformat.o
>  OBJS-$(CONFIG_AGATE_FILTER)  += af_agate.o
>  OBJS-$(CONFIG_AINTERLEAVE_FILTER)+= f_interleave.o
> diff --git a/libavfilter/af_afir.c b/libavfilter/af_afir.c
> new file mode 100644
> index 00..d85c70710e
> --- /dev/null
> +++ b/libavfilter/af_afir.c
> @@ -0,0 +1,535 @@
> +/*
> + * Copyright (c) 2017 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; 

[FFmpeg-devel] [PATCH] nvenc:Add Fractional CQ Support

[Yogender Gupta]

CQ rate control in NVENC now supports fractional values (SDK 8.0). Please find 
patch attached for the same.

Thanks,
Yogender

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


0001-nvenc-Add-Fractional-CQ-Support.patch
Description: 0001-nvenc-Add-Fractional-CQ-Support.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel