Zebediah Figura (@zfigura) commented about dlls/winegstreamer/wg_format.c:
> return NULL;
>
> gst_video_info_set_format(&info, video_format, format->u.video.width, abs(format->u.video.height));
> + info.fps_n = format->u.video.fps_n;
> + info.fps_d = format->u.video.fps_d;
> + if (!format->u.video.fps_d && !format->u.video.fps_n)
> + info.fps_d = 1;
This may be correct (although I'm curious if it actually matters here?) but should be a separate patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48901
Zebediah Figura (@zfigura) commented about dlls/winegstreamer/wg_parser.c:
> * file (or other medium), but gst_event_new_qos() expects the timestamp in
> * running time. */
> stream_time = gst_segment_to_running_time(&stream->segment, GST_FORMAT_TIME, params->timestamp * 100);
> - if (stream_time == -1)
> + if (stream_time == -1 || -params->diff*100 >= stream_time)
That doesn't seem right. What is this doing?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48900
Zebediah Figura (@zfigura) commented about dlls/winegstreamer/wg_format.c:
> if (gst_video_info_from_caps(&info, caps))
> wg_format_from_video_info(format, &info);
> }
> - else if (!strcmp(name, "audio/mpeg"))
> + else if (!strcmp(name, "audio/mpeg") && gst_structure_get_boolean(structure, "parsed", &parsed) && parsed)
This is correct, I think, but also orthogonal to the purpose of this patch. Can you please split this out into a separate patch?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48897
Zebediah Figura (@zfigura) commented about dlls/winegstreamer/quartz_parser.c:
> * but as long as every sample fits into our allocator, we're fine. */
> return format->u.video_cinepak.width * format->u.video_cinepak.height * 3;
>
> + case WG_MAJOR_TYPE_VIDEO_MPEG1:
> + return wg_format_get_bytes_for_uncompressed(WG_VIDEO_FORMAT_YV12,
> + format->u.video_mpeg1.width, format->u.video_mpeg1.height);
> +
This is overestimation because we can't do any better, right? In that case it probably deserves a comment just to clarify that's what's happening.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3938#note_48896
On Mon Oct 16 21:55:32 2023 +0000, Alfred Agrell wrote:
> Unfortunately, we do. I had sleeps everywhere during development, then
> removed every one I could, but that specific one is load-bearing.
> https://testbot.winehq.org/JobDetails.pl?Key=138782&f101=exe64.report
> https://testbot.winehq.org/JobDetails.pl?Key=138783&f101=exe64.report
> I tried swapping it for IBaseFilter_GetState(), but that just returned
> immediately then gave the same segfault. https://testbot.winehq.org/JobDetails.pl?Key=138786&f101=exe64.report
> Calling GetState twice worked, but I'm pretty sure that's just because
> those calls take long enough to satisfy its timing demands. A sleep is
> cleaner. (Slightly. Still ugly.)
> I could also move the sleep, but I don't think that would accomplish anything.
Hrm, that's suspicious, IMemAllocator::GetBuffer() returns VFW_E_NOT_COMMITTED. Does the VMR's IMemAllocator change by any chance when we reconnect? I.e. is IMemInputPin::GetAllocator() actually returning the same allocator that it was returning before?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3970#note_48893