[Bug 667653] Autodetect multicore/multithread processors

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=667653
  GStreamer | gst-plugins-bad | 0.11.x

--- Comment #4 from Jean-François Fortin Tam <nekohayo at gmail.com> 2012-02-03 14:24:54 UTC ---
Well, for what it's worth, all the other video editors/encoders I've seen (in
the commercial world *and* the open source world) default to using all the
cores/threads they can when rendering. Especially with HD footage being common
these days, you simply can't expect reasonable render times with a single
thread.

To give you some background perspective, circa 2004, with a single thread
processor, when I rendered a 25 minutes timeline (not even in HD and not in a
heavily compressed format, and that was with a professional commercial video
editor), I started the render process and went to sleep, because it would take
a couple of hours or the whole night.

With those things in mind, as a video editor myself, I still see encoding as an
"expensive, ultimate, fire ze missiles" operation where I *expect* my computer
to be pegged down for a while with fans whirring full blast. I think most video
editors expect this kind of behavior too.

As for the question of "multiple streams"... correct me if I'm wrong, but video
encoding is by far the most expensive operation. Encoding audio/subtitles/etc
is negligibly fast compared to crunching multi-million pixels with complex
algorithms multiple times per second.


If you want to be absolutely safe and ensure that you can still watch 1080p
videos on youtube at the same time as you're rendering a 4K video, maybe the
default could be "maximum_threads -1" or "number_of_cores +1" or something...
but a default of 1 is surely not a good default.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.