Здравствуйте, Sharov, Вы писали:

C>>По моему опыту в большинстве случаев виснет если буфера переполнены. Я бы попробовал queue в пайплайн добавить. Сначала без ограничения размера и посмотрел бы, как размер памяти процесса себя ведёт.

S>Вот тут я добавил больше деталей и debug сообщения -- https://lists.freedesktop.org/archives/gstreamer-devel//2023-August/081632.html

Ну вот, в пуле буфера кончились. Конкретно здесь с queue промашка вышла — я забыл, что у appsink есть своя собственная очередь с неограниченным размером по умолчанию, так что здесь дополнительная очередь проблемы не решает. А скажи, пожалуйста, если в том месте, где у тебя SetState(State.Null), вместо Null Paused выставить (у тебя же всё равно зависание на первой итерации происходит), тоже виснуть будет? Я повторил твой пример (под lin, надо будет под win попробовать, потому как по логам явная отсылка к d3d11, ты, кстати, с какой версией gstreamer работаешь?), но зависания не добился. Ежели в любом случае виснуть будет, то, на мой взгляд, следуюший шаг — это после того как все элементы в пайплайн добавятся, найти этот bufferpool и выставить ему max_buffers в 0.

S>Кстати, код выше (AddProbe) он вообще корректен для получения времени кадра, т.е. я могу рассчитывать на то, что в probeInfo.Buffer находится прям целый
S>кадр, а не какой-то чанк или вообще какие-нибудь странные данные? Пока кажется, что в буффере действительно находится фрейм.

Врать не буду — не знаю, могу ориентироваться только на описание splitmuxsink. Вообще-то, ты же ему на вход вроде уже закодированный поток передаёшь, или я чего-то не понимаю.

"This element wraps a muxer and a sink, and starts a new file when the mux contents are about to cross a threshold of maximum size of maximum time, splitting at video keyframe boundaries."