It's actually not a good idea to name the files after the codec, and there's good (technical) reasons for that.
A container contains more than just a single video stream.
They can also contain audio streams and subtitles, with multiple of each, of different types.
What are you going to call a file containing an AV1 video stream, an MPEG2 video stream, a 2-channel MP3 audio stream, a 5.1-channel AC3 audio stream, SubRip (.srt) subtitles for one language, and VobSub (.sub+.idx) for another language?
The above also means that just knowing the video codec is not enough to know whether your device can play it, since your proposition will be missing e.g. audio codec(s).
Trying to play a file with e.g. FLAC audio on a device that does not support it? Worst case it doesn't work at all, best case you get video but no audio.
All that is before you get to the actual video codec, which also complicates matters: For example, H.264 has profiles and levels, and not all devices/decoders support all profiles and levels. This means you also need to know the profile+level of the file, and the maximum supported by the device to tell whether it can play the file.
The question is whether “.av1” conveys more useful information to the end user than “.mkv”
Of course you can make an “.h264” with opus audio but in reality no one does that. And anyway even if that wasn’t the case, once you decide to use that extension you agree to not do that.
Audio is also both easier to play on anything with software encoding and easy to reencode if needed.
Perfect is the enemy of the good.
What useful information does the “.mkv” or “.webm” extension offer exactly? It’s “correct,” but also completely useless. The only signal it provides is accidental and unreliable.
Might as well use “.video” and “.audio”.
> Of course you can make an “.h264” with opus audio but in reality no one does that.
People definitely do that. And even if they didn't, significantly more people create h264+flac releases, and flac is also supported by much fewer devices than e.g. AC3.
E.g. .mkv does convey useful information. A player needs to support the container format as well, not just the codecs for the streams it contains. Different containers also support different features (not all containers are equal), and there are tools that only work for some containers.
The signal provided is only accidental and unreliable as a proxy for audio or video codec, not in general.
.webm is also a bit of a bad example here, since it's just a subset of matroska (mkv), but more importantly it initially only supported a single video codec and a single audio codec (VP8 & Vorbis). Of course, that has changed since, with the addition of support for VP9, AV1, and Opus.
Is it really not a good idea per se, or simply that it would need to be more prescriptive?
For example a new extension could mandate minimum support for codecs or features. Like wp explains, matroska file extensions are .MKV for video (with subtitles and audio), .MK3D for stereoscopic video, .MKA for audio-only files, and .MKS for subtitles. I’m not aware of any reason an extension couldn’t represent minimum package requirements, like audio/video/at least av1 codec, etc, that would work for most cases, while potentially still retaining extensibility where practical.
But then you're not really naming it after the codec.
Instead you create a standard that mandates container X, support for video codecs Y[, ...], and support for audio codecs Z[, ...]. Then you can document a player/device as supporting that standard and also name video files after it.
Thank you, that’s correct. I was questioning an argument you made in a way that was not technically analogous.
The gist of the comment should have referred only to what I brought up, which as you point out is a minimum simple standard for packaging and contents as it could relate to a file extension.
A container contains more than just a single video stream.
They can also contain audio streams and subtitles, with multiple of each, of different types.
What are you going to call a file containing an AV1 video stream, an MPEG2 video stream, a 2-channel MP3 audio stream, a 5.1-channel AC3 audio stream, SubRip (.srt) subtitles for one language, and VobSub (.sub+.idx) for another language?
The above also means that just knowing the video codec is not enough to know whether your device can play it, since your proposition will be missing e.g. audio codec(s).
Trying to play a file with e.g. FLAC audio on a device that does not support it? Worst case it doesn't work at all, best case you get video but no audio.
All that is before you get to the actual video codec, which also complicates matters: For example, H.264 has profiles and levels, and not all devices/decoders support all profiles and levels. This means you also need to know the profile+level of the file, and the maximum supported by the device to tell whether it can play the file.