In yesterday's article, along with a lot of benchmark data, I've explained the advantages of optimizing your iOS- and Apple TV-native (that is, MP4, MOV or M4V) video files, should you want to stream it or watch it from a, head seek-wise, inherently slow(ish) medium like an optical disc or a traditional hard disk.
In the current one, I explain how you can find out whether a video is indeed optimized or not. That way, you can save you a lot of time by avoiding re-optimizing it. If the tool you use allows it at all – for example, iFlicks or MP4Tools don't allow for separate optimizations, “only” during at the end of a full, (compared to a quick, manual checking) time-consuming remuxing. (Subler, of course, does it – see yesterday's tutorial on using this feature.)
It's very-very easy to find out whether a particular video file is optimized. I show you two ways of doing it.
1. The easy way
First, an easier, faster but more error-prone way: a simple file viewer like Total Commander (which, should you use OS X, runs just fine under CrossOver and in no way need a full-fledged Windows environment like Parallels to run – this is why I present Mac-like file viewer screenshots below).
First, an optimized file (I've also made it available HERE) put the "MooV" atom at the beginning of the file; pay attention to my red rectangle annotation:
(This is also mentioned in the Subler FAQ)
A screenshot of the same file but before optimization follows. It shows no moov at all and, therefore, easy to differentiate from the optimized one:
This method works under all operating systems – under Windows (and, as you can see, even OS X!) with Total Commander (and with tons of other file viewer apps) etc.
2. The harder but safer way
First, get the latest “ISO Viewer XX executable jar” (where XX is currently 2.0-RC-15) from https://code.google.com/p/mp4parser/downloads/list. Under OS X, just click it; under Windows, you may need to install Java first. When it shows its interface, select File > Open and load your movie file. Now, in the let pane, switch from “Box Structure” to “Track & Samples”.
You'll see some tracks there. With the elongated “Birds” video, there will be three of them, the first being the video and the other two the audio tracks.
First, let's take a look at the video track (just select it on the left) in both the unoptimized and the optimized case.
2.1 The unoptimized video
The unoptimized looks like this (the video is accessible HERE; note: large, 700+Mbyte download! You can check out other videos (for example, the ones I've linked to from my yesterday's article) as well before and after optimizing; their structure look similar but, of course, the file positions will differ):
What can you see in the right pane (assuming it's, as is by default, entirely scrolled up)? The first video sample starts at file position 45672 and is 1311747 bytes long. (This is what the first row means there.) The second starts at 1357419 etc. If you scroll entirely down to the bottom:
you'll see the last (3188th) video chunk starts at position 689,470,298 in the file – that is, some 15 Mbytes (the size of the last video chunk is only 27,442 bytes) before the end of the file (which is at position 704,180,885), meaning there's a lot of info after the last video chunk.
Now, let's take a look at the two audio tracks. Select Track 2 and, as with the video, check out the first record at the top:
The first starts at position 689,497,748 – that is, almost immeditately after the last video chunk, which ends at, as we've seen, position 689,470,298 + 27,442.
The last record at the bottom shows it starts at 700,646,548:
Finally, track 3 (that is, the second audio track) starts at 700,649,108 (immediately after the first audio track finishes):
… and ends at 704,099,532 (almost immediately – some 90kbytes - before the end of the file):
What's the verdict? Yes, albeit the three tracks are all stored as short(ish) chunks, they aren't interleaved: the first chunk of the second stream starts strictly after the last chunk of the first ends and so on. This is what causes a lot of additional buffering while streaming and, with optical / mechanical discs/disks, unnecessary head movement between the current video position and the end of the file to read the audio chunk(s) belonging to the current video chunk(s).
Now, what about the optimized video?
2.2 The optimized video
The video (which is an optimized version of the above one; it's not available online but you can easily create it by just using Subler to optimize) has three track, as before.
The video track samples start at 81,375 and end at 703,986,509 (with the size of 27,442, as in the non-optimized case):
The first audio track starts at 7,708,602 and ends at 704,128,621:
The second audio track starts at 7,718,842 and ends at 704,135,227:
See? The audio track chunks are interleaved with the video track chunks. The video and audio chunks belonging to each other are also very closely stored in the file.
This way, you can easily see whether a particular track is correctly interleaved. Just select the non-video tracks and check where they (more precisely, their first chunk) all start. Close to the start of the file (say, in the first 10 million bytes)? The file is, then, optimized. Around the end of the file? Then, it isn't.
3. Other uses of ISO Viewer
The first tab of the left pane, “Box Structure”, allows for checking out other parameters of the file. For example, it'll list the H.264 level – something you'll always need to set when trying to synchronize some of your BD rips or camera videos to your iOS device (see for example THIS for more info). An example shot of this:
This (see my annotation) shows the (absolutely errorenous) level 5.0 some of the latest Canon cameras (for example, the S100 and G1 X) use with their 1080p24 and, consequently, not even level 4.1 videos.
Unfortunately, ISO Viewer can strictly be used for checking this information. While the values are editable and there's even an “Apply Changes” button with non-container boxes, the edited values won't be stored back in the file. That is, you in no way can use ISO Viewer to edit the level of a H.264 video to, say, make it accepted by iTunes for iOS synchronization or shown by Safari when directly accessed on the Net.
There's another library, “MP4 Parser”, of the same developer, which also allow for writing. I'll definitely return to it in another article. For the time being, just a quick bugfix I've just invented for his PrintStructure.java, which immediately crashes after the “fc.read(bb);” statement: just add the “bb.rewind();” statement immediately after that. Then, the code will happily work.