РОДСТВЕННЫЕ ЗАЯВКИ НА ПАТЕНТ
Эта непредварительная патентная заявка США испрашивает приоритет и настоящим включает посредством ссылки в ней полное раскрытие, одновременно рассматриваемой предварительной патентной заявки США № 60/413060 от 24 сентября 2002 г. на "Способы аппаратного ускорения выполнения регулировок формирующего усилителя (ФУ) видеоизображений в устройстве отображения компьютера".
Эта непредварительная патентная заявка США также испрашивает приоритет и настоящим включает посредством ссылки в ней на полное раскрытие одновременно рассматриваемой предварительной патентной заявки США № 60/376880 от 15 апреля 2002 г. на "Способы и устройства для устранения чересстрочности в видеоизображениях".
Эта непредварительная патентная заявка США предметно связана с непредварительной патентной заявкой США № 10/273505 от 18 октября 2002 г. на "Способы и устройства для обработки чересстрочных видеоизображений для устройств отображения видеоданных с построчной разверткой". Эта непредварительная патентная заявка США № 10/273505 также включена в настоящее описание посредством ссылки во всей своей полноте.
ОБЛАСТЬ ТЕХНИКИ
Это раскрытие относится, в основном, к обработке данных изображения/графики для отображения и, в частности, в качестве примера, а не ограничения, для обеспечения взаимодействия между визуализаторами видеоданных и драйверами графических устройств, используя протокол для передачи информации между ними, а также косвенно функциональных возможностей. Такая информация может включать в себя запросы, ответы, инструкции и т.д., которые ориентированы, например, на операции регулировки ФУ.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
В типичной вычислительной среде графическая плата, или аналогичная ей, ответственна за передачу изображений на устройство отображения и за выполнение, по меньшей мере частично, обработки изображений. Для видеоизображений часто используется устройство и способ наложения графики при помощи графической платы и всего вычислительного устройства. Например, для отображения видеоизображений с цифрового многофункционального диска или от источника потоковой передачи из Интернета, инициируется процедура наложения графики для размещения и поддержания видеоизображений.
Процедура наложения графики выбирает прямоугольник и цвет фонового экрана для определения расположения экрана, на котором должно отображаться видеоизображение. Прямоугольник может быть определен начальной координатой для угла прямоугольника вместе с требуемыми высотой и шириной. Цветом фонового экрана обычно является редко наблюдаемый цвет, такой как ярко-розовый цвет, и используется, чтобы обеспечить, что видеоизображение накладывается только в пределах указанного прямоугольника, если видеоизображение логически позиционируется на самом верхнем слое рабочего стола на экране устройства отображения.
Во время работы, так как графическая плата подает цвета пиксела на устройство отображения, она осуществляет проверку для определения того, находится ли расположение данного пиксела в пределах выбранного прямоугольника наложения графики. Если нет, то на устройство отображения передаются данные изображения по умолчанию. Если, с другой стороны, расположение данного пиксела находится в пределах выбранного прямоугольника наложения графики, графическая плата осуществляет проверку для определения того, соответствуют ли данные изображения по умолчанию этого пиксела выбранному цвету фонового экрана. Если нет, на устройство отображения для данного пиксела передаются данные изображения по умолчанию. Если, с другой стороны, цветом данного пиксела является выбранный цвет фонового экрана, графическая плата направляет данные видеоизображения на устройство отображения для этого данного пиксела.
У этого способа наложения графики, к сожалению, существует несколько недостатков. Во-первых, в любой данный момент времени в действии находятся обычно только аппаратные ресурсы, достаточные для одной процедуры наложения графики. Тем не менее, использование способа наложения графики всегда приводит к ограничениям в количестве возможных одновременных отображений видеоизображения, ограничиваемых аппаратным обеспечением. Во-вторых, розовый цвет или другой цвет фонового экрана иногда становится видимым (т.е. отображается на соответствующем устройстве отображения), когда окно, содержащее отображаемое видеоизображение, быстро перемещается по рабочему столу на экране устройства отображения.
В-третьих, команда распечатки изображения экрана не действует эффективно, так как видеоизображение, которое отображается на устройстве отображения, не захватывается командой распечатки изображения экрана. Вместо этого, командой распечатки изображения экрана захватывается цвет фонового экрана, так что распечатываемое (или копируемое и вставляемое) изображение включает в себя сплошной прямоугольник цвета фонового экрана, когда видеоизображение отображается на устройстве отображения.
Другой способ отображения видеоизображений предусматривает использование главного микропроцессора для выполнения регулировок видеоданных перед передачей видеоизображения на графический процессор для подачи на устройство отображения. Этот способ с главным процессором (процессором-хостом) также имеет ряд недостатков. Во-первых, главный микропроцессор и связанная с ним подсистема памяти типичной вычислительной среды не оптимизирована для обработки больших видеоизображений. Следовательно, сильно ограничивается размер и число видеоизображений, которые могут быть отображены. Во-вторых, для того чтобы главный микропроцессор работал эффективно, видеоизображение должно постоянно находиться в памяти, которая непосредственно адресуется главным микропроцессором. В результате, другие виды аппаратного ускорения, такие как разуплотнение и/или устранение чересстрочности, не могут быть выполнены для видеоизображения.
Таким образом, известные способы, такие как процедура наложения графики и использование главного процессора, приводят к визуальным артефактам, являются медленнодействующими и/или неэффективно используют ресурсы памяти, аппаратно ограничены, ограничивают гибкость презентации видеоданных и/или не обеспечивают полностью функциональность команды распечатки экрана. Следовательно, существует потребность в схемах и/или способах устранения этих и других недостатков посредством, в том числе, обеспечения взаимодействия между визуализаторами видеоданных и драйверами графических устройств.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Обеспечение взаимодействия между визуализаторами видеоданных и драйверами графических устройств может выполняться посредством протоколов связи и/или интерфейсов прикладного программирования (ИПП), которые обеспечивают обмен информацией, касающейся возможностей обработки изображения соответствующего графического аппаратного обеспечения, между драйвером графического устройства и визуализатором видеоданных. Возможности обработки изображения включают в себя возможности обработки видеоданных; возможности обработки видеоданных включают в себя, в качестве примера, но не ограничения, регулировки управления формирующего усилителя (ФУ), устранение чересстрочности, коррекции формата (сжатие-растяжение по осям) изображения, преобразования цветового пространства, преобразования частоты кадров, вертикальное или горизонтальное зеркальное отображение и альфа-смешение.
В примерном осуществлении способа способ обеспечивает взаимодействие между одним или несколькими визуализаторами видеоданных и по меньшей мере одним драйвером графического устройства, причем способ включает в себя действия: запроса визуализатором видеоданных из одного или нескольких визуализаторов видеоданных, по меньшей мере одного драйвера графического устройства в отношении возможностей обработки видеоданных; и информирование по меньшей мере одним драйвером графического устройства визуализатора видеоданных по меньшей мере о подмножестве возможностей обработки видеоданных, которое по меньшей мере один драйвер графического устройства может предложить визуализатору видеоданных.
В первом приведенном для примера осуществлении носителя его исполняемые электронными средствами инструкции для визуализатора видеоданных создают действия, включающие в себя: выдачу запроса от визуализатора видеоданных на драйвер графического устройства, причем в запросе запрашивается информация, относящаяся к возможностям ФУ, и прием ответа визуализатором видеоданных от драйвера графического устройства, причем ответ включает в себя запрашиваемую информацию, относящуюся к возможностям ФУ.
Во втором приведенном для примера осуществлении носителя его исполняемые электронными средствами инструкции для драйвера графического устройства создают действия, включающие в себя: прием запроса драйвером графического устройства от визуализатора видеоданных, причем в запросе запрашивается информация, относящаяся к возможностям ФУ; и посылку ответа на визуализатор видеоданных от драйвера графического устройства, причем ответ включает в себя запрашиваемую информацию, которая относится к возможностям ФУ.
В приведенном для примера осуществлении системы система обеспечивает взаимодействие между визуализатором видеоданных и драйвером графического устройства, причем система включает в себя: логику визуализации видеоданных, которая предназначена для подготовки запросов, в которых запрашивается информация, относящаяся к возможностям ФУ, которые могут быть применены к видеоданным, которые подлежат отображению; и логику драйвера графического устройства, которая предназначена для подготовки ответов, указывающих, какие возможности ФУ могут быть применены к видеоданным, которые подлежат отображению.
Здесь описаны другие осуществления способа, системы, устройства, протокола, носителя, средства и т.д.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Одинаковые позиции на чертежах используются для обозначения одинаковых и/или соответствующих аспектов, признаков и компонентов.
На фиг.1 представлен первый конвейер обработки видеоданных, который включает в себя операцию регулировки ФУ.
На фиг.2 представлен второй конвейер обработки видеоданных, который включает в себя две операции обработки видеоданных для получения объекта RGB визуализации.
На фиг.3 представлен третий конвейер обработки видеоданных, который включает в себя одну операцию обработки видеоданных для получения объекта RGB визуализации.
На фиг.4 представлена блок-схема, которая иллюстрирует некоторые функциональные элементы вычислительного или другого электронного устройства, выполненное для обеспечения взаимодействия между визуализаторами видеоданных и драйверами графических устройств.
На фиг.5 представлена диаграмма связи/передачи сигналов, которая иллюстрирует примерный протокол между визуализатором видеоданных и драйвером графического устройства.
На фиг.6 представлена схема последовательности операций, которая иллюстрирует примерный способ обеспечения взаимодействия между визуализатором видеоданных и драйвером графического устройства.
На фиг.7 представлена примерная вычислительная операционная среда (или операционная среда общего электронного устройства), которая может (полностью или частично) реализовать по меньшей мере один аспект обеспечения взаимодействия между визуализаторами видеоданных и драйверами графических устройств, как описано в этой заявке.
ПОДРОБНОЕ ОПИСАНИЕ
Примерные конвейеры обработки видеоданных и регулировки ФУ
Примерный конвейер обработки видеоданных с регулировкой ФУ
На фиг.1 представлен первый конвейер 100 обработки видеоданных, который включает в себя операцию 104 регулировки ФУ. Первый конвейер 100 обработки видеоданных может быть осуществлен с использованием графического аппаратного обеспечения, такого как графическая плата. Он включает в себя (i) три блока 102, 106 и 108 памяти изображения и (ii) по меньшей мере одну операцию 104 обработки изображения. Блок 102 памяти изображения включает в себя внеэкранную плоскую YUV-поверхность видеоизображения. Операция 104 обработки изображения, которая содержит операцию 104 регулировки ФУ, как изображено, применяется к блоку 102 памяти изображения для получения блока 106 памяти изображения. Блок 106 памяти изображения включает в себя внеэкранную плоскую YUV-поверхность или YUV-текстуру в зависимости от параметров и возможностей графического аппаратного обеспечения, которое выполняет операции регулировки изображения.
После одной или нескольких дополнительных операций обработки изображения (не показанных подробно на фиг.1) графическое аппаратное обеспечение создает блок 108 памяти изображения, который включает в себя объект RGB визуализации. Объект RGB визуализации блока 108 памяти изображения может отображаться на устройстве отображения при помощи графического аппаратного обеспечения без дополнительных операций обработки изображения. Кроме того, блок 108 памяти изображения включает в себя данные изображения для каждого пиксела экрана устройства отображения, так что нет необходимости считывать данные изображения с другой памяти во время направления данных изображения с блока 108 памяти изображения на устройство отображения.
Операция 104 регулировки ФУ относится к одной или нескольким регулировкам формирующего усилителя (ФУ). Принцип регулировок ФУ возник тогда, когда видеоданные хранились, обрабатывались и отображались с использованием аналоговых методов. Однако теперь операции 104 регулировки ФУ могут быть выполнены с использованием цифровых методов. Такие операции 104 регулировки ФУ могут включать в себя одну или несколько операций, которые ориентированы на одно или несколько по меньшей мере из следующих свойств видеоизображения: яркость, контраст, насыщенность и оттенок.
Примерные свойства видеоданных, относящиеся к ФУ
Следующие описания яркости, контраста, насыщенности и оттенка, вместе с возможными и/или предполагаемыми установками для манипулирования их величинами, представлены для описанного примерного варианта осуществления. Альтернативно, могут быть использованы другие принципы регулировок ФУ.
Яркость: Яркость, альтернативно, известна как "установка черного"; не следует путать яркость с коэффициентом усиления (контрастом). Она используется для установки уровня "черного для визуального отображения" в каждой конкретной процедуре для визуального отображения. Функционально, она добавляет или вычитает одинаковое количество шагов (битов) квантования из всех слов сигнала яркости в изображении. Она может и обычно действительно создает случаи ограничения, если смещение плюс некоторое слово сигнала яркости меньше 0 или больше полного диапазона. Она обычно взаимодействует с регулировкой контраста.
Контраст: Контраст представляет собой "коэффициент усиления" сигнала яркости изображения. Он используется для изменения относительных величин светлого и темного в изображении. Функционально, он представляет собой линейный положительный или отрицательный коэффициент усиления, который отображает входной диапазон величин на меньший или больший диапазон. Точка установки (например, отсутствие изменения при изменении коэффициента усиления) нормально равна коду 0, но, более точно, она представляет собой кодовое слово, которое связано с номинальной точкой установки черного для визуального отображения. Структура коэффициента усиления контраста представляет собой изменение передачи по линейному закону, которая проходит через эту точку установки. Функции контраста обычно включают в себя округление вычисленных величин, если установленный коэффициент усиления представляет собой что-то отличное от однозначного соответствия, и это округление обычно включает в себя программное сглаживание, чтобы устранить образование видимого артефакта "оконтуривание".
Насыщенность: Насыщенность представляет собой логический эквивалент контраста. Она представляет собой функцию усиления с точкой установки относительно "нулевой насыщенности цвета" (например, код 128 при YUV или код 0 при RGB в описанном осуществлении).
Оттенок: Оттенок представляет собой фазовое соотношение цветовых составляющих. Оттенок типично указывается в градусах, причем действительный диапазон составляет от -180 до +180, а значением по умолчанию является 0 градусов. Оттенок в компонентных системах (например, YUV или RGB) представляет собой переменную из трех частей, в которой три составляющие изменяются вместе так, чтобы сохранить действительные соотношения сигналов цветности и яркости.
Примерная относящаяся к ФУ регулировка в цветовом пространстве YUV
Следующие описания для обработки яркости, контраста, насыщенности и оттенка в цветовом пространстве YUV, вместе с возможными и/или предполагаемыми установками для манипулирования их величинами, представлены для описанного примера осуществления. Альтернативно, могут быть использованы другие принципы регулировок. В общих чертах, работа в цветовом пространстве YUV упрощает вычисления, которые связаны с управлением регулировками ФУ видеопотока.
Обработка Y: Шестнадцать (16) вычитается из величин Y для приведения уровня черного в нуль. Это устраняет смещение постоянной составляющей, так что регулировка контраста не изменяет уровень черного. Так как величины Y могут быть меньше 16, в этом месте обработки должны поддерживаться отрицательные величины Y. Контраст регулируется посредством умножения величин пикселей YUV на постоянную. (Если регулируются U и V, то результатом является изменение цвета, всякий раз когда изменяется контраст.) Величина свойства яркости добавляется (или вычитается) из величин Y с регулируемым контрастом; это предотвращает введение смещения постоянной составляющей из-за регулировки контраста. Наконец, величина 16 обратно добавляется для приведения уровня черного в 16. Примерное уравнение для обработки величин Y представляет собой следующее:
Y'=((Y-16)×С)+B+16,
где С - величина контраста, а B - величина яркости.
Обработка UV: Сто двадцать восемь (128) сначала вычитается из величин U и V, чтобы позиционировать диапазон относительно нуля. Свойство оттенка одно реализуется смешиванием вместе величин U и V следующим образом:
U'=(U-128)×Cos(H)+(V-128)×Sin(H) и
V'=(V-128)×Cos(H)-(U-128)×Sin(H),
где H представляет требуемый угол, соответствующий оттенку.
Насыщенность регулируется посредством умножения U и V на постоянную вместе с величиной насыщенности. Наконец, величина 128 добавляется обратно к U и V. Объединенная обработка оттенка и насыщенности на основе данных UV представляет собой следующее:
U'=(((U-128)×Cos(H)+(V-128)×Sin(H))×С×S)+128 и
V'=(((V-128)×Cos(H)-(U-128)×Sin(H))×С×S)+128,
где С - постоянная величина, как и в вышеприведенном уравнении для Y', H - угол оттенка и S - насыщенность.
Примерный конвейер обработки видеоданных с двумя операциями обработки
На фиг.2 представлен второй конвейер 200 обработки видеоданных, который включает в себя две операции 202 и 206 обработки видеоданных для получения RGB визуализации объекта 108. Второй конвейер 200 обработки видеоданных включает в себя (i) три блока 102, 204 и 108 памяти изображения и (ii) две операции 202 и 206 обработки изображения.
Для второго конвейера 200 обработки видеоданных, в большинстве случаев, блок 204 памяти изображения включает в себя RGB-текстуру. Блок 204 памяти изображения следует из блока 102 памяти изображения после применения операции 202 обработки изображения. Блок 108 памяти изображения получается из блока 204 памяти изображения после операции 206 обработки изображения.
Могут быть выполнены другие операции обработки изображения в дополнение к регулировке управления ФУ. Например, любая одна или несколько из следующих примерных операций обработки видеоданных может быть применена к данным видеоизображения перед его отображением на экране устройства отображения:
1. регулировки управления ФУ;
2. устранение чересстрочности;
3. коррекция формата изображения
4. преобразование цветового пространства; и
5. вертикальное или горизонтальное зеркальное отображение и альфа-смешение.
Когда возможно, требуемые операции обработки видеоданных (и/или другого изображения) объединяются в несколько операций насколько это возможно с тем, чтобы уменьшить общую ширину полосы памяти, которая используется при обработке видеоизображений. Степень, до которой операции обработки могут быть объединены, определяется, в основном, возможностями графического аппаратного обеспечения. Типично, обработка по преобразованию цветового пространства и обработка по коррекции формата изображения применяются ко многим, если не к большинству, видеопотоков. Однако вертикальное/горизонтальное зеркальное отображение и альфа-смешение применяются менее часто.
Для второго конвейера 200 обработки видеоданных обработка по регулировке ФУ и обработка по преобразованию цветового пространства объединяются в операции 202 обработки изображения. Обработка по коррекции формата изображения выполняется с операцией 206 обработки изображения. Дополнительно, вертикальное/горизонтальное зеркальное отображение и/или альфа-смешение могут быть объединены в операцию 206 обработки изображения. Как изображено, графическое аппаратное обеспечение, которое осуществляет второй конвейер 200 обработки видеоданных, использует две операции обработки изображения и три блока памяти изображения для получения блока 108 памяти изображения в качестве объекта RGB визуализации. Однако некоторое графическое аппаратное обеспечение может быть более эффективным.
Примерный конвейер обработки видеоданных с одной операцией обработки
На фиг.3 представлен третий конвейер 300 обработки видеоданных, который включает в себя одну операцию 302 обработки видеоданных для объекта 108 RGB визуализации. Как правило, третий конвейер 300 обработки видеоданных осуществлен с графическим аппаратным обеспечением, использующим одну операцию 302 обработки видеоданных и два блока 102 и 108 памяти изображения. Более конкретно, блок 108 памяти изображения получается из блока 102 памяти изображения в результате операции 302 обработки изображения. Операция 302 обработки изображения, как изображено, включает в себя многочисленные операции обработки видеоданных, как описано ниже.
Третий конвейер 300 обработки видеоданных короче, чем второй конвейер 200 обработки видеоданных (на фиг.2), так как операция 302 обработки изображения объединяет обработку по регулировке ФУ, обработку по преобразованию цветового пространства и обработку по коррекции формата изображения. Поэтому число каскадов в данном конвейере обработки видеоданных зависит от числа и типа операций обработки изображения, которые запрашиваются программным обеспечением (например, приложением, компонентой операционной системы и т.д.), отображающим видеоизображение, а также возможностей соответствующего графического аппаратного обеспечения. Примерное программное обеспечение, графическое аппаратное обеспечение и т.д. описаны дополнительно ниже с ссылкой на фиг.4.
Примерное относящееся к видеоданным программное обеспечение и графическое аппаратное обеспечение
На фиг.4 представлена блок-схема 400, которая изображает некоторые функциональные элементы вычислительного или другого электронного устройства, предназначенного для обеспечения взаимодействия между визуализатором 410 видеоданных и драйвером 422 графического устройства. Эти различные примерные элементы и/или функции реализованы в аппаратном обеспечении, программном обеспечении, программно-аппаратных средствах, некоторых их комбинациях и т.п. Такое аппаратное обеспечение, программное обеспечение, программно-аппаратные средства, некоторые их комбинации и т.п. совместно и отдельно упоминаются здесь в общем как логика.
Конфигурация блок-схемы 400 представляет собой только пример устройства или системы обработки видеоданных. Необходимо понять, что один или несколько из изображенных и описанных элементов и/или функций могут быть объединены, переставлены, дополнены, исключены и т.д. без искажения возможности обеспечения взаимодействия между визуализаторами видеоданных и драйверами графических устройств.
Устройство или система 400 включает в себя логику 408 преобразования, которая, например, может включать в себя инструкции, выполняемые центральным процессором (ЦП), блоком обработки графики и/или их комбинацией. Логика 408 преобразования конфигурирована для приема кодированных видеоданных по меньшей мере от одного источника 406. Кодированные видеоданные от источника 406 кодируются одинаковым образом (например, согласно стандарту MPEG-2 и т.д.), и логика 408 преобразования конфигурируется для декодирования кодированных видеоданных.
В качестве примера, источник 406 может включать в себя магнитный диск и связанный с ним накопитель диска, оптический диск и связанный с ним накопитель диска, магнитную ленту и связанный с ней накопитель магнитной ленты, твердотельную память, передаваемый сигнал, среду передачи или другой аналогичный источник, конфигурированный для доставки или предоставления иным образом кодированных видеоданных на логику 408 преобразования. Дополнительные примеры источника 406 описаны ниже с ссылкой на фиг.7. В некоторых реализациях источник 406 может включать в себя множество компонентов источников, такие как сетевой источник и удаленный источник. Как изображено, источник 406 включает в себя Интернет 404 и удаленное дисковое устройство 402 хранения.
Декодированные видеоданные, которые выводятся логикой 408 преобразования, подаются по меньшей мере на один визуализатор 410 видеоданных. В качестве примера, но не ограничения, визуализатор 410 видеоданных может быть реализован с использованием видеомикшера и визуализатора операционной системы (ОС) Microsoft® Windows®. В описанном осуществлении визуализатор 410 видеоданных конфигурируется для обеспечения возможности логики 408 преобразования декодировать видеопоток для выполнения операций обработки видеоданных, чтобы смешивать любые другие дополнительные видеоданные, такие как кодированные субтитры (КС) или изображения фрагментов цифрового многофункционального диска, с видеоизображениями и т.д. И в соответствующий момент времени визуализатор 410 видеоданных представляет или вызывает представление данных видеоизображения на логику 412 графического интерфейса для конечного отображения на устройстве 436 отображения.
Результирующие видеоданные визуализации, таким образом, подаются на логику 412 графического интерфейса. В качестве примера, но не ограничения, логика 412 графического интерфейса может включать в себя, например, логики DirectDraw®, Direct3D® и другие подобные логики. Логика 412 графического интерфейса конфигурируется для обеспечения интерфейса между визуализатором 410 видеоданных и графическим устройством 424. Как изображено, графическое устройство 424 включает в себя блок 426 графического процессора (БГП), видеопамять 432 и цифроаналоговый преобразователь (ЦАП) 434. В качестве примера, но не ограничения, графическое устройство 424 может быть реализовано в виде платы видеографики, которая конфигурируется внутри вычислительного или другого электронного устройства.
Выходные данные изображения логики 412 графического интерфейса подаются на драйвер 422 графического устройства с использованием интерфейса 414 драйверов устройств (ИДУ). На фиг.3 интерфейс 414 драйверов устройств описывается как имеющий по меньшей мере один интерфейс 416 прикладного программирования (ИПП), связанный с ним. Интерфейс 414 драйверов устройств конфигурируется для поддержки и/или установления интерфейса между визуализатором 410 видеоданных и драйвером 422 графического устройства.
Как изображено в устройстве/системе 400 и для описанного осуществления, интерфейс 414 драйверов устройств и драйвер 422 графического устройства дополнительно могут быть категоризированы как составляющие часть либо пользовательского режима 418, либо режима 420 ядра в отношении соответствующего окружения операционной системы и графического устройства 424. Следовательно, визуализатор 410 видеоданных и интерфейс 414 драйверов устройств составляют часть пользовательского режима 418, а драйвер 422 графического устройства составляет часть режима 420 ядра. Коммуникации, происходящие по меньшей мере между интерфейсом 414 драйверов устройств и драйвером 422 графического устройства, характеризуются переходами между пользовательским режимом 418 и режимом 420 ядра.
В описанном осуществлении данные видеоизображения, которые выводятся визуализатором 410 видеоданных, подаются, таким образом, на блок 426 графического процессора. Блок 426 графического процессора конфигурируется для выполнения одной или нескольких операций обработки изображения. Эти операции обработки изображения включают в себя регулировки ФУ и/или другие операции обработки видеоданных, как указывается, соответственно, логикой 428 регулировки ФУ и/или логикой 430 других операций обработки видеоданных. Операции регулировки ФУ и другие приведенные для примера операции обработки видеоданных, такие как устранение чересстрочности и преобразование частоты кадров, описаны дополнительно ниже, а также выше.
Выход блока 426 графического процессора подается на видеопамять 432. Когда происходит считывание из видеопамяти 432, результирующие данные изображения могут быть направлены на цифроаналоговый преобразователь 434, который выводит соответствующий аналоговый видеосигнал, пригодный для отображения посредством устройства 436 отображения. При других конфигурациях устройство 436 отображения может обеспечивать отображение цифровых данных изображения с видеопамяти 432 без аналогового преобразования цифроаналоговым преобразователем 434.
Примерный протокол между визуализатором видеоданных и драйвером графического устройства
На фиг.5 представлена диаграмма 500 связи/передачи сигналов, которая иллюстрирует примерный протокол между визуализатором 410 видеоданных и драйвером 422 графического устройства. Примерный протокол облегчает выполнение операций обработки видеоданных (или других изображений), таких как регулировка ФУ. Такие операции обработки видеоданных могут включать в себя те, которые запрашиваются/определяются приводимым в действие и управляемым пользователем приложением для отображения видеоданных (например, вызывающим приложением).
Диаграмма 500 связи/передачи сигналов включает в себя многочисленные обмены данными и передачи данных между визуализатором 410 видеоданных и драйвером 422 графического устройства. Дополнительно, связь может устанавливаться и/или ей может способствовать графический интерфейс 412 (на фиг.4) и/или интерфейс 414 драйверов устройств вместе с их любым применимым ИПП 416.
Обмен 502 данными ориентирован на установление возможностей обработки видеоданных (ОВ). Конкретно, визуализатор 410 видеоданных запрашивает или выдает запрос на передачу 502А на драйвер 422 графического устройства в отношении возможностей обработки видеоданных, которыми обладает драйвер 422 графического устройства и которые должны быть им предоставлены. В ответе 502В драйвер 422 графического устройства информирует визуализатор 410 видеоданных о выделенных возможностях обработки видеоданных.
Выделенные возможности обработки видеоданных включают в себя те операции обработки видеоданных, которые драйвер 422 графического устройства может выполнить. Они могут включать в себя одну или несколько операций регулировки управления ФУ, операций устранения чересстрочности, операций коррекции формата изображения, операций преобразования цветового пространства, вертикальное/горизонтальное зеркальное отображение и альфа-смешение, операции преобразования частоты кадров и т.д. Драйвер 422 графического устройства может выбрать и предоставить всю или часть оставшейся рабочей полосы обработки видеоданных. В результате назначения меньшей, чем вся оставшаяся рабочая полоса обработки видеоданных, драйвер 422 графического устройства может сохранить в резерве дополнительную рабочую полосу обработки видеоданных при последующих запросах.
Обмен 504 данными ориентирован на установление возможностей свойств управления для определенной операции обработки видеоданных. В запросе 504А, который посылается от визуализатора 410 видеоданных на драйвер 422 графического устройства, визуализатор 410 видеоданных определяет конкретную операцию обработки видеоданных, выделенную в ответе 502В. Запрос 504А также может включать в себя запрос, что или какие возможности свойств драйвер 422 графического устройства может выполнить в отношении конкретной операции обработки видеоданных. В ответе 504В драйвер 422 графического устройства информирует визуализатор 410 видеоданных в отношении возможностей свойств, которые доступны для указанной конкретной операции обработки видеоданных. Обмен 504 данными может быть исключен, если, например, отсутствуют возможности многократного управления для конкретной операции обработки видеоданных.
Обмен 506 данными ориентирован на установление, какие из других выделенных операций обработки видеоданных могут быть выполнены одновременно с конкретной операцией обработки видеоданных, как указано. В запросе 506А визуализатор 410 видеоданных выдает запрос на драйвер 422 графического устройства с целью определения, какие операции обработки видеоданных, если они есть, могут быть выполнены одновременно с конкретной операцией обработки видеоданных. Драйвер 422 графического устройства информирует визуализатор 410 видеоданных в ответе 506В операций обработки видеоданных, что драйвер 422 графического устройства может выполнить одновременно с конкретной операцией обработки видеоданных. В качестве примера, необходимо заметить, что (i) передачи 504А и 506А и/или (ii) передачи 504В и 506В могут быть объединены в одну передачу запроса и ответа, соответственно.
Обмен 508 данными ориентирован на установление значений для указанного свойства управления конкретной операции обработки видеоданных. В запросе 508А визуализатор 410 видеоданных указывает в запросе свойство управления для конкретной операции обработки видеоданных. Указанное свойство управления может быть выбрано из доступных свойств управления, предоставленных в ответе 504В. Драйвер 422 графического устройства обеспечивает значения, которые относятся к указанному свойству управления для конкретной операции обработки видеоданных, на визуализатор 410 видеоданных. Этими значениями могут быть числовые точки установки, диапазоны и т.д., которые визуализатор 410 видеоданных может использовать как основу при выдаче инструкций на драйвер 422 графического устройства на выполнение конкретной операции обработки видеоданных. Обмен 508 данными может быть повторен для каждого доступного свойства управления, которое указано в ответе 504В. Альтернативно, один такой обмен 508 данными может быть ориентирован на множество (включая все) свойств управления из доступных свойств управления.
Обмен 510 данными ориентирован на инициирование объекта потоковой обработки видеоданных. В инструкции 510А визуализатор 410 видеоданных посылает команду на драйвер 422 графического устройства на открытие объекта потоковой обработки видеоданных. Эта команда может передаваться от имени приложения или другого программного компонента, который пытается представить видеоизображения на устройстве 436 отображения. В ответе 510В драйвер 422 графического устройства возвращает описатель (идентификатор) для объекта потоковой обработки видеоданных на запрашивающий визуализатор 410 видеоданных.
В передаче 512А визуализатор 410 видеоданных инструктирует драйвер 422 графического устройства на выполнение конкретной или другой выделенной операции обработки видеоданных. Команда на выполнение операции обработки видеоданных может включать в себя выбранные числа для установки и/или изменения величин для одного или нескольких свойств управления для конкретной операции обработки видеоданных. В ответ драйвер 422 графического устройства выполняет операцию 512В обработки видеоданных, как было запрошено в передаче 512А. Типично, по меньшей мере один визуализатор 410 видеоданных присваивается каждому приложению, которое должно отображать видеоданные. Всякий раз, когда такое вызывающее приложение запрашивает операцию обработки видеоданных, например, визуализатор 410 видеоданных направляет такой запрос в виде инструкции на операцию обработки видеоданных, дополнительно после повторного форматирования, преобразования и т.д. на драйвер 422 графического устройства.
Команды 512А на выполнение операции обработки видеоданных и результирующие операции 512В обработки видеоданных могут повторяться по необходимости, когда присутствует объект потоковой обработки видеоданных. Когда видеоданные завершены или завершилось соответствующее программное обеспечение, инструкция 514 на закрытие объекта потоковой обработки видеоданных передается с визуализатора 410 видеоданных на драйвер 422 графического устройства.
Подходы, иллюстрируемые на фиг.4, 5 и 6, например, изображены на диаграммах, которые разделены на множество блоков и/или множество передач. Однако порядок и/или расположение, в котором описаны и/или показаны эти подходы, как предполагается, не должны истолковываться как ограничение, и любое количество блоков/передач может быть объединено и/или переупорядочено в любом порядке для осуществления одной или нескольких систем, способов, носителей, протоколов, устройств и т.д. для обеспечения взаимодействия между визуализаторами видеоданных и драйверами графических устройств. Кроме того, хотя описание здесь включает в себя ссылки на определенные осуществления, такие как на фиг.4 (а также примерное системное окружение на (фиг.7)), и на примерные ИПП, эти подходы могут быть осуществлены в любом подходящем аппаратном обеспечении, программном обеспечении, программно-аппаратных средствах или их комбинации, и используя любой(ые) подходящий(ие) язык(и) программирования, механизм(ы) кодирования, систему(ы) понятий протокола, установки графики и т.д.
Примерное осуществление обобщенного ИПП
На фиг.6 представлена схема 600 последовательности операций, которая иллюстрирует примерный способ обеспечения взаимодействия между визуализатором 410 видеоданных и драйвером 422 графического устройства. Хотя описанное осуществление, как отражено на фиг.6, ориентировано на операцию регулировки ФУ, оно этим не ограничивается. Вместо этого, по меньшей мере некоторые аспекты этого примерного осуществления обобщенного ИПП могут быть использованы с одной или несколькими другими операциями обработки видеоданных (или обобщенного изображения).
На схеме 600 последовательности операций визуализатор 410 видеоданных ассоциирован с девятью (9) блоками 602-618, и драйвер 422 графического устройства ассоциирован с шестью (6) блоками 620-630. Каждый из блоков 602-618 и 620-630 соответствует по меньшей мере одному действию, которое выполняется визуализатором 410 видеоданных или от его имени и драйвером 422 графического устройства или от его имени, соответственно.
Схема 600 последовательности операций описывается ниже в контексте примерных обобщенных ИПП. Эти обобщенные ИПП, как описано здесь, могут быть разделены на две функциональные группы способов, логики устройств и т.д. Первая группа может быть использована для определения возможностей обработки видеоданных графического устройства. Вторая группа может быть использована для создания и использования объектов потоковых операций обработки видеоданных.
Эти примерные обобщенные ИПП могут соответствовать ИПП 416 (на фиг.4), которые изображены как часть интерфейса 414 драйверов устройств, который поддерживает графический интерфейс 412 и обеспечивает сопряжение с драйвером 422 графического устройства. ИПП 416 изображены, таким образом, как часть интерфейса 414 драйверов устройств, которая находится в части 418 пользовательского режима. Однако такие ИПП 416, альтернативно, могут быть расположены в другой логике, кроме интерфейса 414 драйверов устройств, и функционировать с ней. Такие другие логики включают в себя, только в качестве примера, визуализатор 410 видеоданных, графический интерфейс 412, некоторую долю части 420 режима ядра и т.д.
Обобщенные ИПП, описанные ниже в этом разделе, могут быть использованы для расширения, улучшения и т.д., например, ускорения видеоданных (УВ) Microsoft® DirectX®, чтобы поддерживать любое число операций обработки видеоданных (например, регулировки ФУ, преобразования частоты кадров и т.д.) для видеосодержимого, отображаемого совместно с драйвером графического устройства. Дополнительную относящуюся информацию можно найти в "Microsoft® Windows® Platform Design Note", озаглавленной "DirectX® VA: Video Acceleration API/DDI", датированной 23 января 2001 г. "DirectX® VA: Video Acceleration API/DDI", которая включена здесь в качестве ссылки во всей своей полноте.
Хотя действия схемы 600 последовательности операций описаны здесь в понятиях ИПП, которые конкретно применимы к современному развитию операционных систем Microsoft® Windows® для персональных компьютеров, необходимо понять, что эти блоки, а также другие осуществления, описанные здесь, также применимы к другим операционным системам и/или другим электронным устройствам.
В нижеследующих примерах выход операции (операций) обработки видеоданных представлен в формате RGB цели визуализации, такой как целевая поверхность DirectDraw®. Такое выполнение исключает необходимость обычных аппаратных методов наложения. Кроме того, весь экран, наблюдаемый на устройстве отображения, включая любые видеоизображения, существует и, более того, присутствует в одной ячейки памяти, так что оно может быть зафиксировано командой распечатки экрана. Эта фиксация распечатки экрана затем может быть вставлена в документ, добавлена в файл, непосредственно распечатана и т.д.
На схеме 600 последовательности операций визуализатор 410 видеоданных уже может был проинформирован драйвером 422 графического устройства, что соответствующее графическое аппаратное обеспечение способно выполнить операции обработки видеоданных по регулировке ФУ, или визуализатор 410 видеоданных может определить существование возможностей ФУ или их отсутствие следующим образом. В блоке 602 визуализатор 410 видеоданных обеспечивает описание видеоданных, подлежащего отображению, и запрашивает возможности обработки графики в отношении свойств управления ФУ.
Визуализатор 410 видеоданных выполняет создание описания видеоданных и/или запрос свойств управления на драйвер 422 графического устройства посредством одной или нескольких передач, как указано стрелкой передачи между блоком 602 и блоком 620. Описание видеоданных позволяет драйверу 422 графического устройства адаптировать доступные, возможные и т.д. возможности обработки видеоданных, основанные на типе видеоданных. Например, заранее определенное множество возможностей может быть установлено для каждого из различных типов видеоданных.
В блоке 620 драйвер 422 графического устройства представляет визуализатору 410 видеоданных список доступных свойств управления ФУ. Этот список может включать в себя ни одного или один или несколько из следующих параметров: яркости, контраста, оттенка и насыщенности. В блоке 604 визуализатор 410 видеоданных принимает доступные свойства управления ФУ от драйвера 422 графического устройства. Действия блоков 620 и 622 могут быть выполнены в ответ на связь с блоком 602. Альтернативно, визуализатор 410 видеоданных может выполнить отдельный запрос на извлечение действий из блока 622.
В блоке 622 драйвер 422 графического устройства предоставляет визуализатору 410 видеоданных те операции обработки видеоданных, которые, возможно, могут быть выполнены одновременно/параллельно с операциями регулировки ФУ. Такие операции обработки видеоданных могут включать в себя ни одной или одну или несколько из следующих операций: YUV2RGB, StretchX, StretchY, SubRects и AlphaBlend. Другие такие операции обработки видеоданных могут включать в себя устранение чересстрочности, преобразование частоты кадров и т.д. В блоке 606 визуализатор 410 видеоданных принимает возможные одновременные операции обработки видеоданных от драйвера 422 графического устройства.
Примерный обобщенный ИПП для выполнения по меньшей мере части действий блоков 602, 604, 606, 620 и 622 представлен следующим образом:
ProcAmpControlQueryCaps
Этот ИПП позволяет визуализатору 410 видеоданных запрашивать драйвер 422 графического устройства для определения информации, относящейся к требованиям ко входу устройства управления ФУ, и любых дополнительных операций обработки видеоданных, которые могли бы поддерживаться во время выполнения операций регулировки ФУ.
HRESULT
ProcAmpControlQueryCaps(
[in] DXVA_VideoDesc* lpVideoDescription,
[out] DXVA_ProcAmpControlCaps* lpProcAmpCaps
);
Драйвер 422 графического устройства сообщает свои возможности для этого режима в выходной структуре DXVA_ProcAmpControlCaps для lpProcAmpCaps.
typedef struct_DXVA_ProcAmpControlCaps {
DWORD Size;
DWORD InputPool;
D3DFORMAT OutputFrameFormat;
DWORD ProcAmpControlProps;
DWORD VideoProcessingCaps;
} DXVA_ProcAmpControlCaps;
Поле Size указывает размер структуры данных и может быть использовано, в том числе, как индикатор версии, если различные версии имеют различные размеры структуры данных.
Поле InputPool указывает пул памяти, из которого должны быть выделены поверхности источника видеоданных. Например, пул памяти может быть расположен в локальной видеопамяти на графической плате, в специально помеченной системной памяти (например, памяти ускоренного графического порта (УГП)), в общей системной памяти и т.д. Документации по D3D и DirectDraw также предоставляют описание действительных ячеек пула памяти.
Поле OutputFrameFormat указывает формат поверхности Direct3D в выходных кадрах. Устройство ФУ может выводить кадры в формате поверхности, который согласуется с входным форматом поверхности. Это поле обеспечивает то, что визуализатор 410 видеоданных сможет подавать правильный формат для поверхностей выходных кадров на аппаратное обеспечение управления ФУ. Заметьте, что, если флаг DXVA_VideoProcess_YUV2RGB (см. ниже) возвращается в поле VideoProcessingCaps, визуализатор 410 видеоданных может предположить, что в этом поле определены действительные выходные форматы, а также формат RGB, такой как RGB32. RGB32 представляет собой формат RGB с 8 битами точности для каждого красного, зеленого и синего канала и с 8 битами неиспользуемых данных.
Поле ProcAmpControlProp идентифицирует операции ФУ, которые аппаратное обеспечение может выполнить. Драйвер 422 графического устройства возвращает логическую часть комбинации операций ФУ, которые он поддерживает:
- DXVA_ProcAmp_None. Аппаратное обеспечение не поддерживает никакую операцию управления ФУ.
- DXVA_ProcAmp_Brightness. Аппаратное обеспечение управления ФУ может выполнить регулировки яркости в видеоизображении.
- DXVA_ProcAmp_Contrast. Аппаратное обеспечение управления ФУ может выполнить регулировки контраста в видеоизображении.
- DXVA_ProcAmp_Hue. Аппаратное обеспечение управления ФУ может выполнить регулировки оттенка в видеоизображении.
- DXVA_ProcAmp_Saturation. Аппаратное обеспечение управления ФУ может выполнить регулировки насыщенности в видеоизображении.
Поле VideoProcessingCaps идентифицирует другие операции, которые могут быть выполнены одновременно с запрашиваемой регулировкой ФУ. Следующие флаги идентифицируют возможные операции:
- DXVA_VideoProcess_YUV2RGB. Аппаратное обеспечение управления ФУ может преобразовать видеоданные из цветового пространства YUV в цветовое пространство RGB. Используемый формат RGB может иметь 8 битов или более точности для каждой цветовой составляющей. Если это возможно, может быть исключена копия буфера в визуализаторе 410 видеоданных. Заметим, что нет необходимости в этом флаге при преобразовании из цветового пространства RGB в цветовое пространство YUV.
- DXVA_VideoProcess_StretchX. Если аппаратное обеспечение управления ФУ может растягивать или сжимать по горизонтали, то коррекция формата изображения может быть выполнена одновременно с регулировкой ФУ видео.
- DXVA_VideoProcess_StretchY. Иногда регулировка формата изображения объединяется с общей операцией изменения размеров изображения для масштабирования видеоизображения в пределах определяемого приложением пространства формирования. Это в некоторой степени редкая особенность. Выполнение масштабирования для изменения размеров видео, чтобы оно умещалось в окне приложения, может быть выполнено одновременно с масштабированием для регулировки ФУ. Выполнение вместе этих масштабирований исключает накопляемые артефакты.
- DXVA_VideoProcess_SubRects. Этот флаг указывает, что аппаратное обеспечение может работать на прямоугольном (вспомогательном) регионе изображения, а также на всем изображении. Прямоугольный регион может быть определен прямоугольником источника в структуре данных DXVA_ProcAmpControlBlt.
- DXVA_VideoProcess_AlphaBlend. Альфа-смешение может управлять тем, как отображается другая графическая информация, например, установкой уровней прозрачности и/или непрозрачности. Таким образом, альфа-величина может указывать прозрачность цвета или степень, с которой цвет смешивается с любым фоновым цветом. Такие альфа-величины могут находиться в диапазоне от полностью прозрачного цвета до полностью непрозрачного цвета.
При работе альфа-смешение может быть выполнено с использованием смешения "пиксел за пикселом" данных исходного и фонового цвета. Каждая из трех цветовых составляющих (красная, зеленая и синяя) данного исходного цвета может быть смешена с соответствующей составляющей фонового цвета для выполнения операции альфа-смешения. В примерном осуществлении цвет может быть представлен, в большинстве случаев, 32-битовой величиной, при этом 8 бит выделены для каждого альфа-, красного, зеленого и синего канала.
Также, использование этого признака может исключить копию буфера у визуализатора 410 видеоданных. Однако это тоже редко используемый признак, так как приложения редко изменяют постоянную альфа-величину, связанную с их потоком видеоданных.
В блоке 608 схемы 600 последовательности операций визуализатор 410 видеоданных выбирает свойство управления ФУ из тех, которые принимаются в блоке 604. В блоке 610 визуализатор 410 видеоданных запрашивает одну или несколько величин из выбранного свойства управления ФУ у драйвера 422 графического устройства. В блоке 624 драйвер 422 графического устройства посылает на визуализатор 410 видеоданных величины для запрашиваемого свойства управления ФУ. Такие величины могут относиться к одной или нескольким из следующих величин: величины по умолчанию, величины приращения, минимальной величины, максимальной величины и т.д.
В блоке 612 визуализатор 410 видеоданных принимает от драйвера 422 графического устройства и, таким образом, информируется об одной или нескольких величинах для выбранного свойства управления ФУ. Как указано стрелкой направления от блока 612 к блоку 608, действия блоков 608, 610, 612 и 624 могут быть повторены для более чем одного, включая все из доступных свойств управления ФУ. Альтернативно, визуализатор 410 видеоданных может запросить драйвер 422 графического устройства о более чем одном, включая все из доступных свойств управления ФУ в одном обмене данными, имеющим две или несколько передач.
Примерный обобщенный ИПП для выполнения по меньшей мере части действий блоков 608, 610, 612 и 624 представлен в следующем виде:
ProcAmpControlQueryRange
Для каждого свойства ФУ (яркость, контраст, насыщенность, оттенок и т.д.) визуализатор 410 видеоданных запрашивает драйвер 422 графического устройства для определения минимума, максимума, размера шага (приращения), величины по умолчанию и т.д. Если аппаратное обеспечение не поддерживает конкретное свойство управления ФУ, драйвер 422 графического устройства может возвратить "E_NOTIMPL" в ответ на функцию ProcAmpControlQueryRange.
Хотя драйвер 422 графического устройства может возвратить любые величины, какие он пожелает, для различных свойств управления ФУ, следующие величины установок предусмотрены в качестве примера (все табличные величины плавающие):
Если величины по умолчанию приводят к нулевому преобразованию потока видеоданных, визуализатору 410 видеоданных разрешается обойти стадию регулировки ФУ в этом конвейере видеоданных, если вызывающее приложение не изменяет никакое из свойств управления ФУ.
HRESULT
ProcAmpControlQueryRange(
[in] DWORD VideoProperty,
[in] DXVA_VideoDesc* lpVideoDescription,
[out] DXVA_VideoPropertyRange* lpPropRange
);
VideoProperty идентифицирует свойство (или свойства) управления ФУ, о которых драйвер 422 графического устройства был запрошен на возвращение информации. В описанном осуществлении возможными величинами параметров для этого поля являются:
- DXVA_ProcAmp_Brightness;
- DXVA_ProcAmp_Contrast;
- DXVA_ProcAmp_Hue; и
- DXVA_ProcAmp_Saturation.
lpVideoDescription предоставляет драйверу 422 графического устройства описание видеоданных, к которому собирается быть применена регулировка ФУ. Драйвер 422 графического устройства может корректировать свою поддержку признака ФУ для конкретных типов описания потока видеоданных.
lpPropRange идентифицирует диапазон (минимум и максимум), размер шага и величину по умолчанию для свойства управления ФУ, которое определено параметром/полем VideoProperty.
typedef struct_DXVA_VideoPropertyRange {
FLOAT MinValue;
FLOAT MaxValue;
FLOAT DefaultValue;
FLOAT StepSize;
} DXVA_VideoPropertyRange, *LPDXVA_VideoPropertyRange.
В блоке 614 схемы 600 последовательности операций визуализатор 410 видеоданных посылает команду на открытие потокового объекта ФУ на драйвер 422 графического устройства. В ответ на это драйвер 422 графического устройства открывает потоковый объект ФУ в блоке 626. В блоке 616 визуализатор 410 видеоданных инструктирует драйвер 422 графического устройства выполнить операцию регулировки ФУ. В ответ на это драйвер 422 графического устройства выполняет запрашиваемую операцию регулировки ФУ в блоке 628.
Как указано изогнутой стрелкой направления в блоке 616, визуализатор 410 видеоданных может продолжать, насколько это необходимо, посылать инструкции на выполнение операции регулировки ФУ на драйвер 422 графического устройства (например, всякий раз, когда это требует вызывающее приложение, отображающее поток видеоданных). В блоке 618 визуализатор 410 видеоданных инструктирует драйвер 422 графического устройства закрыть потоковый объект ФУ. Драйвер 422 графического устройства затем закрывает потоковый объект ФУ в блоке 630.
Примерный обобщенный ИПП для выполнения по меньшей мере части действий блоков 614, 616, 618, 626, 628 и 630 представлен следующим:
Объект ProcAmpStream
После того как визуализатор 410 видеоданных определил возможности аппаратного обеспечения управления ФУ, может быть создан объект ProcAmpStream. Создание объекта ProcAmpStream позволяет драйверу 422 графического устройства зарезервировать любые аппаратные ресурсы, которые необходимы для выполнения запрашиваемой(ых) операции(й) регулировки ФУ.
ProcAmpOpenStream
Метод ProcAmpOpenStream создает объект ProcAmpStream.
HRESULT
ProcAmpOpenStream(
[in] LPDXVA_VideoDesc lpVideoDescription,
[out] HDXVA_ProcAmpStream* lphCcStrm
);
Выходной параметр HDXVA_ProcAmpStream является описателем для объекта ProcAmpStream и используется для идентификации этого потока при будущих вызовах, которые ориентируются на него.
ProcAmpBlt
Метод ProcAmpBlt выполняет операцию регулировки ФУ посредством записи выхода на поверхность приемника во время операции передачи битовых блоков.
HRESULT
ProcAmpBlt(
[in] HDXVA_ProcAmpStream hCcStrm
[in] LPDDSURFACE lpDDSDstSurface,
[in] LPDDSURFACE lpDDSSrcSurface,
[in] DXVA_ProcAmpBlt* ccBlt
);
Прямоугольники источника и приемника используются либо для регулировки ФУ вспомогательного прямоугольника, либо растягивания. Поддержка для растягивания дополнительна (и сообщается флагами Caps). Аналогично, поддержка для вспомогательных прямоугольников не является обязательной.
Поверхностью приемника может быть внеэкранная плоскость, цель визуализации D3D, текстура D3D, которая также является целью визуализации, и т.д. Поверхность приемника может быть выделена, например, в локальной видеопамяти. Форматом пикселей поверхности приемника является формат, указанный в структуре DXVA_ProcAmpCaps, если только не выполняется преобразование цветового пространства из YUV в RGB вместе с операцией регулировки ФУ. В этих случаях форматом поверхности приемника является формат RGB с 8 битами или более точности для каждой цветовой составляющей.
ProcAmpCloseStream
Метод ProcAmpCloseStream закрывает объект ProcAmpStream и инструктирует драйвер 422 графического устройства освободить любой аппаратный ресурс, связанный с идентифицированным потоком.
HRESULT
ProcAmpCloseStream(
HDXVA_ProcAmpStream hCcStrm
);
Примерное конкретное осуществление ИПП
Конкретная ситуация и примерные ИПП, описанные ниже в этом разделе, специально применимы для подмножества существующих операционных систем Microsoft® Windows® для персональных компьютеров. Однако необходимо понять, тем не менее, что принципы, а также некоторые аспекты псевдокода, которые представлены ниже, могут быть использованы (как есть или с модификациями подпрограмм) совместно с другими операционными системами и/или в других средах.
Отображение ИДУ для интерфейса ФУ
Для совместимости с инфраструктурой ИДУ для подмножества существующих операционных систем Microsoft® Windows®, ИПП, описанный выше в предыдущем разделе, может быть "отображен" на существующий ИДУ для DirectDraw и УВ DirectX. В этом разделе описывается отображение интерфейса ФУ на существующий ИДУ DirectDraw и УВ DX.
ИДУ УВ DX сам разделен на две функциональные группы: "контейнер УВ DX" и "устройство УВ DX". Назначение группы ИДУ контейнера УВ DX заключается в определении числа и возможностей различных устройств УВ DX, содержащихся в аппаратном обеспечении устройства отображения. Поэтому драйвер УВ DX может иметь только один контейнер, но он может поддерживать множество устройств УВ DX.
Недопустимо отображать вызов ProcAmpQueryCaps на любую точку входа ИДУ в группе контейнера УВ DX, так как, в отличие от остальных УВ DX, контейнерные методы используют типовые параметры. Однако группа ИДУ устройства УВ DX не использует типовые параметры, поэтому допустимо отображать интерфейс управления ФУ на методы в группе устройств. В этом разделе описывается конкретный пример того, как интерфейс ФУ может быть отображен на ИДУ устройства УВ DX.
Устройство контейнера устранения чересстрочности
Методы устройства УВ DX не используют типовые параметры, так что эти методы могут быть повторно использованы для многих других назначений. Однако методы устройства УВ DX могут быть использованы только в контексте устройства УВ DX, поэтому первой задачей является определение и создание специального "контейнерного устройства".
Непредварительная патентная заявка США № 10/273505 на "Способы и устройства для обеспечения обработки чересстрочных видеоизображений для устройств отображения видеоданных с построчной разверткой", которая включена здесь посредством ссылки выше, включает в себя описание контейнерного устройства устранения чересстрочности. Это описанное в заявке контейнерное устройство устранения чересстрочности повторно используется здесь для функции ProcAmpQueryCaps.
Контейнерное устройство устранения чересстрочности УВ DX представляет собой только программную конструкцию, так что оно не представляет никакого функционального аппаратного обеспечения, содержащегося в физическом устройстве. Пример псевдокода драйвера (устройства) управления ФУ, представленный ниже, указывает, как контейнерное устройство может быть реализовано драйвером.
Вызов ИДУ из компоненты пользовательского режима
Примерная последовательность из восьми (8) задач для использования ИДУ из компоненты пользовательского режима, такой как визуализатор (видео), состоит в следующем:
1. Вызов GetMoCompGuids для получения списка устройств УВ DX, поддерживаемых драйвером.
2. Если "контейнерное устройство устранения чересстрочности" GUID присутствует, вызов CreateMoComp для создания экземпляра этого устройства УВ DX. Контейнерное устройство GUID определено следующим образом:
DEFINE_GUID(DXVA_DeinterlaceContainerDevice, 0x0e85cb93,0x3046,0x4ff0,0xae,0xcc,0xd5,0x8c,0xb5,0xf0,0x35,0xfc);
3. Вызов RenderMocomp с параметром dwFunction, который идентифицирует операцию ProcAmpControlQueryModeCaps. Также параметр lpInputData используется для передачи входных параметров на драйвер, который возвращает свой выход через параметр lpOutputData.
4. Для каждого свойства регулировки ФУ, поддерживаемого аппаратным обеспечением, визуализатор вызывает RenderMocomp с параметром dwFunction, который идентифицирует операцию ProcAmpControlQueryRange. Параметр lpInputData используется для передачи входных параметров на драйвер, который возвращает свой выход через параметр lpOutputData.
5. После того как визуализатор определил возможности регулировки ФУ аппаратного обеспечения, он вызывает CreateMocomp для создании экземпляра устройства управления ФУ. Устройство GUID управления ФУ определяется следующим образом:
DEFINE_GUID(DXVA_ProcAmpControlDevice, 0x9f200913,0x2ffd,0x4056,0x9f,0x1e,0xe1,0xb5,0x08,0xf2,0x2d,0xcf);
6. Визуализатор затем вызывает RenderMocomp устройства управления ФУ с параметром функции DXVA_ProcAmpControlBltFnCode для каждой операции регулировки ФУ.
7. Когда визуализатору больше не нужно уже выполнять операции ФУ, он вызывает DestroyMocomp.
8. Драйвер освобождает любые ресурсы, используемые устройством управления ФУ.
ProcAmpControlQueryCaps
Этот метод отображает непосредственно на вызов метода RenderMoComp контейнерного устройства устранения чересстрочности. Структура DD_RENDERMOCOMPDATA завершается следующим образом:
- dwNumBuffers равно нулю.
- lpBufferInfo равно NULL.
- dwFunction определяется как
DXVA_ProcAmpControlQueryCapsFnCode.
- lpInputData указывает на структуру DXVA_VideoDesc.
- lpOutputData указывает на структуру DXVA_ProcAmpCaps.
Заметьте, что метод RenderMoComp контейнерного устройства УВ DX может быть вызван без вызова сначала BeginMoCompFrame или EndMoCompFrame.
ProcAmpControlQueryRange
Этот метод непосредственно отображается на вызов метода RenderMoComp контейнерного устройства устранения чересстрочности. Структура DD_RENDERMOCOMPDATA завершается следующим образом:
- dwNumBuffers равно нулю.
- lpBufferInfo равно NULL.
- dwFunction определяется как DXVA_ProcAmpControlQueryRangeFnCode.
- lpInputData указывает на структуру DXVA_ProcAmpControlQueryRange.
typedef struct_DXVA_ProcAmpQueryRange{
DWORD Size;
DWORD VideoProperty;
DXVA_VideoDesc VideoDesc;
} DXVA_ProcAmpControlQueryRange,
*LPDXVA_ProcAmpControlQueryRange;
- lpOutputData указывают на структуру DXVA_VideoPropertyRange.
Заметьте, что метод RenderMoComp контейнерного устройства УВ DX может быть вызван без вызова сначала BeginMoCompFrame или EndMoCompFrame.
ProcAmpControlOpenStream
Этот метод отображает непосредственно на метод CreateMoComp структуры DD_MOTIONCOMPCALLBACKS, когда GUID является устройством ФУ GUID, pUncompData указывает на структуру, которая не содержит данных (все нули), и pData указывает на структуру DXVA_VideoDesc.
Если драйвер поддерживает ускоренное декодирование сжатых видеоданных, то визуализатор может вызвать драйвер для создания двух устройств УВ DX - одно для выполнения фактической работы декодирования видеоданных, как определено техническими требованиями на декодирование видеоданных УВ DirectX, а другое для использования строго для регулировок ФУ.
**Пример: Отображение CreateMoComp на ProcAmpControlOpenStream**
Примерный псевдокод ниже показывает, как драйвер может отображать вызов ИДУ CreateMoComp на вызовы ProcAmpControlOpenStream. Псевдокод показывает, как функция CreateMocComp используется для ФУ. Если драйвер поддерживает другие функции УВ DX, такие как декодирование потоков видеоданных стандарта MPEG-2, пример кода ниже может быть расширен и включать в себя обработку дополнительных GUID УВ DX.
DWORD APIENTRY
CreateMoComp(
LPDDHAL_CREATEMOCOMPDATA lpData
)
{
//Убедитесь, что это тот guid, который желателен.
if(!ValidDXVAGuid(lpData->lpGuid)) {
DbgLog((LOG_ERROR, 1,
TEXT("Нет форматов, поддерживаемых для этого GUID")));
lpData->ddRVal=E_INVALIDARG;
return DDHAL_DRIVER_HANDLED;
}
//Поиск контейнерного устройства GUID устранения чересстрочности
if(*lpData->lpGuid==DXVA_DeinterlaceContainerDevice){
DXVA_DeinterlaceContainerDeviceClass* lpDev=
new DXVA_DeinterlaceContainerDeviceClass(
*lpData->lpGuid,
DXVA_DeviceContainer);
if(lpDev){
lpData->ddRVal=DD_OK;
}
else {
lpData->ddRVal=E_OUTOFMEMORY;
}
lpData->lpMoComp->lpDriverReserved1=
(LPVOID)(DXVA_DeviceBaseClass*)lpDev;
return DDHAL_DRIVER_HANDLED;
}
//Поиск устройства GUID управления ФУ
if(*lpData->lpGuid==DXVA_ProcAmpControlDevice) {
DXVA_ProcAmpControlDeviceClass* lpDev=
new DXVA_ProcAmpControlDeviceClass(
*lpData->lpGuid,
DXVA_DeviceProcAmpControl);
if(lpDev) {
LPDXVA_VideoDesc lpVideoDescription=
(LPDXVA_VideoDesc)lpData->lpData;
lpData->ddRVal=
lpDev->ProcAmpControlOpenStream(
lpVideoDescription);
if(lpData->ddRVal!=DD_OK) {
delete lpDev;
lpDev=NULL;
}
}
else {
lpData->ddRVal=E_OUTOFMEMORY;
}
lpData->lpMoComp->lpDriverReserved1=
(LPVOID)(DXVA_DeviceBaseClass*)lpDev;
return DDHAL_DRIVER_HANDLED;
}
lpData->ddRVal=DDERR_CURRENTLYNOTAVAIL;
return DDHAL_DRIVER_HANDLED;
}
**Пример: Осуществление GetMoCompGuids**
В дополнение к функции ИДУ CreateMoComp драйвер также может быть способен осуществить метод GetMoCompGuids структуры DD_MOTIONCOMPCALLBACKS. Следующий пример псевдокода показывает один способ осуществления этой функции в драйвере.
//Это список GUID устройства УВ DV, поддерживаемых
//драйвером - этот список включает в себя декодер,
//ФУ и контейнерное устройство устранения чересстрочности.
//Не важен порядок GUID в списке.
DWORD g_dwDXVANumSupportedGUIDs=2;
const GUID* g_DXVASupportedGUIDs[2]={
&DXVA_DeinterlaceContainerDevice,
&DXVA_ProcAmpControlDevice
};
DWORD APIENTRY
GetMoCompGuids(
PDD_GETMOCOMPGUIDSDATA lpData
)
{
DWORD dwNumToCopy;
//Проверка, это запрос GUID или запрос на счет
if(lpData->lpGuids) {
dwNumToCopy=
min(g_dwDXVANumSupportedGUIDs,
lpData->dwNumGuids);
for (DWORD i=0; i<dwNumToCopy; i++) {
lpData->lpGuids[i]=
*g_DXVASupportedGUIDs[i];
}
}
else {
dwNumToCopy=g_dwDXVANumSupportedGUIDs;
}
lpData->dwNumGuids=dwNumToCopy;
lpData->ddRVal=DD_OK;
return DDHAL_DRIVER_HANDLED;
}
ProcAmpControlBlt
Этот метод отображает непосредственно в метод RenderMoComp структуры DD_MOTIONCOMPCALLBACKS, где
- dwNumBuffers равно двум.
- lpBufferInfo указывает на массив двух поверхностей. Первый элемент массива представляет собой поверхность приемника; второй элемент массива - поверхность источника.
- dwFunction определяется как DXVA_ProcAmpControlBltFnCode.
- lpInputData указывает на следующую структуру:
typedef struct_DXVA_ProcAmpControlBlt {
DWORD Size;
RECT DstRect;
RECT SrcRect;
FLOAT Alpha;
FLOAT Brightness;
FLOAT Contrast;
FLOAT Hue;
FLOAT Saturation;
} DXVA_ProcAmpControlBlt;
- lpOutputData равен NULL.
Заметьте, что устройство УВ DX, используемое для ФУ, RenderMoComp может быть вызвано без вызова BeginMoCompFrame или EndMoCompFrame.
**Пример: Отображение RenderMoComp на ProcAmpControlBlt**
Примерный псевдокод ниже показывает, как драйвер может отобразить вызов ИДУ RenderMoComp на вызовы ProcAmpBlt. Пример кода показывает, как функция RenderMoComp используется для регулировки ProcAmp. Если драйвер поддерживает другие функции УВ DX, такие как декодирование потоков видео MPEG-2, пример кода ниже может быть расширен и включать в себя обработку дополнительных GUID УВ DX.
DWORD APIENTRY
RenderMoComp(
LPDDHAL_RENDERMOCOMPDATA lpData
)
{
if(lpData->dwFunction==DXVA_ProcAmpControlBltFnCode)
{
DXVA_ProcAmpControlDeviceClass* pDXVADev=
(DXVA_ProcAmpControlDeviceClass*)pDXVABase;
DXVA_ProcAmpControlBlt* lpBlt=
(DXVA_ProcAmpControlBlt*)lpData->lpInputData;
LPDDMCBUFFERINFO lpBuffInfo=lpData->lpBufferInfo;
lpData->ddRVal=pDXVADev->ProcAmpControlBlt(
lpBuffInfo[0].lpCompSurface,
lpBuffInfo[1].lpCompSurface,
lpBlt);
return DDHAL_DRIVER_HANDLED;
}
lpData->ddRVal=E_INVALIDARG;
return DDHAL_DRIVER_HANDLED;
}
ProcAmpControlCloseStream
Этот метод отображает непосредственно на метод DestroyMoComp структуры DD_MOTIONCOMPCALLBACKS.
**Пример: Отображение DestroyMoComp на ProcAmpControlCloseStream**
Следующий примерный псевдокод показывает, как драйвер может отобразить вызов ИДУ DestroyMoComp на вызовы ProcAmpControlCloseStream. Пример кода показывает, как функция DestroyMoComp используется для управления ФУ. Если драйвер поддерживает другие функции УВ DX, такие как декодирование потоков видеоданных стандарта MPEG-2, пример кода ниже может быть расширен и включать в себя обработку дополнительных GUID УВ DX.
DWORD APIENTRY
DestroyMoComp(
LPDDHAL_DESTROYMOCOMPDATA lpData
)
{
DXVA_DeviceBaseClass* pDXVABase=
(DXVA_DeviceBaseClass*)
lpData->lpMoComp->lpDriverReserved1;
if(pDXVABase==NULL){
lpData->ddRVal=E_POINTER;
return DDHAL_DRIVER_HANDLED;
}
switch (pDXVABase->m_DeviceType){
case DXVA_DeviceContainer:
lpData->ddRVal=S-OK;
delete pDXVABase;
break;
case DXVA_DeviceProcAmpControl:
{
DXVA_ProcAmpControlDeviceClass* pDXVADev=
(DXVA_ProcAmpControlDeviceClass*)pDXVABase;
lpData->ddRVal=pDXVADev->ProcAmpControlCloseStream();
delete pDXVADev;
}
break;
}
return DDHAL_DRIVER_HANDLED;
}
Примерная операционная среда для компьютера или другого электронного прибора
На фиг.7 изображена примерная вычислительная операционная среда 700 (или операционная среда общего электронного устройства), которая способна (полностью или частично) осуществлять по меньшей мере одно: систему, устройство, компоненту, средство, протокол, принцип, способ, процесс, некоторую их комбинацию и т.д. для обеспечения взаимодействия между визуализаторами видеоданных и драйверами графических устройств, как описано здесь. Вычислительная среда 700 может быть использована в вычислительных и сетевых архитектурах, описанных ниже, или в автономном варианте.
Примерная операционная среда 700 электронного устройства представляет собой только один пример среды и не предназначена для какого-либо ограничения объема использования или функциональных возможностей применяемых электронных архитектур (включая компьютер, игровую консоль, телевизор и т.д.). Среду 700 электронного устройства также не следует интерпретировать как имеющую какую-нибудь зависимость или потребность, относящуюся к любой компоненте или любой комбинации компонент, как изображено на фиг.7.
Кроме того, обеспечение взаимодействия между визуализаторами видеоданных и драйверами графических устройств может быть осуществлено при помощи других многочисленных сред или конфигураций электронного устройства (включая в себя вычислительную систему) общего назначения или специального назначения. Примеры общеизвестных электронных систем, сред и/или конфигураций (электронного прибора), которые могут быть пригодны для использования, включают в себя, но не ограничиваются ими, персональные компьютеры, компьютеры-серверы, "тонкие" клиенты, "толстые" клиенты, персональные цифровые помощники или мобильные телефоны, ручные или портативные устройства, мультипроцессорные системы, микропроцессорные системы, телевизионные приставки, программируемую бытовую электронику, игровые видеомашины, игровые консоли, портативные или ручные игровые блоки, сетевые персональные компьютеры, миникомпьютеры, мейнфреймы, распределенные вычислительные среды, которые включают в себя любую из вышеуказанных систем или устройств, некоторые их комбинации и т.д.
Реализация для обеспечения взаимодействия между визуализаторами видеоданных и драйверами графических устройств могут быть описаны в общем контексте инструкций с электронным исполнением. В общих чертах, инструкции с электронным исполнением включают в себя подпрограммы, программы, объекты, компоненты, структуры данных и т.д., которые выполняют определенные задачи или реализуют конкретные абстрактные типы данных. Обеспечение взаимодействия между визуализаторами видеоданных и драйверами графических устройств, как описано в некоторых вариантах осуществлениях, также может быть выполнено в распределенных вычислительных средах, где задачи выполняются удаленно-связанными устройствами обработки, соединенными через канал связи и/или сеть. Особенно в распределенной вычислительной среде инструкции с электронным исполнением могут быть расположены на отдельных носителях данных, могут исполняться различными процессорами и/или могут распространяться по средам передачи.
Среда 700 электронного устройства включает в себя вычислительное устройство общего назначения в виде компьютера 702, который может содержать любое электронное устройство с вычислительными и/или обрабатывающими возможностями. Компоненты компьютера 702 могут включать в себя, но не ограничиваться ими, один или несколько процессоров или обрабатывающих блоков 704, системную память 706 и системную шину 708, которая соединяет различные системные компоненты, включая процессор 704 с системной памятью 706.
Системная шина 708 представляет собой проводные или беспроводные конструкции шин, включая шину памяти или контроллер памяти, периферийную шину, ускоренный графический порт и процессорную или локальную шину, одного или более из любых нескольких типов, используя любую из многочисленных архитектур шины. В качестве примера, такие архитектуры могут включать в себя шину архитектуры, соответствующей промышленному стандарту, шину микроканальной архитектуры, шину расширенной стандартной архитектуры для промышленного применения, локальную шину Ассоциации по стандартам в области видеоэлектроники, шину межсоединений периферийных компонентов, также известную как дополнительная шина, некоторые их комбинации и т.д.
Компьютер 702 в типовом случае включает в себя множество носителей с электронным доступом. Такими носителями могут быть любые доступные носители, которые доступны для компьютера 702 или другого электронного устройства, и они включают в себя как энергозависимые, так и энергонезависимые носители, съемные и несъемные носители и носители данных и среду передачи.
Системная память 706 включает в себя носители данных с электронным доступом в виде энергозависимой памяти, такой как оперативное запоминающее устройство (ОЗУ) 710, и/или энергонезависимой памяти, такой как постоянное запоминающее устройство (ПЗУ) 712. Базовая система ввода-вывода (БИОС) 714, содержащая базовые подпрограммы, которые способствуют передаче информации между элементами внутри компьютера 702, например, во время запуска, обычно хранится в ПЗУ 712. ОЗУ 710 обычно содержит данные и/или программные модули/инструкции, которые немедленно доступны для обрабатывающего блока 704 и/или с которыми он работает в данный момент.
Компьютер 702 также может включать в себя другие съемные/несъемные и/или энергозависимые/энергонезависимые носители данных. В качестве примера, на фиг.7 изображен накопитель жесткого диска или массив 716 накопителей дисков для считывания и записи на, в типовом случае, несъемный, энергонезависимый магнитный носитель (не показан отдельно); накопитель 718 магнитного диска для считывания и записи на, в типовом случае, съемный, энергонезависимый магнитный диск 720 (например, дискету); и накопитель 722 оптического диска для считывания и/или записи на, в типовом случае, съемный, энергонезависимый оптический диск 724, такой как компакт-диск, цифровой многофункциональный диск или другой оптический носитель. Накопитель 716 жесткого диска, накопитель 718 магнитного диска и накопитель 722 оптического диска каждый подключен к системной шине 708 посредством одного или нескольких интерфейсов 726 носителей данных. Альтернативно, накопитель 716 жесткого диска, накопитель 718 магнитного диска и накопитель 722 оптического диска могут быть подключены к системной шине 708 посредством одного или нескольких других отдельных или комбинированных интерфейсов (не показаны).
Накопители дисков и связанные с ними носители с электронным доступом обеспечивают энергонезависимое хранение инструкций с электронным исполнением, таких как структуры данных, программные модули и другие данные для компьютера 702. Хотя в приведенном для примера компьютере 702 изображены жесткий диск 716, съемный магнитный диск 720 и съемный оптический диск 724, необходимо понимать, что другие типы носителей с электронным доступом могут хранить инструкции, к которым имеется доступ электронным устройством, такие как магнитные кассеты или другие устройства с магнитным хранением, флэш-память, компакт-диск, цифровой многофункциональный диск или другой оптический накопитель, ОЗУ, ПЗУ, электрически стираемые программируемые постоянные запоминающие устройства (ЭСППЗУ) и т.д. Такие носители также могут включать в себя кристаллы так называемых специальных или жестко смонтированных интегральных схем (ИС). Другими словами, может быть использован любой носитель с электронным доступом для реализации носителя данных примерной электронной системы и среды 700.
Любое количество программных модулей (или других блоков или наборов инструкций) может храниться на жестком диске 716, магнитном диске 720, оптическом диске 724, в ПЗУ 712 и/или ОЗУ 710, включая, в качестве общего примера, операционную систему 728, одну или несколько программ 730 приложения, другие программные модули 732 и программные данные 734. В качестве конкретного примера, но не ограничения, визуализатор 410 видеоданных, графический интерфейс 412 и интерфейс 414 драйверов устройств (все на фиг.4) могут быть частью операционной системы 728. Драйвер 422 графического устройства может быть частью программных модулей 732, дополнительно с тесной связью и/или с неотъемлемой зависимостью от операционной системы 728. Также вызывающая программа, такая как Windows® Media® 9, является примером программы 730 приложения. Управление изображением и/или графические данные, которые находятся в текущий момент в системной памяти, могут быть частью программных данных 734.
Пользователь, который изменяет установки ФУ или другие установки видеоданных, например, может вводить команды и/или информацию в компьютер 702 через устройства ввода, такие как клавиатуру 736 и указательное устройство 738 (например, "мышь"). Другие устройства 740 ввода (конкретно не показаны) могут включать в себя микрофон, джойстик, игровой планшет, антенну спутниковой связи, последовательный порт, сканер и/или т.д. Эти и другие устройства ввода подсоединены к обрабатывающему блоку 704 через интерфейсы 742 ввода-вывода, которые подключены к системной шине 708. Однако они и/или устройства вывода могут быть, вместо этого, подсоединены посредством других конструкций интерфейсов и шин, таких как параллельный порт, игровой порт, универсальная последовательная шина (УПШ), интерфейс IEEE 1394 (Firewire), беспроводный интерфейс IEEE 802.11, беспроводный интерфейс Bluetooth® и т.д.
Монитор/экран 744 для визуального наблюдения (который представляет собой пример устройства 436 отображения на фиг.4) или другой тип устройства отображения также может быть подсоединен к системной шине 708 через интерфейс, такой как видеоадаптер 746. Видеоадаптер 746 (или другой компонент) может быть графической платой или может включать ее в себя (которая является примером графического устройства 424) для обработки вычислений с большим количеством графики и для обработки, требующей необходимости отображения. В типовом случае, графическая плата включает в себя БГП (такой как БГП 426), видеоОЗУ (ВОЗУ) (которая является примером видеопамяти 432) и т.д., способствующие быстрому выполнению графических операций. В дополнение к монитору 744 другие периферийные устройства вывода могут включать в себя компоненты, такие как громкоговорители (не показаны) и принтер 748, которые могут быть подсоединены к компьютеру 702 через интерфейсы 742 ввода-вывода.
Компьютер 702 может работать в сетевой среде, используя логические подключения к одному или нескольким удаленным компьютерам, таким как удаленное вычислительное устройство 750. В качестве примера, удаленным вычислительным устройством 750 может быть персональный компьютер, портативный компьютер (например, дорожный компьютер, планшетный компьютер, персональный цифровой помощник, станция подвижной связи и т.д.), карманный компьютер, игровое устройство, сервер, маршрутизатор, сетевой компьютер, равноправное устройство, другой общий узел сети или другой тип компьютера в дополнение к вышеперечисленному и т.д. Удаленное вычислительное устройство 750, однако, изображено в виде портативного компьютера, который может включать в себя многие или все элементы и признаки, описанные здесь в отношении компьютера 702.
Логические соединения между компьютером 702 и удаленным компьютером 750 изображены в виде локальной вычислительной сети (ЛВС) 752 и общей глобальной вычислительной сети (ГВС) 754. Такие сетевые среды являются общепринятыми в офисах, корпоративных вычислительных сетях, интрасетях, Интернете, стационарных и мобильных телефонных сетях, других беспроводных сетях, игровых сетях, некоторых их комбинациях и т.д.
При осуществлении в сетевой среде ЛВС компьютер 702 обычно подсоединен к ЛВС 752 через сетевой интерфейс или адаптер 756. При осуществлении в сетевой среде ГВС компьютер 702 в типовом случае включает в себя модем 758 или другое средство для установления связи через ГВС 754. Модем 758, который может быть внутренним или внешним по отношению к компьютеру 702, может быть подсоединен к системной шине 708 через интерфейсы 742 ввода-вывода или любое другое соответствующее средство (средства). Необходимо иметь ввиду, что изображенные сетевые подключения являются примерными и что могут быть использованы другие средства установления канала (каналов) связи между компьютерами 702 и 750.
В сетевой среде, такой как иллюстрируется средой 700 электронного устройства, программные модули или другие инструкции, которые описаны в отношении компьютера 702, или его частей, могут полностью или частично храниться в устройстве хранения удаленной памяти. В качестве примера, удаленные программы 760 приложений постоянно находятся в компоненте памяти удаленного компьютера 750, но могут быть использованы или другим образом может быть выполнен к ним доступ через компьютер 702. Также, для целей иллюстрации, программы 730 приложений и другие инструкции с электронным исполнением, такие как операционная система 728, изображены здесь в виде дискретных блоков, но понятно, что такие программы, компоненты и другие инструкции постоянно находятся в различные моменты времени в различных компонентах хранения вычислительного устройства 702 (и/или удаленного вычислительного устройства 750) и исполняются процессором(ами) 704 данных компьютера 702 (и/или процессором(ами) удаленного вычислительного устройства 750).
Хотя системы, носители, способы, протоколы, принципы, процессы, устройства и их осуществления были описаны языком, характерным для конструктивных, логических, алгоритмических и функциональных признаков и/или диаграмм, необходимо иметь в виду, что изобретение, определенное в прилагаемой формуле изобретения, необязательно ограничивается конкретными описанными признаками или диаграммами. Скорее, конкретные признаки и диаграммы описаны как примерные формы осуществления заявленного изобретения.
Изобретение относится к средствам обработки графических данных. Техническим результатом является обеспечение взаимодействия между визуализаторами видеоданных и драйверами графического аппаратного обеспечения. Технический результат достигается тем, что при помощи протоколов связи и/или интерфейса прикладного программирования, позволяющих производить обмен информацией, осуществляют передачу запроса от визуализатора видеоданных на драйвер графического устройства, в отношении операций обработки изображения, которые драйвер графического устройства способен предоставить визуализатору видеоданных, ответ на запрос указывает, по меньшей мере, на одну операцию обработки изображения, которую драйвер графического устройства способен предоставить визуализатору видеоданных. Причем операции обработки изображения включают операции регулировок управления формирующим усилителем (ФУ), устранения чересстрочности, коррекций формата изображения, преобразований цветового пространства, преобразований частоты кадров, вертикального или горизонтального зеркального отображения и альфа-смешения. 16 н. и 68 з.п. ф-лы, 7 ил.
Приоритет по пунктам:
WO 00/38161 А1, 21.12.1998 | |||
ЭЛЕКТРОННЫЙ ЦВЕТОКОРРЕКТОР | 1989 |
|
RU2033702C1 |
RU 97109918 А, 27.05.1999 | |||
JP 2001117806 А1, 27.04.2001 | |||
US 6166720 A, 26.12.2000 | |||
Способ изготовления биметаллических изделий из порошковых материалов | 1984 |
|
SU1215868A1 |
Авторы
Даты
2007-10-10—Публикация
2003-04-15—Подача