<!doctype html><html lang="en">
 <head>
  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  <title>Specification of Live Media Ingest</title>
  <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
<style data-fill-with="stylesheet">/******************************************************************************
 *                   Style sheet for the W3C specifications                   *
 *
 * Special classes handled by this style sheet include:
 *
 * Indices
 *   - .toc for the Table of Contents (<ol class="toc">)
 *     + <span class="secno"> for the section numbers
 *   - #toc for the Table of Contents (<nav id="toc">)
 *   - ul.index for Indices (<a href="#ref">term</a><span>, in §N.M</span>)
 *   - table.index for Index Tables (e.g. for properties or elements)
 *
 * Structural Markup
 *   - table.data for general data tables
 *     -> use 'scope' attribute, <colgroup>, <thead>, and <tbody> for best results !
 *     -> use <table class='complex data'> for extra-complex tables
 *     -> use <td class='long'> for paragraph-length cell content
 *     -> use <td class='pre'> when manual line breaks/indentation would help readability
 *   - dl.switch for switch statements
 *   - ol.algorithm for algorithms (helps to visualize nesting)
 *   - .figure and .caption (HTML4) and figure and figcaption (HTML5)
 *     -> .sidefigure for right-floated figures
 *   - ins/del
 *
 * Code
 *   - pre and code
 *
 * Special Sections
 *   - .note       for informative notes             (div, p, span, aside, details)
 *   - .example    for informative examples          (div, p, pre, span)
 *   - .issue      for issues                        (div, p, span)
 *   - .assertion  for assertions                    (div, p, span)
 *   - .advisement for loud normative statements     (div, p, strong)
 *   - .annoying-warning for spec obsoletion notices (div, aside, details)
 *
 * Definition Boxes
 *   - pre.def   for WebIDL definitions
 *   - table.def for tables that define other entities (e.g. CSS properties)
 *   - dl.def    for definition lists that define other entitles (e.g. HTML elements)
 *
 * Numbering
 *   - .secno for section numbers in .toc and headings (<span class='secno'>3.2</span>)
 *   - .marker for source-inserted example/figure/issue numbers (<span class='marker'>Issue 4</span>)
 *   - ::before styled for CSS-generated issue/example/figure numbers:
 *     -> Documents wishing to use this only need to add
 *        figcaption::before,
 *        .caption::before { content: "Figure "  counter(figure) " ";  }
 *        .example::before { content: "Example " counter(example) " "; }
 *        .issue::before   { content: "Issue "   counter(issue) " ";   }
 *
 * Header Stuff (ignore, just don't conflict with these classes)
 *   - .head for the header
 *   - .copyright for the copyright
 *
 * Miscellaneous
 *   - .overlarge for things that should be as wide as possible, even if
 *     that overflows the body text area. This can be used on an item or
 *     on its container, depending on the effect desired.
 *     Note that this styling basically doesn't help at all when printing,
 *     since A4 paper isn't much wider than the max-width here.
 *     It's better to design things to fit into a narrower measure if possible.
 *   - js-added ToC jump links (see fixup.js)
 *
 ******************************************************************************/

/******************************************************************************/
/*                                   Body                                     */
/******************************************************************************/

	body {
		counter-reset: example figure issue;

		/* Layout */
		max-width: 50em;               /* limit line length to 50em for readability   */
		margin: 0 auto;                /* center text within page                     */
		padding: 1.6em 1.5em 2em 50px; /* assume 16px font size for downlevel clients */
		padding: 1.6em 1.5em 2em calc(26px + 1.5em); /* leave space for status flag     */

		/* Typography */
		line-height: 1.5;
		font-family: sans-serif;
		widows: 2;
		orphans: 2;
		word-wrap: break-word;
		overflow-wrap: break-word;
		hyphens: auto;

		/* Colors */
		color: black;
		background: white top left fixed no-repeat;
		background-size: 25px auto;
	}


/******************************************************************************/
/*                         Front Matter & Navigation                          */
/******************************************************************************/

/** Header ********************************************************************/

	div.head { margin-bottom: 1em }
	div.head hr { border-style: solid; }

	div.head h1 {
		font-weight: bold;
		margin: 0 0 .1em;
		font-size: 220%;
	}

	div.head h2 { margin-bottom: 1.5em;}

/** W3C Logo ******************************************************************/

	.head .logo {
		float: right;
		margin: 0.4rem 0 0.2rem .4rem;
	}

	.head img[src*="logos/W3C"] {
		display: block;
		border: solid #1a5e9a;
		border-width: .65rem .7rem .6rem;
		border-radius: .4rem;
		background: #1a5e9a;
		color: white;
		font-weight: bold;
	}

	.head a:hover > img[src*="logos/W3C"],
	.head a:focus > img[src*="logos/W3C"] {
		opacity: .8;
	}

	.head a:active > img[src*="logos/W3C"] {
		background: #c00;
		border-color: #c00;
	}

	/* see also additional rules in Link Styling section */

/** Copyright *****************************************************************/

	p.copyright,
	p.copyright small { font-size: small }

/** Back to Top / ToC Toggle **************************************************/

	@media print {
		#toc-nav {
			display: none;
		}
	}
	@media not print {
		#toc-nav {
			position: fixed;
			z-index: 2;
			bottom: 0; left: 0;
			margin: 0;
			min-width: 1.33em;
			border-top-right-radius: 2rem;
			box-shadow: 0 0 2px;
			font-size: 1.5em;
			color: black;
		}
		#toc-nav > a {
			display: block;
			white-space: nowrap;

			height: 1.33em;
			padding: .1em 0.3em;
			margin: 0;

			background: white;
			box-shadow: 0 0 2px;
			border: none;
			border-top-right-radius: 1.33em;
			background: white;
		}
		#toc-nav > #toc-jump {
			padding-bottom: 2em;
			margin-bottom: -1.9em;
		}

		#toc-nav > a:hover,
		#toc-nav > a:focus {
			background: #f8f8f8;
		}
		#toc-nav > a:not(:hover):not(:focus) {
			color: #707070;
		}

		/* statusbar gets in the way on keyboard focus; remove once browsers fix */
		#toc-nav > a[href="#toc"]:not(:hover):focus:last-child {
			padding-bottom: 1.5rem;
		}

		#toc-nav:not(:hover) > a:not(:focus) > span + span {
			/* Ideally this uses :focus-within on #toc-nav */
			display: none;
		}
		#toc-nav > a > span + span {
			padding-right: 0.2em;
		}

		#toc-toggle-inline {
			vertical-align: 0.05em;
			font-size: 80%;
			color: gray;
			color: hsla(203,20%,40%,.7);
			border-style: none;
			background: transparent;
			position: relative;
		}
		#toc-toggle-inline:hover:not(:active),
		#toc-toggle-inline:focus:not(:active) {
			text-shadow: 1px 1px silver;
			top: -1px;
			left: -1px;
		}

		#toc-nav :active {
			color: #C00;
		}
	}

/** ToC Sidebar ***************************************************************/

	/* Floating sidebar */
	@media screen {
		body.toc-sidebar #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			max-width: 80%;
			max-width: calc(100% - 2em - 26px);
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body.toc-sidebar #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}
		body.toc-sidebar #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	/* Hide main scroller when only the ToC is visible anyway */
	@media screen and (max-width: 28em) {
		body.toc-sidebar {
			overflow: hidden;
		}
	}

	/* Sidebar with its own space */
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body:not(.toc-inline) #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}

		body:not(.toc-inline) {
			padding-left: 29em;
		}
		/* See also Overflow section at the bottom */

		body:not(.toc-inline) #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) {
			margin: 0 4em;
		}
	}

/******************************************************************************/
/*                                Sectioning                                  */
/******************************************************************************/

/** Headings ******************************************************************/

	h1, h2, h3, h4, h5, h6, dt {
		page-break-after: avoid;
		page-break-inside: avoid;
		font: 100% sans-serif;   /* Reset all font styling to clear out UA styles */
		font-family: inherit;    /* Inherit the font family. */
		line-height: 1.2;        /* Keep wrapped headings compact */
		hyphens: manual;         /* Hyphenated headings look weird */
	}

	h2, h3, h4, h5, h6 {
		margin-top: 3rem;
	}

	h1, h2, h3 {
		color: #005A9C;
		background: transparent;
	}

	h1 { font-size: 170%; }
	h2 { font-size: 140%; }
	h3 { font-size: 120%; }
	h4 { font-weight: bold; }
	h5 { font-style: italic; }
	h6 { font-variant: small-caps; }
	dt { font-weight: bold; }

/** Subheadings ***************************************************************/

	h1 + h2,
	#subtitle {
		/* #subtitle is a subtitle in an H2 under the H1 */
		margin-top: 0;
	}
	h2 + h3,
	h3 + h4,
	h4 + h5,
	h5 + h6 {
		margin-top: 1.2em; /* = 1 x line-height */
	}

/** Section divider ***********************************************************/

	:not(.head) > hr {
		font-size: 1.5em;
		text-align: center;
		margin: 1em auto;
		height: auto;
		border: transparent solid 0;
		background: transparent;
	}
	:not(.head) > hr::before {
		content: "\2727\2003\2003\2727\2003\2003\2727";
	}

/******************************************************************************/
/*                            Paragraphs and Lists                            */
/******************************************************************************/

	p {
		margin: 1em 0;
	}

	dd > p:first-child,
	li > p:first-child {
		margin-top: 0;
	}

	ul, ol {
		margin-left: 0;
		padding-left: 2em;
	}

	li {
		margin: 0.25em 0 0.5em;
		padding: 0;
	}

	dl dd {
		margin: 0 0 .5em 2em;
	}

	.head dd + dd { /* compact for header */
		margin-top: -.5em;
	}

	/* Style for algorithms */
	ol.algorithm ol:not(.algorithm),
	.algorithm > ol ol:not(.algorithm) {
	 border-left: 0.5em solid #DEF;
	}

	/* Put nice boxes around each algorithm. */
	[data-algorithm]:not(.heading) {
	  padding: .5em;
	  border: thin solid #ddd; border-radius: .5em;
	  margin: .5em calc(-0.5em - 1px);
	}
	[data-algorithm]:not(.heading) > :first-child {
	  margin-top: 0;
	}
	[data-algorithm]:not(.heading) > :last-child {
	  margin-bottom: 0;
	}

	/* Style for switch/case <dl>s */
	dl.switch > dd > ol.only,
	dl.switch > dd > .only > ol {
	 margin-left: 0;
	}
	dl.switch > dd > ol.algorithm,
	dl.switch > dd > .algorithm > ol {
	 margin-left: -2em;
	}
	dl.switch {
	 padding-left: 2em;
	}
	dl.switch > dt {
	 text-indent: -1.5em;
	 margin-top: 1em;
	}
	dl.switch > dt + dt {
	 margin-top: 0;
	}
	dl.switch > dt::before {
	 content: '\21AA';
	 padding: 0 0.5em 0 0;
	 display: inline-block;
	 width: 1em;
	 text-align: right;
	 line-height: 0.5em;
	}

/** Terminology Markup ********************************************************/


/******************************************************************************/
/*                                 Inline Markup                              */
/******************************************************************************/

/** Terminology Markup ********************************************************/
	dfn   { /* Defining instance */
		font-weight: bolder;
	}
	a > i { /* Instance of term */
		font-style: normal;
	}
	dt dfn code, code.idl {
		font-size: medium;
	}
	dfn var {
		font-style: normal;
	}

/** Change Marking ************************************************************/

	del { color: red;  text-decoration: line-through; }
	ins { color: #080; text-decoration: underline;    }

/** Miscellaneous improvements to inline formatting ***************************/

	sup {
		vertical-align: super;
		font-size: 80%
	}

/******************************************************************************/
/*                                    Code                                    */
/******************************************************************************/

/** General monospace/pre rules ***********************************************/

	pre, code, samp {
		font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;
		font-size: .9em;
		page-break-inside: avoid;
		hyphens: none;
		text-transform: none;
	}
	pre code,
	code code {
		font-size: 100%;
	}

	pre {
		margin-top: 1em;
		margin-bottom: 1em;
		overflow: auto;
	}

/** Inline Code fragments *****************************************************/

  /* Do something nice. */

/******************************************************************************/
/*                                    Links                                   */
/******************************************************************************/

/** General Hyperlinks ********************************************************/

	/* We hyperlink a lot, so make it less intrusive */
	a[href] {
		color: #034575;
		text-decoration: none;
		border-bottom: 1px solid #707070;
		/* Need a bit of extending for it to look okay */
		padding: 0 1px 0;
		margin: 0 -1px 0;
	}
	a:visited {
		border-bottom-color: #BBB;
	}

	/* Use distinguishing colors when user is interacting with the link */
	a[href]:focus,
	a[href]:hover {
		background: #f8f8f8;
		background: rgba(75%, 75%, 75%, .25);
		border-bottom-width: 3px;
		margin-bottom: -2px;
	}
	a[href]:active {
		color: #C00;
		border-color: #C00;
	}

	/* Backout above styling for W3C logo */
	.head .logo,
	.head .logo a {
		border: none;
		text-decoration: none;
		background: transparent;
	}

/******************************************************************************/
/*                                    Images                                  */
/******************************************************************************/

	img {
		border-style: none;
	}

	/* For autogen numbers, add
	   .caption::before, figcaption::before { content: "Figure " counter(figure) ". "; }
	*/

	figure, .figure, .sidefigure {
		page-break-inside: avoid;
		text-align: center;
		margin: 2.5em 0;
	}
	.figure img,    .sidefigure img,    figure img,
	.figure object, .sidefigure object, figure object {
		max-width: 100%;
		margin: auto;
	}
	.figure pre, .sidefigure pre, figure pre {
		text-align: left;
		display: table;
		margin: 1em auto;
	}
	.figure table, figure table {
		margin: auto;
	}
	@media screen and (min-width: 20em) {
		.sidefigure {
			float: right;
			width: 50%;
			margin: 0 0 0.5em 0.5em
		}
	}
	.caption, figcaption, caption {
		font-style: italic;
		font-size: 90%;
	}
	.caption::before, figcaption::before, figcaption > .marker {
		font-weight: bold;
	}
	.caption, figcaption {
		counter-increment: figure;
	}

	/* DL list is indented 2em, but figure inside it is not */
	dd > .figure, dd > figure { margin-left: -2em }

/******************************************************************************/
/*                             Colored Boxes                                  */
/******************************************************************************/

	.issue, .note, .example, .assertion, .advisement, blockquote {
		padding: .5em;
		border: .5em;
		border-left-style: solid;
		page-break-inside: avoid;
	}
	span.issue, span.note {
		padding: .1em .5em .15em;
		border-right-style: solid;
	}

	.issue,
	.note,
	.example,
	.advisement,
	.assertion,
	blockquote {
		margin: 1em auto;
	}
	.note  > p:first-child,
	.issue > p:first-child,
	blockquote > :first-child {
		margin-top: 0;
	}
	blockquote > :last-child {
		margin-bottom: 0;
	}

/** Blockquotes ***************************************************************/

	blockquote {
		border-color: silver;
	}

/** Open issue ****************************************************************/

	.issue {
		border-color: #E05252;
		background: #FBE9E9;
		counter-increment: issue;
		overflow: auto;
	}
	.issue::before, .issue > .marker {
		text-transform: uppercase;
		color: #AE1E1E;
		padding-right: 1em;
		text-transform: uppercase;
	}
	/* Add .issue::before { content: "Issue " counter(issue) " "; } for autogen numbers,
	   or use class="marker" to mark up the issue number in source. */

/** Example *******************************************************************/

	.example {
		border-color: #E0CB52;
		background: #FCFAEE;
		counter-increment: example;
		overflow: auto;
		clear: both;
	}
	.example::before, .example > .marker {
		text-transform: uppercase;
		color: #827017;
		min-width: 7.5em;
		display: block;
	}
	/* Add .example::before { content: "Example " counter(example) " "; } for autogen numbers,
	   or use class="marker" to mark up the example number in source. */

/** Non-normative Note ********************************************************/

	.note {
		border-color: #52E052;
		background: #E9FBE9;
		overflow: auto;
	}

	.note::before, .note > .marker,
	details.note > summary::before,
	details.note > summary > .marker {
		text-transform: uppercase;
		display: block;
		color: hsl(120, 70%, 30%);
	}
	/* Add .note::before { content: "Note"; } for autogen label,
	   or use class="marker" to mark up the label in source. */

	details.note > summary {
		display: block;
		color: hsl(120, 70%, 30%);
	}
	details.note[open] > summary {
		border-bottom: 1px silver solid;
	}

/** Assertion Box *************************************************************/
	/*  for assertions in algorithms */

	.assertion {
		border-color: #AAA;
		background: #EEE;
	}

/** Advisement Box ************************************************************/
	/*  for attention-grabbing normative statements */

	.advisement {
		border-color: orange;
		border-style: none solid;
		background: #FFEECC;
	}
	strong.advisement {
		display: block;
		text-align: center;
	}
	.advisement > .marker {
		color: #B35F00;
	}

/** Spec Obsoletion Notice ****************************************************/
	/* obnoxious obsoletion notice for older/abandoned specs. */

	details {
		display: block;
	}
	summary {
		font-weight: bolder;
	}

	.annoying-warning:not(details),
	details.annoying-warning:not([open]) > summary,
	details.annoying-warning[open] {
		background: #fdd;
		color: red;
		font-weight: bold;
		padding: .75em 1em;
		border: thick red;
		border-style: solid;
		border-radius: 1em;
	}
	.annoying-warning :last-child {
		margin-bottom: 0;
	}

@media not print {
	details.annoying-warning[open] {
		position: fixed;
		left: 1em;
		right: 1em;
		bottom: 1em;
		z-index: 1000;
	}
}

	details.annoying-warning:not([open]) > summary {
		text-align: center;
	}

/** Entity Definition Boxes ***************************************************/

	.def {
		padding: .5em 1em;
		background: #DEF;
		margin: 1.2em 0;
		border-left: 0.5em solid #8CCBF2;
	}

/******************************************************************************/
/*                                    Tables                                  */
/******************************************************************************/

	th, td {
		text-align: left;
		text-align: start;
	}

/** Property/Descriptor Definition Tables *************************************/

	table.def {
		/* inherits .def box styling, see above */
		width: 100%;
		border-spacing: 0;
	}

	table.def td,
	table.def th {
		padding: 0.5em;
		vertical-align: baseline;
		border-bottom: 1px solid #bbd7e9;
	}

	table.def > tbody > tr:last-child th,
	table.def > tbody > tr:last-child td {
		border-bottom: 0;
	}

	table.def th {
		font-style: italic;
		font-weight: normal;
		padding-left: 1em;
		width: 3em;
	}

	/* For when values are extra-complex and need formatting for readability */
	table td.pre {
		white-space: pre-wrap;
	}

	/* A footnote at the bottom of a def table */
	table.def           td.footnote {
		padding-top: 0.6em;
	}
	table.def           td.footnote::before {
		content: " ";
		display: block;
		height: 0.6em;
		width: 4em;
		border-top: thin solid;
	}

/** Data tables (and properly marked-up index tables) *************************/
	/*
		 <table class="data"> highlights structural relationships in a table
		 when correct markup is used (e.g. thead/tbody, th vs. td, scope attribute)

		 Use class="complex data" for particularly complicated tables --
		 (This will draw more lines: busier, but clearer.)

		 Use class="long" on table cells with paragraph-like contents
		 (This will adjust text alignment accordingly.)
		 Alternately use class="longlastcol" on tables, to have the last column assume "long".
	*/

	table {
		word-wrap: normal;
		overflow-wrap: normal;
		hyphens: manual;
	}

	table.data,
	table.index {
		margin: 1em auto;
		border-collapse: collapse;
		border: hidden;
		width: 100%;
	}
	table.data caption,
	table.index caption {
		max-width: 50em;
		margin: 0 auto 1em;
	}

	table.data td,  table.data th,
	table.index td, table.index th {
		padding: 0.5em 1em;
		border-width: 1px;
		border-color: silver;
		border-top-style: solid;
	}

	table.data thead td:empty {
		padding: 0;
		border: 0;
	}

	table.data  thead,
	table.index thead,
	table.data  tbody,
	table.index tbody {
		border-bottom: 2px solid;
	}

	table.data colgroup,
	table.index colgroup {
		border-left: 2px solid;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		border-right: 2px solid;
		border-top: 1px solid silver;
		padding-right: 1em;
	}

	table.data th[colspan],
	table.data td[colspan] {
		text-align: center;
	}

	table.complex.data th,
	table.complex.data td {
		border: 1px solid silver;
		text-align: center;
	}

	table.data.longlastcol td:last-child,
	table.data td.long {
	 vertical-align: baseline;
	 text-align: left;
	}

	table.data img {
		vertical-align: middle;
	}


/*
Alternate table alignment rules

	table.data,
	table.index {
		text-align: center;
	}

	table.data  thead th[scope="row"],
	table.index thead th[scope="row"] {
		text-align: right;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		text-align: right;
	}

Possible extra rowspan handling

	table.data  tbody th[rowspan]:not([rowspan='1']),
	table.index tbody th[rowspan]:not([rowspan='1']),
	table.data  tbody td[rowspan]:not([rowspan='1']),
	table.index tbody td[rowspan]:not([rowspan='1']) {
		border-left: 1px solid silver;
	}

	table.data  tbody th[rowspan]:first-child,
	table.index tbody th[rowspan]:first-child,
	table.data  tbody td[rowspan]:first-child,
	table.index tbody td[rowspan]:first-child{
		border-left: 0;
		border-right: 1px solid silver;
	}
*/

/******************************************************************************/
/*                                  Indices                                   */
/******************************************************************************/


/** Table of Contents *********************************************************/

	.toc a {
		/* More spacing; use padding to make it part of the click target. */
		padding-top: 0.1rem;
		/* Larger, more consistently-sized click target */
		display: block;
		/* Reverse color scheme */
		color: black;
		border-color: #3980B5;
		border-bottom-width: 3px !important;
		margin-bottom: 0px !important;
	}
	.toc a:visited {
		border-color: #054572;
	}
	.toc a:not(:focus):not(:hover) {
		/* Allow colors to cascade through from link styling */
		border-bottom-color: transparent;
	}

	.toc, .toc ol, .toc ul, .toc li {
		list-style: none; /* Numbers must be inlined into source */
		/* because generated content isn't search/selectable and markers can't do multilevel yet */
		margin:  0;
		padding: 0;
		line-height: 1.1rem; /* consistent spacing */
	}

	/* ToC not indented until third level, but font style & margins show hierarchy */
	.toc > li             { font-weight: bold;   }
	.toc > li li          { font-weight: normal; }
	.toc > li li li       { font-size:   95%;    }
	.toc > li li li li    { font-size:   90%;    }
	.toc > li li li li .secno { font-size: 85%; }
	.toc > li li li li li { font-size:   85%;    }
	.toc > li li li li li .secno { font-size: 100%; }

	/* @supports not (display:grid) { */
		.toc > li             { margin: 1.5rem 0;    }
		.toc > li li          { margin: 0.3rem 0;    }
		.toc > li li li       { margin-left: 2rem;   }

		/* Section numbers in a column of their own */
		.toc .secno {
			float: left;
			width: 4rem;
			white-space: nowrap;
		}

		.toc li {
			clear: both;
		}

		:not(li) > .toc              { margin-left:  5rem; }
		.toc .secno                  { margin-left: -5rem; }
		.toc > li li li .secno       { margin-left: -7rem; }
		.toc > li li li li .secno    { margin-left: -9rem; }
		.toc > li li li li li .secno { margin-left: -11rem; }

		/* Tighten up indentation in narrow ToCs */
		@media (max-width: 30em) {
			:not(li) > .toc              { margin-left:  4rem; }
			.toc .secno                  { margin-left: -4rem; }
			.toc > li li li              { margin-left:  1rem; }
			.toc > li li li .secno       { margin-left: -5rem; }
			.toc > li li li li .secno    { margin-left: -6rem; }
			.toc > li li li li li .secno { margin-left: -7rem; }
		}
	/* } */

	@supports (display:grid) {
		/* Use #toc over .toc to override non-@supports rules. */
		#toc {
			display: grid;
			align-content: start;
			grid-template-columns: auto 1fr;
			grid-column-gap: 1rem;
			column-gap: 1rem;
			grid-row-gap: .6rem;
			row-gap: .6rem;
		}
		#toc h2 {
			grid-column: 1 / -1;
			margin-bottom: 0;
		}
		#toc ol,
		#toc li,
		#toc a {
			display: contents;
			/* Switch <a> to subgrid when supported */
		}
		#toc span {
			margin: 0;
		}
		#toc > .toc > li > a > span {
			/* The spans of the top-level list,
			   comprising the first items of each top-level section. */
			margin-top: 1.1rem;
		}
		#toc#toc .secno { /* Ugh, need more specificity to override base.css */
			grid-column: 1;
			width: auto;
			margin-left: 0;
		}
		#toc .content {
			grid-column: 2;
			width: auto;
			margin-right: 1rem;
		}
		#toc .content:hover {
			background: rgba(75%, 75%, 75%, .25);
			border-bottom: 3px solid #054572;
			margin-bottom: -3px;
		}
		#toc li li li .content {
			margin-left: 1rem;
		}
		#toc li li li li .content {
			margin-left: 2rem;
		}
	}


/** Index *********************************************************************/

	/* Index Lists: Layout */
	ul.index       { margin-left: 0; columns: 15em; text-indent: 1em hanging; }
	ul.index li    { margin-left: 0; list-style: none; break-inside: avoid; }
	ul.index li li { margin-left: 1em }
	ul.index dl    { margin-top: 0; }
	ul.index dt    { margin: .2em 0 .2em 20px;}
	ul.index dd    { margin: .2em 0 .2em 40px;}
	/* Index Lists: Typography */
	ul.index ul,
	ul.index dl { font-size: smaller; }
	@media not print {
		ul.index li span {
			white-space: nowrap;
			color: transparent; }
		ul.index li a:hover + span,
		ul.index li a:focus + span {
			color: #707070;
		}
	}

/** Index Tables *****************************************************/
	/* See also the data table styling section, which this effectively subclasses */

	table.index {
		font-size: small;
		border-collapse: collapse;
		border-spacing: 0;
		text-align: left;
		margin: 1em 0;
	}

	table.index td,
	table.index th {
		padding: 0.4em;
	}

	table.index tr:hover td:not([rowspan]),
	table.index tr:hover th:not([rowspan]) {
		background: #f7f8f9;
	}

	/* The link in the first column in the property table (formerly a TD) */
	table.index th:first-child a {
		font-weight: bold;
	}

/******************************************************************************/
/*                                    Print                                   */
/******************************************************************************/

	@media print {
		/* Pages have their own margins. */
		html {
			margin: 0;
		}
		/* Serif for print. */
		body {
			font-family: serif;
		}
	}
	@page {
		margin: 1.5cm 1.1cm;
	}

/******************************************************************************/
/*                                    Legacy                                  */
/******************************************************************************/

	/* This rule is inherited from past style sheets. No idea what it's for. */
	.hide { display: none }


/******************************************************************************/
/*                             Overflow Control                               */
/******************************************************************************/

	.figure .caption, .sidefigure .caption, figcaption {
		/* in case figure is overlarge, limit caption to 50em */
		max-width: 50rem;
		margin-left: auto;
		margin-right: auto;
	}
	.overlarge > table {
		/* limit preferred width of table */
		max-width: 50em;
		margin-left: auto;
		margin-right: auto;
	}

	@media (min-width: 55em) {
		.overlarge {
			margin-left: calc(13px + 26.5rem - 50vw);
			margin-right: calc(13px + 26.5rem - 50vw);
			max-width: none;
		}
	}
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) .overlarge {
			/* 30.5em body padding 50em content area */
			margin-left: calc(40em - 50vw) !important;
			margin-right: calc(40em - 50vw) !important;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) .overlarge {
			/* 4em html margin 30.5em body padding 50em content area */
			margin-left: 0 !important;
			margin-right: calc(84.5em - 100vw) !important;
		}
	}

	@media not print {
		.overlarge {
			overflow-x: auto;
			/* See Lea Verou's explanation background-attachment:
			 * http://lea.verou.me/2012/04/background-attachment-local/
			 *
			background: top left  / 4em 100% linear-gradient(to right,  #ffffff, rgba(255, 255, 255, 0)) local,
			            top right / 4em 100% linear-gradient(to left, #ffffff, rgba(255, 255, 255, 0)) local,
			            top left  / 1em 100% linear-gradient(to right,  #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            top right / 1em 100% linear-gradient(to left, #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            white;
			background-repeat: no-repeat;
			*/
		}
	}
</style>
  <meta content="Bikeshed version e0f6b8b749fa390ec1e89d64ac471d2710b038a2" name="generator">
  <link href="https://dashif.org/guidelines/" rel="canonical">
<style>/* style-md-lists */

/* This is a weird hack for me not yet following the commonmark spec
   regarding paragraph and lists. */
[data-md] > :first-child {
    margin-top: 0;
}
[data-md] > :last-child {
    margin-bottom: 0;
}</style>
<style>/* style-counters */

body {
    counter-reset: example figure issue;
}
.issue {
    counter-increment: issue;
}
.issue:not(.no-marker)::before {
    content: "Issue " counter(issue);
}

.example {
    counter-increment: example;
}
.example:not(.no-marker)::before {
    content: "Example " counter(example);
}
.invalid.example:not(.no-marker)::before,
.illegal.example:not(.no-marker)::before {
    content: "Invalid Example" counter(example);
}

figcaption {
    counter-increment: figure;
}
figcaption:not(.no-marker)::before {
    content: "Figure " counter(figure) " ";
}</style>
<style>/* style-dfn-panel */

.dfn-panel {
    position: absolute;
    z-index: 35;
    height: auto;
    width: -webkit-fit-content;
    width: fit-content;
    max-width: 300px;
    max-height: 500px;
    overflow: auto;
    padding: 0.5em 0.75em;
    font: small Helvetica Neue, sans-serif, Droid Sans Fallback;
    background: #DDDDDD;
    color: black;
    border: outset 0.2em;
}
.dfn-panel:not(.on) { display: none; }
.dfn-panel * { margin: 0; padding: 0; text-indent: 0; }
.dfn-panel > b { display: block; }
.dfn-panel a { color: black; }
.dfn-panel a:not(:hover) { text-decoration: none !important; border-bottom: none !important; }
.dfn-panel > b + b { margin-top: 0.25em; }
.dfn-panel ul { padding: 0; }
.dfn-panel li { list-style: inside; }
.dfn-panel.activated {
    display: inline-block;
    position: fixed;
    left: .5em;
    bottom: 2em;
    margin: 0 auto;
    max-width: calc(100vw - 1.5em - .4em - .5em);
    max-height: 30vh;
}

.dfn-paneled { cursor: pointer; }
</style>
<style>/* style-selflinks */

.heading, .issue, .note, .example, li, dt {
    position: relative;
}
a.self-link {
    position: absolute;
    top: 0;
    left: calc(-1 * (3.5rem - 26px));
    width: calc(3.5rem - 26px);
    height: 2em;
    text-align: center;
    border: none;
    transition: opacity .2s;
    opacity: .5;
}
a.self-link:hover {
    opacity: 1;
}
.heading > a.self-link {
    font-size: 83%;
}
li > a.self-link {
    left: calc(-1 * (3.5rem - 26px) - 2em);
}
dfn > a.self-link {
    top: auto;
    left: auto;
    opacity: 0;
    width: 1.5em;
    height: 1.5em;
    background: gray;
    color: white;
    font-style: normal;
    transition: opacity .2s, background-color .2s, color .2s;
}
dfn:hover > a.self-link {
    opacity: 1;
}
dfn > a.self-link:hover {
    color: black;
}

a.self-link::before            { content: "¶"; }
.heading > a.self-link::before { content: "§"; }
dfn > a.self-link::before      { content: "#"; }</style>
<style>/* style-autolinks */

.css.css, .property.property, .descriptor.descriptor {
    color: #005a9c;
    font-size: inherit;
    font-family: inherit;
}
.css::before, .property::before, .descriptor::before {
    content: "‘";
}
.css::after, .property::after, .descriptor::after {
    content: "’";
}
.property, .descriptor {
    /* Don't wrap property and descriptor names */
    white-space: nowrap;
}
.type { /* CSS value <type> */
    font-style: italic;
}
pre .property::before, pre .property::after {
    content: "";
}
[data-link-type="property"]::before,
[data-link-type="propdesc"]::before,
[data-link-type="descriptor"]::before,
[data-link-type="value"]::before,
[data-link-type="function"]::before,
[data-link-type="at-rule"]::before,
[data-link-type="selector"]::before,
[data-link-type="maybe"]::before {
    content: "‘";
}
[data-link-type="property"]::after,
[data-link-type="propdesc"]::after,
[data-link-type="descriptor"]::after,
[data-link-type="value"]::after,
[data-link-type="function"]::after,
[data-link-type="at-rule"]::after,
[data-link-type="selector"]::after,
[data-link-type="maybe"]::after {
    content: "’";
}

[data-link-type].production::before,
[data-link-type].production::after,
.prod [data-link-type]::before,
.prod [data-link-type]::after {
    content: "";
}

[data-link-type=element],
[data-link-type=element-attr] {
    font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace;
    font-size: .9em;
}
[data-link-type=element]::before { content: "<" }
[data-link-type=element]::after  { content: ">" }

[data-link-type=biblio] {
    white-space: pre;
}</style>
 <body class="h-entry">
  <div class="head">
   <p data-fill-with="logo"><a href="https://dashif.org/"><img src="Images/DASH-IF.png"></a> </p>
   <h1 class="p-name no-ref" id="title">Specification of Live Media Ingest</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Living Document, <time class="dt-updated" datetime="2019-04-23">23 April 2019</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt>This version:
     <dd><a class="u-url" href="https://dashif.org/guidelines/">https://dashif.org/guidelines/</a>
     <dt>Issue Tracking:
     <dd><a href="https://github.com/Dash-Industry-Forum/Ingest/issues">GitHub</a>
     <dt class="editor">Editors:
     <dd class="editor p-author h-card vcard"><span class="p-name fn">DASH IOP Ingest TF</span>
     <dd class="editor p-author h-card vcard"><span class="p-name fn"></span>
    </dl>
   </div>
   <div data-fill-with="warning"></div>
   <hr title="Separator for header">
  </div>
  <div data-fill-with="at-risk"></div>
  <nav data-fill-with="table-of-contents" id="toc">
   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
   <ol class="toc" role="directory">
    <li>
     <a href="#IngestSpec"><span class="secno">1</span> <span class="content">Specification: Live Media Ingest</span></a>
     <ol class="toc">
      <li><a href="#Abstract"><span class="secno">1.1</span> <span class="content">Abstract</span></a>
      <li><a href="#CopyRights"><span class="secno">1.2</span> <span class="content">Copyright Notice and Disclaimer</span></a>
     </ol>
    <li><a href="#Introduction"><span class="secno">2</span> <span class="content">Introduction</span></a>
    <li><a href="#conventions"><span class="secno">3</span> <span class="content">Conventions and Terminology</span></a>
    <li><a href="#workflow_and_use_cases"><span class="secno">4</span> <span class="content">Media Ingest Workflows and Profiles</span></a>
    <li><a href="#general"><span class="secno">5</span> <span class="content">General Ingest Protocol Behavior</span></a>
    <li>
     <a href="#profile_1"><span class="secno">6</span> <span class="content">Ingest Interface 1:  CMAF Ingest Protocol Behavior</span></a>
     <ol class="toc">
      <li><a href="#profile_1_general"><span class="secno">6.1</span> <span class="content">CMAF Ingest General Considerations</span></a>
      <li><a href="#general_Protocol_Requirements_p1"><span class="secno">6.2</span> <span class="content">General Protocol Requirements</span></a>
      <li><a href="#Requirements_for_formatting_Media_Tracks"><span class="secno">6.3</span> <span class="content">Requirements for Formatting Media Tracks</span></a>
      <li><a href="#Requirements_for_switchingsets"><span class="secno">6.4</span> <span class="content">Requirements for Signalling Switching Sets</span></a>
      <li><a href="#timed_text_and_subtitle_streams"><span class="secno">6.5</span> <span class="content">Requirements for Timed Text, Captions and Subtitle Streams</span></a>
      <li><a href="#timed_metadata"><span class="secno">6.6</span> <span class="content">Requirements for Timed Metadata</span></a>
      <li><a href="#failover"><span class="secno">6.7</span> <span class="content">Requirements for Media Processing Entity Failover and Connection Error Handling</span></a>
      <li><a href="#failover_source"><span class="secno">6.8</span> <span class="content">Requirements for Live Media Source Failover</span></a>
     </ol>
    <li>
     <a href="#dash_ingest"><span class="secno">7</span> <span class="content">Ingest Interface 2: DASH and HLS Ingest Protocol Behavior</span></a>
     <ol class="toc">
      <li>
       <a href="#DASH_General"><span class="secno">7.1</span> <span class="content">General requirements</span></a>
       <ol class="toc">
        <li><a href="#Industry_compliance"><span class="secno">7.1.1</span> <span class="content">Industry Compliance</span></a>
        <li><a href="#DASH_Ingest_HTTP"><span class="secno">7.1.2</span> <span class="content">HTTP connections</span></a>
        <li><a href="#DASH_Ingest_naming"><span class="secno">7.1.3</span> <span class="content">Unique segment and manifest naming</span></a>
        <li><a href="#DASH_Ingest_DNS_Lookups"><span class="secno">7.1.4</span> <span class="content">DNS lookups</span></a>
        <li><a href="#DASH_Ingest_Publisher_Identification"><span class="secno">7.1.5</span> <span class="content">Ingest source identification</span></a>
        <li><a href="#DASH_Ingest_Common_Failure_Behaviors"><span class="secno">7.1.6</span> <span class="content">Common Failure behaviors</span></a>
       </ol>
      <li>
       <a href="#HLS_Ingest_specific_requirements"><span class="secno">7.2</span> <span class="content">HLS specific requirements</span></a>
       <ol class="toc">
        <li><a href="#HLS_file_extensions_and_mime_types"><span class="secno">7.2.1</span> <span class="content">File extensions and mime-types</span></a>
        <li><a href="#Upload_order"><span class="secno">7.2.2</span> <span class="content">Upload order</span></a>
        <li><a href="#HLS_Ingest_Encryption"><span class="secno">7.2.3</span> <span class="content">Encryption</span></a>
        <li><a href="#HLS_Ingest_relative_paths"><span class="secno">7.2.4</span> <span class="content">Relative paths</span></a>
        <li><a href="#HLS_Ingest_Resiliency"><span class="secno">7.2.5</span> <span class="content">Resiliency</span></a>
       </ol>
      <li>
       <a href="#DASH_requirements"><span class="secno">7.3</span> <span class="content">DASH specific requirements</span></a>
       <ol class="toc">
        <li><a href="#DASH_mime_types_and_extensions"><span class="secno">7.3.1</span> <span class="content">File extensions and mime-types</span></a>
        <li><a href="#DASH_Relative_paths_and_extensions"><span class="secno">7.3.2</span> <span class="content">Relative paths</span></a>
       </ol>
      <li><a href="#CMAF_requirements"><span class="secno">7.4</span> <span class="content">CMAF specific requirements</span></a>
     </ol>
    <li><a href="#Example_ingest"><span class="secno">8</span> <span class="content">Illustrative Example of using CMAF and DASH ingest specification</span></a>
    <li><a href="#iana"><span class="secno">9</span> <span class="content">IANA Considerations</span></a>
    <li><a href="#contrib"><span class="secno">10</span> <span class="content">Acknowledgements</span></a>
    <li>
     <a href="#references_custom"><span class="secno">11</span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#references-url"><span class="secno">11.1</span> <span class="content">URL References</span></a>
     </ol>
    <li><a href="#conformance"><span class="secno"></span> <span class="content"> Conformance</span></a>
    <li>
     <a href="#index"><span class="secno"></span> <span class="content">Index</span></a>
     <ol class="toc">
      <li><a href="#index-defined-here"><span class="secno"></span> <span class="content">Terms defined by this specification</span></a>
     </ol>
    <li>
     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#normative"><span class="secno"></span> <span class="content">Normative References</span></a>
     </ol>
   </ol>
  </nav>
  <main>
   <h2 class="heading settled" data-level="1" id="IngestSpec"><span class="secno">1. </span><span class="content">Specification: Live Media Ingest</span><a class="self-link" href="#IngestSpec"></a></h2>
   <h3 class="heading settled" data-level="1.1" id="Abstract"><span class="secno">1.1. </span><span class="content">Abstract</span><a class="self-link" href="#Abstract"></a></h3>
   <p>This document presents the DASH-IF Live Media Ingest Protocol Specification.  Two protocol interfaces are defined. The first, interface 1, CMAF ingest, is based on fragmented MPEG-4 as defined by the common media application track format (CMAF). The second interface is based on MPEG DASH and HLS.
   Both Interfaces use the HTTP POST Method to transmit media objects from the ingest source to the receiving entity.
   Examples of live streaming workflows using these
   protocol interfaces are also presented. The protocol interfaces also support carriage of timed metadata and timed text. Guidelines for redundancy and failover are also included.</p>
   <h3 class="heading settled" data-level="1.2" id="CopyRights"><span class="secno">1.2. </span><span class="content">Copyright Notice and Disclaimer</span><a class="self-link" href="#CopyRights"></a></h3>
   <p>Please review these documents
   carefully, as they describe your rights and restrictions with  
   respect to this document.  Code Components extracted from this  
   document must include Simplified BSD License text as described  
   in Section 4.e of the Trust Legal Provisions and are provided  
   without warranty as described in the Simplified BSD License</p>
   <p>This is a document made available by DASH-IF. The technology
embodied in this document may involve the use of intellectual
property rights, including patents and patent applications owned
or controlled by any of the authors or developers of this document.
No patent license, either implied or express, is granted to you by
this document. DASH-IF has made no search or investigation for such
rights and DASH-IF disclaims any duty to do so. The rights and obligations
 which apply to DASH-IF documents, as such rights and obligations are set
 forth and defined in the DASH-IF Bylaws and IPR Policy including,
 but not limited to, patent and other intellectual property license
 rights and obligations. A copy of the DASH-IF Bylaws and IPR Policy
 can be obtained at http://dashif.org/.</p>
   <p>The material contained herein is provided on an AS IS basis and to the
maximum extent permitted by applicable law, this material is provided   
AS IS, and the authors and developers of this material and DASH-IF   
hereby disclaim all other warranties and conditions, either express,
implied or statutory, including, but not limited to, any (if any) implied  
warranties, duties or conditions of merchantability,
of fitness for a particular purpose, of accuracy or completeness of responses,
of workmanlike effort, and of lack of negligence.
In addition, this document may include references to documents and/or   
technologies controlled by third parties.
Those third party documents and technologies may be subject to third party   
rules and licensing terms. No intellectual property license, either implied or express,
to any third party material is granted to you by this document or DASH-IF.   
DASH-IF makes no any warranty whatsoever for such third party material.</p>
   <h2 class="heading settled" data-level="2" id="Introduction"><span class="secno">2. </span><span class="content">Introduction</span><a class="self-link" href="#Introduction"></a></h2>
   <p>The main goal of this specification is to define the
   interoperability point between an <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source">Ingest Source</a> and a <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity">Receiving entity</a> that typically reside
   in the cloud or the network. This specification does
   not impose any new constraints or requirements to clients
   that consume streams using any defined
   streaming protocol, with a preference for <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a></p>
   <p>Live media ingest happens between an <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source①">Ingest source</a>, such as a  live video encoder <a data-link-type="dfn" href="#live-encoder" id="ref-for-live-encoder">live encoder</a> and a <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity①">Receiving entity</a>.
   Examples of such a <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity②">Receiving entity</a> include media packagers,streaming origins and content delivery networks.
   The combination of ingest sources and
   distributed media processing entities  
   is common in practical video streaming deployments.  
   It allows media processing functionality to be distributed between entities.</p>
   <p>Nevertheless, in such deployments, interoperability between
   ingest sources and downstream processing  
   entities can sometimes be challenging.  
   This challenge comes from the fact that  
   there are multiple levels of interoperability.
   This challenge also comes from the fact that each vendor has a
   different view of what is expected/preferred as well as how various
   technical specifications apply.</p>
   <p>For example, the network protocol for transmission
   of data and the setup of the connectivity are important.  
   This includes schemes for establishing the ingest  
   connection, handling disconnects and failures,  
   providing procedures for reliably sending
   and receiving the data, and timely resolution of hostnames.</p>
   <p>A second level of interoperability lies
   in the media container and coded media formats.  
   The Moving Picture Experts Group defined several media  
   container formats such as <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> and <a data-link-type="biblio" href="#biblio-mpeg2ts">[MPEG2TS]</a> which are widely adopted and well supported.  
   However, these are general purpose formats,  
   targeting several different application areas.  
   To do so, they provide many different profiles and options.  
   Detailed interoperability is often achieved through  
   other application standards such as those for  
   the broadcast, storage or video on demand. For interoperable
   live media ingest, this document provides
   guidance on how to use <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> and <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a>.</p>
   <p>In addition, the codec and profile used,
   e.g. <a data-link-type="biblio" href="#biblio-mpeghevc">[MPEGHEVC]</a> are important  
   interoperability points that itself also  
   have different profiles and different
   configurations. This specification
   provides some guidance on how encoded
   media should be represented and transmitted.</p>
   <p>A third level of interoperability,
   lies in the way metadata is  
   inserted in streams. live  
   content often needs such metadata to signal  
   opportunities for ad insertion,  
   or other attributes like timed graphics or general
   information relating to the broadcast.  Examples  
   of such metadata include <a data-link-type="biblio" href="#biblio-scte35">[SCTE35]</a> markers which  
   are often found in broadcast streams and other  
   metadata such as ID3 tags <a data-link-type="biblio" href="#biblio-id3v2">[ID3v2]</a> relating to the
   media presentation.
   In fact, many more types of metadata relating
   to the live event might be ingested and passed
   on to an OTT workflow.</p>
   <p>Fourth, for live media, handling the timeline
   of the presentation consistently is important.  
   This includes sampling of media, avoiding  
   timeline discontinuities and synchronizing  
   timestamps attached by different ingest sources
   such as audio and video. In addition, media
   timeline discontinuities must be avoided as much as
   possible in normal operation. Further, when
   using redundant ingest sources, ingested
   streams must be sample accurately synchronized.
   Last, streams may need to be started at the same
   time as to avoid miss alignment between audio and video
   tracks.</p>
   <p>Fifth, in streaming workflows it is important
   to have support for failovers of both the ingest sources  
   and media processing entities. This is important  
   to avoid interruptions of 24/7 live services such  
   as Internet television where components may fail.</p>
   <p>In practical deployments, multiple ingest sources
   and media processing entities are often used. This requires  
   that multiple ingest sources and media processing
   entities work together in a redundant workflow where  
   some of the components might fail. Well defined
   failover behavior will help interoperability.</p>
   <p>This document provides a specification
   for establishing these interoperability points.
   The approaches are based on known standardized  
   technologies that have been tested and deployed  
   in several large scale streaming  
   deployments.</p>
   <p>Two key interfaces and their protocol specification have been
   identified.
   One mainly aims as a ingest format to packager
   or active media processor, while the second works mainly
   to ingest media streaming presentations to origin servers
   and or storage or content delivery network facilities.
   The section on interfaces and profiles provides more
   background and motivation around these two interfaces
   that both use HTTP POST.</p>
   <p>We further motivate the specification
   in this document supporting    
   HTTP 1.1 <a data-link-type="biblio" href="#biblio-rfc7235">[RFC7235]</a> and <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> a bit more.   
   We believe that Smooth streaming <a data-link-type="dfn" href="#ms-sstr" id="ref-for-ms-sstr">MS-SSTR</a> and HLS <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a> have shown that HTTP usage   
   can survive the Internet ecosystem for   
   media delivery. In addition, HTTP based   
   ingest fits well with current HTTP   
   based streaming protocols including <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a>.   
   In addition, there is good support for HTTP   
   middleboxes and HTTP routing available   
   making it easy to debug and trace errors.   
   The HTTP POST provides a push based   
   method for delivery for pushing the   
   live content when it becomes available.</p>
   <p>Regarding the transport protocol, in future versions,
   alternative transport protocols could be considered  
   advancing over HTTP 1.1 or TCP.
   We believe the proposed media format and protocol interfaces
   will provide the same benefits with other transports  
   protocols. Our view is that for current and near future  
   deployments using <a data-link-type="biblio" href="#biblio-rfc7235">[RFC7235]</a> is still a good approach.</p>
   <p>The document is structured as follows, in section 3
   we present the conventions and terminology used throughout   
   this document. In section 4 we present use cases and   
   workflows related to media ingest and the two profiles/interfaces   
   presented. Sections 5-9 will detail the protocol and   
   the two different interfaces defined.</p>
   <h2 class="heading settled" data-level="3" id="conventions"><span class="secno">3. </span><span class="content">Conventions and Terminology</span><a class="self-link" href="#conventions"></a></h2>
   <p>The following terminology is used in the rest of this document.</p>
   <p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this    
   document are to be interpreted as described in BCP 14, RFC 2119 <a data-link-type="biblio" href="#biblio-rfc2119">[RFC2119]</a>.</p>
   <p><strong>ISOBMFF</strong>: the ISO Base Media File Format specified in <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a>.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="cmaf-ingest"><strong>CMAF Ingest</strong></dfn>:
          Ingest interface defined in this specification for push based <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="dash-ingest"><strong>DASH Ingest</strong></dfn>:
          Ingest interface defined in this specification for push based <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="hls-ingest"><strong>HLS Ingest</strong></dfn>:
          Ingest interface defined in this specification for push based <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="ingest-stream"><strong>Ingest Stream</strong></dfn>:
          The stream of media pushed from the ingest source to the media processing entity</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="live-stream-event"><strong>Live stream event</strong></dfn>:
           The total live stream for the ingest relating to a broadcast event.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="live-encoder"><strong>Live encoder</strong></dfn>:
           Entity performing live  
           encoding of a high quality
           Ingest stream,  
           can serve as ingest source</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="ingest-source"><strong>Ingest source</strong></dfn>:
            A media source ingesting live media content to a receiving entity  
            , it is typically a live encoder but not restricted  
            to this, e.g. it could be a stored media resource.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="publishing-point"><strong>Publishing point</strong></dfn>:
              Entry point used to receive an ingest stream,  
              consumes/receives the incoming media <a data-link-type="dfn" href="#ingest-stream" id="ref-for-ingest-stream">ingest stream</a>,
              typically via a publishing URL setup to receive the stream</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="manifest-objects"><strong>Manifest objects</strong></dfn> Objects ingested that represent streaming manifest
	        e.g. .mpd in MPEG DASH, .m3u8 in HLS</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="Media objects" data-noexport id="media-objects"> <strong>Media objects</strong> </dfn> Objects ingested that represent the media, and or
	        timed text, or other non manifest objects, typically
           these are CMAF addressable media objects such as
           CMAF chunks, fragments or segments.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="Objects" data-noexport id="objects"> <strong>Objects</strong> </dfn> [=Manifest objects] or <a data-link-type="dfn" href="#media-objects" id="ref-for-media-objects">Media objects</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="streaming-presentation"><strong>Streaming presentation</strong></dfn> set of <a data-link-type="dfn" href="#objects" id="ref-for-objects">Objects</a> composing
	        a Streaming presentation based on a streaming protocol such
           as for example <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="media-processing-entity"><strong>Media processing entity</strong></dfn>:
            Entity used to process the media content,  
            receives/consumes a media [=Ingest stream].</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="receiving-entity"><strong>Receiving entity</strong></dfn>:
          Entity used to receive the media content,  
          receives/consumes an [=Ingest stream].</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="CMAFstream" data-noexport id="cmafstream"> <strong>CMAFstream</strong> </dfn>:
             bytestream that follows the CMAF track format structure format
             defined in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="Media fragment" data-noexport id="media-fragment"> <strong>Media fragment</strong> </dfn> Media fragment, combination of moof and mdat in
             ISOBMFF structure (MovieFragmentBox and mediaDataBox),
             can be a CMAF fragment or chunk</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="CMAF Header" data-noexport id="cmaf-header"> <strong>CMAF Header</strong> </dfn>:
             CMAF track header defined in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="CMAF Media object" data-noexport id="cmaf-media-object"> <strong>CMAF Media object</strong> </dfn>:
             CMAF media object defined in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="CMAF fragment" data-noexport id="cmaf-fragment"> <strong>CMAF fragment</strong> </dfn>:
             CMAF fragment defined in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="CMAF chunk" data-noexport id="cmaf-chunk"> <strong>CMAF chunk</strong> </dfn>:
             CMAF chunk defined in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="CMAF segment" data-noexport id="cmaf-segment"> <strong>CMAF segment</strong> </dfn>:
             CMAF segment defined in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="cmaf-track"><strong>CMAF Track</strong></dfn> CMAF Track defined in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="HTTP POST" data-noexport id="http-post"> <strong>HTTP POST</strong> </dfn>:
             Command used in the Hyper Text Transfer Protocol for  
             sending data from a source to a destination <a data-link-type="biblio" href="#biblio-rfc7235">[RFC7235]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="POST_URL" data-noexport id="post_url"> <strong>POST_URL</strong> </dfn>:
            Target URL of a POST command in the HTTP protocol  
             for posting data from a source to a destination.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="tcp"><strong>TCP</strong></dfn>:
           Transmission Control Protocol (TCP) as defined in <a data-link-type="biblio" href="#biblio-rfc793">[RFC793]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="event-received-time"><strong>Event Received Time</strong></dfn>:
            The time a metadata item is seen/observed by the application for
            the first time, e.g. an announcement/avail. The time the event
            is received (event received time). This could for example
            be the time an EventMessageBox becomes available</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="Event Presentation Time" data-noexport id="event-presentation-time"> <strong>Event Presentation Time</strong> </dfn>:
              The time a metadata event is applied to a stream (if applicable),
              correspond to the presentation_time of a dash event <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a> (event presentation time)</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="connection"><strong>Connection</strong></dfn>:
              A connection setup between two hosts, typically the  
              media <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source②">Ingest source</a> and [=Receiving entity].</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="switching-set"><strong>Switching set</strong></dfn>:
           Group of tracks corresponding to a switching set defined in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> or an adaptationset in <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="ABR" data-noexport id="abr"> <strong>ABR</strong> </dfn>:
          Adaptive Bit-Rate</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="RTP" data-noexport id="rtp"><strong>RTP</strong> </dfn>:
         Real Time Protocol</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="OTT" data-noexport id="ott"><strong>OTT</strong> </dfn>:
         Over the top transmission, i.e. HTTP based video streaming</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="moof"><strong>moof</strong></dfn>:
           The MovieFragmentBox "moof" box as defined in the  
           ISOBMFF  base media file format <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> that defines
           the metadata of a fragment.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="ftyp"><strong>ftyp</strong></dfn>:
          The FileTypeBox "ftyp" box as defined
          in the ISOBMFF <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="moov"><strong>moov</strong></dfn>:
           The container box for all metadata MovieBox "moov" defined in the  
           ISOBMFF base media file format <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="mdat" data-noexport id="mdat"> <strong>mdat</strong> </dfn>:
           The mediaDataBox "mdat" box defined in
            ISOBMFF <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a>.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="mfra"><strong>mfra</strong></dfn>:
            The movieFragmentRandomAccessBox "mfra" box defined in  
            the ISOBMFF <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> to signal random access samples  
            (these are samples that require no prior  
            or other samples for decoding) <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a>.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="tfdt" data-noexport id="tfdt"> <strong>tfdt</strong> </dfn>:
            The TrackFragmentBaseMediaDecodeTimeBox box "tfdt"  
            defined in <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> used  
            to signal the decode time of the media  
            fragment signalled in the <a data-link-type="dfn" href="#moof" id="ref-for-moof">moof</a> box.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="basemediadecodetime" data-noexport id="basemediadecodetime"> <strong>basemediadecodetime</strong> </dfn>:
            Decode time of first sample as signalled in the <a data-link-type="dfn" href="#tfdt" id="ref-for-tfdt">tfdt</a> box</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="mdhd" data-noexport id="mdhd"> <strong>mdhd</strong> </dfn>:
             The MediaHeaderBox "mdhd" as defined in <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a>,  
             this box contains information about the media such  
             as timescale, duration, language using ISO 639-2/T <a data-link-type="biblio" href="#biblio-iso-639-2">[iso-639-2]</a> codes <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="elng" data-noexport id="elng"> <strong>elng</strong> </dfn>:
             Extended language tag box "elng" defined in <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> that  
             can override the language information</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="nmhd" data-noexport id="nmhd"> <strong>nmhd</strong> </dfn>:
             The nullMediaHeaderBox "nmhd" as defined in <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> to signal a track for which no specific  
             media header is defined, used for metadata tracks</p>
   <h2 class="heading settled" data-level="4" id="workflow_and_use_cases"><span class="secno">4. </span><span class="content">Media Ingest Workflows and Profiles</span><a class="self-link" href="#workflow_and_use_cases"></a></h2>
   <p>Two key workflows and interfaces have been identified for which media
   ingest interface protocols are defined.</p>
   <p>The first workflow uses a separate live encoder as <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source③">Ingest source</a> and packager as <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity③">Receiving entity</a>. In this case, interface 1, <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> (CMAF) Ingest may be used. This interface uses <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> to ingest a live encoded stream to the packager. The <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity④">Receiving entity</a> in this case may do the pacakging, encryption, or
   other active media processing on the stream. This interface is defined
   in a way that it will be possible to generate streaming presentation
   based on <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a> or HLS <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a> based on the ingested stream.</p>
   <p>The second workflow, constitutes ingest to a passive delivery system, such
   as a cloud storage or a content delivery network. In this case the stream needs
   to be formatted as close as possible to the final stream for consumption by a client.
   This interface is defined in the second part, interface 2 <a data-link-type="dfn" href="#dash-ingest" id="ref-for-dash-ingest">DASH Ingest</a> or <a data-link-type="dfn" href="#hls-ingest" id="ref-for-hls-ingest">HLS Ingest</a>.
   It enables a push based version of these commonly used streaming protocols.
   In this case, besides the media object, also manifest objects are ingested to the <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity⑤">Receiving entity</a>.</p>
   <p>Diagram 1: Example with <a data-link-type="dfn" href="#cmaf-ingest" id="ref-for-cmaf-ingest">CMAF Ingest</a></p>
   <figure> <img src="Images/Diagram1.png"> </figure>
   <p>Diagram 2: Example with DASH Ingest</p>
   <figure> <img src="Images/Diagram2.png"> </figure>
   <p>Diagram 1 shows the workflow with a live media ingest from an
    ingest source towards a media processing entity.   
    In the example in diagram 1, the media processing entity  
    prepares the final media presentation for the client  
    that is delivered by the Content Delivery Network to a client.
    The media processing entity could be a live packager for
    DASH or HLS streams.</p>
   <p>Diagram 2 shows the example in workflow 2 were content
    is ingested directly into a Content Delivery Network.  
    The content delivery network enables the delivery to the client.</p>
   <p>An example of a media ingest protocol for the first workflow
    is the ingest part of the Microsoft Smooth   
    Streaming protocol <a data-link-type="dfn" href="#ms-sstr" id="ref-for-ms-sstr①">MS-SSTR</a>. This protocol   
    connects live encoders/ingest sources
    to the Microsoft Smooth Streaming server
    and to the Microsoft Azure cloud.   
    This protocol has shown to be robust, flexible and   
    easy to implement in live encoders. In addition, it   
    provided features for high availability and   
    server side redundancy.</p>
   <p>The DASH-IF <a data-link-type="dfn" href="#cmaf-ingest" id="ref-for-cmaf-ingest①">CMAF Ingest</a> protocol defined in this document,
    advances over the smooth
    ingest protocol including lessons learned over the last   
    ten years after the initial deployment of    
    smooth streaming in 2009 and several advances   
    on signaling metadata and timed text.</p>
   <p>In addition, the current specification incorporates the latest media formats
    and protocols, making it ready for current and   
    next generation media codecs such as <a data-link-type="biblio" href="#biblio-mpeghevc">[MPEGHEVC]</a> and protocols like MPEG DASH <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a>.
    In addition, to support the sub profiling
    of existing media containers CMAF <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> is referenced.</p>
   <p>The second interface referred
    as DASH and HLS ingest
    is included for ingest of media   
    streaming presentations to entities where    
    the media is not altered actively.
    A key idea of this part of the specification is to re-use   
    the similarities of MPEG DASH <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a> and HLS <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a> protocols   
    to enable a simultaneous ingest of media   
    presentations of these two formats using   
    common media fragments such as based on <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> and <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> formats. In this   
    interface naming is important to enable direct   
    processing and storage of the presentation.</p>
   <p>We present these two interfaces separately.
    We made this decision as it will   
    reduce a lot of overhead in the   
    information that needs to be signalled   
    compared to having both interfaces   
    combined into one, as was the case   
    in a draft version of this document.</p>
   <p>However, both use the HTTP POST
    method defined in <a data-link-type="biblio" href="#biblio-rfc7235">[RFC7235]</a> and similar
    mechanisms for authentication and failure handling
    leaving a shared protocol core. Therefore, in some
    practical implementations,
    the two interfaces might be combined
    into one, when the DASH or HLS is also
    using the Common Media Application Track
    Format. But this is not assumed in this specification.</p>
   <p>Table 1 highlights some of the key
    differences and practical considerations of
    the interfaces. In <a data-link-type="dfn" href="#cmaf-ingest" id="ref-for-cmaf-ingest②">CMAF Ingest</a>,
    the ingest source can be  
    simple as the <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity⑥">Receiving entity</a> can  
    do many of the operations related to the  
    delivery such as encryption or generating the streaming  
    manifests. In addition, the distribution of functionalities  
    can make it easier to scale a deployment with many  
    live media sources and media processing entities.</p>
   <p>In some cases, an encoder has sufficient
   capabilities to prepare the final presentation for the  
   client, in that case content can be ingested directly  
   to a more passive media processing entity that provides  
   a pass through like functionality.  
   In this case also <a data-link-type="dfn" href="#manifest-objects" id="ref-for-manifest-objects">Manifest objects</a> and other client specific  
   information needs to be ingested. Besides these factors  
   , choosing a workflow for a video streaming platform depends  
   on many other factors. This specification does not
   provide guidance on what workflow is best to use in which
   cases. Yet, the live ingest specification
   covers the two interfaces suitable for
   different types of workflows, or in some cases the interfaces
   may be combined into a live streaming workflow.</p>
   <p>The best choice for a specific platform depends
   on many of the use case specific requirements,
   circumstances  and the available technologies.</p>
   <p>Table 1: different ingest use cases</p>
   <table class="def">
    <tbody>
     <tr>
      <th>Profile
      <th>Ingest source
      <th> Media processing 
     <tr>
      <td>CMAF Ingest
      <td>Limited overview, simpler encoder, multiple sources 
      <td> re-encryption, transcode, stitching, watermark, packaging
     <tr>
      <td>DASH/HLS Ingest
      <td>Global overview, targets duplicate presentations, limited flexibility no redundancy
      <td> manifest manipulation, transmission, storage
   </table>
   <p>Diagram 3:
  workflow with redundant Ingest sources and receiving entities</p>
   <figure> <img src="Images/Diagram6.png"> </figure>
   <p>Finally, Diagram 3 highlights another aspect that was taken into consideration
  for large scale systems with many users. Often content owners would like to run multiple
  ingest sources, multiple receiving entities and make them available to the clients
  in a seamless fashion for maximum resiliancey. This approach is common when serving web pages,
  and this architecture also applies to video streaming platforms. In Diagram 3
  it is highlighted how one or more Ingest Sources can be sending data to one or
  more processing entities. In such a workflow it is important to handle the case
  when one ingest source or media processing entity fails. Both the system and client
  behavior is an important consideration in practical video streaming systems that need
  to run 24/7 such as Internet Television. Failovers must be handled robustly and without
  causing service interruption.
  This specification details how this failover and redundancy support can be achieved.</p>
   <h2 class="heading settled" data-level="5" id="general"><span class="secno">5. </span><span class="content">General Ingest Protocol Behavior</span><a class="self-link" href="#general"></a></h2>
   <p>The media ingest follows the following
  general requirements for both target /interfaces.</p>
   <ol>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source④">Ingest source</a> SHALL communicate
using the HTTP POST method as defined in
the HTTP protocol, version 1.1 <a data-link-type="biblio" href="#biblio-rfc7235">[RFC7235]</a></p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source⑤">Ingest source</a> SHOULD
use HTTP over TLS, if TLS is used it SHALL support atleast
TLS version 1.2, higher version
may also be supported additionally <a data-link-type="biblio" href="#biblio-rfc2818">[RFC2818]</a></p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source⑥">Ingest source</a> SHOULD repeatedly resolve
the hostname to adapt to changes in the IP to Hostname mapping
such as for example by using the domain naming system
DNS <a data-link-type="biblio" href="#biblio-rfc1035">[RFC1035]</a> or any other system that is in place.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source⑦">Ingest source</a> MUST update the IP to hostname
resolution respecting the TTL (time to live) from DNS
query responses, this will enable better resilience
to changes of the IP address in large scale deployments
where the IP address of the  media
processing entities may change frequently.</p>
    <li data-md>
     <p>In case HTTP over TLS <a data-link-type="biblio" href="#biblio-rfc2818">[RFC2818]</a> protocol is used,
basic authentication HTTP AUTH <a data-link-type="biblio" href="#biblio-rfc7617">[RFC7617]</a> or TLS client certificates MUST be supported.</p>
    <li data-md>
     <p>Mutual authentication SHALL be supported.
Client certificates SHALL chain to a trusted CA
, or be self assigned.</p>
    <li data-md>
     <p>As compatibility profile for the TLS encryption
the ingest source SHOULD use the mozzilla
intermediate compatibility profile <a data-link-type="dfn" href="#mozillatls" id="ref-for-mozillatls">MozillaTLS</a>.</p>
    <li data-md>
     <p>In case of an authentication error, the ingest
source SHALL retry establishing the <a data-link-type="dfn" href="#connection" id="ref-for-connection">Connection</a> within a fixed time period
with updated authentication credentials</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source⑧">Ingest source</a> SHOULD terminate
the <a data-link-type="dfn" href="#http-post" id="ref-for-http-post">HTTP POST</a> request if data is not being sent
at a rate commensurate with the MP4 fragment duration.
An HTTP POST request that does not send data can
prevent the <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity⑦">Receiving entity</a> from quickly disconnecting from the ingest source
in the event of a service update.</p>
    <li data-md>
     <p>The HTTP POST for sparse
data SHOULD be short-lived,
terminating as soon as the data of a fragment is sent.</p>
    <li data-md>
     <p>The POST request uses a <a data-link-type="dfn" href="#post_url" id="ref-for-post_url">POST_URL</a> to the basepath of the
publishing point at the media processing entity and
SHOULD use an additional relative path when posting
different streams and fragments, for example,
to signal the stream or fragment name.</p>
    <li data-md>
     <p>Both the <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source⑨">Ingest source</a> and <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity⑧">Receiving entity</a> MUST support IPv4 and IPv6 transport.</p>
   </ol>
   <h2 class="heading settled" data-level="6" id="profile_1"><span class="secno">6. </span><span class="content">Ingest Interface 1:  CMAF Ingest Protocol Behavior</span><a class="self-link" href="#profile_1"></a></h2>
   <p>This section describes the protocol behavior specific to
interface 1: <a data-link-type="dfn" href="#cmaf-ingest" id="ref-for-cmaf-ingest③">CMAF Ingest</a>. Operation of this  
profile MUST also adhere to the general requirements.</p>
   <h3 class="heading settled" data-level="6.1" id="profile_1_general"><span class="secno">6.1. </span><span class="content">CMAF Ingest General Considerations</span><a class="self-link" href="#profile_1_general"></a></h3>
   <p>The binary media format for conveying
the media is based on CMAF track constraints as  
specified in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a>.
A key benefit of this  format is that it
allows easy identification  
of stream boundaries, enabling switching, redundancy,  
re-transmission resulting in a good fit with the current  
Internet infrastructures. Many problems in  
practical streaming deployment often deal  
with issues related to the binary  
media format. We believe that the CMAF
track format will make things easier  
and that the industry is already heading  
in this direction following recent specifications  
like <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> and HLS <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a>.</p>
   <p><a data-link-type="dfn" href="#cmaf-ingest" id="ref-for-cmaf-ingest④">CMAF Ingest</a> typically assumes ingest to an active media processing entity.
It advances over the ingest  
part of the smooth ingest protocol <a data-link-type="dfn" href="#ms-sstr" id="ref-for-ms-sstr②">MS-SSTR</a> by only using  
standardized media container formats
and boxes based on <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> and <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a>.  
In addition, this enables extension towards codecs like <a data-link-type="biblio" href="#biblio-mpeghevc">[MPEGHEVC]</a> and  
timed metadata ingest of subtitle and timed text streams.  
The workflow ingesting multiple media ingest streams with <a data-link-type="dfn" href="#cmaf-ingest" id="ref-for-cmaf-ingest⑤">CMAF Ingest</a> is illustrated in Diagram 4. Discussions
on the early development have been documented <a data-link-type="dfn" href="#fmp4git" id="ref-for-fmp4git">fmp4git</a>.</p>
   <p>Diagram 4: CMAF ingest with multiple ingest sources</p>
   <figure> <img src="Images/Diagram7.png"> </figure>
   <p>Diagrams 5-7 detail some of the concepts and structures.
Diagram 5 shows the data format structure of the <a data-link-type="dfn" href="#cmaf-track" id="ref-for-cmaf-track">CMAF Track</a> format <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> and <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a>. In this format media meta data   
such as playback time, sample duration and sample data (encoded samples)   
are interleaved. The MovieFragmentBox <a data-link-type="dfn" href="#moof" id="ref-for-moof①">moof</a> box as specified in <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> is used   
to signal the information to playback and decode the samples   
stored in the following mdat box.   
The <a data-link-type="dfn" href="#ftyp" id="ref-for-ftyp">ftyp</a> and moov box contain the track specific information   
and can be seen as a <a data-link-type="dfn" href="#cmaf-header" id="ref-for-cmaf-header">CMAF Header</a> of the stream, sometimes referred   
as a <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> header.  
The combination of <a data-link-type="dfn" href="#moof" id="ref-for-moof②">moof</a> <a data-link-type="dfn" href="#mdat" id="ref-for-mdat">mdat</a> can be referred   
as a <a data-link-type="dfn" href="#cmaf-fragment" id="ref-for-cmaf-fragment">CMAF fragment</a> or <a data-link-type="dfn" href="#cmaf-chunk" id="ref-for-cmaf-chunk">CMAF chunk</a> or a <a data-link-type="dfn" href="#cmaf-segment" id="ref-for-cmaf-segment">CMAF segment</a> depending on the structure content and the number of moof mdat structures
in the addressable object.</p>
   <p>The combination of <a data-link-type="dfn" href="#ftyp" id="ref-for-ftyp①">ftyp</a> and <a data-link-type="dfn" href="#moov" id="ref-for-moov">moov</a> can be referred
to as a <a data-link-type="dfn" href="#cmaf-header" id="ref-for-cmaf-header①">CMAF header</a>.  
These CMAF Addressable media objects can be jointly referred to as <a data-link-type="dfn" href="#cmaf-media-object" id="ref-for-cmaf-media-object">CMAF Media object</a></p>
   <p>Diagram 5: <a data-link-type="dfn" href="#cmaf-track" id="ref-for-cmaf-track①">CMAF Track</a> stream:</p>
   <figure> <img src="Images/Diagram8.png"> </figure>
   <p>Diagram 5 illustrates the synchronization model, that
is based on the synchronization model proposed in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a>.
Different bit-rate tracks and/or media streams are conveyed
in separate CMAF tracks. By having the boundaries
to the fragments time aligned for tracks comprising the
same content stream at different bit-rates, bit-rate  
switching can be achieved. By using a common timeline  
different streams can be synchronized at the receiver,  
while they are in a separate <a data-link-type="dfn" href="#cmaf-track" id="ref-for-cmaf-track②">CMAF Track</a>,
send over a separate connection, possibly from a different <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source①⓪">Ingest source</a>. For more information on the synchronization
model we refer to section 6 of <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a>. For synchronization
of tracks coming from different encoders, sample time accuracy
is required. i.e. the same samples need to be mapped to the
sample time on the timescale used for the track. Further,
in case multiple redundant ingest sources are used
they must present sample accurately synchronized streams.</p>
   <p>In diagram 7 another advantage of this synchronization model
is illustrated, the concept of late binding. In the case   
of late binding, streams are combined on playout
in a presentation. By using   
the fragment boundaries and a common timeline it can   
be received by the media processing entity and embedded   
in the presentation. Late binding is useful for many   
practical use cases when broadcasting television   
content with different types of media and
metadata tracks originating from different sources.
Also it allows storage of each track separately, and combining
them later in a presentation based on user/operator preferences.
Contrary, to multiplexed content, with late binding, the
combination of media tracks is decided at playout.</p>
   <p>Note that it is important, as defined in MPEG CMAF
that different CMAF Tracks have the same starting time
sharing an implicit timeline. A stream becoming available
late or from a different source needs to be synchronized
and time aligned with other streams ingested avoiding
miss alignment and other issues.</p>
   <p>Diagram 6: <a data-link-type="dfn" href="#cmaf-track" id="ref-for-cmaf-track③">CMAF Track</a> synchronization:</p>
   <figure> <img src="Images/Diagram9.png"> </figure>
   <p>Diagram 7: CMAF late binding:</p>
   <figure> <img src="Images/Diagram10.png"> </figure>
   <p>Diagram 8 shows the flow of the media ingest. It starts with a
DNS resolution (if needed) and an authentication step (using Authy,   
or TLS certificates) to establish a secure <a data-link-type="dfn" href="#tcp" id="ref-for-tcp">TCP</a> connection.
While this specification promotes TLS certificates,
in future versions using token based authentication may be considered.
In some private datacenter deployments where nodes   
are not reachable from outside, a non authenticated connection   
may also be used. The ingest source then issues a POST   
to test that the <a data-link-type="dfn" href="#media-processing-entity" id="ref-for-media-processing-entity">media processing entity</a> is listening. This
POST contains the <a data-link-type="dfn" href="#moov" id="ref-for-moov①">moov</a> + <a data-link-type="dfn" href="#ftyp" id="ref-for-ftyp②">ftyp</a> box (the init fragment
or <a data-link-type="dfn" href="#cmaf-header" id="ref-for-cmaf-header②">CMAF Header</a> or could be empty.
In case this is successful this is followed by the rest of
the fragments in the <a data-link-type="dfn" href="#cmafstream" id="ref-for-cmafstream">CMAFstream</a>. At the end of
the session, for tear down the source may send an empty <a data-link-type="dfn" href="#mfra" id="ref-for-mfra">mfra</a> box to close the connection and <a data-link-type="dfn" href="#publishing-point" id="ref-for-publishing-point">Publishing point</a>. This is then followed with a zero length
chunk, allowing the receiver to send a response, the encoder can
follow up by closing the TCP connection using a FIN command as
defined in HTTP RFC2616.</p>
   <p>Diagram 8: CMAF ingest flow</p>
   <figure> <img src="Diagrams/media-ingest.png"> </figure>
   <h3 class="heading settled" data-level="6.2" id="general_Protocol_Requirements_p1"><span class="secno">6.2. </span><span class="content">General Protocol Requirements</span><a class="self-link" href="#general_Protocol_Requirements_p1"></a></h3>
   <ol>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source①①">Ingest source</a> SHALL start
by sending an HTTP POST request with the
CMAF Header, or an empty request,
by using the POSTURL
This can help the ingest source
to quickly detect whether the
publishing point is valid,
and if there are any authentication
or other conditions required.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source①②">Ingest source</a> MUST initiate
a media ingest connection by posting the <a data-link-type="dfn" href="#cmaf-header" id="ref-for-cmaf-header③">CMAF header</a> after step 1</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source①③">Ingest source</a> SHOULD use the chunked transfer
encoding option of the HTTP POST command <a data-link-type="biblio" href="#biblio-rfc2626">[RFC2626]</a> when the content length is unknown at the start of transmission
or to support use cases that require low latency</p>
    <li data-md>
     <p>If the HTTP POST request terminates or times out with a TCP
error, the <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source①④">Ingest source</a> MUST establish
a new connection, and follow the
preceding requirements. Additionally, the <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source①⑤">Ingest source</a> MAY resend
the fragment in which the timeout or TCP error occurred.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source①⑥">Ingest source</a> MUST handle
any error responses
received from the media processing entity, by establishing
a new connection and following the preceding
requirements including retransmitting
the ftyp and moov boxes or the <a data-link-type="dfn" href="#cmaf-header" id="ref-for-cmaf-header④">CMAF Header</a>.</p>
    <li data-md>
     <p>In case the <a data-link-type="dfn" href="#live-stream-event" id="ref-for-live-stream-event">Live stream event</a> is over the
ingest source SHALL signal
the stop by transmitting an empty <a data-link-type="dfn" href="#mfra" id="ref-for-mfra①">mfra</a> box
towards the media processing entity.
After that it SHALL send an empty HTTP chunk,
Wait for the HTTP response before closing
TCP session RFC2616
when this response is received</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source①⑦">Ingest source</a> SHOULD use a separate TCP
connection for ingest of each different CMAF track</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source①⑧">Ingest source</a> MAY use a separate relative path
in the <a data-link-type="dfn" href="#post_url" id="ref-for-post_url①">POST_URL</a> for ingesting each different track by
appending it to the <a data-link-type="dfn" href="#post_url" id="ref-for-post_url②">POST_URL</a>, this can make it
easy to detect redundant streams from different ingest
sources.</p>
    <li data-md>
     <p>The base media decode timestamps <a data-link-type="dfn" href="#basemediadecodetime" id="ref-for-basemediadecodetime">basemediadecodetime</a> in tfdt of fragments in the <a data-link-type="dfn" href="#cmafstream" id="ref-for-cmafstream①">CMAFstream</a> SHOULD arrive in increasing order
for each of the fragments in the different
tracks/streams that are ingested.</p>
    <li data-md>
     <p>The fragment sequence numbers
seq_num of fragments in the <a data-link-type="dfn" href="#cmafstream" id="ref-for-cmafstream②">CMAFstream</a> signalled in the tfhd
SHOULD arrive in increasing order for each of the different
tracks/streams that are ingested. Using both
timestamp basemediadecodetime and seq_num
based indexing will help the media processing
entities identify discontinuities in the ingest stream.</p>
    <li data-md>
     <p>Stream names MAY be signalled by adding the relative path
 Stream(stream_name) to the <a data-link-type="dfn" href="#post_url" id="ref-for-post_url③">POST_URL</a>, this can be
 useful for identification when multiple
 ingest sources send the same redundant stream to a receiver</p>
    <li data-md>
     <p>The average and maximum bitrate of each
 track SHOULD be signalled
 in the btrt box in the sample
 entry of the CMAF header or init fragment</p>
    <li data-md>
     <p>In case a track is part of a <a data-link-type="dfn" href="#switching-set" id="ref-for-switching-set">Switching set</a>, all
 properties section 6.4 and 7.3.4 of <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> MUST be satisfied,
 enabling the receiver to group the tracks in respective
 switching sets</p>
    <li data-md>
     <p>Ingested tracks MUST conform to CMAF track structure defined
 in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a></p>
    <li data-md>
     <p>CMAF Tracks SHOULD NOT use segmentTypeBox to signal <a data-link-type="dfn" href="#cmaf-media-object" id="ref-for-cmaf-media-object①">CMAF Media object</a> brands like chunk, fragment, segment.</p>
   </ol>
   <p class="note" role="note"><span>Note,</span> in case a media processing entity cannot process a request from an ingest source
	correctly, it can send respective HTTP error code. Please see the section
    for the usage of these codes in <a href="#failover">Failover and error handling</a>. Please
	also read this section for a complete understanding of the general protocol behavior.</p>
   <h3 class="heading settled" data-level="6.3" id="Requirements_for_formatting_Media_Tracks"><span class="secno">6.3. </span><span class="content">Requirements for Formatting Media Tracks</span><a class="self-link" href="#Requirements_for_formatting_Media_Tracks"></a></h3>
   <ol>
    <li data-md>
     <p>Media tracks SHALL be formatted using boxes
according to section 7 of <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> except
for section 7.4. which dictates boxes that are
not compliant to <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> relating to encryption
and DRM systems</p>
    <li data-md>
     <p>The trackFragmentDecodeTime box <a data-link-type="dfn" href="#tfdt" id="ref-for-tfdt①">tfdt</a> box
MUST be present for each fragment posted.</p>
    <li data-md>
     <p>The ISOBMFF media fragment duration SHOULD be constant,
the duration MAY fluctuate to compensate
for non-integer frame rates. By choosing an appropriate
timescale (a multiple of the frame rate is recommended)
this issue should be avoided.</p>
    <li data-md>
     <p>The fragment durations SHOULD be between
approximately 1 and 6 seconds.</p>
    <li data-md>
     <p>The CMAF Tracks SHOULD use
a timescale for video streams based on the framerate
and 44.1 KHz or 48 KHz for audio streams
or any another timescale that enables integer
increments of the decode times of
fragments signalled in the "tfdt" box based on this scale.
If necessary, integer multiples of these timescales
could be used.</p>
    <li data-md>
     <p>The language of the CMAF Track SHOULD be signalled in the <a data-link-type="dfn" href="#mdhd" id="ref-for-mdhd">mdhd</a> box or <a data-link-type="dfn" href="#elng" id="ref-for-elng">elng</a> boxes in the
init fragment, cmaf header
and/or <a data-link-type="dfn" href="#moov" id="ref-for-moov②">moov</a> headers (<a data-link-type="dfn" href="#mdhd" id="ref-for-mdhd①">mdhd</a>).</p>
    <li data-md>
     <p>Media CMAF tracks SHOULD
contain the bitrate btrt box specifying the target
average and maximum bitrate of the fragments
in the sample entry container in the init fragment/CMAF header</p>
    <li data-md>
     <p>The CMAF track MAY comprise CMAF chunks <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> which are moof mdat structures that may  
not be an IDR or switching point</p>
    <li data-md>
     <p>For video tracks, profiles like avc1 and hvc1 MAY be used
that signal the sequence parameter set in the CMAF Header.
In this case codec parameters do not change
dynamically during the live event.</p>
    <li data-md>
     <p>Alternatively, video tracks MAY use profiles like avc3 or
 hev1 that signal the parameter sets (PPS, SPS, VPS) in
  in the media samples.</p>
    <li data-md>
     <p>In case the language of a track changes a new init fragment
  with update <a data-link-type="dfn" href="#mdhd" id="ref-for-mdhd②">mdhd</a> and or <a data-link-type="dfn" href="#elng" id="ref-for-elng①">elng</a> SHOULD be send.</p>
    <li data-md>
     <p>Track roles SHOULD be signalled in the ingest by using a kind box
  in userData udta box. The kind box MUST contain a schemeIdUri MPEG
  urn:mpeg:dash:role:2011 and a value containing a Role
  as defined in <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a>. In case this signalling
    does not occur processing entity can define the role for
    the track independently from the media ingest source.</p>
   </ol>
   <p class="note" role="note"><span>Note:</span> <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> has the notion of a segment, a fragment and a chunk.
A fragment can be composed of one or more chunks, while a segment can be
composed of one or more fragments. The <a data-link-type="dfn" href="#media-fragment" id="ref-for-media-fragment">Media fragment</a> defined here
is independent of this notion and can be a chunk, a fragment containing
a single chunk or a segment containing a single fragment containing
a single chunk. In this text we use <a data-link-type="dfn" href="#media-fragment" id="ref-for-media-fragment①">Media fragment</a> to denote the structure combination moof mdat, corresponding
to a CMAF fragment or chunk.</p>
   <h3 class="heading settled" data-level="6.4" id="Requirements_for_switchingsets"><span class="secno">6.4. </span><span class="content">Requirements for Signalling Switching Sets</span><a class="self-link" href="#Requirements_for_switchingsets"></a></h3>
   <p>In live streaming a bundle of streams corresponding to a channel is ingested by posting
  to a publishing point. CMAF has the notion of a switchingsets <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> which map to similar
  streaming protocol concepts like adaptationset in <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a>. To signal a switching set
  CMAF media tracks MUST correspond to the constraints defined in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> section 7.3.4 .
  Table 2 summarizes the CMAF Switching set constraints.</p>
   <p>Table 2: Switching set constraints</p>
   <table class="def">
    <tbody>
     <tr>
      <th>Box
      <th> General CMAF header constraints in a CMAF switching set 
     <tr>
      <td>ftyp
      <td>Shall be identical except for media profile brands (see ‎1 in ‎7.3.4.1) 
     <tr>
      <td>mvhd
      <td>Shall be identical except for creation_time, and modification_time 
     <tr>
      <td>tkhd
      <td>Shall be identical except for width, height,
      creation_time, and modification_time. See NOTE 1.
     <tr>
      <td>trex 
      <td>identical 
     <tr>
      <td>elst
      <td>Shall be identical except for video CMAF track files with a different composition offset
     <tr>
      <td>mdhd
      <td>Shall be identical except for creation_time, and modification_time 
     <tr>
      <td>mehd
      <td>Global overview, targets duplicate presentations
     <tr>
      <td>meta
      <td>May contain different boxes and data 
     <tr>
      <td>udta
      <td>May contain different boxes and data 
     <tr>
      <td>cprt
      <td>identical
     <tr>
      <td>kind
      <td>identical
     <tr>
      <td>elng
      <td>identical
     <tr>
      <td>hdlr
      <td>identical
     <tr>
      <td>vmhd
      <td>identical
     <tr>
      <td>smhd
      <td>identical
     <tr>
      <td>sthd
      <td>identical
     <tr>
      <td>dref
      <td>identical
     <tr>
      <td>stsd
      <td>Sample entries shall have the same codingname (four-character code)
   </table>
   <p>NOTE 1: Track width and height can differ, but picture aspect ratio is the same for all CMAF tracks.
  NOTE 2: Sample entry constraints for CMAF switching sets are defined by each CMAF media profile</p>
   <p>For additional signalling of CMAF tracks belonging to the same switching set, the ingest source MAY set the alternate_group value
  in    the TrackHeaderBox tkhd to a value that is the same for tracks belonging to the same switching set.
  This allows explicit signalling of tracks that do apply to switchingset constraints but do not belong to the same switching set.
  Alternatively one could signal switching explicitly by means outside of this specification.</p>
   <h3 class="heading settled" data-level="6.5" id="timed_text_and_subtitle_streams"><span class="secno">6.5. </span><span class="content">Requirements for Timed Text, Captions and Subtitle Streams</span><a class="self-link" href="#timed_text_and_subtitle_streams"></a></h3>
   <p>The live media ingest specification follows requirements for ingesting
a track with timed text, captions and/or subtitle streams. The
recommendations for formatting subtitle and timed text track
are defined in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> and <a data-link-type="biblio" href="#biblio-mpeg4-30">[MPEG4-30]</a> and are re-iterated
here for convenience to the reader. Note that the text in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> prevails the text below when different except for
the notion of 9, 10 and 11.</p>
   <ol>
    <li data-md>
     <p>The track SHOULD be a sparse track signalled by a null media
header <a data-link-type="dfn" href="#nmhd" id="ref-for-nmhd">nmhd</a> containing the timed text, images, captions
corresponding to the recommendation of storing tracks
in CMAF <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a>, or a sthd for an ISOBMFF
subtitle track (e.g. TTML)</p>
    <li data-md>
     <p>Based on this recommendation, the trackhandler "hdlr" SHALL
be set to "text" for WebVTT and "subt" for TTML following <a data-link-type="biblio" href="#biblio-mpeg4-30">[MPEG4-30]</a></p>
    <li data-md>
     <p>In case TTML is used the track MUST use the XMLSampleEntry
to signal sample description of the sub-title stream <a data-link-type="biblio" href="#biblio-mpeg4-30">[MPEG4-30]</a></p>
    <li data-md>
     <p>In case WebVTT is used the track must use the WVTTSampleEntry
to signal sample description of the text stream <a data-link-type="biblio" href="#biblio-mpeg4-30">[MPEG4-30]</a></p>
    <li data-md>
     <p>These boxes SHOULD signal the mime type and specifics as
described in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> sections 11.3 ,11.4 and 11.5</p>
    <li data-md>
     <p>The boxes described in 2-4 must be present in the init
fragment (<a data-link-type="dfn" href="#ftyp" id="ref-for-ftyp③">ftyp</a> + <a data-link-type="dfn" href="#moov" id="ref-for-moov③">moov</a>) or cmaf header for the given track</p>
    <li data-md>
     <p>subtitles in CTA-608 and CTA-708 format SHOULD be conveyed
following the recommendation section 11.5 in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> via
Supplemental Enhancement Information SEI messages
in the video track <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a></p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ftyp" id="ref-for-ftyp④">ftyp</a> box in the CMAF Header for the track
containing timed text, images, captions and sub-titles
MAY use signalling using CMAF profiles based on <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a></p>
     <p>8a. WebVTT   Specified in 11.2 ISO/IEC 14496-30 <a data-link-type="biblio" href="#biblio-mpeg4-30">[MPEG4-30]</a> <em>cwvt</em></p>
     <p>8b.TTML IMSC1 Text  Specified in 11.3.3 <a data-link-type="biblio" href="#biblio-mpeg4-30">[MPEG4-30]</a> IMSC1 Text Profile <em>im1t</em></p>
     <p>8c.TTML IMSC1 Image Specified in 11.3.4 <a data-link-type="biblio" href="#biblio-mpeg4-30">[MPEG4-30]</a> IMSC1 Image Profile <em>im1i</em></p>
    <li data-md>
     <p>The BitRateBox btrt SHOULD be used to signal the average and
  maximum bitrate in the sample entry box, this is
  most relevant for bitmap or xml based timed text subtitles
  that may consume significant bandwidths (e.g. im1i)</p>
    <li data-md>
     <p>In case the language of a track changes, a new init fragment or
  CMAF Header with updated <a data-link-type="dfn" href="#mdhd" id="ref-for-mdhd③">mdhd</a> and/or <a data-link-type="dfn" href="#elng" id="ref-for-elng②">elng</a> SHOULD be send from the
  ingest source to the media processing entity.</p>
    <li data-md>
     <p>Track roles can be signalled in the ingest, by using a kind box
  in udta box. The kind box MUST contain a schemeIdUri MPEG
  urn:mpeg:dash:role:2011 and a value containing a Role
  as defined in <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a></p>
   </ol>
   <p class="note" role="note"><span>Note:</span> <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> allows multiple kind boxes, hence multiple roles
can be signalled. By default one should signal the DASH role
urn:mpeg:dash:role:2011. A receiver can derive corresponding configuration
for other streaming protocols such as HLS <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a>. In case this
is not desired, additional kind boxes with corresponding schemeIdUri
and values can be used to explicitly signal this kind of information.
Subschemes can be signalled in the schemeIdURI as schemeIdURI@value.</p>
   <p>An informative scheme of defined roles in MPEG DASH and respective
corresponding roles in HLS <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a> can be found below,
additionally the forced subtitle in HLS might be derived from
a DASH forced subtitle role</p>
   <p>Table 3: Roles for subtitle and Audio tracks and HLS Characteristics</p>
   <table class="def">
    <tbody>
     <tr>
      <th>Characteristic <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a> 
      <th> urn:mpeg:dash:role:2011 
     <tr>
      <td>transcribes-spoken-dialog 
      <td>subtitle 
     <tr>
      <td>easy-to-read 
      <td> easyreader 
     <tr>
      <td>descripes-video 
      <td>description 
     <tr>
      <td>descripes-music-and-sound 
      <td>caption 
   </table>
   <p>MPEG DASH roles are defined in urn:mpeg:dash:role:2011 <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a>.
Additionally another example for explicitly signalling roles could b
e DVB DASH <a data-link-type="biblio" href="#biblio-dvb-dash">[DVB-DASH]</a>. One could use schemeiduri@value and role as defined there.
e.g. 	kind.schemeIdUri="urn:tva:metadata:cs:AudioPurposeCS:2007@1 kind.value=Alternate</p>
   <h3 class="heading settled" data-level="6.6" id="timed_metadata"><span class="secno">6.6. </span><span class="content">Requirements for Timed Metadata</span><a class="self-link" href="#timed_metadata"></a></h3>
   <p>This section discusses the specific formatting requirements
  for <a data-link-type="dfn" href="#cmaf-ingest" id="ref-for-cmaf-ingest⑥">CMAF Ingest</a> of timed metadata related to events and markers for  
  ad insertion or other timed metadata.  An example of  
  these are opportunities for splice points and program information  
  signalled by SCTE-35 markers. This type of  event signalling  
  is different from regular audio/video information  
  because of its sparse nature. In this case,  
  the signalling data usually does not  
  happen continuously, and the intervals can  
  be hard to predict.</p>
   <p>Examples of timed metadata are ID3 tags <a data-link-type="biblio" href="#biblio-id3v2">[ID3v2]</a>, SCTE-35 markers <a data-link-type="biblio" href="#biblio-scte35">[SCTE35]</a> and DASH emsg  
  messages defined in section 5.10.3.3 of <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a>.
  In addition, any other metadata can be signalled in this
  scheme by providing a URI to identify the scheme, and
  the metadata embedded as samples in mdat.</p>
   <p>Table 4 provides some example urn schemes to be signalled i
  Table 5 illustrates an example of a SCTE-35 marker stored  
  in a DASH emsg, that is stored as a metadata sample.</p>
   <p>The presented approach enables ingest of
  timed metadata from different sources,  
  possibly on different locations by embedding them in  
  sparse metadata tracks. In this approach metadata
  are not interleaved with the media as for example
  the case in emsg boxes in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a>.</p>
   <p>Example metadata messages include inband event message box
  as used in <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a>, <a data-link-type="biblio" href="#biblio-dvb-dash">[DVB-DASH]</a>, or alternatively
  direct embedding of <a data-link-type="biblio" href="#biblio-scte35">[SCTE35]</a> or <a data-link-type="biblio" href="#biblio-id3v2">[ID3v2]</a> which might
  in some cases be used.</p>
   <p>For Example, by embedding the emsg structure in samples the benefits
  of its usages in DASH and CMAF are kept. In this case
  the URIMetasample entry will be mpeg:dash:event:2012,
  while the SchemeIdUri could be used to signal schemes
  of the messageData payload in the EventMessage.</p>
   <p>Table 4: Roles for subtitle and Audio tracks and HLS Characteristics</p>
   <table class="def">
    <tbody>
     <tr>
      <th>SchemeIdURI 
      <th> Reference 
     <tr>
      <td>urn:mpeg:dash:event:2012
      <td> <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a>, 5.10.4 subtitle 
     <tr>
      <td>urn:dvb:iptv:cpm:2014 
      <td> <a data-link-type="biblio" href="#biblio-dvb-dash">[DVB-DASH]</a>, 9.1.2.1 
     <tr>
      <td>urn:scte:scte35:2013:bin 
      <td><a data-link-type="biblio" href="#biblio-scte35">[SCTE35]</a> 14-3 (2015), 7.3.2 
     <tr>
      <td>www.nielsen.com:id3:v1 
      <td>Nielsen ID3 in MPEG-DASH <a data-link-type="biblio" href="#biblio-id3v2">[ID3v2]</a> 
   </table>
   <p>Table 5: Example of a SCTE-35 marker embedded in a DASH eventmessagebox</p>
   <table class="def">
    <tbody>
     <tr>
      <th> Tag 
      <th> Value 
     <tr>
      <td>scheme_uri_id 
      <td> urn:scte:scte35:2013:bin 
     <tr>
      <td>Value 
      <td> value used to signal subscheme 
     <tr>
      <td>Timescale 
      <td>positive number, ticks per second, similar to track timescale 
     <tr>
      <td>presentation_time_delta 
      <td>non-negative number, splice time compared to tfdt 
     <tr>
      <td>event_duration 
      <td>duration of event  "0xFFFFFFFF" if unknown 
     <tr>
      <td>id 
      <td>unique identifier for message 
     <tr>
      <td> message_data 
      <td> splice info section including CRC 
   </table>
   <p>Alternatively, a version 1 of the eventmessagebox with absolute timing
  could be used, where the presentation time is added as a 64 bit integer.
  In this case care must be taken not to signal events in the past or or
  far in the future.</p>
   <p>The active media processing entity can insert metadata in any of the
  switching sets, embedded as DashEventMesageBoxes. The metadata is assumed
  to relate to the media presentation (e.g. program information, splice information
  , chapter information) and not to a specific track. For track specific metadata
  other structures like the CMAF header can be used.
  Configuration of the <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity⑨">Receiving entity</a> on how to handle the metadata is out of scope of current document.
  More information about this will be given in supplementatal
  documents on implementation guidelines and best practices, that specify some recommended
  practices and example implmeentation. For example, a default behavior could be to embed
  the metadata events as eventmessages in each audio track in the switching sets for delivery.</p>
   <p>The following steps are recommended for timed metadata
  ingest related to events, tags, ad markers and  
  program information:</p>
   <ol>
    <li data-md>
     <p>Metadata SHALL be conveyed in a CMAF track, where
the media handler (hdlr) is "meta",
the track handler box is a null media header box <a data-link-type="dfn" href="#nmhd" id="ref-for-nmhd①">nmhd</a>.</p>
    <li data-md>
     <p>The metadata track applies to the media streams
ingested to a <a data-link-type="dfn" href="#publishing-point" id="ref-for-publishing-point①">Publishing point</a> entry at the media
processing entity or origin server</p>
    <li data-md>
     <p>The URIMetaSampleEntry entry SHALL contain,
in a URIbox, the URI following the URI syntax in <a data-link-type="biblio" href="#biblio-rfc3986">[RFC3986]</a> defining the form  of the metadata
(see the ISO Base media file format
 specification <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a>).</p>
    <li data-md>
     <p>The URIMetaSampleEntry
  MAY contain the urn urn:mpeg:dash:event:2012
  or an equivalent urn to signal the presence of event
  message boxes</p>
    <li data-md>
     <p>The timescale of the metadata SHOULD match the value
specified in the media header box "mdhd" of the
metadata track.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#event-received-time" id="ref-for-event-received-time">Event Received Time</a> is signalled in the "tfdt" box
 of the track fragment  as the basemediadecode
 time, this is the time when the metadata will be
 first received.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#event-presentation-time" id="ref-for-event-presentation-time">Event Presentation Time</a> can be signalled as
a difference to the Event Received Time by an
empty sample with duration delta, the application
time is the time when the metadata or event is
applied. It is equal to the media presentation time
of the sample containing the event/metadata. In such as
sparse fragment contains 3 samples, and empty sample
to signal the difference, a sample that contains the
Data, and an optional empty sample to fill the timeline</p>
    <li data-md>
     <p>The duration of the sample SHOULD correspond
to the duration of the metadata if the metadata is valid
for a duration of time (if applicable), however,
sometimes this is not the case and alternative
durations can be used.</p>
    <li data-md>
     <p>Empty samples, and fragments with empty samples
SHOULD be used to fill the timeline to avoid timeline
gaps or 32 bit duration overflow for large timescales</p>
    <li data-md>
     <p>All Timed Metadata samples SHOULD
be sync samples <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a>,
defining the entire set of
metadata for the time interval
they cover. Hence, the sync
sample table box SHOULD
not be present.</p>
    <li data-md>
     <p>The payload is conveyed in the mdat box as
sample information.</p>
    <li data-md>
     <p>In some cases, the duration of the metadata may not
be known, in this case the sample duration could
be set to zero and updated later when the timestamp
of the next metadata fragment is received.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source①⑨">Ingest source</a> SHOULD not embed inband event message
 boxes emsg in the ingest stream</p>
   </ol>
   <p class="note" role="note"><span>Note:</span> <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> has the notion of an inband event message box to convey
metadata and event messages. In the current specification
a separate track is used instead to convey such information.
Advantages include avoiding sending duplicate information
in multiple tracks, and avoiding a strong dependency between media
and metadata by interleaving them. The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source②⓪">Ingest source</a> SHOULD NOT
send inband emsg box and the receiver SHOULD ignore it. However,
event message box can be embedded as samples in the timed metadata
track.</p>
   <h3 class="heading settled" data-level="6.7" id="failover"><span class="secno">6.7. </span><span class="content">Requirements for Media Processing Entity Failover and Connection Error Handling</span><a class="self-link" href="#failover"></a></h3>
   <p>Given the nature of live streaming, good failover support is
  critical for ensuring the availability of the service.  
  Typically, media services are designed to handle various types  
  of failures, including network errors, server errors, and storage  
  issues. When used in conjunction with proper failover  
  logic from the ingest sources side, highly reliable live streaming  
  setups can be build. In this section, we discuss requirements  
  for failover scenarios. The following steps are required for an <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source②①">Ingest source</a> to deal with a failing media processing entity.</p>
   <p>The <a data-link-type="dfn" href="#cmaf-ingest" id="ref-for-cmaf-ingest⑦">CMAF ingest</a> source should implement the following recommendations
   to achieve failover support.</p>
   <ol>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source②②">Ingest source</a> MUST use a timeout in order of segment duration (1-6 seconds)
  for establishing the
TCP connection. If an attempt to establish
the connection takes longer than the timeout,
  abort the operation and try again.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source②③">Ingest source</a> SHOULD resend media fragments for which a
connection was terminated early, if the connection was down
  for less than 3 average segments durations. For connections
  that were down longer, ingest can resume at the live edge
  of the live media presentation instead.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source②④">Ingest source</a> SHOULD
NOT limit the number of retries to establish a
connection or resume streaming after a TCP error occurs.</p>
    <li data-md>
     <p>After a TCP error:
a. The current connection MUST be closed,
  and a new connection MUST be created
  for a new HTTP POST request.
b. The new HTTP POST URL MUST be the same
  as the initial POST URL for the
  fragment to be ingested.
c. The new HTTP POST MUST include stream
  headers (<a data-link-type="dfn" href="#ftyp" id="ref-for-ftyp⑤">ftyp</a>, and <a data-link-type="dfn" href="#moov" id="ref-for-moov④">moov</a> boxes)
  identical to the stream headers.</p>
    <li data-md>
     <p>In case the <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity①⓪">Receiving entity</a> cannot process the
 POST request due to authentication or permission
 problems then it SHALL return a permission denied HTTP 403</p>
    <li data-md>
     <p>In case the media processing entity can process the request
 it SHALL return an HTTP 200 OK or 202 Accepted</p>
    <li data-md>
     <p>In case the media processing entity can process
 the fragment in the POST request body but finds
 the media type cannot be supported it SHOULD return an HTTP 415
 unsupported media type</p>
    <li data-md>
     <p>In case an unknown error happened during
 the processing of the HTTP
 POST request a HTTP 400 Bad request SHALL be returned
 by the media processing entity</p>
    <li data-md>
     <p>In case the media processing entity cannot
 process a fragment posted
 due to missing or incorrect init fragment, an HTTP 412
 unfulfilled condition SHALL be returned</p>
    <li data-md>
     <p>In case an ingest source receives an HTTP 412 response,
 it SHALL resend <a data-link-type="dfn" href="#ftyp" id="ref-for-ftyp⑥">ftyp</a> and <a data-link-type="dfn" href="#moov" id="ref-for-moov⑤">moov</a> boxes, or the CMAF
 Header.</p>
   </ol>
   <h3 class="heading settled" data-level="6.8" id="failover_source"><span class="secno">6.8. </span><span class="content">Requirements for Live Media Source Failover</span><a class="self-link" href="#failover_source"></a></h3>
   <p><a data-link-type="dfn" href="#live-encoder" id="ref-for-live-encoder①">Live encoder</a> or <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source②⑤">Ingest source</a> failover is the second type
  of failover scenario that needs to be supported for end-to-end  
  live streaming delivery. In this scenario, the error condition  
  occurs on the <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source②⑥">Ingest source</a> side. The following expectations apply  
  to the live ingestion endpoint when encoder failover happens:</p>
   <ol>
    <li data-md>
     <p>A new <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source②⑦">Ingest source</a> instance SHOULD be instantiated
 to continue the ingest</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source②⑧">Ingest source</a> MUST use
 the same URL for HTTP POST requests as the failed instance.</p>
    <li data-md>
     <p>The new <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source②⑨">Ingest source</a> POST request
 MUST include the same <a data-link-type="dfn" href="#cmaf-header" id="ref-for-cmaf-header⑤">CMAF Header</a> or
 init fragment as the failed instance</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source③⓪">Ingest source</a> MUST be properly synced with all other running ingest sources
 for the same live presentation to generate synced audio/video  
 samples with aligned fragment boundaries.
 This implies that UTC timestamps
 for fragments in the "tfdt" match between decoders,
 and encoders. In addition, fragment boundaries need
 to be appropriately synchronized.</p>
    <li data-md>
     <p>The new stream MUST be semantically equivalent
 with the previous stream, and interchangeable
 at the header and media fragment levels.</p>
    <li data-md>
     <p>The new instance of <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source③①">Ingest source</a> SHOULD
 try to minimize data loss. The basemediadecodetime tfdt
 of media fragments SHOULD increase from the point where
 the encoder last stopped. The basemediadecodetime in the
 tfdt box SHOULD increase in a continuous manner, but it
 is permissible to introduce a discontinuity, if necessary.
 Media processing entities can ignore
 fragments that it has already received and processed, so
 it is better to error on the side of resending fragments
 than to introduce discontinuities in the media timeline.</p>
   </ol>
   <h2 class="heading settled" data-level="7" id="dash_ingest"><span class="secno">7. </span><span class="content">Ingest Interface 2: DASH and HLS Ingest Protocol Behavior</span><a class="self-link" href="#dash_ingest"></a></h2>
   <p>Interface 2 defines the protocol specific behavior required to ingest a <a data-link-type="dfn" href="#streaming-presentation" id="ref-for-streaming-presentation">Streaming presentation</a> composed of <a data-link-type="dfn" href="#manifest-objects" id="ref-for-manifest-objects①">Manifest objects</a> and <a data-link-type="dfn" href="#media-objects" id="ref-for-media-objects①">Media objects</a> to receiving entities that provide either pass-through functionality or limited processing of the content. In this mode, the <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source③②">Ingest source</a> prepares and delivers to the receiving entity all the <a data-link-type="dfn" href="#objects" id="ref-for-objects①">Objects</a> intended for consumption by a client. These are complete <a data-link-type="dfn" href="#streaming-presentation" id="ref-for-streaming-presentation①">Streaming presentation</a> including all manifest and media objects.</p>
   <p>This interface is intended to be used by workflows which do not require active media processing post encoding. It leverages the fact that many encoders provide HLS and DASH packaging capabilities and that the resulting packaged content can easily be transferred via HTTP to standard web servers. However, neither HLS nor DASH has specified how such a workflow is intended to work leaving the industry to self specify key decisions such as how to secure and authenticate ingest sources, who is responsible for managing the content life cycle, the order of operations, failover, robustness, etc. In most cases a working solution can be had using a readily available web server such as Nginx or Varnish and the standard compliment of HTTP Methods. In many cases Interface 2 simply documents what is considered industry best practice while attempting to provide guidance to areas less common.</p>
   <p>The requirements below encapsulate all needed functionality to support Interface 2. The requirements listed for Interface 1 (CMAF Ingest) in section <a href="#general_Protocol_Requirements_p1">§6.2 General Protocol Requirements</a> do not apply to Interface 2. General shared requirements are covered in section <a href="#general">§5 General Ingest Protocol Behavior</a>. In case [!MPEGCMAF] media is used, the media track and segment formatting will be similar as defined in Interface 1.</p>
   <h3 class="heading settled" data-level="7.1" id="DASH_General"><span class="secno">7.1. </span><span class="content">General requirements</span><a class="self-link" href="#DASH_General"></a></h3>
   <h4 class="heading settled" data-level="7.1.1" id="Industry_compliance"><span class="secno">7.1.1. </span><span class="content">Industry Compliance</span><a class="self-link" href="#Industry_compliance"></a></h4>
   <ol>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source③③">Ingest source</a> MUST be able to create a compliant <a data-link-type="dfn" href="#streaming-presentation" id="ref-for-streaming-presentation②">Streaming presentation</a> for MPEG-DASH <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a> or HTTP live Streaming <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a>. The Ingest Source MAY create both MPEG-DASH and HLS Streaming Presentations using common Media Objects (e.g., CMAF), but the Ingest Source MUST generate format specific Manifest Objects which describe the common Media Objects.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source③④">Ingest source</a> MUST support the configuration and use of Fully Qualified Domain Names (per RFC8499) to identify the <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity①①">Receiving entity</a>.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source③⑤">Ingest source</a> MUST support the configuration of the path which it will POST or PUT all the <a data-link-type="dfn" href="#objects" id="ref-for-objects②">Objects</a> to.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source③⑥">Ingest source</a> SHOULD support the configuration of the delivery path which clients will use to retrieve the content. When provided, the <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source③⑦">Ingest source</a> MUST use this path to build absolute URLs in the Manifest Files it generates. When absent, relative pathing is assumed and the Ingest Source MUST build the Mainfest Files accordingly.</p>
   </ol>
   <p>These capabilities are further illustrated in the Examples sections, and may be defined outside the scope of this specification.</p>
   <h4 class="heading settled" data-level="7.1.2" id="DASH_Ingest_HTTP"><span class="secno">7.1.2. </span><span class="content">HTTP connections</span><a class="self-link" href="#DASH_Ingest_HTTP"></a></h4>
   <ol>
    <li data-md>
     <p>The Ingest Source MUST transfer <a data-link-type="dfn" href="#manifest-objects" id="ref-for-manifest-objects②">Manifest objects</a> and <a data-link-type="dfn" href="#media-objects" id="ref-for-media-objects②">Media objects</a> to the Receiving entity via individual HTTP 1.1 <a data-link-type="biblio" href="#biblio-rfc7235">[RFC7235]</a> PUT or POST operations to the configured path. This specification does not imply any functional differentiation between a PUT or a POST operation. Either may be used to transfer content to the <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity①②">Receiving entity</a>. Unless indicated otherwise, the use of the term POST can be interpreted as PUT or POST.</p>
    <li data-md>
     <p>The Ingest Source SHOULD remove <a data-link-type="dfn" href="#media-objects" id="ref-for-media-objects③">Media objects</a> from the Receiving entity which are no longer referenced in the corresponding <a data-link-type="dfn" href="#manifest-objects" id="ref-for-manifest-objects③">Manifest objects</a> via an HTTP DELETE operation. How long the Ingest Source waits to remove unreferenced content SHOULD be configurable. Upon receipt of a DELETE request, the Receiving entity should:</p>
     <p>2a. delete the referenced content and return a 200 OK HTTP Response code</p>
     <p>2b. delete the corresponding folder if the last file in the folder is deleted and it is not a root folder but not necessarily recursively deleting empty folders.</p>
    <li data-md>
     <p>To avoid delay associated with the TCP handshake, the Ingest Source SHOULD use Persistent TCP connections.</p>
    <li data-md>
     <p>To avoid head of line blocking, the Ingest Source SHOULD use Multiple Parallel TCP connections to transfer the streaming presentation that it is generating. For example, the Ingest Source POSTs each bit rate in a Media Presentation over a different TCP Session.</p>
   </ol>
   <h4 class="heading settled" data-level="7.1.3" id="DASH_Ingest_naming"><span class="secno">7.1.3. </span><span class="content">Unique segment and manifest naming</span><a class="self-link" href="#DASH_Ingest_naming"></a></h4>
   <ol>
    <li data-md>
     <p>The Ingest Source MUST ensure all <a data-link-type="dfn" href="#media-objects" id="ref-for-media-objects④">Media objects</a> (video segments, audio segments, init segments and caption segments) have unique paths. This uniqueness applies across all ingested content in previous sessions, as well as the current session. This requirement ensures previously cached content (i.e., by a CDN) is not inadvertently served instead of newer content of the same name.</p>
    <li data-md>
     <p>The Ingest Source MUST ensure all objects in a <a data-link-type="dfn" href="#live-stream-event" id="ref-for-live-stream-event①">Live stream event</a> are contained within the configured path. Should the Receiving entity receive Media Objects outside of the allowed path, it SHOULD return an HTTP 403 Forbidden response.</p>
    <li data-md>
     <p>For each live stream event, the Ingest Source MUST provide unique paths for the <a data-link-type="dfn" href="#manifest-objects" id="ref-for-manifest-objects④">Manifest objects</a>. One suggested method of achieving this is to introduce a timestamp of the start of the live stream event in to the manifest path. An event is defined by the explicit start and stop of the encoding process.</p>
    <li data-md>
     <p>When receiving objects with the same path as an existing object, the Receiving entity MUST over-write the existing objects with the newer objects of the same path.</p>
    <li data-md>
     <p>The Ingest Source MUST include a number which is monotonically increasing with each new Media Object at the end of Media objects name. It MUST be possible to retrieve this numeric suffix via a regular expression. A common method is to use the time at which the Media Segment was created divided by the Media object duration.</p>
    <li data-md>
     <p>The Ingest Source MUST identify Media objects containing initialization fragments by using either the .init file extension OR "init" in their file name. All other objects which do not contain initialization fragments MUST NOT include the string "init" in their file name.</p>
    <li data-md>
     <p>The Ingest source MUST include a file extension and a MIME-type for all media objects. The following file extensions and mime-types are the ONLY permissible combinations to be used:</p>
   </ol>
   <p>Table 6 outlines the formats that media and manifest objects are expected
	to follow based on their file extension. Segments
	may be formatted as MPEG-4 <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> .mp4, .m4v, m4a, CMAF based <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> for .cmf[v.a.m.t], or <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a> for .mpd or HLS <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a> for .m3u8. Alternatively
    .ts based files follow <a data-link-type="biblio" href="#biblio-mpeg2ts">[MPEG2TS]</a>. Note that MPEG-2 TS is a commonly used format today,
    and supported as ingest format. However we expect it gradually phased out in the coming 5 years.
	For consistency between profiles and DASH and HLS segments based on <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> based
    media objects would be preferred.</p>
   <p>Table 6:</p>
   <table class="def">
    <tbody>
     <tr>
      <th> File Extension 
      <th> Mime Type 
     <tr>
      <th> .m3u8 
      <th> application/x-mpegURL or vnd.apple.mpegURL 
     <tr>
      <th> .mpd 
      <th> application/x-mpegURL 
     <tr>
      <th> .cmfv 
      <th> video/mp4 
     <tr>
      <th> .cmfa 
      <th> audio/mp4 
     <tr>
      <th> application/mp4 
     <tr>
      <th> .cmfm 
      <th> application/mp4 
     <tr>
      <th> .mp4 
      <th> video/mp4 or application/mp4 
     <tr>
      <th> .m4v 
      <th> video/mp4 
     <tr>
      <th> .m4a 
      <th> audio/mp4 
     <tr>
      <th> .m4s 
      <th> video/iso.segment 
     <tr>
      <th> .init 
      <th> video/mp4 
     <tr>
      <th> .header 
      <th> video/mp4 
     <tr>
      <th> .key 
      <th> to be defined 
   </table>
   <h4 class="heading settled" data-level="7.1.4" id="DASH_Ingest_DNS_Lookups"><span class="secno">7.1.4. </span><span class="content">DNS lookups</span><a class="self-link" href="#DASH_Ingest_DNS_Lookups"></a></h4>
   <p>DNS lookup requirements are defined in the general protocol requirements section <a href="#general">§5 General Ingest Protocol Behavior</a>.</p>
   <h4 class="heading settled" data-level="7.1.5" id="DASH_Ingest_Publisher_Identification"><span class="secno">7.1.5. </span><span class="content">Ingest source identification</span><a class="self-link" href="#DASH_Ingest_Publisher_Identification"></a></h4>
   <ol>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source③⑧">Ingest source</a> MUST include a User-Agent header (which provides information about brand name, version number, and build number in a readable format) in all allowed HTTP messages. The Receiving entity MUST log the received User-Agent, along with other relevant HTTP Header data to facilitate troubleshooting.</p>
   </ol>
   <h4 class="heading settled" data-level="7.1.6" id="DASH_Ingest_Common_Failure_Behaviors"><span class="secno">7.1.6. </span><span class="content">Common Failure behaviors</span><a class="self-link" href="#DASH_Ingest_Common_Failure_Behaviors"></a></h4>
   <p>The following items define the behavior of an ingest source when encountering certain conditions.</p>
   <ol>
    <li data-md>
     <p>When the ingest source receives a TCP connection attempt timeout, abort midstream, response timeout, TCP send/receive timeout or 5xx response when attempting to POST content to the <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity①③">Receiving entity</a>, it MUST</p>
     <p>1a. For manifest objects: re-resolve DNS on each retry (per the DNS TTL) and retry indefinitely.</p>
     <p>1b. For media objects: re-resolve DNS on each retry (per the DNS TTL) and continue uploading for n seconds, where n is the segment duration. After it reaches the media object duration value, drop the current data and continue with the next media object, updating the manifest object with a discontinuity marker appropriate for the protocol format at hand. To maintain continuity of the time-line, the ingest source SHOULD continue to upload the missing media object with a lower priority. Once a media object is successfully uploaded, the ingest source SHOULD update the corresponding manifest object to reflect the now available media object. Note that many HLS clients do not like changes to manifest files, such as removing a previously present discontinuity, so care should be taken in choosing to make such updates.</p>
    <li data-md>
     <p>Upon receipt of an HTTP 403 or 400 error, for all objects (manifest and non-manifest), the ingest source MUST not retry and stop attempting to ingesting objects and provide a log or fatal error condition.</p>
   </ol>
   <h3 class="heading settled" data-level="7.2" id="HLS_Ingest_specific_requirements"><span class="secno">7.2. </span><span class="content">HLS specific requirements</span><a class="self-link" href="#HLS_Ingest_specific_requirements"></a></h3>
   <h4 class="heading settled" data-level="7.2.1" id="HLS_file_extensions_and_mime_types"><span class="secno">7.2.1. </span><span class="content">File extensions and mime-types</span><a class="self-link" href="#HLS_file_extensions_and_mime_types"></a></h4>
   <p>When ingesting prepared HLS content, the Ingest Source MUST:</p>
   <ol>
    <li data-md>
     <p>use a .m3u8 file extension for parent and child playlists.</p>
    <li data-md>
     <p>use a .key file extension for any keyfiles posted to the receiving entity for client delivery.</p>
    <li data-md>
     <p>use a ".ts" file extension for segments encapsulated in a Transport Stream File Format.</p>
    <li data-md>
     <p>use one of the allowed file extensions (per the table above) appropriate for the mime-type of the content encapsulated using <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a>, it MUST NOT use a ".ts" file extension.</p>
   </ol>
   <h4 class="heading settled" data-level="7.2.2" id="Upload_order"><span class="secno">7.2.2. </span><span class="content">Upload order</span><a class="self-link" href="#Upload_order"></a></h4>
   <p>In accordance with the HTTP live Streaming <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a> recommendation, ingest sources
    MUST upload all required files for a specific bitrate and segment before proceeding to the next segment.
    For example, for a bitrate that has segments and a playlist that updates every segment and key files,
    ingest sources upload the segment file followed by a key file (optional) and the playlist file in serial fashion.
    The encoder MUST only move to the next segment after the previous segment has been successfully
    uploaded or after the segment duration time has elapsed. The order of operation should be:</p>
   <ol>
    <li data-md>
     <p>Upload media segment,</p>
    <li data-md>
     <p>Optionally upload key file, if required,</p>
    <li data-md>
     <p>Upload the .m3u8.</p>
   </ol>
   <p>If there is a problem with any of the Steps, retry them.
    Do not proceed to Step 3 until Step 1 succeeds or times out as described in common
    failure behaviors above. Failed uploads MUST result in a stream manifest Discontinuity per <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a>.</p>
   <h4 class="heading settled" data-level="7.2.3" id="HLS_Ingest_Encryption"><span class="secno">7.2.3. </span><span class="content">Encryption</span><a class="self-link" href="#HLS_Ingest_Encryption"></a></h4>
   <ol>
    <li data-md>
     <p>The ingest source MAY choose to encrypt the media segments and publish the corresponding keyfile to the <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity①④">Receiving entity</a>.</p>
   </ol>
   <h4 class="heading settled" data-level="7.2.4" id="HLS_Ingest_relative_paths"><span class="secno">7.2.4. </span><span class="content">Relative paths</span><a class="self-link" href="#HLS_Ingest_relative_paths"></a></h4>
   <ol>
    <li data-md>
     <p>The ingest source SHOULD use Relative URL paths to address each segment within the stream level manifest.</p>
   </ol>
   <h4 class="heading settled" data-level="7.2.5" id="HLS_Ingest_Resiliency"><span class="secno">7.2.5. </span><span class="content">Resiliency</span><a class="self-link" href="#HLS_Ingest_Resiliency"></a></h4>
   <ol>
    <li data-md>
     <p>When ingesting media objects to multiple receiving entities, the ingest source MUST send identical media objects with identical names</p>
    <li data-md>
     <p>To allow resumption of failed sessions and to avoid reuse of previously cached content, the ingest source MUST NOT restart object names or use previously used object names.</p>
    <li data-md>
     <p>When multiple ingest sources are used, they MUST use consistent media object names including when reconnecting due to any application or transport error. A common approach is to use (epoch time)/(segment duration) as the object name.</p>
   </ol>
   <h3 class="heading settled" data-level="7.3" id="DASH_requirements"><span class="secno">7.3. </span><span class="content">DASH specific requirements</span><a class="self-link" href="#DASH_requirements"></a></h3>
   <h4 class="heading settled" data-level="7.3.1" id="DASH_mime_types_and_extensions"><span class="secno">7.3.1. </span><span class="content">File extensions and mime-types</span><a class="self-link" href="#DASH_mime_types_and_extensions"></a></h4>
   <p>When ingesting prepared DASH content, the Ingest Source MUST:</p>
   <ol>
    <li data-md>
     <p>use a ".mpd" file extension for manifest objects.</p>
    <li data-md>
     <p>use one of the allowed file extensions (see table above) for Media objects. It MUST NOT use a ".ts" file extension.</p>
   </ol>
   <h4 class="heading settled" data-level="7.3.2" id="DASH_Relative_paths_and_extensions"><span class="secno">7.3.2. </span><span class="content">Relative paths</span><a class="self-link" href="#DASH_Relative_paths_and_extensions"></a></h4>
   <ol>
    <li data-md>
     <p>The ingest source SHOULD use Relative URL paths to address each segment within the manifest object.</p>
   </ol>
   <h3 class="heading settled" data-level="7.4" id="CMAF_requirements"><span class="secno">7.4. </span><span class="content">CMAF specific requirements</span><a class="self-link" href="#CMAF_requirements"></a></h3>
   <p>When the media source is using CMAF for the Media Objects, it MUST also prepare format specific manifest files (.m3u8 for   HLS and .mpd for DASH). The format specific manifest files MUST reference the CMAF content such that it can be shared between the two formats (e.g., same path and file names).</p>
   <h2 class="heading settled" data-level="8" id="Example_ingest"><span class="secno">8. </span><span class="content">Illustrative Example of using CMAF and DASH ingest specification</span><a class="self-link" href="#Example_ingest"></a></h2>
   <p>In this section we provide some example deployments for live streaming, mapping to the architecture
  defined in DASH-IF live Task Force. Diagram 9 shows an example where a separate packager
  and origin server are used.</p>
   <p>Diagram 9: Example setup schema with CMAF ingest and DASH/HLS ingest</p>
   <figure> <img src="Images/DiagramX.png"> </figure>
   <p>The broadcast source is used as input to the live <a data-link-type="dfn" href="#abr" id="ref-for-abr">ABR</a> encoder. The broadcast sources can be
  original SDI signals from a broadcast facility or TS streams intercepted from a broadcast
  that need to be re-used in an <a data-link-type="dfn" href="#ott" id="ref-for-ott">OTT</a> distribution workflow. The live ABR encoder source performs the
  ABR encoding of the tracks into CMAF tracks and functions as the ingest source in the CMAF
  ingest interface. Multiple live ABR encoder sources can be used, providing redundant inputs to the packager,
  which is the media processing entity consuming the CMAF ingest. The packager is receiving the
  different CMAF tracks. The ingest follows the CMAF Ingest specification in this document, allowing for failover,
  redundancy and many of the other features related to the content tracks. The live encoder source performs the following tasks:</p>
   <ul>
    <li data-md>
     <p>It demuxes and receives the MPEG-2 transport stream and/or HD SDI signal</p>
    <li data-md>
     <p>It formats the metadata in these streams such as SCTE-35 or SCTE 104 to timed metadata tracks</p>
    <li data-md>
     <p>It performs a high quality ABR encoding in different bit-rates with aligned switching points</p>
    <li data-md>
     <p>It packages all media and timed text tracks as CMAF compliant tracks and signals track roles
in kind boxes</p>
    <li data-md>
     <p>It POSTs the addressable media objects composing the tracks to the live packager according
to the CMAF ingest specification interface defined in this document.</p>
    <li data-md>
     <p>The CMAF ingest allows multiple live encoder sources and packagers to be deployed benefiting
from redundant stream creation, avoiding timeline discontinuities due to failures as much as
possible.</p>
    <li data-md>
     <p>In case the receiver fails, it will reconnect and resend as defined in the section on failover once it
reconnects</p>
    <li data-md>
     <p>In case the live encoder source fails it will restart and perform the steps as detailed in the section on      failover</p>
   </ul>
   <p>The live encoder source can be deployed in the cloud or on a bare metal server or even as a dedicated hardware.
   The live encoder source may have some tools or configuration API’s to author the CMAF tracks and feed
   instruction/properties from the original SDI or broadcast into the CMAF tracks. The packager
   receives the ingested streams, and performs the following tasks.</p>
   <ul>
    <li data-md>
     <p>It receives the CMAF tracks, grouping switching sets based on switching set constraints</p>
    <li data-md>
     <p>When packaging to MPEG DASH, an adaptationset is created for each switchingset ingested</p>
    <li data-md>
     <p>The near constant fragment duration is used to generate segmenttemplate based presentation
 using either $Number$ or $Time$</p>
    <li data-md>
     <p>In case changes happen, the packager can update the manifest and embed inband events to trigger
 manifest updates in the fragments</p>
    <li data-md>
     <p>The DASH Packager encrypts media segments according to key information available. This key information
 is typically exchanged by protocol defined in Content Protection Interchange Format (CPIX) this
 allows configuration of the content keys, initialization vectors and embedding encryption information in the manifest</p>
    <li data-md>
     <p>The DASH packager signals subtitles in the manifest based on received CMAF streams and roles signalled in
 kind box</p>
    <li data-md>
     <p>In case a fragment is missing and SegmentTimeline is used, the packager may signal a discontinuity in the
 Manifest presentation description</p>
    <li data-md>
     <p>In case a low latency mode is used, the packager may make output available before the entire fragment
 is received in the chunked transfer encoding</p>
    <li data-md>
     <p>The packager may also have a proprietary API similar to the live source, for configuration of aspects
 like the segmentTimeBuffer, DVR window, encryption modes enabled etc.</p>
    <li data-md>
     <p>The packager uses a DASH or HLS ingest to push content to an origin server of content delivery network.       Alternatively, it could also make content directly available as DASH or HLS as an origin server. In this       case DASH/HLS ingest is avoided, and the packager also serves as the origin server.</p>
    <li data-md>
     <p>The packager converts the timed metadata track and uses it to convert to either MPD Events or inband events
 signalled in the manifest.</p>
    <li data-md>
     <p>The packager may also generate HLS or other streaming media presentations based on the input.</p>
    <li data-md>
     <p>In case the packager crashes or fails, it will restart itself and wait for the ingest source to perform the   actions as detailed in the section on failover</p>
   </ul>
   <p>The content delivery network (CDN) consumes a DASH/HLS ingest, or serves as a proxy for content delivered to a client.
         The CDN, in case it is consuming the POST based DASH/HLS ingest performs the following tasks</p>
   <ul>
    <li data-md>
     <p>it stores all posted content and makes them available for HTTP GET requests from locations
 corresponding to the paths signalled in the manifest</p>
    <li data-md>
     <p>it occasionally deletes content based on instructions from the ingest source, in this setup the packager</p>
    <li data-md>
     <p>in case low latency mode is used, content could be made available before the entire pieces of content are available</p>
    <li data-md>
     <p>It updates the manifest accordingly when a manifest update is received</p>
    <li data-md>
     <p>It serves as a cache proxy for HTTP get requests forwarded to the packager</p>
   </ul>
   <p>In case the CDN serves as a proxy, it only forwards requests for content to the packager to receive the content,and caches relevant segments for a duration N until it expires.</p>
   <p>The client receives DASH or HLS streams, and is not affected by the specification of this work. Nevertheless, it is expected that by using a common media application format, less caching and less overhead in the network
      will result in a better user experience. The client still needs to retrieve license and key information by steps defined outside of this specification. Information
      on how to retrieve this information will typically be signalled in the manifest prepared by the packager.</p>
   <p>This example aims to illustrate how the specification defined in this document can be used to provide a
      live streaming presentation to clients, this example does not preclude other ways of using the
      specification and protocols defined in this document.</p>
   <p>A second example can be seen in Diagram 10. It constitutes the reference workflow for chunked DASH CMAF
      under development by DASH-IF and DVB. In this workflow a contribution encoder produces an <a data-link-type="dfn" href="#rtp" id="ref-for-rtp">RTP</a> mezzanine stream
      that is transmitted to FFMPEG, an open source encoder/packager running on a server. Alternatively, a file resource may be used. In this workflow FFMPEG functions as the ingest source. FFMPEG produces the ingest stream with different ABR encoded CMAF tracks. In addition, it also sends a manifest that complies with DASH-IF and DVB low latency CMAF specification and MPD updates. The CMAF tracks also contain respective timing information (prft etc.).
      In this case the ingest source implements interface 2 DASH ingest. But as in this case the DASH
      presentation uses CMAF, the media and track constraints of interface 1 are also satisfied. By also
      resending CMAF Headers in case of failures both interfaces may be satisfied.</p>
   <p>The origin server is used to pass the streams to the client, and may in some cases also perform a re-encryption
      or re-packaging of the streaming presentation as needed by the client (in case encryption is needed for example).  
      The target client is DASH.js and an end-to-end latency of maximum 3500 ms is targeted.</p>
   <p>This example DASH reference workflow uses DASH Ingest that does not employ encryption and timed metadata and uses CMAF formatting. This exploits the synergies between the two interfaces defined in this document
      hence the ingest between FFMPEG and the origin server may implement both interfaces simultaneously.</p>
   <p>To receive the stream as a CMAF ingest for re-packaging at the origin the following steps can be applied.
	  This is the case where interface 1 and interface 2 are used interchangeably, hence the live encoder can either
	  ingest to an origin that supports interface 2 with CMAF formatting, including the requirements from interface 1.</p>
   <ol>
    <li data-md>
     <p>Ignore the DASH Manifest</p>
    <li data-md>
     <p>Ignore the segment names, only look at the relative path to identify the stream names</p>
    <li data-md>
     <p>Ignore the HTTP Delete commands</p>
   </ol>
   <p>The approaches for authentication and DNS resolution are similar for the two profiles/interfaces, as are the track
      formatting in case CMAF based media are used. This example does not use timed metadata. The ingest source
      may resend the CMAF header or init fragment in case of connection failures to conform to the CMAF ingest
      specification. The origin server can then be used to repackage or re-encrypt the streams.</p>
   <p>To receive the stream as a DASH Ingest in this workflow, the steps described in DASH Ingest may be applied.</p>
   <p>Diagram 10: DASH-IF Reference DASH-IF Live Chunked CMAF Production Workflow</p>
   <figure> <img src="Images/DiagramXI.png"> </figure>
   <h2 class="heading settled" data-level="9" id="iana"><span class="secno">9. </span><span class="content">IANA Considerations</span><a class="self-link" href="#iana"></a></h2>
   <p>This memo includes no request to IANA.</p>
   <h2 class="heading settled" data-level="10" id="contrib"><span class="secno">10. </span><span class="content">Acknowledgements</span><a class="self-link" href="#contrib"></a></h2>
   <p>We thank the contributors to draft and the support from the following
   companies: Huawei, Akamai, BBC R&amp;D, CenturyLink, Microsoft, Unified Streaming, Facebook, Hulu,
   Comcast, ITV, Qualcomm, Tencent, Samsung, MediaExcel, Harmonic, Sony, Arris, BitMovin, DSR and AWS Elemental.</p>
   <h2 class="heading settled" data-level="11" id="references_custom"><span class="secno">11. </span><span class="content">References</span><a class="self-link" href="#references_custom"></a></h2>
   <h3 class="heading settled" data-level="11.1" id="references-url"><span class="secno">11.1. </span><span class="content">URL References</span><a class="self-link" href="#references-url"></a></h3>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="fmp4git">fmp4git</dfn> Unified Streaming github fmp4 ingest,
                "https://github.com/unifiedstreaming/fmp4-ingest".</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="mozillatls">MozillaTLS</dfn> Mozilla Wikie Security/Server Side TLS
                https://wiki.mozilla.org/Security/Server_Side_TLS
                #Intermediate_compatibility_.28default.29
                (last acessed 30th of March 2018)</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="ms-sstr">MS-SSTR</dfn> Smooth streaming protocol
              https://msdn.microsoft.com/en-us/library/ff469518.aspx
                last updated March 16 2018 (last acessed June 11 2018)</p>
  </main>
  <div data-fill-with="conformance">
   <h2 class="no-ref no-num heading settled" id="conformance"><span class="content"> Conformance</span><a class="self-link" href="#conformance"></a></h2>
   <p> Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology.
            The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
            in the normative parts of this document
            are to be interpreted as described in RFC 2119.
            However, for readability,
            these words do not appear in all uppercase letters in this specification. </p>
   <p> All of the text of this specification is normative
            except sections explicitly marked as non-normative, examples, and notes. <a data-link-type="biblio" href="#biblio-rfc2119">[RFC2119]</a> </p>
   <p> Examples in this specification are introduced with the words “for example”
            or are set apart from the normative text with <code>class="example"</code>, like this: </p>
   <div class="example" id="example-example"><a class="self-link" href="#example-example"></a> This is an example of an informative example. </div>
   <p> Informative notes begin with the word “Note”
            and are set apart from the normative text with <code>class="note"</code>, like this: </p>
   <p class="note" role="note"> Note, this is an informative note. </p>
  </div>
<script>
(function() {
  "use strict";
  var collapseSidebarText = '<span aria-hidden="true">←</span> '
                          + '<span>Collapse Sidebar</span>';
  var expandSidebarText   = '<span aria-hidden="true">→</span> '
                          + '<span>Pop Out Sidebar</span>';
  var tocJumpText         = '<span aria-hidden="true">↑</span> '
                          + '<span>Jump to Table of Contents</span>';

  var sidebarMedia = window.matchMedia('screen and (min-width: 78em)');
  var autoToggle   = function(e){ toggleSidebar(e.matches) };
  if(sidebarMedia.addListener) {
    sidebarMedia.addListener(autoToggle);
  }

  function toggleSidebar(on) {
    if (on == undefined) {
      on = !document.body.classList.contains('toc-sidebar');
    }

    /* Don’t scroll to compensate for the ToC if we’re above it already. */
    var headY = 0;
    var head = document.querySelector('.head');
    if (head) {
      // terrible approx of "top of ToC"
      headY += head.offsetTop + head.offsetHeight;
    }
    var skipScroll = window.scrollY < headY;

    var toggle = document.getElementById('toc-toggle');
    var tocNav = document.getElementById('toc');
    if (on) {
      var tocHeight = tocNav.offsetHeight;
      document.body.classList.add('toc-sidebar');
      document.body.classList.remove('toc-inline');
      toggle.innerHTML = collapseSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, 0 - tocHeight);
      }
      tocNav.focus();
      sidebarMedia.addListener(autoToggle); // auto-collapse when out of room
    }
    else {
      document.body.classList.add('toc-inline');
      document.body.classList.remove('toc-sidebar');
      toggle.innerHTML = expandSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, tocNav.offsetHeight);
      }
      if (toggle.matches(':hover')) {
        /* Unfocus button when not using keyboard navigation,
           because I don’t know where else to send the focus. */
        toggle.blur();
      }
    }
  }

  function createSidebarToggle() {
    /* Create the sidebar toggle in JS; it shouldn’t exist when JS is off. */
    var toggle = document.createElement('a');
      /* This should probably be a button, but appearance isn’t standards-track.*/
    toggle.id = 'toc-toggle';
    toggle.class = 'toc-toggle';
    toggle.href = '#toc';
    toggle.innerHTML = collapseSidebarText;

    sidebarMedia.addListener(autoToggle);
    var toggler = function(e) {
      e.preventDefault();
      sidebarMedia.removeListener(autoToggle); // persist explicit off states
      toggleSidebar();
      return false;
    }
    toggle.addEventListener('click', toggler, false);


    /* Get <nav id=toc-nav>, or make it if we don’t have one. */
    var tocNav = document.getElementById('toc-nav');
    if (!tocNav) {
      tocNav = document.createElement('p');
      tocNav.id = 'toc-nav';
      /* Prepend for better keyboard navigation */
      document.body.insertBefore(tocNav, document.body.firstChild);
    }
    /* While we’re at it, make sure we have a Jump to Toc link. */
    var tocJump = document.getElementById('toc-jump');
    if (!tocJump) {
      tocJump = document.createElement('a');
      tocJump.id = 'toc-jump';
      tocJump.href = '#toc';
      tocJump.innerHTML = tocJumpText;
      tocNav.appendChild(tocJump);
    }

    tocNav.appendChild(toggle);
  }

  var toc = document.getElementById('toc');
  if (toc) {
    createSidebarToggle();
    toggleSidebar(sidebarMedia.matches);

    /* If the sidebar has been manually opened and is currently overlaying the text
       (window too small for the MQ to add the margin to body),
       then auto-close the sidebar once you click on something in there. */
    toc.addEventListener('click', function(e) {
      if(e.target.tagName.toLowerCase() == "a" && document.body.classList.contains('toc-sidebar') && !sidebarMedia.matches) {
        toggleSidebar(false);
      }
    }, false);
  }
  else {
    console.warn("Can’t find Table of Contents. Please use <nav id='toc'> around the ToC.");
  }

  /* Wrap tables in case they overflow */
  var tables = document.querySelectorAll(':not(.overlarge) > table.data, :not(.overlarge) > table.index');
  var numTables = tables.length;
  for (var i = 0; i < numTables; i++) {
    var table = tables[i];
    var wrapper = document.createElement('div');
    wrapper.className = 'overlarge';
    table.parentNode.insertBefore(wrapper, table);
    wrapper.appendChild(table);
  }

})();
</script>
  <h2 class="no-num no-ref heading settled" id="index"><span class="content">Index</span><a class="self-link" href="#index"></a></h2>
  <h3 class="no-num no-ref heading settled" id="index-defined-here"><span class="content">Terms defined by this specification</span><a class="self-link" href="#index-defined-here"></a></h3>
  <ul class="index">
   <li><a href="#abr">ABR</a><span>, in §3</span>
   <li><a href="#basemediadecodetime">basemediadecodetime</a><span>, in §3</span>
   <li><a href="#cmaf-chunk">CMAF chunk</a><span>, in §3</span>
   <li><a href="#cmaf-fragment">CMAF fragment</a><span>, in §3</span>
   <li><a href="#cmaf-header">CMAF Header</a><span>, in §3</span>
   <li><a href="#cmaf-ingest">CMAF Ingest</a><span>, in §3</span>
   <li><a href="#cmaf-media-object">CMAF Media object</a><span>, in §3</span>
   <li><a href="#cmaf-segment">CMAF segment</a><span>, in §3</span>
   <li><a href="#cmafstream">CMAFstream</a><span>, in §3</span>
   <li><a href="#cmaf-track">CMAF Track</a><span>, in §3</span>
   <li><a href="#connection">Connection</a><span>, in §3</span>
   <li><a href="#dash-ingest">DASH Ingest</a><span>, in §3</span>
   <li><a href="#elng">elng</a><span>, in §3</span>
   <li><a href="#event-presentation-time">Event Presentation Time</a><span>, in §3</span>
   <li><a href="#event-received-time">Event Received Time</a><span>, in §3</span>
   <li><a href="#fmp4git">fmp4git</a><span>, in §11.1</span>
   <li><a href="#ftyp">ftyp</a><span>, in §3</span>
   <li><a href="#hls-ingest">HLS Ingest</a><span>, in §3</span>
   <li><a href="#http-post">HTTP POST</a><span>, in §3</span>
   <li><a href="#ingest-source">Ingest source</a><span>, in §3</span>
   <li><a href="#ingest-stream">Ingest Stream</a><span>, in §3</span>
   <li><a href="#live-encoder">Live encoder</a><span>, in §3</span>
   <li><a href="#live-stream-event">Live stream event</a><span>, in §3</span>
   <li><a href="#manifest-objects">Manifest objects</a><span>, in §3</span>
   <li><a href="#mdat">mdat</a><span>, in §3</span>
   <li><a href="#mdhd">mdhd</a><span>, in §3</span>
   <li><a href="#media-fragment">Media fragment</a><span>, in §3</span>
   <li><a href="#media-objects">Media objects</a><span>, in §3</span>
   <li><a href="#media-processing-entity">Media processing entity</a><span>, in §3</span>
   <li><a href="#mfra">mfra</a><span>, in §3</span>
   <li><a href="#moof">moof</a><span>, in §3</span>
   <li><a href="#moov">moov</a><span>, in §3</span>
   <li><a href="#mozillatls">MozillaTLS</a><span>, in §11.1</span>
   <li><a href="#ms-sstr">MS-SSTR</a><span>, in §11.1</span>
   <li><a href="#nmhd">nmhd</a><span>, in §3</span>
   <li><a href="#objects">Objects</a><span>, in §3</span>
   <li><a href="#ott">OTT</a><span>, in §3</span>
   <li><a href="#post_url">POST_URL</a><span>, in §3</span>
   <li><a href="#publishing-point">Publishing point</a><span>, in §3</span>
   <li><a href="#receiving-entity">Receiving entity</a><span>, in §3</span>
   <li><a href="#rtp">RTP</a><span>, in §3</span>
   <li><a href="#streaming-presentation">Streaming presentation</a><span>, in §3</span>
   <li><a href="#switching-set">Switching set</a><span>, in §3</span>
   <li><a href="#tcp">TCP</a><span>, in §3</span>
   <li><a href="#tfdt">tfdt</a><span>, in §3</span>
  </ul>
  <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
  <h3 class="no-num no-ref heading settled" id="normative"><span class="content">Normative References</span><a class="self-link" href="#normative"></a></h3>
  <dl>
   <dt id="biblio-dvb-dash">[DVB-DASH]
   <dd><a href="http://www.etsi.org/deliver/etsi_ts/103200_103299/103285/01.02.01_60/ts_103285v010201p.pdf">ETSI TS 103 285 Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks</a>. March 2018. URL: <a href="http://www.etsi.org/deliver/etsi_ts/103200_103299/103285/01.02.01_60/ts_103285v010201p.pdf">http://www.etsi.org/deliver/etsi_ts/103200_103299/103285/01.02.01_60/ts_103285v010201p.pdf</a>
   <dt id="biblio-id3v2">[ID3v2]
   <dd><a href="http://id3.org/id3v2.4.0-structure">ID3 tag version 2.4.0 - Main Structure</a>. URL: <a href="http://id3.org/id3v2.4.0-structure">http://id3.org/id3v2.4.0-structure</a>
   <dt id="biblio-iso-639-2">[ISO-639-2]
   <dd>ISO/TC 37/SC 2. <a href="https://www.iso.org/standard/4767.html">Codes for the representation of names of languages -- Part 2: Alpha-3 code</a>. 1998. International Standard. URL: <a href="https://www.iso.org/standard/4767.html">https://www.iso.org/standard/4767.html</a>
   <dt id="biblio-isobmff">[ISOBMFF]
   <dd><a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c068960_ISO_IEC_14496-12_2015.zip">Information technology — Coding of audio-visual objects — Part 12: ISO Base Media File Format</a>. December 2015. International Standard. URL: <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c068960_ISO_IEC_14496-12_2015.zip">http://standards.iso.org/ittf/PubliclyAvailableStandards/c068960_ISO_IEC_14496-12_2015.zip</a>
   <dt id="biblio-mpeg2ts">[MPEG2TS]
   <dd><a href="https://www.iso.org/standard/74427.html?browse=tc">Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems</a>. Published. URL: <a href="https://www.iso.org/standard/74427.html?browse=tc">https://www.iso.org/standard/74427.html?browse=tc</a>
   <dt id="biblio-mpeg4-30">[MPEG4-30]
   <dd><a href="https://www.iso.org/standard/75394.html?browse=tc">Information technology -- Coding of audio-visual objects -- Part 30: Timed text and other visual overlays in ISO base media file format</a>. Published. URL: <a href="https://www.iso.org/standard/75394.html?browse=tc">https://www.iso.org/standard/75394.html?browse=tc</a>
   <dt id="biblio-mpegcmaf">[MPEGCMAF]
   <dd><a href="https://www.iso.org/standard/71975.html?browse=tc">Information technology -- Multimedia application format (MPEG-A) -- Part 19: Common media application format (CMAF) for segmented media</a>. Published. URL: <a href="https://www.iso.org/standard/71975.html?browse=tc">https://www.iso.org/standard/71975.html?browse=tc</a>
   <dt id="biblio-mpegdash">[MPEGDASH]
   <dd><a href="https://www.iso.org/standard/65274.html?browse=tc">Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats</a>. Published. URL: <a href="https://www.iso.org/standard/65274.html?browse=tc">https://www.iso.org/standard/65274.html?browse=tc</a>
   <dt id="biblio-mpeghevc">[MPEGHEVC]
   <dd><a href="https://www.iso.org/standard/69668.html?browse=tc">Information technology -- High efficiency coding and media delivery in heterogeneous environments -- Part 2: High efficiency video coding</a>. Published. URL: <a href="https://www.iso.org/standard/69668.html?browse=tc">https://www.iso.org/standard/69668.html?browse=tc</a>
   <dt id="biblio-rfc1035">[RFC1035]
   <dd>P.V. Mockapetris. <a href="https://tools.ietf.org/html/rfc1035">Domain names - implementation and specification</a>. November 1987. Internet Standard. URL: <a href="https://tools.ietf.org/html/rfc1035">https://tools.ietf.org/html/rfc1035</a>
   <dt id="biblio-rfc2119">[RFC2119]
   <dd>S. Bradner. <a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>. March 1997. Best Current Practice. URL: <a href="https://tools.ietf.org/html/rfc2119">https://tools.ietf.org/html/rfc2119</a>
   <dt id="biblio-rfc2626">[RFC2626]
   <dd>P. Nesser II. <a href="https://tools.ietf.org/html/rfc2626">The Internet and the Millennium Problem (Year 2000)</a>. June 1999. Informational. URL: <a href="https://tools.ietf.org/html/rfc2626">https://tools.ietf.org/html/rfc2626</a>
   <dt id="biblio-rfc2818">[RFC2818]
   <dd>E. Rescorla. <a href="https://tools.ietf.org/html/rfc2818">HTTP Over TLS</a>. May 2000. Informational. URL: <a href="https://tools.ietf.org/html/rfc2818">https://tools.ietf.org/html/rfc2818</a>
   <dt id="biblio-rfc3986">[RFC3986]
   <dd>T. Berners-Lee; R. Fielding; L. Masinter. <a href="https://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>. January 2005. Internet Standard. URL: <a href="https://tools.ietf.org/html/rfc3986">https://tools.ietf.org/html/rfc3986</a>
   <dt id="biblio-rfc7235">[RFC7235]
   <dd>R. Fielding, Ed.; J. Reschke, Ed.. <a href="https://tools.ietf.org/html/rfc7235">Hypertext Transfer Protocol (HTTP/1.1): Authentication</a>. June 2014. Proposed Standard. URL: <a href="https://tools.ietf.org/html/rfc7235">https://tools.ietf.org/html/rfc7235</a>
   <dt id="biblio-rfc7617">[RFC7617]
   <dd>J. Reschke. <a href="https://tools.ietf.org/html/rfc7617">The 'Basic' HTTP Authentication Scheme</a>. September 2015. Proposed Standard. URL: <a href="https://tools.ietf.org/html/rfc7617">https://tools.ietf.org/html/rfc7617</a>
   <dt id="biblio-rfc793">[RFC793]
   <dd>J. Postel. <a href="https://tools.ietf.org/html/rfc793">Transmission Control Protocol</a>. September 1981. Internet Standard. URL: <a href="https://tools.ietf.org/html/rfc793">https://tools.ietf.org/html/rfc793</a>
   <dt id="biblio-rfc8216">[RFC8216]
   <dd>R. Pantos, Ed.; W. May. <a href="https://tools.ietf.org/html/rfc8216">HTTP Live Streaming</a>. August 2017. Informational. URL: <a href="https://tools.ietf.org/html/rfc8216">https://tools.ietf.org/html/rfc8216</a>
   <dt id="biblio-scte35">[SCTE35]
   <dd><a href="https://www.scte.org/SCTEDocs/Standards/SCTE%2035%202019.pdf">Digital Program Insertion Cueing Message for Cable</a>. URL: <a href="https://www.scte.org/SCTEDocs/Standards/SCTE%2035%202019.pdf">https://www.scte.org/SCTEDocs/Standards/SCTE%2035%202019.pdf</a>
  </dl>
  <aside class="dfn-panel" data-for="cmaf-ingest">
   <b><a href="#cmaf-ingest">#cmaf-ingest</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-cmaf-ingest">4. Media Ingest Workflows and Profiles</a> <a href="#ref-for-cmaf-ingest①">(2)</a> <a href="#ref-for-cmaf-ingest②">(3)</a>
    <li><a href="#ref-for-cmaf-ingest③">6. Ingest Interface 1:  CMAF Ingest Protocol Behavior</a>
    <li><a href="#ref-for-cmaf-ingest④">6.1. CMAF Ingest General Considerations</a> <a href="#ref-for-cmaf-ingest⑤">(2)</a>
    <li><a href="#ref-for-cmaf-ingest⑥">6.6. Requirements for Timed Metadata</a>
    <li><a href="#ref-for-cmaf-ingest⑦">6.7. Requirements for Media Processing Entity Failover and Connection Error Handling</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="dash-ingest">
   <b><a href="#dash-ingest">#dash-ingest</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-dash-ingest">4. Media Ingest Workflows and Profiles</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="hls-ingest">
   <b><a href="#hls-ingest">#hls-ingest</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-hls-ingest">4. Media Ingest Workflows and Profiles</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="ingest-stream">
   <b><a href="#ingest-stream">#ingest-stream</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-ingest-stream">3. Conventions and Terminology</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="live-stream-event">
   <b><a href="#live-stream-event">#live-stream-event</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-live-stream-event">6.2. General Protocol Requirements</a>
    <li><a href="#ref-for-live-stream-event①">7.1.3. Unique segment and manifest naming</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="live-encoder">
   <b><a href="#live-encoder">#live-encoder</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-live-encoder">2. Introduction</a>
    <li><a href="#ref-for-live-encoder①">6.8. Requirements for Live Media Source Failover</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="ingest-source">
   <b><a href="#ingest-source">#ingest-source</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-ingest-source">2. Introduction</a> <a href="#ref-for-ingest-source①">(2)</a>
    <li><a href="#ref-for-ingest-source②">3. Conventions and Terminology</a>
    <li><a href="#ref-for-ingest-source③">4. Media Ingest Workflows and Profiles</a>
    <li><a href="#ref-for-ingest-source④">5. General Ingest Protocol Behavior</a> <a href="#ref-for-ingest-source⑤">(2)</a> <a href="#ref-for-ingest-source⑥">(3)</a> <a href="#ref-for-ingest-source⑦">(4)</a> <a href="#ref-for-ingest-source⑧">(5)</a> <a href="#ref-for-ingest-source⑨">(6)</a>
    <li><a href="#ref-for-ingest-source①⓪">6.1. CMAF Ingest General Considerations</a>
    <li><a href="#ref-for-ingest-source①①">6.2. General Protocol Requirements</a> <a href="#ref-for-ingest-source①②">(2)</a> <a href="#ref-for-ingest-source①③">(3)</a> <a href="#ref-for-ingest-source①④">(4)</a> <a href="#ref-for-ingest-source①⑤">(5)</a> <a href="#ref-for-ingest-source①⑥">(6)</a> <a href="#ref-for-ingest-source①⑦">(7)</a> <a href="#ref-for-ingest-source①⑧">(8)</a>
    <li><a href="#ref-for-ingest-source①⑨">6.6. Requirements for Timed Metadata</a> <a href="#ref-for-ingest-source②⓪">(2)</a>
    <li><a href="#ref-for-ingest-source②①">6.7. Requirements for Media Processing Entity Failover and Connection Error Handling</a> <a href="#ref-for-ingest-source②②">(2)</a> <a href="#ref-for-ingest-source②③">(3)</a> <a href="#ref-for-ingest-source②④">(4)</a>
    <li><a href="#ref-for-ingest-source②⑤">6.8. Requirements for Live Media Source Failover</a> <a href="#ref-for-ingest-source②⑥">(2)</a> <a href="#ref-for-ingest-source②⑦">(3)</a> <a href="#ref-for-ingest-source②⑧">(4)</a> <a href="#ref-for-ingest-source②⑨">(5)</a> <a href="#ref-for-ingest-source③⓪">(6)</a> <a href="#ref-for-ingest-source③①">(7)</a>
    <li><a href="#ref-for-ingest-source③②">7. Ingest Interface 2: DASH and HLS Ingest Protocol Behavior</a>
    <li><a href="#ref-for-ingest-source③③">7.1.1. Industry Compliance</a> <a href="#ref-for-ingest-source③④">(2)</a> <a href="#ref-for-ingest-source③⑤">(3)</a> <a href="#ref-for-ingest-source③⑥">(4)</a> <a href="#ref-for-ingest-source③⑦">(5)</a>
    <li><a href="#ref-for-ingest-source③⑧">7.1.5. Ingest source identification</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="publishing-point">
   <b><a href="#publishing-point">#publishing-point</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-publishing-point">6.1. CMAF Ingest General Considerations</a>
    <li><a href="#ref-for-publishing-point①">6.6. Requirements for Timed Metadata</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="manifest-objects">
   <b><a href="#manifest-objects">#manifest-objects</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-manifest-objects">4. Media Ingest Workflows and Profiles</a>
    <li><a href="#ref-for-manifest-objects①">7. Ingest Interface 2: DASH and HLS Ingest Protocol Behavior</a>
    <li><a href="#ref-for-manifest-objects②">7.1.2. HTTP connections</a> <a href="#ref-for-manifest-objects③">(2)</a>
    <li><a href="#ref-for-manifest-objects④">7.1.3. Unique segment and manifest naming</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="media-objects">
   <b><a href="#media-objects">#media-objects</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-media-objects">3. Conventions and Terminology</a>
    <li><a href="#ref-for-media-objects①">7. Ingest Interface 2: DASH and HLS Ingest Protocol Behavior</a>
    <li><a href="#ref-for-media-objects②">7.1.2. HTTP connections</a> <a href="#ref-for-media-objects③">(2)</a>
    <li><a href="#ref-for-media-objects④">7.1.3. Unique segment and manifest naming</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="objects">
   <b><a href="#objects">#objects</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-objects">3. Conventions and Terminology</a>
    <li><a href="#ref-for-objects①">7. Ingest Interface 2: DASH and HLS Ingest Protocol Behavior</a>
    <li><a href="#ref-for-objects②">7.1.1. Industry Compliance</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="streaming-presentation">
   <b><a href="#streaming-presentation">#streaming-presentation</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-streaming-presentation">7. Ingest Interface 2: DASH and HLS Ingest Protocol Behavior</a> <a href="#ref-for-streaming-presentation①">(2)</a>
    <li><a href="#ref-for-streaming-presentation②">7.1.1. Industry Compliance</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="media-processing-entity">
   <b><a href="#media-processing-entity">#media-processing-entity</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-media-processing-entity">6.1. CMAF Ingest General Considerations</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="receiving-entity">
   <b><a href="#receiving-entity">#receiving-entity</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-receiving-entity">2. Introduction</a> <a href="#ref-for-receiving-entity①">(2)</a> <a href="#ref-for-receiving-entity②">(3)</a>
    <li><a href="#ref-for-receiving-entity③">4. Media Ingest Workflows and Profiles</a> <a href="#ref-for-receiving-entity④">(2)</a> <a href="#ref-for-receiving-entity⑤">(3)</a> <a href="#ref-for-receiving-entity⑥">(4)</a>
    <li><a href="#ref-for-receiving-entity⑦">5. General Ingest Protocol Behavior</a> <a href="#ref-for-receiving-entity⑧">(2)</a>
    <li><a href="#ref-for-receiving-entity⑨">6.6. Requirements for Timed Metadata</a>
    <li><a href="#ref-for-receiving-entity①⓪">6.7. Requirements for Media Processing Entity Failover and Connection Error Handling</a>
    <li><a href="#ref-for-receiving-entity①①">7.1.1. Industry Compliance</a>
    <li><a href="#ref-for-receiving-entity①②">7.1.2. HTTP connections</a>
    <li><a href="#ref-for-receiving-entity①③">7.1.6. Common Failure behaviors</a>
    <li><a href="#ref-for-receiving-entity①④">7.2.3. Encryption</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="cmafstream">
   <b><a href="#cmafstream">#cmafstream</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-cmafstream">6.1. CMAF Ingest General Considerations</a>
    <li><a href="#ref-for-cmafstream①">6.2. General Protocol Requirements</a> <a href="#ref-for-cmafstream②">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="media-fragment">
   <b><a href="#media-fragment">#media-fragment</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-media-fragment">6.3. Requirements for Formatting Media Tracks</a> <a href="#ref-for-media-fragment①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="cmaf-header">
   <b><a href="#cmaf-header">#cmaf-header</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-cmaf-header">6.1. CMAF Ingest General Considerations</a> <a href="#ref-for-cmaf-header①">(2)</a> <a href="#ref-for-cmaf-header②">(3)</a>
    <li><a href="#ref-for-cmaf-header③">6.2. General Protocol Requirements</a> <a href="#ref-for-cmaf-header④">(2)</a>
    <li><a href="#ref-for-cmaf-header⑤">6.8. Requirements for Live Media Source Failover</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="cmaf-media-object">
   <b><a href="#cmaf-media-object">#cmaf-media-object</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-cmaf-media-object">6.1. CMAF Ingest General Considerations</a>
    <li><a href="#ref-for-cmaf-media-object①">6.2. General Protocol Requirements</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="cmaf-fragment">
   <b><a href="#cmaf-fragment">#cmaf-fragment</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-cmaf-fragment">6.1. CMAF Ingest General Considerations</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="cmaf-chunk">
   <b><a href="#cmaf-chunk">#cmaf-chunk</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-cmaf-chunk">6.1. CMAF Ingest General Considerations</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="cmaf-segment">
   <b><a href="#cmaf-segment">#cmaf-segment</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-cmaf-segment">6.1. CMAF Ingest General Considerations</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="cmaf-track">
   <b><a href="#cmaf-track">#cmaf-track</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-cmaf-track">6.1. CMAF Ingest General Considerations</a> <a href="#ref-for-cmaf-track①">(2)</a> <a href="#ref-for-cmaf-track②">(3)</a> <a href="#ref-for-cmaf-track③">(4)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="http-post">
   <b><a href="#http-post">#http-post</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-http-post">5. General Ingest Protocol Behavior</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="post_url">
   <b><a href="#post_url">#post_url</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-post_url">5. General Ingest Protocol Behavior</a>
    <li><a href="#ref-for-post_url①">6.2. General Protocol Requirements</a> <a href="#ref-for-post_url②">(2)</a> <a href="#ref-for-post_url③">(3)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="tcp">
   <b><a href="#tcp">#tcp</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-tcp">6.1. CMAF Ingest General Considerations</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="event-received-time">
   <b><a href="#event-received-time">#event-received-time</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-event-received-time">6.6. Requirements for Timed Metadata</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="event-presentation-time">
   <b><a href="#event-presentation-time">#event-presentation-time</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-event-presentation-time">6.6. Requirements for Timed Metadata</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="connection">
   <b><a href="#connection">#connection</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-connection">5. General Ingest Protocol Behavior</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="switching-set">
   <b><a href="#switching-set">#switching-set</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-switching-set">6.2. General Protocol Requirements</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="abr">
   <b><a href="#abr">#abr</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-abr">8. Illustrative Example of using CMAF and DASH ingest specification</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="rtp">
   <b><a href="#rtp">#rtp</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-rtp">8. Illustrative Example of using CMAF and DASH ingest specification</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="ott">
   <b><a href="#ott">#ott</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-ott">8. Illustrative Example of using CMAF and DASH ingest specification</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="moof">
   <b><a href="#moof">#moof</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-moof">3. Conventions and Terminology</a>
    <li><a href="#ref-for-moof①">6.1. CMAF Ingest General Considerations</a> <a href="#ref-for-moof②">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="ftyp">
   <b><a href="#ftyp">#ftyp</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-ftyp">6.1. CMAF Ingest General Considerations</a> <a href="#ref-for-ftyp①">(2)</a> <a href="#ref-for-ftyp②">(3)</a>
    <li><a href="#ref-for-ftyp③">6.5. Requirements for Timed Text, Captions and Subtitle Streams</a> <a href="#ref-for-ftyp④">(2)</a>
    <li><a href="#ref-for-ftyp⑤">6.7. Requirements for Media Processing Entity Failover and Connection Error Handling</a> <a href="#ref-for-ftyp⑥">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="moov">
   <b><a href="#moov">#moov</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-moov">6.1. CMAF Ingest General Considerations</a> <a href="#ref-for-moov①">(2)</a>
    <li><a href="#ref-for-moov②">6.3. Requirements for Formatting Media Tracks</a>
    <li><a href="#ref-for-moov③">6.5. Requirements for Timed Text, Captions and Subtitle Streams</a>
    <li><a href="#ref-for-moov④">6.7. Requirements for Media Processing Entity Failover and Connection Error Handling</a> <a href="#ref-for-moov⑤">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="mdat">
   <b><a href="#mdat">#mdat</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-mdat">6.1. CMAF Ingest General Considerations</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="mfra">
   <b><a href="#mfra">#mfra</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-mfra">6.1. CMAF Ingest General Considerations</a>
    <li><a href="#ref-for-mfra①">6.2. General Protocol Requirements</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="tfdt">
   <b><a href="#tfdt">#tfdt</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-tfdt">3. Conventions and Terminology</a>
    <li><a href="#ref-for-tfdt①">6.3. Requirements for Formatting Media Tracks</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="basemediadecodetime">
   <b><a href="#basemediadecodetime">#basemediadecodetime</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-basemediadecodetime">6.2. General Protocol Requirements</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="mdhd">
   <b><a href="#mdhd">#mdhd</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-mdhd">6.3. Requirements for Formatting Media Tracks</a> <a href="#ref-for-mdhd①">(2)</a> <a href="#ref-for-mdhd②">(3)</a>
    <li><a href="#ref-for-mdhd③">6.5. Requirements for Timed Text, Captions and Subtitle Streams</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="elng">
   <b><a href="#elng">#elng</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-elng">6.3. Requirements for Formatting Media Tracks</a> <a href="#ref-for-elng①">(2)</a>
    <li><a href="#ref-for-elng②">6.5. Requirements for Timed Text, Captions and Subtitle Streams</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="nmhd">
   <b><a href="#nmhd">#nmhd</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-nmhd">6.5. Requirements for Timed Text, Captions and Subtitle Streams</a>
    <li><a href="#ref-for-nmhd①">6.6. Requirements for Timed Metadata</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="fmp4git">
   <b><a href="#fmp4git">#fmp4git</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-fmp4git">6.1. CMAF Ingest General Considerations</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="mozillatls">
   <b><a href="#mozillatls">#mozillatls</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-mozillatls">5. General Ingest Protocol Behavior</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="ms-sstr">
   <b><a href="#ms-sstr">#ms-sstr</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-ms-sstr">2. Introduction</a>
    <li><a href="#ref-for-ms-sstr①">4. Media Ingest Workflows and Profiles</a>
    <li><a href="#ref-for-ms-sstr②">6.1. CMAF Ingest General Considerations</a>
   </ul>
  </aside>
<script>/* script-dfn-panel */

document.body.addEventListener("click", function(e) {
    var queryAll = function(sel) { return [].slice.call(document.querySelectorAll(sel)); }
    // Find the dfn element or panel, if any, that was clicked on.
    var el = e.target;
    var target;
    var hitALink = false;
    while(el.parentElement) {
        if(el.tagName == "A") {
            // Clicking on a link in a <dfn> shouldn't summon the panel
            hitALink = true;
        }
        if(el.classList.contains("dfn-paneled")) {
            target = "dfn";
            break;
        }
        if(el.classList.contains("dfn-panel")) {
            target = "dfn-panel";
            break;
        }
        el = el.parentElement;
    }
    if(target != "dfn-panel") {
        // Turn off any currently "on" or "activated" panels.
        queryAll(".dfn-panel.on, .dfn-panel.activated").forEach(function(el){
            el.classList.remove("on");
            el.classList.remove("activated");
        });
    }
    if(target == "dfn" && !hitALink) {
        // open the panel
        var dfnPanel = document.querySelector(".dfn-panel[data-for='" + el.id + "']");
        if(dfnPanel) {
            dfnPanel.classList.add("on");
            var rect = el.getBoundingClientRect();
            dfnPanel.style.left = window.scrollX + rect.right + 5 + "px";
            dfnPanel.style.top = window.scrollY + rect.top + "px";
            var panelRect = dfnPanel.getBoundingClientRect();
            var panelWidth = panelRect.right - panelRect.left;
            if(panelRect.right > document.body.scrollWidth && (rect.left - (panelWidth + 5)) > 0) {
                // Reposition, because the panel is overflowing
                dfnPanel.style.left = window.scrollX + rect.left - (panelWidth + 5) + "px";
            }
        } else {
            console.log("Couldn't find .dfn-panel[data-for='" + el.id + "']");
        }
    } else if(target == "dfn-panel") {
        // Switch it to "activated" state, which pins it.
        el.classList.add("activated");
        el.style.left = null;
        el.style.top = null;
    }

});
</script>