Last Comment Bug 901944 - Rendering glitches on H.264 video only in FF23 on Vista
: Rendering glitches on H.264 video only in FF23 on Vista
Status: RESOLVED FIXED
[leave open]
: regression
Product: Core
Classification: Components
Component: Audio/Video: Playback (show other bugs)
: 23 Branch
: x86 Windows Vista
: -- normal with 3 votes (vote)
: ---
Assigned To: Chris Pearce (:cpearce)
: Samvedana (:Samvedana)
: Anthony Jones (:kentuckyfriedtakahe, :k17e)
Mentors:
: 884203 (view as bug list)
Depends on:
Blocks: 847267
  Show dependency treegraph
 
Reported: 2013-08-06 07:24 PDT by banakon
Modified: 2016-05-15 02:21 PDT (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
verified disabled
+
disabled
+
disabled
+
fixed


Attachments
DxDiag.txt (52.74 KB, text/plain)
2013-08-07 15:37 PDT, banakon
no flags Details
Disable DXVA on Vista (1.71 KB, patch)
2013-08-11 22:00 PDT, Chris Pearce (:cpearce)
ajones: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
lukasblakk+bugs: approval‑mozilla‑beta+
lukasblakk+bugs: approval‑mozilla‑release+
Details | Diff | Splinter Review
Proper fix: Ignore MF_E_TRANSFORM_TYPE_NOT_SET error when initializing DXVA (3.44 KB, patch)
2013-08-11 22:59 PDT, Chris Pearce (:cpearce)
padenot: review+
lukasblakk+bugs: approval‑mozilla‑aurora-
Details | Diff | Splinter Review
firefox 23 win764bit dxva2 - dxva checker.png (57.74 KB, image/png)
2013-08-14 22:33 PDT, Elbart
no flags Details

Description banakon 2013-08-06 07:24:26 PDT
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130730113002

Steps to reproduce:

Install FF23

then watch these video in the left side
http://ie.microsoft.com/testdrive/graphics/videoformatsupport/default.html



Actual results:

Green lines on the right of the videos h264.



Expected results:

all the video have to work fine as with FF22!!

the changelog of FF23 tells about accelerated h264 on Vista+....
I guess a bug has been introduced. zwero issue with ff22 on the same machine.
Comment 1 banakon 2013-08-06 08:03:06 PDT
to resolve the bug, install FF22.

please fix this bug related to h264 html5 ;)
thanks.
Comment 2 banakon 2013-08-06 08:19:16 PDT
on ff23 the issue is fixed disabling acceleration hw in ff.
since I have a new gpu and new drivers, I guess that this issue has to be resolved by Mozilla, since
http://www.mozilla.org/en-US/firefox/23.0beta/releasenotes/
Enabled DXVA2 on Windows Vista+ to accelerate H.264 video decoding
Comment 3 banakon 2013-08-06 15:37:31 PDT
http://www.mozilla.org/en-US/firefox/23.0/releasenotes/
Enabled DXVA2 on Windows Vista+ to accelerate H.264 video decoding

maybe that this change introduced a bug...do you agree? thanks.
Comment 4 banakon 2013-08-07 06:20:45 PDT
hi, where are you? ;)
Comment 5 Loic 2013-08-07 06:39:15 PDT
WFM with FF23 on Win 7, but it's clearly an issue with FF23 on Vista, as you reported.
Comment 6 banakon 2013-08-07 06:55:19 PDT
Thank you for your reply and for better topic title.
If wanted, I can upload a dxdiag.txt.
Vista32 sp2.
Ok silverlight and flash. 
I guess that the issue is related to h264 accelerated on html5.

I hope that the developers will fix, perhaps in FF23.0.1.
Please let me know if there are good news ;9
regards.
Comment 7 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-08-07 11:00:35 PDT
Please provide a copy of the Graphics section of your about:support page.

It's unlikely that this is a regression since we just implemented support for this. It's more likely that your machine represents an edge case we did not account for.
Comment 8 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-08-07 11:05:08 PDT
Nominating this for tracking while we investigate.
Comment 9 bhavana bajaj [:bajaj] 2013-08-07 12:31:48 PDT
Thanks for getting this on our radar Anthony, I'll start tracking once we have more information about the regression range,affected version etc.
Comment 10 Chris Pearce (:cpearce) 2013-08-07 13:09:01 PDT
(In reply to banakon from comment #6)
> Thank you for your reply and for better topic title.
> If wanted, I can upload a dxdiag.txt.

Please do! Having a dxdiag report would help. Also, what graphics card do you have?
Comment 11 Chris Pearce (:cpearce) 2013-08-07 13:18:22 PDT
Also, you can set the pref "media.windows-media-foundation.use-dxva" to "false" if you load "about:config" in the URL bar to disable DXVA, and that should enable you to work around the problem. Also, if setting this pref to false makes the problem go away, it will definitely prove that DXVA is the problem.
Comment 12 Chris Pearce (:cpearce) 2013-08-07 13:55:15 PDT
And as Anthony asked, a copy of your Graphics section from about:support would be very handy.

We'll need to just blacklist this card on Vista I think, and we need the information asked for in order to identify the card. Thanks!
Comment 13 banakon 2013-08-07 15:37:54 PDT
Created attachment 787167 [details]
DxDiag.txt
Comment 14 banakon 2013-08-07 15:38:17 PDT
Thanks for your reply! much appreciated.
the GPU is not old, I am wondering if my GPU on Vista32 sp2 (PLUS platform upgrade + supplement to the platform upgrade via "Windows Update") were not supported by the changes introduced with FF23 (since the changelog refers to "Vista+" and "dxva2", and my graphic does support dxva5 too). Here the Graphics, thanks for investigating!!
(OK if h264 runs in flashplayer and silverlight (acceleration ON: CPU 3-9% 1080p full screen, therefore I am sure that the acceleration works fine, otherwise I would find more than 3-9% cpu load while watching the videos 1080p full screen mode, in FF)
=====
5-12-2013 NVIDIA GeForce GTX 650
Direct2D attivo true
DirectWrite attivo true (7.0.6002.23097)
Driver scheda grafica  nvd3dum nvwgf2um,nvwgf2um
Finestre con accelerazione GPU  1/1 Direct3D 10
GPU #2 attiva false
ID dispositivo 0x0fc6ID 
produttore 0x10de
RAM scheda grafica 2047
Rendering WebGLGoogle Inc. -- ANGLE (NVIDIA GeForce GTX 650)
Versione driver 9.18.13.2018
AzureCanvasBackend direct2d 
AzureContentBackend direct2d 
AzureFallbackCanvasBackend cairo
====

what is wrong here?

@Chris: thanks you too, here my dxdiag.txt attached ;)
my card vga (via hdmi):
http://www.asus.com/Graphics_Cards/GTX650E2GD5/

If this may help, I add following:
the 2 "html5 h264" videos in my link above look with green lines on the rightside (FF with hw acceleration on).

oh no, please do not blacklist my card!! ;) it were fine if you could take an effort to make my card working with dxva enabled on Vista ;)
Ok, I will read tomorrow your response, after investigating ;)

Chris, I confirm: by setting the key to false, all is ok!!!!
what should I do now, leaving the setting to false until ff24, then re-setting it to true or what now?? thanks for suggestions.
very strange my friend, that FF23 doesnt support dxva2 (my card does support dxva5 too!) in Vista, VLC player does it on the same machine! very strange. perhaps you will find a fix, not a workaround ;) :)

PS: issue: I have to use the space bar on the keyboard to pause /play the videos, full screen and small screen too.
If I press the > Play/Pause botton: nothing happens, the video get forward og ONE FRAME only!! I have to use the keyboard botton and all is ok!!! strange.

Best regards.
Comment 15 Chris Pearce (:cpearce) 2013-08-07 15:52:37 PDT
Thanks for posting that information. A few other people have reported problems with Nvidia GT450. I will try to investigate in the next few weeks, I've got a lot on my plate at the moment.
Comment 16 banakon 2013-08-07 15:59:10 PDT
GTX 650, a card from the end of 2012, not too old ;) 

[[  nvidia and asus via email -but NOT officially on their website due to concurrence/business reasons...told me that this card GTX 650 is capable to support accelerated H26**5** rendering too! while gtx 640 doesnt ]].

Ok Chris, I can wait without problems ;)
thanks a lot!
Comment 17 reginaldp 2013-08-07 19:24:36 PDT
I'm on Vista with a very capable GTX 460 and getting these same crazy artifacts, H.264 worked fine in FF 22 so I've downgraded to it for the time being.

If FF22 wasn't using DXVA2 then what was it using to accelerate video on the GPU?
Comment 18 Chris Pearce (:cpearce) 2013-08-07 19:28:30 PDT
FF22 was using not accelerating H.264 decoding using the GPU, it was doing everything in software on the CPU. Setting the pref media.windows-media-foundation.use-dxva to false makes Firefox go back to using the CPU for decoding.
Comment 19 Elbart 2013-08-08 01:36:52 PDT
I also got the green lines with a 8800GTX on Vista but not Windows 7.
Comment 20 Elbart 2013-08-08 02:57:18 PDT
With the "Trace Log"-feature of the program "DXVA Checker"[1][2] you can see that Firefox isn't using DXVA2 in Vista, even if both media.windows-media-foundation.*-preferences are set to true and HW-acceleration is enabled.
DXVA2 for H264 is working fine on the same machine in Vista in media-players like MPC-HC with LAV Filters, so it's probably no driver- or OS-problem.

[1]: http://bluesky23.yu-nagi.com/en/DXVAChecker.html
[2]: http://forums.mozillazine.org/viewtopic.php?p=13008365#p13008365
Comment 21 Chris Pearce (:cpearce) 2013-08-08 03:25:16 PDT
elbart: If you set the pref "media.windows-media-foundation.use-dxva" to "false" in "about:config" does the problem go away?
Comment 22 Elbart 2013-08-08 04:52:03 PDT
Yes.
Comment 23 banakon 2013-08-08 07:49:59 PDT
(In reply to elbart from comment #20)
> With the "Trace Log"-feature of the program "DXVA Checker"[1][2] you can see
> that Firefox isn't using DXVA2 in Vista, even if both
> media.windows-media-foundation.*-preferences are set to true and
> HW-acceleration is enabled.
> DXVA2 for H264 is working fine on the same machine in Vista in media-players
> like MPC-HC with LAV Filters, so it's probably no driver- or OS-problem.
> 
> [1]: http://bluesky23.yu-nagi.com/en/DXVAChecker.html
> [2]: http://forums.mozillazine.org/viewtopic.php?p=13008365#p13008365


On my Vista I see the DLL "Microsoft DTV-DVD Video Decoder":
Msmpeg2vdec.dll,
Mfh264dec.dll in the folder system32
therefore I should not experience problems with accelerated h264, even vlc and flashplayer are using h264 accelerated, and the gpu does support dxva5, so I hope that these "not old" cards will not be blacklisted by Mozilla.
As said by friend Chris, we wait a few weeks, or until the 17th september with FF24, no problems ;)
Comment 24 Lukas Blakk [:lsblakk] use ?needinfo 2013-08-08 21:28:59 PDT
(In reply to Chris Pearce (:cpearce) from comment #18)
> FF22 was using not accelerating H.264 decoding using the GPU, it was doing
> everything in software on the CPU. Setting the pref
> media.windows-media-foundation.use-dxva to false makes Firefox go back to
> using the CPU for decoding.

That suggests this is a regression in 23 then?  Can we get a regression range? If there's a low-risk backout we can consider taking it as a ride-along to a 23.0.1
Comment 25 Chris Pearce (:cpearce) 2013-08-08 22:18:04 PDT
This is a regression from bug 847267. It affects Vista only, on some graphics cards only.

I have acquired a graphics card on which this bug occurs, and I am currently in the process of installing Vista on an old machine so that I can reproduce this and see if I can fix it.

We could easily disable this feature on Vista only with a simple low risk patch. 

We can then either re-enable this feature on Vista once I have figured out how to fix this issue, or if I can't fix it we can blacklist graphics cards that we know we have issues on, and re-enable it on other Vista machines.
Comment 26 Chris Pearce (:cpearce) 2013-08-11 21:44:40 PDT
OK, I installed Vista on my machine and I discovered that I can reproduce the bug on my nVidia GTS 240 video card. This bug has also been reported on nVidia Cards GTX 460, 8800GTX, and GT450. This makes me think that the bug may be very widespread, affecting a large number, possibly all, nVidia cards on Vista. Possibly it affects vendors of other cards, I just don't know.

I think we should disable DXVA on Vista and ship that in Firefox 23.0.1. We'll fallback to having H.264 decoded in software, just as we did in Firefox 22.

We can then fix this in Nightly and let the proper fix ride the trains, so that we limit the risk of further regressions in our release build.
Comment 27 Chris Pearce (:cpearce) 2013-08-11 22:00:54 PDT
Created attachment 788782 [details] [diff] [review]
Disable DXVA on Vista

Disable DXVA on Vista. We will fallback to using software decoding for H.264, as we did in Firefox 22.
Comment 29 Chris Pearce (:cpearce) 2013-08-11 22:25:23 PDT
*** Bug 884203 has been marked as a duplicate of this bug. ***
Comment 30 Chris Pearce (:cpearce) 2013-08-11 22:33:08 PDT
Comment on attachment 788782 [details] [diff] [review]
Disable DXVA on Vista

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 847267; hardware accelerated H.264 video decoding on Windows using DXVA2.

User impact if declined: Some unknown percentage of Vista users will have the painting of their H.264 videos screwed up. For example see https://bug884203.bugzilla.mozilla.org/attachment.cgi?id=781665
Possibly all Vista users are affected, but it may be limited to all or some subset of nVidia video card owners. 

Testing completed (on m-c, etc.): Just landed this patch to disable hardware acceleration added in bug 847267. We will fallback to our previous software decoding method that we shipped in Firefox 22. I tested this patch on a physical (non-virtual) machine running Vista.

Risk to taking this patch (and alternatives if risky): This patch disables the regressing feature, this is the lowest risk thing that we can do.

String or IDL/UUID changes made by this patch: None.

Because this bug could affect all or at least a large proportion of Vista users, we should take this patch to disable the regressing feature on Aurora, Beta, and Release. I will fix this properly on Nightly and the fix can then ride the trains.
Comment 31 Chris Pearce (:cpearce) 2013-08-11 22:59:15 PDT
Created attachment 788792 [details] [diff] [review]
Proper fix: Ignore MF_E_TRANSFORM_TYPE_NOT_SET error when initializing DXVA

This patch fixes the problem "properly". It seems that on Vista (at least with my nVidia GTS240), we get MF_E_TRANSFORM_TYPE_NOT_SET returned when we try to notify the decoder about the D3DDeviceManager. It seems that this happens because setting the D3D manager enables DXVA, and that affects the input and output types that the decoder can produce. It seems that we can just ignore this error, and the decoder will reconfigure itself to produce frames stored in D3D surfaces with in the correct format using DXVA.

The rendering artifacts we saw were caused by us treating this error as meaning that we can't use DXVA, setting mUseHWAccel=false, but we were not reconfiguring the decoder to output YV12, which is the format that we use when we're using software decoding. So we were still getting NV12, but were interpreting it as YV12, hence the rendering errors. So in this patch I also add code to reconfigure the video decoder if setting up DXVA fails, to ensure that we're outputting video frames in the format that we expect. This means if setup fails for some other reason, we'll fall back to software properly.

I could be wrong about MF_E_TRANSFORM_TYPE_NOT_SET being safe to ignore, which is why I think this fix should ride the trains.
Comment 32 banakon 2013-08-12 02:46:23 PDT
Chris, please dont forget the gtx 650! see above ;) thanks.
Comment 33 Paul Adenot (:padenot) 2013-08-12 10:00:18 PDT
Comment on attachment 788792 [details] [diff] [review]
Proper fix: Ignore MF_E_TRANSFORM_TYPE_NOT_SET error when initializing DXVA

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

::: content/media/wmf/WMFReader.cpp
@@ +588,5 @@
>      if (SUCCEEDED(hr)) {
>        ULONG_PTR manager = ULONG_PTR(mDXVA2Manager->GetDXVADeviceManager());
>        hr = videoDecoder->ProcessMessage(MFT_MESSAGE_SET_D3D_MANAGER,
>                                          manager);
> +      if (hr == MF_E_TRANSFORM_TYPE_NOT_SET) {

I would have assumed that other project experience the same issue and use the same workaround, but apparently not (I checked VLC and a couple other projects using dxva2).

It seems to work without this workaround for Chrome: http://mxr.mozilla.org/chromium/source/src/content/common/gpu/media/dxva_video_decode_accelerator.cc#660, but I'm not sure if they use dxva2 on vista.

VLC does use dxva2 on Vista, from what I've read, but they don't implement this workaround as well.
Comment 34 Lukas Blakk [:lsblakk] use ?needinfo 2013-08-12 10:51:50 PDT
Comment on attachment 788782 [details] [diff] [review]
Disable DXVA on Vista

Let's get this landed on mozilla-release and mozilla-beta (24) for now.  If the 'proper fix' is low enough risk perhaps it can get uplifted to aurora and maybe even up to beta 24 but for now let's get this out of our larger user populations.  Please set the status to 'disabled' for 23/24 once landed.
Comment 35 Ryan VanderMeulen [:RyanVM] 2013-08-12 12:42:55 PDT
https://hg.mozilla.org/mozilla-central/rev/624083d612b1
Comment 36 banakon 2013-08-12 14:55:18 PDT
I dont understand: will ff24 release resolve th issue or there will be a workaround disabling dxva?
ff 26 will be still affected??
Comment 37 Chris Pearce (:cpearce) 2013-08-12 15:20:24 PDT
We will disable hardware accelerated video in Firefox 23 and Firefox 24 on Vista only. Video will continue to playback on Vista in Firefox 23 and 24 using software decoding, just as it did in Firefox 22.

I will attempt to fix this properly in Firefox 25.
Comment 38 banakon 2013-08-12 15:26:19 PDT
Thanks for your explanation!
I wait for the 29th october (FF25).
(Please look at the PS: on comment #14 too).
Comment 39 Chris Pearce (:cpearce) 2013-08-12 15:50:52 PDT
Disabled on Release:
https://hg.mozilla.org/releases/mozilla-release/rev/1b3d8ae5eb2a
Comment 40 Chris Pearce (:cpearce) 2013-08-12 15:57:54 PDT
This was disabled in Nightly (Fx26) when I landed the changeset in comment 28.
Comment 41 Chris Pearce (:cpearce) 2013-08-12 19:00:39 PDT
(In reply to Paul Adenot (:padenot) from comment #33)
> Comment on attachment 788792 [details] [diff] [review]
> Proper fix: Ignore MF_E_TRANSFORM_TYPE_NOT_SET error when initializing DXVA
> 
> Review of attachment 788792 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: content/media/wmf/WMFReader.cpp
> @@ +588,5 @@
> >      if (SUCCEEDED(hr)) {
> >        ULONG_PTR manager = ULONG_PTR(mDXVA2Manager->GetDXVADeviceManager());
> >        hr = videoDecoder->ProcessMessage(MFT_MESSAGE_SET_D3D_MANAGER,
> >                                          manager);
> > +      if (hr == MF_E_TRANSFORM_TYPE_NOT_SET) {
> 
> I would have assumed that other project experience the same issue and use
> the same workaround, but apparently not (I checked VLC and a couple other
> projects using dxva2).

I'm not sure about VLC, but Chromium's code initializes and uses the H.264 decoder directly, so they have finer control over the startup phase and the order which input/output formats are setup during startup. Whereas we're using the IMFSourceReader API, and have much less control over the startup phase. We're actually passing in the D3DDeviceManager *after* the setup has happened, and I'm guessing on Win7 and later the SourceReader automatically reconfigures to reflect that, whereas on Vista it does not.

I imagine VLC might have finer control over the decoder initialization like Chromium does, since VLC is likely to use their own MP4 demuxer (like Chromium does).
Comment 42 Chris Pearce (:cpearce) 2013-08-12 19:38:51 PDT
Disabled DXVA on Vista only on Beta (Fx24):
https://hg.mozilla.org/releases/mozilla-beta/rev/8fabfd404a7d
Comment 43 Chris Pearce (:cpearce) 2013-08-12 19:46:09 PDT
Landed "proper fix" on mozilla-central (Fx26):

https://hg.mozilla.org/integration/mozilla-inbound/rev/2900a5398134
Comment 44 Elbart 2013-08-12 23:31:05 PDT
1.) Does this mean 24ESR will never have DXVA for Vista?
2.) Were there also reports of glitches with AMD- and Intel-GPUs on Vista, or why is this feature being disabled for all GPUs on Vista?
Comment 45 Carsten Book [:Tomcat] 2013-08-13 05:05:24 PDT
https://hg.mozilla.org/mozilla-central/rev/2900a5398134
Comment 46 banakon 2013-08-13 06:13:21 PDT
the real fix comes with FF26 on the 10th december. it should be a very big issue.
Comment 47 Chris Pearce (:cpearce) 2013-08-13 15:05:54 PDT
Comment on attachment 788792 [details] [diff] [review]
Proper fix: Ignore MF_E_TRANSFORM_TYPE_NOT_SET error when initializing DXVA

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 847267; hardware accelerated H.264 video decoding on Windows using DXVA2.

User impact if declined: Some unknown percentage of Vista users will have the painting of their H.264 videos screwed up.

Testing completed (on m-c, etc.): Landed yesterday on m-c. I tested this patch on a physical (non-virtual) machine running Vista with an nVidia card.

Risk to taking this patch (and alternatives if risky): This patch ignore an error returned by the video decoder. It seems to be safe to ignore that error, but there is some risk of it causing regressions.

String or IDL/UUID changes made by this patch: None.
Comment 48 Manuela Muntean [Away] 2013-08-14 06:38:30 PDT
I can't reproduce this issue, using a nVIDIA GeForce GT 610 video card. First I tried with an older version of the video driver (311.06), and then with the latest one (320.49). With neither one of the driver versions was I able to see the problem.

From the 3 videos, only one is available (implemented) on Vista for the moment: WebM (HTML5 video)
Comment 49 Manuela Muntean [Away] 2013-08-14 06:44:51 PDT
(In reply to Manuela Muntean [:Manuela] [QA] from comment #48)
> I can't reproduce this issue, using a nVIDIA GeForce GT 610 video card.
> First I tried with an older version of the video driver (311.06), and then
> with the latest one (320.49). With neither one of the driver versions was I
> able to see the problem.
> 
> From the 3 videos, only one is available (implemented) on Vista for the
> moment: WebM (HTML5 video)

I tested with Firefox 23 release
Comment 50 banakon 2013-08-14 06:47:55 PDT
All the 3 videos are available on Vista.
(try with GTX 650).
Comment 51 Manuela Muntean [Away] 2013-08-14 07:15:15 PDT
(In reply to banakon from comment #50)
> All the 3 videos are available on Vista.
> (try with GTX 650).

I'm sorry, but we only have 610 and 620 video cards.
Comment 53 Chris Pearce (:cpearce) 2013-08-14 15:18:38 PDT
(In reply to Manuela Muntean [:Manuela] [QA] from comment #49)
> (In reply to Manuela Muntean [:Manuela] [QA] from comment #48)
> > I can't reproduce this issue, using a nVIDIA GeForce GT 610 video card.
> > First I tried with an older version of the video driver (311.06), and then
> > with the latest one (320.49). With neither one of the driver versions was I
> > able to see the problem.
> > 
> > From the 3 videos, only one is available (implemented) on Vista for the
> > moment: WebM (HTML5 video)
> 
> I tested with Firefox 23 release


You need to fully patch your Vista via Windows Update to play H.264 video. You need service pack 1, 2, and you also need the "platform update for Windows Vista" installed.
Comment 54 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-08-14 15:40:32 PDT
Samvedana tested this in the QA Lab; we have a Windows Vista PC with an NVidia 8800GTX. She was able to reproduce this issue in Firefox 23.0 but not in Firefox 23.0.1. Based on this I think we can say this is "resolved" in a matter of speaking for Firefox 23.0.1.
Comment 55 Elbart 2013-08-14 22:32:45 PDT
Has the proper fix been landed in Nightly 2013-08-14 or earlier? Because I cannot get any logs from "DXVA Checker" regarding usage of DXVA2 in the same way I get logs on Windows 7 with Firefox 23, see the attachment.
There's also no change of cpu-load, which would indicate that hardware-decoding is being used. And there's no way to tell from within Firefox if hardware-decoding is being used or if the software-decoder is used.
Comment 56 Elbart 2013-08-14 22:33:04 PDT
Created attachment 790633 [details]
firefox 23 win764bit dxva2 - dxva checker.png
Comment 57 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-08-16 10:57:12 PDT
Calling this verified disabled for Fx23 as per comment 54.
Comment 58 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-08-16 10:57:58 PDT
Samvedana, can you please also confirm this issue is no longer reproducible in the latest Firefox 24 Beta builds?
Comment 59 Lukas Blakk [:lsblakk] use ?needinfo 2013-08-19 09:07:41 PDT
Comment on attachment 788782 [details] [diff] [review]
Disable DXVA on Vista

Given the potential for unknown regressions in ignoring the error we should let the 'proper' fix ride the trains for the full length of time to collect feedback so let's disable on Aurora as well.
Comment 60 Lukas Blakk [:lsblakk] use ?needinfo 2013-08-19 09:08:35 PDT
Comment on attachment 788792 [details] [diff] [review]
Proper fix: Ignore MF_E_TRANSFORM_TYPE_NOT_SET error when initializing DXVA

Approved the disabling patch for Aurora, we'll let this ride from Nightly.
Comment 61 Chris Pearce (:cpearce) 2013-08-19 15:26:04 PDT
Disabled on Aurora (Firefox 25):
https://hg.mozilla.org/releases/mozilla-aurora/rev/4167b7fca818
Comment 62 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-08-19 17:26:45 PDT
Samvedana, can you please verify this is no longer reproducible in tomorrow's Firefox 24.0b4 build1 candidate and tomorrow's Firefox 25.0a2 Aurora build?
Comment 63 Chris Pearce (:cpearce) 2013-08-27 16:36:33 PDT
See also 878030 and bug 908386, this issue occurs on Win7 on at least the following GPUs, with the most up-to-date drivers:

Intel(R) G41 Express Chipset
Mobile Intel(r) 965 Express Chipset

I will track fixing this on Win7 in bug 908386; we need to decide what we're going to do about this issue on Win 7 until the fix in Firefox 26 ships on Release.
Comment 64 Elbart 2013-08-28 00:16:46 PDT
Any info regarding comment #56?
I still cannot get any logs as of Nightly 08-27.
Comment 65 Chris Pearce (:cpearce) 2013-08-28 11:42:57 PDT
I imagine DXVA Checker doesn't detect DXVA when it's used the way we're using it?
Comment 66 Elbart 2013-08-29 03:36:40 PDT
Unless Firefox is using DXVA in Vista differently than in Windows 7, "DXVA Checker" detects the usage DXVA just fine in Windows 7 64bit using the latest Nightly (Build ID 20130828030202) and the log looks like the attachment in comment #56.

I assume that the proper fix of comment #31 for Vista is at least not working for my card (8800 GTX), and Firefox is falling back to software-decoding without the user being able to see which decoding-method is being used. DXVA-decoding in Windows 7 on the same machine with the same drivers is working fine.
DXVA-decoding is working fine in my Vista-installation for other programs, for example with current nightlies of the videoplayer MPC-HC ( http://nightly.mpc-hc.org/ ), which also shows up in the "DXVA Checker" trace logs. So there's no fundamental problem with DXVA in Vista at least for my card/driver-combination.

Also, in Windows 7 I can see a difference of the CPU load between hardware (~7%) and software decoding (~11%). I cannot see the same kind of difference with the same Nightly version in Vista, which probably means that Firefox is using software-decoding even if media.windows-media-foundation.use-dxva is set to true.
Comment 67 banakon 2013-10-13 07:20:26 PDT
in ff24 the default value for is media.windows-media-foundation.use-dxva is TRUE!
Comment 68 banakon 2013-11-02 07:36:16 PDT
can vista users enable the accelerated rendering h264 starting from ff26 release?
Comment 69 banakon 2013-11-02 07:37:06 PDT
my question because I dont see this bug in the ff26beta release notes.
Comment 70 Marcin Starzyk 2013-11-02 08:31:21 PDT
I think FF doesn't use DxVA on Vista and it's impossible to enable it.
Comment 71 Elbart 2013-11-02 08:50:14 PDT
The restriction regarding Vista should have been lifted in 26, see comment #43.
But then it's impossible to tell if Firefox is using DXVA or not without using third-party tools.
Comment 72 banakon 2013-11-02 09:50:02 PDT
I dont understand.
if FF is not using and will not use dxva this bug is unuseful, but above is written "fixed in FF26" and I want to tell what this means: dxva on or off in ff26?

elbart: if you set the key "dxva enabled", it should use dxva, and if this bug will be fixed in december, with dxva true we will watch the videos without green screen.
Comment 73 Chris Pearce (:cpearce) 2013-11-02 13:19:26 PDT
"Fixed" refers to the bug as reported; it means that there are no rendering glitches on Vista. This was achieved by disabling DXVA on Vista. DXVA was subsequently re-enabled with a fallback to software decoding if DXVA initialization failed.

So Firefox 26 will try to use DXVA on Vista using the same mechanism that works in other Windows versions, and if that fails, it falls back to software.

I was looking at the VLC and MPC code the other day, and I found that they weren't using DXVA the same way we are. They're using the DXVA video decoder service interface, whereas we're using the IMFSourceReader interface. Maybe it's this difference that is causing DXVA to not work in Firefox but work in other media players on Vista.
Comment 74 banakon 2013-11-02 16:58:15 PDT
Thanks Chris. 
Flash player and silverlight are using accelerated h264 too
we can monitor if ff26 on vista will use dxva by watching the task manager:
i.e. if 1080p video = 3% CPU load, then we can say that dxva is working properly. If we will see 30% we know that dxva is not active.
Comment 75 banakon 2013-11-02 17:01:40 PDT
please tell me/us the nvidia driver version you are using, 
the drivers that on your vista are able to guarantee no rendering glitches with dxva *enabled*. this is important. the integration between nvidia and firefox!
Comment 76 banakon 2013-11-02 17:03:07 PDT
default:
media.windows-media-foundation.use-dxva;true

FF25.
Comment 77 banakon 2013-11-02 17:06:03 PDT
"So Firefox 26 will try to use DXVA on Vista using the same mechanism that works in other Windows versions, and if that fails, it falls back to software."

why it may fail the initialization?
it is very important to suggest the correct nvidia driver build, the build that works on your test machine, should become our build.
Comment 78 banakon 2013-11-09 06:09:42 PST
@the dev which handles this bug for vista:

what graphic card are you using for testing?
I have the gtx 650 with driver 320.18
Comment 79 Chris Pearce (:cpearce) 2013-11-09 11:18:44 PST
GTS 240. Do you still see the glitches on your machine?
Comment 80 banakon 2013-11-09 16:18:55 PST
Ok gts 240 is old, so I guess that there will be no issue with newer cards like gtx.
I wait ff26 for testing, because I would like to see if the h264 html5 video will work well with acceleration enabled.
Comment 81 banakon 2013-12-10 06:57:04 PST
Hi Chris,

FF26. Gtx650
accekleration active. dxva true.
rendering glitches on Vista resolved.
I guess (not sure, but I guess) that the GPU acceleration is enabled, because the first video High profile (first post) requires 5-9-13% CPU load.
Comment 82 Jean-Yves Avenard [:jya] 2015-09-18 07:33:50 PDT
shouldn't we close that bug? last update was almost 2 years ago
Comment 83 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2015-09-18 10:35:29 PDT
(In reply to Jean-Yves Avenard [:jya] from comment #82)
> shouldn't we close that bug? last update was almost 2 years ago

I'll put that to :cpearce since he added the [leave open] tag to this bug. In general if there's more work to do in this bug it should remain open, otherwise it should be closed.
Comment 84 Chris Pearce (:cpearce) 2015-09-20 16:03:47 PDT
I think we can close this now.

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