Good to know - I hadn't realized you'd picked up the patch. I should
have checked before posting.
Colin Caughie
Chief Software Architect
(509) 232-5261 ext 5914
What is heroic customer service?
<http://www.openeye.net/heroic-customer-service/>
** NOTICE **
The infor
Are you a) using interleaved mode and b) not processing one or more of
the streams in the session (e.g. throwing away an audio stream)?
If so, it could be the issue I reported here:
http://lists.live555.com/pipermail/live-devel/2013-April/016796.html
From: live-devel-boun...@ns.live555.com
would indicate that it is (decoding would fail otherwise), so perhaps
your problem is elsewhere?
Colin Caughie
Chief Software Architect
(509) 232-5261 ext 5914
What is heroic customer service?
<http://www.openeye.net/heroic-customer-service/>
** NOTICE **
The information contain
I concur; IP cameras are supporting higher and higher resolutions, and their
maximum encoded frame size (particularly for I-frames) naturally increases in
proportion. This can be mitigated by using H.264 slices but not many of them
seem to do so.
That’s not necessarily a reason to increase t
Thanks - in the meantime the change will be getting plenty of testing
here; I'll let you know if we experience any problems with it.
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson
Sent: Monday, April 01, 2013 9:47 PM
To: LIVE555 St
Thanks for the reply. I actually made that change about a year ago; I
was aware that the code was already calculating presentation time for
the purpose of synchronization, but for some reason I thought it was
just a relative presentation time, not an absolute one that accurately
reflected the time
My apologies, I accidentally left in an unused variable declaration that
I was using for debug purposes. Amended patch attached.
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Colin Caughie
Sent: Monday, April 01, 2013 4:46 PM
To: live-de
When an application is receiving data on some but not all of the streams
in an interleaved RTSP session (i.e. it isn't calling getNextFrame() for
some of the streams), the streams that are not being received consume an
enormous amount of CPU cycles compared to the streams that are being
processed.
The attached patch allows access to the last received sender report RTP
timestamp, making it possible to get the full NTP/RTP time mapping
currently in effect (since it was already possible to get the last
received NTP timestamp).
This information can be used to calculate the wallclock timestam
