[FFmpeg-devel] [PATCH 5/9] hevc: derive partial merge list

The merge list only needs to be derived up to the merge index. --- libavcodec/hevc_mvs.c | 35 ++- 1 file changed, 26 insertions(+), 9 deletions(-) diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c index 2b017dd..0302c88 100644 --- a/libavcodec/hevc_mvs.c

[FFmpeg-devel] [PATCH 6/9] hevc: derive partially amvp list

When the candidate has been found, no need to derive others. --- libavcodec/hevc_mvs.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c index 0302c88..952a431 100644 --- a/libavcodec/hevc_mvs.c +++ b/libavcodec/hevc_mvs.c @@ -737,6 +737,11 @@

[FFmpeg-devel] [PATCH 4/9] hevc: reduce cu depth allocation

--- libavcodec/hevc.c | 4 ++-- libavcodec/hevc_cabac.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c index 2b37f53..4d3513a 100644 --- a/libavcodec/hevc.c +++ b/libavcodec/hevc.c @@ -100,7 +100,7 @@ static int

[FFmpeg-devel] [PATCH 2/9] hevc: reduce allocation for skip_flag

Save only 2 CTB lines worth of data (i.e. at worst 16 lines). --- libavcodec/hevc.c | 4 ++-- libavcodec/hevc.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c index f8a495f..bed2f5f 100644 --- a/libavcodec/hevc.c +++

[FFmpeg-devel] [PATCH 7/9] hevc: use intreadwrite

When dealing with MVs, both components may be processed at a time. --- libavcodec/hevc.c | 3 +-- libavcodec/hevc_mvs.c | 23 +-- 2 files changed, 10 insertions(+), 16 deletions(-) diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c index 4d3513a..f2bbe91 100644 ---

Re: [FFmpeg-devel] [PATCH 5/9] hevc: derive partial merge list

Note: this is also used for skip blocks, so the speed improvement of this patch should be around 1 or 2%. (amvp probably much less) 2014-07-10 8:47 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: The merge list only needs to be derived up to the merge index. --- libavcodec

[FFmpeg-devel] [PATCH] libavutil: document side effects of macros

Hi, I had missed some potential consequences of these macros, so here's something to document these consequences. I'm still a bit unsatisfied, as I would think AV_(ZERO|COPY|SWAP)64 are not that much affected by unaligned addresses or, if they are aligned to 4, compared to 2 AV_*32 operations.

Re: [FFmpeg-devel] [PATCH 7/9] hevc: use intreadwrite

a patch where I align various things to 4 to allow using AV_ZERO32/AV_RN32A. -- Christophe From 86fcce0a680e799eff3df86eb28ee77a88736811 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Sat, 12 Jul 2014 16:51:09 +0200 Subject: [PATCH 2/4] hevc: use intreadwrite

Re: [FFmpeg-devel] [PATCH] libavutil: document side effects of macros

Hi, 2014-07-19 14:17 GMT+02:00 Michael Niedermayer michae...@gmx.at: did you intend to attach a patch ? Here you are. -- Christophe From 30f5f833280c0753a000ab05fd60b9d0a9685dcb Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Thu, 10 Jul 2014 20:49:06

Re: [FFmpeg-devel] new webpage design patches

Hi, 2014-07-15 10:10 GMT+02:00 Clément Bœsch u...@pkh.me: The new website can be previewed @ http://db0.galo.pe/ffmpeg-web/ Some comments: - The FFmpeg project is proud a brand new version - lacks a to launch/... ? - The whole section before news does not fit in my screen height and is even

[FFmpeg-devel] [PATCH 2] hevc: use different thread wait/report for tmvp

: Christophe Gisquet christophe.gisq...@gmail.com Date: Sun, 20 Jul 2014 09:52:50 +0200 Subject: [PATCH 2/2] hevc: use different thread wait/report for tmvp The tmvp only needs decoded MVs, not the whole filtered pixels. Therefore abuse field 1 to report parsing process, and use it when checking progress

Re: [FFmpeg-devel] [PATCH 2] hevc: use different thread wait/report for tmvp

Hi, 2014-07-20 13:35 GMT+02:00 Ronald S. Bultje rsbul...@gmail.com: Do you get a speedup? I tinkered with some related problem in vp9 once and I never got a significant speedup out of it... Whatever your definition of significant, I don't think the figure I have is. It's around 1% on a dual

[FFmpeg-devel] [PATCH 2/4] hevc: use new step progress API

Use new API without introducing changes to synchronization points, i.e. same behaviour. --- libavcodec/hevc.c| 19 ++- libavcodec/hevc_filter.c | 10 +- libavcodec/hevc_mvs.c| 4 ++-- libavcodec/hevc_refs.c | 2 +- 4 files changed, 18 insertions(+), 17

[FFmpeg-devel] [PATCH 4/4] hevc: use new step threading API for DBF-only cases

In that case, there's an offset of 4 between the CTB line and the raster line. --- libavcodec/hevc_filter.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/libavcodec/hevc_filter.c b/libavcodec/hevc_filter.c index abf8b24..8b5ae6b 100644 --- a/libavcodec/hevc_filter.c

[FFmpeg-devel] [PATCH] x86: hevc_mc: replace simple leas by adds

slower in ffmpeg or if there's something else occurring. -- Christophe From 36dbc9b67269579e23345ec225ffa270d472b94e Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Thu, 24 Jul 2014 17:23:47 +0200 Subject: [PATCH 10/10] x86: hevc_mc: replace simple leas by adds

[FFmpeg-devel] [PATCH] x86: hevc_mc: replace one lea by add

Hi, I missed that occurrence in the previous patch. -- Christophe From 673b18b88e80650bfc7f898f2ac000147d2d71eb Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Fri, 25 Jul 2014 19:07:27 +0200 Subject: [PATCH 11/13] x86: hevc_mc: replace one lea by add

Re: [FFmpeg-devel] [PATCH] x86: hevc_mc: load less data in epel filters

2014-07-27 10:20 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: This is already used for qpel/luma filters. And with patch. From 4c9ef00c805b5ea81d96955bdfbc57ab7b383934 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Fri, 25 Jul 2014 15:08:49

[FFmpeg-devel] [PATCH] hevc_mc: reduce stride for bidir temp buffers

The stride is sometimes way bigger than actually needed. ptrdiff_t is the actual type used. Aligning to 8 is needed as the lines must have aligned addresses for SIMD. -- Christophe From 126adf820bc54c2d00f794629595ad6310fbfc37 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq

[FFmpeg-devel] [PATCH] hevc_filter: run vertical and horizontal together

One may interleave even more vertical and horizontal passes, but this is less straightforward (more code changes than just moves). -- Christophe From b48828b956d3a183d358ef9ad8a12f354c87da7d Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Sat, 26 Jul 2014 21

Re: [FFmpeg-devel] [PATCH] hevc_mc: reduce stride for bidir temp buffers

Hi, 2014-07-27 19:18 GMT+02:00 Michael Niedermayer michae...@gmx.at: It is unconditionally set to 64, which is quite higher than the actual block size. is this faster? No, which surprises me, but so be it. On the other hand, if this stride is PB_MAX_SIZE throughout the code, then maybe its

[FFmpeg-devel] [PATCH 1/4] hevc: move MAX_PB_SIZE declaration

--- libavcodec/hevc.h| 1 - libavcodec/hevcdsp.h | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h index 8420f38..0369d8f 100644 --- a/libavcodec/hevc.h +++ b/libavcodec/hevc.h @@ -56,7 +56,6 @@ #define MAX_TRANSFORM_DEPTH 5

[FFmpeg-devel] [PATCH 3/4] hevcdsp: remove more instances of compile-time-fixed parameters

--- libavcodec/hevc.c | 8 +++ libavcodec/hevcdsp.h | 8 +++ libavcodec/hevcdsp_template.c | 56 +-- libavcodec/x86/hevc_mc.asm| 18 +++--- libavcodec/x86/hevcdsp.h | 6 ++--- libavcodec/x86/hevcdsp_init.c |

[FFmpeg-devel] [PATCH 4/4] x86: hevcdsp: use compilation-time-fixed constant

The stride for some buffers is known. --- libavcodec/x86/hevc_mc.asm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm index ea4447b..2c34927 100644 --- a/libavcodec/x86/hevc_mc.asm +++ b/libavcodec/x86/hevc_mc.asm @@

Re: [FFmpeg-devel] [PATCH 1/4] libavcodec: new API for frame threading by step

2014-07-23 21:20 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: Didn't refresh the patch with update documentation. Here it is. It didn't contain dummy functions in libavcodec/utils.c. The attached patch should fix failures to build with pthread disabled. -- Christophe From

Re: [FFmpeg-devel] [PATCH] x86: hevc_mc: fix register count usage

With patch. From 0b5d56a563df7efdfcf206013680510c62e2569c Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Mon, 28 Jul 2014 11:48:21 +0200 Subject: [PATCH 10/15] x86: hevc_mc: fix register count usage A macro was using a fixed register, causing too many GPRs

Re: [FFmpeg-devel] [PATCH 1/4] libavcodec: new API for frame threading by step

Hi, note: I'm using step throughout the patch because of the step function and what the causal part most often looks like. I have no idea for another less confusing wording. 2014-07-28 23:15 GMT+02:00 Michael Niedermayer michae...@gmx.at: maybe i misunderstand but the progress[1] y check looks

Re: [FFmpeg-devel] [PATCH 0/4] Exploit compile-time constant

Hi, 2014-08-02 14:48 GMT+02:00 Michael Niedermayer michae...@gmx.at: is this for apply/push or just RFC/WIP ? in-between. I had expected Mickael Raulet to comment if he was seeing something not compatible with this. I think the bipred code is a bit more mature since Ronald comments (iirc), so

Re: [FFmpeg-devel] [PATCH 0/4] Exploit compile-time constant

for the others, so I didn't bother resending them/starting another thread. -- Christophe From 8b13e4350c6662ca4bd2bcab443a1e62f7751b30 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Mon, 28 Jul 2014 08:55:26 +0200 Subject: [PATCH 1/5] x86: hevc_mc: assume 2nd

[FFmpeg-devel] [PATCH] x86: hevc_deblock: remove unnecessary masking

, and I can't really spend more time on it. -- Christophe From 57819727586c186bfea733a8f06eead22ac6a1f2 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Wed, 23 Jul 2014 23:21:20 +0200 Subject: [PATCH 08/13] x86: hevc_deblock: remove unnecessary masking

Re: [FFmpeg-devel] [PATCH 3/4] hevcdsp: remove more instances of compile-time-fixed parameters

2014-07-28 19:17 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: --- libavcodec/hevc.c | 8 +++ libavcodec/hevcdsp.h | 8 +++ libavcodec/hevcdsp_template.c | 56 +-- libavcodec/x86/hevc_mc.asm| 18

[FFmpeg-devel] [PATCH] hevc_deblock: change tc type

Hi, this patch is mostly cosmetical. I don't like seeing arrays passed to dsp functions being of a type whose length may not be fixed, though it's a small matter here. -- Christophe From 25a3d9fa51860b8df108f31a818e6f74ee1761da Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq

[FFmpeg-devel] [PATCH 2/5] x86: better share ff_pw_2

--- libavcodec/x86/constants.c | 2 -- libavcodec/x86/constants.h | 3 +-- libavcodec/x86/dwt_yasm.asm | 3 ++- libavcodec/x86/inline_asm.h | 2 +- 4 files changed, 4 insertions(+), 6 deletions(-) diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c index ee3f1a5..bfb0ff3

[FFmpeg-devel] [PATCH 1/5] x86: vpx/h264/hevc/mpeg2: share constants

--- libavcodec/x86/constants.c | 5 + libavcodec/x86/constants.h | 5 + libavcodec/x86/h264_intrapred_10bit.asm | 2 +- libavcodec/x86/hevc_deblock.asm | 2 +- libavcodec/x86/hpeldsp.asm | 3 ++- libavcodec/x86/vp8dsp.asm | 2 +-

[FFmpeg-devel] [PATCH 5/5] x86: sbrdsp/fft: reuse ps_neg constant

--- libavcodec/x86/constants.c | 2 ++ libavcodec/x86/constants.h | 2 ++ libavcodec/x86/fft.asm | 7 --- libavcodec/x86/sbrdsp.asm | 2 +- 4 files changed, 9 insertions(+), 4 deletions(-) diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c index bfb0ff3..5d2c237 100644

[FFmpeg-devel] [PATCH 4/5] x86: diracdsp: reuse constants

--- libavcodec/x86/diracdsp_yasm.asm | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/libavcodec/x86/diracdsp_yasm.asm b/libavcodec/x86/diracdsp_yasm.asm index 3e9765b..d3cf9f1 100644 --- a/libavcodec/x86/diracdsp_yasm.asm +++ b/libavcodec/x86/diracdsp_yasm.asm @@

[FFmpeg-devel] [PATCH 3/5] x86: dwt: better share constants

--- libavcodec/x86/constants.h | 1 + libavcodec/x86/dwt_yasm.asm | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/libavcodec/x86/constants.h b/libavcodec/x86/constants.h index c85a54e..f73a9f2 100644 --- a/libavcodec/x86/constants.h +++ b/libavcodec/x86/constants.h @@

[FFmpeg-devel] [PATCH] hevc: fix incorrect sao buffer size

This fixes ticket #3839. -- Christophe From 3745a3b611159f6a373785b67cbc92d4b36af44b Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Sun, 10 Aug 2014 11:43:12 +0200 Subject: [PATCH] hevc: fix incorrect sao buffer size It previously used the output, cropped

[FFmpeg-devel] [PATCH] hevc_ps: verify P/T/L information

:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Sat, 9 Aug 2014 20:11:20 +0200 Subject: [PATCH] hevc_ps: verify P/T/L information This makes the SPS parsing a little, but barely, safer. --- libavcodec/hevc_ps.c | 43 ++- 1 file changed

Re: [FFmpeg-devel] [PATCH] hevc: fix incorrect sao buffer size

Hi, 2014-08-10 11:59 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: This fixes ticket #3839. By the way, not completely sure, but that is probably exploitable (I am not a security expert): - indicate large cropping in the header; this will cause an overrun of probably (max_ctb_size

Re: [FFmpeg-devel] [PATCH] hevc_ps: verify P/T/L information

Hi, 2014-08-10 14:42 GMT+02:00 Ronald S. Bultje rsbul...@gmail.com: Are we using the checked bitstream reader? If we are, we're fine already... I think we are. On the other hand, it seems the top caller, ff_hevc_decode_nal_vps, is never checking if we have read past the bitstream end. Shouldn't

[FFmpeg-devel] [PATCH] hevc_mvs: set candidate availabilities

The patch fixes overreads (and crashes) introduced in 3ad04608. -- Christophe From adfac6472b015e162988e2e2208e95cc87248be2 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Sun, 10 Aug 2014 15:02:36 +0200 Subject: [PATCH] hevc_mvs: set candidate availabilities

[FFmpeg-devel] [PATCH] hevc: do generic validation of bitstream

Hi, the patch tries to validate these high-level syntax elements. Unfortunately, it causes fuzzing to be less efficient, eg with the sequence from ticket #3840 where no frame are decoded. -- Christophe From 6b60cf2968099fa4395e1e3120ab66d95d4c8709 Mon Sep 17 00:00:00 2001 From: Christophe

[FFmpeg-devel] [PATCH 2/4] proresenc_kostya: report buffer overflow

If the allocated size, despite best efforts, is too small, exit with the appropriate error. --- libavcodec/proresenc_kostya.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c index 24cb333..a70ae3c

[FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small

The buffer allocation may be incorrect (e.g. with an alpha plane), and currently causes the buffer to be set to NULL by init_put_bits, later on causing crashing. So, detect that situation, and if detected, reallocate the buffer and ask a sample if it happens. Fixes ticket #2760 ---

[FFmpeg-devel] [PATCH 4/4] proresenc_kostya: properly account for alpha

The packet buffer allocation considered as dct-coded, while it is actually run-coded and thus requires a larger buffer. --- libavcodec/proresenc_kostya.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/libavcodec/proresenc_kostya.c

[FFmpeg-devel] [PATCH 1/4] proresenc_kostya: remove unneeded parameters

--- libavcodec/proresenc_kostya.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c index 93bcde7..24cb333 100644 --- a/libavcodec/proresenc_kostya.c +++ b/libavcodec/proresenc_kostya.c @@ -471,7 +471,6 @@ static

Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small

Hi, 2014-08-12 2:34 GMT+02:00 Michael Niedermayer michae...@gmx.at: +if (pkt_size = buf - orig_buf) { this isnt sufficient, there could be 1 byte space left, then the reallocate wouldnt run and encode_slice() would run into the extra padding and fail Yeah, you're right. I

Re: [FFmpeg-devel] [PATCH 4/4] proresenc_kostya: properly account for alpha

Hi, 2014-08-12 1:56 GMT+02:00 Michael Niedermayer michae...@gmx.at: - (2 + 2 * ctx-num_planes + + (2 + 2 * FFMIN(3, ctx-num_planes) + slice_hdr_size is 2 + 2 * (ctx-num_planes - 1); is this difference intended ? I don't

Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small

2014-08-12 7:56 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: Yeah, you're right. I have no idea how big a slice can be, as that seems the extra size check here. How about FF_MIN_BUFFER_SIZE ? Then the growth would be FFMAX(FF_MIN_BUFFER_SIZE, buf - orig_buf) ? Here's a patch

Re: [FFmpeg-devel] [PATCH 4/4] proresenc_kostya: properly account for alpha

Hi, 2014-08-12 8:10 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: Yeah, I'll drop it. Done. Kostya suggested another rounding (the slice bitstreams are byte-aligned), integrated in this patch. -- Christophe From 4e72ed146848b1d7b1804080f43b5d45484e3d94 Mon Sep 17 00:00:00 2001

Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small

Hi, 2014-08-12 10:19 GMT+02:00 Michael Niedermayer michae...@gmx.at: the serious undersizing check already depends on the assumtation that FF_MIN_BUFFER_SIZE is larger than a slice, Yes, and here lies the issue: if we haven't been able to guess it correctly previously, how likely are we to

Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small

Hi, 2014-08-12 12:26 GMT+02:00 Michael Niedermayer michae...@gmx.at: On Tue, Aug 12, 2014 at 11:56:21AM +0200, Christophe Gisquet wrote: Hi, 2014-08-12 10:19 GMT+02:00 Michael Niedermayer michae...@gmx.at: the serious undersizing check already depends on the assumtation

Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small

Hi, 2014-08-12 12:38 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: I chose 2 times in the attached patch. I have no strong opinion on which solution is best, though reallocating was a specific request I got. Forgot a parameter to the call to avpriv_request_sample, will be added

[FFmpeg-devel] [PATCH] dpx: use aligned line starts

Hi, the attached patch improves the decoding of ticket #3692 by following S268M-2003. Unfortunately, that probably means ffmpeg's dpx encoder is not compliant to these specifications. -- Christophe From 4ba2ec15c9a111fb4e20523d5a8fa337bedee92d Mon Sep 17 00:00:00 2001 From: Christophe Gisquet

Re: [FFmpeg-devel] [PATCH] dpx: use aligned line starts

2014-08-13 9:48 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: Unfortunately, that probably means ffmpeg's dpx encoder is not compliant to these specifications. And indeed the decoder is then no longer able to decode a file produced by the encoder when number of bytes per line

[FFmpeg-devel] [PATCH 1/4] dpx: use aligned line starts

SMPTE 268M-2003 specifies that each line starts at a 4-bytes boundary. Therefore, modify correspondingly the input buffer strides and size. Partially fixes ticket #3692: DLAD_8b_3c_big.dpx still has inverted colors, which might be related to endianness. --- libavcodec/dpx.c | 34

[FFmpeg-devel] [PATCH 2/4] dpxenc: enforce alignment requirement

S268M-2003 specifies that each line start is aligned on a 4-byte boundary. --- libavcodec/dpxenc.c | 44 +--- 1 file changed, 37 insertions(+), 7 deletions(-) diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c index 0eb1297..059d8c6 100644 ---

[FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits

Fixes DLAD_8b_3c_big.dpx from ticket #3692 --- libavcodec/dpx.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c index 2ad7527..d4d6833 100644 --- a/libavcodec/dpx.c +++ b/libavcodec/dpx.c @@ -232,6 +232,8 @@ static int decode_frame(AVCodecContext *avctx,

[FFmpeg-devel] [PATCH 3/4] dpx: abort if encrypted

--- libavcodec/dpx.c | 9 + 1 file changed, 9 insertions(+) diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c index 8cd7d73..2ad7527 100644 --- a/libavcodec/dpx.c +++ b/libavcodec/dpx.c @@ -108,6 +108,15 @@ static int decode_frame(AVCodecContext *avctx, av_log(avctx,

Re: [FFmpeg-devel] [PATCH 3/4] dpx: abort if encrypted

: Christophe Gisquet christophe.gisq...@gmail.com Date: Wed, 13 Aug 2014 01:44:40 +0200 Subject: [PATCH 3/4] dpx: warn if encrypted --- libavcodec/dpx.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c index 8cd7d73..6c4951b 100644 --- a/libavcodec/dpx.c

Re: [FFmpeg-devel] [PATCH 2/4] dpxenc: enforce alignment requirement

Hi, 2014-08-14 4:30 GMT+02:00 Michael Niedermayer michae...@gmx.at: probably ok applied Now that I think of it, this change causes older versions of ffmpeg to be unable to decode the output of the fixed encoder. So: - Should we bump eg a minor version number to let any decoder have the

Re: [FFmpeg-devel] [PATCH 1/4] dpx: use aligned line starts

Hi, 2014-08-14 4:17 GMT+02:00 Michael Niedermayer michae...@gmx.at: see http://samples.ffmpeg.org/image-samples/dpx_samples.zip Note that the date metadata in that file does not have a valid format either. -- Christophe ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits

Hi, 2014-08-14 5:01 GMT+02:00 Michael Niedermayer michae...@gmx.at: On Wed, Aug 13, 2014 at 10:21:54AM +, Christophe Gisquet wrote: case 50081: +avctx-pix_fmt = AV_PIX_FMT_BGR24; +break; this possibly breaks decoding

Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small

Hi, 2014-08-12 12:44 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: Forgot a parameter to the call to avpriv_request_sample, will be added later. If there's no further comment on this option for the reallocation, here's an updated patch. -- Christophe From

Re: [FFmpeg-devel] [PATCH 1/2] lavc/flacdsp: document limitations of the LPC encoder

Hi, 2014-08-14 17:14 GMT+02:00 James Darnley james.darn...@gmail.com: + * This limit is used: + * - when CONFIG_SMALL is 0 to unroll a loop in the C template. + * - when SSE4 (or newer) is available on x86 to unroll a copy loop. Does the implementer of a new dsp version really has

Re: [FFmpeg-devel] [PATCH 2/2] lavc/flacdsp: change lpc_encoder function pointer prototype

Hi, 2014-08-14 17:14 GMT+02:00 James Darnley james.darn...@gmail.com: This should help to clarify the API. OK. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: test flac LPC encoder

Hi, 2014-08-14 17:15 GMT+02:00 James Darnley james.darn...@gmail.com: The LPC encoder is not used at compression levels below 3 but the basic acodec test uses -compression_level 2. This adds a test using -compression_level 5, which is the current default. What order is used in that case? It

Re: [FFmpeg-devel] [PATCH] fate: test flac LPC encoder

Hi, 2014-08-14 18:08 GMT+02:00 James Darnley james.darn...@gmail.com: Minimum 1, maximum 8. Should I find out what order(s) are actually chosen? The encoder algorithm might change and make that information useless, but that could be useful. I fear that only checking which orders it *tests* is

Re: [FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits

Hi, 2014-08-14 11:48 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: Hi, 2014-08-14 5:01 GMT+02:00 Michael Niedermayer michae...@gmx.at: On Wed, Aug 13, 2014 at 10:21:54AM +, Christophe Gisquet wrote: case 50081: +avctx-pix_fmt = AV_PIX_FMT_BGR24; +break

[FFmpeg-devel] [PATCH] gifdec: use truncated width for image manipulation

59ea1d72b27272d2a28c680fc87b353f1a88eb36 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Sun, 17 Aug 2014 09:47:46 +0200 Subject: [PATCH] gifdec: use truncated width for image manipulation Some files seem to have an off-by-one error. In most cases, it appears to be on the image

Re: [FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits

Le 13 août 2014 12:22, Christophe Gisquet christophe.gisq...@gmail.com a écrit : Fixes DLAD_8b_3c_big.dpx from ticket #3692 --- libavcodec/dpx.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c index 2ad7527..d4d6833 100644 --- a/libavcodec/dpx.c

[FFmpeg-devel] [PATCH 1/2] alacenc: increase predictor buffer

This change is almost cosmetical only, and reduces the changes needed to fix the 24bps case. --- libavcodec/alacenc.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/libavcodec/alacenc.c b/libavcodec/alacenc.c index bc68a06..6345253 100644 ---

[FFmpeg-devel] [PATCH 2/2] alacenc: fix extra bits extraction

The raw coded bits are extracted prior to decorrelation, as is correctly performed by the decoder, and not after. --- libavcodec/alacenc.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/libavcodec/alacenc.c b/libavcodec/alacenc.c index 6345253..b9ad899

[FFmpeg-devel] [PATCH 0/2] Fix ALAC encoder for 24bps

the raw MSBs. It would possible to detect bitstreams before this change and achieve correct decoding if need be. Christophe Gisquet (2): alacenc: increase predictor buffer alacenc: fix extra bits extraction libavcodec/alacenc.c | 35 --- 1 file changed, 24

Re: [FFmpeg-devel] [PATCH 0/2] Fix ALAC encoder for 24bps

2014-08-17 19:09 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: It would possible to detect bitstreams before this change and achieve correct decoding if need be. fate tests still pass with the changes, which means the test sample doesn't contain the corner case involved

Re: [FFmpeg-devel] [PATCH] gifdec: use truncated width for image manipulation

Hi, 2014-08-17 20:39 GMT+02:00 Michael Niedermayer michae...@gmx.at: +if (width s-screen_width) { +av_log(s-avctx, AV_LOG_ERROR, Invalid image width.\n); +return AVERROR_INVALIDDATA; +} +if (left + width s-screen_width) { +/* width must be kept around

Re: [FFmpeg-devel] [PATCH 2/2] alacenc: fix extra bits extraction

Hi, 2014-08-17 19:09 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: The raw coded bits are extracted prior to decorrelation, as is correctly performed by the decoder, and not after. Forgot to mention it fixes ticket #2768 (haven't checked 2497 yet), so commit message amended

Re: [FFmpeg-devel] [PATCH] gifdec: use truncated width for image manipulation

for missing the obvious, indeed in those cases pw/height would end negative... So I have added the checks you propose and decided to shuffle them with the others. Updated patch attached. -- Christophe From a8a329b19d72405b6cc7de173e3f160be02e212d Mon Sep 17 00:00:00 2001 From: Christophe

Re: [FFmpeg-devel] [PATCH 0/2] Fix ALAC encoder for 24bps

Hi, 2014-08-17 19:09 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: It would possible to detect bitstreams before this change and achieve correct decoding if need be. So after further exploration, you can't really detect this: - there's no metadata for the alac bitstream

[FFmpeg-devel] [RFC] [PATCH] proresenc_kostya: warn/reject on incorrect profile

. -- Christophe From d9679c80df991e98b1f00fd15f9c1c3c689ec426 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Mon, 18 Aug 2014 11:27:50 +0200 Subject: [PATCH] proresenc_kostya: warn/reject on incorrect profile This fixes the following situations: - Reject

Re: [FFmpeg-devel] [RFC] [PATCH] huffyuvenc, multithread and context=1

Hi, 2014-06-19 6:23 GMT+02:00 Michael Niedermayer michae...@gmx.at: patch applied Am I missing something or was it not applied? -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] alac: add option to decoded incorrect ALAC

Hi, this is a proposal to allow decoding incorrect files. There is no obvious and systematic way to detect them however. -- Christophe From feaacb09d8660b7e8784ad4a550dda455f172e24 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Mon, 18 Aug 2014 09:53:20

Re: [FFmpeg-devel] [PATCH] alac: add option to decoded incorrect ALAC

2014-08-18 15:59 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: this is a proposal to allow decoding incorrect files. There is no obvious and systematic way to detect them however. Ignore the version.h stray change in your review, I thought I had removed it. -- Christophe

Re: [FFmpeg-devel] [RFC] [PATCH] proresenc_kostya: warn/reject on incorrect profile

2014-08-18 19:26 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: Hi, And with all patches. -- Christophe From 89b54fbd698eb9c68f0bf30105bcaf72c5575d27 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet christophe.gisq...@gmail.com Date: Mon, 18 Aug 2014 11:27:50 +0200 Subject: [PATCH

Re: [FFmpeg-devel] [RFC] [PATCH] proresenc_kostya: warn/reject on incorrect profile

Hi, 2014-08-18 13:40 GMT+02:00 Carl Eugen Hoyos ceho...@ag.or.at: Christophe Gisquet christophe.gisquet at gmail.com writes: If a profile was set, the automatic setting should probably not overwrite it. (If this is possible.) But I consider the usecase where a user wants to encode alpha

Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.

Hi, 2014-08-18 19:22 GMT+02:00 Ronald S. Bultje rsbul...@gmail.com: You mean the centerpoint chroma location (top-left, top-middle, middle-middle, etc.) respective to the set of luma pixels? I don't think it's only that, but it's probably only slightly longer to implement. For interlaced

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/proresenc_kostya: allocate 1 slice more to avoid triggering the reallocation warning when the used space is actually less than the allocated

Hi, 2014-08-18 21:49 GMT+02:00 Michael Niedermayer michae...@gmx.at: +int max_slice_size = (ctx-frame_size_upper_bound - 200) / (ctx-pictures_per_frame * ctx-slices_per_picture + 1); Regarding the reallocation check: pkt_size = buf - orig_buf + 2 * max_slice_size For last slice, pkt_size

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/proresenc_kostya: set initial max_slice_size based on frame_size_upper_bound

Hi, 2014-08-19 12:31 GMT+02:00 Michael Niedermayer michae...@gmx.at: suggested commit message: avcodec/proresenc_kostya: set initial max_slice_size based on frame_size_upper_bound If the initial max_slice_size is 0 then reallocation is disabled for the first slice. OK. --

[FFmpeg-devel] [PATCH 2/3] wavpackenc: report too small buffer

bytestream2_* will not cause buffer overflow, but on the other hand, it should be checked whether overflows have been prevented. --- libavcodec/wavpackenc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c index 5b8973c..46c69a3 100644 ---

[FFmpeg-devel] [PATCH 0/3] wavpack: buffer sizes

The decoder is reporting CRC errors instead of the prime cause of end-of-packet. This happens with current encoder when there are a few samples and the output buffer is undersized because its size didn't account for headers. Christophe Gisquet (3): wavpack: report if there is no bits left

[FFmpeg-devel] [PATCH 3/3] wavpackenc: proper buffer allocation

The allocation didn't account for headers, that can be easily 79 bytes. As a result, buffers allocated for a few samples (e.g. 5 in the original bug) could be undersized. Fixed ticket #2881. --- libavcodec/wavpackenc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

Re: [FFmpeg-devel] [PATCH 2/3] wavpackenc: report too small buffer

Hi, 2014-08-19 16:20 GMT+02:00 Nicolas George geo...@nsup.org: IMHO, the correct error depends on how sure you are that a buffer too small SHOULD not happen. If you are very sure, then av_assert0(). That would be it: I'm sure that, if the condition occurs and the packet is written anyway,

Re: [FFmpeg-devel] [PATCH] x86/hecv_res_add: add ff_hevc_transform_add{8, 16, 32}_8_avx

Hi, 2014-08-20 4:55 GMT+02:00 James Almer jamr...@gmail.com: ~15% faster than sse2 [...] @@ -509,7 +509,11 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const int bit_depth) if (ARCH_X86_64) { c-hevc_v_loop_filter_luma = ff_hevc_v_loop_filter_luma_8_avx;

[FFmpeg-devel] [PATCH 0/5] RGB48/64 with bits_per_raw_sample

and bits_per_raw_sample==12 is e.g. not rescaled to 16bits to match its rgb48 colorspace. One may argue that a proper solution is to reduce as often as possible references to bits_per_raw_sample and, instead, always use the colorspace information and to introduce new colorspaces as needed. Christophe

[FFmpeg-devel] [PATCH 3/5] dpxenc: fix encoding of packed RGB48/64

When input had 12 bits, it was invariably treated as packed RGB with 12 bits per component. --- libavcodec/dpxenc.c | 37 - 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c index aca745b..d02684b 100644 ---

[FFmpeg-devel] [PATCH 5/5] pnmdec: keep bitdepth rather than rescaling

pnmdec currently respects the consign of rgb48 content. Instead, do not rescale and make the bits_per_raw_sample valid and useful. --- libavcodec/pnmdec.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/libavcodec/pnmdec.c b/libavcodec/pnmdec.c index c84b6eb..36bdfe7 100644 ---

[FFmpeg-devel] [PATCH 2/5] pnmenc: use bits_per_raw_sample

This allows writing actual bitdepth in RGB48 when it isn't actually 16. --- libavcodec/pnmenc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/pnmenc.c b/libavcodec/pnmenc.c index e6c3635..9198ddb 100644 --- a/libavcodec/pnmenc.c +++ b/libavcodec/pnmenc.c @@ -84,6 +84,8 @@

[FFmpeg-devel] [PATCH 4/5] ffmpeg: keep bitdepth where possible

Thanks to av_get_pix_fmt_loss, we can determine more precisely if a conversion will incur some kind of loss. If this loss doesn't modify in particular bitdepth, the input bitdepth can be reused for the output. --- ffmpeg.c | 9 + 1 file changed, 9 insertions(+) diff --git a/ffmpeg.c

Re: [FFmpeg-devel] [PATCH 4/5] ffmpeg: keep bitdepth where possible

Hi, 2014-08-20 10:10 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: +if (!(av_get_pix_fmt_loss(enc_ctx-pix_fmt, dec_ctx-pix_fmt, 0) + (FF_LOSS_DEPTH|FF_LOSS_COLORSPACE|FF_LOSS_CHROMA))) { If it was ever useful, this is probably wrong

Re: [FFmpeg-devel] [PATCH 0/5] RGB48/64 with bits_per_raw_sample

Hi, 2014-08-20 10:10 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com: One may argue that a proper solution is to reduce as often as possible references to bits_per_raw_sample and, instead, always use the colorspace information and to introduce new colorspaces as needed. I'd prefer

  1   2   3   4   5   6   >