Hello Gentlefolk,
I've been bringing up FFMPEG using Visual Studio 2022 and the MINGW64
environment, and came across sundry things that absolutely needed fixes, so I
thought I'd submit them as a series of small patches for you to consider. Here
is the first patch.
--Zem
==
> FWIW, this setup is definitely being used by lots of others already - so
> whenever there's such an issue, the main question to ask is why others
> haven't run into the issue before. But improvements are definitely
> welcome!
You have to have PATH set up so that rc.exe is found inside the Window
> paths; it's msys2 which does the whole unix-style paths and which
> automatically tries to rewrite command line arguments as if they were
> paths, with some level of heuristics.
Yes, this makes sense. The build uses /bin/bash, which is configured as
x86_64-pc-msys, and that's where the rewriti
Second version of my patch. Please let me know if I forgot something.
--Zem
===
When building FFMPEG in the MSYS environment under Windows, one must not use
forward slashes ('/') for command-line options. It appears that th
Thanks for the detailed explanation. Now my head hurts.
I guess by "native" you mean those apps that do not depend on MSYS/Cygwin
DLL functionality? All of the apps are native.
So I can definitely understand the appeal of MinGW. But what about
MSYS? Is it some sort of copyright/GPL avoidance
> Not at all - it's entirely a technical thing. MSYS, which is a fork of
> cygwin, is an environment to provide a full POSIX (i.e. unix) environment
> on top of Windows, which involves a lot of trickery to make system calls
> like fork() work on top of a OS that doesn't provide that.
But that's ex
Use CONFIG_FFRTMPCRYPT_PROTOCOL for conditional compilation and NOT run-time
evaluation. If optimizations are disabled and CONFIG_FFRTMPCRYPT_PROTOCOL==0,
the compiler may fail to get rid of the conditional blocks. Alas, the blocks
themselves contain calls to RTMPE functionality (ff_rtmpe_gen_
