Closed
Bug 1395543
Opened 7 years ago
Closed 7 years ago
Virtual Reality Tour bug in latest FF version
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(fennec+, firefox55 affected, firefox56 fix-optional, firefox57 fix-optional)
RESOLVED
DUPLICATE
of bug 1395497
Tracking | Status | |
---|---|---|
fennec | + | --- |
firefox55 | --- | affected |
firefox56 | --- | fix-optional |
firefox57 | --- | fix-optional |
People
(Reporter: johan, Unassigned)
Details
Attachments
(1 file)
(deleted),
image/png
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/601.2.7 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.7
Steps to reproduce:
In my Virtual Reality Tours (made with Panotour software from Kolor) it's possible to blend in movie footage in a 360 photo (called "Livepano).
Please look at www.ccvr-schipholairport.com, choose option Virtual Tour and look how this works in the first stop the Tour. On desktop browser and other mobile browsers no problem, however with new FF for Android v55.0 there's an error.
Actual results:
The movie part in the 360 photo is now shown as a black box (see enclosed). The sound still works well.
Expected results:
The piece of footage should have been shown seamlessly.
Dear Sebastian,
This is my first big report at Mozilla.
Can you please update me if this bug will be picked up/assigned to someone?
Is more information needed from my side?
Best regards, Johan
Flags: needinfo?(s.kaspari)
Comment 2•7 years ago
|
||
Thank you, Johan! I'll flag it for our bug triage meeting. Also cc-ing Mike Taylor from the webcompat team.
Flags: needinfo?(s.kaspari)
Updated•7 years ago
|
tracking-fennec: --- → ?
This simple HTML5 video texture fail into Firefox 55.02 for Android (with WebGL).
https://krpano.com/ios/bugs/ios8-webgl-video-performance/
This is mandatory to use an HTML5 video as texture for 360° videos and VR needs.
Thanks.
Comment 5•7 years ago
|
||
On Firefox for Android, there is no VR support. VR only supports on Desktop Firefox. In terms of WebGL video support, we just landed a big patch for GPU video in FF 57. We have confirmed it will increase our performance on Desktop platforms. No sure if it would help for Android FF, but it is worth to have a try. Btw, users need to disable anti-aliasing for WebGL context, otherwiser, on some mobile devices, it indeed will be black.
Flags: needinfo?(dmu)
Comment 6•7 years ago
|
||
Hi Johan
Is comment 5 gives you enough information you need?
Flags: needinfo?(johan)
Jamie I think we probably need to put back the attach/detach stuff in SurfaceTexture, that way we can consume the video SurfaceTexture for canvas. Is that something you can do?
tracking-fennec: ? → +
status-firefox55:
--- → affected
status-firefox56:
--- → fix-optional
status-firefox57:
--- → fix-optional
Flags: needinfo?(jnicol)
Comment 8•7 years ago
|
||
I'm not familiar with how this worked before. In GLBlitHelpers we need to attach, render to an fb, then detach. But at the same time we might need to use the texture in the compositor. Do we attach and detach in TextureHost::Lock and Unlock? How do we serialize the access?
Flags: needinfo?(jnicol) → needinfo?(snorp)
Comment 9•7 years ago
|
||
Hi,
about 'users need to disable anti-aliasing for WebGL context':
Antialias was already disabled in that example and it still not working:
https://krpano.com/ios/bugs/ios8-webgl-video-performance/
So that shouldn't be the reason.
Beside of this - there should be never the need to manually disable antialias to get something basic working of course! ;-)
Maybe see also the page-source of that example for more information - all code is in the html file. It is a very reduced example and uses only very little and simple WebGL code.
Best regards,
Klaus
(In reply to Jamie Nicol [:jnicol] from comment #8)
> I'm not familiar with how this worked before. In GLBlitHelpers we need to
> attach, render to an fb, then detach. But at the same time we might need to
> use the texture in the compositor. Do we attach and detach in
> TextureHost::Lock and Unlock? How do we serialize the access?
Right. We'd need a cross-process mutex most likely.
Flags: needinfo?(snorp)
Reporter | ||
Comment 11•7 years ago
|
||
Hi guys, being the person who started this bug report 20 days, I'm wondering ... will this be solved in the next update and, if so, when is this update released?
Many people depend on this part of Firefox for Android working well and they keep seeing now the black screen.
Hope you guys can give me an indication. I have no experience in this (I add as a disclaimer).
Cheers, Johan
Flags: needinfo?(johan)
Comment 12•7 years ago
|
||
Bug 1395497 has patches so I'm closing this as a duplicate of that
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 13•7 years ago
|
||
Hi Guys,
I just downloaded v56.0 but error is still there (for screenshot: see my first post here; it's identical).
I see that the message is flagged "RESOLVED".
May be the guys/Benjamin from KOLOR/GOPRO can give his tech view on this?
Comment 14•7 years ago
|
||
Hi Johan.
"Resolved" in this case only means that the work is being tracked in bug 1395497 rather than here. Multiple bugs were filed with the same root cause, and that's the one which has more activity on it. Hopefully it should be fixed soon.
Assignee | ||
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•