After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 573395 - autodetect multicore/multithread processors
autodetect multicore/multithread processors
Status: RESOLVED NOTABUG
Product: pitivi
Classification: Other
Component: Rendering
Git
Other Linux
: Normal enhancement
: 0.91
Assigned To: Pitivi maintainers
Pitivi maintainers
: 653496 (view as bug list)
Depends on: 667653
Blocks:
 
 
Reported: 2009-02-27 13:43 UTC by Jean-François Fortin Tam
Modified: 2012-02-12 15:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2009-02-27 13:43:52 UTC
Now that bug #569988 seems solved, PiTiVi should automagically detect multicore/multiprocessor systems for rendering.
Comment 1 Jean-François Fortin Tam 2009-09-11 02:22:02 UTC
Also, I should mention that manually setting the number of threads to 4 in x264's settings does not seem to have any effect (pretty much only one of my 4 cores is used).
Comment 2 Jean-François Fortin Tam 2010-11-26 17:53:23 UTC
Seems to work now in pitivi git with theora and x264.
Comment 3 Jean-François Fortin Tam 2011-06-27 23:11:23 UTC
...yet it doesn't do that for vp8 (which has a manual threads setting). Not sure about theora and x264.

Wondering if it's a gstreamer issue, or something to be fixed by the switch to GES...
Comment 4 Jean-François Fortin Tam 2011-06-27 23:12:20 UTC
*** Bug 653496 has been marked as a duplicate of this bug. ***
Comment 5 Brion Vibber 2011-11-04 21:09:48 UTC
I'm definitely seeing single-threaded rendering for Theora output in 0.15 (Ubuntu 11.10). This is a bit frustrating on an 8-core machine. :)
Comment 6 Jean-François Fortin Tam 2012-01-10 19:44:17 UTC
GES doesn't automagically fix this, so I filed bug #667653 in gstreamer about this instead.
Comment 7 Thibault Saunier 2012-01-15 02:45:31 UTC
As sebastian said, it is not really easy to find a good way to handle that in GST. So the solution might be to have in the UI like 2 or 3 "perfomance modes" for encoding such as: low performance, normal perfomances and high performances (needs more thinking about the terminlogy etc...) and then just map inside PiTiVi the properties to set number of threads to this performance setting for the various encoders.
Comment 8 Jean-François Fortin Tam 2012-02-03 15:32:43 UTC
As I hinted in bug #667653's c4, I don't believe in dumping this responsibility onto the user. The user doesn't care. And having a global preference would be generally a nonsensical option. Anyone, when asked "do you want to render with maximum performance?" will answer yes. It's like asking "Do you want your car engine to have maximum fuel efficiency without compromising performance?".

Pitivi should Just Work™ and automatically set the threads to the maximum, or maximum -1.

For the time being though, we'll probably have to do a bit of a hack in pitivi to map to the non-standardized properties that govern threads. Hopefully this will only be one standardized gstreamer property in the future.
Comment 9 Jean-François Fortin Tam 2012-02-03 17:15:45 UTC
Okay, so:
- theoraenc: NOTOURBUG*
- x264enc: defaults to 0 (automatic), which works. Nothing to do.
- schroenc: automatic. Nothing to do.
- vp8enc: defaults to 1. We should override this.
- ffmpeg codecs: supposedly threaded, but disabled? Nothing to do.
- all the other codecs: don't seem to support threading. Nothing to do.

*: I am told that threading is planned for libtheora 1.3. Once that happens, I guess it will be available in gstreamer and we'll see.
Comment 10 Jean-François Fortin Tam 2012-02-12 15:55:36 UTC
After some discussion, it seems the reason why VP8 does not use multiple threads by default is that it significantly affects encoding quality... as such, the default setting is supposedly the right one and there is nothing to be done on the pitivi side.