Last Comment Bug 869866 - 'Fullscreen playback' NVIDIA stereo 3d for youtube not working since FX21
: 'Fullscreen playback' NVIDIA stereo 3d for youtube not working since FX21
Status: RESOLVED WONTFIX
: regression
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: 22 Branch
: x86 Windows 7
: -- normal (vote)
: ---
Assigned To: Milan Sreckovic [:milan]
: juan becerra [:juanb]
Mentors:
Depends on:
Blocks: 837859
  Show dependency treegraph
 
Reported: 2013-05-08 02:56 PDT by testing.s3d
Modified: 2015-02-25 09:52 PST (History)
24 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
-
wontfix
-
wontfix
-


Attachments
Disable H.264 High Profile Level 3.1, leaving all the profiles, including high supported at 3.0 (1.16 KB, patch)
2013-05-13 13:23 PDT, Milan Sreckovic [:milan]
cpearce: feedback+
Details | Diff | Review

Description testing.s3d 2013-05-08 02:56:42 PDT
User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.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; BOIE9;ENUS)

Steps to reproduce:

1. Install Aurora version 22.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 testing.s3d 2013-05-08 02:58:48 PDT
This is similar to the earlier bug: 744063
https://bugzilla.mozilla.org/show_bug.cgi?id=744063
Comment 2 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-05-08 11:45:37 PDT
Juan, can you try to reproduce this in the QA Lab?
Comment 3 Milan Sreckovic [:milan] 2013-05-09 10:48:07 PDT
I think I'm seeing the same behaviour on 21 (beta) as well.  When did this work last? (+1 on the regression window wanted).
Comment 4 Milan Sreckovic [:milan] 2013-05-09 10:52:12 PDT
I'm not sure how to read comment 0 - does it work correctly in the window, but not in full screen, or does it not work correctly in both full screen and window?
Comment 5 juan becerra [:juanb] 2013-05-09 11:29:31 PDT
I was able to reproduce on 22.a2 with the latest build from today. I'll have to check check in 21 and find a regression range as well.
Comment 6 juan becerra [:juanb] 2013-05-09 14:19:51 PDT
This is the regression range I came up with:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ba515e203813&tochange=bc108d2ce8d1
Comment 7 juan becerra [:juanb] 2013-05-09 14:50:28 PDT
(In reply to Milan Sreckovic [:milan] from comment #4)
> I'm not sure how to read comment 0 - does it work correctly in the window,
> but not in full screen, or does it not work correctly in both full screen
> and window?

Works correctly within the window but not in fullscreen mode.
Comment 8 Milan Sreckovic [:milan] 2013-05-10 07:18:50 PDT
Juan et al., I'm having trouble getting 20 to work either, which makes it difficult to actually test.  I find a number of 3d YouTube videos "complain" about not being available in HTML5 format - can you provide a direct link to the one that you had working on 20?  This is how I'm setup:
* In Nvidia control panel's "Manage 3D settings", stereo is enabled and stereo display mode is set to "generic active stereo" - should the settings be different?
* Under set up stereoscopic 3d, it's enabled and running the "Test stereoscopic 3d..." runs in stereo (full screen mode).
* I tried, for example, with www.youtube.com/watch?v=Hbhv27ITXT0&feature=html5_3d
* It lets me choose html5 3d - on the unsupported hardware, I get the "unsupported hardware" message, there is no such message here.
* what am I missing?
Comment 9 Milan Sreckovic [:milan] 2013-05-10 07:27:07 PDT
Never mind, got it. I had some non-default config options.
Comment 10 Milan Sreckovic [:milan] 2013-05-10 09:54:57 PDT
Narrower regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8f4ec9046b03&tochange=1eab3e0d7f53
Comment 11 Milan Sreckovic [:milan] 2013-05-10 11:04:12 PDT
This is caused by the fix to bug 837859, enabling WMF back end.  Just backing that out is likely not an option, I imagine the fallout would be significant.
Comment 12 Milan Sreckovic [:milan] 2013-05-10 11:09:54 PDT
I can, however, confirm that setting the preference media.windows-media-foundation.enabled to false (non-default) makes the problem go away.
Comment 13 bhavana bajaj [:bajaj] 2013-05-10 11:50:19 PDT
(In reply to Milan Sreckovic [:milan] from comment #12)
> I can, however, confirm that setting the preference
> media.windows-media-foundation.enabled to false (non-default) makes the
> problem go away.

:Milan, by switching the pref-off will the user lose the ability to playback MP3/MP4/H.264/AAC in HTML5 <video> and <audio> which bug 837859 is essentially resolving?
Comment 14 bhavana bajaj [:bajaj] 2013-05-10 11:52:54 PDT
Also adding needinfo on Juan who is in the lab testing this atm. to help confirm the above and also see if the original problem of changing the 3D viewing mode works fine with other modes other than HTML5 stereo view ?
Comment 15 Milan Sreckovic [:milan] 2013-05-10 12:51:06 PDT
(In reply to bhavana bajaj [:bajaj] from comment #13)
> 
> :Milan, by switching the pref-off will the user lose the ability to playback
> MP3/MP4/H.264/AAC in HTML5 <video> and <audio> which bug 837859 is
> essentially resolving?

I think it may make it worse, but I don't think it takes it away in general, though perhaps it does in Metro.  Chris would know better, but that may take until Monday to sort out.

I'm not suggesting we change the default, just to tell the users to change that preference if they have trouble with the full screen playback, as a stop gap measure.
Comment 16 juan becerra [:juanb] 2013-05-10 13:17:06 PDT
(In reply to bhavana bajaj [:bajaj] from comment #14)
> Also adding needinfo on Juan who is in the lab testing this atm. to help
> confirm the above and also see if the original problem of changing the 3D
> viewing mode works fine with other modes other than HTML5 stereo view ?

Unfortunately HTML5 stereo view is the only mode that really works stereoscopically, at least with the hardware at hand. It's probably the most common scenario.
Comment 17 Chris Pearce (:cpearce) 2013-05-10 14:03:45 PDT
So, there's a couple of moving parts here.

* Primarily, enabling WMF means we support H.264/AAC/MP3.
* We have to implement 3D support on a per-format basis, we've only done it for WebM so far.
* When we have H.264 support enabled in Firefox, YouTube is probably querying to see if the browser supports H.264, and trying to play H.264 in preference to WebM.
* Because we don't have 3D video support for H.264 yet, the video plays side by side. That's why disabling the pref makes 3D work again, because then we're playing WebM and our WebM decoder is 3D aware.

So this is not a regression, in as much as it is a new feature request; support 3D in H.264 in Firefox.
Comment 18 Chris Pearce (:cpearce) 2013-05-10 14:18:43 PDT
(In reply to Milan Sreckovic [:milan] from comment #15)
> (In reply to bhavana bajaj [:bajaj] from comment #13)
> > 
> > :Milan, by switching the pref-off will the user lose the ability to playback
> > MP3/MP4/H.264/AAC in HTML5 <video> and <audio> which bug 837859 is
> > essentially resolving?

Yes, the user will not be able to play H.264/AAC/MP3 files if they disable that perf.


> I'm not suggesting we change the default, just to tell the users to change
> that preference if they have trouble with the full screen playback, as a
> stop gap measure.

This seems the least risky thing to do.
Comment 19 Milan Sreckovic [:milan] 2013-05-10 16:09:55 PDT
(In reply to Chris Pearce (:cpearce) from comment #17)
> 
> So this is not a regression, in as much as it is a new feature request;
> support 3D in H.264 in Firefox.

It's possible this is the case, but let me challenge it just a bit, as it will at least clear it up for me:
* this plays just fine in the window.  so, we are decoding and displaying the movie correctly.
* it fails on full screen only; unless we're getting different content when we switch to full screen?

Looking at the trunk, the difference between the success in window and failure in full screen, seems to be that ImageLayerD3D10::RenderLayer() fails to GetContainer() in the full screen case with WMF enabled.
Comment 20 Milan Sreckovic [:milan] 2013-05-10 16:27:00 PDT
Bas, any idea why GetContainer would fail?
Comment 21 Milan Sreckovic [:milan] 2013-05-10 16:39:40 PDT
Never mind, the container is there.
Comment 22 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2013-05-10 16:42:10 PDT
(In reply to Milan Sreckovic [:milan] from comment #19)
> * this plays just fine in the window.  so, we are decoding and displaying
> the movie correctly.

You mean 3D H.264 videos play just fine in a window?
Comment 23 Jason Smith [:jsmith] 2013-05-10 16:55:01 PDT
Just a FYI from the testing Juan & I did on this a while back when the fallback content was used (WebM) and we had this bug occur - We never saw this problem happen in the window case at all, it only happened in the fullscreen case.

You can see my response on release drivers, but I think the right short-term solution is an outreach approach to YouTube to serve us WebM.
Comment 24 Chris Pearce (:cpearce) 2013-05-10 19:56:28 PDT
YouTube is requesting a higher res stereo H.264 video when it enters fullscreen on stereo video pages, and a comparatively lower res stereo WebM video when in windowed mode otherwise. That's why we see this issue only when fullscreen, as we don't support stereo H.264 yet, and YouTube must be assuming that anything that reports that it canplay H.264 can handle stereo H.264.
Comment 25 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2013-05-12 21:54:34 PDT
Filed bug 871421 on supporting 3D with WMF. However we shouldn't try to do that to fix the regression. I agree that Youtube outreach is probably the best approach for now...
Comment 26 bhavana bajaj [:bajaj] 2013-05-13 11:41:09 PDT
cc'ing :jet & needsinfo'ing him to check if he has any contacts to try and to do the outreach here, as :jason mentioned he may have the right and direct Engineering contacts that may be helpful here.
Comment 27 Milan Sreckovic [:milan] 2013-05-13 13:13:18 PDT
One (perhaps relevant) point - all of the movies I tried are done in H.264 High Profile Level 3.1.  Inside of our code, we support constrained baseline, baseline, extended, main and high at level 3.0, as well as high profile level 3.1.

If we stop supporting H.264 High Profile 3.1 this bug goes away.  This means that we still have H.264 support for all the other profiles.  I have no idea what percentage of the content on the web is using High Profile 3.1 (avc1.64001F).

Does that make sense as a workaround for this release?
Comment 28 Milan Sreckovic [:milan] 2013-05-13 13:23:20 PDT
Created attachment 748976 [details] [diff] [review]
Disable H.264 High Profile Level 3.1, leaving all the profiles, including high supported at 3.0

Disabling the high profile level 3.1 makes the bug go away - what are we losing by taking out this level?
Comment 29 Chris Pearce (:cpearce) 2013-05-13 15:25:16 PDT
Comment on attachment 748976 [details] [diff] [review]
Disable H.264 High Profile Level 3.1, leaving all the profiles, including high supported at 3.0

Review of attachment 748976 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, this is how to tell our canPlayType API implementation to not report that it can play High Profile Level 3.1.

I have no idea how much content out there is level 3.1, it may be very common. If we took this patch we would report that we couldn't play Level 3.1, but we'd still be able to play it if users tried to play it despite us reporting that we couldn't.
Comment 30 strobe 2013-05-17 16:21:07 PDT
Many videos use this profile for 1080p, including YouTube H.264 1080p material; disabling it might have consequences beyond this particular bug. YouTube's looking into this issue, expect to see a page-level fix soon.

The diversity of playback conditions is exceeding the expressiveness of codec profile and level info (and for codecs that don't have this concept, like VP8, it's even harder to determine whether e.g. a platform supports 4K video streams). A more general solution to this problem might involve standardizing and then checking additional parameters to RFC 6381-style bucket MIME types, like size and stereo3d.
Comment 31 Alex Keybl [:akeybl] 2013-06-11 09:52:28 PDT
This is being fixed on the YouTube side, so we no longer need to track on our end.
Comment 32 Matt Grimes [:Matt_G] 2013-07-23 22:16:38 PDT
Can anyone confirm if this has been fixed on the Youtube side as Alex mentioned? We've got a support article up that we'd like to archive if it is no longer an issue.
Comment 33 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-07-24 09:40:21 PDT
Juan, would you mind quickly checking if this still reproduces in our lab?
Comment 34 juan becerra [:juanb] 2013-07-24 10:58:37 PDT
I can still reproduce this on the latest Fx23 beta.

Who do we need to remind on YouTube's end to get this fixed?
Comment 36 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2015-02-25 09:21:12 PST
Over to Release Management to make a call here. This has been broken for over two years. Do we have active engineering resources assigned to NVidia 3D support? Does YouTube? If not, this bug should probably be resolved WONTFIX until that situation changes.
Comment 37 Sylvestre Ledru [:sylvestre] 2015-02-25 09:52:52 PST
We have been pinged by Nvidia a few time on this topic. As far as I understand, there is some important architecture issues with this part of the code which makes it hard for us to work on it. AFAIK, there are even discussions to remove the code itself.

So, to me, yes, WONTFIX is the appropriate answer to this bug.

Note You need to log in before you can comment on or make changes to this bug.