We're hiring!
*

Testing Video4Linux2 drivers like a boss

Ezequiel Garcia avatar

Ezequiel Garcia
May 23, 2019

Share this post:

Note: In September 2021, the GStreamer project merged all its git repositories into a single, unified repository, often called monorepo. The build system referred in this post as "gst-build" is now in the root of this combined/mono repository.

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.

Down the rabbit hole

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/

With 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

Combining gst-build and virtme

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 vivid driver:

$ 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!

Comments (0)


Add a Comment






Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest Blog Posts

Visual-inertial tracking for Monado

05/04/2022

Monado now has initial support for 6DoF ("inside-out") tracking for devices with cameras and an IMU! Three free and open source SLAM/VIO…

Spotlight on Meson's full-featured developer environment

30/03/2022

When developing an application or a library, it is very common to want to run it without installing it, or to install it into a custom prefix…

How to write a Vulkan driver in 2022

23/03/2022

An incredible amount has changed in Mesa and in the Vulkan ecosystems since we wrote the first Vulkan driver in Mesa for Intel hardware…

Improving the reliability of file system monitoring tools

14/03/2022

Every file system used in production has tools to try to recover from system crashes. To provide a better infrastructure for those tools,…

PipeWire: A year in review & a look ahead

08/03/2022

The PipeWire project made major strides over the past few years, bringing shiny new features, and paving the way for new possibilities in…

Landing a new syscall, part 1: What is futex?

08/02/2022

Over the past 18 months, we have been on a roller-coaster ride developing futex2, a new set of system calls. As part of this effort, the…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2022. All rights reserved. Privacy Notice. Sitemap.