[Bug 60018] New: ashes of the sun / unity crashes after video_frame_wrap_buffer
http://bugs.winehq.org/show_bug.cgi?id=60018 Bug ID: 60018 Summary: ashes of the sun / unity crashes after video_frame_wrap_buffer Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: zlice@crtdrift.us Target Milestone: --- Distribution: --- Created attachment 81440 --> http://bugs.winehq.org/attachment.cgi?id=81440 wine-stdout https://synthaxed.itch.io/ashes-of-the-sun (don't get it confused with the adult game of the same name :] ) wine 11.12 and 11.13 both end up crashing after the intro (have to sit through and press F to pass dialog because it's new game, takes a minute or so). wine 10.1 doesn't find the mouse, not if this works in previous releases. tried a WINEDEBUG but didn't see anything and +all just chugs. - gstreamer 1.28.5 - mesa 26.1.4 - dxvk 3.0.1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://synthaxed.itch.io/a | |shes-of-the-sun --- Comment #1 from Ken Sharp <imwellcushtymelike@gmail.com> --- Please attach a console output without DXVK. https://gitlab.winehq.org/wine/wine/-/wikis/Bugs -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #2 from zlice <zlice@crtdrift.us> --- Created attachment 81442 --> http://bugs.winehq.org/attachment.cgi?id=81442 wine-builtin-dx -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #3 from zlice <zlice@crtdrift.us> --- Created attachment 81443 --> http://bugs.winehq.org/attachment.cgi?id=81443 ashes-builtin-dbg-d3d-tail managed to get a WINEDEBUG="+d3d", 22gb x-x if that helps -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #4 from zlice <zlice@crtdrift.us> --- Created attachment 81449 --> http://bugs.winehq.org/attachment.cgi?id=81449 ashes-builtin-gbd-msvcp-msvideo fwiw, the game crashes here ``` rax 0x1 1 rbx 0x200000000 8589934592 rcx 0x0 0 rdx 0xf14c3944fe1c3e84 -1059408843855085948 rsi 0x1 1 rdi 0x7f2698000030 139803735621680 rbp 0xf14c3944fe1c3e84 0xf14c3944fe1c3e84 rsp 0xf14c3944fe1c3e84 0xf14c3944fe1c3e84 r8 0xf14c3944fe1c3e84 -1059408843855085948 r9 0xf14c3944fe1c3e84 -1059408843855085948 r10 0x0 0 r11 0x246 582 r12 0x0 0 r13 0x0 0 r14 0x0 0 r15 0x0 0 rip 0x7f29ba329eae 0x7f29ba329eae eflags 0x10286 [ PF SF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 k0 0x400010 4194320 k1 0x100000 1048576 k2 0xffffffff 4294967295 k3 0x88004002 2281717762 k4 0x0 0 k5 0x0 0 k6 0x0 0 k7 0x0 0 fs_base 0x7f278601e6c0 139807728723648 gs_base 0x7f26b935c000 139804292792320 0x7f29ba329e5c: nopl 0x0(%rax) 0x7f29ba329e60: mov 0x30(%rdi),%r8 0x7f29ba329e64: mov 0x8(%rdi),%r9 0x7f29ba329e68: mov 0x38(%rdi),%rdx 0x7f29ba329e6c: ror $0x11,%r8 0x7f29ba329e70: xor %fs:0x30,%r8 0x7f29ba329e79: ror $0x11,%r9 0x7f29ba329e7d: xor %fs:0x30,%r9 0x7f29ba329e86: ror $0x11,%rdx 0x7f29ba329e8a: xor %fs:0x30,%rdx 0x7f29ba329e93: mov (%rdi),%rbx 0x7f29ba329e96: mov 0x10(%rdi),%r12 0x7f29ba329e9a: mov 0x18(%rdi),%r13 0x7f29ba329e9e: mov 0x20(%rdi),%r14 0x7f29ba329ea2: mov 0x28(%rdi),%r15 0x7f29ba329ea6: mov %esi,%eax 0x7f29ba329ea8: mov %r8,%rsp 0x7f29ba329eab: mov %r9,%rbp => 0x7f29ba329eae: jmp *%rdx ``` and somehow setting WINEDEBUG="+msvcp,+msvideo" allows the cutscene to skip or something and go into the game? i assume i missed some video? went afk expecting a crash. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #5 from zlice <zlice@crtdrift.us> --- Created attachment 81458 --> http://bugs.winehq.org/attachment.cgi?id=81458 ashes-stackdum-unity-err-after-reader-chk so i think this has something to do with mfplatreadwrite/reader.c source_reader_release() ? when things work vs segfault the last message always seems to be from here. several things call it but i'm not sure what's in thread locks and what isn't. tried doing a check for 'if (reader == 0)' and returning at the start of source_reader_release() and now i get a unity crash/error popup and a wine stack trace window, but it seems to be from random places in mfplatreader. not sure if that's more race conditions? or maybe im just breaking things. i watched a youtube video and the first fade out after the intro scene is just a very short fade to black and back. so it's not missing a video like some games on linux. maybe it's a short 1 frame video placeholder or something. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #6 from Stian Low <wineryyyyy@gmail.com> --- Unable to reproduce any crash for wine-11.13 but intro video skips and goes straight to gameplay. DXVK not tested so maybe crash only happens for it. MR-11404 for minimal support for Get/OpenSharedHandle() also does not fix videos (as it does for Haven and Signifier via WINE_D3D_CONFIG=csmt=0x2,renderer=vulkan) but does produce the err:dmo:video_frame_wrap_buffer logs that do not log otherwise: https://gitlab.winehq.org/wine/wine/-/merge_requests/11404 021c:err:dmo:video_frame_wrap_buffer frame fmt nv12 220x220 stride 220 isn't aligned to 16 bytes 021c:err:dmo:video_frame_copy_from_buffer frame fmt nv12 220x220 stride 256, format 00007F0442840D60, buffer 00007F044D8F0B40 These logs may indicate this bug is related: https://bugs.winehq.org/show_bug.cgi?id=50277: 0024:fixme:dxgi:DXGID3D10CreateDevice Ignoring flags 0x820. 01f0:fixme:dxgi:dxgi_resource_GetSharedHandle iface 00007F8803796528, shared_handle 00007F88B59ADBF0 stub! However, forcing UnityPlayer.dll software video decoding for D3D11_CREATE_DEVICE_VIDEO_SUPPORT=0x800 does not fix intro videos for Ashes of the Sun like it does for Haven and Signifier: https://gitlab.winehq.org/wine/wine/-/merge_requests/11398 Not even hack which forces NV12 allowing Haven and Signifier videos to play works for Ashes of the Sun which always skips straight to gameplay: https://bugs.winehq.org/show_bug.cgi?id=56614#c26 Ashes of the Sun is yet another Unity game awaiting MR-10567 to fix dark rendering for renderer=vulkan for default `winecfg -v win10`: https://gitlab.winehq.org/wine/wine/-/merge_requests/10567/ https://bugs.winehq.org/show_bug.cgi?id=45364 `winecfg -v win7` fixes dark rendering for renderer=vulkan as workaround in the meantime. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #7 from zlice <zlice@crtdrift.us> --- thanks for all the info, will take a look. was up way too late looking at this. undid my previous comment because i figured i just broke something and saw a few things like mfreadwrite/reader.c : source_reader_async_command_Release doing a interlock INC instead of DEC like every other release (only addrefs were doing INC) but then i was crashing in rtworkq/queue.c ... so ig something with 'uknowns'. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #8 from zlice <zlice@crtdrift.us> --- so after digging through wine and gstreamer for far too long. one crash is in dlls/ntdll/unix/debug.c : __wine_dbg_header() gets `struct debug_info *info = get_info();` then immediately tries to `char *pos = info->output;` --- but get_info() returns 'debug_info[0x800]' from thread data, which is 0x58, which clearly fails to deref. idk if that's a race from threads being deleted or something is overflowing into it. but the ending line `016c:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 00007FFFFE20FE80` does seem to be constant... i see easy way to disable or fprintf() before the wine macros though. trying to add a fprintf() in `__WINE_DPRINTF` or anything leads to linker failures for fprintf() - and there is no corresponding WINE_NO_ERROR for error, like there is for trace and debug/fixme. even if i could disable messages, that doesn't help see whats going on (unless it is a overflow and pushes a crash to somewhere else?) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #9 from zlice <zlice@crtdrift.us> --- i dont* see an easy way or replace or add* fprintf -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #10 from zlice <zlice@crtdrift.us> --- Created attachment 81474 --> http://bugs.winehq.org/attachment.cgi?id=81474 mfplat-mediatype-fix So this patch seems to fix 1 bug, however I built a normal build with debugging/trace/fixme messages still enabled and only this patch on top of 11.13 and the game can still crash at the intro 'movie/overlay' w/e it's playing at 220 pixels. Still don't really know why the descriptor pointer is 0. presentation_descriptor_Clone looks wrapped in thread locks and MFCreatePresentationDescriptor seems to return early if count is 0 or descriptors are invalid. Possibly thread race on release? for ref 0x00000001800158a7 <+39>: mov rcx,r12 0x00000001800158aa <+42>: call QWORD PTR [rip+0x24be0] # 0x18003a490 <__imp_EnterCriticalSection> 0x00000001800158b0 <+48>: mov rax,QWORD PTR [rsi+0x8] 0x00000001800158b4 <+52>: mov eax,DWORD PTR [rax+rbx*1+0x8] 0x00000001800158b8 <+56>: mov DWORD PTR [rbp+0x0],eax 0x00000001800158bb <+59>: mov rax,QWORD PTR [rsi+0x8] 0x00000001800158bf <+63>: mov rcx,QWORD PTR [rax+rbx*1] 0x00000001800158c3 <+67>: mov QWORD PTR [rdi],rcx 0x00000001800158c6 <+70>: mov rax,QWORD PTR [rcx] <<< CRASH - desc=0 0x00000001800158c9 <+73>: call QWORD PTR [rax+0x8] 0x00000001800158cc <+76>: mov rcx,r12 0x00000001800158cf <+79>: call QWORD PTR [rip+0x24c0b] # 0x18003a4e0 <__imp_LeaveCriticalSection> Check if descriptor is 0 and fuk off. Used E_INVALID ret but maybe E_HANDLE is a better error? I moved the descriptor set and addref inside the critical section with the bool set, idk if it's that "critical" but figured if the bools that important then why not? With WINE_NO_TRACE_MSGS and WINE_NO_DEBUG_MSGS, commenting out any ERR lines in mfplat and winegstreamer, AND on top of this patch, the game has made it past intro several times in a row with no problem (did put 1 error in to spit out "INVALID" so I could be sure the descriptor was indeed set to 0). As for the debug printout issue I still don't really know what is going on. Assume a thread race. Was at the descriptor bit before but as the crashes were changing thought I was in the wrong spot. A if > 0xFFFF may be good? But you wouldn't really be able to tell what's wrong or where. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #11 from zlice <zlice@crtdrift.us> --- Created attachment 81479 --> http://bugs.winehq.org/attachment.cgi?id=81479 crash-mfreadwrite-media_stream_destroy *sigh* started to play then got to a area that you interact with this terminal and it plays some noise and visual effect, then bam another crash. this one is on destroy so i have to assume it is just creating/destroying 220px sized things so fast it breaks. `media_stream_destroy()` called/inlined inside `source_reader_release()` where i was originally poking around is trying to access list pointers for 0. putting a `if (stream->transforms.next != 0)` around the list loop in `media_stream_destroy()` -- and some extra logic and critical sections i had, as well as `if (reader->streams)` guard inside `source_reader_release()` loop that calls destroy seems to be good. sadly, the screen you're supposed to interact with never shows anything =/ and the buttons aren't there because i've clicked all over and got nothing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #12 from zlice <zlice@crtdrift.us> --- Created attachment 81480 --> http://bugs.winehq.org/attachment.cgi?id=81480 mfreadwrite-reader-patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #13 from zlice <zlice@crtdrift.us> --- Created attachment 81481 --> http://bugs.winehq.org/attachment.cgi?id=81481 wine-gst-nostream-src_0 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #14 from Stian Low <wineryyyyy@gmail.com> --- Windows 11 test produces the same results with game going straight to gameplay without displaying video. Dev logs and comments indicate that videos/cinema were recently added for latest version: https://synthaxed.itch.io/ashes-of-the-sun Maybe latest version of game is bugged and tries to play the wrong video. Earlier versions seem unavailable to test and compare. WINEDEBUG=+mfplat indicates game plays Waveform.m4v: 01d0:trace:mfplat:stream_handler_BeginCreateObject 00007FFFFE80A240, L"Assets/Assets/Sprites/Waveform.m4v", 0x1, 0000000000000000, 0000000000000000, 00007FFFFE809FB0, 00007F6D564E0960. Waveform.m4v plays fine via gst-play-1.0 but duration is less than 1 second. Maybe Waveform.m4v actually plays for vanilla wine but too brief to actually display anything onscreen same as Windows 11. Maybe Waveform.m4v is the wrong video that is supposed to be played? If the game is still under active development then bugs for it may not be worth spending too much time on until game is officially released. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #15 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #14)
01d0:trace:mfplat:stream_handler_BeginCreateObject 00007FFFFE80A240, L"Assets/Assets/Sprites/Waveform.m4v", 0x1, 0000000000000000, 0000000000000000, 00007FFFFE809FB0, 00007F6D564E0960.
I hacked the patch to play Jupiter.m4v instead which is longer than 1 second but game still skips straight to gameplay even with various hacks I reported. Therefore video duration less than 1 second may not be the only issues. But regardless, unless I'm mistaken expecting video to play right after campfire/radio transmission scene, because wine seems to produce same results as Windows 11 test, this may be a bug with the game itself rather than wine for now. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #16 from zlice <zlice@crtdrift.us> ---
Waveform.m4v plays fine via gst-play-1.0 but duration is less than 1 second.
Yes, this is what I was thinking, it's too short to even notice, and gets removed before it even "plays".
But regardless, unless I'm mistaken expecting video to play right after campfire/radio transmission scene, because wine seems to produce same results as Windows 11 test, this may be a bug with the game itself rather than wine for now.
The first one I can see being a bug or oversight or something, but youtube videos show people playing and finishing the game. The second video at the tower is totally viewable and they can interact with screens. https://youtu.be/o6_k7uK7BvA?t=1321 Also, I think the fact that wine is trying to double delete is a bug either way? Maybe I don't understand the program<>library/dll interaction but my patches clearly allow me to play where it was crashing before. And like I said people play and finish the game without it crashing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #17 from Stian Low <wineryyyyy@gmail.com> --- (In reply to zlice from comment #16)
The first one I can see being a bug or oversight or something, but youtube videos show people playing and finishing the game. The second video at the tower is totally viewable and they can interact with screens. https://youtu.be/o6_k7uK7BvA?t=1321
Based on video I was mistaken in expecting a video to actually play after the campfire scene. Maybe Waveform.m4v is valid and just used to init mfplat.
Also, I think the fact that wine is trying to double delete is a bug either way? Maybe I don't understand the program<>library/dll interaction but my patches clearly allow me to play where it was crashing before. And like I said people play and finish the game without it crashing.
Are you still testing with DXVK? Wine may still be bugged for whatever DXVK loads but vanilla loads differently and prevents crashing for whatever reason. Please with vanilla wine if you're able. Maybe DXVK expects proton-specific capabilities that vanilla wine does not provide but DXVK tries anyway without respect to vanilla context. Proton test would clarify. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #18 from zlice <zlice@crtdrift.us> --- Yes, Ken asked and I set the dlls to builtin and there are no lines about DXVK in output anywhere. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #19 from Stian Low <wineryyyyy@gmail.com> --- (In reply to zlice from comment #18)
Yes, Ken asked and I set the dlls to builtin and there are no lines about DXVK in output anywhere.
So it crashes without DXVK? If so please retry with a fresh prefix untouched by DXVK because I've never encountered any crash. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #20 from zlice <zlice@crtdrift.us> --- The prefix did not matter but I am having a REALLY hard time getting the crashes to trigger now, which definitely seems like a thread race. I think the delete/unref is in winegstreamer wg_parser/format seeing that the stream is h264, but not 'stream-format == byte-stream' (it's avc) so it rejects, goes to gstreamer autoplug detect and finds video/quicktime, not entirely sure how that all intertwines. As you said, gst-play can read the video (and audio that wine plays) just fine from jupiter and friends. The log with GST_DEBUG=5 is over 100MB, but if you want to take a look, the tower with the videos is basically straight from where you start. Around the rocks/canyons and between 2 silos in the middle of sat dishes. (this would be so much easier with game saves) Also extracting the m4v, it is weird that the files 1080 but the logs keep saying 220x220. DEBUG typefind gsttypefindelement.c:823:gst_type_find_get_extension:<typefind> finding extension of Assets/Assets/Videos/Jupiter.m4v DEBUG GST_PLUGIN_LOADING gstpluginfeature.c:106:gst_plugin_feature_load: loading plugin for feature 0x7f6d64018120; 'video/mpeg4' FIXME WINE dlls/winegstreamer/wg_format.c:694:wg_format_from_caps: Unhandled caps video/quicktime, variant=(string)iso. INFO WINE dlls/winegstreamer/wg_parser.c:542:autoplug_select_cb: Using "QuickTime demuxer". DEBUG WINE dlls/winegstreamer/wg_format.c:571:wg_format_from_caps_video_h264: Rejecting stream format avc. ?????? DEBUG codecparsers_h264 gsth264parser.c:1608:gst_h264_parser_identify_nalu_avc: Can't parse, buffer has too small size 93, offset 93 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #21 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81688 --> http://bugs.winehq.org/attachment.cgi?id=81688 Screenshots videos fixed via MR-11398 for renderer=gl Duplicate of Haven video bug with fixes currently in-process: - https://bugs.winehq.org/show_bug.cgi?id=50277#c82 - https://gitlab.winehq.org/wine/wine/-/merge_requests/11398#note_147852 - https://gitlab.winehq.org/wine/wine/-/merge_requests/11404#note_147641 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #22 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #6)
Unable to reproduce any crash for wine-11.13 but intro video skips and goes straight to gameplay. DXVK not tested so maybe crash only happens for it.
Game does not have intro videos and requires spending time to reach videos to confirmed bugged without MR-11398. Unfortunately it seems not to have save points upon restarting which was required after falling through the floor which may have been a game vs wine bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #23 from zlice <zlice@crtdrift.us> --- well, i'm right back to where i started. only thing ive learnt is source_reader_create_decoder_for_stream seems to be the thing causing access to unreachable memory in winedbg unix output i mentioned. and that not putting a "\n" newline in ERR() output corrupts and overflows into memory somehow. ended up getting the length of lines causing crash dumps in ntdll exception.c raise_status loop. reboot doesnt help, fresh prefix doesnt help, disabling trace/fixme and the patches i posted before help 'get farther' but im just beat knowing all the debugging it took to get that far last time will probably take that long again. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #24 from zlice <zlice@crtdrift.us> --- (In reply to zlice from comment #23)
well, i'm right back to where i started. only thing ive learnt is source_reader_create_decoder_for_stream seems to be the thing causing access to unreachable memory in winedbg unix output i mentioned.
for reference, the line ("Failed to get decoder output media type, hr %#lx\n", hr) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #25 from zlice <zlice@crtdrift.us> --- ok, went back to the start with the dmo errors. `video_frame_wrap_buffer()` (that complains about the alignment) seems to be the wrong type, it's BOOL but used as 'int' for size everywhere. also the alignment seems to disagree between wine and ffmpeg but means nothing. wine's ffmpeg embedded config.h has a define for align 64 (avx512) while newer ffmpeg-6 has the align stuff in C code, which i think is figured at runtime. and parts of avutil/frame check for align and switch between 32/64. changing the line in wrap_buffer() between 16/32/64 doesn't seem to do anything but make the buffer size bump to align. `video_processor_process_frame()` calls ffmpeg's `sws_scale_frame()` which appears to be the source of my crashes. skipping that and doing the `video_frame_copy_to_buffer()` fallback after it gets passed the intro every time. maybe that's overflowing somewhere and the source of the random weird crashes like with debug prints? probably better to update ffmpeg though instead of trying to fix an old version and not knowing what it may have changed/broke. unfortunately, using "WINE_D3D_CONFIG=csmt=0x2,renderer=gl" gives a unity crash report, probably because intel GPUs don't work well with gl, just renderer=gl or trying with dxvk doesn't seem to do anything. i assume with dxvk it's probably not using gl anyway. maybe i'm doing something wrong, or intel gpu, or my sws_scale_frame() remove is the cause, but i can't get videos to play. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #26 from Stian Low <wineryyyyy@gmail.com> --- (In reply to zlice from comment #25)
ok, went back to the start with the dmo errors.
Please retest with only this patch for a clean prefix which is all that was needed for my screenshots: - https://bugs.winehq.org/show_bug.cgi?id=50277#c46 diff --git a/dlls/dxgi/dxgi_main.c b/dlls/dxgi/dxgi_main.c index ca1fb525535..34719b1c5ef 100644 --- a/dlls/dxgi/dxgi_main.c +++ b/dlls/dxgi/dxgi_main.c @@ -147,6 +147,11 @@ HRESULT WINAPI DXGID3D10CreateDevice(HMODULE d3d10core, IDXGIFactory *factory, I if (flags) FIXME("Ignoring flags %#x.\n", flags); + if (flags & 0x800) + { + FIXME("failing for D3D11_CREATE_DEVICE_VIDEO_SUPPORT\n"); + return E_FAIL; + } if (TRACE_ON(dxgi)) dump_feature_levels(feature_levels, level_count); -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #27 from zlice <zlice@crtdrift.us> --- Created attachment 81732 --> http://bugs.winehq.org/attachment.cgi?id=81732 process_frame_ret_size_double_use (In reply to Stian Low from comment #26)
Please retest with only this patch for a clean prefix which is all that was needed for my screenshots: - https://bugs.winehq.org/show_bug.cgi?id=50277#c46
ah ok - i did mr-11398 which didn't work. the 0x800 / kickback to software render patch takes care of the crashing and the video playback. did look a bit more at `video_processor_process_frame()`, it seems like it is double using `ret` for `size` and then not returning `MF_E_TRANSFORM_NEED_MORE_INPUT` but `S_OK`. idk if it's right between all the wine plumbing and just ret/size being confused. it does not work on top of the 0x800 patch though. thanks, i'll try to play this soon. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60018 --- Comment #28 from Stian Low <wineryyyyy@gmail.com> --- (In reply to zlice from comment #27)
ah ok - i did mr-11398 which didn't work.
Patch above that hardcodes 0x800 is a reduced form of MR-11398 and exposes it's fundamental essence for fixing Unity game videos. MR-11398 fixes videos similarly but requires Unity games to be run with `WINE_D3D_CONFIG=no_create_flags=0x800` because fix is not hardcoded and disabled by default and must be run such as: WINE_D3D_CONFIG=no_create_flags=0x800 wine ashes_of_creation.exe
the 0x800 / kickback to software render patch takes care of the crashing and the video playback.
Excellent. This means it should practically be considered a duplicate of Haven video bug-50277 if no other bugs are encountered.
did look a bit more at `video_processor_process_frame()`, it seems like it is double using `ret` for `size` and then not returning `MF_E_TRANSFORM_NEED_MORE_INPUT` but `S_OK`. idk if it's right between all the wine plumbing and just ret/size being confused. it does not work on top of the 0x800 patch though.
mfplat may indeed also be bugged so if you encounter any other bugs now that patch allows game videos appear for plain vanilla wine then please report them. MR-11398 uses a different and probably much simpler code path than DXVK or however you were running it previously which involves d3d-cross-device multi-threading which may be much more bug prone. If still you encounter similar bugs using the less bug prone codepath via patch above then this bug should probably remain open and be considered only a partial duplicate of bug-50277 because mfplat bugs more broadly/specifically may need to be fixed first in order to close this bug properly per earlier description/comments.
thanks, i'll try to play this soon.
Good luck. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla