- wine-gitlab - winehq.org

[PATCH 0/1] MR7834: d3d11/tests: Add broken to test_nv12.
by Bernhard Übelacker (＠bernhardu) 16 Apr '25

16 Apr '25

[This is a testbot run with this patch.](https://testbot.winehq.org/JobDetails.pl?Key=157936) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7834

3 2

[PATCH v3 0/1] MR7829: d3d9/tests: Skip some d3d12 tests instead of crashing.
by Rémi Bernon (＠rbernon) 16 Apr '25

16 Apr '25

-- v3: d3d9/tests: Skip some d3d12 tests instead of crashing. https://gitlab.winehq.org/wine/wine/-/merge_requests/7829

3 2

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

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: > Do we really need this custom GUID? Can't the fixups be confined on the > unix side only? 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_100990

1 0

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

15 Apr '25

On Tue Apr 15 22:51:55 2025 +0000, Alfred Agrell wrote: > No, it's not. The first three bytes (in text form) are the same, but the > other 13 bytes don't look like anything. Ugh. I don't know how that happened. It does make SteamVR happy, though. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7706#note_100986

1 0

Re: [PATCH v5 0/1] MR7706: powrprof.dll: Partially implement PowerGetActiveScheme for SteamVR
by Alfred Agrell (＠Alcaro) 15 Apr '25

15 Apr '25

On Tue Apr 15 22:51:55 2025 +0000, Robert Lippmann wrote: > It is defined in winnt.h as GUID_MIN_POWER_SAVINGS. > Unfortunately, if I put those DEFINE_GUID statements into winnt.h, it > breaks compilation of other modules. > ``` > // > // ========================================= > // Define GUIDs which represent well-known power schemes > // ========================================= > // > // > // Maximum Power Savings - indicates that very aggressive power savings > measures will be used to help > // stretch battery life. > // > // {a1841308-3541-4fab-bc81-f71556f20b4a} > // > DEFINE_GUID( GUID_MAX_POWER_SAVINGS, 0xA1841308, 0x3541, 0x4FAB, 0xBC, > 0x81, 0xF7, 0x15, 0x56, 0xF2, 0x0B, 0x4A ); > // > // No Power Savings - indicates that almost no power savings measures > will be used. > // > // {8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c} > // > DEFINE_GUID( GUID_MIN_POWER_SAVINGS, 0x8C5E7FDA, 0xE8BF, 0x4A96, 0x9A, > 0x85, 0xA6, 0xE2, 0x3A, 0x8C, 0x63, 0x5C ); > // > // Typical Power Savings - indicates that fairly aggressive power > savings measures will be used. > // > // {381b4222-f694-41f0-9685-ff5bb260df2e} > // > DEFINE_GUID( GUID_TYPICAL_POWER_SAVINGS, 0x381B4222, 0xF694, 0x41F0, > 0x96, 0x85, 0xFF, 0x5B, 0xB2, 0x60, 0xDF, 0x2E ); > ``` No, it's not. The first three bytes (in text form) are the same, but the other 13 bytes don't look like anything. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7706#note_100985

1 0

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

15 Apr '25

Rémi Bernon (@rbernon) commented about dlls/winegstreamer/wg_transform.c: > buffer_add_video_meta(buffer, &video_info); > } > > + /* we perform DTS first as it should never be later than PTS, so any required timestamp offset should be the maximum here */ > + if (sample->flags & WG_SAMPLE_FLAG_HAS_DTS) > + { > + dts = sample->dts += transform->ts_offset; > + if (dts < 0) > + { > + transform->ts_offset -= dts; Updating the offset continuously feels weird, though I've only skimmed over the code for now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7623#note_100983

1 0

2025

2024

2023

2022

wine-gitlab