224969 2021-04-22 22:38:34 -0700 [GStreamer] webrtc/video-vp8-videorange.html is failing 2021-05-05 03:07:05 -0700 1 1 1 Unclassified WebKit WebRTC WebKit Nightly Build Unspecified Unspecified RESOLVED DUPLICATE 225345 https://bugs.webkit.org/show_bug.cgi?id=225345 P2 Normal --- 1 dpino webkit-unassigned bugs-noreply jean-yves.avenard pnormand oldest_to_newest 1753461 0 dpino 2021-04-22 22:38:34 -0700 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" 1753503 1 pnormand 2021-04-23 02:18:13 -0700 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. 1756802 2 dpino 2021-05-04 22:12:59 -0700 Fixed by r276988. 1756810 3 dpino 2021-05-04 22:30:54 -0700 *** This bug has been marked as a duplicate of bug 225345 *** 1756881 4 jean-yves.avenard 2021-05-05 03:07:05 -0700 (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.