On Mon, Jul 22, 2019 at 11:57:24PM +0200, 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:
> 15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-515
On Mon, Jul 29, 2019 at 10:36:15PM +0200, Jean-Baptiste Kempf wrote:
> Yo,
>
> On Tue, Jul 23, 2019, at 04:42, Lynne wrote:
> > Jul 23, 2019, 12:00 AM by mich...@niedermayer.cc:
> > >> Moreover, if neither the codec, nor container can change the resolution,
> > >> then how does that make anything
Yo,
On Tue, Jul 23, 2019, at 04:42, Lynne wrote:
> Jul 23, 2019, 12:00 AM by mich...@niedermayer.cc:
> >> Moreover, if neither the codec, nor container can change the resolution,
> >> then how does that make anything different?
> >
> >> Please, stop it with those patches. It takes energy and some
On Thu, Jul 25, 2019 at 05:55:02PM +0200, Paul B Mahol wrote:
> On 7/25/19, Michael Niedermayer wrote:
> > On Wed, Jul 24, 2019 at 02:42:24PM +0200, Lynne wrote:
> >> Jul 24, 2019, 11:08 AM by mich...@niedermayer.cc:
> >>
> >> >
> >> > What did you expect ? IIRC you have asked for whole classes of
Jul 25, 2019, 4:47 PM by mich...@niedermayer.cc:
> On Wed, Jul 24, 2019 at 02:42:24PM +0200, Lynne wrote:
>
>> Jul 24, 2019, 11:08 AM by mich...@niedermayer.cc:
>>
>> >
>> > What did you expect ? IIRC you have asked for whole classes of security
>> > issues to be not fixed.
>> >
>> > Something lik
On 7/25/19, Michael Niedermayer wrote:
> On Wed, Jul 24, 2019 at 02:42:24PM +0200, Lynne wrote:
>> Jul 24, 2019, 11:08 AM by mich...@niedermayer.cc:
>>
>> >
>> > What did you expect ? IIRC you have asked for whole classes of security
>> > issues to be not fixed.
>> >
>> > Something like that would
On Wed, Jul 24, 2019 at 02:42:24PM +0200, Lynne wrote:
> Jul 24, 2019, 11:08 AM by mich...@niedermayer.cc:
>
> >
> > What did you expect ? IIRC you have asked for whole classes of security
> > issues to be not fixed.
> >
> > Something like that would require a vote and majority of developers.
> >
On 7/24/19, James Almer wrote:
> On 7/23/2019 9:39 PM, 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 s
On 7/23/2019 9:39 PM, 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? Withou
Jul 24, 2019, 11:08 AM by mich...@niedermayer.cc:
>
> What did you expect ? IIRC you have asked for whole classes of security
> issues to be not fixed.
>
> Something like that would require a vote and majority of developers.
>
The way I interpret this: "Of course I ignored you, you're mental!", d
On Tue, Jul 23, 2019 at 04:42:32AM +0200, Lynne wrote:
> Jul 23, 2019, 12:00 AM by mich...@niedermayer.cc:
>
> > On Tue, Jul 23, 2019 at 12:13:51AM +0200, Lynne wrote:
> >
> >> Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc:
> >>
> >> > The dimensions are always 320x200 they are hardcoded in the
On Wed, Jul 24, 2019 at 01:39:01AM +0100, 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
On Wed, Jul 24, 2019 at 01:29:26AM +0200, Reimar Döffinger wrote:
>
>
> 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:
>
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?
>
> 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? Without any kind of
> comment on the point of this cal
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:
> 15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712
Jul 23, 2019, 9:13 AM by geo...@nsup.org:
> Lynne (12019-07-23):
>
>> Please stay out of all my emails and harassing me over apparently not
>> having enough commits.
>>
>
> What are you taking about? I have gone over your interactions on the
> mailing-list, and found nothing about number of commit
On 7/23/19, Carl Eugen Hoyos wrote:
> Am Di., 23. Juli 2019 um 04:47 Uhr schrieb Lynne :
>>
>> Jul 22, 2019, 11:24 PM by ceffm...@gmail.com:
>
>> > Please stop with these comments.
>> >
>> > No matter what others may tell you, they are not useful but very
>> > disturbing.
>>
>> Please stay out of
Am Di., 23. Juli 2019 um 04:47 Uhr schrieb Lynne :
>
> Jul 22, 2019, 11:24 PM by ceffm...@gmail.com:
> > Please stop with these comments.
> >
> > No matter what others may tell you, they are not useful but very disturbing.
>
> Please stay out of all my emails
I wish I could!
Sadly, you keep attac
Lynne (12019-07-23):
> Please stay out of all my emails and harassing me over apparently not
> having enough commits.
What are you taking about? I have gone over your interactions on the
mailing-list, and found nothing about number of commits, nor anything
that looks to me like harassment, but I m
Jul 22, 2019, 11:24 PM by ceffm...@gmail.com:
> Am Di., 23. Juli 2019 um 00:14 Uhr schrieb Lynne :
>
>> If the size somehow gets lost between lavf and lavc then the problem is
>> there, and should be solved by not fudging the decoder.
>>
>
> (Using libavformat is no condition for using libavcodec
Jul 23, 2019, 12:00 AM by mich...@niedermayer.cc:
> On Tue, Jul 23, 2019 at 12:13:51AM +0200, Lynne wrote:
>
>> Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc:
>>
>> > The dimensions are always 320x200 they are hardcoded in the demuxer.
>> > Hardcode them instead in the decoder.
>> >
>> > Fixes:
On Tue, Jul 23, 2019 at 12:13:51AM +0200, Lynne wrote:
> Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc:
>
> > The dimensions are always 320x200 they are hardcoded in the demuxer.
> > Hardcode them instead in the decoder.
> >
> > Fixes: Timeout (16sec -> 400ms)
> > Fixes:
> > 15574/clusterfuzz-
Am Di., 23. Juli 2019 um 00:14 Uhr schrieb Lynne :
> If the size somehow gets lost between lavf and lavc then the problem is
> there, and should be solved by not fudging the decoder.
(Using libavformat is no condition for using libavcodec)
> Moreover, if neither the codec, nor container can chan
Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc:
> The dimensions are always 320x200 they are hardcoded in the demuxer.
> Hardcode them instead in the decoder.
>
> Fixes: Timeout (16sec -> 400ms)
> Fixes:
> 15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712
>
> F
The dimensions are always 320x200 they are hardcoded in the demuxer.
Hardcode them instead in the decoder.
Fixes: Timeout (16sec -> 400ms)
Fixes:
15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712
Found-by: continuous fuzzing process
https://github.com/google/os
26 matches
Mail list logo
