GNOME Bugzilla – Bug 609274
[regression] [decodebin2] massive slowness in importing clips in pitivi
Last modified: 2010-05-27 18:36:11 UTC
Latest versions of the gstreamer PPA packages cause pitivi to be *REALLY* slow to import clips. Usually importing a clip didn't take >1-2 seconds, but now users and testers (including me) are constantly hitting the 10-seconds import timeout in pitivi. Some projects/clips can never be imported now, whereas they used to. On my end, I think this started occuring with the gstreamer PPA updates from december or january. If this problem is present with pitivi in ubuntu 10.04, it will be fail on a massive scale. I'm hoping this was already reported and fixed, but someone suggested I file a bug nonetheless.
I confirm the bug. Please, see bug #575356 for logs.
Is this with every file or only specific file types? Is it taking 100% CPU all the time?
It's pretty much every file type as far as I can tell. There are *some* formats/containers like mkv and ogg that will import more easily than, say mp4; they will actually import (instead of going over the 10 seconds timeout), but they will import slowly. Some mp4 files import too. In general it is clearly slower for all file types, it's just that the ones that were already slow are now impossible to import because they're even slower.
A quick look at what time is spent in discovering a 10s DV-in-AVI file (i.e. 720x576 DV which is fast to decode, and an AVI container which is fast to parse) gives me the following: Total discovery time : 845ms * time spent between discovery start and avidemux finishes parsing file : 27ms * time spent for encoding a png file : 26ms * time spent between discovery start and pngenc pushes out encoded buffer : 271ms * time spent between pngenc pushes out encoded buffer and avidemux stops its streaming thread : 571ms (!?!?!??!?!) The problem therefore lies between the moment pngenc has finished encoding the buffer and the moment avidemux stops streaming. My guess at this point lies in multiqueue taking aeons to forward the GST_FLOW_UNEXPECTED back to avidemux. Will investigate this a bit more in a couple of hours.
Maybe commit fbdf4dcedad8692f1e3d8838551188987e462e74 caused it? commit fbdf4dcedad8692f1e3d8838551188987e462e74 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Jan 26 12:43:09 2010 +0100 multiqueue: handle UNEXPECTED flowreturn better When we receive an UNEXPECTED flowreturn from downstream, we must not shutdo the pushing thread because upstream will at some point push an EOS that we s need to push further downstream. To achieve this, convert the UNEXPECTED return value to OK. Add a fixme so t we implement the right logic to propagate the flowreturn upstream at some po Also clean up the unit test a little. Fixes #608136
Created attachment 153331 [details] [review] Revert "multiqueue: handle UNEXPECTED flowreturn better" This reverts commit fbdf4dcedad8692f1e3d8838551188987e462e74. Partly fixes #609274
Created attachment 153332 [details] [review] multiqueue: Don't stop threads on UNEXPECTED and forward flow returns. When a downstream element returns GST_FLOW_UNEXPECTED we want to: * let the dataqueue task running * forward the flow return upstream. This allows upstream elements to push EOS, and have that EOS event come downstream. Fixes #609274
commit 4e0b2dc8321138940caaa4efcb104795f060482a Author: Edward Hervey <bilboed@bilboed.com> Date: Tue Feb 9 15:51:18 2010 +0100 multiqueue: Don't stop threads on UNEXPECTED and forward flow returns. When a downstream element returns GST_FLOW_UNEXPECTED we want to: * let the dataqueue task running * forward the flow return upstream. This allows upstream elements to push EOS, and have that EOS event come downstream. Fixes #609274 commit 9cc47f8cbaee097818b3a82b23c1d3b5af387b91 Author: Edward Hervey <bilboed@bilboed.com> Date: Tue Feb 9 13:35:08 2010 +0100 Revert "multiqueue: handle UNEXPECTED flowreturn better" This reverts commit fbdf4dcedad8692f1e3d8838551188987e462e74. Partly fixes #609274
It seems the bug was not resolved. Pitivi gives error on large file (i installed gstreamer from gst-developers PPA for ubuntu)
What's the output of: - dpkg -l '*gstreamer*' | grep ii - gst-inspect-0.10 multiqueue | grep Version Could you create a GST_DEBUG log and put it up somewhere?
The log is attached. The command is: GST_DEBUG=3,gnl*:5,python:5 PITIVI_DEBUG=5 /usr/bin/pitivi > debug.log 2>&1 Other output follow: gst-inspect-0.10 multiqueue | grep Version Version: 0.10.26 dpkg -l '*gstreamer*' | grep ii ii bluez-gstreamer 4.51-0ubuntu2 Bluetooth GStreamer support ii gstreamer0.10-alsa 0.10.26-1~karmic1 GStreamer plugin for ALSA ii gstreamer0.10-ffmpeg 0.10.9-2~ppa9.10+1 FFmpeg plugin for GStreamer ii gstreamer0.10-gnomevfs 0.10.26-1~karmic1 GStreamer plugin for GnomeVFS ii gstreamer0.10-gnonlin 0.10.14-1~karmic1 non-linear editing module for GStreamer ii gstreamer0.10-nice 0.0.10-1~ppa9.10+1 ICE library (GStreamer plugin) ii gstreamer0.10-pitfdll 0.9.1.1+cvs20080215-1ubuntu1 GStreamer plugin for using MS Windows binary ii gstreamer0.10-plugins-bad 0.10.17-1~karmic1 GStreamer plugins from the "bad" set ii gstreamer0.10-plugins-bad-multiverse 0.10.13-0ubuntu1 GStreamer plugins from the "bad" set (Multiv ii gstreamer0.10-plugins-base 0.10.26-1~karmic1 GStreamer plugins from the "base" set ii gstreamer0.10-plugins-base-apps 0.10.26-1~karmic1 GStreamer helper programs from the "base" se ii gstreamer0.10-plugins-good 0.10.18-1~karmic1 GStreamer plugins from the "good" set ii gstreamer0.10-plugins-ugly 0.10.13-2~karmic1 GStreamer plugins from the "ugly" set ii gstreamer0.10-plugins-ugly-multiverse 0.10.12-0ubuntu1 GStreamer plugins from the "ugly" set (Multi ii gstreamer0.10-pulseaudio 0.10.18-1~karmic1 GStreamer plugin for PulseAudio ii gstreamer0.10-tools 0.10.26-1~karmic1 Tools for use with GStreamer ii gstreamer0.10-x 0.10.26-1~karmic1 GStreamer plugins for X11 and Pango ii libgstreamer-plugins-base0.10-0 0.10.26-1~karmic1 GStreamer libraries from the "base" set ii libgstreamer0.10-0 0.10.26-1~karmic1 Core GStreamer libraries and elements ii phonon-backend-gstreamer 4:4.3.1-4ubuntu1 Phonon GStreamer 0.10.x backend ....................
Created attachment 153572 [details] pitivi/gst debug log
Guido, were you using pitivi from git ?
yes, I compiled it in my launchpad ppa. It is the 2010.02.02
(In reply to comment #14) > yes, I compiled it in my launchpad ppa. > It is the 2010.02.02 ps. I use it on Karmic (but with your gst-dev ppa)
Guido, this was fixed this tuesday, so 2010 02 09.
thank you jean. I supposed the issue was caused by gstreamer only. I have upgraded pitivi now and it works.
*** Bug 619850 has been marked as a duplicate of this bug. ***