Closed Bug 1053482 Opened 8 years ago Closed 2 years ago

GUM does properly handle certain tab dimensions when tab sharing

Categories

(Firefox for Android Graveyard :: Screencasting, defect)

ARM
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: rbarker, Unassigned)

Details

Attachments

(3 files)

When sharing a tab via GUM, if the height or width is an odd number, the v plane in the yuv image has an extra width / 4 padding of bytes at the beginning.
It isn't just odd dimensions, (odd dimensions will actually trigger an assert in debug builds). I have also get improperly generated yuv images at 1196 x 622. The problem again appears to be extra padding in the v plane.
Summary: GUM does properly handle odd dimensions when tab sharing → GUM does properly handle certain tab dimensions when tab sharing
Attachment #8472696 - Attachment description: U and V plane both have extra padding → U and V plane both have extra padding at 1196 x 622
Per blassey's bug/comments in bug 1124512, this is likely the RGB->YUV conversion code, or some other variation that's not producing YUV 4:2:0 correctly (or with different assumptions about stride/padding than the webrtc code assumes, or that's hard-coded somewhere.
We've found a bug in the MediaPipeline video reception code (fixed in Nightly), that would cause chroma offsets/tears in received video with odd widths/heights (but not in gUM streams piped directly to a <video> element).  Can this be retested without the %4 to verify if it's still needed?  thanks
Flags: needinfo?(rbarker)
(In reply to Randell Jesup [:jesup] from comment #5)
> We've found a bug in the MediaPipeline video reception code (fixed in
> Nightly), that would cause chroma offsets/tears in received video with odd
> widths/heights (but not in gUM streams piped directly to a <video> element).
> Can this be retested without the %4 to verify if it's still needed?  thanks

I've removed the %4 from MediaEngineTabVideoSource.cpp however I am unable to create a video with odd width. When I set the max width in toolkit/modules/secondscreen/RokuApp.jsm to 379, I receive a video of width 378 (which is rendered correctly on the receiving end). Is there some where else that is rounding down to the nearest even value?
Flags: needinfo?(rbarker)
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.