5 ms·

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 b

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.

mncolinlee 9y ago
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.
- WhitneyLand 9y ago
  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.
- SahAssar 9y ago
  WebRTC isn't a file container like the rest of them though, right?
  - cypher543 9y ago
    Correct. WebRTC is just a specification for an API on top of SRTP+ICE+SCTP.
- acchow 9y ago
  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.
  - floatboth 9y ago
    Maybe you should start. Check your YouTube liked videos list. How many entries are "this video is no longer available"?
- deno 9y ago
  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.
  - mncolinlee 9y ago
    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.
    - deleted 9y ago
      [deleted]
    - deno 9y ago
      > 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.

mncolinlee 9y ago

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.

WhitneyLand 9y ago
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.
SahAssar 9y ago
WebRTC isn't a file container like the rest of them though, right?
- cypher543 9y ago
  Correct. WebRTC is just a specification for an API on top of SRTP+ICE+SCTP.
acchow 9y ago
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.
- floatboth 9y ago
  Maybe you should start. Check your YouTube liked videos list. How many entries are "this video is no longer available"?
deno 9y ago
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.
- mncolinlee 9y ago
  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.
  - deleted 9y ago
    [deleted]
  - deno 9y ago
    > 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.