GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2018-11-26T00:14:29Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/750meson: build nvdec2018-11-26T00:14:29ZBugzilla Migration Usermeson: build nvdec## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#796792)](https://bugzilla.gnome.org/show_bug.cgi?id=796792)**
## Description
See summary, pretty straightforward## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#796792)](https://bugzilla.gnome.org/show_bug.cgi?id=796792)**
## Description
See summary, pretty straightforwardhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/303flowcombiner: update_pad_flow should check that the pad is inside the combiner2021-09-24T11:09:27ZBugzilla Migration Userflowcombiner: update_pad_flow should check that the pad is inside the combiner## Submitted by Xabier Rodríguez Calvar `@calvaris`
Assigned to **Xabier Rodríguez Calvar `@calvaris`**
**[Link to original bug (#796794)](https://bugzilla.gnome.org/show_bug.cgi?id=796794)**
## Description
Created attachment 3730...## Submitted by Xabier Rodríguez Calvar `@calvaris`
Assigned to **Xabier Rodríguez Calvar `@calvaris`**
**[Link to original bug (#796794)](https://bugzilla.gnome.org/show_bug.cgi?id=796794)**
## Description
Created attachment 373000
patch
Currently it is not doing that and that can create issues
~~**Patch 373000**~~, "patch":
[0001-flowcombiner-update_pad_flow-check-for-the-pad-to-ha.patch](/uploads/9fd0b8d7e3865a4b4a13ad07fc2705e6/0001-flowcombiner-update_pad_flow-check-for-the-pad-to-ha.patch)https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/45Gstreamer RTSP client connects to Gstreamer RTSP server: Only fixed number of...2019-01-13T17:30:36ZBugzilla Migration UserGstreamer RTSP client connects to Gstreamer RTSP server: Only fixed number of connections are possible, then always "Error (503): Service Unavailable"## Submitted by Marie Maurer
**[Link to original bug (#796797)](https://bugzilla.gnome.org/show_bug.cgi?id=796797)**
## Description
Created attachment 373004
Wireshark trace of 5 successful connection and 20 not successful connect...## Submitted by Marie Maurer
**[Link to original bug (#796797)](https://bugzilla.gnome.org/show_bug.cgi?id=796797)**
## Description
Created attachment 373004
Wireshark trace of 5 successful connection and 20 not successful connections
I have a Gstreamer RTSP server, Gstreamer version 1.14.1 on Linux i.MX6.
I use a Gstreamer RTSP client, Gstreamer version 1.14.1 also on Linux i.MX6.
Both on same machine or on different machines, does not matter.
Linux is almost mainline latest.
Client side:
# cat stopme_5s
eos, name=Done-testing, playback-time=5.0
stop, playback-time=7.0
# cat run_streaming_5s_multiple_times.sh
echo "*************************************"
echo "*** HERE IS THE START OF THE TEST ***"
echo "*************************************"
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
./run_streaming_5s.sh
# cat run_streaming_5s.sh
gst-validate-1.0 --set-scenario stopme_5s rtspsrc location=rtsp://10.5.121.255:8554/live ! capsfilter caps=application/x-rtp,media=video ! rtph264depay ! identity silent=false ! fakesink
#
Server side:
Part of a bigger application.
When I let run the above test script, I see that I can connect 5 times,
but all further connects are rejected by "Error (503): Service Unavailable".
Major problem: Why only 5 connections? TCP is completely disconnected,
no still established connections? Does RTSP server not handle sudden
disconnects of the TCP connections and requires TEARDOWN to work
correctly?
Minor problem: Is it correct, that Gstreamer RTSP client (Element rtspsrc)
does not use a TEARDOWN message? Instead just disconnects?
I found https://bugzilla.gnome.org/show_bug.cgi?id=757624,
looks similar, but I assume that such an important bug is not existing for 3 years?
I attach a Wireshark trace and also a Gstreamer trace.
**Attachment 373004**, "Wireshark trace of 5 successful connection and 20 not successful connections":
[service_unavail.pcapng](/uploads/be2c609b94bd53022cce4b2c31624b7c/service_unavail.pcapng)
Version: 1.14.1https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/120Add bindings for enum types of element properties in pipeline2018-11-04T17:47:51ZSebastian DrögeAdd bindings for enum types of element properties in pipeline*Created by: js4785*
There are missing enum type bindings in regards to `Element`s in a given `Pipeline`.
One problematic example:
```rust
let queue = gst::ElementFactory::make("queue", "queue")
.expect("Could not create q...*Created by: js4785*
There are missing enum type bindings in regards to `Element`s in a given `Pipeline`.
One problematic example:
```rust
let queue = gst::ElementFactory::make("queue", "queue")
.expect("Could not create queue element.");
// queue.set_property("leaky", & ??? .to_value())
// .expect("Can't set property leaky of queue element");
```
It isn't possible to set the `leaky` property of `queue` because it is of type [`GstQueueLeaky`](https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-queue.html#GstQueueLeaky), which is an enum that doesn't at all exist in `gstreamer-rs` or its associated crates.
However it does (obviously) exist on C-level and gets instantiated at compile-time, and its representation on Rust-level can be easily shown:
```rust
let leaky_type = queue.get_property("leaky").unwrap().type_();
println!("{:?}", leaky_type);
```
Running `cargo run` would give:
```
GstQueueLeaky
```
but, at least according to my understanding of the docs, I can't use the wrapper `glib::types::Type` around `GstQueueLeaky` to set the value of the enum to something else.
If there are currently ways around this issue, I'd like to know also. Thanks!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/304Problems deserializing stream-start events2021-09-24T11:09:26ZBugzilla Migration UserProblems deserializing stream-start events## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#796806)](https://bugzilla.gnome.org/show_bug.cgi?id=796806)**
## Description
> 0:00:07.399046676 12893 0x7f6d700040a0 DEBUG rtpgstdepay gstrtpgstdepay.c:2...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#796806)](https://bugzilla.gnome.org/show_bug.cgi?id=796806)**
## Description
> 0:00:07.399046676 12893 0x7f6d700040a0 DEBUG rtpgstdepay gstrtpgstdepay.c:290:read_event:`<depayloader>` parsing event GstEventStreamStart, stream-id=(string)d9486e4ba1afa28e746e6a227057a1bbffd29ae47871dbe2c22d900098420579, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, group-id=(uint)7, stream=(GstStream)"\(GstStream\)\ stream0";
> 0:00:07.399060467 12893 0x7f6d700040a0 WARN structure gststructure.c:1974:gst_structure_parse_field: failed to parse value stream=(GstStream)(GstStream) stream0eam0";
> 0:00:07.399073720 12893 0x7f6d700040a0 WARN structure gststructure.c:2042:priv_gst_structure_parse_fields: Failed to parse field, r=stream=(GstStream)(GstStream) stream0eam0";
There are multiple problems here:
a) There's the stream in here now, which is not serializable. In older versions of GStreamer this was not a problem and as such it's arguably a backwards compatibility breakage
Not sure what we can do about that, other than letting deserialization skip over fields that it can't deserialize... which might have other problems if they are fields that are actually expected to be there (and then other code dereferences a NULL later)
b) Trying to deserialize the stream field just completely falls apart, not sure what the parsing code tries to do there at all. This might also affect other structureshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/751webrtc SDP RTX processing bug with no ssrc2020-01-18T23:25:39ZBugzilla Migration Userwebrtc SDP RTX processing bug with no ssrc## Submitted by Jan Schmidt `@thaytan`
**[Link to original bug (#796810)](https://bugzilla.gnome.org/show_bug.cgi?id=796810)**
## Description
The unit test for webrtc encounters a case where it uses an uninitialised variable here in...## Submitted by Jan Schmidt `@thaytan`
**[Link to original bug (#796810)](https://bugzilla.gnome.org/show_bug.cgi?id=796810)**
## Description
The unit test for webrtc encounters a case where it uses an uninitialised variable here in sdp_media_from_transceiver(), because the caps it generates for type == GST_WEBRTC_SDP_TYPE_OFFER don't contain an ssrc.
This patch adds a warning when that happens, but I'm not sure why it's happening:
diff --git a/ext/webrtc/gstwebrtcbin.c b/ext/webrtc/gstwebrtcbin.c
index 9baebede3..ffe0bb1c7 100644
--- a/ext/webrtc/gstwebrtcbin.c
+++ b/ext/webrtc/gstwebrtcbin.c
@@ -1701,15 +1701,17 @@ sdp_media_from_transceiver (GstWebRTCBin * webrtc, GstSDPMedia * media,
gint clockrate = -1;
gint rtx_target_pt;
gint original_rtx_target_pt; /* Workaround chrome bug: https://bugs.chromium.org/p/webrtc/issues/detail?id=6196 */
- guint rtx_target_ssrc;
+ guint rtx_target_ssrc = -1;
if (gst_structure_get_int (s, "payload", &rtx_target_pt))
g_array_append_val (reserved_pts, rtx_target_pt);
original_rtx_target_pt = rtx_target_pt;
- gst_structure_get_int (s, "clock-rate", &clockrate);
- gst_structure_get_uint (s, "ssrc", &rtx_target_ssrc);
+ if (!gst_structure_get_int (s, "clock-rate", &clockrate))
+ GST_WARNING_OBJECT (webrtc, "Caps %" GST_PTR_FORMAT " are missing clock-rate", caps);
+ if (!gst_structure_get_uint (s, "ssrc", &rtx_target_ssrc))
+ GST_WARNING_OBJECT (webrtc, "Caps %" GST_PTR_FORMAT " are missing ssrc", caps);
_pick_fec_payload_types (webrtc, WEBRTC_TRANSCEIVER (trans), reserved_pts,
clockrate, &rtx_target_pt, media);
Here's the warning:
0:00:00.874198556 16302 0x1976720 WARN webrtcbin gstwebrtcbin.c:1714:sdp_media_from_transceiver:`<webrtcbin0>` Caps application/x-rtp, payload=(int)96, encoding-name=(string)OPUS, media=(string)audio, clock-rate=(int)48000, rtcp-fb-nack-pli=(boolean)true are missing ssrchttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/752d3dvideosink: SetRenderRectangle bug2022-04-17T22:49:45ZBugzilla Migration Userd3dvideosink: SetRenderRectangle bug## Submitted by tom..@..il.com
**[Link to original bug (#796812)](https://bugzilla.gnome.org/show_bug.cgi?id=796812)**
## Description
Created attachment 373057
Gtk on Windows 10
It seems that there's a bug in d3dvideosink whe...## Submitted by tom..@..il.com
**[Link to original bug (#796812)](https://bugzilla.gnome.org/show_bug.cgi?id=796812)**
## Description
Created attachment 373057
Gtk on Windows 10
It seems that there's a bug in d3dvideosink when setting render rectangle.
I have modified
https://github.com/GStreamer/gstreamer-sharp/blob/master/samples/BasicTutorial5.cs
to set the render rectangle, like this:
VideoOverlayAdapter adapter = new
VideoOverlayAdapter(overlay.Handle);
adapter.WindowHandle = windowHandle;
adapter.SetRenderRectangle(50, 50, 427, 240);
adapter.HandleEvents(true);
I expected that the video will be rendered in the 427x240 rectangle, at the
position 50,50, but there is a correct rectangle at the position, and video
is moved to the 50,50 inside this rectangle. The same happens in the
WinForms version of the sample.
It looks OK when running on Linux Mint 19.
**Attachment 373057**, "Gtk on Windows 10":
![gtk](/uploads/b0826639105875ad7cc47ed0419c1cf6/gtk.jpg)
Version: 1.14.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/753msdkvpp: Fix renegotiation issues if upstream forces a resolution change2019-04-18T08:19:12ZBugzilla Migration Usermsdkvpp: Fix renegotiation issues if upstream forces a resolution change## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#796819)](https://bugzilla.gnome.org/show_bug.cgi?id=796819)**
## Description
If upstream decoder (for eg:), produce video frames of different resolution, curren...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#796819)](https://bugzilla.gnome.org/show_bug.cgi?id=796819)**
## Description
If upstream decoder (for eg:), produce video frames of different resolution, current msdkvpp will fail to renegotiate.
Multiple changes and some rewriting(in the allocation logic) are required to implement this.
Similar changes in the decoder: https://bugzilla.gnome.org/show_bug.cgi?id=796566 could be a good reference.
### Blocking
* [Bug 789886](https://bugzilla.gnome.org/show_bug.cgi?id=789886)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/115Caught SIGSEGV when check how played video in gst-launch2021-09-24T12:23:14ZBugzilla Migration UserCaught SIGSEGV when check how played video in gst-launch## Submitted by Mikhail Gavrilov `@Mikhail`
**[Link to original bug (#796824)](https://bugzilla.gnome.org/show_bug.cgi?id=796824)**
## Description
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.14.1
GStreamer 1.14.1
http:...## Submitted by Mikhail Gavrilov `@Mikhail`
**[Link to original bug (#796824)](https://bugzilla.gnome.org/show_bug.cgi?id=796824)**
## Description
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.14.1
GStreamer 1.14.1
http://download.fedoraproject.org
$ rpm -qa | grep -i gstreamer | sort
gstreamer1-1.14.1-5.fc29.i686
gstreamer1-1.14.1-5.fc29.x86_64
gstreamer1-debuginfo-1.14.1-5.fc29.x86_64
gstreamer1-debugsource-1.14.1-5.fc29.x86_64
gstreamer1-devel-1.14.1-5.fc29.x86_64
gstreamer1-libav-1.14.1-1.fc29.x86_64
gstreamer1-libav-debuginfo-1.14.1-1.fc29.x86_64
gstreamer1-libav-debugsource-1.14.1-1.fc29.x86_64
gstreamer1-plugins-bad-free-1.14.1-4.fc29.x86_64
gstreamer1-plugins-bad-free-debuginfo-1.14.1-4.fc29.x86_64
gstreamer1-plugins-bad-free-debugsource-1.14.1-4.fc29.x86_64
gstreamer1-plugins-base-1.14.1-3.fc29.i686
gstreamer1-plugins-base-1.14.1-3.fc29.x86_64
gstreamer1-plugins-base-debuginfo-1.14.1-3.fc29.x86_64
gstreamer1-plugins-base-debugsource-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-debuginfo-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-debugsource-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-gtk-1.14.1-3.fc29.x86_64
gstreamer1-plugins-ugly-free-1.14.1-3.fc29.x86_64
gstreamer1-plugins-ugly-free-debuginfo-1.14.1-3.fc29.x86_64
gstreamer1-plugins-ugly-free-debugsource-1.14.1-3.fc29.x86_64
gstreamer1-vaapi-1.14.1-2.fc29.x86_64
gstreamer1-vaapi-debuginfo-1.14.1-2.fc29.x86_64
gstreamer1-vaapi-debugsource-1.14.1-2.fc29.x86_64
PackageKit-gstreamer-plugin-1.1.10-1.fc29.x86_64
$ gst-launch-1.0 playbin uri=file:///home/mikhail/Videos/3D/Metallica.ThroughTheNever\(2013\)3D-halfOU\(Ash61\)Audio-5.1\(MVO.TNT\).mkv
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayWayland\)\ gldisplaywayland0";
mesa: for the -simplifycfg-sink-common option: may only occur zero or one times!
Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayEGL\)\ vaapidisplayegl0";
Redistribute latency...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
ERROR: from element /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0: Output window was closed
Additional debug info:
xvimagesink.c(555): gst_xv_image_sink_handle_xevents (): /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0
Execution ended after 0:01:08.275317701
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Caught SIGSEGV
```
#0 0x00007f15a23572b2 in __waitpid
#1 0x00007f15a2397287 in g_on_error_stack_trace
#2 0x000055edf3efcebf in fault_spin () at gst-launch.c:103
#3 0x000055edf3efcebf in fault_handler_sighandler (signum=11)
#4 0x00007f15a2357930 in <signal handler called> () at /lib64/libpthread.so.0
#5 0x00007f156a5895e0 in ()
#6 0x00007f157b6e22f6 in pipe_resource_reference (tex=0x0, ptr=0x7f157c0f65c0)
#7 0x00007f157b6e22f6 in vl_compositor_cleanup_state
#8 0x00007f157b6cf8f9 in vlVaTerminate (ctx=<optimized out>) at context.c:387
#9 0x00007f15900d6265 in vaTerminate (dpy=0x7f157c0acc90) at va.c:754
#10 0x00007f158a51ea46 in gst_vaapi_display_destroy
#11 0x00007f158a51ea46 in gst_vaapi_display_finalize
#12 0x00007f15a28a7f79 in g_object_unref (_object=0x55edf612e790)
#13 0x00007f15a2c998b9 in gst_object_unref (object=<optimized out>)
#14 0x00007f15a2c99b20 in gst_object_replace
#15 0x00007f158a51faa9 in gst_vaapi_display_replace
#16 0x00007f158a57489e in gst_vaapi_display_egl_finalize
#17 0x00007f15a28a7f79 in g_object_unref (_object=0x7f157c03a4f0)
#18 0x00007f15a2c998b9 in gst_object_unref (object=<optimized out>)
#19 0x00007f15a2c99b20 in gst_object_replace
#20 0x00007f158a51faa9 in gst_vaapi_display_replace
#21 0x00007f158a52c2c2 in gst_vaapi_video_pool_finalize (pool=0x7f15800557b0)
#22 0x00007f158a524e92 in gst_vaapi_mini_object_free (object=0x7f15800557b0)
#23 0x00007f158a4f7012 in gst_vaapipostproc_destroy (postproc=<optimized out>)
#24 0x00007f158a4f7a3d in gst_vaapipostproc_finalize (object=<optimized out>)
#25 0x00007f15a28a7f79 in g_object_unref (_object=0x7f157c191ea0)
#26 0x00007f15a2c998b9 in gst_object_unref (object=<optimized out>)
#27 0x00007f15a2cd60ea in _gst_message_free (message=0x7f15641082a0)
#28 0x00007f15a23bfb15 in g_list_foreach (list=<optimized out>,
#29 0x00007f15a23bfb3f in g_list_free_full
#30 0x00007f15a2cae287 in gst_bus_set_flushing
#31 0x00007f15a2cee465 in gst_pipeline_change_state
#32 0x00007f1595000e5d in gst_play_bin_change_state
#33 0x00007f15a2cc7902 in gst_element_change_state
#34 0x00007f15a2cc802e in gst_element_set_state_func
#35 0x000055edf3efac08 in main (argc=<optimized out>, argv=<optimized out>)
Spinning. Please run 'gdb gst-launch-1.0 12204' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
```https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/16Caught SIGSEGV when check how played video in gst-launch2018-11-04T09:57:31ZBugzilla Migration UserCaught SIGSEGV when check how played video in gst-launch## Submitted by Mikhail Gavrilov `@Mikhail`
**[Link to original bug (#796824)](https://bugzilla.gnome.org/show_bug.cgi?id=796824)**
## Description
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.14.1
GStreamer 1.14.1
http:...## Submitted by Mikhail Gavrilov `@Mikhail`
**[Link to original bug (#796824)](https://bugzilla.gnome.org/show_bug.cgi?id=796824)**
## Description
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.14.1
GStreamer 1.14.1
http://download.fedoraproject.org
$ rpm -qa | grep -i gstreamer | sort
gstreamer1-1.14.1-5.fc29.i686
gstreamer1-1.14.1-5.fc29.x86_64
gstreamer1-debuginfo-1.14.1-5.fc29.x86_64
gstreamer1-debugsource-1.14.1-5.fc29.x86_64
gstreamer1-devel-1.14.1-5.fc29.x86_64
gstreamer1-libav-1.14.1-1.fc29.x86_64
gstreamer1-libav-debuginfo-1.14.1-1.fc29.x86_64
gstreamer1-libav-debugsource-1.14.1-1.fc29.x86_64
gstreamer1-plugins-bad-free-1.14.1-4.fc29.x86_64
gstreamer1-plugins-bad-free-debuginfo-1.14.1-4.fc29.x86_64
gstreamer1-plugins-bad-free-debugsource-1.14.1-4.fc29.x86_64
gstreamer1-plugins-base-1.14.1-3.fc29.i686
gstreamer1-plugins-base-1.14.1-3.fc29.x86_64
gstreamer1-plugins-base-debuginfo-1.14.1-3.fc29.x86_64
gstreamer1-plugins-base-debugsource-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-debuginfo-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-debugsource-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-gtk-1.14.1-3.fc29.x86_64
gstreamer1-plugins-ugly-free-1.14.1-3.fc29.x86_64
gstreamer1-plugins-ugly-free-debuginfo-1.14.1-3.fc29.x86_64
gstreamer1-plugins-ugly-free-debugsource-1.14.1-3.fc29.x86_64
gstreamer1-vaapi-1.14.1-2.fc29.x86_64
gstreamer1-vaapi-debuginfo-1.14.1-2.fc29.x86_64
gstreamer1-vaapi-debugsource-1.14.1-2.fc29.x86_64
PackageKit-gstreamer-plugin-1.1.10-1.fc29.x86_64
$ gst-launch-1.0 playbin uri=file:///home/mikhail/Videos/3D/Metallica.ThroughTheNever\(2013\)3D-halfOU\(Ash61\)Audio-5.1\(MVO.TNT\).mkv
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayWayland\)\ gldisplaywayland0";
mesa: for the -simplifycfg-sink-common option: may only occur zero or one times!
Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayEGL\)\ vaapidisplayegl0";
Redistribute latency...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
ERROR: from element /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0: Output window was closed
Additional debug info:
xvimagesink.c(555): gst_xv_image_sink_handle_xevents (): /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0
Execution ended after 0:01:08.275317701
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Caught SIGSEGV
```
#0 0x00007f15a23572b2 in __waitpid
#1 0x00007f15a2397287 in g_on_error_stack_trace
#2 0x000055edf3efcebf in fault_spin () at gst-launch.c:103
#3 0x000055edf3efcebf in fault_handler_sighandler (signum=11)
#4 0x00007f15a2357930 in <signal handler called> () at /lib64/libpthread.so.0
#5 0x00007f156a5895e0 in ()
#6 0x00007f157b6e22f6 in pipe_resource_reference (tex=0x0, ptr=0x7f157c0f65c0)
#7 0x00007f157b6e22f6 in vl_compositor_cleanup_state
#8 0x00007f157b6cf8f9 in vlVaTerminate (ctx=<optimized out>) at context.c:387
#9 0x00007f15900d6265 in vaTerminate (dpy=0x7f157c0acc90) at va.c:754
#10 0x00007f158a51ea46 in gst_vaapi_display_destroy
#11 0x00007f158a51ea46 in gst_vaapi_display_finalize
#12 0x00007f15a28a7f79 in g_object_unref (_object=0x55edf612e790)
#13 0x00007f15a2c998b9 in gst_object_unref (object=<optimized out>)
#14 0x00007f15a2c99b20 in gst_object_replace
#15 0x00007f158a51faa9 in gst_vaapi_display_replace
#16 0x00007f158a57489e in gst_vaapi_display_egl_finalize
#17 0x00007f15a28a7f79 in g_object_unref (_object=0x7f157c03a4f0)
#18 0x00007f15a2c998b9 in gst_object_unref (object=<optimized out>)
#19 0x00007f15a2c99b20 in gst_object_replace
#20 0x00007f158a51faa9 in gst_vaapi_display_replace
#21 0x00007f158a52c2c2 in gst_vaapi_video_pool_finalize (pool=0x7f15800557b0)
#22 0x00007f158a524e92 in gst_vaapi_mini_object_free (object=0x7f15800557b0)
#23 0x00007f158a4f7012 in gst_vaapipostproc_destroy (postproc=<optimized out>)
#24 0x00007f158a4f7a3d in gst_vaapipostproc_finalize (object=<optimized out>)
#25 0x00007f15a28a7f79 in g_object_unref (_object=0x7f157c191ea0)
#26 0x00007f15a2c998b9 in gst_object_unref (object=<optimized out>)
#27 0x00007f15a2cd60ea in _gst_message_free (message=0x7f15641082a0)
#28 0x00007f15a23bfb15 in g_list_foreach (list=<optimized out>,
#29 0x00007f15a23bfb3f in g_list_free_full
#30 0x00007f15a2cae287 in gst_bus_set_flushing
#31 0x00007f15a2cee465 in gst_pipeline_change_state
#32 0x00007f1595000e5d in gst_play_bin_change_state
#33 0x00007f15a2cc7902 in gst_element_change_state
#34 0x00007f15a2cc802e in gst_element_set_state_func
#35 0x000055edf3efac08 in main (argc=<optimized out>, argv=<optimized out>)
Spinning. Please run 'gdb gst-launch-1.0 12204' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
```https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/121Automatically install and link gstreamer on any OS2018-11-04T17:47:51ZSebastian DrögeAutomatically install and link gstreamer on any OS*Created by: JoshuaBatty*
Hey guys, really excited to see gstreamer working in Rust. @mitchmindtree and I are working on a creative coding library for Rust called [Nannou](https://github.com/nannou-org/nannou) and we would love to use g...*Created by: JoshuaBatty*
Hey guys, really excited to see gstreamer working in Rust. @mitchmindtree and I are working on a creative coding library for Rust called [Nannou](https://github.com/nannou-org/nannou) and we would love to use grstreamer-rs as the official video streaming backend.
The goals of the project is to offer something similar to [Processing](https://processing.org/) in that artists and designers who may not have much experience with coding can get up and running really quickly. Obviously cargo makes this process perfect for this if only pure rust libraries are used. It becomes a bit of a stretch when users are required to link to C libraries on their system.
As a result, i'm looking at a way of completely automating the downloading and install process for gstreamer which we can put in the build.rs file for Nannou.
Currently I have the [this repo](https://github.com/JoshuaBatty/auto_install_gstreamer) setup for testing this process. I've tested it on Mac OS and everything downloaded and worked successfully first time on a fresh machine. Basically the program does the following
1. Checks for an existing hombrew installation
2. Downloads and installs hombrew if an existing installation wasn't found
3. Checks for an existing gstreamer install
4. Downloads and installs gstreamer in an existing installation wasn't found
After running the program, I can download and run the tutorial examples for this repo without any extra manual work. Great! One BIG problem is that it took around 5 hours on my 7 year old macbook air machine to download and compile all the necessary brew taps before it could install gstreamer.
My current thoughts are it would be better to fetch the binaries and have script install them that way, but I can't find a way of doing this for linux. Also, how to approach installing gstreamer on a linux machine that uses a package manager other than apt-get.... things could start getting messy.
Also, if you're interested we would be happy to contribute this upstream as a build.rs file for this repo. Of course we understand if you would like to keep this as a manual installation step that you require users to do.
Would love to hear any thoughts, questions or criticisms. Thanks.
https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/40composition: Output one single segment "per seek"2021-09-24T12:21:05ZBugzilla Migration Usercomposition: Output one single segment "per seek"## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#796831)](https://bugzilla.gnome.org/show_bug.cgi?id=796831)**
## Description
See commit message.## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#796831)](https://bugzilla.gnome.org/show_bug.cgi?id=796831)**
## Description
See commit message.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/754srtpdec: remove bogus check that accesses uninitialized memory2023-04-12T07:46:13ZBugzilla Migration Usersrtpdec: remove bogus check that accesses uninitialized memory## Submitted by Michael Olbrich `@mol`
**[Link to original bug (#796835)](https://bugzilla.gnome.org/show_bug.cgi?id=796835)**
## Description
I came across this while using valgrind to debug a unrelated problem. I'm
not sure what ...## Submitted by Michael Olbrich `@mol`
**[Link to original bug (#796835)](https://bugzilla.gnome.org/show_bug.cgi?id=796835)**
## Description
I came across this while using valgrind to debug a unrelated problem. I'm
not sure what the check was meant to do but I see no reason the check
anything but the return value of gst_structure_get()https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/41Review and test encoder and decoder properties2019-04-09T19:05:29ZBugzilla Migration UserReview and test encoder and decoder properties## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#796839)](https://bugzilla.gnome.org/show_bug.cgi?id=796839)**
## Description
Create from [bug 792900](https://bugzilla.gnome.org/show_bug.cgi?id=792900)
Th...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#796839)](https://bugzilla.gnome.org/show_bug.cgi?id=796839)**
## Description
Create from [bug 792900](https://bugzilla.gnome.org/show_bug.cgi?id=792900)
The new properties were only lightly tested. There is still a lot of property that make little sense or are not usable for specific encoders, so some properties might be applied to audio encoder that only make sense for video. Some extra filtering might be needed.
There is a also some bugs. To use H263 with RTP, you need to set the GOB size, that property was called "rtp-payload-size", without that it works badly in RTP. Need to chase this up, might be an upstream FFMPEG bug.1.15.90https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/472gstglwayland: Crash when wl_shell is not support2021-09-24T13:24:18ZBugzilla Migration Usergstglwayland: Crash when wl_shell is not support## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#796841)](https://bugzilla.gnome.org/show_bug.cgi?id=796841)**
## Description
Similar to [bug 796772](https://bugzilla.gnome.org/show_bug.cgi?id=796772), libgstg...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#796841)](https://bugzilla.gnome.org/show_bug.cgi?id=796841)**
## Description
Similar to [bug 796772](https://bugzilla.gnome.org/show_bug.cgi?id=796772), libgstgl does not work well if there is no wl_shell support. In fact, it crash. I am working on patches.
The compositor:
weston --shell fullscreen-shell.so
GStreamer:
gst-play-1.0 somefile --videosink=glimagesinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/755srt: Refactor plugin to support non-blocking SRT APIs2021-09-24T14:36:34ZBugzilla Migration Usersrt: Refactor plugin to support non-blocking SRT APIs## Submitted by Seungha Yang
**[Link to original bug (#796842)](https://bugzilla.gnome.org/show_bug.cgi?id=796842)**
## Description
Add support "srt://localhost:port" style uri, and change the
default host to "localhost"## Submitted by Seungha Yang
**[Link to original bug (#796842)](https://bugzilla.gnome.org/show_bug.cgi?id=796842)**
## Description
Add support "srt://localhost:port" style uri, and change the
default host to "localhost"https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/122gstreamer-rtsp-server build Error on armv7l (RasperryPI): expected u8, found i82018-11-04T17:47:51ZSebastian Drögegstreamer-rtsp-server build Error on armv7l (RasperryPI): expected u8, found i8*Created by: meldron*
Hi there,
trying to build `gstreamer-rtsp-server` on armv7l (Raspberry PI) fails with the following errors:
```
error[E0308]: mismatched types
--> gstreamer/src/tags.rs:197:39
|
197 | ...*Created by: meldron*
Hi there,
trying to build `gstreamer-rtsp-server` on armv7l (Raspberry PI) fails with the following errors:
```
error[E0308]: mismatched types
--> gstreamer/src/tags.rs:197:39
|
197 | ffi::gst_tag_get_type(tag_name.as_ptr() as *const i8)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected u8, found i8
|
= note: expected type `*const u8`
found type `*const i8`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
error: Could not compile `gstreamer`.
warning: build failed, waiting for other jobs to finish...
error: aborting due to 4 previous errors
Some errors occurred: E0277, E0308.
For more information about an error, try `rustc --explain E0277`.
error: Could not compile `gio`.
```
I previously reported the error at [gpio](https://github.com/gtk-rs/gio/issues/137), where @sdroege suggested that:
> Somewhere there must be a u8 or i8 instead of c_char
```
error[E0308]: mismatched types
--> gstreamer/src/tags.rs:197:39
|
197 | ffi::gst_tag_get_type(tag_name.as_ptr() as *const i8)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected u8, found i8
|
= note: expected type `*const u8`
found type `*const i8`
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/756msdk: msdkmjpegdec fail.2018-12-03T04:09:35ZBugzilla Migration Usermsdk: msdkmjpegdec fail.## Submitted by wangfei `@wangfei`
**[Link to original bug (#796853)](https://bugzilla.gnome.org/show_bug.cgi?id=796853)**
## Description
$ gst-launch-1.0 filesrc location=0795image04_1280x1024.jpg ! jpegparse ! msdkmjpegdec ! msd...## Submitted by wangfei `@wangfei`
**[Link to original bug (#796853)](https://bugzilla.gnome.org/show_bug.cgi?id=796853)**
## Description
$ gst-launch-1.0 filesrc location=0795image04_1280x1024.jpg ! jpegparse ! msdkmjpegdec ! msdkvpp ! glimagesink
0:00:00.038675694 29386 0x1a76050 ERROR msdkdec gstmsdkdec.c:409:gst_msdkdec_init_decoder:`<msdkmjpegdec0>` Init failed (undeveloped feature)
0:00:00.038692225 29386 0x1a76050 ERROR msdkdec gstmsdkdec.c:824:gst_msdkdec_negotiate:`<msdkmjpegdec0>` Failed to renegotiationhttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/66Error in recipe Soundtouch2018-11-07T09:39:10ZBugzilla Migration UserError in recipe Soundtouch## Submitted by Dagomi2cat
**[Link to original bug (#796854)](https://bugzilla.gnome.org/show_bug.cgi?id=796854)**
## Description
The url in the recipe don't work because the url is down.
url = 'http://www.surina.net/soundtouch...## Submitted by Dagomi2cat
**[Link to original bug (#796854)](https://bugzilla.gnome.org/show_bug.cgi?id=796854)**
## Description
The url in the recipe don't work because the url is down.
url = 'http://www.surina.net/soundtouch/soundtouch-1.9.2.tar.gz'
I use the alternative url
url ='https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/soundtouch/1.9.2-2/soundtouch_1.9.2.orig.tar.gz'
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/67Error in recipe openssl2018-11-07T09:39:58ZBugzilla Migration UserError in recipe openssl## Submitted by Dagomi2cat
**[Link to original bug (#796855)](https://bugzilla.gnome.org/show_bug.cgi?id=796855)**
## Description
The version 1.1.0h of the openssl do't existis in the ftp://ftp.openssl.org/source/ it should be chang...## Submitted by Dagomi2cat
**[Link to original bug (#796855)](https://bugzilla.gnome.org/show_bug.cgi?id=796855)**
## Description
The version 1.1.0h of the openssl do't existis in the ftp://ftp.openssl.org/source/ it should be changed to 1.1.0g.
Version: 1.14.0