In commit 975a1a8,function ff_vc1_h_s_overlap_mmi was refactored,
but the declaration in libavcodec/mips/vc1dsp_mips.h was unchanged.
Change-Id: I90beae683511622a0cc1130ab1660ac8669ec3ef
Signed-off-by: Shiyou Yin
---
libavcodec/mips/vc1dsp_mips.h | 2 +-
1 file changed, 1 insertion(+), 1 deletio
On 7/12/18, Stephen Seo wrote:
> 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
This fixes the check for the reserved MPEG audio version ID,
used to detect an invalid frame header.
---
libavcodec/mpegaudiodecheader.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpegaudiodecheader.h b/libavcodec/mpegaudiodecheader.h
index ed9961250a..1da2a4cb6
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 12/07/2018 06:40, 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,
or should I email another p
On Thu, Jul 12, 2018 at 5:52 PM, Timo Rothenpieler
wrote:
> On 12/07/2018 06:40, 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-e
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 12-07-2018 02:45 PM, Stephen Seo wrote:
I have already added some lines in configure to not compile the filter
unless --enable-version3 is also specified to configure, but thanks for
checking.
Just to be clear - the library is LGPL3 and your filter is meant to be GPL3.
Regards,
Gyan
__
On Thu, Jul 12, 2018 at 7:10 PM, Gyan Doshi wrote:
>
>
> On 12-07-2018 02:45 PM, Stephen Seo wrote:
>
>
> I have already added some lines in configure to not compile the filter
>>>
>> unless --enable-version3 is also specified to configure, but thanks for
>> checking.
>>
>
> Just to be clear - th
On Mon, Jul 09, 2018 at 03:26:54PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> ff_av1_filter_obus() could eventually be replaced by an autoinserted
> filter_units bsf, assuming it doesn't slow down the muxing process
> too much (CBS is fast reading packets, but not so much assem
On 12-07-2018 03:59 PM, Stephen Seo wrote:
Yes, because it also uses a lanczos resampling implementation based on the
one that exists in Lenstool, which is in the Lensfun repository and that is
GPL3 while Lensfun itself is LGPL3. Correct me if I'm wrong, but I think
that because of this the fi
On Wed, Jul 11, 2018 at 03:47:45PM -0700, Wang Cao wrote:
> >
> > 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:51
On Wed, Jul 11, 2018 at 04:36:53PM -0700, Sasi Inguva wrote:
> 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
On Wed, Jul 11, 2018 at 11:32:33AM -0700, Sasi Inguva wrote:
> LGTM.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epict
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
> 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
> 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
> 主题: Re: [FFmpeg-devel] [PATCH 6/9] avcodec: [loongson] optimize
> get_cabac_inline with asm.
>
> 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 th
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-05/msg00401.html
Change-Id: I780125d4cdee71d40457aaee22126ba0547a2c8
Reoptimize function ff_put_h264_chroma_mc8_mmi and ff_avg_h264_chroma_mc8_mmi.
Performance of h264 decoding improved about 5%(from 69fps to 73fps, tested on
loongson 3A3000).
Change-Id: Iccd7f4e480b2d0bfc47e4d409874c4adb77416cc
Signed-off-by: Shiyou Yin
---
libavcodec/mips/h264chroma_mmi.c | 74
Remove useless variable addr used in function ff_put_pixels16_8.
Change-Id: I8b8c996a73ad13676852baa5ef4060d73882c0ab
Signed-off-by: Shiyou Yin
---
libavcodec/mips/hpeldsp_mmi.c | 43 ---
1 file changed, 20 insertions(+), 23 deletions(-)
diff --git a/liba
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.
This optimization improved h264 decoding performance about 1fps(tested on
loongson 3A3000).
Change-Id: I4e8b75510e6a34b4c80f84ad784b00377570c4ec
Signed-off-by: S
Optimize function get_cabac_inline with asm.
This optimization improved h264 decoding performance about 3fps(from 74fps to
77fps, tested on loongson 3A3000).
Change-Id: Ia06381d3b820b6abdeef6af257d7b64b43f08a4b
Signed-off-by: Shiyou Yin
---
libavcodec/cabac_functions.h | 3 ++
libavcodec/mips
Failed case: mss2-wmv
pmullh instrunction was used to do the multiplication of 16 bits data in
following functions,and this may cause overflow problem.
1. ff_vc1_inv_trans_8x8_dc_mmi
2. ff_vc1_inv_trans_8x8_mmi
3. ff_vc1_inv_trans_8x4_mmi
4. ff_vc1_inv_trans_4x8_mmi
5. ff_vc1_inv_trans_4x4_mmi
C
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.
This optimization improved mpeg4 decoding performance about 6fps(from 158fps to
164fps, tested on loongson 3A3000).
Change-Id: I6baff96587c5441cd8b7
On 7/12/2018 8:26 AM, Michael Niedermayer wrote:
> On Mon, Jul 09, 2018 at 03:26:54PM -0300, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> ff_av1_filter_obus() could eventually be replaced by an autoinserted
>> filter_units bsf, assuming it doesn't slow down the muxing process
>> too
---
libavfilter/vf_convolution_opencl.c | 46 +
1 file changed, 11 insertions(+), 35 deletions(-)
diff --git a/libavfilter/vf_convolution_opencl.c
b/libavfilter/vf_convolution_opencl.c
index e2ba81b..00246b2 100644
--- a/libavfilter/vf_convolution_opencl.c
+++
Signed-off-by: Jun Zhao
---
libavcodec/hevc_ps.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index bca3abb..bc5406b 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1094,11 +1094,9 @@ int ff_hevc_parse_s
On Thu, Jul 12, 2018 at 21:17:42 +0900, Stephen Seo wrote:
> + --enable-lensfun enable lensfun lens correction [no]
I may be mistaken, but aren't (new) dependencies to external libraries
coded as "libfoo"? So "--enable-liblensfun"?
> EXTERNAL_LIBRARY_VERSION3_LIST="
> gmp
> +le
use skip_bits when want to skip some bits.
Signed-off-by: Jun Zhao
---
libavcodec/hevc_ps.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index bc5406b..116d938 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Wednesday, July 11, 2018 3:10 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] lavfi/opencl: add macro for opencl
> error handling.
>
> On
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Danil Iashchenko
> Sent: Thursday, July 12, 2018 7:02 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Danil Iashchenko
> Subject: [FFmpeg-devel] [PATCH] lavfi/convolution_opencl: implement
> CL_FAIL_
Sorry I probably confused you a little bit. I was not suggesting removing
anything. I tried to convince you that
there is some issue with the bitrate calculation.
From your original comments:
> This changes the printed values
> ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -qscale 2 -vframes 3 -an
Is this the latest/correct patch series for these things? I saw some
other patches conflicted with Marton's work
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hey Thomas,
On Thu, Jul 12, 2018 at 12:29 PM, Tomas Härdin wrote:
> Is this the latest/correct patch series for these things? I saw some
> other patches conflicted with Marton's work
>
Yes, the conflicts were on the demuxer side
--
Baptiste
___
ffmp
2018-07-12 20:56 GMT+02:00, Wang Cao :
> After my change:
>
>> frame=3 fps=0.0 q=2.0 Lsize= 51kB time=00:00:00.12
>> bitrate=3495.7kbits/s speed= 12x
>
> Before my change(master branch)
>
>> frame=3 fps=0.0 q=2.0 Lsize= 57kB time=00:00:00.12
>> bitrate=3884.7kbits/s speed=11.2x
As explained in https://ffmpeg.org/ffmpeg-codecs.html#Codec-Options :
Sometimes, a global option may only affect a specific kind of codec,
and may be nonsensical or ignored by another, so you need to be aware
of the meaning of the specified options.
As far as I can tell, there is an effort to mov
Switch to use CL_FAIL_ON_ERROR for error handling
---
>Hi Danil,
>The patch looks good, But I think it would be more proper to use a title like
>"switch to use CL_FAIL_ON_ERROR " or "use CL_FAIL_ON_ERROR for error handling".
>Ruiling
Hi!
Changed title to a proper one.
Thanks!
Danil.
libav
On 12/07/18 23:20, Danil Iashchenko wrote:
> Switch to use CL_FAIL_ON_ERROR for error handling
>
> ---
>
>> Hi Danil,
>
>> The patch looks good, But I think it would be more proper to use a title
>> like "switch to use CL_FAIL_ON_ERROR " or "use CL_FAIL_ON_ERROR for error
>> handling".
>
>> R
On Thu, Jul 12, 2018 at 12:10:22AM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch silences a warning about an unused variable for the
> default compilation.
>
> Please comment, Carl Eugen
> h263dec.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
> 033e73b13321e415b275c02
2018-07-13 0:58 GMT+02:00, Michael Niedermayer :
> On Thu, Jul 12, 2018 at 12:10:22AM +0200, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch silences a warning about an unused variable for the
>> default compilation.
>>
>> Please comment, Carl Eugen
>
>> h263dec.c |3 +--
>> 1 file changed
On Tue, Jul 10, 2018 at 10:34:51AM +0100, Marcin Gorzel wrote:
> Hi Michael,
>
> I think I know where the misunderstanding could be.
>
> The main changes in my patch are:
>
> rematrix.c:389 and rematrix_int.c:36:
>
> Before:
> int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout)
>
>
On Mon, Jul 09, 2018 at 04:48:02PM +0100, Marcin Gorzel wrote:
> Rematrixing supports up to 64 channels but there is only a limited number of
> channel layouts defined. Currently, in/out channel count is obtained from the
> channel layout so if the channel layout is undefined (e.g. for 9, 10, 11
On Thu, Jul 12, 2018 at 09:30:25AM +0200, Karsten Otto wrote:
> This fixes the check for the reserved MPEG audio version ID,
> used to detect an invalid frame header.
> ---
> libavcodec/mpegaudiodecheader.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
will apply
thx
[...]
--
Michael
>
> I believe users will expect that "size" shows the file size, especially
> since this was done for more than a decade.
If this is the convention, I believe it should be kept as it was. On the
other hand, I believe
"bitrate" should be calculated through stream size not the file size.
On Thu, Ju
The attached patch adds parsing for WebM encryption info into the
AVEncryptionInfo side-data. The AVEncryptionInitInfo will be handled
in another patch.
Spec: https://www.webmproject.org/docs/webm-encryption/
I am currently seeing a problem with this when using Opus audio. In
read_frame_interna
On Wed, Jul 11, 2018 at 11:53:25PM +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
Signed-off-by: Jacob Trimble
---
libavformat/matroskadec.c | 43 +--
1 file changed, 32 insertions(+), 11 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 1ded431b80..bfef329e59 100644
--- a/libavformat/matroskadec.c
+++ b/
On Thu, Jul 12, 2018 at 10:59:44AM -0300, James Almer wrote:
> On 7/12/2018 8:26 AM, Michael Niedermayer wrote:
> > On Mon, Jul 09, 2018 at 03:26:54PM -0300, James Almer wrote:
> >> Signed-off-by: James Almer
> >> ---
> >> ff_av1_filter_obus() could eventually be replaced by an autoinserted
> >> f
On Thu, Jul 12, 2018 at 04:31:11PM -0700, Wang Cao wrote:
> >
> > I believe users will expect that "size" shows the file size, especially
> > since this was done for more than a decade.
>
> If this is the convention, I believe it should be kept as it was. On the
> other hand, I believe
> "bitrate"
On 7/12/2018 9:29 PM, Michael Niedermayer wrote:
> On Thu, Jul 12, 2018 at 10:59:44AM -0300, James Almer wrote:
>> On 7/12/2018 8:26 AM, Michael Niedermayer wrote:
>>> On Mon, Jul 09, 2018 at 03:26:54PM -0300, James Almer wrote:
Signed-off-by: James Almer
---
ff_av1_filter_obus() co
On Thu, Jul 12, 2018 at 11:29 PM, Moritz Barsnick wrote:
> > +#define LANCZOS_RESOLUTION 256
>
> > +av_log(ctx, AV_LOG_INFO, "Using camera %s\n",
> lensfun->camera->Model);
> [...]
> > +av_log(ctx, AV_LOG_FATAL, "Failed to find camera in lensfun
> database\n");
>
> If you're loggi
On 10-07-2018 03:31 PM, Gyan Doshi wrote:
Test command:
ffplay -f lavfi -i "color,\
drawtext=fontfile='arial.ttf':fontcolor=white:fontsize=H/5:\
text='A string of characters':\
box=1:boxcolor=green:boxborderw=5:\
x='w-w*t/5':y=-th+h*t/10"
Pushed as 1a31c2b5df1179fdc1b8e84c8fa89d853e517309
___
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,
>> Tested on l
55 matches
Mail list logo
