Secure HTML5 Video Player Plugin for WordPress

UPDATE 5/22/15: We have a new Q&A section for this plugin.

Go to Q&A Board for SH5VP

This is a video FAQ for our WordPress Plugin called Secure HTML5 Video Player. In it, we walk you through questions about security (and how to secure pages, which is NOT part of this plugin by the way), folder settings for secured videos, shortcode and parameters to set on your page or past,  and a Safari-specific video encoding issue we hear about a lot.

We hope you find the plugin helpful! Please share comments or update the plugin yourself if you see areas needing improvement.

 

Having trouble installing and making it work? The first thing we recommend is searching the comments on this page via your browser’s Find command. We are happy to answer questions when we’re not working on paid client work. If you can’t wait, might I suggest hiring an oDesker for help? It was one of our best discoveries of 2011.

Comments

  1. Bob says

    I’ve been using Secure HTML5 Video Player (currently version 3.9) to handle a number of short videos on a client’s site. The setup has successfully worked on several hosts (to facilitate development and testing). The client just upgraded from FatCow’s regular shared hosting to its new “WP Essential” faster shared hosting.

    On the new platform the following problem has begun occurring: Even though the locally-hosted videos still work fine on computer-based browsers, they fail to play at all on IOS devices. There’s no error message–just no response when you attempt to start the video playing.

    For now I’m working around the problem by hosting the videos on Amazon S3.

    Any idea what might be happening?

    Thanks.

    • duncan says

      Have you tried an alternate setting for caching? It looks like you’re using dynamic caching. If you switched to file caching, the video playback performance should be more consistent. The most recent update to file caching is optimized for space. One option uses hard links, and the other symbolic file links. We provide 2 options because some server configurations are such that only one of those options work.

      I’m not sure why the video is failing to play on iOS. My best guess would be that there is some configuration on the server that is set to limit the capabilities of PHP, and that is making some aspect of the plugin fail. I’d advise that you check the server’s error log and see if there are any php errors present. If there are errors, please send that information to us.

      • Bob says

        The video performance is fine at this point. The only issue is the failure to play on iOS when the videos are hosted on the new FatCow server. On the old server, on my test server at Bluehost, and on my local development server the problem doesn’t exist.

        I don’t think I have access to the server logs, but I’ll see. Regardless, they have a ticket open and I’m sure someone can look at them.

        I was basically just checking whether this (won’t play on iOS from certain servers) is a symptom you’ve run into before. I realize your Plugin is free, and don’t want to take a bunch of your time. Thanks again for the quick responses!

  2. Bob says

    In response to a question I left on June 23, Duncan explained that that on Chrome, you needed to set preload=”yes” to get autoplay to work. This solved my problem at the time.

    I just updated from v 3.8 to v 3.9, and immediately began to experience a significant delay before my videos would begin to autoplay in Chrome. I was able to resolve this by changing preload back to “no”. (And autoplay now works in Chrome with preload=”no”.)

    Any idea what’s going on?

    • duncan says

      Hi Bob,

      Sorry for the problems. I don’t think the preload setting should make any different with regard to autoplay in the latest version of Chrome. This may have been a bug specific to an older version of Chrome.

      I think the change in the plugin that may have broke auto play for some of your videos in Chrome is likely the one that now orders MP4 videos ahead of OGV and WEBM. That change was done primarily because now that Firefox support MP4 videos, and because processor efficiency is greater with MP4 decoding both on mobile and desktop browsers, there’s no reason to give a preference to the other codecs.

      But the side effect of that change is that likely Chrome is giving preferred playback preference to MP4 rather than the other format, and that’s revealing a streaming issue specific to some of your MP4 videos. With MP4 unless they’re encoded as being “web optimized” or “fast start” they will encounter delays prior to playback on most browsers.

      You should be able to do this using Handbrake:
      http://diveintohtml5.info/video.html#handbrake-gui
      or Final Cut Studio:
      http://www.screenlight.tv/blog/2010/11/25/encoding-h-264-quicktime-for-the-web-with-compressor/
      or another video encoder that is able to create MP4 videos meant for web playback, like Miro:
      http://www.htmlandcssbook.com/extras/encoding-videos-for-the-web/

      If these file updates are too time consuming, for the time being you can reverse the change we made by editing the file:
      sh5vp-functions.php at around line: 1836
      from:

      if ($mp4_source) {
      $video_tag .= “{$mp4_source}n”;
      }
      if ($webm_source) {
      $video_tag .= “{$webm_source}n”;
      }
      if ($ogg_source) {
      $video_tag .= “{$ogg_source}n”;
      }

      to:

      if ($webm_source) {
      $video_tag .= “{$webm_source}n”;
      }
      if ($ogg_source) {
      $video_tag .= “{$ogg_source}n”;
      }
      if ($mp4_source) {
      $video_tag .= “{$mp4_source}n”;
      }

      That will change the source tag ordering back to the way it was before. Please let us know if you continue to have problems after trying these steps. Thanks.

  3. Thorsten says

    Your plugin worked fine, but the last update seemed to change things.
    You changed something in the way the files are served from cache I
    remember. In my case I cannot serve the files anymore from cache they
    will not display in both Internet Explorer and Firefox 32.0.1. This
    happened after I did some changes on my site.

    What I did: My video directory was a symbolic link to a directory
    somewhere else on my webspace. I changed the video directory to a
    different symlink and the videos could not be started. The controls
    appear but I cannot start the video.

    I tested different locations and managed to run the video from my
    public_html folder but all other locations I have tested did not work.

    Is there a way to clear the cache or do I have to use real directories
    as video directory and not symlinks?

    By the way: In Firefox 32.0.1, when serving files dynamically, Mp4 files
    did not display in general on my blog. The plugin starts a flash player
    but the video could not be started. My workaround was the option to
    serve from cached files but this seems to have stopped working now.

    • Duncan says

      Hi Thorsten,

      Sorry about the problems.

      In the recent update we optimized the plugin to favor using symbolic links instead of file copies when trying to cache the file for video serving. In most situations, this should improve performance and space usage significantly.

      I think for your case, the problem is either that:

      1. The webserver is configured to not allow serving linked files.
      If this is the case, I think it can be solved by adding this line to your htaccess file:

      Options +FollowSymLinks
      Or by adding “FollowSymLinks” to the link of options set in the apache configuration for “Options”.

      2. The PHP code is not able to create a symbolic link to a symbolic link
      If this is the case, I think it can be solved by making the video directory setting point to a real directory, or by making the symbolic link a hard link to the directory. I don’t think this is likely the problem, but it might be worth trying.

      Another thing you can try is deleting the sh5vp_cache directory in wp-content.

      If it still doesn’t work after all that, you can change the behavior back to how it was before it in the php file: prepvideo.php in the plugin’d directory, and change around line 94:

      if (!symlink($video_orig, $video_cache)) {
      copy($video_orig, $video_cache);
      }

      to be:

      copy($video_orig, $video_cache);

      After making that change, delete the sh5vp_cache directory to make it take effect.

  4. says

    After I moved my video files to AWS S3 all video files can be downloaded via a mouse right pressign and downloaded via video option. All S3 configurations and secure html5 plugin are via id and secret key, properly configured. No fall backs or download options set in the plugin.
    What I am doing wrong? You will find different video plugins, please use this link to see what I am reporting http://www.pororo.com.br/cante-com-pororo/
    My concern is regarding some training videos that can not be downloaded in such easy way.
    Thank you.

    • Lucinda Brown says

      Hi Virg,

      This is one of the most common questions (and frustrations) we hear. Once a user is on your page watching a video, they can steal it. No one can get around that. They can screencapture the whole video using jing or other screen capture tools. What our plugin does is

      • store videos in a place above the top web root folder so no one can snoop and find them.
      • help you manage videos, skinning, caching and playback from a variety of storage options

      We don’t handle the securing of the pages either, despite the plugin’s name. There are so many good options for managing access to pages (such as paid memberships pro, wordpress password protect page, memberpress, ithemes exchange, etc.).

      Your job is to find a way to ensure the right person gets to the page with your protected videos. After they’re there, there’s nothing anyone can do to 100% protect the content.

  5. duncan says

    iOS devices should play MPEG4 files fine, but the issues can come up when they’re not HTML5 video encoded. There are many codecs for MPEG4, and the only one that is supported for video playback on the web through the video tag is H.264. Also, if there’s an option to “web optimize” the video, it’s usually a good idea to use that option when you encode the video.

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>