ZenLinux Blog

I’ve spent the better part of this week doing battle with a pesky problem in Firefox v3. The bug report on Mozilla’s bug tracking system (along with a patch to fix it) can be found here if you’d like to read all the gory details.

The product I’m putting the finishing touches on at work is a touchscreen-based appliance that can, among other things, display video streams from IP cameras. The lowest common denominator for IP cameras it supports is the motion JPEG protocol, so early on in the project (many months ago) we did some testing and found that Firefox readily supports displaying these streams, and that we could also use a video player plugin for better system performance. Sounds like an easy feature to add, yes?

Nope! It turns out that the bug I referenced above means that once you display an MJPEG stream, it never stops running. If you browse away from the stream you still take a performance hit, and Firefox eats up the CPU and network bandwidth resources as if the stream was still being displayed. This became a critical problem on an embedded platform that needed to display up to four IP camera streams at the same time. Additionally, the camera streams are not the focus of the product (its primary purpose is to control multiroom audio systems).

So onto “Plan B” – the mplayer video plugin for Firefox. As a bonus, this plugin makes use of hardware video acceleration to display streams, resulting in significantly lower CPU utilization. Have we found a winner? No, again. The plugin did its job well, until you went to unload it from the page. This process turns out to take an indeterminate amount of time due to various complex interactions between the plugin and the independent mplayer process that also needs to be shut down. The delay would amount to several seconds regularly – unacceptable for the product’s requirements. Various aggressive methods of killing the plugin to avoid the delay only resulted in killing Firefox along with it. And through communication with one of the open source developers of the mplayer plugin, we confirmed that this was a inherent design problem that could not be overcome.

So what now? All I can say is we are very, very lucky that the Mozilla team fixed this bug. Although it is not yet released into the mainline Firefox, I was able to apply the patch cleanly to the sources and compile a custom Firefox that meets our needs.

It’s been a long week, but in the end I am still grateful that we’re using open source software as our technology foundation. It may have its problems, but if you put some effort into searching through the infrastructure that’s publicly available on the web (i.e, bug tracking sites and mailing lists) you can usually understand and find the solutions to your problems.