directory tree based gst-rtsp-server app

[Gregor Boirie]

Hi,

I'm trying to implement a standalone gst-rtsp-server based daemon serving a
whole local directory hierarchy and I have a couple of questions for
gst-rtsp-server developpers.

Currently, my prototype is able to recursively monitor a configured root
directory with discovered "playable" children registered to a GstRTSPMountPoints
object.
Pipelines are created using a single custom GstRTSPMediaFactory object, derived
from GstRTSPMediaFactoryURI implementation where the "create_element" method is
overloaded to give uridecodebin a proper URI.
This single factory handles all entries (related to a single top-level
directory) registered to the mount points object mentionned above.

However, I'm wandering if this approach suits well with the way gst-rtsp-server
is designed and I'd like to hear your suggestions.

1/ mount points and prefix based URI / factory removal
-------------------------------------------------------

I want to reuse GstRTSPMountPoints's internal GSequence to manage
individual file entries / URI. References to related real directories
are kept in a separate application level GTree. Directories life-cycle is
monitored through GFileMonitor / inotify combination.

When a whole sub-directory is removed from file system, application receive a
single "directory deletion" event. Therefore, I need a way to unregister a
whole directory hierarchy from the mount points object. Something like "remove
all entries begining with this path prefix"...
Which means patching rtsp-mount-points.c, something that I'd like to avoid.

Would you see any other way to implement such a feature ?


2/ multiple URI / single factory mappings and ref counting
----------------------------------------------------------

Factory is g_object_unref'ed at gst_rtsp_mount_points_remove_factory time
although not g_object_ref'ed in gst_rtsp_mount_points_add_factory.

This leads to reference counting inconsistencies when mount points object is
destroyed (gst_rtsp_mount_points_finalize -> g_sequence_free ->
data_item_free).

An additional "g_object_ref (factory);" in "data_item_new ()" fixes these for
me. Is this a bug or do I miss something ?


Regards,
Grégor