Open Bug 1403810 Opened 7 years ago Updated 2 years ago

Intermittent dom/media/test/reftest/bipbop_300_215kbps.mp4.lastframe.html == http://localhost:38815/1506565143848/665/reftest/bipbop_300_215kbps.mp4.lastframe-ref.html | image comparison, max difference: 255, number of differing pixels: 106192

Categories

(Core :: Audio/Video: Playback, defect, P5)

Product:
Core
Component:
Audio/Video: Playback
Type:
defect

Tracking

()

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: intermittent-failure)

Component: Audio/Video → Audio/Video: Playback
This is permafailing on linux64-qr as of bug 1215089. (linux64-qr is a regular linux64 build with webrender enabled, which you can do by putting MOZ_ACCELERATED=1 MOZ_WEBRENDER=1 in your environment before starting the build).

If the failure is going to tricky to fix or track down I'm not opposed to disabling the test for webrender until we can figure it out.
Blocks: 1215089
Flags: needinfo?(jyavenard)
(That being said, linux64-qr is tier-1 so this is technically grounds for a backout).
The issue seen in bug 1215089 which caused the backed out was in the WebGL code that incorrectly mixed width and stride.

Could it be that it's the problem in webrender ?

in the mean time, disabling the test with webrender would be the best option if it can't be resolved quickly.
the aim of supporting HDR on restricted platform is for evangelism perspective, and not having it in webrender because of webrender issues would not be an acceptable solution.
Flags: needinfo?(jyavenard)
looking at the screen shot: https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/cS4waWslRZuCT6YkQbQCKQ/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

this is definitely an issue of the wrong stride being use.

prior bug 1215089, there were a few misuse of the width field in place of stride. Those were corrected, and unfortunately exposed a few places in the code where those values were incorrectly used (e.g using the stride instead of the width or vice versa)
Flags: needinfo?(bugmail)
Ok, if you are fairly confident it is a bug on the webrender side feel free to reland your patches, but please mark the test as fails-if(webrender).
Flags: needinfo?(bugmail)
I can see an obvious issue in the binding:
http://searchfox.org/mozilla-central/source/gfx/webrender_bindings/RenderBufferTextureHost.cpp#70

this is using the width in place of the stride when allocating the texture.

But unfortunately, it's not sufficient for playback to be okay.

I'm investigating a bit (before just disabling the tests) because as it is, no video will play properly anymore...
ok, the bug that caused the surge of errors will be fixed in patch 12 of bug 1215089
Thank you for tracking it down!
(In reply to Jean-Yves Avenard [:jya] from comment #9)
> ok, the bug that caused the surge of errors will be fixed in patch 12 of bug
> 1215089

For the record, it was patch 11, i.e. https://hg.mozilla.org/mozilla-central/rev/edb7fa9379c7

Leaving this bug open, since it was actually filed for an intermittent that was seen before bug 1215089 landed.

There's a pernosco trace here that matches this bug title from a try push I did.

Looking at the reftest output, the difference seems to be that the expected/actual is off by one. (I don't know what the numbers mean, but one is 00:00:01.16, and the other is 00:00:01.17, with the code 000046 vs 000047; maybe a frame nuber

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.