On 2015-07-15 00:06, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 35 ++
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_deband.c | 312
> +++
> 4 files changed, 349
On 2015-07-17 02:01, Emanuel Berg wrote:
> This zsh, using ffmpeg and normalize-audio, seems to
> do it. But it is slow. Remember normalize-audio is
> lightning fast so time is spent getting and putting
> together the audio with the movie. Perhaps it can be
> optimized somehow - do tell, if you kno
On 2015-07-09 18:55, Paul B Mahol wrote:
> +{ "n", "enable channels coupling", OFFSET(channels_coupled),
> AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, FLAGS },
This should be "enable channel coupling"
> +static const double s_pi =
> 3.14159265358979323846264338327950288419716939937510582097494459230
On 2015-07-09 18:55, Paul B Mahol wrote:
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 3fce874..74c408a 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -1520,6 +1520,164 @@ Optional. It should have a value much less than 1
> (e.g. 0.05 or 0.02) and is
> used to prevent
On 2015-07-15 21:48, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_convolution.c | 331
> +++
> 3 files changed, 333 insertions(+)
> create mode 100
On 2015-07-17 12:55, Paul B Mahol wrote:
> On 7/17/15, James Darnley wrote:
>> On 2015-07-09 18:55, Paul B Mahol wrote:
>>> +{ "n", "enable channels coupling", OFFSET(channels_coupled),
>>> AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, FLAGS },
>>
&
On 2015-10-10 00:43, Ganesh Ajjanagadde wrote:
> During a build, a lot of *.o-hash files are created - had not noticed
> this as they are usually dumped in tmpfs on Linux. However, they
> sometimes are present during a long build in the project directory, making it
> annoying to commit while the pr
On 2015-10-09 14:46, Nicolas George wrote:
> Le quartidi 4 vendémiaire, an CCXXIV, James Darnley a écrit :
>> I can. You should find it attached to this email. I cleaned it up and
>> put two test cases of data into the file. You will need Lua and the
>> Lua-iconv mod
On 2015-10-10 23:06, Ganesh Ajjanagadde wrote:
> ...
Is the greatest common denominator (yes, I had to look that up) actually
used anywhere that is slow and needs to be fast?
All the uses of 'av_gcd' found by grep appear be dealing with timing. I
see framerate, timebase, scale. I do see uses in
On 2015-10-21 12:18, wm4 wrote:
> with size_t/ptrdiff_t
> being 128 bit, and a new "long long long int" type (I swear, they will
> do it, even if that type name looks horrible).
Please no! Just require a C99 style uint128_t/int128_t type.
signature.asc
Description: OpenPGP digital signature
__
On 2015-10-21 14:44, Clément Bœsch wrote:
> On Wed, Oct 21, 2015 at 06:00:21AM -0400, Ganesh Ajjanagadde wrote:
> [...]
>> why don't you spend 5 minutes trying to outline to beginners like me
>> what is "actually important" in your view?
>>
>
> According to the first 100 answers of the survey, the
On 2015-10-23 13:54, Hendrik Leppkes wrote:
> The only reason the combination of frame threads and HWAccel was
> considered useful is to allow a seamless fallback to multi-threaded
> software decoding if the HWAccel is not available, however the issues
> outlined above far outweight this.
On 2015-11-13 15:23, Ganesh Ajjanagadde wrote:
> diff --git a/libavutil/version.h b/libavutil/version.h
> index 909f9a6..ea10ff0 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -56,8 +56,8 @@
> */
>
> #define LIBAVUTIL_VERSION_MAJOR 55
> -#define LIBAVUTIL_VERSION_MINOR
On 2015-11-19 13:52, Ganesh Ajjanagadde wrote:
> diff --git a/libavfilter/af_dynaudnorm.c b/libavfilter/af_dynaudnorm.c
>> index 8f0c2d0..62a2653 100644
>> --- a/libavfilter/af_dynaudnorm.c
>> +++ b/libavfilter/af_dynaudnorm.c
>> @@ -227,8 +227,6 @@ static int cqueue_pop(cqueue *q)
>> return 0
On 2015-12-04 15:33, Nicolas George wrote:
> Why do we need a new options system?
>
> Most importantly: escaping hell
OMG yes! I have seen several times the amount of backslashes Windows
users are forced to use to provide a path to some of the filters.
You raise a lot of good points that need
On 2015-12-04 06:29, Ryan Williams wrote:
> EDIT: Fixed errors in syntax.
>
> TLDR, Would you consider an 'underlay' filter or perhaps an option on the
> 'overlay' filter that reverses the order of the input labels?
>
> Consider the following shorthand syntax "[input][a] overlay, [b] overlay, [c
On 2015-12-31 07:02, Kieran Kunhya wrote:
>> Apart from that, again from a quick glance, there are a ton of
>> mallocs/frees. Can these somehow get consolidated?
>
> Yes, that's what I don't know how to solve easily. They should of
> course be a single allocated buffer that's reused.
Forgive me i
Around 35% faster than the avx version.
---
libavcodec/v210enc.c | 5 ++--
libavcodec/v210enc.h | 1 +
libavcodec/x86/v210enc.asm| 53 +++
libavcodec/x86/v210enc_init.c | 7 ++
4 files changed, 49 insertions(+), 17 deletions(-)
On 2016-01-14 20:21, Henrik Gramner wrote:
> On Wed, Jan 13, 2016 at 4:55 PM, James Darnley
> wrote:
>> diff --git a/libavcodec/x86/v210enc.asm b/libavcodec/x86/v210enc.asm
>> index 859e2d9..a8f3d3c 100644
>> --- a/libavcodec/x86/v210enc.asm
>> +++ b/libavcodec/x86
On 2016-01-14 21:42, Henrik Gramner wrote:
> On Thu, Jan 14, 2016 at 9:27 PM, James Darnley
> wrote:
>> On 2016-01-14 20:21, Henrik Gramner wrote:
>>> xmN can be used unconditionally which gets rid of the %else. E.g.
>>>
>>> movu
2.6 times faster
---
I have one question now. Should I make the function name match the assembly
existing deblock/loop filter functions? I took the current name from the C (as
I was originally trying to use a gather instruction but that didn't offer any
benefit).
---
libavcodec/x86/h264_deblock.
Around 35% faster than the avx version.
Signed-off-by: Henrik Gramner
---
The only changes here are the ones suggested by Henrik and a whitespace change
for alignment at the function definition in v210enc_init.c
---
libavcodec/v210enc.c | 5 +++--
libavcodec/v210enc.h | 1 +
Around 25% faster than the ssse3 version.
---
New patch. Should I squash this into the previous patch before committing?
---
libavcodec/v210enc.c | 11 +--
libavcodec/x86/constants.c| 3 ++-
libavcodec/x86/constants.h| 2 +-
libavcodec/x86/v210enc.asm| 20 ++
---
Is the name I chose for the 10-bit tests (v210-10) okay?
---
tests/fate/vcodec.mak| 3 ++-
tests/ref/vsynth/vsynth1-v210-10 | 4
tests/ref/vsynth/vsynth2-v210-10 | 4
tests/ref/vsynth/vsynth3-v210-10 | 4
tests/ref/vsynth/vsynth_lena-v210-10 | 4
The sample factor must be the same for both 8- and 10-bit functions chosen
otherwise the output will be incorrect.
---
Should I squash this one too?
---
libavcodec/v210enc.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/v210enc.h b/libavcodec/v210enc.h
index 85f8
On 2016-01-15 03:55, James Almer wrote:
> On 1/14/2016 11:05 PM, James Darnley wrote:
>> diff --git a/libavcodec/x86/h264_deblock.asm
>> b/libavcodec/x86/h264_deblock.asm
>> index 5151f3c..20f0814 100644
>> --- a/libavcodec/x86/h264_deblock.asm
>> +++
On 2016-01-15 04:21, Ronald S. Bultje wrote:
> If you don't need r%dm (looks like you don't, but didn't check
> exhaustively), you can also use a negative stack size (0 - mmsize -
> ARCH_X86_64 * 2 * mmsize), then it will not create a stack pointer.
I am already using r[0-3]m for storage. (A nice
On 2016-01-15 21:55, James Almer wrote:
> On 1/15/2016 5:00 PM, James Darnley wrote:
>> On 2016-01-15 03:55, James Almer wrote:
>>> On 1/14/2016 11:05 PM, James Darnley wrote:
>>>> diff --git a/libavcodec/x86/h264_deblock.asm
>>>> b/libavcodec/x86/h2
On 2016-01-15 20:07, James Darnley wrote:
> ...
If nobody has further comments about the patches I will probably push
these after I wake up.
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
On 2016-01-17 03:11, James Darnley wrote:
> On 2016-01-15 20:07, James Darnley wrote:
>> ...
>
> If nobody has further comments about the patches I will probably push
> these after I wake up.
>
A little later than planned but now pushed.
signature.asc
Description: Open
On 2016-01-17 23:59, Henrik Gramner wrote:
> The following patches were recently pushed to x264.
>
> Geza Lore (1):
> x86inc: Add debug symbols indicating sizes of compiled functions
>
> Henrik Gramner (6):
> x86inc: Be more verbose in assertion failures
> x86inc: Improve FMA instruction ha
Someone on IRC asked for a scale that would fit in a given box. This is the
answer. I couldn't see it in the existing examples so I thought I would add it.
---
doc/filters.texi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index dd1f203..56236c6 10
On 2016-01-23 22:11, charlie.arn...@gmail.com wrote:
> +if enabled msvc; then
> +dst_path=$(pwd -W)
> +else
> +dst_path=$(pwd)
> +fi
> +
If using MSVC through Cygwin is supported this would fail. Its pwd
command does not have the -W option.
Most people probably don't use both.
signat
On 2016-01-23 23:48, charlie.arn...@gmail.com wrote:
> From: Charles Arnold
>
> Use cygpath -w when running under cygwin, and pwd -W under mingw
> ---
> configure | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index f7d1000..94a694a
On 2016-01-24 00:10, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 12:06 AM, James Darnley
> wrote:
>> On 2016-01-23 23:48, charlie.arn...@gmail.com wrote:
>>> From: Charles Arnold
>>>
>>> Use cygpath -w when running under cygwin, and pwd -W
On 2016-01-24 00:24, James Darnley wrote:
> I will try and find out how old the option is.
--mixed was added in 2002:
> https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=1050e57c9afee171480510d3277877aca29c0f96
signature.asc
Description: OpenPGP digital sig
On 2016-01-22 14:44, Michael Niedermayer wrote:
> On Fri, Jan 22, 2016 at 03:53:10AM +0100, James Darnley wrote:
>> Someone on IRC asked for a scale that would fit in a given box. This is the
>> answer. I couldn't see it in the existing examples so I thought I would add
&
On 2016-01-26 17:53, Vittorio Gambaletta (VittGam) wrote:
> Hi,
>
> On 26/01/2016 15:20:22 CET, Vittorio Gambaletta (VittGam) wrote:
>> Hi,
>>
>> On 26/01/2016 15:16:21 CET, James Darnley wrote:
>>> On 2016-01-22 14:44, Michael Niedermayer wrote:
>>&
On 2016-01-11 18:21, Stefano Sabatini wrote:
> +This option shows the following information for each processing step,
> +in this order: the user process time (in microseconds), the elapsed
> +relative time (in microseconds), the processing step type, and the
> +relative stream.
What is "relative t
On 2016-01-27 13:09, Stefano Sabatini wrote:
> Simplify parsing and consistency.
Fine.
(Ha. It looks like I forgot to press send on this before going out.)
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-de
On 2016-01-27 19:27, Stefano Sabatini wrote:
> On date Wednesday 2016-01-27 13:56:38 +0100, James Darnley encoded:
>> On 2016-01-11 18:21, Stefano Sabatini wrote:
>>> +This option shows the following information for each processing step,
>>> +in this order: the user pr
On 2016-01-31 16:58, Umair Khan wrote:
> Hi,
> Thanks for reply. I did a lot of searching but couldn't get what is
> the proper way to resend the patch with amended commit.
> Should I just do git send-email again ?
> And should I send it to this thread only ? If yes, how ?
Yes. Run send-email aga
2.6 times faster (366 vs. 142 cycles)
---
Changes since last patch:
- name changed to follow 420 version.
- use one less reg by using r4 more (James Almer's suggestion)
- don't require aligned space in the stack, use a negative value as the cglobal
argument. (perhaps unnessecary now that r6 i
On 2016-02-02 23:25, Paul B Mahol wrote:
> Hi,
>
> patch attached.
Nice. I look forward to reading it.
Firstly: why limit it to Lua 5.1? I think it should also support
LuaJIT. While it is ABI compatible with 5.1 this patch would require
its headers to be in "lua-5.1". My suggestion would be
On 2016-02-05 21:20, Henrik Gramner wrote:
> Using rNm and x86inc's stack allocation with a negative value at the same
> time isn't supported, and caused the original stack pointer to be clobbered
> when using a compiler that doesn't support stack alignment.
> ---
> libavcodec/x86/h264_deblock.asm
On 2016-02-05 21:20, Paul B Mahol wrote:
> diff --git a/cmdutils.c b/cmdutils.c
> index e0d2807..03a4836 100644
> --- a/cmdutils.c
> +++ b/cmdutils.c
> @@ -1625,7 +1625,7 @@ int show_filters(void *optctx, const char *opt, const
> char *arg)
>( i && (filter->flag
On 2016-02-04 19:40, Paul B Mahol wrote:
> +#define FN_ENTRY(name) {#name, script_ ## name}
> +struct fn_entry {
> +const char *name;
> +int (*fn)(lua_State *L);
> +};
> +
> +static const struct fn_entry main_fns[] = {
> +FN_ENTRY(log),
> +FN_ENTRY(frame_count),
> +FN_ENTRY(fil
On 2015-07-30 15:36, Nemo wrote:
> I need "-fopenmp" to tell gcc to use OpenMP now. But where should I insert
> "-fopenmp" to?
Add it to the compiler and linker flags. The easiest way to do this
with ffmpeg is probably to configure with --extra-cflags=-fopenmp and
--extra-ldflags=-fopenmp
si
On 2015-09-08 05:42, Timothy Gu wrote:
> ffmpeg | branch: master | Timothy Gu | Mon Sep 7
> 19:11:16 2015 -0700| [617d53f4c7e43b5df6f99b363b550ff7b0007c6e] | committer:
> Timothy Gu
>
> configure: Reenable colorized warnings and check for tput's existence
>
> Untested.
>
>> http://git.videol
At present it only converts global metadata as that is what I wanted to do. It
should be possible to extend it so that the conversion can be different for
different files or streams.
---
doc/ffmpeg.texi | 6 +++
ffmpeg.c| 15 ++
ffmpeg.h| 1 +
ffmpeg_opt.c| 149 ++
On 2015-09-22 20:22, Nicolas George wrote:
> Le primidi 1er vendémiaire, an CCXXIV, James Darnley a écrit :
>> +@item -metadata_iconv_code_page_list @var{code_page_list}
>> +Force the metadata from input files to be converted through the given
>> codepages
>> +using
On 2015-09-23 16:56, Nicolas George wrote:
> Le primidi 1er vendémiaire, an CCXXIV, James Darnley a écrit :
>> At present it only converts global metadata as that is what I wanted to do.
>> It
>> should be possible to extend it so that the conversion can be different for
On 2015-09-23 19:28, Nicolas George wrote:
> Hi.
>
> This is a proposal for an API in libavutil to perform text encoding
> conversions. I had it in mind to clean up the subtitles code initially, and
> now it could be useful for James' proposal about metadata. The issues are
> relying on the option
On 2015-09-24 12:36, Nicolas George wrote:
> Le duodi 2 vendémiaire, an CCXXIV, James Darnley a écrit :
>> It is not supposed to replace any invalid bytes with a "random"
>> character. That sounds like it will only make the problem worse with
>> that lossy removal
On 2015-09-24 20:37, Nicolas George wrote:
> Le tridi 3 vendémiaire, an CCXXIV, James Darnley a écrit :
>> I don't know what to say here. I know the encodings needed for iconv
>> because I arrived at them by brute force. I wrote a short Lua script to
>> iterate over a l
On 2015-09-27 14:37, Stefano Sabatini wrote:
> ---
> src/index | 234
> ++
> 1 file changed, 234 insertions(+)
>
> diff --git a/src/index b/src/index
> index 9d12a7b..8937172 100644
> --- a/src/index
> +++ b/src/index
> @@ -37,6 +37,240
On 2015-09-27 17:43, Stefano Sabatini wrote:
> On date Sunday 2015-09-27 15:28:50 +0200, James Darnley encoded:
>> On 2015-09-27 14:37, Stefano Sabatini wrote:
>>> +
>>> +TNS still needs some polishing, but has the potential to reduce coding
>>> +ar
On 2015-09-27 23:06, Ganesh Ajjanagadde wrote:
> On Sun, Sep 27, 2015 at 5:00 PM, James Darnley
> wrote:
>> On 2015-09-27 17:43, Stefano Sabatini wrote:
>>> On date Sunday 2015-09-27 15:28:50 +0200, James Darnley encoded:
>>>> On 2015-09-27 14:37, Stefano Sabatin
On 2015-09-29 21:56, Clément Bœsch wrote:
> On Tue, Sep 29, 2015 at 09:21:53PM +0200, Hendrik Leppkes wrote:
>> I agree, we have patchcheck for typo checking.
>
> A lot of people do not run patchcheck (I personally never do, and given
> that we fix typo on a regular basis I'm probably not the only
On 2015-10-01 19:25, Paul B Mahol wrote:
> +cglobal maskedmerge8, 10, 11, 3, 0, bsrc, blinesize, osrc, olinesize, msrc,
> mlinesize, dst, dlinesize, w, h
You need a guard to prevent this being compiled on x86.
> +lea bsrcq, [bsrcq+blinesizeq]
> +lea osrcq, [osrcq+olinesizeq]
> +lea m
do that it would eliminate those almost pointless
files.
--
James Darnley (7):
avutil: add shared assembly constants
avcodec: replace old C file with new assembly constants
avcodec: use new constants in C inline assembly
avcodec: use new constants in assembly
avfilter: use new constants i
---
libavcodec/x86/Makefile | 2 +-
libavcodec/x86/constants.asm | 1 +
libavcodec/x86/constants.c | 81
tests/ref/fate/source| 1 +
4 files changed, 3 insertions(+), 82 deletions(-)
create mode 100644 libavcodec/x86/constants.asm
de
---
libavfilter/x86/Makefile | 2 ++
libavfilter/x86/af_volume.asm | 3 +--
libavfilter/x86/constants.asm | 1 +
libavfilter/x86/vf_fspp.asm| 3 +--
libavfilter/x86/vf_removegrain.asm | 3 +--
libavfilter/x86/vf_ssim.asm| 2 +-
libavfilter/x86/vf_yadif.asm
---
So here is the test file I was working on with the thoughts I had.
---
; This section is intended to possibly be included in x86inc.asm
; Align all constant to 32 bytes whether they are used in AVX code or not.
%assign constant_align 32
; Value to be used as padding to achieve alignment. Sho
---
libavcodec/x86/cavsdsp.c| 2 +-
libavcodec/x86/constants.h | 66 -
libavcodec/x86/inline_asm.h | 2 +-
libavcodec/x86/vc1dsp_mmx.c | 2 +-
4 files changed, 3 insertions(+), 69 deletions(-)
delete mode 100644 libavcodec/x86/constants.h
diff
---
libavcodec/x86/ac3dsp.asm | 2 +-
libavcodec/x86/bswapdsp.asm | 3 +--
libavcodec/x86/diracdsp_yasm.asm| 6 +-
libavcodec/x86/dwt_yasm.asm | 6 +-
libavcodec/x86/h263_loopfilter.asm | 2 +-
libavcodec/x86/h264_chromamc.asm
---
libswscale/x86/Makefile | 1 +
libswscale/x86/constants.asm | 1 +
libswscale/x86/output.asm| 5 +
tests/ref/fate/source| 1 +
4 files changed, 4 insertions(+), 4 deletions(-)
create mode 100644 libswscale/x86/constants.asm
diff --git a/libswscale/x86/Makefile b/libswsca
---
tests/ref/fate/source | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/ref/fate/source b/tests/ref/fate/source
index 781f4cd..c1383dd 100644
--- a/tests/ref/fate/source
+++ b/tests/ref/fate/source
@@ -9,6 +9,7 @@ libavcodec/reverse.c
libavcodec/x86/constants.asm
libavdevice/file_ope
On 2015-10-02 19:16, Timothy Gu wrote:
> On Fri, Oct 2, 2015 at 10:08 AM James Darnley
> wrote:
>
>> The third patch uses them in the remaining inline assembly.
>>
>
> That's the crux of the problem: inline asm uses these constants, but will
> be una
On 2015-10-03 04:08, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Oct 2, 2015 at 4:58 PM, Hendrik Leppkes wrote:
>
>> On Fri, Oct 2, 2015 at 7:16 PM, Timothy Gu wrote:
>>> On Fri, Oct 2, 2015 at 10:08 AM James Darnley
>>> wrote:
>>>
>>>> T
On 2018-05-10 17:44, Derek Buitenhuis wrote:
> These demuxers have probes that mainly probe based on file extension,
> and map to codec IDs that render text as video. The result is that
> ffmpeg will, by default, happily render, for example, .txt files
> as images. This is not exactly a good securi
On 2018-05-11 00:57, Derek Buitenhuis wrote:
>> Disabling demuxers by default does not seem to be a good idea to me.
>
> So rendering arbitrary text files by default seems like a good idea in
> comparsion?
I want to argue some more so here you go: it isn't "by default".
It gets rendered because
On 2018-05-20 20:53, Stephan Holljes wrote:
> +#include
> +#include
> +#include
That's not portable. Lua headers are not in a subdirectory.
> +int configs_read(struct HTTPDConfig **configs, const char *filename)
> +{
> +int ret = 0;
> +int nb_configs = 0;
> +int nb_streams = 0;
>
On 2018-07-13 19:26, Michael Niedermayer wrote:
> Found-by:
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/dirac_dwt_template.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/dirac_dwt_template.c b/libavcodec/dirac_dwt_template.c
> index 528f
From: James Darnley
---
tests/fate/vcodec.mak | 24
tests/ref/vsynth/vsynth1-vc2-5_3 | 4
tests/ref/vsynth/vsynth1-vc2-haar | 4
tests/ref/vsynth/vsynth2-vc2-5_3 | 4
tests/ref/vsynth/vsynth2-vc2-haar | 4
tests
On 2018-07-14 17:58, Michael Niedermayer wrote:
> On Fri, Jul 13, 2018 at 08:09:57PM +0200, James Darnley wrote:
>> From: James Darnley
>>
>> ---
>> tests/fate/vcodec.mak | 24
>> tests/ref/vsynth/vsynth1-vc2-5_3
On 2018-07-14 23:31, Michael Niedermayer wrote:
> [SMPTE VC-2 encoder @ 0x2a42640] Error setting option wavelet_type to value
> 444p12.
Yep. Good work make!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpe
From: James Darnley
---
Michael, can you test this for the same failure you saw last time?
tests/fate/vcodec.mak | 24
tests/ref/vsynth/vsynth1-vc2-t5_3 | 4
tests/ref/vsynth/vsynth1-vc2-thaar | 4
tests/ref/vsynth/vsynth2-vc2-t5_3
On 2018-07-18 02:24, Michael Niedermayer wrote:
> On Mon, Jul 16, 2018 at 01:03:53PM +0200, James Darnley wrote:
>> From: James Darnley
>>
>> ---
>> Michael, can you test this for the same failure you saw last time?
>
> seems to work in all cases i tested
Good
it in Haar? Is the AVX2 worth it in the latter two? I added
those later which is why they are separate patches. I will squash them before
pushing if I keep them.
James Darnley (6):
diracdec: add 10-bit Haar SIMD functions
diracdec: add 10-bit Legall 5,3 (5_3) SIMD functions
diracdec: add 10
Speed of ffmpeg when decoding a 720p yuv422p10 file encoded with the
relevant transform.
C: 94fps
SSE2: 118fps
AVX2: 121fps
---
libavcodec/x86/dirac_dwt_10bit.asm| 55 +++
libavcodec/x86/dirac_dwt_init_10bit.c | 23 +++
2 files changed, 78 insertions(+)
dif
---
libavcodec/x86/dirac_dwt_10bit.asm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/x86/dirac_dwt_10bit.asm
b/libavcodec/x86/dirac_dwt_10bit.asm
index 2e039e11ea..d0da822a81 100644
--- a/libavcodec/x86/dirac_dwt_10bit.asm
+++ b/libavcodec/x86/dirac_dwt_10bit.asm
Speed of ffmpeg when decoding a 720p yuv422p10 file encoded with the
relevant transform.
C: 84fps
SSE2: 111fps
AVX2: 115fps
---
libavcodec/x86/dirac_dwt_10bit.asm| 38 +++
libavcodec/x86/dirac_dwt_init_10bit.c | 16 +++
2 files changed, 54 insertions(+)
dif
@@ -0,0 +1,113 @@
+;**
+;* x86 optimized discrete 10-bit wavelet trasnform
+;* Copyright (c) 2018 James Darnley
+;*
+;* This file is part of FFmpeg.
+;*
+;* FFmpeg is free software; you can redistribute it and/or
+;* modify
---
libavcodec/x86/dirac_dwt_10bit.asm| 4 +++-
libavcodec/x86/dirac_dwt_init_10bit.c | 22 ++
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/libavcodec/x86/dirac_dwt_10bit.asm
b/libavcodec/x86/dirac_dwt_10bit.asm
index 681de5e1df..ae110d2945 100644
--- a/
---
libavcodec/x86/dirac_dwt_10bit.asm| 3 ++-
libavcodec/x86/dirac_dwt_init_10bit.c | 13 +
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/libavcodec/x86/dirac_dwt_10bit.asm
b/libavcodec/x86/dirac_dwt_10bit.asm
index ae110d2945..2e039e11ea 100644
--- a/libavcodec
On 2018-07-19 17:23, Rostislav Pehlivanov wrote:
>
> Could you provide standard overall transform results using START/STOP_TIMER
> rather than overall decoding speed?
> Coefficients sizes and therefore golomb unpacking speed changes with
> respect to the transform so potentially there could be som
On 2018-07-19 17:26, Rostislav Pehlivanov wrote:
> On 19 July 2018 at 15:52, James Darnley wrote:
>
>> int32_t *b1, int32_t *b2, int
>> b1[i] = COMPOSE_DIRAC53iH0(b0[i], b1[i], b2[i]);
>> }
>>
>> +static void dd97_vertical_hi_sse2(i
On 2018-07-19 17:23, Rostislav Pehlivanov wrote:
> Could you provide standard overall transform results using START/STOP_TIMER
> rather than overall decoding speed?
Ask and ye shall receive.
> haar horizontal compose
> sse2: 3.67x faster (45248±108.1 vs. 12328±21.1 decicycles) compared with
Speed of ffmpeg when decoding a 720p yuv422p10 file encoded with the
relevant transform.
C: 94fps
SSE2: 118fps
AVX2: 121fps
legall vertical hi
sse2: 3.86x faster (20201 vs. 5231 decicycles) compared with C
avx2: 6.70x faster (20201 vs. 3014 decicycles) compared with C
legall vertical l
Speed of ffmpeg when decoding a 720p yuv422p10 file encoded with the
relevant transform.
C: 84fps
SSE2: 111fps
AVX2: 115fps
dd97 vertical hi
sse2: 2.77x faster (31773 vs. 11457 decicycles) compared with C
avx2: 3.83x faster (31773 vs. 8297 decicycles) compared with C
---
libavcodec/x
I will ask the same question as last time. Is the AVX worth it in Haar? Also I
am surprised that the AVX2 doesn't have a bigger difference on some of the
vertical transforms.
James Darnley (3):
diracdec: add 10-bit Haar SIMD functions
diracdec: add 10-bit Legall 5,3 (5_3) SIMD func
wavelet trasnform
+;* Copyright (c) 2018 James Darnley
+;*
+;* This file is part of FFmpeg.
+;*
+;* FFmpeg is free software; you can redistribute it and/or
+;* modify it under the terms of the GNU Lesser General Public
+;* License as published by the Free Software Foundation; either
+;* version 2.
On 2018-07-26 17:29, Rostislav Pehlivanov wrote:
> On 26 July 2018 at 12:28, James Darnley wrote:
> +cglobal vertical_compose_haar_10bit, 3, 6, 4, b0, b1, w
>> +DECLARE_REG_TMP 4,5
>> +
>> +mova m2, [pd_1]
>> +mov r3d, wd
>> +and wd,
On 2018-07-27 15:05, Henrik Gramner wrote:
> On Fri, Jul 27, 2018 at 1:47 PM, James Darnley wrote:
>> On 2018-07-26 17:29, Rostislav Pehlivanov wrote:
>>>> +cglobal horizontal_compose_haar_10bit, 3, 6+ARCH_X86_64, 4, b, temp_, w,
>>>> x, b2
>>>> +
---
doc/filters.texi | 5 +
libavfilter/vf_subtitles.c | 23 ---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index a161754233..cfbc807f16 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21160,6 +211
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 ++
tests/checkasm/checkasm.h | 1 +
tests/checkasm/vf_yadif.c | 62 +++
4 files changed, 67 insertions(+)
create mode 100644 tests/checkasm/vf_yadif.c
diff --git a/tests/checkasm/Makefile b
Zen 2 (Ryzen 7 3700X):
1.73x faster (3603±586.3 vs. 2082±317.1 decicycles) compared with ssse3
Using an SD y4m file speed increases from ~ 3600 fps to ~4700.
---
libavfilter/x86/vf_yadif.asm| 83 +++--
libavfilter/x86/vf_yadif_init.c | 4 ++
2 files changed, 62 in
---
libavfilter/vf_yadif.c | 13 +
libavfilter/x86/vf_yadif_init.c | 4 +---
libavfilter/yadif.h | 3 ++-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
index afa4d1d53d..1f9434f961 100644
--- a/lib
---
tests/fate/filter-video.mak | 4 +--
tests/ref/fate/filter-yadif10 | 60 +--
tests/ref/fate/filter-yadif16 | 60 +--
3 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/tests/fate/filter-video.mak b/tests/fate/filt
401 - 500 of 517 matches
Mail list logo
