GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-08-08T09:05:18Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2886videorate: hits assert with drop-only and variable output framerate2023-08-08T09:05:18ZPhilippe Normandvideorate: hits assert with drop-only and variable output framerate```
gst-launch-1.0 videotestsrc do-timestamp=1 num-buffers=5 ! videorate drop-only=true ! video/x-raw,framerate=0/1 ! queue ! fakesink
ERROR:../subprojects/gst-plugins-base/gst/videorate/gstvideorate.c:745:gst_video_rate_push_buffer: ass...```
gst-launch-1.0 videotestsrc do-timestamp=1 num-buffers=5 ! videorate drop-only=true ! video/x-raw,framerate=0/1 ! queue ! fakesink
ERROR:../subprojects/gst-plugins-base/gst/videorate/gstvideorate.c:745:gst_video_rate_push_buffer: assertion failed: (GST_BUFFER_DURATION_IS_VALID (outbuf))
Bail out! ERROR:../subprojects/gst-plugins-base/gst/videorate/gstvideorate.c:745:gst_video_rate_push_buffer: assertion failed: (GST_BUFFER_DURATION_IS_VALID (outbuf))
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2885RTSP Client does not disconnect when RTSPMediaFactory is removed (no EOS sent).2023-08-08T08:59:00ZPaulo GomesRTSP Client does not disconnect when RTSPMediaFactory is removed (no EOS sent).Hello,
First, let me try to describe what I am trying to achieve.
I have an GstRTSPServer running, that provides several streams, each one with its own mount point.
For that I create a RTSPMediaFactory with its own pipeline and add it w...Hello,
First, let me try to describe what I am trying to achieve.
I have an GstRTSPServer running, that provides several streams, each one with its own mount point.
For that I create a RTSPMediaFactory with its own pipeline and add it with the .add_factory method. So far so good.
Now, the problem is that sometimes, the characteristics of that stream change. To handle that I .remove_factory() and .add_factory() on the same mount point, this time with a slightly different pipeline (basically, I want to optionally add audio to the stream, and toggle between the two pipelines when settings change).
The problem is, since the both steps (remove and add factory) happen in sequence, the client never detects that the stream was stopped.
I sense this is because when the RTSPMediaFactory is removed, no BYE signal is sent to the client, so it just recovers after some brief moments.
I tried .set_eos_shutdown(True) but didn't notice any change.
I've looked into this old issue https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/8 and it seems to be related to my problem, but could not find a solution.
Is this by design? A bug? Or am I doing this the wrong way?
Thanks in advance.
FYI, the client I'm using is VLC.
The server was written in Python and Gstreamer version is 1.18.4https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2884playbin3,decodebin3: Select wrong stream type with gapless flag2023-08-09T02:10:54Zchinn zamplaybin3,decodebin3: Select wrong stream type with gapless flagI have three mp4 files:
1.mp4 with both audio and video stream
2.mp4 with video stream only
3.mp4 with both audio and video stream
Testing cmd:
gst-play-1.0 --gapless --use-playbin3 1.mp4 2.mp4 3.mp4
**The 3.mp4 will only play the ...I have three mp4 files:
1.mp4 with both audio and video stream
2.mp4 with video stream only
3.mp4 with both audio and video stream
Testing cmd:
gst-play-1.0 --gapless --use-playbin3 1.mp4 2.mp4 3.mp4
**The 3.mp4 will only play the audio, but the video is gone**
The dot file of 1.mp4:
![image](/uploads/4a4c021015634b942636a1485ed8514d/image.png)
The dot file of 2.mp4:
![image](/uploads/7a31a1445e70706c34eaf5a8cfa1f11e/image.png)
The dot file of 3.mp4:
![image](/uploads/677c4b61d8a9782ad02a47e36d519697/image.png)
As the png files shows, when playing 3.mp4, the decodebin will create a new audio stream (now there are two audio streams and one video stream in total), but the 3.mp4 only have two streams, so the playbin only check the type of the first two streams which is both audio type, than the video stream is not selected:
``` shell
0:00:07.147435095 3331 0x7f4000aaa0 DEBUG playbin3 gstplaybin3.c:2248:gst_play_bin3_handle_message:<playbin> selected s
tream types changed, reconfiguring output
0:00:07.147449387 3331 0x7f4000aaa0 DEBUG playbin3 gstplaybin3.c:2812:reconfigure_output:<playbin> selected_stream_type
s : audio
0:00:07.147463388 3331 0x7f4000aaa0 DEBUG playbin3 gstplaybin3.c:2814:reconfigure_output:<playbin> active_stream_types
: audio video
0:00:07.147478263 3331 0x7f4000aaa0 DEBUG playbin3 gstplaybin3.c:2829:reconfigure_output:<playbin> Stream type status:
'audio' selected active
0:00:07.147490513 3331 0x7f4000aaa0 DEBUG playbin3 gstplaybin3.c:2836:reconfigure_output:<playbin> Stream type 'audio'
already active
0:00:07.147504222 3331 0x7f4000aaa0 DEBUG playbin3 gstplaybin3.c:2829:reconfigure_output:<playbin> Stream type status:
'video' NOT selected active
0:00:07.147516472 3331 0x7f4000aaa0 DEBUG playbin3 gstplaybin3.c:2839:reconfigure_output:<playbin> Stream type 'video'
is no longer requested
0:00:07.159008628 3331 0x7f4000aaa0 DEBUG playbin3 gstplaybin3.c:2487:remove_combiner:<playbin> No combiner element to
remove
0:00:07.159033128 3331 0x7f4000aaa0 DEBUG playbin3 gstplaybin3.c:2829:reconfigure_output:<playbin> Stream type status:
'text' NOT selected NOT active
0:00:07.159066087 3331 0x7f4000aaa0 DEBUG playbin3 gstplaybin3.c:2896:reconfigure_output:<playbin> selected_stream_type
s : audio
0:00:07.159081546 3331 0x7f4000aaa0 DEBUG playbin3 gstplaybin3.c:2898:reconfigure_output:<playbin> active_stream_types
: audio
```
My gstreamer version is 1.22.0.
I don't know if what I described is detailed, please let me know if you need more infomations.
Best Wishes.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/396onvifmetadatapay - cannot create proper metadata stream2023-11-13T12:11:05ZPrzemysław Janikulaonvifmetadatapay - cannot create proper metadata streamHello,
I've been trying to create RTSP ONVIF media server. I'm using Gstreamer 1.20.3 and gst-plugins-onvif with Python bindings. I want to be able to setup two streams:
- /video - simple video stream
- /metadata - metadata of the video...Hello,
I've been trying to create RTSP ONVIF media server. I'm using Gstreamer 1.20.3 and gst-plugins-onvif with Python bindings. I want to be able to setup two streams:
- /video - simple video stream
- /metadata - metadata of the video (bounding boxes of detected objects)
I was able to setup RTSP server and connect to /video stream without any issue, but I'm having hard time recieving metadata over RTSP.
Based on how it is implemented in [happpytime ](https://www.happytimesoft.com/) and how ONVIF Device Manager interacts with it - it seems that proper communication with ONVIF should look like this:
1. Client sends request OPTIONS on base rtsp url (rtsp://address:port/endpoint)
2. Server responds with available options (OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN, STOP)
3. Client sends DESCRIBE request on base rtsp url
4. Server responds with proper SDP containing all available streams (such as /realvideo, /metadata)
5. Client sends SETUP request on particular endpoint (rtsp://address:port/endpoint/metadata)
So as a starting point I've tried to setup video and metadata streams separately using `GstRtspServer.RTSPServer`. As I mentioned - video streams is working, but as for metadata this is what I've been able to achieve so far:
```
import gi
from gi.repository import Gst, GstRtspServer, GObject
import xml.etree.ElementTree as ET
class MediaFactory(GstRtspServer.RTSPMediaFactory):
def __init__(self, **properties):
super(MediaFactory, self).__init__(**properties)
self.launch_string = (
"appsrc name=metadata ! rtponvifmetadatapay pt=96"
)
def on_need_data(self, src, length):
metadata_buf = Gst.Buffer.new_wrapped(self.get_xml_message().encode('utf-8'))
# metadata_buf.pts = metadata_buf.dts = 0 # Set the timestamp of the metadata buffer
retval = src.emit('push-buffer', metadata_buf)
if retval != Gst.FlowReturn.OK:
print("Error pushing metadata buffer:", retval)
def do_create_element(self, url):
return Gst.parse_launch(self.launch_string)
def do_configure(self, rtsp_media):
self.number_frames = 0
metadata_src = rtsp_media.get_element().get_by_name('metadata')
metadata_src.connect('need-data', self.on_need_data)
def get_xml_message(self):
body = self.mocked_xml_metadata()
soap_response = ET.tostring(body, encoding="utf-8")
return soap_response
def mocked_xml_metadata(self):
# Create the root element
metadata_stream = ET.Element('tt:MetadataStream')
# Add the VideoAnalytics element
video_analytics = ET.SubElement(metadata_stream, 'tt:VideoAnalytics')
# Add the first Frame element
frame1 = ET.SubElement(video_analytics, 'tt:Frame', {'UtcTime': '2008-10-10T12:24:57.321'})
object1 = ET.SubElement(frame1, 'tt:Object', {'id': '1'})
appearance1 = ET.SubElement(object1, 'tt:Appearance')
shape1 = ET.SubElement(appearance1, 'tt:Shape')
bounding_box1 = ET.SubElement(shape1, 'tt:BoundingBox',
{'x': '0.1', 'y': '0.1', 'width': '0.2', 'height': '0.2'})
# Add the second Frame element
frame2 = ET.SubElement(video_analytics, 'tt:Frame', {'UtcTime': '2008-10-10T12:24:57.621'})
object2 = ET.SubElement(frame2, 'tt:Object', {'id': '2'})
appearance2 = ET.SubElement(object2, 'tt:Appearance')
shape2 = ET.SubElement(appearance2, 'tt:Shape')
bounding_box2 = ET.SubElement(shape2, 'tt:BoundingBox',
{'x': '0.3', 'y': '0.3', 'width': '0.2', 'height': '0.2'})
return metadata_stream
def create_envelop(self) -> ET.Element:
"""
Wsdl references and namespaces used by onvif
"""
envelope = ET.Element(
"s:Envelope",
attrib={
"xmlns:s": "http://www.w3.org/2003/05/soap-envelope",
"xmlns:e": "http://www.w3.org/2003/05/soap-encoding",
"xmlns:wsa": "http://www.w3.org/2005/08/addressing",
"xmlns:xs": "http://www.w3.org/2001/XMLSchema",
"xmlns:xsi": "http://www.w3.org/2001/XMLSchema-instance",
"xmlns:wsaw": "http://www.w3.org/2006/05/addressing/wsdl",
"xmlns:wsnt": "http://docs.oasis-open.org/wsn/b-2",
"xmlns:wstop": "http://docs.oasis-open.org/wsn/t-1",
"xmlns:wsntw": "http://docs.oasis-open.org/wsn/bw-2",
"xmlns:wsrf-rw": "http://docs.oasis-open.org/wsrf/rw-2",
"xmlns:wsrf-r": "http://docs.oasis-open.org/wsrf/r-2",
"xmlns:wsrf-bf": "http://docs.oasis-open.org/wsrf/bf-2",
"xmlns:wsdl": "http://schemas.xmlsoap.org/wsdl",
"xmlns:wsoap12": "http://schemas.xmlsoap.org/wsdl/soap12",
"xmlns:http": "http://schemas.xmlsoap.org/wsdl/http",
"xmlns:d": "http://schemas.xmlsoap.org/ws/2005/04/discovery",
"xmlns:wsadis": "http://schemas.xmlsoap.org/ws/2004/08/addressing",
"xmlns:tt": "http://www.onvif.org/ver10/schema",
"xmlns:tns1": "http://www.onvif.org/ver10/topics",
"xmlns:tds": "http://www.onvif.org/ver10/device/wsdl",
"xmlns:trt": "http://www.onvif.org/ver10/media/wsdl",
"xmlns:tev": "http://www.onvif.org/ver10/events/wsdl",
"xmlns:timg": "http://www.onvif.org/ver20/imaging/wsdl",
"xmlns:tst": "http://www.onvif.org/ver10/storage/wsdl",
"xmlns:dn": "http://www.onvif.org/ver10/network/wsdl",
"xmlns:pt": "http://www.onvif.org/ver10/pacs",
"xmlns:tr2": "http://www.onvif.org/ver20/media/wsdl",
"xmlns:tptz": "http://www.onvif.org/ver20/ptz/wsdl",
"xmlns:tan": "http://www.onvif.org/ver20/analytics/wsdl",
"xmlns:axt": "http://www.onvif.org/ver20/analytics",
"xmlns:trp": "http://www.onvif.org/ver10/replay/wsdl",
"xmlns:tse": "http://www.onvif.org/ver10/search/wsdl",
"xmlns:trc": "http://www.onvif.org/ver10/recording/wsdl",
"xmlns:tac": "http://www.onvif.org/ver10/accesscontrol/wsdl",
"xmlns:tdc": "http://www.onvif.org/ver10/doorcontrol/wsdl",
"xmlns:tmd": "http://www.onvif.org/ver10/deviceIO/wsdl",
"xmlns:tth": "http://www.onvif.org/ver10/thermal/wsdl",
"xmlns:tcr": "http://www.onvif.org/ver10/credential/wsdl",
"xmlns:tar": "http://www.onvif.org/ver10/accessrules/wsdl",
"xmlns:tsc": "http://www.onvif.org/ver10/schedule/wsdl",
"xmlns:trv": "http://www.onvif.org/ver10/receiver/wsdl",
"xmlns:tpv": "http://www.onvif.org/ver10/provisioning/wsdl",
"xmlns:ter": "http://www.onvif.org/ver10/error",
},
)
return envelope
class MediaFactoryServer(GstRtspServer.RTSPServer):
def __init__(self):
GstRtspServer.RTSPServer.__init__(self)
self.set_service('8554')
self.factory = MediaFactory()
self.factory.set_shared(True)
self.get_mount_points().add_factory("/stream", self.factory)
self.attach(None)
if __name__ == "__main__":
GObject.threads_init()
Gst.init(None)
server = MediaFactoryServer()
loop = GObject.MainLoop()
loop.run()
```
I've also created a script that should be able to recieve metadata from the server:
```import gi
gi.require_version('Gst', '1.0')
from gi.repository import Gst, GObject
Gst.init(None) # Initialize GStreamer
GObject.threads_init() # Initialize threads support
# Create the GStreamer pipeline string
pipeline_str = (
"rtspsrc location=rtsp://127.0.0.1:8554/stream ! "
"rtponvifmetadatadepay ! "
"fakesink sync=false"
)
# Create the GStreamer pipeline
pipeline = Gst.parse_launch(pipeline_str)
# Start the pipeline
pipeline.set_state(Gst.State.PLAYING)
# Listen for bus messages
bus = pipeline.get_bus()
while True:
message = bus.timed_pop_filtered(Gst.CLOCK_TIME_NONE, Gst.MessageType.ANY)
if message is None:
break
if message.type == Gst.MessageType.ERROR:
err, debug_info = message.parse_error()
print(f"Error: {err.message}")
break
# Stop the pipeline
pipeline.set_state(Gst.State.NULL)
```
When I have the server up and running and I'm trying to connect to it with the second script I'm getting:
`Error: Could not get/set settings from/on resource.`
My question would be: is this proper configuration of pipeline?
How to achieve what is required by ONVIF (one endpoint which responds on DESCRIBE request with proper SDP) using Gstreamer RTSP Server? Should I use multiple mount points, or is it possible simply by using single mountpoint and onvifmetadatacombiner somehow?Mathieu DuponchelleMathieu Duponchellehttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/443iOS: cross files specify host_machine.system() incorrectly2023-08-07T09:49:49ZamysparkiOS: cross files specify host_machine.system() incorrectlyHi,
As per https://mesonbuild.com/Reference-tables.html#operating-system-names, *all* Darwin-based OSes should report `host_machine.system()` equal to `'darwin'`.
However, Cerbero sets this value to `ios`, which is only supported on 1....Hi,
As per https://mesonbuild.com/Reference-tables.html#operating-system-names, *all* Darwin-based OSes should report `host_machine.system()` equal to `'darwin'`.
However, Cerbero sets this value to `ios`, which is only supported on 1.2.0 and higher, and only for `host_machine.subsystem()`. This breaks build systems following standard conventions.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2880x264: Missing ROI driven QP adjustment2023-08-03T19:31:21ZDhaval Sutariax264: Missing ROI driven QP adjustment### Describe your issue
For ROI based QP value, we are using "gst_buffer_add_video_region_of_interest_meta" and "gst_video_region_of_interest_meta_add_param" APIs.
But after calling this APIs, before x264enc we are not getting expected b...### Describe your issue
For ROI based QP value, we are using "gst_buffer_add_video_region_of_interest_meta" and "gst_video_region_of_interest_meta_add_param" APIs.
But after calling this APIs, before x264enc we are not getting expected behaviour.
#### Expected Behavior
Region selected should looks different than other region. Like if qp is high that ROI should look blur.
#### Observed Behavior
No different between ROI and non ROI area.
#### Setup
Linux 18.04https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/442documentation: MSYS2 Perl needs CPAN set up before usage2023-08-03T01:22:14Zamysparkdocumentation: MSYS2 Perl needs CPAN set up before usageHi,
A nit regarding the documentation of the Windows's MSYS2 bootstrap: CPAN needs to be run at least once prior to building recipes requiring Perl e.g. pango. Otherwise the following error happens, since the MSYS2 internal folders aren...Hi,
A nit regarding the documentation of the Windows's MSYS2 bootstrap: CPAN needs to be run at least once prior to building recipes requiring Perl e.g. pango. Otherwise the following error happens, since the MSYS2 internal folders aren't linked into PERL5LIB yet:
```
[155/155] "F:\cerbero\build\build-tools\bin\meson" "--internal" "exe" "--unpickle" "F:\cerbero\build\sources\msvc_x86_64\pango-1.50.11\_builddir\meson-private\meson_exe_perl_0ff55fac389bb67dc7db0e73fbfe93395a8aa9dc.dat"
FAILED: utils/pango-view.1
"F:\cerbero\build\build-tools\bin\meson" "--internal" "exe" "--unpickle" "F:\cerbero\build\sources\msvc_x86_64\pango-1.50.11\_builddir\meson-private\meson_exe_perl_0ff55fac389bb67dc7db0e73fbfe93395a8aa9dc.dat"
while executing ['perl', '-w', 'D:/msys64/usr/bin/help2man', '--no-info', '--section=1', '--help-option=--help-all', '--name="Pango text viewer"', '--output=utils/pango-view.1', 'F:/cerbero/build/sources/msvc_x86_64/pango-1.50.11/_builddir/utils/pango-view.exe']
--- stdout ---
--- stderr ---
Can't locate Locale/gettext.pm in @INC (you may need to install the Locale::gettext module) (@INC contains: /F/cerbero/build/dist/msvc_x86_64/lib/perl5:/F/cerbero/build/dist/msvc_x86_64/lib/perl5/site_perl/5.32 D:/msys64/ucrt64/lib/perl5/site_perl/5.32.1 D:/msys64/ucrt64/lib/perl5/site_perl/5.32.1 D:/msys64/ucrt64/lib/perl5/site_perl D:/msys64/ucrt64/lib/perl5/vendor_perl D:/msys64/ucrt64/lib/perl5/core_perl) at D:/msys64/usr/bin/help2man line 30.
BEGIN failed--compilation aborted at D:/msys64/usr/bin/help2man line 30.
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2878queue: leaky feature request2023-08-02T20:52:27ZMaurizio Buratoqueue: leaky feature requestCurrently queue has 3 leaky modes but it seems that none of them solve my problem
Here is an example:
we have a queue between a source and an encoder
queue is set to max-size-bytes=128000 (other max limits to 0)
the source sends 1024 by...Currently queue has 3 leaky modes but it seems that none of them solve my problem
Here is an example:
we have a queue between a source and an encoder
queue is set to max-size-bytes=128000 (other max limits to 0)
the source sends 1024 bytes for each buffer
if the source send data a little too fast than the encoder speed the queue buffer will reach max-size-bytes
now i would like that source buffers are discarded until the queue size is back to 0 (Zero) because i need to have an empty queue again like at pipeline start.
none of the leaky mode allows this.
leaky=1 or leaky=2 only discard 1024 bytes until there is again space for 1024 bytes inside the queue, they don't wait for the queue to be empty
would it be possible to create a leaky=3 that behave like this? (discard until queue is empty)
i'm a commandline user so no programmatically solutions are good for mehttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/441Cannot find dll.a for plugins2023-08-26T22:22:01Zdayo7116Cannot find dll.a for pluginsI am using 1.22.5 runtime/development installer. ![image](/uploads/00b108d6c2a352f4db2283287d304ab8/image.png)
I want to link gstreamer staticly, I found core static libs(such as libgstreamer-1.0.dll.a), but cannot find plugin static li...I am using 1.22.5 runtime/development installer. ![image](/uploads/00b108d6c2a352f4db2283287d304ab8/image.png)
I want to link gstreamer staticly, I found core static libs(such as libgstreamer-1.0.dll.a), but cannot find plugin static libs for windows(such as libgstwasapi2.dll.a).
Does gstreamer CI support static libs for plugins? Or do I need to compile static plugins myself?
Thanks!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2876wasapi2sink: No volume sync from system volume2023-08-01T14:38:46ZJonas Kvingewasapi2sink: No volume sync from system volumeWhen setting volume on wasapi2sink, it syncs to the system volume, but when connecting notify::volume, no event is received when the system volume is changed.When setting volume on wasapi2sink, it syncs to the system volume, but when connecting notify::volume, no event is received when the system volume is changed.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2874Consider converting GValue with nullptr GValueArray to an empty string2023-08-01T00:30:22ZSlava AndrejevConsider converting GValue with nullptr GValueArray to an empty string### Describe your issue
If you call `get_defs` from Glibmm's `libglibmm_generate_extra_defs-2.68.so` on `GstAudioInterleave`, `get_defs` raises a segmentation fault.
#### Expected Behavior
No segmentation fault.
#### Observed Behavior...### Describe your issue
If you call `get_defs` from Glibmm's `libglibmm_generate_extra_defs-2.68.so` on `GstAudioInterleave`, `get_defs` raises a segmentation fault.
#### Expected Behavior
No segmentation fault.
#### Observed Behavior
Segmentation fault.
Here is what is going on. The segmentation fault happens when Glibmm tries to extract the default value for the `channel-positions` property of `GstAudioInterleave`. It calls `g_param_spec_get_default_value` to extract the default value from the `channel-positions` property specification. Then it passes this default value to `g_value_transform` with the second argument of type `G_TYPE_STRING`. Everything looks legitimate at this point. Yet, the code explodes on a null pointer dereference. It happens because `g_value_transform` ends up in the GStreamer code here:
```c
static void
_gst_value_transform_g_value_array_string (const GValue * src_value,
GValue * dest_value, const gchar * begin, const gchar * end)
{
GValue *list_value;
GValueArray *array;
GString *s;
guint i;
gchar *list_s;
guint alen;
array = src_value->data[0].v_pointer;
alen = array->n_values;
```
The last line above dereferences a null pointer. It happens because `channel-positions` has an array type. A default value for it is set by a call to `boxed_proxy_value_init`, which initializes `data[0].v_pointer` with NULL.
Since a null pointer is a valid initial value for an array, I believe the right thing to do is to check if the array is NULL inside `_gst_value_transform_g_value_array_string` and return an empty string.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2873ci: Enable gst-plugins-rs documentation2023-09-20T17:19:08ZNicolas Dufresneci: Enable gst-plugins-rs documentationCurrently the cargo wrapper script depends on Python 3.8, but we have 3.7 in the old fedora we use in our image, and glib version 2.66 is required, but we currently build 2.62.
For the 3.8 deps, we can workaround with a quick shlex_join...Currently the cargo wrapper script depends on Python 3.8, but we have 3.7 in the old fedora we use in our image, and glib version 2.66 is required, but we currently build 2.62.
For the 3.8 deps, we can workaround with a quick shlex_join() function (excuse my style, I'm rusty in python):
```python
def shlex_join(args):
ret = ''
for a in args:
ret += ' ' + shlex.quote(a)
return ret
```
For Glib, I haven't checked by we let plugins-rs be out of sync, and why we didn't sync all our subproject here. But to update, we can build manually, or update our fedora image, which is covered by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1060https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2872dash: seeking sometimes doesn't work2023-07-31T09:20:49ZAngelo Verlain Shemadash: seeking sometimes doesn't work### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstream...### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
When using MPEG-DASH, sometimes seeking doesn't work
#### Expected Behavior
<!-- What did you expect to happen -->
Expect seeking to work correctly
#### Observed Behavior
<!-- What actually happened -->
Seeking fails, (sometimes) a message "Could not seek." is logged. And the video restarts
#### Setup
- **Operating System:** arch rolling
- **Device:** Computer
- **GStreamer Version:** GStreamer 1.22.5
- **Command line:** gst-play-1.https://dash.akamaized.net/akamai/test/caption_test/ElephantsDream/elephants_dream_480p_heaac5_1.mpd
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type `gst-play-1.https://dash.akamaized.net/akamai/test/caption_test/ElephantsDream/elephants_dream_480p_heaac5_1.mpd`
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
It fails to seek everytime.
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->
Here is a [test page of DASH functionality](https://reference.dashif.org/dash.js/v3.1.3/samples/dash-if-reference-player/index.html), where the original/test URL is from. To get the URL. Click **Stream -> Subtitles and Captions -> [DASH-IF] External VTT file**https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2869ges-launch-1.0 v1.22.1 cannot use v4l2h264enc2023-08-03T16:46:59ZVincent ACHARDges-launch-1.0 v1.22.1 cannot use v4l2h264encHello!
Trying to cut a h264/mp4 video using ges-launch-1.0 on a Raspberry Pi fails:
`ges-launch-1.0 +clip video.mp4 inpoint=1.0 duration=1.0 -o out.mp4 -f "video/quicktime:video/x-h264" `
Console Output:
```
ERROR from element v4l2...Hello!
Trying to cut a h264/mp4 video using ges-launch-1.0 on a Raspberry Pi fails:
`ges-launch-1.0 +clip video.mp4 inpoint=1.0 duration=1.0 -o out.mp4 -f "video/quicktime:video/x-h264" `
Console Output:
```
ERROR from element v4l2h264enc0: Failed to process frame./>
Debugging info: ../sys/v4l2/gstv4l2videoenc.c(828): gst_v4l2_video_enc_handle_frame (): /GESPipeline:gespipeline0/GstEncodeBin:internal-encodebin/v4l2h264enc:v4l2h264enc0:
Maybe be due to not enough memory or failing driver
```
- Custom minimalist aarch64 OS: uname -a: Linux (none) 5.10.14-v8+
- Raspberry Pi4
- Gstreamer 1.22.1
Dmesg output shows a kernel problem (v4l2h264enc)
I tried to force encoding level to 3 (because in gstreamer pipelines, a capsfilter after v4l2h264enc solves the problem), unsuccesfully:
```
ges-launch-1.0 +clip video.mp4 inpoint=1 duration=1 -o out.mp4 -f "video/quicktime:video/x-h264,level=(string)3"
ges-launch-1.0 --video-caps 'video/x-h264,level=(string)3' +clip video.mp4 inpoint=1 duration=1 -o out.mp4 -f "video/quicktime:video/x-h264"
ges-launch-1.0 --video-caps 'level=(string)3' +clip video.mp4 inpoint=1 duration=1 -o out.mp4 -f "video/quicktime:video/x-h264"
ges-launch-1.0 --video-caps 'video/x-h264,level=(string)3' +clip video.mp4 inpoint=1 duration=1 -o out.mp4
```
The problem here is more my lack of understanding of ges-launch syntax...
I asked a few months ago on the raspberrypi forum:
https://forums.raspberrypi.com/viewtopic.php?t=347790
I can recompile anything (kernel, gstreamer), do some tests, eager to help...
Cheershttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2868GstBase.BaseParse.do_handle_frame() results in a 'mini_object != NULL' asser...2023-07-28T15:46:32ZAntonio OspiteGstBase.BaseParse.do_handle_frame() results in a 'mini_object != NULL' assertionWhile experimenting with writing a parser in python ([dummyparse.py](/uploads/520a3edb0061cbf2fbde4b8498927613/dummyparse.py)) I get the following message when `GstBase.BaseParse.do_handle_frame()` is called:
```
(gst-launch-1.0:28584): ...While experimenting with writing a parser in python ([dummyparse.py](/uploads/520a3edb0061cbf2fbde4b8498927613/dummyparse.py)) I get the following message when `GstBase.BaseParse.do_handle_frame()` is called:
```
(gst-launch-1.0:28584): GStreamer-CRITICAL **: 12:58:24.009: gst_mini_object_ref: assertion 'mini_object != NULL' failed
```
I noticed (in another experiment) that the message does not show up if `do_handle_frame()` returns `Gst.FlowReturn.OK` without pushing any buffers.
The command line I am using is:
```
GST_PLUGIN_PATH=$GST_PLUGIN_PATH:$PWD \
gst-launch-1.0 fakesrc sizetype=fixed num-buffers=10 ! dummyparse ! fakesink
```
I tried looking where the issue comes from with:
```
G_DEBUG=fatal-criticals \
GST_PLUGIN_PATH=$GST_PLUGIN_PATH:$PWD \
gdb -ex run --args gst-launch-1.0 fakesrc sizetype=fixed num-buffers=10 ! dummyparse ! fakesink
```
And I get this trace:
```
#0 0x00007ffff7d87be5 in _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
#1 0x00007ffff7d88efd in g_logv
(log_domain=0x7ffff7f6d650 <g_log_domain_gstreamer> "GStreamer", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffff52876c0)
at ../../../glib/gmessages.c:1371
#2 0x00007ffff7d890cf in g_log
(log_domain=<optimized out>, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff7dd76bc "%s: assertion '%s' failed")
at ../../../glib/gmessages.c:1413
#3 0x00007ffff7d898f9 in g_return_if_fail_warning
(log_domain=<optimized out>, pretty_function=pretty_function@entry=0x7ffff7f7e170 <__func__.20440> "gst_mini_object_ref", expression=expression@entry=0x7ffff7f7deea "mini_object != NULL") at ../../../glib/gmessages.c:2762
#4 0x00007ffff7f08b72 in gst_mini_object_ref (mini_object=0x0) at ../subprojects/gstreamer/gst/gstminiobject.c:455
#5 0x00007ffff75012c2 in gst_buffer_ref (buf=<optimized out>) at ../subprojects/gstreamer/gst/gstbuffer.h:431
#6 0x00007ffff75012c2 in gst_base_parse_frame_copy (frame=0x555555986400) at ../subprojects/gstreamer/libs/gst/base/gstbaseparse.c:694
#7 0x00007ffff7cecb73 in g_boxed_copy (boxed_type=0x5555559ab270 [GstBaseParseFrame], src_boxed=0x555555986400) at ../../../gobject/gboxed.c:343
#8 0x00007ffff6a2b2ed in pygi_boxed_copy_in_place (self=0x7ffff544e108) at ../subprojects/pygobject/gi/pygi-boxed.c:219
#9 0x00007ffff6a30016 in pygi_marshal_cleanup_args_to_py_marshal_success (state=state@entry=0x7ffff5287900, cache=<optimized out>)
at ../subprojects/pygobject/gi/pygi-marshal-cleanup.c:156
#10 0x00007ffff6a2bb74 in _pygi_closure_handle (cif=<optimized out>, result=<optimized out>, args=<optimized out>, data=<optimized out>)
at ../subprojects/pygobject/gi/pygi-closure.c:589
#11 0x00007ffff78f26db in ffi_closure_unix64_inner () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#12 0x00007ffff78f2a56 in ffi_closure_unix64 () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#13 0x00007ffff75033b2 in gst_base_parse_handle_buffer
(parse=parse@entry=0x5555559a0e60 [dummyparse+DummyParse], buffer=<optimized out>, skip=skip@entry=0x7ffff5287c0c, flushed=flushed@entry=0x7ffff5287c10)
at ../subprojects/gstreamer/libs/gst/base/gstbaseparse.c:2202
#14 0x00007ffff75093ec in gst_base_parse_chain (pad=<optimized out>, parent=<optimized out>, buffer=<optimized out>)
at ../subprojects/gstreamer/libs/gst/base/gstbaseparse.c:3287
#15 0x00007ffff7f0efa2 in gst_pad_chain_data_unchecked (data=0x7ffff002b260, type=4112, pad=0x555555798310 [GstPad])
at ../subprojects/gstreamer/gst/gstpad.c:4326
#16 0x00007ffff7f0efa2 in gst_pad_push_data (pad=pad@entry=0x5555557980c0 [GstPad], type=type@entry=4112, data=data@entry=0x7ffff002b260)
at ../subprojects/gstreamer/gst/gstpad.c:4582
#17 0x00007ffff7f157a2 in gst_pad_push (pad=pad@entry=0x5555557980c0 [GstPad], buffer=0x7ffff002b260) at ../subprojects/gstreamer/gst/gstpad.c:4701
#18 0x00007ffff751fd25 in gst_base_src_loop (pad=0x5555557980c0 [GstPad]) at ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c:2966
#19 0x00007ffff7f42981 in gst_task_func (task=0x5555559bd170 [GstTask]) at ../subprojects/gstreamer/gst/gsttask.c:328
#20 0x00007ffff7daacc3 in g_thread_pool_thread_proxy (data=<optimized out>) at ../../../glib/gthreadpool.c:307
#21 0x00007ffff7daa325 in g_thread_proxy (data=0x555555985140) at ../../../glib/gthread.c:784
#22 0x00007ffff7cc2fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#23 0x00007ffff7bf389f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
I don't know enough to actually understand where the problem might be (if there is a problem).
The parser seems to work fine, the message is just *distracting* but I thought I'd report it anyway.
Thank you,
Antoniohttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2867GstToc can not be modified using pygobject2023-07-28T12:56:44ZBugzilla Migration UserGstToc can not be modified using pygobject## Submitted by Thomas Weißschuh `@t-8ch`
**[Link to original bug (#796889)](https://bugzilla.gnome.org/show_bug.cgi?id=796889)**
## Description
Created attachment 373196
reproduction case
When using pygobject it is not possi...## Submitted by Thomas Weißschuh `@t-8ch`
**[Link to original bug (#796889)](https://bugzilla.gnome.org/show_bug.cgi?id=796889)**
## Description
Created attachment 373196
reproduction case
When using pygobject it is not possible to create and modify and GstToc.
Modifications abort with:
(test.py:25237): GStreamer-CRITICAL **: 20:57:54.160: gst_toc_append_entry: assertion 'gst_mini_object_is_writable (GST_MINI_OBJECT_CAST (toc))' failed
The problem lies in the fact, that the GstToc is in reality a GstMiniObject.
Unfortunately there is no way to access the relevant methods/macros from python and raw casting from toc to miniobject is also not possible.
A reproduction case is attached.
**Attachment 373196**, "reproduction case":
[test.py](/uploads/7437fc40786b489654678a96d67d4a99/test.py)
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2866Adding Properties / cryptic PROP_02023-07-28T12:52:19ZVitaly IvanovAdding Properties / cryptic PROP_0I find Adding Properties (https://gstreamer.freedesktop.org/documentation/plugin-development/basics/args.html?gi-language=c) extremely rudimentary and unhelpful. I've spent more time trying to figure out (unsuccessfully) why there's unus...I find Adding Properties (https://gstreamer.freedesktop.org/documentation/plugin-development/basics/args.html?gi-language=c) extremely rudimentary and unhelpful. I've spent more time trying to figure out (unsuccessfully) why there's unused PROP_0 in the properties enum, which also presents in at least some Base GST elements (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst/audiotestsrc/gstaudiotestsrc.c#L117).
Neither Google nor chatGPT know anything about that, there's nothing in the docs, nothing in comments in the source code. Is it really required? Is property_id = 0 a reserved value?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2863dmabuf: get plane size calculated by v4l2videodec2023-08-08T09:14:07ZJeri Lidmabuf: get plane size calculated by v4l2videodec### Describe your issue
If use dma buffer, v4l2 decoder driver will calculate the CAPTURE buffer plane size once, the dma buffer is actually allocated by gstreamer and gstreamer has to calculate the plane size once again.
#### Expected...### Describe your issue
If use dma buffer, v4l2 decoder driver will calculate the CAPTURE buffer plane size once, the dma buffer is actually allocated by gstreamer and gstreamer has to calculate the plane size once again.
#### Expected Behavior
<!-- What did you expect to happen -->
in v4l2object, gstreamer will acquire format from v4l2videodec by ioctl API, here gstreamer can get the CAPTURE buffer plane size, and allocate CAPTURE buffer, no need to calculate itself. This can keep CAPTURE buffer plane size same.
```
if (is_mplane) {
for (i = 0; i < format.fmt.pix_mp.num_planes; i++)
GST_DEBUG_OBJECT (v4l2object->dbg_obj, " stride %d, sizeimage %d",
format.fmt.pix_mp.plane_fmt[i].bytesperline,
format.fmt.pix_mp.plane_fmt[i].sizeimage);
} else {
GST_DEBUG_OBJECT (v4l2object->dbg_obj, " stride %d, sizeimage %d",
format.fmt.pix.bytesperline, format.fmt.pix.sizeimage);
}
```
Especially, while there is v4l2convert plugin, for pipeline:
```
appsrc + v4l2videodec + v4l2convert + waylandsink
```
v4l2convert has to calculate the OUTPUT buffer plane size once again, so gstreamer/v4l2videodec/v4l2convert calcuate 3 times of plane size, it's duplicated and if one of them calculate error then playback fail. If the plane size formula has to change, these 3 modules all have to change code too.
#### Question
1) Why not get CAPTURE plane size from v4l2videodec plugin? The CAPTURE buffer plane size is produced by v4l2videodec, GStreamer and v4l2convert are both a user, they should follow v4l2videodec but no need calculate themself.
2) How to transfer the buffer plane size? By GstCaps or any other way ? Take into account multi plane size for multiplane format.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2861playsink: Integrate bayer2rgb and dsdconvert2023-07-27T12:22:20ZCarlos Rafael Gianiplaysink: Integrate bayer2rgb and dsdconvertFollowing the discussions from [the DSD merge request](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3901) and [this issue about DSD support](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/972), ...Following the discussions from [the DSD merge request](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3901) and [this issue about DSD support](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/972), fundamental DSD support is in place. However, DSD bits can be grouped into different formats. For example, DSDU32LE groups bits into 32-bit words. (These are not sample formats! See [GstDsdInfo](https://gstreamer.freedesktop.org/documentation//audio/gstdsd.html?gi-language=c#GstDsdInfo) for details about this.) If for example an ALSA device can handle DSDU32LE, but the incoming data has its bits grouped as DSDU16BE, then a conversion is needed, otherwise there is a not-negotiated error.
The `dsdconvert` element uses [gst_dsd_convert](https://gstreamer.freedesktop.org/documentation//audio/gstdsd.html?gi-language=c#gst_dsd_convert) to take care of this conversion. However, it needs to be integrated into playsink. Once that is done, DSD is fully covered by playbin and playsink - autoplugging would insert DSF / DFF parsers, and would detect if the downstream audio sink can handle DSD or not, inserting DSD->PCM elements if necessary. And, in case of hardware that can directly handle DSD, it would convert between grouping formats (DSDU8, DSDU32LE etc.) as needed.
Also, similarly, Bayer -> RGB conversion is needed to be able to fully support Bayer graphics out of the box. The `bayer2rgb` element needs to be integrated into `playsink` for this purpose.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2860gl: Need to add modifier support for glupload and gldownload2024-02-12T23:29:11ZHe Junyangl: Need to add modifier support for glupload and gldownloadThe new platform export the DRM's modifier to users now. For example, the GPU surface with the X tiling have the modifier of I915_FORMAT_MOD_X_TILED on Intel platforms. We need to set this kind of modifiers correctly when we share the DM...The new platform export the DRM's modifier to users now. For example, the GPU surface with the X tiling have the modifier of I915_FORMAT_MOD_X_TILED on Intel platforms. We need to set this kind of modifiers correctly when we share the DMA surfaces between different module, such as VA->3D. On old platform, this modifier stored inside libdrm but now we need to explicitly specify it.
We already have some patch for VA part: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2032
and according to @ndufresne , all the video-format/modifier should have "format:modifier" in caps, like:
```
video/x-raw(memory:DMABuf)
width: [ 16, 16384 ]
height: [ 16, 16384 ]
format: { (string)NV12:0x0100000000000002, (string)I420, (string)YV12, (string)YUY2:0x0100000000000002, (string)P010_10LE:0x0100000000000002, (string)BGRA:0x0100000000000002, (string)RGBA:0x0100000000000002, (string)BGR10A2_LE:0x0100000000000002, (string)VUYA:0x0100000000000002 }
```
We also need to add this to gl's DMA part.