[mythtv] Placeshifting for MythTV?

[Stewart Nelson]

Hi developers,

I'm toying with the idea of adding a placeshifting feature to MythTV
and am writing to ask:
-- How much work it might be, given what I've already done?
-- Would much of the community benefit?, i.e. I'd be willing to do
    more, if there would be many users.
-- What would be a good general approach?

The initial goal is decent HD playback, without freezes, gaps or
glitches, with responsive skip/backspace/seek, within the program
that has been retrieved so far.  By "decent", I mean picture and
sound providing enjoyable large-screen viewing of e.g. a basketball
game or an action movie; videophile quality is not expected.

What I started with:

I have a Slingbox Pro-HD in New York, connected to a Motorola DVR
from Verizon FiOS.  The Internet connection is 20 Mbps upstream.
Using the SlingPlayer application, it works quite well at short
distances, but at our winter home in Bangkok (with 10 Mbps DSL),
performance is poor.  Typically, a streaming rate of only 1.5 Mbps is
achieved. During fast action, this causes the CBR H.264 encoder,
which can do only 720p30 to begin with, to drop two of every three
frames.  At 10 fps, watching action sports sucks.  Next, even a minor
disturbance on the Internet causes the video to glitch.  Finally, it's
very frustrating to control the remote DVR.  The latency of the Internet
connection, IR relay and video buffering, combined with the sluggish
response of the DVR itself, results in a 1-2 second loop delay.

Next steps:

There is an open source Slingbox recorder, but on the PRO-HD, capture
was limited to 320x240.  Using that as a guide, I wrote one that could
handle 1280x720.  Recording to a local file at 4+ Mbps yields a decent
picture.  Once captured, the file could be moved to Bangkok by HTTP
and played with VLC, or copied to a flash drive and played on the TV.
However, you couldn't start watching a three-hour show until 12 hours
after it began (3 hours to capture + 9 hours to transfer).  That's no big
deal for a movie, but for a sports event, you'd likely inadvertently
see the result on the Internet first, ruining it completely.

So, I took aim at the file transfer, rigging a UDP-based FTP with a large
window, which achieves ~8 Mbps across the link, vs. ~1.5 Mbps for
HTTP.  Also, it throttles as it approaches EOF; allowing the transfer to
follow the growing recording.  At this point, one can start watching
after the show ends and enjoy all trick play features.  Alternatively,
you can begin viewing shortly after the beginning of the broadcast,
but with no skip capability at all.  This near-real-time mode has
another issue; if an Internet disturbance allows the player to overrun
the file, it quits and there is no recovery, short of starting over.

I made several attempts to get VLC / mplayer / whatever to work
well when faced with a growing file, all to no avail, probably because
I understand little about the innards of these complex players.  Then,
it hit me that MythTV may be an ideal solution, because it was
designed from the ground up, to allow trick play in a growing file.

Does anyone want this stuff?

I would expect demand for placeshifting to be huge: more than
500,000 Slingboxes have been sold (even though they don't work
very well); there are several other similar products.  While those
spending long periods away from home would benefit most,
vacationers and business travelers would also like to catch a game
from their home town, or view the latest episode of their favorite
series.  These days, most hotel rooms come with broadband and
an HDTV; you just need an HDMI cable to connect it to your laptop.
Surprisingly, I see no placeshifting requests whatever on the wishlist.
Searching the forums, I find a few users with a remote slave backend,
connected by VPN.  But, if I understand correctly, that only works if
the playback rate is less than what the TCP connection will
consistently support, which would generally preclude HD operation.

I understand that most travelers will not have enough bandwidth for
real time streaming of quality HD, even with an aggressive transfer
algorithm.  IMO, that's not a serious issue; time zone differences
and trip schedules make it unlikely that they would want to watch at
the time a show is aired.  They just have to be careful not to see the
result of that game.

How do you make it all work?

One possibility is to run a separate process on the backend, which
receives the file from the remote and emulates an IPTV source.  That
way, I'd have a well-defined spec to design to, and wouldn't have to
modify (or even understand) MythTV.  The remote recorder would be
unchanged.  It's a fairly simple perl script, runs on Win/Mac/Linux,
needs only the Slingbox IP address and password for configuration,
and has no UI.  Unfortunately, this approach has a major problem --
it would require a Slingbox.  While it would be possible to write
recorder scripts for other capture devices, that would requite a great
deal of effort, needlessly duplicating what's already been done for
the MythTV backend.

A better approach might be to capture with a regular backend (I'd
replace the Slingbox with a Hauppauge 1212), and add a feature
where one can designate a backend as "remote", which would cause
its recordings to be automatically migrated to the master.  The
database would be adjusted, so frontends connect to the master
to view the content.  Unfortunately, I have no idea what that might
entail, or whether there would be serious problems, e.g. because data
coming into the master, unlike that from a physical tuner, could be
arriving slower than real time.  Eventually, I (or someone else, using
my HD recorder as a guide) might write a tuner module for Slingbox,
which may be useful to some users, even if they don't care about
placeshifting.

Of course, there may be a better paradigm than either of the two
above; I look forward to your suggestions.

Thanks for reading my long tale of woe, and happy new year to all.

--Stewart