Print less output from compare_videos.py in WebRTC quality test.

Print less output from compare_videos.py in WebRTC quality test.

My best theory here is that compare_videos.py has been printing so much
output that we hit some buffer size, and give other processes the
chance to slip in stdout output. For instance, here the printf in the
test races with the user input monitor for Windows. This patch will
cause us to print just the result lines, which should keep us from
hitting this os buffer limitation.

For an example, search for PSNR in http://chromegw/i/chromium.webrtc/builders/Win7%20Tester/builds/5737/steps/webrtc_manual_browser_tests_test/logs/stdio. 
You can see that the user input monitor log writes right into the 
PSNR line.  I don't know what buffer size we are hitting, 
but the log line seems to always happen in a very consistent place 
which is why I think there's some buffer we fill up.

BUG=327990
R=kjellander@chromium.org,tommi@chromium.org

[kjellander_chromium, 2014-01-07 17:47:53]

I prefer we go ahead with http://review.webrtc.org/6679004/ instead to address
the original cause of this.

However, it would be nice to have some kind of safeguard in the browser test(s)
against this for the future, but I guess it's hard to do unless we figure out
what that buffer size is? Let's start with looking at how the Chromium WebRTC
FYI bots behave when this is submitted to WebRTC (then we'll wait for
webrtc_revision to be rolled in Chromium DEPS).

[phoglund_chromium, 2014-01-07 18:10:34]

Yeah, let's go ahead and close this one.

[fischman, 2014-01-07 18:25:43]

drive-by

On Tue, Jan 7, 2014 at 8:00 AM, <phoglund@chromium.org> wrote:

> My best theory here is that compare_videos.py has been printing so much
> output that we hit some buffer size, and give other processes the
> chance to slip in stdout output.
>

I think the explanation is simpler; the printf in question is going to
stdout but LOGs go to stderr.  There's no expectation of
atomicity/separation between the two when both FDs are pointed at the same
device.

(I agree that simply not emitting logspam is better, but I'm _also_
suggesting that once you have a reasonable set of output, sending it to
stderr instead of stdout might make more sense)

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.