Hello Ross,
I am using live555 example of RTSP client to get H265 stream from live555 RTSP
server.
This works ok, but I have found that when I use RTP over UDP even in Release
mode I get 10 frames from 15:
video/H265: Received 242463 bytes. Presentation time: 1646927520.711646
NPT: 6.914277
video/H265: Received 95993 bytes. Presentation time: 1646927520.787290
NPT: 6.989921
video/H265: Received 92240 bytes. Presentation time: 1646927520.938423
NPT: 7.141053
video/H265: Received 90951 bytes. Presentation time: 1646927521.014823
NPT: 7.217453
video/H265: Received 89245 bytes. Presentation time: 1646927521.170223
NPT: 7.372854
video/H265: Received 88764 bytes. Presentation time: 1646927521.248545
NPT: 7.451175
video/H265: Received 88492 bytes. Presentation time: 1646927521.404267
NPT: 7.606898
video/H265: Received 89281 bytes. Presentation time: 1646927521.482667
NPT: 7.685297
video/H265: Received 89489 bytes. Presentation time: 1646927521.636699
NPT: 7.839329
video/H265: Received 89550 bytes. Presentation time: 1646927521.714032
NPT: 7.916662
video/H265: Received 242796 bytes. Presentation time: 1646927521.868298
NPT: 8.070929
video/H265: Received 96175 bytes. Presentation time: 1646927521.946698
NPT: 8.149328
video/H265: Received 90630 bytes. Presentation time: 1646927522.099830
NPT: 8.302460
video/H265: Received 90530 bytes. Presentation time: 1646927522.177307
NPT: 8.379937
video/H265: Received 90730 bytes. Presentation time: 1646927522.332640
NPT: 8.535270
video/H265: Received 90532 bytes. Presentation time: 1646927522.412006
NPT: 8.614636
video/H265: Received 90030 bytes. Presentation time: 1646927522.564294
NPT: 8.766925
video/H265: Received 90314 bytes. Presentation time: 1646927522.718348
NPT: 8.920979
video/H265: Received 90062 bytes. Presentation time: 1646927522.797203
NPT: 8.999834
video/H265: Received 89691 bytes. Presentation time: 1646927522.950047
NPT: 9.152678
But when I switch to RTP over RTSP (TCP mode) I get all 15 frames from 15:
video/H265: Received 241897 bytes. Presentation time: 1646927716.943881
NPT: 1.151394
video/H265: Received 95645 bytes. Presentation time: 1646927717.021403
NPT: 1.228916
video/H265: Received 93541 bytes. Presentation time: 1646927717.097614
NPT: 1.305127
video/H265: Received 91154 bytes. Presentation time: 1646927717.174025
NPT: 1.381538
video/H265: Received 89872 bytes. Presentation time: 1646927717.249758
NPT: 1.457271
video/H265: Received 89961 bytes. Presentation time: 1646927717.326313
NPT: 1.533826
video/H265: Received 90606 bytes. Presentation time: 1646927717.402557
NPT: 1.610070
video/H265: Received 89637 bytes. Presentation time: 1646927717.478557
NPT: 1.686070
video/H265: Received 89330 bytes. Presentation time: 1646927717.555268
NPT: 1.762781
video/H265: Received 88263 bytes. Presentation time: 1646927717.632256
NPT: 1.839769
video/H265: Received 89523 bytes. Presentation time: 1646927717.709194
NPT: 1.916707
video/H265: Received 89499 bytes. Presentation time: 1646927717.787849
NPT: 1.995362
video/H265: Received 88963 bytes. Presentation time: 1646927717.863160
NPT: 2.070673
video/H265: Received 89193 bytes. Presentation time: 1646927717.938493
NPT: 2.146006
video/H265: Received 90416 bytes. Presentation time: 1646927718.014948
NPT: 2.222461
video/H265: Received 242463 bytes. Presentation time: 1646927718.092470
NPT: 2.299983
video/H265: Received 95993 bytes. Presentation time: 1646927718.170503
NPT: 2.378016
video/H265: Received 94709 bytes. Presentation time: 1646927718.248880
NPT: 2.456393
video/H265: Received 92240 bytes. Presentation time: 1646927718.324535
NPT: 2.532048
video/H265: Received 90951 bytes. Presentation time: 1646927718.401590
NPT: 2.609103
video/H265: Received 90715 bytes. Presentation time: 1646927718.477990
NPT: 2.685503
video/H265: Received 89245 bytes. Presentation time: 1646927718.553467
NPT: 2.760980
video/H265: Received 88764 bytes. Presentation time: 1646927718.628944
NPT: 2.836457
video/H265: Received 88091 bytes. Presentation time: 1646927718.707610
NPT: 2.915123
video/H265: Received 88492 bytes. Presentation time: 1646927718.784921
NPT: 2.992434
video/H265: Received 89281 bytes. Presentation time: 1646927718.860587
NPT: 3.068100
video/H265: Received 89841 bytes. Presentation time: 1646927718.937520
NPT: 3.145033
video/H265: Received 89489 bytes. Presentation time: 1646927719.016420
NPT: 3.223933
video/H265: Received 89550 bytes. Presentation time: 1646927719.093086
NPT: 3.300599
video/H265: Received 89300 bytes. Presentation time: 1646927719.169330
NPT: 3.376843
So, it seems that RTSP client can't handle such stream correctly and part of
frames are skipped.
Is there any way to speed up RTSP client or use some cache to prevent frame
skipping in UDP mode?
Currently I use DummySink as in RTSP client example that use afterGettingFrame
and fSource->getNextFrame to get next frame.
I look forward to your answer,
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: Monday, 7 February 2022 12:20
To: LIVE555 Streaming Media - development & use <live-de...@us.live555.com>
Subject: Re: [Live-devel] [Mirasys] Live555 RTSP server questions
EXTERNAL
> On Feb 7, 2022, at 11:04 PM, Victor Vitkovskiy
> <victor.vitkovs...@mirasys.com> wrote:
>
> Hello Ross,
>
> Actually, we have a requirement to support at least some secured streaming
> variant, so if we can use RTSP over TLS it will be good even if HTTPS is not
> supported.
> Could you please advise me how I can use this TLS?
If you want RTSP-over-TLS, but *not* SRTP, call:
setTLSState(<certFileName>, <privKeyFileName>, False); on your
“RTSPServer” object, where <certFileName> is the (string) pathname of a
certificate file, and <privKeyFileName> is the (string) pathname of a private
key file - both in PEM format. In this case, your server will need to be be
running on port 322, otherwise the LIVE555 RTSP client implementation will not
know that it needs to connect to the server using TLS.
If you want RTSP-over-TLS, *and* SRTP, call:
setTLSState(<certFileName>, <privKeyFileName>, True); on your
“RTSPServer” object. In this case, your server can be running on whatever port
number you want; the URL (beginning with “rtsps://“) will tell the client that
it needs to connect to the server using TLS.
Note that you don’t need to do *anything* to your client; it gets all of the
information it needs from the stream’s URL, and from the server.
(Of course, all of this requires OpenSSL, so will *not* work if you’re
compiling with “-DNO_OPENSSL=1”.)
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
