> - from the core dumps it's hard to tell which action causes the crash since
> it's an asynchronous event but the stack trace is always the same:
> «
> (gdb) bt
> #0 0x636e456c in ?? ()
> #1 0x08091c89 in FramedSource::afterGetting (source=0x8647d50) at
> FramedSource.cpp:91
> #2 0x080d8825 in
Fixing the handling of this rare issue (a RTCP “RR” being received after a
“BYE” (with the same SSRC)) would be non-trivial, and is not a high priority.
If you want to distinguish between multiple “RTPTransmissionStats” records, you
can do so using the “timeCreated()” and “lastTimeReceived()” fu
FYI, the latest version (2016.03.14) of the “LIVE555 Streaming Media” software
should fix this problem.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailma
> I wanted to ask about the limitation in openRTSP lib na playCommon.cpp file
> about -p parameter.
> Why there is a check that port should be even?
Because of the way that RTP/RTCP is defined (in the relevant IETF standards).
The even-numbered port is used for RTP; the next port number (i.e.,
Hi Ross,
I wanted to ask about the limitation in openRTSP lib na playCommon.cpp
file about -p parameter.
Why there is a check that port should be even?
I.e. 557 will not work on snapshot (there is a check for it in code) but
removing the check in code and recompiling it works without problems.
Hello Ross,
in http://lists.live555.com/pipermail/live-devel/2013-January/016347.html I
described the following scenario: "We have been running for some time a
RTSPServer that acquires video from a live source (with our own DeviceSource)
from which we create 2 or 3 replicas: one for multicast stre
