Bug 47231 – [chromium] Video-related compositor tests failing in DumpRenderTree

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Kenneth Russell]

The following video-related compositor tests are failing in DumpRenderTree when run with --enable-accelerated-compositing. I haven't triaged the failures but suspect that they all have the same root cause.

compositing/geometry/clipped-video-controller.html
compositing/geometry/video-fixed-scrolling.html
compositing/geometry/video-opacity-overlay.html
compositing/layers-inside-overflow-scroll.html
compositing/overflow/overflow-compositing-descendant.html
compositing/overflow/scroll-ancestor-update.html
compositing/reflections/load-video-in-reflection.html
compositing/self-painting-layers.html
compositing/self-painting-layers2.html
compositing/video/video-background-color.html
compositing/video/video-poster.html

[Mihai Parparita]

It looks like all these tests fail because they can't load the test video file: http://svn.webkit.org/repository/webkit/trunk/LayoutTests/compositing/resources/video.mp4

(not sure what makes it special, Safari, QuickTime and VLC can play it just fine)

[Kenneth Russell]

(In reply to comment #1)
> It looks like all these tests fail because they can't load the test video file: http://svn.webkit.org/repository/webkit/trunk/LayoutTests/compositing/resources/video.mp4
> 
> (not sure what makes it special, Safari, QuickTime and VLC can play it just fine)

Hmm. Thinking about this more, we only include certain decoders in the Google Chrome branded build, not Chromium. We are probably missing the appropriate decoder in DRT.

[Mihai Parparita]

(In reply to comment #2)
> Hmm. Thinking about this more, we only include certain decoders in the Google Chrome branded build, not Chromium. We are probably missing the appropriate decoder in DRT.

The tests in media/ have findMediaFile (http://trac.webkit.org/browser/trunk/LayoutTests/media/media-file.js) which switches to ogg if that's playable. Does it make sense to do that here too?

[Kenneth Russell]

(In reply to comment #3)
> (In reply to comment #2)
> > Hmm. Thinking about this more, we only include certain decoders in the Google Chrome branded build, not Chromium. We are probably missing the appropriate decoder in DRT.
> 
> The tests in media/ have findMediaFile (http://trac.webkit.org/browser/trunk/LayoutTests/media/media-file.js) which switches to ogg if that's playable. Does it make sense to do that here too?

Maybe. vrk, scherkus, can you confirm?

[Andrew Scherkus]

That's most likely the issue.

To verify try building DRT with GYP_DEFINES="ffmpeg_branding=Chrome" and see if the tests run (or at least don't crap out because we don't support .mp4)

[Mihai Parparita]

(In reply to comment #5)
> That's most likely the issue.
> 
> To verify try building DRT with GYP_DEFINES="ffmpeg_branding=Chrome" and see if the tests run (or at least don't crap out because we don't support .mp4)

Actually, the video.mp4 file doesn't seem to play in Chrome dev channel (on Mac) either, which presumably should be able to handle the h264 codec.

[Andrew Scherkus]

yeah it's an mpeg-4 as opposed to h.264 video :(

[Mihai Parparita]

(In reply to comment #7)
> yeah it's an mpeg-4 as opposed to h.264 video :(

For the compositor tests I don't think we care about specific codecs, just that there's a video element. Is there a codec that we could use that would work on all platforms/ports, or do we have to include both ogg and h264 or mpeg-4 files?

[Andrew Scherkus]

probably best/safest to do something like in LayoutTests/media

[Mihai Parparita]

Created attachment 82872 [details]
Patch

[Mihai Parparita]

Tests still fail with image diffs even with this fix, filed bug 54694 about that.

[Kent Tamura]

Comment on attachment 82872 [details]
Patch

LGTM except ChangeLog diff starting at line 3.

[Mihai Parparita]

Committed r78951: <http://trac.webkit.org/changeset/78951>

[Mihai Parparita]

(In reply to comment #12)
> (From update of attachment 82872 [details])
> LGTM except ChangeLog diff starting at line 3.

That was just a bad diff since there were two consecutive entries with my name on them. Once I rebaselined to ToT it started at line 1.