As readers are no doubt aware I’m an enthusiastic user of Apple products. Note that I didn’t say fan - I am a fan of things that don’t suck, and Apple generally delivers. But that’s not to say that other organizations can’t. One product that I particularly like is the video players from Roku. A feature that they have (at least in their top of the line models) that is missing in the the Apple TV is the ability to play back video from a USB thumb drive. These days 64g memory sticks are cheap and plentiful, which means that one has the ability to haul around a pretty decent video collection in a volume approximately equal to a couple deck of cards, that (unlike Netflix) doesn’t need a decent Internet connection, or indeed any Internet connection at all.

I know what you’re thinking… RS must get the videos by bittorrenting them right? Bzzt, no. Even if I didn’t work for a company that’s “in the business”, I’ve never been big on stealing. Imagining for a moment some hypothetical world in which I had flexible morals, the above statement about being a fan of things that don’t suck applies. From time to time I’ve used BT to look for a single program that our DVR should have recorded, but captured the end of a sportball game or a presidential address instead (thats’s a pretty good defense against accusations of “stealing” since we should have had it via our cable subscription). With that limited exposure I’ve found the level of compression typically found in the torrent world to be annoying.

There’s enough stuff on TV to fill my requirements. Some of it is even good. I have a Silicon Dust HD Homerun Prime, which is a little box with an F connector for cable TV, a slot for a cablecard, and a gigabit ethernet connector on the rear. I got mine on Black Friday sale at Amazon for $80 last fall; it typically sells for half again that much. MythTV knows how to talk to an HD Homerun Prime, as does NASDVR (much more approachable but fewer features). You can also talk to it with VLC and just record a transport stream to disk. This is sometimes exactly what you want, since it gives you the ability to start the recording a couple of minutes early and end it a couple of minutes late. The VLC command is of the form: cvlc$CHANNEL --run-time=$DURATION vlc://quit --sout file/ts:$FILENAME That will yield an mpeg2-ts file with mpeg2 video and ac3 audio, including all EIA-608/CEA-708 closed captions (not the same thing as subtitles!) and everything. Basically, it’s the bits straight off the QAM signal that comes in on your cable, minus the conditional access encryption which is removed by the cablecard.

The good news is that there’s no transcoding going on here, which is pleasant - in the cable tv ecosystem the encoder chain from the camera to you is already longer than optimal, and additional unnecessary transcoding only degrades the picture further while heating your home with CPU waste heat.

Sidebar: The cable industry is working on this, in no small part by taking satellites out of the equation and getting “mezzanine” (very high bitrate, very high quality) content over terrestrial fiber as the start point for encoding to various end-use codecs, resolutions, and bitrates in a single step. <a href=>An article</a> from 2013 refers to a <a href=>contemporaneously published CableLabs spec</a> that narrows down choices of mezzanine formats to three for the cable industry (there are actually a huge number of mezzanine formats in the wild).

Back to the transcoding question. One can of course play back the mpeg2 video on a laptop in VLC, but the Roku does not know what to do with an mpeg2-ts file. This is sad - the Roku already can ingest a .ts container (that’s what HLS is based on) and no doubt the hardware capability to decode mpeg2 is there in the SoC; it’s just a matter of whether it’s worth the licensing fees and development time to get to that hardware codec enabled (and do the AC3 audio playback, which is also a licensed codec). The Raspberry Pi folks offer a decoder license (tied to a particular SBC serial number) for a couple of quid; the Roku folks have made the (probably correct) business decision to not offer this. After all, as an over-the-top device, Roku boxes are “in competition with” the Cable TV ecosystem, not necessarily “integrated with” the Cable TV ecosystem; there’s no reason for them to support H.262 when they already have H.264.

That means we have to transcode one more time to a format that the Roku likes, and can be played back with either the Roku Media Player channel or something like Roksbox.

What does the Roku like? H.264 mp4 with AAC audio, Level 4.0, Main or High. They <a href=>lay it out here</a> albeit with suggested bit rates that are parsimonious and look ugly, even on a small screen.

ffmpeg and avconv work pretty well for transcoding, when one’s source material is “clean”, which is to say that it comes from a DVD or BluRay disk where the frame rate never shifts and there is good quality assurance on the encoding. One can’t speak quite so kindly of the technical compromises that are made for carriage on cable TV plant, either to fit in more channels (squishing the bit rate hard) or just out of general sloppiness (frame rate changes when lower-third graphics cut in and out, for instance), and no matter what tricks I try, the ffmpeg family tends to fail to keep the audio and video in sync for certain content. This drives me bananas.

Fortunately, there’s HandBrake (yes, the DVD ripping software) which does a pretty reasonable job of keeping the sync together and even tells you in the logs when it’s doing minor time steps to preserve audio/video synchronization. There’s a CLI version too, and in addition to the Mac it runs on Linux, which means I can run it in a virtualized environment on the server in the basement that has 2-4x as many cores as I have in any of my laptops. But it’s a pain getting that installed, since the daily builds (what you want, alas) are not part of the default Ubuntu distribution and there’s a lot of outdated information floating around as to how to add them in.

For Ubuntu 14.04, the proper series of incantations is: sudo apt-get install software-properties-common sudo apt-add-repository ppa:stebbins/handbrake-snapshots sudo apt-get update sudo apt-get upgrade sudo apt-get install handbrake-cli Then you’ll have your binary (mixed-case, how very non-Unix!) in /usr/bin/HandBrakeCLI

I’ll upload the encoder wrapper script I use (shows all the parameters) separately.

Now… you’re probably wondering whether I get rid of the commercials. I’m starting to play with that. The trick is finding a video editor that can be used for simple cut-in and cut-out without transcoding when saving. This should be fairly straightforward; indeed in a J.83 system (North American cable), the MPEG2 has an I-frame every half second, so one should be OK just snipping at the closest I-frame and calling it done. You can even do it on the command line with avconv or ffmpeg (use the “copy” codec), but it’s cumbersome.

On the Mac (actually cross-platform) there’s an editing program called avidemux. Despite the name it will work admirably on mpeg2-ts, if by “admirably” one means “can’t handle HD (only SD)”, “crashes when you try to seek past the end of the file” and “user interface is the typical Linux-level consistency that you’ve come to expect from stuff with an UI written in Qt”. You can install it from homebrew, but your time might be better spent digging through Google output and buttonholing friends looking for an editor. So I’m still looking.

Another thing I’m working on is getting closed captioning working. My wife likes having it turned on, and my mother in law is hard of hearing, so that’s a plus. There’s a program called “ccextractor” that will extract the EIA-608/CEA-708 captions and stick them in a <a href=>.srt</a> file. The problem has been getting Roksbox or Roku Media Player to do anything intelligent with them, despite following instructions.

So, all this is a work in progress. At least the video seems to be coming out OK. Maybe someone who reads this can share video editor recommendations or .srt clues.