Closed Bug 869866 Opened 11 years ago Closed 10 years ago

'Fullscreen playback' NVIDIA stereo 3d for youtube not working since FX21

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
22 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox20 --- unaffected
firefox21 - wontfix
firefox22 - wontfix
firefox23 - ---

People

(Reporter: testing.s3d, Assigned: milan)

References

Details

(Keywords: regression)

Attachments

(1 file)

Disable H.264 High Profile Level 3.1, leaving all the profiles, including high supported at 3.0
(deleted), patch
cpearce
: feedback+
Details | Diff | Splinter Review 
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
This is similar to the earlier bug: 744063
https://bugzilla.mozilla.org/show_bug.cgi?id=744063
Juan, can you try to reproduce this in the QA Lab?
QA Contact: jbecerra
I think I'm seeing the same behaviour on 21 (beta) as well.  When did this work last? (+1 on the regression window wanted).
tracking-firefox22: + → ?
tracking-firefox23: + → ?
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?
Flags: needinfo?(testing.s3d)
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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.
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?
Flags: needinfo?(testing.s3d) → needinfo?(jbecerra)
Never mind, got it. I had some non-default config options.
Flags: needinfo?(jbecerra)
Assignee: nobody → milan
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.
I can, however, confirm that setting the preference media.windows-media-foundation.enabled to false (non-default) makes the problem go away.
(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?
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 ?
Flags: needinfo?(jbecerra)
(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.
Flags: needinfo?(cpearce)
(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.
Flags: needinfo?(jbecerra)
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.
Flags: needinfo?(cpearce)
(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.
Blocks: 837859
(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.
Bas, any idea why GetContainer would fail?
Flags: needinfo?(bas)
Never mind, the container is there.
Flags: needinfo?(bas)
(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?
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.
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.
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...
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.
Flags: needinfo?(bugs)
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?
Disabling the high profile level 3.1 makes the bug go away - what are we losing by taking out this level?
Attachment #748976 - Flags: feedback?(cpearce)
No longer blocks: 854372
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.
Attachment #748976 - Flags: feedback?(cpearce) → feedback+
Summary: 'Fullscreen playback' NVIDIA stereo 3d for youtube not working in Aurora Ver22.0a2 → 'Fullscreen playback' NVIDIA stereo 3d for youtube not working since FX21
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.
Flags: needinfo?(bugs)
This is being fixed on the YouTube side, so we no longer need to track on our end.
tracking-firefox21: + → -
tracking-firefox22: + → -
tracking-firefox23: + → -
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.
Juan, would you mind quickly checking if this still reproduces in our lab?
Flags: needinfo?(jbecerra)
Keywords: qawanted
I can still reproduce this on the latest Fx23 beta.

Who do we need to remind on YouTube's end to get this fixed?
Flags: needinfo?(jbecerra)
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.
status-firefox21: affected → wontfix
status-firefox22: affected → wontfix
Flags: needinfo?(release-mgmt)
Keywords: qawanted
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(release-mgmt)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: