Closed
Bug 901944
Opened 11 years ago
Closed 9 years ago
Rendering glitches on H.264 video only in FF23 on Vista
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: banakon, Assigned: cpearce)
References
Details
(Keywords: regression, Whiteboard: [leave open])
Attachments
(4 files)
52.74 KB,
text/plain
|
Details | |
1.71 KB,
patch
|
ajones
:
review+
lsblakk
:
approval-mozilla-aurora+
lsblakk
:
approval-mozilla-beta+
lsblakk
:
approval-mozilla-release+
|
Details | Diff | Splinter Review |
3.44 KB,
patch
|
padenot
:
review+
lsblakk
:
approval-mozilla-aurora-
|
Details | Diff | Splinter Review |
57.74 KB,
image/png
|
Details |
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.
to resolve the bug, install FF22. please fix this bug related to h264 html5 ;) thanks.
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
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.
WFM with FF23 on Win 7, but it's clearly an issue with FF23 on Vista, as you reported.
Component: Untriaged → Video/Audio
Keywords: regressionwindow-wanted
Product: Firefox → Core
Summary: Bug H264 only in FF23 → Rendering glitches on H.264 video only in FF23 on Vista
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.
Severity: normal → major
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.
Severity: major → normal
Keywords: regressionwindow-wanted
Nominating this for tracking while we investigate.
status-firefox23:
--- → ?
tracking-firefox23:
--- → ?
Comment 9•11 years ago
|
||
Thanks for getting this on our radar Anthony, I'll start tracking once we have more information about the regression range,affected version etc.
status-firefox24:
--- → ?
Assignee | ||
Comment 10•11 years ago
|
||
(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?
Assignee | ||
Comment 11•11 years ago
|
||
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.
Assignee | ||
Comment 12•11 years ago
|
||
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!
Reporter | ||
Comment 13•11 years ago
|
||
Reporter | ||
Comment 14•11 years ago
|
||
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.
Assignee | ||
Comment 15•11 years ago
|
||
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.
Reporter | ||
Comment 16•11 years ago
|
||
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•11 years ago
|
||
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?
Assignee | ||
Comment 18•11 years ago
|
||
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•11 years ago
|
||
I also got the green lines with a 8800GTX on Vista but not Windows 7.
Comment 20•11 years ago
|
||
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
Assignee | ||
Comment 21•11 years ago
|
||
elbart: If you set the pref "media.windows-media-foundation.use-dxva" to "false" in "about:config" does the problem go away?
Comment 22•11 years ago
|
||
Yes.
Reporter | ||
Comment 23•11 years ago
|
||
(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•11 years ago
|
||
(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
Keywords: regression,
regressionwindow-wanted
Assignee | ||
Comment 25•11 years ago
|
||
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.
Assignee | ||
Comment 26•11 years ago
|
||
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.
Assignee | ||
Comment 27•11 years ago
|
||
Disable DXVA on Vista. We will fallback to using software decoding for H.264, as we did in Firefox 22.
Assignee: nobody → cpearce
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #788782 -
Flags: review?(ajones)
Updated•11 years ago
|
Attachment #788782 -
Flags: review?(ajones) → review+
Assignee | ||
Comment 28•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/624083d612b1
Whiteboard: [leave open]
Assignee | ||
Comment 30•11 years ago
|
||
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.
Attachment #788782 -
Flags: approval-mozilla-release?
Attachment #788782 -
Flags: approval-mozilla-beta?
Attachment #788782 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 31•11 years ago
|
||
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.
Attachment #788792 -
Flags: review?(paul)
Reporter | ||
Comment 32•11 years ago
|
||
Chris, please dont forget the gtx 650! see above ;) thanks.
Blocks: 847267
Keywords: regressionwindow-wanted
Comment 33•11 years ago
|
||
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.
Attachment #788792 -
Flags: review?(paul) → review+
Updated•11 years ago
|
Updated•11 years ago
|
status-firefox25:
--- → affected
status-firefox26:
--- → affected
tracking-firefox24:
--- → +
tracking-firefox25:
--- → +
tracking-firefox26:
--- → +
Comment 34•11 years ago
|
||
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.
Attachment #788782 -
Flags: approval-mozilla-release?
Attachment #788782 -
Flags: approval-mozilla-release+
Attachment #788782 -
Flags: approval-mozilla-beta?
Attachment #788782 -
Flags: approval-mozilla-beta+
Reporter | ||
Comment 36•11 years ago
|
||
I dont understand: will ff24 release resolve th issue or there will be a workaround disabling dxva? ff 26 will be still affected??
Assignee | ||
Comment 37•11 years ago
|
||
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.
Reporter | ||
Comment 38•11 years ago
|
||
Thanks for your explanation! I wait for the 29th october (FF25). (Please look at the PS: on comment #14 too).
Assignee | ||
Comment 39•11 years ago
|
||
Disabled on Release: https://hg.mozilla.org/releases/mozilla-release/rev/1b3d8ae5eb2a
Assignee | ||
Comment 40•11 years ago
|
||
This was disabled in Nightly (Fx26) when I landed the changeset in comment 28.
Assignee | ||
Comment 41•11 years ago
|
||
(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).
Assignee | ||
Comment 42•11 years ago
|
||
Disabled DXVA on Vista only on Beta (Fx24): https://hg.mozilla.org/releases/mozilla-beta/rev/8fabfd404a7d
Assignee | ||
Comment 43•11 years ago
|
||
Landed "proper fix" on mozilla-central (Fx26): https://hg.mozilla.org/integration/mozilla-inbound/rev/2900a5398134
Comment 44•11 years ago
|
||
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?
Reporter | ||
Comment 46•11 years ago
|
||
the real fix comes with FF26 on the 10th december. it should be a very big issue.
Assignee | ||
Comment 47•11 years ago
|
||
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.
Attachment #788792 -
Flags: approval-mozilla-aurora?
Comment 48•11 years ago
|
||
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•11 years ago
|
||
(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
Reporter | ||
Comment 50•11 years ago
|
||
All the 3 videos are available on Vista. (try with GTX 650).
Comment 51•11 years ago
|
||
(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.
Assignee | ||
Comment 53•11 years ago
|
||
(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•11 years ago
|
||
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.
QA Contact: samvedana.gohil
Comment 55•11 years ago
|
||
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•11 years ago
|
||
Comment 57•11 years ago
|
||
Calling this verified disabled for Fx23 as per comment 54.
Comment 58•11 years ago
|
||
Samvedana, can you please also confirm this issue is no longer reproducible in the latest Firefox 24 Beta builds?
Comment 59•11 years ago
|
||
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.
Attachment #788782 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 60•11 years ago
|
||
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.
Attachment #788792 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
Assignee | ||
Comment 61•11 years ago
|
||
Disabled on Aurora (Firefox 25): https://hg.mozilla.org/releases/mozilla-aurora/rev/4167b7fca818
Comment 62•11 years ago
|
||
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?
Assignee | ||
Comment 63•11 years ago
|
||
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•11 years ago
|
||
Any info regarding comment #56? I still cannot get any logs as of Nightly 08-27.
Assignee | ||
Comment 65•11 years ago
|
||
I imagine DXVA Checker doesn't detect DXVA when it's used the way we're using it?
Comment 66•11 years ago
|
||
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.
Reporter | ||
Comment 67•11 years ago
|
||
in ff24 the default value for is media.windows-media-foundation.use-dxva is TRUE!
Reporter | ||
Comment 68•11 years ago
|
||
can vista users enable the accelerated rendering h264 starting from ff26 release?
Reporter | ||
Comment 69•11 years ago
|
||
my question because I dont see this bug in the ff26beta release notes.
Comment 70•11 years ago
|
||
I think FF doesn't use DxVA on Vista and it's impossible to enable it.
Comment 71•11 years ago
|
||
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.
Reporter | ||
Comment 72•11 years ago
|
||
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.
Assignee | ||
Comment 73•11 years ago
|
||
"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.
Reporter | ||
Comment 74•11 years ago
|
||
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.
Reporter | ||
Comment 75•11 years ago
|
||
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!
Reporter | ||
Comment 76•11 years ago
|
||
default: media.windows-media-foundation.use-dxva;true FF25.
Reporter | ||
Comment 77•11 years ago
|
||
"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.
Reporter | ||
Comment 78•11 years ago
|
||
@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
Assignee | ||
Comment 79•11 years ago
|
||
GTS 240. Do you still see the glitches on your machine?
Reporter | ||
Comment 80•11 years ago
|
||
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.
Reporter | ||
Comment 81•10 years ago
|
||
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.
Updated•9 years ago
|
Component: Audio/Video → Audio/Video: Playback
Comment 82•9 years ago
|
||
shouldn't we close that bug? last update was almost 2 years ago
Comment 83•9 years ago
|
||
(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.
Flags: needinfo?(cpearce)
Assignee | ||
Comment 84•9 years ago
|
||
I think we can close this now.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(cpearce)
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•