Closed
Bug 744063
Opened 13 years ago
Closed 13 years ago
'Fullscreen playback' NVIDIA stereo 3d for youtube not working in FF 13 or higher
Categories
(Core :: Graphics, defect)
Tracking
()
VERIFIED
FIXED
mozilla15
People
(Reporter: testing.s3d, Assigned: kinetik)
References
Details
(Keywords: regression, reproducible, Whiteboard: [qa+:juanb])
Attachments
(1 file)
2.95 KB,
patch
|
bas.schouten
:
review+
akeybl
:
approval-mozilla-aurora+
akeybl
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; FDM)
Steps to reproduce:
1. Install Aurora latest version 13.0a2
2. Open Aurora Browser and goto www.3dvisionlive.com/3dv-html5-detection
3. Goto http://www.3dvisionlive.com/yt3d
4. Click on '3D button -> Change 3D viewing mode and select HTML5 stereo view'.
5. Play the video in full screen and observe.
Actual results:
Full screen HTML5 videos are not playing in Stereo mode. Video is playing side by side.
Expected results:
Full screen HTML5 videos should play in stereo mode
Comment 1•13 years ago
|
||
From the release-drivers email, this apparently works fine in Firefox 9, but not in Firefox 13? Can you get a narrower regression range than that?
Keywords: regressionwindow-wanted
I seem to remember there being some "NVidia Stereo 3D" issue we were considering taking for Firefox 11.0.1 -- is there any correlation to that issue?
Comment 3•13 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #2)
> I seem to remember there being some "NVidia Stereo 3D" issue we were
> considering taking for Firefox 11.0.1 -- is there any correlation to that
> issue?
That's bug 725152 and affected all 3d video - this is specific to FS 3D video.
(In reply to testing.s3d from comment #0)
> 1. Install Aurora latest version 13.0a2
As Gavin notes, it'd be good to know if FF12 (beta) or FF14 (nightly) are affected. If possible, you can go even further and use http://harthur.github.com/mozregression/ (along with dates from https://wiki.mozilla.org/Rapid_Release/Calendars) to find an exact regression date. Anthony would be a good contact if you have any questions about the tool.
Reporter | ||
Comment 4•13 years ago
|
||
I tried regressing using mozregression. But this fullscreen 3d bug seems to have been introduced after the generic bug 725152 which affected all 3d video.
So it looks like the fullscreen 3d bug got in while the all 3d video was broken. So cannot regress here.
Comment 5•13 years ago
|
||
Results from Geo and I's testing
Prerequistes
We confirmed hardware with NVIDIA's drivers. We also tested the demos NVIDIA had to make sure that we had 3D video worked as expected. We confirmed we had 3D video setup correctly.
Testing
We tested the following different videos:
http://www.3dvisionlive.com/3d_video Silverlight Oil Rush 3D Trailer
http://www.3dvisionlive.com/3d_video Silverlight Oil Rush 3D Trailer Full Screen
http://www.3dvisionlive.com/content/nvidia-3d-vision-pc-0 Embedded YouTube HTML 5 demo
http://www.youtube.com/watch?v=T9fpI3IzV20 YouTube HTML 5 video
http://www.youtube.com/watch?v=T9fpI3IzV20 YouTube HTML 5 video Full Screen
Results
9.0.1 release
* Entering/Exiting Silverlight video (partial and full screen) worked as expected (glasses on and off at right time)
* Entering YouTube HTML 5 video worked as expected in all cases.
* Exiting YouTube HTML 5 video by closing tab did not turn off glasses in any case. Exiting Firefox did.
12.0 b6
* Worked exactly the same as 9.0.1 release
13.0 a2
* Worked as 9.0.1 release, EXCEPT:
* Entering YouTube HTML 5 full-screen video showed side-by-side rather than through alternating shutters.
Updated•13 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•13 years ago
|
Component: General → Video/Audio
QA Contact: general → video.audio
Updated•13 years ago
|
(In reply to Jason Smith from comment #5)
> 13.0 a2
> * Worked as 9.0.1 release, EXCEPT:
> * Entering YouTube HTML 5 full-screen video showed side-by-side rather than through alternating shutters.
I believe this is the root issue for this bug (ie. side-by-side video rather than shuttered).
Jason, would it be possible for you to narrow down a regression range using the Firefox 13 Nightly nightlies?
Comment 7•13 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #6)
> (In reply to Jason Smith from comment #5)
> > 13.0 a2
> > * Worked as 9.0.1 release, EXCEPT:
> > * Entering YouTube HTML 5 full-screen video showed side-by-side rather than through alternating shutters.
>
> I believe this is the root issue for this bug (ie. side-by-side video rather
> than shuttered).
>
> Jason, would it be possible for you to narrow down a regression range using
> the Firefox 13 Nightly nightlies?
Not yet, since we no longer have a machine hooked up for 3D video testing (I gave the machine back to Clint). I need to get a machine setup for this though, as it is important.
Comment 9•13 years ago
|
||
JP, who's the right person to take a look at this bug? We'd like to fix for FF13 (where the regression first appears).
Assignee: nobody → jpr
Keywords: regression
Comment 10•13 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #8)
> Jason, did you get a chance to retest this?
Finally got a machine setup for this (took a while though). We were able to reproduce the problem on Firefox 13 Beta. Confirmed that it works correctly in Firefox 12. However, in the process of testing, we noticed that video preview (even in 12) shows the double video. Is that bug filed somewhere?
Now that we have the machine correctly, we can regression test this to know when the problem happened.
Important note - During our setup, when we hit configuration issues, we noticed that the double-video showing even happened with the demo video when it was incorrectly configured (e.g. required graphics driver for GE Force GT 520 wasn't installed).
Comment 11•13 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #10)
> (In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #8)
> > Jason, did you get a chance to retest this?
>
> Finally got a machine setup for this (took a while though). We were able to
> reproduce the problem on Firefox 13 Beta. Confirmed that it works correctly
> in Firefox 12. However, in the process of testing, we noticed that video
> preview (even in 12) shows the double video. Is that bug filed somewhere?
I thought that was *this* bug? From comment 0:
> Actual results:
>
> Full screen HTML5 videos are not playing in Stereo mode. Video is playing side by side.
Comment 12•13 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #11)
> (In reply to Jason Smith [:jsmith] from comment #10)
> > (In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #8)
> > > Jason, did you get a chance to retest this?
> >
> > Finally got a machine setup for this (took a while though). We were able to
> > reproduce the problem on Firefox 13 Beta. Confirmed that it works correctly
> > in Firefox 12. However, in the process of testing, we noticed that video
> > preview (even in 12) shows the double video. Is that bug filed somewhere?
>
> I thought that was *this* bug? From comment 0:
>
> > Actual results:
> >
> > Full screen HTML5 videos are not playing in Stereo mode. Video is playing side by side.
This bug refers to full-screen mode, not preview mode (preview is when you hover the stream progress bar and you see a small preview window in youtube).
Comment 13•13 years ago
|
||
Thanks for that clarification, Jason. Can you please file a bug for the preview issue in a new bug? Also, please continue to drill down the regression range for *this* bug. Ideally, we need an offending changeset ID by Monday.
Comment 14•13 years ago
|
||
comment 4's argument may be correct, although I'll check a couple more nightly builds before 2/8. I downloaded a 2/18 nightly build and saw this issue still happening. The bug blocking analysis of this bug (bug 752152) was fixed on 2/15 8:43am. I'll check 2/17, 2/16, 2/15 nightly builds as well. If this is correct, then a regression window for this specific bug might not be possible. We could figure out when bug 725152 was first broken (not sure if that helps though).
Comment 15•13 years ago
|
||
2/18 I mean in that first sentence*
Comment 16•13 years ago
|
||
Update on this bug (and it's good news actually for getting a regression range) - so both bug 725152 and this bug occurred on 2/15.
Comment 17•13 years ago
|
||
Regression window:
Last working: January 1st Nightly Build
First failed: January 2nd Nightly Build
Anthony - How do I get a change log for this between the two days?
Comment 18•13 years ago
|
||
Hmm, the regression window doesn't make sense why that happens, but I've checked again to make sure. Looking at the logs on moz-central, nothing was checked in within that timeframe:
e2b6064a04ff: Bug 683205 - Reftests for RLE8 BMPs. r=joe.
diff
browse
Brian R. Bondy <netzen@gmail.com> - Tue, 03 Jan 2012 21:37:59 -0500 - rev 83724
Bug 683205 - Reftests for RLE8 BMPs. r=joe.
d0e3133d19e2: Bug 713183 - Make JSOP_*PROP and JSOP_*NAME store a PropertyName immediate, not a JSAtom immediate, and take advantage of this fact. r=bhackett
diff
browse
Jeff Walden <jwalden@mit.edu> - Tue, 27 Dec 2011 02:27:02 -0600 - rev 83723
Bug 713183 - Make JSOP_*PROP and JSOP_*NAME store a PropertyName immediate, not a JSAtom immediate, and take advantage of this fact. r=bhackett
Updated•13 years ago
|
Keywords: regressionwindow-wanted
Comment 19•13 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #17)
> Regression window:
>
> Last working: January 1st Nightly Build
> First failed: January 2nd Nightly Build
Thanks Jason.
> Anthony - How do I get a change log for this between the two days?
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-01-01&enddate=2012-01-02
Comment 20•13 years ago
|
||
Maybe it's the patch in bug 714445? Kyle Huey - Thoughts?
Comment 21•13 years ago
|
||
Looking at the patch for the code (https://bugzilla.mozilla.org/attachment.cgi?id=585137&action=diff), it definitely looks like it's touching code that says "stereo mode." I have a hunch this is the patch that caused this regression.
(In reply to Jason Smith [:jsmith] from comment #20)
> Maybe it's the patch in bug 714445? Kyle Huey - Thoughts?
See comment 4.
Comment 23•13 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #22)
> (In reply to Jason Smith [:jsmith] from comment #20)
> > Maybe it's the patch in bug 714445? Kyle Huey - Thoughts?
>
> See comment 4.
I don't think comment 4 is completely right, cause I did get a regression range here. Yes, 3D video wasn't "working," but I think what that comment refers to is not seeing the 3D layout in the video. This bug refers to seeing the duplicated side by side video. I tested various builds from 2/18 all the way back to Jan 1st - what I noticed was that the two issues acted independently of one another (e.g. on 2/18 I was able to see the 3D pieces of video, but saw the issue specified in this bug). Looking at both pieces of code though, it looks like they are touching the same area:
- https://bug725152.bugzilla.mozilla.org/attachment.cgi?id=596875
- https://bugzilla.mozilla.org/attachment.cgi?id=585137&action=diff
I've confirmed this twice on our test machine in the lab - Jan 1st working, busted on Jan 2nd.
Does this problem reproduce in Firefox 11? Bug 714445 shipped in Firefox 11.
Comment 25•13 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #24)
> Does this problem reproduce in Firefox 11? Bug 714445 shipped in Firefox 11.
Yes. Tested on Firefox 11 Release - This problem also occurs there.
Ok, then it's probably bug 714445.
Blocks: 714445
Comment 27•13 years ago
|
||
To backup and review the data collected so far:
- Firefox 9.0.1 - Works
- Firefox 11 - Busted
- Firefox 12 - Works
- Firefox 13 - Busted
Patch linked to possibly is bug 714415.
Open question - Why would it be working in Firefox 12, but busted in Firefox 13?
Comment 28•13 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #26)
> Ok, then it's probably bug 714445.
Can you prepare a try build with bug 714445 backed out for QA to test?
Backing out bug 714445 is not the right fix. Reading preferences off the main thread is not something we want to reintroduce.
Assignee | ||
Comment 30•13 years ago
|
||
Bug 725152 fixed the regression introduced by bug 714445. It seems pretty likely that *this* regression was introduced during the period that stereo video was broken by bug 714445.
Try setting the integer pref "media.webm.force_stereo_mode" to either 1 or 2 (either should work, one will probably result in the stereo effect being depth reversed) and rerunning the regression search.
Comment 31•13 years ago
|
||
(In reply to Matthew Gregan [:kinetik] from comment #30)
> Bug 725152 fixed the regression introduced by bug 714445. It seems pretty
> likely that *this* regression was introduced during the period that stereo
> video was broken by bug 714445.
>
> Try setting the integer pref "media.webm.force_stereo_mode" to either 1 or 2
> (either should work, one will probably result in the stereo effect being
> depth reversed) and rerunning the regression search.
Set that pref and re-ran a regression range on this:
Last Working: Feb 3rd
First Failed: Feb 4th
Changelog: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-02-03&enddate=2012-02-04
Comment 32•13 years ago
|
||
FWIW, you can get more accurate pushlog ranges by getting the changesets from about:buildconfig in the relevant builds, and then using fromchange/tochange instead of dates, e.g.:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=da45fc5e6b95&tochange=766a59650976
Assignee | ||
Comment 33•13 years ago
|
||
Hm, nothing in that regression range jumps out at me as being a possible culprit.
Assignee | ||
Comment 34•13 years ago
|
||
Firefox 12 works for me, but the breakage occurs at the *start* of that regression range, so the hunt is for something in the range of AURORA_BASE_20120131:da45fc5e6b95. My best guess is that this'll be bug 715785.
No longer blocks: 714445
Assignee | ||
Comment 35•13 years ago
|
||
Confirmed, b2f1b368e2f2 is good and 67b0e13d7a62 is bad.
Blocks: 715785
Comment 36•13 years ago
|
||
Sending over to Bas since it's believed that he landed the regressing bug.
Assignee: jpr → bas.schouten
Updated•13 years ago
|
Assignee: bas.schouten → nobody
Component: Video/Audio → Graphics
QA Contact: video.audio → thebes
Updated•13 years ago
|
Assignee: nobody → bas.schouten
Comment 37•13 years ago
|
||
I don't have a NVidia 3D Vision setup and I can't figure anything out from looking at the code. Is there anyway I can trick the page into thinking I have one so I can at least inspect some variables?
Comment 38•13 years ago
|
||
(In reply to Bas Schouten (:bas) from comment #37)
> I don't have a NVidia 3D Vision setup and I can't figure anything out from
> looking at the code. Is there anyway I can trick the page into thinking I
> have one so I can at least inspect some variables?
Note - There is a machine setup in Mt View for this. If there is someone you know from GFX that could debug this that works in the Mt View office, let me know, as I could work with this person on this bug.
Comment 39•13 years ago
|
||
Youtube keeps telling me 'HTML5 3D Unavailable' when I try to open these links directly, any pointers to what I'm doing wrong?
Comment 40•13 years ago
|
||
Never mind, I guess these just really weren't available, using Jason's exact video I can at least get something to play and to let me inspect some variables.
Comment 41•13 years ago
|
||
As far as I can tell (without having the proper hardware). All the metadata is seen right in Layers and the instructions are sent. However the regression range obviously points at the ImageLayer changes. I'm not sure what I can do locally here, hopefully Matthew or Jeff can take a look? The relevant code is in ImageLayerD3D10::Render and ImageLayerD3D9::Render.
Comment 42•13 years ago
|
||
This is also not working in the latest nightly and aurora builds.
status-firefox14:
--- → affected
status-firefox15:
--- → affected
Updated•13 years ago
|
Summary: 'Fullscreen playback' NVIDIA stereo 3d for youtube not working in latest Aurora v13 → 'Fullscreen playback' NVIDIA stereo 3d for youtube not working in FF 13 or higher
Since we have the hardware, we'd better fix this. I can help out with any ImageLayer issues.
Assignee: bas.schouten → kinetik
Assignee | ||
Comment 45•13 years ago
|
||
This seems to fix it for me; specially passing the correct texture sizes to SendNv3DVMetaData, the other changes just fix the warning logic.
Attachment #626356 -
Flags: review?(bas.schouten)
Assignee | ||
Comment 46•13 years ago
|
||
specially = specifically, sorry.
Comment 47•13 years ago
|
||
Comment on attachment 626356 [details] [diff] [review]
v0
Review of attachment 626356 [details] [diff] [review]:
-----------------------------------------------------------------
Ahah! Apparently mSize is set to the size of mPicSize.
Let's do the same change for ImageLayerD3D9!
Attachment #626356 -
Flags: review?(bas.schouten) → review+
Assignee | ||
Comment 48•13 years ago
|
||
Oh, that reminds me, the D3D9 backend didn't work at all for me in stereo mode. I'll apply the same change there tomorrow and retest, but there may be something else wrong there (possibly even a different regression range).
Assignee | ||
Comment 49•13 years ago
|
||
Stereo 3D with the D3D9 backend is completely broken in Firefox 12 for me, as far as I can tell (by setting gfx.direct2d.disabled == true and layers.prefer-d3d9 == true), so I'm going to file a separate bug for that.
Comment 50•13 years ago
|
||
(In reply to Matthew Gregan [:kinetik] from comment #49)
> Stereo 3D with the D3D9 backend is completely broken in Firefox 12 for me,
> as far as I can tell (by setting gfx.direct2d.disabled == true and
> layers.prefer-d3d9 == true), so I'm going to file a separate bug for that.
Good thing is somebody with recent drivers and a modern GPU (i.e. most 3D Vision users), aren't going to be on D3D9 layers, but yeah.
Assignee | ||
Comment 51•13 years ago
|
||
Assignee | ||
Updated•13 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla15
Comment 52•13 years ago
|
||
It would be really nice to get someone to look into the shadow layers implementation of stereo 3d while we get this setup so that it doesn't break again with OMTC.
Status: ASSIGNED → NEW
Target Milestone: mozilla15 → ---
Comment 53•13 years ago
|
||
(In reply to Benoit Girard (:BenWa) from comment #52)
> It would be really nice to get someone to look into the shadow layers
> implementation of stereo 3d while we get this setup so that it doesn't break
> again with OMTC.
If the proposed layers rewrite goes through, that will take care of this. (In a way that will -hopefully- allow implementing this relatively easily on other platforms (i.e. OGL) as well)
Assignee | ||
Comment 54•13 years ago
|
||
Comment on attachment 626356 [details] [diff] [review]
v0
[Approval Request Comment]
Bug caused by (feature/regressing bug #): 715785
User impact if declined: Stereo 3D disabled when switching video resolution, zooming the page, or switching to fullscreen
Testing completed (on m-c, etc.): Yes
Risk to taking this patch (and alternatives if risky): Low.
String or UUID changes made by this patch: None.
Attachment #626356 -
Flags: approval-mozilla-beta?
Attachment #626356 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 55•13 years ago
|
||
Please don't ignore Bugzilla's clobber warning.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla15
Comment 56•13 years ago
|
||
(In reply to Matthew Gregan [:kinetik] from comment #55)
> Please don't ignore Bugzilla's clobber warning.
Sorry, I though I redid my comment properly.
Comment 57•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Whiteboard: [qa+]
Comment 58•13 years ago
|
||
Comment on attachment 626356 [details] [diff] [review]
v0
[Triage Comment]
Low risk regression fix localized to 3D video. Approved for Aurora 14 and Beta 13.
Attachment #626356 -
Flags: approval-mozilla-beta?
Attachment #626356 -
Flags: approval-mozilla-beta+
Attachment #626356 -
Flags: approval-mozilla-aurora?
Attachment #626356 -
Flags: approval-mozilla-aurora+
Comment 59•13 years ago
|
||
Strangely enough, I can no longer get a reproduction of this problem on FF 13 Beta, FF 14 Aurora, and FF 15 Nightly with the patch applied. Do YouTube fix something behind the scenes?
Assignee | ||
Comment 60•13 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/f937f9e12e9b
https://hg.mozilla.org/releases/mozilla-beta/rev/986ab7634e22
(In reply to Jason Smith [:jsmith] from comment #59)
> Strangely enough, I can no longer get a reproduction of this problem on FF
> 13 Beta, FF 14 Aurora, and FF 15 Nightly with the patch applied. Do YouTube
> fix something behind the scenes?
Are you sure it hasn't reverted to Flash mode? YouTube seems to forget the HTML5 opt-in cookie pretty frequently for me. I don't think there are any changes that could've resolved this from YouTube's side; it's a bug in our rendering code.
Comment 61•13 years ago
|
||
Jason is now on PTO until Wednesday I believe. Juan can you check this is fixed in that latest Aurora? We'll need to wait until Beta 6 (Monday) to test this for Beta.
Thanks
Comment 62•13 years ago
|
||
I was working with Jason yesterday on this, planning ahead of his PTO, so we could both see the same results. I'll check this later today.
Comment 63•13 years ago
|
||
Verified on Fx13b6, latest Fx14 and Fx15 (5/31) using the steps in comment #0, full screen HTML5 videos play in stereo mode.
Comment 64•13 years ago
|
||
Thanks a lot, Juan!
Status: RESOLVED → VERIFIED
Whiteboard: [qa+] → [qa+:juanb]
Reporter | ||
Comment 65•12 years ago
|
||
We are observing this issue again with Aurora ver 22.0a2.
A new bug is filed: https://bugzilla.mozilla.org/show_bug.cgi?id=869866
You need to log in
before you can comment on or make changes to this bug.
Description
•