ading, but this is my
understanding how tls encoding is specified.
Thanks again,
Johannes
On Fri, 2 Dec 2022 11:04:12 +1300
Ross Finlayson wrote:
> > On Dec 2, 2022, at 9:41 AM, Gajdosik Johannes
> > wrote:
> >
> > Hello Ross,
> > I am sorry, it is not fixed y
fCtx = 0x5563a370, fCon = 0x55659170}, fClient =
@0x5562d760}, fPOSTSocketTLS = { = {
_vptr.TLSState = 0x5560c620 , isNeeded
= 1 '\001', fHasBeenSetup = 0 '\000', fCtx = 0x0, fCon = 0x0},
fClient = @0x5562d760}, fInputTLS = 0x5562d930,
Hello Ross,
Now I use the new version live.2022.11.29.tar.gz. And still get the same
SIGSEGV:
gaj@gajdosik /sdb3/JohannesGajdosikPKE/live.2022.11.29/testProgs $ gdb
./openRTSP
GNU gdb (Gentoo 8.3.1 vanilla) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version
I use version live.2022.11.19.tar.gz. Compiled using config.linux-gdb (with -O0
for better debugging)
On the server side I call
rtspServer->setTLSState(PATHNAME_TO_CERTIFICATE_FILE,PATHNAME_TO_PRIVATE_KEY_FILE,False,False);
like in testOnDemandRTSPServer.cpp.
Last 2 parameters False,False
On Wed, 10 Aug 2016 07:28:41 -0700
Ross Finlayson wrote:
> Absolutely not!
>
> LIVE555 programmers should never have to deal with RTP timestamps directly.
> Our software automatically uses RTCP to convert presentation times to RTP
> timestamps (when transmitting) and back to presentation time
Thanks for the LiveMedia Software!
While receiving rtp over rtsp from my liveMedia server implementation, I
receive bad timestamps every time when a new client starts to receive the same
stream. I fixed this behaviour with the patch below.
This patch also gives me full control over the timestam
On Tue, 9 Aug 2016 12:47:49 -0700
Ross Finlayson wrote:
Thanks for your answer!
> > In my opinion this behaviour is inappropriate, since I use TCP streaming
> > exactly because I never must drop a frame.
>
> This is unrealistic, and impossible if your network stream is exceeding the
> capac
In my application I send rtp streams over rtsp (tcp streaming) because I cannot
afford dropping a single frame.
After some research I found that liveMedia will drop my frames in certain
circumstances, especially when I send big I-Frames.
The code is in RTPInterface::sendDataOverTCP, which will no
