[Spice-devel] [spice v10 08/27] server: Add VP8 support to the GStreamer video encoder

[Francois Gouget]

On Thu, 3 Mar 2016, Christophe Fergeau wrote:
[...]
> > > +        if (system("egrep -l '^flags\\b.*: .*\\bht\\b' /proc/cpuinfo
> > > >/dev/null 2>&1") == 0) {
> > > +            /* Hyperthreading is enabled so divide by two to get the number
> > > +             * of physical cores.
> > > +             */
> > > +            physical_core_count = physical_core_count / 2;
> > > +        }
> > 
> > Or as you are using /proc/cpuinfo detect from it.
> > 
> > I'm not sure we should consider compatibility with other processors (like ARM).
> 
> In general, I don't think we want to silently use as many cores as
> possible for cpu intensive work. This will break down as soon as 2 VMs
> trigger the streaming code at the same time, they both will be trying to
> use all the available physical cores. Even with a single VM, it could
> use 4 vcpus and do CPU intensive tasks on some of them, thus the vp8
> encoder would fight for these resources.

I can certainly separate that part of the patch.

That said it's not because we tell the encoder that it can use all the 
cores that it will necessarily max them out. This will depend on the 
resolution and framerate of the stream.

Also x264enc will automatically use the optimal number of threads for 
its encoding needs. As soon as the resolution is high that's likely to 
be 2 or 4 cores and I don't think we should artificially restrict it.

But more importantly, I think we should let the kernel worry about 
scheduling.

What the video encoder should do is detect when the encoding is falling 
behind and reduce the stream's fps so it can keep up rather than produce 
frames that are already late. The GStreamer encoder already tweaks the 
fps as a way to quickly adjust the bitrate so this mechanism can 
probably be reused. This should solve both the case where the system is 
too slow to encode the stream, and the case where multiple encoders or 
other processes compete for CPU resources.


-- 
Francois Gouget <fgouget at codeweavers.com>