April 2025 - wine-gitlab

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

17 Apr '25

On Thu Apr 17 07:54:50 2025 +0000, Rémi Bernon wrote: > Have you tried GstVideoTimeCodeMeta / do you know what it does? No, I didn't look at that. But taking a look now, it looks like it might be good for Video PTS/DTS, but wouldn't work for audio. I'm not sure for duration either. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101244

1 0

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Rémi Bernon (＠rbernon) 17 Apr '25

17 Apr '25

On Wed Apr 16 08:20:27 2025 +0000, Brendan McGrath wrote: > 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`. Hmm, I'm not sure that moving timestamp generation to the unix side is better. Can't we simply fill the sample timestamps from the input provided timestamps instead of the GStreamer-generated timestamps we don't really care about? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101242

1 0

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Rémi Bernon (＠rbernon) 17 Apr '25

17 Apr '25

On Wed Apr 16 01:09:24 2025 +0000, Brendan McGrath wrote: > 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). IMO the offset should only be updated once, and there should be a check and warning/fixme message if that assumption is broken. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101241

1 0

Re: [PATCH v5 0/2] MR7623: winegstreamer: Use provided PTS and duration in video_decoder.
by Rémi Bernon (＠rbernon) 17 Apr '25

17 Apr '25

Rémi Bernon (@rbernon) commented about dlls/winegstreamer/wg_transform.c: > - GST_BUFFER_PTS(buffer) = sample->pts * 100; > + { > + pts = sample->pts += transform->ts_offset; > + if (pts < 0) > + { > + transform->ts_offset -= pts; > + pts = 0; > + } > + GST_BUFFER_PTS(buffer) = pts * 100; > + > + if (transform->attrs.preserve_timestamps) > + { > + transform_timestamp = gst_caps_new_empty_simple("timestamp/x-wg-transform"); > + gst_buffer_add_reference_timestamp_meta(buffer, transform_timestamp, pts * 100, > + sample->flags & WG_SAMPLE_FLAG_HAS_DURATION ? sample->duration * 100 : GST_CLOCK_TIME_NONE); > + gst_caps_unref(transform_timestamp); Have you tried GstVideoTimeCodeMeta / do you know what it does? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101240

1 0

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

17 Apr '25

On Wed Apr 16 01:06:36 2025 +0000, Brendan McGrath wrote: > 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. Testing H.264 decoding, I've been unable to discern any difference. I only tested with a small sample of videos, but it seems to work both with and without and with no notable difference in performance. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_101239

1 0

[PATCH v5 0/5] MR7812: win32u: Add more CompAttr, CompClause implementation using cursor_begin, cursor_end concept.
by Byeongsik Jeon (＠bsjeon) 17 Apr '25

17 Apr '25

If CompAttr and CompClause are properly configured, Japanese input will be more comfortable. Inspired by cursor_begin and cursor_end from Wayland zwp_text_input_v3:: preedit_string, I extended the cursor_pos concept as follows: cursor_pos = MAKELONG( cursor_begin, cursor_end ); ime_to_tascii_ex() uses this to construct CompAttr, CompClause. MS Windows native CompAttr, CompClause is a bit more complicated than this, but the concept is useful enough. It requires additional implementation in the Wine ime_ui_window proc and richedit control. However, it is useful for applications that inline ime composition string. This can be tested with MS Office Word, Excel. LANG=ja_JP.UTF-8 wine EXCEL.EXE Test key sequences: - “n-i-h-o-n-g-o-n-o-m-o-j-i-d-e-s-u-.-SPACE”. - And, RIGHT, LEFT, Shift+LEFT, Shift+RIGHT, ESC, SPACE, etc. -- v5: winex11: Update only when caret pos changed in xic_preedit_caret. winex11: Extend cursor_pos using cursor_begin, cursor_end. winemac: Extend cursor_pos using cursor_begin, cursor_end. winewayland: Extend cursor_pos using cursor_begin, cursor_end. win32u: Add more CompAttr, CompClause implementation using cursor_begin, cursor_end concept. https://gitlab.winehq.org/wine/wine/-/merge_requests/7812

3 7

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

17 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. -- v3: winewayland: Use an empty string to clear the composition string. imm32: Fix the WM_IME_COMPOSITION messages to be between the WM_IME_{START|END}COMPOSITION message. https://gitlab.winehq.org/wine/wine/-/merge_requests/7827

3 4

[PATCH v3 0/5] MR7817: winebth.sys part 10: Add support for removing and disconnecting devices.
by Vibhav Pant (＠vibhavp) 17 Apr '25

17 Apr '25

-- v3: bluetoothapis/tests: Add tests for BluetoothRemoveDevice. bluetoothapis: Implement BluetoothRemoveDevice. bluetoothapis: Add stub for BluetoothRemoveDevice. winebth.sys: Implement IOCTL_WINEBTH_RADIO_REMOVE_DEVICE. winebth.sys: Implement IOCTL_BTH_DISCONNECT_DEVICE. https://gitlab.winehq.org/wine/wine/-/merge_requests/7817

2 6

Re: [PATCH v8 0/1] MR7706: powrprof.dll: Partially implement PowerGetActiveScheme for SteamVR
by Robert Lippmann (＠rlippmann) 17 Apr '25

17 Apr '25

Fixed GUID and added a comment -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7706#note_101230

1 0

Re: [PATCH v8 0/1] MR7706: powrprof.dll: Partially implement PowerGetActiveScheme for SteamVR
by Robert Lippmann (＠rlippmann) 17 Apr '25

17 Apr '25

On Thu Apr 17 03:21:46 2025 +0000, Robert Lippmann wrote: > Ugh. I don't know how that happened. > It does make SteamVR happy, though. Ok, fixed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7706#note_101228

1 0

2025

2024

2023

2022

wine-gitlab April 2025