Signed-off-by: Mateusz Brzostek
---
libavcodec/rscc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/rscc.c b/libavcodec/rscc.c
index e4b51973d8..7d4e842cd3 100644
--- a/libavcodec/rscc.c
+++ b/libavcodec/rscc.c
@@ -64,7 +64,7 @@ typedef struct RsccContext
W dniu 24.10.2017 o 10:02, Mateusz pisze:
> The Bayer matrix 8x8 used in DITHER_COPY macro is table dithers[5].
> Remaining dithers[] matrixes are generated from this matrix by
> downshift or upshift.
>
> This patch fixes dithers[6] and dithers[7] matrixes -- they were
&g
Please apply patch
https://patches.videolan.org/patch/18630/
to x265 and recheck.
Mateusz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
we have included windows.h in much more files and we should
avoid conflicts with defines/function declarations.
Signed-off-by: Mateusz Brzostek
---
libavcodec/jpegls.h | 4
libavcodec/mss2.c| 6 +++---
l
W dniu 03.12.2017 o 22:26, Michael Niedermayer pisze:
> On Sat, Dec 02, 2017 at 09:50:26PM +0100, Mateusz wrote:
>> After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
>> we have included windows.h in much more files and we should
>> avoid
After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
we have included windows.h in much more files and we should
avoid conflicts with defines/function declarations.
Signed-off-by: Mateusz Brzostek
---
libavcodec/jpegls.h | 4
libavcodec/mss2.c| 6 +++---
l
W dniu 04.12.2017 o 15:02, Derek Buitenhuis pisze:
> On 12/4/2017 8:03 AM, Mateusz wrote:
>> After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
>> we have included windows.h in much more files and we should
>> avoid conflicts with defines/function de
EADSAFE || !codec->init)
return 0;
Mateusz
W dniu 04.12.2017 o 20:27, Mateusz pisze:
> W dniu 04.12.2017 o 15:02, Derek Buitenhuis pisze:
>> On 12/4/2017 8:03 AM, Mateusz wrote:
>>> After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
W dniu 05.12.2017 o 15:20, James Almer pisze:
> On 12/4/2017 8:31 PM, Mateusz wrote:
>> After some tests:
>> 1) #undef far
>> after #include is wrong -- in oleauto.h is declaration
>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>> and 'FA
W dniu 05.12.2017 o 17:44, James Almer pisze:
> On 12/5/2017 1:40 PM, Mateusz wrote:
>> W dniu 05.12.2017 o 15:20, James Almer pisze:
>>> On 12/4/2017 8:31 PM, Mateusz wrote:
>>>> After some tests:
>>>> 1) #undef far
>>>> after #include is
W dniu 05.12.2017 o 12:12, Hendrik Leppkes pisze:
> On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
>> After some tests:
>> 1) #undef far
>> after #include is wrong -- in oleauto.h is declaration
>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>
riables in atomic_compare_exchange* macro.
Signed-off-by: Mateusz Brzostek
---
libavcodec/jpegls.h | 2 ++
libavcodec/mjpegdec.h | 2 ++
libavcodec/mss2.c | 6 +++---
libavcodec/utils.c| 12
libavformat/mxfenc.c | 2 +-
5 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/
W dniu 07.12.2017 o 10:42, Hendrik Leppkes pisze:
> On Thu, Dec 7, 2017 at 2:02 AM, Mateusz wrote:
>> After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
>> we have included windows.h in much more files and we should
>> avoid conflicts with defines/
After commit 3701d49 'error_resilience: remove avpriv_atomic usage'
we have included windows.h in much more files and we should
avoid conflicts with defines/function declarations.
Signed-off-by: Mateusz Brzostek
---
libavcodec/jpegls.h | 2 ++
libavcodec/mjpegdec.h | 2 ++
libavco
W dniu 07.12.2017 o 22:58, Hendrik Leppkes pisze:
> Am 07.12.2017 20:40 schrieb "Mateusz" :
>
> W dniu 07.12.2017 o 10:42, Hendrik Leppkes pisze:
>> On Thu, Dec 7, 2017 at 2:02 AM, Mateusz wrote:
>>> After commit 3701d49 'error_resilience: remove av
>flip_line[plane](inrow, outrow, width);
and now at part from tests/checkasm/vf_hflip.c:
call_ref(src, dst_ref, w);
call_new(src, dst_new, w);
For me there is no "src + (width - 1) * step" in tests/checkasm/vf_hflip.c
You pass start of the src buffer but you shou
New patch in attach.
Now it is OK in my system (mingw 32/64-bit, VS 2017 64-bit). Thanks!
Mateusz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
W dniu 11.12.2017 o 00:51, Mateusz pisze:
> W dniu 10.12.2017 o 21:13, Martin Vignali pisze:
>>>
>>> For me there is no "src + (width - 1) * step" in tests/checkasm/vf_hflip.c
>>>
>>> You pass start of the src buffer but you should pass end of the
W dniu 11.12.2017 o 11:00, Martin Vignali pisze:
> 2017-12-11 10:49 GMT+01:00 Mateusz :
>
>> W dniu 11.12.2017 o 00:51, Mateusz pisze:
>>> W dniu 10.12.2017 o 21:13, Martin Vignali pisze:
>>>>>
>>>>> For me there is no "src + (width - 1)
;
> New patch in attach, with an add in fate/checkasm.mak
My bad, sorry for misinformation. The old patch that broke fate was in fate,
next wasn't and I checked only end of fate tests (I wrongly assume that it
passes fate) but 32-bit VS 2017 hangs at 'fate-api-png-codec-param' an
Signed-off-by: Mateusz Brzostek
---
libavfilter/vf_overlay.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index a7d3906016..aa5835ae3a 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter
If ffmpeg reduces bit-depth to 8-bit or more, it uses DITHER_COPY macro.
The problem is DITHER_COPY macro make images darker (on all planes).
In x265 project there is issue #365 which is caused by this DITHER_COPY bug.
I think it is time to fix -- there are more and more high bit-depth sources.
P
W dniu 2017-09-05 o 15:40, Michael Niedermayer pisze:
> On Mon, Sep 04, 2017 at 09:33:34AM +0200, Mateusz wrote:
>> If ffmpeg reduces bit-depth to 8-bit or more, it uses DITHER_COPY macro.
>> The problem is DITHER_COPY macro make images darker (on all planes).
>>
>> In
W dniu 2017-09-05 o 23:37, Michael Niedermayer pisze:
> On Tue, Sep 05, 2017 at 04:42:06PM +0200, Mateusz wrote:
>> W dniu 2017-09-05 o 15:40, Michael Niedermayer pisze:
>>> On Mon, Sep 04, 2017 at 09:33:34AM +0200, Mateusz wrote:
>>>> If ffmpeg reduces bit-d
W dniu 2017-09-06 o 02:07, Michael Niedermayer pisze:
> On Wed, Sep 06, 2017 at 01:25:45AM +0200, Mateusz wrote:
>> W dniu 2017-09-05 o 23:37, Michael Niedermayer pisze:
>>> On Tue, Sep 05, 2017 at 04:42:06PM +0200, Mateusz wrote:
>>>> W dniu 2017-09-05 o 15:40, Micha
W dniu 2017-09-06 o 09:27, Mateusz pisze:
> W dniu 2017-09-06 o 02:07, Michael Niedermayer pisze:
>> On Wed, Sep 06, 2017 at 01:25:45AM +0200, Mateusz wrote:
>>> W dniu 2017-09-05 o 23:37, Michael Niedermayer pisze:
>>>> On Tue, Sep 05, 2017 at 04:42:06PM +0200, Mateu
kes code faster (I don't see any Intel Intrinsics in ffmpeg so it's
probably for testing only).
Please review.
Mateusz
From a52417a3817ac774eb364bbef20c954a3d278d45 Mon Sep 17 00:00:00 2001
From: Mateusz
Date: Fri, 22 Sep 2017 01:22:59 +0200
Subject: [PATCH] swscale_unscaled
lower than current code but
with better quality)
Please review/test.
Mateusz
From 8eaa76fc82550f62f1a22e9388a51dc61c031a2c Mon Sep 17 00:00:00 2001
From: Mateusz
Date: Fri, 22 Sep 2017 14:54:53 +0200
Subject: [PATCH] swscale_unscaled: fix and speed up DITHER_COPY macro for x86
with SSE2
---
W dniu 2017-09-22 o 17:47, James Almer pisze:
> On 9/22/2017 12:23 PM, Mateusz wrote:
>> New version of the patch -- now it uses the same logic independent of the
>> target bitdepth.
>>
>> For x86_64 it is much faster than current code (with perfect quality), for
>
W dniu 2017-09-23 o 17:01, Michael Niedermayer pisze:
> On Fri, Sep 22, 2017 at 02:10:01AM +0200, Mateusz wrote:
>> To reduce bit depth in planar YUV or gray pixel formats ffmpeg uses
>> DITHER_COPY macro.
>> Now it makes images greener and with visible dither pattern.
>
W dniu 2017-09-25 o 01:42, Carl Eugen Hoyos pisze:
> 2017-09-23 19:18 GMT+02:00 Mateusz :
>
>> In reality -- current version of DITHER_COPY mess
>> up the average color tone.
>
> You could explain how we can reproduce this.
Please take any video with colors that you
W dniu 2017-09-25 o 22:53, Carl Eugen Hoyos pisze:
> 2017-09-23 19:18 GMT+02:00 Mateusz :
>> W dniu 2017-09-23 o 17:01, Michael Niedermayer pisze:
>>> On Fri, Sep 22, 2017 at 02:10:01AM +0200, Mateusz wrote:
>>>> To reduce bit depth in planar YUV or gray pixel format
W dniu 2017-09-26 o 13:31, Carl Eugen Hoyos pisze:
> 2017-09-26 1:33 GMT+02:00 Mateusz :
>
>> I've sent C code patch 2017-09-06 (and nothing) so I thought that the
>> problem is with speed. For simplicity I've attached this patch.
>
> You could (wait a day o
libraries link correctly to my application.
>>
> This would break the workflow for everyone that is currently working
> with the current names, however.
For gcc it breaks nothing (it still makes lib...a files), for msvc it is
improvement.
Is there any person happy with lib...a names for
Fixed DITHER_COPY macro (only C code), updated FATE tests.
PSNR in tests that needed update goes from 50 to 999.99 -- the quality is there.
Please review.
Mateusz
From d870ba10aa4b3520fc30215fbbd57565faa13df4 Mon Sep 17 00:00:00 2001
From: Mateusz
Date: Fri, 6 Oct 2017 16:49:54 +0200
Subject
Lately ffmpeg supports gray9/10/12 pixel formats.
This patch adds gray9/10/12 pixel formats to y4m.
It also moves gray16 to 'strict -1' section.
Please review.
Mateusz
From f2b31ef66931e02a355e3140d47b17f0d307dec7 Mon Sep 17 00:00:00 2001
From: Mateusz
Date: Sat, 7 Oct 2017 19:0
W dniu 2017-10-06 o 17:33, Mateusz pisze:
> Fixed DITHER_COPY macro (only C code), updated FATE tests.
>
> PSNR in tests that needed update goes from 50 to 999.99 -- the quality is
> there.
Ping.
___
ffmpeg-devel mailing list
ffmpeg-deve
W dniu 2017-10-20 o 20:07, Jan Ekstrom pisze:
> On Fri, Oct 20, 2017 at 10:26 AM, Mateusz wrote:
>> W dniu 2017-10-06 o 17:33, Mateusz pisze:
>>> Fixed DITHER_COPY macro (only C code), updated FATE tests.
>>>
>>> PSNR in tests that needed update goes from 50 to
The Bayer matrix 8x8 used in DITHER_COPY macro is table dithers[5].
Remaining dithers[] matrixes are generated from this matrix by
downshift or upshift.
This patch fixes dithers[6] and dithers[7] matrixes -- they were
too dark.
Signed-off-by: Mateusz Brzostek
---
libswscale/swscale_unscaled.c
This patch uses dithering in DITHER_COPY macro only if
it was not used option '-sws_dither none'.
With option '-sws_dither none' it uses downshift.
For human eye dithering is OK, for video codecs not necessarily.
If user don't want to use dithering, we should respect that
W dniu 2017-10-07 o 21:41, Paul B Mahol pisze:
> On 10/7/17, Mateusz wrote:
>> Lately ffmpeg supports gray9/10/12 pixel formats.
>>
>> This patch adds gray9/10/12 pixel formats to y4m.
>>
>> It also moves gray16 to 'strict -1' section.
>>
>
W dniu 24.10.2017 o 10:02, Mateusz pisze:
> The Bayer matrix 8x8 used in DITHER_COPY macro is table dithers[5].
> Remaining dithers[] matrixes are generated from this matrix by
> downshift or upshift.
>
> This patch fixes dithers[6] and dithers[7] matrixes -- they were
> too dar
W dniu 2017-03-16 o 19:17, Michael Niedermayer pisze:
> On Wed, Mar 15, 2017 at 10:52:29PM +0100, Mateusz Brzostek wrote:
>> Hello!
>>
>> There are 3 problems with DITHER_COPY macro in libswscale/swscale_unscaled.c:
>> 1) there is overflow in dithering from 12-
In previous patch there was missing braces {} in for (; j < length; j++) loop.
Please ignore that patch.
New patch with braces and without FFMIN macro.
Mateusz
W dniu 2017-03-18 o 21:28, Mateusz Brzostek pisze:
> W dniu 2017-03-16 o 19:17, Michael Niedermayer pisze:
>> On Wed, Mar
W dniu 2017-03-20 o 10:00, Carl Eugen Hoyos pisze:
> 2017-03-15 22:52 GMT+01:00 Mateusz Brzostek :
>> Hello!
>>
>> There are 3 problems with DITHER_COPY macro in libswscale/swscale_unscaled.c:
>> 1) there is overflow in dithering from 12-bit to 10-bit (output value &
c_depth-dst_depth-1][i&7];\
For bugs 2) and 3) it is needed formula that do not make images darker (in
attachment). So please review.
Mateusz
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index ba3d688..429c98c 100644
--- a/libswscale/swscale_unscaled.c
+++ b
W dniu 2017-03-16 o 19:17, Michael Niedermayer pisze:
> On Wed, Mar 15, 2017 at 10:52:29PM +0100, Mateusz Brzostek wrote:
>> Hello!
>>
>> There are 3 problems with DITHER_COPY macro in libswscale/swscale_unscaled.c:
>> 1) there is overflow in dithering from 12-
47 matches
Mail list logo
