Re: [FFmpeg-devel] graph.{html,css} embed failure on Windows build

[Kacper Michajlow <kasper93-at-gmail.com@ffmpeg.org>]

On Tue, 17 Jun 2025 at 20:54, softworkz . <softworkz@hotmail.com> wrote:
>
>
> > -----Original Message-----
> > From: Kacper Michajlow <kasper93@gmail.com>
> > Sent: Tuesday, June 17, 2025 6:36 PM
> > To: softworkz . <softworkz@hotmail.com>
> > Cc: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > Subject: Re: graph.{html,css} embed failure on Windows build
>
> [..]
>
> > > > > I will wait for the remaining CI builds to succeed and submit the
> > > > > rebased patchset to the ML then.
> > > > >
> > > > > Please let me know whether it fixes the build on your side as well.
> > > >
> > > > Yes, this fixes the build issue. Thanks.
> > >
> > > Thanks for confirming. Patch update sent.
> > >
> > > > Note, I created a pipeline to upload this failing configuration to the fate
> > server.
> > > > So we have coverage of this config now. Things tend to break if
> > > > something is not tested.
> > >
> > > Yup - but that's testing only after merge to master.
> > > I'm thinking about adding an additional check build for Patchwork.
> > > Do you think your configuration is common enough to do this? Or is
> > > there a more typical configure setup for this kind of build
> > > (Win-CLang) that would make more sense for the project?
> >
> > I think this config is criminally underused. Everyone thinks MSVC
> > (cl.exe) only when talking about Visual Studio. But actually they are shipping
> > LLVM toolchain which is a great way to build software with Windows SDK
> > (without mingw) that is not MSVC (cl.exe) compatible.
>
> It still needs MSYS2 for the Gnu build system, but yea, I get the point of
> using the platform SDK directly.

For the build system if you use 3rd-party meson port
https://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg you can
compile ffmpeg without MSYS2. This is handy, especially for
dependencies, because you can build them as subprojects, which
simplifies things. But MSYS2 mingw package manager is handy, because
you don't need to build everything yourself.

> How's the resulting binaries' performance? I'm using the SMP project
> generator which allows you to actually work and debug in VS like with
> any other MSVC project/solution, but for production compiles, that's
> not an option as it's way slower than the GCC/MSYS2/mingw path..

It's Clang/LLVM, basically the same compiler as when using mingw path.
In theory performance should be "the same", of course in case of mingw
you have some parts of C runtime from mingw, so things are different.
We had this problem where llvm-mingw was using custom math functions
which were significantly slower than UCRT ones, but this has been
resolved, just an example.

That's also the main advantage of using Clang, because MSVC has its
own limitations and performance difference. It's good that it builds,
but it has always been better to avoid it :)

GCC vs Clang performance is another story.

If you want to debug in VS/windbg. You can create PDB files even from
llvm-mingw build. All you need is cflag `-gcodeview` and ldflag
`-Wl,-pdb=` (empty will use target name). And then you can load such
binaries in VS with debug info without an issue. LLVM is nice like
that because it supports both GNU and MSVC worlds and many things are
just interchangeable.

> > Of course mingw and
> > llvm-mingw have existed for a long time and are goto solutions for such cases,
> > but I find it nice to run software with standard SDK.
> >
> > To answer your questions, depends how much resources you want to throw at
> > that. I wouldn't say this configuration is critical. Though at least one Clang
> > based Windows build would be good to have, whether llvm-mingw or clang-
> > msvc. Note I don't mean clang-cl because this thing is supposed to be closely
> > compatible with MSVC itself, so in theory if cl.exe is working clang-cl.exe
> > should do too.
>
> Now that andriy/make_x86 is active again, I can disable softworkz/make_linux_x64,
> which is almost the same. The mac run is the fastest and of no concern, Linux-shared
> and Linux-out-of-tree don't run FATE. The heavy-weights are Win-MSVC and Win-GCC
> which take 40-60 and 30-50 minutes including FATE (but only partial FATE due to
> the pending patchset for subtitle refs). The Win-MSVC-CLang took 50min (but I don't
> know the range yet).
>
> FATE takes about 2/3 of the time, so when adding Win-MSVC-CLang it would be good
> to have at most 2 of the - then 3 - Windows builds also running FATE. I'm not sure
> which of them would be the least important - maybe Win-GCC, because it's closest
> to the Linux FATE build and Windows-specific issues would be detected with Win-MSVC
> and Win-MSVC-CLang anyway?

I would say the main thing is testing Win-MSVC to see if things work
in the MSVC world. Win-MSVC-Clang is very similar to GNU-Clang in
terms of driver part, but uses MSVC sysroot. It's oversimplified, but
in practice it uses GNU style frontend, as opposed to clang-cl/cl
using MSVC style. Therefore most issues are in the build system or in
platform specific defines. Like we had a linking issue
https://ffmpeg.org/pipermail/ffmpeg-devel/2025-June/345029.html or
this graph.css embedding issue. So it's nice to test, but at the same
time I don't expect huge breakage in this specific configuration,
probably only build related.

- Kacper
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".