hev1 are two different things.
hvc1 is HEVC video with the metadata for decoding it stored only in the container (meaning not in the video stream).
hev1 is the FFmpeg default tag, which indicates an HEVC video where metadata can be stored in the container or the stream.
Basically, Apple is the inflexible party here by insisting that metadata be stored only in the container. Or more likely, their insistence on signaling that metadata is only in the container, whether it is actually there or not.
People have already asked the FFmpeg developers to make
hvc1 the default tag. The developers declined. They didn’t give their reasoning, but my guess would be that they did not (or could not) guarantee that metadata would only appear in the container to be
hvc1 compliant. Note that libx265 is a separate software project from FFmpeg, with separate developers.
See request at FFmpeg bug tracker:
#6860 (hvc1 instead of hev1 in FourCC) – FFmpeg
In light of this, I think it would be dangerous to make the current Shotcut HEVC stock export presets use the
hvc1 tag as a default. Perhaps it might be viable to create an additional HEVC export preset where the phrase “for Apple devices” is clearly indicated in the title for those willing to take the risk with
hvc1. (This is just my opinion… I’m in no position to say what will actually happen.)
For now, the best solution is to make a custom export preset as @MusicalBox demonstrated and add
vtag=hvc1 to the list before saving it. This would remove the need to run ffmpeg after export to add the tag manually. As a convenience, also adding
meta.preset.extension=mp4 to the Other box would set the default extension to .mp4 so you wouldn’t have to add it yourself at every export.
For the uber-curious, note what happens in the metadata with the
The container metadata:
ffprobe -i test.mp4 -show_format
format_long_name=QuickTime / MOV
…which doesn’t contain much decoding metadata. Most of it is still in the stream (note the
ffprobe -i test.mp4 -show_entries stream
codec_long_name=H.265 / HEVC (High Efficiency Video Coding)
I didn’t take time to compare this file to the ISO spec to be certain, but I’m pretty sure this file does not totally qualify as HVC1-compliant despite the
codec_tag_string being overridden to say it is. This is why I don’t think a request to change the default to HVC1 would get any traction… it wouldn’t be correct from a compliance standpoint and could cause problems with more strict playback systems. The fact that the file plays on Mac High Sierra seems to suggest that Apple’s decoder is more forgiving than it lets on, provided the file makes it through the
hvc1 checkpoint. Why the checkpoint is still there is anyone’s guess.