СИСТЕМА И СПОСОБ ДЛЯ ПОТОКОВОЙ ПЕРЕДАЧИ ВОСПРОИЗВОДИМОГО КОНТЕНТА
SYSTEM AND METHOD FOR FLOW TRANSFER OF REPRODUCED CONTENT

Настоящая патентная заявка испрашивает приоритет предварительной патентной заявки США № 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 файла добавляется как часть глобальной информации.
Для сигнализации информации кодека в MPD, альтернативный способ предусматривает сигнализацию одного глобального типа MIME кодека для одного альтернативного представления одного типа воспроизводимого материала, и указание, что глобальный codec_mine_type указывает только первоначальный тип MIME кодека типа воспроизводимого материала в альтернативном представлении. Аналогичные подходы можно применять для потоковой передачи мультимедийных контентов, содержащих другие типы воспроизводимого материала, например, синхронизированный текст и синхронизированную графику.
В некотором варианте осуществления, реализуется процесс потоковой передачи по требованию, который обеспечивает признаки запуска, паузы, возобновления и остановки. Согласно варианту осуществления, запуск потоковой передачи включает в себя следующие этапы. Во-первых, клиент получает URL MPD. Каким образом клиент получает URL MPD, выходит за рамки объема этого документа. Во-вторых, клиент получает MPD, например, с использованием запроса HTTP GET. Также возможно, что клиент получает MPD в последовательном режиме, т.е. используя множественные запросы HTTP GET с байтовыми диапазонами. При использовании последовательного запрашивания MPD, следующие этапы могут уже начаться, как только MPD данные для соответствующих сегментов станут доступны на клиенте, и клиент может использовать отдельную линию связи TCP для запрашивания MPD, одновременно используя линии связи TCP для запрашивания сегментов. При использовании подхода 2 к хранению, клиент получает файл, содержащий "гигантскую" ячейку 'moov' и, если MPD не включено, MPD, используя один запрос HTTP GET или в последовательном режиме;
В-третьих, клиент анализирует MPD и выбирает одно или более надлежащих альтернативных представлений (по одному для каждого типа воспроизводимого материала), содержащие все типы воспроизводимого материала, необходимые клиенту. При использовании подхода 2 к хранению, клиент может анализировать файл, содержащий "гигантскую" ячейку 'moov' и использовать содержащуюся в ней информацию, помимо или включая MPD, при выборе надлежащих альтернативных представлений.
В-четвертых, клиент запрашивает сегменты выбранных альтернативных представлений, начиная с первого сегмента для каждого выбранного альтернативного представления. При использовании подхода 2 к хранению, клиент запрашивает сегменты выбранных альтернативных представлений, начиная со второго сегмента для каждого выбранного альтернативного представления.
Согласно варианту осуществления, URL файла, содержащего конкретный сегмент, указан в MPD, причем каждое значение индекса файла соответствует одному файлу и количеству сегментов, и URL для одного значения индекса файла является конкатенацией соответствующего префикса URL и значения индекса файла, например в форме 5 десятичных цифр. Это правило применяется ко всем запросам HTTP GET, предусмотренным в процессе потоковой передачи, включая случай потоковой передачи в реальном времени. При использовании подхода 2 к хранению, значение индекса файла 00000 зарезервировано для файла, содержащего "гигантскую" ячейку 'moov'.
Если запрашивается весь файл, независимо от того, содержит ли он один или более сегментов, использовать байтовый диапазон не требуется. Если в файле хранится более одного сегмента, и клиент запрашивает подмножество всех сегментов, включенных в файл, нужно использовать байтовый диапазон. Это правило применяется ко всем запросам HTTP GET, предусмотренным в процессе потоковой передачи, включая случай потоковой передачи в реальном времени.
Согласно варианту осуществления, для выполнения паузы или остановки, клиент просто перестает запрашивать данные путем отправки запросов HTTP GET. Для выполнения возобновления, клиент отправляет запросы HTTP GET для запрашивания сегментов, начиная со следующего сегмента после последнего запрошенного сегмента.
Согласно варианту осуществления, для поиска конкретной позиции, вперед или назад, клиент отправляет запросы HTTP GET для запрашивания сегментов текущих альтернативных представлений, начиная с сегмента, начинающегося с конкретной позиции. Заметим, что поиск может быть нацелен только на конкретные позиции, где начинается сегмент. Для поиска конкретной позиции в направлении назад, если клиент буферизовал данные после этой конкретной позиции, он может воспроизводить данные буфера после этой конкретной позиции.
Согласно варианту осуществления, для осуществления перемотки вперед с конкретной скоростью воспроизведения, осуществляются следующие этапы. Во-первых, клиент перестает запрашивать данные текущих альтернативных представлений. Во-вторых, клиент выбирает надлежащее альтернативное представление перемотки видео вперед, частота кадров которого наилучшим образом соответствует целевой скорости воспроизведения. В-третьих, клиент запрашивает сегменты выбранного альтернативного представления, начиная с временной позиции сразу после последнего запрошенного сегмента. В одном варианте осуществления, клиент воспроизводит воспроизводимый материал на заданной скорости воспроизведения.
Согласно варианту осуществления, для осуществления перемотка назад с конкретной скоростью воспроизведения, осуществляются следующие этапы. Во-первых, клиент перестает запрашивать данные текущих альтернативных представлений. Во-вторых, клиент выбирает надлежащее альтернативное представление перемотки видео назад, частота кадров которого наилучшим образом соответствует целевой скорости воспроизведения. В-третьих, клиент запрашивает сегменты выбранного альтернативного представления, начиная с временной позиции сразу после последнего запрошенного сегмента. В одном варианте осуществления, для этого требуется, чтобы при создании альтернативных представлений перемотки видео назад, порядок декодирования кадров видео был обратным относительно порядка отображения. Согласно варианту осуществления, клиент воспроизводит воспроизводимый материал на заданной скорости воспроизведения.
Согласно варианту осуществления, для осуществления адаптации потоковой передачи путем переключения с одного альтернативного представления A на другое альтернативное представление B, осуществляются следующие этапы. Во-первых, клиент перестает запрашивать данные текущих альтернативных представлений.
Во-вторых, если клиент ни разу не принял ни одного сегмента B, то клиент сначала запрашивает первый сегмент B, а затем запрашивает сегменты B, начиная с временной позиции сразу после последнего запрошенного сегмента. Одновременно клиент сохраняет первый сегмент B для использования в будущем при переключении обратно на B из любого другого альтернативного представления. Если клиент принял и сохранил первый сегмент B, то запрашивание первого сегмента пропускается. При использовании подхода 2 к хранению, клиент просто запрашивает сегменты B, начиная с временной позиции сразу после последнего запрошенного сегмента.
Согласно варианту осуществления, для потоковой передачи в реальном времени, следующие ограничения применяются в некоторых вариантах осуществления. Во-первых, за исключением первого сегмента, который содержит ноль образцов воспроизводимого материала, длительность сегмента во временном измерении постоянна, т.е. constant_segment_duration не равен 0.
Во-вторых, если каждый сегмент сохраняется в отдельном файле, то MPD не содержит элементов для каждого файла, т.е. MPD является статическим (не изменяется) в течение сеанса потоковой передачи в реальном времени. Это означает, что constant_num_segments_per_file не равен 0, codec_mime_type_included_for_each_file должен быть равен 0, constant_segment_duration не должен быть равен 0, и byte_offset_included равен 0. В этом случае, URL файла, содержащего последний сегмент для каждого альтернативного представления, должен представлять собой конкатенацию префикса URL для альтернативного представления и значения 5 десятичных цифр 99999. Альтернативно, URL файла, содержащего последний сегмент для каждого альтернативного представления, может представлять собой конкатенацию префикса URL для альтернативного представления и особой строки, например "last_segment". Согласно варианту осуществления, если файл содержит более одного сегмента, то num_segments_aligned задается равным true.
В одном варианте осуществления потоковой передачи в реальном времени, запуск имеет следующие этапы. Во-первых, клиент получает URL MPD. Во-вторых, клиент получает MPD с использованием запроса HTTP GET. При использовании подхода 2 к хранению, клиент получает файл, содержащий "гигантскую" ячейку 'moov' и, если MPD не включено, MPD.
В-третьих, клиент анализирует MPD и выбирает одно или более надлежащих альтернативных представлений (по одному для каждого типа воспроизводимого материала), содержащие все типы воспроизводимого материала, необходимые клиенту. При использовании подхода 2 к хранению, клиент может анализировать файл, содержащий "гигантскую" ячейку 'moov' и использовать содержащуюся в ней информацию, помимо или включая MPD, при выборе надлежащих альтернативных представлений.
В-четвертых, клиент запрашивает первый сегмент для каждого из выбранных альтернативных представлений, и затем запрашивает последний сегмент для каждого выбранного альтернативного представления. При использовании подхода 2 к хранению, клиент непосредственно запрашивает последний сегмент для каждого выбранного альтернативного представления.
В-пятых, если каждый сегмент сохраняется в отдельном файле (т.е. constant_num_segments_per_file равно 1), клиент периодически проверяет наличие следующего файла, соответствующего следующему значению индекса файла, и при наличии файла, клиент запрашивает следующий файл с использованием запроса HTTP GET без байтового диапазона. В этом случае, если следующий файл не содержит ячейки 'moof' (например, файл пуст), то клиент приходит к заключению, что сеанс потоковой передачи в реальном времени завершен. В противном случае (в файле может храниться более одного сегмента), клиент периодически запрашивает обновленную часть MPD, используя запрос HTTP GET с байтовым диапазоном без концевого ограничения, начиная с последнего из ранее запрошенных байтов, после чего запрашивает следующий доступный сегмент. В этом случае, если следующий сегмент пуст (т.е. не содержит образцов воспроизводимого материала), клиент приходит к заключению, что сеанс потоковой передачи в реальном времени завершен. Клиент может использовать отдельную линию связи TCP для запрашивания MPD, одновременно используя другую линию связи TCP для запрашивания сегментов. Период для периодической проверки наличия следующего файла или следующего сегмента должен быть меньшим, но близким к длительности сегмента или равным длительности сегмента.
Согласно варианту осуществления, для выполнения паузы или остановки, клиент просто перестает запрашивать данные путем отправки запросов HTTP GET. Для выполнения возобновления, клиент отправляет запрос HTTP GET для запрашивания последнего сегмента для каждого выбранного альтернативного представления, и затем осуществляет вышеописанный пятый этап.
Согласно варианту осуществления, для поиска конкретной позиции в направлении назад, клиент отправляет запросы HTTP GET для запрашивания сегментов текущих альтернативных представлений, начиная с сегмента, начинающегося с конкретной позиции. В некоторых вариантах осуществления, поиск нацелен на конкретные позиции, где начинается сегмент. Если клиент буферизовал данные после этой конкретной позиции, он может воспроизводить данные буфера после этой конкретной позиции.
В одном варианте осуществления, перемотка назад для потоковой передачи в реальном времени такая же, как для потоковой передачи по требованию.
Согласно варианту осуществления потоковой передачи в реальном времени, для осуществления адаптации потоковой передачи путем переключения с одного альтернативного представления A на другое альтернативное представление B, осуществляются следующие этапы.
Во-первых, клиент перестает запрашивать данные текущих альтернативных представлений. Во-вторых, если клиент ни разу не принял ни одного сегмента B, то клиент сначала запрашивает первый сегмент B, и затем запрашивает последний сегмент B. Одновременно клиент должен сохранять первый сегмент B для использования в будущем при переключении обратно на B из любого другого альтернативного представления. Если клиент принял и сохранил первый сегмент B, то запрашивание первого сегмента пропускается. При использовании подхода 2 к хранению, клиент просто запрашивает последний сегмент B.
В-третьих, если каждый сегмент сохраняется в отдельном файле (т.е. constant_num_segments_per_file равно 1), клиент периодически проверяет наличие следующего файла, соответствующего следующему значению индекса файла, и при наличии файла, клиент запрашивает следующий файл с использованием запроса HTTP GET без байтового диапазона. В этом случае, если следующий файл не содержит ячейки 'moof' (например, файл пуст), то клиент приходит к заключению, что сеанс потоковой передачи в реальном времени завершен. В противном случае (в файле может храниться более одного сегмента), клиент периодически запрашивает обновленную часть MPD, используя запрос HTTP GET с байтовым диапазоном без концевого ограничения, начиная с последнего из ранее запрошенных байтов, после чего запрашивает следующий доступный сегмент. В этом случае, если следующий сегмент пуст (т.е. не содержит образцов воспроизводимого материала), клиент приходит к заключению, что сеанс потоковой передачи в реальном времени завершен. Клиент может использовать отдельную линию связи TCP для запрашивания MPD, одновременно используя другую линию связи TCP для запрашивания сегментов. Период для периодической проверки наличия следующего файла или следующего сегмента должен быть меньшим, но близким к длительности сегмента или равным длительности сегмента.
Согласно варианту осуществления, в MPD могут быть включены байтовый диапазон и временной диапазон сегмента воспроизводимого материала, что позволяет клиентам эффективно запрашивать сегменты воспроизводимого материала с использованием только байтовых диапазонов.
В дополнительном варианте осуществления, для альтернативного представления воспроизводимого материала для поддержки контентов воспроизводимого материала, кодированных согласно более чем одной конфигурации кодирования. Согласно варианту осуществления, максимальная длина всех сегментов может быть включена в MPD для обеспечения возможности использования байтового диапазона без сигнализации байтовых диапазонов в MPD и значительного сокращения размера MPD, что позволяет уменьшить задержку запуска для процесса потоковой передачи.
В дополнительном варианте осуществления, Для указания окончания сеанса потоковой передачи в реальном времени, сервер может составить следующий ожидаемый файл или сегмент аномальным образом, например, создать пустой файл или сегмент. Согласно варианту осуществления, чтобы обеспечить переход к сеансу потоковой передачи в реальном времени и начать запрашивать самый последний контент, для файла, содержащего самый последний сегмент, имеющийся на сервере потоковой передачи, используется особое имя файла и, следовательно, особый URL. Согласно варианту осуществления, чтобы клиент мог понять, с какого файла начинать, когда он желает найти конкретную временную позицию, в то время как длительность сегмента постоянна, и ни для какого сегмента в MPD не сигнализируются байтовые смещения и временные смещения, URL файла формируется, чтобы иметь возможность указывать время начала воспроизведения файла. В одном варианте осуществления, предусмотрены эффективные процессы потоковой передачи, которые обеспечивают нормальные процессы потоковой передачи, такие как запуск, пауза, возобновление и остановка, а также процессы поиска, перемотки вперед, перемотки назад и адаптации потока.
Хотя настоящие варианты осуществления и их преимущества были подробно описаны, следует понимать, что изобретение допускает различные изменения, замены и альтернативы, не выходящие за рамки его сущности и объема, заданные нижеследующей формулой изобретения. Например, многие из рассмотренных выше признаков и функций можно реализовать в программном обеспечении, аппаратном обеспечении или программно-аппаратном обеспечении, или в их комбинации.
Кроме того, объем настоящей заявки не подлежит ограничению конкретными вариантами осуществления процесса, машины, производства, состава материала, средств, способов и этапов, описанных в описании изобретения. Как очевидно специалисту в данной области техники из раскрытия настоящего изобретения, процессы, машины, производство, состав материала, средства, способы или этапы, которые существуют в настоящее время или будут разработаны в дальнейшем, которые осуществляют, по существу, ту же функцию или приводят к, по существу, такому же результату, что и соответствующие описанные здесь варианты осуществления, можно использовать согласно настоящему изобретению. Соответственно, нижеследующая формула изобретения призвана включать в свой объем такие процессы, машины, производство, состав материала, средства, способы или этапы.