cl is unable to create an executable file/ plus DASH play issues

[mediabuff]

I use the batch file for building ffmpeg. Which demands that I run that in a pure 'cmd' shell. Which I did - but I get the above error. If I run in a configured cmd 'x86, the compilation seems to work. Some thing wrong in the setup of the compiler env ?

[brabebhin]

You should probably redo the build setup.

[lukasf]

Yes, you probably missed one of the prerequisites setup steps. Maybe you did not install the ARM or ARM64 compiler tools from VS Installer?

For a detailed error, check the build log file, e.g. ffmpeg\Output\Windows10\ARM\ffbuild\config.log for the ARM build log.

[brabebhin]

I recently had a build error on arm/64 due to invalid/corrupted gcc package in msys2.

[mediabuff]

I am not building for ARM. Was building for x86.

[lukasf]

I can only help you if you post detailed build logs. So for x86, post ffmpeg\Output\Windows10\x86\ffbuild\config.log and also paste the complete CMD output here.

Alternatively, you can also try the new PowerShell based build script. It gives you much better control over which SDK and toolset versions you want to use. This will probably replace the old build script soon, so you might directly want to jump for this, it works very well already.

This will build x86, it defaults to 141 C++ toolkit and 10.0.18362.0 SDK:

powershell -ExecutionPolicy Bypass -File .\Build-FFmpeg.ps1 -Platforms x86

You can easily override the SDK and toolkit. This would build with 142 toolkit and 10.0.17763.0 SDK:

powershell -ExecutionPolicy Bypass -File .\Build-FFmpeg.ps1 -Platforms x86 -VcVersion 14.2 -WindowsTargetPlatformVersion 10.0.17763.0

The above commands are ment to be run from a clean CMD, in FFmpegInteropX folder. Alternatively, you can of course directly run the script from a clean PowerShell instance, with less parameters:

.\Build-FFmpeg.ps1 -Platforms x86

[mediabuff]

Thanks for you for your support. Followed powershell instructions verbatim and have attached the log.

From a clean cmd prompt: powershell -ExecutionPolicy Bypass -File .\Build-FFmpeg.ps1 -Platforms x86 -VcVersion 14.2 -WindowsTargetPlatformVersion 10.0.17763.0 > c:\temp\ffmpegcompile.log

(url ffmpegcompile.log )

[lukasf]

And the ffmpeg config.log?

[lukasf]

Also, some important log messages (such as path, lib, sdk folders) are logged into error out (this is strange behavior of the ffmpeg build script). You have only redirected the standard out. It is better if you just run the command normally from a blank cmd, then copy all and paste into a file. That way, you capture both standard and error out.

And as I said, I'd also need the config.log, since the exact build error message is only logged there, not in the CMD output.

[mediabuff]

Attached both logs.

config.log

ffmpegcompile.log

[mediabuff]

Failure point in config.log est_cc BEGIN ./ffconf.9Qz24zrE/test.c 1 int main(void){ return 0; } END ./ffconf.9Qz24zrE/test.c cl.exe -nologo -c -Fo./ffconf.9Qz24zrE/test.o ./ffconf.9Qz24zrE/test.c test.c /c/MyDevProjects/MyProjectsThirdPartyLibs/FFmpegInteropX/ffmpeg/compat/windows/mslink -nologo -out:./ffconf.9Qz24zrE/test.exe ./ffconf.9Qz24zrE/test.o LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib' C compiler test failed.

[lukasf]

LIBCMT.lib is a library that is part of the compiler tools. So somehow your VS installation is incomplete. Maybe you are missing some installer options.

Can you please try the following in VS Installer:

1. Expand the "Universal Windows Platform development" workload on the right (under "Installation details"). Make sure "C++ (v142) Universal Windows Platform tools" is selected.

2. Open "Individual components", in "Compilers" section, make sure you have "MSVC v142 - VS2019 C++ x86/x64 build tools (latest version)" selected.

If that does not help, you could try installing v141 tools and compile with that. Again, make sure you have both the UWP tools on the right panel, plus the compilers in optional components.

If all that does not work, please try selecting the "Desktop development with C++" workload. Again make sure you select the v142 or v141 tools in the panel on the right.

[mediabuff]

I have 2017, 2019 and 2019 Preview installed. 2019 is not a full install but 2019 Preview is. The script doesn't pick up the preview.

Since, 2019 is no a full install, I have uninstalled that. So, now the scripts are using 2017 tools. Still the same issue.

1. "Universal Windows Platform development " is installed. Attached

2. Compiles - see attached

[lukasf]

Ok that explains why the build did not work. On VS2017, you need to select a few additional components. Please check the "prerequisites" list on our readme.md and see if all of them are installed.

[lukasf]

Alternatively, I think it should be possible to make the script pick up the VS2019 preview. Try adding this to your PS call:

-VsWhereCriteria '-latest', '-prerelease'

[mediabuff]

Same issue with the '2019 preview' version. Can't be my installation - tried 3 versions - all standard installations.

[lukasf]

Sorry to hear that it is still not running. You are the first one to report so many problems, all others were able to get this running smoothly.

Are you sure that the script actually picked up the preview? I don't have a preview installed so I cannot verify those parameters. You should be able to see from cmd output which tools are used. The VS2019 install was not complete, so it is no surprise that it did not work. Did you install all prerequisites for VS2017 as listed in readme.md? A standard installation is not sufficient.

Also generally, it is not a good idea to use preview versions for creating production software. I'd rather recommend to uninstall VS2017 and install a regular VS2019 with all required prerequisites.

[lukasf]

I have just pushed a new PR to master, which improves debug output of the new build script. It will print out all the environment variables, so we can see which lib, include and path are actually being set.

[mediabuff]

Attached new logs for preview version: config.log ffmpegcompile.log

[lukasf]

Ok the new logging helped here:

[ERROR:vcvars.bat] Toolset directory for version '14.1' was not found.

You need to pass "-VcVersion 14.2" in the build script to select v142 compiler tools. Or you must install v141 compilers, plus "C++ (v141) Universal Windows Platform tools" from Universal Windows Platform development workload optional components.

Expand the "Universal Windows Platform development" workload on the right (under "Installation details"). Make sure "C++ (v142) Universal Windows Platform tools" is selected.

[mediabuff]

Thanks for your support thus far. Still the same issue.

1. Tried -VcVersion 14.2 . Attached logs

config.2019preview.142tools.log ffmpegcompile.2019preview.142tools.log

2. Installed v141 compiles. Attached logs

ffmpegcompile.2019preview.141tools.log config.2019preview.141tools.log

[brabebhin]

I think you should uninstall all visual studio versions and go with vs2017. We know for sure 2017 works. 2019 is still weird-ish.

[lukasf]

You have selected those C++ UWP Tools right?

I only have VS2019 installed on my main dev machine (non preview) and it worked right from the start. VS2017 also worked without any issues. I also had both installed in parallel on my older dev installation, both worked without issues. I don't know what is wrong with your installation. Both latest logs you posted show successful vcvarsall, but both do not find LIBCMT.lib when the compiler is invoked.

Maybe the preview version just has some bugs. Or your installation is somehow corrupted. Either you should install a regular VS2019, or you need to setup VS2017 to include all required prerequisites and try with that. As I already said, I generally would not recommend to use preview versions for real development purposes. The official VS release versions have more than enough bugs, believe me ;)

[mediabuff]

I give up and move on to builds from https://github.com/ShiftMediaProject. Much saner build process for native Visual environment.

[lukasf]

Sure, you can also take ffmpeg builds from other places. There are also a few ffmpeg nuget packets (although often not up to date). But if you build a Store App, you need to be sure to get UWP builds, otherwise you will fail store certification. SMP builds are Win32 desktop, not UWP, afaik.

Some features of this lib (especially in subtitles area) might not work, if you use arbitrary builds without the added zlib, bz2 and iconv.

[mediabuff]

lukasf, immensely appreciated your support. Will continue to engage in this repo.

On your comments.

SMP builds are Win32 desktop, not UWP, afaik.

Yes, understand. Convincing the author to get a UWP build. He is getting closer. At least for playing/streaming videos (without bluray support etc).

I was able to get FFmpegInteropX working with SMP desktop build and a hacked-up build for UWP. By hacked-up I mean, mixed build, using the dependencies in SMP which are enabled for Winrt and desktop libs for those that are not.

Performance, stability and video quality - for dash streaming - such as BBC

I am compared FFmpegInteropX , VLC and plain vanilla browser. All browsers beat the hell out of the native players (both ffmpeg and VLC). They are responsive, super smooth and do the highest quality stream 720 or 1080p faithfully.

VLC comes next best. Stable - but not as smooth and of mediocre quality.

FFmpegInteropX is definitely unusable - stalls, freezes and resource intensive. Possibly because the network stack in ffmpeg is not performant under UWP and also all the baggage of Microsoft media foundation framework. I don't know what the future is for this - in terms of streaming. Definitely, not competing close enough with browsers.

Please note my discussions here: https://github.com/ShiftMediaProject/FFmpeg/issues/30#issuecomment-573339425

-nag

[lukasf]

I hope you tested a release build without debugger attached? Running with debugger from VS will always result in poor performance and lots of hickups. I did not see any hickups in any of the streams I tested recently, including that big buck bunny link you posted. And when I compared performance of local 4K video file playback (SW decoder) a few months back, FFmpegInteropX beat VLC hands down.

If you can provide a steam URL that performs poor on FFmpegInteropX, I'd like to look into it. But I guess you just need to use Debug -> Start Sithout Debugging (Ctrl+F5) in VS.

Just checked memory consumption playing that big buck bunny stream: VLC: 126 MB FFmpegInteropX CPP Sample: 62 MB FFmpegInteropX C# Sample: 65 MB

http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4

[mediabuff]

Yes, I tried with the release build of SMP -https://github.com/ShiftMediaProject/FFmpeg/releases/tag/4.3.r96057.

Tried with all combinations - with debugger/without, with trace log enabled and without, with all release build and no tracing. Understandably, debug builds and trace logs will hurt. But the release builds are not any better. There is a substantive and qualitative difference in the stacks.

BigBuckBunny.mp4 is not sufficient to excercise the stacks.

You can use this URL. This is geo-restricted to UK. https://vs-dash-uk-live.bbcfmt.hs.llnwd.net/pool_902/live/uk/bbc_news_channel_hd/bbc_news_channel_hd.isml/pc_hd_abr_v2_dash.mpd

I also tried with Zeronoe builds.

Please compare the video experience in a browser.

[lukasf]

I cannot open that stream, I am located in Germany.

But looking at the URI, this seems to be a DASH stream, which is not really supported yet from our side. A DASH stream usually contains multiple video streams at different formats, resolutions and bitrates. The browser selects an appropriate stream, based on your resolution, decoder support and connection speed, dropping back to lower bitrate streams if decode speed or connection speed is not sufficient. We currently do not support any of that. The lib will just select the first video stream, which is usually the one with the highest resolution. It might have a too high bitrate for your connection, causing the lag - or maybe it has a format such as HEVC that cannot be HW decoded on your side, again causing decode lag.

If you can provide a DASH stream without geo lock, I could further look into that. I guess we could extend the lib so you could select the different video streams. But I don't think that we can provide auto stream selection inside the lib. I wouldn't know where to get all the info required for that. But if we'd expose all video streams, then I think MediaPlayerElement would offer a video stream selection UI, and you could also programmatically select an appropriate stream.

[mediabuff]

I cannot open that stream, I am located in Germany.

Just a thought. You may use a VPN (which is what i do).

But I don't think that we can provide auto stream selection inside the lib

Fair enough. A stream choice API would be good.

[brabebhin]

@lukasf

Isn't support for multiple video streams pretty similar to what we already do for multiple audio streams? In fact I think it shouldn't take us too long to do it (I might give it a shot next week! it's been a while since I did any commits here anyway ^^).

@mediabuff, I have the opposite experience: my app based on ffmpeginteropx beats the lolz out of browsers when it comes to streaming.