СООБЩЕНИЕ ХАРАКТЕРИСТИК РАБОЧЕЙ ТОЧКИ НЕСКОЛЬКИХ ИЗОБРАЖЕНИЙ ВИДЕО (MVC)
SIGNALLING CHARACTERISTICS OF MULTIVIEW VIDEO CODING (MVC) OPERATION POINT

[0001] Настоящая заявка на патент испрашивает приоритет предварительных заявок США № 61/232272, поданной 7 августа 2009 года, № 61/248738, поданной 5 октября 2009 года, и № 61/266861, поданной 4 декабря 2009 года, все содержимое которых включено в настоящий документ посредством ссылки в их соответствующей полноте.
ОБЛАСТЬ ТЕХНИКИ
[0002] Это раскрытие изобретения относится к транспортированию кодированных видеоданных.
УРОВЕНЬ ТЕХНИКИ
[0003] Возможности цифрового видео могут быть встроены в широкий диапазон устройств, в том числе цифровые телевизоры, системы цифрового прямого широковещания, беспроводные широковещательные системы, карманные персональные компьютеры (PDA), портативные или настольные компьютеры, цифровые камеры, цифровые записывающие устройства, проигрыватели цифровых медиаданных, устройство видеоигр, видеоигровые консоли, сотовые или спутниковые радиотелефоны, устройства видеоконференции и тому подобные. Устройства цифрового видео реализуют способы сжатия видео, такие как описанные в стандартах, заданных посредством MPEG-2, MPEG-4, ITU-T H.263 или ITU-T H.264/MPEG-4, Часть 10, Улучшенного кодирования видео (AVC) и расширениях этих стандартов, для передачи и приема цифровой видеоинформации более эффективно.
[0004] Способы сжатия видео выполняют пространственное предсказание и/или временное предсказание для снижения или удаления избыточности, свойственной видеопоследовательностям. Для блочного кодирования видео, видеокадр или слайс (срез) могут быть разделены на макроблоки. Каждый макроблок может быть дополнительно разделен. Макроблоки в кодированном посредством внутреннего кодирования (I) кадре или слайсе (срезе) кодируют с помощью пространственного предсказания с учетом соседних макроблоков. Макроблоки в кодированном посредством внешнего кодирования (P или B) кадре или слайсе могут использовать пространственное предсказание с учетом соседних макроблоков в том же кадре или слайсе или временное предсказание с учетом других опорных кадров.
[0005] После того, как видеоданные были закодированы, видеоданные могут быть пакетированы мультиплексором для передачи или хранения. MPEG-2 включает в себя раздел "Системы", который задает транспортный уровень для множества стандартов кодирования видео. Системы транспортного уровня MPEG-2 могут быть использованы видеокодерами MPEG-2, или другими видеокодерами, согласующимися с разными стандартами кодирования видео. Например, MPEG-4 предписывает другие способы кодирования и декодирования, нежели MPEG-2, но видеокодеры, реализующие способы стандарта MPEG-4, все же могут использовать способы транспортного уровня MPEG-2.
[0006] В общем, ссылки на "Системы MPEG-2" в этом раскрытии изобретения относятся к транспортному уровню видеоданных, предписанному посредством MPEG-2. Транспортный уровень, предписанный посредством MPEG-2, в этом раскрытии изобретения также называется как "транспортный поток MPEG-2" или просто "транспортный поток". Аналогично транспортный уровень систем MPEG-2 также включает в себя программные потоки. Транспортные потоки и программные потоки, в общем, включают в себя разные форматы для доставки подобных данных, где транспортный поток содержит одну или более "программ", включающих в себя как аудио, так и видеоданные, в то время как программные потоки включают в себя одну программу, включающую в себя как аудио, так и видеоданные.
[0007] Были предприняты усилия для разработки новых стандартов кодирования видео на основе H.264/AVC. Одним таким стандартом является стандарт масштабируемого кодирования видео (SVC), который является масштабируемым расширением для H.264/AVC. Другим стандартом является кодирование нескольких изображений видео, который становится расширением на несколько изображений для H.264/AVC. Спецификация Системы MPEG-2 описывает то, как потоки сжатых мультимедийных (видео и аудио) данных могут быть мультиплексированы вместе с другими данными для образования единого потока данных, подходящего для передачи и хранения. Самая последняя спецификация систем MPEG-2 указана в "Information Technology-Generic Coding of Moving Pictures and Associated Audio: Systems, Recommendation H.222.0; International Organisation for Standardisation, ISO/IEC JTC1/SC29/WG11; Coding of Moving Pictures and Associated Audio", Май 2006. Недавно спроектированный группой MPEG стандарт транспортирования MVC через Системы MPEG-2 и последней версией этой спецификации является "Study of ISO/IEC 13818-1:2007/FPDAM4 Transport of MVC", MPEG doc. N10572, MPEG of ISO/IEC JTC1/SC29/WG11, Мауи, Гавайи, США, апрель 2009.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[0008] В общем, это раскрытие изобретения описывает способы для улучшения кодирования нескольких изображений видео в Системах MPEG-2 (Экспертная группа по кинематографии). В частности, способы этого раскрытия изобретения направлены на структуру данных для рабочей точки потока битов Системы MPEG-2, где структура данных сообщает способность воспроизведения для принимающего устройства, способность декодирования для принимающего устройства и в некоторых примерах битовую скорость для рабочей точки. Структура данных может соответствовать дескриптору рабочей точки, который включен в поток битов Системы MPEG-2.
[0009] Для того, чтобы правильно декодировать и отображать видеоданные рабочей точки, принимающее устройство должно удовлетворять свойствам, описанным способностью воспроизведения и способностью декодирования, сообщенным в структуре данных. Потоки битов Системы MPEG-2 могут включать в себя множество рабочих точек, которые соответствуют различным изображениям программы. Использование разных рабочих точек для программы дает возможность различным клиентским устройствам выполнять адаптацию. То есть клиентские устройства с разными способностями воспроизведения и декодирования могут извлекать изображения из одной и той же программы для отображения двумерных или трехмерных видеоданных. Клиентские устройства могут также согласовываться с серверным устройством для выборки данных и изменяющейся битовой скоростью, чтобы адаптироваться для транспорта медиаданных с различными характеристиками полосы частот.
[0010] В одном примере способ включает в себя конструирование с помощью исходного устройства, структуры данных, соответствующей рабочей точке кодирования нескольких изображений видео (MVC) потока битов стандарта Системы MPEG-2, в котором структура данных сообщает значение способности воспроизведения, которое описывает способность воспроизведения, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, значение способности декодирования, которое описывает способность декодирования, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, и значение битовой скорости, которое описывает битовую скорость рабочей точки MVC и в котором структура данных включена как часть потока битов, и вывод потока битов, содержащего структуру данных.
[0011] В другом примере устройство включает в себя мультиплексор, который конструирует структуру данных, соответствующую рабочей точке MVC потока битов стандарта Системы MPEG-2, в котором структура данных сообщает значение способности воспроизведения, которое описывает способность воспроизведения, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, значение способности декодирования, которое описывает способность декодирования, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, и значение битовой скорости, которое описывает битовую скорость рабочей точки MVC и которое включает в себя структуру данных как часть потока битов, и выходной интерфейс, который выводит поток битов, содержащий структуру данных.
[0012] В другом примере устройство включает в себя средство для конструирования структуры данных, соответствующей рабочей точке MVC потока битов стандарта Системы MPEG-2, в котором структура данных сообщает значение способности воспроизведения, которое описывает способность воспроизведения, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, значение способности декодирования, которое описывает способность декодирования, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, и значение битовой скорости, которое описывает битовую скорость рабочей точки MVC, и причем структура данных включена как часть потока битов, и средство для вывода потока битов, содержащего структуру данных.
[0013] В другом примере считываемый компьютером носитель информации содержит инструкции, которые заставляют процессор исходного устройства конструировать структуру данных, соответствующую рабочей точке MVC потока битов стандарта Системы MPEG-2, в котором структура данных сообщает значение способности воспроизведения, которое описывает способность воспроизведения, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, значение способности декодирования, которое описывает способность декодирования, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, и значение битовой скорости, которое описывает битовую скорость рабочей точки MVC, и при этом структура данных включена как часть потока битов, и заставляют выходной интерфейс выводить поток битов, содержащий структуру данных.
[0014] В другом примере способ включает в себя этапы, на которых принимают с помощью целевого устройства структуру данных, соответствующую рабочей точке MVC потока битов стандарта Системы MPEG-2 (Экспертная группа по кинематографии), в котором структура данных сообщает значение способности воспроизведения, которое описывает способность воспроизведения, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, значение способности декодирования, которое описывает способность декодирования, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, и значение битовой скорости, которое описывает битовую скорость рабочей точки MVC, определяют способен ли видеодекодер целевого устройства декодировать изображения, соответствующие рабочей точке MVC, на основе способности декодирования, сообщенной структурой данных, определяют способно ли целевое устройство воспроизводить изображения, соответствующие рабочей точке MVC, на основе способности воспроизведения, сообщенной структурой данных, и отправляют изображения, соответствующие рабочей точке MVC, на видеодекодер целевого устройства, когда определено, что видеодекодер целевого устройства способен декодировать и воспроизводить изображения, соответствующие рабочей точке MVC.
[0015] В другом примере устройство содержит входной интерфейс, выполненный с возможностью приема структуры данных, соответствующей рабочей точке MVC потока битов стандарта Системы MPEG-2, в котором структура данных сообщает значение способности воспроизведения, которое описывает способность воспроизведения, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, значение способности декодирования, которое описывает способность декодирования, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, и значение битовой скорости, которое описывает битовую скорость рабочей точки MVC, видеодекодер, выполненный с возможностью декодирования видеоданных; и демультиплексор, выполненный с возможностью определения того, способен ли видеодекодер декодировать изображения, соответствующие рабочей точке MVC, на основе способности декодирования, сообщенной структурой данных, определения того, способно ли устройство воспроизводить изображения, соответствующие рабочей точке MVC, на основе способности воспроизведения, сообщенной структурой данных, и отправки изображений, соответствующих рабочей точке MVC, на видеодекодер, когда определено, что видеодекодер способен декодировать и воспроизводить изображения, соответствующие рабочей точке MVC.
[0016] В другом примере устройство включает в себя средство для приема структуры данных, соответствующей рабочей точке MVC потока битов стандарта Системы MPEG-2, в котором структура данных сообщает значение способности воспроизведения, которое описывает способность воспроизведения, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, значение способности декодирования, которое описывает способность декодирования, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, и значение битовой скорости, которое описывает битовую скорость рабочей точки MVC, средство для определения того, способен ли видеодекодер устройства декодировать изображения, соответствующие рабочей точке MVC, на основе способности декодирования, сообщенной структурой данных, средство для определения того, способно ли устройство воспроизводить изображения, соответствующие рабочей точке MVC, на основе способности воспроизведения, сообщенной структурой данных, и средство для отправки изображений, соответствующих рабочей точке MVC, на видеодекодер устройства, когда определено, что видеодекодер устройства способен декодировать и воспроизводить изображения, соответствующие рабочей точке MVC.
[0017] В другом примере считываемый компьютером носитель информации содержит инструкции, которые заставляют процессор целевого устройства принимать структуру данных, соответствующую рабочей точке MVC потока битов стандарта Системы MPEG-2, в котором структура данных сообщает значение способности воспроизведения, которое описывает способность воспроизведения, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки MVC, значение способности декодирования, которое описывает способность декодирования, которую необходимо удовлетворить принимающим устройством для использования рабочей точки MVC, и значение битовой скорости, которое описывает битовую скорость рабочей точки MVC, определять, способен ли видеодекодер целевого устройства декодировать изображения, соответствующие рабочей точке MVC, на основе способности декодирования, сообщенной структурой данных, определять способно ли целевое устройство воспроизводить изображения, соответствующие рабочей точке MVC, на основе способности воспроизведения, сообщенной структурой данных, и отправлять изображения, соответствующие рабочей точке MVC, на видеодекодер целевого устройства, когда определено, что видеодекодер целевого устройства способен декодировать и воспроизводить изображения, соответствующие рабочей точке MVC.
[0018] Детали одного или более примеров изложены на прилагающихся чертежах и в описании ниже. Другие признаки, цели и преимущества будут очевидны из описания и чертежей, и из формулы изобретения.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[0019] На Фиг. 1 показана блок-схема, иллюстрирующая примерную систему, в которой исходное аудио/видео (A/V) устройство транспортирует аудио- и видеоданные на целевое А/V устройство.
[0020] На Фиг. 2 показана блок-схема, иллюстрирующая примерную компоновку компонентов мультиплексора в соответствии с этим раскрытием изобретения.
[0021] На Фиг. 3 показана блок-схема, иллюстрирующая примерный набор таблиц специальной информации о программах в соответствии с этим раскрытием изобретения.
[0022] На Фиг. 4-6 показаны концептуальные схемы, иллюстрирующие различные примеры наборов данных, которые могут быть включены в дескриптор рабочей точки.
[0023] На фиг. 7 показана концептуальная схема, иллюстрирующая примерный образец предсказания MVC.
[0024] На Фиг. 8 показана маршрутная карта, иллюстрирующая примерный способ для использования структуры данных, которая сообщает характеристики рабочей точки.
ПОДРОБНОЕ ОПИСАНИЕ
[0025] Способы этого раскрытия изобретения, в общем, направлены на улучшение кодирования нескольких изображений видео (MVC) в системах MPEG-2 (Экспертная группа по кинематографии), то есть системах, которые согласовываются с MPEG-2 с учетом сведений транспортного уровня. MPEG-4, например, предоставляет стандарты для кодирования видео, но, в общем, предполагает, что видеокодеры, согласованные со стандартом MPEG-4, будут использовать системы транспортного уровня MPEG-2. Следовательно, способы этого раскрытия изобретения применимы к видеокодерам, которые согласованы с MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4 или другим стандартом кодирования видео, который использует транспортные потоки и/или программные потоки (также упоминающиеся как "потоки программ") MPEG-2.
[0026] В частности, способы этого раскрытия изобретения могут модифицировать синтаксические элементы на транспортном уровне для транспортных потоков и программных потоков MPEG-2. Например, способы этого раскрытия изобретения включают в себя дескриптор, который передают в транспортном потоке для описания признаков рабочей точки. Серверное устройство, например, может предоставлять различные рабочие точки в потоке битов транспортного уровня MPEG-2, каждый их которых соответствует соответствующему поднабору конкретных изображений видеоданных кодирования нескольких изображений видео. То есть рабочая точка, в общем, соответствует поднабору изображений в потоке битов. В некоторых примерах каждое изображение рабочей точки включает в себя видеоданные с одинаковой частотой кадров.
[0027] Целевое устройство может использовать дескрипторы рабочих точек, включенные в потоки битов, чтобы выбрать одну из рабочих точек, подлежащих декодированию, и в конечном счете представлению (например, отображению) пользователю. Вместо того, чтобы по приему передавать данные для всех изображений на видеодекодер, целевое устройство может отправлять на видеодекодер только изображения выбранной рабочей точки. Таким образом, целевое устройство может отбрасывать данные для изображений, которые не будут декодированы. Целевое устройство может выбирать рабочую точку на основе наивысшего качества, поддерживаемого одной из рабочих точек для потока битов.
[0028] Серверное устройство может отправлять множество подпотоков битов (каждый из которых может соответствовать рабочей точке) в едином транспортном потоке или программном потоке. Несмотря на то, что различных разделах это раскрытие изобретения может ссылаться индивидуально на "транспортный поток" или "программный поток", должно быть понятно, что способы этого раскрытия изобретения, в общем, применимы к любому или обоим из транспортных потоков MPEG-2 и программных потоков. В общем, это раскрытие изобретения описывает использование дескрипторов в качестве примерных структур данных для выполнения способов этого раскрытия изобретения. Дескрипторы используют для расширения функциональности потока. Дескрипторы этого раскрытия изобретения могут быть использованы как транспортными потоками, так и программными потоками для реализации способов этого раскрытия изобретения. Несмотря на то, что это раскрытие изобретения в первую очередь фокусируется на дескрипторах, как примерной структуре данных, которая может быть использована для сообщения значения способности воспроизведения для рабочей точки, значение способности декодирования для рабочей точки и значения битовой скорости для рабочей точки, должно быть понятно, что для выполнения этих способов могут быть использованы другие структуры данных.
[0029] В соответствии со способами этого раскрытия изобретения исходное устройство 20 может конструировать дескриптор рабочей точки, который описывает характеристики рабочей точки. Характеристики могут включать в себя, например то, какие изображения включены в рабочую точку и частоты кадров для изображений рабочей точки. Дескриптор рабочей точки может указывать способность воспроизведения, которая должна поддерживаться видеодекодером для того, чтобы принимать и декодировать рабочую точку, способность декодирования, которая должна поддерживаться видеодекодером для того, чтобы принимать и декодировать рабочую точку и битовую скорость для рабочей точки.
[0030] Способы этого раскрытия изобретения могут, в общем, представлять каждую рабочую точку, как если бы рабочая точка была своей собственной программой, сообщенной таблицей карты программы в транспортном потоке или картой программного потока в программном потоке. В качестве альтернативы, когда программа содержит множество рабочих точек, способы этого раскрытия изобретения предоставляют информацию о том, как повторно собирать рабочие точки в дескрипторах рабочих точек. Дескрипторы рабочих точек могут дополнительно сообщать зависимости рабочих точек, которые могут экономить биты.
[0031] На Фиг. 1 показана блок-схема, иллюстрирующая примерную систему 10, в которой исходное аудио/видео (A/V) устройство 20 транспортирует аудио- и видеоданные на целевое А/V устройство 40. Система 10 с Фиг. 1 может соответствовать системе видеотелеконференции, серверной/клиентской системе, широковещающей/принимающей системе или любой другой системе, в которой видеоданные отправляют из исходного устройства, такого как исходное A/V устройство 20, на целевое устройство, такое как целевое A/V устройство 40. В некоторых примерах исходное A/V устройство 20 и целевое A/V устройство 40 могут выполнять двусторонний обмен информацией. То есть исходное A/V устройство 20 и целевое A/V устройство 40 могут быть способны как кодировать, так и декодировать (и передавать и принимать) аудио- и видеоданные. В некоторых примерах аудиокодер 26 может содержать голосовой кодер, также называемый вокодером.
[0032] Исходное A/V устройство 20, в примере Фиг. 1, содержит аудиоисточник 22 и видеоисточник 24. Аудиоисточник 22 может содержать, например, микрофон, который производит электрические сигналы, представляющие захваченные аудиоданные, подлежащие декодированию аудиокодером 26. В качестве альтернативы аудиоисточник 22 может содержать носитель информации, хранящий ранее записанные аудиоданные, генератор аудиоданных, такой как компьютеризированный синтезатор, или любой другой источник аудиоданных. Видеоисточник 24 может содержать видеокамеру, которая производит видеоданные, подлежащие декодированию видеокодером 28, носитель информации, кодированный ранее записанными видеоданными, блок генерирования видеоданных или любой другой источник видеоданных.
[0033] Необработанные аудио- и видеоданные могут содержать аналоговые или цифровые данные. Аналоговые данные могут быть оцифрованы до их кодирования аудиокодером 26 и/или видеокодером 28. Аудиоисточник 22 может также получать аудиоданные от говорящего участника, во время того как говорящий участник говорит, и видеоисточник 24 может одновременно получать видеоданные говорящего участника. В других примерах аудиоисточник 22 может содержать считываемый компьютером носитель информации, содержащий сохраненные аудиоданные, и видеоисточник 24 может содержать считываемый компьютером носитель информации, содержащий сохраненные видеоданные. Таким образом, описанные в этом раскрытии изобретения способы могут быть применены к прямой трансляции, потоковой передаче, аудио- и видеоданным в реальном времени и к заархивированным, заранее записанным аудио- и видеоданным.
[0034] Аудиокадры, которые соответствуют видеокадрам, в общем, являются аудиокадрами, содержащими аудиоданные, которые были захвачены аудиоисточником 22, одновременно с видеоданными, захваченными видеоисточником 24, которые содержатся внутри видеокадров. Например, в то время как говорящий участник обычно производит аудиоданные посредством разговора, аудиоисточник 22 захватывает аудиоданные, а видеоисточник 24 захватывает видеоданные говорящего участника в тоже самое время, то есть во время того, как аудиоисточник 22 захватывает аудиоданные. Следовательно, аудиокадр может временно соответствовать одному или более конкретным видеокадрам. Следовательно, аудиокадр, соответствующий видеокадру, в общем, соответствует ситуации, в которой аудиоданные и видеоданные были захвачены в одно и то же время, и для которой аудиокадр и видеокадр содержат, соответственно, аудиоданные и видеоданные, которые были захвачены в одно и то же время.
[0035] В некоторых примерах аудиокодер 26 может кодировать метку времени в каждом кодированном аудиокадре, которая представляет время, в которое были записаны аудиоданные для кодированного аудиокадра, и аналогично видеокодер 28 может кодировать метку времени каждом кодированном видеокадре, которая представляет время, в которое были записаны видеоданные для кодированного видеокадра. В таких примерах аудиокадр, соответствующий видеокадру, может содержать аудиокадр, содержащий метку времени, и видеокадр, содержащий ту же метку времени. Исходное A/V устройство 20 может включать в себя внутренний генератор тактовых импульсов, из которого аудиокодер 26 и/или видеокодер 28 могут генерировать метки времени, или который аудиоисточник 22 и видеоисточник 24 могут использовать, чтобы связать аудио- и видеоданные, соответственно, с меткой времени.
о
[0036] В некоторых примерах аудиоисточник 22 может отправлять данные на аудиокодер 26, соответствующие времени, в которое были записаны аудиоданные, и видеоисточник 24 может отправлять данные на видеокодер 28, соответствующие времени, в которое были записаны видеоданные. В некоторых примерах аудиокодер 26 может кодировать идентификатор последовательности в кодированных аудиоданных для указания относительного временнго порядка кодированных аудиоданных, но без необходимости указания абсолютного времени, в которое были записаны аудиоданные, и аналогично видеокодер 28 может также использовать идентификаторы последовательностей для указания относительного временного порядка кодированных видеоданных. Аналогично в некоторых примерах идентификатор последовательности может быть сопоставлен или, иначе, соотнесен с меткой времени.
[0037] Способы этого раскрытия изобретения, в общем, направлены на транспорт кодированных мультимедийных (например, аудио и видео) данных, и прием, и последующую интерпретацию, и декодирование транспортированных мультимедийных данных. Способы этого раскрытия изобретения, в частности, применимы для транспортирования данных кодирования нескольких изображений видео, то есть видеоданных, содержащих множество изображений. Как показано в примере на Фиг. 1, видеоисточник 24 может предоставлять множество изображений сцены на видеокодер 28. MVC может быть полезно для генерирования трехмерных видеоданных для использования трехмерным дисплеем, таким как стереоскопический и автостереоскопический трехмерный дисплей.
[0038] Исходное A/V устройство 20 может предоставлять "сервис" целевому A/V устройству 40. В общем, сервис соответствует поднабору доступных изображений данных MVC. Например, данные MVC могут быть доступны для восьми изображений, пронумерованных с нуля до семи. Один сервис может соответствовать стереовидео, имеющему два изображения, в то время как другой сервис может соответствовать четырем изображениям, и еще один сервис может соответствовать всем восьми изображениям. В общем, сервис соответствует любой комбинации (то есть любому поднабору) доступных изображений. Сервис может также соответствовать комбинации доступных изображений, равно как и аудиоданных. Рабочая точка может соответствовать сервису, так что исходное A/V устройство 20 может дополнительно предоставлять дескриптор рабочей точки для каждого сервиса, предоставленного исходным A/V устройством 20.
[0039] Исходное A/V устройство 20 в соответствии со способами этого раскрытия изобретения способно предоставлять сервисы, которые соответствуют поднабору изображений. В общем, изображение представлено идентификатором изображения, также называемым как "view_id". В общем, идентификаторы изображений содержат синтаксические элементы, которые могут быть использованы для идентификации изображения. MVC кодер предоставляет view_id изображения, когда кодируют изображение. view_id может быть использован MVC декодером для предсказания изменений между изображениями или другими блоками для других целей, например, для воспроизведения.
[0040] Предсказание изменений между изображениями является способом для кодирования MVC видеоданных кадра со ссылкой на один или более кадров при общем временном расположении как и кодированный кадр разных изображений. На Фиг. 7, который рассмотрен более подробно ниже, предоставлена примерная схема кодирования для предсказания изменений между изображениями. В общем, кодированный кадр MVC видеоданных может быть кодирован с пространственным предсказанием, временным и/или со ссылкой на кадры других изображений при общем временном расположении. Следовательно, опорные изображения, исходя из которых предсказывают другие изображения, в общем, декодируют до изображений, для которых образцовые изображения действуют как образец, так что эти декодированные изображения могут быть использованы для образца при декодировании образцовых изображений. Порядок декодирования необязательно соответствует порядку view_id. Следовательно, порядок декодирования изображений описан с использованием индексов порядка изображений. Индексы порядка изображений являются индексами, которые указывают порядок декодирования компонентов изображения в блоке доступа.
[0041] Каждый индивидуальный поток данных (или аудио, или видео) называют элементарным потоком. Элементарный поток является одиночным с цифровым кодированием (возможно сжатым) компонентом программы. Например, кодированное видео или аудио часть программы может быть элементарным потоком. Элементарный поток может быть преобразован в пакетированный элементарный поток (PES) до мультиплексирования в программный поток или транспортный поток. Внутри одной и той же программы ID потока используют, чтобы отличать PES-пакеты, принадлежащие одному элементарному потоку, от других. Базовой единицей данных элементарного потока является пакет пакетированного элементарного потока (PES). Таким образом, каждое изображение MVC видеоданных соответствует соответствующим элементарным потокам. Аналогично аудиоданные соответствуют одному или более соответствующим элементарным потокам.
[0042] Видеопоследовательность с MVC кодированием может быть разделена на несколько подпотоков битов, каждый из которых является элементарным потоком. Каждый подпоток битов может быть идентифицирован с помощью поднабора MVC view_id. На основе концепции каждого поднабора MVC view_id задают подпоток битов MVC видео. Подпоток битов MVC видео содержит блоки NAL изображений, указанных в поднаборе MVC view_id. Программный поток, в общем, содержит только блоки NAL, которые являются блоками NAL элементарных потоков. Также спроектировано так, что любые два элементарных потока не могут содержать идентичное изображение.
[0043] В примере на Фиг. 1, мультиплексор 30 принимает элементарные потоки, содержащие видеоданные, от видеокодера 28 и элементарные потоки, содержащие аудиоданные, от аудиокодера 26. В некоторых примерах видеокодер 28 и аудиокодер 26, каждый, могут включать в себя пакетизаторы для формирования пакетов PES из кодированных данных. В других примерах видеокодер 28 и аудиокодер 26, каждый, могут взаимодействовать с соответствующими пакетизаторами для формирования пакетов PES из кодированных данных. В еще других примерах мультиплексор 30 может включать в себя пакетизаторы для формирования пакетов PES кодированных аудио- и видеоданных.
[0044] "Программа", как использовано в этом раскрытии изобретения, может содержать комбинацию аудиоданных и видеоданных, например элементарный аудиопоток и поднабор доступных изображений, доставленных сервисом исходного A/V устройства 20. Каждый пакет PES включает в себя stream_id, который идентифицирует элементарный поток, которому принадлежит пакет PES. Мультиплексор 30 отвечает за сборку элементарных потоков в составные программные потоки или транспортные потоки. Программный поток и транспортный поток являются двумя альтернативными мультиплексами, нацеленными на разные применения.
[0045] В общем, программный поток включает в себя данные для одной программы, в то время как транспортный поток может включать в себя данные для одной или более программ. Мультиплексор 30 может кодировать любой или оба из программного потока или транспортного потока на основе предоставляемого сервиса, среды, в которую будет передан поток, числа программ для отправки или других соображении. Например, когда видеоданные подлежат кодированию в носителе информации, мультиплексор 30 может с большей вероятностью формировать программный поток, в то время когда видеоданные подлежат потоковой передаче через сеть, широковещательной передаче или отправке как части видеотелефонии, мультиплексор 30 может с большей вероятностью использовать транспортный поток.
[0046] Мультиплексор 30 может быть склонен в сторону использования программного потока для хранения и отображения одиночной программы от сервиса цифрового хранения. Программный поток предназначен для использования в свободных от ошибок окружающих средах или окружающих средах, менее подверженных встречающимся ошибкам, потому что программные потоки достаточно чувствительны к ошибкам. Программный поток просто содержит принадлежащие ему элементарные потоки и обычно содержит пакеты переменной длины. В программном потоке PES-пакеты, которые получены из предоставляемых элементарных потоков, организованы в "упаковки". Упаковка содержит заголовок упаковки, необязательный системный заголовок и любое число PES-пакетов, взятых из любых предоставляемых элементарных потоков, в любом порядке. Системный заголовок содержит сводку о характеристиках программного потока, такую как максимальная скорость передачи данных, число предоставляемых элементарных видео- и аудиопотоков, дополнительно информация о временном согласовании или другая информация. Декодер может использовать информацию, содержащуюся в системном заголовке для определения того, способен или нет декодер декодировать программный поток.
[0047] Мультиплексор 30 может использовать транспортный поток для одновременной доставки множества программ через потенциально подверженные ошибкам каналы. Транспортный поток является мультиплексом, задуманным для мультипрограммных применений, таких как широковещательная передача, так что единственный транспортный поток может вмещать много независимых программ. Транспортный поток может содержать ряд транспортных пакетов, где длина каждого из транспортных пакетов составляет 188 байт. Использование коротких пакетов с постоянной длиной приводит к тому, что транспортный поток менее чувствителен к ошибкам, чем программный поток. Кроме того, каждому транспортному пакету длиной 188 байт может быть дана дополнительная защита от ошибок за счет обработки пакетов посредством процесса стандартной защиты от ошибок, такого как кодирование Рида-Соломона. Улучшенная устойчивость к ошибкам транспортного потока означает, что он имеет лучшие шансы на выживание в подверженных ошибкам каналах, находящихся, например, в широковещательном окружении.
[0048] Может показаться, что транспортный поток лучше, чем программный поток из-за его повышенной устойчивости к ошибкам и способности переносить много одновременных программ. Однако транспортный поток является более сложным мультиплексом, чем программный поток, и, следовательно, является более сложным для создания и более трудным для демультиплексирования, чем программный поток. Первый байт транспортного пакета может быть байтом синхронизации, имеющим значение 0×47 (шестнадцатеричное 47, двоичное '01000111', десятичное 71). Одиночный транспортный поток может переносить много разных программ, где каждая программа содержит много пакетированных элементарных потоков. Мультиплексор 30 может использовать тринадцатибитное поле Идентификатора пакета (PID), чтобы отличать транспортные пакеты, содержащие данные одного элементарного потока, от тех, которые переносят данные других элементарных потоков. Обязанностью мультиплексора является гарантирование того, что каждому элементарному потоку присваивают уникальное значение PID. Последний байт транспортного пакета может быть полем счетчика непрерывности. Мультиплексор 30 увеличивает значение поля счетчика непрерывности между последовательными транспортными пакета, принадлежащими одному элементарному потоку. Это дает возможность декодеру или другому блоку целевого устройства, такому как целевое А/V устройство 40, обнаруживать потери или прирост транспортных пакетов и, следует надеяться, скрывать ошибки, которые в противном случае могут возникать из такого события.
[0049] Мультиплексор 30 принимает пакеты PES для элементарных потоков программы от аудиокодера 26 и видеокодера 28 и формирует соответствующие блоки уровня сетевой абстракции (NAL) из пакетов PES. В примере H.264/AVC (Улучшенное кодирование видео), кодированные видеосегменты организуют в блоки NAL, которые обеспечивают "дружественные к сетям" применения адресации представлений видео, такие как видеотелефония, хранение, широковещательная передача или потоковая передача. Блоки NAL могут быть классифицированы на блоки NAL уровня видеокодирования (VCL) и блоки NAL не-VCL. Блоки VCL содержат механизм базового сжатия и могут содержать уровни блоков, макроблоков и/или полос. Другие блоки NAL являются блоками NAL не-VCL.
[0050] Мультиплексор 30 может формировать блоки NAL, содержащие заголовок, который идентифицирует программу, которой принадлежит NAL, равно как и полезная информация, например аудиоданные, видеоданные иди данные, которые описывают транспортный или программный поток, которому соответствуют блоки NAL. Например, в H.264/AVC, блок NAL включает в себя 1-байтовый заголовок и полезную информацию переменного размера. В одном примере заголовок блока NAL содержит элемент priority_id, элемент temporal_id, элемент anchor_pic_flag, элемент view_id, элемент non_idr_flag и элемент inter_view_flag. В традиционном MVC удерживают блок NAL, заданный посредством H.264, кроме префиксных блоков NAL и блоков NAL слайса, кодированных с помощью MVC, которые содержат 4-байтный заголовок блока NAL MVC и полезную информацию блока NAL.
[0051] Элемент priority_id заголовка NAL может быть использован для процесса простой однопроходной адаптации потока битов. Элемент temporal_id может быть использован для указания временного уровня соответствующего блока NAL, где разные временные уровни соответствуют разным частотам кадров.
[0052] Элемент anchor_pic_flag может указывать является ли картинка опорной картинкой или не опорной картинкой. Опорные картинки и все картинки, следующие за ней в порядке вывода (то есть порядке отображения), могут быть корректно декодированы без декодирования предыдущих картинок в порядке декодирования (то есть порядке потока битов) и, таким образом, могут быть использованы в качестве случайных точек доступа. Опорные картинки и не опорные картинки могут иметь разные зависимости, и те и другие сообщаются в наборе параметров последовательности. Другие флаги подлежат обсуждению и использованию в следующих разделах этой главы. Такая опорная картинка может также называться как точка доступа открытой GOP (Группы картинок), в то время как точка доступа закрытой GOP также поддерживается, когда элемент non_idr_flag равен нулю. Элемент non_idr_flag указывает является ли картинка картинкой мгновенного обновления декодера (IDR) или картинкой IDR (V-IDR) изображения. В общем, картинка IDR и все следующие за ней картинки в порядке вывода или порядке потока битов, могут быть корректно декодированы без декодирования предыдущих картинок как в порядке декодирования, так и в порядке отображения.
[0053] Элемент view_id может содержать синтаксическую информацию, который может быть использован для идентификации изображения, который может быть использован для интерактивности данных внутри MVC декодера, например для предсказания изменений между изображениями, и вне декодера, например для воспроизведения. Элемент inter_view_flag может указывать используется ли соответствующий блок NAL другими изображениями для предсказания изменений между изображениями. Для переноса информации 4-байтного заголовка блока NAL для базового изображения, который может быть совместим с AVC, при MVC задают префиксный блок NAL. В контексте MVC, блок доступа базового изображения включает в себя блоки NAL VCL изображения текущего момента времени, равно как и его префиксный блок NAL, который содержит только заголовок блока NAL. H.264/AVC декодер может игнорировать префиксный блок NAL.
[0054] Блок NAL, включающий видеоданные в своей полезной информации, может содержать различные степени гранулярности видеоданных. Например, блок NAL может содержать блок видеоданных, макроблок, множество макроблоков, слайс видеоданных или весь кадр видеоданных. Мультиплексор 30 может принимать кодированные видеоданные от видеокодера 28 в виде пакетов PES элементарных потоков. Мультиплексор 30 может связывать каждый элементарный поток с соответствующей программой посредством соотнесения stream_id с соответствующими программами, например, в базе данных или других структурах данных, таких как таблица карты программы (PMT) и карта программного потока (PSM).
[0055] Мультиплексор 30 может также собирать блоки доступа из множества блоков NAL. В общем, блок доступа может содержать один или более блоков NAL для представления кадра видеоданных, равно как и аудиоданных, соответствующих кадру, когда такие аудиоданные доступны. Блок доступа, в общем, включает в себя все блоки NAL для одного момента времени вывода, например все аудио-и видеоданные для одного момента времени. Например, если каждое изображение имеет частоту кадров в 20 кадров в секунду (кадр/сек), то каждый момент времени может соответствовать временному интервалу в 0,05 секунд. Во время этого временного интервала характерные кадры для всех изображений одного и того же блока доступа (одного и того же момента времени) могут быть воспроизведены одновременно. В примере, соответствующем H.264/AVC, блок доступа может содержать кодированную картинку в один момент времени, которая может быть представлена как картинка, кодированная в первую очередь. Следовательно, блок доступа может содержать все аудио- и видеокадры общего временного момента, например все изображения соответствующие времени X. Это раскрытие изобретения также относится к кодированной картинке конкретного изображения, в качестве "компонента изображения". То есть компонент изображения может содержать кодированную картинку (или кадр) для конкретного изображения в конкретное время. Следовательно, блок доступа может быть задан как содержащий все компоненты изображений общего временного момента. Порядок декодирования блоков доступа необязательно должен быть таким же, как порядок вывода или отображения.
[0056] Мультиплексор 30 может также встраивать данные, касающиеся программы, в блок NAL. Например, мультиплексор 30 может создавать блок NAL, содержащий таблицу карты программы (PMT) или карту программного потока (PSM). В общем, PMT используют для описания транспортного потока, в то время как PSM используют для описания программного потока. Как более подробно описано ниже с учетом примера на Фиг. 2, мультиплексор 30 может содержать или взаимодействовать с блоком хранения данных, который связывает элементарные потоки, принятые от аудиокодера 26 и видеокодера 28, с программами и, следовательно, с соответствующими транспортными потоками и/или программными потоками.
[0057] Как и в случае большинства стандартов кодирования видео, H.264/AVC задает синтаксис, семантику и процесс декодирования для свободных от ошибок потоков битов, любой из которых согласуется с определенным профилем или уровнем. H.264/AVC не указывает кодер, но кодеру ставят задачу с гарантией того, что сгенерированные потоки битов являются совместимыми со стандартом для декодера. В контексте стандарта кодирования видео "профиль" соответствует поднабору алгоритмов, признаков или инструментов и ограничений, которые к ним применяются. Как задано стандартом H.264, например, "профиль" является поднабором синтаксиса всего потока битов, который указан стандартом H.264. "Уровень" соответствует ограничениям потребления ресурсов декодера, таких как, например, память и вычислительные ресурсы декодера, которые относятся к разрешению картинки, битовой скорости и скорости обработки макроблока (MB).
[0058] Стандарт H.264 показывает, что внутри границ, наложенных синтаксисом данного профиля, все еще возможно требовать большое изменение в рабочих характеристиках кодеров и декодеров в зависимости от значений, принятых синтаксическими элементами в потоке битов, таких как указанный размер декодированных картинок. Стандарт H.264 дополнительно показывает, что во многих применениях как не практично, так и не экономично реализовывать декодер, способный иметь дело со всеми гипотетическими использованиями синтаксиса внутри конкретного профиля. Следовательно, стандарт H.264 задает "уровень" как указанный набор ограничений, наложенных на значения синтаксических элементов в потоке битов. Эти ограничения могут быть простыми ограничениями на значения. В качестве альтернативы эти ограничения могут принимать вид ограничений на арифметические комбинации значений (например, ширина картинки, умноженная на высоту картинки, умноженную на число декодируемых картинок в секунду). Стандарт H.264 дополнительно обеспечивает то, что индивидуальные реализации могут поддерживать разный уровень для каждого поддерживаемого профиля.
[0059] Декодер, согласовываясь с профилем, обычно поддерживает все признаки, заданные в профиле. Например, в качестве признака кодирования кодирование B-картинки не поддерживается в базовом профиле H.264/AVC, но поддерживается в других профилях H.264/AVC. Декодер, согласовываясь с уровнем, должен быть способен декодировать любой поток битов, который не требует ресурсов, выходящих за пределы, заданные в уровне. Задания профилей и уровней могут быть полезными для интерпретируемости. Например, во время передачи видео, задания пары профиля и уровня могут быть согласованы и установлены для всей сессии передачи. Более конкретно в H.264/AVC уровень может задавать, например, ограничения на число макроблоков, которые нужно обработать, на размер буфера декодированной картинки (DPB), размер буфера кодированной картинки (СРВ), диапазон векторов вертикального движения, максимальное число векторов движения на два последующих MB, и может ли B-блок иметь разделения подмакроблоков менее чем 8x8 пикселей. Таким образом, декодер может определять способен ли декодер правильно декодировать поток битов.
[0060] Набор параметров, в общем, содержит информацию заголовка уровня последовательности в наборах параметров последовательности (SPS) и редко изменяемую информацию заголовка уровня картинки в наборах параметров картинки (PPS). С наборами параметров эта редко изменяемая информация не нуждается в повторении для каждой последовательности или картинки; следовательно, может быть эффективно улучшено кодирование. Кроме того, использование наборов параметров может обеспечить возможность внеполосной передачи информации заголовка, избегая необходимости избыточных передач для достижения устойчивости к ошибкам. При внеполосной передаче блоки NAL набора параметров передают по другому каналу, нежели другие блоки NAL.
[0061] Стандарт Системы MPEG-2 позволяет расширения системы посредством "дескрипторов". Как PMT, так и PSM включают в себя циклы дескрипторов, в которые могут быть вставлены один или более дескрипторов. В общем, дескриптор может содержать структуру данных, которая может быть использована для расширения задания программ и/или элементов программы. Это раскрытие изобретения описывает дескрипторы рабочих точек для выполнения способов этого раскрытия изобретения. В общем, дескриптор рабочей точки этого раскрытия изобретения улучшает дескриптор расширения традиционного MVC за счет описания способности воспроизведения, способности декодирования и битовой скорости для рабочей точки. Целевое устройство, такое как целевое A/V устройство 40, может использовать дескрипторы рабочих точек для каждой рабочей точки, чтобы выбрать одну из рабочих точек потока битов для декодирования.
[0062] Каждая PMT или PSM может включать в себя дескриптор рабочей точки, который описывает характеристики рабочей точки. Например, исходное устройство 20 может предоставлять дескриптор рабочей точки для предоставления значения способности воспроизведения, которое описывает способность воспроизведения для клиентского устройства 40. Для того, чтобы клиентское устройство 40 правильно осуществляло воспроизведение (например, отображало) видеоданных рабочей точки, клиентское устройство 40 должно удовлетворять способностям воспроизведения, сообщенным значением способности воспроизведения. Значение способности воспроизведения может описывать, например, число изображений, подлежащих отображению (например, число изображений намеченных для воспроизведения), и/или частоту кадров видеоданных для изображений. Таким образом, клиентское устройство 40 может определять, что способности воспроизведения удовлетворены, когда выдеовыход 44 клиентского устройства 40 способен отображать некоторое число изображений рабочей точки с частотой кадров, указанной дескриптором рабочей точки.
[0063] В примерах, в которых исходное устройство 20 передает поток битов MVC, используя протоколы многоадресной передачи или широковещательной передачи, исходное устройство 20 может пакетировать весь поток битов MVC в транспортные потоки, которые могут быть приняты клиентскими устройствами, имеющими различные способности воспроизведения. Например, некоторые трехмерные программы могут иметь разное число изображений (например, два изображения, четыре изображения, шесть изображений или восемь изображений), и различные устройства могут быть способны использовать любое число между одной и четырьмя парами изображений. Таким образом, каждое клиентское устройство может определять какую рабочую точку использовать на основе поддерживаемого числа изображений, которые могут быть отображены клиентским устройством. Например, клиентское устройство 40 может определять какую из рабочих точек использовать посредством определения числа изображений, которые могут быть отображены видеовыходом 44, и частоты кадров, с которой выдеовыход 44 способен отображать видеоданные и определять какую из рабочих точек следует использовать на основе способностей воспроизведения видеовыхода 44.
[0064] В примерах, в которых исходное устройство передает поток битов MVC, используя протокол одноадресной передачи, клиентское устройство 40 может устанавливать сессию, соответствующую программе с допустимым числом изображений, посредством проверки способности воспроизведения, указанной в соответствующих дескрипторах рабочих точек. Аналогично в примерах, в которых поток битов MVC кодируют в считываемый компьютером носитель информации для локального воспроизведения, клиентское устройство 40 может выбирать подходящую программу посредством проверки способности воспроизведения, указанной в дескрипторах рабочих точек PMT или PSM.
[0065] Исходное устройство 20 может также предоставлять значение способности декодирования в дескрипторе рабочей точки. Число изображений, подлежащих декодированию, необязательно может быть таким же, как число изображений, подлежащих отображению. Следовательно, дескриптор рабочей точки может отдельно сообщать число изображений, подлежащих отображению, и число изображений, подлежащих декодированию, для рабочей точки. К тому же дескриптор рабочей точки может специально идентифицировать изображения, соответствующие рабочей точке. Определенные клиентские устройства могут предпочитать конкретные изображения для различных целей, например, на основе угла наблюдения. Следовательно, клиентское устройство 40 может быть выполнено с возможностью выбора рабочей точки на основе того, какие изображения доступны в рабочей точке.
[0066] В некоторых примерах способности декодирования, сообщенные в рабочей точке, могут дополнительно или в качестве альтернативы указывать профиль и уровень, которым соответствует рабочая точка. В примерах, в которых исходное устройство 20 передает поток битов, используя протоколы многоадресной передачи или широковещательной передачи, различные клиентские устройства с разными способностями декодирования могут принимать поток битов. Например, некоторые декодеры могут быть способны только декодировать два изображения с 30 кадр/сек, в то время как некоторые могут быть способны декодировать четыре изображения с 60 кадр/сек. В примерах, в которых исходное устройство 20 передает поток битов, используя протокол одноадресной передачи, клиентское устройство 40 может устанавливать подходящую сессию (для специальной трехмерной программы) после проверки способности декодирования, указанной в дескрипторах в PMT. Аналогично для локального воспроизведения клиентское устройство 40 может выбирать подходящую программу посредством проверки способности декодирования, указанной в дескрипторах рабочих точек PMT или PSM.
[0067] Исходное устройство 20 может дополнительно сообщать информацию о битовой скорости в дескрипторе рабочей точки. Информация о битовой скорости может описывать либо среднюю битовую скорость, либо максимальную битовую скорость или обе скорости для рабочей точки. Например, когда исходное устройство 20 передает поток битов, используя протокол одноадресной передачи, используемый для передачи канал может быть ограничен в части полосы пропускания. Следовательно, клиентское устройство 40 может выбирать рабочую точку, имеющую приемлемую максимальную или среднюю битовую скорость для канала связи.
[0068] В некоторых примерах исходное устройство 20 может дополнительно указывать частоту кадров рабочей точки в дескрипторе рабочей точки. Определенные изображения рабочей точки могут иметь частоты кадров, которые не совпадают с частотой кадров рабочей точки. Таким образом, клиентское устройство 40 может определять частоту кадров рабочей точки и частоту кадров такого изображения для облегчения процесса повторной сборки декодированных видеоданных для целей отображения видеоданных. В различных примерах, когда частоты кадров двух рабочих точек не совпадают, клиентское устройство 40 может выбрасывать кадры из изображений рабочей точки, имеющей более высокую частоту кадров, или интерполировать кадры из изображений рабочей точки, имеющей более низкую частоту кадров.
[0069] Обычно элементарный поток включает в себя флаги "no_sei_nal_unit_present" и "no_prefix_nal_unit_present", которые описывают, соответственно, включает ли в себя элементарный поток сообщения SEI и префиксные блоки NAL. Это раскрытие изобретения предлагает, чтобы клиентские устройства, такие как клиентское устройство 40, сделали вывод о том, присутствуют ли сообщения SEI и префиксные блоки NAL внутри рабочей точки, вместо того, чтобы явно сообщать эти значения для рабочей точки. Для определения того, присутствуют ли сообщения SEI в рабочей точке, клиентское устройство 40 может определять равняется ли единице максимальное значение из значений no_sei_nal_unit_present элементарных потоков для рабочей точки. Аналогично для определения того, присутствуют ли префиксные блоки NAL в рабочей точке, клиентское устройство 40 может определять равняется ли единице максимальное значение из значений no_prefix_nal_unit_present элементарных потоков для рабочей точки.
[0070] Рассмотренные выше примеры сфокусированы на дескрипторах рабочих точек, содержащихся для каждой рабочей точки потока битов MVC. В качестве альтернативы исходное устройство 20 может предоставлять дескрипторы расширения MVC, которые сообщают аналогичные данные. Например, исходное устройство 20 может связывать более чем одни дескриптор расширения MVC с подпотоком битов MVC видео, который соответствует элементарному потоку. Исходное устройство 20 может указывать в дескрипторе расширения MVC для подпотока битов частоту кадров, поднабор view_id изображений, подлежащих отображению, и число изображений, подлежащих декодированию. Исходное устройство 20 может дополнительно сообщать соответствие между дескрипторами расширения MVC и соответствующей рабочей точкой.
[0071] Стандарты сжатия видео, такие как H.261, H.262, H.263, MPEG-1, MPEG-2 и H.264/MPEG-4 часть 10, используют временное предсказание с компенсацией движения, чтобы снизить временную избыточность. Кодер использует предсказание с компенсацией движения исходя из ранее кодированных картинок (также называемых в настоящем документе как кадры), чтобы предсказывать картинки, кодируемые в данный момент, согласно векторам движения. Существуют три основных типа картинок при обычном кодировании видео. Ими являются внутренне кодированные картинки ("I-картинки" или "I-кадры"), картинки с предсказанием ("P-картинки" или "P-кадры") и картинки с двунаправленным предсказанием ("B-картинки" или "B-кадры"). P-картинки используют только опорную картинку перед текущей картинкой во временном порядке. В B-картинке каждый блок B-картинки может быть предсказан исходя из одной или двух опорных картинок. Эти опорные картинки могут быть расположены перед и после текущей картинки во временном порядке.
[0072] В соответствии со стандартом кодирования H.264 в качестве примера B-картинки используют два списка ранее кодированных опорных картинок, список 0 и список 1. Каждый из этих двух списков содержит кодированные в прошлом и будущем картинки во временном порядке. Блоки в B-картинке могут быть предсказаны одним из нескольких способов: предсказание с компенсацией движения исходя из опорной картинки списка 0, предсказание с компенсацией движения исходя из опорной картинки списка 1 или предсказание с компенсацией движения исходя из комбинации опорных картинок как списка 0, так и списка 1. Чтобы получить комбинацию опорных картинок как списка 0, так и списка 1, две опорные зоны с компенсацией движения получают из опорной картинки списка 0 и списка 1 соответственно. Их комбинация будет использована для предсказания текущего блока.
[0073] Стандарт ITU-T H.264 поддерживает внутреннее предсказание при различных размерах блоков, таких как 16 на 16, 8 на 8 или 4 на 4 для компонентов яркости, и 8x8 для компонентов цветности, равно как внешнее предсказание при различных размерах блоков, таких как 16×16, 16×8, 8×16, 8×8, 8×4, 4×8 и 4×4 для компонентов яркости и отмасштабированные соответствующим образом размеры для компонентов цветности. В этом раскрытии изобретения "×" и "на" могут быть использованы взаимозаменяемо для ссылки на размеры блока в пикселях в части вертикальных и горизонтальных размеров, например 16×16 пикселей или 16 на 16. В общем, блок 16×16 будет иметь 16 пикселей в вертикальном направлении (y=16) и 16 пикселей в горизонтальном направлении (x=16). Аналогично блок N×N, в общем, имеет N пикселей вертикальном направлении и N пикселей в горизонтальном направлении, где N представляет неотрицательное целое значение. Пиксели в блоке могут быть скомпонованы в ряды и столбцы.
[0074] Размеры блоков, которые меньше чем 16 на 16, могут называться как разделения макроблока 16 на 16. Видеоблоки могут содержать блоки данных пикселей в области пикселей, или блоки коэффициентов преобразования в области преобразования, например, следующее применение преобразования, такого как дискретное косинусное преобразование (DCT), целочисленное преобразование, вейвлет преобразование или концептуально аналогичное преобразование в данные остаточного видеоблока, представляющие разности пикселей между кодированными видеоблоками и предсказанными видеоблоками. В некоторых случаях видеоблок может содержать блоки квантованных коэффициентов преобразования в области преобразования.
[0075] Меньшие видеоблоки могут обеспечивать лучшее разрешение и могут быть использованы для расположений видеокадров, которые включают в себя высокие уровни детализации. В общем, макроблоки и различные разделения, иногда называемые как подблоки, могут считаться видеоблоками. К тому же слайс может считаться множеством видеоблоков, таких как макроблоки и/или подблоки. Каждый слайс может быть независимо декодируемой единицей видеокадра. В качестве альтернативы кадры, сами по себе, могут быть декодируемыми единицами, или другие части кадра могут быть заданы как декодируемые единицы. Термин "кодированная единица" и "кодирующая единица" могут относится к любой независимо декодируемой единице видеокадра, такой как весь кадр, слайс кадра, группа картинок (GOP) также называемая как последовательность, или другая независимо декодируемая единица, заданная согласно применяемым способам кодирования.
[0076] Термин макроблок относится к структуре данных для кодирования картинок и/или видеоданных согласно двумерному массиву пикселей, который содержит 16x16 пикселей. Каждый пиксель содержит компонент цветности и компонент яркости. Следовательно, макроблок может задавать четыре блока яркости, где каждый содержит двумерный массив 8x8 пикселей, два блока цветности, где каждый содержит двумерный массив 16x16 пикселей, и заголовок, содержащий синтаксическую информацию, такую как образец кодированного блока (СВР), режим кодирования (например, внутренний (I) или внешний (P или B) режимы кодирования), размер разделения для разделений кодированных посредством внутренне кодированных блоков (например, 16×16, 16×8, 8×16, 8×8, 8×4, 4×8, или 4×4) или один или более векторов движения для внешне кодированных макроблоков.
[0077] Видеокодер 28, видеодекодер 48, аудиокодер 26, аудиодекодер 46, мультиплексор 30 и демультиплексор 38, каждый, могут быть реализованы в виде любой из множества подходящих схем кодирования и декодирования при соответствующих условиях, таких как один или более микропроцессоров, процессоры цифровой обработки сигналов (DSP), специализированные интегральные микросхемы (ASIC), программируемые пользователем вентильные матрицы (FPGA), дискретная логическая схема, программное обеспечение, аппаратное обеспечение, микропрограммное обеспечение или любая их комбинация. Каждые видеокодер 28 и видеодекодер 48 может быть включен в один или более кодеров или декодеров, любой из которых может быть интегрирован как часть комбинированного видеокодера/декодера (кодек). Аналогично каждый аудиокодер 26 и аудиодекодер 46 могут быть включены в один или более кодеров или декодеров, любой из которых может быть интегрирован как часть комбинированного кодека. Устройство, включающее в себя видеокодер 28, видеодекодер 48, аудиокодер 26, аудиодекодер 46, мультиплексор 30 и/или демультиплексор 38, может содержать интегральную схему, микропроцессор и/или устройство беспроводной связи, такое как сотовый телефон.
[0078] Способы этого раскрытия изобретения могут предложить определенные преимущества дополнительно к традиционным способам для подпотока битов MVC, которые не обеспечивают сообщение характеристик рабочих точек. Каждый подпоток битов может включать в себя один или более изображений соответствующего потока битов. А некоторых случаях рабочая точка может соответствовать изображениям разных потоков битов. Способы этого раскрытия изобретения предоставляют дескриптор рабочей точки, который идентифицирует изображения соответствующей рабочей точки.
[0079] После того, как мультиплексор 30 собрал блок NAL и/или блок доступа из принятых данных, мультиплексор 30 пропускает блок на выходной интерфейс 32 для вывода. Выходной интерфейс 32 может содержать, например, передатчик, приемопередатчик, устройство для записи данных на считываемый компьютером носитель, такое как, например, оптический привод, привод для магнитных носителей (например, дисковод гибких магнитных дисков), порт универсальной последовательной шины, сетевой интерфейс или другой выходной интерфейс. Выходной интерфейс 32 выводит блок NAL или блок доступа на считываемый компьютером носитель 34, такой как, например, сигнал передачи, магнитный носитель, оптический носитель, память, флэш-накопитель или другой считываемый компьютером носитель.
[0080] В конечном счете интерфейс 36 ввода осуществляет выборку данных из считываемого компьютером носителя 34. Входной интерфейс 36 может содержать, например, накопитель на оптических дисках, накопитель на магнитных носителях, порт USB, приемник, приемопередатчик или другой интерфейс считываемого компьютером носителя. Входной интерфейс 36 может предоставлять блок NAL или блок доступа демультиплексору 38. Демультиплексор 38 может демультиплексировать транспортный поток или программный поток на составляющие потоки PES, депакетировать потоки PES для выборки данных и отправлять кодированные данные либо на аудиодекодер 46, либо видеодекодер 48 в зависимости от того, являются ли кодированные данные частью аудио- или видеопотока, например, как указано заголовками пакетов PES потока. Аудиодекодер 46 декодирует аудиоданные и отправляет декодированные аудиоданные на аудиовыход 42, в то время как видеодекодер 48 декодирует кодированные видеоданные и отправляет декодированные видеоданные, которые могут включать в себя множество изображений потока, на видеовыход 44. Видеовыход 44 может содержать дисплей, который использует множество изображений сцены, например стереоскопический или автостереоскопический дисплей, который представляет каждую картинку сцены одновременно.
[0081] В частности, демультиплексор 38 может выбирать рабочую точку принятого потока битов. Например, демультиплексор 38 может сравнивать характеристики рабочих точек потока битов для выбора надлежащей рабочей точки, подлежащей использованию целевым А/V устройством 40. В общем, демультиплексор 38 может попытаться выбрать одну из рабочих точек, которые обеспечат ощущение просмотра наивысшего качества для пользователя, которые могут быть декодированы видеодекодером 48. Например, демультиплексор 38 может сравнивать способности воспроизведения и способности декодирования видеодекодера 48 с предложенными способностями воспроизведения и декодирования, сигнализированными дескрипторами рабочих точек потока битов. Из рабочих точек, которые демультиплексор 38 определяет как способные быть правильно декодированными видеодекодером 48, демультиплексор 38 может выбирать рабочую точку, которая обеспечит видеоданные наивысшего качества, например наивысшую частоту кадров и/или битовую скорость. В других примерах демультиплексор 38 может выбирать одну из поддерживаемых рабочих точек на основе других соображений, таких как, например, потребляемая мощность.
[0082] На Фиг. 2 показана блок-схема, иллюстрирующая примерную компоновку компонентов мультиплексора 30 (Фиг. 1). В примере на фиг. 2 мультиплексор 30 включает в себя блок 60 управления потоком, интерфейс 80 видеовхода, интерфейс 82 аудиовхода, выходной интерфейс 84 мультиплексированного потока и таблицы 88 специальной информации о программах. Блок 60 управления потоком включает в себя конструктор 62 блока NAL, конструктор 64 PMT, блок 66 поиска идентификатора потока (ID потока) и блок 68 назначения идентификатора программы (PID).
[0083] В примере на Фиг. 2 интерфейс 80 видеовхода и интерфейс 82 аудиовхода включают в себя пакетизаторы для формирования блоков PES из кодированных видеоданных и кодированных аудиоданных. В других примерах видео- и/или аудиопакетизаторы могут быть включены в блок или модуль, который является внешним по отношению к мультиплексору 30. С учетом примера на Фиг. 2 интерфейс 80 видеовхода может формировать пакеты PES из кодированных видеоданных, принятых от видеокодера 28, и интерфейс 82 аудиовхода может формировать пакеты PES из кодированных аудиоданных, принятых от аудиокодера 26.
[0084] Блок 60 управления потоком принимает пакеты PES от интерфейса 80 видеовхода и интерфейса 82 аудиовхода. Каждый пакет PES включает в себя ID потока, который идентифицирует элементарный поток, которому принадлежит пакет PES. Блок 66 поиска ID потока может определять программу, которой соответствует пакет PES посредством осуществления запроса к таблицам 88 специальной информации о программах. То есть блок 66 поиска ID потока может определять, какой программе соответствует принятый пакет PES. Каждая программа может содержать множество элементарных потоков, в то время как, в общем, один элементарный поток соответствует только одной программе. Однако в некоторых примерах элементарный поток может быть включен во множество программ. Каждый пакет PES может быть включен во множество потоков, выводимых из мультиплексора 30, как и различные сервисы могут каждый включать в себя различные поднаборы доступных аудио- и видеопотоков. Следовательно, блок 66 поиска ID потока может определять, должен ли пакет PES быть включен в один или более выходных потоков (например, один или более транспортных или программных потоков) и конкретно в какой из выходных потоков включать пакет PES.
[0085] В одном примере каждый элементарный поток соответствует программе. Мультиплексор 30 может отвечать за гарантию того, что каждый элементарный поток связан с конкретной программой и, следовательно, с ID программы (PID). Когда пакет PES принят, включающий в себя ID потока, который не распознается мультиплексором 30 (например, ID потока, не хранящийся в таблицах 88 специальной информации о программах), то блок 68 назначения PID создает одну или более записей в таблицах 88 специальной информации о программах, чтобы связать новый ID потока с не использованным PID.
[0086] После определения программы, которой соответствует пакет PES, конструктор 62 блока NAL формирует блок NAL, содержащий пакет PES, например, посредством инкапсуляции пакета PES заголовком блока NAL, включающего в себя PID программы, которой соответствует ID потока пакета PES. В некоторых примерах конструктор 62 блока NAL, или другой подблок блока 60 управления потоком, может формировать блок доступа, содержащий множество NAL блоков.
[0087] Конструктор 64 PMT создает таблицы карт программ (PMT) для соответствующего выходного потока мультиплексора 30, используя информацию из таблиц 88 специальной информации о программах. В другом примере блок 60 управления потоком может содержать конструктор PSM для создания карт программных потоков, выводимых мультиплексором 30. В некоторых примерах мультиплексор 30 может содержать как конструктор 64 PMT, так и конструктор PSM, и выводить транспортный поток и/или программный поток. В примере на Фиг. 2 конструктор 64 PMT может конструировать PMT, включающую в себя новые дескрипторы, описанные этим раскрытием изобретения, например дескриптор рабочей точки, равно как и любые другие необходимые дескрипторы и данные PMT для PMT. Конструктор 64 PMT может периодически, например, после определенного периода времени или после передачи определенного количества данных отправлять последующую PMT для транспортного потока. Конструктор 64 PMT может пропускать созданные PMT в конструктор 62 блока NAL для формирования блока NAL, содержащего PMT, например, посредством инкапсуляции PMT соответствующим заголовком блока NAL, включающим в себя соответствующий PID.
[0088] Конструктор 64 PMT может создавать структуру данных, такую как дескриптор рабочей точки, для каждой рабочей точки программы. Структура данных, созданная конструктором 64 PMT, может сообщать значение способности воспроизведения, которое описывает способность воспроизведения, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки, значение способности декодирования, которое описывает способность декодирования, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки, и значение битовой скорости, которое описывает битовую скорость рабочей точки.
[0089] Например, конструктор 64 PMT может определять число изображений, подлежащих отображению для рабочей точки, и частоту кадров для изображений рабочей точки на основе информации, хранимой таблицами 88 специальной информации о программах, или информации, принятой от видеокодера 28 через интерфейс 80 видеовхода. Конструктор PMT 64 может сообщать число изображений и/или частоту кадров для изображений рабочей точки используя значение способности воспроизведения структуры данных.
[0090] Конструктор 64 PMT может также определять число изображений, подлежащих декодированию, для рабочей точки и значение уровня для профиля, которому соответствуют изображения рабочей точки. Например, конструктор 64 PMT может определять число макроблоков, которое нужно для обработки, размер буфера декодированной картинки, размер буфера кодированной картинки, диапазон векторов вертикального движения, максимальное число векторов движения на два последующих макроблока, и/или может ли B-блок иметь разделения подмакроблоков менее чем 8×8 пикселей, и использовать эти определения, чтобы определять уровень для рабочей точки. Конструктор 64 PMT может принимать эту информацию от видеокодера 28 через интерфейс 80 видеовхода. Конструктор PMT 64 может затем представлять число изображений, подлежащих декодированию, и/или значение уровня профиля, используя значение способности декодирования для рабочей точки.
[0091] Конструктор 64 PMT может дополнительно определять значение битовой скорости для рабочей точки и кодировать значение битовой скорости в структуру данных. Значение битовой скорости может соответствовать средней битовой скорости или максимальной битовой скорости для рабочей точки. Конструктор 64 PMT может вычислять битовую скорость для рабочей точки или принимать указание битовой скорости от видеокодера 28.
[0092] Выходной интерфейс 84 мультиплексированного потока может принимать один или более блоков NAL и/или блоков доступа от блока 60 управления потоком, например блоки NAL, содержащие пакеты PES (например, аудио- и видеоданные), и/или блоки NAL, содержащие PMT. В некоторых примерах выходной интерфейс 84 мультиплексированного потока может формировать блоки доступа из одного или более блоков NAL, соответствующих общему временному расположению после приема блоков NAL от блока 60 управления потоком. Выходной интерфейс 84 мультиплексированного потока передает блоки NAL или блоки доступа в качестве вывода в соответствующий транспортный поток и программный поток. Выходной интерфейс 84 мультиплексированного потока может также принимать структуру данных от конструктора 64 PMT и включать структуру данных как часть потока битов.
[0093] На Фиг. 3 показана блок-схема, иллюстрирующая примерный набор таблиц 88 специальной информации о программах. Элементарный поток, которому принадлежит транспортный пакет, может быть определен на основе значения PID транспортного пакета. Для того, чтобы декодер правильно декодировал принятые данные, декодер должен быть способен определять, какой элементарный поток принадлежит каждой программе. Специальная информация о программах, как включенная в таблицу 88 специальной информации о программах, может явным образом указывать взаимосвязь между программами и элементарными потоками компонентов. В примере на фиг. 3 таблицы 88 специальной информации о программах включают в себя таблицу 100 сетевой информации, таблицу 102 условного доступа, таблицу 104 программного доступа и таблицу 106 карты программы. Для примера на Фиг. 3 предполагают, что выходной поток содержит транспортный поток MPEG-2. В альтернативном примере выходной поток может содержать программный поток, в этом случае таблица 106 карты программы может быть заменена картой программного потока.
[0094] Спецификация Системы MPEG-2 задает, что каждая программа, переносимая в транспортном потоке, имеет таблицу карты программы, такую как таблица 106 карты программы, связанную с ней. Таблица 106 карты программы может включать в себя сведения о программе и элементарных потоках, которые включает в себя программа. В качестве одного примера программа, идентифицированная как программа номер 3, может содержать элементарный видеопоток с PID 33, английский аудиопоток с PID 57 и китайский аудиопоток с PID 60. Допускается для PMT включать в себя более чем одну программу.
[0095] Базовая таблица карты программы, указанная спецификацией Системы MPEG-2, может быть украшена несколькими из множества дескрипторов, например дескрипторами 108, указанными в спецификации Системы MPEG-2. Дескрипторы 108 могут включать в себя любые или все из указанных дескрипторов спецификации Системы MPEG-2. В общем, дескрипторы, такие как дескрипторы 108, переносят дополнительную информацию о программе или ее элементарных потоков компонентов или подпотоков битов. Дескрипторы могут включать в себя параметры кодирования видео, параметры кодирования аудио, идентификацию языка, информацию "pan-and-scan", сведения условного доступа, информацию об авторском праве или другую подобную информацию. Специалист вещания или другой пользователь может задавать дополнительные частные дескрипторы.
[0096] Это раскрытие изобретения предоставляет дескриптор рабочей точки для описания характеристик рабочей точки в потоке битов, согласующимся с Системами MPEG-2. Дескрипторы 108 могут включать в себя дескрипторы рабочих точек для каждой рабочей точки соответствующего потока битов. Как показано на Фиг. 3, дескрипторы 108 включают в себя дескрипторы 110 расширения MVC, дескриптор 112 иерархии и дескрипторы 114 рабочих точек. Каждый из дескрипторов 114 рабочей точки может соответствовать конкретной рабочей точке потока битов и сообщать для рабочей точки значение способности воспроизведения, которое описывает способность воспроизведения, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки, значение способности декодирования, которое описывает способность декодирования, которую необходимо удовлетворить принимающим устройством, для использования рабочей точки, и значение битовой скорости, которое описывает битовую скорость рабочей точки. В элементарных потоках компонентов, связанных с видео, также существует дескриптор иерархии, который предоставляет информацию для идентификации элементов программы, содержащий компоненты иерархически кодированных видео-, аудио- и частных потоков.
[0097] Ниже таблица 1 предоставляет один пример данных, включенных в дескрипторы 110 расширения MVC. Различные поля и разрядности полей, показанных в таблице 1, являются лишь одним примером. В одном примере каждый подпоток битов MVC видео является связанным с соответствующим одним из дескрипторов 110 расширения MVC, который указывает характеристики соответствующего подпотока битов MVC видео. Подпоток битов MVC видео может иметь потребность собрать другие подпотоки битов MVC видео. То есть для того, чтобы декодировать и представить конкретный подпоток битов, клиентское устройство может иметь потребность извлечь и декодировать видеоданные из других подпотоков битов общего потока битов, который включает в себя два подпотока битов.
<b>Таблица 1</b><b>Дескриптор расширения MVC</b>
Синтаксис
Число битов
Символика
MVC_extension_descriptor() {
descriptor_tag
8
uimsbf
descriptor_length
8
uimsbf
average_bit_rate
16
uimsbf
maximum_bitrate
16
uimsbf
reserved
4
bslbf
view_order_index_min
10
bslbf
View_order_index_max
10
bslbf
temporal_id_start
3
bslbf
temporal_id_end
3
bslbf
no_sei_nal_unit_present
1
bslbf
reserved
1
bslbf
}
[0098] В примере таблицы 1 поле метки дескриптора может соответствовать восьмибитному полю метки дескриптора, которое включено в каждый дескриптор, как изложено стандартом Системы MPEG-2, для конкретной идентификации дескриптора. Стандарт Системы MPEG-2 задает определенные метки дескрипторов и отмечает другие значения меток дескрипторов, например значения с 36 по 63, как "зарезервированные". Однако поправка 4 к стандарту Системы MPEG-2 предлагает устанавливать дескриптор расширения MVC в значение "49", которое соответствует одной из зарезервированных меток дескриптора, как указано в спецификации Системы MPEG-2. Таким образом, это раскрытие изобретения предлагает устанавливать значение descriptor_tag дескрипторов 110 расширения MVC в значение "49".
[0099] Снова поле длины дескриптора может соответствовать восьмибитному полю длины дескриптора, которое также включено в каждый дескриптор, как изложено стандартом Системы MPEG-2. Мультиплексор 30 может устанавливать значение поля длины дескриптора, равное числу байт соответствующего одного из дескрипторов 110 расширения MVC, непосредственно следуя полю длины дескриптора. Так как длина дескриптора расширения MVC не изменяется, мультиплексор 30 может устанавливать значение поля длины дескриптора для каждого из дескрипторов 110 расширения MVC в значение восемь для представления присутствия восьми байт информации, следуя полю длины дескриптора.
[0100] Поле средней битовой скорости может содержать шестнадцатибитное поле, которое указывает среднюю битовую скорость, в килобитах в секунду, повторно собранного видеопотока AVC. То есть поле средней битовой скорости описывает среднюю битовую скорость для видеопотока, когда видеопоток собран из составляющих частей транспортного потока или программного потока, которым соответствует один из дескрипторов 110 расширения MVC. В некоторых примерах мультиплексор 30 может устанавливать значение поля средней битовой скорости в ноль для указания того, что средняя битовая скорость не указана одним из дескрипторов 110 расширения MVC.
[0101] Поле максимальной битовой скорости может содержать шестнадцатибитное поле, которое указывает максимальную битовую скорость, в килобитах в секунду, повторно собранного видеопотока AVC. То есть поле максимальной битовой скорости описывает максимальную битовую скорость для видеопотока, когда видеопоток собран из составляющих частей транспортного потока или программного потока, которым соответствует один из дескрипторов 110 расширения MVC. В некоторых примерах мультиплексор 30 может устанавливать значение поля максимальной битовой скорости в ноль для указания того, что максимальная битовая скорость не указана одним из дескрипторов 110 расширения MVC.
[0102] Поле минимального индекса порядка изображений может содержать десятибитное поле, которое указывает минимальное значение индекса порядка изображений всех блоков NAL, содержащихся в связанном подпотоке битов MVC видео. Аналогично поле максимального индекса порядка изображений является десятибитным полем, которое указывает максимальное значение индекса порядка изображений всех блоков NAL, содержащихся в связанном подпотоке битов MVC видео.
[0103] Поле начального временного ID может содержать трехбитное поле, которое указывает минимальное значение temporal_id синтаксического элемента заголовка блока NAL всех блоков NAL, содержащихся в связанном подпотоке битов MVC видео. То есть значение временного ID включено в заголовок для каждого блока NAL. В общем, значение временного ID соответствует конкретной частоте кадров, где относительно большие значения временных ID соответствуют большим частотам кадров. Например, значение '0' для временного ID может соответствовать частоте кадров 15 кадров в секунду (кадр/сек), значение '1' для временного ID может соответствовать частоте кадров 30 кадр/сек. Таким образом, сбор всех картинок, имеющих временной ID, равный 0, в этом примере в набор может быть использован для формирования видеосегмента, имеющего частоту кадров 15 кадр/сек, в то время как сбор всех картинок, имеющих временной ID, равный 0, и всех картинок, имеющих временной ID, равный 1, в другой набор может быть использован для формирования видеосегмента, имеющего частоту кадров 30 кадр/сек. Мультиплексор 30 определяет наименьший временной ID из всех блоков NAL подпотока битов MVC видео и устанавливает значение поля начального временного ID, равным этому определенному наименьшему значению временного ID.
[0104] Конечное поле временного ID может содержать трехбитное поле, которое указывает максимальное значение временного ID синтаксического элемента заголовка блока NAL всех блоков NAL, содержащихся в связанном подпотоке битов MVC видео. Следовательно, мультиплексор 30 определяет наибольший временной ID из всех блоков NAL подпотока битов MVC видео и устанавливает значение начального поля временного ID, равным этому определенному наибольшему значению временного ID.
[0105] Поле отсутствия блока NAL SEI может содержать однобитный флаг, который, когда установлен в значение '1', указывает, что в связанном подпотоке битов MVC видео отсутствуют блоки NAL дополнительной информации по усовершенствованию. Мультиплексор 30 может определять были ли помещены в поток битов один или более блоков NAL дополнительной информации по усовершенствованию и устанавливать значение поля отсутствия блока NAL SEI в значение '1', когда в потоке битов нет блоков NAL SEI, но может устанавливать значение поля отсутствия блока NAL SEI в значение '0', когда по меньшей мере один блок NAL SEI присутствует в потоке битов.
[0106] Ниже таблица 2 предоставляет один пример данных, включенных в дескриптор 112 иерархии. В системах MPEG-2 дескриптор иерархии может быть задан для программного потока видео, которое содержит вложенный программный поток видео. Различные поля и разрядности полей, показанных в таблице 2, предоставлены в качестве одного примера. Значение hierarchy_layer_index задает индекс уровня текущего программного потока, и значение hierarchy_embedded_layer_index идентифицирует зависимый уровень. В проекте MVC программный поток может зависеть от другого программного потока, используя дескриптор иерархии. То есть зависимости между программными потоками могут быть определены на основе данных, включенных в дескриптор иерархии.
<b>Таблица 2</b><b>Дескриптор иерархии</b>
Синтаксис
Число битов
Символика
hierarchy_descriptor() {
Descriptor_tag
8
uimsbf
Descriptor_length
8
uimsbf
reserved
1
bslbf
temporal_scalability_flag
1
bslbf
spatial_scalability_flag
1
bslbf
quality_scalability_flag
1
bslbf
Hierarchy_type
4
Uimsbf
reserved
2
bslbf
Hierarchy_layer_index
6
uimsbf
Tref_present_flag
1
bslbf
reserved
1
bslbf
hierarchy_embedded_layer_index
6
uimsbf
reserved
2
bslbf
hierarchy_channel}
6
uimsbf
[0107] Как отмечено выше, спецификация Системы MPEG-2 указывает, что каждый дескриптор включает в себя поле метки дескриптора и поле длины дескриптора. Следовательно, дескриптор 112 иерархии включает в себя поле метки дескриптора и поле длины дескриптора. В соответствии со спецификацией Системы MPEG-2 мультиплексор 30 может устанавливать значение поля метки дескриптора в значение "4" для дескриптора 112 иерархии.
[0108] Длина дескриптора 112 иерархии может быть определена заранее, так как каждый экземпляр дескриптора 112 иерархии должен включать в себя тоже количество данных. В одном примере мультиплексор 30 может устанавливать значение поля длины дескриптора в значение четыре, указывающее четыре байта в экземпляре дескриптора 112 иерархии, следуя концу поля длины дескриптора.
[0109] Поле типа иерархии описывает иерархическую связь между связанным уровнем иерархии и его вложенным уровнем иерархии. В одном примере мультиплексор 30 устанавливает значение поле типа иерархии на основе иерархической взаимосвязи, например, как описано в таблице 3 ниже. В качестве одного примера, когда масштабируемость применяют в более чем одном направлении, мультиплексор 30 может устанавливать поле типа иерархии в значение "8" ("комбинированная масштабируемость", как показано в таблице 3), и мультиплексор 30 устанавливает значения поля флага временной масштабируемости, поля флага пространственной масштабируемости и поля флага качества масштабируемости согласно данным, извлеченным из пакетов PES и заголовков пакетов PES соответствующих потоков. В общем, мультиплексор 30 может определять зависимости между разными потоками, соответствующими различным изображениям и/или потокам аудиоданных. Мультиплексор 30 может также определять является ли зависимый поток, который содержит уровень усовершенствования, пространственным уровнем, уровнем усовершенствования отношения сигнал-шум (SNR), уровнем усовершенствования качества или другим типов уровня усовершенствования.
[0110] В качестве другого примера для подпотоков битов MVC видео мультиплексор 30 может устанавливать поле типа иерархии в значение '9' ("MVC", как показано в таблице 3) и может устанавливать значения каждого из поля флага масштабируемости, поля флага пространственной масштабируемости и поля флага качества масштабируемости в '1'. В качестве еще одного примера для подпотоков битов базовых изображений MVC мультиплексор 30 может устанавливать поле типа иерархии в значение '15' и может устанавливать значения поля флага масштабируемости, поля флага пространственной масштабируемости и поля флага качества масштабируемости в '1'. В качестве еще одного примера для префиксных подпотоков битов MVC мультиплексор 30 может устанавливать поле типа иерархии в значение '14' и может устанавливать поле флага масштабируемости, поле флага пространственной масштабируемости и поле флага качества масштабируемости в значение '1'.
[0111] Поле индекса уровня иерархии может содержать шестибитное поле, которое задает уникальный индекс связанного элемента программы в таблице иерархий уровней кодирования. Индексы могут быть уникальны в пределах определения одиночной программы. Для подпотоков битов видео видеопотоков AVC, согласующиеся с одним или более профилями, заданными в Приложении G ITU-T Rec. H.264|ISO/IEC 14496-10, этот является индексом элемента программы, который назначен таким образом, что порядок потока битов будет корректным, если связанные представления зависимости SVC подпотоков битов видео одного и того же блока доступа повторно собраны в порядке возрастания hierarchy_layer_index. Для подпотока битов MVC видео видеопотоков AVC, согласующиеся с одним или более профилями, заданными в Приложении H ITU-T Rec. H.264|ISO/IEC 14496-10, этот является индексом элемента программы, который назначен таким образом, что любое из этих значений больше, чем значение hierarchy_layer_index, указанное в дескрипторе иерархии для префиксного подпотока битов MVC.
[0112] Поле индекса вложенного уровня иерархии может содержать шестибитное поле, которое задает индекс таблицы иерархии элемента программы, к которой требуется осуществить доступ до декодирования элементарного потока, связанного с соответствующим экземпляром дескриптора 112 иерархии. Это раскрытие изобретения оставляет значение для поля индекса вложенного уровня иерархии не заданным для случая, когда поле типа иерархии имеет значение 15 (то есть значение, соответствующее базовому уровню).
[0113] Поле канала иерархии может содержать шестибитное поле, которое указывает номер предназначенного канала для связанного элемента программы в упорядоченном наборе каналов передачи. Наиболее надежный канал передачи задают посредством самого нижнего значения поля канала иерархии с учетом определения иерархии общей передачи. Учтите, что данный канал иерархии может быть в одно и то же время назначен нескольким элементам программы.
[0114] Зарезервированные поля таблиц 1 и 2 зарезервированы для будущего использования за счет развития будущих стандартов. Способы этого раскрытия изобретения в данное время не предлагают назначения семантического смысла значениям зарезервированных полей.
[0115] Ниже, таблица 3 иллюстрирует потенциальные значения для поля типа иерархии, описанные ниже:
<b>Таблица 3</b><b>Значения поля типа иерархии</b>
Значение
Описание
0
Зарезервировано
1
Пространственная масштабируемость
2
SNR масштабируемость
3
Временная масштабируемость
4
Разделение данных
5
Поток бита расширения
6
Частный поток
7
Профиль с несколькими изображениями
8
Комбинированная масштабируемость
9
Подпоток битов MVC видео
10-13
Зарезервировано
14
Префиксный подпоток битов MVC
15
Базовый уровень, подпоток битов MVC базового изображения, или подпоток битов AVC видео MVC
[0116] В некоторых примерах дескриптор 112 иерархии может быть использован для сообщения подпотока битов MVC, сообщенного инкрементным подпотоком битов и вложенными подпотоками битов. Вложенные подпотоки включают в себя прямо зависимые подпотоки битов, соответствующие hierarchy_embedded_layer_index, и все вложенные подпотоки битов этого прямо зависимого подпотока битов. В этом раскрытии изобретения изображения, которые содержатся явным образом, называют расширенными изображениями, в то время как изображения, которые вложены, называют зависимыми изображениями.
[0117] В примере, в котором выход мультиплексора 30 содержит программный поток, таблицы 88 специальной информации о программах могут включать в себя структуру программного потока (PSM). PSM может предоставлять описание элементарных потоков в соответствующем программном потоке и взаимосвязи элементарных потоков друг с другом. В некоторых примерах структура программного потока может также соответствовать транспортному потоку. При переноске в соответствующем транспортном потоке структура PSM не должна быть модифицирована. Мультиплексор 30 может указывать, что PSM присутствует в пакете PES посредством установки значения stream_id пакета PES в 0xBC, то есть шестнадцатеричное значение BC, которое соответствует двоичному значению 10111100, или десятичное значение 188.
[0118] Мультиплексор 30 содержит полный список всех программ, доступных в транспортном потоке, в таблице 104 связей программ. Мультиплексор 30 также может встраивать таблицы связей программ а блоки NAL. Мультиплексор 30 может указывать, что блок NAL включает в себя таблицу связей программ посредством назначения блоку NAL значения PID 0. Мультиплексор 30 может вносить в список таблицы 104 связей программ каждую программу вместе со значением PID транспортных пакетов, которые содержат соответствующую таблицу карты программы. Используя такой же указанный выше пример, примерная таблица карты программы, которая указывает элементарные потоки программы номер 3, имеет PID 1001 и другая PMT имеет другой PID 1002. Эти или подобные наборы информации могут быть включены в таблицу 104 связей программ.
[0119] Таблицы 88 специальной информации о программах также включают в себя таблицу 100 сетевой информации (NIT) и таблицу 102 условного доступа (CAT). Программа номер ноль, как указано в PAT, имеет специальное значение. В частности, программа номер ноль может быть использована для указания пути к таблице 100 сетевой информации. Таблица является необязательной и когда присутствует, таблица может предоставлять информацию о физической сети, несущей транспортный поток, такую как частоты каналов, сведения о спутниковом ретрансляторе, характеристики модуляции, отправитель сервиса, имя сервиса и сведения о доступных альтернативных сетях.
[0120] Если какие-либо элементарные потоки внутри транспортного потока являются скремблированными, то должна присутствовать таблица 102 условного доступа. Таблица 102 условного доступа предоставляет сведения использующихся систем(ы) скремблирования и предоставляет значения PID транспортных пакетов, которые содержат информацию управления условным доступом и санкционирующую информацию. Формат этой информации не задан в рамках стандарта Системы MPEG-2.
[0121] На Фиг. 4 показана блок-схема, иллюстрирующая примерный набор данных, которые могут быть включены в один из дескрипторов 114 рабочей точки (фиг. 3). В примере на Фиг. 4 дескриптор 118 рабочей точки включает в себя поле 120 метки дескриптора, поле 122 длины дескриптора, поле 124 частоты кадров, поле 126 числа изображений для отображения, поле 128 числа изображений для декодирования, поля 130 идентификаторов изображений, поле 132 средней битовой скорости, поле 134 максимальной битовой скорости, поле 136 временного идентификатора и поля 138 зарезервированных хвостовых битов.
[0122] В примере на Фиг. 4 поле 124 частоты кадров и поле 126 числа изображений для воспроизведения соответствуют примерному значению способности воспроизведения, поле 128 числа изображений для декодирования соответствует примерному значению способности декодирования, и поле 132 средней битовой скорости и поле 134 максимальной битовой скорости соответствуют примерному значению битовой скорости. Дескриптор 118 рабочей точки является всего лишь одним примером структуры данных, которая может быть использована для сообщения характеристик рабочей точки, таких как способность воспроизведения, способность декодирования и битовая скорость. На Фиг. 5 и 6 ниже предоставлены альтернативные примеры дескрипторов рабочих точек, которые сообщают эти характеристики.
[0123] Как описано выше, спецификация Системы MPEG-2 указывает, что каждый дескриптор имеет поле метки дескриптора и поле длины дескриптора, каждое по 8 битов. Таким образом, мультиплексор 30 (Фиг. 1) может назначать значение полю 120 метки дескриптора, указывающее дескриптор рабочей точки MVC. Мультиплексор 30 может также определять число изображений для рабочей точки и число зарезервированных бит для дескриптора рабочей точки и затем вычислять длину дескриптора 118 рабочей точки в байтах, следуя полю 122 длины дескриптора. Мультиплексор 30 может назначать это вычисленное значение длины полю 122 длины дескриптора при создании экземпляра дескриптора 118 рабочей точки.
[0124] Поле 124 частоты кадров может содержать 16-битное поле, которое указывает максимальную частоту кадров, в кадр/256 секунд, повторно собранного видеопотока AVC. То есть мультиплексор 30 может вычислять максимальную частоту кадров в 256 секундный период времени, чтобы устанавливать значение поля 124 частоты кадров. В некоторых примерах деление на 256 может приводить к конвертации значения с плавающей запятой в целочисленное значение. В другом примере могут быть использованы отличные от 256 секунд периоды времени. 256 секундный период времени, описанный с учетом поля 124 частоты кадров, является всего лишь одним потенциальным примером, для которого может быть вычислена максимальная частота кадров рабочей точки.
[0125] Поле 126 числа изображений для отображения может содержать десятибитное поле, которое указывает значение числа изображений, намеченных для вывода повторно собранного видеопотока AVC. В общем, поле 126 числа изображений для отображения представляет число изображений, подлежащих отображению для соответствующей рабочей точки. Так как разные дисплеи могут быть способны отображать разное число изображений, клиентское устройство может использовать значение поля 126 числа изображений для отображения, чтобы выбирать рабочую точку, которая имеет столько изображений, подлежащих отображению, сколько возможно на дисплее для клиентского устройства. Например, если клиентское устройство способно отображать четыре изображения, клиентское устройство может выбирать рабочую точку с полем числа изображений для отображения, имеющим значение, указывающее, что будет отображено четыре изображения для соответствующей рабочей точки. Следовательно, поле 126 числа изображений для отображения может быть включено как часть значения способности воспроизведения. Аналогично мультиплексор 30 может устанавливать значение поля 126 числа изображений для отображения согласно числу изображений, подлежащих отображению для рабочей точки.
[0126] Поле 128 числа изображений для декодирования может содержать десятибитное поле, которое указывает значение числа изображений, требуемых для декодирования повторно собранного видеопотока AVC. Этот значение может отличаться от числа изображений, подлежащих отображению, указанных полем 126 числа изображений для отображения. Это может возникнуть из-за определенных изображений, требуемых для декодирования в результате зависимостей изображений, но которые в действительности не отображают.
[0127] Вкратце ссылаясь на Фиг. 7, в качестве примера изображения S0 и S1 могут быть изображениями, которые подлежат отображению для рабочей точки. Изображение S0 может быть декодировано непосредственно без декодирования каких-либо других изображений. Однако чтобы декодировать изображение S1, также должен быть декодировано изображение S2, так как изображение S1 включает в себя данные предсказания, относящиеся к изображению S2. Следовательно, в этом примере поле 126 числа изображений для воспроизведения будет иметь значение "два", но поле 128 числа изображений для декодирования будет иметь значение "три". В некоторых примерах изображение, подлежащее отображению, может быть интерполировано из одного или более изображений, так что число изображений, подлежащих отображению, может быть больше, чем число изображений, подлежащих декодированию. То есть используя базовый изображения и информацию о глубине, видеодекодер 48 (Фиг. 1) может интерполировать второе изображение. Видеодекодер 48 может использовать два или более изображений для вычисления информации о глубине для интерполяции нового изображения, или видеодекодер 48 может принимать информацию о глубине для изображения от исходного устройства 20.
[0128] Поле 128 числа изображений для декодирования может соответствовать значению способности декодирования в том, что декодер клиентского устройства (такой как видеодекодер 48 целевого устройства 40) должен быть способен декодировать число изображений, равное значению поля 128 числа изображений для декодирования. Следовательно, клиентское устройство может выбирать рабочую точку, имеющую поле числа изображений для декодирования, представляющее число изображений, которое видеодекодер клиентского устройства способен декодировать.
[0129] Дескриптор 118 рабочей точки на Фиг. 4 также включает в себя поля 130 идентификаторов изображений. Каждое из полей 130 идентификаторов изображений может содержать десятибитное поле, которое указывает значение view_id блоков NAL, содержащихся в повторно собранном видеопотоке AVC. Таким образом, идентификаторы изображений каждого отображаемого изображения для рабочей точки сообщают, используя поля 130 идентификаторов изображений. То есть идентификаторы изображений полей 130 идентификаторов изображений соответствуют отображаемым изображениям. Таким образом, изображения, которые декодируют, но не отображают, не сообщают посредством полей 130 идентификаторов изображений, в примере на Фиг. 4.
[0130] Поле 132 средней битовой скорости может содержать 16-битное поле, которое указывает среднюю частоту битов, в килобитах в секунду, повторно собранного видеопотока AVC. Когда установлено в 0, среднюю битовую скорость не указывают. То есть значение ноль для поля 132 средней битовой скорости предполагает, что поле 132 средней битовой скорости не должно быть использовано для определения средней битовой скорости повторно собранного видеопотока AVC.
[0131] Поле 134 максимальной битовой скорости может содержать 16-битное поле, которое указывает максимальную битовую скорость, в килобитах в секунду, повторно собранного видеопотока AVC. Когда установлено в 0, максимальную битовую скорость не указывают. То есть когда значение поля 134 максимальной битовой скорости установлено в ноль, поле 134 максимальной битовой скорости не должно быть использовано для определения максимальной битовой скорости повторно собранного видеопотока AVC.
[0132] Поле 136 временного идентификатора может содержать трехбитное поле, которое указывает значение temporal_id, соответствующее частоте кадров повторно собранного видеопотока AVC. То есть temporal_id может быть использован для определения частоты кадров повторно собранного видеопотока AVC, как рассмотрено выше.
[0133] Примерный дескриптор 118 рабочей точки также включает в себя поля 138 зарезервированных хвостовых битов. В одном примере, например, как показано в таблице 4 ниже, число зарезервированных хвостовых битов может быть использовано как для дополнительного сообщения, так и для заполнения дескриптора 118 рабочей точки, так чтобы дескриптор 118 рабочей точки заканчивался на границе байта. Например, как рассмотрено выше, дескриптор 118 рабочей точки может использовать десять битов для представления идентификатора изображения каждого отображаемого изображения. Статичное число битов помимо битов, использованных для идентификаторов изображений и зарезервированных хвостовых битов, в этом примере составляет 87. Таким образом, для гарантии того, что дескриптор 118 рабочей точки заканчивается на границе байта (то есть имеет число битов, которое делится без остатка на восемь), мультиплексор 30 может добавлять некоторое число хвостовых битов согласно следующей формуле:
хвостовые биты = (1+6*num_display_views)%8,
где '%' представляет математический оператор остатка целочисленного деления. То есть A%В дает в результате остаток A, деленный на B, так что остаток находится в диапазоне целых чисел между 0 и B-1.
[0134] Таблица 4 обобщает примерный набор данных, которые могут быть включены в пример дескриптора 118 рабочей точки на Фиг. 4.
<b>Таблица 4</b><b>Дескриптор рабочей точки MVC</b>
Синтаксис
Число битов
Символика
MVC_op_descriptor(3 {
descriptor_tag
8
uimsbf
descriptor_length
8
uimsbf
frame_rate
16
uimsbf
num_display_views
10
uimsbf
num_decode_views
10
uimsbf
for (i=0; i<num_display_views; i++) {
view_id
10
uimsbf
}
average_bit_rate
16
uimsbf
maximum_bitrate
16
uimsbf
temporal_id
3
uimsbf
for(i=0;i<(l+6*num_display_views)%8;i++) {
reserved_bit
1
bslbf
}
}
[0135] На Фиг. 5 показана блок-схема, иллюстрирующая альтернативный примерный набор данных, которые могут быть включены в один из дескрипторов 114 рабочей точки (фиг. 3). В общем, каждый из дескрипторов 114 рабочих точек должен иметь общий формат, так чтобы клиентское устройство могло быть выполнено с возможностью приема дескрипторов рабочих точек единого формата. Таким образом, каждый из дескрипторов 114 рабочих точек может иметь формат, аналогичный дескриптору рабочей точки на Фиг. 4, Фиг. 5 или Фиг. 6, или другой общий формат, который включает в себя аналогичные данные для сообщения.
[0136] В примере на Фиг. 5 дескриптор 140 рабочей точки включает в себя поле 142 метки дескриптора, поле 144 длины дескриптора, поле 146 profile_IDC, поле 148 level_IDC, поле 149 частоты кадров, поле 150 числа изображений для отображения, поле 152 числа изображений для декодирования, поле 154 средней битовой скорости, поле 156 максимальной битовой скорости, поле 158 временного идентификатора, поле 160 зарезервированного бита, поля 162 индексов порядка изображений, поля 164 идентификаторов изображений и поля 166 зарезервированных хвостовых битов. IDC означает "указатель". Как разъяснено ниже, пример дескриптора 140 рабочей точки в явной форме сообщает значения profile_idc и level_idc для рабочей точки, равно как и информацию того, как собрана рабочая точка.
[0137] Поле 150 числа изображений для отображения и поле 149 частоты кадров соответствуют значению способности воспроизведения, сообщенному дескриптором 140 рабочей точки. Поле 146 profile_IDC, поле 148 level_IDC и поле 152 числа изображений для декодирования в примере на Фиг. 5 представляют примеры данных, которые могут соответствовать значению способности декодирования, сообщенному дескриптором 140 рабочей точки. Поле 154 средней битовой скорости и поле 156 максимальной битовой скорости соответствуют значению битовой скорости, сообщенному дескриптором 140 рабочей точки.
[0138] Как описано выше, спецификация Системы MPEG-2 указывает, что каждый дескриптор имеет поле метки дескриптора и поле длины дескриптора, каждое из которых может составлять 8 битов в длину. Таким образом, мультиплексор 30 (Фиг. 1) может назначать значение полю 142 метки дескриптора, указывающее дескриптор рабочей точки MVC. Мультиплексор 30 может также определять число изображений для рабочей точки и число зарезервированных бит для дескриптора рабочей точки, и затем вычислять длину дескриптора 140 рабочей точки в байтах, следуя полю 144 длины дескриптора. Мультиплексор 30 может назначать это вычисленное значение длины полю 144 длины дескриптора при создании экземпляра дескриптора 140 рабочей точки.
[0139] Поле 146 profile_IDC может содержать восьмибитное поле, которое указывает profile_IDC рабочей точки, повторно собранной за счет информации, данной в дескрипторе 140 рабочей точки. Поле 148 level_IDC может содержать восьмибитное поле, которое указывает level_IDC рабочей точки, повторно собранной за счет информации, данной в дескрипторе 140 рабочей точки.
[0140] Поле 149 частоты кадров может содержать 16-битное поле, которое указывает максимальную частоту кадров, в кадр/256 секунд, повторно собранного видеопотока AVC. То есть мультиплексор 30 может вычислять максимальную частоту кадров в 256 секундный период времени, чтобы устанавливать значение поля 149 частоты кадров. Как и в случае поля 124 частоты кадров, в других примерах для поля 149 частоты кадров могут быть использованы другие периоды времени кроме 256 секунд.
[0141] Поле 150 числа изображений для отображения может содержать десятибитное поле, которое указывает значение числа изображений, намеченных для вывода повторно собранного видеопотока AVC. В общем, поле 150 числа изображений для отображения представляет число изображений, подлежащих отображению для соответствующей рабочей точки. Поле 152 числа изображений для декодирования может содержать десятибитное поле, которое указывает значение числа изображений, требуемых для декодирования повторно собранного видеопотока AVC. Этот значение может отличаться от числа изображений, подлежащих отображению, указанных полем 150 числа изображений для отображения. Это может возникнуть из-за определенных изображений, требуемых для декодирования в результате зависимостей изображений, но которые в действительности не отображают, например, как описано выше с учетом поля 128 числа изображений для декодирования.
[0142] Поле 154 средней битовой скорости может содержать 16-битное поле, которое указывает среднюю частоту битов, в килобитах в секунду, повторно собранного видеопотока AVC. Когда установлено в 0, среднюю битовую скорость не указывают. То есть значение ноль для поля 154 средней битовой скорости предполагает, что поле 154 средней битовой скорости не должно быть использовано для определения средней битовой скорости повторно собранного видеопотока AVC. Поле 156 максимальной битовой скорости может содержать 16-битное поле, которое указывает максимальную битовую скорость, в килобитах в секунду, повторно собранного видеопотока AVC. Когда установлено в 0, максимальную битовую скорость не указывают. То есть, когда значение поля 156 максимальной битовой скорости установлено в ноль, поле 156 максимальной битовой скорости не должно быть использовано для определения максимальной битовой скорости повторно собранного видеопотока AVC.
[0143] Поле 158 временного идентификатора может содержать трехбитное поле, которое указывает значение temporal_id, соответствующее частоте кадров повторно собранного видеопотока AVC. То есть temporal_id может быть использован для определения частоты кадров повторно собранного видеопотока AVC, как рассмотрено выше.
[0144] Дескриптор 140 рабочей точки также включает в себя поля 162 индексов порядка изображений и поля 164 идентификаторов изображений. Каждое из полей 162 индексов порядка изображений может содержать десятибитное поле, которое указывает значение индекса порядка изображений блоков NAL, содержащихся в рабочей точке. Клиентское устройство может повторно собирать блоки NAL, соответствующие всем сообщенным значениям view_order_index, сообщенным в дескрипторе 140 рабочей точки посредством поля 162 индексов порядка изображений. Поля 162 индексов порядка изображений включают в себя поля индексов порядка изображений для каждого из изображений, подлежащих декодированию. Данное значение view_order_index клиентское устройство может извлекать соответствующие блоки NAL из элементарных потоков, так как дескриптор расширения MVC сообщает диапазон значений индексов порядка изображений в этом элементарном потоке, и диапазон охватывает значение view_order_index, сообщенное в дескрипторе рабочей точки.
[0145] Каждое из полей 164 идентификаторов изображений может содержать десятибитное поле, которое указывает значение view_id блоков NAL, содержащихся в повторно собранном видеопотоке AVC. Таким образом, идентификаторы изображений каждого отображаемого изображения для рабочей точки сообщают, используя поля 164 идентификаторов изображений. То есть идентификаторы изображений полей 164 идентификаторов изображений соответствуют отображаемым изображениям. Таким образом, изображения, которые декодируют, но не отображают, не сообщают посредством полей 164 идентификаторов изображений, в примере на Фиг. 5.
[0146] Дескриптор 140 рабочей точки также включает в себя поля 166 зарезервированных хвостовых битов. Дескриптор 140 рабочей точки может включать в себя хвостовые биты в качестве заполняющих, так что число битов в дескрипторе 140 рабочей точки делят без остатка на восемь. Так как число полей индексов порядка изображений и полей идентификаторов изображений может варьироваться, число хвостовых битов, которые мультиплексор 30 включает в дескриптор 140 рабочей точки, может варьироваться соответственно. Например, число хвостовых битов может быть определено согласно следующей формуле:
хвостовые биты = (6*(num_display_views+num_decode_views))%8,
где '%' представляет оператор остатка целочисленного деления.
[0147] Таблица 5 обобщает примерный набор данных, которые могут быть включены в примерный дескриптор 140 рабочей точки на Фиг. 5.
<b>Таблица 5</b><b>Дескриптор рабочей точки MVC</b>
Синтаксис
Число битов
Символика
MVC_op_descriptorQ {
descriptor_tag
8
uimsbf
descriptor_length
8
uimsbf
profile_idc
8
uimsbf
level_idc
8
uimsbf
frame_rate
16
uimsbf
num_display_views
10
uimsbf
num_decode_views
10
uimsbf
average_bit_rate
16
maximum_bitrate
16
uimsbf
temporal_id
3
uimsbf
reserved_bit
1
bslbf
for (i=0; i< num_decode_views; i++) {
view_order_index
10
uimsbf
}
for (i=0; i<num_display_views; i++) {
view_id
10
uimsbf
}
for (i=0; i<6*(num_display_views+num_decode_views)%8; i++) {
reserved_bit
1
bslbf
}
}
[0148] На Фиг. 6 показана блок-схема, иллюстрирующая другой альтернативный примерный набор данных, которые могут быть включены в один из дескрипторов 114 рабочей точки (фиг. 3). В примере на Фиг. 6 дескриптор 170 рабочей точки включает в себя поле 172 метки дескриптора, поле 174 длины дескриптора, поле 176 profile_IDC, поле 178 level_IDC, поле 180 частоты кадров, поле 182 числа изображений для отображения, поле 184 числа изображений для декодирования, поле 186 средней битовой скорости, поле 188 максимальной битовой скорости, поле 190 временного идентификатора, поле 192 зарезервированного бита, поле 194 идентификатора рабочей точки, поле 196 зависимого флага рабочей точки, необязательное поле 198 идентификатора зависимой рабочей точки, поля 200 индексов порядка изображений, поля 202 идентификаторов изображений и поля 204 зарезервированных хвостовых битов. Как описано ниже, дескриптор 170 рабочей точки предоставляет примерный дескриптор рабочей точки для рабочей точки, которая зависит от другой рабочей точки и которая сообщает дополнительные изображения, требуемые для декодирования.
[0149] Поле 182 числа изображений для отображения и поле 180 частоты кадров соответствуют значению способности воспроизведения, сообщенному дескриптором 140 рабочей точки. Поле 176 profile_IDC, поле 178 level_IDC и поле 184 числа изображений для декодирования в примере на Фиг. 6 представляют примеры данных, которые могут соответствовать значению способности декодирования, сообщенному дескриптором 140 рабочей точки. Поле 154 средней битовой скорости и поле 156 максимальной битовой скорости соответствуют значению битовой скорости, сообщенному дескриптором 140 рабочей точки.
[0150] Как описано выше, спецификация Системы MPEG-2 указывает, что каждый дескриптор имеет поле метки дескриптора и поле длины дескриптора, каждое по 8 битов. Таким образом, мультиплексор 30 (Фиг. 1) может назначать значение полю 172 метки дескриптора, указывающее дескриптор рабочей точки MVC. Мультиплексор 30 может также определять число изображений для рабочей точки и число зарезервированных бит для дескриптора рабочей точки и затем вычислять длину дескриптора 170 рабочей точки в байтах, следуя полю 174 длины дескриптора. Мультиплексор 30 назначает это вычисленное значение длины полю 174 длины дескриптора при создании экземпляра дескриптора 140 рабочей точки.
[0151] Поле 176 profile_IDC может содержать восьмибитное поле, которое указывает profile_idc рабочей точки, повторно собранной посредством информации, данной в дескрипторе 170 рабочей точки. Поле 178 level_IDC может содержать восьмибитное поле, которое указывает level_idc рабочей точки, повторно собранной посредством информации, данной в дескрипторе 170 рабочей точки.
[0152] Поле 180 частоты кадров может содержать 16-битное поле, которое указывает максимальную частоту кадров, в кадр/256 секунд, повторно собранного видеопотока AVC. То есть мультиплексор 30 может вычислять максимальную частоту кадров в 256 секундный период времени, чтобы устанавливать значение поля 149 частоты кадров. Как и в случае поля 124 частоты кадров, в других примерах для поля 180 частоты кадров могут быть использованы другие периоды времени кроме 256 секунд.
[0153] Поле 182 числа изображений для отображения может содержать десятибитное поле, которое указывает значение числа изображений, намеченных для вывода повторно собранного видеопотока AVC. В общем, поле 182 числа изображений для отображения представляет число изображений, подлежащих отображению для соответствующей рабочей точки. Поле 184 числа изображений для декодирования может содержать десятибитное поле, которое указывает значение числа изображений, требуемых для декодирования повторно собранного видеопотока AVC. Этот значение может отличаться от числа изображений, подлежащих отображению, указанных полем 182 числа изображений для отображения. Это может возникнуть из-за определенных изображений, требуемых для декодирования в результате зависимостей изображений, но которые в действительности не отображают, например, как описано выше с учетом поля 128 числа изображений для декодирования.
[0154] Поле 186 средней битовой скорости может содержать 16-битное поле, которое указывает среднюю частоту битов, в килобитах в секунду, повторно собранного видеопотока AVC. Когда установлено в 0, среднюю битовую скорость не указывают. То есть значение ноль для поля 186 средней битовой скорости предполагает, что поле 186 средней битовой скорости не должно быть использовано для определения средней битовой скорости повторно собранного видеопотока AVC. Поле 188 максимальной битовой скорости может содержать 16-битное поле, которое указывает максимальную битовую скорость, в килобитах в секунду, повторно собранного видеопотока AVC. Когда установлено в 0, максимальную битовую скорость не указывают. В частности, когда значение поля 188 максимальной битовой скорости установлено в ноль, поле 188 максимальной битовой скорости не должно быть использовано для определения максимальной битовой скорости повторно собранного видеопотока AVC.
[0155] Поле 190 временного идентификатора может содержать трехбитное поле, которое указывает значение temporal_id, соответствующее частоте кадров повторно собранного видеопотока AVC. То есть temporal_id может быть использован для определения частоты кадров повторно собранного видеопотока AVC, как рассмотрено выше. Поле 192 зарезервированного бита соответствует одиночному биту, который зарезервирован для будущего использования.
[0156] Дескриптор 170 рабочей точки также включает в себя поле 194 идентификатора рабочей точки и поле 196 зависимого флага рабочей точки. Поле 194 идентификатора рабочей точки может содержать десятибитное поле, которое указывает идентификатор рабочей точки, описанной дескриптором 170 рабочей точки. Поле 196 зависимого флага рабочей точки является флагом одиночного бита, который указывает, сообщена ли зависимость текущей рабочей точки от другой рабочей точки. Если зависимый флаг 196 рабочей точки имеет значение "единица" (или "истина"), то зависимость сообщена; если значение зависимого флага 196 рабочей точки "ноль" (или "ложь"), то зависимость не сообщена.
[0157] Когда значение зависимого флага 196 рабочей точки "истина" или "единица", дескриптор 170 рабочей точки дополнительно включает в себя поле 198 идентификатора зависимой рабочей точки. Когда присутствует, поле 198 идентификатора рабочей точки может содержать десятибитное поле, которое указывает идентификатор рабочей точки, от которой зависит текущий дескриптор. То есть, когда мультиплексор 30 определяет, что дескриптор 170 рабочей точки соответствует рабочей точке, которая зависит от другой рабочей точки, мультиплексор 30 устанавливает значение зависимого флага рабочей точки в "истина" или "единица" и затем сообщает идентификатор рабочей точки, от которой зависит рабочая точка, соответствующая дескриптору 170 рабочей точки.
[0158] Дескриптор 170 рабочей точки также включает в себя поля 200 индексов порядка изображений и поля 202 идентификаторов изображений. Каждое из полей 202 индексов порядка изображений может содержать десятибитное поле, которое указывает значение индекса порядка изображений блоков NAL, содержащихся в текущей рабочей точке с идентификатором operation_point_id, но не содержащихся в рабочей точке с идентификатором dependent_operation_point_id. Клиентское устройство может повторно собирать блоки NAL, соответствующие всем сообщенным значениям view_order_index, сообщенным в дескрипторе 170 рабочей точки посредством поля 200 индексов порядка изображений. Поля 200 индексов порядка изображений включают в себя поля индексов порядка изображений для каждого из изображений, подлежащих декодированию. Данное значение view_order_index клиентское устройство может извлекать соответствующие блоки NAL из элементарных потоков, так как дескриптор расширения MVC сообщает диапазон значений индексов порядка изображений в этом элементарном потоке, и диапазон охватывает значение view_order_index, сообщенное в дескрипторе рабочей точки. Рабочая точка, сообщенная в дескрипторе 170 рабочей точки, повторно собирают посредством блоков NAL, соответствующих всем сообщенным значениям view_order_index полей 200 индексов порядка изображений, и блоков NAL, вмещенных рабочей точкой с идентификатором dependent_operation_point_id.
[0159] Каждое из полей 202 идентификаторов изображений может содержать десятибитное поле, которое указывает значение view_id блоков NAL, содержащихся в повторно собранном видеопотоке AVC. Таким образом, идентификаторы изображений каждого отображаемого изображения для рабочей точки сообщают, используя поля 202 идентификаторов изображений. То есть идентификаторы изображений полей 164 идентификаторов изображений соответствуют отображаемым изображениям. Таким образом, изображения, которые декодируют, но не отображают, не сообщают посредством полей 202 идентификаторов изображений в примере на Фиг. 5.
[0160] Дескриптор 170 рабочей точки также включает в себя поля 204 зарезервированных хвостовых битов. Дескриптор 170 рабочей точки может включать в себя хвостовые биты в качестве заполняющих, так что число битов в дескрипторе 170 рабочей точки делят без остатка на восемь. Так как число полей индексов порядка изображений и полей идентификаторов изображений может варьироваться, число хвостовых битов, которые мультиплексор 30 включает в дескриптор 170 рабочей точки, может варьироваться соответственно. Например, число хвостовых битов может быть определено согласно следующей формуле:
хвостовые биты = (6*(num_display_views + num_decode_views)) % 8,
где '%' представляет оператор остатка целочисленного деления.
[0161] Таблица 6 ниже обобщает примерный набор данных, которые могут быть включены в примерный дескриптор 170 рабочей точки на Фиг. 6.
<b>Таблица 6</b><b>Дескриптор рабочей точки MVC</b>
Синтаксис
Число битов
Символика
MVC_op_descriptor() {
descriptor_tag
8
uimsbf
descriptor_length
8
uimsbf
profile_idc
8
uimsbf
level_idc
8
uimsbf
frame_rate
16
uimsbf
num_display_views
10
uimsbf
num_decode_views
10
uimsbf
average_bit_rate
16
maximum_bitrate
16
uimsbf
temporal_id
3
uimsbf
reserved_bit
1
bslbf
operation_point_id
10
uimsbf
op_dependent_flag
1
bslbf
if (op_dependent_flag)
dependent_operation_point_id
10
10
for (i=0; i<num_decode_views; i++) {
view_order_index
10
uimsbf
}
for (i=0; i<num_display_views; i++) {
view id
10
uimsbf
}
for (i=0 ; i<6*(num_display_views+num_decode_views)%8; i++) {
reserved_bit
1
bslbf
}
}
[0162] В качестве еще одной альтернативы исходное устройство 20 (фиг. 1) сообщает характеристики рабочей точки, используя структуру данных, отличную от дескриптора рабочей точки. Например, исходное устройство 20 может сообщать значение способности воспроизведения, которое описывает способность воспроизведения, удовлетворяющую принимающее устройство для использования рабочей точки MVC, значение способности декодирования, которое описывает способность декодирования, удовлетворяющую принимающее устройство для использования рабочей точки MVC, и значение битовой скорости, которое описывает битовую скорость рабочей точки MV используя модифицированный дескриптор расширения MVC.
Ниже, таблица 7 иллюстрирует пример такого модифицированного дескриптора расширения MVC.
<b>Таблица 7</b><b>Дескриптор расширения MVC</b>
Синтаксис
Число битов
Символика
MVC_extension_descriptor() {
descriptor_tag
8
uimsbf
descriptor_length
8
uimsbf
frame_rate
16
uimsbf
num_display_views
16
uimsbf
num_decode_views
10
uimsbf
for (i=0; i< num display views; i++) {
view_id
10
uimsbf
}
average_bit_rate
16
uimsbf
maximum_bitrate
16
uimsbf
reserved
4
bslbf
view_order_index_min
10
bslbf
view_order_index_max
10
bslbf
temporal_id_start
3
bslbf
temporal_id_end
3
bslbf
no_sei_nal_unit_present
1
bslbf
reserved
1
bslbf
}
[0163] Мультиплексор 30 (Фиг. 2) может конструировать дескрипторы 110 расширения MVC согласно синтаксису, заданному в таблице 7. В общем, семантика синтаксических элементов таблицы 7 такая же, как и у элементов с общими названиями, описанных с учетом таблицы 1 выше. Пример таблицы 7 включает в себя дополнительные элементы вдобавок к элементам таблицы 1, а именно поле частоты кадров, поле числа изображений для отображения, поле числа изображений для декодирования и поля идентификаторов изображений для каждого изображения рабочей точки, которой соответствует дескриптор расширения MVC.
[0164] Поле частоты кадров может содержать шестнадцатибитное поле, которое указывает максимальную частоту кадров, в кадр/256 секунд, повторно собранного видеопотока AVC. Поле числа изображений для отображения "num_display_views" может содержать десятибитное поле, которое указывает значение числа изображений, намеченных для вывода повторно собранного видеопотока AVC. Поле числа изображений для декодирования "num_decode_views" может содержать десятибитное поле, которое указывает значение числа изображений, требуемых для декодирования повторно собранного видеопотока AVC. Каждое из полей идентификаторов изображений "view_id" может содержать десятибитное поле, которое указывает значение view_id блоков NAL для соответствующего изображения, содержащихся в повторно собранном видеопотоке AVC.
[0165] В некоторых примерах один или более дескрипторов рабочих точек могут включать в себя значения, которые указывают максимальное значение временного идентификатора и значение максимальной частоты кадров все рабочих точек MVC потока битов. В некоторых примерах максимальное значение временного идентификатора и значение максимальной частоты кадров всех рабочих точек MVC потока битов могут быть сообщены в дескрипторе рабочей точки MVC.
[0166] На фиг. 7 показана концептуальная схема, иллюстрирующая примерный образец предсказания MVC. В примере на Фиг. 7 проиллюстрированы восемь изображений (имеющие ID изображений с "S0" по "S7"), и для каждого изображения проиллюстрированы двенадцать временных расположений (с "T0" по "T11"). То есть каждый ряд на Фиг. 7 соответствует изображению, в то время как каждый столбец указывает временное расположение.
[0167] Несмотря на то, что MVC имеет так называемое базовое изображение, который является декодируемым декодерами H.264/AVC, и изображения стереопары, должны также поддерживаться посредством MVC, преимущество MVC состоит в том, что оно может поддерживать пример, который использует более чем два изображения в качестве входа 3D видео и декодирует это 3D видео, представленное множеством изображений. Средство воспроизведения клиента, имеющее MVC декодер, может ожидать 3D видеоконтент с множеством изображений.
[0168] Кадры на Фиг. 7 указаны рядом с указателем каждого ряда и каждого столбца на Фиг. 7, используя заштрихованный блок, включающий в себя букву, обозначающую является ли соответствующий кадр внутренне кодированным (то есть I-кадром), или внешне кодированным в одном направлении (то есть как P-кадр) или нескольких направлениях (то есть как B- кадр). В общем, предсказания указаны стрелками, где кадр, на который они направлены, использует в качестве образца для предсказания объект, от которого они направлены. Например, P-кадр изображения S2 во временном расположении T0 предсказывают на основе I-кадра изображения S0 во временном расположении T0.
[0169] Как и в случае кодирования одного изображения видео, кадры видеопоследовательности кодирования нескольких изображений видео могут быть кодированы с предсказанием с учетом кадров в разных временных расположениях. Например, b-кадр изображения S0 во временном расположении T1 имеет направленную на него стрелку от I-кадра изображения S0 во временном расположении T0, указывая, что b-кадр предсказан исходя из I-кадра. Дополнительно, однако, в контексте кодирования нескольких изображений видео кадры могут быть предсказаны посредством предсказания изменений между изображениями. То есть компонент изображения может использовать компоненты изображений других изображений для образца. В MVC, например, предсказание изменений между изображениями осуществляют, как если компонент изображения в другом изображении является образцом между предсказаниями. Потенциальные образцы для предсказания изменений между изображениями сообщают в наборе параметров последовательности расширения MVC и могут модифицировать посредством процесса конструирования списка опорных изображений, который обеспечивает возможность гибкого упорядочивания образцов между предсказаниями или образцов предсказания между изображениями.
Ниже, таблица 8 предоставляет примерное определение для набора параметров последовательности расширения MVC.
<b>Таблица 8</b><img file="00000001.tif" he="162" wi="148" img-content="undefined" img-format="tif" />
[0170] На Фиг. 7 предоставлены различные примеры предсказания изменений между изображениями. Кадры изображения S1 в примере на Фиг. 7 проиллюстрированы как предсказанные исходя из кадров в разных временных расположениях изображения S1, равно как предсказанные посредством предсказания изменений между изображениями исходя из кадров изображений S0 и S2 в тех же временных расположениях. Например, b-кадр изображения S1 во временном расположении T1 предсказывают на основе каждого из B-кадров изображения S1 во временных расположениях T0 и T2, равно как b-кадров изображений S0 и S2 во временном расположении T1.
[0171] В примере на Фиг. 7 заглавная буква "B" и строчная буква "b" предназначены для указания разных иерархических взаимосвязей между кадрами, а не разных способов кодирования. В общем, кадры с заглавными буквами "B" относительно более высокие в иерархии предсказания, чем кадры со строчными буквами "b". На Фиг. 7 также проиллюстрированы вариации в иерархии предсказания, используя разные степени штриховки, где кадры с большей величиной штриховки (то есть относительно более темные) являются более высокими в иерархии предсказания, чем те кадры, которые имеют меньшую штриховку (то есть относительно более светлые). Например, все I-кадры на Фиг. 7 проиллюстрированы с полной штриховкой, в то время как P-кадры имеют слегка более светлую штриховку, и B-кадры (кадры со строчной буквой "b") имеют различные степени штриховки относительно друг друга, но всегда более светлую, чем штриховка P-кадров и I-кадров.
[0172] В общем, иерархия предсказания относится к индексам порядка изображений в том отношении, что относительно более высокие в иерархии предсказания кадров должны быть декодированы до декодирования кадров, которые являются относительно более низкими в иерархии, так что те относительно более высокие в иерархии кадров могут быть использованы как опорные кадры во время декодирования относительно более низких в иерархии предсказания кадров. Индекс порядка изображения является индексом, который указывает порядок декодирования компонентов изображения в блоке доступа. Индексы порядка изображений предполагаются в SPS расширения MVC, как указано в Приложении H стандарта H.264/AVC (поправка MVC). В SPS для каждого индекса i сообщают соответствующий view_id. Декодирование компонентов изображений должно следовать возрастающему порядку индексов порядка изображений. Если представлены все изображения, то индексы порядка изображений находятся в последовательном порядке от 0 до num_views_minus_1.
[0173] Таким образом, кадры, использующиеся в качестве опорных кадров, могут быть декодированы до декодирования кадров, которые кодированы со ссылкой на опорные кадры. Индекс порядка изображения является индексом, который указывает порядок декодирования компонентов изображения в блоке доступа. Для каждого индекса порядка изображения i сообщают соответствующий view_id. Декодирование компонентов изображений следует возрастающему порядку индексов порядка изображений. Если представлены все изображения, то набор индексов порядка изображений может содержать последовательно упорядоченный набор от нуля до полного числа изображений минус один.
[0174] Для определенных кадров на одинаковых уровнях иерархии порядок декодирования может не иметь значения относительно друг друга. Например, I-кадр изображения S0 во временном расположении T0 используют в качестве опорного кадра для P-кадра изображения S2 во временном расположении T0, который, в свою очередь, используют в качестве кадра для P-кадра изображения S4 во временном расположении T0. Следовательно, I-кадр изображения S0 во временном расположении T0 должен быть декодирован до P-кадра изображения S2 во временном расположении T0, которое должно быть декодировано до P-кадра изображения S4 во временном расположении T0. Однако между изображениями S1 и S3 порядок декодирования не имеет значения, так как изображения S1 и S3 не зависят друг от друга для предсказания, но зато предсказаны только исходя из изображений, которые являются более высокими в иерархии предсказания. К тому же изображение S1 может быть декодировано до изображения S4 при условии, что изображение S1 декодировано после изображений S0 и S2.
[0175] Таким образом, для описания изображений с S0 по S7 может быть использовано иерархическое упорядочивание. Пусть запись SA>SB означает, что изображение SA должно быть декодировано до изображения SB. Используя эту запись, S0>S2>S4>S6>S7, в примере на Фиг. 7. Также с учетом примера на Фиг. 7 S0>S1, S2>S1, S2>S3, S4>S3, S4>S5 и S6>S5. Возможен любой порядок декодирования для изображений, которые не нарушают эти требования. Следовательно, возможны многие разные порядки декодирования только с определенными ограничениями. Ниже представлены два примерных порядка декодирования, хоть и следует понимать, что возможны многие другие порядки декодирования. В одном примере, проиллюстрированном в таблице 9 ниже, изображения декодируют так скоро, насколько это возможно.
<b>Таблица 9</b>
ID изображения
S0
S1
S2
S3
S4
S5
S6
S7
Индекс порядка изображения
0
2
1
4
3
6
5
7
[0176] Пример таблицы 9 показывает, что изображение S1 может быть декодировано сразу после того, как были декодированы изображения S0 и S2, изображение S3 может быть декодировано сразу после того, как были декодированы изображения S2 и S4, и изображение S5 может быть декодировано сразу после того, как были декодированы изображения S4 и S6.
[0177] Таблица 10 ниже предоставляет другой примерный порядок декодирования, в котором порядок декодирования является таким, что любое изображение, которое используют как опорное для другого изображения, декодируют до изображений, которые не используют как опорные для любого другого изображения.
<b>Таблица 10</b>
ID изображения
S0
S1
S2
S3
S4
S5
S6
S7
Индекс порядка изображения
0
5
1
6
2
7
3
4
[0178] Пример таблицы 10 показывает, что кадры изображений S1, S3, S5, и S7 не выступают в качестве опорных кадров для кадров любых других изображений, и следовательно, изображения S1, S3, S5, и S7 могут быть декодированы после кадров тех изображений, которые используют как опорные кадры, то есть изображения S0, S2, S4 и S6 в примере на Фиг. 7. Относительно друг друга изображения S1, S3, S5 и S7 могут быть декодированы в любом порядке. Следовательно, в примере таблицы 10, изображение S7 кодируют до каждого из изображений S1, S3 и S5.
[0179] Чтобы было ясно, может существовать иерархическая взаимосвязь между кадрами каждого изображения, равно как и между временными расположениями кадров в каждом кадре. С учетом примера на Фиг. 7 кадры во временном расположении T0 являются либо предсказанными посредством внутреннего предсказания, либо предсказанными посредством предсказания изменений между изображениями исходя из кадров других изображений во временном расположении T0. Аналогично кадры во временном расположении T8 являются либо предсказанными посредством предсказания изменений внутри изображения, либо предсказанными посредством предсказания изменений между изображениями исходя из кадров других изображений во временном расположении T8. Следовательно, с учетом временной иерархии временные расположения T0 и T8 находятся на вершине временной иерархии.
[0180] Кадры во временном расположении T4 в примере на Фиг. 7 являются более низкими во временной иерархии, чем кадры временных расположений T0 и T8, так как кадры временного расположения T4 являются B-кодированными со ссылкой на кадры временных расположений T0 и T8. Кадры во временных расположениях T2 и T6 являются более низкими во временной иерархии, чем кадры во временном расположении T4. Наконец, кадры во временных расположениях T1, Т3, T5 и T7 являются более низкими во временной иерархии, чем кадры во временных расположениях T2 и T6.
[0181] В MVC поднабор всего потока битов может быть извлечен для формирования подпотока битов, который все еще согласуется с MVC. Существуют множество возможных подпотоков битов, которые могут потребоваться для специфичного применения, на основе, например, сервиса, предоставленного сервером, производительности, поддержке, и возможностях декодеров одного или более клиентов, и/или привилегии одного или более клиентов. Например, клиент может требовать только три изображения, и может существовать два сценария. В одном примере один клиент может требовать ощущение плавного просмотра и может предпочитать изображения S0, S1 и S2 со значениями view_id, в то время как другой клиент может требовать масштабируемость изображений и предпочитать изображения S0, S2 и S4 со значениями view_id. Если изначально view_id упорядочены с учетом примера таблицы 9, значения индексов порядка изображений составляют {0, 1, 2} и {0, 1, 4} в этих двух примерах соответственно. Учтите, что оба из этих подпотоков битов могут быть кодированы как независимые потоки битов MVC и могут поддерживаться одновременно.
[0182] Может существовать множество подпотоков битов MVC, которые являются декодируемыми MVC декодерами. В теории любая комбинация изображений, которая удовлетворяет следующим двум свойствам, может быть декодирована MVC декодером, совместимым с определенным профилем или уровнем: (1) компоненты изображений в каждом блоке доступа упорядочены в возрастающем порядке индексов порядка изображений, и (2) для каждого изображения в комбинации ее зависимые изображения также включены в комбинацию.
[0183] На Фиг. 8 показана маршрутная карта, иллюстрирующая примерный способ для использования структуры данных, которая сообщает характеристики рабочей точки. То есть способ на Фиг. 8 включает в себя конструирование структур данных для каждой рабочей точки потока битов Системы MPEG-2 исходным устройством, например исходным устройством 20 (Фиг. 1). Способ на Фиг. 8 также включает в себя использование принятых структур данных для выбора рабочей точки, из которой извлекают мультимедийные данные для декодирования и отображения целевым устройством, таким как целевое устройство 40 (Фиг. 1).
[0184] Изначально в примере на Фиг. 8 исходное устройство 20 определяет рабочие точки для программы (210). Например, исходное устройство 20 может выбирать различные поднаборы изображений программы для создания различных рабочих точек, которые представляют клиентские устройства, имеющие различные возможности, например возможности воспроизведения и декодирования. Администратор может взаимодействовать с исходным устройством 20, например, для выбора изображений и создания рабочих точек, которые представляют клиентские устройства, имеющие варьирующиеся способности воспроизведения и декодирования, или другие рабочие точки, которые могут быть созданы автоматически исходным устройством 20.
[0185] После определения рабочих точек для программы исходное устройство 20 может генерировать структуры данных для каждой из рабочих точек в таблице карты программы (212), например, когда поток битов будут вещать как транспортный поток Системы MPEG-2. В качестве альтернативы исходное устройство 20 может генерировать структуры данных в карте программного потока, например, когда поток битов будут вещать как программный поток Системы MPEG-2. В любом случае исходное устройство 20 может генерировать для каждой рабочей точки структуру данных, которая представляет характеристики соответствующей рабочей точки. Структура данных может содержать дескриптор рабочей точки, соответствующий одному из примеров на Фиг. 4-6, например. Таким образом, структура данных может сообщать характеристики воспроизведения, характеристики декодирования и битовую скорость для соответствующей рабочей точки.
[0186] Затем исходное A/V устройство 20 может выводить структуры данных (214), например внутри PMT в примере на Фиг. 8, на клиентское устройство, например целевое устройство 40 (Фиг. 1). Таким образом, исходное устройство 20 может выводить структуры данных как часть потока битов. Исходное устройство 20 может выводить поток битов в виде широковещательной передачи, одноадресной передачи, многоадресной передачи, передачи на любой адрес или другого протокола связи по сети, например по беспроводной или проводной сети, или осуществлять широковещательную передачу на телевизионных частота, например, согласно сигналам, согласующимся со стандартами Комитета улучшенных телевизионных систем (ATSC) или стандартами Комитета национальных телевизионных систем (NTSC). В качестве альтернативы исходное устройство 20 может кодировать поток битов в считываемый компьютером носитель информации, такой как DVD-ROM, диск Blu-ray, флэш-накопитель, магнитный диск или другой носитель информации, и в этом случае исходное устройство 20 может формировать PSM, которая включает в себя структуры данных для рабочих точек и кодировать PSM в считываемый компьютером носитель информации.
[0187] Целевое устройство 40 может в конечном счете принимать PMT (или PSM) от исходного устройства 20 (216). Затем целевое устройство 40 может выбирать одну из рабочих точек на основе характеристик рабочих точек, сообщенных структурами данных, включенными в PMT или PSM (218). В общем, целевое устройство 40 может выбирать рабочую точку, для которой целевое устройство 40 удовлетворяет способностям воспроизведения и декодирования, сообщенным соответствующей структурой данных. Например, целевое устройство 40 может определять способен ли видеовыход 44 осуществлять воспроизведение числа изображений, указанного структурой данных, как числа изображений, подлежащих отображению, с частотой кадров в соответствии со значением способности воспроизведения, сообщенным структурой данных для рабочей точки. Аналогично целевое устройство 40 может определять способен ли видеодекодер 48 декодировать число изображений, подлежащих декодированию, для рабочей точки, которое сообщено структурой данных значения способности декодирования рабочей точки. К тому же в некоторых примерах целевое устройство 40 может использовать битовую скорость, сообщенную в структуре данных, для выбора рабочей точки, которая пригодна для среды транспортировки, например, на основе ограничений полосы пропускания среды транспортировки, из которой целевое устройство 40 принимает поток битов.
[0188] Когда целевое устройство 40 определяет, что целевое устройство 40 способно осуществлять воспроизведение и декодирование более чем одной рабочей точки, целевое устройство 40 может выбирать рабочую точку с наивысшим качеством для декодирования и воспроизведения. Например, целевое устройство 40 может выбирать рабочую точку, имеющую наибольшее число изображений, наибольшую битовую скорость, наибольшую частоту кадров или другие указатели качества для рабочей точки, чтобы определять какую рабочую точку выбрать.
[0189] После выбора рабочей точки целевое устройство 40 может осуществлять выборку данных для рабочей точки из потока битов (220). То есть целевое устройство 40 может извлекать данные для каждого изображения, соответствующего рабочей точке, из программы, включенной в поток битов. В некоторых примерах целевое устройство 40 выбирает данные из одного или более подпотоков битов потока битов для извлечения данных для рабочей точки. После извлечения данных целевое устройство может декодировать и отображать данные для выбранной рабочей точки (222). Видеодекодер 48 может декодировать каждый из изображений, которые подлежат декодированию, для рабочей точки, в то время как видеовыход 44 может отображать каждый из изображений, которые подлежат отображению, для рабочей точки. Отображаемые изображения необязательно могут являться изображениями, которые являются декодированными, как описано выше.
[0190] В одном или более примерах описанные функции могут быть реализованы в аппаратном обеспечении, программном обеспечением, микропрограммном обеспечении или любой комбинации этого. В случае реализации в программном обеспечении функции могут хранить или передавать как одну или более инструкций или код на считываемый компьютером носитель. Считываемые компьютером носители могут включать в себя считываемые компьютером носители информации, такие как среды хранения данных и коммуникационные среды, включающие в себя любую среду, которая облегчает передачу компьютерной программы из одного места в другое. Средами хранения данных могут являться любые доступные среды, к которым можно осуществить доступ посредством одного или более компьютеров или одного или более процессоров для выборки инструкций, кода и/или структур данных для реализации способов, описанных в этом раскрытии изобретения. В качестве примера, а не ограничения, такие считываемые компьютером носители информации могут содержать оперативную память, постоянную память, электрически стираемую программируемую постоянную память, CD-ROM или другое хранилище на оптических дисках, хранилище на магнитных дисках или другие магнитные запоминающие устройства, флэш-память или любой другой носитель, который может быть использован для хранения желаемого программного кода в форме инструкций или структур данных и к которому можно осуществить доступ посредством компьютера. Также любое соединение может быть названо считываемым компьютером носителем. Например, если инструкции передают с Web-сайта, сервера или другого удаленного источника, используя коаксиальный кабель, оптоволоконный кабель, витую пару, цифровую абонентскую линию связи (DSL) или беспроводные технологии, такие как инфракрасная связь, радио и микроволновая, то коаксиальный кабель, оптоволоконный кабель, витая пара, DSL или беспроводные технологии, такие как инфракрасная связь, радио и микроволновая, включаются в определение носителя. Однако следует понимать, что считываемый компьютером носитель информации и среда хранения данных не включают в себя соединения, несущие волны, сигналы промежуточные среды. Оптический диск и магнитный диск, как используется в настоящем документе, включают в себя компакт-диск (CD), лазерный диск, оптический диск, универсальный цифровой диск (DVD), флоппи-диск и blu-ray диск, где магнитные диски обычно воспроизводят данные магнитно, в то время как оптические диски обычно воспроизводят данные оптически с помощью лазера. Комбинации выше сказанного также должны быть включены в объем считываемых компьютером носителей.
[0191] Инструкции могут быть исполнены одним или более процессорами, такими как один или более процессоров цифровой обработки сигналов (DSP), микропроцессоры общего назначения, специализированные интегральные микросхемы (ASIC), программируемые пользователем вентильные матрицы (FPGA) или другим эквивалентом схем интегрированной или дискретной логики. Следовательно, термин "процессор", как используется в настоящем документе, может относится к любой из вышеуказанных структур или любой другой структуре, подходящей для реализации способов, описанных в настоящем документе. К тому же в некоторых аспектах описанная в настоящем документе функциональность может быть предоставлена внутри выделенного аппаратного обеспечения и/или программных модулей, выполненных с возможностью кодирования и декодирования, или включена в комбинированный кодек. Также способы могут быть полностью реализованы в одной и больше схемах или логических элементах.
[0192] Способы этого раскрытия изобретения могут быть реализованы в широком спектре устройств или аппаратов, включающих в себя беспроводную гарнитуру, интегральную схему (IC) или набор IC (например, набор микросхем). Различные компоненты, модули или блоки описаны в этом раскрытии изобретения, чтобы подчеркнуть функциональные аспекты устройств, выполненных с возможностью выполнения раскрытых способов, но не обязательно требовать реализацию посредством разных аппаратных блоков. Скорее, как описано выше, различные блоки могут быть скомбинированы в аппаратном блоке кодека или предоставлены группой взаимодействующих аппаратных блоков, включающих в себя один или более процессоров, как описано выше, совместно с подходящим программным обеспечением и/или микропрограммным обеспечением.
[0193] Были описаны различные примеры. Эти и другие примеры входят в объем следующей формулы изобретения.