[FFmpeg-devel] [PATCH 1/4] opencl: Print error string when compilation fails

[Timothy Gu]

---
 libavutil/opencl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index 8686493..c2956fd 100644
--- a/libavutil/opencl.c
+++ b/libavutil/opencl.c
@@ -484,7 +484,8 @@ cl_program av_opencl_compile(const char *program_name, 
const char *build_opts)
 status = clBuildProgram(program, 1, &(opencl_ctx.device_id), build_opts, 
NULL, NULL);
 if (status != CL_SUCCESS) {
 av_log(_ctx, AV_LOG_ERROR,
-   "Compilation failed with OpenCL program: %s\n", program_name);
+   "Compilation failed with OpenCL program '%s': %s\n",
+   program_name, av_opencl_errstr(status));
 program = NULL;
 goto end;
 }
-- 
2.1.4

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

[FFmpeg-devel] [PATCH] chromakey: Use the pixel descriptor API for chroma subsampling info

[Timothy Gu]

---
 libavfilter/vf_chromakey.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/libavfilter/vf_chromakey.c b/libavfilter/vf_chromakey.c
index 47fdea631..3309748 100644
--- a/libavfilter/vf_chromakey.c
+++ b/libavfilter/vf_chromakey.c
@@ -35,6 +35,9 @@ typedef struct ChromakeyContext {
 float blend;
 
 int is_yuv;
+
+int hsub_log2;
+int vsub_log2;
 } ChromakeyContext;
 
 static uint8_t do_chromakey_pixel(ChromakeyContext *ctx, uint8_t u[9], uint8_t 
v[9])
@@ -79,24 +82,17 @@ static int do_chromakey_slice(AVFilterContext *avctx, void 
*arg, int jobnr, int
 
 ChromakeyContext *ctx = avctx->priv;
 
-int hsub_log2 = 0, vsub_log2 = 0;
 int x, y, xo, yo;
 uint8_t u[9], v[9];
 
 memset(u, ctx->chromakey_uv[0], sizeof(u));
 memset(v, ctx->chromakey_uv[1], sizeof(v));
 
-if (frame->format == AV_PIX_FMT_YUVA420P || frame->format == 
AV_PIX_FMT_YUVA422P)
-hsub_log2 = 1;
-
-if (frame->format == AV_PIX_FMT_YUVA420P)
-vsub_log2 = 1;
-
 for (y = slice_start; y < slice_end; ++y) {
 for (x = 0; x < frame->width; ++x) {
 for (yo = 0; yo < 3; ++yo) {
 for (xo = 0; xo < 3; ++xo) {
-get_pixel_uv(frame, hsub_log2, vsub_log2, x + xo - 1, y + 
yo - 1, [yo * 3 + xo], [yo * 3 + xo]);
+get_pixel_uv(frame, ctx->hsub_log2, ctx->vsub_log2, x + xo 
- 1, y + yo - 1, [yo * 3 + xo], [yo * 3 + xo]);
 }
 }
 
@@ -155,12 +151,25 @@ static av_cold int query_formats(AVFilterContext *avctx)
 return ff_set_common_formats(avctx, formats);
 }
 
+static av_cold int config_input(AVFilterLink *inlink)
+{
+AVFilterContext *avctx = inlink->dst;
+ChromakeyContext *ctx = avctx->priv;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
+
+ctx->hsub_log2 = desc->log2_chroma_w;
+ctx->vsub_log2 = desc->log2_chroma_h;
+
+return 0;
+}
+
 static const AVFilterPad chromakey_inputs[] = {
 {
 .name   = "default",
 .type   = AVMEDIA_TYPE_VIDEO,
 .needs_writable = 1,
 .filter_frame   = filter_frame,
+.config_props   = config_input,
 },
 { NULL }
 };
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH 3/3][RFC] avfilter/vf_chromakey: Add OpenCL acceleration

[Timothy Gu]

On Tue, Oct 13, 2015 at 3:28 AM Timo Rothenpieler 
wrote:

> > Hi
> >
> > I use your filter, but the kernel can't pass the compile, you should
> consider the "double" type in the kernel, some GPU card does not support
> double type
> > I add "#pragma OPENCL_EXTENSION cl_khr_fp64: enable " to the kernel, but
> it does not works
> >
> > I will check the error tomorrow
>
> I tested this filter on Nvidia on Linux, using driver 355 and on the
> Intel CPU-based OpenCL SDK so far.
> Using floats potentially has an impact on the keying quality.
>

Segfaults here with ffmpeg -f lavfi -i allrgb -vf chromakey=green:opencl=1
-f null -

gdb doesn't give anything useful:

$ gdb ffmpeg_g
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ffmpeg_g...done.
(gdb) r -loglevel debug -f lavfi -i allrgb -vf chromakey=green:opencl=1 -f
null -
Starting program: /home/timothy-gu/ffmpeg/ffmpeg/ffmpeg_g -loglevel debug
-f lavfi -i allrgb -vf chromakey=green:opencl=1 -f null -
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
ffmpeg version N-75973-g3cff255 Copyright (c) 2000-2015 the FFmpeg
developers
  built with gcc 4.9.2 (Debian 4.9.2-10)
  configuration: --enable-gpl --enable-libass --enable-libfdk-aac
--enable-libfreetype --enable-libmp3lame --enable-libopus
--enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264
--enable-nonfree --extra-ldflags='-L/opt/intel/opencl-1.2-5.0.0.57/lib64
-Wl,-rpath,/opt/intel/opencl-1.2-5.0.0.57/lib64' --enable-opencl
  libavutil  55.  3.100 / 55.  3.100
  libavcodec 57.  5.100 / 57.  5.100
  libavformat57.  3.100 / 57.  3.100
  libavdevice57.  0.100 / 57.  0.100
  libavfilter 6. 11.100 /  6. 11.100
  libswscale  4.  0.100 /  4.  0.100
  libswresample   2.  0.100 /  2.  0.100
  libpostproc54.  0.100 / 54.  0.100
Splitting the commandline.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging
level) with argument 'debug'.
Reading option '-f' ... matched as option 'f' (force format) with argument
'lavfi'.
Reading option '-i' ... matched as input file with argument 'allrgb'.
Reading option '-vf' ... matched as option 'vf' (set video filters) with
argument 'chromakey=green:opencl=1'.
Reading option '-f' ... matched as option 'f' (force format) with argument
'null'.
Reading option '-' ... matched as output file.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument debug.
Successfully parsed a group of options.
Parsing a group of options: input file allrgb.
Applying option f (force format) with argument lavfi.
Successfully parsed a group of options.
Opening an input file: allrgb.
detected 4 logical cores
[New Thread 0x7fffed3b9700 (LWP 13438)]
[New Thread 0x7fffecbb8700 (LWP 13439)]
[New Thread 0x7fffec3b7700 (LWP 13440)]
[New Thread 0x7fffebbb6700 (LWP 13441)]
[New Thread 0x7fffeb3b5700 (LWP 13442)]
[Parsed_allrgb_0 @ 0x1bb0fa0] size:4096x4096 rate:25/1 duration:-1.00
sar:1/1
[AVFilterGraph @ 0x1baff00] query_formats: 2 queried, 1 merged, 0 already
done, 0 delayed
[lavfi @ 0x1baf700] All info found
Input #0, lavfi, from 'allrgb':
  Duration: N/A, start: 0.00, bitrate: N/A
Stream #0:0, 1, 1/25: Video: rawvideo, 1 reference frame (RGB[24] /
0x18424752), rgb24, 4096x4096 [SAR 1:1 DAR 1:1], 1/25, 25 tbr, 25 tbn, 25
tbc
Successfully opened the file.
Parsing a group of options: output file -.
Applying option vf (set video filters) with argument
chromakey=green:opencl=1.
Applying option f (force format) with argument null.
Successfully parsed a group of options.
Opening an output file: -.
Successfully opened the file.
[New Thread 0x7fffe4bb2700 (LWP 13443)]
[New Thread 0x7fffe43b1700 (LWP 13444)]
[New Thread 0x7fffe3bb0700 (LWP 13445)]
[New Thread 0x7fffe33af700 (LWP 13446)]
[New Thread 0x7fffe2bae700 (LWP 13447)]
[Parsed_chromakey_0 @ 0x1bb52a0] Setting 'color' to value 'green'
[Parsed_chromakey_0 @ 0x1bb52a0] Setting 'opencl' to value '1'
[OPENCLUTILS @ 0x1510100] Could not get device ID: DEVICE NOT FOUND:
[OPENCLUTILS @ 0x1510100] Platform Name: Intel(R) Corporation, Device Name:
Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz
[New Thread 0x7fffdb6b8700 (LWP 13448)]
[New Thread 

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Carl Eugen Hoyos]

Ronald S. Bultje  gmail.com> writes:

> I think the general case, it'd be nice to figure out 
> why Carl's results are slightly different from yours

Why do you think they are different at all?
Did you look at the tables?

Carl Eugen

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

Re: [FFmpeg-devel] [PATCHv3] web/src/about: add note on portability

[Lou Logan]

On Tue, Oct 13, 2015, at 03:55 PM, Ganesh Ajjanagadde wrote:

> ping

LGTM & pushed. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat: PTS/DTS timestamps get broken in concat

[Jaroslav Snajdr]

Another attempt at trac #4924: use cat->avf->start_time to setup opened 
file structure in concatdec.c. This field always contains the correct 
timestamp.


---
 libavformat/concatdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 832b7f4..7686f28 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -314,7 +314,7 @@ static int open_file(AVFormatContext *avf, unsigned 
fileno)

 file->start_time = !fileno ? 0 :
cat->files[fileno - 1].start_time +
cat->files[fileno - 1].duration;
-file->file_start_time = (avf->start_time == AV_NOPTS_VALUE) ? 0 : 
avf->start_time;
+file->file_start_time = (cat->avf->start_time == AV_NOPTS_VALUE) ? 
0 : cat->avf->start_time;
 file->file_inpoint = (file->inpoint == AV_NOPTS_VALUE) ? 
file->file_start_time : file->inpoint;

 if ((ret = match_streams(avf)) < 0)
 return ret;
--

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

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 11:15 PM, Carl Eugen Hoyos  wrote:
> Ronald S. Bultje  gmail.com> writes:
>
>> I think the general case, it'd be nice to figure out
>> why Carl's results are slightly different from yours
>
> Why do you think they are different at all?
> Did you look at the tables?

They are different, and our conclusions are different (in a slight way).
Carl claims that the old code and new code are mostly the same in
speed, but in the cases where they differ, the old code is faster.
I claim the opposite: they are mostly the same, but in the cases where
they differ, the new code is faster.

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

[FFmpeg-devel] [PATCH 4/4] opencl: Force the use of 1.2 APIs

[Timothy Gu]

Silences warnings regarding `clCreateCommandQueue` being deprecated.

Only a very limited number of products support 2.0. Since the
replacement API (`clCreateCommandQueueWithProperties`) is only available
in 2.0, we should not update it just yet.
---
 libavutil/opencl.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavutil/opencl.h b/libavutil/opencl.h
index e423e55..168461d 100644
--- a/libavutil/opencl.h
+++ b/libavutil/opencl.h
@@ -32,6 +32,7 @@
 #ifndef LIBAVUTIL_OPENCL_H
 #define LIBAVUTIL_OPENCL_H
 
+#define CL_USE_DEPRECATED_OPENCL_1_2_APIS 1
 #ifdef __APPLE__
 #include 
 #else
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] .gitignore: some font temporaries

[Timothy Gu]

On Tue, Oct 13, 2015 at 6:24 PM Ganesh Ajjanagadde  wrote:

> On Tue, Oct 13, 2015 at 9:20 PM, Timothy Gu  wrote:
> > Patch LGTM.
>
> Go ahead and push


Pushed, thanks.

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

[FFmpeg-devel] [PATCH 2/4] opencl: Print compilation log

[Timothy Gu]

Useful when debugging.
---
 libavutil/opencl.c | 33 ++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index c2956fd..f720ce0 100644
--- a/libavutil/opencl.c
+++ b/libavutil/opencl.c
@@ -449,12 +449,14 @@ end:
 cl_program av_opencl_compile(const char *program_name, const char *build_opts)
 {
 int i;
-cl_int status;
+cl_int status, build_status;
 int kernel_code_idx = 0;
 const char *kernel_source;
 size_t kernel_code_len;
 char* ptr = NULL;
 cl_program program = NULL;
+size_t log_size;
+char *log = NULL;
 
 LOCK_OPENCL;
 for (i = 0; i < opencl_ctx.kernel_code_count; i++) {
@@ -481,11 +483,36 @@ cl_program av_opencl_compile(const char *program_name, 
const char *build_opts)
 program = NULL;
 goto end;
 }
-status = clBuildProgram(program, 1, &(opencl_ctx.device_id), build_opts, 
NULL, NULL);
+
+build_status = clBuildProgram(program, 1, &(opencl_ctx.device_id), 
build_opts, NULL, NULL);
+status = clGetProgramBuildInfo(program, opencl_ctx.device_id,
+   CL_PROGRAM_BUILD_LOG, 0, NULL, _size);
 if (status != CL_SUCCESS) {
+av_log(_ctx, AV_LOG_WARNING,
+   "Failed to get compilation log: %s\n",
+   av_opencl_errstr(status));
+} else {
+log = av_malloc(log_size);
+if (log) {
+status = clGetProgramBuildInfo(program, opencl_ctx.device_id,
+   CL_PROGRAM_BUILD_LOG, log_size,
+   log, NULL);
+if (status != CL_SUCCESS) {
+av_log(_ctx, AV_LOG_WARNING,
+   "Failed to get compilation log: %s\n",
+   av_opencl_errstr(status));
+} else {
+int level = build_status == CL_SUCCESS ? AV_LOG_DEBUG :
+ AV_LOG_ERROR;
+av_log(_ctx, level, "Compilation log:\n%s\n", log);
+}
+}
+av_freep();
+}
+if (build_status != CL_SUCCESS) {
 av_log(_ctx, AV_LOG_ERROR,
"Compilation failed with OpenCL program '%s': %s\n",
-   program_name, av_opencl_errstr(status));
+   program_name, av_opencl_errstr(build_status));
 program = NULL;
 goto end;
 }
-- 
2.1.4

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

[FFmpeg-devel] [PATCH 3/4] opencl: Use "opencl" as log context name

[Timothy Gu]

All other classes use lowercase names.
---
 libavutil/opencl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index f720ce0..62706f3 100644
--- a/libavutil/opencl.c
+++ b/libavutil/opencl.c
@@ -84,7 +84,7 @@ static const AVOption opencl_options[] = {
 };
 
 static const AVClass openclutils_class = {
-.class_name= "OPENCLUTILS",
+.class_name= "opencl",
 .option= opencl_options,
 .item_name = av_default_item_name,
 .version   = LIBAVUTIL_VERSION_INT,
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: fix frame management

[Muhammad Faiz]

On Tue, Oct 13, 2015 at 1:31 PM, Clément Bœsch  wrote:
>
> Did you test if you get the same results with and without the perms
> filter?
>

it gives mostly same result (e.g in common usage with ffplay)
it gives more correct result when  you still need frame reference like this
code

// buffersink is connected to showcqt filter
int i
AVFrame *frame[32];
for (i = 0; i < 32; i++) {
frame[i] = av_frame_alloc();
av_buffersink_get_frame_flags(buffersink, frame[i], 0);
}

the old code will gives incorrect result (frame[0] to frame[30] will be
clobbered by frame[31] because they reference to the same buffers

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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: fix frame management

[Clément Bœsch]

On Tue, Oct 13, 2015 at 12:18:58PM +0700, Muhammad Faiz wrote:
> 

> From 893d4068adb9d3d2c118186bdc5645056f0ef172 Mon Sep 17 00:00:00 2001
> From: Muhammad Faiz 
> Date: Tue, 13 Oct 2015 12:06:37 +0700
> Subject: [PATCH] avfilter/avf_showcqt: fix frame management
> 
> follow frame writability rule
> reuse buffer
> ---
>  libavfilter/avf_showcqt.c | 61 
> +++

Did you test if you get the same results with and without the perms
filter?

[...]

-- 
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] Survey for the community

[Thilo Borgmann]

Am 12.10.15 um 21:10 schrieb Clément Bœsch:
> On Fri, Oct 09, 2015 at 06:13:05PM +0200, Clément Bœsch wrote:
> [...]
 You have 24 hours to make comments.
>>>
>>> 24 hours is IMHO too little. What is the hurry? Maybe at least 96 hours?
>>>
>>
>> People had time to comment on the thread already, but sure OK for 96
>> hours.
>>
> 
> Not sure if I counted well, but the survey starts now at
> https://fr.surveymonkey.com/r/QCP7JSS

Done, thanks!

-Thilo

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

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Clément Bœsch]

On Tue, Oct 13, 2015 at 12:31:10AM -0400, Ganesh Ajjanagadde wrote:
> On Tue, Oct 13, 2015 at 12:26 AM, Ganesh Ajjanagadde  wrote:
> > On Tue, Oct 13, 2015 at 12:16 AM, Carl Eugen Hoyos  wrote:
> >> Ganesh Ajjanagadde  mit.edu> writes:
> >>
> >>> Bench from libavfilter/astats on a 15 min clip.
> >>
> >> I believe that your test would indicate that the
> >> old variant is faster or that no result can be
> >> given which is what my tests show.
> 
> Also, how you can possibly believe that the old variant is faster is
> beyond me given the astonishing amount of work by Intel, Red Hat, and
> others to create the absolutely best performing libc.
> 
> Just have a look at
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_sin.c;hb=HEAD#l281,
> it gives an idea of the extreme lengths they go to.
> 

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_fabs.c;hb=HEAD

[/tmp]☭ cat a.c
#include 
#include 

#define FFABS(a) ((a) >= 0 ? (a) : (-(a)))

double f1d(double x) { return fabs(x); }
double f2d(double x) { return FFABS(x); }

int f1i(int x) { return abs(x); }
int f2i(int x) { return FFABS(x); }
[/tmp]☭ gcc -O2 -c a.c && objdump -d -Mintel a.o

a.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   f2 0f 10 0d 00 00 00movsd  xmm1,QWORD PTR [rip+0x0]# 8 

   7:   00 
   8:   66 0f 54 c1 andpd  xmm0,xmm1
   c:   c3  ret
   d:   0f 1f 00nopDWORD PTR [rax]

0010 :
  10:   66 0f 2e 05 00 00 00ucomisd xmm0,QWORD PTR [rip+0x0]# 18 

  17:   00 
  18:   72 06   jb 20 
  1a:   f3 c3   repz ret 
  1c:   0f 1f 40 00 nopDWORD PTR [rax+0x0]
  20:   f2 0f 10 0d 00 00 00movsd  xmm1,QWORD PTR [rip+0x0]# 28 

  27:   00 
  28:   66 0f 57 c1 xorpd  xmm0,xmm1
  2c:   c3  ret
  2d:   0f 1f 00nopDWORD PTR [rax]

0030 :
  30:   89 fa   movedx,edi
  32:   89 f8   moveax,edi
  34:   c1 fa 1fsaredx,0x1f
  37:   31 d0   xoreax,edx
  39:   29 d0   subeax,edx
  3b:   c3  ret
  3c:   0f 1f 40 00 nopDWORD PTR [rax+0x0]

0040 :
  40:   89 fa   movedx,edi
  42:   89 f8   moveax,edi
  44:   c1 fa 1fsaredx,0x1f
  47:   31 d0   xoreax,edx
  49:   29 d0   subeax,edx
  4b:   c3  ret
[/tmp]☭ 

So fabs() is inlined by the compiler (gcc 5.2.0 here), while abs() is
essentially identical to FFABS().

I have similar results with clang (3.7.0).

Conclusion: using fabs() looks better with at least recent versions of clang
and GCC on x86-64 (but may introduce slight behaviour changes?)

To be more rigorous, it would be interesting to compare on different arch &
compilers, but changing FFABS() with fabs() sounds OK to me.

-- 
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] mips & aac breakage

[Nedeljko Babic]

Hi Michael,

I am checking fate test results and posts on the ffmpeg-devel list basically 
only once a day so thanks for this info.

-Nedeljko

Od: Michael Niedermayer [mich...@niedermayer.cc]
Poslato: 13. oktobar 2015 4:57
Za: FFmpeg development discussions and patches; Nedeljko Babic
Tema: mips & aac breakage

Hi

you probably already saw it but just to be sure its not missed
mips optimizations where broken again today:

CC  libavcodec/mips/aaccoder_mips.o
ffmpeg/libavcodec/mips/aaccoder_mips.c: In function ‘ff_aac_coder_init_mips’:
ffmpeg/libavcodec/mips/aaccoder_mips.c:2548: error: ‘AACEncOptions’ has no 
member named ‘aac_coder’
make: *** [libavcodec/mips/aaccoder_mips.o] Error 1
make: Target `all' not remade because of errors.

ive disabled them in 97437bd17a8c5d4135b2f3b1b299bd7bb72ce02c so
build is not broken


--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/9] x86: simple_idct10_template: fix overflow in pass

[Christophe Gisquet]

Hi,

2015-10-13 2:26 GMT+02:00 Michael Niedermayer :
> On Mon, Oct 12, 2015 at 07:37:46PM +0200, Christophe Gisquet wrote:
>> When the input of a pass has 15 or 16 bits of precision (in particular
>> the column pass), the addition of a bias to W4 may lead to overflows
>> in the input to pmaddwd.
>>
>> This requires postponing the adding of the bias to after the first
>> butterfly. To do so, the fact that m15, unused although zeroed, is
>> exploited. In case the pass is safe, an address can be directly used,
>> and the number of xmm regs can be decreased. Otherwise, the 32bits bias
>> is loaded into it.
>> ---
>>  libavcodec/x86/proresdsp.asm  |  8 
>>  libavcodec/x86/simple_idct10_template.asm | 13 -
>>  2 files changed, 16 insertions(+), 5 deletions(-)
>
> how can i reproduce these overflows ?

Generate the vsynth3-dnxhd-1080i-10bit.mov added after another patch.

Decode it first using faani (you could miss the error).

Now, for the parameters that fail. You know how
(1<<(%pass_bitdepth-1))/W4 is added to the first butterfly. The macro
allows to pass the right pw_ to it (essentially times 4 dw
1<<(%pass_bitdepth-1-14)), or "" and expects to find a
pd_round_%pass_bitdepth (essentially times 4 dd
1<<(%pass_bitdepth-1)). This is indicated in the comments of the
template: "Adding 1<<(%2-1) for >=15 bits values".

Contrast:
"", 13, pw_8, 18, 0, pw_1023 => stddev:1.33 PSNR: 45.61 MAXDIFF:  255
"", 12, pw_16, 19, 0, pw_1023 => stddev:0.33 PSNR: 57.61 MAXDIFF:  255
to the result of the current parameters (no difference)

The same input doesn't cause issue to prores, for some reason,
probably because the mean DC (through times 4 dw 0x2008) is added at
the last pass.

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

Re: [FFmpeg-devel] [PATCH] avcodec/fft: out of place permutation with av_fft_permute2

[Muhammad Faiz]

remaining patches (2 patches)
i am sorry i dont send them as patchset

thanks
From 83b82b028232d1bbe91b636a94ad68b6d8026dab Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Tue, 13 Oct 2015 11:59:21 +0700
Subject: [PATCH] avcodec/x86/fft: use default fft_permute

default fft_permute is faster
---
 libavcodec/x86/fft_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/x86/fft_init.c b/libavcodec/x86/fft_init.c
index 5085f11..6792ba5 100644
--- a/libavcodec/x86/fft_init.c
+++ b/libavcodec/x86/fft_init.c
@@ -44,7 +44,7 @@ av_cold void ff_fft_init_x86(FFTContext *s)
 /* SSE for P3/P4/K8 */
 s->imdct_calc  = ff_imdct_calc_sse;
 s->imdct_half  = ff_imdct_half_sse;
-s->fft_permute = ff_fft_permute_sse;
+/* s->fft_permute = ff_fft_permute_sse; */
 s->fft_calc= ff_fft_calc_sse;
 s->fft_permutation = FF_FFT_PERM_SWAP_LSBS;
 }
-- 
1.8.3.1

From 74a5a19069980d7a400f7c6f7dec30d282f1dee3 Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Tue, 13 Oct 2015 14:59:39 +0700
Subject: [PATCH] avfilter/avf_showcqt: use av_fft_permute2

---
 libavfilter/avf_showcqt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
index 5d5fa6c..32856f8 100644
--- a/libavfilter/avf_showcqt.c
+++ b/libavfilter/avf_showcqt.c
@@ -469,8 +469,7 @@ static int plot_cqt(AVFilterLink *inlink)
 int font_height = (FONT_HEIGHT/2) * video_scale;
 
 /* real part contains left samples, imaginary part contains right samples 
*/
-memcpy(s->fft_result, s->fft_data, fft_len * sizeof(*s->fft_data));
-av_fft_permute(s->fft_context, s->fft_result);
+av_fft_permute2(s->fft_context, s->fft_result, s->fft_data);
 av_fft_calc(s->fft_context, s->fft_result);
 s->fft_result[fft_len] = s->fft_result[0];
 
-- 
1.8.3.1

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

[FFmpeg-devel] RTP API in ffmpeg

[Abhilash Mhaisne]

Hey all,
 Does ffmpeg have an API for the real time transport protocol?
If yes, can you give links? I am unable to find.

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

Re: [FFmpeg-devel] [PATCH 2/9] fate: add 10bits YUV4:2:2 test

[Christophe Gisquet]

Hi,

2015-10-13 4:04 GMT+02:00 Michael Niedermayer :
> wasnt that easy, there was another difference, between 32 and 64bit
> it may be float rounding in the scaler but its not dnxhd i worked
> around it by adjusting the scaler parameters.

I'm not completely sure now, but I think I didn't run into those
failures under Win64. That's a strange thing that no fate test
previously caught the issue before (irrespective of dnxhd), but it
sounds like something that may bite again.

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

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Paul B Mahol]

On 10/13/15, Clement Boesch  wrote:
> On Tue, Oct 13, 2015 at 12:31:10AM -0400, Ganesh Ajjanagadde wrote:
>> On Tue, Oct 13, 2015 at 12:26 AM, Ganesh Ajjanagadde 
>> wrote:
>> > On Tue, Oct 13, 2015 at 12:16 AM, Carl Eugen Hoyos 
>> > wrote:
>> >> Ganesh Ajjanagadde  mit.edu> writes:
>> >>
>> >>> Bench from libavfilter/astats on a 15 min clip.
>> >>
>> >> I believe that your test would indicate that the
>> >> old variant is faster or that no result can be
>> >> given which is what my tests show.
>>
>> Also, how you can possibly believe that the old variant is faster is
>> beyond me given the astonishing amount of work by Intel, Red Hat, and
>> others to create the absolutely best performing libc.
>>
>> Just have a look at
>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_sin.c;hb=HEAD#l281,
>> it gives an idea of the extreme lengths they go to.
>>
>
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_fabs.c;hb=HEAD
>
> [/tmp]* cat a.c
> #include 
> #include 
>
> #define FFABS(a) ((a) >= 0 ? (a) : (-(a)))
>
> double f1d(double x) { return fabs(x); }
> double f2d(double x) { return FFABS(x); }
>
> int f1i(int x) { return abs(x); }
> int f2i(int x) { return FFABS(x); }
> [/tmp]* gcc -O2 -c a.c && objdump -d -Mintel a.o
>
> a.o: file format elf64-x86-64
>
>
> Disassembly of section .text:
>
>  :
>0:   f2 0f 10 0d 00 00 00movsd  xmm1,QWORD PTR [rip+0x0]# 8
> 
>7:   00
>8:   66 0f 54 c1 andpd  xmm0,xmm1
>c:   c3  ret
>d:   0f 1f 00nopDWORD PTR [rax]
>
> 0010 :
>   10:   66 0f 2e 05 00 00 00ucomisd xmm0,QWORD PTR [rip+0x0]# 18
> 
>   17:   00
>   18:   72 06   jb 20 
>   1a:   f3 c3   repz ret
>   1c:   0f 1f 40 00 nopDWORD PTR [rax+0x0]
>   20:   f2 0f 10 0d 00 00 00movsd  xmm1,QWORD PTR [rip+0x0]# 28
> 
>   27:   00
>   28:   66 0f 57 c1 xorpd  xmm0,xmm1
>   2c:   c3  ret
>   2d:   0f 1f 00nopDWORD PTR [rax]
>
> 0030 :
>   30:   89 fa   movedx,edi
>   32:   89 f8   moveax,edi
>   34:   c1 fa 1fsaredx,0x1f
>   37:   31 d0   xoreax,edx
>   39:   29 d0   subeax,edx
>   3b:   c3  ret
>   3c:   0f 1f 40 00 nopDWORD PTR [rax+0x0]
>
> 0040 :
>   40:   89 fa   movedx,edi
>   42:   89 f8   moveax,edi
>   44:   c1 fa 1fsaredx,0x1f
>   47:   31 d0   xoreax,edx
>   49:   29 d0   subeax,edx
>   4b:   c3  ret
> [/tmp]*
>
> So fabs() is inlined by the compiler (gcc 5.2.0 here), while abs() is
> essentially identical to FFABS().
>
> I have similar results with clang (3.7.0).
>
> Conclusion: using fabs() looks better with at least recent versions of
> clang
> and GCC on x86-64 (but may introduce slight behaviour changes?)
>
> To be more rigorous, it would be interesting to compare on different arch &
> compilers, but changing FFABS() with fabs() sounds OK to me.

What about fmax/FFMAX?
> --
> Clement B.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] QSV support clarifications

[Gwenole Beauchesne]

Hi,

2015-10-12 20:10 GMT+02:00 Stefano Sabatini :
> Hi all,
>
> I wanted to test QSV encoding and decoding, which is included since
> several months in FFmpeg, and have a few questions.
>
> 1. QSV encoding and decoding depends on libmfx, but no references are
> present in the code to the library, so I have to suppose that the
> required library is this one:
> https://github.com/lu-zero/mfx_dispatch

Luca's repo is indeed what allows it to build effortlessly, while also
supplying a DSO for libmfx.
It is also possible to build against the Intel supplied headers but a
correct pkg-config file is indeed missing, and additional configury
would be needed in the FFmpeg part to use the libs.private portions of
it. i.e. in case we are stuck to a static library.

FFmpeg should also provide an explicit link to libva-drm, since it
uses it in the MFX specific parts.

> While at it, do you know what's the point of the mfx_dispatch
> component (why adding the intel media library path to flags is not
> enough)?

Probably to select between the SW and HW implementations. :)

> 2. The mfx_dispatch library compiles fine on my system, but then I
> wonder how it is supposed to reference the Intel Media library:
> https://software.intel.com/en-us/intel-media-server-studio

IIRC, there is an installation script in the Media Server Studio.
However, I didn't use it but rather used the "Generic" variant and
installed everything into a dedicated subdirectory.

>
> ...
>
> I'm able to compile FFmpeg with --enable-libmfx after installing
> the mfx_dispatch library, and run this command:
> ffmpeg -i test.mp4 -c:v h264_qsv -y test.out.mp4
>
> but then it fails with:
> Error initializing an internal MFX session
>
> Running strace on the command it results that it's looking for the
> libmfxsw64.so library and failing:
> open("/lib/x86_64-linux-gnu/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
> (No such file or directory)
> open("/usr/lib/x86_64-linux-gnu/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 
> ENOENT (No such file or directory)
> open("/lib/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
> directory)
> open("/usr/lib/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
> or directory)
> munmap(0x7f9a55072000, 155122)  = 0
>
> If I update the LD_LIBRARY_PATH to point to the intel media library in
> /opt/intel/mediasdk it will find the library and then hang.
>
> I had some hard time finding relevant information on the Internet, so
> I ask if you can help to clarify these points.
>
> I'll happily provide a few benchmarks and update documentation
> accordingly if I manage to make it work.
> --
> FFmpeg = Fancy and Forgiving Mean Problematic Excellent Gymnast
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet

[Tomas Härdin]

On Mon, 2015-10-05 at 14:25 +0200, Tobias Rapp wrote:
> On 05.10.2015 09:10, tim nicholson wrote:
> > On 04/10/15 13:07, Tomas Härdin wrote:
> >> On Mon, 2015-09-28 at 15:11 +0200, Tobias Rapp wrote:
> >>> [...]
> >>
> >> For me the most important thing is that anything dealing with MXF should
> >> never write invalid files.
> >
> > +1 for sure.
> 
> To overstate your point: So it would be OK to skip most input frames and 
> replace them with black frames as long as the output file is valid MXF?
> 
> I think there are different requirements for determining what makes an 
> "error" depending on the use-case. If I try to recover video frames from 
> an broken hard disk, for example, I probably won't mind some lost 
> frames. If I try to encode a video file from a presumably healthy input 
> file I likely care about lost frames.
> 
> >> I'm not sure whether the current code is
> >> broken per se, but it does look suspicious. Perhaps someone else has a
> >> better idea?
> >>
> >
> > Truncate/pad mis sized frames to allow muxing to continue, and issue a
> > warning (as at present)?
> 
> It is currently quite difficult to ensure that all frames have been 
> transcoded if there is only a warning in the log message because AFAIK 
> the only generic way to separate a info log message from a warning is to 
> parse terminal color code sequences. The other solution would be to 
> maintain a RegEx black-list of log output messages in the parent process.
> 
> Wouldn't it be helpful to introduce some flag option like "-flags 
> +xerror" on avformat level to toggle between "recover as much as 
> possible" mode and "encode all or fail" mode?

Possibly. Feels like it'd be tricky to write tests for. But I do see a
point in having a mode where lavf is not allowed to do anything strange,
as it often tends to want to do. But this really touches on some rather
nasty bits of how lavf is (not) structured, and I think it might be
easier if you just keep some local hack for your workflow rather than
try to bring some sanity to the situation..

/Tomas

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

Re: [FFmpeg-devel] [PATCH 2/9] fate: add 10bits YUV4:2:2 test

[Christophe Gisquet]

Hi,

2015-10-13 0:00 GMT+02:00 Michael Niedermayer :
>> I'm so bad at this codec stuff.
>
> no, you are not, this stuff is rather convoluted and the mpegvideo
> *dct stuff is not well documented.

Sorry for the outburst, it was really frustrating to get caught in
whatever hurdle a modification ran into, for the 4th time or so.
I did try to run local test files, as unfortunately fate doesn't catch
those errors.

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

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

[Bodecs Bela]

Dear Marton Balint,

2015.10.12. 23:07 keltezéssel, Marton Balint írta:


On Mon, 12 Oct 2015, Bodecs Bela wrote:


Dear All,

currently stream specifiers may contain stream index, stream type,
stream id, program id, metadata key/value es usable config settings.
But you can not combine them. In some case, mainly working with
multiprogram mpeg-ts containers as input, this feature would be handy.
This patch makes it possible to combine them.
Examples: p:601:a  will select all audio streams of program 601,
a:m:language:hun will select all audio streams marked by its metadata
as hun language,
p:604:v:0  will select first video stream of program 604,
a:m:language:hun:0 will select 1st audio streams with hun language.
p:403:s:0 will select the first avaiable sub_title tream of program 403,
and p:403:s:m:language:hun:0  will select the first hungarian language
sub_title stream of program 403.  To select first hungarian language
audio stream a:m:language:hun:0
The order of sub-specifiers (program/type/metadata/usable_config) is
arbitrary. So, you may also write v:p:604:0 to select first video stream
of program 604

Please consider to put this enhancement into the official ffmpeg code.


I like the idea, but are you sure just concating the specifiers is a 
good approach?


For example, what will the following mean?

m:language:u

All usable streams with language metadata or streams where the 
language metadata is 'm'?



Thank you for you like my idea.
The current stream specifier syntax is very robust, easy to parse and 
easy to use. I would not introduce any new
syntax for applying multiple criteria in the stream specifier 
expressions. On the other hand, there are only few people,
who really needs this multiple criteria feature. My enhancement does not 
alter the current behaviour in any way.
So most of the users will not notice anything. But those who really need 
it, they will appreciate it.
So, I think, by making possible to concatenate  specifiers  inside 
stream specifier expressions is a natural way to

extend the current syntax.

Regarding your example: m:language:u
This expression is right in the current applicable syntax, without any 
enhancement. It means "all streams where the language metadata is u"
To select "streams where the language metadata is 'm'? " you should 
write  m:language:m


With my enhancement you can achive to select "All usable streams with 
language metadata" as you wrote:
(more precisely I think you mean: all usable stream where there exists 
language metadata independently its value)


u:m:language  or m:language::u



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

best regards,

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

Re: [FFmpeg-devel] [PATCH] vf_lut: Add support for RGB48 and RGBA64

[Paul B Mahol]

On 10/11/15, Steven Robertson  wrote:
> Thanks for taking a look!
>
> Steve
>

lgtm, do you need to update fate?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Clément Bœsch]

On Tue, Oct 13, 2015 at 09:25:03AM +0200, Paul B Mahol wrote:
[...]
> What about fmax/FFMAX?

Feel free to try that out (it looks OT regarding the patch), but fmax()
looks glibc specific

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] avfilter/fifo: fix failed assertion

[Muhammad Faiz]

From 93ba60f844d8e81435eeefe6cc7cac2d79d518c6 Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Tue, 13 Oct 2015 15:09:17 +0700
Subject: [PATCH] avfilter/fifo: fix failed assertion

some filters make fifo filter fail:
at least showcqt and showwaves (i don't check all)
command:
ffmpeg -loglevel debug -filter_complex "amovie=audio.mp3, showcqt, fifo" -f 
null -y /dev/null
message:
Assertion fifo->root.next failed at libavfilter/fifo.c:240
Aborted
---
 libavfilter/fifo.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/libavfilter/fifo.c b/libavfilter/fifo.c
index e477cff..ae670e2 100644
--- a/libavfilter/fifo.c
+++ b/libavfilter/fifo.c
@@ -187,9 +187,9 @@ static int return_audio_frame(AVFilterContext *ctx)
 }
 
 while (s->out->nb_samples < s->allocated_samples) {
-int len;
+int len, must_break = 0;
 
-if (!s->root.next) {
+while (!s->root.next) {
 ret = ff_request_frame(ctx->inputs[0]);
 if (ret == AVERROR_EOF) {
 av_samples_set_silence(s->out->extended_data,
@@ -198,11 +198,13 @@ static int return_audio_frame(AVFilterContext *ctx)
s->out->nb_samples,
nb_channels, link->format);
 s->out->nb_samples = s->allocated_samples;
+must_break = 1;
 break;
 } else if (ret < 0)
 return ret;
-av_assert0(s->root.next); // If ff_request_frame() succeeded 
then we should have a frame
 }
+if (must_break)
+break;
 head = s->root.next->frame;
 
 len = FFMIN(s->allocated_samples - s->out->nb_samples,
@@ -231,13 +233,12 @@ static int request_frame(AVFilterLink *outlink)
 FifoContext *fifo = outlink->src->priv;
 int ret = 0;
 
-if (!fifo->root.next) {
+while (!fifo->root.next) {
 if ((ret = ff_request_frame(outlink->src->inputs[0])) < 0) {
 if (ret == AVERROR_EOF && outlink->request_samples)
 return return_audio_frame(outlink->src);
 return ret;
 }
-av_assert0(fifo->root.next);
 }
 
 if (outlink->request_samples) {
-- 
1.8.3.1

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

Re: [FFmpeg-devel] Survey for the community

[Thomas Volkert]

On Fri, Oct 09, 2015 at 06:13:05PM +0200, Clément Bœsch wrote: [...]

You have 24 hours to make comments.

24 hours is IMHO too little. What is the hurry? Maybe at least 96 hours?


People had time to comment on the thread already, but sure OK for 96
hours.


Not sure if I counted well, but the survey starts now at
https://fr.surveymonkey.com/r/QCP7JSS

ffmpeg-user announce: 
http://ffmpeg.org/pipermail/ffmpeg-user/2015-October/028798.html

Google+ and twitter maintainers, can you share it here too?


Shared on Facebook:  https://www.facebook.com/ffmpeg.org

Best regards,
Thomas.



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

[FFmpeg-devel] [PATCH 1/2] avutil/fifo: add function av_fifo_generic_peek_at()

[Zhang Rui]

---
 libavutil/fifo.c| 37 +
 libavutil/fifo.h| 11 +++
 tests/ref/fate/fifo | 14 ++
 3 files changed, 62 insertions(+)

diff --git a/libavutil/fifo.c b/libavutil/fifo.c
index 07fb4ec..cabb009 100644
--- a/libavutil/fifo.c
+++ b/libavutil/fifo.c
@@ -148,6 +148,35 @@ int av_fifo_generic_write(AVFifoBuffer *f, void *src, int 
size,
 return total - size;
 }
 
+int av_fifo_generic_peek_at(AVFifoBuffer *f, void *dest, int offset, int 
buf_size, void (*func)(void*, void*, int))
+{
+uint8_t *rptr = f->rptr + offset;
+uint32_t rndx = f->rndx + offset;
+
+av_assert2(offset >= 0);
+while (buf_size > 0) {
+int len;
+
+if (rptr >= f->end)
+rptr -= f->end - f->buffer;
+
+av_assert2(rndx < f->wndx);
+len = FFMIN(f->end - rptr, buf_size);
+if (func)
+func(dest, rptr, len);
+else {
+memcpy(dest, rptr, len);
+dest = (uint8_t *)dest + len;
+}
+
+buf_size -= len;
+rptr += len;
+rndx += len;
+}
+
+return 0;
+}
+
 int av_fifo_generic_peek(AVFifoBuffer *f, void *dest, int buf_size,
  void (*func)(void *, void *, int))
 {
@@ -223,6 +252,14 @@ int main(void)
 }
 printf("\n");
 
+/* peek_at at FIFO */
+n = av_fifo_size(fifo) / sizeof(int);
+for (i = 0; i < n; i++) {
+av_fifo_generic_peek_at(fifo, , i * sizeof(int), sizeof(j), NULL);
+printf("%d: %d\n", i, j);
+}
+printf("\n");
+
 /* read data */
 for (i = 0; av_fifo_size(fifo) >= sizeof(int); i++) {
 av_fifo_generic_read(fifo, , sizeof(int), NULL);
diff --git a/libavutil/fifo.h b/libavutil/fifo.h
index 0e4070b..dc7bc6f 100644
--- a/libavutil/fifo.h
+++ b/libavutil/fifo.h
@@ -84,6 +84,17 @@ int av_fifo_size(const AVFifoBuffer *f);
 int av_fifo_space(const AVFifoBuffer *f);
 
 /**
+ * Feed data at specific position from an AVFifoBuffer to a user-supplied 
callback.
+ * Similar as av_fifo_gereric_read but without discarding data.
+ * @param f AVFifoBuffer to read from
+ * @param offset offset from current read position
+ * @param buf_size number of bytes to read
+ * @param func generic read function
+ * @param dest data destination
+ */
+int av_fifo_generic_peek_at(AVFifoBuffer *f, void *dest, int offset, int 
buf_size, void (*func)(void*, void*, int));
+
+/**
  * Feed data from an AVFifoBuffer to a user-supplied callback.
  * Similar as av_fifo_gereric_read but without discarding data.
  * @param f AVFifoBuffer to read from
diff --git a/tests/ref/fate/fifo b/tests/ref/fate/fifo
index 18a5691..5a59c5a 100644
--- a/tests/ref/fate/fifo
+++ b/tests/ref/fate/fifo
@@ -24,4 +24,18 @@
 11: 11
 12: 12
 
+0: 0
+1: 1
+2: 2
+3: 3
+4: 4
+5: 5
+6: 6
+7: 7
+8: 8
+9: 9
+10: 10
+11: 11
+12: 12
+
 0 1 2 3 4 5 6 7 8 9 10 11 12
-- 
2.5.3

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

[FFmpeg-devel] [PATCH 2/2] avformat/async: cache some data for fast seek backward

[Zhang Rui]

---
 libavformat/async.c | 123 
 1 file changed, 104 insertions(+), 19 deletions(-)

diff --git a/libavformat/async.c b/libavformat/async.c
index a8c8f54..9fac84a 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -24,7 +24,6 @@
  /**
  * @TODO
  *  support timeout
- *  support backward short seek
  *  support work with concatdec, hls
  */
 
@@ -43,8 +42,17 @@
 #endif
 
 #define BUFFER_CAPACITY (4 * 1024 * 1024)
+#define READ_BACK_CAPACITY  (4 * 1024 * 1024)
 #define SHORT_SEEK_THRESHOLD(256 * 1024)
 
+typedef struct RingBuffer
+{
+AVFifoBuffer *fifo;
+int   read_back_capacity;
+
+int   read_pos;
+} RingBuffer;
+
 typedef struct Context {
 AVClass*class;
 URLContext *inner;
@@ -61,7 +69,7 @@ typedef struct Context {
 
 int64_t logical_pos;
 int64_t logical_size;
-AVFifoBuffer   *fifo;
+RingBuffer  ring;
 
 pthread_cond_t  cond_wakeup_main;
 pthread_cond_t  cond_wakeup_background;
@@ -72,6 +80,73 @@ typedef struct Context {
 AVIOInterruptCB interrupt_callback;
 } Context;
 
+static int ring_init(RingBuffer *ring, unsigned int capacity, int 
read_back_capacity)
+{
+memset(ring, 0, sizeof(RingBuffer));
+ring->fifo = av_fifo_alloc(capacity + read_back_capacity);
+if (!ring->fifo)
+return AVERROR(ENOMEM);
+
+ring->read_back_capacity = read_back_capacity;
+return 0;
+}
+
+static void ring_destroy(RingBuffer *ring)
+{
+av_fifo_freep(>fifo);
+}
+
+static void ring_reset(RingBuffer *ring)
+{
+av_fifo_reset(ring->fifo);
+ring->read_pos = 0;
+}
+
+static int ring_size(RingBuffer *ring)
+{
+return av_fifo_size(ring->fifo) - ring->read_pos;
+}
+
+static int ring_space(RingBuffer *ring)
+{
+return av_fifo_space(ring->fifo);
+}
+
+static int ring_generic_read(RingBuffer *ring, void *dest, int buf_size, void 
(*func)(void*, void*, int))
+{
+int ret;
+
+av_assert2(buf_size <= ring_size(ring));
+ret = av_fifo_generic_peek_at(ring->fifo, dest, ring->read_pos, buf_size, 
func);
+ring->read_pos += buf_size;
+
+if (ring->read_pos > ring->read_back_capacity) {
+av_fifo_drain(ring->fifo, ring->read_pos - ring->read_back_capacity);
+ring->read_pos = ring->read_back_capacity;
+}
+
+return ret;
+}
+
+static int ring_generic_write(RingBuffer *ring, void *src, int size, int 
(*func)(void*, void*, int))
+{
+av_assert2(size <= ring_space(ring));
+return av_fifo_generic_write(ring->fifo, src, size, func);
+}
+
+static int ring_size_of_read_back(RingBuffer *ring)
+{
+return ring->read_pos;
+}
+
+static int ring_drain(RingBuffer *ring, int offset)
+{
+av_assert2(offset >= -ring_size_of_read_back(ring));
+av_assert2(offset <= -ring_size(ring));
+ring->read_pos += offset;
+return 0;
+}
+
 static int async_check_interrupt(void *arg)
 {
 URLContext *h   = arg;
@@ -102,7 +177,7 @@ static void *async_buffer_task(void *arg)
 {
 URLContext   *h= arg;
 Context  *c= h->priv_data;
-AVFifoBuffer *fifo = c->fifo;
+RingBuffer   *ring = >ring;
 int   ret  = 0;
 int64_t   seek_ret;
 
@@ -132,14 +207,14 @@ static void *async_buffer_task(void *arg)
 c->seek_ret   = seek_ret;
 c->seek_request   = 0;
 
-av_fifo_reset(fifo);
+ring_reset(ring);
 
 pthread_cond_signal(>cond_wakeup_main);
 pthread_mutex_unlock(>mutex);
 continue;
 }
 
-fifo_space = av_fifo_space(fifo);
+fifo_space = ring_space(ring);
 if (c->io_eof_reached || fifo_space <= 0) {
 pthread_cond_signal(>cond_wakeup_main);
 pthread_cond_wait(>cond_wakeup_background, >mutex);
@@ -149,7 +224,7 @@ static void *async_buffer_task(void *arg)
 pthread_mutex_unlock(>mutex);
 
 to_copy = FFMIN(4096, fifo_space);
-ret = av_fifo_generic_write(fifo, (void *)h, to_copy, (void 
*)wrapped_url_read);
+ret = ring_generic_write(ring, (void *)h, to_copy, (void 
*)wrapped_url_read);
 
 pthread_mutex_lock(>mutex);
 if (ret <= 0) {
@@ -173,11 +248,9 @@ static int async_open(URLContext *h, const char *arg, int 
flags, AVDictionary **
 
 av_strstart(arg, "async:", );
 
-c->fifo = av_fifo_alloc(BUFFER_CAPACITY);
-if (!c->fifo) {
-ret = AVERROR(ENOMEM);
+ret = ring_init(>ring, BUFFER_CAPACITY, READ_BACK_CAPACITY);
+if (ret < 0)
 goto fifo_fail;
-}
 
 /* wrap interrupt callback */
 c->interrupt_callback = h->interrupt_callback;
@@ -225,7 +298,7 @@ cond_wakeup_main_fail:
 mutex_fail:
 ffurl_close(c->inner);
 url_fail:
-av_fifo_freep(>fifo);
+ring_destroy(>ring);
 fifo_fail:
 return ret;
 }
@@ -248,7 +321,7 @@ static int async_close(URLContext *h)
 pthread_cond_destroy(>cond_wakeup_main);
 

Re: [FFmpeg-devel] RTP API in ffmpeg

[Ronald S. Bultje]

Hi,

On Tue, Oct 13, 2015 at 2:47 AM, Abhilash Mhaisne  wrote:

> Hey all,
>  Does ffmpeg have an API for the real time transport protocol?
> If yes, can you give links? I am unable to find.


Just open a rtp://ip.ip.ip.ip:port link as argument to avformat_open_input.
You can use private options to set protocol (RTP/UDP) options. For sending,
it's the same, but you open an output file.

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

Re: [FFmpeg-devel] [PATCH 3/3][RFC] avfilter/vf_chromakey: Add OpenCL acceleration

[highgod0401]

From: Timo Rothenpieler
Date: 2015-10-10 17:47
To: FFmpeg development discussions and patches
CC: highgod0401
Subject: Re: [FFmpeg-devel] [PATCH 3/3][RFC] avfilter/vf_chromakey: Add OpenCL 
acceleration
> Could you please fix it?
> 
> Thanks
> 
> Best regards

curl
https://github.com/BtbN/FFmpeg/commit/29294c283a656cf809461cbae21d612b5a0f2159.patch
| git apply

That works for me, the patch is not in git format-patch format, so git
am can't apply it.

I also attached the two patches in format-patch format, in case you
realy want to use git am.

Hi

I use your filter, but the kernel can't pass the compile, you should consider 
the "double" type in the kernel, some GPU card does not support double type
I add "#pragma OPENCL_EXTENSION cl_khr_fp64: enable " to the kernel, but it 
does not works

I will check the error tomorrow

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

Re: [FFmpeg-devel] [PATCH] web/src/about: add note on portability

[Ganesh Ajjanagadde]

On Mon, Oct 12, 2015 at 3:44 PM, Ganesh Ajjanagadde  wrote:
> On Sun, Oct 11, 2015 at 8:27 PM, Ganesh Ajjanagadde  wrote:
>> On Sun, Oct 11, 2015 at 6:00 PM, Moritz Barsnick  wrote:
>>> On Sun, Oct 11, 2015 at 16:29:16 -0400, Ganesh Ajjanagadde wrote:
 +  Microsoft Windows, the BSD's, Solaris, etc. under a wide variety of 
 build
>>> ^
>>> Even abbreviations and acronyms don't get an apostrophe with their
>>> plural 's'.
>>>
>>> http://www.oxforddictionaries.com/words/apostrophe
>>
>> Noted, changed locally. By the way, I was debating about adding info
>> about machine architectures to get "build environments, machine
>> architectures, and configurations." It is slightly more verbose, and
>> we want this paragraph to be pretty short. As such, I am not sure
>> about this, though I slightly favor adding it.
>
> any other suggestions? I am not comfortable with write access to
> ffmpeg-web, so unless there are any other comments on this I will post
> a patchv2.

v2 sent.

>
>>
>>>
>>> Moritz
>>> ___
>>> 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 7/9] x86: simple_idct: add pure idct functions

[Michael Niedermayer]

On Mon, Oct 12, 2015 at 07:37:48PM +0200, Christophe Gisquet wrote:
> This is done by not passing clamping regs to the macro, and there,
> deducing that this is a pure idct.
> 
> There are not many users (vf_spp is one), and the _add version doesn't
> look like it will ever be used.
> ---
>  libavcodec/x86/idctdsp_init.c |  4 +-
>  libavcodec/x86/proresdsp.asm  |  8 ++--
>  libavcodec/x86/simple_idct.h  |  3 ++
>  libavcodec/x86/simple_idct10.asm  | 12 +++--
>  libavcodec/x86/simple_idct10_template.asm | 76 
> +++
>  5 files changed, 64 insertions(+), 39 deletions(-)

stashed with previous commit to not break spp and applied

thanks

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- 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 5/9] x86: simple_idct10_template: fix overflow in pass

[Michael Niedermayer]

On Tue, Oct 13, 2015 at 01:33:07PM +0200, Christophe Gisquet wrote:
> Hi,
> 
> 2015-10-13 13:10 GMT+02:00 Michael Niedermayer :
> > hmm, iam a bit concerned that adding the rounder (which effectively is
> > 0.5) causes a overflow, that would if iam not mistaken imlpy that
> > things are very close to overflowing already without it
> 
> It's true, but the immediate cause here is the input coeffs
> overflowing (ie, once the rounder is added, a positive value is seen
> as a negative one to pmaddwd).

have you tried using saturating additions for the rounder ?


> 
> Otherwise, your concern is basically whether 32bits arithmetics is
> enough: then simple_idct may also overflows on x86_32.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH 8/9] x86: simple_idct: 12bits versions

[Michael Niedermayer]

On Mon, Oct 12, 2015 at 07:37:49PM +0200, Christophe Gisquet wrote:
> On 12 frames of a 444p 12 bits DNxHR sequence, _put function:
> C: 78902 decicycles in idct,  262071 runs, 73 skips
> avx:   32478 decicycles in idct,  262045 runs, 99 skips
> 
> Difference between the 2:
> stddev:0.39 PSNR:104.47 MAXDIFF:2
> 
> This is unavoidable and due to the scale factors used in the x86
> version, which cannot match the C ones.
> 
> In addition, the trick of adding an initial bias to the input of a
> pass can overflow, as the input coefficients are already 15bits,
> which is the maximum this function can handle.
> 
> Overall, however, the omse on 12 bits samples goes from 0.16916 to
> 0.16883. Reducing rowshift by 1 improves to 0.0908, but causes
> overflows.
> ---
>  libavcodec/x86/idctdsp_init.c| 22 --
>  libavcodec/x86/simple_idct.h |  6 ++
>  libavcodec/x86/simple_idct10.asm | 16 
>  3 files changed, 42 insertions(+), 2 deletions(-)

applied

thanks

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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] news: add thank you note for telepoint/mediahub

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 9:13 AM, compn  wrote:
> On Mon, 12 Oct 2015 15:10:22 -0700
> "Reynaldo H. Verdejo Pinochet"  wrote:
>
>> Signed-off-by: Reynaldo H. Verdejo Pinochet 
>> ---
>>  src/index | 33 +
>>  1 file changed, 33 insertions(+)
>
> thanks
>
> applied.

Was the grammar change I pointed out incorporated? What about the
second suggestion?

>
> -compn
> ___
> 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] news: add thank you note for telepoint/mediahub

[compn]

On Tue, 13 Oct 2015 09:18:35 -0400
Ganesh Ajjanagadde  wrote:

> On Tue, Oct 13, 2015 at 9:13 AM, compn  wrote:
> > On Mon, 12 Oct 2015 15:10:22 -0700
> > "Reynaldo H. Verdejo Pinochet"  wrote:
> >
> >> Signed-off-by: Reynaldo H. Verdejo Pinochet
> >>  ---
> >>  src/index | 33 +
> >>  1 file changed, 33 insertions(+)
> >
> > thanks
> >
> > applied.
> 
> Was the grammar change I pointed out incorporated? What about the
> second suggestion?

you can check on ffmpeg.org (it updated as soon as i committed).

"on their own" -> "in their own" was fixed. thank you.

"for their support" -> "for your support" was not.

just my personal choice, as now the sentence kind of reads as a general
"everyone should thank telepoint/mediahub for this donation" instead of
a "we thank telepoint/mediahub for this donation". more of a community
thank you? i dunno. maybe it should be "thanks TO telepoint and ..."
instead.

if i was going to fix something else i'd probably change this as well:
"donated a dedicated server with free of charge internet connectivity."
to "donated a dedicated server and bandwidth."

i am a native english speaker , but years of helping non-native english
speakers has warped my comprehension. so now if i think the sentence
conveys the required information, i will just leave it alone. :)

otherwise hours and hours get spent on spelling and grammar and it
drains motivation to work on other things.

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

Re: [FFmpeg-devel] [PATCH 6/9] x86: simple_idct_put: 10bits versions

[Michael Niedermayer]

On Mon, Oct 12, 2015 at 07:37:47PM +0200, Christophe Gisquet wrote:
> Modeled from the prores version. Clips to [0;1023] and is bitexact.
> Bitexactness requires to add offsets in different places compared to
> prores or C, and makes the function approximately 2% slower.
> 
> For 16 frames of a DNxHD 4:2:2 10bits test sequence:
> 
> C:60861 decicycles in idct, 1048205 runs,371 skips
> sse2: 27567 decicycles in idct, 1048216 runs,360 skips
> avx:  26272 decicycles in idct, 1048171 runs,405 skips
> 
> The pure and add versions are not implemented, so the corresponding dsp
> functions are set to NULL to make it clear in a code executing them.
> ---
>  libavcodec/x86/Makefile  |  1 +
>  libavcodec/x86/idctdsp_init.c| 20 +++
>  libavcodec/x86/simple_idct.h |  3 +++
>  libavcodec/x86/simple_idct10.asm | 54 
> 
>  4 files changed, 78 insertions(+)
>  create mode 100644 libavcodec/x86/simple_idct10.asm

applied

thanks

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet

[Tobias Rapp]

On 13.10.2015 08:42, Tomas Härdin wrote:

On Mon, 2015-10-05 at 14:25 +0200, Tobias Rapp wrote:

On 05.10.2015 09:10, tim nicholson wrote:

On 04/10/15 13:07, Tomas Härdin wrote:

On Mon, 2015-09-28 at 15:11 +0200, Tobias Rapp wrote:

[...]


For me the most important thing is that anything dealing with MXF should
never write invalid files.


+1 for sure.


To overstate your point: So it would be OK to skip most input frames and
replace them with black frames as long as the output file is valid MXF?

I think there are different requirements for determining what makes an
"error" depending on the use-case. If I try to recover video frames from
an broken hard disk, for example, I probably won't mind some lost
frames. If I try to encode a video file from a presumably healthy input
file I likely care about lost frames.


I'm not sure whether the current code is
broken per se, but it does look suspicious. Perhaps someone else has a
better idea?



Truncate/pad mis sized frames to allow muxing to continue, and issue a
warning (as at present)?


It is currently quite difficult to ensure that all frames have been
transcoded if there is only a warning in the log message because AFAIK
the only generic way to separate a info log message from a warning is to
parse terminal color code sequences. The other solution would be to
maintain a RegEx black-list of log output messages in the parent process.

Wouldn't it be helpful to introduce some flag option like "-flags
+xerror" on avformat level to toggle between "recover as much as
possible" mode and "encode all or fail" mode?


Possibly. Feels like it'd be tricky to write tests for. But I do see a
point in having a mode where lavf is not allowed to do anything strange,
as it often tends to want to do. But this really touches on some rather
nasty bits of how lavf is (not) structured, and I think it might be
easier if you just keep some local hack for your workflow rather than
try to bring some sanity to the situation..


I agree that it would cause too much impact to add some "lavf mode 
switch" that covers the different use-cases. Will work-around it by some 
log message pattern matching in my application.


Thanks for taking the time to discuss the issue. I think I have a better 
view on the situation now.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 5/9] x86: simple_idct10_template: fix overflow in pass

[Michael Niedermayer]

On Tue, Oct 13, 2015 at 09:01:44AM +0200, Christophe Gisquet wrote:
> Hi,
> 
> 2015-10-13 2:26 GMT+02:00 Michael Niedermayer :
> > On Mon, Oct 12, 2015 at 07:37:46PM +0200, Christophe Gisquet wrote:
> >> When the input of a pass has 15 or 16 bits of precision (in particular
> >> the column pass), the addition of a bias to W4 may lead to overflows
> >> in the input to pmaddwd.
> >>
> >> This requires postponing the adding of the bias to after the first
> >> butterfly. To do so, the fact that m15, unused although zeroed, is
> >> exploited. In case the pass is safe, an address can be directly used,
> >> and the number of xmm regs can be decreased. Otherwise, the 32bits bias
> >> is loaded into it.
> >> ---
> >>  libavcodec/x86/proresdsp.asm  |  8 
> >>  libavcodec/x86/simple_idct10_template.asm | 13 -
> >>  2 files changed, 16 insertions(+), 5 deletions(-)
> >
> > how can i reproduce these overflows ?
> 
> Generate the vsynth3-dnxhd-1080i-10bit.mov added after another patch.
> 
> Decode it first using faani (you could miss the error).
> 
> Now, for the parameters that fail. You know how
> (1<<(%pass_bitdepth-1))/W4 is added to the first butterfly. The macro
> allows to pass the right pw_ to it (essentially times 4 dw
> 1<<(%pass_bitdepth-1-14)), or "" and expects to find a
> pd_round_%pass_bitdepth (essentially times 4 dd
> 1<<(%pass_bitdepth-1)). This is indicated in the comments of the
> template: "Adding 1<<(%2-1) for >=15 bits values".

hmm, iam a bit concerned that adding the rounder (which effectively is
0.5) causes a overflow, that would if iam not mistaken imlpy that
things are very close to overflowing already without it

but either way this patch is needed for the 10bit IDCT code
so applied

thanks

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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, swresample, swscale: use fabs, fabsf instead of FFABS

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 2:45 AM, Clément Bœsch  wrote:
> On Tue, Oct 13, 2015 at 12:31:10AM -0400, Ganesh Ajjanagadde wrote:
>> On Tue, Oct 13, 2015 at 12:26 AM, Ganesh Ajjanagadde  
>> wrote:
>> > On Tue, Oct 13, 2015 at 12:16 AM, Carl Eugen Hoyos  
>> > wrote:
>> >> Ganesh Ajjanagadde  mit.edu> writes:
>> >>
>> >>> Bench from libavfilter/astats on a 15 min clip.
>> >>
>> >> I believe that your test would indicate that the
>> >> old variant is faster or that no result can be
>> >> given which is what my tests show.
>>
>> Also, how you can possibly believe that the old variant is faster is
>> beyond me given the astonishing amount of work by Intel, Red Hat, and
>> others to create the absolutely best performing libc.
>>
>> Just have a look at
>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_sin.c;hb=HEAD#l281,
>> it gives an idea of the extreme lengths they go to.
>>
>
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_fabs.c;hb=HEAD
>
> [/tmp]☭ cat a.c
> #include 
> #include 
>
> #define FFABS(a) ((a) >= 0 ? (a) : (-(a)))
>
> double f1d(double x) { return fabs(x); }
> double f2d(double x) { return FFABS(x); }
>
> int f1i(int x) { return abs(x); }
> int f2i(int x) { return FFABS(x); }
> [/tmp]☭ gcc -O2 -c a.c && objdump -d -Mintel a.o
>
> a.o: file format elf64-x86-64
>
>
> Disassembly of section .text:
>
>  :
>0:   f2 0f 10 0d 00 00 00movsd  xmm1,QWORD PTR [rip+0x0]# 8 
> 
>7:   00
>8:   66 0f 54 c1 andpd  xmm0,xmm1
>c:   c3  ret
>d:   0f 1f 00nopDWORD PTR [rax]
>
> 0010 :
>   10:   66 0f 2e 05 00 00 00ucomisd xmm0,QWORD PTR [rip+0x0]# 18 
> 
>   17:   00
>   18:   72 06   jb 20 
>   1a:   f3 c3   repz ret
>   1c:   0f 1f 40 00 nopDWORD PTR [rax+0x0]
>   20:   f2 0f 10 0d 00 00 00movsd  xmm1,QWORD PTR [rip+0x0]# 28 
> 
>   27:   00
>   28:   66 0f 57 c1 xorpd  xmm0,xmm1
>   2c:   c3  ret
>   2d:   0f 1f 00nopDWORD PTR [rax]
>
> 0030 :
>   30:   89 fa   movedx,edi
>   32:   89 f8   moveax,edi
>   34:   c1 fa 1fsaredx,0x1f
>   37:   31 d0   xoreax,edx
>   39:   29 d0   subeax,edx
>   3b:   c3  ret
>   3c:   0f 1f 40 00 nopDWORD PTR [rax+0x0]
>
> 0040 :
>   40:   89 fa   movedx,edi
>   42:   89 f8   moveax,edi
>   44:   c1 fa 1fsaredx,0x1f
>   47:   31 d0   xoreax,edx
>   49:   29 d0   subeax,edx
>   4b:   c3  ret
> [/tmp]☭
>
> So fabs() is inlined by the compiler (gcc 5.2.0 here), while abs() is
> essentially identical to FFABS().

Yes, on integers they are identical. Differences come on floating
point, which is the point of my patch. Thanks for showing the asm.

>
> I have similar results with clang (3.7.0).
>
> Conclusion: using fabs() looks better with at least recent versions of clang
> and GCC on x86-64 (but may introduce slight behaviour changes?)

There might be some behavior changes (floating point is not exact,
etc), but at least they are governed by the ISO C document. FATE still
passes.

>
> To be more rigorous, it would be interesting to compare on different arch &
> compilers, but changing FFABS() with fabs() sounds OK to me.
>
> --
> Clément B.
>
> ___
> 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 01/10] lavu: add AESNI CPU flag

[Moritz Barsnick]

On Tue, Oct 13, 2015 at 04:27:07 +0200, Michael Niedermayer wrote:
> > @@ -117,6 +117,7 @@ static const struct {
> >  { "SSSE3","ssse3",AV_CPU_FLAG_SSSE3|AV_CPU_FLAG_ATOM },
> >  { "SSE4.1",   "sse4", AV_CPU_FLAG_SSE4 },
> >  { "SSE4.2",   "sse42",AV_CPU_FLAG_SSE42 },
> > +{ "AES-NI",   "aesni",AV_CPU_FLAG_AESNI },
> 
> not 100% sure its this but the - looks like invalid syntax
> -, +, *, /, ... should be avoided

In this case, isn't this just a string used in print_cpu_name()?

BTW, Henrik Gramner pointed out yesterday:

> Should be "AES-NI" with a dash here since that's the official name,
> possibly in a few other places as well (using a dash wherever SSE4.1
> is spelled with dot is probably reasonable).

And Rodger didn't even change it everywhere possible (commit message,
configure output). ;-)

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

Re: [FFmpeg-devel] [PATCH 5/9] x86: simple_idct10_template: fix overflow in pass

[Christophe Gisquet]

Hi,

2015-10-13 13:10 GMT+02:00 Michael Niedermayer :
> hmm, iam a bit concerned that adding the rounder (which effectively is
> 0.5) causes a overflow, that would if iam not mistaken imlpy that
> things are very close to overflowing already without it

It's true, but the immediate cause here is the input coeffs
overflowing (ie, once the rounder is added, a positive value is seen
as a negative one to pmaddwd).

Otherwise, your concern is basically whether 32bits arithmetics is
enough: then simple_idct may also overflows on x86_32.

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

Re: [FFmpeg-devel] [PATCH 2/9] fate: add 10bits YUV4:2:2 test

[Christophe Gisquet]

2015-10-13 9:06 GMT+02:00 Christophe Gisquet :
>I think I didn't run into those failures under Win64.

Confirmed, as well as under Win32 (also gcc 5.2.0) and gcc x86_64
4.9.2 under a linux environment.

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

[FFmpeg-devel] [PATCH 2/2] avformat: add vag demuxer

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/Makefile |  1 +
 libavformat/allformats.c |  1 +
 libavformat/vag.c| 78 
 3 files changed, 80 insertions(+)
 create mode 100644 libavformat/vag.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2971912..c2170c8 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -440,6 +440,7 @@ OBJS-$(CONFIG_TTA_DEMUXER)   += tta.o apetag.o 
img2.o
 OBJS-$(CONFIG_TTY_DEMUXER)   += tty.o sauce.o
 OBJS-$(CONFIG_TXD_DEMUXER)   += txd.o
 OBJS-$(CONFIG_UNCODEDFRAMECRC_MUXER) += uncodedframecrcenc.o framehash.o
+OBJS-$(CONFIG_VAG_DEMUXER)   += vag.o
 OBJS-$(CONFIG_VC1_DEMUXER)   += rawdec.o
 OBJS-$(CONFIG_VC1_MUXER) += rawenc.o
 OBJS-$(CONFIG_VC1T_DEMUXER)  += vc1test.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0ccde9d..f732611 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -307,6 +307,7 @@ void av_register_all(void)
 REGISTER_DEMUXER (TXD,  txd);
 REGISTER_DEMUXER (TTY,  tty);
 REGISTER_MUXER   (UNCODEDFRAMECRC,  uncodedframecrc);
+REGISTER_DEMUXER (VAG,  vag);
 REGISTER_MUXDEMUX(VC1,  vc1);
 REGISTER_MUXDEMUX(VC1T, vc1t);
 REGISTER_DEMUXER (VIVO, vivo);
diff --git a/libavformat/vag.c b/libavformat/vag.c
new file mode 100644
index 000..e40159f
--- /dev/null
+++ b/libavformat/vag.c
@@ -0,0 +1,78 @@
+/*
+ * VAG demuxer
+ * Copyright (c) 2015 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; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/channel_layout.h"
+#include "avformat.h"
+#include "internal.h"
+
+static int vag_probe(AVProbeData *p)
+{
+if (memcmp(p->buf, "VAGp", 4))
+return 0;
+
+return AVPROBE_SCORE_MAX / 3 * 2;
+}
+
+static int vag_read_header(AVFormatContext *s)
+{
+AVStream *st;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+avio_skip(s->pb, 4);
+st->codec->codec_type  = AVMEDIA_TYPE_AUDIO;
+st->codec->codec_id= AV_CODEC_ID_ADPCM_PSX;
+st->codec->channels= 1 + (avio_rb32(s->pb) == 0x0004);
+avio_skip(s->pb, 4);
+st->duration   = avio_rb32(s->pb) / 16 * 28;
+st->codec->sample_rate = avio_rb32(s->pb);
+if (st->codec->sample_rate <= 0)
+return AVERROR_INVALIDDATA;
+avio_skip(s->pb, 28);
+avpriv_set_pts_info(st, 64, 1, st->codec->sample_rate);
+
+return 0;
+}
+
+static int vag_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+int ret;
+
+if (avio_feof(s->pb))
+return AVERROR_EOF;
+
+ret = av_get_packet(s->pb, pkt, 1024);
+if (ret > 0 && ret < 1024)
+av_shrink_packet(pkt, ret);
+
+return ret;
+}
+
+AVInputFormat ff_vag_demuxer = {
+.name   = "vag",
+.long_name  = NULL_IF_CONFIG_SMALL("Sony VAG"),
+.read_probe = vag_probe,
+.read_header= vag_read_header,
+.read_packet= vag_read_packet,
+.extensions = "vag",
+};
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH]vc1 Autodetection

[Carl Eugen Hoyos]

On Monday 05 October 2015 03:53:32 am Michael Niedermayer wrote:
> On Sun, Oct 04, 2015 at 11:47:59PM +0200, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached is a patch implementing vc-1 autodetection.
> >
> > Please review, Carl Eugen
> >
> >  Makefile  |2 -
> >  rawdec.c  |4 ---
> >  vc1dec.c  |   71
> > ++ version.h
> > |2 -
> >  4 files changed, 73 insertions(+), 6 deletions(-)
>
> tools/probetest 100 10
> ...
> testing size=65536
> Failure of vc1 probing code with score=51 type=1 p=DF0 size=65536

Slightly improved patch attached that passes probetest.

Please review, Carl Eugen
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 2971912..d118019 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -440,7 +440,7 @@ OBJS-$(CONFIG_TTA_DEMUXER)   += tta.o apetag.o 
img2.o
 OBJS-$(CONFIG_TTY_DEMUXER)   += tty.o sauce.o
 OBJS-$(CONFIG_TXD_DEMUXER)   += txd.o
 OBJS-$(CONFIG_UNCODEDFRAMECRC_MUXER) += uncodedframecrcenc.o framehash.o
-OBJS-$(CONFIG_VC1_DEMUXER)   += rawdec.o
+OBJS-$(CONFIG_VC1_DEMUXER)   += rawdec.o vc1dec.o
 OBJS-$(CONFIG_VC1_MUXER) += rawenc.o
 OBJS-$(CONFIG_VC1T_DEMUXER)  += vc1test.o
 OBJS-$(CONFIG_VC1T_MUXER)+= vc1testenc.o
diff --git a/libavformat/rawdec.c b/libavformat/rawdec.c
index 16fb221..7098ebd 100644
--- a/libavformat/rawdec.c
+++ b/libavformat/rawdec.c
@@ -205,7 +205,3 @@ static int mjpeg_probe(AVProbeData *p)
 
 FF_DEF_RAWVIDEO_DEMUXER2(mjpeg, "raw MJPEG video", mjpeg_probe, 
"mjpg,mjpeg,mpo", AV_CODEC_ID_MJPEG, AVFMT_GENERIC_INDEX|AVFMT_NOTIMESTAMPS)
 #endif
-
-#if CONFIG_VC1_DEMUXER
-FF_DEF_RAWVIDEO_DEMUXER2(vc1, "raw VC-1", NULL, "vc1", AV_CODEC_ID_VC1, 
AVFMT_GENERIC_INDEX|AVFMT_NOTIMESTAMPS)
-#endif
diff --git a/libavformat/vc1dec.c b/libavformat/vc1dec.c
index e69de29..33f8465 100644
--- a/libavformat/vc1dec.c
+++ b/libavformat/vc1dec.c
@@ -0,0 +1,81 @@
+/*
+ * VC-1 demuxer
+ * Copyright (c) 2015 Carl Eugen Hoyos
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+#include "rawdec.h"
+#include "libavutil/intreadwrite.h"
+#include "libavcodec/vc1_common.h"
+
+static int vc1_probe(AVProbeData *p)
+{
+int seq = 0, entry = 0, frame = 0, i;
+
+for (i = 0; i < p->buf_size + 5; i++) {
+uint32_t code = AV_RB32(p->buf + i);
+if ((code & 0xffe0) == 0x100) {
+int type = code & 0x11f;
+i += 4;
+switch (type) {
+case VC1_CODE_SEQHDR: {
+int profile, level, chromaformat;
+profile = (p->buf[i] & 0xc0) >> 6;
+if (profile != PROFILE_ADVANCED) {
+seq = 0;
+continue;
+}
+level = (p->buf[i] & 0x38) >> 3;
+if (level >= 5) {
+seq = 0;
+continue;
+}
+chromaformat = (p->buf[i] & 0x6) >> 1;
+if (chromaformat != 1) {
+seq = 0;
+continue;
+}
+seq++;
+i += 6;
+break;
+}
+case VC1_CODE_ENTRYPOINT:
+if (!seq)
+continue;
+entry++;
+i += 2;
+break;
+case VC1_CODE_FRAME:
+case VC1_CODE_FIELD:
+case VC1_CODE_SLICE:
+if (seq && entry)
+frame++;
+break;
+}
+}
+}
+
+if (frame > 1)
+return AVPROBE_SCORE_EXTENSION / 2 + 1;
+if (frame == 1)
+return AVPROBE_SCORE_EXTENSION / 4;
+return 0;
+}
+
+FF_DEF_RAWVIDEO_DEMUXER2(vc1, "raw VC-1", vc1_probe, "vc1", AV_CODEC_ID_VC1, 
AVFMT_GENERIC_INDEX|AVFMT_NOTIMESTAMPS)
diff --git a/libavformat/version.h b/libavformat/version.h
index f7a2e09..76e2f55 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -31,7 +31,7 @@
 
 #define LIBAVFORMAT_VERSION_MAJOR  57
 #define LIBAVFORMAT_VERSION_MINOR   3
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
 
 

Re: [FFmpeg-devel] [RFC] QSV support clarifications

[Ivan Uskov]

Hello Stefano,

Monday, October 12, 2015, 9:10:04 PM, you wrote:
SS> 2. The mfx_dispatch library compiles fine on my system, but then I
SS> wonder how it is supposed to reference the Intel Media library:
SS> https://software.intel.com/en-us/intel-media-server-studio

SS> ...

SS> I'm able to compile FFmpeg with --enable-libmfx after installing
SS> the mfx_dispatch library, and run this command:
SS> ffmpeg -i test.mp4 -c:v h264_qsv -y test.out.mp4

SS> but then it fails with:
SS> Error initializing an internal MFX session
As far as I understanding Intel's libraries and patches from Media SDK should
be  present  in a system.
The  open-source mfx dispatch library is just wrapper which loads appropriate
.so by intel.
The official instruction how to setup intel media sdk
on linux is following: 
https://software.intel.com/sites/default/files/media_server_studio_getting_started_guide.pdf

 SS> Running strace on the command it results that it's looking for the
SS> libmfxsw64.so library and failing:
SS> open("/lib/x86_64-linux-gnu/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
SS> open("/usr/lib/x86_64-linux-gnu/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
SS> open("/lib/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
SS> open("/usr/lib/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such 
file or directory)
SS> munmap(0x7f9a55072000, 155122)  = 0
Intel's library usually locates into the
/opt/intel/mediasdk/lib64
For example for Media SDK 1.16 here following files should be:
-rwxr-xr-x. 1 root root 28826704 Jun 11 08:44 iHD_drv_video.so
-rwxr-xr-x. 1 root root 10646952 Jun 11 08:44 libmfxhw64-p.so.1.16
lrwxrwxrwx. 1 root root   20 Jul 10 16:52 libmfxhw64.so -> 
libmfxhw64-p.so.1.16
-rwxr-xr-x. 1 root root  9364712 Jun 11 08:44 libmfxsw64-p.so.1.16
lrwxrwxrwx. 1 root root   20 Jul 10 16:52 libmfxsw64.so -> 
libmfxsw64-p.so.1.16


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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

[FFmpeg-devel] [PATCH 1/2] avcodec: add ADPCM PSX decoder

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile|  1 +
 libavcodec/adpcm.c | 43 +++
 libavcodec/allcodecs.c |  1 +
 libavcodec/avcodec.h   |  1 +
 4 files changed, 46 insertions(+)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b8bd895..f9c8501 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -686,6 +686,7 @@ OBJS-$(CONFIG_ADPCM_IMA_WAV_ENCODER)  += adpcmenc.o 
adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_WS_DECODER)   += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_MS_DECODER)   += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_MS_ENCODER)   += adpcmenc.o adpcm_data.o
+OBJS-$(CONFIG_ADPCM_PSX_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_SBPRO_2_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_SBPRO_3_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_SBPRO_4_DECODER)  += adpcm.o adpcm_data.o
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index ba38041..904bb2b 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -152,6 +152,7 @@ static av_cold int adpcm_decode_init(AVCodecContext * avctx)
 case AV_CODEC_ID_ADPCM_THP_LE:
 case AV_CODEC_ID_ADPCM_AFC:
 case AV_CODEC_ID_ADPCM_DTK:
+case AV_CODEC_ID_ADPCM_PSX:
 avctx->sample_fmt = AV_SAMPLE_FMT_S16P;
 break;
 case AV_CODEC_ID_ADPCM_IMA_WS:
@@ -665,6 +666,7 @@ static int get_nb_samples(AVCodecContext *avctx, 
GetByteContext *gb,
 nb_samples = (buf_size / 128) * 224 / ch;
 break;
 case AV_CODEC_ID_ADPCM_DTK:
+case AV_CODEC_ID_ADPCM_PSX:
 nb_samples = buf_size / (16 * ch) * 28;
 break;
 }
@@ -1548,6 +1550,46 @@ static int adpcm_decode_frame(AVCodecContext *avctx, 
void *data,
 bytestream2_seek(, 0, SEEK_SET);
 }
 break;
+case AV_CODEC_ID_ADPCM_PSX:
+for (channel = 0; channel < avctx->channels; channel++) {
+samples = samples_p[channel];
+
+/* Read in every sample for this channel.  */
+for (i = 0; i < nb_samples / 28; i++) {
+int predict, shift, flag;
+int16_t byte;
+
+predict = bytestream2_get_byteu();
+shift   = predict & 0xf;
+predict = predict >> 4;
+if (predict >= 5)
+return AVERROR_INVALIDDATA;
+flag= bytestream2_get_byteu();
+
+/* Decode 28 samples.  */
+for (n = 0; n < 28; n++) {
+int32_t sample = 0;
+int16_t scale;
+
+if (flag < 0x07) {
+if (!(n & 1))
+byte = bytestream2_get_byteu();
+if (!(n & 1))
+scale = byte & 0xf;
+else
+scale = byte >> 4;
+
+scale = scale << 12;
+
+sample = (int)((scale >> shift) + 
c->status[channel].sample1 * xa_adpcm_table[predict][0] / 64 + 
c->status[channel].sample2 * xa_adpcm_table[predict][1] / 64);
+}
+*samples++ = av_clip_int16(sample);
+c->status[channel].sample2 = c->status[channel].sample1;
+c->status[channel].sample1 = sample;
+}
+}
+}
+break;
 
 default:
 return -1;
@@ -1622,6 +1664,7 @@ ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_SMJPEG,  
sample_fmts_s16,  adpcm_ima_smjpeg,
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_WAV, sample_fmts_s16p, adpcm_ima_wav,  
   "ADPCM IMA WAV");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_WS,  sample_fmts_both, adpcm_ima_ws,   
   "ADPCM IMA Westwood");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_MS,  sample_fmts_s16,  adpcm_ms,   
   "ADPCM Microsoft");
+ADPCM_DECODER(AV_CODEC_ID_ADPCM_PSX, sample_fmts_s16p, adpcm_psx,  
   "ADPCM PSX");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_SBPRO_2, sample_fmts_s16,  adpcm_sbpro_2,  
   "ADPCM Sound Blaster Pro 2-bit");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_SBPRO_3, sample_fmts_s16,  adpcm_sbpro_3,  
   "ADPCM Sound Blaster Pro 2.6-bit");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_SBPRO_4, sample_fmts_s16,  adpcm_sbpro_4,  
   "ADPCM Sound Blaster Pro 4-bit");
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index c8f7992..b19c9fd 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -508,6 +508,7 @@ void avcodec_register_all(void)
 REGISTER_ENCDEC (ADPCM_IMA_WAV, adpcm_ima_wav);
 REGISTER_DECODER(ADPCM_IMA_WS,  adpcm_ima_ws);
 REGISTER_ENCDEC (ADPCM_MS,  adpcm_ms);
+REGISTER_DECODER(ADPCM_PSX, adpcm_psx);
 REGISTER_DECODER(ADPCM_SBPRO_2, adpcm_sbpro_2);
 REGISTER_DECODER(ADPCM_SBPRO_3, adpcm_sbpro_3);
 REGISTER_DECODER(ADPCM_SBPRO_4, adpcm_sbpro_4);
diff --git 

Re: [FFmpeg-devel] [RFC] QSV support clarifications

[Michael Niedermayer]

CC-ing Ivan so he doesnt miss this though he should be following
ffmpeg-devel and keeping an eye on qsv anyway ...

On Mon, Oct 12, 2015 at 08:10:04PM +0200, Stefano Sabatini wrote:
> Hi all,
> 
> I wanted to test QSV encoding and decoding, which is included since
> several months in FFmpeg, and have a few questions.
> 
> 1. QSV encoding and decoding depends on libmfx, but no references are
> present in the code to the library, so I have to suppose that the
> required library is this one:
> https://github.com/lu-zero/mfx_dispatch
> 
> While at it, do you know what's the point of the mfx_dispatch
> component (why adding the intel media library path to flags is not
> enough)?
> 
> 2. The mfx_dispatch library compiles fine on my system, but then I
> wonder how it is supposed to reference the Intel Media library:
> https://software.intel.com/en-us/intel-media-server-studio
> 
> ...
> 
> I'm able to compile FFmpeg with --enable-libmfx after installing
> the mfx_dispatch library, and run this command:
> ffmpeg -i test.mp4 -c:v h264_qsv -y test.out.mp4
> 
> but then it fails with:
> Error initializing an internal MFX session
> 
> Running strace on the command it results that it's looking for the
> libmfxsw64.so library and failing:
> open("/lib/x86_64-linux-gnu/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
> (No such file or directory)
> open("/usr/lib/x86_64-linux-gnu/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 
> ENOENT (No such file or directory)
> open("/lib/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
> directory)
> open("/usr/lib/libmfxsw64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
> or directory)
> munmap(0x7f9a55072000, 155122)  = 0
> 
> If I update the LD_LIBRARY_PATH to point to the intel media library in
> /opt/intel/mediasdk it will find the library and then hang.
> 
> I had some hard time finding relevant information on the Internet, so
> I ask if you can help to clarify these points.
> 
> I'll happily provide a few benchmarks and update documentation
> accordingly if I manage to make it work.
> -- 
> FFmpeg = Fancy and Forgiving Mean Problematic Excellent Gymnast
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


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

[FFmpeg-devel] [PATCH] avcodec/mips/aaccoder_mips: Sync with the generic code

[Nedeljko Babic]

This patch fixes build of AAC encoder optimized for mips that was broken due
 to some changes in generic code that were not propagated to the optimized code.

Also, some functions in the optimized code are basically duplicate of functions
 from generic code. Since they do not bring enough improvement to the optimized
 code to justify their existence, they are removed (which improves
 maintainability of the optimized code).

Optimizations disabled in 97437bd are enabled again.

Signed-off-by: Nedeljko Babic 
---
 libavcodec/mips/aaccoder_mips.c | 134 +---
 1 file changed, 3 insertions(+), 131 deletions(-)

diff --git a/libavcodec/mips/aaccoder_mips.c b/libavcodec/mips/aaccoder_mips.c
index 53de94c..e8e1e62 100644
--- a/libavcodec/mips/aaccoder_mips.c
+++ b/libavcodec/mips/aaccoder_mips.c
@@ -63,6 +63,7 @@
 #include "libavcodec/aacenc.h"
 #include "libavcodec/aactab.h"
 #include "libavcodec/aacenctab.h"
+#include "libavcodec/aacenc_utils.h"
 
 #if HAVE_INLINE_ASM
 typedef struct BandCodingPath {
@@ -130,62 +131,6 @@ static const uint8_t esc_sign_bits[289] = {
 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2
 };
 
-#define ROUND_STANDARD 0.4054f
-#define ROUND_TO_ZERO 0.1054f
-
-static void abs_pow34_v(float *out, const float *in, const int size) {
-#ifndef USE_REALLY_FULL_SEARCH
-int i;
-float a, b, c, d;
-float ax, bx, cx, dx;
-
-for (i = 0; i < size; i += 4) {
-a = fabsf(in[i  ]);
-b = fabsf(in[i+1]);
-c = fabsf(in[i+2]);
-d = fabsf(in[i+3]);
-
-ax = sqrtf(a);
-bx = sqrtf(b);
-cx = sqrtf(c);
-dx = sqrtf(d);
-
-a = a * ax;
-b = b * bx;
-c = c * cx;
-d = d * dx;
-
-out[i  ] = sqrtf(a);
-out[i+1] = sqrtf(b);
-out[i+2] = sqrtf(c);
-out[i+3] = sqrtf(d);
-}
-#endif /* USE_REALLY_FULL_SEARCH */
-}
-
-static float find_max_val(int group_len, int swb_size, const float *scaled) {
-float maxval = 0.0f;
-int w2, i;
-for (w2 = 0; w2 < group_len; w2++) {
-for (i = 0; i < swb_size; i++) {
-maxval = FFMAX(maxval, scaled[w2*128+i]);
-}
-}
-return maxval;
-}
-
-static int find_min_book(float maxval, int sf) {
-float Q = ff_aac_pow2sf_tab[POW_SF2_ZERO - sf + SCALE_ONE_POS - 
SCALE_DIV_512];
-float Q34 = sqrtf(Q * sqrtf(Q));
-int qmaxval, cb;
-qmaxval = maxval * Q34 + 0.4054f;
-if (qmaxval >= (FF_ARRAY_ELEMS(aac_maxval_cb)))
-cb = 11;
-else
-cb = aac_maxval_cb[qmaxval];
-return cb;
-}
-
 /**
  * Functions developed from template function and optimized for quantizing and 
encoding band
  */
@@ -860,7 +805,6 @@ static void quantize_and_encode_band_cost_ESC_mips(struct 
AACEncContext *s,
 unsigned int v_codes;
 int c1, c2, c3, c4;
 int t0, t1, t2, t3, t4;
-const float *vec1, *vec2;
 
 qc1 = scaled[i  ] * Q34 + ROUNDING;
 qc2 = scaled[i+1] * Q34 + ROUNDING;
@@ -965,8 +909,6 @@ static void quantize_and_encode_band_cost_ESC_mips(struct 
AACEncContext *s,
 
 if (out || energy) {
 float e1, e2, e3, e4;
-vec1 = _vectors[curidx*2];
-vec2 = _vectors[curidx2*2];
 e1 = copysignf(c1 * cbrtf(c1) * IQ, in[i+0]);
 e2 = copysignf(c2 * cbrtf(c2) * IQ, in[i+1]);
 e3 = copysignf(c3 * cbrtf(c3) * IQ, in[i+2]);
@@ -2390,76 +2332,6 @@ static float quantize_band_cost(struct AACEncContext *s, 
const float *in,
 
 #include "libavcodec/aacenc_quantization_misc.h"
 
-static float find_form_factor(int group_len, int swb_size, float thresh, const 
float *scaled, float nzslope) {
-const float iswb_size = 1.0f / swb_size;
-const float iswb_sizem1 = 1.0f / (swb_size - 1);
-const float ethresh = thresh, iethresh = 1.0f / ethresh;
-float form = 0.0f, weight = 0.0f;
-int w2, i;
-for (w2 = 0; w2 < group_len; w2++) {
-float e = 0.0f, e2 = 0.0f, var = 0.0f, maxval = 0.0f;
-float nzl = 0;
-for (i = 0; i < swb_size; i+=4) {
-float s1 = fabsf(scaled[w2*128+i  ]);
-float s2 = fabsf(scaled[w2*128+i+1]);
-float s3 = fabsf(scaled[w2*128+i+2]);
-float s4 = fabsf(scaled[w2*128+i+3]);
-maxval = FFMAX(maxval, FFMAX(FFMAX(s1, s2), FFMAX(s3, s4)));
-e += (s1+s2)+(s3+s4);
-s1 *= s1;
-s2 *= s2;
-s3 *= s3;
-s4 *= s4;
-e2 += (s1+s2)+(s3+s4);
-/* We really don't want a hard non-zero-line count, since
- * even below-threshold lines do add up towards band spectral 
power.
- * So, fall steeply towards zero, but smoothly
- */
-if (s1 >= ethresh) {
-nzl += 1.0f;
-} else {
-nzl += powf(s1 * iethresh, nzslope);
-}
-

Re: [FFmpeg-devel] [PATCH 01/10] lavu: add AESNI CPU flag

[Michael Niedermayer]

On Tue, Oct 13, 2015 at 02:46:55PM +0200, Moritz Barsnick wrote:
> On Tue, Oct 13, 2015 at 04:27:07 +0200, Michael Niedermayer wrote:
> > > @@ -117,6 +117,7 @@ static const struct {
> > >  { "SSSE3","ssse3",AV_CPU_FLAG_SSSE3|AV_CPU_FLAG_ATOM },
> > >  { "SSE4.1",   "sse4", AV_CPU_FLAG_SSE4 },
> > >  { "SSE4.2",   "sse42",AV_CPU_FLAG_SSE42 },
> > > +{ "AES-NI",   "aesni",AV_CPU_FLAG_AESNI },
> > 
> > not 100% sure its this but the - looks like invalid syntax
> > -, +, *, /, ... should be avoided
> 
> In this case, isn't this just a string used in print_cpu_name()?

maybe it was the aes-ni in
static const AVOption cpuflags_opts[] =
that caused the issue


> 
> BTW, Henrik Gramner pointed out yesterday:
> 
> > Should be "AES-NI" with a dash here since that's the official name,
> > possibly in a few other places as well (using a dash wherever SSE4.1
> > is spelled with dot is probably reasonable).
> 
> And Rodger didn't even change it everywhere possible (commit message,
> configure output). ;-)
> 
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
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] [PATCHv2] web/src/about: add note on portability

[Moritz Barsnick]

> +  environments, machine architecture, and configurations.
  ^^
plural -> architectures

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

Re: [FFmpeg-devel] [PATCH 9/9] x86: dct-test: add more idcts

[Michael Niedermayer]

On Mon, Oct 12, 2015 at 07:37:50PM +0200, Christophe Gisquet wrote:
> In particular for 10 and 12 bits.
> ---
>  libavcodec/dct-test.c |  2 ++
>  libavcodec/x86/dct-test.c | 10 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/libavcodec/dct-test.c b/libavcodec/dct-test.c
> index 56e1a62..72fe353 100644
> --- a/libavcodec/dct-test.c
> +++ b/libavcodec/dct-test.c
> @@ -82,6 +82,8 @@ static const struct algo idct_tab[] = {
>  { "REF-DBL", ff_ref_idct,  FF_IDCT_PERM_NONE },
>  { "INT", ff_j_rev_dct, FF_IDCT_PERM_LIBMPEG2 },
>  { "SIMPLE-C",ff_simple_idct_8, FF_IDCT_PERM_NONE },
> +{ "SIMPLE-C10",  ff_simple_idct_10,FF_IDCT_PERM_NONE },
> +{ "SIMPLE-C12",  ff_simple_idct_12,FF_IDCT_PERM_NONE },
>  { "PR-C",ff_prores_idct_wrap,  FF_IDCT_PERM_NONE, 0, 1 },
>  #if CONFIG_FAANIDCT
>  { "FAANI",   ff_faanidct,  FF_IDCT_PERM_NONE },
> diff --git a/libavcodec/x86/dct-test.c b/libavcodec/x86/dct-test.c
> index 0414381..b022552 100644
> --- a/libavcodec/x86/dct-test.c
> +++ b/libavcodec/x86/dct-test.c
> @@ -85,6 +85,16 @@ static const struct algo idct_tab_arch[] = {
>  { "PR-AVX",  ff_prores_idct_put_10_avx_wrap, FF_IDCT_PERM_TRANSPOSE, 
> AV_CPU_FLAG_AVX, 1 },
>  # endif
>  #endif
> +#if HAVE_YASM
> +#if HAVE_SSE2_EXTERNAL
> +{ "SIMPLE10-SSE2",  ff_simple_idct10_sse2, FF_IDCT_PERM_TRANSPOSE, 
> AV_CPU_FLAG_SSE2, 1 },
> +{ "SIMPLE12-SSE2",  ff_simple_idct12_sse2, FF_IDCT_PERM_TRANSPOSE, 
> AV_CPU_FLAG_SSE2, 1 },
> +#endif
> +#if HAVE_AVX_EXTERNAL
> +{ "SIMPLE10-AVX",   ff_simple_idct10_avx,  FF_IDCT_PERM_TRANSPOSE, 
> AV_CPU_FLAG_AVX,  1 },
> +{ "SIMPLE12-AVX",   ff_simple_idct12_avx,  FF_IDCT_PERM_TRANSPOSE, 
> AV_CPU_FLAG_AVX,  1 },
> +#endif
> +#endif

applied with some changes

thanks

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH 06/10] lavu/aes: add x86 AESNI optimizations

[Henrik Gramner]

On Tue, Oct 13, 2015 at 2:33 AM, Rodger Combs  wrote:
> +%macro AES_CRYPT 1
> +%if %1 == 1
> +%define CRYPT aesdec
> +%define LAST  aesdeclast
> +cglobal aes_decrypt, 6,6,2
> +%else
> +%define CRYPT aesenc
> +%define LAST  aesenclast
> +cglobal aes_encrypt, 6,6,2
> +%endif
> +pxor xm1, xm1
> +shl r5d, 4
> +sub r5, 0x60
> +test r4, r4
> +je .block
> +movdqu xm1, [r4] ; iv
> +.block:
> +movdqu xm0, [r2] ; state
> +%if %1 == 0
> +pxor xm0, xm1
> +%endif
> +pxor  xm0, [r0 + r5 + 0x60]
> +CRYPT xm0, [r0 + r5 + 0x50]
> +CRYPT xm0, [r0 + r5 + 0x40]
> +CRYPT xm0, [r0 + r5 + 0x30]
> +CRYPT xm0, [r0 + r5 + 0x20]
> +CRYPT xm0, [r0 + r5 + 0x10]
> +CRYPT xm0, [r0 + r5 + 0x00]
> +CRYPT xm0, [r0 + r5 - 0x10]
> +CRYPT xm0, [r0 + r5 - 0x20]
> +CRYPT xm0, [r0 + r5 - 0x30]
> +cmp r5, 0x60
> +jl .last
> +CRYPT xm0, [r0 + r5 - 0x40]
> +CRYPT xm0, [r0 + r5 - 0x50]
> +cmp r5, 0x80
> +jl .last
> +CRYPT xm0, [r0 + 0x20]
> +CRYPT xm0, [r0 + 0x10]
> +.last:
> +LAST xm0, [r0]
> +test r4, r4
> +je .noiv
> +%if %1 == 1
> +pxor xm0, xm1
> +movdqu xm1, [r2]
> +%else
> +movdqa xm1, xm0
> +%endif
> +.noiv
> +movdqu [r1], xm0
> +dec r3d
> +add r2, 16
> +add r1, 16
> +test r3d, r3d
> +jne .block
> +%if %1 == 0
> +test r4, r4
> +je .ret
> +movdqu [r4], xm0
> +.ret:
> +%endif
> +REP_RET
> +%endmacro

If you use enc and dec as macro arguments instead of 0 and 1 you could
get rid of some of the if:s. E.g. using cglobal aes_%1rypt and the
instructions aes%1 and aes%1last instead of the CRYPT/LAST macros.
"%if %1 == 0" can be replaced by "%ifidn %1, enc" as well (which is
also more clear).

Use m# instead of xm# since you're not dealing with mixing xmm and ymm
registers.

Use mova instead of movdqa and movu instead of movdqu.

Vertically align the lines on the first comma.

You can also adjust the r5 offset to make the "cmp r5, 0x80" fit in a
signed byte as well, but that's pretty minor.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/9] x86: simple_idct10_template: fix overflow in pass

[Christophe Gisquet]

2015-10-13 15:43 GMT+02:00 Michael Niedermayer :
> On Tue, Oct 13, 2015 at 01:33:07PM +0200, Christophe Gisquet wrote:
>> Hi,
>>
>> 2015-10-13 13:10 GMT+02:00 Michael Niedermayer :
>> > hmm, iam a bit concerned that adding the rounder (which effectively is
>> > 0.5) causes a overflow, that would if iam not mistaken imlpy that
>> > things are very close to overflowing already without it
>>
>> It's true, but the immediate cause here is the input coeffs
>> overflowing (ie, once the rounder is added, a positive value is seen
>> as a negative one to pmaddwd).
>
> have you tried using saturating additions for the rounder ?

This would prevent an absolutely wrong result due to overflow, but
would not be sufficient for bitexactness.

The cases where the bitexactness issue arise may be pathological, not
appearing in fate, though.

But I'll check.

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

Re: [FFmpeg-devel] [PATCHv2] avformat/mov: fix integer overflow

[Michael Niedermayer]

On Tue, Oct 13, 2015 at 12:26:24PM -0400, Ganesh Ajjanagadde wrote:
> Partially fixes Ticket 4727.
> 
> -duration is not a safe expression, since duration can be INT_MIN.
> One might ask how it can become INT_MIN.
> Although it is true that line 2574 is no longer reached with INT_MIN due
> to commit 053e80f6eaf8d87521fe58ea96886b6ee0bbe59d (which fixed another
> integer overflow issue), mov_update_dts_shift is called on line 3549 as
> well, right after a read of untrusted data.
> One can do the fix locally there, but that function is already a huge
> mess. Changing mov_update_dts_shift is likely better.
> 
> This changes duration to INT_MIN + 1 in such cases. This should not make any
> practical difference since such streams are anyway fuzzer files.
> 
> Tested with FATE.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavformat/mov.c | 4 
>  1 file changed, 4 insertions(+)

LGTM

thx

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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/mips/aaccoder_mips: Sync with the generic code

[Michael Niedermayer]

On Tue, Oct 13, 2015 at 04:14:51PM +0200, Nedeljko Babic wrote:
> This patch fixes build of AAC encoder optimized for mips that was broken due
>  to some changes in generic code that were not propagated to the optimized 
> code.
> 
> Also, some functions in the optimized code are basically duplicate of 
> functions
>  from generic code. Since they do not bring enough improvement to the 
> optimized
>  code to justify their existence, they are removed (which improves
>  maintainability of the optimized code).
> 
> Optimizations disabled in 97437bd are enabled again.
> 
> Signed-off-by: Nedeljko Babic 
> ---
>  libavcodec/mips/aaccoder_mips.c | 134 
> +---
>  1 file changed, 3 insertions(+), 131 deletions(-)

applied

thanks

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

[FFmpeg-devel] [PATCHv3] web/src/about: add note on portability

[Ganesh Ajjanagadde]

---
 src/about | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/about b/src/about
index 8d8f606..67342a1 100644
--- a/src/about
+++ b/src/about
@@ -4,7 +4,11 @@
 transcode, mux, demux, 
stream, filter and play 
pretty much anything
   that humans and machines have created. It supports the most obscure
   ancient formats up to the cutting edge. No matter if they were
-  designed by some standards committee, the community or a corporation.
+  designed by some standards committee, the community or a corporation. It is
+  also highly portable: FFmpeg compiles, runs, and passes our testing 
infrastructure
+  http://fate.ffmpeg.org;>FATE across Linux, Mac OS X,
+  Microsoft Windows, the BSDs, Solaris, etc. under a wide variety of build
+  environments, machine architectures, and configurations.
 
 
 It contains libavcodec, libavutil, libavformat, libavfilter, 
libavdevice,
-- 
2.6.1

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

[FFmpeg-devel] [PATCHv2] avformat/mov: fix integer overflow

[Ganesh Ajjanagadde]

Partially fixes Ticket 4727.

-duration is not a safe expression, since duration can be INT_MIN.
One might ask how it can become INT_MIN.
Although it is true that line 2574 is no longer reached with INT_MIN due
to commit 053e80f6eaf8d87521fe58ea96886b6ee0bbe59d (which fixed another
integer overflow issue), mov_update_dts_shift is called on line 3549 as
well, right after a read of untrusted data.
One can do the fix locally there, but that function is already a huge
mess. Changing mov_update_dts_shift is likely better.

This changes duration to INT_MIN + 1 in such cases. This should not make any
practical difference since such streams are anyway fuzzer files.

Tested with FATE.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavformat/mov.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4c073a3..7c90d40 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2521,6 +2521,10 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 static void mov_update_dts_shift(MOVStreamContext *sc, int duration)
 {
 if (duration < 0) {
+if (duration == INT_MIN) {
+av_log(NULL, AV_LOG_WARNING, "mov_update_dts_shift(): dts_shift 
set to %d\n", INT_MAX);
+duration++;
+}
 sc->dts_shift = FFMAX(sc->dts_shift, -duration);
 }
 }
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH 1/3] x86: simple_idct10_template: use const

[Ronald S. Bultje]

Hi,

On Tue, Oct 13, 2015 at 3:21 PM, Christophe Gisquet <
christophe.gisq...@gmail.com> wrote:

> This avoid going through constants.c while still sharing them
> with proresdsp.asm
> ---
>  libavcodec/x86/constants.c| 28
> 
>  libavcodec/x86/constants.h| 16 
>  libavcodec/x86/proresdsp.asm  | 13 +
>  libavcodec/x86/simple_idct10.asm  | 26 ++
>  libavcodec/x86/simple_idct10_template.asm | 13 -
>  5 files changed, 39 insertions(+), 57 deletions(-)


Wonderful, thank you! LGTM.

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

[FFmpeg-devel] [PATCH 1/3] x86: simple_idct10_template: use const

[Christophe Gisquet]

This avoid going through constants.c while still sharing them
with proresdsp.asm
---
 libavcodec/x86/constants.c| 28 
 libavcodec/x86/constants.h| 16 
 libavcodec/x86/proresdsp.asm  | 13 +
 libavcodec/x86/simple_idct10.asm  | 26 ++
 libavcodec/x86/simple_idct10_template.asm | 13 -
 5 files changed, 39 insertions(+), 57 deletions(-)

diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c
index 7e3d490..0098e20 100644
--- a/libavcodec/x86/constants.c
+++ b/libavcodec/x86/constants.c
@@ -89,31 +89,3 @@ DECLARE_ALIGNED(32, const ymm_reg,  ff_pd_8192) = { 
0x20002000ULL, 0x000
 0x20002000ULL, 
0x20002000ULL };
 DECLARE_ALIGNED(32, const ymm_reg,  ff_pd_65535)= { 0xULL, 
0xULL,
 0xULL, 
0xULL };
-
-/* simple idct 10 */
-#define W1sh2 22725 // W1 = 90901 = 22725<<2 + 1
-#define W2sh2 21407 // W2 = 85627 = 21407<<2 - 1
-#define W3sh2 19265 // W3 = 77062 = 19265<<2 + 2
-#define W4sh2 16384 // W4 = 65535 = 16384<<2 - 1
-#define W5sh2 12873 // W5 = 51491 = 12873<<2 - 1
-#define W6sh2  8867 // W6 = 35468 =  8867<<2
-#define W7sh2  4520 // W7 = 18081 =  4520<<2 + 1
-
-#define TIMES4(a, b)\
- 
(((b)&0xLL)<<48)+(((a)&0xLL)<<32)+(((b)&0xLL)<<16)+((a)&0xLL), \
- 
(((b)&0xLL)<<48)+(((a)&0xLL)<<32)+(((b)&0xLL)<<16)+((a)&0xLL)
-
-#if ARCH_X86_64
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w4_plus_w2) = { TIMES4(W4sh2,  W2sh2) };
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w4_min_w2)  = { TIMES4(W4sh2, -W2sh2) };
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w4_plus_w6) = { TIMES4(W4sh2, +W6sh2) };
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w4_min_w6)  = { TIMES4(W4sh2, -W6sh2) };
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w1_plus_w3) = { TIMES4(W1sh2, +W3sh2) };
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w3_min_w1)  = { TIMES4(W3sh2, -W1sh2) };
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w7_plus_w3) = { TIMES4(W7sh2, +W3sh2) };
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w3_min_w7)  = { TIMES4(W3sh2, -W7sh2) };
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w1_plus_w5) = { TIMES4(W1sh2, +W5sh2) };
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w5_min_w1)  = { TIMES4(W5sh2, -W1sh2) };
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w5_plus_w7) = { TIMES4(W5sh2, +W7sh2) };
-DECLARE_ALIGNED(16, const xmm_reg,  ff_w7_min_w5)  = { TIMES4(W7sh2, -W5sh2) };
-#endif
diff --git a/libavcodec/x86/constants.h b/libavcodec/x86/constants.h
index 496933f..f989755 100644
--- a/libavcodec/x86/constants.h
+++ b/libavcodec/x86/constants.h
@@ -68,20 +68,4 @@ extern const ymm_reg  ff_pd_32;
 extern const ymm_reg  ff_pd_8192;
 extern const ymm_reg  ff_pd_65535;
 
-# if ARCH_X86_64
-/* simple_idct10, used by prores and dnxhd */
-extern const xmm_reg  ff_w4_plus_w2;
-extern const xmm_reg  ff_w4_min_w2;
-extern const xmm_reg  ff_w4_plus_w6;
-extern const xmm_reg  ff_w4_min_w6;
-extern const xmm_reg  ff_w1_plus_w3;
-extern const xmm_reg  ff_w3_min_w1;
-extern const xmm_reg  ff_w7_plus_w3;
-extern const xmm_reg  ff_w3_min_w7;
-extern const xmm_reg  ff_w1_plus_w5;
-extern const xmm_reg  ff_w5_min_w1;
-extern const xmm_reg  ff_w5_plus_w7;
-extern const xmm_reg  ff_w7_min_w5;
-# endif
-
 #endif /* AVCODEC_X86_CONSTANTS_H */
diff --git a/libavcodec/x86/proresdsp.asm b/libavcodec/x86/proresdsp.asm
index 4633844..edfd2f7 100644
--- a/libavcodec/x86/proresdsp.asm
+++ b/libavcodec/x86/proresdsp.asm
@@ -32,6 +32,19 @@ pw_88:  times 8 dw 0x2008
 cextern pw_1
 cextern pw_4
 cextern pw_1019
+; Below are defined in simple_idct10.asm built from selecting idctdsp
+cextern w4_plus_w2
+cextern w4_min_w2
+cextern w4_plus_w6
+cextern w4_min_w6
+cextern w1_plus_w3
+cextern w3_min_w1
+cextern w7_plus_w3
+cextern w3_min_w7
+cextern w1_plus_w5
+cextern w5_min_w1
+cextern w5_plus_w7
+cextern w7_min_w5
 
 %include "libavcodec/x86/simple_idct10_template.asm"
 
diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm
index ec388f9..cd83d61 100644
--- a/libavcodec/x86/simple_idct10.asm
+++ b/libavcodec/x86/simple_idct10.asm
@@ -37,6 +37,32 @@ pd_round_12: times 4 dd 1<<(12-1)
 pd_round_15: times 4 dd 1<<(15-1)
 pd_round_19: times 4 dd 1<<(19-1)
 
+%macro CONST_DEC  3
+const %1
+times 4 dw %2, %3
+%endmacro
+
+%define W1sh2 22725 ; W1 = 90901 = 22725<<2 + 1
+%define W2sh2 21407 ; W2 = 85627 = 21407<<2 - 1
+%define W3sh2 19265 ; W3 = 77062 = 19265<<2 + 2
+%define W4sh2 16384 ; W4 = 65535 = 16384<<2 - 1
+%define W5sh2 12873 ; W5 = 51491 = 12873<<2 - 1
+%define W6sh2  8867 ; W6 = 35468 =  8867<<2
+%define W7sh2  4520 ; W7 = 18081 =  4520<<2 + 1
+
+CONST_DEC  w4_plus_w2,   W4sh2, +W2sh2
+CONST_DEC  w4_min_w2,W4sh2, -W2sh2
+CONST_DEC  w4_plus_w6,   W4sh2, +W6sh2

Re: [FFmpeg-devel] [PATCH 2/9] fate: add 10bits YUV4:2:2 test

[James Almer]

On 10/12/2015 11:04 PM, Michael Niedermayer wrote:
> On Tue, Oct 13, 2015 at 12:00:07AM +0200, Michael Niedermayer wrote:
>> On Mon, Oct 12, 2015 at 10:39:23PM +0200, Christophe Gisquet wrote:
>>> Le 12 oct. 2015 21:37, "Michael Niedermayer"  a
>>> écrit :

 On Mon, Oct 12, 2015 at 07:37:43PM +0200, Christophe Gisquet wrote:
> It was useful to (accidentally?) spot an overflow in the column pass
> of the x86 simple_idct10 implementation.
> ---
>  tests/fate/vcodec.mak  | 6 +-
>  tests/ref/vsynth/vsynth1-dnxhd-1080i-10bit | 4 
>  tests/ref/vsynth/vsynth2-dnxhd-1080i-10bit | 4 
>  tests/ref/vsynth/vsynth3-dnxhd-1080i-10bit | 4 
>  tests/ref/vsynth/vsynth_lena-dnxhd-1080i-10bit | 4 
>  5 files changed, 21 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/vsynth/vsynth1-dnxhd-1080i-10bit
>  create mode 100644 tests/ref/vsynth/vsynth2-dnxhd-1080i-10bit
>  create mode 100644 tests/ref/vsynth/vsynth3-dnxhd-1080i-10bit
>  create mode 100644 tests/ref/vsynth/vsynth_lena-dnxhd-1080i-10bit

 this alone and with patch 1 doesnt pass fate:
>>>
>>> I'm so bad at this codec stuff.
>>
>> no, you are not, this stuff is rather convoluted and the mpegvideo
>> *dct stuff is not well documented.
>>
>> I think the patchset is mostly fine, ill retest things and will try to
>> fix the remaining issues (if iam able to) and if successfull ill apply
> 
> 
>> it i think this one patch here is fine as is if its applied later in
> 
> wasnt that easy, there was another difference, between 32 and 64bit
> it may be float rounding in the scaler but its not dnxhd i worked
> around it by adjusting the scaler parameters.

This test is failing on pretty much every fate client. Valgrind seems to
complain about uninitialized values.
http://fate.ffmpeg.org/report.cgi?time=20151013040721=x86_64-archlinux-gcc-valgrindundef
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffserver_config: check for INT_MIN before doing FFABS

[Michael Niedermayer]

On Fri, Oct 09, 2015 at 11:31:22AM -0400, Ganesh Ajjanagadde wrote:
> FFABS(INT_MIN) is not safe. Alternative of using FFNABS is not as
> readable.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  ffserver_config.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thanks

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

There will always be a question for which you do not know the correct answer.


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/9] fate: add 10bits YUV4:2:2 test

[Christophe Gisquet]

Hi,

2015-10-13 21:41 GMT+02:00 James Almer :
> This test is failing on pretty much every fate client. Valgrind seems to
> complain about uninitialized values.
> http://fate.ffmpeg.org/report.cgi?time=20151013040721=x86_64-archlinux-gcc-valgrindundef

Can someone test the following patch? I don't think the fate results change.

-- 
Christophe


0001-dnxhdenc-fix-access-outside-of-image.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat: add vag demuxer

[Michael Niedermayer]

On Tue, Oct 13, 2015 at 03:07:36PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/Makefile |  1 +
>  libavformat/allformats.c |  1 +
>  libavformat/vag.c| 78 
> 
>  3 files changed, 80 insertions(+)
>  create mode 100644 libavformat/vag.c
> 
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 2971912..c2170c8 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -440,6 +440,7 @@ OBJS-$(CONFIG_TTA_DEMUXER)   += tta.o 
> apetag.o img2.o
>  OBJS-$(CONFIG_TTY_DEMUXER)   += tty.o sauce.o
>  OBJS-$(CONFIG_TXD_DEMUXER)   += txd.o
>  OBJS-$(CONFIG_UNCODEDFRAMECRC_MUXER) += uncodedframecrcenc.o framehash.o
> +OBJS-$(CONFIG_VAG_DEMUXER)   += vag.o
>  OBJS-$(CONFIG_VC1_DEMUXER)   += rawdec.o
>  OBJS-$(CONFIG_VC1_MUXER) += rawenc.o
>  OBJS-$(CONFIG_VC1T_DEMUXER)  += vc1test.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 0ccde9d..f732611 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -307,6 +307,7 @@ void av_register_all(void)
>  REGISTER_DEMUXER (TXD,  txd);
>  REGISTER_DEMUXER (TTY,  tty);
>  REGISTER_MUXER   (UNCODEDFRAMECRC,  uncodedframecrc);
> +REGISTER_DEMUXER (VAG,  vag);
>  REGISTER_MUXDEMUX(VC1,  vc1);
>  REGISTER_MUXDEMUX(VC1T, vc1t);
>  REGISTER_DEMUXER (VIVO, vivo);
> diff --git a/libavformat/vag.c b/libavformat/vag.c
> new file mode 100644
> index 000..e40159f
> --- /dev/null
> +++ b/libavformat/vag.c
> @@ -0,0 +1,78 @@
> +/*
> + * VAG demuxer
> + * Copyright (c) 2015 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; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "libavutil/channel_layout.h"
> +#include "avformat.h"
> +#include "internal.h"
> +
> +static int vag_probe(AVProbeData *p)
> +{
> +if (memcmp(p->buf, "VAGp", 4))
> +return 0;
> +
> +return AVPROBE_SCORE_MAX / 3 * 2;
> +}
> +
> +static int vag_read_header(AVFormatContext *s)
> +{
> +AVStream *st;
> +
> +st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
> +
> +avio_skip(s->pb, 4);
> +st->codec->codec_type  = AVMEDIA_TYPE_AUDIO;
> +st->codec->codec_id= AV_CODEC_ID_ADPCM_PSX;
> +st->codec->channels= 1 + (avio_rb32(s->pb) == 0x0004);
> +avio_skip(s->pb, 4);
> +st->duration   = avio_rb32(s->pb) / 16 * 28;
> +st->codec->sample_rate = avio_rb32(s->pb);
> +if (st->codec->sample_rate <= 0)
> +return AVERROR_INVALIDDATA;
> +avio_skip(s->pb, 28);
> +avpriv_set_pts_info(st, 64, 1, st->codec->sample_rate);
> +
> +return 0;
> +}
> +
> +static int vag_read_packet(AVFormatContext *s, AVPacket *pkt)
> +{
> +int ret;
> +
> +if (avio_feof(s->pb))
> +return AVERROR_EOF;
> +
> +ret = av_get_packet(s->pb, pkt, 1024);

> +if (ret > 0 && ret < 1024)
> +av_shrink_packet(pkt, ret);

isnt that redundant ?
either way patch LGTM

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

[FFmpeg-devel] [PATCH] concatdec: fix file_start_time calculation regression

[Marton Balint]

Fixes ticket #4924.

Found-by: Jaroslav Šnajdr 
Signed-off-by: Marton Balint 
---
 libavformat/concatdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 832b7f4..7686f28 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -314,7 +314,7 @@ static int open_file(AVFormatContext *avf, unsigned fileno)
 file->start_time = !fileno ? 0 :
cat->files[fileno - 1].start_time +
cat->files[fileno - 1].duration;
-file->file_start_time = (avf->start_time == AV_NOPTS_VALUE) ? 0 : 
avf->start_time;
+file->file_start_time = (cat->avf->start_time == AV_NOPTS_VALUE) ? 0 : 
cat->avf->start_time;
 file->file_inpoint = (file->inpoint == AV_NOPTS_VALUE) ? 
file->file_start_time : file->inpoint;
 if ((ret = match_streams(avf)) < 0)
 return ret;
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH 07/10] checkasm: add tests for AES

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 5:06 PM, Henrik Gramner  wrote:
> Added some randomization to count and made report() less verbose:
>
> diff --git a/tests/checkasm/aes.c b/tests/checkasm/aes.c
> index 67b..4549a3d 100644
> --- a/tests/checkasm/aes.c
> +++ b/tests/checkasm/aes.c
> @@ -23,12 +23,14 @@
>  #include "libavutil/aes_internal.h"
>  #include "libavutil/internal.h"
>
> +#define MAX_COUNT 16

Not really that important, but unless this increases FATE time
significantly, I would recommend a much larger MAX_COUNT, and multiple
iterations (e.g #define an ITER_COUNT), so that the testing is more
extensive over random inputs.

> +
>  void checkasm_check_aes(void)
>  {
>  int i, j, d;
>  AVAES b;
> -uint8_t pt[32];
> -uint8_t temp[2][32];
> +uint8_t pt[MAX_COUNT*16];
> +uint8_t temp[2][MAX_COUNT*16];
>  uint8_t iv[2][16];
>
>  for (d = 0; d <= 1; d++) {
> @@ -37,21 +39,22 @@ void checkasm_check_aes(void)
>  if (check_func(b.crypt, "aes_%scrypt_%i", d ? "de" : "en", i)) {
>  declare_func(void, AVAES *a, uint8_t *dst, const uint8_t 
> *src,
>   int count, uint8_t *iv, int rounds);
> -for (j = 0; j < 32; j++)
> +int count = (rnd() & (MAX_COUNT-1)) + 1;
> +for (j = 0; j < 16*MAX_COUNT; j++)
>  pt[j] = rnd();
>  for (j = 0; j < 16; j++)
>  iv[0][j] = iv[1][j] = rnd();
> -call_ref(, temp[0], pt, 2, iv[0], b.rounds);
> -call_new(, temp[1], pt, 2, iv[1], b.rounds);
> -if (memcmp(temp[0], temp[1], sizeof(temp[0])))
> +call_ref(, temp[0], pt, count, iv[0], b.rounds);
> +call_new(, temp[1], pt, count, iv[1], b.rounds);
> +if (memcmp(temp[0], temp[1], 16*count))
>  fail();
> -call_ref(, temp[0], pt, 2, NULL, b.rounds);
> -call_new(, temp[1], pt, 2, NULL, b.rounds);
> -if (memcmp(temp[0], temp[1], sizeof(temp[0])))
> +call_ref(, temp[0], pt, count, NULL, b.rounds);
> +call_new(, temp[1], pt, count, NULL, b.rounds);
> +if (memcmp(temp[0], temp[1], 16*count))
>  fail();
> -bench_new(, temp[1], pt, 1, NULL, b.rounds);
> +bench_new(, temp[1], pt, MAX_COUNT, NULL, b.rounds);
>  }
> -report("%scrypt_%i", d ? "de" : "en", i);
>  }
>  }
> +report("crypt");
> ___
> 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 2/3] simple_idct12: align C and x86

[Michael Niedermayer]

On Tue, Oct 13, 2015 at 09:21:40PM +0200, Christophe Gisquet wrote:
> Results for omse on the 3 idct dct-test.
> 
> C:   0.16915859   0.11848359   0.12913125
> x86: 0.16883281   0.11849063   0.19041875
> 
> Using 14 and 17 as shifts subtantially improve those, but actually
> cause overflows and incorrect decoding of 12bpp content.
> ---
>  libavcodec/simple_idct_template.c | 17 -
>  libavcodec/x86/idctdsp_init.c |  8 +++-
>  libavcodec/x86/simple_idct10.asm  |  7 +++
>  3 files changed, 10 insertions(+), 22 deletions(-)

dct-test -i changes
IDCT SIMPLE-C12: max_err=1 omse=0.11856094 ome=0.00286875 syserr=0.0259 
maxout=288 blockSumErr=64
to
IDCT SIMPLE-C12: max_err=1 omse=0.11825703 ome=0.01024297 syserr=0.05225000 
maxout=288 blockSumErr=64

dct-test -i 2
 5825711334133413341334  582571
   2571  5813341334133413342571  58
 5825713805   -11563805   -1156  582571
   2571  58   -11563805   -115638052571  58
 5825713805   -11563805   -1156  582571
   2571  58   -11563805   -115638052571  58
 5825711334133413341334  582571
   2571  5813341334133413342571  58
IDCT SIMPLE-C12: max_err=1 omse=0.12911875 ome=0.06609375 syserr=0.19025000 
maxout=256 blockSumErr=64
to
   25605073256025602560256025605073
   50732560256025602560256050732560
   256050735031  705031  7025605073
   50732560  705031  70503150732560
   256050735031  705031  7025605073
   50732560  705031  70503150732560
   25605073256025602560256025605073
   50732560256025602560256050732560
IDCT SIMPLE-C12: max_err=1 omse=0.19041875 ome=0.15929375 syserr=0.25365000 
maxout=256 blockSumErr=64

the ome and syserr values worsen by this

iam not objecting to this if thats what people want, just want to
make sure its not missed

also IIUC this is just to make C and x86 match, so it could just be
skiped with no ill effects except that tnen x86 and C would not be
bitexact matches ?


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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [PATCH 2/9] fate: add 10bits YUV4:2:2 test

[James Almer]

On 10/13/2015 5:06 PM, Christophe Gisquet wrote:
> Hi,
> 
> 2015-10-13 21:41 GMT+02:00 James Almer :
>> > This test is failing on pretty much every fate client. Valgrind seems to
>> > complain about uninitialized values.
>> > http://fate.ffmpeg.org/report.cgi?time=20151013040721=x86_64-archlinux-gcc-valgrindundef
> Can someone test the following patch? I don't think the fate results change.
> 
> -- Christophe
> 
> 
> 0001-dnxhdenc-fix-access-outside-of-image.patch
> 
> 
> From 14c1cd9c71af08d2875f6804dc286bc6fcfbf74e Mon Sep 17 00:00:00 2001
> From: Christophe Gisquet 
> Date: Tue, 13 Oct 2015 22:02:41 +0200
> Subject: [PATCH] dnxhdenc: fix access outside of image
> 
> This is the same test as for the 8bit case.
> ---
>  libavcodec/dnxhdenc.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
> index 1e14b8c..f4a7b98 100644
> --- a/libavcodec/dnxhdenc.c
> +++ b/libavcodec/dnxhdenc.c
> @@ -776,11 +776,13 @@ static int dnxhd_mb_var_thread(AVCodecContext *avctx, 
> void *arg,
>  unsigned mb  = mb_y * ctx->m.mb_width + mb_x;
>  int sum = 0;
>  int sqsum = 0;
> +int bw = FFMIN(avctx->width - 16 * mb_x, 16);
> +int bh = FFMIN((avctx->height >> ctx->interlaced) - 16 * mb_y, 
> 16);
>  int mean, sqmean;
>  int i, j;
>  // Macroblocks are 16x16 pixels, unlike DCT blocks which are 8x8.
> -for (i = 0; i < 16; ++i) {
> -for (j = 0; j < 16; ++j) {
> +for (i = 0; i < bh; ++i) {
> +for (j = 0; j < bw; ++j) {
>  // Turn 16-bit pixels into 10-bit ones.
>  int const sample = (unsigned) pix[j] >> 6;
>  sum   += sample;
> -- 2.6.0

Fixes the failure and valgrind errors, so applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 07/10] checkasm: add tests for AES

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 5:55 PM, Henrik Gramner  wrote:
> On Tue, Oct 13, 2015 at 11:28 PM, Ganesh Ajjanagadde  wrote:
>> Not really that important, but unless this increases FATE time
>> significantly, I would recommend a much larger MAX_COUNT, and multiple
>> iterations (e.g #define an ITER_COUNT), so that the testing is more
>> extensive over random inputs.
>
> Each count is in the order of microseconds, but with this kind of
> algorithm I don't see how just iterating over a larger buffer will
> increase the chance of finding any issues.

The random stream will be of longer length, providing more bytes of
data over which aes runs (and thereby covering more bit patterns).
This was my motivation.

> ___
> 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 07/10] checkasm: add tests for AES

[Henrik Gramner]

On Tue, Oct 13, 2015 at 11:28 PM, Ganesh Ajjanagadde  wrote:
> Not really that important, but unless this increases FATE time
> significantly, I would recommend a much larger MAX_COUNT, and multiple
> iterations (e.g #define an ITER_COUNT), so that the testing is more
> extensive over random inputs.

Each count is in the order of microseconds, but with this kind of
algorithm I don't see how just iterating over a larger buffer will
increase the chance of finding any issues.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] simple_idct12: align C and x86

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 6:04 PM, Michael Niedermayer
 wrote:
> On Tue, Oct 13, 2015 at 09:21:40PM +0200, Christophe Gisquet wrote:
>> Results for omse on the 3 idct dct-test.
>>
>> C:   0.16915859   0.11848359   0.12913125
>> x86: 0.16883281   0.11849063   0.19041875
>>
>> Using 14 and 17 as shifts subtantially improve those, but actually
>> cause overflows and incorrect decoding of 12bpp content.
>> ---
>>  libavcodec/simple_idct_template.c | 17 -
>>  libavcodec/x86/idctdsp_init.c |  8 +++-
>>  libavcodec/x86/simple_idct10.asm  |  7 +++
>>  3 files changed, 10 insertions(+), 22 deletions(-)
>
> dct-test -i changes
> IDCT SIMPLE-C12: max_err=1 omse=0.11856094 ome=0.00286875 syserr=0.0259 
> maxout=288 blockSumErr=64
> to
> IDCT SIMPLE-C12: max_err=1 omse=0.11825703 ome=0.01024297 syserr=0.05225000 
> maxout=288 blockSumErr=64
>
> dct-test -i 2
>  5825711334133413341334  582571
>2571  5813341334133413342571  58
>  5825713805   -11563805   -1156  582571
>2571  58   -11563805   -115638052571  58
>  5825713805   -11563805   -1156  582571
>2571  58   -11563805   -115638052571  58
>  5825711334133413341334  582571
>2571  5813341334133413342571  58
> IDCT SIMPLE-C12: max_err=1 omse=0.12911875 ome=0.06609375 syserr=0.19025000 
> maxout=256 blockSumErr=64
> to
>25605073256025602560256025605073
>50732560256025602560256050732560
>256050735031  705031  7025605073
>50732560  705031  70503150732560
>256050735031  705031  7025605073
>50732560  705031  70503150732560
>25605073256025602560256025605073
>50732560256025602560256050732560
> IDCT SIMPLE-C12: max_err=1 omse=0.19041875 ome=0.15929375 syserr=0.25365000 
> maxout=256 blockSumErr=64
>
> the ome and syserr values worsen by this
>
> iam not objecting to this if thats what people want, just want to
> make sure its not missed

I do not object if there is a good reason for why keeping the error
bars the same is not feasible. As a percentage of the original errors,
these changes do not look negligible.

This should be documented as (preferably) commit message + comment, or
at the least in the commit message.

>
> also IIUC this is just to make C and x86 match, so it could just be
> skiped with no ill effects except that tnen x86 and C would not be
> bitexact matches ?
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
>
> ___
> 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] .gitignore: some font temporaries

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 8:13 PM, Michael Niedermayer
 wrote:
> On Sun, Oct 11, 2015 at 04:27:49PM -0400, Ganesh Ajjanagadde wrote:
>> ---
>>  .gitignore | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/.gitignore b/.gitignore
>> index 0b26f68..b215828 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -3,3 +3,4 @@
>>  /htdocs/main.rss
>>  /htdocs/components
>>  /htdocs/style.less
>> +/htdocs/fonts/*.woff2
>
> what generates these woff2 files ?

No idea, and am not a web dev guy so can't really pinpoint it. If it
helps, I get only one such file:
htdocs/fonts/fontawesome-webfont.woff2

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you think the mosad wants you dead since a long time then you are either
> wrong or dead since a long time.
>
> ___
> 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

[FFmpeg-devel] [PATCHv3 1/2] avfilter/all: propagate errors of functions from avfilter/formats

[Ganesh Ajjanagadde]

Hi all,

Attached is a new version reflecting all freedback received so far.

Thanks,
Ganesh
From a218d8274498f67cfbaadc1240dbf2cfe7b20dee Mon Sep 17 00:00:00 2001
From: Ganesh Ajjanagadde 
Date: Sun, 4 Oct 2015 23:39:25 -0400
Subject: [PATCHv3 1/2] avfilter/all: propagate errors of functions from
 avfilter/formats

Many of the functions from avfilter/formats can return errors, usually AVERROR(ENOMEM).
This propagates the return values.

All of these were found by using av_warn_unused_result, demonstrating its utility.
The second patch in this series adds av_warn_unused_result to avfilter/formats.
There are two reasons for this ordering:
1. Applying the other patch first will result in a huge number of noisy
warnings. This patch first corrects the behavior, so that the second
patch does not trigger any "warning regressions".

2. I have currently used av_warn_unused_result liberally in the second
patch, since I see no loss and only benefits as outlined in its
justification. However, a policy should be adopted regarding when to use
av_warn_unused_result, and consensus may be difficult to achieve.

Tested with FATE. I am least sure of the changes to avfilter/filtergraph,
since I don't know what/how reduce_format is intended to behave and how it should
react to errors.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/aeval.c| 28 +--
 libavfilter/af_aformat.c   | 14 ++
 libavfilter/af_agate.c |  3 +-
 libavfilter/af_amerge.c| 21 --
 libavfilter/af_amix.c  |  7 +++--
 libavfilter/af_aresample.c | 29 
 libavfilter/af_astreamsync.c   | 17 +++-
 libavfilter/af_channelmap.c| 17 +---
 libavfilter/af_channelsplit.c  | 17 +++-
 libavfilter/af_earwax.c| 12 
 libavfilter/af_extrastereo.c   | 12 
 libavfilter/af_join.c  | 17 ++--
 libavfilter/af_pan.c   | 20 --
 libavfilter/af_replaygain.c| 20 --
 libavfilter/af_resample.c  | 31 +++--
 libavfilter/af_sidechaincompress.c | 19 -
 libavfilter/af_stereotools.c   | 13 -
 libavfilter/af_stereowiden.c   | 12 
 libavfilter/asrc_anullsrc.c|  8 --
 libavfilter/asrc_flite.c   | 14 ++
 libavfilter/avf_aphasemeter.c  | 21 ++
 libavfilter/avf_avectorscope.c | 21 ++
 libavfilter/avf_concat.c   | 25 +
 libavfilter/avf_showcqt.c  | 21 ++
 libavfilter/avf_showfreqs.c| 21 ++
 libavfilter/avf_showspectrum.c | 21 ++
 libavfilter/avf_showvolume.c   | 21 ++
 libavfilter/avf_showwaves.c| 21 ++
 libavfilter/avfiltergraph.c| 24 
 libavfilter/buffersink.c   | 35 ++--
 libavfilter/buffersrc.c| 24 +---
 libavfilter/drawutils.c|  6 ++--
 libavfilter/f_drawgraph.c  |  6 ++--
 libavfilter/f_ebur128.c| 27 --
 libavfilter/formats.c  | 56 +++---
 libavfilter/src_movie.c| 16 +++
 libavfilter/vf_alphamerge.c| 15 ++
 libavfilter/vf_boxblur.c   |  7 +++--
 libavfilter/vf_crop.c  |  7 +++--
 libavfilter/vf_detelecine.c|  7 +++--
 libavfilter/vf_displace.c  |  3 +-
 libavfilter/vf_elbg.c  |  6 ++--
 libavfilter/vf_extractplanes.c |  8 --
 libavfilter/vf_fieldorder.c|  9 +++---
 libavfilter/vf_frei0r.c|  7 +++--
 libavfilter/vf_hflip.c |  7 +++--
 libavfilter/vf_histogram.c |  7 +++--
 libavfilter/vf_il.c|  8 --
 libavfilter/vf_maskedmerge.c   |  3 +-
 libavfilter/vf_mergeplanes.c   | 15 ++
 libavfilter/vf_neighbor.c  |  3 +-
 libavfilter/vf_noise.c |  7 +++--
 libavfilter/vf_overlay.c   | 28 +++
 libavfilter/vf_palettegen.c|  6 ++--
 libavfilter/vf_paletteuse.c|  8 --
 libavfilter/vf_scale.c |  8 +++---
 libavfilter/vf_showpalette.c   |  6 ++--
 libavfilter/vf_stack.c |  7 +++--
 libavfilter/vf_swapuv.c|  6 ++--
 libavfilter/vf_telecine.c  |  7 +++--
 libavfilter/vf_transpose.c |  7 +++--
 libavfilter/vf_vectorscope.c   |  8 --
 libavfilter/vsrc_life.c|  6 ++--
 63 files changed, 477 insertions(+), 436 deletions(-)

diff --git a/libavfilter/aeval.c b/libavfilter/aeval.c
index b6c420a..ac9dea8 100644
--- a/libavfilter/aeval.c
+++ b/libavfilter/aeval.c
@@ -350,36 +350,34 @@ static int aeval_query_formats(AVFilterContext *ctx)
 static const enum AVSampleFormat sample_fmts[] = {
 AV_SAMPLE_FMT_DBLP, 

Re: [FFmpeg-devel] [PATCH] .gitignore: some font temporaries

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 8:31 PM, Ganesh Ajjanagadde  wrote:
> On Tue, Oct 13, 2015 at 8:13 PM, Michael Niedermayer
>  wrote:
>> On Sun, Oct 11, 2015 at 04:27:49PM -0400, Ganesh Ajjanagadde wrote:
>>> ---
>>>  .gitignore | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/.gitignore b/.gitignore
>>> index 0b26f68..b215828 100644
>>> --- a/.gitignore
>>> +++ b/.gitignore
>>> @@ -3,3 +3,4 @@
>>>  /htdocs/main.rss
>>>  /htdocs/components
>>>  /htdocs/style.less
>>> +/htdocs/fonts/*.woff2
>>
>> what generates these woff2 files ?
>
> No idea, and am not a web dev guy so can't really pinpoint it. If it
> helps, I get only one such file:
> htdocs/fonts/fontawesome-webfont.woff2

Some kind of font compression maybe?
https://github.com/google/woff2
(see the RUN section)

>
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> If you think the mosad wants you dead since a long time then you are either
>> wrong or dead since a long time.
>>
>> ___
>> 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] intmath: remove av_ctz.

[Andreas Cadhalpun]

On 13.10.2015 04:21, Michael Niedermayer wrote:
> On Mon, Oct 12, 2015 at 08:15:10PM +0200, Andreas Cadhalpun wrote:
>> It seems several headers are intended to be installed, but actually aren't:
> 
>> libavutil/des.h:
>>  av_des_alloc
>>  av_des_crypt
>>  av_des_init
>>  av_des_mac
>> libavutil/rc4.h:
>>  av_rc4_alloc
>>  av_rc4_crypt
>>  av_rc4_init
>> libavutil/tree.h
>>  av_tree_destroy
>>  av_tree_enumerate
>>  av_tree_find
>>  av_tree_insert
>>  av_tree_node_alloc
>>  av_tree_node_size
> 
> the ones above are IMHO intended to be public

I sent a patch to install them.

What about libavcodec/avdct.h?
You added it last year in commit 932ff70 with the comment:
"This provides a public sustainable API/ABI for DCT functions."
So I'm pretty sure it should be installed.

I'm not sure about libavformat/avlanguage.h and libavfilter/transform.h.
But since they are not mentioned in APIchanges, they were probably
not intended to be public. Should we just rename the functions to ff_*?

libavcodec/audioconvert.h contains only deprecated stuff.
Since this header isn't installed anymore, it could be removed,
except that FF_API_AVCODEC_RESAMPLE still needs it.
Let's just not bother with this until it gets removed.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Stream specifier enhancement

[Marton Balint]

On Tue, 13 Oct 2015, Bodecs Bela wrote:


Dear Marton Balint,

2015.10.12. 23:07 keltezéssel, Marton Balint írta:


On Mon, 12 Oct 2015, Bodecs Bela wrote:


Dear All,

currently stream specifiers may contain stream index, stream type,
stream id, program id, metadata key/value es usable config settings.
But you can not combine them. In some case, mainly working with
multiprogram mpeg-ts containers as input, this feature would be handy.
This patch makes it possible to combine them.
Examples: p:601:a  will select all audio streams of program 601,
a:m:language:hun will select all audio streams marked by its metadata
as hun language,
p:604:v:0  will select first video stream of program 604,
a:m:language:hun:0 will select 1st audio streams with hun language.
p:403:s:0 will select the first avaiable sub_title tream of program 403,
and p:403:s:m:language:hun:0  will select the first hungarian language
sub_title stream of program 403.  To select first hungarian language
audio stream a:m:language:hun:0
The order of sub-specifiers (program/type/metadata/usable_config) is
arbitrary. So, you may also write v:p:604:0 to select first video stream
of program 604

Please consider to put this enhancement into the official ffmpeg code.


I like the idea, but are you sure just concating the specifiers is a 
good approach?


For example, what will the following mean?

m:language:u

All usable streams with language metadata or streams where the 
language metadata is 'm'?



Thank you for you like my idea.
The current stream specifier syntax is very robust, easy to parse and 
easy to use. I would not introduce any new
syntax for applying multiple criteria in the stream specifier 
expressions. On the other hand, there are only few people,
who really needs this multiple criteria feature. My enhancement does not 
alter the current behaviour in any way.


Are you sure? What if somebody matched a semicolon, or a string which 
contained a semicolon in a metadata value? E.g.: m:timecode:00:00:00:00


So most of the users will not notice anything. But those who really need 
it, they will appreciate it.
So, I think, by making possible to concatenate  specifiers  inside 
stream specifier expressions is a natural way to

extend the current syntax.

Regarding your example: m:language:u
This expression is right in the current applicable syntax, without any 
enhancement. It means "all streams where the language metadata is u"
To select "streams where the language metadata is 'm'? " you should 
write  m:language:m


With my enhancement you can achive to select "All usable streams with 
language metadata" as you wrote:
(more precisely I think you mean: all usable stream where there exists 
language metadata independently its value)


u:m:language  or m:language::u


Sorry, I wasn't clear because I mistyped my question, I wanted to ask for 
a stream with language metadata 'u'.


I was referring to the problematic nature of the optional parameters that 
can/may be interpreted as a different specifier.


How do you specify a usable stream with language metadata?

m:language:u or m:language::u

Apparently in this case the user has to specify the optional parameter as 
well for the metadata (double semicolon) because otherwise it will not 
work. So the parameter is not so optional anymore.


This will also bite you if you want to extend an existing specifier with 
an optional parameter later, the specifier which used to work suddenly 
will not.


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

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 9:12 AM, Ganesh Ajjanagadde  wrote:
> On Tue, Oct 13, 2015 at 4:02 AM, Clément Bœsch  wrote:
>> On Tue, Oct 13, 2015 at 09:25:03AM +0200, Paul B Mahol wrote:
>> [...]
>>> What about fmax/FFMAX?
>>
>> Feel free to try that out (it looks OT regarding the patch), but fmax()
>> looks glibc specific

Seems they are actually ISO:
http://en.cppreference.com/w/c/numeric/math/fmax

Can someone check availability on all of our platforms of interest
(e.g Microsoft)?

>
> Maybe (long term) we can use an av_fabs, av_fabsf, av_fmin/av_fmax (or
> ff_, avpriv_, etc) that pick out the right thing for different
> configurations. It will need something split between configure/header
> guards. I am willing to do this, once everyone is convinced.
>
>>
>> --
>> Clément B.
>>
>> ___
>> 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

[FFmpeg-devel] [PATCH] x86/vp9itxfm: fix register clobbering in ff_vp9_idct_idct_4x4_add_12_sse2

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/x86/vp9itxfm_16bpp.asm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/x86/vp9itxfm_16bpp.asm 
b/libavcodec/x86/vp9itxfm_16bpp.asm
index 06b39ff..902685e 100644
--- a/libavcodec/x86/vp9itxfm_16bpp.asm
+++ b/libavcodec/x86/vp9itxfm_16bpp.asm
@@ -406,7 +406,7 @@ IADST4_FN iadst, IADST4, iadst, IADST4
 %endmacro
 
 INIT_XMM sse2
-cglobal vp9_idct_idct_4x4_add_12, 4, 4, 6, dst, stride, block, eob
+cglobal vp9_idct_idct_4x4_add_12, 4, 4, 8, dst, stride, block, eob
 cmp   eobd, 1
 jg .idctfull
 
-- 
2.6.0

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

Re: [FFmpeg-devel] [PATCH] x86/vp9itxfm: fix register clobbering in ff_vp9_idct_idct_4x4_add_12_sse2

[James Almer]

On 10/13/2015 8:10 PM, Henrik Gramner wrote:
> On Wed, Oct 14, 2015 at 1:04 AM, James Almer  wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/x86/vp9itxfm_16bpp.asm | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/x86/vp9itxfm_16bpp.asm 
>> b/libavcodec/x86/vp9itxfm_16bpp.asm
>> index 06b39ff..902685e 100644
>> --- a/libavcodec/x86/vp9itxfm_16bpp.asm
>> +++ b/libavcodec/x86/vp9itxfm_16bpp.asm
>> @@ -406,7 +406,7 @@ IADST4_FN iadst, IADST4, iadst, IADST4
>>  %endmacro
>>
>>  INIT_XMM sse2
>> -cglobal vp9_idct_idct_4x4_add_12, 4, 4, 6, dst, stride, block, eob
>> +cglobal vp9_idct_idct_4x4_add_12, 4, 4, 8, dst, stride, block, eob
>>  cmp   eobd, 1
>>  jg .idctfull
> 
> Lgtm.

Pushed, thanks.

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

Re: [FFmpeg-devel] [PATCH] ffserver_config: check for INT_MIN before doing FFABS

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 3:45 PM, Michael Niedermayer
 wrote:
> On Fri, Oct 09, 2015 at 11:31:22AM -0400, Ganesh Ajjanagadde wrote:
>> FFABS(INT_MIN) is not safe. Alternative of using FFNABS is not as
>> readable.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  ffserver_config.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> LGTM
>
> thanks

pushed, thanks.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> There will always be a question for which you do not know the correct answer.
>
> ___
> 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] [PATCHv2] avformat/mov: fix integer overflow

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 1:49 PM, Michael Niedermayer
 wrote:
> On Tue, Oct 13, 2015 at 12:26:24PM -0400, Ganesh Ajjanagadde wrote:
>> Partially fixes Ticket 4727.
>>
>> -duration is not a safe expression, since duration can be INT_MIN.
>> One might ask how it can become INT_MIN.
>> Although it is true that line 2574 is no longer reached with INT_MIN due
>> to commit 053e80f6eaf8d87521fe58ea96886b6ee0bbe59d (which fixed another
>> integer overflow issue), mov_update_dts_shift is called on line 3549 as
>> well, right after a read of untrusted data.
>> One can do the fix locally there, but that function is already a huge
>> mess. Changing mov_update_dts_shift is likely better.
>>
>> This changes duration to INT_MIN + 1 in such cases. This should not make any
>> practical difference since such streams are anyway fuzzer files.
>>
>> Tested with FATE.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavformat/mov.c | 4 
>>  1 file changed, 4 insertions(+)
>
> LGTM
>
> thx

pushed and updated ticket, thanks.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many things microsoft did are stupid, but not doing something just because
> microsoft did it is even more stupid. If everything ms did were stupid they
> would be bankrupt already.
>
> ___
> 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

[FFmpeg-devel] [PATCH] avcodec: remove unused avpriv_ac3_parse_header

[Andreas Cadhalpun]

It was replaced by avpriv_ac3_parse_header2.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/ac3_parser.c | 9 -
 libavcodec/ac3_parser.h | 2 --
 2 files changed, 11 deletions(-)

diff --git a/libavcodec/ac3_parser.c b/libavcodec/ac3_parser.c
index 5ab5627..0dd98b9 100644
--- a/libavcodec/ac3_parser.c
+++ b/libavcodec/ac3_parser.c
@@ -151,15 +151,6 @@ int avpriv_ac3_parse_header2(GetBitContext *gbc, 
AC3HeaderInfo **phdr)
 return 0;
 }
 
-int avpriv_ac3_parse_header(GetBitContext *gbc, AC3HeaderInfo *hdr)
-{
-AC3HeaderInfo tmp, *ptmp = 
-int ret = avpriv_ac3_parse_header2(gbc, );
-
-memcpy(hdr, ptmp, ((intptr_t)_layout) - ((intptr_t)) + 
sizeof(uint64_t));
-return ret;
-}
-
 static int ac3_sync(uint64_t state, AACAC3ParseContext *hdr_info,
 int *need_next_header, int *new_frame_start)
 {
diff --git a/libavcodec/ac3_parser.h b/libavcodec/ac3_parser.h
index f37387d..80bc5ef 100644
--- a/libavcodec/ac3_parser.h
+++ b/libavcodec/ac3_parser.h
@@ -39,6 +39,4 @@
  */
 int avpriv_ac3_parse_header2(GetBitContext *gbc, AC3HeaderInfo **hdr);
 
-int avpriv_ac3_parse_header(GetBitContext *gbc, AC3HeaderInfo *hdr);
-
 #endif /* AVCODEC_AC3_PARSER_H */
-- 
2.6.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3] web/src/about: add note on portability

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 12:10 PM, Ganesh Ajjanagadde
 wrote:
> ---
>  src/about | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/about b/src/about
> index 8d8f606..67342a1 100644
> --- a/src/about
> +++ b/src/about
> @@ -4,7 +4,11 @@
>  transcode, mux, demux, 
> stream, filter and play 
> pretty much anything
>that humans and machines have created. It supports the most obscure
>ancient formats up to the cutting edge. No matter if they were
> -  designed by some standards committee, the community or a corporation.
> +  designed by some standards committee, the community or a corporation. It is
> +  also highly portable: FFmpeg compiles, runs, and passes our testing 
> infrastructure
> +  http://fate.ffmpeg.org;>FATE across Linux, Mac OS X,
> +  Microsoft Windows, the BSDs, Solaris, etc. under a wide variety of build
> +  environments, machine architectures, and configurations.
>  
>
>  It contains libavcodec, libavutil, libavformat, libavfilter, 
> libavdevice,
> --
> 2.6.1
>

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

Re: [FFmpeg-devel] [PATCH] avutil: merge avpriv_float_dsp_init into avpriv_float_dsp_alloc

[James Almer]

On 10/13/2015 8:48 PM, Andreas Cadhalpun wrote:
> Also replace the last two usages of avpriv_float_dsp_init with
> avpriv_float_dsp_alloc.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavutil/float_dsp.c | 47 ++-
>  libavutil/float_dsp.h |  9 -
>  2 files changed, 26 insertions(+), 30 deletions(-)
> 
> diff --git a/libavutil/float_dsp.c b/libavutil/float_dsp.c
> index 337708e..c1430f0 100644
> --- a/libavutil/float_dsp.c
> +++ b/libavutil/float_dsp.c
> @@ -116,8 +116,12 @@ float avpriv_scalarproduct_float_c(const float *v1, 
> const float *v2, int len)
>  return p;
>  }
>  
> -av_cold void avpriv_float_dsp_init(AVFloatDSPContext *fdsp, int bit_exact)
> +av_cold AVFloatDSPContext *avpriv_float_dsp_alloc(int bit_exact)
>  {
> +AVFloatDSPContext *fdsp = av_mallocz(sizeof(AVFloatDSPContext));
> +if (!fdsp)
> +return NULL;
> +
>  fdsp->vector_fmul = vector_fmul_c;
>  fdsp->vector_fmac_scalar = vector_fmac_scalar_c;
>  fdsp->vector_fmul_scalar = vector_fmul_scalar_c;
> @@ -138,14 +142,7 @@ av_cold void avpriv_float_dsp_init(AVFloatDSPContext 
> *fdsp, int bit_exact)
>  ff_float_dsp_init_x86(fdsp);
>  if (ARCH_MIPS)
>  ff_float_dsp_init_mips(fdsp);
> -}
> -
> -av_cold AVFloatDSPContext *avpriv_float_dsp_alloc(int bit_exact)
> -{
> -AVFloatDSPContext *ret = av_mallocz(sizeof(AVFloatDSPContext));
> -if (ret)
> -avpriv_float_dsp_init(ret, bit_exact);
> -return ret;
> +return fdsp;
>  }
>  
>  
> @@ -386,7 +383,7 @@ int main(int argc, char **argv)
>  {
>  int ret = 0, seeded = 0;
>  uint32_t seed;
> -AVFloatDSPContext fdsp, cdsp;
> +AVFloatDSPContext *fdsp, *cdsp;
>  AVLFG lfg;
>  
>  LOCAL_ALIGNED(32, float, src0, [LEN]);
> @@ -430,29 +427,37 @@ int main(int argc, char **argv)
>  fill_double_array(, dbl_src0, LEN);
>  fill_double_array(, dbl_src1, LEN);
>  
> -avpriv_float_dsp_init(, 1);
> +fdsp = avpriv_float_dsp_alloc(1);
>  av_force_cpu_flags(0);
> -avpriv_float_dsp_init(, 1);
> +cdsp = avpriv_float_dsp_alloc(1);
> +
> +if (!fdsp || !cdsp) {
> +ret = 1;
> +goto end;
> +}

This could go above the av_log or av_lfg_init lines, to avoid pointlessly
running all the array filling code when the test is going to fail anyway.

LGTM nonetheless.

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

Re: [FFmpeg-devel] [PATCH 2/9] fate: add 10bits YUV4:2:2 test

[Michael Niedermayer]

On Tue, Oct 13, 2015 at 04:41:50PM -0300, James Almer wrote:
> On 10/12/2015 11:04 PM, Michael Niedermayer wrote:
> > On Tue, Oct 13, 2015 at 12:00:07AM +0200, Michael Niedermayer wrote:
> >> On Mon, Oct 12, 2015 at 10:39:23PM +0200, Christophe Gisquet wrote:
> >>> Le 12 oct. 2015 21:37, "Michael Niedermayer"  a
> >>> écrit :
> 
>  On Mon, Oct 12, 2015 at 07:37:43PM +0200, Christophe Gisquet wrote:
> > It was useful to (accidentally?) spot an overflow in the column pass
> > of the x86 simple_idct10 implementation.
> > ---
> >  tests/fate/vcodec.mak  | 6 +-
> >  tests/ref/vsynth/vsynth1-dnxhd-1080i-10bit | 4 
> >  tests/ref/vsynth/vsynth2-dnxhd-1080i-10bit | 4 
> >  tests/ref/vsynth/vsynth3-dnxhd-1080i-10bit | 4 
> >  tests/ref/vsynth/vsynth_lena-dnxhd-1080i-10bit | 4 
> >  5 files changed, 21 insertions(+), 1 deletion(-)
> >  create mode 100644 tests/ref/vsynth/vsynth1-dnxhd-1080i-10bit
> >  create mode 100644 tests/ref/vsynth/vsynth2-dnxhd-1080i-10bit
> >  create mode 100644 tests/ref/vsynth/vsynth3-dnxhd-1080i-10bit
> >  create mode 100644 tests/ref/vsynth/vsynth_lena-dnxhd-1080i-10bit
> 
>  this alone and with patch 1 doesnt pass fate:
> >>>
> >>> I'm so bad at this codec stuff.
> >>
> >> no, you are not, this stuff is rather convoluted and the mpegvideo
> >> *dct stuff is not well documented.
> >>
> >> I think the patchset is mostly fine, ill retest things and will try to
> >> fix the remaining issues (if iam able to) and if successfull ill apply
> > 
> > 
> >> it i think this one patch here is fine as is if its applied later in
> > 
> > wasnt that easy, there was another difference, between 32 and 64bit
> > it may be float rounding in the scaler but its not dnxhd i worked
> > around it by adjusting the scaler parameters.
> 
> This test is failing on pretty much every fate client. Valgrind seems to
> complain about uninitialized values.
> http://fate.ffmpeg.org/report.cgi?time=20151013040721=x86_64-archlinux-gcc-valgrindundef

this is different from the failure i saw
mine was vsynth3 and didnt show anything in valgrind on my box

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

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] [PATCH] x86/vp9itxfm: fix register clobbering in ff_vp9_idct_idct_4x4_add_12_sse2

[Henrik Gramner]

On Wed, Oct 14, 2015 at 1:04 AM, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/x86/vp9itxfm_16bpp.asm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/x86/vp9itxfm_16bpp.asm 
> b/libavcodec/x86/vp9itxfm_16bpp.asm
> index 06b39ff..902685e 100644
> --- a/libavcodec/x86/vp9itxfm_16bpp.asm
> +++ b/libavcodec/x86/vp9itxfm_16bpp.asm
> @@ -406,7 +406,7 @@ IADST4_FN iadst, IADST4, iadst, IADST4
>  %endmacro
>
>  INIT_XMM sse2
> -cglobal vp9_idct_idct_4x4_add_12, 4, 4, 6, dst, stride, block, eob
> +cglobal vp9_idct_idct_4x4_add_12, 4, 4, 8, dst, stride, block, eob
>  cmp   eobd, 1
>  jg .idctfull

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

Re: [FFmpeg-devel] [PATCH] avutil: install des.h, rc4.h and tree.h as public headers

[James Almer]

On 10/13/2015 7:37 PM, Andreas Cadhalpun wrote:
> These headers contain functions supposed to be public.
> 
> libavutil/des.h:
>  av_des_alloc
>  av_des_crypt
>  av_des_init
>  av_des_mac
> libavutil/rc4.h:
>  av_rc4_alloc
>  av_rc4_crypt
>  av_rc4_init

Since these two were never installed, we can remove the FF_API_CRYPTO_CONTEXT
wrapper from them before applying this patch, as this would be the first time
the API becomes public.

Now, what i want to know is what will it be in the end for the actual
deprecation in question? Reimar and Nicolas were against making the context
opaque as having them in stack has its uses.
I want to know what people want, since the deprecation is not present on any
release and we still have time to rollback. Do we keep the deprecation in
place for des, rc4, blowfish and xtea, or remove it altogether?

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

[FFmpeg-devel] [PATCH] avutil: merge avpriv_float_dsp_init into avpriv_float_dsp_alloc

[Andreas Cadhalpun]

Also replace the last two usages of avpriv_float_dsp_init with
avpriv_float_dsp_alloc.

Signed-off-by: Andreas Cadhalpun 
---
 libavutil/float_dsp.c | 47 ++-
 libavutil/float_dsp.h |  9 -
 2 files changed, 26 insertions(+), 30 deletions(-)

diff --git a/libavutil/float_dsp.c b/libavutil/float_dsp.c
index 337708e..c1430f0 100644
--- a/libavutil/float_dsp.c
+++ b/libavutil/float_dsp.c
@@ -116,8 +116,12 @@ float avpriv_scalarproduct_float_c(const float *v1, const 
float *v2, int len)
 return p;
 }
 
-av_cold void avpriv_float_dsp_init(AVFloatDSPContext *fdsp, int bit_exact)
+av_cold AVFloatDSPContext *avpriv_float_dsp_alloc(int bit_exact)
 {
+AVFloatDSPContext *fdsp = av_mallocz(sizeof(AVFloatDSPContext));
+if (!fdsp)
+return NULL;
+
 fdsp->vector_fmul = vector_fmul_c;
 fdsp->vector_fmac_scalar = vector_fmac_scalar_c;
 fdsp->vector_fmul_scalar = vector_fmul_scalar_c;
@@ -138,14 +142,7 @@ av_cold void avpriv_float_dsp_init(AVFloatDSPContext 
*fdsp, int bit_exact)
 ff_float_dsp_init_x86(fdsp);
 if (ARCH_MIPS)
 ff_float_dsp_init_mips(fdsp);
-}
-
-av_cold AVFloatDSPContext *avpriv_float_dsp_alloc(int bit_exact)
-{
-AVFloatDSPContext *ret = av_mallocz(sizeof(AVFloatDSPContext));
-if (ret)
-avpriv_float_dsp_init(ret, bit_exact);
-return ret;
+return fdsp;
 }
 
 
@@ -386,7 +383,7 @@ int main(int argc, char **argv)
 {
 int ret = 0, seeded = 0;
 uint32_t seed;
-AVFloatDSPContext fdsp, cdsp;
+AVFloatDSPContext *fdsp, *cdsp;
 AVLFG lfg;
 
 LOCAL_ALIGNED(32, float, src0, [LEN]);
@@ -430,29 +427,37 @@ int main(int argc, char **argv)
 fill_double_array(, dbl_src0, LEN);
 fill_double_array(, dbl_src1, LEN);
 
-avpriv_float_dsp_init(, 1);
+fdsp = avpriv_float_dsp_alloc(1);
 av_force_cpu_flags(0);
-avpriv_float_dsp_init(, 1);
+cdsp = avpriv_float_dsp_alloc(1);
+
+if (!fdsp || !cdsp) {
+ret = 1;
+goto end;
+}
 
-if (test_vector_fmul(, , src0, src1))
+if (test_vector_fmul(fdsp, cdsp, src0, src1))
 ret -= 1 << 0;
-if (test_vector_fmac_scalar(, , src2, src0, src1[0]))
+if (test_vector_fmac_scalar(fdsp, cdsp, src2, src0, src1[0]))
 ret -= 1 << 1;
-if (test_vector_fmul_scalar(, , src0, src1[0]))
+if (test_vector_fmul_scalar(fdsp, cdsp, src0, src1[0]))
 ret -= 1 << 2;
-if (test_vector_fmul_window(, , src0, src1, src2))
+if (test_vector_fmul_window(fdsp, cdsp, src0, src1, src2))
 ret -= 1 << 3;
-if (test_vector_fmul_add(, , src0, src1, src2))
+if (test_vector_fmul_add(fdsp, cdsp, src0, src1, src2))
 ret -= 1 << 4;
-if (test_vector_fmul_reverse(, , src0, src1))
+if (test_vector_fmul_reverse(fdsp, cdsp, src0, src1))
 ret -= 1 << 5;
-if (test_butterflies_float(, , src0, src1))
+if (test_butterflies_float(fdsp, cdsp, src0, src1))
 ret -= 1 << 6;
-if (test_scalarproduct_float(, , src0, src1))
+if (test_scalarproduct_float(fdsp, cdsp, src0, src1))
 ret -= 1 << 7;
-if (test_vector_dmul_scalar(, , dbl_src0, dbl_src1[0]))
+if (test_vector_dmul_scalar(fdsp, cdsp, dbl_src0, dbl_src1[0]))
 ret -= 1 << 8;
 
+end:
+av_freep();
+av_freep();
 return ret;
 }
 
diff --git a/libavutil/float_dsp.h b/libavutil/float_dsp.h
index ad8e3eb..d1be38f 100644
--- a/libavutil/float_dsp.h
+++ b/libavutil/float_dsp.h
@@ -170,15 +170,6 @@ typedef struct AVFloatDSPContext {
  */
 float avpriv_scalarproduct_float_c(const float *v1, const float *v2, int len);
 
-/**
- * Initialize a float DSP context.
- *
- * @param fdspfloat DSP context
- * @param strict  setting to non-zero avoids using functions which may not be 
IEEE-754 compliant
- */
-void avpriv_float_dsp_init(AVFloatDSPContext *fdsp, int strict);
-
-
 void ff_float_dsp_init_aarch64(AVFloatDSPContext *fdsp);
 void ff_float_dsp_init_arm(AVFloatDSPContext *fdsp);
 void ff_float_dsp_init_ppc(AVFloatDSPContext *fdsp, int strict);
-- 
2.6.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 8:58 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Tue, Oct 13, 2015 at 8:09 PM, Ganesh Ajjanagadde 
> wrote:
>
>> On Tue, Oct 13, 2015 at 2:45 AM, Clément Bœsch  wrote:
>> > On Tue, Oct 13, 2015 at 12:31:10AM -0400, Ganesh Ajjanagadde wrote:
>> >> On Tue, Oct 13, 2015 at 12:26 AM, Ganesh Ajjanagadde 
>> wrote:
>> >> > On Tue, Oct 13, 2015 at 12:16 AM, Carl Eugen Hoyos 
>> wrote:
>> >> >> Ganesh Ajjanagadde  mit.edu> writes:
>> >> >>
>> >> >>> Bench from libavfilter/astats on a 15 min clip.
>> >> >>
>> >> >> I believe that your test would indicate that the
>> >> >> old variant is faster or that no result can be
>> >> >> given which is what my tests show.
>> >>
>> >> Also, how you can possibly believe that the old variant is faster is
>> >> beyond me given the astonishing amount of work by Intel, Red Hat, and
>> >> others to create the absolutely best performing libc.
>> >>
>> >> Just have a look at
>> >>
>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_sin.c;hb=HEAD#l281
>> ,
>> >> it gives an idea of the extreme lengths they go to.
>> >>
>> >
>> >
>> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_fabs.c;hb=HEAD
>> >
>> > [/tmp]☭ cat a.c
>> > #include 
>> > #include 
>> >
>> > #define FFABS(a) ((a) >= 0 ? (a) : (-(a)))
>> >
>> > double f1d(double x) { return fabs(x); }
>> > double f2d(double x) { return FFABS(x); }
>> >
>> > int f1i(int x) { return abs(x); }
>> > int f2i(int x) { return FFABS(x); }
>> > [/tmp]☭ gcc -O2 -c a.c && objdump -d -Mintel a.o
>> >
>> > a.o: file format elf64-x86-64
>> >
>> >
>> > Disassembly of section .text:
>> >
>> >  :
>> >0:   f2 0f 10 0d 00 00 00movsd  xmm1,QWORD PTR [rip+0x0]#
>> 8 
>> >7:   00
>> >8:   66 0f 54 c1 andpd  xmm0,xmm1
>> >c:   c3  ret
>> >d:   0f 1f 00nopDWORD PTR [rax]
>> >
>> > 0010 :
>> >   10:   66 0f 2e 05 00 00 00ucomisd xmm0,QWORD PTR [rip+0x0]
>> # 18 
>> >   17:   00
>> >   18:   72 06   jb 20 
>> >   1a:   f3 c3   repz ret
>> >   1c:   0f 1f 40 00 nopDWORD PTR [rax+0x0]
>> >   20:   f2 0f 10 0d 00 00 00movsd  xmm1,QWORD PTR [rip+0x0]#
>> 28 
>> >   27:   00
>> >   28:   66 0f 57 c1 xorpd  xmm0,xmm1
>> >   2c:   c3  ret
>> >   2d:   0f 1f 00nopDWORD PTR [rax]
>> >
>> > 0030 :
>> >   30:   89 fa   movedx,edi
>> >   32:   89 f8   moveax,edi
>> >   34:   c1 fa 1fsaredx,0x1f
>> >   37:   31 d0   xoreax,edx
>> >   39:   29 d0   subeax,edx
>> >   3b:   c3  ret
>> >   3c:   0f 1f 40 00 nopDWORD PTR [rax+0x0]
>> >
>> > 0040 :
>> >   40:   89 fa   movedx,edi
>> >   42:   89 f8   moveax,edi
>> >   44:   c1 fa 1fsaredx,0x1f
>> >   47:   31 d0   xoreax,edx
>> >   49:   29 d0   subeax,edx
>> >   4b:   c3  ret
>> > [/tmp]☭
>> >
>> > So fabs() is inlined by the compiler (gcc 5.2.0 here), while abs() is
>> > essentially identical to FFABS().
>> >
>> > I have similar results with clang (3.7.0).
>> >
>> > Conclusion: using fabs() looks better with at least recent versions of
>> clang
>> > and GCC on x86-64 (but may introduce slight behaviour changes?)
>> >
>> > To be more rigorous, it would be interesting to compare on different
>> arch &
>> > compilers, but changing FFABS() with fabs() sounds OK to me.
>>
>> I noticed that is being applied piecemeal, and some of it has been
>> pushed. Does that mean I am free to push (with the reduced commit
>> message) as well?
>
>
> You'll notice that Paul did it for the filters he maintains. I'm fine with
> you doing this for any code I maintain (no further review required). You
> can find maintainers for each piece of code in git log or MAINTAINERS. It
> sounds like Paul is fine with this also. I think the general case, it'd be
> nice to figure out why Carl's results are slightly different from yours (or
> maybe it's noise?). If we can resolve that, I don't think there's any
> further outstanding objections, right?

No other outstanding objections - the only serious concern is
availability (which is a non-issue since we were already using fabs,
fabsf sporadically). Carl's issues should be either noise, or a
bad/slow libc fabs implementation. Hence I requested him for his
config.

I will give respective maintainers a week for slowly adding this
stuff. To reiterate, I have not touched avcodec as it is mostly
integer math anyway - if someone could point out some "hotspots" in
avcodec with this issue, that would be great.

>
> Also, 

Re: [FFmpeg-devel] [PATCH] .gitignore: some font temporaries

[Timothy Gu]

El martes, 13 de octubre de 2015, Michael Niedermayer
 escribió:

> On Sun, Oct 11, 2015 at 04:27:49PM -0400, Ganesh Ajjanagadde wrote:
> > ---
> >  .gitignore | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/.gitignore b/.gitignore
> > index 0b26f68..b215828 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -3,3 +3,4 @@
> >  /htdocs/main.rss
> >  /htdocs/components
> >  /htdocs/style.less
> > +/htdocs/fonts/*.woff2
>
> what generates these woff2 files ?


They are first installed to htdocs/ components with Bower (a local package
manager for the web) and then copied to htdocs/:
https://github.com/FFmpeg/web/blob/master/Makefile#L64

Patch LGTM.

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

Re: [FFmpeg-devel] [PATCH] .gitignore: some font temporaries

[Ganesh Ajjanagadde]

On Tue, Oct 13, 2015 at 9:20 PM, Timothy Gu  wrote:
> El martes, 13 de octubre de 2015, Michael Niedermayer
>  escribió:
>
>> On Sun, Oct 11, 2015 at 04:27:49PM -0400, Ganesh Ajjanagadde wrote:
>> > ---
>> >  .gitignore | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/.gitignore b/.gitignore
>> > index 0b26f68..b215828 100644
>> > --- a/.gitignore
>> > +++ b/.gitignore
>> > @@ -3,3 +3,4 @@
>> >  /htdocs/main.rss
>> >  /htdocs/components
>> >  /htdocs/style.less
>> > +/htdocs/fonts/*.woff2
>>
>> what generates these woff2 files ?
>
>
> They are first installed to htdocs/ components with Bower (a local package
> manager for the web) and then copied to htdocs/:
> https://github.com/FFmpeg/web/blob/master/Makefile#L64
>
> Patch LGTM.

Go ahead and push - I believe I do have write privileges for
ffmpeg-web, but since I am not a web dev and have limited experience
with managing websites, it will be a few months before I feel
comfortable pushing on my own. Thanks for the info.

>
> Timothy
> ___
> 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 3/3][RFC] avfilter/vf_chromakey: Add OpenCL acceleration

[Wei Gao]

2015-10-13 18:27 GMT+08:00 Timo Rothenpieler :

> Hi
>>
>> I use your filter, but the kernel can't pass the compile, you should
>> consider the "double" type in the kernel, some GPU card does not support
>> double type
>> I add "#pragma OPENCL_EXTENSION cl_khr_fp64: enable " to the kernel, but
>> it does not works
>>
>> I will check the error tomorrow
>>
>
> I tested this filter on Nvidia on Linux, using driver 355 and on the Intel
> CPU-based OpenCL SDK so far.
> Using floats potentially has an impact on the keying quality.
>
Hi

I have check the error, for some card, yes, just like what I said above,
some cards does not support double type, so we must check the opencl
extension: cl_khr_fp64 before the kernel compile. If the device support, we
use GPU, else, we use CPU or use float type, Is it OK?

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