Radiant Media Player offers 4 different player skins each with a different look and feel and optimised for cross-device rendering. They can be customised through skin-colorization or CSS to better fit your project requirements.
A player skin is set with the
skin player setting:
The name of the skin to be used - available values are: 's1', 's2', 's3', 's4', 'outstream'. Default: 's1'.
If you have multiple players on the same page, all players will have the same skin: the first skin loaded.
You can see all 4 skins live here.
The 'outstream' skin is only available when using outstream video ads.
Represents the delay in milliseconds before the overlay control bar fades away when no user interaction is detected. On mobile
delayToFade value is automatically increased by 33% for easier user-interaction. Default: 2500.
Hide player seek bar. This effectively prevents seeking into a video. This should only be used for on-demand video content. This also disables keyboard control for seeking. Default: false.
Hide player fullscreen button. This effectively prevents entering into fullscreen mode. This also disables keyboard control for fullscreen. Default: false.
Permanently hide the player central play button. Default: false which means the player central play button is displayed.
Permanently hide the player central buffering overlay (animated wave or spinner depending on skin when player is buffering data). Default: false which means the player central buffering overlay is displayed when buffering happens.
Set the player background colour in hex colour format (typically shown in certain aspect-ratio configuration or when no poster setting is provided). Default: '000000'.
fadeInPlayer is set to true, the player will have a CSS fadeIn effect (400 ms) as it becomes ready, giving a nicer player introduction to the viewer. Default: true.
The player will use a separator character in the sharing and quality modules. This setting lets you tune this character. Default: '-'.
The 4 player skins can easily be colorized using the following player settings.
skinBackgroundColor: this setting will colorize the background of the skin (String, default to '')
skinButtonColor: this setting will colorize the buttons and texts of the skin (String, default to '')
skinAccentColor: this setting will colorize secondary UI elements of the skin - like hover state for buttons (String, default to '')
The above parameters accept either HEX color code (example: 'FF0000') or rgba color code (example: 'rgba(0, 255, 0, 0.8)') for transparency support.
Colorized player example:
Player code for the above example:
Radiant Media Player skins can be customised through CSS. Source CSS and LESS files are available for each player skin in our back-end within the self-hosting player files package.
When doing advanced CSS work on the player you must self-host the player files.
First navigate to the css/ folder within the self-hosted player package and inspect it.
Option 1: tuning with Less
open the rmp-s1.less file (or another rmp-s*.less file) - this is the file for the 's1' skin. You will see that it references several .less files:
You can apply your modifications to each .less file you want to tune. You will then need to use a less compiler to output your changes to CSS.
Option 2: tuning with CSS
open rmp-s1.css (or another rmp-s*.css file) and apply your modifications
In all cases you will need to minify (a.k.a. compress) your modified CSS file to rmp-s1.min.css in place of the former rmp-s1.min.css file (or another rmp-s*.min.css file for the other skins). The player will then automatically pick up the CSS changes.
init is called on player - which means that any CSS you may apply to the player when page loads may be overwritten at a later stage (e.g. after
init has been
called). Typically one can know when player CSS is loaded and applied when the player
ready event fires. You may use
CSS specificity to override the player CSS (while a limited use of the !important exception is generally accepted in the industry using CSS specificity is a better approach).
This could work for simple CSS modifications. However for any advanced CSS work on the player you should follow the steps above to modify the core player CSS and let the player load the modified CSS through its own logic.
This is not an exhaustive list of CSS classes for the player but rather some high-level information about the player structure. If you want to customize extensively the player UI with CSS you are going to need to use a DOM inspector at some point to better understand the player layout.
.rmp-containerclass: this is the player container where all UI elements are added
.rmp-contentclass (child of
.rmp-container): this is where the video tag, poster frame or captions rendering area are appended
.rmp-overlay-buttonclass (child of
.rmp-container): the overlay central play button
.rmp-loading-spinclass (child of
.rmp-container): the central loading spinner
.rmp-outlineclass (child of
.rmp-container): the control bar at the bottom of
.rmp-moduleclass (children of
.rmp-container): the module UI (like sharing, bitrate selector or closed captions menu) - more information on player modules can be found here
When the player is resized (for example on player load, orientation change or window resizing) the player will add resizing classes to its container based on its current width. Those resizing classes change the layout of the player to better fit the current player size and are applied at common break points for devices currently available on the market:
.rmp-extrasmallclass is present
.rmp-smallclass is present
.rmp-mediumclass is present
Most of the player CSS magic happens at
.rmp-chromeclass on the player container. When the player UI elements are not visible the player has a
.rmp-no-chromeclass on the player container.
.rmp-fullscreen-onclass on the player container.
.rmp-liveclass on the player container.
.rmp-live-dvrclass on the player container.
.rmp-mobileclass on the player container.
.rmp-castingclass on the player container.
.rmp-related-uiclass on the player container.
.rmp-audio-onlyclass on the player container.
Eventually you may want to go one step further and build your own set of player controls from scratch. You can do this by setting
hideControls to true and using
our player API to command the player (play/pause, volume, seek ...).