This is the first batch of a series implementing faster media source resolution required to workaround an Unreal Engine race condition present in some games, and deterministic stream ordering that decodebin / parsebin cannot provide, which is required to expose the streams in native order, for compatibility in several other applications.
I pushed the full series as a branch here: https://gitlab.winehq.org/rbernon/wine/-/commits/mr/wg-source-part-one
Note that this full series is also a first step in the direction of having a simpler demuxer interface, which will be required in the future for compatibility with applications that build MF or DirectShow pipelines directly and expect the relevant components to behave as a demuxer and expose compressed media types. For now it only delays the use of wg_parser to whenever the media source is started, and matches the non-ordered streams using their media types and tags. This is a best effort solution but I don't think we can do much better for the moment.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3606
--
v2: winegstreamer: Expose the generic video decoder transform.
winegstreamer: Introduce a generic audio decoder transform.
winegstreamer: Rename aac_decoder to audio_decoder.
winegstreamer: Translate generic unknown audio / video media types.
winegstreamer: Support generic audio / video unknown formats.
winegstreamer: Call gst_video_info_from_caps for all video formats.
winegstreamer: Call gst_audio_info_from_caps for all audio formats.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5138
I'm not sure about the need for this solution, so it's a **DRAFT**. For me it is an academic interest to check whether atomic locks will give advantages over pthread_mutex in games. First impressions are that games have become smoother, but need to think about tests that can actually be measured.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6031
The sequence lives in the object header, and the object is containing
the shm struct. The code was reading before the dummy_shm variable and
sometimes asserted that the sequence isn't initialized to zero.
Fixes a random wineserver crash, sorry about that.
--
v2: server: Use a shared_object_t for the dummy object.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6037
The sequence lives in the object header, which is containing the shm
struct. The code was reading before the dummy_shm variable and sometimes
asserted that the sequence isn't initialized to zero.
Fixes a random wineserver crash, sorry about that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6037
On Thu Jun 27 01:11:28 2024 +0000, Zhiyi Zhang wrote:
> > It fails on asserting return value of sending LVM_GETNEXTITEM message
> In that case, please also add a test checking the same thing.
Hi, could you add a test?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5909#note_75710