22593 2008-12-02 11:12:09 -0800 <video> pixel tests are failing if display is asleep 2008-12-04 12:49:05 -0800 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Mac OS X 10.5 RESOLVED WONTFIX P2 Normal --- 21911 1 pol pol mitz oldest_to_newest 101029 0 pol 2008-12-02 11:12:09 -0800 <video> pixel tests are randomly failing on bots (actually, they are failing more often than passing): when failing, the failure is apparently always the same: it's a different in brightness Fail: http://build.webkit.org/results/trunk-mac-intel-pixel/665/results.html Pass: http://build.webkit.org/results/trunk-mac-intel-pixel/664/results.html Fail: http://build.webkit.org/results/trunk-mac-intel-pixel/663/results.html 101260 1 pol 2008-12-03 14:02:26 -0800 Doesn't seem to repro on the Tiger bot: there it's always the same 2 tests that fail. I can't repro the random failure on my machine which is very similar to the Leopard bot, so I took offline the bot to attempt to repro there, but still can't after several attempts (either when running LayoutTests/media or the entire LayoutTests). There must be something different the build bot does... For reference, the expected RGB value of the top-left pixel of the first video when the display is using the GenericRGB profile for the LayoutTests/media/video-aspect-ratio.html test is 60-23-87. 101374 2 pol 2008-12-04 12:45:52 -0800 Actually, I spoke too fast: I cannot repro the failures on the Tiger bot and these failures are also brightness related, so I guess it's the same bug. The difference is that on the Leopard bot it happens now and then, while on Tiger all the time: media/video-aspect-ratio.html expected image image diffs 2.05% media/video-controls-rendering.html expected image image diffs 1.68% http://build.webkit.org/builders/trunk-mac-ppc-pixel 101375 3 pol 2008-12-04 12:49:05 -0800 I finally found the cause: the video frame in the <video> layout tests only renders with a different brightness when the display of the computer is asleep! Tiger 10.4.11 & Leopard 10.5.5 are apparently affected when using QT 7.5.5. I don't know however it's specific to this H264 video used by the tests or a generic <video> issue. I don't think it's worth tracking down as it's potentially quite a bit of work for a limited return: only test system are affected as nobody would want to watch a video with the display asleep.