ПЕРЕДАЧА ДЛИНЫ ЭЛЕМЕНТА КАДРА ПРИ КОДИРОВАНИИ АУДИО Российский патент 2015 года по МПК G10L19/00 H03M7/30 

Изобретение относится к кодированию аудио, например, так называемому USAC кодеку (USAC = объединенное кодирование речи и аудио), и, в частности, к передаче длины элемента кадра.

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

Одним примером таких кодеков аудио является USAC кодек, как определено в ISO/IEC CD 23003-3. Этот стандарт, названный "Information technology - MPEG audio technologies - Part 3: Unified speech and audio coding", описывает подробно функциональные блоки опорной модели вызова для предложений по объединенному кодированию речи и аудио.

Фиг. 5a и 5b иллюстрируют блок-схемы декодера и кодера. Ниже кратко объяснены общие функциональные возможности отдельных блоков. Затем, проблемы при объединении всех получающихся частей синтаксиса в поток битов объяснены со ссылками на фиг. 6.

Фиг. 5a и 5b иллюстрируют блок-схемы кодера и декодера. Блок-схемы кодера и декодера USAC отражают структуру кодирования USAC MPEG-D. Общая структура может быть описана, подобно следующей: сначала имеется общая предварительная/пост-обработка, состоящая из функционального блока MPEG Surround (MPEGS) для управления стерео или многоканальной обработкой, и блок расширенного SBR (eSBR), который обрабатывает параметрическое представление аудио более высоких частот во входном сигнале. Затем имеются две ветви, одна, состоящая из тракта модифицированного инструмента усовершенствованного кодирования аудио (AAC), и другая, состоящая из тракта, основанного на кодировании с линейным предсказанием (область LP или LPC), что, в свою очередь, означает или представление в частотной области или представление во временной области остатка LPC. Все переданные спектры и для AAC и для LPC представлены в области MDCT после квантования и арифметического кодирования. Представление во временной области использует схему кодирования с ACELP возбуждением.

Базовая структура USAC MPEG-D показана на фиг. 5a и 5b. Поток данных в этой диаграмме направлен слева направо, сверху вниз. Функции декодера заключаются в том, чтобы найти описание квантованных спектров аудио или представления во временной области в полезных данных потока битов и декодировать квантованные значения и другую информацию реконструкции.

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

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

Для каждого из необязательных инструментов, которые оперирует над данными сигнала, опция "пройти через" («выполнить посредством») сохраняется, и во всех случаях, где обработка пропускается, спектры или выборки времени при их вводе передают непосредственно через этот инструмент без модификации.

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

Обработка eSBR и MPEGS применяется одинаковым образом к обоим трактам кодирования после обработки перехода.

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

Выходными из инструмента демультиплексора полезных данных потока битов являются:

* В зависимости от типа базового кодирования в текущем кадре любые из:

- квантованных и свободных от шумов кодированных спектров, представленных посредством

- информации коэффициента масштабирования;

- арифметически кодированных спектральных линий

* или: параметров линейного предсказания (LP) вместе с сигналом возбуждения, представленным также любым из:

- квантованных и арифметически кодированных спектральных линий (возбуждение с кодированным преобразованием, TCX), или

- ACELP-кодированного возбуждения временной области

* Информация заполнения спектральным шумом (опционально)

* Информация решения M/S (опционально)

* Информация формирования временного шума (TNS) (опционально)

* Информация управления банком фильтров

* Информация управления обращенной деформацией шкалы времени (TW) (опционально)

* Информация управления расширенным спектральным ответом полосы пропускания (eSBR) (опционально)

* Информация управления MPEG Surround (MPEGS) (опционально)

Инструмент свободного от шумов декодирования коэффициента масштабирования принимает информацию от демультиплексора полезных данных потока битов, синтаксически анализирует эту информацию, и декодирует кодированные по Хаффману и DPCM коэффициенты масштабирования.

Входными данными для инструмента свободного от шумов декодирования коэффициента масштабирования являются:

* Информация коэффициента масштабирования для свободных от шумов кодированных спектров

Выходными данными для инструмента свободного от шумов декодирования коэффициента масштабирования являются:

* Декодированное целочисленное представление коэффициентов масштабирования:

Инструмент спектрального свободного от шумов декодирования принимает информацию от демультиплексора полезных данных потока битов, синтаксически анализирует эту информацию, декодирует арифметически кодированные данные, и восстанавливает квантованные спектры. Входными данными для этого инструмента свободного от шумов декодирования являются:

* Свободные от шумов кодированные спектры

Выходными данными для этого инструмента свободного от шумов декодирования являются:

* Квантованные значения спектров

Инструмент обратного квантователя принимает квантованные значения для спектров, и преобразует целочисленные значения в немасштабированные восстановленные спектры. Этот квантователь является квантователем компандирования, чей коэффициент компандирования зависит от выбранного основного режима кодирования.

Выходными данными для инструмента обратного квантователя являются:

* Квантованные значения для спектров

Выходными данными для инструмента обратного квантователя являются:

* Немасштабированные обратно квантованные спектры.

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

Входными данными для инструмента заполнения шумом являются:

* Немасштабированные обратно квантованные спектры

* параметры заполнения шумом

* Декодированное целочисленное представление коэффициентов масштабирования

Выходными данными для инструмента заполнения шума являются:

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

* Модифицированное целочисленное представление коэффициентов масштабирования

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

Входными данными для коэффициентов масштабирования являются:

* Декодированное целочисленное представление коэффициентов масштабирования

* Немасштабированные обратно квантованные спектры

Выходными данными от коэффициентов масштабирования являются:

* Масштабированные обратно квантованные спектры.

Для краткого обзора по инструменту M/S см. ISO/IEC 14496-3:2009, 4.1.1.2.

Для краткого обзора по инструменту временного формирования шума (TNS), см. ISO/IEC 14496-3:2009, 4.1.1.2.

Инструмент переключения блока/банка фильтров применяет инверсию отображения частоты, которое было выполнено в кодере. Обратное модифицированное дискретное косинусное преобразование (IMDCT) используется для инструмента банка фильтров. IMDCT может быть сконфигурировано, чтобы поддерживать 120, 128, 240, 256, 480, 512, 960 или 1024 спектральных коэффициентов.

Входными данными для инструмента банка фильтров являются:

* (Обратно квантованные) спектры

* Информация управления банком фильтров

Выходными данными для инструмента банка фильтров являются:

* Аудио сигнал(ы), восстановленные во временной области.

Инструмент переключения банка/блока фильтров с деформированной шкалой времени заменяет нормальный инструмент переключения банка/блока фильтров, когда режим деформации шкалы времени разрешен. Банк фильтров является тем же самым (IMDCT), что и для нормального банка фильтров, дополнительно вырезанные в виде окна выборки временной области отображаются из области деформированной шкалы времени в область с линейной шкалой временем посредством повторной дискретизации с изменением шкалы времени.

Входными данными для инструментов банка фильтров с деформированной шкалой времени являются:

* Обратно квантованные спектры

* Информация управления банком фильтров

* Информация управления деформированной шкалой времени

Выходом(ами) инструмента банка фильтров является:

* восстановленный аудио сигнал(ы) области с линейной шкалой времени

Инструмент расширенного SBR (eSBR) восстанавливает диапазон высоких частот аудио сигнала. Он основан на репликации последовательностей гармоник, усеченных во время кодирования. Он регулирует спектральную огибающую генерированного диапазона высоких частот и применяет обратное фильтрование, и добавляет шум и синусоидальные компоненты, чтобы заново создать спектральные характеристики первоначального сигнала.

Входными данными для инструмента eSBR являются:

* Квантованные данные огибающей

* смешанные данные управления

* сигнал временной области от базового декодера частотной области или базового декодера ACELP/TCX

Выходными данными для инструмента eSBR являются любое из:

* сигнала временной области или

* представления сигнала в QMF-области, например, используется в инструменте MPEG Surround.

Инструмент MPEG Surround (MPEGS) формирует множественные сигналы из одного или более сигналов ввода, применяя сложную процедуру смешения с увеличением числа каналов к сигналу(ам) ввода, которым управляют соответствующие пространственные параметры. В контексте USAC MPEGS используется для того, чтобы кодировать многоканальный сигнал посредством передачи параметрической побочной информации вместе с переданным смешанным с пониженным числом каналов сигналом.

Входными данными для инструмента MPEGS являются:

* сигнал временной области с пониженным числом каналов, или

* представление в QMF-области сигнала с пониженным числом каналов из инструмента eSBR

Выходными данными для инструмента MPEGS являются:

* многоканальный сигнал временной области

Инструмент Классификатор Сигнала анализирует первоначальный сигнал ввода и генерирует из него информацию управления, которая инициирует выбор различных режимов кодирования. Анализ сигнала ввода является зависимым от реализации и пытается выбрать оптимальный базовый режим кодирования для заданного кадра сигнала ввода. Выходные данные классификатора сигнала могут (необязательно) также использоваться, чтобы влиять на поведение других инструментов, например MPEG Surround, расширенного SBR, банка фильтров с деформацией временной шкалы и других.

Входными данными для инструмента Классификатора сигнала являются:

* первоначальный немодифицированный сигнал ввода

* дополнительные параметры, зависимые от реализации

Выходными данными для инструмента Классификатора сигнала являются:

* управляющий сигнал, чтобы управлять выбором базового кодера-декодера (не-LP фильтрованное кодирование в частотной области, LP фильтрованная частотная область или LP фильтрованное кодирование во временной области).

Инструмент ACELP обеспечивает способ, чтобы эффективно представить сигнал возбуждения во временной области посредством комбинирования долгосрочного предсказателя (адаптивное кодовое слово) с импульсно-подобной последовательностью (обновленное кодовое слово). Восстановленное возбуждение посылают через фильтр LP-синтеза, чтобы сформировать сигнал временной области.

Входными данными для инструмента ACELP являются:

* индексы адаптивной и обновленной кодовой книги

* значения адаптивного и обновленного коэффициентов усиления кодов

* другие данные управления

* обратно квантованные и интерполированные коэффициенты LPC фильтра

Выходными данными для инструмента ACELP являются:

* восстановленный аудио сигнал временной области

Инструмент основанного на MDCT средства декодирования TCX используется, чтобы вернуть взвешенное представление остатка LP из MDCT-области назад в сигнал временной области и выводит сигнал временной области, включающий в себя взвешенную фильтрацию LP-синтеза. IMDCT может быть сконфигурирован, чтобы поддерживать 256, 512, или 1024 спектральных коэффициентов.

Входными данными для инструмента TCX являются:

* (Обратно квантованные) спектры MDCT

* обратно квантованные и интерполированные коэффициенты LPC фильтра

Выходными данными для инструмента TCX являются:

* восстановленный аудио сигнал временной области

Технология, раскрытая в ISO/IEC CD 23003-3, который включен здесь по ссылке, обеспечивает определение канальных элементов, которые являются, например, элементами единственного канала, содержащими полезные данные только для единственного канала, или элементами пары каналов, содержащими полезные данные для двух каналов, или канальными элементами LFE (низкочастотное расширение), содержащими полезные данные для канала LFE.

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

Фиг. 6 показывает более общий пример кодера и декодера, соответственно, оба изображенные в одном общем виде, где кодер кодирует аудио содержимое 10 в поток 12 битов, с декодером, декодирующим аудио содержимое или по меньшей мере его часть, из потока 12 битов. Результат декодирования, то есть реконструкция, указана как 14. Как иллюстрировано на Фиг. 6, аудио содержимое 10 может быть составлено из многих аудио сигналов 16. Например, аудио содержимое 10 может быть пространственной аудио сценой, составленной из ряда аудио каналов 16. Альтернативно, аудио содержимое 10 может представить конгломерат аудио сигналов 16 с аудио сигналами 16, представляющими, отдельно и/или в группах, отдельные аудио объекты, которые могут быть соединены в аудио сцену на усмотрение пользователя декодера, чтобы получить реконструкцию 14 аудио содержимого 10 в форме, например, пространственной аудио сцены для конкретной конфигурации громкоговорителей. Кодер кодирует аудио содержимое 10 в блоках последовательных периодов времени. Такой период времени в качестве примера показан как 18 на Фиг. 6. Кодер кодирует последовательные периоды 18 аудио содержимого 10, используя один и тот же способ: то есть, кодер вставляет в поток 12 битов один кадров 20 за период 18 времени. При этом кодер разлагает аудио содержимое в пределах соответствующего периода 18 времени в элементы кадра, количество и значение/тип которого являются одинаковыми для каждого периода 18 времени и кадра 20, соответственно. Относительно кодека USAC, описанного в общих чертах выше, например, кодер кодирует одну и ту же пару аудио сигналов 16 в каждом периоде 18 времени в элемент пары каналов элементов 22 кадров 20, используя другой принцип кодирования, такой как кодирование единственного канала для другого аудио сигнала 16, чтобы получить единственный элемент 22 канала и т.д. Параметрическая побочная информация для получения аудио сигналов повышающего микширования из аудио сигнала понижающего микширования как определено одним или более элементами 22 кадра, собирается, чтобы сформировать другой элемент кадра в пределах кадра 20. В этом случае элемент кадра, передающий эту побочную информацию, ссылается на, или формирует некоторый вид данных расширения для других элементов кадра. Естественно, такие расширения не ограничены многоканальной или многообъектной побочной информацией.

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

Кроме того, чтобы обеспечить пропуск элементов кадра, которые должны быть пропущены, поток 12 битов должен передать вышеупомянутую информацию длины относительно элементов кадра, потенциально подлежащие пропуску. Эта передача, в свою очередь, уменьшает эффективность сжатия.

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

Кроме того, было бы выгодно, если передача информации длины могла бы быть выполнена более эффективно.

Соответственно, есть потребность в другой концепции потока битов, кодера и декодера, соответственно.

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

Этот задача решается объектами согласно независимым пунктам формулы изобретения.

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

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

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

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

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

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

Фиг. 1 показывает схематическую блок-схему кодера и его вход и выход в соответствии с вариантом осуществления;

Фиг. 2 показывает схематическую блок-схему декодера и его вход и выход в соответствии с вариантом осуществления;

Фиг. 3 схематично показывает поток битов в соответствии с вариантом осуществления;

Фиг. 4а-z и za-zc показывает таблицы псевдокода, иллюстрирующие конкретный синтаксис потока битов в соответствии с вариантом осуществления; и

Фиг. 5a и b показывает блок-схему кодера USAC и декодера; и

Фиг. 6 показывает типичную пару кодера и декодера.

Фиг. 1 показывает кодер 24 в соответствии с вариантом осуществления. Кодер 24 предназначен для того, чтобы кодировать аудио содержимое 10 в поток 12 битов.

Как описано в вводной части описания настоящей заявки, аудио содержимое 10 может быть конгломератом нескольких аудио сигналов 16. Аудио сигналы 16 представляют, например, отдельные аудио каналы пространственной аудио сцены. Альтернативно, аудио сигналы 16 формируют аудио объекты набора аудио объектов, вместе определяющих аудио сцену для свободного микширования на стороне декодирования. Аудио сигналы 16 определены в общем временном базисе t, как иллюстрировано позицией 26. Таким образом, аудио сигналы 16 могут относиться к одному и тому же временному интервалу и могут, соответственно, быть выровнены по времени друг относительно друга.

Кодер 24 конфигурируется так, чтобы кодировать последовательные периоды 18 времени аудио содержимого 10 в последовательность кадров 20 так, чтобы каждый кадр 20 представлял соответствующий один из периодов 18 времени аудио содержимого 10. Кодер 24 конфигурируется, в некотором смысле, чтобы кодировать каждый период времени одинаково таким образом, чтобы каждый кадр 20 содержал последовательность из количества элементов N из элементов кадра. В пределах каждого кадра 20 справедливо, что каждый элемент 22 кадра имеет соответствующий один из множества типов элемента. В частности, последовательность кадров 20 является композицией из последовательностей N элементов кадра 22, с каждым элементом 22 кадра, имеющим один из соответствующего множества типов элемента таким образом, что каждый кадр 20 содержит один элемент 22 кадра из каждой из N последовательностей элементов 22 кадра, соответственно, и для каждой последовательности элементов 22 кадра элементы 22 кадра имеют равный тип элемента друг относительно друга. В вариантах осуществления, описанных ниже, N элементов кадра в пределах каждого кадра 20 скомпонованы в потоке 12 битов таким образом, что элементы кадра 22, помещенные в некоторую позицию элемента, имеют тот же самый или равный тип элемента и формируют одну из N последовательностей элементов кадра, иногда называемых подпотоками в нижеследующем описании. Таким образом, первые элементы 22 кадра в кадрах 20 имеют один и тот же тип элемента и формируют первую последовательность (или подпоток) элементов кадра, вторые элементы 22 кадра из всех кадров 20 имеют тип элемента, равный друг другу, и формируют вторую последовательность элементов кадра, и т.д. Однако, следует подчеркнуть, что этот аспект следующих вариантов осуществления является просто дополнительным, и все из далее описанных в общих чертах вариантов осуществления могут быть модифицированы в этом отношении: например, вместо того, чтобы сохранять порядок среди элементов кадра N подпотоков в пределах каждого кадра 20 постоянным с передачей информации относительно типов элемента подпотоков в блоке конфигурации, все ниже поясненные варианты осуществления могут быть пересмотрены в том, чтобы соответствующий тип элемента из элементов кадра содержался в пределах самого синтаксиса элемента кадра, так чтобы порядок среди подпотоков в пределах каждого кадра 20 мог изменяться между различными кадрами. Естественно, такая модификация может иметь место за счет отказа от преимущества относительно эффективности передачи, как далее объяснено ниже. Еще в качестве альтернативы, порядок может быть фиксированным, но так или иначе заранее определенным в соответствии с соглашением, так чтобы никакая индикация в пределах блока конфигурации не была бы необходима.

Как описано в общих чертах более подробно ниже, подпотоки, переданные последовательностью кадров 20, передают информацию, которая позволяет декодеру восстановить аудио содержимое. В то время как некоторые из подпотоков могут быть обязательными, другие являются так или иначе опциональными и могут быть пропущены некоторыми из декодеров. Например, некоторые из подпотоков могут представить побочную информацию относительно других подпотоков и могут, например, быть необязательными. Это объяснено более подробно ниже. Однако, чтобы позволить декодерам пропустить некоторые из элементов кадра или, более точно, элементы кадра по меньшей мере одной из последовательностей элементов кадра, то есть, одного из подпотоков, кодер 24 конфигурируется, чтобы записать блок 28 конфигурации в поток 12 битов, который содержит информацию длины полезных данных по умолчанию в отношении длины полезных данных по умолчанию. Далее, кодер записывает для каждого элемента 22 кадра этого по меньшей мере одного подпотока информацию длины в поток 12 битов, содержащую, для по меньшей мере поднабора элементов 22 кадра этого по меньшей мере одного подпотока, флаг длины полезных данных по умолчанию, с последующим, если флаг длины полезных данных по умолчанию не установлен, значением длины полезных данных. Любой элемент кадра этой по меньшей мере одной из последовательностей элементов 22 кадра, флаг длины расширенных полезных данных по умолчанию которой установлен, имеет длину полезных данных по умолчанию, и любой элемент кадра этой по меньшей мере одной из последовательностей элементов 22 кадра, флаг 64 длины полезных данных расширения по умолчанию которой не установлен, имеет длину полезных данных, соответствующую значению длины полезных данных. С помощью этой меры явной передачи длины полезных данных для каждого элемента кадра пропускаемого подпотока можно избежать. Вместо этого, в зависимости от типа полезных данных, переданного такими элементами кадра, статистика длины полезных данных может быть такой, что эффективность передачи значительно увеличивается, при обращении к длине полезных данных по умолчанию, вместо того, чтобы явно передавать длину полезных данных для каждого элемента кадра снова и снова.

Таким образом, вместо общего описания потока битов, ниже то, что упомянуто выше, описано более подробно со ссылками на более конкретные варианты осуществления. Как упомянуто выше, в этих вариантах осуществления постоянный, но настраиваемый порядок среди подпотоков в последовательных кадрах 20 просто представляет необязательный признак и может быть изменен в этих вариантах осуществления.

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

a) элементы кадра типа элемента единственного канала, например, могут генерироваться кодером 24, чтобы представить один единственный аудио сигнал. Соответственно, последовательность элементов 22 кадра в некоторой позиции элемента в пределах кадров 20, например, i^-й элемент в кадрах с 0>i>N+1, которые, следовательно, формируют i^-й подпоток элементов кадра, вместе могут представлять последовательные периоды 18 времени такого единственного аудио сигнала. Аудио сигнал, представленный таким образом, может непосредственно соответствовать любому одному из аудио сигналов 16 аудио содержимого 10. Альтернативно, однако, и как описано более подробно ниже, такой представленный аудио сигнал может быть одним каналом из сигнала понижающего микширования, который, наряду с данными полезных данных элементов кадра другого типа элемента кадра, позиционированного в другой позиции элемента в пределах кадров 20, дает количество аудио сигналов 16 аудио содержимого 10, которое выше, чем количество каналов упомянутого выше сигнала понижающего микширования. В случае варианта осуществления, описанного более подробно ниже, элементы кадра такого типа элемента единственного канала обозначены UsacSingleChannelElement. В случае MPEG Surround и SAOC, например, имеется только единственный сигнал понижающего микширования, который может быть моно, стерео, или даже многоканальным в случае MPEG Surround. В последнем случае такой, например, сигнал 5.1 понижающего микширования, состоит из двух элементов пары каналов и одного элемента единственного канала. В этом случае элемент единственного канала, так же как два элемента пары каналов, является только частью сигнала понижающего микширования. В случае понижающего микширования стерео будет использоваться элемент пары каналов.

b) Элементы кадра типа элемента пары каналов могут быть сгенерированы кодером 24, чтобы представить стерео пару аудио сигналов. Таким образом, элементы 22 кадра этого типа, которые позиционированы в общую позицию элемента в пределах кадров 20, вместе могут формировать соответствующий подпоток элементов кадра, которые представляют последовательные периоды 18 времени такой стерео аудио пары. Эта стерео пара аудио сигналов, представленных таким образом, может быть непосредственно любой парой аудио сигналов 16 аудио содержимого 10, или может представлять, например, сигнал понижающего микширования, который наряду с данными полезных данных элементов кадра другого типа элемента, которые позиционированы в другую позицию элемента, приводят к количеству аудио сигналов 16 аудио содержимого 10, которое выше, чем 2. В варианте осуществления, описанном более подробно ниже, элементы кадра такого типа элемента пары каналов обозначены как UsacChannelPairElement.

c) Чтобы передать информацию относительно аудио сигналов 16 аудио содержимого 10, которые нуждаются в меньшей полосе частот, например, каналы сабвуфера или подобные, кодер 24 может поддерживать элементы кадра конкретного типа с элементами кадра такого типа, которые позиционированы в общую позицию элемента, представляющую, например, последовательные периоды 18 времени единственного аудио сигнала. Этот аудио сигнал может быть любым одним из аудио сигналов 16 аудио содержимого 10 непосредственно, или может быть частью сигнала понижающего микширования, как описано выше в отношении единственного типа элемента канала и типа элемента пары каналов. В варианте осуществления, описанном более подробно ниже, элементы кадра такого конкретного типа элемента кадра обозначены UsacLfeElement.

d) Элементы кадра типа элемента расширения могут генерироваться кодером 24, чтобы передать побочную информацию наряду с потоком битов, чтобы разрешить декодеру выполнить повышающее микширование любого из аудио сигналов, представленных элементами кадра любого из типов a, b и/или c, чтобы получить большее количество аудио сигналов. Элементы кадра такого типа элемента расширения, которые позиционированы в некоторую общую позицию элемента в пределах кадров 20, могут соответственно передавать побочную информацию, относящуюся к последовательному периоду 18 времени, которая позволяет выполнить повышающее микширование соответствующего периода времени одного или более аудио сигналов, представленных любым из других элементов кадра, чтобы получить соответствующий период времени более высокого количества аудио сигналов, в котором последние могут соответствовать первоначальным аудио сигналам 16 аудио содержимого 10. Примеры для такой побочной информации могут, например, быть параметрической побочной информацией, такой как, например, MPS или побочная информация SAOC.

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

Как стало ясно из вышеприведенного описания, пропуски элементов 22 кадра этого типа элемента расширения из потока 12 битов или пренебрежение этими элементами кадра при декодировании, не полностью представляет реконструкцию аудио содержимого 10 невозможной: по меньшей мере остающиеся элементы кадра других типов элемента передают достаточно информации, чтобы обеспечить аудио сигналы. Эти аудио сигналы не обязательно соответствуют первоначальным аудио сигналам аудио содержимого 10 или надлежащему их поднабору, но могут представлять своего рода "смесь" аудио содержимого 10. То есть, элементы кадра типа элемента расширения могут передавать информацию (данные полезных данных), которая представляет побочную информацию относительно одного или более элементов кадра, позиционированных в различные позиции элемента в пределах кадров 20.

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

Перед продолжением описания кодера согласно Фиг. 1, однако, нужно отметить, что имеется несколько возможностей для альтернатив для типов элемента, описанных выше. Это особенно верно для типа элемента расширения, описанного выше. В частности, в случае типа элемента расширения, конфигурируемого таким образом, что данные полезных данных пропускаются декодерами, которые, например, не в состоянии обработать соответствующие данные полезных данных, эти данные полезных данных этих элементов кадра типа элемента расширения могут быть любым типом данных полезных данных. Эти данные полезных данных могут формировать побочную информацию относительно данных полезных данных других элементов кадра других типов элемента кадра, или могут формировать самостоятельные данные полезных данных, представляющие другой аудио сигнал, например. Кроме того, даже в случае данных полезных данных элементов кадра типа элемента расширения, представляющих побочную информацию данных полезных данных элементов кадра других типов элемента кадра, эти данные полезных данных этих элементов кадра типа элемента расширения не ограничены только описанным видом, а именно, многоканальной или многообъектной побочной информацией. Полезные данные многоканальной побочной информации сопровождают, например, сигнал понижающего микширования, представленный любым из элементов кадра другого типа элемента, пространственными признаками, такими как параметры кодирования бинаурального сигнала (BCC), например, значения межканальной когерентности (ICC), межканальные разности уровней (ICLD), и/или межканальные разности времени (ICTD) и, необязательно, коэффициенты предсказания канала, причем эти параметры известны в уровне техники из, например, стандарта MPEG Surround. Только упомянутые параметры пространственных признаков могут, например, быть переданы в пределах данных полезных данных элементов кадра типа элемента расширения с время/частотным разрешением, то есть один параметр на каждую ячейку времени/частоты сетки времени/частоты. В случае многообъектной побочной информации эти данные полезных данных элемента кадра типа элемента расширения могут содержать аналогичную информацию, такую как параметры кросс-корреляции между объектами (IOC), разности уровней объекта (OLD), так же как параметры понижающего микширования, показывающие, как первоначальные аудио сигналы были преобразованы понижающим микшированием в канал(ы) сигнала понижающего микширования, представленного любым из элементов кадра другого типа элемента. Последние параметры, например, известны в уровне техники из стандарта SAOC. Однако, примером другой побочной информации, которую могут представлять данные полезных данных элементов кадра типа элемента расширения, являются, например, данные SBR для того, чтобы параметрически кодировать огибающую высокочастотной части аудио сигнала, представленного любым из элементов кадра других типов элемента кадра, позиционированных в различную позицию элемента в пределах кадров 20, и разрешающих, например, репликацию спектрального диапазона с использованием низкочастотной части, которая получена из последнего аудио сигнала, в качестве базиса для высокочастотной части, с последующим формированием огибающей высокочастотной части, таким образом полученной посредством огибающей данных SBR. В более широком смысле, данные полезных данных элементов кадра типа элемента расширения могут передавать побочную информацию для того, чтобы модифицировать аудио сигналы, представленные элементами кадра любого из других типов элемента, позиционированных в различную позицию элемента в пределах кадра 20 или во временной области или в частотной области, причем частотная область может, например, быть областью QMF или некоторой другой областью банка фильтров или областью преобразования.

Возобновляя далее описание функциональных возможностей кодера 24 согласно Фиг. 1, он конфигурируется, чтобы закодировать в поток 12 битов блок 28 конфигурации, который содержит поле, указывающее количество N элементов, и часть синтаксиса индикации типа, указывающую для каждой позиции элемента из последовательности из N позиций элемента, соответствующий типа элемента. Соответственно, кодер 24 конфигурируется, чтобы кодировать, для каждого кадра 20, последовательность из N элементов 22 кадра в поток 12 битов так, чтобы каждый элемент 22 кадра из последовательности из N элементов 22 кадра, который позиционирован в соответствующую позицию элемента в пределах последовательности из N элементов 22 кадра в потоке 12 битов, имел тип элемента, обозначенный частью индикации типа для соответствующей позиции элемента. Другими словами, кодер 24 формирует N подпотоков, каждый из которых является последовательностью элементов 22 кадра соответствующего типа элемента. То есть, для всех этих N подпотоков элементы 22 кадра имеют равный тип элемента, в то время как элементы кадра различных подпотоков могут иметь различный тип элемента. Кодер 24 конфигурируется, чтобы мультиплексировать все эти элементы кадра в поток 12 битов посредством конкатенации всех N элементов кадра этих подпотоков относительно одного общего периода 18 времени, чтобы сформировать один кадр 20. Соответственно, в потоке 12 битов эти элементы 22 кадра размещены в кадрах 20. В пределах каждого кадра 20, представители N подпотоков, то есть N элементов кадра, касающиеся одного и того же периода 18 времени, размещены в статическом последовательном порядке, определенном последовательностью позиций элемента, и частью синтаксиса индикации типа в блоке 28 конфигурации, соответственно.

С помощью использования части синтаксиса индикации типа кодер 24 в состоянии свободно выбрать порядок, используя то, какие элементы 22 кадра из N подпотоков скомпонованы в пределах кадров 20. С помощью этой меры кодер 24 в состоянии удерживать, например, служебные расходы буферизации на стороне декодирования настолько низкими насколько возможно. Например, подпоток элементов кадра типа элемента расширения, который передает побочную информацию для элементов кадра другого подпотока (базового подпотока), которые имеют тип элемента без расширения, может быть позиционирован в позицию элемента в пределах кадров 20 немедленно следующей за позицией элемента, в которой эти элементы кадра базового подпотока расположены в кадрах 20. С помощью этой меры время буферизации, в течение которого сторона декодирования должна буферизовать результаты или промежуточные результаты декодирования базового подпотока для применения побочной информации к нему, сохраняется малым, и служебные расходы буферизации могут быть уменьшены. В случае побочной информации данных полезных данных элементов кадра подпотока, которые имеют тип элемента расширения, применяемый к промежуточному результату, такому как частотная область, аудио сигнала, представленного другим подпотоком элементов 22 кадра (базовым подпотоком), позиционирование подпотока элементов 22 кадра типа элемента расширения так, чтобы он немедленно следовал за базовым подпотоком, не только минимизирует служебные расходы буферизации, но также и продолжительность времени, во время которой декодер может быть вынужден прерывать дальнейшую обработку реконструкции представленного аудио сигнала, так как, например, данные полезных данных элементов кадра типа элемента расширения должны модифицировать реконструкцию аудио сигнала относительно представления базового подпотока. Может, однако, также быть выгодным поместить зависимый подпоток расширения до его базового подпотока, представляющего аудио сигнал, к которому подпоток расширения относится, Например, кодер 24 свободен поместить подпоток полезных данных расширения в потоке битов ранее по отношению к подпотоку типа элемента канала. Например, полезные данные расширения подпотока i могут передавать данные управления динамическим диапазоном (DRC) и быть переданы до или во время более ранней позиции i элемента, относительно кодирования соответствующего аудио сигнала, например, с помощью кодирования в частотной области (FD), в пределах подпотока канала в позиции i+1 элемента, например. Затем, декодер в состоянии использовать DRC немедленно при декодировании и восстановлении аудио сигнала, представленного подпотоком i+1 типа без расширения.

Кодер 24, как описано выше, представляет возможный вариант осуществления настоящей заявки. Однако, Фиг. 1 также показывает возможную внутреннюю структуру кодера, которая должна быть понята просто как иллюстрация. Как показано на Фиг. 1, кодер 24 может содержать модуль 30 распределения и преобразователь 32 в последовательную форму, между которым различные модули 34a-e кодирования соединены способом, описанным более подробно ниже. В частности, модуль 30 распределения конфигурируется, чтобы принимать аудио сигналы 16 аудио содержимого 10 и распределять их на отдельные модули 34a-e кодирования. Этот способ, которым модуль 30 распределения распределяет последовательные периоды 18 времени аудио сигнала 16 на модули 34a-34e кодирования, является статическим. В частности, распределение может быть таким, что каждый аудио сигнал 16 направляется исключительно к одному из модулей 34a-34e кодирования. Аудио сигнал, подаваемый к кодеру LFE 34a, кодируется кодером LFE 34a в подпоток элементов 22 кадра типа c (см. выше), например. Аудио сигнал, подаваемый на вход кодера 34b единственного канала, кодируются с помощью последнего в подпоток элементов 22 кадра типа а (см. выше), например. Точно так же, пара аудио сигналов, подаваемых к входу кодера 34c пары каналов, кодируется с помощью последнего в подпоток элементов 22 кадра типа d (см. выше), например. Вышеуказанные модули 34a-34c кодирования соединены своим входом и выходом между модулем 30 распределения с одной стороны и преобразователем 32 в последовательную форму с другой стороны.

Как показано на Фиг. 1, однако, входы модулей 34b и 34c кодера не только соединены с интерфейсом вывода модуля 30 распределения. Вместо этого, на них могут быть поданы сигналы вывода любого из модулей 34d и 34e кодирования. Эти последние модули 34d и 34e кодирования являются примерами модулей кодирования, которые конфигурируются, чтобы кодировать ряд входящих аудио сигналов в сигнал понижающего микширования с меньшим количеством каналов понижающего микширования с одной стороны, и подпоток элементов 22 кадра типа d (см. выше), с другой стороны. Как стало ясно из вышеупомянутого описания, модуль 34d кодирования может быть кодером SAOC, и модуль 34e кодирования может быть кодером MPS. Сигналы понижающего микширования направляют любому из модулей 34b и 34c кодирования. Подпотоки, генерируемые модулями 34a-34e кодирования, направляют преобразователю 32 в последовательную форму, который преобразует эти подпотоки в последовательную форму в поток 12 битов, как описано выше. Соответственно, модули 34d и 34e кодирования имеют свой вход для количества аудио сигналов, соединенных с интерфейсом вывода модуля 30 распределения, в то время как их выход подпотока соединен с интерфейсом ввода преобразователя 32 в последовательную форму, и их выход понижающего микширования соединен с входами модулей 34b и/или 34c кодирования, соответственно.

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

После описания кодера 24 и его возможной внутренней структуры, соответствующий декодер описан со ссылками на фиг. 2. Декодер согласно Фиг. 2 в целом указан ссылочной позицией 36 и имеет вход, чтобы принимать поток 12 битов, и выход для того, чтобы выводить восстановленную версию 38 аудио содержимого 10 или их смесь. Соответственно, декодер 36 конфигурируется, чтобы декодировать поток 12 битов, содержащий блок 28 конфигурации и последовательность кадров 20, показанную на Фиг. 1, и декодировать каждый кадр 20, декодируя элементы 22 кадра в соответствии с типом элемента, указанным частью индикации типа, для соответствующей позиции элемента, в которой соответствующий элемент 22 кадра позиционирован в последовательности из N элементов 22 кадра соответствующего кадра 20 в потоке 12 битов. То есть, декодер 36 конфигурируется, чтобы назначить каждый элемент 22 кадра на один из возможных типов элемента в зависимости от его позиции элемента в пределах текущего кадра 20, а не любой информации в пределах самого элемента кадра. С помощью этой меры декодер 36 получает N подпотоков, где первый подпоток составлен из первых элементов 22 кадра кадров 20, второй подпоток составлен из вторых элементов 22 кадра в кадрах 20, третий подпоток составлен из третьих элементов 22 кадра в кадрах 20 и т.д.

Прежде, чем описать функциональные возможности декодера 36 относительно элементов кадра типа элемента расширения более подробно, возможная внутренняя структура декодера 36 согласно фиг. 2 объяснена более подробно так, чтобы соответствовать внутренней структуре кодера 24 согласно фиг. 1. Как описано относительно кодера 24, эта внутренняя структура должна быть понята просто как являющаяся иллюстративной.

В частности, как показано на Фиг. 2, декодер 36 может внутри себя содержать модуль 40 распределения и компоновщик 42, между которыми модули 44a-44e декодирования соединены. Каждый модуль 44a-44e декодирования ответственен за декодирование подпотока элементов 22 кадра некоторого типа элемента кадра. Соответственно, модуль 40 распределения конфигурируется, чтобы распределять N подпотоков потока 12 битов на модули 44a-44e декодирования, соответственно. Модуль 44a декодирования, например, является декодером LFE, который декодирует подпоток элементов 22 кадра типа c (см. выше) так, чтобы получить узкополосный (например) аудио сигнал на его выходе. Аналогично, декодер 44b единственного канала декодирует входящий подпоток элементов 22 кадра типа a (см. выше) так, чтобы получить единственный аудио сигнал на его выходе, и декодер 44c пары каналов декодирует входящий подпоток элементов 22 кадра типа b (см. выше) так, чтобы получить пару аудио сигналов на его выходе. Модули 44a к 44c декодирования имеют свои вход и выход соединенными между интерфейсом вывода модуля 40 распределения с одной стороны, и интерфейсом ввода компоновщика 42, с другой стороны.

Декодер 36 может просто иметь модули 44a-44c декодирования. Другие модули 44e и 44d декодирования являются ответственными за элементы кадра типа элемента расширения и являются, соответственно, дополнительными, насколько требуется соответствие с аудио кодеком. Если оба или любой из этих модулей 44e-44d расширения отсутствуют, модуль 40 распределения конфигурируется пропускать соответствующие подпотоки элемента кадра расширения в потоке 12 битов, как описано более подробно ниже, и восстановленная версия 38 аудио содержимого 10 является просто смесью первоначальной версии, имеющей аудио сигналы 16.

Если присутствуют, однако, то есть, если декодер 36 поддерживает элементы кадра расширения SAOC и/или MPS, многоканальный декодер 44e может быть сконфигурирован, чтобы декодировать подпотоки, генерируемые кодером 34e, в то время как многообъектный декодер 44d является ответственным за декодирование подпотоков, генерируемых многообъектным кодером 34d. Соответственно, в случае, если модули 44e и/или 44d декодирования присутствуют, коммутатор 46 может соединить выход любого из модулей 44c и 44b декодирования с входом сигнала понижающего микширования модуля 44e и/или 44d декодирования. Многоканальный декодер 44e может быть сконфигурирован, чтобы выполнять повышающее микширование поступающего сигнала понижающего микширования, используя побочную информацию в поступающем подпотоке от модуля 40 распределения, чтобы получить увеличенное число аудио сигналов на его выходе. Многообъектный декодер 44d может действовать соответственно с тем отличием, что многообъектный декодер 44d рассматривает отдельные аудио сигналы как аудио объекты, тогда как многоканальный декодер 44e рассматривает аудио сигналы на его выходе как аудио каналы.

Аудио сигналы, восстановленные таким образом, направляют компоновщику 42, который компонует их, чтобы сформировать реконструкцию 38. Компоновщиком 42 может дополнительно управлять пользовательский ввод 48, причем этот пользовательский ввод указывает, например, доступную конфигурацию громкоговорителей или наибольшее количество разрешенных каналов 38 реконструкции. В зависимости от пользовательского ввода 48 компоновщик 42 может запретить любой из модулей 44a-44e декодирования такие как, например, любой из модулей 44d и 44e расширения, в то время как присутствуют и хотя элементы кадра расширения присутствуют в потоке 12 битов.

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

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

Прежде, чем описать далее возможные детали декодера, кодера и потока битов, соответственно, нужно отметить, что, благодаря способности кодера распределять элементы кадра подпотоков, которые имеют тип элемента расширения, между элементами кадра подпотоков, которые не имеют типа элемента расширения, служебные расходы буферизации декодера 36 могут быть снижены кодером 24, подходящим образом выбирая порядок среди подпотоков и порядок среди элементов кадра подпотоков в пределах каждого кадра 20, соответственно. Предположим, например, что подпоток, входящий в декодер 44c пары каналов, позиционирован в первой позиции элемента в пределах кадра 20, в то время как многоканальный подпоток для декодера 44e позиционирован в конце каждого кадра. В этом случае декодер 36 должен буферизовать промежуточный аудио сигнал, представляющий сигнал понижающего микширования для многоканального декодера 44e, в течение периода времени, соединяющего времена между прибытием первого элемента кадра и последним элементом кадра каждого кадра 20, соответственно. Только затем многоканальный декодер 44e способен начать его обработку. Этой задержки можно избежать кодером 24, компонуя подпоток, назначенный для многоканального декодера 44e, во второй позиции элемента кадров 20, например. С другой стороны, модуль 40 распределения не должен проверять каждый элемент кадра относительно его членства в любом из подпотоков. Вместо этого модуль 40 распределения в состоянии вывести членство текущего элемента 22 кадра из текущего кадра 20 для любого из подпотоков N просто из блока конфигурации и части синтаксиса индикации типа, содержащейся в ней.

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

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

Блок 28 конфигурации содержит, как описано выше, поле 50, указывающее количество N элементов, то есть количество N элементов кадра в пределах каждого кадра 20, и количество подпотоков, мультиплексированных в поток 12 битов, как описано выше. В нижеследующем варианте осуществления, описывающем вариант осуществления для конкретного синтаксиса потока 12 битов, поле 50 обозначено numElements и блок 28 конфигурации назван UsacConfig в следующем конкретном примере синтаксиса согласно Фиг. 4a-z и za-zc. Далее, блок 28 конфигурации содержит часть 52 синтаксиса индикации типа. Как уже описано выше, эта часть 52 указывает для каждой позиции элемента тип элемента из множества типов элемента. Как показано на Фиг. 3 и как имеет место относительно нижеследующего конкретного примера синтаксиса, часть 52 синтаксиса индикации типа может содержать последовательность N элементов 54 синтаксиса, где каждый элемент 54 синтаксиса указывает тип элемента для соответствующей позиции элемента, в которую соответствующий элемент 54 синтаксиса позиционирован в пределах части 52 синтаксиса индикации типа. Другими словами, i^-й элемент 54 синтаксиса в пределах части 52 может указывать тип элемента i-го подпотока и i-й элемент кадра каждого кадра 20, соответственно. В последующем конкретном примере синтаксиса элемент синтаксиса обозначен UsacElementType. Хотя часть 52 синтаксиса индикации типа может содержаться в потоке 12 битов как просто-соединенная или смежная часть потока 12 битов, в качестве примера показано на Фиг. 3, что его элементы 54 перемешаны с другими частями элемента синтаксиса блока 28 конфигурации, которые присутствуют для каждой из N позиций элемента отдельно. В нижеописанных в общих чертах вариантах осуществления эти перемешанные части синтаксиса принадлежат специфичным для подпотока данным 55 конфигурации, значение которых описано ниже более подробно.

Как уже описано выше, каждый кадр 20 составлен из последовательности из N элементов 22 кадра. Типы элемента этих элементов 22 кадра не сигнализируются соответствующими индикаторами типа в пределах элементов 22 кадра непосредственно. Вместо этого типы элемента элементов 22 кадра определяются их позицией элемента в пределах каждого кадра 20. Элемент 22 кадра, появляющийся первым в кадре 20, обозначенный как элемент 22a кадра на Фиг. 3, имеют первую позицию элемента и соответственно тип элемента, который указан для первой позиции элемента частью 52 синтаксиса в блоке 28 конфигурации. То же самое применяется относительно следующих элементов 22 кадра. Например, элемент 22b кадра, имеющий место сразу после первого элемента 22a кадра в потоке 12 битов, то есть, имеющий позицию 2 элемента, имеет тип элемента, обозначенный частью 52 синтаксиса.

В соответствии с конкретным вариантом осуществления элементы 54 синтаксиса размещены в потоке 12 битов в том же самом порядке, как элементы 22 кадра, к которым они относятся. Таким образом, первый элемент 54 синтаксиса, то есть элемент, появляющийся первым в потоке 12 битов и помещенный в наиболее удаленную левую сторону на Фиг. 3, указывает тип элемента первого появляющегося элемента 22a кадра каждого кадра 20, второй элемент 54 синтаксиса указывает тип элемента второго элемента 22b кадра и т.д. Естественно, последовательный порядок или компоновка элементов 54 синтаксиса в потоке 12 битов и частей 52 синтаксиса могут быть переключаемыми относительно последовательного порядка элементов 22 кадра в пределах кадров 20. Другие перестановки также могут быть выполнимы, хотя менее предпочтительны.

Для декодера 36 это означает, что то же самое может быть сконфигурировано, чтобы считать эту последовательность из N элементов 54 синтаксиса из части 52 синтаксиса индикации типа. Чтобы быть более точным, декодер 36 считывает поле 50 так, что декодер 36 знает количество N элементов 54 синтаксиса, которые должны быть считаны из потока 12 битов. Как упомянуто выше, декодер 36 может быть сконфигурирован, чтобы ассоциировать элементы синтаксиса и тип элемента, обозначенный таким образом, с элементами 22 кадра в пределах кадров 20 так, чтобы i-й элемент 54 синтаксиса был ассоциирован с i-м элементом 22 кадра.

В дополнение к вышеупомянутому описанию, блок 28 конфигурации может содержать последовательность 55 из N элементов 56 конфигурации с каждым элементом 56 конфигурации, содержащим информацию конфигурации для типа элемента для соответствующей позиции элемента, в которой соответствующий элемент 56 конфигурации позиционирован в последовательности 55 из N элементов 56 конфигурации. В частности, порядок, в котором последовательность элементов 56 конфигурации записывается в поток 12 битов (и считывается из потока 12 битов декодером 36), может быть тем же порядком, какой использован для элементов 22 кадра и/или элементов 54 синтаксиса, соответственно. То есть, элемент 56 конфигурации, появляющийся первым в потоке 12 битов, может содержать информацию конфигурации для первого элемента 22a кадра, второй элемент 56 конфигурации - информацию конфигурации для элемента 22b кадра и т.д. Как уже упомянуто выше, часть 52 синтаксиса индикации типа и специфические для позиции элемента данные 55 конфигурации показаны в варианте осуществления согласно Фиг. 3 как перемежаемые друг с другом в том, что элемент 56 конфигурации, принадлежащий позиции i элемента, позиционирован в поток 12 битов между индикатором 54 типа для позиции i элемента и позицией i+1 элемента. Другими словами, элементы 56 конфигурации и элементы 54 синтаксиса размещены в потоке битов поочередно и считываются из него поочередно декодером 36, но другое расположение этих данных в потоке 12 данных в пределах блока 28 также может быть выполнимо, как упомянуто выше.

Посредством передачи элемента 56 конфигурации для каждой позиции 1…N элемента в блоке 28 конфигурации, соответственно, поток битов обеспечивает различное конфигурирование элементов кадра, принадлежащих различным подпотокам, и позиций элемента, соответственно, но имеющих один и тот же тип элемента. Например, поток 12 битов может содержать два подпотока единственного канала и соответственно два элемента кадра типа элемента единственного канала в пределах каждого кадра 20. Информация конфигурации для обоих подпотоков может, однако, быть настроена по-разному в потоке 12 битов. Это, в свою очередь, означает, что кодеру 24 согласно фиг. 1 разрешено по-разному установить параметры кодирования в информации конфигурации для этих различных подпотоков, и декодер 44b единственного канала декодера 36 управляется посредством использования этих различных параметров кодирования при декодировании этих двух подпотоков. Это также верно для других модулей декодирования. Говоря в более общем виде, декодер 36 конфигурируется, чтобы считывать последовательность из N элементов 56 конфигурации из блока 28 конфигурации и декодировать i-й элемент 22 кадра в соответствии с типом элемента, обозначенным i^-м элементом 54 синтаксиса, и используя эту информацию конфигурации, содержащуюся в i^-м элементе 56 конфигурации.

В иллюстративных целях на Фиг. 3 принято, что второй подпоток, то есть подпоток, составленный из элементов 22b кадра, появляющихся во второй позиции элемента в пределах каждого кадра 20, имеет подпоток типа элемента расширения, составленный из элементов 22b кадра типа элемента расширения. Естественно, это является просто иллюстративным.

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

В любом случае Фиг. 3 показывает дополнительный пример для построения элементов 56 конфигурации относительно типа элемента расширения. В ниже поясненном конкретном варианте осуществления синтаксиса эти элементы 56 конфигурации обозначены UsacExtElementConfig. Для законченности только, следует отметить, что в ниже поясненном конкретном варианте осуществления синтаксиса элементы конфигурации для других типов элемента обозначены UsacSingleChannelElementConfig, UsacChannelPairElementConfig и UsacLfeElementConfig.

Однако, прежде, чем описать возможную структуру элемента 56 конфигурации для типа элемента расширения, ссылка делается к части Фиг. 3, показывающей возможную структуру элемента кадра типа элемента расширения, здесь - иллюстративно второго элемента 22b кадра. Как здесь показано, элементы кадра типа элемента расширения могут содержать информацию 58 длины в отношении длины соответствующего элемента 22b кадра. Декодер 36 конфигурируется, чтобы считывать, из каждого элемента 22b кадра типа элемента расширения каждого кадра 20, эту информацию 58 длины. Если декодер 36 не в состоянии или не проинструктирован пользовательским вводом обрабатывать подпоток, к которому этот элемент кадра типа элемента расширения принадлежит, декодер 36 пропускает этот элемент 22b кадра, используя информацию 58 длины в качестве длины интервала пропуска, то есть длины части потока битов, которая должна быть пропущена. Другими словами, декодер 36 может использовать информацию 58 длины, чтобы вычислить количество байтов или любую другую подходящую меру для того, чтобы определить длину интервала потока битов, которая должна быть пропущена до осуществления доступа или посещения следующего элемента кадра в пределах текущего кадра 20 или начала следующего последующего кадра 20, чтобы далее продолжать считывание потока 12 битов.

Как описано более подробно ниже, элементы кадра типа элемента расширения могут быть сконфигурированы для адаптации для будущих или альтернативных расширений или развитий аудио кодека и, соответственно, элементы кадра типа элемента расширения могут иметь различные статистические распределения длины. Чтобы использовать возможность, что в соответствии с некоторыми приложениями элементы кадра типа элемента расширения некоторого подпотока имеют постоянную длину или имеют очень узкое статистическое распределение длины, в соответствии с некоторыми вариантами осуществления настоящей заявки, элементы 56 конфигурации для типа элемента расширения могут содержать информацию 60 длины полезных данных по умолчанию, как показано на Фиг. 3. В этом случае возможно для элементов 22b кадра типа элемента расширения соответствующего подпотока обращаться к этой информации 60 длины полезных данных по умолчанию, содержащейся в пределах соответствующего элемента 56 конфигурации для соответствующего подпотока, вместо того, чтобы явно передавать длину полезных данных. В частности, как показано на Фиг. 3, в этом случае информация 58 длины может содержать условную (содержащую условие) часть 62 синтаксиса в форме флага 64 длины полезных данных расширения по умолчанию, с последующим, если флаг 64 длины полезных данных по умолчанию не установлен, значением 66 длины полезных данных расширения. Любой элемент 22b кадра типа элемента расширения имеет длину полезных данных расширения по умолчанию, как обозначено информацией 60 в соответствующем элементе 56 конфигурации, в случае, если флаг 64 длины полезных данных расширения по умолчанию в информации 62 длины из соответствующего элемента 22b кадра типа элемента расширения установлен, и имеет длину полезных данных расширения, соответствующую значению 66 длины полезных данных расширения в информации 58 длины из соответствующего элемента 22b кадра типа элемента расширения в случае, если флаг 64 длины полезных данных расширения по умолчанию из информации 58 длины из соответствующего 22b кадра типа элемента расширения не установлен. Таким образом, явного кодирования значения 66 длины полезных данных расширения можно избежать кодером 24 всякий раз, когда возможно просто обратиться к длине полезных данных расширения по умолчанию, как обозначено информацией 60 длины полезных данных по умолчанию в пределах элемента 56 конфигурации из соответствующего подпотока и позиции элемента, соответственно. Декодер 36 действует следующим образом. Он считывает информацию 60 длины полезных данных по умолчанию во время считывания элемента 56 конфигурации. При считывании элемента 22b кадра соответствующего подпотока декодер 36, при считывании информации длины этих элементов кадра, считывает флаг 64 длины полезных данных расширения по умолчанию и проверяет, установлен ли он или нет. Если флаг 64 длины полезных данных по умолчанию не установлен, декодер продолжает считывание значения 66 длины полезных данных расширения из условной части 62 синтаксиса из потока битов, чтобы получить длину полезных данных расширения соответствующего элемента кадра. Однако, если флаг 64 длины полезных данных по умолчанию установлен, декодер 36 устанавливает длину полезных данных расширения соответствующего кадра, чтобы быть равным длине полезных данных расширения по умолчанию, как получено из информации 60. Пропуск декодера 36 может затем вовлечь пропуск секции 68 полезных данных текущего элемента кадра, используя длину полезных данных расширения, только что определенную как длина интервала пропуска, то есть длина части потока 12 битов, которая должна быть пропущена, чтобы получить доступ к следующему элементу 22 кадра текущего кадра 20 или началу следующего кадра 20.

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

Однако, так как априори не ясно, имеют ли полезные данные, переданные элементами кадра типа элемента расширения некоторого подпотока, такую статистику относительно длины полезных данных элементов кадра, и соответственно стоит ли передавать длину полезных данных по умолчанию явно в элементе конфигурации такого подпотока элементов кадра типа элемента расширения, в соответствии с дальнейшим вариантом осуществления информация 60 длины полезных данных по умолчанию также реализуется условной частью синтаксиса, содержащей флаг 60a, названный UsacExtElementDefaultLengthPresent в следующем конкретном примере синтаксиса, и указывающей, имеет ли место явная передача длины полезных данных по умолчанию. Просто если установлена, условная часть синтаксиса содержит явную передачу 60b длины полезных данных по умолчанию, названную UsacExtElementDefaultLength в следующем конкретном примере синтаксиса. Иначе, длина полезных данных по умолчанию является установленной по умолчанию в 0. В последнем случае экономится потребление битов потока битов, поскольку явной передачи длины полезных данных по умолчанию избегают. Таким образом, декодер 36 (и модуль 40 распределения, который ответственен за все процедуры считывания, описанные выше и ниже), может быть сконфигурирован, при считывании информации 60 длины полезных данных по умолчанию, считывать флаг 60 присутствия длины полезных данных по умолчанию из потока 12 битов, выполнять проверку относительно того, установлен ли флаг 60 присутствия длины полезных данных по умолчанию, и если флаг 60 присутствия длины полезных данных по умолчанию установлен, устанавливать длину полезных данных расширения по умолчанию в нуль, и если флаг 60 присутствия длины полезных данных по умолчанию не установлен, явно считывать длину 60b полезных данных расширения по умолчанию из потока 12 битов (а именно поле 60b после флага 60a).

В дополнение к или альтернативно механизму длины полезных данных по умолчанию, информация 58 длины может содержать флаг 70 присутствия полезных данных расширения, причем любой элемент 22b кадра типа элемента расширения, флаг 70 присутствия полезных данных расширения в информации 58 длины которого не установлен, просто состоит из флага присутствия полезных данных расширения и все. Таким образом, секции 68 полезных данных нет. С другой стороны, информация 58 длины любого элемента 22b кадра типа элемента расширения, флаг 70 присутствия полезных данных расширения в информации 58 длины которого установлен, также содержит часть 62 или 66 синтаксиса, указывающую длину полезных данных расширения соответствующего 22b кадра, то есть длину его секции 68 полезных данных. В дополнение к механизму длины полезных данных по умолчанию, то есть в комбинации с флагом 64 длины полезных данных расширения по умолчанию, флаг 70 присутствия полезных данных расширения позволяет обеспечить каждый элемент кадра типа элемента расширения двумя эффективно кодируемыми длинами полезных данных, а именно, 0 с одной стороны, и длиной полезных данных по умолчанию, то есть самой вероятной длиной полезных данных, с другой стороны.

При синтаксическом анализе или считывании информации 58 длины текущего элемента 22b кадра типа элемента расширения декодер 36 считывает флаг 70 присутствия полезных данных расширения из потока 12 битов, проверяет, установлен ли флаг 70 присутствия полезных данных расширения, и если флаг 70 присутствия полезных данных расширения не установлен, прекращает считывать соответствующий элемент 22b кадра и возобновляет считывание другого, следующего, элемента 22 кадра текущего кадра 20 или начинает считывание или синтаксический анализ следующего кадра 20. Принимая во внимание, что, если флаг 70 присутствия данных полезных данных установлен, декодер 36 считывает часть 62 синтаксиса или по меньшей мере часть 66 (если флаг 64 является несуществующим, так как этот механизм не доступен), и пропускает, если полезные данные текущего элемента 22 кадра должны быть пропущены, секцию 68 полезных данных, посредством использования длины полезных данных расширения соответствующего элемента 22b кадра типа элемента расширения в качестве длины интервала пропуска.

Как описано выше, элементы кадра типа элемента расширения могут быть обеспечены, чтобы приспособиться для будущих расширений кодека аудио или альтернативных расширений, для которых текущий декодер не является подходящим, и соответственно, элементы кадра типа элемента расширения должны быть конфигурируемыми. В частности, в соответствии с некоторым вариантом осуществления блок 28 конфигурации содержит, для каждой позиции элемента, для которой часть 52 индикации типа указывает тип элемента расширения, элемент 56 конфигурации, содержащий информацию конфигурации для этого типа элемента расширения, при этом информация конфигурации содержит, в дополнение или альтернативно к вышеупомянутым описанным в общих чертах компонентам, поле 72 типа элемента расширения, указывающее тип данных полезных данных из множества типов данных полезных данных. Множество типов данных полезных данных, в соответствии с одним вариантом осуществления, может содержать тип многоканальной побочной информации и тип многообъектной побочной информации кодирования помимо других типов данных, которые, например, зарезервированы для будущих усовершенствований. В зависимости от указанного типа данных полезных данных элемент 56 конфигурации дополнительно содержит специфические для типа данных полезных данных данные конфигурации. Соответственно, элементы 22b кадра в соответствующей позиции элемента и соответствующего подпотока, соответственно, передают в своих секциях 68 полезных данных данные полезных данных, соответствующие указанному типу данных полезных данных. Чтобы обеспечить адаптацию длины специфических для типа данных полезных данных данных 74 конфигурации к этому типу данных полезных данных, и обеспечить резервирование для будущих усовершенствований дополнительных типов данных полезных данных, конкретные варианты осуществления синтаксиса, описанные ниже, имеют элементы 56 конфигурации типа элемента расширения, дополнительно содержащие значение длины элемента конфигурации, названное UsacExtElementConfigLength так, чтобы декодеры 36, которые не знают о типе данных полезных данных, указанных для текущего подпотока, были в состоянии пропустить элемент 56 конфигурации и его специфические для типа данных полезных данных данные 74 конфигурации, чтобы получить доступ к следующей сразу после части потока 12 битов, такой как элемент 54 синтаксиса типа элемента следующей позиции элемента (или в альтернативном варианте осуществления, не показанном, элемент конфигурации следующей позиции элемента), или началу первого кадра после блока 28 конфигурации, или некоторым другим данным, как показано со ссылками на фиг. 4a. В частности, в следующем конкретном варианте осуществления для синтаксиса, данные конфигурации многоканальной побочной информации содержатся в SpatialSpecificConfig, в то время как данные конфигурации многообъектной побочной информации содержатся в пределах SaocSpecificConfig.

В соответствии с последним аспектом, декодер 36 может быть сконфигурирован, при считывании блока 28 конфигурации, выполнять следующие этапы для каждой позиции элемента или подпотока, для которого часть 52 индикации типа указывает тип элемента расширения:

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

Если поле 72 типа элемента расширения указывает тип многоканальной побочной информации, считывание данных 74 конфигурации многоканальной побочной информации в качестве части информации конфигурации из потока 12 битов, и если поле 72 типа элемента расширения указывает тип многообъектной побочной информации, считывание данных 74 конфигурации многообъектной побочной информации в качестве части информации конфигурации из потока 12 битов.

Затем, при декодировании соответствующих элементов 22b кадра, то есть элементов, соответствующих позиции элемента и подпотока, соответственно, декодер 36 может конфигурировать многоканальный декодер 44e, используя данные 74 конфигурации многоканальной побочной информации, в то же время подавая на таким образом сконфигурированный многоканальный декодер 44e данные 68 полезных данных соответствующих элементов 22b кадра в качестве многоканальной побочной информации, в случае типа данных полезных данных, указывающего тип многоканальной побочной информации, и декодировать соответствующие элементы 22b кадра посредством конфигурирования многообъектного декодера 44d, используя данные 74 конфигурации многообъектной побочной информации и подавая таким образом на сконфигурированный многообъектный декодер 44d данные 68 полезных данных соответствующего элемента 22b кадра, в случае типа данных полезных данных, указывающего тип многообъектной побочной информации.

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

Например, декодер 36 может быть сконфигурирован, чтобы, для любой позиции элемента, для которой часть 52 индикации типа указывает тип элемента расширения, считывать поле 76 длины данных конфигурации из потока 12 битов в качестве части информации конфигурации элемента 56 конфигурации для соответствующей позиции элемента так, чтобы получить длину данных конфигурации, и проверять, принадлежит ли тип данных полезных данных, указанный полем 72 типа элемента расширения в информации конфигурации элемента конфигурации для соответствующей позиции элемента, заранее определенному набору типов данных полезных данных, являющемуся поднабором множества типов данных полезных данных. Если тип данных полезных данных, указанный полем 72 типа элемента расширения в информации конфигурации элемента конфигурации для соответствующей позиции элемента, принадлежит заранее определенному набору типов данных полезных данных, декодер 36 может считывать зависимые от данных полезных данных данные 74 конфигурации в качестве части информации конфигурации элемента конфигурации для соответствующей позиции элемента из потока 12 данных, и декодировать элементы кадра типа элемента расширения в соответствующей позиции элемента в кадрах 20, используя эти зависимые от данных полезных данных данные 74 конфигурации. Но, если тип данных полезных данных, указанный полем 72 типа элемента расширения в информации конфигурации элемента конфигурации для соответствующей позиции элемента, не принадлежит заранее определенному набору типов данных полезных данных, декодер может пропускать зависимые от данных полезных данных данные 74 конфигурации, используя эту длину данных конфигурации, и пропускать элементы кадра типа элемента расширения в соответствующей позиции элемента в кадрах 20, используя информацию 58 длины в них.

В дополнение к, или альтернативно, вышеупомянутым механизмам, элементы кадра некоторого подпотока могут быть сконфигурированы, чтобы передаваться фрагментами, а не по одному за кадр полностью. Например, элементы конфигурации типов элемента расширения могут содержать флаг 78 использования фрагментации, декодер может быть сконфигурирован, чтобы при считывании элементов 22 кадра, позиционированных в любой позиции элемента, для которой часть индикации типа указывает тип элемента расширения, и для которой флаг 78 использования фрагментации из элемента конфигурации установлен, считывать информацию 80 фрагментов из потока 12 битов, и использовать эту информацию фрагментов, чтобы поместить данные полезных данных этих элементов кадра последовательных кадров вместе. В следующем конкретном примере синтаксиса каждый элемент кадра типа расширения подпотока, для которого установлен флаг 78 использования фрагментации, содержит пару из флага начала, указывающего начало полезных данных подпотока, и флага конца, указывающего конец элемента полезных данных подпотока. Эти флаги называют usacExtElementStart и usacExtElementStop в следующем конкретном примере синтаксиса.

Кроме того, в дополнение к, или альтернативно, вышеупомянутым механизмам, один и тот же код с переменной длиной кода может использоваться, чтобы считывать информацию 80 длины, поле 72 типа элемента расширения и поле 76 длины данных конфигурации, таким образом снижая сложность для реализации декодера, например, и экономя биты, посредством затребования дополнительных битов просто в редко появляющихся случаях, таких как будущие типы элемента расширения, более длинные длины типа элемента расширения и т.д. В ниже поясненном конкретном примере этот код VLC получают из Фиг. 4m.

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

(1) Считывание блока 28 конфигурации, и

(2) считывание/синтаксический разбор последовательности кадров 20. Этап 1 и 2 выполняются декодером 36 и, более точно, модулем 40 распределения.

(3) Реконструкция аудио содержимого ограничена теми подпотоками, то есть теми последовательностями элементов кадра в позициях элемента, декодирование которых поддерживается декодером 36. Этап 3 выполняется в декодере 36 в, например, его модулях декодирования (см. Фиг. 2).

Соответственно, на этапе 1 декодер 36 считывает количество 50 подпотоков и количество элементов 22 кадра в кадре 20, соответственно, так же как часть 52 синтаксиса типа элемента, показывающую тип элемента каждого из этих подпотоков и позиции элемента, соответственно. Для того, чтобы синтаксически разобрать поток битов на этапе 2, декодер 36 затем циклически считывает элементы 22 кадра последовательности кадров 20 из потока 12 битов. При этом декодер 36 пропускает элементы кадра или оставшиеся части/части полезных данных их, посредством использования информации 58 длины, как было описано выше. На третьем этапе декодер 36 выполняет реконструкцию, декодируя не пропущенные элементы кадра.

При принятии на этапе 2 решения - какие из позиций элемента и подпотоков должны быть пропущены, декодер 36 может проверить элементы 56 конфигурации в блоке 28 конфигурации. Чтобы выполнить это, декодер 36 может быть сконфигурирован, чтобы циклически считывать элементы 56 конфигурации из блока 28 конфигурации потока 12 битов в том же самом порядке, как используется для самих индикаторов 54 типа элемента и элементов 22 кадра. Как указано выше, циклическое считывание элементов 56 конфигурации может перемежаться с циклическим считыванием элементов 54 синтаксиса. В частности, декодер 36 может проверить поле 72 типа элемента расширения в пределах элементов 56 конфигурации подпотоков типа элемента расширения. Если тип элемента расширения не поддерживается, декодер 36 пропускает соответствующий подпоток и соответствующие элементы 22 кадра в соответствующих позициях элемента кадра в пределах кадров 20.

Чтобы уменьшить частоту следования в битах, необходимую для передачи информации 58 длины, декодер 36 конфигурируется, чтобы проверить элементы 56 конфигурации подпотоков типа элемента расширения, и в частности, их информацию 60 длины полезных данных по умолчанию, на этапе 1. На втором этапе декодер 36 проверяет информацию 58 длины элементов 22 кадра расширения, которые должны быть пропущены. В частности, сначала декодер 36 проверяет флаг 64. Если установлен, декодер 36 использует длину по умолчанию, указанную для соответствующего подпотока посредством информации 60 длины полезных данных по умолчанию, в качестве оставшейся длины полезных данных, которая должна быть пропущена, чтобы продолжить циклическое считывание/синтаксический анализ элементов кадра этих кадров. Если флаг 64, однако, не установлен, то декодер 36 явно считывает длину 66 полезных данных из потока 12 битов. Хотя явно не пояснено выше, должно быть ясно, что декодер 36 может получить количество битов или байтов, которые должны быть пропущены, чтобы получить доступ к следующему элементу кадра текущего кадра или следующего кадра, посредством некоторого дополнительного вычисления. Например, декодер 36 может принимать во внимание, активизирован ли механизм фрагментации или нет, как пояснено выше относительно флага 78. Если активизирован, декодер 36 может принимать во внимание, что элементы кадра подпотока, имеющего установленный флаг 78, в любом случае имеют информацию 80 фрагментации и что, соответственно, данные 68 полезных данных начинаются позже, как это имело бы в случае не установленного флага 78 фрагментации.

При декодировании на этапе 3 декодер действует как обычно: то есть, отдельные подпотоки подаются на соответствующие механизмы декодирования или модули декодирования, как показано на Фиг. 2, при этом некоторые подпотоки могут формировать побочную информацию относительно других подпотоков, как было пояснено выше относительно конкретных примеров подпотоков расширения.

Относительно других возможных деталей относительно функциональных возможностей декодеров ссылка делается к вышеупомянутому описанию. Для законченности следует только отметить, что декодер 36 может также пропустить дальнейший синтаксический анализ элементов 56 конфигурации на этапе 1, а именно, для тех позиций элемента, которые должны быть пропущены, так как, например, тип элемента расширения, указанный полем 72, не соответствует поддерживаемому набору типов элемента расширения. Затем декодер 36 может использовать информацию 76 длины конфигурации, чтобы пропустить соответствующие элементы конфигурации при циклическом считывании/синтаксическом анализе элементов 56 конфигурации, то есть при пропуске соответствующего количества битов/байтов, чтобы получить доступ к следующему элементу синтаксиса потока битов, такому как индикатор 54 типа следующей позиции элемента.

Перед продолжением вышеупомянутого конкретного варианта осуществления синтаксиса нужно отметить, что настоящее изобретение не ограничено, чтобы быть реализованным кодированием объединенной речи и аудио и его аспектами, такими как переключение базового кодирования, используя микширование, или переключение между подобным AAC кодированием в частотной области и LP кодированием, используя параметрическое кодирование (ACELP) и кодирование с преобразованием (TCX). Вместо этого вышеупомянутые подпотоки могут представить аудио сигналы, используя любую схему кодирования. Кроме того, в то время как в ниже описанном в общих чертах конкретном варианте осуществления синтаксиса предполагается, что SBR является опцией кодирования базового кодека, используемого для представления аудио сигналов, используя подпотоки типа элемента единственного канала и пары каналов, SBR также может не быть опцией последних типов элемента, а просто быть используемыми, с использованием типов элемента расширения.

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

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

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

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

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

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

Данные конфигурации SBR ("заголовок SBR") разделяются на SbrInfo() и SbrHeader(). Для SbrHeader() определена версия по умолчанию (SbrDfltHeader()), на которую можно эффективно ссылаться в потоке битов. Это уменьшает битовое требование в местах, где повторная передача данных конфигурации SBR необходима.

Более обычно применяемые изменения конфигурации для SBR могут быть эффективно сигнализированы с помощью элемента синтаксиса Sbrlnfo().

Конфигурация для параметрического расширения полосы частот (SBR) и инструментов параметрического кодирования стерео (MPS212, aka. MPEG Surround 2-1-2), тесно интегрируется в структуру конфигурации USAC. Это представляет намного лучший способ, которым обе технологии фактически используются в стандарте.

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

Расширения могут быть помещены (то есть перемежаться) с канальными элементами в любом порядке. Это позволяет, чтобы расширения были считаны прежде или после конкретного канального элемента, к которому должно быть применено расширение.

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

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

Конфигурация потока битов

UsacConfig() (Фиг. 4a) UsacConfig() был расширен, чтобы содержать информацию о содержащемся содержимом аудио, а также обо всем необходимом для полной установки декодера. Информация высокого уровня об аудио (частота дискретизации, конфигурации канала, длины кадра вывода) собирается вначале для свободного доступа от более высоких (прикладных) уровней.

channelConfigurationlndex, UsacChannelConfig() (Фиг. 4b)

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

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

Этот список позиций динамиков является расширенным набором списка, имеющегося в стандарте MPEG Surround (см. Таблицу 1 и фиг. 1 в ISO/IEC 23003-1). Четыре дополнительных позиции динамика были добавлены, чтобы быть в состоянии охватить в последнее время введенные установки динамика 22.2 (см. Фиг. 3a, 3b, 4a и 4b).

UsacDecoderConfig() (Фиг. 4c)

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

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

Цикл по всем элементам затем обеспечивает конфигурацию всех элементов всех типов (единственный, пара, lfe, расширение).

UsacConfigExtension() (Фиг. 4l)

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

UsacSingleChannelEIementConfig() (Фиг. 4d) Эта конфигурация элемента содержит всю информацию, необходимую для конфигурирования декодера, чтобы декодировать один единственный канал. Это является по существу информацией, относящейся к базовому кодеру, и если используется SBR, относящейся к SBR информацией.

UsacChannelPairElementConfig() (Фиг. 4e)

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

UsacLfeElementConfig() (Фиг. 4f)

Конфигурация элемента LFE не содержит данных конфигурации, поскольку элемент LFE имеет статическую конфигурацию.

UsacExtEIementConfig() (Фиг. 4k)

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

Расширения, которые предполагаются, как уже объединенные с USAC, включают в себя: MPEG Surround, SAOC, и некоторый вид элемента FIL, как известно из MPEG-4 AAC.

UsacCoreConfig() (Фиг. 4g)

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

SbrConfig() (Фиг. 4h)

Чтобы уменьшить служебные расходы в битах, произведенные частой повторной передачей sbr_header(), значения по умолчанию для элементов sbr_header(), которые обычно сохраняются постоянными, теперь переносятся в элементе конфигурации SbrDfltHeader(). Кроме того, статические элементы конфигурации SBR также переносятся в SbrConfig(). Эти статические биты включают в себя флаги для разрешения или запрещения конкретных признаков расширенного SBR, подобных гармонической транспозиции или интер-TES.

SbrDfltHeader() (Фиг. 4i) Это переносит элементы sbr_header(), которые типично сохраняются постоянными. Влияющие на элементы вещи, такие как амплитудное разрешение, частотный диапазон разделительного фильтра, предварительное выравнивание спектра, теперь переносятся в SbrInfo(), что позволяет эффективно изменять их на лету.

Mps212Config() (Фиг. 4j)

Подобно вышеупомянутой конфигурации SBR, все параметры установки для инструмента MPEG Surround 2-1-2 собраны в этой конфигурации. Были удалены все элементы из SpatialSpecificConfig(), которые не являются релевантными или избыточными в этом контексте.

Полезные данные потока битов

UsacFrame() (Фиг. 4n)

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

UsacSingleChannelEIement() (Фиг. 4o)

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

UsacChannelPairEIement() (Фиг. 4p)

Этот элемент охватывает данные для всех возможных способов закодировать стерео пару. В частности, все разновидности унифицированного кодирования стерео охватываются в пределах от традиционного основанного на M/S кодирования до полностью параметрического кодирования стерео с помощью MPEG Surround 2-1-2. stereoConfiglndex указывает, какая особенность фактически используется. Подходящие eSBR данные и MPEG Surround 2-1-2 данные посылаются в этом элементе

UsacLfeEIement() (Фиг. 4q)

Прежний lfe_channel_element() переименован только для того, чтобы следовать последовательной схеме обозначений.

UsacExtEIement() (Фиг. 4r)

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

UsacCoreCoderData() (Фиг. 4s)

Этот новый элемент суммирует всю информацию, затрагивающую базовые кодеры, и следовательно также содержит потоки fd_channel_stream() и lpd_channel_stream().

StereoCoreToolInfo() (Фиг. 4t)

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

UsacSbrData() (Фиг. 4x)

Функциональные возможности CRC и традиционные элементы описания масштабируемого кодирования аудио были удалены из того, что должно было быть элементом sbr_extension_data(). Чтобы уменьшить служебные расходы, вызванные частой повторной передачей информации SBR и данных заголовка, присутствие их может быть явно сигнализировано.

Sbrlnfo() (Фиг. 4y)

Данные конфигурации SBR, которые часто модифицируются «на лету». Они включают в себя элементы, управляющие такими вещами как разрешение по амплитуде, частотный диапазон разделительного фильтра (разделительного фильтра), предварительное выравнивание спектра, которое ранее требовало передачи полного sbr_header() (см. 6.3 в [N11660], "Efficiency").

SbrHeader() (Фиг. 4z)

Чтобы поддерживать способность SBR изменять значения в sbr_header() на лету, теперь возможно передавать SbrHeader() в UsacSbrData() в случае, если отличные значения от посланных в SbrDfltHeader() должны использоваться. Механизм bs_header_extra был поддержан, чтобы сохранить служебные расходы настолько низкими насколько возможно для большинства общих случаев.

sbr_data() (Фиг. 4za)

Снова, остатки масштабируемого кодирования SBR были удалены, так как они не применимы в контексте USAC. В зависимости от количества каналов sbr_data() содержит один sbr_single_channel_EIement() или один sbr_channel_pair_element().

usacSampIingFrequencyIndex

Эта таблица является расширенным набором таблицы, используемой в MPEG-4, чтобы сигнализировать частоту осуществления выборки аудио кодека. Таблица была дополнительно расширена, чтобы также охватить частоты следования битов при осуществлении выборки, которые в настоящее время используются в операционных режимах USAC. Некоторые кратные значения частот осуществления выборки были также добавлены.

channelConfigurationlndex

Эта таблица является расширенным набором таблицы, используемой в MPEG-4, чтобы сигнализировать channelConfiguration. Она была дополнительно расширена, чтобы позволить сигнализировать обычно используемых и предполагаемых будущих установок параметров громкоговорителя. Индекс в эту таблицу сигнализируется 5 битами, чтобы учесть будущие расширения.

usacElementType

Существуют только 4 типа элемента. Один для каждого из четырех основных элементов потока битов: Usac-SingleChannelElement(), UsacChannelPairElement(), UsacLfeElement(), UsacExtEle-ment(). Эти элементы обеспечивают необходимую структуру верхнего уровня, в то же время поддерживая всю необходимую гибкость.

usacExtElementType

Внутри UsacExtElement() этот элемент позволяет сигнализировать множество расширений. Чтобы выдержать проверку временем, битовое поле было выбрано достаточно большим, чтобы учесть все мыслимые расширения. Из в настоящее время известных расширений уже несколько предложены для рассмотрения: элемент заполнения, MPEG Surround и SAOC.

usacConfigExtType

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

coreSbrFrameLengthlndex

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

stereoConfiglndex

Эта таблица определяет внутреннюю структуру UsacChannelPairElement(). Она указывает использование моно или стерео ядра, использование MPS212, применен ли SBR стерео, и применено ли остаточное кодирование в MPS212.

Посредством перемещения больших частей полей заголовка eSB в заголовок по умолчанию, на который можно сослаться посредством флага заголовка по умолчанию, битовое требование на посылку данных управления eSBR было значительно уменьшено. Прежние битовые поля sbr_header(), которые были рассмотрены для изменения наиболее вероятно в системе реального мира, были вместо этого заимствованы для элемента sbrInfo(), который теперь состоит только из 4 элементов, охватывающих максимум 8 битов. По сравнению с sbr_header(), который состоит по меньшей мере из 18 битов, это составляет экономию 10 битов.

Более трудно оценить воздействие этого изменения на полную частоту следования в битах, так как это сильно зависит от частоты передачи данных управления eSBR в sbrInfo(). Однако, уже для случая обычного использования, где разделительный фильтр sbr изменяется в потоке битов, экономия в битах может быть столь же высокой как 22 бита на каждое появление, при посылке sbrInfo() вместо полностью переданного sbr_header().

Выходной сигнал декодера USAC может быть далее обработан посредством MPEG Surround (MPS) (ISO/IEC 23003-1) или SAOC (ISO/IEC 23003-2). Если инструмент SBR в USAC является активным, декодер USAC может быть обычно эффективно объединенным с последующим декодером MPS/SAOC, с помощью соединения их в области QMF таким же образом, как описано для HE-AAC в ISO/IEC 23003-1 4.4. Если соединение в области QMF невозможно, они должны быть связаны во временной области.

Если побочная информация MPS/SAOC внедрена в поток битов USAC посредством механизма usacExtElement (с usacExtElementType, равным ID _EXT_ELE_MPEGS или ID _EXT_ELE_SAOC), выравнивание во времени между данными USAC и данными MPS/SAOC предполагает самое эффективное соединение между декодером USAC и декодером MPS/SAOC. Если инструмент SBR в USAC является активным и если MPS/SAOC использует представление области QMF в 64 частотных диапазонов (см. ISO/IEC 23003-1 6.6.3), самое эффективное соединение находится в области QMF. Иначе, самое эффективное соединение находится во временной области. Это соответствует выравниванию во времени для комбинации HE-AAC и MPS, как определено в ISO/IEC 23003-1 4.4, 4.5, и 7.2.1.

Дополнительная задержка, введенная добавлением декодирования MPS после декодирования USAC, задается с помощью ISO/IEC 23003-1 4.5 и зависит от того, используется ли HQ MPS или LP MPS, и соединен ли MPS с USAC в области QMF или во временной области.

ISO/IEC 23003-1 4.4 разъясняет интерфейс между системами USAC и MPEG. Каждый блок доступа, поставленный аудио декодеру из системного интерфейса, должен привести к соответствующему блоку композиции, доставленному из аудио декодера к системному интерфейсу, то есть, блоку составления композиции. Это должно включать в себя условия запуска и завершения, то есть, когда блок доступа является первым или последним в конечной последовательности блоков доступа.

Для блока композиции аудио, ISO/IEC 14496-1 7.1.3.5 Composition Time Stamp (CTS) определяет, что время композиции относится к n-ой выборке аудио в пределах блока композиции. Для USAC значение n всегда равно 1. Следует отметить, что это относится непосредственно к выходному сигналу декодера USAC. В этом случае этот декодер USAC, например, объединенный с декодером MPS, должен быть принят во внимание для блоков композиции, доставленных на выходе декодера MPS.

Если побочная информация MPS/SAOC внедрена в поток битов USAC посредством механизма usacExtElement (с usacExtElementType являющимся ID_EXT_ELE_MPEGS или ID_EXT_ELE_SAOC), следующие ограничения могут, необязательно, примениться:

- параметр MPS/SAOC sacTimeAlign (см. ISO/IEC 23003-1 7.2.5) будет иметь значение 0.

- частота осуществления выборки MPS/SAOC будет такой же выходная частота осуществления выборки USAC.

- параметр MPS/SAOC bsFrameLength (см. ISO/IEC 23003-1 5.2) должен иметь одно из разрешенных значений из заранее определенного списка.

Этот синтаксис полезных данных потока битов USAC показан на Фиг. 4n-4r, и синтаксис вспомогательных элементов полезных данных показан на Фиг. 4s-w, и расширенный синтаксис полезных данных SBR показан на Фиг. 4x-4zc.

Краткое описание элементов данных

UsacConfig() Этот элемент содержит информацию о содержащемся аудио контенте, а также всем необходимом для полной установки декодера

UsacChannelConfig() Этот элемент дает информацию о содержащихся элементах потока битов и их отображении на громкоговорители

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

UsacConfigExtension() Механизм расширения конфигурации для расширения конфигурации для будущих расширений конфигурации для USAC.

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

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

UsacLfeElementConfig() конфигурация элемента LFE не содержит данные конфигурации, так как элемент LFE имеет статическую конфигурацию.

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

UsacCoreConfig() содержит данные конфигурации, которые оказывают влияние на установку базового кодера.

SbrConfig() содержит значения по умолчанию для элементов конфигурации eSBR, которые типично сохраняются постоянными. Кроме того, статические элементы конфигурации SBR также передаются в SbrConfig(). Эти статические биты включают в себя флаги для разрешения или запрещения конкретных особенностей расширенного SBR, подобных перемещению гармоник или внешним TES.

SbrDfltHeader() Этот элемент переносит версию по умолчанию элементов SbrHeader(), на которые можно ссылаться, если никакие отличающиеся значения для этих элементов не являются желательными.

Mps212Config() Все параметры установки инструмента для MPEG Surround 2-1-2 собраны в этой конфигурации.

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

usacSampIingFrequencylndex Этот индекс определяет частоту осуществления выборки аудио сигнала после декодирования. Значение usacSamplingFrequencylndex и их ассоциированные частоты осуществления выборки описаны в Таблице C.

Таблица C
Значение и смысл usacSamplingFrequencyIndex usacSamplingFrequencyIndex Частота выборки 0x00 96000 0x01 88200 0x02 64000 0x03 48000 0x04 44100 0x05 32000 0x06 24000 0x07 22050 0x08 16000 0x09 12000 0x0a 11025 0x0b 8000 0x0c 7350 0x0d Зарезервирован 0x0e Зарезервирован 0x0f 57600 0x10 51200 0x11 40000 0x12 38400 0x13 34150 0x14 28800 0x15 25600 0x16 20000 0x17 19200 0x18 17075 0x19 14400 0x1a 12800 0x1b 9600 0x1c Зарезервирован 0x1d Зарезервирован 0x1e Зарезервирован 0x1f Значение перехода Замечание: значения UsacSamplingFrequencylndex 0x00-0x0e идентичны таковым из samplingFrequencylndex 0x0-0xe, содержащимся в AudioSpecificConfig(), заданном в ISO/IEC 14496-3:2009

usacSampIingFrequency Выходная частота выборки декодера, закодированное как целочисленное значение без знака в случае, если usacSamplingFrequencylndex равняется нулю.

channelConfigurationlndex Этот индекс определяет конфигурацию канала. Если channelConfigurationlndex > 0, этот индекс однозначно определяет количество каналов, канальных элементов и ассоциированное отображение громкоговорителя согласно Таблице Y. Названия позиций громкоговорителя, используемых сокращений и обычной позиции доступных громкоговорителей могут быть получены из Фиг. 3a, 3b и Фиг. 4a и 4b.

bsOutputChannelPos Этот индекс описывает позиции громкоговорителя, которые ассоциированы с заданным каналом согласно Таблице ХХ. Фиг. Y указывает позицию громкоговорителя в 3D-среде слушателя. Чтобы облегчить понимание позиций громкоговорителя, Таблица ХХ также содержит позиции громкоговорителя согласно IEC 100/1706/CDV, которые перечислены здесь для информации заинтересованному читателю.

usacConfigExtensionPresent Указывает присутствие расширений к конфигурации

numOutChannels Если значение channelConfigurationlndex указывает, что ни одна из заранее заданных конфигураций канала не используется, то этот элемент определяет количество каналов аудио, для которых должна быть ассоциирована конкретная позиция громкоговорителя.

numElements Это поле содержит ряд элементов, которые будут следовать в цикле по типам элемента в UsacDecoderConfig()

usacElementType[elemldx] определяет тип канального элемента USAC упомянутого элемента в позиции elemldx в потоке битов. Существуют четыре типа элемента, один для каждого из четырех основных элементов потока битов: Usac-SingleChannelElement(), UsacChannelPairElement(), UsacLfeElement(), UsacExtElement(). Эти элементы обеспечивают необходимую структуру верхнего уровня, в то же время поддерживая всю необходимую гибкость. Значение usacElementType определено в Таблице A.

stereoConfiglndex Этот элемент определяет внутреннюю структуру UsacChan-nelPairElement(). Он указывает использование моно или стерео ядра, использование MPS212, применен ли стерео SBR, и применено ли остаточное кодирование в MPS212 согласно Таблице ZZ. Этот элемент также определяет значения элементов bsStereoSbr и bsResidualCoding помощника.

tw_mdct Этот флаг сигнализирует использование деформированной шкалы времени MDCT в этом потоке.

noiseFilling Этот флаг сигнализирует использование заполнения шумом спектральных окон в базовом кодере FD.

harmonicSBR Этот флаг сигнализирует использование гармонических вставок для SBR.

bs_interTes Этот флаг сигнализирует использование инструмента интер-TES в SBR.

dflt_start_freq Это является значением по умолчанию для элемента bs_start_freq потока битов, который применяется в случае, если флаг sbrUseDfltHeader указывает, что значения по умолчанию для элементов SbrHeader() должны быть приняты.

dflt_stop_freq Это является значением по умолчанию для элемента bs_stop_freq потока битов, который применяется в случае, если флаг sbrUseDfltHeader указывает, что значения по умолчанию для элементов SbrHeader() должны быть приняты.

dflt_header_extra1 Это является значением по умолчанию для элемента bs_header_extra1 потока битов, который применяется в случае, если флаг sbrUseDfltHeader указывает, что значения по умолчанию для элементов SbrHeader() должны быть приняты.

dflt_header_extra2 Это является значением по умолчанию для элемента bs_header_extra2 потока битов, который применяется в случае, если флаг sbrUseDfltHeader указывает, что значения по умолчанию для элементов SbrHeader() должны быть приняты.

dflt_freq_scale Это является значением по умолчанию для элемента bs_freq_scale потока битов, который применяется в случае, если флаг sbrUseDfltHeader указывает, что значения по умолчанию для элементов SbrHeader() должны быть приняты.

dflt_alter_scale Это является значением по умолчанию для элемента bs_alter_scale потока битов, который применяется в случае, если флаг sbrUseDfltHeader указывает, что значения по умолчанию для элементов SbrHeader() должны быть приняты.

Dflt-noise_bands Это является значением по умолчанию для элемента bs_noise_bands потока битов, который применяется в случае, если флаг sbrUseDfltHeader указывает, что значения по умолчанию для элементов SbrHeader() должны быть приняты.

dflt_limiter_bands Это является значением по умолчанию для элемента bs_limiter_bands потока битов, который применяется в случае, если флаг sbrUseDfltHeader указывает, что значения по умолчанию для элементов SbrHeader() должны быть приняты.

dflt_limiter_gains Это является значением по умолчанию для элемента bs_limiter_gains потока битов, который применяется в случае, если флаг sbrUseDfltHeader указывает, что значения по умолчанию для элементов SbrHeader() должны быть приняты.

dflt_interpoI_freq Это является значением по умолчанию для элемента bs_interpol_freq потока битов, который применяется в случае, если флаг sbrUseDfltHeader указывает, что значения по умолчанию для элементов SbrHeader() должны быть приняты.

dflt_smoothing_mode Это является значением по умолчанию для элемента bs_smoothing_mode потока битов, который применяется в случае, если флаг sbrUseDfltHeader указывает, что значения по умолчанию для элементов SbrHeader() должны быть приняты.

usacExtElementType этот элемент позволяет сигнализировать типы расширений потока битов. Смысл (значение) usacExtElementType определен в Таблице B.

Таблица B
Значение usacExtElementType Значение 0 1 2 /* зарезервировано для использования ISO*/ 3-127 /* зарезервировано для использования вне ISO*/ 128 и выше Замечание: специфическим для приложений значениям usacExtElementType предписано быть в пространстве, зарезервированном для использования вне ISO. Они пропускаются декодером, когда минимум структуры требуется декодером для пропуска этих расширений

usacExtEIementConfigLength сигнализирует длину конфигурации расширения в байтах (октетах).

usacExtElementDefaultLengthPresent Этот флаг сигнализирует, передан ли usacExtElementDefaultLength в UsacExtElementConfig().

usacExtElementDefaultLength сигнализирует длину по умолчанию элемента расширения в байтах. Только если элемент расширения в заданном блоке доступа отклоняется от этого значения, дополнительная длина должна быть передана в потоке битов. Если этот элемент не будет явно передан (usacExtElementDefaultLengthPresent==0), то значение usacExtElementDefaultLength должно быть установлено в ноль.

usacExtElementPayloadFrag Этот флаг указывает, могут ли полезные данные этого элемента расширения быть фрагментированы и посланы как несколько сегментов в последовательных кадрах USAC.

numConfigExtensions Если расширения к конфигурации присутствуют в UsacConfig(), это значение указывает количество сообщенных расширений конфигурации.

confExtldx Индекс к расширениям конфигурации.

usacConfigExtType Этот элемент позволяет сигнализировать типы расширения конфигурации. Значение usacExtElementType определено в Таблице D.

Таблица D
Значения usacConfigExtType Значение ID_CONFIG_EXT_FILL 0 /* зарезервировано для использования ISO*/ 1-127 /* зарезервировано для использования вне ISO*/ 128 и выше

usacConfigExtLength сигнализирует длину расширения конфигурации в байтах (октетах).

bsPseudoLr Этот флаг сигнализирует, что инверсное среднее / боковое вращение должно быть применено к базовому сигналу до обработки Mps212.

Таблица
bsPseudoLr bsPseudoLr Значение 0 Выходным сигналом базового кодера является DMX/RES 1 Выходным сигналом базового кодера является Pseudo L/R

bsStereoSbr Этот флаг сигнализирует использование SBR стерео в комбинации с декодированием MPEG Surround.

Таблица
bsStereoSbr bsStereoSbr Значение 0 Моно SBR 1 Стерео SBR

bsResidualCoding указывает, применено ли остаточное кодирование согласно Таблице ниже. Значение bsResidualCoding определено с помощью stereoConfiglndex (см. X).

Таблица
bsResidualCoding bsResidualCoding Значение 0 нет кодирования остатка, базовым кодером является моно 1 кодирование остатка, базовым кодером является стерео

sbrRatioIndex указывает отношение между базовой частотой осуществления выборки и частотой осуществления выборки после обработки eSBR. В то же самое время, оно указывает количество частотных диапазонов анализа и синтеза QMF, используемых в SBR согласно Таблице ниже.

elemldx Индекс для элементов, присутствующих в UsacDecoderConfig() и UsacFrame().

UsacConfig()

UsacConfig() содержит информацию о выходной частоте осуществления выборки и конфигурации канала. Эта информация должна быть идентичной информации, сообщенной вне элемента, например в MPEG-4 AudioSpecificConfig().

Выходная частота осуществления выборки Usac

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

UsacChannelConfig ()

Эта таблица конфигурации каналов охватывает самые общие позиции громкоговорителя. Для дополнительной гибкости каналы могут быть отображены на полный выбор 32 позиций громкоговорителя, найденных в современных установках громкоговорителя в различных приложениях (см. Фиг. 3a, 3b),

Для каждого канала, содержащегося в потоке битов, UsacChannelConfig() определяет ассоциированную позицию громкоговорителя, на которую этот конкретный канал должен быть отображен. Позиции громкоговорителя, которые индексированы в bsOutputChannelPos, перечислены в таблице Х. В случае множественных канальных элементов индекс i для bsOutputChannelPos[i] указывает позицию, в которой канал появляется в потоке битов. Фигура Y дает краткий обзор по позициям громкоговорителя относительно слушателя.

Более точно каналы пронумерованы в последовательности, в которой они появляются в битовом потоке, начиная с 0 (нуля). В тривиальном случае UsacSingleChannelElement() или UsacLfeElement() номер канала назначается на этот канал, и подсчет каналов увеличивается на один. В случае UsacChannelPairElement() первый канал в этом элементе (с индексом ch == 0) пронумерован первым, тогда как второй канал в том же самом элементе (с индексом ch==1) принимает следующий больший номер, и подсчет каналов увеличивается на два.

Из этого следует, что numOutChannels должен быть равным или меньшим, чем накопленная сумма всех каналов, содержащихся в потоке битов. Накопленная сумма всех каналов эквивалентна количеству всех элементов UsacSingleChannelElement() плюс количество всех элементов UsacLfeEle-ment() плюс два раза количество всех элементов UsacChannelPairElement().

Все записи в массиве bsOutputChannelPos должны быть взаимно различными, чтобы избежать двойного назначения позиций громкоговорителя в потоке битов.

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

UsacDecoderConfig()

UsacDecoderConfig() содержит всю дополнительную информацию, запрошенную декодером, чтобы интерпретировать поток битов. Сначала значение sbrRatioIndex определяет соотношение между основной длиной (ccfl) кадра кодера и длиной выходного кадра. После sbrRatioIndex имеется цикл по всем канальным элементам в существующем потоке битов. Для каждой итерации тип элемента сигнализируется в usacElementType[], с непосредственно следующей за ним соответствующей структурой конфигурации. Порядок, в котором различные элементы присутствуют в UsacDecoderConfig(), должен быть идентичным порядку соответствующих полезных данных в UsacFrame().

Каждый экземпляр элемента может быть сконфигурирован независимо. При считывании каждого канального элемента в UsacFrame(), для каждого элемента соответствующая конфигурация этого экземпляра, то есть с тем же самым elemldx, должна использоваться.

UsacSingleChannelElementConfig()

UsacSingleChannelElementConfig() содержит всю информацию, необходимую для конфигурирования декодера, чтобы декодировать один единственный канал. Данные конфигурации SBR передаются, только если SBR фактически используется.

UsacChannelPairEIementConfig()

UsacChannelPairEIementConfig() содержит относящиеся к базовому кодеру данные конфигурации, так же как данные конфигурации SBR в зависимости от использования SBR. Точный тип алгоритма кодирования стерео обозначен посредством stereoConfiglndex. В USAC пара каналов может быть закодирована различными способами. Ими являются:

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

2. Моно канал базового кодера в комбинации с основанным на MPEG Surround MPS212 для полностью параметрического кодирования стерео. Моно обработка SBR применяется в отношении основного сигнала.

3. Стерео пара базового кодера в комбинации с основанным на MPEG Surround MPS212, где первый канал базового кодера несет сигнал понижающего микширования, и второй канал несет остаточный сигнал. Остаток может быть частотным диапазоном, ограниченным для реализации частичного остаточного кодирования. Моно обработка SBR применяется только в отношении сигнала понижающего микширования перед обработкой MPS212.

4. Стерео пара базового кодера в комбинации с основанным на MPEG Surround MPS212, где первый канал базового кодера несет сигнал понижающего микширования и второй канал несет остаточный сигнал. Остаток может быть частотным диапазоном, ограниченным для реализации частичного остаточного кодирования. SBR Стерео применяется в отношении восстановленного сигнала стерео после обработки MPS212.

Опции 3 и 4 могут быть далее скомбинированы с псевдо вращением канала LR после базового декодера.

UsacLfeElementConfig()

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

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

UsacCoreConfig()

UsacCoreConfig() только содержит флаги для разрешения или запрещения использования MDCT с деформированной шкалой времени и спектрального заполнения шумом на глобальном уровне потока битов. Если tw_mdct установлен в ноль, то деформированная шкала времени не должна быть применена. Если noiseFilling установлен в ноль, то спектральное заполнение шумом не должно быть применено.

SbrConfig()

Элемент SbrConfig() потока битов служит цели сигнализировать точные параметры установки eSBR. С одной стороны, SbrConfig() сигнализирует общее использование инструментов eSBR. С другой стороны, он содержит версию по умолчанию для SbrHeader(), SbrDfltHeader(). Эти значения этого заголовка по умолчанию должны быть приняты, если никакое различие SbrHeader() не будет передано в потоке битов. Основа этого механизма в том, что обычно только один набор значений SbrHeader() применяется в одном потоке битов. Передача SbrDfltHeader() затем позволяет обращаться к этому набору значений по умолчанию очень эффективно посредством использования только одного бита в потоке битов. Возможность изменять значения SbrHeader «на лету» все еще сохраняется, обеспечивая передачу в частотном диапазоне нового SbrHeader непосредственно в потоке битов.

SbrDfltHeader() SbrDfltHeader() является тем, что можно назвать основным шаблоном SbrHeader() и должно содержать значения для преобладающе используемой eSBR конфигурации. В потоке битов эта конфигурация может быть указана, устанавливая флаг sbrUseDfltHeader. Структура SbrDfltHeader() идентична таковой из SbrHeader(). Чтобы быть в состоянии проводить различие между значениями SbrDfltHeader() и SbrHeader(), битовые поля в SbrDfltHeader() имеют префикс "dflt_" вместо "bs_". Если использование SbrDfltHeader() указано, то битовые поля SbrHeader() должны принять значения соответствующего SbrDfltHeader(), то есть

bs_start_freq = dflt_start_freq;

bs_stop_freq = dflt_stop_freq;

и т.д.

(продолжить для всех элементов в SbrHeader(), подобно:

bs_xxx_yyy = dflt_xxx_yyy;

Mps212Config()

Mps212Config() повторно собирает SpatialSpecificConfig() для MPEG Surround, и был в большей части выведен из него. Он однако уменьшен в такой степени, чтобы содержать только информацию, относящуюся к моно к стерео повышающему микшированию в контексте USAC. Следовательно, MPS212 конфигурирует только один блок OTT.

UsacExtElementConfig()

UsacExtElementConfig() - является общим контейнером для данных конфигурации элементов расширения для USAC. Каждое расширение USAC имеет уникальный идентификатор типа, usacExtElementType, который определен в Таблице Х. Для каждого UsacExtElementConfig() длина содержащейся конфигурации расширения передается в переменной usacExtElementConfigLength и позволяет декодерам благополучно пропускать элементы расширения, usacExtElementType которых неизвестен.

Для расширений USAC, которые обычно имеют постоянную длину полезных данных, UsacExtElementConfig() разрешает передачу usacExtElementDefaultLength. Определение длины полезных данных по умолчанию в этой конфигурации обеспечивает очень эффективную сигнализацию usacExtElementPayloadLength внутри UsacExtElement(), где потребление битов требуется быть сохраненным низким.

В случае расширений USAC, где большее количество данных накоплено и передается не на основе кадра, а только каждый второй кадр или еще более редко, эти данные могут быть переданы во фрагментах или сегментах, распределенных по нескольким кадрам USAC. Это может быть полезно, чтобы сохранить емкость в битах более уравненной. Использование этого механизма сигнализируется флагом usacExtElementPayloadFlag. Механизм фрагментации далее объяснен в описании usacExtElement в 6.2. X.

UsacConfigExtension()

UsacConfigExtension() является общим контейнером для расширений UsacConfig(). Он обеспечивает удобный способ исправить или расширить информацию, обмениваемую во время инициализации или установки декодера. Присутствие расширений config обозначается посредством usacConfigExtensionPresent. Если расширения config присутствуют (usacConfigExtensionPresent == 1), точное количество этих расширений следует в битовом поле numConfigExtensions. Каждое расширение конфигурации имеет уникальный идентификатор типа, usacConfigExtType, который определен в Таблице Х. Для каждого UsacConfigExtension длина содержащегося расширения конфигурации передается в переменной usacConfigExtLength и позволяет анализатору потока битов конфигурации благополучно пропускать расширения конфигурации, usacConfigExtType которых неизвестен.

Полезные данные верхнего уровня для USAC типа аудио объекта

Термины и определения

UsacFrame() Этот блок данных содержит аудио данные в течение временного периода одного кадра USAC, связанную информацию и другие данные. Как сигнализировано в UsacDecoderConfig(), UsacFrame() содержит numElements элементов. Эти элементы могут содержать аудио данные для одного или двух каналов, аудио данные для низкочастотного расширения или полезные данные расширения.

UsacSingleChannelEIement() Сокращение - SCE. Синтаксический элемент потока битов, содержащий закодированные данные для единственного аудио канала. single_channel_element() в основном состоит из UsacCoreCoderData(), содержащего данные или для FD или для LPD базового кодера. В случае, если SBR является активным, UsacSingleChannelElement также содержит данные SBR.

UsacChannelPairEIement() Сокращение - CPE. Синтаксический элемент полезных данных потока битов, содержащий данные для пары каналов. Пара каналов может быть достигнута или с помощью передачи двух дискретных каналов или с помощью одного дискретного канала и связанных полезных данных Mps212. Это сигнализируется посредством stereoConfiglndex. UsacChannelPairElement также содержит данные SBR в случае, если SBR является активным.

UsacLfeElement() Сокращение - LFE. Синтаксический элемент, который содержит канал расширения низкой частоты осуществления выборки. LFEs всегда кодируются, используя элемент fd_channel_stream().

UsacExtElement(), Синтаксический элемент, который содержит полезные данные расширения. Длина элемента расширения или сигнализируется как длина по умолчанию в конфигурации (USACExtElementConfig()) или сигнализируется в UsacExtElement() непосредственно. Если присутствует, полезные данные расширения имеют тип usacExtElementType, как сигнализируется в этой конфигурации.

usacIndependencyFlag указывает, может ли текущий UsacFrame() быть декодирован полностью без знания информации от предыдущих кадров согласно Таблице ниже

Таблица
Смысл usacIndependencyFlag значение usacIndependencyFlag смысл 0 Декодирование данных, переданных в UsacFrame(), может требовать доступа к предыдущему UsacFrame() 1 Декодирование данных, переданных в UsacFrame(), возможно без доступа к предыдущему UsacFrame() Замечание: Пожалуйста, обратитесь к X.Y для рекомендаций относительно использования usacIndependencyFlag

usacExtElementUseDefaultLength указывает, соответствует ли длина элемента расширения значению usacExtElementDefaultLength, которое было определено в UsacExtElementConfig().

usacExtElementPayloadLength должен содержать длину элемента расширения в байтах. Это значение должно только быть явно передано в потоке битов, если длина элемента расширения в существующем блоке доступа отклоняется от значения по умолчанию, usacExtEIement-DefaultLength.

usacExtElementStart Указывает, начинает ли текущий usacExtElementSegmentData блок данных.

usacExtElementStop Указывает, заканчивает ли текущий usacExtElementSegmentData блок данных.

usacExtElementSegmentData Конкатенация всех usacExtElementSegmentData из UsacExtElement() последовательных кадров USAC, начинающихся с UsacExtElement() с usacExtElementStart==1 вплоть до и включая UsacExtElement() с usacExtElementStop == 1, формирует один блок данных. В случае, если полный блок данных содержится в одном UsacExtElement(), usacExtElementStart и usacExtElementStop должны оба быть установлены в 1. Блоки данных интерпретируются в качестве выровненных по границе байта полезных данных расширения в зависимости от usacExtElementType согласно следующей Таблице:

fill_byte Октет битов, которые могут использоваться, чтобы дополнить поток битов битами, которые не переносят информации. Точная битовая комбинация, используемая для fill_byte, должна быть равна '10100101'.

Вспомогательные элементы

nrCoreCoderChannels В контексте элемента пары каналов эта переменная указывает количество каналов базового кодера, которые формируют основу для кодирования стерео. В зависимости от значения stereoConfiglndex это значение должно быть 1 или 2.

nrSbrChannels В контексте элемента пары каналов эта переменная указывает количество каналов, к которым применяется обработка SBR. В зависимости от значения stereoConfiglndex это значение должно быть 1 или 2.

Вспомогательные полезные данные для USAC

Термины и определения

UsacCoreCoderData() Этот блок данных содержит аудио данные базового кодера. Элемент полезных данных содержит данные для одного или двух каналов базового кодера, для или FD или для LPD режима. Конкретный режим сигнализируется для каждого канала в начале элемента.

StereoCoreToolInfo() Вся относящаяся к стерео информация захватывается в этом элементе. Он имеет дело с многочисленными зависимостями полей битов в режимы кодирования стерео.

Вспомогательные элементы

commonCoreMode в CPE этот флаг указывает, используют ли оба закодированных канала базового кодера один и тот же режим.

Mps212Data() Этот блок данных содержит полезные данные для модуля стерео Mps212. Присутствие этих данных зависит от stereoConfiglndex.

common_window указывает, используют ли канал 0 и канал 1 из CPE идентичные параметры окна.

common_tw указывает, используют ли канал 0 и канал 1 из CPE использует идентичные параметры для MDCT с деформированной шкалой времени.

Декодирование UsacFrame()

Один UsacFrame() формирует один блок доступа потока битов USAC. Каждый UsacFrame декодирует в 768, 1024, 2048 или 4096 выходных выборок согласно outputFrameLength, определенному из Таблицы Х.

Первый бит в UsacFrame() является usacIndependencyFlag, который определяет, может ли заданный кадр быть декодирован без какого-нибудь знания предыдущего кадра. Если usacIndependencyFlag установлен в 0, то зависимости к предыдущему кадру могут присутствовать в полезных данных текущего кадра.

UsacFrame() далее составлен из одного или более синтаксических элементов, которые должны появиться в потоке битов в том же самом порядке, что их соответствующие элементы конфигурации в UsacDecoderConfig(). Позиция каждого элемента в последовательности всех элементов индексирована посредством elemldx. Для каждого элемента должна использоваться соответствующая конфигурация, как передано в UsacDecoderConfig(), этого экземпляра, то есть с тем же самым elemldx.

Эти синтаксические элементы имеют один из четырех типов, которые перечислены в Таблице Х. Тип каждого из этих элементов определен с помощью usacElementType. Могут быть множественные элементы одного и того же типа. Элементы, появляющиеся в одной и той же позиции elemldx в различных кадрах, должны принадлежать одному и тому же потоку.

Если эти полезные данные потока битов должны быть переданы по каналу с постоянной скоростью передачи, то они могут включать в себя элемент полезных данных расширения с usacExtEIementType равным ID_EXT_ELE_FILL, чтобы настроить мгновенную частоту следования в битах. В этом случае примером кодированного сигнала стерео является:

Декодирование UsacSingleChannelEIement()

Простая структура UsacSingleChannelEIement() состоит из одного экземпляра элемента UsacCoreCoderData() с nrCoreCoderChannels, установленным в 1. В зависимости от sbrRatioIndex этого элемента элемент UsacSbrData() следует с nrSbrChannels, также установленным в 1.

Декодирование UsacExtEIement()

Структуры UsacExtEIement() в потоке битов могут быть декодированы или пропущены декодером USAC. Каждое расширение идентифицировано посредством usacExtElementType, переданным в UsacExtElementConfig(), ассоциированных с UsacExtElement(). Для каждого usacExtElementType может присутствовать конкретный декодер.

Если декодер для этого расширения доступен для декодера USAC, то полезные данные расширения отправляются декодеру расширения немедленно после того, как UsacExtEIement() был синтаксически разобран декодером USAC.

Если декодер для расширения не доступен для декодера USAC, минимум структуры предоставляется в пределах потока битов, так, чтобы расширение могло быть проигнорировано декодером USAC.

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

Полезные данные расширения, которые охватывают один или более UsacFrame(), могут быть фрагментированы и их полезные данные распределены среди нескольких UsacFrame(). В этом случае флаг usacExtElementPayloadFrag установлен в 1, и декодер должен собрать все фрагменты из UsacFrame() с usacExtElementStart, установленным в 1 вплоть до и включая UsacFrame() с usacExtElementStop, установленным в 1. Когда usacExtElementStop установлен в 1, то рассматривают, что расширение является полным и передается к декодеру расширения.

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

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

Каждый UsacExtElement() должен соответствовать требованиям, следующим из использования usaclndependencyFlag. Более точно, если usacIndependencyFlag установлен (== 1), UsacExtElement() должен быть декодируемым без знания предыдущего кадра (и полезных данных расширения, которые могут содержаться в нем).

Процесс декодирования

stereoConfiglndex, который передается в UsacChannelPairElementConfig(), определяет точный тип кодирования стерео, которое применяется в заданном CPE. В зависимости от этого типа стерео кодирования или один или два канала базового кодера фактически передаются в потоке битов, и переменная nrCoreCoderChannels должна быть установлена соответственно. Синтаксический элемент UsacCoreCoderData() затем обеспечивает данные для одного или двух каналов базового кодера.

Аналогично, могут быть данные, доступные для одного или двух каналов в зависимости от типа кодирования стерео и использования eSBR (то есть, если sbrRatioIndex > 0). Значение nrSbrChannels должно быть установлено соответственно и элемент UsacSbrData() синтаксиса обеспечивает eSBR данные для одного или двух каналов.

Наконец Mps212Data() передается в зависимости от значения stereoConfiglndex. Канальный элемент UsacLfeEIement() расширения низкой частоты (LFE)

Обзор

Чтобы поддерживать регулярную структуру в декодере, UsacLfeElement() определен как стандартный элемент fd_channel_stream (0,0,0,0, x), то есть, он равен UsacCoreCoderData(), используя кодер частотной области. Таким образом, декодирование может быть сделано, используя стандартную процедуру для декодирования элемента UsacCoreCoderData().

Чтобы приспособить большую скорость передачи в битах и аппаратно- эффективную реализацию декодера LFE, однако, несколько ограничений применяются к вариантам, используемым для кодирования этого элемента:

- поле window_sequence всегда устанавливается в 0 (ONLY_LONG_SEQUENCE)

- Только самые низкие 24 спектральных коэффициентов любого LFE могут быть отличными от нуля

- временное формирование шума не используется, то есть tns_data_present установлен в 0

- деформированная шкала времени не является активной

- заполнение шумом не применяется

UsacCoreCoderData()

UsacCoreCoderData() содержит всю информацию для декодирования одного или двух каналов базового кодера. Порядок декодирования:

- получить core_mode[] для каждого канала

- в случае двух базовых кодированных каналов (nrChannels==2), синтаксически разобрать StereoCoreToolInfoO и определить все относящиеся к стерео параметры

- В зависимости от сигнализированного core_modes передать lpd_channel_stream() или fd_channel_stream() для каждого канала

Как можно видеть из вышеупомянутого списка, декодирование одного канала базового кодера (nrChannels == 1) приводит к получению бита core_mode, с последующим одним lpd_channel_stream или fd_channel_stream, в зависимости от core_mode.

В случаях двух каналов базового кодера некоторая избыточность сигнализации между каналами может использоваться, в частности, если core_mode обоих каналов равно 0. См. 6.2. X (Декодирование StereoCoreToolInfoO) для более подробной информации

StereoCoreToolInfo()

StereoCoreToolInfo() позволяет эффективно кодировать параметры, значения которых могут быть совместно использованы в каналах базового кодера CPE в случае, если оба канала закодированы в режиме FD (core_mode [0, 1] == 0). В частности, следующие элементы данных совместно используются, когда подходящий флаг в потоке битов установлен в 1.

Если соответствующий флаг не установлен, то элементы данных передаются индивидуально для каждого канала базового кодера или в StereoCoreToolInfo() (max_sfb, max_sfb1) или в fd_channel_stream(), который следует за StereoCoreToolInfo() в элементе UsacCoreCoderData().

В случае common_window == 1 StereoCoreToolInfo() также содержит информацию о кодировании стерео M/S и данных комплексного предсказания в области MDCT (см. 7.7.2).

UsacSbrData() Этот блок данных содержит полезные данные для расширения полосы частот SBR для одного или двух каналов. Присутствие этих данных зависит от sbrRatioIndex.

Sbrlnfo() Этот элемент содержит параметры управления SBR, которые не требуют сброса декодера при изменении.

SbrHeader() Этот элемент содержит данные заголовка SBR с параметрами конфигурации SBR, это типично, не изменяются в течение продолжительности потока битов.

Полезные данные SBR для USAC

В USAC полезные данные SBR передаются в UsacSbrData(), который является неотъемлемой частью каждого элемента единственного канала или элемента пары каналов. UsacSbrData() следует сразу за UsacCoreCoderData(). Нет полезных данных SBR для каналов LFE.

numSlots количество временных слотов в кадре Mps212Data.

Хотя немного аспектов было описано в контексте устройства, ясно, что эти аспекты также представляют описание соответствующего способа, где блок или устройство соответствуют этапу способа или признаку этапа способа. Аналогично, аспекты, описанные в контексте этапа способа, также представляют описание соответствующего блока или элемента или признака соответствующего устройства.

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

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

Сигнал кодированного аудио может быть передан через проводной или беспроводный носитель передачи или может быть сохранен на машиночитаемом носителе или на невременном носителе данных.

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

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

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

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

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

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

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

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

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

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

1. Декодер для декодирования потока (12) битов, содержащего блок (28) конфигурации и последовательность кадров (20), соответственно представляющие последовательные периоды времени аудио содержимого (10), при этом последовательность кадров (20) является композицией из N последовательностей элементов (22) кадра, где каждый элемент (22) кадра имеет соответствующий один из множества типов элемента так, что каждый кадр (20) содержит один элемент (22) кадра из N последовательностей элементов (22) кадра, соответственно, и для каждой последовательности элементов (22) кадра элементы (22) кадра имеют равный тип элемента друг относительно друга,
при этом декодер сконфигурирован, чтобы синтаксически разбирать поток (12) битов и восстанавливать аудио содержимое на основании поднабора упомянутых последовательностей элементов кадра и чтобы, в отношении по меньшей мере одной из упомянутых последовательностей элементов (22) кадра, не принадлежащих поднабору последовательностей элементов кадра, считывать из блока (28) конфигурации, для по меньшей мере одной из упомянутых последовательностей элементов (22) кадра, информацию (60) длины полезных данных по умолчанию в отношении длины полезных данных по умолчанию, и
для каждого элемента (22) кадра из упомянутой по меньшей мере одной из последовательностей элементов (22) кадра считывать информацию длины из потока (12) битов, причем считывание информации (58) длины содержит, для по меньшей мере поднабора элементов (22) кадра из упомянутой по меньшей мере одной из последовательностей элементов (22) кадра, считывание флага (64) длины полезных данных по умолчанию с последующим, если флаг (64) длины полезных данных по умолчанию не установлен, считыванием значения (66) длины полезных данных,
пропускать, при синтаксическом разборе потока (12) битов, любого элемента кадра из по меньшей мере одной из упомянутых последовательностей элементов (22) кадра, флаг (64) длины полезных данных расширения по умолчанию которого установлен, используя длину полезных данных по умолчанию в качестве длины интервала пропуска, и любого элемента кадра из упомянутых по меньшей мере одной из последовательностей элементов (22) кадра, флаг (64) длины полезных данных расширения по умолчанию которого не установлен, используя длину полезных данных, соответствующую значению (66) длины полезных данных, в качестве длины интервала пропуска.

2. Декодер по п. 1, в котором декодер сконфигурирован для, при считывании блока (28) конфигурации, считывания поля (50), указывающего количество элементов N, и части (52) синтаксиса индикации типа, указывающей, для каждой позиции элемента из последовательности из N позиций элемента, тип элемента из множества типов элемента, при этом декодер сконфигурирован, чтобы декодировать каждый кадр (20) посредством декодирования каждого элемента (22) кадра в соответствии с типом элемента, указанным частью синтаксиса индикации типа, для соответствующей позиции элемента, в которой соответствующий элемент кадра позиционирован в пределах последовательности из N элементов (22) кадра из соответствующего кадра (20) в потоке (12) битов.

3. Декодер по п. 2, в котором декодер сконфигурирован, чтобы считывать последовательность из N элементов (54) синтаксиса из части (52) синтаксиса индикации типа, причем каждый элемент указывает тип элемента для соответствующей позиции элемента, в которой соответствующий элемент синтаксиса позиционирован в последовательности из N элементов синтаксиса.

4. Декодер по п. 1, в котором декодер сконфигурирован, чтобы считывать элемент (56) конфигурации для каждой последовательности из элементов кадра из блока (28) конфигурации, причем каждый элемент конфигурации содержит информацию конфигурации для соответствующей последовательности элементов кадра, при этом декодер сконфигурирован, чтобы, при восстановлении аудио содержимого на основании поднабора последовательностей элементов кадра, декодировать каждый элемент (22) кадра упомянутого поднабора последовательностей элементов кадра, используя информацию конфигурации соответствующего элемента конфигурации.

5. Декодер по п. 4, в котором часть (52) синтаксиса индикации типа содержит последовательность из N элементов (54) синтаксиса, причем каждый элемент (54) синтаксиса указывает тип элемента для соответствующей позиции элемента, в которой соответствующий элемент (54) синтаксиса позиционирован в части (52) синтаксиса индикации типа, при этом декодер сконфигурирован, чтобы считывать элементы (56) конфигурации и элементы (54) синтаксиса из потока (12) битов поочередно.

6. Декодер по п. 1, в котором декодер сконфигурирован, чтобы, при считывании информации (58) длины любого элемента кадра из упомянутой по меньшей мере одной последовательности элементов кадра, считывать флаг (70) присутствия полезных данных расширения из потока (12) битов, выполнять проверку, установлен ли флаг (70) присутствия полезных данных расширения, и, если флаг (70) присутствия полезных данных расширения не установлен, прекращать считывать соответствующий элемент (22b) кадра и возобновлять считывание другого элемента (22) кадра из текущего кадра (20) или элемента кадра последующего кадра (20), и если флаг (70) присутствия полезных данных установлен, продолжать считывание флага длины (64) полезных данных по умолчанию с последующим, если флаг (64) длины полезных данных по умолчанию не установлен, значением (66) длины полезных данных из потока (12) битов и с упомянутым пропуском.

7. Декодер по п. 1, в котором
декодер сконфигурирован, чтобы, при считывании информации (60) длины полезных данных по умолчанию,
считывать флаг присутствия длины полезных данных по умолчанию из потока (12) битов,
проверять, установлен ли флаг присутствия длины полезных данных по умолчанию,
если флаг присутствия длины полезных данных по умолчанию не установлен, устанавливать длину полезных данных расширения по умолчанию равной нулю, и
если флаг присутствия длины полезных данных по умолчанию установлен, явно считывать длину полезных данных расширения по умолчанию из битового потока.

8. Декодер по п. 1, в котором
декодер сконфигурирован, чтобы, при считывании блока (28) конфигурации, для каждой последовательности элементов кадра упомянутой по меньшей мере одной последовательности элементов кадра,
считывать элемент (56) конфигурации, содержащий информацию конфигурации для типа элемента расширения из потока (12) битов, при этом информация конфигурации содержит поле (72) типа элемента расширения, указывающее тип данных полезных данных из множества типов данных полезных данных.

9. Декодер по п. 8, в котором множество типов данных полезных данных содержит тип многоканальной побочной информации и тип многообъектной побочной информации кодирования,
декодер сконфигурирован, чтобы, при считывании блока (28) конфигурации, для каждой из упомянутой по меньшей мере одной последовательности элементов кадра,
если поле (72) типа элемента расширения указывает тип многоканальной побочной информации, считывать данные (74) конфигурации многоканальной побочной информации в качестве части информации конфигурации из потока данных (12), и
если поле (72) типа элемента расширения указывает тип многообъектной побочной информации, считывать данные (74) конфигурации многообъектной побочной информации в качестве части информации конфигурации из потока данных, и
декодер сконфигурирован, чтобы при декодировании каждого кадра
декодировать элементы кадра любой из упомянутых по меньшей мере одной последовательности элементов кадра, для которой тип элемента расширения элемента (56) конфигурации указывает тип многоканальной побочной информации, посредством конфигурирования многоканального декодера (44е), используя данные (74) конфигурации многоканальной побочной информации, и подачи на таким образом сконфигурированный многоканальный декодер (44е) данных (68) полезных данных из элементов (22b) кадра упомянутой соответствующей последовательности элементов кадра в качестве многоканальной побочной информации и
декодировать элементы кадра любой из упомянутых по меньшей мере одной последовательности элементов кадра, для которой тип элемента расширения элемента (56) конфигурации указывает тип многообъектной побочной информации, посредством конфигурирования многообъектного декодера (44d), используя данные (74) конфигурации многообъектной побочной информации, и подачи на таким образом сконфигурированный многообъектный декодер (44d) данных (68) полезных данных из элементов (22) кадра упомянутой соответствующей последовательности элементов кадра.

10. Декодер по п. 8, в котором декодер сконфигурирован, чтобы, для любой из упомянутых по меньшей мере одной последовательности элементов кадра,
считывать поле (76) длины данных конфигурации из потока (12) битов в качестве части информации конфигурации элемента конфигурации для соответствующей последовательности элементов кадра,
проверять, принадлежит ли тип данных полезных данных, указанный полем (72) типа элемента расширения из информации конфигурации этого элемента конфигурации для соответствующей последовательности элементов кадра, заранее определенному набору типов данных полезных данных, являющихся поднабором множества типов данных полезных данных,
если тип данных полезных данных, указанный полем (72) типа элемента расширения из информации конфигурации этого элемента конфигурации для соответствующей последовательности элементов кадра, принадлежит заранее определенному набору типов данных полезных данных,
считывать зависимые от данных полезных данных данные (74) конфигурации в качестве части информации конфигурации элемента конфигурации для соответствующей последовательности элементов кадра из потока (12) данных, и
декодировать элементы кадра упомянутой последовательности элементов кадра в кадрах (20), используя упомянутые зависимые от данных полезных данных данные (74) конфигурации, и
если тип данных полезных данных, указанный полем (72) типа элемента расширения из информации конфигурации элемента конфигурации для соответствующей последовательности элементов кадра, не принадлежит заранее определенному набору типов данных полезных данных,
пропускать зависимые от данных полезных данных данные (74) конфигурации, используя длину данных конфигурации, и
пропускать элементы кадра упомянутой соответствующей последовательности элементов кадра в кадрах (20), используя информацию (58) длины в них.

11. Декодер по п. 1, в котором
декодер сконфигурирован, чтобы, при считывании блока (28) конфигурации, для каждой из упомянутых по меньшей мере одной последовательности элементов кадра,
считывать элемент (56) конфигурации, содержащий информацию конфигурации для типа элемента расширения из потока (12) битов, при этом информация конфигурации содержит флаг (78) использования фрагментации, и
декодер сконфигурирован, чтобы, при считывании элементов (22) кадра любой последовательности элементов кадра, для которой флаг (78) использования фрагментации из элемента конфигурации установлен,
считывать информацию фрагмента из потока битов и
использовать информацию фрагмента, чтобы поместить данные полезных данных этих элементов кадра последовательных кадров вместе.

12. Декодер по п. 1, в котором декодер сконфигурирован таким образом, что декодер восстанавливает аудиосигнал из элементов (22) кадра одной из поднабора упомянутых последовательностей элементов кадра, которые имеют тип элемента единственного канала.

13. Декодер по п. 1, в котором декодер сконфигурирован таким образом, что декодер восстанавливает аудиосигнал из элементов (22) кадра одной из поднабора упомянутых последовательностей элементов кадра, которые имеют тип элемента пары каналов.

14. Декодер по п. 1, в котором декодер сконфигурирован, чтобы использовать один и тот же код с переменной длиной кода, чтобы считывать информацию (80) длины, поле (72) типа элемента расширения и поле (76) длины данных конфигурации.

15. Кодер для кодирования аудио содержимого в поток битов, причем кодер сконфигурирован, чтобы
кодировать последовательные периоды (18) времени аудио содержимого (10) в последовательность кадров (20), соответственно представляющих последовательные периоды (18) времени аудио содержимого (10), таким образом, что последовательность кадров (20) является композицией из N последовательностей элементов (22) кадра, причем каждый элемент (22) кадра является соответствующим одним из множества типов элемента так, что каждый кадр (20) содержит один элемент (22) кадра из N последовательностей элементов (22) кадра, соответственно, и для каждой последовательности элементов (22) кадра эти элементы (22) кадра имеют равный тип элемента относительно друг друга,
кодировать в поток (12) битов блок (28) конфигурации, который содержит, для по меньшей мере одной из последовательностей элементов (22) кадра, информацию (60) длины полезных данных по умолчанию в отношении длины полезных данных по умолчанию и
кодировать каждый элемент (22) кадра из упомянутых по меньшей мере одной из последовательностей элементов (22) кадра в поток битов (12) таким образом, что он содержит информацию (58) длины, содержащую, для по меньшей мере поднабора элементов (22) кадра из по меньшей мере одной из последовательностей элементов (22) кадра, флаг (64) длины полезных данных по умолчанию, с последующим, если флаг длины (64) полезных данных по умолчанию не установлен, значением (66) длины полезных данных, и что любой элемент кадра по меньшей мере одной из последовательностей элементов (22) кадра, флаг (64) длины полезных данных расширения по умолчанию которого установлен, имеет длину полезных данных по умолчанию, и любой элемент кадра по меньшей мере одной из последовательностей элементов (22) кадра, флаг (64) длины полезных данных расширения по умолчанию которого не установлен, имеет длину полезных данных, соответствующую значению (66) длины полезных данных.

16. Способ декодирования потока (12) битов, содержащего блок (28) конфигурации и последовательность кадров (20), соответственно представляющих последовательные периоды времени аудио содержимого, в котором
последовательность кадров (20) является композицией из N последовательностей элементов (22) кадра, где каждый элемент (22) кадра имеет соответствующий один из множества типов элемента так, что каждый кадр (20) содержит один элемент (22) кадра из N последовательностей элементов (22) кадра, соответственно, и для каждой последовательности элементов (22) кадра элементы (22) кадра имеют равный тип элемента друг относительно друга,
при этом способ содержит синтаксический разбор потока (12) битов и восстановление аудио содержимого на основании поднабора упомянутых последовательностей элементов кадра и, в отношении по меньшей мере одной из упомянутых последовательностей элементов (22) кадра, не принадлежащих поднабору последовательностей элементов кадра,
считывание из блока (28) конфигурации, для по меньшей мере одной из упомянутых последовательностей элементов (22) кадра, информации (60) длины полезных данных по умолчанию в отношении длины полезных данных по умолчанию, и,
для каждого элемента (22) кадра из упомянутой по меньшей мере одной из последовательностей элементов (22) кадра, считывание информации длины из потока (12) битов, причем считывание информации (58) длины содержит, для по меньшей мере поднабора элементов (22) кадра из упомянутой по меньшей мере одной из последовательностей элементов (22) кадра, считывание флага (64) длины полезных данных по умолчанию с последующим, если флаг (64) длины полезных данных по умолчанию не установлен, считыванием значения (66) длины полезных данных, пропуск, при синтаксическом разборе потока (12) битов, любого элемента кадра из по меньшей мере одной из упомянутых последовательностей элементов (22) кадра, флаг (64) длины полезных данных расширения по умолчанию которого установлен, используя длину полезных данных по умолчанию в качестве длины интервала пропуска, и любого элемента кадра из упомянутых по меньшей мере одной из последовательностей элементов (22) кадра, флаг (64) длины полезных данных расширения по умолчанию которого не установлен, используя длину полезных данных, соответствующую значению (66) длины полезных данных, в качестве длины интервала пропуска.

17. Способ кодирования аудио содержимого в поток битов, причем способ содержит
кодирование последовательных периодов (18) времени из аудио содержимого (10) в последовательность кадров (20), соответственно представляющих последовательные периоды (18) времени из аудио содержимого (10), таким образом, что последовательность кадров (20) является композицией из N последовательностей элементов (22) кадра, где каждый элемент (22) кадра является соответствующим одним из множества типов элемента так, чтобы каждый кадр (20) содержал один элемент (22) кадра из N последовательностей элементов (22) кадра, соответственно, и для каждой последовательности элементов (22) кадра эти элементы (22) кадра имели равный тип элемента относительно друг друга,
кодирование в поток (12) битов блока (28) конфигурации, который содержит, для по меньшей мере одной из последовательностей элементов (22) кадра, информацию (60) длины полезных данных по умолчанию в отношении длины полезных данных по умолчанию, и
кодирование каждого элемента (22) кадра из по меньшей мере одной из последовательностей элементов (22) кадра в поток битов (12) таким образом, что он содержит информацию (58) длины, содержащую, для по меньшей мере поднабора элементов (22) кадра из по меньшей мере одной из последовательностей элементов (22) кадра, флаг (64) длины полезных данных по умолчанию, с последующим, если флаг длины (64) полезных данных по умолчанию не установлен, значением (66) длины полезных данных, и что любой элемент кадра упомянутой по меньшей мере одной из последовательностей элементов (22) кадра, флаг (64) длины полезных данных расширения по умолчанию которого установлен, имеет длину полезных данных по умолчанию, и любой элемент кадра из по меньшей мере одной из последовательностей элементов (22) кадра, флаг (64) длины полезных данных расширения по умолчанию которого не установлен, имеет длину полезных данных, соответствующую значению (66) длины полезных данных.

18. Считываемый компьютером носитель, содержащий компьютерную программу для выполнения, при выполнении на компьютере, способа по п. 16.

19. Считываемый компьютером носитель, содержащий компьютерную программу для выполнения, при выполнении на компьютере, способа по п. 17.