On Fri, Jul 17, 2020 at 02:25:24PM -0700, Yongle Lin wrote:
> On Wed, Jul 15, 2020 at 4:13 PM Mark Thompson wrote:
>
> > On 15/07/2020 18:43, Yongle Lin wrote:
> > > add block type field to AVVideoBlockParams so we could either export or
> > visualize it later.
> > > ---
> > > libavutil/video_e
gcc warning: assignment from incompatible pointer type.
---
libavcodec/mips/h264dsp_mips.h | 24 +--
libavcodec/mips/h264dsp_msa.c | 94 ++
2 files changed, 62 insertions(+), 56 deletions(-)
diff --git a/libavcodec/mips/h264dsp_mips.h b/libavcodec/
On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
On Fri, Jul 17, 2020 at 07:13:28PM +0200, Marton Balint wrote:
On Fri, 17 Jul 2020, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> In SMPTE ST 12-1: 2014 Sec 12.2, we need to mark the frame flag if the frame rate > 30FPS to
> avoi
On 7/17/20, Steinar H. Gunderson wrote:
> On Sun, Jul 12, 2020 at 01:01:07PM +0200, Paul B Mahol wrote:
>> +@section rblur
>> +Apply Radial blur filter.
>
> I tried this; it looks very aliased and absolutely not like what I'd expect
> from a
> radial blur at all.
>
> $ wget
> https://upload.wiki
On Sat, Jul 18, 2020 at 10:17:27AM +0200, Paul B Mahol wrote:
>> https://storage.sesse.net/ffmpeg-radialblur.png
> You are deeply confused, filters are working just fine.
The above picture pretty clearly shows otherwise...? Could you tell me where
my confusion would lie?
/* Steinar */
--
Homep
On 7/18/20, Steinar H. Gunderson wrote:
> On Sat, Jul 18, 2020 at 10:17:27AM +0200, Paul B Mahol wrote:
>>> https://storage.sesse.net/ffmpeg-radialblur.png
>> You are deeply confused, filters are working just fine.
>
> The above picture pretty clearly shows otherwise...? Could you tell me where
On Sat, Jul 18, 2020 at 10:28:21AM +0200, Paul B Mahol wrote:
>> The above picture pretty clearly shows otherwise...? Could you tell me where
>> my confusion would lie?
> The filter option amount/angle set is very small.
It's the default value. Could you recommend a command line?
/* Steinar */
--
On 7/18/20, Steinar H. Gunderson wrote:
> On Sat, Jul 18, 2020 at 10:28:21AM +0200, Paul B Mahol wrote:
>>> The above picture pretty clearly shows otherwise...? Could you tell me
>>> where
>>> my confusion would lie?
>> The filter option amount/angle set is very small.
>
> It's the default value.
On Wed, 08 Jul 2020 12:54:46 +
"Zane van Iperen" wrote:
>
> v6: [8]
> * split out header and extradata fixes
> * add more-descriptive commit messages
> * fix bit_rate overflow
>
Will rebase and push in the next few days if no objections.
___
ffmp
On Fri, Jul 17, 2020 at 09:41:20PM +0200, Steinar H. Gunderson wrote:
> Change BitBuf into uint64_t on all supported 64-bit platforms.
> This means we need to flush the buffer less often, which is a
> significant speed win. 32-bit platforms are unchanged.
> Output bitstream is the same.
>
> All AP
On Sat, Jul 18, 2020 at 11:06:17AM +0200, Paul B Mahol wrote:
The above picture pretty clearly shows otherwise...? Could you tell me
where my confusion would lie?
>>> The filter option amount/angle set is very small.
>> It's the default value. Could you recommend a command line?
> Unless
On 7/18/20, Steinar H. Gunderson wrote:
> On Sat, Jul 18, 2020 at 11:06:17AM +0200, Paul B Mahol wrote:
> The above picture pretty clearly shows otherwise...? Could you tell me
> where my confusion would lie?
The filter option amount/angle set is very small.
>>> It's the default value
On Sat, Jul 18, 2020 at 12:53:18PM +0200, Paul B Mahol wrote:
> Nope, algorithm is just fine. You are interpreting results wrongly.
If you are not willing to tell me what is wrong with my interpretation
(outside “you are using the wrong parameters, and I won't tell you what the
right parameters ar
On Sat, Jul 18, 2020 at 11:53:44AM +0200, Michael Niedermayer wrote:
>> +#if ARCH_AARCH64 || ARCH_IA64 || ARCH_MIPS64 || ARCH_SPARC64 || ARCH_X86_64
> this needs a #include "config.h" or something equivalent
Sounds right, will fix.
/* Steinar */
--
Homepage: https://www.sesse.net/
__
From: Gautam Ramakrishnan
This patch adds support for PPM marker for JPEG2000
decoder. It allows the samples p1_03.j2k and p1_05.j2k
to be decoded.
---
libavcodec/jpeg2000dec.c | 111 +++
1 file changed, 101 insertions(+), 10 deletions(-)
diff --git a/libavco
On 7/18/20, Steinar H. Gunderson wrote:
> On Sat, Jul 18, 2020 at 12:53:18PM +0200, Paul B Mahol wrote:
>> Nope, algorithm is just fine. You are interpreting results wrongly.
>
> If you are not willing to tell me what is wrong with my interpretation
> (outside “you are using the wrong parameters,
On Fri, Jul 17, 2020 at 09:41:19PM +0200, Steinar H. Gunderson wrote:
> Preparatory patch for making the bit buffer different size on different
> platforms; make a typedef and make all the hardcoded sizes into expressions
> deriving from this size.
>
> No functional change; generated assembler is
Am Fr., 17. Juli 2020 um 21:41 Uhr schrieb Steinar H. Gunderson
:
> +#if ARCH_AARCH64 || ARCH_IA64 || ARCH_MIPS64 || ARCH_SPARC64 || ARCH_X86_64
I suggest to only do this for the platforms that you actually tested.
> +typedef uint64_t BitBuf;
> +#define AV_WBBUF AV_WB64
> +#define AV_WLBUF AV_WL
From: Jun Zhao
remove the timeout option docs part for HTTP protocol and add
auth_type option part.
Signed-off-by: Jun Zhao
---
doc/protocols.texi | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 64ad
From: Jun Zhao
Enable the custom callback in sub-demuxer
Signed-off-by: Jun Zhao
---
libavformat/hls.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index ba17c4e..cf0b71d 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1984,6 +1984,7 @@ s
From: Gautam Ramakrishnan
The codeblock decoder checks whether the mqc decoder
has decoded the right number of bytes. However, this
check does not account for the fact that the mqc encoder's
flush routine adds 2 bytes of data which does not have to be
read by the decoder. The check is modified to
From: Jun Zhao
Enable the custom callback in sub-demuxer
Signed-off-by: Jun Zhao
---
libavformat/dashdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 694782c..c5a5ff6 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@
From: Gautam Ramakrishnan
The JPEG2000 standard reserves marker values 0xFF30
to 0xFF3F to be used as parameterless markers. This
patch adds support to decode codestream with such
markers. This allows decoding of p0_02.j2k.
---
libavcodec/jpeg2000dec.c | 3 ++-
1 file changed, 2 insertions(+), 1
From: Gautam Ramakrishnan
The codeblock decoder checks whether the mqc decoder
has decoded the right number of bytes. However, this
check does not account for the fact that the mqc encoder's
flush routine adds 2 bytes of data which does not have to be
read by the decoder. The check is modified to
From: Gautam Ramakrishnan
This patch adds support for PPM marker for JPEG2000
decoder. It allows the samples p1_03.j2k and p1_05.j2k
to be decoded.
---
libavcodec/jpeg2000dec.c | 111 +++
1 file changed, 101 insertions(+), 10 deletions(-)
diff --git a/libavco
On Thu, Jul 16, 2020 at 9:35 AM myp...@gmail.com wrote:
>
> On Tue, Jul 14, 2020 at 9:47 PM Moritz Barsnick wrote:
> >
> > On Sun, Jul 12, 2020 at 22:44:46 +0800, myp...@gmail.com wrote:
> > > Maybe I give an inaccurate description in the commit message, in fact,
> > > libsrt 1.4.1 remove the SRT
On Sat, Jul 18, 2020 at 09:44:03AM +0200, Marton Balint wrote:
>
>
> On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
>
> > On Fri, Jul 17, 2020 at 07:13:28PM +0200, Marton Balint wrote:
> > >
> > >
> > > On Fri, 17 Jul 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > From: Limin Wang
> >
On Sat, Jul 18, 2020 at 01:31:49PM +0200, Paul B Mahol wrote:
>> In short, this patch has:
>>
>> - An unusually slow algorithm (sin, cos, atan, division; all per-pixel).
> This is actually good.
Is it good that it's slow? Or do you mean that the algorithm isn't actually
slow?
> Performance is no
On Sat, Jul 18, 2020 at 01:53:36PM +0200, Carl Eugen Hoyos wrote:
>> +#if ARCH_AARCH64 || ARCH_IA64 || ARCH_MIPS64 || ARCH_SPARC64 || ARCH_X86_64
> I suggest to only do this for the platforms that you actually tested.
OK. If so, that's x86-64 only.
/* Steinar */
--
Homepage: https://www.sesse.ne
On Sat, Jul 18, 2020 at 01:34:55PM +0200, Michael Niedermayer wrote:
> this from libavcodec/mpegvideo_enc.c
> set_put_bits_buffer_size(&s->pb,
> FFMIN(s->thread_context[i]->pb.buf_end - s->pb.buf, INT_MAX/8-32));
> needs to be updated too
OK. Including in v3, sending shortly.
/* Ste
Change BitBuf into uint64_t on 64-bit x86. This means we need to flush the
buffer less often, which is a significant speed win. All other platforms,
including all 32-bit ones, are unchanged. Output bitstream is the same.
All API constraints are kept in place, e.g., you still cannot put_bits()
more
Preparatory patch for making the bit buffer different size on different
platforms; make a typedef and make all the hardcoded sizes into expressions
deriving from this size.
No functional change; generated assembler is near-identical.
---
libavcodec/mpegvideo_enc.c | 2 +-
libavcodec/put_bits.h
On 7/18/20, Steinar H. Gunderson wrote:
> On Sat, Jul 18, 2020 at 01:31:49PM +0200, Paul B Mahol wrote:
>>> In short, this patch has:
>>>
>>> - An unusually slow algorithm (sin, cos, atan, division; all per-pixel).
>> This is actually good.
>
> Is it good that it's slow? Or do you mean that the a
On Sat, Jul 18, 2020 at 04:59:21PM +0200, Paul B Mahol wrote:
>> Is it good that it's slow? Or do you mean that the algorithm isn't actually
>> slow?
> It is pretty fast here.
Could you quantify what you mean by “pretty fast”? (Is it fast also measured
in CPU time, or only if you have a bunch of c
On 7/18/20, Steinar H. Gunderson wrote:
> On Sat, Jul 18, 2020 at 04:59:21PM +0200, Paul B Mahol wrote:
>>> Is it good that it's slow? Or do you mean that the algorithm isn't
>>> actually
>>> slow?
>> It is pretty fast here.
>
> Could you quantify what you mean by “pretty fast”? (Is it fast also m
On 18-07-2020 05:26 pm, Jun Zhao wrote:
From: Jun Zhao
remove the timeout option docs part for HTTP protocol and add
auth_type option part.
Signed-off-by: Jun Zhao
---
doc/protocols.texi | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/doc/
To enable runtime detection for MIPS, we need to refine ffbuild
part to support buildding these feature together.
Firstly, we fixed configure, let it probe native ability of toolchain
to decide wether a feature can to be enabled, also clearly marked
the conflictions between loongson2 & loongson3 a
Add MMI & MSA runtime detection for MIPS.
Basically there are two code pathes. For systems that
natively support CPUCFG instruction or kernel emulated
that instruction, we'll sense this feature from HWCAP and
report the flags according to values grab from CPUCFG. For
systems that have no CPUCFG (o
This series adds MIPS MSA & MMI runtime detection support
Please review.
Thanks!
v2:
- Add CPUCFG support.
- Add "-mloongson-ext" to MMIFLAGS for Loongson-3 as well. (Loongson2F don't
need this flag)
v3:
- Address reveiew suggestions from Shiyou Yin and Weixi Gu.
v4:
- Disable DSP for
GCC complains about them.
Signed-off-by: Jiaxun Yang
---
libavcodec/mips/h264dsp_mips.h | 18 +-
libavcodec/mips/h264dsp_mmi.c | 18 +-
libavcodec/mips/xvid_idct_mmi.c | 4 ++--
libavcodec/mips/xvididct_mips.h | 4 ++--
4 files changed, 22 insertions(+), 22 d
That helper grab from kernel code can allow us to inline
newer instructions (not implemented by the assembler) in
a elegant manner.
Signed-off-by: Jiaxun Yang
---
libavutil/mips/asmdefs.h | 42
1 file changed, 42 insertions(+)
diff --git a/libavutil/mips
GCC complains:
warning: listing the stack pointer register ‘$29’ in a clobber
list is deprecated [-Wdeprecated]
Actually stack pointer was restored at the end of the inline assembly
so there is no reason to add it to the clobber list.
Also use $sp insted of $29 to make our intention much more cle
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 46
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/vf_rblur.c | 560 +++
4 files changed, 610 insertions(+)
create mode 100644 libavfilter/vf_rblur.c
diff --gi
Greetings!
unconditional AVFMT_TS_DISCONT also helps to survive when pts rollover in
mpegts occurs.
seems like this patch will break again reading long-lasting hls.
--
Aleksey Skripka
> On 17 Jul 2020, at 04:09, Dongwon Kim wrote:
>
> I modified setting AVFMT_TS_DISCONT flag on HLS input f
On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
On Sat, Jul 18, 2020 at 09:44:03AM +0200, Marton Balint wrote:
On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
> On Fri, Jul 17, 2020 at 07:13:28PM +0200, Marton Balint wrote:
> >
> >
> > On Fri, 17 Jul 2020, lance.lmw...@gmail.com wr
Am Di., 9. Juni 2020 um 20:25 Uhr schrieb Carl Eugen Hoyos :
>
> Am Di., 9. Juni 2020 um 19:12 Uhr schrieb Gautam Ramakrishnan
> :
> >
> > On Tue, Jun 9, 2020 at 10:24 PM Carl Eugen Hoyos wrote:
> > >
> > > Am Di., 9. Juni 2020 um 14:07 Uhr schrieb :
> > > >
> > > > From: Gautam Ramakrishnan
> >
Threaded input can increase smoothness of e.g. x11grab significantly. Before
this patch, in order to activate threaded input the user had to specify a
"dummy" additional input, with this change it is no longer required.
Signed-off-by: Marton Balint
---
doc/ffmpeg.texi | 5 +++--
fftools/ffm
Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka
'int'); cast to an unsigned type to negate this value to itself
Fixes:
23760/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-604209011412172
Found-by: continuous fuzzing process
https://github.com/google/
Fixes: Timeout (169sec -> 9sec)
Fixes:
23745/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQA_fuzzer-5638172179693568
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
Also query time only once, not for every variant stream, otherwise variant
streams might get a slightly different initial program date time. And we can
set this unconditionally because HLS_PROGRAM_DATE_TIME flag is checked
elsewhere.
Signed-off-by: Marton Balint
---
libavformat/hlsenc.c | 8 ++--
On Sat, Jul 18, 2020 at 08:38:16PM +0200, Marton Balint wrote:
>
>
> On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
>
> > On Sat, Jul 18, 2020 at 09:44:03AM +0200, Marton Balint wrote:
> > >
> > >
> > > On Sat, 18 Jul 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > On Fri, Jul 17, 2020
On Sat, Jul 18, 2020 at 06:46:22PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> This patch adds support for PPM marker for JPEG2000
> decoder. It allows the samples p1_03.j2k and p1_05.j2k
> to be decoded.
> ---
> libavcodec/jpeg2000dec.c | 111 +
On Sat, Jul 18, 2020 at 03:30:49PM +0800, Shiyou Yin wrote:
> gcc warning: assignment from incompatible pointer type.
> ---
> libavcodec/mips/h264dsp_mips.h | 24 +--
> libavcodec/mips/h264dsp_msa.c | 94
> ++
> 2 files changed, 62 insertions(+), 5
On Sat, Jul 18, 2020 at 06:46:21PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> The JPEG2000 standard reserves marker values 0xFF30
> to 0xFF3F to be used as parameterless markers. This
> patch adds support to decode codestream with such
> markers. This allows decoding of p0
On Sat, Jul 18, 2020 at 04:53:02PM +0200, Steinar H. Gunderson wrote:
> Preparatory patch for making the bit buffer different size on different
> platforms; make a typedef and make all the hardcoded sizes into expressions
> deriving from this size.
>
> No functional change; generated assembler is
55 matches
Mail list logo
