Система и способ для потоковой передачи воспроизводимого контента

Иллюстрации

Показать все

В соответствии с вариантом осуществления, способ включает в себя прием электронными средствами описания представления воспроизводимого материала (MPD) из сети. MPD описывает мультимедийный контент, который включает в себя альтернативные представления множества типов воспроизводимого материала, и MPD включает в себя информацию, указывающую, как кодируются альтернативные представления. Способ также включает в себя выбор одного из множества альтернативных представлений для, по меньшей мере, одного из множества типов воспроизводимого материала на основании информации, включенной в MPD, запрашивание выбранного одного из множества альтернативных представлений пофрагментно, и прием электронными средствами фрагмента воспроизводимых данных. 4 н. и 31 з.п. ф-лы, 4 ил.

Реферат

Настоящая патентная заявка испрашивает приоритет предварительной патентной заявки США № 61/258162, поданной 4 ноября 2009 г., озаглавленной “HTTP потоковая передача”, которая в полном объеме включена в настоящее описание изобретения посредством ссылки.

Область техники

Настоящее изобретение относится к системам связи, более конкретно, к системе и способу для потоковой передачи воспроизводимого контента.

Уровень техники

С ростом возможностей IP-сетей и сетевой инфраструктуры и с повышением качества технологии потоковой передачи видеоматериалов на основе интернета, популярность потоковая передачи в интернете для распространения видеоматериалов стремительно увеличивается. Один общий способ реализации потоковой передачи видео предусматривает передачу видеопрограммы с сервера протокола передачи гипертекстовых файлов (HTTP) на клиент HTTP, работающий во всемирной паутине. Потоковая передача видео во всемирной паутине получила широкое распространение благодаря простоте доступа, то есть предоставлению пользователю возможности просто кликнуть по ссылке, чтобы просмотреть видеоконтент.

Однако технология потоковой передачи видеоматериалов сталкивается с некоторыми трудностями. В ряде случаев, когда пользователь запрашивает видео-контент, может возникать существенная задержка прежде, чем контент начнет воспроизводиться. В ряде случаев, потоковая передача видео-контента прерывается или зависает вследствие большой сетевой нагрузки и/или неблагоприятных условий на линии связи. В других случаях, даже если сетевая линия связи первоначально работает хорошо, параметры просмотра могут в дальнейшем снижаться вследствие изменения условий в сети.

Сущность изобретения

В соответствии с вариантом осуществления, способ включает в себя прием электронными средствами описания представления воспроизводимого материала (MPD) из сети. MPD описывает мультимедийный контент, который включает в себя альтернативные представления множества типов воспроизводимого материала, и MPD включает в себя информацию, указывающую, как кодируются альтернативные представления. Способ также включает в себя выбор одного из множества альтернативных представлений для, по меньшей мере, одного из множества типов воспроизводимого материала на основании информации, включенной в MPD, запрашивание выбранного одного из множества альтернативных представлений пофрагментно, и прием электронными средствами фрагмента воспроизводимых данных.

Выше приведено обобщенное описание признаков варианта осуществления настоящего изобретения, чтобы можно было лучше понять нижеследующее подробное описание изобретения. Ниже описаны дополнительные признаки и преимущества вариантов осуществления изобретения, которые составляют предмет формулы изобретения. Специалистам в данной области техники очевидно, что концепцию и конкретные раскрытые варианты осуществления могут использоваться как основа для модификации или создания других структур или процессов, согласно задачам настоящего изобретения. Очевидно, что такие эквивалентные конструкции не выходят за рамки сущности и объема изобретения, установленных в нижеследующей формуле изобретения.

Краткое описание чертежей

Настоящее изобретения и его преимущества поясняются далее со ссылками на чертежи, на которых показано следующее:

фиг. 1 система потоковой передачи воспроизводимого материала;

фиг. 2 один мультимедийный контент, хранящийся на сервере потоковой передачи НТТР, показывающий вариант осуществления структуры данных;

фиг. 3 - вариант осуществления структуры описания представления воспроизводимого материала (MPD); и

фиг. 4 - компьютерная система для реализации способов, отвечающих варианту осуществления.

Соответствующие числовые и символьные обозначения на чертежах относятся к соответствующим частям, если не указано иное. Фигуры представлены для иллюстрации аспектов вариантов осуществления и не всегда выполнены в масштабе.

Подробное описание иллюстративных вариантов осуществления

Ниже подробно рассмотрено формирование и использование различных вариантов осуществления. Однако очевидно, что настоящее изобретение обеспечивает многочисленные применимые идеи изобретения, которые можно реализовать в разнообразных конкретных контекстах. Рассмотренные конкретные варианты осуществления призваны всего лишь иллюстрировать конкретные пути создания и использования изобретение, но не ограничивать объем изобретения.

Настоящее изобретение описано применительно к вариантам осуществления в конкретных контекстах, например, системы и способа для потоковой передачи воспроизводимого контента. В частности, некоторые варианты осуществления относятся к потоковой передаче воспроизводимого контента на основе протокола HTTP.

Фиг. 1 иллюстрирует систему 100 потоковой передачи воспроизводимого контента на основе http, в которой реализованы концепции и способы настоящего изобретения. Система 100 имеет сервер 102 потоковой передачи HTTP, который передает воспроизводимый материал потоковой передачи на клиент 106 потоковой передачи HTTP через IP-сеть 104. Очевидно, что альтернативные варианты осуществления также могут относиться к другим системам потоковой передачи помимо систем потоковой передачи HTTP.

Варианты осуществления настоящего изобретения используют системы и способы для потоковой передачи HTTP мультимедийных потоков аудио и/или видео и/или других типов воспроизводимого материала. Эти системы и способы обеспечивают гибкую и эффективную поддержку потоковой передачи по требованию и в реальном времени на основании способа хранения, описания представления воспроизводимого материала (MPD) и использования запросов HTTP GET с байтовыми диапазонами или без них. В MPD могут быть включены байтовый диапазон и временной диапазон сегмента воспроизводимого материала, что позволяет клиентам эффективно запрашивать сегменты воспроизводимого материала с использованием только байтовых диапазонов. MPD может включать в себя дополнительную информацию кодека для альтернативного представления воспроизводимого материала для поддержки контентов воспроизводимого материала, кодированных согласно более чем одной конфигурации кодирования. Например, MPD 202 на фиг. 2 указывает альтернативные представления 204, 206, 208 и 210. Каждое из этих альтернативных представлений может охватывать единичный файл или множественные файлы данных воспроизводимого контента, причем с каждым файлом связан уникальный унифицированный указатель ресурса (URL).

Максимальная длина всех сегментов может быть включена в MPD для обеспечения возможности использования байтового диапазона без сигнализации байтовых диапазонов в MPD и значительного сокращения размера MPD, что позволяет уменьшить задержку запуска для процесса потоковой передачи. Для указания окончания сеанса потоковой передачи в реальном времени, сервер может составить следующий ожидаемый файл или сегмент аномальным образом, например, создать пустой файл или сегмент. Чтобы обеспечить переход к сеансу потоковой передачи в реальном времени и начать запрашивать самый последний контент, для файла, содержащего самый последний сегмент, имеющийся на сервере потоковой передачи, используется особое имя файла и, следовательно, особый URL. Чтобы клиент мог понять, с какого файла начинать, когда он желает найти конкретную временную позицию, в то время как длительность сегмента постоянна, и ни для какого сегмента в MPD не сигнализируются байтовые смещения и временные смещения, можно формировать URL файла, чтобы иметь возможность указывать время начала воспроизведения файла. Предусмотрены эффективные процессы потоковой передачи, которые обеспечивают нормальные процессы потоковой передачи, такие как запуск, пауза, возобновление и остановка, а также процессы поиска, перемотки вперед, перемотки назад и адаптации потока.

Фиг. 3 иллюстрирует структуру 300 MPD согласно одному варианту осуществления настоящего изобретения. MPD 300 имеет информацию 302 байтового диапазона и временного диапазона, информацию 304 длительности сегмента, информацию 306 перемотки вперед и назад, информацию 308 URL и информацию 310 частоты кадров. В некоторых вариантах осуществления может быть включена другая информация 312. В альтернативных вариантах осуществления можно использовать подмножество структуры 300 MPD.

Фиг. 4 иллюстрирует компьютерную систему 400, приспособленную для использования согласно вариантам осуществления настоящего изобретения, например, для хранения и/или выполнения программного обеспечения, связанного с вариантами осуществления. Центральный процессор (ЦП) 401 подключен к системной шине 402. ЦП 401 может быть любым ЦП общего назначения. Однако варианты осуществления настоящего изобретения не ограничены архитектурой ЦП 401 при условии, что ЦП 401 поддерживает описанные здесь операции, отвечающие изобретению. Шина 402 подключена к оперативной памяти (ОЗУ) 403, которая может представлять собой SRAM, DRAM или SDRAM. К шине 402 также подключено ПЗУ 404, которое может представлять собой ППЗУ, ЭППЗУ или ЭСППЗУ. В ОЗУ 403 и ПЗУ 404 содержатся пользовательские и системные данные и программы, известные в технике.

Шина 402 также подключено к адаптеру 405 ввода/вывода (I/O), адаптер 411 связи, адаптер 408 пользовательского интерфейса, и мультимедийный адаптер 409. Адаптер 405 ввода/вывода подключает запоминающие устройства 406, например, один или более из жесткого диска, привода CD, привода флоппи-диска, накопителя на магнитной ленте, к компьютерной системе 400. Адаптер 405 ввода/вывода также подключен к принтеру (не показан), который позволяет системе печатать бумажные копии информации, например, документы, фотографии, статьи и пр. Заметим, что принтер может представлять собой, например, матричный, лазерный и пр. принтер, факсимильный аппарат, сканер или копир. Адаптер пользовательского интерфейса подключен к клавиатуре 413 и мыши 407, а также к другим устройствам. Мультимедийный адаптер 409, который в некоторых вариантах осуществления может представлять собой видео и/или звуковую карту, подключен к устройству 410 отображения и акустическому устройству 415. Устройством 410 отображения может быть ЭЛТ, плоскопанельный дисплей или устройство отображения другого типа, и акустическим устройством 415 может быть громкоговоритель, наушники или другая аналоговая или цифровая аудиосистема.

В некоторых вариантах осуществления, потоковая передача HTTP означает потоковую передачу мультимедийных контентов на основе протокола HTTP. 3GPP поддерживает потоковую доставку после выпуска 4 своих спецификаций. 3GPP TS 26.234 задает потоковую доставку на основе RTSP и RTP по UDP. Потоковая передача HTTP получила широкое распространение как разновидность доставки видеоматериалов в интернете, и http все чаще используется как основной протокол для доставки мультимедиа. В альтернативных вариантах осуществления можно использовать другие системы и стандарты потоковой передачи.

Технические основания популярности потоковой передачи HTTP включают в себя возможность использовать стандартные серверы и стандартные кэши HTTP (или, в целом, дешевые серверы) для доставки контента, что позволяет доставлять его с CDN или любой другой стандартной серверной фермы, возможность перемещать управление "сеансами потоковой передачи" целиком на клиент, что, в принципе, только открывает одно или несколько соединений TCP с одним или несколькими стандартными серверами HTTP или кэшами, потоковая передача HTTP также популярна, поскольку обеспечивает легкие и нетрудоемкие услуги потоковой передачи благодаря обходу вопросов прохождения NAT и брандмауэра.

Один подход к потоковой передаче HTTP именуется статическим режимом обслуживания контента. В этом режиме, стандартный сервер HTTP используется без какого-либо расширения. Контент обеспечивается в виде файла или собрания файлов, имеющихся на сервере HTTP. Клиент получает контент, обращаясь к файлам с использованием запроса HTTP GET с байтовыми диапазонами или без них.

Существующие решения для потоковой передачи HTTP на основе вышеозначенного подхода оставляют нерешенными, по меньшей мере, следующие проблемы. Во-первых, использование временных диапазонов в запросах HTTP GET упрощает для клиента запрашивание воспроизводимых данных с сервера потоковой передачи. Однако существующие стандартные серверы HTTP понимают байтовые диапазоны, но не понимают временные диапазоны.

Во-вторых, нет возможности сигнализировать в MPD информацию о более одной конфигурации кодирования для альтернативного представления воспроизводимого материала. В-третьих, для обеспечения малой задержки запуска, предпочтительно иметь MPD малого размера. Таким образом, в ряде случаев, в MPD желательно не иметь информации, зависящей от файла или сегмента воспроизводимого материала, поскольку представление можно разбить на большое количество файлов во временном измерении. Однако у клиента нет возможности содержательно запрашивать сегменты воспроизводимого материала в отсутствие в MPD информации, зависящей от файла или сегмента воспроизводимого материала, например, временных диапазонов и/или байтовых диапазонов.

В-четвертых, сервер должен информировать клиентов о завершении сеанса потоковой передачи в реальном времени, чтобы они не продолжали безуспешные попытки, раздражающие пользователя. Один способ извещения об этом клиентов состоит в использовании регулярно обновляемого MPD. Однако для этого требуется, чтобы клиент регулярно принимал обновление MPD, что сопряжено с дополнительными затратами ресурсов на клиенте, что обременительно, когда желательно и возможно использовать статическое MPD.

В-пятых, при переходе к потоковой передаче в реальном времени, клиент обычно желает начать принимать самый последний контент. Для этого предполагается сообщение информации URL и/или байтового диапазона самого последнего сегмента воспроизводимого материала через регулярно обновляемое MPD. Однако для этого требуется, чтобы клиент регулярно принимал обновление MPD, что сопряжено с дополнительными затратами ресурсов на клиенте, что обременительно, когда желательно и возможно использовать статическое MPD.

В-шестых, когда длительность сегмента постоянна, и ни для какого сегмента в MPD не сигнализируются байтовые смещения и временные смещения, клиент не может понять, с какого файла начинать, когда он хочет найти конкретную временную позицию. Наконец, в потоковой передаче HTTP отсутствует механизм для поддержки перемотки вперед и перемотки назад.

Для решения вышеперечисленных проблем, предусмотрены следующие новые признаки среди тех, которые обеспечены вариантами осуществления изобретения. Во-первых, в MPD могут быть включены байтовый диапазон и временной диапазон сегмента воспроизводимого материала, что позволяет клиентам эффективно запрашивать сегменты воспроизводимого материала с использованием только байтовых диапазонов. Во-вторых, MPD может включать в себя дополнительную информацию кодека для альтернативного представления воспроизводимого материала для поддержки контентов воспроизводимого материала, кодированных согласно более чем одной конфигурации кодирования.

В-третьих, максимальная длина всех сегментов может быть включена в MPD для обеспечения возможности использования байтового диапазона без сигнализации байтовых диапазонов в MPD и значительного сокращения размера MPD, что позволяет уменьшить задержку запуска для процесса потоковой передачи. В-четвертых, для указания окончания сеанса потоковой передачи в реальном времени, сервер может составить следующий ожидаемый файл или сегмент аномальным образом, например, создать пустой файл или сегмент. В-пятых, чтобы обеспечить переход к сеансу потоковой передачи в реальном времени и начать запрашивать самый последний контент, для файла, содержащего самый последний сегмент, имеющийся на сервере потоковой передачи, используется особое имя файла и, следовательно, особый URL.

В-шестых, задан префикс URL для альтернативного представления. URL файла, содержащего один или более сегментов альтернативного представления, представляет собой конкатенацию префикса URL для альтернативного представления и соответствующего значения индекса файла, например, в виде пяти десятичных цифр, например, 00000, 00005, 00012, и т.д. Для каждого альтернативного представления, значение индекса файла для первого файла (содержащего ячейку 'moov') равно 0, и значение индекса файла для других файлов равно значению индекса сегмента первого сегмента, содержащегося в файле, которое равно полю порядкового номера, находящемуся в ячейке заголовка фрагмента фильма фрагмента фильма, соответствующего первому сегменту, содержащемуся в файле. Таким образом, когда длительность сегмента постоянна, и ни для какого сегмента в MPD не сигнализируются байтовые смещения и временные смещения, клиент может понять, с какого файла начинать, когда он хочет найти конкретную временную позицию.

Наконец, предусмотрены эффективные процессы потоковой передачи, которые обеспечивают нормальные процессы потоковой передачи, такие как запуск, пауза, возобновление и остановка, а также процессы поиска, перемотки вперед, перемотки назад и адаптации потока.

Варианты осуществления настоящего изобретения включают в себя подход для статического режима обслуживания контента потоковой передачи HTTP, включающий в себя хранение файлов, описание представления воспроизводимого материала и процессы потоковой передачи для потоковой передачи по требованию и потоковой передачи в реальном времени.

Что касается хранения файлов, в некоторых вариантах осуществления описание представления воспроизводимого материала (MPD) сохраняется в отдельном файле само по себе. В одном варианте осуществления, файлы воспроизводимого материала сохраняются таким образом, что каждый файл содержит один или более сегментов одного альтернативного представления. Например, в некоторых вариантах осуществления, файл может содержать только один или более сегментов одного альтернативного представления аудиоматериала, файл может содержать только один или более сегментов одного альтернативного представления видеоматериала, файл может содержать только один или более сегментов одного альтернативное представление аудио-видеоматериала, состоящего из одного альтернативного представления аудиоматериала и одного представления видеоматериала. Однако, в одном варианте осуществления, файл на самом деле содержит один или более сегментов более чем одного альтернативного представления видеоматериала, и не содержит один или более сегментов более чем одного альтернативного представления аудиоматериала.

Согласно варианту осуществления, первый сегмент одного альтернативного представления содержит ячейку 'ftyp' и ячейку 'moov', но не содержит ячейку 'moof'. В ячейке 'moov', в одном варианте осуществления, не задокументировано ни одного образца воспроизводимого материала, т.е., счетчик элементов в каждой ячейке 'stts', содержащийся в ячейке 'moov', должен быть равен 0, и счетчик образцов в каждой ячейке 'stsz' или 'stz2', содержащийся в ячейке 'moov', должен быть равен 0. Поскольку в первом сегменте не задокументировано ни одного образца, нет необходимости в соответствующей ячейке 'mdat'. Согласно варианту осуществления, любой другой сегмент кроме первого сегмента содержит строго один фрагмент фильма. Альтернативно, можно использовать более одного фрагмента фильма. Кроме того, для любого другого сегмента кроме первого сегмента, метаданные (ячейка 'moof' и т.д.) и воспроизводимые данные (ячейка 'mdat') должны храниться в одном и том же файле.

Для некоторых альтернативных представлений, разбиение образцов воспроизводимого материала на сегменты выравнивается по времени, так что n-й сегмент альтернативного представления A охватывает тот же период времени, что и для любого другого альтернативного представления B. Допустимо исключение для альтернативных представлений перемотки вперед и перемотки назад, для которых один сегмент охватывает целое число сегментов в альтернативных представлениях для нормального воспроизведения.

Альтернативно вышеописанному подходу к хранению (именуемому подходом 1 к хранению), предполагается наличие одной "гигантской" ячейки 'moov', содержащий первые сегменты альтернативных представлений, и это сохраняется в отдельном файле само по себе, тогда как другие сегменты альтернативных представлений сохраняются согласно вышеописанному подходу к хранению. Этот альтернативный подход именуется подходом 2 к хранению. Для обоих подходов 1 и 2 к хранению, MPD также может быть включено в ячейку 'moov' или доступно по URL, включенном в ячейку 'moov'.

Для потоковой передачи в реальном времени, помимо вышеописанных спецификаций, справедливо следующее:

В одном варианте осуществления, когда используется формат H.264/AVC видео, наборы параметров сохраняются в отдельной последовательности наборов параметров, а не в элементах образца, поскольку видеокодеру может потребоваться определить оптимальные параметры кодирования в ходе кодирования и поэтому наборы параметров не могут быть известны и включены при генерации ячейки 'moov'.

Согласно варианту осуществления, альтернативный способ сохранения MPD предполагает его сохранение как части файла воспроизводимого материала. Однако сохранение MPD в виде отдельного файла самого по себе облегчает доступ к MPD, в частности в случае потоковой передачи по требованию, поскольку для вызова MPD можно использовать лишь один запрос HTTP GET. Если он сохраняется как часть файла воспроизводимого материала, то для запроса строго MPD, клиенту должно быть известно точное местоположение MPD в файле. Еще одно преимущество отдельного хранения MPD состоит в значительном упрощении процесса для потоковой передачи в реальном времени, поскольку увеличение записей MPD не будет оказывать влияния на смещение части воспроизводимого материала файла воспроизводимого материала, содержащего MPD.

Существует много альтернативных способов сохранения воспроизводимого контента, исключая MPD. Например, первый альтернативный способ предусматривает сохранение всех альтернативных представлений в одном файле, как обычно делается в потоковой передаче на основе RTP/RTSP. Второй альтернативный способ предусматривает сохранение всех метаданных (ячейки 'moov' и ячеек 'moov' и т.д.) в одном файле, и всех воспроизводимых данных (ячейки или ячеек 'mdat') в других файлах, без разделения на множественные файлы во временном измерении (т.е. всех сегментов одного альтернативного представления в одном файле). В некоторых вариантах осуществления, эти два способа сохранения могут быть неблагоприятны для кэширования.

Третий альтернативный способ аналогичен второй альтернативе, но предусматривает разделение на множественные файлы во временном измерении, например, каждый сегмент сохраняется в двух отдельных файлах, один из которых служит для метаданных (ячейка 'moov' или 'moof'), а другой для воспроизводимых данных (ячейка 'mdat'). Основным недостатком этого способа хранения по сравнению с предложенным подходом является то, что количество файлов удваивается, и, следовательно, удваивается количество запросов HTTP для потоковой передачи одного и того же контента.

Четвертая альтернатива предусматривает сохранение одного или более сегментов каждого альтернативного представления аудио-видеоматериала в одном файле. Основным недостатком этого способа является избыточное хранение. Например, при наличии двух альтернативных представлений аудиоматериала, каждое альтернативное представление видеоматериала повторно сохраняется дважды.

Для потоковой передачи видео в реальном времени в формате H.264/AVC, наборы параметров также могут сохраняться в элементах образца. Однако это не позволяет видеокодеру переходить к более оптимальным параметрам кодирования в ходе кодирования. Другой альтернативной является помещение новых наборов параметров в новую ячейку, содержащуюся в ячейке 'moof'. В некоторых отношениях, этот подход не обладает обратной совместимостью, и существующие программы чтения файлов в формате H.264/AVC будут игнорировать новую ячейку, причем новые наборы параметров необходимы для правильного декодирования образцов, содержащихся во фрагменте фильма.

Ниже приведен вариант осуществления синтаксиса и семантики для MPD:

media_presentation_description()

{

//начало глобальной информации

BOOL live_session;

byte(4) major_brand;

byte(4) timescale;

byte(4) presentation_duration;

BOOL constant_segment_duration;

if(constant_segment_duration)

byte(4) segment_duration;

BOOL constant_num_segments_per_file;

if(constant_num_segments_per_file)

byte(4) num_segments_in_one_file;

BOOL num_segments_aligned;

BOOL byte_offset_included;

BOOL codec_mime_type_included_for_each_file;

byte(2) num_separate_audio_alternatives;

byte(2) num_separate_video_alternatives;

byte(2) num_av_combined_alternatives;

byte(2) num_video_fastforward_alternatives;

byte(2) num_video_rewind_alternatives;

for (i=0; i<num_separate_audio_alternatives; i++){

string codec_mime_type;

byte(4) avg_bitrate;

byte(2) language_code;

byte(1) channel_count;

string url_prefix;

byte(4) max_segment_len_in_bytes;

}

for (i=0; i<num_separate_video_alternatives; i++){

string codec_mime_type;

byte(4) width;

byte(4) height;

byte(4) avg_framerate;

byte(4) avg_bitrate;

string url_prefix;

byte(4) max_segment_len_in_bytes;

}

for (i=0; i<num_av_combined_alternatives; i++){

string audio_codec_mime_type;

byte(4) audio_avg_bitrate;

byte(2) language_code;

byte(1) channel_count;

string video_codec_mime_type;

byte(4) width;

byte(4) height;

byte(4) avg_framerate;

byte(4) video_avg_bitrate;

string url_prefix;

byte(4) max_segment_len_in_bytes;

}

for (i=0; i<num_video_fastforward_alternatives; i++){

string codec_mime_type;

byte(4) width;

byte(4) height;

byte(4) avg_framerate;

byte(4) avg_bitrate;

string url_prefix;

byte(4) max_segment_len_in_bytes;

byte(1) num_segments_denominator_ff[i];

}

for (i=0; i<num_video_rewind_alternatives; i++){

string codec_mime_type;

byte(4) width;

byte(4) height;

byte(4) avg_framerate;

byte(4) avg_bitrate;

string url_prefix;

byte(4) max_segment_len_in_bytes;

byte(1) num_segments_denominator_rw[i];

}

//конец глобальной информации, начало информации, зависящей от сегмента

// Следующие шесть полей являются просто переменными,

// и для них не существует битов, используемых в MPD

file_index_a=0;

file_index_v=0;

file_index_av=0;

file_index_ff=0;

file_index_rw=0;

file_index=-1;

while(!EoMPD){//EoMPD – конец описания представления воспроизводимого

//материала

file_index++;

if((!constant_num_segments_per_file)&&(num_segments_aligned))

byte(4) num_segments_in_one_file;

for (i=0; i<num_separate_audio_alternatives; i++){

if(codec_mime_type_included_for_each_file)

string audio_codec_mime_type_for_one_file;

mpd_for_one_file();

file_index_a+=num_segments_in_one_file;

}

for (i=0; i<num_separate_video_alternatives; i++) {

if(codec_mime_type_included_for_each_file)

string video_codec_mime_type_for_one_file;

mpd_for_one_file();

file_index_v += num_segments_in_one_file;

}

for (i=0; i<num_av_combined_alternatives; i++){

if(codec_mime_type_included_for_each_file){

string audio_codec_mime_type_for_one_file;

string video_codec_mime_type_for_one_file;

}

mpd_for_one_file();

file_index_av+=num_segments_in_one_file;

}

for (i=0; i<num_video_fastfoward_alternatives; i++){

if((!file_index)||

(file_index%num_segments_denominator_ff[i]==1)){

if(codec_mime_type_included_for_each_file)

string

video_codec_mime_type_for_one_file;

mpd_for_one_file();

file_index_ff+=num_segments_in_one_file;

}

}

for (i=0; i<num_video_rewind_alternatives; i++){

if((!file_index)||

(file_index%num_segments_denominator_ff[i]==1)){

if(codec_mime_type_included_for_each_file)

string

video_codec_mime_type_for_one_file;

mpd_for_one_file();

file_index_rw+=num_segments_in_one_file;

}

}

}

}

mpd_for_one_file()

{

if((!constant_num_segments_per_file)&&(!num_segments_aligned))

byte(4) num_segments_in_one_file;

for(i=0; i<num_segments_in_one_file; i++){

if(!constant_segment_duration) {

byte(4) segment_start_time;

byte(4) segment_duration;

}

if(byte_offset_included) {

byte(4) segment_start_byte_offset;

byte(4) segment_end_byte_offset;

}

}

}

Согласно варианту осуществления, заданы следующие переменные:

live_session: Это поле, равное FALSE, указывает, что MPD предназначено для сеанса потоковой передачи по требованию. Значение TRUE указывает, что MPD предназначено для сеанса потоковой передачи в реальном времени.

major_brand: Главный идентификатор брэнда файла, указывающий признаки формата файла, которые должен поддерживать клиент, чтобы иметь возможность воспроизводить представление воспроизводимого материала.

timescale: Целое число, которое задает масштаб времени для всего представления; это количество единиц времени, которые проходят за одну секунду. Например, система координат времени, которая измеряет время в шестидесятых долях секунды, имеет timescale 60.

presentation_duration: Целое число, указывающее длину представления (в указанном масштабе времени) альтернативного представления для нормального воспроизведения. Когда значение равно 0, длина представления неизвестна. В описании представления воспроизводимого материала для сеанса потоковой передачи в реальном времени это значение задано равным 0.

constant_segment_duration: когда значение равно TRUE, длина сегмента постоянна во времени. Когда значение равно FALSE, длина сегмента во времени не постоянна.

segment_duration: Задает длину сегмента во времени (в указанном масштабе времени).

constant_num_segments_per_file: Когда значение равно TRUE, за исключением файла(ов), содержащего(их) ячейку 'moov', каждый файл содержит постоянное количество сегментов. Когда значение равно FALSE, файлы, не содержащие ячейку 'moov', могут содержать разные количества сегментов.

num_segments_in_one_file: Задает количество сегментов (за исключением файла(ов), содержащего(их) ячейку 'moov') в одном файле.

num_segments_aligned: Когда значение равно TRUE, количество сегментов в каждом файле выравнивается по времени для всех альтернативных представлений. Когда значение равно FALSE, количество сегментов в каждом файле не выравнивается по времени для всех альтернативных представлений.

byte_offset_included: Когда значение равно TRUE, байтовые смещения для каждого сегмента включены в MPD. Когда значение равно FALSE, байтовые смещения для каждого сегмента не включены в MPD.

codec_mime_type_included_for_each_file: Когда значение равно TRUE, тип MIME кодека включен в конкретную часть файла MPD. Когда значение равно FALSE, тип MIME кодека информация включен только в глобальную часть MPD.

num_separate_audio_alternatives: Задает количество раздельно хранящихся альтернативных представлений аудиоматериала.

num_separate_video_alternatives: Задает количество раздельно хранящихся альтернативных представлений видеоматериала.

num_av_combined_audio_alternatives: Задает количество раздельно хранящихся альтернативных представлений аудио-видеоматериала.

num_video_fastforward_alternatives: Задает количество раздельно хранящихся альтернативных представлений перемотки видеоматериала вперед.

num_video_rewind_alternatives: Задает количество раздельно хранящихся альтернативных представлений перемотки видеоматериала назад.

codec_mime_type: Задает параметр типа MIME для начальных образцов воспроизводимого материала воспроизводимого материала типа аудио или видео в альтернативном представлении. Для видео, этот параметр типа MIME включает в себя также информацию профиля и уровня.

avg_bitrate/audio_avg_bitrate/video_avg_bitrate: Задает среднюю битовую скорость воспроизводимого материала типа аудио или видео в альтернативном представлении, в битах в секунду.

language_code: Указывает код языка для этого воспроизводимого материала. См. в ISO 639-2/T набор из трех кодов символов. Каждый символ упакован как разность между его значением ASCII и 0x60. Поскольку код ограничен тремя буквами в нижнем регистре, эти значения строго положительны.

channel_count: Задает количество аудиоканалов воспроизводимого материала типа аудио в альтернативном представлении.

url_prefix: Задает префикс URL для альтернативного представления. URL файла, содержащего один или более сегментов альтернативного представления, представляет собой конкатенацию префикса URL для альтернативного представления и соответствующего значения индекса файла, например, в виде пяти десятичных цифр, например, 00000, 00005, 00012 и т.д. Значение индекса файла выводится из MPD. Для каждого альтернативного представления, значение индекса файла для первого файла (содержащего ячейку 'moov') равно 0, значение индекса файла для других файлов равно значению индекса сегмента первого сегмента, содержащегося в файле, которое равно полю sequence_number находящемуся в ячейке заголовка фрагмента фильма фрагмента фильма, соответствующего первому сегменту, содержащемуся в файле. Когда длительность сегмента постоянна, и ни для какого сегмента в MPD не сигнализируются байтовые смещения и временные смещения, клиент может понять, с какого файла начинать, когда он хочет найти конкретную временную позицию.

max_segment_len_in_bytes: Задает максимальную длину сегмента в байтах. Это значение позволяет использовать надлежащий байтовый диапазон, не сигнализируя все байтовые диапазоны в MPD. Например, начиная с начала сегмента, не зная длину сегмента в байтах, клиент может запрашивать блок данных размером, равным max_segment_len_in_bytes, чтобы гарантированно запрашивать весь сегмент. Начиная с конкретной позиции сегмента, не зная длину сегмента в байтах, клиент может запрашивать блок данных размером, равным max_segment_len_in_bytes за минусом конкретной позиции сегмента в байтах, чтобы гарантированно запрашивать весь сегмент.

width: Задает горизонтальное разрешение воспроизводимого материала типа видео в альтернативном представлении, выражаемое в пикселях.

height: Задает вертикальное разрешение воспроизводимого материала типа видео в альтернативном представлении, выражаемое в пикселях.

avg_framerate: Задает среднюю частоту кадров, выражаемую в кадрах за 256 секунд, воспроизводимого материала типа видео в альтернативном представлении. Для альтернативных представлений перемотки вперед или перемотки назад видеоматериала, это значение вычисляется как количество всех кадров видео, деленное на длину представления (в указанном масштабе времени) альтернативного представления для нормального воспроизведения с последующим масштабированием до количества кадров за 256 секунд.

num_segments_denominator_ff[i]: Каждый сегмент i-го альтернативное представление перемотки видео вперед соответствует числу, равному num_segments_denominator_ff[i] сегментов в альтернативном представлении видеоматериала для нормального воспроизведения.

num_segments_denominator_rw[i]: Каждый сегмент i-го альтернативное представление перемотки видео назад соответствует числу, равному num_segments_denominator_rw[i] сегментов в альтернативном представлении видеоматериала для нормального воспроизведения.

audio_codec_mime_type_for_one_file: Задает тип MIME кодека для образцов аудиосигнала в файле, соответствующий конкретному значению индекса файла.

video_codec_mime_type_for_one_file: Задает тип MIME кодека для образцов видеосигнала в файле, соответствующий конкретному значению индекса файла. Это значение включает в себя информацию профиля и уровня.

segment_start_time: Задает начальное время сегмента, в миллисекундах, относительно начала представления.

segment_duration: Задает длительность сегмента, в указанном масштабе времени.

segment_start_byte_offset: Задает байтовое смещение первого байта сегмента в файле, содержащем сегмент.

segment_end_byte_offset: задает байтовое смещение последнего байта сегмента в файле, содержащем сегмент.

Очевидно, что альтернативный вариант осуществления может охватывать подмножество вышеописанных команд, переменных и определений.

Согласно варианту осуществления, MPD можно описать на XML или в SDP, или в виде полей блоков данные, включенных в новую ячейку согласно основному формату файл воспроизводимого материала ISO. MPD в форме XML или SDP также может быть включено в ячейку, например ячейку 'moov', или в новую ячейку сразу после ячейки 'ftyp' в файле.

Ниже приведена иллюстративная схема XML, которая задает формат любого MPD в XML.

Вышеописанный вариант осуществления синтаксиса и семантики для MPD применяется к подходу 1 к хранению для некоторых вариантов осуществления. При использовании подхода 2 к хранению, MPD можно немного видоизменить в некоторых вариантах осуществления следующим образом. Например, MPD может быть включено в "гигантскую" ячейку 'moov' или доступно по URL в "гигантской" ячейке 'moov'. Поля, эквивалентная информация для которых присутствует в "гигантской" ячейке 'moov', например, major_brand, timescale и presentation_duration, можно исключить из MPD. Затем значения индекса файла первоначально задаются равными 1, а не 0, так что в цикле после глобальной информации значение индекса начинается с 1, и значение индекса файла 0 зарезервировано для файла, содержащего "гигантскую" ячейку 'moov'.

Согласно варианту осуществления, префикс URL добавляется как часть глобальной информации для файла, содержащего "гигантскую" ячейку 'moov', и URL для файла является конкатенацией префикса URL и "00000". Альтернативно, сам URL файла добавляется как часть г