TiVo MRV — Use a Second Wrapper?

Recently, in TiVo Multi-Room Viewing (Yet Again) and earlier TiVo Multi-Room Viewing entries to this blog I indicated my disappointment that my second TiVo DVR can't share recordings with my first TiVo if the recordings are copy-protected. I suggested that digital watermarking might be used on TiVo video recordings to enable tracking of the account from which a recorded program has been copied from one TiVo to another using Multi-Room Viewing (MRV).

I now have come to believe watermarking isn't the answer. I'll go into what the answer to the problem of using MRV on copy-protected material later in this entry. First, more about why watermarking isn't such a good idea.

In the following sample of a graphic image that has been given a watermark ...



... the identity of the image's creator has indelibly become part of the visible image. I suggested that something like this could be done with the video images associated with a TiVo recording when the recording is copied (a) to another TiVo using MRV, or (b) to a computer using TiVoToGo (TTG). The watermark could represent the 10-digit Media Access Key (MAK) of the recording TiVo(s) on a local home network, or else it could contain the user name on the TiVo account associated with the MAK.

After posting my last entry on the subject, I began to worry about whether a watermarking scheme to protect MRV is even feasible, so I started rummaging about in Google to see if watermarking has ever been seriously proposed for TiVo recordings.

It seems that the answer is only a highly qualified yes. In 2005, TiVo Inc. issued this press release indicating it would be using watermarking for TiVoToGo:

To discourage abuse or unlawful use of this feature, TiVo intends to employ "watermark" technologies on programs transferred to a portable device using the TiVoToGo feature that would enable tracking of the account from which a transferred program originated.

In other words, the "low-cost software [that users need to purchase] to facilitate the [TiVoToGo] transfer of content from the PC to ... portable devices" such as an iPod supposedly will watermark the transferred and reformatted content. For example on a Mac, Roxio's Toast Titanium software transfers a TiVo recording from the TiVo to the Mac, optionally decrypts it — since it is received in encrypted form — plays it on the Mac, makes a standard DVD of it, and/or converts it to a format compatible with an iPod.

I have made iPod-compatible copies of TiVo recordings in this way. I can't confirm that they're actually watermarked. They're certainly not visibly watermarked ... but watermarking can also be done invisibly.


Even if watermarking of TiVoToGo conversions is being done invisibly, it seemingly is not really what I'm looking for. The problem I've been fretting about with watermarking MRV transfers, as opposed to TTG conversions, is that in the latter the MPEG-2 video in the TiVo recording has to be decoded and then re-encoded in MPEG-4/h.264 format for (say) an iPod. The watermarking can be done rather easily between the decoding step and the re-encoding step.

But with MRV there is no decode/re-encode process. (Nor is there in TTG, prior to the actual format conversion which is the optional final step.) Instead, the intact MPEG-2 program stream as recorded on the TiVo, complete with the "wrapper" that the recording TiVo has added to the stream in order to encrypt it and keep it from being used in the absence of a TiVo-authorized decryption algorithm, is copied to the receiving TiVo as is. There is no convenient opportunity to watermark the video, visibly or invisibly.


So, if watermarking is out, what is in?

Watermarking is out, I repeat, due to the need to burrow down to an inner level of the information in the MPEG-2 program stream — the digitally encoded video information itself — decode it, add a watermark to it, and re-encode it. Such a process is difficult and time-consuming, and decoding and re-encoding lossy MPEG-2 video compression sacrifices quality.

If the burrowing-watermarking approach is a non-starter, then perhaps the right way to approach the MRV problem would be to add something to the very outer level of the MPEG stream.

Keep in mind that a TiVo already encases each MPEG-2 program stream that it records in a "wrapper" which in effect encrypts the stream. Unless the playback software or hardware knows the Media Access Key (MAK) of the recording TiVo and knows precisely how that MAK can be used to decrypt the stream, thereby removing the wrapper, playback is impossible.

Still, for better or for worse, that particular TiVo encryption/decryption algorithm has been hacked. Software known as tivodecode is available which can decrypt a .TiVo file that TiVoToGo has transferred to a computer from a TiVo DVR. This software is independent of the official software used with TiVoToGo, such that an average computer user can learn to decode any .TiVo file he has by providing the recording MAK as a parameter to tivodecode. Once the .TiVo file is decrypted, it can be used in any number of ways — including reformatting it to MPEG-4/h.264 for an iPod, with no watermarking whatever!

That means that authorized MRV copying of copy-protected programs needs an extra, better, layer of protection.


I envision it working something like this: when TiVo B wants to receive an MRV copy of a copy-protected program that has been recorded on TiVo A, B uses a secure network connection to send A an encryption key. This key is one which B has made up at random; it is not the MAK which is shared by the two TiVos.

The ad hoc encryption key would be generated by B, the requesting TiVo, at the time the MRV request is initiated. In fact, it could be (based on) a number representing the precise time and date, down to the millisecond or nanosecond, that the MRV request occurs.

The ad hoc encryption key would be transmitted by the receiving TiVo B to the sending TiVo A using something like a "secure socket layer," a type of safeguard against digital eavesdropping that is familiar to all those sending credit card numbers across the Internet.

Once it received the ad hoc encryption key from TiVo B, TiVo A would use it to add a second "wrapper" around the requested program stream, in addition to the wrapper already being used that depends on the MAK. This second wrapper would represent an additional layer of encryption. Only TiVo B, the receiving TiVo which has requested the MRV copy and which has provided the ad hoc key, could remove the second wrapper and play the copy in the customary way.

This strategy of using a second wrapper would apply only to Multi-Room Viewing, not to TiVoToGo. TTG would still not be able to transfer copy-protected programs. Only MRV would be able to do that.


The general idea here would be that the only real threat to digital rights management posed by TiVo MRV has to do with eavesdropping. If two TiVos, using nothing but approved methods, send copies of copy-protected programs between themselves on a home network in a way that is completely secure from eavesdropping, there is presumably no possibility of illicit activity.

An assumption here is accordingly that the elaborate new authentication protocol that, I am suggesting, ought to be used for MRV would make the process unhackable — that is, the MRV "handshake" between two authorized TiVos (including, but not limited to, the secure transmission of the ad hoc key) could never be faked by a computer hacker programming his computer to pretend to be "TiVo B," the requesting TiVo. Hence, the only way the hacker could get access to the copy-protected MPEG stream being transmitted on the network would be by "listening in" to its MRV transmission, while it is in progress. But that would only get him an encrypted program stream that he lacks the ad hoc key to decrypt.

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.

Using a Browser for TiVoToGo

This post is part of my TiVoToGo series on the ins and outs of moving TV recordings from a TiVo DVR to a Mac, for use eventually with iTunes, Front Row, and Apple TV. In previous posts I assumed the use of TiVo Desktop to copy recordings from the TiVo to the Mac. But there is an alternative. As long as you have the TiVo Desktop software installed, you can simply transfer recordings via your browser.

This is true whether you use a Mac browser or a Windows browser in Parallels Desktop for Mac.

I use Firefox as my main browser, but any browser will do. Just enter the URL https://<IP_address>/nowplaying/index.html. (Notice the "s" in https.)

The <IP_address> is that of your TiVo, which you can learn from TiVo Central -> Messages & Settings -> Settings -> Phone & Network on your TiVo. Mine is currently 10.0.1.4, though it changes from time to time. (Your TiVo has an IP address only if it's connected to a network. You need to network your TiVo if you want to use TiVoToGo.)

Next come the formalities. You may be presented by your browser with a warning about an unknown security certificate. Just click OK or Continue to go on. You will then be asked to enter a user name and password. The user name is tivo. The password is the media access key of your TiVo, a ten-digit number you can discover by navigating to TiVo Central -> Messages & Settings -> Account & System Information -> Media Access Key on your TiVo. You enter these and click the option to have the browser remember them for future use.

(Later on when you download files, you may have to enter the user name and password a second time. Do the same as before: enter user name tivo, type in your media access key as password, and tell the browser to remember this information for future use.)

Once you are done with the administrivia, you see something like:





All the shows recorded on your TiVo are presented, grouped by program title into folders as necessary. You can click to open a folder and see the shows within.

(If you don't see folders, you may be in classic view rather than groups view. Scroll to the bottom of the page and click on groups.)

For individual shows, in folders or otherwise, you can click on Download MPEG-PS to download the show to your computer as a .TiVo file.

When you do that, the browser will do whatever it usually does when you download something. Default behavior for Firefox is to create the downloaded file on the Desktop, but you can alter Firefox's Options/Preferences to always ask where to save a downloaded file. That's what I do, since I want to direct all TiVo downloads to a folder on my AirPort disk.

An AirPort disk is a USB 2.0 hard drive connected to an Apple AirPort Extreme Base Station ... a router, for all you non-Mac people. I like to use the browser method, rather than the official TiVo Desktop software, to copy recordings from my TiVo to my Mac, because I can't get the latter to direct downloads to my AirPort disk.

To find a show you want to download, you'll probably have to scroll down the Now Playing list:




When you click on Download MPEG-PS, then after you tell the browser where to put the downloaded file, you'll see:




It will take a fair amount of time for the download to complete. You won't see a time estimate, since the TiVo doesn't let the download process know how big the file is. You can bank on it taking upwards of an hour for an hour show on a wireless home network. These files are big.

Once the download is done, you'll be able to play the file in Toast Video Player under Mac OS X. You can also play it in Windows Media Player under Windows XP in Parallels ... maybe. I find that Windows Media Player balks, complaining about a missing codec, unless I upgrade TiVo Desktop to TiVo Desktop Plus. (This tells me the TiVo Desktop Plus package contains more than just the application itself.)

You can also convert the .TiVo file for use with iTunes, Front Row, and Apple TV ... the subject of Using VideoReDo on TiVo Files and Using VisualHub on TiVo Files.

Using VideoReDo TVSuite on a Mac

VideoReDo TVSuite is $74.99 software from VideoReDo that can edit MPEG-2 videos. That makes it an excellent choice for those like me who want to transfer TV recordings from their TiVo DVR to their Apple TV, cutting out commercials along the way.

Using TiVoToGo functionality found on all current TiVo models, you can transfer recordings of TV shows to your PC or to your Mac. VideoReDo demands a Windows PC. I have only Macs. I get around that problem by running Windows in the $79.99 Parallels Desktop for Mac package.

Parallels basically lets me set up, on my Intel-based MacBook Pro laptop, a "virtual machine," complete with imaginary hardware devices such as network adapters and hard drives. Into that virtual machine I install Windows XP. Windows shows up as (you guessed it) the contents of an ordinary Mac OS X window:




If you like, you can also run Windows/Parallels in full-screen mode, hiding all Mac-like things entirely. Or you can run it in "Coherence" mode, such that each open window in Windows becomes a separate open Window in the ordinary Mac environment.

You can learn more about running Windows in Parallels in Using Parallels Desktop for TiVo-to-Apple-TV Transfers.

After I bring up Windows in Parallels, I then copy one or more TiVo recordings from my TiVo box to my virtual Windows computer via TiVoToGo — specifically, by use of the free TiVo Desktop software I downloaded from here and installed in Windows:




I actually sprang for the $24.95 TiVo Desktop Plus upgrade, available here, an enhanced version of TiVo Desktop. I did this for two reasons.

One, Plus allows TiVo Desktop to export .TiVo files directly in an h.264 codec suitable for an iPod, without resorting to third-party software. This "one-stop shopping" approach I found to be of sadly limited use for Apple TV, though, since output resolution is restricted to 320 x 240 pixels, and since no provision is made for editing the programs.

Two, the Plus upgrade allows .TiVo files to play in Windows Media Player in Windows XP, which I find to be nice but not essential.

Yes, I probably could have saved my $24.95.

You can learn more about this TiVo Desktop software in Using TiVo Desktop in Windows.

Alternatively, you can use a Web browser to copy TiVo recordings without using the TiVo Desktop application (though you do need to have TiVo Desktop or TiVo Desktop Plus installed). See Using a Browser for TiVoToGo for more about that.

Once one or more TiVo recordings have been copied to the Windows virtual machine, I theoretically might need to decrypt them, since they arrive on the Windows VM in encrypted form. However — and this differs from my experience with TiVo Desktop on the Mac — I don't actually seem to have to perform a separate decryption step, before VideoReDo (see below) can use the files. I'm not sure exactly why this is, but it's a definite speedup.


The next thing I do, after transferring one or more TiVo files to my virtual Windows machine, is open one of them for editing in VideoReDo:



Once I am done with the editing process per se, I tell VideoReDo to save my (edited) result in an .mpg container file, the internal contents of which are officially considered an "MPEG-2 program stream." The .TiVo input file itself is in a similar MPEG-2 internal format, except that it's encrypted. So when I save the edited video to an .mpg file, basically all VideoReDo does is a "fast frame copy" of all the video and audio frames in the input file (minus, of course, the stuff I've edited out). This happens fairly rapidly, with no transcoding and accordingly no loss of quality.

I find it convenient to save to an AirPort disk the rather large .mpg files created by VideoReDo. Windows (into which I have installed the free download AirPort for Windows software) lets me access the 500 GB USB 2.0 hard drive I have attached to my AirPort Extreme base station (that's Apple's fancy name for a WiFi router).

The next step (see below) is to use the .mpg files I store on the AirPort disk as input to Mac software, VisualHub, which will convert them for Apple TV use. VisualHub, like all Mac software, can also utilize the AirPort disk.

You can learn more about the VideoReDo editing/exporting process in Using VideoReDo on TiVo Files.


I need to convert the edited .mpg videos from the MPEG-2 format in which they are recorded by VideoReDo to a format playable by Apple TV.

Specifically, I need to convert them to the h.264 version of the MPEG-4 codec. h.264 is a compact, high-quality way to encode video programs, much more space-efficient at any given level of video quality than MPEG-2. Not only does Apple TV use h.264, so do video iPods and iPhones.

I find the software of choice to do the MPEG-2 to h.264 transcoding is VisualHub, which sells for $23.32:



The basic idea is that you drag the .mpg file you want to convert into the VisualHub window, choose To: iTunes, and select Optimize for: Apple TV with H.264 Encoding checkmarked. Use the Edit... button to tell VisualHub where to put your output file. Then click Start (replaced by Cancel in the screen shot above) to initiate the conversion.

If you want to get more control over the details of the conversion, then before you click Start, click Advanced... and see the Advanced Settings pane:



In this particular example, I forced FFmpeg Decoding (rather than QuickTime Decoding or VLC Decoding). Since I have managed to gain some familiarity with FFmpeg as a transcoding engine (see Transcoding to h.264 Using FFmpeg), that seemed reasonable.

I also forced the size-in-pixels of the video frame to 960x540, and the video framerate to 30 frames per second. The input was actually 1280x720 — 720p high-definition TV — at 60 fps. Apple TV can't handle that frame size/rate combination, so I lowered both the size and the rate to the top numbers Apple TV will tolerate.

You can learn more about using VisualHub to create Apple TV-compatible videos out of TiVo recordings in Using VisualHub on TiVo Files.


The "bucket brigade" of TiVo Desktop Plus and VideoReDo TVSuite in Windows (running in Parallels Desktop for Mac), followed by VisualHub on the Mac side, seems to be a winner for me.

TiVo Desktop Plus grabs my recordings and copies them to my computer.

VideoReDo TVSuite edits out the commercials and unwanted material. It also can work magic with input files that are in need of some kind of repair, such as making sure the audio and video are properly in sync. For especially damaged files, its Quick Stream Fix option can save the day.

VisualHub is a versatile engine for converting between (among other combinations) the original file's MPEG-2 video codec and the MPEG-4/h.264 codec required by Apple TV.

What's not to like?

Using VisualHub on TiVo Files

In this TiVoToGo series of posts I've been talking about ways to usher recorded TV shows from your TiVo DVR to your Mac and then play them on your Apple TV.

One good way involves using a software "bucket brigade":

1. TiVo Desktop to copy recordings from the TiVo to the Mac — see Using TiVo Desktop in Windows.
   
2. VideoReDo TVSuite to edit out commercials, and also decrypt the original file — see Using VideoReDo TVSuite on a Mac.
   
3. VisualHub to convert the decrypted-and-edited file to a format compatible with Apple TV. (Edit: Unfortunately, since this post originally appeared, Techspansion, the creator of VisualHub, has closed its doors.)
   

The first two run in Windows XP, which runs in Parallels Desktop for Mac — see Using Parallels Desktop for TiVo-to-Apple-TV Transfers. The third, VisualHub, is the topic of this post. It runs under Mac OS X.

VisualHub (whose logo appears to the right) is "the universal video converter for Macintosh," which means it can convert virtually any video file (with or without audio) into any of several formats. One of the input formats VisualHub can convert is MPEG-2, signified by an .mpg filename extension. (VisualHub cannot read an encrypted MPEG-2 file with a .TiVo extension, such as one created by TiVo Desktop. This is one reason why I use VideoReDo, which reads in a .TiVo file and exports an .mpg.)

VisualHub in turn reads in an .mpg file and converts it to an .mp4 file — an extension signifying MPEG-4 as opposed to MPEG-2. MPEG-4 encoding is more space- and bitrate-efficient than the MPEG-2 format used on DVDs.

Yet more efficient is the h.264 version of MPEG-4, which is what VisualHub produces when told (1) to export to iTunes ... (2) a file optimized for Apple TV ... (3) using h.264 encoding:


Setting up the VisualHub conversion illustrated above was simple. I simply dragged an .mpg file icon to the VisualHub icon in the Dock. (I could also have dragged it into the VisualHub main window shown above, after manually having opened the VisualHub application.)

I then clicked on the iTunes tab at the left end of the To: row. I checkmarked H.264 Encoding. I used the pop-up menu to select optimizing for Apple TV ... instead of, say, iPod Touch or iPod Nano.

One thing that did was make sure my output file uses "B frames," handy ways of encoding individual video frames or pictures. B frames hold the output file size and bitrate down. If B frames aren't used, the output consists of just I frames and P frames, which use more bits than B frames. However, since B frames impose a heavy load on the decoder of the file, iPods don't support them. Apple TVs do.

I didn't have to move the Quality slider to Standard, because that was the default position. The different slider positions make for different levels of video quality in the output file by increasing or decreasing the video bitrate (and consequently the file size). I find that standard quality is fine for TiVo standard definition files, resulting in video that plays without artifacts. The file size is, meanwhile, quite compact.

I clicked on the Edit... button to tell VisualHub where to put the output file. By default, VisualHub puts the output file in the same folder as the input file. If you want it to go in a different place, use the Edit... button. (One thing lacking in VisualHub is the ability to give the output file any name you like. Instead, the output file always has the same name as the input file, with a different extension.)

I checkmarked Add to iTunes since I wanted my output file to play through iTunes on an Apple TV. The Add to iTunes option avoids having to add the output file manually.

Finally, I clicked on the Start button (which was replaced by the Cancel button seen in the screen shot above). VisualHub began the conversion of the input file to the output file, a process which lasted over two hours. The result was a file playable by iTunes and likewise by Front Row and Apple TV.

You can gain additional control over how the output file is rendered by using the VisualHub Advanced Options window. More on that in Using VisualHub Advanced Options.

Using VisualHub Advanced Options

This is another post in my TiVoToGo series on the ins and outs of moving TV recordings from a TiVo DVR to a Mac, for use eventually with iTunes, Front Row, and Apple TV.

One good way to do it involves this software "bucket brigade":

1. TiVo Desktop to copy recordings from the TiVo to the Mac — see Using TiVo Desktop in Windows. (You can also do this with a Web browser — see Using a Browser for TiVoToGo.)
   
2. VideoReDo TVSuite to edit out commercials, and also decrypt the copied file — see Using VideoReDo TVSuite on a Mac.
   
3. VisualHub to convert the decrypted-and-edited file to a format compatible with Apple TV.
   

The first two run in Windows XP, which runs in Parallels Desktop for Mac — see Using Parallels Desktop for TiVo-to-Apple-TV Transfers. The third, VisualHub, is the topic of this post. It runs under Mac OS X.

In Using VisualHub on TiVo Files I discussed the basics of using VisualHub. In this post I'll deal with some of VisualHub's Advanced Settings.

The Advanced Settings window looks like this:




In the above screen shot I'm about to convert a file that I identified in the VisualHub Main Window:



This conversion is to be of a file in the MPEG-2 video compression format, as indicated by the .mpg extension. That input file is the result of copying a TiVo recording of an episode of House that was cablecast in 720p, the high-definition format in which there are 60 frames of video per second, each frame having a resolution of 1,280 x 720 pixels. After copying the recording using TiVo Desktop, I edited out commercials using VideoReDo. Now I have to convert it to a format compatible with Apple TV.

That format is the h.264 version of the MPEG-4 codec ... which is exactly what has been selected in VisualHub's Main Window. But there are restrictions that apply to files that are going to be playable by Apple TV, which is why I have to use Advanced Settings.

Apple TV files have certain combinations of resolutions and frame rates that need to be adhered to. It turns out that the top resolution for video with the 16:9 aspect ratio — the aspect ratio that is standard for HDTV — is 960 pixels by 540 pixels, at a maximum frame rate of 30 frames per second. Hence, in the Advanced Settings window above I indicate Size: 960 x 540 px and Framerate: 30.

I have also told VisualHub to Force: FFmpeg decoding. The input file will accordingly be decoded by FFmpeg, a decoding-encoding module included with VisualHub. I don't want to use the second choice in the Force: pop-up menu, Quicktime decoding, since for murky reasons QuickTime, even when enhanced with Apple's $19.99 QuickTime MPEG-2 Playback Component, will neither play nor decode most .mpg files derived from TiVo recordings.

Nor do I want to use the third, remaining choice in the Force: pop-up menu, VLC decoding. The main reason for that is ... well, actually, I just haven't tried that option.

If I don't put the check mark next to Force:, my experience is that VisualHub will default to FFmpeg decoding anyway. I put the check mark there just for illustrative purposes.


That's about it with respect to HDTV recordings. I also like to save old movies from the Turner Classic Movies channel, which is standard-def. Many of these are shown in a letterbox: the movie is shown in its original aspect ratio with black bars at the top and bottom of the screen.

When a letterboxed movie is converted by VisualHub and then shown on a widescreen TV via Apple TV, it will have black bars not only at the top and bottom, but at the sides as well:




You can use the cropping features of VisualHub to reduce or eliminate the black bars at the top and bottom. In so doing, you will also eliminate the bars at the side:




Here are the necessary Advanced Settings:




I set up the conversion to crop 104 pixels (actually, lines of pixels) off the top and 104 off the bottom of the nominally 640 x 480 input image, resulting in a 640 x 272 output image.

(To be quite precise, the actual frame size of the input image happens to be 704 x 480, not 640 x 480. 704 non-square pixels are shoehorned into each input line where 640 square pixels will appear in the output of the conversion. Since VisualHub cannot output non-square pixels, I'm ignoring this detail.)


How I determined exactly how many lines to crop at top and bottom was not at all straightforward, though. There are several ways to do this. One is to use the Set Autocrop: pop-up menu, selecting from it its By This File option.

When you do that, VisualHub examines the first few seconds of the input file to try to see how many lines of pixels at the top and bottom of the screen are all black. Those are presumably the letterboxing bars, and they can go away.

Trouble is, TiVo files generally have a line of pixels at or near the top of the screen in which the pixels are not all black. This line contains changing information that translates into Closed Captioning text. It fools VisualHub into using zero for the number of lines to autocrop at top.

VisualHub has a better chance of getting the bottom autocrop figure right. In my conversion of The Great Escape, it wanted the crop-at-bottom number to be 108 lines.

At first I thought I would just use the same number for crop-at-top. I recognized, however, that the results of the video compression VisualHub would be doing as it converted the MPEG-2 input to the MPEG-4/h.264 output would be better in quality if the number of horizontal lines in the resulting image were divisible by 16.

Doing a little back-of-the-envelope math, I saw that the crop-at-top and crop-at-bottom numbers should each be divisible by 8 — given that the number of lines in the input image, 480, is divisible by 16. 8 times 2 is 16. Hence, the crop-at-top and crop-at-bottom numbers can be divisible by 8 ... not necessarily by 16.

108 is not divisible by 8, while 104 is. Hence, I used 104 as both the crop-at-top and the crop-at-bottom number.

Another way to get the right cropping numbers is by trial and error ... in which case, you would be well advised to create a short snippet of the movie to run your experiments on. You can do that in VideoReDo as a separate step from outputting the entire movie. If you go the snippet route, your best bet is to output a swatch of, say, one minute in length from somewhere in the middle of the movie. Use that snippet for your cropping experiments.

(Why a snippet from the middle of the movie? Often, material at the very beginning gives a false bottom-autocrop reading. For instance, old MGM flicks typically start with a Leo the Lion logo on a black background. VisualHub interprets everything below the logo as croppable.)

Finally, a quick and dirty way to set the cropping numbers for any letterboxed film is to try 60 for both the top and the bottom figures. The result will be a 640 x 360 frame, for a 16:9 aspect ratio. That's the aspect ratio of a widescreen HDTV. There may still be (shorter) letterboxing bars on the HDTV screen, but even if you cropped off every single line of black in the input, by the time Apple TV got done displaying the output image on your HDTV, the (shorter) bars would show up there anyway.

Of course, 60 is not divisible by 8, so the purist may prefer to crop 56 pixels, or 64, at top and bottom and sacrifice the exact 16:9 aspect ratio. Or, try 56 at top and 64 at bottom.

One caveat: Not all letterbox bars are greater than, say, 60 pixels in height, and using a predetermined number such as 60 for quick-and-dirty frame cropping could bite into the actual image. One way to avoid that is to click VisualHub's Preview button in Advanced Settings. Up will pop a window giving you an advance look at a single frame from the video:




Once the Preview window is visible, you can change the number of seconds into the video the preview frame comes from by setting Start at ___ sec. That lets you find a still frame that is truly representative — if, say, early frames from the very beginning of the video aren't letterboxed.

With the Preview window visible, you can go back to the Advanced Settings window and tweak the cropping parameters. Then either click Preview again in the Advanced Settings window or click Generate in the Preview window. The still frame will be redisplayed with the new cropping. In that way you can zero in on just the cropping numbers you want.

(Another great thing about the Preview window is that you can check mark Show Compression, then change the Quality setting in the VisualHub main window and click Generate. The preview will be regenerated with the new compression parameter, and you can see immediately how your change will affect the output quality.)

Please pardon the above extended dissertation on image cropping, by the way. Cropping is helpful in making best use of your TV screen's real estate ... and it makes for smaller output files from VisualHub!


If you go back and look at the prior Advanced Settings screen shot, you can see that I also check-marked VisualHub's Deinterlace option. Understanding the value of this option, alas, demands another dissertation.

Standard-def TV is interlaced, which means every still frame in the moving image is actually two pictures. One picture occupies the odd-numbered lines of the 480 lines of pixels in the image; the second, which represents the scene 1/60 second later, occupies the even-numbered lines.

Normally, that creates no problems. There are simply 30 frames per second, each composed of two fields, for a field rate of 60 per second.

When the source of the program is film, though, there are problems. Film is shot at 24 frames per second, not video's 30 frames per second. When film is shown on television, the 24 frames can be sliced and diced into 48 fields easily enough ... but there need to be an additional 12 fields to pad out to 60 per second.

That is done simply be repeating some of the 48 fields. (TV is known for its repeats, right?)

For technical reasons, this trick is referred to as "3:2 pulldown," aka "2:3 pulldown."

When the resulting TV signal is captured by a TiVo and digitized, and then converted to MPEG-4/h.264, the conversion creates frames that are not interlaced. They do not consist of two pictures 1/60 second apart. They consist of a single picture per video frame which is the composite of the two fields of the original.

When two fields are composited in this way, they can produce an image that comes from two separate frames of film. Objects that are in motion can have their normally straight edges take on a serrated appearance:




Watching such serrated-edge images stream by can give the impression that the images are fuzzy or unstable.

The best antidote is to do "3:2 pulldown compensation": simply remove the 12 fields per second that were inserted to pad out to 60. The result, done right, is that each of the (now) 24 frames per second of video represents exactly one frame of the original film. No more serrated edges.

Sadly, VisualHub has no way of doing 3:2 pulldown compensation. Instead, it uses deinterlacing. In the type of deinterlacing VisualHub uses, one field of each frame is simply discarded ... or, actually, it has the other field of the same frame substituted for it.

Now, all the information in each frame of video output comes from just one film frame ... and there can be no serrated edges. The image looks rock steady:




The downside is that vertical resolution is halved. Where there were originally 480 lines of vertical resolution, now there are just 240. (And cropping the image at top and bottom can result in even fewer lines of vertical resolution.)

So the use of VisualHub's Deinterlace option is a matter of personal taste. I myself find that deinterlacing produces a more pleasing result than allowing edge serration to creep in. Your mileage may vary.

Transcoding to h.264 Using FFmpeg

(Geek alert: this article is not for the technically faint of heart!)

One of the basic tasks to be done in transforming a TiVo recording into a video that plays on an Apple TV is the transcoding of the MPEG-2 of the original TiVo recording (after it has been duly decrypted) into a file that uses the MPEG-4 codec. Specifically, the h.264 variety of that codec is what Apple TV must have. Apple TV can't use MPEG-2.

If you, like me, use VisualHub for this transcoding purpose, you may (again, like me) run into situations where you need more control over what VisualHub is doing ... more control, that is, than the "ordinary" Advanced Settings in VisualHub seem to give you.

You can gain extra control by checkmarking "Force: FFmpeg Decoding" and entering appropriate FFmpeg options and arguments into the "Extra FFmpeg flags" field.

So, what is FFmpeg? FFmpeg is a standalone software tool that VisualHub "contains" in the form of a Unix executable file named vh131ffmpeg, located in the user folder ~/Library/Application Support/Techspansion/. The exact name of the executable could change in future releases of VisualHub; that's the name as of version 1.3.1 of VisualHub.

That Unix executable can be directly invoked in Terminal, if you want to play around with it without using VisualHub as an intermediary. Here's how I get to it, under username dalekhound:

$ cd /Users/dalekhound/Library/Application\ Support/Techspansion
$ ./vh131ffmpeg

The $ is the prompt character in Terminal, which is always, in my case, expanded to:

eric-stewarts-computer:Techspansion dalekhound$

I'll leave that boilerplate out in what follows, and just use $.

Notice that I have to precede the name of the executable with ./ so as to get $ ./vh131ffmpeg. If I don't do that, the Mac tries to find vh131ffmpeg somewhere other than the current directory, the one which I set using cd.

Just entering ./vh131ffmpeg with no options or arguments causes it to produce a voluminous list of the options you can choose ... as if you had entered ./vh131ffmpeg -help.

Another way to learn about FFmpeg's options is to visit http://ffmpeg.mplayerhq.hu/ffmpeg-doc.html.

You can also find a well-written overview of FFmpeg's usage at http://howto-pages.org/ffmpeg/.

The basic function of VisualHub's "Extra FFmpeg flags" field is to allow you to input various options and arguments to FFmpeg, just as you would if you were using the command-line interface in Terminal. Here's a very brief primer on the options and arguments.

If I enter, in Terminal:

$ ./vh131ffmpeg -i ...

and fill in the placeholder meaningfully with the path to an input file, FFmpeg will transcode the input file and produce an output file in according to the options that I replace ... with.

For purposes of this tutorial I'm using an input file whose full path can be given as:

/Volumes/My\ Book-3/TiVo/TiVo\ Shows/Needing\ Export/From\ VideoReDo/Hello,\ Dolly\!.mpg

Notice two things. First, the levels of the folder hierarchy are separated from each other by a forward slash /. Second, every character in the pathname (including space characters) that is not a letter, a number, or a period is preceded by an "escape" character: a backward slash \.

Alternatively, the whole pathname, or any part thereof that would otherwise have to contain internal escape characters, can be enclosed in single quotes ('). For example:

'/Volumes/My Book-3/TiVo/TiVo Shows/Needing Export/From VideoReDo/Hello, Dolly!'.mpg

The output file's full path name can be exactly the same as that for the input file, except that .mp4 is substituted for .mpg. This is appropriate for two reasons. One, you don't want to overwrite the input file. Two, the output file (in this case) will be in a format appropriate to the MPEG-4/h.264 codec, and as such should have the qualifier .mpg.

Rather than laboriously type in the whole path name, try typing just ./vh131ffmpeg -i , with a trailing space character, after which you can simply drag the Finder icon for the input file into the Terminal window. The properly specified path name will magically appear, with all the required escape characters. Then type in the options you want to replace the ellipsis ( ... ) with, in the above template. Finally, again drag the Finder icon for the input file into Terminal, but this time go on to manually edit the output file name (if desired) and definitely change the extension to .mp4. Once you have done all that, hit the return key, and the command will execute.

Another trick you can use is to build the command line in a TextEdit document and copy it in its entirety to Terminal. You can use the drag-the-Finder-option shortcut too. But now, the pathname you get in TextEdit won't have the necessary escape characters, so you have to manually enclose the pathname in single quotes.

If I use TextEdit to build:

/vh131ffmpeg -i '/Volumes/My Book-3/TiVo/TiVo Shows/Needing Export/From VideoReDo/Hello, Dolly!'.mpg

and copy that into Terminal (hitting return), I see:

FFmpeg version SVN-r9226, Copyright (c) 2000-2007 Fabrice Bellard, et al. libavutil: 49.4.0 libavcodec: 51.40.4 libavformat: 51.12.1 built: Feb 12 2008 19:58:15, gcc: 4.0.1 (Apple Computer, Inc. build 5367), i386

Input #0, mpeg, from '/Volumes/My Book-3/TiVo/TiVo Shows/Needing Export/From VideoReDo/Hello, Dolly!.mpg':

Duration-8906 start-0.200000 bitrate-2312

0.0,,dvd1e0,,,Video,mpeg2video,yuv420p,704,480,29.97

0.1,,dvd80,,,Audio,ac3,48000,2,192

The first part is information about this particular version of FFmpeg, followed by important information about the input file. (Notice that as yet there are no further FFmpeg options in the command line, and no output file is specified.)

The duration of the input file is 8,906 seconds, or about 148.43 minutes ... or about 2.47 hours. It's actual start time is for some reason offset from the nominal beginning by 0.2 seconds. The bitrate of the file, including both its audio and video streams, is 2,312 kilobits per second.

There are two streams, a video stream, designated 0.0, and an audio stream, 0.1. These designations use "0" before the "." to represent the first (and in this case only) input file to FFmpeg, and the "0" and "1" after the "." to represent, respectively, the first and second streams in that single input file. The first (or "0.0") stream is video; the second (or "0.1") stream is audio.

I'm not sure what some of the other stuff means, but:

• mpeg2video is the video codec that will be used by FFmpeg to decode the video stream
• yuv420p tells how the video's pixels are "put together": how the color is specified as two components (uv) and how the luminance (black and white component) is specified (y); I think "420p" has to do with the way in which the color information is "subsampled" (reduced in quantity) with respect to the luminance
• The video frame has 704 pixels horizontally and 480 pixels vertically
• There are 29.97 video frames per second
• The audio is encoded using the ac3 (i.e., Dolby Digital) codec, with 48.000 audio samples per second for each channel; there are 2 channels (i.e., it is stereo); the audio bitrate is 192 Kb/sec
  

Notice that what is not mentioned, but is actually the case, is that this input file plays back in (say) the VLC media player with an aspect ratio of 4:3. That "display aspect ratio" is usual with standard definition NTSC fare such as this recording.

Also notice that the "nominal aspect ratio" is 704:480 — that is, there are 704 pixels horizontally in the frame and 480 pixels vertically. For a 4:3 frame with 480 "lines," the number of pixels in each line "ought to be" 640, not 704. 640:480 is the same as 4:3. (To see this, divide the X in X:Y by the Y. For both 640:480 and 4:3, the result is 1.33333 .... .)

But 704:480 is 1.4666666 ... , not 1.33333 ... .

So the pixels in my input file are not the usual "square" pixels whose height and width are equal. Instead, the width is only 640/704 of the height. 640/704 equals 0.909090909 ... . These pixels are roughly 90% as wide as they "ought to be."

That's not a bad thing: cramming 704 pixels into a line that "ought to" contain only 640 pixels allows greater horizontal resolution.

Actually, though, I believe the non-square pixels are but an artifact of how the TiVo captures standard-definition analog TV, which has a display aspect ratio of 4:3. Instead of encoding it as 480 lines of 640 square pixels per line, it uses non-square pixels in a 704x480 grid.

This is akin to how 4:3 video is recorded in MPEG-2 on a non-anamorphic DVD. By emulating a DVD format, a TiVo makes it relatively easy to use TiVoToGo to transfer a recording to a computer and then burn it (after decrypting) to a DVD.

But FFmpeg, at least when its output file is h.264, uses only square pixels. If you transcode a 704x480 file in FFmpeg (or in VisualHub with FFmpeg as its decoder), the result will have a 640x480 grid. Whatever extra horizontal resolution (above 640 pixels per line) that may have been in the input file will be lost. Fortunately, I don't believe actual standard-def 4:3 channels have even 640 pixels per line of discernible detail, so nothing is really lost here.

[More to come ...]