Comment by WhitneyLand
9 years ago
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.
5 replies →
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.
3 replies →
WebRTC isn't a file container like the rest of them though, right?
Correct. WebRTC is just a specification for an API on top of SRTP+ICE+SCTP.
File extensions are still essentially irrelevant.
I'm pretty tech savvy and I haven't downloaded a video file to my computer from the internet in years.
Maybe you should start. Check your YouTube liked videos list. How many entries are "this video is no longer available"?
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.