Access All Your Media On TV Using jflicks

I read about the jflicks media system through an announcement here on JavaLobby. It sounded like a great project - an open source project, written in Java, to access all your media on your TV. Everyone wants to get at all of their media from the comfort of their sofa. That's why we have solutions like GoogleTV and Boxee. An open source project like jflicks is a great opportunity to add in some of your own killer features. I talked to the project creator, Douglas Barnum to find out more about jflicks. Read on to find out more about the project, or jump to the end of the article to see a video of jflicks in action.

DZone: Could you introduce yourself to the readers?

Douglas Barnum: I've been doing software as a living for 20 years.  I first found Java in '97 and I knew right away it was something special.  Part of that realization was object oriented programming itself as Java was my first real exposure.  I remember the feeling after I wrote my first UI application (it was an email client) and how smart I felt because it came together so quickly.  Later I realized it wasn't me - it was Java.  :-)

DZone: What exactly is jflicks?

Douglas Barnum: First and foremost it's a project that allows me to test my code by watching TV.  :-)

The most general description I think I can come up with is it is a media system to allow you to access the media you own on any TV in your home.  And be a system flexible enough to continue to do so into the future.  The way we consume our media has changed so much in the recent past - and I'm sure it will continue to change.

For a long time I wanted to have a home theater.  A couple of years ago I was able to put a modest one together in our basement.  Nothing really fancy as one can spend a lot of time and money.  When you do have a home theater you do like to show it off to friends and family because it's fun to watch movies on the big screen, in comfortable seating with nice surround sound.  You need to have these physical things but you also need a software component to really show off your system.  You want an experience that is like a real theater but without the overpriced popcorn and drinks.  :-)

There are several terrific open source and closed source projects out there you can use for the software component for a home theater and I have run a couple of them.  My experience with them was positive for the most part but when you are a developer and using software you find yourself imagining what you would do differently if you designed it.  And because I felt there were limitations to what I wanted the software to do that I was using, I thought the idea of home theater software needed re-thinking.

The jflicks media system is my attempt at that re-thinking.  I want the system to be capable of running throughout the home - not just on one PC.  The most important design goals are:

• The user interface to be the same at each TV.  One remote control can do everything.
• All media (video, audio, photos etc) be available at every TV in the home
• The software components of the system discover each other on the local network without user interaction.  And these components can “come and go” without disruption.
• All functionality should be selectable by the user.
• Be cross platform.

The last three bullets really show that something like Java with a modular system like OSGi can be used for the realization of these design goals.

DZone: Has the project been running for long? Are there many committers?

Douglas Barnum:  I started working on the project about a year ago.  It took a few months to have something to run and play with in our home theater.  The home theater became the "testing lab".  :-)  Last August I felt the software had gotten to the point that it was ready to become our only media system in our home and switched fully over so all TVs were running jflicks.  Work has continued with stability and basic functionality the main goal.

At this point there has only been one committer - me.  My goal has been to get the project to a certain point where others could install it and play with it.  I think the project has a good foundation.  But to be the best, it needs the ideas and skills from other developers.  I am hoping developers hop on board to make this happen.
 

DZone: Why use Java to implement jflicks? Did you consider any other languages?

Douglas Barnum: To be honest there really wasn't any other languages considered.  Perhaps it's "if all you have is a hammer, then everything looks like a nail."  Since I have been working in Java for so long it's just a natural selection for me.  I think the design goals did drive me to use OSGi though.  I had never used OSGi before this project, but had read a few articles on JavaLobby prior so I did have it in the back of my mind.  I think it's a perfect fit - the modularity that OSGi gives Java was ideal for jflicks.

DZone: What does the architecture look like?

Douglas Barnum: In general terms the architecture is distributed between at least one "server" and one "client".   A server is meant to supply media and the client is meant to consume media.  Of course these both can be running on one machine connected to a TV.

One thing that makes jflicks different than other media systems is that different tasks of managing or maintaining the system are better suited to being performed with a desktop application than with the TV "10-foot" user interface.  For example, the DVR functionality requires one or more folders to store recordings.  Why would anyone want to type in this folder path information in the TV UI?  In my home I'm the one setting up the system, other people using the TV UI would NEVER care about this setting.  All it would do is confuse them and make the system harder to use just by the fact that it exists on some screen.  No it's better to do this configuration elsewhere - like in a desktop application - try to keep the TV UI as simple as possible.  All the other media systems I used have this configuration in the TV UI - I think it's a design mistake.

Since all the applications that make up the jflicks media system are OSGi based, all functionality is discovered at run time.  In OSGi lingo, this functionality is supplied by "service implementations" or "bundles".  To illustrate, one service definition (a Java Interface with about 10 methods) we have is a "Recorder".  A Recorder can access some video hardware device and write video data to a file.  Now any particular service implementation of a Recorder may or may not be installed.  These Recorder implementations by their very nature will be dependent on some particular hardware device.  And perhaps there would be different implementations based upon the operating system.  No doubt the code that can get video data from the same hardware device will most likely be different whether the OS is Linux, Windows or Mac.  The point it that the bundle is only deployed to a system that has the particular hardware device.  There is no sense in deploying it otherwise.  The modularity that OSGi gives you is that the system as a whole can be expanded by writing more service implementations without changing the core.

Also as a general rule I think it's best to reuse system tools and programs whenever possible.  These of course are decisions made by whomever writes the service implementation.  I think it's not the best idea to rewrite a video player when we have players like VLC and MPlayer already written and portable to most platforms.

DZone: How does it work?

Douglas Barnum: It's my experience that running one or more Home Theater PCs is not a simple task and takes some technical expertise.  Perhaps the easiest is Windows Media Center - but still one needs to be pretty technical.  I don't know if jflicks can ever be made into a "DVR for dummies" but I want jflicks to be as easy to manage as possible.  One idea I had was an application that can easily be expanded (thanks to OSGi) that can help the user diagnose their system and offer solutions to fix the "problems" they have.  Sort of a "forum in an application".  Here is how it usually works - people have a problem with their setup - if they can't find some wiki page to help themselves, they will post their problem in a forum.  Hopefully they do get some help and at some point the forum post is tagged "[solved]" so some future user learns from the experience.

However imagine that these solutions instead of just being documented, could be coded up and solved shortly after installing the system by a desktop application.  The user would save a ton of time - first they have to discover the problem, then spend time researching how to fix it.  The beauty of OSGi again is this application at it's core would not need to change - it simply is extended by adding more "problem solving" service implementations.

I have the beginnings of this application and I call it "Aspirin".  Currently it doesn't have a lot of problem solving services but as time goes on the number will grow.

In general, how the jflicks media system works is dependent on the functionality the user installed.  I will explain my setup, even though it may not be typical.  I run two servers and five TV clients.  Each TV client can consume any media from the two servers.  The clients and servers auto discover each other at runtime.  From a Java programmers perspective, you are just using Objects - the remote access is handled for you.  I use a project called r-osgi that makes doing this dead simple for a Java programmer.  Communication happens in two ways - a normal API defined by Java interfaces and the OSGi Event mechanism.

The first server has DVR functionality with six recorders, manages a video library (movies, TV, home video), maintains movie preview videos downloaded from the Internet, and serves our photo library.

The second server only runs what I call an "On Demand" service.  There has been an explosion of devices available to consumers the last two years that allow us to access media on the net.  On Demand services are meant to interact with these sort of devices.  The device might be a cable box, a bluray player or some other set top box.  The key here is that you really need to interact directly with the device, using it's user interface.  It is really the only way to integrate the device into the system.  The problem with this is usually you need to use the proper remote to control it, and it usually is connected directly to your TV.  We have neither in this case!  The only way to do this in a general way is to stream the video live over your local network and display it locally on the TV you are watching.  Then also emulate the remote control in some way over the network.

I have written just one on demand implementation and it is running in this second server.  I own a Roku box that is connected to this second server via a Hauppauge HD-PVR 1212 recorder and component video cables.  This service allows me to watch the Roku "live" on any of the TVs in our home.  I can interact with the Roku using my remote and watch any content that the Roku can supply.  Because the control and video is sent over my local network, there is a slight delay.  The delay is about a second.  The Roku interface is so simple that this delay is not a problem.  A second limitation is that only one TV at a time can use an on demand service.  The advantage to having a service like this is that we can watch the Roku on any TV without physically having to move it.

DZone: What are your plans for the future of jflicks?

Douglas Barnum: There is so much to do that it makes my head hurt!

First of all I'm hoping developers jump on board to help.  All the applications could use more polish.  The desktop configuration application is very developer oriented.  It definitely needs to be made easier to understand and to use.  The other desktop apps could use more polish too.

And since my system is Ubuntu Linux, more support exists on that platform than on the others.  I'd really love to see someone step up and help with Windows and Mac - for example writing Recorder service implementations that know how to get video data from devices on those platforms.

These are just a few things - there are many more.  The TV UI is functional but not very flashy.  It just uses Java 2D - I lay out components on a JLayeredPane.  Perhaps in the future things like JOGL or JavaFX (the library) may help make it more pleasing to the eye.  In the near term I'm going to try to make the Java 2D a little richer.  Up until now I've been more concerned with correctness than with slickness.  But certainly users want the TV UI to look really nice.

Douglas took the time to put together a video showcasing what jflicks can do. 

Some points on this video from Douglas: 

1. I didn't select it to run, but the Google TV is just web sites that have optimized their site to Google TV.  jflicks simply launches chrome full screen.
2. The On Demand Roku is streaming the Roku live over my network.  As you can see I can access Netflix via this box while running Linux.
3. My "Photo" player is viewing photos that have been tagged with some tool.  I use Digikam and have a service running in the server that can read and access the Digikam database.  A good service implementation here would be one that supported Flickr.  Flickr has a nice web service API so this would be fairly easy to do.
4. The "Previews" run an intro and then the latest previews found on the net.  A service in the server downloads them and stores them locally to be played.
5. The Video Library is on my local NAS server.  I started two of them to show that they also show a intro before playing the movie.  The intro can match the aspect ratio of the feature and I played a 2.35:1 and 4:3 aspect ratio films to show that.
6. Then I showed the Recording screen to watch recordings.  I did not demonstrate this but commercial skipping is supported - the videos with the blue flag has detected commercials.  A quick press of a button and it can be skipped.

All intros were made by this site: http://vipidme.com

The name of my theater is the "Moonlight Theater" and you can see it is used in the custom intros.  The intros used are configured in the server so people can easily use their own.