gstreamer-vaapi issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues2023-06-28T08:26:04Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/344No VASurface after vaapipostproc2023-06-28T08:26:04ZRob KramerNo VASurface after vaapipostprocWhile adding wayland support to my gstreamer application (using waylandsink), I noticed excessive CPU use during playback. When I use gst-play to play the same file, the CPU use is much lower, as expected for a vaapi pipeline. I compared...While adding wayland support to my gstreamer application (using waylandsink), I noticed excessive CPU use during playback. When I use gst-play to play the same file, the CPU use is much lower, as expected for a vaapi pipeline. I compared the dot-graphs of the two applications and as far as I can see, the only difference is that in mine the output of the GatVaapiPostproc element is not marked as VASurface -- which would explain the CPU use.
If I look at warning level debug output, I can't see anything interesting. If I increase the level, things become very verbose..
Does anyone have any idea what could cause this, or how I can further troubleshoot this? Does this indicate that something is going wrong during pad negotiations of some element?https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/343vaapih264dec doesn't seem to support video/x-raw(meta:GstVideoGLTextureUpload...2023-05-29T02:19:53Znabil risevaapih264dec doesn't seem to support video/x-raw(meta:GstVideoGLTextureUploadMeta) video/x-raw(memory:DMABuf)Based on the [doc here](https://gstreamer.freedesktop.org/documentation/vaapi/vaapih264dec.html?gi-language=c) which says the src pad supports video/x-raw(meta:GstVideoGLTextureUploadMeta) and video/x-raw(memory:DMABuf). I tried testing ...Based on the [doc here](https://gstreamer.freedesktop.org/documentation/vaapi/vaapih264dec.html?gi-language=c) which says the src pad supports video/x-raw(meta:GstVideoGLTextureUploadMeta) and video/x-raw(memory:DMABuf). I tried testing them using the following pipelines respectively:
`sudo gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw, format=I420 ! x264enc ! h264parse ! vaapih264dec ! video/x-raw\(meta:GstVideoGLTextureUploadMeta\) ! fakesink`
`sudo gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw, format=I420 ! x264enc ! h264parse ! vaapih264dec ! video/x-raw\(memory:DMABuf\) ! fakesink`
In the first one I get "Internal data stream error" and in the 2nd I get "vaapidecode_h264-0 can't handle caps video/x-raw(memory:DMA)". 'Full output at the end).
Is this a bug or am I missing something?
```
$ sudo gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw, format=I420 ! x264enc ! h264parse ! vaapih264dec ! video/x-raw\(meta:GstVideoGLTextureUploadMeta\) ! fakesink
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
Setting pipeline to PAUSED ...
error: XDG_RUNTIME_DIR not set in the environment.
error: XDG_RUNTIME_DIR not set in the environment.
error: XDG_RUNTIME_DIR not set in the environment.
Pipeline is PREROLLING ...
Got context from element 'vaapidecode_h264-0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayGBM\)\ gldisplaygbm0";
Got context from element 'vaapidecode_h264-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayDRM\)\ vaapidisplaydrm1", gst.vaapi.Display.GObject=(GstObject)"\(GstVaapiDisplayDRM\)\ vaapidisplaydrm1";
Redistribute latency...
Redistribute latency...
ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
streaming stopped, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
```
```
sudo gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw, format=I420 ! x264enc ! h264parse ! vaapih264dec ! video/x-raw\(memory:DMABuf\) ! fakesink
libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
WARNING: erroneous pipeline: could not link vaapidecode_h264-0 to fakesink0, vaapidecode_h264-0 can't handle caps video/x-raw(memory:DMABuf)
```https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/341How can I make dynamic textoverlay on a video feed quicker when the encoding ...2023-04-25T18:17:54Znabil riseHow can I make dynamic textoverlay on a video feed quicker when the encoding and decoding is done by GPU?I got a pipeline like the following:
> rtspsrc ! queue ! rtph264depay ! h264parse ! vaapidecodebin ! queue flush-on-eos=TRUE ! videorate ! video/x-raw,framerate=5/1 ! textoverlay name=textsrc ! videorate ! vaapih264enc ! rtph264pay
Thi...I got a pipeline like the following:
> rtspsrc ! queue ! rtph264depay ! h264parse ! vaapidecodebin ! queue flush-on-eos=TRUE ! videorate ! video/x-raw,framerate=5/1 ! textoverlay name=textsrc ! videorate ! vaapih264enc ! rtph264pay
This is being run on an intel GPU with iHD as a driver, and it's working well to make textoverlay on video and stream it back, the problem is that when I have the textoverlay active it causes delays, after some research I found [This](https://gstreamer.freedesktop.org/documentation/additional/design/subtitle-overlays.html?gi-language=c) which explains a potential issue, encoding/decoding being done on GPU and the textoverlay on CPU (using pango) causes the problem.
I also found about vaapioverlay, which is unlike what it's name indicates is more a video mixer.
I am not sure if it's possible to use vaapioverlay to get the desired result.
Is it possible to get a video feed with just textoverlay on it ? the idea is to overlay it on video stream using vaapioverlay.
Is there a way I can make the textoverlay faster that I am missing?
I didn't find a vaapitextoverlay but is there something close to this?https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/339Vaapi H265 decoder failing on some rtsp streams2023-03-02T08:38:27ZGuru GovindanVaapi H265 decoder failing on some rtsp streamsHi,
I am working with rtsp streams coming from security cameras and I have a decoder pipeline which processes the video streams.
For a few rtsp streams it seems to fail with `decode error -1 (GST_VAAPI_DECODER_STATUS_ERROR_UNKNOWN)`.
T...Hi,
I am working with rtsp streams coming from security cameras and I have a decoder pipeline which processes the video streams.
For a few rtsp streams it seems to fail with `decode error -1 (GST_VAAPI_DECODER_STATUS_ERROR_UNKNOWN)`.
These streams are decoding fine with software decode or nvh265dec.
eg pipeline
```
GST_DEBUG=*vaapi*:6 gst-launch-1.0 rtspsrc latency=100 location=rtsp://admin:pass@192.168.3.8:554/snl/live/1/1 protocols=0x00000004 name=basesrc basesrc. ! rtph265depay ! tee name=t t.! queue ! vaapidecodebin name=video_decoder ! fakesink
```
These errors are driving the GPU utilization to 100%. The following is a error snippet.
```
0:00:03.682988567 48666 0x55ff3c212180 INFO vaapidecode gstvaapidecode.c:775:gst_vaapidecode_handle_frame:<vaapidecode0> requesting upstream a key unit
0:00:03.850340769 48666 0x55ff3c212180 DEBUG vaapi gstvaapidecoder_h265.c:1497:parse_slice: parse slice
0:00:03.850366654 48666 0x55ff3c212180 DEBUG vaapi gstvaapidecoder_h265.c:1783:init_picture: <IDR>
0:00:03.850371236 48666 0x55ff3c212180 DEBUG vaapi gstvaapidecoder_h265.c:1628:init_picture_poc: decode PicOrderCntVal
0:00:03.850380745 48666 0x55ff3c212180 DEBUG vaapi gstvaapidecoder_h265.c:1673:init_picture_poc: PicOrderCntVal 0
0:00:03.850385638 48666 0x55ff3c212180 DEBUG vaapi gstvaapidecoder_h265.c:2818:decode_slice: slice (366282 bytes)
0:00:03.850424706 48666 0x55ff3c212180 DEBUG vaapi gstvaapidecoder_objects.c:263:gst_vaapi_picture_decode_with_surface_id: decode picture 0x00000005
0:00:03.850514131 48666 0x55ff3c212180 DEBUG vaapi gstvaapiutils.c:131:vaapi_check_status: vaEndPicture(): internal decoding error
0:00:03.850521891 48666 0x55ff3c212180 WARN vaapidecode gstvaapidecode.c:764:gst_vaapidecode_handle_frame:<vaapidecode0> decode error -1
0:00:03.850527209 48666 0x55ff3c212180 INFO vaapidecode gstvaapidecode.c:775:gst_vaapidecode_handle_frame:<vaapidecode0> requesting upstream a key unit
0:00:03.850981965 48666 0x55ff3c212180 DEBUG vaapi gstvaapidecoder_h265.c:1497:parse_slice: parse slice
0:00:03.850994269 48666 0x55ff3c212180 DEBUG vaapi gstvaapidecoder_h265.c:1628:init_picture_poc: decode PicOrderCntVal
0:00:03.850998272 48666 0x55ff3c212180 DEBUG vaapi gstvaapidecoder_h265.c:1673:init_picture_poc: PicOrderCntVal 1
0:00:03.851002687 48666 0x55ff3c212180 DEBUG vaapi gstvaapidecoder_h265.c:2818:decode_slice: slice (7723 bytes)
0:00:03.851009258 48666 0x55ff3c212180 DEBUG vaapi gstvaapidecoder_objects.c:263:gst_vaapi_picture_decode_with_surface_id: decode picture 0x00000001
0:00:03.851065636 48666 0x55ff3c212180 DEBUG vaapi gstvaapiutils.c:131:vaapi_check_status: vaEndPicture(): internal decoding error
0:00:03.851070098 48666 0x55ff3c212180 WARN vaapidecode gstvaapidecode.c:764:gst_vaapidecode_handle_frame:<vaapidecode0> decode error -1
```
I have attached the debug logs level 6 with Vaapi filters for the entire run. I appreciate any help with this.
Please let me know if you need any other details.
Thanks![vaapi_debug.log](/uploads/1481cfb62580f80a3691e610d2e32aed/vaapi_debug.log)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/335vp9 causes Internal data stream error2024-03-05T06:54:41ZBram Stolkvp9 causes Internal data stream errorA pipeline with `vaapih264enc ! vaapih264dec` works fine.
Similarly, `vaapih265enc ! vaapih265dec` works, but if I try `vaapivp9enc ! vaapivp9dec` I get an internal data stream error:
```
$ gst-launch-1.0 videotestsrc ! video/x-raw,wi...A pipeline with `vaapih264enc ! vaapih264dec` works fine.
Similarly, `vaapih265enc ! vaapih265dec` works, but if I try `vaapivp9enc ! vaapivp9dec` I get an internal data stream error:
```
$ gst-launch-1.0 videotestsrc ! video/x-raw,width=1920,height=1080 ! vaapivp9enc ! vaapivp9dec ! vaapisink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapisink0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayWayland\)\ vaapidisplaywayland0", gst.vaapi.Display.GObject=(GstObject)"\(GstVaapiDisplayWayland\)\ vaapidisplaywayland0";
ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
streaming stopped, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
```
OS: Ubuntu 22.10
CPU: 12600k
GPU: Intel ADL-S
gstreamer version: 1.20.3-2
vainfo:
```
$ vainfo
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/local/lib/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.17 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.6.0 (54d0e8288)
```
package versions:
```
$ dpkg --list | grep gstreamer
ii gir1.2-gstreamer-1.0:amd64 1.20.3-1 amd64 GObject introspection data for the GStreamer library
ii gstreamer1.0-alsa:amd64 1.20.3-2 amd64 GStreamer plugin for ALSA
ii gstreamer1.0-gl:amd64 1.20.3-2 amd64 GStreamer plugins for GL
ii gstreamer1.0-libav:amd64 1.20.3-1ubuntu2 amd64 ffmpeg plugin for GStreamer
ii gstreamer1.0-packagekit 1.2.5-2ubuntu2 amd64 GStreamer plugin to install codecs using PackageKit
ii gstreamer1.0-pipewire:amd64 0.3.58-2ubuntu1 amd64 GStreamer 1.0 plugin for the PipeWire multimedia server
ii gstreamer1.0-plugins-base:amd64 1.20.3-2 amd64 GStreamer plugins from the "base" set
ii gstreamer1.0-plugins-base-apps 1.20.3-2 amd64 GStreamer helper programs from the "base" set
ii gstreamer1.0-plugins-good:amd64 1.20.3-1ubuntu1 amd64 GStreamer plugins from the "good" set
ii gstreamer1.0-plugins-ugly:amd64 1.20.3-1 amd64 GStreamer plugins from the "ugly" set
ii gstreamer1.0-tools 1.20.3-1 amd64 Tools for use with GStreamer
ii gstreamer1.0-vaapi:amd64 1.20.3-1 amd64 VA-API plugins for GStreamer
ii gstreamer1.0-x:amd64 1.20.3-2 amd64 GStreamer plugins for X11 and Pango
ii libgstreamer-gl1.0-0:amd64 1.20.3-2 amd64 GStreamer GL libraries
ii libgstreamer-plugins-bad1.0-0:amd64 1.20.3-1ubuntu6 amd64 GStreamer libraries from the "bad" set
ii libgstreamer-plugins-base1.0-0:amd64 1.20.3-2 amd64 GStreamer libraries from the "base" set
ii libgstreamer-plugins-good1.0-0:amd64 1.20.3-1ubuntu1 amd64 GStreamer development files for libraries from the "good" set
ii libgstreamer1.0-0:amd64 1.20.3-1 amd64 Core GStreamer libraries and elements
```https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/333vaapi stops working correctly intermittently2022-08-28T05:40:34ZPapasani Mohansrinivasvaapi stops working correctly intermittentlyhi gstreamer-vaapi team,
I am running dlstreamer:devel docker on xeon e2286g bare metal dedicated server from vultr , and in bios boot menu I have enabled integrated graphics card too , when i initialise my pipeline with
```GST_DEBUG...hi gstreamer-vaapi team,
I am running dlstreamer:devel docker on xeon e2286g bare metal dedicated server from vultr , and in bios boot menu I have enabled integrated graphics card too , when i initialise my pipeline with
```GST_DEBUG=3 gst-launch-1.0 udpsrc port=10000 ! queue ! h264parse ! vaapidecodebin ! videorate ! video/x-raw,width=312,height=312 ,framerate=1/1 ! videoconvert ! capsfilter caps="video/x-raw,format=BGR" ! gvapython module=xeon_gva_python.py class=custom_accumulator function=process_frame arg={\\\"cam_no\\\":\\\"1\\\"} ! fakesink async=false```
pipeline runs but , for every 5 hours pipeline stops running showing below statements
```
videodecoder gstvideodecoder.c:1448:gst_video_decoder_sink_event_default:<vaapidecode0> upstream tags: taglist, video-codec=(string)"H.264\ \(Main\ Profile\)", minimum-bitrate=(uint)8080, maximum-bitrate=(uint)160080, bitrate=(uint)27246;
0:00:04.417700189 55 0x55e7662c3b00 WARN vaapidecode gstvaapidecode.c:778:gst_vaapidecode_handle_frame:<vaapidecode0> decode error -1
0:00:04.417734799 55 0x55e7662c3b00 WARN videodecoder gstvideodecoder.c:4361:_gst_video_decoder_error:<vaapidecode0> error: Decoding error
0:00:04.417755512 55 0x55e7662c3b00 WARN videodecoder gstvideodecoder.c:4363:_gst_video_decoder_error:<vaapidecode0> error: Decode error -1
0:00:04.417774714 55 0x55e7662c3b00 INFO vaapidecode gstvaapidecode.c:789:gst_vaapidecode_handle_frame:<vaapidecode0> requesting upstream a key unit
0:00:04.417820212 55 0x55e7662c3b00 INFO h264parse gsth264parse.c:3632:gst_h264_parse_src_event:<h264parse0> received upstream force-key-unit event, seqnum 243 running_time 99:99:99.999999999 all_headers 0 count 0
```
then i had to reboot server for vaapi to properly working again
kindly provide a solution to this !https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/330HEVC Encode corruption with max_transform_hierarchy_depth_inter=22022-07-08T04:26:33ZBoyuan ZhangHEVC Encode corruption with max_transform_hierarchy_depth_inter=2HEVC encode output shows corruption using any AMD/radeon GPU. The issue is cause by patch: https://github.com/GStreamer/gstreamer-vaapi/commit/17d82e14e78af901f1cd7f2344e173ad6ae6a8a6. (According to comment, this workaround was made due ...HEVC encode output shows corruption using any AMD/radeon GPU. The issue is cause by patch: https://github.com/GStreamer/gstreamer-vaapi/commit/17d82e14e78af901f1cd7f2344e173ad6ae6a8a6. (According to comment, this workaround was made due to Intel HW limitations at that time)
After reverting above changes, all tests pass.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/327gstreamer crashes with gstreamer-vaapi installed2022-06-21T14:01:17ZCheriogstreamer crashes with gstreamer-vaapi installedThe issue is documented [here](https://github.com/openframeworks/openFrameworks/issues/6871).
The following error
`(parole:4094): GStreamer-Base-CRITICAL **: 13:27:30.761: basetransform: second attempt to fixate caps returned invalid (...The issue is documented [here](https://github.com/openframeworks/openFrameworks/issues/6871).
The following error
`(parole:4094): GStreamer-Base-CRITICAL **: 13:27:30.761: basetransform: second attempt to fixate caps returned invalid (NULL) caps on pad vaapipostproc0:sink`
shows up with different front ends (parole in my case). It is reliably reproducible in `Arch Linux` when `gstreamer-vaapi` is installed with [the video mentioned here](https://github.com/openframeworks/openFrameworks/issues/6871#issuecomment-1107940741); when gstreamer-vaapi is not installed the video plays but without hardware acceleration.
Hardware acceleration driver: intel-media-driver (Intel UHD Graphics 10710U, Comet Lake GT2)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/323Consider blocklisting the Intel i965 VAAPI driver2022-02-04T02:59:03ZRobert MaderConsider blocklisting the Intel i965 VAAPI driverThe Gnome project currently [considers enabling hardware encoding for screencasting by default](https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2080) in the upcoming 42 release. Right now it looks like only [three driver impl...The Gnome project currently [considers enabling hardware encoding for screencasting by default](https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2080) in the upcoming 42 release. Right now it looks like only [three driver implementations are allowed by defaul](https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/blob/master/gst/vaapi/gstvaapipluginutil.c#L953-955)t:
- `Intel i965 driver`
- `Intel iHD driver`
- `Mesa Gallium driver`
During testing it was found that the i965 driver was by far the one most likely to cause issues. Further more, unlike the later ones which appear to have active upstream activity and generally responsive developers, development on the i965 driver [appears to have mostly stalled](https://github.com/intel/intel-vaapi-driver/commits/master).
In order to provide a more reliable out-of-the-box experience, would it make sense to consider disabling that driver by default? It looks like at least Gnome-Shell otherwise would need to carry its own blocklist.
While this decreases VAAPI support on the first look, the hope by the responsive Shell devs is that using hardware encoding by default in more common places increases driver quality eventually, leading to more widespread use.
---
cc: @ndufresne @vjaquez @He_Junyanhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/321vaapih264enc - PTS < DTS when using b frames2021-11-26T08:01:20ZEric Knappvaapih264enc - PTS < DTS when using b framesI am on the master branch. Using vaapih264enc to create an mpegts file with b frames results in timestamp errors (PTS < DTS). The same file created with x264enc has no timestamp errors.
Create file without b frames
`gst-launch-1.0 vid...I am on the master branch. Using vaapih264enc to create an mpegts file with b frames results in timestamp errors (PTS < DTS). The same file created with x264enc has no timestamp errors.
Create file without b frames
`gst-launch-1.0 videotestsrc num-buffers=50 ! vaapih264enc aud=true ! queue ! mpegtsmux ! filesink location=test-vaapi.ts`
ffplay has no errors
`ffplay test-vaapi.ts`
Create file with b frames
`gst-launch-1.0 videotestsrc num-buffers=50 ! vaapih264enc aud=true max-bframes=2 ! queue ! mpegtsmux ! filesink location=test-vaapi-bframes.ts`
ffplay has many timestamp errors (but still plays fine)
`ffplay test-vaapi-bframes.ts`
```text
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324008999, dts=324009000, size=3634
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324017999, dts=324018000, size=3667
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324026999, dts=324027000, size=3628
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324035999, dts=324036000, size=3642
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324044999, dts=324045000, size=3692
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324053999, dts=324054000, size=3659
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324062999, dts=324063000, size=3628
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324071999, dts=324072000, size=3586
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324080999, dts=324081000, size=3636
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324098999, dts=324099000, size=3603
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324107999, dts=324108000, size=3645
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324116999, dts=324117000, size=3642
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324125999, dts=324126000, size=3638
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324134999, dts=324135000, size=3605
[mpegts @ 0x7fbec8000bc0] Invalid timestamps stream=0, pts=324143999, dts=324144000, size=3644
```
Create file with b frames (x264)
`gst-launch-1.0 videotestsrc num-buffers=50 ! x264enc bframes=2 ! queue ! mpegtsmux ! filesink location=test-x264-bframes.ts`
ffplay has no errors
`ffplay test-x264-bframes.ts`
## Possible fix
x264enc sets PTS and DTS in [gst_x264_enc_encode_frame()](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-ugly/ext/x264/gstx264enc.c#L2589)
vaapih264enc only sets PTS in [gst_vaapi_encoder_h264_reordering()](gst-libs/gst/vaapi/gstvaapiencoder_h264.c#L3303). An invalid DTS is set somewhere else.
Adding a basic DTS here fixes the issue for most of my use cases.
```diff
diff --git a/subprojects/gstreamer-vaapi/gst-libs/gst/vaapi/gstvaapiencoder_h264.c b/subprojects/gstreamer-vaapi/gst-libs/gst/vaapi/gstvaapiencoder_h264.c
index ad56cca2c4..b0ef217309 100644
--- a/subprojects/gstreamer-vaapi/gst-libs/gst/vaapi/gstvaapiencoder_h264.c
+++ b/subprojects/gstreamer-vaapi/gst-libs/gst/vaapi/gstvaapiencoder_h264.c
@@ -764,6 +764,7 @@ struct _GstVaapiEncoderH264
guint abs_diff_pic_num_list0;
guint abs_diff_pic_num_list1;
GstClockTime cts_offset;
+ GstClockTime last_dts;
gboolean config_changed;
/* frame, poc */
@@ -2810,6 +2811,8 @@ reset_properties (GstVaapiEncoderH264 * encoder)
else
encoder->cts_offset = 0;
+ encoder->last_dts = 0;
+
/* init max_frame_num, max_poc */
encoder->log2_max_frame_num =
h264_get_log2_max_frame_num (encoder->idr_period);
@@ -3299,8 +3302,16 @@ gst_vaapi_encoder_h264_reordering (GstVaapiEncoder * base_encoder,
end:
g_assert (picture);
frame = picture->frame;
- if (GST_CLOCK_TIME_IS_VALID (frame->pts))
+ if (GST_CLOCK_TIME_IS_VALID(frame->pts)) {
frame->pts += encoder->cts_offset;
+ if (encoder->cts_offset > 0) {
+ frame->dts = encoder->last_dts + encoder->cts_offset;
+ if (frame->dts >= frame->pts) {
+ frame->dts = frame->pts - (4 * encoder->cts_offset);
+ }
+ encoder->last_dts = frame->dts;
+ }
+ }
/* set frame_num based on previous frame reference type */
set_frame_num (encoder, picture);
```
Setting the DTS here does not work in cases where `fps_n == 0`.
`gst-launch-1.0 filesrc location=test-vaapi-bframes.ts ! tsparse ! tsdemux ! vaapih264dec ! vaapih264enc aud=true max-bframes=2 ! queue ! mpegtsmux ! filesink location=test2.ts`https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/3201.19.3: test suite is failing2022-06-25T18:12:37ZTomasz Kłoczko1.19.3: test suite is failingSource tree configuration:
```console
+ /usr/bin/meson --buildtype=plain --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/libexec --bindir=/usr/bin --sbindir=/usr/sbin --includedir=/usr/include --datadir=/usr/share --mandir=/usr/share...Source tree configuration:
```console
+ /usr/bin/meson --buildtype=plain --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/libexec --bindir=/usr/bin --sbindir=/usr/sbin --includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man --infodir=/usr/share/info --localedir=/usr/share/locale --sysconfdir=/etc --localstatedir=/var --sharedstatedir=/var/lib --wrap-mode=nodownload --auto-features=enabled . x86_64-redhat-linux-gnu -D doc=disabled -D examples=enabled -D tests=enabled
The Meson build system
Version: 0.59.4
Source dir: /home/tkloczko/rpmbuild/BUILD/gstreamer-vaapi-1.19.3
Build dir: /home/tkloczko/rpmbuild/BUILD/gstreamer-vaapi-1.19.3/x86_64-redhat-linux-gnu
Build type: native build
Project name: gstreamer-vaapi
Project version: 1.19.3
C compiler for the host machine: /usr/bin/gcc (gcc 11.2.1 "gcc (GCC) 11.2.1 20211019 (Red Hat 11.2.1-6)")
C linker for the host machine: /usr/bin/gcc ld.bfd 2.37-17
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports link arguments -Wl,-Bsymbolic-functions: YES
Compiler for C supports arguments -fvisibility=hidden: YES
Compiler for C supports arguments -fno-strict-aliasing: YES
Library m found: YES
Found pkg-config: /usr/bin/pkg-config (1.8.0)
Run-time dependency gstreamer-1.0 found: YES 1.19.3
Run-time dependency gstreamer-base-1.0 found: YES 1.19.3
Run-time dependency gstreamer-pbutils-1.0 found: YES 1.19.3
Run-time dependency gstreamer-allocators-1.0 found: YES 1.19.3
Run-time dependency gstreamer-video-1.0 found: YES 1.19.3
Run-time dependency gstreamer-codecparsers-1.0 found: YES 1.19.1
Run-time dependency gstreamer-gl-1.0 found: YES 1.19.3
Header <gst/gstconfig.h> has symbol "GST_DISABLE_GST_DEBUG" with dependency gstreamer-1.0: YES
Message: GStreamer debug system is disabled
Compiler for C supports arguments -Wno-unused: YES
Run-time dependency gmodule-2.0 found: YES 2.70.1
Run-time dependency libva found: YES 1.13.0
Run-time dependency libva-drm found: YES 1.13.0
Run-time dependency libva-wayland found: YES 1.13.0
Run-time dependency libva-x11 found: YES 1.13.0
Run-time dependency libdrm found: YES 2.4.107
Run-time dependency libudev found: YES 249
Run-time dependency egl found: YES 1.5
Run-time dependency gl found: YES 1.2
Run-time dependency glesv2 found: YES 3.2
Run-time dependency gstreamer-check-1.0 found: YES 1.19.3
Library dl found: YES
Run-time dependency wayland-client found: YES 1.19.0
Run-time dependency wayland-protocols found: YES 1.23
Program wayland-scanner found: YES (/usr/bin/wayland-scanner)
Run-time dependency x11 found: YES 1.7.2
Run-time dependency xrandr found: YES 1.5.2
Run-time dependency gtk+-3.0 found: YES 3.24.30
Has header "GLES2/gl2.h" with dependency glesv2: YES
Has header "GLES2/gl2ext.h" with dependency glesv2: YES
Has header "GLES3/gl3.h" with dependency glesv2: YES
Has header "GLES3/gl3ext.h" with dependency glesv2: YES
Has header "GLES2/gl2ext.h" with dependency glesv2: YES (cached)
Has header "va/va_enc_vp9.h" with dependency libva: YES
Has header "va/va_dec_av1.h" with dependency libva: YES
Run-time dependency gstreamer-gl-prototypes-1.0 found: YES 1.19.3
Run-time dependency gstreamer-gl-x11-1.0 found: YES 1.19.3
Run-time dependency gstreamer-gl-wayland-1.0 found: YES 1.19.3
Run-time dependency gstreamer-gl-egl-1.0 found: YES 1.19.3
Has header "X11/XKBlib.h" with dependency x11: YES
Program /usr/libexec/gstreamer-1.0/gst-plugins-doc-cache-generator found: YES (/usr/libexec/gstreamer-1.0/gst-plugins-doc-cache-generator)
Program hotdoc skipped: feature doc disabled
Message: Hotdoc not found, not building the documentation
Program scripts/extract-release-date-from-doap-file.py found: YES (/home/tkloczko/rpmbuild/BUILD/gstreamer-vaapi-1.19.3/scripts/extract-release-date-from-doap-file.py)
Message: Package release date: 2021-11-03
Configuring config.h using configuration
Build targets in project: 24
```
And test suite result:
```console
+ /usr/bin/meson test -C x86_64-redhat-linux-gnu --num-processes 12 --print-errorlogs
ninja: Entering directory `/home/tkloczko/rpmbuild/BUILD/gstreamer-vaapi-1.19.3/x86_64-redhat-linux-gnu'
ninja: no work to do.
1/2 elements_vaapioverlay OK 0.88s
2/2 elements_vaapipostproc FAIL 1.72s exit status 2
>>> MALLOC_PERTURB_=13 GST_PLUGIN_PATH_1_0=/home/tkloczko/rpmbuild/BUILD/gstreamer-vaapi-1.19.3/x86_64-redhat-linux-gnu:/usr/lib64/gstreamer-1.0 GST_PLUGIN_SYSTEM_PATH_1_0='' GST_REGISTRY=/home/tkloczko/rpmbuild/BUILD/gstreamer-vaapi-1.19.3/x86_64-redhat-linux-gnu/tests/check/elements_vaapipostproc.registry CK_DEFAULT_TIMEOUT=20 /home/tkloczko/rpmbuild/BUILD/gstreamer-vaapi-1.19.3/x86_64-redhat-linux-gnu/tests/check/elements_vaapipostproc
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
stdout:
Running suite(s): vaapipostproc
33%: Checks: 3, Failures: 0, Errors: 2
../tests/check/elements/vaapipostproc.c:174:E:general:test_crop_mouse_events:0: (after this point) Received signal 6 (Aborted)
../tests/check/elements/vaapipostproc.c:174:E:general:test_orientation_mouse_events:0: (after this point) Received signal 6 (Aborted)
Check suite vaapipostproc ran in 0.823s (tests failed: 2)
stderr:
(gst-plugin-scanner:512076): GStreamer-WARNING **: 23:22:53.479: Failed to load plugin '/usr/lib64/gstreamer-1.0/libgstrtp.so': /usr/lib64/gstreamer-1.0/libgstrtp.so: undefined symbol: gst_rtp_header_extension_set_attributes_from_caps_simple_sdp
(gst-plugin-scanner:512076): GStreamer-WARNING **: 23:22:53.479: Failed to load plugin '/usr/lib64/gstreamer-1.0/libgstrtpmanager.so': /usr/lib64/gstreamer-1.0/libgstrtpmanager.so: undefined symbol: gst_rtp_header_extension_set_attributes_from_caps_simple_sdp
libva info: VA-API version 1.13.0
libva info: Trying to open /usr/lib64/dri/nouveau_drv_video.so
libva info: Found init function __vaDriverInit_1_13
libva info: va_openDriver() returns 0
libva info: VA-API version 1.13.0
libva info: Trying to open /usr/lib64/dri/nouveau_drv_video.so
libva info: Found init function __vaDriverInit_1_13
libva info: va_openDriver() returns 0
nouveau: kernel rejected pushbuf: No such device
nouveau: ch2: krec 0 pushes 1 bufs 4 relocs 0
nouveau: ch2: buf 00000000 00000002 00000004 00000004 00000000
nouveau: ch2: buf 00000001 00000006 00000004 00000000 00000004
nouveau: ch2: buf 00000002 0000000c 00000002 00000000 00000002
nouveau: ch2: buf 00000003 0000000d 00000004 00000004 00000000
nouveau: ch2: psh 00000000 0000001ef4 0000001f44
nouveau: 0x200181c2
nouveau: 0x03303210
nouveau: 0x200681c3
nouveau: 0x00001030
nouveau: 0x00000020
nouveau: 0x00000040
nouveau: 0x00000001
nouveau: 0x00000000
nouveau: 0x00000000
nouveau: 0x20088100
nouveau: 0x00000000
nouveau: 0x003d5000
nouveau: 0x00000000
nouveau: 0x019a3000
nouveau: 0x00000080
nouveau: 0x00000080
nouveau: 0x00000020
nouveau: 0x00000040
nouveau: 0x200180c0
nouveau: 0x00000686
elements_vaapipostproc: ../nouveau/pushbuf.c:728: nouveau_pushbuf_data: Assertion `kref' failed.
nouveau: kernel rejected pushbuf: No such device
nouveau: ch2: krec 0 pushes 1 bufs 4 relocs 0
nouveau: ch2: buf 00000000 00000002 00000004 00000004 00000000
nouveau: ch2: buf 00000001 00000006 00000004 00000000 00000004
nouveau: ch2: buf 00000002 0000001a 00000002 00000000 00000002
nouveau: ch2: buf 00000003 0000000c 00000004 00000004 00000000
nouveau: ch2: psh 00000000 0000001f44 0000001f94
nouveau: 0x200181c2
nouveau: 0x03303210
nouveau: 0x200681c3
nouveau: 0x00001030
nouveau: 0x00000020
nouveau: 0x00000040
nouveau: 0x00000001
nouveau: 0x00000000
nouveau: 0x00000000
nouveau: 0x20088100
nouveau: 0x00000000
nouveau: 0x019a7000
nouveau: 0x00000000
nouveau: 0x019a5000
nouveau: 0x00000080
nouveau: 0x00000080
nouveau: 0x00000020
nouveau: 0x00000040
nouveau: 0x200180c0
nouveau: 0x00000686
elements_vaapipostproc: ../nouveau/pushbuf.c:728: nouveau_pushbuf_data: Assertion `kref' failed.
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
Summary of Failures:
2/2 elements_vaapipostproc FAIL 1.72s exit status 2
Ok: 1
Expected Fail: 0
Fail: 1
Unexpected Pass: 0
Skipped: 0
Timeout: 0
```https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/318gst-vaapi crashes with the following error found no short_term_reference pict...2021-11-15T14:53:07ZGuru Govindangst-vaapi crashes with the following error found no short_term_reference picture with PicNumHi There,
GST_VAAPI version: 1.18.4.1
I am doing some benchmarking with Gstreamer pipelines and Intel GPU.
I have created a test stream that loops through a ts segment to generate an rtsp stream.
```
for i in $(seq 1 16); do
ffmpe...Hi There,
GST_VAAPI version: 1.18.4.1
I am doing some benchmarking with Gstreamer pipelines and Intel GPU.
I have created a test stream that loops through a ts segment to generate an rtsp stream.
```
for i in $(seq 1 16); do
ffmpeg -re -stream_loop -1 -i test.ts -c copy -f rtsp rtsp://localhost:8554/mystream$i > raw_logs/ffmpeg_$i.log 2>&1 &
sleep 1
done
```
I am running the following pipeline ingesting each fo the 16 streams
```
gst-launch-1.0 hlssink2 name=enc_ingest1 playlist-length=5 max-files=10 target-duration=2 send-keyframe-requests=true playlist-location="/spot-tmp/gst1/360/enc_stream1.m3u8" location="/spot-tmp/gst1/360/fa%05d.ts" async=false \
rtspsrc location="rtsp://:@10.0.0.206:8554/mystream$i" protocols=4 name=rtspsrc0 rtspsrc0. ! rtph264depay ! h264parse ! queue ! vaapih264dec ! videoscale ! "video/x-raw,width=640" ! videorate ! "video/x-raw,framerate=10/1" ! vaapih264enc ! enc_ingest1.video
```
The pipeline works fine for the first 5 streams after that I start getting the following errors on other pipelines and they stop ingesting.
```
0:00:10.646916697 215 0x55a537dfd760 ERROR vaapi gstvaapidecoder_h264.c:2757:find_short_term_reference: found no short-term reference picture with PicNum = 5
0:00:10.646972894 215 0x55a537dfd760 ERROR vaapi gstvaapidecoder_h264.c:2757:find_short_term_reference: found no short-term reference picture with PicNum = 5
0:00:10.646989200 215 0x55a537dfd760 ERROR vaapi gstvaapidecoder_h264.c:2757:find_short_term_reference: found no short-term reference picture with PicNum = 4
0:00:10.647001969 215 0x55a537dfd760 ERROR vaapi gstvaapidecoder_h264.c:2757:find_short_term_reference: found no short-term reference picture with PicNum = 3
0:00:10.647016914 215 0x55a537dfd760 ERROR vaapi gstvaapidecoder_h264.c:2963:exec_picture_refs_modification_1: list 0 entry 0 is empty
0:00:10.647030196 215 0x55a537dfd760 ERROR vaapi gstvaapidecoder_h264.c:2963:exec_picture_refs_modification_1: list 0 entry 1 is empty
0:00:10.647041867 215 0x55a537dfd760 ERROR vaapi gstvaapidecoder_h264.c:2963:exec_picture_refs_modification_1: list 0 entry 2 is empty
0:00:10.647053899 215 0x55a537dfd760 ERROR vaapi gstvaapidecoder_h264.c:2963:exec_picture_refs_modification_1: list 0 entry 3 is empty
0:00:10.778790111 215 0x55a537dfd760 WARN vaapidecode gstvaapidecode.c:780:gst_vaapidecode_handle_frame:<vaapidecode0> decode error -1
0:00:10.778795028 215 0x55a537dfd760 WARN videodecoder gstvideodecoder.c:4361:_gst_video_decoder_error:<vaapidecode0> error: Decoding error
0:00:10.778798718 215 0x55a537dfd760 WARN videodecoder gstvideodecoder.c:4363:_gst_video_decoder_error:<vaapidecode0> error: Decode error -1
0:00:10.780945866 215 0x55a537c65b00 FIXME basesink gstbasesink.c:3384:gst_base_sink_default_event:<giostreamsink0> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
0:00:10.780974685 215 0x55a537c65b00 WARN gio_base_sink gstgiobasesink.c:218:gst_gio_base_sink_event:<giostreamsink0> ignored SEGMENT event in time format
Redistribute latency...
0:00:11.268396982 215 0x55a537dfce40 FIXME basesink gstbasesink.c:3384:gst_base_sink_default_event:<giostreamsink1> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
0:00:11.268439473 215 0x55a537dfce40 WARN gio_base_sink gstgiobasesink.c:218:gst_gio_base_sink_event:<giostreamsink1> ignored SEGMENT event in time format
0:03:55.888237472 215 0x7f0c640058c0 WARN rtspsrc gstrtspsrc.c:3574:on_timeout_common:<rtspsrc0> source 95974fbf, stream 95974fbf in session 0 timed out
```
It works fine with software decoding. So I think it could be a problem with gst-vaapi. Is there any parameters in gst-vaapi decoder I should set so that it is happy?
Appreciate your help.
Thanks!https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/3161.18.5: rotation on sink is not working anymore after switching from X to Way...2021-11-17T11:40:26ZMarc Leeman1.18.5: rotation on sink is not working anymore after switching from X to WaylandRotation on the video sink does not seem to work anymore.
`gst-launch-1.0 videotestsrc ! vaapipostproc ! vaapisink rotation=180`
ii i965-va-driver-shaders:amd64 2.4.1-1 amd64 VAAPI ...Rotation on the video sink does not seem to work anymore.
`gst-launch-1.0 videotestsrc ! vaapipostproc ! vaapisink rotation=180`
ii i965-va-driver-shaders:amd64 2.4.1-1 amd64 VAAPI driver for Intel G45 & HD Graphics familyhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/314Video decoded with vaapih264 occasionally appears green2021-09-27T09:01:45Zwugaosheng123Video decoded with vaapih264 occasionally appears greenI use GStreamer to play a UDP video stream, and my pipeline string is
`udpsrc port=1991 caps=\"application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264\" ! rtpjitterbuffer latency=20 ! rtpmp2tdepay ! ts...I use GStreamer to play a UDP video stream, and my pipeline string is
`udpsrc port=1991 caps=\"application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264\" ! rtpjitterbuffer latency=20 ! rtpmp2tdepay ! tsdemux ! queue name=video_ch ! h264parse ! queue name=dec0 ! vaapih264dec ! videoconvert n-threads=0 ! autovideosink`
However, he may occasionally have a green screen as shown in the figure:
![2021-09-17_16-33-43](/uploads/f362661bc1ffa89eb26d9dc902e7d039/2021-09-17_16-33-43.png)
Then I use the following pipeline to play the video stream again and save the video stream as a video file in MP4 format again.
`udpsrc port=1991 caps=\"application/x-rtp, media=video\" ! rtpjitterbuffer latency=200 ! rtpmp2tdepay ! tsdemux ! tee name=tee0 tee0.! queue ! filesink location=test.mp4 tee0.! queue name=video_ch ! h264parse ! queue name=dec0 ! vaapih264dec ! videoconvert n-threads=0 ! autovideosink`
When I use ffplay and VLC to play the MP4 file, there will be no green screen, but the following prompt error occurs when I use ffplay.
![2021-09-17_16-49-22](/uploads/1056cbcf776be321bcbb24395304898a/2021-09-17_16-49-22.png)
When I broadcast the MP4 file using gstplay and the following pipeline, a green screen appears, but replace vaapih264dec in the pipeline with avdec_h264, vaapisink is replaced with autovideosink (using soft decoding), the green screen phenomenon disappears.
`filesrc location=/home/wgs/hp2.mp4 ! h264parse ! vaapih264dec low-latency =true !vaapisink`
I think the above reason is the problem of the decoder in vaapi plug-in. The decoder used by ffplay and VLC can deal with the loss of I-frames, while vaapih264dec has a problem when I-frames are lost. I don't know if my analysis is reasonable. I haven't found vaapih264dec any problems, and I don't know how to solve them.
When I use the vainfo command, the result is:
![image](/uploads/655b5a105859dfcdccc1e4482b114d97/image.png)
When I make the ` lspci | grep VGA`command, my result is shown in the figure.
![image](/uploads/33e37ad4acd8e55641c41e325dbe5bc1/image.png)
I really need your help.
Thanks.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/313Frame tearing caused by 4k video and interaction with GL on certain configura...2021-09-24T12:23:32ZFrancisco Ayala Le BrunFrame tearing caused by 4k video and interaction with GL on certain configurationsThe following command results in frame tearing when vaapidecodebin is selected by decodebin:
`gst-launch-1.0 -v urisourcebin uri=https://upload.wikimedia.org/wikipedia/commons/0/08/Visit_of_the_Mandelbulb_%284K_UHD%3B_50FPS%29.webm ! dec...The following command results in frame tearing when vaapidecodebin is selected by decodebin:
`gst-launch-1.0 -v urisourcebin uri=https://upload.wikimedia.org/wikipedia/commons/0/08/Visit_of_the_Mandelbulb_%284K_UHD%3B_50FPS%29.webm ! decodebin ! glimagesink`
![decodebin.svg](/uploads/c2b7fd1b8a91f389c42c692bbd960bbb/decodebin.svg)
This means that both the `player`, `playbin`, and all other elements which use the decodebin in some way have this same problem.
However, when the pipeline is recreated as closely as possible using the following, there is no frame tearing:
`urisourcebin uri=https://upload.wikimedia.org/wikipedia/commons/0/08/Visit_of_the_Mandelbulb_%284K_UHD%3B_50FPS%29.webm ! typefind! matroskademux ! multiqueue max-size-bytes=2097152 max-size-time=0 ! vaapidecodebin ! glimagesink`
![recreate.svg](/uploads/ca0fa196a45eb5ae7fc522853b5e9e6a/recreate.svg)
I have noticed that when using the decodebin programmatically I don't get `GLSyncMeta` with the buffers. Perhaps that is the problem. However, I can't confirm whether the second pipeline will correctly deliver the `GLSyncMeta`, as I haven't been able to instantiate it programatically yet.
## Environment
```
ibva info: VA-API version 1.11.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_11
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.11 (libva 2.10.0)
vainfo: Driver version: Mesa Gallium driver 21.2.1 - kisak-mesa PPA for AMD Radeon RX 6700 XT (NAVY_FLOUNDER, DRM 3.40.0, 5.11.0-31-generic, LLVM 12.0.1)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
```
Gstreamer version is 1.18.4-1.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/312Green screen instead of playing video2021-11-17T10:12:10ZChristian StadelmannGreen screen instead of playing videoEnvironment: GNOME+Wayland session, have gstreamer1-vaapi installed.
Steps to reproduce:
1. Start epiphany
2. browse any website with video
3. start video
What should happen:
Play video. If it cannot be done using hardware acceleration...Environment: GNOME+Wayland session, have gstreamer1-vaapi installed.
Steps to reproduce:
1. Start epiphany
2. browse any website with video
3. start video
What should happen:
Play video. If it cannot be done using hardware acceleration, use software video decoding instead. If that is also not possible, show an error message.
What happens:
Green screen instead of video.
Example output on command line:
```
$ LC_ALL=C epiphany https://winfuture.de/videos/Hardware/Fairphone-3-im-Hands-On-Transparentes-fair-gebautes-Smartphone-20630.html
failed to open /usr/lib64/dri/hybrid_drv_video.so
Not using hybrid_drv_video.so
failed to open /usr/lib64/dri/hybrid_drv_video.so
Not using hybrid_drv_video.so
failed to open /usr/lib64/dri/hybrid_drv_video.so
Not using hybrid_drv_video.so
** (epiphany:252407): WARNING **: 19:29:51.802: GDK is not able to create a GL context, falling back to glReadPixels (slow!): Unable to create a GL context
```
(Note that I don't have a hybrid GPU system, only an Intel iGPU)
Note: This issue was first reported on https://gitlab.gnome.org/GNOME/epiphany/-/issues/1594, then to https://bugs.webkit.org/show_bug.cgi?id=230057 on recommendation by Michael Catanzaro.
## Software version info:
epiphany-40.3-1.fc34.x86_64
webkit2gtk3-2.32.3-1.fc34.x86_64
glib2-2.68.4-1.fc34.x86_64
gtk3-3.24.30-1.fc34.x86_64
gstreamer1-1.19.1-2.1.18.4.fc34.x86_64
gstreamer1-vaapi-1.19.1-2.1.18.4.fc34.x86_64
gstreamer1-libav-1.18.4-3.fc34.x86_64
libva-2.11.0-1.fc34.x86_64
libva-intel-driver-2.4.1-5.fc34.x86_64
# vainfo output
With and without gstreamer1-vaapi installed, `vainfo` has the same output:
```
vainfo
libva info: VA-API version 1.11.0
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_11
libva error: /usr/lib64/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_10
failed to open /usr/lib64/dri/hybrid_drv_video.so
Not using hybrid_drv_video.so
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.11 (libva 2.11.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Ironlake Desktop - 2.4.1
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264Main : VAEntrypointVLD
VAProfileH264High : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
```
# Totem
Note: Playing back the same video with totem (and gstreamer1-vaapi installed) instead of epiphany shows the video just fine.
# Debugging info
Following a similar bug (#164), I've attached the output of running `$ GST_DEBUG="2,vaapi*:7" LC_ALL=C epiphany https://winfuture.de/videos/Hardware/Fairphone-3-im-Hands-On-Transparentes-fair-gebautes-Smartphone-20630.html` and playing the (green screen) video about 11 seconds here:
* with terminal colors: [gstreamer-vaapi-green-screen.stderr.log](/uploads/5323b992244fd423b2e0b0cdaf87b0ac/gstreamer-vaapi-green-screen.stderr.log)
* same logfile without terminal color codes: [gstreamer-vaapi-green-screen.stderr-nocolors.log](/uploads/90e5e58fc7e67bfe003889692f515e97/gstreamer-vaapi-green-screen.stderr-nocolors.log)
I am willing to provide more debugging info but I don't know where to start debugging.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/310vaapisink triggers assert in theoradec2021-09-24T12:23:31Zlaknollvaapisink triggers assert in theoradecHi all,
I'm currently working on the gstreamer backend for Qt Multimedia in Qt 6, and am having some trouble using the vaapisink on my machine. First issue follows (as I could nicely isolate it to gstreamer only):
Running:
```
gst-lau...Hi all,
I'm currently working on the gstreamer backend for Qt Multimedia in Qt 6, and am having some trouble using the vaapisink on my machine. First issue follows (as I could nicely isolate it to gstreamer only):
Running:
```
gst-launch-1.0 filesrc location=~/Videos/ogg.ogg ! oggdemux ! theoradec ! videoconvert ! vaapisink
```
triggers the following assertion:
```
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapisink0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
**
ERROR:../subprojects/gst-plugins-base/ext/theora/gsttheoradec.c:710:theora_handle_image: assertion failed: (vmeta->height == dec->info.frame_height)
Bail out! ERROR:../subprojects/gst-plugins-base/ext/theora/gsttheoradec.c:710:theora_handle_image: assertion failed: (vmeta->height == dec->info.frame_height)
Aborted
```
There are no issues when running the same pipeline using xvimagesink or glimagesink.
This happens using gstreamer-1.18.4, I couldn't try 1.19, as that has other (larger) issues when using vaapi elements on my HW.
Output of vainfo below:
```
libva info: VA-API version 1.7.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_7
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.7 (libva 2.6.0)
vainfo: Driver version: Mesa Gallium driver 21.1.0-devel for AMD Radeon RX 5700 XT (NAVI10, DRM 3.35.0, 5.4.0-80-generic, LLVM 12.0.0)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
```https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/308pipe.set_context(context) not working?2021-12-02T12:00:26ZMarianna Smidth Buschlepipe.set_context(context) not working?Basically I have 2 problems which are both related to the `VADisplay` (in the `GstContext`):
- I need to do remote development, so I need to use X forwarding (`ssh -X`)
- I need to decouple my pipelines, using something like the `interpi...Basically I have 2 problems which are both related to the `VADisplay` (in the `GstContext`):
- I need to do remote development, so I need to use X forwarding (`ssh -X`)
- I need to decouple my pipelines, using something like the `interpipesrc/sink` from RidgeRun
For the 1st see http://gstreamer-devel.966125.n4.nabble.com/vaapi-and-x-forwarding-td4697642.html for full story.
But basically the issue is that I need to remotely run (with X forwarding) some pipelines with VAAPI elements (`vaapih264enc/dec`), a simple example:
```
gst-launch-1.0 videotestsrc is-live=true pattern=ball !
video/x-raw,framerate=30/1,format=NV12 ! tee name=t ! queue ! vaapih264enc
rate-control=4 bitrate=15000 ! video/x-h264,profile=high ! h264parse !
fakesink t. ! queue ! videoconvert ! timeoverlay ! textoverlay text=src !
ximagesink sync=0
```
Which results in:
```
Setting pipeline to PAUSED ...
error: XDG_RUNTIME_DIR not set in the environment.
X Error of failed request: BadRequest (invalid request code or no such
operation)
Major opcode of failed request: 154 (DRI2)
Minor opcode of failed request: 1 (DRI2Connect)
Serial number of failed request: 12
Current serial number in output stream: 12
```
It has been pointed to me that the problem is related `DRI2` support:
> I guess the problems caused by the `SSH with "-X"`
The vaapi elements need the DRI2 protocal support, which can not span
the machine. It only support local X server.
> You can run this command on the local machine or compile the VAAPI
plugins without X11 feature.
> Vaapi element inside use gst_vaapi_create_display() to create the
VADisplay. It will try wayland, x11, drm one by one. In your case, the
x11 way return success and so choose. But later, when vaInitialize, the
it fails to init because no DRI2 extersion support.
> The best way is disabling the X11 support in build. And because you do
not need to use vaapisink, it is OK.
With this information I have managed to "force" the DRM display by doing something like this:
```
gst-launch-1.0 videotestsrc is-live=true pattern=ball !
video/x-raw,framerate=30/1,format=NV12 ! tee name=t ! queue ! vaapih264enc
rate-control=4 bitrate=5000 ! video/x-h264,profile=high ! queue ! h264parse
! queue ! vaapih264dec low-latency=1 ! queue !
video/x-raw,framerate=30/1,format=NV12 ! queue ! videoconvert ! queue !
ximagesink sync=0 fakesrc ! vaapisink display=drm --gst-debug=*:3
```
The `fakesrc ! vaapisink display=drm` forces the `VADisplay` to DRM and that gets shared on the bus and set automatically on the `vaapih264enc`/`vaapih264dec`
The `fakesrc ! vaapisink display=drm` pipeline dies right away:
```
0:00:00.167233055 5878 0x564d0741e4f0 WARN vaapisink gstvaapipluginbase.c:1260:gst_vaapi_plugin_base_pad_get_input_buffer:<vaapisink0> error: failed to validate source buffer
0:00:00.167252497 5878 0x564d0741e4f0 WARN vaapisink gstvaapipluginbase.c:1260:gst_vaapi_plugin_base_pad_get_input_buffer:<vaapisink0> error: failed to validate source buffer
ERROR: from element /GstPipeline:pipeline0/GstVaapiSink:vaapisink0: failed to validate source buffer
Additional debug info:
../gstreamer-vaapi-1.18.2/gst/vaapi/gstvaapipluginbase.c(1260): gst_vaapi_plugin_base_pad_get_input_buffer (): /GstPipeline:pipeline0/GstVaapiSink:vaapisink0: failed to validate source buffer
ERROR: pipeline doesn't want to preroll.
0:00:00.167433979 5878 0x564d0741e4f0 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<fakesrc0> error: Internal data stream error.
0:00:00.167453711 5878 0x564d0741e4f0 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<fakesrc0> error: streaming stopped, reason error (-5)
ERROR: from element /GstPipeline:pipeline0/GstFakeSrc:fakesrc0: Internal data stream error.
```
But the rest continues to play fine.
Now I would like a bit more elegant solution, since I need to handle anyway the HAVE_CONTEXT and NEED_CONTEXT messages on the bus because I want to decouple my pipelines.
So I have tried:
```
pipelines.append("videotestsrc num-buffers=1 ! vaapisink display=drm
name=vaapi_dummy")
pipelines.append("videotestsrc is-live=true pattern=ball !
video/x-raw,framerate=30/1,format=NV12 ! "
"tee name=t ! queue ! vaapih264enc name=enc rate-control=4
bitrate=15000 ! video/x-h264,profile=high ! h264parse ! "
"interpipesink name=vtest sync=false async=false "
"t. ! queue ! videoconvert ! timeoverlay ! textoverlay
text=src ! ximagesink sync=0 ")
pipelines.append("interpipesrc listen-to=vtest is-live=false
stream-sync=restart-ts ! "
"identity sync=true ! h264parse ! vaapih264dec name=dec
low-latency=true ! queue ! videoconvert ! timeoverlay ! textoverlay
name=text_out text=out ! ximagesink sync=0 ")
```
The first pipeline goes to playing from start, and then after I got the context from it I start the other 2.
However it doesn't work, I end up getting the DRI2 error as soon as the 2 other pipelines go into playing/ready/paused, before I get the NEED_CONTEXT message from them...
So I have also tried setting the context before setting them to PLAYING (instead of waiting for the NEED_CONTEXT), but the context doesn't seem to get applied, because I still get the DRI2 error.
```
def on_message(self, bus, message, pipe):
mtype = message.type
if mtype == Gst.MessageType.EOS:
# Handle End of Stream
print("End of stream from " + str(message.src.name))
elif mtype == Gst.MessageType.ERROR:
# Handle Errors
err, debug = message.parse_error()
print(err, debug)
self.loop.quit()
exit(-1)
elif mtype == Gst.MessageType.WARNING:
# Handle warnings
err, debug = message.parse_warning()
print(err, debug)
elif mtype == Gst.MessageType.NEED_CONTEXT:
res, context_type = message.parse_context_type()
print("Got NEED_CONTEXT: " + str(context_type) + " from " + str(message.src.name))
if context_type != "gst.vaapi.Display":
return Gst.BusSyncReply.PASS
if not self.vaapi_display:
print("No Context available")
return Gst.BusSyncReply.PASS
context = Gst.Context.new("gst.vaapi.Display", False)
s = context.writable_structure()
s.set_value("gst.vaapi.Display", self.vaapi_display)
message.src.set_context(context)
elif mtype == Gst.MessageType.HAVE_CONTEXT:
context = message.parse_have_context()
if not context:
return Gst.BusSyncReply.PASS
context_type = context.get_context_type()
print("Got HAVE_CONTEXT: " + str(context_type) + " from " + str(message.src.name))
if context_type != "gst.vaapi.Display":
return Gst.BusSyncReply.PASS
s = context.get_structure()
if not s:
return Gst.BusSyncReply.PASS
value = s.get_value("gst.vaapi.Display")
if not value:
return Gst.BusSyncReply.PASS
print("Found display: " + str(value.name))
if not self.vaapi_display:
self.vaapi_display = GObject.Value.dup_object(value)
print("New display: " + str(self.vaapi_display.name))
else:
print("Warning, we already have a VADisplay: " + str(self.vaapi_display.name))
#play other pipes when we have a VADisplay
if message.src.name == "vaapi_dummy":
for pipe in self.pipeline:
enc = pipe.get_by_name("enc")
dec = pipe.get_by_name("dec")
if enc or dec:
context = Gst.Context.new("gst.vaapi.Display", False)
s = context.writable_structure()
s.set_value("gst.vaapi.Display", self.vaapi_display)
if enc:
print("Setting enc context")
pipe.set_context(context)
if dec:
print("Setting dec context")
pipe.set_context(context)
self.play(pipe=pipe)
#return True
return Gst.BusSyncReply.PASS
```
The only way I can avoid the error is by adding fx `videotestsrc num-buffers=1 ! vaapisink display=drm` to each pipeline (which I really don't this is a good solution).
Then I can see the NEED/HAVE context messages from all the vaapisinks, but not from encoder/decoder.
I guess their contexts are being set by upstream/downstream queries?
And for the second problem, if I don't use X forwarding, but just want to be able to set a common `VADisplay` for the encoder/decoder in the decoupled pipelines.
I still get kind of the same issues, the context doesn't seem to get applied through neither the NEED_CONTEXT nor if I do it before going into playing.
I end up getting a lot of NEED/HAVE context messages from both encoder and decoder with all sorts of different displays and not the DRM from the first "dummy" pipeline.
```
0:00:00.112341812 10690 0x7fc8901bd750 WARN vaapiblend gstvaapiblend.c:184:gst_vaapi_blend_initialize:<vaapiblend0> VPP does not support global alpha blending
Got NEED_CONTEXT: gst.vaapi.app.Display from vaapi_dummy
Got HAVE_CONTEXT: gst.vaapi.Display from vaapi_dummy
Found display: vaapidisplaydrm1
New display: vaapidisplaydrm1
0:00:00.169431769 10690 0x55a6f745d230 FIXME default gstutils.c:4025:gst_pad_create_stream_id_internal:<videotestsrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
error: XDG_RUNTIME_DIR not set in the environment.
error: XDG_RUNTIME_DIR not set in the environment.
0:00:00.186637485 10690 0x55a6f745e0a0 FIXME default gstutils.c:4025:gst_pad_create_stream_id_internal:<videotestsrc1:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
Got NEED_CONTEXT: gst.vaapi.Display from enc
(gst_ctrl.py:10690): GStreamer-CRITICAL **: 09:34:46.751: gst_structure_free: assertion 'GST_STRUCTURE_REFCOUNT (structure) == NULL' failed
Got HAVE_CONTEXT: gst.vaapi.Display from enc
Found display: vaapidisplayglx0
Warning, we already have a VADisplay: vaapidisplaydrm1
0:00:00.245473554 10690 0x55a6f745df70 FIXME default gstutils.c:4025:gst_pad_create_stream_id_internal:<interpipesrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
End of stream from pipeline0
Got NEED_CONTEXT: gst.vaapi.Display from dec
(gst_ctrl.py:10690): GStreamer-CRITICAL **: 09:34:46.754: gst_structure_free: assertion 'GST_STRUCTURE_REFCOUNT (structure) == NULL' failed
Got NEED_CONTEXT: gst.gl.GLDisplay from dec
Got NEED_CONTEXT: gst.x11.display.handle from dec
Got NEED_CONTEXT: GstWaylandDisplayHandleContextType from dec
Got HAVE_CONTEXT: gst.gl.GLDisplay from dec
Got NEED_CONTEXT: gst.gl.app_context from dec
Got HAVE_CONTEXT: gst.vaapi.Display from dec
Found display: vaapidisplayx11-0
Warning, we already have a VADisplay: vaapidisplaydrm1
0:00:00.405237943 10690 0x55a6f745f9e0 WARN GST_CAPS gstpad.c:5701:pre_eventfunc_check:<vtest:sink> caps video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)high, level=(string)3.2, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt601, chroma-site=(string)jpeg, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true not accepted
0:00:00.405493743 10690 0x55a6f745e050 ERROR interpipesink gstinterpipesink.c:447:gst_inter_pipe_sink_get_caps:<vtest> Failed to obtain an intersection between upstream elements and listeners
0:00:00.405797199 10690 0x55a6f745f9e0 ERROR interpipesink gstinterpipesink.c:432:gst_inter_pipe_sink_get_caps:<vtest> Failed to obtain an intersection between listener caps
```
Am I missing something in how to properly set the `GstContext`/`VADisplay`?https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/304Auto-calculation of bitrate bricks Vaapi encoder when framerate=0/12021-09-24T12:23:31ZMarianna Smidth BuschleAuto-calculation of bitrate bricks Vaapi encoder when framerate=0/1Create a test file
```
GST_DEBUG=*:3 gst-launch-1.0 videotestsrc num-buffers=300 ! video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! vaapih264enc rate-control=4 bitrate=20000 ! video/x-h264,profile=high ! filesink location=...Create a test file
```
GST_DEBUG=*:3 gst-launch-1.0 videotestsrc num-buffers=300 ! video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! vaapih264enc rate-control=4 bitrate=20000 ! video/x-h264,profile=high ! filesink location=demo.h264
```
Transcode it: it works
```
GST_DEBUG=*:3 gst-launch-1.0 filesrc location=demo.h264 ! queue ! h264parse ! vaapih264dec ! queue ! "video/x-raw,format=NV12" ! queue ! vaapih264enc rate-control=4 bitrate=20000 ! video/x-h264,profile=high ! fakesink -v
```
Try to trasncode with automatic calculation of bitrate (`bitrate=0`): it stalls and leaves Vaapi in an un-usable state, requires reboot to recover.
```
GST_DEBUG=*:3 gst-launch-1.0 filesrc location=demo.h264 ! queue ! h264parse ! vaapih264dec ! queue ! "video/x-raw,format=NV12" ! queue ! vaapih264enc rate-control=4 bitrate=0 ! video/x-h264,profile=high ! fakesink -v
```
From https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/blob/master/gst-libs/gst/vaapi/gstvaapiencoder_h264.c#L2707
```
base_encoder->bitrate =
gst_util_uint64_scale (factor, GST_VAAPI_ENCODER_FPS_N (encoder),
GST_VAAPI_ENCODER_FPS_D (encoder)) / 1000;
```
So I guess the fps=0 gives a bitrate of zero which breaks the encoder badly.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/300Segfault in Intel video with all versions since somewhere after 1.14.42021-09-24T12:23:30ZAndré KjellstrupSegfault in Intel video with all versions since somewhere after 1.14.4Please see another great open project:
https://github.com/mavlink/qgroundcontrol/issues/9258#issuecomment-756635470
In short: gstreamer fails badly on Intel video using this application.Please see another great open project:
https://github.com/mavlink/qgroundcontrol/issues/9258#issuecomment-756635470
In short: gstreamer fails badly on Intel video using this application.