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,
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:
>
>
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,
> > > > 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?
> >
>
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
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,
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
