On 12-07-2018 04:33 AM, Mark Thompson wrote:
I'm not sure I'm completely in favour of that change, anyway? The section feels more coherent to
me as "OpenCL versions of other filters" rather than "all filters using OpenCL"
- program_opencl/openclsrc do something really quite different. Does
Lensfun is a library that applies lens correction to an image using a
database of cameras/lenses (you provide the camera and lens models, and
it uses the corresponding database entry's parameters to apply lens
correction). It is licensed under LGPL3.
The lensfun filter utilizes the lensfun library
On Thu, Jul 12, 2018 at 12:47 PM Stephen Seo wrote:
>
> Hi,
>
> It appears I used the wrong license in libavfilter/vf_lensfun.c
>
> It derives from the Lensfun library that uses (L)GPL3, but I used GPL2 by
> mistake.
>
> Should I 'git send-email' the whole patch again with this mistake resolved,
>
Hi,
It appears I used the wrong license in libavfilter/vf_lensfun.c
It derives from the Lensfun library that uses (L)GPL3, but I used GPL2 by
mistake.
Should I 'git send-email' the whole patch again with this mistake resolved,
or should I email another patch with just the license correction? (I'
Lensfun is a library that applies lens correction to an image using a
database of cameras/lenses (you provide the camera and lens models, and
it uses the corresponding database entry's parameters to apply lens
correction). It is licensed under LGPL3.
The lensfun filter utilizes the lensfun library
> > From: gxw
> >
> > Optimize vp8 loop filter with mmi, four functions optimized:
> > 1. ff_vp8_h_loop_filter8uv_mmi.
> > 2. ff_vp8_v_loop_filter8uv_mmi.
> > 3. ff_vp8_h_loop_filter16_mmi.
> > 4. ff_vp8_v_loop_filter16_mmi.
> >
> > Vp8 decoding speed improved about 50%(from 73fps to 110fps, Teste
On Thu, Jul 12, 2018 at 12:43 AM Marton Balint wrote:
>
>
>
> On Wed, 11 Jul 2018, Jun Zhao wrote:
>
> > use pixelutils API for sad in motion estimation.
>
> Does it make sense to improve this code? I thought a superior and faster
> approach was a result of 2017 GSOC task:
>
> https://docs.google.
On 04/07/18 05:07, Li, Zhong wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Hendrik Leppkes
>> Sent: Wednesday, July 4, 2018 2:15 AM
>> To: FFmpeg development discussions and patches
>>
>> Subject: Re: [FFmpeg-devel] [PATCH] http
LGTM. thanks
On Tue, Jul 10, 2018 at 5:18 PM Michael Niedermayer
wrote:
> 0.266 <- 0.299 sec (this is time ffmpeg so containing alot other things)
>
> Sample for benchmark was: ffmpeg -f rawvideo -pix_fmt yuv420p -s 32x32 -i
> /dev/zero -t 24:00:00.00 out.mp4
>
> Signed-off-by: Michael Niedermaye
Hi!
Attached patch allows to fast-start mov files with free atoms after
the moov atom.
Tested with the sample from ticket #7277.
Please comment, Carl Eugen
From 8decd60aaae4209f4991c926f058f9370701336e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 12 Jul 2018 01:24:39 +0200
Subject:
On 05/07/18 15:11, Danil Iashchenko wrote:
> add documentation to all existing OpenCL filters
> ---
>> I like this patch, the other thing, is it have any plan to update
>> openCL part like VAAPI (https://trac.ffmpeg.org/wiki/Hardware/VAAPI)
>> in https://trac.ffmpeg.org/wiki/HWAccelIntro, thanks.
>
>
> This changes the printed values
> ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -qscale 2 -vframes 3 -an
> test2.avi
> frame=3 fps=0.0 q=2.0 Lsize= 51kB time=00:00:00.12
> bitrate=3495.7kbits/s speed= 12x
> video:51kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
> muxing
On 09/07/18 03:26, Danil Iashchenko wrote:
> lavfi: add vflip_opencl, hflip_opencl.
> Behaves like existing vflip, hflip filters.
> ---
> configure | 2 +
> libavfilter/Makefile | 4 +
> libavfilter/allfilters.c | 2 +
> libavfilter/opencl/vflip.cl | 60 +
2018-07-12 0:03 GMT+02:00, Karsten Otto :
> Argh, just noticed a stupid mistake - quite obviously, the check pattern
> needs to be shifted too, i.e. 1<<19 instead of just 1. Luckily, it won't do
> any harm, since it can never evaluate to true.
>
> What is the protocol in this case - Do I send a new
On 09/07/18 13:41, Danil Iashchenko wrote:
> Fixed using uninitialized value "global_work[0]" when calling "av_log".
>
> ---
> libavfilter/vf_avgblur_opencl.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/vf_avgblur_opencl.c b/libavfilter/vf_avgblur
On 03/07/18 19:16, Ruiling Song wrote:
> Signed-off-by: Ruiling Song
> ---
> libavfilter/opencl.h| 11 +
> libavfilter/vf_avgblur_opencl.c | 45 +--
> libavfilter/vf_overlay_opencl.c | 29 +--
> libavfilter/vf_program_opencl.
Hi!
Attached patch silences a warning about an unused variable for the
default compilation.
Please comment, Carl Eugen
From d9fd7569ef2526f00b5544c3efef377ea86f815c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 12 Jul 2018 00:07:55 +0200
Subject: [PATCH] lavc/h263dec: Remove a varia
Argh, just noticed a stupid mistake - quite obviously, the check pattern
needs to be shifted too, i.e. 1<<19 instead of just 1. Luckily, it won't do
any harm, since it can never evaluate to true.
What is the protocol in this case - Do I send a new version of the patch?
Or another patch to the patc
MP3 frames may not be aligned to aa chunk boundaries. When seeking,
calculate the expected frame offset in the target chunk. Adjust the
timestamp and truncate the next packet accordingly.
This solution works for the majority of tested audio material. For
some rare encodings with mp3 padding or emb
> Am 11.07.2018 um 20:09 schrieb Michael Niedermayer :
>
> Signierter PGP-Teil
> On Sat, Jul 07, 2018 at 07:41:29PM +0200, Karsten Otto wrote:
>> MP3 frames may not be aligned to aa chunk boundaries. When seeking,
>> calculate the expected frame offset in the target chunk. Adjust the
>> timestamp
Michael, Nicolas,
Do you think this patch is now ready to be applied? Or would you like me to
make any further changes?
Thanks,
Marcin
On Tue, Jul 10, 2018 at 10:34 AM Marcin Gorzel wrote:
> Hi Michael,
>
> I think I know where the misunderstanding could be.
>
> The main changes in my patch a
On Wed, Jul 11, 2018 at 11:13:43AM -0700, Sasi Inguva wrote:
> LGTM. thanks
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to
LGTM.
On Tue, Jul 10, 2018 at 5:18 PM Michael Niedermayer
wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mov.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 67b3e11eb9..951a337cca 100644
> --- a/liba
On Wed, Jul 11, 2018 at 11:05:09AM -0700, Sasi Inguva wrote:
> This one LGTM. Thanks for doing this.
will apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
signature.asc
Desc
LGTM. thanks
On Tue, Jul 10, 2018 at 5:18 PM Michael Niedermayer
wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mov.c | 19 ---
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index aabf06de12..67b3e11
This one LGTM. Thanks for doing this.
On Tue, Jul 10, 2018 at 5:18 PM Michael Niedermayer
wrote:
> 0.324 <-0.491 sec
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mov.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavfor
On Sat, Jul 07, 2018 at 07:41:29PM +0200, Karsten Otto wrote:
> MP3 frames may not be aligned to aa chunk boundaries. When seeking,
> calculate the expected frame offset in the target chunk. Adjust the
> timestamp and truncate the next packet accordingly.
>
> This solution works for the majority o
On Tue, Jul 10, 2018 at 08:10:00PM +0530, Umair Khan wrote:
> Hi,
>
> Patch attached.
>
> -Umair
> lrcdec.c |3 +++
> 1 file changed, 3 insertions(+)
> 6782b07bfa45139361c15527ee5fb78e5893b9ba
> 0001-avformat-lrcdec-fix-losing-opening-bracket.patch
> From 95a5d2e5575c5f895e4251775a48f7deb
On Wed, 11 Jul 2018, Jun Zhao wrote:
use pixelutils API for sad in motion estimation.
Does it make sense to improve this code? I thought a superior and faster
approach was a result of 2017 GSOC task:
https://docs.google.com/document/d/1Hyh_rxP1KGsVkg7i7yU8Bcv92z0LIL4r-axpoKfvMFk/edit
May
On Wed, 4 Jul 2018 23:10:46 +0300
Shlomi Fish wrote:
Ping! Can this patch be reviewed please?
--
-
Shlomi Fish http://www.shlomifish.org/
Parody of "The Fountainhead" - http://shlom.in/towtf
When Chuck Norris uses git, he t
On Sun, Jul 8, 2018 at 11:21 PM, Michael Niedermayer
wrote:
> On Thu, Jun 28, 2018 at 02:51:00AM +0200, Stephan Holljes wrote:
>> This patchset took embarrassingly long to produce. I first took a few wrong
>> turns, but I think I'm now at a point where I reached the limits of the
>> public server
2018-07-11 16:32 GMT+02:00, Derek Buitenhuis :
> On Tue, Jul 10, 2018 at 8:17 PM, Michael Niedermayer
> wrote:
>> 0.324 <-0.491 sec
>>
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavformat/mov.c | 10 +++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> All four of these patch
On Tue, Jul 10, 2018 at 8:17 PM, Michael Niedermayer
wrote:
> 0.324 <-0.491 sec
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mov.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
All four of these patches combined bring the penalty down from 2-3x to ~1.19x,
whic
Hi,
I was wondering if anyone more in the know about this can help fix this issue.
https://trac.ffmpeg.org/ticket/7282#comment:11
It’s preventing us from supporting adaptive Streaming between LCAAC and HEAAC.
Thanks
Ronak
Sent from my iPhone
___
ffm
2018-07-11 11:46 GMT+02:00, Shiyou Yin :
> Reoptimized following functions with mmi:
> 1. ff_put_pixels4_8_mmi.
> 2. ff_put_pixels8_8_mmi.
> 3. ff_put_pixels16_8_mmi.
> 4. ff_add_pixels_clamped_mmi.
Same for this and some other patches:
Please explain why the change was done.
Carl Eugen
_
2018-07-11 11:45 GMT+02:00, Shiyou Yin :
> Reoptimized following functions with mmi.
> 1. ff_simple_idct_put_mmi
> 2. ff_simple_idct_add_mmi
> 3. ff_simple_idct_mmi (rename to ff_simple_idct_8_mmi)
Are the new functions faster? Easier to maintain?
More future-proof?
Please add some explanation to
2018-07-11 11:44 GMT+02:00, Shiyou Yin :
> Revert expensive optimizations in gcc O3 optimization for loongson.
> The bug in gcc-4.9.x has been fixed in gcc master branch.
> Loongson released gcc-4.9.3-3.fc21.loongson with this patch.
I believe the title of the patch can be clarified ("revert
no-e
2018-07-11 11:46 GMT+02:00, Shiyou Yin :
> From: gxw
>
> Optimize vp8 loop filter with mmi, four functions optimized:
> 1. ff_vp8_h_loop_filter8uv_mmi.
> 2. ff_vp8_v_loop_filter8uv_mmi.
> 3. ff_vp8_h_loop_filter16_mmi.
> 4. ff_vp8_v_loop_filter16_mmi.
>
> Vp8 decoding speed improved about 50%(from
2018-07-11 12:22 GMT+02:00, Shiyou Yin :
> Optimize function get_cabac_inline with asm for loongson platform.
The commit message should contain some numbers about the
speed-up.
Does this patch (and do the other patches) work on both mips
platforms? (There are two that are currently supported by
F
Optimize function get_cabac_inline with asm for loongson platform.
Change-Id: I538ad5c2d2fc20793aa36b6697c956a1b5ddbc78
Signed-off-by: Shiyou Yin
---
libavcodec/cabac_functions.h | 3 ++
libavcodec/mips/cabac.h | 119 +++
2 files changed, 122 insert
On Wed, Jul 11, 2018 at 5:46 PM, Shiyou Yin
wrote:
> From: gxw
>
> Optimize vp8 loop filter with mmi, four functions optimized:
> 1. ff_vp8_h_loop_filter8uv_mmi.
> 2. ff_vp8_v_loop_filter8uv_mmi.
> 3. ff_vp8_h_loop_filter16_mmi.
> 4. ff_vp8_v_loop_filter16_mmi.
>
> Vp8 decoding speed improved ab
From: gxw
Optimize vp8 loop filter with mmi, four functions optimized:
1. ff_vp8_h_loop_filter8uv_mmi.
2. ff_vp8_v_loop_filter8uv_mmi.
3. ff_vp8_h_loop_filter16_mmi.
4. ff_vp8_v_loop_filter16_mmi.
Vp8 decoding speed improved about 50%(from 73fps to 110fps, Tested on loongson
3A3000).
Change-Id
Reoptimized following functions with mmi:
1. ff_put_pixels4_8_mmi.
2. ff_put_pixels8_8_mmi.
3. ff_put_pixels16_8_mmi.
4. ff_add_pixels_clamped_mmi.
Change-Id: I80be1891f52942e432a72e96c135bc9ead92972f
Signed-off-by: Shiyou Yin
---
libavcodec/mips/hpeldsp_mmi.c | 133 +++--
Failed case: mss2-wmv
In series functions of ff_vc1_inv_trans, pmullh instrunction was used to do the
multiplication of 16 bits data. It will cause overflow problem.
Change-Id: I1dc6a7e6740cd6e38d51c91d2e644b2ad8263939
Signed-off-by: Shiyou Yin
---
libavcodec/mips/vc1dsp_mmi.c | 1493 ++
Optimize function get_cabac_inline with asm for loongson platform.
Change-Id: I538ad5c2d2fc20793aa36b6697c956a1b5ddbc78
Signed-off-by: Shiyou Yin
---
libavcodec/cabac_functions.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/cabac_functions.h b/libavcodec/cabac_functions.h
in
Remove useless variable addr used in function ff_put_pixels16_8.
Change-Id: I6a1ddd98c14261cffb2b59a8ecfb0d4983d87a85
Signed-off-by: Shiyou Yin
---
libavcodec/mips/hpeldsp_mmi.c | 43 ---
1 file changed, 20 insertions(+), 23 deletions(-)
diff --git a/liba
Reoptimize function ff_put_h264_chroma_mc8_mmi and ff_avg_h264_chroma_mc8_mmi
v2.
Change-Id: I24c72ce5f5ef537faa603fdf5c56ecdd1327034d
Signed-off-by: Shiyou Yin
---
libavcodec/mips/h264chroma_mmi.c | 740 ---
1 file changed, 454 insertions(+), 286 deletions(-
Optimized memset with mmi in following functions:
1. ff_h264_add_pixels4_8_mmi.
2. ff_h264_idct_add_8_mmi.
3. ff_h264_idct8_add_8_mmi.
Change-Id: If2656d2c945ce7996c0d5398f8fbae94540f1d83
Signed-off-by: Shiyou Yin
---
libavcodec/mips/h264dsp_mmi.c | 36 +---
1 fil
Revert expensive optimizations in gcc O3 optimization for loongson.
The bug in gcc-4.9.x has been fixed in gcc master branch.
Loongson released gcc-4.9.3-3.fc21.loongson with this patch.
More bug info see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67736
https://gcc.gnu.org/ml/gcc-patches/2012-0
On Tue, Jul 10, 2018 at 05:52:00PM -0400, Patrick Keroulas wrote:
> This codec is already capable of depacking some combinations of pixel
> formats and depth as defined in the RFC4175. The only difference between
> progressive and interlace is that either a packet will contain the whole
> frame, or
On Tue, Jul 10, 2018 at 05:51:59PM -0400, Patrick Keroulas wrote:
> Ancillary data can carry various side data that can't be transmitted in
> bitstreams. For now, this struct includes interlaced field flags and
> the must be attached to an AVPacket as side data.
>
> Signed-off-by: Patrick Keroulas
51 matches
Mail list logo
