Playing videos with yuv422p format (YV16) doesn't render colors properly.
Created attachment 109224 [details] Patch
Created attachment 109227 [details] Patch
Is it intentional that this patch only contains a regression test, not a fix?
(In reply to comment #3) > Is it intentional that this patch only contains a regression test, not a fix? The fix has been submitted to chrome, and will be committed today. Issue: http://code.google.com/p/chromium/issues/detail?id=95642, patch: http://codereview.chromium.org/8052002/
Comment on attachment 109227 [details] Patch Other platforms may want this test, so it seems reasonable to have it in WebKit. Your ChangeLog should have explained why there was no associated code change.
Comment on attachment 109227 [details] Patch Clearing flags on attachment: 109227 Committed r103477: <http://trac.webkit.org/changeset/103477>
All reviewed patches have been landed. Closing bug.
Chromium rebaselines done in http://trac.webkit.org/changeset/103553 (CPU) and http://trac.webkit.org/changeset/103603 (GPU).
(In reply to comment #5) > (From update of attachment 109227 [details]) > Other platforms may want this test, so it seems reasonable to have it in WebKit. Your ChangeLog should have explained why there was no associated code change. As written, this test is worthless to some ports because it is hard coded to use an Ogg video file instead of querying the UA to find out what formats is supports and using an appropriate file - the technique used by all the other media tests.
How can we guarantee to get a yuv422 video format by through a query? Other media files care about the codec of a file, however in this case both yuv422 and yuv420 are for the same codec. findMediaFile() returns the first file format that is supported which I don't see it helpful.
I agree with Eric. This test can be useful for all ports in which case there needs to be a copy of test_yuv420.ogv that works for webkit ports that don't support ogg (i.e., check in a test_yuv420.mp4). That way findMediaFile("video", "content/test_yuv420") will choose the appropriate ogv/mp4 extension based on UA support and this test can be enabled for all ports.
Reopening to attach new patch.
Created attachment 133606 [details] Patch
Created attachment 133608 [details] Patch
I am not very familiar with the process in WebKit. Should I open a new bug to update those tests? Should these tests be committed first and after running on the bots we open a new bug to create a baseline for all ports?
Comment on attachment 133608 [details] Patch Attachment 133608 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12123897 New failing tests: media/video-colorspace-yuv422.html media/video-colorspace-yuv420.html
Created attachment 133616 [details] Archive of layout-test-results from ec2-cr-linux-04 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-04 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Yes, it is much preferred to have one bug per patch, and certainly not to revive bugs that have been resolved for a long time.
Is this still necessary now that https://bugs.webkit.org/show_bug.cgi?id=82281 is in?