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_
> 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
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
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
> 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
> 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
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
==
