4 ms·

I suggested it because I’m more familiar with the QuickTime container format from 30+ years as a Mac developer, the QuickTime container format is straightforwar

I suggested it because I’m more familiar with the QuickTime container format from 30+ years as a Mac developer, the QuickTime container format is straightforward to implement, well-documented and unencumbered, it’s the basis of ISOBMFF which is a standard already, and (crucially) it maintains a significant degree of separation between general-purpose concepts and specific CODEC implementations. The latter is why there are both tracks and track media in QuickTime while a lot of more playback-specific formats combine them. In the QuickTime architecture, a video track is a video track regardless of whether it’s implemented using Motion JPEG or Cinepak or MPEG-4 etc. Same with audio, subtitles, and any other form of data stream. The high-level types and low-level implementations of those types are kept distinct so most tooling can be written at a higher level, while enabling a developer to reach down to a lower level as necessary or desired.

DaiPlusPlus 3y ago
Out of curiosity, did you consider RIFF? Ostensibly it predates QTFF, but shares the same structure and concept of being a sequence of tagged chunks. I'm curious why ISO decided to standardise QTFF for BMFF over RIFF. I also note that RIFF itself is based on IFF, from which Apple derived AIFF, which shares similarities with QTFF, so maybe that Emmy award should have gone to Electronic Arts for inventing IFF in 1985 ...also, genuine question: are there any known predecessors of IFF's "chunked-sequential" file-format? (idea: reckon we'd find anything interesting in the docs for LucasArt's EditDroid's file-formats?)
- eschaton 3y ago
  To my knowledge, RIFF is comparable to the lowest levels of the QuickTime container format in that it’s made up of chunks with a tag and a size. Lots of file formats have done that back into the 1960s and probably even before, it’s one of the most basic ways to represent typed records in streams. (I think a lot of people forget that data processing started with fixed-sized records, and that streams and variable-sized records were innovations.) What the QuickTime format supports that makes it appropriate for representing tape data—and for receiving Emmy and Oscar awards, among others, for its classical uses—is provide a bunch of additional abstractions atop its low-level implementation to represent typed and subtyped streams of data that (accurately!) span time intervals using arbitrary timebases. One of the reasons some other formats are less appropriate is that they don’t have that separation between type and subtype (track and track media, in QuickTime terminology), don’t allow arbitrary tracks, don’t support media with different native timebases, etc. This means you can’t easily write code that’s agnostic of the sample representation and CODEC details. (This was my issue with Ogg a couple decades ago—it’s a playback format for finished artifacts, not a format for authoring and editing.) I figure instead of reinventing all of the stuff that’s already been done the past 30+ years for getting that sort of layering right, it’s much easier to just come up with some new track types and CODECs and fit them into an architecture that already supports most of what the problem requires.
- Lammy 3y ago
  > are there any known predecessors of IFF's "chunked-sequential" file-format? https://www.martinreddy.net/gfx/2d/IFF.txt https://www.martinreddy.net/gfx/2d/IFF.txt “Previous Work” sez — “Our basic need to move data between independently developed programs is similar to that addressed by the Apple Macintosh desk scrap or "clipboard" [Inside Macintosh chapter "Scrap Manager"].” “Macintosh uses a simple and elegant scheme of 4-character "identifiers" to identify resource types, clipboard format types, file types, and file creator programs. […] We'll honor Apple's designers by adopting this scheme.” “We may also borrow some Macintosh IDs and data formats.” And some other mentions too, like Postscript and

DaiPlusPlus 3y ago

Out of curiosity, did you consider RIFF? Ostensibly it predates QTFF, but shares the same structure and concept of being a sequence of tagged chunks. I'm curious why ISO decided to standardise QTFF for BMFF over RIFF. I also note that RIFF itself is based on IFF, from which Apple derived AIFF, which shares similarities with QTFF, so maybe that Emmy award should have gone to Electronic Arts for inventing IFF in 1985 ...also, genuine question: are there any known predecessors of IFF's "chunked-sequential" file-format? (idea: reckon we'd find anything interesting in the docs for LucasArt's EditDroid's file-formats?)

eschaton 3y ago
To my knowledge, RIFF is comparable to the lowest levels of the QuickTime container format in that it’s made up of chunks with a tag and a size. Lots of file formats have done that back into the 1960s and probably even before, it’s one of the most basic ways to represent typed records in streams. (I think a lot of people forget that data processing started with fixed-sized records, and that streams and variable-sized records were innovations.) What the QuickTime format supports that makes it appropriate for representing tape data—and for receiving Emmy and Oscar awards, among others, for its classical uses—is provide a bunch of additional abstractions atop its low-level implementation to represent typed and subtyped streams of data that (accurately!) span time intervals using arbitrary timebases. One of the reasons some other formats are less appropriate is that they don’t have that separation between type and subtype (track and track media, in QuickTime terminology), don’t allow arbitrary tracks, don’t support media with different native timebases, etc. This means you can’t easily write code that’s agnostic of the sample representation and CODEC details. (This was my issue with Ogg a couple decades ago—it’s a playback format for finished artifacts, not a format for authoring and editing.) I figure instead of reinventing all of the stuff that’s already been done the past 30+ years for getting that sort of layering right, it’s much easier to just come up with some new track types and CODECs and fit them into an architecture that already supports most of what the problem requires.
Lammy 3y ago
> are there any known predecessors of IFF's "chunked-sequential" file-format? https://www.martinreddy.net/gfx/2d/IFF.txt https://www.martinreddy.net/gfx/2d/IFF.txt “Previous Work” sez — “Our basic need to move data between independently developed programs is similar to that addressed by the Apple Macintosh desk scrap or "clipboard" [Inside Macintosh chapter "Scrap Manager"].” “Macintosh uses a simple and elegant scheme of 4-character "identifiers" to identify resource types, clipboard format types, file types, and file creator programs. […] We'll honor Apple's designers by adopting this scheme.” “We may also borrow some Macintosh IDs and data formats.” And some other mentions too, like Postscript and