The 2/6 problem is that GStreamer doesn't give us any PTS for Cinepak videos. With decodebin_parser, the Cinepak decoder's GstVideoDecoder base class takes the DTS, and previous PTS, and fills in missing PTS; I couldn't decipher the exact formula, so I just picked something.
If PTS plus duration feels better to you, then so be it. For some reason, the first frame does have a PTS.
avidemux sets PTS on keyframes, so that's an explanation.
Technically DTS is not supposed to mean PTS. They're supposed to increase at the same rate but they may not be equal. DirectShow doesn't directly have the concept of the DTS [note that SetTime() vs SetMediaTime() is not this]. GstVideoDecoder will supply PTS from DTS using this assumption, or supply PTS from the previous PTS plus duration.
I'm not sure that *just* using DTS is safe either, exactly. Ideally we should just omit PTS if it isn't present. The MPEG-1 splitter doesn't always output PTS. The AVI splitter does, and if some application depends on that then I'd prefer to use AVI-specific code.
The 6/6 deadlock consists of the AVI decoder calling IMemInputPin_Receive, which, for some reason, calls into another thread that calls qc_Notify. It works in decodebin_parser seemingly by accident; that function doesn't take any PE-side locks, it just calls into Unix code directly (and Unix-side locks are, of course, not held while calling IMemInputPin), so I just mirrored that.
If you can think of a better solution, do tell. Release the lock before calling IMemInputPin, maybe? But the release is higher up the call stack, so there's no obvious way to do that. Release lock, call IMemInputPin, and re-acquire lock just so strmbase/pin.c can release it?
I don't have my full notes unfortunately, but according to my limited notes I actually tested with a native filter [not sure which], and blocking in Notify() and calling Receive() does block, so it sounds like the deadlock you're describing is a real deadlock on Windows. What component is calling Notify() from Receive() and doing it from a separate thread? Is it a Wine component? Why is it using a separate thread if the call is apparently synchronous anyway?
Perhaps the filter I tested with wasn't the AVI decoder, and the AVI decoder really is immune to this deadlock. Further speculation is that our QC logic in the AVI decoder is not what native does and should just be deleted. I won't ask you to go through testing that, but I would like to know why we're calling back from a separate thread that Receive() is blocking on anyway.