[mythtv] IPTV solution project, anyone?

[Jun Yu]

Looks interesting, I definitely will check it out. Thanks for the lead.

Jun

On 12/6/05, Michael Haas <hansi.urpils at gmail.com> wrote:
>
>
>
> On 12/6/05, Robert Johnston <anaerin at gmail.com > wrote:
>
> > On 12/6/05, Jun Yu <junyuu at gmail.com> wrote:
> > > Sorry if it is OT.
> > >
> > > Back a while ago there was a short discussion about adding iptv client
> >
> > > function to the front end. My problem back then was how can it be
> > tested and
> > > used with no outlet in US where I live.  A litter dig brings more
> > questions
> > > than answers but al comes down to a simple one: is there a standard as
> > how
> > > IPTV should be implemented?  I couldn't find any.  Even there is one,
> > what
> > > is the chance that SBC or Verizon will follow it? I would say next to
> > none.
> > > So here I will try again to bring it up: Let's start project to build
> > a
> > > complete IPTV solution with backend management node, streaming node,
> > routing
> > > node, and client (plug in for myth forntend). Most of the
> > functionality can
> > > be borrowed from other projects like videolan; multicast is supported
> > by
> > > Linux, what left are the management parts: content, schedule, user
> > > management and client.
> > >
> > > The usage? It can be  used as a way to share the recording and central
> > > stored media files among different platforms, include handhold
> > devices, a
> > > small community where media file can be shared, a college campus TV
> > station,
> > > and so on if we have a window client ready which is there already if
> > you
> > > know videolan.
> > >
> > > Why not steam on demand? Heavy load on the server means more money
> > spend,
> > > frustrating user when not being able to connect, less efficient use of
> >
> > > bandwidth, confusing with too many choices, and not trendy - J
> > >
> > >
> > >
> > > Anyway, let's talk if you are interested or want your opinion being
> > heard.
> >
> > Y'know, with the talk of this, and UPNP Media services going on, it
> > sounds like we're going to start having "Connectors" for Myth. That
> > is, other programs that use LibMyth to communicate with the backend
> > servers and provide "Services" (Like a Myth->UPNP gateway, a
> > Myth->IPTV gateway, an IPTV->Myth gateway, you get the idea).
> >
> > Perhaps there could be more scope to make Myth more Modularised (A
> > "Tuner" Module, a "Program Guide Data" Module, a "Playback" Module,
> > and so on), so that an IPTV "Tuner" (Say) can be added in without
> > having to shuffle the whole of the Myth Sourcecode to make it fit.
> > Kind of like the way Winamp/XMMS does Plugins for Input, output,
> > visualisation, and expand that concept. That way Myth can be opened up
> > a lot more for development, and changes to one area don't have to kill
> > the whole of the tree (DVB/EIT changes, for example. There you'd have
> > a DVB "Input" plugin, and an EIT "Program Guide Provider" plugin). It
> > would also mean that diffrent types of input cards (DVB-S, DVB-T,
> > CI/CAM, IPTV, UPNP, and the rest of the alphabet soup) can be added
> > and removed from a system easily, and that chunks of code that aren't
> > needed in a particular configuration can be removed completely (So if
> > you're building a DVB-Based backend, you grab the DVB, EIT, and
> > Backend Core packages/sources, and just build those).
> >
> > You could even have different "Storage Backends", so your Myth box
> > could support streaming archived shows to/from Tape Backup, or
> > DVD-Recorders.
> >
> > This will, however, require modularity, and a rock-solid API to hang
> > all this functionality from.
> >
> > I know this suggestion would make for a lot of work, especially in the
> > short-term, but I believe it would be worth it. Using ZeroConfig (Or
> > UPNP, or something similar), all these services could discover each
> > other, and arrange themselves into a logical and sensible format.
> >
> > --
> > Robert "Anaerin" Johnston
> >
> >
>
> Hello!
>
> I'm afraid I won't be much of a help regarding the implementation of IPTV,
> mainly because I can't write a single line of code :). However, I'd like to
> bring your attention to a project called NMM. This abbreviation stands for
> "network-integrated multimedia middleware" and it sounds very promising.
> Here is a  (quite long, sorry) quote from
> http://www.networkmultimedia.org/NMM/Status/index.html :
>
> These [ networked multimedia] devices offer high-quality input and output
> > capabilities often together with enough computing power and programmability
> > to perform a variety of multimedia operations. However, integrating and
> > controlling these distributed devices from an application is difficult
> > because of the variety of underlying technologies.
> > We are currently developing a network-integrated multimedia middleware.
> > Our architecture allows for a flexible usage of different networking
> > technologies and offers the extensibility to transparently use various
> > existing infrastructures. Distributed devices can be discovered, inspected,
> > and then integrated into a common media processing graph.
>
>
>
> Check it out at http://www.networkmultimedia.org
>
> Best regards,
>
> Michael 'laga' Haas
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20051207/0a100541/attachment.htm