Adding NDI Streams

the ndi is pulled into zixi broadcaster using the auto discovery mechanism described in the ndi stream discovery docid\ wbckncnlgzh7yncez0hcx section to add an ndi input stream before adding the ndi input stream, you must configure the relevant transcoding profiles see configuring transcoding profiles for ndi sources docid\ pnh1oa3iwbosmwkitahbj ndi inputs can be resized but not padded with black bars enabling the “keep aspect ratio” checkbox in the transcoding profile will cause the transcoder to fail in the zixi broadcaster navigation menu, click the inputs tab in the menu bar, click new input the add a new input stream window is displayed select ndi for the input stream new ndi input enter the maximum concurrent connections to this stream from the max outputs drop down list default unlimited select the show in matrix check box to display this stream in the matrix (see using the matrix docid\ bp6mo9f2qbxmu6gurkog4 ) default selected select the log this stream checkbox if you would like to generate event logs for this input select the analyze checkbox if you would like to enable stream analysis for the input specify the stream parameters (see input stream parameters table docid 93defmo0e05mia1mowlxn ) if you want to specify billing codes to identify and differentiate traffic on a zixi broadcaster for billing purposes, select this checkbox ( see input stream parameters table docid 93defmo0e05mia1mowlxn below) if you want to enable time shift, select this checkbox ( see input stream parameters table docid 93defmo0e05mia1mowlxn ) if you want to enable multicast on pull outputs , select this checkbox ( see input stream parameters table docid 93defmo0e05mia1mowlxn ) if you want to enable encryption , select this checkbox ( see input stream parameters table docid 93defmo0e05mia1mowlxn ) for more information, see encrypting an input stream in zixi broadcaster docid\ v3ryrbn08r4cojwl wvoq if you want to configure the recording parameters , specify them in the respective fields ( see input stream parameters table docid 93defmo0e05mia1mowlxn ) click ok the “input added” message appears at the top of the screen the ndi stream is added to the zixi broadcaster and now appears in the list of streams available in the zixi broadcaster inputs screen input stream parameters table parameter description stream parameters stream select one of the ndi streams available based on your configuration from the drop down menu on a local area network, ndi will use the discovery mechanism to advertise the sources, and zixi broadcaster will automatically discover these streams to make the streams discoverable in the cloud, you need to deploy an ndi discovery server and configure the ndi plug in with the settings mentioned above video profile select an existing transcoding video profile, or select remove stream if you want to remove the video track audio profile select an existing transcoding audio profile, or select remove stream if you want to remove the audio track timing audio reference level \[db] this parameter attenuates the audio level by the specified level in db this setting is used to prevent audio clipping transport stream bitrate \[kbps] specify the bitrate of the transport stream this parameter is optional if you do not specify a ts bitrate, the stream will be vbr if you specify a bitrate, the stream will be cbr the bitrate value must be compatible with the selected profile add rtp headers select this checkbox to add rtp headers to the stream rtp adds a 12 byte header, which includes a sequence number and a timestamp that can be used to detect dropped packets the sequence number in the rtp headers can be used to do automatic reordering, and the timestamps can help overcome inter packet gaps, also known as iat (inter arrival time) however, plain rtp does not feature error recovery or error protection by default, the rtp headers (which include the timestamps and sequences) are used on the input side, but then they are stripped off, and they no longer propagate to outputs smoothing buffer the smoothing feature uses a buffer to time packets according to the stream's clock this is useful when there are bursts in the rate at which the stream arrives the smoothing feature creates a queue in the buffer, allowing smoother entry into the broadcaster the smoothing parameter defines the size of the buffer in milliseconds a larger buffer enables smoother entry; however, it may influence the latency rate enable time shift select this checkbox to record the stream content and broadcast it after a specified delay to deploy an input stream that uses the current stream's time shift, you need to configure a "delayed" input stream, see adding delayed streams docid\ zp5ql 5kthhdphmrhddhe maximum delay \[hh\ mm\ ss] specify the time of the delayed transmission of this stream maximum 24 hours enable multicast on pull outputs select this checkbox to enable the transmission of this stream’s outputs as multicast a zixi receiver that will pull the stream will receive it in multicast by default, zixi broadcaster is configured to allow transparent fallback to unicast if it is out of the lan requires enabling multicast pull in the settings multicast only selecting this checkbox will force the transmission of this stream only in multicast enable encryption select this checkbox to encrypt the input stream the stream encryption prevents any further processing, such as analysis, transcoding, etc the encryption works in the following way if the stream has been encrypted at the source the stream will remain encrypted regardless of the output type zixi broadcaster can only encrypt the stream after it has been decrypted if the stream is being encrypted by the zixi broadcaster it will be encrypted only if the output is a zixi pull or zixi push output all other outputs will send out an unencrypted stream for more information, see encrypting an input stream in zixi broadcaster docid\ v3ryrbn08r4cojwl wvoq encryption type (for encryption enabled) specify the type of encryption (aes 128/192/256) encryption key (for encryption enabled) click generate to generate an encryption key the generated encryption key must be sent to the end user to decipher the received encoded stream recording parameters select this checkbox to customize the recording parameters destination type select the radio button for the desired storage type and then fill in the relevant parameters record to disk – the recording is saved on the local disk it is possible to record to an external destination by replacing the default storage location with a symbolic link to learn more, see the using an external storage docid\ z2amp6 fj7crckkfqrthq section record to s3 – the file is saved to your aws s3 bucket the mechanism uses aws multipart upload amazon advises defining a lifetime rule for objects in the destination bucket record to disk parameters file name template specify the file name pattern that zixi will use to generate when saving the recorded content a separate file will be generated for each recording up to the time specified in the max recorded file duration parameter (see above) after this duration, a new file will be generated the file name pattern can include any string and up to five variables listed below only the %t=hh mm ss creation time is mandatory you can change the order of these variables and add text as long as you maintain the legitimate structure of the file in linux and windows %s=stream id optional %y=year optional %m=month optional %d=day optional %t=hh mm ss creation time mandatory %u=yyyymmddthhmmssz utc timestamp optional for example, the following pattern %y recording%t ts will generate the following file name 2017 recording15 32 35 ts max recorded file duration \[hours] specify the maximum time allotted for recording a video stream default 2 hours keep recorded files for \[hours] specify the maximum time for storing the recording default 0 hours custom path optionally specify a storage location for the recorded files that is relative to the root folder this location bypasses the location specified as the root folder in the settings > general screen record to s3 parameters file name template specify the file name pattern that zixi will use to generate when saving the recorded content a separate file will be generated for each recording up to the time specified in the max recorded file duration parameter (see above) after this duration, a new file will be generated the file name pattern can include any string and up to five variables listed below only the %t=hh mm ss creation time is mandatory you can change the order of these variables and add text as long as you maintain the legitimate structure of the file in linux and windows %s=stream id optional %y=year optional %m=month optional %d=day optional %t=hh mm ss creation time mandatory %u=yyyymmddthhmmssz utc timestamp optional for example, the following pattern %y recording%t ts will generate the following file name 2017 recording15 32 35 ts max recorded file duration \[hours] specify the maximum time allotted for recording a video stream default 2 hours url specify the url of the s3 bucket ignore tls certificate errors tls certificate for s3 bucket might be detected as faulty if bucket name contains dot\[s] when this option is selected, zixi broadcaster will ignore the tls certificate errors and transmit the stream to its destination access key the access key that is used for accessing the s3 bucket secret key the secret key that is used for accessing the s3 bucket advanced mode parameters maximal dts pcr delta refers to the maximum allowable difference between the decoding time stamp (dts) and the program clock reference (pcr) in an mpeg 2 transport stream (ts) this delta is crucial for maintaining synchronization between the encoder and decoder, ensuring smooth playback without buffering issues or timing errors recommended setting 1000 (ms) allow 4 4 4 chroma subsampling refers to enabling full chroma resolution in a video signal, meaning that color information is preserved at the highest quality without compression compression compress the stream if possible to reduce bandwidth fast connect dynamically minimize latency advanced mode the fields discussed below are optional and available only in advanced mode to enter advanced mode add the url parameter ?advanced=1 to the zixi broadcaster url in your browser and press enter/return to reload the page note the advanced mode settings are generally intended for advanced users and special cases if you do not understand the settings, you should probably accept the default values ndi input advanced fields scte 35 the most commonly used advanced settings are those which relate to scte markers support scte 35 injection select this if you want to be able to insert your own scte 35 messages for such purposes as inserting a preroll or ad break scte 35 pid you can specify a specific pid for scte 35 injection, or leave it at the default auto value remove old scte 35 packets if you are inserting new scte 35 messages, it's a good idea to remove any old ones, unless you know what they are and that they need to stay timeout for number of ms to wait for a null packet to insert scte 35 (keeps the stream cbr) latency offset latency offset is a configuration parameter that delays the processing of a transport stream by a defined amount of time (in milliseconds) this delay is not arbitrary—it serves specific operational goals scte 35 cue injection and pre roll support in broadcast workflows, scte 35 markers signal ad breaks or content insertion points by applying a latency offset, the system can inject scte 35 packets ahead of playback , ensuring accurate timing for ad insertion or blackout triggers this is critical for compliance and monetization workflows example zixi broadcaster introduced latency offset to enable scte 35 insertion after the offset for pre roll scenarios stream normalization and timeline alignment hls inputs often arrive with irregular timestamps (pcr, pts, dts) or discontinuities adding a latency offset gives the system time to buffer and normalize segments , repair timeline irregularities, and remultiplex into a stable mpeg ts output this prevents audio drift and switching errors downstream smooth buffering for burst handling when upstream encoders send data in bursts, latency offset combined with buffering helps maintain a steady flow into the broadcaster this avoids jitter and packet timing issues that could disrupt adaptive bitrate workflows