744063 - 'Fullscreen playback' NVIDIA stereo 3d for youtube not working in FF 13 or higher

Status: VERIFIED FIXED

Description

[testing.s3d]

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

[:Gavin Sharp [email: [e-mail]]]

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?

Comment 2

[Anthony Hughes (:ashughes) [GFX][QA][Mentor]]

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

[Alex Keybl [:akeybl]]

(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.

Comment 4

[testing.s3d]

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

[Jason Smith [:jsmith]]

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.

Comment 6

[Anthony Hughes (:ashughes) [GFX][QA][Mentor]]

(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

[Jason Smith [:jsmith]]

(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 8

[Anthony Hughes (:ashughes) [GFX][QA][Mentor]]

Jason, did you get a chance to retest this?

Comment 9

[Alex Keybl [:akeybl]]

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).

Comment 10

[Jason Smith [:jsmith]]

(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

[Anthony Hughes (:ashughes) [GFX][QA][Mentor]]

(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

[Jason Smith [:jsmith]]

(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

[Anthony Hughes (:ashughes) [GFX][QA][Mentor]]

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

[Jason Smith [:jsmith]]

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

[Jason Smith [:jsmith]]

2/18 I mean in that first sentence*

Comment 16

[Jason Smith [:jsmith]]

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

[Jason Smith [:jsmith]]

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

[Jason Smith [:jsmith]]

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 <[e-mail]> - 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 <[e-mail]> - 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

Comment 19

[Anthony Hughes (:ashughes) [GFX][QA][Mentor]]

(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

[Jason Smith [:jsmith]]

Maybe it's the patch in bug 714445? Kyle Huey - Thoughts?

Comment 21

[Jason Smith [:jsmith]]

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.

Comment 22

[Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary)]

(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

[Jason Smith [:jsmith]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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.

Comment 24

[Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary)]

Does this problem reproduce in Firefox 11?  Bug 714445 shipped in Firefox 11.

Comment 25

[Jason Smith [:jsmith]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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.

Comment 26

[Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary)]

Ok, then it's probably bug 714445.

Comment 27

[Jason Smith [:jsmith]]

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

[Alex Keybl [:akeybl]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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?

Comment 29

[Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary)]

Backing out bug 714445 is not the right fix.  Reading preferences off the main thread is not something we want to reintroduce.

Comment 30

[Matthew Gregan [:kinetik]]

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

[Jason Smith [:jsmith]]

(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

[:Gavin Sharp [email: [e-mail]]]

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

Comment 33

[Matthew Gregan [:kinetik]]

Hm, nothing in that regression range jumps out at me as being a possible culprit.

Comment 34

[Matthew Gregan [:kinetik]]

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.

Comment 35

[Matthew Gregan [:kinetik]]

Confirmed, b2f1b368e2f2 is good and 67b0e13d7a62 is bad.

Comment 36

[Alex Keybl [:akeybl]]

Sending over to Bas since it's believed that he landed the regressing bug.

Comment 37

[Bas Schouten (:bas.schouten)]

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

[Jason Smith [:jsmith]]

(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

[Bas Schouten (:bas.schouten)]

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

[Bas Schouten (:bas.schouten)]

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

[Bas Schouten (:bas.schouten)]

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

[Jason Smith [:jsmith]]

This is also not working in the latest nightly and aurora builds.

Comment 44

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Since we have the hardware, we'd better fix this. I can help out with any ImageLayer issues.

Comment 45

[Matthew Gregan [:kinetik]]

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.

Comment 46

[Matthew Gregan [:kinetik]]

specially = specifically, sorry.

Comment 47

[Bas Schouten (:bas.schouten)]

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!

Comment 48

[Matthew Gregan [:kinetik]]

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).

Comment 49

[Matthew Gregan [:kinetik]]

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

[Bas Schouten (:bas.schouten)]

(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.

Comment 51

[Matthew Gregan [:kinetik]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fb10831a58a5

Comment 52

[Benoit Girard (:BenWa)]

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.

Comment 53

[Bas Schouten (:bas.schouten)]

(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 54

[Matthew Gregan [:kinetik]]

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.

Comment 55

[Matthew Gregan [:kinetik]]

Please don't ignore Bugzilla's clobber warning.

Comment 56

[Benoit Girard (:BenWa)]

(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

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/fb10831a58a5

Comment 58

[Alex Keybl [:akeybl]]

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.

Comment 59

[Jason Smith [:jsmith]]

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?

Comment 60

[Matthew Gregan [:kinetik]]

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

[Anthony Hughes (:ashughes) [GFX][QA][Mentor]]

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

[juan becerra [:juanb]]

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

[juan becerra [:juanb]]

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

[Anthony Hughes (:ashughes) [GFX][QA][Mentor]]

Thanks a lot, Juan!

Comment 65

[testing.s3d]

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