Я наблюдаю, как GStreamer работает на iOS утечки файловых дескрипторов от glimagesink, которые в конечном итоге приводят к следующим ошибкам:
GST_POLL gstpoll.c:724:gst_poll_new:[00m 0x1068c1ae0: can't create socket pair !
gst_poll_write_control: assertion 'set != NULL' failed
Это происходит после 50-200 циклов разрушения конвейера (или просто glimagesink) и воссоздание. Мой основной код - динамический c, но то же самое происходит с iOS примером кода # 3, gst_parse_launch и конвейером вроде
udpsrc ! rtph264depay ! decodebin ! tee name=t t. ! queue ! glimagesink
. Я могу остановить его, закомментировав этот вызов в мой код (но тогда я не получаю отображение):
gst_video_overlay_set_window_handle(GST_VIDEO_OVERLAY(video_overlay), (guintptr) (id) ui_view);
Я не могу запустить valgrind для проверки утечки GStreamer, и профилировщик утечек iOS, похоже, не подхватывает это. То, что я вижу, - это увеличение числа дескрипторов, которые выглядят так:
File Descriptor 32 number 31 in use for: /private/var/mobile/Containers/Data/Application/<uuid>/Library/Caches/com.company.app/com.apple.opengl/linkCache.data
Итак, я понял, что что-то не выпускает дескрипторы linkCache.data. Что-то в создании glwindow или glcontext (g_main_context_new()?). Я не могу найти какую-либо информацию о файле linkCache.data или о том, что / почему iOS делает с ним.
Я пытался использовать unref() больше, но это просто приводит к сбоям, и кажется, что GstElements, которые я храню в коде, утилизируются правильно. Похоже, единственное, что я не пробовал, это перекомпилировать библиотеку с изменениями.
Возможно, GWakeup аварийно завершает работу, а вот стек вызовов: 
Любые идеи или вещи, чтобы попробовать? Как правильно выпустить GstVideoOverlay, возвращенный из set_window_handle? Я делаю это unref(), но этого недостаточно.