GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-06-01T16:16:49Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/900rtspsrc: deadlock on set_state(NULL)2023-06-01T16:16:49ZAlba Mendezme@alba.shrtspsrc: deadlock on set_state(NULL)I've found a deadlock when setting the state of `rtspsrc` to `NULL`. I think this bug is in rtspsrc's side, not our pipeline, but I might be wrong.
- `change_state` waits for the RTSP task to finish.
- It can't finish because it's in th...I've found a deadlock when setting the state of `rtspsrc` to `NULL`. I think this bug is in rtspsrc's side, not our pipeline, but I might be wrong.
- `change_state` waits for the RTSP task to finish.
- It can't finish because it's in the middle of sending EOS to the stream's `udpsrc[0]`, and it's waiting on its `STATE_LOCK`.
- `STATE_LOCK` is held by the RTCP task, which is (due to timeout) also sending EOS to the stream's `udpsrc[0]`. It can't finish because it's waiting for udpsrc's task to finish.
- udpsrc's task can't finish because it's blocked by rtpjitterbuffer's chain function. I suppose the 'flushing' is expected to unblock it, but I still have to investigate further.
Note: (I don't know if it's relevant) I didn't call `gst_element_set_state` on `rtspsrc` directly, but on its immediate parent bin (which is not the pipeline).
Below are the relevant stack traces. This caught me off guard, I'm not 100% sure the stack traces are correct... once I'm able to reproduce again I'll give more info.
Main thread:
- gst_element_set_state(bin, NULL)
- https://gitlab.freedesktop.org/gstreamer/gstreamer/blob/41677a526b83bb2493087af1d93b50c297cf97cd/gst/gstbin.c#L2615
- https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/rtsp/gstrtspsrc.c#L9233
RTSP task:
- https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/rtsp/gstrtspsrc.c#L6189
- https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/rtsp/gstrtspsrc.c#L5049
- https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/rtsp/gstrtspsrc.c#L5003
- https://gitlab.freedesktop.org/gstreamer/gstreamer/blob/b16e96dd878e0c5e7baeb8fad62ca43de1f66982/gst/gstelement.c#L1973
RTCP task:
- https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/rtsp/gstrtspsrc.c#L3600
- https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/rtsp/gstrtspsrc.c#L3581
- https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/rtsp/gstrtspsrc.c#L3543
- https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/aad9c8a2165b0bbee957c54262391006e81907af/gst/rtsp/gstrtspsrc.c#L5003
- https://gitlab.freedesktop.org/gstreamer/gstreamer/blob/5230cab38d22b861fec54174c9285fb4c2f10cef/libs/gst/base/gstbasesrc.c#L1934
udpsrc task:
~~~
#1 0x0000007f884f4b84 in g_cond_wait () at /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#2 0x0000007f4aef9a40 in gst_rtp_jitter_buffer_chain () at /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstrtpmanager.so
#3 0x0000007f78167de4 in gst_pad_push_data () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#4 0x0000007f781710bc in gst_pad_push () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#5 0x0000007f4af0784c in gst_rtp_ssrc_demux_chain () at /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstrtpmanager.so
#6 0x0000007f78167de4 in gst_pad_push_data () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#7 0x0000007f781710bc in gst_pad_push () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#8 0x0000007f78167de4 in gst_pad_push_data () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#9 0x0000007f781710bc in gst_pad_push () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#10 0x0000007f4af27a5c in gst_rtp_session_process_rtp () at /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstrtpmanager.so
#11 0x0000007f4af0cb90 in source_push_rtp () at /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstrtpmanager.so
#12 0x0000007f4af1e704 in rtp_source_process_rtp () at /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstrtpmanager.so
#13 0x0000007f4af19a84 in rtp_session_process_rtp () at /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstrtpmanager.so
#14 0x0000007f4af2b460 in gst_rtp_session_chain_recv_rtp () at /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstrtpmanager.so
#15 0x0000007f78167de4 in gst_pad_push_data () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#16 0x0000007f781710bc in gst_pad_push () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#17 0x0000007f7814f0f4 in gst_proxy_pad_chain_default () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#18 0x0000007f78167de4 in gst_pad_push_data () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#19 0x0000007f781710bc in gst_pad_push () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#20 0x0000007f6b79a734 in gst_base_src_loop () at /usr/lib/aarch64-linux-gnu/libgstbase-1.0.so.0
#21 0x0000007f781aa94c in gst_task_func () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
~~~https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/710Wrong profile-level-id doesn't allow to show video stream on Chrome2022-11-10T09:21:07ZSabri MTIBAAWrong profile-level-id doesn't allow to show video stream on ChromeHello,
I have an issue with the the profile-level-id generated in SDP offer. gstreamer is well launched with different pipelines
tspsrc name=uridb location=rtsp://3xxxxx/media latency=100 ! queue ! webrtcbin name=sendrecv stun-server=st...Hello,
I have an issue with the the profile-level-id generated in SDP offer. gstreamer is well launched with different pipelines
tspsrc name=uridb location=rtsp://3xxxxx/media latency=100 ! queue ! webrtcbin name=sendrecv stun-server=stun://xxxx:19302"
the problem that the video streaming doesn't work only if profile level id to equal 42e01f .. others media streams worked fine.
is it possible to have a way to force the attribute "rofile-level-id" in SDP offer? I mean from the source code.
SDP offer
{
"sdp": {
"type": "offer",
"sdp": "
v=0\r\no=- 5741020075475070333 0 IN IP4 0.0.0.0\r\n
s=-\r\nt=0 0\r\n
a=ice-options:trickle\r\n
m=video 9 UDP/TLS/RTP/SAVPF 96\r\n
c=IN IP4 0.0.0.0\r\na=setup:actpass\r\n
a=ice-ufrag:p1Wf4WFTOUtYhdUgIe4SpcPS9vD47giI\r\n
a=ice-pwd:UjXwzttvUang42eAj5piRmkpZFHBmoO5\r\n
a=rtcp-mux\r\na=rtcp-rsize\r\na=sendrecv\r\n
a=rtpmap:96 H264/90000\r\na=rtcp-fb:96 nack pli\r\n
a=rtcp-fb:96 transport-cc\r\na=charset:Shift_JIS\r\n
a=etag:1234567890\r\na=x-framerate:15\r\na=framerate:15.0\r\n
a=fmtp:96 packetization-mode=1;profile-level-id=4d0028;sprop-parameter-sets=Z00AKIqKUDwBE/Kg,aO48gA==\r\n
a=ssrc:1687063760 msid:user481470074@host-90bfffe2 webrtctransceiver0\r\n
a=ssrc:1687063760 cname:user481470074@host-90bfffe2\r\na=mid:video0\r\n
a=fingerprint:sha-256 C4:59:DC:2D:AD:48:55:AD:8E:5E:4B:4B:33:62:47:05:84:1B:35:49:FE:F2:3E:D2:6D:A4:08:AA:30:4F:4F:C1\r\n
a=rtcp-mux-only\r\n
a=fmtp:96 profile-level-id=42e01f\r\n"
},
"type": "video-offer",
"target": "mobile",
"name": "camera"
}
thanks
Sabrihttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/899imagefreeze does not take num_buffers property2021-06-16T14:27:40ZJeffrey Bindingaimagefreeze does not take num_buffers propertyWhen using imagefreeze in a gstreamer pipeline on Debian, I cannot specify the num-buffers property. And when I do not, it will hang the process infinitely.
To reproduce, you can use the following command:
`gst-launch-1.0 \
compositor...When using imagefreeze in a gstreamer pipeline on Debian, I cannot specify the num-buffers property. And when I do not, it will hang the process infinitely.
To reproduce, you can use the following command:
`gst-launch-1.0 \
compositor name=comp sink_0::width=960 sink_0::height=540 sink_0::offset=$v0offset \
sink_1::width=960 sink_1::height=540 sink_1::xpos=960 sink_1::offset=$v1offset \
sink_2::width=960 sink_5::height=540 \
sink_3::width=960 sink_6::height=540 sink_6::xpos=960 \
background=black \
mp4mux name=muxp4 ! filesink location=sw_av_img2.mp4 \
filesrc location=$audio ! wavparse ! faac ! muxp4. \
capturesrc location=$v0 timestamp-present=true length-size=4 ! h264parse ! avdec_h264 ! videorate ! comp. \
capturesrc location=$v1 timestamp-present=true length-size=4 ! h264parse ! avdec_h264 ! videorate ! comp. \
comp. ! x264enc speed-preset=ultrafast bitrate=1000 ! video/x-h264,width=1920,height=1080,framerate=15/2 ! muxp4. \
filesrc location=$img ! decodebin ! videoconvert ! video/x-raw,format=I420 ! textoverlay text=TB ! imagefreeze num-buffers=50 ! comp. \
filesrc location=$img ! decodebin ! videoconvert ! video/x-raw,format=I420 ! textoverlay text=MD ! imagefreeze num-buffers=50 ! comp. `
This gives me the following output:
`WARNING: erroneous pipeline: no property "num-buffers" in element "imagefreeze0"`
I am using gstreamer on Debian 10.9 and have deployed the following packages.
libgstreamer1.0-0/stable,now 1.14.4-1 amd64
gstreamer1.0-plugins-good/stable,now 1.14.4-1+deb10u1 amd64https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/709[Gstreamer]GstDtlsConnection : error: SSL routines:ssl_read_internal:uninitia...2021-06-16T13:14:51ZSabri MTIBAA[Gstreamer]GstDtlsConnection : error: SSL routines:ssl_read_internal:uninitializedDears,
I'm working on an internal project to experiment WebRTC. I'm using a IP Camera which provides RTSP Stream and followed the nice example that Nirbheek provided it convert tom RTSP to WebRTC.
http://blog.nirbheek.in/2018/02/gstrea...Dears,
I'm working on an internal project to experiment WebRTC. I'm using a IP Camera which provides RTSP Stream and followed the nice example that Nirbheek provided it convert tom RTSP to WebRTC.
http://blog.nirbheek.in/2018/02/gstreamer-webrtc.html
Due to limited size of camera memory/ size I tried to simplify the gstreamer pipeline and cross compiled in static gstreamer. Everything is fine except that the streaming doesn't work due SSL error.
0:00:12.838692803 1577 0x2129c50 ERROR dtlsconnection gstdtlsconnection.c:994:handle_error:<GstDtlsConnection@0x20c5e20> Fatal SSL error
0:00:12.838902078 1577 0x2129c50 ERROR dtlsconnection gstdtlsconnection.c:977:ssl_err_cb:<GstDtlsConnection@0x20c5e20> ssl error: 1883194048:error:1420B114:SSL routines:ssl_read_internal:uninitialized:ssl/ssl_lib.c:1727:
0:00:12.839094262 1577 0x2129c50 ERROR dtlsdec gstdtlsdec.c:503:process_buffer:<dtlsdec0> Error processing buffer: Fatal SSL error
0:00:12.839345028 1577 0x2129c50 ERROR dtlsdec gstdtlsdec.c:618:sink_chain:<dtlsdec0> Failed to process buffer: error
Any idea please?
Thanks in advance for your help.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/308pipe.set_context(context) not working?2021-12-02T12:00:26ZMarianna Smidth Buschlepipe.set_context(context) not working?Basically I have 2 problems which are both related to the `VADisplay` (in the `GstContext`):
- I need to do remote development, so I need to use X forwarding (`ssh -X`)
- I need to decouple my pipelines, using something like the `interpi...Basically I have 2 problems which are both related to the `VADisplay` (in the `GstContext`):
- I need to do remote development, so I need to use X forwarding (`ssh -X`)
- I need to decouple my pipelines, using something like the `interpipesrc/sink` from RidgeRun
For the 1st see http://gstreamer-devel.966125.n4.nabble.com/vaapi-and-x-forwarding-td4697642.html for full story.
But basically the issue is that I need to remotely run (with X forwarding) some pipelines with VAAPI elements (`vaapih264enc/dec`), a simple example:
```
gst-launch-1.0 videotestsrc is-live=true pattern=ball !
video/x-raw,framerate=30/1,format=NV12 ! tee name=t ! queue ! vaapih264enc
rate-control=4 bitrate=15000 ! video/x-h264,profile=high ! h264parse !
fakesink t. ! queue ! videoconvert ! timeoverlay ! textoverlay text=src !
ximagesink sync=0
```
Which results in:
```
Setting pipeline to PAUSED ...
error: XDG_RUNTIME_DIR not set in the environment.
X Error of failed request: BadRequest (invalid request code or no such
operation)
Major opcode of failed request: 154 (DRI2)
Minor opcode of failed request: 1 (DRI2Connect)
Serial number of failed request: 12
Current serial number in output stream: 12
```
It has been pointed to me that the problem is related `DRI2` support:
> I guess the problems caused by the `SSH with "-X"`
The vaapi elements need the DRI2 protocal support, which can not span
the machine. It only support local X server.
> You can run this command on the local machine or compile the VAAPI
plugins without X11 feature.
> Vaapi element inside use gst_vaapi_create_display() to create the
VADisplay. It will try wayland, x11, drm one by one. In your case, the
x11 way return success and so choose. But later, when vaInitialize, the
it fails to init because no DRI2 extersion support.
> The best way is disabling the X11 support in build. And because you do
not need to use vaapisink, it is OK.
With this information I have managed to "force" the DRM display by doing something like this:
```
gst-launch-1.0 videotestsrc is-live=true pattern=ball !
video/x-raw,framerate=30/1,format=NV12 ! tee name=t ! queue ! vaapih264enc
rate-control=4 bitrate=5000 ! video/x-h264,profile=high ! queue ! h264parse
! queue ! vaapih264dec low-latency=1 ! queue !
video/x-raw,framerate=30/1,format=NV12 ! queue ! videoconvert ! queue !
ximagesink sync=0 fakesrc ! vaapisink display=drm --gst-debug=*:3
```
The `fakesrc ! vaapisink display=drm` forces the `VADisplay` to DRM and that gets shared on the bus and set automatically on the `vaapih264enc`/`vaapih264dec`
The `fakesrc ! vaapisink display=drm` pipeline dies right away:
```
0:00:00.167233055 5878 0x564d0741e4f0 WARN vaapisink gstvaapipluginbase.c:1260:gst_vaapi_plugin_base_pad_get_input_buffer:<vaapisink0> error: failed to validate source buffer
0:00:00.167252497 5878 0x564d0741e4f0 WARN vaapisink gstvaapipluginbase.c:1260:gst_vaapi_plugin_base_pad_get_input_buffer:<vaapisink0> error: failed to validate source buffer
ERROR: from element /GstPipeline:pipeline0/GstVaapiSink:vaapisink0: failed to validate source buffer
Additional debug info:
../gstreamer-vaapi-1.18.2/gst/vaapi/gstvaapipluginbase.c(1260): gst_vaapi_plugin_base_pad_get_input_buffer (): /GstPipeline:pipeline0/GstVaapiSink:vaapisink0: failed to validate source buffer
ERROR: pipeline doesn't want to preroll.
0:00:00.167433979 5878 0x564d0741e4f0 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<fakesrc0> error: Internal data stream error.
0:00:00.167453711 5878 0x564d0741e4f0 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<fakesrc0> error: streaming stopped, reason error (-5)
ERROR: from element /GstPipeline:pipeline0/GstFakeSrc:fakesrc0: Internal data stream error.
```
But the rest continues to play fine.
Now I would like a bit more elegant solution, since I need to handle anyway the HAVE_CONTEXT and NEED_CONTEXT messages on the bus because I want to decouple my pipelines.
So I have tried:
```
pipelines.append("videotestsrc num-buffers=1 ! vaapisink display=drm
name=vaapi_dummy")
pipelines.append("videotestsrc is-live=true pattern=ball !
video/x-raw,framerate=30/1,format=NV12 ! "
"tee name=t ! queue ! vaapih264enc name=enc rate-control=4
bitrate=15000 ! video/x-h264,profile=high ! h264parse ! "
"interpipesink name=vtest sync=false async=false "
"t. ! queue ! videoconvert ! timeoverlay ! textoverlay
text=src ! ximagesink sync=0 ")
pipelines.append("interpipesrc listen-to=vtest is-live=false
stream-sync=restart-ts ! "
"identity sync=true ! h264parse ! vaapih264dec name=dec
low-latency=true ! queue ! videoconvert ! timeoverlay ! textoverlay
name=text_out text=out ! ximagesink sync=0 ")
```
The first pipeline goes to playing from start, and then after I got the context from it I start the other 2.
However it doesn't work, I end up getting the DRI2 error as soon as the 2 other pipelines go into playing/ready/paused, before I get the NEED_CONTEXT message from them...
So I have also tried setting the context before setting them to PLAYING (instead of waiting for the NEED_CONTEXT), but the context doesn't seem to get applied, because I still get the DRI2 error.
```
def on_message(self, bus, message, pipe):
mtype = message.type
if mtype == Gst.MessageType.EOS:
# Handle End of Stream
print("End of stream from " + str(message.src.name))
elif mtype == Gst.MessageType.ERROR:
# Handle Errors
err, debug = message.parse_error()
print(err, debug)
self.loop.quit()
exit(-1)
elif mtype == Gst.MessageType.WARNING:
# Handle warnings
err, debug = message.parse_warning()
print(err, debug)
elif mtype == Gst.MessageType.NEED_CONTEXT:
res, context_type = message.parse_context_type()
print("Got NEED_CONTEXT: " + str(context_type) + " from " + str(message.src.name))
if context_type != "gst.vaapi.Display":
return Gst.BusSyncReply.PASS
if not self.vaapi_display:
print("No Context available")
return Gst.BusSyncReply.PASS
context = Gst.Context.new("gst.vaapi.Display", False)
s = context.writable_structure()
s.set_value("gst.vaapi.Display", self.vaapi_display)
message.src.set_context(context)
elif mtype == Gst.MessageType.HAVE_CONTEXT:
context = message.parse_have_context()
if not context:
return Gst.BusSyncReply.PASS
context_type = context.get_context_type()
print("Got HAVE_CONTEXT: " + str(context_type) + " from " + str(message.src.name))
if context_type != "gst.vaapi.Display":
return Gst.BusSyncReply.PASS
s = context.get_structure()
if not s:
return Gst.BusSyncReply.PASS
value = s.get_value("gst.vaapi.Display")
if not value:
return Gst.BusSyncReply.PASS
print("Found display: " + str(value.name))
if not self.vaapi_display:
self.vaapi_display = GObject.Value.dup_object(value)
print("New display: " + str(self.vaapi_display.name))
else:
print("Warning, we already have a VADisplay: " + str(self.vaapi_display.name))
#play other pipes when we have a VADisplay
if message.src.name == "vaapi_dummy":
for pipe in self.pipeline:
enc = pipe.get_by_name("enc")
dec = pipe.get_by_name("dec")
if enc or dec:
context = Gst.Context.new("gst.vaapi.Display", False)
s = context.writable_structure()
s.set_value("gst.vaapi.Display", self.vaapi_display)
if enc:
print("Setting enc context")
pipe.set_context(context)
if dec:
print("Setting dec context")
pipe.set_context(context)
self.play(pipe=pipe)
#return True
return Gst.BusSyncReply.PASS
```
The only way I can avoid the error is by adding fx `videotestsrc num-buffers=1 ! vaapisink display=drm` to each pipeline (which I really don't this is a good solution).
Then I can see the NEED/HAVE context messages from all the vaapisinks, but not from encoder/decoder.
I guess their contexts are being set by upstream/downstream queries?
And for the second problem, if I don't use X forwarding, but just want to be able to set a common `VADisplay` for the encoder/decoder in the decoupled pipelines.
I still get kind of the same issues, the context doesn't seem to get applied through neither the NEED_CONTEXT nor if I do it before going into playing.
I end up getting a lot of NEED/HAVE context messages from both encoder and decoder with all sorts of different displays and not the DRM from the first "dummy" pipeline.
```
0:00:00.112341812 10690 0x7fc8901bd750 WARN vaapiblend gstvaapiblend.c:184:gst_vaapi_blend_initialize:<vaapiblend0> VPP does not support global alpha blending
Got NEED_CONTEXT: gst.vaapi.app.Display from vaapi_dummy
Got HAVE_CONTEXT: gst.vaapi.Display from vaapi_dummy
Found display: vaapidisplaydrm1
New display: vaapidisplaydrm1
0:00:00.169431769 10690 0x55a6f745d230 FIXME default gstutils.c:4025:gst_pad_create_stream_id_internal:<videotestsrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
error: XDG_RUNTIME_DIR not set in the environment.
error: XDG_RUNTIME_DIR not set in the environment.
0:00:00.186637485 10690 0x55a6f745e0a0 FIXME default gstutils.c:4025:gst_pad_create_stream_id_internal:<videotestsrc1:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
Got NEED_CONTEXT: gst.vaapi.Display from enc
(gst_ctrl.py:10690): GStreamer-CRITICAL **: 09:34:46.751: gst_structure_free: assertion 'GST_STRUCTURE_REFCOUNT (structure) == NULL' failed
Got HAVE_CONTEXT: gst.vaapi.Display from enc
Found display: vaapidisplayglx0
Warning, we already have a VADisplay: vaapidisplaydrm1
0:00:00.245473554 10690 0x55a6f745df70 FIXME default gstutils.c:4025:gst_pad_create_stream_id_internal:<interpipesrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
End of stream from pipeline0
Got NEED_CONTEXT: gst.vaapi.Display from dec
(gst_ctrl.py:10690): GStreamer-CRITICAL **: 09:34:46.754: gst_structure_free: assertion 'GST_STRUCTURE_REFCOUNT (structure) == NULL' failed
Got NEED_CONTEXT: gst.gl.GLDisplay from dec
Got NEED_CONTEXT: gst.x11.display.handle from dec
Got NEED_CONTEXT: GstWaylandDisplayHandleContextType from dec
Got HAVE_CONTEXT: gst.gl.GLDisplay from dec
Got NEED_CONTEXT: gst.gl.app_context from dec
Got HAVE_CONTEXT: gst.vaapi.Display from dec
Found display: vaapidisplayx11-0
Warning, we already have a VADisplay: vaapidisplaydrm1
0:00:00.405237943 10690 0x55a6f745f9e0 WARN GST_CAPS gstpad.c:5701:pre_eventfunc_check:<vtest:sink> caps video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)high, level=(string)3.2, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt601, chroma-site=(string)jpeg, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true not accepted
0:00:00.405493743 10690 0x55a6f745e050 ERROR interpipesink gstinterpipesink.c:447:gst_inter_pipe_sink_get_caps:<vtest> Failed to obtain an intersection between upstream elements and listeners
0:00:00.405797199 10690 0x55a6f745f9e0 ERROR interpipesink gstinterpipesink.c:432:gst_inter_pipe_sink_get_caps:<vtest> Failed to obtain an intersection between listener caps
```
Am I missing something in how to properly set the `GstContext`/`VADisplay`?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/155Add sample on how to include a plugin to a flatpak manifest2023-02-23T17:17:21ZDave Patrick CabertoAdd sample on how to include a plugin to a flatpak manifestIt would be helpful since it is not that straightforwardIt would be helpful since it is not that straightforwardJordan PetridіsJordan Petridіshttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/331Cannot bootstrap on Debian 10 (Buster)2021-06-21T14:24:39ZBartłomiej KurzejaCannot bootstrap on Debian 10 (Buster)Hi,
I can't bootstrap the latest version of cerbero (master branch) from `python:3.8-slim` docker image that under the hood is Debian 10. It looks like Debian changes the representation of releases.
```
user@e19262871794:/cerbero$ git ...Hi,
I can't bootstrap the latest version of cerbero (master branch) from `python:3.8-slim` docker image that under the hood is Debian 10. It looks like Debian changes the representation of releases.
```
user@e19262871794:/cerbero$ git rev-parse --short HEAD
bf82c02d
user@e19262871794:/cerbero$ cat /etc/issue
Debian GNU/Linux 10 \n \l
user@e19262871794:/cerbero$ ./cerbero-uninstalled bootstrap
Traceback (most recent call last):
File "<string>", line 19, in <module>
File "/cerbero/cerbero/main.py", line 19, in <module>
from cerbero import hacks
File "/cerbero/cerbero/hacks.py", line 99, in <module>
from cerbero.utils.shell import new_call as shell_call
File "/cerbero/cerbero/utils/shell.py", line 51, in <module>
PLATFORM = system_info()[0]
File "/cerbero/cerbero/utils/__init__.py", line 267, in system_info
raise FatalError("Distribution '%s' not supported" % str(d))
cerbero.errors.FatalError: Fatal Error: Distribution '('Debian GNU/Linux', '10', 'buster')' not supported
```https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/140eventfd leacks caused by clients disconnected without TEARDOWN request2021-06-15T12:46:59ZIohannes Folborteventfd leacks caused by clients disconnected without TEARDOWN requestI am debugging a server, which listens for rtp streams and wraps them arround with rtsp connection.
When clients request stream url's from server and disconnect from it without anouncing TEARDOWN request i see that the server doesn't ret...I am debugging a server, which listens for rtp streams and wraps them arround with rtsp connection.
When clients request stream url's from server and disconnect from it without anouncing TEARDOWN request i see that the server doesn't return fome event file descriptors to system.
# Scenario
1. Server started (0 clients connected)
```
# lsof -p `ps ax | grep rtp-to-rtsp | grep build | awk '{print $1}'` | wc -l
160
```
2. Client 1 connected to stream (1 client listens for stream)
```
# lsof -p `ps ax | grep rtp-to-rtsp | grep build | awk '{print $1}'` | wc -l
238
```
3. Client 2 connected to stream (2 clients listen for stream)
```
# lsof -p `ps ax | grep rtp-to-rtsp | grep build | awk '{print $1}'` | wc -l
304
```
4. Client 2 disconnected from stream
```
# lsof -p `ps ax | grep rtp-to-rtsp | grep build | awk '{print $1}'` | wc -l
238
```
5. Client 1 disconnected from stream
```
# lsof -p `ps ax | grep rtp-to-rtsp | grep build | awk '{print $1}'` | wc -l
172
```
6. Client 1 connected to stream
```
# lsof -p `ps ax | grep rtp-to-rtsp | grep build | awk '{print $1}'` | wc -l
239
```
7. Client 1 disconnected from stream
```
# lsof -p `ps ax | grep rtp-to-rtsp | grep build | awk '{print $1}'` | wc -l
173
```
8. Client 1 connected to server
9. Client 1 disconnected from server
```
# lsof -p `ps ax | grep rtp-to-rtsp | grep build | awk '{print $1}'` | wc -l
174
```
# Investigation
The clients terminate TCP connection but doesn't send TEARDOWN request. I have attached two logs with opened files, that server holds
[log1 - list of opened files by server after first client (connect disconnect)](/uploads/d6505178fd6d49d68a67af8f9daede05/log1)
[log2 - list of opened files by server after 10 times connect/disconnect](/uploads/985096c121510d37d95d7a8f22e495c3/log2)
The `diff` between the files shows, that some eventfd's are not freed:
```
diff -Npru /tmp/log1 /tmp/log2
--- /tmp/log1 2021-06-15 14:11:40.915764953 +0200
+++ /tmp/log2 2021-06-15 14:12:19.296715697 +0200
@@ -168,5 +168,15 @@ rtp-to-rt 26946 ifolbort 39u a_inode
rtp-to-rt 26946 ifolbort 40u IPv4 8903123 0t0 TCP *:8554 (LISTEN)
rtp-to-rt 26946 ifolbort 41u IPv4 8903125 0t0 TCP localhost:3737 (LISTEN)
rtp-to-rt 26946 ifolbort 43u a_inode 0,13 0 9299 [eventfd]
+rtp-to-rt 26946 ifolbort 44u a_inode 0,13 0 9299 [eventfd]
+rtp-to-rt 26946 ifolbort 45u a_inode 0,13 0 9299 [eventfd]
+rtp-to-rt 26946 ifolbort 46u a_inode 0,13 0 9299 [eventfd]
+rtp-to-rt 26946 ifolbort 47u a_inode 0,13 0 9299 [eventfd]
+rtp-to-rt 26946 ifolbort 48u a_inode 0,13 0 9299 [eventfd]
+rtp-to-rt 26946 ifolbort 49u a_inode 0,13 0 9299 [eventfd]
+rtp-to-rt 26946 ifolbort 50u a_inode 0,13 0 9299 [eventfd]
+rtp-to-rt 26946 ifolbort 51u a_inode 0,13 0 9299 [eventfd]
rtp-to-rt 26946 ifolbort 52u unix 0x00000000d7ef03c5 0t0 8904713 type=STREAM
rtp-to-rt 26946 ifolbort 53u unix 0x000000000ecc3ba3 0t0 8904714 type=STREAM
+rtp-to-rt 26946 ifolbort 54u a_inode 0,13 0 9299 [eventfd]
+rtp-to-rt 26946 ifolbort 55u a_inode 0,13 0 9299 [eventfd]
```
If at least one client is connected to server then the leack is not observed (see steps 3,4 in the Scenario).
I wonder if it is an internal gst-rtsp-server issue or a misshandle my rtsp connections?
For each media factory i use next configurations:
```
factory = gst_rtsp_media_factory_new();
gst_rtsp_media_factory_set_media_gtype(factory, GST_TYPE_RTSP_MEDIA);
gst_rtsp_media_factory_set_launch(GST_RTSP_MEDIA_FACTORY(factory), gstLaunchString.c_str());
gst_rtsp_media_factory_set_shared(GST_RTSP_MEDIA_FACTORY(factory), FALSE);
gst_rtsp_media_factory_set_suspend_mode(GST_RTSP_MEDIA_FACTORY(factory), GST_RTSP_SUSPEND_MODE_RESET);
gst_rtsp_media_factory_set_transport_mode(GST_RTSP_MEDIA_FACTORY(factory), GST_RTSP_TRANSPORT_MODE_PLAY);
gst_rtsp_media_factory_set_stop_on_disconnect(GST_RTSP_MEDIA_FACTORY(factory), TRUE);
```
Up on `GstRTSPClient` `closed` signal i perform next cleanup:
```
static gboolean cleanup_sessions(GstRTSPServer* server)
{
GstRTSPSessionPool* pool = gst_rtsp_server_get_session_pool(server);
guint sessions = gst_rtsp_session_pool_get_n_sessions(pool);
gst_rtsp_session_pool_cleanup(pool);
gst_object_unref(pool);
return TRUE;
}
GstRTSPFilterResult media_remove(GstRTSPSession * sess,
GstRTSPSessionMedia * media,
gpointer user_data)
{
return GST_RTSP_FILTER_REMOVE;
}
static GstRTSPFilterResult session_remove(GstRTSPClient * client,
GstRTSPSession * sess,
gpointer user_data)
{
gst_rtsp_session_filter(sess, media_remove, nullptr);
return GST_RTSP_FILTER_REMOVE;
}
static void closed_callback (GstRTSPClient * self,
gpointer user_data)
{
GstRTSPConnection* connection = gst_rtsp_client_get_connection(self);
const std::string ipAddr = gst_rtsp_connection_get_ip(connection);
std::cerr << "client (" << ipAddr << ") closed" << std::endl;
gst_rtsp_client_session_filter(self, session_remove, nullptr);
gst_rtsp_client_close(self);
}
static void client_connected (GstRTSPServer * server, GstRTSPClient * client)
{
...
g_signal_connect(client, "closed", G_CALLBACK(closed_callback), nullptr);
...
}
void RtpToRtspserver::init()
{
//create rtsp server. By default it will listen connections on port 8554
mRtspserver = gst_rtsp_server_new();
//Set server signals and callbacks
g_signal_connect(mRtspserver, "client-connected", G_CALLBACK(client_connected), nullptr);
//set up monitoring callbacks
g_timeout_add_seconds(2, G_SOURCE_FUNC(cleanup_sessions), mRtspserver);
...
}
```https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/348Static linking on Windows2021-06-16T13:27:49ZIhor RanchynskyiStatic linking on WindowsI'm successfully compiling and running after I set `PKG_CONFIG_PATH`.
Setting `PKG_CONFIG_ALL_STATIC` or any library `_STATIC` seems to have no effect.
Am I missing something?I'm successfully compiling and running after I set `PKG_CONFIG_PATH`.
Setting `PKG_CONFIG_ALL_STATIC` or any library `_STATIC` seems to have no effect.
Am I missing something?https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/139RtspClientSink element Error2021-08-19T12:50:53ZEran BraunRtspClientSink element Error**rtspclientsink** crashes the pipeline after the sink location has crashed.
I have reproduced the issue with the following pipeline:
**gst-launch-1.0 videotestsrc ! queue ! x264enc ! rtspclientsink location=rtsp://{rtspserver_ip_}:{rt...**rtspclientsink** crashes the pipeline after the sink location has crashed.
I have reproduced the issue with the following pipeline:
**gst-launch-1.0 videotestsrc ! queue ! x264enc ! rtspclientsink location=rtsp://{rtspserver_ip_}:{rtspserver_port_}/{rtspserver_path_}**
and **Wowza** as an rtsp server for recording the stream.
Upon killing the Wowza engine service the pipeline has crashed indicating errors regarding the **rtspclientsink**:
**ERROR**: from element /GstPipeline:pipeline0/GstRTSPClientSink:rtspclientsink0: Could not write to resource.
**ERROR**: gst_rtsp_connection_connect_with_response_usec: failed to connect: Operation was cancelled
**ERROR**: gst_rtsp_conninfo_connect: Could not connect to server. (Operation interrupted)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1604nvcodec: Segment seeking without FLUSH flag leads to immediate SEGMENT_DONE a...2021-06-16T18:27:23ZTyler Comptonnvcodec: Segment seeking without FLUSH flag leads to immediate SEGMENT_DONE and memory leakI have a script that streams video from a file and decodes it, dumping the resulting frames into a `fakesink`.
I want the video to seamlessly loop, so I send a segment seek event to the pipeline once it hits the `PLAYING` state and sen...I have a script that streams video from a file and decodes it, dumping the resulting frames into a `fakesink`.
I want the video to seamlessly loop, so I send a segment seek event to the pipeline once it hits the `PLAYING` state and send another segment seek event whenever the `SEGMENT_DONE` message received by my bus watch. This script works fine using `avdec_h264` and `vaapih264dec`.
When running the script with `nvh264dec`, I see different behavior. When I send a seek event after the `SEGMENT_DONE` message, the pipeline immediately responds with another `SEGMENT_DONE` message. If I keep sending seek events in response, this causes a memory leak.
I found that adding the `FLUSH` seek flag to my seek event solves this problem, but this isn't necessary with other decoders. Especially considering the memory leak, this feels like a bug.
I've been able to reproduce this on multiple MP4/H.264 video files, but have not tested it on other container or encoding formats. I'd be happy to send an example video if it helps.
I have a reproducible example in Python [available as a Gist here](https://gist.github.com/velovix/b6021e72737228944b784978b97d0584), alongside the Dockerfile I reproduced this problem with in case that's helpful.
CC @seungha.yang who appears to be the resident expert. Thank you for taking a look!
Versions I've tested:
- GStreamer: 1.18.4 and 1.19.1
- Python: 3.6
- PyGObject: 3.40.1
- Cuda: 10.0 and 11.2
- OS: Ubuntu 18.04 via Dockerhttps://gitlab.freedesktop.org/gstreamer/gst-examples/-/issues/46SSL: WRONG_VERSION_NUMBER2021-06-21T07:33:29ZniwiSSL: WRONG_VERSION_NUMBERI have tried to run the webrtc/sendrecv/gst/webrtc_sendrecv.py example, but I am not able to get it to work.
All the sendrecv-gst containers (sendrecv-gst, sendrecv-gst-java, and sendrecv-gst-rust) fail to build, so I tried to start the ...I have tried to run the webrtc/sendrecv/gst/webrtc_sendrecv.py example, but I am not able to get it to work.
All the sendrecv-gst containers (sendrecv-gst, sendrecv-gst-java, and sendrecv-gst-rust) fail to build, so I tried to start the `sendrecv-js` and `signalling` containers using the webrtc/docker-compose.yml script (with all the sendrecv-gst containers disabled). Then I ran `python webrtc/sendrecv/gst/webrtc_sendrecv.py 1 --server=wss://127.0.0.1:8443`.
I got the following error, which (after some googling) seems to be related to server expecting TLS, while client offers SSL.
```
Traceback (most recent call last):
File "sendrecv/gst/webrtc_sendrecv.py", line 189, in <module>
loop.run_until_complete(c.connect())
File "/usr/lib/python3.6/asyncio/base_events.py", line 484, in run_until_complete
return future.result()
File "sendrecv/gst/webrtc_sendrecv.py", line 40, in connect
self.conn = await websockets.connect(self.server, ssl=sslctx)
File "/home/niwi/.local/lib/python3.6/site-packages/websockets/client.py", line 535, in __await_impl__
transport, protocol = await self._create_connection()
File "/usr/lib/python3.6/asyncio/base_events.py", line 820, in create_connection
sock, protocol_factory, ssl, server_hostname)
File "/usr/lib/python3.6/asyncio/base_events.py", line 846, in _create_connection_transport
yield from waiter
File "/usr/lib/python3.6/asyncio/sslproto.py", line 505, in data_received
ssldata, appdata = self._sslpipe.feed_ssldata(data)
File "/usr/lib/python3.6/asyncio/sslproto.py", line 201, in feed_ssldata
self._sslobj.do_handshake()
File "/usr/lib/python3.6/ssl.py", line 689, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:852)
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/708vaapi: ADL YOCTO Timestamping when rendering 8k AV1 video2022-11-10T09:21:07ZLi Ying Govaapi: ADL YOCTO Timestamping when rendering 8k AV1 videoSUT Information:
- Platform: ADL-S
- OS: Yocto
- Kernel: 5.10.35-intel-ese-standard-lts
Defect Description:
- Timestamping when rendering 8k AV1 video.
- No issue when decoding 8k AV1 video on MSDK.
Command and error:
GST-VAAPI:
`gst...SUT Information:
- Platform: ADL-S
- OS: Yocto
- Kernel: 5.10.35-intel-ese-standard-lts
Defect Description:
- Timestamping when rendering 8k AV1 video.
- No issue when decoding 8k AV1 video on MSDK.
Command and error:
GST-VAAPI:
`gst-launch-1.0 filesrc location=/media/AV1_Videos/Coastguard_7680x4320_3mbps_60fps_Main_at_L6.1.mkv ! matroskademux ! vaapiav1dec ! vaapipostproc ! glimagesink`
GST-MSDK:
`gst-launch-1.0 filesrc location=/media/AV1_Videos/Coastguard_7680x4320_3mbps_60fps_Main_at_L6.1.mkv ! matroskademux ! msdkav1dec async-depth=4 ! msdkvpp ! glimagesink`
root@intel-corei7-64:~# `gst-launch-1.0 filesrc location=/media/AV1_Videos/Coastguard_7680x4320_3mbps_60fps_Main_at_L6.1.mkv ! matroskademux ! msdkav1dec async-depth=4 ! msdkvpp ! glimagesink`
```
Setting pipeline to PAUSED ...
libva info: VA-API version 1.9.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_9
libva info: va_openDriver() returns 0
Pipeline is PREROLLING ...
Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";
Got context from element 'msdkvpp0': gst.msdk.Context=context, gst.msdk.Context=(GstMsdkContext)"\(GstMsdkContext\)\ msdkcontext0";
Redistribute latency...
Pipeline is PREROLLED ...0 %)
Setting pipeline to PLAYING ...
New clock: GstSystemClock
WARNING: from element /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink: A lot of buffers are being dropped.
Additional debug info:
../git/libs/gst/base/gstbasesink.c(3132): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
There may be a timestamping problem, or this computer is too slow.
WARNING: from element /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink: A lot of buffers are being dropped.
Additional debug info:
../git/libs/gst/base/gstbasesink.c(3132): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink:
There may be a timestamping problem, or this computer is too slow.
Got EOS from element "pipeline0".
Execution ended after 0:00:11.634939749
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/707Missing decoder: H.2652021-06-11T13:31:25ZArmin234Missing decoder: H.265Hi,
I'm new one gstreamer and i have a problem to extract the images from files created with ffmpeg. Launching the
gstreamer on my Win10 PC in with
gst-launch-1.0.exe filesrc location=F11.mov ! decodebin ! videoconvert ! video/x-raw,fo...Hi,
I'm new one gstreamer and i have a problem to extract the images from files created with ffmpeg. Launching the
gstreamer on my Win10 PC in with
gst-launch-1.0.exe filesrc location=F11.mov ! decodebin ! videoconvert ! video/x-raw,format=GRAY8 ! multifilesink location=u%d.bmp
I get following messages:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Missing element: H.265 decoder
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0: Your GStreamer installation is missing a plug-in.
Additional debug info:
../gst/playback/gstdecodebin2.c(4720): gst_decode_bin_expose (): /GstPipeline:pipeline0/GstDecodeBin:decodebin0:
no suitable plugins found:
Missing decoder: H.265 (video/x-h265, stream-format=(string)byte-stream, alignment=(string)au, level=(string)5, tier=(string)main, profile=(string)monochrome, width=(int)2464, height=(int)2056, framerate=(fraction)25/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, chroma-format=(string)4:0:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)0, parsed=(boolean)true)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
Is there any work around / decoder that I Can use ?
Regards
Arminhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/897rtph265depay: "gst_debug_log_valist: assertion 'category != NULL' failed"2021-10-01T08:38:38ZChatPionrtph265depay: "gst_debug_log_valist: assertion 'category != NULL' failed"The following pipelines
`gst-launch-1.0 videotestsrc ! x265enc ! rtph265pay config-interval=1 pt=96 ! udpsink host=127.0.0.1 port=1234`
and
`GST_DEBUG=3 gst-launch-1.0 udpsrc port=1234 caps="application/x-rtp,encoding-name=H265,payload...The following pipelines
`gst-launch-1.0 videotestsrc ! x265enc ! rtph265pay config-interval=1 pt=96 ! udpsink host=127.0.0.1 port=1234`
and
`GST_DEBUG=3 gst-launch-1.0 udpsrc port=1234 caps="application/x-rtp,encoding-name=H265,payload=96" ! rtph265depay ! h265parse ! avdec_h265 ! queue ! autovideoconvert ! autovideosink`
give me errors like
`(gst-launch-1.0:29447): GStreamer-CRITICAL **: 11:03:01.909: gst_debug_log_valist: assertion 'category != NULL' failed`
I suspect these errors are due to `rth265depay`.
Tested on master.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/915Sharpness property of videoscale element doesn't work2021-09-24T13:26:24ZAleksandr MuravjovSharpness property of videoscale element doesn't workWondered that sharpness doesn't work for a simple pipelines.
Gstreamer version - 1.18.4 as well as 1.14.5.
Pipelines:
```
gst-launch-1.0 videotestsrc ! videoscale sharpness=0.5 ! autovideosink
gst-launch-1.0 videotestsrc ! videoscale sha...Wondered that sharpness doesn't work for a simple pipelines.
Gstreamer version - 1.18.4 as well as 1.14.5.
Pipelines:
```
gst-launch-1.0 videotestsrc ! videoscale sharpness=0.5 ! autovideosink
gst-launch-1.0 videotestsrc ! videoscale sharpness=1 ! autovideosink
gst-launch-1.0 videotestsrc ! videoscale sharpness=1.5 ! autovideosink
```
produce the same image.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/914Some GstAppSink functions have incorrect return nullability in Vala2021-06-30T20:14:15ZMichael de GansSome GstAppSink functions have incorrect return nullability in Vala[In Vala, `GstAppSink.pull_sample()`](https://valadoc.org/gstreamer-app-1.0/Gst.App.Sink.pull_sample.html) and some other fucntions specify non-nullable `Gst.Sample` in the docs and bindings when in reality, the return is nullable and sh...[In Vala, `GstAppSink.pull_sample()`](https://valadoc.org/gstreamer-app-1.0/Gst.App.Sink.pull_sample.html) and some other fucntions specify non-nullable `Gst.Sample` in the docs and bindings when in reality, the return is nullable and should be `Gst.Sample?`. I'm not very familiar with GObject annotations but perhaps the problem lies there?
Valac version is `Vala 0.40.23`
Meson version is `0.57.2`
GStreamer version is `1.14.5`
Platform is aarch64 Ubuntu 18.04 (Linux for Tegra)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/896rtpac3depay: source caps only allow "audio/ac3", not "audio/x-ac3"2023-10-12T16:22:33ZAbleBaconrtpac3depay: source caps only allow "audio/ac3", not "audio/x-ac3"The sink caps for `rtpac3pay` (the AC3 payloader) have both `audio/ac3` and `audio/x-ac3`:
```
SINK template: 'sink'
Availability: Always
Capabilities:
audio/ac3
audio/x-ac3
```
The source caps for `rtpac3depay` (t...The sink caps for `rtpac3pay` (the AC3 payloader) have both `audio/ac3` and `audio/x-ac3`:
```
SINK template: 'sink'
Availability: Always
Capabilities:
audio/ac3
audio/x-ac3
```
The source caps for `rtpac3depay` (the AC3 depayloader) only allow `audio/ac3`:
```
SRC template: 'src'
Availability: Always
Capabilities:
audio/ac3
```
The source caps for the depayloader (`rtpac3depay`) should also include `audio/x-ac3`. The capability for `audio/x-ac3` is important because the FFMPEG AC3 plugins only accept `audio/x-ac3`, not `audio/ac3`. Also, conceptually, the depayloader should be able to reverse any payloading that the payloader does.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/154rsaudioloudnorm shows no effect2021-06-16T15:48:45ZRico Beierrsaudioloudnorm shows no effectHi,
I am trying to normalize an audio-clip for gstreamer editing services (ges); but it seems not to work.
```rust
let clp_audio = UriClip::new(&format!("file://test.flac"))?;
clp_audio.set_start(time);
clp_audio.add(&Effect::new("volu...Hi,
I am trying to normalize an audio-clip for gstreamer editing services (ges); but it seems not to work.
```rust
let clp_audio = UriClip::new(&format!("file://test.flac"))?;
clp_audio.set_start(time);
clp_audio.add(&Effect::new("volume volume=0.5 ! volume volume=0.5")?)?; // turn volume down
clp_audio.add(&Effect::new("audioresample ! rsaudioloudnorm ! audioresample ! capsfilter caps=audio/x-raw,rate=48000")?)?; // should be louder afterwards, but rsaudioloudnorm has no effect
l.add_clip(&clp_audio)?;
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1603Update NVENC API to version 11.02023-05-30T16:11:29ZAntonio OspiteUpdate NVENC API to version 11.0Hi,
currently the nvenc elements support NVENC API version 9.1:
```
0:00:00.031951941 25312 0x258fcc0 INFO nvenc gstnvenc.c:936:gst_nvenc_load_library: Maximum supported API version by driver: 11.0
0:00:00.031979...Hi,
currently the nvenc elements support NVENC API version 9.1:
```
0:00:00.031951941 25312 0x258fcc0 INFO nvenc gstnvenc.c:936:gst_nvenc_load_library: Maximum supported API version by driver: 11.0
0:00:00.031979879 25312 0x258fcc0 INFO nvenc gstnvenc.c:954:gst_nvenc_load_library: API version 9.1 load done
```
As per https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/sys/nvcodec/nvEncodeAPI.h#L113-114
Would it be possible to update the code to access functionalities from API 11.0?
In particular I would eventually be interested in encoding HEVC with an alpha channel as defined in https://developer.apple.com/av-foundation/HEVC-Video-with-Alpha-Interoperability-Profile.pdf which apparently is supported in the Video Codec SDK 11.0, like suggested in https://docs.nvidia.com/video-technologies/video-codec-sdk/nvenc-application-note/index.html#nvenc-capabilities__table-whats-new
I don't have access to the NVIDIA Video Codec SDK but I found a more recent `nvEncodeAPI.h` in https://github.com/johnhe4/nvenc_h265_transparency and I see it has been updated also in https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
After dropping the updated `nvEncodeAPI.h` over the current one in gst-plugins-bad the code still compiles but there are some deprecation warnings so I'd prefer someone more experienced with nvcodec to take a look, or at least provide some guidance about the update process, cc @seungha.yang
Thanks a lot,
Antonio