Video Freezes after 4 seek call with Streamlock enabled (RTMPS Streaming)

Wowza Streaming Engine
1

We have our own flash player working perfectly with the Wowza server so far. Recently we enabled Streamlock (RTMPS streaming instead of RTMP) as instructed by your Stremlock document. We have been observing a unique video seek issue with RTMPS streaming. The player seamlessly allows first four seek post which it hangs / freezes.

This issue doesn’t occur if we use RTMP but due to our security need we have to use Wowza Streamlock. The hang (video freeze) happens exactly after 4 seek, once the video is frozen and if you pause and un-pause the video starts but no further seek is allowed. In addition after the video freezes if we stop the video and restart, it plays and allows 4 seek and then the problem repeats.

Thanks in advance.

2

What player are you using? It is recommended to set the NetStream.proxyType to “best”, (the default is “none”), but this is not configurable in some players. When NetStream.proxyType is set to default “none” RTMPS is actually handled as RTMPTS (tunnelling), which is probably why you are seeing less stable streaming.

At present this NetStream.proxyType is not configurable in JW Player but it is supported in Flowplayer. We think the next point release of JW Player will add this feature.

Richarde

3

Right, NetConnection.proxyType, my confusion.

Do you see log messages that say “insufficient bandwidth” in your access log corresponding to this problem? This refers to client-side bandwidth, the player is not able to keep up with rapid, repeated seek commands.

Richard

4

But the problem was regarding your Flash client? Flash does not support RTSP. I am confused. Which RTSP client are you testing with?

So, you are saying that RTSP does not work as well if StreamLock is enabled? It should not be affected.

What about RTMPS with StreamLock?

Richard

5

Do you see the same behavior with the Wowza Manager’s test RTMP player? If not, then you will want to debug your player, and IMediaStreamActionNotify3.onSeek() might help you. Log each the onSeek location of each seek. The location is the timecode the player has requested.

If you do see this with the Wowza test player as well, I will try to replicate on an EC2 server with StreamLock. And if you could provide the logs (to ticket #92027) from an isolated test: Startup Wowza on server with StreamLock enabled, and seek 5 times with your player, then seek 5 times with Wowza test player using.

Richard

6

Hi,

The test RTMP player in the Wowza Manager works with RTMPS. Let me know what you see using that player.

Richard

7

Thanks for updating this thread and posting a solution. Glad to hear you sorted this out.

Regards,

Salvadore

8

Thanks. We are using our own Flash player and have set NetConnect.proxyType as Best, we don’t see option of proxy type in NetStream class.

9

No I trust their is no BW issue. What surprises us is that everything works perfectly if we disable stream lock and use typical RTMP streaming. We see the issue only with RTSP and that too very predictably after four video random seek call. Also we don’t make rapid seek calls, even if call is made with gap of minutes same issue is seen.

10

Sorry I meant RTMPS, it was typo. What we have observed that when we enable Sreamlock we are advised to use RTMPS and when using it along with streamlock feature we see the seek / video freeze issue.

11

Sorry for delay in reply. We can confirm testing with 5 separate flash player all ending up creating same issue when using RTMPS streaming. The only difference was number of seek varied, in some player the video freezes after 2 seek and some take 6 seek before video freezes. Please note RTMP only streaming with Wowza and our player works fine. Do you have any (wowza) player where we can test RTMPS streaming with stream lock enabled. Thanks.

12

Hi,

Did you ever find a fix for this. I’m using jPlayer and having the same issue with streaming audio. 4 seeks and it freezes. Appreciate if you would help if you did find a fix.

Thanks

13

Ignore the last message, I managed to fix it with the fix below.

What player are you using? It is recommended to set the NetStream.proxyType to “best”, (the default is “none”), but this is not configurable in some players. When NetStream.proxyType is set to default “none” RTMPS is actually handled as RTMPTS (tunnelling), which is probably why you are seeing less stable streaming.

At present this NetStream.proxyType is not configurable in JW Player but it is supported in Flowplayer. We think the next point release of JW Player will add this feature.

Richarde