GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-08-17T20:34:38Zhttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/336Question: is python 3.9 supported ?2021-08-17T20:34:38ZAaron BoxerQuestion: is python 3.9 supported ?I am seeing the following error :
```
Recipe 'zlib' failed at the build step 'configure'
Traceback (most recent call last):
File "/home/src/cerbero/cerbero/build/oven.py", line 463, in _cook_recipe_step
await ret
File "/home/src...I am seeing the following error :
```
Recipe 'zlib' failed at the build step 'configure'
Traceback (most recent call last):
File "/home/src/cerbero/cerbero/build/oven.py", line 463, in _cook_recipe_step
await ret
File "/home/src/cerbero/cerbero/build/recipe.py", line 102, in async_wrapped
await stepfunc()
File "/home/src/cerbero/cerbero/build/build.py", line 63, in async_call
res = await func(*args)
File "/home/src/cerbero/cerbero/build/build.py", line 1100, in configure
await shell.async_call(meson_cmd, self.meson_dir, logfile=self.logfile, env=self.env)
File "/home/src/cerbero/cerbero/utils/shell.py", line 242, in async_call
proc = await asyncio.create_subprocess_exec(*cmd, cwd=cmd_dir,
File "/usr/lib/python3.9/asyncio/subprocess.py", line 236, in create_subprocess_exec
transport, protocol = await loop.subprocess_exec(
File "/usr/lib/python3.9/asyncio/base_events.py", line 1661, in subprocess_exec
transport = await self._make_subprocess_transport(
File "/usr/lib/python3.9/asyncio/unix_events.py", line 197, in _make_subprocess_transport
transp = _UnixSubprocessTransport(self, protocol, args, shell,
File "/usr/lib/python3.9/asyncio/base_subprocess.py", line 36, in __init__
self._start(args=args, shell=shell, stdin=stdin, stdout=stdout,
File "/usr/lib/python3.9/asyncio/unix_events.py", line 789, in _start
self._proc = subprocess.Popen(
File "/usr/lib/python3.9/subprocess.py", line 951, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.9/subprocess.py", line 1821, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: '/home/src/cerbero/build/build-tools/bin/meson'
Select an action to proceed:
```
```https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/144Media pipeline for one of the rtsp streams is failed to prepare with "wait_pr...2021-09-24T11:03:29ZIohannes FolbortMedia pipeline for one of the rtsp streams is failed to prepare with "wait_preroll: failed to preroll pipeline"I have a server which listens for incoming rtp streams and provides rtsp media links for this streams.
For some reason i am experiencing the issue with connection to one of the media links. When connectiong to media rtsp server is not ab...I have a server which listens for incoming rtp streams and provides rtsp media links for this streams.
For some reason i am experiencing the issue with connection to one of the media links. When connectiong to media rtsp server is not able to preroll the pipeline within the timeout and next error is seen
```
bad_log:
...
Aug 17 09:35:52 SV3220NA303 rtp-to-rtsp-server[830]: 0:29:40.275167696 830 0xa9c680 WARN rtspmedia rtsp-media.c:3000:wait_preroll: failed to preroll pipeline
Aug 17 09:35:52 SV3220NA303 rtp-to-rtsp-server[830]: 0:29:40.275183383 830 0xa9c680 WARN rtspmedia rtsp-media.c:3304:gst_rtsp_media_prepare: failed to preroll pipeline
Aug 17 09:35:52 SV3220NA303 rtp-to-rtsp-server[830]: 0:29:40.275942045 830 0xa9c680 ERROR rtspclient rtsp-client.c:1044:find_media: client 0x7f5a7c02ee40: can't prepare media
Aug 17 09:35:52 SV3220NA303 rtp-to-rtsp-server[830]: 0:29:40.276092339 830 0xa9c680 ERROR rtspclient rtsp-client.c:2955:handle_describe_request: client 0x7f5a7c02ee40: no media
...
```
Logs for good media link and bad media link are attached.
[bad_log](/uploads/b44b4e35d013fb5698eb7fcdd3eded94/bad_log)
[good_log](/uploads/c62f67cb357e40f33e322cc120c13aef/good_log)
The major difference between the pipeline construction is that in bad case caps creation event for `video/x-h264` is not arrived, thus the media pipeline is not created within a timeout.
In case of valid pipeline event is received and media pipeline is created sucessfully:
```
good_log:
...
0:13:59.694671471 2042 0x7f68fc004000 INFO GST_EVENT gstevent.c:814:gst_event_new_caps: creating caps event video/x-h264, stream-format=(string)avc, alignment=(string)au, codec_data=(buffer)01424032ffe1001167424032f40a0fd0800001f400003a984201000568ce01af20, level=(string)5, profile=(string)constrained-baseline
0:13:59.694783493 2042 0x7f68fc004000 INFO GST_EVENT gstevent.c:814:gst_event_new_caps: creating caps event application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)424032, sprop-parameter-sets=(string)"Z0JAMvQKD9CAAAH0AAA6mEI\=\,aM4BryA\=", payload=(int)96, ssrc=(uint)481514705, timestamp-offset=(uint)1030785127, seqnum-offset=(uint)21035
...
```
Can someone explain what can be a reason for this behavior? Why does media factory is able to create media for one link but is not able to create media for another one?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1644Nearly impossible to negotiate H.264 browser independently due to a flaw in w...2021-08-18T08:46:24ZNeil YoungNearly impossible to negotiate H.264 browser independently due to a flaw in webrtcbinI already started several discussions w/o coming to a satisfying solution, e.g. here https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1641
The symptom is: If webrtcbin is supposed to answer to an incoming offer containi...I already started several discussions w/o coming to a satisfying solution, e.g. here https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1641
The symptom is: If webrtcbin is supposed to answer to an incoming offer containing H.264 codecs it fails in almost all cases. No video is sent to remote. The other way around works.
The reason is, that the SDP comparison/negotiation is way too strict.
**Problem 1**
It is for instance not possible to have an SDP offer with payload type 106 w/o explicitly specifying this payload type while opening the pipeline, e.g. like so:
```
PIPELINE_TEST_H264 = '''
webrtcbin name=webrtcbin bundle-policy=max-bundle stun-server=stun://stun.l.google.com:19302
videotestsrc is-live=true pattern=smpte ! video/x-raw,width=640,height=480 ! videoconvert ! x264enc ! rtph264pay config-interval=1 !
application/x-rtp,media=video,encoding-name=H264,payload=106 ! webrtcbin.
```
If the payload=106 entry is missing, it will not work.
**Problem 2**
If the `profile-level-id` of the OFFERER is not exactly a match with the profile-id returned after the local pipeline is opened it will not work.
For instance this trace shows, that the payload type 106 and profile-level-id 42c01e is returned after opening the a.m. pipeline
```0:00:02.139386647 2346 0xb284bb20 DEBUG webrtcbin gstwebrtcbin.c:279:gst_webrtcbin_sink_event:<webrtcbin> On <webrtcbin:sink_0> checking negotiation? 1, caps application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)42c01e, sprop-parameter-sets=(string)"Z0LAHtkAoD2wFqDAwNSgAAADACAAAAeR4sXJ\,aMuMsg\=\=", payload=(int)106, ssrc=(uint)247990408, timestamp-offset=(uint)3232755765, seqnum-offset=(uint)10019, a-framerate=(string)30```
Not only that the external H.264 codec needs to carry exactly the same 106 as payload type, I additionally need to munge the incoming SDP and change all constrained baseline profile-level-ids so that it matches my local profile-level-id, otherwise the video will not be sent:
Hack:
```
incoming_sdp = incoming_sdp.replace("42e01f", "42c01e") # test video
```
And this even though the 42c01e is a subset of the 42e01f, IMHO, so it MUST be accepted.
It is nearly impossible to have a solution with reasonable efforts to have this replacement done for each camera/source, since every input has it's own idea of a profile-level-id... I'm having 3 cameras and three profile-level-ids...
**Problem 3**
In addition it will not work if the OFFERER sends VP8 or VP9 codecs along side the H.264 codec definitions. This in turn requires to limit the offered codecs on the browser side to H.264 only, best just one profile.
The required functionality of `setCodecPreferences`(https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpTransceiver/setCodecPreferences) seems to be only experimental (even though supported by Chrome and Safari) and lacks at least `getCapabilities` support in Firefox (https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpSender/getCapabilities), so there is no support yet in all browsers for this kind of management.
All these reasons make it currently impossible to have an application using webrtcbin being able to ANSWER a valid incoming OFFER containing valid H.264 caps and agree on H.264 finally. As said: Working with an app just OFFERING H.264 works with all browsers.
Unless I have overseen something I would consider this as an issue.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/161cargo_wrapper.py doesn't support --verbose2023-05-31T13:41:29ZJan Beichcargo_wrapper.py doesn't support --verboseTo facilitate debugging remote builds (e.g., on non-x86 archs downstream) it'd be nice if `--verbose` from Meson was propagated to cargo-c.
```
$ meson setup _build
$ meson compile -v -C _build
```
Related:<br/>
https://github.com/free...To facilitate debugging remote builds (e.g., on non-x86 archs downstream) it'd be nice if `--verbose` from Meson was propagated to cargo-c.
```
$ meson setup _build
$ meson compile -v -C _build
```
Related:<br/>
https://github.com/freebsd/freebsd-ports/commit/30a00f2227a3<br/>
https://github.com/freebsd/freebsd-ports/commit/7bec7b192cda<br/>https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1642Switch to libfreeaptx2022-02-16T04:55:46ZLaurent BigonvilleSwitch to libfreeaptxHello,
So there is apparently a fork of libopenaptx before the license changed that has been created. The fork is called [libfreeaptx](https://github.com/iamthehorker/libfreeaptx). pipewire already switched to that fork https://gitlab.f...Hello,
So there is apparently a fork of libopenaptx before the license changed that has been created. The fork is called [libfreeaptx](https://github.com/iamthehorker/libfreeaptx). pipewire already switched to that fork https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/843, so gstreamer should maybe do the same?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/724Pad activation failure related to typefind and ghost pads2021-09-24T11:08:16ZSebastian DrögePad activation failure related to typefind and ghost padsForwarded from https://gitlab.gnome.org/GNOME/gtk/-/issues/4062
[app.c](/uploads/c6f1d904524d4d5b6d2062477ca9a816/app.c) reproduces the issue. Just start it with `./app /path/to/some/media/file`.
It fails with
```
(app:183943): GStrea...Forwarded from https://gitlab.gnome.org/GNOME/gtk/-/issues/4062
[app.c](/uploads/c6f1d904524d4d5b6d2062477ca9a816/app.c) reproduces the issue. Just start it with `./app /path/to/some/media/file`.
It fails with
```
(app:183943): GStreamer-CRITICAL **: 18:23:22.243: getrange on pad source:src but it was not activated in pull mode
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: Internal data stream error.
Additional debug info:
../plugins/elements/gsttypefindelement.c(1232): gst_type_find_element_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind:
streaming stopped, reason error (-5)
(app:183943): GStreamer-CRITICAL **: 18:23:22.243: chain on pad decodebin0:sink but it was not in push mode
```
Just using a `giostreamsrc` in front of `decodebin` OTOH works fine (see commented out code).https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/915pulsesink: Cannot play µLaw audio with pipewire-pulse2021-08-17T17:02:14ZJeffrey C. Olliepulsesink: Cannot play µLaw audio with pipewire-pulseThis WAV file came from a Cisco Unity Voice Mail system and contains µLaw encoded audio in a WAV container. GStreamer is not able to play it. Plays just fine in VLC.
```
Analyzing file:///home/jcollie/Downloads/VoiceMessage.wav
Done dis...This WAV file came from a Cisco Unity Voice Mail system and contains µLaw encoded audio in a WAV container. GStreamer is not able to play it. Plays just fine in VLC.
```
Analyzing file:///home/jcollie/Downloads/VoiceMessage.wav
Done discovering file:///home/jcollie/Downloads/VoiceMessage.wav
Properties:
Duration: 0:00:18.620000000
Seekable: yes
Live: no
Tags:
container format: WAV
bitrate: 64000
audio codec: Mu-law audio
audio: audio/x-wav
Tags:
None
Codec:
audio/x-wav
Stream ID: (null)
Language: <unknown>
Channels: 0 ()
Sample rate: 0
Depth: 0
Bitrate: 0
Max bitrate: 0
audio: audio/x-mulaw, rate=(int)8000, channels=(int)1
Tags:
container format: WAV
bitrate: 64000
audio codec: Mu-law audio
Codec:
audio/x-mulaw, rate=(int)8000, channels=(int)1
Stream ID: 83db2453a79223e5959c7c546ac3dd99
Language: <unknown>
Channels: 1 (unknown layout)
Sample rate: 8000
Depth: 16
Bitrate: 64000
Max bitrate: 0
```
![VoiceMessage](/uploads/1d4cabe668443b0dab3679a3b4750ba1/VoiceMessage.wav)https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/353GstTracerImpl: support MiniObject hooks2021-09-19T13:29:26ZSimonas KazlauskasGstTracerImpl: support MiniObject hooksThese are absent from the initial implementation because we have no bindings to `MiniObject`. `grep` for `TODO(#353)` for the location in source code.These are absent from the initial implementation because we have no bindings to `MiniObject`. `grep` for `TODO(#353)` for the location in source code.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1641H.264 offer from Chrome crashes webrtcbin 18.42021-08-17T10:00:35ZNeil YoungH.264 offer from Chrome crashes webrtcbin 18.4This is the situation:
I'm running a GST 18.4 python app. This app communicates with a Chrome JS app on the same network.
The app is able to send and receive VP8, but I'm having a problem with H.264, in case the Python app (webrtcbin b...This is the situation:
I'm running a GST 18.4 python app. This app communicates with a Chrome JS app on the same network.
The app is able to send and receive VP8, but I'm having a problem with H.264, in case the Python app (webrtcbin based) is the ANSWERER. The problem is not there if the Python app is the OFFERER.
First the positive case: This is my H.264 pipeline in the Python app. If the Python app OFFERS, the video appears in Chrome.
```
# H.264 TEST VIDEO
PIPELINE_TEST_H264 = '''
webrtcbin name=webrtcbin bundle-policy=max-bundle stun-server=stun://stun.l.google.com:19302
videotestsrc is-live=true pattern=smpte ! video/x-raw,width=1280,height=720 ! videoconvert ! x264enc ! rtph264pay config-interval=1 ! webrtcbin.
'''
```
The SDP handshake is like so:
The OFFER sent:
```
v=0
o=- 143230668495837560 0 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle
a=group:BUNDLE video0
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:8OgtMvs3Zdn04lGPl61MEeQGtuq2XNS+
a=ice-pwd:GbtIZHC7CWPkgzNrnH7mWEtWNpaeWL5n
a=rtcp-mux
a=rtcp-rsize
a=sendonly
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack pli
a=framerate:30
a=fmtp:96 packetization-mode=1;profile-level-id=42c01f;sprop-parameter-sets=Z0LAH9kAUAW7AWoCAgKAAAADAIAAAB5HjBkk,aMuMsg==
a=ssrc:2817782937 msid:user2521903457@host-548ae76e webrtctransceiver0
a=ssrc:2817782937 cname:user2521903457@host-548ae76e
a=mid:video0
a=fingerprint:sha-256 1B:99:58:8C:F3:33:28:60:02:E6:11:66:74:B7:84:B4:D9:06:32:12:13:23:F0:E9:23:68:9D:C3:CC:79:85:C5
```
The ANSWER received (video flows):
```
v=0
o=- 6562431427409268738 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video0
a=msid-semantic: WMS
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:OoGw
a=ice-pwd:egHkzRQOlN6ADWLnaltQ6AkA
a=ice-options:trickle
a=fingerprint:sha-256 20:C2:D3:AA:37:07:31:87:FA:71:D4:20:CF:50:ED:07:EA:C8:B8:1D:EA:02:73:9C:7C:AC:24:5C:F3:C9:DA:60
a=setup:active
a=mid:video0
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack pli
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
```
Works. Video flows.
But now the other way around: The video does not appear in Chrome, if Chrome is the OFFERER. The ANSWER confirms that with "a=inactive".
The OFFER generated by Chrome:
```
v=0
o=- 6799643414674800834 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=extmap-allow-mixed
a=msid-semantic: WMS
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 122 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116 37
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Tyef
a=ice-pwd:tct8Z2AfUb1yNAT/aWDfj2OI
a=ice-options:trickle
a=fingerprint:sha-256 F6:01:90:DF:E5:67:4E:B0:9F:DF:14:1A:3B:08:2F:E8:12:ED:CC:35:EB:4D:E2:22:AF:1F:18:7C:EB:37:D7:41
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:122 VP9/90000
a=rtcp-fb:122 goog-remb
a=rtcp-fb:122 transport-cc
a=rtcp-fb:122 ccm fir
a=rtcp-fb:122 nack
a=rtcp-fb:122 nack pli
a=fmtp:122 profile-id=1
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=102
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=127
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:35 AV1X/90000
a=rtcp-fb:35 goog-remb
a=rtcp-fb:35 transport-cc
a=rtcp-fb:35 ccm fir
a=rtcp-fb:35 nack
a=rtcp-fb:35 nack pli
a=rtpmap:36 rtx/90000
a=fmtp:36 apt=35
a=rtpmap:124 H264/90000
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=124
a=rtpmap:123 H264/90000
a=rtcp-fb:123 goog-remb
a=rtcp-fb:123 transport-cc
a=rtcp-fb:123 ccm fir
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032
a=rtpmap:118 rtx/90000
a=fmtp:118 apt=123
a=rtpmap:114 red/90000
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=114
a=rtpmap:116 ulpfec/90000
a=rtpmap:37 flexfec-03/90000
a=rtcp-fb:37 goog-remb
a=rtcp-fb:37 transport-cc
a=fmtp:37 repair-window=10000000
```
The ANSWER generated by webrtcbin:
```
v=0
o=- 6799643414674800834 2 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE 0
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=ice-ufrag:ej11/cl3FCkkhNmNliiql1R5MX5MFn/g
a=ice-pwd:SgutRYS/iWj9l8WvWvXGzrohbIiTLK+f
a=mid:0
a=rtcp-mux
a=setup:active
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 ccm fir
a=inactive
a=fingerprint:sha-256 BD:5C:65:0E:D3:75:67:8B:80:71:57:D5:08:14:70:1A:BB:4F:51:F8:54:53:80:17:8C:3E:44:DB:EA:E5:04:06
```
I then tried limit the codecs offered by Chrome to one of the seemingly matching H.264 formats by `setCodecPreferences``
```
videoTransceiver.setCodecPreferences([
{ clockRate: 90000, mimeType: "video/H264", sdpFmtpLine: "level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f" }
])
```
After this the OFFER from Chrome looks like this:
```
v=0
o=- 1241534504099527837 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=extmap-allow-mixed
a=msid-semantic: WMS oQrYP0RdXW3OITfGDlPmkOEuvWzFikm0VwlO
m=video 9 UDP/TLS/RTP/SAVPF 106
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:hO7n
a=ice-pwd:cZ0ULb11MCZp/kiAj1Pq4z7j
a=ice-options:trickle
a=fingerprint:sha-256 9F:2B:04:A2:8C:6F:34:A6:CB:19:20:C5:2E:91:A8:94:94:F8:29:CF:EC:ED:18:DF:19:B8:79:F0:6A:E4:4A:64
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 urn:3gpp:video-orientation
a=extmap:4 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:oQrYP0RdXW3OITfGDlPmkOEuvWzFikm0VwlO a6613978-f98b-4fee-87b8-42f0ea143d1b
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:106 H264/90000
a=rtcp-fb:106 goog-remb
a=rtcp-fb:106 transport-cc
a=rtcp-fb:106 ccm fir
a=rtcp-fb:106 nack
a=rtcp-fb:106 nack pli
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=ssrc:2404631310 cname:g3pckgfqHMLdr/Ev
a=ssrc:2404631310 msid:oQrYP0RdXW3OITfGDlPmkOEuvWzFikm0VwlO a6613978-f98b-4fee-87b8-42f0ea143d1b
a=ssrc:2404631310 mslabel:oQrYP0RdXW3OITfGDlPmkOEuvWzFikm0VwlO
a=ssrc:2404631310 label:a6613978-f98b-4fee-87b8-42f0ea143d1b
```
...and the ANSWER from the Python app:
```
v=0
o=- 4514418055778671968 2 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE 0
m=video 9 UDP/TLS/RTP/SAVPF 106
c=IN IP4 0.0.0.0
a=ice-ufrag:dJWSQZTBciCBx2fEbfUoj+CfUl+MBBlF
a=ice-pwd:LI/7knZzqS/yUtOZDLU6P74mQDW/aCu3
a=mid:0
a=rtcp-mux
a=setup:active
a=rtpmap:106 H264/90000
a=rtcp-fb:106 nack pli
a=rtcp-fb:106 ccm fir
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=recvonly
a=fingerprint:sha-256 24:63:1E:23:6E:B0:A3:F3:1E:DA:C6:0E:7F:4F:DC:74:98:FE:F4:8D:AE:84:02:44:F1:16:F1:3D:C4:68:2B:25
```
That looks promising, because there seems to be an agreement on the format. What concerns me is the `a=recvonly` and in fact, the screen remains black on the Chrome side. And in case the Chrome app sends video as announced, the Python app crashes with sigsev after "on_incoming_pad_added".
I don't know if it means something: If I run the Python app as OFFERER this trace appears:
`:00:03.684006943 16546 0xb284cf20 DEBUG webrtcbin gstwebrtcbin.c:279:gst_webrtcbin_sink_event:<webrtcbin> On <webrtcbin:sink_0> checking negotiation? 1, caps application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)42c01f, sprop-parameter-sets=(string)"Z0LAH9kAUAW7AWoCAgKAAAADAIAAAB5HjBkk\,aMuMsg\=\=", payload=(int)96, seqnum-offset=(uint)20552, timestamp-offset=(uint)1267346039, ssrc=(uint)1634604066, a-framerate=(string)30`
I see a difference in the profile-level-id of **42c01f** compared to the later offered **42e01f**, but it works, maybe because the Chrome decoder does not care. But on the Chrome side 42c01f is not in the range of possible codecs:
![image](/uploads/11056930e8b6abadf8a41cf8435ed280/image.png)
I'm a bit lost here and beginning to think about NOT using GST in ANSWERING mode, at least not for H.264... There seems to be no understanding between both parties...https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/310vaapisink triggers assert in theoradec2021-09-24T12:23:31Zlaknollvaapisink triggers assert in theoradecHi all,
I'm currently working on the gstreamer backend for Qt Multimedia in Qt 6, and am having some trouble using the vaapisink on my machine. First issue follows (as I could nicely isolate it to gstreamer only):
Running:
```
gst-lau...Hi all,
I'm currently working on the gstreamer backend for Qt Multimedia in Qt 6, and am having some trouble using the vaapisink on my machine. First issue follows (as I could nicely isolate it to gstreamer only):
Running:
```
gst-launch-1.0 filesrc location=~/Videos/ogg.ogg ! oggdemux ! theoradec ! videoconvert ! vaapisink
```
triggers the following assertion:
```
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapisink0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
**
ERROR:../subprojects/gst-plugins-base/ext/theora/gsttheoradec.c:710:theora_handle_image: assertion failed: (vmeta->height == dec->info.frame_height)
Bail out! ERROR:../subprojects/gst-plugins-base/ext/theora/gsttheoradec.c:710:theora_handle_image: assertion failed: (vmeta->height == dec->info.frame_height)
Aborted
```
There are no issues when running the same pipeline using xvimagesink or glimagesink.
This happens using gstreamer-1.18.4, I couldn't try 1.19, as that has other (larger) issues when using vaapi elements on my HW.
Output of vainfo below:
```
libva info: VA-API version 1.7.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_7
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.7 (libva 2.6.0)
vainfo: Driver version: Mesa Gallium driver 21.1.0-devel for AMD Radeon RX 5700 XT (NAVI10, DRM 3.35.0, 5.4.0-80-generic, LLVM 12.0.0)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1640recvonly answer, how to change that?2021-08-14T05:41:08ZNeil Youngrecvonly answer, how to change that?I know, this has already been an issue for some others two years ago. The answer was all the time "gst rejects the offer because port 0 in m line" or so.
I'm now seemingly having the same problem, but I don't know how to solve this. The...I know, this has already been an issue for some others two years ago. The answer was all the time "gst rejects the offer because port 0 in m line" or so.
I'm now seemingly having the same problem, but I don't know how to solve this. The offerer is Chrome 92 on macOS.
I can see the 0 port in the audio m line:
`m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126`
not in the video m line.
`m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116`
The answering side is a Raspberry PI 32 bit, running a Python3 app, having GST 18.4, compiled from source. The answerer is having a pipeline providing a test video. The test video is displayed in the Chrome app, if the PI is the offerer. In this case the offer contains "sendonly", as designed.
```
PIPELINE_TEST_VP8 = '''
webrtcbin name=webrtcbin bundle-policy=max-bundle stun-server=stun://stun.l.google.com:19302
videotestsrc is-live=true pattern=ball ! videoconvert ! queue ! vp8enc deadline=1 ! queue ! rtpvp8pay !
queue ! application/x-rtp,media=video,encoding-name=VP8,payload=97 ! webrtcbin.
'''
```
The symptom is that there is no video on the offering side, streams are not provided by the answerer.
The behaviour is consistent, it also happens if I run the same python app on my MacBook.
I don't blame GST, I just would like to know, what I have to do in order get anything else except "recvonly". Do I have to munge the incoming answer, carve out the 0?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1639[GStreamer 1.18.4][WebRTC][mDNS]2023-05-16T03:48:37ZPierre-Henri LE FUR[GStreamer 1.18.4][WebRTC][mDNS]Hello,
I am not able to make webrtcbin cope with mdns anonymized ICE address candidates despite [GStreamer support since 1.18](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1523) :
![image](/uploads/98931...Hello,
I am not able to make webrtcbin cope with mdns anonymized ICE address candidates despite [GStreamer support since 1.18](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1523) :
![image](/uploads/989319dfa6db3cf9b0b2be974d2ee3e7/image.png)
but I have avahi working on my debian 11 bullseye docker system and able to resolve the candidates:
![image](/uploads/f99c3a13e4bb139acf1462538e995d93/image.png)
`hosts` line in my /etc/nsswitch.conf:
```
hosts: files mdns4_minimal [NOTFOUND=return] dns
```
Has someone any hint of what is happening?
Thank you for your time.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/914rtpjitterbuffer: rtx-next-seqnum=true causes packets discarded although they ...2024-03-20T11:35:52ZSebastian Drögertpjitterbuffer: rtx-next-seqnum=true causes packets discarded although they arrive in timeThe sequence of events is as follows
1. packet 1 arrives, expected timer for packet 2 is scheduled based on some packet rate estimate
2. expected timer triggers and goes into the "reschedule as LOST timer" case, effectively updating...The sequence of events is as follows
1. packet 1 arrives, expected timer for packet 2 is scheduled based on some packet rate estimate
2. expected timer triggers and goes into the "reschedule as LOST timer" case, effectively updating `next_in_seqnum`
3. packet 2 arrives in time (maybe the sender shortly stopped capturing, skipped a frame before its encoder, or ...) but is discarded because `next_in_seqnum` was already updated
This might've been introduced by 63c7a9ae430db991746dc4b13d26d4f7945b2dc1 but I can't really test that because the change is entangled with lots of other changes, and my application won't work with a jitterbuffer before that version because it requires newer features.
The commit itself looks correct to me though, however I think there somewhere needs to be a distinction between RTX timers based on estimations and RTX timers that are set when a packet with a higher seqnum is arriving (and we actually *know* that the missing packet should've arrived by now).
Converting expected timers to lost timers before seeing a higher seqnum is wrong in any case.
----
Independent of that we should probably consider changing the default for `rtx-next-seqnum` to `false` as the code is quite dubious, and Pexip for example disable it because it causes more problems than it solves.
CC @hgr @ndufresnehttps://gitlab.freedesktop.org/gstreamer/orc/-/issues/37ppc64le segfaults2021-09-22T06:39:13ZVítppc64le segfaultsI am observing issues with ORC on ppc64le when running active storage (part of Ruby on Rails) test suite via VIPS:
~~~
Thread 10 "worker" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc77ef0e0 (LWP 80455)]
0x00...I am observing issues with ORC on ppc64le when running active storage (part of Ruby on Rails) test suite via VIPS:
~~~
Thread 10 "worker" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc77ef0e0 (LWP 80455)]
0x00007ffff0010344 in ?? ()
#0 0x00007ffff0010344 in ?? ()
No symbol table info available.
#1 0x00007ffff0622428 in orc_executor_run () from /lib64/liborc-0.4.so.0
No symbol table info available.
#2 0x00007fffc77eaee0 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 10 "worker" received signal SIGSEGV, Segmentation fault.
0x00007ffff7d3d148 in check_stack_overflow () from /lib64/libruby.so.3.0
#0 0x00007ffff7d3d148 in check_stack_overflow () from /lib64/libruby.so.3.0
No symbol table info available.
#1 0x00007ffff7d3d278 in sigsegv () from /lib64/libruby.so.3.0
No symbol table info available.
#2 <signal handler called>
No locals.
#3 0x00007ffff0010344 in ?? ()
No symbol table info available.
#4 0x00007ffff0622428 in orc_executor_run () from /lib64/liborc-0.4.so.0
No symbol table info available.
#5 0x00007fffc77eaee0 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
~~~
Stopping GDB on `orc_executor_run`, this is the backtrace:
~~~
Thread 10 "worker" hit Breakpoint 1, 0x00007ffff05b2404 in orc_executor_run () from /lib64/liborc-0.4.so.0
#0 0x00007ffff05b2404 in orc_executor_run () from /lib64/liborc-0.4.so.0
No symbol table info available.
#1 0x00007ffff13ee108 in vips_executor_run () from /lib64/libvips.so.42
No symbol table info available.
#2 0x00007ffff11fc83c in vips_reducev_vector_gen(_VipsRegion*, void*, void*, void*, int*) () from /lib64/libvips.so.42
No symbol table info available.
#3 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#4 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#5 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#6 0x00007ffff13cb798 in vips_image_write_gen () from /lib64/libvips.so.42
No symbol table info available.
#7 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#8 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#9 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#10 0x00007ffff128e548 in vips_copy_gen.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#11 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#12 0x00007ffff13f7144 in vips_region_prepare_to_generate () from /lib64/libvips.so.42
No symbol table info available.
#13 0x00007ffff13f7454 in vips_region_prepare_to () from /lib64/libvips.so.42
No symbol table info available.
#14 0x00007ffff1299084 in vips_embed_base_gen () from /lib64/libvips.so.42
No symbol table info available.
#15 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#16 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#17 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#18 0x00007ffff11f2188 in vips_reduceh_gen(_VipsRegion*, void*, void*, void*, int*) () from /lib64/libvips.so.42
No symbol table info available.
#19 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#20 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#21 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#22 0x00007ffff13cb798 in vips_image_write_gen () from /lib64/libvips.so.42
No symbol table info available.
#23 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#24 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#25 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#26 0x00007ffff13cb798 in vips_image_write_gen () from /lib64/libvips.so.42
No symbol table info available.
#27 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#28 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#29 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#30 0x00007ffff13cb798 in vips_image_write_gen () from /lib64/libvips.so.42
No symbol table info available.
#31 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#32 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#33 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#34 0x00007ffff13cb798 in vips_image_write_gen () from /lib64/libvips.so.42
No symbol table info available.
#35 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#36 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#37 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#38 0x00007ffff128e548 in vips_copy_gen.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#39 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#40 0x00007ffff13f7144 in vips_region_prepare_to_generate () from /lib64/libvips.so.42
No symbol table info available.
#41 0x00007ffff13f7454 in vips_region_prepare_to () from /lib64/libvips.so.42
No symbol table info available.
#42 0x00007ffff13d7f78 in wbuffer_work_fn () from /lib64/libvips.so.42
No symbol table info available.
#43 0x00007ffff13ef50c in vips_thread_main_loop () from /lib64/libvips.so.42
No symbol table info available.
#44 0x00007ffff13f00a8 in vips_thread_run () from /lib64/libvips.so.42
No symbol table info available.
#45 0x00007ffff1994c30 in g_thread_proxy () from /lib64/libglib-2.0.so.0
No symbol table info available.
#46 0x00007ffff19c5448 in linux_pthread_proxy () from /lib64/libglib-2.0.so.0
No symbol table info available.
#47 0x00007ffff7839c10 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#48 0x00007ffff7a0d310 in clone () from /lib64/libc.so.6
No symbol table info available.
~~~
~~~
$ cat /etc/system-release
Fedora release 35 (Rawhide)
$ rpm -q orc
orc-0.4.31-5.fc35.ppc64le
~~~
https://bugzilla.redhat.com/show_bug.cgi?id=1917540https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/933gl: memory leak in gstglwindow_eagl.m2023-07-27T11:22:55Zezero9gl: memory leak in gstglwindow_eagl.mI'm faced with a memory leak in gst-libs/gst/gl/eagl/gstglwindow_eagl.m in iOS.
I cleaned the pipeline, but the `priv->internal_view` was not freed.
How to release the 'priv->internal_view'?
![memory_leak](/uploads/61d8393f24793b245887...I'm faced with a memory leak in gst-libs/gst/gl/eagl/gstglwindow_eagl.m in iOS.
I cleaned the pipeline, but the `priv->internal_view` was not freed.
How to release the 'priv->internal_view'?
![memory_leak](/uploads/61d8393f24793b245887bd2a59e78097/memory_leak.png)
please refer to My clean up code below.
`
pipeline = gst_parse_launch(pipeline_str, NULL);
videosink = gst_bin_get_by_interface(GST_BIN(pipeline), GST_TYPE_VIDEO_OVERLAY);
main_loop = g_main_loop_new(NULL, FALSE);
gst_video_overlay_set_window_handle(GST_VIDEO_OVERLAY(videosink), (guintptr) preview);
gst_element_set_state(pipeline, GST_STATE_PLAYING);
g_main_loop_run(main_loop);
gst_element_set_state (pipeline, GST_STATE_NULL);
gst_object_unref (pipeline);
gst_object_unref(videosink);`https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/932Gst_video_meta_set_alignment() passes argument by value2021-09-24T13:26:31ZStefanSalewskiGst_video_meta_set_alignment() passes argument by value https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html?gi-language=c#gst_video_meta_set_alignment
No that is not wrong, but a bit surprising. As most GTK related functions seems to pass structs always as references. A... https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html?gi-language=c#gst_video_meta_set_alignment
No that is not wrong, but a bit surprising. As most GTK related functions seems to pass structs always as references. At least I can currently not remember a function which passes structs by value. For language bindings one has to be a bit carefully in this case.
Comment of Sebastian Dröge GNOME Team:
>That seems like an oversight. It should really be passed by reference to make automated bindings happy. Please create an issue
References: https://discourse.gnome.org/t/gst-video-meta-set-alignment-passes-argument-by-value/7258https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/723Gst_video_meta_set_alignment() passes argument by value2021-08-11T19:43:34ZStefanSalewskiGst_video_meta_set_alignment() passes argument by value https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html?gi-language=c#gst_video_meta_set_alignment
No that is not wrong, but a bit surprising. As most GTK related functions seems to pass structs always as references. A... https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html?gi-language=c#gst_video_meta_set_alignment
No that is not wrong, but a bit surprising. As most GTK related functions seems to pass structs always as references. At least I can currently not remember a function which passes structs by value. For language bindings one has to be a bit carefully in this case.
Comment of Sebastian Dröge GNOME Team:
>That seems like an oversight. It should really be passed by reference to make automated bindings happy. Please create an issue
References: https://discourse.gnome.org/t/gst-video-meta-set-alignment-passes-argument-by-value/7258https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/160fallbacksrc with stream HTTP/MJPEG2022-08-30T06:18:42ZAlexfallbacksrc with stream HTTP/MJPEGHi all!!
I am testing plugin fallbacksrc (0.7.0), for RSTP/H264 streaming work fine. However, I have problems with HTTP/MJPEG.
To simplify the example, I am using the uri property, where I indicate the address of the stream.
`gst-lau...Hi all!!
I am testing plugin fallbacksrc (0.7.0), for RSTP/H264 streaming work fine. However, I have problems with HTTP/MJPEG.
To simplify the example, I am using the uri property, where I indicate the address of the stream.
`gst-launch-1.0 fallbacksrc uri=http://192.168.0.231/video.mjpg ! videoconvert ! waylandsink`
The problem is that it does not link to the streaming and when the timeout ends it switches to the black image.
Is it possible to use HTTP/MJPEG streams with the fallbacksrc plugin?
Is it necessary to use any extra plugins?
[Attach log](/uploads/e3ece317e45ce38caa79f39a35d61beb/gst.log).
Usual pipeline that I used for HTTP is:
`gst-launch-1.0 -v souphttpsrc is-live=true location=http://192.168.0.231/video.mjpg ! multipartdemux ! jpegparse ! avdec_mjpeg ! waylandsink`
and pipeline with playbin work.
`gst-launch-1.0 -v playbin uri=http://192.168.0.231/video.mjpg`
Thanks!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/722RTSP Issue with gstreamer2021-08-13T12:40:26Zmehul-rigynRTSP Issue with gstreamerHello , I tried to play an RTSP stream with Gstreame with
gst-launch-1.0 --gst-debug=rtspsrc:5 rtspsrc location="rtsp://user:pass@ip.add.dest.serv:554/H264?ch=3&subtype=0" ! decodebin ! fakesink
but I got following error log
[gsterror...Hello , I tried to play an RTSP stream with Gstreame with
gst-launch-1.0 --gst-debug=rtspsrc:5 rtspsrc location="rtsp://user:pass@ip.add.dest.serv:554/H264?ch=3&subtype=0" ! decodebin ! fakesink
but I got following error log
[gsterrorlog.txt](/uploads/c0ffbb4f4d1e85a400941257da1ed0aa/gsterrorlog.txt)
I am able to run the rtsp stream in VLC player ir in ffplay.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/721Erroneous pipeline: no element "rtspsrc"2021-08-11T06:42:03Zmehul-rigynErroneous pipeline: no element "rtspsrc"Hello, when I try to run a rtsp stream with following launch command I get an error
**gst-launch-1.0 -v playbin uri="rtsp://link-to-rtsp-feed"**
Error:
```
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
/GstURI...Hello, when I try to run a rtsp stream with following launch command I get an error
**gst-launch-1.0 -v playbin uri="rtsp://link-to-rtsp-feed"**
Error:
```
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
/GstURIDecodeBin:uridecodebin0: ring-buffer-max-size = 0
/GstURIDecodeBin:uridecodebin0: buffer-size = -1
/GstURIDecodeBin:uridecodebin0: buffer-duration = -1
/GstURIDecodeBin:uridecodebin0: use-buffering = false
/GstURIDecodeBin:uridecodebin0: download = false
/GstURIDecodeBin:uridecodebin0: uri = rtsp://link-to-rtsp-feed
/GstURIDecodeBin:uridecodebin0: connection-speed = 0
Missing element: Real Time Streaming Protocol (RTSP) source
ERROR: from element /GstURIDecodeBin:uridecodebin0: No URI handler implemented for "rtsp".
Additional debug info:
gsturidecodebin.c(1409): gen_source_element (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0
Setting pipeline to NULL ...
Freeing pipeline ...
```