FlowplayerNative's API is a powerful extension for the HTML5 video object, with a small set of it's own properties, methods and event types. Most are for convenience and some extensions normalizes the API so that it works consistently across browsers.
When using the javascript API, creating a Flowplayer instance is synchronous. The first argument is the selector or container you wish to have the Flowplayer instance live inside of, the second argument is the configuration object.
When using cloud-hosted players, all of the Flowplayer libraries are loaded asynchronously in parallel to reduce startup time. This means that we must know that the cloud hosted resources have finished loading and it is safe to access the api of a given player. In these asynchronous environments you can access the flowplayer.cloud Promise to ensure that all of the parallel loading is done.
Cloud embeds intelligently detect if they are located in a container other than and to automatically create a Flowplayer instance. Adding a cloud hosted asset loader to a or tag will mean the loader will not automatically create the Flowplayer instances on resolving, since it is impossible to determine the best strategy in these setups.
This does not mean you cannot use the cloud-based player to manage configuration from the Platform, it just requires some special consideration. We have this advanced cloud-based single-page application as a demonstration of how mix the two.
By default the player is positioned in the middle. To change alignment of the player to either left or right:
Go to FV Player settings > scroll down to post interface options > tick Align. Now you can insert your video. In the interface you can now choose you alignment from the drop down menu: default (middle), left, or right.
You can check demo in here.
We heard about problems when using some fancy pro templates like OptimizePress (read below for fixing instructions) or Gantry framework. These templates often break the WordPress conventions (probably as they often try to add too many non-template functions, like video support built-in into the template). We can debug the issues for you, just head over to our website and order the pro support.
The error message means the WordPress media uploads directory (by default wp-content/uploads) is not writable by PHP. We use this standard WordPress path as it should work for nearly all the websites. Most of people use the standard WordPress Media Library, so this should really work.
This option is not available. With autobuffer, it means every visitor on every visit to your page will be downloading the video. This means that you use a lot more bandwidth than on demand. I know that I actually watch the video on only about 1/3 of the pages with video that I visit. That saves you money (no bandwidth overages) and means that people who do want to watch the video and other visitors to your site get faster performance.
If you want to autobuffer, you can turn that on in the options (we turn it off by default and recommend that it stays off).
You can change this manually in the the models/flowplayer.php in the flowplayer_head function. It you use videos in widgets you might need to edit the function flowplayer_content in controller/frontend.php as well. Please be carefull when editing source codes.
Fill the Flowplayer shortcode part according to your needs. The apply filter needs to be called because the flowplayer shortcodes are not parsen outside posts automatically. Also, please do not forget to add the echo at the beginning.
There is an possible issue with some themes: YouTube video opens in fullscreen, but after minimizing and opening fullscreen again, the video is shrinked in the left part of the screen (as in this example). You need to copy this CSS into your theme style sheet:
I have an HTML5 page I have created for my own offline use that has around 60 instances of HTML5 video tags and this crashes FireFox ( I have sent the report details on..unfortunately it is not possible to copy & paste them from the report box as this doesn't allow for copy/paste).I also disabled hardware acceleration in the tools options but this has not helped.
I use .ogv video file instead of .mp4and Firefox handles this file fine now (with over 60 video player instances on the page). It was a while since I had last tried HTML5 video and I had forgotten it is not exactly straightforward with which browser supporting different formats.
Since firebox does not support mp4 codec it is calling upon flash player to run the mp4 file wrapped in flash, and its most likely flash player causing it to crash, not the html5 coding. loost the flash player wrapper and encode you video with webm or ogg which Firefox natively supports and you will have no need for the extra coding to support the mp4
You shouldn't need to paste long crash reports in the forum. When Firefox crashes, it usually records information about what was happening at that moment. You can submit that data to Mozilla and share it with forum volunteers to see whether it points to the solution. Please check the support article "Firefox Crashes" (especially the last section) for steps to get those crash IDs from the about:crashes page (the linkable ones will start with bp-), and then post some of the recent ones here.
I guess Mozilla are paying royalties to MMPEG-LA now ( -US/docs/HTML/Supported_media_formats ) Last time i did any web stuff it didn't support. Also it cannot use the HIGH profile for lower machines, so depending on how iy was encoded and the particular machine.
I never had to do anything like that to get it to work, and just tested it, and it works just fine. In order to support mp4 the codec has to be supported in Firefox, i studies this quite some time ago and know that i never installed any of that. That is why Firefox can play webm right out of the box. There is no native support for webm in windows, thats why you have to use VLC to play it natively BECAUSE VLC HAS THE CODEC embedded AS THE SAME WITH MKV and i didn't have to go fiddling around with any Windows Media Foundation support, that is because the codec has to be supported within the browser, the OS does not run it unless you download it and play with a native player. Everything is handled within the browser.
You might want to read the articles that i posted as quoted: " Mozilla will release Firefox 21 next Tuesday and with it comes H.264 support to the browser " As it looks like you didn't read this. IF mpeg decoding was dependent on the platform there would have been no need for this article and support within the browser, right?
If you require proof, download opera and try running pure HTML5 code as in my example above and see if mp4 file is indeed dependent on the operating system or browser. OPERA DOES NOT SUPPORT MP4 Can you get it to play natively in the browser? I think with a little reading of the articles i posted as 100% PROOF i know what i am talking about.
I can say that i dealt with this over two years ago and studies it in a professional working environment with a user base of over 10,000, so i do know that this is a 100% browser support issue unless you are calling WMP for example to handle mp4 content, that is completely different matter as talking about playing natively in the browser using html5
You are correct that older versions of Firefox didn't even bother to try hooking into these decoding APIs. That was for "political" reasons, because Mozilla sought to drive everyone to use only open (not patent encumbered) codecs. Google had promised to go along with that, but never did, leaving Firefox as the lonely holdout, and Firefox users stuck using plugins to play MPEG-encoded media.
Since that was a losing battle, Firefox has gradually been adding support for these external decoders. On Windows Vista and higher, this is the Media Foundation API, and on Windows XP, Firefox 26 now uses DirectShow (I don't know what that is, actually). On Linux there is gstreamer, and on Mac, it's not yet possible. Android platforms are a mixed bag as well.
3a8082e126