The PyQt testsuite

So, you have installed valkka-core and valkka-examples as instructed here. The same hardware requirements apply here as in the tutorial.

The PyQt testsuite is available at

valkka_examples/api_level_2/qt/

The testsuite is intended for:

  • Demonstration
  • Benchmarking
  • Ultimate debugging
  • As materia prima for developers - take a copy of your own and use it as a basis for your own Valkka / Qt program

If you want a more serious demonstration, try out Valkka Live instead.

Currently the testsuite consists of the following programs:

File Explanation
test_studio_1.py
- Stream from several rtsp cameras or sdp sources
- Widgets are grouped together
- This is just live streaming, so use:

rtsp://username:password@your_ip

- If you define a filename, it is interpreted as an sdp file

test_studio_2.py
- Like test_studio_1.py
- Floating widgets

test_studio_3.py
- Like test_studio_2.py
- On a multi-gpu system, video can be sent to another gpu/x-screen pair

test_studio_4.py
- Like test_studio_3.py
- A simple user menu where video widgets can be opened
- Open the File menu to add video on the screen

test_studio_detector.py
- Like test_studio_1.py
- Shares video to OpenCV processes
- OpenCV processes connect to Qt signal/slot system

test_studio_file.py
- Read and play stream from a matroska file
- Only matroska-contained h264 is accepted.
- Convert your video to “ip-camera-like” stream with:

ffmpeg -i your_video_file -c:v h264 -r 10 -preset ultrafast
-profile:v baseline
-bsf h264_mp4toannexb -x264-params keyint=10:min-keyint=10
-an outfile.mkv

- If you’re recording directly from an IP camera, use:

ffmpeg -i rtsp://username:password@your_ip -c:v copy -an outfile.mkv

test_studio_multicast.py
- Like test_studio_1.py
- Recast multiple IP cameras into multicast

test_studio_rtsp.py
- Like test_studio_1.py
- Recast IP cameras to unicast.
- Streams are accessible from local server:

rtsp://127.0.0.1:8554/streamN

(where N is the number of the camera)

test_studio_5.py
Very experimental
- Prefer test_studio_6.py over this one
- Continuous recording to ValkkaFS
- Dumps all streams to a single file (uses ValkkaMultiFS)
- Simultaneous, interactive playback : use mouse clicks & wheel to navigate the timeline
- remove directory fs_directory/ if the program refuses to start

test_studio_6.py
Experimental
- Continuous recording to ValkkaFS
- One file per stream (uses ValkkaSingleFS)
- Simultaneous, interactive playback : use mouse clicks & wheel to navigate the timeline
- remove directory fs_directory_*/ if the program refuses to start

Before launching any of the testsuite programs you should be aware of the common problems of linux video streaming.

test_studio_1.py

Do this:

cd valkka_examples/api_level_2/qt/
python3 test_studio_1.py

The program launches with the following menu:

_images/test_config.png

The field on the left is used to specify stream sources, one source per line. For IP cameras, use “rtsp://”, for sdp files, just give the filename. In the above example, we are connecting to two rtsp IP cams.

The fields on the right are:

Field name What it does
n720p Number of pre-reserved frames for 720p resolution
n1080p Number of pre-reserved frames for 1080p resolution
n1440p etc.
n4K etc.
naudio (not used)
verbose (not used)
msbuftime Frame buffering time in milliseconds
live affinity Bind the streaming thread to a core. Default = -1 (no binding)
gl affinity Bind frame presentation thread to a core. Default = -1
dec affinity start Bind decoding threads to a core (first core). Default = -1
dec affinity stop Bind decoding threads to cores (last core). Default = -1
replicate Dump each stream to screen this many times
correct timestamp
1 = smart-correct timestamp (use this!)
0 = restamp upon arrival
socket size bytes don’t touch. Default value = 0.
ordering time millisecs don’t touch. Default value = 0.

As you learned from the tutorial, in Valkka, frames are pre-reserved on the GPU. If you’re planning to use 720p and 1080p cameras, reserve, say 200 frames for both.

Decoded frames are being queued for “msbuftime” milliseconds. This is necessary for de-jitter (among other things). The bigger the buffering time, the more pre-reserved frames you’ll need and the more lag you get into your live streaming. A nice value is 300. For more on the subject, read this.

Replicate demonstrates how Valkka can dump the stream (that’s decoded only once) to multiple X windows. Try for example the value 24 - you get each stream on the screen 24 times, without any performance degradation or the need to decode streams more than once.

In Valkka, all threads can be bound to a certain processor core. Default value “-1” indicates that the thread is unbound and that the kernel can switch it from one core to another (normal behaviour).

Let’s consider an example:

Field name value
live affinity 0
gl affinity 1
dec affinity start 2
dec affinity stop 4

Now LiveThread (the thread that streams from cameras) stays at core index 0, all OpenGL operations and frame presenting at core index 1. Let’s imagine you have ten decoders running, then they will placed like this:

Core Decoder thread
core 2 1, 4, 7, 10
core 3 2, 5, 8
core 4 3, 6, 9

Setting processor affinities might help, if you can afford the luxury of having one processor per decoder. Otherwise, it might mess up the load-balancing performed by the kernel.

By default, don’t touch the affinities (simply use the default value -1).

Finally, the buttons that launch the test, do the following:

Button What it does?
SAVE Saves the test configuration (yes, save it)
RUN(QT) Runs THE TEST (after saving, press this!)
RUN Runs the test without Qt
FFPLAY Runs the streams in ffplay instead (if installed)
VLC Runs the streams in vlc instead (if installed)

RUN(QT) is the thing you want to do.

FFPLAY and VLC launch the same rtsp streams by using either ffplay or vlc. This is a nice test to see how Valkka performs against some popular video players.

test_studio_detector.py

The detector test program uses OpenCV, so you need to have it installed

Launch the program like this:

cd valkka_examples/api_level_2/qt/
python3 test_studio_detector.py

This is similar to test_studio_1.py. In addition to presenting the streams on-screen, the decoded frames are passed, once in a second, to OpenCV movement detectors. When movement is detected, a signal is sent with the Qt signal/slot system to the screen.

This test program is also used in the gold standard test. Everything is here: streaming, decoding, OpenGL streaming, interface to python and even the posix shared memory and semaphores. One should be able to run this test with a large number of cameras for a long period of time without excessive memory consumption or system instabilities.