GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-09-19T20:13:58Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/405How would one adapt the gtksink example to play from http sources?2022-09-19T20:13:58ZAgentBillyHow would one adapt the gtksink example to play from http sources?I know basically nothing about gstreamer.
I do know that in the command line the following will play a video from a http source
```
gst-launch-1.0 souphttpsrc location=http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/Big...I know basically nothing about gstreamer.
I do know that in the command line the following will play a video from a http source
```
gst-launch-1.0 souphttpsrc location=http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4 ! decodebin ! autovideosink
```
from that, I assumed you would change
```rust
let src = gstreamer::ElementFactory::make("videotestsrc", None).unwrap();
```
to
```rust
let src = gstreamer::ElementFactory::make("souphttpsrc", None).unwrap();
src.set_property("location", "http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4");
```
But where you go from there, I have no idea.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1446Importing existing D3D11 textures in d3d11 elements as optimization2022-09-16T17:32:52ZNoTuxNoBuxImporting existing D3D11 textures in d3d11 elements as optimizationI'm using the D3D11 GStreamer elements successfully in a Unity application to copy data from a simple RGBA pixel buffer into GStreamer through an `appsrc`, and uploading it through `d3d11upload` to later profit from hardware-accelerated ...I'm using the D3D11 GStreamer elements successfully in a Unity application to copy data from a simple RGBA pixel buffer into GStreamer through an `appsrc`, and uploading it through `d3d11upload` to later profit from hardware-accelerated h.264 encoding using `mfh264enc` (which also supports D3D11 textures).
Unity on Windows can use D3D11 for rendering itself, where I [can get direct access to said texture](https://docs.unity3d.com/ScriptReference/Texture.GetNativeTexturePtr.html) (`ID3D11Resource*`), and I was wondering if such a texture pointer can be directly passed to one of the D3D11 plugins as an optimization to avoid the copy.
In other words: I'm currently downloading the Unity GPU texture to system memory, to later upload it again for GStreamer.
I took a look at the source code, and the plugins use caps `video/x-raw(memory:D3D11Memory)` for this, but it appears structures such as `GstD3D11Memory`, which end up wrapping the `ID3D11Resource`, are not publicly exposed for development, so it is not clear to me if it is currently possible (without mimicking said structures manually) to provide the right data to the existing elements from my `appsrc`. I may be missing something here, though.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1444wavparse: Runs all typefinders for all output2022-11-15T16:01:00ZEdward Herveywavparse: Runs all typefinders for all outputIntroduced by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/754f3a315ba37a523cbe114614cb32d666c02abe 12 years ago :smile:
In order to figure out if the "raw" audio contained within the wav container is actually DTS, `wavp...Introduced by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/754f3a315ba37a523cbe114614cb32d666c02abe 12 years ago :smile:
In order to figure out if the "raw" audio contained within the wav container is actually DTS, `wavparse` calls the typefinder helper ... except that means it runs *all* typefinders.
Since it only cares about checking for DTS, it should only run the `audio/x-dts` typefinder (if present).https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/245threadshare: ts-jitterbuffer emits request-pt-map without declaring2022-09-21T11:31:08ZMac Thi Kieu Vanthreadshare: ts-jitterbuffer emits request-pt-map without declaringAn issue was found with error log: "Emitting 'request-pt-map': Signal 'request-pt-map' of type 'RsTsJitterBuffer' not found"
```
0:00:26.271047760 29741 0x7f60d0001e00 LOG ts-jitterbuffer generic/threadshare/src/jitterbuffer/imp...An issue was found with error log: "Emitting 'request-pt-map': Signal 'request-pt-map' of type 'RsTsJitterBuffer' not found"
```
0:00:26.271047760 29741 0x7f60d0001e00 LOG ts-jitterbuffer generic/threadshare/src/jitterbuffer/imp.rs:344:gstthreadshare::jitterbuffer::imp:<RTP_jitter_buffer_1_2> Storing buffer, seq: 7919, rtptime: 1713120, pt: 101
0:00:26.271061470 29741 0x7f60d0001e00 DEBUG ts-jitterbuffer generic/threadshare/src/jitterbuffer/imp.rs:377:gstthreadshare::jitterbuffer::imp:<RTP_jitter_buffer_1_2:sink> New payload type: 101
0:00:26.271074817 29741 0x7f60d0001e00 TRACE GST_REFCOUNTING gstminiobject.c:466:gst_mini_object_ref: 0x7f60d0017800 ref 2->3
0:00:26.271100783 29741 0x7f60d0001e00 DEBUG GST_CAPS gstpad.c:2733:gst_pad_get_current_caps:<RTP_jitter_buffer_1_2:sink> get current pad caps application/x-rtp, media=(string)audio, clock-rate=(int)8000, encoding-name=(string)G729, payload=(int)18
0:00:26.271130238 29741 0x7f60d0001e00 DEBUG ts-jitterbuffer generic/threadshare/src/jitterbuffer/imp.rs:184:gstthreadshare::jitterbuffer::imp:<RTP_jitter_buffer_1_2> Parsing Caps("application/x-rtp, media=(string)audio, clock-rate=(int)8000, encoding-name=(string)G729, payload=(int)18")
0:00:26.271148752 29741 0x7f60d0001e00 DEBUG ts-jitterbuffer generic/threadshare/src/jitterbuffer/imp.rs:192:gstthreadshare::jitterbuffer::imp:<RTP_jitter_buffer_1_2> Caps 'payload' (18) doesn't match payload type (101)
0:00:26.271159809 29741 0x7f60d0001e00 TRACE GST_REFCOUNTING gstminiobject.c:648:gst_mini_object_unref: 0x7f60d0017800 unref 3->2
0:00:26.271188718 29741 0x7f60d0001e00 ERROR ts-jitterbuffer generic/threadshare/src/jitterbuffer/imp.rs:393:gstthreadshare::jitterbuffer::imp:<RTP_jitter_buffer_1_2:sink> Emitting 'request-pt-map': Signal 'request-pt-map' of type 'RsTsJitterBuffer' not found
```
The source code of the jitterbuffer shows that it not declare this "request-pt-map" signal yet.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/generic/threadshare/src/jitterbuffer/imp.rs#L1409https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/978gstreamer destory EGLDisplay when application is using it2023-07-18T15:36:49Zshang qianggstreamer destory EGLDisplay when application is using itwe have a QML player application
[QMLTest.tgz](/uploads/9a953406fa3f0aaf561e85db59cb0eed/QMLTest.tgz)
when stop the video player ,screen will freeze(with wayland desktop)
this application has two issue:
1. gstreamer destory the qt's ...we have a QML player application
[QMLTest.tgz](/uploads/9a953406fa3f0aaf561e85db59cb0eed/QMLTest.tgz)
when stop the video player ,screen will freeze(with wayland desktop)
this application has two issue:
1. gstreamer destory the qt's EGLDisplay
2. the the wayland server will not send ping pong ,when switch to the background and swich back
with the first issue:
```
diff --git a/gst-libs/gst/gl/egl/gstgldisplay_egl.c b/gst-libs/gst/gl/egl/gstgldisplay_egl.c
index 8eb53a2d5..ad6beae88 100644
--- a/gst-libs/gst/gl/egl/gstgldisplay_egl.c
+++ b/gst-libs/gst/gl/egl/gstgldisplay_egl.c
@@ -298,7 +298,7 @@ gst_gl_display_egl_from_gl_display (GstGLDisplay * display)
ret->display =
gst_gl_display_egl_get_from_native (display_type, native_display);
-
+ ret->foreign_display = true;
if (!ret->display) {
GST_WARNING_OBJECT (ret, "failed to get EGLDisplay from native display");
gst_object_unref (ret);
```
1 i use this to fix the issue ,why we cancel this fix ?
: https://gitlab.freedesktop.org/dylanmccall/gst-plugins-base/-/commit/f9135c64bd6d2aa2310e8ed7d8a7b695ecf47e2c
2 how can i use this function gst_gl_display_egl_set_foreign_display?https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/106gst_base_sink_get_stats documentation is misleading2022-09-15T09:11:57ZRares Branicigst_base_sink_get_stats documentation is misleadingThe documentation for GstBaseSink / gst_base_sink_get_stats at
https://gstreamer.freedesktop.org/documentation/base/gstbasesink.html?gi-language=c#gst_base_sink_get_stats
says
"average-rate" G_TYPE_DOUBLE **average frame rate**,
sugg...The documentation for GstBaseSink / gst_base_sink_get_stats at
https://gstreamer.freedesktop.org/documentation/base/gstbasesink.html?gi-language=c#gst_base_sink_get_stats
says
"average-rate" G_TYPE_DOUBLE **average frame rate**,
suggesting the property can be used to get the video frame rate, for example.
Playing a file with 30000/1001 frame rate, the values reported vary between 0.11 and 0.17.
fpsdisplaysink does not use frame-stats.
Perhaps the documentation could be more precise as to the meaning and intent of this property.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/401ci: Only run manually and make use of the merge bot2022-11-27T17:59:28ZSebastian Drögeci: Only run manually and make use of the merge botShould get basically the same configuration as the monorepo. Same applies to gstreamer-rs / gst-plugins-rs.
CC @alatieraShould get basically the same configuration as the monorepo. Same applies to gstreamer-rs / gst-plugins-rs.
CC @alatieraJordan PetridіsJordan Petridіshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1442fakevideosink: should not install properties at instance init2023-06-02T19:49:08ZMathieu Duponchellefakevideosink: should not install properties at instance initThis forces us to instantiate the object before looking up its properties as part of https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3026 , and is quite uglyThis forces us to instantiate the object before looking up its properties as part of https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3026 , and is quite uglyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1441nvh265sldec: Empty RefPicSetStCurrBefore error after frame loss ; width=752, ...2022-09-16T21:49:10ZJacob Teplitskynvh265sldec: Empty RefPicSetStCurrBefore error after frame loss ; width=752, height=480@seungha.yang I've cloned today gstreamer with your fix commit c91d72e6 . But I still have errors after packet loss.
The problem happens only if I use nvh265sldec and width=752, height=480
If I use avdec_h265, no problem. If I don't...@seungha.yang I've cloned today gstreamer with your fix commit c91d72e6 . But I still have errors after packet loss.
The problem happens only if I use nvh265sldec and width=752, height=480
If I use avdec_h265, no problem. If I don't specify width=752, height=480 . no problem.
FYI , I'm also using https://github.com/EricssonResearch/scream/tree/master/gstscream .
Sender :
Pipeline: videotestsrc is-live=true pattern=snow ! videoconvertscale ! video/x-raw, format=NV12, framerate=20/1, width=752, height=480 ! nvh265enc name=video zerolatency=true preset=low\
-latency-hq rc-mode=cbr-ld-hq gop-size=-1 bitrate=500 ! queue max-size-buffers=2 max-size-bytes=0 max-size-time=0 ! rtph265pay ssrc=1 config-interval=-1 ! queue max-size-buffers=2 max-siz\
e-bytes=0 max-size-time=0 ! screamtx name="screamtx" params=" -forceidr -ect 1 -initrate 500 -minrate 500 -maxrate 40000 " ! udpsink host=192.168.1.10 port=30112 sync=false rtpbin n\
ame=r udpsrc port=30112 address=192.168.1.25 ! queue ! screamtx.rtcp_sink screamtx.rtcp_src ! r.recv_rtcp_sink_0
Receiver:
ECVPIPELINE=rtpbin latency=10 name=rtpbin udpsrc port=30112 address=192.168.1.10 ! queue max-size-buffers=2 max-size-bytes=0 max-size-time=0 ! screamrx name=screamrx screamrx.src ! appli\
cation/x-rtp, media=video, encoding-name=H265, clock-rate=90000 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph265depay ! h265parse ! nvh265sldec name=videodecoder ! queue max-size-buffers=2 max-s\
ize-bytes=0 max-size-time=0 ! glupload ! glcolorconvert ! fpsdisplaysink video-sink="glimagesinkelement" rtpbin.send_rtcp_src_0 ! funnel name=f ! queue max-size-buffers=2 max-size-bytes=0 \
max-size-time=0 ! udpsink host=192.168.1.25 port=30112 sync=false async=false screamrx.rtcp_src ! f.
(scream_receiver:582751): GStreamer-WARNING **: 11:07:09.269: ../subprojects/gstreamer/gst/gstpad.c:5352:store_sticky_event:<f:src> Sticky event misordering, got 'segment' before 'caps'
(scream_receiver:582751): GStreamer-WARNING **: 11:07:09.269: ../subprojects/gstreamer/gst/gstpad.c:5352:store_sticky_event:<queue2:sink> Sticky event misordering, got 'segment' before 'ca\
ps'
(scream_receiver:582751): GStreamer-WARNING **: 11:07:09.269: ../subprojects/gstreamer/gst/gstpad.c:5352:store_sticky_event:<queue2:src> Sticky event misordering, got 'segment' before 'cap\
s'
(scream_receiver:582751): GStreamer-WARNING **: 11:07:09.269: ../subprojects/gstreamer/gst/gstpad.c:5352:store_sticky_event:<udpsink0:sink> Sticky event misordering, got 'segment' before '\
caps'
0:02:09.431902539 582751 0x7f66340090c0 ERROR nvh265dec gstnvh265dec.c:842:gst_nv_h265_dec_start_picture:<videodecoder> Empty RefPicSetStCurrBefore[0]
0:02:09.455129067 582751 0x7f66340090c0 ERROR nvh265dec gstnvh265dec.c:842:gst_nv_h265_dec_start_picture:<videodecoder> Empty RefPicSetStCurrBefore[0]
0:02:09.471591765 582751 0x7f66340090c0 ERROR nvh265dec gstnvh265dec.c:842:gst_nv_h265_dec_start_picture:<videodecoder> Empty RefPicSetStCurrBefore[0]
0:02:09.491998034 582751 0x7f66340090c0 ERROR nvh265dec gstnvh265dec.c:842:gst_nv_h265_dec_start_picture:<videodecoder> Empty RefPicSetStCurrBefore[0]
0:02:09.561039462 582751 0x7f66340090c0 ERROR nvh265dec gstnvh265dec.c:842:gst_nv_h265_dec_start_picture:<videodecoder> Empty RefPicSetStCurrBefore[0]
0:02:09.599110876 582751 0x7f66340090c0 ERROR nvh265dec gstnvh265dec.c:842:gst_nv_h265_dec_start_picture:<videodecoder> Empty RefPicSetStCurrBefore[0]
0:02:09.681386484 582751 0x7f66340090c0 ERROR nvh265dec gstnvh265dec.c:842:gst_nv_h265_dec_start_picture:<videodecoder> Empty RefPicSetStCurrBefore[0]
0:02:09.695690427 582751 0x7f66340090c0 ERROR nvh265dec gstnvh265dec.c:842:gst_nv_h265_dec_start_picture:<videodecoder> Empty RefPicSetStCurrBefore[0]
0:02:09.729403642 582751 0x7f66340090c0 ERROR nvh265dec gstnvh265dec.c:842:gst_nv_h265_dec_start_picture:<videodecoder> Empty RefPicSetStCurrBefore[0]
0:02:09.781125201 582751 0x7f66340090c0 ERROR nvh265dec gstnvh265dec.c:842:gst_nv_h265_dec_start_picture:<videodecoder> Empty RefPicSetStCurrBefore[0]
0:02:09.833923003 582751 0x7f66340090c0 ERROR nvh265dec gstnvh265dec.c:842:gst_nv_h265_dec_start_picture:<videodecoder> Empty RefPicSetStCurrBefore[0]
### error from Some("/GstPipeline:pipeline0/GstNvH265SLDec:videodecoder"): Failed to decode data (Some("../subprojects/gst-plugins-bad/gst-libs/gst/codecs/gsth265decoder.c(1987): gst_h265_\
decoder_handle_frame (): /GstPipeline:pipeline0/GstNvH265SLDec:videodecoder"))https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1734CPU consumption is reaching 100% with very one RTSP stream2022-11-16T10:53:42ZChandramouli PCPU consumption is reaching 100% with very one RTSP streamHello,
Good evening. Please find the below environment:
Operating System: Ubuntu 22.04 Server edition
GStreamer: 1.20.3
We are trying to render the RTSP stream that is coming from an IP camera on to a web browser using GStreamer and W...Hello,
Good evening. Please find the below environment:
Operating System: Ubuntu 22.04 Server edition
GStreamer: 1.20.3
We are trying to render the RTSP stream that is coming from an IP camera on to a web browser using GStreamer and WebRTCBin plugin. We followed the below URL and able to render the stream successfully:
**https://gitlab.freedesktop.org/gstreamer/gst-examples/-/tree/discontinued-for-monorepo/webrtc**
But, I noticed that CPU consumption is reaching to 100% with only one RTSP stream. Please find the enclosed screenshot for your reference.
![image](/uploads/bc284c9f28927b532afe9e2cdf0cbb6f/image.png)
Hence, request you to help us in resolving the load issue.
Thank you.
Best Regards,
Chandramouli.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1733SSL Issue with Signaling module (GStreamer + WebRTC + Signaling)2023-05-16T03:38:39ZChandramouli PSSL Issue with Signaling module (GStreamer + WebRTC + Signaling)Hello,
Good evening. Please find the below environment:
Operating System: Ubuntu 22.04 Server edition
GStreamer: 1.20.3
We are trying to render the RTSP stream that is coming from an IP camera on to a web browser using GStreamer and ...Hello,
Good evening. Please find the below environment:
Operating System: Ubuntu 22.04 Server edition
GStreamer: 1.20.3
We are trying to render the RTSP stream that is coming from an IP camera on to a web browser using GStreamer and WebRTCBin plugin. We followed the below URL:
**https://gitlab.freedesktop.org/gstreamer/gst-examples/-/tree/discontinued-for-monorepo/webrtc**
We are able to render the stream successfully with http and https with the FQDN that is used in the source code (https://webrtc.nirbheek.in).
But, when we are using our own FQDN, SSL is not working. We generated SSL certificates (.pem files) using letsencrypt and placed in gst-examples/webrtc/signalling folder. Also, replaced the default FQDN i.e. webrtc.nirbheek.in with our FQDN in gst-examples/webrtc/sendrecv/gst/webrtc-sendrecv.c file as below:
Replaced static const gchar *server_url = "wss://webrtc.nirbheek.in:8443" as
static const gchar *server_url = "wss://abc.def.in:8443";
But, https is not working. Please suggest that do we need to change anything and anywhere else with respect to our FQDN?
Thank you.
Best Regards,
Chandramouli.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1440webrtcbin: ICE connection takes ~2 seconds to move from checking to connected2022-10-14T14:58:12ZChris Wigginswebrtcbin: ICE connection takes ~2 seconds to move from checking to connectedI'm trying to narrow down why our WebRTC connections take ~2 seconds to complete however I'm coming up short. Running GStreamer 1.20.3
We have implemented a GStreamer pipeline in Python with a coturn server set as the WebRTC TURN server...I'm trying to narrow down why our WebRTC connections take ~2 seconds to complete however I'm coming up short. Running GStreamer 1.20.3
We have implemented a GStreamer pipeline in Python with a coturn server set as the WebRTC TURN server. From our logs (as below - logging on element state change), we can see it takes about ~2 seconds from getting the answer from janus to the connection completing. Essentially the exact same config on the browser, which connects almost instantaneously.
Any pointers as to what I can look into and why this takes a while to complete? We don't do trickle ice, we wait for all candidates to be gathered before sending the offer, and then the answer contains all candidates too. You can see that the candidates are gathered super quick, but after going into the CHECKING connection state, it takes 2s before the funnel is then set up and the pipeline continues
```
2022-09-14 13:11:17,574 - src.elements.webrtc - INFO - Gathering ICE...
2022-09-14 13:11:17,665 - src.elements.webrtc - INFO - Got Ice Candidate candidate:25 1 UDP 337641727 172.18.0.20 54167 typ relay raddr 10.1.1.77 rport 9
2022-09-14 13:11:17,738 - src.elements.webrtc - INFO - Gathering ICE Complete
2022-09-14 13:11:17,738 - src.elements.webrtc - INFO - Sending offer after gathering ICE
2022-09-14 13:11:17,739 - src.signalling - INFO - Sending offer
2022-09-14 13:11:17,739 - socketio.client - INFO - Emitting event "transcoder:streamEvent" [/]
2022-09-14 13:11:17,740 - engineio.client - INFO - Sending packet MESSAGE data 2["transcoder:streamEvent",{"jsep":{"type":"offer","sdp":"v=0\r\no=- 5447281297030345240 0 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=ice-options:trickle\r\na=group:BUNDLE video0\r\nm=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100\r\nc=IN IP4 0.0.0.0\r\na=setup:actpass\r\na=ice-ufrag:DkyQDFCOwnanmALqDGJ9+pWuprNayvcs\r\na=ice-pwd:HbDlmlqEdVQd72Ke7YBTP0mpDPQvttQu\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=sendonly\r\na=rtpmap:96 H264/90000\r\na=rtcp-fb:96 nack\r\na=rtcp-fb:96 nack pli\r\na=rtcp-fb:96 transport-cc\r\na=framerate:25\r\na=fmtp:96 packetization-mode=1;sprop-parameter-sets=Z00AKZpnA8ARPy4C3AQEBQAAAwPoAADDUOhgAP78AAP75rvLjQwAH9+AAH9813lwoA==,aO48gA==;profile-level-id=4d0029;level-asymmetry-allowed=1\r\na=rtpmap:97 red/90000\r\na=rtpmap:98 ulpfec/90000\r\na=rtpmap:99 rtx/90000\r\na=fmtp:99 apt=97\r\na=rtpmap:100 rtx/90000\r\na=fmtp:100 apt=96\r\na=ssrc-group:FID 550766102 480361981\r\na=ssrc:550766102 msid:user3017390952@host-f37ba75a webrtctransceiver0\r\na=ssrc:550766102 cname:user3017390952@host-f37ba75a\r\na=ssrc:480361981 msid:user3017390952@host-f37ba75a webrtctransceiver0\r\na=ssrc:480361981 cname:user3017390952@host-f37ba75a\r\na=mid:video0\r\na=fingerprint:sha-256 68:E6:29:0C:B1:31:CE:DA:45:BB:9B:B3:38:2D:9D:FE:F7:AD:82:C4:58:4E:64:AA:91:9E:FC:3A:4C:05:6C:C6\r\na=rtcp-mux-only\r\na=candidate:25 1 UDP 337641727 172.18.0.20 54167 typ relay raddr 10.1.1.77 rport 9\r\n","trickle":false},"streamId":"0583e567874945a3bd816f77aa5adcd8","type":"streamOffer"}]
2022-09-14 13:11:17,817 - engineio.client - INFO - Received packet MESSAGE data 2["transcoder:streamAnswer",{"handleId":4298755108933040,"jsep":{"type":"answer","sdp":"v=0\r\no=- 1663117877744549 1 IN IP4 172.18.0.19\r\ns=VideoRoom 0583e567874945a3bd816f77aa5adcd8\r\nt=0 0\r\na=group:BUNDLE video0\r\na=ice-options:trickle\r\na=fingerprint:sha-256 E0:20:FB:D3:48:87:91:C9:90:C4:97:51:BE:9C:9A:DA:4B:5E:4C:0D:1E:96:29:7B:B2:76:C8:0F:01:EF:88:B0\r\na=extmap-allow-mixed\r\na=msid-semantic: WMS janus\r\nm=video 9 UDP/TLS/RTP/SAVPF 96 100\r\nc=IN IP4 172.18.0.19\r\na=recvonly\r\na=mid:video0\r\na=rtcp-mux\r\na=ice-ufrag:M/y0\r\na=ice-pwd:4V2R0b3bbDo7TVfXw5J8dv\r\na=ice-options:trickle\r\na=setup:active\r\na=rtpmap:96 H264/90000\r\na=rtcp-fb:96 ccm fir\r\na=rtcp-fb:96 nack\r\na=rtcp-fb:96 nack pli\r\na=rtcp-fb:96 goog-remb\r\na=rtcp-fb:96 transport-cc\r\na=fmtp:96 packetization-mode=1;sprop-parameter-sets=Z00AKZpnA8ARPy4C3AQEBQAAAwPoAADDUOhgAP78AAP75rvLjQwAH9+AAH9813lwoA==,aO48gA==;profile-level-id=4d0029;level-asymmetry-allowed=1\r\na=rtpmap:100 rtx/90000\r\na=fmtp:100 apt=96\r\na=msid:janus janusvideo0\r\na=ssrc:2150183323 cname:janus\r\na=ssrc:2520873591 cname:janus\r\na=candidate:1 1 udp 2015363327 172.18.0.19 39961 typ host\r\na=candidate:1 1 udp 2015363327 172.18.0.19 39961 typ host\r\na=candidate:1 1 udp 2015363327 1.1.1.1 39961 typ host\r\na=end-of-candidates\r\n"},"server":"development","sessionId":6249999229949083,"streamId":"0583e567874945a3bd816f77aa5adcd8"}]
2022-09-14 13:11:17,818 - socketio.client - INFO - Received event "transcoder:streamAnswer" [/]
2022-09-14 13:11:17,818 - src.signalling - INFO - Received answer
2022-09-14 13:11:17,819 - src.elements.webrtc - DEBUG - Received answer:
{'handleId': 4298755108933040, 'jsep': {'type': 'answer', 'sdp': 'v=0\r\no=- 1663117877744549 1 IN IP4 172.18.0.19\r\ns=VideoRoom 0583e567874945a3bd816f77aa5adcd8\r\nt=0 0\r\na=group:BUNDLE video0\r\na=ice-options:trickle\r\na=fingerprint:sha-256 E0:20:FB:D3:48:87:91:C9:90:C4:97:51:BE:9C:9A:DA:4B:5E:4C:0D:1E:96:29:7B:B2:76:C8:0F:01:EF:88:B0\r\na=extmap-allow-mixed\r\na=msid-semantic: WMS janus\r\nm=video 9 UDP/TLS/RTP/SAVPF 96 100\r\nc=IN IP4 172.18.0.19\r\na=recvonly\r\na=mid:video0\r\na=rtcp-mux\r\na=ice-ufrag:M/y0\r\na=ice-pwd:4V2R0b3bbDo7TVfXw5J8dv\r\na=ice-options:trickle\r\na=setup:active\r\na=rtpmap:96 H264/90000\r\na=rtcp-fb:96 ccm fir\r\na=rtcp-fb:96 nack\r\na=rtcp-fb:96 nack pli\r\na=rtcp-fb:96 goog-remb\r\na=rtcp-fb:96 transport-cc\r\na=fmtp:96 packetization-mode=1;sprop-parameter-sets=Z00AKZpnA8ARPy4C3AQEBQAAAwPoAADDUOhgAP78AAP75rvLjQwAH9+AAH9813lwoA==,aO48gA==;profile-level-id=4d0029;level-asymmetry-allowed=1\r\na=rtpmap:100 rtx/90000\r\na=fmtp:100 apt=96\r\na=msid:janus janusvideo0\r\na=ssrc:2150183323 cname:janus\r\na=ssrc:2520873591 cname:janus\r\na=candidate:1 1 udp 2015363327 172.18.0.19 39961 typ host\r\na=candidate:1 1 udp 2015363327 172.18.0.19 39961 typ host\r\na=candidate:1 1 udp 2015363327 1.1.1.1 39961 typ host\r\na=end-of-candidates\r\n'}, 'server': 'development', 'sessionId': 6249999229949083, 'streamId': '0583e567874945a3bd816f77aa5adcd8'}
2022-09-14 13:11:17,819 - src.elements.webrtc - INFO - Setting up sessionId keepalive for 6249999229949083
2022-09-14 13:11:17,828 - src.app - DEBUG - Element rtpfunnel0 going from GST_STATE_NULL to GST_STATE_READY
2022-09-14 13:11:17,828 - src.app - DEBUG - Element rtpfunnel0 going from GST_STATE_READY to GST_STATE_PAUSED
2022-09-14 13:11:17,829 - src.app - DEBUG - Element rtpfunnel0 going from GST_STATE_PAUSED to GST_STATE_PLAYING
2022-09-14 13:11:17,829 - src.app - DEBUG - Element queue3 going from GST_STATE_NULL to GST_STATE_READY
2022-09-14 13:11:17,830 - src.app - DEBUG - (type=<enum GST_STREAM_STATUS_TYPE_CREATE of type Gst.StreamStatusType>, owner=<__gi__.GstQueue object at 0x7f88ecf98240 (GstQueue at 0x7f88d018c9d0)>)
2022-09-14 13:11:17,830 - src.app - DEBUG - (type=<enum GST_STREAM_STATUS_TYPE_ENTER of type Gst.StreamStatusType>, owner=<__gi__.GstQueue object at 0x7f88ecf98240 (GstQueue at 0x7f88d018c9d0)>)
2022-09-14 13:11:17,831 - src.app - DEBUG - Element queue3 going from GST_STATE_READY to GST_STATE_PAUSED
2022-09-14 13:11:17,831 - src.app - DEBUG - Element queue3 going from GST_STATE_PAUSED to GST_STATE_PLAYING
2022-09-14 13:11:17,832 - src.app - DEBUG - Element rtprtxsend0 going from GST_STATE_NULL to GST_STATE_READY
2022-09-14 13:11:17,833 - src.app - DEBUG - Element bin0 going from GST_STATE_NULL to GST_STATE_READY
2022-09-14 13:11:17,834 - src.app - DEBUG - (type=<enum GST_STREAM_STATUS_TYPE_CREATE of type Gst.StreamStatusType>, owner=<__gi__.GstRtpRtxSend object at 0x7f88ecfdfdc0 (GstRtpRtxSend at 0x7f88dc186000)>)
2022-09-14 13:11:17,834 - src.app - DEBUG - Element rtprtxsend0 going from GST_STATE_READY to GST_STATE_PAUSED
2022-09-14 13:11:17,835 - src.app - DEBUG - Element bin0 going from GST_STATE_READY to GST_STATE_PAUSED
2022-09-14 13:11:17,836 - src.app - DEBUG - Element rtprtxsend0 going from GST_STATE_PAUSED to GST_STATE_PLAYING
2022-09-14 13:11:17,838 - src.app - DEBUG - Element bin0 going from GST_STATE_PAUSED to GST_STATE_PLAYING
2022-09-14 13:11:17,838 - src.app - DEBUG - Element clocksync0 going from GST_STATE_NULL to GST_STATE_READY
2022-09-14 13:11:17,839 - src.app - DEBUG - Element clocksync0 going from GST_STATE_READY to GST_STATE_PAUSED
2022-09-14 13:11:17,839 - src.app - DEBUG - Element clocksync0 going from GST_STATE_PAUSED to GST_STATE_PLAYING
2022-09-14 13:11:17,840 - src.elements.webrtc - DEBUG - WebRTC State is <enum GST_WEBRTC_PEER_CONNECTION_STATE_CONNECTING of type GstWebRTC.WebRTCPeerConnectionState>
2022-09-14 13:11:17,840 - src.elements.webrtc - DEBUG - WebRTC ICE State is <enum GST_WEBRTC_ICE_CONNECTION_STATE_CHECKING of type GstWebRTC.WebRTCICEConnectionState>
2022-09-14 13:11:17,841 - src.app - DEBUG - (type=<enum GST_STREAM_STATUS_TYPE_ENTER of type Gst.StreamStatusType>, owner=<__gi__.GstRtpRtxSend object at 0x7f88ecfbbbc0 (GstRtpRtxSend at 0x7f88dc186000)>)
2022-09-14 13:11:19,925 - src.app - DEBUG - Element funnel0 going from GST_STATE_NULL to GST_STATE_READY
2022-09-14 13:11:19,927 - src.app - DEBUG - Element dtlsenc0 going from GST_STATE_NULL to GST_STATE_READY
2022-09-14 13:11:19,928 - src.app - DEBUG - Element clocksync_0 going from GST_STATE_NULL to GST_STATE_READY
2022-09-14 13:11:19,930 - src.app - DEBUG - Element srtpenc0 going from GST_STATE_NULL to GST_STATE_READY
2022-09-14 13:11:19,931 - src.app - DEBUG - Element dtlssrtpenc0 going from GST_STATE_NULL to GST_STATE_READY
2022-09-14 13:11:19,932 - src.app - DEBUG - Element funnel0 going from GST_STATE_READY to GST_STATE_PAUSED
2022-09-14 13:11:19,933 - src.app - DEBUG - (type=<enum GST_STREAM_STATUS_TYPE_CREATE of type Gst.StreamStatusType>, owner=<__gi__.GstDtlsEnc object at 0x7f88ffa2a980 (GstDtlsEnc at 0x7f88e82a7600)>)
2022-09-14 13:11:19,934 - src.app - DEBUG - Element dtlsenc0 going from GST_STATE_READY to GST_STATE_PAUSED
2022-09-14 13:11:19,934 - src.app - DEBUG - Element clocksync_0 going from GST_STATE_READY to GST_STATE_PAUSED
2022-09-14 13:11:19,935 - src.app - DEBUG - Element srtpenc0 going from GST_STATE_READY to GST_STATE_PAUSED
2022-09-14 13:11:19,936 - src.app - DEBUG - (type=<enum GST_STREAM_STATUS_TYPE_ENTER of type Gst.StreamStatusType>, owner=<__gi__.GstDtlsEnc object at 0x7f88ecfee540 (GstDtlsEnc at 0x7f88e82a7600)>)
2022-09-14 13:11:19,936 - src.app - DEBUG - Element dtlssrtpenc0 going from GST_STATE_READY to GST_STATE_PAUSED
2022-09-14 13:11:19,937 - src.app - DEBUG - Element funnel0 going from GST_STATE_PAUSED to GST_STATE_PLAYING
2022-09-14 13:11:19,938 - src.app - DEBUG - Element dtlsenc0 going from GST_STATE_PAUSED to GST_STATE_PLAYING
2022-09-14 13:11:19,939 - src.app - DEBUG - Element clocksync_0 going from GST_STATE_PAUSED to GST_STATE_PLAYING
2022-09-14 13:11:19,939 - src.app - DEBUG - Element srtpenc0 going from GST_STATE_PAUSED to GST_STATE_PLAYING
2022-09-14 13:11:19,940 - src.app - DEBUG - Element dtlssrtpenc0 going from GST_STATE_PAUSED to GST_STATE_PLAYING
2022-09-14 13:11:19,941 - src.app - DEBUG - <flags GST_MESSAGE_STREAM_START of type Gst.MessageType>, <Gst.Pipeline object at 0x7f88ff83b540 (GstPipeline at 0x7f88e8008130)>
2022-09-14 13:11:19,941 - src.app - DEBUG - <flags GST_MESSAGE_LATENCY of type Gst.MessageType>, <__gi__.GstNiceSink object at 0x7f88ecfee540 (GstNiceSink at 0x7f88dc0d91c0)>
2022-09-14 13:11:19,976 - src.elements.webrtc - DEBUG - WebRTC State is <enum GST_WEBRTC_PEER_CONNECTION_STATE_CONNECTED of type GstWebRTC.WebRTCPeerConnectionState>
2022-09-14 13:11:19,976 - src.elements.webrtc - DEBUG - WebRTC ICE State is <enum GST_WEBRTC_ICE_CONNECTION_STATE_COMPLETED of type GstWebRTC.WebRTCICEConnectionState>
```
Any pointers or things I should be looking at? More than happy to open any MR's if we find a bug, I just need to know where to look :smile:https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1439ci: documentation build bot uses an old docker fedora image2022-10-10T11:04:07ZVíctor Manuel Jáquez Lealci: documentation build bot uses an old docker fedora imagedocumentation build bot uses an old docker fedora image:
```
Using Docker executor with image registry.freedesktop.org/gstreamer/gst-ci/amd64/fedora:2020-07-03.0-master ...�
```
The problem is it has and old version of libva-dev which...documentation build bot uses an old docker fedora image:
```
Using Docker executor with image registry.freedesktop.org/gstreamer/gst-ci/amd64/fedora:2020-07-03.0-master ...�
```
The problem is it has and old version of libva-dev which isn't supported by gstva, so gstva library isn't generated and neither its documentation. Then, if plugins (read by plugins_cache.json) use API documented in gstva library, documentation will fail.
What would be the procedure to update docker's image used by documentation build bot?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/244rtpav1depay: Output individual OBUs instead of constructing TUs2023-02-09T19:25:41ZSebastian Drögertpav1depay: Output individual OBUs instead of constructing TUsShould simplify the codeShould simplify the codehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1438nvh265dec: can't decode stream if coded resolution is larger than display res...2022-10-07T22:18:33ZJacob Teplitskynvh265dec: can't decode stream if coded resolution is larger than display resolutionThe following pipeline fails.
When I use 264 (ID=4) pipeline works.
When I uncomment ENC , the pipeline works.
export GST_DEBUG=2
ID=5
ENC=" videoconvertscale ! video/x-raw, format=NV12, framerate=20/1, width=752, height=480 ! nvh26${I...The following pipeline fails.
When I use 264 (ID=4) pipeline works.
When I uncomment ENC , the pipeline works.
export GST_DEBUG=2
ID=5
ENC=" videoconvertscale ! video/x-raw, format=NV12, framerate=20/1, width=752, height=480 ! nvh26${ID}enc "
#ENC=" videoconvertscale ! video/x-raw, format=NV12 ! nvh26${ID}enc "
gst-launch-1.0 -e videotestsrc ! videoconvertscale ! $ENC ! video/x-h26${ID}, profile=main ! nvh26${ID}dec ! queue ! fakesink
0:00:00.232672072 508617 0x55a6948d50a0 WARN nvrtcloader gstnvrtcloader.c:137:gst_nvrtc_load_library: Could not open library libnvrtc.so, libnvrtc.so: cannot open shared object\
file: No such file or directory
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'nvh265dec0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext1", cuda-device-id=(uint)0;
Got context from element 'nvh265dec0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";
Redistribute latency...
0:00:00.342946507 508617 0x55a694797800 WARN nvdec gstnvdec.c:719:parser_decode_callback: CUDA call failed: CUDA_ERROR_INVALID_VALUE, invalid argument
0:00:00.342975360 508617 0x55a694797800 ERROR nvdec gstnvdec.c:720:parser_decode_callback:<nvh265dec0> failed to decode picture
0:00:00.343023679 508617 0x55a6947979e0 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<videotestsrc0> error: Internal data stream error.
0:00:00.343035151 508617 0x55a6947979e0 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<videotestsrc0> error: streaming stopped, reason error (-5)
ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data stream error.
Additional debug info:
../subprojects/gstreamer/libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
0:00:00.343251757 508617 0x55a6947979e0 WARN videodecoder gstvideodecoder.c:1416:gst_video_decoder_sink_event_default:<nvh265dec0> error: No valid frames decoded before end of s\
tream
0:00:00.343260613 508617 0x55a6947979e0 WARN videodecoder gstvideodecoder.c:1416:gst_video_decoder_sink_event_default:<nvh265dec0> error: no valid frames found
ERROR: from element /GstPipeline:pipeline0/nvh265dec:nvh265dec0: No valid frames decoded before end of stream
Additional debug info:
../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c(1416): gst_video_decoder_sink_event_default (): /GstPipeline:pipeline0/nvh265dec:nvh265dec0:
no valid frames found
ERROR: pipeline doesn't want to preroll.
Freeing pipeline ...https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1437There is a size of the image that creates a crumbling video.2022-11-10T09:21:16ZJun TakaThere is a size of the image that creates a crumbling video.[Goals]<br>
Create a movie using I420 format images of any size (Width and height are both multiples of 2)
[Issue]<br>
There is a size of the image that creates a crumbling video. For example, a video with width 100 and height 380.
Vide...[Goals]<br>
Create a movie using I420 format images of any size (Width and height are both multiples of 2)
[Issue]<br>
There is a size of the image that creates a crumbling video. For example, a video with width 100 and height 380.
Videos with width 96, height 380 or width 104 and height 380 can be created.
I don't understand why videos can't be made depending on the size.
When the size is such that a crumbling video is created, the callback (last parameter of gst_buffer_new_wrapped_full) is set so that it will be called when the data for one frame is read, and even if one image is passed, the callback will not occur.
I would like to know either how to successfully animate any size or under what size conditions the video is created successfully.
[SampleCode]<br>
```
GstElement* pipeline;
GstElement* appsrc;
GstElement* rawvideoparse;
GstElement* enc;
GstElement* vp9parse;
GstElement* splitmuxsink;
GstElement* muxer;
GstCaps* caps;
pipeline = gst_pipeline_new("test-pipeline");
appsrc = gst_element_factory_make("appsrc", "source");
g_object_set(G_OBJECT(appsrc), "stream-type", 0, "format", GST_FORMAT_TIME, NULL);
caps = gst_caps_new_simple("video/x-raw",
"format", G_TYPE_STRING, "I420",
"width", G_TYPE_INT, WIDTH,
"height", G_TYPE_INT, HEIGHT,
"framerate", GST_TYPE_FRACTION, FRAMERATE, 1,
NULL);
g_object_set(appsrc, "caps", caps, "format", GST_FORMAT_TIME, NULL);
// g_signal_connect(appsrc, "need-data", G_CALLBACK(needData), &data);
// g_signal_connect(appsrc, "enough-data", G_CALLBACK(enoughData), &data);
gst_caps_unref(caps);
rawvideoparse = gst_element_factory_make("rawvideoparse", "rawvideoparse");
g_object_set(G_OBJECT(rawvideoparse), "width", WIDTH, NULL);
g_object_set(G_OBJECT(rawvideoparse), "height", HEIGHT, NULL);
enc = gst_element_factory_make("msdkvp9enc", "enc");
g_object_set(G_OBJECT(enc), "gop-size", FRAMERATE, NULL);
g_object_set(G_OBJECT(enc), "bitrate", BITRATE, NULL);
vp9parse = gst_element_factory_make("vp9parse", "vp9parse");
muxer = gst_element_factory_make("matroskamux", "matroskamux");
g_object_set(G_OBJECT(muxer), "offset-to-zero", true, NULL);
splitmuxsink = gst_element_factory_make("splitmuxsink", "splitmuxsink");
g_object_set(G_OBJECT(splitmuxsink), "location", FILE_PATH, NULL);
g_object_set(G_OBJECT(splitmuxsink), "max-size-time", CYCLE_TIME, NULL);
g_object_set(G_OBJECT(splitmuxsink), "async-finalize", false, NULL);
g_object_set(G_OBJECT(splitmuxsink), "muxer", muxer, NULL);
gst_bin_add_many(GST_BIN(pipeline), appsrc, rawvideoparse, enc, vp9parse, splitmuxsink, NULL);
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/242Can install gst-plugins-rs with package manager?2022-09-12T07:53:43ZBehzadCan install gst-plugins-rs with package manager?How can i install gst-plugins-rs with package manager? (e.g. Debian distro). Is it necessary at all?How can i install gst-plugins-rs with package manager? (e.g. Debian distro). Is it necessary at all?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1434rtpjitterbuffer: RTCP SRs with "out-of-order" RTP timestamps generate bad ref...2023-05-24T11:04:29Zmattc1170rtpjitterbuffer: RTCP SRs with "out-of-order" RTP timestamps generate bad reference timestamps### Describe your issue
Duplicate reference timestamp metadata is sometimes seen on consecutive frames in my GStreamer RTSP video client running a pipeline with the following front-end elements: rtspsrc add-reference-timestamp-meta=true ...### Describe your issue
Duplicate reference timestamp metadata is sometimes seen on consecutive frames in my GStreamer RTSP video client running a pipeline with the following front-end elements: rtspsrc add-reference-timestamp-meta=true ! rtph264depay ! h264parse ! ...
#### Expected Behavior
Unique, correct reference timestamp metadata for all frame buffers coming out of the h264parse src pad.
#### Observed Behavior
Multiple instances of duplicated, incorrect reference timestamp metadata coinciding with RTCP SRs received by the video client.
#### Data from deeper investigation
Some RTSP servers (some Axis cameras, GStreamer RTSP server under certain conditions) can generate RTCP Sender Reports whose RTP timestamps are not strictly ordered in sequence with the accompanying RTP stream. When this happens, the gstrtpjitterbuffer code will generate bad reference timestamp metadata for some number of packets until the RTP stream timestamps have "caught up" to the last RTCP SR timestamp. For example, take the following packets received in order:
```
RTP packet N: Time=100000
RTP packet N+1: Time=100000
RTP packet N+2: Time=100000
RTCP SR packet: RTP timestamp=115500 NTP time=<foo>
RTP packet N+3: Time=100000
RTP packet N+4: Time=103000
RTP packet N+5: Time=103000
RTP packet N+6: Time=106000
...
RTP packet N+M: Time=115000
RTP packet N+M+1: Time=118000
```
In this case, all of the buffers for packets from N+3 to N+M will have identical improperly-calculated reference timestamp metadata due to the following code in gstrtpjitterbuffer.c:
```
// If we can calculate a NTP time based solely on the Sender Report, or
// inband NTP header extension do that so that we can still add a reference
// timestamp meta to the buffer
if (!GST_CLOCK_TIME_IS_VALID (ntp_time) &&
GST_CLOCK_TIME_IS_VALID (priv->last_known_ntpnstime) &&
priv->last_known_ext_rtptime != -1) {
guint64 ext_time = priv->last_known_ext_rtptime;
ext_time = gst_rtp_buffer_ext_timestamp (&ext_time, rtptime);
ntp_time =
priv->last_known_ntpnstime + gst_util_uint64_scale (ext_time -
priv->last_known_ext_rtptime, GST_SECOND, priv->clock_rate);
}
```
When the SR RTP timestamp is later than the RTP buffer timestamp, this code cannot calculate the correct NTP reference timestamp correctly because it subtracts the RTCP SR RTP timestamp from the RTP buffer timestamp, returning the result as a scaled unsigned 64-bit int. When the SR RTP timestamp is greater than the RTP buffer timestamp, the gst_util_uint64_scale() function returns 0. Until the SR RTP timestamp is less than the RTP buffer timestamps, all buffers will have reference timestamp metadata incorrectly set to the priv->last_known_ntpnstime (from the RTCP SR).
#### Setup
- Ubuntu 22.04
- RTSP client: laptop
- RTSP server: Axis M-3068P video camera (also seen with GStreamer RTSP server serving video generated from testvideosrc with RTSP server rtpbin property "rtcp-sync-send-time" set to false)
- GStreamer git b90d02741e
- Running our own application, but likely reproducible with a gst-launch pipeline of:
rtspsrc location="<device RTSP url>" latency=40 add-reference-timestamp-meta=true buffer-mode=none ntp-sync=true protocols=tcp ! rtph264depay ! h264parse disable-passthrough=true ! video/x-h264,stream-format=byte-stream,alignment=au ! fakesink
### Steps to reproduce the bug
Connect a GStreamer rtspsrc pipeline to an RTSP server that generates RTCP SRs with RTP timestamps that are "out-of-order" with respect to the associated RTP stream.
### How reproducible is the bug?
Always reproducible with Axis M3068-P camera and GStreamer git. Sometimes reproducible with GStreamer RTSP server.
### Solutions you have tried
I have actually implemented a tentative fix in gstrtpjitterbuffer.c that will delay updating the priv->last_known_ntpnstime and priv->last_known_ext_rtptime until the RTP buffer timestamps are greater than the RTCP SR timestamp. I will attach a patch of this tentative fix for consideration.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1433How to fine tune subprojects build2022-11-10T09:21:16Zdpatel257How to fine tune subprojects buildHow can I fine tune the subprojects build when building ?
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/meson_options.txt
Since monorepo transition, it is confusing how can we fine tune each...How can I fine tune the subprojects build when building ?
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/meson_options.txt
Since monorepo transition, it is confusing how can we fine tune each subprojects when building. Is it documented somewhere?
Thankshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/241ci: Some Windows improvements2022-09-12T08:15:53ZSebastian Drögeci: Some Windows improvementsBuild all plugins by default but exclude specific ones (`cargo build --all --exclude ...`) so that always all plugins, including new ones, are built and Windows-incompatible ones have to be explicitly excluded.
This will also considerab...Build all plugins by default but exclude specific ones (`cargo build --all --exclude ...`) so that always all plugins, including new ones, are built and Windows-incompatible ones have to be explicitly excluded.
This will also considerably speed up the build compared to building each plugin individually.Jordan PetridіsJordan Petridіs