As the Brightcove platform continues to be used as the foundation for new and unique applications, one of the most exciting emerging proposals is for internal communications over a corporate intranet.
The use cases we're starting to see is for large multinationals who have embraced video as a key tool for corporate and client communications, particularily in the finanicial and legal vertical - if a picture says a 1000 words, how many words does a video say?
I'm happy to say that running Brightcove over an intranet is just as straightforward as running it over the internet. This is thanks to the Flash client side runtime that allows the BC platform to adopt the end user's security profile for accessing local resources.
There are some limitations and things to do to get this up and running but nothing that should scare you off to giving it serious consideration for your corporation.
The key to this setup is the use of Remote Assets - the ability to supply Brightcove a URL to a 3rd party media resource. It is the only upload method that will allow you to currently access locally stored media (images and videos).
This media , ex: http://intranet/media/videos/myvideo.flv, still needs to conform to our currently supported playback requirements and the URL needs to be accessible by he Flash Runtime (eg URLs beginning with http://. smb://, rtmp://, file://) for our players to be able to consume it properly.
By using Remote Assets you will need to do the encoding of the files outside of Brightcove as the phsyical file never gets passed to the platform, just its location. You can still leverage Dynamic Delivery however.
You will also be responsible for ensuring the media assets are accessible as our support team won't have access to your intranet.
You also need to adhere to the Flash security policy by placing a crossdomain.xml file at the root of each media URL - so if my media is located at http://intranet/media/videos/myvideo.flv then my crossdomain needs to be located at http://intranet/crossdomain.xml - this is true for every domain I reference, so if I have http://intranet1/..../myvideo1.flv then I'll also need a crossdomain.xml at http://intranet1/crossdomain.xml
The structure of the domain file will be unique to you but for testing you can use something like this:
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<allow-access-from domain="*" />
This opens it completely up to accept all connections, you'll NEED TO LOCK THIS DOWN before going into production.
You also need to make sure that your viewers have domain rights to access the media resources - otherwise the players will load but you won't get any video playback. This is done at the network admin layer (such as ActiveDirectory). Remember the Flash client will operate under the user's security profile.
Finally you need to make sure that you allow access to the Brigthcove service via your proxy/firewall. The domains you'll need to allow are (all HTTP or HTTPS):
You shouldn't ever lock this to the underlying IPs as they are subject to change at any time with no notification.
You then upload, via Batch Provisioning manifest file, links to the object - for example:
Once in you can work on it as you normally would in the console, adding all your metadata, programming it, creating players and even putting ads against it (imagine a client VPN video network where you get some promos in there as well).
You can then play the video back as per normal via the Brightcove Player, getting access to our rich API, the ability to serve ads, usage tracking and anything else that concerns you. And there's no need to worry if the Player code is taken externally from your intranet as the underlying media resource will be inaccessible in anycase.
Corporate video communication is becoming an absolute necessity both internally and as an end product. Getting this set up on your intranet will be a very secure and robust way of leveraging the power of video for your business.