Christian Costa wrote:
Hi,
Changelog: Don't fail a connection because an input pin does not expose the IMemInputPin interface (pull pins typically).
This seems wrong. The FileAsyncReaderPin (and any other output pin that connects to a pull pin) should override the pConnectSpecific function so that it doesn't query for IMemInputPin. I can't explain why this isn't currently done.
Fixed a bug that made the connection possible whereas no suitable media type has be found during the negociation.
Good catch.
Fixed the release of the media sample in PullPin_Thread_Process.
Again, good catch. I see now that without this fix we would have leaked ref counts on the IMediaSample object.
Added and fixed a lot of traces.
I don't really like the (%p/%p)->... notation, but if it helps you in debugging then it's fine.
Rob
I don't really like the (%p/%p)->... notation, but if it helps you in debugging then it's fine.
Well, I introduced this notation in the D3D code to log both the interface given by the application AND the 'base' object from the Wine side.
Which is sometimes useful to debug when we get problems with object version mismatch.
Lionel
Robert Shearman wrote:
Christian Costa wrote:
Hi,
Changelog: Don't fail a connection because an input pin does not expose the IMemInputPin interface (pull pins typically).
This seems wrong. The FileAsyncReaderPin (and any other output pin that connects to a pull pin) should override the pConnectSpecific function so that it doesn't query for IMemInputPin. I can't explain why this isn't currently done.
You're simply right. This is wrong. Ok, I will resent a patch without this change for the moment.
I don't really like the (%p/%p)->... notation, but if it helps you in debugging then it's fine.
Well, I won't repeat what Lionel said but this has been very usefull for debugging the quartz code.
Christian
-
Christian Costa -
Lionel Ulmer -
Robert Shearman