light background

Advanced video publishing

This guide refers to advanced video publishing use cases. For standard video publishing please see our basic guide here.

To publish a video in Flowplayer and take advantage of the most advanced use cases you need two things:

  1. Video file that is properly encoded
  2. Video player that is configured for your use case

Video file that is properly encoded

You have three options for how to host and make the video files available for playback in Flowplayer:

  • Flowplayer hosted video (default choice and recommended use case)
  • Self hosted video added as Remote video in Flowplayer
  • Self hosted video not added as Remote video to Flowplayer

Below is an overview of the different options:

Flowplayer hosted

We always recommend that you upload your video file to Flowplayer and let us take care of the encoding to ensure that you benefit from flawless playback on every screen and also take advantage of our optimized CDN to ensure flawless playback across all networks in the world. Learn how to publish videos in this way.

Remote video

We also offer you the possibility to host video files yourself in case it is more practical for you. A common case is if you already have a very large and properly encoded media library stored in the cloud and don’t want to move the files to Flowplayer. In this case you can host your video file yourself either as a remote video. You publish a remote video exactly like a normal video.

By adding your assets as remote video assets in Flowplayer you will get analytics with the video assets and can take advantage of other functionality in Flowplayer such as metadata handling and playlists but can still keep the files stored in your server and hosted using your CDN. In addition you benefit from automatic upgrades and improved ways of handling video sources in the video player as we take care and optimize the loading of assets across different platforms.

Self hosted

In case you want to host the video files yourself, but do not want any of the features listed with remote videos, you are free to only use the player and load your source files directly into the player. Publish a player and configure it with your sources.

Video analytics are available for videos hosted by us and for remote video assets, ie if they are registered in our system and you embed them using the platform src id . External videos without a Flowplayer src id cannot be tracked. Do not embed the video urls directly! If you embed with the pure Javascript embed, you must also load the platform integration plugin.

Video player that is configured for your use case

Each time you publish a video in Flowplayer you need a player profile to go with it. In case you do not make a choice of the player profile we will automatically select your default profile as the base setup.

Technical requirements for remote / self-hosted video clips and streams

MP4

MP4 videos should be real MPEG-4 part 10 resp. h264 videos in an MP4 container. Make sure your encoder does not create MPEG-4 part 2 aka h263, which will not play in all browsers. The audio track should be AAC rather than MP3.

MP4 metadata

H.264 encoded videos carry their metadata — duration, frame rate etc. — in the so called "moov atom".

By default encoding programs will insert the moov atom at the end of the video file which is suitable for playback of a local file in a desktop program. However, any kind of progressive download requires the metadata to be available right away for immediate playback. Otherwise the player has to wait for the entire video to be downloaded before playback starts.

Make sure to select an option in your transcoding program which puts the moov atom at the beginning of the file!

In case you already have a lot of MP4 videos with the moov atom at the end of the file, use a dedicated program such as QTIndexSwapper or MOOV Relocator to move it to the beginning.

HLS and DASH streams

The video streams must be served with a cross domain policy (CORS) allowing GET requests. If the segments are not static files, but are retrieved via byte-range requests HEAD and OPTIONS must be allowed as well.

Sample CORS Configuration for Amazon S3:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>

        <!-- only required for byte-range based retrieval -->
        <AllowedMethod>HEAD</AllowedMethod>

        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>*</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

For other server configurations, please check enable-cors.org .

On a https site, you MUST load the stream with https as well. Modern browsers do not allow mixed content, hence you cannot use a http HLS stream on a https site.

Mime types

Make sure that all the files are available on the server (avoid redirects) and that the server transmits them with the correct Content-Type header. Depending on your server you might have to extend the .htaccess or mime.types files (Apache), use the IIS manager (Internet Information Server) or set the header via Metadata (Amazon S3). Example .htaccess file:

## video types
AddType application/x-mpegurl .m3u8
AddType video/mp4             .mp4
AddType video/webm            .webm
AddType application/dash+xml .mpd

## hls transport stream segments:
AddType video/mp2t            .ts

## subtitle text tracks:
AddType text/vtt              .vtt

For nginx, the MIME type is defined in nginx/conf/mime.types In lighthttps, use the config file

In Amazon S3 you need to give the content type as a parameter to the AWS cli or s3cmd when uploading a file, or adapt it in the metadata section of each file when it's already uploaded.

HTTPS

It is hightly recommended to serve all files with https. Never mix protocols!