GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2018-11-04T17:47:51Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/110g_signal_emit_by_name won't accept correct argument type2018-11-04T17:47:51ZSebastian Drögeg_signal_emit_by_name won't accept correct argument type*Created by: maxmcd*
This fails with `BoolError("Incompatible argument types")`
```rust
let opus_caps = gst::Caps::from_str(&rtp_caps_opus).unwrap();
webrtc
.emit("add-transceiver", &[&3i32, &opus_caps])
.unwrap();
```
[a...*Created by: maxmcd*
This fails with `BoolError("Incompatible argument types")`
```rust
let opus_caps = gst::Caps::from_str(&rtp_caps_opus).unwrap();
webrtc
.emit("add-transceiver", &[&3i32, &opus_caps])
.unwrap();
```
[add-transceiver](https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-webrtcbin.html#GstWebRTCBin-add-transceiver) accepts direction and caps.
I've tried a few values for the direction:
```rust
gstreamer_webrtc_sys::GST_WEBRTC_RTP_TRANSCEIVER_DIRECTION_RECVONLY
&(gstreamer_webrtc_sys::GST_WEBRTC_RTP_TRANSCEIVER_DIRECTION_RECVONLY).to_value()
&(gstreamer_webrtc_sys::GST_WEBRTC_RTP_TRANSCEIVER_DIRECTION_RECVONLY
as gstreamer_webrtc_sys::GstWebRTCRTPTransceiverDirection)
.to_value(),
// etc....
```
Wondering if I'm missing a way to pass the type. https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/108Segfault on gstreamer_sdp::SDPMessage::parse_buffer2018-11-04T17:47:51ZSebastian DrögeSegfault on gstreamer_sdp::SDPMessage::parse_buffer*Created by: maxmcd*
Example code:
```rust
let ret = gstreamer_sdp::SDPMessage::parse_buffer(b"t=0 0\r\n").unwrap();
```
Valgrind output:
```
==5178== Invalid read of size 4
==5178== at 0x58E94D9: gst_sdp_message_emails_len ...*Created by: maxmcd*
Example code:
```rust
let ret = gstreamer_sdp::SDPMessage::parse_buffer(b"t=0 0\r\n").unwrap();
```
Valgrind output:
```
==5178== Invalid read of size 4
==5178== at 0x58E94D9: gst_sdp_message_emails_len (gstsdpmessage.c:897)
==5178== by 0x58ED356: gst_sdp_message_as_text (gstsdpmessage.c:499)
==5178== by 0x2D2920: gstreamer_sdp::sdp_message::SDPMessage::as_text (sdp_message.rs:134)
==5178== by 0x19A9CA: <gst_rust::WsClient as ws::handler::Handler>::on_message (main.rs:239)
==5178== by 0x146C75: <ws::connection::Connection<H>>::read_frames (connection.rs:658)
==5178== by 0x150020: <ws::connection::Connection<H>>::read (connection.rs:602)
==5178== by 0x16BECB: <ws::io::Handler<F>>::handle_event (io.rs:548)
==5178== by 0x169A46: <ws::io::Handler<F>>::event_loop (io.rs:429)
==5178== by 0x175502: <ws::io::Handler<F>>::run (io.rs:396)
==5178== by 0x120042: <ws::WebSocket<F>>::run (lib.rs:331)
==5178== by 0x11FC73: ws::connect (lib.rs:121)
==5178== by 0x19ACA3: gst_rust::connect_to_websocket_server_async (main.rs:264)
==5178== Address 0x8 is not stack'd, malloc'd or (recently) free'd
```
Digging into this a little bit more now, but hoping I might be missing something obvious.
I simplified the buffer value to hopefully provide a more concise failure example, but it also segfaults with a full SDP offer. https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/151ges: Work around trait naming conflicts2018-11-04T20:14:38ZSebastian Drögeges: Work around trait naming conflictsThere is no problem naming traits the same in different modules, but the compiler has problems resolving things sometimes then (compiler bug). That's why it's e.g. `gst::GstObjectExt` instead of `gst::ObjectExt`.
The following discussio...There is no problem naming traits the same in different modules, but the compiler has problems resolving things sometimes then (compiler bug). That's why it's e.g. `gst::GstObjectExt` instead of `gst::ObjectExt`.
The following discussion from !157 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/merge_requests/157#note_74514):
> You might want to name the trait `GESContainerExt` to prevent conflicts with `gtk::ContainerExt`
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/merge_requests/157#note_74512):
> You might want to name this `GESPipelineExt` to prevent conflicts with `gst::PipelineExt`Thibault Sauniertsaunier@igalia.comThibault Sauniertsaunier@igalia.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/513clone the code from gitlab2018-11-05T05:24:41ZHaihao Xiangclone the code from gitlabgst-plugins-good was migrated from fd.o to gitlab, some URLs should be updated as well.gst-plugins-good was migrated from fd.o to gitlab, some URLs should be updated as well.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/814clone the code from gitlab2018-11-05T05:27:09ZHaihao Xiangclone the code from gitlabgst-plugins-bad was migrated from fd.o to gitlab, some URLs should be updated as well.gst-plugins-bad was migrated from fd.o to gitlab, some URLs should be updated as well.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/116Clone the code from gitlab2018-11-05T05:27:59ZHaihao XiangClone the code from gitlabgstreamer-vaapi was migrated from fd.o to gitlab, some URLs should be updated as well.gstreamer-vaapi was migrated from fd.o to gitlab, some URLs should be updated as well.https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/1Migrate repositories and bugtracker to gitlab.freedesktop.org2018-11-05T06:40:31ZEdward HerveyMigrate repositories and bugtracker to gitlab.freedesktop.orgThis issue is to plan, organize and track the migration of GStreamer to gitlab.freedesktop.org
## TODO
* [x] Review modules to migrate: #2 #3
* [x] Review group labels to be created and used for the various fields from bugzilla #5
* [x]...This issue is to plan, organize and track the migration of GStreamer to gitlab.freedesktop.org
## TODO
* [x] Review modules to migrate: #2 #3
* [x] Review group labels to be created and used for the various fields from bugzilla #5
* [x] test the bugzilla migration script on a private gitlab instance
* with mails disabled
* and with same version as upstream gitlab.freedesktop.org
* [x] @slomo : test github migration script on a private gitlab instance with mails disabled.
* [x] Prepare mail announcing migration, what will change (and what will not change), what people who are interested should do, and the dates.
* [x] @bilboed: Get GCE VM in us-east1 (closest to both bugzilla and gitlab) for running migration script
## Stage 1 - Migrate git
* [x] Announce git migration on developer focused channels
* [x] Ask fdo admins to run a pre-prepared script `fdo-import-repo.py` with a list of modules from #2 to move to gitlab
* [x] Disable merge commits for each project - "Settings" -> "Merge request settings" -> "Fast-forward merge"
* [x] Update project description
* [x] Committers updates their push (and optionally pull remotes) for gitlab. End users (read-only access) still use the cgit mirror.
* [x] Make the GStreamer group public
## Stage 2 - Migrate bugs
* [x] @bilboed Migrate bugs using the tested script #4
* [x] Push gst-docs contributing update: https://gitlab.freedesktop.org/ystreet/gst-docs/tree/gitlab
## Post migration
* [x] Ask bugzilla admins (andre ?) to update the banner to point to fdo gitlab for GStreamer.Edward HerveyEdward Hervey2018-11-04https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/23Notify GNOME Bugzilla people that we migrated2018-11-05T08:00:47ZSebastian DrögeNotify GNOME Bugzilla people that we migratedThe header on Bugzilla still lists GStreamer as an exception. Ideally it would point to here then.The header on Bugzilla still lists GStreamer as an exception. Ideally it would point to here then.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/96queue2: incorrect current-level-time reported after seek (with packetized data)2018-11-05T08:29:36ZBugzilla Migration Userqueue2: incorrect current-level-time reported after seek (with packetized data)## Submitted by Aleksander Wabik
**[Link to original bug (#744587)](https://bugzilla.gnome.org/show_bug.cgi?id=744587)**
## Description
Created attachment 296913
The testcase
Steps to reproduce the bug:
1) Have a queue2 ...## Submitted by Aleksander Wabik
**[Link to original bug (#744587)](https://bugzilla.gnome.org/show_bug.cgi?id=744587)**
## Description
Created attachment 296913
The testcase
Steps to reproduce the bug:
1) Have a queue2 element,
2) Send SEGMENT (GST_FORMAT_TIME) event with non-zero start/position/time.
3) Start pushing buffers with PTSes starting at 0 to the queue.
Effects:
1) As soon the queue obtains buffers with valid in-segment PTS, it reports buffered time level correctly,
2) As soon the queue pushes first buffer with PTS < segment.start to the srcpad, the queue stops reporting buffered time level correctly, it reports 0 buffered.
This is caused by rewriting src_segment.position with buffer's PTS, and then gst_segment_to_running_time() returns GST_CLOCK_TIME_NONE.
At this point, if we have a very fast source element, and a very slow decoder, the decoder may block on the first frame (with PTS below segment start) for quite a long time (especially if it's a software decoder decoding 1080p HEVC or VP9 frame). In this time, the queue reports current-level-time == 0, and what's worse, if the queue has buffer & byte limits 0, and only the time limit set, fast source may push megabytes of data, tens of seconds of data, even though the limit may be 0.5 seconds. The queue will not block, as it thinks it's 0% filled.
Additional bug (fixed by the same fix): some streams have non-monotonic PTSes. Push buffer with PTS=1s, duration=1s, and then push buffer with PTS=0s, duration=1s. The queue has now 2 seconds of data buffered, but it will report only one second.
I am attaching the extended unit tests for queue2 element that demonstrate both these problems.
~~**Patch 296913**~~, "The testcase":
[patch1-queue2-testcase.patch](/uploads/45ddd0f507d0096b9ec0cbeea377265c/patch1-queue2-testcase.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/7Migrate push notifications from post-receive hook on cgit to GitLab2018-11-05T09:48:42ZSebastian DrögeMigrate push notifications from post-receive hook on cgit to GitLabSee https://docs.gitlab.com/ee/user/project/integrations/emails_on_push.html
We would configure that per repo and put the GStreamer commit mailing list in there as receiver.
Any opinions on this? CC @daniels @bilboed @tpm?
* [x] email...See https://docs.gitlab.com/ee/user/project/integrations/emails_on_push.html
We would configure that per repo and put the GStreamer commit mailing list in there as receiver.
Any opinions on this? CC @daniels @bilboed @tpm?
* [x] emails sent to commit ml on every push from gitlab
* [x] Make sure legacy post-commit hooks are disabled @tpm ? @daniels ?Jordan PetridіsJordan Petridіshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/85New plugin for MPEG TS time shifting2018-11-05T10:23:17ZBugzilla Migration UserNew plugin for MPEG TS time shifting## Submitted by Krzysztof Konopko
**[Link to original bug (#692397)](https://bugzilla.gnome.org/show_bug.cgi?id=692397)**
## Description
Created attachment 234220
Proposed implementation
tstimeshift: New plugin for MPEG TS ti...## Submitted by Krzysztof Konopko
**[Link to original bug (#692397)](https://bugzilla.gnome.org/show_bug.cgi?id=692397)**
## Description
Created attachment 234220
Proposed implementation
tstimeshift: New plugin for MPEG TS time shifting
This is an initial proposal. I'd like to ask for any help, views, suggestions and directions.
The plugin is base on Fluendo timeshift element [1] although quite substantially changed. The proposed code is maintained on GitHub [2]. The gsttstimeshift comprises several elements that can be used for MPEG TS time shifting:
tsshifter : Time Shift for MPEG TS streams
tsshifterbin : Time Shift + TS parser for MPEG TS streams
tsseeker : Time Shift seeker
tsindexer : Indexer for MPEG-TS streams
A typical pipeline that makes use of them would look like:
`<some MPEG TS src>` ! tsshifterbin ! `<some MPEG TS sink>`
The tsshifterbin element will instantiate elements as follows:
tsparse ! tsindexer ! tsshifter ! tsseeker
and prepare tsindexer ("tune" it to look for the right PID containing PCRs).
Potentially tsshifter can be replaced with queue2 (see the problems below) and this is actually one of the goals.
Problems still to be considered/solved/improved:
---------------------------------------
- naming
Both tsindexer and tsseeker are supposed to be MPEG TS agnostic but ATM they are TS specific, hence their names.
Also the tsshifter is actually a ring buffer.
- tsindexer
* uses overengineered for this use case and abandoned GstIndex API (local copy)
* can't remove index entries
* can't write the index to the disk
* duplicates parsing TS packets logic from tsparse
tsparse would have to be improved to send some additional timestamp information (e. g. as tags or as buffer timestamps) so that the indexer could pick them up. The indexer itself could be a generic component (no knowledge about TS packets), hard to come up with the right format though.
- tsindexer and tsseeker share an index object while it should be shared through some index database
- tsshifter
* it's actually a ring buffer, not a shifter (see naming notes above)
* ideally it should be replaced with queue2
* as a first attempt, replacement could be optional (both tsshifter and queue2 co-exist)
There are still some issues when using queue2 instead of tsshifter that have to be solved.
* as a goal tsshifter could be completely replaced with queue2 which might require some changes/improvements of the latter:
* custom allocator can be used (see FileMemAllocator: https://bugzilla.gnome.org/show_bug.cgi?id=691299)
- tests still to be written
- documentation
[1] https://github.com/kkonopko/gst-fluendo-timeshift
[2] https://github.com/kkonopko/gst-plugins-bad/tree/ts-timeshifter-element
**Patch 234220**, "Proposed implementation":
[0001-tstimeshift-New-plugin-for-MPEG-TS-time-shifting.patch](/uploads/bc023c5128ab9309e8ac13904b038774/0001-tstimeshift-New-plugin-for-MPEG-TS-time-shifting.patch)
### See also
* [Bug 691299](https://bugzilla.gnome.org/show_bug.cgi?id=691299)https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/103Add bindings for GstMeta and the various metas defined in the libraries2018-11-05T10:40:16ZSebastian DrögeAdd bindings for GstMeta and the various metas defined in the librarieshttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/101Structure::to_string() is crashing2018-11-05T10:40:16ZSebastian DrögeStructure::to_string() is crashing*Created by: gdesmott*
See this simple test https://github.com/gdesmott/gstreamer-rs/commit/f649a00dfb0f5b8815da60c3a5fd8cd2fddf204f
Calling `to_string()` is crashing with
> thread 'structure::tests::test_string_conversion' has ov...*Created by: gdesmott*
See this simple test https://github.com/gdesmott/gstreamer-rs/commit/f649a00dfb0f5b8815da60c3a5fd8cd2fddf204f
Calling `to_string()` is crashing with
> thread 'structure::tests::test_string_conversion' has overflowed its stackhttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/90Building on Windows x64 with MSVC not working2018-11-05T10:40:16ZSebastian DrögeBuilding on Windows x64 with MSVC not working*Created by: ArmsOfSorrow*
Hello,
I wanted to write a simple program that just reports the linked gstreamer version. It looks like this:
```
fn main() {
let version = gstreamer::version_string();
println!("Hello, world! Y...*Created by: ArmsOfSorrow*
Hello,
I wanted to write a simple program that just reports the linked gstreamer version. It looks like this:
```
fn main() {
let version = gstreamer::version_string();
println!("Hello, world! You're using {}", version);
}
```
The build fails with:
```
error: failed to run custom build command for `glib-sys v0.5.0`
process didn't exit successfully: `C:\Users\waved\Desktop\devel\projects\gst-print-version\target\debug\build\glib-sys-04fcb8127bd3b7bb\build-script-build` (exit code: 1)
--- stderr
MSVC target detected. If you are using the MSVC ABI rust build, please use the GNU ABI build instead.
```
Now, this is not a gstreamer bug per se, but I'm curious why I can't build this with the recommended default toolchain for my platform.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/89Does this crate support android?2018-11-05T10:40:16ZSebastian DrögeDoes this crate support android?*Created by: ArmsOfSorrow*
I know that the underlying gstreamer library supports it, but what's the story for this crate?*Created by: ArmsOfSorrow*
I know that the underlying gstreamer library supports it, but what's the story for this crate?https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/98Tutorial 3 does not work on OSX2018-11-05T10:40:16ZSebastian DrögeTutorial 3 does not work on OSX*Created by: ferjm*
Tutorial 3 does not play any audio and breaks with this output on OSX:
```bash
❯ ./target/debug/basic-tutorial-3
Pipeline state changed from Null to Ready
Received new pad src_0 from test-pipeline
It has type ...*Created by: ferjm*
Tutorial 3 does not play any audio and breaks with this output on OSX:
```bash
❯ ./target/debug/basic-tutorial-3
Pipeline state changed from Null to Ready
Received new pad src_0 from test-pipeline
It has type video/x-raw which is not raw audio. Ignoring.
Error received from element Some("/GstPipeline:test-pipeline/GstURIDecodeBin:source/GstSoupHTTPSrc:source") Internal data stream error.
Debugging information: Some("gstbasesrc.c(2939): void gst_base_src_loop(GstPad *) (): /GstPipeline:test-pipeline/GstURIDecodeBin:source/GstSoupHTTPSrc:source:\nstreaming stopped, reason not-linked (-1)")
```
It works perfectly fine on Linux.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/97Add bindings for GstSDPMessage and others, and the WebRTC library2018-11-05T10:40:16ZSebastian DrögeAdd bindings for GstSDPMessage and others, and the WebRTC libraryA WIP branch can be found here: https://github.com/sdroege/gstreamer-rs/tree/webrtc-sdp
Main thing that is missing at this point is to add bindings for GstSDPMessage, which unfortunately have to be fully manually written.A WIP branch can be found here: https://github.com/sdroege/gstreamer-rs/tree/webrtc-sdp
Main thing that is missing at this point is to add bindings for GstSDPMessage, which unfortunately have to be fully manually written.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/81Bug in GStreamer, mark MessageRef::get_src() unsafe?2018-11-05T10:40:16ZSebastian DrögeBug in GStreamer, mark MessageRef::get_src() unsafe?*Created by: rikte88*
When running a playbin, It turns out that messages exist on the bus where the message src pointer is invalid. (already freed or something)
Checking if msg.get_src() == pipeline sometimes causes memory corruption...*Created by: rikte88*
When running a playbin, It turns out that messages exist on the bus where the message src pointer is invalid. (already freed or something)
Checking if msg.get_src() == pipeline sometimes causes memory corruption that will crash the program at a later time.
This is of course not a problem with this excellent library, but possibly MessageRef::get_src() should be unsafe with a warning until this gets fixed in GStreamer?
This is the reason for the bug that i filed earlier:
https://github.com/sdroege/gstreamer-rs/issues/70
I managed to work around this limitation in the following way:
```
// let msg_from_pipeline = msg.get_src().unwrap() == pipeline; // DON'T DO THIS
let msg_from_pipeline = unsafe { // WORKAROUND
use glib::translate::ToGlibPtr;
use gstreamer_sys::{GstElement, GstPipeline};
let pipeline_ptr: *const GstPipeline = pipeline.to_glib_none().0;
let msg_src_ptr = (*msg.as_ptr()).src as *const GstElement;
pipeline_ptr as *const GstElement == msg_src_ptr
};
```
With the workaround, all problems go away and it works flawlessly.
Tested on Fedora 27 with:
[karlri@localhost ~]$ gst-launch-1.0 --version
gst-launch-1.0 version 1.12.4
GStreamer 1.12.4
http://download.fedoraproject.org
https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/70Memory corruption playbin no unsafe2018-11-05T10:40:16ZSebastian DrögeMemory corruption playbin no unsafe*Created by: rikte88*
A combination of bus.timed_pop(), msg.get_src(), and playbin.set_state() causes a GStreamer-CRITICAL error which makes no sense when looking at the code. The error is followed by lots of memory corruption (lots of ...*Created by: rikte88*
A combination of bus.timed_pop(), msg.get_src(), and playbin.set_state() causes a GStreamer-CRITICAL error which makes no sense when looking at the code. The error is followed by lots of memory corruption (lots of errors in valgrind). No unsafe code is needed. The bug cannot be reliably triggered, but repeatedly changing the state does the trick. The shortest example I could come up with to make it occur is attached, and valgrind output obtained with:
valgrind ./target/debug/binary > valgrind-output.txt 2>&1
[corruption-example.zip](https://github.com/sdroege/gstreamer-rs/files/1604266/corruption-example.zip)
Tested on latest stable Fedora and Debian, same result. Deleted Cargo.lock, used:
"gstreamer 0.10.1 (registry+https://github.com/rust-lang/crates.io-index)",
Used:
stable-x86_64-unknown-linux-gnu (default)
rustc 1.23.0 (766bd11c8 2018-01-01)https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/68undefined reference to gst_stream_type_get_type2018-11-05T10:40:16ZSebastian Drögeundefined reference to gst_stream_type_get_type*Created by: AndreKR*
What I did:
- Install Rust with `rustup-init.exe` and choose `x86_64-pc-windows-gnu` as default triple.
- Install MSYS2
- Inside the msys2-mingw64 shell run the command from [here](https://github.com/sdroege/gst...*Created by: AndreKR*
What I did:
- Install Rust with `rustup-init.exe` and choose `x86_64-pc-windows-gnu` as default triple.
- Install MSYS2
- Inside the msys2-mingw64 shell run the command from [here](https://github.com/sdroege/gstreamer-rs#windows)
- Create a new Rust project with `cargo new --bin test`
- Add `gstreamer = "0.10.0"` to my Cargo.toml dependencies
- Create main.rs:
```rust
extern crate gstreamer as gst;
fn main() {
gst::init().unwrap();
}
```
Now, because I got an error `ld: cannot find -lgstreamer-1.0` (and the same for `gobject-2.0`, `glib-2.0` and `gobject-2.0`) I tried setting environment variables:
```cmd
set PKG_CONFIG_PATH=C:\dev\msys64\mingw64\lib\pkgconfig
set LIBRARY_PATH=C:\dev\msys64\mingw64\lib
```
After I set `LIBRARY_PATH`, the error changed to:
> `C:\dev-projects\rust-test\test\target\debug\deps\libgstreamer-70220f7014e9955f.rlib(gstreamer-70220f7014e9955f.gstreamer8.rust-cgu.o): In function gstreamer::auto::flags::{{impl}}::static_type':
c:\dev\rust\cargo\registry\src\github.com-1ecc6299db9ec823\gstreamer-0.10.0\src\auto/flags.rs:807: undefined reference to gst_stream_type_get_type'`