BD-J

 BD-J is an interactive mode intended for advanced interactivity, such as fancy menus and video games. It is more advanced than HDMV mode as it supports object-oriented programming, complex animations, true-color graphics, more memory, and networking capabilities. Major and mini-major studios often use BD-J for their custom programming framework that suits their needs without the restrictions of HDMV.

 

 

 

 

 

Features

FIG.1: BD-J System Overview
BD-J supports all the default features from HDMV but has additional exclusive ones:

  • Bookmarks - Bookmarks allow you to bookmark your favorite scenes in the movie. They are saved in the player's local storage or persistent storage.
  • Virtual File System - The Virtual File System is to access content in the player's local storage.
  • Local Storage - Local storage is used to install content from the disc or download content from a network. Profile 1.1 players have a mandatory storage of 256MB. Additional storage can be added.
  • Network Access - BD-J applications can access a local network or an internet connection (examples: RSS feeds, multiplayer, upload high-scores, downloads, local transfers, etc.)
  • Colored Buttons - All Blu-ray remotes have Red, Green, Blue, and Yellow colored buttons for additional interactivity.
  • Object-Oriented Programming - BD-J provides an open and flexible programming environment for BD-ROMs.
  • BD-J Background - Adds a background behind the Primary Video layer. 

 

 

 

 

Java Runtime and Virtual Machine

BD-J is based on Java ME and its core computing platform is built upon Personal Basis Profile 1.0., which consists of Foundation Profile 1.0 and Connected Device Configuration 1.0. This mode uses a high-level programming language called Java for Java Programs. The Java Virtual Machine is inside the Java Runtime Environment, a software platform that provides an environment (runtime libraries) required to run Java applications. Since BD-J is based on Java ME, programming classes are restricted to Java 1.3, meaning anything above that is incompatible.

FIG.2: Overview of Java application tables
BD-J is also based on the GEM and MHP standards. MHP is an open middleware system standard designed by Europe's DVB for interactive digital television. The MHP enables the reception and execution of interactive, Java-based applications on a TV set. Globally Executable MHP (GEM) is an international standard based on MHP for the non-European TV markets often used on terrestrial, satellite, and cable set-top boxes and TV sets for interactive content. BD-J is based on GEM 1.0.2 which in turn is based on MHP 1.0.3. Other GEM platforms equivalent to BD-J are DVB-J (Europe), OCAP-J (U.S. Cable), ACAP-J (N. America), ARIB-J (Japan), and Ginga-J (S. America). Since all these platforms are based on the common GEM-core, it made it possible for developers to write Java applications that will run interoperably on all these systems.

    See: Java Language

A BD-J program is called an Xlet (similar to Applet). A BD-J Object file (BD-J's equivalent to a Movie Object) is a "table" of Java applications (Xlets) that trigger playlist playback, other Movie or BD-J Objects, and Java programs. 

Java classes and assets are stored inside a JAR file in the JAR directory. A JAR file size limit is only 4 MB (as per HD Cookbook and blu-play.com guidelines for compatibility). However, assets can be stored outside the JAR file as the Xlet can control everything in the disc's directory (video, audio, objects, files), GPRs/PSRs, persistent storage, and the virtual file system that reads/writes/installs content in the player's local storage. The Xlet can also control the video playlists, multi-angle, and playback speed.

For the Xlet to have access to everything, a BD-J Blu-ray disc must come with a Security Certificate. Since Java is a robust programming environment (that includes the ability to access the internet), it is vital to protect the player from unintended content and malicious code such as a virus. Signed apps have full permissions, while unsigned ones are sandboxed.

The Java virtual machine loads the xlet program that constitutes an application onto the work memory, decodes the Xlet program, and controls the lower layers based on the decoding results. More specifically, in the control of the lower layers, the Java virtual machine issues a Java Media Framework (JMF) method to a BD middleware (not illustrated) so that a function call corresponding to the BD playback device replaces the existent function call, and issues the function call after replacement to the playback control engine. BD-J also incorporates APIs from HAVi for UI rendering and org.bluray/davic packages for resource and media control. 


Application Manager

Whenever a title-to-title branch (Title Jump) takes place, the application manager directs the Java virtual machine to automatically launch any application that:

  • FIG. 3: Application Manager
    is not currently running in the source Title, but  
  • carries the AutoRun attribute for the destination Title.

Simultaneously, the application manager terminates any application that:

  • is active in the source Title, but  
  • has no defined lifecycle (i.e., is not bound) in the destination Title.

Both the startup and shutdown decisions are driven by consulting the application management table associated with the current BD-J Object.

When a title branch occurs, the module manager sends an activate(bobj_id) notification to the application manager. On receiving this signal, the application manager:

  1. Updates its internal reference so that the current BD-J Object corresponds to the supplied bobj_id,  
  2. Consults the application management table of that BD-J Object,  
  3. Determines which applications should be auto-started and which should be terminated.

In Figure 4, the markers indicate the following sequence:

  • ★0 : A Title Jump is triggered  
  • ★1 : The module manager issues notify activate(bobj_id)  
  • ★2 : The application manager refers to the application management table  
  • ★3 : The application manager instructs the Java virtual machine to launch the designated application(s)  
  • (★4, ★5) : As a result of the startup command, the Java virtual machine loads the corresponding Xlet program(s) from local memory into work memory.

This mechanism ensures seamless and correct application lifecycle management across title boundaries during Blu-ray Disc playback.



User Event Manager

The User Event Manager categorizes incoming user events from the processing unit into two main groups:

  1. Playback control events (★1) handle commands that direct media playback, including instructions to:
    • FIG.4: The process of the User Event manager to the
      Default Operation Manager 
      Play
    • Stop
    • Pause (On/Off)
    • Resume from still mode (Still Off)
    • Fast Forward (with a specified speed)
    • Rewind (with a specified speed)
    • Switch audio track
    • Change subtitle
    • Switch viewing angle
  2. Key events (★2), in contrast, correspond to presses of navigation and numeric keys on the remote control: Move Up, Move Down, Move Left, Move Right, and the number keys (0–9).

 (★3) Function calls are issued to the playback control engine based on the user events for playback control.

 This separation allows the BD-J runtime to efficiently route playback-related commands directly to the player engine while forwarding interactive/navigation inputs to the Java application for menu handling and other on-screen responses.

 

Event Listener Manager


The Event Listener Manager examines incoming key events and routes them appropriately. As shown by the solid arrows (◆1 and ◆2), the manager handles distribution as follows:
  • If the key event matches one that has been explicitly registered via an EventListener in the currently active Xlet program, often corresponding to the Java Media Framework (JMF), the manager forwards it to the relevant Xlet. This Xlet is typically referenced indirectly through the BD-J Object associated with the title. Once received, the registered listener in the Xlet triggers the application's custom response, effectively activating or controlling interactive behavior.
  • If the key event is not registered with any EventListener in the Xlet, the manager instead passes it to the default operation manager (or player engine fallback handler). This ensures reliable processing of all possible remote control inputs—even unregistered or system-reserved keys—preventing any event from being ignored.

This dual-path mechanism guarantees that BD-J applications can respond selectively to specific user inputs (e.g., for menu navigation or custom controls) while the underlying player handles standard or unclaimed keys (such as basic playback overrides) in a consistent, fail-safe manner across different discs and titles.

When an unregistered key event reaches the Event Listener Manager (i.e., no matching EventListener in the Xlet), it is routed to the default operation manager, which responds by invoking the appropriate function on the playback control engine.

The arrow (◆3) indicates the function call issued by the default operation manager.


PLMT Processor (Patented Enhancement)

Note: The following describes a proprietary enhancement from U.S. Patent US7627233B2 (Panasonic), which is not part of the standard BD-J specification. In core BD-J, playlist control is typically handled manually by applications via APIs, without automatic table-based management. This patented system adds reliability by automating playlist transitions, especially to handle app loading delays or failures.

The PLMT processor (PlayList Management Table processor) forms part of the application manager. When it receives an activate(bobi_id) request from the module manager, it looks up the corresponding BDJObject in the PlayList Management Table using the provided bobi_id.  

If the PlayList Management Table entry for that BD-J Object specifies a playlist (PL) with the AutoPlay playback attribute, the PLMT processor instructs the playback control engine to start playback of that AutoPlay PL (by issuing a PlayPL function call — indicated by arrow ▲1).  

Conversely, when the playback control engine sends a notification event signaling the completion of a playlist's playback (arrow ▲2), the PLMT processor interprets the moment this notify event is received as the Title endpoint.




Memory

    Main Article: Memory & Limitations

The 2010 release of Alien contains an Java interactive feature 
called MU-TH-UR Mode that runs when the movie is playing.
BD-J's graphics, data, and sounds are loaded into their separate memory, 45.5 MB for graphics (Profile 1.1 standard, per HD Cookbook and Blu-Disc Studio guidelines), 4 MB for app cache, and 5 MB for interactive sounds. The bigger memory size is necessary for advanced multimedia applications. Optionally, Profile 2.0 (BD-Live and Blu-ray3D) players have an additional 15MB of graphics memory (61.5MB total) for networking and 3D content. Ultra HD BD has 131 MB of graphics memory for 4K graphics.

BD-J Xlet's can also use the primary memory buffer to control the Primary Video: 5 MB/40 Mbps, Secondary Video: 5 MB/40 Mbps, Primary Audio: 3.456 MB/ 27.648 Mbps, and Secondary Audio: 32 KB/256 Kbps.

Developers must be conservative and creative when handling BD-J's limited memory buffers.

 

 

 


APIs

Unlike, HDMV, BD-J uses APIs. An API (Application programming interface) is a set of rules or protocols that let software applications communicate with each other to exchange data, features, and functionality. BD-J has two types of APIs, mandatory and optional. Mandatory APIs must be used in order of BD-J programs to work. Key examples include JMF for media control, HAVi for UI, and org.bluray packages for BD-specific features.

    See: List of BD-J APIs

 

Other Computer Languages

While Java is the primary and mandatory programing language for BD-J, other languages can be used alongside Java. XML, a markup language, can also be used with Java programs (parser) to bound files and assets together. It is possible to use other programming languages like C using Cybil compiler, but performance will be slower. 

The Criterion Collection uses JavaScript in their BD titles using Mozilla's Rhino, an open-source implementation of JavaScript written entirely in Java.

 

BD-J Graphics

    Main Article: Graphics

HDMV's 8-bit Interactive Graphics is replaced with 32-bit Java Graphics. It supports 24-bit true-color and 8-bit (256 level) alpha (transparent). The graphics are usually for interactive elements, buttons, sprites, fonts, backgrounds, and decorations. Java Graphics is more advanced as it can be scaled, overlapped, and have smooth frame-by-frame animations. Java Graphics supports, PNG, JPEG, and GIF and has a memory buffer of 45.5 MB.

BD-J supports victor-based text font rendering using the OpenType format (called BD-J Text). For subtitles, BD-J can use the Presentation Graphics Stream. Both OpenType and Presentation Graphics share the same buffer of 4MB, and both formats cannot be used at the same time.

 

BD-J Background

Example of a BD-J Background
Exclusive to BD-J, a background can be applied behind the Primary Video, it can display a single image or a single color. It shares the same 45.5MB graphics buffer.

 

 

 

 

 

Networking

    Main Article: Networking

BD-J is capable of accessing a local or online network connection using secure HTTPS and TCP/IP protocols when connecting to servers and URLs.

 

Local Storage

    Main Article: Local Storage

Unlike HDMV's limited Persistent Storage, BD-J has access of Local Storage of 256MB (or more). This storage is used for BD-J apps to read/write/install content.

 

Video Games

A Pinball BD-J video game from Surf's Up; the controls 
are suitable for the remote, controller, or keyboard.
   Main Article: Video Games

BD-J mode is capable of making complex 2D or 2.5D video games, though limited by remote input and player resources.


 

 

 

 

 

 

 

Sources

Refrences




Author(s) : Æ Firestone


on Friday, April 19, 2024 | , | A comment?
0 responses to “BD-J”

Leave a Reply

Popular Pages