gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2024-02-10T18:25:31Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3291Rust: make debug builds instead of --release builds for monorepo subpipelines?2024-02-10T18:25:31ZTim-Philipp Müllertim@centricular.comRust: make debug builds instead of --release builds for monorepo subpipelines?Not 100% sure, but I was wondering if we're currently always creating `--release` builds, and if so if there's a way to create debug builds instead?
Might save some CI cycles for monorepo sub-pipelines.
(In fact we might not need to bu...Not 100% sure, but I was wondering if we're currently always creating `--release` builds, and if so if there's a way to create debug builds instead?
Might save some CI cycles for monorepo sub-pipelines.
(In fact we might not need to build plugins-rs at all for any monorepo change that doesn't affect public API, but I guess that's another discussion)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3074qml6glsink: fps decrease compared to qt5 qmlglsink2023-10-26T10:48:47ZDeymos sqml6glsink: fps decrease compared to qt5 qmlglsink### 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/ -->
Significant decrease in FPS in qml6glsink relative to qmlglsink(qt5)
#### Expected Behavior
<!-- What did you expect to happen -->
rtsp is played with native fps, similar to what happens in vlc
#### Observed Behavior
<!-- What actually happened -->
FPS reduced by 20-40% relative to qt5 and FPS at source
#### Setup
- **Operating System:** Windows
- **Device:** Computer <!-- Delete as appropriate !-->
- **GStreamer Version:** 1.23.0
- **Command line:**
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. Play low-quality stream with qml6glsink
### How reproducible is the bug?
<!The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Always
### Screenshots if relevant
on left side qmlglsink, on right side qml6glsink, pipeline and code the same:
https://drive.google.com/file/d/1qdelYydk9ANxMX4I4ca4UzPTCu-UM_Oo/view?usp=sharing
### Additional Information
Video info:
Codec: H264 - MPEG-4 AVC (part 10)
Resolution: 960x576
framerate: 12
colors: ITU-R BT.709https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2845jpegenc: Slow Encoding Issue at Resolution Width=4192, Height=31202023-07-24T06:30:21ZSulthan Amanujpegenc: Slow Encoding Issue at Resolution Width=4192, Height=3120Dear Team,
I hope this email finds you well. I am writing to seek your assistance in resolving a performance issue related to the Gstreamer pipeline with the Jpegenc element. I have been working on capturing frames from an imx8 board ca...Dear Team,
I hope this email finds you well. I am writing to seek your assistance in resolving a performance issue related to the Gstreamer pipeline with the Jpegenc element. I have been working on capturing frames from an imx8 board camera device and encoding them using Gstreamer. However, when I use the Jpegenc element, I am experiencing a significant decrease in the frame rate.
Below, I have provided three different pipeline commands and their corresponding frame rates:
**1. Without Jpegenc (Frame Rate: 8)**
gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw, width=4192,height=3120 ! videoconvert ! tee name=t ! queue ! fpsdisplaysink sync=false
=false4192,height=3120 ! videoconvert ! tee name=t ! queue ! fpsdisplaysink sync
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:44.370671000
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
**Total showed frames (357), playing for (0:00:44.370925250), fps (8.046).**
**2. With Tee branch and without jpegenc (Frame Rate: 4.6)**
gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw, width=4192,height=3120 ! videoconvert ! tee name=t ! queue ! fpsdisplaysink sync=false t. ! queue ! fakesink
etting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:33.713813875
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
**Total showed frames (156), playing for (0:00:33.714091500), fps (4.627).**
Freeing pipeline ...
**3. With Jpegenc (Frame Rate: 0.4)**
gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,width=4192,height=3120 ! videoconvert ! tee name=t ! queue ! fpsdisplaysink sync=false t. ! queue ! jpegenc ! fakesink
=false t. ! queue ! jpegenc ! fakesink! tee name=t ! queue ! fpsdisplaysink sync
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:23.952335250
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
**Total showed frames (14), playing for (0:00:23.952648750), fps (0.584).**
The following elements are affected by the fakesink and fpsdisplaysink.
As you can see, the frame rate drops significantly when using Jpegenc. I have even tried adjusting the `idct-method` and `quality` properties, but the results are not as expected.
The details of my system are as follows:
- Gstreamer version: 1.14
- Linux version: Bionic
I am seeking your expertise to help identify the cause of this slowdown and suggest possible solutions to resolve the issue. Your assistance in this matter is highly appreciated.
Looking forward to your prompt response.
Thank you and best regards,
Sulthanhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2712Scaletempo 2x playback causes high CPU loading2023-06-30T07:51:27ZrlandjScaletempo 2x playback causes high CPU loadingOn an Android phone that I use on a daily basis (running Android O),
I have found that when playing at 2x speed, the CPU loading of the
entire GStreamer pipeline is relatively high, sometimes reaching around 60% cpu loading.
I used sim...On an Android phone that I use on a daily basis (running Android O),
I have found that when playing at 2x speed, the CPU loading of the
entire GStreamer pipeline is relatively high, sometimes reaching around 60% cpu loading.
I used simpleperf to run a callgraph hot spot map and found that the bottleneck
is in the best_overlap_offset_s16() function in gstscaletempo.c,almost 98% CPU loading is consumed by this function. Therefore, I came here to seek help from the knowledgeable experts on this forum. Is anyone familiar with NEON programming? Can you help me optimize this function using the SIMP instruction in NEON? I have no prior experience with NEON, but I do have a mobile device handy that I can use to compare the performance before and after optimization.
```
Arch: arm64
Event: cpu-cycles:u (type 0, config 0)
Samples: 30624
Event count: 23246964527
Children Self Command Pid Tid Shared Object Symbol
34.42% 0.00% amcaudiodec-c 17305 17427 /apex/com.android.runtime/lib/bionic/libc.so __start_thread
|
-- __start_thread
|
-- __pthread_start(void*)
g_thread_proxy
g_thread_pool_thread_proxy
gst_task_func
|--0.04%-- [hit in function]
|
--99.96%-- gst_amc_audio_dec_loop
|--0.13%-- [hit in function]
|
|--95.13%-- gst_audio_decoder_finish_frame
| |--0.14%-- [hit in function]
| |
| |--99.21%-- gst_audio_decoder_output
| | |--0.03%-- [hit in function]
| | |
| | --99.97%-- gst_audio_decoder_push_forward
| | |
| | |--99.92%-- gst_pad_push
| | | gst_pad_push_data
| | | |--0.01%-- [hit in function]
| | | |
| | | |--99.93%-- gst_pad_chain_data_unchecked
| | | | |--0.08%-- [hit in function]
| | | | |
| | | | |--99.78%-- gst_proxy_pad_chain_default
| | | | | |--0.08%-- [hit in function]
| | | | | |
| | | | | |--99.87%-- gst_pad_push
| | | | | | |
| | | | | | |--99.95%-- gst_pad_push_data
| | | | | | | |--0.01%-- [hit in function]
| | | | | | | |
| | | | | | | |--99.95%-- gst_pad_chain_data_unchecked
| | | | | | | | |
| | | | | | | | |--99.96%-- gst_proxy_pad_chain_default
| | | | | | | | | gst_pad_push
| | | | | | | | | |--0.02%-- [hit in function]
| | | | | | | | | |
| | | | | | | | | --99.98%-- gst_pad_push_data
| | | | | | | | | |
| | | | | | | | | |--99.89%-- gst_pad_chain_data_unchecked
| | | | | | | | | | |--0.02%-- [hit in function]
| | | | | | | | | | |
| | | | | | | | | | |--99.95%-- gst_concat_sink_chain
| | | | | | | | | | | |
| | | | | | | | | | | |--99.95%-- gst_pad_push
| | | | | | | | | | | | gst_pad_push_data
| | | | | | | | | | | | |
| | | | | | | | | | | | |--99.97%-- gst_pad_chain_data_unchecked
| | | | | | | | | | | | | |--0.02%-- [hit in function]
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |--99.91%-- gst_proxy_pad_chain_default
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |--99.92%-- gst_pad_push
| | | | | | | | | | | | | | | gst_pad_push_data
| | | | | | | | | | | | | | | |--0.02%-- [hit in function]
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |--99.97%-- gst_pad_chain_data_unchecked
| | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | |--99.93%-- gst_tee_chain
| | | | | | | | | | | | | | | | | |--0.05%-- [hit in function]
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | --99.95%-- gst_tee_handle_data
| | | | | | | | | | | | | | | | | |--0.06%-- [hit in function]
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | --99.94%-- gst_pad_push
| | | | | | | | | | | | | | | | | gst_pad_push_data
| | | | | | | | | | | | | | | | | |--0.01%-- [hit in function]
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |--99.93%-- gst_pad_chain_data_unchecked
| | | | | | | | | | | | | | | | | | |--0.02%-- [hit in function]
| | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | |--99.93%-- gst_stream_synchronizer_sink_chain
| | | | | | | | | | | | | | | | | | | |--0.05%-- [hit in function]
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |--99.88%-- gst_pad_push
| | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | |--99.98%-- gst_pad_push_data
| | | | | | | | | | | | | | | | | | | | | |--0.03%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | |--99.93%-- gst_pad_chain_data_unchecked
| | | | | | | | | | | | | | | | | | | | | | |--0.02%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |--99.88%-- gst_proxy_pad_chain_default
| | | | | | | | | | | | | | | | | | | | | | | gst_pad_push
| | | | | | | | | | | | | | | | | | | | | | | gst_pad_push_data
| | | | | | | | | | | | | | | | | | | | | | | |--0.03%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |--99.90%-- gst_pad_chain_data_unchecked
| | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | |--99.95%-- gst_base_transform_chain
| | | | | | | | | | | | | | | | | | | | | | | | | |--0.04%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | |--99.78%-- gst_pad_push
| | | | | | | | | | | | | | | | | | | | | | | | | | gst_pad_push_data
| | | | | | | | | | | | | | | | | | | | | | | | | | |--0.01%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | --99.99%-- gst_pad_chain_data_unchecked
| | | | | | | | | | | | | | | | | | | | | | | | | | |--0.02%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | |--99.95%-- gst_base_transform_chain
| | | | | | | | | | | | | | | | | | | | | | | | | | | |--0.01%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |--99.47%-- default_generate_output
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |--99.06%-- gst_scaletempo_transform
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |--0.18%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |--98.51%-- best_overlap_offset_s16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |--0.59%-- fill_queue
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |--6.43%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |--57.72%-- __memcpy_base_a55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |--22.51%-- gst_buffer_map
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gst_buffer_map_range
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |--26.49%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |--47.69%-- gst_memory_make_mapped
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gst_memory_map
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |--48.71%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --51.29%-- gst_mini_object_lock
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --25.82%-- _get_merged_memory
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gst_mini_object_ref
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --13.34%-- gst_buffer_unmap
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |--40.69%-- [hit in function]
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |--40.50%-- gst_mini_object_unlock
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --18.81%-- gst_memory_unmap
```
```
/* buffer padding for loop optimization: sizeof(gint32) * (loop_size - 1) */
#define UNROLL_PADDING (4*3)
static guint
best_overlap_offset_s16 (GstScaletempo * st)
{
gint32 *pw, *ppc;
gint16 *po, *search_start;
gint64 best_corr = G_MININT64;
guint best_off = 0;
guint off;
glong i;
pw = st->table_window;
po = st->buf_overlap;
po += st->samples_per_frame;
ppc = st->buf_pre_corr;
for (i = st->samples_per_frame; i < st->samples_overlap; i++) {
*ppc++ = (*pw++ * *po++) >> 15;
}
search_start = (gint16 *) st->buf_queue + st->samples_per_frame;
for (off = 0; off < st->frames_search; off++) {
gint64 corr = 0;
gint16 *ps = search_start;
ppc = st->buf_pre_corr;
ppc += st->samples_overlap - st->samples_per_frame;
ps += st->samples_overlap - st->samples_per_frame;
i = -((glong) st->samples_overlap - (glong) st->samples_per_frame);
do {
corr += ppc[i + 0] * ps[i + 0];
corr += ppc[i + 1] * ps[i + 1];
corr += ppc[i + 2] * ps[i + 2];
corr += ppc[i + 3] * ps[i + 3];
i += 4;
} while (i < 0);
if (corr > best_corr) {
best_corr = corr;
best_off = off;
}
search_start += st->samples_per_frame;
}
return best_off * st->bytes_per_frame;
}
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1646d3d11/GES: poor performance2022-12-09T20:43:36Zwatsonwelchd3d11/GES: poor performance### Describe your issue
GES does not appear to take advantage of hardware-accelerated d3d11 elements (such as d3d11h264dec and d3d11compositor) to create a zero-copy rendering pipeline. Playback of high-res/high-framerate video is very p...### Describe your issue
GES does not appear to take advantage of hardware-accelerated d3d11 elements (such as d3d11h264dec and d3d11compositor) to create a zero-copy rendering pipeline. Playback of high-res/high-framerate video is very poor.
#### Expected Behavior
I'd expect GES to use hardware-accelerated d3d11 elements to maximize performance.
#### Observed Behavior
GES appears to either not use the hardware-accelerated plugins, or CPU-copying (or otherwise degraded performance) is occurring somewhere in the pipeline.
#### Setup
- **Operating System:** Windows
- **GStreamer Version:** 1.21.3
- **Command line:**
### Steps to reproduce the bug
1. Download a high-res (e.g. 4K) and/or high-framerate (e.g. 60fps) video, such as [Netflix's "Sparks" open content](http://download.opencontent.netflix.com.s3.amazonaws.com/TechblogAssets/Sparks/encodes/Sparks_4096x2160_5994fps_SDR.mp4)
2. Open Windows PowerShell
3. Type `gst-launch-1.0 playbin uri=file:///path/to/Sparks_4096x2160_5994fps_SDR.mp4`
4. Observe that the video plays back normally (using hardware acceleration)
5. Type `$env:GST_PLUGIN_FEATURE_RANK="d3d11compositor:max"`
6. Type `$env:GST_PLUGIN_FEATURE_RANK="d3d11h264dec:max"`
7. Type `ges-launch-1.0 +clip Sparks_4096x2160_5994fps_SDR.mp4`
8. Observe that playback is extremely poor/choppy
### How reproducible is the bug?
Appears to be very reproducible with various 4K videos, on various devices.
### Related non-duplicate issues
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1117https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1535vah264dec + videoconvert is slow2022-11-15T13:35:00ZEric Knappvah264dec + videoconvert is slowConverting the output of vah264dec to anything with videoconvert is very slow. When resolution and framerate are high enough (e.g. 720p30), the conversion speed is less than realtime. Single core CPU usage hits 100%. The same pipeline wi...Converting the output of vah264dec to anything with videoconvert is very slow. When resolution and framerate are high enough (e.g. 720p30), the conversion speed is less than realtime. Single core CPU usage hits 100%. The same pipeline with vaapih264dec or vapostproc is much faster. I tried converting to multiple formats and they were all slow when vah264dec was paired with videoconvert. Logs do not show any issues.
#### Setup
- **Operating System:** Ubuntu 20.04.5
- **CPU:** i7-6700
- **GStreamer Version:** Main branch
SLOW:
`gst-launch-1.0 videotestsrc ! 'video/x-raw,width=1280,height=720,framerate=30/1' ! vah264enc ! queue ! h264parse ! vah264dec ! 'video/x-raw,format=NV12' ! videoconvert ! 'video/x-raw,format=UYVY' ! fakesink`
FAST (vaapih264dec):
`gst-launch-1.0 videotestsrc ! 'video/x-raw,width=1280,height=720,framerate=30/1' ! vah264enc ! queue ! h264parse ! vaapih264dec ! 'video/x-raw,format=NV12' ! videoconvert ! 'video/x-raw,format=UYVY' ! fakesink`
FAST (vapostproc):
`gst-launch-1.0 videotestsrc ! 'video/x-raw,width=1280,height=720,framerate=30/1' ! vah264enc ! queue ! h264parse ! vah264dec ! 'video/x-raw,format=NV12' ! vapostproc ! 'video/x-raw,format=UYVY' ! fakesink`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1390urisourcebin: Download-buffering trashes on fast network2022-11-10T09:21:15ZBastien Noceraurisourcebin: Download-buffering trashes on fast networkWhen download-buffering is enabled in playbin (through the `download` flag), accessing videos through HTTP will download the video as fast as possible, and write it to a local cache.
Unfortunately that means that it will try to download...When download-buffering is enabled in playbin (through the `download` flag), accessing videos through HTTP will download the video as fast as possible, and write it to a local cache.
Unfortunately that means that it will try to download hundreds of megs of data from local DLNA server, with the local cache being slow enough that this will cause performance problems until the download has finished. Ideally, `urisourcebin`/`downloadbuffer` would know how fast the disk and the network are so it can throttle its own download speed.
See https://gitlab.gnome.org/GNOME/totem/-/issues/496https://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.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2775deinterlace: tomsmocomp SSE2 code disabled because IS_SSE2 is never defined a...2023-07-06T11:15:42ZVivia Nikolaidoudeinterlace: tomsmocomp SSE2 code disabled because IS_SSE2 is never defined anywhereIn this line:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/gst/deinterlace/tvtime/tomsmocomp/tomsmocompmacros.h#L62
there is:
`#ifdef IS_SSE2`
but this doesn't seem to be defined anywhere, effectively disab...In this line:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/gst/deinterlace/tvtime/tomsmocomp/tomsmocompmacros.h#L62
there is:
`#ifdef IS_SSE2`
but this doesn't seem to be defined anywhere, effectively disabling the SSE2 code.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/536Implement more accurate clock waiting on Windows2022-11-10T09:21:01ZSebastian DrögeImplement more accurate clock waiting on WindowsSee https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/434#note_464772
> Windows may have a possible implementation using Waitable timers but that is not implemented here and instead falls back to the GCond implementati...See https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/434#note_464772
> Windows may have a possible implementation using Waitable timers but that is not implemented here and instead falls back to the GCond implementation. GCond waits on Windows is still as accurate as the previous GstPoll-based implementation.
Should indeed be possible around `SetWaitableTimer` and `WaitForMultipleObjects` (we can't wait just for the timer as that does not allow cancellation: cancelling a waitable timer causes all threads to continue waiting until timeout according to the documentation).https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/535registry: expensive plugin metadata loading2022-11-10T09:21:01ZEdward Herveyregistry: expensive plugin metadata loadingThe plugin metadata is known to be a structure of strings, but we go through the expensive `gst_structure_to_string`/`gst_structure_from_string` as a storage format.
`gst_structure_from_string()` represents over 36% (in callgrind instru...The plugin metadata is known to be a structure of strings, but we go through the expensive `gst_structure_to_string`/`gst_structure_from_string` as a storage format.
`gst_structure_from_string()` represents over 36% (in callgrind instruction calls) of reading the registry cache.
It would be more efficient to just use a simple/custom binary format to store/create those structures:
* byte with number of elements (to directly call gst_structure_new_empty())
* for each entry:
* For the name, either:
* '0' byte followed by one byte for GST_ELEMENT_METADATA_* (allows directly using quark for setting the value)
* '1' byte followed by 4 bytes for the length of the custom name, followed by the NULL-terminated string for the name
* 4 bytes with length of value (so we know how much follows)
* string null terminatedhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/521Cost of string fields in caps2021-09-24T11:08:51ZEdward HerveyCost of string fields in capsUsing strings in caps values introduce the following overhead:
* strdup for copying the value
* strcmp for comparing the values
* temporary memory copies (because of strdup) everywhere
Furthermore, those string values will be somewhat l...Using strings in caps values introduce the following overhead:
* strdup for copying the value
* strcmp for comparing the values
* temporary memory copies (because of strdup) everywhere
Furthermore, those string values will be somewhat limited (they are well-known types).
It would be worthwile to investigate using "interned" strings for the `G_TYPE_STRING` values in the `GstStructure` of `GstCaps`. This can be done by using `g_value_set_static_string()` which will internally avoid copies and allow fast string comparision.
This could be done by having a "private" `GHashTable` in `gstvalue.c` for those strings (instead of clashing with the global GQuark hashtable).
This might introduce a small memory increase (because of the hashtable) but which should mitigate the overall memory usage of string copies everywhere.
Note that this should *only* be done for **caps structures**. Other usages don't imply uniqueness of string values.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/519Reduce number of allocations for events/messages/queries/caps and structures ...2021-09-24T11:08:53ZEdward HerveyReduce number of allocations for events/messages/queries/caps and structures in general(Originally in https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/291)
# status
* structurefields are inlined in `GstStructure` : https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/392
* `GstValueList` and `GstVa...(Originally in https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/291)
# status
* structurefields are inlined in `GstStructure` : https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/392
* `GstValueList` and `GstValueArray` have been inlined : https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/402
# overview
Right now for events, messages and queries we have the following:
* One allocation for `GstEvent` (or `GstMessage` or `GstQuery`)
* One allocation for `GstStructure`
* One allocation for `GArray`
* Allocations for the contents of that array : `GQuark` + `GValue`
Ideally we should *fold* those altogether (like `GstBufferList` does) by inlining as much as possible in the top-level structure. Something like this :
``` c
typedef struct {
GstMessage message;
GstStructureImpl structure; /* Note: not a pointer */
} GstMessageImpl;
struct _GstStructureField /* Same as existing */
{
GQuark name;
GValue value;
};
typedef struct {
GstStructure s;
gint *parent_refcount;
guint fields_len;
guint fields_alloc;
GstStructureField *fields;
GstStructureField arr[1]; /* self-allocated, expands at the end */
} GstStructureImpl;
```
The above could improve:
* Locality of data
* Less micro-allocations (with the overhead of whatever slice/tcmalloc/whatever allocator you're using)
Note : Unfortunately `GArray` can't be *initialized* statically (i.e. you provide the pointer instead of glib allocating it). We also don't need some features (zero-terminated, destroynotify, ...) of it. So we could implemented our own `GstStructureArray` internal variant which would allow us to inline even more.
Note : This would also require modifying slightly how queries/events/messages are currently created. You'd have to first figure out the ideal number of fields to be allocated (including number of answer fields for queries and padding for some external users) and then fill in the structure.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2579avdec: better multi-threaded decoding performance for live pipelines where do...2023-05-18T11:34:29ZBugzilla Migration Useravdec: better multi-threaded decoding performance for live pipelines where downstream does not sync to clock## Submitted by Tim Müller `@tpm`
**[Link to original bug (#696501)](https://bugzilla.gnome.org/show_bug.cgi?id=696501)**
## Description
Currently we always use FF_THREAD_SLICE mode for multithreaded H.264 decoding.
This mode r...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#696501)](https://bugzilla.gnome.org/show_bug.cgi?id=696501)**
## Description
Currently we always use FF_THREAD_SLICE mode for multithreaded H.264 decoding.
This mode requires encoder support, so multiple threads will only be used if the H.264 video is encoded in a suitable way (i.e. with multiple slices per frame). This is not necessarily the case, and where this is not the case decoding will be done in a single thread only, hampering performance.
We should use FF_THREAD_SLICE only for live pipelines where latency is important, and use FF_THREAD_FRAME for decoding scenarios where latency does not matter, to make sure we actually use multiple threads for decoding if possible.
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=56206