The new media source in experimental fails to play any video #246
Comments
|
No, it's supposed to work but we also use a limited number of GStreamer plugins so it's possible that it broke with a wider set. It looks like for instance that h264parse is unhappy here, we don't have it in Proton. Does a patch like this helps? diff --git a/dlls/winegstreamer/wg_media_type.c b/dlls/winegstreamer/wg_media_type.c
index f45ba294a2c..c610ae17c32 100644
--- a/dlls/winegstreamer/wg_media_type.c
+++ b/dlls/winegstreamer/wg_media_type.c
@@ -302,7 +302,7 @@ static void init_caps_from_video_h264(GstCaps *caps, const MFVIDEOFORMAT *format
gst_structure_remove_field(gst_caps_get_structure(caps, 0), "format");
gst_structure_set_name(gst_caps_get_structure(caps, 0), "video/x-h264");
- gst_caps_set_simple(caps, "stream-format", G_TYPE_STRING, "byte-stream", NULL);
+ gst_caps_set_simple(caps, "stream-format", G_TYPE_STRING, format_size - sizeof(*format) ? "avc" : "byte-stream", NULL);
gst_caps_set_simple(caps, "alignment", G_TYPE_STRING, "au", NULL);
}
|
|
@rnbrznr That doesn't work unfortunately, it gives the same exact error. I also tried hardcoding that "avc" string just to be safe, no effect. I quickly added a breakpoint to see if that code was even being executed and it looks like it's not so there must be a problem earlier on, maybe it doesn't detect that it's h264? |
|
Just retested after today's commits, it's still broken. h264, h265, vp8, vp9, nothing plays in both games and applications. @rnbrznr how are you building and testing your new code? I must be doing something wrong... |
|
Sorry, we're not really testing with full-featured GStreamer, so it might be broken in some ways. It's not very much a supported use case, although I would obviously like it work for Wine upstream. Please note that whatever is in bleeding-edge is also very experimental and only there to get some wider feedback. I will suggest to simply not include the changes in your build if they are causing problems. The change I suggested should help as far as I can see from your log |
|
I know experimental is just for testing, that's why I build it regularly, to check for regressions, stability, compatibility with new games, etc. I asked because it seems odd that everything I throw at it doesn't work, I want to be sure that I'm not building or using it wrong. What applications and videos are you testing it with? |
|
This issue is also affecting games like Throne and Liberty on Steam. Ingame videos dont work on experimental. |
|
@daegalus These commits are not in experimental yet, they're only in bleeding-edge. If it works with stable, some other change must have broken that game, if you have the time you should do a bisect and find out the exact commit. |
|
It looks like this was fixed a few days ago, @rbernon can you confirm? |
|
@adolfintel The new media source work was temporarily pulled from bleeding edge in order to work on it more and fix some found regressions. It will likely be back within a couple of weeks. |
|
Thanks for the heads up @alasky17 Will you leave the WINE_NEW_MEDIA_SOURCE variable for regression testing? |
|
@adolfintel Disabling WINE_NEW_MEDIA_SOURCE with the variable will be impossible with the degree to which the media code is being altered by the new patches (as you might have already noticed when it was in bleeding-edge last month). However, the new media source will not be in a stable release for a long time so that folks have a fallback while we fix regressions (as well as a version to regression-check against :). While the new media source changes are only in bleeding-edge (which will be a lot more time than usual) folks can also compare bleeding-edge to "regular experimental" when determining if something is regressive. |
|
Looks like the new media source has been deployed, and it works :) I noticed that some games play H264 videos with the wrong color space though, they look washed out. |
|
Which games? Knowing what's affected would help with troubleshooting. |
|
Of the ones that I have tried so far, A Plague Tale Requiem (immediately visible in the intro videos) and a non-steam indie game based on stepmania. I'm very interested in the new media source and I'll be testing every game in my library for regressions. I'll update this post if I find any problem. Update 1: Trombone Champ (Unity 2019) also has washed out colors playing H264 videos Update 2: UE4/5 have no issues with H264 |
|
With the reintroduction of the new media source, the game Ghostbusters: The Video Game Remastered is now able to play 4K MP4 videos! However, some videos display a green bar at the bottom.
From what I understand (though I haven't personally tested this), this issue wasn't present in the initial implementation of the new media source, all videos played without problems back then. Additionally, attempting to play the "Bonus Commercial Footage" video from the "Extras > Videos" section causes the game to crash. |
|
Can confirm the issue with Ghostbusters Remastered. It's minor but it's there |
|
@adolfintel I'm not seeing any washed out colors with Plague Tale: Requiem with my "standard" setup. Could you upload some side-by-side screenshots of where you see the issue? Also, are you still using the same setup as before with full-featured Gstreamer etc? |
|
Yes, I'm still using a full gstreamer. I haven't seen many issues to be honest, if anything the new media source has improved compatibility with some games like starship troopers that didn't want to play videos in crappy formats like wmv. Anyway, screenshot of requiem with the current bleeding-edge: Same intro video in proton stable: I see the same washed out colors in the handful of unity games that use mp4 as well, but I haven't found other games with this issue. |
|
@KeyofBlueS I'm not seeing the green stripe. Could you please copy your system information from Steam (Steam -> Help -> System Information and Steam -> Help -> Steam Runtime Diagnostics) and put each in a gist, then include a link to the gists? Are you also using the full gstreamer setup instead of the official Proton one? Also - I don't have access to that bonus video :( If there is a way for you to upload the game files so that I can get access, that would be really helpful :) |
|
@adolfintel Thank you for the screenshots! I see it now -- will investigate further :) |
|
Hi @alasky17, thanks for getting back! Here are the logs you requested: I dont know about gstreamer, I believe I'm using the official Proton setup. When you mentioned "upload the game files", were you referring to that specific video? If so, you can find it in your game files at Or did you mean a savegame where that extra content is unlocked? If that's the case, I've attached it here: Just extract the archive and place the files in Let me know if there's anything else you need! |
|
@adolfintel The "washed out" issue with some videos like Plague Tale Requiem should be fixed with current bleeding-edge. Please let me know if you see this with any other games! (and exactly where in the games so I can repro easily :). A feature needed to be implemented for a particular video type, and there could be other video types that need something similar that we've missed. Thank you again for your attention to detail and reporting! |
|
@KeyofBlueS Thank you! That is exactly what I was asking for :) Weirdly, I'm not seeing the green stripe OR the crash on the bonus videos with your save (which worked for me to test the right bit, thanks again!!!) ... Could you get 2 logs with both failures? It would be really great if you can get one log with current experimental (not-bleeding-edge) and one with bleeding-edge so that we have something to compare against. Please use PROTON_LOG=+quartz,+strmbase,+strmbase_qc,+gstreamer,+amstream,+qcap,+qcap_v4l,+qedit,+mciqtz,+mci,+mfplat,+gstreamer,+evr,+dxva2,+wmvcore %command% |
|
Here are the Proton logs you requested! Please note that when using the standard Proton Experimental, the game plays lower resolution OGV videos. Only with the current Proton Bleeding-Edge it plays higher resolution MP4 videos. Additionally, when capturing the Proton bleeding-edge log, the game doesn't "crash to desktop" at the bonus video; instead, it freezes on a black screen, requiring a forced stop. In this scenario, the Proton log file grows significantly in size (I stopped the game as quickly as possible, within a few seconds, but the log still ended up being around 550MB), which is why I've compressed and uploaded the logs in a zip file. Thank you for taking the time to look into this issue. I appreciate your help! |
|
@alasky17 Both APT Requiem and Unity games seem to work properly with the current bleeding-edge. Awesome work :) |
|
@KeyofBlueS Thank you for the logs! We figured out what was going on - the game picks up the GPU and monitor, and doesn't play the MP4 videos for certain combinations (which is Windows behavior) so I was accidentally still looking at the ogv video. We will continue to work on these bugs (the green line and the issues with the bonus videos), but it could be some time before they are fixed properly. I believe they are not actually "regressions" caused by new media source, but merely "regular" video playback bugs with the MP4 videos that are only just now working at all. Thank you again for all the info - we will plan to avoid enabling the MP4 videos in stable Proton versions until these bugs are also fixed :) |
|
Thank you for taking a look at this! Feel free to reach out if you need anything further regarding this issue. Best regards. |
|
It looks like the latest Bleeding-Edge update, I'm guessing thanks to commit 8a4c3f6, has mostly resolved the green bar issue, that now only appears for a split second at the start of the initial "logo" video! The crash during the extra "Bonus Commercial Footage" video is still happening. |
|
@KeyofBlueS Thank you for the update! Glad the green bar fix is working for you :) WRT the crash - after some investigation it looks like the root cause is that the mp4 video is simply much larger (unsurprisingly) and Proton struggles to keep up with playing it. We are always trying to make Proton more efficient at video playback to improve perf in general, but that is a longer road than fixing something that is specifically "wrong" like the green stripe :( |
|
@alasky17 I really appreciate the effort in looking into the issue. I'm not entirely sure what you mean by "the video is simply much larger". In any case, I just compared the video that caused the crash, "BR_commercial.mp4", with the other mp4 files using the tool "mediainfo". I noticed that it's the only one with an audio sampling rate of 44.1 kHz, while the others use 48.0 kHz. So I tried converting the audio in "BR_commercial.mp4" from 44.1 kHz to 48.0 kHz using the following steps: Navigate to the directory containing the video files (make sure to replace 'path_to_steamapps_folder' with the actual path to your steamapps directory) Rename the original BR_commercial.mp4 to BR_commercial_44100Hz.mp4 for backup purposes Use ffmpeg to copy the video stream (-c:v copy) without re-encoding After doing this, the video no longer causes the game to crash. And thanks again for investigating the issue! |
|
@KeyofBlueS Thank you so much for the investigation! Somehow in the earlier messages, I missed the fact that it was specifically the "commercial" video that was causing the crash. I looked at some of the other videos in the bonus content and found some significant audio desync with MP4 - this is what I was referring to and what I assumed (incorrectly) was causing the game to completely crash for you. The audio desync in the other videos that I'm seeing (which is more significant than Windows behavior on the same hardware) is due to some inefficiencies with video playback on Proton. I apologize for the inaccurate description earlier - I was rushed with my reply ... although I suppose it worked out because now I realize what I was missing all along (thank you!). When I said the MP4 videos are "bigger", I meant they take more processing power to play. Now that I'm looking at the right thing, I can see the complete crash with the commercial video just like you described. I checked the game on Windows, and the video and audio slowly desync over time as the video plays - this is not too surprising based on your investigation. It seems like they did not intend for the audio sampling rate to differ ... The game does nothing to sync audio and video (which was discovered when investigating the audio/video desync I mentioned above). Even though the 44.1 kHz sampling rate is pretty clearly a game bug, I will still pass along to investigate the crash - it seems like we are certainly not handling things well, as the game does not crash on Windows, merely desync with an increasing gap as the video plays as one might expect. Thank you again for all the detailed investigation! This was incredibly helpful :) |
|
@alasky17 Yes, the game not attempting to sync the audio and video is a known issue, and unfortunately, the developers of this remaster, among other things, were unable to address or resolve this flaw. Thank you for your thorough work on this problem, and as always, please feel free to ask if you need any further clarification or additional information! |
I build Wine regularly using the TkG build system and I've noticed an issue with video playback that started around July 5 when the new media source was pushed to the experimental branch (I couldn't bisect it to the exact commit, most intermediate commits fail to compile).
Every game I tested with the current experimental branch that uses mfplat for videos fails to display them: the audio plays but the video is either completely white, gray or black. This happens both with and without hardware decoding.
Enabling gstreamer debug output, I get the following log when it tries to play a video:
I'm testing on Arch Linux, fully updated with a 6900XT. Gstreamer is installed and working in other applications (and older builds of experimental).
Is this a known issue? Is it supposed to work in tandem with some other component in proton that I'm missing? Am I missing some library?
The text was updated successfully, but these errors were encountered: