GNOME Bugzilla – Bug 640675
high cpu-load with 0.10.32 release
Last modified: 2011-02-05 13:06:36 UTC
With the latest core I get a high cpu-load. I can reproduce this with a simple "videotestsrc ! d3dvideosink" (or dshow/ddraw) pipeline here. Replacing the libgstreamer-0.10.dll with the one from 0.10.31 solves this for me. Orc version is 0.4.11. All dlls are build via mingw32 under ubuntu 10.10 (was never a problem before). Can anyone confirm this? Thanks, Thomas PS: Another strange thing is that the deinterlacer can not be enabled on running pipeline. I can switch off via the "mode" property in my app but not on again. This is also solved with replacing the above dll so i guess it's not the deinterlacer itself.
Could you create a debug log for both versions? Like this: $ GST_DEBUG=*:5 gst-launch-0.10 videotestsrc num-buffers=300 ! d3dvideosink 2>dbg-0.10.31.log and then the same for 0.10.32? > PS: Another strange thing is that the deinterlacer can not be enabled on > running pipeline. I can switch off via the "mode" property in my app but not on > again. This is also solved with replacing the above dll so i guess it's not the > deinterlacer itself. This would best be tracked in a separate bug, I think. Not sure how the core library would affect this though (you're really just replacing libgstreamer-0.10.dll, right?). If you could make a small test program that demonstrates the problem, that'd be very helpful too.
Created attachment 179596 [details] logfiles Sorry, had to replace the libgstbase-0.10.dll too because I get "gst_clock_single_shot_id_reinit() is missing" else.
Thanks. What would be even more helpful would be if you could just build GStreamer from git and do a git-bisect between RELEASE-0.10.31 and RELEASE-0.10.32 to find out which commit caused the problem exactly :-)
Test more than 250 commits? :-( PS: The deinterlacer problem exists also under linux. I use mode=0 (auto) to enable and mode=2 (disabled) to disable it. With 0.10.32 auto isn't working to reenable it at running pipeline, but with mode=1 (interlaced) it works. Starting the pipeline with mode=0 works too. Maybe this helps a little bit...
> Test more than 250 commits? :-( No, git-bisect bisects, so it'll take only take a handful of tests. > PS: The deinterlacer problem exists also under linux. I use mode=0 (auto) to > enable and mode=2 (disabled) to disable it. With 0.10.32 auto isn't working to > reenable it at running pipeline, but with mode=1 (interlaced) it works. > Starting the pipeline with mode=0 works too. Maybe this helps a little bit... Did you file a separate bug for the deinterlacer problem? If not, please do.
For the record, git bisect shows it has been introduced in commit 73ee14302fd6d7f26207707187d06c1bba32e2c5 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Thu Oct 21 01:15:44 2010 +0200 poll: make timer polls lockfree Make sure we don't take a mutex in the normal code path of the timer poll. On the other hand, the following one fixes this (i.e. the cpu usage, please file a separate one for the deinterlacer problem as mentioned): commit 50d566d9ade049f8e42bb52add7cf1b9cba505df Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Thu Feb 3 15:17:13 2011 +0100 poll: trigger rebuild setup in _new Failing to do so in the Windows case (implicitly triggered otherwise) would have a subsequent _wait return immediately leading to high CPU usage timeout loops. Fixes #640675.
Works, thank you! For the deinterlacer Bug #641599 was filed.