Note that "GenericMediaServer::lookupServerMediaSession” is part of the library
code, and thus is not meant to be modified. Instead, you should subclass
“RTSPServer”, and reimplement the virtual function “lookupServerMediaSession” in
your subclass. (This is what we did for the “DynamicRTSPServer” code in the
“mediaServer” directory.)
Yes, I intent to use live555 library by standard "extending" way. I have
already extend "RTSPServer" class to redefine my
"lookupServerMediaSession" method, if I didn't express it clearly.
But perhaps we should step back and ask why you want to block within your
implementation of “lookupServerMediaSession”? What are you trying to do here?
Since I want to use the library to build a live/playback streaming
server with database and other third-party SDK into it. When handling
"lookupServerMediaSession", I may 1) query the database 2) call some
functions in third-party SDK to get video stream (which may use class
"DeviceSource" later). And I can't assume operation 1 and 2 will not
block (And I think even 100 ms block is not tolerant), since database
query may slow down because of network conditions, and third-party SDK's
non-blocking can't be counted on.
I once wanted to put these operations after RTSP "PLAY" succeeds, but
when errors occur when doing my stream setup stuff, I lose the chance to
response with an error code in RTSP protocol, such as "404 File Not Found".
Yes. Unfortunately, the “lookupServerMediaSession” function was meant to be
synchronous, so the only way that I can see for it to ‘block’ (handling events)
within its implementation is to (recursively) call “doEventLoop()” with a
'watch variable' parameter. This does have the problem that you noted - that
if there are subsequent calls to “lookupServerMediaSession” within this event
loop, then handling will be LIFO - but I don’t see any alternative.
And now I still have a possible option: implementing a event-pool
"TaskScheduler". But I worry whether this is feasible, since the whole
library is designed basing on event-driven with one thread. What's your
advice to this idea, or is there any pioneer? (And if event pool is
finally feasible, using Boost.Asio to accomplish the task may work.)
Mit Shan.
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
