Summary: | [chromium] Video-related compositor tests failing in DumpRenderTree | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Kenneth Russell <kbr> | ||||
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | jamesr, kbr, mihaip, scherkus, tkent, tony, vangelis, vrk | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Kenneth Russell
2010-10-05 17:22:24 PDT
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) (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. (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? (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? 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) (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. yeah it's an mpeg-4 as opposed to h.264 video :( (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? probably best/safest to do something like in LayoutTests/media Created attachment 82872 [details]
Patch
Tests still fail with image diffs even with this fix, filed bug 54694 about that. Comment on attachment 82872 [details]
Patch
LGTM except ChangeLog diff starting at line 3.
Committed r78951: <http://trac.webkit.org/changeset/78951> (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. |