ZEN MASTER September 2019 RELEASE NOTES

the following updates will be pushed to zen master on september 9, 2019 stats, uptime & outage, and usage reporting zen master now provides the ability to generate stats, uptime & outage, and usage reports the user defines the granularity and time period for the report into a report configuration, then generates the report, and then downloads the result as an xls file to use the new reporting feature, an admin first needs to update roles to include viewing or editing reports next, users with edit permissions can select reports in the left hand menu and click on the “+ add” button on the new report dialog, provide a name for the report, select the access tags, choose the report type and then configure the report parameters creating and saving the report does not actually run the report, it just saves the report configuration so that it can be run at any time in the future when you select an existing report configuration, you will see the basic details of the report in the details tab click on “generate report” to bring up a dialog for generating the report provide a name for this instance of the report this name will be used for the excel file that is generated and made available for download you can also update the time period and time zone of the report from the default in the report configuration depending on their complexity, some reports can take quite a while to generate – minutes to hours for longer duration reports, the recommendation is to use the largest granularity possible the “run history” tab displays the generated reports they are in the process of generating after the report generation is complete, the results can be downloaded and deleted the data available in reports depends on the type of report – stats, uptime & outage, or usage – and the type of object being reported on stats report the stats report provides data on the following object types, as shown in the tabs of a downloaded xls file the statistics available for broadcasters, for instance, are the following name max disk usage max nvidia decoder cluster avg disk usage avg nvidia decoder access tags min disk usage min nvidia decoder time max install disk usage max nvidia encoder max receive bitrate \[kbps] avg install disk usage avg nvidia encoder avg receive bitrate \[kbps] min install disk usage min nvidia encoder min receive bitrate \[kbps] max cpu max nvidia memory max send bitrate \[kbps] avg cpu avg nvidia memory avg send bitrate \[kbps] min cpu min nvidia memory min send bitrate \[kbps] max memory max nvidia usage udprcvbuferrors avg memory avg nvidia usage udpsndbuferrors min memory min nvidia usage each type of object will have different available statistics below is an example of a stats report on broadcasters uptime & outage report the uptime & outage report is available for sources and allows you to see the uptime of sources as shown in the example below the outages tab show details on each source outage, including tr 101 errors and cqa errors uptime and outage reports can be used to quantify the quality and consistency of video feeds being provided by content originators usage report the usage report shows bytes sent and active time for sources and targets and bytes transcoded for transcoded channels over the period of time for the report it can be used to provide data necessary for usage based billing an example of a usage report as shown below single sign on user authentication zen master now supports single sign on (sso) user authentication via oauth 2 0 any oauth 2 0 provider should work, but thus far microsoft office 365, google identity, and okta have been validated with zen master feedback on any others is welcome once sso has been configured on a zen master domain by an admin, the login screen will first have you choose the sso provider, as shown in the following example normally an organization will only use one sso provider, but zen master can support multiple sso providers or multiple instances from one sso provider on one zen master domain, where that is useful by clicking the “sign in with zen master credentials” link at the bottom of the page, legacy zen master accounts can continue to be used until the email address associated with an account has been associated with an sso provider, upon which time the sso system must be used to login to zen master for new sso user accounts, there will be an account activation process with the sso provider similar to the example below from okta once you select an sso provider on the zen master sign in page, you will next enter your sso credentials if your sso configuration has multi factor authentication enabled, you will complete that step next and will then be logged in to your zen master domain as usual, your permissions and groups will be set up by an admin who has configured your account configuring single sign on if you do not have an existing sso provider, the example below demonstrates setting up sso on google identity to highlight the key steps required to configure any sso with zen master however, documenting setup of sso providers, in general, is beyond the scope of this document to configure sso in zen master, select account settings from the settings menu next, click “+create sso configuration” the create new sso configuration dialog shows us the information we need to get from the sso provider as well as the callback url information for zen master that is provided to the sso provider for google identity platform, start by enabling it next create a new oauth client id next, fill in the redirect url from the zen master form above and enter the javascript origin, which is the same as the redirect url without the path download the json from the sso provider as it will include the information needed for zen master • authorization url • token url • client id • client secret next, click the oauth consent setting link and fill in necessary details on the oauth consent screen finally, copy the pertinent data shown in bold from the downloaded json file {"web" {"client id" "123456533461 rb2qo4ih2asi5sl5dq8nao0ukdbslrr7 apps googleusercontent com", "project id" "tim zen master integration", "auth uri" "https //accounts google com/o/oauth2/auth", "token uri" "https //oauth2 googleapis com/token", "auth provider x509 cert url" "https //www googleapis com/oauth2/v1/certs", "client secret" "12345e3q4begaqdjyukzkj o", "redirect uris" \["https //zixi staging zixi com/auth/oauth2/callback"], "javascript origins" \["https //zixi staging zixi com"] } } into the sso configuration form in zen master when ‘allow pre registered users only’ is enabled, only users who already have an account setup in the zen master domain will be able to log in via sso when it is not enabled, any user in the sso can log into the zen master domain but they will not have membership in any access groups and will not have any permissions until an admin adds these when a zen master domain is first setup for a customer, a non sso admin account will be created that admin can then set up sso, including for the email address of that admin account, and then login via the sso it is possible to have only sso accounts accessing a zen master domain or, if desired, it is possible to have a mix of sso and non sso accounts an example of the later case is everyone within an organization would login to zen master via the organization’s sso but partners or others outside of the organization can be given non sso accounts in the same zen master domain network bonding zixi's network bonding feature enables you to divide a stream into several network paths by utilizing multiple nics and ip links and then subsequently reuniting the divided streams at the zixi broadcaster network bonding supports push streams from the zixi feeder to the zixi broadcaster to enable network bonding, edit the source and select any for feeder output nic and then enable bonding under the details tab of the source you will see the nics with their ip addresses that are being used in the bonded connection as well as the bitrate of data being send out over each link in the history tab for the source you can see a graph over timer of the jitter, rtt, and bitrate of each ip link zixi platform v13 features with the general availability of the zixi platform v13, the following new features are now available in zen master when using v13 broadcasters estimated psnr the zixi broadcaster is now able to estimate the peak signal to noise ratio (psnr) of a source video without a need for the reference video estimated psnr (epsnr) is calculated for each frame of the video and is displayed in zen master as a continuous graph and as a heat map of histograms to view the epsnr graph, select the history tab when viewing a source and expand the content analysis graph the scale for epsnr is on the right axis if there are multiple video pids available in the source content, the desired pid to be viewed can be selected the resolution of the graph depends on the zoom level and is as low as 1 datapoint per minute to view the epsnr heat map, select the history tab when viewing a source and expand the encoding quality graph each vertical column in this graph represents a histogram of the epsnr values of all video frames over a 10 minute window the scale for epsnr is 11 to 60 with higher values being higher quality a higher encoding quality video source will produce a heat map with red color at the higher end of the scale if there are multiple video pids available in the source content, this graph only shows data for the first video pid found in the source content epsnr in the zixi broadcaster may be a separately priced and licensed feature epsnr analysis does not support mpeg2 or hevc/h 265 content, but does support most flavors of h 264 content stream delivery working in tandem, the zixi broadcaster and zixi receiver are now able to identifies dropped packets from a broadcaster to a receiver on a per pid basis the impact of dropped packets for video or audio pids is corrupted video or audio the impact of dropped packets for ad markers (scte 35) is those ads would not be properly loaded and displayed in the downstream system in zen master, the percentage of successfully delivered packets is displayed on a graph the resolution of the graph depends on the zoom level and is as low as 1 datapoint per minute to view the stream delivery graph, select the history tab when viewing a target and expand the stream delivery graph stream delivery analysis in the zixi broadcaster may be a separately priced and licensed feature stream quality analysis stream quality analysis identifies missing or corrupt video or audio frames from a feeder to a broadcaster on a per pid basis a frame is considered corrupt if the frame’s data is completely missing, partially missing or if it depends on a frame whose data is completely missing or partially missing for example, if an i frame is corrupt then it as well as all following p frames until the next i frame will be corrupt as well because they depend on the i frame and previous p frames if a p frame is corrupt, then the following p frames up to the next i frame will be corrupt in zen master, the % of good frames, i e not corrupt and not missing, out of the total frames per pid is displayed on a graph the resolution of the graph depends on the zoom level and is as low as 1 datapoint per minute to view the stream quality graph, select the history tab when viewing a source and expand the stream quality graph in the example above we see 93% good frames, which is not the 100% we would normally expect if we analyze the network statistics, below, we see that at that particular point in time there were some network packets that needed to be recovered and all of them were successfully recovered this tells us the missing or corrupt frames did not occur during transmission but instead occurred in the source if we look at the tr 101 analysis in the content analysis graph, we see that there were cc errors during that time period since there were no unrecovered packets during transmission, the cc errors are in the source stream itself and that accounts for the bad frames shown in the stream quality graph stream quality analysis in the zixi broadcaster may be a separately priced and licensed feature traceroute the zixi broadcaster now collects traceroutes from feeders to the broadcaster and from the broadcaster to receivers to view the current traceroute results in the zen master ui, select the trace route tab when viewing a source or target click the refresh button to update the traceroute results historical traceroute results are also available on the history tab of sources and targets the history graphs shows round trip times (rtt) to each server in the route between the source and broadcaster or broadcaster and target the resolution of the graph depends on the zoom level is as low as 1 datapoint per minute if there are persistent large round trip times through particular servers, a network reconfiguration may be necessary to alleviate the issue when routing through fixed fiber or mpls connections, the round trip time history graph may prove useful in debugging and resolving network bottlenecks in the example displayed below, routes through the aws network are continuously optimized and thus we do not see persistent large round trip times to see the host ip address and round trip time of a particular server, hover the mouse over one of the plots and a popup will display this information traceroute analysis in the zixi broadcaster may be a separately priced and licensed feature packet timing analysis packet timing analysis displays a histogram of packet arrival time (recovered if necessary) from push and pull sources this analysis can be used to see a history of latency from the source and to fine tune latency targets in the graph, the vertical axis is time in milliseconds with the max value set to the latency target and the horizontal axis is user specified minutes, hours, days, etc darker red in the histogram means more packets arrive at that particular latency in the graph below, most packets arrived under 1 second but some arrived just over 1 second since the target latency was set to 4 seconds, fec in the zixi algorithm would have been essentially disabled looking at the historical data, if desired, it would be reasonable to set the target latency around 1 second and then the dynamic use of fec in the zixi protocol would be used when necessary clearly, setting a latency target of 500ms under these network conditions would not be reasonable write hls/dash to mediastore the zixi broadcaster now supports writing hls and dash streams to aws elemental mediastore in the zen master ui, select http for the target type and then select mediastore for the type aac he audio encoding transcoding in the zixi broadcaster now supports aac high efficiency audio encoding in the zen master ui, select the desired encoding style in the audio profile pull down when audio transcoding is selected video cropping (zm 237) transcoding in the zixi broadcaster now supports video cropping by percentage or pixel ranges the cropping is specified on the transcoded channel definition as shown below the cropping is specified on the input and thus all renditions of the stream will be cropped the same minor improvements and bug fixes • added udp send errors to broadcaster history (zm 278) • added flag to force users to update password on next login (zm 279) • fixed issue where unable to delete domain as zixi admin (zm 268) • fixed incorrect channel diagram (zm 270) • fixed rest api for targets of pass through channels missing channel id (zm 261) • fixed no play button for azure targets (zm 271) • fixed issue where max bit rate does not display on zenm when editing pre existing source (zm 269) • fixed issue with forced user logout