Re: [Mvpmc-devel] MythTV Transcode Proxy libcmyth support

[Chase D. <cha...@gm...>]

On Feb 19, 2009, at 2:50 PM, Tom Metro wrote:
> Chase Douglas wrote:
>> So an MTP-enabled frontend first connects to MTP, then sends the
>> "STARTTLS" message. The server responds "OK", and then the TLS-SRP
>> handshake begins between the frontend and MTP. The STARTTLS message  
>> is
>> required to be the first message unless the connection is for the  
>> video
>> stream data. This is easy to differentiate because the video stream  
>> data
>> connection must begin with the "ANN FileTransfer" message.
>
> If TLS wasn't involved, necessitating the use of a different startup
> handshake and port, how would you envision it working? Could MTP  
> listen
> on the standard port and accept connections from unmodified MythTV  
> clients?

TLS doesn't necessitate a different port. In fact, it's only MTP  
that's enforcing clients to begin with STARTTLS, so TLS can actually  
be made optional, or optional for certain frontend ip ranges.

The two changes that are required right now are the TLS support, the  
message to set the transcoding command, and the message that tells MTP  
what address the frontend reaches it through. As a side note, all of  
this is explained in the wiki page I wrote for this at http://trac.assembla.com/legend/wiki/MythTVTranscodeProxy 
. The TLS support could be made optional, and the transcoding command  
could be set to default to just being passthrough, and MAYBE the  
external address could be skipped around. In reality, this is not  
really necessary as unmodified frontends should just be connecting to  
the master backend instead of MTP. There's nothing to be gained unless  
the frontend can actually talk to MTP to enable its features.

> Probably not relevant to connections made to a back-end over the
> Internet, but have you given any thought to MythTV's protocol for
> discovering back-end servers?

I haven't thought about it, but I don't think it would be too hard.  
I've implemented searching for backends in my MyMote iPhone app  
already, so I don't think it would be a big deal to implement the  
other side :)

>> When the backend responds with information on which backend has the
>> stream, MTP swaps out the backend address in the response with  
>> itself.
>
> That sounds ambitious that you included support for slave back-ends in
> the first cut.
>
> So if the video is on a remote slave, MTP streams it to itself, puts  
> the
> transcoding process in the middle as a filter, and passes it on to the
> client? I gather in all cases then - even for video on the local  
> machine
> - you're using a MythTV back-end to supply the stream, and not  
> accessing
> the file directly.

Correct

> If so, I should revise what I said in the other thread. If the
> transcoding command is viewed as a black box filter, then I guess MTP
> just needs to pass on navigation commands to the actual back-end, and
> the filter will see any jumps reflected in its input stream. (That's
> assuming MythTV implements the jumps without disrupting the video. If
> the video gets stopped and restarted, then you might need to restart  
> the
> filter process.)

See my response in the other thread for more details.

>> Right now, I have the transcode command specified
>> in the unsecured data connection for the video stream. I probably  
>> will
>> change this so that the transcode command is set on a control
>> connection. That way the user has already been authenticated and the
>> command is sent over an encrypted channel.
>
> Better, and perfectly acceptable for a prototype, but the list of  
> users
> permitted to stream video from a back-end - authenticated or not - may
> not be the same users permitted to execute arbitrary commands on the
> back-end.

My initial thought on this is that a list of allowed executables could  
be set. This would include things like ffmpeg, vlc, and mencoder. It  
would be user configurable of course. If someone were really paranoid,  
they could only allow MTP to run in some sort of jail. I don't want to  
get away from freedom to use any program you wish though.

> Ideally, instead of specifying a transcode command, you should extend
> the MythTV protocol to include a client signature command, which might
> include a list of capabilities (resolutions, video formats,  
> bitrates) as
> well as something similar to the Agent header sent by web browsers, so
> the back-end configuration can differentiate between say an iPhone and
> an N810, even if they might have identical capabilities, in case
> platform specific hacks are needed. Then a configuration table used by
> MTP would map from the client signatures to an appropriate transcoding
> command.

That idea has merit. Maybe instead of what I proposed above, MTP could  
have user defined presets. An "iPhone" preset would be my ffmpeg  
command I use in my setup. Instead of my iPhone frontend telling it  
what command to run, it just says to run the iPhone transcoding  
preset. The more I think about it, the more I like this approach.  
Unless someone suggests elsewise, I'll probably implement it this way.

> As I recall the protocol version negotiation process used by MythTV is
> somewhat lame, so this may not be possible, but it would also be ideal
> to leverage that so an MTP-aware client could detect that it was  
> talking
> to MTP and send the extended commands.

I've thought about this as well, especially since an unmodified client  
can't talk to MTP and expect things to just work. I'll certainly do  
something about it though.

I've gone ahead and opened up tickets on trac.assembla.com/legend for  
each of these issues so I don't forget about them.

Thanks