[Bug 756964] New: rtspsink (RTSP RECORD) pausing / handling of non-contiguous timestamps

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=756964

            Bug ID: 756964
           Summary: rtspsink (RTSP RECORD) pausing / handling of
                    non-contiguous timestamps
    Classification: Platform
           Product: GStreamer
           Version: 1.6.0
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gst-rtsp-server
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: fraxinas at opendreambox.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

i've got the following scenario:
my audio+video sources produce streams which are being muxed into mpeg-TS and
then tee'd into a LAN rtsp-server pipeline as well as an rtspsink element to do
a rtsp record to a remote "rtsp proxy" instance that receives the ts and hands
it over to n remote rtsp clients.
to prevent unnecessary uploading of the ts payload, the "proxy" does a cond
wait in the media-configure callback until a client is actually connected and
ready to receive the data. a leaking queue in front of the rtspsink element
drops buffers while the upload is stalled.
but this only works if the first remote client connects within just a few
seconds, otherwise the pts have advanced too far for the rtsp
payloader/depayloader to cope with.
an additional tsparse element on the sender side was also inefficient.

what i don't like either about this is the fact that delaying the OK response
will ever only work at the beginning of the transfer and at the cost of raising
the tcp timeout to a very high value which will make it hard to detect other
tcp errors which may occur. neither is it going to allow "pausing" the transfer
again if later on the proxy loses all clients.

currently, i've solved this with a tacky unreliable solution where the sender
writes the ts to a tcpclientsink with a max-lateness property of 1s and the
proxy only reads from the socket as soon as clients are present and 0-rebases
the timestamps.

imho ideally for users' convenience would be, if pausing the media-pipeline of
the proxy (the instance that the stream is transferred TO) would cause the
sender's (the instance that RTSP RECORD stream originates from) rtspsink
element to block.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.