[Regression] Some H.264 videos have green border
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox97 | --- | unaffected |
firefox98 | --- | wontfix |
firefox99 | --- | verified |
People
(Reporter: kevin, Assigned: lsalzman)
References
(Regression, )
Details
(Keywords: regression)
Attachments
(4 files)
(deleted),
image/png
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-release-
|
Details |
In Firefox Nightly (Build 20220304152603) on Linux in either Wayland or XWayland (haven't tested plain X), some H.264 videos are decoded incorrectly, resulting in a green border along some edges of the image. For example, https://thumbs.gfycat.com/IncompatibleNaiveBobolink-mobile.mp4 (screenshot attached)
mozregression pushlog https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ac8115af185628e4d938cc18088843cb6cffae76&tochange=3b1e43ee77740b6fd56351a017a7a78634b863b9 suggests this was regressed by Bug 1713276.
I'm able to reproduce the issue with either media.ffmpeg.vaapi.enabled=true
or media.ffmpeg.vaapi.enabled=false
. I'm unable to reproduce the issue on Windows.
Reporter | ||
Comment 1•3 years ago
|
||
Reporter | ||
Comment 2•3 years ago
|
||
Updated•3 years ago
|
Comment 3•3 years ago
|
||
Set release status flags based on info from the regressing bug 1713276
Comment 4•3 years ago
|
||
:alwu, since you are the author of the regressor, bug 1713276, could you take a look?
For more information, please visit auto_nag documentation.
Comment 5•3 years ago
|
||
Hi, Lee,
I guess this is something like bug 1757111, would you mind to help take it a look?
Thank you.
Assignee | ||
Comment 6•3 years ago
|
||
(In reply to Alastor Wu [:alwu] from comment #5)
Hi, Lee,
I guess this is something like bug 1757111, would you mind to help take it a look?
Thank you.
This looks like a bug directly in bug 1713276. I tried loading the video in MPV, and it reports a size of 460x244. Whereas the non-aligned dimensions (mPicSize) of the video directly at FFmpegVideoDecoder::CreateEmptyPlanarYCbCrData are being reported as 464x256. So somehow there is some sizing information that is being lost when you are decoding it? is coded_width/coded_height the wrong thing to be accessing there?
Assignee | ||
Comment 7•3 years ago
|
||
Updated•3 years ago
|
Comment 9•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Ah, thank for helping this. Yep, using width
and height
for mPicSize
looks correct.
Comment 11•3 years ago
|
||
Is this something you wanted to ride-along in a 98 dot release? Please nominate for release approval if so.
Assignee | ||
Comment 12•3 years ago
|
||
Comment on attachment 9266645 [details]
Bug 1758193 - Don't use codec_width and coded_height for mPicSize. r?alwu
Beta/Release Uplift Approval Request
- User impact if declined: Improper cropping of videos when using the FFmpeg decoder.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: 1750858 1757111
- Risk to taking this patch: Medium
- Why is the change risky/not risky? (and alternatives if risky): Slightly risky in terms of the number of files changed overall (between this, bug 1750858, and bug 1757111). The alternative, however, is that videos will look wrong regardless due to the original clipping issue. The changes so far have not seemed to cause any increases in instability the last few weeks and seem to resolve the clipping issues.
- String changes made/needed:
Comment 13•3 years ago
|
||
Comment on attachment 9266645 [details]
Bug 1758193 - Don't use codec_width and coded_height for mPicSize. r?alwu
Given the other dependencies we'd have to uplift for this, I think we're better off letting this ride 99 to release in a couple weeks instead.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 14•3 years ago
|
||
I was able to reproduce the issue on Ubuntu 20.4 using build 99.0a1 (20220304214025).
Verified as fixed on Ubuntu 20.4 / Win10x64 using builds: 99.0b4 (20220315185755) and 100.0a1 (20220315213924).
Description
•