shinchiro/mpv-winbuild-cmake

Possible bug with the version of libx265 embedded.

Closed this issue · 2 comments

Hi :

Working with SVP, I noticed that conversion from a 8 bits video to x265 8bits, don't work anymore.
I make my way through the process and discovered that this simple command line :

./mpv.com ./vids.mkv --no-config --o=output.mkv --no-audio --no-sub --no-sub-auto --of=matroska --ovc=libx265 --ovcopts=profile=main

cause this bug :

(+) Video --vid=1 () (h264 1920x1080 25.000fps)
Audio --aid=1 --alang=eng () (opus 2ch 48000Hz)
VO: [lavc] 1920x1080 yuv420p
[vo/lavc] Opening encoder: libx265 H.265 / HEVC [libx265]
x265 [error]: main profile not supported, internal bit depth 10.
[ffmpeg] libx265: Invalid or incompatible profile set: main.
[vo/lavc] Could not initialize encoder.
Could not initialize video chain.
Video: no video
[encode] no data written to target file
Exiting... (Interrupted by error)

After digging, it seems that the version of libx265 in mpv is compiled only with 10 bits.

When not trying to force a profile, here is part of the output :

x265 [info]: build info [Windows][GCC 12.2.1][64 bit] 10bit

Which we can compare with the version embedded, for example, with ffmpeg :

x265 [info]: build info [Windows][GCC 9.3.1][64 bit] 8bit+10bit

A look on the documentation of libx265 explain the problem :

Profile, Level, Tier
--profile, -P
Enforce the requirements of the specified profile, ensuring the output stream will be decodable by a decoder which supports that profile. May abort the encode if the specified profile is impossible to be supported by the compile options chosen for the encoder (a high bit depth encoder will be unable to output bitstreams compliant with Main or MainStillPicture).

I have try to force with option like --vf=format=fmt=yuv420p with no success.

I think this is not the desired behaviour. The version of libx265 embeded in mpv should be compiled in 8bit 10 bit.

The problem seems to exist on many build, I have opened a bug report on MPV and they say that the main windows version are based on your version, so I guess that the bug come from here (but I am not sure of that ...)

That's not bug. I purposely compile only 10bit for x64 to reduce the file size. Might reconsider

It's noticed. Sadly, this prevent converting to 8bits while some common decoder are not 10bits compatible.