[FFmpeg-devel] [PATCH] zscale: Fix memory leak

[Jkldjfset]

Empty Message

0001-avfilter-zscale-fix-memory-leak.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_ssim: fix temp size calculation

[Muhammad Faiz]

On Sat, Aug 5, 2017 at 2:48 PM, Paul B Mahol  wrote:
> On 8/4/17, Muhammad Faiz  wrote:
>> On Thu, Aug 3, 2017 at 1:53 PM, Tobias Rapp  wrote:
>>> On 03.08.2017 03:03, Muhammad Faiz wrote:

 Also use av_mallocz_array.
 Fix Ticket6519.

 Signed-off-by: Muhammad Faiz 
 ---
  libavfilter/vf_ssim.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

 diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
 index c3c204268f..d8c049177c 100644
 --- a/libavfilter/vf_ssim.c
 +++ b/libavfilter/vf_ssim.c
 @@ -219,6 +219,8 @@ static float ssim_endn_8bit(const int (*sum0)[4],
 const int (*sum1)[4], int widt
  return ssim;
  }

 +#define SUM_LEN(w) (((w) >> 2) + 3)
 +
  static float ssim_plane_16bit(SSIMDSPContext *dsp,
uint8_t *main, int main_stride,
uint8_t *ref, int ref_stride,
 @@ -228,7 +230,7 @@ static float ssim_plane_16bit(SSIMDSPContext *dsp,
  int z = 0, y;
  float ssim = 0.0;
  int64_t (*sum0)[4] = temp;
 -int64_t (*sum1)[4] = sum0 + (width >> 2) + 3;
 +int64_t (*sum1)[4] = sum0 + SUM_LEN(width);

  width >>= 2;
  height >>= 2;
 @@ -256,7 +258,7 @@ static float ssim_plane(SSIMDSPContext *dsp,
  int z = 0, y;
  float ssim = 0.0;
  int (*sum0)[4] = temp;
 -int (*sum1)[4] = sum0 + (width >> 2) + 3;
 +int (*sum1)[4] = sum0 + SUM_LEN(width);

  width >>= 2;
  height >>= 2;
 @@ -402,7 +404,7 @@ static int config_input_ref(AVFilterLink *inlink)
  for (i = 0; i < s->nb_components; i++)
  s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] /
 sum;

 -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) *
 (1
 + (desc->comp[0].depth > 8)));
 +s->temp = av_mallocz_array(2 * SUM_LEN(inlink->w),
 (desc->comp[0].depth > 8) ? sizeof(int64_t[4]) : sizeof(int[4]));
  if (!s->temp)
  return AVERROR(ENOMEM);
  s->max = (1 << desc->comp[0].depth) - 1;

>>>
>>> Fixes the crashing command and runs without reports in Valgrind.
>>
>> Applied.
>
> What about closing #6519?

Closed.

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

[FFmpeg-devel] [PATCH] avcodec/dirac_dwt: Fixes integer overflows in COMPOSE_DAUB97*

[Michael Niedermayer]

Fix multiple: runtime error: signed integer overflow: 6497 * 3409630 cannot be 
represented in type 'int'
Fixes: 2819/clusterfuzz-testcase-minimized-4743700301217792

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

diff --git a/libavcodec/dirac_dwt.h b/libavcodec/dirac_dwt.h
index 62f8472b41..e715e53bc4 100644
--- a/libavcodec/dirac_dwt.h
+++ b/libavcodec/dirac_dwt.h
@@ -117,16 +117,16 @@ void ff_spatial_idwt_slice2(DWTContext *d, int y);
 (b4 + ((-2*(b0+b8) + 10*(b1+b7) - 25*(b2+b6) + 81*(b3+b5) + 128) >> 8))
 
 #define COMPOSE_DAUB97iL1(b0, b1, b2)\
-(b1 - ((1817*(b0 + b2) + 2048) >> 12))
+(b1 - ((int)(1817U*(b0 + b2) + 2048) >> 12))
 
 #define COMPOSE_DAUB97iH1(b0, b1, b2)\
-(b1 - (( 113*(b0 + b2) + 64) >> 7))
+(b1 - ((int)( 113U*(b0 + b2) + 64) >> 7))
 
 #define COMPOSE_DAUB97iL0(b0, b1, b2)\
-(b1 + (( 217*(b0 + b2) + 2048) >> 12))
+(b1 + ((int)( 217U*(b0 + b2) + 2048) >> 12))
 
 #define COMPOSE_DAUB97iH0(b0, b1, b2)\
-(b1 + ((6497*(b0 + b2) + 2048) >> 12))
+(b1 + ((int)(6497U*(b0 + b2) + 2048) >> 12))
 
 
 #endif /* AVCODEC_DWT_H */
-- 
2.13.0

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

Re: [FFmpeg-devel] [PATCH] avutil/frame: allow only one element per type in frame side data

[James Almer]

On 7/29/2017 1:12 AM, James Almer wrote:
> On 7/25/2017 9:10 PM, James Almer wrote:
>> Same rationale as with packet side data, it was never meant to do otherwise
>> as av_frame_get_side_data returns the first entry it finds of a given type.
>>
>> Based on code from libavformat's av_stream_add_side_data().
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavutil/frame.c | 14 ++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/libavutil/frame.c b/libavutil/frame.c
>> index 24d5d5f184..c41d4be8cc 100644
>> --- a/libavutil/frame.c
>> +++ b/libavutil/frame.c
>> @@ -638,10 +638,24 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
>> *frame,
>>  AVBufferRef *buf)
>>  {
>>  AVFrameSideData *ret, **tmp;
>> +int i;
>>  
>>  if (!buf)
>>  return NULL;
>>  
>> +for (i = 0; i < frame->nb_side_data; i++) {
>> +AVFrameSideData *sd = frame->side_data[i];
>> +
>> +if (sd->type == type) {
>> +av_buffer_unref(>buf);
>> +av_dict_free(>metadata);
>> +sd->buf  = buf;
>> +sd->data = sd->buf->data;
>> +sd->size = buf->size;
>> +return sd;
>> +}
>> +}
>> +
>>  if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
>>  goto fail;
> 
> Ping.
> 

I'll apply this soon unless someone objects.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mov: prevent duplication of first fragment's ctts_data

[Daniel Glöckner]

MP4 files with fragments might have the first moof box that is mentioned
in a fragment index before the first mdat box. Since it is then already
parsed by mov_read_header, we have to make sure that mov_switch_root
will not parse it again when seeking by setting the headers_read flag in
the index. Parsing it a second time would cause the ctts_data array to
receive a second copy of the information from the trun box, leading to
wrong PTS values for the second and following fragments in presence of
B-frames.

Fixes ticket 6560.

Signed-off-by: Daniel Glöckner 
---
 libavformat/mov.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 63f84be..c2da1b6 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6345,6 +6345,13 @@ static int mov_read_header(AVFormatContext *s)
 }
 ff_configure_buffers_for_index(s, AV_TIME_BASE);
 
+for (i = 0; i < mov->fragment_index_count; i++) {
+MOVFragmentIndex *idx = mov->fragment_index_data[i];
+for (j = 0; j < idx->item_count; j++)
+if (idx->items[j].moof_offset <= mov->fragment.moof_offset)
+idx->items[j].headers_read = 1;
+}
+
 return 0;
 }
 
-- 
2.7.0

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

Re: [FFmpeg-devel] libavcodec/exr : add SSE2 simd for reorder pixels (WIP)

[Ivan Kalvachev]

On 8/5/17, Martin Vignali  wrote:
> Hello,
>
> Based on pull request in the official openexr library :
> https://github.com/openexr/openexr/pull/229/commits/4198128397c033d4f69e5cc0833195da500c31cf
>
> i try to port the reorder part (used in zip and rle decompression), to asm
> Tested on OS X
> pass fate test for me
>
> I test with this command :
> ./ffmpeg -i ./fate-suite/exr/rgba_slice_zip16.exr -f null -;./ffmpeg -i
> ./fate-suite/exr/rgba_slice_zip16.exr -f null - -cpuflags 0
>
> the result of the timer are :
> scalar : 960355 decicycles in reorder_pixels_zip,  64 runs,  0
> skips
> sse :   84763 decicycles in reorder_pixels_zip,  64 runs,  0
> skips
>
> Comments Welcome
>
> Martin
> Jokyo Images

64 runs seems way too few runs for reliable result.
Please try to run ffmpeg encoding for about a minute.

About the patch:

> +%include "libavutil/x86/x86util.asm"
> +
> +SECTION .text

Please include "x86inc.asm" explicitly.

> +INIT_XMM sse2
> +cglobal reorder_pixels, 3,5,3, src, dst, size
> +
> +shrr2,1;half_size

It's better to use the labels you define in the cglobal,
If I count correctly, "r2" would be "sizeq".
("srcq" and "dstq" would be the correct labels for the pointers).


> +;calc loop count for simd reorder
> +movr3,r2;
> +shrr3,4;calc loop count simd

Align the instruction at 4 spaces.
Align the first operands so that the ending commas are vertically aligned.
For the follow up operands, just add one space after the comma.

Put some spaces before the comment, to separate it from the operands.
BTW, this is not C, you don't need to end every line with ";"
e.g.
> +mov  r3, r2
> +shr  r3, 4  ;calc loop count simd


> +;jump to afterloop2 if loop count simd is 0
> +cmpr3,0;
> +jleafterloop2;

If you only check for size==0, then
the "shr" has already set the correct Z flag.

However, if r3/size==1, you'd still read
16 bytes at once in the first loop.
Aka, overread.


> +;simd loop
> +loop1:
> +movdqaxmm0,[r0];load first 16 bytes

Use "m0" instead.


> +lea r4, [r0 + r2];
> +
> +movdquxmm1, [r4]; unaligned load

r4 doesn't seem to be used for anything else.
Just move the address calculation directly into
the "movdqu", it can take it.

> +movdqa xmm2,xmm0;copy xmm0
> +
> +punpcklbw xmm2,   xmm1;
> +movdqa [r1],   xmm2;
> +add r1, 16;

use "mmsize" instead of 16.

> +movdqa xmm2,   xmm0;
> +punpckhbw xmm2,   xmm1;
> +movdqa[r1],   xmm2;
> +addr1,16;

You can actually avoid one of the "add"
if you use [r1+mmsize] and add 32 at the second
"add" (or 2*mmsize).

> +decr3;
> +addr0,16;

> +; test repeat
> +cmpr3,   0;
> +jgeloop1;

First, "dec" instructions are avoided,
because they do a partial update
on the flag register and
this causes interdependence.

Second, you can use the flags from
the "sub" to check if it has reached
zero or has gone negative.


> +afterloop2:
> +;scalar part
> +
> +mov r3, r2;
> +and r3, 15 ;half_size % 16
> +lea r4, [r0 + r2];
> +
> +;initial condition loop
> +cmpr3,0;
> +jleend;
> +
> +loop2:
> +mov r1, r0;
> +inc r1;
> +mov r1, r4;
> +inc r1;
> +inc r0;
> +inc r4;
> +dec r3;
> +; test repeat
> +cmpr3,   0;
> +jgloop2;

O_o
This loop does not read or write to memory.

You can replace the second "cmp" in this
loop with unconditional jump to the
"initial condition loop" compare.
(aka move loop2: two instruction above).

This is how "for(;;)" is usually implemented in C compilers.

Be sure to test your function with different sizes,
to salt your output buffers and check for underwrites, overwrites
etc...

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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[James Almer]

On 8/5/2017 6:17 PM, Nicolas George wrote:
> L'octidi 18 thermidor, an CCXXV, James Almer a écrit :
>> Indeed, but that's something that should have been done once AVOptions
>> gained the shorthand feature with the CLI, not several years down the
>> line and hundreds of scripts and tutorials potentially considering it a
>> fixed syntax.
>>
>> At this point, breaking current shorthand behavior is pretty disruptive,
>> at least without some warnings and removal grace period.
>> My suggestion would be to keep dummy options in a similar fashion we
>> keep deprecated functions, so the shorthand notation does not start
>> trying to fill values of unexpected new or moved options. Making them
>> raise a warning about how it will stop working in the near future (No
>> need for two years like with API, one or two releases should be enough)
>> and maybe mention the new option that will be filled by the shorthand
>> notation.
> 
> That would be ideal, if we had unlimited manpower. Unfortunately, we do
> not.

What do you mean? What i suggested would be done each time an option is
removed or added anywhere but at the end, both of which afaik are
uncommon cases.
It's not something that requires a rewrite of the current codebase.

> 
>> Is there for that matter a way to achieve this for the CLI only and not
>> keeping the dummy options for library users?
> 
> Not easily, I think.
> 
> Regards,
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_slice: Fix overflow in slice offset

[Michael Niedermayer]

On Fri, Aug 04, 2017 at 04:05:24AM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: signed integer overflow: 1610612736 * 2 cannot be 
> represented in type 'int'
> Fixes: 2817/clusterfuzz-testcase-minimized-5289691240726528
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264_slice.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)

patchset applied

[...]
-- 
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] doc/filters: document the unstability of the shorthand options notation.

[Nicolas George]

L'octidi 18 thermidor, an CCXXV, James Almer a écrit :
> Indeed, but that's something that should have been done once AVOptions
> gained the shorthand feature with the CLI, not several years down the
> line and hundreds of scripts and tutorials potentially considering it a
> fixed syntax.
> 
> At this point, breaking current shorthand behavior is pretty disruptive,
> at least without some warnings and removal grace period.
> My suggestion would be to keep dummy options in a similar fashion we
> keep deprecated functions, so the shorthand notation does not start
> trying to fill values of unexpected new or moved options. Making them
> raise a warning about how it will stop working in the near future (No
> need for two years like with API, one or two releases should be enough)
> and maybe mention the new option that will be filled by the shorthand
> notation.

That would be ideal, if we had unlimited manpower. Unfortunately, we do
not.

> Is there for that matter a way to achieve this for the CLI only and not
> keeping the dummy options for library users?

Not easily, I think.

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] avformat/utils: fix memory leak in avformat_free_context

[Michael Niedermayer]

On Thu, Aug 03, 2017 at 09:29:37AM -0700, Steven Siloti wrote:
> On Mon, Jul 31, 2017 at 11:08 AM, Steven Siloti 
> wrote:
> 
> > The pointer to the packet queue is stored in the internal structure
> > so the queue needs to be flushed before internal is freed.
> >
> > Signed-off-by: Steven Siloti 
> > ---
> >  libavformat/utils.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 38d247c6cd..58283616dc 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -4333,8 +4333,8 @@ void avformat_free_context(AVFormatContext *s)
> >  av_dict_free(>metadata);
> >  av_dict_free(>internal->id3v2_meta);
> >  av_freep(>streams);
> > -av_freep(>internal);
> >  flush_packet_queue(s);
> > +av_freep(>internal);
> >  av_free(s);
> >  }
> >
> > --
> > 2.13.0.windows.1
> >
> > Is there something wrong with this patch? It seems like a straightforward
> fix to me. Perhaps you would prefer it as an attachment. If so, attached.

>  utils.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> dcd295b47267244aa767fa9cace848bde36e1043  
> 0001-avformat-utils-fix-memory-leak-in-avformat_free_cont.patch
> From 5ec9a446fdc5874d859f3a9d92a0b5d9f82583aa Mon Sep 17 00:00:00 2001
> From: Steven Siloti 
> Date: Tue, 18 Jul 2017 11:26:39 -0700
> Subject: [PATCH] avformat/utils: fix memory leak in avformat_free_context
> 
> The pointer to the packet queue is stored in the internal structure
> so the queue needs to be flushed before internal is freed.
> 
> Signed-off-by: Steven Siloti 
> ---
>  libavformat/utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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] swscale: fix gbrap16 alpha channel issues

[Michael Niedermayer]

On Thu, Aug 03, 2017 at 04:21:54PM +0100, James Cowgill wrote:
> Fixes filter-pixfmts-scale test failing on big-endian systems due to
> alpSrc not being cast to (const int32_t**).
> 
> Also fixes distortions in the output alpha channel values by copying the
> alpha channel code from the rgba64 case found elsewhere in output.c.
> 
> Fixes ticket 6555.
> 
> Signed-off-by: James Cowgill 
> ---
>  v2
>  
>  Move declaration of A inside the loop and don't bother initializing it since
>  the initial value would never be read.

applied

thanks

[...]
-- 
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

[FFmpeg-devel] libavcodec/exr : add SSE2 simd for reorder pixels (WIP)

[Martin Vignali]

Hello,

Based on pull request in the official openexr library :
https://github.com/openexr/openexr/pull/229/commits/4198128397c033d4f69e5cc0833195da500c31cf

i try to port the reorder part (used in zip and rle decompression), to asm
Tested on OS X
pass fate test for me

I test with this command :
./ffmpeg -i ./fate-suite/exr/rgba_slice_zip16.exr -f null -;./ffmpeg -i
./fate-suite/exr/rgba_slice_zip16.exr -f null - -cpuflags 0

the result of the timer are :
scalar : 960355 decicycles in reorder_pixels_zip,  64 runs,  0 skips
sse :   84763 decicycles in reorder_pixels_zip,  64 runs,  0
skips

Comments Welcome

Martin
Jokyo Images


0001-libavcodec-exr-add-sse2-simd-for-reorder_pixels.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Implement NewTek NDI support

[Marton Balint]

On Thu, 3 Aug 2017, Maksym Veremeyenko wrote:


On 30.07.2017 17:19, Marton Balint wrote:
[...]

Subject: [PATCH] lavd: implement NewTek NDI muxer/demuxer support


Hi,

About the warnings for the bottom field order and the negative linesize, I 
still think it is better to reject them (return an error), this way the 
user will be forced to fix the input, by changing the field order (e.g by 
using the fieldorder filter before passing video) or getting rid of the 
negative linesize.


To support negative linesizes, there is one more thing you might do: If the
source frame has a negative linesize, then instead of cloning, allocate a new
avframe with av_frame_alloc, set widht/height/format, use av_frame_get_buffer
to allocate a buffer, then use av_frame_copy to copy the data from the source
frame to the newly allocated one which should have a positive linesize.
A bit too much work for a rarely used feature, but if you are interested, it is
doable. You can generate a negative linesize source with the vflip filter.

I did some further tests, and I still cannot see my own ffmpeg generated
source, I am running this command:

./ffmpeg -nostdin -f libndi_newtek -wait_sources 10 -find_sources 1 -i none & 
./ffmpeg -f lavfi -i mptestsrc,format=pix_fmts=uyvy422 -f libndi_newtek dummy

Even after 10 seconds, the first process finds 0 sources, the second process is
running happily. Does this work for you?

I also have some additional comments for the patch:

[..]


+@subsection Examples
+
+@itemize
+
+@item
+Play video clip:
+@example
+ffmpeg -i "udp://@239.1.1.1:10480?fifo_size=100_nonfatal=1" -vf 
"scale=720:576,fps=fps=25,setdar=dar=16/9,format=pix_fmts=uyvy422" -f libndi_newtek NEW_NDI1


@ needs escaping into @@

[..]


+while (1)
+{
+int f, t = ctx->wait_sources / 1000;
+av_log(avctx, AV_LOG_DEBUG, "Waiting for sources %d miliseconds\n", t);
+f = NDIlib_find_wait_for_sources(ctx->ndi_find, t);
+av_log(avctx, AV_LOG_DEBUG, "NDIlib_find_wait_for_sources returns 
%d\n", f);
+if (!f)
+break;
+};


You should not loop indefinitely, give up after a few tries.

[..]


+static int ndi_write_video_packet(AVFormatContext *avctx, AVStream *st, 
AVPacket *pkt)
+{
+struct NDIContext *ctx = avctx->priv_data;
+AVFrame *avframe, *tmp = (AVFrame *)pkt->data;
+
+if (tmp->format != AV_PIX_FMT_UYVY422 ||
+tmp->width  != ctx->video->xres ||
+tmp->height != ctx->video->yres) {
+av_log(avctx, AV_LOG_ERROR, "Got a frame with invalid pixel format or 
dimension.\n");
+av_log(avctx, AV_LOG_ERROR, "tmp->width=%d, tmp->height=%d, ctx->video->xres=%d, 
ctx->video->yres=%d\n", tmp->width, tmp->height, ctx->video->xres, ctx->video->yres);
+return AVERROR(EINVAL);
+}
+avframe = av_frame_clone(tmp);
+if (!avframe) {
+av_log(avctx, AV_LOG_ERROR, "Could not clone video frame.\n");


For ENOMEM we typically don't use an error message.

[..]



+static int ndi_write_header(AVFormatContext *avctx)
+{
+int ret = 0;
+unsigned int n;
+struct NDIContext *ctx = avctx->priv_data;
+const NDIlib_send_create_t ndi_send_desc = { .p_ndi_name = avctx->filename,
+.p_groups = NULL, .clock_video = false, .clock_audio = false };


Setting both clock_video and clock_audio to false is intentional? Maybe better
to clock based on the stream types you get? (E.g. clock to video if you have a
video stream, clock to audio otherwise?)

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

[FFmpeg-devel] [PATCH] Add macros used in opus_pvq_search to x86util.asm

[Ivan Kalvachev]

Improved version of VBROADCASTSS that works like the avx2 instruction.
Emulation of vpbroadcastd.
Horizontal sum HSUMPS that places the result in all elements.
Emulation of blendvps and pblendvb.
From cf4dc8fcd974a845b91aaa8685c06fa145b01786 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Sat, 5 Aug 2017 20:18:50 +0300
Subject: [PATCH 1/6] Add macros to x86util.asm .

Improved version of VBROADCASTSS that works like the avx2 instruction.
Emulation of vpbroadcastd.
Horizontal sum HSUMPS that places the result in all elements.
Emulation of blendvps and pblendvb.

Signed-off-by: Ivan Kalvachev 
---
 libavutil/x86/x86util.asm | 108 ++
 1 file changed, 100 insertions(+), 8 deletions(-)

diff --git a/libavutil/x86/x86util.asm b/libavutil/x86/x86util.asm
index cc7d272cad..d460ee5193 100644
--- a/libavutil/x86/x86util.asm
+++ b/libavutil/x86/x86util.asm
@@ -832,14 +832,25 @@
 pmaxsd  %1, %2
 %endmacro
 
-%macro VBROADCASTSS 2 ; dst xmm/ymm, src m32
-%if cpuflag(avx)
-vbroadcastss %1, %2
-%else ; sse
-%ifnidn %1, %2
-movss%1, %2
-%endif
-shufps   %1, %1, 0
+%macro VBROADCASTSS 2 ; dst xmm/ymm, src m32/xmm
+%if cpuflag(avx2)
+vbroadcastss  %1, %2; ymm, xmm
+%elif cpuflag(avx)
+%ifnum sizeof%2 ; avx1 register
+vpermilps  xmm%1, xmm%2, q  ; xmm, xmm, imm || ymm, ymm, imm
+%if sizeof%1 >= 32  ; mmsize>=32
+vinsertf128  %1, %1, xmm%1, 1   ; ymm, ymm, xmm, im
+%endif
+%else   ; avx1 memory
+vbroadcastss  %1, %2; ymm, mm32 || xmm, m32
+%endif
+%else
+%ifnum sizeof%2 ; sse register
+shufps  %1, %2, %2, q
+%else   ; sse memory
+movss   %1, %2
+shufps  %1, %1, 0
+%endif
 %endif
 %endmacro
 
@@ -854,6 +865,21 @@
 %endif
 %endmacro
 
+%macro VPBROADCASTD 2 ; dst xmm/ymm, src m32/xmm
+%if cpuflag(avx2)
+vpbroadcastd  %1, %2
+%elif cpuflag(avx) && sizeof%1 >= 32
+%error vpbroadcastd not possible with ymm on avx1. try vbroadcastss
+%else
+%ifnum sizeof%2 ; sse2 register
+pshufd  %1, %2, q
+%else   ; sse memory
+movd%1, %2
+pshufd  %1, %1, 0
+%endif
+%endif
+%endmacro
+
 %macro SHUFFLE_MASK_W 8
 %rep 8
 %if %1>=0x80
@@ -918,3 +944,69 @@
 movhlps%1, %2; may cause an int/float domain transition and has a dependency on dst
 %endif
 %endmacro
+
+; Horizontal Sum of Packed Single precision floats
+; The resulting sum is in all elements.
+%macro HSUMPS 2 ; dst/src, tmp
+%if cpuflag(avx)
+%if sizeof%1>=32  ; avx
+vperm2f128  %2, %1, %1, (0)*16+(1)
+addps   %1, %2
+%endif
+shufps  %2, %1, %1, q1032
+addps   %1, %2
+shufps  %2, %1, %1, q0321
+addps   %1, %2
+%else  ; this form is a bit faster than the short avx-like emulation.
+movaps  %2, %1
+shufps  %1, %1, q1032
+addps   %1, %2
+movaps  %2, %1
+shufps  %1, %1, q0321
+addps   %1, %2
+; all %1 members should be equal for as long as float a+b==b+a
+%endif
+%endmacro
+
+; Emulate blendvps if not available
+;
+; src_b is destroyed when using emulation with logical operands
+; SSE41 blendv instruction is hard coded to use xmm0 as mask
+%macro BLENDVPS 3 ; dst/src_a, src_b, mask
+%if cpuflag(avx)
+blendvps  %1, %1, %2, %3
+%elif cpuflag(sse4)
+%if notcpuflag(avx)
+%ifnidn %3,xmm0
+%error sse41 blendvps uses xmm0 as default 3d operand, you used %3
+%endif
+%endif
+blendvps  %1, %2, %3
+%else
+xorps  %2, %1
+andps  %2, %3
+xorps  %1, %2
+%endif
+%endmacro
+
+; Emulate pblendvb if not available
+;
+; src_b is destroyed when using emulation with logical operands
+; SSE41 blendv instruction is hard coded to use xmm0 as mask
+%macro PBLENDVB 3 ; dst/src_a, src_b, mask
+%if cpuflag(avx)
+%if cpuflag(avx) && notcpuflag(avx2) && sizeof%1 >= 32
+%error pblendb not possible with ymm on avx1, try blendvps.
+%endif
+pblendvb  %1, %1, %2, %3
+%elif cpuflag(sse4)
+%ifnidn %3,xmm0
+%error sse41 pblendvd uses xmm0 as default 3d operand, you used %3
+%endif
+pblendvb  %1, %2, %3
+%else
+pxor  %2, %1
+pand  %2, %3
+pxor  %1, %2
+%endif
+%endmacro
-- 
2.13.2

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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[James Almer]

On 8/5/2017 2:15 PM, Nicolas George wrote:
> L'octidi 18 thermidor, an CCXXV, James Almer a écrit :
>> Users may not know that it's a shortcut to begin with.
> 
> It is exactly the reason I am proposing to document it here.

Indeed, but that's something that should have been done once AVOptions
gained the shorthand feature with the CLI, not several years down the
line and hundreds of scripts and tutorials potentially considering it a
fixed syntax.

At this point, breaking current shorthand behavior is pretty disruptive,
at least without some warnings and removal grace period.
My suggestion would be to keep dummy options in a similar fashion we
keep deprecated functions, so the shorthand notation does not start
trying to fill values of unexpected new or moved options. Making them
raise a warning about how it will stop working in the near future (No
need for two years like with API, one or two releases should be enough)
and maybe mention the new option that will be filled by the shorthand
notation.

Is there for that matter a way to achieve this for the CLI only and not
keeping the dummy options for library users?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Nicolas George]

L'octidi 18 thermidor, an CCXXV, James Almer a écrit :
> Users may not know that it's a shortcut to begin with.

It is exactly the reason I am proposing to document it here.

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] doc/filters: document the unstability of the shorthand options notation.

[James Almer]

On 8/5/2017 1:42 PM, Nicolas George wrote:
> L'octidi 18 thermidor, an CCXXV, Michael Niedermayer a écrit :
>> I think you do not realize how annoying this would be in practice
>>
>> Users do not know all these nuances that one syntax is stable and work
>> and one works but is not future proof. It also violates the priniple of
>> least surprise. Aka this fails one of the most fundamental rules of
>> user interface design
> 
> I think all competent users should realize that a shortcut is less
> stable than the full notation.

Users may not know that it's a shortcut to begin with.

> 
>> This comment makes me a bit sad.
>>
>> It implies that old code is bad without any solid fact, nothing one can
>> proof, disproof, or fix.
> 
> I am not saying that all the old code is bad. But do you want to imply
> that all of it is good? As long as some of it is bas, we need to improve
> it, and unconditional compatibility is an hindrance to that.
> 
>> And thats not even related here, you
>> didnt start by wanting to fix a mistake in the order, the changed order
>> was a side effect of other work.
> 
> Actually, the "other work" was fixing a mistake: implementing the
> options in the individual filters.
> 
>> also my suggestion was to define what is stable now and maintain that
>> properly and disallow what is not stable. Have a clear interface and
>> stick to it.
>>
>> Stable interfaces are important.
> 
> Named options are stable. There is no need for anything more.
> 
> Regards,
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

[Sasi Inguva]

To the best of my knowledge, all fate changes are benign. All of them
correspond to a size increase of 54 bytes, which is the total size of the
new atoms added.

On Sat, Aug 5, 2017 at 9:27 AM, Derek Buitenhuis  wrote:

> On 8/4/2017 9:35 PM, Sasi Inguva wrote:
> > According to https://developer.apple.com/library/content/documentation/
> QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html and ISO-IEC-14496-12 Section
> 10.1.1.1 and 10.1.1.3
> >
> > Signed-off-by: Sasi Inguva 
> > ---
> >  libavformat/movenc.c| 70 +-
> ---
> >  tests/ref/fate/adtstoasc_ticket3715 |  4 +--
> >  tests/ref/fate/copy-psp |  4 +--
> >  tests/ref/fate/movenc   | 12 +++
> >  4 files changed, 49 insertions(+), 41 deletions(-)
>
> Probably OK, if FATE changes are benign.
>
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Nicolas George]

L'octidi 18 thermidor, an CCXXV, Michael Niedermayer a écrit :
> I think you do not realize how annoying this would be in practice
> 
> Users do not know all these nuances that one syntax is stable and work
> and one works but is not future proof. It also violates the priniple of
> least surprise. Aka this fails one of the most fundamental rules of
> user interface design

I think all competent users should realize that a shortcut is less
stable than the full notation.

> This comment makes me a bit sad.
> 
> It implies that old code is bad without any solid fact, nothing one can
> proof, disproof, or fix.

I am not saying that all the old code is bad. But do you want to imply
that all of it is good? As long as some of it is bas, we need to improve
it, and unconditional compatibility is an hindrance to that.

>  And thats not even related here, you
> didnt start by wanting to fix a mistake in the order, the changed order
> was a side effect of other work.

Actually, the "other work" was fixing a mistake: implementing the
options in the individual filters.

> also my suggestion was to define what is stable now and maintain that
> properly and disallow what is not stable. Have a clear interface and
> stick to it.
> 
> Stable interfaces are important.

Named options are stable. There is no need for anything more.

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] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

[Derek Buitenhuis]

On 8/5/2017 5:27 PM, Derek Buitenhuis wrote:
> Probably OK, if FATE changes have been confirmed to be benign.

Woops, replied to the wrong patch version.

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

Re: [FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

[Derek Buitenhuis]

On 8/4/2017 9:35 PM, Sasi Inguva wrote:
> According to 
> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
>  and ISO-IEC-14496-12 Section 10.1.1.1 and 10.1.1.3
> 
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/movenc.c| 70 
> +
>  tests/ref/fate/adtstoasc_ticket3715 |  4 +--
>  tests/ref/fate/copy-psp |  4 +--
>  tests/ref/fate/movenc   | 12 +++
>  4 files changed, 49 insertions(+), 41 deletions(-)

Probably OK, if FATE changes are benign.

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

Re: [FFmpeg-devel] [PATCH] lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.

[Derek Buitenhuis]

On 8/4/2017 7:46 PM, Sasi Inguva wrote:
> According to 
> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
> 
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/movenc.c| 70 
> +
>  tests/ref/fate/adtstoasc_ticket3715 |  4 +--
>  tests/ref/fate/copy-psp |  4 +--
>  tests/ref/fate/movenc   | 12 +++
>  4 files changed, 49 insertions(+), 41 deletions(-)

Probably OK, if FATE changes have been confirmed to be benign.

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

Re: [FFmpeg-devel] [PATCH 2/8] build: treat crystalhd like other hwaccels

[Philip Langdale]

On Fri, 28 Jul 2017 11:59:13 +
Philip Langdale  wrote:

> On 2017-07-28 11:51, Clément Bœsch wrote:
> > From: Clément Bœsch 
> > 
> > ---
> >  configure | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/configure b/configure
> > index a80f9cb2eb..a2ad72f7f4 100755
> > --- a/configure
> > +++ b/configure
> > @@ -1529,7 +1529,6 @@ EXTERNAL_LIBRARY_LIST="
> >  $EXTERNAL_LIBRARY_VERSION3_LIST
> >  $EXTERNAL_LIBRARY_GPLV3_LIST
> >  chromaprint
> > -crystalhd
> >  gcrypt
> >  gnutls
> >  jni
> > @@ -1586,6 +1585,7 @@ EXTERNAL_LIBRARY_LIST="
> >  "
> >  HWACCEL_AUTODETECT_LIBRARY_LIST="
> >  audiotoolbox
> > +crystalhd
> >  cuda
> >  cuvid
> >  d3d11va
> > @@ -3588,7 +3588,7 @@ done
> >  enable_weak audiotoolbox
> > 
> >  # Enable hwaccels by default.
> > -enable_weak d3d11va dxva2 vaapi vda vdpau videotoolbox_hwaccel xvmc
> > +enable_weak crystalhd d3d11va dxva2 vaapi vda vdpau 
> > videotoolbox_hwaccel xvmc
> >  enable_weak xlib
> > 
> >  enable_weak cuda cuvid nvenc vda_framework videotoolbox 
> > videotoolbox_encoder
> > @@ -5797,7 +5797,6 @@ enabled bzlib && check_lib bzlib bzlib.h
> > BZ2_bzlibVersion-lbz2
> >  enabled  lzma && check_lib lzma   lzma.h lzma_version_number -llzma
> > 
> >  check_lib libm math.h sin -lm && LIBM="-lm"
> > -disabled crystalhd || check_lib crystalhd "stdint.h
> > libcrystalhd/libcrystalhd_if.h" DtsCrystalHDVersion -lcrystalhd
> > 
> >  atan2f_args=2
> >  copysign_args=2
> > @@ -6157,6 +6156,8 @@ enabled vdpau &&
> >  enabled vdpau &&
> >  check_lib vdpau_x11 "vdpau/vdpau.h vdpau/vdpau_x11.h"
> > vdp_device_create_x11 -lvdpau -lX11
> > 
> > +enabled crystalhd && check_lib crystalhd "stdint.h
> > libcrystalhd/libcrystalhd_if.h" DtsCrystalHDVersion -lcrystalhd
> > +
> >  if enabled x86; then
> >  case $target_os in
> >  mingw32*|mingw64*|win32|win64|linux|cygwin*)  
> 
> Looks fine to me.

You asked me to actually check it with the hardware, so I did and it's
working correctly.

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

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Michael Niedermayer]

On Sat, Aug 05, 2017 at 03:42:08PM +0200, Nicolas George wrote:
> L'octidi 18 thermidor, an CCXXV, Michael Niedermayer a écrit :
> > This is ambigous and if interpreted litterally
> > then even a scale=320:240 would no longer be guranteed to work
> > but would require scale=width=320:height=240 to be used.
> 
> That is intentional. Note that w=320:h=240 is enough: four characters
> more.

I think you do not realize how annoying this would be in practice

Users do not know all these nuances that one syntax is stable and work
and one works but is not future proof. It also violates the priniple of
least surprise. Aka this fails one of the most fundamental rules of
user interface design


> 
> > the shorthand is widely used and convenient
> 
> It is convenient, but not absolutely necessary. Once in a script, the
> extra function names make it more readable and more robust anyway.
> 
> > That way anything that works will contine to work and one cannot
> > mistakly write a script that uses unstable shorthand options
> 

> Remember that "anything that works will continue to work" is opposed to
> "we can add new features without being burdened by past mistakes".

This comment makes me a bit sad.

It implies that old code is bad without any solid fact, nothing one can
proof, disproof, or fix. And thats not even related here, you
didnt start by wanting to fix a mistake in the order, the changed order
was a side effect of other work.

also my suggestion was to define what is stable now and maintain that
properly and disallow what is not stable. Have a clear interface and
stick to it.

Stable interfaces are important.

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [PATCH]v6 Opus Pyramid Vector Quantization Search in x86 SIMD asm

[Ivan Kalvachev]

On 8/5/17, Hendrik Leppkes  wrote:
> On Sat, Aug 5, 2017 at 12:21 PM, Ivan Kalvachev 
> wrote:
>> On 8/5/17, Rostislav Pehlivanov  wrote:
>>> On 4 August 2017 at 23:58, Ivan Kalvachev  wrote:
>>>

 >> I had it mixed before, but I changed it to be consistent.
 >> Some new avx instruction are not overloaded or
 >> available without their "v-" prefix.
 >> e.g. x86util uses vpbroadcastw in SPLATW.
 >
 > Every instruction that has both a legacy encoding and a VEX-encoding
 > will be automatically converted to VEX in AVX functions when written
 > without the v-prefix. There is no legacy encoding for newer
 > instructions so there's no reason for x86inc to overload those.

 That's great, but it doesn't address the original problem.
 Do you insist on removing the "v-" prefix from AVX only instructions?


>>> I insist.
>>
>> If you insist, then you should have a good technical reason for it.
>> Something that is not based on looks, cosmetics or "it has always been
>> like this".
>>
>> For example, slow compilation because of unnecessary macro expansion is
>> a technical reason to keep the "v-" prefix.
>>
>
> Consistency with the typical style of our codebase is also a reason.

No, it is not. This fall in category of doing things wrong,
because we have always done them wrong.
Also you brought up the matter of compilation speed,
now you don't care about it? ;)

Don't worry, I will do the requested change,
only because in future it might help with
avx1 & ymm integer test.

Please answer my other question(s).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Nicolas George]

L'octidi 18 thermidor, an CCXXV, Michael Niedermayer a écrit :
> This is ambigous and if interpreted litterally
> then even a scale=320:240 would no longer be guranteed to work
> but would require scale=width=320:height=240 to be used.

That is intentional. Note that w=320:h=240 is enough: four characters
more.

> the shorthand is widely used and convenient

It is convenient, but not absolutely necessary. Once in a script, the
extra function names make it more readable and more robust anyway.

> That way anything that works will contine to work and one cannot
> mistakly write a script that uses unstable shorthand options

Remember that "anything that works will continue to work" is opposed to
"we can add new features without being burdened by past mistakes".

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] doc/filters: document the unstability of the shorthand options notation.

[Michael Niedermayer]

On Sat, Aug 05, 2017 at 11:42:06AM +0200, Nicolas George wrote:
> Signed-off-by: Nicolas George 
> ---
>  doc/filters.texi | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 7e5a9a625a..886cd5a7e8 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -161,6 +161,11 @@ follow the same constraints order of the previous point. 
> The following
>  
>  @end itemize
>  
> +Future evolutions of filters may require inserting new options or changing
> +their order, especially for the non-essential options, and that would break
> +options given without their name. For that reason, uses that require
> +stability should favor the @var{key=value} notation.

This is ambigous and if interpreted litterally
then even a scale=320:240 would no longer be guranteed to work
but would require scale=width=320:height=240 to be used.

the shorthand is widely used and convenient
IMHO declaring it _all_ unstable would be a mistake

also iam thinking that we should either accept the option order we
choose when initially adding a filter and try
to maintain compatibility whenever that is possible.
Or specify exactly for each filter in the code which options are allowed
in shorthand and then also not accept options beyond that if accessed
through shorthand

That way anything that works will contine to work and one cannot
mistakly write a script that uses unstable shorthand options


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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

[FFmpeg-devel] [PATCH] add gray9 support

[Paul B Mahol]

Hi,

patches attached.


0001-libavutil-add-GRAY9-pixel-format.patch
Description: Binary data


0002-libswscale-add-gray9-support.patch
Description: Binary data


0003-avfilter-vf_extractplanes-add-9-bitdepth-support.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: fix alpha blending for planar formats with a transparent background

[Michael Niedermayer]

On Fri, Aug 04, 2017 at 10:23:55AM +0200, Marton Balint wrote:
> When the background had an alpha channel, the old code in blend_plane
> calculated premultiplied alpha from the destination plane colors instead of 
> the
> destination alpha.
> 
> Also the calculation of the output alpha should only happen after the color
> planes are already finished.
> 
> Fixes output of:
> ffplay -f lavfi "testsrc2=alpha=32[a];color=black[b];[b][a]overlay[out0]"

if it is easy, please add a fate test when / after you push this

thx

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCH]v6 Opus Pyramid Vector Quantization Search in x86 SIMD asm

[Hendrik Leppkes]

On Sat, Aug 5, 2017 at 12:21 PM, Ivan Kalvachev  wrote:
> On 8/5/17, Rostislav Pehlivanov  wrote:
>> On 4 August 2017 at 23:58, Ivan Kalvachev  wrote:
>>
>>>
>>> >> I had it mixed before, but I changed it to be consistent.
>>> >> Some new avx instruction are not overloaded or
>>> >> available without their "v-" prefix.
>>> >> e.g. x86util uses vpbroadcastw in SPLATW.
>>> >
>>> > Every instruction that has both a legacy encoding and a VEX-encoding
>>> > will be automatically converted to VEX in AVX functions when written
>>> > without the v-prefix. There is no legacy encoding for newer
>>> > instructions so there's no reason for x86inc to overload those.
>>>
>>> That's great, but it doesn't address the original problem.
>>> Do you insist on removing the "v-" prefix from AVX only instructions?
>>>
>>>
>> I insist.
>
> If you insist, then you should have a good technical reason for it.
> Something that is not based on looks, cosmetics or "it has always been
> like this".
>
> For example, slow compilation because of unnecessary macro expansion is
> a technical reason to keep the "v-" prefix.
>

Consistency with the typical style of our codebase is also a reason.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_premultiply: add inplace mode

[Paul B Mahol]

On 8/5/17, Nicolas George  wrote:
> Le septidi 17 thermidor, an CCXXV, Paul B Mahol a écrit :
>> From f952d9a2c87f7c2387d509e986aee5adb424d9d2 Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol 
>> Date: Fri, 4 Aug 2017 22:28:53 +0200
>> Subject: [PATCH] avfilter/vf_premultiply: add inplace mode
>>
>> ---
>>  libavfilter/vf_premultiply.c | 195
>> +++
>>  1 file changed, 142 insertions(+), 53 deletions(-)
>
> But what does it do? How does it benefit the user?

I posted this mainly for comments on activate usage.

Basically with activated option it do not need two inputs but just
one, so now I need to know how to correctly use activate just to pass
what you get frames to next filter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]v6 Opus Pyramid Vector Quantization Search in x86 SIMD asm

[Ivan Kalvachev]

On 8/5/17, Rostislav Pehlivanov  wrote:
> On 4 August 2017 at 23:58, Ivan Kalvachev  wrote:
>
>>
>> >> I had it mixed before, but I changed it to be consistent.
>> >> Some new avx instruction are not overloaded or
>> >> available without their "v-" prefix.
>> >> e.g. x86util uses vpbroadcastw in SPLATW.
>> >
>> > Every instruction that has both a legacy encoding and a VEX-encoding
>> > will be automatically converted to VEX in AVX functions when written
>> > without the v-prefix. There is no legacy encoding for newer
>> > instructions so there's no reason for x86inc to overload those.
>>
>> That's great, but it doesn't address the original problem.
>> Do you insist on removing the "v-" prefix from AVX only instructions?
>>
>>
> I insist.

If you insist, then you should have a good technical reason for it.
Something that is not based on looks, cosmetics or "it has always been
like this".

For example, slow compilation because of unnecessary macro expansion is
a technical reason to keep the "v-" prefix.

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

[FFmpeg-devel] [PATCH v3] libaf/hlsenc: allow dynamic encryption key rotation

[DeHackEd]

Makes behaviour of 805ce25b1d2f optional, re-enables
HLS key rotation feature

Signed-off-by: DHE 
---
 doc/muxers.texi  | 7 ++-
 libavformat/hlsenc.c | 4 +++-
 2 files changed, 9 insertions(+), 2 deletions(-)

v1->v2: Actually works this time

v2->v3: Documentation fix, parameter reference was incorrect

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 94472ce..2bec5f8 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -551,7 +551,7 @@ format. The optional third line specifies the 
initialization vector (IV) as a
 hexadecimal string to be used instead of the segment sequence number (default)
 for encryption. Changes to @var{key_info_file} will result in segment
 encryption with the new key/IV and an entry in the playlist for the new key
-URI/IV.
+URI/IV if @code{hls_flags periodic_rekey} is enabled.

 Key info file format:
 @example
@@ -665,6 +665,11 @@ first segment's information.
 @item omit_endlist
 Do not append the @code{EXT-X-ENDLIST} tag at the end of the playlist.

+@item periodic_rekey
+The file specified by @code{hls_key_info_file} will be checked periodically and
+detect updates to the encryption info. Be sure to replace this file atomically,
+including the file containing the AES encryption key.
+
 @item split_by_time
 Allow segments to start on frames other than keyframes. This improves
 behavior on some players when the time between keyframes is inconsistent,
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5cf8c89..74a3249 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -85,6 +85,7 @@ typedef enum HLSFlags {
 HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment duration 
(microsec) in segment filenames when use_localtime  e.g.: %%09t
 HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size (bytes) 
in segment filenames when use_localtime  e.g.: %%014s
 HLS_TEMP_FILE = (1 << 11),
+HLS_PERIODIC_REKEY = (1 << 12),
 } HLSFlags;

 typedef enum {
@@ -1236,7 +1237,7 @@ static int hls_start(AVFormatContext *s)
   " will use -hls_key_info_file priority\n");
 }

-if (c->number <= 1) {
+if (c->number <= 1 || (c->flags & HLS_PERIODIC_REKEY)) {
 if (c->key_info_file) {
 if ((err = hls_encryption_start(s)) < 0)
 goto fail;
@@ -1804,6 +1805,7 @@ static const AVOption options[] = {
 {"second_level_segment_index", "include segment index in segment filenames 
when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_SECOND_LEVEL_SEGMENT_INDEX }, 0, UINT_MAX,   E, "flags"},
 {"second_level_segment_duration", "include segment duration in segment 
filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_SECOND_LEVEL_SEGMENT_DURATION }, 0, UINT_MAX,   E, "flags"},
 {"second_level_segment_size", "include segment size in segment filenames 
when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 = 
HLS_SECOND_LEVEL_SEGMENT_SIZE }, 0, UINT_MAX,   E, "flags"},
+{"periodic_rekey", "reload keyinfo file periodically for re-keying", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_PERIODIC_REKEY }, 0, UINT_MAX,   E, "flags"},
 {"use_localtime", "set filename expansion with strftime at segment 
creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
 {"use_localtime_mkdir", "create last directory component in 
strftime-generated filename", OFFSET(use_localtime_mkdir), AV_OPT_TYPE_BOOL, 
{.i64 = 0 }, 0, 1, E },
 {"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type), 
AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E, 
"pl_type" },
-- 
1.8.4.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_premultiply: add inplace mode

[Nicolas George]

Le septidi 17 thermidor, an CCXXV, Paul B Mahol a écrit :
> From f952d9a2c87f7c2387d509e986aee5adb424d9d2 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Fri, 4 Aug 2017 22:28:53 +0200
> Subject: [PATCH] avfilter/vf_premultiply: add inplace mode
> 
> ---
>  libavfilter/vf_premultiply.c | 195 
> +++
>  1 file changed, 142 insertions(+), 53 deletions(-)

But what does it do? How does it benefit the user?

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

[Nicolas George]

Signed-off-by: Nicolas George 
---
 doc/filters.texi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index 7e5a9a625a..886cd5a7e8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -161,6 +161,11 @@ follow the same constraints order of the previous point. 
The following
 
 @end itemize
 
+Future evolutions of filters may require inserting new options or changing
+their order, especially for the non-essential options, and that would break
+options given without their name. For that reason, uses that require
+stability should favor the @var{key=value} notation.
+
 If the option value itself is a list of items (e.g. the @code{format} filter
 takes a list of pixel formats), the items in the list are usually separated by
 @samp{|}.
-- 
2.13.2

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

Re: [FFmpeg-devel] [PATCH 07/14] lavfi/vf_overlay: use framesync2 options.

[Nicolas George]

L'octidi 18 thermidor, an CCXXV, Michael Niedermayer a écrit :
> The documentation says
> @section overlay
> [...]
> @table @option
> @item x
> @item y
> [...]
> @item eof_action
> 
> Thats the order used in the example

Yes. But it does not work like that for all the options. So basically,
you guessed that you could go to the third option, and you were lucky,
but it is not guaranteed.

> Also either way
> A user should be able to write a command line with filters from the
> documentation and know if it will be supported in the future before
> the future occurs and she finds out it stopped working.

Yes, that would be ideal. But it is not presently true. We should make
an effort to document the options that can be used in shorthand
notation.

And you are being evasive: do you consider this issue blocking?

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 07/14] lavfi/vf_overlay: use framesync2 options.

[Nicolas George]

Le septidi 17 thermidor, an CCXXV, Paul B Mahol a écrit :
> Also what about to porting one of simple filter(just filter_frame
> call) to activate API,
> i can not do it myself unless someone show me how.

Now that the new design has proved to work, rewriting
doc/filter_design.txt is near the top of my list of priorities.

But a filter that has only a filter_frame call does not benefit much
from porting to activate design. It is only when there is a queue of
frames involved or when something special is needed at EOF (which often
come together) that it matters. I have a WIP branch for rewriting
vf_fps.

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 v2] avfilter/vf_ssim: fix temp size calculation

[Paul B Mahol]

On 8/4/17, Muhammad Faiz  wrote:
> On Thu, Aug 3, 2017 at 1:53 PM, Tobias Rapp  wrote:
>> On 03.08.2017 03:03, Muhammad Faiz wrote:
>>>
>>> Also use av_mallocz_array.
>>> Fix Ticket6519.
>>>
>>> Signed-off-by: Muhammad Faiz 
>>> ---
>>>  libavfilter/vf_ssim.c | 8 +---
>>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libavfilter/vf_ssim.c b/libavfilter/vf_ssim.c
>>> index c3c204268f..d8c049177c 100644
>>> --- a/libavfilter/vf_ssim.c
>>> +++ b/libavfilter/vf_ssim.c
>>> @@ -219,6 +219,8 @@ static float ssim_endn_8bit(const int (*sum0)[4],
>>> const int (*sum1)[4], int widt
>>>  return ssim;
>>>  }
>>>
>>> +#define SUM_LEN(w) (((w) >> 2) + 3)
>>> +
>>>  static float ssim_plane_16bit(SSIMDSPContext *dsp,
>>>uint8_t *main, int main_stride,
>>>uint8_t *ref, int ref_stride,
>>> @@ -228,7 +230,7 @@ static float ssim_plane_16bit(SSIMDSPContext *dsp,
>>>  int z = 0, y;
>>>  float ssim = 0.0;
>>>  int64_t (*sum0)[4] = temp;
>>> -int64_t (*sum1)[4] = sum0 + (width >> 2) + 3;
>>> +int64_t (*sum1)[4] = sum0 + SUM_LEN(width);
>>>
>>>  width >>= 2;
>>>  height >>= 2;
>>> @@ -256,7 +258,7 @@ static float ssim_plane(SSIMDSPContext *dsp,
>>>  int z = 0, y;
>>>  float ssim = 0.0;
>>>  int (*sum0)[4] = temp;
>>> -int (*sum1)[4] = sum0 + (width >> 2) + 3;
>>> +int (*sum1)[4] = sum0 + SUM_LEN(width);
>>>
>>>  width >>= 2;
>>>  height >>= 2;
>>> @@ -402,7 +404,7 @@ static int config_input_ref(AVFilterLink *inlink)
>>>  for (i = 0; i < s->nb_components; i++)
>>>  s->coefs[i] = (double) s->planeheight[i] * s->planewidth[i] /
>>> sum;
>>>
>>> -s->temp = av_malloc_array((2 * inlink->w + 12), sizeof(*s->temp) *
>>> (1
>>> + (desc->comp[0].depth > 8)));
>>> +s->temp = av_mallocz_array(2 * SUM_LEN(inlink->w),
>>> (desc->comp[0].depth > 8) ? sizeof(int64_t[4]) : sizeof(int[4]));
>>>  if (!s->temp)
>>>  return AVERROR(ENOMEM);
>>>  s->max = (1 << desc->comp[0].depth) - 1;
>>>
>>
>> Fixes the crashing command and runs without reports in Valgrind.
>
> Applied.

What about closing #6519?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel