When handling onStreamDestroy for an IMediaStream where isPlay() returns true, is there a way to shut down/disconnect the stream such that the publisher will stop sending video?
I tried looping through the streams and shutting down all with a matching name like this:
List<IMediaStream> streams = mediaStream.getStreams().getStreams();
for (IMediaStream stream : streams) {
if (stream.getName().equals(mediaStream.getName())) {
getLogger().info("[DVS] Closing stream - " + dumpStream(stream));
stream.close();
}
}
Afterward, the log said:
INFO stream stop kGwBRB-msUOWDRgNwvMEyw.sdp -
INFO server comment - [DVS] onStreamDestroy - name: kGwBRB-msUOWDRgNwvMEyw.sdp,
type: live-lowlatency, direction: player
INFO server comment - [DVS] Closing stream - name: kGwBRB-msUOWDRgNwvMEyw.sdp, t
ype: live-lowlatency, direction: source
INFO server comment - [DVS] Closing stream - name: kGwBRB-msUOWDRgNwvMEyw.sdp, t
ype: live-lowlatency, direction: player
INFO stream destroy kGwBRB-msUOWDRgNwvMEyw.sdp -
INFO session disconnect 1041852817 -
However, I continued to get data coming to Wowza from the video source (observed by sniffing traffic), so I guess this isn’t the right way to do it.
If I’m shutting Wowza down, I notice that streaming stops when this is written to the log:
INFO rtsp disconnect 284155326 -
This is maybe a funny way of asking, but is there a path through the API from IMediaStream that will cause the rtsp disconnect?
Thanks,
Eric
Eric,
In this example we try to stop the encoder like this:
sendStreamOnStatusError(stream, "NetStream.Publish.Rejected", "bitrate too high");
stream.getClient().setShutdownClient(true);
Some encoders (FMLE at least) persistently reconnect. It’s obnoxious, but am not sure what else can be done
Richard
Eric,
Looks like it is working according to the logs.
INFO stream unpublish 84YirtWnc0S44F3gzbgsMg.sdp
Instead of Wireshark, look at a player that is playing the stream. See if it stops
Richard
Eric,
There is not any way to shut off an encoder from Wowza.
Richard
If RTMP encoder (that makes a NetConnection to Wowza) you can try to do client.setShutDownClient(true). That might kill ffmpeg. FMLE will just keep trying to reconnect.
Richard
Eric,
I’m not sure what to suggest. I’m sure you have dug through the API doc.
Richard
Hi Richard,
Thanks for the suggestion, but it didn’t seem to do the trick. Maybe what I need is a way to send an RTSP TEARDOWN message from Wowza to the encoder. The stream is originally initiated by the encoder (live555) sending ANNOUNCE, SETUP & PLAY to the media server. I thought I read somewhere that RTSP can be sent either direction, though. If that’s not right, then maybe just a way to shut down the socket.
I also tried shutting down the RTPSession – I feel like I’m shutting stuff down pell-mell:
private void experimentalStop(IMediaStream mediaStream) {
getLogger().info("[DVS] Trying to disconnect stream " + mediaStream.getName());
List<IMediaStream> streams = mediaStream.getStreams().getStreams();
for(IMediaStream stream : streams) {
if(stream.getName().equals(mediaStream.getName())) {
IClient client = stream.getClient();
if (client != null) {
getLogger().info("[DVS] * got IClient to shut down - " + dumpStream(stream));
client.setShutdownClient(true);
}
RTPStream rtpStream = stream.getRTPStream();
if (rtpStream != null) {
getLogger().info("[DVS] * got RTPStream to shut down - " + dumpStream(stream));
rtpStream.getRTPContext().shutdownRTPSession(rtpStream.getSession());
}
getLogger().info("[DVS] * closing stream - " + dumpStream(stream));
stream.close();
}
}
}
Here’s my log output:
INFO stream stop 84YirtWnc0S44F3gzbgsMg.sdp -
INFO server comment - [DVS] onStreamDestroy - name: 4YirtWnc0S44F3gzbgsMg.sdp, type: live-lowlatency, direction: player
INFO server comment - [DVS] Trying to disconnect stream 84YirtWnc0S44F3gzbgsMg.sdp
INFO server comment - [DVS] * got RTPStream to shut down - name: 84YirtWnc0S44F3gzbgsMg.sdp, type: live-lowlatency, direction: source
INFO stream unpublish 84YirtWnc0S44F3gzbgsMg.sdp -
INFO server comment - [DVS] onStreamDestroy - name: 84YirtWnc0S44F3gzbgsMg.sdp, type: live-lowlatency, direction: source
INFO stream destroy 84YirtWnc0S44F3gzbgsMg.sdp -
INFO rtsp disconnect 225687726 -
INFO server comment - [DVS] * closing stream - name: 84YirtWnc0S44F3gzbgsMg.sdp, type: live-lowlatency, direction: source
INFO server comment - [DVS] * got IClient to shut down - name: 84YirtWnc0S44F3gzbgsMg.sdp, type: live-lowlatency, direction: player
INFO server comment - [DVS] * closing stream - name: 84YirtWnc0S44F3gzbgsMg.sdp, type: live-lowlatency, direction: player
INFO stream destroy 84YirtWnc0S44F3gzbgsMg.sdp -
INFO session disconnect 965464950 -
The video is still going to the media server, though (despite the “rtsp disconnect” that I was hoping to get). It’s not that the encoder restarts (like with a new RTSP ANNOUNCE). It just never stops, as I watch with Wireshark.
Any other suggestions?
Thanks,
Eric
Sorry – I guess I’m not communicating well, or understanding your answer.
It’s the data moving from the encoder to the Wowza MS that I’m trying to stop, not from the media server to the player. In fact, the sequence I’m working through starts by closing the player’s browser window and getting an onStreamDestroy in my module.
Once there aren’t any players, I want to shut down the encoder. Since there is an active communication channel between the encoder and media server carrying RTSP/RTP, I’d like to use that existing channel to stop the encoder if possible. Is that a reasonable strategy?
If so, how can it be done? My flailing attempts at closing everything in sight have failed because, although lots of media sever internal objects are getting destroyed, data continues to flow to the server.
Thanks again for your help.
Eric
If there were a kinder, gentler, protocol approved way that would be great, but I believe that closing the socket on Wowza’s end would work for me. Live555 (which we’re using right now) stops streaming when Wowza is stopped, as gcoulbourne reports that ffmpeg does.
The trouble is that I can’t find a way to close the socket using the Wowza API. As I mentioned in my 09-19-2011, 10:57 AM post, I tried closing everything I could get my hands on, including a call to client.setShutDownClient(true), but the socket appeared to stay open since data kept flowing from Live555 to Wowza.
Richard, you mentioned RTMP in connection with the suggestion to call client.setShutDownClient. Is that really only in play with RTMP? If so, that doesn’t help much since I’m doing RTSP/RTP.
Presumably there’s a socket.close() somewhere in the Wowza source code. Is there a way someone with source access could backtrack from there to find a call that that would invoke it that is accessible from the API?
Thanks,
Eric
Is it not possible to close the socket on the Wowza side? I know that ffmpeg dies if Wowza is shut down. Is there a way to kill the publisher, so that the socket will close, and ffmpeg will get the hint?
Hello guys,
it’s 2014 out there, and this problem still persist
EricJS, have you found a solution for that ?