LINUX.ORG.RU

Пересжатие H264 с потерей кадров

 , , ,


0

3

Приветствую.

Опять продолжение темы Запись сырого h264

Теоретический подсчет показал, что в сравнении с raw записью 1920х1080 MJPEG создающую нагрузку на носитель где то 1.2 Мб/c при 5 фпс, такая же запись H264 при 30 фпс создает поток где то 0.6 Мб/c, т.е. в принципе уже проверенную пропускную способность по записи укладываюсь, а вот с онлайн стримом вопрос.

Абсолютно точно придется пропускать кадры. Если для мжпег удалось сделать это очень равномерно, т.к. из очереди std::deque всегда брался для пересжатия из мжпег в х264 только последний кадр, то в случае с h264 нужно занусуть видео поток в канал где то до 2мбит/c, т.е. декодирование->масштабирование в 2-2.5 раза->сжатие. Все это делается на слабенькой arm пока без доступа к ядру гпу.

Первое что приходит в голову это подряд пересжимать кадры и сбрасывать очередь каждый раз при поступлении I кадра - да камера отдает I кадры каждую секунды и еще 29 P кадров, расстояние не большое, но «рывок» в конце каждой секунды все равно хоть как будет и скорее всего придется отбросить 2/3 кадров (по аналогии с мжпег пересжатием в х264).

Буду благодарен любой идее )

★★★

Последнее исправление: wolverin (всего исправлений: 1)

Ответ на: комментарий от anonymous

Существенно отличается 640х360, поэтому и есть необоснованное предположение, что китайцы выполняют какое то упрощение при кодировании Р кадров, которым возможно можно воспользоваться.

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

у него задача уменьшить битрейт

что бы пропихнуть непропихуемое

хотя конечно прежде чем заниматься любыми манипуляциями

не плохо изучить характеристики потока

и что там по чем

anonymous
()
Ответ на: комментарий от anonymous

При 1920х1080 И кадр по данным ффпробе весит 150К и 29 штук Р кадров по 15К, т.е. в 2-3 Мбит/с можно просто уменьшив количество кадров впихнуть, если б такое удалось)

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

а я изначально разве не сказала что это не решаемая задача?

но когда хочется поласкать поток

то лучше уж это делать из чего то явно не нужного

да и характеристик потока еще никто не показал

SPS PPS SEI бывают жирные

да не И фрейм то все же

в П фреймах бывают B слайсы

итд

anonymous
()
Ответ на: комментарий от anonymous

Как то без декодирования по кадрам с камеры некоторым удается выполнять поиск движения, что это конкретно и как делается я не знаю, как и про В слайсы, но В кадров нет, как и блоки спс ппс и сеи какие то копейки байт

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

ну вот, начинается, характеристик нет, все дела, так что ты советуешь если информации нет; also sps\pps не бывают жирными, да и предложение разобрать sps\pps и собрать снова, это сотни строчек сишечки которые, чтобы написать, надо раскурить спеку h264 досконально, по тсу тут не заметно, но для него это задача длинной во всю жизнь, он высокоуровневое api avcodec всунул\высунул осваивал год

anonymous
()
Ответ на: комментарий от anonymous

он хочет что то делать

вот я ему совет и даю

то что это в моем видении смысла нет он слушать не хочет

и не только меня

ну вот и пусть занимается ремуксом стрима

задачу не сделает

но чему то научится

anonymous
()

Смотри, сколько времени у тебя тратится на декодирование стрима? h264 как бы сделан так, что бы декодироваться быстрее и проще, чем сжиматься. Что если распаковать, а потом уже расжатые каждры прореживать дальше по пайплайну.

Ну и нужно смотреть и использовать аппаратный кодек. На слабом ARM/aarch64 без этого никуда.

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

пока тесты показали что просто декодер потребляет 3/4 цпу и выдает по данным ffmpeg где то до 28 кадров - вроде более чем, но увы это лишь одна из задач и кодеру по опыту мне уже известно нужно еще столько же.

аппаратного кодека нет, есть ВОЗМОЖНО в будущем вариант с возможностью аппаратного УСКОРЕНИЯ на GPU Mali (cedrus в ффмпеге), что позволит лишь тупо разгрузить CPU и выдать те же 10-12 фпс (хоть мне этого и за глаза хватает)

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

А что за железо? Мы просто кодировщик используем на Khadas VIM3, но ручками, не из ffmpeg, просто на уровне библиотеки. Там ресурса хватает за глаза и за уши. Но и плата дорогая и, относительно, мощная.

Просто же раскодировать с пропусками, такая себе идея. Будет картинка вечно битая. А вот на кодирование ты несжатые фреймы вполне можешь выплёвывать уже с пропусками нужными. Главное обеспечить монотонный FPS, ну что бы пропуски были ±одинаковые по числу меж кадрами.

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

железка NanoPi Neo Core, рубля 2-3 стоит, из мжпег в х264 на цпу пережать 1920х1080 удалось вполне в смотрибельном качестве, да тоже либы использую

про раскодирование с пропусками - есть ни на чем не основанное предположение что с камеры идут Р кадры связанные только с И кадром потому что ну не верю я, что люто дешевая камера (те же 3 рубля) способна выдавать 30фпс при 2мп или 60 фпс при 1мп, хотя специалисты говорят, что на камерах просто используется аппаратный кодер (не ускоритель, а именно кодек) на одном кристалле и в купе с дешевым процессором общего назначения дает дешевую камеру.

кхадас видел в сборке для распознавания номеров машин с принудительным охлаждением, а у нас даже радиатор на чип не ставился поначалу )

wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 2)
Ответ на: комментарий от wolverin

что на камерах просто используется аппаратный кодер

Именно так. Часто ещё и функционально очень ограниченный, например, только базовый профиль и так далее. Обычно в составе специализированного SoC, ну или нет. Возьми те же чипы Cypress FX3: там проц относительно слабый, но есть параллельный 32 битный интерфейс на 100Mhz, который очень удачно может класть данные в USB минуя CPU, так что 4K30 можно прокачать в YUV. Соответственно, если у кодека есть выход параллельный, то вполне можно в такую схему завернуть. На FX2 интерфейс беднее, но тоже можно много чего вытянуть.

кхадас видел в сборке для распознавания номеров машин с принудительным охлаждением, а у нас даже радиатор на чип не ставился поначалу )

Он просто люто отключает CPU по перегреву…

Ладно, отвлеклись.

про раскодирование с пропусками - есть ни на чем не основанное предположение что с камеры идут Р кадры связанные только с И кадром

Вот тут нужно снять поток и проанализировать его. Но.. ЕМНИП, каждый последующий же P кадр может содержать как независимые макроблоки, так и отсылки на предыдущие I и P кадры. Т.е. артефакты будут гарантированно. А если добавить B кадры, то каша обеспечена.

В общем, нужно нацелится на ускорение декодирования и оптимизацию этого процесса. Камера определённая? Можно её заставить отдавать меньший FPS? А можно заставить её отдавать несжатый YUV?

Далее:

NanoPi Neo Core

Судя по описанию, там Allwinner H3, а если верить, то декодер h264 у него есть. Ну и далее:

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

да это все видел уж с пару лет назад, но там проблема в том, что либо это уже очень все устарело по отношению к тому же ффмпегу и с текущими версиями не дружит, либо вообще нет программной реализации поддержки (возможно только я не нашел), в дереве устройств для своей железки я уже корректно выделил DMA для ускорения на GPU Mali или как там оно зовется, но пока до использования в своем бинарнике не дошел хотя бы используя отреверсированный вариант от ффмпега с цедрусом.

зы. В кадров нет.

wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 1)
Ответ на: комментарий от wolverin

На ffmpeg даже не смотреть, разве что как интерфейс к v4l2. Поискать, как кодек самому запустить, либой или что-то вроде того.

Я не вижу, как, даже в отсутствие B кадров, сделать прореживание и не получить артефакты.

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

ну полноте наговаривать то, 40-50% удалось сравнительно безболезненно выкинуть входящих байт, хоть и в конце все равно пересжать пришлось.

wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 1)
Ответ на: комментарий от hatred

Возможно как то так

https://securtv.ru/presscenter/materials/osobennosti-nastroyki-kodirovaniya-v-videoregistratorakh-dahua.html

Реализация виртуальной технологии I-кадра гарантирует, что определённый P-кадр может назначить I-кадр как ближайший опорный кадр, не учитывая с 1-го по 4-й P-кадр (на рисунке 5-й P-кадр ссылается только на 0-й I-кадр), таким образом, он становиться, как бы, 1-м кадром для следующих за ним P-кадрами.

wolverin ★★★
() автор топика
Последнее исправление: wolverin (всего исправлений: 2)
Ответ на: комментарий от wolverin

Да, но ты как-то должен воздействовать на камеру, что бы получать промежуточные P кадры, которые ссылаются не на предыдущий, а на предыдущий I кадр, даже иллюстрация об этом говорит: https://cdn.securtv.ru/cache/article/3724a08a5052d10fa82f208fea2bfd70.webp

Ну и поток при этом, теоретически, станет жирнее. Эдакий компромисс.

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

) Бох с ним с воздействием, как бы определить, что такое есть во входящих байтах с камеры!? Т.е. что такое «виртуальный И кадр»!?

Кстати ни на чем не основанная статейка пишет, что у китайцев получилось как раз уменьшить поток, за счет того что GOP можно сделать существенно шире в этом случае.

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

как бы определить, что такое есть во входящих байтах с камеры!?

тут нужно залезть в устройство NAL у P-фрейма и посмотреть как задаётся ссылка. Собственно, это, вроде, стандартная функция P фрейма: https://eymenkurdoglu.github.io/2016/07/01/hierp-one.html, собственно, по ссылке твой вопрос:

  1. How does it know which frame is to be used as a reference to decode the current frame?

Т.е. что такое «виртуальный И кадр»!?

Маркетинговый ход. P кадр со ссылкой не на предыдущий, по списку P/I, а на предыдущий I. Плюс с ним же, скорее всего, ещё передают и SPS/PPS.

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

тут еще интересной ссылкой поделились https://stackoverflow.com/questions/32782447/gop-structure-via-ffmpeg

она правда про В кадры, но может такое быть для P кадра тоже актуально если AVPacket.pos обнуляется при росте AVPacket.pts, при этом NALU не содержит IDR среза - то это и есть «вируальный И кадр»!?

Нннада проверить…

wolverin ★★★
() автор топика
18 июля 2024 г.