Identified known issues include:
When sharing large numbers of videos, Brightcove recommends sharing at most two pages of videos at a time. Sharing a large number of videos at once may cause a timeout error.
Adding captions to a video that was shared which already contains captions is not supported.
Media sharing will fail for videos created by clipping live streams.
Workaround
One way of preventing this is to implement a Live custom error message in the player by adding plugin including code some like the following:
// Listen for a change on the durationmyPlayer.on("durationchange", ()=>{
// Save the duration to a local variable
var duration = myPlayer.duration();
// Check if the duration is a finite number (VOD)
// or if it's infinite (Live).
// If it's a VOD it would mean that the recurrent stream is over
// and the custom image would be displayed.
var isLive = !Number.isFinite(myPlayer.duration())
if(!isLive && duration !== 0){myPlayer.pause();myModal.open();
When seeking playback to the beginning of a video with a pre-roll ad, the ads-ad-ended
and ads-pod-ended
events will fire.
A possible work-around would be to use
player.currentTime(0.1)
instead of this
player.currentTime(0)
user_agent
delivered to it with analytics data. The most common cause that we have identified for this is a custom user_agent string created by Instagram, but there are probably others.The Ghostery browser plugin may interfere with the Social module preventing it from loading properly.
Workaround: Add Studio to the whitelist for Ghostery.
Check the Brightcove Player Release Notes to see if a past known issue has been corrected by a recent release.
document.querySelector
)querySelector()
or querySelectorAll()
methods will fail if the element ID starts with a number. There is a painful workaround but the better solution is to avoid doing this.id
Set to default
id="default"
on the page. The blog post DOM: element IDs are global variables explains why this is an issue. One common symptom of this problem is the MEDIA_ERR_UNKNOWN
error.Workaround
We have resolved this issue for SSAI by adding additional CORs headers. If you are using client-side ads, this will not address the issue, as the CORs headers have to be sent from your server or hosting service. The headers we added are:
access-control-allow-headers: Server,Range,Content-Length,Content-Range
access-control-allow-headers: X-Requested-With,Origin,Range,Accept-Encoding,Referer
access-control-allow-methods: GET,HEAD,OPTIONS
access-control-allow-origin: *
Brightcove Player may generate warnings that appear in browser's console. The warnings, as opposed to error messages, are harmless and do not effect play back. An example of a warning is displayed here:
.vjs-has-started .vjs-poster {
display: block;
}
none
, automatic playback of the next video will fail silently.
If multiple players have the same id on one page and specify different size inside <video>
tag using width
and height
attributes, the player CSS from the last player is applied to all players.
Workarounds
When using Chrome and Firefox, videos in the Brightcove Player may display with a greyish color. This can be due to hardware acceleration and/or NVIDIA driver settings.
Workaround: Open the NVIDIA Control Panel. Under Video select Adjust video color settings. Under How do you make color adjustments select With the NVIDIA settings. Under Advanced make sure Dynamic Range is Full (0-255) not Limited (16-235). Dynamic contrast enhancement should be unchecked. This issue has been reported on the Google Chrome Help Forum.
Whether you are using Chrome Device Mode or other emulators to test video playback, be aware that emulators do not accurately represent how an actual device will perform. While you can use emulators for initial testing during development, it is best practice to use real devices for accurate results.
When testing playback with Chrome Device Mode, you may see this message: "The use of Chrome in device mode simply renders the viewport and user agent string of that device in Chrome, which is not an accurate representation of how the actual device will perform."
data-setup
data-setup
with Brightcove Player. You may see use of data-setup
in the API documentation, but this is because that documentation is generated directly from the Video.js player source code, and you MAY use that attribute with the video
tag with pure Video.js. The attribute sends configuration information to the player, but Brightcove Player uses a different method to perform this task, which makes data-setup
unreliable.
In environments where Flash is disabled or Flash-based HLS is disabled for the player, and the player is explicitly sized using a style
attribute on the video
tag, fullscreen viewing may not function in some browsers.
Workaround: remove the style
attribute from the video
tag, and instead create a rule in page stylesheet like this:
.video-js{
width:640px;
height:360px;
}
On most desktop browsers, the Brightcove Player will only play HLS on HTTPS web sites when both the manifest and the video segments are served over HTTPS connections. This is due to recent changes to several browsers that more severely restrict non-SSL content. This affects users of Chrome, Firefox and Internet Explorer on desktop computers. It does not affect Safari users or mobile browsers, and it does not affect playback of MP4 renditions.
We are in the process of addressing this limitation for Video Cloud-managed assets; if you manage your own CDN and transcoding (remote assets), you must configure your CDN to support HTTPS delivery of both manifest and video content.
In newer browsers that support the fullscreen API, it's necessary to apply in-page CSS rules to ensure the player is scaled to 100% when switching to fullscreen. Otherwise, the player will appear at the original size within the fullscreen display. For details, see the Fullscreen display topic in the Size the Player document.
For IE10 and earlier, with no fullscreen API support, a new window will open, but the player will not be sized to fill the window. This is because no styles have been applied to resize the player. Since the window cannot be scrolled, you may only see a section of the website, with no player at all.
When multiple videos are published on a single page with HapYak chapters, an incorrect chapter could be displayed.
Workaround
Use this script: https://github.com/brightcove/gallery-in-page-snippets/blob/master/snippets/hapyakFix.js. However, Flash playback (IE11/Win7) cannot avoid this issue, so the HTML5 fallback needs to be implemented in case of IE11/Win7.
This error, caused by a known bug, can occur when switching between different formats, for instance MP4 and HLS, in a player. Until the bug is fixed, you can simply retry the code that is causing the issue. The following code is an example that corrected the error in an app:
try {
myPlayer.catalog.load(video);
} catch (e) {
myPlayer.catalog.load(video);
}
myPlayer.play();
bc()
method to instantiate the player. The need to use the method will be determined by how/when the player assets are loaded. See the RequireJS and Brightcove Player document for more information.referrer_url
value may have different values between iOS and Android devices. Because of this, it is recommended to use the description_url
value instead. This value is consistent across all platforms and devices.<div>
tag with an id
assigned the value global
. This causes issues with Brightcove Player.You will be linked to the particular plugin document so see the known issues for a plugin. Since version 5 is in maintenance mode, and this is a cosmetic issue, it will not be fixed.
:hover
pseudo-class. Another long press elsewhere on the player will typically close the menu.Learn how to create Android apps that utilize the Brightcove Player SDK for Android.
Learn how to create iOS apps that utilize the Brightcove Player SDK for iOS.
Due to a bug on MSE on Chrome browser implementation documented here:
https://bugs.chromium.org/p/chromium/issues/detail?id=534301
Playback on that browser for version 5 and above of BC player will fail (showing MEDIA_ERR_DECODE) if the audio profile of the rendition being attempted is different from AAC-LC.
To avoid this happening on new ingested content, customers need to make sure they either
"max_aac_profile": "aac-lc"
To avoid this happening on existing content, options are:
h264_profile
is set to baseline
or the h264_profile
is not added to the Job request, it causes an issue on Windows 10 using Firefox v57.PLAYER_ERR_TIMEOUT
error.