Skip to main content

Fill bookmenu's (BDLocator[])MenuDiscNavigator.sceneVideoStartPL from Show?

5 replies [Last post]
ken2006
Offline
Joined: 2008-07-22

Hi, I'm looking for a way to pupulate at runtime, the (BDLocator[]) sceneVideoStartPL array in MenuDiscNavigator, using the playListMarks that are already defined in the compiled show file.

This would replace the hard-coded field-initializer (bd://1.PLAYLIST:00001.MARK:00002-00006) that exists now, and help automate compiles where there are varied numbers of marks.

Can anyone suggest a best way to do this? I'm not sure but it appears I could read the Segment[] from Show, though I'm unclear how to determine which segments are those declared in the .xml or in the grin/show file (I presume the .xml playListMarks are also copied-into the show file and thus accessible at runtime?).

And any impact of initializing the array in a static block or lazy-initializer inside of MenuDiscNavigator, or is this best done in a initXlet() method?

Thanks,
Ken

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
chihiro_saito
Offline
Joined: 2006-11-08

Hi Ken,

.xml files are just a human readable form of the BDMV/PLAYLIST/
.mpls binary files. This mpls file format is defined by the Blu-ray spec. Grin and it's show file know nothing about it or have any use of it during compilation. Indeed, by hard-coding these sceneVideoStartPL locators, the hdcookbook's MenuXlet assumes that it will be running on a BDMV disc structure that contains a playlist file named 00001.mpls that has PlayMark 2 to 6 in it.

I imagine that it's not too difficult to parse the playlist.mpls (or even
.xml if you choose to) to find out all the PlayMarks in that playlist file and dynamically generate corresponding locator strings. One can do this during the xlet compilation time and store them in a property file, or generate an additional .java file that also gets compiled with your xlet etc, to be used at runtime. There's a playlist tool under hdcookbook DiscCreationTools/playlist that converts mpls to xml and back. You can probably take some parsing logic from there.

As for the timing to initialize the array - if it's just about creating a handful of BDLocators, I believe it's not going to be any noticeable performance hit whenever you do it.

Best,
Chihiro

ken2006
Offline
Joined: 2008-07-22

Thank you Chihiro! I think the cleanest implementation would be as you suggest, to runtime-parse the playlist files, although the MPLSObject seems like it might be a little heavywiegtht for getting the BDLocator strings.

Some questions if I may:

Am I likely to have JME issues (memory or speed or portable-ness) if I just integrate the entire PlayList tool onto the disc?

Do you know if "ISO646-US" (StringIOHelper.readISO646String call in readObject) is guaranteed to be safe on all BD devices, or if not can we safely use 8859-1 or UTF-8?

chihiro_saito
Offline
Joined: 2006-11-08

Hi,

My suggestion is to do the parsing during the xlet _compilation_ time, on a desktop machine that you're running javac and other tools for constructing a disc image, and not during the xlet runtime. I suppose that by the time you're compiling your xlet, you have all other disc assets including playlist that you'll be running your xlet with.

The playlist tool won't run as a BD-J app since it uses jdk 5 language features and JAXB for xml handing etc. I don't remember off the top of my head if ISO646-US is available on CDC 1.0...

Thanks,
Chihiro

ken2006
Offline
Joined: 2008-07-22

Thank you, and I agree, compile time storage is best due to the Playlist tool's 1.5 language bindings. I will proceed as advised and store the playlist data separately.

Do you know if a lightweight runtime PlayList parsing utility (1.3 based, i.e no XML, enums, annos) may be included in future? It seems to be a very useful idea to read the data from PlayItem, ClipInfo, STNTable etc at runtime, vs storing some of the same data separately.

Thanks again,

Ken

chihiro_saito
Offline
Joined: 2006-11-08

Hi Ken,

> Do you know if a lightweight runtime PlayList parsing utility (1.3 based, i.e no XML, enums, annos) may be included in future?

I don't think it's hard to do this technically, but I doubt that we'll do it. Some playlist info are accessible through APIs, and even if some low level info in playlist are needed by the app, these playlist files are static (won't be changing during xlet runtime, that's what I mean) that it'll be much wiser to do the parsing offline.

Hmm, though, one can dynamically change the playlist with VFS update. Wonder if there can be some uncommon use case there where xlet can't be updated and need to adjust to a random new playlist or something...

Anyhow, hope your app goes well!

Chihiro