shows a v3 version from 10/23 which runs OK
mpv-x86_64-v3-20231025-git-06c26e3.7z
has mysteriously re-appeared. I’ll try to build again later.
Please ignore my previous message.
I’m still confused as to why the v3 build does not appear in shinchiros site unless you select the display all option at the bottom, and also why your build process picked up the gcc build to use in error.
It has been acknowledged by a respondent on shinchiro’s site that the gcc build is considered a legacy release and does have an issue with Windows 10 and needs to be fixed.
Vern
For reference =>
Interesting tho, that the mpv.dll works but not the mpv.exe when compiled via gcc…
Well, I also only compile via gcc for now, maybe I will revert the commit that is mentioned in the later issue. (if it’s not fixed in a day or two… I guess I need to change my building system over to clang… meh)
Did you revert the changes manually by physically changing/replacing the files or is there a semi automatic way of doing it?
Manually. I edited both the cmake/packages_check.cmake and the ntruehd version of the packages/mpv.cmake file.
Thanks. This might be useful for future reference. In the meantime I mainly need mpv-2.dll which still works. But I have also downloaded Shinchiro’s mpv.exe because it is easier and quicker to use for testing than firing up Plex.
The build should be working again. Just merged the fix.
=> mpv: strip before add-gnu-debuglink for gcc build by Andarwinux · Pull Request #486 · shinchiro/mpv-winbuild-cmake · GitHub
Also, the clang build works too. The initial llvm build process does take a while. (~ 1h)
##Edit: Added some instructions on building with clang
I was going to ask you why someone would choose clang over gcc. But I decided to some Googling instead. Clang might be faster overall on an Intel CPU but apparently lacks some advanced features? So I’m still curious as to why this issue happened? Do the majority of Devs use Clang these days?
Don´t know if Clang is hugely better, but as stated on the winbuild repo GCC is considered legacy… (to be honest don’t know why…) I guess it’s better to migrate over to Clang now, fix the bugs, and make it work fine, then wait for GCC to be completely broken and not get any fixes…
As said the clang build system works fine.
Also found this nice comparison article: GCC vs Clang: Battle of the Behemoths - Incredibuild
Yeah I read a few articles. Anyway, I tried to build the Clang environment. but it fails at ninja llvm.
May sound like missing dependencies.
I know very little about this stuff 
But I did a bit of Googling which led me to the logs which led me to more googling. From there I found the missing LLD dependancy. I don’t have a super-fast machine but once the dependancy was found it took about 10 minutes to build the toolchain. So maybe other modern multicore Intel/AMD CPUs running on a VM will be similar. The mpv-plex-ntruehd build might also be a bit quicker than when using gcc.
Sorry to bother you (again), but would you please give quick a quick tutorial on how to incorporate changes like this:
into your build?
In the meantime there are mpv builds with the fix posted as part of the commit.
Figured it out, However, note that the posted builds don’t have the required ffmpeg fixes that this build has.
Okay so. Danbez over at the avsforum also asked this. Here is what I have answered (little bit modified):
There are multiple ways to compile it now. Two of them are janky but may work.
-
extract the modified file(s) (those files that contain the additional code) and replace them in a working default compiling environment => so for example when you have cloned my winbuild repo, look for the mpv packages folder inside the build64 folder. Then search for the file’s location and replace the files with your modified ones. Rebuild. This is janky AF (as it may be possible that the files get overwritten due to ninja things…) but it works. I have done early builds of modified mpv with this method.
-
(Assuming you have forked the original mpv github repo and pushed the changes to this repo) This method is also not purely perfect and relies on a working winbuild environment. Go to the root dir of the winbuild repo, then go into the packages folder, and search for a mpv-version.cmake (would recommend using a mpv-plex-xtruehd.cmake as the necessary lines are already present) you want to edit. Inside the file you have these lines:
Code:
GIT_REPOSITORY https://github.com/mitzsch/mpv.git
SOURCE_DIR ${SOURCE_LOCATION}
GIT_CLONE_FLAGS "--filter=tree:0"
UPDATE_COMMAND ""
GIT_REMOTE_NAME origin
GIT_TAG plex-htpc-hdr-patches
There replace the GIT_REPOSITORY GitHub - mitzsch/mpv: 
Command line video player with your github repo. You are likely pushed the patches to a non-default branch, so this needs to be adjusted as well. Replace GIT_TAG plex-htpc-hdr-patches with GIT_TAG
Hit save and cross your fingers that the .cmake will not be overwritten on compile. (run ninja mpv-your-selected-version.cmake)
- The cleanest method relies on method 2 but instead of editing the mpv-plex-xtruehd.cmake locally, change it remotely… On a fork of my winbuild repo, then rebuild as usual.
Hope that helps.
What I always did was simply to run the git update then replace the source files manually before compilation. This is basically the same as option 1. But in my case I only needed to make changes to a single file. I haven’t checked if that is the case here.
