TiVo Multi-Room Viewing (Yet Again)

Recently, in TiVo Multi-Room Viewing (Again), I indicated my disappointment that my new (second) TiVo DVR can't share recordings with my first TiVo if the recordings are copy-protected.

I have a home wireless network. Both of my TiVos are nodes on it (in addition to my two Mac computers, a cable modem, and assorted Apple TV and AirPort networking devices). After a TiVo makes a recording, in theory that recording can be copied via the network to the other TiVo, in what the folks at TiVo Inc. call "multi-room viewing" or MRV. The only problem is, an awful lot of the programs are copy-protected: their digital bitstreams contain a flag bit that says, "This program can be copied once, i.e., only for a single generation. The copy cannot then itself be copied."

Owing to how TiVo Inc. has chosen to comply with an agreement it has entered into with CableLabs, a consortium representing the cable TV industry and, indirectly, the providers of copyright-protected programming to cable channels, that flag bit is in fact honored by not letting a copy-protected program participate in MRV.

Note that no programs on channels that are broadcast locally over the air and then carried on cable are copy-protected in this way, only many (but not all) programs on cable-only channels.

If a copy-protected program on the first TiVo could be viewed on a second TiVo, then the way that would happen is this: it would be copied to the second TiVo. Thenceforth, it could be watched on the second TiVo ... or the original could still be watched on the first TiVo.

But, no. TiVo Inc. chooses instead to not allow MRV copying of "copy once" originals. As far as I can tell, the main reason is the fear on the part of the cable industry and program copyright holders that the original bitstream could be intercepted and have its copy protection stripped while a legitimate copy is being made across the home computer network.

In theory, at least, TiVo Inc. could go to CableLabs and ask for special approval of a (presently unspecified) scrambling or encryption method that, if used by TiVo DVRs for MRV, would nullify the piracy threat. However, the granting of said approval is not something that has happened ... yet.


The present way of doing MRV ties the original version of a copy-protected program to a specific device: the actual TiVo DVR that made the recording. A non-copy protected recording is, on the other hand, tied to a specific home network, not a specific device on that network. I believe any "fix" for the present inability to share copy-protected programs among multiple TiVos on a single home network would need to make such programs network-specific rather than device-specific.

I believe it was the original intent of TiVo Inc. to do exactly this, but the CableLabs agreement got in the way.

TiVo Inc. apparently intended to base MRV authorization on the TiVo's Media Access Key (MAK). The MAK is a unique 10-digit number that identifies every TiVo. It can be brought up on a TiVo's associated TV screen by means of the Messages and Settings menu hierarchy of the TiVo. Once you know what your TiVo's MAK is, you can (for instance) enter it into TiVo Desktop/TiVo Transfer software on your computer to enable TiVoToGo.

TiVoToGo is the ability to copy (again, non-copy protected) recordings from a TiVo to a computer. Once the copies are on the computer, they can be viewed and/or decrypted, then converted to other video formats such as for use on an iPod.

The decryption of a computer file with a .TiVo extension, once it has been copied from a TiVo DVR to the computer via TiVoToGo, requires that you enter the MAK of the originating TiVo into the computer software doing the decrypting. (That is, the MAK needs to be specified both to copy the recording and to decrypt it. The latter may be done by the same software as the former. If it is not, the MAK has to be specified to both.)


Details of the TiVo encryption-decryption system are hard to come by. Apparently, the TiVo DVR takes the "MPEG-2 program stream" which contains the TV show's video and audio information, as recorded in digital form, and it puts some kind of digital "wrapper" around it. For the original video and audio to be played, the wrapper must first be removed. This is something that cannot be done properly unless the software knows the MAK used by the originating TiVo DVR at the time the wrapper was created — at the time the show was recorded by that DVR, that is.

When a recording is copied from its original TiVo to a computer or to a second TiVo, the wrapper comes along with it. The resulting copy of the original recording cannot be played unless it can be unwrapped first — which can't happen unless the computer or second TiVo knows the MAK.

As I found out when I added a second TiVo to my home network, all TiVos on the same home network share the same MAK! (A TiVo on a different home network, though, has a different MAK.) Clearly, if the MAK is the basis for unobstructed MRV'ing of material on a local home network, all TiVos on the same home net should be able to participate in unobstructed MRV sharing of copy-protected material, in particular. TiVos not on the same network, since they do not share the same MAK, couldn't share the recordings. Neither could computer software applications that have not been supplied with the original MAK.


I suggest as a possible solution to the current MRV impasse that the MAK might be used as a digital "watermark" which the recording TiVo (or any other compliant DVR) visibly embeds in the video of a recording that is being shared via MRV.

Below is a sample of a watermarked image:


In the simplest implementation, "watermarking" would indelibly stamp the copied video recording with the identity (MAK) of its source DVR, which, as I have said, is actually the MAK of the home network. Any DVR with the same MAK (because it is on the same network) could compensate for the watermark and effectively "erase" it from the video as it is being legitimately played back. Watermark "erasure" would be done for legitimate playback only. The watermark would remain a part of the original recording and all copies made of it. Moreover, if a third-generation copy were made from a legitimate second-generation copy, it too would bear the watermark. No matter how many generations of copies were made, every generation's copies would duly inherit the watermark.

In a more elaborate implementation of the watermark strategy, instead of using the actual MAK as the watermark, the watermark could be an encrypted version of the MAK that could be matched for purposes of "erasure" during playback only by using that same encryption key (or a closely related one) to manipulate the supposedly identical MAK which is known to the playback device or application. More on that possibility later.

Or, instead of using the (encrypted or not) MAK as the watermark, the recording TiVo could use the user name on the account to which the TiVo belongs. Because every TiVo on the home network has access, via the network, to the TiVo Inc. database, it could (based on the MAK) fetch the same user name when doing MRV playback of a copy-protected recording. The retrieved user name, instead of the MAK itself, could be used as the basis of "erasing" the watermark for playback.


In any implementation of MRV watermarking, the MAK would be crucial in three ways. First, the MAK would need to be specified by the receiving TiVo to the recording TiVo in order for the latter to gain access to the recording TiVo's Now Playing list. Second, the MAK would be required for the receiving TiVo to be able to "unwrap" the copied recording. Third, the MAK would be required for the receiving TiVo to know how to "erase" the video watermark at playback time.

Similarly, if the destination device were a computer and not another TiVo, the same three mandatory uses of the MAK would apply. All legitimate uses of a watermarked TiVo recording would be MAK-dependent in three interlocking ways.

If a watermarked video recording were intercepted and diverted in an act of piracy, all protocol-compliant computer software, or any protocol-compliant home-entertainment hardware such as a TiVo or another DVR, could simply refuse to play it if that software or hardware were not privy to the same MAK. Alternatively, protocol-compliant software or hardware could go ahead and play it in the assurance that the watermark would show up on screen and effectively ruin the playback.

Non-compliant software/hardware might also play it ... but the watermark would be constructed such that only protocol-compliant software/hardware, on the same network with the recording DVR and therefore privy to the same MAK, could successfully "erase" it during playback. Non-compliant software or hardware accordingly would be able to play the video only in a "ruined," visibly degraded way, owing to the presence of the uncompensated visible watermark.


In the scheme I propose, the watermark, which would show up on a TV or computer screen that was trying to play an unauthorized copy of an original recording, would be in some way based on the MAK of the recording DVR. The MAK uniquely identifies the TiVo account of the owner of the recording TiVo, whose responsibility it is to see that his personal recordings don't show up in someone else's hands. As a legitimate TiVo user wanting to avoid the consequences of having "my" recordings show up in "your" (illicit) hands — I might face de-authorization of my TiVo account, or worse — it would accordingly behoove me to make sure my home network was secure against piracy.

In a worst-case scenario, a video pirate might supply a customer with (a) a watermarked video recording derived from someone's TiVo, along with (b) playback software or hardware that is capable of "erasing" the watermark during playback, but only if given (c) the MAK used to watermark the recording.

That scenario could be averted by encrypting the watermark, as suggested earlier. That is, instead of having the watermark be the MAK itself, it could be an encrypted version of the MAK that would be matched for purposes of "erasure" during playback only by using that same secret key (or a closely related one) to manipulate the original MAK and "erase" the watermark. Our pirate (or his customer) would thus have to know the actual MAK of the recording TiVo, not just the encrypted version thereof which shows up as the watermark. He would also have to know the key used to encrypt the MAK for purposes of creating and "erasing" the watermark.

Such an encrypting key might at some point be discovered by the piracy community and compromised. Because TiVos are regularly updated from TiVo Central by means of an Internet connection or phone line, the encrypting key in question could be changed any time it was compromised. If that happened, MRV copies made with the old key would no longer work.

That is, unfortunately, unavoidable. Occasionally, blameless users would be irked to find a legitimate copy they made only yesterday no longer works today. But that's far better than the current situation, in which legitimate users can never make MRV copies of copy-protected TiVo recordings.

Note also that if the MAK-based watermark were encrypted, casual users who stumble across a pirated video online would be unable to learn the MAK of the source TiVo — which is a good thing. Yet TiVo Inc. or any other authorized watchdog, being privy to the original encryption key, would be easily able to identify exactly whose TiVo the pirated copy originated from.


I realize that the ideas I'm broaching herein are sketchy and provisional. They need to be vetted to make sure they are reasonably watertight. The various interlocking concerns who are involved in this issue do have a right to protect their programming against piracy. No one who says otherwise is going to win that argument.

Still, the key word in that preceding paragraph is "reasonably." It is generally recognized that dedicated pirates will find a way around any copy-protection system, given enough time. The aim is to make it very, very hard for them to do so, since making it absolutely impossible is impossible.

That said, any sketchy proposal such as this one needs fleshing out and thorough vetting by all concerned who would be betting their "family jewels" on the success of the methodology. Such fleshing out and vetting ought to be done in the context of developing a full industry-standard protocol for MRV and "to go" usage of copy-protected recordings made by home DVRs and potentially used by other DVRs/hardware devices/computer applications.

It is the present absence of such a multi-industry protocol and accord which is really to blame for my not being able to MRV my copy-protected recordings of TNT's "The Closer."

TiVo Multi-Room Viewing (Again)

Recently I got a TiVo HD digital video recorder:

It joins the TiVo Series 3 I bought two years ago:

You can read about my experiences with the TiVo Series 3 in earlier installments in my TiVo series of posts. In particular, this post gives more details about my main topic herein: TiVo multi-room viewing.

My new TiVo HD hooks to my new living room TV — see My New Samsung LN52A650 TV. The old one hooks to my two-year-old Sony KDL-40XBR2 upstairs in the bedroom. The new TiVo, like the old one, digitally records cable TV programs, including digital channels, analog channels, high-def channels, and premium channels.

One of the nice things I can do with either TiVo is take advantage of TiVoToGo capabilities (see my TiVoToGo series). Programs that have been recorded on a TiVo (if they are not copy protected) can then be transferred via a wired or wireless home network to a computer, where they can be stored or converted into videos playable in iTunes or on an iPod.

Another nice thing I can do, now that I have two TiVos, is "multi-room viewing." MRV (click here for an official description; click here for a FAQ) lets you transfer shows between two or more TiVo DVRs.

Say you have recorded an episode of "House" on your bedroom TiVo but want to watch it on the TiVo in your living room. You go to the Now Playing list on the living-room TiVo — that's the list of programs that have been recorded locally on that TiVo — and scroll down until you reach an entry for, say, "Bedroom TiVo." Selecting the entry brings up the Now Playing list of the remote TiVo in the bedroom!

From that list you select whichever program you want to watch in the living room and then select "Transfer this recording," and the show begins streaming from the bedroom TiVo to the one in the living room. (This assumes, by the way, that you have both TiVos on the same wired or wireless home network.) After you initiate the transfer, you can optionally begin watching the transferred copy as it is being made.

After the transfer has been completed, you will have two copies of the program, one on the bedroom TiVo and one on the living room TiVo. The new copy is for all practical purposes identical to the original, and you can watch it as often as you like, set it up either never to be deleted or to be eligible for deletion after so many days, and do whatever else you are accustomed to doing with "live" TiVo recordings. The only obvious difference is that the new copy does not show the channel, time, etc. of the original recording — though the program information you can pull up by pressing the Info button on the remote is the same.


That being said, there are (as always) some gotchas.

(1) One gotcha is that watching a show in "real time," as it is being transferred, TiVo to TiVo, can be an iffy proposition. If your home network can't keep up speed-wise, then the real-time viewing process can bog down. I have a wireless 802.11g network that I find can keep up nicely with a transfer of a standard-def TV program, but with high-def material it bogs down. HD material uses more bits per second and requires higher bandwidth than my network can manage in real time. As a result, when I am watching an HD transfer in real time, the receiving TiVo frequently goes into pause mode and requires me to hit the play button on the remote to continue. The transfer, meanwhile, continues normally, and after a while, even if I never restart the viewing process, it finishes — at which time all the viewing glitches go away.

(2) Another gotcha is that you may not want to create a permanent second copy. There are two variants. One, you may want just to watch the program stream from the bedroom TiVo on the living room TV, without having the recording copied permanently (until it's deleted, that is) on the LR TiVo. Or two, you may want the permanent copy to stay on the LR TiVo, while that on the bedroom TiVo goes away, automatically and immediately, once the transfer is done.

TiVo multi-room viewing supports neither option.

TiVo MRV does not have a "stream without copying, for viewing only" mode. Possibly this is because many home networks are too slow to make this a viable option.

Nor does TiVo MRV have a "move" mode that allows automatic and immediate deletion of the original recording, once the transfer has been done. And this leads into the next gotcha ...

(3) Copy-protected shows that have been recorded on, say, a bedroom TiVo cannot be transferred in any way to another TiVo. They can't be copied, they can't be streamed, and they can't be moved.

Cable companies use a set of flag bits in a byte called the Copy Control Information, or CCI, to invoke copy protection. This byte is present in all digital broadcasts and cablecasts. Depending on how it is set, it can limit the amount of copying that can be done. You can visit this thread in the TiVo Community Forum to find out more about how CCI, copy protection, and "digital rights management" (DRM) affect TiVo usage. The official TiVo Inc. policy regarding copy protection can be read here.

Basically, if the CCI code represented as hexadecimal 0x02 is set by the cable company, it means "copy once" (or "copy one generation") is technically permissible — as opposed to CCI 0x03, "copy never." "Copy once" should accordingly permit MRV transfers. However, the agreement TiVo Inc. has signed with the cable industry won't let digital recorders transfer CCI 0x02 programs between themselves unless CableLabs, a consortium which represents the cable industry, approves the way the recordings are encrypted while they are being transferred. In the absence of such approval, a company like TiVo Inc. is expected to fall back on not letting such transfers take place at all.

And that's exactly what TiVo Inc. does.

Technically, this restriction applies only to TiVos that have CableCARDs — credit-card sized objects that when inserted in a TiVo Series 3 or TiVo HD allow the TiVo to receive scrambled digital channels. Consequently, shows that are received on analog channels or "clear" (unencrypted) digital channels can always be transferred from one TiVo to another.

CableLabs' "DFAST Technology License Agreement for Unidirectional Digital Cable Products," which sets forth in legalese the copy-protection constraints applying to CableCARD-enabled TiVos, can be accessed by clicking the hotlink above.


So, what programs are copy protected, and what programs are not? First of all, I have found that anything that I receive on premium channels like HBO is protected. Likewise, episodes of many series, such as "The Closer" on TNT (or TNT-HD), that are shown on cable-only digital channels are protected.

On the other hand, anything that is aired on a local digital or high-def TV channel and is retransmitted over cable is, by law, required not to be copy protected. So, for instance, "House" on Fox is always copyable (even in HD!).

Unfortunately, the number of programs that are legally copy protected on cable may be growing. I have found that some series on some cable networks that used to be copyable are no longer copyable. (Of course, the episodes recorded before copy protection went into place are still copyable.)

The use of copy protection may vary from one cable provider (mine is Comcast) to another. It is generally believed by those concerned with the issue — but I can't confirm this — that cable companies have been signing agreements with program providers that require the cable companies to use copy protection on certain shows or certain channels.


Now for some editorializing on my part: I believe TiVo multi-room viewing should be allowed for "copy once" programs.

Specifically, I don't think copying, streaming, or moving copy-protected material from one DVR to another constitutes a basic violation of copyright law. Rather, it qualifies as "fair use" of copyright-protected digital material.

However, a cable-TV program provider (such as a Hollywood studio) who holds a copyright has a legitimate worry: that a show such as "The Closer" could be pirated en route from a "source TiVo," during an MRV transfer, to a receiving device. The digitally transmitted stream could be forced to make a "detour" into someone's personal computer. For example, the PC could conceivably masquerade as a TiVo and receive the digitally transmitted stream from the source TiVo. The received program stream's CCI byte could then be set to 0x00. Then the resulting copy could be distributed over the Internet.

There are at least two ways to guard against such a scenario. One is to insist that a robust scrambling/encryption method be used during a TiVo-to-TiVo transfer. The other is to make sure that the "handshake" between any two TiVos prior to initiating a transfer is sacrosanct and can't be mimicked by another device.

In the present state of affairs, apparently CableLabs is emphasizing the robustness of the encryption method and paying less attention to the sanctity of the handshake. Because TiVo Inc. has not obtained approval of the encryption method used for all files on its TiVo boxes as satisfying the CableLabs requirement that would allow at least a "move" operation for copy-protected shows, MRV is currently being crippled with respect to the fair-use rights of TiVo owners.

If the cable industry would allow "copy once" programs to be moved (or copied, or at least streamed) from one DVR to another solely on the basis that the sacrosanct handshake between the two DVRs is valid, and would waive the requirement that in such a scenario the encryption method used for the transfer must be specifically CableLabs-approved, some progress could be made.

In short, there is room for compromise.

Such a compromise could, and probably should, include establishing an MRV encryption/scrambling method that would be acceptable to the cable industry and to DVR makers. Presumably, such a method would have to be more robust than the simple encryption TiVo uses today for recordings on a TiVo box. Yet it would not necessarily have to be as robust as HDCP, the elaborate method used to encrypt video for transmission over an HDMI cable. The reason: if HDCP were an acceptable option from the point of view of DVR makers, then, since it is already included as part of the CableLabs agreement, TiVos and other DVRs could use it for MRV right now! That they aren't doing so implies that HDCP is too elaborate (and probably too dependent on costly hardware add-ons such as computer chips) to be used in this way.

If DVR makers could formally agree on handshake and encryption requirements, multi-room viewing of "copy once" material could become a reality. What's more, the agreement might enable TiVos to "talk to" other DVRs such as those built into some cable boxes, and to exchange programs with them.

So I say to the respective industries: c'mon guys ... put your heads together and come up with a mutually satisfactory way to let me watch "The Closer," as recorded on my bedroom TiVo, on my living room TV.

LCD Flat Panels: Uneven Backlighting

I have two 1080p flat-panel LCD HDTVs, a new Samsung LN52A650 (52") and a two-year-old Sony Sony KDL-40XBR2 (40"). They both exhibit a problem with uneven backlighting, the Samsung to a very minor degree, the Sony to a more noticeable (but still hard to spot) extent. Research on the web indicates that this and related problems — "cloudy" backlighting, a "flashlight" effect, "leaky" backlighting, "mura" (a Japanese word) — are not uncommon on large 1080p LCD flat-panel HDTVs.

Click here to see an official thread about the clouding/flashlighting problem with the Samsung LNxxA650 model HDTVs. Click here for a similar thread about Sony LCDs.

Here are some pictures showing what the problem can look like when an artificially solid black/dark image (or a "regular" image with a very dark background) is on the screen:


To test your TV: some TVs will give you a solid black screen if tuned to an unused input; or, you can use an appropriate image from a DVD, such as the end credits from many movies.

The number of individual TVs about which forum posters have complained concerning this type of problem is so large, it has to be said that the uneven backlighting problem is not confined to just a few unfortunate set owners. This sort of problem is showing up on a great many high-priced LCD flat panels from Sony and Samsung, and perhaps from other manufacturers as well. For Sony and Samsung, there seem to be similar problems with successive generations of LCD flat-panel HDTVs; for instance, the current Sony KDL-nnXBR4 and XBR5 models seem to be affected, and not just the older XBR2 and XBR3 models. Multiple Samsung models over the last few years are also known to be prone to the problem.

Many buyers have replaced their original LCD sets by exchanging them at the store where they bought them or by taking advantage of the manufacturer's warranty, and found the replacement TVs too often have the same problem, if to a greater or lesser extent.

There is little reliable information on what causes the problem, or what solves the problem.

There is some unscientific, anecdotal evidence that the problem stems from mechanical or heat-induced stresses on the LCD panel itself. (This is the theory I personally subscribe to.) An LCD panel works by using electrical signals to tell molecules in individual pixel-sized locations in the panel to block light from a large fluorescent backlight from passing through the panel and reaching your eyes. Ignoring details concerning how this is done separately for the red, green, and blue components of the color TV picture, the basic idea is that as certain light-blocking molecules (the "liquid crystals") twist and untwist, light from the backlight passes through the panel unobstructed or is blocked to one degree or another. The three-dimensional geometric alignment of all the pixel-sized cells containing the twisty light-blocking molecules has to be absolutely uniform. Otherwise, you get "uneven backlighting" and see "clouds."

If there are uneven mechanical or thermal stresses on the LCD panel, perhaps coming from physical distortions transmitted from the frame of the TV assembly, the panel can warp, dimple, twist, crumple, etc., to a very minute degree. Now the twisty light-blocking molecules aren't squarely in front of the spots of light which they are intended to control. The effect is similar to what happens when you view an LCD flat panel from off-axis and see increased overall brightness and reduced overall contrast. The difference here is that only certain spots on the screen are, in effect, being viewed off-axis, owing to the warping, dimpling, and distorting coming from uneven mechanical or thermal stresses that have been applied to the physical LCD panel.

At least, that is the theory. Giving it some support is the fact that some people have reported being able to reduce the severity of the problem by slightly loosening some or all of the screws holding the TV assembly together, after carefully laying the TV face down on a soft cloth covering a perfectly flat and level floor. (This is a procedure that can cause major problems if botched, and it may void your warranty, so don't try it lightly.) Many who have done this have suggested leaving the TV in this face-down position, powered on so that it stays at normal operating temperature, for hours or days before re-tightening the screws to a lesser degree than they were originally tightened.

Other people have reported that their uneven backlighting problems have gone away or diminished on their own after several weeks or months of TV use, presumably because the cumulative effect of cycles of heating/cooling the TV over and over again has eliminated or minimized the mechanical stresses the TV assembly as a whole puts on the LCD panel it houses. Yet other people report that the problem either appears or disappears (depending on the individual TV) each time the set warms up, after not having been used for a while.

All of these reports tend to confirm that mechanical/thermal stresses on the LCD panel are the prime culprit.


There have been, in addition, reports that the cloudiness/unevenness problems tend to vanish if you simply turn down the LCD backlight — not contrast or brightness, but "backlight" per se — as you can do from the onscreen menu systems of these TVs. Sony, moreover, has apparently issued a firmware upgrade for some of its XBR models that will apparently do this automatically when the scene on the screen is dark. (I have ordered the upgrade but have not tried it yet.)

It stands to reason that reducing the backlight intensity would camouflage the problem, which is basically that too much light is leaking through in certain spots, in dark scenes. Lower the amount of light that the backlight produces, and there is consequently less light to leak through.

As a sheer guess, it may be that keeping the backlight low also generates less heat, reducing thermal stresses on the LCD panel.


So far, there appears to be little hard evidence that these problems derive from poorly manufactured LCD panels per se. I had the panel inside my Sony replaced under warranty, and the new one turned out to be exactly like the original, insofar as this problem was concerned. It looks as if the installation of the new panel inside the TV assembly created the problem all over again. This is more evidence that the problem has to do with mechanical/thermal stresses coming from the TV assembly as a whole.

Some posters to the threads mentioned above have tried to assign blame for the problem to certain ranges of the manufacturers' series of serial numbers, or to certain specific months of manufacture, or to what country the TV was assembled in. I have seen little hard evidence that any of these factors is important.

Nor does there seem to be any correlation between this problem and that of "dead" or "stuck" individual LCD pixels — which are defects in the manufacture of the LCD panels themselves.

It also needs to be noted that this problem is typically hard to spot. Unless you are looking at just the right kind of image on the LCD screen and the "cloudiness" just happens to catch your eye — or possibly you have made a point of trying to find it — you may in fact have the problem and never become aware of it. Some people, once they have discovered it, pretty much dismiss it from their minds as relatively unimportant. Others become semi-obsessed with it. I have personally found that it is better to be in the former group than the latter ...

My New Samsung LN52A650 TV

The LN52A650 is one of Samsung's 2008-model TVs — this one is a 1080p 52" LCD flat panel — that have been improved in several ways over last year's models. I just broke down and got an LN52A650 for my living room, to go where I used to have a rear-projection Samsung 61" DLP HDTV.

I also have a five-year-old 32" non-1080p Hitachi plasma HDTV in my basement and a two-year-old 40" 1080p Sony LCD flat panel in my bedroom. See the posts in my Sony KDL-40XBR2 series for more on the latter. The Sony is an excellent TV — though it has some minor problems with imperfect brightness uniformity across the screen, seemingly due to uneven backlighting — but the new Samsung is even better overall and has no such uniformity issues.

The main reason it beats the Sony: the Samsung has black levels I'd truly describe as "inky." The Sony just can't match them.

The Samsung advertises a dynamic contrast ratio of 50,000:1. (The Sony's is a comparatively paltry 7,000: 1.) That means the brightest white the Samsung can produce is 50,000 times brighter than the inkiest black. Actual video pictures don't need that much contrast, needless to say, but the figure is still meaningful — provided, that is, that the stunningly high contrast ratio is achieved (at least in part) by lowering the level at which black is displayed, not by just upping the level of white. And that's exactly what Samsung has done with the LN52A650.

The 50,000:1 ratio, by the way, isn't the best Samsung has to offer. The best would be the 1,000,000:1 dynamic contrast ratio (!) possessed by a handful of its other models (none of which comes in the 52" size I wanted). That superior ratio is a direct result of backlighting the LCD screen using an array of tiny, individually controllable LEDs, not the uniform fluorescent backlight of the LN52A650. LED backlighting provides a yet further step up in contrast ratio/black level, but at a super-premium price.


You can watch the LN52A650 in a well-lit room and still get a dazzling picture with all those inky blacks, I have found. And not only are the blacks convincing, the portions of the picture that are near-black have excellent definition (fine "shadow detail"). Some HDTVs like my Hitachi tend to "swallow" shadow detail to fool the eye into thinking blacks are being displayed darker than they really are.

Color renditions are superb on the LN52A650, as are the smoothness and naturalness of the brightness gradations between black and white. And I have seen no color banding due to suboptimal internal handling of digital signals — my Hitachi exhibits a lot of banding, my Sony only a little bit.

In fact, the LN52A650 is the first HDTV I've had that gives me a marvelous picture right out of the box, without a lot of fussing and tweaking. I find the "Standard" preset looks just fine to my eyes, though I do turn off "Dynamic Contrast" as providing too much contrast for my taste. There is also, separately, a "Dynamic" preset — too jazzed up to suit me — and a "Movie" preset that I find a little too restrained for daily use.

(Edit: After a couple of days of using the "Standard" preset, I switched to "Movie." The latter gives a less dazzling picture, but one that ultimately seems more realistic. I have found that I like to up the "Gamma" setting from 0 to +3 in "Movie" mode, which brings out yet more shadow detail. Other than that, I have left the "Movie" preset as it comes out of the box.)

Each preset, including "Movie," can have a raft of video (and audio) parameters individually adjusted, if need be, independently for each video input. Or, if you decide you have made things worse and not better, it's easy to reset any preset to its original settings.

There are also separate, non-adjustable "entertainment mode" presets that I haven't tried yet. (Edit: I've tried them now, if briefly, and found them nothing special.)


You can read CNet's full review of the LN52A650 here. All in all, CNet rates the LN52A650 "excellent," giving it four stars out of five.

CNet marks this generally excellent set down for the reddish tint of its bezel, which I find so hard to see as to be a non-factor. They correctly note that (as is the glossy bezel) the front of the screen is shiny, not matte-finished, allowing reflections of brightly lit objects in the room to bounce off the screen or bezel and into the viewer's eye. In my room, that doesn't happen to be much of a problem. (The shiny face of the screen is part of Samsung's strategy to give you deeper blacks and steeper contrast ratios.)

CNet also dislikes the "awkward click wheel remote"; I agree. The wheel spins under your finger and accomplishes what up-down-right-left clicks of the same wheel also accomplish: navigating on-screen menus, lowering or raising volume, etc. But it's unnecessary, clumsy, hard to get used to ... and can't be turned off.

Finally, CNet says there are "some [visible] artifacts when de-judder modes are engaged"; I haven't noticed those.


Another nice thing about the LN52A650 is its combination of a 120-Hz refresh rate with a 4-millisecond response time. Each pixel is refreshed twice as often as with the more customary 60-Hz rate for LCD TVs, and it takes a swift 4 ms for the refreshed pixel to stabilize. My Sony's response time is double that: 8 ms.

The difference in response time and refresh rate can be detected by the eye. Imagine a motionless closeup of a face in repose. Since nothing is in motion, you can see every last nuance of facial detail. Now, say the face starts to move as the camera pans. On my Sony, the details of the facial rendition soften due to "motion blur." Then when the camera stops panning, the details turn crisp again.

This can lead to eye fatigue, since the softening of detail tricks the eye into thinking it has to refocus. Then, when the detail turns crisp again, the eye says, "Whoops! Let's go back to that earlier focus." On the Samsung, the fast response time and the rapid refresh rate eliminate motion blur and eye fatigue.


Also, the colors on the Samsung just seem right — as they do on the Sony, but not on the Hitachi plasma. On the Hitachi, the reds seem orange, and a black-and-white picture can take on a green tinge. (On a color TV, B&W is really the sum of red, green, and blue signals. If the TV messes up the computation, a "colorless" picture can wind up with a tint.)

To be fair, plasmas and LCD flat panels have come a long way since the Hitachi was made, and it would be a mistake to downrate plasmas based on what is now a Stone Age model.

The Samsung produces sound through its internal speakers that my not-so-wonderful ears can make good sense of, in terms of comprehending dialogue. Neither the Sony nor the Hitachi render dialogue as well. Music on the Samsung sounds great as well.

The December 2008 issue of Consumer Reports gives the Samsung LN52A650 the highest rating of all the LCD and plasma HDTVs of various sizes that it tested (though no LED-backlit LCDs were among them).


The Samsung LN52A650 is priced in the mid-to-upper tier of 52" LCDs. You can pay a lot less for an LCD with the same screen size (or you can pay more if you want more bells and whistles).

There are, I'd say, three tiers of HDTV buyers. The top tier will spare no expense to get the absolute best, and will undoubtedly prefer an LED-backlit LCD, when one becomes available in their preferred screen size, or one of the top plasmas, which sometimes produce even inkier blacks than the LN52A650. Better still, for some buyers, are the front-projection TVs that fill huge screens in home theaters with to-die-for images.

The bottom tier of HDTV buyers want the lowest price, or close to it, on any given screen size. They are willing to sacrifice performance for economy — and who can blame them, since even the cheapest flat panel today gives a picture far superior to anything that was available just a few years ago?

Then there's the middle tier, in which I proudly place myself. I and those like me will pay extra for noticeably better performance and features ... but we don't absolutely have to have the state of the art in a TV set.

In which tier would you place yourself? If you, too, are in the middle tier, and if you want a 52" flat panel HDTV, you would do well to look into the Samsung LN52A650.

HD TV Shows at iTunes Store

With the recent release of iTunes 8.0, Steve Jobs and company at Apple has also made available, for customers at Apple's iTunes Store, TV shows in high-definition for the first time.

HD episodes of Ugly Betty, Desperate Housewives, The Office, 30 Rock, Monk, Lost, and many other hit series can be purchased for $2.99, $1.00 more than the standard-def versions.

When you click on a "Buy Episode" button in iTunes, if the episode is HD, what you are supposed to be buying and downloading is actually two versions of the show, one HD and the other SD.

I find that there is a bug in Apple's implementation, however. If you use a Shopping Cart at the iTunes Store, rather than 1-Click Shopping, you can't get the HD shows. In my tests, you only get the SD version placed in your cart, not the HD. Then when you click on "Buy Now," the SD version only is downloaded.

Other people have reported online that they don't even get the SD version, just an indication that the show is mysteriously "unavailable."

The solution is to go into iTunes Preferences, under "Store," and click "Buy and download using 1-Click." That deselects "Buy using a Shopping Cart." (Make sure you have emptied your cart before doing this.) Now when you click a "Buy Episode" button, you will get an iTunes dialog asking you to confirm your purchase (unless you have previously told iTunes to disable this message). Once you authorize the purchase, the download will begin immediately of the two versions of the show.

iTunes 8.0 will then have both versions in its library. You can play either one, either in iTunes 8.0 or in QuickTime Player 7.5.5 (which, if you don't already have it, you need to get).

The HD version of the first episode of Monk, Season 7, "Mr. Monk Buys a House," is currently a freebie. It plays with a resolution of 1280 x 720 pixels with a total bit rate of 4541 kbps. (QT Player shows the data rate as being a bit lower: 4107.45 kbits/s.) This is true 720p resolution.

QT Player's numbers for the SD version are 853 x 480 non-square pixels in a 720 x 480 frame, at 1624.86 kbits/s. The SD file for this close-to-one-hour show takes up 509.8 MB, while the HD version uses 1.37 GB — nearly three times the storage.

The HD version plays just fine on my Apple TV, either when synced or streamed, with full resolution that is visibly better than that of the SD version.

Despite what I seem to have read online, it does not appear that iTunes 8.0 is smart enough, if you inadvertently try to sync an HD show to your iPod Touch, to substitute the SD equivalent. Instead, you have to manually arrange to sync the SD version. (I sync TV Shows using a selected playlist; syncing TV Shows by show rather that playlist, however, does not get around this problem.)

This shortfall, though minor, points up the inherent problem with the way Apple is implementing HD. It looks to me as if the only reason to bundle an SD version with an HD show is for the benefit of the iPod. (Maybe some older Macs than my MacBook Pro running Mac OS X 10.5.4 will, like an iPod, refuse to play HD, but I don't know this for a fact.)

If the iPod Touch (or iPhone) could just be updated so that it would play HD versions, downrezzing them as necessary for the coarser screen, Apple could omit the SD version entirely — saving about 20 percent on download time and storage requirements, plus obviating the iTunes Store bug that causes problems when using the Shopping Cart.

Coming alongside the iTunes and QuickTime upgrades was an upgrade (version 2.1) to my iPod Touch software. As part of the upgrade, there was a concurrent upgrade to the iPod's firmware. I wasn't aware that iPods have upgradeable firmware, but since they do, I have to wonder whether they could be made compatible with HD video.

HD video as implemented at the iTunes Store has higher bitrates than the iPod can nominally keep up with, and probably uses B-frames ("bidirectional video frames") to slim down storage requirements. But if the iPod's bitrate limit and allergy to B-frames could be overcome, voila: (albeit downrezzed) HD video!

I can pretty much guarantee that future iPods/iPhones will have it. Is there any hope for current 'Pods?

iPod Touch: How to Set Up a Random Album Playlist

This isn't about video or HDTV, but it is about my new iPod Touch, which I've been talking about in several recent posts.

Because it only has 8 GB of flash memory, most of which is devoted to videos, I'd like to find a way to set up a smart playlist in iTunes that will allow me to select, say, a random 2 gigabytes worth of music to sync to it as a playlist. Here's the catch. I want not randomly selected songs, but randomly selected whole albums.

A post by "Myra" about halfway down in this forum thread shows how.

The key thing is to checkmark Shuffle By Albums (rather then By Songs or By Groupings) in the iTunes Controls menu. (In pre-8.0 iTunes, go to iTunes Preferences and, under Playback, select Albums rather than Songs or Groupings at the bottom of the pane, and click OK.)

Then set up a smart playlist (I call mine "iPod Random Album") and set it up this way:

• I enter "Limit to 2 GB selected by random" and checkmark it
  
• I checkmark "Live updating"
  

When I click OK, the playlist fills in with 2 GB worth of randomly selected whole albums!

If I delete an entire album from the playlist, a new album, randomly selected, magically replaces it.

If I delete everything in the playlist, it magically fills in with an entirely new random selection of albums.

If I want, I can add various selection-limiting rules. For instance, right now I'm limiting the albums on the iPod to those in a certain other playlist of mine called "Elaine." To do that, I just use the rule "Playlist is Elaine."

The rule "Last played is before {enter a date two days ago}" will keep the list fresh.

If you object to shuffling albums rather than songs, you can revert to Shuffle: Songs in iTunes Preferences: Playback after making the playlist. Just remember to return to Shuffle: Albums each time you want to refresh the playlist.

Hooking iPod Touch to an HDTV

Apple's iPod Touch is sort of a jack-of-all-trades. Not only will it play music and videos for your eyes (and ears) only, in the standard video iPod way. It will also connect to your HDTV and play media for all to see and hear.

The secret to this is to get either an Apple Composite AV Cable ($49) ...










... or an Apple Component AV Cable ($49).











They both come with not only a means to connect your iPod Touch to a TV, but also a USB power adapter to hook it to electrical power. (This, along with virtually everything else I say in this post, applies equally to an iPhone as to an iPod Touch, by the way.) You just connect either version of AV cable to the 30-pin dock connector on the iPod's bottom edge, plug the AV cable's video and audio connectors into an appropriate input on your TV, and plug the USB connector on the AV cable into the USB adapter, which plugs into a wall outlet.

The audio connectors on both AV cables are the same: the typical red and white stereo audio RCA plugs. They go into, respectively, a pair of right and left audio-in RCA jacks on your TV.

The video connectors differ with the type of AV cable you get. If you get an Apple Composite AV Cable (which is what I have) you plug a single yellow-identified "composite" video RCA plug into a like jack on the TV. If you get the Apple Component AV Cable, you insert RCA plugs coded red, green, and blue into the appropriate "component" or "YPbPr" video inputs on your TV.

I recommend also getting the Apple Universal Dock ($49) to go with your setup. It lets you hook the 30-pin connector on the AV cable to it permanently. Then when you want to use the iPod Touch with the TV, you just stick the iPod in the dock, turn on the TV, and make sure the TV is set to use the correct input for the iPod.

The dock even comes with an Apple Remote that you can use from your easy chair to pause playback, skip to the next song or chapter, etc.



A very nice thing about using the iPod-to-TV connection to play videos, which is its main purpose, is that it does a pretty darn good job of it.

True, the resolution is only 480i. This is not high-definition video. An Apple TV can give you up to 1280 x 720 pixels of resolution, progressively scanned at 24 frames per second. Not so, the iPod Touch. A video file with that kind of HD resolution won't play on an iPod, period. Files that play on an iPod will have lower resolution in both the horizontal direction (the first number) and the vertical direction (the second number).

The second number (vertical resolution) will typically be 480 pixels, at most. For widescreen movies that play with black letterboxing bars at the top and bottom of the screen, this number is reduced appropriately.

The first number (horizontal resolution) can be at most 720 pixels, I believe. (Actually, though, because some videos are "anamorphically encoded," somewhat more than 720 pixels can be horizontally squeezed into the width of a nominally 720 x 480 video frame.)

The TV playback from an iPod touch iPhone will use "interlaced" fields, not "progressively scanned" frames, according to a footnote in this informative support document from Apple. Thus, it is 480i, not 480p, video playback that you will see on your HDTV screen.

Your HDTV will, however, "deinterlace" this 480i signal to give you a seemingly "progressive" viewing experience, ideally with no visible "scan lines" or jagged, vibrating edges on objects. How close to this ideal your experience will be depends in part on how well your HDTV does deinterlacing and in part on how "clean" your source video is, in terms of its encoding.


A nice thing about video playback on an HDTV from an iPod touch, at least in my opinion, is that the proper picture geometry is always preserved. For example, if the original video uses the old-style 4:3 aspect ratio, that's what you'll see on the TV screen. The 4:3 video frame will be "pillarboxed": flanked by thick vertical black bars on a 16:9 HDTV. (For this to be so, you'll need to make sure that "Widescreen" is selected under Video Preferences on the iPod.)

Or, if the original video has an aspect ratio greater than the HDTV's nominal 16:9, the iPod Touch will give you black letterboxing bars at the top and bottom of the screen.

Of course, if the original video has exactly 16:9 as its aspect ratio, you'll see neither letterboxing bars nor pillarboxing bars, and every pixel on the HDTV screen will be lit.

There are many people, though, who disagree with me on this — they want to see every HDTV screen pixel lit, no matter what the aspect ratio of the original video is. If the original ratio is not 16:9, they would like the image to be stretched either vertically or horizontally, as needed, to fill the screen. That this produces incorrect picture geometry — people who are too tall and skinny, or too short and fat — doesn't bother this type of viewer.

Since the iPod Touch introduces black bars whenever needed to preserve correct picture geometry, this type of viewer might not be happy.


The iPod Touch/TV combination has a few drawbacks, too. One is that you have to summon up the video, music album, playlist, etc. that you want to play from the touchscreen of the iPod itself, which at the time already has to be connected to the 30-pin connector of the AV cable (or to the dock). There is no way, even using the Apple Remote, to select items to play back from the TV screen itself. Plus, if you remove the iPod from the dock to locate your media files and initiate play, when you put it back in the dock, you'll just have to start things all over again.

Another drawback is that when you're playing music, you don't see the title, album art, etc. on the TV screen, as you would if you were using an Apple TV ... just a black screen.

The iPod-to-TV connection is not nearly as sophisticated as an Apple TV. The contents of the iPod screen are not sent to the TV, ever. That means you can't use the TV screen as an enlargement of the iPod screen, nor (as already mentioned) can you use the buttons on the remote to navigate to buttons and hotlinks on the iPod and select stuff. The remote won't do anything at all until you're actually playing something.

When you do play something, you will see its album art and identifying and control information on the iPod screen ... a nice touch, but it's not a lot of use to you from a distant easy chair.


Apple needs to rethink the user interface for the iPod-to-TV connection bigtime, in my humble opinion. My first inclination is to think that there's no reason why Apple shouldn't make the iPod Touch do everything an Apple TV does.

The Apple TV syncs automatically and wirelessly to your iTunes library. To sync the iPod Touch you have to connect it to the Mac running iTunes — even though the iPod Touch does connect wirelessly to your home network.

The Apple TV wirelessly streams video and music from iTunes — multiple iTunes libraries, not just the one used for syncing. To do the same with iPod Touch, you have to get geeky: see iPhone Remote Software Streams Media to iPhone/iPod!. Even then, the user interface that you have to put up with is worse-than-primitive by Apple TV standards. For example, when you are streaming a video into your HDTV via an iPod Touch, the chapter-advance function on the Apple Remote doesn't work. Instead of zipping to the start of the next chapter, it terminates the QuickTime playback of the video. Not wonderful.

The Apple TV does YouTube. So does the iPod Touch — but not using its iPod-to-HDTV interface.


The list goes on of things an Apple TV does that an iPod Touch, hooked to an HDTV, ought to emulate. When you think about it, there are only a few things an Apple TV can do that Steve Jobs and Company can be forgiven for not putting in the iPod Touch.

The Apple TV has a 40 GB or 160 GB hard drive to store synced material, while the iPod Touch uses a lesser amount of flash memory, 8 GB, 16 GB, or 32 GB. Clearly, you won't be able to sync as much stuff with an iPod Touch as with Apple TV.

The iPod Touch has to limit the amount of power it consumes so as to provide reasonable battery life and not generate too much heat. I imagine the reason that it limits video resolutions and bitrates and won't support videos using space-saving "B-frames" (bidirectional frames) has to do with this understandable design constraint. This is why Apple TV can play certain videos that iPod Touch can't.

Still and all, once you have your video library converted for use with an iPod Touch (or iPhone), those same videos play back on an Apple TV with all the resolution and quality they are capable of providing, given their iPod-specific limitations. It would be nice if the iPod Touch could likewise output them at resolutions higher than 480i, at least when using the Apple Component AV Cable.

Now, it may be that the chipsets necessary to make that happen are just too big, or run too hot, or gobble up too much power, or add too much to the cost of the iPod Touch to be economically feasible. Even so, I would sure like to see such a hi-def output capability, via component video if not HDMI, built into a future iPod Touch.

iPhone Remote Software Streams Media to iPhone/iPod!

Good news! You can now get media files such as movies, music, and photos to stream from your computer to your iPhone/iPod Touch using a software package called iPhone Remote. I have a new iPod Touch, or iTouch for short, so I'll talk specifically about it, but what I say below applies equally to the iPhone.

If you have one of these units, you know that iTunes syncs media files in your iTunes library to it. Every media file that you sync to your unit gets copied to its internal memory. Mine has 8 gigabytes, which gets used up pretty fast. About 500 songs plus 2 movies plus 3 TV shows will fill up the entire 8 gigs.

Meanwhile, I have about 120 movies in my library. I've quickly gotten tired of syncing the 1 or 2 movies I want to watch next. Isn't there a way, I wondered, to stream movies to the iTouch?

This YouTube movie clued me in:



If you watch it carefully a couple of times, you may glean all the information you need to get iPhone Remote working for you. But if you want more detail, read on.


The first 6 steps in the movie are pretty much optional. They concern making it possible for iPhone Remote to stream media to your iTouch when you're out of range of your own home wireless network, by setting up a dynamic host name on the Web that will always, when used as part or a Web address or URL, access your Mac remotely.

Step 1 creates a free user account at dyndns.com. During that step, you set up a user name and password to protect the account. Step 2 then sets up a dynamic DNS host name within that account. The purpose of these two steps has to do with giving a permanent Web-accessible host name to your wireless router's IP address.

For example, I am using dalekhound.webhop.biz as my host name. You can't click on it or type it into a browser to link to it directly, since I don't have it set up for that. What it does is serve as a proxy for the IP address of my home router, which is (slightly scrambled) 69.251.77.501.

So when I go into Safari (this works best with Safari, not with my usual browser, Firefox) and go to the URL https://dalekhound.webhop.biz:5010/, what I see (after authenticating my identity) is:


This is the browser interface put up by iPhone Remote. It is intended for the iPhone or iPod Touch, but I can look at it in Safari on my Mac.

(To actually get this far, I need to go through an authentication phase in which I first choose to continue despite an "invalid" security certificate for my pseudo-website, and then I log in with my username and password. This is the username and password I created when I installed iPhone Remote.)

DNS, by the way, stands for Domain Name System, the system by which a domain name such as .biz can be qualified to become .webhop.biz and further qualified to become the host name dalekhound.webhop.biz. When DNS is dynamic, the Internet Protocol address of the router associated with my host name can change. My Internet provider periodically changes the IP address of my router: 69.251.77.501 becomes, say, 69.251.77.502. With dynamic DNS, the change is transparent when I use host name dalekhound.webhop.biz.


Steps 3 and 4 in the movie also have to do with dynamic DNS setup. Something has to tell dyndns.com that my router's IP address has changed, whenever that happens behind my back. The DynDNS Updater, a piece of free software you can download from dyndns.com, sets up a "daemon" that sits in my Mac system and monitors my router's IP address. When that IP address changes, the DynDNS Updater daemon automatically updates my account at dyndns.com.

Step 3 in the movie has you download and install the DynDNS Updater. Once that is done, Step 4 configures it. You tell it your dyndns.com user name and password at this stage ... which may or may not be different from the user name and password you're going to use with iPhone Remote later on. DynDNS Updater then retrieves your account information and host name from dyndns.com. (I'm not quite sure why the movie shows the host name being manually entered in DynDNS Updater, since mine appeared automatically under User when I first fired up DynDNS Updater.)

You also want to make sure the preference is set in DynDNS Updater Preferences to automatically fire the daemon up each time you reboot your Mac.


Things get a bit trickier in Step 5: you need to forward your router's ports 5010 and 5012 to your Mac.

DynDNS Updater uses two software "ports" in your router. One becomes its "server port" and the other is its "media port." You can see this in the iPhone Remote Preferences window, once you have downloaded and installed iPhone Remote in Step 7 below:


Notice that you have to turn on the "Share media insecurely" option in order to allow your videos and music files to be played on an iPhone or iPod touch. Anyone who knows the full path name to a media file of yours (and also can authenticate with your username and password) can play your videos and music on his iPhone or iTouch.

Back to the idea of "ports": your router has to be set up to "forward" ports 5010 and 5012 to the Mac which hosts the media files you want to play on your iPhone/iTouch. In my case the Mac in question has been given the statically assigned IP address 10.0.1.202, so I have to go into AirPort Utility and do some Port Mapping on my AirPort Base Station:


The two entries in question are the two at the bottom: 5010 -> 10.0.1.202:5010 and 5012 -> 10.0.1.202:5012. You have to add those to get iPhone Remote to work.

In the movie, a Step 5 procedure for a different type of router is shown. If you have an AirPort Base Station, you should ignore it.

Also ignore Step 6, which wants you to enable dynamic DNS on your router. I'm not quite sure what this step does, but it's not applicable on an AirPort Base Station. I suspect it is yet another way to notify dyndns.com when the router's IP address changes.


Step 7, the next step in the movie, is a crucial one. You need to download iPhone Remote at http://code.google.com/p/telekinesis/ and install it on your Mac. (Note that nothing at all gets installed on the iPhone or iPod Touch. You are not using unauthorized software or "jailbreaking" your unit.)

This is the time that you actually configure iPhone Remote's preferences, including setting up or changing the user name and password you'll be using on your iPhone/iTouch when you want to play a movie or a music file. To do this, you click on "Change Password" in the Preferences window:


Then you simply enter a Web Username and Web Password. Then you dismiss the dialog by clicking Save and in the window above click Restart Server.

This is also the time you make sure your server and media ports have the right numbers, 5010 and 5012, respectively, and that you checkmark the "Share media insecurely" option.

Once you've done that, you can close the Preferences window.


That's basically it! You're ready to start using iPhone Remote from Safari on your iPhone or iPod Touch.

Make sure that iPhone Remote is still running. You can leave the Preferences window open if it makes you feel better ... but as long as iPhone Remote is running, you're fine. Now enter your dyndns.com host name, followed by :5010, into Safari's address line on your iPhone/iTouch. In my case, I enter dalekhound.webhop.biz:5010.

If you get a message about an unknown security certificate at this point, touch Continue. Enter your iPhone Remote user name and password when prompted. You'll see a miniature version of:


and when you touch the Files button, you'll see a list of files and folders at your user folder level on your Mac. From there you can navigate either down the folder hierarchy or (by touching the active hot links in the blue bar toward the top of the the screen) back upward to your hard drive level or to the level of your computer as a whole. Hence, you can navigate to any movie or music file on your computer that will play on your iPhone/iTouch and, by touching its name, play it in QuickTime on the iPhone/iTouch!

Videos for iPod Touch, Part 2

In Videos for iPod Touch, I talked about my sleek-looking new iPod Touch 8G:

No, I said, it's not an iPhone, but iPhones are wait-listed right now.

The iPod Touch shares with the iPhone the ability to sync with iTunes and play video movies and TV shows, music, podcasts, etc. But not all videos that iTunes (or my Apple TV) will play can go onto the iPod — even though the offending videos are nominally in the MPEG-4/h.264 format that the iPod expects. I expect other iPod owners have the same kinds of problem. This post is about ways around the problems.


There are actually two kinds of problem here:

1. If a video has been encoded with a video bitrate of over 1500 kbps, the iPod won't sync to it or play it.
2. The iPod can't sync to or play videos that have been encoded with B-frames, space saving representations of individual video frames that record differences between themselves and following frames (and from preceding frames, but that's not a problem).

The iPod simply doesn't have enough memory or processing power to cope with high-bitrate videos or with deriving current frames from following frames in the video stream.

One solution to either incompatibility problem is to re-rip the video from an original DVD. I use HandBrake to port videos from DVD to iTunes. HandBrake 0.9.2 (the current version) has several presets for iPod-compatible rips. The one which I use a slightly modified version of is "iPod High-Rez." Any of the iPod-related presets will work, in that they carefully avoid giving you B-frames and video bitrates in excess of 1500 kbps. (They also insert the mysterious "iPod atom," making the output compatible with pre-Touch video iPods.)

However, I recommend that you modify the preset, as I did, to turn on Anamorphic: Strict under Picture Settings. This allows your output file to use "anamorphic encoding" if the DVD itself does. For more on what that means, see below.


The second workaround for getting a non-iPod-playable video to play on an iPod is to do a conversion of an existing rip into a form that works with iPod.

The simplest way to do a conversion is to select the movie or TV show in iTunes and select "Convert Selection for iPod/iPhone" in the Advanced menu. iTunes will verify that the video is not already iPod-playable, and if not it will start to convert it to an iPod-usable format — a lengthy process. The output file automatically goes into ~/Music/iTunes/iTunes Music/Movies (or ~/Music/iTunes/iTunes Music/TV Shows). The file name is the same as that of the original file, modified as necessary to ensure uniqueness. The original file is left untouched.

Using iTunes to do the conversion has several drawbacks:

• The process is super-slow. It takes iTunes much longer to convert a file than it would take HandBrake to re-rip it.
  
• You can't direct the output to any folder or hard drive you want. You have to be content with iTunes' default folder.
• You can't name the converted output file anything other than iTunes' automatic choice of file name.
• You can't control parameters like the resolution in pixels of the video frame. In my admittedly limited experience, iTunes seemingly insists on giving the output video file a frame width of 640 pixels, with a corresponding pixel height designed to reproduce the original's aspect ratio.
  

The second way to do a conversion is to use QuickTime Player. That allows you more control over such things as the destination drive and folder, the output file name, the video resolution, and other useful parameters. But, like iTunes itself, QuickTime is slow, slow, slow.

I'm currently investigating a third alternative: using a third-party video converter.

I'm presently trying the $29 ImTOO iPod Video Converter for Mac:




ImTOO's website says it "can convert video and audio files such as AVI, MPEG, WMV, DivX, MP4, MOV, XviD, VOB (the video format used in DVD), MP3, AAC, AC3, etc., to iPod supported formats, including MP4, MOV, MP3, and M4A."

I have just begun to experiment with ImTOO, and I find it pretty much works as advertised. And it's fast ... as long as it isn't butting heads with a HandBrake DVD rip, in which case it slows down to a crawl in favor of HandBrake.

Still, I have found at least two of my HandBrake rips that ImTOO's conversion attempts stall out on. At least using the settings I have tried, ImTOO gets to a certain point in the conversion and then just sits there ... forever.

One drawback with ImTOO is that MPEG-4/h.264 conversions for iPod are automatically given the .mp4 file extension, which means they automatically open in QuickTime Player, when double-clicked in the Finder. The .m4v extension, allowing automatic opening in iTunes, would be better.

A second drawback with ImTOO is that if your original file was created by HandBrake with chapter stops/names, ImTOO won't carry them over to the converted file. Bummer.

Another ImTOO drawback, one that applies to other third-party converters I've tried as well, is pretty technical, so bear with me as I try to describe it. I'm going to present this somewhat technical discussion in blue, in case you want to skip it. I'll also indent it.

I have an existing rip of Harry Potter and the Prisoner of Azkaban that HandBrake made some time ago. Its video frame dimensions (per iTunes' Get Info Summary) are 853x360 pixels. This means that if I play the video in iTunes or in QuickTime Player, I'll see it in a frame that is 853 pixels wide by 360 pixels high. 853:360 corresponds to the aspect ratio of the Potter movie on DVD.

Yet if I play the video in QuickTime Player, the player's Inspector window says (under "Format") that the video frame is only 720x360! What accounts for the discrepancy between 853 and 720? And why is the default-size QuickTime viewer window actually 853 pixels wide, not 720?

The solution to this mystery is that the HandBrake output simply reproduces the 720 pixels that are physically present in each row of each video frame on the DVD. But HandBrake also detects that the widescreen DVD was "anamorphically encoded" — formatted especially for widescreen TVs — such that the DVD player stretches the 720 pixels provided per row into the space of 853 pixels, thereby widening the frame as it is being viewed.

Handbrake also detects that the nominal 480 rows of pixels in each video frame on the DVD is actually only 360 useful rows. The remaining rows at top and bottom of the screen are not even coded; they are played as black letterboxing bars. Since they're not coded on the DVD, they don't need explicit coding in HandBrake's output, either. So HandBrake outputs an MPEG-4/h.264 file that has video frames of 720x360 pixels. These 720x360-pixel frames are intended to be displayed as if each frame had 853x360 as its true dimensions.

(For a clear discussion of anamorphic encoding in general and how HandBrake deals with it, see "Guide to Anamorphic Encoding in HandBrake.")

In other words, the HandBrake output is anamorphically encoded, just like the input from the DVD. Anamorphic encoding simply means that (in this particular case) a 720x360 pixel grid is stretched at time of playback to fill an 853x360 frame.

Yet when ImTOO converts the anamorphically encoded HandBrake-ripped video, it doesn't retain the anamorphic encoding. Instead, when ImTOO is set up to use an output video size of 853x360, it internally expands the 720x360 pixels in each input frame to fit into an 853x360 box and then uses that box to derive a non-anamorphic 853x360 output file.

(Actually, the ImTOO conversion fails unless the output video size is trimmed by a single pixel to 852x360! Apparently the two numbers surrounding the "x" have to be even.)

I have found that the only way to keep the original aspect ratio and also retain all the input file's video detail is to enter iTunes' video dimensions for the input file into ImTOO's Video Size field in the "Advance" settings. In the example of Harry Potter and the Prisoner of Azkaban, that's 853x360 — trimmed to 852x360 — not the unstretched 720x360 shown in QuickTime's Inspector window. Setting the ImTOO video size to 852x360 seems to be the only way to preserve the aspect ratio of the original video frame, for this particular movie.

When ImTOO is set up to retain all the detail in the original video file and preserve the same aspect ratio, it uses more pixels in the video frame, hence contains more bits in the output file, than it really needs to. This is because ImTOO can't produce an anamorphically encoded output file even when the input file is anamorphic. So its output, in this example, has video frames whose dimensions in pixels are 852 horizontally by 360 vertically.

Unfortunately, all that careful manipulation of ImTOO's conversion parameters results in an output file from ImTOO that iTunes won't sync to the iPod Touch! The output file plays in iTunes, on Apple TV, and in QuickTime Player ... but won't work with the iTouch. My guess is that the 852x360 video frame contains too many pixels to be iPod-acceptable.

A workaround to that problem might be to use, say, 720x304 as the output frame size in ImTOO. 720:304 is basically the same aspect ratio as 852:360. When ImTOO uses a video size of 720x304 for this movie's conversion, the output file syncs to the iPod just fine.

Trouble is, there are now only 304 pixels of vertical resolution in the picture, not 360 pixels vertically. The difference is not noticeable on the iPod, whose screen resolution is only 480x320 anyway. But the video looks much softer on my Apple TV-fed HDTV.

Yet I have found that this strategy of reducing the vertical resolution to preserve the aspect ratio is what at least one other converter I've tried, TechSpansion's VisualHub, does by default when converting videos for the iPod Touch. It is a sensible choice, given that VisualHub, like ImTOO, cannot retain anamorphic encoding.

In fact — please note this well — the only reason I have any objection at all to this conversion strategy used by ImTOO and VisualHub is that I prefer to end up with a single video file that has all the resolution of the original DVD and plays on Apple TV as well as on iPod.

Yet the only way I have found to do this is to use anamorphic encoding that is honored by iTunes, Apple TV, and iPod ... and none of the converters I've tried so far can do that. HandBrake alone seems to be able to produce anamorphically encoded output that works with all my software and all my devices. That is why I plan to re-rip all my existing iPod-incompatible DVD rips with HandBrake, rather than converting the existing rips with ImTOO or VisualHub.

Note: ImTOO has in its advanced options, in addition to the Video Size parameter, an Aspect parameter. If I set the former to 720x360 for the Potter movie and the latter to 2.37 (852 ÷ 360), I get output that mimics the input when played in QuickTime Player. That is, it shows as 720x360 under Format in the Inspector window, while actually playing as 852x360. Thus, it would seem to be anamorphically encoded. However, neither iTunes nor the iPod will play it at 852x360, only at 720x360, which gives the wrong aspect ratio and distorted image geometry. I have no idea why iTunes/iPod honor the anamorphic nature of the HandBrake-ripped file but not of the ImTOO-converted file.

OK, that's the end of the admittedly technical discussion about various iPod video converters' lack of support for "anamorphic encoding" that works in all my software and in all my devices. There is, however, an important lesson to be learned from that discussion, one that all iPod Touch owners need to hear. It is this: contrary to what you may have heard elsewhere, the iPod Touch (and presumably the iPhone) can play videos that have more pixels in the video frame than the nominal 480x320 screen resolution of the playback device, the iTouch or iPhone, can display!

iPod Touch videos can have more than 640 pixels in their video frame width, which I previously thought to be the maximum number of bits allowed! I don't know what the true upper limit is as yet, but it's at least 720 pixels of horizontal resolution! (There may also be an upper limit, at present unknown, on the product of the horizontal resolution in pixels and the vertical resolution in pixels.)

Of course, you'll see at best only 480x320 resolution on the iPod itself. But the same file can be played on, say, Apple TV with full resolution. Cool!

Videos for iPod Touch

My new iPod Touch 8G (for 8 gigabytes of storage) is a $299 marvel. Sleek-looking, too:

No, it's not an iPhone, but iPhones are wait-listed right now.

The iPod Touch shares with the similar iPhone the ability to sync with iTunes and play videos, music, podcasts, etc. The videos can be movies or TV shows downloaded from the iTunes store. Or they can be videos you yourself have created, including those you have ripped from your collection of DVDs (see earlier posts in my Ripping DVDs series for more on that).

I have an extensive library of movies (and TV shows) that I have ripped from DVDs, usually using HandBrake. They were converted by HandBrake from the MPEG-2 format used on DVDs into the MPEG-4/h.264 format, the increasingly common format used in Apple products: iTunes, Apple TV, and the iPhone and video iPods, including the iPod Touch.

Only problem is, some of my MPEG-4/h.264 videos which play fine in iTunes and on my Apple TV can't be copied to my iPod Touch. When I try to sync them, I get an error dialog such as this one:

Some of the videos in your iTunes library, including the video "Notorious", were not copied to the iPod "Eric's iPod Touch 8G" because they cannot be played on this iPod.

Expanding the dialog box reveals:

"Notorious" was not copied because the video format is not supported by the iPod "Eric's iPod Touch 8G".

I have learned that there are three usual suspects:

1. The video file does not contain an "iPod atom."
2. The video file was encoded with "B-frames."
   
3. The video file has too high a video bitrate, over 1500 Kbps.
   

Of course, if any of the videos are not shown in iTunes' Get Info Summary panel as being of kind: (Protected, or not) MPEG-4 video file using video codec: H.264 with profile: Low Complexity, then that would be yet another problem entirely. Other formats/codecs/profiles are not iPod-playable.

Whether or not an MPEG-4 video file is "Protected" — copy protected, that is, per the iTunes Store's Digital Rights Management protocols — makes no actual difference to iPod playability. The files your get from the iTunes store will be protected, of course, but they'll work fine on an iPod Touch. The files you rip from DVDs will not be copy protected at all. But to also work fine on iPod Touch, a video file you make yourself must be MPEG-4/h.264/Low Complexity, and it must adhere to certain extra rules.

HandBrake knows about all these rules, and if you use one of HandBrake's built-in iPod presets — I recommend "iPod High-Rez" — you'll always get an output file that is iTouch-compatible.

But several of my "legacy" rips aren't iTouch-compatible, as it turns out. Some of them were ripped by an earlier version of HandBrake (the current version is 0.9.2) that didn't always make iPod-compatible output files. At that time, I had no idea about any restrictions on iPod compatibility, and didn't really care. I was primarily interested in getting the best possible results for my Apple TV. Now, I wish I had had more foresight.

Anyway, here is more about the three usual suspects:

1. What is the mysterious "iPod atom"? It is apparently nothing more than a sequence of bytes that starts with the four hexadecimal characters 'uuid' followed by the parameter '1200', also in hex. This goes into the so-called "MPEG-4 file container" as "metadata." It magically allows iTunes to sync the video to certain picky early video iPod models (but not the iPod Touch or iPhone, which ignores the "iPod atom").

For early video iPod owners: if a video file's only flaw is the lack of an iPod atom, I am given to understand that AtomicParsley can help. According to this discussion, one can download and install a certain special version of AtomicParsley and then use the following command line in Terminal to insert an iPod atom in any MPEG-4 video file:

AtomicParsley OUTPUT.mp4 --DeepScan --iPod-uuid 1200 --overWrite

where OUTPUT.mp4 represents the name of the video file. You need to change OUTPUT.mp4 to the name of the MPEG-4 file you wish to modify. It's best to copy the original file and work only with the copy. (I assume the extension .m4v, where applicable, works also.)

I tried this with the 0.9.0 version of AtomicParsley, which is the only one I could actually find on the Internet. It simply did not work at all as an inserter of iPod atoms. Then I read the discussion referenced above a bit more closely and learned that I really need a certain "subversion" of AtomicParsley that does support this procedure. Unfortunately, I could not locate that subversion.

However, I am also led to believe that the "iPod atom" is needed only for the so-called 5th-generation and 6th-generation video iPods, the ones with the truly tiny video screens, that came along prior to the iPod Touch and the iPhone. The iTouch and iPhone don't care about the presence or absence of the "iPod atom," one way or the other.

2. MPEG-4 videos can optionally use so-called "B-frames." When they do, no iPod model to date can play them.

B-frames are "bidirectional," in that they are streamlined video frames that represent only the video information that has changed in that particular frame, compared to a prior video frame or a following video frame. B-frames make for smaller MPEG-4 files, because the ability to key off a later frame, not just an earlier one, can result in there being far fewer bits in the file.

Forcing the MPEG decoder to scan ahead to look at following frames, though, is not supported for iPods. It requires too much memory and too much processing overhead. However, iTunes can do it; so can the Apple TV.

If you rip a DVD especially for Apple TV in HandBrake, HandBrake will use B-frames ... and the resulting output file won't play on an iPod, no matter what you do.

3. Every MPEG-4 file has a certain "total bitrate." If you look at iTunes' Get Info Summary for the file, you'll see both a bitrate (such as 159 kbps) and a total bitrate (such as 1657 kbps). The first is how many bits (or thousands of bits) per second are used for the audio. The latter is how many are used for the video and audio, together. If you subtract the former from the latter you'll get the video bitrate, in this case, 1498 kbps. It has to be 1500 or less to work on an iPod.

(Actually, I seem to have some files where the crucial figure is just a little over 1500 kbps, but the videos play OK on my iPod. I can't explain why this is.)


So those are the three "usual suspects" that can keep an otherwise good MPEG-4/h.264 video file from working on an iPod Touch or iPhone. The first doesn't actually affect the iPod Touch or iPhone, only earlier video iPod models.

The second and third affect all video iPods. If you have a file which uses either B-frames or too many bits per second for the video (or both) you'll need to do one of two things to get the movie, TV show, or whatever to work on an iPod. Neither choice is easy.

The first choice is to re-rip your video from scratch. It's the choice I recommend, where feasible, for reasons that will be made clear as I discuss the second choice in my follow-on post, Videos for iPod Touch, Part 2.

If you do elect to re-rip your video, you need to make sure you do it in such a way as to produce an iPod-playable output file. You need to include an iPod atom, assuming you are using an earlier-model video iPod (even if you aren't, including the iPod atom doesn't hurt anything). You need to make sure no B-frames are used in the output. And you must make sure the video bitrate is 1500 kbps or less.

If you are using HandBrake 0.9.2 to do the ripping, the easiest way to avoid going wrong is to use one of the included presets for the iPod or iPhone. These include:

• iPhone / iPod Touch
  
• iPod High-Rez
  
• iPod Low-Rez
  

I find "iPod High-Rez" ideal for my purposes, as it automatically includes the iPod atom in case it's needed, spurns B-frames, and sets 1500 kbps as the maximum video bitrate.

I actually have created my own modified version of this preset, as I (owing to poor hearing) like to include English-language subtitles on all my rips. I strongly recommend that you modify the preset, as I did, to turn on Anamorphic: Strict under Picture Settings. This allows your output file to use "anamorphic encoding" if the DVD itself does. More on what that means can be found in Videos for iPod Touch, Part 2.


The second workaround for getting a non-iPod-playable video to play on your iPod is to use special software to do a conversion. I'll cover that option in Videos for iPod Touch, Part 2.