On Mon Aug 22 22:03:30 2022 +0000, **** wrote:
Zebediah Figura (she/her) replied on the mailing list: ``` On 8/20/22 09:03, R��mi Bernon wrote:
+static HRESULT WINAPI test_pin_ReceiveConnection(IPin *iface, IPin *peer, const AM_MEDIA_TYPE *mt) +{ + return S_OK; +} + +static HRESULT WINAPI test_pin_Disconnect(IPin *iface) +{ + return S_OK; +} Refcounting-wise this isn't exactly legal. I'd recommend using strmbase_sink for the IPin implementation, which would save a lot of code anyway. +static HRESULT WINAPI test_mem_input_pin_ReceiveMultiple(IMemInputPin *iface, + IMediaSample **samples, long count, long *processed) I don't think we want to use "long"; it won't do the right thing without MinGW. +{ + struct test_pin *impl = impl_from_IMemInputPin(iface); Please use more descriptive names than "impl". The rest of DirectShow uses "pin" here. + winetest_push_context("%u", !!receive_can_block); It'd be nice to be a little less terse here. + hr = IBaseFilter_EnumPins(filter, &enum_pins); + ok(hr == S_OK, "Got hr %#lx.\n", hr); + hr = IEnumPins_Next(enum_pins, 1, pins, NULL); + ok(hr == S_OK, "Got hr %#lx.\n", hr); + hr = IPin_Connect(pins[0], &video_pin.IPin_iface, &video_mt); + todo_wine + ok(hr == S_OK, "Got hr %#lx.\n", hr); + if (hr != S_OK) + { + hr = IPin_Connect(pins[0], &video_pin.IPin_iface, &wine_video_mt); + ok(hr == S_OK, "Got hr %#lx.\n", hr); + } + IPin_Release(pins[0]); It'd be simpler just to use IBaseFilter::FindPin(), as in other DirectShow tests. Note that we already have tests for pin order anyway. Is there any reason to pass a specific media type instead of using NULL? + hr = IBaseFilter_GetState(filter, INFINITE, &state); INFINITE should be avoided in tests. [And if Run() returns S_OK, it should be sufficient to pass zero here.]
Is there any reason to pass a specific media type instead of using NULL?
No real reason, just didn't know we could, but now it actually shows a difference from native, that Wine doesn't accept compressed types, which imho is worth keeping. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/686#note_6713