TiVo to Mac to Apple TV — Part IV, Fine Tuning

In my previous post, TiVo to Mac to Apple TV — Part III, One-Stop Shopping, I told how I use kmttg to download onto my Mac movies from the Turner Classic Movies HD channel that have been recorded on my TiVo Premiere. During the download, kmttg simultaneously decrypts the file: removes the copy protection so that the resulting file on my Mac is an ordinary .mpg file. Then, since .mpg files can't be used by an Apple TV, I tell kmttg to invoke the popular video reformatter HandBrake to re-encode the file as an .m4v file. I furthermore arrange to have HandBrake insert into that .m4v file, as soft subtitles — "soft" subtitles are subtitles which may be viewed optionally, at the user's discretion — the closed captions that were embedded in the original .mpg file.

It also works with movies from other cable channels such as Encore HD.

To do it in my last post, I created, in a text file called hb_my_appletv.enc, a kmttg "encoding profile":

# Description (single line, keep short)
Handbrake AppleTV: m4v container, AppleTV preset (h.264 video, aac & ac3 audio)

# Encode command or script (single line)# Known keywords: FFMPEG, MENCODER, HANDBRAKE, PERL, INPUT, OUTPUT, PWD, CPU_CORES, SRTFILE
HANDBRAKE -i INPUT --cpu CPU_CORES --preset AppleTV --subtitle 1 -f m4v -D 1,1 -A "Stereo","AC3" --rate 29.97 -v -o OUTPUT

# Encoded output file extension
m4v

That hb_my_appletv encoding profile has drawbacks when kmttg uses it, though. Its main problem is a bit on the geeky side: it fails to "detelecine" the film-based video that it encodes in the .m4v output file.

Now for some extremely nerdy stuff shown in italics with a yellow background to explain what I've just said (feel free to skip over it):


When a movie is shown on 1080i HDTV, it undergoes a "telecine" process to compensate for the fact that motion picture film consists of only 24 frames per second. The 1080i format used by TCM HD and most other HD movie channels uses 30 video frames per second. (Actually, for highly technical reasons, that 30 fps is slightly lowered to 29.97 fps.)


The "telecine" process, also known as "3:2 pulldown" or "2:3 pulldown," shows some of the original film's frames to the video camera for a slightly longer time than it shows other of the film's frames.


Each second, as 24 film frames are being exposed to the video camera, the video camera is recording 29.97 video frames — not 24 video frames — in such a way that each video frame is divided into two video "fields." The video fields are captured by the video camera at a "field rate" of (29.97 x 2), or 59.94, fields per second.


The division of each video frame into two separate video fields is called "interlacing." The "i" in 1080i indicates that the video is interlaced.


Each video field is missing exactly half of the horizontal scan lines that make up a complete video frame. For example, in 1080i video each frame has 1080 scan lines. Lines 1, 3, 5, 7, ... , 1079 (the odd-numbered lines) make us the first field in each pair of video fields. Lines 0, 2, 4, 6, ... , 1078 (the even-numbered lines) make up the second field of each pair.


Ordinarily, each pair of fields — even though the two fields in the pair are time-offset by a small fraction of a second  — can be thought of as making up a single video frame. In telecined video, though, problems arise when you do that.


The root of the problem is that the .m4v file which HandBrake creates isn't permitted to use interlaced video. It has to use "progressively scanned" (or, more simply, "progressive") video, meaning that each video frame is kept intact and not divided into two successive, time-offset video fields.


When interlaced video is re-encoded as progressive video — for instance, when kmttg's use of HandBrake invokes the hb_my_appletv encoding profile shown above — some of the film's frames are presented for a duration long enough to show up, in the original interlaced video, in three successive video fields instead of just two. Accordingly, in the progressive video that kmttg's re-encoding process creates, there wind up being two video frames out of each group of five successive video frames that are composites of two successive film frames.


When that happens, objects that are in motion on the screen (or seem to be moving because the film camera is panning) show up in two slightly different places in the progressive video frame. This graphic shows an exaggerated version of the "jaggies" that result:

Obviously, if you use a computer-based video player such as VLC or QuickTime Player that can freeze video motion and then do frame-by-frame video advance, you can readily see the jaggies that occur in precisely two successive progressive video frames out of each group of five progressive frames, i.e., the two of the five that are derived from different film frames. But the important thing is that you can also see a lack of smoothness, clarity, and motion uniformity when the resulting progressive video is watched at normal speed.


All this is due to the fact that, when interlaced video that has been telecined from 24-fps film at 29.97 video frames per second (actually, 59.94 video fields per second) is re-encoded as 29.97-fps progressive video that does not employ video fields at all, jaggies result ... and the motion you see on a TV screen loses clarity, uniformity, and smoothness.


The problem goes away, though, if you "detelecine" the interlaced video as it is being re-encoded as progressive video. Luckily, HandBrake knows how to do that. If you specify its --detelecine parameter, it can detect which two frames (or, actually, which two field pairs) out of every five field pairs in the 1080i input video had the paired two fields come from different film frames. Knowing that, it can simply strip out the redundant information which the telecine process used to pad out the 24 fps of the movie to get 29.97-fps interlaced video.


The result is that each video frame of the .m4v output matches up exactly, one for one, with a single frame of the original film.


Clearly, however, this works properly only when HandBrake is permitted to reduce the 29.97-fps frame rate of the input .mpg video to 24 fps in the .m4v output. In other words, HandBrake's video output has to wind up with the same frame rate as the original film had: 24 frames per second. This requires not giving HandBrake a -r or --rate setting — such as, for instance, --rate 29.97.

OK. That's the end of the nerdy stuff. The takeaway is that "telecined" video is padded out to a frame rate higher than that of the original film. I need a kmttg encoding profile that employs HandBrake's --detelecine option ... but does not specify its -r or --rate setting at all. This will turn the 29.97-fps 1080i video in the input file into 24-fps video in the output. Each of the output video frames will represent exactly one film frame from the original movie.

Here is my hb_my_appletv_1280 kmttg encoding profile that does all that:

# Description (single line, keep short)
m4v container, soft subtitles, 1280 x ___ video, detelecine

# Encode command or script (single line)# Known keywords: FFMPEG, MENCODER, HANDBRAKE, PERL, INPUT, OUTPUT, PWD, CPU_CORES, SRTFILE
HANDBRAKE -i INPUT --cpu CPU_CORES -e x264 -q 20.0 -X 1280 --subtitle 1 --detelecine --loose-anamorphic -x cabac=0:ref=2:me=umh:b-adapt=2:weightb=0:trellis=0:weightp=0 -a 1,1 -E faac,copy:ac3 -B 160,160 -6 dpl2,auto -R Auto,Auto -D 1,1 -A "AAC","AC3" -f m4v -v -o OUTPUT

# Encoded output file extension
m4v

It is the --subtitle 1 specification that tells HandBrake to convert closed captions into "soft" subtitles, by the way.

(This page gives a full rundown on the various HandBrake settings such as, --subtitle, --detelecine and --loose-anamorphic. You can learn what settings are specified in HandBrake's AppleTV and other built-in presets here.)

If you use the Finder's Duplicate command to make a copy of (say) the hb_appletv.enc file that already exists in the encode folder that comes with kmttg, you can then use TextEdit to edit the copy of the file. Copy the above text and paste it in place of the text already in the file, then save the file as hb_my_appletv_1280.enc. Launch kmttg (or if it is already running, choose the "Refresh Encoding Profiles" item in its File menu). Then you can select hb_my_appletv_1280 in its "Encoding Profile" popup menu.

Shortening the Encode

When I do that and then encode a video in kmttg using this hb_my_appletv_1280 encoding profile, the encode process takes up to, say, ten hours, the exact time depending on a number of factors. To shorten the encode time (at the expense of having lower video resolution in the output file) I created the kmttg encoding profile going by the filename hb_my_appletv_720.enc ...

# Description (single line, keep short)
m4v container, soft subtitles, 720 x ___ video, detelecine

# Encode command or script (single line)# Known keywords: FFMPEG, MENCODER, HANDBRAKE, PERL, INPUT, OUTPUT, PWD, CPU_CORES, SRTFILE
HANDBRAKE -i INPUT --cpu CPU_CORES -e x264 -q 20.0 -X 720 --subtitle 1 --detelecine --loose-anamorphic -x cabac=0:ref=2:me=umh:b-adapt=2:weightb=0:trellis=0:weightp=0 -a 1,1 -E faac,copy:ac3 -B 160,160 -6 dpl2,auto -R Auto,Auto -D 1,1 -A "AAC","AC3" -f m4v -v -o OUTPUT

# Encoded output file extension
m4v

... to give me output video with not 1280 but 720 pixels per scan line across the screen. When I tell kmttg to encode with that hb_my_appletv_720 profile ...

... I wind up with an .m4v output file that is suitably detelecined, but it only has video resolution comparable to that of an ordinary DVD. The encode process takes much less time, though, so I consider the loss of video resolution to be a very small price to pay.