On Mon Aug 4 17:21:31 2025 +0000, Tim Clem wrote:
> No, that doesn't get it working. It looks like there's a caps mismatch
> before we even get around to making the capsfilter:
> ```
> 0:00:00.017267666 17294 0x600003423b40 INFO WINE
> wg_transform.c:683:wg_transform_create: transform 0x7fec778130a0 input
> caps video/x-h264, stream-format=(string)byte-stream
> 0:00:00.017561208 17294 0x600003423b40 ERROR WINE
> wg_transform.c:522:transform_create_decoder_elements: !!! input_mime=video/x-h264
> 0:00:00.017566333 17294 0x600003423b40 ERROR WINE
> wg_transform.c:501:transform_get_parsed_caps: !!! forcing byte-stream
> 0:00:00.023404625 17294 0x600003423b40 WARN WINE
> unixlib.c:126:find_element_factories: Failed to find any element factory
> matching type 1x, caps video/x-h264, stream-format=(string)byte-stream,
> alignment=(string)au, parsed=(boolean)true / video/x-raw.
> 0:00:00.023408750 17294 0x600003423b40 ERROR WINE
> wg_transform.c:562:transform_create_decoder_elements: !!! couldn't find decoder
> 0:00:00.024156416 17294 0x600003423b40 ERROR WINE
> wg_transform.c:785:wg_transform_create: Failed to create winegstreamer transform.
> 1033289.659:0520:0524:warn:quartz:wg_transform_create_mf Failed to
> create transform, status 0xc0000001
> 1033289.659:0520:0524:err:winediag:h264_decoder_create GStreamer doesn't
> support H.264 decoding, please install appropriate plugins
> ```
> transform_create_decoder_elements calls transform_get_parsed_caps early,
> and since this is video/x-h264, it returns caps with byte-stream.
> Shortly thereafter when transform_create_decoder_elements does
> `find_element(GST_ELEMENT_FACTORY_TYPE_DECODER)`, vtdec doesn't pass
> muster because of that.
Sorry @tclem, of course. I just updated the MR. I've moved the `stream-format` and `alignment` caps out of `transform_get_parsed_caps` and directly to where we create the capsfilter.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8532#note_112075
@rbernon, I could use some advice on this.
I believe this has been broken since 31b9d0c0cc67b3a03340c33f0e9942bee94c431b--unfortunately I don't have a standalone test app for it, but when display mode emulation is enabled, games like Half-Life 2 display correctly on launch but do not display correctly after the (full)screen resolution is changed in-game.
The fix here does work, but it's maybe not correct to call `make_context_current()` in the `client_surface_update`? I found that in the case of the view position check in `macdrv_client_surface_update`, win32u calls `make_context_current` afterwards. This isn't the case when the DPI has changed though, requiring that explicit `make_context_current` call.
Also previously this check was done in `macdrv_swap_buffers` and it could be done now in `macdrv_surface_swap`, but it seems preferable to do things in `update` rather than `swap` if possible.
And !8504 changes all of this, where should it go in that case?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8698