sasamy 7 16 июня Опубликовано 16 июня (изменено) · Жалоба On 6/16/2024 at 12:25 PM, repstosw said: На ПК с 3 ГГц в один поток с помощью SSE2 картинка 160x240 жмется с 900 - 1200 FPS. Надеюсь на T113-s3 скорость будет не хуже 10 FPS 😂. не до такой степени - для сравнения x264 + linux на t113, тестовый файл и команда запуска взяты с гитхаба https://github.com/lieff/minih264 однопоток Quote # x264 -I 30 --profile baseline --preset veryfast --tune zerolatency -b 0 -r 1 --qp 33 --ipratio 1.0 --qcomp 1.0 -o x264.264 --fps 30 foreman.cif --input-res 352x288 --slices 1 --threads 1 raw [info]: 352x288p 0:0 @ 30/1 fps (cfr) x264 [info]: using cpu capabilities: ARMv6 NEON x264 [info]: profile Constrained Baseline, level 1.3, 4:2:0, 8-bit x264 [info]: frame I:10 Avg QP:33.00 size: 5879 x264 [info]: frame P:290 Avg QP:33.00 size: 895 x264 [info]: mb I I16..4: 36.3% 0.0% 63.7% x264 [info]: mb P I16..4: 2.5% 0.0% 1.1% P16..4: 31.8% 12.1% 2.6% 0.0% 0.0% skip:50.0% x264 [info]: coded y,uvDC,uvAC intra: 51.3% 36.3% 13.7% inter: 9.4% 4.2% 0.3% x264 [info]: i16 v,h,dc,p: 36% 26% 26% 13% x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 18% 24% 2% 15% 6% 7% 3% 6% x264 [info]: i8c dc,h,v,p: 68% 13% 15% 3% x264 [info]: kb/s:254.66 encoded 300 frames, 48.25 fps, 254.66 kb/s On 6/16/2024 at 4:18 PM, repstosw said: В билд-скриптах указан Cortex-A8. Надеюсь под A7 скомпиляется. Если нет - попробую переделать. ничего переделывать не пришлось в x264 - он тоже для cortex-a8 оптимизирован Quote buildroot-2022.08.3-sk-t113/output/host/bin/arm-none-linux-gnueabihf-gcc -Wno-maybe-uninitialized -Wshadow -O3 -ffast-math -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1 -Wall -I. -I. -std=gnu99 -D_GNU_SOURCE -mcpu=cortex-a8 -mfpu=neon -fPIC -fomit-frame-pointer -fno-tree-vectorize -fvisibility=hidden -c x264.c -o x264.o x264.264 Изменено 16 июня пользователем sasamy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 40 16 июня Опубликовано 16 июня · Жалоба 10 минут назад, sasamy сказал: 160x240 жмется с 900 - 1200 FPS 11 минут назад, sasamy сказал: input-res 352x288 11 минут назад, sasamy сказал: 48.25 fps Ну если первую картинку взять такого же разрешения, то фпс там упадет раза в 2, с учетом 1ГГц против 3 еще в 3 раза, т.е. получаем 120-150, ну все-таки комповый проц круче раза в 3 как минимум при всех тех же вводных))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 17 июня Опубликовано 17 июня (изменено) · Жалоба 10 hours ago, sasamy said: не до такой степени - для сравнения x264 + linux на t113, тестовый файл и команда запуска взяты с гитхаба https://github.com/lieff/minih264 однопоток Я говорил про картинку своего разрешения: 160x240 10 hours ago, sasamy said: ничего переделывать не пришлось в x264 - он тоже для cortex-a8 оптимизирован T113-s3 - это cortex-a7. По всей строгости нужно исправить параметры сборки. Чтобы не было сюрпризов. 10 hours ago, mantech said: Ну если первую картинку взять такого же разрешения, то фпс там упадет раза в 2, с учетом 1ГГц против 3 еще в 3 раза, т.е. получаем 120-150, ну все-таки комповый проц круче раза в 3 как минимум при всех тех же вводных))) Выше я говорил, что до 1200 FPS это с картинкой 160x240. С картинкой 80x120 вообще - до 3300 FPS Это на ПК 3ГГц под виндой с включенным SSE2: gcc -Ofast -msse2 -DNDEBUG -fomit-frame-pointer -ftree-vectorize -fno-math-errno -fmax-errors=1 -c minih264e_test.c gcc -o minih264e_test.exe minih264e_test.o Как будет на T113, пока не пробовал. Пока занимаюсь радиотрактом. Плюс, как я говорил ранее -нужны будут несколько итераций кодировки - с проверкой на влезаемость в буфер фиксиованного размера - для передачи данных. У меня адаптивный алгоритм качества кодирования: вначале качество повышается - растёт с каждым кадром - от минимума к максимуму через определенный шаг. Если сжатый результат не влезает - качество минус шаг и перекодировка, если влезло - следующий кадр - качество растёт на плюс шаг. В итоге качество постоянно меняется исходя из картинки и критерия влезаемости в буфер. И да, H264 нужно использовать в режиме - когда каждый кадр ключевой (GOP=1). Потому что при разрушении одного кадра - не должны страдать следующие за ним. Сжатия в этом случе меньше, но всё равно больше чем у JPEG как минимум в 2 раза (субъективно визуально при том же качестве картинки). Изменено 17 июня пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 17 июня Опубликовано 17 июня (изменено) · Жалоба On 6/13/2024 at 10:51 PM, repstosw said: Дистанция устойчивой связи 160 метров. 4GFSK 20 hours ago, repstosw said: Дальность устойчивой связи 203 метра. 2GFSK Вот тут в статье написано, что переход к 4GFSK хоть и сужает полосу в 2 раза (выигрыш в чутье +3дБ), но переход к 4-позиционной модуляции - на 5 дБ гробится из-за разделения символов. При условии, если индекс модуляции(по внешней девиации частоты) тот же - 1. https://siliconlabs.my.site.com/community/s/article/4gfsk-vs-2gfsk-sensitivity-on-si446x?language=en_US В итоге возврат к 2GFSK - это выигрыш на : 5-3 = 2 дБ. А теперь считаем: 160 * SQRT( 10^(2/10) ) = 1.259x 160 = 201 метр. Что практически совпало с измеренной на практике дальностью. Итого, отказ от 4GFSK дал выигрыш в чутье +2 дБ или по дальности увеличение на +26%. AT86RF215 уделывают эти Si4463, за счёт более лучшей чувствительности: на 500 kbps заявлено чутьё -108 дБм для OQPSK модуляции! Si4463 даёт только -97 дБм для 2GFSK 500 kbps df=+/-250 kHz, тоесть на 11 дБ хуже! Из-за более качественного детектора в том числе. Теоретически выигрыш в дальности от применения AT86RF215 будет: SQRT( 10^(11/10) ) = 3.54x Изменено 17 июня пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 18 июня Опубликовано 18 июня (изменено) · Жалоба К вопросу дальности связи. Эфир - помойка. Потенциал приёмника не раскрыт: -97 дБм < -82.6 дБм. Для нормального приема нужен сигнал превышающий шумы как минимум на 10 дБ: -73 дБм. Изменено 18 июня пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 40 18 июня Опубликовано 18 июня · Жалоба 1 час назад, repstosw сказал: К вопросу дальности связи. Эфир - помойка. Так вы же сами выбрали такой диапазон, 433 - это помойка, как в свое время стал 27МГц... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 18 июня Опубликовано 18 июня (изменено) · Жалоба 1 hour ago, mantech said: Так вы же сами выбрали такой диапазон, 433 - это помойка, как в свое время стал 27МГц... Да везде помойка ))) Просмотрел полосу частот от 50 МГц до 3000 МГц. Много больших помоек в диапазоне 140-160 МГц, 420 - 510 МГц, потом есть на 840 - 880 МГц, потом GSM 900, GSM1800, WiFi 2.4 GHz - куча стволов торчит. Выбрать что-то менее шумное - мало представляется возможным. Разве что на 8xx МГц кое-где есть на 10 дБ меньше шума. Как раз одна из полос частот, отведённая для детских радиопереговорных устройств в РФ ))) Соваться в неизведанные частоты не хочется, чтобы не получить по шапке. ))) Остаётся либо повышать мощность или более эффективнее - использовать направленные антенны. Изменено 18 июня пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 40 18 июня Опубликовано 18 июня · Жалоба 1 час назад, repstosw сказал: использовать направленные антенны. Для носимых устройств это не вариант вообще.. 1 час назад, repstosw сказал: Соваться в неизведанные частоты не хочется, чтобы не получить по шапке. ))) Ну тут да, особенно с мощностью больше 1Вт Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 18 июня Опубликовано 18 июня (изменено) · Жалоба On 6/17/2024 at 11:24 AM, repstosw said: И да, H264 нужно использовать в режиме - когда каждый кадр ключевой (GOP=1). Потому что при разрушении одного кадра - не должны страдать следующие за ним. И всё-же максимум сжатия с этим H264 выходит, исключительно, когда используются не только ключевые кадры. Для GOP=10 (каждый 10-й ключевой кадр, остальные производные от него) - выходит 9 кадров практически занимают мало места. Для 53 кбит/с видео 160x240 это будет выглядеть таким образом: Десятка смежных фреймов не превышает 6617 байт. Фул-дуплекс ещё, поэтому в обе стороны скорость : 53*2 = 106 кбит/c. Остальное - на звук + FEC + CRC. Впихивается в 125 кбит/c. Теоретический выигрыш в дальности: SQRT(824.5kHz/197.87kHz) = 2.04x Тоесть: 203 м * 2,04 = 414 метров. Пример видео 160x240 удовлетворяющее этим условиям (сгенерированное модифицированной версией minih264e_test.c с контролем размера фреймов: out.264 С учётом того, что в 90% случаев будет исключительно "говорящая голова", то конфигурация имеет право на существование. Изменено 18 июня пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 40 18 июня Опубликовано 18 июня · Жалоба 1 час назад, repstosw сказал: И всё-же максимум сжатия с этим H264 выходит, исключительно, когда используются не только ключевые кадры. Что вполне логично, т.к. так и было изначально задумано... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 18 июня Опубликовано 18 июня (изменено) · Жалоба 7 hours ago, mantech said: Что вполне логично, т.к. так и было изначально задумано.. Зато не очень удобно для передачи данных. И увеличивает задержку на приёмной стороне. Это надо закодировать пачку фреймов, проверить, лезет ли она в буфер. Если не лезет, то перекодировать эту пачку повторно, снизив качество. Если кодировать по одному фрейму, то выходит большой шум визуально при смене кадров, из-за того что выделенный размер строго на один фрейм. А так получается - львиную долю жрёт ключевой кадр, а следующие за ним - намного меньше, что и даёт сжатие более эффективным, но более неудобным для потоковой передачи данных. Есть ещё режим кодирования по битрейту с использованием VBV буфера. Но сколько бы не ставил битрейт, кодер так и норовит вылезти за этот предел, приходится занижать битрейт на 20-30%, иначе результат кодирования не лезет в буфер. Смысл тогда указывать битрейт - не понятен. И вообще, почему нельзя было сделать режим кодирования, при котором серия фреймов гарантированно влезала в конкретный буфер. Вот в аудио-кодеке CELT есть такой режим - исходя из параметров разрядности, семплирования, длины фрейма и коэфф. сжатия - можно расчитать размер выходного фрейма, который константа. Формализую задачу: Необходимо передавать и принимать (full-duplex) два видео с размером кадра 160x240 10 FPS на расстояние 1 км, используя Omni-антенны на высоте не более 1,5 м от земли, по прямой. Изменено 18 июня пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 40 19 июня Опубликовано 19 июня · Жалоба 6 часов назад, repstosw сказал: И вообще, почему нельзя было сделать режим кодирования, при котором серия фреймов гарантированно влезала в конкретный буфер. Наверно можно, но потеряется эффективность сжатия. Ну и если нужно по максимуму корректно передать инфу получателю, то не избежать использования ЕСС, ибо почти все в радиосвязи на них завязано... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 19 июня Опубликовано 19 июня (изменено) · Жалоба 17 hours ago, repstosw said: Впихивается в 125 кбит/c. Теоретический выигрыш в дальности: SQRT(824.5kHz/197.87kHz) = 2.04x Тоесть: 203 м * 2,04 = 414 метров. Испытан новый конфиг: 2FSK, 125 кбит/c, девиация 31,25 кГц (индекс модуляции 0.5, MSK), полоса приёмника около 200 кГц. Дальность устойчивой связи 327 метров. Дальше трасса поворачивается, нет прямой видимости, связь с перебоями. И вообще, проблема за городом найти кусок прямой ровной трассы без перепадов и каких-либо строительных объектов по бокам (если стоять на дороге и никуда не подниматься). 1 hour ago, mantech said: Наверно можно, но потеряется эффективность сжатия. Ну и если нужно по максимуму корректно передать инфу получателю, то не избежать использования ЕСС, ибо почти все в радиосвязи на них завязано... А при чём тут ECC? Зачем он упомянут? Если в контексте того, что на него тоже надо резервировать полосу - так это учтено уже: у меня на FEC отводится до 20% от всего пакета (в расчёт битрейта видео идёт только свободная от FEC часть буфера). Изменено 19 июня пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 40 19 июня Опубликовано 19 июня (изменено) · Жалоба 38 минут назад, repstosw сказал: А при чём тут ECC? Зачем он упомянут? 38 минут назад, repstosw сказал: на FEC отводится до 20% от всего пакета Ну если уже используете, тогда уже ни при чем))) 38 минут назад, repstosw сказал: И вообще, проблема за городом найти кусок прямой ровной трассы без перепадов и каких-либо строительных объектов по бокам Что у вас там за местность такая, я в своем Кирове и в городе 500м по прямой найду без труда))) Улицы довольно прямые, да и река есть мост в смысле)) Изменено 19 июня пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 19 июня Опубликовано 19 июня (изменено) · Жалоба 24 minutes ago, mantech said: Улицы довольно прямые, да и река есть мост в смысле)) Река и мост - дадут сразу выигрыш в 5 раз как минимум. Потому что высоты и водная поверхность. Нужен участок прямой дороги, которая земля или асфальт, без всяких высот и водных поверхностей. Изменено 19 июня пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
