One of the coolest aspects of the QuickTime format (the one I know the most about) was the separation of the moov and mdat atoms. It let an editing application

One of the coolest aspects of the QuickTime format (the one I know the most about) was the separation of the moov and mdat atoms. It let an editing application define cuts and add tracks without reserializing (to say nothing of re-encoding) the whole file. A track referenced in a moov header could also point to an entirely different file on disk. A lot of non-destructive edits could simply be performed on the moov header which could live on a small slow disk referencing mdats in files living on a large fast disk. Thanks to the way aliases worked the external file could be an alias to sort of get automatically found if the large fast disk was removable like an external SCSI disk. This let the relatively weak 68k Macs of the day do offline editing of video without a bunch of extra hardware (like the Amiga's VideoToaster). The QuickTime format did allow the moov and mdat atoms to be serialized into a monolithic file so they could work on single fork file systems. The format was later extended so external references could be URLs. Ref Movies were a small MOV that referenced tracks living at different URLs. This was extended further to tag referenced tracks with bandwidth settings much like how HLS works. A small Ref Movie could point to a postage stamp 56k stream and a high res T1 stream (or whatever bandwidth) and the player depending on its local network conditions would pick the appropriate reference. QuickTime Player 7's "Export for Web" function used this method. It would encode multiple versions of a movie then build a Ref Movie pointing to them. It even built a small HTML file with the appropriate embed/object tag incantation to stick the output on the web easily. RealPlayer had similar reference functionality with RAM files, they could reference streams at multiple bandwidths to let the player pick the appropriate one for local conditions.