GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-03-02T06:30:43Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/980Set NULL state to queue results in deadlock2022-03-02T06:30:43ZMatteo FoglioSet NULL state to queue results in deadlockI am working on the attached pipeline created using the Python interface for Gstreamer. The pipeline uses some plugins from Nvidia Deepstream, but I believe the issue I am having in unrelated.
In brief: the pipeline ingests some rtsp v...I am working on the attached pipeline created using the Python interface for Gstreamer. The pipeline uses some plugins from Nvidia Deepstream, but I believe the issue I am having in unrelated.
In brief: the pipeline ingests some rtsp video streams, put them into a leaky queue, and then it sends the frames to some Deepstream custom plugins that will run some AI models on them (but I suspect Deepstream plugins are probably not important for this issue).
Sometime I need to stop processing a video frame. Therefore, I want to remove the elements in charge of processing the stream. Suppose I want to stop stream number `50` (first row in the pipeline attached). I'll start by setting its elements' state to `NULL`. What I do is the following:
- I set to `NULL` the state of the `GstBin` called `source-bin-50` (see pipeline). This bin contains the elements that decode the rtsp video stream.
- I set to `NULL` the state of the `queue` called `frame_queue_50`. The problem is that this sometime results in a deadlock during the the `set_state` function.
I read online that the issue could be caused by the queue still having some content and therefore not willing to move to `NULL` state. However, as of now, I haven't found a solution. Should I send any signal to the `queue`?
[pipeline.pdf](/uploads/c9cc089731f8ff3b1e478908a3b474a0/pipeline.pdf)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/981compositor pipeline does not start when used with shmsink/shmsrc but works fi...2022-03-06T21:51:49ZMarc Schmittcompositor pipeline does not start when used with shmsink/shmsrc but works fine with videomixer### Describe your issue
Following the documentation at https://gstreamer.freedesktop.org/documentation/videomixer/index.html, which says "videomixer is deprecated in favor of compositor, please do not use this element in newly-written c...### Describe your issue
Following the documentation at https://gstreamer.freedesktop.org/documentation/videomixer/index.html, which says "videomixer is deprecated in favor of compositor, please do not use this element in newly-written code!", I started my project using compositor and spent ours trying to get a simple pipleline to run which involves two shmsrc as input. When I replace the word `compositor` with `videomixer`, it works like a charm.
#### Expected Behavior
I expected the compositor to be a drop-in replacement for videomixer.
#### Observed Behavior
Using `compositor`, the pipeline cannot start. Running with `GST_DEBUG=5`, I can see that the queues are running full as if the compositor is not able to write to the shmsink.
#### Setup
- **Operating System:** Debian Linux (but the same happens under Ubuntu 20.04).
- **Device:** Computer
- **GStreamer Version:** 1.18.5
- **Command line:** bash
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. run the following script (SOURCE_CAPS might need to be updated based on your gstreamer version):
```
#!/bin/bash
rm -rf "/tmp/1.$$" "/tmp/2.$$" "/tmp/3.$$"
SOURCE_CAPS='video/x-raw, format=(string)AYUV64, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive'
gst-launch-1.0 videotestsrc pattern=0 is-live=1 ! shmsink socket-path="/tmp/1.$$" wait-for-connection=0 >/dev/null 2>&1 &
gst-launch-1.0 videotestsrc pattern=1 is-live=1 ! shmsink socket-path="/tmp/2.$$" wait-for-connection=0 >/dev/null 2>&1 &
gst-launch-1.0 -v \
compositor name=compositor sink_1::alpha=0.5 ! shmsink name=compositor_sink socket-path="/tmp/3.$$" wait-for-connection=0 \
shmsrc name=shmsrc1 socket-path="/tmp/1.$$" do-timestamp=1 is-live=1 ! queue name=queue1 ! ${SOURCE_CAPS} ! videoconvert ! compositor. \
shmsrc name=shmsrc2 socket-path="/tmp/2.$$" do-timestamp=1 is-live=1 ! queue name=queue2 ! ${SOURCE_CAPS} ! videoconvert ! compositor.
```
Now edit the script and replace all occurrences of `compositor` with `videomixer` and it will work just fine.
### How reproducible is the bug?
Always
### Solutions you have tried
I've spend hours and hours trying many options until I thought let's just give `videomixer` a try to see if it makes a difference and it did.
### Additional Information
Running with `GST_DEBUG=5`, this is where we can see the queues running full:
```
0:00:01.039095542 171777 0x56132e6c3980 DEBUG queue_dataflow gstqueue.c:1243:gst_queue_chain_buffer_or_list:<queue1> queue is full, waiting for free space
0:00:01.040241901 171777 0x56132e6c39e0 DEBUG GST_POLL gstpoll.c:1195:gst_poll_fd_has_closed: 0x56132e4ab370: fd (fd:17, idx:1) 0
0:00:01.040342770 171777 0x56132e6c39e0 DEBUG GST_POLL gstpoll.c:1241:gst_poll_fd_has_error: 0x56132e4ab370: fd (fd:17, idx:1) 0
0:00:01.040393248 171777 0x56132e6c39e0 DEBUG GST_POLL gstpoll.c:1266:gst_poll_fd_can_read_unlocked: 0x56132e4ab370: fd (fd:17, idx:1) 1
0:00:01.040465808 171777 0x56132e6c39e0 DEBUG GST_MEMORY gstmemory.c:139:gst_memory_init: new memory 0x7f4b2400c570, maxsize:614400 offset:0 size:614400
0:00:01.040530354 171777 0x56132e6c39e0 DEBUG GST_CLOCK gstclock.c:1091:gst_clock_get_internal_time:<GstSystemClock> internal time 10:07:36.148975789
0:00:01.040565704 171777 0x56132e6c39e0 DEBUG GST_CLOCK gstclock.c:1136:gst_clock_get_time:<GstSystemClock> adjusted time 10:07:36.148975789
0:00:01.040589355 171777 0x56132e6c39e0 DEBUG basesrc gstbasesrc.c:2435:gst_base_src_do_sync:<shmsrc2> no sync needed
0:00:01.040611720 171777 0x56132e6c39e0 DEBUG basesrc gstbasesrc.c:2672:gst_base_src_get_range:<shmsrc2> buffer ok
0:00:01.040653863 171777 0x56132e6c39e0 DEBUG GST_SCHEDULING gstpad.c:4400:gst_pad_chain_data_unchecked:<queue2:sink> calling chainfunction &gst_queue_chain with buffer buffer: 0x7f4b2400d000, pts 0:00:00.717607129, dts 0:00:00.717607129, dur 99:99:99.999999999, size 614400, offset none, offset_end none, flags 0x0
0:00:01.040690438 171777 0x56132e6c39e0 DEBUG GST_SCHEDULING gstpad.c:4406:gst_pad_chain_data_unchecked:<queue2:sink> called chainfunction &gst_queue_chain with buffer 0x7f4b2400d000, returned ok
0:00:01.040720763 171777 0x56132e6c39e0 DEBUG basesrc gstbasesrc.c:2579:gst_base_src_get_range:<shmsrc2> calling create offset 18446744073709551615 length 4096, time 0
0:00:01.040743159 171777 0x56132e6c39e0 DEBUG shmsrc gstshmsrc.c:330:gst_shm_src_create:<shmsrc2> Stopping 0x56132e6a04f0
0:00:01.040769446 171777 0x56132e6c39e0 DEBUG GST_POLL gstpoll.c:1414:gst_poll_wait: 0x56132e4ab370: timeout :99:99:99.999999999
0:00:01.073598351 171777 0x56132e6c39e0 DEBUG GST_POLL gstpoll.c:1195:gst_poll_fd_has_closed: 0x56132e4ab370: fd (fd:17, idx:1) 0
0:00:01.074145071 171777 0x56132e6c39e0 DEBUG GST_POLL gstpoll.c:1241:gst_poll_fd_has_error: 0x56132e4ab370: fd (fd:17, idx:1) 0
0:00:01.074449183 171777 0x56132e6c39e0 DEBUG GST_POLL gstpoll.c:1266:gst_poll_fd_can_read_unlocked: 0x56132e4ab370: fd (fd:17, idx:1) 1
0:00:01.074542975 171777 0x56132e6c39e0 DEBUG GST_MEMORY gstmemory.c:139:gst_memory_init: new memory 0x7f4b2400c600, maxsize:614400 offset:0 size:614400
0:00:01.074595430 171777 0x56132e6c39e0 DEBUG GST_CLOCK gstclock.c:1091:gst_clock_get_internal_time:<GstSystemClock> internal time 10:07:36.183041753
0:00:01.074622038 171777 0x56132e6c39e0 DEBUG GST_CLOCK gstclock.c:1136:gst_clock_get_time:<GstSystemClock> adjusted time 10:07:36.183041753
0:00:01.074650367 171777 0x56132e6c39e0 DEBUG basesrc gstbasesrc.c:2435:gst_base_src_do_sync:<shmsrc2> no sync needed
0:00:01.074673239 171777 0x56132e6c39e0 DEBUG basesrc gstbasesrc.c:2672:gst_base_src_get_range:<shmsrc2> buffer ok
0:00:01.074718326 171777 0x56132e6c39e0 DEBUG GST_SCHEDULING gstpad.c:4400:gst_pad_chain_data_unchecked:<queue2:sink> calling chainfunction &gst_queue_chain with buffer buffer: 0x7f4b2400d120, pts 0:00:00.751673093, dts 0:00:00.751673093, dur 99:99:99.999999999, size 614400, offset none, offset_end none, flags 0x0
0:00:01.074752665 171777 0x56132e6c39e0 DEBUG queue_dataflow gstqueue.c:1243:gst_queue_chain_buffer_or_list:<queue2> queue is full, waiting for free space
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/983gst-plugins-good/gtk: Document how to "draw black"2022-02-01T13:58:36ZBastien Noceragst-plugins-good/gtk: Document how to "draw black"`GstGtkBaseSink` will `_draw_black()` when GL or the windowing system isn't completely initialised, but there doesn't seem to be a way to force the sink to drop all of its known texture to draw black after having displayed video.
In tot...`GstGtkBaseSink` will `_draw_black()` when GL or the windowing system isn't completely initialised, but there doesn't seem to be a way to force the sink to drop all of its known texture to draw black after having displayed video.
In totem, this happens when open and playing back video `1`, coming back to the library with Ctrl+W or the back button (this will close the file and set the pipeline to `GST_STATE_READY`), and selecting another video. The original video will be visible for a couple of frames, enough to clearly be visible.
(This was already a problem with clutter-gst: https://gitlab.gnome.org/GNOME/totem/-/issues/105)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/989macos: unstable devenv when a version is already installed via brew2023-01-10T08:58:17ZStéphane Cerveauscerveau@igalia.commacos: unstable devenv when a version is already installed via brew### Describe your issue
If a Gstreamer version is already installed via [brew](https://brew.sh/). The devenv is unstable seen that DYLD_LIBRARY_PATH is discarded for security reason.
When I check the logs, I see that the plugin is 1.19,...### Describe your issue
If a Gstreamer version is already installed via [brew](https://brew.sh/). The devenv is unstable seen that DYLD_LIBRARY_PATH is discarded for security reason.
When I check the logs, I see that the plugin is 1.19, Gstreamer is 1.18. Plugin is blacklisted.
#### Expected Behavior
To have a stable devenv using the plugins/library from Gstreamer build directory
#### Observed Behavior
When I check the logs, I see that the plugin is 1.19, Gstreamer is 1.18. Plugin is blacklisted.
#### Setup
- **Operating System:** MacOs Catalina
- **Device:** Computer
- **GStreamer Version:** 1.19.90
- **Command line:** ninja -C build devenv
### Steps to reproduce the bug
$$ install gstreamer via brew (version inferior to the current dev version)
$ meson builddir
$ ninja -C builddir
$ ninja -C buiddir devenv
$ gst-inspect autovideosink
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
Uninstall gstreamer from brew
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/992Subproject libdrm fails the build when --wrap-mode=forcefallback is used2022-11-10T09:21:10ZErik De RijckeSubproject libdrm fails the build when --wrap-mode=forcefallback is usedWhen building with `--wrap-mode=forcefallback`, meson fails to properly build libdrm even though all required dependencies seem to be satisfied.
```
meson build \
--buildtype=release \
--default-library=static \
...When building with `--wrap-mode=forcefallback`, meson fails to properly build libdrm even though all required dependencies seem to be satisfied.
```
meson build \
--buildtype=release \
--default-library=static \
--wrap-mode=forcefallback \
-Dgpl=enabled \
-Dorc=enabled \
-Dbase=enabled \
-Dgood=enabled \
-Dbad=enabled \
-Dugly=enabled \
-Dauto_features=disabled \
-Dgst-plugins-base:gl=enabled \
-Dgst-plugins-base:videoconvert=enabled \
-Dgst-plugins-base:app=enabled \
-Dgst-plugins-base:gl_winsys=egl,gbm \
-Dgst-plugins-base:gl_api=opengl \
-Dgst-plugins-good:videobox=enabled \
-Dgst-plugins-good:png=enabled \
-Dgst-plugins-bad:gl=enabled \
-Dgst-plugins-bad:nvcodec=enabled \
-Dgst-plugins-ugly:x264=enabled
```
[meson-output.txt](/uploads/5ec3f4be26994db49c34e270caf27fdf/meson-output.txt)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/993Some id3 tags repeated2022-11-10T09:21:10ZAustin ButlerSome id3 tags repeated### Describe your issue
Running `gst-discoverer-1.0 -v my_file.mp3` results in the `artist`, `album`, and `genre` tags showing repetition.
Other applications, such as `ffprobe`, do not have the same issue.
```
artist: William Elliott ...### Describe your issue
Running `gst-discoverer-1.0 -v my_file.mp3` results in the `artist`, `album`, and `genre` tags showing repetition.
Other applications, such as `ffprobe`, do not have the same issue.
```
artist: William Elliott Whitmore & Jenny Hoyston, Jenny Hoyston and William Whitmore, Jenny Hoyston and William Whitmore, Jenny Hoyston and William Whitmore, Jenny Hoyston and William Whitmore
album: Hallways Of Always, Hallways Of Allways, Hallways Of Allways, Hallways Of Allways, Hallways Of Allways
genre: Country, Folk, Folk, Folk, Folk
```
#### Expected Behavior
Tags are "normal" like in other ID3 readers.
#### Observed Behavior
Certain tag values are repeated multiple times.
#### Setup
- **Operating System:** NixOS
- **Device:** Computer
- **GStreamer Version:** 1.18.5
- **Command line:** gst-discoverer-1.0 -v my_file.mp3
### Steps to reproduce the bug
1. open terminal
2. type `gst-discoverer-1.0 -v my_file.mp3`
### How reproducible is the bug?
100%
### Solutions you have tried
I'm able to fix the file by running `mp3val -f my_file.mp3` on it.
### Additional Information
I can't provide the files directly due to copyright, but if you're interested I can probably extract the tags if you're able to guide me a bit. It's easy enough for _me_ to fix the files now that I know a workaround, but for users of applications like Lollypop that use GStreamer and don't offer tag editing, it's hard to fix. I tried a number of other tag editors and none of them repro'd this issue.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/-/issues/998nvcodec messes up the aspect resolution for different SAR and DAR values2022-02-05T23:57:27ZGuru Govindannvcodec messes up the aspect resolution for different SAR and DAR values### Describe your issue
When the SAR/DAR values are very high, the nvcodecs seems to change the aspect ratio of the video.
I have a video segment which has a high SAR/DAR values. The sw and intel transcodes seems to handle it properly. ...### Describe your issue
When the SAR/DAR values are very high, the nvcodecs seems to change the aspect ratio of the video.
I have a video segment which has a high SAR/DAR values. The sw and intel transcodes seems to handle it properly. However nvcodecs seems to change aspect ration from 16/9 to 4/3. Also the SAR values seems to be flipped or sometimes completely messes up the video.
The following is the SAR/DAR values of the ts segment I am trying to transcode.
```
Stream #0:0[0x41]: Video: h264 (High) (HDMV / 0x564D4448), yuvj420p(pc, bt709, progressive), 480x270 [SAR 46892:45837 DAR 750272:412533], 15 fps, 25 tbr, 90k tbn, 30 tbc
```
After the nvcodec transcode the SAR/DAR values are as follows
```
Stream #0:0[0x41]: Video: h264 (HDMV / 0x564D4448), yuvj420p(pc, bt709, progressive), 1920x1086 [SAR 62959:17280 DAR 62959:9774], 15 fps, 15 tbr, 90k tbn, 30 tbc
```
I am using the following pipeline to transcode it
```
gst-launch-1.0 filesrc location="high_sar_values.ts" ! tsdemux ! queue ! h264parse ! nvh264dec ! videorate ! videoscale ! video/x-raw,width=1920,height=1086,framerate=15/1 ! nvh264enc ! mpegtsmux ! filesink location="output_gst.ts"
```
#### Expected Behavior
It should retain the aspect ratio similar to software transcodes.
#### Observed Behavior
It changes the Aspect ratio to 4:3 or other unviewable strip. The resulting SAR and DAR values dont match the original ratios.
#### Setup
- **Operating System:** Ubuntu 20.04
- **GStreamer Version:** 18.04
- **Command line:**
```
gst-launch-1.0 filesrc location="high_sar_orig.ts" ! tsdemux ! queue ! h264parse ! nvh264dec ! videorate ! videoscale ! video/x-raw,width=1920,height=1086,framerate=15/1 ! nvh264enc ! mpegtsmux ! filesink location="output_gst.ts"
```
### Steps to reproduce the bug
1. open terminal
2. type ```
gst-launch-1.0 filesrc location="high_sar_orig.ts" ! tsdemux ! queue ! h264parse ! nvh264dec ! videorate ! videoscale ! video/x-raw,width=1920,height=1086,framerate=15/1 ! nvh264enc ! mpegtsmux ! filesink location="output_gst.ts"
```
3. Play the output_gst.ts
### How reproducible is the bug?
Happens everytime.
[high_sar_orig.ts](/uploads/e7ca4858f886795b0b99c085de147c09/high_sar_orig.ts)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/999av1parse: Parse colorimetry, mastering display metadata, content light level ...2022-02-07T14:02:59ZSebastian Drögeav1parse: Parse colorimetry, mastering display metadata, content light level metadata from bitstream if not provided by upstreamhttps://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/9Build failure with `-Dc_std=c11`2022-02-07T04:10:11ZLászló VáradyBuild failure with `-Dc_std=c11`When configuring the project with `-Dc_std=cXX` (89, 99, 11), the compilation fails due to an incorrectly detected PCREL check:
```sh
$ meson setup -Dc_std=c11 build
...
$ meson compile -C build
[1/10] Compiling C object src/libffi.so.7...When configuring the project with `-Dc_std=cXX` (89, 99, 11), the compilation fails due to an incorrectly detected PCREL check:
```sh
$ meson setup -Dc_std=c11 build
...
$ meson compile -C build
[1/10] Compiling C object src/libffi.so.7.1.0.p/x86_unix64.S.o
FAILED: src/libffi.so.7.1.0.p/x86_unix64.S.o
cc -Isrc/libffi.so.7.1.0.p -Isrc -I../src -I. -I.. -Iinclude -I../include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 -O2 -g -DFFI_BUILDING -fPIC -DTARGET=X86_64 -MD -MQ src/libffi.so.7.1.0.p/x86_unix64.S.o -MF src/libffi.so.7.1.0.p/x86_unix64.S.o.d -o src/libffi.so.7.1.0.p/x86_unix64.S.o -c ../src/x86/unix64.S
../src/x86/unix64.S: Assembler messages:
../src/x86/unix64.S:451: Error: junk at end of line, first unrecognized character is `@'
```
The problematic check:
```
Command line: cc /tmpg5c31nq9/testfile.c -o /tmpg5c31nq9/output.obj -c -D_FILE_OFFSET_BITS=64 -O0 -std=c11
Code:
asm (".text; foo: nop; .data; .long foo-.; .text");
Compiler stdout:
Compiler stderr:
/tmpg5c31nq9/testfile.c:1:6: error: expected declaration specifiers or '...' before string constant
1 | asm (".text; foo: nop; .data; .long foo-.; .text");
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Checking if "ASM x86 PCREL" : compiles: NO
```
Workaround:
Using `-Dc_std=gnuXX`.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1000audioinvert: silent with F32LE2022-02-08T10:01:27ZDavid Grinbergaudioinvert: silent with F32LE### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstream...### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
This simple pipeline outputs silent invert.wav file
```
gst-launch-1.0 filesrc location=input.wav ! wavparse ! audioconvert ! audioresample ! 'audio/x-raw,format=F32LE' ! audioinvert degree=1.0 ! wavenc ! filesink location=invert.wav
```
But if I change F32LE to S16LE everything is ok.
#### Expected Behavior
invert.wav contains inverted input.wav
#### Observed Behavior
invert.wav contains silence
#### Setup
- **Operating System:** macOS 11.5.2
- **Device:** MacBook Pro 2019 Intel Core i9
- **GStreamer Version:** 1.18.4
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
100%
### Solutions you have tried
Tried running with different GST_DEBUG values but found none errorshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/182Implement a Transcriber element using Google Cloud Speech-to-Text API2022-09-16T09:07:28ZRafael CarícioImplement a Transcriber element using Google Cloud Speech-to-Text APII would like to implement a new plugin around Google Cloud multimedia/machine learning APIs. The first one that seems to make sense to me is an element similar to the existing [`awstranscriber`](https://gitlab.freedesktop.org/gstreamer/g...I would like to implement a new plugin around Google Cloud multimedia/machine learning APIs. The first one that seems to make sense to me is an element similar to the existing [`awstranscriber`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/main/net/rusoto/src/aws_transcriber) but using the Google [Speech-to-Text API](https://cloud.google.com/speech-to-text).
Is this something you would consider accepting here? If yes, I will start working on it. :smiley:https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1002RTSP stream does not work2022-02-08T11:23:01ZantonioasRTSP stream does not workHi, I'm using the plugin with OBS and it works great with Dahua cameras, but I have a problem with Panasonic's RTSP stream (example link: rtsp://root:root@123.456.789.000:554/MediaInput/h264) and I can't understand why.
Thank you for yo...Hi, I'm using the plugin with OBS and it works great with Dahua cameras, but I have a problem with Panasonic's RTSP stream (example link: rtsp://root:root@123.456.789.000:554/MediaInput/h264) and I can't understand why.
Thank you for your help.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1003Update hw accelerated video decoding docs2022-02-08T19:31:50ZNirbheek Chauhannirbheek.chauhan@gmail.comUpdate hw accelerated video decoding docs`subprojects/gst-docs/markdown/tutorials/playback/hardware-accelerated-video-decoding.md` needs updating, carrying over from discussion at https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1671`subprojects/gst-docs/markdown/tutorials/playback/hardware-accelerated-video-decoding.md` needs updating, carrying over from discussion at https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1671https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1006playbin doesn't play from smb sources2022-11-10T09:21:10ZClaudio Saavedraplaybin doesn't play from smb sourcesThis works:
```
gst-launch-1.0 -v giosrc location=smb://osmc/seagate/music/song.mp3 ! decodebin ! audioconvert ! audioresample ! autoaudiosink
```
This doesn't:
```
gst-launch-1.0 -v playbin uri=smb://osmc/seagate/music/song.mp3
```
...This works:
```
gst-launch-1.0 -v giosrc location=smb://osmc/seagate/music/song.mp3 ! decodebin ! audioconvert ! audioresample ! autoaudiosink
```
This doesn't:
```
gst-launch-1.0 -v playbin uri=smb://osmc/seagate/music/song.mp3
```
The error:
```
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: No URI handler implemented for "smb".
Additional debug info:
../gst/playback/gsturidecodebin.c(1449): gen_source_element (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0
```
Both rhythmbox and totem cannot play music from a samba share, I suspect they both use playbin or some other automatic pipeline, not sure though (didn't check). In any case, shouldn't playbin be able to link `smb:` uris with the `giosrc` source?
gstreamer 1.18.5 from debian testing.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1016nvjpegdec Fails to recognize JPEG streams2022-02-16T19:29:09ZGary Hollisnvjpegdec Fails to recognize JPEG streams### Describe your issue
The nvjpegdec NVDEC JPEG decoder fails to recognize any JPEG streams, including those generated using only gst-plugins-good plugins.
Plugin: nvjpegdec (nvcodec)
Version: 1.18.5
## Examples:
### (WORKS) Standard ...### Describe your issue
The nvjpegdec NVDEC JPEG decoder fails to recognize any JPEG streams, including those generated using only gst-plugins-good plugins.
Plugin: nvjpegdec (nvcodec)
Version: 1.18.5
## Examples:
### (WORKS) Standard JPEG CPU test pipeline:
`gst-launch-1.0 -v videotestsrc ! video/x-raw,width=720,height=480,framerate=30/1 ! jpegenc ! jpegparse ! jpegdec ! videoconvert ! autovideosink`
### (FAILS) Same but using nvjpegdec to decode instead of jpegdec:
`gst-launch-1.0 -v videotestsrc ! video/x-raw,width=720,height=480,framerate=30/1 ! jpegenc ! jpegparse ! nvjpegdec ! videoconvert ! autovideosink`
## Another example using fakesink:
### (WORKS) jpegdec pipeline with fakesink:
`gst-launch-1.0 -v videotestsrc ! video/x-raw,width=720,height=480,framerate=30/1 ! jpegenc ! jpegparse ! jpegdec ! videoconvert ! fakesink`
### (FAILS) same but with nvjpegdec:
`gst-launch-1.0 -v videotestsrc ! video/x-raw,width=720,height=480,framerate=30/1 ! jpegenc ! jpegparse ! nvjpegdec ! videoconvert ! fakesink`
#### Expected Behavior
I expected a test video stream to be displayed for the autovideosink case, and a successful stream in the fakesink case.
#### Observed Behavior
Neither test stream successfully ran. Error logs are in "Additional Information" section.
#### Setup
- **Operating System:**
Linux
uname -srvm:
Linux 5.15.12-arch1-1 #1 SMP PREEMPT Wed, 29 Dec 2021 12:04:56 +0000 x86_64
- **GStreamer Version:**
gst-launch-1.0 --version:
gst-launch-1.0 version 1.18.5
GStreamer 1.18.5
https://www.archlinux.org/
- **Command line:**
Not entirely sure what this template entry means
### Steps to reproduce the bug
1. Open terminal on system with NVIDIA GPU and nvcodec plugin installed via gst-plugins-bad.
2. Enter this gstreamer command:
`gst-launch-1.0 -v videotestsrc ! video/x-raw,width=720,height=480,framerate=30/1 ! jpegenc ! jpegparse ! nvjpegdec ! videoconvert ! fakesink`
### How reproducible is the bug?
The reproducibility of the bug is Always after running the above example.
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->
`gst-launch-1.0 -v videotestsrc ! video/x-raw,width=720,height=480,framerate=30/1 ! jpegenc ! jpegparse ! nvjpegdec ! videoconvert ! autovideosink` output:
<details>
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'nvjpegdec0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext0", cuda-device-id=(int)0;
Got context from element 'nvjpegdec0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";
/GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = video/x-raw, format=(string)Y444, width=(int)720, height=(int)480, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw, format=(string)Y444, width=(int)720, height=(int)480, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstJpegEnc:jpegenc0.GstPad:sink: caps = video/x-raw, format=(string)Y444, width=(int)720, height=(int)480, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw, format=(string)Y444, width=(int)720, height=(int)480, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstJpegEnc:jpegenc0.GstPad:src: caps = image/jpeg, sof-marker=(int)0, width=(int)720, height=(int)480, 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
/GstPipeline:pipeline0/GstJpegParse:jpegparse0.GstPad:sink: caps = image/jpeg, sof-marker=(int)0, width=(int)720, height=(int)480, 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
ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data stream error.
Additional debug info:
../gstreamer/libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
ERROR: from element /GstPipeline:pipeline0/nvjpegdec:nvjpegdec0: No valid frames decoded before end of stream
Additional debug info:
../gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c(1246): gst_video_decoder_sink_event_default (): /GstPipeline:pipeline0/nvjpegdec:nvjpegdec0:
no valid frames found
ERROR: pipeline doesn't want to preroll.
/GstPipeline:pipeline0/GstJpegParse:jpegparse0.GstPad:src: caps = image/jpeg, parsed=(boolean)true, format=(string)YV12, width=(int)720, height=(int)480, framerate=(fraction)30/1
Setting pipeline to NULL ...
Freeing pipeline ...
</details>
`gst-launch-1.0 -v videotestsrc ! video/x-raw,width=720,height=480,framerate=30/1 ! jpegenc ! jpegparse ! nvjpegdec ! videoconvert ! fakesink` output:
<details>
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'nvjpegdec0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext0", cuda-device-id=(int)0;
Got context from element 'nvjpegdec0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";
/GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = video/x-raw, format=(string)Y444, width=(int)720, height=(int)480, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw, format=(string)Y444, width=(int)720, height=(int)480, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstJpegEnc:jpegenc0.GstPad:sink: caps = video/x-raw, format=(string)Y444, width=(int)720, height=(int)480, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw, format=(string)Y444, width=(int)720, height=(int)480, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstJpegEnc:jpegenc0.GstPad:src: caps = image/jpeg, sof-marker=(int)0, width=(int)720, height=(int)480, 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
/GstPipeline:pipeline0/GstJpegParse:jpegparse0.GstPad:sink: caps = image/jpeg, sof-marker=(int)0, width=(int)720, height=(int)480, 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
/GstPipeline:pipeline0/GstJpegParse:jpegparse0.GstPad:src: caps = image/jpeg, parsed=(boolean)true, format=(string)YV12, width=(int)720, height=(int)480, framerate=(fraction)30/1
/GstPipeline:pipeline0/nvjpegdec:nvjpegdec0.GstPad:sink: caps = image/jpeg, parsed=(boolean)true, format=(string)YV12, width=(int)720, height=(int)480, framerate=(fraction)30/1
ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data stream error.
Additional debug info:
../gstreamer/libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
ERROR: from element /GstPipeline:pipeline0/nvjpegdec:nvjpegdec0: No valid frames decoded before end of stream
Additional debug info:
../gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c(1246): gst_video_decoder_sink_event_default (): /GstPipeline:pipeline0/nvjpegdec:nvjpegdec0:
no valid frames found
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
</details>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1017transcoder: Critical warning during shutdown2022-02-13T12:31:13ZPhilippe Normandtranscoder: Critical warning during shutdown```
file ../glib/gthread-posix.c: line 1369 (g_system_thread_wait): error 'Resource deadlock avoided' during 'pthread_join (pt->system_thread, NULL)'
Thread 1 (Thread 0x7ff5feffd640 (LWP 488)):
#0 g_logv (log_domain=0x7ff6b273d00e "GLi...```
file ../glib/gthread-posix.c: line 1369 (g_system_thread_wait): error 'Resource deadlock avoided' during 'pthread_join (pt->system_thread, NULL)'
Thread 1 (Thread 0x7ff5feffd640 (LWP 488)):
#0 g_logv (log_domain=0x7ff6b273d00e "GLib", log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=<optimized out>) at ../glib/gmessages.c:1417
#1 0x00007ff6b26ef073 in g_log (log_domain=log_domain@entry=0x7ff6b273d00e "GLib", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7ff6b27a51d8 "file %s: line %d (%s): error '%s' during '%s'") at ../glib/gmessages.c:1455
#2 0x00007ff6b273bde2 in g_system_thread_wait (thread=0xb3f9e0) at ../glib/gthread-posix.c:1369
#3 0x00007ff6b27128c2 in g_thread_join (thread=0xb3f9e0) at ../glib/gthread.c:1007
#4 0x00007ff6b16e0a4a in gst_transcoder_dispose (object=0x7063b0 [GstTranscoder]) at ../gst-libs/gst/transcoder/gsttranscoder.c:234
#5 0x00007ff6b27e463f in g_object_unref (_object=<optimized out>) at ../gobject/gobject.c:3549
#6 g_object_unref (_object=0x7063b0) at ../gobject/gobject.c:3479
#7 0x00007ff6b17f8412 in gst_object_unref (object=<optimized out>) at ../gst/gstobject.c:267
#8 0x00007ff6b1839a3e in _gst_message_free (message=0xbc8da0 [GstMessage]) at ../gst/gstmessage.c:213
#9 0x00007ff6b16e426f in gst_message_unref (msg=0xbc8da0 [GstMessage]) at /usr/include/gstreamer-1.0/gst/gstmessage.h:374
#10 gst_transcoder_signal_adapter_bus_sync_handler (bus=<optimized out>, message=0xbc8da0 [GstMessage], user_data=<optimized out>) at ../gst-libs/gst/transcoder/gsttranscoder-signal-adapter.c:148
#11 0x00007ff6b180d7d2 in gst_bus_post (bus=0xb03340 [GstBus], message=message@entry=0xbc8da0 [GstMessage]) at ../gst/gstbus.c:357
#12 0x00007ff6b16e26bf in api_bus_post_message (self=self@entry=0x7063b0 [GstTranscoder], message_type=message_type@entry=GST_TRANSCODER_MESSAGE_STATE_CHANGED, firstfield=firstfield@entry=0x7ff6b16e546f "state") at ../gst-libs/gst/transcoder/gsttranscoder.c:433
#13 0x00007ff6b16e383f in notify_state_changed (self=self@entry=0x7063b0 [GstTranscoder], new_state=new_state@entry=GST_TRANSCODER_STATE_PLAYING) at ../gst-libs/gst/transcoder/gsttranscoder.c:605
#14 0x00007ff6b16e39ca in state_changed_cb (bus=bus@entry=0xa15870 [GstBus], msg=msg@entry=0xbc4380 [GstMessage], user_data=<optimized out>) at ../gst-libs/gst/transcoder/gsttranscoder.c:685
#15 0x00007ff6b27e248f in g_cclosure_marshal_VOID__BOXEDv (closure=closure@entry=0x7ff5ac001660, return_value=return_value@entry=0x0, instance=instance@entry=0xa15870, args=args@entry=0x7ff5feffc960, marshal_data=marshal_data@entry=0x0, n_params=n_params@entry=1, param_types=0x7c31e0) at ../gobject/gmarshal.c:1686
#16 0x00007ff6b27df229 in _g_closure_invoke_va (closure=closure@entry=0x7ff5ac001660, return_value=return_value@entry=0x0, instance=instance@entry=0xa15870, args=args@entry=0x7ff5feffc960, n_params=1, param_types=0x7c31e0) at ../gobject/gclosure.c:893
#17 0x00007ff6b27f8a98 in g_signal_emit_valist (instance=0xa15870, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ff5feffc960) at ../gobject/gsignal.c:3406
#18 0x00007ff6b27f8cb3 in g_signal_emit (instance=instance@entry=0xa15870, signal_id=<optimized out>, detail=<optimized out>) at ../gobject/gsignal.c:3553
#19 0x00007ff6b180d50c in gst_bus_async_signal_func (bus=0xa15870 [GstBus], message=0xbc4380 [GstMessage], data=<optimized out>) at ../gst/gstbus.c:1280
#20 0x00007ff6b180e3fc in gst_bus_source_dispatch (source=0x7ff5ac001480, callback=0x7ff6b180d4b0 <gst_bus_async_signal_func>, user_data=0x0) at ../gst/gstbus.c:821
#21 0x00007ff6b26e7294 in g_main_dispatch (context=0xa1fb90) at ../glib/gmain.c:3381
#22 g_main_context_dispatch (context=0xa1fb90) at ../glib/gmain.c:4099
#23 0x00007ff6b26e7638 in g_main_context_iterate (context=0xa1fb90, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4175
#24 0x00007ff6b26e7943 in g_main_loop_run (loop=0xa1dba0) at ../glib/gmain.c:4373
#25 0x00007ff6b16e130c in gst_transcoder_main (data=<optimized out>) at ../gst-libs/gst/transcoder/gsttranscoder.c:829
#26 0x00007ff6b2712351 in g_thread_proxy (data=0xb3f9e0) at ../glib/gthread.c:827
#27 0x00007ff6b26763ba in start_thread (arg=0x7ff5feffd640) at pthread_create.c:481
#28 0x00007ff6b211cb03 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1018webRTCbin could not handle caps2022-02-14T09:36:57ZAkshay Pratap SinghwebRTCbin could not handle caps```
Failed to parse launch: could not link rtph264pay0 to sendrecv, sendrecv can't handle caps application/x-rtp, media=(string)video, encoding-name=(string)H264, payload=(int)96
ERROR: failed to start pipeline
```
https://gitlab.freedes...```
Failed to parse launch: could not link rtph264pay0 to sendrecv, sendrecv can't handle caps application/x-rtp, media=(string)video, encoding-name=(string)H264, payload=(int)96
ERROR: failed to start pipeline
```
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-examples/webrtc/sendonly/webrtc-unidirectional-h264.c
tried running this example.
Used to work before with gstreamer 1.16 , upgraded to 1.20.0 using source build from the tag 1.20.0 with gpl license enabled.
Cant understand why it fails to handle H264 payload now.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1701avdec_h264 producing sudden PTS jumps in RTSP streams2022-02-14T16:35:14ZArkadiy Kulevavdec_h264 producing sudden PTS jumps in RTSP streamsHello!
I'm receiving a 30 FPS video stream from a RTSP camera via TCP. Every few seconds I experience sudden choppy playback:
`rtspsrc latency=2000 location=rtspt://guest:gstreamer1@sala.ath.cx:5540/Streaming/Channels/101 ! rtph264dep...Hello!
I'm receiving a 30 FPS video stream from a RTSP camera via TCP. Every few seconds I experience sudden choppy playback:
`rtspsrc latency=2000 location=rtspt://guest:gstreamer1@sala.ath.cx:5540/Streaming/Channels/101 ! rtph264depay ! h264parse ! identity name=id_parse ! avdec_h264 ! identity name=id_avdec ! watchdog timeout=10000 ! autovideosink`
I've been trying to wrap my head around this problem for quite a while and finally wrote a python script which shows me the PTS offsets in different parts of the pipeline ([gst.py](/uploads/1480a00860f8be0cbef49f409a4e50ce/gst.py) script attached)
`h264parse` produces a small jump in PTS only in the beginning of the playback, but stays more or less at 0.0333 afterwards (which is consistent with 30 FPS).
`avdec_h264`, however, produces jumps every several seconds:
```
[pts= 0.194 ] pts_parse delta from previous PTS not 0.0333 = 0.193780327
[pts= 0.194 ] pts_avdec delta from previous PTS not 0.0333 = 0.193780327
[pts= 4.31 ] pts_avdec delta from previous PTS not 0.0333 = 0.06699949600000021
[pts= 6.509 ] pts_avdec delta from previous PTS not 0.0333 = 0.06690735799999992
[pts= 8.307 ] pts_avdec delta from previous PTS not 0.0333 = 0.06704043799999937
[pts= 12.306 ] pts_avdec delta from previous PTS not 0.0333 = 0.06695861200000053
[pts= 13.705 ] pts_avdec delta from previous PTS not 0.0333 = 0.06703847100000004
[pts= 20.308 ] pts_avdec delta from previous PTS not 0.0333 = 0.06702971500000032
[pts= 20.642 ] pts_avdec delta from previous PTS not 0.0333 = 0.09999486099999899
[pts= 23.275 ] pts_avdec delta from previous PTS not 0.0333 = 0.06699473599999806
[pts= 24.341 ] pts_avdec delta from previous PTS not 0.0333 = 0.09999411300000105
```
Is it a bug? Or I should write a wrapper script which fixes the PTS after `avdec_h264` myself?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1089vaapih265enc: error: add_slice_headers: assertion failed2022-03-14T09:07:08ZQuackdocvaapih265enc: error: add_slice_headers: assertion failedHello, I am trying to implement video accelerated encode into Spice server project for VMs. I have managed to get software encoding working, however when I try to use vaapiH265enc I run into this error.
`Bail out! ERROR:../gstreamer/su...Hello, I am trying to implement video accelerated encode into Spice server project for VMs. I have managed to get software encoding working, however when I try to use vaapiH265enc I run into this error.
`Bail out! ERROR:../gstreamer/subprojects/gstreamer-vaapi/gst-libs/gst/vaapi/gstvaapiencoder_h265.c:2235:add_slice_headers: assertion failed: (encoder->num_slices && encoder->num_slices < ctu_size)`
I have tried manually setting num-slices=1 but that doesn't seem to work. I am unsure if this is a bug, or if I am missing something in my code. I have used this command line to verify that that vaapiH265enc is working on my machine
`gst-launch-1.0 -vf filesrc location=out.yuv num-buffers=150 ! rawvideoparse format=i420 width=1920 height=1080 ! videoconvert ! video/x-raw,format=NV12 ! vaapih265enc rate-control=cqp init-qp=14 quality-level=4 keyframe-period=30 num-slices=1 refs=1 max-bframes=2 ! video/x-h265,profile=main ! h265parse ! filesink location=./output.h265`