[mythtv] Placeshifting for MythTV?

[Raymond Wagner]

On 12/30/2011 23:31, Stewart Nelson wrote:
> I'm toying with the idea of adding a placeshifting feature to MythTV
> and am writing to ask:

This a topic that has largely been avoided in the past due to legality 
concerns.  Anything that allows transfer of content between two 
independent backends is pretty much out of the question.  Just like how 
there is nothing inherently wrong with bittorrent, anyone with the least 
bit of common sense would realize the primary use of such a capability 
would be for illegal sharing of content between independent users.  
ReplayTV got into hot water a decade ago with just such a feature that 
allowed their units to push content to other units, on the network, and 
more importantly over the internet.

Allowing remote tuners such as a Slingbox are going to come into similar 
issue.  There is a subculture built around sharing Slingbox access 
between different users, and even a few companies to facilitate such, 
even though such actions are violating copyright, and against Sling 
Media's own license agreement.  Now there is nothing preventing someone 
from making their own IPTV headend with a bit of VLC knowledge, but the 
multicast (and thus VPN) requirement would limit its utility some.  
That's besides the fact that a Slingbox tuner would unnecessarily 
degrade the quality of the recording, as well as the issue that 
recording over an unreliable network is simply a bad idea (this includes 
recording over local wireless networks).

Any previous (and likely future) official attempts at place shifting in 
MythTV have been on the opposite side of the equation.  MythTV's most 
basic design strategies are actually based around place shifting.  You 
shift recordings from your backend to your frontend, located at some 
point on the opposite side of the network.  That network can be however 
large you want it to be, spanning one machine, a whole home, a hotel, 
multiple buildings on a property, or even across the internet.  The 
issue is just one of security and bandwidth.

All of Myth's internal streaming is done using the raw, original files.  
If you're recording 16Mbps ATSC content, you need to be able to stream 
such content to your end point.  In order to facilitate seeking, you 
actually want bandwidth several times that of your content, and gigabit 
is noticeably better than even 100mbit in that regard.  You can 
transcode this content ahead of time for reduced bandwidth, but then 
you've lost access to the original high quality source.  There are plans 
to rework much of the internal schema at some point during the 0.26 
development cycle to allow multiple copies against a single recording, 
but that's still a long ways off.

MythTV itself is hideously insecure.  Anyone who knows their way around 
the protocol could push a new executable to the backend and run it, 
compromising the rest of the machine in the process.  Even though MySQL 
has password and endpoint restrictions, it's still a bad idea to put 
that out on the open internet as well.  Since the frontend needs access 
to both, that really limits remote access to being done through a VPN, 
in addition to bandwidth requirements.  Wrapping the backend protocol in 
an authentication and SSL layer would be simple enough, but the hard 
part is the database.  There are plans to migrate the database to an 
embedded thread in the backend, and then proxy all data access by 
frontends and slave backends through the backend protocol, but that is a 
significant undertaking and again, a long way off.

So what is currently possible?  A while back, MythWeb introduced a flash 
streaming mechanism.  It's a fairly crude setup, where a Perl script 
pipes the file through ffmpeg, where it is transcoded to a rather low 
bitrate Sorensen video, and then pumped over the HTTP socket.  It works, 
but it's not pretty, it doesn't handle seeking well, and would likely 
break on an intermittent connection.  Very recently, a replacement 
transcoding interface was added into the new Services API.  The backend 
now supports chunked transcoding and streaming, currently demo'd in 
videos of an iPad application being written by Robert McNamara.  A new 
HTML5/flash frontend to this is planned for MythWeb for the 0.25 release.