A 100%-chance hanging scenario

[chainikdn]

Open video, wait for SVP to kick-in and stabilize, move the quality/perf slider in SVP and immediately after that click on the video timeline. There's probably a race condition when seeking while the filter is still "working" on script reloading via RC, IF script reloading takes a lot of time (such as SVP script with GPU acceleration enabled). I can't trigger hang with seeking only or moving SVP's slider only. It only appears when both events happen at the same time.

[chainikdn]

BTW I can see that the script is recreated TWICE on every seek. Why?

[CrendKing]

I can reproduce the freeze only on madVR. The freeze was at its input pin's QueryAccept(). Can you do it on say EVR?

BTW I can see that the script is recreated TWICE on every seek. Why?

What do you mean? Where do you see it twice?

[chainikdn]

What do you mean? Where do you see it twice?

T  19504 @    35271: Start processing output frame   1479 at  308700396 ~  308910395 frameTime     209999 for source    739 Output queue size 32 Front   1480 Back   1511
T   8044 @    35271: Frame handler begin flush
T   8044 @    35271: Frame handler wait for barriers
T  19504 @    35274: GarbageCollect frame    739 pre refcount    1 post queue size 18
T  19504 @    35274: Output worker thread wait for flush
T   8044 @    35398: Frame handler end flush
T   8044 @    35398: ReloadAviSynthScript
T   8044 @    35908: Frame handler begin flush
T   8044 @    35908: Frame handler wait for barriers
T  19504 @    35908: Output worker thread wait for flush
T   8044 @    35912: Frame handler end flush
T   8044 @    35912: ReloadAviSynthScript
T  24400 @    36461: Processed source frame:      0 at          0 ~     417083, nextSourceFrameNb      0 nextOutputFrameStartTime          0
T  24400 @    36465: Processed source frame:      1 at     420000 ~     837083, nextSourceFrameNb      1 nextOutputFrameStartTime          0
T  24400 @    36465: Create output frame      0 for source frame      0 at          0 ~     209999

[chainikdn]

Can you do it on say EVR?

Hmm... nope. But I can't do it with madVR and "GPU accel" off in SVP either. So probably it actually hangs somewhere in the video driver or something like this... in which case removing unnecessary (?) GPU reinitialization (two times on every seek vs. one time) may help a bit.

[CrendKing]

About the reload twice issue. The flush comes from upstream, twice. And I can only get this behavior in MPC-HC. MPC-BE only flushes once. I also tested with EVR and madVR on MPC-HC. Not related to renderer.

The call stack of the two flushes are exactly the same. Could be a bug of MPC-HC. You could file a ticket to clsid2.

EVR call stack

avisynth_filter_64.ax!AvsFilter::FrameHandler::Flush() Line 161
avisynth_filter_64.ax!AvsFilter::CAviSynthFilter::EndFlush() Line 372
avisynth_filter_64.ax!CTransformInputPin::EndFlush() Line 740
[Inline Frame] LAVVideo.ax!CTransformFilter::EndFlush() Line 437
LAVVideo.ax!CLAVVideo::EndFlush() Line 955
LAVVideo.ax!CTransformInputPin::EndFlush() Line 741
LAVSplitter.ax!CLAVOutputPin::DeliverEndFlush() Line 301
LAVSplitter.ax!CLAVSplitter::DeliverEndFlush() Line 1052
LAVSplitter.ax!CLAVSplitter::SetPositionsInternal(void * caller, __int64 * pCurrent, unsigned long dwCurrentFlags, __int64 * pStop, unsigned long dwStopFlags) Line 1228
LAVSplitter.ax!CLAVOutputPin::SetPositions(__int64 * pCurrent, unsigned long dwCurrentFlags, __int64 * pStop, unsigned long dwStopFlags) Line 648
quartz.dll!CPosPassThru::SetPositions(__int64 *,unsigned long,__int64 *,unsigned long)
mpc-hc64.exe!CStreamSwitcherPassThru::SetPositions(__int64 * pCurrent, unsigned long CurrentFlags, __int64 * pStop, unsigned long StopFlags) Line 167
quartz.dll!CPosPassThru::SetPositions(__int64 *,unsigned long,__int64 *,unsigned long)
quartz.dll!CFGControl::CImplMediaSeeking::SetMediaTime(__int64 *,unsigned long,__int64 *,unsigned long)
quartz.dll!CFGControl::CImplMediaSeeking::SetPositions(__int64 *,unsigned long,__int64 *,unsigned long)
mpc-hc64.exe!CMainFrame::SeekTo(__int64 rtPos, bool bShowOSD) Line 15296
mpc-hc64.exe!CMainFrame::OnHScroll(unsigned int nSBCode, unsigned int nPos, CScrollBar * pScrollBar) Line 3062
mpc-hc64.exe!CWnd::OnWndMsg(unsigned int message, unsigned __int64 wParam, __int64 lParam, __int64 * pResult) Line 2698
mpc-hc64.exe!CWnd::WindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2099
mpc-hc64.exe!CMainFrame::WindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 17580
mpc-hc64.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 265
mpc-hc64.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 417
user32.dll!UserCallWinProcCheckWow()
user32.dll!DispatchMessageWorker()
mpc-hc64.exe!AfxInternalPumpMessage() Line 183
mpc-hc64.exe!CWinThread::Run() Line 629
mpc-hc64.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 61
[Inline Frame] mpc-hc64.exe!invoke_main() Line 118
mpc-hc64.exe!__scrt_common_main_seh() Line 288
kernel32.dll!00007ff830697034()
ntdll.dll!00007ff83097cec1()

[chainikdn]

Indeed... ok, if there's nothing we could do about it here I'll close this for now.

[CrendKing]

FYI, tested on the released version of MPC-HC 1.9.7 x64 and the development 1.9.7.100 x64.