Hi, On Mon, Oct 31, 2016 at 08:49:23PM +0100, Francois Gouget wrote: > We run the VP8 encoder in real time mode so it uses only the minimum > amount of time needed to encode each frame. However by default it > only uses one thread so that for large/complex frames it may run at > less than the source fps. Besides resulting in dropped frames this > blocks the main server thread for most of the time. > So this patch configures the VP8 encoder to use all the CPU's physical > core, resulting in less wall clock time spent in encode_frame(). > > Signed-off-by: Francois Gouget <fgouget@xxxxxxxxxxxxxxx> > --- > > I am resubmitting this patch because I think the reasons for not > applying it last time were wrong. See: > https://lists.freedesktop.org/archives/spice-devel/2016-March/027026.html > > Here is an illustration of the impact of threading for the > big_buck_bunny_1080p_h264.mov video: > > http://fgouget.free.fr/tmp/Spice-vp8-threads.png > http://fgouget.free.fr/tmp/Spice-vp8-threads.xls > > The graph shows the time spent in encode_frame() (taken from the > standard traces) when vp8enc uses 1, 2 or 4 threads. Well, I did not say that using more threads was not useful, I was only worried that using all CPUs could not be so good (eg multiple VMs encoding at the same time), especially as I think you mentioned that trying to use too many threads was causing rendering issues? > I'll also note that the h264 encoder automatically uses multiple > threads already so this patch only brings vp8enc in line with it. After a quick look at x264, it seems to be using more threads than physiical CPUs. Is it ok too with vp8enc? I'd really like that we don't have that code invoking egrep as a fallback, ie no g_get_num_processors, no _SC_NPROCESSORS_ONLN, tough luck? (the latter is available on el6). Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel