We love the DeepStream framework and how it is enabling us to rapidly build on the very solid foundation of GStreamer. DeepStream, however, appears to be built on a now dated version of GStreamer (v1.14.5), so this topic is intended to outline specific reasons why a newer version of GStreamer (v1.18.4 or newer) would be highly desirable from our perspective.
To begin, there are a number of CVE (Common Vulnerabilities and Exposures) reports that are applicable for GStreamer v1.14.5 that have been fixed for GStreamer v1.18.4. These CVEs, in particular, affect GStreamer elements that are utilised in our DeepStream-based solution, including:
- CVE-2019-9928 - “GStreamer before 1.16.0 has a heap-based buffer overflow in the RTSP connection parser via a crafted response from a server, potentially allowing remote code execution.”
- CVE-2020-6095 - “An exploitable denial of service vulnerability exists in the GstRTSPAuth functionality of GStreamer/gst-rtsp-server 1.14.5. A specially crafted RTSP setup request can cause a null pointer deference resulting in denial-of-service. An attacker can send a malicious packet to trigger this vulnerability.”
- CVE-2021-3185 - “A flaw was found in the gstreamer h264 component of gst-plugins-bad before v1.18.1 where when parsing a h264 header, an attacker could cause the stack to be smashed, memory corruption and possibly code execution.” This CVE in particular has been encountered during the testing of our DeepStream-based solution and thus is high-priority to be fixed to avoid the issue occurring in a production environment.
In addition, there are several issue reports listed on the GStreamer Gitlab group that pertain to GStreamer elements that we use in our DeepStream-based solution. There are likely more than those that have been currently found, but these include:
- h264parse: not correctly converting avc (alignment=au) to byte-stream (alignment=nal) (#1356) · Issues · GStreamer / gst-plugins-bad · GitLab - “h264parse: not correctly converting avc (alignment=au) to byte-stream (alignment=nal)” (h264parse)
- Webrtc 1.14.5 and 1.16.2 blocked in OutputSelector on pc but not on phone (#1322) · Issues · GStreamer / gst-plugins-bad · GitLab - “Webrtc 1.14.5 and 1.16.2 blocked in OutputSelector on pc but not on phone” (webrtcbin)
- rtph264pay commit 4add820c breaks h264 rendering (#540) · Issues · GStreamer / gst-plugins-good · GitLab - “rtph264pay commit 4add820c breaks h264 rendering” (rtph264pay)
We’ve also encountered an issue with the webrtcbin element during its usage in our DeepStream-based solution. When the browser initialises the WebRTC connection with GStreamer, it is not able to receive the WebRTC stream. However, if GStreamer were to initialise the WebRTC connection with the browser, then this issue does not occur. Notably, this issue does not occur in v1.16 and v1.18 builds of GStreamer.
Finally, GStreamer v1.14.5 is now so dated, that we only have docs for v1.16 and v1.18!!
We’d really love if DeepStream could move to a more recent foundation of GStreamer (e.g. v1.18.4) as this would offer us more stability, which is a prime requisite for our DeepStream-based solution. Is there any such update on the roadmap planned, and if not, can the above be put forward as evidence for there being (some) DeepStream user community demand for such an update!