Есть скажем видео поток резолюцией 320х240, передача кадр за кадром (т.д. progressive).
Нужно его выводить на выход как interlaced (подается на вход стандартного TV video encoderа).
Есть намерение не ударяться в de-interlacing в полной мере в целях сохранения ресурсов системы по минимуму, а просто передавать входной поток как он есть на вход encoderа генерируя соотв. синхронизацию как буд-то передаются не цельные кадры а fields т.е. encoder будет воспринимать входной поток как interlaced и каждая пара входных кадров будет им интрепретироваться как первый и второй field одного кадра соответственно и ессно кадровая частота на выходе будет в 2 раза меньше входной (это OK). Ессно, перед этим будет делаться интерполяция по горизонтали в 2 раза (получаем inerlaced кадр 640х480 таким образом сохраняя aspect ratio).
Вопрос в том, приведет ли такой путь "interlacingа" с смазу динамических объектов либо смазу изображения когда камера делает panning ?
Нужно ли ожидать заметных артифактов типа упомянутого выше вследствии такого подхода относительно стандартного interlacingа ? (стандартный interlacing подразумевает сохранение в памяти первого кадра, интреполяция по вертикали в 2 раза получая 480 строк и вывод их чет/нечет как при обычном interlace) ?

Что думаем ?

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

Спасибо за мнение.
SECAMа не подразумеватеся, будут PAL может быть и NTSC.
Да, насчет артифакта интерполяции по горизонтали - это-то понятно, но уровнем размазывания действительно можно управлять (возможно пропуская через HPF), думаю это не будет камнем преткновения.
Мне интуитивно кажется что смаз будет результатом попытки соединить четнные/нечетные строки одного и того-же выходного кадра строками 2х последовательных входных кадров...пока не дохиливаю почему такая ситуация не может дать смаза на диамическом изображении....
Кстати, в моей аппликации цвет особой роли не играет (только как OSD), основная инфа картинки - ч/б, т.е. gray scale...

Смаз может появиться только если перепутать синхру на выходе и устроить выходной кадр из полей двух входных кадров, а не из сдвоенных строк одного.

Дык речь то как раз и идет о получении выходного кадра из двух смежных входных...(четное поле выходного = 1ый входной кадр, нечетное поле того-же выходного = 2ой входной кадр)

"Смаз" однозначно в этом случае будет. И уровень этого "смаза" будет напрямую определяться скоростью изменения сюжета или движения камеры. Естественно, что если сюжет меняется очень редко или очень медленно, то наверно можно на это дело "забить".

А почему бы не интерполировать исходные кадры, как по горизонтали, так и по вертикали?

А еще лучше проверить в "живую" все варианты на реальных кадрах и уже после этого принимать решения.

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

"Другой подход" который я упоминал в своей теме как раз и пердполагает интерполирование и строк (т.е. и по вертикали) таким образом получая целый выходной кадр из одного входного). Проблема в том что в таком случае процессинг будет гораздо более интенсивен, и ресурсы памяты нужны будут гораздо более сереьзные чем хотелось-бы...
Проблема еще в том что все это должно делаться в FPGA ибо сама система уже существует но блок composite out в ней реаялизован неправильно и не работает как надо. Моя задача его переделать внося как можно меньше существенных изменений в дизайн. Конечно, если-бы в моем распоряжении был DSP - было-бы проще, но увы, все что есть - FPGA и видмо нужно будет SRAM...