Текущее время: 13 май 2024, 08:09 • Часовой пояс: UTC + 3 часа |
Актуальный SDK/API…
Автор | Сообщение |
f2065
|
|
Зарегистрирован: 28 сен 2006, 05:01 Сообщения: 830 Откуда: Russia,Moscow
|
А как получить актуальный 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 штук)… Можно конечно анализировать разные косвенные факторы для поиска нужного окна, но может есть более простое решение?
|
|
|
BTVSoft
|
|
Beholder | ![Аватара пользователя](./download/file.php?avatar=12.jpg) |
Зарегистрирован: 19 авг 2004, 11:47 Сообщения: 190
|
f2065 писал(а): Так же очевидно что все команды контектстных меню тоже должны иметь свои коды (а с ними можно написать гораздо больше разных полезных плагинов). Например при помощи Spy++ я уже знаю какому окну просто послать WM_COMMAND 103 для прямого включения 4:3, или WM_COMMAND 104 для 16:9… Напрямую по хэндлу посылал - работает! Однако вопрос - как это окно простым образом найти? У него имени нет, класс «TPUtilWindow» (и таких окон 7 штук)… Можно конечно анализировать разные косвенные факторы для поиска нужного окна, но может есть более простое решение? В официальном API нет команды для переключения соотношения сторон. Все что вы делаете - это пытаетесь посылать команды в ID пункты меню. Это не есть правильно. Если вам действительно не хватает каких-то команд в стандартном API, напишите нам, мы постараемся реализовать их.
|
|
|
hd44780
|
|
Эксперт | ![Аватара пользователя](./download/file.php?avatar=8220.gif) |
Зарегистрирован: 23 мар 2007, 14:32 Сообщения: 4034 Откуда: РФ, ДНР, Донецк
|
f2065 писал(а): Напрямую по хэндлу посылал - работает! Уж не видеоокну Вы его посылали? Если да, то ищите его через Код: HWND hBhWnd = FindWindow ( "TVideoFrame", "Video window" ); Это где-то здесь на форуме от Support-а проскакивало ....
Behold TV 609FM, Behold TV X7 Intel Core i7-4770K, ASUS Z87-K, RAM 32 GB, NVidia GT630 2GB. Win7, на 10 худо-бедно пахал только X7 влагодаря аппаратному кодировщику.
|
|
|
f2065
|
|
Зарегистрирован: 28 сен 2006, 05:01 Сообщения: 830 Откуда: Russia,Moscow
|
BTVSoft писал(а): Если вам действительно не хватает каких-то команд в стандартном API, напишите нам, мы постараемся реализовать их. Например не хватает команд для выбора соотношения сторон (и отключения свободного аспекта для фуллскрина, только не триггер а конкретное выкл или вкл) - все 5 пунктов меню «Соотношение сторон». И команда сообщающая текущее состояние свободного режима и выбранного аспекта. Вот чтобы написать такой плагин - viewtopic.php?f=7&t=7188&start=30И ведь очевидно что если и будет это дополнение API реализовано - то через много дней (если не месяцев). А прямая эмуляция меню - работает здесь и сейчас. Поэтому вообще на будущее была бы полезна команда возвращающая хэндл того окна которому можно слать коды меню. hd44780 писал(а): Уж не видеоокну Вы его посылали? Я же писал кому я посылаю… Увы, это не видеоокно (а вообще окон у него полсотни).
|
|
|
f2065
|
|
Зарегистрирован: 28 сен 2006, 05:01 Сообщения: 830 Откуда: Russia,Moscow
|
Возникло несколько вопросов:
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 нет?
|
|
|
hd44780
|
|
Эксперт | ![Аватара пользователя](./download/file.php?avatar=8220.gif) |
Зарегистрирован: 23 мар 2007, 14:32 Сообщения: 4034 Откуда: РФ, ДНР, Донецк
|
f2065 писал(а): 1. Что за версия возвращается в BeholdTV_Plugin_Version и на что это влияет? Я так понял что это не версия плагина… Именно версия Вашего плагина. Эту функцию ПО вызывает. Зачем - не знаю. Разработчики ответят. f2065 писал(а): 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? Или это зависит ещё от каких-то факторов и мне надо ожидать и какой-то другой вариант? Не знаю. По-моему, всегда YUV422, но не уверен. Я писал плагин наложения текста на кадр и проверял только Код: ePixFmt PixFmt; // формат кадра (YUY2 или RGB24) RGB кадров я вообще не видел. Может они есть только на тюнерах с RGB входом? Но у меня таких нету, проверить не могу. Со своей стороны могу поделиться функциями YUY2<->RGB24 для Си. Написаны на асме с оптимизацией под MMX. Аргументы там - 2 указателя (буфер-источник, буфер-приёмник) и размеры (width, height). Страйдов нету, с этой хренью, видать, сам бехолдовский плагинный фильтр разбирается. Тем проще для нас ![Улыбочка :)](./images/smilies/icon_smile.gif) . Писал не я, добрые люди поделились на каком-то программистском форуме. Работают нормально вроде. f2065 писал(а): 4. В функциях PROC_PLUGIN_START и PROC_PLUGIN_FUNC на что влияет возврат FALSE или TRUE ? Оба варианта возврата - и в обоих случаях плагин работает нормально… Может задел на будущее - типа вырубать плагины, которые не смогли инициализироваться .... Пока могу посоветовать писать как положено - TRUE - всё в порядке, FALSE - проблемы. А что из этого - не нашего ума заботы .... А то выйдет завтра новая версия ПО, где это проверяется, и полезут разные глюки от того, что какой-то автор какого-то плагина схалтурил и поленился чётко прописать эти "мелочи". f2065 писал(а): 5. PROC_PLUGIN.szName, PROC_PLUGIN.szDesc - там ANSI… На нерусской винде (понимаю что это практически неактуально) - русские буквы будут ведь нечитаемы. Сходу не увидел решения. BeholdTV_Plugin_PR ведь не передаёт идентификатора языка. Разве что самому в DLL_PROCESS_ATTACH смотреть GetACP() и прописывать нужную строку в PROC_PLUGIN. Где-то тут админ писал, что ПО работает только в ANSI. Если есть возможность - поставьте винду с китайскими иероглифами или арабской вязью, проверьте, и нам расскажете ![Счастлив :D](./images/smilies/icon_biggrin.gif) . Да и все файлы со списками каналов и разными настройками, кстати тоже в кодировке Win-1251 ... f2065 писал(а): Решения на уровне Beholder API нет? API такое, какое есть. Я сам тут года 2-3 назад просил дать что-то "покруче". Даже тему где-то создавал со своими пожеланиями. Пока тишина ![Плачу :cry:](./images/smilies/icon_cry.gif) .
Behold TV 609FM, Behold TV X7 Intel Core i7-4770K, ASUS Z87-K, RAM 32 GB, NVidia GT630 2GB. Win7, на 10 худо-бедно пахал только X7 влагодаря аппаратному кодировщику.
|
|
|
BTVSoft
|
|
Beholder | ![Аватара пользователя](./download/file.php?avatar=12.jpg) |
Зарегистрирован: 19 авг 2004, 11:47 Сообщения: 190
|
f2065Цитата: а вообще окон у него полсотни Каких таких полсотни? Если не открывать диалоги, то 2 основных окна, в видеоокне несколько дочерних и в главной панели несколько окон, относящихся к таймеру. Всего около 15 окон, включая дочерние. Цитата: Что за версия возвращается в BeholdTV_Plugin_Version и на что это влияет? Внутренний параметр. Подставляете из примера. Цитата: PARAM_STR.BitPerPixel и PARAM_STR.PixFmt - нет ли в этом избыточной инфы? Ведь по идее есть только два варианта - BitPerPixel=16bpp и PixFmt=YUY2, либо BitPerPixel=24bpp и PixFmt=RGB24. Можно ли ожидать каких-то других комбинаций? Это два разных параметра, сделаны были ранее для удобства, поскольку заранее было неизвестно, какие форматы пространства могли быть в последующих моделях. Формат RGB24 будет актуален при выборе RGB24 в настройках просмотра или записи. На текущих моделях других вариантов не будет. Формат нужен для понимания расположения пикселов в буфере, число бит на пиксел используется для рассчета страйда строки. Нет ничего плохого в том, что есть избыточная информация, хуже когда ее не хватает. Цитата: В функциях PROC_PLUGIN_START и PROC_PLUGIN_FUNC на что влияет возврат FALSE или TRUE Возвращаемое значение анализируется в родительском фильтре. Если, например, PROC_PLUGIN_START вернул FALSE, для него Stop не вызывается. Цитата: PROC_PLUGIN.szName, PROC_PLUGIN.szDesc - там ANSI Это так. В чисто EN версиях Windows нет никаких проблем, если установлена поддержка требуемой кодовой страницы.
|
|
|
f2065
|
|
Зарегистрирован: 28 сен 2006, 05:01 Сообщения: 830 Откуда: Russia,Moscow
|
hd44780 писал(а): Со своей стороны могу поделиться функциями YUY2<->RGB24 для Си. Написаны на асме с оптимизацией под MMX. Было бы интересно посмотреть на YUY2->RGB (обратно тут не нужно)… Я вообще поискал в инете, везде какие-то тормозные пример с двойным вызовом подпрограммы для каждой пары байт… Написал сам с нуля, почитав википедию: Код: ; стандартная формула конвертации YUY2(422) в RGB888 ; прочитать 4 байта Y'UV (u, y1, v, y2 ) ; записать 6 байт RGB (R, G, B, R, G, B) ; y1 = yuv[0]; ; u = yuv[1]; ; y2 = yuv[2]; ; v = yuv[3]; ; rgb1 = Y'UV444toRGB888(y1, u, v); ; rgb2 = Y'UV444toRGB888(y2, u, v); ; ; Y'UV444toRGB888: ; C = Y-16 ; D = U-128 ; E = V-128 ; R = clamp ((298*C + 409*E + 128) >> 8) ; G = clamp ((298*C - 100*D - 208*E + 128) >> 8) ; B = clamp ((298*C + 516*D + 128) >> 8) ; ; Оптимизация формулы: ; F = 298*C+128 ; R = clamp ((F + 409*E) >> 8) ; G = clamp ((F - 100*D - 208*E) >> 8) ; B = clamp ((F + 516*D) >> 8) ; ; далее вторая оптимизация алгоритма - учитывая что в каждом из 2 вызовов Y'UV444toRGB888 ; одинаковое вычисление D и E (из V и U) - надо сделать единую функцию, чтобы 2 лишних вычислений не было
; Вход: ; esi - начало массива YUY2 ; edi - выход для RGB ; ebp - размер массива YUY2 в байтах (ebp = X*Y*2)
loop1: ; C = Y'-16 xor eax, eax lodsb ; Y1 sub eax, 16 mov edx, 298 imul edx add eax, 128 movd mm1, eax ; F for R1 movd mm2, eax ; F for G1 movd mm3, eax ; F for B1
; D = U-128 xor eax, eax lodsb ; U sub eax, 128 mov ebx, eax ; D
; C = Y'-16 xor eax, eax lodsb ; Y2 sub eax, 16 mov edx, 298 imul edx add eax, 128 movd mm4, eax ; F for R2 movd mm5, eax ; F for G2 movd mm6, eax ; F for B2 ; E = V-128 xor eax, eax lodsb ; V sub eax, 128 mov ecx, eax ; E
; 409*E ; mov eax, ecx ; E mov edx, 409 imul edx movd mm0, eax paddd mm1, mm0 ; R1 paddd mm4, mm0 ; R2
; 100*D mov eax, ebx ; D mov edx, 100 imul edx movd mm0, eax psubd mm2, mm0 ; G1 psubd mm5, mm0 ; G2
; 208*E mov eax, ecx ; E mov edx, 208 imul edx movd mm0, eax psubd mm2, mm0 ; G1 psubd mm5, mm0 ; G2
; 516*D mov eax, ebx ; D mov edx, 516 imul edx movd mm0, eax paddd mm3, mm0 ; B1 paddd mm6, mm0 ; B2
; >> 8 psrad mm3, 8 ; B1 psrad mm2, 8 ; G1 psrad mm1, 8 ; R1 psrad mm6, 8 ; B2 psrad mm5, 8 ; G2 psrad mm4, 8 ; R2
; clamp packuswb mm3, mm3 packuswb mm2, mm2 packuswb mm1, mm1 packuswb mm6, mm6 packuswb mm5, mm5 packuswb mm4, mm6
movd eax, mm3 ; B1 stosb movd eax, mm2 ; G1 stosb movd eax, mm1 ; R1 stosb
movd eax, mm6 ; B2 stosb movd eax, mm5 ; G2 stosb movd eax, mm4 ; R2 stosb sub ebp, 4 ja loop1 hd44780 писал(а): Где-то тут админ писал, что ПО работает только в ANSI. Ну как-бы в BeholdTV можно выбрать English-интерфейс… И тогда ANSI не страшно. Если все тексты (особенно описание) в плагинах тоже писать на английском. BTVSoft писал(а): Цитата: а вообще окон у него полсотни Каких таких полсотни? Если не открывать диалоги, то 2 основных окна, в видеоокне несколько дочерних и в главной панели несколько окон, относящихся к таймеру. Всего около 15 окон, включая дочерние. Это не так. Всякие анализаторы (spy++, Process Monitor и т.п.) наглядно показывают что живых окон у него 48 штук. Из них 23 окна верхнего уровня… BTVSoft писал(а): Цитата: PROC_PLUGIN.szName, PROC_PLUGIN.szDesc - там ANSI Это так. В чисто EN версиях Windows нет никаких проблем, если установлена поддержка требуемой кодовой страницы. Проблема есть, если пользователь совсем не русский и понимает только EN. Во-первых ему придётся поставить RU-страницу для всех(!) неюникодных программ, во-вторых это ему всё равно не поможет (т.к. русского языка он не знает). Или
|
|
|
hd44780
|
|
Эксперт | ![Аватара пользователя](./download/file.php?avatar=8220.gif) |
Зарегистрирован: 23 мар 2007, 14:32 Сообщения: 4034 Откуда: РФ, ДНР, Донецк
|
f2065 писал(а): Было бы интересно посмотреть на YUY2->RGB (обратно тут не нужно)… Ловите ![Счастлив :D](./images/smilies/icon_biggrin.gif) . BPP_DrawText.zip - мой полный плагин - пишет фразу "Сигнал кончился, сигнала больше нет!" в соответствующей ситуации. Текст вшитый, управления никакого нет. Алгоритм там, в сущности, простой - если кадр в YUV, конвертируем его в RGB24, пишем текст с помощью WinAPI, потом обратно в YUV. Если кадр уже в RGB, то оба конвертирования не выполняются. Может где-то и криво, не знаю, особо не заморачивался. Единственный недостаток, который заметил - загрузка проца типа 25% на моём 4-головом Core2Quad. Но на каком этапе он жрёт процессор я не изучал - меня и так устраивает ![Счастлив :D](./images/smilies/icon_biggrin.gif) . Как писать текст сразу на YUV я не нашёл. Где-то мне советовали библиотеку Intel IPP (если название не переврал за давностью лет), но я её так и не смотрел. Компилится под VS.NET 2005, более ранние и более поздние не проверял. Собственно конвертирование всё сидит в convert_yuy2.h. выдрано из Avisynth v2.5 (там написано). Поэтому, если где какая-то бажина вылезет, все бочки катите на него, меня там и рядом не стояло ![Счастлив :D](./images/smilies/icon_biggrin.gif) . Кстати. Я когда-то пытался анализировать чёрные полосы, помнится там гонять YUV в RGB не нужно. Достаточно вычленять из строки кадра яркостную Y компоненту и анализировать её. В чёрных полосах она почти в нуле болтается .... RGB проверять гораздо сложнее - сбоев и ошибок в разы больше. Я этот этап проходил уже .... Да и порог срабатывания хрен знает как определить. Ведь RGB24=000000h очень редко бывает. Может для какого-то одного пикселя строки и проскочит такое, а в целом по строке такого точно никогда не будет. Может ещё и от алгоритма конвертирования как-то зависит - не знаю. А если в кадре есть жуткие эфирные наводки на какую-нибудь поганую антенну-проволочку в усложнённых условиях типа "коробки из многоэтажек" - там проще сразу пойти и удавиться с горя, чем RGB24 анализировать ![Плачу :cry:](./images/smilies/icon_cry.gif) ... Вы посмотрите стандартный плагин-осциллограф BPP_LineView, там эти особенности очень отчётливо просматриваются. Довольно полезная штука ![Улыбочка :)](./images/smilies/icon_smile.gif) . Вложил архив BPP_AutoAspect_2005.zip - мои потуги на этом поприще. Аспекты не переключает, просто рисует линию по границе чёрной полосы (только верхней ![Счастлив :D](./images/smilies/icon_biggrin.gif) , я на ней тренировался). Может что-то для Вас сгодится... Я это дело забросил, надоело ![Счастлив :D](./images/smilies/icon_biggrin.gif) . Мне оно и на фиг не надо - монитор всё равно 4:3 и менять его я не собираюсь ![Счастлив :D](./images/smilies/icon_biggrin.gif) .... А телек мой широкоформатный такие фокусы от рождения делать умеет. Писал просто так, чисто для удовольстия. PS. Если BPP_AutoAspect_2005 окажется чем-то не тем ![Счастлив :D](./images/smilies/icon_biggrin.gif) , стукните. Просто я на работе, проверить не могу (тюнера нету). Я тогда дома гляну и кину ещё раз. Делал тоже в 2005-й студии, другие не проверял. Удачи. Если что, можете спрашивать в личку. Смогу-помогу.
Behold TV 609FM, Behold TV X7 Intel Core i7-4770K, ASUS Z87-K, RAM 32 GB, NVidia GT630 2GB. Win7, на 10 худо-бедно пахал только X7 влагодаря аппаратному кодировщику.
|
|
|
f2065
|
|
Зарегистрирован: 28 сен 2006, 05:01 Сообщения: 830 Откуда: Russia,Moscow
|
hd44780 писал(а): Собственно конвертирование всё сидит в convert_yuy2.h. выдрано из Avisynth v2.5 (там написано). Ну да, это в целом медленная процедура за счёт универсальности… hd44780 писал(а): Я когда-то пытался анализировать чёрные полосы, помнится там гонять YUV в RGB не нужно. Достаточно вычленять из строки кадра яркостную Y компоненту и анализировать её. В чёрных полосах она почти в нуле болтается .... Тоже думал так, но похоже что не всегда, для Y при чёрном цвете обычно значение около 0xE. Надо внимательно принцип работы YUY изучать… Скорее на этапе распаковки я буду сразу объединять RGB в 1 байт (либо сложением либо OR). Всё равно нужна унификация алгоритма на случай если приходит RGB. hd44780 писал(а): RGB проверять гораздо сложнее - сбоев и ошибок в разы больше. Я этот этап проходил уже .... Да и порог срабатывания хрен знает как определить. Ведь RGB24=000000h очень редко бывает. Ну так побайтно… плюс отсеивать шум исходя из того что шум идёт по горизонтали. Т.е. единичная яркая точка у которой сверху и снизу темно - это шум. Я думаю анализировать прямоугольник и подсчитывать его средневзвешенный уровень… Плюс границы в заведомо эффективной части кадра. Вложение:
![wide_correct.jpg](./download/file.php?id=327)
wide_correct.jpg [ 61.33 КБ | Просмотров: 29423 ]
Считаетм средневзвешенное значение для зон кадра. темнота = 0 свет = 1 H0 = ничего не делать A0 B0 C0 D1 E1 G0 F0 = 16:9 A1 or B1 or C1 or F1 or G1 = 4:3 hd44780 писал(а): А если в кадре есть жуткие эфирные наводки на какую-нибудь поганую антенну-проволочку в усложнённых условиях типа "коробки из многоэтажек" - там проще сразу пойти и удавиться с горя, чем RGB24 анализировать ![Плачу :cry:](./images/smilies/icon_cry.gif) ... Я вообще пока только одну проблему вижу - возможность разных размеров потока (непонятно зачем их предусмотрели). Не только 768*576, а ещё и другие. Надо делать универсальный расчёт координат, а это увеличивает нагрузку CPU.
|
|
|
hd44780
|
|
Эксперт | ![Аватара пользователя](./download/file.php?avatar=8220.gif) |
Зарегистрирован: 23 мар 2007, 14:32 Сообщения: 4034 Откуда: РФ, ДНР, Донецк
|
f2065 писал(а): Я вообще пока только одну проблему вижу - возможность разных размеров потока (непонятно зачем их предусмотрели). Не только 768*576, а ещё и другие. Надо делать универсальный расчёт координат, а это увеличивает нагрузку CPU. Я думаю, здесь причины исторические. Раньше компы были дохлые и хилые. Ну не тянули они обработку полноразмерного кадра. Я сам лично в начале 2000-х годов делал записи 382x288 (если правильно помню), ибо мой тогдашний Celeron Tualatin 1200 (был такой проц ![Улыбочка :)](./images/smilies/icon_smile.gif) ) большего не тянул. Вы можете пока схитрить - сказать, что вы обрабатываете только максимальный кадр размером 768x572. Если идёт меньше - ничего не делаете. Захотите - потом добавите.
Behold TV 609FM, Behold TV X7 Intel Core i7-4770K, ASUS Z87-K, RAM 32 GB, NVidia GT630 2GB. Win7, на 10 худо-бедно пахал только X7 влагодаря аппаратному кодировщику.
|
|
|
f2065
|
|
Зарегистрирован: 28 сен 2006, 05:01 Сообщения: 830 Откуда: Russia,Moscow
|
hd44780 писал(а): Вы можете пока схитрить - сказать, что вы обрабатываете только максимальный кадр размером 768x572. А вот нет ли тут какой особенности с NTSC? У них что-то размер потока 720*480… Проверить проблематично… На SECAM пробовал включить вручную NTSC - 768x572 идёт… Но вероятно там возникают искажения из-за интерполяции строк из 480 в 576 (не кратное число ведь).
|
|
|
ALF
|
|
Эксперт | ![Аватара пользователя](./download/file.php?avatar=3555.gif) |
Зарегистрирован: 02 апр 2006, 21:37 Сообщения: 1329
|
В NTSC 480 строк и с этим надо считаться. К тому же PCI-E чипсеты не имеют встроенного скаллера и у них нет формата 768хХХХ с квадратным пикселем. Только 704хХХХ, 720хХХХ и кратные им. С этим тоже надо считаться. Т.е. как не крути, а размер кадра надо учитывать и то, что драйвер тюнера поддерживает на выходе несколько разрешений - абсолютно нормальное явление. В DirectShow это всегда воспринималось как должное.
Behold TV M6 Extra Behold TV H8 Behold TV T8
|
|
|
hd44780
|
|
Эксперт | ![Аватара пользователя](./download/file.php?avatar=8220.gif) |
Зарегистрирован: 23 мар 2007, 14:32 Сообщения: 4034 Откуда: РФ, ДНР, Донецк
|
А зачем этот NTSC вообще? Он же вроде только в Америке и Японии кажется эксплуатируется ....
Behold TV 609FM, Behold TV X7 Intel Core i7-4770K, ASUS Z87-K, RAM 32 GB, NVidia GT630 2GB. Win7, на 10 худо-бедно пахал только X7 влагодаря аппаратному кодировщику.
|
|
|
ALF
|
|
Эксперт | ![Аватара пользователя](./download/file.php?avatar=3555.gif) |
Зарегистрирован: 02 апр 2006, 21:37 Сообщения: 1329
|
Если формат существует, то он должен поддерживаться. Потом, встречаются всякие там приставки, игровые консоли и пр., где NTSC чуть ли не единственный формат на выходе или даже может меняться в зависимости от загруженной игры.
Behold TV M6 Extra Behold TV H8 Behold TV T8
|
|
|
Кто сейчас на конференции |
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 30 |
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
|
|