On 4/4/2017 10:53 PM, James Darnley wrote:
> Haswell:
> - 1.02x faster (405±0.7 vs. 397±0.8 decicycles) compared with mmxext
>
> Skylake-U:
> - 1.06x faster (498±1.8 vs. 470±1.3 decicycles) compared with mmxext
> ---
> libavcodec/x86/h264_idct.asm | 20
> libavcodec/x86/h2
On 4/4/2017 10:53 PM, James Darnley wrote:
> Haswell:
> - 1.11x faster (522±0.4 vs. 469±1.8 decicycles) compared with mmxext
>
> Skylake-U:
> - 1.21x faster (671±5.5 vs. 555±1.4 decicycles) compared with mmxext
Again, you should add an SSE2 version first, then an AVX one if it's
measurably fast
On 4/4/2017 10:53 PM, James Darnley wrote:
> ---
> libavcodec/x86/h264_idct.asm | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
> index c36fea5..878ff02 100644
> --- a/libavcodec/x86/h264_idct.asm
>
On 4/4/2017 11:12 PM, Michael Niedermayer wrote:
> On Tue, Apr 04, 2017 at 11:44:21AM +0200, Clément Bœsch wrote:
>> ffmpeg | branch: master | Clément Bœsch | Tue Apr 4
>> 11:44:45 2017 +0200| [4ea942f2ceaafbfed43933895bd0e8aad043ca44] | committer:
>> Clément Bœsch
>>
>> Merge commit '5f102a955
On Tue, Apr 04, 2017 at 11:44:21AM +0200, Clément Bœsch wrote:
> ffmpeg | branch: master | Clément Bœsch | Tue Apr 4
> 11:44:45 2017 +0200| [4ea942f2ceaafbfed43933895bd0e8aad043ca44] | committer:
> Clément Bœsch
>
> Merge commit '5f102a9559099429826e84758b8b5182244c52db'
>
> * commit '5f102a9
The labels get stripped leading to (slightly) nicer disassembly from
objdump.
---
libavcodec/x86/h264_idct.asm | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index 878ff02..dde40e9 100644
--
Haswell:
- 1.11x faster (522±0.4 vs. 469±1.8 decicycles) compared with mmxext
Skylake-U:
- 1.21x faster (671±5.5 vs. 555±1.4 decicycles) compared with mmxext
---
libavcodec/x86/h264_idct.asm | 33 -
libavcodec/x86/h264dsp_init.c | 3 +++
2 files changed, 35 ins
---
libavcodec/x86/h264_idct.asm | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index dde40e9..bc4dce4 100644
--- a/libavcodec/x86/h264_idct.asm
+++ b/libavcodec/x86/h264_idct.asm
@@ -87,10 +87,
---
libavcodec/x86/h264_idct.asm | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/x86/h264_idct.asm b/libavcodec/x86/h264_idct.asm
index c36fea5..878ff02 100644
--- a/libavcodec/x86/h264_idct.asm
+++ b/libavcodec/x86/h264_idct.asm
@@ -695,7 +695,7 @@ cglo
Haswell:
- 1.02x faster (405±0.7 vs. 397±0.8 decicycles) compared with mmxext
Skylake-U:
- 1.06x faster (498±1.8 vs. 470±1.3 decicycles) compared with mmxext
---
libavcodec/x86/h264_idct.asm | 20
libavcodec/x86/h264dsp_init.c | 2 ++
2 files changed, 22 insertions(+)
di
On Tue, Apr 04, 2017 at 06:13:30PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Apr 4, 2017 at 5:52 PM, Michael Niedermayer
> wrote:
>
> > On Tue, Apr 04, 2017 at 12:48:17PM -0400, Ronald S. Bultje wrote:
> > > These use the mmx IDCT, but sse2 put/add_pixels_clamped implementations.
> > > Th
After better testing I have decided to only submit these two functions. The
others did not provide a speedup better than the deviation in testing. Those
patches remain in the list archive should someone wish to try them.
James Darnley (5):
avcodec/h264: change RETs into REP_RETs where appropri
Fixes ticket #6285.
Signed-off-by: Marton Balint
---
libavfilter/vf_framerate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index b4a74f7..45fab25 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_
Resurrecting this patch.
On Thu, Sep 15, 2016 at 3:20 AM, Michael Niedermayer wrote:
> On Fri, Sep 09, 2016 at 05:26:03PM -0700, Brett Harrison wrote:
> > Here are the changes requested
> [...]
> > +static av_cold int parse_fontsize(AVFilterContext *ctx)
> > +{
> > +DrawTextContext *s = ctx-
Hi,
On Tue, Apr 4, 2017 at 5:52 PM, Michael Niedermayer
wrote:
> On Tue, Apr 04, 2017 at 12:48:17PM -0400, Ronald S. Bultje wrote:
> > These use the mmx IDCT, but sse2 put/add_pixels_clamped implementations.
> > This way we don't need to use the ff_put/add_pixels_clamped function
> > pointers.
>
On Tue, Apr 04, 2017 at 12:48:17PM -0400, Ronald S. Bultje wrote:
> These use the mmx IDCT, but sse2 put/add_pixels_clamped implementations.
> This way we don't need to use the ff_put/add_pixels_clamped function
> pointers.
> ---
> libavcodec/x86/idctdsp_init.c | 10 ++
> libavcodec/x86/si
Hi,
On Tue, Apr 4, 2017 at 5:18 PM, Michael Niedermayer
wrote:
> On Tue, Apr 04, 2017 at 12:48:13PM -0400, Ronald S. Bultje wrote:
> > Instead, hardcode the use of the _arm implementation of this function.
> > Since there's separate implementations of idct{,_put,_add} for neon,
> > this has no p
Instead, hardcode the use of the _arm implementation of add_pixels,
and use the C version for put_pixels (as no arm-optimized version
exists). Since there's separate implementations of idct{,_put,_add}
for neon, this has no practical impact on performance.
---
libavcodec/arm/idctdsp_init_arm.c | 8
On Tue, Apr 04, 2017 at 12:48:13PM -0400, Ronald S. Bultje wrote:
> Instead, hardcode the use of the _arm implementation of this function.
> Since there's separate implementations of idct{,_put,_add} for neon,
> this has no practical effect on performance.
> ---
> libavcodec/arm/idctdsp_init_arm.c
Hello,
Thanks for testing.
I will try to find a way to test on big endian.
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
On Tue, Apr 4, 2017 at 3:07 PM, James Almer wrote:
> On 4/4/2017 1:48 PM, Ronald S. Bultje wrote:
> > ---
> > libavcodec/x86/Makefile | 2 +-
> > libavcodec/x86/cavsdsp.c| 165 ++
> --
> > libavcodec/x86/cavsidct.asm | 165 ++
On 4/4/2017 1:48 PM, Ronald S. Bultje wrote:
> ---
> libavcodec/x86/Makefile | 2 +-
> libavcodec/x86/cavsdsp.c| 165
> ++--
> libavcodec/x86/cavsidct.asm | 165
>
> 3 files changed, 171 insertions(+),
Hi,
On Fri, Mar 31, 2017 at 07:23:28PM +0100, Rostislav Pehlivanov wrote:
> On 31 March 2017 at 18:11, Kieran Kunhya wrote:
>
> > On Fri, 31 Mar 2017 at 17:57 Rostislav Pehlivanov
> > wrote:
> >
> > > On 31 March 2017 at 16:36, Damien Riegel <
> > > damien.rie...@savoirfairelinux.com
> > > > wr
These use the mmx IDCT, but sse2 put/add_pixels_clamped implementations.
This way we don't need to use the ff_put/add_pixels_clamped function
pointers.
---
libavcodec/x86/idctdsp_init.c | 10 ++
libavcodec/x86/simple_idct.c | 15 +--
libavcodec/x86/simple_idct.h | 3 +++
3 f
---
libavcodec/x86/Makefile | 2 +-
libavcodec/x86/cavsdsp.c| 165 ++--
libavcodec/x86/cavsidct.asm | 165
3 files changed, 171 insertions(+), 161 deletions(-)
create mode 100644 libavcodec/x86/cavsidct
This removes the last use of the ff_put/add_pixels_clamped global
function pointers, and as such they are removed.
This patch has a negative effect on performance on MIPS, since there's
a SIMD-optimized put/add_pixels_clamped, but no xvid or jrev. From a
code maintenance point of view, that is pro
This makes using the function pointer ff_add_pixels_clamped() unnecessary,
since we always know what the best implementation is at compile-time.
---
libavcodec/x86/cavsdsp.c| 15 +-
libavcodec/x86/cavsidct.asm | 48 -
2 files changed, 61
Since there's separate SSE2 implementations of xvid_idct_put/add, this
patch has no practical impact on performance.
---
libavcodec/x86/xvididct_init.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/x86/xvididct_init.c b/libavcodec/x86/xvididct_init.c
index
Instead, hardcode the use of the _arm implementation of this function.
Since there's separate implementations of idct{,_put,_add} for neon,
this has no practical effect on performance.
---
libavcodec/arm/idctdsp_init_arm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
On Tue, 4 Apr 2017 12:34:56 -0300
James Almer wrote:
> On 4/4/2017 2:45 AM, wm4 wrote:
> > Can do audio decoding, audio encoding, video decoding, video encoding,
> > video HW encoding. I also had video HW decoding, but removed it for now,
> > as thw hwframes integration wasn't very sane.
> >
> >
On 4/4/2017 2:45 AM, wm4 wrote:
> Can do audio decoding, audio encoding, video decoding, video encoding,
> video HW encoding. I also had video HW decoding, but removed it for now,
> as thw hwframes integration wasn't very sane.
>
> Some of the MS codecs aren't well tested, and might not work prope
On Tue, Apr 04, 2017 at 05:14:30PM +0200, wm4 wrote:
> On Tue, 4 Apr 2017 17:01:15 +0200
> Michael Niedermayer wrote:
>
> > On Mon, Apr 03, 2017 at 07:50:07PM +, Ben Chang wrote:
> > > Hi,
> > >
> > > This patch adds copy of HDR VUI info from decode ctx to encode ctx.
> > > Currently, info
On Tue, 4 Apr 2017 17:01:15 +0200
Michael Niedermayer wrote:
> On Mon, Apr 03, 2017 at 07:50:07PM +, Ben Chang wrote:
> > Hi,
> >
> > This patch adds copy of HDR VUI info from decode ctx to encode ctx.
> > Currently, information under colour_description_present_flag (eg. colour
> > primar
On Mon, Apr 03, 2017 at 07:50:07PM +, Ben Chang wrote:
> Hi,
>
> This patch adds copy of HDR VUI info from decode ctx to encode ctx.
> Currently, information under colour_description_present_flag (eg. colour
> primaries, transfer_characteristics, matrix_coeffs) do not get copied to
> outpu
On Tue, 4 Apr 2017 16:30:58 +0200
Carl Eugen Hoyos wrote:
> 2017-04-04 16:04 GMT+02:00 wm4 :
> > On Tue, 4 Apr 2017 15:44:29 +0200
> > Carl Eugen Hoyos wrote:
> >
> >> 2017-04-04 12:45 GMT+02:00 wm4 :
> >> > On Tue, 4 Apr 2017 12:43:14 +0200
> >> > Carl Eugen Hoyos wrote:
> >> >
> >> >> 2
2017-04-04 16:04 GMT+02:00 wm4 :
> On Tue, 4 Apr 2017 15:44:29 +0200
> Carl Eugen Hoyos wrote:
>
>> 2017-04-04 12:45 GMT+02:00 wm4 :
>> > On Tue, 4 Apr 2017 12:43:14 +0200
>> > Carl Eugen Hoyos wrote:
>> >
>> >> 2017-04-04 12:41 GMT+02:00 wm4 :
>> >> > On Tue, 4 Apr 2017 12:09:23 +0200
>> >> > Ca
This fixes a proble where ffmpeg would cause crash to do a seek when the
network disconnect.
The log like this:
01-01 10:53:03.441 6580 6580 F DEBUG : backtrace:
01-01 10:53:03.441 6580 6580 F DEBUG : #00 pc 0002942e
/system/lib/libavformat.so (ffurl_write+9)
Signed-off-by: tiejun.p
On Tue, Apr 04, 2017 at 03:59:28PM +0200, Michael Niedermayer wrote:
> On Tue, Apr 04, 2017 at 11:00:23AM +0100, Rostislav Pehlivanov wrote:
> > On 4 April 2017 at 02:54, Michael Niedermayer
> > wrote:
> >
> > > On Mon, Apr 03, 2017 at 10:31:27PM +0100, Rostislav Pehlivanov wrote:
> > > > As it g
Hi,
On Tue, Apr 4, 2017 at 10:07 AM, Michael Niedermayer wrote:
> On Tue, Apr 04, 2017 at 09:09:36AM -0400, Ronald S. Bultje wrote:
> > This fixes the following tsan warnings when running fate-dnxhr-parse:
> >
> > WARNING: ThreadSanitizer: data race (pid=29917)
> > Write of size 8 at 0x025
On Tue, Apr 04, 2017 at 09:09:36AM -0400, Ronald S. Bultje wrote:
> This fixes the following tsan warnings when running fate-dnxhr-parse:
>
> WARNING: ThreadSanitizer: data race (pid=29917)
> Write of size 8 at 0x025b12d8 by thread T2 (mutexes: write M1543):
> #0 ff_idctdsp_init src/liba
On Tue, 4 Apr 2017 15:44:29 +0200
Carl Eugen Hoyos wrote:
> 2017-04-04 12:45 GMT+02:00 wm4 :
> > On Tue, 4 Apr 2017 12:43:14 +0200
> > Carl Eugen Hoyos wrote:
> >
> >> 2017-04-04 12:41 GMT+02:00 wm4 :
> >> > On Tue, 4 Apr 2017 12:09:23 +0200
> >> > Carl Eugen Hoyos wrote:
> >> >
> >> >> 2
On Tue, Apr 4, 2017 at 3:44 PM, Carl Eugen Hoyos wrote:
> 2017-04-04 12:45 GMT+02:00 wm4 :
>> On Tue, 4 Apr 2017 12:43:14 +0200
>> Carl Eugen Hoyos wrote:
>>
>>> 2017-04-04 12:41 GMT+02:00 wm4 :
>>> > On Tue, 4 Apr 2017 12:09:23 +0200
>>> > Carl Eugen Hoyos wrote:
>>> >
>>> >> 2017-04-04 7:45 GM
On Tue, Apr 04, 2017 at 11:00:23AM +0100, Rostislav Pehlivanov wrote:
> On 4 April 2017 at 02:54, Michael Niedermayer
> wrote:
>
> > On Mon, Apr 03, 2017 at 10:31:27PM +0100, Rostislav Pehlivanov wrote:
> > > As it gives excellent encoding gains at an insignificant speed increase
> > > and passes
Hi,
On Tue, Apr 4, 2017 at 9:09 AM, Ronald S. Bultje wrote:
> This fixes the following tsan warning:
>
> WARNING: ThreadSanitizer: data race (pid=95987)
> Write of size 4 at 0x7d504278 by main thread:
> #0 get_frame_defaults frame.c:117 (ffmpeg:x86_64+0x1016c5b18)
> [..]
> Previous w
2017-04-04 12:45 GMT+02:00 wm4 :
> On Tue, 4 Apr 2017 12:43:14 +0200
> Carl Eugen Hoyos wrote:
>
>> 2017-04-04 12:41 GMT+02:00 wm4 :
>> > On Tue, 4 Apr 2017 12:09:23 +0200
>> > Carl Eugen Hoyos wrote:
>> >
>> >> 2017-04-04 7:45 GMT+02:00 wm4 :
>> >>
>> >> > + --enable-mf enable deco
This fixes the following tsan warning:
WARNING: ThreadSanitizer: data race (pid=95987)
Write of size 4 at 0x7d504278 by main thread:
#0 get_frame_defaults frame.c:117 (ffmpeg:x86_64+0x1016c5b18)
[..]
Previous write of size 4 at 0x7d504278 by thread T2:
[failed to restore the st
This fixes the following tsan warnings when running fate-dnxhr-parse:
WARNING: ThreadSanitizer: data race (pid=29917)
Write of size 8 at 0x025b12d8 by thread T2 (mutexes: write M1543):
#0 ff_idctdsp_init src/libavcodec/idctdsp.c:313 (ffmpeg+0x0044b68e)
[..]
Previous write of size 8
Hi,
On Sun, Apr 2, 2017 at 6:32 PM, Kyle Swanson wrote:
> Signed-off-by: Kyle Swanson
> ---
> libavfilter/af_loudnorm.c | 58 +++---
> -
> 1 file changed, 34 insertions(+), 24 deletions(-)
>
> diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudn
On Tue, Apr 4, 2017 at 8:05 AM, Shivraj Patil
wrote:
> Hi,
>
> > diff --git a/libavcodec/hevcpred.h b/libavcodec/hevcpred.h
> > [..]
> > @@ -26,6 +26,8 @@
> > #include
> > #include
> >
> > +#include "get_bits.h"
> > +
>
hevcpred does not depend on get_bits.h and does not use any symbols
(get
Hi,
Above patch fixes the mips build bug.
Shivraj.
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
Michael Niedermayer
Sent: 31 March 2017 15:22
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] Build fix for MI
Hi,
On Tue, Apr 4, 2017 at 6:33 AM, Carl Eugen Hoyos wrote:
> Hi!
>
> I believe attached patch makes FFmpeg a little more consistent with itself.
Looks like it, yes.
This patch does expose a bug we've discussed before though. Since the
return value of handle_jpeg() is or()'ed into src_range a
On Tue, 4 Apr 2017 12:43:14 +0200
Carl Eugen Hoyos wrote:
> 2017-04-04 12:41 GMT+02:00 wm4 :
> > On Tue, 4 Apr 2017 12:09:23 +0200
> > Carl Eugen Hoyos wrote:
> >
> >> 2017-04-04 7:45 GMT+02:00 wm4 :
> >>
> >> > + --enable-mf enable decoding via MediaFoundation [no]
> >>
> >>
2017-04-04 12:41 GMT+02:00 wm4 :
> On Tue, 4 Apr 2017 12:09:23 +0200
> Carl Eugen Hoyos wrote:
>
>> 2017-04-04 7:45 GMT+02:00 wm4 :
>>
>> > + --enable-mf enable decoding via MediaFoundation [no]
>>
>> Why is it not autodetected?
>
> Do we want that?
Would autodetection break FFmpeg
On Tue, 4 Apr 2017 12:09:23 +0200
Carl Eugen Hoyos wrote:
> 2017-04-04 7:45 GMT+02:00 wm4 :
>
> > + --enable-mf enable decoding via MediaFoundation [no]
>
> Why is it not autodetected?
Do we want that?
___
ffmpeg-devel mailing list
ff
Hi!
I believe attached patch makes FFmpeg a little more consistent with itself.
Please comment, Carl Eugen
From 5e1239a6bf3d97b360a447bd88da2e0477ffc0c9 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 4 Apr 2017 12:24:41 +0200
Subject: [PATCH] lsws/utils: Make gray10 and gray12 full-s
On Mon, Apr 03, 2017 at 04:33:57PM +0200, Matthieu Bouron wrote:
> ---
> doc/examples/extract_mvs.c | 56
> +++---
> 1 file changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/doc/examples/extract_mvs.c b/doc/examples/extract_mvs.c
> index 552a7334
2017-04-04 7:45 GMT+02:00 wm4 :
> + --enable-mf enable decoding via MediaFoundation [no]
Why is it not autodetected?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Tue, Apr 04, 2017 at 06:04:37AM +0200, wm4 wrote:
> On Mon, 3 Apr 2017 19:50:07 +
> Ben Chang wrote:
>
> > From c8092bc538ba7ae32357ca166e67809eb3705f60 Mon Sep 17 00:00:00 2001
> > From: Ben Chang
> > Date: Mon, 27 Mar 2017 17:00:19 -0700
> > Subject: [PATCH] Allow transfer of HDR-requir
On 4 April 2017 at 02:54, Michael Niedermayer
wrote:
> On Mon, Apr 03, 2017 at 10:31:27PM +0100, Rostislav Pehlivanov wrote:
> > As it gives excellent encoding gains at an insignificant speed increase
> > and passes fate without problems, it should now be safe to enable by
> > default.
>
> Still
Doesn't work yet with slice threading and won't work with AMV.
---
libavcodec/mpegvideo_enc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 71a858fc72..db241c82f0 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvid
On Tue, Apr 04, 2017 at 09:31:14AM +0200, wm4 wrote:
> On Tue, 4 Apr 2017 09:21:00 +0200
> Matthieu Bouron wrote:
>
> > ---
> > libavcodec/mediacodecdec.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
>
> Both patches LGTM.
Applied. Thanks for the review.
Matthieu
On Tue, 4 Apr 2017 09:21:00 +0200
Matthieu Bouron wrote:
> ---
> libavcodec/mediacodecdec.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
Both patches LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.o
---
libavcodec/mediacodecdec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 4cbec09acd..857e7a5fed 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -552,7 +552,7 @@ AVCodec ff
---
libavcodec/mediacodecdec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 79a51ec684..4cbec09acd 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -552,7 +552,7 @@ AVCodec ff
Le quartidi 14 germinal, an CCXXV, Lou Logan a écrit :
> On Mon, Apr 3, 2017, at 02:14 AM, Nicolas George wrote:
> > Signed-off-by: Nicolas George
> > ---
> > doc/muxers.texi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> LGTM
Thanks, pushed.
Regards,
--
Nicolas George
sig
65 matches
Mail list logo
