GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-08-17T10:00:35Zhttps://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 ...
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/913splitmuxsink creates files that are too large when using mpegtsmux2023-07-04T16:28:56Zkoreysplitmuxsink creates files that are too large when using mpegtsmuxWhen using mpegtsmux with splitmuxsink it will write the file fine but staying within the parameters the size of file seems to go bigger than set. If I use mp4mux it will at least stay within the max size file.
Gstreamer 1.18.4When using mpegtsmux with splitmuxsink it will write the file fine but staying within the parameters the size of file seems to go bigger than set. If I use mp4mux it will at least stay within the max size file.
Gstreamer 1.18.4https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/335Pattern for files_devel provided in libunwind.recipe results in build error o...2021-08-10T20:09:25ZSteve McDanielPattern for files_devel provided in libunwind.recipe results in build error on LinuxExtra dash prevents libunwind.pc from getting included in files_devel.
Cebero devel package is missing libunwind.pc because the pattern "libunwind-*.pc" is used to populate files_devel.
The missing libunwind.pc file results in pkg-co...Extra dash prevents libunwind.pc from getting included in files_devel.
Cebero devel package is missing libunwind.pc because the pattern "libunwind-*.pc" is used to populate files_devel.
The missing libunwind.pc file results in pkg-config failing to resolve dependencies for gstreamer-1.0.pc.
Fixed in Merge Request: https://gitlab.freedesktop.org/gstreamer/cerbero/-/merge_requests/722https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/352`extern "C"` functions called from C code should guard against unwinding2021-08-11T09:10:24ZSimonas Kazlauskas`extern "C"` functions called from C code should guard against unwindingAs far as I can tell https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/master/gstreamer/src/log.rs#L342-377 is called directly from GStreamer and then calls arbitrary Rust code. However it does not catch the unwinding that hap...As far as I can tell https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/master/gstreamer/src/log.rs#L342-377 is called directly from GStreamer and then calls arbitrary Rust code. However it does not catch the unwinding that happens from the Rust end, therefore being (I believe) unsound especially with versions of Rust that don't mitigate this by introducing trampolines that abort in these kinds of situations.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1638SRT stats send-duration-us duplicated2021-09-24T14:39:33ZSektor van SkijlenSRT stats send-duration-us duplicatedThe `send-duration-us` field is defined twice, and each time with a different type.
File `ext/srt/gstsrtobject.c` function `get_stats_for_srtsock`, in the `is_sender` section there is:
```
...
/* time duration when UDT is send...The `send-duration-us` field is defined twice, and each time with a different type.
File `ext/srt/gstsrtobject.c` function `get_stats_for_srtsock`, in the `is_sender` section there is:
```
...
/* time duration when UDT is sending data (idle time exclusive) */
"send-duration-us", G_TYPE_INT64, stats.usSndDuration,
...
/* busy sending time (i.e., idle time exclusive) */
"send-duration-us", G_TYPE_UINT64, stats.usSndDuration,
"negotiated-latency-ms", G_TYPE_INT, stats.msSndTsbPdDelay, NULL);
```
Another minor problem is `*bytes += stats.byteSent;` for `is_sender` section, but `stats.byteRecvTotal` for else section. As you don't request clearing the stats in the `srt_bstats` call it shouldn't make a difference, but formally it's wrong.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/931gl: Need to add modifier support for glupload and gldownload2023-07-27T11:30:05ZHe Junyangl: Need to add modifier support for glupload and gldownloadThe new platform export the DRM's modifier to users now. For example, the GPU surface with the X tiling have the modifier of I915_FORMAT_MOD_X_TILED on Intel platforms. We need to set this kind of modifiers correctly when we share the DM...The new platform export the DRM's modifier to users now. For example, the GPU surface with the X tiling have the modifier of I915_FORMAT_MOD_X_TILED on Intel platforms. We need to set this kind of modifiers correctly when we share the DMA surfaces between different module, such as VA->3D. On old platform, this modifier stored inside libdrm but now we need to explicitly specify it.
We already have some patch for VA part: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2032
and according to @ndufresne , all the video-format/modifier should have "format:modifier" in caps, like:
```
video/x-raw(memory:DMABuf)
width: [ 16, 16384 ]
height: [ 16, 16384 ]
format: { (string)NV12:0x0100000000000002, (string)I420, (string)YV12, (string)YUY2:0x0100000000000002, (string)P010_10LE:0x0100000000000002, (string)BGRA:0x0100000000000002, (string)RGBA:0x0100000000000002, (string)BGR10A2_LE:0x0100000000000002, (string)VUYA:0x0100000000000002 }
```
We also need to add this to gl's DMA part.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/930playbin2 hangs on "about-to-finish" signal with audio/video media2021-09-30T08:11:12ZStéphane Cerveauscerveau@igalia.complaybin2 hangs on "about-to-finish" signal with audio/video media### Describe your issue
Playing a playlist of A/V media with gst-play-1.0 hangs on first media change (about-to-finish). The bug does not happen with video only media.
#### Expected Behavior
Play the next media.
#### Observed Behavior...### Describe your issue
Playing a playlist of A/V media with gst-play-1.0 hangs on first media change (about-to-finish). The bug does not happen with video only media.
#### Expected Behavior
Play the next media.
#### Observed Behavior
The playback hangs on first "about-to-finish" using gst-play-1.0 with a media composed of a video track **AND** an audio track
#### Setup
- **Operating System:** Linux
- **Device:** Computer
- **GStreamer Version:** Master
- **Command line:**
### Steps to reproduce the bug
```
$ gst-play-1.0 file1.mov file2.mov --gapless
```
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
The bug happens on any GStreamer version since 1.16https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/912matroskademux: subrip subtitles can be rendered with XML tags2022-10-17T11:17:25ZAlexander Slobodeniukmatroskademux: subrip subtitles can be rendered with XML tags**About the issue:**
---------------
We have a file, it's muxed with ffmpeg, and contains SubRip subtitles (from an srt file)
[SampleVideo_640x480_1mb.mkv](/uploads/0d66c18801a84c5290c0b3da92eb5ec1/SampleVideo_640x480_1mb.mkv)
VLC can ...**About the issue:**
---------------
We have a file, it's muxed with ffmpeg, and contains SubRip subtitles (from an srt file)
[SampleVideo_640x480_1mb.mkv](/uploads/0d66c18801a84c5290c0b3da92eb5ec1/SampleVideo_640x480_1mb.mkv)
VLC can play this file without issues
![mkv-vlc](/uploads/bb3ae16d0a8f118c8333b047a00833a7/mkv-vlc.jpg)
But if we play it with gst-play-1.0, we can see the XML tags rendered together with the subtitle text
![mkv-gst](/uploads/0c0af63bbcc00ad32f922d2bd872cbe6/mkv-gst.jpg)
---
Subtitles are correctly muxed and have codec id of the SubRip format: [S_TEXT/UTF8](https://tools.ietf.org/id/draft-ietf-cellar-codec-04.html#name-srt-subtitles)
When matroskademux element opens this file, for subtitles stream it [exposes pango-markup caps](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/gst/matroska/matroska-demux.c#L7295)
```c
...
if (!strcmp (codec_id, GST_MATROSKA_CODEC_ID_SUBTITLE_UTF8)) {
/* well, plain text simply does not have a lot of markup ... */
caps = gst_caps_new_simple ("text/x-raw", "format", G_TYPE_STRING,
"pango-markup", NULL);
context->postprocess_frame = gst_matroska_demux_check_subtitle_buffer;
subtitlecontext->check_markup = TRUE;
...
```
This particular action (saying that SubRip is a pango markup) is wrong: SubRip has it's own markup, and it's not always compatible with pango, and the file attached is the case.
**About a fix:**
---
If we open with GStreamer an srt file with same subtitles, it doesn't have described issue, because the input is handled by a **subparse** element, that converts different subtitle formats to pango-markup and also throws away unknown markups.
Idea of fix that is going to be proposed in the MRs is to make **subparse** element autoplug after **matroskademux** and make the convertion SubRip --> pango-markup.
To do that we do 2 things:
1. Instead of "pango-markup" expose from **matroskademux** some new format, let's call it "text/x-subrip-muxed" (do you know, maybe there's already some existing format for it?).
NOTE: We can't use "application/x-subtitle" that is used for srt files, because it's a little bit different: data of such format is supposed to have number and timestamp inside of the text.
[MR to matroskademux element, (gst-plugins-good)](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1045/diffs)
2. Make **subparse** element handle "text/x-subrip-muxed". [MR to subparse element (gst-plugins-base)](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1248/diffs)https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/90http://gstreamer-devel.966125.n4.nabble.com/ offline?2021-09-17T17:55:15ZMarianna Smidth Buschlehttp://gstreamer-devel.966125.n4.nabble.com/ offline?For several days I can't access http://gstreamer-devel.966125.n4.nabble.com/
Is it down?For several days I can't access http://gstreamer-devel.966125.n4.nabble.com/
Is it down?