test5362

You guys are seriously thinking that Nvidia telemetry causes washed out video in Firefox? Because I don't think these issues are related at all and Nvidia telemetry discussion would be really better off in a seperate thread. But fine, I'll bite, I haven't actually seen the telemetry container process or any services in years, and certainly don't have any recovery.bat in my Windows folder. I think all of that is outdated information for current drivers and if telemetry is in there it's not visible by these factors anymore.

I finally got around to check the browser flags in a comparison with the laptop, and deleted a whole bunch of those that didn't exist on the laptop and looked like they could be related to the issue, but unfortunately no success. I simply can't get hardware accelerated video to not look washed out in Firefox, using the GTX 1060. It could still be some very obscurely named flag that I missed, but at this point I rather think that video acceleration might have not been tested with this newer card under Win7, or that it's a driver issue (I have a problem with blank selection menus in the multi-monitor driver tab that I could never fix with driver updates so far). Comparing about:support doesn't yield anything interesting either, only thing that stands out to me is that the pixel ratio on the 1060 is listed as 1,1,1,1 while on the laptop it says 1, which I don't really understand. The only other thing is that a couple of the browser flags were shader related or device ID related and showed newer versions on the 1060 setup, but I didn't really feel like changing those to what is shown on the laptop, the hardware is different after all. At this point I'm probably done with this unless someone else with a Pascal card and Win7 is willing to test this issue. Here is the list of flags that I changed: sanity-test.advanced-layers false -> true All deleted: layers.m true layers.mlgpu.sanity-test-failed false gfx.crash-guard.d3d11layers.appVersion 55.0 gfx.crash-guard.d3d11layers.deviceID 0x1c03 gfx.crash-guard.d3d11layers.driverVersion 22.21.13.8233 gfx.crash-guard.d3d11layers.feature-d2d true gfx.crash-guard.d3d11layers.feature-d3d11 true gfx.crash-guard.glcontext.appVersion 45.0.2 gfx.crash-guard.glcontext.deviceID 0x11c0 gfx.crash-guard.glcontext.driverVersion 10.18.13.6472 gfx.crash-guard.glcontext.gfx.driver-init.direct3d11-angle true gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle true gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle-force-d3d11 false gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle-force-warp false gfx.crash-guard.glcontext.gfx.driver-init.webgl-angle-try-d3d11 true gfx.crash-guard.status.d3d11layers 2 gfx.crash-guard.status.d3d9video 2 gfx.crash-guard.status.glcontext 2 gfx.webrender.force-disabled false

Yes, I'm indeed using Webrender, I may have possibly set it at one point because scrolling exhibited tearing otherwise. At least that was the case in the old days where it was just hardware acceleration on/off the in the regular options. But it's been so long that I don't know for sure. I'm aware that the browser disables certain functions on Win7, specifically WEBRENDER_DCOMP_PRESENT/WEBRENDER_COMPOSITOR (FEATURE_FAILURE_DCOMP_NOT_WIN10). Also ACCELERATED_CANVAS2D shows as "Disabled by default" due to "FEATURE_FAILURE_DISABLED", not sure if that stems from the aforementioned one. And WebGPU is also blocked ("WebGPU cannot be enabled in release or beta", WEBGPU_DISABLE_RELEASE_OR_BETA). In any case, of the flags you mentioned only gfx.webrender.compositor was actually true, but it's blocked anyway as I just said. I did try to set it to false anyway which expectedly changed nothing for the video issue. The flag that enables Webrender in my case is probably one of these: gfx.webrender.software.d3d11=true gfx.webrender.enabled-no-gpu-process-with-angle-win=true

I'm using full range RGB only and still have the problem. The only fix for me is media.hardware-video-decoding.enabled=false (the layers one does nothing), but this is undesirable on some systems due to the extra CPU load, so I'm still looking for a solution. To be honest I was expecting this to be a more common issue than it seems to be, so I'm probably going to have to go through checking a lot of flags to see which one causes the washed out video playback. To clarify again, these two images showcase the difference between media.hardware-video-decoding.enabled on true/false for me:

I've seen system sounds not work altogether on Win7 too, as in the files being present in the folder and everything listed in the respective tab, system sounds not muted, but nothing will play.

Well, had a gfx driver crash after sleep mode on that laptop, nothing strange as sleep/hibernate would always cause issues like that for me, but since then video acceleration in Firefox has been broken just like on the 1060. Unfortunately system restore was off and I didn't think to make screenshots of the changed flags in about:support, so that doesn't help, but I think that does point to some blacklisting flag that is applied upon crashing and disables something. If there was a way to see what about:config flags are the newest... I never tried Chrome, but used Chrome-based Opera for quite a while and do not recommend it under Win7, I wrote a bit about that in this thread as well. Have had a curious bug with that actually - using a DVI monitor and TV over HDMI in clone mode with same resolution/hz (seems to be more performant than the normal mode, it tended to give microstutter in games when a browser window or video was on the other screen) almost everything under the "Change resolution" Nvidia CP tab is blanked out for me, and the color range selection is missing altogether. I know it's running in full range, so everything techncially works, but I always wondered if others experienced this as well. Edit: video works correctly again on the laptop, not sure what caused the change. I did delete two flags, namely layers.mlgpu.sanity-test-failed=false and gfx.blacklist.video-overlay.failureid=FEATURE_FAILURE_DL_BLOCKLIST_NO_ID, but they do not seem to actually effect anything.

That may be true as graphics cards always had some output differences between vendors, but that's a seperate matter as this is not about overall output but specifically Firefox video differences with media.hardware-video-decoding.enabled toggled on or off. To reiterate, videos look fine with this set to false (software decoding) but washed out set to true (hardware decoding).

The washed out video issue in Firefox is still present as of 115.4.0esr. It's a problem for other users under presumably newer operating systems too, as indicated by this fairly new thread: https://support.mozilla.org/en-US/questions/1421330 (though judging by severity this example may possibly be due to another issue with HDR output, which is unrelated here) And two older bugzilla threads that also seem to pertain to the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1727490 https://bugzilla.mozilla.org/show_bug.cgi?id=1726186 The mentioned disabling of VAAPI hardware acceleration via media.ffmpeg.vaapi.enabled=false really seems to amount to the same as the previously mentioned media.hardware-video-decoding.enabled=false workaround, so probably nothing new there. However, I have managed to test this on an older laptop with GT 540M GPU, also Windows 7 x64 with the latest driver from 2018, and actually found that Youtube videos display correctly even with hardware decoding enabled! Using h264ify and verified by looking at video engine load of course, and the GT 540M's decoder is really only good for one 1080p60 h.264 stream at once as one might expect, but still a welcome surprise. Comparing about:support between the two systems (the PC with washed out Youtube has a GTX 1060), the main points all appear identical, except for differences in gfx.crash-guard flags and such. Right now, I can't say if this difference is caused by video acceleration in Firefox being broken on newer GPUs, some old about:config flag tripping Firefox up (these seem to accumulate over time, but seem to be phased out and be ignored in later versions, or so my understanding anyway), or even some other factor, but it would be helpful if someone with a 10-series Nvidia GPU could check if Firefox has the washed out video issue.

Sorry for double posting, but it looks like Firefox 115 is going to be the last version to officially support Win7, after which there will be ESR support until September 2024: https://support.mozilla.org/en-US/kb/firefox-users-windows-7-8-and-81-moving-extended-support However, it's stated that ESR support will only include security fixes, while 115 is scheduled to release on July 4, so this might be the last chance to get a fix for the aforementioned color range issue with HW decoding. Again, calling for people especially with AMD or Intel graphics to verify the issue. To be clear, software decoding e.g. h264 up to 1080p60 won't really be an issue on most quad cores out there, but I reckon 4k60 or even 4k30 will be an issue for a lot of hardware still running Win7, not to mention it's less power efficient than hardware decoding.

These Microsoft antivirus updates always occur at an inopportune time for me, so I'm trying to set them to run at a different time, but can't seem to find anything related in Task Scheduler. Does anyone know where this setting is hidden?

Firefox is a RAM hog as always of course but works pretty well for me now that I figured out the issue with washed out video, so it will be a shame to see Win7 support cease. I don't have any experience with Chrome/Chromium or such but AFAIK Opera is based on that and definitely feels a lot more broken on Win7 already, plus I believe uBlock Origin is said to work best on Firefox as well. I used PM around the time Mozilla did one of their stupid UI redesigns but ditched it again after realizing how much slower and less multithreaded it was, and recall it also randomly deleting my sessions upon updating. This was years ago so I have no idea what the current status on it is, but I remember them ditching XP support in their mainline build and only supporting it in a legacy build, but right now I only see 32-bit and 64-bit Windows builds on their page with no apparent information as to what versions are supported.

I don't expect Windows 7 support for much longer than a year from now anyway, but more testing might leave us with a slightly better final version indeed. And yes, it's a nice surprise that the hotfix is out already.

In Firefox 113, any kind of fullscreen video is broken under Win7/8, see here: https://bugzilla.mozilla.org/show_bug.cgi?id=1832547 https://bugzilla.mozilla.org/show_bug.cgi?id=1830721 Apparently this bug was known for 10 days in Nightly but went through for release, because they don't even test stuff under Win7 anymore, and the fix is only scheduled for May 23rd right now. Oh well, maybe this topic can save others the hassle.

Nope, nothing in there and nothing in about:support (which actually has a codec list) and plugins either.

Thanks for the suggestion about those codecs. I got all of the mentioned tools and to be honest wasn't sure what exactly to do with most of them, but autoruns did show me two Techsmith codecs, which were vidc.tsc2 and vidc.tscc, with a reference to the SysWOW64 folder. I got rid of them alongside all the corresponding registry entries I could find. In total, the deleted files were: tsccvid64.dll, tsccvid.dll, tsc2_codec64.dll and tsc2_codec32.dll. After a reboot, I could not see any Techsmith in Resource Monitor, but as soon as I start Firefox, unfortunately that activation.cloud.techsmith.com connection is back.

Thanks for the replies, I couldn't find anything in Task Scheduler either, and I rechecked the services and just can't see anything strange there, it's pretty much all standard Windows services. I did turn off SSDPSRV as I have no need for UPnP, I'm not sure why it was running anyway as revertservice claims the default setting for it is "manual". That did kill the UDP connection from that but it's still trying to connect via Firefox, and in fact it seems to try to connect right after boot, even before Firefox is launched. I'm using tcpview and procexp so some of these tools are probably redundant (and CurrProcess only sees 32-bit processes btw) but I went through SpyDllRemover, MBAM and AdwCleaner so far and they found nothing relevant. I went ahead and changed the 127.0.0.1 IP in the hosts file for activation.cloud.techsmith.com to some random private range IP, then instead of connections to activation.cloud.techsmith.com tcpview would show 65.52.240.48. That was actually in the hosts file too but I looked that IP up online and got this: https://superuser.com/questions/729277/why-am-i-connected-to-65-52-240-48 and also this: https://support.mozilla.org/bm/questions/1302652 So basically confirming the issue but no solution offered. Procexp shows me the Firefox process that's doing this TCP connection but there seems to be no way to see what triggers this.

I'm seeing connection attempts via SSDPSRV and Firefox to activation.cloud.techsmith.com, related to Techsmith Camtasia which I have uninstalled a long time ago. It's also blocked via hosts file, but I would still like to get rid of this. I've already tried looking through all processes, services and deleting anything related in the registry, as well as running several different AV scans, but to no avail.

Maybe you can test HW acceleration on/off in Firefox to confirm that it's broken under Win7? It would be interesting to get some feedback from Intel/AMD GPU users, too. As far as the tint in Opera goes, there are a couple of other variables that I haven't explored, such as the different backends, I was using the OpenGL backend for these tests. In addition there's also a Vulkan option in the flags that was just producing black squares everywhere in the GUI for me. Anyway, the performance issues I mentioned are present under both OpenGL and D3D11, so I would not recommend using that browser at least under Win7.

So I just put media.hardware-video-decoding.enabled to false, restarted the browser and am getting different results now: Also verified there's no video engine load while playing the video so it should be software decoded now. Interesting thing is, while this isn't washed out anymore this is actually still different from what Opera is outputting, the white is brighter and in comparison it now seems that Opera has a red tint to the greys? If you download these images and flip through them you can see what I'm talking about. So, is Firefox rendering it correctly now while Opera was giving me bad video too all along? Also as a side remark, media.hardware-video-decoding.failed was already at false and is listed as a changed setting, for whatever that's worth. PS: it just occurred to me that I had h264ify on for Firefox the entire time while it was off for Opera, so I thought this might be related, because Opera was getting an AV1 video previously. However I just turned it on and it doesn't seem to be the cause, here a quick screenshot from Opera to prove it:

Ok, thanks for testing, so I need to look into why this happens only for me then. Some screenshots: Firefox: Opera: I have also found the topic where a missing function in Win7 is mentioned, which is DX11 DXVA, but the topic is 6 years old already so I don't know if that is relevant anymore. I will try to disable hardware video acceleration to see if that makes a difference.

That bugzilla thread is a couple years old so those Twitch links don't work anymore, but any video on Twitch exhibits the issue for me. If something more akin to a test pattern is needed I found this video, I even went ahead and downloaded both H.264 and VP9 versions of it, playing those with VLC matches what Opera outputs while it is washed out on Firefox. I run a current version of Opera, right now 95.0.4635.80.

Why downgrade from 112 to 102 ESR when it will have the exact same issue with videos?

Hi everyone, I did a quick search and couldn't find any discussion of this, but at least for me with Nvidia under Win7, video playback in Firefox is still broken as of today (version 112, using Webrender). This is an older bug report related to the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1459526 The test videos on that page that still work actually do show correctly now, but still, any actual video on Youtube or Twitch looks obviously washed out, with blacks showing as grey instead. I can't find the source anymore, but I've read a couple of years ago that the fix that they did really just applies to Win10+ because they used a function that is missing in older Windows versions, and I guess the userbase for Win7 is so small now that nobody really seemed to care. Can anybody confirm this issue? As a workaround I've been running Opera additionally, which doesn't have the color range issues (though I did have to switch off HW accelerated video for performance and stability reasons), however the problem here is that whenever I run Opera I get very noticeable stutters in games that aren't traceable to any additional CPU or GPU load. The more demanding the game itself is and the more cores it uses the more frequent and worse the stutters get. Furthermore, while playing a game having any kind of video running in the background is completely impossible on Opera, it becomes a complete stutterfest. I've also noticed some severe Windows GUI performance degradation that sometimes seems to happen when running Opera for long periods of time, so considering all of that my guess is that Opera is really badly coded when it comes to interacting with the GPU driver.