UPDATE (24/Feb/2013): see
https://forums.macrumors.com/posts/16900876/ for an even easier way.
I've heard this from a few people, but I haven't noticed any differences between the file before and after it's gone through iFlicks. I recently gave
iDentify 2 a chance and it works pretty well, although I don't think it can import into iTunes like iFlicks can (maybe the paid version can, I'm not sure).
iFlicks does optimize automatically its remuxed output while remuxing (and this can't be disabled, even if you absolutely don't need to waste time on this) - I think this might be the case when adding metadata.
BTW, it's very easy to quickly test whether an MP4 (mov / m4v) file is optimized. Here's a full tutorial on it (I copy it here in its entirety as I don't want to promote my blog by just giving you a link to the original. Sorry for the length: when writing tutorials, I tend to be as clear as possible):
Apple TV users and Streaming Video Providers attention: deciding if a video file is optimized
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 article 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):
(top)
(bottom)
The first audio track starts at 7,708,602 and ends at 704,128,621:
(top)
(bottom)
The second audio track starts at 7,718,842 and ends at 704,135,227:
(top)
(bottom)
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.
