[FFmpeg-devel] What's the last version of ffmpeg known to work on Windows 9x/ME?
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 https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffmpeg-3.4.12 does not build (i686-w64-mingw32)
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: > > > On Fri, Dec 23, 2022 at 04:04:31PM +0100, Carlo Bramini wrote: > > Hello, > > > > I tried to build ffmpeg-3.4.12, which is the last one supporting Windows > > XP, but it fails to compile the resource file for Windows. > > Running verbose build, it prints this output on the console: > > > > > $ make V=1 > > > i686-w64-mingw32-windres -I. -Isrc/ --preprocessor "i686-w64-mingw32-gcc > > > -E -xc-header -DRC_INVOKED -MMD -MF libavdevice/avdeviceres.d -MT > > > libavdevice/avdeviceres.o" -o libavdevice/avdeviceres.o > > > /home/carlo/packages/ffmpeg/mingw64-i686-ffmpeg-3.4.12-1.noarch/src/ffmpeg-3.4.12/libavdevice/avdeviceres.rc > > > /bin/sh: i686-w64-mingw32-gcc -E -xc-header -DRC_INVOKED -MMD -MF > > > libavdevice/avdeviceres.d -MT libavdevice/avdeviceres.o: No such file or > > > directory > > > make: *** > > > [/home/carlo/packages/ffmpeg/mingw64-i686-ffmpeg-3.4.12-1.noarch/src/ffmpeg-3.4.12/ffbuild/common.mak:86: > > > libavdevice/avdeviceres.o] Error 1 > > > > I found a solution by comparing ffbuild/common.mak between this version and > > the latest 5.1.2, which has already fixed this bug. > > So, I'm wondering if it could be possible to apply the same patch for > > fixing this tiny issue in the next maintenance release of 3.4.x branch, if > > it will happen in the 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.733625900 > > +0100 > > @@ -83,7 +83,7 @@ COMPILE_NVCC = $(call COMPILE,NVCC) > > -$(if $(ASMSTRIPFLAGS), $(STRIP) $(ASMSTRIPFLAGS) $@) > > > > %.o: %.rc > > - $(WINDRES) $(IFLAGS) --preprocessor "$(DEPWINDRES) -E -xc-header > > -DRC_INVOKED $(CC_DEPFLAGS)" -o $@ $< > > + $(WINDRES) $(IFLAGS) $(foreach ARG,$(CC_DEPFLAGS),--preprocessor-arg > > "$(ARG)") -o $@ $< > > > > %.i: %.c > > $(CC) $(CCFLAGS) $(CC_E) $< > > This is the patch, you seem talking about. > > commit f9626d1065c43f1d51afe66bdf988b9f33729440 > Author: Martin Storsjö > Date: Sat May 15 00:42:38 2021 +0300 > > ffbuild: Avoid using the --preprocessor argument to windres > > Instead use --preprocessor-arg; in binutils 2.36, the --preprocessor > flag was changed so that it no longer accepts a string containing > multiple arguments, but the whole --preprocessor argument is > treated as the path to the preprocessor executable (where the path > can contain spaces). > > It's currently unclear whether this behaviour will stay or if it > is going to be reverted in the future, see discussion at [1]. Just > to be safe, avoid using the --preprocessor argument. Don't redeclare > the full preprocessing command, but just add the $(CC_DEPFLAGS) options. > > Based on a patch by Kyle Schwartz. > > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=27594 > > Signed-off-by: Martin Storsjö > > > [...] > > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > "You are 36 times more likely to die in a bathtub than at the hands of a > terrorist. Also, you are 2.5 times more likely to become a president and > 2 times more likely to become an astronaut, than to die in a terrorist > attack." -- Thoughty2 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] ffmpeg-3.4.12 does not build (i686-w64-mingw32)
Hello, I tried to build ffmpeg-3.4.12, which is the last one supporting Windows XP, but it fails to compile the resource file for Windows. Running verbose build, it prints this output on the console: > $ make V=1 > i686-w64-mingw32-windres -I. -Isrc/ --preprocessor "i686-w64-mingw32-gcc -E > -xc-header -DRC_INVOKED -MMD -MF libavdevice/avdeviceres.d -MT > libavdevice/avdeviceres.o" -o libavdevice/avdeviceres.o > /home/carlo/packages/ffmpeg/mingw64-i686-ffmpeg-3.4.12-1.noarch/src/ffmpeg-3.4.12/libavdevice/avdeviceres.rc > /bin/sh: i686-w64-mingw32-gcc -E -xc-header -DRC_INVOKED -MMD -MF > libavdevice/avdeviceres.d -MT libavdevice/avdeviceres.o: No such file or > directory > make: *** > [/home/carlo/packages/ffmpeg/mingw64-i686-ffmpeg-3.4.12-1.noarch/src/ffmpeg-3.4.12/ffbuild/common.mak:86: > libavdevice/avdeviceres.o] Error 1 I found a solution by comparing ffbuild/common.mak between this version and the latest 5.1.2, which has already fixed this bug. So, I'm wondering if it could be possible to apply the same patch for fixing this tiny issue in the next maintenance release of 3.4.x branch, if it will happen in the 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.733625900 +0100 @@ -83,7 +83,7 @@ COMPILE_NVCC = $(call COMPILE,NVCC) -$(if $(ASMSTRIPFLAGS), $(STRIP) $(ASMSTRIPFLAGS) $@) %.o: %.rc - $(WINDRES) $(IFLAGS) --preprocessor "$(DEPWINDRES) -E -xc-header -DRC_INVOKED $(CC_DEPFLAGS)" -o $@ $< + $(WINDRES) $(IFLAGS) $(foreach ARG,$(CC_DEPFLAGS),--preprocessor-arg "$(ARG)") -o $@ $< %.i: %.c $(CC) $(CCFLAGS) $(CC_E) $< ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Type mismatch in ADPCM
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? > > > > Excuse me... I was just wondering what to do > > You could answer above question. I'm sorry, I was thinking that you did the question to Mr. Paul, since you were requesting a comment from him. For me, I would say that this change makes the code more correct rather than more readable, which should be a more important reason, but that's just my opinion. Sincerely. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Type mismatch in ADPCM
Hello everyone, > Il 11 marzo 2018 alle 11.42 Carl Eugen Hoyos <ceffm...@gmail.com> ha scritto: > > 2018-03-11 11:27 GMT+01:00 Carlo Bramini <carlo.bra...@libero.it>: > > > Hello, > > I see. I expected that adding that could be considered out of the coding > > guidelines. > > You misunderstand: > The issue is not (afaict) the coding guidelines but the fact that the > change would mean we claim a compatibility that we cannot guarantee. > > > 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? > Excuse me... I was just wondering what to do, because I had not received any more replies about that patch. Thank you very much for your time. Sincerely. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Type mismatch in ADPCM
Hello,
I see. I expected that adding that could be considered out of the coding
guidelines.
However, what about the patch attached for fixing the declaration of
ff_adpcm_afc_coeffs[2][16]?
Although it works because the binary values are the same, this is wrong,
independently by the fact that you are compiling for plain C or C++.
Sincerely.
> Il 10 marzo 2018 alle 20.38 Carl Eugen Hoyos <ceffm...@gmail.com> ha scritto:
>
> 2018-03-10 15:02 GMT+01:00 Carlo Bramini <carlo.bra...@libero.it>:
>
> > I noticed this thing because I compiled those sources with a more robust
> > syntax check, by using C++ rather that plain C. At pratical level, nothing
> > changed, except for the .h files that required to use the extern "C"
> > keyword. I was wondering if you could evaulate the chance to add this
> > feature to the include files.
> > It could be done directly by using some #ifdef/#endif, or perhaps by doing
> > something like this, somewhere in a common file:
> >
> > #ifdef __cplusplus
> >
> > #define FFMPEG_EXTERN_C_BEGIN extern "C" {
> >
> > #define FFMPEG_EXTERN_C_END }
> >
> > #else
> >
> > #define FFMPEG_EXTERN_C_BEGIN
> >
> > #define FFMPEG_EXTERN_C_END
> >
> > #endif
>
> In addition to what was said:
> We cannot commit above because we would not test it
> and we cannot guarantee that it will always work: We
> provide C headers, if you want to use them in a C++
> project, it is your responsibility to make sure it works,
> not ours.
>
> Carl Eugen
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Type mismatch in ADPCM
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 libavcodec/adpcm_data.h it is declared as int16_t:
https://github.com/FFmpeg/FFmpeg/blob/d168e78effd170377ec57f67bca05c9f0de91bca/libavcodec/adpcm_data.h#L43
Those values are used as signed integer elsewhere.
So, I would like to suggest to fix this declaration with attached patch.
I noticed this thing because I compiled those sources with a more robust syntax
check, by using C++ rather that plain C. At pratical level, nothing changed,
except for the .h files that required to use the extern "C" keyword. I was
wondering if you could evaulate the chance to add this feature to the include
files.
It could be done directly by using some #ifdef/#endif, or perhaps by doing
something like this, somewhere in a common file:
#ifdef __cplusplus
#define FFMPEG_EXTERN_C_BEGIN extern "C" {
#define FFMPEG_EXTERN_C_END }
#else
#define FFMPEG_EXTERN_C_BEGIN
#define FFMPEG_EXTERN_C_END
#endif
and just add FFMPEG_EXTERN_C_BEGIN and FFMPEG_EXTERN_C_END to the top and to
the bottom of each include file. You could take it as a suggestion, allowing
compilation with both GCC and G++ may show you some defects you cannot see
normally and give room to some improvements.
Sincerely.diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index cd3bbd33c2..2753bd852d 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -1254,7 +1254,7 @@ static int adpcm_decode_frame(AVCodecContext *avctx, void
*data,
int coeff1, coeff2;
int shift;
unsigned int channel;
-uint16_t *samplesC;
+int16_t *samplesC;
int count = 0;
int offsets[6];
diff --git a/libavcodec/adpcm_data.c b/libavcodec/adpcm_data.c
index 4cce0a5857..e7ca5bc697 100644
--- a/libavcodec/adpcm_data.c
+++ b/libavcodec/adpcm_data.c
@@ -25,6 +25,8 @@
#include
+#include "adpcm_data.h"
+
/* ff_adpcm_step_table[] and ff_adpcm_index_table[] are from the ADPCM
reference source */
static const int8_t adpcm_index_table2[4] = {
@@ -106,9 +108,9 @@ const int8_t ff_adpcm_yamaha_difflookup[] = {
-1, -3, -5, -7, -9, -11, -13, -15
};
-const uint16_t ff_adpcm_afc_coeffs[2][16] = {
-{ 0, 2048, 0, 1024, 4096, 3584, 3072, 4608, 4200, 4800, 5120, 2048, 1024,
64512, 64512, 63488 },
-{ 0, 0, 2048, 1024, 63488, 64000, 64512, 62976, 63288, 63236, 62464,
63488, 64512, 1024, 0, 0 }
+const int16_t ff_adpcm_afc_coeffs[2][16] = {
+{ 0, 2048, 0, 1024, 4096, 3584, 3072, 4608, 4200, 4800, 5120, 2048, 1024,
-1024, -1024, -2048, },
+{ 0, 0, 2048, 1024, -2048, -1536, -1024, -2560, -2248, -2300, -3072,
-2048, -1024, 1024, 0, 0, }
};
const int16_t ff_adpcm_mtaf_stepsize[32][16] = {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
