<!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 eee3e9e7543e2188fb60d183a6cf3fe3a7d971c1" 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-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-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-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>
<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-syntax-highlighting */

.highlight:not(.idl) { background: hsl(24, 20%, 95%); }
code.highlight { padding: .1em; border-radius: .3em; }
pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }
c-[a] { color: #990055 } /* Keyword.Declaration */
c-[b] { color: #990055 } /* Keyword.Type */
c-[c] { color: #708090 } /* Comment */
c-[d] { color: #708090 } /* Comment.Multiline */
c-[e] { color: #0077aa } /* Name.Attribute */
c-[f] { color: #669900 } /* Name.Tag */
c-[g] { color: #222222 } /* Name.Variable */
c-[k] { color: #990055 } /* Keyword */
c-[l] { color: #000000 } /* Literal */
c-[m] { color: #000000 } /* Literal.Number */
c-[n] { color: #0077aa } /* Name */
c-[o] { color: #999999 } /* Operator */
c-[p] { color: #999999 } /* Punctuation */
c-[s] { color: #a67f59 } /* Literal.String */
c-[t] { color: #a67f59 } /* Literal.String.Single */
c-[u] { color: #a67f59 } /* Literal.String.Double */
c-[cp] { color: #708090 } /* Comment.Preproc */
c-[c1] { color: #708090 } /* Comment.Single */
c-[cs] { color: #708090 } /* Comment.Special */
c-[kc] { color: #990055 } /* Keyword.Constant */
c-[kn] { color: #990055 } /* Keyword.Namespace */
c-[kp] { color: #990055 } /* Keyword.Pseudo */
c-[kr] { color: #990055 } /* Keyword.Reserved */
c-[ld] { color: #000000 } /* Literal.Date */
c-[nc] { color: #0077aa } /* Name.Class */
c-[no] { color: #0077aa } /* Name.Constant */
c-[nd] { color: #0077aa } /* Name.Decorator */
c-[ni] { color: #0077aa } /* Name.Entity */
c-[ne] { color: #0077aa } /* Name.Exception */
c-[nf] { color: #0077aa } /* Name.Function */
c-[nl] { color: #0077aa } /* Name.Label */
c-[nn] { color: #0077aa } /* Name.Namespace */
c-[py] { color: #0077aa } /* Name.Property */
c-[ow] { color: #999999 } /* Operator.Word */
c-[mb] { color: #000000 } /* Literal.Number.Bin */
c-[mf] { color: #000000 } /* Literal.Number.Float */
c-[mh] { color: #000000 } /* Literal.Number.Hex */
c-[mi] { color: #000000 } /* Literal.Number.Integer */
c-[mo] { color: #000000 } /* Literal.Number.Oct */
c-[sb] { color: #a67f59 } /* Literal.String.Backtick */
c-[sc] { color: #a67f59 } /* Literal.String.Char */
c-[sd] { color: #a67f59 } /* Literal.String.Doc */
c-[se] { color: #a67f59 } /* Literal.String.Escape */
c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */
c-[si] { color: #a67f59 } /* Literal.String.Interpol */
c-[sx] { color: #a67f59 } /* Literal.String.Other */
c-[sr] { color: #a67f59 } /* Literal.String.Regex */
c-[ss] { color: #a67f59 } /* Literal.String.Symbol */
c-[vc] { color: #0077aa } /* Name.Variable.Class */
c-[vg] { color: #0077aa } /* Name.Variable.Global */
c-[vi] { color: #0077aa } /* Name.Variable.Instance */
c-[il] { color: #000000 } /* Literal.Number.Integer.Long */
</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-01-31">31 January 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_general"><span class="secno">6</span> <span class="content">Profile 1: CMAF Ingest General Considerations</span></a>
    <li>
     <a href="#profile_1"><span class="secno">7</span> <span class="content">Profile 1:  CMAF Ingest Protocol Behavior</span></a>
     <ol class="toc">
      <li><a href="#general_Protocol_Requirements_p1"><span class="secno">7.1</span> <span class="content">General Protocol Requirements</span></a>
      <li><a href="#Requirements_for_formatting_Media_Tracks"><span class="secno">7.2</span> <span class="content">Requirements for Formatting Media Tracks</span></a>
      <li><a href="#timed_text_and_subtitle_streams"><span class="secno">7.3</span> <span class="content">Requirements for Timed Text Captions and Subtitle Streams</span></a>
      <li><a href="#timed_metadata"><span class="secno">7.4</span> <span class="content">Requirements for Timed Metadata</span></a>
      <li><a href="#failover"><span class="secno">7.5</span> <span class="content">Requirements for Media Processing Entity Failover</span></a>
      <li><a href="#failover_source"><span class="secno">7.6</span> <span class="content">Requirements for live Media Source Failover</span></a>
     </ol>
    <li>
     <a href="#dash_ingest"><span class="secno">8</span> <span class="content">Profile 2: DASH and HLS Ingest General Considerations</span></a>
     <ol class="toc">
      <li>
       <a href="#DASH_General"><span class="secno">8.1</span> <span class="content">General requirements</span></a>
       <ol class="toc">
        <li><a href="#Industry_compliance"><span class="secno">8.1.1</span> <span class="content">Industry Compliance</span></a>
        <li><a href="#DASH_Ingest_HTTP"><span class="secno">8.1.2</span> <span class="content">HTTP connections</span></a>
        <li><a href="#DASH_Ingest_naming"><span class="secno">8.1.3</span> <span class="content">Unique segment and manifest naming</span></a>
        <li><a href="#DASH_Ingest_DNS_Lookups"><span class="secno">8.1.4</span> <span class="content">DNS lookups</span></a>
        <li><a href="#DASH_Ingest_Publisher_Identification"><span class="secno">8.1.5</span> <span class="content">Ingest source identification</span></a>
        <li><a href="#DASH_Ingest_Common_Failure_Behaviors"><span class="secno">8.1.6</span> <span class="content">Common Failure behaviors</span></a>
       </ol>
      <li>
       <a href="#HLS_Ingest_specific_requirements"><span class="secno">8.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">8.2.1</span> <span class="content">File extensions and mime-types</span></a>
        <li><a href="#Upload_order"><span class="secno">8.2.2</span> <span class="content">Upload order</span></a>
        <li><a href="#HLS_Ingest_Encryption"><span class="secno">8.2.3</span> <span class="content">Encryption</span></a>
        <li><a href="#HLS_Ingest_relative_paths"><span class="secno">8.2.4</span> <span class="content">Relative paths</span></a>
        <li><a href="#HLS_Ingest_Resiliency"><span class="secno">8.2.5</span> <span class="content">Resiliency</span></a>
       </ol>
      <li>
       <a href="#DASH_requirements"><span class="secno">8.3</span> <span class="content">DASH specific requirements</span></a>
       <ol class="toc">
        <li><a href="#DASH_mime_types_and_extensions"><span class="secno">8.3.1</span> <span class="content">File extensions and mime-types</span></a>
        <li><a href="#DASH_Relative_paths_and_extensions"><span class="secno">8.3.2</span> <span class="content">Relative paths</span></a>
       </ol>
     </ol>
    <li><a href="#security"><span class="secno">9</span> <span class="content">Security Considerations</span></a>
    <li><a href="#iana"><span class="secno">10</span> <span class="content">IANA Considerations</span></a>
    <li><a href="#contrib"><span class="secno">11</span> <span class="content">Acknowledgements</span></a>
    <li>
     <a href="#references_custom"><span class="secno">12</span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#references-url"><span class="secno">12.1</span> <span class="content">URL References</span></a>
     </ol>
    <li><a href="#Authors"><span class="secno">13</span> <span class="content">Author’s Address</span></a>
    <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>
      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative 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 draft presents the specification of Live Media Ingest.
   Two profiles are defined, the first profile, CMAF ingest 
   is based on fragmented MPEG-4 (fmp4). The second profile 
   is based on MPEG DASH and HLS. Details on ingest of 
   metadata markers, timed text, subtitles data are also included 
   in the specification.</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>This document presents the specification Live Media Ingest.
   live media ingest happens between an ingest source such as a  
   live video encoder <a data-link-type="dfn" href="#live-encoder" id="ref-for-live-encoder">live encoder</a> and distributed media 
   processing entities that receive the ingest. 
   Examples of such media processing 
   entities include media packagers, streaming origins and 
   content delivery networks. The structure
   setup by these media processing entities 
   for receiving the ingest is sometimes referred to as a <a data-link-type="dfn" href="#publishing-point" id="ref-for-publishing-point">Publishing point</a>.
   The combination of ingest sources and
   distributed media processing entities  
   is common in practical video streaming deployments.  
   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  
   that need to be achieved.</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 repeatedly sending 
   and receving 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,  
   targetting several different application areas.  
   To do so they provide many different profiles and options.  
   Detailed inter-operability is often achieved through  
   other application standards such as those for  
   the broadcast or storage. For inter-operable 
   live media ingest, this document provides 
   guidance on how to use <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a>.  
   In addition, the codec  and profile used, 
   e.g. <a data-link-type="biblio" href="#biblio-mpeghevc">[MPEGHEVC]</a> are important  
   inter-operability 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 metadata like timed graphics.  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 like ID3 tags <a data-link-type="biblio" href="#biblio-id3v2">[ID3v2]</a>.</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.</p>
   <p>Fifth, in streaming workflows it is important
   to have support for failovers of both the ingest sources  
   and the media processing entities. This is important  
   to avoid interruptions of 24/7 live services such  
   as Internet television where components can fail.  
   In practical deployments, multiple ingest sources  
   and media processing entities are used. This requires  
   that multiple ingest sources and media processing
   entities work together in a redundant workflow where  
   some of the components might fail.</p>
   <p>This document provides the specification
   for establishing these inter-operability points. 
   The approaches are based on known standardized  
   technologies that have been tested and deployed  
   in several large scale streaming  
   deployments. Two key workflows have been  
   identified for which two different media  
   ingest profiles will be detailed.</p>
   <p>In a first workflow for profile 1,
   CMAF ingest, encoded media is ingested  
   downstream for further processing of the media
   in the media processing entity.  
   Examples of such media processing could be any  
   media transformation such as packaging,  
   encrypting or transcoding the streams.  
   Other example operations include watermarking,  
   content insertion and generating streaming manifests  
   based on <a data-link-type="biblio" href="#biblio-mpegdash">[MPEGDASH]</a> or HLS <a data-link-type="biblio" href="#biblio-rfc8216">[RFC8216]</a>. 
   What is typical of these operations is 
   that they actively inspect,  
   or modify the media content and may  
   generate new derived media content.  
   In this workflow it is important  
   to convey mediadata and metadata that  
   assists such active media processing operations.  
   This workflow type is addressed  
   in the first profile referred to as CMAF ingest.</p>
   <p>In the second workflow in profile 2,
   the encoded media is ingested   
   into an entity that does none or very minimal inspection  
   or modification of the media content. The main aim  
   of such processing entities often lies in storage,  
   caching and delivery of the media content. An example  
   of such an entity is a Content Delivery Network (CDN)  
   for delivering and caching Internet content.  
   Content delivery networks are often designed for  
   Internet content like web pages and might  
   not be aware of media specific aspects. In fact, streaming  
   protocols like MPEG DASH and HTTP Live Streaming have been  
   developed with re-use of such a media agnostic  
   Content Delivery Networks in mind. For ingesting  
   encoded media into a content delivery network it  
   is important to have the media presentation in a form  
   that is very close or matching to the format  
   that the clients need to playback the presentation,  
   as changing or complementing the media presentation  
   will be difficult. This second workflow is supported  
   in profile 2 DASH and HLS ingest. This specification 
   provides a push based ingest for these protocols.</p>
<pre class="highlight">Diagram 1: Example with media ingest in profile 1 (fmp4/CMAF ingest)

============       ==============      ==============
||        || ingest||  Active  || HLS  || Content  ||  HLS
|| ingest ||====>>>||processing||===>>>|| Delivery ||==>>>Client
|| source ||       || entity   || DASH || Network  ||  DASH
============       ==============      ==============
   
</pre>
<pre class="highlight">Diagram 2: Example with media ingest in profile 2 (HLS or DASH ingest)
 
============       ==============      
||        || ingest|| Content  ||   HLS/DASH
|| ingest ||====>>>||Delivery  ||==>>>> Client
|| source ||       || Network  ||  
============       ============== 
</pre>
   <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.</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
   is the ingest part of 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 first profile CMAF ingest
   advances over the smooth 
   ingest procotol including lessons learned over the last   
   ten years after the initial deployment of    
   smooth streaming in 2009 and several advances   
   on signalling metadata and timed text.   
   In addition, it 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 exising media containers CMAF <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> is referenced.</p>
   <p>A second profile referenced
   as DASH and HLS ingest 
   is included for ingest of media   
   streaming presentations to entities were    
   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   
   profile naming is important to enable direct   
   processing and storage of the presentation.</p>
   <p>We present these two profiles 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 profiles   
   combined into one, as was the case   
   in a prior version of this draft.</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 easier to debug and trace errors.   
   The HTTP POST provides a push based   
   method for delivery for pusing the   
   live content when available.</p>
   <p>The binary media format for conveying
   the media is based on fragmented MPEG-4 format as  
   specified in <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> <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 fragmented  
   MPEG-4 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>Regarding the transports protocol, in future versions,
   alternative transport protocols could be considered  
   advancing over HTTP 1.1 or TCP. 
   We believe the proposed media format  
   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 main goal of this specification is to define the inter-operability
   point between live sources (ingest sources) and media processing 
   entities that typically reside in the cloud or the network. 
   This specification does not impose any new constraints
   or requirements for live streaming to media clients on 
   end-user devices that consume streams using any 
   defined streaming protocol, with a preference for [!MPEGDASH]</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   
   presented. Sections 5-9 will detail the protocol and   
   the two different profiles.</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>ISOBMFF: 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="fmp4-ingest"><strong>fmp4 Ingest</strong></dfn>:
          Ingest mode defined in this specification for ingesting fmp4 and/or CMAF content</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="cmaf-ingest"><strong>CMAF Ingest</strong></dfn>:
          Ingest mode defined in this specification for ingesting  CMAF content</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="dash-ingest"><strong>DASH Ingest</strong></dfn>:
          Ingest mode defined in this specification for ingesting MPEG DASH content directly.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="hls-ingest"><strong>HLS Ingest</strong></dfn>:
          Ingest mode defined for ingesting HLS content directly</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="ingest-stream"><strong>Ingest Stream</strong></dfn>:
          The stream of media produced by the live source  
            transmitted 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.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="live-encoder"><strong>live encoder</strong></dfn>:
           entity performing live  
           encoding and production of a high quality live 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 media content  
            , typically a live encoder but not restricted  
            to this, it could be a storage source aswell.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="publishing point" data-noexport id="publishing-point"><strong>publishing point</strong> </dfn>:
              Entry point used to receive the media content,  
              consumes/receives the incoming media <a data-link-type="dfn" href="#ingest-stream" id="ref-for-ingest-stream">ingest stream</a> at the media processing entity</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 representing media, and or 
	   timed text, or other non manifest objects</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="Objects" data-noexport id="objects"> <strong>Objects</strong> </dfn> objects ingested by the ingest source such as 
	   manifest objects and media objects 
	   (media segments, subtitle segments)</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="streaming-presentation"><strong>streaming presentation</strong></dfn> manifest objects and media objects composing 
	   a Streaming presentation based on a streaming protocol</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 process the media content,  
          receives/consumes a media [=ingest stream].
	  May only provide a pass through functionality.</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 ingest source and media processing entity.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="ftyp"><strong>ftyp</strong></dfn>:
          the filetype and compatibility FileTypeBox "ftyp" box as described  
          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" described 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-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-noexport id="moof"><strong>moof</strong></dfn>:
           The MovieFragmentBox "moof" box as described in the  
           ISOBMFF  base media file format <a data-link-type="biblio" href="#biblio-isobmff">[ISOBMFF]</a> that describes  
           the metadata of a fragment.</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"  
            in the base media file format <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, often used for metadata tracks</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 [[!RFC7235]</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)</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="fragmentedMP4stream" data-noexport id="fragmentedmp4stream"> <strong>fragmentedMP4stream</strong> </dfn>:
             A <a data-link-type="dfn" href="#fragmentedmp4stream" id="ref-for-fragmentedmp4stream">fragmentedMP4stream</a> can be defined  
             using the IETF RFC 5234 ANB <a data-link-type="biblio" href="#biblio-rfc5234">[RFC5234]</a> as follows. <strong>fragmentedMP4stream</strong> =
             headerboxes fragments:
             headerboxes = <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> fragments = X fragment  
             fragment = <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></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-lt="TCP" 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-lt="Arrival Time" data-noexport id="arrival-time"> Arrival Time </dfn>:
            The time a metadata item is seen/observed by the application for 
            the first time, e.g. an announcement/avail</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-lt="Application time" data-noexport id="application-time"> Application time </dfn>:
              The time a metadata event is applied to a stream (if applicable)</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>In this section we highlight two example workflows
  corresponding to the two different profiles.  
  Diagram 3 shows an example workflow of media ingest  
  with <a data-link-type="dfn" href="#fmp4-ingest" id="ref-for-fmp4-ingest">fmp4 Ingest</a> or <a data-link-type="dfn" href="#cmaf-ingest" id="ref-for-cmaf-ingest">CMAF Ingest</a> in a streaming workflow. 
  The live media  is ingested into the media processing 
  entity that performs  operations like on-the-fly encryption, 
  content stitching,  packaging and possibly other operations 
  before  delivery of the final media presentation to the client.  
  This type of distributed media processing offloads  
  many functionalities from the ingest source.  
  As long as the stream originating from the media  
  source contains sufficient metadata, the media  
  processing entity can generate the media presentation  
  for streaming to clients or other derived media  
  presentations as needed by a client.</p>
   <p>Diagram 4 shows an alternative example with ingest
  to a content delivery network, or perhaps another  
  passive media entity such as a cloud storage. 
  In this case the ingest source uses HTTP post 
  to push the fragments and the manifests or other media
  objects composing the <a data-link-type="dfn" href="#streaming-presentation" id="ref-for-streaming-presentation">streaming presentation</a>.</p>
   <p>In this case, still MPEG-4 media fragments can be used,
  but the ingest works slightly different. The ingest 
  can be based on <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> defined in profile 2 and includes sending the 
  manifest. In this case the manifest 
  and fragments are send with 
  using individual fixed length HTTP POST commands
  to paths that correspond to paths defined in the
  manifest.</p>
   <p>Practice has shown that the ingest schemes
  can be quite different for the two configurations  
  , and that combining them into a single protocol  
  will result in overhead such as sending  
  duplicate information in the manifest or  
  ISOBMFF moov box, and increased  
  signalling overhead for starting, closing  
  and resetting the <a data-link-type="dfn" href="#connection" id="ref-for-connection">Connection</a>. Therefore,  
  the two procedures for media ingest in  
  these two common workflows are presented  
  as separately in different profiles.</p>
<pre class="highlight">Diagram 3: Streaming workflow with fragmented MPEG-4 ingest in profile 1 (CMAF/fmp4 ingest)

============       ==============      ==============
|| live   ||ingest ||  Media   || HLS  || Content  ||  HLS
|| media  ||====>>>||processing||===>>>|| Delivery ||==>>> Client
|| source || fmp4  || entity   || DASH || Network  ||  DASH
============       ==============      ==============
</pre>
<pre class="highlight">Diagram 4: Streaming workflow with DASH ingest in profile 2 DASH/HLS ingest

============  fmp4   ==============      
|| live   ||manifest|| Content  ||   
|| media  ||====>>> ||Delivery  ||==>>>> Client
|| source ||        || Network  ||  
============        ==============   
</pre>
   <p>Diagram 5 highlights some of the key
  differences and practical considerations of 
  the profiles. In profile 1 (CMAF or fmp4 ingest) 
  the ingest source can be  
  simple as the media processing entity 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 manifests 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 types of workflows by two different  
  profiles fmp4/CMAF ingest and DASH/HLS ingest. 
  The best choice for a specific platform depends  
  on many of the use case specific requirements, 
  circumstances  and the available technologies.</p>
<pre class="highlight">  Diagram 5: Differences profile 1 and profile 2 for use cases
============================================================
|Profile   |    Ingest source     |   Media processing     |
|----------|----------------------|------------------------|
|Profile 1 |limited overview      |encrypt, transcode,     |
| CMAF     | simple encoder       |package, watermark      |
| fmp4     | multiple sources     |content stitch, timed   |
|Profile 2 |   Global overview    | cache, store, deliver  |
| DASH     |encoder targets client|                        |
| HLS      |only duplicate sources| manifest manipulation  |
|          |                      | storage &amp; transmission |
============================================================
  
</pre>
<pre class="highlight">Diagram 6:
workflow with redundant Ingest sources and media processing entities

              fmp4  ==============     
============ stream||  Media   || 
|| Ingest ||====>>>||Processing|| \\
|| source ||   //  ||  Entity  ||  \\ 
============  //   ==============   \\  ============        
============ //                      \\ || load   || 
|| Ingest ||// redundant stream       >>||balancer|| ==>>> Client
|| source ||\\ stream                // =============
============ \\     =============   // 
============  \\   || Media     || //     
|| Ingest ||====>>>||Processing ||//        
|| source ||   //  || Entity    ||
============  //   ===============
============ //     
|| Ingest ||// redundant stream       
|| source ||       
============  
</pre>
   <p>Diagram 6 highlights another aspect that was taken into
  consideration for large scale systems with many users.  
  Often one would like to run multiple ingest sources,  
  multiple  media processing entities and make them available  
  to the clients via a load balancer. This way requests  
  can be balanced over multiple processing nodes.  
  This approach is common when serving web pages,  
  and this architecture also applies to video  
  streaming platforms. In Diagram  6 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 source or media processing entity fails over.  
  We call this support for failover. It 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 seamlesslessly without causing service interruption.  
  This specification details how this failover and redundancy  
  support can be achieved. In addition, some recommendations
  for redundant ingest sources and media processing entities 
  are provided.</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 profiles.</p>
   <ol>
    <li data-md>
     <p>The ingest source 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 ingest source SHOULD
use HTTP over TLS, if TLS is used it SHALL be 
TLS version 1.2 or higher <a data-link-type="biblio" href="#biblio-rfc2818">[RFC2818]</a></p>
    <li data-md>
     <p>The ingest source 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 ingest source MUST update the IP to hostname
resolution respecting the TTL (time to live) from DNS
query responses, this will enable better resillience
to changes of the IP address in large scale deployments
where the IP address of the  media
processing entities may change frequenty.</p>
    <li data-md>
     <p>In case HTTPS <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  ingest source 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 media processing entities
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 sparse 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>
   </ol>
   <h2 class="heading settled" data-level="6" id="profile_1_general"><span class="secno">6. </span><span class="content">Profile 1: CMAF Ingest General Considerations</span><a class="self-link" href="#profile_1_general"></a></h2>
   <p>The fmp4 or CMAF ingest assumes ingest to an active media processing entity,
from one or more <a data-link-type="dfn" href="#ingest-source" id="ref-for-ingest-source">ingest source</a>, ingesting one or more  
types of media streams. This 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 allows 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  
fragmented MPEG-4 ingest is illustrated in Diagram 7. Discussions
on the early development have been documented <a data-link-type="dfn" href="#fmp4git" id="ref-for-fmp4git">fmp4git</a>.</p>
<pre class="highlight"> Diagram 7: fragmented MPEG-4 ingest with multiple ingest sources

============ fmp4  ==============     
||        || video ||          || 
|| ingest ||====>>>||          ||
|| source ||       ||          || 
============       ||          ||      
||        || fmp4  ||          ||
|| ingest ||====>>>||  Active  ||      ==============
|| source || audio ||   Media  || HLS  || Content  ||  HLS
============       || procesing||===>>>|| Delivery ||==>>> Client
||        || fmp4  ||  entity  || DASH || Network  ||  DASH
||ingest  ||====>>>||          ||       =============
|| source || text  ||          ||
============       ||          ||
||        || fmp4  ||          || 
||ingest  || meta  ||          ||
|| source ||  data ||          ||
||        ||====>>>||          ||
============       ==============
</pre>
   <p>Diagrams 8-10 detail some of the concepts and structures.
Diagram 8 shows the data format structure of fragmented   
MPEG-4 <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 <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 header of the stream, sometimes referred   
as a <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> header. The styp box can be used to signal the   
type of fragment. The combination of styp <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 CMAF fragment, 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 an init fragment or a CMAF header.</p>
<pre class="highlight">Diagram 8: fragmented mp4 stream: 

=========================================================
||ftyp||moov||styp||moof||mdat||styp||moof||mdat|| .....=
=========================================================
</pre>
   <p>Diagram 9 illustrates the synchronisation model, that
is based on the synchronisation 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 fragmented mp4 streams. By having the boundaries 
to the fragments time alligned for tracks comprising the 
same 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 separated fragmented mp4 stream  
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 synchronisation
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 
sameple 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 10 another advantage of this synchronisation model
is illustrated, the concept of late binding. In the case   
of late binding, a new stream becomes available or is 
adopted 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.</p>
<pre class="highlight">Diagram 9: fmp4 stream synchronisation:

=========================================================
||ftyp||moov||styp||moof||mdat||styp||moof||mdat|| .....=
=========================================================
||ftyp||moov||styp||moof||mdat||styp||moof||mdat|| .....=
=========================================================
||ftyp||moov||styp||moof||mdat||styp||moof||mdat|| .....=
=========================================================
</pre>
<pre class="highlight">Diagram 10: fmp4 late binding: 

===================================================
||ftyp||moov||styp||moof||mdat||moof||mdat|| .....=
===================================================
===================================================  &lt;&lt; ==  different available track
||ftyp||moov||styp||moof||mdat||moof||mdat|| .....=
===================================================                   
</pre>
   <p>Diagram 11 shows the flow of the media ingest. It starts with a
DNS resolution (if needed) and an authentication step (Authy,   
TLS certificate) to establish a secure <a data-link-type="dfn" href="#tcp" id="ref-for-tcp">TCP</a> connection.   
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 cmaf header. In case this is succesfull this is followed by the rest of 
the fragments in the fragmented MPEG-4 stream. At the end of 
the session, for tear down the source can send an empty <a data-link-type="dfn" href="#mfra" id="ref-for-mfra">mfra</a> box to close the connection. 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.</p>
<pre class="highlight">Diagram 11: fmp4 ingest flow
||===============================================================||
||=====================            ============================  ||
|||     ingest source |            |  Media processing entity | ||
||=====================            ============================  ||
||        || &lt;&lt;------  DNS Resolve    -------->> ||              ||
||        || &lt;&lt;------  Authenticate   -------->> ||              ||
||        || &lt;&lt;------POST fmp4stream  -------->> ||              ||
||================== Moov + ftyp Sending  =======================||
||        || &lt;&lt;------ 404 Bad Request -----------||              ||
||        || &lt;&lt;------ 202 OK --------------------||              ||
||        || &lt;&lt;------ 403 Forbidden -------------||              ||
||        || &lt;&lt;------ 404 Bad Request            ||              ||
||        || &lt;&lt;------ 400 Forbidden -------------||              ||
||        ||         Unsupported Media Type      ||              ||
||        || &lt;&lt;------ 415 Forbidden -------------||              ||
||================== Moov + ftyp Sending  =======================||
||        || &lt;&lt;------ 202 OK --------------------||              ||
||============= fragmented MP4 Sending ==========================||
||        || &lt;&lt;------ 404 Bad Request -----------||              ||
||============= mfra box Sending (close) ========================||
||        || &lt;&lt;------ 200 OK --------------------||              ||
||=====================            ============================  ||
||| live ingest source |            |  Media processing entity | ||
||=====================            ============================  ||
||        ||                                     ||              ||
||===============================================================||
</pre>
   <h2 class="heading settled" data-level="7" id="profile_1"><span class="secno">7. </span><span class="content">Profile 1:  CMAF Ingest Protocol Behavior</span><a class="self-link" href="#profile_1"></a></h2>
   <p>This section describes the protocol behavior specific to
profile 1: Fragmented MPEG-4 / CMAF ingest. Operation of this  
profile MUST also adhere to general requirements in section 4.</p>
   <h3 class="heading settled" data-level="7.1" id="general_Protocol_Requirements_p1"><span class="secno">7.1. </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 ingest source SHALL start
by sending an HTTP POST request with the 
init fragment "ftyp" and "moov" 
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 ingest source MUST initiate
a media ingest connection by posting the
CMAF header or boxes  after step 1</p>
    <li data-md>
     <p>The ingest source 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 prior to the end of the stream, the ingest source MUST establish
a new connection, and follow the
preceding requirements. Additionally, the ingest source MAY resend
the fragment in which the timeout or TCP error occured.</p>
    <li data-md>
     <p>The ingest source 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 CMAF header.</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 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 ingest of each different track by 
appending it to the <a data-link-type="dfn" href="#post_url" id="ref-for-post_url②">POST_URL</a></p>
    <li data-md>
     <p>The fragment decode timestamps <a data-link-type="dfn" href="#basemediadecodetime" id="ref-for-basemediadecodetime">basemediadecodetime</a> in tdft of fragments in the <a data-link-type="dfn" href="#fragmentedmp4stream" id="ref-for-fragmentedmp4stream①">fragmentedMP4stream</a> SHOULD arrive in increasing order 
for each of 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="#fragmentedmp4stream" id="ref-for-fragmentedmp4stream②">fragmentedMP4stream</a> signalled in the tfhd
SHOULD arrive in increasing order for each of the different
tracks/streams that are ingested. Using both 
timestamp in 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>
   </ol>
   <h3 class="heading settled" data-level="7.2" id="Requirements_for_formatting_Media_Tracks"><span class="secno">7.2. </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 fragmented MP4 stream 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 considered.</p>
    <li data-md>
     <p>The language of the stream 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="#moof" id="ref-for-moof④">moof</a> headers (<a data-link-type="dfn" href="#mdhd" id="ref-for-mdhd①">mdhd</a>).</p>
    <li data-md>
     <p>Fragments posted towards the media procesing entity 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 media track MAY use the notion of a CMAF chunk <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> which is a moof mdat structure that may  
not be an IDR or switching point and is not targetted 
as an independently addressable media fragment</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 the sample entry. In this case parameters do not change
dynamically during the live event and are signalled 
in the moviebox in the init fragment (CMAF Header).</p>
    <li data-md>
     <p>Alternatively videotracks MAY use profiles like avc3 or
 hev1 that signal the parameter sets (PPS, SPS, VPS) in 
  in the media samples in the mdat box.</p>
    <li data-md>
     <p>In case the language of 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>
   </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. For example
the styp box can be used to signal if the following structure is a CMAF fragment,
chunk, or segment.</p>
   <h3 class="heading settled" data-level="7.3" id="timed_text_and_subtitle_streams"><span class="secno">7.3. </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 media ingest follows the following 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 the text in <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a> references prevails the text below when different except for 
the notion of 9 adding a bitrate box.</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 fragmented MPEG-4 <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 [[!MPEG4-30]</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 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 init fragment 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>
     <p>8d. CEA  CTA-608 and CTA-708 Specified in 11.4 <a data-link-type="biblio" href="#biblio-mpeg4-30">[MPEG4-30]</a> Caption data is embedded in SEI messages in video track ccea</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 track changes a new init fragment
  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>
   </ol>
   <h3 class="heading settled" data-level="7.4" id="timed_metadata"><span class="secno">7.4. </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 ingest of timed metadata related to events and markers for  
  ad insertion or other timed metadata.  An example of  
  these are opportunities for dynamic live ad insertion  
  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. 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>. 
  For example, DASH Event messages contain a schemeIdUri 
  that defines the payload of the message.</p>
   <p>Table 1 provides some example urn schemes
  Table 2 illustrates an example of a SCTE-35 marker stored  
  in a DASH emsg.  
  The presented approach allows ingest of  
  timed metadata from different sources,  
  possibly on different locations by embedding them in  
  sparse metadata tracks. In this approach metadata 
  is not interleaved with the media as for example
  the case in emsg boxes in [!MPEGCMAF]</p>
   <p>Example metadata messages include e-msg 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 <a data-link-type="biblio" href="#biblio-scte35">[SCTE35]</a> or <a data-link-type="biblio" href="#biblio-id3v2">[ID3v2]</a> messages could be
  conveyed in a sparse metadata track.</p>
<pre class="highlight">Table 1 Example of DASH emsg schemes  URI
| Scheme URI                 | Reference                      | 
| --------------------------:|:------------------------------:| 
| urn:mpeg:dash:event:2012   | DASH, 5.10.4                   | 
| urn:dvb:iptv:cpm:2014      | DVB-DASH, 9.1.2.1              | 
|  urn:scte:scte35:2013:bin  | [!SCTE35] 14-3 (2015), 7.3.2   |  
| www.nielsen.com:id3:v1     | Nielsen ID3 in MPEG-DASH       |
</pre>
<pre class="highlight">Table 2 example of a SCTE-35 marker embedded in a DASH emsg  
| Tag                     |          Value                      |
|------------------------:|:-----------------------------------:|
| scheme_uri_id           | urn:scte:scte35:2013:bin            |
| Value                   | the value of the SCTE 35 PID        |
| Timescale               | positive number,similar to track    |
| presentation_time_delta | non-negative number, splice time    |
|                         | relative  to tfdt                   |
| event_duration          | duration of event  "0xFFFFFFFF"     |
|                         |  indicates unknown duration         |
| Id                      | unique identifier for message       |
| message_data            | splice info section including CRC   |
</pre>
   <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 fragmented mp4 stream, 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 stream 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</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 [[!ISOBMFF]). For example, the URIBox
 could contain for ID3 tags <a data-link-type="biblio" href="#biblio-id3v2">[ID3v2]</a> the URL  http://www.id3.org or
 or urn:scte:scte35:2013a:bin
 for scte 35 markers <a data-link-type="biblio" href="#biblio-scte35">[SCTE35]</a>}</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="#arrival-time" id="ref-for-arrival-time">Arrival 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 detected.</p>
    <li data-md>
     <p>The <a data-link-type="dfn" href="#application-time" id="ref-for-application-time">Application time</a> can be signalled as
a difference to the arrival time by an 
empty sample with duration delta, the application
time is the time when the metadata or event is 
applied. It is the media presentation time
of the sample containing the event/metadata</p>
    <li data-md>
     <p>The duration of the sample signalled in the
trun box containing the metadata
SHOULD correspond to the duration of 
the metadata if the metadata is valid 
for a duration of time (if applicable)</p>
    <li data-md>
     <p>Empty samples, and fragments with empty samples
SHOULD be used to fill the timeline to avoid timeline 
gaps</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 metadata fragment becomes available to the
media processing entity
when the corresponding track fragment
from the media that has an equal
or larger timestamp compared to
the arrival time signalled
in the tfdt basemediadecodetime.
For example, if the sparse sample
has a timestamp of t=1000, it is expected that after the
processing entity sees "video"
(assuming the parent track name is "video")
fragment timestamp 1000 or beyond, it can retrieve the
sparse fragment from the binary payload.</p>
    <li data-md>
     <p>The payload is conveyed in the mdat box as
sample information. This enables
muxing of the metadata tracks.</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 ingest source SHALL 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 emsg 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 ingest source shall not 
send inband emsg box and the receiver SHALL ignore it.</p>
   <h3 class="heading settled" data-level="7.5" id="failover"><span class="secno">7.5. </span><span class="content">Requirements for Media Processing Entity Failover</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.</p>
   <p>The following steps are required for an ingest source
   to deal with a failing media processing entity.</p>
   <ol>
    <li data-md>
     <p>The ingest source MUST use a timeout for establishing the
TCP connection. If an attempt to establish 
the connection takes longer abort the operation and try again.</p>
    <li data-md>
     <p>The ingest source MUST resend media fragments for which a
connection was terminated early</p>
    <li data-md>
     <p>The ingest source 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 media processing entity cannot process the
  POST request due to authentication or permission
  problems then it SHOULD return a permission denied HTTP 403</p>
    <li data-md>
     <p>In case the media processing entity can process the request
  it SHOULD 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 404 Bad request SHOULD 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 SHOULD be returned</p>
    <li data-md>
     <p>In case a 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</p>
   </ol>
   <h3 class="heading settled" data-level="7.6" id="failover_source"><span class="secno">7.6. </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 ingest source side. The following expectations apply  
  to the live ingestion endpoint when encoder failover happens:</p>
   <ol>
    <li data-md>
     <p>A new ingest source instance SHOULD be instantiated
  to continue the ingest</p>
    <li data-md>
     <p>The ingest source MUST use
   the same URL for HTTP POST requests as the failed instance.</p>
    <li data-md>
     <p>The new  ingest source POST request
  MUST include the same cmaf header or 
  init fragment as the failed instance</p>
    <li data-md>
     <p>The ingest source
  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 start running at
  an appropriate fragment boundaries.</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 ingest source SHOULD
  try to minimize data loss. The basemediadecodetime tdft
  of media fragments SHOULD increase from the point where
  the encoder last stopped. The basemediadecodetime in the
  tdft 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="8" id="dash_ingest"><span class="secno">8. </span><span class="content">Profile 2: DASH and HLS Ingest General Considerations</span><a class="self-link" href="#dash_ingest"></a></h2>
   <p>Profile 2 is designed 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> in 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 ingests 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>Profile 2 exists independently of Profile 1. The requirements below encapsulate all
   needed functionality to support Profile 2. The requirements listed for 
   Profile 1 in section #general_Protocol_Requirements_p1 do not apply to Profile 2. 
   General shared requirements are covered in section #general.</p>
   <h3 class="heading settled" data-level="8.1" id="DASH_General"><span class="secno">8.1. </span><span class="content">General requirements</span><a class="self-link" href="#DASH_General"></a></h3>
   <h4 class="heading settled" data-level="8.1.1" id="Industry_compliance"><span class="secno">8.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="#streaming-presentation" id="ref-for-streaming-presentation③">streaming presentation</a> ingested MUST be either 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> conforming.</p>
    <li data-md>
     <p>The ingest source MUST support the use of fully qualified domain names to identify the <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity">receiving entity</a>.</p>
    <li data-md>
     <p>Both the ingest source and <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity①">receiving entity</a> MUST support IPv4 and IPv6 transport.</p>
    <li data-md>
     <p>The ingest source MUST have the capability of specifying the publishing path
  (which will be used to publish the content) as well as the delivery path 
  (which clients will use to retrieve the content). 
  This capability is further illustrated in the Examples section TBD</p>
   </ol>
   <h4 class="heading settled" data-level="8.1.2" id="DASH_Ingest_HTTP"><span class="secno">8.1.2. </span><span class="content">HTTP connections</span><a class="self-link" href="#DASH_Ingest_HTTP"></a></h4>
   <ol>
    <li data-md>
     <p><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> MUST be uploaded via individual HTTP 1.1 <a data-link-type="biblio" href="#biblio-rfc7235">[RFC7235]</a> PUT or POST operations. This specification does not imply any functional differentation 
  between a PUT or a POST operation. Either may be used to supply content to the receiving entity.</p>
    <li data-md>
     <p><a data-link-type="dfn" href="#media-objects" id="ref-for-media-objects②">media objects</a> that are not referenced in corresponding <a data-link-type="dfn" href="#manifest-objects" id="ref-for-manifest-objects②">manifest objects</a> SHOULD be removed by the ingest source via an HTTP DELETE operation. 
  A DELETE request should support:   
   3.1. deleting an empty folder.
   3.2. deleting 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>Persistent TCP connections SHOULD be used.</p>
    <li data-md>
     <p>Multiple Parallel connections SHOULD be used to ingest the streaming presentation
  that is being concurrently generated. For example, parallel connections 
  can be used for <a data-link-type="dfn" href="#media-objects" id="ref-for-media-objects③">media objects</a> for different bitrates.</p>
    <li data-md>
     <p>If the content length of an object is not known at the start of the upload,
  for example with low latency chunked encoding, 
  then HTTP 1.1 Chunked transfer encoding MUST be used.</p>
   </ol>
   <h4 class="heading settled" data-level="8.1.3" id="DASH_Ingest_naming"><span class="secno">8.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>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)
MUST carry unique path names. This uniqueness applies across all
ingested content in previous sessions, 
as well as the current session.</p>
    <li data-md>
     <p>All objects in a <a data-link-type="dfn" href="#live-stream-event" id="ref-for-live-stream-event①">live stream event</a> MUST be contained within a root path assigned to it.</p>
    <li data-md>
     <p><a data-link-type="dfn" href="#manifest-objects" id="ref-for-manifest-objects③">Manifest objects</a> MUST carry paths which are unique to each live stream event.
One suggested method of achieving this is to introduce the timestamp of the start of the 
live stream event in to the manifest path.</p>
    <li data-md>
     <p>Objects uploaded with the same path as a prior object will replace the prior object.</p>
    <li data-md>
     <p>Media object names MUST end with a number which is monotonically increasing.
It MUST be possible to retrieve this numeric suffix via a regular expression</p>
    <li data-md>
     <p>media objects containing initialization fragments MUST be identified
through either using 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>All objects must carry a file extension and a MIME-type.
The following file extensions and mime-types are the ONLY permissible combinations to be used:</p>
   </ol>
<pre class="highlight">| File extension| Mime-type|
| --- | --- |
| .m3u8| application/x-mpegURL or vnd.apple.mpegURL |
| .mpd | video/MP2T |
| .ts | video/MP2T |
|.cmfv | video/mp4 |
|.cmfa | audio/mp4 |
|.cmft | application/mp4 |
|.m4v | video/mp4 |
|.mp4 | video/mp4 or application/mp4 |
|.m4a | audio/mp4 |
|.m4s | video/iso.segment |
|.init | video/mp4 |
|.header | video/mp4 |
|.key | to be defined |
</pre>
   <h4 class="heading settled" data-level="8.1.4" id="DASH_Ingest_DNS_Lookups"><span class="secno">8.1.4. </span><span class="content">DNS lookups</span><a class="self-link" href="#DASH_Ingest_DNS_Lookups"></a></h4>
   <ol>
    <li data-md>
     <p>The ingest source MUST perform a fresh DNS lookup of the receiving entity hostname prior to
ingesting any manifest or media object at the start live stream event</p>
    <li data-md>
     <p>The publishing entity MUST honor DNS Time To live values when re-connecting, for any reason,
to the <a data-link-type="dfn" href="#receiving-entity" id="ref-for-receiving-entity②">receiving entity</a>.</p>
    <li data-md>
     <p>For services in which ingest sources are dynamically allocated based upon DNS resolution,
it is recommended that short TTL values are chosen in order to allow ingest sources to fail 
over to new ingest servers if warranted under a failure scenario.</p>
   </ol>
   <h4 class="heading settled" data-level="8.1.5" id="DASH_Ingest_Publisher_Identification"><span class="secno">8.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 ingest source MUST include a User-Agent header (which provides information about brand name,
version number, and build number in a readable format) in all post messages.</p>
   </ol>
   <h4 class="heading settled" data-level="8.1.6" id="DASH_Ingest_Common_Failure_Behaviors"><span class="secno">8.1.6. </span><span class="content">Common Failure behaviors</span><a class="self-link" href="#DASH_Ingest_Common_Failure_Behaviors"></a></h4>
    The following items define the behavior of an ingest source when encountering certain conditions. 
   <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
           a. For manifest objects: re-resolve DNS on each retry (per the DNS TTL) and retry indefinitely.
           b. 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. 
	To maintain continuity of the DVR time-line, the ingest source SHOULD continue to upload 
	the missing media object with a lower priority. Once a media object is successfully uploaded, 
	update the corresponding manifest object 
	with an discontinuity marker appropriate for the protocol format at hand.</p>
    <li data-md>
     <p>HTTP 403 or 400 errors
a For all objects (manifest and non-manifest), do not retry. 
  The ingest source MUST stop ingesting objects and 
  provide a log or fatal error condition.</p>
   </ol>
   <h3 class="heading settled" data-level="8.2" id="HLS_Ingest_specific_requirements"><span class="secno">8.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="8.2.1" id="HLS_file_extensions_and_mime_types"><span class="secno">8.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>
   <ol>
    <li data-md>
     <p>The parent and child playlists MUST use a .m3u8 file extension.</p>
    <li data-md>
     <p>The keyfile, if required, MUST use a .key file extension, if statically served.</p>
    <li data-md>
     <p>If segments are encapsulated using a Transport Stream File Format, they MUST carry a ".ts" file extension.</p>
    <li data-md>
     <p>If segments are encapsulated using <a data-link-type="biblio" href="#biblio-mpegcmaf">[MPEGCMAF]</a>, then they MUST NOT use  a ".ts" file extension and must use one of the other allowed file extensions appropriate for the mime-type of the content they are carrying.</p>
   </ol>
   <h4 class="heading settled" data-level="8.2.2" id="Upload_order"><span class="secno">8.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 should upload the segment file followed by a key file (optional) and the playlist file in serial fashion. 
 The encoder should 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:
       1.1 Upload media segment,
       1.2 Optionally upload key file, if required,
       1.3 Upload the .m3u8.
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="8.2.3" id="HLS_Ingest_Encryption"><span class="secno">8.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 receiving entity.</p>
   </ol>
   <h4 class="heading settled" data-level="8.2.4" id="HLS_Ingest_relative_paths"><span class="secno">8.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>Relative URL paths SHOULD be used to address each segment.</p>
   </ol>
   <h4 class="heading settled" data-level="8.2.5" id="HLS_Ingest_Resiliency"><span class="secno">8.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="8.3" id="DASH_requirements"><span class="secno">8.3. </span><span class="content">DASH specific requirements</span><a class="self-link" href="#DASH_requirements"></a></h3>
   <h4 class="heading settled" data-level="8.3.1" id="DASH_mime_types_and_extensions"><span class="secno">8.3.1. </span><span class="content">File extensions and mime-types</span><a class="self-link" href="#DASH_mime_types_and_extensions"></a></h4>
   <ol>
    <li data-md>
     <p>The manifests objects MUST use a ".mpd" file extension.</p>
    <li data-md>
     <p>Media objects MUST NOT use  a ".ts" file extension and must use
 one of the other allowed file extensions defined in XX appropriate
 for the mime-type of the content they are carrying.</p>
   </ol>
   <h4 class="heading settled" data-level="8.3.2" id="DASH_Relative_paths_and_extensions"><span class="secno">8.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>Relative URL paths MUST be used to address each segment.</p>
   </ol>
   <h2 class="heading settled" data-level="9" id="security"><span class="secno">9. </span><span class="content">Security Considerations</span><a class="self-link" href="#security"></a></h2>
   <p>Security considerations are extremely important
   for media ingest. Retrieving media from an illicit  
   source can cause inappropriate content  
   to be broadcasted and possibly lead to failure 
   of infrastructure. Basic security requirements 
   have been covered in  section 5.  
   No security considerations except the ones mentioned  
   in this part of the text are expelictly considered.  
   Further security considerations will be updated  
   once they have been investigated further based  
   on review of this draft.</p>
   <h2 class="heading settled" data-level="10" id="iana"><span class="secno">10. </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="11" id="contrib"><span class="secno">11. </span><span class="content">Acknowledgements</span><a class="self-link" href="#contrib"></a></h2>
   <p>We thank some of the contributors for contribution to draft or discussions</p>
   <p>Will Law Akamai</p>
   <p>James Gruessing BBC R&amp;D</p>
   <p>Kevin Moore Amazon AWS Elemental</p>
   <p>Kevin Johns CenturyLink</p>
   <p>John Deutscher Microsoft</p>
   <p>Patrick Gendron Harmonic Inc.</p>
   <p>Nikos Kyriopoulos MediaExcel</p>
   <p>Rufael Mekuria Unified Streaming</p>
   <p>Sam Geqiang Zhang Microsoft</p>
   <p>Arjen Wagenaar Unified Streaming</p>
   <p>Dirk Griffioen Unified Streaming</p>
   <p>Matt Poole ITV</p>
   <p>Alex Giladi Comcast</p>
   <p>Cenk Facebook</p>
   <p>Thomas Stockhammer Qualcomm</p>
   <p>Iraj Sodaghar,  Tencent</p>
   <p>Ali Begen Comcast/Ozyegin University</p>
   <p>Paul Higgs, Huawei</p>
   <h2 class="heading settled" data-level="12" id="references_custom"><span class="secno">12. </span><span class="content">References</span><a class="self-link" href="#references_custom"></a></h2>
   <h3 class="heading settled" data-level="12.1" id="references-url"><span class="secno">12.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>
   <h2 class="heading settled" data-level="13" id="Authors"><span class="secno">13. </span><span class="content">Author’s Address</span><a class="self-link" href="#Authors"></a></h2>
   <p>Rufael Mekuria (editor)
   Unified Streaming  
   Overtoom 60 1054HK</p>
   <p>Phone: +31 (0)202338801
   E-Mail: rufael@unified-streaming.com</p>
   <p>Sam Geqiang Zhang
   Microsoft  
   E-mail: Geqiang.Zhang@microsoft.com</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="#application-time">Application time</a><span>, in §3</span>
   <li><a href="#arrival-time">Arrival Time</a><span>, in §3</span>
   <li><a href="#basemediadecodetime">basemediadecodetime</a><span>, in §3</span>
   <li><a href="#cmaf-ingest">CMAF Ingest</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="#fmp4git">fmp4git</a><span>, in §12.1</span>
   <li><a href="#fmp4-ingest">fmp4 Ingest</a><span>, in §3</span>
   <li><a href="#fragmentedmp4stream">fragmentedMP4stream</a><span>, in §3</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 §12.1</span>
   <li><a href="#ms-sstr">MS-SSTR</a><span>, in §12.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="#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="#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-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="http://www.itu.int/rec/T-REC-H.222.0-201206-I">Information technology -- Generic coding of moving pictures and associated audio information: Systems ITU-T Rec. H.222.0 / ISO/IEC 13818-1:2013</a>. URL: <a href="http://www.itu.int/rec/T-REC-H.222.0-201206-I">http://www.itu.int/rec/T-REC-H.222.0-201206-I</a>
   <dt id="biblio-mpeg4-30">[MPEG4-30]
   <dd><a href="https://www.iso.org/standard/63107.html">ISO/IEC 14496-30:2014 Preview Information technology -- Coding of audio-visual objects -- Part 30: Timed text and other visual overlays in ISO base media file format</a>. March 2014. URL: <a href="https://www.iso.org/standard/63107.html">https://www.iso.org/standard/63107.html</a>
   <dt id="biblio-mpegcmaf">[MPEGCMAF]
   <dd><a href="https://www.iso.org/standard/71975.html">ISO/IEC 23000-19:2018 Information technology -- Multimedia application format (MPEG-A) -- Part 19: Common media application format (CMAF) for segmented media</a>. January 2018. URL: <a href="https://www.iso.org/standard/71975.html">https://www.iso.org/standard/71975.html</a>
   <dt id="biblio-mpegdash">[MPEGDASH]
   <dd><a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c065274_ISO_IEC_23009-1_2014.zip">ISO/IEC 23009-1:2014 Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats</a>. URL: <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c065274_ISO_IEC_23009-1_2014.zip">http://standards.iso.org/ittf/PubliclyAvailableStandards/c065274_ISO_IEC_23009-1_2014.zip</a>
   <dt id="biblio-mpeghevc">[MPEGHEVC]
   <dd><a href="https://www.iso.org/standard/35424.html">ISO/IEC 23008-2:2013 Information technology -- High efficiency coding and media delivery in heterogeneous environments -- Part 2: High efficiency video coding</a>. December 2013. URL: <a href="https://www.iso.org/standard/35424.html">https://www.iso.org/standard/35424.html</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-rfc5234">[RFC5234]
   <dd>D. Crocker, Ed.; P. Overell. <a href="https://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>. January 2008. Internet Standard. URL: <a href="https://tools.ietf.org/html/rfc5234">https://tools.ietf.org/html/rfc5234</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%202016.pdf">Digital Program Insertion Cueing Message for Cable</a>. URL: <a href="https://www.scte.org/SCTEDocs/Standards/SCTE%2035%202016.pdf">https://www.scte.org/SCTEDocs/Standards/SCTE%2035%202016.pdf</a>
  </dl>
  <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></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>
  </dl>
  <aside class="dfn-panel" data-for="fmp4-ingest">
   <b><a href="#fmp4-ingest">#fmp4-ingest</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-fmp4-ingest">4. Media Ingest Workflows and Profiles</a>
   </ul>
  </aside>
  <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>
   </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">7.1. General Protocol Requirements</a>
    <li><a href="#ref-for-live-stream-event①">8.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①">7.6. 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">6. Profile 1: CMAF Ingest General Considerations</a> <a href="#ref-for-ingest-source①">(2)</a>
    <li><a href="#ref-for-ingest-source②">7.1. General Protocol Requirements</a> <a href="#ref-for-ingest-source③">(2)</a>
    <li><a href="#ref-for-ingest-source④">7.6. Requirements for live Media Source Failover</a>
    <li><a href="#ref-for-ingest-source⑤">8. Profile 2: DASH and HLS Ingest General Considerations</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">2. Introduction</a>
    <li><a href="#ref-for-publishing-point①">7.4. 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">8. Profile 2: DASH and HLS Ingest General Considerations</a>
    <li><a href="#ref-for-manifest-objects①">8.1.2. HTTP connections</a> <a href="#ref-for-manifest-objects②">(2)</a>
    <li><a href="#ref-for-manifest-objects③">8.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">8. Profile 2: DASH and HLS Ingest General Considerations</a>
    <li><a href="#ref-for-media-objects①">8.1.2. HTTP connections</a> <a href="#ref-for-media-objects②">(2)</a> <a href="#ref-for-media-objects③">(3)</a>
    <li><a href="#ref-for-media-objects④">8.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">8. Profile 2: DASH and HLS Ingest General Considerations</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">4. Media Ingest Workflows and Profiles</a>
    <li><a href="#ref-for-streaming-presentation①">8. Profile 2: DASH and HLS Ingest General Considerations</a> <a href="#ref-for-streaming-presentation②">(2)</a>
    <li><a href="#ref-for-streaming-presentation③">8.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. Profile 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">8.1.1. Industry Compliance</a> <a href="#ref-for-receiving-entity①">(2)</a>
    <li><a href="#ref-for-receiving-entity②">8.1.4. DNS lookups</a>
    <li><a href="#ref-for-receiving-entity③">8.1.6. Common Failure behaviors</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">4. Media Ingest Workflows and Profiles</a>
    <li><a href="#ref-for-connection①">5. General Ingest Protocol Behavior</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">3. Conventions and Terminology</a>
    <li><a href="#ref-for-ftyp①">6. Profile 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④">7.3. Requirements for Timed Text Captions and Subtitle Streams</a> <a href="#ref-for-ftyp⑤">(2)</a>
    <li><a href="#ref-for-ftyp⑥">7.5. Requirements for Media Processing Entity Failover</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">3. Conventions and Terminology</a>
    <li><a href="#ref-for-moov①">6. Profile 1: CMAF Ingest General Considerations</a> <a href="#ref-for-moov②">(2)</a>
    <li><a href="#ref-for-moov③">7.3. Requirements for Timed Text Captions and Subtitle Streams</a>
    <li><a href="#ref-for-moov④">7.5. Requirements for Media Processing Entity Failover</a> <a href="#ref-for-moov⑤">(2)</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">7.1. General Protocol Requirements</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> <a href="#ref-for-moof①">(2)</a>
    <li><a href="#ref-for-moof②">6. Profile 1: CMAF Ingest General Considerations</a> <a href="#ref-for-moof③">(2)</a>
    <li><a href="#ref-for-moof④">7.2. Requirements for Formatting Media Tracks</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">3. Conventions and Terminology</a>
    <li><a href="#ref-for-mdat①">6. Profile 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. Profile 1: CMAF Ingest General Considerations</a>
    <li><a href="#ref-for-mfra①">7.1. 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①">7.2. 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">7.1. 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">7.2. 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③">7.3. 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">7.2. Requirements for Formatting Media Tracks</a> <a href="#ref-for-elng①">(2)</a>
    <li><a href="#ref-for-elng②">7.3. 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">7.3. Requirements for Timed Text Captions and Subtitle Streams</a>
    <li><a href="#ref-for-nmhd①">7.4. Requirements for Timed Metadata</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="media-fragment">
   <b><a href="#media-fragment">#media-fragment</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-media-fragment">7.2. Requirements for Formatting Media Tracks</a> <a href="#ref-for-media-fragment①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="fragmentedmp4stream">
   <b><a href="#fragmentedmp4stream">#fragmentedmp4stream</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-fragmentedmp4stream">3. Conventions and Terminology</a>
    <li><a href="#ref-for-fragmentedmp4stream①">7.1. General Protocol Requirements</a> <a href="#ref-for-fragmentedmp4stream②">(2)</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①">7.1. 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. Profile 1: CMAF Ingest General Considerations</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="arrival-time">
   <b><a href="#arrival-time">#arrival-time</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-arrival-time">7.4. Requirements for Timed Metadata</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="application-time">
   <b><a href="#application-time">#application-time</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-application-time">7.4. 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. Profile 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> <a href="#ref-for-ms-sstr①">(2)</a>
    <li><a href="#ref-for-ms-sstr②">6. Profile 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>