MythTV Transcode Proxy libcmyth support

[Chase Douglas-4]

As stuart has noted, I've been working on a side project called MythTV  
Transcode Proxy. You can follow the discusson on the mythtv-users  
mailing list if you like.

I wanted to point out my git repo which has all of the changes I made.  
These include support for:

* OS X (mac and iPhone)
* GnuTLS TLS-SRP authentication and encryption of connections through  
MTP
* On the fly transcoding of live tv and recordings (recordings is not  
quite functional in MTP, just haven't gotten to it yet)
* SSL based MySQL connections, client certificates may be used  
(there's also support for getting a client certificate from MTP  
through an encrypted connection)

This was all done for my own project to make an iPhone frontend. I  
completely understand if the mvpmc developers do not want to pull my  
changes as some of them require my unofficial MTP server to be fully  
functional. However, the OS X and SSL based MySQL connections are  
wholly independent of MTP and can be merged without issue. Also, the  
MTP-based changes do not harm normal libcmyth functionality without an  
MTP server.

You can find the git repo at:

git clone git://git.assembla.com/legend.git

A full diff of my changes can be seen at:

http://trac-git.assembla.com/legend/changeset?new=%4043280ec014a147b5f4b5066f18577287c784cd5a&old=%40949b18a034526d5c985c6d139df825f140919ad4

I appreciate any comments and suggestions you may have.

Thanks,
Chase Douglas

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[stuart-20]

Chase Douglas wrote:

> As stuart has noted, I've been working on a side project called MythTV  
> Transcode Proxy. You can follow the discusson on the mythtv-users  
> mailing list if you like.
>
> I wanted to point out my git repo which has all of the changes I made.  
> These include support for:
>
> * OS X (mac and iPhone)
> * GnuTLS TLS-SRP authentication and encryption of connections through  
> MTP
> * On the fly transcoding of live tv and recordings (recordings is not  
> quite functional in MTP, just haven't gotten to it yet)
> * SSL based MySQL connections, client certificates may be used  
> (there's also support for getting a client certificate from MTP  
> through an encrypted connection)
>
> This was all done for my own project to make an iPhone frontend. I  
> completely understand if the mvpmc developers do not want to pull my  
> changes as some of them require my unofficial MTP server to be fully  
> functional. However, the OS X and SSL based MySQL connections are  
> wholly independent of MTP and can be merged without issue. Also, the  
> MTP-based changes do not harm normal libcmyth functionality without an  
> MTP server.
>
> You can find the git repo at:
>
> git clone git://git.assembla.com/legend.git
>
> A full diff of my changes can be seen at:
>
> http://trac-git.assembla.com/legend/changeset?new=%4043280ec014a147b5f4b5066f18577287c784cd5a&old=%40949b18a034526d5c985c6d139df825f140919ad4
>
> I appreciate any comments and suggestions you may have.
>
> Thanks,
> Chase Douglas
>
> ------------

Hi Chase...

I grabbed a copy of your mvpmc repo.  Are there other changes necessary
to make the mvpmc project compile?  I'm building on a Fedora9 machine.
I could switch to a Debian Unstable machine if that would help.



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Chase Douglas-4]

On Feb 17, 2009, at 7:31 PM, stuart wrote:

> Chase Douglas wrote:
>> As stuart has noted, I've been working on a side project called  
>> MythTV  Transcode Proxy. You can follow the discusson on the mythtv-
>> users  mailing list if you like.
>> I wanted to point out my git repo which has all of the changes I  
>> made.  These include support for:
>> * OS X (mac and iPhone)
>> * GnuTLS TLS-SRP authentication and encryption of connections  
>> through  MTP
>> * On the fly transcoding of live tv and recordings (recordings is  
>> not  quite functional in MTP, just haven't gotten to it yet)
>> * SSL based MySQL connections, client certificates may be used  
>> (there's also support for getting a client certificate from MTP  
>> through an encrypted connection)
>> This was all done for my own project to make an iPhone frontend. I  
>> completely understand if the mvpmc developers do not want to pull  
>> my  changes as some of them require my unofficial MTP server to be  
>> fully  functional. However, the OS X and SSL based MySQL  
>> connections are  wholly independent of MTP and can be merged  
>> without issue. Also, the  MTP-based changes do not harm normal  
>> libcmyth functionality without an  MTP server.
>> You can find the git repo at:
>> git clone git://git.assembla.com/legend.git
>> A full diff of my changes can be seen at:
>> http://trac-git.assembla.com/legend/changeset?new=%4043280ec014a147b5f4b5066f18577287c784cd5a&old=%40949b18a034526d5c985c6d139df825f140919ad4
>> I appreciate any comments and suggestions you may have.
>> Thanks,
>> Chase Douglas
>> ------------
>
> Hi Chase...
>
> I grabbed a copy of your mvpmc repo.  Are there other changes  
> necessary to make the mvpmc project compile?  I'm building on a  
> Fedora9 machine. I could switch to a Debian Unstable machine if that  
> would help.

I couldn't tell you in regards to the mvpmc project. The only reason I  
have a git repo with the whole mvpmc source is that you can't pull  
just the include and libs/libcmyth directories alone.

If you are wanting to know how to build the libcmyth library alone,  
then all you have to do is go into the libs/libcmyth dir and compile  
all the objects you like and link them together into the object file  
format of your choice. You'll need to add -I../../include as a  
compiler flag so it can see the include files though. That's basically  
what I have Xcode do for me when I build it.

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[stuart-20]

Chase Douglas wrote:

> On Feb 17, 2009, at 7:31 PM, stuart wrote:
>> Chase Douglas wrote:
>>> As stuart has noted, I've been working on a side project called
>>> MythTV  Transcode Proxy. You can follow the discusson on the
>>> mythtv-users  mailing list if you like.
>>> I wanted to point out my git repo which has all of the changes I
>>> made.  These include support for:
>>> * OS X (mac and iPhone)
>>> * GnuTLS TLS-SRP authentication and encryption of connections
>>> through  MTP
>>> * On the fly transcoding of live tv and recordings (recordings is
>>> not  quite functional in MTP, just haven't gotten to it yet)
>>> * SSL based MySQL connections, client certificates may be used  
>>> (there's also support for getting a client certificate from MTP  
>>> through an encrypted connection)
>>> This was all done for my own project to make an iPhone frontend. I  
>>> completely understand if the mvpmc developers do not want to pull my  
>>> changes as some of them require my unofficial MTP server to be fully  
>>> functional. However, the OS X and SSL based MySQL connections are  
>>> wholly independent of MTP and can be merged without issue. Also, the  
>>> MTP-based changes do not harm normal libcmyth functionality without
>>> an  MTP server.
>>> You can find the git repo at:
>>> git clone git://git.assembla.com/legend.git
>>> A full diff of my changes can be seen at:
>>> http://trac-git.assembla.com/legend/changeset?new=%4043280ec014a147b5f4b5066f18577287c784cd5a&old=%40949b18a034526d5c985c6d139df825f140919ad4 
>>>
>>> I appreciate any comments and suggestions you may have.
>>> Thanks,
>>> Chase Douglas
>>> ------------
>>
>> Hi Chase...
>>
>> I grabbed a copy of your mvpmc repo.  Are there other changes
>> necessary to make the mvpmc project compile?  I'm building on a
>> Fedora9 machine. I could switch to a Debian Unstable machine if that
>> would help.
>
> I couldn't tell you in regards to the mvpmc project. The only reason I
> have a git repo with the whole mvpmc source is that you can't pull just
> the include and libs/libcmyth directories alone.
>
> If you are wanting to know how to build the libcmyth library alone, then
> all you have to do is go into the libs/libcmyth dir and compile all the
> objects you like and link them together into the object file format of
> your choice. You'll need to add -I../../include as a compiler flag so it
> can see the include files though. That's basically what I have Xcode do
> for me when I build it.

Hi Chase...

Forgive me, I'm trying to understand your work in my spare (ha!) time.
Briefly, from what I gathered so far, you added a char *trancode
argument which, I assume, should literally contain the transcoding
command necessary for a given client.  The line in your wiki which
starts "ffmpeg -i - -async 10..." is such an example, correct?



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Chase Douglas-4]

On Feb 18, 2009, at 9:37 AM, stuart wrote:

> Chase Douglas wrote:
>> On Feb 17, 2009, at 7:31 PM, stuart wrote:
>>> Hi Chase...
>>>
>>> I grabbed a copy of your mvpmc repo.  Are there other changes  
>>> necessary to make the mvpmc project compile?  I'm building on a  
>>> Fedora9 machine. I could switch to a Debian Unstable machine if  
>>> that would help.
>> I couldn't tell you in regards to the mvpmc project. The only  
>> reason I have a git repo with the whole mvpmc source is that you  
>> can't pull just the include and libs/libcmyth directories alone.
>> If you are wanting to know how to build the libcmyth library alone,  
>> then all you have to do is go into the libs/libcmyth dir and  
>> compile all the objects you like and link them together into the  
>> object file format of your choice. You'll need to add -I../../
>> include as a compiler flag so it can see the include files though.  
>> That's basically what I have Xcode do for me when I build it.
>
> Hi Chase...
>
> Forgive me, I'm trying to understand your work in my spare (ha!)  
> time. Briefly, from what I gathered so far, you added a char  
> *trancode argument which, I assume, should literally contain the  
> transcoding command necessary for a given client.  The line in your  
> wiki which starts "ffmpeg -i - -async 10..." is such an example,  
> correct?

Yep. No need for forgiveness either :). I'm happy to help and look  
forward to others trying out the code.

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Tom Metro-9]

Chase Douglas wrote:
> ...I've been working on a side project called MythTV  
> Transcode Proxy.
>
> * On the fly transcoding of live tv and recordings (recordings is not  
> quite functional in MTP, just haven't gotten to it yet)

Sounds terrific. We've been talking about doing something like that for
years.

Can you explain the mechanics of how your proxy injects itself into the
  middle of the MythTV protocol connection? I gather a side effect of
your choice to use encrypted sockets is that you're listening on a
different port number.


> * SSL based MySQL connections, client certificates may be used  
> (there's also support for getting a client certificate from MTP  
> through an encrypted connection)

Aside from certificate retrieval, what did you have to implement to
support this? Doesn't MySQL offer built-in SSL or TLS support? Or were
all the changes on the client side?


stuart wrote:
> As I was just searching for a trancode command suitable for Chase's
> recent lib changes for the mvpmc box.
>  
> ffmpeg -i source.mpg -target pal-svcd -vcodec copy output.mpg

Is that specified on the client side? That seems to imply the client can
have the proxy execute an arbitrary command, which seems rather
dangerous. OK for a prototype, but something that ought to get
refactored to a set of fixed choices or similar.

Also, I had assumed given this was an on-the-fly transcoding that VLC
was going to be involved. Are the ffmpeg codecs up to the task of
real-time transcoding? Does this mean the hardware used for MTP needs to
be faster than what would suffice for a similar VLC setup?

  -Tom

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Chase Douglas-4]

On Feb 18, 2009, at 6:31 PM, Tom Metro wrote:

> Chase Douglas wrote:
>> ...I've been working on a side project called MythTV  Transcode  
>> Proxy.
>> * On the fly transcoding of live tv and recordings (recordings is  
>> not  quite functional in MTP, just haven't gotten to it yet)
>
> Sounds terrific. We've been talking about doing something like that  
> for years.
>
> Can you explain the mechanics of how your proxy injects itself into  
> the  middle of the MythTV protocol connection? I gather a side  
> effect of your choice to use encrypted sockets is that you're  
> listening on a different port number.

The point of MTP is to enable the features it has, but also to do so  
as seamlessly as possible. That means using the same connection  
scheme. All connections to the master backend (which is where all  
frontend connections to a systems start) should begin on the same  
backend port. 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.

As for the rest of the proxy implementation, MTP listens to the  
packets as they go between the frontend and the backend. For instance,  
when the frontend requests a live tv stream, MTP sees the request and  
flags it. When the backend responds with information on which backend  
has the stream, MTP swaps out the backend address in the response with  
itself. The key is that every slave backend connection goes through a  
separate MTP port. This allows MTP to figure out the destination  
backend for the connection from the frontend. If the connection is on  
the main MTP port, then MTP proxies the connection to the master  
backend. If the connection is on a secondary port, then the connection  
is proxied to the correct slave backend. (In effect, MTP is sort of  
spawning separate versions of itself for every backend in the system  
in a lazy way).

>> * SSL based MySQL connections, client certificates may be used  
>> (there's also support for getting a client certificate from MTP  
>> through an encrypted connection)
>
> Aside from certificate retrieval, what did you have to implement to  
> support this? Doesn't MySQL offer built-in SSL or TLS support? Or  
> were all the changes on the client side?

MySQL suports TLS/SSL support out of the box in most distributions.  
You just have to enable it in the configure stage. I just added the  
ability to specify TLS/SSL connections through libcmyth. You don't  
even have to provide a client certificate if you don't want to.

> stuart wrote:
>> As I was just searching for a trancode command suitable for Chase's
>> recent lib changes for the mvpmc box.
>> ffmpeg -i source.mpg -target pal-svcd -vcodec copy output.mpg
>
> Is that specified on the client side? That seems to imply the client  
> can have the proxy execute an arbitrary command, which seems rather  
> dangerous. OK for a prototype, but something that ought to get  
> refactored to a set of fixed choices or similar.

That is a good point. 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.

> Also, I had assumed given this was an on-the-fly transcoding that  
> VLC was going to be involved. Are the ffmpeg codecs up to the task  
> of real-time transcoding? Does this mean the hardware used for MTP  
> needs to be faster than what would suffice for a similar VLC setup?

This is exactly why I have the transcoding process be a completely  
open ended matter. Some people will find VLC is best for them. Others  
mencoder. For my iPhone frontend, I've found that ffmpeg is the best  
due to the special formatting needed.

Thanks for the questions!

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Tom Metro-9]

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?

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?


> 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.

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.)


> 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.

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.

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.


> Thanks for the questions!

Thanks for the answers! :-)  And the code.

 -Tom

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel

[Chase Douglas-4]

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

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mvpmc-devel mailing list
Mvpmc-devel@...
https://lists.sourceforge.net/lists/listinfo/mvpmc-devel