It has been a couple of days since I started to seriously dive into ffmpeg. I have to admit that I caught fire on it meanwhile. My goals now are: On the one hand I want to get the idea of "driving ffmpeg as an external application" working in a robust and versatile way (which seems to require some coding for ffmpeg) and on the other hand I want to build and debug it in a Windows-enviroment. The latter means: I want to be able to debug it with VisualStudio or WinDbg, which requires to have PDB files. I seems that quite a few people have already taken on this challenge, but no one has yet completed this port. My plan for compiling ffmpeg on Windows is to use the Intel C++ compiler (using version 188.8.131.528), since it is capable of producing PDBs, understands C99 and also the AT&T-inline assembly (at least to some degree, more on this latter).
So far I did the following:
- I took the source of ffmpeg, put everything into a VisualStudio-project.
- Made the source compile somehow. Problematic code (which did not compile) I either changed (if it was an easy fix) or commented out.
After a couple of days I arrived at a successful build of ffmpeg. "Successful" means: build went fine, and the executable was able to transcode a video (literally a single video at this point). Now I will be working trough all my changes so far and see if they were reasonable. Might be great if some of those changes could make its way back into the ffmpeg-trunk - but I have not yet reached the point where this makes sense.
So far, I faced two major issues:
- trouble with the C99-standard-library function "lrint"
- trouble with AT&T inline assembly
The first one is by far the easiest one. The story (as far as my understanding goes) is that lrint and its cousins are part of the C99-standard-library and are usually declared in <math.h>. However, with Intel C++ on the Windows platform, the compiler uses the MSVC-header, and there we do not find lrint. The nasty thing about it is, that it compiles and links ok (just warning about an implicit declaration of lrint, which is of course allowed in C), but it does not work. No idea why, but the lrint-function that gets linked just returns garbage. This is also reported here or here. My solution so far was to replace <math.h> by <mathimf.h>. It is important to replace all occurences of <math.h>, since one cannot have both in one compilation unit. Not the best solution I suppose, but it works fine.
The trouble with the AT&T inline assembly is a bigger one. I will come back in a latter post on this, but my goal still is to solve it (instead of just omitting the problematic code).
BTW - so far I am believing that gcc cannot produce PDBs. However - I am not definitely sure about this. If it were possible somehow I would probably go with "compile problematic code with GCC" in order to solve the AT&T inline assembly issue.