OK, now I understand the problem that you're reporting. (I didn't pay much
attention to it before, because you use an unprofessional email address, and
many of your previous comments have been bogus.)
Yes, the server did have a problem computing the 'current NPT' if it received
more than one c
> But after first call this function the value of mostRecentPresentationTime
> and initialPresentationTime will be reset to zero.
>No you're wrong. Those values get set to zero only when the "RTPSink" object
>is created.
But I see those values get set to zero when the "RTPSink" continue to play
> I was wondering what was the status of SRTP support?
It will happen. When it does, you (and others on this mailing list) will be
the first to know :-)
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-deve
I was wondering what was the status of SRTP support?
And what, if anything, I could do to help?
Kevin Anthony
Software Engineer
Activu Corporation
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-dev
> 2. Seek in that stream.
> Range: clock=20130322T20.000Z-
>
> The response to #2:
> Range: clock=20130322T20Z-20130322T204538Z
>
> 3. And then, after teardown, start up the same stream with the same seek-time.
> PLAY rtsp://192.168.1.103/archive/TVF-01a/ RTSP/1.0
> Range: clock=2013032
Is this intended, or is it somehow server dependent?
I don't know. Please show the complete RTSP protocol exchange for each
case, so I can try to figure out what's happening.
I've attached the protocol exchange for the following example:
1. Start up an archive stream without any ti
Hi Ralf, Ross,
Thanks for the link to the RCF6501 that bring a solution to know the timestamp
of the first RTP packet.
I follow times to times the ONVIF specification
http://www.onvif.org/specs/stream/ONVIF-Streaming-Spec-v210.pdf that also
propose to insert a NTP timestamp (and
