gst-rtsp-server regression: Seeking broken when protocol is TCP.
With 1.14.4, I've observed that, for a non-live source, seeking from an rtsp client (using gstrtspsrc) to an rtsp server works fine with UDP, but is broken for TCP...it is essentially a no-op.
I observer that when setting TCP as the transport in gstrtspsrc, then performing a seek, the SDP in the response to the PLAY comand that follows the PAUSE has an incorrect range value:
... LOG rtspsrc gstrtspsrc.c:8732:dump_key_value: key: 'Range', value: 'npt=now-44.4033'
If I understand correctly, a non-live stream should never use the 'now' constant. For example, in: https://tools.ietf.org/id/draft-ietf-mmusic-rfc2326bis-33.html#rfc.section.4.5:
The special constant "now" is defined as the current instant of a live event.
It MAY only be used for live events, and MUST NOT be used for on-demand (i.e.,
non-live) content.
By simply changing the transport in the gstrtspsrc to UDP, all is well:
... LOG rtspsrc gstrtspsrc.c:8732:dump_key_value: key: 'Range', value: 'npt=16.8301-44.4033'
I believe the source of the problem is gst-rtsp-server, rtsp-stream.c::gst_rtsp_stream_query_position(...). For TCP, the function fails to determine the current position of the stream. In earlier releases (at last in 1.12.0), when the protocol was not UDP, the stream position was determined by querying the sink found in GstRTsPStream->priv->appsink[0]. Patching the 1.14.4 codebase to do likewise fixes the issue, but I doubt that is the right thing to do, as there there seems to be an entirely new mechanism in place, and it must have been put there for some reason (:-).
This is possibly related to bug (#797195).