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.
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.
I know how you feel. But they didn't like my suggestion of "Deep Space VP9".
what about .. av2
it's "windows 8 to windows 10" problem again.
2 replies →
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.
10 replies →
WebRTC isn't a file container like the rest of them though, right?
1 reply →
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.
1 reply →
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.
Not just visually. For a long time, googling for "AV1" would produce mostly results about AVI.
At first I thought this was a late April Fool's prank. The next headline might be a new FOSS font called C0mic S4ns.
No need for that now that we have Comic Sans Neue: http://www.comicneue.com/ (FOSS-licensed)
Now the FOSS people have something to laugh at too!
At least it's not a container - you won't have *.av1 filenames.
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.
That's a very important distinction.
I immediately thought this was like, a joke article RE: AVI format.
..So there you have it from an "unbiased^, first impression" -standpoint.
^ Unbiased in terms of any exposure / prior knowledge of this project.
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)
The first is a video codec, the second a container format. You won't see the raw .av1 much.
Finally, a codec name stupider than "DivX ;-)".
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.
For more history on this, see https://en.wikipedia.org/wiki/DivX#History
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.
Source: worked at DivX
I can't agree with you enough. I am astonished this didn't occur to anyone at Xiph.