Bug 69113 – Video format yuv422p doesn't show properly.

• Component: Media
• Status: RESOLVED FIXED

[Shadi]

Playing videos with yuv422p format (YV16) doesn't render colors properly.

[Shadi]

Created attachment 109224 [details]
Patch

[Shadi]

Created attachment 109227 [details]
Patch

[Alexey Proskuryakov]

Is it intentional that this patch only contains a regression test, not a fix?

[Shadi]

(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/

[Eric Seidel (no email)]

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.

[WebKit Review Bot]

Comment on attachment 109227 [details]
Patch

Clearing flags on attachment: 109227

Committed r103477: <http://trac.webkit.org/changeset/103477>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Ryosuke Niwa]

Chromium rebaselines done in http://trac.webkit.org/changeset/103553 (CPU) and http://trac.webkit.org/changeset/103603 (GPU).

[Eric Carlson]

(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.

[Shadi]

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.

[Andrew Scherkus]

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.

[Shadi]

Reopening to attach new patch.

[Shadi]

Created attachment 133606 [details]
Patch

[Shadi]

Created attachment 133608 [details]
Patch

[Shadi]

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?

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[Alexey Proskuryakov]

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.

[Eric Carlson]

Is this still necessary now that https://bugs.webkit.org/show_bug.cgi?id=82281 is in?