The following layout test is failing (currently disabled in TestExpectations):

external/wpt/webvtt/rendering/cues-with-video/processing-model/dom_override_remove_cue_while_paused.html

The reason for the failure is because the conversion function, in the shader, is the following:
mediump vec3 _uDoColorConversion(in mediump vec3 _ucolor){
   (_ucolor = (mat3(1.1643835, 1.1643836, 1.1643835,
                    -1.5562883e-08, -0.39176229, 2.0172319,
                    1.5960267, -0.81296766, 1.2258721e-08) * _ucolor));
   (_ucolor += vec3(-0.87107271, 0.52930564, -1.0816754));
   return _ucolor;
}

3 8-bit textures are passed to the shader:
Y: 235 (uniform color)
U: 128 (uniform color)
V: 128 (uniform color)

So, after using the conversion function, we get:
R = 235/255 * 1.1643835 + 128/255 * -1.5562883e-08 + 128/255 * 1.5960267 + -0.87107271 = 1.0031294
G = 235/255 * 1.1643836 + 128/255 * -0.39176229 + 128/255 * -0.81296766 + 0.52930564 = 0.9976378
B = 235/255 * 1.1643835 + 128/255 * 2.0172319 + 128/255 * 1.2258721e-08 + -1.0816754 = 1.0039552

Note that, if we replace 128/255 by an exact 0.5, we get:
R = 235/255 * 1.1643835 + 0.5 * -1.5562883e-08 + 0.5 * 1.5960267 + -0.87107271 = 0.9999999
G = 235/255 * 1.1643836 + 0.5 * -0.39176229 + 0.5 * -0.81296766 + 0.52930564 = 1.0000001
B = 235/255 * 1.1643835 + 0.5 * 2.0172319 + 0.5 * 1.2258721e-08 + -1.0816754 = 0.9999999

so the matrix looks correct, but the error on 8 bit data is quite large. Multiplying each UV coefficient in the matrix by 255/256 would solve this issue, but then would cause some issue if the matrix was used with floating point textures, where a value of 0.5 can be properly represented.
Also, 10b textures, for example, would also have the same issue, with different factors (1023/1024).

The texture format should be taken into account, if possible, when computing the YUV matrix to avoid large rounding errors on non floating point formats.