Java to Appear in Next-Gen DVD players

Ivan P. writes "Sun Microsystems's Java technology will be built into Blu-ray DVD players, executives said on Monday during Sun's JavaOne trade show, a development that advances the technology in the consumer electronics market for which Sun originally developed the software. 'Java will be used for control menus, interactive features, network services and games,' said Yasushi Nishimura, director of Panasonic's Research and Development Company of America. 'This means that all Blu-ray Disc player devices will be shipped equipped with Java.'" Next stop, annoying Flash intros.

Comments

Microsoft vs. Sun

[DosBubba]

Microsoft's codec is in the HD-DVD spec

thank god

[MatD]

That means it will take about a week for someone to write a crack to bypass all those annoying trailers we have to watch before we can actually watch the dvd we payed for.

Re:thank god

[nomadic]

Though how are you going to get the crack onto the machine? Unless they allow firmware changes via CD?

Re:thank god

[pete-classic]

We don't have to watch 'em. "mplayer dvd://" usually gets us right to the feature!

-Peter

Re:thank god

[Anonymous Coward]

I like those trailers, they give me time to find the hand creme between the cushions and get my towel.

Re:thank god

[delus10n0]

There is also the _free_ DVD43 program.

Re:thank god

[den_erpel]

Oh god, that's the vitamine B complex and porteins that Roosta was talking about to Zaphod.

Gives a whole new meaning to "Every man should know where his towel is".

Re:thank god

[RDW]

You might find these pages useful:
http://www.dvd-replica.com/DVD/vmcommands.php
http://www.dvd-replica.com/DVD/vmcmdset.php
http://dvdlab.wikicities.com/wiki/Commands
(brief descriptions of the current DVD VM commands).

Re:thank god

[-brazil-]

sigh

Correction: Java has not exploitable buffer overflows, because arrays have a fixed size and any array access is checked against that size, so attempts to write beyond the end of the array result in an ArrayIndexOutOfBoundException rather than smashing the stack. Most other common (in C) forms of exploits don't exist because there is no pointer arithmetic.

Great! (Not)

[jamesbromberger]

Now my DVD player is going to be slow to respond to UI, just like my mobile phone is now. Next they'll be putting Windows Mobile on these things too, and it will take 45+ seconds to 'boot' the damn thing, like with the Orange C500 phones....

Re:Great! (Not)

[spinozaq]

This is 'Insightful'?! This is a troll to start Java is slow because applets are stupid war. Java is a platform. Code it how you will. It's obviously a damn good platform considering its extremely wide spread use despite strong arm tactics by its competitors.

Re:Great! (Not)

[Osty]

Well, my TIVO has the Linux O/S and it's as slow as christmas. It ain't got anything to do with the UI you idiot, it's the speed of the CPU in the thing.

In Tivo's case, it actually is Java. The interface used to be very quick and snappy. Then they decided to push the Home Media Option out to all users, and the same quick, responsive UI has now slowed down to a horrible crawl. The hardware didn't change at all, only the software.

As for the poster making the crack about putting Windows Mobile on a box, Microsoft already has a program with Comcast and Motorola where the HD DVR box Comcast offers uses Microsoft technology. I have no idea if it's WinCE-based or Windows XP Embedded-based, but it's very quick and responsive compared to my now-sluggish Tivo. It doesn't have all of the searching and filtering features of Tivo (I wish it at least had thumbs-up/down), but it has a more responsive UI and records HD streams so I use it much more than my Tivo (relegated to my bedroom TV and a basic cable feed).

Re:Great! (Not)

[pivo]

In Tivo's case, it actually is Java. The interface used to be very quick and snappy. Then they decided to push the Home Media Option out to all users

The problem with your reasoning is that the quick and snappy UI was also in Java.

Re:Great! (Not)

[JebusIsLord]

a) Java was DESIGNED for embedded systems, first and foremost. That's why it is hardware-agnostic; because it allows the hardware makers to throw in whatever chips are cheap in bulk at the time, change on a whim, and still push out the same upgrade to everyone. Being cross-platform in the MacOS/Linux/Windows way was just sort of a side-effect. Think about how much this will benefit set-top manufacturers!!

b) Java isn't interpreted anymore... its just-in-time compiled and then executed as native code. A bit of a start-up pause while the classes compile, that's all.

Re:Great! (Not)

[Decaff]

b) Java isn't interpreted anymore... its just-in-time compiled and then executed as native code. A bit of a start-up pause while the classes compile, that's all.

These days it is even better than that. There is no start-up pause for compilation. The VM starts interpreting bytecode immediately, while the Hotspot profiler thread starts looking for sections of code to translate to very highly optimised native code.

Re:Great! (Not)

[SewersOfRivendell]

Show me a set-top box running off a battery.

Java actually wasn't designed for generic 'embedded systems', it was designed for set-top boxes, but it was apparently too expensive for the prospective customers.

So this was Gosling's original intent. I don't know whether it's good or bad that it's now fulfilling that intent. I'd rather see Ruby in the standard, it'd be a lot easier to work with (and cheaper to license).

Re:Great! (Not)

[-brazil-]

Nope, it's you who's confused. Java has made use of JIT compilers since at least version 1.2. The platform independent bytecode (Java .class files) is compiled to platform-dependant machine code while it runs. At first this was done to all the code, which increased startup delays a lot, nowadays only the frequently-executed code (on a per-method basis) is JIT-compiled, the rest is indeed interpreted, which gets you the best of both worlds.

Re:Great! (Not)

[rjshields]

Really? It's not interpreted anymore??? I was under the impression that java has had a virtual machine ever since it was designed

You seem to be under the incorrect impression that the presence of a virtual machine means interpreted code.

I think you may possibly be confused with javascript

It's quite obvious to me and anyone with an ounce of sense that the grandparent is *not* talking about Javascript.

The future is now.

[JonLatane]

Next stop, annoying Flash intros.

I believe they're already essentially here, in the form of previews - some of which are unskippable - before you can even get to the menu. (Not Flash, but obviously still something very, very wrong.)

Look on the bright side...

[Will_Malverson]

Next stop, annoying Flash intros.

Well, at least they'll take up less space than the current annoying MPEG2 intros...

games on dvd player

[clockwise_music]

Does this mean I can run NetHack on my new DVD player?

Re:games on dvd player

[rockola]

Does this mean I can run NetHack on my new DVD player?

Sure it does, immediately after you've rewritten all of NetHack in Java. Best of luck.

Re:games on dvd player

[rnx]

shameless plug:
http://keye.phk.at/ would translate rather nicely to a dvd player + remote as it was written for mobile phones. we'd only need to cater to a higher resolution.

Misconceptions, as usual

[Anonymous Coward]

Next stop, annoying Flash intros. Sigh... how this relates to java is beyond me... java is actually a very powerful language that drives alot of enterprise solutions and embedded systems. People always confuse java with java applets, or for some reason think java is crap. I used to too, before I got to know the language better. Oh, do I like Ruby or python better? Sure. But that doesnt remove the fact that java is here to stay and has proven itself more than enough in the enterprise. So why slashdot's hostility towards it remains is beyond me. I've seen large scale systems attempted to be developed in perl and believe me... that doesnt work well at all! :)

Re:Misconceptions, as usual

[Decaff]

Because Java is slow, takes a lot of processor cycles,

As shown by Linpack benchmarks run last year, Java can run at up to 95% of the speed of optimised C++.

and eats memory like there's no tomorrow.

Embedded Java systems can run in as little as a few hundred KB of memory.

This is going to seriously hinder blu-ray adaption.

Just as the use of Java on mobile phones has (not) hindered the production of Java games and applications for those phones?

A Java implementation means at least 30% more processor power and memory than otherwise needed.

Why not look at the real situation and not present a years-old outdated view of Java?

Re:Misconceptions, as usual

[Agent_9191]

With a great many applications all your have to do to make a Java application an applet is change the signature from

public static void main(String[] args)

to

init()

, derive from the Applet class and you have an applet. That is part of the appeal of Java, it really is easy to migrate the code to any environment.

Re:Misconceptions, as usual

[Decaff]

Aw, come on. Don't use some obscure, rare example as a means of "proving" that java is good. Look at the majority of software out there that's written in java. It just plain sucks.

Ok. Let's take an obscure rare example like... E-Bay!

The entire site is written in Java. It is one of the most high-performance, reliable and successful websites ever written. Your bank uses Java. All major stock exchanges (with tens of thousands of transactions per second) use Java.

It takes forever to fire up due to the VM,

Java 1.5 now has VM start-up times in a few hundred milliseconds at most.

is sluggish on GUI response,

Not now. Have you tried Swing or SWT on Java 1.5?

and soaks up RAM like a sponge (near 300MB of RAM to use the iPlanet web server admin interface?? WTF!?)

So don't use the iPlanet Web server.

Face it, java may offer some advantages to the programmer, but the end user suffers for it. Plus, I've seen far more java exception errors than I've ever seen segmentation faults.

With good reason. Most errors in C/C++ programs that corrupt memory are hidden and never discovered. These lead to problems that allow viruses and worms to attack. Maybe it is just me, but I would rather use a language that threw an exception whenever I did something wrong..

Re:Misconceptions, as usual

[Decaff]

Aw, come on. Don't use some obscure, rare example as a means of "proving" that java is good.

I picked Linpack because it is a benchmark for raw floating point math performance. This was the final area where (until recently) Java could be criticised as being inadequate in terms of performance. The 2004 Linpack benchmarks show Sun's JDK 1.5 as being within 6% of optimised C++ for floating point numerical work - extremely impressive.

If the majority of java code sucks

The majority of code written in any language sucks.

I've got no choice to but to state that java itself sucks. If it's so goddamned difficult to write GOOD java code, then that's a fundamental problem with the language.

In that case, we would have to say that C and C++ have serious problems. The use of these languages over the past 15-20 years has led to the current problems with buffer overruns, viruses and worms that plague major operating systems and languages.

Re:Misconceptions, as usual

[duffahtolla]

//Why migrate? Leave em both in.

import java.applet.Applet;
import java.awt.Graphics;

public class ItsBoth extends Applet {
String message = "";
public void paint(Graphics g) {
g.drawString(message, 50, 25);
}
public init() {
message="It's a floor wax!";
}
public static void main(String[] args) {
System.out.println("It's a Dessert Topping!");
}
}

Re:Misconceptions, as usual

[Decaff]

But that doesnt remove the fact that java is here to stay and has proven itself more than enough in the enterprise. So why slashdot's hostility towards it remains is beyond me.

This hostility is so boring and extremely old fashioned and reactionary.

I have seen exactly the same thing in the 70s when developers were complaining about procedural code, and wanted to keep their 'GOTO's.

I have also seen the same thing in the 80s when the idea of using C or C++ in place of assembler was consider too innovative, slow, and demanding of memory.

And again, in the 90s, there was the same reaction against the use of OOP.

Now that procedural development, the use of high level languages, and OOP are now mainstream, the same old arguments are being used against safe and VM-based languages like Java.

Re:Misconceptions, as usual

[Decaff]

I guess you don't know what 'ISAPI' and '.dll' means. It appears in pretty much every eBay URL that does anything significant. Clearly eBay doesn't find Java sufficient for absolutely everything on their site.

That is the remnant of their legacy system. E-Bay discarded their original C++ ISAPI system and moved to Java/J2EE running on WebSphere years ago.

Scope widening too far?

[Sv-Manowar]

After reading the article, it seems to me that these new media standards are pushing far beyond just new ways to store video. Gosling is quoted as saying "Part of the DVD standard is the players have network ports out of the back". This just smacks of network controlled DRM, and the ability to run java bytecode when the discs boot could allow a whole new range of lockdown facilities on the disks. Not to mention the amount of complexity having network & JVM functionality must be introducing to the end units. Surely even mass production wil struggle to bring such complex devices down to sane prices in the near future.

This would appear to be strongly pushing the bias of practicality toward the opposing HD-DVD camp, while attempting to strengthen Blu-Ray's position as technologically more advanced and superior.

Re:Scope widening too far?

[hsmith]

yeah, but you are forgetting, using java could allow easy reverse engineering of the player. java is cake to reverse engineer, it would take someone no time to pump out a solution that lacks the DRM features, or atleast come up with a way to cirumvent the DRM features (such as a fake server to "authenticate" against)

i see it as a great thing

Re:Scope widening too far?

[Decaff]

This just smacks of network controlled DRM

Why?

and the ability to run java bytecode when the discs boot could allow a whole new range of lockdown facilities on the disks.

How is this different from running any other software when the discs boot? The use of Java bytecode has no relevance to lockdown.

Not to mention the amount of complexity having network & JVM functionality must be introducing to the end units. Surely even mass production wil struggle to bring such complex devices down to sane prices in the near future.

What complexity? Most new mobile phones have JVMs built in. There has been no struggle to bring these 'complex devices' to 'sane prices'.

The more things change . . .

[jvarsoke]

Kinda funny, Java started as a language for programming TV cableboxes, and after years of evolving into everything from J2ME to J2EE, it finds itself back home atop the TV in DVD players.

One of my absolute top peeves

[SirSlud]

Is it just me, or am I the only one completely freakin annoyed with DVD menus? One out of every two has a DVD menu that is absolutely infuriating from a usability perspective. Half the time I'm guessing at what is about to happen, as there appears to be not one freakin convention in the industry as to how DVD menus should be laid out, operate, and respond. I appears to be a totally 'make-work' industry, and nobody can convince me that the production of fancy interfaces doesn't cost a little extra. I'm not saying you can't figure them out after a little fumbling, but sheesh, I'm buying a movie and some comentary, not a magazine that happens to contain a movie.

ARGH. Probably one of my absolute top peeves of the last 10 years of technology. Its enough to make one weep for the comforting sight of a simple, nondescript blinking 12:00.

As for Java, I don't care what it is. I hope to god that interface creation is done through SOME kind of standardized framework or toolkit so at least widgets can at least act, if not look similar, DVD to DVD.

I know I'm asking for a lot tho, because it really seems to me that there are a lot of things in our technilogical world that are done simply because somebody sees a potential way to make money and successfully sells the problem (standardized DVD menus, in this case, the horror) to an industry.

Re:One of my absolute top peeves

[Lisandro]

Same here, but the "most annoying DVD feature of all time" prize goes to (taaa-daah!) unskippable trailers/clips/FBI warnings/whatever. In some recent releases, it's downright infuriating - with up to three movie trailers you have to go through before you can even get to the content.

Publicists should be shot.

Re:One of my absolute top peeves

[Jah-Wren Ryel]

unskippable trailers/clips/FBI warnings/whatever

Video Help is your friend - look up your dvd player and crack it. Chances are good your player is easily hackable to disable the unskippable crap. If yours isn't on the list, at least you now have a list of what DVD players to consider buying when you want to upgrade.

Not Java but JVM.

[burnttoy]

Editors, you should try to correct the original article not parrot it. 'nuff said

Anyhoo.. what they are saying (which I think is pretty cool) is that the movies will be scripted by programs "written in" java byte codes. Who cares what the language is (java is a language editors). It could even be Flash something or other, or C++ compiled on Windows as long as the output is JVM byte codes who cares. This _could_ lead to very interesting development tools and quite imaginative use of next gen disks.

More interesting would be knowing about the API to be specified along with JVM. It could even be DirectX. There's nothing to prevent that.

The API is more interesting as having picked a general purpose machine representation how general purpose will the API be that it uses?

Basically this is worth crap to Sun except for publicity. I thought the JVM specs were open(ish).

Re:Not Java but JVM.

[burnttoy]

As far as I understand it the .Net technologies and this are complimentary in that they tackle different but similar problems. Although .Net supplies a byte code interpreter of its own (CLR) it isn't necessary to use it (in fact most .Net apps are compiled to x86 machine language). .Net supplies a standard for language and API linkage data, representations of API's if you like. JVM supplies a binary level interface for execution of code. Also, it isn't that people aren't (they are just in very small numbers) writing JVM byte code in something other than Java the point is they _can_. There are, I believe, JVM back ends for GCC for example. In this case JVM is being used a little like XML. The syntax is there (the mark up language) but the tags and data mean nothing unless you know what they mean (XHTML for example). This is why I think information on the API is probably as interesting, if not more so, than the machine level programming model.

Re:Not Java but JVM.

[PCM2]

If you do a little studying, I think you'll find that your understanding is erroneous. The .Net Framework is "the managed programming model for Windows" -- Microsoft has trademarked that phrase, in fact. Managed code means the CLR. You might write .Net applications in C++, but you most certainly don't write them in assembly language. You can link to unmanaged objects, but a .Net application is implicitly managed.

While there are a number of ways to generate Java bytecode from code that is not Java, these are largely academic. The JVM back end for GCC you mention describes itself as "highly experimental." There's Jython, but Python is itself a fully interpreted language, so it doesn't count. Sun has said that it has no interest in supporting languages other than Java on the JVM.

The CLR, on the other hand, was designed from the ground up to be a runtime environment suited to multiple languages. Right now, right at this minute, in addition to C# you can write .Net applications in a variety of languages, including Managed C++, Visual Basic, a language called J#, and JScript. Active work is being done to port other languages to it; I keep hearing about Haskell, for instance.

Re:Not Java but JVM.

[Dacta]

The JVM back end for GCC you mention describes itself as "highly experimental."

Untrue. The Java-GCC backend can be used now, for significant program. For instance, Fedora 4 ships the Eclipse IDE compiled using GCC.

Sun has said that it has no interest in supporting languages other than Java on the JVM.

Untrue. JDK 6.0 will include an API to use scripting languages directly, and will include a Javascript-on-Java implementation. There is also Project Coyote (scripting languages on Sun's Netbeans IDE), as well as a JSR for Groovy (the JVM based scripting language).

I'm not quote sure why you think "Python is itself a fully interpreted language, so it doesn't count" either. Just because it is fully interperate in it's current, C based implementation doesn't mean that won't change in the future. For instance, if the Parrot VM ever becomes useful then Python will be running under a JIT compiler, just the same as Java. Infact, it would be possible right now to modify Jython to emit Java bytecode, which then could be compiled by the JIT.

My DVD player already has Flash.

[metalpet]

> Next stop, annoying Flash intros.

The playstation 2 already has a flash player in it, used by various games for their menu systems among other things.
I guess game companies try not to annoy their customers, so Flash gets used reasonably there.

Java DVD Player + network connection + Azureus

[Scott Swezey]

Damn, now we just need to get these things a network connection and a plugin for Azureus, then I can download new movies before their released, watch them on my TV, and maybe if its also one of those nifty VHS/DVD combo things, burn my new movie to a disk.

Seems very unlikley

[SuperKendall]

Although I see what you are saying about the danger of a network based DRM creeping into discs, I think it very unlikley - a deivce that requires a working network connection would not be nearly as mass-market as DVD players are today. It simply cannot be a requirement.

There may be some specialized discs that do something like this but I don't not think it will be mandatory.

Could be much nicer for DVD content creation apps

[SuperKendall]

The inclusion of Java could lead to nicer open source DVD authoring apps that would allow easier control over menu workings. And it's a lot nicer to have a standard language underneath rather than the cryptic menu building language of todays DVD's.

At the very least those games they always throw on kids DVD's might not be so awful to play if they do not have to be shoe-horned into a system never really designed for games.

Re:The only appliances that are fit for Java:

[Waikikamukau Slim]

Not true. My coffee machine is <b>perfectly</b> fit for Java.

Re:Java IS sux

[Decaff]

Note: the majority of people couldn't give a hang about back-end, so called 'enterprise' solutions with Java)

Yes, because, like, no-one uses E-Bay, banks, stock-markets, airline on-line booking systems.

I'm sure the majority of people couldn't give a hang about these.

Uh... what?

[mcc]

Microsoft's codec is also in the Blu-Ray spec

Re:ARG

[Decaff]

No this isn't a shot at Java this is a shot at over building things. What's next Java in my car?

It may already be there:
http://www.zdnetasia.com/news/software/0,39044164, 39185006,00.htm

Finally...

[Ingolfke]

I can run Eclipse on my Blu-Ray player!

I can see it now

[Cereal Box]

Joe Sixpack inserts his new DVD into the drive and...

"NullPointerException? WTF?"

Re:Java IS sux

[Decaff]

That would explain why eBay is so slow.

That is a very easy comment to make, but I don't think that it is fair comment considering E-Bay is possibly the highest volume website ever, and I doubt that the developers of that site are stupid enough to develop the site using a slow technology. I'm afraid the 'slow' argument is getting very old fashioned and rather boring. Java is used for extremely high volume websites, dealing with thousands of transactions every second.

It is time the 'slow' argument was finally put to rest.

Actually I think we are getting muddled up here. You began by saying that Java (as in back end/server side Java) was something we all use and should appreciate. I'm saying no one cares about that and it is highly swappable with any other competing technology.

What other competing technology?

Oh, Microsoft IS shipping with HD-DVD...

[SuperKendall]

Just not right away.

Don't believe Microsoft would be so stupid? Read this!

As the saying goes - Game Over, Man! And not for Sony.

And for cross-reference, Balmer said as much (about the eventual inclusion of HD-DVD) when interviewed by Engadget way back in May. Actually what he really said then was they could go other way, but the link I provided seems to indicate which way they are swinging - and is anyone surprised it's whatever Sony is NOT doing?

Two reasons why I object to Timothy

[tod_miller]

Not even his posted comment, but to him, he is objectionable:

Next stop, annoying Flash intros.

Right... the processor that will run the JVM, if not a specific Java chip, then the DVD will certainly have a chip capable of running an embedded flash player.

Now. I have to shout sorry:

FLASH IS A DISPLAY / VECTOR ANIMATION TECHNOLOGY.

1) It has nothing to do with Java - THIS news is AWESOME and I look forward to being able to write my own programs to take screen caps, and write a whimsical comment while the player is playing, and email it to a friend. Or keep a log of my movies and ratings as I watch them, or write a book mark sharing XML format, and wire it to the remote, so you can bookmark film locations, and plug your own audio commentary on them. (think about wedding videos / holiday video, and you will see why this is nice - but also for mainstream stuff)

2) So, Java can do games and animation, and even there are Java flash players, and SVG players, and MPEG4 players. Just because the technology is there, doesn't mean annoying 'Flash' (unrelated) intros.

3) *ahem*

What is more annoying is the abundance of unskipable content on DVD's, and this has nothing to do with either of the unrelated technologies that you have mentioned.

If this can be screwed off, I would be happier, I still haven't had time to look for a firmware hack for my DVD player.

Anyway.

Re:Java IS sux

[CowboyBob500]

Out of work VB6 developer by any chance?

Bob

This is ancient news and lousy planning

[Teancum]

OK, yes, the announcement is something new and it is relevant for /. to report this kind of story, but as far as the DVD industry is concerned, they blew their chance and this is essentially old news.

Every DVD player comes equiped with its own CPU, and even its own assembly code that is a part of the DVD-Video specification. This is already a part of the DVD-Video spec from even the very beginning. The problem is that Hollywood (together with the other members of the DVD Consortium... now DVD Forum) deliberately crippled the CPU so that it could in reality do very little. I've described this CPU has having 26 registers, no RAM at all, and 1 TB ROM address space, with incredible video capabilities but lousy rendering capabilities (sub-pictures).

Frankly, I think the DVD Forum blew their chance at having a cheap consumer entertainment computer back when the original design was put together back in the mid 1980s. If the CPU would have even had just a little bit more computing power, including a small (even 64 K) amount of RAM and text rendering capabilities (nothing new or even expensive to implement back when the design was being put together) they would have had not only a movie playing machine, but a computing platform that would have been more widely distruted than the X-Box or Playstation.

Even before the DVD-Video 1.0 spec came out (it was at a beta 0.98 when I mentioned this) I was suggesting to the design committee for DVD-Video to incorporate Java into the specification. Even then (about 10 years ago) I felt that some sort of programming environment would have been both easy to implement and offer to make DVD-Video something well beyond a simple movie playback box. Obviously my idea fell on deaf ears. Too bad I didn't patent the idea (perhaps I should have).

The DVD Forum will probabaly screw this one up as well, but at least they are going down the right general direction. IMHO there is no reason to make it specific to the Blu-ray format except as a splash to make the new generation of players seem to have more capabilities. Existing DVD discs certainly could be using this same capability, and there is plenty of space on a DVD for some binary (even raw source code) programming instructions, with a full two hour movie.

Cool applications of this

[DickBreath]

Do I get this right?

A $50 box that is quiet, plugged into my TV, plugged into the Internet, and can run custom code from a custom disk that I burn?

Possible applications anyone?

A cheap slave box with a custom Java code that functions as an alternate type of MythTV front end, that streams video on demand from a MythTV backend?

Games? (Using only the remote control as an input device?)

A general porpoise Java app could be written that talks to a server, where the server "drives" the user interface on the TV screen. This general purpose DVD only needs to be released once. Applications can be written on your Linux box that present any type of user interface for any purpose. Home control menus and applications, for example. Show me the latest Slashdot headlines. (But the custom code for this is on the Linux box, the DVD is just a general remote driven user interface toolkit.) Show me the current weather map. Show me the front door security camera.