Old versions of sed do not support the -E option.
Signed-off-by: Lauri Kasanen
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index b02b4cc..51f1227 100755
--- a/configure
+++ b/configure
@@ -3722,7 +3722,7 @@ find_things_extern
On Fri, 16 Nov 2018 22:36:16 +0100
Carl Eugen Hoyos wrote:
> 2018-11-15 15:00 GMT+01:00, Lauri Kasanen :
> > Old versions of sed do not support the -E option.
>
> > -VERSION_SCRIPT_POSTPROCESS_CMD='tr " " "\n" | sed -n
> > /global:/,/l
-by: Lauri Kasanen
---
libswscale/ppc/swscale_altivec.c | 53
1 file changed, 53 insertions(+)
diff --git a/libswscale/ppc/swscale_altivec.c b/libswscale/ppc/swscale_altivec.c
index 2fb2337..8c6056d 100644
--- a/libswscale/ppc/swscale_altivec.c
+++ b
On Fri, 16 Nov 2018 22:09:25 +0100
Carl Eugen Hoyos wrote:
> (This is less important atm, but I believe all functions currently
> in libswscale/ppc compile and run fine on - old - 32bit be hardware
> as your new function does.
> My completely inexperienced suspicion is that the instruction that
On Sun, 6 Jan 2019 13:23:43 +0100
Carl Eugen Hoyos wrote:
> 2019-01-04 20:43 GMT+01:00, Lauri Kasanen :
> > +#ifdef __POWER8_VECTOR__
>
> If this is correct, I assume it fixes a bug in the current code
> and should be a separate patch, no?
>
> > case 16:
>
On Tue, 8 Jan 2019 11:08:04 +0200
Lauri Kasanen wrote:
> The existing code was in no released kernel that I can see. The corrected code
> was added in 3.9.
>
> Signed-off-by: Lauri Kasanen
> ---
> libavutil/ppc/cpu.c | 10 +-
> 1 file changed, 5 insertions(+),
format tested with an image to video conversion.
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 59
1 file changed, 59 insertions(+)
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 6462c11..70da6ae 100644
format tested with an image to video conversion.
Signed-off-by: Lauri Kasanen
---
v2: Copy-pasted rows were flipped.
libswscale/ppc/swscale_vsx.c | 59
1 file changed, 59 insertions(+)
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc
On Sun, 16 Dec 2018 00:22:00 +0100
Michael Niedermayer wrote:
> On Sat, Dec 15, 2018 at 06:32:31PM +0200, Lauri Kasanen wrote:
> > Tested on POWER8 LE. Testing on earlier ppc and/or BE appreciated.
> >
> > libswscale/ppc/sw
-by: Lauri Kasanen
---
Tested on POWER8 LE. Testing on earlier ppc and/or BE appreciated.
v2: Added #undef vzero, that define broke the build on older gcc. Thanks Michael
libswscale/ppc/swscale_altivec.c | 141 ++-
1 file changed, 139 insertions(+), 2 deletions
On Thu, 6 Dec 2018 21:47:18 +0100
Michael Niedermayer wrote:
> On Tue, Dec 04, 2018 at 02:27:22PM +0100, Michael Niedermayer wrote:
> > > > > On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote:
> > > > > > Also ping on "swscale/output:
On Mon, 17 Dec 2018 01:03:36 +0100
Carl Eugen Hoyos wrote:
> 2018-12-16 10:06 GMT+01:00, Lauri Kasanen :
> > This function wouldn't benefit from VSX instructions, so I put it
> > under altivec.
> >
> > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix
On Mon, 17 Dec 2018 14:52:49 +0100
Carl Eugen Hoyos wrote:
> >> Note that this function / this pix_fmt currently has no real use-case
> >> afaict.
> >
> > Is there a list of which pix fmts are useful? Of course I don't want to
> > waste both my and reviewers' time, if the format is considered
On Sun, 16 Dec 2018 11:06:53 +0200
Lauri Kasanen wrote:
> This function wouldn't benefit from VSX instructions, so I put it
> under altivec.
>
> ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> grayf32le \
> -f null -vframes 100 -v error -nostats
to video conversion.
Signed-off-by: Lauri Kasanen
---
Tested on POWER8 LE. Testing on earlier ppc and/or BE appreciated.
libswscale/ppc/swscale_altivec.c | 139 ++-
1 file changed, 137 insertions(+), 2 deletions(-)
diff --git a/libswscale/ppc/swscale_altivec.c
On Fri, 7 Dec 2018 13:50:12 +0100
Carl Eugen Hoyos wrote:
> > Carl Eugen Hoyos wrote:
> >> 2018-11-27 14:26 GMT+01:00, Lauri Kasanen :
> >> > Fate passes, each format tested with an image to video conversion.
> >> >
> >> > Depends o
On Tue, 4 Dec 2018 03:21:30 +0100
Michael Niedermayer wrote:
> On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote:
> > Also ping on "swscale/output: VSX-optimize
> > nbps yuv2plane1".
>
> This IIUC has not been tested on BE yet
>
> my ppc emula
On Thu, 6 Dec 2018 22:36:01 +0100
Carl Eugen Hoyos wrote:
> 2018-11-27 14:26 GMT+01:00, Lauri Kasanen :
> > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> > yuv420p9le \
> > -f null -vframes 100 -v error -nostats -
> >
> > Speedups
On Mon, 26 Nov 2018 14:24:15 +0200
Lauri Kasanen wrote:
> Passes fate on LE (with "lavc/jrevdct: Avoid an aliasing violation" applied).
> Can anyone test BE?
Ping.
- Lauri
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
On Fri, 30 Nov 2018 12:30:58 +0300
Michael Kostylev wrote:
>
> >> Passes fate on LE (with "lavc/jrevdct: Avoid an aliasing violation"
> >> applied). Can anyone test BE?
> >
> > Ping.
>
> FATE becomes green as much as possible, I haven't performed any benchmarking
> though.
Thanks for
On Fri, 23 Nov 2018 03:26:50 +0100
Michael Niedermayer wrote:
> On Wed, Nov 21, 2018 at 07:19:45PM +0200, Lauri Kasanen wrote:
> > On Wed, 21 Nov 2018 17:22:36 +0100
> > Michael Niedermayer wrote:
> > > the full fate tests must be run, many of these tests use swscale wit
On Fri, 23 Nov 2018 23:01:02 +0100
Michael Niedermayer wrote:
> On Fri, Nov 23, 2018 at 10:38:13AM +0200, Lauri Kasanen wrote:
> > I mean, if my patch adds no failures, is that enough to apply it?
>
> yes that and the tests failing should still fail the same way with the
&
Hi,
The lone power8 fate failing test seems like an aliasing issue.
I've isolated it into the attached standalone test case. Compiling it
with
gcc -std=c11 -maltivec -mabi=altivec -mvsx -O3 -fno-tree-vectorize
-o test test.c
reproduces on gcc 8.2.0, dropping the optimization level fixes it. This
On Sun, 25 Nov 2018 17:17:58 +0200
Lauri Kasanen wrote:
> This code would probably crash on systems where unaligned access is
> prohibited, I think the incoming block is just 16-bit aligned.
I see the block comes from aligned malloc, so scratch that part, it's at
least 128-bit aligned.
-
submit a patch moving them once this is reviewed.
>
> v2: Remove !BE check
> Signed-off-by: Lauri Kasanen
Ping. Seems not many ffmpeg devs interested in ppc.
- Lauri
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, 21 Nov 2018 13:21:58 +0100
Michael Niedermayer wrote:
> On Wed, Nov 21, 2018 at 10:12:48AM +0200, Lauri Kasanen wrote:
> > > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> > > yuv420p \
> > > -f null -vframes 100 -v error -nos
On Wed, 21 Nov 2018 17:22:36 +0100
Michael Niedermayer wrote:
> the full fate tests must be run, many of these tests use swscale without
> having "scale" in their name
> and yes on lower end hardware 20min and longer is possible
I get failures on the baseline, without my patch. What is the
On Mon, 26 Nov 2018 11:03:55 +0300
Michael Kostylev wrote:
>
> http://fate.xffm.org/?sort=arch
> /ppc
Yeah, mentioned in the commit message. Follow-up patch coming today.
- Lauri
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Mon, 26 Nov 2018 00:45:26 +0100
Carl Eugen Hoyos wrote:
> 2018-11-25 16:17 GMT+01:00, Lauri Kasanen :
> > Hi,
> >
> > The lone power8 fate failing test seems like an aliasing issue.
> > I've isolated it into the attached standalone test case. Compiling it
> >
yuv2plane1_12LE_vsx 11.0404
yuv2plane1_14BE_vsx 10.1763
yuv2plane1_14LE_vsx 11.2728
Fate passes, each format tested with an image to video conversion.
Depends on "swscale/ppc: Move VSX-using code to its own file". Only tested on
LE.
Signed-off-by: Lauri Kasanen
---
libs
On Sat, 17 Nov 2018 15:20:08 +0100
Carl Eugen Hoyos wrote:
> 2018-11-17 9:09 GMT+01:00, Lauri Kasanen :
> > Carl Eugen Hoyos wrote:
> >> (This is less important atm, but I believe all functions currently
> >> in libswscale/ppc compile and run fine on - old - 32bit b
Passes fate on LE (with "lavc/jrevdct: Avoid an aliasing violation" applied).
Can anyone test BE?
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/Makefile | 1 +
libswscale/ppc/swscale_altivec.c | 291 ++
libs
On Wed, 9 Jan 2019 22:26:25 +0100
Carl Eugen Hoyos wrote:
> > +#ifdef __GNUC__
> > +// GCC does not support vmuluwm yet. Bug open.
> > +__asm__("vmuluwm %0, %1, %2" : "=v"(vtmp) : "v"(vin32l),
> > "v"(vfilter[j]));
> > +vleft = vec_add(vleft, vtmp);
> > +
yuv420p16be
10463 UNITS in planarX, 130874 runs,198 skips
154405 UNITS in planarX, 131061 runs, 11 skips
Signed-off-by: Lauri Kasanen
---
v2: Separate macros so that yuv2plane1_16_vsx remains available for power7
v3: Remove accidental tabs, switch to HAVE_POWER8 from configure + runtime check
On Wed, 9 Jan 2019 21:55:30 +0100
Carl Eugen Hoyos wrote:
> 2019-01-08 10:08 GMT+01:00, Lauri Kasanen :
> > The existing code was in no released kernel that I can see. The corrected
> > code
> > was added in 3.9.
> >
> > Signed-off-by: Lauri Kasanen
>
On Thu, 10 Jan 2019 18:09:21 +0100
Carl Eugen Hoyos wrote:
> >> > -goto out;
> >>
> >> This seems like an unrelated change.
> >
> > It's necessary. HWCAP appears before HWCAP2 in the array, so if the
> > code jumps out in HWCAP, it never gets to checking the CAP2 bits like
> >
On Mon, 7 Jan 2019 13:44:56 +0100
Michael Niedermayer wrote:
> > The modern approaches, DCT, FFT, wavelets and such transforms, are all
> > likely too slow to decode.
>
> you said it can do mpeg1 and xvid, these are DCT based
> have you tried H.264 ? (i imagine that might with asm optimizations
On Mon, 7 Jan 2019 17:42:58 +0100
Michael Niedermayer wrote:
> > According to a 2010 comparison
> > https://keyj.emphy.de/video-encoder-comparison/
> > x264 constrained baseline (everything off) takes something like 30%
> > longer to decode vs xvid at the same rate. Probably more because that
>
yuv420p16be
10463 UNITS in planarX, 130874 runs,198 skips
154405 UNITS in planarX, 131061 runs, 11 skips
Signed-off-by: Lauri Kasanen
---
v2: Separate macros so that yuv2plane1_16_vsx remains available for power7
libswscale/ppc/swscale_ppc_template.c | 4 +-
libswscale/ppc/swscale_vsx.c
Hi,
If you were to design a video codec for a very low-end decoder, what
would it look like?
My target is MIPS 100MHz, and it should decode 320x240x30 in full speed
in software, with headroom for audio too. Seems all the codec research
in last 20 years has been more quality with more overhead,
yuv420p16be
10463 UNITS in planarX, 130874 runs,198 skips
154405 UNITS in planarX, 131061 runs, 11 skips
Signed-off-by: Lauri Kasanen
---
The existing VSX yuv2plane1 is also ifdefed out for POWER7, even though it
works there.
This is for cleanliness mainly, separating the macros would
On Fri, 11 Jan 2019 09:56:15 +0100
Michael Niedermayer wrote:
> > +#ifdef __GNUC__
> > +// GCC does not support vmuluwm yet. Bug open.
>
> this should probably be tested by configure similar to how other
> compiler limitations are tested
We can't really test for it, because there
On Sat, 12 Jan 2019 14:52:07 +0100
Michael Niedermayer wrote:
> On Sat, Jan 12, 2019 at 10:47:50AM +0200, Lauri Kasanen wrote:
> > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> > yuv420p16be \
> > -s 1920x1728 -f null -vframes 100 -v error -nostat
yuv420p16be
10463 UNITS in planarX, 130874 runs,198 skips
154405 UNITS in planarX, 131061 runs, 11 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_ppc_template.c | 4 +-
libswscale/ppc/swscale_vsx.c | 186 +-
2 files changed, 184
, 131072 runs, 0 skips
yuv420p16be
10634 UNITS in planarX, 131072 runs, 0 skips
150959 UNITS in planarX, 131072 runs, 0 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_ppc_template.c | 4 +-
libswscale/ppc/swscale_vsx.c | 186
On Mon, 7 Jan 2019 12:37:01 -0500
"Ronald S. Bultje" wrote:
> On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote:
> > "Ronald S. Bultje" wrote:
> >
> > > Have you considered vp8? It may sound weird but this is basically what
> > > vp8 was
On Sat, 12 Jan 2019 01:03:09 +0100
Michael Niedermayer wrote:
> On Fri, Jan 11, 2019 at 11:16:20AM +0200, Lauri Kasanen wrote:
> > On Fri, 11 Jan 2019 09:56:15 +0100
> > Michael Niedermayer wrote:
> >
> > > > +#ifdef __GNUC__
> > > > +
On Tue, 08 Jan 2019 21:32:30 +
Simon Nash wrote:
> I have encountered a problem with ffmpeg (a segmentation fault) that
> occurs only when running ffmpeg on the Marvell Armada 370 processor.
...
> When the 32-bit floating-point multiply instruction
> 0x0018a8f2 : vmla.f32
The existing code was in no released kernel that I can see. The corrected code
was added in 3.9.
Signed-off-by: Lauri Kasanen
---
libavutil/ppc/cpu.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
index 7bb7cd8..b022149
yuv420p16be
10463 UNITS in planarX, 130874 runs,198 skips
154405 UNITS in planarX, 131061 runs, 11 skips
Signed-off-by: Lauri Kasanen
---
v2: Separate macros so that yuv2plane1_16_vsx remains available for power7
v3: Remove accidental tabs, switch to HAVE_POWER8 from configure + runtime check
On Fri, 30 Nov 2018 14:05:26 +0200
Lauri Kasanen wrote:
> On Fri, 30 Nov 2018 12:30:58 +0300
> Michael Kostylev wrote:
> >
> > >> Passes fate on LE (with "lavc/jrevdct: Avoid an aliasing violation"
> > >> applied). Can anyone test BE?
> &g
On Mon, 14 Jan 2019 16:13:52 +0100
Michael Niedermayer wrote:
> On Sun, Jan 13, 2019 at 10:26:20AM +0200, Lauri Kasanen wrote:
> > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> > yuv420p16be \
> > -s 1920x1728 -f null -vframes 100 -v error -nostat
On Thu, 17 Jan 2019 09:40:09 +0200
Lauri Kasanen wrote:
> On Tue, 8 Jan 2019 11:08:04 +0200
> Lauri Kasanen wrote:
>
> > The existing code was in no released kernel that I can see. The corrected
> > code
> > was added in 3.9.
> >
> > Signed-off-by: La
Signed-off-by: Lauri Kasanen
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
Ref http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/239357.html
Requesting commit access so I don't have to constantly bug Michael.
diff --git a/MAINTAINERS b/MAINTAINERS
index bc2ae13..e3a80e9 100644
On Fri, 29 Mar 2019 17:00:38 +0300
Вячеслав wrote:
> ---
> libswscale/ppc/Makefile |3 +-
> libswscale/ppc/input_vsx.c| 3801
> +
> libswscale/swscale.c |3 +
> libswscale/swscale_internal.h |1 +
> 4 files changed, 3807
, 0 skips
8659 UNITS in yuv2packed1, 32767 runs, 1 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 291 +++
1 file changed, 291 insertions(+)
v2: HAVE_POWER8 from ifdef to if
Resending due to mail client troubles
diff
On Thu, 21 Mar 2019 01:20:21 +0100
Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch makes the only argument to the common probe() function const.
>
> Please comment, Carl Eugen
LGTM
- Lauri
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Tue, 26 Mar 2019 22:00:54 +0100
Michael Niedermayer wrote:
> On Tue, Mar 26, 2019 at 08:58:34AM +0200, Lauri Kasanen wrote:
> > In this function, the exact same clamping happens both in the if and
> > unconditionally.
> >
> > Signed-off-by: Lauri Kasanen
>
On Thu, 21 Mar 2019 09:54:17 +0200
Lauri Kasanen wrote:
> ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
> -s 1200x1440 -f null -vframes 100 -pix_fmt $i -nostats \
> -cpuflags 0 -v error -
>
> This uses 32-bit mul, so POWER8 only.
>
> The followi
In this function, the exact same clamping happens both in the if and
unconditionally.
Signed-off-by: Lauri Kasanen
---
libswscale/output.c | 10 --
1 file changed, 10 deletions(-)
v2: Remove the unconditional instead of the if'd clipping.
I'll leave changing the bit pattern to others
In this function, the exact same clamping happens both in the if and
unconditionally.
Signed-off-by: Lauri Kasanen
---
libswscale/output.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/libswscale/output.c b/libswscale/output.c
index d7c53e6..8441ddd 100644
--- a/libswscale
runs, 2 skips
yvyu422
117669 UNITS in yuv2packedX, 16384 runs, 0 skips
16271 UNITS in yuv2packedX, 16379 runs, 5 skips
uyvy422
117310 UNITS in yuv2packedX, 16384 runs, 0 skips
16226 UNITS in yuv2packedX, 16382 runs, 2 skips
Signed-off-by: Lauri Kasanen
skips
yvyu422
14516 UNITS in yuv2packed1, 32767 runs, 1 skips
943 UNITS in yuv2packed1, 32767 runs, 1 skips
uyvy422
14530 UNITS in yuv2packed1, 32767 runs, 1 skips
941 UNITS in yuv2packed1, 32766 runs, 2 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc
, 16383 runs, 1 skips
yvyu422
19438 UNITS in yuv2packed2, 16384 runs, 0 skips
3800 UNITS in yuv2packed2, 16380 runs, 4 skips
uyvy422
19128 UNITS in yuv2packed2, 16384 runs, 0 skips
3721 UNITS in yuv2packed2, 16380 runs, 4 skips
Signed-off-by: Lauri Kasanen
yvyu422
117669 UNITS in yuv2packedX, 16384 runs, 0 skips
16271 UNITS in yuv2packedX, 16379 runs, 5 skips
uyvy422
117310 UNITS in yuv2packedX, 16384 runs, 0 skips
16226 UNITS in yuv2packedX, 16382 runs, 2 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc
On Mon, 25 Mar 2019 11:17:38 +0100
Michael Niedermayer wrote:
> On Sun, Mar 24, 2019 at 01:04:51PM +0200, Lauri Kasanen wrote:
> > In this function, the exact same clamping happens both in the if and
> > unconditionally.
> >
> > Signed-off-by: Lauri Kasanen
>
in yuv2packed2, 16384 runs, 0 skips
This is a low speedup, but the x86 mmx version also gets only ~2x. The mmx
version
is also heavily inaccurate, while the vsx version has high accuracy.
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 188
UNITS in yuv2packed1, 32764 runs, 4 skips
This is a low speedup, but the x86 mmx version also gets only ~2x. The mmx
version
is also heavily inaccurate, while the vsx version has high accuracy.
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 425
On Sun, 24 Mar 2019 15:10:35 +0200
Lauri Kasanen wrote:
> ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
> -s 1200x1440 -f null -vframes 100 -pix_fmt $i -nostats \
> -cpuflags 0 -v error -
>
> 15.3x speedup:
>
> yuyv422
> 14513 UNITS
On Mon, 1 Apr 2019 09:07:48 +0300
slava wrote:
> Sorry for title. It is my first experience in git send-email. Can I make
> a benchmark with handwritten tests or have some standard tool in ffmeg?
> And will the benchmark on x86-64 be informative?
We have standard bench macros, START_TIMER and
in yuv2packed2, 16384 runs, 0 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 166 +++
1 file changed, 166 insertions(+)
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 0ac8cac..6ff8b62 100644
in yuv2packedX, 16384 runs, 0 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 160 +++
1 file changed, 160 insertions(+)
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 6ff8b62..e05f9ec 100644
On Mon, 8 Apr 2019 06:39:27 +0800
Steven Liu wrote:
> >+.long_name = NULL_IF_CONFIG_SMALL("Xunlie Video File"),
XV is a video output format, so please make the title something like
"flv: Add XV (Xunlie Video) support".
- Lauri
___
On Thu, 21 Feb 2019 20:34:29 +0100
Michael Niedermayer wrote:
> Improves speed from 5.4 to 4.2 seconds
> Fixes:
> 13149/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGM_fuzzer-5760833622114304
LGTM
Though, I really would expect the compiler to detect and optimize that.
I wonder if
On Mon, 18 Mar 2019 14:06:15 +0100
Carl Eugen Hoyos wrote:
>
> This looks good to me if you tested it and it reduces the number of warnings.
Tested on power8. With these two patches, swscale/ppc has no warnings.
- Lauri
___
ffmpeg-devel mailing list
On Mon, 18 Mar 2019 13:56:52 +0200
Lauri Kasanen wrote:
> Signed-off-by: Lauri Kasanen
> ---
> libswscale/ppc/swscale_ppc_template.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
Applying these t
On Wed, 20 Mar 2019 16:31:57 +0100
Carl Eugen Hoyos wrote:
> 2019-03-20 16:06 GMT+01:00, Lauri Kasanen :
> > On Wed, 20 Mar 2019 15:51:20 +0100
> > Carl Eugen Hoyos wrote:
> >
> >> 2019-03-20 15:06 GMT+01:00, Lauri Kasanen :
> >>
&
, 0 skips
8659 UNITS in yuv2packed1, 32767 runs, 1 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 291
+++ 1 file changed, 291 insertions(+)
v2: HAVE_POWER8 from ifdef to if
diff --git a/libswscale/ppc/swscale_vsx.c b
On Wed, 20 Mar 2019 14:41:27 +0100
Carl Eugen Hoyos wrote:
> 2019-03-20 13:37 GMT+01:00, Lauri Kasanen :
>
> > @@ -480,5 +722,66 @@ av_cold void ff_sws_init_swscale_vsx(SwsContext *c)
>
> Are there followup patches?
> Or why is the following hunk so convoluted?
I plan
, 0 skips
8659 UNITS in yuv2packed1, 32767 runs, 1 skips
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 303 +++
1 file changed, 303 insertions(+)
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index
On Mon, 18 Mar 2019 09:13:01 +0100
Moritz Barsnick wrote:
> On Sun, Mar 17, 2019 at 23:05:01 +0100, Paul B Mahol wrote:
> > Still wrong, You can decode images you linked just fine (albeit with
> > incorrect colors) with command:
> >
> > ffmpeg -subimage 1 -i IMAGE.dng rest of command.
>
>
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_ppc_template.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/libswscale/ppc/swscale_ppc_template.c
b/libswscale/ppc/swscale_ppc_template.c
index 3964a7a..aff2dd7 100644
--- a/libswscale/ppc
Signed-off-by: Lauri Kasanen
---
libswscale/ppc/swscale_altivec.c | 6 +++---
libswscale/ppc/swscale_ppc_template.c | 9 +
libswscale/ppc/swscale_vsx.c | 6 +++---
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/libswscale/ppc/swscale_altivec.c b/libswscale
On Sun, 13 Jan 2019 10:26:20 +0200
Lauri Kasanen wrote:
> ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
> yuv420p16be \
> -s 1920x1728 -f null -vframes 100 -v error -nostats -
>
> 9-14 bit funcs get about 6x speedup, 16-bit gets about 15x.
> Fate p
On Tue, 8 Jan 2019 11:08:04 +0200
Lauri Kasanen wrote:
> The existing code was in no released kernel that I can see. The corrected code
> was added in 3.9.
>
> Signed-off-by: Lauri Kasanen
> ---
> libavutil/ppc/cpu.c | 10 +-
> 1 file changed, 5 insertions(+), 5 d
On Fri, 5 Apr 2019 11:41:19 +0300
Lauri Kasanen wrote:
> ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 -sws_flags
> fast_bilinear \
> -s 1200x720 -f null -vframes 100 -pix_fmt $i -nostats \
> -cpuflags 0 -v error -
>
> 32-bit mul, power8 onl
On Mon, 1 Apr 2019 13:37:32 +0300
Lauri Kasanen wrote:
> ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
> -s 1200x720 -f null -vframes 100 -pix_fmt $i -nostats \
> -cpuflags 0 -v error -
>
> 32-bit mul, power8 only.
>
> ~6.
On Mon, 1 Apr 2019 13:13:59 +0300
Lauri Kasanen wrote:
> ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 -sws_flags area \
> -s 1200x720 -f null -vframes 100 -pix_fmt $i -nostats \
> -cpuflags 0 -v error -
>
> 32-bit mul, power8 only.
>
> ~
On Sun, 31 Mar 2019 17:18:47 +0300
Lauri Kasanen wrote:
> ./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 -sws_flags
> fast_bilinear \
> -s 1200x1440 -f null -vframes 100 -pix_fmt $i -nostats \
> -cpuflags 0 -v error -
>
> 32-bit mul, power8 only.
&g
On Thu, 18 Apr 2019 13:53:37 +0200
Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch silences a warning that is shown with some gcc versions.
It pokes my style sense to have different things in the sizeof() and
the var. How about uint32_t in both?
- Lauri
On Thu, 18 Apr 2019 15:07:03 +0200
Hendrik Leppkes wrote:
> On Thu, Apr 18, 2019 at 2:54 PM Lauri Kasanen wrote:
> >
> > On Thu, 18 Apr 2019 13:53:37 +0200
> > Carl Eugen Hoyos wrote:
> >
> > > Hi!
> > >
> > > Attached patch s
On Fri, 7 Jun 2019 08:38:35 -0700
Adrian Tong wrote:
> Hi
>
> I have a workload which spends a significant amount of time (~10%) in
> the yuv420_bgr24_mmxext function in FFMEPG.
>
> I looked at the assembly and profile and see MMX (64 bit) registers are
> used. I wonder whether we can have a
On Sat, 8 Jun 2019 06:51:51 -0700
Adrian Tong wrote:
> Hi Lauri.
>
> Thanks for the reply, any reason why this has not been implemented before ?
> it seems to me that this would be a pretty important/hot function.
Just the usual, nobody has had the interest. There are other places too
where the
On Mon, 10 Jun 2019 17:42:00 -0700
Adrian Tong wrote:
> I have been trying to implement yuv420_to_bgr24 using SSE2 instruction. I
> ran into the case where the output of C implemented yuv420_to_bgr24 has
> slightly different resulting bgr24 image from MMX implemented
> yuv420_to_bgr24. Is this
On Thu, 9 May 2019 22:59:12 -0700
Philip Langdale wrote:
> I don't think this is terribly useful, as the only thing out there that
> can even handle NV24 content is VDPAU and the only time you have to
> deal with it is when doing VDPAU OpenGL interop where swscale is
> irrelevant. In the other
On Fri, 10 May 2019 08:07:45 -0700
Philip Langdale wrote:
> On Fri, 10 May 2019 09:35:40 +0300
> Lauri Kasanen wrote:
>
> >
> > I'm having trouble making out what formats exactly isSemiPlanarYUV()
> > matches. Are you sure it's an equivalent check?
>
On Fri, 10 May 2019 10:08:57 -0700
Philip Langdale wrote:
> On 2019-05-10 08:12, Lauri Kasanen wrote:
> > On Fri, 10 May 2019 08:07:45 -0700
> > Philip Langdale wrote:
> >
> >> On Fri, 10 May 2019 09:35:40 +0300
> >> Lauri Kasanen wrote:
> >>
Copy-paste thinko in the title I see. Will remove the _vsx suffix from
the title.
- Lauri
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On Wed, 1 May 2019 22:57:47 +0200
Carl Eugen Hoyos wrote:
> 2019-04-28 3:18 GMT+02:00, Alexander Strasser :
>
> > What do you think about using awk instead of shell?
>
> Do we only use awk for --enable-random and the dependency
> files so far? Does configure also work without awk now and
> would
-by: Lauri Kasanen
---
libswscale/ppc/swscale_vsx.c | 64 +++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 2e20ab3..a82cf95 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale
1 - 100 of 113 matches
Mail list logo
