FaSTTUBe/GST-Tensordecoder-ov_ep
61
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

rtspconnection: Start CSeq at 1

Browse Source 
RFC 7826 recommends (but does not require) starting at 0,
but at least one known server implementation fails to copy
request sequence numbers <1 into responses due to an
incorrect null check.

The server known to exhibit this behavior is the Parrot
Streaming Server, serving video from their UAV devices.
A fix has been submitted upstream as well:
https://github.com/Parrot-Developers/librtsp/pull/2

The Parrot developers are known to have tested with LibVLC.
In WireShark debugging, LibVLC appears to start with a CSeq
of 2, which is likely why this bug went unnoticed.

This reverts 487595a7d6e2d, which set this to 0 citing the
RFC. The switch to 0 was thus a recent one; it's therefore
possible server implementors relied on the previous
GStreamer client behavior in their tests as well.

Fixes #624.
This commit is contained in:
Eike Hein 2019-06-12 04:45:09 +09:00
parent 2ea98270b4
commit 303f927d70
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
gst-libs/gst/rtsp/gstrtspconnection.c
View File

@ -362,7 +362,8 @@ gst_rtsp_connection_create (const GstRTSPUrl * url, GstRTSPConnection ** conn)
newconn->url = gst_rtsp_url_copy (url);
newconn->timer = g_timer_new ();
newconn->timeout = 60;
newconn->cseq = 0; /* RFC 7826: "it is RECOMMENDED to start at 0." */
newconn->cseq = 1; /* RFC 7826: "it is RECOMMENDED to start at 0.",
but some servers don't copy values <1 due to bugs. */
newconn->remember_session_id = TRUE;