6 ms·

RIFF (used for .wav and.avi files) was just a pure container format. The actual payload content was compressed/represented by an open-ended set of CODECs, as in

RIFF (used for .wav and.avi files) was just a pure container format. The actual payload content was compressed/represented by an open-ended set of CODECs, as indicated by the "FOURCC" (four character code) present in the file.

layer8 2y ago
I know, but what is the practical difference for the file loader? In both cases you have formats with open-ended extensions (PNG chunks and XML elements), and in both cases you have to make sure that the overall format matches what you expect.
- jdiff 2y ago
  For SVG there are standards that define how to interact with unknown elements, and a set of standard elements which are actually part of the spec. With PNG, there's a minimum set of chunks that are required, and you can safely stick with those and get something that works for the vast majority of cases. This is totally different from a container which can contain any type of data in any type of format. If you get a valid PNG, you can load something meaningful from it. If you get a generic container, you might be able to inspect it at a surface level but there's no guarantee that the contents are even conceptually meaningful to you.
  - layer8 2y ago
    Effectively the same is true for IFF-compliant formats like ILBM and AIFF, which are usually distinguished either by file extension or by file-system metadata. It’s a bit like criticizing a format for being XML-based, under the argument that XML can represent all kinds of payloads.
    - jdiff 2y ago
      That's exactly what I'm working towards. It's the difference between just using an XML file and using an XML file with a unique extension tacked onto it. It represents a subset with set expectations for behavior. That expectation is what matters. For generic containers, there are no expectations on what's inside. If I'm making a video player, do I support MKV? Well, some of them. Not all of them. You have to try it and find out. Heck, even within a single codec it's hard to find complete support. Last I checked, browsers won't touch an H264 stream unless it's also YUV420p which also places certain restrictions on physical dimensions of the data and probably some other stuff that's escaping my mind. If I'm making an image viewer, do I support SVG or PNG? For this example, let's say I only support PNG, but I can tell from the outset what's inside any file I might try to load. I can confidently say I can meaningfully load and display anything that uses the established standards of the PNG format to store image data. Sure, there are extensible bits, but they're not part of those core expectations surrounding the core part of the format, the image data I care about. And I didn't have to try and open the PNG first to see if it was actually an SVG. I can recognize not-bitmaps at a glance without having to inspect them any deeper than their extension.
- HarHarVeryFunny 2y ago
  With RIFF you not only need to be able to handle the container format, but also the specific type of payload content, which for video varied from simple uncompressed YUV formats like Y41P to proprietary compressed ones like WMV1 (Windows Media Video). Being able to handle the RIFF format therefore had no bearing on whether you'd be able to extract data from it.

layer8 2y ago

I know, but what is the practical difference for the file loader? In both cases you have formats with open-ended extensions (PNG chunks and XML elements), and in both cases you have to make sure that the overall format matches what you expect.

jdiff 2y ago
For SVG there are standards that define how to interact with unknown elements, and a set of standard elements which are actually part of the spec. With PNG, there's a minimum set of chunks that are required, and you can safely stick with those and get something that works for the vast majority of cases. This is totally different from a container which can contain any type of data in any type of format. If you get a valid PNG, you can load something meaningful from it. If you get a generic container, you might be able to inspect it at a surface level but there's no guarantee that the contents are even conceptually meaningful to you.
- layer8 2y ago
  Effectively the same is true for IFF-compliant formats like ILBM and AIFF, which are usually distinguished either by file extension or by file-system metadata. It’s a bit like criticizing a format for being XML-based, under the argument that XML can represent all kinds of payloads.
  - jdiff 2y ago
    That's exactly what I'm working towards. It's the difference between just using an XML file and using an XML file with a unique extension tacked onto it. It represents a subset with set expectations for behavior. That expectation is what matters. For generic containers, there are no expectations on what's inside. If I'm making a video player, do I support MKV? Well, some of them. Not all of them. You have to try it and find out. Heck, even within a single codec it's hard to find complete support. Last I checked, browsers won't touch an H264 stream unless it's also YUV420p which also places certain restrictions on physical dimensions of the data and probably some other stuff that's escaping my mind. If I'm making an image viewer, do I support SVG or PNG? For this example, let's say I only support PNG, but I can tell from the outset what's inside any file I might try to load. I can confidently say I can meaningfully load and display anything that uses the established standards of the PNG format to store image data. Sure, there are extensible bits, but they're not part of those core expectations surrounding the core part of the format, the image data I care about. And I didn't have to try and open the PNG first to see if it was actually an SVG. I can recognize not-bitmaps at a glance without having to inspect them any deeper than their extension.
HarHarVeryFunny 2y ago
With RIFF you not only need to be able to handle the container format, but also the specific type of payload content, which for video varied from simple uncompressed YUV formats like Y41P to proprietary compressed ones like WMV1 (Windows Media Video). Being able to handle the RIFF format therefore had no bearing on whether you'd be able to extract data from it.