This format is used by many Unity games, with D3D-enabled source reader.
--
v3: mfreadwrite/reader: Fixup MFVideoFormat_ABGR32 subtype to enumerate the video processor.
winegstreamer: Support MFVideoFormat_ABGR32 output in the video processor.
mfreadwrite/tests: Add tests with MFVideoFormat_ABGR32 output format.
mf/tests: Add video processor tests with MFVideoFormat_ABGR32 format.
mfplat: Add MFVideoFormat_ABGR32 format information.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5626
On Thu May 16 13:27:29 2024 +0000, Rémi Bernon wrote:
> Yes it doesn't send patches if there's not diff. If you want to test
> things on the testbot you can also directly submit patch files on
> https://testbot.winehq.org/Submit.pl (you need to register first).
Thanks for the info, I have requested an account. I see that you already scheduled a manual run so thanks for that too :)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5652#note_70662
On Wed May 15 17:36:27 2024 +0000, Piotr Caban wrote:
> This marker is specific to templates so it doesn't really belong to
> `demangle_datatype` function. The patch you have proposed e.g.
> incorrectly demangles `??__K_l@@YA?AUCC@@I$$VI@Z`.
I see your point. Note that the other way around (pseudo "datatypes" for function in template argument list) is not correctly detected either (eg. in `"?AU?$my_iter@H$0A@Z@@"`)
and goes down to demangle_datatype
so I think we should be symmetrical between functions' arg list and template arg list
and hence:
- move out of demangle_datatype non real data types ($$V as you did, Z for ...)
- handle the end of list cases before calling demangle_datatype
something like this could do [err](/uploads/314e62b635f2bfcfce46544ac03aaef1/err)
(not ready for inclusion yet: we don't have test for generating template arg list as '<>')
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5646#note_70661
Now that we have MF pipelines properly resolved everywhere, we should be able to implement this, which is how native works. Some games assume a unique media type exposed by the source, and/or video processor being present in the pipeline.
It still decompresses streams internally, so next, we'll have to make it output compressed stream and let MF plug decoder elements in the pipelines.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5627
This is based on work done by Andrew Eikum. It has been in some form in Proton for the last 4 years.
If server's sampling rate is not 48kHz **DOOM Eternal** will try to set it 48kHz for the streams using the implemented interface. There's a whole class of audio devices that use 44.1kHz sampling rate and at least PulseAudio / PipeWire tends to inherit the value from the hardware to avoid resampling. The value can also be overridden by the user via the audio server's config files.
In such cases, if the interface is not present or stubbed, this results in **audio underruns and noticeable crackling**.
It's easy to test with pipewire-pulse:
```
$ cat /etc/pipewire/pipewire.conf.d/sample-rate.conf
context.properties = {
default.clock.rate = 41100
}
```
With PulseAudio this should be doable via setting `default-sample-rate = 41100` in `/etc/pulse/daemon.conf`.
--
v2: winepulse.drv: Implement set_sample_rate.
mmdevapi: Implement AudioClockAdjustment_SetSampleRate.
mmdevapi: Add stub IAudioClockAdjustment implementation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5585
For some reason gitlab is not sending out patches properly (or at least as I would expect) for this MR and testbot isn't triggered. It hasn't sent out [PATCH v4 2/2], and for the no-diff v5 I sent to explicitly retrigger testbot there have been no patches at all :disappointed:
Does gitlab not send out a patch if there hasn't been a content change for that patch since the last version? Is there a way to trigger testbot manually for an MR?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5652#note_70644