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

["Roy, Radhika R CIV USARMY (US)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
Leon Geyser
Sent: Thursday, April 04, 2013 12:56 PM
To: Thomas Davies
Cc: [e-mail]
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 <[e-mail]> wrote:


	Harald,



Classification: UNCLASSIFIED
Caveats: NONE