mfplat : sample size to small when decoding WMV3/NV12

[Theucalyptus]

As mentioned in https://github.com/Open-Wine-Components/umu-protonfixes/issues/82#issuecomment-2261525964, there's been progress on video playback in KiriKiri-powered visual novels when using a full gstreamer and no mediaconverter. This engine has 4 video playback method : overlay, layer, mixer and media foundation. Only overlay works, so I tried to make the others work because some games don't allow the user to choose.

When debugging MF and Mixer, I had these errors using GE9-12 : wg_transform.c:714:copy_video_buffer: Output buffer is too small : 921600 < 1382400.

912600 is the computed sample size for a MFVideoFormat_NV12 1280x720 video, so 8bpp. And 1382400 is the same but with 12bpp, which seems to be what gst/quartz are reporting/using.

Naively, I changed mf_get_stride_for_format() to compute the stride using bit per pixel instead of byte per pixel and to my surprise it fixes the issue (minus some flashing frames as the beginning of playback). I'm not really sure why NV12 would be 8bpp but after some googling I'm even more confused so...

PS: only applies without mediaconverter : with it theses games don't have video playback at all even though some of them are Deck Verified (like 1230140) and have a transcoded_video.foz. Fixing this issue would at least allow them to work more easily with downstream Proton forks.

Logs : steam-1230140.log

[layercak3]

Please test in GE-Proton9-7 with media converter disabled. I think this is a regression between the bleeding-edge commit picked in 9-7 and 9-8. (824ccfa43f05bf7eeb39bccaec91b464bc2614e7, 3e1c699fdcca554f01d3b7d4db7c25f41c18691d)

[ghost]

Please test in GE-Proton9-7 with media converter disabled. I think this is a regression between the bleeding-edge commit picked in 9-7 and 9-8. (824ccfa, 3e1c699)

Yes, can confirm that playback works fine in 9-7.

[layercak3]

The new changes from a few hours ago broke wmv playback (only audio might play depending on vomstyle or if you wait a few seconds), now neither -vomstyle=overlay nor your patch fix the issue anymore. h264/mpeg still works fine though

[layercak3]

This applied on latest bleeding-edge helps. https://gitlab.winehq.org/wine/wine/-/merge_requests/6536

Specifically, 9d08b87d42f439beca32d20e46d838e51856d8d8, for when they force-push and the commit is lost.

[layercak3]

Patch to fix a regression for applications which use WMA Lossless audio in wine 9.13+ (and valve bleeding-edge since Sep 6 rebase) caused by https://gitlab.winehq.org/wine/wine/-/merge_requests/5805

diff --git a/dlls/winegstreamer/wg_media_type.c b/dlls/winegstreamer/wg_media_type.c
index a8b3f75ea28..09d8e313698 100644
--- a/dlls/winegstreamer/wg_media_type.c
+++ b/dlls/winegstreamer/wg_media_type.c
@@ -163,6 +163,18 @@ static void init_caps_from_wave_format_wma3(GstCaps *caps, const WMAUDIO3WAVEFOR
     gst_caps_set_simple(caps, "bitrate", G_TYPE_INT, format->wfx.nAvgBytesPerSec * 8, NULL);
 }
 
+static void init_caps_from_wave_format_wma4(GstCaps *caps, const WMAUDIO3WAVEFORMAT *format, UINT32 format_size)
+{
+    init_caps_codec_data(caps, &format->wfx + 1, format->wfx.cbSize);
+
+    gst_structure_remove_field(gst_caps_get_structure(caps, 0), "format");
+    gst_structure_set_name(gst_caps_get_structure(caps, 0), "audio/x-wma");
+    gst_caps_set_simple(caps, "wmaversion", G_TYPE_INT, 4, NULL);
+    gst_caps_set_simple(caps, "block_align", G_TYPE_INT, format->wfx.nBlockAlign, NULL);
+    gst_caps_set_simple(caps, "depth", G_TYPE_INT, format->wfx.wBitsPerSample, NULL);
+    gst_caps_set_simple(caps, "bitrate", G_TYPE_INT, format->wfx.nAvgBytesPerSec * 8, NULL);
+}
+
 static void init_caps_from_wave_format(GstCaps *caps, const GUID *subtype,
         const void *format, UINT32 format_size)
 {
@@ -178,9 +190,10 @@ static void init_caps_from_wave_format(GstCaps *caps, const GUID *subtype,
         return init_caps_from_wave_format_wma1(caps, format, format_size);
     if (IsEqualGUID(subtype, &MFAudioFormat_WMAudioV8))
         return init_caps_from_wave_format_wma2(caps, format, format_size);
-    if (IsEqualGUID(subtype, &MFAudioFormat_WMAudioV9)
-            || IsEqualGUID(subtype, &MFAudioFormat_WMAudio_Lossless))
+    if (IsEqualGUID(subtype, &MFAudioFormat_WMAudioV9))
         return init_caps_from_wave_format_wma3(caps, format, format_size);
+    if (IsEqualGUID(subtype, &MFAudioFormat_WMAudio_Lossless))
+        return init_caps_from_wave_format_wma4(caps, format, format_size);
 
     GST_FIXME("Unsupported subtype " WG_GUID_FORMAT, WG_GUID_ARGS(*subtype));
 }

[kisak-valve]

Hello @layercak3, at a glance, that looks like something to send upstream and then request it get cherry picked for Proton after the merge request is accepted upstream.

[layercak3]

Just documenting it for now, when I have some time in the future to look at this again and a dev hasn't fixed it by then I will probably file a wine bug.

[ghost]

Closing as with new proton media development this issue exact isn't relevant any more.