[Spice-devel] Streaming video performance concepts

[David Jaša]

Dne 23.6.2011 11:49, Alon Levy napsal(a):
> On Thu, Jun 23, 2011 at 10:50:57AM +0300, Yaniv Kaul wrote:
>> We could throw many more into the thread.
>> When comparing video encodings, we must take into account:
>> - speed of encoding (many of the encoders are not fast enough for
>> real time, they may decode fast, but we need fast encoding too)
>> - quality (and how to measure it - see
>> http://x264dev.multimedia.cx/archives/472 )
>> - features, flexibility, license, active development community, ...
>>
>> This is really not an easy task and there's probably not a
>> one-fit-all solution to it. Here's an example for some comparison -
>> http://x264dev.multimedia.cx/archives/102
>>
>> Also, just a thought - say we do Flash pass-through (from guest to
>> client), have we solved perhaps solved 90% of the problem in
>> real-world usage?
>
> How would you propose to do this? write flash plugins for major (ie, ff, chrome)
> browsers? (well, chrome can take ff plugins I think, so down to two) and fake
> a proxy for the real plugin on the client?
>

We could use some video acceleration API, preferably VDPAU for Linux 
guests and DXVA for Windows guests, because these APIs are supported by 
Adobe Flash. The main disadvantage is non technical: we would either 
need clients equipped with video-acceleration-capable GPUs or we would 
have to include patent-free/royalty-free codecs only by default or we 
would have to pay royalties for every client sold (possibly by buying 
fluendo codecs). Technically, we could do video decoding on both guest 
and client, depending on their power resources.

As for plugin passthrough, nspluginwrapper would help on firefox. I'm 
not sure though, if something similar exists for IE.


David Jaša

>> Y.
>>
>> On 06/23/2011 09:13 AM, Attila Sukosd wrote:
>>> How about WebM?
>>> http://www.webmproject.org/
>>>
>>> Sounds like it could be useful :)
>>>
>>> Best Regards,
>>> Attila Sukosd
>>>
>>> -----------------------------------------
>>> DTU Computing Center - www.cc.dtu.dk
>>> attila at cc.dtu.dk, gbaras at student.dtu.dk, s070600 at student.dtu.dk
>>>
>>>
>>>
>>>
>>> On Thu, Jun 23, 2011 at 1:58 AM, John A. Sullivan III
>>> <jsullivan at opensourcedevel.com>   wrote:
>>>> On Wed, 2011-06-22 at 23:49 +0200, Alon Levy wrote:
>>>>> On Wed, Jun 22, 2011 at 03:44:40PM -0400, John A. Sullivan III wrote:
>>>>>> On Wed, 2011-06-22 at 17:01 +0200, Alon Levy wrote:
>>>>>>> On Wed, Jun 22, 2011 at 09:56:28AM -0400, John A. Sullivan III wrote:
>>>>>>>> On Wed, 2011-06-22 at 11:27 +0200, Alon Levy wrote:
>>>>>>>>> <snip>>   Thank you very much for the explanation.  It's pretty much what I
>>>>>>>>>> expected - that the codec is different, trading CPU efficiency for
>>>>>>>>>> bandwidth inefficiency and I certainly understand the reasons why.
>>>>>>>>>>
>>>>>>>>>> Is there any thought or plan to make the codec configurable for those
>>>>>>>>>> who are willing to sacrifice CPU for bandwidth, e.g., VP8, Theora, or
>>>>>>>>>> H.264?
>>>>>>>>>>
>>>>>>>>> I haven't done any testing on this but I think the cpu requirements are large.
>>>>>>>>> maybe with hardware doing the encoding this would work well enough. Technically
>>>>>>>>> just dropping in a different codec and extending the protocol doesn't sound like
>>>>>>>>> a lot of work. Patches welcome?
>>>>>>>> <snip>
>>>>>>>> I wish I had the skill set to help in that way! Thanks - John
>>>>>>>>
>>>>>>> Would you be able to provide some benchmarks (choose some pc you have) for:
>>>>>>>   encoding speed of
>>>>>>>    VP8, Theora, H.264
>>>>>>>   for various bitdepths and resolutions (you choose, maybe just one - take the resolutions
>>>>>>>   of a normal youtube window and a fullscreen of your choice).
>>>>>>> ?
>>>>>>>
>>>>>>> Alon
>>>>>>>
>>>>>> I would be delighted to do so if it will help.  I don't have a clue how
>>>>>> to.  If you have a link or reference you can point me to, that would be
>>>>>> appreciated. Otherwise, it will be off to the world of Internet
>>>>>> research.  Thanks - John
>>>>> It's been pointed to me off list that my suggestion was very inaccurate, and that perhaps
>>>>> we have other considerations, like prefering an open (source, no patents) codec like
>>>>> Theora even if it is worse then H.264 / VP8. Yaniv gave a link to an already old but
>>>>> interesting comparison: http://keyj.emphy.de/video-encoder-comparison/
>>>>>
>>>> I believe H.264 is heavily patent encumbered even though free but I also
>>>> thought that VP8 was now not patent encumbered and as readily usable as
>>>> theora. It would seem to be the ideal candidate if using it as a real
>>>> time codec is feasible.  Again, I'm way out of my depth and merely
>>>> spewing a couple of hours of Internet research.  Thanks - John
>>>>
>>>> _______________________________________________
>>>> Spice-devel mailing list
>>>> Spice-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>
>>> _______________________________________________
>>> Spice-devel mailing list
>>> Spice-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>
>> _______________________________________________
>> Spice-devel mailing list
>> Spice-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


-- 


David Jaša