GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-03-22T16:50:45Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/963qtsink: change widget while playing2022-03-22T16:50:45Zbkarasmqtsink: change widget while playingI have an audio/video player application created based on the playbin3 pipeline. My video sink is a qtsink element which is configured to render incoming video on Qml item (GstGLVideoItem).
Now, I'm trying to move rendering of the vide...I have an audio/video player application created based on the playbin3 pipeline. My video sink is a qtsink element which is configured to render incoming video on Qml item (GstGLVideoItem).
Now, I'm trying to move rendering of the video to a different window by changing parent of the GstGLVideoItem. This works perfectly on macOS and Linux but not on Windows. I've spent some time debugging GstGLVideoItem (qtitem) and qtsink and my understanding is that it doesn't work because on Windows new window is rendered in a different thread. As a result new GL context is being created which is not passed to the qtsink element because that only happens when qtsink changes state from NULL to READY.
I'm a gstreamer/Qt/OpenGl newbie so please assume I haven't tried obvious solutions.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1104rtphdrextclientaudiolevel Example pipeline doesn't work.2022-11-10T09:21:12ZMaxandre Ogeretrtphdrextclientaudiolevel Example pipeline doesn't work.Hey, the pipeline example of rtphdrextclientaudiolevel doesn't work.: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/gst/rtpmanager/gstrtphdrext-clientaudiolevel.c#L26
- First of all there's ...Hey, the pipeline example of rtphdrextclientaudiolevel doesn't work.: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/gst/rtpmanager/gstrtphdrext-clientaudiolevel.c#L26
- First of all there's a typo : `audiconvert`
- Then the syntax is wrong, impossible to copy and paste it into the command line
- Even after correcting the pipeline it doesn't work :
```
gst-launch-1.0 pulsesrc ! level audio-level-meta=true ! audiconvert ! rtpL16pay ! 'application/x-rtp, extmap-1=(string)\< \"\", urn:ietf:params:rtp-hdrext:ssrc-audio-level, \"vad=on\" \>' ! udpsink
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1103v4l2h264dec0: Too old frames, bug in decoder -- please file a bug: NEW DETAILS2022-07-03T00:40:34ZF. Duncanhv4l2h264dec0: Too old frames, bug in decoder -- please file a bug: NEW DETAILSThis g_warning is triggered by an anomaly (NOT a decoder bug) where the first few video frames are not processed in gstv4l2videodec.c `gst_v4l2_video_dec_loop(GstVideodecoder *decoder)`.
For certain streams, (described below)
the first ...This g_warning is triggered by an anomaly (NOT a decoder bug) where the first few video frames are not processed in gstv4l2videodec.c `gst_v4l2_video_dec_loop(GstVideodecoder *decoder)`.
For certain streams, (described below)
the first frame to get past line 712
```
frame =
gst_video_decoder_get_frame (decoder,
GST_BUFFER_TIMESTAMP (buffer) / GST_SECOND);
```
is the frame with frame->system_frame_number = 4, while frames 0,1,2,3 are waiting, with oldest_frame->system_frame_number = 0.
These only get removed by the garbage collection code when frames 101 - 104 are processed, triggering the warning four times.
I could not diagnose why the these frames dont get through. There is one instance of a return at line 693 (this occurs once only (presumably when the nal pps and sps data in frame 0 gets turned into caps specifying the resolution by h264parse)
if (ret == GST_V4L2_FLOW_RESOLUTION_CHANGE) {
GST_WARNING_OBJECT (decoder, "Received resolution change");
g_atomic_int_set (&self->capture_configuration_change, TRUE);
return;
}
The source is an h264 video stream (Apple Airplay from an iOS client) where the first frame has the structure
0x00 0x00 0x00 0x01 SPS 0x00 0x00 00x00 0x01 PPS 0x00 0x00 00x00 0x01 (h264 video)
and thereafter only 0x00 0x00 0x00 0x01 (h264 video).
Everything works fine when an appsrc with no caps set injects this into a video pipeline starting with h264parse. Possibly a few (4) initial video frames are lost, but everything then works fine in the pipeline, so no decoder errors.
The cleanup of these first four orphan frames ideally should only generate a GST_DEBUG-2 warning, not the "annoying"
g_warning it now does.
there is some prior discussion in #1094
some printf statements added to gst_v4l2_video_dec_loop after line 712 show what happens:
```
Begin streaming to GStreamer video pipeline
current frame = 4, oldest_frame = 0
unref oldest_frame = 0
current frame = 5, oldest_frame = 0
unref oldest_frame = 0
current frame = 6, oldest_frame = 0
unref oldest_frame = 0
current frame = 7, oldest_frame = 0
unref oldest_frame = 0
current frame = 8, oldest_frame = 0
<snip>
current frame = 99, oldest_frame = 0
unref oldest_frame = 0
current frame = 100, oldest_frame = 0
unref oldest_frame = 0
current frame = 101, oldest_frame = 0
drop oldest frame = 0
** (uxplay:20882): WARNING **: 19:36:27.001: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug
unref oldest_frame = 1
current frame = 102, oldest_frame = 1
drop oldest frame = 1
** (uxplay:20882): WARNING **: 19:36:27.003: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug
unref oldest_frame = 2
current frame = 103, oldest_frame = 2
drop oldest frame = 2
** (uxplay:20882): WARNING **: 19:36:27.004: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug
unref oldest_frame = 3
current frame = 104, oldest_frame = 3
drop oldest frame = 3
** (uxplay:20882): WARNING **: 19:36:27.049: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug
unref oldest_frame = 104
current frame = 105, oldest_frame = 105
unref oldest_frame = 105
current frame = 106, oldest_frame = 106
<snip>
```
I dont quite understand what drop and unref are doing in terms of freeing the presumably-rendered video data, and why frame 0 keeps getting unref'ed 100 times until the garbage collection starts (when current frame - oldest > 100)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1711v4l2h264dec0: Too old frames, bug in decoder -- please file a bug2022-03-22T01:25:34ZF. Duncanhv4l2h264dec0: Too old frames, bug in decoder -- please file a bugThis g_warning is triggered by an anomaly (NOT a decoder bug) where the first few video frames are not processed in gstv4l2videodec.c `gst_v4l2_video_dec_loop(GstVideodecoder *decoder)`.
For certain streams, (described below)
the first ...This g_warning is triggered by an anomaly (NOT a decoder bug) where the first few video frames are not processed in gstv4l2videodec.c `gst_v4l2_video_dec_loop(GstVideodecoder *decoder)`.
For certain streams, (described below)
the first frame to get past line 712
```
frame =
gst_video_decoder_get_frame (decoder,
GST_BUFFER_TIMESTAMP (buffer) / GST_SECOND);
```
is the frame with frame->system_frame_number = 4, while frames 0,1,2,3 are waiting, with oldest_frame->system_frame_number = 0.
These only get removed by the garbage collection code when frames 101 - 104 are processed, triggering the warning four times.
I could not diagnose why the these frames dont get through. There is one instance of a return at line 693
if (ret == GST_V4L2_FLOW_RESOLUTION_CHANGE) {
GST_WARNING_OBJECT (decoder, "Received resolution change");
g_atomic_int_set (&self->capture_configuration_change, TRUE);
return;
}
The source is an h264 video stream (Apple Airplay from an iOS client) where the first frame has the structure
0x00 0x00 0x00 0x01 SPS 0x00 0x00 00x00 0x01 PPS 0x00 0x00 00x00 0x01 (h264 video)
and thereafter only 0x00 0x00 0x00 0x01 (h264 video).
Every works fine when an appsrc with no caps set injects this into a video pipeline starting with h264parse. Possibly a few (4) initial video frames are lost, but every then works fine in the pipeline, so no decoder errors.
The cleanup of these first four orphan frames ideally should only generate a GST_DEBUG-2 warning, not the "annoying"
g_warning it now does.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1102Missing element: MPEG-4 AAC decoder2022-03-21T19:07:07ZAli Massah KainiMissing element: MPEG-4 AAC decoderI tried below command but got error.
What's the problem?
`gst-launch-1.0 uridecodebin3 uri=file:///D:/MyWorks/Python/VideoSearchEngine/VideoSet/4.mp4 ! openh264dec ! videoconvert name=mconverter ! video/x-raw, format=BGR, width=480, he...I tried below command but got error.
What's the problem?
`gst-launch-1.0 uridecodebin3 uri=file:///D:/MyWorks/Python/VideoSearchEngine/VideoSet/4.mp4 ! openh264dec ! videoconvert name=mconverter ! video/x-raw, format=BGR, width=480, height=480 ! d3dvideosink name=msink`
output:
```
(gst-launch-1.0:16912): GStreamer-WARNING **: 20:08:48.856: Failed to load plugin 'F:\gstreamer\1.0\msvc_x86_64\lib\gstreamer-1.0\gstassrender.dll': The specified module could not be found.
This usually means Windows was unable to find a DLL dependency of the plugin. Please check that PATH is correct.
You can run 'dumpbin -dependents' (provided by the Visual Studio developer prompt) to list the DLL deps of any DLL.
There are also some third-party GUIs to list and debug DLL dependencies recursively.
(gst-launch-1.0:16912): GStreamer-WARNING **: 20:08:48.916: Failed to load plugin 'F:\gstreamer\1.0\msvc_x86_64\lib\gstreamer-1.0\gstwavpack.dll': The specified module could not be found.
This usually means Windows was unable to find a DLL dependency of the plugin. Please check that PATH is correct.
You can run 'dumpbin -dependents' (provided by the Visual Studio developer prompt) to list the DLL deps of any DLL.
There are also some third-party GUIs to list and debug DLL dependencies recursively.
Use Windows high-resolution clock, precision: 1 ms
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Missing element: MPEG-4 AAC decoder
Got context from element 'nvh264dec0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext0", cuda-device-id=(int)0;
Got context from element 'nvh264dec0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplay\)\ gldisplay0";
Redistribute latency...
ERROR: from element /GstPipeline:pipeline0/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstQTDemux:qtdemux0: Internal data stream error.
Additional debug info:
../gst/isomp4/qtdemux.c(6747): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstQTDemux:qtdemux0:
streaming stopped, reason not-linked (-1)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1101Random crashes when stopping playback of multiple videos2022-05-18T13:29:36ZIvan MolodetskikhRandom crashes when stopping playback of multiple videos### Describe your issue
I'm updating [an app](https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.Identity) that plays a number of `playbin3` elements at once (they are all children of a single `GstPipeline`). When the app is close...### Describe your issue
I'm updating [an app](https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.Identity) that plays a number of `playbin3` elements at once (they are all children of a single `GstPipeline`). When the app is closed it sets the pipeline state to `NULL`.
I've been hitting random segfaults from GStreamer threads when closing the app. It's easiest to reproduce when running under a debugger, opening five or so video files, then closing the app before they all finished prerolling.
Generally the segfaults look something like this, with the "corrupted size vs. prev_size in fastbins" message:
![image](/uploads/bdd912c44d9cbc426173347cc087763c/image.png)
I tried reproducing the crash under valgrind a few times and got these messages in the log:
```
==168892== Thread 60 multiqueue2:src_:
==168892== Invalid read of size 8
==168892== at 0x446E91F8: si_switch_compute_shader (si_compute.c:530)
==168892== by 0x446E91F8: si_launch_grid (si_compute.c:963)
==168892== by 0x446EA90A: si_launch_grid_internal (si_compute_blit.c:94)
==168892== by 0x446EC701: si_compute_clear_render_target (si_compute_blit.c:856)
==168892== by 0x4449B740: vlVaHandleSurfaceAllocate (surface.c:812)
==168892== by 0x4449C1E3: vlVaCreateSurfaces2.part.0 (surface.c:1003)
==168892== by 0x3DDEBE97: vaCreateSurfaces (va.c:1182)
==168892== by 0x3DD6BA70: UnknownInlinedFun (gstvaapisurface.c:220)
==168892== by 0x3DD6BA70: gst_vaapi_surface_new_full (gstvaapisurface.c:431)
==168892== by 0x3DD99996: UnknownInlinedFun (gstvaapisurface.c:466)
==168892== by 0x3DD99996: context_ensure_surfaces (gstvaapicontext.c:200)
==168892== by 0x3DD99F24: context_create (gstvaapicontext.c:258)
==168892== by 0x3DD9BA7B: UnknownInlinedFun (gstvaapicontext.c:526)
==168892== by 0x3DD9BA7B: gst_vaapi_context_new (gstvaapicontext.c:490)
==168892== by 0x3DD4C3FB: gst_vaapi_decoder_ensure_context (gstvaapidecoder.c:981)
==168892== by 0x3DD51869: UnknownInlinedFun (gstvaapidecoder_h264.c:1655)
==168892== by 0x3DD51869: UnknownInlinedFun (gstvaapidecoder_h264.c:4170)
==168892== by 0x3DD51869: gst_vaapi_decoder_h264_start_frame.lto_priv.0 (gstvaapidecoder_h264.c:4875)
==168892== Address 0xa8 is not stack'd, malloc'd or (recently) free'd
==168892==
==168892==
==168892== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==168892== Access not within mapped region at address 0xA8
==168892== at 0x446E91F8: si_switch_compute_shader (si_compute.c:530)
==168892== by 0x446E91F8: si_launch_grid (si_compute.c:963)
==168892== by 0x446EA90A: si_launch_grid_internal (si_compute_blit.c:94)
==168892== by 0x446EC701: si_compute_clear_render_target (si_compute_blit.c:856)
==168892== by 0x4449B740: vlVaHandleSurfaceAllocate (surface.c:812)
==168892== by 0x4449C1E3: vlVaCreateSurfaces2.part.0 (surface.c:1003)
==168892== by 0x3DDEBE97: vaCreateSurfaces (va.c:1182)
==168892== by 0x3DD6BA70: UnknownInlinedFun (gstvaapisurface.c:220)
==168892== by 0x3DD6BA70: gst_vaapi_surface_new_full (gstvaapisurface.c:431)
==168892== by 0x3DD99996: UnknownInlinedFun (gstvaapisurface.c:466)
==168892== by 0x3DD99996: context_ensure_surfaces (gstvaapicontext.c:200)
==168892== by 0x3DD99F24: context_create (gstvaapicontext.c:258)
==168892== by 0x3DD9BA7B: UnknownInlinedFun (gstvaapicontext.c:526)
==168892== by 0x3DD9BA7B: gst_vaapi_context_new (gstvaapicontext.c:490)
==168892== by 0x3DD4C3FB: gst_vaapi_decoder_ensure_context (gstvaapidecoder.c:981)
==168892== by 0x3DD51869: UnknownInlinedFun (gstvaapidecoder_h264.c:1655)
==168892== by 0x3DD51869: UnknownInlinedFun (gstvaapidecoder_h264.c:4170)
==168892== by 0x3DD51869: gst_vaapi_decoder_h264_start_frame.lto_priv.0 (gstvaapidecoder_h264.c:4875)
==168892== If you believe this happened as a result of a stack
==168892== overflow in your program's main thread (unlikely but
==168892== possible), you can try to increase the size of the
==168892== main thread stack using the --main-stacksize= flag.
==168892== The main thread stack size used in this run was 8388608.
```
#### Setup
- **Operating System:** Fedora 36 Silverblue, running the app in a Fedora 35 toolbox
- **Device:** Computer
- **GStreamer Version:** gstreamer1-1.20.0-1.fc35.x86_64, gstreamer1-vaapi-1.20.0-1.fc35.x86_64
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Pretty frequently on my setup; the more videos the more likely it happens, but running without a debugger decreases the likelihood.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/189threadshare: udpsrc missing timeout option2022-03-21T08:07:42ZDan Sirbuthreadshare: udpsrc missing timeout optionudpsrc has a timeout optional param that ys-udpsrc is missing.udpsrc has a timeout optional param that ys-udpsrc is missing.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1100Can't play back WebVTT embedded in WebM/MKV2022-03-21T14:00:04ZBastien NoceraCan't play back WebVTT embedded in WebM/MKVOriginally from: https://gitlab.gnome.org/GNOME/totem/-/issues/511
[webm-vtt-sub-totem-issue-511](/uploads/80c174dc1e4d79be76066f13a5e122fe/webm-vtt-sub-totem-issue-511.webm)
I made the following changes to GStreamer to get past the "u...Originally from: https://gitlab.gnome.org/GNOME/totem/-/issues/511
[webm-vtt-sub-totem-issue-511](/uploads/80c174dc1e4d79be76066f13a5e122fe/webm-vtt-sub-totem-issue-511.webm)
I made the following changes to GStreamer to get past the "unknown decoder" error, but:
```diff
diff --git a/subprojects/gst-plugins-good/gst/matroska/matroska-demux.c b/subprojects/gst-plugins-good/gst/matroska/matroska-demux.c
index 64cc6be60b..9d08fe72fa 100644
--- a/subprojects/gst-plugins-good/gst/matroska/matroska-demux.c
+++ b/subprojects/gst-plugins-good/gst/matroska/matroska-demux.c
@@ -7342,6 +7342,10 @@ gst_matroska_demux_subtitle_caps (GstMatroskaTrackSubtitleContext *
caps = gst_caps_new_empty_simple ("application/x-usf");
context->postprocess_frame = gst_matroska_demux_check_subtitle_buffer;
subtitlecontext->check_markup = FALSE;
+ } else if (!strcmp (codec_id, GST_MATROSKA_CODEC_ID_SUBTITLE_VTT)) {
+ caps = gst_caps_new_empty_simple ("application/x-subtitle-vtt");
+ context->postprocess_frame = gst_matroska_demux_check_subtitle_buffer;
+ subtitlecontext->check_markup = FALSE;
} else if (!strcmp (codec_id, GST_MATROSKA_CODEC_ID_SUBTITLE_VOBSUB)) {
caps = gst_caps_new_empty_simple ("subpicture/x-dvd");
((GstMatroskaTrackContext *) subtitlecontext)->send_dvd_event = TRUE;
diff --git a/subprojects/gst-plugins-good/gst/matroska/matroska-ids.h b/subprojects/gst-plugins-good/gst/matroska/matroska-ids.h
index c4fc73caad..74f2885978 100644
--- a/subprojects/gst-plugins-good/gst/matroska/matroska-ids.h
+++ b/subprojects/gst-plugins-good/gst/matroska/matroska-ids.h
@@ -422,6 +422,7 @@
#define GST_MATROSKA_CODEC_ID_SUBTITLE_SSA "S_TEXT/SSA"
#define GST_MATROSKA_CODEC_ID_SUBTITLE_ASS "S_TEXT/ASS"
#define GST_MATROSKA_CODEC_ID_SUBTITLE_USF "S_TEXT/USF"
+#define GST_MATROSKA_CODEC_ID_SUBTITLE_VTT "D_WEBVTT/SUBTITLES"
#define GST_MATROSKA_CODEC_ID_SUBTITLE_VOBSUB "S_VOBSUB"
#define GST_MATROSKA_CODEC_ID_SUBTITLE_HDMVPGS "S_HDMV/PGS"
#define GST_MATROSKA_CODEC_ID_SUBTITLE_BMP "S_IMAGE/BMP"
```
But subparse still complains that:
```
subparse gstsubparseelement.c:205:gst_sub_parse_data_format_autodetect:^[[00m no subtitle format detected
subparse gstsubparse.c:1459:gst_sub_parse_format_autodetect:<parser>^[[00m error: The input is not a valid/supported subtitle file
```
Because we're missing the re-adding of a header for the purpose of detection, like was done in the qtdemux:
https://gitlab.freedesktop.org/hadess/gstreamer/blob/main/subprojects/gst-plugins-good/gst/isomp4/qtdemux.c#L15148-L15151
No idea how to do that with the Matroska demuxer...https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1099Some usm files do not play - Scaleform Video2022-03-20T04:19:11ZorbeaSome usm files do not play - Scaleform Video### Describe your issue
When trying to play some `.usm` (Scaleform Video) files with gst-play they will fail.
These videos are from the game Xuan Yuan Sword VII from GOG (https://www.gog.com/en/game/xuanyuan_sword_vii) and not being ab...### Describe your issue
When trying to play some `.usm` (Scaleform Video) files with gst-play they will fail.
These videos are from the game Xuan Yuan Sword VII from GOG (https://www.gog.com/en/game/xuanyuan_sword_vii) and not being able to play the videos causes the game to crash after a early cutscene when playing it with wine.
Most of the `.asm` files do work, but a few do not.
`file(1)` reports all of the files as `Scaleform Video`.
`gst-typefind` reports the following for most of the videos where only a few don't work.
```
video/mpeg, systemstream=(boolean)false, mpegversion=(int)1, parsed=(boolean)false
```
And this for a few videos which all do not work.
```
FAILED: Could not determine type of stream.
```
#### Expected Behavior
The videos should play.
#### Observed Behavior
When `gst-typefind` reports the video information correctly, but fails to play:
```
Now playing Xuan-Yuan Sword VII/SWD7_GOG/Content/CriFile/MV_mq1902_Afterword_World_01_25D.usm
Redistribute latency...
Redistribute latency...
Redistribute latency...
Redistribute latency...
ERROR No valid frames decoded before end of stream for file://Xuan-Yuan%20Sword%20VII/SWD7_GOG/Content/CriFile/MV_mq1902_Afterword_World_01_25D.usm
ERROR debug information: ../gst-plugins-base-1.20.1/gst-libs/gst/video/gstvideodecoder.c(1416): gst_video_decoder_sink_event_default (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/avdec_mpeg2video:avdec_mpeg2video0:
no valid frames found
Reached end of play list.
```
And when it can't report the type of stream:
```
Now playing Xuan-Yuan Sword VII/SWD7_GOG/Content/CriFile/GameHelp_M_12.usm
ERROR Could not determine type of stream. for file://Xuan-Yuan%20Sword%20VII/SWD7_GOG/Content/CriFile/GameHelp_M_12.usm
ERROR debug information: ../gstreamer-1.20.1/plugins/elements/gsttypefindelement.c(1179): gst_type_find_element_loop (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind
Reached end of play list.
```
#### Setup
- **Operating System:** Gentoo
- **Device:** Computer
- **GStreamer Version:** 1.20.1
### Steps to reproduce the bug
Example files:
[MV_mq0303_GodBook_JiP_02_25D.usm](/uploads/4b9c5cbbfe92f306f8a23b9a74d5d0f4/MV_mq0303_GodBook_JiP_02_25D.usm)
[GameHelp_M_12.usm](/uploads/4091c381d1a0e4246f351555573ca202/GameHelp_M_12.usm)
For comparison this video works:
[GameHelp_M_01.usm](/uploads/d83e55445ce3117beb40e6fd31971d5d/GameHelp_M_01.usm)
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type `gst-play-1.0 foo.usm`
### How reproducible is the bug?
Alwayshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1098gst-build: wayland include files for gst-plugins-bad not found when they are ...2022-03-20T22:29:05ZF. Duncanhgst-build: wayland include files for gst-plugins-bad not found when they are in /usr/include/waylandOpenSUSE 15.3 puts wayland include files in /usr/include/wayland as opposed to/usr/include.
A build of gst-plugins-bad (for nvdec) then fails for 1.16.3
Is there any option to tell meson or ninja about an extra -I include dir?
The si...OpenSUSE 15.3 puts wayland include files in /usr/include/wayland as opposed to/usr/include.
A build of gst-plugins-bad (for nvdec) then fails for 1.16.3
Is there any option to tell meson or ninja about an extra -I include dir?
The simple workaround for users with this issue is to copy all the wayland\*.h files from their location (here /usr/include/wayland/) to gst-plugins-bad/gst-libs/gst/wayland/ , but ideally this should have been "automatic", or fixable with a meson or ninja "include" option I could not find.
It seems an attempt to fix this was made in the past, but it's not working.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1076https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/188threadshare: Using abortable and AbortHandle to stop the task loop leads to a...2022-03-25T18:13:11ZMac Thi Kieu Vanthreadshare: Using abortable and AbortHandle to stop the task loop leads to a large delay in the main thread.Using abortable and AbortHandle to stop the task loop leads to a large delay in the main thread.
When a share-thread element (ts-udpsrc/ts-udpsink/ts-jitterbuffer) changes state from Pause to Ready, it calls stop on its task. The task h...Using abortable and AbortHandle to stop the task loop leads to a large delay in the main thread.
When a share-thread element (ts-udpsrc/ts-udpsink/ts-jitterbuffer) changes state from Pause to Ready, it calls stop on its task. The task has an abort_handle, so it calls abort. And then, it sends a trigger Stop to the state machine and then waits for ACK from it.
At the state machine, the spawn_loop is stopped by aborting, and the trigger event Stop is put into pending_triggering_evt. At the run method, the event Stop is handled and the state machine sends ack to the main thread. The main thread receives ack and continues its job.
The problem is the main thread is blocked for a while by waiting for the ack from another thread via the abort handle method. The abortable is in futures::future::{self, abortable, AbortHandle, Aborted, BoxFuture, RemoteHandle};. As described in AbortHandle, we can stop a task from a remote future loop by calling its method abort. In the document, the method abort will not immediately stop the task:
> Notifies the Abortable task associated with this handle that it should abort. Note that if the task is currently being polled on another thread, it will not immediately stop running. Instead, it will continue to run until its poll method returns.
In fact, the delay is about 0.0077s. In my case, there are 6 share thread elements in a pipeline (two flows, each flow contains ts-udpsrc, ts-udpsink, ts-jitterbuffer). Changing state of the pipeline gets 0.0462s. When my app handles 500 concurrent calls, the 500th must wait for 23s. It is not reasonable to block the main thread to wait for that.
```
0:00:23.062971436 25144 0x2216600 DEBUG ts-runtime generic/threadshare/src/runtime/executor.rs:123:gstthreadshare::runtime::executor: Blocking on new dummy context
0:00:23.062986630 25144 0x2216600 TRACE ts-runtime generic/threadshare/src/runtime/task.rs:649:gstthreadshare::runtime::task: Awaiting ack for Stop
0:00:23.070756777 25144 0x7f56d4001c60 TRACE ts-runtime generic/threadshare/src/runtime/task.rs:1069:gstthreadshare::runtime::task: Task loop aborted
0:00:23.070809003 25144 0x7f56d4001c60 TRACE ts-runtime generic/threadshare/src/runtime/executor.rs:558:gstthreadshare::runtime::executor: Task TaskId(2) on context src_ctx done
0:00:23.070894543 25144 0x7f56d8001d30 TRACE ts-runtime generic/threadshare/src/runtime/task.rs:807:gstthreadshare::runtime::task: State machine popped TriggeringEvent { trigger: Pause }
```
From the log above, we can see the different time from "Awaiting ack for Stop" to "Task loop aborted" is about 0.0077shttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1097good: jackaudiosrc can not receive multi channel2022-03-17T23:30:34ZDennis Scheibagood: jackaudiosrc can not receive multi channelI am using gstreamer in an alpine docker container and I need to map a 16ch input from jack to 8 x stereo udp streams.
Because of realtime schedeuling issues in the container I needed to replace jack with pipewire but this should work tr...I am using gstreamer in an alpine docker container and I need to map a 16ch input from jack to 8 x stereo udp streams.
Because of realtime schedeuling issues in the container I needed to replace jack with pipewire but this should work transparent and because of the synth software SuperCollider I am bound to using Jack.
According to the [pipewire documentation](https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Migrate-JACK#jack_lsp) the equivalent of `jack_lsp` is
```shell
~ # pw-link -iol
SuperCollider:out_1
|-> gst-launch-1.0:in_jackaudiosrc0_1
SuperCollider:out_2
|-> gst-launch-1.0:in_jackaudiosrc0_2
SuperCollider:out_3
SuperCollider:out_4
SuperCollider:out_5
SuperCollider:out_6
SuperCollider:out_7
SuperCollider:out_8
SuperCollider:out_9
SuperCollider:out_10
SuperCollider:out_11
SuperCollider:out_12
SuperCollider:out_13
SuperCollider:out_14
SuperCollider:out_15
SuperCollider:out_16
SuperCollider:in_1
SuperCollider:in_2
gst-launch-1.0:in_jackaudiosrc0_1
|<- SuperCollider:out_1
gst-launch-1.0:in_jackaudiosrc0_2
|<- SuperCollider:out_2
```
SuperCollider creates 16 output channels on the jack device.
You can also see that I already connected a stereo pair succesfully via
```shell
gst-launch-1.0 jackaudiosrc port-pattern="SuperCollider" ! queue ! audioconvert ! audioresample ! opusenc ! rtpopuspay ! queue max-size-bytes=0 max-size-buffers=0 ! udpsink host=127.0.0.1 port=5002
```
The question is now how I can access the other 14 channels - I tried
```shell
~ # gst-launch-1.0 --version
gst-launch-1.0 version 1.18.5
GStreamer 1.18.5
https://alpinelinux.org
~ # gst-launch-1.0 jackaudiosrc connect=0 ! audioconvert ! "audio/x-raw,channels=2" ! wavenc ! filesink location=foo.wav
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSrcClock
Redistribute latency...
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:04.409656367
Setting pipeline to NULL ...
Freeing pipeline ...
~ # ffprobe foo.wav
ffprobe version 4.4.1 Copyright (c) 2007-2021 the FFmpeg developers
built with gcc 10.3.1 (Alpine 10.3.1_git20211027) 20211027
[wav @ 0x7f245d686640] Estimating duration from bitrate, this may be inaccurate
Input #0, wav, from 'foo.wav':
Duration: 00:00:04.57, bitrate: 3072 kb/s
Stream #0:0: Audio: pcm_f32le ([3][0][0][0] / 0x0003), 48000 Hz, 2 channels, flt, 3072 kb/s
~ # gst-launch-1.0 jackaudiosrc connect=0 ! audioconvert ! "audio/x-raw,channels=4" ! wavenc ! filesink location=foo.wav
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
ERROR: from element /GstPipeline:pipeline0/GstJackAudioSrc:jackaudiosrc0: Internal data stream error.
New clock: GstAudioSrcClock
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstJackAudioSrc:jackaudiosrc0:
streaming stopped, reason not-negotiated (-4)
Execution ended after 0:00:00.000476941
Setting pipeline to NULL ...
Freeing pipeline ...
```
so this naive approach did not work.
The [documentation](https://gstreamer.freedesktop.org/documentation/jack/jackaudiosrc.html?gi-language=c#jackaudiosrc-page) says that
> It will create **N** Jack ports named in name_num where name is the element name and num is starting from 1. Each port corresponds to a gstreamer channel.
but how to specify this channel number is omitted.
Also the documentation https://gstreamer.freedesktop.org/documentation/jack/jackaudiosrc.html?gi-language=c#jackaudiosrc:port-names states that you can specify an argument `port-names` but this is missing in my version (was introduced in 1.20? - https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/4a5197dc27a3300111df5ee44a613a58ccdabd47) and I tried the whole day to compile gstreamer but it somehow always failed and each try takes more than half an hour. If there is a way to obtain a static binary I would love to try it out as it sounds promising.
I am sorry if this is malformed or is not the proper place to ask such questions.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1096av1decoder: new_picture and start_picture are redundant2022-03-18T12:42:22ZNicolas Dufresneav1decoder: new_picture and start_picture are redundantIn our AV1 decoder base class, I notice that new_picture() and new_sequence() are called in pair, resulting in a redundant set of virtual function. I wonder if new_picture() wasn't meant to be called similarly to vp9 new_sequence(), when...In our AV1 decoder base class, I notice that new_picture() and new_sequence() are called in pair, resulting in a redundant set of virtual function. I wonder if new_picture() wasn't meant to be called similarly to vp9 new_sequence(), when a parameter that would require renegotiation is needed and no compatible sequence header was seen ?
cc @He_Junyan @seungha.yang @dwlsalmeidahttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1095rfbsrc: capital letters (shift+letter) not working2022-03-23T15:41:20ZMarc Leemanrfbsrc: capital letters (shift+letter) not working
gst-plugins-bad
Version: git (or 1.20.1)
Connecting to a VNC server with rfbsrc does no send over capitals (Shift+X, or CAPS LOCK). I suppose other hotkeys can be affected too.
```
gst-launch-1.0 rfbsrc uri=rfb://:admin@192.168.178.7...
gst-plugins-bad
Version: git (or 1.20.1)
Connecting to a VNC server with rfbsrc does no send over capitals (Shift+X, or CAPS LOCK). I suppose other hotkeys can be affected too.
```
gst-launch-1.0 rfbsrc uri=rfb://:admin@192.168.178.79:5903?shared=1 ! videoconvert ! queue ! xvimagesink
```
Connecting with another client (xtigervnc) works as expected
```
xvncviewer password=/home/marc/vncpassword Shared=1 192.168.178.79::5903
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1094video4linux2: Request for backports from master to future 1.20.22023-04-21T09:00:21ZF. Duncanhvideo4linux2: Request for backports from master to future 1.20.2Needed for Raspbery Pi GPU video decoding:
@ndufresne
If not already planned please add these to future 1.20.2
- [ ] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/d394b8b4bdc229ab3a47dd6b666157b57b3eb8a3 and https://gi...Needed for Raspbery Pi GPU video decoding:
@ndufresne
If not already planned please add these to future 1.20.2
- [ ] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/d394b8b4bdc229ab3a47dd6b666157b57b3eb8a3 and https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/e2b2ff26c99723cbbe7129412cc707d0de6d78dd Part of
!1567 needs a backport MR the cherry-pick those, this is ready for backport. [PENDING](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1991)
- [ ] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/fe56af607b7e8ceb265f30b1806833048fbbce98 and https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/24eb35f113404f8f5bd8f2a69bb14058441cb656 Part of !1381 this was delayed to 1.21 due to the complexity. That prooved right, we have a first fixup !1960 and another large patch the fix a regression cause by this one !1968. It totally non-trivial changes to backport, specilly that is it not stable yet.
(Tested on RPi (manjaro) to work as patches to 1.20.0, and apply to 1.20.1)
If possible, also silence the (annoying) warning at line 727 of v4l2/gstv4l2videodec.c
(it seems that this can be triggered by latency in the stream).
v4l2h264dec plugin is broken without these patches.
```
if (frame) {
GstVideoCodecFrame *oldest_frame;
gboolean warned = FALSE; <----------------- set to TRUE in 1.20.2?
/* Garbage collect old frames in case of codec bugs */
while ((oldest_frame = gst_video_decoder_get_oldest_frame (decoder)) &&
check_system_frame_number_too_old (frame->system_frame_number,
oldest_frame->system_frame_number)) {
gst_video_decoder_drop_frame (decoder, oldest_frame);
oldest_frame = NULL;
if (!warned) {
g_warning ("%s: Too old frames, bug in decoder -- please file a bug", <------the warning
GST_ELEMENT_NAME (decoder));
warned = TRUE;
}
}
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/962gst-plugins-good (v4l2) request for backports from master to future 1.20.22022-03-16T20:12:32ZF. Duncanhgst-plugins-good (v4l2) request for backports from master to future 1.20.2Needed for Raspbery Pi GPU video decoding:
@ndufresne
If not already planned please add these to future 1.20.2
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/d394b8b4bdc229ab3a47dd6b666157b57b3eb8a3
https://gitlab.free...Needed for Raspbery Pi GPU video decoding:
@ndufresne
If not already planned please add these to future 1.20.2
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/d394b8b4bdc229ab3a47dd6b666157b57b3eb8a3
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/e2b2ff26c99723cbbe7129412cc707d0de6d78dd
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/fe56af607b7e8ceb265f30b1806833048fbbce98
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/24eb35f113404f8f5bd8f2a69bb14058441cb656
(Tested on RPi (manjaro) to work as patches to 1.20.0, and apply to 1.20.1)
If possible, also silence the (annoying) warning at line 727 of v4l2/gstv4l2videodec.c
(it seems that this can be triggered by latency in the stream).
v4l2h264dec plugin is broken without these patches.
```
if (frame) {
GstVideoCodecFrame *oldest_frame;
gboolean warned = FALSE; <----------------- set to TRUE in 1.20.2?
/* Garbage collect old frames in case of codec bugs */
while ((oldest_frame = gst_video_decoder_get_oldest_frame (decoder)) &&
check_system_frame_number_too_old (frame->system_frame_number,
oldest_frame->system_frame_number)) {
gst_video_decoder_drop_frame (decoder, oldest_frame);
oldest_frame = NULL;
if (!warned) {
g_warning ("%s: Too old frames, bug in decoder -- please file a bug", <------the warning
GST_ELEMENT_NAME (decoder));
warned = TRUE;
}
}
```https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/370macos: document or provide a way to uninstall the package2022-03-16T14:03:37ZStéphane Cerveauscerveau@igalia.commacos: document or provide a way to uninstall the packageWith 1.20.1, there is no option to remove the GStreamer package after installing it.
I found this documentation but its not up to date:
https://codeanticode.wordpress.com/2009/04/03/gstreamer-installer-for-macosx/#:~:text=To%20uninstal...With 1.20.1, there is no option to remove the GStreamer package after installing it.
I found this documentation but its not up to date:
https://codeanticode.wordpress.com/2009/04/03/gstreamer-installer-for-macosx/#:~:text=To%20uninstall%2C%20just%20delete%20the,to%20remove%20the%20setenv%20lines.https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/369macos: package installer layout is incorrect2022-07-16T04:22:20ZStéphane Cerveauscerveau@igalia.commacos: package installer layout is incorrect### Describe your issue
During the macos installation, I noticed that the installer layout is incorrect and the logo is hiding the installer summary
#### Expected Behavior
a better look for the installer
#### Observed Behavior
the l...### Describe your issue
During the macos installation, I noticed that the installer layout is incorrect and the logo is hiding the installer summary
#### Expected Behavior
a better look for the installer
#### Observed Behavior
the logo is over the sumaary
#### Setup
- **Operating System:** MacOs Monterey
- **Device:** Computer
- **GStreamer Version:** 1.20.1
- **Command line:**
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. Download the 1.20.1 installer and run it
### How reproducible is the bug?
Always
### Screenshots if relevant
![Screenshot_2022-03-16_at_10.27.24](/uploads/c95488517bb07628f97d0826c2f45dd4/Screenshot_2022-03-16_at_10.27.24.png)
### Solutions you have tried
### 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/1093macos: document or provide a way to uninstall the package2022-03-16T14:03:24ZStéphane Cerveauscerveau@igalia.commacos: document or provide a way to uninstall the packageWith 1.20.1, there is no option to remove the GStreamer package after installing it.
I found this documentation but its not up to date:
https://codeanticode.wordpress.com/2009/04/03/gstreamer-installer-for-macosx/#:~:text=To%20uninstal...With 1.20.1, there is no option to remove the GStreamer package after installing it.
I found this documentation but its not up to date:
https://codeanticode.wordpress.com/2009/04/03/gstreamer-installer-for-macosx/#:~:text=To%20uninstall%2C%20just%20delete%20the,to%20remove%20the%20setenv%20lines.https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/368The generated .pc files have hardcoded references to prefix instead of ${prefix}2024-02-16T11:43:04ZGeo-mThe generated .pc files have hardcoded references to prefix instead of ${prefix}Hi, after building a gstreamer 1.20 distribution for centos7, the generated build is not relocatable, because of some hardcoded path references in pkg-config files.
What i do is run pkg-config --libs gstreamer-webrtc-1.0 --cflags --def...Hi, after building a gstreamer 1.20 distribution for centos7, the generated build is not relocatable, because of some hardcoded path references in pkg-config files.
What i do is run pkg-config --libs gstreamer-webrtc-1.0 --cflags --define-variable=prefix=/myprefix (where myprefix corresponds to the installed location on the client machine (please correct me if this is the wrong usage)
Unfortunately this results in things like -I/usr/local/gstreamer-1.0/include/orc-0.4, which are the paths i used when building the tarball on the build machine.
In short: not all .pc files have a variable prefix resulting in non-relocatable builds
Thanks
# Update: 20221104
Based on gstreamer-1.0 linux packaging with cerbero
## includedir:
- [x] libavformat
- [x] taglib_c
- [x] libavfilter
- [x] libavutil
- [x] taglib
- [x] libswresample
- [x] libavcodec
- [x] orc 0.4.31 -> 0.4.33
- [x] freetype2
- [x] pango
- [x] pangocairo
- [x] pangoft2
- [x] x264
## libdir
- [ ] dvdnav
- [ ] dvdread
- [ ] expat
- [ ] flac
- [x] gobject-introspection-1.0
- [x] gobject-introspection-no-export-1.0
- [ ] libass
- [x] libavcodec
- [x] libavfilter
- [x] libavformat
- [x] libavutil
- [ ] libcroco-0.6
- [ ] libdca
- [ ] libdts
- [ ] libjpeg
- [ ] libmpg123
- [ ] libpng16
- [ ] librsvg-2.0
- [ ] librtmp
- [x] libswresample
- [x] libtiff-4
- [ ] libturbojpeg
- [ ] libunwind
- [ ] libunwind-coredump
- [ ] libunwind-generic
- [ ] libunwind-ptrace
- [ ] libunwind-setjmp
- [ ] libxml-2.0
- [x] ogg
- [x] opencore-amrnb
- [x] opencore-amrwb
- [x] sbc
- [ ] spandsp
- [x] speex
- [x] taglib
- [x] taglib_c
- [x] theora
- [x] theoradec
- [x] theoraenc
- [ ] vo-aacenc
- [ ] vorbis
- [ ] vorbisenc
- [ ] vorbisfile
- [x] x264
- [ ] zbar