GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T16:19:59Zhttps://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/33Cannot build armeabi-v7a arm64-v8a at the same time on android studio2021-09-24T16:19:59ZChangNam AnCannot build armeabi-v7a arm64-v8a at the same time on android studioMy environment is...
Android Studio: 3.2.1
Android ndk version: r14b
Gradle version: 3.1.0
Gstreamer version: gstreamer-1.0-android-universal-1.14.1
If `APP_ABI := armeabi armeabi-v7a` is built correctly but `APP_ABI := armeabi armeabi...My environment is...
Android Studio: 3.2.1
Android ndk version: r14b
Gradle version: 3.1.0
Gstreamer version: gstreamer-1.0-android-universal-1.14.1
If `APP_ABI := armeabi armeabi-v7a` is built correctly but `APP_ABI := armeabi armeabi-v7a arm64-v8a` is not built and
I toke error log as below.
Please let me know how to fix this issue.
```
> Task :app:buildNative
10:47:05.891 [QUIET] [system.out] GStreamer : [LINK] => gst-build-armeabi/libgstreamer_android.so
10:47:07.304 [QUIET] [system.out] Done mkdir
10:47:07.325 [QUIET] [system.out] Done cp
10:47:07.558 [QUIET] [system.out] [armeabi] Prebuilt : libgstreamer_android.so <= gst-build-armeabi/
10:47:07.634 [QUIET] [system.out] Done rm
10:47:07.671 [QUIET] [system.out] [armeabi] Install : libgstreamer_android.so => libs/armeabi/libgstreamer_android.so
10:47:07.860 [QUIET] [system.out] [armeabi] SharedLibrary : libtutorial-4.so
10:47:08.041 [QUIET] [system.out] [armeabi] Install : libtutorial-4.so => libs/armeabi/libtutorial-4.so
10:47:08.152 [QUIET] [system.out] GStreamer : [GEN] => gst-build-armeabi-v7a/gstreamer_android.c
10:47:08.288 [QUIET] [system.out] GStreamer : [COMPILE] => gst-build-armeabi-v7a/gstreamer_android.c
10:47:08.755 [QUIET] [system.out] GStreamer : [LINK] => gst-build-armeabi-v7a/libgstreamer_android.so
10:47:10.131 [QUIET] [system.out] Done mkdir
10:47:10.152 [QUIET] [system.out] Done cp
10:47:10.385 [QUIET] [system.out] [armeabi-v7a] Prebuilt : libgstreamer_android.so <= gst-build-armeabi-v7a/
10:47:10.397 [null] [org.gradle.process.internal.health.memory.MemoryManager]
10:47:10.397 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 17019641856, Free: 7089037312}
10:47:10.397 [DEBUG] [org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 17019641856, Free: 7089037312}
10:47:10.397 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 954728448, Committed: 613941248}
10:47:10.400 [null] [org.gradle.internal.progress.DefaultBuildOperationExecutor]
> Task :app:buildNative FAILED
10:47:10.461 [QUIET] [system.out] Done rm
10:47:10.500 [QUIET] [system.out] [armeabi-v7a] Install : libgstreamer_android.so => libs/armeabi-v7a/libgstreamer_android.so
10:47:10.678 [QUIET] [system.out] [armeabi-v7a] SharedLibrary : libtutorial-4.so
10:47:10.845 [QUIET] [system.out] [armeabi-v7a] Install : libtutorial-4.so => libs/armeabi-v7a/libtutorial-4.so
10:47:10.953 [QUIET] [system.out] GStreamer : [GEN] => gst-build-arm64-v8a/gstreamer_android.c
10:47:11.082 [QUIET] [system.out] GStreamer : [COMPILE] => gst-build-arm64-v8a/gstreamer_android.c
10:47:11.434 [QUIET] [system.out] GStreamer : [LINK] => gst-build-arm64-v8a/libgstreamer_android.so
10:47:12.306 [ERROR] [system.err] C:/Android/android-ndk-r14b-windows-x86_64/android-ndk-r14b/build//../toolchains/aarch64-linux-android-4.9/prebuilt/windows-x86_64/lib/gcc/aarch64-linux-android/4.9.x/../../../../aarch64-linux-android/bin\l
d.gold.exe: error: D:/MyProject/gstreamer-1.0-android-universal-1.14.1/arm/lib/gstreamer-1.0/libgstcoreelements.a(libgstcoreelements_la-gstelements.o): incompatible target
10:47:12.306 [ERROR] [system.err] gst-build-arm64-v8a/gstreamer_android.c:67: error: undefined reference to 'gst_plugin_coreelements_register'
10:47:12.344 [ERROR] [system.err] clang.exe: error: linker command failed with exit code 1 (use -v to see invocation)
10:47:12.354 [ERROR] [system.err] make: *** [buildsharedlibrary_arm64-v8a] Error 1
10:47:12.355 [QUIET] [system.out] make: Leaving directory `D:/MyProject/project/app/src/main'
10:47:12.363 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: FAILED
```
Thanks in advance.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/354unregister + register plugin makes plugin unavailable to playbin2022-11-10T09:20:51ZAaron Boxerunregister + register plugin makes plugin unavailable to playbinVersion 1.14.1 on Windows.
Suppose I have a working plugin `FOO` that works with `playbin`.
AFter initializing gstreamer, I call
```
auto reg = gst_registry_get ();
auto plugin = gst_registry_find_plugin (reg, "FOO");
if (plugin){
gs...Version 1.14.1 on Windows.
Suppose I have a working plugin `FOO` that works with `playbin`.
AFter initializing gstreamer, I call
```
auto reg = gst_registry_get ();
auto plugin = gst_registry_find_plugin (reg, "FOO");
if (plugin){
gst_registry_remove_plugin(reg, plugin);
gst_registry_add_plugin(reg,plugin);
}
```
and the plugin's elements are now no longer available for auto-plugging in `playbin`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/547glcolorbalance: Corrupted output2021-09-24T13:24:49ZSebastian Drögeglcolorbalance: Corrupted outputThe pipeline in https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/546 causes corrupted output, see attached picture.
![Screenshot_from_2019-01-24_10-19-49](/uploads/c47a09d6513e6a9532d75fa227033977/Screenshot_from_2019-01...The pipeline in https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/546 causes corrupted output, see attached picture.
![Screenshot_from_2019-01-24_10-19-49](/uploads/c47a09d6513e6a9532d75fa227033977/Screenshot_from_2019-01-24_10-19-49.png)https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/61Make all TimelineElement timestamps "frame based" / rational numbers / TimeCodes2021-09-24T12:17:16ZThibault Sauniertsaunier@igalia.comMake all TimelineElement timestamps "frame based" / rational numbers / TimeCodesCurrently all times in GES are GstClockTime, meaning they are on a nanosecond scale.
Since video material is based on frames, for video editing this degree of freedom can
lead to small glitches. In that context it's more accurate to spec...Currently all times in GES are GstClockTime, meaning they are on a nanosecond scale.
Since video material is based on frames, for video editing this degree of freedom can
lead to small glitches. In that context it's more accurate to specify the times by
the number of frames, within a scale defined by the framerate. Note all major video
editing apps use this one way or the other.
This is a proposal to allow GES to base timestamps on output and media files framerates.
For that we can reuse [GstVideoTimeCode] which implements
all the logic for converting Video timecode as standardized by the SMPTE to
`GstClockTime`s. This means that if we write a new API using that object that
logic is already abstracted out even though the VideoTimeCode API doesn't 100%
match our needs and we will probably add some helper methods/constructors to
better fit with our use case.
[GstVideoTimeCode]: https://gstreamer.freedesktop.org/documentation/video/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideotimecode.html?gi-language=c#GstVideoTimeCode
## API additions:
### `GESTimeline`
The idea would be to introduce a `(GstFraction) GESTimeline:rate` property on
which all timestamps will be "snapped", with that done, we need each and every
`GESTimelineElement` timestamps inside a timeline snapped to it.
We still need backward compatibility with previous behaviour, and to do so, the
idea is to have a mode where no snapping happens, and to make that happen, the
possible solution is to make `GESTimeline:rate == NULL` mean "no
snapping should happen. What should be the `GESTimeline:rate` default value?
`NULL` so that default behaviour is unchanged?
Also one case we need to handle is setting the `GESTimeline:rate`, which
involves retimestamping all contained objects in a sensible way.
Also, setting `GESTimeline:rate` will override any
`GESTrack:restriction-caps['framerate']` value.
### `GESTimelineElement`
Add `_timecode` setter variants for timestamps, for example:
``` c
gboolean ges_timeline_element_set_start_timecode (GESTimelineElement *element, GstVideoTimeCode *start);
gboolean ges_timeline_element_set_inpoint_timecode (GESTimelineElement *element, GstVideoTimeCode *duration);
gboolean ges_timeline_element_set_duration_timecode (GESTimelineElement *element, GstVideoTimeCode *duration);
gboolean ges_timeline_element_ripple_timecode (GESTimelineElement *self, GstVideoTimeCode *start);
gboolean ges_timeline_element_ripple_end_timecode (GESTimelineElement *self, GstVideoTimeCode *end);
gboolean ges_timeline_element_roll_start_timecode (GESTimelineElement *self, GstVideoTimeCode *start);
gboolean ges_timeline_element_roll_end_timecode (GESTimelineElement *self, GstVideoTimeCode *end);
gboolean ges_timeline_element_trim_timecode (GESTimelineElement *self, GstVideoTimeCode *start);
```
### Clips
* `GESUriSource:inpoint` should probably use the input file rate and we should
try to make that the default. Currently we anyway have a videorate element
that makes the output framerate the one of the `GESTrack:restriction-caps`
value, we should try to change that behaviour and let the `compositor` handle
the framerate modulation between input streams
* `GESTimelineElement:duration`: Currently we do not make a difference between
the consumed duration of the input clip and the outputed duration in the timeline,
mainly because we do not handle time stretching yet. Having a rate for that
timestamp that is different than the one of the timeline leads to inconsistency in
terms of what that timestamp represents, and when "drawing" a representation the time
will need to be converted, this is far from ideal.
=> **Should we add a new notion of "input-duration" or "media-duration" ?**
``` c
GESClip* ges_clip_split_timecode (GESClip *clip, GstVideoTimeCode *position);
```
### Container
``` c
gboolean ges_container_edit_timecode (GESContainer *container,
GList *layers,
gint new_layer_priority,
GESEditMode mode,
GESEdge edge,
GstVideoTimeCode *position);
```https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/176Add bindings for the Tag library2023-02-08T08:07:38ZSebastian DrögeAdd bindings for the Tag libraryEspecially all those additional tag types defined there. They need to be manually implemented, one trait impl per tag type (see `gstreamer/src/tag.rs` for details).Especially all those additional tag types defined there. They need to be manually implemented, one trait impl per tag type (see `gstreamer/src/tag.rs` for details).https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/545gstaudioaggregator: segfault in gst_audio_aggregator_aggregate()2021-09-24T13:24:48ZYury Mukhitovgstaudioaggregator: segfault in gst_audio_aggregator_aggregate()GStreamer 1.14.2, OS CentOS 7.3 64-bit
**Problem Description**
`gst_audio_aggregator_aggregate()` function acquires locks on `'agg'` and `'aagg'` then iterates over sink pads:
```
(at gstaudioaggregator.c:1786)
for (; iter; iter = ...GStreamer 1.14.2, OS CentOS 7.3 64-bit
**Problem Description**
`gst_audio_aggregator_aggregate()` function acquires locks on `'agg'` and `'aagg'` then iterates over sink pads:
```
(at gstaudioaggregator.c:1786)
for (; iter; iter = iter->next) {
GstAudioAggregatorPad *pad = (GstAudioAggregatorPad *) iter->data;
GstAggregatorPad *aggpad = (GstAggregatorPad *) iter->data;
gboolean pad_eos = gst_aggregator_pad_is_eos (aggpad);
```
During the pads iteration the `gst_audio_aggregator_mix_buffer()` function gets called which releases the `'pad'` and `'aagg'` locks temporarily:
```
(at gstaudioaggregator.c:1577)
GST_OBJECT_UNLOCK (pad);
GST_OBJECT_UNLOCK (aagg);
filled = GST_AUDIO_AGGREGATOR_GET_CLASS (aagg)->aggregate_one_buffer (aagg,
pad, inbuf, in_offset, outbuf, out_start, overlap);
GST_OBJECT_LOCK (aagg);
GST_OBJECT_LOCK (pad);
```
This makes the removal of a pad from audiomixer possible (executed concurrently from other thread).
The pad removal invalidates current pad iterator because its memory (an element of GList) gets freed.
Next iteration cycle in `gst_audio_aggregator_aggregate()` executes `'iter = iter->next'` then accesses an invalid `'iter'` pointer with `'iter->data'` statement.
This results in a segfault due to dereferencing of invalid pointer. Occasionally this error manifests as a lock up on a mutex in `gst_aggregator_pad_is_eos()`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/878wpesrc: possible race condition in gst_wpe_src_create()2021-09-24T14:36:56ZPhilippe Normandwpesrc: possible race condition in gst_wpe_src_create()Sometimes the element hits this condition:
```
g_return_val_if_fail(img != NULL, GST_FLOW_ERROR);
```
The element should be able to wait for the first valid EGLImage coming from the WPE backend, filling empty buffers in the mean time.Sometimes the element hits this condition:
```
g_return_val_if_fail(img != NULL, GST_FLOW_ERROR);
```
The element should be able to wait for the first valid EGLImage coming from the WPE backend, filling empty buffers in the mean time.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/875mpegtspacketizer: Not enough information to calculate proper timestamp when p...2022-06-29T09:10:35Zdirac bracketmpegtspacketizer: Not enough information to calculate proper timestamp when playing radio streamHi,
I am on Debian 9.5 using GStreamer 1.10.4 and was trying to get the following radio stream URI to play:
```
http://kong.kbskme.gscdn.com/1fm/_definst_/1fm.stream/playlist.m3u8?_lsu_sa_=3c659434ccaf31a3e487c7ac3f91273d138c6da2308db4...Hi,
I am on Debian 9.5 using GStreamer 1.10.4 and was trying to get the following radio stream URI to play:
```
http://kong.kbskme.gscdn.com/1fm/_definst_/1fm.stream/playlist.m3u8?_lsu_sa_=3c659434ccaf31a3e487c7ac3f91273d138c6da2308db4ff6d84653b703034a987d8defc35733864acfc38d5dcb24358235664fa74b665a0aa1808b70d504d61efebb17d2c38ff66efc58c0f860e1f43
```
This is what the command line output is when using gst-launch-1.0 -v playbin3:
```
umagi@debian:~$ gst-launch-1.0 -v playbin3 uri=http://kong.kbskme.gscdn.com/1fm/_definst_/1fm.stream/playlist.m3u8?_lsu_sa_=3c659434ccaf31a3e487c7ac3f91273d138c6da2308db4ff6d84653b703034a987d8defc35733864acfc38d5dcb24358235664fa74b665a0aa1808b70d504d61efebb17d2c38ff66efc58c0f860e1f43
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0: ring-buffer-max-size = 0
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0: buffer-size = -1
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0: buffer-duration = -1
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0: use-buffering = false
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0: download = false
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0: uri = http://kong.kbskme.gscdn.com/1fm/_definst_/1fm.stream/playlist.m3u8?_lsu_sa_=3c659434ccaf31a3e487c7ac3f91273d138c6da2308db4ff6d84653b703034a987d8defc35733864acfc38d5dcb24358235664fa74b665a0aa1808b70d504d61efebb17d2c38ff66efc58c0f860e1f43
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0: connection-speed = 0
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0: source = "\(GstSoupHTTPSrc\)\ source"
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0/GstTypeFindElement:typefindelement0.GstPad:src: caps = application/x-hls
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0/GstHLSDemux:hlsdemux0.GstPad:sink: caps = application/x-hls
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0/GstHLSDemux:hlsdemux0.GstPad:src_0: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0/GstQueue2:queue2-1.GstPad:sink: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0/GstQueue2:queue2-1.GstPad:src: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0.GstGhostPad:src_0: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstDecodebin3:decodebin3-0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0.GstGhostPad:sink.GstProxyPad:proxypad3: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstTypeFindElement:typefind.GstPad:src: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstTSDemux:tsdemux0.GstPad:sink: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstTypeFindElement:typefind.GstPad:sink: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0.GstGhostPad:sink: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstDecodebin3:decodebin3-0.GstGhostPad:sink: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstURISourceBin:urisourcebin0.GstGhostPad:src_0.GstProxyPad:proxypad2: caps = video/mpegts, systemstream=(boolean)true, packetsize=(int)188
/GstPlayBin3:playbin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstAacParse:aacparse0.GstPad:sink: caps = audio/mpeg, mpegversion=(int)2, stream-format=(string)adts
buffering... 0%
```
But nothing happens.
Since this kind of URI plays OK in VLC this does not seem to be a server-side issue.
Following the suggestions and help of Philippe Normand to my post on this issue on the GStreamer-devel mail list
[read post](http://gstreamer-devel.966125.n4.nabble.com/How-to-play-internet-radio-URL-with-query-td4689399.html), I added the gst.log and the stream.ts capture file in attach.
The gst.log file shows a flurry of warnings of the kind:
```
0:00:00.287885677 6377 0x555e54214630 WARN mpegtspacketizer mpegtspacketizer.c:2331:mpegts_packetizer_pts_to_ts: Not enough information to calculate proper timestamp
```
[gst.log](/uploads/8b0ebdebd3f2383b9ac8b106ef432fb9/gst.log)[stream.ts](/uploads/8b3e74bed7a0e1fe050cf854dd08e397/stream.ts)
Can you have a check?
Thanks!https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/60Add a configuration for max-bitrate2021-09-24T11:03:44ZJuho YlikorpiAdd a configuration for max-bitrateRe-purposed from initial issue:
> UDP streams with large I-frames (4K ip-cameras and even some 1080p) are generating too large UDP burst and those will be dropped by routers/VPN GWs etc. with small buffers (datacenter connections are 10...Re-purposed from initial issue:
> UDP streams with large I-frames (4K ip-cameras and even some 1080p) are generating too large UDP burst and those will be dropped by routers/VPN GWs etc. with small buffers (datacenter connections are 10Gbits but Internet only 100Mbits).
While it's theoretically possible through GstBin::deep-element-added signal to do custom setup on the udpsink, it is likely that these days more and more users will need to control the burst rate. The buffer-size has been exposed similarly if I read the code correctly.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/352harness: caps/segment event sending should be decoupled2021-09-24T11:09:18ZSebastian Drögeharness: caps/segment event sending should be decoupledYou don't always want a new default segment event to be sent when the caps are changed, and you might want to handle segments yourself.
Any ideas for how to do this in a backwards compatible way?You don't always want a new default segment event to be sent when the caps are changed, and you might want to handle segments yourself.
Any ideas for how to do this in a backwards compatible way?https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/48invalidate cache when external libav* changes2021-09-24T12:52:30ZRobert McQueeninvalidate cache when external libav* changesEndless OS and Flatpak runtimes with a codecs extension both share the property that in certain cases, libav gets replaced with a more capable version elsewhere on the library search path. The GStreamer caching machinery does not "notice...Endless OS and Flatpak runtimes with a codecs extension both share the property that in certain cases, libav gets replaced with a more capable version elsewhere on the library search path. The GStreamer caching machinery does not "notice" this change (indeed I'm not sure it's monitoring the dependent .so files at all) so in the case of a more capable system libav with more supported codecs, if GStreamer has already built its caches they are not updated and the new codecs are unavailable.
Endless has an ugly patch for this which has been copied into the Flatpak freedesktop-sdk runtime - https://gitlab.com/freedesktop-sdk/freedesktop-sdk/blob/18.08/patches/gst-libav-stop-caching-codecs.patch
This works, in as much as when a more capable libav is provided in an alternative location on the path, the cache is invalidated and refreshed. However it has the obvious downside that this is hardcoding the library search path, which means that if you place a different libav in another location on the library path (particularly in a sandboxed context like Flatpak where the library path can be changed dynamically) it is not noticed.
We could avoid hardcoding the library path and solve this problem more robustly by fetching the path of the currently loaded libav* using dlinfo, and then making the cache validity dependent on the properties of that file, so that if a different one is found by the linker, the cache will be correctly invalidated.
Perhaps in the end you would want to add a function to the registry to allow a dynamic library file cache dependency to be added easily, or you could do this dlinfo lookup in gst-libav as a special case.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/551flac: Transcoding result in no audio (underflow)2021-09-24T13:33:17ZNicolas Dufresneflac: Transcoding result in no audio (underflow)I was surprised to find out, but a simple encoder/parse/decoder chain leads to no audio, disabling the sync fixes it.
```
gst-launch-1.0 pulsesrc ! flacenc ! flacparse ! flacdec ! pulsesink sync=1
```
p.s. I also don't know why a parse...I was surprised to find out, but a simple encoder/parse/decoder chain leads to no audio, disabling the sync fixes it.
```
gst-launch-1.0 pulsesrc ! flacenc ! flacparse ! flacdec ! pulsesink sync=1
```
p.s. I also don't know why a parser is required.https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/58Test Timeout of check.gst-rtsp-server.gst_rtspserver.test_play_smpte_range2021-09-24T11:03:44ZNicolas DufresneTest Timeout of check.gst-rtsp-server.gst_rtspserver.test_play_smpte_rangeThis test timed out in one of my MR, and it's unrelated to the changes:
https://gitlab.freedesktop.org/ndufresne/gst-plugins-base/-/jobs/82545
```
check.gst-rtsp-server.gst_rtspserver.test_play_smpte_range: Timeout 'Application timed ou...This test timed out in one of my MR, and it's unrelated to the changes:
https://gitlab.freedesktop.org/ndufresne/gst-plugins-base/-/jobs/82545
```
check.gst-rtsp-server.gst_rtspserver.test_play_smpte_range: Timeout 'Application timed out: 120.0 secs'
You can reproduce with: GST_STATE_IGNORE_ELEMENTS='' GST_REGISTRY='/builds/ndufresne/gst-plugins-base/gst-build/build/subprojects/gst-rtsp-server/tests/check/gst/rtspserver.registry' CK_DEFAULT_TIMEOUT='120' GST_CHECKS='test_play_smpte_range' GST_PLUGIN_SYSTEM_PATH_1_0='' GST_PLUGIN_PATH_1_0='/builds/ndufresne/gst-plugins-base/gst-build/build' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base:gst-plugins-good:gst-plugins-bad:gst-rtsp-server' /builds/ndufresne/gst-plugins-base/gst-build/build/subprojects/gst-rtsp-server/tests/check/gst_rtspserver
Dumping log files on failure
Dumping contents of /builds/ndufresne/gst-plugins-base/validate-output/logs/check/gst-rtsp-server/gst_rtspserver/test_play_smpte_range
=================
Test name: check.gst-rtsp-server.gst_rtspserver.test_play_smpte_range
Command: '/builds/ndufresne/gst-plugins-base/gst-build/build/subprojects/gst-rtsp-server/tests/check/gst_rtspserver'
=================
Running suite(s): rtspserver
0%: Checks: 1, Failures: 0, Errors: 1
../subprojects/gst-rtsp-server/tests/check/gst/rtspserver.c:385:E:general:test_play_smpte_range:0: (after this point) Test timeout expired
Check suite rtspserver ran in 120.028s (tests failed: 1)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/869missing rtmpsink with credentials (pubUser:pubPasswd)2021-09-24T14:36:55ZAlexandermissing rtmpsink with credentials (pubUser:pubPasswd)After struggling and diving through code for several hours last night I ended up concluding that the rtmpsink in gstreamer does not support using user:pass credentials.
In principle librtmp should support this. Typically using the argum...After struggling and diving through code for several hours last night I ended up concluding that the rtmpsink in gstreamer does not support using user:pass credentials.
In principle librtmp should support this. Typically using the arguments ``pubUser`` and ``pubPasswd`` however a pipeline such as ``rtmpsink location="rtmp://url/app/key live=true pubUser=username pubPasswd=password"`` does not work.
I have looked at OBS, which also uses librtmp but apparently are maintaining a fork inside their source-tree:
https://github.com/obsproject/obs-studio/blob/06488a55ce6728edf11bd0db47a164a70633936a/plugins/obs-outputs/librtmp/rtmp.c#L3347
Thus I'm not sure where all the differences are and why it is currently not possible to use this in gstreamer.
Hopefully someone with more knowledge than me can figure this one out.
cheers
ps;
I ended up using a named pipe and ffmpeg for the output, which currently has their own rtmp implementation that uses a ``rtmp://user:pass@url`` type of connect-uri
Of course it would be preferred to have the output directly in gstreamer.https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/30Build of tutorials fails for Android under MacOS2021-09-24T16:19:58ZJohannes HartzBuild of tutorials fails for Android under MacOSHi, I am in the process of writing an app for Android and want to use GStreamer for an audio component.
I can build Android apps with C++ support in Android Studio using NDK. I also have successfully build "Playback tutorial 1" for Mac...Hi, I am in the process of writing an app for Android and want to use GStreamer for an audio component.
I can build Android apps with C++ support in Android Studio using NDK. I also have successfully build "Playback tutorial 1" for MacOS from the Gstreamer tutorials ("Tutorial 1" is not functional in MacOS as mentioned here: https://stackoverflow.com/questions/35137165/gstreamer-1-0-video-from-tutorials-is-not-playing-on-macos).
Trying to build the tutorials for Android on MacOS using GStream 1.14.4 fails (in command line and Android Studio):
...
GStreamer : [GEN] => gst-build-arm64-v8a/gstreamer_android.c
GStreamer : [COMPILE] => gst-build-arm64-v8a/gstreamer_android.c
clang: error: argument unused during compilation: '--gcc-toolchain=/Users/johannes/Library/Android/sdk/ndk-bundle/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64' [-Werror,-Wunused-command-line-argument]
make: *** [gst-build-arm64-v8a/gstreamer_android.o] Error
This can be fixed modifying the respective gstreamer-1.0.mk:
`$(GSTREAMER_ANDROID_O): PRIV_CC_CMD := $(TARGET_CC) --sysroot=$(SYSROOT_GST_INC) $(SYSROOT_ARCH_INC_ARG) $(TARGET_CFLAGS) \
-c $(GSTREAMER_ANDROID_C) -Wall -Werror -o $(GSTREAMER_ANDROID_O) $(GSTREAMER_ANDROID_CFLAGS)`
needs to be replaced with
`(GSTREAMER_ANDROID_O): PRIV_CC_CMD := $(TARGET_CC) --sysroot=$(SYSROOT_GST_INC) $(SYSROOT_ARCH_INC_ARG) $(TARGET_CFLAGS) \
-c $(GSTREAMER_ANDROID_C) -Wall -o $(GSTREAMER_ANDROID_O) $(GSTREAMER_ANDROID_CFLAGS)`
(removing -Werror).
Then another error occurs due to missing the Gold linker (not standard in MacOS):
...
GStreamer : [GEN] => gst-build-arm64-v8a/gstreamer_android.c
GStreamer : [COMPILE] => gst-build-arm64-v8a/gstreamer_android.c
GStreamer : [LINK] => gst-build-arm64-v8a/libgstreamer_android.so
clang: error: invalid linker name in argument '-fuse-ld=gold'
make: *** [buildsharedlibrary_arm64-v8a] Error 1
I tried the default ld linker to fix this:
`GSTREAMER_LD := -fuse-ld=ld$(EXE_SUFFIX) -Wl,-soname,lib$(GSTREAMER_ANDROID_MODULE_NAME).so`
instead of
`GSTREAMER_LD := -fuse-ld=gold$(EXE_SUFFIX) -Wl,-soname,lib$(GSTREAMER_ANDROID_MODULE_NAME).so`
Which leads to the following error:
...
GStreamer : [GEN] => gst-build-arm64-v8a/gstreamer_android.c
GStreamer : [COMPILE] => gst-build-arm64-v8a/gstreamer_android.c
GStreamer : [LINK] => gst-build-arm64-v8a/libgstreamer_android.so
clang: warning: argument unused during compilation: '--gcc-toolchain=/Users/johannes/Library/Android/sdk/ndk-bundle/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64' [-Wunused-command-line-argument]
ld: warning: directory not found for option '-L/home/nirbheek/projects/repositories/gst/cerbero.git/build/dist/android_universal/arm64/lib'
ld: warning: directory not found for option '-L/home/nirbheek/projects/repositories/gst/cerbero.git/build/android-ndk-16/platforms/android-21/arch-arm64/usr/lib'
ld: unknown option: --whole-archive
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [buildsharedlibrary_arm64-v8a] Error 1
I fiddled with the linker options for a while (e.g. replacing --whole-archive with -all_load) but ran into lots of new errors. What can I do here to advance?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/542audiodecoder / videodecoder: Don't unconditionally post an error message if n...2021-09-24T13:24:47ZSebastian Drögeaudiodecoder / videodecoder: Don't unconditionally post an error message if no frames were decoded before end-of-streamThis can also happen correctly in dynamic pipeline when switching between streams very fast, and switching just after the caps event and before the first decoded buffer can be output.
It should probably get at least a property instead o...This can also happen correctly in dynamic pipeline when switching between streams very fast, and switching just after the caps event and before the first decoded buffer can be output.
It should probably get at least a property instead of always posting an error message, but maybe someone has an idea how to do some meaningful autodetection here if there was an error or not?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/539test_video_color_convert is missing a visual verification2021-09-24T13:24:47ZNicolas Dufresnetest_video_color_convert is missing a visual verificationThis test runs through all possible conversion combination, but does not validate the output. My suggestion is that we use the pack function to set some pixel values, and use unpack to read back some pixels and compare. Some helper are n...This test runs through all possible conversion combination, but does not validate the output. My suggestion is that we use the pack function to set some pixel values, and use unpack to read back some pixels and compare. Some helper are needed as pack/unpack can be in 4 different formats, ARGB, ARGB64, AYUV and AYUV64.
This is related to !86https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/349bin: Race condition between gst_bin_remove() and gst_bin_element_set_state() ...2021-09-24T11:09:18ZSebastian Drögebin: Race condition between gst_bin_remove() and gst_bin_element_set_state() (and gst_element_set_locked_state())We need to take the state lock here to ensure that we're not currently just before setting the state of this child element. Otherwise it can happen that we removed the element here and e.g. set it to NULL state, and shortly afterwards ha...We need to take the state lock here to ensure that we're not currently just before setting the state of this child element. Otherwise it can happen that we removed the element here and e.g. set it to NULL state, and shortly afterwards have another thread set it to a higher state again as part of a state change for the whole bin.
When adding an element to the bin this is not needed as we require callers to always ensure after adding to the bin that the new element is set to the correct state.
This is reliably reproducible in one application I have here after 14 to 20 hours.
https://gitlab.freedesktop.org/gstreamer/gstreamer/merge_requests/65 tried solving this but it causes regressions as we can't simply take the state lock from `gst_bin_remove()`: it will then often be taken after the stream lock, but proper shutdown of elements requires the other way around so we get a deadlock due to locking order.
I believe this is unfixable in 1.0 and for 2.0 we should think about moving all the state handling into a dedicated thread and have it all controlled by the top-level pipeline.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/533glimagesink: various refcount issues / segfaults when run with validate2021-09-24T13:24:45ZMathieu Duponchelleglimagesink: various refcount issues / segfaults when run with validate`gst-validate-1.0 videotestsrc num-buffers=100 ! glimagesink --set-scenario change_state_intensive`
on my machine, I often see crashes and / or critical errors such as:
```
0:00:00.141768222 6227 0x975540 ERROR val...`gst-validate-1.0 videotestsrc num-buffers=100 ! glimagesink --set-scenario change_state_intensive`
on my machine, I often see crashes and / or critical errors such as:
```
0:00:00.141768222 6227 0x975540 ERROR validate gst-validate-reporter.c:195:gst_validate_report_valist: <pipeline0> 2080 (critical) : g-log: We got a g_log critical issue : g_object_ref: assertion 'G_IS_OBJECT (object)' failed
0:00:00.142093128 6227 0x975540 ERROR validate gst-validate-reporter.c:195:gst_validate_report_valist: <pipeline0> 2080 (critical) : g-log: We got a g_log critical issue : gst_gl_window_resize: assertion 'GST_IS_GL_WINDOW (window)' failed
0:00:00.142355370 6227 0x975540 ERROR validate gst-validate-reporter.c:195:gst_validate_report_valist: <pipeline0> 2080 (critical) : g-log: We got a g_log critical issue : gst_gl_window_draw: assertion 'GST_IS_GL_WINDOW (window)' failed
0:00:00.142611845 6227 0x975540 ERROR validate gst-validate-reporter.c:195:gst_validate_report_valist: <pipeline0> 2080 (critical) : g-log: We got a g_log critical issue : gst_object_unref: assertion '((GObject *) object)->ref_count > 0' failed
```
stacktrace on SIGSEGV:
```
<Caught SIGNAL: SIGSEGV>
#0 0x00007fa5acbb0df9 in syscall () at /lib64/libc.so.6
#1 0x00007fa5ad723333 in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007fa59a5a08b4 in gst_gl_window_default_send_message (window=0x988a20, callback=<optimized out>, data=<optimized out>)
#3 0x00007fa59a58270d in gst_gl_context_thread_add (context=<optimized out>, func=func@entry=0x7fa59a578f40 <gst_gl_base_filter_gl_stop>, data=data@entry=0x9801a0) at ../subprojects/gst-plugins-base/gst-libs/gst/gl/gstglcontext.c:1579
#4 0x00007fa59a578f1f in gst_gl_base_filter_reset (filter=0x9801a0)
#5 0x00007fa59a578f1f in gst_gl_base_filter_stop (bt=<optimized out>)
#6 0x00007fa5aaab3d94 in gst_base_transform_activate (trans=trans@entry=0x9801a0, active=active@entry=0)
#7 0x00007fa5aaab3e85 in gst_base_transform_sink_activate_mode (pad=<optimized out>, parent=0x9801a0, mode=<optimized out>, active=0)
#8 0x00007fa5adcf9cdb in gst_validate_pad_monitor_activatemode_func (pad=0x9522a0, parent=0x9801a0, mode=GST_PAD_MODE_PUSH, active=0)
#9 0x00007fa5ada2aab6 in activate_mode_internal (pad=pad@entry=0x9522a0, parent=parent@entry=0x9801a0, mode=mode@entry=GST_PAD_MODE_PUSH, active=active@entry=0) at ../subprojects/gstreamer/gst/gstpad.c:1220
#10 0x00007fa5ada2b515 in gst_pad_set_active (pad=pad@entry=0x9522a0, active=0)
#11 0x00007fa5ada0787d in activate_pads (vpad=<optimized out>, ret=0x7ffd54c73d90, active=0x7ffd54c73dec) at ../subprojects/gstreamer/gst/gstelement.c:3036
#12 0x00007fa5ada1b36c in gst_iterator_fold (it=it@entry=0x91c5c0, func=func@entry=0x7fa5ada07860 <activate_pads>, ret=ret@entry=0x7ffd54c73d90, user_data=user_data@entry=0x7ffd54c73dec) at ../subprojects/gstreamer/gst/gstiterator.c:617
#13 0x00007fa5ada08216 in iterator_activate_fold_with_resync (iter=iter@entry=0x91c5c0, user_data=user_data@entry=0x7ffd54c73dec, func=0x7fa5ada07860 <activate_pads>) at ../subprojects/gstreamer/gst/gstelement.c:3060
#14 0x00007fa5ada0a22e in gst_element_pads_activate (element=element@entry=0x9801a0, active=<optimized out>, active@entry=0)
#15 0x00007fa5ada0a481 in gst_element_change_state_func (element=0x9801a0, transition=GST_STATE_CHANGE_PAUSED_TO_READY)
#16 0x00007fa59a578d6b in gst_gl_base_filter_change_state (element=0x9801a0, transition=GST_STATE_CHANGE_PAUSED_TO_READY)
#17 0x00007fa5ada0c5de in gst_element_change_state (element=element@entry=0x9801a0, transition=transition@entry=GST_STATE_CHANGE_PAUSED_TO_READY)
#18 0x00007fa5ada0ccfe in gst_element_set_state_func (element=0x9801a0, state=GST_STATE_READY) at ../subprojects/gstreamer/gst/gstelement.c:2902
#19 0x00007fa5ad9eb817 in gst_bin_element_set_state (next=GST_STATE_READY, current=GST_STATE_PAUSED, start_time=0, base_time=8034553076535, element=0x9801a0, bin=0x978020) at ../subprojects/gstreamer/gst/gstbin.c:2601
#20 0x00007fa5ad9eb817 in gst_bin_change_state_func (element=0x978020, transition=GST_STATE_CHANGE_PAUSED_TO_READY)
#21 0x00007fa5ada0c5de in gst_element_change_state (element=element@entry=0x978020, transition=transition@entry=GST_STATE_CHANGE_PAUSED_TO_READY)
#22 0x00007fa5ada0ccfe in gst_element_set_state_func (element=0x978020, state=GST_STATE_READY) at ../subprojects/gstreamer/gst/gstelement.c:2902
#23 0x00007fa5ad9eb817 in gst_bin_element_set_state (next=GST_STATE_READY, current=GST_STATE_PAUSED, start_time=0, base_time=8034553076535, element=0x978020, bin=0x988400) at ../subprojects/gstreamer/gst/gstbin.c:2601
#24 0x00007fa5ad9eb817 in gst_bin_change_state_func (element=0x988400, transition=GST_STATE_CHANGE_PAUSED_TO_READY)
#25 0x00007fa5ada0c5de in gst_element_change_state (element=element@entry=0x988400, transition=GST_STATE_CHANGE_PAUSED_TO_READY)
#26 0x00007fa5ada0cfde in gst_element_continue_state (element=element@entry=0x988400, ret=ret@entry=GST_STATE_CHANGE_SUCCESS)
#27 0x00007fa5ada0c7c5 in gst_element_change_state (element=element@entry=0x988400, transition=transition@entry=GST_STATE_CHANGE_PLAYING_TO_PAUSED)
#28 0x00007fa5ada0ccfe in gst_element_set_state_func (element=0x988400, state=GST_STATE_NULL) at ../subprojects/gstreamer/gst/gstelement.c:2902
#29 0x00007fa5add06006 in _execute_set_state (scenario=0x9aa100, action=<optimized out>)
#30 0x00007fa5add09c89 in gst_validate_execute_action (action_type=0x94eb70, action=action@entry=0x9a71b0)
#31 0x00007fa5add0a8df in _execute_sub_action_action (action=action@entry=0x9a71b0)
#32 0x00007fa5add0e036 in _action_set_done (action=0x9a71b0)
#33 0x00007fa5ad6dd8e5 in g_main_context_invoke_full ()
#34 0x00007fa5add0a936 in gst_validate_action_set_done (action=<optimized out>)
#35 0x00007fa5add0b4d2 in message_cb (bus=<optimized out>, message=0x9d2ea0, scenario=0x9aa100)
#36 0x00007fa5aba4c03e in ffi_call_unix64 () at /lib64/libffi.so.6
#37 0x00007fa5aba4b9ff in ffi_call () at /lib64/libffi.so.6
#38 0x00007fa5ad44e5a5 in g_cclosure_marshal_generic ()
#39 0x00007fa5ad44dadd in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#40 0x00007fa5ad460eb3 in signal_emit_unlocked_R ()
#41 0x00007fa5ad469fda in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#42 0x00007fa5ad46a5d3 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#43 0x00007fa5ad9f3e94 in gst_bus_async_signal_func (bus=0x891bf0, message=0x9d2ea0, data=<optimized out>) at ../subprojects/gstreamer/gst/gstbus.c:1251
#44 0x00007fa5ad9f4cad in gst_bus_source_dispatch (source=0x9bdfd0, callback=0x7fa5ad9f3e40 <gst_bus_async_signal_func>, user_data=0x0)
#45 0x00007fa5ad6dc7cd in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#46 0x00007fa5ad6dcb98 in g_main_context_iterate.isra ()
#47 0x00007fa5ad6dcec2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#48 0x0000000000402cc0 in main (argc=<optimized out>, argv=<optimized out>)
Please run 'gdb <process-name> 6227' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
```https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/128Totem's properties helper crashes when VAAPI plugins are loaded2021-09-24T12:23:16ZBastien NoceraTotem's properties helper crashes when VAAPI plugins are loadedBacktrace:
```
#0 0x00007f20969f7f00 in ?? ()
#1 0x00007f209edd73b6 in pipe_resource_reference (tex=0x0, ptr=0x7f20b818bcb0) at ./util/u_inlines.h:144
#2 vl_compositor_cleanup_state (s=s@entry=0x7f20b818bc98) at vl/vl_compositor.c:146...Backtrace:
```
#0 0x00007f20969f7f00 in ?? ()
#1 0x00007f209edd73b6 in pipe_resource_reference (tex=0x0, ptr=0x7f20b818bcb0) at ./util/u_inlines.h:144
#2 vl_compositor_cleanup_state (s=s@entry=0x7f20b818bc98) at vl/vl_compositor.c:1466
#3 0x00007f209edc49b9 in vlVaTerminate (ctx=<optimized out>) at context.c:387
#4 0x00007f20ac599925 in vaTerminate (dpy=0x7f20b81983c0) at va.c:751
#5 0x00007f20ad2b9b66 in gst_vaapi_display_destroy (display=0x55f36a09c890) at gstvaapidisplay.c:835
#6 gst_vaapi_display_finalize (object=0x55f36a09c890) at gstvaapidisplay.c:1063
#7 0x00007f20f0834fb9 in g_object_unref (_object=0x55f36a09c890) at gobject.c:3340
#8 0x00007f20c5f748b9 in gst_object_unref (object=<optimized out>) at gstobject.c:266
#9 0x00007f20c5f74b20 in gst_object_replace (oldobj=oldobj@entry=0x55f36a1b7b88, newobj=newobj@entry=0x0) at gstobject.c:343
#10 0x00007f20ad2babc9 in gst_vaapi_display_replace (old_display_ptr=old_display_ptr@entry=0x55f36a1b7b88, new_display=new_display@entry=0x0) at gstvaapidisplay.c:1227
---Type <return> to continue, or q <return> to quit---
#11 0x00007f20ad30fa7e in gst_vaapi_display_egl_finalize (object=0x55f36a1b7b20) at gstvaapidisplay_egl.c:305
```
Full backtrace and original report at https://gitlab.gnome.org/GNOME/totem/issues/281