On Sun, Jan 27, 2019 at 10:51:12 -0500, agrecascino...@gmail.com wrote:
> Subject: [FFmpeg-devel] [PATCH] fix sidx size being doubled in offset. fixes
> an issue where if the video size was very specific, ffmpeg would hang from
> not filling the
> sidx_pts for all streams, due to not rea
On Thu, Jan 31, 2019 at 10:16:00 +0100, Moritz Barsnick wrote:
> Please split your commit message into a leading line, an empty line,
> and then the explanatory text.
Forget this, I didn't see V3 of your patch.
D'uh,
Moritz
___
ffmpeg-devel mailing list
30.01.19 21:42 - jannis_wth:
> 30.01.19 21:02 - James Almer:
>> I guess avctx->internal->last_pkt_props could work for this, but it may
>> not be consistent across decoders.
>
> avctx->internal->last_pkt_props stores the properties of the last passed
> packet, and does not get updated on decoding
Improves speed for 780/clusterfuzz-testcase-6393552642768896 from 95 sec to 60
sec
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/gifdec.c | 6 +-
1 file changed, 1 insertion(+), 5 deleti
This function is useful in more cases than just imgutils
Signed-off-by: Michael Niedermayer
---
doc/APIchanges | 3 +++
libavutil/imgutils.c | 8 ++--
libavutil/imgutils.h | 10 ++
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
On Sun, 20 Jan 2019 at 15:16, Tomas Härdin wrote:
> > Hi. Just to say, I tried setting up additional score_tabs for the
> > bottom/right partial blocks. Unfortunately, after implementing it and
> > ironing out the bugs, the new score tables actually caused a slight
> > increase in file size!
>
sorry i sent my first two emails about 4 days ago and after waiting a few days
i just decided to subscribe and resubmit my patches.
i think they just got through now.
Sent from my iPhone
> On Jan 31, 2019, at 4:16 AM, Moritz Barsnick wrote:
>
>> On Thu, Jan 31, 2019 at 10:16:00 +0100, Moritz B
Remove the pdiff_lut_scale in nlmeans, when search the weight_luttable
in nlmeans_slices(), the old way need to the float-point arithmetic
using pdiff_lut_scale. This change will avoid using pdiff_lut_scale
in the weight_lut table search, it's will improve the performance about
12%. (1080P size pic
On Thu, Jan 31, 2019 at 14:09:01 +0100, Michael Niedermayer wrote:
> This function is useful in more cases than just imgutils
[...]
> libavutil/imgutils.c | 8 ++--
> libavutil/imgutils.h | 10 ++
If so, couldn't it be placed in libavutil/mem.[ch]? It seems
appropriate.
Moritz
__
tor 2019-01-31 klockan 13:31 + skrev Matthew Fearnley:
> > On Sun, 20 Jan 2019 at 15:16, Tomas Härdin wrote:
>
> > > Hi. Just to say, I tried setting up additional score_tabs for the
> > > bottom/right partial blocks. Unfortunately, after implementing it and
> > > ironing out the bugs, the
Signed-off-by: Mateusz Brzostek
---
libavcodec/rscc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/rscc.c b/libavcodec/rscc.c
index e4b51973d8..7d4e842cd3 100644
--- a/libavcodec/rscc.c
+++ b/libavcodec/rscc.c
@@ -64,7 +64,7 @@ typedef struct RsccContext {
/
On 1/31/2019 12:36 PM, Mateusz wrote:
> Signed-off-by: Mateusz Brzostek
> ---
> libavcodec/rscc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/rscc.c b/libavcodec/rscc.c
> index e4b51973d8..7d4e842cd3 100644
> --- a/libavcodec/rscc.c
> +++ b/libavcodec/rscc
On Sun, Jan 27, 2019 at 01:44:13AM +0100, Michael Niedermayer wrote:
> No speed difference, or slightly faster (the difference is too small so it
> may be noise
> that this appears faster)
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ffv1.h | 4 +---
> 1 file changed, 1 insertion(+
On Thu, Jan 31, 2019 at 12:49:22PM -0300, James Almer wrote:
> On 1/31/2019 12:36 PM, Mateusz wrote:
> > Signed-off-by: Mateusz Brzostek
> > ---
> > libavcodec/rscc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/rscc.c b/libavcodec/rscc.c
> > index e4
From a03e88da9deb21b800714b695b4d99edb54397ff Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Thu, 31 Jan 2019 21:44:19 +0530
Subject: [PATCH] web/consulting: add myself
Signed-off-by: Gyan Doshi
---
src/consulting | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/consult
Partial port of the ARM Neon for aarch64.
Benchmarks from fate:
benchmarking with Linux Perf Monitoring API
nop: 58.6
checkasm: using random seed 1760970128
NEON:
- vp8dsp.idct [OK]
- vp8dsp.mc [OK]
- vp8dsp.loopfilter [OK]
checkasm: all 21 tests passed
vp8_idct_add_c: 201.6
vp8_
On Sat, Jan 19, 2019 at 12:00:48AM +0100, Michael Niedermayer wrote:
> Suggested-by: BBB
> Signed-off-by: Michael Niedermayer
> ---
> doc/APIchanges | 3 +++
> libavcodec/avcodec.h | 8
> libavcodec/options_table.h | 1 +
> tests/ref/fate/a
On Thu, Jan 31, 2019 at 03:36:56PM +0800, Decai Lin wrote:
> This is robust for some corner case there is incorrect list1 count
> in pps header, but it's a P slice and can be decoded well.
please provide a sample h264 video that needs this
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B
On 1/31/2019 1:25 PM, Michael Niedermayer wrote:
> On Sat, Jan 19, 2019 at 12:00:48AM +0100, Michael Niedermayer wrote:
>> Suggested-by: BBB
>> Signed-off-by: Michael Niedermayer
>> ---
>> doc/APIchanges | 3 +++
>> libavcodec/avcodec.h | 8
>> libav
On Sun, Jan 27, 2019 at 11:08:29AM -0500, agrecascino...@gmail.com wrote:
> From: mptcultist
>
> fixes an issue where if the video size was very specific, ffmpeg would hang
> from not filling the sidx_pts for all streams, due to not reading the last
> sidx lump. for #7572
>
> ---
> libavforma
---
INSTALL.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/INSTALL.md b/INSTALL.md
index 5db912231c..3b220bc6ff 100644
--- a/INSTALL.md
+++ b/INSTALL.md
@@ -1,4 +1,4 @@
-#Installing FFmpeg:
+## Installing FFmpeg
1. Type `./configure` to create the configuration. A list o
On Thu, 31 Jan 2019 21:57:38 +0530
Gyan wrote:
> From a03e88da9deb21b800714b695b4d99edb54397ff Mon Sep 17 00:00:00 2001
> From: Gyan Doshi
> Date: Thu, 31 Jan 2019 21:44:19 +0530
> Subject: [PATCH] web/consulting: add myself
>
> Signed-off-by: Gyan Doshi
> ---
> src/consulting | 13 ++
2019-01-31 17:04 GMT+01:00, Magnus Röös :
> Partial port of the ARM Neon for aarch64.
Reproduced a >20% speedup for fate-vp8 and applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmp
On Thu, 31 Jan 2019 11:46:49 -0500
Justin Bull wrote:
> ---
> INSTALL.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/INSTALL.md b/INSTALL.md
> index 5db912231c..3b220bc6ff 100644
> --- a/INSTALL.md
> +++ b/INSTALL.md
> @@ -1,4 +1,4 @@
> -#Installing FFmpeg:
> +## In
2019-01-31 14:55 GMT+01:00, Jun Zhao :
> Remove the pdiff_lut_scale in nlmeans, when search the weight_luttable
> in nlmeans_slices(), the old way need to the float-point arithmetic
> using pdiff_lut_scale. This change will avoid using pdiff_lut_scale
> in the weight_lut table search, it's will imp
Hi!
Attached patch persistently uses "const" for AVInputFormat pointer
after the next version bump.
Please comment, Carl Eugen
From 95fc17cc1a82ea6d2e9e96932e145cc2b4c210b6 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 31 Jan 2019 21:40:58 +0100
Subject: [PATCH] lavf: Constify AVInp
2019-01-31 21:43 GMT+01:00, Carl Eugen Hoyos :
> Hi!
>
> Attached patch persistently uses "const" for AVInputFormat pointer
> after the next version bump.
Now with an actually working version.
Please comment, Carl Eugen
From f383a7f914b2c7240378b404d529a7d73c68941b Mon Sep 17 00:00:00 2001
From:
On 1/31/2019 5:54 PM, Carl Eugen Hoyos wrote:
> 2019-01-31 21:43 GMT+01:00, Carl Eugen Hoyos :
>> Hi!
>>
>> Attached patch persistently uses "const" for AVInputFormat pointer
>> after the next version bump.
> Now with an actually working version.
>
> Please comment, Carl Eugen
>
>
> 0001-lavf-Co
On Wed, Jan 30, 2019 at 5:43 PM James Almer wrote:
> On 1/30/2019 10:20 PM, Chris Cunningham wrote:
> >>
> And this definitely means there's a bug elsewhere. This parser should
> have not been used for codecs ids other than GSM and GSM_MS. That's
> precisely what this assert() is m
Found with the help of codespell-1.14.0.
Signed-off-by: Moritz Barsnick
---
doc/bitstream_filters.texi | 2 +-
doc/codecs.texi| 2 +-
doc/filters.texi | 24
doc/formats.texi | 2 +-
doc/general.texi | 8
doc/muxers.t
On Thu, Jan 31, 2019, at 2:23 PM, Moritz Barsnick wrote:
> Found with the help of codespell-1.14.0.
>
> Signed-off-by: Moritz Barsnick
> ---
> doc/bitstream_filters.texi | 2 +-
> doc/codecs.texi| 2 +-
> doc/filters.texi | 24
> doc/formats.texi
On Thu, Jan 31, 2019 at 09:54:14PM +0100, Carl Eugen Hoyos wrote:
> 2019-01-31 21:43 GMT+01:00, Carl Eugen Hoyos :
> > Hi!
> >
> > Attached patch persistently uses "const" for AVInputFormat pointer
> > after the next version bump.
>
> Now with an actually working version.
>
> Please comment, Carl
If a hardware encoder is used, the pixel format may be a hardware pixel format.
This leads to invalid VPCC atom being written, due to depth of hardware pixel
formats being 0.
To work around this, fallback on bits_per_raw_sample.
Signed-off-by: Nikolas Bowe
---
libavcodec/vaapi_encode.c | 2 +-
Bad content may contain stsc boxes with a first_chunk index that
exceeds stco.entries (chunk_count).
mov_get_stsc_samples now checks for this and returns 0 when
values are invalid.
Also updates MOVStsc to use unsigned ints, per spec.
---
libavformat/isom.h | 6 +++---
libavformat/mov.c | 4 ++--
Some extra context: this remedies some bad math that otherwise triggers an
abort near the bottom of mov_seek_stream().
My first thought on seeing this was we should probably be
returning AVERROR_INVALIDDATA somewhere. The stsc and stco boxes aren't
agreeing (stco says no chunks, stsc.first points
On Fri, Feb 1, 2019 at 3:57 AM Carl Eugen Hoyos wrote:
>
> 2019-01-31 14:55 GMT+01:00, Jun Zhao :
> > Remove the pdiff_lut_scale in nlmeans, when search the weight_luttable
> > in nlmeans_slices(), the old way need to the float-point arithmetic
> > using pdiff_lut_scale. This change will avoid usi
Remove the pdiff_lut_scale in nlmeans and increase weight_lut table size
from 2^9 to 80, this change will avoid using pdiff_lut_scale in
nlmeans_slice() for weight_lut table search, it's will improve the
performance about 12%. (in 1080P size picture case).
Use the profiling command like:
perf
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Michael Niedermayer
> Sent: 2019年2月1日 1:12
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: no need check ref
> list1 for P slices
Optimize put_hevc_qpel_bi_h_8 with mmi in the case width=4/8/12/16/24/32/48/64.
This optimization improved HEVC decoding performance 2.1%(2.34x to 2.39x,
tested on loongson 3A3000).
---
libavcodec/mips/hevcdsp_init_mips.c | 9 +++
libavcodec/mips/hevcdsp_mips.h | 9 +++
libavcodec/mips/h
Optimize put_hevc_qpel_uni_hv_8 with mmi in the case
width=4/8/12/16/24/32/48/64.
This optimization improved HEVC decoding performance 2.7%(2.24x to 2.30x,
tested on loongson 3A3000).
---
libavcodec/mips/hevcdsp_init_mips.c | 9 ++
libavcodec/mips/hevcdsp_mips.h | 21
libavcodec/mip
Optimize put_hevc_epel_bi_hv_8 with mmi in the case width=4/8/12/16/24/32.
This optimization improved HEVC decoding performance 1.7%(2.30x to 2.34x,
tested on loongson 3A3000).
---
libavcodec/mips/hevcdsp_init_mips.c | 7 ++
libavcodec/mips/hevcdsp_mips.h | 6 ++
libavcodec/mips/hevcdsp_
document ranges and defaults for nlmeans options
Signed-off-by: Jun Zhao
---
doc/filters.texi |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index fc98323..d588315 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12296,10
Optimize put_hevc_qpel_h_8 with mmi in the case width=4/8/12/16/24/32/48/64.
This optimization improved HEVC decoding performance 2%(2.39x to 2.44x, tested
on loongson 3A3000).
---
libavcodec/mips/hevcdsp_init_mips.c | 9
libavcodec/mips/hevcdsp_mips.h | 9
libavcodec/mips/hevcds
On Fri, Feb 1, 2019 at 1:28 PM Lin, Decai wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Michael Niedermayer
> > Sent: 2019年2月1日 1:12
> > To: FFmpeg development discussions and patches
> >
> > Subject: Re: [FFmpeg-devel
44 matches
Mail list logo
