On Thu Apr 17 07:07:45 2025 +0000, Brendan McGrath wrote:
- Why does it sometimes work under Wine
I found that when Wine succeeds, we get the following entry logged:
gstnvdecoder.cpp:851:gst_nv_decoder_output_picture:<nvh264dec0> Negotiate again on reconfigureThis is a the result of the `GST_PAD_FLAG_NEED_RECONFIGURE` flag being set on the `nvh264dec0:src` pad when it tries to push a buffer. That flag is set when we link `decodebin0` to `deinterlace0`. But the pipeline processing begins as soon as `decodebin0` finishes linking internally. So the order in which the reconfigure flag is set and when a buffer is sent is indeterminable (thus sometimes it works, sometimes it doesn't).
- Why does it always work with `gst-launch-1.0`
The simple answer is timing. If I apply the following patch: [gstreamer.patch](/uploads/8c5dd45b70be7f4fda8957daf53cb04c/gstreamer.patch) then `gst-launch-1.0` fails 100% of the time. This patch just delays the setting of the reconfigure flag by 10ms. However, even with this delay, when this MR is applied to Wine, Wine will succeed 100% of the time (as it has no need to reconfigure).
Since we are immediately doing a reconfigure, is the not-negotiated error actually a problem, or is it just transient?
However, even with this delay, when this MR is applied to Wine, Wine will succeed 100% of the time (as it has no need to reconfigure).
I'm confused, you just said we are doing a reconfigure, and we should be if we're linking a new pad?