GNOME Bugzilla – Bug 564777
performance issue with ffmpegcolorspace and liboil
Last modified: 2009-06-27 23:47:30 UTC
I run totem and play an ogg video, and notice the following performance report using the Sun Studio compiler performance tool: This is running a 43.49 second test: - 8.666 seconds - resample_linear_argb_ref in liboil - 6.545 seconds - yuv420p_to_argb32 in gstffmpegcolorspace - 6.044 seconds - merge_linear_argb_ref in liboil Note the #2 function is a gstffmpegcolorspace function. It seems it would be good to make this function make use of hardware acceleration.
For reference, I ran the report viewing this video: http://ia310809.us.archive.org/3/items/whycopyrightdoc/whycopyrightdoc.ogg
Oops, the name of the function is wrong. The correct name of the gstffmpegcolorspace function that is consuming 6.545 seconds is: - 6.545 seconds - yuv420p_to_rgb32 in gstffmpegcolorspace Sorry about that.
The normal way to "make use of hardware acceleration" for this is by using XV (xvimagesink) instead of having a slow software conversion/scaling for display with ximagesink. glimagesink may also be an option (or if not, it might become one in the future). A faster software colourspace converter and video scaler would be nice, but for playback it's better to avoid hitting the software fallbacks at all.
I ran a 172.541 second test, my top 3 were: 1 - merge_linear_argb_ref (/usr/lib/liboil-0.3.so.0.3.0) with 56.039 seconds 2 - resample_linear_argb_ref (/usr/lib/liboil-0.3.so.0.3.0) with 39.708 seconds 3 - yuv420p_to_rgb32 (/usr/lib/gstreamer-0.10/libgstffmpegcolorspace.so) with 19.324 seconds Coming after that every thing was single digit and fairly trivial
that would be ffmpegcolorspace (from gst-plugins-base) and liboil (through videoscale I imagine ?) and not gst-ffmpeg. I don't really know if this is a bug or a enhancement. In the case of the latter, we normally close enhancements bugs pretty quickly if there isn't a proposal for improvement and/or a patch.
Edward: Yes, right, thanks for putting this report in the right category. Note I also filed an enhancement request for liboil so that those functions hopefully get more attention. The lack of tuned liboil functions making use of hardware acceleration is probably more of a bug than this bug report. Refer here: http://bugs.freedesktop.org/show_bug.cgi?id=19113 This issue was reported to Sun by Che Cristo, who said that totem is so slow playing video that it tends to stutter due to using high CPU. He said using VLC does not have this issue, and VLC only tends to use about 30% of CPU. I am guessing this is because VLC has better hardware acceleration support. This seems to be confirmed by our performance analysis which does seem to indicate a lot of time spent in these 3 functions. All of which look like the sort of functions which would lend themselves well to hardware acceleration. This issue is probably more of an enhancement request, so I understand if you close it. However, I'd think that the GStreamer team would want to focus on improving performance of known & identified functions which cause performance issue when playing video with common tools. Or at least keep track of them somewhere.
Michael seems to indicate that ffmpegcolorspace shouldn't be used when using the xvimagesink. However, I'm still seeing that ffmpegcolorspace function eating time when I'm using xvimagesink. Is this perhaps a bug in totem that it shouldn't use this in the pipeline when xvimagesink is being used?
Can you provide a full debug log of totem playing that file ? Not for the whole duration of the file, but at least until it displays something. GST_DEBUG=5 totem <filename> > log 2>&1 bzip2 log
Are you using gcc to compile? GCC is the only recommended compiler for liboil.
I just reran the test making sure that I had run gstreamer-properties first and set the "Default Output" plugin on the "Video" tab to "X Window System (X11/Xshm/Xv) so that Xvideo would be used. When running this way, the top 3 functions reported above do not appear in the report. This indicates that the liboil and ffmpegcolorspace functions are not used when xvimagesink is used, and the overall performance is much better. Che, can you re-verify that setting your output plugin to xvideosink and then running totem still has performance problems on your system? Can you run the Sun Studio "collect/analyzer" program to see if the above functions still show up in your report when using the Xvideo plugin? If you are seeing these, then I'm wondering if your system doesn't support Xvideo and somehow the system is falling back to the non-Xvideo version.
Che: Ping.
(In reply to comment #11) > Che: Ping. > Hi Tobias...since upgrading to Indiana build 117 I no longer have this issue...should we close of this bug?
Yes, let's close it as OBSOLETE then
Che, can you run gstreamer-properties from a terminal and let us know what the setting for "Default Output" in the "Video" tab is? Is it Autodetect, X Window System (no Xv), or X Window System (X11, Xshm, Xv)? Note that the performance problem only happens if the setting is "X Window System (No Xv)". I suspect that the reason you no longer see this issue in build 117 is because the default value changed. I suspect that you would still see the performance issue if the setting is "X Window System (no Xv)". Can you verify? If so, then this is still a performance issue, and perhaps the bug should be left open since I think there is an opportunity to improve performance here unless work has been done to address the performance issue. I don't think that is the case. If this is still a problem, then please reopen this bug.