Netflix Streaming Coming to PS3 Next Month

[Asher]

Java isn't a real open standard. I recall MS making a much faster implementation of Java and getting sued for their troubles.

I understand why you're such a big fan of BD-J, patsu, I just don't see it's value. It's way overkill, it's way too complicated, and it's way too heavy for what are, 99% of the time, relatively simple uses. It's unfortunately something that happens a lot in technology (and Sony seemed to have a particular problem with that on the PS3 itself).

I've learned over the years that KISS is the way to go. I realize it's really easy to extol how awesome BD-J is because you can do anything and everything in it, but the complexity of it is frequently detrimental. Bluray was late to the game in virtually all important aspects of the spec: PiP, BD-Live, etc and I have to believe that's because of the complexity of the environment they're building.

HDi kept it simple and they had all of these features from day one, in a manner that was more responsive for users and quicker to load. In addition, in many ways the HDi implementation was more forward-looking because it could also be implemented INSIDE a stream from a source, which meant studios could provide all of the same "rich content" provided on the disc to online digital distribution avenues. Which means instead of just getting the video stream from Netflix, if we still had HDi support in players, we could potentially be getting a full "rich content" experience through DD.

As I understand it, this is also the approach Apple has taken with iTunes Extras and it was also the approach Sony took with the PSP and originally wanted to take with Bluray. The BD-J implementation on Bluray is really the odd man out here.

 

[patsu]

Java isn't a real open standard. I recall MS making a much faster implementation of Java and getting sued for their troubles.

Ah because MS tried to incorporate proprietary extensions and still call it Java. It would fragment the base. Not our problems though. MS can still contribute to Java if they want to.

I understand why you're such a big fan of BD-J, patsu, I just don't see it's value. It's way overkill, it's way too complicated, and it's way too heavy for what are, 99% of the time, relatively simple uses. It's unfortunately something that happens a lot in technology (and Sony seemed to have a particular problem with that on the PS3 itself).

I've learned over the years that KISS is the way to go.

I abandoned Java programming long ago. But I know it is not necessarily a slow language. Gmail is written in Java for example. You won't be able to discuss overkill without highlighting an application. Nothing in this world is an automatic overkill, my friend. It simply reflects on your personal preference and past experiences.

You can do NetFlix instant streaming in BD-J on relatively low cost Blu-ray players. That's enough for me to know that Java and the kind people behind the implementation have done their job.

EDIT:
HDi has a different goal. It is designed as an interface and a language tied to the interface. Java is a general programming run-time, with or without the DOM. People experimented with iPhone integration, live streaming and other ridiculous stuff. I sure hope we continue to see more interesting applications in the future.

Like I said, Blu-ray has an even simpler interface language for menu systems. BD-J is meant for more complex scenarios.

Apple iTunes and PSP can do whatever they want, their needs are different. In the worst case, Apple can fall back on Objective C while PSP can choose from C/C++. They are also single vendor platforms, totally in a different position.

 

[zed]

Java isn't a real open standard. I recall MS making a much faster implementation of Java and getting sued for their troubles.

A tried and tested formula
http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

Im sure If some company comes up with an 'improved' version of c# then MS would also take steps to stop it

 

[obonicus]

Java isn't a real open standard. I recall MS making a much faster implementation of Java and getting sued for their troubles.

That case is a textbook case of the use of Embrace, Extend, Extinguish. Both BEA/Oracle and IBM have released JVMs that are better than Sun's in several ways, there's been no lawsuit. It's not an open standard because, last I checked, a J2ME runtime costs money to implement, and I think the compatibility suites do too. Any company that pays for the suite and meets the compatibility requirement, though, can create their own JVM.

 

[Asher]

Ah because MS tried to incorporate proprietary extensions and still call it Java. It would fragment the base. Not our problems though. MS can still contribute to Java if they want to.

There's really no point for them to do so. I'm not saying this to troll, but C# and the .NET CLR is what Java should've been from the start. On the past five years, Sun's been hacking in features to Java just to play catchup with C# and the language is losing its "clean design" feel it used to have. Java's implementations of generics is truly embarrassing, for example. It was a quick "me too" in response to C# 2.0.

I abandoned Java programming long ago. But I know it is not necessarily a slow language.

It is. If you want a performant application, you will never -- ever -- choose Java unless you don't know what you're doing or you have no other choice.

Java is the language of choice if you want portability, not performance. It's a decision they made and it's not a bad one, but the people who pretend Java is everything and anything are kidding themselves. Sacrifices are made for portability.

You won't be able to discuss overkill without highlighting an application. Nothing in this world is an automatic overkill, my friend. It simply reflects on your preference.

It's overkill. Can you implement a custom video scrubber without writing Java code? That's an example of overkill. What if I just want to change the color of the scrubber?

There should be simple ways to do simple things, and implementing a heavy framework just because then you can do obscure things is not necessarily a good design choice. It has more effects than just making it harder to develop for -- it increases loading time as well, and potentially response time for users.

You can do NetFlix instant streaming in BD-J on relatively low cost Blu-ray players. That's enough for me to know that Java and the kind people behind the implementation have done their job.

Does the Netflix streaming disc work on all Bluray players with an internet connection?

If the answer is "no", then no, they didn't do their job. Even then, as we've already discussed, the Netflix streaming disc is a temporary solution to a legal problem and not a technical triumph. According to the HDi specs, it would've been possible in HDi as well.

EDIT:
HDi has a different goal. It is designed as an interface and a language tied to the interface. Java is a general programming run-time, with or without the DOM. People experimented with iPhone integration, live streaming. I sure hope we continue to see more interesting applications in the future.

First, you are oversimplifying HDi. HDi includes a JScript runtime, which is far more powerful than you are giving it credit for. Have you seen what's possible with JavaScript these days? Look at the Palm Pre, look at Google's latest web apps, look at Office Online...HDi came with a general programming language and runtime, it's just a far lighter weight language which is far more appropriate for the usage on a media disc than Java.

As for the iPhone integration, if you're thinking of the new FoxPop thing launching Dec 1st, it has 100% nothing to do with Bluray. The iPhone/PC devices use audio cues to display popups on the iPhone/PC, it requires no special BD-J software.

 

[Asher]

That case is a textbook case of the use of Embrace, Extend, Extinguish. Both BEA/Oracle and IBM have released JVMs that are better than Sun's in several ways, there's been no lawsuit. It's not an open standard because, last I checked, a J2ME runtime costs money to implement, and I think the compatibility suites do too. Any company that pays for the suite and meets the compatibility requirement, though, can create their own JVM.

IBM and BEA/Oracle are partners with Sun, and Sun has a venomous hatred for Microsoft. If you ever go to a James Gosling speech, ask him a question about C# and watch him blow his top.

Let's be clear. C# and the .NET CLR are far more "open standards" than Java is. Many, many people here keep saying Java is an open standard, when it is not.

Java is a de facto standard under the JSR and still is controlled by Sun. Only in 2007 did they open source the framework under the GPL, but that doesn't make it an open standard either.

C# is both a ECMA and ISO standard, of which Java is not. Likewise, the .NET CLR is both an ECMA and ISO open standard.

Yes, MS' implementation of Java was "incomplete" (this was Sun's word, not mine). But it sacrificed completeness for speed, which is why it was by far faster than Sun's. It wasn't until MS' Java VM that Sun actually started looking at making Java more performant with technology like JIT. I'm well aware of the business reasoning and motivation behind their Java VM, but that's not relevant to this topic.

In retrospect it wasn't any different from Sun making Java ME ("incomplete Java") and just calling it something else.

 

[Asher]

A tried and tested formula
http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

Im sure If some company comes up with an 'improved' version of c# then MS would also take steps to stop it

Last I checked, MS is actually helping Novell develop their version of C#/.NET support, even though it is presently not completely compatible with the official Windows versions.

 

[deathindustrial]

Last I checked, MS is actually helping Novell develop their version of C#/.NET support, even though it is presently not completely compatible with the official Windows versions.

Last I checked, Microsoft's relationship with Novell also fell under the embrace, extend extinguish banner.

http://arstechnica.com/business/news/2006/11/8178.ars

And Mono is arguably another example in action.

http://www.groklaw.net/articlebasic.php?story=20090717043855128

Cheers

 

[obonicus]

IBM and BEO/Oracle are partners with Sun, and Sun has a venomous hatred for Microsoft. If you ever go to a James Gosling speech, ask him a question about C# and watch him blow his top.

Okay, now that Oracle owns Sun, let's see if they try to cut IBM out. There's no love lost between these companies. The situation is very different, and you know it.

Let's be clear. C# and the .NET CLR are far more "open standards" than Java is. Many, many people here keep saying Java is an open standard, when it is not.

Sure, it's not, but anyone can build a JVM if they have the cash -- if you're building BD players you probably can pay to make or license a JVM.

Yes, MS' implementation of Java was "incomplete" (this was Sun's word, not mine). But it sacrificed completeness for speed, which is why it was by far faster than Sun's. It wasn't until MS' Java VM that Sun actually started looking at making Java more performant with technology like JIT. I'm well aware of the business reasoning and motivation behind their Java VM, but that's not relevant to this topic.

Of course it is! You used as an argument that Sun went after Microsoft for implementing a different VM when it's nothing of the sort. If you actually know the truth then you're spreading FUD.

 

[bkilian]

What would you need to write a netflix client? You need a bit of storage, you need a net connection. You need the ability to process XML, since I'm betting it's a web service. And you need the ability to load images, stream video and render text.

All of those features were available in HDi. From day 1. In fact, the Transformers HD DVD actually does all of those things.

We're comparing to Java, though. All of that can be done through libraries implemented in native code. Of course, native code becomes a problem when you start to have vendors with significantly different solutions.

Yes, but you still need to go back up through the java stack to the client code every time a user interaction occurs and to drive the animations. The Universal titles, for instance, did most of their menu navigation and animation without touching any javascript code. (In the first titles, anyway. They got more complex after that, but it was still mostly handled by the native animation engine)

 

[patsu]

There's really no point for them to do so. I'm not saying this to troll, but C# and the .NET CLR is what Java should've been from the start. On the past five years, Sun's been hacking in features to Java just to play catchup with C# and the language is losing its "clean design" feel it used to have. Java's implementations of generics is truly embarrassing, for example. It was a quick "me too" in response to C# 2.0.

Sure, but that is a different argument from Java is overkill right ? We have done amazing things with or without those language features. If MS wanted, they could have submitted .NET CLR and C# to BDA too, but they didn't. They chose HDi. Again, not our problems now.

It is. If you want a performant application, you will never -- ever -- choose Java unless you don't know what you're doing or you have no other choice.

Tell that to Gmail implementors.
It is one of the most heavily used Internet applications ever.

Java is the language of choice if you want portability, not performance. It's a decision they made and it's not a bad one, but the people who pretend Java is everything and anything are kidding themselves. Sacrifices are made for portability.

It depends on what level you're talking about, the sacrifice can be small or big.

It's overkill. Can you implement a custom video scrubber without writing Java code? That's an example of overkill. What if I just want to change the color of the scrubber?

That's not overkill. You simply highlight another approach. .NET is an overkill from that perspective too.

The development tools have interface builder to help you simplify the development. A custom video scrubber is still machine code in the end. As long as the scrubber gets compiled to native code, I don't think there's any overkill at all. What you refer to as overkill seems to be development convenience, which is being solved by the BD-J authoring tool providers.

There should be simple ways to do simple things, and implementing a heavy framework just because then you can do obscure things is not necessarily a good design choice. It has more effects than just making it harder to develop for -- it increases loading time as well, and potentially response time for users.

So you're talking about development convenience: Too much work for too little benefit. That is a different problem altogether, and like I said, the authoring tool provider addresses this space. Your favorite CLR run-time has this problem too, but MS has a interface builder environment for it.

Does the Netflix streaming disc work on all Bluray players with an internet connection?

If the answer is "no", then no, they didn't do their job. Even then, as we've already discussed, the Netflix streaming disc is a temporary solution to a legal problem and not a technical triumph. According to the HDi specs, it would've been possible in HDi as well.

It works and that's sufficient for consumers.

As for whether the same disc can work across all Blu-ray players, the answer is probably no. However it depends on how NetFlix manage it for business reasons. The BD-Live NetFlix streaming service is impressive *especially* because it's a temporary solution that they can put together without prior planning. It speaks volume about the need for a general purpose programming environment, as opposed to some shoehorned framework.

First, you are oversimplifying HDi. HDi includes a JScript runtime, which is far more powerful than you are giving it credit for. Have you seen what's possible with JavaScript these days? Look at the Palm Pre, look at Google's latest web apps, look at Office Online...HDi came with a general programming language and runtime, it's just a far lighter weight language which is far more appropriate for the usage on a media disc than Java.

As I understand, HDi requires a DOM as part of the run-time model. I don't think I have simplified JScript the way you have simplified the Java run-time issues.

As for the iPhone integration, if you're thinking of the new FoxPop thing launching Dec 1st, it has 100% nothing to do with Bluray. The iPhone/PC devices use audio cues to display popups on the iPhone/PC, it requires no special BD-J software.

http://www.netblender.com/main/products/bd-touch/

 

[makattack]

Last I checked, MS is actually helping Novell develop their version of C#/.NET support, even though it is presently not completely compatible with the official Windows versions.

Outside of some toy personal projects I have on the XNA Game Dev SDK, I don't program in C# or .NET professionally, but I am aware of this Open Source implmentation of the .NET RT:

http://www.mono-project.com/

Is this the Novell project you're referring to? There seems to be some affiliation.

 

[Asher]

Okay, now that Oracle owns Sun, let's see if they try to cut IBM out. There's no love lost between these companies. The situation is very different, and you know it.

It wouldn't surprise me in the least if Ellison did try to cut IBM out. It also wouldn't surprise me in the least if Oracle tried to kill MySQL.

Sure, it's not, but anyone can build a JVM if they have the cash -- if you're building BD players you probably can pay to make or license a JVM.

Aside from finding it ridiculous that they have to license the JVM...who is to say Sun cannot refuse someone the implementation rights? They own the rights to the JVM from the trademark to the technology.

Of course it is! You used as an argument that Sun went after Microsoft for implementing a different VM when it's nothing of the sort. If you actually know the truth then you're spreading FUD.

That's exactly what happened, the difference being MS "optimized" the VM to run significantly faster by running it as native code and not as a simple bytecode interpreter.

The only thing different from what MS did and what these new optimized JREs did is MS did it on their Windows platform and included it with the OS. Since these embedded JREs are not on systems where users have a choice which JRE runs on it, Sun doesn't care. Plus, it's not MS.

Last I checked, Microsoft's relationship with Novell also fell under the embrace, extend extinguish banner.

http://arstechnica.com/business/news/2006/11/8178.ars

This has absolutely NOTHING to do with C#, .NET, Mono, Moonlight, etc.

And Mono is arguably another example in action.

http://www.groklaw.net/articlebasic.php?story=20090717043855128

Cheers

You have to be kidding me? This is textbook FUD. The FSF and RMS have been fearmongering since the beginning about Mono and NONE of their claims have been realized. They have an agenda, and you should remember that.

It's not another example of it in action because MS has done precisely nothing to indicate what you are claiming.

 

[Asher]

Sure, but that is a different argument from Java is overkill right ? We have done amazing things with or without those language feature. If MS wanted, they could have submitted .NET CLR and C# to BDA too, but they didn't. They chose HDi. Again, not our problems now.

MS didn't submit it presumably because it'd be overkill. They were fully behind HDI.

Tell that to Gmail implementors.
It is one of the most heavily used Internet applications ever.

And gmail is famous for doing as much as it can client-side..using Javascript and the DOM. This is perhaps the worst example you could've possibly given as it's a tremendous example of the power of JS/DOM/etc.

As a bonus, it doesn't at all use Java in any way.

That's not overkill. You simply highlight another approach. .NET is an overkill from that perspective too.

YES. That is the point. .NET would be overkill for this as well! And yes, it is overkill to have to write Java code to change the color of a video scrubber.

The development tools have interface builder to help you simplify the development. A custom video scrubber is still machine code in the end.

It should be XML.

I'm not sure if you've followed industry trends, but the trend is moving away from using machine code to define interfaces into using standards like XML (or HTML/CSS ).

As long as the scrubber gets compiled to native code, I don't think there's any overkill at all.

It shouldn't have to be compiled to native code. You should be able to flip a layout value in a simple data file and that'll be the end of it. Any reasonably designed system would be like that.

This is how it works in iTunes Extras, Sony PSP movies, HDi, Silverlight video players, HTML5 video, etc. BD-J on Bluray is the odd man out here, and it's a very silly design that is overkill.

So you're talking about development convenience: Too much work for too little benefit. That is a different problem altogether, and like I said, the authoring tool provider addresses this space. Your favorite .CLR run-time has this problem too, but MS has a interface builder environment for it.

You are completely missing the point. It's not JUST about development convenience, it's about the complexity of the tool from end to end. Yes, Visual Studio has an interface builder but that is not the point at all. First of all, .NET on Bluray/HD DVD would be as every bit as stupid as Java would be. Second of all, this is a terrible example on your part again. The new Visual Studio apps, even when using this interface builder, write interface designs to XML and NOT to machine code or code of any kind. The layout and the back-end code are separate, as they should be.

But, again, this isn't the point. BD-J is heavy from start to finish. It doesn't matter if there's an interface builder for it if you need to create custom classes just to implement an ever-so-slightly customised video scrubber. That's <em>overkill</em>. It increases loading time for users, it increases development efforts and complexity for developers. It's just overkill.

As for whether the same disc can work across all Blu-ray players, the answer is probably no.

Then this is a terrific example of why BD-J was a bad idea. The code isn't even portable, apparently. You have repeatedly used Netflix as an example of the triumph of BD-J, when it could just as easily have been implemented in HDi and work on every HD DVD player ever made, from the start.

As I understand, HDi requires a DOM as part of the run-time model. I don't think I have simplified JScript the way you have simplified the Java run-time issues.

I am utterly gobsmacked right now.

Yes, HDi requires DOM and JScript runtimes. Which are smaller and less complex by orders of magnitude compared to the JRE.

And how have I simplified Java run-time issues? They're all there. You can either use JIT which results in painfully long loading times for what should be simple tasks like playing a video, or you can use simple bytecode interpretation which is slow all the time. In any case, Bluray interfaces are not as responsive as they should be.

http://www.netblender.com/main/products/bd-touch/

To be perfectly honest, products like this are a reason why BD-J was overkill and a bad idea. Studios are going to make content only accessible to people with iPhones/iPod touches or "other wifi devices"? If I'm watching a Bluray on a 42" LCD, why would I want to use a 3.5" display on my iPod or iPhone? If I'm looking at the iPod or iPhone I'm not looking at the TV.

This is another terrific example of the overkill of BD-J resulting in solutions looking for problems.

 

[wco81]

Well convenience is there but the Netflix movie selection is poor. They mostly seem to have already-released DVD box sets of TV shows online.

For instance, I recorded and viewed Bourne Ultimatum off HBO or Showtime, liked it so looked at Netflix for the previous movies. Neither available on streaming and they're 5 and 7-year old movies.

So I'd have had to order them by mail anyways. Hollywood studios aren't going to give away even their back-catalog on streaming for free. If they ever put more titles on streaming, Netflix won't be able to include it for nothing.

For the foreseeable future, packaged media is still the best source for movies, not just in quality but in selection.


On a related note about all these interactive applications on movies, is it Paramount or Universal, one of the last holdouts from Blu-Ray, which is putting out iPhone applications which will interact with BD-J applications on some of their Blu-Ray releases?

Would HDi have ever supported iPhone applications in this way?

 

[Asher]

Well convenience is there but the Netflix movie selection is poor. They mostly seem to have already-released DVD box sets of TV shows online.

For instance, I recorded and viewed Bourne Ultimatum off HBO or Showtime, liked it so looked at Netflix for the previous movies. Neither available on streaming and they're 5 and 7-year old movies.

So I'd have had to order them by mail anyways. Hollywood studios aren't going to give away even their back-catalog on streaming for free. If they ever put more titles on streaming, Netflix won't be able to include it for nothing.

For the foreseeable future, packaged media is still the best source for movies, not just in quality but in selection.


On a related note about all these interactive applications on movies, is it Paramount or Universal, one of the last holdouts from Blu-Ray, which is putting out iPhone applications which will interact with BD-J applications on some of their Blu-Ray releases?

Would HDi have ever supported iPhone applications in this way?

Doubtful, at least with the version that was released when HD DVD was released.

That's not to say newer versions of the spec couldn't have been released to add Bluetooth or Wifi support. After all, Bluray did see many releases while HD DVD had just the one.

I suppose it could also be possible if you use the internet as an intermediary. EG, sign in on both the iPhone/iPod and through the movie player, then it could work just fine.

 

[obonicus]

It wouldn't surprise me in the least if Ellison did try to cut IBM out. It also wouldn't surprise me in the least if Oracle tried to kill MySQL.

Let's see. If they do, you have a point.

Aside from finding it ridiculous that they have to license the JVM...who is to say Sun cannot refuse someone the implementation rights? They own the rights to the JVM from the trademark to the technology.

Find an example of that. Otherwise you're the one fearmongering. The JVM's been around for over a decade.

The only thing different from what MS did and what these new optimized JREs did is MS did it on their Windows platform and included it with the OS. Since these embedded JREs are not on systems where users have a choice which JRE runs on it, Sun doesn't care. Plus, it's not MS.

They also started adding proprietary extensions and breaking compatibility with Java which is exactly where the 3 Es come from. You're really comparing apples and oranges.

 

[Asher]

Find an example of that. Otherwise you're the one fearmongering. The JVM's been around for over a decade.

Microsoft cannot implement Java. The very fact that Sun can take people to court and prevent them from implementing Java is evidence enough that they have the power to do so. It's happened historically and it can happen again, it's not fearmongering it's a simple fact. Sun can, and has, prevented people from implementing the JRE.

They also started adding proprietary extensions and breaking compatibility with Java which is exactly where the 3 Es come from. You're really comparing apples and oranges.

Isn't BD-J itself a proprietary extension to Java?

 

[obonicus]

Yes, but you still need to go back up through the java stack to the client code every time a user interaction occurs and to drive the animations. The Universal titles, for instance, did most of their menu navigation and animation without touching any javascript code. (In the first titles, anyway. They got more complex after that, but it was still mostly handled by the native animation engine)

You worked only on the 360 HD-DVD peripheral, right? Do you know how this worked on less beefy hardware, like Toshiba's players?

 

[obonicus]

Microsoft cannot implement Java.

Seriously?

Isn't BD-J itself a proprietary extension to Java?

And it's not called Java, it's not claiming to be compatible with any other Java environment. You really shouldn't complain about RMS' fearmongering when you keep ignoring the actual details of the Microsoft/Java debacle and claiming that Sun will do something it only did once, under circumstances that are very different from anything you describe. What you're doing is FUD, plain and simple.

'Gosh, but they could cut us off!' Sure, if you have a history of breaking standards and not playing well with others.