date:20160216

[FFmpeg-devel] Debugging option

2016-02-16 Thread Chau Pham

Good morning !!


I just compiled debug version of ffmpeg in linux ubuntu with eclipse


with options:


--disable-stripping

--enable-debug=3

--extra-cflags="-gstabs+"

--disable-optimizations



after compiling ,I can debug ffmpeg.c but only inside ffmpeg.c, debug cannot go 
into outside of ffmpeg.c


what option can enable debugging go to whole project?


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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/avienc: reformat raw rgb to comply to specs

2016-02-16 Thread Mats Peterson


On 02/17/2016 04:56 AM, Mats Peterson wrote:

On 02/17/2016 04:48 AM, Mats Peterson wrote:


AVI has support for palette switching by using the 'xxpc' chunk in the
video data for the record, but it hasn't been implemented yet. I suppose
it's enough to just add an "initial" palette to the BITMAPINFOHEADER in
the meantime.

Mats




And that should be done for 1 bpp AVI as well (using 2 palette entries).



It should be done for any bit depth <= 8 bpp, at that, using 2^bitdepth 
palette entries.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/avienc: reformat raw rgb to comply to specs

2016-02-16 Thread Mats Peterson


On 02/17/2016 04:48 AM, Mats Peterson wrote:


AVI has support for palette switching by using the 'xxpc' chunk in the
video data for the record, but it hasn't been implemented yet. I suppose
it's enough to just add an "initial" palette to the BITMAPINFOHEADER in
the meantime.

Mats




And that should be done for 1 bpp AVI as well (using 2 palette entries).

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/avienc: reformat raw rgb to comply to specs

2016-02-16 Thread Mats Peterson


On 02/17/2016 04:38 AM, Mats Peterson wrote:

Michael Niedermayer  skrev: (17 februari 2016 03:50:58 
CET)

@todo move to seperate file and reuse in movenc

Signed-off-by: Michael Niedermayer 
---
libavformat/avienc.c  |   40

tests/ref/vsynth/vsynth3-bpp1 |4 ++--
tests/ref/vsynth/vsynth3-rgb  |4 ++--
3 files changed, 44 insertions(+), 4 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 649961d..b9aee37 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -644,6 +644,38 @@ static int write_skip_frames(AVFormatContext *s,
int stream_index, int64_t dts)
 return 0;
}

+static int write_reshuffled_raw_rgb(AVFormatContext *s, AVPacket *pkt,
AVCodecContext *enc, int expected_stride)
+{
+int ret;
+AVPacket *new_pkt = av_packet_alloc();
+int stride = pkt->size / enc->height;
+int padding = expected_stride - FFMIN(expected_stride, stride);
+int y;
+
+if (!new_pkt)
+return AVERROR(ENOMEM);
+
+ret = av_new_packet(new_pkt, expected_stride * enc->height);
+if (ret < 0)
+goto end;
+
+ret = av_packet_copy_props(new_pkt, pkt);
+if (ret < 0)
+goto end;
+
+for (y = 0; yheight; y++) {
+memcpy(new_pkt->data + y*expected_stride, pkt->data +
y*stride, FFMIN(expected_stride, stride));
+memset(new_pkt->data + y*expected_stride + expected_stride -
padding, 0, padding);
+}
+
+ret = avi_write_packet(s, new_pkt);
+
+end:
+av_packet_free(_pkt);
+
+return ret;
+}
+
static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
{
 unsigned char tag[5];
@@ -661,6 +693,14 @@ static int avi_write_packet(AVFormatContext *s,
AVPacket *pkt)
 if (ret < 0)
 return ret;
 }
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0)
{
+int64_t bpc = enc->bits_per_coded_sample != 15 ?
enc->bits_per_coded_sample : 16;
+int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
+int stride = (enc->width * bpc + 7) >> 3;
+if (expected_stride * enc->height != pkt->size &&
+stride * enc->height == pkt->size)
+return write_reshuffled_raw_rgb(s, pkt, enc,
expected_stride);
+}

 if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
 return ret;
diff --git a/tests/ref/vsynth/vsynth3-bpp1
b/tests/ref/vsynth/vsynth3-bpp1
index 5a65728..39f27f3 100644
--- a/tests/ref/vsynth/vsynth3-bpp1
+++ b/tests/ref/vsynth/vsynth3-bpp1
@@ -1,4 +1,4 @@
-98852649c5201df7d85d0e9b5a5b9f15 *tests/data/fate/vsynth3-bpp1.avi
-15352 tests/data/fate/vsynth3-bpp1.avi
+d5689d1f5c2d4c28a345d5964a6161a8 *tests/data/fate/vsynth3-bpp1.avi
+20452 tests/data/fate/vsynth3-bpp1.avi
0b1ea21b69d384564dd3a978065443b2
*tests/data/fate/vsynth3-bpp1.out.rawvideo
stddev:   97.64 PSNR:  8.34 MAXDIFF:  248 bytes:86700/86700
diff --git a/tests/ref/vsynth/vsynth3-rgb
b/tests/ref/vsynth/vsynth3-rgb
index c0a8563..f67d285 100644
--- a/tests/ref/vsynth/vsynth3-rgb
+++ b/tests/ref/vsynth/vsynth3-rgb
@@ -1,4 +1,4 @@
-a2cb86007b8945e2d1399b56585b983a *tests/data/fate/vsynth3-rgb.avi
-180252 tests/data/fate/vsynth3-rgb.avi
+000bd5f3251bfd6a2a2b590b2d16fe0b *tests/data/fate/vsynth3-rgb.avi
+183652 tests/data/fate/vsynth3-rgb.avi
693aff10c094f8bd31693f74cf79d2b2
*tests/data/fate/vsynth3-rgb.out.rawvideo
stddev:3.67 PSNR: 36.82 MAXDIFF:   43 bytes:86700/86700
--
1.7.9.5

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


Splendid job, Michael. Now only to properly attach the palette to the 
BITMAPINFOHEADER in the strf chunk for AVI. And include it in the video sample 
description for QuickTime.

Mats



AVI has support for palette switching by using the 'xxpc' chunk in the 
video data for the record, but it hasn't been implemented yet. I suppose 
it's enough to just add an "initial" palette to the BITMAPINFOHEADER in 
the meantime.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/avienc: reformat raw rgb to comply to specs

2016-02-16 Thread Mats Peterson

Michael Niedermayer  skrev: (17 februari 2016 03:50:58 
CET)
>@todo move to seperate file and reuse in movenc
>
>Signed-off-by: Michael Niedermayer 
>---
>libavformat/avienc.c  |   40
>
> tests/ref/vsynth/vsynth3-bpp1 |4 ++--
> tests/ref/vsynth/vsynth3-rgb  |4 ++--
> 3 files changed, 44 insertions(+), 4 deletions(-)
>
>diff --git a/libavformat/avienc.c b/libavformat/avienc.c
>index 649961d..b9aee37 100644
>--- a/libavformat/avienc.c
>+++ b/libavformat/avienc.c
>@@ -644,6 +644,38 @@ static int write_skip_frames(AVFormatContext *s,
>int stream_index, int64_t dts)
> return 0;
> }
> 
>+static int write_reshuffled_raw_rgb(AVFormatContext *s, AVPacket *pkt,
>AVCodecContext *enc, int expected_stride)
>+{
>+int ret;
>+AVPacket *new_pkt = av_packet_alloc();
>+int stride = pkt->size / enc->height;
>+int padding = expected_stride - FFMIN(expected_stride, stride);
>+int y;
>+
>+if (!new_pkt)
>+return AVERROR(ENOMEM);
>+
>+ret = av_new_packet(new_pkt, expected_stride * enc->height);
>+if (ret < 0)
>+goto end;
>+
>+ret = av_packet_copy_props(new_pkt, pkt);
>+if (ret < 0)
>+goto end;
>+
>+for (y = 0; yheight; y++) {
>+memcpy(new_pkt->data + y*expected_stride, pkt->data +
>y*stride, FFMIN(expected_stride, stride));
>+memset(new_pkt->data + y*expected_stride + expected_stride -
>padding, 0, padding);
>+}
>+
>+ret = avi_write_packet(s, new_pkt);
>+
>+end:
>+av_packet_free(_pkt);
>+
>+return ret;
>+}
>+
> static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
> {
> unsigned char tag[5];
>@@ -661,6 +693,14 @@ static int avi_write_packet(AVFormatContext *s,
>AVPacket *pkt)
> if (ret < 0)
> return ret;
> }
>+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0)
>{
>+int64_t bpc = enc->bits_per_coded_sample != 15 ?
>enc->bits_per_coded_sample : 16;
>+int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
>+int stride = (enc->width * bpc + 7) >> 3;
>+if (expected_stride * enc->height != pkt->size &&
>+stride * enc->height == pkt->size)
>+return write_reshuffled_raw_rgb(s, pkt, enc,
>expected_stride);
>+}
> 
> if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
> return ret;
>diff --git a/tests/ref/vsynth/vsynth3-bpp1
>b/tests/ref/vsynth/vsynth3-bpp1
>index 5a65728..39f27f3 100644
>--- a/tests/ref/vsynth/vsynth3-bpp1
>+++ b/tests/ref/vsynth/vsynth3-bpp1
>@@ -1,4 +1,4 @@
>-98852649c5201df7d85d0e9b5a5b9f15 *tests/data/fate/vsynth3-bpp1.avi
>-15352 tests/data/fate/vsynth3-bpp1.avi
>+d5689d1f5c2d4c28a345d5964a6161a8 *tests/data/fate/vsynth3-bpp1.avi
>+20452 tests/data/fate/vsynth3-bpp1.avi
>0b1ea21b69d384564dd3a978065443b2
>*tests/data/fate/vsynth3-bpp1.out.rawvideo
> stddev:   97.64 PSNR:  8.34 MAXDIFF:  248 bytes:86700/86700
>diff --git a/tests/ref/vsynth/vsynth3-rgb
>b/tests/ref/vsynth/vsynth3-rgb
>index c0a8563..f67d285 100644
>--- a/tests/ref/vsynth/vsynth3-rgb
>+++ b/tests/ref/vsynth/vsynth3-rgb
>@@ -1,4 +1,4 @@
>-a2cb86007b8945e2d1399b56585b983a *tests/data/fate/vsynth3-rgb.avi
>-180252 tests/data/fate/vsynth3-rgb.avi
>+000bd5f3251bfd6a2a2b590b2d16fe0b *tests/data/fate/vsynth3-rgb.avi
>+183652 tests/data/fate/vsynth3-rgb.avi
>693aff10c094f8bd31693f74cf79d2b2
>*tests/data/fate/vsynth3-rgb.out.rawvideo
> stddev:3.67 PSNR: 36.82 MAXDIFF:   43 bytes:86700/86700
>-- 
>1.7.9.5
>
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Splendid job, Michael. Now only to properly attach the palette to the 
BITMAPINFOHEADER in the strf chunk for AVI. And include it in the video sample 
description for QuickTime.

Mats
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] swscale/x86/output: Fix yuv2planeX_16* with unaligned destination

2016-02-16 Thread Michael Niedermayer

Signed-off-by: Michael Niedermayer 
---
 libswscale/x86/output.asm |   23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/libswscale/x86/output.asm b/libswscale/x86/output.asm
index 9570969..133817c 100644
--- a/libswscale/x86/output.asm
+++ b/libswscale/x86/output.asm
@@ -54,8 +54,8 @@ SECTION .text
 ; int32_t if $output_size is 16. $filter is 12-bits. $filterSize is a multiple
 ; of 2. $offset is either 0 or 3. $dither holds 8 values.
 ;-
-%macro yuv2planeX_mainloop 1
-.pixelloop:
+%macro yuv2planeX_mainloop 2
+.pixelloop_%2:
 %assign %%i 0
 ; the rep here is for the 8bit output mmx case, where dither covers
 ; 8 pixels but we can only handle 2 pixels per register, and thus 4
@@ -82,7 +82,7 @@ SECTION .text
 movam2,  m1
 %endif ; %1 == 8/9/10/16
 movsx cntr_reg,  fltsizem
-.filterloop_ %+ %%i:
+.filterloop_%2_ %+ %%i:
 ; input pixels
 mov r6, [srcq+gprsize*cntr_reg-2*gprsize]
 %if %1 == 16
@@ -129,7 +129,7 @@ SECTION .text
 %endif ; %1 == 8/9/10/16
 
 sub   cntr_reg,  2
-jg .filterloop_ %+ %%i
+jg .filterloop_%2_ %+ %%i
 
 %if %1 == 16
 psrad   m2,  31 - %1
@@ -156,7 +156,7 @@ SECTION .text
 %endif ; mmxext/sse2/sse4/avx
 pminsw  m2, [yuv2yuvX_%1_upper]
 %endif ; %1 == 9/10/16
-mova   [dstq+r5*2],  m2
+mov%2   [dstq+r5*2],  m2
 %endif ; %1 == 8/9/10/16
 
 add r5,  mmsize/2
@@ -164,7 +164,7 @@ SECTION .text
 
 %assign %%i %%i+2
 %endrep
-jg .pixelloop
+jg .pixelloop_%2
 %endmacro
 
 %macro yuv2planeX_fn 3
@@ -235,7 +235,16 @@ cglobal yuv2planeX_%1, %3, 8, %2, filter, fltsize, src, 
dst, w, dither, offset
 
 xor r5,  r5
 
-yuv2planeX_mainloop %1
+%if mmsize == 8 || %1 == 8
+yuv2planeX_mainloop %1, a
+%else ; mmsize == 16
+test  dstq, 15
+jnz .unaligned
+yuv2planeX_mainloop %1, a
+REP_RET
+.unaligned:
+yuv2planeX_mainloop %1, u
+%endif ; mmsize == 8/16
 
 %if %1 == 8
 %if ARCH_X86_32
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 1/2] swscale/x86/output: Move code into yuv2planeX_mainloop

2016-02-16 Thread Michael Niedermayer

Signed-off-by: Michael Niedermayer 
---
 libswscale/x86/output.asm |  141 +++--
 1 file changed, 72 insertions(+), 69 deletions(-)

diff --git a/libswscale/x86/output.asm b/libswscale/x86/output.asm
index 9ea4af9..9570969 100644
--- a/libswscale/x86/output.asm
+++ b/libswscale/x86/output.asm
@@ -54,75 +54,7 @@ SECTION .text
 ; int32_t if $output_size is 16. $filter is 12-bits. $filterSize is a multiple
 ; of 2. $offset is either 0 or 3. $dither holds 8 values.
 ;-
-
-%macro yuv2planeX_fn 3
-
-%if ARCH_X86_32
-%define cntr_reg fltsizeq
-%define movsx mov
-%else
-%define cntr_reg r7
-%define movsx movsxd
-%endif
-
-cglobal yuv2planeX_%1, %3, 8, %2, filter, fltsize, src, dst, w, dither, offset
-%if %1 == 8 || %1 == 9 || %1 == 10
-pxorm6,  m6
-%endif ; %1 == 8/9/10
-
-%if %1 == 8
-%if ARCH_X86_32
-%assign pad 0x2c - (stack_offset & 15)
-SUB rsp, pad
-%define m_dith m7
-%else ; x86-64
-%define m_dith m9
-%endif ; x86-32
-
-; create registers holding dither
-movqm_dith, [ditherq]; dither
-testoffsetd, offsetd
-jz  .no_rot
-%if mmsize == 16
-punpcklqdq  m_dith,  m_dith
-%endif ; mmsize == 16
-PALIGNR m_dith,  m_dith,  3,  m0
-.no_rot:
-%if mmsize == 16
-punpcklbw   m_dith,  m6
-%if ARCH_X86_64
-punpcklwd   m8,  m_dith,  m6
-pslld   m8,  12
-%else ; x86-32
-punpcklwd   m5,  m_dith,  m6
-pslld   m5,  12
-%endif ; x86-32/64
-punpckhwd   m_dith,  m6
-pslld   m_dith,  12
-%if ARCH_X86_32
-mova  [rsp+ 0],  m5
-mova  [rsp+16],  m_dith
-%endif
-%else ; mmsize == 8
-punpcklbw   m5,  m_dith,  m6
-punpckhbw   m_dith,  m6
-punpcklwd   m4,  m5,  m6
-punpckhwd   m5,  m6
-punpcklwd   m3,  m_dith,  m6
-punpckhwd   m_dith,  m6
-pslld   m4,  12
-pslld   m5,  12
-pslld   m3,  12
-pslld   m_dith,  12
-mova  [rsp+ 0],  m4
-mova  [rsp+ 8],  m5
-mova  [rsp+16],  m3
-mova  [rsp+24],  m_dith
-%endif ; mmsize == 8/16
-%endif ; %1 == 8
-
-xor r5,  r5
-
+%macro yuv2planeX_mainloop 1
 .pixelloop:
 %assign %%i 0
 ; the rep here is for the 8bit output mmx case, where dither covers
@@ -233,6 +165,77 @@ cglobal yuv2planeX_%1, %3, 8, %2, filter, fltsize, src, 
dst, w, dither, offset
 %assign %%i %%i+2
 %endrep
 jg .pixelloop
+%endmacro
+
+%macro yuv2planeX_fn 3
+
+%if ARCH_X86_32
+%define cntr_reg fltsizeq
+%define movsx mov
+%else
+%define cntr_reg r7
+%define movsx movsxd
+%endif
+
+cglobal yuv2planeX_%1, %3, 8, %2, filter, fltsize, src, dst, w, dither, offset
+%if %1 == 8 || %1 == 9 || %1 == 10
+pxorm6,  m6
+%endif ; %1 == 8/9/10
+
+%if %1 == 8
+%if ARCH_X86_32
+%assign pad 0x2c - (stack_offset & 15)
+SUB rsp, pad
+%define m_dith m7
+%else ; x86-64
+%define m_dith m9
+%endif ; x86-32
+
+; create registers holding dither
+movqm_dith, [ditherq]; dither
+testoffsetd, offsetd
+jz  .no_rot
+%if mmsize == 16
+punpcklqdq  m_dith,  m_dith
+%endif ; mmsize == 16
+PALIGNR m_dith,  m_dith,  3,  m0
+.no_rot:
+%if mmsize == 16
+punpcklbw   m_dith,  m6
+%if ARCH_X86_64
+punpcklwd   m8,  m_dith,  m6
+pslld   m8,  12
+%else ; x86-32
+punpcklwd   m5,  m_dith,  m6
+pslld   m5,  12
+%endif ; x86-32/64
+punpckhwd   m_dith,  m6
+pslld   m_dith,  12
+%if ARCH_X86_32
+mova  [rsp+ 0],  m5
+mova  [rsp+16],  m_dith
+%endif
+%else ; mmsize == 8
+punpcklbw   m5,  m_dith,  m6
+punpckhbw   m_dith,  m6
+punpcklwd   m4,  m5,  m6
+punpckhwd   m5,  m6
+punpcklwd   m3,  m_dith,  m6
+punpckhwd   m_dith,  m6
+pslld   m4,  12
+pslld   m5,  12
+pslld   m3,  12
+pslld   m_dith,  12
+mova  [rsp+ 0],  m4
+mova  [rsp+ 8],  m5
+mova  [rsp+16],  m3
+mova  [rsp+24],  m_dith
+%endif ; mmsize == 8/16
+%endif ; %1 == 8
+
+xor r5,  r5
+
+yuv2planeX_mainloop %1
 
 %if %1 == 8
 %if ARCH_X86_32
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH 1/2] swscale/x86/output: Fix yuv2planeX_16* with unaligned destination

2016-02-16 Thread Michael Niedermayer

On Wed, Feb 17, 2016 at 03:50:57AM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libswscale/x86/output.asm |  160 
> -
>  1 file changed, 87 insertions(+), 73 deletions(-)

cleaner patch posted (in a minute)

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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

[FFmpeg-devel] [PATCH] avcodec/eatqi: print error on mb decode failure

2016-02-16 Thread Michael Niedermayer

Signed-off-by: Michael Niedermayer 
---
 libavcodec/eatqi.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavcodec/eatqi.c b/libavcodec/eatqi.c
index d3b2a97..8fd5cdb 100644
--- a/libavcodec/eatqi.c
+++ b/libavcodec/eatqi.c
@@ -37,6 +37,7 @@
 #include "mpeg12.h"
 
 typedef struct TqiContext {
+AVCodecContext *avctx;
 GetBitContext gb;
 BlockDSPContext bdsp;
 BswapDSPContext bsdsp;
@@ -79,8 +80,11 @@ static int tqi_decode_mb(TqiContext *t, int16_t (*block)[64])
   t->intra_matrix,
   t->intra_scantable.permutated,
   t->last_dc, block[n], n, 1);
-if (ret < 0)
+if (ret < 0) {
+av_log(t->avctx, AV_LOG_ERROR, "ac-tex damaged at %d %d\n",
+   t->mb_x, t->mb_y);
 return -1;
+}
 }
 
 return 0;
@@ -127,6 +131,8 @@ static int tqi_decode_frame(AVCodecContext *avctx,
 AVFrame *frame = data;
 int ret, w, h;
 
+t->avctx = avctx;
+
 w = AV_RL16([0]);
 h = AV_RL16([2]);
 tqi_calculate_qtable(t, buf[4]);
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 2/2] avformat/avienc: reformat raw rgb to comply to specs

2016-02-16 Thread Michael Niedermayer

@todo move to seperate file and reuse in movenc

Signed-off-by: Michael Niedermayer 
---
 libavformat/avienc.c  |   40 
 tests/ref/vsynth/vsynth3-bpp1 |4 ++--
 tests/ref/vsynth/vsynth3-rgb  |4 ++--
 3 files changed, 44 insertions(+), 4 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 649961d..b9aee37 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -644,6 +644,38 @@ static int write_skip_frames(AVFormatContext *s, int 
stream_index, int64_t dts)
 return 0;
 }
 
+static int write_reshuffled_raw_rgb(AVFormatContext *s, AVPacket *pkt, 
AVCodecContext *enc, int expected_stride)
+{
+int ret;
+AVPacket *new_pkt = av_packet_alloc();
+int stride = pkt->size / enc->height;
+int padding = expected_stride - FFMIN(expected_stride, stride);
+int y;
+
+if (!new_pkt)
+return AVERROR(ENOMEM);
+
+ret = av_new_packet(new_pkt, expected_stride * enc->height);
+if (ret < 0)
+goto end;
+
+ret = av_packet_copy_props(new_pkt, pkt);
+if (ret < 0)
+goto end;
+
+for (y = 0; yheight; y++) {
+memcpy(new_pkt->data + y*expected_stride, pkt->data + y*stride, 
FFMIN(expected_stride, stride));
+memset(new_pkt->data + y*expected_stride + expected_stride - padding, 
0, padding);
+}
+
+ret = avi_write_packet(s, new_pkt);
+
+end:
+av_packet_free(_pkt);
+
+return ret;
+}
+
 static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 unsigned char tag[5];
@@ -661,6 +693,14 @@ static int avi_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (ret < 0)
 return ret;
 }
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
+int64_t bpc = enc->bits_per_coded_sample != 15 ? 
enc->bits_per_coded_sample : 16;
+int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
+int stride = (enc->width * bpc + 7) >> 3;
+if (expected_stride * enc->height != pkt->size &&
+stride * enc->height == pkt->size)
+return write_reshuffled_raw_rgb(s, pkt, enc, expected_stride);
+}
 
 if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
 return ret;
diff --git a/tests/ref/vsynth/vsynth3-bpp1 b/tests/ref/vsynth/vsynth3-bpp1
index 5a65728..39f27f3 100644
--- a/tests/ref/vsynth/vsynth3-bpp1
+++ b/tests/ref/vsynth/vsynth3-bpp1
@@ -1,4 +1,4 @@
-98852649c5201df7d85d0e9b5a5b9f15 *tests/data/fate/vsynth3-bpp1.avi
-15352 tests/data/fate/vsynth3-bpp1.avi
+d5689d1f5c2d4c28a345d5964a6161a8 *tests/data/fate/vsynth3-bpp1.avi
+20452 tests/data/fate/vsynth3-bpp1.avi
 0b1ea21b69d384564dd3a978065443b2 *tests/data/fate/vsynth3-bpp1.out.rawvideo
 stddev:   97.64 PSNR:  8.34 MAXDIFF:  248 bytes:86700/86700
diff --git a/tests/ref/vsynth/vsynth3-rgb b/tests/ref/vsynth/vsynth3-rgb
index c0a8563..f67d285 100644
--- a/tests/ref/vsynth/vsynth3-rgb
+++ b/tests/ref/vsynth/vsynth3-rgb
@@ -1,4 +1,4 @@
-a2cb86007b8945e2d1399b56585b983a *tests/data/fate/vsynth3-rgb.avi
-180252 tests/data/fate/vsynth3-rgb.avi
+000bd5f3251bfd6a2a2b590b2d16fe0b *tests/data/fate/vsynth3-rgb.avi
+183652 tests/data/fate/vsynth3-rgb.avi
 693aff10c094f8bd31693f74cf79d2b2 *tests/data/fate/vsynth3-rgb.out.rawvideo
 stddev:3.67 PSNR: 36.82 MAXDIFF:   43 bytes:86700/86700
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 1/2] swscale/x86/output: Fix yuv2planeX_16* with unaligned destination

2016-02-16 Thread Michael Niedermayer

Signed-off-by: Michael Niedermayer 
---
 libswscale/x86/output.asm |  160 -
 1 file changed, 87 insertions(+), 73 deletions(-)

diff --git a/libswscale/x86/output.asm b/libswscale/x86/output.asm
index 9ea4af9..7db72f8 100644
--- a/libswscale/x86/output.asm
+++ b/libswscale/x86/output.asm
@@ -55,75 +55,8 @@ SECTION .text
 ; of 2. $offset is either 0 or 3. $dither holds 8 values.
 ;-
 
-%macro yuv2planeX_fn 3
-
-%if ARCH_X86_32
-%define cntr_reg fltsizeq
-%define movsx mov
-%else
-%define cntr_reg r7
-%define movsx movsxd
-%endif
-
-cglobal yuv2planeX_%1, %3, 8, %2, filter, fltsize, src, dst, w, dither, offset
-%if %1 == 8 || %1 == 9 || %1 == 10
-pxorm6,  m6
-%endif ; %1 == 8/9/10
-
-%if %1 == 8
-%if ARCH_X86_32
-%assign pad 0x2c - (stack_offset & 15)
-SUB rsp, pad
-%define m_dith m7
-%else ; x86-64
-%define m_dith m9
-%endif ; x86-32
-
-; create registers holding dither
-movqm_dith, [ditherq]; dither
-testoffsetd, offsetd
-jz  .no_rot
-%if mmsize == 16
-punpcklqdq  m_dith,  m_dith
-%endif ; mmsize == 16
-PALIGNR m_dith,  m_dith,  3,  m0
-.no_rot:
-%if mmsize == 16
-punpcklbw   m_dith,  m6
-%if ARCH_X86_64
-punpcklwd   m8,  m_dith,  m6
-pslld   m8,  12
-%else ; x86-32
-punpcklwd   m5,  m_dith,  m6
-pslld   m5,  12
-%endif ; x86-32/64
-punpckhwd   m_dith,  m6
-pslld   m_dith,  12
-%if ARCH_X86_32
-mova  [rsp+ 0],  m5
-mova  [rsp+16],  m_dith
-%endif
-%else ; mmsize == 8
-punpcklbw   m5,  m_dith,  m6
-punpckhbw   m_dith,  m6
-punpcklwd   m4,  m5,  m6
-punpckhwd   m5,  m6
-punpcklwd   m3,  m_dith,  m6
-punpckhwd   m_dith,  m6
-pslld   m4,  12
-pslld   m5,  12
-pslld   m3,  12
-pslld   m_dith,  12
-mova  [rsp+ 0],  m4
-mova  [rsp+ 8],  m5
-mova  [rsp+16],  m3
-mova  [rsp+24],  m_dith
-%endif ; mmsize == 8/16
-%endif ; %1 == 8
-
-xor r5,  r5
-
-.pixelloop:
+%macro yuv2planeX_mainloop 2
+.pixelloop_%2:
 %assign %%i 0
 ; the rep here is for the 8bit output mmx case, where dither covers
 ; 8 pixels but we can only handle 2 pixels per register, and thus 4
@@ -150,7 +83,7 @@ cglobal yuv2planeX_%1, %3, 8, %2, filter, fltsize, src, dst, 
w, dither, offset
 movam2,  m1
 %endif ; %1 == 8/9/10/16
 movsx cntr_reg,  fltsizem
-.filterloop_ %+ %%i:
+.filterloop_%2_ %+ %%i:
 ; input pixels
 mov r6, [srcq+gprsize*cntr_reg-2*gprsize]
 %if %1 == 16
@@ -197,7 +130,7 @@ cglobal yuv2planeX_%1, %3, 8, %2, filter, fltsize, src, 
dst, w, dither, offset
 %endif ; %1 == 8/9/10/16
 
 sub   cntr_reg,  2
-jg .filterloop_ %+ %%i
+jg .filterloop_%2_ %+ %%i
 
 %if %1 == 16
 psrad   m2,  31 - %1
@@ -224,7 +157,7 @@ cglobal yuv2planeX_%1, %3, 8, %2, filter, fltsize, src, 
dst, w, dither, offset
 %endif ; mmxext/sse2/sse4/avx
 pminsw  m2, [yuv2yuvX_%1_upper]
 %endif ; %1 == 9/10/16
-mova   [dstq+r5*2],  m2
+mov%2   [dstq+r5*2],  m2
 %endif ; %1 == 8/9/10/16
 
 add r5,  mmsize/2
@@ -232,7 +165,88 @@ cglobal yuv2planeX_%1, %3, 8, %2, filter, fltsize, src, 
dst, w, dither, offset
 
 %assign %%i %%i+2
 %endrep
-jg .pixelloop
+jg .pixelloop_%2
+%endmacro
+
+%macro yuv2planeX_fn 3
+
+%if ARCH_X86_32
+%define cntr_reg fltsizeq
+%define movsx mov
+%else
+%define cntr_reg r7
+%define movsx movsxd
+%endif
+
+cglobal yuv2planeX_%1, %3, 8, %2, filter, fltsize, src, dst, w, dither, offset
+%if %1 == 8 || %1 == 9 || %1 == 10
+pxorm6,  m6
+%endif ; %1 == 8/9/10
+; xor r0,r0
+; mov r0,[r0]
+%if %1 == 8
+%if ARCH_X86_32
+%assign pad 0x2c - (stack_offset & 15)
+SUB rsp, pad
+%define m_dith m7
+%else ; x86-64
+%define m_dith m9
+%endif ; x86-32
+
+; create registers holding dither
+movqm_dith, [ditherq]; dither
+testoffsetd, offsetd
+jz  .no_rot
+%if mmsize == 16
+punpcklqdq  m_dith,  m_dith
+%endif ; mmsize == 16
+PALIGNR m_dith,  m_dith,  3,  m0
+.no_rot:
+%if mmsize == 16
+punpcklbw   m_dith,  m6
+%if ARCH_X86_64
+punpcklwd   m8,  m_dith,  m6
+pslld   m8,  12
+%else ; x86-32
+punpcklwd   m5,  m_dith,  m6
+pslld   m5,  12
+%endif ; x86-32/64
+punpckhwd   m_dith,  m6
+pslld   m_dith,  12
+%if ARCH_X86_32
+mova  [rsp+ 0],  m5
+mova  [rsp+16],  m_dith
+%endif
+%else ; mmsize == 8
+punpcklbw   m5,  m_dith,  m6
+punpckhbw   m_dith,  m6
+punpcklwd   m4,  m5,  m6
+punpckhwd   m5,  m6
+punpcklwd   m3,  m_dith,  m6
+punpckhwd   m_dith,  m6
+pslld   m4,  12
+pslld   m5,  12
+pslld

Re: [FFmpeg-devel] [PATCH] avfilter/vf_drawbox: add alpha support

2016-02-16 Thread Andrey Utkin

On Mon, 15 Feb 2016 11:40:33 +0100
Paul B Mahol  wrote:

> Hi,
> 
> patch attached.

I am not keen on raw data planes handling, so I could ignore something
important. Also I haven't tested this patch in runtime. Otherwise the
patch looks good.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: drawutils >8 bit support

2016-02-16 Thread Paul B Mahol

On 2/16/16, Paul B Mahol  wrote:
> On 2/15/16, Paul B Mahol  wrote:
>> Hi,
>>
>> patch attached.
>>
>> I couldn't get blend functions to work correctly.
>>
>
> Now with blend properly working.
>
> But now I have issues with fate ref update, it mess up terminal here
> so one needs to use reset.
>

Now with fate ref updated and pad align issue fixed.
From 9463aa15680f85bcd05dbfbc4a654e2c8eb05178 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Mon, 15 Feb 2016 17:07:33 +0100
Subject: [PATCH] avfilter/drawutils: >8 bit support

Signed-off-by: Paul B Mahol 
---
 libavfilter/drawutils.c   | 240 +++---
 libavfilter/drawutils.h   |   6 +-
 libavfilter/vf_pad.c  |   8 +-
 tests/ref/fate/filter-pixfmts-pad |  32 +
 4 files changed, 239 insertions(+), 47 deletions(-)

diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index 23a0eb5..57dd838 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -24,6 +24,7 @@
 #include "libavutil/avassert.h"
 #include "libavutil/avutil.h"
 #include "libavutil/colorspace.h"
+#include "libavutil/intreadwrite.h"
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "drawutils.h"
@@ -175,8 +176,10 @@ int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat format, unsigned flags)
 return AVERROR(ENOSYS);
 for (i = 0; i < desc->nb_components; i++) {
 c = >comp[i];
-/* for now, only 8-bits formats */
-if (c->depth != 8)
+/* for now, only 8-16 bits formats */
+if (c->depth < 8 || c->depth > 16)
+return AVERROR(ENOSYS);
+if (desc->flags & AV_PIX_FMT_FLAG_BE)
 return AVERROR(ENOSYS);
 if (c->plane >= MAX_PLANES)
 return AVERROR(ENOSYS);
@@ -184,6 +187,9 @@ int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat format, unsigned flags)
 if (pixelstep[c->plane] != 0 &&
 pixelstep[c->plane] != c->step)
 return AVERROR(ENOSYS);
+if (pixelstep[c->plane] == 6 &&
+c->depth == 16)
+return AVERROR(ENOSYS);
 pixelstep[c->plane] = c->step;
 if (pixelstep[c->plane] >= 8)
 return AVERROR(ENOSYS);
@@ -214,11 +220,18 @@ void ff_draw_color(FFDrawContext *draw, FFDrawColor *color, const uint8_t rgba[4
 if ((draw->desc->flags & AV_PIX_FMT_FLAG_RGB) &&
 ff_fill_rgba_map(rgba_map, draw->format) >= 0) {
 if (draw->nb_planes == 1) {
-for (i = 0; i < 4; i++)
+for (i = 0; i < 4; i++) {
 color->comp[0].u8[rgba_map[i]] = rgba[i];
+if (draw->desc->comp[rgba_map[i]].depth > 8) {
+color->comp[0].u16[rgba_map[i]] = color->comp[0].u8[rgba_map[i]] << 8;
+}
+}
 } else {
-for (i = 0; i < 4; i++)
+for (i = 0; i < 4; i++) {
 color->comp[rgba_map[i]].u8[0] = rgba[i];
+if (draw->desc->comp[rgba_map[i]].depth > 8)
+color->comp[rgba_map[i]].u16[0] = color->comp[rgba_map[i]].u8[0] << (draw->desc->comp[rgba_map[i]].depth - 8);
+}
 }
 } else if (draw->nb_planes == 3 || draw->nb_planes == 4) {
 /* assume YUV */
@@ -226,9 +239,22 @@ void ff_draw_color(FFDrawContext *draw, FFDrawColor *color, const uint8_t rgba[4
 color->comp[1].u8[0] = RGB_TO_U_CCIR(rgba[0], rgba[1], rgba[2], 0);
 color->comp[2].u8[0] = RGB_TO_V_CCIR(rgba[0], rgba[1], rgba[2], 0);
 color->comp[3].u8[0] = rgba[3];
+if (draw->desc->comp[0].depth > 8)
+color->comp[0].u16[0] = color->comp[0].u8[0] << (draw->desc->comp[0].depth - 8);
+if (draw->desc->comp[1].depth > 8)
+color->comp[1].u16[0] = color->comp[1].u8[0] << (draw->desc->comp[1].depth - 8);
+if (draw->desc->comp[2].depth > 8)
+color->comp[2].u16[0] = color->comp[2].u8[0] << (draw->desc->comp[2].depth - 8);
+if (draw->desc->comp[3].depth > 8)
+color->comp[3].u16[0] = color->comp[3].u8[0] << (draw->desc->comp[3].depth - 8);
 } else if (draw->format == AV_PIX_FMT_GRAY8 || draw->format == AV_PIX_FMT_GRAY8A) {
 color->comp[0].u8[0] = RGB_TO_Y_CCIR(rgba[0], rgba[1], rgba[2]);
 color->comp[1].u8[0] = rgba[3];
+} else if (draw->format == AV_PIX_FMT_GRAY16 || draw->format == AV_PIX_FMT_YA16) {
+color->comp[0].u8[0] = RGB_TO_Y_CCIR(rgba[0], rgba[1], rgba[2]);
+color->comp[0].u16[0] = color->comp[0].u8[0] << 8;
+color->comp[1].u8[0] = rgba[3];
+color->comp[1].u16[0] = color->comp[1].u8[0] << 8;
 } else {
 av_log(NULL, AV_LOG_WARNING,
"Color conversion not implemented for %s\n", draw->desc->name);
@@ -361,6 +387,31 @@ static void blend_line(uint8_t *dst, unsigned src, unsigned alpha,
 }
 }
 
+static void blend_line16(uint8_t *dst,

Re: [FFmpeg-devel] [PATCH] avfilter: add BobWeaver deinterlacing filter

2016-02-16 Thread Thomas Mundt

>>> Paul B Mahol  schrieb am Di, 16.2.2016:
 On 2/8/16, Thomas Mundt  wrote:
> Hendrik Leppkes  schrieb am Mo, 8.2.2016:
>>> How does the speed compare to YADIF?
>>> Or in other words, is it usable in real-time, or rather designed for
>>> offline processing?
>>>
>> YADIF is quicker, because of its CPU optimizations. Without CPU
>> optimizations BobWeaver is quicker.
>> It should definitely be usable in real-time.
>
> Could you provide samples when this filters gives better output than
> yadif/w3fdif ?

I´ve uploaded some samples for comparison:

http://free-vsts.com/files/bwdif_w3fdif_yadif.zip

I used the same command for all competitors:
ffmpeg -i xxx_orig.mp4 -vf DEINTERLACER -r 50 -aspect 16:9 -vcodec libx264 -crf 
18 out.mp4
bwdif  DEINTERLACER: bwdif
yadif  DEINTERLACER: yadif=1
w3fdif DEINTERLACER: w3fdif=filter=complex

For comparison of moving interlaced scenes I´ve uploaded the sample parkjoy(pj).
This is difficult for deinterlacers and doesn´t look very good with all 
competitors. Yadif makes kind of a watercolor effect. W3fdif is much closer to 
the original progressive parkjoy source file. BobWeaver is very close to 
w3fdif, but shows less artefacts especially in moving front trees.

For comparison of still interlaced scenes I´ve uploaded the samples kiosk and 
bars.
Here w3fdif shows jigging because of its absent still pixel detection. Yadif 
and BobWeaver are fine. With sample bars only BobWeaver shows the correct 3 
white lines in the timecode. I don´t have original progressive versions of 
kiosk and bars, since this is broadcast content.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2 2/2] avcodec/libzvbi-teletextdec: use common functions for matching data_unit_id and data_identifier

2016-02-16 Thread Marton Balint

Signed-off-by: Marton Balint 
---
 libavcodec/libzvbi-teletextdec.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/libavcodec/libzvbi-teletextdec.c b/libavcodec/libzvbi-teletextdec.c
index 308f735..667cd28 100644
--- a/libavcodec/libzvbi-teletextdec.c
+++ b/libavcodec/libzvbi-teletextdec.c
@@ -20,6 +20,7 @@
 
 #include "avcodec.h"
 #include "libavcodec/ass.h"
+#include "libavcodec/dvbtxt.h"
 #include "libavutil/opt.h"
 #include "libavutil/bprint.h"
 #include "libavutil/internal.h"
@@ -368,12 +369,6 @@ static void handler(vbi_event *ev, void *user_data)
 vbi_unref_page();
 }
 
-static inline int data_identifier_is_teletext(int data_identifier) {
-/* See EN 301 775 section 4.4.2. */
-return (data_identifier >= 0x10 && data_identifier <= 0x1F ||
-data_identifier >= 0x99 && data_identifier <= 0x9B);
-}
-
 static int slice_to_vbi_lines(TeletextContext *ctx, uint8_t* buf, int size)
 {
 int lines = 0;
@@ -382,7 +377,7 @@ static int slice_to_vbi_lines(TeletextContext *ctx, 
uint8_t* buf, int size)
 int data_unit_length = buf[1];
 if (data_unit_length + 2 > size)
 return AVERROR_INVALIDDATA;
-if (data_unit_id == 0x02 || data_unit_id == 0x03) {
+if (ff_data_unit_id_is_teletext(data_unit_id)) {
 if (data_unit_length != 0x2c)
 return AVERROR_INVALIDDATA;
 else {
@@ -434,7 +429,7 @@ static int teletext_decode_frame(AVCodecContext *avctx, 
void *data, int *data_si
 
 ctx->handler_ret = pkt->size;
 
-if (data_identifier_is_teletext(*pkt->data)) {
+if (ff_data_identifier_is_teletext(*pkt->data)) {
 if ((lines = slice_to_vbi_lines(ctx, pkt->data + 1, pkt->size - 
1)) < 0)
 return lines;
 ff_dlog(avctx, "ctx=%p buf_size=%d lines=%u pkt_pts=%7.3f\n",
-- 
2.6.2

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

[FFmpeg-devel] [PATCHv2 1/2] avformat/dvbtxt: add raw demuxer for dvb teletext probing

2016-02-16 Thread Marton Balint

Signed-off-by: Marton Balint 
---
 libavcodec/dvbtxt.h  | 41 +++
 libavformat/Makefile |  1 +
 libavformat/allformats.c |  1 +
 libavformat/dvbtxt.c | 50 
 libavformat/utils.c  |  1 +
 5 files changed, 94 insertions(+)
 create mode 100644 libavcodec/dvbtxt.h
 create mode 100644 libavformat/dvbtxt.c

diff --git a/libavcodec/dvbtxt.h b/libavcodec/dvbtxt.h
new file mode 100644
index 000..ff88fcf
--- /dev/null
+++ b/libavcodec/dvbtxt.h
@@ -0,0 +1,41 @@
+/*
+ * DVB teletext common functions.
+ *
+ * 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
+ */
+
+#ifndef AVCODEC_DVBTXT_H
+#define AVCODEC_DVBTXT_H
+
+#include "libavutil/attributes.h"
+
+/* Returns true if data identifier matches a teletext stream according to EN
+ * 301 775 section 4.4.2 */
+static av_always_inline int ff_data_identifier_is_teletext(int data_identifier)
+{
+return (data_identifier >= 0x10 && data_identifier <= 0x1F ||
+data_identifier >= 0x99 && data_identifier <= 0x9B);
+}
+
+/* Returns true if data unit id matches EBU teletext data according to
+ * EN 301 775 section 4.4.2 */
+static av_always_inline int ff_data_unit_id_is_teletext(int data_unit_id)
+{
+return (data_unit_id == 0x02 || data_unit_id == 0x03);
+}
+
+#endif /* AVCODEC_DVBTXT_H */
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 35a383d..38c6706 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -144,6 +144,7 @@ OBJS-$(CONFIG_DTS_MUXER) += rawenc.o
 OBJS-$(CONFIG_DV_DEMUXER)+= dv.o
 OBJS-$(CONFIG_DV_MUXER)  += dvenc.o
 OBJS-$(CONFIG_DVBSUB_DEMUXER)+= dvbsub.o
+OBJS-$(CONFIG_DVBTXT_DEMUXER)+= dvbtxt.o
 OBJS-$(CONFIG_DXA_DEMUXER)   += dxa.o
 OBJS-$(CONFIG_EA_CDATA_DEMUXER)  += eacdata.o
 OBJS-$(CONFIG_EA_DEMUXER)+= electronicarts.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 02bb16a..9662941 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -121,6 +121,7 @@ void av_register_all(void)
 REGISTER_DEMUXER (DTSHD,dtshd);
 REGISTER_MUXDEMUX(DV,   dv);
 REGISTER_DEMUXER (DVBSUB,   dvbsub);
+REGISTER_DEMUXER (DVBTXT,   dvbtxt);
 REGISTER_DEMUXER (DXA,  dxa);
 REGISTER_DEMUXER (EA,   ea);
 REGISTER_DEMUXER (EA_CDATA, ea_cdata);
diff --git a/libavformat/dvbtxt.c b/libavformat/dvbtxt.c
new file mode 100644
index 000..6828738
--- /dev/null
+++ b/libavformat/dvbtxt.c
@@ -0,0 +1,50 @@
+/*
+ * RAW dvb teletext demuxer
+ * Copyright (c) 2016 Marton Balnt 
+ *
+ * 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 "libavcodec/dvbtxt.h"
+
+#include "avformat.h"
+#include "rawdec.h"
+
+static int dvbtxt_probe(AVProbeData *p)
+{
+const uint8_t *end = p->buf + p->buf_size;
+const uint8_t *buf;
+
+/* The purpose of this is demuxer is to detect DVB teletext streams in
+ * mpegts, so we reject invalid buffer sizes */
+if ((p->buf_size + 45) % 184 != 0)
+return 0;
+
+if (!ff_data_identifier_is_teletext(p->buf[0]))
+return 0;
+
+for (buf = p->buf + 1; buf < end; buf += 46) {
+if (!ff_data_unit_id_is_teletext(buf[0]) && buf[0] != 0xff)
+return 0;
+if (buf[1] != 0x2c) // data_unit_length
+return 0;
+}
+
+return AVPROBE_SCORE_MAX / 2;
+}
+

Re: [FFmpeg-devel] [PATCH 1/2] avformat/dvbtxt: add raw demuxer for dvb teletext probing

2016-02-16 Thread Carl Eugen Hoyos

Marton Balint  passwd.hu> writes:

> >> +return AVPROBE_SCORE_MAX / 2;
> >
> > Is this ok for one frame?
> 
> I don't know, I figured even for the smallest PES 
> payload which is 139 bytes we are matching 1+2+2+2 
> mostly different bytes

Then the score is ok (or too small).

> >> +++ b/libavutil/internal.h
> >
> > Please create a new teletext header in libavcodec.
> 
> Why not in libavutil then?

Because it is far too specific for libavutil.

> It is used in a codec in libavcodec and a probe 
> function in libavformat.

This means it should be in libavcodec.

Carl Eugen

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

Re: [FFmpeg-devel] Question about "make distclean" after "git pull"

2016-02-16 Thread Mats Peterson


On 02/16/2016 05:37 PM, Nicolas George wrote:

L'octidi 28 pluviôse, an CCXXIV, Mats Peterson a écrit :

Is it very important to use a "make distclean" after a "git pull"? It
depends on the changes made to the newly pulled code, I guess.


Exactly. The most common issue is when files are renamed or deleted: without
distclean, the dependency files are still there and make will fail because
it thinks it still needs them.

So basically: if you forget distclean and it works, then it was probably not
necessary; and if build fails, you know distclean was necessary. There may
have been cases where forgetting distclean would cause bugs more subtle than
that, but I do not remember the specifics.

Regards,



Thanks for this exhaustive answer, Nicolas.

Mats

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

Re: [FFmpeg-devel] [PATCH] Add mkdir support for HLS localtime-generated segment files

2016-02-16 Thread Johan Ström


On 16/02/16 00:59, Michael Niedermayer wrote:

On Mon, Feb 15, 2016 at 10:35:57PM +0100, Johan Ström wrote:

Thanks for your attention!

Updated patch attached. It has been rebased against current master
(avio_open2->ffio_open_whitelist changes) with no issues.

On 14/02/16 01:29, Michael Niedermayer wrote:

On Wed, Feb 03, 2016 at 10:44:28PM +0100, Johan Ström wrote:

Hi,

this patch adds -use_localtime_mkdir option to the HLS encoder.
Use with -use_localtime, and set -hls_segment_filename to a path
which contains a subdirectory i.e.
/some/path/%Y%m%d/%Y%m%dT%H%M%S-%s.ts
This will mkdir the %Y%m%d-part of the path if it does not already exist.

In addition, each filename in the playlist output will be prefixed
with this subdirectory (if playlist and segment shares the same base
path).

...

missing update to the docs

Actually, there was no docs for the -use_localtime property at all.
I've added for both use_localtime and use_localtime_mkdir now.

what happens if the path is not a local file but for example
http://...

if that otherwise works but fails with the new option then it should
be documented and maybe tested for. It may seem logic for us but a
user might be confused why the option doesnt work for that

That is not possible in any mode, and neither would I expect it to.

The following is with -use_localtime 1 -hls_segment_filename 
http://localhost/test/%d.ts:


[tcp @ 0x80401e880] Connection to tcp://localhost:80 failed (Connection 
refused), trying next address

Output #0, hls, to '/storage/dvr/ipcam//test/playlist.m3u8':
  Metadata:
title   : RTSP Session
encoder : Lavf57.25.100
Stream #0:0: Video: h264, yuv420p, 352x288, q=2-31, 25 fps, 25 tbr, 
25 tbn, 25 tbc

Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
..
[tcp @ 0x804065080] Connection to tcp://back-1:80 failed (Connection 
refused), trying next address
[tcp @ 0x804065080] Connection to tcp://back-1:80 failed (Connection 
refused), trying next address
frame=  198 fps= 29 q=-1.0 Lsize=N/A time=00:00:07.92 bitrate=N/A 
speed=1.17x
video:350kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: unknown

Exiting normally, received signal 2.

Same thing without -use_localtime 1.
So, it seems it tries to use some kind of tcp transport (rather than HTTP).

I did notice a minor typo in my docs patch, so a new patch is attached.


also can you add a fate test for this feature ?

Sorry, I have no idea how those works or how to write one. As far as
I can see there are none for HLS today which I could extend on..

yes, it would be great to have hls fate tests
without such tests someone might break hls without him noticing ...
but thats orthogonal to the patch


Indeed. But I'm probably not the right one to write them.

From 443289a36c71bfecbc748ad706d2fa35d3659e90 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Johan=20Str=C3=B6m?= 
Date: Wed, 3 Feb 2016 22:20:07 +0100
Subject: [PATCH] hlsenc: add use_localtime_mkdir option to automatically
 create time-based directory

Use with -use_localtime, and set -hls_segment_filename to a path which
contains a subdirectory i.e. /some/path/%Y%m%d/%Y%m%dT%H%M%S-%s.ts
This will mkdir the %Y%m%d-part of the path if it does not already
exist.
In addition, each filename in the playlist output will be prefixed with
this subdirectory (if playlist and segment shares the same base path).
---
 doc/muxers.texi  | 20 
 libavformat/hlsenc.c | 50 +++---
 2 files changed, 63 insertions(+), 7 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 2e6bb4c..f2ad7fe 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -318,6 +318,26 @@ ffmpeg in.nut -hls_segment_filename 'file%03d.ts' out.m3u8
 This example will produce the playlist, @file{out.m3u8}, and segment files:
 @file{file000.ts}, @file{file001.ts}, @file{file002.ts}, etc.
 
+@item use_localtime
+Use strftime on @var{filename} to expand the segment filename with localtime.
+The segment number (%d) is not available in this mode.
+@example
+ffmpeg in.nut -use_localtime 1 -hls_segment_filename 'file-%Y%m%d-%s.ts' 
out.m3u8
+@end example
+This example will produce the playlist, @file{out.m3u8}, and segment files:
+@file{file-20160215-1455569023.ts}, @file{file-20160215-1455569024.ts}, etc.
+
+@item use_localtime_mkdir
+Used together with -use_localtime, it will create up to one subdirectory which
+is expanded in @var{filename}.
+@example
+ffmpeg in.nut -use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename 
'%Y%m%d/file-%Y%m%d-%s.ts' out.m3u8
+@end example
+This example will create a directory 201560215 (if it does not exist), and then
+produce the playlist, @file{out.m3u8}, and segment files:
+@file{201560215/file-20160215-1455569023.ts}, 
@file{201560215/file-20160215-1455569024.ts}, etc.
+
+
 @item hls_key_info_file @var{key_info_file}
 Use the information in @var{key_info_file} for segment

Re: [FFmpeg-devel] [PATCH 1/2] avformat/dvbtxt: add raw demuxer for dvb teletext probing

2016-02-16 Thread Marton Balint



On Tue, 16 Feb 2016, Carl Eugen Hoyos wrote:


Marton Balint  passwd.hu> writes:

+/* The purpose of this is demuxer is to detect DVB teletext 
streams in

+ * mpegts, so we reject invalid buffer sizes */
+if ((p->buf_size + 45) % 184 != 0)
+return 0;


I don't think this is ok (although I may miss 
something):
The file could end in the middle of a teletext 
patckage or the end of the probe buffer could 
be within a teletext package.


Usually you'd be right, but not this time I think because the reason for 
this demuxer is not to actually handle RAW dvb teletext files (I doubt 
those exists in the real world), but only to detect DVB teletext streams 
in mpegts. Therefore it matches for a single PES payload, not a bitstream.


A RAW dvb teletext file would be a dump of PES payloads without separation 
where one would constantly have to find synchornization because there is 
no way of knowning how big is a PES payload and when the next one starts.


On the other hand DVB teletext PES payloads have a strict length 
requirement, and they are at most 1437 bytes long, so the full payload 
should always be probed even if the probe function truncates at 2048 bytes 
or so (I don't know if it does or not).





+if (!ff_data_identifier_is_teletext(p->buf[0]))
+return 0;
+
+for (buf = p->buf + 1; buf < end; buf += 46) {
+if (!ff_data_unit_id_is_teletext(buf[0]) && buf[0] != 0xff)
+return 0;
+if (buf[1] != 0x2c) // data_unit_length
+return 0;
+}


I suspect this should count frames.


Not really, a PES payload is only one frame, the loop match data units 
(practically VBI lines, or stuffing).



+return AVPROBE_SCORE_MAX / 2;


Is this ok for one frame?


I don't know, I figured even for the smallest PES payload which is 139 
bytes we are matching 1+2+2+2 mostly different bytes, which should be a 
pretty safe detection, therefore AVPROBE_SCORE_MAX / 2. I can use anything 
here you prefer.





+++ b/libavutil/internal.h


Please create a new teletext header in libavcodec.


Why not in libavutil then? It is used in a codec in libavcodec and a probe 
function in libavformat.


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

Re: [FFmpeg-devel] [PATCH v2] avfilter/avf_showcqt: improve pts handling

2016-02-16 Thread Muhammad Faiz

On Tue, Feb 16, 2016 at 6:22 PM, wm4  wrote:
> On Tue, 16 Feb 2016 18:01:16 +0700
> Muhammad Faiz  wrote:
>
>> From bc59d4a7636e2f199b3dbda06e8e3bc53e260cae Mon Sep 17 00:00:00 2001
>> From: Muhammad Faiz 
>> Date: Tue, 16 Feb 2016 07:03:37 +0700
>> Subject: [PATCH v2] avfilter/avf_showcqt: improve pts handling
>>
>> correct output pts based on input pts
>> make seeking possible
>> output frame one by one on eof
>> tested with showinfo filter
>>
>> Suggested-by: Paul B Mahol 
>> ---
>>  libavfilter/avf_showcqt.c | 47 
>> +++
>>  libavfilter/avf_showcqt.h |  2 +-
>>  2 files changed, 36 insertions(+), 13 deletions(-)
>>
>> diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
>> index 712a999..6bb2d18 100644
>> --- a/libavfilter/avf_showcqt.c
>> +++ b/libavfilter/avf_showcqt.c
>> @@ -48,6 +48,8 @@
>>  #define FONTCOLOR   "st(0, (midi(f)-59.5)/12);" \
>>  "st(1, if(between(ld(0),0,1), 0.5-0.5*cos(2*PI*ld(0)), 0));" \
>>  "r(1-ld(1)) + b(ld(1))"
>> +#define PTS_STEP 10
>> +#define PTS_TOLERANCE 1
>>
>>  #define OFFSET(x) offsetof(ShowCQTContext, x)
>>  #define FLAGS (AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM)
>> @@ -989,11 +991,10 @@ static void process_cqt(ShowCQTContext *s)
>>  yuv_from_cqt(s->c_buf, s->cqt_result, s->sono_g, s->width);
>>  }
>>
>> -static int plot_cqt(AVFilterContext *ctx)
>> +static int plot_cqt(AVFilterContext *ctx, AVFrame **frameout)
>>  {
>>  AVFilterLink *outlink = ctx->outputs[0];
>>  ShowCQTContext *s = ctx->priv;
>> -int ret = 0;
>>
>>  memcpy(s->fft_result, s->fft_data, s->fft_len * sizeof(*s->fft_data));
>>  av_fft_permute(s->fft_ctx, s->fft_result);
>> @@ -1004,7 +1005,7 @@ static int plot_cqt(AVFilterContext *ctx)
>>  if (s->sono_h)
>>  s->update_sono(s->sono_frame, s->c_buf, s->sono_idx);
>>  if (!s->sono_count) {
>> -AVFrame *out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
>> +AVFrame *out = *frameout = ff_get_video_buffer(outlink, outlink->w, 
>> outlink->h);
>>  if (!out)
>>  return AVERROR(ENOMEM);
>>  if (s->bar_h)
>> @@ -1013,14 +1014,13 @@ static int plot_cqt(AVFilterContext *ctx)
>>  s->draw_axis(out, s->axis_frame, s->c_buf, s->bar_h);
>>  if (s->sono_h)
>>  s->draw_sono(out, s->sono_frame, s->bar_h + s->axis_h, 
>> s->sono_idx);
>> -out->pts = s->frame_count;
>> -ret = ff_filter_frame(outlink, out);
>> -s->frame_count++;
>> +out->pts = s->next_pts;
>> +s->next_pts += PTS_STEP;
>>  }
>>  s->sono_count = (s->sono_count + 1) % s->count;
>>  if (s->sono_h)
>>  s->sono_idx = (s->sono_idx + s->sono_h - 1) % s->sono_h;
>> -return ret;
>> +return 0;
>>  }
>>
>>  /* main filter control */
>> @@ -1133,7 +1133,7 @@ static int config_output(AVFilterLink *outlink)
>>  s->format = outlink->format;
>>  outlink->sample_aspect_ratio = av_make_q(1, 1);
>>  outlink->frame_rate = s->rate;
>> -outlink->time_base = av_inv_q(s->rate);
>> +outlink->time_base = av_mul_q(av_inv_q(s->rate), av_make_q(1, 
>> PTS_STEP));
>>  av_log(ctx, AV_LOG_INFO, "video: %dx%d %s %d/%d fps, bar_h = %d, axis_h 
>> = %d, sono_h = %d.\n",
>> s->width, s->height, av_get_pix_fmt_name(s->format), 
>> s->rate.num, s->rate.den,
>> s->bar_h, s->axis_h, s->sono_h);
>> @@ -1209,7 +1209,7 @@ static int config_output(AVFilterLink *outlink)
>>  return AVERROR(ENOMEM);
>>
>>  s->sono_count = 0;
>> -s->frame_count = 0;
>> +s->next_pts = 0;
>>  s->sono_idx = 0;
>>  s->remaining_fill = s->fft_len / 2;
>>  s->remaining_frac = 0;
>> @@ -1232,14 +1232,16 @@ static int config_output(AVFilterLink *outlink)
>>  static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
>>  {
>>  AVFilterContext *ctx = inlink->dst;
>> +AVFilterLink *outlink = ctx->outputs[0];
>>  ShowCQTContext *s = ctx->priv;
>>  int remaining, step, ret, x, i, j, m;
>>  float *audio_data;
>> +AVFrame *out = NULL;
>>
>>  if (!insamples) {
>>  while (s->remaining_fill < s->fft_len / 2) {
>>  memset(>fft_data[s->fft_len - s->remaining_fill], 0, 
>> sizeof(*s->fft_data) * s->remaining_fill);
>> -ret = plot_cqt(ctx);
>> +ret = plot_cqt(ctx, );
>>  if (ret < 0)
>>  return ret;
>>
>> @@ -1248,6 +1250,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
>> *insamples)
>>  for (x = 0; x < (s->fft_len-step); x++)
>>  s->fft_data[x] = s->fft_data[x+step];
>>  s->remaining_fill += step;
>> +
>> +if (out)
>> +return ff_filter_frame(outlink, out);
>>  }
>>  return AVERROR_EOF;
>>  }
>> @@ -1263,12 +1268,30 @@ static int filter_frame(AVFilterLink

Re: [FFmpeg-devel] [PATCH] avfilter: add firequalizer filter

2016-02-16 Thread Muhammad Faiz

On Tue, Feb 16, 2016 at 6:48 PM, Paul B Mahol  wrote:
> On 2/16/16, Muhammad Faiz  wrote:
>> patch attached
>>
>> thank's
>>
>>
>> ---
>>  Changelog |   1 +
>>  MAINTAINERS   |   1 +
>>  configure |   2 +
>>  doc/filters.texi  | 109 
>>  libavfilter/Makefile  |   1 +
>>  libavfilter/af_firequalizer.c | 592 
>> ++
>>  libavfilter/allfilters.c  |   1 +
>>  libavfilter/version.h |   2 +-
>>  8 files changed, 708 insertions(+), 1 deletion(-)
>>  create mode 100644 libavfilter/af_firequalizer.c
>>
>> diff --git a/Changelog b/Changelog
>> index 96a9955..1794164 100644
>> --- a/Changelog
>> +++ b/Changelog
>> @@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest 
>> within each release,
>>  releases are sorted from youngest to oldest.
>>
>>  version :
>> +- firequalizer filter
>>
>
> Interesting.
>
>>
>>  version 3.0:
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e57150d..9f7baf0 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -353,6 +353,7 @@ Filters:
>>af_biquads.c  Paul B Mahol
>>af_chorus.c   Paul B Mahol
>>af_compand.c  Paul B Mahol
>> +  af_firequalizer.c Muhammad Faiz
>>af_ladspa.c   Paul B Mahol
>>af_pan.c  Nicolas George
>>af_sidechaincompress.cPaul B Mahol
>> diff --git a/configure b/configure
>> index 2148f11..b775cb9 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2857,6 +2857,8 @@ eq_filter_deps="gpl"
>>  fftfilt_filter_deps="avcodec"
>>  fftfilt_filter_select="rdft"
>>  find_rect_filter_deps="avcodec avformat gpl"
>> +firequalizer_filter_deps="avcodec"
>> +firequalizer_filter_select="rdft"
>>  flite_filter_deps="libflite"
>>  frei0r_filter_deps="frei0r dlopen"
>>  frei0r_src_filter_deps="frei0r dlopen"
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 68f54f1..67506dc 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -2366,6 +2366,115 @@ Sets the difference coefficient (default: 2.5). 0.0 
>> means mono sound
>>  Enable clipping. By default is enabled.
>>  @end table
>>
>> +@section firequalizer
>> +Apply FIR Equalization using arbitrary frequency response.
>> +
>> +The filter accepts the following option:
>> +
>> +@table @option
>> +@item gain
>> +Set gain curve equation (in dB). The expression can contain variables:
>> +@table @option
>> +@item f
>> +the evaluated frequency
>> +@item sr
>> +sample rate
>> +@item ch
>> +channel number, set to 0 when multichannels evaluation is disabled
>> +@item chid
>> +channel id, see libavutil/channel_layout.h, set to the first channel id when
>> +multichannels evaluation is disabled
>> +@item chs
>> +number of channels
>> +@item chlayout
>> +channel_layout, see libavutil/channel_layout.h
>> +
>> +@end table
>> +and functions:
>> +@table @option
>> +@item gain_interpolate(f)
>> +interpote gain on frequency f based on gain_entry
>> +@end table
>> +This option is also available as command. Default is 
>> @code{gain_interpolate(f)}.
>> +
>> +@item gain_entry
>> +Set gain entry for gain_interpolate function. The expression can
>> +contain functions:
>> +@table @option
>> +@item entry(f, g)
>> +store gain entry at frequency f with value g
>> +@end table
>> +This option is also available as command.
>> +
>> +@item delay
>> +Set filter delay in seconds. Higher value means more accurate.
>> +Default is @code{0.01}.
>> +
>> +@item accuracy
>> +Set filter accuracy in Hz. Lower value means more accurate.
>> +Default is @code{5}.
>> +
>> +@item wfunc
>> +Set window function. Acceptable values are:
>> +@table @option
>> +@item rectangular
>> +rectangular window, useful when gain curve is already smooth
>> +@item hann
>> +hann window (default)
>> +@item hamming
>> +hamming window
>> +@item blackman
>> +blackman window
>> +@item nuttall3
>> +3-terms continuous 1st derivative nuttall window
>> +@item mnuttall3
>> +minimum 3-terms discontinuous nuttall window
>> +@item nuttall
>> +4-terms continuous 1st derivative nuttall window
>> +@item bnuttall
>> +minimum 4-terms discontinuous nuttall (blackman-nuttall) window
>> +@item bharris
>> +blackman-harris window
>> +@end table
>> +
>> +@item fixed
>> +If enabled, use fixed number of audio samples. This improves speed when
>> +filtering with large delay. Default is disabled.
>> +
>> +@item multi
>> +Enable multichannels evaluation on gain. Default is disabled.
>> +@end table
>> +
>> +@subsection Examples
>> +@itemize
>> +@item
>> +lowpass at 1000 Hz:
>> +@example
>> +firequalizer=gain='if(lt(f,1000), 0, -INF)'
>> +@end example
>> +@item
>> +lowpass at 1000 Hz with gain_entry:
>> +@example
>> +firequalizer=gain_entry='entry(1000,0); entry(1001, -INF)'
>> +@end example
>> +@item
>> +custom equalization:
>> +@example
>>

Re: [FFmpeg-devel] [PATCH v2] avfilter/avf_showcqt: improve pts handling

2016-02-16 Thread Muhammad Faiz

On Tue, Feb 16, 2016 at 6:22 PM, wm4  wrote:
> On Tue, 16 Feb 2016 18:01:16 +0700
> Muhammad Faiz  wrote:
>
>> From bc59d4a7636e2f199b3dbda06e8e3bc53e260cae Mon Sep 17 00:00:00 2001
>> From: Muhammad Faiz 
>> Date: Tue, 16 Feb 2016 07:03:37 +0700
>> Subject: [PATCH v2] avfilter/avf_showcqt: improve pts handling
>>
>> correct output pts based on input pts
>> make seeking possible
>> output frame one by one on eof
>> tested with showinfo filter
>>
>> Suggested-by: Paul B Mahol 
>> ---
>>  libavfilter/avf_showcqt.c | 47 
>> +++
>>  libavfilter/avf_showcqt.h |  2 +-
>>  2 files changed, 36 insertions(+), 13 deletions(-)
>>
>> diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
>> index 712a999..6bb2d18 100644
>> --- a/libavfilter/avf_showcqt.c
>> +++ b/libavfilter/avf_showcqt.c
>> @@ -48,6 +48,8 @@
>>  #define FONTCOLOR   "st(0, (midi(f)-59.5)/12);" \
>>  "st(1, if(between(ld(0),0,1), 0.5-0.5*cos(2*PI*ld(0)), 0));" \
>>  "r(1-ld(1)) + b(ld(1))"
>> +#define PTS_STEP 10
>> +#define PTS_TOLERANCE 1
>>
>>  #define OFFSET(x) offsetof(ShowCQTContext, x)
>>  #define FLAGS (AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM)
>> @@ -989,11 +991,10 @@ static void process_cqt(ShowCQTContext *s)
>>  yuv_from_cqt(s->c_buf, s->cqt_result, s->sono_g, s->width);
>>  }
>>
>> -static int plot_cqt(AVFilterContext *ctx)
>> +static int plot_cqt(AVFilterContext *ctx, AVFrame **frameout)
>>  {
>>  AVFilterLink *outlink = ctx->outputs[0];
>>  ShowCQTContext *s = ctx->priv;
>> -int ret = 0;
>>
>>  memcpy(s->fft_result, s->fft_data, s->fft_len * sizeof(*s->fft_data));
>>  av_fft_permute(s->fft_ctx, s->fft_result);
>> @@ -1004,7 +1005,7 @@ static int plot_cqt(AVFilterContext *ctx)
>>  if (s->sono_h)
>>  s->update_sono(s->sono_frame, s->c_buf, s->sono_idx);
>>  if (!s->sono_count) {
>> -AVFrame *out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
>> +AVFrame *out = *frameout = ff_get_video_buffer(outlink, outlink->w, 
>> outlink->h);
>>  if (!out)
>>  return AVERROR(ENOMEM);
>>  if (s->bar_h)
>> @@ -1013,14 +1014,13 @@ static int plot_cqt(AVFilterContext *ctx)
>>  s->draw_axis(out, s->axis_frame, s->c_buf, s->bar_h);
>>  if (s->sono_h)
>>  s->draw_sono(out, s->sono_frame, s->bar_h + s->axis_h, 
>> s->sono_idx);
>> -out->pts = s->frame_count;
>> -ret = ff_filter_frame(outlink, out);
>> -s->frame_count++;
>> +out->pts = s->next_pts;
>> +s->next_pts += PTS_STEP;
>>  }
>>  s->sono_count = (s->sono_count + 1) % s->count;
>>  if (s->sono_h)
>>  s->sono_idx = (s->sono_idx + s->sono_h - 1) % s->sono_h;
>> -return ret;
>> +return 0;
>>  }
>>
>>  /* main filter control */
>> @@ -1133,7 +1133,7 @@ static int config_output(AVFilterLink *outlink)
>>  s->format = outlink->format;
>>  outlink->sample_aspect_ratio = av_make_q(1, 1);
>>  outlink->frame_rate = s->rate;
>> -outlink->time_base = av_inv_q(s->rate);
>> +outlink->time_base = av_mul_q(av_inv_q(s->rate), av_make_q(1, 
>> PTS_STEP));
>>  av_log(ctx, AV_LOG_INFO, "video: %dx%d %s %d/%d fps, bar_h = %d, axis_h 
>> = %d, sono_h = %d.\n",
>> s->width, s->height, av_get_pix_fmt_name(s->format), 
>> s->rate.num, s->rate.den,
>> s->bar_h, s->axis_h, s->sono_h);
>> @@ -1209,7 +1209,7 @@ static int config_output(AVFilterLink *outlink)
>>  return AVERROR(ENOMEM);
>>
>>  s->sono_count = 0;
>> -s->frame_count = 0;
>> +s->next_pts = 0;
>>  s->sono_idx = 0;
>>  s->remaining_fill = s->fft_len / 2;
>>  s->remaining_frac = 0;
>> @@ -1232,14 +1232,16 @@ static int config_output(AVFilterLink *outlink)
>>  static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
>>  {
>>  AVFilterContext *ctx = inlink->dst;
>> +AVFilterLink *outlink = ctx->outputs[0];
>>  ShowCQTContext *s = ctx->priv;
>>  int remaining, step, ret, x, i, j, m;
>>  float *audio_data;
>> +AVFrame *out = NULL;
>>
>>  if (!insamples) {
>>  while (s->remaining_fill < s->fft_len / 2) {
>>  memset(>fft_data[s->fft_len - s->remaining_fill], 0, 
>> sizeof(*s->fft_data) * s->remaining_fill);
>> -ret = plot_cqt(ctx);
>> +ret = plot_cqt(ctx, );
>>  if (ret < 0)
>>  return ret;
>>
>> @@ -1248,6 +1250,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
>> *insamples)
>>  for (x = 0; x < (s->fft_len-step); x++)
>>  s->fft_data[x] = s->fft_data[x+step];
>>  s->remaining_fill += step;
>> +
>> +if (out)
>> +return ff_filter_frame(outlink, out);
>>  }
>>  return AVERROR_EOF;
>>  }
>> @@ -1263,12 +1268,30 @@ static int filter_frame(AVFilterLink

Re: [FFmpeg-devel] [PATCH 09/12] avformat/mxfenc: use ff_parse_creation_time_metadata

2016-02-16 Thread Tomas Härdin

On Sat, 2016-02-06 at 20:13 +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavformat/mxfenc.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 6da8b10..cd13f89 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -2041,7 +2041,6 @@ static int mxf_write_header(AVFormatContext *s)
>  int i, ret;
>  uint8_t present[FF_ARRAY_ELEMS(mxf_essence_container_uls)] =
> {0};
>  const MXFSamplesPerFrame *spf = NULL;
> -AVDictionaryEntry *t;
>  int64_t timestamp = 0;
>  
>  if (!s->nb_streams)
> @@ -2212,9 +2211,7 @@ static int mxf_write_header(AVFormatContext *s)
>  sc->order = AV_RB32(sc->track_essence_element_key+12);
>  }
>  
> -if (t = av_dict_get(s->metadata, "creation_time", NULL, 0))
> -timestamp = ff_iso8601_to_unix_time(t->value);
> -if (timestamp)
> +if (ff_parse_creation_time_metadata(s, , 1) > 0)
>  mxf->timestamp = mxf_parse_timestamp(timestamp);
>  mxf->duration = -1;

Looks OK

/Tomas

signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] lavu: add JNI support

2016-02-16 Thread Matthieu Bouron

On Mon, Feb 15, 2016 at 6:56 PM, Hendrik Leppkes 
wrote:

> On Mon, Feb 15, 2016 at 6:52 PM, Matthieu Bouron
>  wrote:
> > From: Matthieu Bouron 
> >
> > ---
> >  configure|   4 +
> >  libavutil/Makefile   |   4 +
> >  libavutil/jni.c  |  55 +++
> >  libavutil/jni.h  |  42 +
> >  libavutil/jni_internal.c | 391
> +++
> >  libavutil/jni_internal.h | 147 ++
> >  6 files changed, 643 insertions(+)
> >  create mode 100644 libavutil/jni.c
> >  create mode 100644 libavutil/jni.h
> >  create mode 100644 libavutil/jni_internal.c
> >  create mode 100644 libavutil/jni_internal.h
> >
> > diff --git a/configure b/configure
> > index 2148f11..d05ae4d 100755
> > --- a/configure
> > +++ b/configure
> > @@ -206,6 +206,7 @@ External library support:
> >--enable-gnutls  enable gnutls, needed for https support
> > if openssl is not used [no]
> >--disable-iconv  disable iconv [autodetect]
> > +  --enable-jni enable JNI support [no]
> >--enable-ladspa  enable LADSPA audio filtering [no]
> >--enable-libass  enable libass subtitles rendering,
> > needed for subtitles and ass filter [no]
> > @@ -1432,6 +1433,7 @@ EXTERNAL_LIBRARY_LIST="
> >  gmp
> >  gnutls
> >  iconv
> > +jni
> >  ladspa
> >  libass
> >  libbluray
> > @@ -5455,6 +5457,7 @@ enabled decklink  && { check_header
> DeckLinkAPI.h || die "ERROR: DeckLin
> >  enabled frei0r&& { check_header frei0r.h || die "ERROR:
> frei0r.h header not found"; }
> >  enabled gmp   && require2 gmp gmp.h mpz_export -lgmp
> >  enabled gnutls&& require_pkg_config gnutls gnutls/gnutls.h
> gnutls_global_init
> > +enabled jni   && { check_header jni.h && enabled pthreads; }
> >  enabled ladspa&& { check_header ladspa.h || die "ERROR:
> ladspa.h header not found"; }
> >  enabled libiec61883   && require libiec61883 libiec61883/iec61883.h
> iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
> >  enabled libass&& require_pkg_config libass ass/ass.h
> ass_library_init
> > @@ -6222,6 +6225,7 @@ echo "threading support ${thread_type-no}"
> >  echo "safe bitstream reader ${safe_bitstream_reader-no}"
> >  echo "SDL support   ${sdl-no}"
> >  echo "opencl enabled${opencl-no}"
> > +echo "JNI support   ${jni-no}"
> >  echo "texi2html enabled ${texi2html-no}"
> >  echo "perl enabled  ${perl-no}"
> >  echo "pod2man enabled   ${pod2man-no}"
> > diff --git a/libavutil/Makefile b/libavutil/Makefile
> > index 65b2d25..ab39d41 100644
> > --- a/libavutil/Makefile
> > +++ b/libavutil/Makefile
> > @@ -72,6 +72,8 @@ HEADERS-$(CONFIG_LZO)   += lzo.h
> >
> >  HEADERS-$(CONFIG_OPENCL)+= opencl.h
> >
> > +HEADERS-$(CONFIG_JNI)   += jni.h
> > +
> >  ARCH_HEADERS = bswap.h
> \
> > intmath.h
> \
> > intreadwrite.h
>  \
> > @@ -148,6 +150,7 @@ OBJS-$(!HAVE_ATOMICS_NATIVE)+= atomic.o
>\
> >
> >  OBJS-$(CONFIG_LZO)  += lzo.o
> >  OBJS-$(CONFIG_OPENCL)   += opencl.o opencl_internal.o
> > +OBJS-$(CONFIG_JNI)  += jni.o jni_internal.o
> >
> >  OBJS += $(COMPAT_OBJS:%=../compat/%)
> >
> > @@ -158,6 +161,7 @@ SKIPHEADERS-$(HAVE_ATOMICS_GCC)+=
> atomic_gcc.h
> >  SKIPHEADERS-$(HAVE_ATOMICS_SUNCC)  += atomic_suncc.h
> >  SKIPHEADERS-$(HAVE_ATOMICS_WIN32)  += atomic_win32.h
> >  SKIPHEADERS-$(CONFIG_OPENCL)   += opencl.h
> > +SKIPHEADERS-$(CONFIG_JNI)  += jni_internal.h
> >
> >  TESTPROGS = adler32
>  \
> >  aes
>  \
> > diff --git a/libavutil/jni.c b/libavutil/jni.c
> > new file mode 100644
> > index 000..fb89426
> > --- /dev/null
> > +++ b/libavutil/jni.c
> > @@ -0,0 +1,55 @@
> > +/*
> > + * Copyright (c) 2015-2016 Matthieu Bouron  stupeflix.com>
> > + *
> > + * 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

Re: [FFmpeg-devel] [PATCH] avutil: disable arch specific intmath routines if optimizations are disabled

2016-02-16 Thread Michael Niedermayer

On Tue, Feb 16, 2016 at 11:00:38PM +0800, Yu Xiaolei wrote:
> On Tue, Feb 16, 2016 at 9:01 PM, Michael Niedermayer  > wrote:
> 
> > On Tue, Feb 16, 2016 at 02:40:10PM +0800, Xiaolei Yu wrote:
> > > Current intmath routines for arm require inter-procedure constant
> > propagation
> > > and fail to compile when optimizations are disabled.
> > > ---
> > >  configure   | 1 +
> > >  libavutil/intmath.h | 2 ++
> > >  2 files changed, 3 insertions(+)
> >
> > on arm without opts and this patch i get
> > src/libavcodec/arm/aac.h: In function ‘VMUL4S’:
> > src/libavcodec/arm/aac.h:102:5: error: can't find a register in class
> > ‘LO_REGS’ while reloading ‘asm’
> > src/libavcodec/arm/aac.h:102:5: error: ‘asm’ operand has impossible
> > constraints
> > make: *** [libavcodec/aacdec.o] Error 1
> >
> >
> This error seems unrelated to the patch, but I am not sure as I am only
> building some selected codecs.
> Can you build again without the patch?
> 
> Without the patch I get:
> In file included from src/libavutil/intmath.h:30:0,
>  from src/libavutil/common.h:106,
>  from src/libavutil/avutil.h:288,
>  from src/libavutil/samplefmt.h:24,
>  from src/libavcodec/avcodec.h:31,
>  from src/libavcodec/internal.h:33,
>  from src/libavcodec/h264_direct.c:28:
> src/libavutil/arm/intmath.h: In function 'get_scale_factor':
> src/libavutil/arm/intmath.h:69:5: warning: asm operand 2 probably doesn't
> match constraints
>  __asm__ ("ssat %0, %2, %1" : "=r"(x) : "r"(a), "i"(p+1));
>  ^
> src/libavutil/arm/intmath.h:69:5: error: impossible constraint in 'asm'

yes, its worse without teh patch


> 
> on x86 build passes with and without the patch here
> > with what compiler is this needed ?
> >
> >
> Yes, x86 builds fine without this patch. But the underlying problem is not
> arch specific and may be encountered in other inline asm. I think current
> patch is more consistent if we consider these routines as manual
> optimizations.

i dont uderstand
the problem is specific to 2 arm asm functions
you disable all intmath arm functions
you disable all intmath x86 functions
(none use the immedeate operand so cannot be affected)
you leave all other x86 and arm functions enabled

I think the 2 affected functions should be put under #if
there should be no need to disable anything else
its just the functions that use the immedeate operand which fail id
assume

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

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


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

Re: [FFmpeg-devel] MediaCodec support

2016-02-16 Thread Matthieu Bouron

On Tue, Feb 16, 2016 at 2:47 PM, Matthieu Bouron 
wrote:

>
>
> On Tue, Feb 16, 2016 at 12:36 PM, wm4  wrote:
>
>> On Tue, 16 Feb 2016 12:09:58 +0100
>> Matthieu Bouron  wrote:
>>
>> > On Tue, Feb 16, 2016 at 10:41 AM, wm4  wrote:
>> >
>> > > On Mon, 15 Feb 2016 18:52:25 +0100
>> > > Matthieu Bouron  wrote:
>> > >
>> > > > Hello,
>> > > >
>> > > > The following patchset adds basic MediaCodec support to libavcodec,
>> ie:
>> > > only
>> > > > h264 is supported and the HWAccel part (Surface output) is missing.
>> > > >
>> > > > JNI comes as a dependency. The JNI support is based on the same
>> patchset
>> > > I've
>> > > > sent some time ago with some improvements.
>> > > >
>> > > > I originally developed the patch against the Ndk API (Android >=
>> 5.0)
>> > > but then
>> > > > changed my mind and go with the JNI version for two main reasons:
>> > > >
>> > > >   * there are still too many android 4 devices
>> > > >   * there is still needs for some jni bits as the MediaCodec Ndk API
>> > > >   does not provide a way to known the codec name which is mandatory
>> > > >   to workaround or blacklist some implementations (ie: do not use
>> known
>> > > >   software decoders, workaround OMX.SEC.avc.dec as it returns
>> invalid
>> > > >   stride and slice-height values, ...)
>> > > >
>> > >
>> > > I guess there's no way around it.
>> > >
>> > > > I decided to mimic the Ndk API minus a few differences (see
>> > > > mediacodec_wrapper.h) so it can be ported more easily to the C API
>> in the
>> > > > future. The other reason being it is to totally hide the JNI code.
>> > > >
>> > > > The HWAccel part is on my todo list but I wanted a real use case to
>> > > develop the
>> > > > API against.
>> > > >
>> > > > The development branch can be found here:
>> > > > https://github.com/mbouron/FFmpeg/tree/feature/mediacodec-support
>> > > >
>> > > > --enable-jni and --enable-mediacodec is required to build the
>> > > h264_mediacodec
>> > > > decoder.
>> > > >
>> > > > av_jni_register_java_vm(vm) must called before lavc is used.
>> > >
>> > > Wasn't there some sort of trick that could avoid this?
>> > >
>> >
>> > The workaround for this is to call a *private* C++ API, and in
>> particular
>> > checking that the variable jni_invocation_ is initialized
>> > and call the GetCreatedJavaVMS function from:
>> >
>> https://android.googlesource.com/platform/libnativehelper/+/master/JniInvocation.cpp
>> >
>> >
>>
>> If I read this right, the host can somehow initialize the JNI, and then
>> JNI_GetCreatedJavaVMs() will work?
>>
>
> AFAIK, This is initialized when the VM (dalvik or art) is initialized.
>
>>
>> Though it looks like that function will just crash if the jni stuff is
>> not initialized. With no way to ensure or verify initialization using
>> public (or just C++?) API. Well, I guess this is Android quality code...
>>
>
> Well it is ... this api is not public.
>

I implemented this and pushed it to the development branch, so there is no
need to call av_jni_register_java_vm anymore (so this part of the public
api will be removed)

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

Re: [FFmpeg-devel] Question about "make distclean" after "git pull"

2016-02-16 Thread Nicolas George

L'octidi 28 pluviôse, an CCXXIV, Mats Peterson a écrit :
> Is it very important to use a "make distclean" after a "git pull"? It
> depends on the changes made to the newly pulled code, I guess.

Exactly. The most common issue is when files are renamed or deleted: without
distclean, the dependency files are still there and make will fail because
it thinks it still needs them.

So basically: if you forget distclean and it works, then it was probably not
necessary; and if build fails, you know distclean was necessary. There may
have been cases where forgetting distclean would cause bugs more subtle than
that, but I do not remember the specifics.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] Question about "make distclean" after "git pull"

2016-02-16 Thread Mats Peterson

Is it very important to use a "make distclean" after a "git pull"? It 
depends on the changes made to the newly pulled code, I guess.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: disable arch specific intmath routines if optimizations are disabled

2016-02-16 Thread Yu Xiaolei

On Tue, Feb 16, 2016 at 9:01 PM, Michael Niedermayer  wrote:

> On Tue, Feb 16, 2016 at 02:40:10PM +0800, Xiaolei Yu wrote:
> > Current intmath routines for arm require inter-procedure constant
> propagation
> > and fail to compile when optimizations are disabled.
> > ---
> >  configure   | 1 +
> >  libavutil/intmath.h | 2 ++
> >  2 files changed, 3 insertions(+)
>
> on arm without opts and this patch i get
> src/libavcodec/arm/aac.h: In function ‘VMUL4S’:
> src/libavcodec/arm/aac.h:102:5: error: can't find a register in class
> ‘LO_REGS’ while reloading ‘asm’
> src/libavcodec/arm/aac.h:102:5: error: ‘asm’ operand has impossible
> constraints
> make: *** [libavcodec/aacdec.o] Error 1
>
>
This error seems unrelated to the patch, but I am not sure as I am only
building some selected codecs.
Can you build again without the patch?

Without the patch I get:
In file included from src/libavutil/intmath.h:30:0,
 from src/libavutil/common.h:106,
 from src/libavutil/avutil.h:288,
 from src/libavutil/samplefmt.h:24,
 from src/libavcodec/avcodec.h:31,
 from src/libavcodec/internal.h:33,
 from src/libavcodec/h264_direct.c:28:
src/libavutil/arm/intmath.h: In function 'get_scale_factor':
src/libavutil/arm/intmath.h:69:5: warning: asm operand 2 probably doesn't
match constraints
 __asm__ ("ssat %0, %2, %1" : "=r"(x) : "r"(a), "i"(p+1));
 ^
src/libavutil/arm/intmath.h:69:5: error: impossible constraint in 'asm'

on x86 build passes with and without the patch here
> with what compiler is this needed ?
>
>
Yes, x86 builds fine without this patch. But the underlying problem is not
arch specific and may be encountered in other inline asm. I think current
patch is more consistent if we consider these routines as manual
optimizations.

The code __asm__ ("ssat %0, %2, %1" : "=r"(x) : "r"(a), "i"(p+1)) is in
fact illegal as the bit position (p+1) is not a compile time constant.  The
compiler can emit code only because p is known after constant propagation.

I am using gcc-4.9 shipped by android ndk r10e.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets

2016-02-16 Thread Mats Peterson


On 02/16/2016 03:34 PM, Michael Niedermayer wrote:


no, that patch is left for others to decide, my oppinion is that the
muxer bug must be fixed first to prevent the generation of invalid
files. I wanted to look into it as you dont look into it but i dont
have time now



That's OK regarding not having time. But the reason I don't look into it 
is that I'm afraid of messing things up. I don't have enough knowledge 
about the details when it comes to the muxing side of things.


Mats

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets

2016-02-16 Thread Mats Peterson


On 02/16/2016 03:34 PM, Michael Niedermayer wrote:

And what about the monowhite switching code?



Did you forget that one??


no, that patch is left for others to decide, my oppinion is that the
muxer bug must be fixed first to prevent the generation of invalid
files. I wanted to look into it as you dont look into it but i dont
have time now

Please be patient, also its not going to be done sooner by asked 10
times a day privately and on the ML



wm4 has already agreed on its redundant character. And as I have stated 
thousands of times, monow/monob shouldn't be used for palettized data. 
Just because a 1 bpp raw AVI file lacks a palette, it doesn't suddenly 
become monochrome. monow/monob is suitable for file formats with 
explicit black & white modes, like nut, TIFF and PNG. The BMP code does 
the right thing, it uses pal8 exclusively for 1 bpp.


Regarding "generation of invalid files", the only valid files FFmpeg 
will currently generate when using rawvideo is nut, regardless of using 
pal8 for 1 bpp raw AVI or not. The stride is incorrect for AVI and 
QuickTime files created with "-vcodec rawvideo", regardless of bit depth.


Mats


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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets

2016-02-16 Thread Michael Niedermayer

On Tue, Feb 16, 2016 at 03:06:35PM +0100, Mats Peterson wrote:
> On 02/16/2016 03:04 PM, Mats Peterson wrote:
> >Michael Niedermayer  skrev: (16 februari 2016 
> >15:03:13 CET)
> >>On Tue, Feb 16, 2016 at 11:49:31AM +0100, Mats Peterson wrote:
> >>>I have removed the 4-byte alignment line.
> >>>
> >>>--
> >>>Mats Peterson
> >>>http://matsp888.no-ip.org/~mats/
> >>
> >>>  rawdec.c |8 +++-
> >>>  1 file changed, 7 insertions(+), 1 deletion(-)
> >>>8368a0a3c0eab1db6651662f5108dac88e986c59
> >>0002-lavc-rawdec-Retrieve-nut-palette-from-packets.patch
> >>> From 6256d18629e70c24260e4cfb1993411ccebfac73 Mon Sep 17 00:00:00
> >>2001
> >>>From: Mats Peterson 
> >>>Date: Tue, 16 Feb 2016 11:44:50 +0100
> >>>Subject: [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets
> >>
> >>applied
> >>
> >>thanks
> >>
> >>[...]
> >
> >And what about the monowhite switching code?
> >
> 
> Did you forget that one??

no, that patch is left for others to decide, my oppinion is that the
muxer bug must be fixed first to prevent the generation of invalid
files. I wanted to look into it as you dont look into it but i dont
have time now

Please be patient, also its not going to be done sooner by asked 10
times a day privately and on the ML

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

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


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

Re: [FFmpeg-devel] [PATCH] Do not remove HWACCEL flag with FF_API_XVMC

2016-02-16 Thread Ronald S. Bultje

Hi,

On Tue, Feb 16, 2016 at 8:25 AM, Ivan Kalvachev 
wrote:

> On 2/15/16, Hendrik Leppkes  wrote:
> > On Mon, Feb 15, 2016 at 3:13 PM, Ivan Kalvachev 
> > wrote:
> >> On 2/15/16, Ronald S. Bultje  wrote:
> >>> Hi,
> >>>
> >>> On Mon, Feb 15, 2016 at 8:26 AM, Ivan Kalvachev 
> >>> wrote:
> >>>
>  On 2/15/16, Hendrik Leppkes  wrote:
>  > On Mon, Feb 15, 2016 at 2:13 PM, Ivan Kalvachev <
> ikalvac...@gmail.com>
>  > wrote:
>  >> Do not remove HWACCEL flag with FF_API_XVMC since the
>  >> flag is supposed to be used as generic one.
>  >>
>  >
>  > The flag is unused except by the XVMC decoder, so removing it with
> it
>  > seems appropriate.
> 
>  Should I add it to the other hwaccel decoders?
> >>>
> >>>
> >>> Would it have a real-world purpose?
> >>
> >> Does any of the other Capability flags serve any real-world purpose?
> >> e.g. CAP_DRAW_HORIZ_BAND or  CAP_DR1.
> >>
> >> The *_BAND indicates usage of draw_horiz_band callback().
> >> The * _DR1 indicates usage of get_buffer(),
> >
> > DR1 could probably be removed as well, since practically every codec
> > we have does it this way now.
> > But removing existing things and adding new things are entirely
> > different topics.
>
> That's not correct - *_HWACCEL isn't new thing either.
>
> You do understand that blocking this change means
> removing existing thing, don't you?
>
>
> >> The *_HWACCEL is supposed to indicate usage of get_format() and
> >> availability of certain data, when it is called.
> >>
> >> Since the trend is removing codecs that do only hwaccel,
> >> I think it is useful for the application to know that the codec
> >> can do more than software decoding.
> >>
> >
> > This is hardly useful, because hwaccels do not "just work", for proper
> > hwaccel support you need to hardcode the available codecs in your
> > application and appropriate conditions for them, so things like
> > profile checks, hardware compatibility checks, etc can be implemented.
> > A generic "this codec does hwaccel" flag is not very useful here.
>
> Yes, it is not mandatory for decoding.
>
> But that's true for all capabilities flag, including the threading ones.
> If your application supports threading you can always use the thread
> safe functions.
>

Hold on a minute, these aren't remotely the same. The slice-thread or
frame-thread flags indicate that the decoder supports a form of MT, and has
significant effect on how the decoder is invoked. These flags are not
informational-only. There's other flags that are not information-only also.
Please distinguish between them.

> The capability flags are there to make things simpler.
>

No.

This is really important: no.

The capability flags are to indicate capabilities of the codec such that
common code (inside ffmpeg!) can invoke the decoder functions correctly and
most optimally. Calling a single-threaded-only decoder with MT will cause
corrupt decoding and crashes. That's bad. Likewise, invoking
single-threaded decoding on a MT decoder will cause a significant slowdown.
Also bad.

The hwaccel flag is informational. The actual capability is checked by
existence of the ACHWAccel with that particular codec id. These info-only
flags can easily be forgotten or be misinterpreted. The AVHWAccel check I
indicated to you is more complete, more informational and guaranteed to be
correct for the particular target platform you're on.

Currently the only way an application could find that given codec
> supports hwaccel
> is to decode a frame, wait for get_format() callback and check the pixfmt
> list.
>
> Ronald proposed to implement public function that would
> query if given codec support given hwaccel pixfmt.
> It's good, but it is not simple.
> (Listing decoders is 400+ codecs * 10 hwaccel types,
> traversing 40+ element table for each combination.)
>

So your CPU is from the mid-60s? I mean, you can do that in 1/100th of the
time it takes to decode one block in a modern video codec. And that's an
issue for initialization code why exactly?

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets

2016-02-16 Thread Mats Peterson


On 02/16/2016 03:04 PM, Mats Peterson wrote:

Michael Niedermayer  skrev: (16 februari 2016 15:03:13 
CET)

On Tue, Feb 16, 2016 at 11:49:31AM +0100, Mats Peterson wrote:

I have removed the 4-byte alignment line.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  rawdec.c |8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)
8368a0a3c0eab1db6651662f5108dac88e986c59

0002-lavc-rawdec-Retrieve-nut-palette-from-packets.patch

 From 6256d18629e70c24260e4cfb1993411ccebfac73 Mon Sep 17 00:00:00

2001

From: Mats Peterson 
Date: Tue, 16 Feb 2016 11:44:50 +0100
Subject: [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets


applied

thanks

[...]


And what about the monowhite switching code?



Did you forget that one??

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets

2016-02-16 Thread Mats Peterson

Michael Niedermayer  skrev: (16 februari 2016 15:03:13 
CET)
>On Tue, Feb 16, 2016 at 11:49:31AM +0100, Mats Peterson wrote:
>> I have removed the 4-byte alignment line.
>> 
>> -- 
>> Mats Peterson
>> http://matsp888.no-ip.org/~mats/
>
>>  rawdec.c |8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>> 8368a0a3c0eab1db6651662f5108dac88e986c59 
>0002-lavc-rawdec-Retrieve-nut-palette-from-packets.patch
>> From 6256d18629e70c24260e4cfb1993411ccebfac73 Mon Sep 17 00:00:00
>2001
>> From: Mats Peterson 
>> Date: Tue, 16 Feb 2016 11:44:50 +0100
>> Subject: [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets
>
>applied
>
>thanks
>
>[...]

And what about the monowhite switching code?
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets

2016-02-16 Thread Michael Niedermayer

On Tue, Feb 16, 2016 at 11:49:31AM +0100, Mats Peterson wrote:
> I have removed the 4-byte alignment line.
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  rawdec.c |8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 8368a0a3c0eab1db6651662f5108dac88e986c59  
> 0002-lavc-rawdec-Retrieve-nut-palette-from-packets.patch
> From 6256d18629e70c24260e4cfb1993411ccebfac73 Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Tue, 16 Feb 2016 11:44:50 +0100
> Subject: [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

Re: [FFmpeg-devel] MediaCodec support

2016-02-16 Thread Matthieu Bouron

On Tue, Feb 16, 2016 at 12:36 PM, wm4  wrote:

> On Tue, 16 Feb 2016 12:09:58 +0100
> Matthieu Bouron  wrote:
>
> > On Tue, Feb 16, 2016 at 10:41 AM, wm4  wrote:
> >
> > > On Mon, 15 Feb 2016 18:52:25 +0100
> > > Matthieu Bouron  wrote:
> > >
> > > > Hello,
> > > >
> > > > The following patchset adds basic MediaCodec support to libavcodec,
> ie:
> > > only
> > > > h264 is supported and the HWAccel part (Surface output) is missing.
> > > >
> > > > JNI comes as a dependency. The JNI support is based on the same
> patchset
> > > I've
> > > > sent some time ago with some improvements.
> > > >
> > > > I originally developed the patch against the Ndk API (Android >= 5.0)
> > > but then
> > > > changed my mind and go with the JNI version for two main reasons:
> > > >
> > > >   * there are still too many android 4 devices
> > > >   * there is still needs for some jni bits as the MediaCodec Ndk API
> > > >   does not provide a way to known the codec name which is mandatory
> > > >   to workaround or blacklist some implementations (ie: do not use
> known
> > > >   software decoders, workaround OMX.SEC.avc.dec as it returns invalid
> > > >   stride and slice-height values, ...)
> > > >
> > >
> > > I guess there's no way around it.
> > >
> > > > I decided to mimic the Ndk API minus a few differences (see
> > > > mediacodec_wrapper.h) so it can be ported more easily to the C API
> in the
> > > > future. The other reason being it is to totally hide the JNI code.
> > > >
> > > > The HWAccel part is on my todo list but I wanted a real use case to
> > > develop the
> > > > API against.
> > > >
> > > > The development branch can be found here:
> > > > https://github.com/mbouron/FFmpeg/tree/feature/mediacodec-support
> > > >
> > > > --enable-jni and --enable-mediacodec is required to build the
> > > h264_mediacodec
> > > > decoder.
> > > >
> > > > av_jni_register_java_vm(vm) must called before lavc is used.
> > >
> > > Wasn't there some sort of trick that could avoid this?
> > >
> >
> > The workaround for this is to call a *private* C++ API, and in particular
> > checking that the variable jni_invocation_ is initialized
> > and call the GetCreatedJavaVMS function from:
> >
> https://android.googlesource.com/platform/libnativehelper/+/master/JniInvocation.cpp
> >
> >
>
> If I read this right, the host can somehow initialize the JNI, and then
> JNI_GetCreatedJavaVMs() will work?
>

AFAIK, This is initialized when the VM (dalvik or art) is initialized.

>
> Though it looks like that function will just crash if the jni stuff is
> not initialized. With no way to ensure or verify initialization using
> public (or just C++?) API. Well, I guess this is Android quality code...
>

Well it is ... this api is not public.


>
> > > > The patchset also includes supports for Android content uris which
> is not
> > > > mandatory for the mediacodec supports but helps dealing with them
> more
> > > > seamlessly.
> > >
> > > I'm still not convinced that this is necessary (custom I/O allows any
> > > application to provide its own I/O callbacks). This would also avoid
> > > the need for avpriv JNI API, since it'd be confined to libavcodec.
> > >
> >
> > Content uris are the proper way to deal with medias on Android since
> > version 5.0.
>
> What exactly does this mean? What are content URIs anyway? Some crazy
> Android-specific crap to make URLs harder? Is it not possible to turn
> this into something reasonable on a higher level? Does MediaCodec have
> to access it? (Would be strange since the demuxer would be between
> that.)
>

Content uris are a "protocol" used to access files from other apps (meaning
the accessed files can be private).
Every application can create its own content uris and attaches temporary or
definitive permissions (r/w), so other applications can acces its data.

Example:
From your application (A), the user choose to grab some content from
application (B) (let's say a photos gallery), it opens application (B) and
let the user choose a collection of medias. When the selection is done,
Application (A) get the selection of medias as a collection of content uris
(which have generally temporary read permissions). At this point you can't
have a file path because the content could be on the app (B) private
storage but you can have access to a filestream (java) or a regular file
descriptor.
Note: It is considered really bad practice to copy the content of the uri
locally to have access to a regular file path.


> > Having it in lavf as a protocol would prevent anyone who wants
> > to support it in its application to re-do a custom io wrapper around it.
> > IMHO, it's like the other protocols we already support (samba, ssh,
> gopher,
> > icecast, ...) and the code that adds its support is not intrusive (it
> just
> > returns a fd that is then used by the file protocol functions).
>
> Can't judge it, but we don't like all these

Re: [FFmpeg-devel] [PATCH] Do not remove HWACCEL flag with FF_API_XVMC

2016-02-16 Thread Ivan Kalvachev

On 2/15/16, Hendrik Leppkes  wrote:
> On Mon, Feb 15, 2016 at 3:13 PM, Ivan Kalvachev 
> wrote:
>> On 2/15/16, Ronald S. Bultje  wrote:
>>> Hi,
>>>
>>> On Mon, Feb 15, 2016 at 8:26 AM, Ivan Kalvachev 
>>> wrote:
>>>
 On 2/15/16, Hendrik Leppkes  wrote:
 > On Mon, Feb 15, 2016 at 2:13 PM, Ivan Kalvachev 
 > wrote:
 >> Do not remove HWACCEL flag with FF_API_XVMC since the
 >> flag is supposed to be used as generic one.
 >>
 >
 > The flag is unused except by the XVMC decoder, so removing it with it
 > seems appropriate.

 Should I add it to the other hwaccel decoders?
>>>
>>>
>>> Would it have a real-world purpose?
>>
>> Does any of the other Capability flags serve any real-world purpose?
>> e.g. CAP_DRAW_HORIZ_BAND or  CAP_DR1.
>>
>> The *_BAND indicates usage of draw_horiz_band callback().
>> The * _DR1 indicates usage of get_buffer(),
>
> DR1 could probably be removed as well, since practically every codec
> we have does it this way now.
> But removing existing things and adding new things are entirely
> different topics.

That's not correct - *_HWACCEL isn't new thing either.

You do understand that blocking this change means
removing existing thing, don't you?

>> The *_HWACCEL is supposed to indicate usage of get_format() and
>> availability of certain data, when it is called.
>>
>> Since the trend is removing codecs that do only hwaccel,
>> I think it is useful for the application to know that the codec
>> can do more than software decoding.
>>
>
> This is hardly useful, because hwaccels do not "just work", for proper
> hwaccel support you need to hardcode the available codecs in your
> application and appropriate conditions for them, so things like
> profile checks, hardware compatibility checks, etc can be implemented.
> A generic "this codec does hwaccel" flag is not very useful here.

Yes, it is not mandatory for decoding.

But that's true for all capabilities flag, including the threading ones.
If your application supports threading you can always use the thread
safe functions.

The capability flags are there to make things simpler.

Currently the only way an application could find that given codec
supports hwaccel
is to decode a frame, wait for get_format() callback and check the pixfmt list.

Ronald proposed to implement public function that would
query if given codec support given hwaccel pixfmt.
It's good, but it is not simple.
(Listing decoders is 400+ codecs * 10 hwaccel types,
traversing 40+ element table for each combination.)

It literally cannot be simpler than using the already existing flag.
The bit is already allocated for that, it is kept unused in the new
AV_CODEC_CAP*

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/rawdec: Remove temporary monowhite switching code for 1 bpp AVI without a palette

2016-02-16 Thread Mats Peterson

Mats Peterson  skrev: (16 februari 2016 
14:06:07 CET)
>Mats Peterson  skrev: (16 februari
>2016 11:48:28 CET)
>>
>And once more Michael, give me one sensible reason as to why you want
>to fix the long standing muxer issues before applying these patches.
>That will seemingly take forever, and it won't make any difference if
>you apply these patches now or in a hundred years when the muxer side
>is fixed. Furthermore, FFmpeg is used by several media players, and
>they couldn't care less about muxing to raw AVI or QuickTime not
>working correctly.
>-- 
>Mats Peterson
>http://matsp888.no-ip.org/~mats/
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Just add a blurb to the documentation regarding the use of "-vcodec rawvideo" 
with AVI or QuickTime not working correctly, so nut should be used instead.
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/rawdec: Remove temporary monowhite switching code for 1 bpp AVI without a palette

2016-02-16 Thread Mats Peterson

Mats Peterson  skrev: (16 februari 2016 
11:48:28 CET)
>
And once more Michael, give me one sensible reason as to why you want to fix 
the long standing muxer issues before applying these patches. That will 
seemingly take forever, and it won't make any difference if you apply these 
patches now or in a hundred years when the muxer side is fixed. Furthermore, 
FFmpeg is used by several media players, and they couldn't care less about 
muxing to raw AVI or QuickTime not working correctly.
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil: disable arch specific intmath routines if optimizations are disabled

2016-02-16 Thread Michael Niedermayer

On Tue, Feb 16, 2016 at 02:40:10PM +0800, Xiaolei Yu wrote:
> Current intmath routines for arm require inter-procedure constant propagation
> and fail to compile when optimizations are disabled.
> ---
>  configure   | 1 +
>  libavutil/intmath.h | 2 ++
>  2 files changed, 3 insertions(+)

on arm without opts and this patch i get
src/libavcodec/arm/aac.h: In function ‘VMUL4S’:
src/libavcodec/arm/aac.h:102:5: error: can't find a register in class ‘LO_REGS’ 
while reloading ‘asm’
src/libavcodec/arm/aac.h:102:5: error: ‘asm’ operand has impossible constraints
make: *** [libavcodec/aacdec.o] Error 1

on x86 build passes with and without the patch here
with what compiler is this needed ?

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

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


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

Re: [FFmpeg-devel] [PATCH] avfilter: add BobWeaver deinterlacing filter

2016-02-16 Thread Thomas Mundt

>>> Paul B Mahol  schrieb am Di, 16.2.2016:On 2/8/16, Thomas 
>>> Mundt  wrote:
> Hendrik Leppkes  schrieb am Mo, 8.2.2016:
>>> How does the speed compare to YADIF?
>>> Or in other words, is it usable in real-time, or rather designed for
>>> offline processing?
>>>
>> YADIF is quicker, because of its CPU optimizations. Without CPU
>> optimizations BobWeaver is quicker.
>> It should definitely be usable in real-time.
> 
> Could you provide samples when this filters gives better output than
> yadif/w3fdif ?

Shure. Is there an intended place where I can upload them or is it free choice?
Please note that the output is not better than yadif AND w3dif. But it will 
look like yadif when yadif is better than w3fdif and look like w3fdif when 
w3fdif is better than yadif.
I´m at work atm, but will upload the samples tonight.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][PATCH][BROKEN] avfilter: drawutils >8 bit support

2016-02-16 Thread Paul B Mahol

On 2/16/16, Nicolas George  wrote:
> L'octidi 28 pluviose, an CCXXIV, Paul B Mahol a ecrit :
>> Now with blend properly working.
>
> Nice. Have you checked how it affects performance for the cases that were
> already supported?

It should be marginal.

>
>> But now I have issues with fate ref update, it mess up terminal here
>> so one needs to use reset.
>
> This has been a common issue in the Unix world for a long time, although it
> became less frequent in recent years. It has nothing to do with FATE or
> FFmpeg, it is just a combination between braindead tty API in Unix and poor
> default configuration of shells. It was discussed here last summer:
>
> #   -> "ttyctl -f" in ~/.zshrc, "bash_tty_mode=$(stty -g);
> #   PROMPT_COMMAND='stty $bash_tty_mode'" in ~/.bashrc; that can be added
> in
> #   the FAQ or the wiki.
>
> The solution with zsh is more efficient.

Well, even if I ignore that one, the generated diff is mess because of crashes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC][PATCH][BROKEN] avfilter: drawutils >8 bit support

2016-02-16 Thread Nicolas George

L'octidi 28 pluviôse, an CCXXIV, Paul B Mahol a écrit :
> Now with blend properly working.

Nice. Have you checked how it affects performance for the cases that were
already supported?

> But now I have issues with fate ref update, it mess up terminal here
> so one needs to use reset.

This has been a common issue in the Unix world for a long time, although it
became less frequent in recent years. It has nothing to do with FATE or
FFmpeg, it is just a combination between braindead tty API in Unix and poor
default configuration of shells. It was discussed here last summer:

#   -> "ttyctl -f" in ~/.zshrc, "bash_tty_mode=$(stty -g);
#   PROMPT_COMMAND='stty $bash_tty_mode'" in ~/.bashrc; that can be added in
#   the FAQ or the wiki.

The solution with zsh is more efficient.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] tests/fate: added dnxhr parser regression test

2016-02-16 Thread Michael Niedermayer

On Mon, Feb 15, 2016 at 10:01:27PM -0800, Mark Reid wrote:
> Hi,
> This patch adds a fate test for the parsing raw dnxhr streams.
> 
> Can someone add this test footage to fate for me?
> https://dl.dropboxusercontent.com/u/170952/fate/dnxhd/dnxhr_cid1274.dnxhr
> it goes in
> FATE_ROOT/dnxhd/dnxhr_cid1274.dnxhr

added

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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: add BobWeaver deinterlacing filter

2016-02-16 Thread Paul B Mahol

On 2/8/16, Thomas Mundt  wrote:
 Hendrik Leppkes  schrieb am Mo, 8.2.2016:
>> How does the speed compare to YADIF?
>> Or in other words, is it usable in real-time, or rather designed for
>> offline processing?
>>
> YADIF is quicker, because of its CPU optimizations. Without CPU
> optimizations BobWeaver is quicker.
> It should definitely be usable in real-time.

Could you provide samples when this filters gives better output than
yadif/w3fdif ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/libzvbi-teletextdec: use common functions for matching data_unit_id and data_identifier

2016-02-16 Thread Michael Niedermayer

On Tue, Feb 16, 2016 at 03:35:53AM +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavcodec/libzvbi-teletextdec.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)

LGTM

thanks

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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH] avfilter: add firequalizer filter

2016-02-16 Thread Paul B Mahol

On 2/16/16, Muhammad Faiz  wrote:
> patch attached
>
> thank's
>
>
> ---
>  Changelog |   1 +
>  MAINTAINERS   |   1 +
>  configure |   2 +
>  doc/filters.texi  | 109 
>  libavfilter/Makefile  |   1 +
>  libavfilter/af_firequalizer.c | 592 
> ++
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/version.h |   2 +-
>  8 files changed, 708 insertions(+), 1 deletion(-)
>  create mode 100644 libavfilter/af_firequalizer.c
>
> diff --git a/Changelog b/Changelog
> index 96a9955..1794164 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest 
> within each release,
>  releases are sorted from youngest to oldest.
>
>  version :
> +- firequalizer filter
>

Interesting.

>
>  version 3.0:
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e57150d..9f7baf0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -353,6 +353,7 @@ Filters:
>af_biquads.c  Paul B Mahol
>af_chorus.c   Paul B Mahol
>af_compand.c  Paul B Mahol
> +  af_firequalizer.c Muhammad Faiz
>af_ladspa.c   Paul B Mahol
>af_pan.c  Nicolas George
>af_sidechaincompress.cPaul B Mahol
> diff --git a/configure b/configure
> index 2148f11..b775cb9 100755
> --- a/configure
> +++ b/configure
> @@ -2857,6 +2857,8 @@ eq_filter_deps="gpl"
>  fftfilt_filter_deps="avcodec"
>  fftfilt_filter_select="rdft"
>  find_rect_filter_deps="avcodec avformat gpl"
> +firequalizer_filter_deps="avcodec"
> +firequalizer_filter_select="rdft"
>  flite_filter_deps="libflite"
>  frei0r_filter_deps="frei0r dlopen"
>  frei0r_src_filter_deps="frei0r dlopen"
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 68f54f1..67506dc 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -2366,6 +2366,115 @@ Sets the difference coefficient (default: 2.5). 0.0 
> means mono sound
>  Enable clipping. By default is enabled.
>  @end table
>
> +@section firequalizer
> +Apply FIR Equalization using arbitrary frequency response.
> +
> +The filter accepts the following option:
> +
> +@table @option
> +@item gain
> +Set gain curve equation (in dB). The expression can contain variables:
> +@table @option
> +@item f
> +the evaluated frequency
> +@item sr
> +sample rate
> +@item ch
> +channel number, set to 0 when multichannels evaluation is disabled
> +@item chid
> +channel id, see libavutil/channel_layout.h, set to the first channel id when
> +multichannels evaluation is disabled
> +@item chs
> +number of channels
> +@item chlayout
> +channel_layout, see libavutil/channel_layout.h
> +
> +@end table
> +and functions:
> +@table @option
> +@item gain_interpolate(f)
> +interpote gain on frequency f based on gain_entry
> +@end table
> +This option is also available as command. Default is 
> @code{gain_interpolate(f)}.
> +
> +@item gain_entry
> +Set gain entry for gain_interpolate function. The expression can
> +contain functions:
> +@table @option
> +@item entry(f, g)
> +store gain entry at frequency f with value g
> +@end table
> +This option is also available as command.
> +
> +@item delay
> +Set filter delay in seconds. Higher value means more accurate.
> +Default is @code{0.01}.
> +
> +@item accuracy
> +Set filter accuracy in Hz. Lower value means more accurate.
> +Default is @code{5}.
> +
> +@item wfunc
> +Set window function. Acceptable values are:
> +@table @option
> +@item rectangular
> +rectangular window, useful when gain curve is already smooth
> +@item hann
> +hann window (default)
> +@item hamming
> +hamming window
> +@item blackman
> +blackman window
> +@item nuttall3
> +3-terms continuous 1st derivative nuttall window
> +@item mnuttall3
> +minimum 3-terms discontinuous nuttall window
> +@item nuttall
> +4-terms continuous 1st derivative nuttall window
> +@item bnuttall
> +minimum 4-terms discontinuous nuttall (blackman-nuttall) window
> +@item bharris
> +blackman-harris window
> +@end table
> +
> +@item fixed
> +If enabled, use fixed number of audio samples. This improves speed when
> +filtering with large delay. Default is disabled.
> +
> +@item multi
> +Enable multichannels evaluation on gain. Default is disabled.
> +@end table
> +
> +@subsection Examples
> +@itemize
> +@item
> +lowpass at 1000 Hz:
> +@example
> +firequalizer=gain='if(lt(f,1000), 0, -INF)'
> +@end example
> +@item
> +lowpass at 1000 Hz with gain_entry:
> +@example
> +firequalizer=gain_entry='entry(1000,0); entry(1001, -INF)'
> +@end example
> +@item
> +custom equalization:
> +@example
> +firequalizer=gain_entry='entry(100,0); entry(400, -4); entry(1000, -6); 
> entry(2000, 0)'
> +@end example
> +@item
> +higher delay:
> +@example
> +firequalizer=delay=0.1:fixed=on
> +@end example
> +@item
> +lowpass on left channel, highpass

Re: [FFmpeg-devel] MediaCodec support

2016-02-16 Thread Matthieu Bouron

On Tue, Feb 16, 2016 at 10:41 AM, wm4  wrote:

> On Mon, 15 Feb 2016 18:52:25 +0100
> Matthieu Bouron  wrote:
>
> > Hello,
> >
> > The following patchset adds basic MediaCodec support to libavcodec, ie:
> only
> > h264 is supported and the HWAccel part (Surface output) is missing.
> >
> > JNI comes as a dependency. The JNI support is based on the same patchset
> I've
> > sent some time ago with some improvements.
> >
> > I originally developed the patch against the Ndk API (Android >= 5.0)
> but then
> > changed my mind and go with the JNI version for two main reasons:
> >
> >   * there are still too many android 4 devices
> >   * there is still needs for some jni bits as the MediaCodec Ndk API
> >   does not provide a way to known the codec name which is mandatory
> >   to workaround or blacklist some implementations (ie: do not use known
> >   software decoders, workaround OMX.SEC.avc.dec as it returns invalid
> >   stride and slice-height values, ...)
> >
>
> I guess there's no way around it.
>
> > I decided to mimic the Ndk API minus a few differences (see
> > mediacodec_wrapper.h) so it can be ported more easily to the C API in the
> > future. The other reason being it is to totally hide the JNI code.
> >
> > The HWAccel part is on my todo list but I wanted a real use case to
> develop the
> > API against.
> >
> > The development branch can be found here:
> > https://github.com/mbouron/FFmpeg/tree/feature/mediacodec-support
> >
> > --enable-jni and --enable-mediacodec is required to build the
> h264_mediacodec
> > decoder.
> >
> > av_jni_register_java_vm(vm) must called before lavc is used.
>
> Wasn't there some sort of trick that could avoid this?
>

The workaround for this is to call a *private* C++ API, and in particular
checking that the variable jni_invocation_ is initialized
and call the GetCreatedJavaVMS function from:
https://android.googlesource.com/platform/libnativehelper/+/master/JniInvocation.cpp


> > The patchset also includes supports for Android content uris which is not
> > mandatory for the mediacodec supports but helps dealing with them more
> > seamlessly.
>
> I'm still not convinced that this is necessary (custom I/O allows any
> application to provide its own I/O callbacks). This would also avoid
> the need for avpriv JNI API, since it'd be confined to libavcodec.
>

Content uris are the proper way to deal with medias on Android since
version 5.0. Having it in lavf as a protocol would prevent anyone who wants
to support it in its application to re-do a custom io wrapper around it.
IMHO, it's like the other protocols we already support (samba, ssh, gopher,
icecast, ...) and the code that adds its support is not intrusive (it just
returns a fd that is then used by the file protocol functions). The issue
here is its jni dependency right ?


>
> > In order to use this support, av_jni_register_application_context(env,
> context)
> > must be called before lavf/lavu is used.
>
> For "content URIs"?
>

Yes for content uris usage.


>
> ___
> 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 v2] avfilter/avf_showcqt: improve pts handling

2016-02-16 Thread Muhammad Faiz

correct output pts based on input pts
make seeking possible
output frame one by one on eof
tested with showinfo filter

patch attached

thank's
From bc59d4a7636e2f199b3dbda06e8e3bc53e260cae Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Tue, 16 Feb 2016 07:03:37 +0700
Subject: [PATCH v2] avfilter/avf_showcqt: improve pts handling

correct output pts based on input pts
make seeking possible
output frame one by one on eof
tested with showinfo filter

Suggested-by: Paul B Mahol 
---
 libavfilter/avf_showcqt.c | 47 +++
 libavfilter/avf_showcqt.h |  2 +-
 2 files changed, 36 insertions(+), 13 deletions(-)

diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
index 712a999..6bb2d18 100644
--- a/libavfilter/avf_showcqt.c
+++ b/libavfilter/avf_showcqt.c
@@ -48,6 +48,8 @@
 #define FONTCOLOR   "st(0, (midi(f)-59.5)/12);" \
 "st(1, if(between(ld(0),0,1), 0.5-0.5*cos(2*PI*ld(0)), 0));" \
 "r(1-ld(1)) + b(ld(1))"
+#define PTS_STEP 10
+#define PTS_TOLERANCE 1
 
 #define OFFSET(x) offsetof(ShowCQTContext, x)
 #define FLAGS (AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM)
@@ -989,11 +991,10 @@ static void process_cqt(ShowCQTContext *s)
 yuv_from_cqt(s->c_buf, s->cqt_result, s->sono_g, s->width);
 }
 
-static int plot_cqt(AVFilterContext *ctx)
+static int plot_cqt(AVFilterContext *ctx, AVFrame **frameout)
 {
 AVFilterLink *outlink = ctx->outputs[0];
 ShowCQTContext *s = ctx->priv;
-int ret = 0;
 
 memcpy(s->fft_result, s->fft_data, s->fft_len * sizeof(*s->fft_data));
 av_fft_permute(s->fft_ctx, s->fft_result);
@@ -1004,7 +1005,7 @@ static int plot_cqt(AVFilterContext *ctx)
 if (s->sono_h)
 s->update_sono(s->sono_frame, s->c_buf, s->sono_idx);
 if (!s->sono_count) {
-AVFrame *out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
+AVFrame *out = *frameout = ff_get_video_buffer(outlink, outlink->w, outlink->h);
 if (!out)
 return AVERROR(ENOMEM);
 if (s->bar_h)
@@ -1013,14 +1014,13 @@ static int plot_cqt(AVFilterContext *ctx)
 s->draw_axis(out, s->axis_frame, s->c_buf, s->bar_h);
 if (s->sono_h)
 s->draw_sono(out, s->sono_frame, s->bar_h + s->axis_h, s->sono_idx);
-out->pts = s->frame_count;
-ret = ff_filter_frame(outlink, out);
-s->frame_count++;
+out->pts = s->next_pts;
+s->next_pts += PTS_STEP;
 }
 s->sono_count = (s->sono_count + 1) % s->count;
 if (s->sono_h)
 s->sono_idx = (s->sono_idx + s->sono_h - 1) % s->sono_h;
-return ret;
+return 0;
 }
 
 /* main filter control */
@@ -1133,7 +1133,7 @@ static int config_output(AVFilterLink *outlink)
 s->format = outlink->format;
 outlink->sample_aspect_ratio = av_make_q(1, 1);
 outlink->frame_rate = s->rate;
-outlink->time_base = av_inv_q(s->rate);
+outlink->time_base = av_mul_q(av_inv_q(s->rate), av_make_q(1, PTS_STEP));
 av_log(ctx, AV_LOG_INFO, "video: %dx%d %s %d/%d fps, bar_h = %d, axis_h = %d, sono_h = %d.\n",
s->width, s->height, av_get_pix_fmt_name(s->format), s->rate.num, s->rate.den,
s->bar_h, s->axis_h, s->sono_h);
@@ -1209,7 +1209,7 @@ static int config_output(AVFilterLink *outlink)
 return AVERROR(ENOMEM);
 
 s->sono_count = 0;
-s->frame_count = 0;
+s->next_pts = 0;
 s->sono_idx = 0;
 s->remaining_fill = s->fft_len / 2;
 s->remaining_frac = 0;
@@ -1232,14 +1232,16 @@ static int config_output(AVFilterLink *outlink)
 static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
 {
 AVFilterContext *ctx = inlink->dst;
+AVFilterLink *outlink = ctx->outputs[0];
 ShowCQTContext *s = ctx->priv;
 int remaining, step, ret, x, i, j, m;
 float *audio_data;
+AVFrame *out = NULL;
 
 if (!insamples) {
 while (s->remaining_fill < s->fft_len / 2) {
 memset(>fft_data[s->fft_len - s->remaining_fill], 0, sizeof(*s->fft_data) * s->remaining_fill);
-ret = plot_cqt(ctx);
+ret = plot_cqt(ctx, );
 if (ret < 0)
 return ret;
 
@@ -1248,6 +1250,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
 for (x = 0; x < (s->fft_len-step); x++)
 s->fft_data[x] = s->fft_data[x+step];
 s->remaining_fill += step;
+
+if (out)
+return ff_filter_frame(outlink, out);
 }
 return AVERROR_EOF;
 }
@@ -1263,12 +1268,30 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
 s->fft_data[j+m].re = audio_data[2*(i+m)];
 s->fft_data[j+m].im = audio_data[2*(i+m)+1];
 }
-ret = plot_cqt(ctx);
+ret = plot_cqt(ctx, );
 if (ret < 0) {
 av_frame_free();
 return ret;
 }
 remaining -=

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: improve pts handling

2016-02-16 Thread Paul B Mahol

On 2/16/16, Muhammad Faiz  wrote:
> On Mon, Feb 15, 2016 at 4:49 PM, Muhammad Faiz  wrote:
>> On Sat, Feb 13, 2016 at 12:20 AM, Paul B Mahol  wrote:
>>>-ret = plot_cqt(ctx);
>>>+ret = plot_cqt(ctx, AV_NOPTS_VALUE);
>> it should not be set to AV_NOPTS_VALUE, but to previous pts + something
>>
>>>-ret = plot_cqt(ctx);
>>>+ret = plot_cqt(ctx, insamples->pts + i);
>> av_rescale_q(insamples->pts, inlink->time_base, av_make_q(1,
>> inlink->sample_rate)) + i - s->fft_len/2
>>
>> Thank's
>
> Are you going to fix it? If not, i will post a patch to fix it.

Not right now, feel free to do it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets

2016-02-16 Thread Mats Peterson


I have removed the 4-byte alignment line.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 6256d18629e70c24260e4cfb1993411ccebfac73 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Tue, 16 Feb 2016 11:44:50 +0100
Subject: [PATCH 2/2] lavc/rawdec: Retrieve nut palette from packets

---
 libavcodec/rawdec.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 10bca05..eb9fe48 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -365,7 +365,6 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 if (avctx->pix_fmt == AV_PIX_FMT_PAL8) {
 const uint8_t *pal = av_packet_get_side_data(avpkt, AV_PKT_DATA_PALETTE,
  NULL);
-
 if (pal) {
 av_buffer_unref(>palette);
 context->palette = av_buffer_alloc(AVPALETTE_SIZE);
@@ -375,6 +374,13 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 }
 memcpy(context->palette->data, pal, AVPALETTE_SIZE);
 frame->palette_has_changed = 1;
+} else if (context->is_nut_pal8) {
+int vid_size = avctx->width * avctx->height;
+if (avpkt->size - vid_size) {
+pal = avpkt->data + vid_size;
+memcpy(context->palette->data, pal, avpkt->size - vid_size);
+frame->palette_has_changed = 1;
+}
 }
 }
 
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH 1/2] lavc/rawdec: Remove temporary monowhite switching code for 1 bpp AVI without a palette

2016-02-16 Thread Mats Peterson



--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From e62d408f3f6a90806ac64d04f06a522411a41365 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Tue, 16 Feb 2016 11:43:30 +0100
Subject: [PATCH 1/2] lavc/rawdec: Remove temporary monowhite switching code for 1 bpp AVI without a palette

---
 libavcodec/rawdec.c   |   19 ---
 tests/ref/vsynth/vsynth1-bpp1 |4 ++--
 tests/ref/vsynth/vsynth2-bpp1 |4 ++--
 tests/ref/vsynth/vsynth3-bpp1 |4 ++--
 tests/ref/vsynth/vsynth_lena-bpp1 |4 ++--
 5 files changed, 8 insertions(+), 27 deletions(-)

diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 287be96..10bca05 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -128,10 +128,6 @@ static av_cold int raw_init_decoder(AVCodecContext *avctx)
 avctx->pix_fmt   == AV_PIX_FMT_YUYV422)
 context->is_yuv2 = 1;
 
-/* Temporary solution until PAL8 is implemented in nut */
-if (context->is_pal8 && avctx->bits_per_coded_sample == 1)
-avctx->pix_fmt = AV_PIX_FMT_NONE;
-
 return 0;
 }
 
@@ -206,21 +202,6 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 return AVERROR_INVALIDDATA;
 }
 
-/* Temporary solution until PAL8 is implemented in nut */
-if (avctx->pix_fmt == AV_PIX_FMT_NONE &&
-avctx->bits_per_coded_sample == 1 &&
-avctx->frame_number == 0 &&
-context->palette &&
-AV_RB64(context->palette->data) == 0x
-) {
-const uint8_t *pal = av_packet_get_side_data(avpkt, AV_PKT_DATA_PALETTE, NULL);
-if (!pal) {
-avctx->pix_fmt = AV_PIX_FMT_MONOWHITE;
-context->is_pal8 = 0;
-context->is_mono = 1;
-} else
-avctx->pix_fmt = AV_PIX_FMT_PAL8;
-}
 desc = av_pix_fmt_desc_get(avctx->pix_fmt);
 
 if ((avctx->bits_per_coded_sample == 8 || avctx->bits_per_coded_sample == 4
diff --git a/tests/ref/vsynth/vsynth1-bpp1 b/tests/ref/vsynth/vsynth1-bpp1
index 0bd1a77..0abadd6 100644
--- a/tests/ref/vsynth/vsynth1-bpp1
+++ b/tests/ref/vsynth/vsynth1-bpp1
@@ -1,4 +1,4 @@
 611de0803ff6bd0ef385dde59964a105 *tests/data/fate/vsynth1-bpp1.avi
 640452 tests/data/fate/vsynth1-bpp1.avi
-576b690e8a8921c54d777463b63a8307 *tests/data/fate/vsynth1-bpp1.out.rawvideo
-stddev:   97.41 PSNR:  8.36 MAXDIFF:  238 bytes:  7603200/  7603200
+cd1e1448d9895561347ceb66d0add34d *tests/data/fate/vsynth1-bpp1.out.rawvideo
+stddev:   84.48 PSNR:  9.60 MAXDIFF:  218 bytes:  7603200/  7603200
diff --git a/tests/ref/vsynth/vsynth2-bpp1 b/tests/ref/vsynth/vsynth2-bpp1
index d283d6c..38e745f 100644
--- a/tests/ref/vsynth/vsynth2-bpp1
+++ b/tests/ref/vsynth/vsynth2-bpp1
@@ -1,4 +1,4 @@
 b51ad49892eb8f8912c5a983718a17bb *tests/data/fate/vsynth2-bpp1.avi
 640452 tests/data/fate/vsynth2-bpp1.avi
-338fb9039a4564e471bf8179f0c48a95 *tests/data/fate/vsynth2-bpp1.out.rawvideo
-stddev:   80.40 PSNR: 10.02 MAXDIFF:  238 bytes:  7603200/  7603200
+f0dfc0e87e5d96bce29a5944b1bd7471 *tests/data/fate/vsynth2-bpp1.out.rawvideo
+stddev:   68.98 PSNR: 11.36 MAXDIFF:  218 bytes:  7603200/  7603200
diff --git a/tests/ref/vsynth/vsynth3-bpp1 b/tests/ref/vsynth/vsynth3-bpp1
index 5a65728..b4267cf 100644
--- a/tests/ref/vsynth/vsynth3-bpp1
+++ b/tests/ref/vsynth/vsynth3-bpp1
@@ -1,4 +1,4 @@
 98852649c5201df7d85d0e9b5a5b9f15 *tests/data/fate/vsynth3-bpp1.avi
 15352 tests/data/fate/vsynth3-bpp1.avi
-0b1ea21b69d384564dd3a978065443b2 *tests/data/fate/vsynth3-bpp1.out.rawvideo
-stddev:   97.64 PSNR:  8.34 MAXDIFF:  248 bytes:86700/86700
+52ae74ef7910e5b603c12288d425b9ae *tests/data/fate/vsynth3-bpp1.out.rawvideo
+stddev:   84.76 PSNR:  9.57 MAXDIFF:  232 bytes:86700/86700
diff --git a/tests/ref/vsynth/vsynth_lena-bpp1 b/tests/ref/vsynth/vsynth_lena-bpp1
index 63ab9e1..2577733 100644
--- a/tests/ref/vsynth/vsynth_lena-bpp1
+++ b/tests/ref/vsynth/vsynth_lena-bpp1
@@ -1,4 +1,4 @@
 2859022fac452b59e49a1189c4fbb3ec *tests/data/fate/vsynth_lena-bpp1.avi
 640452 tests/data/fate/vsynth_lena-bpp1.avi
-3be3497f8ca548c9196dcecc5bc7cb2b *tests/data/fate/vsynth_lena-bpp1.out.rawvideo
-stddev:   96.52 PSNR:  8.44 MAXDIFF:  231 bytes:  7603200/  7603200
+6183ba861d4e48d4aaefc514fde270e5 *tests/data/fate/vsynth_lena-bpp1.out.rawvideo
+stddev:   83.28 PSNR:  9.72 MAXDIFF:  215 bytes:  7603200/  7603200
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: improve pts handling

2016-02-16 Thread Muhammad Faiz

On Mon, Feb 15, 2016 at 4:49 PM, Muhammad Faiz  wrote:
> On Sat, Feb 13, 2016 at 12:20 AM, Paul B Mahol  wrote:
>>-ret = plot_cqt(ctx);
>>+ret = plot_cqt(ctx, AV_NOPTS_VALUE);
> it should not be set to AV_NOPTS_VALUE, but to previous pts + something
>
>>-ret = plot_cqt(ctx);
>>+ret = plot_cqt(ctx, insamples->pts + i);
> av_rescale_q(insamples->pts, inlink->time_base, av_make_q(1,
> inlink->sample_rate)) + i - s->fft_len/2
>
> Thank's

Are you going to fix it? If not, i will post a patch to fix it.

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

[FFmpeg-devel] [PATCH] avfilter: add firequalizer filter

2016-02-16 Thread Muhammad Faiz

patch attached

thank's
From 5ec5d798e974f690d881787b7272ed23b7d4bdbc Mon Sep 17 00:00:00 2001
From: Muhammad Faiz 
Date: Tue, 16 Feb 2016 17:03:08 +0700
Subject: [PATCH] avfilter: add firequalizer filter

---
 Changelog |   1 +
 MAINTAINERS   |   1 +
 configure |   2 +
 doc/filters.texi  | 109 
 libavfilter/Makefile  |   1 +
 libavfilter/af_firequalizer.c | 592 ++
 libavfilter/allfilters.c  |   1 +
 libavfilter/version.h |   2 +-
 8 files changed, 708 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/af_firequalizer.c

diff --git a/Changelog b/Changelog
index 96a9955..1794164 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest within each release,
 releases are sorted from youngest to oldest.
 
 version :
+- firequalizer filter
 
 
 version 3.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index e57150d..9f7baf0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -353,6 +353,7 @@ Filters:
   af_biquads.c  Paul B Mahol
   af_chorus.c   Paul B Mahol
   af_compand.c  Paul B Mahol
+  af_firequalizer.c Muhammad Faiz
   af_ladspa.c   Paul B Mahol
   af_pan.c  Nicolas George
   af_sidechaincompress.cPaul B Mahol
diff --git a/configure b/configure
index 2148f11..b775cb9 100755
--- a/configure
+++ b/configure
@@ -2857,6 +2857,8 @@ eq_filter_deps="gpl"
 fftfilt_filter_deps="avcodec"
 fftfilt_filter_select="rdft"
 find_rect_filter_deps="avcodec avformat gpl"
+firequalizer_filter_deps="avcodec"
+firequalizer_filter_select="rdft"
 flite_filter_deps="libflite"
 frei0r_filter_deps="frei0r dlopen"
 frei0r_src_filter_deps="frei0r dlopen"
diff --git a/doc/filters.texi b/doc/filters.texi
index 68f54f1..67506dc 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2366,6 +2366,115 @@ Sets the difference coefficient (default: 2.5). 0.0 means mono sound
 Enable clipping. By default is enabled.
 @end table
 
+@section firequalizer
+Apply FIR Equalization using arbitrary frequency response.
+
+The filter accepts the following option:
+
+@table @option
+@item gain
+Set gain curve equation (in dB). The expression can contain variables:
+@table @option
+@item f
+the evaluated frequency
+@item sr
+sample rate
+@item ch
+channel number, set to 0 when multichannels evaluation is disabled
+@item chid
+channel id, see libavutil/channel_layout.h, set to the first channel id when
+multichannels evaluation is disabled
+@item chs
+number of channels
+@item chlayout
+channel_layout, see libavutil/channel_layout.h
+
+@end table
+and functions:
+@table @option
+@item gain_interpolate(f)
+interpote gain on frequency f based on gain_entry
+@end table
+This option is also available as command. Default is @code{gain_interpolate(f)}.
+
+@item gain_entry
+Set gain entry for gain_interpolate function. The expression can
+contain functions:
+@table @option
+@item entry(f, g)
+store gain entry at frequency f with value g
+@end table
+This option is also available as command.
+
+@item delay
+Set filter delay in seconds. Higher value means more accurate.
+Default is @code{0.01}.
+
+@item accuracy
+Set filter accuracy in Hz. Lower value means more accurate.
+Default is @code{5}.
+
+@item wfunc
+Set window function. Acceptable values are:
+@table @option
+@item rectangular
+rectangular window, useful when gain curve is already smooth
+@item hann
+hann window (default)
+@item hamming
+hamming window
+@item blackman
+blackman window
+@item nuttall3
+3-terms continuous 1st derivative nuttall window
+@item mnuttall3
+minimum 3-terms discontinuous nuttall window
+@item nuttall
+4-terms continuous 1st derivative nuttall window
+@item bnuttall
+minimum 4-terms discontinuous nuttall (blackman-nuttall) window
+@item bharris
+blackman-harris window
+@end table
+
+@item fixed
+If enabled, use fixed number of audio samples. This improves speed when
+filtering with large delay. Default is disabled.
+
+@item multi
+Enable multichannels evaluation on gain. Default is disabled.
+@end table
+
+@subsection Examples
+@itemize
+@item
+lowpass at 1000 Hz:
+@example
+firequalizer=gain='if(lt(f,1000), 0, -INF)'
+@end example
+@item
+lowpass at 1000 Hz with gain_entry:
+@example
+firequalizer=gain_entry='entry(1000,0); entry(1001, -INF)'
+@end example
+@item
+custom equalization:
+@example
+firequalizer=gain_entry='entry(100,0); entry(400, -4); entry(1000, -6); entry(2000, 0)'
+@end example
+@item
+higher delay:
+@example
+firequalizer=delay=0.1:fixed=on
+@end example
+@item
+lowpass on left channel, highpass on right channel:
+@example
+firequalizer=gain='if(eq(chid,1), gain_interpolate(f), if(eq(chid,2), gain_interpolate(1e6+f), 0))'
+:gain_entry='entry(1000, 0); entry(1001,-INF);

Re: [FFmpeg-devel] MediaCodec support

2016-02-16 Thread wm4

On Mon, 15 Feb 2016 18:52:25 +0100
Matthieu Bouron  wrote:

> Hello,
> 
> The following patchset adds basic MediaCodec support to libavcodec, ie: only
> h264 is supported and the HWAccel part (Surface output) is missing.
> 
> JNI comes as a dependency. The JNI support is based on the same patchset I've
> sent some time ago with some improvements.
> 
> I originally developed the patch against the Ndk API (Android >= 5.0) but then
> changed my mind and go with the JNI version for two main reasons:
> 
>   * there are still too many android 4 devices
>   * there is still needs for some jni bits as the MediaCodec Ndk API
>   does not provide a way to known the codec name which is mandatory
>   to workaround or blacklist some implementations (ie: do not use known
>   software decoders, workaround OMX.SEC.avc.dec as it returns invalid
>   stride and slice-height values, ...)
> 

I guess there's no way around it.

> I decided to mimic the Ndk API minus a few differences (see
> mediacodec_wrapper.h) so it can be ported more easily to the C API in the
> future. The other reason being it is to totally hide the JNI code.
> 
> The HWAccel part is on my todo list but I wanted a real use case to develop 
> the
> API against.
> 
> The development branch can be found here:
> https://github.com/mbouron/FFmpeg/tree/feature/mediacodec-support
> 
> --enable-jni and --enable-mediacodec is required to build the h264_mediacodec
> decoder.
> 
> av_jni_register_java_vm(vm) must called before lavc is used.

Wasn't there some sort of trick that could avoid this?

> The patchset also includes supports for Android content uris which is not
> mandatory for the mediacodec supports but helps dealing with them more
> seamlessly.

I'm still not convinced that this is necessary (custom I/O allows any
application to provide its own I/O callbacks). This would also avoid
the need for avpriv JNI API, since it'd be confined to libavcodec.

> In order to use this support, av_jni_register_application_context(env, 
> context)
> must be called before lavf/lavu is used.

For "content URIs"?

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/icodec: ico probe with unknown data

2016-02-16 Thread Mark Harris

>> Header:  OK, 2 frames
>> Frame 0: Unknown (offset points beyond end of probe buffer)
>> Frame 1: Invalid
>> Previously this example had a score of 25, even though the score would
>> be 1 if the unknown frame was known to be valid or 0 if it was known
>> to be invalid.  For this example the score is now 1.
>
> If the header is ok and the offset points beyond the end
> of the probe buffer, the score was always 25 (before I
> extended the check). Why should this be changed?
> 25 is not very high after checking ~40 bit.

If you think that 25 is better when there is 1 unknown frame and 1
invalid frame, I don't see an issue with that.  However in that case,
when the unknown frame is known to be valid it should have a score
that is at least the same value.  It doesn't make sense for the score
with an unknown value to be higher than the highest score that could
possibly be produced if the unknown value was known.

For this patch I just wanted to keep the behavior exactly the same in
the common case where all of the data is in the buffer.

For the case of unknown data, the existing code can do strange things.
For example if the probe buffer ends in the middle of a size or offset
field then it can end up reading a partial value, which can cause it
to check bytes at the wrong offset or produce false positives or false
negatives.  There were also inconsistencies if there was a mixture of
unknown and invalid data.  It seemed only logical that with unknown
data the score should never be higher than what it would be if the
data was known to be valid, and never be lower than what it would be
if the data was known to be invalid.  So I preserved the existing
behavior for the cases of known data, and adjusted the behavior for
unknown data so that the scores would be within these constraints and
so that there was no reliance on the zero padding.

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

Re: [FFmpeg-devel] [PATCH]concatdec: measure duration when it is not available

2016-02-16 Thread Nicolas George

L'octidi 28 pluviôse, an CCXXIV, Bodecs Bela a écrit :
> Do you have any suggestion for me what to do now?
> Please give me a hint where to find this bug or should I open a trac ticket
> for it?

I already told you: find out exactly WHY the result is different. I suggest
you use this kind of test case:

ffprobe -show_packets -show_streams input.ts
cat input.ts | ffprobe -show_packets -show_streams -

When we know why, we can discuss how.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH v5] Added VideoToolbox H.264 encoder.

2016-02-16 Thread wm4

On Tue, 16 Feb 2016 09:58:30 +0800
Rick Kern  wrote:

> Enable with configure --enable-vtenc and encode using -codec:v vtenc_h264.
> 
> Signed-off-by: Rick Kern 
> ---
>  MAINTAINERS|1 +
>  configure  |3 +
>  libavcodec/Makefile|1 +
>  libavcodec/allcodecs.c |1 +
>  libavcodec/vtenc.c | 1269 
> 
>  5 files changed, 1275 insertions(+)
>  create mode 100644 libavcodec/vtenc.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0705a69..a6a5fcf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -289,6 +289,7 @@ Codecs:
>vp8   David Conrad, Jason Garrett-Glaser, 
> Ronald Bultje
>vp9   Ronald Bultje, Clément Bœsch
>vqavideo.cMike Melanson
> +  vtenc.c   Rick Kern
>wavpack.c Kostya Shishkov
>wmaprodec.c   Sascha Sommer
>wmavoice.cRonald S. Bultje
> diff --git a/configure b/configure
> index 2148f11..ab0958b 100755
> --- a/configure
> +++ b/configure
> @@ -287,6 +287,7 @@ External library support:
>--disable-sdldisable sdl [autodetect]
>--disable-securetransport disable Secure Transport, needed for TLS support
> on OSX if openssl and gnutls are not used 
> [autodetect]
> +  --enable-vtenc   enable VideoToolbox encoder [no]
>--enable-x11grab enable X11 grabbing (legacy) [no]
>--disable-xlib   disable xlib [autodetect]
>--disable-zlib   disable zlib [autodetect]
> @@ -1505,6 +1506,7 @@ EXTERNAL_LIBRARY_LIST="
>  schannel
>  sdl
>  securetransport
> +vtenc
>  x11grab
>  xlib
>  zlib
> @@ -5605,6 +5607,7 @@ enabled openssl   && { use_pkg_config openssl 
> openssl/ssl.h SSL_library_
> check_lib openssl/ssl.h SSL_library_init 
> -lssl -lcrypto -lws2_32 -lgdi32 ||
> die "ERROR: openssl not found"; }
>  enabled qtkit_indev  && { check_header_objcc QTKit/QTKit.h || disable 
> qtkit_indev; }
> +enabled vtenc && require VideoToolbox 
> VideoToolbox/VTCompressionSession.h VTCompressionSessionPrepareToEncodeFrames 
> -framework VideoToolbox
>  
>  # libdc1394 check
>  if enabled libdc1394; then
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index f6a4fbb..409fa62 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -119,6 +119,7 @@ OBJS-$(CONFIG_TEXTUREDSP)  += texturedsp.o
>  OBJS-$(CONFIG_TEXTUREDSPENC)   += texturedspenc.o
>  OBJS-$(CONFIG_TPELDSP) += tpeldsp.o
>  OBJS-$(CONFIG_VIDEODSP)+= videodsp.o
> +OBJS-$(CONFIG_VTENC)   += vtenc.o
>  OBJS-$(CONFIG_VP3DSP)  += vp3dsp.o
>  OBJS-$(CONFIG_VP56DSP) += vp56dsp.o
>  OBJS-$(CONFIG_VP8DSP)  += vp8dsp.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 2097db0..91a0284 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -610,6 +610,7 @@ void avcodec_register_all(void)
>  REGISTER_ENCODER(HEVC_QSV,  hevc_qsv);
>  REGISTER_ENCODER(LIBKVAZAAR,libkvazaar);
>  REGISTER_ENCODER(MPEG2_QSV, mpeg2_qsv);
> +REGISTER_ENCODER(VTENC_H264,vtenc_h264);
>  
>  /* parsers */
>  REGISTER_PARSER(AAC,aac);
> diff --git a/libavcodec/vtenc.c b/libavcodec/vtenc.c
> new file mode 100644
> index 000..6f35930
> --- /dev/null
> +++ b/libavcodec/vtenc.c
> @@ -0,0 +1,1269 @@
> +/*
> + * copyright (c) 2015 Rick Kern 
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "avcodec.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/avassert.h"
> +#include "libavutil/atomic.h"
> +#include "libavutil/avstring.h"
> +#include "libavcodec/avcodec.h"
> +#include "internal.h"
> +#include 
> +
> +
> +static const uint8_t start_code[] = { 0, 0, 0, 1 };
>

Re: [FFmpeg-devel] [PATCH v5] Added VideoToolbox H.264 encoder.

2016-02-16 Thread Carl Eugen Hoyos

wm4  googlemail.com> writes:

> On Tue, 16 Feb 2016 08:32:40 + (UTC)
> Carl Eugen Hoyos  ag.or.at> wrote:
> 
> > Rick Kern  gmail.com> writes:
> > 
> > > +enabled vtenc && 
> > > require VideoToolbox VideoToolbox/VTCompressionSession.h 

I cut away the relevant part here, sorry:
VTCompressionSessionPrepareToEncodeFrames

> > On which osx systems is this header not available?
> 
> The same where videotoolbox decoding is not available, maybe.

Above is supported since 10.9 which in turn is 
supported on hardware that was sold from 2009 on.
I believe it should be autodetected to avoid bitrot.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH v5] Added VideoToolbox H.264 encoder.

2016-02-16 Thread wm4

On Tue, 16 Feb 2016 08:32:40 + (UTC)
Carl Eugen Hoyos  wrote:

> Rick Kern  gmail.com> writes:
> 
> > +enabled vtenc && 
> > require VideoToolbox VideoToolbox/VTCompressionSession.h  
> 
> On which osx systems is this header not available?

The same where videotoolbox decoding is not available, maybe.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] cfhd: reallocate internal buffers on format change.

2016-02-16 Thread Carl Eugen Hoyos

Kieran Kunhya  kunhya.com> writes:

[...]

If this fixes a ticket on trac, please add a reference 
to the commit message.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/dvbtxt: add raw demuxer for dvb teletext probing

2016-02-16 Thread Carl Eugen Hoyos

Marton Balint  passwd.hu> writes:

> +/* The purpose of this is demuxer is to detect DVB teletext 
> streams in
> + * mpegts, so we reject invalid buffer sizes */
> +if ((p->buf_size + 45) % 184 != 0)
> +return 0;

I don't think this is ok (although I may miss 
something):
The file could end in the middle of a teletext 
patckage or the end of the probe buffer could 
be within a teletext package.

> +if (!ff_data_identifier_is_teletext(p->buf[0]))
> +return 0;
> +
> +for (buf = p->buf + 1; buf < end; buf += 46) {
> +if (!ff_data_unit_id_is_teletext(buf[0]) && buf[0] != 0xff)
> +return 0;
> +if (buf[1] != 0x2c) // data_unit_length
> +return 0;
> +}

I suspect this should count frames.

> +return AVPROBE_SCORE_MAX / 2;

Is this ok for one frame?

> +++ b/libavutil/internal.h

Please create a new teletext header in libavcodec.

Thank you!

Carl Eugen

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

Re: [FFmpeg-devel] Pull request for VideoToolbox Encoder

2016-02-16 Thread Carl Eugen Hoyos

Richard Kern  gmail.com> writes:

> VideoToolbox Encoder for OSX/iOS: 
> https://github.com/FFmpeg/FFmpeg/pull/177
> 
> I submitted a patch a while ago and had it reviewed, 
> but it was never pushed.

Please ping the thread with the review instead.
(Or resend your patch.)

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH v5] Added VideoToolbox H.264 encoder.

2016-02-16 Thread Carl Eugen Hoyos

Rick Kern  gmail.com> writes:

> +enabled vtenc && 
> require VideoToolbox VideoToolbox/VTCompressionSession.h

On which osx systems is this header not available?

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/icodec: ico probe with unknown data

2016-02-16 Thread Carl Eugen Hoyos

Mark Harris  gmail.com> writes:

> Header:  OK, 2 frames
> Frame 0: Unknown (offset points beyond end of probe buffer)
> Frame 1: Invalid
> Previously this example had a score of 25, even though the score would
> be 1 if the unknown frame was known to be valid or 0 if it was known
> to be invalid.  For this example the score is now 1.

If the header is ok and the offset points beyond the end 
of the probe buffer, the score was always 25 (before I 
extended the check). Why should this be changed?
25 is not very high after checking ~40 bit.

Carl Eugen

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

67 matches

Mail list logo