GNOME Bugzilla – Bug 340282
Goom visualization is unusable at 'Normal' size and higher
Last modified: 2006-05-31 16:24:11 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/gst-plugins-good0.10/+bug/41707 "Goom visualization works as expected as 'Small' size. But if I increase it to 'Normal', 'Large' or 'Extra Large', totem sucks up 1 CPU to 100% (I use P4 HT), and the sound output becomes choppy or no output at all. Visualization is invisible too. However, sometimes it is possible to restore it to working normally by dragging the possition slider, pausing/unpausing etc. Then CPU usage drops back to ~10% on 'Normal' size, ~25% on Large size (average from both virtual processors). So CPU it is capable of doing those Gooms at realtime, the problems lie somewhere else. Im not sure, but IIRC it is a regression from Flight5-6 where it worked fine. I attach the part of GST_DEBUG=3 totem output. http://librarian.launchpad.net/2382737/backtrace.txt No special information here though, just warnings like WARN (0x8504118 - 0:00:06.240627000) mad( 9806) gstmad.c(1411):gst_mad_chain: mad_header_decode had an error: input buffer too small (or EOF)"
goom is pretty CPU intensive and needs to do QoS.
* gst/goom/gstgoom.c: (gst_goom_class_init), (gst_goom_init), (gst_goom_finalize), (gst_goom_reset), (gst_goom_sink_setcaps), (gst_goom_src_setcaps), (gst_goom_src_event), (gst_goom_sink_event), (get_buffer), (gst_goom_chain), (gst_goom_change_state): * gst/goom/gstgoom.h: Handle QoS. Handle flushing, discont and events. Fix timestamps and various other cleanups.