ОБРАТНАЯ СВЯЗЬ И СИНХРОНИЗАЦИЯ КАДРОВ МЕЖДУ МЕДИА КОДЕРАМИ И ДЕКОДЕРАМИ Российский патент 2012 года по МПК H04N7/64 H04L1/18 H04L7/00 

УРОВЕНЬ ТЕХНИКИ

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

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

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

Описываются системы и/или способы («инструменты»), которые дают возможность обеспечить обратную связь и синхронизацию кадров между медиа кодерами и декодерами. Более конкретно, кодер может кодировать кадры, которые основаны на исходном контенте (содержании), подлежащем посылке к декодеру. Кодер может определять, должен ли кадр быть помещенным в кэш посредством кодера или декодера. Если кадр должен быть помещенным в кэш, то кодер может это указать посредством кодирования кадра одним или несколькими управляющими битами кэша. Декодер может принять этот кадр от кодера и может проверить управляющие биты кэша для определения того, поместить ли кадр в кэш. Декодер может также декодировать этот кадр.

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

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

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

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

Фиг.6 является блок-схемой алгоритма, иллюстрирующей процесс обработки кадра, принятого, например, посредством декодеров.

Одинаковые позиции используются по всему описанию и чертежам для ссылки на подобные компоненты и особенности.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

Обзор

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

Этот документ для удобства организован в разделы, с разделами, вводимыми посредством заголовков, выбранных для удобства, а не для ограничения. Сначала описывается иллюстративное Рабочее окружение для выполнения обратной связи и синхронизации кадров между кодерами и декодерами. Затем описываются Структуры данных, за которыми следуют иллюстративные Потоки данных. Наконец, описываются Процессы обработки.

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

Рабочее окружение

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

Фиг.1 иллюстрирует одно такое рабочее окружение 100. Рабочее окружение 100 может содержать рабочую станцию 102а, имеющую один или несколько процессоров 104а и машиночитаемый носитель 106а. Рабочая станция 102а может содержать вычислительное устройство, такое как сотовый телефон, настольный компьютер, электронный секретарь, сервер и т.п. Процессор 104а может быть выполнен с возможностью доступа и/или выполнения машиночитаемого носителя 106а. Машиночитаемый носитель 106а может содержать или иметь доступ к кодеру 108, который может быть реализован как модуль, программа или другой объект, способный взаимодействовать с включаемым сетью объектом.

Кодер 108 может использоваться для кодирования исходного контента 110 во множество соответствующих кадров 112. Исходный контент 110 может предполагать любое число различных форм, таких как живая (реальная) презентация, характерная для диктора или другого исполнителя. Исходным контентом 110 может быть видео- и/или аудиоконференция. Наконец, исходным контентом 110 может быть предварительно существующие или предварительно записанные компьютерные средства информации, такие как аудио- или видеоносители.

Рабочее окружение 100 может также содержать сеть 114 и связанный с ней сервер (серверы) 116. Сеть 114 дает возможность осуществлять связь между рабочей станцией 102 и сервером (серверами) 116 и может содержать глобальную или локальную проводную или беспроводную сеть, такую как Интернет или корпоративный интранет. Понятно, что кодер 108 может использоваться для кодирования исходного контента 110 в кадры 112 с использованием протокола, который подходит для передачи по сети 114.

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

Сеть 114 может использоваться для передачи кадров 112 от рабочей станции 102а по меньшей мере к одной дополнительной рабочей станции 102b. Понятно, что сеть 114 не может передавать все кадры совершенным образом от рабочей станции 102а к рабочей станции 102b. Соответственно, ссылка 112 на фиг.1 представляет кадры, когда они покидают рабочую станцию 102а, и ссылка 118 представляет кадры, когда они выходят из сети 114 и предоставлены для рабочей станции 102b. Некоторые кадры 112 могут быть потеряны, искажены или испорчены другим способом во время передачи через сеть 114 по сравнению с кадрами 118. Соответственно, если некоторые из кадров 112 потеряны, то принятые кадры 118 могут быть видны как подмножество посланных кадров 112. Также, если некоторые кадры 112 испорчены, то принятые кадры 118 могут быть видны как посланные кадры 112 в испорченном состоянии.

Обращаясь к рабочей станции 102b более подробно, ее можно реализовать подобно рабочей станции 102а, описанной выше. Таким образом, рабочая станция 102b может включать в себя процессор (процессоры) 104b и машиночитаемый носитель 106b. Машиночитаемый носитель 106b может содержать или иметь доступ к декодеру 120.

Декодер 120 может использоваться для приема и декодирования кадров 118, принятых от рабочей станции 102а через сеть 114. Декодер 120 использовал бы тот же самый протокол для декодирования кадров 118, что и был использован ранее кодером 108 для кодирования кадров 112. Если декодер 120 определяет, что кадры 118 не испорчены, повреждены или потеряны относительно кадров 112, то декодер может декодировать эти кадры 118 в декодированное содержание (контент) 122.

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

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

Возвращаясь к обработке декодера 120, если декодер 120 определяет, что некоторые из кадров 118 были разрушены или повреждены во время передачи через сеть 114 или что некоторые из кадров 112 были потеряны и не прибыли на рабочую станцию 102b, то декодер 120 может соответственно сообщить кодеру 108. Более конкретно, декодер 120 может сообщить кодеру 108 с использованием канала 124 обратной связи. Канал 124 обратной связи может быть реализован, по меньшей мере частично, с использованием сети 114, хотя протокол, используемый для кодирования и/или передачи данных через канал 124 обратной связи, может быть или может не быть тем же самым, что и протокол, используемый для кодирования и/или передачи кадров 112 и 118. Перемещение данных через канал 124 обратной связи через сеть 114 представлено ссылками 124а и 124b. Из-за ошибок в сети или других проблем данные 124а и 124b могут несколько различаться по тем же самым причинам, по которым кадры 112 могут отличаться от кадров 118.

После принятия сообщения о потерянных, поврежденных или другим образом испорченных кадрах 112 или 118 кодер 108 может передать исправленные или замененные кадры 112 к декодеру 120. Понятно, что этот процесс сообщения поврежденных кадров и передачи исправленных или замененных кадров 112 может быть повторен, пока декодер 120 не будет иметь информацию, подходящую для декодирования кадров 118 таким образом, чтобы сформировать декодируемый контент 122 на рабочей станции 102b.

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

Понятно, что только одна рабочая станция 102b и связанный с ней декодер 120 показаны на фиг.1 только для ясности и удобочитаемости, а не для ограничения возможных реализаций рабочего окружения 100. В частности, отметим, что могло бы быть включено любое число различных рабочих станций 102b и соответствующих декодеров 120, с различными одними из рабочих станций 102b и декодеров 120, имеющими различные конфигурации, особенности, производительности, возможности и другие характеристики. Например, различные рабочие станции 102b могли бы поддерживать различные насыщенности цвета, разрешающие способности, выраженные в пикселах (элементах изображения), размеры изображений на экране или другие аспекты обработки исходного контента 110 и/или декодируемого контента 122. Далее понятно, что каждая рабочая станция 102b и/или декодер 120 могли бы иметь соответствующий канал 124 обратной связи. С использованием этого канала 124 обратной связи рабочие станции 102b и/или декодеры 120 могут обеспечить конкретную локальную информацию, имеющую отношение к их локальным окружениям, обратно к кодеру 108.

Структуры данных

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

Фиг.2 иллюстрирует структуру 200 данных, по меньшей мере часть которой может быть подходящей для реализации соответствующих примеров кадров 112 и/или 118, показанных на фиг.1. Предполагая только для примера, что кодер 108 и декодер 120 реализуют транспортный протокол реального времени (RTP), структура 200 данных может включать в себя, для данного кадра 112 и/или 118, поле 205 для стандартного заголовка RTP и поле 210, которое содержит данные, которые считаются полезной нагрузкой кадров 112 и/или 118. Кроме того, структура 200 данных может содержать поле 215 для данных дополнительного заголовка. Данные, содержащиеся в поле 215, могут считаться расширением лежащего в основе протокола, используемого кодером 108 и декодером 120. В примере, показанном на фиг.2, этим протоколом может быть RTP, хотя ясно, что и другие протоколы могут быть равным образом подходящими.

Обращаясь к полю 215 более подробно, фиг.2 иллюстрирует несколько примеров данных, которые могут быть включены в поле 215 для конкретного кадра 112 и/или 118. Подполе 220 может содержать один или несколько управляющих битов кэша. Эти управляющие биты кэша могут дать кодеру 108 возможность контролировать и/или управлять помещением в кэш конкретных кадров 112 и/или 118 посредством декодера 120. Эти биты 220 могут поддерживать операции восстановления и синхронизации кадров между кодером 108 и одними из декодеров 120. Эта операция помещения в кэш более подробно описывается ниже.

Подполе 222 может указывать, для данного кадра 112 и/или 118, каким типом кадра он является. Фиг.2 иллюстрирует три типа кадров, хотя ясно, что могут быть реализованы и другие типы кадров, и реализованные кадры могут быть названы или помечены иначе, чем описано здесь.

Как показано в подполе 222, I-кадр представляет собой целый, самостоятельный кадр контента, например аудио- или видеокадр. I-кадр является «свободно стоящим» и может быть декодирован и воспроизведен посредством декодера 120 без ссылки на какие-либо другие предыдущие или будущие кадры.

P-кадр представляет собой разницу (разность) между текущим состоянием аудио или видео и предыдущим I-кадром. Таким образом, можно сказать, что P-кадр ссылается на предыдущий I-кадр. Поскольку P-кадр содержит данные, представляющие собой только разницы относительно этого предыдущего I-кадра, P-кадр обычно намного меньше, чем I-кадр. Для сохранения полосы частот через сеть 114 может быть подходящим использовать P-кадры максимально возможно. Когда исходный контент 110 проявляет относительно небольшое движение со временем, разницы в последовательных кадрах обычно относительно малы и легко представляются посредством P-кадров. Однако, когда исходный контент 110 проявляет относительно большое движение со временем или проявляет существенное изменение сцены или контекста, кодер 108 может использовать один или несколько I-кадров для установки новой сцены или контекста. Также, частота потерь, испытываемая рабочей станцией 102b и/или декодером 120, может сообщаться рабочей станции 102а и/или кодеру 108. В свою очередь, кодер 108 может рассматривать частоту потерь, сообщенную декодером 120, в определении того, посылать ли I-кадры или P-кадры к декодеру 120. Кроме того, сообщенная частота потерь может быть одним фактором в управлении частотой смены кадров, скоростью передачи битов, качеством и тем, посылать ли Super P-кадры.

Подполе 222 может также поддерживать дополнительный тип кадра 112 и/или 118, который называется здесь для удобства, а не для ограничения, Super P-кадром. Super P-кадр подобен P-кадру в том, что он определяет изменение в контенте относительно предыдущего состояния контента. Однако, вместо ссылки на предыдущий кадр, Super P-кадр ссылается на контент кэша, который локально поддерживается на декодере 120. Эта операция помещения в кэш описывается более подробно ниже.

Подполе 224 может содержать индекс или другой тип уникального идентификатора для данного кадра 112 и/или 118. Например, содержимое подполя 224 может принимать форму порядкового номера для кадров или пакетов, уникальной временной метки, смещения или положения данного кадра 112 и/или 118 в пределах контекста исходного контента 110, смещения данного кадра 112 и/или 118 относительно начала исходного контента 110 и т.п.

Содержимое подполя 224, в любой форме, может быть заполнено кодером 108 при кодировании исходного контента 110 в кадры 112 в рабочей станции 102а. В рабочей станции 102b декодер 120 может ссылаться на содержимое подполя 224 для данного кадра 118 при декодировании и сборке множества кадров 118 в декодированный контент 122. Более конкретно, содержимое подполя 224 может дать декодеру 120 возможность собирать (компоновать) кадры 118 в соответствующий порядок при представлении декодированного контента 122. Кроме того, декодер 120 может использовать содержимое подполя 224, по меньшей мере частично, для определения того, были ли один или несколько кадров 112, посланные кодером 108, потеряны во время передачи через сеть 114 к рабочей станции 102b.

В качестве примера вышеупомянутого, декодер 120 может принимать заданную последовательность кадров 118, имеющую идентификаторы 224, такие как А, В и D. Однако, декодер 120 может ожидать, что эти три кадра 118 имеют такие идентификаторы 224, как А, В и С. Если декодер 120 не принимает кадр С в некоторую величину времени, то декодер 120 может сделать вывод, что кадр 112, соответствующий ожидаемому кадру С, никогда не прибудет и был потерян в сети 114. Соответственно, декодер 120 может сообщить кодеру 108, что пакет С был потерян, например, через канал 124 обратной связи.

Подполе 226 может содержать данные, имеющие отношение к преобразованию цветового пространства, выполняемому кодером 108 на основе характеристик или конфигурации конкретного декодера 120. Напомним, из предыдущего обсуждения фиг.1, что конкретные примеры декодера 120 могут передавать информацию, имеющую отношение к их локальным возможностям или особенностям цветного показа, обратно к кодеру 108, например, через канал 124 обратной связи. В качестве реакции на эту обратную связь от конкретных декодеров 120 кодер 108 может специфически подготовить (адаптировать) кадры 112, которые посылаются к каждому из конкретных декодеров 120. Любые данные, имеющие отношение к преобразованиям цветового пространства, выполняемым кодером 108 от имени данного декодера 120, могут храниться в подполе 226. Например, исходный контент 110 может быть захвачен и представлен для кодера 108 в иллюстративном диапазоне 256 цветов. Однако если данный декодер 120 может поддерживать и показывать только 16 цветов, то вряд ли было бы полезным передавать кадры 112, которые поддерживают 256 цветов, к этому данному декодеру 120. Соответственно, через данные, содержащиеся в подполе 226, кодер 108 может инструктировать декодер 120, как преобразовать эти цвета, представленные в кадре 112, в цвета, которые поддерживаются декодером 120. В дополнение или вместо вышеупомянутого, кодер 108 может указывать, через данные в подполе 226, как кодер 108 уже преобразовал цвета в кадре 112, для выгоды декодера 120.

Подполе 228 может содержать данные, имеющие отношение к любым преобразованиям разрешения пикселов, выполняемым кодером 108 от имени конкретного декодера 120. Вспомним из предыдущего обсуждения фиг.1, что конкретные примеры декодера 120 могут передавать данные, такие как их разрешение пикселов, к кодеру 108, например, через канал 124 обратной связи. Со ссылкой на предыдущее обсуждение подполя 226, касающееся насыщенности цвета, подполе 228 может дать возможность подобной обработки, касающейся разрешения пикселов. Например, исходный контент 110 может быть захвачен и представлен для кодера 108 в относительно высокой плотности пикселов. Однако один или несколько декодеров 120 могут не поддерживать эту высокую плотность пикселов, и другие декодеры 120 могут поддерживать другие плотности пикселов. Таким образом, кодер 108 может оптимизировать плотность пикселов различных кадров 112, посылаемых к различным декодерам 120, в зависимости от возможностей различных декодеров 120. Соответственно, подполе 228 может содержать любую информацию, имеющую отношение к любым преобразованиям в разрешении пикселов, выполняемым кодером 108, или имеющую отношение к любым преобразованиям, которые должны быть выполнены декодером 120 в обработке кадров 118.

После описания предыдущих примеров полей 205-215 и подполей 220-228 ясно, что различные реализации структуры 200 данных могли бы включать в себя одно или несколько примерных полей 205-215 или подполей 220-228 или могут содержать дополнительные данные, поля или подполя, отличные от показанных на фиг.2. Кроме того, компоновка, имена и конфигурация этих полей или подполей структуры 200 данных являются только иллюстративными и выбраны только для удобства иллюстрации и описания и не ограничивают возможные реализации структуры 200 данных. Далее ясно, что данные примеры структуры 200 данных могут быть связаны с конкретными кадрами 112, но каждый пример структуры 200 данных необязательно имеет заполненным каждое поле и/или подполе, как показано на фиг.2.

Фиг.3 иллюстрирует структуру 300 данных, по меньшей мере части которой могут быть подходящими для реализации соответствующих примеров канала 124 обратной связи, показанного на фиг.1. Более конкретно, передача данных от соответствующих примеров декодера 120 к кодеру 108 может быть облегчена, по меньшей мере частично, с использованием структуры 300 данных.

Обращаясь к структуре 300 данных более подробно, поле 305 может содержать данные, сообщающие частоту потерь локальных кадров или пакетов, испытываемую декодерами 120. Эта частота потерь может быть выражена, например, как число кадров, потерянных в единицу времени, испытываемое конкретным декодером 120. При наличии этой информации кодер 108 может выбрать, как часто передавать I-кадры или P-кадры к декодерам 120. Также, эта информация может дать кодеру 108 возможность определять, когда и/или как часто направлять или инструктировать декодеры 120 поместить в кэш конкретные кадры 112/118. Эти операции помещения в кэш обсуждаются далее ниже со ссылками на фиг.4-6.

Поле 310 может содержать данные, сообщающие потерю конкретного кадра 112/118. При сообщении потери кадра декодер 120 может ссылаться на данные таким образом, как это обсуждалось ранее относительно подполя 224, показанного на фиг.2. Напомним, что подполе 224 может содержать информацию идентификации для конкретных кадров 112/118. Например, если декодер 120 подозревает, что один или несколько кадров 112 отсутствуют, декодер 120 может сообщить последовательность кадров 118, которые действительно приняты, так что кодер 108 может определить, какие кадры 112 были потеряны. В другом примере, декодер 120 мог бы рассчитать или определить информацию идентификации для подозреваемых отсутствующих кадров 112.

Поле 315 может содержать данные, представляющие локальное разрешение пикселов, поддерживаемое конкретным декодером 120. В качестве реакции на эти данные 315, сообщенные декодером 120, кодер 108 может преобразовать разрешение пикселов кадров 112/118, посланных к декодеру 120, может инструктировать декодер 120, как преобразовать разрешение пикселов кадров 112/118, или может выполнить другую, связанную с этим обработку. Любое из предыдущего может быть выполнено в соединении с подполем 228, показанным на фиг.2.

Поле 320 может содержать данные, представляющие локальную насыщенность цвета, поддерживаемую конкретным декодером 120. В качестве реакции на эти данные, сообщенные декодером 120, кодер 108 может преобразовать насыщенность цвета кадров 112/118, посланных к декодеру 120, может инструктировать декодер 120, как преобразовать насыщенность цвета кадров 112/118, или может выполнить другую, связанную с эти обработку. Любое из предыдущего может быть выполнено в соединении с подполем 226, показанным на фиг.2.

После описания предыдущих примеров полей 305-320 ясно, что различные реализации структуры 300 данных могли бы включать в себя одно или несколько этих примерных полей 305-320 или могут содержать дополнительные данные, поля или подполя, отличные от показанных на фиг.3. Кроме того, компоновка, имена и конфигурация полей структуры 300 данных являются только иллюстративными и выбраны только для удобства иллюстрации и описания и не ограничивают возможные реализации структуры 300 данных. Далее ясно, что данные примеры структуры 300 данных могут быть связаны с конкретными примерами данных, передаваемых от декодеров 120 к кодеру 108. Однако каждый пример структуры 300 данных необязательно имеет заполненным каждое поле, как показано на фиг.3.

Потоки данных

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

Фиг.4 иллюстрирует рабочее окружение 400 для принятия кадров 118, объединения нового кадра 118 с предыдущим изображением на экране для формирования обновленного изображения на экране, помещения кадра 118 в кэш и объединения нового кадра 118 с содержимым кэша для формирования обновленного изображения на экране. Рабочее окружение 400 может быть реализовано, по меньшей мере частично, посредством рабочей станции 102b и/или декодера 120, хотя аспекты рабочего окружения 400 могут быть также реализованы посредством других компонентов или инструментов.

Предположим, что в момент времени (Т₁) принят кадр 118. Напомним, что кадры 118 могут быть связаны с соответствующими примерами структуры 200 данных, как обсуждалось выше со ссылкой на фиг.2. Предположим далее, что поле 222 структуры 200 данных для кадра 118а указывает, что кадр 118а является I-кадром. Поскольку кадр 118а является I-кадром, кадр 118а может быть представлен непосредственно на изображении 402 на экране, связанном, например, с рабочей станцией 102b. Для удобства, изображение 402 на экране, как оно установилось бы при представлении I-кадра 118а, обозначено как изображение 402а на экране на фиг.4.

Вспомним из обсуждения фиг.2, что структура 200 данных для кадров 112/118 может включать в себя управляющие биты 220 кэша. Предположим с целью описания рабочего окружения 400, что структура 200 данных включает в себя два управляющих бита 220 кэша. Первый управляющий бит кэша может быть помечен «Кэш», а по меньшей мере второй управляющий бит кэша может быть помечен «Использовать Кэш». Любой или оба этих бита могут быть установлены или быть активными для данного кадра 118.

Обращаясь сначала к биту «Кэш», когда этот бит установлен для данного кадра 112/118, этот бит управляет декодером 120, чтобы сохранить кадр 112/118 и/или изображение на экране, являющееся результатом этого кадра 112/118, в кэш 404, поддерживаемый локально рабочей станцией 102b и/или декодером 120. Таким образом, в примере, показанном на фиг.4, предположим, что I-кадр 118а имеет бит «Кэш» установленным или активным, как показано в блоке 406. Соответственно, I-кадр 118а был бы представлен как изображение 402а на экране и сохранен в кэше 404.

Некоторые реализации рабочего окружения 400 могут помещать в кэш все примеры I-кадров 112/118 по умолчанию. Другие реализации рабочего окружения могут помещать в кэш только те I-кадры 112/118, которые имеют их биты «Кэш» установленными или активными.

Предположим, что в момент времени (Т₂) прибывает кадр 118b и что его тип 222 кадра указывает, что это P-кадр. Напомним, что P-кадр выражает разницу между текущим состоянием исходного контента 110 и некоторым предыдущим исходным кадром. Соответственно, содержимое кадра 118b объединяется с предыдущим изображением 402а на экране, как представлено в блоке 408а объединения. Объединение 408а приводит к обновленному изображению 402b на экране.

После описания обработки P-кадра 118b отметим, в общем, что P-кадр 118 может иметь свой бит «Кэш» установленным или активным. В этом случае само содержимое P-кадра 118 может храниться в кэше 404, в некоторых реализациях рабочего окружения 400. В других реализациях изображение на экране (например, изображение 402b на экране), являющееся результатом объединения P-кадра (например, кадра 118b), может быть помещено в кэш.

Предположим, что в момент времени (Т₃) прибывает кадр 118с и что его тип 222 кадра указывает, что это P-кадр. В этом случае содержимое кадра 118с объединяется с предыдущим изображением 402b на экране, как представлено посредством блока 408b объединения. Объединение 408b приводит к обновленному изображению 402с на экране. Предыдущее, однако, предполагает, что кадр 118с действительно прибывает в рабочее окружение 400. Если кадр 118с терпит неудачу в прибытии в рабочее окружение 400, то обновленного изображения 402с на экране не будет. Далее, к моменту времени, когда рабочее окружение 400 обнаруживает потерю кадра, предыдущее изображение 402b на экране может угаснуть или другим образом стать устаревшим. В этом случае кодер 108 может быть извещен о потере кадра. См., например, блок 310 и связанное с ним обсуждение фиг.3.

В качестве реакции на сообщение 310 потери кадра кодер 108 может послать P-кадр 118d замены. Предположим, что рабочее окружение 400 принимает этот P-кадр 118d замены в момент времени (Т₄). Как указано посредством блока 410, управляющие биты 220 кэша для замены P-кадра 118d могут иметь свой бит «Использовать Кэш» установленным или активным. Это управляет рабочим окружением 400 для объединения текущего P-кадра 118d с содержимым 404 кэша, а не с предыдущим изображением на экране. Это объединение из кэша представлено, в основном, посредством блока 408с объединения.

Поскольку этот P-кадр 118d замены закодирован относительно помещенного в кэш исходного кадра, а не предыдущего I-кадра, P-кадр 118d называется здесь Super P-кадром, как обсуждалось ранее. Кодер 108 кодирует Super P-кадр 118d на основе помещенного в кэш исходного кадра, и, таким образом, Super P-кадр является гораздо меньшим, чем был бы I-кадр замены. Таким образом, посылка Super P-кадра 118d для компенсации потери кадра потребляет меньше полосы частот сети, чем посылка I-кадра 118 замены.

В некоторых реализациях кодер 108 может не послать Super P-кадр 118d, если испорченный кадр достаточно близок к следующему I-кадру 118е, который прибудет в декодер 120. В таких реализациях декодер 120 может ожидать следующий I-кадр 118е. Декодер 120 может быть выполнен с одной или несколькими параметрами настройки, которые определяют, как близко разрушенный кадр должен быть относительно следующего I-кадра 118е для того, чтобы эта обработка произошла.

После того как Super P-кадр объединен с содержимым кэша 404, изображение на экране 402d будет законченным. Фиг.4 также изображает прибытие нового I-кадра 118е в момент времени (Т₅), что приводит к новому изображению на экране 402е.

Отметим, что фиг.4 показывает один кэш 404 только для удобства иллюстрации и описания. Дополнительные кэши 404 могли бы быть обеспечены посредством кодера 108 и/или декодера 120 таким образом, что множественные исходные кадры 112/118 могут храниться и поддерживаться посредством кодера 108 и/или декодера 120. Эти множественные исходные кадры 112/118 могут быть испорченными или потерянными. Там, где реализованы множественные кэши 404, дополнительные управляющие биты кэша (например, управляющие биты 220 кэша на фиг.2) могут быть реализованы как подходящие для предписания или указания, какой кэш 404 был использован для кодирования данного кадра 112/118 замены.

Кроме того, отметим, что управляющие биты 220 кэша обеспечивают средство для того, чтобы дать кодеру 108 возможность инструктировать декодер 120 в том, как управлять помещением в кэш и связанной с этим синхронизацией кадров 112/118 замены. Наконец, исходные кадры, помещенные в кодер 108 и декодер 120, и кадры 112/118 замены, кодированные из них, обеспечивают средство для синхронизации обработки кодера 108 и декодера 120.

Процессы обработки

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

Фиг.5 иллюстрирует процесс 500 обработки, который может быть выполнен для кодирования кадров и для ответа на сообщение потерь пакетов. Технологический процесс 500 обработки описывается здесь в соединении с кодером 108. Однако ясно, что технологический процесс 500 обработки может быть реализован на устройствах или компонентах, отличных от кодера 108, не выходя за рамки сущности и объема данного описания.

На этапе 502 кодируют один или несколько кадров из исходного контента 110. На этапе 504 оценивают, поместить ли в кэш текущий кадр 112 для возможной дальнейшей ссылки. Если кадр 112 должен быть помещен в кэш, то на этапе 506 устанавливают бит «Кэш» для текущего кадра 112. Напомним, что бит «Кэш» может быть реализован как часть управляющих битов 220 кэша, показанных на фиг.2. На этапе 508 помещают в кэш текущий кадр 112 для дальнейшей ссылки. Например, текущий кадр 112 может быть помещен в кэш кодером 108. На этапе 510 передают текущий кадр 112 к декодеру 120. Иллюстративная обработка кадра 112, например, в декодере 120 описана со ссылкой на фиг.6 ниже.

Возвращаясь на этап 504, если текущий кадр 112 не должен быть помещен в кэш, то на этапе 512 очищают бит «Кэш» для этого кадра 112. В некоторых примерах бит «Кэш» может быть инициализирован на некоторую установку или очищенное состояние, когда кадр 112 создается. В таких случаях этапы 512 или 506 не могут выполняться, если необязательно изменять состояние бита «Кэш» из его инициализированного состояния.

После этапа 512 процесс 500 обработки переходит на этап 510, описанный выше. После того как этап 510 выполнен, процесс 500 обработки может вернуться на этап 502 для обработки следующего кадра 112, в котором закодирован исходный контент 110. Понятно, что процесс 500 обработки может образовать цикл через этапы 502-512, подходящий для кодирования исходного контента 110 в соответствующие кадры 112.

В любое время во время обработки на этапах 502-512, на этапе 514 могут принять сообщение 310 потерь кадров. Этап 514 может возникнуть в любой точке в пределах процесса 500 обработки. Процесс 500 обработки может также проверять и отвечать на принятие сообщения 310 потерь кадров в любой точке относительно этапов 502-512. Кроме того, процесс 500 обработки может реализовать этап 514 как прерывание, ответвиться от некоторой точки в пределах этапов 502-512 для обслуживания этого прерывания, выполнить этапы 516-522 (описанные ниже) как программу обработки прерываний и вернуться к точке на этапах 502-512, в которой прерывание было принято. Для удобства иллюстрации фиг.5 показывает процесс 500 обработки, ветвящийся на этап 514, когда принято сообщение 310 потерь кадров, независимо от того, где в пределах этапов 502-512 находится процесс 500 обработки.

На этапе 516 ссылаются на кадр, который был помещен в кэш ранее на этапе 508. На этапе 518 кодируют новый P-кадр, относящийся или ссылающийся на кадр, помещенный в кэш. На этапе 520 устанавливают бит «Использовать Кэш» нового P-кадра, если этот бит еще не установлен. Напомним, что управляющие биты 220 кэша, показанные и обсуждаемые на фиг.2, могут включать в себя бит «Использовать Кэш», который управляет, например, декодером 120 для ссылки на содержимое кэша 404, а не на текущее изображение 402 на экране при обновлении текущего изображения 402 на экране. Этот новый P-кадр только для удобства называется Super P-кадром. На этапе 522 передают Super P-кадр к декодеру 120 для того, чтобы дать последнему возможность компенсировать потерю кадра, сообщенную на этапе 514.

Фиг.6 иллюстрирует процесс 600 обработки для обработки кадра, принятого, например, декодером 120. Хотя процесс 600 обработки описан здесь в соединении с такими инструментами, как декодер 120 и кодер 108, другие реализации процесса 600 обработки могли бы также быть реализованы с другими инструментами, не выходя за рамки сущности и объема этого описания.

На этапе 602 принимают кадр 118, переданный, например, на этапе 510, показанном на фиг.5. На этапе 604 проверяют, испорчен ли принятый кадр 118 или ожидался ли другой кадр 118. Рассматривая порчу кадров, на этапе 604 могут проверить на порчу, например, посредством оценки контрольной суммы или другой схемы обнаружения и исправления ошибок, реализованной посредством декодера 120 и/или кодера 108. Рассматривая потерю кадров, напомним, что кадры 118 могут быть связаны с соответствующими примерами структуры 200 данных, описанными выше на фиг.2. Структура 200 данных может содержать поле 224 для установления последовательности или уникальной идентификации кадра 118 другим образом. С использованием, например, этого поля 224 на этапе 604 могут проверить, является ли текущий кадр 118 ожидаемым последующим предыдущего кадра 118. Если нет, то ожидаемый последующий кадра 118 может быть потерян.

Если текущий кадр 118 испорчен или не ожидается, то на этапе 606 сообщают о потерянном или испорченном кадре. Это сообщение, выпущенное на этапе 606, может соответствовать сообщению, принятому на этапе 514, показанном на фиг.5, и сообщению 310 потери кадров, показанному на фиг.3.

Если текущий кадр 118 не испорчен и является ожидаемым последующим кадром, то на этапах 608, 610 и 612 могут проверить, каким типом кадров является кадр 118. Напомним, что структура 200 данных может содержать подполе 222, указывающее тип кадра. На этапе 608 проверяют, является ли кадр 118 I-кадром, на этапе 610 проверяют, является ли кадр 118 P-кадром, и на этапе 612 проверяют, является ли кадр 118 Super P-кадром.

Обращаясь к этапу 608, если кадр 118 является I-кадром, то на этапе 614 могут непосредственно отобразить кадр 118, без ссылки на текущее изображение на экране или какой-либо другой кадр 118. На этапе 610, если кадр 118 является P-кадром, то на этапе 616 обновляют текущее изображение на экране посредством его объединения с кадром 118. На этапе 614 затем представляют обновленное изображение на экране. На этапе 612, если кадр 118 является Super P-кадром, то на этапе 618 обновляют изображение на экране посредством его объединения с содержимым кэша, такого как кэш 404, показанный на фиг.4. Напомним, что Super P-кадр может быть указан или обнаружен посредством бита «Использовать Кэш», установленного или активированного. На этапе 614 затем представляют обновленное изображение на экране.

После этапа 612, если кадр 118 не является ни I-кадром, P-кадром, ни Super P-кадром, то на этапе 620 могут обработать этот другой тип кадра. После этого процесс 600 обработки может вернуться на этап 602 для ожидания следующего кадра 118.

После этапа 614 на этапе 622 проверяют, установлен ли бит «Кэш» для кадра 118. Если это так, то на этапе 624 сохраняют кадр 118 в кэше, таком как, например, кэш 404, показанный на фиг.4. Блок 602 затем ожидает прибытия следующего кадра 118. Возвращаясь на этап 614, если бит «Кэш» не установлен для кадра 118, то этап 624 может быть обойден, и на этапе 602 затем ожидают прибытия следующего кадра 118.

Заключение

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

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

Изобретение относится к медиа кодерам и декодерам. Техническим результатом является обеспечение эффективной синхронизации кадров между кодерами и декодерами. Указанный технический результат достигается тем, что кодер кодирует кадры, которые основаны на исходном контенте, подлежащем посылке к декодеру. Кодер может определить, следует ли поместить в кэш кадр, посредством кодера и декодера. Если кадр должен быть помещен в кэш, то кодер может указать это посредством кодирования этого кадра одним или несколькими управляющими битами кэша. Декодер может принять кадр от кодера и может проверить управляющие биты кэша для определения того, поместить ли в кэш этот кадр, и может декодировать этот кадр. 2 н. и 10 з.п. ф-лы, 6 ил.

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

2. Способ по п.1, дополнительно содержащий этап, на котором помещают в кэш кадр в кодере.

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

4. Способ по п.1, дополнительно содержащий передачу кадра, по меньшей мере, к одному декодеру.

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

6. Способ по п.1, дополнительно содержащий прием данных, касающихся разрешения пикселов, поддерживаемых декодером.

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

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

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

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

11. Способ по п.10, дополнительно содержащий этап, на котором помещают в кэш кадр.

12. Способ по п.10, дополнительно содержащий этап объединения кадра замены, по меньшей мере, с одним помещенным в кэш исходным кадром.