GStreamer-VAAPI 1.10 (now 1.10.1)
A lot of things have happened last month and I have neglected this report. Let me try to fix it.First, the autumn GStreamer Hackfest and the GStreamer Conference 2016 in Berlin.
The hackfest’s venue was the famous C-Base, where we talked with friends and colleagues. Most of the discussions were leaned towards the release 1.10. Still, Julien Isorce and I talked about our approaches for DMABuf sharing with downstream; we agreed on to explore how to implement an allocator based on GstDmaBufAllocator. We talked with Josep Torra about the performance he was getting with gstreamer-vaapi encoders (and we already did good progress on this). Also we talked with Nicolas Dufresne about v4l2 and kmssink. And many other informal chats along with beer and pizza.
Afterwards, in the GStreamer Conference, I talked a bit about the current status of GStreamer-VAAPI and what we can expect from release 1.10. Here’s the video that the folks from Ubicast recorded. You can see the slides here too.
I spent most of the conference with Scott, Sree and Josep tracing the bottlenecks in the frame uploading to VA Intel driver, and trying to answer the questions of the folks who gently approached me. I hope my answers were any helpful.
And finally, the first of November, the release 1.10 hit the streets!
As it is already mentioned in the release notes, these are the main new features you can find in GStreamer-VAAPI 1.10
- All decoders have been split, one plugin feature per codec. So far, the available ones, depending on the driver, are: vaapimpeg2dec, vaapih264dec, vaapih265dec, vaapivc1dec, vaapivp8dec, vaapivp9dec and vaapijpegdec (which already was split).
- Improvements when mapping VA surfaces into memory, differentiating from negotiation caps and allocations caps, since the allocation memory for surfaces may be bigger than one that is going to be mapped.
- vaapih265enc got support to constant bitrate mode (CBR).
- Since several VA drivers are unmaintained, we decide to keep a white list with the va drivers we actually test, which is mostly the i915 and, in some degree, gallium from mesa project. Exporting the environment variable GST_VAAPI_ALL_DRIVERS disable the white list.
- The plugin features are registered, in run-time, according to its support by the loaded VA driver. So only the decoders and encoder supported by the system are registered. Since the driver can change, some dependencies are tracked to invalidate the GStreamer registry and reload the plugin.
- DMA-Buf importation from upstream has been improved, gaining performance.
- vaapipostproc now can negotiate through caps the buffer transformations.
- Decoders now can do reverse playback! But they only shows I frames, because the surface pool is smaller than the required by the GOP to show all the frames.
- The upload of frames onto native GL textures has been optimized too, keeping a cache of the internal structures for the offered textures by the sink, improving a lot the performance with glimagesink.
This is the short log summary since branch 1.8:
1 Allen Zhang
19 Hyunjun Ko
1 Jagyum Koo
2 Jan Schmidt
7 Julien Isorce
1 Matthew Waters
1 Michael Olbrich
1 Nicolas Dufresne
13 Scott D Phillips
9 Sebastian Dröge
30 Sreerenj Balachandran
1 Stefan Sauer
1 Stephen
1 Thiago Santos
1 Tim-Philipp Müller
1 Vineeth TM
154 Víctor Manuel Jáquez LealThanks to Igalia, Intel Open Source Technology Center and many others for making GStreamer-VAAPI possible.