ПРЕДОСТАВЛЕНИЕ ДОПОЛНИТЕЛЬНОЙ ИНФОРМАЦИИ ОБРАБОТКИ
PROVIDING ADDITIONAL PROCESSING INFORMATION

Техническая область
Варианты осуществления в целом относятся к обработке медиа-контента и, в частности, к предоставлению дополнительной информации обработки, полезной в связи с обработкой медиа-контента.
Область техники, к которой относится изобретение
Стандарт H.264/MPEG-4, часть 10 или стандарт усовершенствованного кодирования видео (AVC) является современным стандартом кодирования видео. Это гибридный кодек, который использует преимущества устранения избыточности между кадрами и в пределах одного кадра. Выходными данными процесса кодирования являются данные уровня кодирования видео (VCL), которые далее инкапсулируются в блок уровня сетевой абстракции (NAL) до передачи или хранения.
Дополнительная информация улучшения (SEI) предоставляется, чтобы помочь в процессах, связанных с постдекодированием, таким как отображение. Примеры SEI-сообщений включают в себя определение указаний постфильтра и преобразование тона. SEI-сообщения разработаны таким образом, что они не являются обязательными для процесса декодирования. Соответствующие декодеры могут отбрасывать SEI-сообщения, которые для них не понятны. SEI-сообщения в настоящее время инкапсулируются в блок NAL просто как VCL-данные, но не оказывают воздействие на декодирование.
В соответствии с предшествующим уровнем техники должен быть создан файл с конкретным знанием возможностей отображения медиа-терминалов, чтобы гарантировать правильное воспроизведение. Новые возможности отображения, добавляемые через информацию улучшения, т.е. вне петли декодирования, не могут быть выполнены способом обратной совместимости. Примером этого являются подвергнутые пространственному перемежению кадры SEI-сообщений, которые были добавлены в видео H.264, чтобы способствовать визуализации декодированных изображений на трехмерных (3D) устройствах отображения. Эти SEI-сообщения извлекаются из попытки использования существующего двухмерного (2D) кодека, такого как H.264, для кодирования 3D-контента. Пример этого является, где SEI-сообщение описывает, что четные кадры назначаются виду слева и нечетные кадры назначаются виду справа.
SEI-сообщения разработаны способом с возможностью их отбрасывания, когда они поступают на декодирование. Является важным то, однако, что медиа-терминал может правильно интерпретировать эту информацию для вещей вне декодирования, таких как 3D-визуализация. Традиционный медиа-терминал, у которого отсутствует способность понимать эти SEI-сообщения, будет просто игнорировать их и осуществлять визуализацию декодированных изображений на 2D-дисплее, приводящую к существенным артефактам отображения, например скачками между видами слева и справа каждый кадр, для представленного выше примера.
Кроме того, в настоящее время медиа-терминалам требуется декодировать поток битов видео для того, чтобы выяснить, необходимы ли улучшения и какие типы информации улучшения необходимы. Это является проблематичным как для локального воспроизведения, так и для передачи. Например, может быть фильм, который не является полностью отображаемым, и медиа-терминал обнаружит только, что он не может правильно отобразить его, когда он попадет на неизвестное SEI-сообщение. В другом случае, когда он приходит к медиа-передаче, простым и быстрым способом утончения потока битов является удаление всех SEI-сообщений, как не требуемых для декодирования. Это может приводить к прореживанию SEI-сообщений, которые являются существенными для визуализации.
Таким образом, в упомянутой области техники существует общая потребность в эффективной обработке дополнительной информации обработки, такой как SEI-данные, для того чтобы решить или по меньшей мере уменьшить упомянутые проблемы предшествующего уровня техники.
Сущность изобретения
Главной целью является позволить обеспечение дополнительной информации обработки эффективным способом.
Эта и другие цели выполняются посредством вариантов осуществления, раскрываемых здесь.
Кратко, аспект вариантов осуществления относится к способу предоставления дополнительной информации обработки, относящейся к или связанной с кодированным медиа-контентом. Способ включает в себя предоставление псевдоидентификатора медиа-кодека, используемого для кодирования медиа-контента. Дополнительная информация обработки также предоставляется. Дополнительная информация обработки определяет инструкции постдекодирования для обработки декодированного медиа-контента, получаемого посредством декодирования кодированного медиа-контента. Псевдоидентификатор и дополнительная информация обработки совместно организованы в файле для того, чтобы вызывать прекращение декодирования кодированного медиа-контента посредством традиционного медиа-терминала, который не распознает псевдоидентификатор. Соответственно, совместная организация псевдоидентификатора и дополнительной информации обработки в файле позволяет декодирование медиа-контента с использованием медиа-кодека и позволяет обработку постдекодирования декодированного медиа-контента с использованием дополнительной информации обработки посредством медиа-терминала, который распознает псевдоидентификатор.
Другой аспект относится к устройству для предоставления дополнительной информации обработки. Устройство содержит поставщик идентификатора для предоставления псевдоидентификатора медиа-кодека. Поставщик информации осуществляется в устройстве для предоставления дополнительной информации обработки, определяющей инструкции постдекодирования. Устройство также содержит организатор файлов для совместной организации псевдоидентификатора и дополнительной информации обработки в файле таким образом, чтобы вызывать прекращение декодирования кодированного медиа-контента посредством традиционного медиа-терминала, который не распознает псевдоидентификатор. Медиа-терминал, который распознает псевдоидентификатор, сможет, однако, декодировать кодированный медиа-контент с использованием медиа-кодека и далее обрабатывать медиа-контент с последующим декодированием на основе дополнительной информации обработки.
Еще один аспект вариантов осуществления относится к способу обработки медиа-контента. Способ включает в себя прием файла, содержащего псевдоидентификатор и дополнительную информацию обработки. Если псевдоидентификатор, извлекаемый из файла, не распознается, то декодирование кодированного медиа-контента прекращается, так что медиа-контент не будет представлен пользователю. Однако если псевдоидентификатор распознается, то медиа-кодек для использования для декодирования кодированного медиа-контента выбирается на основе идентификатора кодека медиа-кодека, извлекаемого на основе псевдоидентификатора. Кодированный медиа-контент затем декодируется с использованием дополнительного медиа-кодека. Дополнительная информация обработки, извлекаемая из файла, используется для обработки декодированного медиа-контента для получения медиа-контента в форме, подходящей для визуализации для предоставления медиа-презентации для пользователя.
Медиа-терминал раскрывается как еще один аспект вариантов осуществления. Медиа-терминал содержит приемник для приема файла с псевдоидентификатором и дополнительной информацией обработки. Контроллер декодирования медиа-терминала конфигурируется для исследования псевдоидентификатора и определения, является ли псевдоидентификатор распознаваемым посредством медиа-терминала или нет. Если псевдоидентификатор не распознается, то контроллер декодирования дает команду декодеру прекратить или стопить декодирование кодированного медиа-контента. Если вместо этого псевдоидентификатор распознается, то контроллер декодирования выбирает медиа-кодек для использования для декодирования кодированного медиа-контента на основе идентификатора кодека, извлекаемого на основе псевдоидентификатора. Декодер затем конфигурируется для декодирования кодированного медиа-контента с использованием дополнительного медиа-кодека для представления декодированного медиа-контента. Этот декодированный медиа-контент обрабатывается посредством процессора контента на основе дополнительной информации обработки, извлекаемой из файла, чтобы получить медиа-контент в форме, подходящей для визуализации.
Варианты осуществления поэтому обеспечивают эффективный способ предоставления дополнительной информации обработки, который предназначен для использования в соединении с обработкой постдекодирования медиа-контента, чтобы получить медиа-контент в форме, которая позволяет правильную визуализацию и представление пользователю. Традиционные медиа-терминалы, которые не понимают и поэтому не могут использовать дополнительную информацию обработки, лишают возможности визуализации медиа-контента без какой-либо обработки постдекодирования вместо прекращения декодирования. Прекращение декодирования запускается посредством использования псевдоидентификатора вместо истинного идентификатора кодека как идентификатора медиа-кодека. Традиционные медиа-терминалы поэтому воздерживаются от визуализации медиа-контента. Это важно, поскольку визуализация в противном случае приведет к визуальным и/или аудиоартефактам, воспринимаемым пользователем, поскольку обработка постдекодирования медиа-контента с использованием дополнительной информации обработки не была проведена традиционными медиа-терминалами, для которых отсутствует возможность использовать дополнительную информацию обработки.
Краткое описание чертежей
Изобретение, вместе с дополнительными его целями и преимуществами, лучше всего может быть понятно со ссылками на следующее описание, вместе с прилагаемыми чертежами, на которых:
Фиг.1 является блок-схемой, иллюстрирующей способ предоставления дополнительной информации обработки в соответствии с вариантом осуществления;
Фиг.2 является сравнением обработки медиа-контента в соответствии с предшествующим уровнем техники и в соответствии с вариантом осуществления;
Фиг.3 является блок-схемой, иллюстрирующей вариант осуществления совместной организации этапа на фиг.1;
Фиг.4 является схематичным видом медиа-контейнер-файла в соответствии с вариантом осуществления;
Фиг.5 является схематичным видом блока элемента выборки в соответствии с вариантом осуществления;
Фиг.6 является схематичным видом варианта осуществления организации дополнительной информации обработки в блоках элемента выборки медиа-дорожки;
Фиг.7 является общим видом сети связи, в которой могут быть осуществлены варианты осуществления;
Фиг.8 является блок-схемой устройства для предоставления дополнительной информации обработки в соответствии с вариантом осуществления;
Фиг.9 является блок-схемой способа обработки медиа-контента в соответствии с вариантом осуществления;
Фиг.10 является блок-схемой дополнительных этапов способа на Фиг.9 в соответствии с вариантом осуществления;
Фиг.11 является блок-схемой дополнительных этапов способа на фиг.9 в соответствии с другим вариантом осуществления;
Фиг.12 является блок-схемой медиа-терминала в соответствии с вариантом осуществления; и
Фиг.13 является блок-схемой, иллюстрирующей другой вариант осуществления совместной организации этапа на фиг.1.
Подробное описание
На всех чертежах одинаковые ссылочные номера используются для подобных или соответствующих элементов.
Варианты осуществления в целом относятся к обработке медиа-контента и, в частности, к обеспечению и использованию дополнительной информации обработки, которая может использоваться медиа-терминалами и плейерами для обработки и/или визуализации декодированного медиа-контента.
Варианты осуществления обеспечивают эффективные способы передачи такой дополнительной информации обработки к медиа-терминалам. Передача дополнительной информации обработки позволяет медиа-терминалам, которые распознают дополнительную информацию обработки, извлекать ее и использовать ее для обработки медиа-контента перед или во время визуализации. Однако дополнительная информация обработки преимущественно передается таким способом, что традиционные медиа-терминалы, которые не распознают дополнительную информацию обработки, не будут осуществлять визуализацию медиа-контента. Это является предпочтительным, поскольку такая визуализация медиа-контента будет приводить к визуальным и/или аудиоартефактам, воспринимаемым пользователем как отсутствие проведения обработки постдекодирования на основе любой дополнительной информации обработки посредством традиционных медиа-терминалов.
Дополнительная информация обработки (SPI) или дополнительная информация улучшения (SEI), как она также обозначается в уровне техники, определяет инструкции постдекодирования, которые могут использоваться медиа-терминалами и плейерами для обработки декодированного медиа-контента, с которым дополнительная информация обработки связана. Эти инструкции постдекодирования могут поэтому обеспечивать информацию и инструкции медиа-терминалам, как им следует обрабатывать данные для предоставления правильной визуализации медиа-контента во время медиа-сеанса. Дополнительная информация обработки может быть обязательной для медиа-терминалов в том смысле, что пропуск обработки декодированного медиа-контента на основе дополнительной информации обработки препятствует медиа-терминалу визуализировать медиа-контент или медиа-терминал может осуществлять визуализацию медиа-контента, но результирующее медиа-представление будет иметь несколько более или менее серьезные визуальные и/или аудиоартефакты, которые будут восприниматься пользователем. Дополнительная информация обработки может также быть опциональной в том смысле, что не требуется для осуществления визуализации медиа-контента, но будет улучшать визуализацию, возможно посредством увеличения визуальных и/или аудиоэффектов медиа-представления или посредством облегчения операций поиска в медиа-представлении.
Например, AVC определяет SEI-сообщения, которые могут использоваться для улучшения декодирования и визуализации VCL битового потока AVC. Эта информация разработана таким способом, что она не является обязательной для процесса декодирования, т.е. SEI содержит информацию, которая не является необходимой для декодирования VCL и может быть отброшена соответствующими декодерами.
Хотя SEI не является ключевым для процесса декодирования, она может определять требуемые действия для последующего процесса визуализации. Одним из примеров является SEI-сообщение стереовидеоинформации, которое указывает, что кодированные кадры/поля видеопоследовательности состоят из пар изображений, формирующих контент стереоизображения. Более современным примером является SEI-сообщение пространственно перемежающихся кадров "шахматная доска". Оно информирует декодер о том, что выходное декодированное изображение содержит образцы кадра, состоящего из нескольких отдельных кадров с пространственным перемежением и информацию о том, как соответствующим образом осуществить обратное перемежение образцов для целей отображения.
Если традиционный медиа-терминал попытается осуществлять декодирование и осуществлять визуализацию битового потока AVC, содержащего эти SEI-сообщения, без понимания их значения, то он будет отбрасывать их и декодировать битовый поток, не зная, что декодируемые изображения не имеют смысла без дальнейшего обратного перемежения. При непосредственном выводе на 2D-дисплей, результат будет полон артефактов и, конечно, будет не таким, какой подразумевал поставщик контента.
Формат файла AVC определяет хранение AVC в форматах файлов на основе формата ISO медиа файлов, такого как MP4 и 3GP. Битовые потоки AVC, содержащиеся в таких файлах, могут включать в себя SEI-сообщения, которые могут быть полезными для процесса декодирования. Однако отсутствуют ограничения на типы SEI-сообщений, которые могут включаться, и в настоящее время отсутствует механизм сигнализации, который информирует плейер о том, что битовый поток AVC может содержать SEI, которое требуется для правильной визуализации декодируемых данных. Даже если плейер производит анализ битового потока AVC и производит поиск SEI-сообщений, это не может сообщить, накладывает ли любое из детектированных SEI-сообщений действия за пределами петли декодирования, пока он не распознает их и их значения. Отбрасывание внешне безопасной, но неизвестной SEI может, таким образом, приводить к неожиданным результатам. Следовательно, файл должен в соответствии с предшествующим уровнем техники быть сделан с конкретными знаниями способностей отображения терминалов, чтобы гарантировать правильное воспроизведение. Новые возможности отображения, добавляемые через дополнительную информацию обработки, такую как SEI-сообщения, вне петли декодирования, не могут быть сделаны в настоящее время способом обратной совместимости.
Медиа-контент, как раскрыто здесь, относится к медиа-данным, которые могут передаваться медиа-терминалу для декодирования и визуализации там для предоставления медиа-презентации пользователю. Медиа-контент может поэтому быть видеоконтентом или данными, которые проигрываются и представляются на экране дисплея. Альтернативно или в дополнение медиа-контент может быть аудиоконтентом или данными, которые проигрываются и могут слушаться пользователем с помощью громкоговорителя.
Фиг.1 является блок-схемой способа предоставления дополнительной информации обработки, относящейся к кодированному медиа-контенту, в соответствии с вариантом осуществления. Способ начинается на этапе S1, где псевдоидентификатор медиа-кодека предоставляется. Медиа-кодек определяет медиа-кодер, используемый для кодирования релевантного медиа-контента. Этап S1 предоставляет псевдоидентификатор вместо истинного идентификатора кодека медиа-кодека. Псевдоидентификатор должен интерпретироваться здесь в качестве псевдонима идентификатора кодека. Псевдоидентификатор далее выбирается, чтобы быть распознаваемым и может интерпретироваться некоторыми медиа-терминалами, но не распознается и может не интерпретироваться другими медиа-терминалами, обозначенными традиционными медиа-терминалами здесь.
Следующий этап S2 обеспечивает дополнительную информацию обработки, сокращенную в SPI на чертежах. Дополнительная информация обработки определяет инструкции постдекодирования для обработки декодированного медиа-контента, получаемого посредством декодирования кодированного медиа-контента, связанного с дополнительной информацией обработки.
Псевдоидентификатор и дополнительная информация обработки совместно организуются на этапе S3 в файле таким образом, чтобы вызывать прекращение декодирования или предотвращать декодирование кодированного медиа-контента посредством традиционного медиа-терминала, который не распознает псевдоидентификатор. Таким образом, псевдоидентификатор предпочтительно запускает традиционный медиа-терминал прекратить декодирование медиа-контента и, таким образом, не осуществлять визуализацию любого медиа-контента. Однако совместная организация в файле далее проводится таким способом, что она позволяет медиа-терминалу, который распознает псевдоидентификатор, декодировать кодированный медиа-контент, с использованием медиа-декодера, определяемого посредством медиа-кодека, и осуществлять обработку постдекодирования декодированного медиа-контента с использованием дополнительной информации обработки.
Таким образом, совместная организация псевдоидентификатора и дополнительной информации обработки в файле на этапе S1 будет предотвращать традиционный медиа-терминал от декодирования кодированного медиа-контента или запускать медиа-терминал прекратить декодирование кодированного медиа-контента, когда он извлекает псевдоидентификатор. Причиной для этого является то, что традиционные медиа-терминалы не распознают и поэтому могут не использовать дополнительную информацию обработки. Это означает то, что даже хотя традиционный медиа-терминал может декодировать кодированный медиа-контент, он может не правильно выполнить обработку постдекодирования декодированного медиа-контента с использованием дополнительной информации обработки. Это будет приводить к проблемам, которые варианты осуществления решают посредством использования псевдоидентификатора для запуска прекращения декодирования перед тем, как визуализация может быть инициирована в традиционном медиа-терминале.
Фиг.2 схематично иллюстрирует эту концепцию. В этом иллюстративном примере видеоконтент предоставляется с ограничениями в терминах требования дополнительной информации обработки для того, чтобы позволить правильную визуализацию и отображение видеоданных пользователю. Например, дополнительная информация обработки может определять, какие видеокадры кодированных видеоданных или контента соответствуют виду слева и какие видеокадры соответствуют виду справа для стерео или 3D визуализации. Дополнительная информация может затем определять, что каждый нечетный кадр видеоконтента представляет первый (левый или правый) вид, тогда как каждый четный кадр видеоконтента представляет второй (правый или левый) вид. В соответствии с предшествующим уровнем техники старый терминал, т.е. традиционный медиа-терминал, будет правильно декодировать кодированный медиа-контент. Однако, поскольку он не распознает дополнительную информацию обработки, он будет просто игнорировать упомянутую информацию. Это будет приводить к неправильному воспроизведению или визуализации видеоконтента со скачками между левым и правым видами каждый кадр, поскольку традиционный медиа-терминал не является осведомленным о конкретном перемежении видеокадров различных видов. Медиа-представление будет поэтому весьма непривлекательным для просматривающего пользователя и будет полным визуальных артефактов из-за скачков видов в каждом кадре.
В предшествующем уровне техники декодирование и медиа-визуализация проводится в традиционных медиа-терминалах даже несмотря на то, что традиционные медиа-терминалы не распознают дополнительную информацию обработки, необходимую для того, чтобы достигать правильного медиа-представления.
Псевдоидентификатор и совместная организация псевдоидентификатора и дополнительной информации обработки в файле в соответствии с вариантами осуществления решают эту проблему с предшествующим уровнем техники посредством запуска прекращения или останова декодирования кодированного медиа-контента для тех традиционных медиа-терминалов, которые не распознают псевдоидентификатор. Это означает то, что для медиа-контента предпочтительно никогда не осуществляется визуализация в традиционных медиа-терминалах и пользователь может вместо этого быть информирован о том, что его медиа-терминал не поддерживает визуализацию настоящего медиа-контента.
Эта концепция схематично иллюстрируется справа на фиг.2. Таким образом, когда традиционный медиа-терминал, т.е. старый терминал на чертеже, принимает файл с псевдоидентификатором и дополнительной информацией обработки, традиционный медиа-терминал извлекает псевдоидентификатор. Медиа-терминал затем заключает, что он не распознает псевдоидентификатор и поэтому останавливает декодирование медиа-контента.
В конкретном варианте осуществления некоторая дополнительная или внешняя информация может обеспечиваться вместе с файлом, чтобы улучшить самоосведомленность медиа-терминала. Такая метаинформация может, например, быть ссылкой, чтобы информировать медиа-терминал о том, что его декодер устарел для декодирования битового потока и что необходимо некоторое обновление. Это далее иллюстрируется на чертеже, где медиа-терминал может искать обновления кодека для того, чтобы эффективно обрабатывать файл, распознавать псевдоидентификатор и обрабатывать декодированный медиа-контент с использованием дополнительной информации обработки. Медиа-терминал может, таким образом, конфигурироваться для запроса поддержки или обновлений от некоторого предварительно сконфигурированного внешнего источника.
Псевдоидентификатор может поэтому рассматриваться как средство для сокрытия истинного идентификатора кодека медиа-кодека от этих традиционных медиа-терминалов, которые не будут распознавать дополнительную информацию обработки. Сокрытие идентификатора кодека, таким образом, предотвращает традиционные мобильные терминалы от декодирования и, таким образом, от визуализации медиа-контента.
Совместная организация псевдоидентификатора и дополнительной информации обработки предпочтительно выполняется таким способом, что медиа-терминал будет только извлекать дополнительную информацию обработки из файла, если он распознает и может интерпретировать псевдоидентификатор. Это эффективно предотвращает традиционные медиа-терминалы от попытки извлечь и интерпретировать дополнительную информацию обработки, которую они не распознают.
Варианты осуществления описаны далее в связи с различными конкретными примерами осуществления.
Фиг.3 является блок-схемой, иллюстрирующей этап совместной организации на фиг.1 в соответствии с конкретным вариантом осуществления. Способ продолжается с этапа S2 фиг.1. Следующий этап S10 генерирует и обеспечивает медиа-контейнер-файл. Медиа-контейнер-файл можно рассматривать как полный входной пакет, который предпочтительно содержит, в дополнение к медиа-контенту, непосредственно информацию и инструкции, требуемые медиа-терминалами для выполнения декодирования и визуализации медиа-контента. Формат медиа-файла на основе ISO может преимущественно использоваться как формат файла для медиа-контейнер-файла, включающего различные форматы хранения, извлекаемые или основанные на формате медиа-файла на основе ISO, такие как формат файла AVC. Формат файла AVC в свою очередь определяет как H.264 (MPEG-4 AVC) осуществляется в различных форматах файлов, извлекаемых из формата медиа-файла на основе ISO, например формат файла MP4 и 3GP.
Медиа-контейнер-файл, генерируемый на этапе S10, содержит по меньшей мере одну медиа-дорожку, определяющую медиа-контент, и по меньшей мере один контейнер медиа-контента или блок, содержащий кодированный медиа-контент. Пример такого медиа-контейнер-файла 1 иллюстрируется на фиг.4. Медиа-контейнер-файл 1 содержит, в этом примере, соответствующую медиа-дорожку 20, 30 для каждого медиа-контента, чтобы осуществлять визуализацию в течение медиа-презентации. Поэтому, первая медиа-дорожка 20 определяет видеоконтент и вторая медиа-дорожка 30 определяет соответствующий аудио-контент. Медиа-дорожки 20, 30 предпочтительно организуются в контейнере фильма (movie, 'moov') или блоке 10, который является контейнером для метаданных, относящихся к медиа-контенту. Чертеж также иллюстрирует контейнер медиа-данных ('mdat') или блок 40, который является контейнером для действительных медиа-данных для медиа-представления.
Следующий этап S11 способа на фиг.2 обеспечивает блок элемента выборки в медиа-контейнер-файле. Этот блок элемента выборки определяет псевдоидентификатор. Пример такого блока элемента выборки может выглядеть как:
class AVCSampleEntry () раширяет VisualSampleEntry ('resv') {
RestrictedSchemeInfoBox ();
AVCConfigurationBox config;
MPEG4BitRateBox (); // необязательно
MPEG4ExtensionDescriptionBox (); // необязательно
}
или в более общем:
class RestrictedSampleEntry () раширяет SampleEntry ('resv') {
RestrictedSchemeInfoBox ( );
ConfigurationBox config;
}
VisualSampleEntry и AVCSampleEntry определяют то, что медиа-контент является видеоконтентом. Блок элемента выборки разработан таким способом, что он имеет виртуальную базу: SampleEntry (format) расширяет Box (format). То, что находится в поле "format", является неопределенным и является левым по отношению к его извлеченному вводу для назначения ему значения. Например, в случае видео мы имеем: VisualSampleEntry (codingname) расширяет SampleEntry (codingname). В настоящем случае, "codingname" соответствует 'resv', который представляет псевдоидентификатор. Таким образом, вместо определения конкретного медиа-кодека, используемого для кодирования медиа-контента, такого как 'avc1, настоящий вариант осуществления замещает идентификатор кодека медиа-кодека псевдоидентификатором 'resv'.
Блок дополнительной информации обработки предоставляется в блоке элемента выборки на этапе S12. Блок дополнительной информации обработки содержит дополнительную информацию обработки, применимую к медиа-контенту. Этот блок дополнительной информации обработки может размещаться в медиа-контейнер-файле в соответствии с различными вариантами осуществления. В первом варианте осуществления блок дополнительной информации обработки предоставляется непосредственно в блок 80 элемента выборки. Блок элемента выборки может затем быть расширен для чтения, где SeiInformationBox соответствует блоку дополнительной информации обработки:
class AVCSampleEntry () расширяет VisualSampleEntry ('resv') {
RestrictedSchemeInfoBox ();
AVCConfigurationBox config;
SeiInformationBox seiinfo;
MPEG4BitRateBox (); // необязательно
MPEG4ExtensionDescriptionBox (); // необязательно
}
В альтернативном варианте осуществления блок дополнительной информации обработки предоставляется глубже в блоке информации ограниченной схемы вместо непосредственно в блоке элемента выборки. Блок информации ограниченной схемы может затем определяться как:
aligned(8) class RestrictedSchemeInfoBox (fmt) расширяет Box ('rinf') {
Original FormatBox (fmt) originaljormat;
SchemeTypeBox scheme _type_box;//необязательно
SchemeInformationBox info;
}
В таком случае блок дополнительной информации обработки может содержаться в информационном блоке схемы. Включение блока дополнительной информации обработки в информационный блок схемы может, в конкретном варианте осуществления, быть условным при использовании 'aSEI', т.е. AVC SEI, как типа схемы.
В том или другом случае блок дополнительной информации обработки может, в конкретном варианте осуществления, определяться как:
aligned (8) class SeiInformationBox расширяет Box('seii') {
беззнаковое int(8) numRequiredSEIs;
for (i=0; i<numRequiredSEIs;i++) {
беззнаковое int(8) requiredSEI_ID;
}
беззнаковое int(8) numNotRequiredSEIs;
for (i=0; i<numNotRequiredSEIs;i++) {
беззнаковое int(8) NotrequiredSEI_ID;
}
]
Таким образом, в этом конкретном варианте осуществления дополнительная информация обработки может разделяться на обязательную дополнительную информацию обработки (requiredSEI_ID), которая должна использоваться медиа-терминалом в течение обработки постдекодирования медиа-контента, и необязательную дополнительную информацию обработки (NotrequiredSEI_ID). Последняя не является обязательной, но в целом поправит или улучшит медиа-представление или визуализацию медиа-контента, если используется медиа-терминалом. numRequiredSEIs и numNotRequiredSEIs определяют номер версий обязательной и необязательной дополнительной информации обработки, присутствующей в медиа-контейнер-файле и относящейся к конкретному медиа-контенту. requiredSEI_ID принимает значение "payloadType" сообщения дополнительной информации обработки, такого как SEI-сообщение, присутствующего в медиа-потоке и которое полагается необходимым автором файла или разработчиком для правильной визуализации или воспроизведения. NotrequiredSEI_ID соответственно принимает значение "payloadType" сообщения дополнительной информации обработки (SEI-сообщение), которое не полагается необходимым автором файла для правильной визуализации.
Блок дополнительной информации обработки поэтому предпочтительно только содержит соответствующие идентификаторы сообщений дополнительной информации обработки, которые могут использоваться в связи с конкретным медиа-контентом. Сообщения конкретной дополнительной информации обработки, на которые ссылаются посредством этих идентификаторов, могут затем обеспечиваться в другом месте в медиа-контейнер-файле, который далее рассматривается здесь.
Следующий этап S13 фиг.3 обеспечивает блок медиа-формата в блоке элемента выборки. Блок медиа-формата содержит идентификатор кодека медиа-кодека.
В конкретном варианте осуществления первоначальный тип элемента выборки, т.е. идентификатор кодека, содержится в OriginalFormatBox, представляющий блок медиа-формата. OriginalFormatBox может затем содержаться в RestrictedSchemeInfoBox, упомянутом выше:
выровненный (8) class OriginalFormatBox (codingname) расширяет Box('frma') {
беззнаковый int(32) формат данных;//значение от непреобразованного элемента выборки, такого как data_format= 'avc1;
}
Таким образом, в примере выше "data_format" представляет истинный идентификатор медиа-кодека и может принимать различные значения, такие как 'avc1', 'mp4v', и т.д. в зависимости от конкретного медиа-кодека.
Фиг.5 схематично иллюстрирует различные контейнеры или блоки, которые могут использоваться для определения псевдоидентификатора, идентификатора кодека и дополнительной информации обработки. В этом конкретном варианте осуществления блок 80 элемента выборки имеет его традиционный четырехсимвольный код, такой как 'avc1', замещаемый псевдоидентификатором, представляемым посредством 'resv' на чертеже, обозначающем «ограниченное видео» ("restricted video"). В этом примере блок 80 элемента выборки в свою очередь содержит, среди других, блок 70 информации ограниченной схемы, обозначаемый 'rinf' на чертеже. Блок 70 информации ограниченной схемы содержит блок 60 первоначального формата (обозначаемый 'frma' на чертеже) с идентификатором 62 кодека, таким как 'avc1'. В конкретном варианте осуществления блок 70 информации ограниченной схемы также содержит блок 50 дополнительной информации обработки, обозначаемый 'seii' на чертеже. Блок 50 дополнительной информации обработки содержит или перечисляет идентификаторы 52 сообщений требуемой или обязательной дополнительной информации обработки и идентификаторы 54 сообщений нетребуемой или необязательной дополнительной информации обработки.
Фиг.6 представляет медиа-дорожку 20 медиа-контейнер-файла. Этот чертеж иллюстрирует то, что медиа-дорожка 20 может разделяться на несколько блоков 80 элемента выборки, где каждый такой блок 80 элемента выборки связывается с соответствующей частью кодированного медиа-контента, содержащегося в блоке медиа-контента медиа-контейнер-файла. В таком случае дополнительная информация 50 обработки может быть представлена в блоках 80 элемента выборки, как упомянуто ранее. В конкретном варианте осуществления дополнительная информация 50 обработки, определяющая инструкции постдекодирования, применимые к следующей части кодированного медиа-контента, предоставляется в блок 80 элемента выборки, связанный с предыдущей частью кодированного медиа-контента. Эта предыдущая часть кодированного контента тогда имеет время декодирования, предшествующее времени декодирования следующей части кодированного медиа-контента. Таким образом, дополнительная информация 50 обработки, определяющая инструкции постдекодирования, относящиеся к части k, k+1, k+2 медиа-контента, предоставляется в блок 80 элемента выборки, относящийся к части k-1, k, k+1 медиа-контента. В таком случае медиа-терминал будет иметь время, чтобы идентифицировать и обеспечить дополнительную информацию обработки и ее определенные инструкции постдекодирования, когда существенная версия медиа-контента была декодирована медиа-терминалом. Таким образом, любые задержки декодирования и обработки постдекодирования будут поэтому уменьшены.
Однако в большинстве вариантов осуществления блоки 80 элемента выборки и медиа-дорожки 20 типично передаются вместе перед тем, как передаются реальные данные, представляемые в контейнере медиа-данных. Поэтому для этих вариантов осуществления в целом нет необходимости для предоставления дополнительной информации обработки, определяющей инструкции постдекодирования, относящиеся к медиа-контенту k в блоке 80 элемента выборки, относящемся к части k-1 медиа-контента. В ясном контрасте дополнительная информация обработки может вместо этого обеспечиваться в блоке элемента выборки, относящемся к части k медиа-контента.
Действительные инструкции постдекодирования, определяемые посредством дополняющей информации обработки, могут обеспечиваться в действительном битовом потоке. Таким образом, инструкции постдекодирования, такие как SEI-сообщения, могут инкапсулироваться в блоки NAL и затем помещаться глубоко в битовом потоке, где они содержатся в блоке медиа-данных. Другим местом, где действительные инструкции постдекодирования могут размещаться, является некоторый специальный блок, например ViewScalabilityInfoSEIBox, который как раз делает копию действительных инструкций постдекодирования в битовом потоке.
Дальнейшие варианты осуществления медиа-контейнер-файла могут замещать традиционный элемент выборки, такой как AVC элемент выборки, таким способом, что традиционные медиа-терминалы будут не способны его декодировать. Новый элемент выборки тогда определяется подобным образом исходному синтаксису, но с добавлением блока дополнительной информации обработки. В таком случае этот новый элемент выборки будет соответствовать псевдоидентификатору медиа-кодека. Например, блок входной выборки и псевдоидентификатор могут обозначаться 'avcr' для AVC с ограничениями:
class AVCRestrictionsSampleEntry() расширяет VisualSampleEntry ('aver') {
AVCConfigurationBox config;
SeiInformationBox seiinfo;
MPEG4BitRateBox ();// необязательно
MPEG4ExtensionDescriptorsBox ( ); // необязательно
}
В еще другом варианте осуществления новая версия AVCDecoderConfigurationRecord определяется и поэтому используется новое значение для configurationVersion в AVCDEcoderConfigurationRecord. Это осуществляется так, что традиционные медиа-терминалы, которые не могут использовать дополнительную информацию обработки, не смогут декодировать файл.
В необязательном случае новое определение AVCDecoderConfigurationRecord содержит также информацию о требуемой и/или необязательной дополнительной информации обработки. Пример этого синтаксиса показан ниже:
Выровненная (8) class AVCDecoderConfigurationRecord {
беззнаковое int(8) configurationVersion = 2;
беззнаковое int( 8) A VCProfileIndication;
беззнаковое int(8) profile_compatibility;
беззнаковое int(8) AVCLevellndication;
bit(6) reserved='111111'b;
беззнаковое int(2) lengthSizeMinusOne;
bit(3) reserved='111'b;
беззнаковое int(5) numOfSequenceParameterSets;
for (i=0; i<numOfSequenceParameterSets;i++) {
беззнаковое int(16) sequenceParameterSetLength ;
bit(8*sequenceParameterSetLength) sequenceParameterSetNALUnit;
}
беззнаковое int(8) numOfPictureParameterSets;
for (i=0; i< numOfPictureParameterSets; i++) {
беззнаковое int(16) pictureParameterSetLength;
bit(8*pictureParameterSetLength) pictureParameterSetNALUnit;
}
беззнаковое int(8) numRequiredSEIs;
for (i=0; i<numRequiredSEIs; i++) {
беззнаковое int(8) requiredSEI_ID;
}
беззнаковое int(8) numNotRequiredSEIs;
для (i=0; i<numNotRequiredSEIs; i++) {
беззнаковое int(8) NotrequiredSEI_ID;
}
}
В альтернативном варианте осуществления файл, в котором псевдоидентификатор и дополнительная информация обработки совместно организуются, не является необходимым медиа-контейнер-файлом. Фиг.13 иллюстрирует этот вариант осуществления. Способ продолжается с этапа S2 фиг.1. Следующий этап S50 включает в себя генерацию файла протокола описания сеансов (SDP) и совместную организацию псевдоидентификатора и дополнительной информации обработки как различных атрибутивных линий в SDP-файле. Как известно в уровне техники, транспортный протокол реального времени (RTP) разработан для передачи данных в реальном времени. Различные форматы полезной нагрузки определяются для различных медиа-кодеков, и это регулирует правила пакетирования. Вспомогательная информация также типично передается в SDP-файле между отправителем и получателем так, что обе стороны осведомлены о состоянии медиа-контента, передаваемого посредством установления модели ответ/предложение SDP.
SDP-файл может затем быть изменен, чтобы иметь первую атрибутивную линию, содержащую псевдоидентификатор, и вторую атрибутивную линию, содержащую дополнительную информацию обработки. Традиционные медиа-терминалы, которые могут не использовать дополнительную информацию обработки для обработки постдекодирования медиа-контента, не будут распознавать псевдоидентификатор, извлекаемый из SDP-файла. Декодирование медиа-контента, таким образом, останавливается и предотвращается.
В конкретном варианте осуществления псевдоидентификатор используется как новый тип марочного имени вместо старого марочного имени, такой замещает H264 посредством H264-RES, что означает H.264 с ограничениями. Также новые параметры свойств потока определяются, формулируя, какие ограничения применяются. Эти параметры свойств потока соответствуют дополнительной информации обработки, которая может быть задана как требуемые/нетребуемые SEI-сообщения. Пример показан ниже:
m=video 20000 RTP/AVP 97
a=rtpmap:97 H264-RES/90000
a=fmtp:97 sprop-requiredSEI-ID ? {ID1},{ID2}; sprop-NotrequiredSEI-ID={ID3},{ID4},{ID5};
Когда приемник традиционного медиа-терминала принимает SDP-предложение выше, псевдоидентификатор H264-RES останавливает ошибочное декодирование, поскольку традиционный медиа-терминал отклонит это предложение заранее. Только медиа-терминалы, которые распознают H264-RES, примут предложение и могут поэтому правильно декодировать и осуществлять визуализацию медиа-контента с дополнительной информацией обработки. Эти медиа-терминалы будут, таким образом, преобразовывать или транслировать псевдоидентификатор H264-RES в идентификатор кодека, т.е. H264. Это означает то, что эти медиа-терминалы были сконфигурированы для понимания псевдоидентификатора и проведения требуемого преобразования или трансляции идентификатора.
Варианты осуществления, раскрываемые выше, были главным образом проиллюстрированы с помощью H.264/AVC. Это следует, однако, видеть только как иллюстративные, но не ограничивающие примеры. Например, эквивалентные варианты осуществления с расширениями H.264/AVC, такие как масштабируемое видеокодирование (SVC) и видеокодирование с несколькими видами (MVC), среди других, работают очень похожим образом посредством расширения их конкретных конфигурационных записей и/или типов элемента выборки подобным образом.
Варианты осуществления поэтому позволяют детектирование присутствия дополнительной информации обработки посредством медиа-терминала без рассмотрения битового потока. Очевидно, этого достаточно для исследования существенной части медиа-контейнер-файла или SDP-файла или предложения, как проиллюстрировано на примере выше. Дополнительная информация обработки будет кроме того преимущественно видна тем медиа-терминалам, которые могут интерпретировать и использовать дополнительную информацию обработки. Традиционные медиа-терминалы не будут поэтому пытаться отобразить декодируемый битовый поток, который будет требовать дополнительную постобработку перед визуализацией.
Фиг.7 является схематичным видом части сети связи, в которой могут быть реализованы варианты осуществления. Сеть связи иллюстрируется примером на основе радиосети связи, предоставляющей, среди других, службы связи мобильным терминалам 200, 210 и другим пользовательским устройствам, посредством базовых станций 310 или сетевых узлов. Сеть связи также содержит медиа-сервер 300, осуществляемый в или соединяемый с такой базовой станцией 310 для предоставления медиа-контента одному или более запрашивающим медиа-терминалам, таким как мобильные терминалы 200, 210. Чертеж иллюстрирует один возможный вариант осуществления выполнения устройства для предоставления дополнительной информации 100 обработки, обозначаемой устройством предоставления SPI на чертежах. Это устройство 100 конфигурируется для генерации файла 1, как раскрывается здесь, содержащего псевдоидентификатор и дополнительную информацию обработки. Файл 1 затем передается на мобильный терминал 200, 210 посредством соединенной базовой станции 310. На чертеже мобильный терминал 210 может представлять традиционный медиа-терминал, тогда как мобильный терминал 200 указывает медиа-терминал, который распознает псевдоидентификатор, и может использовать дополнительную информацию обработки.
Устройство 100 необязательно должно осуществляться в медиа-сервере 300, но может альтернативно осуществляться в другом сетевом узле сети связи. Распределенное осуществление в нескольких таких сетевых узлах также возможно и находится в области действия вариантов осуществления.
Фиг.8 является схематичной блок-схемой устройства для предоставления дополнительной информации 100 обработки в соответствии с вариантом осуществления. Устройство 100 содержит поставщик 110 идентификатора, конфигурируемый для предоставления псевдоидентификатора медиа-кодека, используемого для кодирования медиа-контента. Поставщик 130 информации конфигурируется для предоставления дополнительной информации обработки, представляющей инструкции постдекодирования для обработки декодированного медиа-контента, получаемого посредством декодирования кодированного медиа-контента. Устройство 100 также содержит организатор 120 файлов, конфигурируемый для совместной организации псевдоидентификатора из поставщика 110 идентификатора и дополнительной информации обработки из поставщика 130 информации в файле. Совместная организация в файле, как было раскрыто здесь, проводится организатором 120 файла, так что он запускает прекращение декодирования кодированного контента посредством традиционного медиа-терминала, который не распознает псевдоидентификатор. Однако совместная организация позволяет декодирование кодированного медиа-контента с использованием медиа-кодека и позволяет постдекодирование обрабатываемого декодированного медиа-контента с использованием дополнительной информации обработки посредством медиа-терминала, который распознает псевдоидентификатор.
Поставщик 130 информации может обеспечивать требуемую дополнительную информацию обработки, представляющую обязательные инструкции постдекодирования для обработки декодированного медиа-контента, и нетребуемую дополнительную информацию обработки, представляющую необязательные инструкции постдекодирования для обработки декодированного медиа-контента.
В конкретном варианте осуществления организатор 120 файла конфигурируется для генерации медиа-контейнер-файла, содержащего по меньшей мере одну медиа-дорожку, определяющую медиа-контент, и по меньшей мере один медиа-контент блок, содержащий кодированный медиа-контент. Поставщик 110 идентификатора может затем обеспечить блок элемента выборки в медиа-контейнер-файле. Блок элемента выборки определяет псевдоидентификатор и содержит блок медиа-формата, содержащий идентификатор кодека, как описано ранее. Поставщик 130 информации предпочтительно обеспечивает блок дополнительной информации обработки, содержащий дополнительную информацию обработки, в блоке элемента выборки. В конкретном варианте осуществления поставщик 130 информации обеспечивает дополнительную информацию обработки, определяющую инструкции постдекодирования, применимые к медиа-контент части k в блоке элемента выборки, связанном с предыдущей медиа-контент частью k-1, имеющей время декодирования, предшествующее времени декодирования медиа-контента части k. В другом варианте осуществления поставщик 130 информации обеспечивает дополнительную информацию обработки, определяющую инструкции постдекодирования, применимые к медиа-контенту части k в блоке элемента выборки, связанном с медиа-контентом части k.
В альтернативном варианте осуществления организатор 120 файла конфигурируется для генерации SDP-файла, содержащего псевдоидентификатор из поставщика 110 идентификатора как первую атрибутивную линию и дополнительную информацию обработки из поставщика 130 информации как вторую атрибутивную линию.
Блоки 110-130 устройства 100 могут осуществляться или обеспечиваться как аппаратное обеспечение или сочетание аппаратного обеспечения и программного обеспечения. В случае осуществления на основе программного обеспечения, компьютерный программный продукт, реализующий устройство 100 или его часть, содержит программное обеспечение или компьютерную программу, запущенную на компьютере общего назначения или специально адаптированном компьютере, процессоре или микропроцессоре. Программное обеспечение включает в себя элементы компьютерного программного кода или части кода программного обеспечения, как иллюстрируется на фиг.8. Программа может храниться во всем или в части, на или в одном или более подходящем невременном читаемом компьютером носителе или средстве хранения данных, таком как магнитные диски, компакт-диски (CD-ROM), DVD диски, устройства памяти USB, жесткие диски, магнитооптическая память, в оперативной памяти (RAM) или энергозависимой памяти, в постоянной памяти (ROM) или флэш-памяти, как встроенное программное обеспечение или на сервере данных.
Устройство 100 может преимущественно осуществляться в или в связи с медиа-сервером 300, как иллюстрируется на фиг.7.
Фиг.9 является блок-схемой, иллюстрирующей способ обработки медиа-контента в медиа-терминале в соответствии с вариантом осуществления. Способ начинается на этапе S20, где файл, содержащий псевдоидентификатор и дополнительную информацию обработки, принимается. Следующий этап S21 проверяет, является ли распознаваемым псевдоидентификатор, сокращенный на чертежах как PID. Если псевдоидентификатор не является распознаваемым, то способ продолжается к этапу S22, где декодирование медиа-контента прекращается или предотвращается. Как обсуждалось в предшествующем изложении, кодированный медиа-контент может либо обеспечиваться в том же файле, что и псевдоидентификатор и дополнительная информация обработки, или обеспечиваться раздельно на этапе S20 или на другом (не раскрывается) этапе. Если псевдоидентификатор вместо этого является распознаваемым, то способ продолжается с этапа S21 к этапу S23. Этот этап S23 выбирает медиа-кодек для декодирования медиа-контента на основе идентификатора кодека, извлекаемого на основе псевдоидентификатора. Следующий этап S24 декодирует медиа-контент с использованием выбранного медиа-кодека. Декодированный медиа-контент обрабатывается на этапе S25 на основе дополнительной информации обработки для того, чтобы получить медиа-контент в форме, подходящей для визуализации, такой как отображение или воспроизведение.
Способ может затем завершаться. Альтернативно, медиа-контент может разделяться на различные части медиа-контента, где дополнительная информация обработки может быть связанной с и применимой к различным таким медиа-частям. В таком случае этапы S24 и S25 повторяются для каждой такой части медиа-контента.
Фиг.10 является блок-схемой, иллюстрирующей дополнительные этапы способа на фиг.9 в соответствии с вариантом осуществления. Способ продолжается с этапа S20 фиг.9, который включает в себя прием медиа-контейнер-файла, содержащего по меньшей мере одну медиа-дорожку, определяющую медиа-контент, по меньшей мере один блок медиа-контента, содержащий кодированный медиа-контент, и по меньшей мере один блок элемента выборки. Блок элемента выборки определяет псевдоидентификатор и содержит блок дополнительной информации обработки с дополнительной информацией обработки и блок медиа-формата с идентификатором кодека.
Следующий этап S30 извлекает псевдоидентификатор из блока элемента выборки и исследует на этапе S21 фиг.9, является ли псевдоидентификатор распознаваемым. Если это верно, то способ продолжается к этапу S31, где идентификатор кодека извлекается из блока медиа-формата. Способ затем продолжается к этапу S23 фиг.9, где медиа-кодек выбирается на основе извлеченного идентификатора кодека.
Фиг.11 является блок-схемой, иллюстрирующей дополнительные этапы способа на фиг.9 в соответствии с другим вариантом осуществления. Способ продолжается с этапа S20 на фиг.9, который включает в себя прием SDP-файла, содержащего первую атрибутивную линию, содержащую псевдоидентификатор, и вторую атрибутивную линию, содержащую дополнительную информацию обработки. Следующий этап S40 читает первую атрибутивную линию в SDP-файле, чтобы идентифицировать псевдоидентификатор. Способ затем продолжается к этапу S21 на фиг.9 для исследования того, является ли псевдоидентификатор распознаваемым. Если это верно, то способ продолжается к этапу S41. Этап S41 преобразует или транслирует псевдоидентификатор в идентификатор кодека. Способ затем продолжается к этапу S23 фиг.9, где медиа-кодек выбирается на основе преобразованного идентификатора кодека.
Если дополнительная информация обработки определяет инструкции постдекодирования, которые позволяют идентификацию того, какие видеокадры принадлежат виду слева и какие видеокадры принадлежит виду справа стерео или 3D визуализации, то этап обработки на фиг.9 может содержать идентификацию видеокадров кодированных видеоданных, соответствующих виду слева, и видеокадров, соответствующих виду справа на основе дополнительной информации обработки.
Фиг.12 является схематической блок-схемой медиа-терминала 200 в соответствии с вариантом осуществления. Медиа-терминал 200 иллюстрируется на примере посредством мобильного терминала на чертеже. Однако это следует только рассматривать как иллюстративный пример. Медиа-терминал может быть любым объектом или устройством или объединением нескольких устройств, которые имеют возможностью декодирования и визуализации. Отдельное такое устройство может быть мобильным терминалом, таким как мобильный телефон или портативный компьютер, компьютер, телевизионная приставка для ТВ или любое другое медиа-обрабатывающее устройство. Функциональность декодирования и визуализации может быть представлена в различных устройствах, которые затем способны проводить проводное или беспроводное соединение друг с другом. Медиа-терминал поэтому также охватывает такой вариант осуществления распределенного выполнения.
Медиа-терминал 200 содержит приемник 210, иллюстрируемый на примере посредством приемопередатчика (TX/RX) на чертеже. Приемник 210 конфигурируется для приема файла, содержащего псевдоидентификатор и дополнительную информацию обработки. Контроллер 220 декодирования конфигурируется для извлечения псевдоидентификатора из файла и проверки, является ли псевдоидентификатор распознаваемым. Если он не распознается посредством контроллера 220 декодирования, то контроллер 220 декодирования дает команду декодеру 230 прекратить декодирование кодированного медиа-контента или остановить декодер 230 от запуска процесса декодирования. Если контроллер 220 декодирования вместо этого распознает псевдоидентификатор, то он выбирает медиа-кодек 235 для использования посредством декодера 230 для декодирования медиа-контента. Этот выбор кодека проводится на основе идентификатора кодека, определяемого посредством контроллера 220 декодирования с использованием псевдоидентификатора.
Декодер 230 затем декодирует кодированный медиа-контент с использованием дополнительного медиа-кодека 235, чтобы получить декодированный медиа-контент. Декодированный медиа-контент далее обрабатывается посредством процессора 240 контента на основе дополнительной информации обработки, извлекаемой из файла, чтобы получить медиа-контент в форме, подходящей для визуализации. Медиа-терминал 200 может, кроме того, иметь медиа-плеер (не показан), который осуществляет визуализацию обработанного медиа-контента для отображения на экране 250 дисплея. Альтернативно или в дополнение медиа-плеер может проигрывать аудио-контент по громкоговорителю (не иллюстрируется) медиа-терминала 200.
В конкретном варианте осуществления приемник 210 принимает медиа-контейнер-файл с по меньшей мере одной медиа-дорожкой, определяющей медиа-контент, по меньшей мере одним блоком медиа-контента, содержащим медиа-контент, и предпочтительно инструкциями постдекодирования, определяемыми посредством дополнительной информации обработки. По меньшей мере один блок элемента выборки также включается в медиа-контейнер-файл и определяет псевдоидентификатор и содержит блок дополнительной информации обработки с дополнительной информацией обработки и блок медиа-формата с идентификатором кодека. В таком случае медиа-терминал 200 предпочтительно содержит поставщик 225 идентификатора, конфигурируемый для извлечения псевдоидентификатора из блока элемента выборки. Поставщик 225 идентификатора предпочтительно также извлекает, если псевдоидентификатор является распознаваемым посредством контроллера 220 декодирования, идентификатор кодека из блока медиа-формата.
В альтернативном варианте осуществления приемник 210 принимает SDP-файл, содержащий первую атрибутивную линию, содержащую псевдоидентификатор, и вторую атрибутивную линию, содержащую дополнительную информацию обработки. Поставщик 225 идентификатора затем конфигурируется для чтения первой атрибутивной линии для извлечения псевдоидентификатора и затем, если псевдоидентификатор является распознаваемым посредством контроллера 220 декодирования, преобразования псевдоидентификатора в идентификатор кодека медиа-кодека 235 с использованием предварительно сконфигурированных данных преобразования, хранящихся в медиа-терминале 200. Такие предварительно сконфигурированные данные преобразования могут быть списком, содержащим псевдоидентификаторы, которые распознаются посредством контроллера 220 декодирования, и идентификаторы кодеков для сопоставления.
Блоки 210-240 медиа-терминала 200 могут осуществляться или обеспечиваться как аппаратное обеспечение или сочетание аппаратного обеспечения и программного обеспечения. В случае осуществления на основе программного обеспечения компьютерный программный продукт, осуществляющий медиа-терминал 200 или его часть, содержит программное обеспечение или компьютерную программу, запущенную на компьютере общего назначения или специально адаптированном компьютере, процессоре или микропроцессоре. Программное обеспечение включает в себя элементы компьютерного программного кода или части кода программного обеспечения, иллюстрируемые на фиг.12. Программа может храниться в целом или части, на или в одном или более подходящем невременном читаемом компьютером носителе или средствах хранения данных, таких как магнитные диски, компакт-диски (CD-ROM), DVD диски, устройства памяти USB, жесткие диски, магнитооптическая память, в оперативной памяти (RAM) или энергозависимой памяти, в постоянной памяти (ROM) или флэш-памяти, как встроенное программное обеспечение или на сервере данных.
Варианты осуществления, рассматриваемые выше, следует понимать как несколько иллюстративных примеров настоящего изобретения. Следует иметь в виду специалистам в данном уровне техники, что различные модификации, сочетания и изменения могут быть сделаны в вариантах осуществления без выхода из объема настоящего изобретения. В частности, различные частичные решения в различных вариантах осуществления могут сочетаться в других конфигурациях, где технически возможно. Область настоящего изобретения, однако, определяется прилагаемыми пунктами формулы изобретения.