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

[Ross Finlayson]

> So, to check my understanding and to document for anyone who ever feels brave enough to do this...
> 
> For each X:{OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, GET_PARAMETER, TEARDOWN}, we would need to:

Not necessarily.  The LIVE555 event loop thread code can take care of a lot of the fine-grain details of the RTSP protocol.  In particular, it can be smart enough to:
	- know that “DESCRIBE” is followed by one or “SETUP”s (one for each track), followed by a “PLAY”
	- know to automatically start (and keep sending) a “GET_PARAMETER” to signal client liveness (for dumb servers that don’t listen to RTCP).
In that case, the application thread(s) (i.e., the rest of VLC) need only signal the LIVE555 event loop thread to:
	- open and start playing a stream
	- pause a stream
	- resume a stream
	- teardown a stream
so you’ve got only 4 message types (between the rest-of-VLC thread(s) and the LIVE555 event loop thread instead of 7.

(Also, feel free to define and implement whatever thread-safe asynchronous messaging mechanism you want if you’re not happy with the “triggerEvent()” mechanism that LIVE555 provides.)


> Then we'd need a new thread calling doEventLoop(), with a watch variable only set for shutdown.

Exactly.


> As you pointed out before, the GET_PARAMETER keepalives could be done as a scheduleDelayedTask(), so that would save one in exchange…

Although, as I noted above, you can probably save more by offloading some of the RTSP protocol logic to the LIVE555 event loop thread.


> Because as Felix points out there can be multiple active RTSP streams

As I noted in my earlier message, the (single-threaded) LIVE555 event loop can do this as well.


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/b001c060/attachment.html>