[Webkit-unassigned] [Bug 199505] New: [GStreamer] media/video-volume.html broken after switching from cubic to linear scaling

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=199505

            Bug ID: 199505
           Summary: [GStreamer] media/video-volume.html broken after
                    switching from cubic to linear scaling
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cturner at igalia.com
                CC: bugs-noreply at webkitgtk.org

Reported test failure was,

--- /home/phil/WebKit/WebKitBuild/Debug/layout-test-results/media/video-volume-expected.txt
+++ /home/phil/WebKit/WebKitBuild/Debug/layout-test-results/media/video-volume-actual.txt
@@ -12,7 +12,7 @@
 EVENT(canplaythrough)
 EXPECTED (video.volume == '0') OK
 RUN(video.volume = 0.5)
-EXPECTED (video.volume == '0.5') OK
+EXPECTED (video.volume == '0.5'), OBSERVED '0.5000011920928955' FAIL
 TEST(video.volume = 1.5) THROWS(DOMException.INDEX_SIZE_ERR) OK
 TEST(video.volume = -0.5) THROWS(DOMException.INDEX_SIZE_ERR) OK
 END OF TEST

This failure was caused by r246730, although it's not a regression. I believe it's a bug in the PA project. PA does it's own linear<->cubic conversions, which was part of the motivation for r246730 in the first place. However, despite the APIs for this conversion promising a inverse operation, we get,

pa_sw_volume_to_linear(pa_sw_volume_from_linear(0.5)) -> 0.500001

The reason this worked before was due to the cubic scaling we initially applied. When you cube 0.5, you get 0.125 and pa_sw_volume_to_linear(pa_sw_volume_from_linear(0.125)) -> 0.125, so the cbrt gives back 0.5. The test passes, but not in the way you would expect.

I believe the bug in PA is due to their use of implicitly widening 32-bit integers to 64-bits in their interpolation code, and getting garbage (undefined memory) in the resulting value which when cast back to float, gives us a rounding issue. I am talking with the developers about it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190704/9def4e54/attachment.html>