Worth noting that behind their firewall, the VideoPlayer fires a MediaPlayerStateChangeEvent.mediaPlayerStateChangeState event with the state of playbackError
I've managed to get this working by specifying port 80 in the url of the video content, but my question remains. Is this the correct behavior of the VideoPlayer component? Does it try a single port (presumably 443) and fire a MediaPlayerStateChangeEvent.mediaPlayerStateChangeState event with the state of playbackError id it can't connect through that port without failing over to 80 as RTMP or RTMPT?
1 person found this helpful
OSMF's NetLoader attempts RTMP connections in "shotgun" style, you can read the specific details in the NetLoader spec (http://opensource.adobe.com/wiki/display/osmf/NetLoader+Specification), which I think is still accurate. As the spec mentions, if you specify a port, then it will only attempt connecting over that port.
If you wanted to change this behavior, you would need to supply a custom NetConnectionFactory (which does the actual connection logic) to NetLoader. This isn't trivial though, since the default NetConnectionFactory handles not just the port/protocol negotiation, but connection sharing as well.
Thanks for replying. Can you explain what you mean by Shotgun Style?
To quote from the NetLoader Spec you provided a link to:
With rtmp-based resources, the class will immediately create a series of NetConnection attempts. The following ports are used by default: 1935, 443, 80 although if a particular port is specified in the resources, only it will be used. If the protocol specified in the resource is rtmp, it will attempt rtmp,rtmpt and rtmps connections. If rtmpe is specified, it will attempt rtmpe and rtmpte. If rtmps is specified, it will only attempt a connection over rtmps.
However this does not occur. Port 80 is never hit unless specified as the target port within the URL. It appears there is no failing-over occurring at all.
Shotgun style means that all connection attempts are made simultaneously (as opposed to making connection attempts sequentially), and the first to succeed is used, the rest are discarded.
You might be running into the following bug:
If you have any details that aren't in the bug, it'd be great if you could add them.
Yep. That's the one.