Broadsign supports the display of dynamic HTML5 content on Broadsign Control Player. To enable this content, we provide a number of tools and configurations:
- Transparency effects
- Content caching
Note: As of Broadsign Control v15.4, we support Chromium version 87+ (with security patches to version 94).
Note: As of Broadsign Control v11.1, Chromium will not work on WinXP (though it will work on v11.0 and earlier). If you try to use Chromium on WinXP (Broadsign Control v11.1+), you will receive the following error message: "[2018-08-01T15:29:51](message) Frame [YourFrameID]. Could not play ad copy id [YourAdCopyID]. Could not find an appropriate codec."
You can render HTML5 content semi-opaque or completely transparent.
Transparency will provide effects similar to the following image:
For details about system requirements and configuring Broadsign Control Administrator, see Transparency.
You can upload HTML5 packages just like videos. HTML5 packages can be previewed and approved to win auctions just like videos.
The Broadsign Control Player’s disk monitoring function will process Broadsign Reach-delivered HTML5 package with the same atomicity as it does in Broadsign Control.
If the player does not have time to download and unzip the HTML5 package before the ad slot needs to play, the slot is skipped.
Broadsign Control Player will accept an "asset_url” in the Ad Response that points to a “.x-html-package”.
Broadsign Control Player will accept a mime of “application/x-html-package” in the Ad Response.
The Chromium browser uses our Chromium caching mechanism.
As a result, if there is no network connection, or if the document takes a few seconds to fully load and you do not want customers to see an incomplete page on screen, Broadsign Control Player will use content from the cache.
For more information, see HTML Content.
Note: If your HTML Package contains a video that should start when the Ad Copy is displayed on screen, use the BroadSignPlay() function. This function is called at the same moment the Ad Copy is displayed on screen, allowing you to pre-buffer the content and control its starting time. For more information, see BroadSignPlay().
You can retrieve data from the Internet by using your HTML Package in two ways:
- Directly, such as displaying a video.
- Indirectly, such as fetching information through an API to then decide what to display on the screen.
The origin of an HTML file executed outside of a web server is "file://". By default, many servers will prevent requests from said origin to be executed, as an ongoing process to prevent XSS (cross-site scripting) attacks.
If you are managing the remote server to which your HTML file is pointing, make sure that the header
Access-Control-Allow-Origin is set to "*". This will allow the origin of the requester to be anything. Doing so, however, may introduce a security risk, so Broadsign suggests to add custom headers in your request that will allow the remote server to authenticate the requester as legitimate. The custom header can be a token that the remote server will verify and either accept or refuse the connection.
If your web redirect ad copy produces an HTTP error -- whether client (4xx) or server (5xx) -- the player will skip to the next item in the loop. Skipping the content ensures that neither error messages nor black screens appear on your monitors.
If nothing is drawn on the screen at playback time even if the HTML file is not empty, the Ad Copy is discarded.
For more information, see HTTP Errors and Incidents.
When calling that function, the HTML page grabs the player focus and any keystroke are then sent to the HTML page.
We recommend not calling the requestFocus() function before the HTML page is displayed. To ensure that the function is called at that point, place the call inside the BroadSignPlay() function .
BroadSignPlay() is called only when the HTML page is shown on the screen, so the keystrokes are sent to the page only from that moment.