Darren: I'm cc:ing desktop-discuss since I imagine people in general mgiht be interest in knowing about performance with multimedia on Solaris
> Any word on this? Is there anything that we can do to get it fixed? [bug report 6445149] This is a tricky bug since multimedia performance issues are complicated. Note that performance can vary widely based on media format, and how the media file was recorded (e.g. the bit rate, sampling frequency, and mono vs. stereo values of the media file) can cause significant performance impact. Also the specific plugins used in GStreamer can cause issues. Note some plugins only support certain bit rates, sampling frequencies, etc. and so to plug them together additional plugins must be added to convert the bit rate, sampling frequency, etc. on the fly, which makes it run more slowly. The above bug is rather vague about the problem, and using the same test files that Robert Kinsella uses for testing multimedia I do not see the problem with these foramts: http://129.156.234.83/mm_test_files.zip It would be handy if you could verify that you also don't see performance problems with totem playing these mp2, mp3, and mpa file types. I certainly do not see the 1:14 delay as reported in the bug. Note that the bug is currently marked as fixed and integrated since I don't see this problem, so I'm a bit confused about why you are asking abut this. However, there are some serious performance issues with GStreamer, so I'll talk about the problems and opportunities that I know about. Work on this bug is ongoing, for example: http://bugzilla.gnome.org/show_bug.cgi?id=360673 I've been working on this bug for over a year and with Padraig's help recently we (mostly Padraig) seem to be making some progress. I think addressing the above GNOME Bugzilla bug is probably the highest priority in addressing overall performance issues with GStreamer. Also there has been some talk about making more use of mediaLib in GStreamer and the Helix engine to take more advantage of MMX, VIS (on Sparc), etc. hardware accelleration. This would probably add the most value to multimedia performance if we wanted to do the work. http://liboil.freedesktop.org/wiki/ Note that liboil exists in the GNOME community and is already used by GStreamer. liboil is a free library very similar to mediaLib. If we were to implement mediaLib support in liboil, then GStreamer would start to take advantage of hardware acceleration. Then the Helix engine could also make use of liboil for good overall hardware acceleration on Solaris. I've talked with the mediaLib team about this and they agree that it would be a nice fit, but multimedia would probably need to become a bit more high priority to justify investing the amount of time to do this (probably would also require working with the mediaLib team to add new functionality to the mediaLib library to map what liboil does as much as possible). Obviously we could also avoid changing liboil and instead make both GStreamer and Helix use mediaLib directly without using liboil. This might be a bit better from a performance perspective, but would probably be a bit more work. Brian
