You have inadvertently pointed out something we missed and that is how
you *intended* the server should force a shutdown of an active session
or a live feed. We had been simply destroying the RTSPClientSession
which is what happens when a TEARDOWN message has been received. And
this is how I discovered the aforementioned problem.
By back tracing to see how afterPlayStreamState() could have been called
I see that we should have been calling handleClosure() on each of the
FramedSources, that would cause the fNoFramesLeft flag in
MultiFramedRTPSink to be set to true and cause the subsession to end, as
you intended. I will modify our code to do this when the server is
forcing shutdown of a session.
I still believe that a BYE message should be sent from the server when
the client initiates the session ending via a TEARDOWN (or other such)
message.
Matt S.
Ross Finlayson wrote:
I'm pretty sure that this would happen with unmodified code, just see
if your bye handler is called in OpenRTSP after sending or a teardown
message while the source is still playing.
It is, *provided that* the original source file does not have a known
duration. When streaming from a live source, or from a file for which
the server does not know the duration, the server sends a RTCP "BYE"
packet when the input source ends.
However, when streaming from a file for which the server knows the
file's duration (currently, MP3, .MPG, .TS and .AVI files), the server
*does not* send a RTCP "BYE" packet when it reaches the end of the
file. The reason for this is to keep the stream alive, and therefore
allow the client - if it desires - to continue playing the file, by
seeking back within it and replaying from an earlier time. Because -
in this case - the client was told the stream's duration beforehand,
it doesn't need to see a RTCP "BYE" in order to know when it ends.
Note the code for the function "afterPlayingStreamState()" in
"liveMedia/OnDemandServerMediaSubsession.cpp".
And yes, I've tested this on the installed code.
If you suspect a bug in the code, then please test this using the
original, released code; not your modifications to the code.
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
