GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-11-02T12:15:20Zhttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/390Creates meson cross file with host_machine.system() == 'ios' instead of 'darwin'2022-11-02T12:15:20ZSebastian DrögeCreates meson cross file with host_machine.system() == 'ios' instead of 'darwin'According to the documentation it should be 'darwin': https://mesonbuild.com/Reference-tables.html#operating-system-names
CC @xclaesse @nirbheekAccording to the documentation it should be 'darwin': https://mesonbuild.com/Reference-tables.html#operating-system-names
CC @xclaesse @nirbheekhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1485souphttpsrc: stall and high memory usage if upstream connection is fast2024-02-21T12:49:09ZArnaud Vracsouphttpsrc: stall and high memory usage if upstream connection is fastSince commit 0bcefa7350ef8fc, souhttpsrc will stall for an undefinite period of time and keep accumulating buffers internally if the upstream connection is fast enough. This is because the code relies on an idle source to trigger reading...Since commit 0bcefa7350ef8fc, souhttpsrc will stall for an undefinite period of time and keep accumulating buffers internally if the upstream connection is fast enough. This is because the code relies on an idle source to trigger reading from soup internal buffers using `g_input_stream_read_async`; in the case where the data can be downloaded very quickly from the server, the main loop might not trigger idle events for a long time, while soup accumulates data internally.
Additionally, the idle callback does not try to dequeue as much data as possible so only one read is done when the callback triggers.
Example (at interrupt 110MB were used by gst-launch):
```
# GST_DEBUG='soup*:7,queue2:6,uridecodebin:5' gst-launch -v souphttpsrc location=https://absolut.zogzog.org/share/1G ! fakesink silent=false
Setting pipeline to PAUSED ...
0:00:00.082892581 4761 0x838abc0 DEBUG souphttpsrc gstsouphttpsrc.c:2332:gst_soup_http_src_start:<souphttpsrc0> start("https://absolut.zogzog.org/share/1G")
0:00:00.083209620 4761 0x838abc0 DEBUG souphttpsrc gstsouphttpsrc.c:1156:gst_soup_http_src_session_open:<souphttpsrc0> Creating session (can share 1)
0:00:00.083415530 4761 0x838abc0 DEBUG souphttpsrc gstsouphttpsrc.c:1161:gst_soup_http_src_session_open:<souphttpsrc0> Created session 0x8306ea8
0:00:00.084049640 4761 0x838abc0 DEBUG souphttpsrc gstsouphttpsrc.c:1181:gst_soup_http_src_session_open:<souphttpsrc0> Waiting for thread to start...
0:00:00.084529470 4761 0x82e7928 DEBUG souphttpsrc gstsouphttpsrc.c:989:thread_func:<souphttpsrc0> thread start
0:00:00.086765908 4761 0x82e7928 DEBUG souphttpsrc gstsouphttpsrc.c:1087:_session_ready_cb:<souphttpsrc0> thread ready
0:00:00.087012528 4761 0x838abc0 DEBUG souphttpsrc gstsouphttpsrc.c:1184:gst_soup_http_src_session_open:<souphttpsrc0> Soup thread started
0:00:00.087141418 4761 0x838abc0 DEBUG souphttpsrc gstsouphttpsrc.c:1194:gst_soup_http_src_session_open:<GstSoupSession@0x8306ea8> Sharing session 0x8306ea8
0:00:00.087335958 4761 0x838abc0 DEBUG souphttpsrc gstsouphttpsrc.c:2395:gst_soup_http_src_set_context:<souphttpsrc0> Setting external session 0x8306ea8
0:00:00.087881797 4761 0x838abc0 DEBUG souphttpsrc gstsouphttpsrc.c:2442:gst_soup_http_src_get_size:<souphttpsrc0> get_size() = FALSE
0:00:00.088047987 4761 0x838abc0 DEBUG souphttpsrc gstsouphttpsrc.c:2488:gst_soup_http_src_do_seek:<souphttpsrc0> do_seek(0-18446744073709551615)
0:00:00.088136807 4761 0x838abc0 DEBUG souphttpsrc gstsouphttpsrc.c:2493:gst_soup_http_src_do_seek:<souphttpsrc0> Seek to current read/end position and no seek pending
Pipeline is PREROLLING ...
Got context from element 'souphttpsrc0': gst.soup.session=context, session=(GstSoupSession)NULL;
0:00:00.090859835 4761 0x82e7960 LOG souphttpsrc gstsouphttpsrc.c:1932:gst_soup_http_src_do_request:<souphttpsrc0> Running request for method: GET
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: stream-start (10254), GstEventStreamStart, stream-id=(string)bc3c4067f7177cbb9fdaceb2d86d28b714f82b1a725d6e27b5b8db0d5e17ed8d, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, group-id=(uint)1;) 0x76c02950
0:00:00.187350836 4761 0x82e7928 TRACE souputils gstsouputils.c:66:gst_soup_util_log_printer_cb:<GstSoupSession@0x8306ea8> HTTP_SESSION(M): > GET /share/1G HTTP/2
0:00:00.187888396 4761 0x82e7928 TRACE souputils gstsouputils.c:66:gst_soup_util_log_printer_cb:<GstSoupSession@0x8306ea8> HTTP_SESSION(M): > Soup-Debug-Timestamp: 1665162303
0:00:00.188134846 4761 0x82e7928 TRACE souputils gstsouputils.c:66:gst_soup_util_log_printer_cb:<GstSoupSession@0x8306ea8> HTTP_SESSION(M): > Soup-Debug: SoupSession 1 (0x82f6330), SoupMessage 1 (0x83aaf00), GSocket 1 (0x76c140f0)
0:00:00.188320226 4761 0x82e7928 TRACE souputils gstsouputils.c:66:gst_soup_util_log_printer_cb:<GstSoupSession@0x8306ea8> HTTP_SESSION(H): > User-Agent: GStreamer souphttpsrc 1.20.3.1 libsoup/3.2.0
0:00:00.188533656 4761 0x82e7928 TRACE souputils gstsouputils.c:66:gst_soup_util_log_printer_cb:<GstSoupSession@0x8306ea8> HTTP_SESSION(H): > Accept-Encoding: identity
0:00:00.188650696 4761 0x82e7928 TRACE souputils gstsouputils.c:66:gst_soup_util_log_printer_cb:<GstSoupSession@0x8306ea8> HTTP_SESSION(H): > icy-metadata: 1
0:00:00.188865185 4761 0x82e7928 TRACE souputils gstsouputils.c:66:gst_soup_util_log_printer_cb:<GstSoupSession@0x8306ea8> HTTP_SESSION(M):
0:00:00.196704730 4761 0x82e7928 INFO souphttpsrc gstsouphttpsrc.c:1383:gst_soup_http_src_got_headers:<souphttpsrc0> got headers
0:00:00.197537039 4761 0x82e7928 DEBUG souphttpsrc gstsouphttpsrc.c:1451:gst_soup_http_src_got_headers:<souphttpsrc0> size = 1073741824
0:00:00.198081909 4761 0x82e7928 DEBUG souphttpsrc gstsouphttpsrc.c:1537:gst_soup_http_src_got_headers:<souphttpsrc0> Content-Type: application/octet-stream
0:00:00.198483569 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:1908:gst_soup_http_src_send_message:<souphttpsrc0> Successfully got a reply
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: custom-downstream-sticky (76830), http-headers, uri=(string)https://absolut.zogzog.org/share/1G, http-status-code=(uint)200, request-headers=(structure)"request-headers\,\ User-Agent\=\(string\)\"GStreamer\\\ souphttpsrc\\\ 1.20.3.1\\\ libsoup/3.2.0\"\,\ Accept-Encoding\=\(string\)identity\,\ icy-metadata\=\(string\)1\;", response-headers=(structure)"response-headers\,\ Server\=\(string\)\"nginx/1.18.0\\\ \\\(Ubuntu\\\)\"\,\ Date\=\(string\)\"Fri\\\,\\\ 07\\\ Oct\\\ 2022\\\ 17:05:03\\\ GMT\"\,\ Content-Type\=\(string\)application/octet-stream\,\ Content-Length\=\(string\)1073741824\,\ Last-Modified\=\(string\)\"Mon\\\,\\\ 25\\\ Jan\\\ 2021\\\ 10:43:42\\\ GMT\"\,\ ETag\=\(string\)\"\\\"600ea0de-40000000\\\"\"\,\ Accept-Ranges\=\(string\)bytes\,\ strict-transport-security\=\(string\)\"max-age\\\=15768000\"\;";) 0x76c28990
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: custom-downstream-sticky (76830), http-context, user-agent=(string)"GStreamer\ souphttpsrc\ 1.20.3.1\ ";) 0x76c289d0
0:00:01.829610239 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2130:gst_soup_http_src_read_buffer:<souphttpsrc0> Read 4096 bytes from http input
0:00:01.829810409 4761 0x82e7960 LOG souphttpsrc gstsouphttpsrc.c:1994:gst_soup_http_src_check_update_blocksize:<souphttpsrc0> Checking to update blocksize. Read: 4096 bytes, blocksize: 4096 bytes, time since last read: 4:56:36.772971000
0:00:01.830280849 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2303:gst_soup_http_src_create:<souphttpsrc0> Returning 0 ok
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = event ******* (fakesink0:sink) E (type: segment (17934), GstEventSegment, segment=(GstSegment)"segment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)bytes, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)1073741824;";) 0x76c02b50
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = preroll *******
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (4096 bytes, dts: 0:00:00.000000000, pts: none, duration: none, offset: 0, offset_end: -1, flags: 00000040 discont , meta: none) 0x7620d000
0:00:05.391198168 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2130:gst_soup_http_src_read_buffer:<souphttpsrc0> Read 4096 bytes from http input
0:00:05.391459388 4761 0x82e7960 LOG souphttpsrc gstsouphttpsrc.c:1994:gst_soup_http_src_check_update_blocksize:<souphttpsrc0> Checking to update blocksize. Read: 4096 bytes, blocksize: 4096 bytes, time since last read: 0:00:03.561371000
0:00:05.391656428 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2018:gst_soup_http_src_check_update_blocksize:<souphttpsrc0> Decreased blocksize to 4096
0:00:05.391933258 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2303:gst_soup_http_src_create:<souphttpsrc0> Returning 0 ok
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 4096, offset_end: -1, flags: 00000000 , meta: none) 0x7620d0a8
0:00:12.280025073 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2130:gst_soup_http_src_read_buffer:<souphttpsrc0> Read 4096 bytes from http input
0:00:12.280287663 4761 0x82e7960 LOG souphttpsrc gstsouphttpsrc.c:1994:gst_soup_http_src_check_update_blocksize:<souphttpsrc0> Checking to update blocksize. Read: 4096 bytes, blocksize: 4096 bytes, time since last read: 0:00:06.888288000
0:00:12.280502793 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2303:gst_soup_http_src_create:<souphttpsrc0> Returning 0 ok
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 8192, offset_end: -1, flags: 00000000 , meta: none) 0x7620d150
0:00:12.282089982 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2130:gst_soup_http_src_read_buffer:<souphttpsrc0> Read 4096 bytes from http input
0:00:12.282591361 4761 0x82e7960 LOG souphttpsrc gstsouphttpsrc.c:1994:gst_soup_http_src_check_update_blocksize:<souphttpsrc0> Checking to update blocksize. Read: 4096 bytes, blocksize: 4096 bytes, time since last read: 0:00:00.001868000
0:00:12.282830051 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2006:gst_soup_http_src_check_update_blocksize:<souphttpsrc0> Increased blocksize to 8192
0:00:12.283045621 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2303:gst_soup_http_src_create:<souphttpsrc0> Returning 0 ok
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 12288, offset_end: -1, flags: 00000000 , meta: none) 0x7620d1f8
0:00:21.581647473 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2130:gst_soup_http_src_read_buffer:<souphttpsrc0> Read 8192 bytes from http input
0:00:21.581960993 4761 0x82e7960 LOG souphttpsrc gstsouphttpsrc.c:1994:gst_soup_http_src_check_update_blocksize:<souphttpsrc0> Checking to update blocksize. Read: 8192 bytes, blocksize: 8192 bytes, time since last read: 0:00:09.298853000
0:00:21.582249863 4761 0x82e7960 DEBUG souphttpsrc gstsouphttpsrc.c:2303:gst_soup_http_src_create:<souphttpsrc0> Returning 0 ok
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (8192 bytes, dts: none, pts: none, duration: none, offset: 16384, offset_end: -1, flags: 00000000 , meta: none) 0x7620d2a0
^Chandling interrupt.
Interrupt: Stopping pipeline ...
```
I've tried reverting the patch (there were conflicts so I'm not confident) and this solves the problem.
FYI thread safety of SoupSession was reintroduced in 3.2.0: https://libsoup.org/libsoup-3.0/client-thread-safety.htmlhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1486ci: support re-trying jobs in triggered cerbero sub-pipelines2022-11-09T18:25:25ZTim-Philipp Müllertim@centricular.comci: support re-trying jobs in triggered cerbero sub-pipelinesWhen a job in a cerbero sub-pipeline fails, the cerbero trigger job fails.
It's then not possible to re-run that job in the sub-pipeline and have the parent pipeline succeed, one always has to spawn a new cerbero pipeline and rebuild ev...When a job in a cerbero sub-pipeline fails, the cerbero trigger job fails.
It's then not possible to re-run that job in the sub-pipeline and have the parent pipeline succeed, one always has to spawn a new cerbero pipeline and rebuild everything from scratch (which takes about another hour give or take).
I wonder if it would be possible to make the [trigger_cerbero_pipeline.py script](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/ci/gitlab/trigger_cerbero_pipeline.py) ...
- first check if there are successful sub-pipelines already (e.g. from retrying a failed job on an existing sub-pipeline)
- next check if there are still-running sub-pipelines, and if so, wait on the last running one instead of triggering a new one
- only trigger a new sub-pipeline if there are no existing sub-pipelines or none that are successful or still in progress.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/249utils/fallbackswitch: apparent race condition2022-10-08T22:05:43ZFrançois Laignelutils/fallbackswitch: apparent race conditionSee https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/jobs/29523423See https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/jobs/29523423https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1488v4l2: Support for Raspberry Pi4 H265/HEVC Decoding2023-10-11T18:50:23Zbluestang2006v4l2: Support for Raspberry Pi4 H265/HEVC DecodingHello,
I am running into issues trying to get the recent GStreamer H265/HEVC Stateless decoder to work on my Raspberry Pi4.
Using the latest `rpi-6.0.y` [branch](https://github.com/raspberrypi/linux/tree/rpi-6.0.y) and this repo, I am...Hello,
I am running into issues trying to get the recent GStreamer H265/HEVC Stateless decoder to work on my Raspberry Pi4.
Using the latest `rpi-6.0.y` [branch](https://github.com/raspberrypi/linux/tree/rpi-6.0.y) and this repo, I am to compile and install all binaries to my Pi4.
However, when the v4l2slh265dec plugin is registered an error msg appears:
```
0:00:01.767247029 2492 0x557ef2de00 INFO v4l2codecs plugin.c:59:register_video_decoder:<v4l2decoder0> Registering rpivid-proc as H265 Decoder
0:00:01.767695641 2492 0x557ef2de00 WARN v4l2codecs-h265dec gstv4l2codech265dec.c:1663:gst_v4l2_codec_h265_dec_register: Not registering H265 decoder since it produces no supported format
```
The Pi4's H265/HEVC decoder seems to be using these formats:
```
v4l2-ctl -d 19 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture Multiplanar
[0]: 'NC12' (Y/CbCr 4:2:0 (128b cols))
[1]: 'NC30' (10-bit Y/CbCr 4:2:0 (128b cols))
[0]: V4L2_PIX_FMT_NV12_COL128 (8-bit)
[1]: V4L2_PIX_FMT_NV12_10_COL128 (10-bit)
```
Hopefully this is just a simple patch and wiring up the respective formats for GStreamer? Please help.
The code for the Pi4's HW H264/HEVC decoder is [here](https://github.com/raspberrypi/linux/tree/rpi-6.0.y/drivers/staging/media/rpivid).https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1489nvav1enc:Add support for av1 hardware encoding2024-02-27T18:28:27Z谢美龙nvav1enc:Add support for av1 hardware encodingThe 8th generation nvenc has added support for av1 encoding. [Support Matrix](https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new).
And rtpav1pay just released in gstreamer 1.21.1. The nvav1enc + rtpav1pay + web...The 8th generation nvenc has added support for av1 encoding. [Support Matrix](https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new).
And rtpav1pay just released in gstreamer 1.21.1. The nvav1enc + rtpav1pay + webrtc will be a nice combination.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1490baseparse: push frame after fatal error2022-10-17T07:57:13Zdiegonietobaseparse: push frame after fatal errorAfter the caps negotiation the baseparse pushes frames even if an error has ocurred.
This is something that does not happen in 1.16.3, but happens in 1.18.6 and above. I am able to reproduce it with pipelines like:
```
gst-launch-1.0 \
...After the caps negotiation the baseparse pushes frames even if an error has ocurred.
This is something that does not happen in 1.16.3, but happens in 1.18.6 and above. I am able to reproduce it with pipelines like:
```
gst-launch-1.0 \
--gst-plugin-load=<private-decoder> \
filesrc location=<h265 main 10 video file> ! \
h265parse ! \
video/x-h265,stream-format=hev1,alignment=nal ! \
<private-decoder-element> ! \
fakesink
```
In the last loop of `gst_base_parse_handle_and_push_frame` in gstbaseparse.c
```
if (G_UNLIKELY (!g_queue_is_empty (&parse->priv->queued_frames))) {
GstBaseParseFrame *queued_frame;
while ((queued_frame = g_queue_pop_head (&parse->priv->queued_frames))) {
gst_base_parse_push_frame (parse, queued_frame);
gst_base_parse_frame_free (queued_frame);
}
}
```
`parse->priv->queued_frames` contains several frames after the caps negotiation, so it tries to push (and decode) all the frames in the queue even if `gst_base_parse_push_frame`is returning an error.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1491mpegtsmux: exceeding CBR bitrate by the elementary stream2022-10-10T16:43:18Zcodinhompegtsmux: exceeding CBR bitrate by the elementary streamHello, we are using GStreamer for remuxing mpegts produced by some broadcasting HW, the output container is also mpegts.
We do know that mpegtsmux's CBR mode requires the overall output bitrate must be higher than bitrate of all elemen...Hello, we are using GStreamer for remuxing mpegts produced by some broadcasting HW, the output container is also mpegts.
We do know that mpegtsmux's CBR mode requires the overall output bitrate must be higher than bitrate of all elementary streams combined, but it seems that we are facing bitrate exceeding problem even if the mpegtsmux output bitrate was set correctly.
The problem looks as follows:
Here is the DVBInspector's bitrate chart view of the original stream:
![image](/uploads/f17478e4181a0b3853f2bfe4b15c725c/image.png)
And here is what we have after remuxing this stream with `filesrc ! tsdemux ! mpegtsmux ! filesink` pipeline:
![image](/uploads/2027fa942900835a2c588ad7e277b0a4/image.png)
As a result of bitrate peaks on the last pic the remuxed stream has timestamps problems exactly at the points where the peaks are presented.
PTS/DTS are too late for the generated by the mpegtsmux CBR implementation PCRs:
![image](/uploads/91c5ffcf255927b563035457fc6b2f75/image.png)
My questions:
1. Why this bitrate peaks may happen even if the original stream has no problems with timestamps?
2. The original stream looks really unusual for me, seems like the stream producing HW is "CBRing" elementary streams somehow so ES streams bitrate looks perfectly flat and video ES looks like it's CBR I frames only but it's actually not. Also there is no stuffing in the original stream. Is it possible to use paddings for elementary streams instead of mpegts stuffing with null packets?
Thanks in advance!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1492iOS GStreamer tutorial applications not compiling in Xcode 13.4.12023-04-17T13:54:10ZPushparaj JayaseelaniOS GStreamer tutorial applications not compiling in Xcode 13.4.1I'm trying to compile and run and sample application downloaded from GStreamer website but unfortunately not able to build the application at all.
![image](/uploads/26d70f5baf4730618e0f0c40051011af/image.png)
Pls some assist. Thanks in...I'm trying to compile and run and sample application downloaded from GStreamer website but unfortunately not able to build the application at all.
![image](/uploads/26d70f5baf4730618e0f0c40051011af/image.png)
Pls some assist. Thanks in advance!https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/250threadshare: pipeline test socket_play_null_play: apparent race condition2024-03-21T08:59:06ZFrançois Laignelthreadshare: pipeline test socket_play_null_play: apparent race conditionSee https://gitlab.freedesktop.org/fengalin/gst-plugins-rs/-/jobs/29569285See https://gitlab.freedesktop.org/fengalin/gst-plugins-rs/-/jobs/29569285https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1493h264parse: can not get the correct resolution in src caps for multi-resolutio...2022-10-18T13:36:15ZShiming Dongh264parse: can not get the correct resolution in src caps for multi-resolution streamsI am tring to decode a multi-resolution stream by gstreamer pipeline. But when the resolution changed during decoding, the decoder can NOT get the new width and height in src caps. I checked the function of **gst_h264_parse_update_src_ca...I am tring to decode a multi-resolution stream by gstreamer pipeline. But when the resolution changed during decoding, the decoder can NOT get the new width and height in src caps. I checked the function of **gst_h264_parse_update_src_caps** in gsth264parse.c, I found below code:
```/* sps should give this but upstream overrides */
2165 if (s && gst_structure_has_field (s, "width"))
2166 gst_structure_get_int (s, "width", &width);
2167 else
2168 width = h264parse->width;
2169
2170 if (s && gst_structure_has_field (s, "height"))
2171 gst_structure_get_int (s, "height", &height);
2172 else
2173 height = h264parse->height;```
The width and height in src caps are overrided by upstream caps instread of using the values in SPS, that's the reason why
decoder can not get the updated width and height. I have no idea why don't you directly use the crop_width and crop_height in SPS?
BTW, I am using the version of GStreamer 1.20.1
the OS is aarch64 GNU/Linuxhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1494Webrtc over h265 in Safari not working2023-10-12T20:59:08ZmgdelafuenteWebrtc over h265 in Safari not workingHello:
I am trying to do a communication from gstreamer to Safari browser using h265 codec in sendonly mode. I have previously tested this codec over webrtc so I am sure that the browser supports it since webkit implements it (checked wi...Hello:
I am trying to do a communication from gstreamer to Safari browser using h265 codec in sendonly mode. I have previously tested this codec over webrtc so I am sure that the browser supports it since webkit implements it (checked with https://github.com/webrtc/samples/tree/gh-pages/src/content/peerconnection/change-codecs).
I have started from the example in https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-examples/webrtc/sendonly/webrtc-unidirectional-h264.c modifying the pipeline. My final pipeline is as follows:
`webrtcbin name=webrtcbin videotestsrc ! videorate ! videoscale ! video/x-raw,width=640,height=360,framerate=15/1 ! videoconvert ! queue max-size-buffers=1 ! x265enc speed-preset=ultrafast ! video/x-h265,profile=main ! queue max-size-time=100000000 ! h265parse ! rtph265pay config-interval=-1 ! application/x-rtp,media=video,encoding-name=H265,payload=104 ! webrtcbin.`
When opening the browser I get a response to the offer it makes but the video does not start. The exchange of sdp messages is as follows:
Negotiation offer created:
```
v=0
o=- 3139870788961411982 0 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle
m=video 9 UDP/TLS/RTP/SAVPF 104
c=IN IP4 0.0.0.0
a=setup:actpass
a=ice-ufrag:U+LQ8nCvY6BLMk5WyDEtLvrV8316GDKG
a=ice-pwd:bi/+EvkAzGYw3hjnPbf1IFJoeM9nr+MJ
a=rtcp-mux
a=rtcp-rsize
a=sendonly
a=rtpmap:104 H265/90000
a=rtcp-fb:104 nack pli
a=rtcp-fb:104 transport-cc
a=framerate:15
a=fmtp:104 sprop-vps=QAEMAf//AWAAAAMAkAAAAwAAAwA/lZQJ;sprop-sps=QgEBAWAAAAMAkAAAAwAAAwA/oAUCAXHy5ZWVKTC//AAEAAWoMDAwIAAAAwAgAAADAeE=;sprop-pps=RAHAc8GJ
a=ssrc:675092278 msid:user2875715355@host-224904eb webrtctransceiver0
a=ssrc:675092278 cname:user2875715355@host-224904eb
a=mid:video0
a=fingerprint:sha-256 9D:76:AA:8F:0B:0E:13:62:39:1E:EB:F0:37:1D:EA:EC:08:AF:55:C3:91:A5:D8:A8:B2:A0:33:56:0A:F5:F9:BF
a=rtcp-mux-only
```
Received SDP:
```
v=0
o=- 819066822958699861 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS
m=video 9 UDP/TLS/RTP/SAVPF 104
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:EGPk
a=ice-pwd:O4oCuUmeXLA/3BxXEO86inXZ
a=ice-options:trickle
a=fingerprint:sha-256 7F:EE:88:1C:61:D5:9C:73:D2:39:C4:D5:80:4E:5F:A6:99:20:12:38:39:5C:01:5E:A5:6B:E9:BF:E4:5B:36:E9
a=setup:active
a=mid:video0
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:104 H265/90000
a=rtcp-fb:104 transport-cc
a=rtcp-fb:104 nack pli
```
My last log in the example is:
`Received ICE candidate with mline index 0; candidate: candidate:1283376487 1 udp 2122260223 b755ed98-c42c-4e75-a1e6-fb1a9600383c.local 61936 typ host generation 0 ufrag EGPk network-id 1 network-cost 50`
but nothing happens.
Thanks in advancehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1496av1parse: Correct the pts for frames inside a super frame.2024-01-22T07:42:05ZSebastian Drögeav1parse: Correct the pts for frames inside a super frame.The following discussion from !3155 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3155#note_1587332): (+6 comments)
> Copying from another discussion t...The following discussion from !3155 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3155#note_1587332): (+6 comments)
> Copying from another discussion thread here
>
> > And AV1 has the same issue, which I need to improve. For the big input buffer, such as the super frame here and the whole TU buffer in AV1, when we split them into frames for the decoder, only the first frame has the correct PTS, and the left all have invalid PTS. But for most of the time(Spec really does not say that :smile: ), the last one is the only frame need to display.
CC @He_Junyanhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1498rtsp-server: If media with eos-shutdown=true is still waiting for EOS to prop...2022-10-14T12:29:25ZSebastian Drögertsp-server: If media with eos-shutdown=true is still waiting for EOS to propagate, new client will receive "Service Unavailable"E.g.
```
0:00:13.742991668 1147 0xd05d88 INFO rtspmedia rtsp-media.c:3151:set_target_state: set target state to NULL for media 0x714221b8
0:00:13.743036335 1147 0xd05d88 DEBUG rtspmedia rtsp-media.c:2791...E.g.
```
0:00:13.742991668 1147 0xd05d88 INFO rtspmedia rtsp-media.c:3151:set_target_state: set target state to NULL for media 0x714221b8
0:00:13.743036335 1147 0xd05d88 DEBUG rtspmedia rtsp-media.c:2791:gst_rtsp_media_set_status: setting new status to 1
0:00:13.743071002 1147 0xd05d88 DEBUG rtspmedia rtsp-media.c:4065:default_unprepare: sending EOS for shutdown
[...]
0:00:32.033201670 1147 0x6f018288 INFO rtspclient rtsp-client.c:3979:handle_request: client 0xccfce8: received a request DESCRIBE rtsp://192.168.0.1/test 1.0
0:00:32.034636337 1147 0x6f018288 INFO rtspmediafactory rtsp-media-factory.c:1452:gst_rtsp_media_factory_construct: constructed media 0x714221b8 for url /test
0:00:32.036173004 1147 0x6f018288 WARN rtspmedia rtsp-media.c:3937:gst_rtsp_media_prepare: media 0x714221b8 was not unprepared
```
Here it took >20s for the media to shut down, which is a bug in itself. But even under normal conditions there is a race condition here between sending the EOS event, receiving the EOS message, and new clients connecting in the meantime.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/414ci: Check what can be done to improve the runtime on Windows2022-10-14T16:00:31ZSebastian Drögeci: Check what can be done to improve the runtime on Windows```
<daniels> slomo: hey, is there a way that you can cache cargo output in gst-rs pipelines? right now it looks like every single pipeline occupies 2h runtime on the windows machines ... https://gitlab.freedesktop.org/slomo/gstreamer-rs...```
<daniels> slomo: hey, is there a way that you can cache cargo output in gst-rs pipelines? right now it looks like every single pipeline occupies 2h runtime on the windows machines ... https://gitlab.freedesktop.org/slomo/gstreamer-rs/-/pipelines/711505/builds
<slomo> daniels: i don't think there's anything cacheable in those CI jobs. i'll check with alatiera_afk[m] when he's back if there's something that can be sped up
<slomo> maybe can just run fewer configuration on windows
```
The same probably also applies for `gst-plugins-rs`.
CC @alatiera @danielshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/251fallbacksrc fails to connect using a known working RTSP axis camera link. Ch...2022-10-29T14:43:02ZSonnyWalkmanfallbacksrc fails to connect using a known working RTSP axis camera link. Changing source state: NullToNull. Works fine with rtspsrcHi,
I've experienced an issue using fallbacksrc for a RSTP link. Continues to show fallback uri which is expected.
gstreamer 1.20.3 base with latest git pull for fallbackswitch.
```
GST_DEBUG=fallbacksrc:9 gst-launch-1.0 fallbacksrc uri...Hi,
I've experienced an issue using fallbacksrc for a RSTP link. Continues to show fallback uri which is expected.
gstreamer 1.20.3 base with latest git pull for fallbackswitch.
```
GST_DEBUG=fallbacksrc:9 gst-launch-1.0 fallbacksrc uri="rtsp://192.168.1.xxx/axis-media/media.amp user-id=xxxx user-pw=xxxx drop-on-latency=1 latency=1000" \
fallback-uri=file:///$HOME/images/nosignal-720p.png \
! queue max-size-buffers=0 max-size-time=10 \
! video/x-raw,width=1280,height=720,format=I420,framerate=25/1 \
! videoconvert ! waylandsink
```
Link works fine using rtspsrc with decode chain behind rtspsrc however couldn't use decodebin3 due to vaapi and opted to use software h264 decoder.
Running Ubuntu and only recently updated to 22.04 LTS and noticed the vaapi plugins having issues with wayland? which could be related to the incompatibility with hardware vaapi decoder??
Log attached.[fallbacksrc.log](/uploads/45e991a4aefcd7e7f190e1c385800a4f/fallbacksrc.log)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1501Error `undefined reference to `libintl_dngettext' ` in alpine2023-01-25T11:39:14ZGolubev MatveiError `undefined reference to `libintl_dngettext' ` in alpineHellol. I will build static gstriamer in alpine docker container. I have thist error:
## Run:
```sh
meson \
--buildtype=release \
--strip \
--default-library=static \
--wrap-mode=forcefallback \
-Dauto_features=disabled \
-Dgst-full-libr...Hellol. I will build static gstriamer in alpine docker container. I have thist error:
## Run:
```sh
meson \
--buildtype=release \
--strip \
--default-library=static \
--wrap-mode=forcefallback \
-Dauto_features=disabled \
-Dgst-full-libraries=videotestsrc,fakesink \
-Dbase=enabled \
-Dgst-plugin-base:videotestsrc=enabled \
builddir
ninja -C builddir
```
## Error:
```sh
[1132/1492] Linking static target subprojects/zlib-1.2.11/libz.a
../subprojects/pcre-8.37/pcre_study.c: In function 'set_start_bits':
../subprojects/pcre-8.37/pcre_study.c:1368:35: warning: '<<' in boolean context, did you mean '<'? [-Wint-in-bool-context]
1368 | if ((map[c/8] && (1 << (c&7))) != 0)
| ~~~^~~~~~~~~
[1133/1492] Linking target subprojects/pcre-8.37/dftables
[1134/1492] Generating subprojects/pcre-8.37/chartables with a custom command
[1135/1492] Compiling C object subprojects/pcre-8.37/libpcre.a.p/meson-generated_.._pcre_chartables.c.o
[1136/1492] Linking static target subprojects/libffi/src/libffi.a
../subprojects/pcre-8.37/pcre_compile.c: In function 'compile_regex':
../subprojects/pcre-8.37/pcre_compile.c:4814:29: warning: array subscript -1 is outside array bounds of 'const pcre_uchar[10]' {aka 'const unsigned char[10]'} [-Warray-bounds]
4814 | ptr = sub_end_of_word - 1;
| ~~~~~~~~~~~~~~~~^~~
../subprojects/pcre-8.37/pcre_compile.c:270:25: note: while referencing 'sub_end_of_word'
270 | static const pcre_uchar sub_end_of_word[] = {
| ^~~~~~~~~~~~~~~
../subprojects/pcre-8.37/pcre_compile.c:4807:31: warning: array subscript -1 is outside array bounds of 'const pcre_uchar[9]' {aka 'const unsigned char[9]'} [-Warray-bounds]
4807 | ptr = sub_start_of_word - 1;
| ~~~~~~~~~~~~~~~~~~^~~
../subprojects/pcre-8.37/pcre_compile.c:266:25: note: while referencing 'sub_start_of_word'
266 | static const pcre_uchar sub_start_of_word[] = {
| ^~~~~~~~~~~~~~~~~
[1137/1492] Linking static target libgstreamer-full-1.0.a
[1138/1492] Linking static target subprojects/glib/glib/libglib-2.0.a
[1139/1492] Linking static target subprojects/pcre-8.37/libpcre.a
[1140/1492] Linking target subprojects/pcre-8.37/pcretest
[1141/1492] Linking target libgstreamer-full-1.0.so
[1142/1492] Linking target subprojects/gst-plugins-base/gst-libs/gst/tag/mklicensestables
[1143/1492] Linking target subprojects/gstreamer/docs/gst-hotdoc-plugins-scanner
[1144/1492] Linking target subprojects/gstreamer/libs/gst/helpers/gst-ptp-helper
[1145/1492] Linking target subprojects/gstreamer/libs/gst/helpers/gst-plugin-scanner
[1146/1492] Linking target subprojects/glib/tests/unicode-collate
[1147/1492] Linking target subprojects/glib/tests/assert-msg-test
[1148/1492] Linking target subprojects/glib/tests/slice-color
[1149/1492] Linking target subprojects/glib/tests/slice-test
[1150/1492] Linking target subprojects/glib/tests/iochannel-test
ninja: job failed: cc -o subprojects/glib/tests/assert-msg-test subprojects/glib/tests/assert-msg-test.p/assert-msg-test.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wl,--start-group subprojects/glib/glib/libglib-2.0.a subprojects/pcre-8.37/libpcre.a -lm -Wl,--end-group -pthread
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: subprojects/glib/glib/libglib-2.0.a(ggettext.c.o): in function `g_dgettext':
ggettext.c:(.text+0xae): undefined reference to `libintl_textdomain'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ggettext.c:(.text+0xbd): undefined reference to `libintl_gettext'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: subprojects/glib/glib/libglib-2.0.a(ggettext.c.o): in function `glib_gettext':
ggettext.c:(.text+0x1a5): undefined reference to `libintl_bindtextdomain'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ggettext.c:(.text+0x1b4): undefined reference to `libintl_bind_textdomain_codeset'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: subprojects/glib/glib/libglib-2.0.a(ggettext.c.o): in function `glib_pgettext':
ggettext.c:(.text+0x325): undefined reference to `libintl_bindtextdomain'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ggettext.c:(.text+0x334): undefined reference to `libintl_bind_textdomain_codeset'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: subprojects/glib/glib/libglib-2.0.a(ggettext.c.o): in function `g_dcgettext':
ggettext.c:(.text+0x50a): undefined reference to `libintl_textdomain'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ggettext.c:(.text+0x519): undefined reference to `libintl_gettext'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: subprojects/glib/glib/libglib-2.0.a(ggettext.c.o): in function `g_dngettext':
ggettext.c:(.text+0x646): undefined reference to `libintl_textdomain'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ggettext.c:(.text+0x657): undefined reference to `libintl_gettext'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: subprojects/glib/glib/libglib-2.0.a(ggettext.c.o): in function `g_dgettext':
ggettext.c:(.text+0x8d): undefined reference to `libintl_dgettext'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: subprojects/glib/glib/libglib-2.0.a(ggettext.c.o): in function `g_dcgettext':
ggettext.c:(.text+0x4dd): undefined reference to `libintl_dcgettext'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: subprojects/glib/glib/libglib-2.0.a(ggettext.c.o): in function `g_dngettext':
ggettext.c:(.text+0x62b): undefined reference to `libintl_dngettext'
collect2: error: ld returned 1 exit status
...
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1505matroskademux: subrip subtitles may be rendered with XML tags2022-10-17T11:17:04ZAlexander Slobodeniukmatroskademux: subrip subtitles may be rendered with XML tags### Describe your issue
We have a file, it's muxed with ffmpeg, and contains SubRip subtitles (from an srt file): [SampleVideo_640x480_1mb.mkv](/uploads/87c6b034141786abea7284667f71966a/SampleVideo_640x480_1mb.mkv)
VLC can play this fil...### Describe your issue
We have a file, it's muxed with ffmpeg, and contains SubRip subtitles (from an srt file): [SampleVideo_640x480_1mb.mkv](/uploads/87c6b034141786abea7284667f71966a/SampleVideo_640x480_1mb.mkv)
VLC can play this file without issues
![mkv-vlc](/uploads/5711bd8e34c92e9cff0bd303681617cf/mkv-vlc.jpg)
But if we play it with gst-play-1.0, we can see the XML tags rendered together with the subtitle text.
![mkv-gst](/uploads/1b3a29cc33184a92c5473a1335eb76a5/mkv-gst.jpg)
#### Expected Behavior
Only the text of the subtitles is rendered
#### Observed Behavior
Rendered text contains unhandled xml tags
#### Setup
- **Operating System:** Any
- **Device:** Any
- **GStreamer Version:** Any
- **Command line:** `gst-play-1.0 SampleVideo_640x480_1mb.mkv`
### Steps to reproduce the bug
1. open terminal
2. type `gst-play-1.0 SampleVideo_640x480_1mb.mkv`
3. check if the subtitles have been rendered as expected
### How reproducible is the bug?
Always
### Additional Information
Subtitles are correctly muxed and have codec id of the SubRip format: [S_TEXT/UTF8](https://tools.ietf.org/id/draft-ietf-cellar-codec-04.html#name-srt-subtitles)
When matroskademux element opens this file, for subtitles stream it [exposes pango-markup caps](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/gst/matroska/matroska-demux.c#L7335)
```c
...
if (!strcmp (codec_id, GST_MATROSKA_CODEC_ID_SUBTITLE_UTF8)) {
/* well, plain text simply does not have a lot of markup ... */
caps = gst_caps_new_simple ("text/x-raw", "format", G_TYPE_STRING,
"pango-markup", NULL);
context->postprocess_frame = gst_matroska_demux_check_subtitle_buffer;
subtitlecontext->check_markup = TRUE;
...
```
This particular action (saying that SubRip is a pango markup) is wrong: SubRip has it's own markup, and it's not always compatible with pango, and the file attached is the case.
### About the fix (provided in the PR)
If we open with GStreamer an srt file with the same subtitles, it doesn't have this issue, because the input is handled by a **subparse** element, that converts different subtitle formats to pango-markup and also **throws away unknown markups**.
An idea of the fix proposed in the [MR](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3198) is to make **subparse** element autoplug after **matroskademux** and make the convertion SubRip --> pango-markup. To do that we do 2 things:
1. Instead of "pango-markup" expose from **matroskademux** some new format, let's call it "text/x-subrip-muxed" (do you know, maybe there's already some existing format for it?).
NOTE: We can't use "application/x-subtitle" that is used for srt files, because it's slightly different: the data of such format is supposed to have a number and a timestamp inside of the text.
2. Make **subparse** element handle "text/x-subrip-muxed".
### PS
Apart from not rendering unhandled xml tags it also would be nice to actually handle them.
This Issue is pretty convenient for this, because the steps to reproduce are the same.
However, we prefer to go step-by-step, so first let's just fix the bug, and then maybe add a new support.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1506rtspsrc: Different npt-range (npt-start and npt-stop) in SETUP and PLAY reque...2022-11-07T11:42:21Zpalkimrtspsrc: Different npt-range (npt-start and npt-stop) in SETUP and PLAY request while getting videos from NVRHi,
I am trying to get recorded videos by using gstreamer from a NVR (network video recorder). I am sending start and end time with my location url, which is fine and works with ffmeg ffplay well. However I want to use gstreamer and I c...Hi,
I am trying to get recorded videos by using gstreamer from a NVR (network video recorder). I am sending start and end time with my location url, which is fine and works with ffmeg ffplay well. However I want to use gstreamer and I cannot get the recorded videos. After checking debug logs of my NVR I see that gstreamer sends the correct time with RTSP SETUP request to NVR. However it sends a totally different time with RTSP PLAY request after SETUP.
npt-start and npt-stop range changes after RSTP SETUP and before RTSP play. If I query for 2022 for example, in SETUP it is true with months day etc.., in PLAY request I see that it changed to 2145 with also wrong day month etc...
I thought this could be an issue, if not I am sorry I cannot show that it is an issue for now.
Here is my pipeline for reference:
gst-launch-1.0 rtspsrc location="rtsp://<nvr-url>:<port>/?uuid=<camera-uuid>&startTime=YYYYMMDDHHMMSSSSS&endTime=YYYYMMDDHHMMSSSSS" ! rtph264depay ! h264parse ! avdec_h264 ! autovideosink
time format: Year(4 digit)Month(2 digit)Day(2 digit)Hour(2 digit)Minute(2 digit)S(5 digit)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1507ges: Various functions that return a GError don't set it in all error paths2022-10-17T17:09:08ZSebastian Drögeges: Various functions that return a GError don't set it in all error pathsExamples are `ges_clip_add_child_to_track()` and `ges_timeline_new_from_uri()`. They return `NULL` in various cases without setting the `GError`.
If returning `NULL` should not be considered an error but normal behaviour then it would b...Examples are `ges_clip_add_child_to_track()` and `ges_timeline_new_from_uri()`. They return `NULL` in various cases without setting the `GError`.
If returning `NULL` should not be considered an error but normal behaviour then it would be necessary to mark the return value as `nullable`, if all `NULL` cases should be considered an error then it must not be marked as `nullable`.