[mythtv] UPnP server and transcoding

[Jeremy Palenchar]

> -----Original Message-----
> From: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-
> bounces at mythtv.org] On Behalf Of David Blain
> Sent: Wednesday, October 07, 2009 12:37 PM
> To: 'Development of mythtv'
> Subject: Re: [mythtv] UPnP server and transcoding
> 
> > I guess my thinking about using one of the other libraries is that
> they
> may
> > be much farther along than we are and we could gain by leveraging
> their
> work
> > and focus on uPnP. I am thinking about full implementation of the
> spec,
> > testing, etc.
> >
> > Perhaps we could change libmythpnp to be the glue between myth and
> their
> > framework instead of doing all of the uPnP heavy lifting ourselves.
> >
> >
> > -Jeremy
> 
> I'm the original developer of the uPnP support.
> 
> I still have plans to extend it to be fully DLNA compliant, but life
> has had
> other plans for the last couple years.
> 
> The idea of on the fly transcoding isn't new and you should keep in
> mind
> that it's not technically part of the uPnP spec.  As others have
> stated, the
> backend has all the pieces needed, they just need someone to take the
> time
> to code it.
> 
> I originally created the protocol stack from scratch for a few reasons:
> 
>   * There was a push to reduce dependencies on outside libraries.
>   * Potential incompatible license issues.
>   * It would be a tighter integration since I was creating it with
> mythbackend in mind.
>   * And ultimately, I wanted to have fun coding it (I learned a lot
> doing
> it).
> 
> One of these days, my life will afford me some free time and I will
> dive
> back in, but ultimately the other devs and Chutt have the final say if
> we
> ditch what we have and replace it with an external library.
> 
> Just my 2 cents.
> 
> David Blain
> 

Thanks for the input David,

Would you consider migrating over to one of the other stacks if the
licensing is compatible or do you think the native stack is still the right
approach?

I looked at the uPnP specs a little bit yesterday and there is a lot that
needs to be done in terms of state handling and message responses in order
to be compliant. I would think it would be easier to offload all of that
work to a team dedicated on building uPnP functionality.

-Jeremy