5 ms·
QuickTime as a Tape Archival Format
- stop50 3y agoAn interesting idea
- actionfromafar 3y agoA great idea! Could even put an actual video stream in there as a "thumbnail" of what is in the data streams.
- KaiserPro 3y agoSupporting actual quicktime from what I recall is a massive massive faff. The colleges that have dealt with QT first hand all seem to loath it with a passion.
- jfb 3y agoThe file format is pretty good, though, and that's largely what's being discussed here.
- deleted 3y ago[deleted]
- eschaton 3y agoThanks, I’m glad someone understood my post. :)
- jfb 3y agoI played some games with QuickTime when I was at Apple, loved the format, even loved the stack, as creaky as it was in (gasp) 2004. The idea that the file can carry tracks that the given reader might not understand allowed me to, for instance, put codec metadata back into intermediates that would otherwise be lost, for PQ analysis purposes.
- deleted 3y ago[deleted]
- parl_match 3y agoQuickTime is a very legacy format, one that even apple seems to have internally pared down heavily. It's one of the first, and it's going to have rough edges.
- jfb 3y agoThe container is a great format, battle-tested, easy to parse and generate. It's really good!
- wut42 3y agoA legacy format... that still lives on as the mp4 container.
- dylan604 3y agothat's not entirely accurate. quicktime has been extended after MP4 container was standardized. so, the MP4 container was based on the version of QT at the time. For example, the color atom was added after that to help players with knowing how to interpret SD/HD colors. They've deprecated using the CLASP and other older features as well. So QT isn't just a locked format living along as MP4. Some apps like MediaInfo will report an MOV with prores and pcm audio as MP4 though, so some people still seem confused.
- CharlesW 3y agoIf the word "legacy" comes to mind I'd guess that you're thinking about 90s-era video codecs. This article is about the file/container format, which was directly adopted as the MPEG-4 file format, which becamse generalized as ISOBMFF (https://en.wikipedia.org/wiki/ISO_base_media_file_format https://en.wikipedia.org/wiki/ISO_base_media_file_format), which won an Emmy in 2021. It's a modern, flexible, extensible format, and so is likely to be around long after we're gone.
- eschaton 3y agoThe only significant rough edge in the QuickTime container format that I know if is the means for extending atom sizes and data offsets to 64 bits. Otherwise it’s extremely clean, especially given that it was designed almost 35 years ago.
- spicybright 3y agoI wasn't expecting much going in but that was a great read. Hearing quicktime turned me off but it's actually an interesting format from this articles description. Obviously proprietary formats with not many open source parsers is the biggest issue, but still a neat idea to think about.
- CharlesW 3y agoThe QuickTime Movie container format became ISOBMFF (https://en.wikipedia.org/wiki/ISO_base_media_file_format https://en.wikipedia.org/wiki/ISO_base_media_file_format), which is open, and so happily has lots of open source support.
- koito17 3y agoNot to mention, it's always been easy to access the QuickTime File Format Specification, and I have seen it being used all the time by people wanting to implement MP4 (de)muxers but not having the money to buy overpriced ISO specifications or effort to hunt around for drafts of MPEG-4 Part 14. There are subtle differences in how you should lay out some atoms (e.g. ftyp is subtly different in QuickTime, MP4 uses free instead of wide atom, some Macintosh-specific fields in vmhd(?) and related atoms are always zeroed out and marked as "reserved" in MP4, etc.). But it's easy to gloss over these differences when you do not care about the Macintosh-specific things (like QuickDraw transforms, sprites, ...)
- eschaton 3y agoThanks! QuickTime’s not proprietary, it’s been well-documented and open since it was new and being 30+ years old there’s not a lot of encumbrance to worry about.
- dylan604 3y agoThe QuickTime container has a lot of unused capabilities. At one point, you could add a Flash track to an MOV that could control the audio/video tracks. At the time, there was a lot of DVD like MOVs where it would switch audio tracks to commentaries or other languages. You could switch to a different video track like angles. The format might be nasty thing to try to parse, but it could do a lot more than just hold a set of video/audio streams.
- donatj 3y agoI've pondered recently if with random access being basically free these days if interleaved media formats are still necessary? Clearly for streaming purposes they make sense but it seems like you could just time align video and audio streams manually in other contexts?
- wongarsu 3y agoSequential access is still a lot cheaper on all levels of the stack. Whether that's playing the file from a network drive, reading the file from disk or even reading RAM or L3 cache. Pulling up random benchmarks, top-of-the-line M.2 SSD are 2-3x faster in sequential reads than in random reads. If you do random reads from a single thread the sequential reads are about 100x faster.
- GauntletWizard 3y agoI wonder how much of that is over-optimization for sequential reads. When I was working in filesystems (back in the spinning rust days), I saw some code whose job it was to prefetch the next several hunks of data when you accessed data - It was a scaling algorithm, so if the block you were accessing was already in memory it would read several more hunks, and the next time you accessed from that same sequence it'd read 2x more than that, up to a fairly high limit - It made sense in this context to, shortly after a file was opened, just read the entire file into memory if it seemed likely to be used in short order, because disk queue latency was often the major limiting factor. What this meant was an at least 2x and often 100x read amplification for truly random reads. There were some heuristics to disable that, too, and then drive controllers started doing this directly so some code to managed that interaction, issuing more early in the "pretty sure we want to read more" path but dialing back the scaling. I would not be surprised if this type of logic is implemented into modern SSD controllers directly. When you issue a random read, it actually reads several sectors ahead, just in case those are the next requests. If we disabled that - How much faster would the random reads path be? How much slower would the sequential be? I suspect (very heavily, given the availability of enterprise drives with precisely this kind of tuning available) that there's a lot of tradeoff to be made.
- dist-epoch 3y agoWhy not Matroska? Should have the same capabilities, but a much bigger open-source ecosystem.
- eschaton 3y agoI 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 agoOut 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 agoTo 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.
- kevin_thibedeau 3y ago> Since tapes themselves are linear, they’re fundamentally time-based. That's definitely not true for LTO which can consume non-deterministic amounts of tape when a write head is acting up or there are buffer underruns.
- deleted 3y ago[deleted]
- eschaton 3y agoI meant in the ideal sense, not practical—every bit of tape essentially corresponds to a timestamp because the medium is essentially one-dimensional. Of course the physical reality of tape is much more complex, but when considering something like an archival data format you need to take into account which aspects of physical reality to preserve and which aspects to drop. The advantage of the QuickTime container format is that it allows for a straightforward representation of all of the aspects of tape that matter for archival purposes—including subtleties like inter-block gaps, tape mark sequences, leader lengths, bad blocks, and so on—in addition to allowing straightforward and efficient storage of data blocks of varying sizes and open-ended metadata, as well as allowing for the possibility of non-destructive editing. Most attempts to represent tape for archival to this point simply haven’t handled any of this, and have instead have just treated tapes as fixed sequences of files containing blocks, often without even recording the sizes of those blocks.
- bitcraft 3y agoThis is a great use of the format. I love to see novel uses of existing technologies.