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
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?
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?
(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.
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.
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.
(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?
(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.
Jason, did you get a chance to retest this?
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).
(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).
(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.
(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).
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 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).
2/18 I mean in that first sentence*
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.
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?
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
(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
Maybe it's the patch in bug 714445? Kyle Huey - Thoughts?
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.
(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.
(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.
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?
(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.
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.
(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
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
Hm, nothing in that regression range jumps out at me as being a possible culprit.
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.
Confirmed, b2f1b368e2f2 is good and 67b0e13d7a62 is bad.
Sending over to Bas since it's believed that he landed the regressing bug.
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?
(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.
Youtube keeps telling me 'HTML5 3D Unavailable' when I try to open these links directly, any pointers to what I'm doing wrong?
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.
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.
This is also not working in the latest nightly and aurora builds.
*** Bug 756409 has been marked as a duplicate of this bug. ***
Since we have the hardware, we'd better fix this. I can help out with any ImageLayer issues.
Created attachment 626356 [details] [diff] [review] v0 This seems to fix it for me; specially passing the correct texture sizes to SendNv3DVMetaData, the other changes just fix the warning logic.
specially = specifically, sorry.
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!
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).
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.
(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.
https://hg.mozilla.org/integration/mozilla-inbound/rev/fb10831a58a5
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.
(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)
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.
Please don't ignore Bugzilla's clobber warning.
(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.
https://hg.mozilla.org/mozilla-central/rev/fb10831a58a5
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.
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?
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.
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
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.
Verified on Fx13b6, latest Fx14 and Fx15 (5/31) using the steps in comment #0, full screen HTML5 videos play in stereo mode.
Thanks a lot, Juan!
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
or
