А как получить актуальный SDK, BhMsg.h и т.п.?

Выложенные файлы - от 2009г.
Вот например - viewtopic.php?f=10&t=11914 - упомянуты новые команды, которых до сих пор нет в опубликованном BhMsg.
И наверняка в версии 5.17 неопубликованных команд ещё очень много…

Так же очевидно что все команды контектстных меню тоже должны иметь свои коды (а с ними можно написать гораздо больше разных полезных плагинов).
Например при помощи Spy++ я уже знаю какому окну просто послать WM_COMMAND 103 для прямого включения 4:3, или WM_COMMAND 104 для 16:9…
Напрямую по хэндлу посылал - работает!
Однако вопрос - как это окно простым образом найти? У него имени нет, класс «TPUtilWindow» (и таких окон 7 штук)… Можно конечно анализировать разные косвенные факторы для поиска нужного окна, но может есть более простое решение?

В официальном API нет команды для переключения соотношения сторон. Все что вы делаете - это пытаетесь посылать команды в ID пункты меню. Это не есть правильно.

Если вам действительно не хватает каких-то команд в стандартном API, напишите нам, мы постараемся реализовать их.

Уж не видеоокну Вы его посылали?
Если да, то ищите его через

Это где-то здесь на форуме от Support-а проскакивало ....

Например не хватает команд для выбора соотношения сторон (и отключения свободного аспекта для фуллскрина, только не триггер а конкретное выкл или вкл) - все 5 пунктов меню «Соотношение сторон». И команда сообщающая текущее состояние свободного режима и выбранного аспекта.
Вот чтобы написать такой плагин - viewtopic.php?f=7&t=7188&start=30

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


Я же писал кому я посылаю… Увы, это не видеоокно (а вообще окон у него полсотни).

Возникло несколько вопросов:

1. Что за версия возвращается в BeholdTV_Plugin_Version и на что это влияет? Я так понял что это не версия плагина…

2. PARAM_STR.BitPerPixel и PARAM_STR.PixFmt - нет ли в этом избыточной инфы?
Ведь по идее есть только два варианта - BitPerPixel=16bpp и PixFmt=YUY2, либо BitPerPixel=24bpp и PixFmt=RGB24.
Можно ли ожидать каких-то других комбинаций?

3. Какой тут YUY2?
Он всегда фиксированный Sampling YUV422, Order YUYV, Progressive, Packed, и только надо учесть размеры FrameWidth*FrameHeight?
Или это зависит ещё от каких-то факторов и мне надо ожидать и какой-то другой вариант?

4. В функциях PROC_PLUGIN_START и PROC_PLUGIN_FUNC на что влияет возврат FALSE или TRUE ? Оба варианта возврата - и в обоих случаях плагин работает нормально…

5. PROC_PLUGIN.szName, PROC_PLUGIN.szDesc - там ANSI… На нерусской винде (понимаю что это практически неактуально) - русские буквы будут ведь нечитаемы. Сходу не увидел решения. BeholdTV_Plugin_PR ведь не передаёт идентификатора языка. Разве что самому в DLL_PROCESS_ATTACH смотреть GetACP() и прописывать нужную строку в PROC_PLUGIN. Решения на уровне Beholder API нет?

Именно версия Вашего плагина. Эту функцию ПО вызывает. Зачем - не знаю. Разработчики ответят.


Не знаю. По-моему, всегда YUV422, но не уверен.
Я писал плагин наложения текста на кадр и проверял только

RGB кадров я вообще не видел. Может они есть только на тюнерах с RGB входом? Но у меня таких нету, проверить не могу.
Со своей стороны могу поделиться функциями YUY2<->RGB24 для Си. Написаны на асме с оптимизацией под MMX. Аргументы там - 2 указателя (буфер-источник, буфер-приёмник) и размеры (width, height).
Страйдов нету, с этой хренью, видать, сам бехолдовский плагинный фильтр разбирается. Тем проще для нас .
Писал не я, добрые люди поделились на каком-то программистском форуме. Работают нормально вроде.


Может задел на будущее - типа вырубать плагины, которые не смогли инициализироваться ....
Пока могу посоветовать писать как положено - TRUE - всё в порядке, FALSE - проблемы. А что из этого - не нашего ума заботы ....
А то выйдет завтра новая версия ПО, где это проверяется, и полезут разные глюки от того, что какой-то автор какого-то плагина схалтурил и поленился чётко прописать эти "мелочи".


Где-то тут админ писал, что ПО работает только в ANSI.
Если есть возможность - поставьте винду с китайскими иероглифами или арабской вязью, проверьте, и нам расскажете .
Да и все файлы со списками каналов и разными настройками, кстати тоже в кодировке Win-1251 ...


API такое, какое есть. Я сам тут года 2-3 назад просил дать что-то "покруче". Даже тему где-то создавал со своими пожеланиями.
Пока тишина .

f2065

Каких таких полсотни? Если не открывать диалоги, то 2 основных окна, в видеоокне несколько дочерних и в главной панели несколько окон, относящихся к таймеру. Всего около 15 окон, включая дочерние.


Внутренний параметр. Подставляете из примера.


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


Возвращаемое значение анализируется в родительском фильтре. Если, например, PROC_PLUGIN_START вернул FALSE, для него Stop не вызывается.


Это так. В чисто EN версиях Windows нет никаких проблем, если установлена поддержка требуемой кодовой страницы.

Было бы интересно посмотреть на YUY2->RGB (обратно тут не нужно)…
Я вообще поискал в инете, везде какие-то тормозные пример с двойным вызовом подпрограммы для каждой пары байт… Написал сам с нуля, почитав википедию:


Ну как-бы в BeholdTV можно выбрать English-интерфейс… И тогда ANSI не страшно. Если все тексты (особенно описание) в плагинах тоже писать на английском.


Это не так. Всякие анализаторы (spy++, Process Monitor и т.п.) наглядно показывают что живых окон у него 48 штук. Из них 23 окна верхнего уровня…


Проблема есть, если пользователь совсем не русский и понимает только EN. Во-первых ему придётся поставить RU-страницу для всех(!) неюникодных программ, во-вторых это ему всё равно не поможет (т.к. русского языка он не знает). Или

Ловите .
BPP_DrawText.zip - мой полный плагин - пишет фразу "Сигнал кончился, сигнала больше нет!" в соответствующей ситуации. Текст вшитый, управления никакого нет.
Алгоритм там, в сущности, простой - если кадр в YUV, конвертируем его в RGB24, пишем текст с помощью WinAPI, потом обратно в YUV. Если кадр уже в RGB, то оба конвертирования не выполняются.
Может где-то и криво, не знаю, особо не заморачивался. Единственный недостаток, который заметил - загрузка проца типа 25% на моём 4-головом Core2Quad. Но на каком этапе он жрёт процессор я не изучал - меня и так устраивает .
Как писать текст сразу на YUV я не нашёл.
Где-то мне советовали библиотеку Intel IPP (если название не переврал за давностью лет), но я её так и не смотрел.

Компилится под VS.NET 2005, более ранние и более поздние не проверял.
Собственно конвертирование всё сидит в convert_yuy2.h. выдрано из Avisynth v2.5 (там написано).
Поэтому, если где какая-то бажина вылезет, все бочки катите на него, меня там и рядом не стояло .

Кстати.
Я когда-то пытался анализировать чёрные полосы, помнится там гонять YUV в RGB не нужно. Достаточно вычленять из строки кадра яркостную Y компоненту и анализировать её. В чёрных полосах она почти в нуле болтается ....
RGB проверять гораздо сложнее - сбоев и ошибок в разы больше. Я этот этап проходил уже ....
Да и порог срабатывания хрен знает как определить. Ведь RGB24=000000h очень редко бывает. Может для какого-то одного пикселя строки и проскочит такое, а в целом по строке такого точно никогда не будет. Может ещё и от алгоритма конвертирования как-то зависит - не знаю.
А если в кадре есть жуткие эфирные наводки на какую-нибудь поганую антенну-проволочку в усложнённых условиях типа "коробки из многоэтажек" - там проще сразу пойти и удавиться с горя, чем RGB24 анализировать ...

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

Вложил архив BPP_AutoAspect_2005.zip - мои потуги на этом поприще. Аспекты не переключает, просто рисует линию по границе чёрной полосы (только верхней , я на ней тренировался). Может что-то для Вас сгодится...
Я это дело забросил, надоело . Мне оно и на фиг не надо - монитор всё равно 4:3 и менять его я не собираюсь ....
А телек мой широкоформатный такие фокусы от рождения делать умеет. Писал просто так, чисто для удовольстия.

PS. Если BPP_AutoAspect_2005 окажется чем-то не тем , стукните. Просто я на работе, проверить не могу (тюнера нету). Я тогда дома гляну и кину ещё раз.
Делал тоже в 2005-й студии, другие не проверял.

Удачи. Если что, можете спрашивать в личку. Смогу-помогу.

Ну да, это в целом медленная процедура за счёт универсальности…


Тоже думал так, но похоже что не всегда, для Y при чёрном цвете обычно значение около 0xE. Надо внимательно принцип работы YUY изучать… Скорее на этапе распаковки я буду сразу объединять RGB в 1 байт (либо сложением либо OR). Всё равно нужна унификация алгоритма на случай если приходит RGB.


Ну так побайтно… плюс отсеивать шум исходя из того что шум идёт по горизонтали. Т.е. единичная яркая точка у которой сверху и снизу темно - это шум.

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


Считаетм средневзвешенное значение для зон кадра.
темнота = 0
свет = 1

H0 = ничего не делать
A0 B0 C0 D1 E1 G0 F0 = 16:9
A1 or B1 or C1 or F1 or G1 = 4:3


Я вообще пока только одну проблему вижу - возможность разных размеров потока (непонятно зачем их предусмотрели). Не только 768*576, а ещё и другие. Надо делать универсальный расчёт координат, а это увеличивает нагрузку CPU.

Я думаю, здесь причины исторические. Раньше компы были дохлые и хилые. Ну не тянули они обработку полноразмерного кадра.
Я сам лично в начале 2000-х годов делал записи 382x288 (если правильно помню), ибо мой тогдашний Celeron Tualatin 1200 (был такой проц ) большего не тянул.
Вы можете пока схитрить - сказать, что вы обрабатываете только максимальный кадр размером 768x572. Если идёт меньше - ничего не делаете. Захотите - потом добавите.

А вот нет ли тут какой особенности с NTSC? У них что-то размер потока 720*480… Проверить проблематично… На SECAM пробовал включить вручную NTSC - 768x572 идёт… Но вероятно там возникают искажения из-за интерполяции строк из 480 в 576 (не кратное число ведь).

В NTSC 480 строк и с этим надо считаться. К тому же PCI-E чипсеты не имеют встроенного скаллера и у них нет формата 768хХХХ с квадратным пикселем. Только 704хХХХ, 720хХХХ и кратные им. С этим тоже надо считаться. Т.е. как не крути, а размер кадра надо учитывать и то, что драйвер тюнера поддерживает на выходе несколько разрешений - абсолютно нормальное явление. В DirectShow это всегда воспринималось как должное.

А зачем этот NTSC вообще? Он же вроде только в Америке и Японии кажется эксплуатируется ....

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