Re: [libav-devel] [PATCH] libavcodec/util: Fix timebase overflow check

2016-01-27 Thread Luca Barbato 
On 27/01/16 22:15, Derek Buitenhuis wrote:
> It could accidentally divide by zero if num was zero.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index e06ee66..a3cb341 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1050,7 +1050,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  if (!avctx->rc_initial_buffer_occupancy)
>  avctx->rc_initial_buffer_occupancy = avctx->rc_buffer_size * 3 / 
> 4;
>  
> -if (avctx->ticks_per_frame &&
> +if (avctx->ticks_per_frame && avctx->time_base.num &&
>  avctx->ticks_per_frame > INT_MAX / avctx->time_base.num) {
>  av_log(avctx, AV_LOG_ERROR,
> "ticks_per_frame %d too large for the timebase %d/%d.",
> 

What about something like

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e06ee66..abad71a 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1050,6 +1050,14 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (!avctx->rc_initial_buffer_occupancy)
 avctx->rc_initial_buffer_occupancy = avctx->rc_buffer_size
* 3 / 4;

+if (avctx->time_base.num <= 0 ||
+avctx->time_base.den <= 0) {
+av_log(avctx, AV_LOG_ERROR, "Impossible time base %d/%d.",
+   avctx->time_base.num,
+   avctx->time_base.den);
+goto free_and_end;
+}
+
 if (avctx->ticks_per_frame &&
 avctx->ticks_per_frame > INT_MAX / avctx->time_base.num) {
 av_log(avctx, AV_LOG_ERROR,
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] libavcodec/util: Fix timebase overflow check

2016-01-27 Thread Derek Buitenhuis 
On 1/27/2016 10:16 PM, Luca Barbato wrote:
> When it is zero? (isn't there a check before to sanitize the time_base ?)

I only see a check for audio.

- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 4/4] avcodec/v210: document the requirement for sample_factor

2016-01-27 Thread Vittorio Giovara 
On Wed, Jan 27, 2016 at 2:59 PM, James Darnley  wrote:
> On 21/01/16 14:00, Anton Khirnov wrote:
>>> Does it make sense for both 8bit and 10bit functions to be called on one
>>> context? IIUC, it only works this way for the checkasm tests. So perhaps
>>> it'd be better and more future-proof to initialize the context for a
>>> specific bitdepth, and just have two inits in the checkasm test.
>>
>> The way the encoder works it would let you switch from 10bit to 8bit
>> every frame.
>>
>> I'd simply make it future-proof by having two variables.
>
> Do you want me to make that change?

If you find time to apply the changes requested and it doesn't take
away too much time, it would be highly appreciated.
-- 
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] libavcodec/util: Fix timebase overflow check

2016-01-27 Thread Luca Barbato 
On 27/01/16 22:15, Derek Buitenhuis wrote:
> It could accidentally divide by zero if num was zero.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index e06ee66..a3cb341 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1050,7 +1050,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  if (!avctx->rc_initial_buffer_occupancy)
>  avctx->rc_initial_buffer_occupancy = avctx->rc_buffer_size * 3 / 
> 4;
>  
> -if (avctx->ticks_per_frame &&
> +if (avctx->ticks_per_frame && avctx->time_base.num &&
>  avctx->ticks_per_frame > INT_MAX / avctx->time_base.num) {
>  av_log(avctx, AV_LOG_ERROR,
> "ticks_per_frame %d too large for the timebase %d/%d.",
> 

When it is zero? (isn't there a check before to sanitize the time_base ?)

lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH 1/3] v210: Add avx2 version of the 8-bit line encoder

2016-01-27 Thread Luca Barbato 
From: James Darnley 

Around 35% faster than the avx version.

Signed-off-by: Henrik Gramner 
Signed-off-by: Luca Barbato 
---
 libavcodec/v210enc.c  |  5 ++--
 libavcodec/v210enc.h  |  1 +
 libavcodec/x86/v210enc.asm| 57 +++
 libavcodec/x86/v210enc_init.c |  7 ++
 4 files changed, 47 insertions(+), 23 deletions(-)

diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index ca6ad2e..ce690f1 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -86,6 +86,7 @@ av_cold void ff_v210enc_init(V210EncContext *s)
 {
 s->pack_line_8  = v210_planar_pack_8_c;
 s->pack_line_10 = v210_planar_pack_10_c;
+s->sample_factor = 1;
 
 if (ARCH_X86)
 ff_v210enc_init_x86(s);
@@ -172,13 +173,13 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 const uint8_t *v = pic->data[2];
 for (h = 0; h < avctx->height; h++) {
 uint32_t val;
-w = (avctx->width / 12) * 12;
+w = (avctx->width / (12 * s->sample_factor)) * 12 * 
s->sample_factor;
 s->pack_line_8(y, u, v, dst, w);
 
 y += w;
 u += w >> 1;
 v += w >> 1;
-dst += (w / 12) * 32;
+dst += (w / (12 * s->sample_factor)) * 32 * s->sample_factor;
 
 for (; w < avctx->width - 5; w += 6) {
 WRITE_PIXELS8(u, y, v);
diff --git a/libavcodec/v210enc.h b/libavcodec/v210enc.h
index 81a3531..74b0514 100644
--- a/libavcodec/v210enc.h
+++ b/libavcodec/v210enc.h
@@ -28,6 +28,7 @@ typedef struct V210EncContext {
 const uint8_t *v, uint8_t *dst, ptrdiff_t width);
 void (*pack_line_10)(const uint16_t *y, const uint16_t *u,
  const uint16_t *v, uint8_t *dst, ptrdiff_t width);
+int sample_factor;
 } V210EncContext;
 
 void ff_v210enc_init(V210EncContext *s);
diff --git a/libavcodec/x86/v210enc.asm b/libavcodec/x86/v210enc.asm
index bdefcdb..7ff1f49 100644
--- a/libavcodec/x86/v210enc.asm
+++ b/libavcodec/x86/v210enc.asm
@@ -21,27 +21,26 @@
 
 %include "libavutil/x86/x86util.asm"
 
-SECTION_RODATA
+SECTION_RODATA 32
 
-v210_enc_min_10: times 8 dw 0x4
-v210_enc_max_10: times 8 dw 0x3fb
+v210_enc_min_10: times 16 dw 0x4
+v210_enc_max_10: times 16 dw 0x3fb
 
-v210_enc_luma_mult_10: dw 4,1,16,4,1,16,0,0
-v210_enc_luma_shuf_10: db -1,0,1,-1,2,3,4,5,-1,6,7,-1,8,9,10,11
+v210_enc_luma_mult_10: times 2 dw 4,1,16,4,1,16,0,0
+v210_enc_luma_shuf_10: times 2 db -1,0,1,-1,2,3,4,5,-1,6,7,-1,8,9,10,11
 
-v210_enc_chroma_mult_10: dw 1,4,16,0,16,1,4,0
-v210_enc_chroma_shuf_10: db 0,1,8,9,-1,2,3,-1,10,11,4,5,-1,12,13,-1
+v210_enc_chroma_mult_10: times 2 dw 1,4,16,0,16,1,4,0
+v210_enc_chroma_shuf_10: times 2 db 0,1,8,9,-1,2,3,-1,10,11,4,5,-1,12,13,-1
 
-v210_enc_min_8: times 16 db 0x1
-v210_enc_max_8: times 16 db 0xfe
+v210_enc_min_8: times 32 db 0x1
+v210_enc_max_8: times 32 db 0xfe
 
-v210_enc_luma_shuf_8: db 6,-1,7,-1,8,-1,9,-1,10,-1,11,-1,-1,-1,-1,-1
-v210_enc_luma_mult_8: dw 16,4,64,16,4,64,0,0
+v210_enc_luma_mult_8: times 2 dw 16,4,64,16,4,64,0,0
+v210_enc_luma_shuf_8: times 2 db 6,-1,7,-1,8,-1,9,-1,10,-1,11,-1,-1,-1,-1,-1
 
-v210_enc_chroma_shuf1_8: db 0,-1,1,-1,2,-1,3,-1,8,-1,9,-1,10,-1,11,-1
-v210_enc_chroma_shuf2_8: db 3,-1,4,-1,5,-1,7,-1,11,-1,12,-1,13,-1,15,-1
-
-v210_enc_chroma_mult_8: dw 4,16,64,0,64,4,16,0
+v210_enc_chroma_mult_8: times 2 dw 4,16,64,0,64,4,16,0
+v210_enc_chroma_shuf1_8: times 2 db 0,-1,1,-1,2,-1,3,-1,8,-1,9,-1,10,-1,11,-1
+v210_enc_chroma_shuf2_8: times 2 db 3,-1,4,-1,5,-1,7,-1,11,-1,12,-1,13,-1,15,-1
 
 SECTION .text
 
@@ -102,7 +101,10 @@ cglobal v210_planar_pack_8, 5, 5, 7, y, u, v, dst, width
 pxorm6, m6
 
 .loop
-movum1, [yq+2*widthq]
+movuxm1, [yq+2*widthq]
+%if cpuflag(avx2)
+vinserti128 m1, m1, [yq+2*widthq+12], 1
+%endif
 CLIPUB  m1, m4, m5
 
 punpcklbw m0, m1, m6
@@ -115,8 +117,13 @@ cglobal v210_planar_pack_8, 5, 5, 7, y, u, v, dst, width
 pshufb  m0, [v210_enc_luma_shuf_10]
 pshufb  m1, [v210_enc_luma_shuf_10]
 
-movqm3, [uq+widthq]
-movhps  m3, [vq+widthq]
+movq xm3, [uq+widthq]
+movhps   xm3, [vq+widthq]
+%if cpuflag(avx2)
+movq xm2, [uq+widthq+6]
+movhps   xm2, [vq+widthq+6]
+vinserti128  m3,   m3, xm2, 1
+%endif
 CLIPUB  m3, m4, m5
 
 ; shuffle and multiply to get the same packing as in 10-bit
@@ -131,11 +138,15 @@ cglobal v210_planar_pack_8, 5, 5, 7, y, u, v, dst, width
 por m0, m2
 por m1, m3
 
-movu[dstq], m0
-movu[dstq+mmsize], m1
+movu [dstq],xm0
+movu [dstq+16], xm1
+%if cpuflag(avx2)
+vextracti128 [dstq+32], m0, 1
+vextracti128 [dstq+48], m1, 1
+%endif
 
 add dstq, 2*mmsize
-add widthq, 6
+add widthq, (mmsize*3)/8
 jl .loop
 
 RET
@@ -149,3 +160,7 @@ v210_planar_pack_8
 INIT_XMM

[libav-devel] [PATCH 2/3] v210: Add avx2 version of the 10-bit line encoder

2016-01-27 Thread Luca Barbato 
From: James Darnley 

Around 25% faster than the ssse3 version.

Signed-off-by: Luca Barbato 
---
 libavcodec/v210enc.c  | 11 +--
 libavcodec/x86/v210enc.asm| 26 +++---
 libavcodec/x86/v210enc_init.c |  4 
 3 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index ce690f1..da0b23f 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -135,13 +135,20 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 const uint16_t *v = (const uint16_t *)pic->data[2];
 for (h = 0; h < avctx->height; h++) {
 uint32_t val;
-w = (avctx->width / 6) * 6;
+w = (avctx->width / (6 * s->sample_factor)) * 6 * s->sample_factor;
 s->pack_line_10(y, u, v, dst, w);
 
 y += w;
 u += w >> 1;
 v += w >> 1;
-dst += (w / 6) * 16;
+dst += (w / (6 * s->sample_factor)) * 16 * s->sample_factor;
+
+for (; w < avctx->width - 5; w += 6) {
+WRITE_PIXELS(u, y, v);
+WRITE_PIXELS(y, u, y);
+WRITE_PIXELS(v, y, u);
+WRITE_PIXELS(y, v, y);
+}
 if (w < avctx->width - 1) {
 WRITE_PIXELS(u, y, v);
 
diff --git a/libavcodec/x86/v210enc.asm b/libavcodec/x86/v210enc.asm
index 7ff1f49..ec4309f 100644
--- a/libavcodec/x86/v210enc.asm
+++ b/libavcodec/x86/v210enc.asm
@@ -23,8 +23,8 @@
 
 SECTION_RODATA 32
 
-v210_enc_min_10: times 16 dw 0x4
-v210_enc_max_10: times 16 dw 0x3fb
+v210_enc_min_10: times 32 dw 0x4
+v210_enc_max_10: times 32 dw 0x3fb
 
 v210_enc_luma_mult_10: times 2 dw 4,1,16,4,1,16,0,0
 v210_enc_luma_shuf_10: times 2 db -1,0,1,-1,2,3,4,5,-1,6,7,-1,8,9,10,11
@@ -47,7 +47,7 @@ SECTION .text
 %macro v210_planar_pack_10 0
 
 ; v210_planar_pack_10(const uint16_t *y, const uint16_t *u, const uint16_t *v, 
uint8_t *dst, ptrdiff_t width)
-cglobal v210_planar_pack_10, 5, 5, 4, y, u, v, dst, width
+cglobal v210_planar_pack_10, 5, 5, 4+cpuflag(avx2), y, u, v, dst, width
 lea r0, [yq+2*widthq]
 add uq, widthq
 add vq, widthq
@@ -57,11 +57,19 @@ cglobal v210_planar_pack_10, 5, 5, 4, y, u, v, dst, width
 movam3, [v210_enc_max_10]
 
 .loop
-movum0, [yq+2*widthq]
+movuxm0, [yq+2*widthq]
+%if cpuflag(avx2)
+vinserti128 m0, m0, [yq+2*widthq+12], 1
+%endif
 CLIPW   m0, m2, m3
 
-movqm1, [uq+widthq]
-movhps  m1, [vq+widthq]
+movqxm1, [uq+widthq]
+movhps  xm1, [vq+widthq]
+%if cpuflag(avx2)
+movq xm4, [uq+widthq+6]
+movhps   xm4, [vq+widthq+6]
+vinserti128  m1, m1, xm4, 1
+%endif
 CLIPW   m1, m2, m3
 
 pmullw  m0, [v210_enc_luma_mult_10]
@@ -75,7 +83,7 @@ cglobal v210_planar_pack_10, 5, 5, 4, y, u, v, dst, width
 movu[dstq], m0
 
 add dstq, mmsize
-add widthq, 6
+add widthq, (mmsize*3)/8
 jl .loop
 
 RET
@@ -85,6 +93,10 @@ cglobal v210_planar_pack_10, 5, 5, 4, y, u, v, dst, width
 INIT_XMM ssse3
 v210_planar_pack_10
 %endif
+%if HAVE_AVX2_EXTERNAL
+INIT_YMM avx2
+v210_planar_pack_10
+%endif
 
 %macro v210_planar_pack_8 0
 
diff --git a/libavcodec/x86/v210enc_init.c b/libavcodec/x86/v210enc_init.c
index fd8508b..33f2e41 100644
--- a/libavcodec/x86/v210enc_init.c
+++ b/libavcodec/x86/v210enc_init.c
@@ -29,6 +29,9 @@ void ff_v210_planar_pack_8_avx2(const uint8_t *y, const 
uint8_t *u,
 void ff_v210_planar_pack_10_ssse3(const uint16_t *y, const uint16_t *u,
   const uint16_t *v, uint8_t *dst,
   ptrdiff_t width);
+void ff_v210_planar_pack_10_avx2(const uint16_t *y, const uint16_t *u,
+ const uint16_t *v, uint8_t *dst,
+ ptrdiff_t width);
 
 av_cold void ff_v210enc_init_x86(V210EncContext *s)
 {
@@ -45,5 +48,6 @@ av_cold void ff_v210enc_init_x86(V210EncContext *s)
 if (EXTERNAL_AVX2(cpu_flags)) {
 s->sample_factor = 2;
 s->pack_line_8   = ff_v210_planar_pack_8_avx2;
+s->pack_line_10  = ff_v210_planar_pack_10_avx2;
 }
 }
-- 
2.6.1

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH 3/3] v210: Use separate sample_factors

2016-01-27 Thread Luca Barbato 
And while at it simplify a little the code.
---
 libavcodec/v210enc.c  | 17 -
 libavcodec/v210enc.h  |  3 ++-
 libavcodec/x86/v210enc_init.c |  7 ---
 3 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index da0b23f..2ee5a1b 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -86,7 +86,8 @@ av_cold void ff_v210enc_init(V210EncContext *s)
 {
 s->pack_line_8  = v210_planar_pack_8_c;
 s->pack_line_10 = v210_planar_pack_10_c;
-s->sample_factor = 1;
+s->sample_factor_8  = 1;
+s->sample_factor_10 = 1;
 
 if (ARCH_X86)
 ff_v210enc_init_x86(s);
@@ -133,15 +134,18 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 const uint16_t *y = (const uint16_t *)pic->data[0];
 const uint16_t *u = (const uint16_t *)pic->data[1];
 const uint16_t *v = (const uint16_t *)pic->data[2];
+int sample_size   = 6 * s->sample_factor_10;
+int sample_w  = avctx->width / sample_size;
+
 for (h = 0; h < avctx->height; h++) {
 uint32_t val;
-w = (avctx->width / (6 * s->sample_factor)) * 6 * s->sample_factor;
+w = sample_w * sample_size;
 s->pack_line_10(y, u, v, dst, w);
 
 y += w;
 u += w >> 1;
 v += w >> 1;
-dst += (w / (6 * s->sample_factor)) * 16 * s->sample_factor;
+dst += sample_w * 16 * s->sample_factor_10;
 
 for (; w < avctx->width - 5; w += 6) {
 WRITE_PIXELS(u, y, v);
@@ -178,15 +182,18 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 const uint8_t *y = pic->data[0];
 const uint8_t *u = pic->data[1];
 const uint8_t *v = pic->data[2];
+int sample_size   = 12 * s->sample_factor_8;
+int sample_w  = avctx->width / sample_size;
+
 for (h = 0; h < avctx->height; h++) {
 uint32_t val;
-w = (avctx->width / (12 * s->sample_factor)) * 12 * 
s->sample_factor;
+w = sample_w * sample_size;
 s->pack_line_8(y, u, v, dst, w);
 
 y += w;
 u += w >> 1;
 v += w >> 1;
-dst += (w / (12 * s->sample_factor)) * 32 * s->sample_factor;
+dst += sample_w * 32 * s->sample_factor_8;
 
 for (; w < avctx->width - 5; w += 6) {
 WRITE_PIXELS8(u, y, v);
diff --git a/libavcodec/v210enc.h b/libavcodec/v210enc.h
index 74b0514..ee3637a 100644
--- a/libavcodec/v210enc.h
+++ b/libavcodec/v210enc.h
@@ -28,7 +28,8 @@ typedef struct V210EncContext {
 const uint8_t *v, uint8_t *dst, ptrdiff_t width);
 void (*pack_line_10)(const uint16_t *y, const uint16_t *u,
  const uint16_t *v, uint8_t *dst, ptrdiff_t width);
-int sample_factor;
+int sample_factor_8;
+int sample_factor_10;
 } V210EncContext;
 
 void ff_v210enc_init(V210EncContext *s);
diff --git a/libavcodec/x86/v210enc_init.c b/libavcodec/x86/v210enc_init.c
index 33f2e41..c4d2745 100644
--- a/libavcodec/x86/v210enc_init.c
+++ b/libavcodec/x86/v210enc_init.c
@@ -46,8 +46,9 @@ av_cold void ff_v210enc_init_x86(V210EncContext *s)
 s->pack_line_8 = ff_v210_planar_pack_8_avx;
 
 if (EXTERNAL_AVX2(cpu_flags)) {
-s->sample_factor = 2;
-s->pack_line_8   = ff_v210_planar_pack_8_avx2;
-s->pack_line_10  = ff_v210_planar_pack_10_avx2;
+s->sample_factor_8  = 2;
+s->pack_line_8  = ff_v210_planar_pack_8_avx2;
+s->sample_factor_10 = 2;
+s->pack_line_10 = ff_v210_planar_pack_10_avx2;
 }
 }
-- 
2.6.1

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 3/3] v210: Use separate sample_factors

2016-01-27 Thread Kieran Kunhya 
On Thu, Jan 28, 2016 at 12:02 AM, Luca Barbato  wrote:
> And while at it simplify a little the code.
> ---
>  libavcodec/v210enc.c  | 17 -
>  libavcodec/v210enc.h  |  3 ++-
>  libavcodec/x86/v210enc_init.c |  7 ---
>  3 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
> index da0b23f..2ee5a1b 100644
> --- a/libavcodec/v210enc.c
> +++ b/libavcodec/v210enc.c
> @@ -86,7 +86,8 @@ av_cold void ff_v210enc_init(V210EncContext *s)
>  {
>  s->pack_line_8  = v210_planar_pack_8_c;
>  s->pack_line_10 = v210_planar_pack_10_c;
> -s->sample_factor = 1;
> +s->sample_factor_8  = 1;
> +s->sample_factor_10 = 1;
>
>  if (ARCH_X86)
>  ff_v210enc_init_x86(s);
> @@ -133,15 +134,18 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
> *pkt,
>  const uint16_t *y = (const uint16_t *)pic->data[0];
>  const uint16_t *u = (const uint16_t *)pic->data[1];
>  const uint16_t *v = (const uint16_t *)pic->data[2];
> +int sample_size   = 6 * s->sample_factor_10;
> +int sample_w  = avctx->width / sample_size;
> +
>  for (h = 0; h < avctx->height; h++) {
>  uint32_t val;
> -w = (avctx->width / (6 * s->sample_factor)) * 6 * 
> s->sample_factor;
> +w = sample_w * sample_size;
>  s->pack_line_10(y, u, v, dst, w);
>
>  y += w;
>  u += w >> 1;
>  v += w >> 1;
> -dst += (w / (6 * s->sample_factor)) * 16 * s->sample_factor;
> +dst += sample_w * 16 * s->sample_factor_10;

Does this not break the rounding?

Kieran
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] lavf: remove the concat protocol

2016-01-27 Thread Anton Khirnov 
Quoting Andreas Cadhalpun (2016-01-27 01:18:23)
> On 26.01.2016 19:42, Anton Khirnov wrote:
> > Quoting Andreas Cadhalpun (2016-01-26 01:02:04)
> >> On 22.01.2016 13:37, Anton Khirnov wrote:
> >>> Just so it's clear what we're talking about, what is "properly" for you?
> >>
> >> That would be a more or less general mechanism, which would have prevented
> >> the information leak in the hls demuxer by default. It should also prevent
> >> any such possible problems in other demuxers.
> >> This could be done by implementing a protocol_whitelist with sensible
> >> defaults.
> > 
> > That was my first idea as well. Turns out, it's rather nontrivial to
> > implement, due to the fact that protocols allow nesting (e.g. http over
> > tcp).
> 
> Could you explain in more detail what problem that would cause?
> The whitelist should simply be passed from http to tcp in that case.

You have to go over all the (de)muxers that call the protocol layer
directly and all the protocols and ensure that those
restrictions are passed through correctly. That is a somewhat nontrivial
amount of work. Not to mention that we first have to design those
restrictions. That's also a not completely obvious step, especially if,
as you're suggesting below, they should somehow be format-dependent.

Frankly, I don't have that much free time on my hands to do all that
quickly. Or do you volunteer?

> 
> > It would also require the calling programs to have quite a lot of
> > knowledge about the libav protocol layer internals.
> 
> Most programs should be able to work with the default.
> 
> >>> And what do you see as "the underlying problem"?
> >>
> >> I think that is libavformat mixing local and remote data. If it wouldn't
> >> to do that by default, such information leaks shouldn't be possible.
> >>
> > 
> > Opening a local playlist that references remote streams is quite common,
> 
> Though it is a lot less common than simply opening a local file.
> 
> > so making this behaviour forbidden by default is likely to break many
> > applications.
> 
> I think that applications wanting this behavior should explicitly enable
> it. To ease the transition period, one could set the protocol_whitelist
> to something sensible for this case, e.g. 'file,http,https,tcp', when the
> filename has the extension of a playlist.

That implies the whitelist is format-dependent, which is already rather
nontrivial.

> 
> > So while I fully agree that the concat protocol is not the root problem,
> > it is the source of its most significat symptom and removing it will
> > prevent the worst leaks.
> 
> That could also be done by disabling it by default, i.e. unless an option
> to enable it is given. That way people using it could at least continue
> to do so after setting said option.
> 
> > Meanwhile, we will have time to introduce the
> > infrastructure to fix this properly (which I think I already started,
> > but finishing it is, as said above, nontrivial).
> > And I'd really rather not design new APIs at gunpoint from pressing
> > security bugs.
> 
> Then just add quick hacks preventing the worst problems.
> I'd rather not have functionality hastily removed due to security
> concerns, that could be easily worked around until a proper solution
> is found.

I don't really understand your position -- on one hand you don't want to
remove "useful" functionality, even though the concat protocol is IMO
borderline-useless. OTOH you are quite fine with breaking applications
by adding restrictive defaults.

-- 
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] lavf: remove the concat protocol

2016-01-27 Thread Peter B. 
On 01/27/2016 01:21 PM, Luca Barbato wrote:
> On 27/01/16 12:10, Peter B. wrote:
>> I'm a user of "concat" for creating lossy access-copies of segmented
>> lossless archival files.
>> This is done in one step, integrated in an automated mass-digitization
>> workflow.
> You can use hls as an editlist. It is much flexible incidentally.

Will read up on this "hls" feature.

Thanks for the tip :)

Regards,
Pb

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 4/4] avcodec/v210: document the requirement for sample_factor

2016-01-27 Thread James Darnley 
On 21/01/16 14:00, Anton Khirnov wrote:
>> Does it make sense for both 8bit and 10bit functions to be called on one
>> context? IIUC, it only works this way for the checkasm tests. So perhaps
>> it'd be better and more future-proof to initialize the context for a
>> specific bitdepth, and just have two inits in the checkasm test.
> 
> The way the encoder works it would let you switch from 10bit to 8bit
> every frame.
> 
> I'd simply make it future-proof by having two variables.

Do you want me to make that change?




signature.asc
Description: OpenPGP digital signature
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 4/4] avcodec/v210: document the requirement for sample_factor

2016-01-27 Thread Luca Barbato 
On 27/01/16 20:59, James Darnley wrote:
> Do you want me to make that change?

Can happen later and I can do myself if there is agreement on going this
way =)

lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] libavcodec/util: Fix timebase overflow check

2016-01-27 Thread Derek Buitenhuis 
It could accidentally divide by zero if num was zero.

Signed-off-by: Derek Buitenhuis 
---
 libavcodec/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e06ee66..a3cb341 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1050,7 +1050,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (!avctx->rc_initial_buffer_occupancy)
 avctx->rc_initial_buffer_occupancy = avctx->rc_buffer_size * 3 / 4;
 
-if (avctx->ticks_per_frame &&
+if (avctx->ticks_per_frame && avctx->time_base.num &&
 avctx->ticks_per_frame > INT_MAX / avctx->time_base.num) {
 av_log(avctx, AV_LOG_ERROR,
"ticks_per_frame %d too large for the timebase %d/%d.",
-- 
2.7.0

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] lavf: remove the concat protocol

2016-01-27 Thread Luca Barbato 
On 27/01/16 12:10, Peter B. wrote:
> 
> On 01/27/2016 09:05 AM, Anton Khirnov wrote:
>> I don't really understand your position -- on one hand you don't want to
>> remove "useful" functionality, even though the concat protocol is IMO
>> borderline-useless. OTOH you are quite fine with breaking applications
>> by adding restrictive defaults.
> 
> I'm a user of "concat" for creating lossy access-copies of segmented
> lossless archival files.
> This is done in one step, integrated in an automated mass-digitization
> workflow.

You can use hls as an editlist. It is much flexible incidentally.

lu

___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] lavf: remove the concat protocol

2016-01-27 Thread Peter B. 

On 01/27/2016 09:05 AM, Anton Khirnov wrote:
> I don't really understand your position -- on one hand you don't want to
> remove "useful" functionality, even though the concat protocol is IMO
> borderline-useless. OTOH you are quite fine with breaking applications
> by adding restrictive defaults.

I'm a user of "concat" for creating lossy access-copies of segmented
lossless archival files.
This is done in one step, integrated in an automated mass-digitization
workflow.

Following the discussion, I wanted to ask what the preferred alternative
is, to concatenate multiple files together - in one step - if "concat"
is removed?

The documentation currently only lists streamable formats (like MPEG),
and the usage of pipes [1].



Thanks,
Pb


== References:
[1] https://libav.org/faq.html#How-can-I-join-video-files_003f



___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel