Hi!
> On 9 Nov 2023, at 13:28, Anton Khirnov wrote:
>
> Quoting James Almer (2023-11-09 13:24:45)
>> Hendrik Leppkes and Reimar Döffinger are active, at least. I agree they
>> should be in the GA.
>
> Right, I did not mean to imply ALL the people in the above li
> On 26 Jul 2023, at 21:15, reimar.doeffin...@gmx.de wrote:
>
> From: Reimar Döffinger
>
> ret can be given an argument instead.
> This is also consistent with how other assembler code
> in FFmpeg does it.
Now pushed.
___
ffmp
> On 27 Jul 2023, at 19:44, Nicolas George wrote:
>
> Reimar Döffinger (12023-07-27):
>> Thanks, sent a new version with that updated, plus a fix for a typo
>> in the commit message.
>
> If it is all you have changed, then I do not think I need to look at it
>
> On 28 Jul 2023, at 12:40, Reimar Döffinger wrote:
>
>
>> On 28 Jul 2023, at 03:37, L. E. Segovia wrote:
>>
>> Updated for 6.0, any constructive feedback will be appreciated.
>
> Using #if means the code will not even be compile tested if the
> feature
> On 28 Jul 2023, at 03:37, L. E. Segovia wrote:
>
> Updated for 6.0, any constructive feedback will be appreciated.
Using #if means the code will not even be compile tested if the
feature is disabled, this makes maintenance especially of rare
features much harder (nevermind code readability).
> On 27 Jul 2023, at 19:33, Nicolas George wrote:
>
> reimar.doeffin...@gmx.de (12023-07-23):
>> From: Reimar Döffinger
>>
>> Change some internal APIs a bit to make it harder to make
>> such mistakes.
>> In particular, have the read chunk funct
> On 23 Jul 2023, at 14:00, reimar.doeffin...@gmx.de wrote:
>
> From: Reimar Döffinger
>
> Change some internal APIs a bit to make it harder to make
> such mistakes.
> In particular, have the read chunk functions return an error
> when the result is incomplete.
>
> On 26 Jul 2023, at 21:43, Martin Storsjö wrote:
>
> On Wed, 26 Jul 2023, reimar.doeffin...@gmx.de wrote:
>
>> From: Reimar Döffinger
>>
>> ret can be given an argument instead.
>> This is also consistent with how other assembler code
>> in FF
> On 27 Jul 2023, at 15:55, Rémi Denis-Courmont wrote:
>
> Hi,
>
> The use of RET vs BR also has microarchitectural side effects. AFAIU, RET
> should always be paired with an earlier BL/BLR to avoid interfering with
> branch prediction.
>
> So depending on the circumstances, either one of
Hi!
> On 24 Jun 2023, at 21:14, Andreas Rheinhardt
> wrote:
>
> Michael Niedermayer:
>> Fixes: out of array access
>> Fixes: crash-0d640731c7da52415670eb47a2af701cbe2e1a3b
>>
>> Found-by: Catena cyber
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavcodec/parser.c | 2 +-
>> 1 file
Hi Martin,
> On 10 Oct 2022, at 23:29, Martin Storsjö wrote:
>
> On Sun, 9 Oct 2022, reimar.doeffin...@gmx.de wrote:
>
>> From: Reimar Döffinger
>>
>> Currently it is done in several different ways, which
>> might cause needless dependencies or in cas
> On 9 Oct 2022, at 16:11, Rémi Denis-Courmont wrote:
>
> Le sunnuntaina 9. lokakuuta 2022, 16.14.47 EEST Reimar Döffinger a écrit :
>> Use load/store instructions that modify sp to save
>> registers to stack, like it is done for all other
>> functions.
>>
Use load/store instructions that modify sp to save
registers to stack, like it is done for all other
functions.
At least valgrind complains about the current code.
---
libavutil/aarch64/tx_float_neon.S | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
> On 26 Feb 2022, at 16:33, James Almer wrote:
>
> The module is now always compiled in.
Thanks, both patches in this series or the alternative patch are fine with me.
Only possible downside I could think of is if there is any use-case why someone
would want the matroska decoder to
> On 9 Mar 2021, at 10:44, zsugabubus
> wrote:
>
> Hi all,
>
> I was not able to find any patches or mails, only two open tickets that
> mention DRM decryption in some way:
>
> https://trac.ffmpeg.org/ticket/1793
> https://trac.ffmpeg.org/ticket/1800
>
> ...however there were no updates
>
> I have never come around to setting up postfix for forwarding mails
> externally on my current system. So, for now, I am using the second best
> solution. Please see the attachment.
Maybe not worth the effort, but FYI git can communicate directly with
a SMTP server nowadays, and msmtmp is
> On 27 Feb 2021, at 09:14, Guo, Yejun wrote:
>
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of Paul B
>> Mahol
>> Sent: 2021年2月26日 19:37
>> To: FFmpeg development discussions and patches
>> Cc: Guo, Yejun
>> Subject: Re: [FFmpeg-devel] [PATCH V3 3/5]
> On 27 Feb 2021, at 06:37, Guo, Yejun wrote:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of Reimar
>> D?ffinger
>>>
>
> For the code in this function, max length of file name is fixed, see the code
> below.
> Anyway, it still increases the on-stack variable size
> On 25 Feb 2021, at 18:52, Chad Fraleigh wrote:
>
> On 2/24/2021 10:38 PM, Guo, Yejun wrote:
>> libavdevice/v4l2.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
>> index 365bacd771..e11d10d20e 100644
>> ---
> On 25 Feb 2021, at 07:38, Guo, Yejun wrote:
> --- a/libavformat/smoothstreamingenc.c
> +++ b/libavformat/smoothstreamingenc.c
> @@ -501,7 +501,7 @@ static int ism_flush(AVFormatContext *s, int final)
>
> for (i = 0; i < s->nb_streams; i++) {
> OutputStream *os = >streams[i];
> -
Hi!
> On 24 Jan 2021, at 17:35, Andriy Gelman wrote:
>
> On Sat, 07. Nov 16:31, Andriy Gelman wrote:
>> On Sat, 31. Oct 10:17, Andriy Gelman wrote:
>>> On Fri, 16. Oct 00:02, Andriy Gelman wrote:
On Fri, 09. Oct 20:17, Andriy Gelman wrote:
> From: Chip Kerchner
>
> ---
>
Hi Martin!
> On 10 Feb 2021, at 22:53, Martin Storsjö wrote:
>
> +.macro idct_16x16 bitdepth
> +function ff_hevc_idct_16x16_\bitdepth\()_neon, export=1
> +//r0 - coeffs
> +mov x15, lr
> +
Binutils doesn't recognize "lr" as alias for x30
>>> It didn’t
> On 23 Jan 2021, at 19:35, Carl Eugen Hoyos wrote:
>
>
> New patch attached, thank you!
>
Looks good to me.
I don’t know if I didn’t test the original change properly
or if compiler behaviour has changed/is different,
but this way should be more correct either way.
Hi!
> On 23 Jan 2021, at 17:31, Carl Eugen Hoyos wrote:
> Attached patch fixes ticket #9077 for me.
>
> Please comment, Carl Eugen
> <0001-lsws-ppc-yuv2rgb-Fix-transparency-converting-from-yu.patch>
Unfortunately I can’t test anything myself anymore since
I don’t have any devices with VGA
Setting the defaults for $arch happens only later, so
the current code would not set AS correctly if --arch
was not specified on the command-line.
Fix it by adding an explicit fallback to $arch_default.
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure
> On 15 Jan 2021, at 23:55, Martin Storsjö wrote:
>
> On Tue, 12 Jan 2021, reimar.doeffin...@gmx.de wrote:
>
>> create mode 100644 libavcodec/aarch64/hevcdsp_idct_neon.S
>> create mode 100644 libavcodec/aarch64/hevcdsp_init_aarch64.c
>
> This patch fails checkasm
Fixed, one mis-translated
> On 15 Jan 2021, at 23:25, Martin Storsjö wrote:
>
> On Fri, 15 Jan 2021, reimar.doeffin...@gmx.de wrote:
>
>> From: Reimar Döffinger
>>
>> It would get immediately overridden to $cc, which in case
>> of gas-preprocessor missing would result in it t
> On 15 Jan 2021, at 22:10, Martin Storsjö wrote:
>
> On Mon, 11 Jan 2021, reimar.doeffin...@gmx.de wrote:
>
>> From: Reimar Döffinger
>>
>> Trivially expand hscale assembler to support > 8 bit formats
>> both for input and output.
>> 16-bit i
> If building with MSVC tools, yes you're right that armasm.exe/armasm64.exe
> takes a different syntax. But the gas-preprocessor tool (which is picked up
> automatically by our configure, one just needs to make sure it's available)
> handles expanding all the macros and rewriting directives
> On 12 Jan 2021, at 21:46, Lynne wrote:
>
> Jan 12, 2021, 19:28 by reimar.doeffin...@gmx.de:
>
>> It’s almost 20%. At least for this combination of
>> codec and stream a large amount of time is spend in
>> non-DSP functions, so even hand-written assembler
>> won’t give you huge gains.
>>
>
> On 12 Jan 2021, at 19:52, Soft Works wrote:
>
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> reimar.doeffin...@gmx.de
>> Sent: Sunday, January 10, 2021 5:44 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Cc: Reimar Döffinger
> On 12 Jan 2021, at 02:41, Andreas Rheinhardt
> wrote:
> Of course I am all ears for how to make it clear that someone who
> modifies the strings also needs to check the array dimensions.
I think I kind of agree with the other comments, this would/should
rather have to be something that can
>
> On 10 Jan 2021, at 19:55, Lynne wrote:
>
> Jan 10, 2021, 17:43 by reimar.doeffin...@gmx.de:
>
>> From: Reimar Döffinger
>>
>> real0m15.040s
>> user0m18.874s (80.7% of original)
>> sys 0m0.168s
>>
>
> I think I have
> On 12 Jan 2021, at 13:24, Josh Dekker wrote:
>
> Hi,
>
> On 2021-01-08 21:36, reimar.doeffin...@gmx.de wrote:
>> From: Reimar Döffinger
>> Makes SIMD-optimized 8x8 and 16x16 idcts for 8 and 10 bit depth
>> available on aarch64.
>> For a UHD HDR (10
On Sun, Jul 05, 2020 at 10:50:14PM +0200, Michael Niedermayer wrote:
> To Achieve this, we could try to
> * attract more developers doing reviews, i have generally suggested
> contributors to help review other peoples patches. Maybe i should
> take a step back and ask developers to ask
On Sun, Jul 05, 2020 at 06:18:20PM +0100, Kieran Kunhya wrote:
> On Sun, Jul 5, 2020 at 6:01 PM Kieran Kunhya wrote:
> >
> > Going back to the original point in hand.
> > Many patches aren't getting reviewed and pushed any more.
> >
> > In part this is because in 2020 whether we like it or not
for malloc failure.
Probably both ought to be changed to AVERROR(ENOMEM).
Signed-off-by: Reimar Döffinger
---
libavfilter/dnn/dnn_backend_native.c | 10 +-
libavfilter/dnn/dnn_backend_native.h | 2 ++
libavfilter/dnn/dnn_backend_native_layer_conv2d.c
for malloc failure.
Probably both ought to be changed to AVERROR(ENOMEM).
Signed-off-by: Reimar Döffinger
---
libavfilter/dnn/dnn_backend_native.c | 10 +-
libavfilter/dnn/dnn_backend_native.h | 2 ++
libavfilter/dnn/dnn_backend_native_layer_conv2d.c
On Thu, Aug 22, 2019 at 12:06:03PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes usage of uninitialized data reading broken r3d files.
>
> Please review, Carl Eugen
> From efce9940b890b9cf5a9e7400b05be10f6906fbb1 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Thu, 22
On 20.08.2019, at 10:57, Paul B Mahol wrote:
> Because of current overall toxic situation in FFmpeg, meeting will not be
> held until situation improves considerably.
It's a bit strange to read a such a opposite statement without any reason given
for the change of mind.
Also while I can see
On 18.08.2019, at 01:28, Michael Niedermayer wrote:
> 30M cycles -> 5M cycles
I see nothing wrong with it, but:
You could save reviewers a lot of time if you gave them a hint of what the
change
contains instead of them having to reverse-engineer.
In this case for example something like
"add
On 15.08.2019, at 13:15, Vittorio Giovara wrote:
> if you use ffmpeg in your $dayjob, being notified of security problem
> in ffmpeg, and acting upon it before the fix lands in the tree, may be
> crucial.
I realize I only responded to this specific part only in the context of this
discussion.
On 15.08.2019, at 19:38, Paul B Mahol wrote:
> On Thu, Aug 15, 2019 at 7:20 PM Reimar Döffinger
> wrote:
>
>> On 15.08.2019, at 13:15, Vittorio Giovara
>> wrote:
>>> I think being on the security list may have some professional
>> implications
>&g
On 15.08.2019, at 13:15, Vittorio Giovara wrote:
> I think being on the security list may have some professional implications
> too: if you use ffmpeg in your $dayjob, being notified of security problem
> in ffmpeg, and acting upon it before the fix lands in the tree, may be
> crucial. I think
On 14.08.2019, at 11:45, Paul B Mahol wrote:
> I strongly disagree with you. Why some people have subscription to security
> mailing list and I'm not allowed also?
Long version, explaining to the best of my knowledge and memory:
The people on it are on it because at some point it was considered
ght be unavoidable to involve anyway, or who has access
anyway.
Thus Michael's reply of not needing help is relevant - without a need the
default response is likely
to involve people only on a case-by-case basis (generally, maintainers would
and should be involved if the issue is related to
On 12.08.2019, at 21:53, Michael Niedermayer wrote:
> On Sun, Aug 11, 2019 at 08:30:51PM +0200, Reimar Döffinger wrote:
>> On 08.08.2019, at 10:36, Michael Niedermayer wrote:
>>
>>> This provides an alternative to retry counters.
>>> Useful if ther
On 11.08.2019, at 21:51, Marton Balint wrote:
>
>
> On Sun, 11 Aug 2019, Reimar Döffinger wrote:
>
>> On 11.08.2019, at 20:41, Reimar Döffinger wrote:
>>
>>> On 05.08.2019, at 23:34, Marton Balint wrote:
>>>> These functions can
On 11.08.2019, at 21:24, Reimar Döffinger wrote:
> On 07.08.2019, at 19:39, Daniel Kolesa wrote:
>
>> The argument to vec_splat_u16 must be a literal. By making the
>> function always inline and marking the arguments const, gcc can
>> turn those into literals, and
On 07.08.2019, at 19:39, Daniel Kolesa wrote:
> While this technically compiles in current ffmpeg, this is only
> because ffmpeg is compiled in strict ISO C mode, which disables
> the builtin 'vector' keyword for AltiVec/VSX. Instead this gets
> replaced with a macro inside altivec.h, which
On 07.08.2019, at 19:39, Daniel Kolesa wrote:
> The argument to vec_splat_u16 must be a literal. By making the
> function always inline and marking the arguments const, gcc can
> turn those into literals, and avoid build errors like:
Why marking the arguments const?
If it depends on that it
On 11.08.2019, at 20:41, Reimar Döffinger wrote:
> On 05.08.2019, at 23:34, Marton Balint wrote:
>
>> These functions can be used to print a variable number of strings
>> consecutively
>> to the IO context. Unlike av_bprintf, no temporery buffer is necessary.
>
&
On 05.08.2019, at 23:34, Marton Balint wrote:
> These functions can be used to print a variable number of strings
> consecutively
> to the IO context. Unlike av_bprintf, no temporery buffer is necessary.
Hm, is there a use-example patch I missed?
Also is the #define ugliness worth it compared
On 08.08.2019, at 10:36, Michael Niedermayer wrote:
> This provides an alternative to retry counters.
> Useful if there is no reasonable maximum number of iterations and
> no ordering that naturally avoids loops.
Going by the old principle of "an API is not tested until it has at least 3
On Wed, Jul 31, 2019 at 09:30:01AM +0800, Shiyou Yin wrote:
> Ensure the address accesed by gssqc1/gslqc1 are 16-byte aligned.
Pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
Looks good to me
On 31.07.2019, at 03:30, Shiyou Yin wrote:
> Ensure the address accesed by gssqc1/gslqc1 are 16-byte aligned.
> ---
> libavcodec/mips/simple_idct_mmi.c | 2 +-
> libavutil/mips/mmiutils.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
Seems sensible to me, though extra points if you or someone has numbers on
performance impact.
To know whether it would be worthwhile to check if it can be optimized...
On 28.07.2019, at 23:46, James Cowgill wrote:
> When compiling FFmpeg with GCC-9, some very random segfaults were
> observed
On 29.07.2019, at 11:54, "Shiyou Yin" wrote:
>>
> DECLARE_ALIGNED is defined in ' libavutil/mem.h ' and related to compiler. No
> matter mips or x86,
> it's definition is ' #define DECLARE_ALIGNED(n,t,v) t __attribute__
> ((aligned (n))) v' when build
> with gcc or clang (Specific
On 28.07.2019, at 16:45, Paul B Mahol wrote:
> On Sun, Jul 28, 2019 at 4:39 PM Reimar Döffinger
> wrote:
>
>> On 28.07.2019, at 08:55, Paul B Mahol wrote:
>>
>>>>
>>>> Just provide as metadata and leave to e.g. libavfilter.
>>>>
>
On 28.07.2019, at 08:55, Paul B Mahol wrote:
>>
>> Just provide as metadata and leave to e.g. libavfilter.
>>
>
> That does not follow DNG specification.
> I really do not have time to comment on other irrelevant stuff you pointed
> in your review.
If you had just told me that I should back
On 28.07.2019, at 10:40, Nick Renieris wrote:
> Actually, I checked a more accurate version of my loop, and GCC
> optimizes away the LUT check anyway:
> https://godbolt.org/z/G1e1R4
> As you can see it's smart enough to create 2 versions of my functions
> (started at L3 with a lookup and L7
I have no MIPS experience, but for what little it is worth thus: it looks fine
to me.
On 28.07.2019, at 06:42, Shiyou Yin wrote:
> In function ff_h264_add_pixels4_8_mmi, there is no need to reset '%[ftmp0]'
> to 0, because it's value has never changed since the start of the asm block.
> This
On 28.07.2019, at 13:56, Michael Niedermayer wrote:
> On Sun, Jul 28, 2019 at 12:45:36AM +0200, Reimar Döffinger wrote:
>>
>>
>> On 28.07.2019, at 00:31, Michael Niedermayer wrote:
>>
>>> This merges several byte operations and avoids some shifts inside
On 28.07.2019, at 00:31, Michael Niedermayer wrote:
> This merges several byte operations and avoids some shifts inside the loop
>
> Improves: Timeout (330sec -> 134sec)
> Improves:
> 15599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSZH_fuzzer-5658127116009472
>
> Found-by:
On 26.07.2019, at 07:18, Shiyou Yin wrote:
> Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned.
Looks good to me if standard DECLARE_ALIGNED should work for stack on MIPS.
(on x86 it used to be possible for the stack pointer to only be 8-byte aligned,
in which case
On 26.07.2019, at 09:34, Nick Renieris wrote:
> Στις Παρ, 26 Ιουλ 2019 στις 2:21 π.μ., ο/η Reimar Döffinger
> έγραψε:
>>
>> On 25.07.2019, at 17:35, velocit...@gmail.com wrote:
>>
>>> +// Lookup table lookup
>>> +if (lut)
>>> +
On 26.07.2019, at 10:25, Shiyou Yin wrote:
> 1. Refine setting zero process in function ff_h264_add_pixels4_8_mmi and
> ff_h264_idct_add_8_mmi.
"refine" is rather unspecific. What was changed? How large is the improvement,
any specific numbers?
> 2. Remove redundant setting zeor
Typo
On 24.07.2019, at 14:37, Michael Niedermayer wrote:
> On Mon, Jul 22, 2019 at 07:07:57AM +0200, Reimar Döffinger wrote:
>>
>>
>> On 22.07.2019, at 01:25, Michael Niedermayer wrote:
>>
>>> Fixes: Timeout (2min -> 100ms)
>>>
Is there a mips maintainer? otherwise:
On 24.07.2019, at 08:46, Shiyou Yin wrote:
> Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned.
> ---
> libavcodec/mips/simple_idct_mmi.c | 2 +-
> libavutil/mips/mmiutils.h | 2 +-
> 2 files changed, 2 insertions(+), 2
On 25.07.2019, at 17:35, velocit...@gmail.com wrote:
> +// Lookup table lookup
> +if (lut)
> +value = lut[value];
As this function is in the innermost loop, doing the if here instead of having
2 different implementations is likely not ideal speed-wise.
> +// Color scaling
>
On 24.07.2019, at 02:39, Kieran Kunhya wrote:
>>
>> What was the cause of the slow decoding? Does this actually fix it, or
>> does it just swipe it "under the carpet"?
>> If someone ever found a sample with a different solution, how would they
>> know that they shouldn't just remove this again?
On 22.07.2019, at 23:57, Michael Niedermayer wrote:
> The dimensions are always 320x200 they are hardcoded in the demuxer.
> Hardcode them instead in the decoder.
>
> Fixes: Timeout (16sec -> 400ms)
> Fixes:
>
Why is "block" not aligned? Does the code for other architectures also use
unaligned instructions for these?
On 23.07.2019, at 09:27, Shiyou Yin wrote:
> Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned.
> ---
> libavcodec/mips/h264dsp_mmi.c | 48
On 22.07.2019, at 01:25, Michael Niedermayer wrote:
> Fixes: Timeout (2min -> 100ms)
> Fixes:
> 15366/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THEORA_fuzzer-5737849938247680
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
On 22.07.2019, at 06:23, hwrenx wrote:
> Mapping log level from av_log_level to davs3_log_level_e:
>
> [AV_LOG_QUIET, AV_LOG_ERROR] => DAVS2_LOG_ERROR
> [AV_LOG_WARNING] => DAVS2_LOG_WARNING
> [AV_LOG_INFO] => DAVS2_LOG_INFO
> [AV_LOG_VERBOSE, AV_LOG_TRACE] =>
On 21.07.2019, at 02:51, James Almer wrote:
> ffmpeg | branch: master | James Almer | Sat Jul 20
> 10:13:08 2019 -0300| [a38eab8b7501440f872ff1af8a0c5482b7b3e532] | committer:
> James Almer
>
> avformat/aacdec: factorize the adts frame resync code
>
> Signed-off-by: James Almer
>
>>
On 19.07.2019, at 21:46, Michael Niedermayer wrote:
> On Fri, Jul 19, 2019 at 03:54:19PM +0200, Paul B Mahol wrote:
>> On 7/19/19, Michael Niedermayer wrote:
>>> On Sat, Jun 22, 2019 at 01:29:36AM +0200, Michael Niedermayer wrote:
Fixes: Timeout (40sec -> 13sec)
Fixes:
On 21.07.2019, at 00:36, Lynne wrote:
> Jul 20, 2019, 11:08 PM by mich...@niedermayer.cc:
>
>> Fixes: Timeout (22 -> 7 sec)
>> Fixes:
>> 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992
>>
>> Found-by: continuous fuzzing process
>>
On 18.07.2019, at 12:54, Michael Niedermayer wrote:
> On Thu, Jul 18, 2019 at 08:21:21AM +0200, Reimar Döffinger wrote:
>>
>>
>> On 16.07.2019, at 20:31, Michael Niedermayer wrote:
>>
>>> On Tue, Jul 16, 2019 at 08:34:14AM +0200, Reimar Döffinger wrote:
&
On 16.07.2019, at 20:31, Michael Niedermayer wrote:
> On Tue, Jul 16, 2019 at 08:34:14AM +0200, Reimar Döffinger wrote:
>> On 16.07.2019, at 00:50, Michael Niedermayer wrote:
>>
>>> Fixes: division by 0
>>> Fixes:
>>> 15657/clusterfuzz-testcas
On 16.07.2019, at 00:50, Michael Niedermayer wrote:
> Fixes: division by 0
> Fixes:
> 15657/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5738154838982656
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by:
On 16.07.2019, at 00:50, Michael Niedermayer wrote:
> Fixes: Leaks
> Fixes:
> 15349/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5102530557640704
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael
This seems reasonable to me, but I have not been involved in any rtp code.
The commit message is maybe a bit on the verbose side, but I don't have any
strong opinion.
On 12.07.2019, at 08:40, Olivier Maignial wrote:
> === PROBLEM ===
>
> I was trying to record h264 + aac streams from an RTSP
b.com/google/oss-fuzz/tree/master/projects/ffmpeg
>Suggested-by: Reimar Döffinger
>Signed-off-by: Michael Niedermayer
>---
> libavformat/vividas.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
>diff --git a/libavformat/vividas.c b/libavformat/vivi
On 03.07.2019, at 09:28, Olivier MAIGNIAL wrote:
> Hello, thanks for review,
>
> 1) Can you give some reason about why we shouldn't use errno? I think it is
> more clear to accept the full int32 range, even if min/max int32 values are
> very unlikely to be used.
It is a global variable, with
On 03.07.2019, at 08:29, Michael Niedermayer wrote:
> On Tue, Jul 02, 2019 at 08:42:43PM -0300, James Almer wrote:
>> On 7/2/2019 5:56 PM, Michael Niedermayer wrote:
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> doc/APIchanges | 3 +++
>>> libavutil/mem.h | 13 +
>>>
On 01.07.2019, at 00:51, Carl Eugen Hoyos wrote:
> Hi!
>
> I believe attached patch fixes undefined behaviour and ticket #7981.
Same here, I think it makes more sense to check the "size" instead of the
pointer.
But I also suspect we might want to think of a way to not need all these
On 01.07.2019, at 01:12, Carl Eugen Hoyos wrote:
> Undefined behaviour was reported in ticket #7981, attached patch tries
> to fix it.
I suspect it makes more sense to check header_len against 0?
And is the NULL pointer really undefined behaviour even if length is 0?
On 29.06.2019, at 18:26, Dmitry A wrote:
> сб, 29 июн. 2019 г. в 21:43, Dmitry A :
>
>>
>>
>> сб, 29 июн. 2019 г. в 19:11, Dmitry A :
>>
>>>
>>>
>>> сб, 29 июн. 2019 г. в 19:04, Carl Eugen Hoyos :
>>>
Am Sa., 29. Juni 2019 um 14:23 Uhr schrieb Dmitry A <
I don't think we should be using errno when avoidable, and it is avoidable here
by disallowing min/max int32 values themselves. Or using strtoll.
I'm also rather sceptical about allowing negative values here, does that make
sense?
Admittedly the type is set to just "int", but maybe it should be
On 28.06.2019, at 22:53, Michael Niedermayer wrote:
> Fixes: left shift of 133 by 24 places cannot be represented in type 'int'
> Fixes:
> 15365/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5716153105645568
>
> Found-by: continuous fuzzing process
>
e here I would say dead code if nothing else is a
reminder of the
bug, though admittedly a very poor one.
Either way I suggest to discuss such things more relaxed, a few days more or
less hardly matters and there might be useful insights from other people (of
course I don't mean
On 26.06.2019, at 13:15, Andreas Håkon wrote:
> Hi Moritz,
>
>>> Wouldn't this be better if extended to be a BSF version of setpts? In
>>> addition to delays, rescaling as well as other ops could be carried out
>>> on TS.
>>
>> I second that notion, or at least the suggestion of a setpts
sion of the normalize function specific
to that format and the SIMD instruction set available
and call it instead of normalize if applicable.
I would expect that you should see at least a 3x speedup
if using e.g. SSE2 (which is why I don't consider a
10% speedup worth changing the code for really).
On 18.06.2019, at 14:55, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -3447 * 2883584 cannot be represented in type
> 'int'
> Fixes:
> 15265/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINK_fuzzer-5088311799971840
>
> Found-by: continuous fuzzing process
>
On 18.06.2019, at 16:25, Michael Niedermayer wrote:
> Fixes: addition of unsigned offset to 0x7f56fc26a9b6 overflowed to
> 0x7f56fc26a8be*
> Fixes:
> clusterfuzz-testcase-minimized-mediasource_MP4_AVC1_pipeline_integration_fuzzer-4917949056679936
>
> Reported-by: Matt Wolenetz
>
On 21.06.2019, at 00:47, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 65313 * 65313 cannot be represented in type
> 'int'
> Fixes:
> 15290/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5738074249625600
>
> Found-by: continuous fuzzing process
>
On 16.06.2019, at 17:12, Paul B Mahol wrote:
> On 6/16/19, Reimar Döffinger wrote:
>>
>>
>> On 16.06.2019, at 12:30, Lynne wrote:
>>
>>> Jun 16, 2019, 10:57 AM by mich...@niedermayer.cc:
>>>
>>>> Fixes: left shift of negative valu
On 16.06.2019, at 12:30, Lynne wrote:
> Jun 16, 2019, 10:57 AM by mich...@niedermayer.cc:
>
>> Fixes: left shift of negative value -4
>> Fixes: signed integer overflow: -15091694 * 167 cannot be represented in
>> type 'int'
>> Fixes: signed integer overflow: 1898547155 + 453967445 cannot be
On 14.06.2019, at 17:01, James Almer wrote:
> On 6/14/2019 11:52 AM, Reimar Döffinger wrote:
>>
>>
>> On 14.06.2019, at 03:15, Chris Cunningham wrote:
>>
>>> Only "succeed" to read a header if the codec is valid. Otherwise
>>> return AVE
1 - 100 of 672 matches
Mail list logo
