RTSP Client sometimes doesn't send video (stream 0) packets to the client

Jeff Shanab jshanab at jfs-tech.com
Thu Mar 11 14:42:15 UTC 2021


I deal with a large amount of security cameras of different brands.

Just an FYI....
60 seconds and GET_PARAMETER are the default and work 90+% of the time.
The Setup reply will tell you if it is not default but is there for default
also, depends on brand. end of session header "timeout=60"

I have seen cameras that
1) cannot handle GET_PARAMETER in any transport (RED Vision)
2) must have OPTIONS or SET_PARAMETER instead
3) use rtcp, the rest are ignored. (I thought the timeout=nn told me which
but it is inconsistent)

The behaviour seems to vary with transport
1) rtsp-over-http.(2 sockets) All bets are off, every mfg interprets the
vague combination of the Apple Quicktime Spec differently.
2) rtsp-over-tcp.(1 socket) Usually GET_PARAMETER is universally accepted
here and is all that is needed.
3) rtsp/rtp/udp (up to 7 sockets) GET_PARAMETER for main session but some
must have rtcp receiver reports per session or they disconnect,

Patterns I see are
   if disconnect in seconds, rtcp issue
   if right on the 30 second, 1 minutes or 2 minute then
GET_PARAMETER/OPTIONS/SET_PARAMETER (OPTIONS on vary old cameras, otherwise
OPTIONS tells you if it supports GET_PARAMETER

Wireshark is your friend.




On Thu, Mar 11, 2021 at 9:22 AM Thornton, Keith <keith.thornton at zeiss.com>
wrote:

> Hi,
> that may be because the server is not receiving the keep alive timer from
> the client. If you have a wireshark log look to see if the client sends a
> GET_PARAMETER once a minute (If you haven't changed the keep alive timeout).
> Gruesse
>
> -----Ursprüngliche Nachricht-----
> Von: gstreamer-devel <gstreamer-devel-bounces at lists.freedesktop.org> Im
> Auftrag von renjith.t
> Gesendet: Donnerstag, 11. März 2021 14:10
> An: gstreamer-devel at lists.freedesktop.org
> Betreff: Re: RTSP Client sometimes doesn't send video (stream 0) packets
> to the client
>
> Hi,
>
> I have actually gone through the session media files.
>
> What I found is that
> -> gstreamer rtsp server is closing the transport for the stream 0 it is
> -> done from "update_transport" method in rtsp-stream.c info debug
> -> printed is "removing TCP 192.168.111.78" where 111.78 was the
> client where video was not displayed
>
> so it is clear that gstreamer is explicitly closing the transport.
>
>
>
>
>
> --
> Sent from:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgstreamer-devel.966125.n4.nabble.com%2F&data=04%7C01%7C%7C6e975d97adaa4a9d361508d8e4981c9b%7C28042244bb514cd680347776fa3703e8%7C1%7C1%7C637510689266574710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jP9RcoouYXOZf1m1UAiUqAEuSn8TBvoy%2FpiGpFN%2BTkc%3D&reserved=0
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fgstreamer-devel&data=04%7C01%7C%7C6e975d97adaa4a9d361508d8e4981c9b%7C28042244bb514cd680347776fa3703e8%7C1%7C1%7C637510689266574710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qscZFcyt5nNK836xWaQVbioQcpbQ9OyCAZPiGS1S6UQ%3D&reserved=0
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210311/c4b507a7/attachment-0001.htm>


More information about the gstreamer-devel mailing list