> By the way, I think there might be a bug in the handling of the
> periodic liveness commands:
> If an OPTIONS response is never received,
> ProxyRTSPClient::continueAfterLivenessCommand is never called, and the
> next liveness command will never be scheduled.
No, the periodic ‘liveness’ commands
> OK, I still can’t quite figure out what’s going wrong here, but I think I’m
> getting closer. I’ve just installed a new version (2016.03.16) of the code
> that adds some extra checking, and some more ‘internal error’ debugging
> fprintf()s. > Please run this new version, and let me know if yo
The (64-bit) "presentation time” values are not passed directly from the server
to the client; instead, they are transferred implicitly, using the (32-bit) RTP
timestamps in each RTP packet, plus periodic RTCP packets that provide the
mapping from RTP timestamp to “presentation time”. This is a
Thanks for quick response.
Yes, there should be 11. I have tested a few values and I left last
one by mistake. I am using camera so next frame never arrives earlier,
so this value doesn't matter.
I changed my code by adding non valid values
fPresentationTime.tv_sec = 1;
fPresent
>> I am using testOnDemandRTSPServer example code from live555. I have wrote my
>> implementation of DeviceSource class. I have set presentation time properly:
>>
>> gettimeofday(&fPresentationTime, NULL);
>> fDurationInMicroseconds = 110;
>
> That’s your problem. You’re telling the server
> I am using testOnDemandRTSPServer example code from live555. I have wrote my
> implementation of DeviceSource class. I have set presentation time properly:
>
> gettimeofday(&fPresentationTime, NULL);
> fDurationInMicroseconds = 110;
That’s your problem. You’re telling the server to wait 1
Hi all,*
*
*Problem:*
In my case, bit stream coming from h264 encoder which is feed by live
camera. Bitstream is sending by live555 library using RTSP protocol.
RTSP packets are received by one of rtsp client like vlc player( the
most important), totem player, mplayer. I need to know how to s
