October 2023 - Wine-GitLab - list.winehq.org

[PATCH v2 0/5] MR3975: Improve module's debug information.
by eric pouech (＠epo) Oct. 20, 2023

Oct. 20, 2023

This series: - fixes a couple of issues in mach-o modules support (getting information from system modules in wow setups, machine information...) - stops hiding information in some fields between dbghelp and winedbg (using an extensible solution, where more information can be shared in the future) - display elf/mach-o in winedbg (previously mach-o was reported as elf) - display PE native vs builtin module information in winedbg -- v2: dbghelp: Remove unneeded parameter to pe_map_file. dbghelp: Simplified module_find_by_addr(). dbghelp: Set the machine type for mach-O modules. dbghelp: Use is_host_64bit for handling bitness of mach-o libs. dbghelp: Rename internal field (system -> host). https://gitlab.winehq.org/wine/wine/-/merge_requests/3975

3 9

[PATCH v3 0/4] MR3729: crypt32: Avoid truncating unicode chars.
by Dmitry Timoshkov (＠dmitry) Oct. 20, 2023

Oct. 20, 2023

-- v3: cryptui: Use CertNameToStr(CERT_NAME_STR_NO_QUOTING_FLAG) to disable quoting. crypt32: Add support for CERT_NAME_STR_NO_QUOTING_FLAG to CertNameToStr(). crypt32/tests: Add some tests for quoted RDN values. crypt32: Avoid truncating unicode chars. https://gitlab.winehq.org/wine/wine/-/merge_requests/3729

2 5

[PATCH v4 0/5] MR408: vkd3d-shader/dxil: Implement constant buffer loads.
by Conor McCarthy (＠cmccarthy) Oct. 20, 2023

Oct. 20, 2023

-- v4: vkd3d-shader/dxil: Implement the DXIL EXTRACTVAL instruction. vkd3d-shader/spirv: Support scalar swizzle of vector SSA registers. vkd3d-shader/dxil: Implement DX instruction CBufferLoadLegacy. vkd3d-shader/dxil: Implement DX instruction CreateHandle. vkd3d-shader/dxil: Replace register_address_init() with register_index_address_init(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/408

2 6

Re: [PATCH v13 0/7] MR3938: winegstreamer: Implement CLSID_CMpegVideoCodec
by Alfred Agrell (＠Alcaro) Oct. 20, 2023

Oct. 20, 2023

On Mon Oct 16 23:45:47 2023 +0000, Zebediah Figura wrote: > This may be correct (although I'm curious if it actually matters here?) > but should be a separate patch. It does matter, gst_pad_push returns GST_FLOW_NOT_NEGOTIATED if I omit it. Separate commit, sure, if you say so. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49357

1 0

Re: [PATCH v13 0/7] MR3938: winegstreamer: Implement CLSID_CMpegVideoCodec
by Alfred Agrell (＠Alcaro) Oct. 20, 2023

Oct. 20, 2023

On Fri Oct 20 01:24:23 2023 +0000, Zebediah Figura wrote: > Hi, really sorry about the very late review on this one (I was out for a > while, and then spent a lot of time catching up on review while I was > out, and then trying to get some more important Wine work done...) > 2/7, seeking parts aside, is broadly doing the right thing (from my > perspective) but I would like to see it arranged differently. What I > would like to see is something like the following, in a series of > individual patches: > * Introduce a wg_parser_create option to use the encoded format; this > should end up being translated to "chain_decodebins" basically as you > have it. I would also rename that to something like "output_compressed" > (with inverted meaning). > Note that in this case autoplug-continue already does what we want, > you shouldn't need to set the "caps" property on top of that. > * Use this property, plus WG_PARSER_DECODEBIN, in the existing frontend > instead of WG_PARSER_MPEGAUDIOPARSE. Delete WG_PARSER_MPEGAUDIOPARSE. > * Ideally patch 1/7 should be moved from the beginning of the series to here. > * Add MPEG-1 system stream support to the quartz frontend. Yes, IRL stuff is always in the way (from us internet folks' perspective), and code review isn't the most exciting task. I don't understand the point of that autoplug-continue handler. It looks like it says "yep, I want this" for certain formats, then it turns around and says "no, I don't want this after all, decode it again" in the pad-added signal. I'm sure that complexity exists for some reason, otherwise someone would've deleted it long ago, but... But I don't need to understand it, as long as someone does. This took me longer to implement than I expected, didn't expect you to be this thorough. Sure helps to have a pair of fresh eyes on it. Worth the wait (though it would've helped to have known how long it'd take). I think I fixed everything (except those with follow-up questions), but some changes are pretty big and/or not exactly what you were thinking of, so I suspect you'll have another set of remarks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49356

1 0

Re: [PATCH v13 0/7] MR3938: winegstreamer: Implement CLSID_CMpegVideoCodec
by Alfred Agrell (＠Alcaro) Oct. 20, 2023

Oct. 20, 2023

On Mon Oct 16 23:46:02 2023 +0000, Zebediah Figura wrote: > Can you please also check (at least the return value of) > IMediaSample::GetMediaType()? I'm rather curious if it's updated or not. It just returns S_FALSE every frame (which means unchanged since previous sample). Sure, let's test it, no reason not to. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49355

1 0

Re: [PATCH v13 0/7] MR3938: winegstreamer: Implement CLSID_CMpegVideoCodec
by Alfred Agrell (＠Alcaro) Oct. 20, 2023

Oct. 20, 2023

On Mon Oct 16 23:45:59 2023 +0000, Zebediah Figura wrote: > If Windows never sets the sample time for video samples after the first > then we should probably make this check more restrictive to explicitly > check that. It's Complicated™ (Apologies if you know some of this already, better too much information than too little.) The MPEG video format contains two layers of framing - the program stream tells which bytes are audio and which are video, but it's just arbitrarily arranged bytes, with no relation to video frame boundaries. Windows' MPEG splitter parses the program stream, reads the first few bytes of the video stream (the codec data) to determine image size, and emits that. Determining the frame boundaries is the video codec's job. GStreamer's mpegpsdemux doesn't read the codec data because why would it. To make the splitter's media type contain image size, I needed to put the mpegvideoparse on this side. Which means that, unlike Windows, each submitted packet is exactly one frame. ``` Windows video0 hr=00000000 len=1214 audio0 hr=00000000 len=2037 audio1 hr=00000000 len=2037 audio2 hr=00000000 len=2025 audio3 hr=00000000 len=2025 audio4 hr=80040249 len=653 Wine video0 hr=00000000 len=859 audio0 hr=00000000 len=1253 video1 hr=80040249 len=195 audio1 hr=00000000 len=1254 video2 hr=80040249 len=84 audio2 hr=00000000 len=1254 video3 hr=80040249 len=76 audio3 hr=00000000 len=1254 audio4 hr=00000000 len=1254 audio5 hr=00000000 len=1254 audio6 hr=00000000 len=1254 ``` Yes, it's messy, but I don't think we can do any better unless I move the mpegvideoparse into the codec object. Which would be more accurate to native, but it would require writing my own decoder for the codec data, would require reintroducing <https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_46588>, and would improve nothing except our test suite. That said, the VFW_S_NO_STOP_TIME check catches nothing. I'll drop it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49353

1 0

Re: [PATCH v13 0/7] MR3938: winegstreamer: Implement CLSID_CMpegVideoCodec
by Alfred Agrell (＠Alcaro) Oct. 20, 2023

Oct. 20, 2023

On Mon Oct 16 23:46:01 2023 +0000, Zebediah Figura wrote: > Shouldn't we get an exact number of frames here? Or is that not > consistent somehow? Yes, it's inconsistent. Wine emits two frames; native only emits one, probably because the graph is paused. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49354

1 0

Re: [PATCH v13 0/7] MR3938: winegstreamer: Implement CLSID_CMpegVideoCodec
by Alfred Agrell (＠Alcaro) Oct. 20, 2023

Oct. 20, 2023

On Mon Oct 16 23:45:56 2023 +0000, Zebediah Figura wrote: > This probably needs to take the filter CS. Same for Info() for that matter. You sure? There's no reference to filter_cs in dlls/quartz/ or dlls/winegstreamer/, except in VMR; it's mostly used in libs/strmbase/. Is this specific interface different? Or maybe they're all buggy? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49352

1 0

Re: [PATCH v13 0/7] MR3938: winegstreamer: Implement CLSID_CMpegVideoCodec
by Alfred Agrell (＠Alcaro) Oct. 20, 2023

Oct. 20, 2023

On Mon Oct 16 23:46:06 2023 +0000, Zebediah Figura wrote: > Usually enum values are capitalized; also, _t is usually reserved for > typedefs. That said, do we even want this enum? Is there any instance > where we shouldn't just iterate over the whole array? > Two of these formats are todo, but I think something like "todo_wine_if > (i == 1 || i == 8)" would be fine. Turns out that no, we don't. Every piece either should test every supported format, or uses only one format and doesn't care which, so it might as well use (or copy) the hardcoded YUY2 one. (Except the RGB8 check in init_video_mt, but I can just switch that to check something else.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_49351

1 0