[Spice-devel] Streaming video performance concepts

Yaniv Kaul ykaul at redhat.com
Thu Jun 23 00:50:57 PDT 2011


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?
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



More information about the Spice-devel mailing list