Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

live RTSP File, RTMP Streamer configuration that worked in 5.2 and earlier, generally not working in 5.3


I have been using versions for a while, and am not able to upgrade to 5.3 because live Wowza based RTSP File, with RTMP Streamer does not bring up video 19 times out of 20. I have tried different provider types and other things that were sometimes useful in prior versions, but none work now.

Trying with your Wizard, it only works on rare occasion, although with 5.2 it always works.

File:
rtsp://root:moo2poo@rmt-501-00408ca5b858.ddns.rmcentral.net:18130/axis-media/media.amp

Streamer:
rtmp://rmtproxy-000180786ADF.ddns.rmcentral.net:1936/rtplive

The video is being streamed through the current version of Wowza Pro 2.x.

6 Community Answers

JW Player

User  
0 rated :

Same problem with 5.3!! I had to drop the use of the player, since I didn't know that the earlier ones worked. I just tried 5.2 and you are right that it works fine by 5.3 only worked once or twice out of dozens of tries.

Thanks for the mention of 5.2, since i didn't want to stay with the other player I was using.

I really hope they get this fixed for 5.3. There are some great new features in 5.3. However, being part of a large news organization, we need live support as well.

Pablo

JW Player Support Agent  
0 rated :

@Andrew -

This issue is related to a new feature added in 5.3, which attempts to connect to both RTMP (port 1935) and RTMPT (port 80). The expected behavior is to connect to the first available port, and discard the other one. What’s happening in this configuration is that for some reason the connection to port 80 (RTMPT) results in the server sending back an unexpected response to the player (“NetConnection.Connect.Rejected”). This generates a player error, which stops the stream in its tracks.

I’ve created a ticket to handle this scenario in a more graceful way:

http://developer.longtailvideo.com/trac/ticket/1151

In the meantime, you might be able to circumvent the issue by blocking all connections over port 80 on your Wowza server.

JW Player

User  
0 rated :

Hi!
I am begiiner.
how can I "In the meantime, you might be able to circumvent the issue by blocking all connections over port 80 on your Wowza server.".? in my server run iis and many application on port 80

JeroenW

JW Player Support Agent  
0 rated :

Can you try this again with the latest build from the player? You can download it here:

http://developer.longtailvideo.com/trac/browser/trunk/fl5

The RTMPT logic has been simplified a lot; tunneling now kicks in only when after 3 seconds the regular connection still hasn’t responded. This used to be a race with 500ms delay for the tunneled connection.

JW Player

User  
0 rated :

@JeroenW:
I'm sorry, but in my opinion this is not the best solution, because we are using the player for a live stream TV, so the user with firewall issues will wait app. 5 seconds till he gets his content....and I'm afraid he won't wait. Of course I can play directly the rtmpt stream, but this is uncomfortable and slow for the users, that could play it through rtmp.

BTW. we are using Wowza streaming servers and you can specify even other ports to be listening on (for example 443) - and you may use it instead of port 80 for rtmpt connection, when you have there also running an apache on the port 80....

JeroenW

JW Player Support Agent  
0 rated :

Well, in my opinion it is the best solution. Users behind firewalls issues are probably much used to video being slow (or not working at all); the 3s delay for the tunneling to kick in should not matter that much. At the same time, people that are not behind firewalls will not have a degraded experience and the server won’t get hit twice (two downsides of the previous solution).

Note that port assignments are not caught by the tunneling logic. Hardcoded port numbers do not break anymore.

This question has received the maximum number of answers.