You could argue not only is it an ergonomic/usability mess but also a security risk, because if future flaws are found in an AVI container code path, it could be used to trick users into executing the video that they normally wouldn’t play. I know that’s a stretch, but there’s just no reason to even have the any of these issues.
That said, I hate to criticize them too much for this detail, in fact, congratulations are in order. It’s been a great engineering effort so far, and hopefully this will continue with the reference implementation evolving into some highly optimized players and encoders.
Aside from the engineering accomplishment you can imagine that it took quite a bit of business effort and coordination to get all these players together and on the same page.
I’d make a bet whoever first proposed the extension name has never been involved with user experience design. But again it’s relative. An excellent chef made a great meal, if just the garnish on top is not perfect it’s not a lot to complain about.
Hopefully, it doesn't ever become the file extension. Current containers for AV1 include Matroska (.mkv), WebM (.webm), ISO base media file format (.3gpp), and WebRTC.
While technically file extensions so far reflected the container used, rather than codec, I think it should be the other way around.
I see “regular users” making decisions based on container file formats all the time, as to whether the file will be playable on their favorite device: DVD player, smartphone, portable music player etc.
It’s not very reliable, or accurate, but if you see an .mkv that’s usually h.264 or hevc, .webm is vp8/vp9 and .avi will play on your DVD.
There’s really no technical reason why file extensions should reflect the container format.
If I rename “BunnyVideo.mkv” to “BunnyVideo.av1” VLC will still play it just fine. But now I can tell at first glance that it will not play on my legacy Smart TV or last year netbook with no hardware decoding.
Whether that AV1 video is actually in a MKV or WebM container doesn’t really matter at all to your average user. It only matters if it will play.
Maybe it would be even better to just have .av1.mkv instead, but double file extensions don’t work on Windows and people think it’s a trick to get you to run malware.
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.
I agree that there needs to be a better proxy for understanding this for average users. It certainly is odd to have the container format as the primary bit of information we convey, but it reflects the information gap between users and developers. I believe the reasoning is that the codec should ideally be invisible and irrelevant information to the average user.
How is a user to know he might need to install a special codec to play a video? This is why OS and hardware support across many devices is essential to the success of new formats. This is why the Alliance for Open Media ensures AV1 succeeds across the spectrum of devices available.
> I believe the reasoning is that the codec should ideally be invisible and irrelevant information to the average user.
I don’t think anyone decided to do it like that. It’s just been the way it always was.
Anyway, early on container formats were actually correlated with the codec, or at least the multimedia stack you needed.
Let’s remember the early file extensions:
.avi .rmbv .wmv .mov .flv
Everyone knew what they needed to install to play one of these files. It’s only later, starting with .mkv really, that container formats stopped having anything to do with codecs.
Even so, .mkv used to for a long time just mean h.264 to most users. If you had a device that could play mkvs it could play h.264 as well.
The confusion started full on with HEVC. To many users mkvs suddenly just stopped being playable.
I don’t see any reason to continue this trend. AV1 should just use “.av1”. Any device/program that can play av1 can also handle mkv/webm. And no one will be confused.
Your reasoning and conclusion are exactly correct.
The only reason for this “I agree” comment is to underscore one last time there is absolutely no reason it has to specifically be .av1, and in fact several reasons it should be something else.
Whoever is involved please just walk right into the execs office and make the case to bring it up at the next meeting, it’s not too late.
You’re right that would be worse, but even if it never happens we’ve all seen how people can be lulled into clicking/trusting seemingly prominent domain names that don’t really exist. More sort of confusion trickery than tech trickery.
It's a video codec, the average user will never give a shit or even realize they are using it. C is a stupid name for a programming language. No one cares.
I very frequently deal with .h264 files, containing just a raw h264 bitstream. Granted, that's more of a special case, because I deal with video encoding and decoding a lot through work.
All the more reason for AV2 to be created more quickly (like when those "lapping approach and frequency-domain techniques" mentioned in the article reach technical maturity)
Fun fact - "DivX ;-)" was a cracked version of the Microsoft MPEG4 decoder which was originally restricted to only play in ASF containers and has nothing to do with DivX the company which came later.
Are you confusing the DivX codec with the DIVX DVD format? I don't know how accurate to it is to say that the cracked MPEG4 decoder had nothing to do with DivX the company. Gej (https://en.wikipedia.org/wiki/J%C3%A9r%C3%B4me_Rota) was the guy that created the DivX ;) crack, and definitely worked at DivX, Inc. from the very beginning.
