Спасибо за быстрое исправление, но к сожалению с svpflow2 4.7.0 у меня плееры (MPC-HC и mpv) выбивают ошибку при проигрывании HDR
Ниже репорт от ИИ, если нужны подробности
========================================================================
svpflow2 4.7.0.320: запись по нулевому указателю, mpv падает через 15-60 секунд воспроизведения
После обновления компонентов core.flow64 и core.flow64vs mpv стабильно падает через 15-60 секунд после начала воспроизведения HDR. Откат одного только svpflow2 на 4.6.0.274 полностью убирает проблему.
Авария — access violation при записи по адресу 0, внутри svpflow2_vs.dll, на фиксированном смещении +0x6750.
Это не тот use-after-free при разрушении фильтра, о котором шла речь в прошлый раз: тот в 4.7.0.320 исправлен, проверил отдельно — раздел 8.
1. Окружение
SVP 4 Pro 4.7.0.302 (менеджер не обновлялся)
svpflow2_vs.dll 4.7.0.320 — виновник
svpflow2_vs.dll 4.6.0.274 — на ней всё работает
svpflow1_vs.dll 4.5.0.205
VapourSynth R73, штатная из поставки SVP — падает
VapourSynth R77 — падает одинаково
AVSF 1.4.8 # svp (ваша сборка) и 1.4.9 — одинаково
mpv v0.41.0-424-gbefe1e73a
Windows 10 Pro 19045, RTX 5070 Ti, драйвер 32.0.16.1074
Обновление принесло только эти два компонента. Важная деталь: svpflow1_vs.dll в обеих поставках побайтово одинаков (SHA-256 AC79CD31801B0462BC91CCEE101FF2AF8B6E712211D90FFE46F046DABE4A1EF7) — installer его перезаписал тем же содержимым. То есть изменился ровно один файл.
svpflow2_vs.dll 4.7.0.320 SHA-256 D05B7AC3CAEF6A9C990F339124B709821BFC6922DA9BB9A83B3CD5F28F237D3B
svpflow2_vs.dll 4.6.0.274 SHA-256 5F84A299EB447C09ABBAF483399B1F1AAAA9E49B2BEB8C6E6C0BEE8AC2D62643
2. Симптом
Картинка замирает, звук начинает икать, появляется окно «mpv has stopped working». Не при закрытии файла и не при пересборке скрипта — посреди обычного воспроизведения, без перемотки и без изменения настроек.
Четыре падения, Application Error:
время аптайм mpv код смещение стек
------------------------------------------------------------------------
22:50:14 ~44 c 0xc0000005 0x6750 R77 + наш AVSF
22:51:16 ~48 c 0xc0000005 0x6750 R77 + наш AVSF
22:58:07 ~18 c 0xc0000005 0x6750 R77 + наш AVSF
23:24:46 ~30 c 0xc0000005 0x6750 R73 сток + AVSF 1.4.8 # svp
Во всех четырёх — svpflow2_vs.dll 4.7.0.320 и одно и то же смещение. В логах SVP при этом ни одной строки уровня E или W.
3. Разбор дампов
Три дампа WER, разные потоки, всё остальное совпадает до бита:
ExceptionCode: c0000005 (Access violation)
Parameter[0]: 1 <- ЗАПИСЬ
Parameter[1]: 0 <- по адресу NULL
rip = svpflow2_vs+0x6750 <- здесь падает
обратный стек (дамп на штатной R73):
svpflow2_vs+0x6750
svpflow2_vs+0x19950 <- вызывающий
VapourSynth.dll+0x1a1cff <- ядро VapourSynth запрашивает кадр
На R77 стек тот же, только ядро называется libvapoursynth+0x97032. Смещения внутри svpflow2 в обоих случаях совпадают: +0x6750 и +0x19950.
Это запись по нулевому указателю, а не повреждение кучи и не use-after-free: адрес отказа ровно 0, смещение стабильное от запуска к запуску. Похоже на указатель, который в 4.6.0.274 либо всегда был валиден, либо проверялся, а в 4.7.0.320 в каком-то состоянии остаётся нулевым.
4. Конфигурация графа
Профиль RIFE 2160p. Источник 3840x2160 HEVC, YUV 4:2:0, 10 бит, BT.2020 PQ, 23.976 fps, выход 47.952.
super = core.svp1.Super(input_m8, "{pel:1,scale:{up:0},gpu:1,full:false}")
vectors = core.svp1.Analyse(super["clip"], super["data"], input_m8,
"{vectors:2,block:{w:32,overlap:0},main:{search:{coarse:{distance:-8,bad:{range:0},width:530},distance:0}}}")
smooth = core.svp2.SmoothFps_RIFE(input_m, smoothfps_params, rife_out=smooth,
vec_src=vec_src, vdata=vdata, src=input_um, fps=src_fps)
smoothfps_params = "{gpuid:11,gpu_qn:2,rate:{num:2,den:1},algo:13,mask:{area:100},scene:{blend:true},hdr:{dovi:false}}"
5. Похоже, задета HDR / 10-битная ветка
На той же сборке 4.7.0.320 и том же профиле RIFE 2160p обычный SDR-ролик 4K (3840x2160, AVC, 8 бит, 29.97) отыграл 97 секунд без единого сбоя и был остановлен штатно. HDR-источник на этой же сборке падал четыре раза из четырёх за 18-48 секунд.
В сгенерированном скрипте между этими двумя прогонами отличаются ровно две вещи, обе — HDR-ветка:
HDR (падает) SDR (чисто)
smoothfps_params ...,scene:{blend:true},hdr:{dovi:false} ...,scene:{blend:true}
input_m8 input_m.resize.Point(YUV420P8) input_m8 = input_m
input_m / src остаются 10-битными 8 бит
То есть в HDR-случае в опции добавляется ключ hdr:, а motion search идёт по отдельному 8-битному клипу, тогда как основной клип и src десятибитные.
Оговорки: SDR-прогон один против четырёх HDR-падений, и файл был другой (AVC 8 бит 29.97 против HEVC 10 бит BT.2020 PQ 23.976). Кодек и частота кадров до плагина не доходят, но одного и того же материала в двух битностях я не проверял.
6. Чего добиться не удалось
Скриптом на голой VapourSynth авария не воспроизводится. Тот же граф, тот же кусок того же файла (10 бит, crop до кратного 32, те же параметры вплоть до hdr:{dovi:false}), 300 кадров синхронным get_frame — чисто:
ветка склейки сцен результат
---------------------------------------------------------------
SmoothFps_RIFE нет 300 кадров, чисто
SmoothFps_RIFE каждые 7 300 кадров, чисто
SmoothFps_RIFE + hdr:{dovi:false} каждые 7 300 кадров, чисто
SmoothFps + hdr:{dovi:false} каждые 7 300 кадров, чисто
Похоже, триггер живёт в realtime-условиях плеера — асинхронные многопоточные запросы кадров, дропы, — а не в самой последовательности фильтров. Поэтому какая из точек входа виновата, я утверждать не могу: живьём проигрывался только профиль RIFE 2160p, классический SmoothFps на 4.7.0.320 в плеере не проверялся.
7. Что исключено
VapourSynth. Специально проверил на штатной R73 из вашей поставки: R77 переименована так, что загрузиться не могла, VSPipe --version отвечает Core R73, в стеке дампа стоит VapourSynth.dll, а не libvapoursynth.dll. Падение то же и на том же смещении.
AVSF. Одновременно с R73 возвращена ваша сборка 1.4.8 # svp вместо нашей 1.4.9. Разницы нет. (К mpv это и так не относится, AVSF работает только в DirectShow-плеерах.)
svpflow1. В обеих поставках побайтово одинаков, см. раздел 1.
Откат. Подменены только три файла svpflow2 на 4.6.0.274, svpflow1 не трогался — воспроизведение стабильно.
Модуль в отчёте об ошибке один и тот же во всех четырёх падениях, это не «пострадавший» сосед: rip указывает внутрь svpflow2, а не на чужой код.
8. Заодно: use-after-free при teardown в 4.7.0.320 исправлен
Тот дефект (free структуры инстанса и следом _Mtx_unlock по мьютексу внутри неё, +0x6d5d / +0x6d71) в 4.7.0.320 больше не воспроизводится.
Проверял тем же способом, что и тогда — full page heap на переименованной копии питона, cdb, голый скрипт VapourSynth с циклами сборки и разрушения графа, ветка SmoothFps:
сборка циклов результат
------------------------------------------------------------------
4.6.0.274 3 падает: MSVCP140!_Mtx_unlock+0x4,
"in free-ed allocation", RVA 0x221D1
4.7.0.320 5 все циклы прошли, аварии нет
Контрольный прогон на 4.6.0.274 сделан в той же сессии, на той же машине и том же файле — то есть метод рабочий, и чистый результат на 4.7.0.320 не артефакт окружения. Какая именно DLL загружена, видно и в выводе скрипта, и в ModLoad отладчика.
Пишу об этом здесь, потому что обе новости про одну и ту же сборку: teardown починен, но появилась запись по NULL из разделов выше.
Готов приложить дампы (два, по 190 МБ), прогнать проверочную сборку или собрать дамп с page heap, если это поможет.