Apparent Windows 10 runtime permissions or locating codec issue

Windows 10 Pro x64 current patched Oct 2017, version 10.0.15063.
K-Lite 13.5.5 Mega base + 13.5.6 update + 13.5.8 update

K-Lite installed using a Windows Administrator privilege account reserved for admin tasks. The expectation is that the codecs will be available to both privileged and non-privileged Windows accounts on the installation computer. If there is an installation option selection which would affect access permissions I have missed it to date.

Application in use is LibreOffice 5.4.1.2 x64 (Impress presentation component) where Impress "slide" pages are used for holding mp4 (typically) video clips and associated notes. A non-privileged Windows account is used for production creation and editing of the LO documents.

Symptoms: Opening the *same* LO file:
A) The Windows Administrator account experiences the expected behaviors: the slide page inserted media object shows a video freeze-frame, then video play works with LO player functions when the media object is selected. Tested both from a direct login to the Admin account and as privilege escalation from a non-privileged account.

B) The non-privileged Windows production account is presented with a lineart spearker-with-sound icon on a black field in the slide page inserted media object. Don't know if the lineart icon is originating from LO or from the underlying codec. LO video player functions deliver only audio.

K-Lite uninstalled then re-installed with re-boots in between several times to no effect.

The symptoms suggest the K-Lite installer is not setting component file (presumably .dll files and/or registry entries) permissions to allow non-privileged execution access or the files are being installed in a location not accessible to non-privileged users. The included Codec Tweak Tool and MPC-HC install and can be launched for non-privileged execution.

The installed codecs should work just fine in non-privileged accounts. Test playback with the GraphStudioNext tool that is included with the pack.

Removed & re-installed with additional ffdshow elements enabled including raw video/audio (against installer recommendations) and x86 as well as x64 components. LibreOffice presentation embedded video now works for non-privileged Windows accounts and displays freeze-frame for previews. Also, tested on NVIDIA-driven display vs. Intel CPU graphics driven display on same computer. Behavior inconsistent from trial to trial but NVIDIA in the mix usually inhibits LO embedded video but not audio. The inconsistent behavior seems related to which display (Intel graphics or NVIDIA-driven) the LO doc windows *first opens* then if the windows is moved to a differently-driven display. This of course can confuse the issues if you are not alert as to how each display is configured for PhysX.

So, a thicket of cautions and gotchas when using K-Lite with LibreOffice document embedded video.

Tested .mp4 file with GraphStudioNext (x64). Video/audio worked as expected and is insensitive to use on NVIDIA-driven display. Same for MPC-HC.

GraphStudioNext behaves as a standard DirectShow application, so if things work with that it means the codecs are working properly. If LibreOffice is 32-bit, then test with the x86 version as well.

One thing you should test is disabling hardware acceleration in the video decoder settings. Maybe LibreOffice doesn't like that. That is also the only thing directly related to the GPU at the codec side.

There was another user with LibreOffice some time ago that also has problems. In his case some files worked and some did not. So test multiple files. MediaInfo can show you details about each file.

In Codec Tweak Tool, only LAV appears to have HW accel settings. No obvious HW settings found in ffdshow components unless Intel QuickSync counts. LAV HW accel On or Off did not make a diff. In HW accel drop-down choices, MPEG-4 checkbox grayed out and not checked which suggests HW accel not supported/implemented for MP4 with LAV.

LO has a Media Player applet with a separate floating windows that behaves somewhat better in displaying video stream but still has blank video frame issues.

Then discovered by chance something truly bizarre: While LO windows on NVIDIA-driven display, wiggle the LO window by its title bar and video stream frame works. Other observations suggest the issue is that LO uses the initial vid frame as a static freeze-frame embedded object visual placeholder. When video play is started, the static placeholder does not go away - effectively the video stream frame plays *behind* the placeholder. Wiggling the LO windows forces a re-draw of LO UI static elements which in turn does away with the static placeholder. Does not eliminate the NVIDIA driver as an issue since LO now gives expected video stream play behavior when the LO window is on the CPU driven display.

That checkbox is for MPEG-4 video (which you might know as DivX or Xvid). MP4 is a container format, so something totally different.

Your discovery suggests the problem isn't the actual playback (and thus not codecs) but the way LO renders its user interface. A new version of LO is available. If that doesn't fix it, you will have to submit a bug report to them.

Yes, have already started planning how to show the LO and/or NVIDIA bug by creating a video using OBS. Still could be an NVIDIA driver or settings issue since LO now works as expected on an integrated graphics (CPU-driven) display. In fact, I can start an LO-embedded video on one display then drag the LO window to/from the other and see the behavior change consistently while the video plays. Filling an issue with video demo with both LO and NVIDIA.

Video codec snake begins to eat its tail.

With NvidiaProfileInspector application it is possible to adjust the GPU settings per application. You can use that to force use of the Intel GPU for the LibreOffice applications.

Found this:
https://bugs.documentfoundation.org/show_bug.cgi?id=107764
Different bug, but possibly related.

Previously tried forcing LO to use Intel integrated graphics (not use NVDIA) via NVIDIA control panel. No joy.

Looked at the LO bug cited. Unchecked LO Tools->Options->LibreOffice->View->OpenGL for all rendering.

BINGO! Expected embedded video play behavior on both NVIDIA and CPU driven displays. So LO use of OpenGL on NVIDIA is the issue. Could still be any one of the three in the stack or even several but disabling OpenGL disrupts the condition. Good enough workaround.

LO Tools->Options->LibreOffice->View->Graphics Output now set with HW accel ON and anit-aliasing ON and OpenGL OFF.
No entry for LO binaries in NVIDIA control panel, so global default behavior when LO on an NVIDIA-driven display.

Here you can get NvidiaProfileInspector:
https://ci.appveyor.com/project/Orbmu2k/nvidiaprofileinspector/build/artifacts

It allows you to create a new profile for LO. It also allows to adjust things that aren't modifiable in the NVIDIA control panel. The value that you need to change is "Enable application for Optimus". Value 0x00000000 equals the integrated graphics.

Good to know that disabling OpenGL works.

Filed LO bug 112958. My first preference is to push LO, OpenGL and NVIDIA to fix their stack so LO can use NVIDIA-driven displays rather than deep diddle NVIDIA so LO does not use NVIDIA.

Also, scary about build chains getting targeted to insert malware prior to code signing step. I dumb luck missed by a few days getting tagged by the CCleaner infected build.