MPV and new 2160p_HDR_Rip

[AlFmla]

New builds Win MPV make crash videos and brakes on new 2160p_HDR_Rip

The MPV.NET-VVCEasy build from 20_01_2024 and the older ones play the video well, but without HDR. Can you check and what is the solution for this video to play without crash and brakes and with HDR?

[MartinEesmaa]

Hi, @AlisaFmla!

That's weird... the new builds Win MPV crashes HDR video when playing using native VVC decoder. On my laptop, it didn't crash and it shows artifacts glitch on beginning of video intro and it started some artifacts glitch via decode native VVC decoder during the movie.

On 20/01/2024 build version, the video plays fine, but seek is slow and freezes about three seconds before video is synchronized. On latest build version shows artifacts playing HDR video 4K, fast seek with artifacts error. Can you share the log to me please by CLI on your Terminal?

I switched from libvvdec to native VVC decoder to reduce CPU usage after 20/01/2024 build version.

Use CLI as command for any reports, copy and upload the log file over GitHub or my email address:

mpv-vvceasy video.mp4 --log-file reportvvchdr.txt

Feel free to ask or reply to me. Meanwhile, I'm gonna check the file that you sent requested link to me to detect errors.

Thank you! :)

• Martin Eesmaa

[MartinEesmaa]

@AlisaFmla, here are my two screenshots of between 20.01.2024 and latest version of 06.03.2024.

I took screenshot using MPV by pressing "s" key to make sure HDR is on. Tried screenshot format and outputting png file won't show HDR color.

Screenshot of 20.01.2024 version of libvvdec: https://imgur.com/QUpWj8r

Screenshot of 06.04.2024 version of native VVC decoder: https://imgur.com/U4VjGgI

I think the solution is I had to switch native VVC decoder to libvvdec by changing code line on my forked repository on Github and then it will be fixed on next build version or might others... but native VVC decoder playing 4K VVC video HDR makes artifacts glitch colors during the movie playing on MPV and FFmpeg.

• Martin Eesmaa

[AlFmla]

report_vvc_hdr.zip left Screenshot of 20.01.2024 version of libvvdec - right Screenshot latest mpv of native VVC decoder left without HDR - right with HDR true? Does this mean that VVenC version 1.9.1 encoded HDR on this video incorrectly and it cannot be fixed, or with the new versions of native VVC decoder this video will not crash and will be with HDR? Old versions with libvvdec will not be able on this video to show HDR correctly?

[MartinEesmaa]

Hi, @AlisaFmla! Thank you for giving your question to me.

left without HDR - right with HDR true?

On the left version, it may be little washed color so that is without HDR before FFmpeg made patch fix with HDR, I guess. On the right version, it is true HDR color to confirm.

Does this mean that VVenC version 1.9.1 encoded HDR on this video incorrectly and it cannot be fixed, or with the new versions of native VVC decoder this video will not crash and will be with HDR?

No, it encoded probably using outdated VVenc Version 1.9.1 and also it can be fix when using only latest FFmpeg and using latest MPV build of command if possible to use --hwdec=cuda --vo=gpu-next, but not old version maybe. Native VVC decoder and external via libvvdec may not crash if it's not overload of using CPU or/and memory to play 4K video on your 4K display, but random seek like mouse scroll on seekbar may crash sometimes.

Old versions with libvvdec will not be able on this video to show HDR correctly?

Kinda not when using old libvvdec and old FFmpeg & MPV, but it should need to show HDR correct when using latest libvvdec and FFmpeg & MPV too.

I looked your log file and it seems there are no warnings and errors, but your monitor or laptop screen is 4K input which may slow down without resizing it. On my laptop of using my monitor 1080p, resizes it without issue on mpv, but when I use ffplay then it actually slows video.

I know the problem is native VVC decoder couldn't decode probably small tiles of 2x1 --tiles 2x1 which left there information in description on your sent link. External VVC decoder works fine to decode 2x1 tiles, so I or we might have to report issue to ffvvc or/and FFmpeg bug report.

Before I give report issue, I have to use royalty-free video for example Xiph videos to encode using 2x1 tiles of vvencapp with FFmpeg pipe or I can still use my own FFmpeg VVCEasy build for vvenc params to insert custom tiles.

RAV1NE encoded using command of vvenc with FFmpeg pipe which causes the decode problem for native VVC decoder on FFmpeg:

ffmpeg -i movie.mkv -f yuv4mpegpipe - | vvencapp --y4m -i - -v 4 --preset medium -q 19 --qpa off --hdr pq_2020 --tiles 2x1 -o 2x1movie.266

Without tiles command, the both decoder are fine without artificial blocks. Using tiles like 2x1 can only cause problem decoding via artificial blocks with random glitch colors of native VVC decoder on FFmpeg.

Thanks for good spot finding on your sent link. :)

Feel free to ask or reply to me.

Regards

• Martin Eesmaa

[MartinEesmaa]

@AlisaFmla, I posted issue to ffvvc, now we have to wait to get fixed for updating VVC native decoder codes.

• Martin Eesmaa

[AlFmla]

Thank you for identifying the problem and creating the correct issue. We will wait for the 2x1 tiles decoding solution. I added a new one issue too. So the new ffmpeg and MPV won't play VVC/H.266? You will have to take this into account in new MPV.NET VVCEasy?

[Andarwinux]

It looks like VVCEasy's mpv is built using mpv-winbuild-cmake, if you want to allow ffvvc, just revert https://github.com/FFmpeg/FFmpeg/commit/110d8549d575aae6b2f627cd63e2eb7082ab8926. By the way, I recommend building vvdec and ffmpeg using the LLVM toolchain with ThinLTO, this dramatically improves the performance of vvdec, for my 7900X, vvdec built with clang -march=native -flto=thin is more than twice as fast as ffvvc.

[AlFmla]

@Andarwinux, thank you for your support! I hope @MartinEesmaa will follow your recommendation.

[MartinEesmaa]

Hello, @Andarwinux and @AlFmla. Thanks for additional comments! :)

@Andarwinux, after I'm reading your comment, I guess I can try and test to see if it's fast to use LLVM and march native. I might have to install mimalloc and upgrade all my packages on Arch Linux before I go build mpv windows on cmake.

Just going to use CMake build configuration on build folder inside mpv-winbuild-cmake:

cmake -DTARGET_ARCH=x86_64-w64-mingw32 -DGCC_ARCH=x86-64-v3 -DCOMPILER_TOOLCHAIN=clang -DLLVM_ENABLE_LTO=Thin ..
ninja llvm
ninja rustup
ninja llvm-clang
ninja mpv

You can look my vvdec.cmake: https://github.com/MartinEesmaa/mpv-winbuild-cmake/blob/master/packages/vvdec.cmake and also CMake more options: https://github.com/shinchiro/mpv-winbuild-cmake/blob/master/CMakeLists.txt

Also for you, @AlFmla. I will follow @Andarwinux's recommendation. Thank you both! :)

I might start tomorrow or another day after tomorrow to build custom improved MPV build.

Regards

• Martin Eesmaa

[L4cache]

It looks like VVCEasy's mpv is built using mpv-winbuild-cmake, if you want to allow ffvvc, just revert FFmpeg/FFmpeg@110d854. By the way, I recommend building vvdec and ffmpeg using the LLVM toolchain with ThinLTO, this dramatically improves the performance of vvdec, for my 7900X, vvdec built with clang -march=native -flto=thin is more than twice as fast as ffvvc.

I don't think it's the compiler optimization that responsible for speed difference. VVdeC has been developed longer thus more mature.

Hello, @Andarwinux and @AlFmla. Thanks for additional comments! :)

@Andarwinux, after I'm reading your comment, I guess I can try and test to see if it's fast to use LLVM and march native. I might have to install mimalloc and upgrade all my packages on Arch Linux before I go build mpv windows on cmake.

Just going to use CMake build configuration on build folder inside mpv-winbuild-cmake:

cmake -DTARGET_ARCH=x86_64-w64-mingw32 -DGCC_ARCH=x86-64-v3 -DCOMPILER_TOOLCHAIN=clang -DLLVM_ENABLE_LTO=Thin ..
ninja llvm
ninja rustup
ninja llvm-clang
ninja mpv

You can look my vvdec.cmake: https://github.com/MartinEesmaa/mpv-winbuild-cmake/blob/master/packages/vvdec.cmake and also CMake more options: https://github.com/shinchiro/mpv-winbuild-cmake/blob/master/CMakeLists.txt

Also for you, @AlFmla. I will follow @Andarwinux's recommendation. Thank you both! :)

I might start tomorrow or another day after tomorrow to build custom improved MPV build.

Regards

• Martin Eesmaa

IIRC, VVdeC did some optimization for "low speed" (e.g. limited to realtime playback) decoding CPU usage recently.

Here. https://github.com/fraunhoferhhi/vvdec/pull/162

It's merged 2024-01-19, kinda right at the point when you switched to ffvvc in 2024-01-20. (sorry for the time format incompatibility)

[Andarwinux]

You can look my vvdec.cmake: https://github.com/MartinEesmaa/mpv-winbuild-cmake/blob/master/packages/vvdec.cmake

I propose the following change:

ExternalProject_Add(vvdec
    GIT_REPOSITORY https://github.com/fraunhoferhhi/vvdec.git
    SOURCE_DIR ${SOURCE_LOCATION}
    GIT_CLONE_FLAGS "--filter=tree:0"
    UPDATE_COMMAND ""
    CONFIGURE_COMMAND ${EXEC} CONF=1 cmake -H<SOURCE_DIR> -B<BINARY_DIR>
        -G Ninja
        -DCMAKE_BUILD_TYPE=Release
        -DCMAKE_TOOLCHAIN_FILE=${TOOLCHAIN_FILE}
        -DCMAKE_INSTALL_PREFIX=${MINGW_INSTALL_PREFIX}
        -DCMAKE_FIND_ROOT_PATH=${MINGW_INSTALL_PREFIX}
        -DCCACHE_FOUND=OFF
        -DBUILD_SHARED_LIBS=OFF
        -DVVDEC_ENABLE_LINK_TIME_OPT=OFF
        -DVVDEC_ENABLE_WARNINGS_AS_WERROR=OFF
    BUILD_COMMAND ${EXEC} ninja -C <BINARY_DIR>
    INSTALL_COMMAND ${EXEC} ninja -C <BINARY_DIR> install
    LOG_DOWNLOAD 1 LOG_UPDATE 1 LOG_CONFIGURE 1 LOG_BUILD 1 LOG_INSTALL 1
)

force_rebuild_git(vvdec)
cleanup(vvdec install)

The CONF=1 in the configure step is very important, as this informs the compiler-wrapper to disable optimization in order to skip optimization during configure to speed things up. -DBUILD_SHARED_LIBS=OFF ensures that shared library build targets are disabled to avoid building meaningless shared libraries, which can be extremely time-consuming and if LTO is enabled.

I might have to install mimalloc and upgrade all my packages on Arch Linux before I go build mpv windows on cmake.

mimalloc is optional and is used to speed up builds, especially LTO builds.

Just going to use CMake build configuration on build folder inside mpv-winbuild-cmake:

cmake -DTARGET_ARCH=x86_64-w64-mingw32 -DGCC_ARCH=x86-64-v3 -DCOMPILER_TOOLCHAIN=clang -DLLVM_ENABLE_LTO=Thin ..
ninja llvm
ninja rustup
ninja llvm-clang
ninja mpv

If you just want to try out the LLVM toolchain, -DLLVM_ENABLE_LTO=Thin is not recommended, as it will cause the already time-consuming LLVM build to become even more time-consuming. The correct way to enable LTO for packages is -DCLANG_PACKAGES_LTO=ON.

But I would recommend install ccache, then add -DENABLE_CCACHE=ON, which will reduce your rebuild time to under 2 minutes. This also applies to GCC, but due to the poor design of GCC, this can lead to OOM.

[MartinEesmaa]

@Andarwinux, thanks for more information to me. I might start first generic build and then maybe LLVM custom MPV build with your following recommendations and also vvdec flag that you modified.

One thing notice that following CMake flag -DVVDEC_ENABLE_LINK_TIME_OPT=OFF means LTO is turned off, cause maybe FFmpeg doesn't detect libvvdec and returns library error undeclared. I hope I can turn back on if it's possible.

Thanks again! :)

Update 1: Generic build is done, now one more to go...

Regards

• Martin Eesmaa

[Andarwinux]

One thing notice that following CMake flag -DVVDEC_ENABLE_LINK_TIME_OPT=OFF means LTO is turned off, cause maybe FFmpeg doesn't detect libvvdec and returns library error undeclared. I hope I can turn back on if it's possible.

VVDEC_ENABLE_LINK_TIME_OPT means -flto=auto, which is FullLTO for clang. mpv-winbuild-cmake has its own compiler and linker wrappers to implement build-system agnostic, deterministic compiler and linker flags passing and filtering mechanism. ThinLTO is implemented by this, which is invisible to build systems.

[MartinEesmaa]

Hi @Andarwinux and @AlFmla. Normal build is added, but LLVM build is requested by @Andarwinux is process await to make build times for long hours.

Also @Andarwinux, thanks for giving tip to me. :)

Regards

• Martin Eesmaa

[MartinEesmaa]

Hi @Andarwinux, your request is finished and I made MPV custom build of x86_64-v3 version. The two builds of generic and native are finished with libvvdec decoding.

Also @AlFmla, thanks for letting me know for creating your own issue. :)

This issue is solved and closed.

• Martin Eesmaa