This page describes the usage of the VQEGPlayer .
As the player can be configured in several different modes, starting with the simplest mode is advantageous.
In order to start the player, run the executable VQEGPlayer.exe. When you start the player, it should open a file dialog in which you can open one of the configuration files provided in version 1. It will then start the playback (in demonstration mode) based on the configuration file chosen, or await the connection from a client via (local or remote) network connection to receive commands (in network server mode).
In order to run the following steps, please download the configuration files and the playlist files available here: here. The configuration files are text files in UTF-16LE, so it important that en editor supporting this is used when they are created and updated. See e.g. Notepad++.
Please also download the video required video sequences (BGR files) from this location.
Simplest mode: 2D Demonstration
In order to activate the 2D Demonstration mode, open the config_demo_mode.txt in the file dialog after starting the player. This mode allows for playing videos from a playlist and may be made to run in a loop as you may want to use on project reviews or trade shows. The configuration settings for this mode is provided in config_demo_mode.txt, the playlist can be found in playlist_demo_mode.txt.
In order to activate the Standalone mode, open the configure_standalone_mode.txt in the file dialog after starting the player. Standalone mode will perform a simple ACR based experiment with a playlist given in the playlist_standalone_mode.txt file. Randomization is currently not supported. Pair Comparison and DSCQS are also implemented but is currently less tested than ACR in standa lone mode. The voting will be performed on a graphical user interface in full screen mode using the mouse. The observer ID is defined in the configuration file and a corresponding file with the extension “.dat” will be created.
3D Demonstration mode
In order to activate the 3D Demonstration mode, open the config_3d_demo_mode.txt in the file dialog after starting the player. This mode works similar to the 2D Demonstration mode. At this moment, the 3D mode only supports playback of BGR files. You can find an appropriate configuration for Full-HD 3D playback in config_3d_demo_mode.txt and the corresponding playlist in playlist_3d_demo_mode.txt
For performing subjective experiments in remote configuration, you usually need 2 distinct PCs.
One PC will act as a “server”, the other will act as a “client”. The server is responsible for playing the videos and will need 3D capabilities. The client will run a Matlab program which will run the test, telling the server which videos to play, and controlling voting for the observer. The client PC will need to have Matlab in 64 bit installed (at this moment, Matlab in 64 bit is required because the imshow3d only has been compiled in mexw64, this is not a hard constraint and it may work also on Linux).
Before running the 3D remote test, the Matlab running program on the client PC needs to be configured with the IP adress of the server PC. Open the file interface_ACR_coding_evaluation.m. Under the “initialize variables” section, near the top of the file, set Server_ip equal to the ip address of the server PC. In the same section port should be set equal to 27105, the default port the software is setup to run on.
On the server PC, before running the 3D remote test, make sure that the VideoQualityPlayer.exe program has permission to send and receive information through the PC’s firewall.
In order to run the 3D remote test, first run the VideoQualityPlayer.exe program on the server PC. Once VideoQualityPlayer.exe starts, it will wait for a connection from a client PC. Next run the interface_ACR_coding_evaluation.m program on the client PC. On the client PC, this program will prompt the user for the ‘observer name’ (name of test participant), then it will attempt to connect to the server PC, once it establishes a connection it will begin to run the test based off of the playlist in playlist_3d_remote_mode.txt.
The playlist file has a specific syntax: the first line contains three numbers separated by a ‘:’ : <nr_of_src>:<nr_of_hrc>:<nr_of_training_seq> The second line contains the filename of the first sequence to be shown in training, the third line contains the filename of the second sequence to be shown in training, and so on. After all training sequences are listed, the next line contains the filename of the first src and first hrc, the next line, the filename of the first src and second hrc, and so on. The Matlab script automatically generates randomized versions for ACR tests, including the constraint that one SRC shall not occur two times in succession and the same HRC shall not occur twice in a row as well. (Please note that therefore the minimum number of SRC and HRC in any ACR test needs to be larger than 1)
On the client side, you configure your interface and the playlist by changing the corresponding interface_ACR_coding_evaluation.m (and eventually the items on the interface using matlab “guide” command). In the (more or less unlikely) event that the player crashes, the data of the observer is not lost and the test can continue after relaunching the player and the matlab script. If no video is shown at the player side, please ensure that you can access the server PC from the client PC, i.e. by performing a ‘ping <server_ip_address>’ in a Windows command window on the client side. Sometimes, the firewall blocks the VideoQualityPlayer.exe and often, especially at the first run, an exception needs to be configured to allow remote computers to connect to the VideoQualityPlayer.exe via the network.
Is my computer/storage fast enough?
Please check the “FlipDiagnostic” files, they contain information about skipped frames, i.e.
Lost flips 1 , at frame number : 0
Lost frames 243-244
“Lost flips” indicates that the player did not follow each and every frame but usually this is not a severe error. “Lost frames” should not occur as this indicates that the observer did not see each frame on the screen.
For avoiding these kinds of situations, there are several possibilities:
- Get a faster storage space, i.e. SSDs or SSD raid systems. Take a look at tomshardware to learn what are the fastest SSDs currently on the market. For 2D playback in Full-HD you need a sustained datarate of about 200MB/s, for 3D, you need twice as much (400MB/s).
- Use more prebuffering: The player loads a certain number of frames (config file parameter “NumberOfSurfaces”) into the main memory before starting the playback. This buffer is continuously filled during playback. The larger the buffer, the more time elapses before the actual playback begins (as the player first reads the data from the storage) but the more likely it will be that the playback continues smoothly until the end. The extreme case would be to configure as many “surfaces” as frames in the video: This results in large main memory consumption (calculation for 400 frames in 3D Full-HD, RGB with Alpha is 4 bytes/pixel: 1920x1080x2x400x4=6GB, remark: from experience this is far larger and needs to be checked), and it also results in a long waiting time for the observer as he watches a gray screen until the whole sequence is loaded into memory (at 200MB/s this takes 6000MB/200MB=30seconds).