May 23, 2019
In a previous post, we presented virtme, the awesome QEMU wrapper developed by Andy Lutomirski.
virtme allows to run a custom built kernel on top of our running root filesystem, which is quite helpful in the testing phase of some kernel feature or driver.
As an example,
virtme is being used by the media subsystem maintainer as part of the regression tests.
On this post, let's explore another example of virtme in action, and see how to test Video4Linux2 drivers on bleeding edge GStreamer builds.
Why GStreamer? Two sound reasons. First, it supports the Video4Linux APIs quite well. Second, it is a very flexible tool, which allows to implement different tests easily. For instance, we can test encode and decode in the same pipeline:
$ gst-launch-1.0 videotestsrc ! v4l2jpegenc ! decodebin ! fakevideosink
There are cases, where you want to test bleeding-edge GStreamer, either to take advantage of the latest support, or to work on an unsupported feature or new plugin. This all means we'd better shape up and build GStreamer from sources.
This may sound troublesome at first, given GStreamer large and modular source base, but it's actually relatively simple using gst-build.
gst-build is GStreamer's meson-based repository aggregrator. As we will see, it can do much more than that. The README.md has all the info you need to get started, but here's a Debian tl;dr:
Make sure you have meson installed:
$ apt-get install meson
The first step is to clone gst-build and build it. The first time it will clone all the GStreamer repos, and so it will take a lot.
$ git clone https://gitlab.freedesktop.org/gstreamer/gst-build $ cd gst-build && meson build && ninja -C build/
gst-build installed, we can now enter a GStreamer sandbox, which GStreamer folks call the Uninstalled Environment. This environment has your bleeding-edge gstreamer. We can enter the environment, and you will see how the prompt is now changed:
$ ninja -C build/ uninstalled ninja: Entering directory `build/' [0/1] Running external command uninstalled. [gst-master] $ [gst-master] $ gst-launch-1.0 --version gst-launch-1.0 version 1.17.0 GStreamer 1.17.0 (GIT) Unknown package origin
Alternatively, the uninstalled environment can be summoned from your regular environment to run a gstreamer pipeline:
$ ./gst-uninstalled.py gst-launch-1.0 --version gst-launch-1.0 version 1.17.0 GStreamer 1.17.0 (GIT) Unknown package origin
With all the pieces in place, the next step is to add some scripting to automate the testing. We'll ask virtme to run a script right after booting, and inside that script we'll put a GStreamer test using the uninstalled environment.
Just as an example, we could have a
test directory, with a simple
test.sh script inside:
#!/bin/bash ./gst-uninstalled.py gst-launch-1.0 -v v4l2src num-buffers=300 ! v4l2convert ! videoconvert ! kmssink driver-name=virtio_gpu force-modesetting=true
And we'd start
virtme with graphic support, specifying the
test init directory, and also passing arguments to the
$ virtme-run --cwd ~/gst-build --script-dir ~/gst-build/test/ --kdir ~/builds/virtme-x86_64 --kopt vivid.node_types=0x1 --kopt vivid.n_devs=1 --qemu-opts -vga virtio -display gtk,gl=off -m 2000
(Keep in mind, I'm not using vanilla virtme here, but my own fork, which has an extra command to run stuff after booting.)
That's it! This is just an example. From here, we could try many different pipelines here, and take advantage of GStreamer's great flexibility to create complete test suites. Happy testing!
Earlier this year, from January to April 2021, I worked on adding support for stateless decoders for GStreamer as part of a multimedia internship…
In our previous post, we presented a project backed by INVEST-AI which introduces a multi-stage neural network-based solution. Now let's…
Initiated as a joint effort by the Google Chrome OS team and Collabora, the recent KernelCI hackfest brought the addition of new tests including…
There's a lot that has happened in the world of Zink since my last update, so let's see if I can bring you up to date on the most important…
Panfrost, the open source driver for Arm Mali, now supports OpenGL ES 3.1 on both Midgard (Mali T760 and newer) and Bifrost (Mali G31, G52,…
Collabora has been investing into Perfetto to enable driver authors & users to get deep insights into driver internals and GPU performance.…