...

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

WebRTC

...

Native Chrome Media Player

Series 5 players support selecting native Chrome for video playback with hardware acceleration or using the default BrightSign Media Player for video playback. You can pick which option is best for your use case (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

WebRTC

For WebRTC, BrightSign OS always uses native Chrome video playback.

Series 5 players, running OS 9.0.115 and later, will automatically use hardware-accelerated decode in this case.

Series 4 and older players do not support hardware-accelerated decode with native Chrome video playback. As such, the decode will be done in software, and we only recommend trying this approach with XT4 players.

Intrinsic Video Size

...

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.

...

• BrightAuthor:connected: Select the Enable native video playback box in theHTML5 State.

• BrightAuthor: Check the Enable native video plane playback box in the HTML5 state.

• BrightScript: Call SetHWZDefault("on") on the roHtmlWidget instance.

...

• 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

 // 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;">

...

To select a decoder in BrightScript, pass an associative array to the roVideoPlayer.PlayFile() method containing the decoder:[friendly_name] parameter:

To select a decoder for HTML video, include the decoder:[friendly_name] property with the hwz attribute:

The max_usage of a decoder determines how many video players can be assigned to the decoder using the system software algorithm described above—video players beyond the  max_usage limit may be assigned to another decoder or not displayed at all. On the other hand, if you manually assign video players using the friendly_name of the decoder, you can assign more video players to the decoder than the max_usage limit, but this may cause unpredictable video-display behavior.

...

BrightSign precision for HTML video timecode playback is 200ms.

Chroma Keying

BrightSign chroma key settings consist of a mask, and a minimum and maximum value. The minimum and maximum are the most important values since the mask is really only useful for “special effects”. Each pixel of every frame is checked to see if it is between the minimum and maximum values and if it is, the pixel is set to fully transparent. If it is outside the range, the pixel is fully opaque. This means you will have a hard edge, not a gradual fade, where the video goes from opaque to transparent.

Chroma Key Tips

• To get better chroma keying, do not anti-alias any pixels that should be transparent. You will then be able to target a single transparency color rather than a range.

• If your video is compressed, the chroma is sub-sampled, so there will be edges where the chroma will end up as an intermediate value between green and the frame color. CGI animations with green holes often have anti-aliasing which will result in a fade of green around edges. You may be able to chroma keyed out these edges with the values shown in the examples below (in these examples, v is anroVideoPlayer object).

• The easiest color to remove from content is black which has a luma value of 0, because the video has sub-sampled chroma (4:2:0 rather than 4:4:4). Using luma keying means that every pixel can be accurately keyed.

• White is luma 240 (it's not quite a full range 8 bit value), but the chroma can mean that it contains many other bright colors, so it's hard to just remove white.

• Arbitrary colors are hard to deal with, as they involve specifying a small range of chroma values which must be calculated. The color to be removed has to be calculated in YCbCr, and the Cb and Cr values are used for the chroma keying. If the source is CGI then the range used can be very tight since a single color is made transparent. If the video source was live footage shot against a green screen, then the range needs to be much wider to accommodate the range of green colors in the video.

Examples

Lower Chroma Key Values

Here the Cr range is 0-32 and the Cb range is 0-48. This may leave a green halo around areas that were blended to give a smoother look since chroma keying can't do smooth transitions.

v.SetKeyingValue({cr:&hff2000, cb:&hff3000})

Higher Chroma Key Values

This example covers a much larger range of colors:

v.SetKeyingValue({cr:&hff7000, cb:&hff7000})