The test was added in r276478. It returns the following failure in WebKitGTK: https://build.webkit.org/results/GTK-Linux-64-bit-Release-Tests/r276484%20%281349%29/webrtc/video-vp8-videorange-diff.txt --- /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/webrtc/video-vp8-videorange-expected.txt +++ /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/webrtc/video-vp8-videorange-actual.txt @@ -2,5 +2,5 @@ PASS Setting video exchange -PASS Track is enabled, video should not be black +FAIL Track is enabled, video should not be black assert_equals: expected "0,0,0" but got "1,0,1"
I had a look... Incoming BGRA frames are converted to I420. The dest colorimetry of the video converter used in GStreamerVideoFrameLibWebRTC::ToI420() is already BT.601 so the color ranges should be correct for incoming frames. Unless there is a bug in the gst video-converter. I am not sure yet.
Fixed by r276988.
*** This bug has been marked as a duplicate of bug 225345 ***
(In reply to Philippe Normand from comment #1) > I had a look... Incoming BGRA frames are converted to I420. The dest > colorimetry of the video converter used in > GStreamerVideoFrameLibWebRTC::ToI420() is already BT.601 so the color ranges > should be correct for incoming frames. > > Unless there is a bug in the gst video-converter. I am not sure yet. For the record, the issue isn't a color space (e.g BT601 vs 709 etc) but a color range one. The data coming in though should be YUV already as that's what is coming out of the vp8 decoder. It's surprising that you would get BGRA in between, this imply that in the code path there's a double conversion happening YUV -> BGRA -> YUV which would be less than optimal. Maybe it's worth investigating this further.