gst-plugins-rs issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues2024-03-20T17:18:58Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/522`rtpgccbwe`: investigate placing the element after the RTP session2024-03-20T17:18:58ZMathieu Duponchelle`rtpgccbwe`: investigate placing the element after the RTP sessionFollowing up on https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1502#note_2332096Following up on https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1502#note_2332096https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/521isofmp4mux crashes when recording with sound and without the chunk-duration p...2024-03-21T13:32:19Zkluddeisofmp4mux crashes when recording with sound and without the chunk-duration paramHi, I'm trying to launch the following pipe: `gst-launch-1.0 rtspsrc location='link' name=rtsp_src rtsp_src. ! application/x-rtp, media=video ! rtph264depay ! h264parse ! h264timestamper ! queue ! isofmp4mux fragment-duration=1000 name=m...Hi, I'm trying to launch the following pipe: `gst-launch-1.0 rtspsrc location='link' name=rtsp_src rtsp_src. ! application/x-rtp, media=video ! rtph264depay ! h264parse ! h264timestamper ! queue ! isofmp4mux fragment-duration=1000 name=muxer_sys ! filesink location=record.mp4 rtsp_src. ! application/x-rtp, media=audio ! queue ! rtpmp4gdepay name=audiodepay ! aacparse ! queue ! muxer_sys.`
and I get an error
_thread '<unnamed>' panicked at mux/fmp4/src/fmp4mux/imp.rs:1335:9:
assertion failed: timeout || all_eos || stream.sinkpad.is_eos() ||
stream.queued_gops.get(1).map(|gop| gop.final_earliest_pts) ==
Some(true) || settings.chunk_duration.is_some()_
if I set the _chunk-duration=1_, the pipe starts, but when I send an `eos` signal, I get an error _assertion failed: at_eos_
There are no problems with streams without soundhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/524Meson: GStreamer 1.24.0 static build fails in gstreamer-plugins-rs because of...2024-03-28T09:00:36ZSeungmin KimMeson: GStreamer 1.24.0 static build fails in gstreamer-plugins-rs because of LTO issuesDevelopers: @dabrain34 @slomo
Build pipeline: https://github.com/selkies-project/selkies-gstreamer/blob/main/addons/gstreamer/Dockerfile
The Meson setup was changed to:
```
meson setup --prefix /opt/gstreamer -Dbuildtype=release --def...Developers: @dabrain34 @slomo
Build pipeline: https://github.com/selkies-project/selkies-gstreamer/blob/main/addons/gstreamer/Dockerfile
The Meson setup was changed to:
```
meson setup --prefix /opt/gstreamer -Dbuildtype=release --default-library=static -Dgstreamer-1.0:gst-full-target-type=static_library -Dpython=enabled -Drs=enabled -Dgpl=enabled -Dbad=enabled -Dugly=enabled -Dlibav=enabled -Dgst-plugins-bad:qsv=enabled -Dgst-plugins-bad:va=enabled -Dgst-plugins-bad:openh264=enabled -Dgst-plugins-ugly:x264=enabled -Ddevtools=disabled -Ddoc=disabled -Dexamples=disabled -Dtests=disabled builddir
```
Logs:
`--default-library=static -Dgstreamer-1.0:gst-full-target-type=shared_library`: https://pastebin.com/raw/3H6Z7KwQ
`--default-library=static -Dgstreamer-1.0:gst-full-target-type=static_library`: https://pastebin.com/raw/BPbNSw5j
@slomo commented:
```
so yes, that's a rust problem but i was under the impression that this was worked around somehow in gstreamer-full too. cerbero has a workaround for it in any case
https://github.com/rust-lang/rust/issues/44322
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/520rtpgccbe: implement chain_list_function and push buffers as they were received.2024-03-27T20:41:21ZFrançois Laignelrtpgccbe: implement chain_list_function and push buffers as they were received.Currently, `rtpgccbe` only implements the `chain_function`. Alternatively, we could also implement the `chain_list_function` and push buffers the same way as they were received.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-r...Currently, `rtpgccbe` only implements the `chain_function`. Alternatively, we could also implement the `chain_list_function` and push buffers the same way as they were received.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1502#note_2331175https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/518Fallback source only shows fallback-uri image from known good RTSP stream2024-03-14T20:50:18ZEric PietrowiczFallback source only shows fallback-uri image from known good RTSP streamI have a known good RTSP camera that streams to `kvssink` with no issues. However, I need to setup `fallbacksrc` in my pipeline to prevent interruptions. I am having trouble with this.
I have a simple example pipeline that writes to th...I have a known good RTSP camera that streams to `kvssink` with no issues. However, I need to setup `fallbacksrc` in my pipeline to prevent interruptions. I am having trouble with this.
I have a simple example pipeline that writes to this file using `filesink` and demonstrates the issue.
My known good pipeline:
```
gst-launch-1.0 rtspsrc location=rtsp://169.254.1.180/net0 ! rtph264depay ! h264parse ! mpegtsmux ! filesink location=output_video.mpeg
```
My fallbacksrc pipeline:
```
GST_DEBUG=fallbacksrc:9 gst-launch-1.0 fallbacksrc uri=rtsp://169.254.1.180/net0 fallback-uri=file:///$HOME/fallback.jpg min-latency=1000 ! x264enc ! h264parse ! mpegtsmux ! filesink location=output_video.mpeg
```
`output_video.mpeg` just shows `fallback.jpg` and nothing else. Is there something I'm missing? My RTSP stream works well with `rtspsrc` as shown by the "known good pipeline" above.
Here are the debug logs from the `fallbacksrc` pipeline:[debug-logs.log](/uploads/cb319158ae8fe8d4b2c56abd2d0b8b5d/debug-logs.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/516whipclientsink: pushing to twitch.tv's WHIP endpoint is a noop2024-03-26T13:14:13ZTristan Matthewswhipclientsink: pushing to twitch.tv's WHIP endpoint is a noopPushing from GStreamer to twitch.tv via WHIP seems to run fine client-side but nothing is registering on the twitch.tv side.
To reproduce:
```
# I also tried with `do-fec=false` but same result
gst-launch-1.0 -v whipclientsink name=whip...Pushing from GStreamer to twitch.tv via WHIP seems to run fine client-side but nothing is registering on the twitch.tv side.
To reproduce:
```
# I also tried with `do-fec=false` but same result
gst-launch-1.0 -v whipclientsink name=whip signaller::whip-endpoint=https://g.webrtc.live-video.net:4443/v2/offer signaller::auth-token=TWITCH_KEY videotestsrc ! videoconvert ! x264enc speed-preset=veryfast tune=zerolatency ! h264parse ! whip. audiotestsrc ! audioconvert ! opusenc ! whip.
```
See also:
https://www.reddit.com/r/WebRTC/comments/12nc5md/twitchtv_now_supports_webrtc_ingestion_via_whip/
By contrast OBS works fine and https://github.com/ggarber/whip-go works reasonably well as well.
N.B. my actual use case would be using an rtspsrc as input but that's a bit overloaded for the scope of this issue, hence starting with testsrcs.
This is with GStreamer 1.24.0 for all modules.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/514uriplaylistbin: fix racy test2024-03-12T15:59:08ZGuillaume Desmottesuriplaylistbin: fix racy test`nb_streams_increasing` is racy: https://gitlab.freedesktop.org/gdesmott/gst-plugins-rs/-/jobs/56188510`nb_streams_increasing` is racy: https://gitlab.freedesktop.org/gdesmott/gst-plugins-rs/-/jobs/56188510https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/513togglerecord: debug racy tests2024-03-12T15:21:38ZGuillaume Desmottestogglerecord: debug racy testsThose tests have been disabled because they are racy:
- [ ] `test_two_stream_close_open_nonlivein_liveout` : !1494Those tests have been disabled because they are racy:
- [ ] `test_two_stream_close_open_nonlivein_liveout` : !1494https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/512Static GStreamer build fails to link rust plugins2024-03-12T21:15:05ZCole RichardsonStatic GStreamer build fails to link rust pluginsWhen compiling the static version of GStreamer (with meson), the link stage of the rust plugins fail with: `LINK : fatal error LNK1181: cannot open input file 'gobject-2.0.lib'`
#### Setup
- Windows 11
- MSVC 2022
- **gst-plugins-rs Ver...When compiling the static version of GStreamer (with meson), the link stage of the rust plugins fail with: `LINK : fatal error LNK1181: cannot open input file 'gobject-2.0.lib'`
#### Setup
- Windows 11
- MSVC 2022
- **gst-plugins-rs Version:** 0.12.2
- **GStreamer Version:** 1.24.0.1
### Steps to reproduce the bug
* Currently copied from a batch script.
```
meson subprojects update --reset
meson setup --wipe --buildtype=release --prefix %INSTALL_DIR%^
-Dstrip=false^
--default-library=static^
-Dgst-full-target-type=static_library^
--wrap-mode=forcefallback^
-Dgst-full-libraries=*^
-Dauto_features=disabled^
-Dbase=enabled^
-Dgood=enabled^
-Dbad=enabled^
-Dtools=enabled^
-Dtests=disabled^
-Dlibnice=enabled^
-Dlibav=disabled^
-Drtsp_server=disabled^
-Dglib:tests=false^
-Dcustom_subprojects=json-glib^
-Djson-glib:default_library=static^
-Djson-glib:tests=false^
-Dpcre2:test=false^
-Dges=disabled^
-Ddevtools=disabled^
-Dpython=disabled^
-Dgstreamer:registry=false^
-Dgst-plugins-base:playback=enabled^
-Dgst-plugins-base:encoding=enabled^
-Dgst-plugins-base:subparse=enabled^
-Dgst-plugins-base:compositor=enabled^
-Dgst-plugins-base:videotestsrc=enabled^
-Dgst-plugins-base:videorate=enabled^
-Dgst-plugins-base:videoconvertscale=enabled^
-Dgst-plugins-base:app=enabled^
-Dgst-plugins-base:typefind=enabled^
-Dgst-plugins-base:examples=disabled^
-Dgst-plugins-base:tests=disabled^
-Dgst-plugins-good:qt6=enabled^
-Dgst-plugins-good:soup=enabled^
-Dgst-plugins-good:rtp=enabled^
-Dgst-plugins-good:isomp4=enabled^
-Dgst-plugins-good:examples=disabled^
-Dgst-plugins-good:tests=disabled^
-Dgst-plugins-bad:autoconvert=enabled^
-Dgst-plugins-bad:d3d11=enabled^
-Dgst-plugins-bad:qt6d3d11=enabled^
-Dgst-plugins-bad:d3dvideosink=disabled^
-Dgst-plugins-bad:nvcodec=disabled^
-Dgst-plugins-bad:webrtc=enabled^
-Dgst-plugins-bad:videoparsers=enabled^
-Dgst-plugins-bad:examples=disabled^
-Dgst-plugins-bad:tests=disabled^
-Drs=enabled^
-Dgst-plugins-rs:webrtc=enabled^
-Dgst-plugins-rs:webrtchttp=enabled^
-Dgst-plugins-rs:rtp=enabled^
-Dgst-plugins-rs:file=enabled^
--vsenv^
%BUILD_DIR%
meson compile -C %BUILD_DIR%
meson install -C %BUILD_DIR%
```
### Solutions you have tried
I attempted to replace `ext_static = 'lib'` in `meson.build` with `ext_static = 'a'`. However, this did not help
[build.log](/uploads/4e0ca0e5a4f2a461d45467c83ce1f74c/build.log)amysparkamysparkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/510janusvrwebrtcsink: API exposing when WebRTC is UP2024-03-20T10:09:13ZGuillaume Desmottesjanusvrwebrtcsink: API exposing when WebRTC is UPI'd need API telling application when the Janus publisher is fully up so I can announce it to subscribers.
My current pre `janusvrwebrtcsink` code is waiting for the [`WebRTCUp`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/...I'd need API telling application when the Janus publisher is fully up so I can announce it to subscribers.
My current pre `janusvrwebrtcsink` code is waiting for the [`WebRTCUp`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/net/webrtc/src/janusvr_signaller/imp.rs?ref_type=heads#L421) message from Janus.
What would be the proper way to expose this to applications?
- A `webrtc-up` signal on the signaller?
- A `janus-state` property tracking the different signaller states: `session-created`, `videoroom-attached`, `room-joined`, `negotiating`, `webrtc-up`?
- Or should this be exposed in a more generic way in the `webrtcsink` base class instead?
@thiblahute : what do you think?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/509meson: ERROR: Could not get pkg-config variable and no default provided for <...2024-03-06T13:23:30ZGuillaume Desmottesmeson: ERROR: Could not get pkg-config variable and no default provided for <PkgConfigDependency gstreamer-1.0: True ['>=1.20.0']>Trying to run `meson` in a gst main env from my toolbox F37 environment:
```
❯ meson setup build
The Meson build system
Version: 1.3.2
Source dir: /var/home/cassidy/dev/rust/gst-plugins-rs
Build dir: /var/home/cassidy/dev/rust/gst-plugi...Trying to run `meson` in a gst main env from my toolbox F37 environment:
```
❯ meson setup build
The Meson build system
Version: 1.3.2
Source dir: /var/home/cassidy/dev/rust/gst-plugins-rs
Build dir: /var/home/cassidy/dev/rust/gst-plugins-rs/build
Build type: native build
Project name: gst-plugins-rs
Project version: 0.13.0-alpha.1
C compiler for the host machine: ccache cc (gcc 12.3.1 "cc (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1)")
C linker for the host machine: cc ld.bfd 2.38-27
Rust compiler for the host machine: rustc -C linker=cc (rustc 1.76.0)
Rust linker for the host machine: rustc -C linker=cc ld.bfd 2.38-27
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program python3 (tomllib) found: YES (/usr/bin/python3) modules: tomllib
Program cargo found: YES 1.76.0 1.76.0 (/var/home/cassidy/.cargo/bin/cargo)
Program cargo_wrapper.py found: YES (/usr/bin/python3 /var/home/cassidy/dev/rust/gst-plugins-rs/cargo_wrapper.py)
Program cargo-cbuild found: YES 0.9.30 0.9.30 (/var/home/cassidy/.cargo/bin/cargo-cbuild)
Found pkg-config: YES (/usr/bin/pkg-config) 1.8.0
Run-time dependency glib-2.0 found: YES 2.74.7
Run-time dependency gstreamer-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-app-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-audio-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-base-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-video-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-rtp-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-webrtc-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-sdp-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-check-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-gl-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-net-1.0 found: YES 1.25.0.1
Library csound64 found: YES
Program nasm found: YES (/usr/bin/nasm)
Run-time dependency openssl found: YES 3.0.9
Run-time dependency pangocairo found: YES 1.50.14
Dependency gstreamer-1.0 found: YES 1.25.0.1 (cached)
Run-time dependency pango found: YES 1.50.14
Dependency pangocairo found: YES 1.50.14 (cached)
Run-time dependency cairo-gobject found: YES 1.17.6
Run-time dependency dav1d found: YES 1.2.1
Dependency cairo-gobject found: YES 1.17.6 (cached)
Run-time dependency libwebpdemux found: YES 1.3.2
Run-time dependency gtk4 found: YES 4.8.3
Program pkg-config found: YES (/usr/bin/pkg-config)
Run-time dependency gobject-2.0 found: YES 2.74.7
Run-time dependency gmodule-2.0 found: YES 2.74.7
Run-time dependency libsodium found: YES 1.0.18
Found CMake: /usr/bin/cmake (3.27.7)
WARNING: CMake Toolchain: Failed to determine CMake compilers state
Run-time dependency csound found: NO (tried pkgconfig and cmake)
docs/meson.build:26:62: ERROR: Could not get pkg-config variable and no default provided for <PkgConfigDependency gstreamer-1.0: True ['>=1.20.0']>
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/508gtk4paintablesink: causes entire memory to fill up when use-scaling-filter=tr...2024-03-03T14:44:03ZDave Patrick Cabertogtk4paintablesink: causes entire memory to fill up when use-scaling-filter=true and on 2x desktop scaling### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstream...### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
Running the example in the tree with `gtk_v4_14` feature enabled, `use-scaling-filter=true` on the paintable, and using 2x desktop scaling cause system memory to fill up and eventually freeze the system and trigger `systemd-oomd`.
I btw didn't test this in fractional scaling, but works just fine with default 1x scaling.
#### Expected Behavior
<!-- What did you expect to happen -->
It should work just fine with as-usual KB/MB usage of memory.
#### Observed Behavior
<!-- What actually happened -->
16GB of memory gets filled up.
#### Setup
- **Operating System:** Fedora Linux 39.20240228.0 (Silverblue) (Linux 6.7.6-200.fc39.x86_64)
- **Device:** Computer (AMD Ryzen 5 5600G)
- **gst-plugins-rs Version:** 0.12 (also reproducible in main branch)
- **GTK version:** 4.13.9-74860f7
- **GStreamer Version:** 1.22.8
- **Command line:** bash
This is also reproducible on an Intel Laptop.
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. Clone repository
1. Modify `gst-plugins-rs/video/gtk4/examples/gtksink.rs` by setting paintable `use-scaling-filter=true`:
```rust
paintable.set_property("use-scaling-filter", true);
```
3. Run `cd gst-plugins-rs/video/gtk4`
3. Set device scaling to 2x (This is on `Displays > Scale > 200%` in GNOME Control Center)
3. Run `cargo run --example gtksink --features gtk_v4_14`
3. Wait memory to fill up and freeze system (this happens within the first 3 seconds after running the command)
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Always
### Solutions you have tried
* Leaving `use-scaling-filter` to default
* Using default 100% scalinghttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/501rtpbasepay2: Consider RTP header extension size in max payload size2024-02-23T13:22:37ZSebastian Drögertpbasepay2: Consider RTP header extension size in max payload sizeThe following discussion from !1424 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1424#note_2293620):
> This is something that would be worth fixi...The following discussion from !1424 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1424#note_2293620):
> This is something that would be worth fixing, and I think we can fix this in the new base classes. But as the old ones have exactly the same bug, and API changes are not a problem here, I'd leave this for the future. It doesn't block this MR.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/499Cargo.lock file is missing in some plugins.2024-02-16T12:53:12ZPatricia MuscaluCargo.lock file is missing in some plugins.gst-plugin-onvif, gst-plugin-claxon and probably some more plugins don't contain Cargo.lock file in the published crates.
Steps to reproduce:
Just analyze the content of the downloaded crate. An example:
https://crates.io/api/v1/crates/...gst-plugin-onvif, gst-plugin-claxon and probably some more plugins don't contain Cargo.lock file in the published crates.
Steps to reproduce:
Just analyze the content of the downloaded crate. An example:
https://crates.io/api/v1/crates/gst-plugin-onvif/0.12.0/downloadhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/497webrtcsink: Does FEC by default which breaks non-VP8/VP9 codecs2024-02-14T10:01:03ZSebastian Drögewebrtcsink: Does FEC by default which breaks non-VP8/VP9 codecsEnabling FEC makes use of Google's broken interpretation of ULPFEC, which only works somewhat reliable with VP8/VP9 but makes it impossible to handle packet loss correctly for other codecs.
This default should probably be re-considered....Enabling FEC makes use of Google's broken interpretation of ULPFEC, which only works somewhat reliable with VP8/VP9 but makes it impossible to handle packet loss correctly for other codecs.
This default should probably be re-considered. As another side-effect, enabling ULPFEC also enables RED, and `gstrtpredenc.c` [currently drops all RTP header extensions except for TWCC](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3301).https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/495rtp: av1: Support scalable streams2024-02-13T11:14:54ZSebastian Drögertp: av1: Support scalable streamsCC @bilboed @lminieroCC @bilboed @lminierohttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/494Build gst-plugins-gtk4 with the equivelant of --all-feautres2024-02-12T12:03:31ZJordan PetridіsBuild gst-plugins-gtk4 with the equivelant of --all-feautresFollowing https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1452 we have features in the crate that conflict with each other and had to exclude it from the `--all-features` CI build in https://gitlab.freedesktop.or...Following https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1452 we have features in the crate that conflict with each other and had to exclude it from the `--all-features` CI build in https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/commit/76b9836e5203a38562efaf806c016b3748308670
In the windows job we iterate over all the crates instead of building the workspace, so we can build them already with feature we want, we also do the same in gst-rs both linux and windows jobs. However we used to be able to do just workspace builds in linux plugin rs as it was faster since it better parallelize the build.
We could either:
* Figure out a way for the features to not conflict (not idea)
* Add another `cargo build` at the end of the current linux job that builds just `-p gst-pluings-gtk4` with the features we want (Which means we'd have to remember to bump it to `v1_24` etc each time)
* Iterate over the crates like we do in the other jobs (same issue applies with bumping the feature manually)Jordan PetridіsJordan Petridіshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/492whipsink stuck in ICE gathering state2024-03-05T14:21:47Zpushya-softnauticswhipsink stuck in ICE gathering stateVersion : gstreamer1.0-plugins-rs/0.9.11-r0/
We are trying to use 'whipsink' for streaming to the Dolby Millicast server and are unable to handle network failure cases.
When we try to connect for the first time using gst-launch (with n...Version : gstreamer1.0-plugins-rs/0.9.11-r0/
We are trying to use 'whipsink' for streaming to the Dolby Millicast server and are unable to handle network failure cases.
When we try to connect for the first time using gst-launch (with network disconnected), webrtcbin seems to be getting stuck in "ICE Gathering state". From the documentation, we expect that it should come out of this state in 15 second timeout. But this doesn't seem to be happening.
Any suggestions on this? We did enable GST_DEBUG=7 and only see the following "ICE Gathering state" message and nothing after that.
**0xaaaaf024e520 ERROR whipsink net/webrtchttp/src/whipsink/imp.rs:379:gstwebrtchttp::whipsink::imp:<whip> ICE gathering state : Gathering**
FYI, we did fix an earlier issue (https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/487#note_2258484) by pulling in latest version of libnice 0.1.21.1 and webrtc changes in gst-plugins-bad.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/491webrtcsink: Errors while generating debug graph during shutdown of pipeline2024-02-09T15:44:54ZJordan Yellozwebrtcsink: Errors while generating debug graph during shutdown of pipeline### Describe your issue
During implementation of !1442 I found that when `GST_DEBUG_DUMP_DOT_DIR` is set, using GStreamer 1.22 and gst-plugins-rs 0.11 branch, the livekitwebrtcsink will occasionally cause lots of glib assertion errors t...### Describe your issue
During implementation of !1442 I found that when `GST_DEBUG_DUMP_DOT_DIR` is set, using GStreamer 1.22 and gst-plugins-rs 0.11 branch, the livekitwebrtcsink will occasionally cause lots of glib assertion errors to get logged when the pipeline is shutting down.
#### Expected Behavior
The pipeline should always shut down cleanly and graphviz dot files should be written to disk.
#### Observed Behavior
There is a long list of assertions failing while a dot file is being generated:
```
Freeing pipeline ...
(gst-launch-1.0:839730): GStreamer-CRITICAL **: 10:29:15.393: gst_mini_object_ref: assertion 'mini_object != NULL' failed
(gst-launch-1.0:839730): GStreamer-CRITICAL **: 10:29:15.393: gst_mini_object_unref: assertion 'mini_object != NULL' failed
(gst-launch-1.0:839730): GStreamer-CRITICAL **: 10:29:15.393: gst_caps_features_is_equal: assertion 'features1 != NULL' failed
(gst-launch-1.0:839730): GStreamer-CRITICAL **: 10:29:15.393: gst_mini_object_ref: assertion 'mini_object != NULL' failed
(gst-launch-1.0:839730): GStreamer-CRITICAL **: 10:29:15.393: gst_caps_is_any: assertion 'GST_IS_CAPS (caps)' failed
```
#### Setup
- **Operating System:** Fedora Linux 39
- **Device:** Computer
- **gst-plugins-rs Version:** 0.11 (https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/commit/5bba2f783632bb27687662017d703af2fb2fd4f1)
- **GStreamer Version:** 1.22.9+ (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/23b88fe0f3060c216a03297f356c50c9a922a74b)
- **Command line:**
```shell
export GST_DEBUG_DUMP_DOT_DIR="$PWD/dot"
mkdir -p "$GST_DEBUG_DUMP_DOT_DIR"
gst-launch-1.0 livekitwebrtcsink name=sink \
signaller::ws-url=ws://localhost:7880 \
signaller::api-key=devkey \
signaller::secret-key=secret \
signaller::room-name=test \
video-caps='video/x-vp8' \
videotestsrc is-live=1 ! video/x-raw,framerate=30/1,width=320,height=180 ! queue ! sink. \
videotestsrc is-live=1 ! video/x-raw,framerate=30/1,width=640,height=360 ! queue ! sink. \
videotestsrc is-live=1 ! video/x-raw,framerate=30/1,width=1280,height=720 ! queue ! sink.
```
### Steps to reproduce the bug
1. Build specified versions of GStreamer and gst-plugins-rs
2. Run LiveKit server with `--dev` flag to allow developer credentials specified above to be accepted
3. type `command` and press ctrl-c a few seconds after starting. Repeat as necessary.
### How reproducible is the bug?
Intermittent, about 1/10 attempts have triggered the bug for me. So far I have only ever experienced the bug when using the livekitwebrtcsink, not the plain webrtcsink with the GST reference signalling server.
### Screenshots if relevant
N/A
### Solutions you have tried
N/A
### Related non-duplicate issues
N/A
### Additional Information
Stack trace:
<details>
<pre>
#0 g_logv (log_domain=0x7ff06a7dd1d8 "GStreamer", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ff0428f2f60) at ../glib/gmessages.c:1423
#1 0x00007ff06a5e9463 in g_log (log_domain=log_domain@entry=0x7ff06a7dd1d8 "GStreamer", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ff06a651280 "%s: assertion '%s' failed") at ../glib/gmessages.c:1461
#2 0x00007ff06a5ea6dd in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ff06a7dd1d8 "GStreamer", pretty_function=pretty_function@entry=0x7ff06a7e3620 <__func__.4> "gst_caps_features_is_any", expression=expression@entry=0x7ff06a7e2991 "features != NULL") at ../glib/gmessages.c:2930
#3 0x00007ff06a746e6e in gst_caps_features_is_any (features=features@entry=0x0) at ../subprojects/gstreamer/gst/gstcapsfeatures.c:766
#4 0x00007ff06a743e1a in gst_caps_is_subset (subset=subset@entry=0x7ff00c0391c0, superset=superset@entry=0x7ff00c019e60) at ../subprojects/gstreamer/gst/gstcaps.c:1348
#5 0x00007ff06a7441e7 in gst_caps_is_equal (caps1=caps1@entry=0x7ff00c0391c0, caps2=caps2@entry=0x7ff00c019e60) at ../subprojects/gstreamer/gst/gstcaps.c:1473
#6 0x00007ff06a74f740 in debug_dump_element_pad_link (pad=0x7ff00c02b870, element=0x7ff00c02b150, details=GST_DEBUG_GRAPH_SHOW_VERBOSE, str=0x7ff00c1074d0, indent=<optimized out>) at ../subprojects/gstreamer/gst/gstdebugutils.c:502
#7 0x00007ff06a750477 in debug_dump_element (bin=bin@entry=0x7ff00c034c90, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE, str=str@entry=0x7ff00c1074d0, indent=indent@entry=4) at ../subprojects/gstreamer/gst/gstdebugutils.c:714
#8 0x00007ff06a7502fa in debug_dump_element (bin=bin@entry=0x7ff00c0c7030, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE, str=str@entry=0x7ff00c1074d0, indent=indent@entry=3) at ../subprojects/gstreamer/gst/gstdebugutils.c:694
#9 0x00007ff06a7502fa in debug_dump_element (bin=bin@entry=0x7ff030048f40, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE, str=str@entry=0x7ff00c1074d0, indent=indent@entry=2) at ../subprojects/gstreamer/gst/gstdebugutils.c:694
#10 0x00007ff06a7502fa in debug_dump_element (bin=bin@entry=0x7ff030066af0, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE, str=str@entry=0x7ff00c1074d0, indent=indent@entry=1) at ../subprojects/gstreamer/gst/gstdebugutils.c:694
#11 0x00007ff06a750580 in gst_debug_bin_to_dot_data (bin=bin@entry=0x7ff030066af0, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE) at ../subprojects/gstreamer/gst/gstdebugutils.c:829
#12 0x00007ff06a750748 in gst_debug_bin_to_dot_file (bin=bin@entry=0x7ff030066af0, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE, file_name=<optimized out>, file_name@entry=0x7ff030058680 "0.00.01.232958865-webrtcsink-session-unique-Paused-to-Ready") at ../subprojects/gstreamer/gst/gstdebugutils.c:873
#13 0x00007ff06a7509aa in gst_debug_bin_to_dot_file_with_ts (bin=0x7ff030066af0, details=GST_DEBUG_GRAPH_SHOW_VERBOSE, file_name=<optimized out>) at ../subprojects/gstreamer/gst/gstdebugutils.c:920
#14 0x00007ff05b88a993 in gstreamer::auto::functions::debug_bin_to_dot_file_with_ts<gstreamer::auto::pipeline::Pipeline, alloc::string::String> (bin=<optimized out>, details=..., file_name=...) at /var/home/jyelloz/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/8c286fa/gstreamer/src/auto/functions.rs:53
#15 0x00007ff05b7d6009 in gstreamer::bin::GstBinExtManual::debug_to_dot_file_with_ts<gstreamer::auto::pipeline::Pipeline, alloc::string::String> (self=0x7ff0428f3558, details=..., file_name=...) at /var/home/jyelloz/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/8c286fa/gstreamer/src/bin.rs:187
#16 gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block#5} () at net/webrtc/src/webrtcsink/imp.rs:2494
#17 0x00007ff05b7c08ef in tokio::runtime::task::core::{impl#6}::poll::{closure#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (ptr=0x7ff03006e130) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/core.rs:328
#18 tokio::loom::std::unsafe_cell::UnsafeCell<tokio::runtime::task::core::Stage<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}>>::with_mut<tokio::runtime::task::core::Stage<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}>, core::task::poll::Poll<()>, tokio::runtime::task::core::{impl#6}::poll::{closure_env#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>> (self=0x7ff03006e130, f=...) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/loom/std/unsafe_cell.rs:16
#19 tokio::runtime::task::core::Core<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>::poll<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (self=0x7ff03006e120, cx=...) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/core.rs:317
#20 0x00007ff05b81972a in tokio::runtime::task::harness::poll_future::{closure#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> () at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/harness.rs:485
#21 core::panic::unwind_safe::{impl#23}::call_once<core::task::poll::Poll<()>, tokio::runtime::task::harness::poll_future::{closure_env#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>> (self=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panic/unwind_safe.rs:272
#22 std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>>, core::task::poll::Poll<()>> (data=<optimized out>) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:552
#23 std::panicking::try<core::task::poll::Poll<()>, core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>>> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:516
#24 std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>>, core::task::poll::Poll<()>> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panic.rs:142
#25 tokio::runtime::task::harness::poll_future<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (core=0x7ff03006e120, cx=...) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/harness.rs:473
#26 tokio::runtime::task::harness::Harness<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>::poll_inner<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (self=<optimized out>) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/harness.rs:208
#27 tokio::runtime::task::harness::Harness<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>::poll<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (self=...) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/harness.rs:153
#28 0x00007ff05c184466 in tokio::runtime::task::raw::RawTask::poll (self=...) at src/runtime/task/raw.rs:201
#29 tokio::runtime::task::LocalNotified<alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>::run<alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (self=...) at src/runtime/task/mod.rs:416
#30 tokio::runtime::scheduler::multi_thread::worker::{impl#1}::run_task::{closure#0} () at src/runtime/scheduler/multi_thread/worker.rs:576
#31 tokio::runtime::coop::with_budget<core::result::Result<alloc::boxed::Box<tokio::runtime::scheduler::multi_thread::worker::Core, alloc::alloc::Global>, ()>, tokio::runtime::scheduler::multi_thread::worker::{impl#1}::run_task::{closure_env#0}> (budget=..., f=...) at src/runtime/coop.rs:107
#32 tokio::runtime::coop::budget<core::result::Result<alloc::boxed::Box<tokio::runtime::scheduler::multi_thread::worker::Core, alloc::alloc::Global>, ()>, tokio::runtime::scheduler::multi_thread::worker::{impl#1}::run_task::{closure_env#0}> (f=...) at src/runtime/coop.rs:73
#33 tokio::runtime::scheduler::multi_thread::worker::Context::run_task (self=0x7ff0428f3a78, task=..., core=<optimized out>) at src/runtime/scheduler/multi_thread/worker.rs:575
#34 0x00007ff05c183218 in tokio::runtime::scheduler::multi_thread::worker::Context::run (self=0x7ff0428f3a78, core=0x7ff050001160) at src/runtime/scheduler/multi_thread/worker.rs:526
#35 0x00007ff05c1882ec in tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure#0} () at src/runtime/scheduler/multi_thread/worker.rs:491
#36 tokio::runtime::context::scoped::Scoped<tokio::runtime::scheduler::Context>::set<tokio::runtime::scheduler::Context, tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure_env#0}, ()> (self=0x7ff030000ca8, t=<optimized out>, f=...) at src/runtime/context/scoped.rs:40
#37 0x00007ff05c180754 in tokio::runtime::context::set_scheduler::{closure#0}<(), tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure_env#0}> (c=<optimized out>) at src/runtime/context.rs:176
#38 std::thread::local::LocalKey<tokio::runtime::context::Context>::try_with<tokio::runtime::context::Context, tokio::runtime::context::set_scheduler::{closure_env#0}<(), tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure_env#0}>, ()> (self=<optimized out>, f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/local.rs:270
#39 std::thread::local::LocalKey<tokio::runtime::context::Context>::with<tokio::runtime::context::Context, tokio::runtime::context::set_scheduler::{closure_env#0}<(), tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure_env#0}>, ()> (self=<optimized out>, f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/local.rs:246
#40 0x00007ff05c17b57c in tokio::runtime::context::set_scheduler<(), tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure_env#0}> (v=0x7ff0428f3a70, f=...) at src/runtime/context.rs:176
#41 tokio::runtime::scheduler::multi_thread::worker::run::{closure#0} () at src/runtime/scheduler/multi_thread/worker.rs:486
#42 tokio::runtime::context::runtime::enter_runtime<tokio::runtime::scheduler::multi_thread::worker::run::{closure_env#0}, ()> (handle=<optimized out>, allow_block_in_place=<optimized out>, f=...) at src/runtime/context/runtime.rs:65
#43 0x00007ff05c1829d0 in tokio::runtime::scheduler::multi_thread::worker::run (worker=...) at src/runtime/scheduler/multi_thread/worker.rs:478
#44 0x00007ff05c1634e2 in tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure#0} () at src/runtime/scheduler/multi_thread/worker.rs:447
#45 tokio::runtime::blocking::task::{impl#2}::poll<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}, ()> (self=..., _cx=<optimized out>) at src/runtime/blocking/task.rs:42
#46 0x00007ff05c1609ca in tokio::runtime::task::core::{impl#6}::poll::{closure#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (ptr=0x7ff05000d728) at src/runtime/task/core.rs:328
#47 tokio::loom::std::unsafe_cell::UnsafeCell<tokio::runtime::task::core::Stage<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>>::with_mut<tokio::runtime::task::core::Stage<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, core::task::poll::Poll<()>, tokio::runtime::task::core::{impl#6}::poll::{closure_env#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>> (self=0x7ff05000d728, f=...) at src/loom/std/unsafe_cell.rs:16
#48 tokio::runtime::task::core::Core<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>::poll<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (self=0x7ff05000d720, cx=...) at src/runtime/task/core.rs:317
#49 0x00007ff05c15f6b5 in tokio::runtime::task::harness::poll_future::{closure#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> () at src/runtime/task/harness.rs:485
#50 core::panic::unwind_safe::{impl#23}::call_once<core::task::poll::Poll<()>, tokio::runtime::task::harness::poll_future::{closure_env#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>> (self=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panic/unwind_safe.rs:272
#51 std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>>, core::task::poll::Poll<()>> (data=<optimized out>) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:552
#52 std::panicking::try<core::task::poll::Poll<()>, core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>>> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:516
#53 std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>>, core::task::poll::Poll<()>> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panic.rs:142
#54 tokio::runtime::task::harness::poll_future<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (core=0x440, cx=...) at src/runtime/task/harness.rs:473
#55 0x00007ff05c15e34b in tokio::runtime::task::harness::Harness<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>::poll_inner<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (self=<optimized out>) at src/runtime/task/harness.rs:208
#56 0x00007ff05c162a58 in tokio::runtime::task::harness::Harness<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>::poll<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (self=...) at src/runtime/task/harness.rs:153
#57 tokio::runtime::task::raw::poll<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (ptr=...) at src/runtime/task/raw.rs:271
#58 0x00007ff05c162f20 in tokio::runtime::task::raw::RawTask::poll (self=...) at src/runtime/task/raw.rs:201
#59 tokio::runtime::task::UnownedTask<tokio::runtime::blocking::schedule::BlockingSchedule>::run<tokio::runtime::blocking::schedule::BlockingSchedule> (self=...) at src/runtime/task/mod.rs:453
#60 0x00007ff05c16a251 in tokio::runtime::blocking::pool::Task::run (self=...) at src/runtime/blocking/pool.rs:159
#61 tokio::runtime::blocking::pool::Inner::run (self=0x7ff05000c9c0, worker_thread_id=<optimized out>) at src/runtime/blocking/pool.rs:513
#62 0x00007ff05c16eb1d in tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure#0} () at src/runtime/blocking/pool.rs:471
#63 std::sys_common::backtrace::__rust_begin_short_backtrace<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:154
#64 0x00007ff05c16f55c in std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()> () at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/mod.rs:529
#65 core::panic::unwind_safe::{impl#23}::call_once<(), std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>> (self=<error reading variable: Cannot access memory at address 0x0>) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panic/unwind_safe.rs:272
#66 std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>>, ()> (data=<optimized out>) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:552
#67 std::panicking::try<(), core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>>> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:516
#68 std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>>, ()> (f=<error reading variable: Cannot access memory at address 0x0>) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panic.rs:142
#69 std::thread::{impl#0}::spawn_unchecked_::{closure#1}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()> () at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/mod.rs:528
#70 core::ops::function::FnOnce::call_once<std::thread::{impl#0}::spawn_unchecked_::{closure_env#1}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>, ()> () at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/ops/function.rs:250
#71 0x00007ff05c2222a5 in alloc::boxed::{impl#47}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2007
#72 alloc::boxed::{impl#47}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2007
#73 std::sys::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/unix/thread.rs:108
#74 0x00007ff06a3d2897 in start_thread (arg=<optimized out>) at pthread_create.c:444
#75 0x00007ff06a45980c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
</pre>
</details>https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/489Support for variant streams & alternative renditions with HLS2024-03-22T12:14:11ZSanchayan Maitysanchayan@sanchayanmaity.netSupport for variant streams & alternative renditions with HLS# HLS support for variant stream and alternate renditions
## Motivation
HTTP Live Streaming specification in [RFC 8216](https://www.rfc-editor.org/rfc/rfc8216) defines alternate renditions and variant streams.
Variant streams are diff...# HLS support for variant stream and alternate renditions
## Motivation
HTTP Live Streaming specification in [RFC 8216](https://www.rfc-editor.org/rfc/rfc8216) defines alternate renditions and variant streams.
Variant streams are different encodings of the same presentation.
- Each Variant Stream MUST present the same content.
- Matching content in Variant Streams MUST have matching timestamps which allows clients to synchronize the media.
- Variant Streams SHOULD contain the same encoded audio bitstream.
Alternative rendition provides an alternative for one of the media or variant stream, an example of which would be supporting multiple languages using different audio streams.
Section 8.6 and 8.7 of the RFC show an example of both.
As of this writing, the existing HLS sink elements don't support variant streams and alternate renditions.
## Proposal
Introduce a new element `hlssink4` with support for
- Generating master playlist
- Variant streams
- Alternate renditions
This then enables support for subtitles and closed captions as well.
The work has similarities with what's being done in the yet to be merged [`encs3hlsbin`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/801) with two primary differences.
- Not tied to S3
- Encoding or bit rate ladder isn't implemented inside `hlssink4`
While one could also extend `hlssink3`, with the existence of `HlsBaseSink`,
- `hlssink4` can be built on top of `HlsBaseSink`
- keep the management of master playlist and thus variant stream, alternate renditions separate and outside `hlssink3`
- Introduce pad naming on the same lines as `splitmuxsink`