It is like that lazy developer that delivers a simple functionality, like an UI interaction, but through a highly coupled and dispersed solution, with code being written in places it shouldn’t be. Sure it could be said that the value was delivered, but a big amount of legacy code was created in the process, and that is because the developer is focusing on the easy part of the task, the algorithm, ratter than a proper abstraction to define it.

It is easy to make something work, but making it maintainable, that is another story. We should, as developers, excel at creating abstractions. This is our real job.

First some background: we are a medium size team, composed of six developers working usually in pairs and doing sprints of 2 to 3 weeks on a project that is already in production, most of our stories are about improving the existing code base while adding some new functionality, and our sprints are usually composed of 20 to 30 stories, demanding quite some space on our dashboard.

A recurrent issue was some small bugs popping up during our client demo, giving them a bad impression about the quality of our code while bringing the team moral down.

Based on these we established some few goals to out new dashboard design:

• More flexibility: writing your name and status on a story/task is not a good idea, since whose working on it can change over time;
• Focus on people: enforce the team members importance on the project;
• A dashboard that would breathe quality: more testing and validation;
• Sense of accomplishment: it should be pretty visible to see when tasks/stories are completed;
• Pleasant to the eye, after all we will be using it everyday.
• Support a good amount of stories/tasks to be done and completed;
• Impose a limit to our WIP (work in progress);

The result is the following design, that according to Eduardo Moreira, resembles the way a brains operates, concentrating the most important things on the core of the dashboard:

On the top we have all the stories in a flow that goes from:

	To Do: At the beginning of the iteration it has the usual 20 to 30 stories ordered by the Product Owner priority. All the impediments are marked with a red flag, and work should not be started until it is unflagged.
	Work In Progress: When a team member starts working on a story it should be moved here. This step contains a much smaller space than the To Do and Completed ones, enforcing the team to work on the fewest stories at the same time, preventing too much unfinished work from happening.
	Done and Waiting Validation: After finishing all the tasks on a story it is moved here, where it waits to be validated by another team member whose do not worked on it. After validation, it then must be marked with a Success or Failure tag, the latter requiring a bug task to be created and placed on the Unexpected space (more on that latter).
	Completed: With the same space as the To Do, here is where all the completed stories lie, giving the team a good sense of accomplishment.

On the middle we have pictures of all the team members and their name tags to be stick on whatever they are working on (tasks, validation,…):

Lastly there is the bottom, with all the tasks split from the stories on our Spring Planing II:

	To Do: Not much different from above but divided into two spaces, a tiny one, to hold all the unexpected tasks (such as bugs) which wore produced during this sprint, and a bigger one, containing all the regular open tasks with the same red flags when suited.
	Work In Progress: Same rules as the stories, except that here the team member working on a task must mark it with his tag.
	Done: When a task is completed, it should be placed here. This step was created, to give the visible difference between work in progress and completed.
	Reported: Composed of all the completed tasks reported on the daily meetings.

These should cover most of it, but if you have any doubt or tip to help us improve our dashboard don’t hesitate on dropping a comment.

Java has a support to media playback through it’s Java Media Framework, which unfortunately, on it’s current version (2.1.1e) does not support many formats for video playback.

So I quickly looked for alternatives, including IBM Toolkit for mpeg4, that hadn’t a sufficient production performance I was looking for, and didn’t offer an easy option for frame grabbing or plugin extensions as JMF does.

Next was Fobs4JMF, which is JMF + ffmpeg. This solution was much more interesting, since it offers a wide variety of codecs (ogg, mp3, m4a, divx, xvid, h264, mov, etc) and is based on the solid ffmpeg solution to decode audio and video.

My implementation, uses the plug-in capabilities of JMF to extend a custom renderer that does a pixel type conversion and rendering to a texture:

This custom renderer works with RGB textures, a type I seemed to make work on my two test machines:

• MacBook with a Integ GMA x3100 – Leopard;
• PC with a Radeon x600 – Debian.

You might wanna try different pixel types to increase the performance for different target machines.

First, lets describe how the Renderer works:

It got to be an implementation of a javax.media.renderer.VideoRenderer since it will be installed as a plugin on JMF.

For the different methods we need to implement, there are a few we need to take proper care of:

• process: this is the method JMF calls passing the movie current frame buffer. Here we treat this buffer and leave it in a way we can latter render in OpenGL;
• getSupportedInputFormats: we return RGBFormat, our target texture format;
• setInputFormat: here we simply tell JMF that the format it chooses is the one we want. Since RGB was the only one we returned as supported there is not much to do here as well.
• getName: returns the renderer neat name!

Next we need a way to access this render from the outside of the JMF world, we need the texture so that we can do GL calls with it (teapot). For this purpose our class must also be a javax.media.Control. Then we can easily get it through an getControl call as:

player.getControl(“javax.media.renderer.VideoRenderer”);

So we implement:

• getControl: returns it’s instance;
• getControls: returns an array containing only it’s instance as a valid control.

The renderer implementation is org.pirelenito.multimedia.jmf.plugin.RGBGLTextureRenderer that you can check on the source code attachment bellow.

And also, to make further development easy, there is an IGLTextureRenderer interface with the public methods called by the Canvas:

• render: that plots the buffer on the texture surface;
• getTexture: to retrieve the texture instance.

Last but not least important, you need to register the render on JMF using the JMFRegistry application. The easiest way to do start it is through Eclipse, since we will need our custom render on the class path:

• Create a new run configuration;
• Set the main class as: JMFRegistry;
• Start and go to the Plugins tab then Renderer;
• Add the org.pirelenito.multimedia.jmf.plugin.RGBGLTextureRenderer;
• Move it to the top of the list;
• Push Commit and you are good to go!

To test it out there is also a helper class to instantiate the movie player, and the Main class which is an OpenGL canvas, to render the teapot with the texture on its surface.

I am not very experienced with OpenGL, so there might be more effitient ways to do this using, for instance PBO (Pixel Buffer Object), if you have any question or suggestions on how to improve this, don’t hesitate on drooping a comment!

Here is the Eclipse project. You will need to download a few dependencies, check the Readme for more information.

Update: I wasn’t properly initializing the Texture. and since I want to add support for more pixel formats, it is easy for you to checkout the updated Eclipse project at: http://labs.pirelenito.org/experiments/svn/java/MovieGL/ latter this afternoon now.

Update 2: Added the repository link on the image above.

Update 3: I’ve migrated my server to a new location, and the Subversion wasn’t up until today. Sorry.

Cheers!