More complex samples from Microsoft, any ETA?

Hi Microsoft,
I (and I'm sure everybody in this forum) am waiting for the more complex (and close to real iHD apps) samples from you. Do you have any ETA

Thanks,
-k

Audio and Video Development3

Yes this is basically what I was fishing for too in my request for more resources.

We apologise for the delay in getting these out; we are aiming to get better samples released soon.

OK, they are on the web at

http://www.microsoft.com/downloads/details.aspx FamilyId=E19C869B-EF37-4E5E-91ED-32D059E3775B&displaylang=en

Sorry for the long delays...

Hi,

did anyone got the samples "AdvancedTechniques" or "rotatingMenus" to run outside hdisim

Greetings ds

After some small debugging you can play them on any hd-dvd player. Xpath Variables are an awesome way to code HDi. Debugging is funny though because the Microsoft Validator doesn't parse the .js for the Xpath stuff and the Sonic Simulator Trace.exe gives this error:

"This.getcurrentmenu() is NULL"

line 130
pos 5
in architecture.js

Plays fine in my 360 HD-DVD player and in the HD-A1 though. It's an interesting case of both de****s not recognizing Xpath correctly but the actual hardware player play it fine. The playback in my 360 is so smooth. You can flip through menus quickly and all inputs are very responsive...even more so than current retail discs.

Excellent work Peter and Team!

Hi Sammaz,

What changes you made after "small debugging" Can you give me a clue

Greetings
ds

One known issue is that the "Rotating Menu" sample won't work on the Toshiba player, unless you get an AACS disc made (ie, burnt discs don't work), although it will work on the emulator and the Xbox 360. Hopefully this issue will be addressed soon.

In the mean time, you can work-around the problem by changing the script that sets backgroundImage to change backgroundFrame instead, and by specifying all the possible thumbnail images for the buttons in the markup file. (This can be done via referential styling, so you don't need to copy-paste the image names on to every button).

One known issue is that the "Rotating Menu" sample won't work on the Toshiba player, unless you get an AACS disc made (ie, burnt discs don't work), although it will work on the emulator and the Xbox 360. Hopefully this issue will be addressed soon.

In the mean time, you can work-around the problem by changing the script that sets backgroundImage to change backgroundFrame instead, and by specifying all the possible thumbnail images for the buttons in the markup file. (This can be done via referential styling, so you don't need to copy-paste the image names on to every button).

Thanks Peter for all your valuable contributions!

Unfortunately, Toshiba STILL didn't adress this grave issue, even with Firmware 2.7. My HD-E1 still gives an error "408bc00b" when trying a project derived from the rotatingMenus sample (the project validates perfectly and runs well in the sim and in PowerDVD). Therefore, some questions from my side:

Do you have an idea how to communicate with Toshiba about such things (my project has hobby status right now, they won't listen to me :-)
What are the limitations of this workaround (how many frames are possible per backgroundImage And how is this situation handled in memory I'll have dozens of images in 1920x1080 to switch between them and worry about the performance impact* - how can I control when the image really gets loaded into the player's memory: will .style.display="none" suffice to unload an image from the pixelbuffer

I'll hack around a bit and see what happens. This bug however is indeed very frustrating.

*especially becaus of this post in a separate thread:

I would make sure you have the images loaded into the filecache (by including them in the manifest and playlist resource lines).

Another option would be to load the files using the FileIO APIs into the filecache.

If the files are loaded into the filecache, make sure you are not exceeding the pixel buffer.

c00b means that one of the resources in the playlist is listed with a size that is too small or missing all together. Run the validator on your project - it should tell you what the problem is

setting style.display to none will remove the image from the pixel buffer. When you set display to auto, there is some decode time, especially with a full screen image. Setting style.visibility to hidden does NOT remove the image from the pixel buffer. So, if decode time is an issue for you, set visibility to hidden and display to auto, and only change visibility when you are ready for it to be displayed (though, timing on this could be tricky with full screen images)

I don't have the spec in front of me, so I don't know what the limit on backgroundFrames is, though, it should be suffiently high enough...if not, you should be able to work around any limitation with multiple divs.