My inclination is that the optimization isn't really worth the risk.

The wording of the Quicktime spec is a little ambiguous:
>The movie atom has an atom type of 'moov'. It contains other types of atoms, including at least one of three possible atoms—the movie header atom ('mvhd'), the compressed movie atom ('cmov'), or a reference movie atom ('rmra').

I think the assumption that `cmov` atoms tend to exist alone is probably correct, but it's very hard to know for sure.
I avoided the optimization because:
- The Quicktime format spec gives a fair amount of lip service to gracefully ignoring unexpected atom configurations so future changes in the spec are less likely to break things
- The Quicktime spec doesn't expressly forbid `cmov` atoms having siblings as far as I could tell
- Anecdotally, I've seen a lot of interestingly structured Quicktime movies in the wild so it is hard to predict what might come in
- The added cost in most worse-case scenarios is reading something like an extra 40-100 bytes of data under the average uncompressed `moov` (timeit pegs this at taking about 684 microseconds on my setup)
- The downside, if the assumption turns out wrong, would mean likely data corruption