Hello Ross,
I have found an issue, one of subsessions was not added to RTSP server so it
was not freed on RTSP server close and that's why this UsageEnvironment reclaim
failed.
Best regards,
-----------------------------------------
Victor Vitkovskiy
Senior software developer
mailto: victor.vitkovs...@mirasys.com
www.mirasys.com
-----Original Message-----
From: Victor Vitkovskiy
Sent: Friday, 28 January 2022 11:16
To: LIVE555 Streaming Media - development & use <live-de...@us.live555.com>
Subject: RE: [Live-devel] [Mirasys] Live555 RTSP server questions
Hello Ross,
Could you please advise me how to shutdown RTSP server completely and free all
resources used by it?
Code example:
////////////////////
RTSPServer* rtspServer = MirasysRTSPServer::createNew(*env, port, authDB);
if (rtspServer == NULL) {
*env << "Failed to create RTSP server: " << env->getResultMsg() << "\n";
exit(1);
}
// Adding server sessions and subsessions
env->taskScheduler().doEventLoop(&stop); // does not return
// close RTSP server
Medium::close(rtspServer);
// free environment & scheduler
auto res = env->reclaim();
delete scheduler;
////////////////////
But env->reclaim() call returns False, because of this:
Boolean UsageEnvironment::reclaim() {
// We delete ourselves only if we have no remainining state:
if (liveMediaPriv == NULL && groupsockPriv == NULL) {
delete this;
return True;
}
return False;
}
liveMediaPriv is not null, so it is not removed.
Could you please advise me how to make this liveMediaPriv null? What should be
called to do this?
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: Wednesday, 26 January 2022 19:19
To: LIVE555 Streaming Media - development & use <live-de...@us.live555.com>
Subject: Re: [Live-devel] [Mirasys] Live555 RTSP server questions
EXTERNAL
> On Jan 27, 2022, at 2:37 AM, Victor Vitkovskiy
> <victor.vitkovs...@mirasys.com> wrote:
>
> Hello Ross,
>
> So, if I understood correctly, if OutPacketBuffer::maxSize is smaller then
> frame, then all that is more then this value will be lost in any way?
Yes.
> I thought that if frame is bigger then buffer then I need to pass this
> buffer part by part in each doGetNextFrame call using fNumTruncatedBytes
> value to define how much data is still remained to send.
No. “doGetNextFrame()” must deliver (or attempt to deliver) only one frame[*]
at a time. But you can’t deliver a frame larger than “fMaxSize”.
[* ]Strictly speaking, in the case of H.264/H.265 video, this is one "NAL unit”
at a time. If you have a very large H.264/H.265 frame, it is best if you can
configure your encoder to break it up into multiple ’slice’ NAL units, and
deliver one of those at a time.
> But according to your last email this fNumTruncatedBytes parameter is useless
> if upper level components just lose all data that is bigger than
> OutPacketBuffer::maxSize.
“fNumTruncatedBytes” is not completely ‘useless’; it gives information to the
downstream object about how much data was lost. But this data is just that -
lost.
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
