L-SMASH Source

[LigH]

Apparently a "Type 2" DV AVI, okay.

Your script looks a bit unusual yet probably valid. Still, try to use a different syntax:

name1="Greenwich, London (16.02.2007 12.53).avi"
a=LWLibavAudioSource(name1)
v=LWLibavVideoSource(name1)
AudioDub(v, a)

[rgr]

It doesn't change anything.

The problem is here:
LWLibavAudioSource(name1)

Without sound it works OK.

[LigH]

I suspected that. Probably the audio stream is not correctly recognised. I am not at all sure but believe to remember that 32 kHz audio was an issue. Or the 2CC marker.

For a good reason I asked for a verbose MediaInfo report. I can't count how often I already explained how to achieve that (https://forum.doom9.org/showthread.php?p=2005134#post2005134).

[rgr]

I suspected that. Probably the audio stream is not correctly recognised. I am not at all sure but believe to remember that 32 kHz audio was an issue. Or the 2CC marker.

For a good reason I asked for a verbose MediaInfo report. I can't count how often I already explained how to achieve that (https://forum.doom9.org/showthread.php?p=2005134#post2005134).

Count : 356
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Inform : Count : 356 / Count of stream of this kind : 1 / Kind of stream : General / Kind of stream : General / Stream identifier : 0 / Inform : AVI (OpenDML) (DV): 12.6 GiB, 1 h 0 min / Count of video streams : 1 / Count of audio streams : 1 / Video_Format_List : DV / Video_Format_WithHint_List : DV (Sony) / Codecs Video : DV / Audio_Format_List : PCM / Audio_Format_WithHint_List : PCM / Audio codecs : PCM / Audio_Channels_Total :
[...]
/ File extension : avi / Format : AVI / Format : AVI / Format/Info : Audio Video Interleave / Format/Extensions usually used : avi / Commercial name : AVI DV / Commercial name : DV / Format profile : OpenDML / Format settings : BitmapInfoHeader / WaveFormatEx / Internet media type : video/vnd.avi / Interleaved : Yes / File size : 13579636736 / File size : 12.6 GiB / File size : 13 GiB / File size : 13 GiB / File size : 12.6 GiB / File size : 12.65 GiB / Duration : 3631160 / Duration : 1 h 0 min / Duration : 1 h 0 min 31 s 160 ms / Duration : 1 h 0 min / Duration : 01:00:31.160 / Duration : 01:00:31:04 / Duration : 01:00:31.160 (01:00:31:04) / Overall bit rate mode : CBR / Overall bit rate mode : Constant / Overall bit rate : 29918013 / Overall bit rate : 29.9 Mb/s / Frame rate : 25.000 / Frame rate : 25.000 FPS / Frame count : 90779 / Stream size : 42672256 / Stream size : 40.7 MiB (0%) / Stream size : 41 MiB / Stream size : 41 MiB / Stream size : 40.7 MiB / Stream size : 40.70 MiB / Stream size : 40.7 MiB (0%) / Proportion of this stream : 0.00314 / Recorded date : 2007-02-11 10:05:26.000 / File creation date : 2024-08-20 22:04:08.267 UTC / File creation date (local) : 2024-08-21 00:04:08.267 / File last modification date : 2024-08-20 22:03:31.185 UTC / File last modification date (local) : 2024-08-21 00:03:31.185 / TAPE : Bernard Abbey, Space Centre / TCOD : 0 / TCDO : 36311600000 / VMAJ : 4 / VMIN : 0 / STAT : 90779 0 3.315543 1 / DTIM : 29838788 647722752
Count of video streams : 1
Count of audio streams : 1
Video_Format_List : DV
Video_Format_WithHint_List : DV (Sony)
Codecs Video : DV
Audio_Format_List : PCM
Audio_Format_WithHint_List : PCM
Audio codecs : PCM
Audio_Channels_Total : 2
[...]
File extension : avi
Format : AVI
Format : AVI
Format/Info : Audio Video Interleave
Format/Extensions usually used : avi
Commercial name : AVI DV
Commercial name : DV
Format profile : OpenDML
Format settings : BitmapInfoHeader / WaveFormatEx
Internet media type : video/vnd.avi
Interleaved : Yes
File size : 13579636736
File size : 12.6 GiB
File size : 13 GiB
File size : 13 GiB
File size : 12.6 GiB
File size : 12.65 GiB
Duration : 3631160
Duration : 1 h 0 min
Duration : 1 h 0 min 31 s 160 ms
Duration : 1 h 0 min
Duration : 01:00:31.160
Duration : 01:00:31:04
Duration : 01:00:31.160 (01:00:31:04)
Overall bit rate mode : CBR
Overall bit rate mode : Constant
Overall bit rate : 29918013
Overall bit rate : 29.9 Mb/s
Frame rate : 25.000
Frame rate : 25.000 FPS
Frame count : 90779
Stream size : 42672256
Stream size : 40.7 MiB (0%)
Stream size : 41 MiB
Stream size : 41 MiB
Stream size : 40.7 MiB
Stream size : 40.70 MiB
Stream size : 40.7 MiB (0%)
Proportion of this stream : 0.00314
Recorded date : 2007-02-11 10:05:26.000
File creation date : 2024-08-20 22:04:08.267 UTC
File creation date (local) : 2024-08-21 00:04:08.267
File last modification date : 2024-08-20 22:03:31.185 UTC
File last modification date (local) : 2024-08-21 00:03:31.185
TCOD : 0
TCDO : 36311600000
VMAJ : 4
VMIN : 0
STAT : 90779 0 3.315543 1
DTIM : 29838788 647722752

[LigH]

I hoped to see a (hexa-) decimal number of the audio format ... plain integer PCM would be a 2-char code equivalent to 1 (0001).

From now on I leave this topic to an actual developer of L-SMASH Works. I guess a debugger is required now.

[rgr]

Count : 285
Count of stream of this kind : 1
Kind of stream : Audio
Kind of stream : Audio
Stream identifier : 0
StreamOrder : 1
Inform : Count : 285 / Count of stream of this kind : 1 / Kind of stream : Audio / Kind of stream : Audio / Stream identifier : 0 / StreamOrder : 1 / Inform : Count : 285 / Count of stream of this kind : 1 / Kind of stream : Audio / Kind of stream : Audio / Stream identifier : 0 / StreamOrder : 1 / Inform : 1 024 kb/s, 32.0 kHz, 16 bits, 2 channels, PCM (Little / Signed) / ID : 1 / ID : 1 / Format : PCM / Format : PCM / Commercial name : PCM / Format settings : Little / Signed / Format settings, Endianness : Little / Format settings, Sign : Signed / Codec ID : 1 / Codec ID/Url : http://www.microsoft.com/windows/ / Duration : 3631160 / Duration : 1 h 0 min / Duration : 1 h 0 min 31 s 160 ms / Duration : 1 h 0 min / Duration : 01:00:31.160 / Duration : 01:00:31.160 / Bit rate mode : CBR / Bit rate mode : Constant / Bit rate : 1024000 / Bit rate : 1 024 kb/s / Channel(s) : 2 / Channel(s) : 2 channels / Sampling rate : 32000 / Sampling rate : 32.0 kHz / Samples count : 116197120 / Bit depth : 16 / Bit depth : 16 bits / Delay : 0 / Delay : 00:00:00.000 / Delay : 00:00:00.000 / Delay, origin : Stream / Delay, origin : Raw stream / Delay relative to video : 0 / Delay relative to video : 00:00:00.000 / Delay relative to video : 00:00:00.000 / Stream size : 464788480 / Stream size : 443 MiB (3%) / Stream size : 443 MiB / Stream size : 443 MiB / Stream size : 443 MiB / Stream size : 443.3 MiB / Stream size : 443 MiB (3%) / Proportion of this stream : 0.03423 / Alignment : Aligned / Alignment : Aligned on interleaves / Interleave, duration : 7.00 / Interleave, duration : 280 / Interleave, duration : 280 ms (7.00 video frames) / Interleave, preload duration : 280 / Interleave, preload duration : 280 ms / ID : 1 / ID : 1 / Format : PCM / Format : PCM / Commercial name : PCM / Format settings : Little / Signed / Format settings, Endianness : Little / Format settings, Sign : Signed / Codec ID : 1 / Codec ID/Url : http://www.microsoft.com/windows/ / Duration : 3631160 / Duration : 1 h 0 min / Duration : 1 h 0 min 31 s 160 ms / Duration : 1 h 0 min / Duration : 01:00:31.160 / Duration : 01:00:31.160 / Bit rate mode : CBR / Bit rate mode : Constant / Bit rate : 1024000 / Bit rate : 1 024 kb/s / Channel(s) : 2 / Channel(s) : 2 channels / Sampling rate : 32000 / Sampling rate : 32.0 kHz / Samples count : 116197120 / Bit depth : 16 / Bit depth : 16 bits / Delay : 0 / Delay : 00:00:00.000 / Delay : 00:00:00.000 / Delay, origin : Stream / Delay, origin : Raw stream / Delay relative to video : 0 / Delay relative to video : 00:00:00.000 / Delay relative to video : 00:00:00.000 / Stream size : 464788480 / Stream size : 443 MiB (3%) / Stream size : 443 MiB / Stream size : 443 MiB / Stream size : 443 MiB / Stream size : 443.3 MiB / Stream size : 443 MiB (3%) / Proportion of this stream : 0.03423 / Alignment : Aligned / Alignment : Aligned on interleaves / Interleave, duration : 7.00 / Interleave, duration : 280 / Interleave, duration : 280 ms (7.00 video frames) / Interleave, preload duration : 280 / Interleave, preload duration : 280 ms
ID : 1
ID : 1
Format : PCM
Format : PCM
Commercial name : PCM
Format settings : Little / Signed
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Codec ID/Url : http://www.microsoft.com/windows/
Duration : 3631160
Duration : 1 h 0 min
Duration : 1 h 0 min 31 s 160 ms
Duration : 1 h 0 min
Duration : 01:00:31.160
Duration : 01:00:31.160
Bit rate mode : CBR
Bit rate mode : Constant
Bit rate : 1024000
Bit rate : 1 024 kb/s
Channel(s) : 2
Channel(s) : 2 channels
Sampling rate : 32000
Sampling rate : 32.0 kHz
Samples count : 116197120
Bit depth : 16
Bit depth : 16 bits
Delay : 0
Delay : 00:00:00.000
Delay : 00:00:00.000
Delay, origin : Stream
Delay, origin : Raw stream
Delay relative to video : 0
Delay relative to video : 00:00:00.000
Delay relative to video : 00:00:00.000
Stream size : 464788480
Stream size : 443 MiB (3%)
Stream size : 443 MiB
Stream size : 443 MiB
Stream size : 443 MiB
Stream size : 443.3 MiB
Stream size : 443 MiB (3%)
Proportion of this stream : 0.03423
Alignment : Aligned
Alignment : Aligned on interleaves
Interleave, duration : 7.00
Interleave, duration : 280
Interleave, duration : 280 ms (7.00 video frames)
Interleave, preload duration : 280
Interleave, preload duration : 280 ms

[LigH]

OK: Codec-ID = 1, stereo, 32000 Hz, 16 bits, Little Endian a.k.a. intel order; as simple as an audio stream in an AVI file could be. What else might be an issue? The interleaving each 7 frames? Indexing PCM in general (may cause huge indexes)?

BTW, indexing PCM audio can take a long time. This is not a crash.

[FranceBB]

Hey rgr, the developer of LWLibav is asd-g, he's very friendly and approachable and he's generally very happy to fix bugs, but he rarely checks this topic. It might be worth opening an issue on GitHub as well Link (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues)

That being said, stereo PCM Little Endian 32000Hz 16bit in an AVI container is indeed a rather weird combination.

[LigH]

That being said, stereo PCM Little Endian 32000Hz 16bit in an AVI container is indeed a rather weird combination.

Not in my opinion. When AVI was developed first in VfW 1.x for Windows 3.x, hardly any other audio format than PCM was imaginable, most of all no VBR audio. Little-endian 16 bit is most common on intel CPUs where Windows runs on IBM compatible PCs. Only the 32 kHz sampling rate is typical to DV, yet common enough. And long interleaving distances (each 7 video frames instead of each frame) is not a reason for trouble either.

[FranceBB]

Probably, yes. It's just that I've rarely seen 32000Hz.
It seems to be standard for DV, but I've mostly seen 44100Hz and 48000Hz for every other source, which is why I found it to be a bit unusual. I think this is probably because hardware decoders resample it to 48000Hz anyway? Dunno. When I playback miniDV on a Sony player via SDI and record them using a Blackmagic Decklink card in v210 with PCM audio they're always 48000Hz 24bit so I guess the decoder is resampling it and saving it in a different bit depth too. It doesn't surprise me as it's a bit like when you make a DolbyE 44800Hz 20bit stream go through a hardware decoder and it automatically becomes 48000Hz 24bit PCM.


Anyway it was cool to see the real file, I mean what was actually on the miniDV tape in the form of an .avi file, that's all. :)

[LigH]

Sound Blaster 1.x cards had an even more weird common sampling rate of 22222 Hz.

Anyway, I don't expect any sampling rate per se to be a reason for a software crash of a container parser, splitter, or audio decoder.

[Z2697]

Help please
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/73

[foxyshadis]

Sound Blaster 1.x cards had an even more weird common sampling rate of 22222 Hz.

Anyway, I don't expect any sampling rate per se to be a reason for a software crash of a container parser, splitter, or audio decoder.

All the way up through the Pro line; 2.x even introduced 43478 kHz for attempts to get 44100. They were all rounded to integer multiples of a small fraction of the i8051 timer they used. Only SB16 finally had true standard sampling rates.

[wonkey_monkey]

Is there anyone who could give me some pointers on how to compile L-SMASH Source from scratch with Visual Studio? I don't really know what I'm supposed to download or how to join it all together...

[Jamaika]

Is there anyone who could give me some pointers on how to compile L-SMASH Source from scratch with Visual Studio? I don't really know what I'm supposed to download or how to join it all together...
Please note that lsmash doesn't work with the latest version of ffmpeg.

[qyot27]

Is there anyone who could give me some pointers on how to compile L-SMASH Source from scratch with Visual Studio? I don't really know what I'm supposed to download or how to join it all together...

Broadly speaking, there are two dependency trees: l-smash and FFmpeg.
obuparse->l-smash
[FFmpeg dependencies*]->FFmpeg

And once those are satisfied, you can build the L-SMASH-Works/AviSynth plugin. Since all of the dependent libs are C libraries, it is most probably far easier to manage by building or installing them via MSys2 with MinGW-w64 and GCC rather than attempting to build it all through Visual Studio.

For FFmpeg, its dependencies can be a bit of a maze, but for LSMASHSource (or FFMS2) you don't need most of them, and you can trim down the size of the built FFmpeg libs so that you're not linking in things you won't even be using (encoders, muxers, stuff like that). The general compression libraries (zlib, bzip2, lzma) and possibly iconv are the only ones that would be *vital*. Then you get into more nuanced choices like whether to use libdav1d to enable AV1 decoding, or - since we are talking about LSMASHSource - if you want to enable hwdec support by using nv-codec-headers (nvidia) and/or libvpl (Intel QSV).

FFmpeg can actually be built by Visual Studio, by dropping into an MSys2 shell from inside the VS Command Prompt, and then using the --toolchain=msvc option when configuring. Not all of the other dependencies in either the FFmpeg or l-smash trees are guaranteed to be able to do that, though, which is why I said it's probably just easier to install or build them through MSys2 with MinGW rather than trying to use VS to do it all. You just need to build the plugin itself with VS.

[wonkey_monkey]

Thanks! But hmm... maybe I should just ask you instead of trying to do it myself just yet :D

Do you think they might be any way to improve loading speeds? I'm working on a project with dozens of Blu-ray rips as input - doing some tests on a subset, LibavSource2 (LSMASHVideoSource/AudioSource fails on my files) takes 1m38s before VirtualDub is ready, whereas FFMpegSource2 takes 13 seconds. But L-SMASH Source seems to have much better audio seeking so it's still my preferred option.

Also forgive my stupidity but... if I set ff_loglevel to >0, where will I find said logs? :confused:

Edit: oops... I think I mistook you for an author of L-SMASH, probably because I've seen your name on the AvisynthPlus GitHub and got mixed up. If you happen to know the answer or can hazard a guess, great, but otherwise, sorry!

[qyot27]

If I had to hazard a guess regarding the difference in indexing times and loading times, perhaps it's down to the methods by which the indices are written, and how they're read back. I can't find any actual reference to FFMS2's index format apart from it being zlib-compressed and an 'fwrite of internal structures to disk', along with mentions of how it differs between indices written by the 32-bit version vs. the 64-bit version in relation to size_t. A format like that would ostensibly be way faster to write and naturally more compact, even before taking zlib into account, but whether that's the reason for the seeking taking longer (vs. that being more related to the zlib compression part than to the way the data is formatted), I don't know.

LSMASHSource, by contrast, writes uncompressed indices in what looks like either straight XML or something very close to it. So the indices are much larger and way more verbose, and would take longer to write; but when seeking, they don't have the overhead of being compressed, and could take advantage of optimized XML parsers, leading to much lower latency.

[wonkey_monkey]

That was roughly my thinking too, although I would expect ffmpeg to decompress fully on load, and L-SMASH to fully parse to internal structures on load, so I wouldn't think there'd be much difference once they're loaded. It's just (again, assuming) the loading that's slow for L-SMASH because it's parsing that large human-readable index file.

Incidentally I think I discovered the source of my ffms2 audio seeking trouble, which is what made me switch to L-SMASH in the first place. I've created an issue on Github about it, but the gist of it is that I don't think audio is being indexed for MKV files.

[wonkey_monkey]

it's probably just easier to install or build them through MSys2 with MinGW rather than trying to use VS to do it all.

I'm trying this now but can't work out how to do a static build. Any ideas? Googling tells me it should something along the lines of

./configure --pkg-config-flags="--static" --extra-libs="-lpthread -lm" --enable-static --disable-shared --disable-debug --disable-doc --disable-ffplay --disable-ffprobe

but that still gives me a dynamically-linked ffmpeg.exe (it complains about missing DLLs unless I run it from within MSYS2) and there's no sign of any .lib files.

And "./configure --help" doesn't list "--enable-static" and "--disable-shared" as switches - instead it has "disable static [no]" and "enable-shared [no]" :confused:

https://i.imgur.com/KMEakvU.png

[LigH]

Building my AudioBoost plugin (https://github.com/LigH-de/AudioBoost), I had to learn that AviSynth plugins using the AviSynth C++ API are not ABI cross-compatible with the avisynth.dll among different compilers. Both have to be compiled with the same. The official AviSynth+ installer ships with an avisynth.dll compiled with MSVC, so compatible plugins using the C++ API have to, as well. Or you need to compile your avisynth.dll with MinGW and GCC as well as all your plugins you want to use with it.

The exception is the older C API (LoadCPlugin).

[qyot27]

I'm trying this now but can't work out how to do a static build. Any ideas? Googling tells me it should something along the lines of

./configure --pkg-config-flags="--static" --extra-libs="-lpthread -lm" --enable-static --disable-shared --disable-debug --disable-doc --disable-ffplay --disable-ffprobe

but that still gives me a dynamically-linked ffmpeg.exe (it complains about missing DLLs unless I run it from within MSYS2) and there's no sign of any .lib files.

And "./configure --help" doesn't list "--enable-static" and "--disable-shared" as switches - instead it has "disable static [no]" and "enable-shared [no]" :confused:

https://i.imgur.com/KMEakvU.png

Slightly amended from the cross-compile instructions for Linux->Windows, assuming that a folder named mpv-build-deps is in your $HOME directory on MSys2:
cd ~/mpv-build-deps && \
git clone git://source.ffmpeg.org/ffmpeg.git && \
mkdir -p ffmpeg/ffmpeg-build/{i686,amd64} && \


amd64
+++++

cd ~/mpv-build-deps/ffmpeg/ffmpeg-build/amd64 && \
../../configure --prefix=$HOME/ffmpeg_build_minimal/amd64 \
--enable-gpl --enable-version3 --disable-w32threads --disable-encoders \
--disable-muxers --disable-doc --disable-debug --disable-devices \
--disable-avdevice --enable-libdav1d --extra-cflags="-march=native" \
--target-os=mingw32 --arch=x86_64 && \
make -j$(nproc) && \
make install

i686
+++++

cd ~/mpv-build-deps/ffmpeg/ffmpeg-build/i686 && \
../../configure --prefix=$HOME/ffmpeg_build_minimal/i686 \
--enable-gpl --enable-version3 --disable-w32threads --disable-encoders --disable-muxers \
--enable-libdav1d --disable-doc --disable-debug --disable-devices --disable-avdevice \
--cpu=pentium3 --extra-cflags="-m32 -mfpmath=sse -march=pentium3 -msse -mtune=pentium3" \
--extra-ldflags="-m32 -L/mingw32/lib" \
--windres="windres -F pe-i386" --target-os=mingw32 --arch=x86 && \
make -j$(nproc) && \
make install

And the static libraries are the .a files in the $HOME/ffmpeg_build_minimal/{amd64,i686}/lib directory.



Building my AudioBoost plugin (https://github.com/LigH-de/AudioBoost), I had to learn that AviSynth plugins using the AviSynth C++ API are not ABI cross-compatible with the avisynth.dll among different compilers. Both have to be compiled with the same. The official AviSynth+ installer ships with an avisynth.dll compiled with MSVC, so compatible plugins using the C++ API have to, as well. Or you need to compile your avisynth.dll with MinGW and GCC as well as all your plugins you want to use with it.

The exception is the older C API (LoadCPlugin).
The above is about compiling FFmpeg. All the *dependencies* for LSMASHSource can be built with GCC, but the plugin shouldn't be.

[wonkey_monkey]

Slightly amended from the cross-compile instructions for Linux->Windows, assuming that a folder named mpv-build-deps is in your $HOME directory on MSys2:

Thanks, that worked... but doesn't seem to have got much further than the previous builds I was doing. They were giving me .a files already, it turned out (apart from libpostproc.a, that's a new one), and don't I need .lib files if I'm trying to link to ffmpeg from a Visual Studio C++ project? :confused:

I'm using the MSYS2 UCRT64 environment, if that means anything to anyone...

I would also still like to solve the mystery of building a fully static and self-contained ffmpeg.exe. It seems I'm fatally cursed to never really understand building so it would nice to win just once...

-------------------------------------------------------------------------------------------------

I skipped ahead a bit just tried to build L-SMASH-Works to see what would happen. First error: it needs lsmash.h. So I got the vimeo/lsmash repo, try to build that, and I get:

error MSB8020: The build tools for Visual Studio 2013 - Windows XP (Platform Toolset = 'v120_xp') cannot be found. To build using the v120_xp build tools, please install Visual Studio 2013 - Windows XP build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution".

Only there's no such "Retarget solution" option in either of the places mentioned.

Is it just me this happens to? :mad:

[qyot27]

Thanks, that worked... but doesn't seem to have got much further than the previous builds I was doing. They were giving me .a files already, it turned out (apart from libpostproc.a, that's a new one), and don't I need .lib files if I'm trying to link to ffmpeg from a Visual Studio C++ project? :confused:
.lib and .a files are just archives, and because MSVC and GCC (or Clang) are more or less compatible on the topic of C-based ABIs, you can just use the .a files if you're in MSVC and trying to link to something built by GCC/MinGW. But you can't do that if the thing that GCC built was C++, because they aren't compatible with each other's C++ ABIs.

You can literally just rename the .a to .lib and it should also work.

I'm using the MSYS2 UCRT64 environment, if that means anything to anyone...
Generally, I don't know. UCRT vs. MSVCRT isn't something I've delved into all that much.

I would also still like to solve the mystery of building a fully static and self-contained ffmpeg.exe. It seems I'm fatally cursed to never really understand building so it would nice to win just once...
I mean, how much time do you have to kill? (https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt) You don't have to have a Linux partition set up, installing Ubuntu through WSL2 works as well.

The FFmpeg part works fine; now that I think about it, I don't think I've been able to get a correctly working full-fat mpv build since they switched to meson (and the cd-paranoia binary was borked this time around too; I need to investigate what's happening).

[wonkey_monkey]

.lib and .a files are just archives

You can literally just rename the .a to .lib and it should also work.

Ah okay, cool. I mean I have no idea which of these .a files does what but maybe I'll figure that out once I get that far. I edited my previous post to add my next frustration...

I mean, how much time do you have to kill? (https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt) You don't have to have a Linux partition set up, installing Ubuntu through WSL2 works as well.

Eh... right now I'd just settle for knowing whether I am completely misunderstanding everything.

A static build of ffmpeg.exe means it would be self-contained and won't rely on any other DLLs, right? Am I just completely deluded to think that that's what I'd get if I follow the instructions of various posts online that say "--enable-static" and "--disable-shared"?

Whenever I try to do anything like this I just end up feeling like you have to be born with this knowledge. Someone puts a bunch of source files on Github and everyone else already seems to know exactly what to do with them in any conceivable situation and there never seems to be any documentation that's of any use to an idiot like me...

[qyot27]

A static build of ffmpeg.exe means it would be self-contained and won't rely on any other DLLs, right?
That's a hard maybe. If you build the dependencies as static, then yes as far as those go. But the toolchains might require you pass additional flags to the linker or the compiler that point it at the static versions of the compiler's libraries.

Just as an example of this, when I built things for Windows on ARM using llvm-mingw, there were a handful of libraries the compiler itself was linking against FFmpeg that I then had to fix (by either copying the .dlls around or deleting the .dll.a so that the compiler wouldn't default to the shared version instead of the static one). This will ultimately require tweaking the options given when building the toolchain.

Am I just completely deluded to think that that's what I'd get if I follow the instructions of various posts online that say "--enable-static" and "--disable-shared"?
Options on enabling or disabling either static or shared are often A) determined by how the project designed their build system in terms of which one is the default and which isn't, and B) largely only applies to that library or program itself, but not necessarily to any dependencies it was linked to.

Whenever I try to do anything like this I just end up feeling like you have to be born with this knowledge. Someone puts a bunch of source files on Github and everyone else already seems to know exactly what to do with them in any conceivable situation and there never seems to be any documentation that's of any use to an idiot like me...
Part of that is that there are several build systems (autotools, CMake, meson, waf, etc.) in common use today, and these generally have some way of querying the configuration options, which in themselves can be fairly standard and applicable to other projects that use the same build system.

This is why advice that you need to run './configure ; make ; make install' is so ubiquitous - that's the way autotools (and some custom-designed, like x264's or FFmpeg's) systems work, and for many years, autotools was the most widely-used - or at least most strongly associated - build system for *nix stuff or FOSS more generally. Those commands are wrong for CMake and meson, even if the sequence itself is correct - all of them have distinct configuration, build, and install processes.

That's changed more recently, with build systems like CMake or meson gaining a lot of popularity. Generally, any of these systems have a core set of options you can set because they're built into the build system itself (stuff like setting an install directory, or some method of setting the C or C++ compiler, etc.), and then there are project-specific ones that you need to look at the output of './configure --help', or searching CMakelists.txt for things being toggled or set with 'option' or 'set' keywords, or the list of options described in the meson_options (or meson.options) file.

And while some or most projects are probably simple enough to use a generic, default set of options, the more complex or intricate a project is, the more likely it is that the project-specific options matter, and it requires some degree of trial and error to come up with the set of options that you personally want.

[Z2697]

I personally use media-autobuild_suite to build the static FFmpeg with custom options and start from there

[wonkey_monkey]

Thanks for taking the time to write all that, qyot27.

Don't ask me how (I've written it all down in case anyone ever needs to know, but it's been long and arduous), but with your instructions and a lot of stubbornness, I've somehow bumbled my way this far, after building lsmash, zlib, xxhash, and ffmpeg:

https://i.imgur.com/B5mmI7r.png

Any idea what I should do now?:confused:

[StvG]

.lib and .a files are just archives, and because MSVC and GCC (or Clang) are more or less compatible on the topic of C-based ABIs, you can just use the .a files if you're in MSVC and trying to link to something built by GCC/MinGW. But you can't do that if the thing that GCC built was C++, because they aren't compatible with each other's C++ ABIs.

You can literally just rename the .a to .lib and it should also work.

Building static ffmpeg with GCC (MinGW) and use it for MSVC-like L-SMASH-Works will not work. Building dynamic ffmpeg libs with GCC (MinGW) and use it for MSVC-like L-SMASH-Works would be ok.

@wonkey_monkey,
1. From "x64 Native Tools Command Prompt for VS..." type "path_to_msys\msys2_shecll.cmd -ucrt64 -use-full-path". You can replace "-ucrt64" with "-mingw64" if you want but prefer ucrt64 if you wouldn't use the plugin on older OS than Windows 10.
2. Go to msys64\usr\bin and rename "link.exe" to "link_.exe"
3. Use this script (https://pastebin.com/AT2TVMnN) to build ffmpeg and its dependencies. - from the ucrt64 shell type "./the_saved_script"
Change lines 5~15 if needed.
Download dav1d settings (https://pastebin.com/NJmsBRQd). Change line #7 to the actual path+file_name.
4. Rename back "link_.exe" to "link.exe" and you can close the ucrt64 shell.
5. Download obuparse (https://github.com/dwbuiten/obuparse) and l-smash (https://github.com/vimeo/l-smash) source codes.
Download VS solution files (https://files.catbox.moe/1iyvt2.7z) for them and extract them in the root of the relevant folders. Copy "obuparse.h" in the root of the l-smash folder. Build the libs with VS. Manually move "obuparse.h" and the lib in the relevant folders where FFMpeg is installed. Manually move "lsmash.h" and the lib in the relevant folders where FFMpeg is installed.
6. In the "x64 Native Tools Command Prompt for VS..." window navigate to the L-SMASH-Works source. Type "cmake -B build_folder -DCMAKE_PREFIX_PATH="path_to_folder_where_are_include/lib_directories" -Dsome_other_options(for e.g., -DENABLE_VPX=OFF)"
By default VS solution files will be created. Open it and build the plugin.

[wonkey_monkey]

I got as far as step 3 and then:

[41/41] Linking C executable minigzip64.exe
ninja: Entering directory `build_x64'
[0/1] Install the project...-- Install configuration: "Release"
-- Installing: C:/msys64/home/David/deps/x64-Release/lib/libzlib.dll.a
-- Installing: C:/msys64/home/David/deps/x64-Release/bin/libzlib.dll
-- Installing: C:/msys64/home/David/deps/x64-Release/lib/libzlibstatic.a
-- Installing: C:/msys64/home/David/deps/x64-Release/include/zconf.h
-- Installing: C:/msys64/home/David/deps/x64-Release/include/zlib.h
-- Installing: C:/msys64/home/David/deps/x64-Release/share/man/man3/zlib.3
-- Installing: C:/msys64/home/David/deps/x64-Release/share/pkgconfig/zlib.pc

mv: cannot stat 'zlibstatic.lib': No such file or directory


There are two copies of libstatic.a in the following locations:


C:\msys64\home\David\zlib-1.3.1\build_x64\libzlibstatic.a
C:\msys64\home\David\deps\x64-Release\lib\libzlibstatic.a

[StvG]

I got as far as step 3 and then:

[41/41] Linking C executable minigzip64.exe
ninja: Entering directory `build_x64'
[0/1] Install the project...-- Install configuration: "Release"
-- Installing: C:/msys64/home/David/deps/x64-Release/lib/libzlib.dll.a
-- Installing: C:/msys64/home/David/deps/x64-Release/bin/libzlib.dll
-- Installing: C:/msys64/home/David/deps/x64-Release/lib/libzlibstatic.a
-- Installing: C:/msys64/home/David/deps/x64-Release/include/zconf.h
-- Installing: C:/msys64/home/David/deps/x64-Release/include/zlib.h
-- Installing: C:/msys64/home/David/deps/x64-Release/share/man/man3/zlib.3
-- Installing: C:/msys64/home/David/deps/x64-Release/share/pkgconfig/zlib.pc

mv: cannot stat 'zlibstatic.lib': No such file or directory


There are two copies of libstatic.a in the following locations:


C:\msys64\home\David\zlib-1.3.1\build_x64\libzlibstatic.a
C:\msys64\home\David\deps\x64-Release\lib\libzlibstatic.a


Open zlib-xxx folder and go to build_xxxx, open CMakeCache.txt and check what is CMAKE_C_COMPILER. It seems you're building with GCC instead of cl/clang-cl.

Edit: Do not remove lines #5, 6, 7 if you don't use clang-cl just change "clang-cl" to "cl" and remove only line #7.
Edit1: Maybe also uncomment lines 53-55.

[wonkey_monkey]

Open zlib-xxx folder and go to build_xxxx, open CMakeCache.txt and check what is CMAKE_C_COMPILER. It seems you're building with GCC instead of cl/clang-cl.

CMAKE_C_COMPILER:FILEPATH=C:/msys64/ucrt64/bin/cc.exe

I commented out the line numbers you mentioned (plus line 41, "fi"), since I've never dealt with Clang.

Edit: Do not remove lines #5, 6, 7 if you don't use clang-cl just change "clang-cl" to "cl" and remove only line #7.

Trying this next.

[wonkey_monkey]

After installing meson (mingw-w64-ucrt-x86_64-meson), I've now got:

Could not find any valid candidate for cross files: C:/uc/dav1d_cross.txt

ERROR: Cannot find specified cross file: C:/uc/dav1d_cross.txt

[StvG]

Ops, forgot it. Here (https://pastebin.com/NJmsBRQd). Save it and change the path in the script. Rename "clang-cl" with "cl" and remove "strip" and "linker" lines.

Edit: Also lines 272, 273 must be removed or change it to "cl" instead "clang-cl"

[wonkey_monkey]

Thanks.

Hmm. This is odd. On running the script again I got:

Cloning into 'ffmpeg'...
warning: Could not find remote branch custom-patches-for-lsmashsource-1 to clone.
fatal: Remote branch custom-patches-for-lsmashsource-1 not found in upstream origin


I deleted all the created folders and tried again but it only got a few steps in - definitely not as far as last time - before repeating the above.

[StvG]

Change line #54 from "custom-patches-for-lsmashsource-1" to "custom-patches-for-lsmashsource".

[wonkey_monkey]

Ah I see, those were the lines I uncommented. Now the error makes sense.

I got another clang-cl error so I changed the PKG_CONFIG_PATH definition (lines 272 and 273).

I now see what looks like ffmpeg ./configure completing, and then:

WARNING: using libmfx without pkg-config
WARNING: libmfx is deprecated. Please run configure with --enable-libvpl to use libvpl instead.
GEN libavfilter/libavfilter.version
GEN libavformat/libavformat.version
GEN libavcodec/libavcodec.version
GEN libswresample/libswresample.version
GEN libswscale/libswscale.version
GEN libavutil/libavutil.version
CC libavfilter/allfilters.o
CC libavfilter/buffersrc.o
CC libavfilter/avfiltergraph.o
allfilters.c
CC libavfilter/audio.o
buffersrc.c
CC libavfilter/avfilter.o
avfiltergraph.c
CC libavfilter/buffersink.o
audio.c
C:/msys64/ucrt64/bin/../include\math.h(202): error C2065: '__asm__': undeclared identifier
C:/msys64/ucrt64/bin/../include\math.h(202): error C2146: syntax error: missing ';' before identifier '__volatile__'


followed by another 2000 or lines of errors, mostly about the word 'type' being a syntax error. IIRC Visual Studio doesn't do inline assembler on x64...

[StvG]

Do you have "nasm" installed?

[wonkey_monkey]

Do you have "nasm" installed?

Only in MSYS2. Do I need to install it Windows-wide and integrate it into Visual Studio or something?

[StvG]

Try with installing it on the Windows-wide and reopen the ucrt64 shell from vs cmd to get nasm in the path.

Edit: I will try it myself now with cl (I always use clang-cl) to see if there are errors.

Edit1: No issues from my side. ffmpeg is build.

Edit2: I updated the script link in the instruction post so to be more user friendly.

[wonkey_monkey]

Try with installing it on the Windows-wide and reopen the ucrt64 shell from vs cmd to get nasm in the path.

Edit: I will try it myself now with cl (I always use clang-cl) to see if there are errors.

Done (and I added the path to the system-wide nasm.exe in environment variables), but with no change to the errors. MSYS2's nasm.exe was already in MSYS2's path.

Perhaps I should get clang...

[StvG]

Mmm. MSYS2 nasm shouldn't be issue because when I type in the ucrt64 shell "where nasm" I get "C:\msys64\ucrt64\bin\nasm.exe". You need "mingw-w64-ucrt-x86_64-nasm".

If you didn't see the other edits from my previous post I updated the script to be more friendly. Also you can use vcpkg (https://github.com/microsoft/vcpkg) to build ffmpeg with MSVC much more easily.

Edit: for vcpkg you can see an example here (https://github.com/vapoursynth/bestsource?tab=readme-ov-file#windows-compilation).

[wonkey_monkey]

Yup, that's the same result I get from "where nasm". But I haven't done anything to tell Visual Studio/cl.exe to use nasm when it finds inline assembler, if that can even be done...

I tried with the new version of script, with these changes:

compiler="cl"
cmake_path="/c/Program Files/CMake/bin/cmake"
dav1d_cross_file="/c/msys64/home/David/dav1d_cross.txt"

but still get the errors.

[StvG]

Share "config.log" from "ffmpeg\ffbuild".

Also "config.h" and "config_components.h", and "config.asm" from "ffmpeg".

[wonkey_monkey]

Share "config.log" from "ffmpeg\ffbuild".

Also "config.h" and "config_components.h", and "config.asm" from "ffmpeg".

https://horman.net/avisynth/ffmpeg_stuff.zip

[StvG]

Thanks. Found the issue (I thought modifying mingw header was only necessary clang-cl). Use this script https://pastebin.com/gJTFMdzd

[wonkey_monkey]

Thanks. Found the issue (I thought modifying mingw header was only necessary clang-cl). Use this script https://pastebin.com/gJTFMdzd

This gets me further, thanks (and thank you very much for your continued efforts and patience).

I was getting a few instances of this:

Cannot open include file: 'stdalign.h'

I haven't found a definite solution so far, but it seems stdalign.h isn't included/supported in Visual Studio. The file does exist within MSYS2 though - I added the path to --extra-cflags in PKG_CONFIG_PATH, and now I get:

Compiler lacks support for C11 static assertions

Here's ffbuild\config.log: https://pastebin.com/Fk7Feuc2

[StvG]

I have it - https://i.ibb.co/VcyPrtKQ/Untitled.png. Try to install the latest Windows SDK or reinstall the one you have.

[wonkey_monkey]

I have it - https://i.ibb.co/VcyPrtKQ/Untitled.png. Try to install the latest Windows SDK or reinstall the one you have.

Yup, i installed the latest SDK and it has the file.

I'll try running the script again tomorrow to see if I still get the same C11 static error.

[StvG]

In case you didn't already you can delete from line 42 to 207 from the script in order to run only the ffmpeg part.