[mythtv] "New" Feature: RTSP streaming for myth backend
devan.lippman at gmail.com
Tue Feb 21 18:05:08 UTC 2006
On 2/17/06, Stormboy <stormboy at stormboy.com> wrote:
> belcampo wrote:
> >>> Some probably interesting alternatives upnp at
> >>> https://sourceforge.net/forum/?group_id=89768 or
> >>> http://www.cybergarage.org/
> >>> if things are compiled with all dependicies one can run 'mediagate --mythtv'
> >>> and with upnp devices like networked dvd-players or vlc with upnp compiled in
> >>> you can access all myth recorded stuff 'everywhere'. Searching for upnp in
> >>> this list gives you more people which are interested in these features
> >>> _______________________________________________
> >>> mythtv-dev mailing list
> >>> mythtv-dev at mythtv.org
> >>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> I am not sure how you jumped from RTSP to UPnP. UPnP is something that
> can sit aside RTP and RTSP.
> RTP is a protocol for transmitting and receiving media (i.e. a transport
> protocol). RTSP is a protocol for controlling a stream, and may use
> RTP for the transport protocol. See http://en.wikipedia.org/wiki/RTSP
> UPnP (http://upnp.org/) is a standard for discovering devices and how to
> communicate with those devices, and includes a set of standards for what
> the device services specifically are.
> There are at least 2 UPnP standards that will be relevant to making
> MythTV available as a UPnP device: the Media Server and Media Renderer
> (http://upnp.org/standardizeddcps/mediaserver.asp). MythTV could also
> act as a Control Point, allowing a user to select media located on a
> Media Server and control the playback of media on a Media Renderer.
> The MediaServer has a Content Directory service that allows clients to
> browse and search for media content on the server. It will also need
> some sort of services to deliver that content.
> The way media is delivered from the Media Server to the Media Renderer
> is open. Currently most UPnP Media Renderers can receive media content
> over HTTP, and most Media Servers can transmit over HTTP. However,
> delivering the media content over RTP is allowed as long as the server
> and renderer support it. RTP is a preferred method for delivering media
> for a few reasons. You may multicast the stream so that no additional
> bandwidth is used when delivering the same stream to multiple clients.
> Furthermore, there is less overhead in delivering the stream (it can use
> UDP). Additionally, a control packets may be examined to determine how
> well the stream is being received. You may synchronized many streams.
> I am sure you can think of more.
> If MythTV can support these, it will integrate with a greater set of
> audiovisual equipment.
> I am currently looking into this for integrating distributed home
> entertainment, security and home automation. The project I am working
> on has a bit to give to MythTV users if MythTV is to go UPnP (both
> server and renderer), even more if it incorporates RTP (and RTSP).
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
Admittedly I jumped into this idea without much background in this.
I've been reading up on this and it looks like It would make more
sense to just try for RTP/RTCP before going with RTSP? Also, seeing
how the livemedia library comes with an application for multicasting
mpeg2 AV over RTP seems like this won't take long to get done. I was
hoping there might be someone out there that can save me some time
looking for where the transfer between the frontend and backend
occurs? Getting all these command protocols (including mythprotocol)
to play together in a neat package ought to be fun. :)
Also on a seemingly unrelated note is there someone out there that can
answer an IGMP question? Seems like in the case of networking
equipment everything needs to support IGMP, linux is an easy one but
what about the home networking structure. Will home switches know how
to pass these messages or should I start looking into other solutions?
Devan Lippman <devan at lippman dot net>
More information about the mythtv-dev