>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org]
>On Behalf Of gxw
>Sent: Thursday, February 21, 2019 8:39 PM
>To: ffmpeg-devel@ffmpeg.org
>Cc: gxw
>Subject: [FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] mmi optimizations
>for VP9
Fixes: Timeout (27 sec -> 39 milli sec)
Fixes:
13151/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QPEG_fuzzer-5717536023248896
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/qpeg.c | 2
Hi Marton!
> Am 23.02.2019 um 20:36 schrieb Marton Balint :
>
> This improves compatibility with some consumer TVs which apparently either
> search a HEVC descriptor (which our mpegts muxer can't generate) or a format
> specifier.
>
> Since the HEVC format specifier is not registered (but used
On Thu, Feb 21, 2019 at 12:13:50PM +0100, Paul B Mahol wrote:
> On 2/21/19, Michael Niedermayer wrote:
> > Fixes: Timeout (78 sec -> 15 millisec)
> > Fixes:
> > 13147/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JV_fuzzer-5727107827630080
> >
> > Found-by: continuous fuzzing process
> >
On Fri, Feb 22, 2019 at 03:40:27PM -0500, Tristan Matthews wrote:
> fixes: https://trac.ffmpeg.org/ticket/6713
> ---
> libavformat/rtpenc_chain.c | 1 +
> 1 file changed, 1 insertion(+)
will apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you
This improves compatibility with some consumer TVs which apparently either
search a HEVC descriptor (which our mpegts muxer can't generate) or a format
specifier.
Since the HEVC format specifier is not registered (but used in the wild), it is
not written if strict_std_compliance is higher than
Signed-off-by: Marton Balint
---
libavformat/mpegtsenc.c | 50 ++---
1 file changed, 18 insertions(+), 32 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 35a72002c8..099d003f42 100644
--- a/libavformat/mpegtsenc.c
+++
Hi all
if there are no objections then ill add the following
"Certificate Authority Authorization" entry:
ffmpeg.org. IN CAA 0 issue "letsencrypt.org"
to the zonefile
This should theoretically guard against some unlikely security issues
Thanks
--
Michael GnuPG fingerprint:
On Sat, Feb 23, 2019 at 11:14:33AM +0100, Steve Lhomme wrote:
> From: Steve Lhomme
>
> ---
> libavformat/matroskadec.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
I think the commit message is a bit terse. This is not just a cosmetic
change (which one might think from
Empty edits can occur at any position within the edit list except for at
the end. Empty edits in the middle should not impact the reported stream
start_time or the video PTS adjustment, so only include empty edits at
the start of the list in empty_edits_sum_duration.
Please see attachment.
--
Hello,
Patch in attach improve prores_aw encoding speed
A basic encoding test (prores to prores)
test file 1 : 137fps -> 140fps
test file 2 : 49fps-> 54 fps
001 : Pre calc codebook switchbits, rice order, exp order and first_exp,
avoid to calc it in encode_codeword func.
002 : small code
Hello,
Patch in attach add fate test for interlace and 444 encoding
All prores_aw encoding test can be test with :
make fate-vsynth3-prores;make fate-vsynth2-prores;make
fate-vsynth1-prores;make fate-vsynth_lena-prores SAMPLES=fate-suite/;make
fate-vsynth3-prores_int;make
On 23/02/2019 00:41, Dale Curtis wrote:
Unknown length has a special encoding which is not uint64_t(-1).
Signed-off-by: Dale Curtis
---
libavformat/matroskadec.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
___
Hello,
Patch in attach, improve decoding speed of qtrle (also known as Mov
Animation)
Can't test on big endian. Test on big endian is welcome.
fate test cmd : make fate-qtrle SAMPLES=fate-suite/
32bpp :
Mainly raw : 33fps -> 40 fps
Mainly rle : 128fps -> 153 fps
24bpp:
Mainly raw :
Steve Lhomme wrote:
> libavformat/matroskadec.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
>diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>index 5aa8a105dc..0e3a6890c1 100644
Should be fine. Best regards, Reto
From: Steve Lhomme
---
libavformat/matroskadec.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 5aa8a105dc..0e3a6890c1 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -68,6
On Sat, Feb 23, 2019 at 03:22:08PM +0800, C.H.Liu wrote:
> I can’t reproduce the OOM. Is it possible the problem relate to a specific
> clip?
>
> Here is my test steps:
> 1. To ensure that it’s not affected by caches, delete all except the .git
> dir in my code dir. Then checkout again.
> 2. To
Hi,
It's possible that it fixes the issue. When I did the patch I noticed some
places used a similar value and some are using -1. I think this should be a
define (probably set to UINT64_MAX) that is used everywhere. It's just a marker
to say the length is unknown.
> On February 22, 2019 at
18 matches
Mail list logo
