> I downloaded your latest and ran it. The output is below.
> I don’t see much difference between the versions and I couldn’t pin point
> your change diffing the sources.
>
> Am I missing something?
Yes, you didn't upgrade your client application. It's still running version
2012.11.16 of our
> Received a complete PLAY response:
> RTSP/1.0 200 OK
> CSeq: 6
> Session: 872219556
> Range: npt=now-
> RTP-Info:
> url=rtsp://10.0.70.22:554/video1+audio1/trackID=0;seq=35711,url=rtsp://10.0.70.22:554/video1+audio1/trackID=1;seq=62268,url=rtsp://10.0.70.22:554/video1+audio1/events;seq=4796
FYI
> I just got puzzled by seeing the output of the following lines of code that I
> copied and pasted:
>
> sprintf(uSecsStr, "%06u", (unsigned)presentationTime.tv_usec);
> envir() << ".\tPresentation time: " << (unsigned)presentationTime.tv_sec <<
> "." << uSecsStr;
Yes, the "(unsigned)" cast in
22:554/video1+audio1"; audio/PCMU: Received 1024
bytes.Presentation time: -850904333.204102NPT: 127507
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson
Sent: Sunday, January 13, 2013 1:16 PM
To: LIVE555 Streaming Media -
You haven't said specifically how you are using our software. Are you using it
as a RTSP/RTP client? If so, then what is *transmitting* the RTP (& RTCP)
packets? (Does the transmitter also use our software?)
The "tv_sec" value in a presentation time (a "struct timeval") is supposed to
be tre
All,
I am getting a negative value for presentationTime.tv_sec in
MySink::afterGettingFrame.
I absolute value increases (when ignoring the sign)
In the live555's custom sink sample code the timestamps (of type timeval) are
getting casually casted to an unsigned.
Is it save to ignore the sign