I was running the unit tests under valgrind like so:

GST_CHECKS=test_media_prepare,test_media_reset make -C tests/check/ gst/media.valgrind

only to find:

Running suite(s): rtspmedia
==13799== 128 (40 direct, 88 indirect) bytes in 1 blocks are definitely lost in loss record 3,318 of 3,497
==13799==    at 0x697D24A: g_type_create_instance (gtype.c:1846)
==13799==    by 0x6952801: g_object_new_internal (gobject.c:1746)
==13799==    by 0x6952FDA: g_object_newv (gobject.c:1890)
==13799==    by 0x6951F75: g_object_new (gobject.c:1556)
==13799==    by 0x4E539E9: gst_rtsp_thread_pool_new (rtsp-thread-pool.c:351)
==13799==    by 0x404B6D: test_media_reset (media.c:311)
==13799==    by 0x5FD1676: tcase_run_tfun_fork (check_run.c:372)
==13799==    by 0x5FD108D: srunner_iterate_tcase_tfuns (check_run.c:175)
==13799==    by 0x5FD1483: srunner_run_tcase (check_run.c:302)
==13799==    by 0x5FD0FA2: srunner_iterate_suites (check_run.c:150)
==13799==    by 0x5FD1CDA: srunner_run_all (check_run.c:561)
==13799==    by 0x5FC7C56: gst_check_run_suite (gstcheck.c:693)
==13799==    by 0x405472: main (media.c:365)
==13799== 
100%: Checks: 2, Failures: 0, Errors: 0

Then I examined the code and found another instance of the leak suprisingly not caught by valgrind. The attached patch plugs both memory leaks.