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 +---
null
+++ b/libavcodec/x86/simple_idct10.asm
@@ -0,0 +1,53 @@
+;**
+;* x86-SIMD-optimized IDCT for prores
+;* this is identical to "simple" IDCT written by Michael Niedermayer
+;* except for the clip range
+;*
+;* Copyright (c) 2011 Ronald S. Bul
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
nxhd decoder is updated to use these idcts by setting its
default to auto: as an intra-only codec, and seeing the stddev/maxdiff,
it seems ok to use the faster ones available.
Christophe Gisquet (9):
dnxhdenc: fix scan used for bitstream generation
x86: prores: templatize 10 bits si
0080973426ddc019d93a040b Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 5 Oct 2015 17:37:38 +0200
Subject: [PATCH] fate: add DNxHD/HR tests
Currently only 2 profiles are evaluated because they are the only 2
with distributed test sequences.
- CID 1260: YUV 4:2:2 10 bits with block-a
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 rep
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 ch
Hi,
> 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 bits -> 4:4:4 8 bits (unknown, unsupported) -> 4:2:2
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, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dnxhddata.c b/libavcod
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 encode as
progressive, which isn't the case.
---
libavcodec/dnxhddata.c | 5
Profiles 1256 & 1270 (currently) signal at the frame header and MB
levels the colorspace used, either RGB or YUV. While a MB-level
varying colorspace is not supported, whether it is constant can be
tracked so as to determine the exact colorspace.
It is not tested against a true RGB sequence, thoug
Fixing different issues occurring when playing around encoder and decoder.
Christophe Gisquet (3):
dnxhddec: better support for 4:4:4
dnxhddata: introduce and use MBAFF flag
dnxhdenc: mark CID 1260 encoder experimental
libavcodec/dnxhddata.c | 7 -
libavcodec/dnxhddata.h | 3
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 sequence here that I assume to be redistributable:
https://trac.ffmpe
Hi,
2015-10-04 4:14 GMT+02:00 Michael Niedermayer :
> ./ffmpeg -f lavfi -i testsrc=s=1440x1080 -vframes 1 -pix_fmt yuv422p -vcodec
> dnxhd -vb 80M -flags +ildct file.mov
btw this afaik uses CID 1260 which has a particular feature,
MBAFF-like. While we do handle it since a few revision, I suspec
Hi,
2015-10-05 10:57 GMT+02:00 tim nicholson :
> I thought JJ had got hold of a copy of the specs...
He was quick to notice the 2014 ones do not cover DNxHR. But the
bitstream doesn't seem to depart that much from the old stuff, and
ffmpeg's output after this patch series seems adequate.
--
Chr
Hi,
2015-10-05 8:44 GMT+02:00 tim nicholson :
> On 02/10/15 20:00, Christophe Gisquet wrote:
>> A series of 0 in a table can be confusing, and the corresponding checks
>> strange, so using a macro instead of that magic is more readable.
>> ---
>>
2015-10-03 18:59 GMT+02:00 Christophe Gisquet :
[SNIP]
There was a blank space in there (I think).
Patch updated
--
Christophe
0008-dnxhd-add-better-support-for-CIDs-1270-to-1274.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg
Hi,
2015-10-03 19:50 GMT+02:00 Carl Eugen Hoyos :
> Looks unintended...
Indeed. Patch updated.
--
Christophe
0001-dnxhddec-cleanup-frame-header-parsing.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpe
Hi,
Le 4 oct. 2015 04:16, "Michael Niedermayer" a écrit :
>
> On Sat, Oct 03, 2015 at 06:59:22PM +0200, Christophe Gisquet wrote:
> > The functions related to bitstream reading must use the natural zigzag
> > order, and not the one permuted for use in the iDCT
From: Jeremy James
Signed-off-by: Christophe Gisquet
---
libavcodec/dnxhddata.c | 8
libavcodec/dnxhddec.c | 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 798cc0e..5fb7a5e 100644
--- a/libavcodec
The functions related to bitstream reading must use the natural zigzag
order, and not the one permuted for use in the iDCT.
This resulted in a bitstream where the AC coefficients were encoded in
an unexpected order.
---
libavcodec/dnxhdenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(
: Christophe Gisquet
---
libavcodec/dnxhddata.c | 64 +--
libavcodec/dnxhddec.c | 92 ++
2 files changed, 118 insertions(+), 38 deletions(-)
diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index e2838de..241ce23
This a 4:4:4 10 bits profile, where image size is not fixed by the
profile, and which strays a bit outside the old frame header parsing
code.
Fixes ticket #4581 (DNxHR is not stricly supported, but that sequence is).
---
libavcodec/dnxhddata.c | 24
libavcodec/dnxhddec.c
Currently not used, but will be used to indicate that a CIDEntry field
is not set, because it is variable, and that checks should be adapted.
---
libavcodec/dnxhddata.h | 3 +++
libavcodec/dnxhddec.c | 6 --
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dnxhddata.h
This is actually similar to DNxHD.
---
libavformat/isom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index eff04ff..e55738b 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -240,6 +240,7 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
The encoder can only deal with 4:2:2.
---
libavcodec/dnxhddata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 4bb215a..798cc0e 100644
--- a/libavcodec/dnxhddata.c
+++ b/libavcodec/dnxhddata.c
@@ -,7 +,7 @@ int ff_
Move the 'interlaced' flag to this element (arbitrarily set to 16bits).
This should allow better detection/selection of profiles.
---
libavcodec/dnxhddata.c | 49 -
libavcodec/dnxhddata.h | 6 +-
2 files changed, 37 insertions(+), 18 deletions(-
Rely more on the actual syntax from the specs (also seen in the
encoder code).
---
libavcodec/dnxhddec.c | 55 +--
1 file changed, 27 insertions(+), 28 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 296f7f7..2f2d989 10
Cleaned up version of v1, with the first patches fixing bugs exacerbated
by the following new code, in general improving the current code so as to
introduce DNxHR.
DNxHR is then added progressively, in particular the extended handling
needed.
Christophe Gisquet (7):
dnxhddec: cleanup frame
2015-10-02 21:00 GMT+02:00 Christophe Gisquet :
> This a 4:4:4 10 bits profile, where image size is not fixed by the
> profile, and which strays a bit outside the old frame header parsing
> code.
>
> Fixes ticket #4581 (DNxHR is not stricly supported, but that sequence is).
reflog
Hi,
2015-10-02 20:57 GMT+02:00 Christophe Gisquet :
> @@ -498,7 +498,7 @@ void dnxhd_unquantize_c(DNXHDEncContext *ctx, int16_t
> *block, int n,
> : ctx->cid_table->luma_weight;
>
> for (i = 1; i <= last_index; i++)
A series of 0 in a table can be confusing, and the corresponding checks
strange, so using a macro instead of that magic is more readable.
---
libavcodec/dnxhddata.c | 10 +-
libavcodec/dnxhddata.h | 3 +++
libavcodec/dnxhddec.c | 6 --
3 files changed, 12 insertions(+), 7 deletions(
From: Jeremy James
These are DNxHR profiles with the following properties:
- Variable size in a profile, requiring variable-sized macroblock table
- Variable bitdepth, up to 12 bits
Signed-off-by: Christophe Gisquet
---
libavcodec/dnxhddata.c | 61 ++-
libavcodec
This a 4:4:4 10 bits profile, where image size is not fixed by the
profile, and which strays a bit outside the old frame header parsing
code.
Fixes ticket #4581 (DNxHR is not stricly supported, but that sequence is).
---
libavcodec/dnxhddata.c | 23 +
libavcodec/dnxhddec.c |
This is actually similar to DNxHD.
---
libavformat/isom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index eff04ff..e55738b 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -240,6 +240,7 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
From: Jeremy James
Signed-off-by: Christophe Gisquet
---
libavcodec/dnxhddata.c | 7 +++
libavcodec/dnxhddec.c | 5 +++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
index 0cbc57b..e39208d 100644
--- a/libavcodec
CIDs 1270 (10 & 12bits) to 1274, as produced by Avid Media Composer,
have been tested. I merged and adapted a bit Jeremy's work (but it's
mostly his code), hence the signing-off.
Christophe Gisquet (3):
isom: add support for DNxHR codec family
dnxhd: add CID 1270
dnxhddec: r
Forward and inverse DCTs may not have the same permutation table,
resulting in a bitstream where the AC coefficients are encoded in
an unexpected order.
---
libavcodec/dnxhdenc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
2015-09-28 18:51 GMT+02:00 Christophe Gisquet :
[SNIP]
Could someone also apply the cosmetic patch for reindentation?
Thanks,
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
it was intended to fix coded_height.
Here's an updated patch.
--
Christophe
From c10e86ce4469b81ac66b7fa2dd233efd191f508c Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Wed, 30 Sep 2015 10:14:59 +0200
Subject: [PATCH 1/3] dnxhddec: initialize with mb-aligned dimensions
The coded
Otherwise, the dsp may change without its permuation being applied.
---
libavcodec/dnxhddec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 8d9b7f0..18b2d51 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
The current one, while correct, does not yield the best possible
results. The specificiations suggest another formula, which results
in quality gains in the decoded output from fate tests. This
justifies changing said formula.
---
libavcodec/dnxhddec.c | 3 ++-
tests/ref/vs
The coded size is a multiple of the macroblock size, which is 16.
---
libavcodec/dnxhddec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index e3dec78..3985318 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -87,6 +87,9 @@ s
The last one is needed for dsp implementations. This set
is mostly meant to evacuate the simplest parts before
DNxHR support is added.
Christophe Gisquet (3):
dnxhddec: initialize with mb-aligned dimensions
dnxhddec: use dequantization formula from specs
dnxhddec: init scantable once
stophe
From 8da8a89ecf33e0c550fa61d6423a64650f6fc770 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 28 Sep 2015 13:59:23 +0200
Subject: [PATCH 01/17] blockdsp: remove high bitdepth parameter
It is only (mis-)used to set the dsp fucntions clear_block(s). But
these functions always work on 16bits-wide elements,
2015-10-01 14:40 GMT+02:00 Ronald S. Bultje :
> bash-3.2$ grep ff_pixblockdsp_init ../libavcodec/*
> ../libavcodec/asvenc.c:ff_pixblockdsp_init(&a->pdsp, avctx);
> ../libavcodec/avdct.c:ff_pixblockdsp_init(&pdsp, avctx);
> ../libavcodec/dnxhdenc.c:ff_pixblockdsp_init(&ctx->m.pdsp, a
2015-09-28 18:51 GMT+02:00 Christophe Gisquet :
> I admit I haven't run this over all of fate, so it would be nice to
> validate nothing actually uses it for pixels (I have see nothing of
> the sort).
Passes fate-video fate-vcodec on Win64.
2015-09-28 11:21 GMT+02:00 Christophe Gisquet :
> Please ignore for now.
The specs explicitly says it is the same for luma and chroma. Here's a
patch that confidently reflects that.
--
Christophe
From bfbb0bdde4eee8d44d9c158e04b50fb4177c428f Mon Sep 17 00:00:00 2001
From: Christophe
From d89cdcaf4f71bcb910e57184c2024029f09b3903 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 28 Sep 2015 13:59:23 +0200
Subject: [PATCH 2/7] blockdsp: remove high bitdepth parameter
It is only (mis-)used to set the dsp fucntions clear_block(s). But
these functions always work on 16bits-wide elements, which
Hi,
2015-09-27 10:09 GMT+02:00 Christophe Gisquet :
> CID 1256 chroma table is the same as luma table for CID 1235 and 1256,
> which is consistent with the content being (normally) RGB.
Please ignore for now.
--
Christophe
___
ffmpeg-devel m
., Baptiste Coudurier
* Copyright (c) 2011 MirriAd Ltd
+ * Copyright (c) 2015 Christophe Gisquet
*
* 10 bit support added by MirriAd Ltd, Joseph Artsimovich
+ * Slice multithreading and MB interlaced support added by Christophe Gisquet
*
* This file is part of FFmpeg.
*
--
2.5.2
CID 1256 chroma table is the same as luma table for CID 1235 and 1256,
which is consistent with the content being (normally) RGB.
CID 1244 weight tables are identica to CID 1244, but as this was not
tested against a real sample, it was not added.
---
libavcodec/dnxhddata.c | 16 +++-
---
libavcodec/dnxhddec.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 06d4780..7b96004 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -64,18 +64,18 @@ typedef struct DN
Each line is padded by the format, and errors are now reported and
stop the decoding. Around 5% speedup.
---
libavcodec/dnxhddec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 8d30446..06d4780 100644
--- a/libavcodec/dnxhddec.c
+++ b/libav
Fewer arguments, less duplicated code.
---
libavcodec/dnxhddec.c | 43 ---
1 file changed, 16 insertions(+), 27 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 34cf379..007eabe 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcode
This only occur when an overrun in coefficient decoding is
detected.
---
libavcodec/dnxhddec.c | 48 ++--
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 007eabe..8d30446 100644
--- a/li
---
libavcodec/dnxhddec.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index fa93407..34cf379 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -63,7 +63,7 @@ typedef struct DNXHDContex
Nothing major, mostly related to error reporting.
Christophe Gisquet (7):
dnxhddec: remove unused qscale parameter
dnxhddec: simplify block parsing calls
dnxhddec: check and report bitstream errors
dnxhddec: use unsafe bitstream reader
dnxhddec: reindent/cosmetics
dnxhddata
around execute2
The speed of slice-threading is equivalent to frame-threading, which
makes the later less attractive. Several decoders forgo implementing
it.
--
Christophe
From 354a8e016e1e10a4288534782104479aae3e62a9 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Fri, 25 Sep 2015 08
2015-09-25 23:25 GMT+02:00 Christophe Gisquet :
[SNIP]
I have reordered the patches so that they don't rely on the slice threading one.
Therefore this one should apply cleanly. (And also not using git
send-email for replies)
From d9601c7b74b5dea0f0be9989cc657fad90c1be7d Mon Sep 17 00:00:00
It currently only applies to CID 1260, but this flag is dependent on
a higher-level flag located in the header.
---
libavcodec/dnxhddec.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 044e479..e5c5f07 100644
--- a/liba
I have reordered the patches so that they don't rely on the slice threading one.
Therefore this one should apply cleanly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
2015-09-26 8:33 GMT+02:00 Christophe Gisquet :
> Is it something that should be avoidable through my code?
I now think so, so please ignore me till I've understood all of the API.
--
Christophe
___
ffmpeg-devel mailing list
ffmp
Hi,
2015-09-26 1:52 GMT+02:00 Michael Niedermayer :
> This segfaults with
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2125/DNxHDtest2.mov
Can't reproduce with frame or slice threading or no threading. What
was the command-line?
> #3 0x00af53fd in avcodec_default_execute2 (c=0x1c
Indicates a YCbCr->RGB transform at the block level. Although nothing
explicitly states it, this would assume the actual content is planar
RGB.
Currently unsupported, but the one sequence I found using it flagged
every mb that way, actually meaning the content was YCbCr, and thus
best left to the
It currently only applies to CID 1260, but this flag is dependent on
a higher-level flag located in the header.
---
libavcodec/dnxhddec.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 0722aa0..82a0d3c 100644
--- a/liba
It is supposed to only old BT.709 colorspaces.
---
libavcodec/dnxhddec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index d9762e4..0722aa0 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -82,6 +82,7 @@ static av_cold int dnxh
Around 3x speedup with 4 threads. Maybe more mb lines should be
batched per thread, but that's good enough for a first try.
---
libavcodec/dnxhddec.c | 221 ++
1 file changed, 133 insertions(+), 88 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/l
ture, but until there's actually change in the flag
value, it is useless. It raises again the question of colorspace
conversion in a codec when various libraries exist.
Christophe Gisquet (4):
dnxhddec: implement slice multithreading
dnxhddec: indicate colorspace
dnxhddec: proper rule fo
Hi,
2015-09-25 22:36 GMT+02:00 Ronald S. Bultje :
> +pd_16: times 8 dd 16
In h264_intrapred_10bit.asm
> +pd_32: times 8 dd 32
In h264_idct_10bit.asm
And that's about anything remotely useful I have to say, as you were
careful about those duplications.
> +pmaxsw m0, m4
> +
.
Fixes last issue from ticket #4876.
Found-by: Christophe Gisquet
Signed-off-by: Christophe Gisquet
---
libavcodec/dnxhddata.c | 103 +++--
1 file changed, 31 insertions(+), 72 deletions(-)
diff --git a/libavcodec/dnxhddata.c b/libavcodec/dnxhddata.c
This bit is 1 in some samples, and seems to coincide with interlaced
mbs and CID1260. 2008 specs do not know about it, and maintain qscale
is 11 bits. This looks oversized, but may help larger bitdepths.
Currently, it leads to an obviously incorrect qscale value, meaning
its syntax is shifted by 1
There are 2 issues, listed in ticket #4876:
- new mb header syntax, where the firt bit indicates mbaff-like handling
- incorrectly scanned weight tables
Christophe Gisquet (1):
dnxhddec: decode and use interlace mb flag
Jeremy James (1):
dnxhddata: correct weight tables
libavcodec
Hi,
2015-09-23 17:06 GMT+02:00 Mickaël Raulet :
> the fix looks weird to me. There is something else underlying.
The issue appeared in d249e682 (not the hash I reported, for some
reason). If you want to test, that commit is buggy (it causes
crashes): commit 7117547 is needed to fix it.
IIRC (the
Hi,
under highly-threaded loads, parallel decoding of WPP is subject to a
race condition.
This basically fixes ticket #4365.
--
Christophe
From ec49c1774c93b52ff83098b8b531ba4084b3bbb2 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Tue, 14 Apr 2015 17:56:54 +0200
Subject: [PATCH 71
The sample position is made weird and non-nominal to force catching
such issues as default values or specialized operations hiding
issues in corner cases.
---
tests/fate/filter-video.mak | 4
tests/ref/fate/filter-scalechroma | 26 ++
2 files changed, 30 inserti
For yuv420p, the chroma position is unilaterally overriden, even
if ffmpeg's command-line explicitly set it. To fix this, override
only if the value is the default one.
Regression since 1515bfb3.
---
libavfilter/vf_scale.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/
fate-vfilter/vcodec on win64.
Christophe Gisquet (2):
vf_scale: conditionally override chroma position
fate: add chroma position scale test
libavfilter/vf_scale.c| 6 +++---
tests/fate/filter-video.mak | 4
tests/ref/fate/filter-scalechroma | 26
ople:
> Michael Niedermayer
> Clément Bœsch
> James Almer
> Paul B Mahol
> Carl Eugen Hoyos
> Andreas Cadhalpun
> Ronald S. Bultje
> wm4
> Lukasz Marek
> Rostislav Pehlivanov
> Hendrik Leppkes
> Christophe Gisquet
>
Sent from a phone so please excuse terseness.
Le 20 sept. 2015 12:47, "Ronald S. Bultje" a écrit:
> if (more_data < 0) {
> s->tab_slice_address[ctb_addr_rs] = -1;
> +avpriv_atomic_int_set(&s1->wpp_err, 1);
> +ff_thread_report_progress2(s->avctx, ctb_r
2015-03-15 8:48 GMT+01:00 Christophe Gisquet :
> The second patch is the most interesting, because it prevents incorrect
> uses of LOCAL_ALIGNED that may have only caused warnings.
>
> This patch is of course smaller because of the code duplication removal
> of the first patch
Force an additional parameter then.
---
libavutil/internal.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/internal.h b/libavutil/internal.h
index 9ba2ea0..8081fdb 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -107,9 +107,9 @@
t (*v) o = l
The later may yield incorrect code for on-stack variables.
---
libavcodec/ppc/h264dsp.c| 8 +++
libavcodec/ppc/h264qpel.c | 50 -
libavcodec/ppc/vp8dsp_altivec.c | 2 +-
3 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/lib
The second patch is the most interesting, because it prevents incorrect
uses of LOCAL_ALIGNED that may have only caused warnings.
This patch is of course smaller because of the code duplication removal
of the first patch.
Christophe Gisquet (3):
lavc/lavu: remove LOCAL_ALIGNED_*
lavu
They were duplicating LOCAL_ALIGNED() without benefit.
---
configure | 8 +++-
libavcodec/aacps.c | 6 +++---
libavcodec/aacsbr.c| 6 +++---
libavcodec/ac3enc.c| 2 +-
libavcodec/ac3enc_template.c
0:00:00 2001
From: Christophe Gisquet
Date: Sat, 14 Mar 2015 14:26:16 +0100
Subject: [PATCH 1/3] lavc: use LOCAL_ALIGNED instead of DECLARE_ALIGNED
The later may yield incorrect code for on-stack variables.
---
libavcodec/dct-test.c | 2 +-
libavcodec/h264_loopfilter.c| 10 +
+LOCAL_ALIGNED(16, static int16_t, qmat, [64]); \
>> +LOCAL_ALIGNED(16, static int16_t, tmp, [64]); \
>> int i; \
>
> LOCAL_ALIGNED + static looks unintended
Same fix then.
Best regards,
Christophe
From 93a8d803f6b87e2c5bd062724630e1d67804da29 Mon Sep 17 00:00:00
Hi,
2015-03-14 18:38 GMT+01:00 Michael Niedermayer :
>> static void ff_prores_idct_wrap(int16_t *dst){
>> -DECLARE_ALIGNED(16, static int16_t, qmat)[64];
>> +LOCAL_ALIGNED(16, static int16_t, qmat, [64]);
>> int i;
>
> this seems to break build
>
> ffmpeg/libavcodec/dct-test.c: In fu
The later may yield incorrect code for on-stack variables.
---
libavcodec/ppc/h264dsp.c| 10 -
libavcodec/ppc/h264qpel.c | 50 -
libavcodec/ppc/vp8dsp_altivec.c | 2 +-
3 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/l
The later may yield incorrect code for on-stack variables.
---
libswscale/ppc/swscale_altivec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libswscale/ppc/swscale_altivec.c b/libswscale/ppc/swscale_altivec.c
index a1548a7..3034c72 100644
--- a/libswscale/ppc/swscale_alt
The later may yield incorrect code for on-stack variables.
---
libavcodec/x86/ac3dsp_init.c | 2 +-
libavcodec/x86/cavsdsp.c | 4 ++--
libavcodec/x86/dct-test.c | 4 ++--
libavcodec/x86/h264_qpel.c| 22 +++---
libavcodec/x86/rv40dsp_init.c | 2 +-
libavcodec/x86/v
They were duplicating LOCAL_ALIGNED() without benefit.
---
configure | 8 +++-
libavcodec/aacps.c | 6 +++---
libavcodec/aacsbr.c| 6 +++---
libavcodec/ac3enc.c| 2 +-
libavcodec/ac3enc_template.c
The later may yield incorrect code for on-stack variables.
---
libavcodec/dct-test.c | 2 +-
libavcodec/h264_loopfilter.c| 10 +-
libavcodec/proresenc_anatoliy.c | 3 ++-
libavcodec/vp8.c| 2 +-
4 files changed, 9 insertions(+), 8 deletions(-)
diff --git a
uplication, the last patch simply removes all
LOCAL_ALIGNED_* macros.
All changes (core+x86) tested with:
fate-vfilter fate-vcodec fate-h264 fate-ac3 fate-vp8 fate-cavs fate-vc1
for Win32 and Win64.
Christophe Gisquet (5):
lavc: use LOCAL_ALIGNED instead of DECLARE_ALIGNED
x86: lavc: use LOCAL_ALIGNED
This is the remaining error, the output on the SPX samples,
respectively csi_miami_stereo_128_spx.eac3 and
csi_miami_5.1_256_spx.eac3, goes from:
stddev:8.71 PSNR: 77.52 MAXDIFF: 235
stddev:24270.51 PSNR: 22.17 MAXDIFF:47166
to:
stddev:0.12 PSNR:114.12 MAXDIFF:1
stddev:0.12 PSNR:11
Should also improve decoding, but actually doesn't...
---
libavcodec/ac3dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 2f78d73..ce45186 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -872,7 +872,7 @@ static i
---
libavcodec/ac3dec.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index ae4129f..ac53bdc 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -924,14 +924,13 @@ static int decode_audio_block(AC3DecodeContext *s, i
201 - 300 of 691 matches
Mail list logo
