September 2024 - Wine-GitLab

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Rémi Bernon Sept. 13, 2024

Sept. 13, 2024

On Fri Sep 13 08:31:24 2024 +0000, Ziqing Hui wrote: > Sounds like we will have 2 backend: winegstreamer and winedmo. For the > mftransforms front ends, like h264 encoder transform, h264 decoder > transform, wmv decoder dmo, will we have 2 seperate front ends? Yes, duplicating the frontend code seems like the easiest thing to do. The video encoder source could live in mfh264enc, and if we need more video encoder modules, they could share its source with PARENTSRC. Note that I haven't explored the encoding path very much yet, so we can probably not worry about it and just keep using GStreamer only for it for now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82104

1 0

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Ziqing Hui (＠zhui) Sept. 13, 2024

Sept. 13, 2024

On Fri Sep 13 08:29:22 2024 +0000, Ziqing Hui wrote: > Which folder will the video_encoder.c be placed? We are putting the PE > frontend implementation of video encoder in winegstreamer now. Will we > have a duplicate video_decoder.c in winedmo folder? Sounds like we will have 2 backend: winegstreamer and winedmo. For the mftransforms front ends, like h264 encoder transform, h264 decoder transform, wmv decoder dmo, will we have 2 seperate front ends? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82103

1 0

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Ziqing Hui (＠zhui) Sept. 13, 2024

Sept. 13, 2024

On Fri Sep 13 08:05:59 2024 +0000, Rémi Bernon wrote: > I'm thinking to implement these with winedmo, while keeping the > redirection to the winegstreamer backend as default. Which folder will the video_encoder.c be placed? We are putting the PE frontend implementation of video encoder in winegstreamer now. Will we have a duplicate video_decoder.c in winedmo folder? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82102

1 0

[PATCH 0/1] MR5787: winevulkan: Use an internal NtUser call to retrieve a GPU LUID.
by Rémi Bernon Sept. 13, 2024

Sept. 13, 2024

Avoid taking the display_device_init mutex outside of win32u. Similar to https://gitlab.winehq.org/wine/wine/-/merge_requests/5786, although this one doesn't cause any problems as far as I know. Still makes things simpler. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5787

2 6

[PATCH 0/10] MR4201: widl: Cleanup and simplify expressions.
by Rémi Bernon Sept. 13, 2024

Sept. 13, 2024

Some cleanup for expressions, sanitizing the structure a bit especially for abstract operations with multiple args. I also found out about named bison variables, implicit (as `$token` referring to `token`), or explicit (as `$name` referring to `token[name]`). I think it would make the rules much more readable so I started using them here. My plan is to add them progressively to the rules, unless there's some good reason not to (like idk how portable they are, if that's something we should be worried about). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4201

2 21

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Rémi Bernon Sept. 13, 2024

Sept. 13, 2024

On Fri Sep 13 08:05:59 2024 +0000, Ziqing Hui wrote: > Will these only be implemented on top of winedmo or the winegstreamer > version will also migrate to it? I'm thinking to implement these with winedmo, while keeping the redirection to the winegstreamer backend as default. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82101

1 0

Re: [PATCH v5 0/4] MR6442: winedmo: Introduce a new DLL as a MF FFmpeg backend.
by Rémi Bernon Sept. 13, 2024

Sept. 13, 2024

On Fri Sep 13 08:05:43 2024 +0000, Ziqing Hui wrote: > one minor question: why this module is called wine**dmo**, from the > above comments, it sounds more like wineffmpeg. I found wineffmpeg to be awkward and didn't like the name, the libraries we use aren't even named ffmpeg but libavformat, libavcodec,... Then, there's an existing msdmo, and winedmo sounded nicer. DMOs (and now MFTs but only a few are pure MFTs, most are dual DMO-MFT objects) are the building blocks of all the windows multimedia components. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6442#note_82100

1 0

Re: [PATCH v2 0/8] MR6430: misc: Register DMO classes from their native DLLs.
by Ziqing Hui (＠zhui) Sept. 13, 2024

Sept. 13, 2024

Will these only be implemented on top of winedmo or the winegstreamer version will also migrate to it? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6430#note_82092

1 0

[PATCH 0/1] MR6489: winemenubuilder:Add exe file icon image extraction in thumbnail_lnk
by Maotong Zhang (＠xiaotong) Sept. 13, 2024

Sept. 13, 2024

You can use "winemenubuilder -t *.exe *.png" to directly extraction icon image files from exe Resolve : https://forum.winehq.org/viewtopic.php?t=39249 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6489

3 2

Re: [PATCH v5 0/4] MR6442: winedmo: Introduce a new DLL as a MF FFmpeg backend.
by Ziqing Hui (＠zhui) Sept. 13, 2024

Sept. 13, 2024

one minor question: why this module is called wine**dmo**, from the above comments, it sounds more like wineffmpeg. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6442#note_82089

1 0