"GStreamer" (GNOME Bugzilla)
2015-10-22 12:46:30 UTC
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-***@lists.freedesktop.org
Reporter: ***@opendreambox.org
QA Contact: gstreamer-***@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.
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-***@lists.freedesktop.org
Reporter: ***@opendreambox.org
QA Contact: gstreamer-***@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.
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.