[opendtv] Re: Mini-ITX and TV over IP Was: RE: Re: How important are new Codecs wrt OTA Broadcasting?
- From: "Silvio Macedo" <s.macedo@xxxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Fri, 24 Feb 2006 13:16:27 -0000
Kon, as usual, I find your emails very interesting and informative.
Thank you.
Not wanting to make this thread off-topic, going into Linux details,
or say more than I should, it would appear to me that you/your team
have/had more experience with the reality of time-to-market and
hardware deployment than time to develop/tune the OS. EVERY single
technical issue you raised is really a non-issue, given enough
know-how and time, which we have, contrary to good video hardware
drivers (on mini-itx boards) which we don't... but hey, you've done it
- I haven't, so...let's see.
Nevertheless, your warnings on the lack of scalability of a commercial
solution, are appreciated.
Regards
Silvio
> -----Original Message-----
> From: opendtv-bounce@xxxxxxxxxxxxx=20
> [mailto:opendtv-bounce@xxxxxxxxxxxxx] On Behalf Of Kon Wilms
> Sent: 24 February 2006 01:43
> To: opendtv@xxxxxxxxxxxxx; opendtv@xxxxxxxxxxxxx
> Subject: [opendtv] Re: Mini-ITX and TV over IP Was: RE: Re:=20
> How important are new Codecs wrt OTA Broadcasting?
>=20
>=20
> > - firstly, Directed Channel Change is archaic compared with what
we
> > are doing - not only can we personalise each terminal=20
> content (or use
> > advanced profile matching to generate a customised playlist,
target
> > the audience, location, peak time, etc), but also we are
introducing
> > feedback via webcam, and other sensors - real-time. - remember,
this
> > is corporate TV, not home tv.
>=20
> Call it directed playlist change then. The point is remote commands
to
> the STB - DCC is just one example. Our system does the same=20
> things, but
> we still need DCC as a feature. You cannot discount its usefulness
if
> you need to force STBs to watch certain content (and=20
> corporate TV users
> are always the first to want this i.e. at 5pm we need to make sure
all
> users are watching the CEO's broadcast/clip/whatnot).
>=20
> > - secondly, most routers in the field are Linux - TiVO runs Linux.
I
> > don't exactly understand your point. Stock linux - no.. maybe
not...
> > but, it's easy and cheap to adapt Linux to our goals.Our=20
> only problems
> > are with hardware decoding acceleration being better=20
> supported on Win
> > than on Linux.=3D20
>=20
> Tivo is so far from stock linux you can't even compare the=20
> two. My point
> is that an off the shelf OS comes with issues and bloat that is
> completely irrelevant for STB usage. You are essentially wasting
CPU,
> storage and memory by using an off the shelf OS.
>=20
> Its very easy to just slap hardware together and roll out a=20
> product but
> the real test comes in reducing the price and making the system
stable
> and managable from the headend and the receiver.
>=20
> Development time is cheap, yes. But hardware costs and management
are
> the opposite when you run in this mode. You can't reduce the
hardware
> costs by taking this approach.
>=20
> > - updating - all sorts of - codecs, drivers, the entire install if
> > needed, is very very easy with one of the countless utils for
this
> > sort of mass deployment and managing. Mass admin is also=20
> quite simple
>=20
> On a two-way network perhaps. But once again - have you tried=20
> this with
> a thousand units in the field?
>=20
> How do you guarantee your update will work? Standard OS=20
> installs have no
> concept of a backup version of self to roll back to if the system
> reboots and comes up corrupted.
>=20
> > - remote diagnostics, etc
>=20
> Only with a two-way network. But that isn't an advantage, you can do
> this with embedded or stripped-down STBs too.
>=20
> > - reliability - fanless and solid state memory /or network
booting..
>=20
> Network booting? Maybe for a handful of units.
>=20
> And how much solid state memory did you need for that=20
> non-stripped down
> XP or linux distro? Even if you do strip it down, what are you
using?
> Cramfs? Jffs? You can't just write infinitely to solid state...
>=20
> > plus a disk for caching content - prone to mechanical=20
> failure (as much
> > as a laptop)...
>=20
> Moot point.
>=20
> > Well, and then, there are all the advantages that I don't have to
> > mention...
>=20
> Windows viruses, hackers owning your OTS linux boxen (OTS=20
> linux STBs are
> a hacker's wet dream, since the user can only fight back with a
remote
> control)... ;)
>=20
> I've been down the path of loading the standard OS on a system and
> slapping some GUI and simple backend hooks on it to make it appear
to
> run as a STB. This works until you need to roll out a lot of units.
> Thats when it falls apart. I have seen this happen so many times in
> datacasting/iptv systems that at this point I will basically=20
> guarantee it.
>=20
> Cheers
> Kon
>=20
> =20
> =20
>
----------------------------------------------------------------------
> You can UNSUBSCRIBE from the OpenDTV list in two ways:
>=20
> - Using the UNSUBSCRIBE command in your user configuration=20
> settings at FreeLists.org=20
>=20
> - By sending a message to: opendtv-request@xxxxxxxxxxxxx with=20
> the word unsubscribe in the subject line.
>=20
>=20
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
