cl is unable to create an executable file/ plus DASH play issues #153
Comments
|
You should probably redo the build setup. |
|
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. |
|
I recently had a build error on arm/64 due to invalid/corrupted gcc package in msys2. |
|
I am not building for ARM. Was building for x86. |
|
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:
You can easily override the SDK and toolkit. This would build with 142 toolkit and 10.0.17763.0 SDK:
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:
|
|
Thanks for you for your support. Followed powershell instructions verbatim and have attached the log. From a clean cmd prompt: (url |
|
And the ffmpeg config.log? |
|
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. |
|
Attached both logs. |
|
Failure point in config.log |
|
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:
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. |
|
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.
|
|
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. |
|
Alternatively, I think it should be possible to make the script pick up the VS2019 preview. Try adding this to your PS call:
|
|
Same issue with the '2019 preview' version. Can't be my installation - tried 3 versions - all standard installations. |
|
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. |
|
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. |
|
Attached new logs for preview version: |
|
Ok the new logging helped here:
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.
|
|
Thanks for your support thus far. Still the same issue.
config.2019preview.142tools.log
ffmpegcompile.2019preview.141tools.log |
|
I think you should uninstall all visual studio versions and go with vs2017. We know for sure 2017 works. 2019 is still weird-ish. |
|
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 ;) |
|
I give up and move on to builds from https://github.com/ShiftMediaProject. Much saner build process for native Visual environment. |
|
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. |
|
lukasf, immensely appreciated your support. Will continue to engage in this repo. On your comments.
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: ShiftMediaProject/FFmpeg#30 (comment) -nag |
|
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: http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4 |
|
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. I also tried with Zeronoe builds. Please compare the video experience in a browser. |
|
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. |
Just a thought. You may use a VPN (which is what i do).
Fair enough. A stream choice API would be good. |
|
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. |
|
@mcosmin222 Indeed it should not be too much work. We did exactly the same already for audio streams, so we know already how to do it. My experience was also that we are pretty much ahead of competition when it comes to performance and efficiency, also in streaming. But I did not test any DASH until now, in fact I did not have any focus on streaming in my own app. When the browser selects 720p but FFmpegInteropX uses 1080p or even 4k, it will be a whole different situation. |
|
I have found out that the DASH format in ffmpeg requires libxml2 to be included. Since we don't have that, DASH streams do not play at all right now. I will try to add libxml2 soon (and maybe also gnutls, required for https streams). |
|
The ffmpeg build i used (SMP) has libxml2. I was able to stream. But not effectively :-) |
|
Well, we aren't exactly competing with SMP. But we also try to do things by the book, make sure there are no problems further down the line, like store certification failures, so adding a new library isn't always easy. I already started working on multiple video streams support. I will also investigate if there is a possibility of implementing adaptive media source from a stream source. |
|
Oh man, adding libxml2 was a whole lot more work than expected. For libxml2 and many other libs, the ffmpeg build system expects that pkg-config packet manager is used. But we don't use that, and I could not find any way to get around this. The vcpkg guys used a patching mechanism, modifying the ffmpeg build script using git patches, and then rolling back afterwards. A pretty fragile approach that I did not want to follow. In the end I found myself writing a "fake" pkg-config tool, which will return just what ffmpeg expects for libxml2. Lots of other changes were required, but in the end I got it working now. Still need to cleanup, will create a PR soon. With libxml2 included, I could play DASH successfully, and I also found the streams pretty laggy like @mediabuff reported, although bitrate was modest and resoultion "only" FullHD. In the end it turned out simple: The MediaStreamSource has a "BufferTime" property, which is 3 seconds by default. I am not 100% sure why we decided to set it to 0 in our code. There might have been bugs with heavy file seeking, I don't remember exactly. Also, a 3 seconds buffer for video frames has a very high memory footprint, especially if SW decoding is used for FullHD or 4K video frames. Since a buffer is not needed at all for local file playback, we did just set it to 0 and assumed people will set this to higher values if they do streaming. If you add this line after creating the MSS, your streams should play flawless:
I think we should offer an easier way to set this. Maybe add a BufferTime property directly on the MSS class, and/or have two default values in the config class, one for files and one for streams. By the way: SMP has created a completely new build system for ffmpeg, based on MSVC and automatic project file generation. It's pretty impressive, but I do not fully understand how it works, and I wouldn't want to be dependent on someone maintaining all this. Also, since we only do decoding, we do not need all those libs included. I think for us it is the better way to just manually pick a few libs, and make them work with the official ffmpeg build system. |
|
Good work! I made the buffer time 0 in ancient times because there were issues with seeking, and playing after a pause. Although the 2nd thing was probably a bug in MF. Probably best way is to offer a configuration option. |
|
Thank you for fast troubleshooting. Will try it out once the PR is available.
Ooo hoo. I thought I was doing something crazy.
Yep, impressive. All kudos to https://github.com/Sibras |
|
All other stream types play flawless with BufferTime 0. Not sure why only DASH has problems with that. Maybe internally, ffmpeg handles that one differently. I think you can test it right now already with the SMP ffmpeg binaries you have. Just set the BufferTime as I indicated above, after creating the MSS instance. It should make your streams run smoothly. |
|
lukasf, I don't have good news. Made the changes and don't seem to have much difference.
` `
` create_task(FFmpegInteropMSS::CreateFromUriAsync(uri, Config)).then([this](FFmpegInteropMSS^ result) #if true ` |
|
Please see the poor quality |
|
Good quality from vlc |
Does the stream still stall and freeze? I thought that your main complaint was that the playback is laggy and unstable. The lib still selects the first stream by default. If you have pulled the latest changes from master branch, you will be able to switch video streams by pressing the "V" key. Switching is not seamless, unfortunately, but you should be able to select the high-res stream like that. |
Doesn't really freeze. Definitely the app is not very responsive. For sure stalls quite a bit. Yes, stalling and video quality - both are issues. |
|
Okay now I also found some DASH streams that lag and freeze, even with buffer set. And after debugging into ffmpeg itself, I think I know why! We currently filter packets on library level: We read all packets and discard the ones for streams that are not selected. This works well for local files and normal streams. But for DASH, this means that during playback, all video and audio streams are transferred simultaneously! Only locally the unneeded ones are discarded. Of course this causes very heavy traffic. Then I found out that in FFmpeg, we can set a "discard" flag on a per-stream level. Then the DASH decoder should only request and transfer the streams that are actually selected. I will see if I can get this running. |
|
Thank you. That explains it. The BBC live dash feed has 9 or 10 streams. Good luck. On a different problem, I have win32/desktop player that uses ffmpeg directly. I get the following issue on Windows. Any ideas ? https://github.com/ShiftMediaProject/FFmpeg/releases/tag/4.3.r96057. |
|
I already had this running yesterday, and the problematic stream played well this time! DASH will still need BufferTime to be set, and now I know the reason why: Unlike normal streams, DASH streams are split up into lots of small segment files, each only few seconds long (usually 3 seconds). So everytime we hit the end of one segment, a new HTTP connection has to be made to request the next segment. That takes about 1-1.5 seconds. A BufferTime of 3 seconds is actually a bit short for that scenario. I noticed one or two short stalls even with that, over a 10 minutes stream. For DASH, the buffer time should probably be higher, maybe 5 to 10 seconds. |
|
Interesting findings. Maybe we should handle that automatically : i.e if Dash stream, then set it by default to 10 seconds unless value in configuration is different. |
|
What about an efficient discard model as well ? |
|
That's what I implemented yesterday, and it solves the problems for me. PR coming soon. |
|
So, the important PRs have been merged now. @mediabuff Please try again with latest changes from master branch. URI sources now have a default BufferTime of 5 seconds. You can change that either in the config class, or directly on the FFmpegInteropMSS instance (it now has a direct property BufferTime). You can switch streams in the sample app by pressing "V" on the keyboard. Stream switching is still slow, but it works. Some improvements are coming there as well, but seamless switching for DASH probably won't be possible unless we do some very heavy changes. |
|
Ok, finally got to test the new version.
Environment - complete new fetch from git and rebuilt (using SMP fffmpeg build) Crash on stream change After 21 secs HTTP error 403 Forbidden |
mediabuff
changed the title
This can only be investigated if you can provide an actual stream uri without region lock.
Yes I also noticed slow statup. VLC is slow as well, our lib is even twice as slow. But I have tested ffplay, and it takes exactly the same time as our lib. I debugged into ffmpeg sources for dash decoder, and the initialization is far from perfect. All streams are actually opened and probed for exact format, and even that in an inefficient way (two http requests where one should be sufficient for stream detection). Plus worst thing: This all happens sequentially, so the more streams there are, the longer it takes. This could all be done in parallel in a fraction of time. So the slow startup is caused by FFmpeg issues. VLC has its own custom DASH parser, also not the best but better than what ffmpeg has to offer. Theoretically, all stream parsing could be avoided because the "MDP" header has all the basic stream info you need (bitrate and resolution), that's what the browsers do. But ffmpeg wants to initialize all streams in detail, which slows things down, especially when doing it all sequential.
This is because a low quality stream is selected.
I have only seen this when pressing too fast. Stream switching takes some time. Please make sure you only press "V" once and wait for switch to happen.
This is only a problem with the CPP sample. It does not have proper error handling. |
|
|
In the sample apps, there is a OnKeyDown handler which sets the SelectedIndex of the video streams on the MediaPlaybackItem. This should result in a call to FFmpegInteropMSS::OnSwitchStreamsRequested. After that, samples are requested for the new video stream. Can you also check which formats the video streams have? Maybe one of the streams has a format that cannot be decoded. |
|
My mpd has six streams. The test player not seeing the streams. I have attached the mpd file. When I press V, this what I get: FFmpeg (Info): [dash @ 0B6D0140] No longer receiving stream_index 2 FFmpeg (Info): [dash @ 0B6D0140] No longer receiving stream_index 3 FFmpeg (Info): [dash @ 0B6D0140] No longer receiving stream_index 4 FFmpeg (Info): [dash @ 0B6D0140] No longer receiving stream_index 5` |
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 ?
The text was updated successfully, but these errors were encountered: