Re: [rtcweb] New VP8 vs H.264 tests uploaded (UNCLASSIFIED)

On 04/04/2013 08:23 PM, Thomas Davies (thdavies) wrote:
> The single-core encode speed I get from these settings is <5fps for the example I chose (which is one of the data points), so these are *not* real time tests.
>
> My understanding is that Google have selected a non-real-time encoding mode to show the capabilities of the VP8 technology and attempted to do the same with x264, hence the --tune veryslow parameter.

One of the tests we provide is a comparision of the encode time vs 
quality for the two codecs.
Of course this one varies a LOT even between different developers' 
machines (the absolute numbers, that is) - machines are very different 
in how fast they encode. Try it out!

>
> Best regards
>
> Thomas
>
> -----Original Message-----
> From: Roy, Radhika R CIV USARMY (US) [mailto:radhika.r.roy.civ@mail.mil]
> Sent: 04 April 2013 18:03
> To: Leon Geyser; Thomas Davies (thdavies)
> Cc: rtcweb@ietf.org
> Subject: RE: [rtcweb] New VP8 vs H.264 tests uploaded (UNCLASSIFIED)
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Yes, real-time applications (i.e. two-way or multipoint conversation)
> performance requirements are fundamentally much more stringent than those of
> the near-real-time (i.e. video streaming)/nor-real-time applications.
>
> So, settings for testing for each one of those applications must be done
> accordingly.
>
> Best regards,
> Radhika
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> Leon Geyser
> Sent: Thursday, April 04, 2013 12:56 PM
> To: Thomas Davies
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] New VP8 vs H.264 tests uploaded
>
> 	If the purpose is to show whether vp8 is superior as a *technology*
> to h264 CBP, then I think the comparison should use the best settings you
> have (ideally with a special full-on non-real time implementation) and test
> against the JM reference encoder. Ideally you would use the same or similar
> GOP structures, number of references, prediction and QP hierarchies.
> 	
>
> I thought WebRTC was meant for real-time communication. What would it
> benefit us if we test settings that won't be used or can't be used in
> practice?
>
> The tests need to test the encoders at realtime/low latency and at a
> constrained bitrate mode like CBR. We aren't archiving videos here :)
>
> A graph that shows the bitrate over time for each clip could be usefull to
> make sure that no encoder spikes the bitrate too high at certain moments.
> I welcome changes to the encoder settings as long as they stay realtime/low
> latency and constrained bitrate.
>   
> On 4 April 2013 17:05, Thomas Davies <thdavies@cisco.com> wrote:
>
>
> 	Harald,
>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb