future.
I attached that patch in this email for reference, if somebody can import that
line from development sources.
Sincerely,
Carlo Bramini.--- origsrc/ffmpeg-3.4.12/ffbuild/common.mak2022-10-27 22:21:00.0
+0200
+++ src/ffmpeg-3.4.12/ffbuild/common.mak2022-12-23 10:46:32
Hello,
yes, that commit seems to be the one that include the needed fix.
Is it possible to import that change also into the next release of 3.4.x
branch? Or do I need to open a new bug report?
Sincerely,
Carlo Bramini.
> Il 23/12/2022 21:21 Michael Niedermayer ha scritto:
>
>
Hello,
what's the last version of ffmpeg known to work on the ancient Windows 9x/ME? I
looked to the history but I was not able to find this information.
Thank you very much for your time.
Sincerely.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Hello,
while working with ADPCM source code, I noticed that there is a type mismatch
in ff_adpcm_afc_coeffs[2][16]. Inside libavcodec/adpcm_data.c it is declared as
uint16_t:
https://github.com/FFmpeg/FFmpeg/blob/d168e78effd170377ec57f67bca05c9f0de91bca/libavcodec/adpcm_data.c#L109
but into lib
you are compiling for plain C or C++.
Sincerely.
> Il 10 marzo 2018 alle 20.38 Carl Eugen Hoyos ha scritto:
>
> 2018-03-10 15:02 GMT+01:00 Carlo Bramini :
>
> > I noticed this thing because I compiled those sources with a more robust
> > syntax check, by using C++
Hello everyone,
> Il 11 marzo 2018 alle 11.42 Carl Eugen Hoyos ha scritto:
>
> 2018-03-11 11:27 GMT+01:00 Carlo Bramini :
>
> > Hello,
> > I see. I expected that adding that could be considered out of the coding
> > guidelines.
>
> You misunderstand:
&g
Hello,
> > > > However, what about the patch attached for fixing the declaration
> > > > of ff_adpcm_afc_coeffs[2][16]?
> > >
> > > This would revert 10542491, a relatively recent change: Maybe Paul,
> > > the author, wants to comment.
> > >
> > > Do you think the code gets more readable?
> >
>