On Fri, Feb 21, 2020 at 5:59 AM Vittorio Giovara
wrote:
>
> On Thu, Feb 20, 2020 at 6:38 PM James Almer wrote:
>
> > On 2/20/2020 5:02 PM, Vittorio Giovara wrote:
> > > On Mon, Feb 10, 2020 at 3:14 PM Mohammad Izadi
> > wrote:
> > >
> > >> From: Mohammad Izadi
> > >>
> > >> Trying to read
Fixes: left shift of 233 by 24 places cannot be represented in type 'int'
Fixes:
20736/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PCM_LXF_fuzzer-4829212685107200
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael
Fixes: signed integer overflow: 2129689466 + 2129689466 cannot be represented
in type 'int'
Fixes:
20715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5155263109922816
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
On Thu, Feb 20, 2020 at 11:22:33AM +, Gaullier Nicolas wrote:
> > De : ffmpeg-devel De la part de Michael
> > Niedermayer
> > Envoyé : vendredi 7 février 2020 23:39
> > À : FFmpeg development discussions and patches
> > Objet : Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB
Vittorio Giovara (12020-02-20):
> bacuase lavf is a library which depends on lavc, not vice versa, hierarchy
> is respected
>
> I still consider it a poor design choice
The poor design choice is to keep the libraries separated. We can see
all the trouble it causes us, between this discussion and
probably ok
On 2/21/20, Michael Niedermayer wrote:
> Fixes: left shift of 233 by 24 places cannot be represented in type 'int'
> Fixes:
> 20736/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PCM_LXF_fuzzer-4829212685107200
>
> Found-by: continuous fuzzing process
>
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> If an audio stream is present, the Sega FILM muxer checks for its
>> compability with the container during init, so that the very same check
>> needn't be repeated during writing the trailer.
>>
>> Essentially the same is true for the presence of a
lgtm
On 1/14/20, Andreas Rheinhardt wrote:
> If an audio stream is present, the Sega FILM muxer checks for its
> compability with the container during init, so that the very same check
> needn't be repeated during writing the trailer.
>
> Essentially the same is true for the presence of a video
> De : ffmpeg-devel De la part de Michael
> Niedermayer
> Envoyé : vendredi 21 février 2020 12:54
> À : FFmpeg development discussions and patches
> Objet : Re: [FFmpeg-devel] [PATCH v7 3/3] avcodec/mpeg12dec: Add CPB coded
> side data
>
> On Thu, Feb 20, 2020 at 11:22:33AM +, Gaullier
NAK
This code should be purged from the tree.
On 2/21/20, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 2129689466 + 2129689466 cannot be
> represented in type 'int'
> Fixes:
> 20715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-5155263109922816
>
> Found-by:
+John Rummell just noticed this patch never landed
upstream. Can this be landed?
- dale
On Thu, Feb 28, 2019 at 1:58 PM Dale Curtis wrote:
> Such errors may make sense for specific formats, but general parsing
> logic shouldn't be treating these as errors regardless of the error
> recognition
On Thu, Feb 20, 2020 at 11:29:51PM +0100, Paul B Mahol wrote:
> On 2/20/20, Michael Niedermayer wrote:
> > On Thu, Feb 20, 2020 at 08:11:34PM +0100, Paul B Mahol wrote:
> >> Are you sure this is correct?
> >> Does asan reports exactly overread by 4?
> >
> > the next line passes diff_size - 8 as a
On Thu, Feb 20, 2020 at 11:32:08PM +0100, Paul B Mahol wrote:
> LGTM
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom
Signed-off-by: Paul B Mahol
---
libavcodec/ac3_parser.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/ac3_parser.c b/libavcodec/ac3_parser.c
index 1e203ae6ac..ba171653ef 100644
--- a/libavcodec/ac3_parser.c
+++ b/libavcodec/ac3_parser.c
@@ -201,6 +201,12 @@ static int
Hi all,
Firstly, I want to thank j-b for his organisation of the meeting at
FOSDEM, I think the meeting itself was productive and the outcome was
good.
Unfortunately, there is one issue: So far no one has shared a copy of
the notes or a picture of the blackboard after the meeting. I was silly
to
On Fri, Feb 21, 2020 at 11:26 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> I doubt that this patch still applies as-is because of
> e2307f4ff197646a7feee0edbcdd2d3262932676.
>
>
Ah, good point. Rebased and attached.
- dale
From 57f732774528eecb837467919ec9a284e95470dc Mon Sep
On Fri, Feb 21, 2020 at 04:41:35PM -0300, Pedro Arthur wrote:
> Hi,
>
> Em qui., 6 de fev. de 2020 às 19:59, Michael Niedermayer
> escreveu:
> >
> > Hi all
> >
> > please help fill the 2020 GSoC Ideas page
> > https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020
>
> It seems the 2020
Hi,
Em qui., 6 de fev. de 2020 às 19:59, Michael Niedermayer
escreveu:
>
> Hi all
>
> please help fill the 2020 GSoC Ideas page
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020
It seems the 2020 results page [1] contains results from 2019.
[1] -
Dale Curtis:
> +John Rummell just noticed this patch never landed
> upstream. Can this be landed?
>
> - dale
>
> On Thu, Feb 28, 2019 at 1:58 PM Dale Curtis wrote:
>
>> Such errors may make sense for specific formats, but general parsing
>> logic shouldn't be treating these as errors
On Wed, Jan 22, 2020 at 04:25:40PM +0100, Andreas Rheinhardt wrote:
> On Wed, Jan 22, 2020 at 4:23 PM Carl Eugen Hoyos wrote:
>
> > Am Mi., 22. Jan. 2020 um 16:21 Uhr schrieb Andreas Rheinhardt
> > :
> > >
> > > On Wed, Jan 22, 2020 at 4:06 PM Carl Eugen Hoyos
> > wrote:
> > >
> > > > Am Mi.,
On Fri, Feb 21, 2020 at 12:54 PM Dale Curtis
wrote:
> On Fri, Feb 21, 2020 at 11:26 AM Andreas Rheinhardt <
> andreas.rheinha...@gmail.com> wrote:
>
>> I doubt that this patch still applies as-is because of
>> e2307f4ff197646a7feee0edbcdd2d3262932676.
>>
>>
> Ah, good point. Rebased and
On Fri, Feb 21, 2020 at 12:42:07PM +0100, Paul B Mahol wrote:
> probably ok
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
signature.asc
On Fri, Feb 21, 2020 at 7:08 PM Mohammad Izadi wrote:
>
> If you believe lavc is at the top of the hierarchy, I can simply move the
> file to lavc. Then both lavc and lavf can use it and hierarchy is
> respected. Can I do that? Doesn't break API? Any objection (with solution)?
> Let's make right
Why does the struct belong to lavu? This struct is super similar to structs
in libavcodec/hevc_sei.h. We just move it to a new file to share it between
hevc and vp9 encoder/decoder.
--
Best,
Mohammad
On Fri, Feb 21, 2020 at 2:03 PM Hendrik Leppkes wrote:
> On Fri, Feb 21, 2020 at 7:08 PM
If you believe lavc is at the top of the hierarchy, I can simply move the
file to lavc. Then both lavc and lavf can use it and hierarchy is
respected. Can I do that? Doesn't break API? Any objection (with solution)?
Let's make right decisions to speed up the process please :).
--
Best,
Mohammad
Hello,
I am Ibrahim Anis CSE final year undergraduate student pursuing B.Tech from
Govt. College Ujjain.I am looking forward to participating GSOC 2020 and
contribute to ffmpeg community.
I am interested in working on the project 'Improvig color constancy video
filter'.I have knowledge of c
On Fri, Feb 21, 2020 at 5:17 PM Mohammad Izadi wrote:
> Why does the struct belong to lavu? This struct is super similar to structs
> in libavcodec/hevc_sei.h. We just move it to a new file to share it between
> hevc and vp9 encoder/decoder.
>
> --
>
1. Please kindly stop top posting:
Hi, I am a 3rd Year Computer Science Student Currently Studying at
Medi-Caps University, Indore.
I want to make a contribution to FFmpeg Project in GSOC 2020.
For Gsoc 2020 I interested in Fuzzing FATE tests in libavformat, libavutil
and libswscale.
I have one minor documentation bug fixed.
And I
28 matches
Mail list logo
