Bug h.265 video codec not quite supported

Hi!

Like all the codecs used by the VideoPlayer (except vp8), H.265 is supported on platforms where the native OS supports it, using the libraries what's already present in there. This means some variability is unfortunately bound to happen.

On AVFoundation (OSX), only the 'hvc1' variant of H.265 files are supported, and here I see the file you are using is of the "other" variant: 'hev1'. The difference is not only the string itself but some details in the file layout.

If you don't have the original source to re-create a new video with the right variant/layout, then you can transcode it with an external tool. With ffmpeg for example, this would go along the lines of

Code (CSharp):

1. ffmpeg -i input-hev1.mp4 -c:v copy -tag:v hvc1 -c:a copy output-hvc1.mp4

and this will just re-create the packaging so it won't lead to loss of quality.

The same goes for Windows in terms of variability: the fact it plays at all means you have installed the HEVC video extension, but the slow performance means something is not keeping up.

For example, Microsoft's guarantee for hardware acceleration of H.265 is up to 1920x1088. Past this, it will still work but if the hardware cannot do it, then it reverts to software decoding. See the note about Maximum Resolution in here: https://docs.microsoft.com/en-us/windows/win32/medfound/h-265---hevc-video-decoder

If you're using H.265 in a context where the playback system has too many unknowns for all of this be reliable, then you should probably revert to using H.264 since the resolution you are using does fit within this codec's constraints (though the size difference will clearly be a disadvantage).

Hope this helps; let us know if this is enough to get you going. If there's anything that still isn't making sense after validating some of the above, we can keep looking together or ask you to file a bug so we can reproduce internally.

Dominique Leroux
A/V developer at Unity

 

Hi!

Sorry for the long pause, been away for a few weeks. The most common format right now is H.264, which means living with a max of 4k resolution. And make sure you distinguish between what the spec allows, and what the platform has chosen to support. For instance, on Windows 8+ (so this includes Windows 10), H.264 is supported up to 4096 × 2304 pixels. But on Windows 7 the max is 1920x1088, as described by Microsoft over here: https://docs.microsoft.com/en-us/windows/win32/medfound/h-264-video-decoder

And as you are finding out, H.265 - although we do support it when present - is a tough requirement to put on users. The reason for this complexity around H.265 seems to be licensing. Video codec technology is quite protected with patents/licences, so that when it's included in a product (OS, game, ...) it's because someone has accepted to foot the bill in one way or another.

One way out of this situation is to use the vp8 codec. This is royalty free and works up to 16384 x 16384. But because Unity uses a software implementation, the performance may not match that of hardware-accelerated implementations we tap into for H.264/H.265. Android is an exception here, where many devices have a hardware implementation of vp8. Successors of vp8 (namely: vp9 and av1) are also something we have an eye on but haven't yet had time to dig into. Note that I'm not recommended you go throw a 16384x16384 movie at Unity right away: there are issues that need to be fixed (I tried...). But you'll be able to import 8K content (7680 × 4320) without trouble and get a feel whether the performance level is up to expectations.

This brings us to VLC: the reason it can sidestep all this complexity is by not honouring software patents/licenses. So VLC likely has its own implementation of all the codec it supports, making things quite simple for users, but at the cost a legal vulnerability that is not appropriate for Unity. Note that I'm not a lawyer; this is just my programmer-level understanding of the ecosystem.

Not sure if any of this is useful, but I hope it's at least somewhat interesting!

Dominique