[Kratos (wanjinhao1)]

Description

Fixes #3700.

VideoHelper._score_frames_async awaited asyncio.to_thread(self._extract_frames, ...) directly. When the caller was cancelled during extraction, the extraction thread kept running and the temporary frame files it writes (delete=False in _extract_frames) were never returned, scored, or cleaned up — one leaked file per sampled frame on every cancelled video scoring.

This PR adds _extract_frames_async, which mirrors the existing audio-extraction pattern (_extract_video_audio_async): it runs extraction through run_legacy_sync_async so that on cancellation it waits for the extraction thread to finish, then unlinks every temporary frame file before propagating CancelledError. The video source file is never touched.

Tests and Documentation

• Added test_video_frame_scorer_cancellation_during_extraction_async (parametrized over single/double cancel), modeled on the existing audio-cancellation test: it blocks frame extraction on a threading event, cancels the scoring task, releases extraction, and asserts all temporary frame files are removed while the source video survives.
• Ran the full suite: python -m pytest tests/unit/score/test_video_scorer.py -q → 34 passed.

No documentation changes needed (internal cleanup behavior).

---

AI assistance disclosure: this change was implemented with the help of an AI coding agent, on behalf of the PR author wanjinhao1.

[Kratos (wanjinhao1)]

@microsoft-github-policy-service agree

[Roman Lutz (romanlutz)]

Thanks for working on this. #3756 was opened first, and I compared the current heads before closing this duplicate.

I did not find behavior here that #3756 lacks. The earlier PR also handles partially created files when extraction itself fails and has broader regression coverage for failed encoding/writes and repeated cancellation. The one useful additional check here is the explicit assertion that the source video still exists after cancellation. I noted that on the now-merged #3756 as a possible small follow-up test.

I am closing this PR so we keep one implementation for #3700. Thank you again for the contribution.