April 2025 - wine-gitlab

[PATCH 0/9] MR7835: win32u: Implement generic OpenGL context functions.
by Rémi Bernon (＠rbernon) 16 Apr '25

16 Apr '25

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/7835

3 11

[PATCH 0/1] MR7827: imm32: Fix the WM_IME_COMPOSITION messages to be between the WM_IME_{START|END}COMPOSITION message.
by Byeongsik Jeon (＠bsjeon) 16 Apr '25

16 Apr '25

This patch fixes a Japanese input issue in MS Office Visual Basic and Mery text editor ime inline mode. The following was considered: 1. Japanese ime: the result string message is always placed between WM_IME_STARTCOMPOSITION and WM_IME_ENDCOMPOSITION. Currently in Wine, the result string message follows WM_IME_ENDCOMPOSITION. dlls/imm32/tests/imm32.c::test_nihongo_no(). 2. Chinese ime: same as Japanese ime. 3. Korean ime: mostly the same, but there are some cases where it is not (e.g. CPS_COMPLETE, 'r-k-RETURN'). However, I haven't found any problem even if it behave like Japanese ime message order. 3. zero-length preedit string: as in MR !3115 commit d1f9aae, the message followed by WM_IME_ENDCOMPOSITION. Currently in Wine, it is associated with WM_IME_STARTCOMPOSITION. 4. zero-length result string: ignore. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7827

3 5

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Brendan McGrath (＠redmcg) 16 Apr '25

16 Apr '25

On Wed Apr 16 01:25:38 2025 +0000, Brendan McGrath wrote: > Oops - sorry. I got the GUID mixed up with `timestamp/x-wg-transform`. > The GUID might not be necessary actually. I might be able to use the > `preserve_timestamps` boolean instead. I think the only difference would > be that if GStreamer lost the `timestamp/x-wg-transform` state, we would > fall back to using the gstreamer values. Which is possibly better. Oops (again). I just tried using the `preserve_timestamps` boolean and it doesn't work. The `timestamp/x-wg-transform` is a flag that lets `video_decoder.c` know that an input timestamp has been provided (and that it should use it). It will otherwise fall back to the behavior defined by `provide_timestamps`. But if we want to get rid of the need for the GUID, I guess we could move the existing logic in `video_decoder.c` (for generating our own timestamp) in to `wg_transform.c`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101018

1 0

Re: [PATCH v9 0/2] MR7796: winegstreamer: Allow caller to allocate samples in MF_XVP_PLAYBACK_MODE.
by Rémi Bernon (＠rbernon) 16 Apr '25

16 Apr '25

The test is causing failures and crashes on Win8.1/early Win10 versions, see: https://test.winehq.org/data/patterns.html#mfplat:mfplat -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7796#note_101013

1 0

[PATCH v5 0/6] MR7715: Implement dynamic formats in directdraw media stream.
by Santino Mazza (＠tati) 16 Apr '25

16 Apr '25

-- v5: amstream: Implement dynamic formats in ddraw stream. amstream/tests: Test for dynamic formats in ddraw stream. amstream: Implement custom allocator for ddraw stream. amstream/tests: Test for custom allocator in ddraw stream. amstream: Release allocator when Disconnect is called in ddraw stream. amstream: Implement IMemAllocator stub for ddraw stream. https://gitlab.winehq.org/wine/wine/-/merge_requests/7715

4 9

[PATCH 0/2] MR7825: windowscodecs/metadata: Add a stub for bKGD writer.
by Nikolay Sivov (＠nsivov) 16 Apr '25

16 Apr '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7825

3 4

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Brendan McGrath (＠redmcg) 16 Apr '25

16 Apr '25

On Wed Apr 16 00:56:58 2025 +0000, Brendan McGrath wrote: > I'll just add, that the state I'm referring to is the sample PTS. On > Windows, the application can provide any arbitrary value and when the > decoder produces the output, it needs to preserve the provided value. Oops - sorry. I got the GUID mixed up with `timestamp/x-wg-transform`. The GUID might not be necessary actually. I might be able to use the `preserve_timestamps` boolean instead. I think the only difference would be that if GStreamer lost the `timestamp/x-wg-transform` state, we would fall back to using the gstreamer values. Which is possibly better. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_100994

1 0

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Brendan McGrath (＠redmcg) 16 Apr '25

16 Apr '25

On Tue Apr 15 22:44:37 2025 +0000, Rémi Bernon wrote: > Updating the offset continuously feels weird, though I've only skimmed > over the code for now. On well formed media, that `dts < 0` should only ever be true once (as after adding ts_offset, we should never get a value below 0 again). It's mainly there in case we get media with malformed timestamps (and dts goes backwards). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_100993

1 0

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Brendan McGrath (＠redmcg) 16 Apr '25

16 Apr '25

On Tue Apr 15 22:44:37 2025 +0000, Rémi Bernon wrote: > How useful are DTS? Do we really need to pass them through? Good question. Unfortunately I must admit to not being an expert on that. Obviously it seems to decode fine without it, so it may be more useful for muxing than decoding. Although, the only codec with B-Frames that I've tested is H.264; maybe there's another codec that's more dependent on it. But I'll experiment and see if I can discern any difference between its inclusion vs. exclusion. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_100992

1 0

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Brendan McGrath (＠redmcg) 16 Apr '25

16 Apr '25

On Wed Apr 16 00:55:35 2025 +0000, Brendan McGrath wrote: > Because we can receive samples in a different order to what was sent > (for example, on B-Frames), I was thinking only GStreamer can preserve > state from input to output. But please correct me if I'm wrong. I'll just add, that the state I'm referring to is the sample PTS. On Windows, the application can provide any arbitrary value and when the decoder produces the output, it needs to preserve the provided value. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_100991

1 0

2025

2024

2023

2022

wine-gitlab April 2025