GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-11-20T20:32:35Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/848shout2send: non-blocking I/O usage in libshout has had breaking changes2021-11-20T20:32:35ZAustin Bonandershout2send: non-blocking I/O usage in libshout has had breaking changesTrying to use the `shout2send` plugin with gst-plugins-base 1.18.3-1 on Arch: https://archlinux.org/packages/extra/x86_64/gst-plugins-good/
Which links `libshout-2.4.5`: https://archlinux.org/packages/extra/x86_64/libshout/
Attempting ...Trying to use the `shout2send` plugin with gst-plugins-base 1.18.3-1 on Arch: https://archlinux.org/packages/extra/x86_64/gst-plugins-good/
Which links `libshout-2.4.5`: https://archlinux.org/packages/extra/x86_64/libshout/
Attempting to connect to a local Icecast server with the following:
```
$ docker run -d --name icecast -p 9001:8000 --restart=always infiniteproject/icecast
$ gst-launch-1.0 -m -v audiotestsrc wave=ticks ! audiomixer ! opusenc ! oggmux ! \
shout2send mount='foo.ogg' port=9001 ip=localhost password=hackme username=source
```
I get this error message on the bus and gst-launch quits:
```
Got message #68 from element "shout2send0" (error): GstMessageError, gerror=(GError)NULL, debug=(string)"../gst-plugins-good/ext/shout2/gstshout2.c\(635\):\ gst_shout2send_connect\ \(\):\ /GstPipeline:pipeline0/GstShout2send:shout2send0:\012shout_open\(\)\ failed:\ err\=Please\ retry\ current\ operation.";
```
This seems to be related to the following issue: https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2316
However, as mentioned in the issue above, it's not clear whether `libshout` should be handling the `SHOUTERR_RETRY` error code internally or not. Additionally, this other issue seems to suggest that it's not possible to correctly handle this code _outside_ `libshout`, at least when returned from `shout_open()`: https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2325https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/325bootstrap is failing on ubuntu 20.042021-11-20T21:02:12ZStéphane Cerveauscerveau@igalia.combootstrap is failing on ubuntu 20.04When running cerbero first bootstrap, I get this error after entering my sudo password:
My python version is 3.8.5.
```
The following NEW packages will be installed:
intltool nasm xutils-dev
0 upgraded, 3 newly installed, 0 to remove...When running cerbero first bootstrap, I get this error after entering my sudo password:
My python version is 3.8.5.
```
The following NEW packages will be installed:
intltool nasm xutils-dev
0 upgraded, 3 newly installed, 0 to remove and 2 not upgraded.
Need to get 645 kB of archives.
After this operation, 5,081 kB of additional disk space will be used.
Do you want to continue? [Y/n] Abort.
Traceback (most recent call last):
File "/home/user/DEV/cerbero/cerbero/utils/shell.py", line 192, in new_call
subprocess.check_call(cmd, cwd=cmd_dir, env=env,
File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', 'apt-get', 'install', 'autotools-dev', 'automake', 'autoconf', 'libtool', 'g++', 'autopoint', 'make', 'cmake', 'bison', 'flex', 'nasm', 'pkg-config', 'libxv-dev', 'libx11-dev', 'libx11-xcb-dev', 'libpulse-dev', 'python3-dev', 'gettext', 'build-essential', 'pkg-config', 'libxext-dev', 'libxi-dev', 'x11proto-record-dev', 'libxrender-dev', 'libgl1-mesa-dev', 'libxfixes-dev', 'libxdamage-dev', 'libxcomposite-dev', 'libasound2-dev', 'build-essential', 'gperf', 'wget', 'libxtst-dev', 'libxrandr-dev', 'libglu1-mesa-dev', 'libegl1-mesa-dev', 'git', 'xutils-dev', 'intltool', 'ccache', 'python3-setuptools', 'libssl-dev']' returned non-zero exit status 1.
```
AFAIU, the default value for bootstrap is to prompt for Y or N by default https://gitlab.freedesktop.org/gstreamer/cerbero/-/commit/d1106af4a230774e0609029a35e78d65709014c2https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/342OpenSSL crashes in iOS TestFlight when built GStreamer with cerbero2021-11-20T22:30:37ZThomas W.OpenSSL crashes in iOS TestFlight when built GStreamer with cerberoI have built GStreamer with cerbero and installed the created iOS Framework on my mac. When I now build my app I can use it without any issues when I test the app in developer mode. But when I upload it to TestFlight the app crashes as s...I have built GStreamer with cerbero and installed the created iOS Framework on my mac. When I now build my app I can use it without any issues when I test the app in developer mode. But when I upload it to TestFlight the app crashes as soon as OpenSSL is used.Nirbheek Chauhannirbheek.chauhan@gmail.comNirbheek Chauhannirbheek.chauhan@gmail.comhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/901Update GitHub mirror for monorepo2021-11-22T18:35:38ZOlivier Crêteolivier.crete@ocrete.caUpdate GitHub mirror for monorepoI think there are 2 things that need to be done:
- [x] Update the default branch to `main` in the monorepo
- [ ] Update the descriptions of the other repos to point to the monorepoI think there are 2 things that need to be done:
- [x] Update the default branch to `main` in the monorepo
- [ ] Update the descriptions of the other repos to point to the monorepoSebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/128Head-Related Transfer Function (HRTF) audio filter2021-11-23T08:19:30ZSebastian DrögeHead-Related Transfer Function (HRTF) audio filterhttps://github.com/mrDIMAS/hrtfhttps://github.com/mrDIMAS/hrtfhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/833souphttpsrc: gzip content-encoding causes application/x-gzip output2021-11-24T15:21:53ZKyrylo Polezhaievsouphttpsrc: gzip content-encoding causes application/x-gzip outputApple recommends HLS playlist to be encoded with gzip.
When Content-Encoding is set to gzip, we have "application/x-gzip", not "application/vnd.apple.mpegURL". But when Content-Type is "application/vnd.apple.mpegURL", we should have "app...Apple recommends HLS playlist to be encoded with gzip.
When Content-Encoding is set to gzip, we have "application/x-gzip", not "application/vnd.apple.mpegURL". But when Content-Type is "application/vnd.apple.mpegURL", we should have "application/vnd.apple.mpegURL" output, even if Content-Encoding is gzip.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/899codecs: mpeg2decoder: draining when sequence changes causes output disorder.2021-11-24T16:29:21ZHe Junyancodecs: mpeg2decoder: draining when sequence changes causes output disorder.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/aedd5f0dd1e9bb8945092434fcf77c055e9e6c34
causes the output disorder. The stream such as:[sony-ct2.mpeg2](/uploads/3cbcb08871615760cf4397844f318b65/sony-ct2.mpeg2)
get wrong ou...https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/aedd5f0dd1e9bb8945092434fcf77c055e9e6c34
causes the output disorder. The stream such as:[sony-ct2.mpeg2](/uploads/3cbcb08871615760cf4397844f318b65/sony-ct2.mpeg2)
get wrong output.Nicolas DufresneNicolas Dufresnehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/871Pipeline randomlly hangs at EOS2021-11-25T01:52:32ZNghia Truong TrungPipeline randomlly hangs at EOSI'm developing a video recording application on NVIDIA Jetson Nano. My application runs on more than 200 Jetson Nano devices, each record 3-10 videos per day. A single device usually records 40-45 minutes with a 5 minute interval in-betw...I'm developing a video recording application on NVIDIA Jetson Nano. My application runs on more than 200 Jetson Nano devices, each record 3-10 videos per day. A single device usually records 40-45 minutes with a 5 minute interval in-between. The problem is: sometimes (< 5%) a video is corrupted and cannot be post-processed.
The pipeline (line breaks added for readability):
```
v4l2src name=video_source
! videorate ! video/x-raw, height=720, width=1280, framerate=30/1
! nvvidconv
! omxh264enc
! queue
! mux.
pulsesrc device=alsa_input.usb-046d_Logitech_BRIO_FC1248A5-03.analog-stereo name=audio_source
! audio/x-raw, rate=44100, channels=2, width=32, depth=32
! queue max-size-buffers=0 max-size-time=0 max-size-bytes=0
! lamemp3enc bitrate=256
! queue
! mux.
qtmux name=mux
! filesink location=filename.mp4
```
I tried running this pipeline with the Python binding (`Gst.parse_launch`) and `gst-launch-1.0` and had problems with both.
- Using the Python binding, I set a clock event on the pipeline's clock object. When it fires, I send and EOS event to the pipeline. My log indicates that the call to `pipeline.send_event` is always made, but sometimes fail to return.
- Using `gst-launch-1.0`, I added the `-e` flag (force EOS) and use a Python's `subprocess` to initiate the process. The main Python process then simply sleeps 40-45 minutes then send a SIGINT event to the subprocess. The log by `gst-launch-1.0` sometimes stop at `EOS on shutdown enabled -- Forcing EOS on the pipeline`.
In either case, the camera is not released and need to be terminated by hand. The resulting video is corruped (missing the moov atom) and cannot be played or read with OpenCV for further processing.
Is this a problem with my pipeline, or a device specific problem, or a Gstreamer bug?
How do I fix this?
---
Device: NVIDIA Jetson Nano
OS: Ubuntu 18.04
Gstreamer version:
```
~$ dpkg -l | grep gstreamer
ii gir1.2-gstreamer-1.0:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GObject introspection data for the GStreamer library
ii gstreamer1.0-alsa:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer plugin for ALSA
ii gstreamer1.0-clutter-3.0:arm64 3.0.26-1 arm64 Clutter PLugin for GStreamer 1.0
ii gstreamer1.0-gl:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer plugins for GL
ii gstreamer1.0-libav:arm64 1.14.5-0ubuntu1~18.04.1 arm64 libav plugin for GStreamer
ii gstreamer1.0-packagekit 1.1.9-1ubuntu2.18.04.6 arm64 GStreamer plugin to install codecs using PackageKit
ii gstreamer1.0-plugins-bad:arm64 1.14.5-0ubuntu1~18.04.1 arm64 GStreamer plugins from the "bad" set
ii gstreamer1.0-plugins-base:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer plugins from the "base" set
ii gstreamer1.0-plugins-base-apps 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer helper programs from the "base" set
ii gstreamer1.0-plugins-good:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer plugins from the "good" set
ii gstreamer1.0-plugins-ugly:arm64 1.14.5-0ubuntu1~18.04.1 arm64 GStreamer plugins from the "ugly" set
ii gstreamer1.0-pulseaudio:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer plugin for PulseAudio
ii gstreamer1.0-tools 1.14.5-0ubuntu1~18.04.2 arm64 Tools for use with GStreamer
ii gstreamer1.0-x:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer plugins for X11 and Pango
ii libgstreamer-gl1.0-0:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer GL libraries
ii libgstreamer-plugins-bad1.0-0:arm64 1.14.5-0ubuntu1~18.04.1 arm64 GStreamer libraries from the "bad" set
ii libgstreamer-plugins-base1.0-0:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer libraries from the "base" set
ii libgstreamer-plugins-base1.0-dev:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer development files for libraries from the "base" set
ii libgstreamer-plugins-good1.0-0:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer development files for libraries from the "good" set
ii libgstreamer1.0-0:arm64 1.14.5-0ubuntu1~18.04.2 arm64 Core GStreamer libraries and elements
ii libgstreamer1.0-dev:arm64 1.14.5-0ubuntu1~18.04.2 arm64 GStreamer core development files
ii nvidia-l4t-gstreamer 32.3.1-20191209225816 arm64 NVIDIA GST Application files
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/903Bad performance when restream input audio/video stream to rtmp2021-11-25T12:35:20ZBruno ScrivoBad performance when restream input audio/video stream to rtmpHello,
I have a video/audio flv stream coming in from the tcp port. What I need to do is read the input stream, edit the input frame and input audio sample, and re-send the edited audio and video to another rtmp server. Video and audio...Hello,
I have a video/audio flv stream coming in from the tcp port. What I need to do is read the input stream, edit the input frame and input audio sample, and re-send the edited audio and video to another rtmp server. Video and audio need to be synchronous.
I'm realizing a c++ code using the following pipeline and gstreamer library.
```bash
tcpclientsrc host=192.168.16.10 port=5000 ! \
flvdemux name=demux \
flvmux name=mux \
demux.audio ! queue ! appsink name=mysinkaudio \
demux.video ! h264parse ! avdec_h264 ! queue ! appsink name=mysink \
appsrc name=mysrc format=3 is-live=true ! nvh264enc ! h264parse ! queue ! mux.video \
appsrc name=mysrcaudio format=3 ! queue ! mux.audio \
mux. ! rtmpsink location=rtmp://localhost/show/stream sync=false async=false
```
My callback when I receive a video sample is this:
```c++
/* The appsink has received a buffer */
GstFlowReturn EditableStreamCapture::new_sample_video (GstElement *sink, EditableStreamCapture *data) {
auto start = std::chrono::high_resolution_clock::now();
GstSample *sample;
GstFlowReturn ret = GST_FLOW_ERROR;
/* Retrieve the buffer */
g_signal_emit_by_name (sink, "pull-sample", &sample);
if (sample) {
if (!data->is_enough_data)
{
g_signal_emit_by_name (data->app_src_video, "push-sample", sample, &ret);
}
gst_sample_unref (sample);
ret = GST_FLOW_OK;
}
auto stop = std::chrono::high_resolution_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(stop - start);
qDebug() << "[EditableStreamCapture]Duration: " << duration.count();
return ret;
}
```
Audio callback is this:
```c++
GstFlowReturn EditableStreamCapture::new_sample_audio (GstElement *sink, EditableStreamCapture *data) {
GstSample *sample;
GstBuffer *buffer;
GstFlowReturn ret;
GstMapInfo info;
/* Retrieve the buffer */
g_signal_emit_by_name (sink, "pull-sample", &sample);
if (sample) {
/* The only thing we do in this example is print a * to indicate a received buffer */
if (!data->is_enough_data)
{
//qDebug () << "*audio ";
g_signal_emit_by_name (data->app_src_audio, "push-sample", sample, &ret);
}
gst_sample_unref (sample);
return GST_FLOW_OK;
}
return GST_FLOW_ERROR;
}
```
Well, my problem is that the output stream is really bad and slow, while the input is very smooth. Currently I'm using nvh264enc for h264 encoding on a nvidia Quadro P600 Mobile.
Maybe something wrong in my pipeline? Video input resolution is 1920 x 1080, with 25 fps. The application runs on a i7, 8th Gen with 12 cores. I tried to remove the audio, but the problem persists. Thank you :)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/42segment: frame stepping returns video to the start + gst_segment_do_seek: ass...2021-11-26T08:24:43ZBugzilla Migration Usersegment: frame stepping returns video to the start + gst_segment_do_seek: assertion 'start <= stop' failed## Submitted by sam tygier
**[Link to original bug (#706307)](https://bugzilla.gnome.org/show_bug.cgi?id=706307)**
## Description
Using totem-3.8.2-1.fc19.x86_64 and gstreamer1-1.0.9-1.fc19.x86_64 on fedora 19.
To reproduce:
...## Submitted by sam tygier
**[Link to original bug (#706307)](https://bugzilla.gnome.org/show_bug.cgi?id=706307)**
## Description
Using totem-3.8.2-1.fc19.x86_64 and gstreamer1-1.0.9-1.fc19.x86_64 on fedora 19.
To reproduce:
1) Open the a theora video file, http://v2v.cc/~j/theora_testsuite/320x240.ogg
2) It will start playing, pause it about 1 second in by pressing space
3) press ',' (comma) to step back 1 frame
4) press '.' (full stop) to step forwards one frame
Expected result:
Steps forward 1 frame
Actual result:
Video return to start
In terminal I see the message
(totem:3794): GStreamer-CRITICAL **: gst_segment_do_seek: assertion `start <= stop' failed
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/905vaapisink: pipeline get aborted with two thread pipeline execute in gst-laun...2021-11-26T08:59:16ZLim Siew Hoonvaapisink: pipeline get aborted with two thread pipeline execute in gst-launch-1.0The pipeline get aborted after execute gst-pipeline. It only able to reproduce if using vaapisink plugins. Tested with fakesink / glimagesink does not seeing this issue.
#### Expected Behavior
It should be able finish playing video and ...The pipeline get aborted after execute gst-pipeline. It only able to reproduce if using vaapisink plugins. Tested with fakesink / glimagesink does not seeing this issue.
#### Expected Behavior
It should be able finish playing video and exit without any issue.
#### Observed Behavior
It immediately showing this error:
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
malloc(): unaligned tcache chunk detected
Aborted
#### Setup
- **Operating System:** Ubuntu, Yocto
- **GStreamer Version:** 1.19.2 or latest main branch (commit id: d867180b4e6efec3a0a866e4123938dbe0a4a79c)
- Media Stack Q3'2021 release - iHD driver, libva 2.13.0 version.
- **Command line:**
gst-launch-1.0 \
filesrc location=remote_1080_8bit_3mbps_noB.265 ! h265parse ! vaapih265dec ! vaapisink \
filesrc location=remote_1080_8bit_3mbps_noB.265 ! h265parse ! vaapih265dec ! vaapisink \
filesrc location=remote_1080_8bit_3mbps_noB.265 ! h265parse ! vaapih265dec ! vaapisink
### Steps to reproduce the bug
1. open terminal
2. Run command above gst-pipeline
### How reproducible is the bug?
The issue is always easy to reproduce with command provided.
### Additional Information
Last test passing before 1.19.2 upgrade:
gstreamer-vaapi commit id: ac51e4192838ccdc8f4a555b784fc2f277031f0chttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/907webrtcbin: nicesink should disable drop_out_of_segment2021-11-26T16:11:38ZGuillaume Desmotteswebrtcbin: nicesink should disable drop_out_of_segmentMy webrtcbin pipeline wasn't sending data to my peer. I took me a while to figure out it was because of:
```
0:02:07.294114779 475677 0x7f6a5c057860 DEBUG basesink gstbasesink.c:4009:gst_base_sink_chain_unlocked:<nicesink1...My webrtcbin pipeline wasn't sending data to my peer. I took me a while to figure out it was because of:
```
0:02:07.294114779 475677 0x7f6a5c057860 DEBUG basesink gstbasesink.c:4009:gst_base_sink_chain_unlocked:<nicesink1> dropping buffer, out of clipping segment
```
I discussed this @slomo who suggested that `webrtcbin` should likely call `gst_base_sink_set_drop_out_of_segment(FALSE)` on `nicesink`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1692hlssink2 does not support async flag anymore in 1.19.3 and hangs during ingest2021-11-30T19:12:50ZGuru Govindanhlssink2 does not support async flag anymore in 1.19.3 and hangs during ingestVersion:
```
root@907fb86a2171:/tmp/# gst-launch-1.0 --version
gst-launch-1.0 version 1.19.3
GStreamer 1.19.3
```
I built gstreamer with 1.19.3 tag and I am running into issues running the following pipeline to ingest rtsp stream.
In the...Version:
```
root@907fb86a2171:/tmp/# gst-launch-1.0 --version
gst-launch-1.0 version 1.19.3
GStreamer 1.19.3
```
I built gstreamer with 1.19.3 tag and I am running into issues running the following pipeline to ingest rtsp stream.
In the previous version (GStreamer 1.18.4) I was able to use async=false and able to do an ABR transcode with an rtsp stream.
I am testing the 1.19.3 and I am running into issues ingesting a pipeline like the following. I have added a encode_ingest_360 but not yet transcoded. But that already hangs.
The following is an example of the pipeline and its output
```
root@907fb86a2171:/# GST_DEBUG=3 gst-launch-1.0 hlssink2 name=ingest playlist-length=0 max-files=0 target-duration=5 \
send-keyframe-requests=true playlist-location=stream0.m3u8 location="fragment%00005d.ts" hlssink2 name=enc_ingest_360 \ playlist-length=5 max-files=5 target-duration=2 send-keyframe-requests=true playlist-location="/spot-tmp/gst1/360/enc_stream1.m3u8" location="/spot-tmp/gst1/360/fa%05d.ts" \
rtspsrc location="rtsp://admin:pass@10.0.0.15:554/cam/realmonitor?channel=1&subtype=0" protocols=4 name=rtspsrc0 \
rtspsrc0. ! rtph264depay ! h264parse ! tee name=t t.! queue ! ingest.video rtspsrc0. ! decodebin ! queue ! audiorate ! \
audioconvert ! fdkaacenc ! tee name=audio_t audio_t. ! ingest.audio
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Pipeline is PREROLLED ...
Prerolled, waiting for progress to finish...
Progress: (connect) Connecting to rtsp://admin:pass@10.0.0.15:554/cam/realmonitor?channel=1&subtype=0
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (request) SETUP stream 1
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending PLAY request
Progress: (request) Sending PLAY request
Progress: (request) Sent PLAY request
Redistribute latency...
Redistribute latency...
Redistribute latency...
0:00:02.166829738 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.167791992 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.168418079 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.168726499 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.168879268 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.169126105 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.169335588 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.169486487 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.169720183 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.169959725 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.170102934 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.170337681 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.170582701 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.170725907 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.170974450 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.171218938 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.171361875 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.171601589 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.295854905 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.303176343 2930910 0x7fbe7404a360 WARN audiodecoder gstaudiodecoder.c:1535:gst_audio_decoder_finish_frame_or_subframe:<fdkaacdec0> Can't copy metadata because input buffers disappeared
0:00:02.303475577 2930910 0x5567570d5a40 FIXME basesink gstbasesink.c:3395:gst_base_sink_default_event:<giostreamsink0> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
0:00:02.303535167 2930910 0x5567570d5a40 WARN gio_base_sink gstgiobasesink.c:219:gst_gio_base_sink_event:<giostreamsink0> ignored SEGMENT event in time format
Redistribute latency...
^Chandling interrupt.:99.
```
I appreciate any help in this.
Thanks,
Guruhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/898souphttpsrc: source:src thread disappears even though handshake_thread task i...2021-12-01T00:54:04Zkwange eekwange@gmail.comsouphttpsrc: source:src thread disappears even though handshake_thread task is runningRegarding this issue, an issue was created in glib-networking and discussion was ongoing.
https://gitlab.gnome.org/GNOME/glib-networking/-/issues/176
However, I still couldn't find a clue as to why the parent thread that created the ta...Regarding this issue, an issue was created in glib-networking and discussion was ongoing.
https://gitlab.gnome.org/GNOME/glib-networking/-/issues/176
However, I still couldn't find a clue as to why the parent thread that created the task disappeared first, so I opened an issue to Gstreamer.
With the following relationship, handshake_thread starts with g_task_run_in_thread through source:src thread,
Sometimes there is a problem in the process of stopping the pipeline when the network situation is terrible.
If I check the crash dump, handshake_thread (pool-pipe-m) is a situation in which a crash occurred during the operation for error string handling, and strangely, at this time, source:src has already disappeared and is not visible.
My guess is that the source:src that created the tls object is gone, which is the cause of the crash of handshake_thread that needs to use the tls object(err_string_lock).
As discussed in glib-networking, it is nonsense that source:src disappears before handshake_thread terminates.
In the normal case backtrace.
```
Thread 2.6 "source:src" hit Breakpoint 2, g_tls_connection_base_handshake (conn=0xf18121b8, cancellable=0x169a770, error=0xf21bc864)
at ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c:1534
1534 ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c: No such file or directory.
(gdb) bt
#0 g_tls_connection_base_handshake (conn=0xf18121b8, cancellable=0x169a770, error=0xf21bc864) at ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c:1534
#1 0xf5d8ab0c in ?? () from /usr/lib/libsoup-2.4.so.1
#2 0xf5d6d646 in ?? () from /usr/lib/libsoup-2.4.so.1
#3 0xf5d87528 in ?? () from /usr/lib/libsoup-2.4.so.1
#4 0xf5d87f0e in soup_session_send () from /usr/lib/libsoup-2.4.so.1
#5 0xf21e6eb2 in gst_soup_http_src_send_message (src=0x16a81e0) at ../git/ext/soup/gstsouphttpsrc.c:1923
#6 gst_soup_http_src_do_request (src=src@entry=0x16a81e0, method=<optimized out>) at ../git/ext/soup/gstsouphttpsrc.c:1999
#7 0xf21e8532 in gst_soup_http_src_create (psrc=0x16a81e0, outbuf=0xf21bcb4c) at ../git/ext/soup/gstsouphttpsrc.c:2191
Thread 2.8 "pool-pipe-m" hit Breakpoint 4, handshake_thread (task=0x15c22e0, object=0xf18121b8, task_data=0xf1814ba0, cancellable=0x169a770)
at ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c:1350
1350 in ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c
(gdb) bt
#0 handshake_thread (task=0x15c22e0, object=0xf18121b8, task_data=0xf1814ba0, cancellable=0x169a770) at ../glib-networking-2.62.4/tls/base/gtlsconnection-base.c:1350
#1 0xf5e936a0 in ?? () from /usr/lib/libgio-2.0.so.0
#2 0xf78fbe48 in ?? () from /usr/lib/libglib-2.0.so.0
#3 0xf78fb8ee in ?? () from /usr/lib/libglib-2.0.so.0
#4 0xf7748898 in start_thread (arg=0x7ca98217) at pthread_create.c:477
```
When a crash occurs in handshake_thread as shown below, source:src has already disappeared.
```
Signal: 11
SignalCode: 1, SEGV_MAPERR
SignalSender: 28
FaultAddress: 0x0000001c
Register dump:
r0: 0x00000000 r1: 0xf6c69f6d r2: 0xf22fd140 r3: 0xf22fd600
r4: 0xf6d43f10 r5: 0xf22fc858 r6: 0xf22fc988 r7: 0xf22fc988
r8: 0xffffffff r9: 0x00000000 r10: 0xf3652ee0 fp: 0xf365352c
ip: 0xf6d4288c sp: 0xf22fc840 lr: 0xf6cb068b pc: 0xf79cb41c
cpsr: 0x00000030
Disassemble:
...
0xf79cb414: mrc p15, #0, r3, c13, c0, #3
0xf79cb418: sub.w r2, r3, #0x4c0
***** 0xf79cb41c: ldr r3, [r0, #0x1c]
PC: /lib/libpthread-2.31.so [0xf79cb41c]
LR: /usr/lib/libcrypto.so.1.1 [0xf6cb068b]
Backtrace: tid = 14905
/lib/libpthread-2.31.so (__pthread_rwlock_rdlock+0x7) [0xf79cb41c] // crash occurred here in pool-pipe-m. is err_string_lock contained in tls object invalid?
/usr/lib/libcrypto.so.1.1 (CRYPTO_THREAD_read_lock+0x6) [0xf6cb068b]
/usr/lib/libcrypto.so.1.1 (ENGINE_set_RSA+0xf6) [0xf6c6a00b]
/usr/lib/libcrypto.so.1.1 (ERR_lib_error_string+0x28) [0xf6c6a32d]
/usr/lib/libcrypto.so.1.1 (ERR_error_string_n+0x18) [0xf6c6a3e1]
/usr/lib/gio/modules/libgioopenssl.so (g_io_openssl_query+0x1a26) [0xf364c55b]
g_tls_connection_openssl_handshake_thread_handshake, gtlsconnection-openssl.c:318
/usr/lib/gio/modules/libgioopenssl.so (g_io_openssl_query+0x62ac) [0xf3650de1]
handshake_thread, gtlsconnection-base.c:1414
/usr/lib/libgio-2.0.so.0.6200.6 (g_task_attach_source+0x1b0) [0xf61166a1]
/usr/lib/libglib-2.0.so.0.6200.6 (g_get_num_processors+0x188) [0xf7b7ae49]
/usr/lib/libglib-2.0.so.0.6200.6 (g_test_get_filename+0xd6) [0xf7b7a8ef]
/lib/libpthread-2.31.so (start_thread+0x90) [0xf79c7899]
/lib/libc-2.31.so (clone+0x3c) [0xf6ec4aad]
Backtrace: tid = 8112
/lib/libpthread-2.31.so (__libc_do_syscall+0x5) [0xf79d1b26]
/lib/libpthread-2.31.so (__pthread_clockjoin_ex+0x176) [0xf79c8983]
/lib/libpthread-2.31.so (pthread_join+0x10) [0xf79c8799]
/usr/lib/libsystrim.so.3.0.0 (end_watch+0xd6) [0xf7d1623f]
/lib/ld-2.31.so (_dl_fini+0x160) [0xf7d35011]
/lib/libc-2.31.so (__run_exit_handlers+0x108) [0xf6e54c19]
/lib/libc-2.31.so (exit+0xe) [0xf6e54cdb]
/lib/libc-2.31.so (__libc_start_main+0x9c) [0xf6e44be9]
/usr/sbin/media-pipeline (_start+0x34) [0xa88351]
Backtrace: tid = 14903
/lib/libc-2.31.so (syscall+0xf) [0xf6ec2730]
/usr/lib/libglib-2.0.so.0.6200.6 (g_cond_wait_until+0x8e) [0xf7b922a7]
/usr/lib/libglib-2.0.so.0.6200.6 (g_byte_array_sort_with_data+0x9e) [0xf7b3e74b]
/usr/lib/libglib-2.0.so.0.6200.6 (g_get_num_processors+0x300) [0xf7b7afc1]
/usr/lib/libglib-2.0.so.0.6200.6 (g_test_get_filename+0xd6) [0xf7b7a8ef]
/lib/libpthread-2.31.so (start_thread+0x90) [0xf79c7899]
/lib/libc-2.31.so (clone+0x3c) [0xf6ec4aad]
Backtrace: tid = 14904
/lib/libc-2.31.so (__libc_do_syscall+0x3) [0xf6e44e24]
/lib/libc-2.31.so (__poll+0x3c) [0xf6ebe535]
/usr/lib/libglib-2.0.so.0.6200.6 (g_main_context_dispatch+0x2aa) [0xf7b5f39b]
/usr/lib/libglib-2.0.so.0.6200.6 (g_main_context_iteration+0x1c) [0xf7b5f449]
/usr/lib/libglib-2.0.so.0.6200.6 (g_main_context_iteration+0x48) [0xf7b5f475]
/usr/lib/libglib-2.0.so.0.6200.6 (g_test_get_filename+0xd6) [0xf7b7a8ef]
/lib/libpthread-2.31.so (start_thread+0x90) [0xf79c7899]
/lib/libc-2.31.so (clone+0x3c) [0xf6ec4aad]
Thread Info:
Tid: 14905
Comm: pool-pipe-m
```
It's not easy to reproduce the problem, so I haven't gotten GST_DEBUG yet, but if it does, I'll look at the gsttask log.
Can't we guess the cause of the parent thread disappearing even though the task is running in sync with only the small information above?
Additionally, got log as below.
Abnormal case, source:src task joined with souphttp's cancelled operation.
```
0:00:03.785770340 16045 0x1ae41a0 DEBUG task gsttask.c:431:gst_task_new: Created task 0x1afa828
0:00:03.785819520 16045 0x1ae41a0 INFO task gsttask.c:460:gst_task_set_lock: setting stream lock 0x1a2b610 on task 0x1afa828
0:00:03.790379100 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:459:gst_base_src_init:<GstBaseSrc@0x1b0c1e0> creating src pad
0:00:03.790426860 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:462:gst_base_src_init:<GstBaseSrc@0x1b0c1e0> setting functions on src pad
0:00:03.790437600 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:470:gst_base_src_init:<GstBaseSrc@0x1b0c1e0> adding src pad
0:00:03.790446340 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:486:gst_base_src_init:<GstBaseSrc@0x1b0c1e0> init done
0:00:03.790827760 16045 0x1ae41a0 INFO basesrc gstbasesrc.c:2309:gst_base_src_set_property:<source> passed structure is [smart-properties, real-time=(boolean)true, adaptive-mode=(boolean)true;], result structure is [smart-properties, push-mode=(boolean)true, real-time=(boolean)true, adaptive-mode=(boolean)true;]
0:00:03.790927460 16045 0x1ae41a0 INFO basesrc gstbasesrc.c:2309:gst_base_src_set_property:<source> passed structure is [smart-properties, interleaving-type=(int)0, drm-mediauri=(string)"https://live.sdn.wavve.com/hls/C4102/KR/1/2000/live.m3u8\?....", low-percent=(int)98, dolby-vision-support=(boolean)true;], result structure is [smart-properties, push-mode=(boolean)true, real-time=(boolean)true, adaptive-mode=(boolean)true, interleaving-type=(int)0, drm-mediauri=(string)"https://live.sdn.wavve.com/hls/C4102/KR/1/2000/live.m3u8\?....", low-percent=(int)98, dolby-vision-support=(boolean)true;]
0:00:03.790995060 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:1446:gst_base_src_default_query:<source> query caps returns 1
0:00:03.791418620 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:1446:gst_base_src_default_query:<source> query caps returns 1
0:00:03.791568720 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:4091:gst_base_src_activate_mode:<source:src> activating in mode 1
0:00:03.791577420 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:4017:gst_base_src_activate_push:<source> Activating in push mode
0:00:03.791587200 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:2241:gst_soup_http_src_start:<source> start("https://live.sdn.wavve.com/hls/C4102/KR/1/2000/live.m3u8?....")
0:00:03.791606520 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:1122:gst_soup_http_src_session_open:<source> dlna opval = 273, flagval=273, src->is_dtcp:0
0:00:03.791625640 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:1132:gst_soup_http_src_session_open:<source> no dlna
0:00:03.791652660 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:1186:gst_soup_http_src_session_open:<source> Creating session (can share 0)
0:00:03.801733600 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:3714:gst_base_src_start_complete:<source> starting source
0:00:03.801758220 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:2349:gst_soup_http_src_get_size:<source> get_size() = FALSE
0:00:03.801773380 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:3727:gst_base_src_start_complete:<source> setting size 18446744073709551615
0:00:03.801797100 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:3735:gst_base_src_start_complete:<source> format: bytes, have size: 0, size: 18446744073709551615, duration: -1
0:00:03.801814260 16045 0x1ae41a0 INFO souphttpsrc gstsouphttpsrc.c:2386:gst_soup_http_src_is_seekable:<source> seekable : 0
0:00:03.801820720 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:3741:gst_base_src_start_complete:<source> is seekable: 0
0:00:03.801825520 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:3746:gst_base_src_start_complete:<source> is random_access: 0
0:00:03.801843740 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:1755:gst_base_src_perform_seek:<source> doing seek: (NULL)
0:00:03.801855300 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:1822:gst_base_src_perform_seek:<source> seek with seqnum 22
0:00:03.801863280 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:1857:gst_base_src_perform_seek:<source> segment configured from 0 to -1, position 0
0:00:03.801888880 16045 0x1ae41a0 INFO basesrc gstbasesrc.c:1495:gst_base_src_do_seek:<source> seeking: bytes segment start=0, offset=0, stop=-1, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0, base=0, position 0, duration -1
0:00:03.801900400 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:2396:gst_soup_http_src_do_seek:<source> do_seek(0-18446744073709551615)
0:00:03.801905500 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:2415:gst_soup_http_src_do_seek:<source> Seek to current read/end position and no seek pending
0:00:03.801933020 16045 0x1ae41a0 DEBUG task gsttask.c:431:gst_task_new: Created task 0x1afa8d0
0:00:03.801942360 16045 0x1ae41a0 INFO task gsttask.c:460:gst_task_set_lock: setting stream lock 0x1af9294 on task 0x1afa8d0
0:00:03.802111720 16045 0x1ae41a0 DEBUG task gsttask.c:673:gst_task_set_state_unlocked:<task1> Changing task 0x1afa8d0 to state 0
0:00:03.802259380 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:3851:gst_base_src_start_wait:<source> got ok
0:00:03.802821800 16045 0x19e7950 DEBUG task gsttask.c:283:gst_task_func: Entering task 0x1afa8d0, thread 0x19e7950
0:00:03.802934060 16045 0x19e7950 DEBUG task gsttask.c:245:gst_task_configure_name:<source:src> Setting thread name to 'source:src'
0:00:03.803022880 16045 0x19e7950 DEBUG basesrc gstbasesrc.c:1000:gst_base_src_send_stream_start:<source> Pushing STREAM_START
0:00:03.803059000 16045 0x19e7950 DEBUG basesrc gstbasesrc.c:3567:gst_base_src_negotiate_unlocked:<source> starting negotiation
0:00:03.803084520 16045 0x19e7950 DEBUG basesrc gstbasesrc.c:1446:gst_base_src_default_query:<source> query caps returns 1
0:00:03.803094520 16045 0x19e7950 DEBUG basesrc gstbasesrc.c:3496:gst_base_src_default_negotiate:<source> caps of src: ANY
0:00:03.803100540 16045 0x19e7950 DEBUG basesrc gstbasesrc.c:3542:gst_base_src_default_negotiate:<source> no negotiation needed
0:00:03.803121420 16045 0x19e7950 DEBUG basesrc gstbasesrc.c:3436:gst_base_src_prepare_allocation:<source> peer ALLOCATION query failed
0:00:03.803165680 16045 0x19e7950 DEBUG basesrc gstbasesrc.c:3442:gst_base_src_prepare_allocation:<source> ALLOCATION (1) params: allocation query: 0xf2105cc0, GstQueryAllocation, caps=(GstCaps)"NULL", need-pool=(boolean)true, allocator=(GArray)NULL, pool=(GArray)NULL;
0:00:03.803192600 16045 0x19e7950 LOG basesrc gstbasesrc.c:3026:gst_base_src_loop:<source> next_ts 0:00:00.000000000 size 24576
0:00:03.803241000 16045 0x19e7950 DEBUG basesrc gstbasesrc.c:2594:gst_base_src_update_length:<source> reading offset 0, length 24576, size -1, segment.stop -1, maxsize -1
0:00:03.803251620 16045 0x19e7950 DEBUG basesrc gstbasesrc.c:2702:gst_base_src_get_range:<source> calling create offset 0 length 24576, time 0
0:00:03.803269660 16045 0x19e7950 LOG souphttpsrc gstsouphttpsrc.c:1973:gst_soup_http_src_do_request:<source> Running request for method: GET
0:00:03.803834180 16045 0x19e7950 DEBUG souphttpsrc gstsouphttpsrc.c:989:gst_soup_http_src_add_range_header:<source> Appending byte range header bytes=0-
0:00:03.803849900 16045 0x19e7950 DEBUG souphttpsrc gstsouphttpsrc.c:1020:_append_extra_header:<source> Appending extra header: "Referer: http://lgchplus-test.wavve.com/?lg_server=qa2"
0:00:03.850823360 16045 0x1ae41a0 DEBUG task gsttask.c:673:gst_task_set_state_unlocked:<task0> Changing task 0x1afa828 to state 1
0:00:03.850850440 16045 0x1ae41a0 DEBUG task gsttask.c:853:gst_task_join:<task0> Joining task 0x1afa828, thread 0x1ae41a0
0:00:03.850857520 16045 0x1ae41a0 DEBUG task gsttask.c:883:gst_task_join:<task0> Joined task 0x1afa828
0:00:03.850869340 16045 0x1ae41a0 DEBUG task gsttask.c:210:gst_task_finalize: task 0x1afa828 finalize
0:00:03.851063320 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:4091:gst_base_src_activate_mode:<source:src> activating in mode 1
0:00:03.851079920 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:4025:gst_base_src_activate_push:<source> Deactivating in push mode
0:00:03.851085400 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:3862:gst_base_src_stop:<source> stopping source
0:00:03.851091180 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:3912:gst_base_src_set_flushing:<source> flushing 1
0:00:03.851097240 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:2317:gst_soup_http_src_unlock:<source> unlock()
0:00:03.851147180 16045 0x1ae41a0 DEBUG task gsttask.c:673:gst_task_set_state_unlocked:<source:src> Changing task 0x1afa8d0 to state 1
0:00:03.852869420 16045 0x19e7950 DEBUG souphttpsrc gstsouphttpsrc.c:1927:gst_soup_http_src_send_message:<source> Sending message failed: Operation was cancelled(19)
0:00:03.852895540 16045 0x19e7950 DEBUG souphttpsrc gstsouphttpsrc.c:2210:gst_soup_http_src_create:<source> Returning -2 flushing
0:00:03.852907460 16045 0x19e7950 DEBUG basesrc gstbasesrc.c:2842:gst_base_src_get_range:<source> create returned -2 (flushing)
0:00:03.852915460 16045 0x19e7950 INFO basesrc gstbasesrc.c:3037:gst_base_src_loop:<source> pausing after gst_base_src_get_range() = flushing
0:00:03.852921980 16045 0x19e7950 DEBUG basesrc gstbasesrc.c:3207:gst_base_src_loop:<source> pausing task, reason flushing
0:00:03.852971900 16045 0x19e7950 DEBUG task gsttask.c:355:gst_task_func: Exit task 0x1afa8d0, thread 0x19e7950
0:00:03.852998900 16045 0x1ae41a0 DEBUG task gsttask.c:853:gst_task_join:<source:src> Joining task 0x1afa8d0, thread 0x1ae41a0
0:00:03.853006620 16045 0x1ae41a0 DEBUG task gsttask.c:883:gst_task_join:<source:src> Joined task 0x1afa8d0
0:00:03.853014400 16045 0x1ae41a0 DEBUG task gsttask.c:210:gst_task_finalize: task 0x1afa8d0 finalize
0:00:03.853024080 16045 0x1ae41a0 DEBUG basesrc gstbasesrc.c:3912:gst_base_src_set_flushing:<source> flushing 0
0:00:03.853031840 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:2330:gst_soup_http_src_unlock_stop:<source> unlock_stop()
0:00:03.853067260 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:2252:gst_soup_http_src_stop:<source> stop()
0:00:03.853074660 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:1289:gst_soup_http_src_session_close:<source> Closing session
0:00:03.853199260 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:1289:gst_soup_http_src_session_close:<source> Closing session
0:00:03.854018640 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:618:gst_soup_http_src_dispose:<source> dispose
0:00:03.854034940 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:1289:gst_soup_http_src_session_close:<source> Closing session
0:00:03.854051180 16045 0x1ae41a0 DEBUG souphttpsrc gstsouphttpsrc.c:635:gst_soup_http_src_finalize:<source> finalize
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/906vaapi: crash in vaGetImage when mapping frame in xvimagesink, with iHD_drv_video2021-12-01T05:46:30ZNeel Nvaapi: crash in vaGetImage when mapping frame in xvimagesink, with iHD_drv_video### Describe your issue
Segv while trying to playback a mp4 file
#### Expected Behavior
<!-- What did you expect to happen -->
no crash
#### Observed Behavior
<!-- What actually happened -->
#### Setup
- **Operating System:** Ubuntu 2...### Describe your issue
Segv while trying to playback a mp4 file
#### Expected Behavior
<!-- What did you expect to happen -->
no crash
#### Observed Behavior
<!-- What actually happened -->
#### Setup
- **Operating System:** Ubuntu 21.10
- **Device:** Computer
- **GStreamer Version:** 1.18.5
- **Command line:**
`gst-launch-1.0 playbin uri=file://file.mp4`
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type `gst-launch-1.0 playbin uri=file://file.mp4`
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Always
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->
debug log attached. [crash.log](/uploads/6c6cc78324ccccd114b07c4b7665c951/crash.log)
GDB session is below
```
gdb) run playbin uri=file:///file.mp4
Starting program: /usr/bin/gst-launch-1.0 playbin uri=file:///file.mp4
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Setting pipeline to PAUSED ...
[New Thread 0x7ffff623a640 (LWP 108607)]
Pipeline is PREROLLING ...
[New Thread 0x7ffff5a39640 (LWP 108608)]
[New Thread 0x7ffff4e4f640 (LWP 108609)]
[New Thread 0x7fffe7fff640 (LWP 108610)]
[New Thread 0x7fffe77fe640 (LWP 108611)]
[New Thread 0x7fffe6372640 (LWP 108612)]
[Thread 0x7fffe6372640 (LWP 108612) exited]
[New Thread 0x7fffe6372640 (LWP 108613)]
Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";
[New Thread 0x7fffe5b71640 (LWP 108614)]
[New Thread 0x7fffe4b7a640 (LWP 108615)]
[New Thread 0x7fffd4a88640 (LWP 108616)]
Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
[New Thread 0x7fffca797640 (LWP 108617)]
Redistribute latency...
[Thread 0x7fffd4a88640 (LWP 108616) exited]
[Thread 0x7fffe5b71640 (LWP 108614) exited]
[New Thread 0x7fffe5b71640 (LWP 108618)]
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Thread 13 "vqueue:src" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe5b71640 (LWP 108618)]
__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:476
476 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt
#0 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:476
#1 0x00007fffe695baf9 in () at /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
#2 0x00007ffff409438c in vaGetImage () at /lib/x86_64-linux-gnu/libva.so.2
#3 0x00007ffff40f6a49 in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so
#4 0x00007ffff40f8e19 in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstvaapi.so
#5 0x00007ffff64b1b6b in gst_video_frame_map_id () at /lib/x86_64-linux-gnu/libgstvideo-1.0.so.0
#6 0x00007ffff522fb02 in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstxvimagesink.so
#7 0x00007ffff638ccfc in () at /lib/x86_64-linux-gnu/libgstbase-1.0.so.0
#8 0x00007ffff635ce10 in () at /lib/x86_64-linux-gnu/libgstbase-1.0.so.0
#9 0x00007ffff7ee2fad in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#10 0x00007ffff7ee6549 in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#11 0x00007ffff7ee696e in gst_pad_push () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#12 0x00007ffff7ecf173 in gst_proxy_pad_chain_default ()
at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#13 0x00007ffff7ee2fad in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#14 0x00007ffff7ee6549 in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#15 0x00007ffff7ee696e in gst_pad_push () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#16 0x00007ffff636a51f in () at /lib/x86_64-linux-gnu/libgstbase-1.0.so.0
#17 0x00007ffff7ee2fad in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#18 0x00007ffff7ee6549 in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#19 0x00007ffff7ee696e in gst_pad_push () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#20 0x00007ffff636a51f in () at /lib/x86_64-linux-gnu/libgstbase-1.0.so.0
#21 0x00007ffff7ee2fad in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#22 0x00007ffff7ee6549 in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#23 0x00007ffff7ee696e in gst_pad_push () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#24 0x00007ffff7ecf173 in gst_proxy_pad_chain_default ()
at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#25 0x00007ffff7ee2fad in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#26 0x00007ffff7ee6549 in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#27 0x00007ffff7ee696e in gst_pad_push () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#28 0x00007ffff6280145 in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcoreelements.so
#29 0x00007ffff7f0d577 in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#30 0x00007ffff7da6654 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#31 0x00007ffff7da3a81 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#32 0x00007ffff7b35927 in start_thread (arg=<optimized out>) at pthread_create.c:435
#33 0x00007ffff7bc59e4 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/910v4l2codecs: build error with Ubuntu Bionic: unknown type 'grefcount'2021-12-01T15:54:39ZBin-CIv4l2codecs: build error with Ubuntu Bionic: unknown type 'grefcount'Catch build error on subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec:
```
00:39:16,677 INFO - ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:92:3: error: unknown type name 'grefcount'
00:39:16,677 INFO ...Catch build error on subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec:
```
00:39:16,677 INFO - ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:92:3: error: unknown type name 'grefcount'
00:39:16,677 INFO - grefcount ref_count;
00:39:16,677 INFO - ^~~~~~~~~
00:39:16,677 INFO - ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In function 'gst_v4l2_codec_vp9_dec_picture_data_new':
00:39:16,677 INFO - ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:106:3: warning: implicit declaration of function 'g_ref_count_init'; did you mean 'g_cond_init'? [-Wimplicit-function-declaration]
00:39:16,677 INFO - g_ref_count_init (&pic_data->ref_count);
00:39:16,677 INFO - ^~~~~~~~~~~~~~~~
00:39:16,677 INFO - g_cond_init
00:39:16,677 INFO - ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In function 'gst_v4l2_codec_vp9_dec_picture_data_ref':
00:39:16,677 INFO - ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:118:3: warning: implicit declaration of function 'g_ref_count_inc'; did you mean 'g_strv_contains'? [-Wimplicit-function-declaration]
00:39:16,677 INFO - g_ref_count_inc (&data->ref_count);
00:39:16,677 INFO - ^~~~~~~~~~~~~~~
00:39:16,677 INFO - g_strv_contains
00:39:16,677 INFO - ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c: In function 'gst_v4l2_codec_vp9_dec_picture_data_unref':
00:39:16,677 INFO - ../subprojects/gst-plugins-bad/sys/v4l2codecs/gstv4l2codecvp9dec.c:125:7: warning: implicit declaration of function 'g_ref_count_dec' [-Wimplicit-function-declaration]
00:39:16,677 INFO - if (g_ref_count_dec (&data->ref_count)) {
00:39:16,677 INFO - ^~~~~~~~~~~~~~~
```
Build success commit id: 9aaef931bf44
Build failed catch: 285695ee52d6
Catch this build error on : Ubuntu Bionic
Root cause: g_ref_count support from 2.58
https://gitlab.gnome.org/GNOME/glib/blob/2.66.2/glib/grefcount.c#L39
But ubuntu bionic support last glib version is 2.56.4
https://launchpad.net/ubuntu/+source/glib2.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1691v4l2codecs PIPE_FORMAT_B10G10R10A2_UNORM2021-12-02T14:11:58Zsimplev4l2codecs PIPE_FORMAT_B10G10R10A2_UNORMI can not wait 1.20, so I build the 1.19.3, please forgive me.
But I try play a demo video on the gnome wayland,no video show and the terminal crazy print `PIPE_FORMAT_B10G10R10A2_UNORM` :
```
drq@opi4:~/music_pi$ GST_DEBUG=4 GST_DEBUG_...I can not wait 1.20, so I build the 1.19.3, please forgive me.
But I try play a demo video on the gnome wayland,no video show and the terminal crazy print `PIPE_FORMAT_B10G10R10A2_UNORM` :
```
drq@opi4:~/music_pi$ GST_DEBUG=4 GST_DEBUG_FILE=g.log GST_DEBUG_NO_COLOR=1 gst-play-1.0 ~/ggxs.mp4
Press 'k' to see a list of keyboard shortcuts.
Now playing /home/drq/ggxs.mp4
Redistribute latency...
Redistribute latency...
Redistribute latency..
0:00:00.0 / 0:04:04.0
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
PIPE_FORMAT_B10G10R10A2_UNORM
drq@opi4:~/music_pi$ ^C
```
[gst.log](/uploads/2f82504938f9e846d56b4e90e44da013/g.log)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/913nice plugin unavailable in GStreamer 1.18.52021-12-03T18:30:15Zvkx86nice plugin unavailable in GStreamer 1.18.5Managed to make [that sample](https://gitlab.freedesktop.org/gstreamer/gst-examples/-/blob/1.18/webrtc/sendonly/webrtc-unidirectional-h264.c) with modification to use videotestsrc to work on Ubuntu 20.04.3 LTS VM with GStreamer 1.16.2 af...Managed to make [that sample](https://gitlab.freedesktop.org/gstreamer/gst-examples/-/blob/1.18/webrtc/sendonly/webrtc-unidirectional-h264.c) with modification to use videotestsrc to work on Ubuntu 20.04.3 LTS VM with GStreamer 1.16.2 after building & installing latest libnice.
It works only with FF on the same VM, Chrome fails to connect after errors in ICE negotiations, same for any browser trying to connect outside of VM.
So I decided to give GStreamer 1.18.5 on Ubuntu 21.10 VM a try to see how webrtcbin & libnice work there...
Build & installed latest libnice and discovered that GStreamer 1.18.5 doesn't recognize nice plugin, despite it being in the correct place and gst-inspect-1.0 sees it when directed to it:
gst-inspect-1.0 /usr/local/lib/x86_64-linux-gnu/gstreamer-1.0/libgstnice.so
Plugin Details:
Name nice
Description Interactive UDP connectivity establishment
Filename /usr/local/lib/x86_64-linux-gnu/gstreamer-1.0/libgstnice.so
Version 0.1.18.1
License LGPL
Source module libnice
Binary package libnice
Origin URL https://nice.freedesktop.org/
nicesrc: ICE source
nicesink: ICE sink
2 features:
+-- 2 elements
Tried to delete ~/.cache/gstreamer-1.0 folder to force plugin cache rebuild - same result, nice plugin is still unavailable to GStreamer.https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/148rtsp onvif server don't work2021-12-06T10:09:59ZAhmet Arabacırtsp onvif server don't workI am streaming webcam video output using gst-rtsp-server as the code given below and getting streams by vlc media player by another computer as a client by connecting the port 8554 (default port) properly.
```
import cv2
import gi
gi....I am streaming webcam video output using gst-rtsp-server as the code given below and getting streams by vlc media player by another computer as a client by connecting the port 8554 (default port) properly.
```
import cv2
import gi
gi.require_version('Gst', '1.0')
gi.require_version('GstRtspServer', '1.0')
from gi.repository import Gst, GstRtspServer, GObject
class SensorFactory(GstRtspServer.RTSPMediaFactory):
def __init__(self, **properties):
super(SensorFactory, self).__init__(**properties)
self.cap = cv2.VideoCapture(0)
self.number_frames = 0
self.fps = 30
self.duration = 1 / self.fps * Gst.SECOND # duration of a frame in nanoseconds
self.launch_string = 'appsrc name=source is-live=true block=true format=GST_FORMAT_TIME ' \
'caps=video/x-raw,format=BGR,width=640,height=480,framerate={}/1 ' \
'! videoconvert ! video/x-raw,format=I420 ' \
'! x264enc speed-preset=ultrafast tune=zerolatency ' \
'! rtph264pay config-interval=1 name=pay0 pt=96'.format(self.fps)
def on_need_data(self, src, lenght):
if self.cap.isOpened():
ret, frame = self.cap.read()
if ret:
data = frame.tostring()
buf = Gst.Buffer.new_allocate(None, len(data), None)
buf.fill(0, data)
buf.duration = self.duration
timestamp = self.number_frames * self.duration
buf.pts = buf.dts = int(timestamp)
buf.offset = timestamp
self.number_frames += 1
retval = src.emit('push-buffer', buf)
print('pushed buffer, frame {}, duration {} ns, durations {} s'.format(self.number_frames,
self.duration,
self.duration / Gst.SECOND))
if retval != Gst.FlowReturn.OK:
print(retval)
def do_create_element(self, url):
return Gst.parse_launch(self.launch_string)
def do_configure(self, rtsp_media):
self.number_frames = 0
appsrc = rtsp_media.get_element().get_child_by_name('source')
appsrc.connect('need-data', self.on_need_data)
class GstServer(GstRtspServer.RTSPServer):
def __init__(self, **properties):
super(GstServer, self).__init__(**properties)
self.factory = SensorFactory()
self.factory.set_shared(True)
self.get_mount_points().add_factory("/test", self.factory)
self.attach(None)
GObject.threads_init()
Gst.init(None)
server = GstServer()
loop = GObject.MainLoop()
loop.run()
```
I want to use RTSPOnvifMediaFactory in case of RTSPMediaFactory. RTSPOnvifMediaFactory was inherited from RTSPMediaFactory. So, I have only change "RTSPMediaFactory" with "RTSPOnvifMediaFactory" and run the code. But can not get streams by using vlc player on the other computer. Can you help me? What I am doing wrong?
RTSPOnvifMediaFactory --> https://gstreamer.freedesktop.org/documentation/gst-rtsp-server/rtsp-onvif-media-factory.html?gi-language=pythonhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/322Recording with GStreamer VA-API bitrate is ignored2021-12-06T11:15:53ZJosé Miguel SarasolaRecording with GStreamer VA-API bitrate is ignoredSystem Description:
- OS: Arch Linux
- DE: Gnome Shell 41.2
- Kernel: Linux 5.15.6
- GPU: AMD 5700XT
- Mesa: 21.2.5
- GStreamer: 1.18.5
If I try to make a record for example with:
`gst-launch-1.0 videotestsrc num-buffers=1000 ! video/x...System Description:
- OS: Arch Linux
- DE: Gnome Shell 41.2
- Kernel: Linux 5.15.6
- GPU: AMD 5700XT
- Mesa: 21.2.5
- GStreamer: 1.18.5
If I try to make a record for example with:
`gst-launch-1.0 videotestsrc num-buffers=1000 ! video/x-raw, format=NV12, width=1920, height=1080, framerate=60/1, interlace-mode=progressive ! videoconvert ! vaapih264enc bitrate=5000 ! h264parse ! matroskamux ! filesink location=out.mkv`
Even if bitrate is set to 5000, using `ffmpeg -i out.mkv`, it will report a bitrate of 41191. This issue has been noticed when using OBS, and the OBS Gstreamer plugin developer confirms this same issue is happening to him too.
If using ffmpeg VA-API plugin, bitrate is correct on the recording, so it doesn't seem to be something on the amdgpu side.