[mythtv] IPTV solution project, anyone?

[Robert Johnston]

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.

So, does anyone like this idea? Or do you think it's all a waste of time?

Answers on a e-mail, and flames to /dev/null... No, wait, it's full! :)
--
Robert "Anaerin" Johnston