Stream.xml

Used to configure security options and content protection of a specific channel. This file is located in the <httporigin-install-dir>/conf/containers/_default_/streams/_default_ directory.

The stream.xml file also contains the following configuration parameters:

<Config> 

<!-- The duration of the content window (in decimal fractions of hours). 
Fragments will be removed as they roll out of the window. A value of 0.0 
disables disk management. -->  

<DiskManagementDuration>3.0</DiskManagementDuration> 

<!-- (Optional) Auth security applied to processing inbound PUT/POST/DELETE 
requests. -->  

<Auth>  

<!-- If the 'SecurityToken' element is present, then an auth test is applied 
to all inbound PUT/POST requests that will check for a valid X-Adobe-HDS-Token 
or X-Adobe-HTTP-Token request header with a valid token value. Requests not 
containing this header or passing an invalid or timed-out token value receive 
an error response of 401 Not Authorized. If the <SecurityToken> element is not 
present, this check is not performed. --> 

<!-- <SecurityToken> If <SecurityToken> element is enabled, it requires a valid 
AES-128 key to use for Token value encryption/decryption, and only Packager(s) 
configures with matching key can write to this Origin. 
<Key>4ff4756ed68239d34d482dbc88819abc</Key> --> 

<!-- Optional 'Timeout' for Token values in seconds. Default value is 600 
seconds (10 minutes). If enabled, this value needs to be applied consistently here
as well as at the Packager. --> 

<!-- <Timeout>600</Timeout> --> 
<!-- </SecurityToken> --> 
<!-- If the 'DeleteSecurityToken' element is present, then an auth test is applied 
to all inbound DELETE requests that will check for a valid X-Adobe-HDS-Token or 
X-Adobe-HTTP-Token request header with a valid token value. Requests not 
containing this header or passing an invalid or timed-out token value receive an 
error response of 401 Not Authorized. If the <DeleteSecurityToken> element is not 
present, this check is not performed. --> 

<!-- <DeleteSecurityToken> If <DeleteSecurityToken> element is enabled, it requires 
a valid AES-128 key to use for Token value encryption/decryption, and only clients 
configured with matching key can delete from this Origin. 
<Key>4ff4756ed68239d34d482dbc88819abc</Key> --> 

<!-- Optional 'Timeout' for Token values in seconds. Default value is 600 seconds
(10 minutes). If enabled, this value needs to be applied consistently here as well 
as at the Packager. --> 

<!-- <Timeout>600</Timeout> --> 
<!-- </DeleteSecurityToken> --> 

</Auth> 

<HttpConfig>    

<!-- Uncomment following to override Server TTL settings for this stream.  
<Headers>  
	<TTL>  
		<F4M>0</F4M>  
		<Bootstrap>0</Bootstrap>  
		<M3U8>0</M3U8>
		<Timeline>0</Timeline>
		<DashManifest>0</DashManifest> 
		<DashManifestPart>0</DashManifestPart> 
	</TTL> 
</Headers> -->

</HttpConfig>

<!-- 
Uncomment the following to enable Fault tolerance support for this stream. 
These options are useful for fault tolerance in workflow involving Just-In-Time 
HLS generation from HDS artifacts, when redundant servers are deployed for this 
stream. When <FaultTolerance> tag exists, then the contained tags are enabled with 
the default values listed below.

MultiServerManifestSyncEnabled: Set it to true if this stream will be served from 
multiple origins using 503-failover-proxy-setup (as described in 
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/
adobe-media-server/pdfs/rock-solid-live-streaming.pdf)

It turns on inclusion of entries of fragments in the JIT created M3U8 that might 
be missing on the local origin server, but may be present on any other origin 
server. When this is set, HLS manifest is updated using the HDS manifest pushed 
from the packager and can recover the fragments missed while origin was 
down.

MaxLagFromLiveEdge: Live edge of JIT created HLS stream will lag that of 
source HDS by at most the amount (in integral seconds) specified by this option. 
It is assumed to be 0 if<MultiServerManifestSyncEnabled> is not enabled. In 
practice, JIT HLS will lag HDS only when some fragment is found missing, otherwise 
it will be near the live edge.If the packagers (sources of HDS fragments) are not 
in sync exactly, then this option allows recovery from the other packager if the 
leading packager drops or is unable to push a fragment, and the slower packager 
manages to send the missing fragment within the configured threshold lag.

ConstantLagFromLiveEdge: It shifts the live edge to delay the JIT HLS stream. It 
should be set to a value (in seconds) by which the fragments can arrive out of 
order, for example: when Packager is configured to push the fragments in parallel 
as soon as they are created rather than serially (waiting for previous one to be 
sent, before pushing next fragment).

MaxLagFromLiveEdge will apply on top of the delay set in ConstantLagFromLiveEdge, 
so effectively JIT HLS stream is constantly delayed by ConstantLagFromLiveEdge and 
can incur a maximum delay of(ConstantLagFromLiveEdge + MaxLagFromLiveEdge) on 
occurrence of gap.
-->

<!-- 
<FaultTolerance>   
	<MultiServerManifestSyncEnabled> true </MultiServerManifestSyncEnabled>   
	<MaxLagFromLiveEdge> 10 </MaxLagFromLiveEdge>   
	<ConstantLagFromLiveEdge> 0 </ConstantLagFromLiveEdge> 
</FaultTolerance>
-->

<!-- The format of cue info to be added in the JIT generated f4m/m3u8. -->                
<CueMode>DPIScte35</CueMode></Config>