Paused WebM videos with alpha channel become completely transparent when hardware acceleration is disabled

VERIFIED FIXED in Firefox 53

Status

()

VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: kkoorts, Assigned: kkoorts)

Tracking

unspecified
mozilla54
Points:
---

Firefox Tracking Flags

(firefox53 verified, firefox54 verified)

Details

Attachments

(1 attachment)

(Assignee)

Description

2 years ago
For videos opened in their own tab:
https://simpl.info/videoalpha/video/dancer1.webm
http://media-hearth.cursecdn.com/goldCards/0/303/303.webm
1. Pausing the video causes it to become transparent.
2. A looping video has an annoying transparent flash each time it passes the end of the video.

For videos embedded in a web page:
https://simpl.info/videoalpha/
1. Pausing the video followed by clicking elsewhere to remove focus from the video causes it to become transparent.
2. Looping videos flash, same as in the own-tab case.
(Assignee)

Updated

2 years ago
Assignee: nobody → kkoorts
Blocks: 944117
Comment hidden (mozreview-request)

Comment 2

2 years ago
mozreview-review
Comment on attachment 8829274 [details]
Bug 1332952 - Implement GetAsSourceSurface() for SharedRGBImage.

https://reviewboard.mozilla.org/r/106386/#review107646

::: gfx/layers/ipc/SharedRGBImage.cpp:120
(Diff revision 1)
> +
> +  RefPtr<gfx::SourceSurface> surface;
> +  { //should this be in its own scope? copied structure from BasicPlanarYCbCrImage::GetAsSourceSurface()
> +    BufferTextureData* decoded_buffer =
> +      mTextureClient->GetInternalData()->AsBufferTextureData();
> +    RefPtr<gfx::DrawTarget> drawTarget = decoded_buffer->BorrowDrawTarget();

Please add a comment about how we're 'borrowing' the DT and retaining a permanent reference to the underlying data (via the surface), but that it's in this instance since we know that the TextureClient is always wrapping a BufferTextureData so it won't go away underneath us.
Attachment #8829274 - Flags: review?(matt.woodrow) → review+
Comment hidden (mozreview-request)
(Assignee)

Updated

2 years ago
Keywords: checkin-needed

Comment 4

2 years ago
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/7927148d6726
Implement GetAsSourceSurface() for SharedRGBImage. r=mattwoodrow
Keywords: checkin-needed
(Assignee)

Comment 5

2 years ago
Comment on attachment 8829274 [details]
Bug 1332952 - Implement GetAsSourceSurface() for SharedRGBImage.

Approval Request Comment
[Feature/Bug causing the regression]: Bug 944117 - WebM alpha support
[User impact if declined]: WebM alpha will not work correctly (frames go completely transparent when paused) when hardware acceleration is disabled.
[Is this code covered by automated tests?]: There is a reftest for the general case of alpha working in WebM videos, but not for this specific case as the test machines have hardware acceleration enabled.
[Has the fix been verified in Nightly?]: I have verified it
[Needs manual test from QE? If yes, steps to reproduce]: No it's not a commonly used feature.
[List of other uplifts needed for the feature/fix]:
[Is the change risky?]: No
[Why is the change risky/not risky?]: It is not risky as it implements a method that doesn't affect anything besides WebM videos with alpha, and is straightforward to implement.
[String changes made/needed]: No string changes needed
Attachment #8829274 - Flags: approval-mozilla-aurora?

Comment 6

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/7927148d6726
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox54: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
status-firefox53: --- → affected
Comment on attachment 8829274 [details]
Bug 1332952 - Implement GetAsSourceSurface() for SharedRGBImage.

Looks like a long standing regression, may not affect too many people but let's go for it in aurora 53.   If you would like this fix in beta and think it's worth uplift, it isn't too late.
Attachment #8829274 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 8

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/fcb2593e3808
status-firefox53: affected → fixed
Depends on: 1333335
No longer depends on: 1333335
I managed to reproduce this issue on Firefox 53.0a1 (2017-01-21), under Windows 7x64, using the examples from Comment 0.
The issue is no longer reproducible on Firefox 53.0b2, or on Firefox 54.0a2 (2017-03-15).
Tests were performed under Windows 7x64, Mac OS X 10.12.1, Ubuntu 16.04x64.
Status: RESOLVED → VERIFIED
status-firefox53: fixed → verified
status-firefox54: fixed → verified
You need to log in before you can comment on or make changes to this bug.