убрать непрошенное сглаживание при захвате видео
- photon1984
- Advanced Member
- Сообщения: 366
- Зарегистрирован: 04.02.2011,19:29
убрать непрошенное сглаживание при захвате видео
Ситуация такова: в современный комп установлена плата захвата цветного сигнала. Принимает она сигнал с БК0011М.
У платы захвата в комплекте поставки есть ПО просмотра сигнала. Оно работает, видеоряд видно. Но есть два момента: 1) это ПО само грабить кино на хард не умеет (сохранять можно лишь одиночные кадры). 2) когда всё окно программы просмотра на рабочем столе умещается, срабатывается какое-то размытие картинки, переход от черного пикселя к не черному становиться плавным. Если окошко проги просмотра опустить хоть чуток за поле рабочего стола, это сглаживание исчезает.
Но вернёмся к записи.
Записывать кино на HDD можно VirtualDub (directshow). Оно записывается в правильном разрешении 256*256 и даже получается 48.8fps (как и должно быть у БК), но в итоге в сграбленных кадрах опять присутствует это нафиг ненужное сглаживание.
Как его выключить? Хочется на выходе иметь видеофайл без сжатия, который бы пиксель-в-пиксель повторял оригинал.
У платы захвата в комплекте поставки есть ПО просмотра сигнала. Оно работает, видеоряд видно. Но есть два момента: 1) это ПО само грабить кино на хард не умеет (сохранять можно лишь одиночные кадры). 2) когда всё окно программы просмотра на рабочем столе умещается, срабатывается какое-то размытие картинки, переход от черного пикселя к не черному становиться плавным. Если окошко проги просмотра опустить хоть чуток за поле рабочего стола, это сглаживание исчезает.
Но вернёмся к записи.
Записывать кино на HDD можно VirtualDub (directshow). Оно записывается в правильном разрешении 256*256 и даже получается 48.8fps (как и должно быть у БК), но в итоге в сграбленных кадрах опять присутствует это нафиг ненужное сглаживание.
Как его выключить? Хочется на выходе иметь видеофайл без сжатия, который бы пиксель-в-пиксель повторял оригинал.
-
- Advanced Member
- Сообщения: 5896
- Зарегистрирован: 02.08.2013,22:13
- Откуда: Павловский Посад Мск.обл.
- Контактная информация:
-
Вклад в сообщество
Осмотрел фото.
Без вывода на Граббер сигнала тактирования видеопотока БКшки сграбить 1:1 нереально - типа как при семплрейте 22 кгц получить верхнюю частоту воспроизведения звука 20 кгц. Нужно от 48 кгц для хриплых верхов или от 192 кгц для "студийного" качества.
*
Нужно грабить в несколько большем ( раза так в 3 ) разрешении по горизонтали, иначе - см. фото выше.
*
Раньше я как-то списывал через чип Филипс 7135 ( PCI 32/33 ) с помощью одной пиратской софтины ( должна гуглится ) - при разрешении 720х576х25 кадров получалось порядка 30 мбайт в 1 сек, заведомо без компресса.
Потом , по старой традиции, это дело чикалось в Адобе Премьер.
Залог качества на выходе - ставим "без компресса" 60 FPS. Да, объем гиганский, зато без потерь качества и почти без "мыльца".
Без вывода на Граббер сигнала тактирования видеопотока БКшки сграбить 1:1 нереально - типа как при семплрейте 22 кгц получить верхнюю частоту воспроизведения звука 20 кгц. Нужно от 48 кгц для хриплых верхов или от 192 кгц для "студийного" качества.
*
Нужно грабить в несколько большем ( раза так в 3 ) разрешении по горизонтали, иначе - см. фото выше.
*
Раньше я как-то списывал через чип Филипс 7135 ( PCI 32/33 ) с помощью одной пиратской софтины ( должна гуглится ) - при разрешении 720х576х25 кадров получалось порядка 30 мбайт в 1 сек, заведомо без компресса.
Потом , по старой традиции, это дело чикалось в Адобе Премьер.
Залог качества на выходе - ставим "без компресса" 60 FPS. Да, объем гиганский, зато без потерь качества и почти без "мыльца".
Коллекционирование радиодеталей : http://collectingrd.kxk.ru/
- photon1984
- Advanced Member
- Сообщения: 366
- Зарегистрирован: 04.02.2011,19:29
Если Вы о линии синхронизации, то она, конечно, к грабберу подключена (вместе с R,G и B).MM писал(а):Без вывода на Граббер сигнала тактирования видеопотока БКшки сграбить 1:1 нереально
Мне кажется, что "мыльцо" на левом скриншоте в первом сообщении - результат действия какого-то фильтра, который должен делать из пиксельной картинки - смазанную. Типа кто-то решил, что так будет красивее. Действительно, настойки захвата одни и те же - а в штатном ПО просмотра мыла нет (скриншот справа), а когда картинку хватает virtualdub через directshow - "мыльце" есть. Мне кажется, что разрешение захвата тут не при делах.
- ATauenis
- Advanced Member
- Сообщения: 5532
- Зарегистрирован: 30.04.2015,21:30
- Откуда: Москва
- Контактная информация:
-
Вклад в сообщество
Там шла речь про pixel clock. Дело в том, что граббер работает "рывками" по одному пикселю. Но частоту и фазу "рывков" он берёт с потолка, точнее на глаз по частоте строк. Это недостаточно для точной оцифровки, т.к. при этом захватывается не середина каждого пикселя, а произвольное место на нём, вплоть до границы с соседними. Также сюда может вмешиваться некий программный фильтр, дабы всю эту погрешность сгладить и списать на низкое разрешение потока. Пробуйте отключить абсолютно все возможные фильтры и писать в нативном разрешении платы видеозахвата. Для записи также годится VLC плеер, в нём можно очень гибко настраивать режим записи и оцифровки.photon1984 писал(а):MM написал:Если Вы о линии синхронизации, то она, конечно, к грабберу подключена (вместе с R,G и B).Без вывода на Граббер сигнала тактирования видеопотока БКшки сграбить 1:1 нереально
-
- Advanced Member
- Сообщения: 2138
- Зарегистрирован: 13.10.2005,21:45
- Откуда: Bryansk, Russia
- Контактная информация:
-
Вклад в сообщество
Устройство для трансляции изображения со старых компьютеров на ПК через USB. Сделай такую штуку и захватывай с супер качеством.
Под OBS classic есть расширение использующее нативное API серии этих карт.
- photon1984
- Advanced Member
- Сообщения: 366
- Зарегистрирован: 04.02.2011,19:29
- photon1984
- Advanced Member
- Сообщения: 366
- Зарегистрирован: 04.02.2011,19:29
разобрался, счастье настало
мыло при захвате через DirectShow возникало при формате YUY2. При смене YUY2 на RGB24 от мыла не осталось и следа. Только картинка стала перевёрнутой. По это не беда, тот же virtual dub умеет налету кадр переворачивать и записывать на HDD уже в правильной ориентации.
С плагином к OBS classic, использующим нативное API datapath, тоже разбирался. Тут результата не достиг. Вообще у этого подхода есть ограничения. Сам OBS Classic требует win7 или выше. А плагин требует x86-систему.
Через плагин картинка на экране получается "острая", без мыла. А вот сохранить её в несжатом виде или в loseless-сжатом виде на HDD у меня не получилось. Ни с помощью CPU (кодек x264 c ключами qp=0 и/или crf=0 и с сумасшедшим битрейтом), ни с помощью Nvidia NVENC-сжатия в режиме "loseless". Всё равно в файле мыло.
Не знаю, может быть здесь тоже всё дело в RGB24/YUY2. Получив результат по-простому в virtualdub, разборки с OBS classic мне уже не так интересны.
мыло при захвате через DirectShow возникало при формате YUY2. При смене YUY2 на RGB24 от мыла не осталось и следа. Только картинка стала перевёрнутой. По это не беда, тот же virtual dub умеет налету кадр переворачивать и записывать на HDD уже в правильной ориентации.
С плагином к OBS classic, использующим нативное API datapath, тоже разбирался. Тут результата не достиг. Вообще у этого подхода есть ограничения. Сам OBS Classic требует win7 или выше. А плагин требует x86-систему.
Через плагин картинка на экране получается "острая", без мыла. А вот сохранить её в несжатом виде или в loseless-сжатом виде на HDD у меня не получилось. Ни с помощью CPU (кодек x264 c ключами qp=0 и/или crf=0 и с сумасшедшим битрейтом), ни с помощью Nvidia NVENC-сжатия в режиме "loseless". Всё равно в файле мыло.
Не знаю, может быть здесь тоже всё дело в RGB24/YUY2. Получив результат по-простому в virtualdub, разборки с OBS classic мне уже не так интересны.