LINUX.ORG.RU

История изменений

Исправление hatred, (текущая версия) :

Если честно, малость не понял логику даже с деком. Я правильно понимаю, что у вас на всех потребителей - одна очередь? И каждый потребитель берёт только то, что лежит сверху?

Если да, то зачем тогда вообще очередь? Двойной-тройной буффер на кадры и всё.

В случае h264. Как минимум можно ничего не класть в очередь если кадр не I (ну или нет PPS пока). И оперировать не одним кадром, а пакетом, равным длине группы (GOP), потому как если ты воткнёшься в середину, то без I и предыдущих/следующих кадров всё равно раскодировать не сможешь нормально. Либо, если артефакты допустимы, то хранить текущий кадр и ближайший I кадр.

Но я бы использовал свою очередь для каждого потребителя. А потом бы смотрел по месту узкие места.

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

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

Ну а что бы всё успевалось: тюнить. vtune в зубы или hotspot/perf и командочку chrt за пазуху.

UPD прочитал про «слабый арм», про vtune тогда забудь :) про hotspot и perf помни.

Исходная версия hatred, :

Если честно, малость не понял логику даже с деком. Я правильно понимаю, что у вас на всех потребителей - одна очередь? И каждый потребитель берёт только то, что лежит сверху?

Если да, то зачем тогда вообще очередь? Двойной-тройной буффер на кадры и всё.

В случае h264. Как минимум можно ничего не класть в очередь если кадр не I (ну или нет PPS пока). И оперировать не одним кадром, а пакетом, равным длине группы (GOP), потому как если ты воткнёшься в середину, то без I и предыдущих/следующих кадров всё равно раскодировать не сможешь нормально. Либо, если артефакты допустимы, то хранить текущий кадр и ближайший I кадр.

Но я бы использовал свою очередь для каждого потребителя. А потом бы смотрел по месту узкие места.

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

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

Ну а что бы всё успевалось: тюнить. vtune в зубы или hotspot/perf и командочку chrt за пазуху.