April 2025 - Wine-GitLab - list.winehq.org

Re: [PATCH v9 0/2] MR7796: winegstreamer: Allow caller to allocate samples in MF_XVP_PLAYBACK_MODE.
by Rémi Bernon April 16, 2025

April 16, 2025

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) April 16, 2025

April 16, 2025

-- 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) April 16, 2025

April 16, 2025

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) April 16, 2025

April 16, 2025

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) April 16, 2025

April 16, 2025

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) April 16, 2025

April 16, 2025

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) April 16, 2025

April 16, 2025

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) April 16, 2025

April 16, 2025

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) April 15, 2025

April 15, 2025

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) April 15, 2025

April 15, 2025

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