GNOME Bugzilla – Bug 300200
cpu usage on certain .mov file goes to 100% once file has finished playing (memory usage also increases a lot)
Last modified: 2005-04-14 10:50:50 UTC
can reproduce on totem, but not on playbin from command line, so assumed totem specific Gentoo bug ref: http://bugs.gentoo.org/show_bug.cgi?id=86042 Mov file can be d/led here: http://www.tliquest.net/allmarksoftware/downloads/videos/gates.mov
Ow yeah, defenitly reproducable with totem/gstreamer/gstplugins-cvs. I just recovered from pressing crtl+alt+sysrq+sub... I've analysed the problem a bit more, when the movie is almost done, the framerate goes down a lot, to about one frame per two seconds. After that, totem uses 100% cpu. When i want to close totem afterwards, it starts sucking memory and you need to be quick to kill it.
May be ALSA-related, I've fixed such issues in our ALSA plugin before. Is it reproduceable with osssink as audio output?
I get the memory usage heavy increase once playing finished but not the cpu usage, and the system is still very very sluggish until i kill totem, with osssink as the audio output.
OK, something (I'm not sure what yet) is sending out data with broken timestamps. Probably the video stream, but I don't see any frames. Anyway, this goes on until 30 minutes, for data that does not exist. That is completely broken. At some point, ALSA decides that the audio/video are too far off and stops a/v sync (that causes the hiccups in playback initially), which will cause the 100% CPU use (continuous non-synced handling of non-existing video frames). What happens after that is unclear. It eats memory, but I haven't been able to see why yet, it hangs my system completely. :-(.
Hm, it seems ffmpeg's cinepak decoder goes into an endless loop to decode video frames on EOS (where it flushes the remaining cached frames, for B-frame movies). Continuously decoding the last frame. Ewh. The play->pause will release_locks, thereby continuously adding data to the queue which ffmpeg endlessly produces. This is a bug in ffmpegdec, which also explains the rest.
Added workaround to ffmpegdec. The rest is up-to-upstream.