Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updated as per DOCS-1110
Expand
titleTable of Contents
Table of Contents

...

  • [int] x-bs-stream-timeout: The length of time (in milliseconds) to wait for a stream to start before abandoning playback. Passing zero indicates that the video player should wait indefinitely. The default timeout value is 5000ms for HTTP streams and 3000ms for all other streams.

  • [int] x-bs-stream-latency: The amount of deviation (in milliseconds) from the default latency value: For example, a value of -500 will reduce the latency by half a second; a 500 value will increase the latency by half a second; and a 0 value will specify the default latency. Specifying a negative value will not change the buffer size; instead, it will give the buffer less time to fill up before playback begins. Usable values extend to approximately -750, though this value may differ depending on the network environment. Reducing the latency too much will result in obvious playback stutter.

  • [int] x-bs-stream-fade-in: The fade-in length (in milliseconds) for streams. By default, non-HTTP streams have a fade value of 1500ms if they contain video and 4000ms if they contain audio only. HTTP streams have a default fade value of 0ms.

  • [int or boolean] x-bs-stream-low-latency: Low-latency mode for RTSP streams. Setting this parameter to true (1) will achieve the lowest possible latency for a stream, but at a reduced maximum bitrate–which is often useful for IP camera streams. This parameter is set to false (0) by default.

  • [int] x-bs-intrinsic-width: The intrinsic width of the source video

  • [int] x-bs-intrinsic-height: The intrinsic height of the source video.

Achieving Low Latency

There are three options to reduce latency on Series 3 and 4 BrightSign players:

x-bs-stream-latency

The x-bs-stream-latency flag (buffer) described above under "Streaming Parameters". In this example, the latency is reduced by half a second (500 milliseconds):

Code Block
<video src="udp://239.192.1.1:5004" x-bs-stream-latency="-500">

x-bs-no-force-capture

If the x-bs-no-force-capture flag is set to true, video capture will bypass frame-rate conversion and introduce the following limitations:

  • Transform values other than "identity" will not work.

  • Screenshots may not be correct

  • The encoded video frame rate and the video mode output must match

For example:

Code Block
<video src="udp://239.192.1.1:5004" x-bs-no-force-capture="1">

x-bs-no-reordering

If the x-bs-no-reordering flag is set, it will Improve latency but disable playback of B-slices. For example:

Code Block
<video src="udp://239.192.1.1:5004" x-bs-no-reordering="1">

See this page for more information about modifying the latency of audio or video streams.

WebRTC

Screen sharing over WebRTC works on XC5 players if you switch to the Chrome video playback stack instead of the default BrightSign Media Player (see HTML Playback Options on Series 5 Players). Note that hardware accelerated video for native chrome playback is not yet available on any Series 5 player other than the XC5.

BrightSign does not support hardware-accelerated decode of WebRTC on Series 4 or lower players.

Intrinsic Video Size

The following order of precedence is used to determine the intrinsic size of a video:

...

Code Block
registry write html mse-support 1

HLS Live Streaming

BrightSign players support HLS live streaming, but large playlists (which usually result from the server delivering a DVR playlist rather than a LIVE playlist) will cause performance issues.

...

  • auto: If the video player is currently not showing anything (i.e. it hasn't played anything yet or the previous loaded video was cleared), the next video will fade in. If the video player is currently playing video, is paused, or is stopped without being cleared, the next video will not fade in. This is the default behavior.

  • always : When a video ends, the video window will go black. The new video will then fade in.

  • never: Videos transition without fade effects. 

HWZ Video Transparency Extensions

If "hwz" is enabled for a <video> element, the video window can also support luma and chroma keys for video transparency. The z-index: parameter must also be specified for transparency to work. The luma and chroma keys are specified as follows: 

  • luma-key:[HEX_VALUE] 

  • cr-key:[HEX_VALUE] 

  • cb-key:[HEX_VALUE]  

Example

Code Block
 // Video on video layer, in front of graphics layer, with luma keyed video.
<video src="example_movie.mp4" hwz="z-index:1; luma-key:#ff0020;">

...