Bluray authoring: Could I put some image files into AUXDATA folder?

[hxuanyu]

Hi,

I'm developing BD-J menu for Bluray authoring. As you know resources used by BD-J menu are usually included in corresponding JAR files, but for some reason I can't do this.

So I have to put several png images into a DBMV folder and when BD-J menu is run, read them out from file system.

I've checked BDMV application specification roughly, it only says what files should be in each folder, like videos should be in STREAMS, playlists in PLAYLIST. So I'd like to know if I could put these images into AUXDATA which is said to contain bonus contents. (actually I've only seen sound.bdmv and some font files could be placed in that folder, but no one mentioned if any other file could be placed in this folder)

So what I'm worrying about is, although I could definitely put images into that folder and burn a Bluray disc. Is it possible that when it's played on some players, because those images are not file types SHOULD be in that folder, then BD-J JAR code fails to read them?

Thanks for your help

[Cornucopia]

Haven't done much BD-J stuff (BDMV mostly), but if what you are using is an intrinsic element of the JAR's usage, AFAIK it needs to be in one of 3 places:
1. Muxed into the appropriate M2TS.
2. In the JAR file(s).
3. online somewhere (rare, but possible)

The AUXDATA folder is specifically for HDMV/BD-J event-based sound objects & OTF fonts - ONLY, IIRC.

But what I don't understand is why you are worrying about this at all - the authoring application that you are designing the BD-J app(s) in should place that stuff FOR YOU when doing the compiling/muxing phase.

If for some reason the authoring app isn't letting you encapsulate the menu, maybe it's because of some other incompatibility that needs to be addressed first...

Scott

[hxuanyu]

But what I don't understand is why you are worrying about this at all - the authoring application that you are designing the BD-J app(s) in should place that stuff FOR YOU when doing the compiling/muxing phase.
Scott

Thanks Scott,

Actually I'm noting using an authoring application to design a menu. In fact we are developing our own Bluray burning/authoring application. Unlike those sophisticated authoring tools in which user can design menu totally as you want, our application only provides some template to choose. So user can't change the layout, button position, etc, but can only import like a background image.

So the way we implement our app is, precompile JAR files and put it into application installer. When user customized a background image in our application and burn, copy the image to a pre-specified folder from which JAR code will read. In this way, we don't need to recreate and sign JAR every time user makes a change to the template.

As I said I'm not sure if putting the image file into AUXDATA will cause problem on some players. I'm afraid if some player will block me from reading files other than font files and sound.bdmv from that folder.

Maybe I can do some hack like naming the image to xxx.m2ts and put it into STREAMS. Because it's named m2ts so I could always access it. Because only BD-J menu actually uses it so it shouldn't break other part of the disc (Could anyone confirm me if I put an invalid m2ts file into STREAMS and it's not referenced anywhere, will the disc be able to be played in ALL Bluray players?).

Thanks for any suggestion

[Cornucopia]

I know it costs $$$, but I strongly suggest that, unless you have the time & energy to devote to reverse-engineering, you license the BD-J spec so that you know all the whats, whys & wherefores of your options. Otherwise, you will be fighting an uphill battle with the possibility of your stuff not being fully supported by players, or worse - crashing them.
Muxman did it (RE) with DVDs, maybe you could do it with BDMV & BD-J!?! - that would certainly crack the authoring bottleneck open.

M2TS does NOT just play on it's own: it is controlled by Playlists (MPLS) which is in turn controlled by the BDMV application & navigation info packets. It all is linked together. That's why it needs to be properly authored as a whole.

Scott

[hxuanyu]

M2TS does NOT just play on it's own: it is controlled by Playlists (MPLS) which is in turn controlled by the BDMV application & navigation info packets. It all is linked together. That's why it needs to be properly authored as a whole.

Scott

Thanks Scott, thanks for your reply, but the license thing is not something myself can decide right now

Let me ask a simple question, if I rename an image file to m2ts and put it into STREAMS (it's not referenced anywhere), will all players just ignore it and play the disc as if there's not such a file? (or the behavior is not defined in spec)

Great thanks

[johns0]

All players will ignore the m2ts file since it isn't referenced,do a test burn and try it out.

[hxuanyu]

All players will ignore the m2ts file since it isn't referenced,do a test burn and try it out.

All players ignore it means it won't break/crash the player itself.

So as long as our JAR can successfully read it, then our BD-J menu works.

[Cornucopia]

If players ignore it, it won't get used by anything. If your JAR uses it, that means players should/will see it and attempt to act on it. But in embedded systems (such as BD-J), the Java VM becomes a true, physical machine. However, machines (virtual or real) can break or be made/designed to break if they don't follow tried & true methods/application lines.

STREAMS is for true M2TS files, referenced or not. Look at what has happened in the past with Hollywood titles that use unreferenced broken/looped sectors - while they sometimes work, they also sometimes freeze up a machine, as well as make it difficult to copy.

If you want to try externally referenced material, try it in a proper place, such as an OTHER or ROM folder.

Scott

[hxuanyu]

If players ignore it, it won't get used by anything. If your JAR uses it, that means players should/will see it and attempt to act on it. But in embedded systems (such as BD-J), the Java VM becomes a true, physical machine. However, machines (virtual or real) can break or be made/designed to break if they don't follow tried & true methods/application lines.

STREAMS is for true M2TS files, referenced or not. Look at what has happened in the past with Hollywood titles that use unreferenced broken/looped sectors - while they sometimes work, they also sometimes freeze up a machine, as well as make it difficult to copy.

If you want to try externally referenced material, try it in a proper place, such as an OTHER or ROM folder.

Scott

Great thanks Scott,

Do you mean, I could create a folder under BDMV named OTHER? Actually I'm quite new to Bluray authoring so please forgive me if my question is too naive

[Cornucopia]

I'm not sure. Either under BDMV if that is possible, or under ROOT.

Scott

[jgae]

Hi,
I've a similar question: What would be a good place for a jpg-file containing the cover image for a self-made compilation? Currently I put it under CERTIFICATE, created there a folder named "Cover" and stored there the cover image or images.
Up to now I did not been suffered by any harm but I checked it always only at one and the same player.

[Cornucopia]

No. Under the BDMV folder umbrella O*N*L*Y items which are BDMV/BD-J-compliant and which were generated by the authoring app should reside inside! Same goes for PRIVATE/AVCHD for AVCHD/AVCHD2/AVCHDlite and VIDEO_TS for DVD-Video and AUDIO_TS for DVD-Audio.

Things that are other should be in a branch off the root.

It's very likely no harm would be done, but then who knows if you find a device that is strict with compliance and crashes because of that? Much better to just follow the protocol and avoid that problem altogether.

Scott

[Cornucopia]

@charlene,

First, nobody was talking about Scenarist. Yes, it is an authoring app, but we were talking about compatibility with the spec, not with a specific app. Scenarist was just one of the most advanced implementations of that spec.

Second, it is not "5.6 now". Scenarist is NOT AVAILABLE ANYMORE in any version. 5.6 was the last version, AFAIK, but it stopped being sold in ~2011.

Very Recent news: Hopefully it will be soon resurrected by "Scenarist.LLC" (I.P. bought away from Rovi), and my guess is that it will incorporate the upcoming 4k extensions to BD.

Scott