Hi Ross,
I completely understand your position.
I just wanted to clarify the use case here: In our application, the end
user decides when to SETUP and PLAY the stream which is presented to
her/him after the DESCRIBE succeeded. It is also the end user deciding
whenever to TEARDOWN the stream. Usuall
When sending RTSP command from another thread than the event loop (it is
actually unsupported see:
http://www.live555.com/liveMedia/faq.html#threads), the response of the
command might arrive prior the handler callback is registered. When that
happen, the handler will never be called even if the re
RTP timestamps.Would you kindly reconsider exposing
the RTP timestamp in RTPSource? Alternatively, I'd be very open to other
ways of getting the accurate sender media clock if you have any ideas?Kind
regards,Lionel*
On Tue, May 12, 2020 at 4:44 PM Ross Finlayson
wrote:
>
>
>
Hi,
In order to achieve very precise digital audio converter clock
synchronisation between server and client in a project I am currently
working on, I need to access the exact RTP timestamp of the last packet
from my MediaSink so I can precisely estimate the clock differences. Using
presentation t
