Does MikTeXinstall/depend on ffmpeg?

[Ulrich-Diez]

Inspired by #956 I'd like to know whether MiKTeX depends on/installs ffmpeg.

If so: Why?

For the pdf-viewing-module of TeXWorks in case of displaying videos embedded into the .pdf-file?

[Redouane-S]

Just to clarify more, that files doesn't exist in the drive at all, and yet MiKTeX is trying to access it nonetheless.

[edocevoli]

What makes you think that MiKTeX depends on the ffmpeg executable?

[Redouane-S]

Because of what the message says in the error report of #957, apparently it needs to retrieve attributes from some ffmpeg file ...

[edocevoli]

ffmpeg is not a file. It's a directory which apparently is in the PATH.

[Redouane-S]

Yes, you're right, but why is MiKTeX trying to access it?

[edocevoli]

Basic knowledge: all directories in PATH are accessed when searching for executables.

[Redouane-S]

Thank you for your input.

[Ulrich-Diez]

What makes you think that MiKTeX depends on the ffmpeg executable?

I have nowhere expressed that I firmly assume that TeX depends on ffmpeg executables/libraries/whatsoever.
I asked whether it is the case.
That is something different.

Indications that I, as a layman, can't just rule it out without making sure (e.g., by asking):

1. In the scenario encountered MiKTeX tried to access a directory related to ffmpeg.
   There was no message on why and in what context this bizarre attempt was being made in the first place.

2. There is TeXWorks which brings along a pdf-viewer which according to the TeXWorks-homepage is capable of displaying embedded videos.
   Considering all the unexpected bizarre things that one nowadays encounters very often in connection with software running under Windows - why should I, as a layman, rule out from the outset that ffmpeg might also be used internally?

3. There are LaTeX2e-packages like media9 and movie15 for embedding videos into pdf-files where ffmpeg is mentioned in the manual explicitly.
   Even if such an idea, although seeming bizarre, could also be interpreted as an attempt to be courteous and therefore seems rather unlikely: Can I rule out without making sure that someone has come up with the idea of supplying said software right away?

Besides this I think MiKTeX without need attempting to access directories only because they are listed in the environment variable path would not be a good idea.
Just taking the fact that something is listed in the path variable as a reason for attempting to access it would be strange.
Therefore I think error-messages should not only inform that something went wrong but also provide comprehensible info on why/in which context the attempt of doing it was undertaken at all.
This could lead to more cases where users outside development, who do not have every syllable of the MiKTeX-documentation and Windows-behavior so present that they can independently interpret into error messages facts/circumstances not mentioned there, can fully see through issues themselves and help themselves without puzzling around and asking apparently annoying questions. (Btw: What Windows-documentation nowadays describes behavior of Windows comprehensible to laymen? E.g., almost no one in my surroundings who started using computers in the last 15 years even knows about the concept of environment-variables. Or about the concept of the scope of environment-variables when having several instances of a shell/command-prompt. )

From the mentioned .log-file I can see that it is a Windows-API-error. But I can't see what MiKTeX was trying to do when the error was triggered. From mentioning "PATH" it is obvious that there was an attempt of accessing something listed in the path-variable. What attempt? Why accessing all paths listed in the path-variable rather than just searching/accessing the directory where MiKTeX-binaries are installed? The latter question led me to guess that MiKTeX might probably be specifically looking for something that is not part of the scope of things developed for MiKTeX, but a separate third-party component/package, such as ffmpeg.

[Redouane-S]

I couldn't agree more, however in my case I did some digging around and asking my brother on what software is installed in that directory, he said that it was "uninstalled" and I have to emphasise on the fact that the files don't exist that MiKTeX is trying to access which is really weird, and of course we have to assume the other fact that I removed the encryption from the drive and did a clean re-install, I uninstalled MiKTeX completely and deleted every register entry, yet when I lock G: volume which has that ffmpeg directory the error still persists. So presumably the only "real" is to do a clean OS re-install, which in my case is not possible anytime soon, and also if my brother needs to lock G: Volume again I end up not being able to use LaTeX again, so my real question is or was, given an situation what to do to avoid this error prompt ?

[Ulrich-Diez]

> I have to emphasise on the fact that the files don't exist that MiKTeX is trying to access which is really weird,

Being picky I think MiKTeX cannot be blamed for the attempt of accessing directories/files that do not exist:

The directory is listed in the PATH-variable and MiKTeX cannot know whether it exists because in order to find out if the directory exists, the volume needs to be accessed. But the volume cannot be accessed due to bitlocker/encryption/locking-issues. The latter is what the error-message in the .log-file says.

I as a layman cannot rule out that the issue might as well be due to the way in which Windows-API-functions for accessing things are designed by the developers of Windows. The design of such Windows-API-functions is not in the responsibility of the development of MiKTeX.

But choosing what Windows-API-functions to have called by MiKTeX to a certain degree is.

However, in the .log-file/error-messages I miss information on what MiKTeX was trying to do in the context of starting the "cascade" whose carrying-out led to calling the API-function which used the environment-variable PATH for searching things and hereby triggered the error-message.

Based on this information a user could more easily judge for him-/herself whether it is a serious problem, and whom to address if so, or if it is something that can be ignored.

In case the ffmpeg-directory was added to the PATH-variable by the installer-program for ffmpeg, the ffmpeg-uninstaller might be faulty because in this case the ffmpeg-uninstaller should have removed that directory from the PATH-variable.

I think a Windows-API-function which searches all directories of the PATH-variable triggering an error when a volume cannot be accessed due to encryption/bitlocker-issues is correct.

But info on why this function was called/what MiKTeX was about to do when calling that function might be helpful when tracking things down.

> when I lock G: volume which has that ffmpeg directory the error still persists. So presumably the only "real" is to do a clean OS re-install, which in my case is not possible anytime soon, and also if my brother needs to lock G: Volume again I end up not being able to use LaTeX again, so my real question is or was, given an situation what to do to avoid this error prompt ?

There is an entry "G:\USER\program\Instaled\Movies\ffmpeg-20190604-d81913e-win64-static\bin" in the operating-system's/Windows 10's environment-variable whose name is PATH.

It seems this entry was added when installing the program ffmpeg in volume "G:".

Maybe installing the program ffmpeg in volume G: took place a long time ago, before attempting to install MiKTeX and before encrypting volume "G:" with bitlocker.

Now volume "G:" is encrypted by bitlocker.

If the program ffmpeg is not installed in the system any more and the entry in the environment-variable is a remainder due to an improper uninstalling-routine, just manually remove this entry from the environment-variable PATH.

If the program ffmpeg is still installed in the system, in the volume "G:", then it is unusable as long as "G:" is not unlocked and therefore inaccessible. Therefore in this case I suggest uninstalling it, hereby ensuring that the entry is removed from the PATH-variable as well, and installing it in a volume not affected by bitlocker or unlocked in any case when the system is booted up.

Here is a link to a tutorial on manually editing environment-variables like the PATH-variable in Windows 10:

https://superuser.com/questions/949560/how-do-i-set-system-environment-variables-in-windows-10