A few things about the BD-J platform
September 16, 2010 §
I’ve recently been creating a project to run on the BD-J platform, as in applications for blu-ray disc players. This is my first real major project and this post is about frustrations and progression in the application. This is my first post on development in the wild.
This project is to create a Video on Demand application, so a server can stream video files to the blu-ray device, and the device can play back. Project and benchmark information has been ran on the PS3. The transport of files is socket based so the Application will use AES PSK encryption.
It runs on a specialised specification that include JDK 1.3 and other various functionality. As you can imagine, there is not a lot of documentation on this platform. There is a specification and that’s about the only place to find information. Requesting Javadocs of the platform is a process that takes days, if ever to come through. There is one book written on the platform which in itself is 50% redundant, it’s a joint book including HD-DVD, the dead specification and platform. So finding information is difficult.The device is locked down, and probably within good reason. There is your usual signing of code and requesting permissions to access features such as storage and network.
The entire build process and structure to allow an application to run is terse. It took a number of days just for the understanding of the requirements for building, generating the ant scripts, finding tools to properly match the signing process, creating all the necessary description files to go along with the application then finally: Building against the supplied class stubs provided by the BD Association.
The emulator for the platform is, you guessed it, just software to play BD disks on PCs. There is no such thing for platforms such as OSX.
Benchmarking is difficult, there is no access to System nano time, a solution has been to send UDP packets to a Server and use the delta between packet arrival to determine a less than accurate time of a test. After normalising the transfer time and running the tests over a large enough iteration, benchmarks can be almost accurate.
Retrieving errors is difficult, if something goes wrong there is just no output. Creating an on-screen logger can only show so much, only after it has been loaded itself.
The codec specification is a small selection, every aspect must match or there is just no output, or errors. These must than be held in a container file (m2ts). Fairly extensive task to get a normal video file into the approved requirements.
Streaming is difficult, you cannot pass bytes of data to a player or anything close to it. One must download a file which declares a structure of files needed and files to come. Files to come need additional structure to define what should be expected to come. A Virtual File System update then needs to be performed which restarts the entire application. Some of the files after the VFS update then get renamed which was entertaining to find out. So to stream files the server must segment the entire video into a defined requirement. Client must download these files and when they’re done attempt to enable them.
It’s slow, quite slow. From the custom benchmarking toolkit I created, the platform is anywhere from 6x to 20x slower than an average desktop from Dell. Having additional encryption and decryption overhead compounds the issue.
Overall the platform has potential to provide great additional features to blu-ray discs. At the end of the day, the PS3 was able to stream a 720p 4.5gb movie and play it back, 100% encrypted. Some movies have been released with mini games (black jack) and others even download additional video content or even the trailer for the next movie.