[vlc-devel] [PATCH] Handle GET_PARAMETER keepalive responses during PAUSE

[Ross Finlayson]

>> If VLC is not waking up periodically to
>> ‘poll’ for this event occurring, then how does it detect it?
[…]
> This is all possible thanks to the ground-breaking cutting-edge technology 
> called The Interrupt.

Yes, of course.  But interrupts are not an OS abstraction, and my question was designed to prompt you to think about how interrupt-driven events (like a mouse click on the ‘play’ button) are implemented in the QT library without polling.  I don’t know (not being familiar with QT), but my guess would be that they’re probably implemented by calling “select()” or “poll()” to wait on a socket - and my point is that, if you wished, you could signal the LIVE555 event loop thread the same way (and, if you did that, you could get rid of your dreaded 10ms poll :-).

It’s worth noting, however, that it will never be possible for VLC to consume 0% CPU during the time that it’s pausing a RTSP stream, *precisely because* it needs to periodically send “GET_PARAMETER” commands (i.e., the original subject of this email thread).

Another thing to keep in mind is that RTSP/RTP clients are supposed to keep sending RTCP “RR” packets even when a stream is paused, and if we’re not in the LIVE555 event loop throughout the time that the stream is paused, then these RTCP packets will not get sent often enough.  (In fact, if you’re not calling “doEventLoop()” at all during the time that the stream is paused, then these RTCP packets won’t be sent at all!)  This is probably not a big deal, because these RTCP packets aren’t needed to tell the server that the client is still alive (the “GET_PARAMETER” commands will do that).  It’s also the case, however that - if you’re not in the LIVE555 event loop during the the time that the stream is paused - RTCP “SR” packets coming from the server won’t be received and processed either.  This could be more serious, because it could conceivably mess up the client’s presentation time computation (and a/v synchronization) after it resumes from the pause.  I’m not sure whether or not this is really a problem, but the fact remains that - to be fully compliant - we should be executing the LIVE555 event loop all the way from the time of the first “PLAY” command, up until the final “TEARDOWN”.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20150625/c608f9d3/attachment.html>