News:

Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu

Howto - Compiling the VOMP Windows Client

Started by cf, February 19, 2008, 22:31:19

Previous topic - Next topic

cf

Hi,

I've recently made some experience in compiling the VOMP Windows client and would like to share it here. Maybe someone finds it helpful.

Carsten

--------------------------------------------------------------------------


How to compile the VOMP Windows Client
===============================

Howto
Version 0.1    19.02.2008
Version 0.1.1 20.02.2008 Added MartenRs remarks


1 Motivation

The goal of the installation was a development environment for the vomp server and client, especially the windows client, because I wanted to look at the code in a working development environment. Maybe one day I'd even contribute something :-).


2 General thoughts about the development environment

I tried building a pure virtual development environment using vmware server. Forget it. While the build environment for the vomp server and the vdr are very well suited to run in a vmware virtual machine (I'm using a c't vdr 5 as base system, which is essentially a vdr based on Debian Etch), the windows client will never run there because vmware doesn't support DirectX. There is only an emulated SVGA graphics card in the virtual machine, and even with software rendering the DirectX subsystem won't initialize at all. As far as I've read, even the not too cheap vmware workstation only brings basic and unstable support for DirectX.

Nevertheless the building environment (compiler, libraries) can be put in a virtual Windows machine. I gave up on this also because I didn't bother finding out which runtime libraries I'd have to deploy to the machine where I'd be using the windows client.

I thought the windows client would be easier to compile and faster to run for development purposes, but maybe I should try Chris' development environment where the MVP simply loads the VOMP client from an NFS export. Maybe I'll give this a try later.


3 Getting the basics

The easiest way to get all the parts needed to build VOMP is Chris' makedevenv-5-script from the Loggytronic website (http://www.loggytronic.com/vomp-devenv.php). I used it to build a development environment inside a vmware virtual machine running Debian Etch.

As Windows compiler I use Visual C++ Express 2008. Download the ISO-Image from Microsoft, burn it to DVD and there you go.

Additionally you have to install a DirectX SDK. I used the November 2007 SDK which can be downloaded from Microsoft.

The formerly needed streamlib.dll which is mentioned in some loggytronic board posts is no longer needed.


4 Building the jpeg library

To build the client, you'll need the jpeg library which is put in the "jpeg" subdirectory of your development tree by the makedevenv-script.
I built it for Windows by strictly following the instructions in the file "install.doc" in the "jpeg-6b" subdirectory. In short for Visual C++ 2008 (nmake comes with it):
- Copy the jconfig.vc-file to jconfig.h
- run "nmake -f makefile.vc"
and you should be done. This produces a "libjpeg.lib" file which can be statically linked to the Windows VOMP client.

In my installation, the jpeg-library's source resides in "z:\jpeg\jpeg-6b".

5 Check out the client from CVS

If you want bleeding edge, or a specific version, I recommend checking it out from cvs, so that you can use cvs to monitor current changes and merge changes in the cvs in your version, or create your own branch. It pays to read the cvs documentation for some more than the basic commands.

To checkout the source which comes nearest to the 0.2.7 Windows client, change the cvs command from the loggytronic website (http://www.loggytronic.com/vomp.php) to

cvs -z3 -d:pserver:anonymous@vomp.cvs.sourceforge.net:/cvsroot/vomp co -D "2007-11-14" -P client

After this, add the two patched files MartenR provided in the board in

http://www.loggytronic.com/forum/index.php?topic=322.msg1990#msg1990

Unfortunately the cvs does not seem to contain a properly tagged version of the 0.2.7-3 Windows client, so all you will get is the source for a Windows client which is stable in most areas, excluding the mediaplayer. Maybe you can find out which files in which versions to use, else we shall be waiting for the next release and hope that all necessary files find their way to the cvs and get properly tagged.

In my installation, the client's source resides in "z:\vomp-cvs\client".


6 Compile using the provided Makefile.nmake

Add all relevant paths of your installation to the makefile (examples, depends on installation):
- Add the binary path (where eg. nmake and cl are located) of Visual C++ to your PATH environment variable.
- JPEG_LIB=z:\jpeg\jpeg-6b
- DXSDK_DIR=F:\Programme\Microsoft DirectX SDK (November 2007)\
- CXXFLAGS_REL = [...] /I"C:\Programme\Microsoft Visual Studio 9.0\VC\include" [...]
- RCFLAGS = /i"C:\Programme\Microsoft Visual Studio 9.0\VC\include"
- Change the resource compiler's call to "$(RC) $(RCFLAGS) /fo"vompwin.res" "vompwin.rc" to honour the RCFLAGS.

Run using the nmake-command "nmake -f Makefile.nmake" and you should be done. The resulting Windows client should need the VC 9 runtime libraries, so be careful to put them somewhere in the path.


7 Build a Visual C++ project file

A Visual C++ project has the major advantage that you can use the VC++-debugger (with some quirks, see below).

First fire up Visual C++ 2008 Express and create a new project with the following attributes:
- Win32 Project
- Windows Application
- Empty project

Then "Add existing items" to the project: All .cc and .h files and the .rc file of the client.

Now cut it back: For several files, there is an "*mvp"-Version, and a "*win"-Version. For the Windows client, remove all those "*mvp"-files, eg. "videomvp.cc" and "audiomvp.cc" from the project, because they won't compile under Windows, and they're only needed for the native MVP-dongle.
Also remove the main.cc and the threadp.cc files from the project. Hope I didn't forget any.

In the project's properties, set some helpful options. I found them out by try & error, so some of them may be reasonable, some not, but this way it works for me. I'll only mention the options which are different from the default values of any Visual C++ 2008 project. I tried to get as near as possible to the options in the Makefile:

Add additional include directories:
- The path to the jpeg library header file (for me: "z:\jpeg\jpeg-6b").

Add preprocessor definitions:
- WIN32, _DEBUG, _WINDOWS, NDEBUG, NEW_DEMUXER
- Do not inherit the standard UNICODE definitions - IIRC unicode gives trouble compiling.
- To better see the errors maybe you want to switch off warnings (/W0).

Set compiler options:
- Do not use unicode response files
- Don't use precompiled headers
- Debug information format: /ZI
- Disable optimization (/Od)
- Enable minimal rebuild (/Gm)
- Basic Runtime Checks: Default
- Runtime-Library: Multi-threaded Debug DLL (/MDd), and for a Release Multi-threaded DLL (currently don't remember the switch syntax)

Set linker options:
- Enable incremental linking (/INCREMENTAL)
- Add jpeg- and DirectX-Library paths as additional library paths: z:\vomp-cvs\jpeg\jpeg-6b; F:\Programme\Microsoft DirectX SDK (November 2007)\Lib\x86
- Here you should keep the inherited defaults
- Don't use UNICODE response files
- Use Library dependend inputs
- Add additional dependencies: d3dx9.lib WS2_32.lib libjpeg.lib d3d9.lib shlwapi.lib iphlpapi.lib strmiids.lib winmm.lib kernel32.lib user32.lib gdi32.lib ole32.lib oleaut32.lib uuid.lib and don't inherit the standard dependencies
- Ignore the standard library libcmtd.lib. It already comes from somewhere else.

Patch the source code:

- Change i18n.cc, line 74 from
   char *p = strchr(s, '$');
  to
   char *p = (char*) strchr(s, '$');

- Change vchannelselect.cc, line 116 from
     m->parameter += input * (ULONG)pow(10, i);
  to
     m->parameter += input * (ULONG)pow(10.0F, i);


Now you should be ready to run the build process.


8 Runnig & debugging the Windows VOMP client

Concerning the necessary runtime dlls, your are on your own. I simply installed VC++ 2008 and the DirectX SDK to the machine where I wanted to run the Windows client.

To run the client, you need a VMR-9-compatible video renderer. Such a renderer comes eg. with PowerDVD 7 or WinDVD 8.
When you run the Exe in the debugger from the Visual Studio IDE, you will maybe get some strange error messages telling you that "you are running a debugger. Exit program and restart without the debugger active" or something similar. This goes back to some broken intellectual property scheme in some video decoders, especially the Nero 6 Video/DVD decoder and the PowerDVD 6/7 decoders. WinDVD doesn't seem to have this annoying restriction, but I don't get video playback in debug mode either - maybe it simply doesn't complain while not producing any video output. At least you can watch the internals of the client running.

Here two additional tricks from MartenR for debugging and circumventing the annoying anti-debug techniques:
* Place a MessageBox at the beginning of the code you want to debug and place a breakpoint after the MessageBox. Then run the programm (not in debug), when the MessageBox appears attach the debugger to the process and you can debug for a while, until the decoder annoys you again. So you can debug with video playback for some time.
* In videowin is a switch DO_VIDEO, which disables video playback, so that playback can be debugged audio only.

================================================

Please put additions and remarks to this howto in the forum and I'll see if I can release a better one with them included.

Ah, and sorry, I'm not too much used to write in english, but I thought this should be shared.

Regards,
   Carsten

MartenR

#1
Hi,
nice howto! I was actually too lazy to do something similar.
Here some comments:
Quote- Runtime-Library: Multi-threaded Debug (/MDd)
should be:
Runtime-Library: Multi-threaded Debug Dll
and for a Release Build
Runtime-Library: Multi-threaded Dll.

Two trick for debugging and the annoying anti-debug techniques:
* Place a MessageBox at the beginning of the code you want to debug and place a breakpoint after the MessageBox. Then run the programm (not in debug), when the MessageBox appears attach the debugger to the process and you can debug for a while, until the decoder annoys you again. So you can debug with video playback for some time.
* In videowin is a switch DO_VIDEO, which disables video playback, so that playback can be debugged audio only.

Marten

cf

Thanks for your remarks, I updated the Howto accordingly.

Carsten


dingo35

#3
One should also exclude the vremoteconfig.* files, since they call a view.h file which does not seem to be present. Strangely enough linux does not complain about this (is this the proof that Linux is more intelligent than Windows  ;)  )

Also, one should note that a lot of patches out there are _only_ compatible with the building environment of the mvp-box, _not_ necessarily with this windows-environment. This is perhaps also the reason a lot of patches are not included in cvs ?

So when testing your building environment, try the client's cvs version first..

sat-user

Somethings to add to point 7.

Mediafile.cc didn't build on winxp with visual studio 2008.
I'd to change fseeko -> _fseeki64 & ftello -> _ftelli64
Better include somewhere
#ifdef _WIN32
#    ifdef __MINGW32__
#        define fseeko fseeko64
#      define ftello ftello64
#    else
#        define fseeko _fseeki64
#        define ftello _ftelli64
#    endif
#endif

Also had to put mfuuid.lib at "Add additional dependencies"

Exclude libcmt.lib (for normal builds) libcmtd.lib (for debug builds)

Link failed, because with the "import existing items" the subdirectories aren't included, imported font & teletxt

After that it build.

Greetz from Holland.