Hello Ross,
I am working with datagrams more then 9 years, so I know what it is and how
this works, don't know why you are so squishy.
I am using RTSP server based on Live555 (H265VideoRTPSink) to send data frames,
as you see intra frames are quite large (about 230Kb) and inter about 90Kb.
Live555 RTSP server already split those frames to smaller NAL units, but the
problem is that I can't receive what I have sent even on local PC using Live555
RTSP client example.
If we compare with VLC - it can receive all frames correctly in this setup, so
that's why I am asking you is this is possible to tune / speedup Live555 RTSP
client somehow.
I have tried to cache frames in this function:
DummySink::afterGettingFrame but this is not helping - even if I don't process
frames, I got 10 frames from 15, so definitely something is not ok.
Receiving buffer size increasing to 2048 helps a lot, but anyway if there are
some tricks / tunes in code that I can use in Live555 RTSP client - could you
please share this info?
Thank you in advance,
Best regards,
-----------------------------------------
Victor Vitkovskiy
Senior software developer
mailto: victor.vitkovs...@mirasys.com
www.mirasys.com
-----Original Message-----
From: live-devel <live-devel-boun...@us.live555.com> On Behalf Of Ross Finlayson
Sent: Thursday, 10 March 2022 18:37
To: LIVE555 Streaming Media - development & use <live-de...@us.live555.com>
Subject: Re: [Live-devel] [Mirasys] Live555 RTSP server questions
EXTERNAL
Congratulations - you’ve discovered datagrams! They sometimes get lost.
You can try to (1) reduce the rate at which datagrams get lost, and/or (2)
reduce the *effect* of a datagram getting lost.
For (1):
- Do you have one or more middleboxes - somewhere between your server
and client - that might be dropping packets?
- You could try increasing the OS’s internal buffer size for the
transmitting socket (for the server) and/or the receiving socket (for the
client). By default, this is set to 50 kBytes for each socket - which is
usually enough. However, you could try increasing it. (grep
“increaseSendBufferTo” and “increaseReceiverBufferTo” in the code.)
For (2):
- You could reconfigure your encoder to decrease the *size* of your
H.265 NAL units (so that they will fit in fewer RTP packets, making it less
likely that the loss of a single RTP packet will cause the whole NAL unit to be
unusable). I.e., you could encode each key frame as a series of ‘slice’ NAL
units, instead of just one (ridiculously large) NAL unit.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
