When Wowza is streaming (not a progressive download), the NetStream.Play.Stop command is being issued when the server is finished sending data. In other words, when the server determines that the EOF has been reached, NetStream.Play.Stop is issued to the Flash client.
When streaming, this is problematic because EOF coincides with the buffer limit.
For example, if our video is 3 minutes long and we have manually set the buffer to “30” via:
myStream.setBufferTime(30);
… then, when the video reaches 2:30 the NetStream.Play.Stop command is sent. If we’ve attached methods to “listen” to NetStream Events, such as:
myStream = new NetStream(netConn);
myStream.onStatus = function(objStatus){
var temp = handleFLVevents(objStatus);
};
function handleFLVevents(infoObject){
if(infoObject['code'] == "NetStream.Play.Stop"){
stopMovie();
}
}
function stopMovie(){
doSomethingElse();
EG_getNextMovie();
}
… You can see that the video gets cut short by the buffer amount (30 seconds). In other words, at 2:30 the player will stop the movie and try to get another one.
This behaviour is not in accordance with the idea for the command. This command is suppose to be used for when the actual video is stopped – not for when the server has no more data to send.
The problem with having the server (Wowza) send the command is that, under certain circumstances, the Flash plugin itself also issues this command to the NetStream Object whenever the video is stopped due to network connection issues, or other complications derived from seeking or multiple play / pause requests.
There seems to be no way to distinguish between when Wowza is issuing the command due to EOF, or when an actual request is made to stop the video.
There needs to be a separation between EOF data transmission and the visual end of the video being played. It is my belief that NetStream.Play.Stop is to be used for the visual video reaching the end of the video and not as some kind of “data marker” indicating the the server has stopped sending data.
