LINUX.ORG.RU

[C] Выбор структуры данных для видеофильтров

 


0

1

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

Вариант 1:

typedef struct image_s
    {
    int w;
    int h;
    int sz_yy;
    int sz_buf;
    uint8_t *buf;
    uint8_t *yy;
    uint8_t *cb;
    uint8_t *cr;
    } image_t;

Вариант 2:

typedef struct pixel_s
    {
    uint8_t yy;
    uint8_t cb;
    uint8_t cr;
    } pixel_t;

typedef struct image_s
    {
    int w;
    int h;
    int px_count;
    int px_sz;
    pixel_t *px;
    } image_t;

Первый вариант удобнее импортировать/экспортировать из планарных форматов (yv12, yuv420p) и обрабатывать покомпонентными фильтрами.

Второй вариант удобнее обрабатывать попиксельными фильтрами, и использовать при этом код типа такого:

out->px[xy]=in->px[xy];
вместо такого:
out->yy[xy]=in->yy[xy];
out->cb[xy]=in->cb[xy];
out->cr[xy]=in->cr[xy];

Есть какие-нибудь аргументы, чтобы остановиться на одном из вариантов?

★★

на вкус и цвет все фломастеры разные

второй вариант имо предпочтительней ибо даёт больше абстракции. к тому же экспорт/импорт делается один раз, а вот фильтры гораздо чаще. ну и во втором варианте орудуеш одной структурой вместо четырёх. kiss

я бы его вообще в список завернул и избавился от индексов. (но это зависит от алгоритма: это если надо просто обработать всё, а не конкретно какой-то один пиксель)

beastie ★★★★★
()
Ответ на: на вкус и цвет все фломастеры разные от beastie

Импорт/экспорт пишется один раз, но работает всегда.

Для примитивных фильтров время импорта/экспорта может занимать от 50% до 90% общего времени обработки.

Для сложных фильтров это уже не важно, но хочется общие тормоза свести к минимуму.

cdslow ★★
() автор топика
Ответ на: комментарий от cdslow

Структуры по типу хранимой информации в принципе совпадают, т.о. можно «отмакросить»/отврапить все операции доступа в этим структурам и в живом коде использовать унифицированные фции и макросы.

Jetty ★★★★★
()

Второй вариант проще в некотором смысле, но если интересует скорость, то первый не хуже в попиксельных операциях, за исключением плохих случаев таких как 1-way кэш и кратное его размеру расстояние между массивами.

amaora ★★
()
Ответ на: комментарий от Jetty

> в живом коде использовать унифицированные фции и макросы

Понятно. Особого смысла в таких макросах не вижу, только если портировать готовые фильтры под другую внутреннюю структуру, а этот вопрос пока не стоит.

Хотя, может быть стоит выбрать структуру, под которую проще портировать имеющиеся фильтры. Ну тут опять разброд — frei0r, например, использует пиксельную структуру, а transcode планарную.

cdslow ★★
() автор топика
Ответ на: комментарий от amaora

> если интересует скорость, то первый не хуже в попиксельных операциях

Итак, если важнее скорость — выбираем первый вариант, который быстрее для импорта/экспорта и компонентных фильтров, и не хуже (в общем случае) для пиксельных фильтров.

Если предпочтительнее удобство написания пиксельных фильтров, выбираем второй вариант, с некоторым снижением скорости.

В такой постановке я больше склоняюсь к первому варианту.

cdslow ★★
() автор топика
Ответ на: комментарий от Jetty

Цель — сделать фреймворк, ориентированный в первую очередь на лёгкость написания (и возможно портирования) под него фильтров, но, по возможности, не вносить тормоза там, где этого можно избежать.

cdslow ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.