GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2018-11-07T12:57:36Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/112video format of endianness declared in vaapi need to be modified.2018-11-07T12:57:36ZBugzilla Migration Uservideo format of endianness declared in vaapi need to be modified.## Submitted by He Junyan
**[Link to original bug (#797359)](https://bugzilla.gnome.org/show_bug.cgi?id=797359)**
## Description
The code:
#elif G_BYTE_ORDER == G_LITTLE_ENDIAN
DEF_RGB (BGRA, ('B', 'G', 'R', 'A'), LSB, 32, ...## Submitted by He Junyan
**[Link to original bug (#797359)](https://bugzilla.gnome.org/show_bug.cgi?id=797359)**
## Description
The code:
#elif G_BYTE_ORDER == G_LITTLE_ENDIAN
DEF_RGB (BGRA, ('B', 'G', 'R', 'A'), LSB, 32,
32, 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000),
DEF_RGB (RGBA, ('R', 'G', 'B', 'A'), LSB, 32,
32, 0x000000ff, 0x0000ff00, 0x00ff0000, 0xff000000),
DEF_RGB (BGRx, ('B', 'G', 'R', 'X'), LSB, 32,
24, 0x00ff0000, 0x0000ff00, 0x000000ff, 0x00000000),
DEF_RGB (RGBx, ('R', 'G', 'B', 'X'), LSB, 32,
24, 0x000000ff, 0x0000ff00, 0x00ff0000, 0x00000000),
-#endif
Make the ARGB xRGB kind video format not suppored when on little endian machine like X86
The video format should not directly relate to endianness. For example,
ARGB on big endian should not be simplely seen as BGRA on little endian machine.
We should provide endianess convert or format convert help functions if endianness does not match.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/110vaapih265dec: [radeon] GStreamer fails to play HEVC video2021-09-24T12:23:16ZBugzilla Migration Uservaapih265dec: [radeon] GStreamer fails to play HEVC video## Submitted by Richard B. Kreckel
**[Link to original bug (#797312)](https://bugzilla.gnome.org/show_bug.cgi?id=797312)**
## Description
Created attachment 373979
Matroska file with x265 video where gst-launch-1.0 fails
The ...## Submitted by Richard B. Kreckel
**[Link to original bug (#797312)](https://bugzilla.gnome.org/show_bug.cgi?id=797312)**
## Description
Created attachment 373979
Matroska file with x265 video where gst-launch-1.0 fails
The attached 1s video plays fine with other players.
$ gst-launch-1.0 playbin uri=file:///data/scratch/das_boot.mkv
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapisink0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
Redistribute latency...
Got context from element 'playsink': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
Redistribute latency...
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0: Internal data stream error.
Additional debug info:
gstmultiqueue.c(2069): gst_multi_queue_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
**Attachment 373979**, "Matroska file with x265 video where gst-launch-1.0 fails":
[das_boot.mkv](/uploads/6bf6fbde9052dc8c86180f575e1c6d12/das_boot.mkv)
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/109vaapiencoder: Surface concurrency issues, failed to encode frame due to 'surf...2021-09-24T12:23:15ZBugzilla Migration Uservaapiencoder: Surface concurrency issues, failed to encode frame due to 'surface in use'## Submitted by Myles Inglis
**[Link to original bug (#797308)](https://bugzilla.gnome.org/show_bug.cgi?id=797308)**
## Description
Created attachment 373971
Add lock to gstvaapisurface patch
It seems that gstreamer-vaapi cur...## Submitted by Myles Inglis
**[Link to original bug (#797308)](https://bugzilla.gnome.org/show_bug.cgi?id=797308)**
## Description
Created attachment 373971
Add lock to gstvaapisurface patch
It seems that gstreamer-vaapi currently does not synchronise access to the vaapi surfaces correctly.
Attempting to use a VASurface while it is mapped (with vaMapBuffer) results in a surface is in use error from vaapi. This was causing an issue for us where one branch of the pipeline would map a GstBuffer and another branch of the pipeline would attempt to encode the buffer with the vaapiencoder while it is mapped. The result is that gstvaapiencoder fails to encode the buffer, and the whole pipeline is stopped.
I've attached the patch we have used to fix the issue. This adds a mutex to gstvaapisurface that is used to correctly synchronise access.
We're using a slightly older version of gstreamer but it doesn't seem like this has changed in the latest master.
**Patch 373971**, "Add lock to gstvaapisurface patch":
[0002-fix-va-surface-concurrency.patch](/uploads/239d543b4a935514127dae2f24f0beff/0002-fix-va-surface-concurrency.patch)
Version: 1.12.2https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/108vaapi: libs: bump libva version requirement2019-01-07T18:38:36ZBugzilla Migration Uservaapi: libs: bump libva version requirement## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#797196)](https://bugzilla.gnome.org/show_bug.cgi?id=797196)**
## Description
Nowadays the minimal requirement of VA-API version for gstremaer-vaapi is 0....## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#797196)](https://bugzilla.gnome.org/show_bug.cgi?id=797196)**
## Description
Nowadays the minimal requirement of VA-API version for gstremaer-vaapi is 0.30.4 (libva 1.0.0) which dates from 2009
Actually it is not currently tested that gstreamer-vaapi works with that ancient version.
ffmpeg requests 0.35.0 (libva 1.3.0) from 2014
mesa's state trackers requests 0.39.0 (libva 1.7.0) from 2016
libva-v4l2-request 0.34.0 (libva 1.2.0) from 2013
I would like to bump to 0.39, as mesa's state trackers, but also I would like to hear other opinions.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/107vaapih264dec: deadlock when PTS or DTS delta is zero2021-09-24T12:23:15ZBugzilla Migration Uservaapih264dec: deadlock when PTS or DTS delta is zero## Submitted by Matteo Valdina `@mvaldina`
**[Link to original bug (#797182)](https://bugzilla.gnome.org/show_bug.cgi?id=797182)**
## Description
Created attachment 373716
workaround for not exausing PROXY_SURFACE
Hi all,
T...## Submitted by Matteo Valdina `@mvaldina`
**[Link to original bug (#797182)](https://bugzilla.gnome.org/show_bug.cgi?id=797182)**
## Description
Created attachment 373716
workaround for not exausing PROXY_SURFACE
Hi all,
This is a nasty issue that I quite to be struggling to reproduce in a synthetic environment (aka gst-launch-1.0).
Here there is my trying to explain my understanding of the problem.
Scope gstvaapidecoder.c and gstvaapidecode.c
The main problem is a deadlock in the decoder due to an exhaustion of PROXY_SURFACE.
This means also stopping the pipeline or manipulating the pipeline will not work
The VAAPI decoder needs these buffers to continue the decoder and if there is no new buffer available will wait on a conditional variable until some PROXY_SURFACE are freed.
I noticed that the trigger of this issue is when a bugged stream () will force the decoder to produce a frame with PTS or DTS near identical in time to the previous frame. That means the gap between the previous PTS or previous DTS is 0.
My suspect is that there is a reference leak when we hit this condition and this cause the exhaustion of PROXY_SURFACE.
I work around the issue of detecting this condition in the push_frame and marking the frame as DECODE_ONLY.
When the frame is popped out during the gst_vaapidecode_push_decoded_frame I'll drop the frame with gst_video_decoder_drop_frame.
I believe that the easy way to reproduce the problem is programmatically generating this bug condition (0).
I can reproduce in my cases due to a looped stream from a remote source (via a network, RTP).
I reproduce the issue on the 1.14.3 and VAAPI 2.2.0.
Attaching the workaround to better understanding my poor explanation. Sorry about that.
Best
Matteo
**Patch 373716**, "workaround for not exausing PROXY_SURFACE":
[0001-vaapidecoder-workaround-for-hang-in-the-vaapi-decode.patch](/uploads/145a658eef84597a6971f3dec6c45a4c/0001-vaapidecoder-workaround-for-hang-in-the-vaapi-decode.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/106vaapidec: leak of dmabuf fds when transitioning from PLAYING to NULL state2022-03-25T19:07:18ZBugzilla Migration Uservaapidec: leak of dmabuf fds when transitioning from PLAYING to NULL state## Submitted by Sakari Kapanen
**[Link to original bug (#797152)](https://bugzilla.gnome.org/show_bug.cgi?id=797152)**
## Description
Created attachment 373668
Reproduction of the described issue
When a pipeline containing a ...## Submitted by Sakari Kapanen
**[Link to original bug (#797152)](https://bugzilla.gnome.org/show_bug.cgi?id=797152)**
## Description
Created attachment 373668
Reproduction of the described issue
When a pipeline containing a VAAPI decode element transitions from PLAYING to NULL state, it seems two dmabuf fds are leaked (when using EGL as the GL platform and dmabuf as the transfer mechanism from decode element to sink).
A minimal pipeline that reproduces the issue is the following:
videotestsrc ! x264enc ! video/x-h264 ! vaapih264dec ! video/x-raw(memory:DMABuf) ! fakesink
See the attached code which creates this pipeline and repeatedly sets it to PLAYING and NULL. Each time, the number of open dmabuf fds is printed. The output is as follows:
count of dmabuf fds: 0
setting pipeline state to PLAYING
count of dmabuf fds: 4
setting pipeline state to NULL
count of dmabuf fds: 2
setting pipeline state to PLAYING
count of dmabuf fds: 6
setting pipeline state to NULL
count of dmabuf fds: 4
setting pipeline state to PLAYING
count of dmabuf fds: 8
setting pipeline state to NULL
after exiting main loop
count of dmabuf fds: 6
after cleanup
count of dmabuf fds: 6
Each time the pipeline transitions to PLAYING, four dmabuf fds seem to be opened. When transitioning to NULL, only two are closed/freed. Additionally, when the program exits and the gstreamer elements are cleaned up (after three cycles), the fds still seem to be left open.
I have an application at hand where it is necessary to repeatedly stop and start the stream. This issue causes memory leakage and, eventually, program crashing due to too many open files. I have also tried to more gracefully stop the pipeline by sending an EOS event and only transitioning to NULL state after receiving the event on the pipeline's bus. However, the results are similar - leakage happens even then. Is there something regarding the dmabufs that has to be taken account during such transitions, or is this simply a bug in gstreamer-vaapi?
Even though the attached code uses a home-baked function that counts the open dmabuf fds, the behaviour can be verified by e.g. watching the output of lsof:
lsof -p $(pidof repro) | grep -c dmabuf
I would appreciate any input on how to resolve the issue (or if you can confirm it's an actual bug in gstreamer-vaapi or some other element).
At least the following elements exhibit the behaviour:
vaapih264dec
vaapih265dec
vaapivp8dec
Hardware:
Intel i5-8250U
Intel UHD Graphics 620
OS:
Arch Linux
gstreamer version 1.14.2
gstreamer-vaapi version 1.14.2
**Attachment 373668**, "Reproduction of the described issue":
[repro.c](/uploads/3eb01653a0e0b3530110636b3520ba23/repro.c)
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/105vaapipostproc: implement the negotiation of memory:DMABuf in sink pad2023-06-27T09:48:09ZBugzilla Migration Uservaapipostproc: implement the negotiation of memory:DMABuf in sink pad## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#797010)](https://bugzilla.gnome.org/show_bug.cgi?id=797010)**
## Description
In order to import tiled buffers vaapipostproc should negotiate memory:DMABU...## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#797010)](https://bugzilla.gnome.org/show_bug.cgi?id=797010)**
## Description
In order to import tiled buffers vaapipostproc should negotiate memory:DMABUf in its sink pad
For more information see:
https://lists.freedesktop.org/archives/gstreamer-devel/2018-August/068973.htmlhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/104vaapipostproc: add rotation feature2019-07-15T11:34:42ZBugzilla Migration Uservaapipostproc: add rotation feature## Submitted by wangfei `@wangfei`
**[Link to original bug (#796628)](https://bugzilla.gnome.org/show_bug.cgi?id=796628)**
## Description
This is an Intel feature requirement.
The Video driver will have a VPP input method for (...## Submitted by wangfei `@wangfei`
**[Link to original bug (#796628)](https://bugzilla.gnome.org/show_bug.cgi?id=796628)**
## Description
This is an Intel feature requirement.
The Video driver will have a VPP input method for (90, 180, 270 degrees) rotation.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/103vaapi: Add support for 422 decoding2018-11-13T09:09:33ZBugzilla Migration Uservaapi: Add support for 422 decoding## Submitted by wangfei `@wangfei`
**[Link to original bug (#796627)](https://bugzilla.gnome.org/show_bug.cgi?id=796627)**
## Description
This is an Intel feature requirement.
Supports higher quality render target in 422 (YUV)....## Submitted by wangfei `@wangfei`
**[Link to original bug (#796627)](https://bugzilla.gnome.org/show_bug.cgi?id=796627)**
## Description
This is an Intel feature requirement.
Supports higher quality render target in 422 (YUV). Apply to HEVC 8bit and 10bit decode, (M)JPEG decode and encode
### Depends on
* [Bug 797143](https://bugzilla.gnome.org/show_bug.cgi?id=797143)
* [Bug 797264](https://bugzilla.gnome.org/show_bug.cgi?id=797264)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/102vaapi: Add GEM buffer support2023-06-06T10:47:59ZBugzilla Migration Uservaapi: Add GEM buffer support## Submitted by wangfei `@wangfei`
**[Link to original bug (#796626)](https://bugzilla.gnome.org/show_bug.cgi?id=796626)**
## Description
This is an Intel feature requirement.
The video driver's vaCreateSurfaces2 driver entrypo...## Submitted by wangfei `@wangfei`
**[Link to original bug (#796626)](https://bugzilla.gnome.org/show_bug.cgi?id=796626)**
## Description
This is an Intel feature requirement.
The video driver's vaCreateSurfaces2 driver entrypoint shall accept a VASurfaceAttribMemoryType attribute value of VA_SURFACE_ATTRIB_MEM_TYPE_KERNEL_PRIME. This attribute will instruct the driver to use the buffer whose Prime file descriptor is stored in the VASurfaceAttribExternalBufferDescriptor as the backing buffer for the new VASurface.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/101vaapipostproc: Bob deinterlace doesn't work for raw file.2021-09-24T12:23:14ZBugzilla Migration Uservaapipostproc: Bob deinterlace doesn't work for raw file.## Submitted by wangfei `@wangfei`
**[Link to original bug (#796625)](https://bugzilla.gnome.org/show_bug.cgi?id=796625)**
## Description
$gst-launch-1.0 -vf filesrc location=1920x1080.nv12 num-buffers=1 ! rawvideoparse format=nv12 ...## Submitted by wangfei `@wangfei`
**[Link to original bug (#796625)](https://bugzilla.gnome.org/show_bug.cgi?id=796625)**
## Description
$gst-launch-1.0 -vf filesrc location=1920x1080.nv12 num-buffers=1 ! rawvideoparse format=nv12 width=1920 height=1080 ! vaapipostproc format=nv12 width=1920 height=1080 deinterlace-mode=1 deinterlace-method=bob ! checksumsink2 file-checksum=false frame-checksum=false plane-checksum=false dump-output=true dump-location=bob_NV12_1920x1080.yuv
The output yuv have 2 frames, and each frame is bit match with input.
But by using yamivpp:
$yamivpp --di bob 1920x1080.nv12 1920x1080.bob.nv12
the output only 1 frame, and md5 is different with input.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/100vaapi: Scrambled rendering for some h.264 videos with glimagesink on AMD GPU2019-05-15T16:29:54ZBugzilla Migration Uservaapi: Scrambled rendering for some h.264 videos with glimagesink on AMD GPU## Submitted by Philippe Normand `@philn`
**[Link to original bug (#796584)](https://bugzilla.gnome.org/show_bug.cgi?id=796584)**
## Description
vainfo:
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns ...## Submitted by Philippe Normand `@philn`
**[Link to original bug (#796584)](https://bugzilla.gnome.org/show_bug.cgi?id=796584)**
## Description
vainfo:
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_1
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.1 (libva 2.1.0)
vainfo: Driver version: mesa gallium vaapi
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
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
Scrambled rendering with: https://download.blender.org/durian/trailer/Sintel_Trailer.480p.DivX_Plus_HD.mkv
No rendering issue with: https://trac.webkit.org/export/232834/webkit/trunk/LayoutTests/media/content/test.mp4https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/99vaapiencoder: (baseclass): wrap in a while loop g_cond_wait() as documented2021-09-24T12:23:13ZBugzilla Migration Uservaapiencoder: (baseclass): wrap in a while loop g_cond_wait() as documented## Submitted by Ahmed K
**[Link to original bug (#796539)](https://bugzilla.gnome.org/show_bug.cgi?id=796539)**
## Description
Created attachment 372602
Screenshot of gstreamer's log
I developed streaming application with gst...## Submitted by Ahmed K
**[Link to original bug (#796539)](https://bugzilla.gnome.org/show_bug.cgi?id=796539)**
## Description
Created attachment 372602
Screenshot of gstreamer's log
I developed streaming application with gstreamer-1.10.4 and used vaapi to accelerate decoding/encoding. It streams video encoded to ts stream with h264 format.
But streaming stops after random period of time when it is started.
Constantly I get error gst_vaapi_encoder_put_frame: failed to allocate coded buffer and gst_vaapiencode_handle_frame: failed to encode frame xxx (status -2).
After some debugging I found the reason for this. It seems that problem is in gst_vaapi_encoder_create_coded_buffer function in gstvaapiencoder.c.
In this line g_cond_wait (&encoder->codedbuf_free, &encoder->mutex); should be placed in loop as spurious wakeup can occur. This is explained in glib documentation: https://developer.gnome.org/glib/stable/glib-Threads.html#g-cond-wait .
I putted g_cond_wait with codedbuf_proxy check in a loop and forced it to retry and wait for the buffer to be available. Then I recompilled gstreamer-vaapi. Now it works perfectly without stopping.
I can submit a patch on request.
**Attachment 372602**, "Screenshot of gstreamer's log":
![scrshot](/uploads/6e171fcfe997183fe38a71622ff4ba06/scrshot.png)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/98vaapih265dec: segfault when it starts to decode a delta frame2021-01-04T11:08:56ZBugzilla Migration Uservaapih265dec: segfault when it starts to decode a delta frame## Submitted by James Stevenson
**[Link to original bug (#796513)](https://bugzilla.gnome.org/show_bug.cgi?id=796513)**
## Description
vaapih265dec crashes with an assert failure if stream does not start on keyframe in the i965 driv...## Submitted by James Stevenson
**[Link to original bug (#796513)](https://bugzilla.gnome.org/show_bug.cgi?id=796513)**
## Description
vaapih265dec crashes with an assert failure if stream does not start on keyframe in the i965 driver.
gst-launch-1.0: gen9_mfd.c:649: gen9_hcpd_get_reference_picture_frame_id: Assertion `0' failed.
```
#0 0x00007f13ff38fe97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f13ff391801 in __GI_abort () at abort.c:79
#2 0x00007f13ff38139a in __assert_fail_base (fmt=0x7f13ff5087d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f13be775b4c "0", file=file@entry=0x7f13be46bdf0 "gen9_mfd.c", line=line@entry=649, function=function@entry=0x7f13be46c500 "gen9_hcpd_get_reference_picture_frame_id") at assert.c:92
#3 0x00007f13ff381412 in __GI___assert_fail (assertion=0x7f13be775b4c "0", file=0x7f13be46bdf0 "gen9_mfd.c", line=649, function=0x7f13be46c500 "gen9_hcpd_get_reference_picture_frame_id") at assert.c:101
#4 0x00007f13be334b41 in () at /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
#5 0x00007f13be33649b in () at /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
#6 0x00007f13d471c820 in vaEndPicture () at /usr/lib/x86_64-linux-gnu/libva.so.2
#7 0x00007f13f0507dd3 in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so
#8 0x00007f13f051fb5d in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so
#9 0x00007f13f04fa643 in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so
#10 0x00007f13f04dec52 in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so
#11 0x00007f13fbde4b81 in gst_video_decoder_decode_frame (decoder=decoder@entry=0x7f13c40761a0, frame=0x55dd7e987df0) at gstvideodecoder.c:3416
#12 0x00007f13fbded16f in gst_video_decoder_have_frame (decoder=0x7f13c40761a0) at gstvideodecoder.c:3348
#13 0x00007f13f04dd81a in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so
#14 0x00007f13fbde4d43 in gst_video_decoder_parse_available (dec=dec@entry=0x7f13c40761a0, at_eos=at_eos@entry=0, new_buffer=0, new_buffer@entry=1) at gstvideodecoder.c:882
#15 0x00007f13fbde770c in gst_video_decoder_chain_forward (decoder=decoder@entry=0x7f13c40761a0, buf=buf@entry=0x55dd7e987ce0, at_eos=at_eos@entry=0) at gstvideodecoder.c:2158
#16 0x00007f13fbde7d52 in gst_video_decoder_chain (pad=<optimised out>, parent=0x7f13c40761a0, buf=0x55dd7e987ce0) at gstvideodecoder.c:2456
#17 0x00007f13fff4146b in gst_pad_chain_data_unchecked (data=0x55dd7e987ce0, type=4112, pad=0x7f13c8024fa0) at gstpad.c:4279
#18 0x00007f13fff4146b in gst_pad_push_data (pad=pad@entry=0x55dd7e9b7b20, type=type@entry=4112, data=data@entry=0x55dd7e987ce0) at gstpad.c:4535
#19 0x00007f13fff497a3 in gst_pad_push (pad=pad@entry=0x55dd7e9b7b20, buffer=buffer@entry=0x55dd7e987ce0) at gstpad.c:4654
#20 0x00007f13fff2f91b in gst_proxy_pad_chain_default (pad=<optimised out>, parent=<optimised out>, buffer=0x55dd7e987ce0) at gstghostpad.c:127
#21 0x00007f13fff4146b in gst_pad_chain_data_unchecked (data=0x55dd7e987ce0, type=4112, pad=0x55dd7e9b3970) at gstpad.c:4279
#22 0x00007f13fff4146b in gst_pad_push_data (pad=pad@entry=0x7f13c8024d50, type=type@entry=4112, data=data@entry=0x55dd7e987ce0) at gstpad.c:4535
```
Example pipeline I am using. I the identity shows the first frame as a delta when the crash happens. However if the first frame is a keyframe it will work correctly deocde and play video.
GST_DEBUG=3 gst-launch-1.0 -v rtspsrc location=<redacted> ! rtph265depay ! h265parse ! identity silent=false ! decodebin ! videoconvert ! xvimagesink
Should the parser not drop data from the stream until a keyframe has passed? I also tried with "h265parse disable-passthrough=true" to try to enable this.
Same video source under both conditions (keyframe/delta as first frame) works fine with the avdec_h265 decoder.
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/97vaapi{h264,h265}enc: Missing frames when encode with B frames from YUV file a...2019-01-16T06:17:26ZBugzilla Migration Uservaapi{h264,h265}enc: Missing frames when encode with B frames from YUV file and num-buffers specified## Submitted by Ullysses A Eoff `@ullysses.a.eoff`
**[Link to original bug (#796495)](https://bugzilla.gnome.org/show_bug.cgi?id=796495)**
## Description
When filesrc num-buffers=N is specified in encode pipeline for vaapi encode an...## Submitted by Ullysses A Eoff `@ullysses.a.eoff`
**[Link to original bug (#796495)](https://bugzilla.gnome.org/show_bug.cgi?id=796495)**
## Description
When filesrc num-buffers=N is specified in encode pipeline for vaapi encode and max-bframes > 0, the resulting encoded video does not contain N frames.
1. Generate 100-frame YUV file:
$ gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw,format=NV12,width=1920,height=1080 ! filesink location=./test.yuv
2. Encode 90 frames from previous YUV output file:
$ gst-launch-1.0 filesrc location=test.yuv num-buffers=90 ! rawvideoparse format=nv12 width=1920 height=1080 ! vaapih264enc rate-control=cbr bitrate=5000 keyframe-period=30 num-slices=4 max-bframes=2 ! h264parse ! filesink location=./test.h264
...the resulting file, test.h264 only contains 88 frames, which is NOT expected.
3. If we switch the encoder to msdkh264enc:
gst-launch-1.0 filesrc location=test.yuv num-buffers=90 ! rawvideoparse format=nv12 width=1920 height=1080 ! msdkh264enc rate-control=cbr bitrate=5000 gop-size=30 num-slices=4 b-frames=2 ! h264parse ! filesink location=./test.h264
...the resulting file contains the requested 90 frames, which is expected.
Other encoders like ffmpeg and yami output the correct number of frames. Thus, only gstreamer-vaapi encoders (all encoders that support b-frames) exhibit the incorrect number of frames in encoded output.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/96vaapi: gobjectify internal classes2023-06-06T10:40:50ZBugzilla Migration Uservaapi: gobjectify internal classes## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#796308)](https://bugzilla.gnome.org/show_bug.cgi?id=796308)**
## Description
gobjectivy internal decoder class and its derivate classes## Submitted by Víctor Manuel Jáquez Leal `@vjaquez`
**[Link to original bug (#796308)](https://bugzilla.gnome.org/show_bug.cgi?id=796308)**
## Description
gobjectivy internal decoder class and its derivate classeshttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/95Totem window is all black in Wayland sessions on Sandy Bridge (and Clarkdale)...2021-09-24T12:23:13ZBugzilla Migration UserTotem window is all black in Wayland sessions on Sandy Bridge (and Clarkdale) CPUs## Submitted by Cristian Aravena Romero `@caravena`
**[Link to original bug (#796033)](https://bugzilla.gnome.org/show_bug.cgi?id=796033)**
## Description
Hello,
Open bug in launchpad.net
https://bugs.launchpad.net/bugs/17707...## Submitted by Cristian Aravena Romero `@caravena`
**[Link to original bug (#796033)](https://bugzilla.gnome.org/show_bug.cgi?id=796033)**
## Description
Hello,
Open bug in launchpad.net
https://bugs.launchpad.net/bugs/1770725
Regards,
--
Cristian Aravena Romero (caravena)
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/94vaapih264dec: hangs when decoding a defect stream2020-07-08T10:38:42ZBugzilla Migration Uservaapih264dec: hangs when decoding a defect stream## Submitted by Thomas Scheuermann
**[Link to original bug (#795770)](https://bugzilla.gnome.org/show_bug.cgi?id=795770)**
## Description
If a defective stream is decoded by gstreamer with vaapi, the pipeline hangs and can't be stop...## Submitted by Thomas Scheuermann
**[Link to original bug (#795770)](https://bugzilla.gnome.org/show_bug.cgi?id=795770)**
## Description
If a defective stream is decoded by gstreamer with vaapi, the pipeline hangs and can't be stopped anymore with setting the pipeline state to GST_STATE_NULL. This call will block forever.
A pcap stream to reproduce this can be found here:
https://barcozone-my.sharepoint.com/:u:/g/personal/thomas_scheuermann_barco_com/EQ8TkhCtzEpFoc3RkFzcpBoBZTxhPF1xERHu6XwFhMwBpQ?e=NhTqE0
The pcap file can be played with
sudo tcpreplay-edit -l 0 -i `<network interface>` --pnat=172.23.0.26:`<local address>`,172.20.51.163:`<remote address>` --enet-dmac=`<remote mac>` gstlock2.pcap
The pipeline can be started the following way:
gst-launch-1.0 udpsrc uri="udp://0.0.0.0:34338" ! application/x-rtp,encoding-name=H264 ! rtph264depay ! h264parse ! vaapih264dec ! vaapisink
The pipeline doesn't hang if avdec_h264 is used.
Regards,
Thomas
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/93vaapi encoding requires stream-format=byte-stream on radeonsi since 1.142021-09-24T12:23:12ZBugzilla Migration Uservaapi encoding requires stream-format=byte-stream on radeonsi since 1.14## Submitted by Christoph Haag
**[Link to original bug (#795372)](https://bugzilla.gnome.org/show_bug.cgi?id=795372)**
## Description
RX 480, latest mesa git.
Since gstreamer 1.14 a simple vaapi encoding pipeline that has been wor...## Submitted by Christoph Haag
**[Link to original bug (#795372)](https://bugzilla.gnome.org/show_bug.cgi?id=795372)**
## Description
RX 480, latest mesa git.
Since gstreamer 1.14 a simple vaapi encoding pipeline that has been working on 1.12.4 never starts encoding and produces a 0 byte output file when pressing ctrl+c:
$ LANG=en gst-launch-1.0 videotestsrc ! vaapih264enc ! "video/x-h264,profile=baseline" ! h264parse ! matroskamux ! filesink location=output.mkv
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapiencodeh264-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
`^`Chandling interrupt.
Interrupt: Stopping pipeline ...
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
`^`C
I was told this is something that should be reported, so here it is.
The workaround for now is to specify stream-format=byte-stream yourself, like this:
gst-launch-1.0 videotestsrc ! vaapih264enc ! "video/x-h264,profile=baseline,stream-format=byte-stream" ! h264parse ! matroskamux ! filesink location=output.mkv
this pipeline works fine with gstreamer 1.14.
The same is true for an equivalent h.265 pipeline:
gst-launch-1.0 videotestsrc ! vaapih265enc ! "video/x-h265,stream-format=byte-stream" ! h265parse ! matroskamux ! filesink location=output.mkv
Bugzilla shows a few other issues that may be relevant, for example maybe [bug 732167](https://bugzilla.gnome.org/show_bug.cgi?id=732167).
Version: 1.14.0
### See also
* [Bug 795340](https://bugzilla.gnome.org/show_bug.cgi?id=795340)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/92gstreamer-vaapi stutters heavily when rendering (some videos) to GLX2021-09-24T12:23:12ZBugzilla Migration Usergstreamer-vaapi stutters heavily when rendering (some videos) to GLX## Submitted by Daniel van Vugt `@vanvugt`
**[Link to original bug (#795325)](https://bugzilla.gnome.org/show_bug.cgi?id=795325)**
## Description
gstreamer-vaapi stutters heavily when rendering (some videos) to GLX.
STUTTERY: ...## Submitted by Daniel van Vugt `@vanvugt`
**[Link to original bug (#795325)](https://bugzilla.gnome.org/show_bug.cgi?id=795325)**
## Description
gstreamer-vaapi stutters heavily when rendering (some videos) to GLX.
STUTTERY:
env GST_GL_PLATFORM=glx gst-launch-1.0 filesrc location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin ! glimagesink
SMOOTH:
env GST_GL_PLATFORM=egl gst-launch-1.0 filesrc location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin ! glimagesink
Interestingly, GLX is even slower than software rendering (ximagesink):
STUTTERY:
env GST_GL_PLATFORM=glx gst-launch-1.0 filesrc location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin ! glimagesink
SMOOTH:
env GST_GL_PLATFORM=glx gst-launch-1.0 filesrc location=bbb_sunflower_2160p_60fps_normal.mp4 ! qtdemux ! vaapidecodebin ! ximagesink
### See also
* https://launchpad.net/bugs/1698270