Thanks, this works great. Stand by for patch.
On Wed, Feb 6, 2019 at 8:38 AM Hendrik Leppkes wrote:
> On Thu, Jan 31, 2019 at 11:29 PM Chris Cunningham
> wrote:
> >
> > On Wed, Jan 30, 2019 at 5:43 PM James Almer wrote:
> >
> > > On 1/30/2019 10:20 PM, Chris Cunningham wrote:
> > > >>
> > >
On Thu, Jan 31, 2019 at 11:29 PM Chris Cunningham
wrote:
>
> On Wed, Jan 30, 2019 at 5:43 PM James Almer wrote:
>
> > On 1/30/2019 10:20 PM, Chris Cunningham wrote:
> > >>
> > And this definitely means there's a bug elsewhere. This parser should
> > have not been used for codecs ids
On Mon, Feb 04, 2019 at 04:33:37PM -0800, Chris Cunningham wrote:
> >
> > The underlined bit above seems like the root cause. Where should we be
> > updating st->internal->avctx->codec_id?
> >
>
> Friendly ping for review
I dont have a testcase so i cant test but possibly setting
>
> The underlined bit above seems like the root cause. Where should we be
> updating st->internal->avctx->codec_id?
>
Friendly ping for review
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Jan 30, 2019 at 5:43 PM James Almer wrote:
> On 1/30/2019 10:20 PM, Chris Cunningham wrote:
> >>
> And this definitely means there's a bug elsewhere. This parser should
> have not been used for codecs ids other than GSM and GSM_MS. That's
> precisely what this assert() is
On 1/30/2019 10:20 PM, Chris Cunningham wrote:
>>
And this definitely means there's a bug elsewhere. This parser should
have not been used for codecs ids other than GSM and GSM_MS. That's
precisely what this assert() is making sure of.
>>>
>>> I'll take a closer look at how
>
> >> And this definitely means there's a bug elsewhere. This parser should
> >> have not been used for codecs ids other than GSM and GSM_MS. That's
> >> precisely what this assert() is making sure of.
> >>
> >
> > I'll take a closer look at how this parser was selected.
>
Ok, here are full
On 1/30/2019 6:44 PM, Chris Cunningham wrote:
> On Wed, Jan 30, 2019 at 1:40 PM James Almer wrote:
>
>> Parsers can't return negative values, only the output packet size. For
>> the purpose of errors, they usually return the entire untouched packet
>> size.
>>
>
> Understood. Is this documented
On Wed, Jan 30, 2019 at 1:40 PM James Almer wrote:
> Parsers can't return negative values, only the output packet size. For
> the purpose of errors, they usually return the entire untouched packet
> size.
>
Understood. Is this documented somewhere? I noted the comment in
av_paser_parse2(), "/*
On 1/30/2019 6:27 PM, chcunningham wrote:
> Return replaces an assert0. libfuzzer generated a testcase that
> triggered this assert (codec=0), causing a crash of chrome's renderer.
> ---
> libavcodec/gsm_parser.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
chcunningham (12019-01-30):
> Return replaces an assert0. libfuzzer generated a testcase that
> triggered this assert (codec=0), causing a crash of chrome's renderer.
> ---
> libavcodec/gsm_parser.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/gsm_parser.c
2019-01-30 22:27 GMT+01:00, chcunningham :
> Return replaces an assert0. libfuzzer generated a testcase that
> triggered this assert (codec=0), causing a crash of chrome's renderer.
Wouldn't this indicate a bug somewhere else?
Carl Eugen
___
Return replaces an assert0. libfuzzer generated a testcase that
triggered this assert (codec=0), causing a crash of chrome's renderer.
---
libavcodec/gsm_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/gsm_parser.c b/libavcodec/gsm_parser.c
index
13 matches
Mail list logo
