Debian Patches
Status for kpipewire/6.3.6-1
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| upstream_686df1e3_Tweak-compiler-warning-flags-to-reduce-unneeded-output.patch | [PATCH] Tweak compiler warning flags to reduce unneeded output -Wno-gnu-statement-expression-from-macro-expansion and -Wno-c99-extensions are non-existent options that add more noise than they fix. Additionally, -Wpedantic is enabled by default which causes a lot of noise, so disable that. Finally, add -Wno-missing-field-initializers to quiet down the final bits of PipeWire API. |
Arjen Hiemstra <ahiemstra@heimr.nl> | no | 2025-03-20 | ||
| upstream_52911b70_Change-Encoder-applyEncodingPreference-to-buildEncodingOptions-.patch | [PATCH] Change Encoder::applyEncodingPreference() to buildEncodingOptions() As it turns out, FFmpeg does something to the pointers here that causes the dictionary to never be properly used. This means we were never applying the encoding options, as avcodec_open() was passed a nullptr for options. Fix this by changing the function to return an AVDictionary* instead of trying to modify a passed-in pointer. This results in a proper dict being returned, that can then be passed to avcodec_open(). The main result of this is that we now properly apply the encoding options for VP9 encoding, which means we can now encode VP9 at realtime speeds instead of it massively lagging behind. |
Arjen Hiemstra <ahiemstra@heimr.nl> | no | upstream | 2025-03-20 | |
| upstream_c928ed5c_Add-logging-of-encoding-options-if-log-level-is-set-to-info.patch | [PATCH] Add logging of encoding options if log level is set to info Allows inspecting what's actually sent to FFmpeg. |
Arjen Hiemstra <ahiemstra@heimr.nl> | no | 2025-03-20 | ||
| upstream_f127a2cc_Set-threads-option-by-default-in-Encoder.patch | [PATCH] Set "threads" option by default in Encoder So we don't have to repeat this in other encoders. |
Arjen Hiemstra <ahiemstra@heimr.nl> | no | 2025-03-20 | ||
| upstream_5a223fe4_Port-Encoder-away-from-deprecated-avcodec-close.patch | [PATCH] Port Encoder away from deprecated avcodec_close | Arjen Hiemstra <ahiemstra@heimr.nl> | no | 2025-03-20 | ||
| upstream_123ae0d2_Tweak-encoding-options-for-VP9.patch | [PATCH] Tweak encoding options for VP9 Don't set both bitrate and CRF, as they are conflicting settings. Instead only set CRF. Also enable row-mt and avoid modifying the codec context in a function that is about options. |
Arjen Hiemstra <ahiemstra@heimr.nl> | no | 2025-03-20 | ||
| upstream_0ac4aa41_encodedstream-Deprecate-setActive-and-replace-with-an-explicit-API.patch | [PATCH] encodedstream: Deprecate setActive() and replace with an explicit API setActive() currently implies starting/stopping the recording process. However, this is somewhat awkward as everything is rather asynchronous with multiple threads involved, which means calling setActive() may mean things are not actually active or may still be active. To avoid this awkwardness, deprecate setActive() and replace it with an explicit start() and stop() method that are clearly documented to be purely requests, with the real active/inactive state matching the stream state. This also makes the "Rendering" state more explicit, when "Stop" is called we immediately switch to the "Rendering" state to indicate we may still be processing frames but are no longer receiving new frames. |
Arjen Hiemstra <ahiemstra@heimr.nl> | no | 2024-10-08 | ||
| upstream_8793ae86_encodedstream-Don-t-query-VAAPI-in-the-constructor.patch | [PATCH] encodedstream: Don't query VAAPI in the constructor Querying VAAPI is expensive, so we should only do that when necessary. So rather than querying what encoder to use on construction, query it on start and only if we don't already have an encoder set. This also avoids duplicate lookups if the user already set the encoder. |
Arjen Hiemstra <ahiemstra@heimr.nl> | no | 2024-10-08 | ||
| upstream_9fe7a568_Adjust-timers-from-the-correct-thread.patch | [PATCH] Adjust timers from the correct thread PipeWireBaseEncodedStream moves the PipeWireProduce into another thread. It is therefore it's responsiblity to ensure that any calls into PipeWireProduce are run in the correct thread. This addresses a warning about timers. |
David Edmundson <kde@davidedmundson.co.uk> | no | 2025-06-26 |