It's an intra codec, so no risk of drift. The simple idct version
clips to an incorrect range, which should be [4;1019] for YUV 10b,
while RGB 10b is fine.
---
libavcodec/dnxhddec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 3b1fbd
---
libavcodec/dct-test.c | 4
libavcodec/x86/dct-test.c | 31 ++-
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dct-test.c b/libavcodec/dct-test.c
index 9a195ab..9eab7fe 100644
--- a/libavcodec/dct-test.c
+++ b/libavcodec/dct-test.
---
libavcodec/dct-test.c | 22 +-
libavcodec/x86/dct-test.c | 22 +-
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dct-test.c b/libavcodec/dct-test.c
index 18d1ba7..24b23e2 100644
--- a/libavcodec/dct-test.c
+++ b/libavcodec
Currently, no arch-specific implementation of the simple idcts
actually exist, only their _put version, and for x86. Therefore,
wrap also the C version to allow easier comparison of the
generated results.
---
libavcodec/dct-test.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions
---
libavcodec/arm/dct-test.c | 10 --
libavcodec/dct-test.c | 41 +++--
libavcodec/ppc/dct-test.c | 10 --
libavcodec/x86/dct-test.c | 9 +++--
4 files changed, 58 insertions(+), 12 deletions(-)
diff --git a/libavcodec/arm/dct-test.c b
On 12 frames of a 444p 12 bits DNxHR sequence:
C: 78902 decicycles in idct, 262071 runs, 73 skips
avx: 32478 decicycles in idct, 262045 runs, 99 skips
Difference between the 2:
stddev:0.39 PSNR:104.47 MAXDIFF:2
This is unavoidable and due to the scale factors used
This should be reused for a generic simple_idct10 function.
Requires a bit of trickery to declare common constants in C.
---
libavcodec/x86/constants.c| 28 +++
libavcodec/x86/constants.h| 16 ++
libavcodec/x86/proresdsp.asm | 263 +---
Modeled from the prores version. Clips to [0;1023] and is bitexact.
Bitexactness requires to add an offset in a different place compared
to prores or C, and makes the function approximately 2% slower.
For 16 frames of a DNxHD 4:2:2 10bits test sequence:
C:60861 decicycles in idct, 1048205 run
The functions related to bitstream reading must use the natural zigzag
order, and not the one permuted for use in the iDCT. This currently
results in bitstreams with 2 issues:
- AC coefficients are encoded in an unexpected order;
- Incorrect weights are applied in the (de)quantization.
This curren
The patch series allowed to find issues on the encoder side with the
use of scans.
To introduce those idcts, the prores one is kind of 'templated', so as
to reuse the code for regular simple_idct. Unfortunately, the 12bits
version can't be bitexact to the C version because the later uses too
preci
Hi,
2015-10-08 1:38 GMT+02:00 Michael Niedermayer :
>> So I have made a fate test on 1 frame for each sequence (total around 1.8MB).
>>
>> Is it ok?
>
> ok
Here you go. Hendrik has kindly volunteered to upload the 2 samples for me.
--
Christophe
From 332b92d977ae04db0080973426ddc019d93a040b Mon
---
libavformat/matroskaenc.c | 43 +++
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 1fb39fe..81e859f 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -845
This solves the problem discussed in
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
by allowing AVCodec::write_header to be delayed until after packets have been
run through required bitstream filters in order to generate global extradata.
It also provides a mechanism by whi
---
libavformat/avformat.h | 8
libavformat/utils.c| 19 +++
2 files changed, 27 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index f3c8260..20759e3 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2758,6 +2758,14 @@
---
libavformat/avformat.h | 8
libavformat/utils.c| 48
2 files changed, 56 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index e2a27d4..5226b0a 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avfor
---
ffmpeg.c | 46 --
ffmpeg.h | 1 -
ffmpeg_opt.c | 6 +-
3 files changed, 9 insertions(+), 44 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index e31a2c6..b9cde79 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -682,47 +682,10 @@ static void wri
---
libavcodec/avcodec.h | 1 +
libavcodec/bitstream_filter.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index ff70d25..ce42e57 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5026,6 +5026,7 @@ typ
---
libavcodec/nvenc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 18bcd96..0e6ef43 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -742,8 +742,6 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
Change to https for FFmpeg websites.
Signed-off-by: Ganesh Ajjanagadde
---
doc/faq.texi | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/doc/faq.texi b/doc/faq.texi
index 5fe716b..ef111c7 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -147,7 +147,7 @@ exec
From: Timo Rothenpieler
Date: 2015-09-30 19:27
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 3/3][RFC] avfilter/vf_chromakey: Add OpenCL
acceleration
>> ping once again
>>
>> Hi
> Could you describe how to verify it, and how can I test it?
>
> Thanks
> Best re
On Wed, Oct 7, 2015 at 8:44 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Oct 7, 2015 at 6:22 PM, Ganesh Ajjanagadde
> wrote:
>>
>> Commit 6dac8c8327 disabled av_uninit for clang, due to some useless
>> warnings.
>> The concept of av_uninit is inherently useful though. This patch silences
>> a
>>
On Wed, Oct 7, 2015 at 8:21 PM, Michael Niedermayer
wrote:
> On Wed, Oct 07, 2015 at 06:22:08PM -0400, Ganesh Ajjanagadde wrote:
>> Commit 6dac8c8327 disabled av_uninit for clang, due to some useless warnings.
>> The concept of av_uninit is inherently useful though. This patch silences a
>> bunch
Hi,
On Wed, Oct 7, 2015 at 6:22 PM, Ganesh Ajjanagadde
wrote:
> Commit 6dac8c8327 disabled av_uninit for clang, due to some useless
> warnings.
> The concept of av_uninit is inherently useful though. This patch silences a
> bunch of warnings on clang e.g
>
> http://fate.ffmpeg.org/log.cgi?time=2
On Wed, Oct 07, 2015 at 06:22:08PM -0400, Ganesh Ajjanagadde wrote:
> Commit 6dac8c8327 disabled av_uninit for clang, due to some useless warnings.
> The concept of av_uninit is inherently useful though. This patch silences a
> bunch of warnings on clang e.g
> http://fate.ffmpeg.org/log.cgi?time=20
On Wed, Oct 07, 2015 at 10:46:50PM +0200, Hendrik Leppkes wrote:
> On Wed, Oct 7, 2015 at 10:18 PM, Michael Niedermayer
> wrote:
> > On Wed, Oct 07, 2015 at 12:28:51PM -0400, Derek Buitenhuis wrote:
> >> This makes the h.264 decoder threadsafe to initialize.
> >
> > can you explain why it is not t
On Wed, Oct 07, 2015 at 08:11:21PM +0200, Christophe Gisquet wrote:
> 2015-10-05 14:03 GMT+02:00 Christophe Gisquet :
> > Hi,
> >
> > 2015-10-05 13:18 GMT+02:00 Michael Niedermayer :
> >> do you have any testcases you can share for these ?
> >
> > I was provided some but that I assume not redistrib
On Mon, Oct 05, 2015 at 08:44:46PM +0200, Christophe Gisquet wrote:
> The MBAFF handling recently introduced on the decoder side shows that
> the encoder does not support it correctly. Therefore, make the related
> profile experimental.
>
> Furthermore, current encoder logic treats it as unable to
On Wed, Oct 07, 2015 at 17:47:44 -0400, Ganesh Ajjanagadde wrote:
> Since I am currently in the warning suppression business, I can help
> out at least in some basic checking. Unfortunately, I believe the icc
> is not freely licensed, which means I can't test this stuff.
I'll get in touch "when I
On Wed, Oct 7, 2015 at 3:34 PM, Michael Niedermayer
wrote:
> On Wed, Oct 07, 2015 at 12:29:35PM -0400, Ganesh Ajjanagadde wrote:
>> Commit 6dac8c8327 disabled av_uninit for clang, due to some useless warnings.
>> The concept of av_uninit is inherently useful though. This patch silences a
>> bunch
Commit 6dac8c8327 disabled av_uninit for clang, due to some useless warnings.
The concept of av_uninit is inherently useful though. This patch silences a
bunch of warnings on clang e.g
http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=x86_64-darwin-clang-polly-vectorize-stripmine-
On Mon, Oct 05, 2015 at 08:44:45PM +0200, Christophe Gisquet wrote:
> MBAFF-like handling of interlaced content in CID 1260 is different from
> the other CIDs, and in particular doesn't use the same syntax.
> ---
> libavcodec/dnxhddata.c | 2 +-
> libavcodec/dnxhddata.h | 3 ++-
> 2 files changed,
On Wed, Oct 7, 2015 at 5:35 PM, Moritz Barsnick wrote:
> On Wed, Oct 07, 2015 at 16:07:53 -0400, Ronald S. Bultje wrote:
>> > BTW, are the "remaining" (meaning: more than from gcc) warnings emitted
>> > by the Intel C(++) Compiler redundant or false? The icc configuration
>> > should then probably
On Wed, Oct 07, 2015 at 16:07:53 -0400, Ronald S. Bultje wrote:
> > BTW, are the "remaining" (meaning: more than from gcc) warnings emitted
> > by the Intel C(++) Compiler redundant or false? The icc configuration
> > should then probably silence them.
>
> I doubt anyone has ever investigated them
On Wed, Oct 07, 2015 at 08:08:39PM +0200, Christophe Gisquet wrote:
> 2015-10-07 10:32 GMT+02:00 Christophe Gisquet :
> >> this would allow ctx->bit_depth to be set but without initializing the
> >> dsp contexts
> >> subsequent runs would also skip init due to
> >> " if (ctx->bit_depth != old_bit_d
On Wed, Oct 7, 2015 at 10:18 PM, Michael Niedermayer
wrote:
> On Wed, Oct 07, 2015 at 12:28:51PM -0400, Derek Buitenhuis wrote:
>> This makes the h.264 decoder threadsafe to initialize.
>
> can you explain why it is not threadsafe currently ?
> (assuming "done = 1" would be moved to the end of
> f
On 10/7/2015 5:27 PM, Paul B Mahol wrote:
> +cglobal w3fdif_simple_high, 5, 10, 8, 0, work_line, in_lines_cur0,
> in_lines_adj0, coef, linesize
[...]
> +cglobal w3fdif_complex_high, 5, 14, 8, 0, work_line, in_lines_cur0,
> in_lines_adj0, coef, linesize
All the values in coeff_hf fit in words, so
Signed-off-by: Paul B Mahol
---
libavfilter/vf_w3fdif.c | 139 +++
libavfilter/w3fdif.h | 61 +++
libavfilter/x86/Makefile | 2 +
libavfilter/x86/vf_w3fdif.asm| 230 +++
libavfilter/x86/vf_w3fdif_i
On Wed, Oct 07, 2015 at 12:28:51PM -0400, Derek Buitenhuis wrote:
> This makes the h.264 decoder threadsafe to initialize.
can you explain why it is not threadsafe currently ?
(assuming "done = 1" would be moved to the end of
ff_h264_decode_init_vlc())
[...]
--
Michael GnuPG fingerprint: 9FF
Hi,
On Wed, Oct 7, 2015 at 3:46 PM, Moritz Barsnick wrote:
> On Tue, Oct 06, 2015 at 22:52:28 -0400, Ganesh Ajjanagadde wrote:
> > ping: the reason I persist in this is because (long-term) the only 2
> > compilers where we can reasonably reach a near "warning is regression"
> > state and benefit
On Tue, Oct 06, 2015 at 22:52:28 -0400, Ganesh Ajjanagadde wrote:
> ping: the reason I persist in this is because (long-term) the only 2
> compilers where we can reasonably reach a near "warning is regression"
> state and benefit from it are clang and gcc.
BTW, are the "remaining" (meaning: more t
---
libavcodec/x86/vp9dsp_init_16bpp_template.c | 4 +-
libavcodec/x86/vp9itxfm_16bpp.asm | 211 ++--
2 files changed, 202 insertions(+), 13 deletions(-)
diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c
b/libavcodec/x86/vp9dsp_init_16bpp_template.c
ind
On Wed, Oct 07, 2015 at 12:29:35PM -0400, Ganesh Ajjanagadde wrote:
> Commit 6dac8c8327 disabled av_uninit for clang, due to some useless warnings.
> The concept of av_uninit is inherently useful though. This patch silences a
> bunch of warnings on clang e.g
> http://fate.ffmpeg.org/log.cgi?time=20
On Wed, Oct 07, 2015 at 06:20:53PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil
>
> Modified sps and pps access from old HEVCContext(s) structure to newly
> introduced HEVCParamSets(ps)
>
> Signed-off-by: Shivraj Patil
> ---
> libavcodec/mips/hevcpred_msa.c | 282
> +
2015-10-05 14:03 GMT+02:00 Christophe Gisquet :
> Hi,
>
> 2015-10-05 13:18 GMT+02:00 Michael Niedermayer :
>> do you have any testcases you can share for these ?
>
> I was provided some but that I assume not redistributable. I asked the
> same question but got no reply.
>
> There's this one sequenc
2015-10-07 10:32 GMT+02:00 Christophe Gisquet :
>> this would allow ctx->bit_depth to be set but without initializing the
>> dsp contexts
>> subsequent runs would also skip init due to
>> " if (ctx->bit_depth != old_bit_depth) {"
>
> Actually, other changes could trigger the issue, like
> 4:2:2 10
On 8 October 2015 at 04:15, Hendrik Leppkes wrote:
> On Wed, Oct 7, 2015 at 7:06 PM, Matt Oliver wrote:
> > On 8 October 2015 at 03:29, Hendrik Leppkes wrote:
> >
> >> On Wed, Oct 7, 2015 at 6:23 PM, Matt Oliver
> wrote:
> >> > On 6 October 2015 at 21:36, Hendrik Leppkes
> wrote:
> >> >
> >>
On Wed, Oct 7, 2015 at 7:06 PM, Matt Oliver wrote:
> On 8 October 2015 at 03:29, Hendrik Leppkes wrote:
>
>> On Wed, Oct 7, 2015 at 6:23 PM, Matt Oliver wrote:
>> > On 6 October 2015 at 21:36, Hendrik Leppkes wrote:
>> >
>> >> The emulation uses native InitOnce* APIs on Windows Vista+, and a
>>
Le tridi 13 vendémiaire, an CCXXIV, Michael Niedermayer a écrit :
> whole patchset should be ok
Thanks. Warnings fixed (sorry about that) and series pushed.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel m
Hello wm4,
Wednesday, October 7, 2015, 7:40:45 PM, you wrote:
w> There's no automagic way to get this done.
w> Hardware accelerators like vaapi and vdpau need the same thing. These
w> have special APIs to set an API context on the decoder. Some APIs use
w> hwaccel_context, vdpau uses av_vdpau_bi
On 8 October 2015 at 03:29, Hendrik Leppkes wrote:
> On Wed, Oct 7, 2015 at 6:23 PM, Matt Oliver wrote:
> > On 6 October 2015 at 21:36, Hendrik Leppkes wrote:
> >
> >> The emulation uses native InitOnce* APIs on Windows Vista+, and a
> >> lock-free/allocation-free approach using atomics and spi
On Wed, 7 Oct 2015 19:20:56 +0300
Ivan Uskov wrote:
> Hello Hendrik,
>
> Wednesday, October 7, 2015, 5:58:25 PM, you wrote:
>
> HL> On Wed, Oct 7, 2015 at 4:41 PM, Ivan Uskov wrote:
>
> HL> Global static variables are not acceptable, sorry.
> HL> You'll have to find another way to solve your
On 10/7/2015 5:24 PM, Derek Buitenhuis wrote:
> This makes the h.264 decoder threadsafe to initialize.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/h264.c | 9 -
> libavcodec/h264.h | 7 +++
> 2 files changed, 15 insertions(+), 1 deletion(-)
Disregard this one, wrong ver s
On Wed, 7 Oct 2015 12:24:32 -0400
Derek Buitenhuis wrote:
> This makes the h.264 decoder threadsafe to initialize.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/h264.c | 9 -
> libavcodec/h264.h | 7 +++
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a
On Wed, Oct 7, 2015 at 12:29 PM, Ganesh Ajjanagadde
wrote:
> Commit 6dac8c8327 disabled av_uninit for clang, due to some useless warnings.
> The concept of av_uninit is inherently useful though. This patch silences a
> bunch of warnings on clang e.g
> http://fate.ffmpeg.org/log.cgi?time=2015091818
Commit 6dac8c8327 disabled av_uninit for clang, due to some useless warnings.
The concept of av_uninit is inherently useful though. This patch silences a
bunch of warnings on clang e.g
http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=x86_64-darwin-clang-polly-vectorize-stripmine-
On Wed, Oct 7, 2015 at 6:23 PM, Matt Oliver wrote:
> On 6 October 2015 at 21:36, Hendrik Leppkes wrote:
>
>> The emulation uses native InitOnce* APIs on Windows Vista+, and a
>> lock-free/allocation-free approach using atomics and spinning for Windows
>> XP.
>> ---
>>
>> This is in preparation to
This makes the h.264 decoder threadsafe to initialize.
Signed-off-by: Derek Buitenhuis
---
libavcodec/h264.c | 9 -
libavcodec/h264.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 3209c9c..1abdc4b 100644
--- a/libavcodec/
On Wed, Oct 7, 2015 at 6:10 PM, Derek Buitenhuis
wrote:
> On 10/7/2015 4:57 PM, wm4 wrote:
>> A static variable in a header file? This doesn't look right. You should
>> define it in h264.c instead.
>
> [17:03] <+wm4> Daemon404: what exactly is the point of declaring the
> init_once in the .h file
This makes the h.264 decoder threadsafe to initialize.
Signed-off-by: Derek Buitenhuis
---
libavcodec/h264.c | 9 -
libavcodec/h264.h | 7 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 3209c9c..1abdc4b 100644
--- a/liba
On 6 October 2015 at 21:36, Hendrik Leppkes wrote:
> The emulation uses native InitOnce* APIs on Windows Vista+, and a
> lock-free/allocation-free approach using atomics and spinning for Windows
> XP.
> ---
>
> This is in preparation to use pthread_once for global static init
> functions,
> and e
Hello Hendrik,
Wednesday, October 7, 2015, 5:58:25 PM, you wrote:
HL> On Wed, Oct 7, 2015 at 4:41 PM, Ivan Uskov wrote:
HL> Global static variables are not acceptable, sorry.
HL> You'll have to find another way to solve your problem, but global
HL> state is not the way to go.
Unfortunately I
On 10/7/2015 5:05 PM, Matt Oliver wrote:
> Couldnt all the above if/includes be simplified by just using a single
> include libavutil/thread.h (which has all the above checks in it.
So, I included "thread.h", which is from avcodec, and it failed. I think it's
pretty non-obvious I need the thread.h
On 10/7/2015 4:57 PM, wm4 wrote:
> A static variable in a header file? This doesn't look right. You should
> define it in h264.c instead.
[17:03] <+wm4> Daemon404: what exactly is the point of declaring the init_once
in the .h file?
[17:03] <@Daemon404> i didnt know the right place to put it
[17:
On 8 October 2015 at 02:39, Derek Buitenhuis
wrote:
> This makes the h.264 decoder threadsafe to initialize.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/h264.c | 7 ++-
> libavcodec/h264.h | 10 ++
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/libav
On 2 October 2015 at 05:14, Hendrik Leppkes wrote:
> On Thu, Oct 1, 2015 at 9:05 PM, wm4 wrote:
> > On Fri, 2 Oct 2015 02:58:52 +0800
> > Wang Bin wrote:
> >
> >> From b8b5ad2d6510778111c2a03ae5cfbe727ee6 Mon Sep 17 00:00:00 2001
> >> From: wang-bin
> >> Date: Tue, 29 Sep 2015 18:11:03 +08
On Wed, 7 Oct 2015 11:39:47 -0400
Derek Buitenhuis wrote:
> This makes the h.264 decoder threadsafe to initialize.
>
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/h264.c | 7 ++-
> libavcodec/h264.h | 10 ++
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --gi
On 10/7/2015 4:39 PM, Derek Buitenhuis wrote:
> +static pthread_once_t ff_h264_vlc_init = PTHREAD_ONCE_INIT;
I've added av_unused here locally.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
libavcodec/x86/vp9dsp_init_16bpp_template.c | 4 +-
libavcodec/x86/vp9itxfm_16bpp.asm | 299 +---
2 files changed, 234 insertions(+), 69 deletions(-)
diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c
b/libavcodec/x86/vp9dsp_init_16bpp_template.c
ind
This makes the h.264 decoder threadsafe to initialize.
Signed-off-by: Derek Buitenhuis
---
libavcodec/h264.c | 7 ++-
libavcodec/h264.h | 10 ++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 3209c9c..27a1d32 100644
--- a/l
From: Anton Khirnov
There's not much reason to generate such a small table at runtime.
Signed-off-by: Derek Buitenhuis
---
libavcodec/cabac.c | 207 ++-
libavcodec/cabac.h | 3 +-
libavcodec/cabac_functions.h | 8 +-
libavcodec/h2
This becomes unuseful in the following commit.
This reverts commit 092d1977cc7146f20c8db2155e7d648afb300de7.
Signed-off-by: Derek Buitenhuis
---
libavcodec/Makefile | 4 +-
libavcodec/cabac.c | 74 -
libavcodec/cabac.h | 7 +--
libav
Towards a glorious non-locking future.
Obviously requires Hendrik's phread_once patch.
Anton Khirnov (1):
cabac: Make cabac starts hardcoded
Derek Buitenhuis (2):
Revert "cabac: Allow hardcoding CABAC table."
h264: Run VLC init under pthread_once
libavcodec/Makefile | 4 +-
li
On Wed, Oct 7, 2015 at 4:41 PM, Ivan Uskov wrote:
> Hello All,
>
> The attached patch represents new design for qsv session control and internal
> allocation. All qsv modules now uses instance of AVQSVContext so now session
> allocates by external application and session allocates internally by f
On Wed, Oct 07, 2015 at 06:21:59PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil
>
> Modified datatype of function argument (pitch from int32_t to ptrdiff_t)
>
> Signed-off-by: Shivraj Patil
> ---
> libavcodec/mips/vp9_lpf_msa.c | 42
>
Hello All,
The attached patch represents new design for qsv session control and internal
allocation. All qsv modules now uses instance of AVQSVContext so now session
allocates by external application and session allocates internally by ffmpeg
itself handles by unified way.
For the case of int
On Wed, Oct 07, 2015 at 06:20:53PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil
>
> Modified sps and pps access from old HEVCContext(s) structure to newly
> introduced HEVCParamSets(ps)
>
> Signed-off-by: Shivraj Patil
> ---
> libavcodec/mips/hevcpred_msa.c | 282
> +
On Wed, Oct 7, 2015 at 3:59 AM, Ronald S. Bultje wrote:
> diff --git a/libavcodec/x86/vp9itxfm_16bpp.asm
> b/libavcodec/x86/vp9itxfm_16bpp.asm
> +%macro IADST4_12BPP_1D 0
> +pandm4, m0, [pd_3fff]
> +pandm5, m1, [pd_3fff]
> +psrad m0, 14
>
On Wed, Oct 7, 2015 at 10:01 AM, Clément Bœsch wrote:
> On Wed, Oct 07, 2015 at 09:31:49AM -0400, Ganesh Ajjanagadde wrote:
>> On Wed, Oct 7, 2015 at 8:59 AM, Clément Bœsch wrote:
>> > On Tue, Oct 06, 2015 at 06:53:47PM -0400, Ganesh Ajjanagadde wrote:
>> >> This adds av_warn_unused_result whenev
On Wed, Oct 07, 2015 at 09:31:49AM -0400, Ganesh Ajjanagadde wrote:
> On Wed, Oct 7, 2015 at 8:59 AM, Clément Bœsch wrote:
> > On Tue, Oct 06, 2015 at 06:53:47PM -0400, Ganesh Ajjanagadde wrote:
> >> This adds av_warn_unused_result whenever it is relevant.
> >>
> >> Signed-off-by: Ganesh Ajjanagad
On Wed, Oct 7, 2015 at 8:59 AM, Clément Bœsch wrote:
> On Tue, Oct 06, 2015 at 06:53:47PM -0400, Ganesh Ajjanagadde wrote:
>> This adds av_warn_unused_result whenever it is relevant.
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavfilter/buffersrc.h | 3 +++
>> 1 file changed, 3 insertion
On Wed, Oct 7, 2015 at 8:56 AM, Michael Niedermayer
wrote:
> On Sat, Sep 19, 2015 at 01:00:17AM -0400, Ganesh Ajjanagadde wrote:
>> Commit 6dac8c8327 disabled av_uninit for clang, due to some useless warnings.
>> The concept of av_uninit is inherently useful though. This patch silences a
>> bunch
The original interpolation algorithm behaved poorly on the borders and
did not even guarantee continuity at the borders. For this reason, a
second interpolation/blending pass was required on the borders to make
them seamless.
However, since the interpolation algorithm was improved in June 2013,
th
On Tue, Oct 06, 2015 at 06:53:47PM -0400, Ganesh Ajjanagadde wrote:
> This adds av_warn_unused_result whenever it is relevant.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavfilter/buffersrc.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavfilter/buffersrc.h b/libavfilter/
On Sat, Sep 19, 2015 at 01:00:17AM -0400, Ganesh Ajjanagadde wrote:
> Commit 6dac8c8327 disabled av_uninit for clang, due to some useless warnings.
> The concept of av_uninit is inherently useful though. This patch silences a
> bunch of warnings on clang e.g
> http://fate.ffmpeg.org/log.cgi?time=20
On Wed, 7 Oct 2015 14:19:58 +0200, Stefano Sabatini wrote:
> > > LGTM. BTW, if you want to drop the band option, you could ifdef it so
> > > that it will be dropt at the next lavfi major bump.
> >
> > Good idea. Something like this?
> >
> > ---
> > libavfilter/vf_delogo.c |6 ++
> > 1 fi
Hi,
On Tue, Oct 6, 2015 at 10:48 PM, Ganesh Ajjanagadde
wrote:
> This patch moves the pointer validity check outside the macro,
> and silences the -Waddress observed with GCC 5.2.
>
> Note that this changes the error message slightly, from:
> "bad option..." to "Error parsing option...".
>
> Sig
From: Shivraj Patil
Modified datatype of function argument (pitch from int32_t to ptrdiff_t)
Signed-off-by: Shivraj Patil
---
libavcodec/mips/vp9_lpf_msa.c | 42 -
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/libavcodec/mips/vp9_lpf_
From: Shivraj Patil
Modified sps and pps access from old HEVCContext(s) structure to newly
introduced HEVCParamSets(ps)
Signed-off-by: Shivraj Patil
---
libavcodec/mips/hevcpred_msa.c | 282
1 file changed, 141 insertions(+), 141 deletions(-)
diff --
On Wed, Oct 07, 2015 at 01:33:58PM +0300, Arttu Ylä-Outinen wrote:
> On 2015-09-29 16:29, Arttu Ylä-Outinen wrote:
> >These patches fix some problems in libkvazaar encoder and update it to work
> >with the latest git version of Kvazaar. Most notable changes are setting
> >pts, dts and keyframe flag
On date Wednesday 2015-10-07 13:57:46 +0200, Jean Delvare encoded:
> Hi Stefano,
>
> On Wed, 7 Oct 2015 11:21:45 +0200, Stefano Sabatini wrote:
> > On date Wednesday 2015-10-07 08:54:59 +0200, Jean Delvare encoded:
> > > The original interpolation algorithm behaved poorly on the borders and
> > >
On Tue, 6 Oct 2015 20:13:58 -0300
James Almer wrote:
> On 10/6/2015 5:33 PM, Paul B Mahol wrote:
> > you set aligned number of samples before calling get_buffer and after
> > that changes
> > frame->nb_samples to actual number of samples.
> >
> > Alternatively IIRC default 16 byte alignment coul
On Tue, 6 Oct 2015 20:07:08 -0500
Rodger Combs wrote:
> This solves the problem discussed in
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
> by allowing AVCodec::write_header to be delayed until after packets have been
> run through required bitstream filters in order t
On Tue, Oct 06, 2015 at 08:07:08PM -0500, Rodger Combs wrote:
> This solves the problem discussed in
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
> by allowing AVCodec::write_header to be delayed until after packets have been
> run through required bitstream filters in or
Hi Stefano,
On Wed, 7 Oct 2015 11:21:45 +0200, Stefano Sabatini wrote:
> On date Wednesday 2015-10-07 08:54:59 +0200, Jean Delvare encoded:
> > The original interpolation algorithm behaved poorly on the borders and
> > did not even guarantee continuity at the borders. For this reason, a
> > second
Hi,
On Tue, Oct 6, 2015 at 10:48 PM, Ganesh Ajjanagadde
wrote:
> This patch moves the pointer validity check outside the macro,
> and silences the -Waddress observed with GCC 5.2.
>
> Note that this changes the error message slightly, from:
> "bad option..." to "Error parsing option...".
>
> Sig
Hi,
On Wed, Oct 7, 2015 at 5:38 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/x86/vf_blend.asm| 62
> +
> libavfilter/x86/vf_blend_init.c | 14 ++
> 2 files changed, 76 insertions(+)
>
> diff --git a/libavfilter/x8
On Tue, Oct 06, 2015 at 11:15:49PM -0400, Ganesh Ajjanagadde wrote:
> Change to https for FFmpeg websites.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> doc/developer.texi | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
applied
thanks
[...]
--
Michael GnuPG fingerprint
On 2015-09-29 16:29, Arttu Ylä-Outinen wrote:
These patches fix some problems in libkvazaar encoder and update it to work
with the latest git version of Kvazaar. Most notable changes are setting
pts, dts and keyframe flag on the output packets and fixing the calculation
of the framerate.
v2: Add
Signed-off-by: Paul B Mahol
---
libavfilter/x86/vf_blend.asm| 62 +
libavfilter/x86/vf_blend_init.c | 14 ++
2 files changed, 76 insertions(+)
diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index 167e72b..7180817 10064
On date Wednesday 2015-10-07 08:54:59 +0200, Jean Delvare encoded:
> The original interpolation algorithm behaved poorly on the borders and
> did not even guarantee continuity at the borders. For this reason, a
> second interpolation/blending pass was required on the borders to make
> them seamless
1 - 100 of 101 matches
Mail list logo
