[Spice-devel] RFC - adding vp8 support

[Jeremy White]

On 01/26/2015 05:16 AM, Marc-André Lureau wrote:
> Hi
> 
> ----- Original Message -----
>> Hi folks,
>>
>> The spice-html5 client supports streaming, for low values of 'support'.
> 
> So you mean the streaming for the video regions only, right?

Right.

> 
>> It would be a fairly substantial boost to it's performance if Spice
>> could encode in a format supported by the MediaSource api such as vp8.
> 
> In theory, MediaSource is format agnostic iirc.

Yes, but there doesn't seem to be any intent or motion to support 'old'
codecs.

> 
> Isn't mjpeg fast enough to decode? I would assume a browser is good to it :)

Well, again, for low values of 'fast enough', yes :-/.  But the current
code has a Javascript mpeg decoder and shoves jpegs onto the screen in
rapid succession.  If you put the html5 client side by side with the gtk
client, the video performance is pretty unsatisfying.

> 
>> We've talked on an off through the years about adding that support; I'd
>> like to go ahead and make that effort.
>>
>> It looks like the task will be fairly straight forward.  There are some
>> aspects of the spice streaming functionality that are wrapped inside
>> mjpeg_encoder.c, and those should logically get broken out.
>>
>> It's not clear if we want to continue with the same stream rate logic;
>> the libvpx encoder has a built in 'target bit rate' setting that may be
>> a more logical approach.
>>
>> But my instinct is to add a video_codec.[ch] set to parallel the
>> snd_codec.[ch] in spice-common, and then to pare out the truly mpeg only
>> parts of the logic into those files.
>>
>> Once that was done, I'd introduce a codec type of VP8 and go from there.
>>
>> Is there anything else I should consider before I begin?  Have others
>> started in on this work?
> 
> I would consider gstreamer instead. At some point, I think spice will stream
> the whole desktop with a lossless video codec (hopefully supported by the
> hardware) and offer an adaptive rtp server for streaming, or even an http based
> adaptive streaming (dash). GStreamer truly shines for this work as it
> would abstract away the whole encoding & streaming part while optimizing the
> use of available hardware. 

Sure; leaning on gstreamer seems quite reasonable.  But I would still be
inclined to refactor out the video portions as a first step.

Does that make sense?

Cheers,

Jeremy