OK, try one more thing:
Move the call to:
Medium::close(transportStream);
after the call to:
Medium::close(session);
but before the call to:
Medium::close(rtspClient);
If this doesn’t work, then just don’t call "Medium::close(transportStream)” at
all. But I don’t care; y
Try moving the call to
Medium::close(transportStream);
after the call to
Medium::close(rtspClient);
Then the fInputSource variable is not valid in
FramedFilter::doStopGettingFrames and the process crashes in the
MPEG2TransportStreamFromESSource destructor.
On 11.08.2021 14:23
> On Aug 11, 2021, at 4:15 AM, Andrey Shvyrkin wrote:
>
> Thanks for answers.
>
> I'm using
> EventTrigger to exit the event loop at any point in time by changing the
> value of the watch variable. And then I use the previously presented code to
> close the session and free memory. In theo
Thanks for answers.
I'm using/EventTrigger/ to exit the event loop at any point in time by
changing the value of the watch variable. And then I use the previously
presented code to close the session and free memory. In theory, I should free
the memory used by the/MPEG2TransportStreamFromESSou
“live555HLSProxy” is intended to be run as an application - i.e., in its own
process - so that when the application (process) ends, any extra memory that it
has allocated is automatically freed. Is there any reason why you have to
embed this code in some other (longer-lasting) application? I.e
> On Jul 6, 2020, at 11:33 AM, Serge via live-devel
> wrote:
>
> The camera source definitely supports TCP streams, and when I change line 169
> from "continueAfterClientCreation1(rtspClient);" to
> "continueAfterClientCreation0(rtspClient, streamUsingTCP);" this does provide
> a TCP stream
--- Begin Message ---
Thank you for your reply.
No, the ?-t? option (stream using RTP/RTCP-over-TCP) is working just
fine - but it depends upon the RTSP server supporting it. Perhaps
your RTSP server (IP camera) doesn?t support it?
You can check this by changing ?RTSP_CLIENT_VERBOSITY_LEVEL?
> On Jul 1, 2020, at 5:13 PM, Serge via live-devel
> wrote:
>
> I am a little late to the party regarding the feedback on the HLSProxy, but I
> have been looking at this tool recently as a means of buffering a video in
> segments before processing parts of it for a project. I have come acros
