On Sun, May 21, 2023 at 11:05:21PM +0200, Paul B Mahol wrote:
> On 5/21/23, Michael Niedermayer <michael@niedermayer.cc> wrote:
> > On Sun, Mar 05, 2023 at 08:02:20PM +0100, Michael Niedermayer wrote:
> >> On Sun, Mar 05, 2023 at 05:37:09PM +0100, Paul B Mahol wrote:
> >> > On 3/5/23, Michael Niedermayer <michael@niedermayer.cc> wrote:
> >> > > Fixes: left shift of 538976288 by 13 places cannot be represented in
> >> > > type
> >> > > 'int'
> >> > > Fixes:
> >> > > 56148/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RKA_fuzzer-6257370708967424
> >> > >
> >> >
> >> > Please make sure that this does not break decoding.
> >>
> >> how ?
> >>
> >> * Testing all rka files on the internet ?
> >> i cannot
> >>
> >> * Reading the specification ?
> >> i failed to find a public specification
> >>
> >> * Generating files that have a high enough sample rate with the binary
> >> windows
> >>   encoder?
> >> "ERROR: Unsupported format type." even at 88.2k, well below that point
> >>
> >> Also if it worked before its dependant on the compiler, its undefined
> >> bahevior.
> >> For files with more normal sample rates like the sample in our archieve
> >> it produces the same output.
> >>
> >> Other ideas ?
> >
> > is above ok or should more testing be done ?
> 
> whatever.

I assume you are ok with this being applied, so i will apply

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data