http://www.emedialive.com/Articles/ReadArticle.aspx?ArticleID=14010

Good quote from article:

Of course, postwar format consolidation has also had its upside. “It’s definitely added focus to the industry where we didn’t have focus before. Everybody’s on the same page, everybody’s working toward the same goals,” says Jess Bowers, director of technical services for 1K Studios (http://www.one-k.com/), of Burbank, CA. “But it seems like there’s a little less fire in the industry,” he adds.Of course, there are die-hard HD DVD lovers who will never utter a nice word about Blu-ray and who will go to their graves condemning Toshiba and Microsoft for their cowardly surrender and Sony for being a bully. And they will insist that just as Betamax was a better format than VHS and unfairly driven from the market, HD DVD was the better technology, the superior underdog that should have been the winner. And they will regale their grandchildren with mythical stories set in the Camelot-like good old days of HD DVD. But for the most part, most of the HD disc developers and producers who had cast their lot (at least partially) with HD DVD have taken the news with calm resignation.

It is interesting to see how some former HDi developers see BD-J. To sum it up BD-J can do more than HDi but is also harder to write. From the sounds of it though there are GUI based BD-J authoring tools that are being developed, and a few that have been released, that should make it easier for small companies to make BD-J applications.

A lot of these issues are quite symmetric: these houses would have had similar complaints if HD DVD had won.

From a consumer perspective, one of the most important things is the fact that Blu-ray has more bandwidth and storage than HD DVD had. This means that some very important issues are simpler. Personally, I am a lot less interested in this interactivity than I am in the quality of the picture and sound.

For people interested in the interactive potential of Blu-ray, this is a very disappointing article:VM/PLAYER INCOMPATABILITIES
Another problem that has confronted newly-baptized Blu-ray developers is the lack of standardized hardware. As hard as this is to believe, even at this late date, each Blu-ray player from each manufacturer is slightly different. “Conformity in the players in the real world is something that is a moving target,” says Metabeam’s Brown.

“Blu-ray players are light years apart,” says Wain. “Each of these boxes may have different JVMs in them--Java Virtual Machines--depending on the manufacturer and which JVM they’ve licensed into their box. So they act quite differently, and one of the things we’ve discovered about working in BD-J is that you can fix one BD-J problem on one player and introduce another problem on another player.”

But isn’t a standard a standard and a spec a spec? “There’s a spec that is handed to all the producers, and there’s a mirror of that spec that’s handed to the player manufacturers, but there are different interpretations of that spec,” says Wain.

“The BD-J spec has an interesting history,” says Bowers. “It pulls from all these other different overlapping specs. It pulls from specs designed for cable set top Java, for example. That Java is sort of the godfather of BD-J. But then there’s overlapping versions of that that got boiled down into BD-J. And so you have different implementations of the spec. The spec describes what we have to do on the content side to create something, but the spec doesn’t describe exactly how to create a player,” says Bowers, who sums up: “The problem is that there is a lot of interpretation possible with the spec. It’s not black and white.”

So what’s a poor struggling production house new to Blu to do? “Lots and lots of testing,” according to Bowers. “We have a variety of different players here in the house, so we’ll burn a lot of BD-Rs and pop them in the different players and test them out, and if we see something where it doesn’t work the same way on different players, we’ll adjust. Our Java programmers might spend a week or two weeks hammering on that. Eventually, we may have to sort of split the difference. I’m talking vaguely because it is kind of a black art. But it is similar to what we all had to do in the early days of DVD with the player incompatibility that existed then.”

“To try to get something that will play equally well on all Blu-ray players is very difficult,” says Applegate. “That will change in time as old players drop by the wayside.”

While some people, such as Applegate, feel certain that electronics manufacturers will work toward solving the player incompatibilities, Bowers isn’t so sure. He worries that in their rush to cut prices and increase sales, manufacturers will skimp. “Players will continue to get faster on the high end, but as price comes down, performance may actually decrease. The manufacturers may want to cut costs. Performance problems may not necessarily go away.”
Reading the whole article, one doesn't come away with a positive feeling, with regard to BD-J. This could severely limit interactive features to only the biggest-selling titles that will appeal to the highest number of consumers, considering how much effort has to go into programming and testing.

Scott

My guess is that as time goes by lots of things will get boiled down into classes that will make the more common things much easier to do. It doesn't surprise me that you see differences in how things run on different machines. Just look how different even basic web pages look in different browsers and on different platforms.

Typical developer woes.... the target is always moving.

"Non-standard standards" - that says volumes about Blu-Ray and the problems it presents to everyone, both consumers and media companies. My interpretation of the article: In hindsight, everyone (except Sony) would have been better off if HD-DVD had won.

"Non-standard standards" - that says volumes about Blu-Ray and the problems it presents to everyone, both consumers and media companies. My interpretation of the article: In hindsight, everyone (except Sony) would have been better off if HD-DVD had won.

Very important win for the image of Sony. But it certainly did not come cheap. I believe in going in for a quick victory deals were cut in favor of content providers, at the cost of future royalties for Sony and Panasonic.

That's my take based on how little the victory did to change the market values of these companies and how little they (especially Sony) have since said about the role of Blu ray on their future revenue and margins.

It is interesting to see how some former HDi developers see BD-J. To sum it up BD-J can do more than HDi but is also harder to write. From the sounds of it though there are GUI based BD-J authoring tools that are being developed, and a few that have been released, that should make it easier for small companies to make BD-J applications.

What can BD-J do that HDi couldn't? Answer: nothing.

No advantages, more difficulty to program, more incompatibilties.

Yeah, it's "better." :eek:

What can BD-J do that HDi couldn't? Answer: nothing.

No advantages, more difficulty to program, more incompatibilties.Note that it was developers who have worked on BD-J/HDi who said that BD-J could do more. Since you are stating that those BD-J/HDi developers are wrong what evidence do you have for that?

Note that it was developers who have worked on BD-J/HDi who said that BD-J could do more. Since you are stating that those BD-J/HDi developers are wrong what evidence do you have for that?

Is BD-J a competing technology to Flex and Ajax, if yes. Why is it better?

Note that it was developers who have worked on BD-J/HDi who said that BD-J could do more. Since you are stating that those BD-J/HDi developers are wrong what evidence do you have for that?
Is this the HD DVD part you are talking about?

Some former HD DVD developers report that the forced switch to Blu-ray has forced them to grapple with graphics. It seems the two formats differ in the way they handle graphics.

“In HD DVD the graphics architecture was such that the graphics were decoded on the fly, as you used them,” says Bowers. “So with a big page of graphics, it would take a split second to decode that page and display those graphics. That happens as you go along and you might have a slight pause here and there. But in Blu-ray all the graphics need to be loaded into a buffer in the beginning, so you take that hit, that pause, in the very, very beginning. Now, on a high-performing player like a PS3, the pre-loading of graphics might take only a few seconds, but on a low-performing player, it takes a long, long time, maybe even minutes, until you can get to what you want to see,” says Bowers. “Now that’s been hard for a developer to get used to. It’s been a pain.”

Bowers isn’t thrilled about some of the tradeoffs he’s had to make in transitioning from HD-DVD graphics to Blu-ray graphics. “Because these [Blu-ray] graphics have to be decoded into memory before they can be used, it sometimes means we have to make changes in our graphics. So we might have to take a design and maybe use less graphics in that design--not dramatically less, but more optimization is required.” This means that developers have had to learn to think differently about how they use graphics, says Bowers, who seems to miss the old days a bit. “In HD DVD you could be more liberal in your use of graphics,” he recalls.

Translating above, HDi was not just scripting. It was scripting plus a native graphics engine described above. A single directive could generate a ton of graphics you had to render seperately with Java. So in some sense, it was a hybrid system.

Is this the HD DVD part you are talking about?No, and goodness knows that these former HDi developers have mixed feelings about BD-J. Still the very fact that they have worked on both and are stating that BD-J is capable of doing more is worth a lot and here are the parts that relate to that:

...
One small company particularly hard hit by HD-DVD’s demise was Rivergate Software Inc. The company is the vendor of DVDAfterEdit, a nifty tool that allows developers to go into an already-authored app to augment and expand its capabilities. Sometimes called a “post-build editor,” it is also useful for debugging. When the truce/surrender announcement came, Rivergate president and owner Larry Applegate was working on an HD DVD version of his AfterEdit tool. He had bet on the wrong horse. Virtually none of the code he’s written can be reused or adapted for Blu-ray. “About two man-years went down the tube,” says Applegate.
...
“We were always working in both formats but predominantly on the HD DVD side, mainly because of client demand. So we had to scramble a bit,” says Duncan Wain, president of Scope Seven LLC of El Segundo, CA. “To be quite frank, I think everybody from a development perspective would agree that it would have been easier to continue to work in HD DVD. It’s just a simpler format -- though BD gives you a lot more options down the road.”
...
“From a programming perspective, having a full-fledged Object Oriented language [Java] to use for interactivity goes far beyond the scripting that HD DVD did,” says Applegate.
...
“Yes, there are more things that you can potentially do in BD-J than you could potentially do in HD-i, but no one has reached that level yet. No one has taken full advantage of it yet,” says Wain. “Profile 2.0 of BD-J is just kicking off; we’ll see how it goes. It is a Java Virtual Machine, which, in itself, means there’s a lot more that you can do. You can do more sophisticated things in Java than you could do in JavaScript. Java is a more advanced language than JavaScript, so you can do more complex interactions.”
...
Larry Applegate sums up the feeling most former HD DVD developers have toward Blu-ray: “Blu-ray is more capable but much harder to build that HD DVD,” says Applegate.
....

It seems that BD-J is more like assembler or machine code and HDi is like a 3G or 4G programming language. You can do a lot more if you code in assembler, but it is more of a pain and it is machine specific.

It seems that BD-J is more like assembler or machine code and HDi is like a 3G or 4G programming language. You can do a lot more if you code in assembler, but it is more of a pain and it is machine specific.

Err.. You can't be farther away than assembler than it's possible to be. You can't be more abstract than an object heavy language like java.

lol

BD-J IS Java. A smaller version of Java but Java none the less. Can it do more or less? It is all in the hands of the developers.

The issue is, regardless of media company, they still have not "realized" how important technology is to their bottom line. They see it as an expense that is a black hole to their bottom line and nothing more. So they try to get away with the least expensive person they can get away with. This is including developers for programming JAVA. Yes, I am talking about JAVA developers. Not beginners, not C+. Not the old mixers or anything of that nature. At this point only Java developers can and should be used for mentoring the BD-J authors or creating the BD-J content.

...an excellent, dispassionate article, kudos to the author. These are absolutely the pros/cons that were discussed long before the so-called "war" came to a sudden stop. Even the most entrenched fanboy can certainly see in these comments that there are inevitably shortcomings for either format, and while the HD-DVD ceiling was certainly lower, it was easier (and, I take it, cheaper) to do the very things that BD is still struggling to acomplish, particularly on non-PS3 players.

No, and goodness knows that these former HDi developers have mixed feelings about BD-J. Still the very fact that they have worked on both and are stating that BD-J is capable of doing more is worth a lot and here are the parts that relate to that:
I read that part but couldn't see how it meant a lot. If Java is better, surely he could have given an example, yet none was. Instead it is a theoretical statement. The part I quoted though, was a concrete area where HDi was better (higher performance graphics).

It is the difference between theory and practice. Point which we made to Disney to get them to support HDi instead of Java. And this was the other point which resonated with them and many others to support HDi:

The issue is, regardless of media company, they still have not "realized" how important technology is to their bottom line. They see it as an expense that is a black hole to their bottom line and nothing more. So they try to get away with the least expensive person they can get away with.

Content companies are companies which well, create content :). Expecting them to become software powerhouses is not sound. That is not the core of their company. Same with others who support them for creative arts. HDi became what it was because we realized these guys could mix graphics with script and flash to create web pages and considered that a skill they had to have. Anything beyond would turn them into a Microsoft or Oracle. Given that pure software companies have trouble putting out bug-free software, there was little hope that content companies would be well off here.

Third point was also made earlier. That is, we warned the content companies that people would just slap any VM they could license and call it the day. But that would cause them huge grief, especially as second and third tier DVD manufacturers got into the market.

Having said all of this, they will have to make all of this work somehow so the situation will get better in the future. As noted above, they better get ready to spend a bunch more money on this stuff though to keep it going (both on development, test and customer support).

Amir

What type of content was the studio aiming to release with HDi or BD-J.

There must have been some goal what they thought would be "good enough".

Amir

What type of content was the studio aiming to release with HDi or BD-J.

There must have been some goal what they thought would be "good enough".
The request came solely from Disney. They created a handful of demos of their "evergreen" classic titles with overlay graphics coming on at the right times to do other "cool" things. They showed these to a number of people including us. We quickly acted on it and created a joint development with them to produce what later became HDi. To gain their trust, we prototyped the exact same demo they had created using HDi. That won them over.

Once HDi made it into DVD Forum, then studios like Warner started to think about how to use it, and helped drive the requirements together with Disney although I don't know that there ever was any other crisp scenario like Disney had in mind.

Just in case folks are wondering why Disney, there a number of reasons. But chief among them that their evergreen titles do not benefit from being in "HD." Which parent would want to rebuy those titles in HD when they already have it in SD? No kid would care about more pixels.

The biggest grief here is yet to come. Imagine you are a CE company selling a player for $99 one day. It would be insane to think that the same company would have to provide firmware upgrades for that player to keep it from crashing on titles released later. There simply is no business model to support that on thin margin/low price devices.

The only solution I can think of is to have them all standardize on one or two processors and one or two BD-J implementations. That plus PS3 would be the limit of what the studios would dare putting up with as far as testing. Without this, they are going to lose their shirt and or leave customers stranded and lawyers happy....

Thanks for the response Amir.

I think most movielovers like myself sometimes think the studios put to much faith in the interactive side of things (we buy movies because we like movies), but it makes some logic from Disneys viewpoint. And some things have been nice upgrades over ordinary DVD menus.

But from a more geeky side of me, could you emulate C64 games with HDi? ;)

The only solution I can think of is to have them all standardize on one or two processors and one or two BD-J implementations.

Personally I think the fact that you aren't married to one processor is a strength. It means that one chip manufacturer can't hold every one hostage. It also means as a manufacturer you have a better chance to be able to use what you are used to and may already have some code base for and you are able to choose what may meet your particular needs the best.

I think some are missing the point that the article was written from the perspective of the small development house. The large development houses that are working with the content providers have the resources and talent required to author in BD-J.

HDi was a much easier language and very similar to web development. So smaller houses had a much smaller ramp up time.

I do tend to agree though that it is the HD video and audio that drives my purchasing, NOT the pretty interactive menus or the ability of blogging with other viewers that drive my purchases. I am slightly interested in what Disney did with their Sleeping Beauty release, but I also remember a lot of the hype around some of their initial DVD plantinum titles which failed to wow me beyond 1 or 2 viewings.

First and foremost put the maximum effort in the video and audio, then worry about the special features.

Personally I have been unimpressed with BD Live, but again I bought BD for its reference video and audio qualities.

Personally I think the fact that you aren't married to one processor is a strength. It means that one chip manufacturer can't hold every one hostage. It also means as a manufacturer you have a better chance to be able to use what you are used to and may already have some code base for and you are able to choose what may meet your particular needs the best.

It can also be a weakness, especially when you get closer to the hardware. All Java implementations rely on a virtual machine (VM) to translate the Java commands to actions by the target machine. This works well when you have a standardized machine that has known and well supported components.

If a target machine (PS3, for example) has well known components (graphics chip, encoders,etc.) the virtual machine will probably support those well. If another machine comes out that has an unsupported graphics chip, the VM will not work properly with it, and the Java program will not work. That may blow some things you don't care about out of the water (BD live, for example), but it may affect others that you do, Menus for example.

It all depends on how much work is put into standardization, coverage of components from companies big and small, and the quality of the code that makes up the VM.

Interesting article. All this mess over what I think the vast majority of people don't really even care about.

I read that part but couldn't see how it meant a lot. If Java is better, surely he could have given an example, yet none was. Instead it is a theoretical statement.Which from the looks of it they believe is accurate and in my opinion they are more likely to be objective about BD-J than someone who worked for Microsoft and promoted HDi for over 2 years.


It is the difference between theory and practice. Point which we made to Disney to get them to support HDi instead of Java.Disney did help develop HDi but last I checked Disney supported Blu-ray.

Disney did help develop HDi but last I checked Disney supported Blu-ray.

I dont think BD-J was the reason.

I dont think BD-J was the reason.True, it was capacity that they most often cited but considering that Disney supported Blu-ray how than did they support HDi?

True, it was capacity that they most often cited but considering that Disney supported Blu-ray how than did they support HDi?

I guess they believed BD-J to be good enough.

What type of content was the studio aiming to release with HDi or BD-J.

There must have been some goal what they thought would be "good enough".You might want to look at this document (http://www.dvdforum.org/images/Requirements%20Specification%20for%20HD%20DVD%20Video%20Appl ication-July2005.pdf) (especially section four). It was written over three years ago, but shows some of the ideas that developers had in mind.

Some of these were incorporated, most weren't. It was just the beginning of what could have been with HD DVD, and what still could be for BD-J. Given the proper care and attention, some of these could have been spectacular to various users.

The key is that it all takes time and labor to create this stuff. If the demand is minimal, studios won't invest the time and cost to add it to the discs.

Scott

Interesting article. All this mess over what I think the vast majority of people don't really even care about.


I think BD live, 2.0 will die. Talk about niche. I almost never watch special features. 2.0 live is like special features with an internet component. The real issue for me when trying it was how boring and unnecessary it really is and IMO how few if ANY consumers will utilize it.

What an overhyped waste. Then again, I don't really see or hear a lot about it.

Interesting article. All this mess over what I think the vast majority of people don't really even care about.

Doesn't matter what we care about. It's a much needed selling point for a next gen format.

John

I think BD live, 2.0 will die. Talk about niche. I almost never watch special features. 2.0 live is like special features with an internet component. The real issue for me when trying it was how boring and unnecessary it really is and IMO how few if ANY consumers will utilize it.
Probably the only thing relevant to actual movie lovers will be the possibility of downloadable extras (deleted scenes, extended scenes, etc). The other stuff, online viewing, chat, etc. doesn't interest me so much.

Doesn't matter what we care about. It's a much needed selling point for a next gen format.

John
What is your reasoning?

Err.. You can't be farther away than assembler than it's possible to be. You can't be more abstract than an object heavy language like java.

Err...you missed my point completely. Because it appears that different CEs are using different implementations of BD-J, it is making coding more difficult for developers. Because there was just one implementation of HDi, it was a lot easier.

“Blu-ray players are light years apart,” says Wain. “Each of these boxes may have different JVMs"

This means either delevopers will have to create less optimized code that works with all JVMs (if possible) or multiple code sets for all the different JVMs.

Err...you missed my point completely. Because it appears that different CEs are using different implementations of BD-J, it is making coding more difficult for developers. Because there was just one implementation of HDi, it was a lot easier.

You were comparing BD-J with assembler... One is a high level abstract language and the other is a low level one step over the micro code of the hardware...

This means either delevopers will have to create less optimized code that works with all JVMs (if possible) or multiple code sets for all the different JVMs.

If they wanted a highly optimized coding engine they would not have chosen Java to start with. The point of java is to make it accessible to a multitude of platform not to be the super duper optimized engine. Accessibility trump performance with java.

What is your reasoning?
Unfortunately, it seems like HD Audio and Video isn't as big a selling point for Joe Public as we'd all like it to be. The majority of the public has a TV smaller than 50" and if it's even HD it's probably 720p. They also don't have an audio setup to take advantage of the HD audio options. So they just aren't going to notice the advantages that Blu-ray HD brings.

So, Blu-ray needs to add some other selling points. Since this is supposed to be the next generation format, it should be able to do more than just play movies. Interactivity and networking are value-adds (buzz word alert) that can be used to sell the product to people that might not get the HD benefits.

The BDA doesn't need to target the AV enthusiast at this point. If you care about picture and sound, you get Blu-ray, period. So now they need to target the general public and the general public likes buzz words and frivolous features.

This is, of course, completely my opinion and not based on any special knowledge. I know what sells my Dad and he couldn't be more Joe Public if he tried.

John

So it seems from reading all this that one of the biggest reasons that studios want BD to replace DVD are the (imagined) huge profits they can reap from all those neat interactive features, just as they tried to do with extras and "easter eggs" on DVDs that were cheap to produce but justified (in their greedy little minds) an extra $10-$15 for a 2 disc premium edition. Alas, for BD, all those profit-generating extra neat features are not so cheap (or easy) to implement, and just end up make the already expensive BD discs even more expensive. IMO, if BD fails, it will be because of the greed of the studios, not the merits (or perceived lack) of the HDM formats of either caliber.

Which from the looks of it they believe is accurate and in my opinion they are more likely to be objective about BD-J than someone who worked for Microsoft and promoted HDi for over 2 years.
I did not question them being objective. Let's review what one of them said:

"Yes, there are more things that you can potentially do in BD-J than you could potentially do in HD-i, but no one has reached that level yet."

So once more, no example is given of why Java is better in these applications. If there is an advantage, it must not be readily apparent and at any rate, the above quote says it is theoretical ("potential"). And hence my point of theory versus practice. A tool made for the user always works better than a tool made for everyone.

As I noted, they went on to give an example point out the opposite, that the core engine in HDi, being a native application, is much faster in generating graphics than Java code.

Disney did help develop HDi but last I checked Disney supported Blu-ray.
Disney put forth the requirement for HDi support in BD format prior to joining and announcing support. Unfortunately, other companies did not come along and they did not get what they asked for. It was very sad for them to see their vision come through in the form of HD DVD with its support from day one for their requirements rather than delayed roll out of BD profiles....

Unfortunately, it seems like HD Audio and Video isn't as big a selling point for Joe Public as we'd all like it to be. The majority of the public has a TV smaller than 50" and if it's even HD it's probably 720p. They also don't have an audio setup to take advantage of the HD audio options. So they just aren't going to notice the advantages that Blu-ray HD brings.

So, Blu-ray needs to add some other selling points. Since this is supposed to be the next generation format, it should be able to do more than just play movies. Interactivity and networking are value-adds (buzz word alert) that can be used to sell the product to people that might not get the HD benefits.

The BDA doesn't need to target the AV enthusiast at this point. If you care about picture and sound, you get Blu-ray, period. So now they need to target the general public and the general public likes buzz words and frivolous features.

This is, of course, completely my opinion and not based on any special knowledge. I know what sells my Dad and he couldn't be more Joe Public if he tried.

John

What world are we talking about? Joe Public could care less about BD-J or any added features for that matter. Sorry, but Blu Ray IS all about improved picture and sound quality and for all those where that is not important to, ( the majority of Joe Public) will not buy even with these buzz word features you are talking about!

Content companies are companies which well, create content :). Expecting them to become software powerhouses is not sound. That is not the core of their company. Same with others who support them for creative arts. HDi became what it was because we realized these guys could mix graphics with script and flash to create web pages and considered that a skill they had to have. Anything beyond would turn them into a Microsoft or Oracle. Given that pure software companies have trouble putting out bug-free software, there was little hope that content companies would be well off here.

Third point was also made earlier. That is, we warned the content companies that people would just slap any VM they could license and call it the day. But that would cause them huge grief, especially as second and third tier DVD manufacturers got into the market.

Having said all of this, they will have to make all of this work somehow so the situation will get better in the future. As noted above, they better get ready to spend a bunch more money on this stuff though to keep it going (both on development, test and customer support).

Amir

I know that ;) I am an IT guy dealing with all forms of technology from so much different business (Finance, Health, Manufacturing, Content development, and studios) :) I am not expecting them (Content creators OR publishers) to become a powerhouse for development. That is not their bread and butter. What I am expecting them (or any other company regardless of what line of business they are in) to have the RIGHT people to leverage what they are trying to push to the consumer.

IE Java developers at this time until tools come out to make it easy for a content creator to push out good quality Java code :)

Of course this is assuming a standard is in place for such things because even a strong Java developer will have their work cut out for them if there is little change here and there between systems.

Alas, for BD, all those profit-generating extra neat features are not so cheap (or easy) to implement, and just end up make the already expensive BD discs even more expensive.
That's the thing. To the extent one is unsure about the real benefits to the bottom line of such features, it is best to keep the burden at the minimum required level on implementers.

When Disney came and asked about these features, my first response was that the last thing they should have in the platform is something that resembles a PC or game console. Sure, both would more than satisfy any needs they might have now and in the future. But it takes an army of people to write and support those platforms. So what was needed was something far, far simpler. Something that was rich, but still manageable.

Even with the level of constrain we brought to HDi, it was an 800 page spec! As we always used to say at Microsoft, "software is hard." And the more of it, the harder it is. CE business is tough as it is when one doesn't have to carry such difficult burden as these interactivity systems represent...

I did not question them being objective. Let's review what one of them said:

"Yes, there are more things that you can potentially do in BD-J than you could potentially do in HD-i, but no one has reached that level yet."

So once more, no example is given of why Java is better in these applications. If there is an advantage, it must not be readily apparent and at any rate, the above quote says it is theoretical ("potential"). And hence my point of theory versus practice. A tool made for the user always works better than a tool made for everyone.

As I noted, they went on to give an example point out the opposite, that the core engine in HDi, being a native application, is much faster in generating graphics than Java code.


Disney put forth the requirement for HDi support in BD format prior to joining and announcing support. Unfortunately, other companies did not come along and they did not get what they asked for. It was very sad for them to see their vision come through in the form of HD DVD with its support from day one for their requirements rather than delayed roll out of BD profiles....


Amir,

It is best to leave the format war rhetoric at the door from now on.

HDi may have been better, but at this point it really does not matter. BD-J is what the industry has to live with. Frankly, I am not that excited by it, but BD-J is not totally impossible to develop.

I know my 4-year old loves playing the car finder BD-J game on Cars. So I am slightly interested in seeing what Disney does with it on their Sleeping Beauty BD.

Amir

I know that ;) I am an IT guy dealing with all forms of technology from so much different business (Finance, Health, Manufacturing, Content development, and studios) :) I am not expecting them (Content creators OR publishers) to become a powerhouse for development. That is not their bread and butter. What I am expecting them (or any other company regardless of what line of business they are in) to have the RIGHT people to leverage what they are trying to push to the consumer.
Peace :).

IE Java developers at this time until tools come out to make it easy for a content creator to push out good quality Java code :)
The resident Java man used to say the same thing here for the last four years. I just did a quick search and this popped up:

Don't confuse the tools with the platform. BD-J's more flexible platform will support a much wider variety of tools. Tools for creative non-programmers will shield the platform complexity (and can provide an interface exactly like that of the existing HDi tools), while programmers can use development tools which provide direct access to the full range of API's. Take a look at tools like Ensequence's On-Q Create (http://www.ensequence.com/products/on-q_create/), which was demoed at a BD-J User Group meeting in Los Angeles earlier this month. It's a very rich environment which non-programmers will be very comfortable with, yet can take advantage of the full range of BD-J API's. It may have taken a bit longer for tools like this to emerge, but within the next six to twelve months you're definitely going to see content emerge which blows away anything you've seen so far (and, I believe, will exceed anything you'll see on HD DVD).

- Talk
So the post was from March of 2007. It is now 16 months later. I am not sure which title has blown away HD DVD. And this article clearly says that even with tools, the environment is tough to deal with. See the point regarding graphics being slow and such. A tool doesn't solve that problem. Nor the issue you raise below (although it could help a bit):

Of course this is assuming a standard is in place for such things because even a strong Java developer will have their work cut out for them if there is little change here and there between systems.

Amir,

Lol

look at that! So we are on the same page. ;)

Peace :).


The resident Java man used to say the same thing here for the last four years. I just did a quick search and this popped up:


So the post was from March of 2007. It is now 16 months later. I am not sure which title has blown away HD DVD. And this article clearly says that even with tools, the environment is tough to deal with. See the point regarding graphics being slow and such. A tool doesn't solve that problem. Nor the issue you raise below (although it could help a bit):

Amir it is best to just ignore posts slamming HD DVD. Everyone here knows that you had a vested interest in the war. Fanning the flames of war here is not going to help.

Amir it is best to just ignore posts slamming HD DVD. Everyone here knows that you had a vested interest in the war. Fanning the flames of war here is not going to help.


He is not.

He is replying to my post. My post has nothing to do with HD-DVD. It has everything to do with having the right people for the job. Java is a monster. To learn it, it will take either prior programming experience in just about any language or learning Java clear out OR having tools that will do the coding ( optimized as much as a Visual tool can do) for the content developer on a push of a button (Right tool for the job).

I understand Java and what it can do. In the end, as with any other language.

Garbage in, Garbage out.

He is not.

He is replying to my post. My post has nothing to do with HD-DVD. It has everything to do with having the right people for the job. Java is a monster. To learn it, it will take either prior programming experience in just about any language or learning Java clear out OR having tools that will do the coding ( optimized as much as a Visual tool can do) for the content developer on a push of a button (Right tool for the job).

I understand Java and what it can do. In the end, as with any other language.

Garbage in, Garbage out.

I agree, but to say that no BD-J title has accomplished more than what HDi could do may be inaccurate. While nothing may have "blown away" HD DVD, did any HD DVD title ever have in-movie games like the Car Finder example above? Never having owned the format, I am not sure, but I don't remember hearing anything about this.

What world are we talking about? Joe Public could care less about BD-J or any added features for that matter.
If that were the case, wouldn't they have dropped this type of feature on DVD by now? It adds to the cost and if it's not helping sell, it should have be dropped. That doesn't seem to be the case though. Superbit, which most here would prefer, didn't do very well in the general public. Placed side by side with a extra laden DVD, Joe is going to going to choose the extras laden DVD over the Superbit (cost being the same).

Joe Public likes to get the most for their money (who doesn't). Fill up the back of the case with extras and buzz words and they'll feel like they are getting more; even if they never use it. BD can't take a step back in this regard and should be taking a step forward. BD-J features, if implemented properly, is a huge step forward and a good selling point. Blu-ray needs it.

John

I agree, but to say that no BD-J title has accomplished more than what HDi could do may be inaccurate. While nothing may have "blown away" HD DVD, did any HD DVD title ever have in-movie games like the Car Finder example above? Never having owned the format, I am not sure, but I don't remember hearing anything about this.

I don't think there is anything on HD DVD like that. edit: Chicken Little has a Space Invaders type game as well and POTC Liar's Dice. Not sure if HDi has anything like those.

What are the differences in picture in picture abilities?

....more than what HDi could do

Stop right there.

Could? Well in the end it is irrelevant as the only people that know what HDi can do (all nuts and bolts) is Microsoft and we might see it as part of Silverlight (if it is not already in there). But beyond that.

There are a lot of "could/should/would". I myself do not like the "what if" game =)

If that were the case, wouldn't they have dropped this type of feature on DVD by now? It adds to the cost and if it's not helping sell, it should have be dropped. That doesn't seem to be the case though. Superbit, which most here would prefer, didn't do very well in the general public. Placed side by side with a extra laden DVD, Joe is going to going to choose the extras laden DVD over the Superbit (cost being the same).

Joe Public likes to get the most for their money (who doesn't). Fill up the back of the case with extras and buzz words and they'll feel like they are getting more; even if they never use it. BD can't take a step back in this regard and should be taking a step forward. BD-J features, if implemented properly, is a huge step forward and a good selling point. Blu-ray needs it.

John

Sorry but I think you give the average consumer too much credit. Most of them like things simple, adding things they don't understand will not entice them to buy a product but will instead shy them away. Buzz words will work in different ways with different segments of the population and thats the way it's always been . BD should stay focused on the improved PQ/AQ, whether that only is enough to further penetrate the market, who knows but it is obviously it's biggest selling point and thats something the average consumer should be able to understand when making a purchasing decision.

Sorry but I think you give the average consumer too much credit. Most of them like things simple, adding things they don't understand will not entice them to buy a product but will instead shy them away.
I've given an example (Superbit DVD) to validate my point. Can you give me a real world example to support you're thoughts?

Not saying you're right or wrong, but it doesn't jive with my experience.

Another example is TVs. Take a look at the touted features. How many of those features actually improve the picture? A lot of those features, if you really care about picture quality, should be turned off. But there they are, front and center, being used as selling points. Joe Public probably doesn't need that superDuPeR FluxRemitter, but by golly he'll pick the TV that has it over the one that doesn't. Even if he doesn't know what it does. :)

Anyway, I think we might be getting off topic here.

John

I've given an example (Superbit DVD) to validate my point. Can you give me a real world example to support you're thoughts?

Not saying you're right or wrong, but it doesn't jive with my experience.

Another example is TVs. Take a look at the touted features. How many of those features actually improve the picture? A lot of those features, if you really care about picture quality, should be turned off. But there they are, front and center, being used as selling points. Joe Public probably doesn't need that superDuPeR FluxRemitter, but by golly he'll pick the TV that has it over the one that doesn't. Even if he doesn't know what it does. :)

Anyway, I think we might be getting off topic here.

John

Just the Feedback I get from talking to the average folks who are not into this stuff. Like I said it could entice some but shy away others. Alot of these people can not operate a remote control let alone what some of these features do. The word I always get is they like things Simple, yes this does consist a segment of the population, how much? who knows. I do not have any Scientific data to support this claim but that doen't mean it does not exist as I have witnessed first hand. We could both be right or we could both be wrong however I do believe we are still talking on-topic. ( BD-J ).

Err...you missed my point completely. Because it appears that different CEs are using different implementations of BD-J, it is making coding more difficult for developers. Because there was just one implementation of HDi, it was a lot easier.



This means either delevopers will have to create less optimized code that works with all JVMs (if possible) or multiple code sets for all the different JVMs.

While I'm not a believer of all these interactivity stuff, I have to point out that there's hundreds of millions of JAVA enabled phones out there from about a dozen major manufacturers. The java games CAN be made to work on pretty much all of them, unless people use the advanced esoteric features that work on only the most advanced ones. I've seen chess, breakout, solitaire java implementations that are very portable.

The disconnect is in studios wanting PS3-like graphics performance under java and the reality of what the chips from Sigma, Broadcom, NEC, Matsushita can deliver. Plus, noone in the chain wants to pay for the ps3-power on the box players that are driving towards the sub $100 retail number, so the chip makers don't want to put in features their customers are not willing to pay for. At least so far anyway.

Err...you missed my point completely. Because it appears that different CEs are using different implementations of BD-J, it is making coding more difficult for developers. Because there was just one implementation of HDi, it was a lot easier.

This means either delevopers will have to create less optimized code that works with all JVMs (if possible) or multiple code sets for all the different JVMs.

This is not true. There is only one BD-J spec, developers code to that specification. If a particular application doesn't work on a particular implementation of BD-J, then it is a bug on that implementation and should/will be fixed by that CE company. Some CE companies will chose to fix it slowly or perhaps not all together, so the consumer will loose on that front. However, most CE companies will do their best effort to fix their stack for any discs which do not work, as most all of the big ones get proof discs from most studios well in advance of the disc release.

Also, the only reason there was only one implementation of HDi was that Toshiba/MS was the only ones in the game. Is there something specific to HDi that says only one software team can develop the HDi stack? Imagine if all the major CE companies created their own HDi implementations. You would see similar problems.

As I noted, they went on to give an example point out the opposite, that the core engine in HDi, being a native application, is much faster in generating graphics than Java code.



I'd be interested in seeing any performance benchmarks to back up such statements. Graphics benchmarks are very easy to implement. Simple blit, font rendering, FAA benchmarks are readily available, at least on the BD-J certification discs.

I'd be interested in seeing any performance benchmarks to back up such statements. Graphics benchmarks are very easy to implement. Simple blit, font rendering, FAA benchmarks are readily available, at least on the BD-J certification discs.

I'm sure that there are benchmarks to exercise, but they would need to be compared on the same platform, with an HDi engine written to that target machine. Java itself is necessarily slower than native mode applications, since a layer of interpretation is present there that is not present in native mode (in this case HDi).

The mechanics are:

1. Java program -> JVM -> machine language.
2. Native mode -> machine language.

Skipping that step makes it faster. The tradeoff is that you get portability of code with Java, since it is not as reliant on the code -> hardware metaphor as native mode is.

In larger computers (PC's and up, probably including the PS3) the point may be moot in that the performance is good enough that it papers over the JVM performance hit, but if you are trying to put out a product but trying to save on the processor, the performance of the JVM may work against you.

So by analysis of the architecture, Java is slower. If you select faster, more expensive components, this becomes much less of an issue. That's the conundrum that companies trying to release less expensive Bluray machines are faced with, along with the development costs.

The mechanics are:

1. Java program -> JVM -> machine language.
2. Native mode -> machine language.


This is not really true. HDi applications are by no means native applications. HDi applications (correct me if I'm wrong), are essentially XML, CSS, and JavaScript (read: AJAX).

This is not native code. This still needs to be interpreted by a scripting engine and rendered. The AVSForum.com website you are reading now is HTML, it is rendered by a native browser.

Your #2 should have been: XML/JavaScript -> ScriptingEngine -> native/machine.

The performance debate between AJAX vs Java is always there, that is for another forum though. My original query was if anyone actually took an embedded platform and ran graphics benchmarks on both an HDi and BD-J implementation. My guess is no, since that would take a lot of resources and is rather moot at this point.

This is not true. There is only one BD-J spec, developers code to that specification. If a particular application doesn't work on a particular implementation of BD-J, then it is a bug on that implementation and should/will be fixed by that CE company. Some CE companies will chose to fix it slowly or perhaps not all together, so the consumer will loose on that front. However, most CE companies will do their best effort to fix their stack for any discs which do not work, as most all of the big ones get proof discs from most studios well in advance of the disc release.

That is not what the article says...

“Blu-ray players are light years apart,” says Wain. “Each of these boxes may have different JVMs in them--Java Virtual Machines--depending on the manufacturer and which JVM they’ve licensed into their box. So they act quite differently, and one of the things we’ve discovered about working in BD-J is that you can fix one BD-J problem on one player and introduce another problem on another player.”

But isn’t a standard a standard and a spec a spec? “There’s a spec that is handed to all the producers, and there’s a mirror of that spec that’s handed to the player manufacturers, but there are different interpretations of that spec,” says Wain.

That is not what the article says...

Actually, if you read it again, the article is saying exactly my point.

Again, there is only one BD-J spec, and only one. Developers will develop to that spec. The spec is very large, it covers lots of features that many applications will never use. Since it is a programming API, it can also be misused by a developer who doesn't know what he/she is doing. If a studio develop finds a problem in is app on player A, it is entirely possible his fix (proper or not proper) will not work so well on player B. That all depends on how well either player's company has developed their BD-J implementation.

The developer writes his code in a BD-J simulator which has passed all API certification tests. Generally the problems with BD-J applications are not crashes, but performance of rendering on slow players. Exposing a player's slow graphics pipelines is very common. This has nothing to do with the BD-J spec, and everything to do with the particular implementation. And ofcourse, how well the developer has written their code.

The developer writes his code in a BD-J simulator which has passed all API certification tests. Generally the problems with BD-J applications are not crashes, but performance of rendering on slow players. Exposing a player's slow graphics pipelines is very common. This has nothing to do with the BD-J spec, and everything to do with the particular implementation. And ofcourse, how well the developer has written their code.
Very good points overall. Just one comment though: the spec does have something to do with it. BD-J started life from lifting a ton of APIs from settop work in Europe. A lot of that functionality was not and is not needed for an optical platform. This increases the "surface area" for bugs and issues substantially versus a system built just for optical media. Take BDMV mode for example. It is designed from ground up for optical so there are far fewer issues with it than BD-J. HDi was larger and hence had more issues. BD-J is much, much larger yet again, making the problem worse.

Again, no disagreement with your overall point :).

This is not really true. HDi applications are by no means native applications. HDi applications (correct me if I'm wrong), are essentially XML, CSS, and JavaScript (read: AJAX).
That is not correct. HDi has built-in primitavies that are executed by the core engine. For example, I can define a menu item graphics and tell it to animated it (in SMIL) in just one line. There is no code drawing it in one place, erasing it and then drawing it at the next pixel so that it slides onto screen. No script code is executed to make the animation work. It is all running using optimized code in the HDi executable which has been written by the equipment maker not application developer.

This is not native code. This still needs to be interpreted by a scripting engine and rendered. The AVSForum.com website you are reading now is HTML, it is rendered by a native browser.

Your #2 should have been: XML/JavaScript -> ScriptingEngine -> native/machine.
HDi was more than a browser with scripting. It was a browser with an integrated graphics engine. The better example is Flash than a browser. We talk about it in terms of browser since that is the context that is easier to understand. But it is more than that.

My original query was if anyone actually took an embedded platform and ran graphics benchmarks on both an HDi and BD-J implementation. My guess is no, since that would take a lot of resources and is rather moot at this point.
The article specifically talks about it. Just read it again. It is not a matter of graphics being faster per-se but rather, in the context of the application here, the native engine being able to do things that requires Java in the other system as was correctly noted.