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

День тупняка сегодня…

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

char * services[] = {(char*)"1", (char*)"22", (char*)"333"};

но что бы можно было собрать его из std::string по типу

std::string services[] = {"1"+var1, var2+"22", "333" + var3 + "333"};

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

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

Как бы вот такое провернуть, чтобы можно было объявить переменную как const даже для методов класса с учетом того, что в конструкторе нужно сначала проинициализировать другие переменные, прежде чем посчитать const ?

Т.е. что то вроде

class X
{
private:
  T * ptr;
public:
  const std::string city;
  X ()
  {
     ...
     ptr->start();
     city = ptr->CalcCity();
  }
}

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

Построено у меня взаимодействие с тысячами железок через mqtt сервер, из всего многообразия «сообщений» приходящих через либу в типе char * msg есть пересылка снимков в jpeg, которые тоже приходят одномоментно тысячами штук на свой сервис, весь «парсинг заголовка сообщения» на этом сервисе выполнял обычным strncmp и для жпега это выглядит как

if (!strncmp(msg, "\xFF\xD8\xFF", 3)) { ... }
else if ...

как я понимаю memcmp быстрее strncmp, тем более мне нужно сравнить байты а не строки и понятно что так тоже как минимум компилируется

if (!memcmp(msg, "\xFF\xD8\xFF", 3)) { ... }

а можно БЕЗ объявления переменной выполнять сравнение набора байт любой длины?

мне такой в голову пришел перл, но что то сомнительна его производительность )

if (memcmp(msg, std::array<uint8_t,3>({0xFF, 0xD8, 0xFF}).data(), 3) == 0)

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

В продолжении темы ) Как обратиться к std::shared_ptr<void> ???

Хотелось бы из boost сделать forward declaration для boost::property_tree::ptree в классе по типу

class CJSON
{
private:
    boost::property_tree::ptree  pt;

public:
    CJSON(const char * msg, const int lmsg);
};

чтобы не всплывало ничего через хедеры в других местах.

Возможно такое??? Вариант моего нерабочего тупизма (

namespace boost {
    namespace property_tree {
        class basic_ptree;
        typedef basic_ptree<std::string, std::string> ptree;
    }
}

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

Где раздобыть? Что то помыкался в гугле не могу живых зеркал найти с этой версией.

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

Есть некая идея у коллег - чтобы ничего не кодить - внутри vpn подключить 100500 сетевых дисков от openipc к серверу и забирать с них выборочно поштучно файлы, коих где то 7000 штук.

Есть какие то ограничения именно по количеству если не учитывать пока вопрос производительности такой затеи??? Насколько знаю для того же nfs это ограничение на количество портов для клиента, где в данном случае клиентом будет железный сервер debian, а нфс сервером openipc.

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

Есть хитрожопая надежда не писать велосипед в части реализации SRTP для сервера WebRTC, который бы полноценно работал БЕЗ промежуточного прокси сервера.

https://ffmpeg.org/ffmpeg-protocols.html#srtp Может кто знает прокатит это?

Или без вариантов нужно RTP пакеты пропускать через libsrtp?

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

Есть usb камера

# v4l2-ctl --all -d 0
Driver Info (not using libv4l2):
    Driver name   : uvcvideo
    Card type     : CS-USB-IMX307: UVC Camera
    Bus info      : usb-1c1d000.usb-1
    Driver version: 4.14.111
    Capabilities  : 0x84200001
        Video Capture
        Streaming
        Extended Pix Format
        Device Capabilities
    Device Caps   : 0x04200001
        Video Capture
        Streaming
        Extended Pix Format
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
    Width/Height      : 1920/1080
    Pixel Format      : 'H264'
    Field             : None
    Bytes per Line    : 3840
    Size Image        : 4147200
    Colorspace        : sRGB
    Transfer Function : Default
    YCbCr Encoding    : Default
    Quantization      : Default
    Flags             :
Crop Capability Video Capture:
    Bounds      : Left 0, Top 0, Width 1920, Height 1080
    Default     : Left 0, Top 0, Width 1920, Height 1080
    Pixel Aspect: 1/1
Selection: crop_default, Left 0, Top 0, Width 1920, Height 1080
Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1080
Streaming Parameters Video Capture:
    Capabilities     : timeperframe
    Frames per second: 30.000 (30/1)
    Read buffers     : 0
                     brightness (int)    : min=0 max=100 step=1 default=50 value=50
                       contrast (int)    : min=0 max=100 step=1 default=50 value=50
                     saturation (int)    : min=0 max=100 step=1 default=50 value=50
                            hue (int)    : min=0 max=100 step=1 default=50 value=50
error 5 getting ctrl White Balance Temperature, Auto

с такими потоками

# v4l2-ctl --list-formats-ext -d 0
ioctl: VIDIOC_ENUM_FMT
    Index       : 0
    Type        : Video Capture
    Pixel Format: 'YUYV'
    Name        : YUYV 4:2:2
        Size: Discrete 640x360
         Interval: Discrete 0.033s (30.000 fps)

    Index       : 1
    Type        : Video Capture
    Pixel Format: 'MJPG' (compressed)
    Name        : Motion-JPEG
        Size: Discrete 640x360
         Interval: Discrete 0.033s (30.000 fps)
        Size: Discrete 1280x720
         Interval: Discrete 0.033s (30.000 fps)
        Size: Discrete 1920x1080
         Interval: Discrete 0.033s (30.000 fps)

    Index       : 2
    Type        : Video Capture
    Pixel Format: 'H264' (compressed)
    Name        : H.264
        Size: Discrete 640x360
         Interval: Discrete 0.033s (30.000 fps)
        Size: Discrete 1280x720
         Interval: Discrete 0.033s (30.000 fps)
        Size: Discrete 1920x1080
         Interval: Discrete 0.033s (30.000 fps)

есть ффмпег с поддержкой декодера на вдпау

# ./ffmpeg-ubrv -codecs | grep vdpau | grep 264
ffmpeg version git-2015-01-22-f86a076 Copyright (c) 2000-2014 the FFmpeg developers
  built on Jul 18 2024 12:09:53 with gcc 5.4.0 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.12) 20160609
  configuration: --prefix=/usr --enable-nonfree --enable-gpl --enable-version3 --enable-vdpau --enable-libx264 --enable-libv4l2 --disable-doc
  libavutil      54.  6.100 / 54.  6.100
  libavcodec     56.  0.101 / 56.  0.101
  libavformat    56.  2.100 / 56.  2.100
  libavdevice    56.  0.100 / 56.  0.100
  libavfilter     5.  0.102 /  5.  0.102
  libswscale      3.  0.100 /  3.  0.100
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  0.100 / 53.  0.100
 DEV.LS h264                 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_vdpau ) (encoders: libx264 libx264rgb cedrus264 )

пытаюсь проверить декодер как

# VDPAU_DRIVER=sunxi ./ffmpeg-ubrv -f v4l2 -input_format h264 -video_size 1920x1080 -pix_fmt yuyv422 -c:v h264_vdpau -i /dev/video0 -f null /dev/null

при поступлении опорного кадра падает с ошибкой

[video4linux2,v4l2 @ 0xf4c480] decoding for stream 0 failed
[video4linux2,v4l2 @ 0xf4c480] Could not find codec parameters for stream 0 (Video: h264 (Baseline), 1920x1080, -5 kb/s): unspecified pixel format
Consider increasing the value for the 'analyzeduration' and 'probesize' options
/dev/video0: could not find codec parameters
Input #0, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (Baseline), 1920x1080, -5 kb/s, 30 fps, 30 tbr, 1000k tbn, 2000k tbc
[buffer @ 0x1157c00] Unable to parse option value "-1" as pixel format
    Last message repeated 1 times
[buffer @ 0x1157c00] Error setting option pix_fmt to value -1.
[graph 0 input from stream 0:0 @ 0xf45620] Error applying options to the filter.
Error opening filters!

к слову использую

# ls -l /usr/lib/arm-linux-gnueabihf/vdpau/libvdpau_sunxi.so*
lrwxrwxrwx 1 root root 19 Jul 19 09:47 /usr/lib/arm-linux-gnueabihf/vdpau/libvdpau_sunxi.so -> libvdpau_sunxi.so.1
lrwxrwxrwx 1 root root 28 Jul 19 08:40 /usr/lib/arm-linux-gnueabihf/vdpau/libvdpau_sunxi.so.1 -> /home/pi/libvdpau_sunxi.so.1

но запрос не показывает какой либой пользуется

# vdpauinfo
vdpauinfo: cannot connect to X server

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

Вдрух кто знает - выполняю пересжатие из мжпег или х264 снова в х264, затем через локальный интерфейс отправляю в свой же rtsp сервер - никак не удается понять, почему при остановке стрима и его запуске вижу 1-2 секунды предыдущего стрима.

Все делаю через api ффмпега.

Думал кодер нужно сбрасывать через avcodec_flush_buffers в ответ ошибка Ignoring attempt to flush encoder that doesn't support it, может быть в декодере х264 накопилось - так нет, для мжпег те же 1-2 секунды предыдущих мусорных кадров, попытался сбросить входящий буфер ртсп сервера через avformat_flush(f) толку нет, варианты av_write_frame(f, NULL) avcodec_send_frame(c, NULL) и тп тоже ничего не сбрасывают.

Да важно - на кодер в начале стрима всегда поступает не сжатый кадр с признаками что он ключевой и типом I, поэтому стрим начинается всегда мгновенно, НО откуда то 1-2 секунды от предыдущего ((

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

В продолжении темы

Сцуть - в древней версии ffmpeg есть отреверсированный кодек cedrus для аппаратного УСКОРЕНИЯ кодирования в H264 на SoC.

На этапе старта нуждаюсь в совете - что будет проще и быстрее - поднять старый кодек до версии libav ффмпега хотя бы 5 ветки (его использую) или полностью реализовывать весь функционал кодека в своем коде???

Из опыта имею только поднятие ffserver до 5 ветки и реализация на его базе простого RTSP сервера )

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

В продолжении темы

Напомню - пишу по кольцу с камеры на флешку без файловой системы через буфер fwrite кусками по 256КБ, из за нехватки времени заняться вопросом скачивание архива выполнялось в полурукопашном режиме через открытие отдельного FILE* или дескриптора в отдельном потоке и долгая перекачка по ентернетам.

Пришло время заняться вопросом отдать архив нескольким клиентам одновременно и собсна вопрос - можно ли через уже открытый FILE* и int fd = fileno(FILE*), используя pread со своим смещением в каждом потоке безопасно выполнять выгрузку одного и того же «файла»? или лучше для каждой выгрузки-потока выполнять свой open?

ЗЫ. на старте не знаю сколько будет одновременно читающих потоков.

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

В продолжении темы

Имеется армка 512МБ рам и 512ГБ сд карта.

Суть - для построения журнала видео архива на носителе без файловой системы при прямом проходе (при обратном смещение 1 минута и перечитывается флешка за секунды) флешки выполняю смещение на размер кадра, для поиска нужным мне меток. Все в целом устраивало при перечитывании временных меток пока писал JPEG, который был размером где то 220КБ, но как только начал писать H264 перечитать флешку «вперед» стало проблемой иба кадры в основном около 15КБ.

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

Собсна глобальный вопрос - как бы ускорить чтение с носителя???

Второстепенный - fread vs fseeko какими буферами оперируют если читается фридом условно 20 байт и как его менять? setvbuf почему то чем то вроде setvbuf(pf, NULL, _IOFBF, 32 * 1024 * 1024) никак не влияет на скорость перечитывания носителя

Или может я просто уперся в физическую скорость флешки!?

жизнь боль )

в продолжении темы Как разблокировать одновременно 2 потока?

3 потока - декодер, енкодер и снимков, декодер ждет переключения между 2 декодированными буферами по барьеру и после переключения отпускает семафоры нужных потоков енкодеров, когда их 2 все работает, только становится на 1 больше и avcodec_send_frame потока снимков начинает переодически слать ошибку -22, даже засегфолился уже ((

для примера обработчик потока снимков

int SnapshotEncode(int (*callback)(const char * topic, const uint8_t * buf, int lbuf), const char * topic)
{
    const AVCodec * pCdc = avcodec_find_encoder(AV_CODEC_ID_MJPEG);
    if (!pCdc)
    {
        fprintf(stderr, "ERROR find snapshot encoder for '%s'\n", avcodec_get_name(AV_CODEC_ID_MJPEG));
        return -1;
    }

    struct stEncoder_t * enc = EncoderNew("snapshot");
    if (!enc) return -2;

    int rt = 0;
    AVCodecContext * pCdcCtx = avcodec_alloc_context3(pCdc);
    if (!pCdcCtx)
    {
        PrintErrorAV("alloc snapshot an encoding context", (rt = AVERROR(ENOMEM)));
        return rt;
    }

    pCdcCtx->time_base = DEFAULT_TIME_BASE;
    pCdcCtx->pix_fmt = pCdcCtxInp->pix_fmt;
    pCdcCtx->height = pCdcCtxInp->height;
    pCdcCtx->width = pCdcCtxInp->width;

    if ((rt = avcodec_open2(pCdcCtx, pCdc, NULL)))
    {
        PrintErrorAV("open snapshot encoder", rt);
        goto END;
    }

    AVPacket * pPkt = av_packet_alloc();
    if (!pPkt)
    {
        PrintErrorAV("allocate snapshot AVPacket", (rt = AVERROR(ENOMEM)));
        goto END;
    }

    EncoderRun(enc, 1);
    if ((rt = sem_wait(&enc->sem)) < 0)
        fprintf(stderr, "ERROR lock encoder semaphore: %d %s\n", errno, strerror(errno));

    if (rt)
    {
        EncoderRun(enc, 0);
        pthread_barrier_wait(&stDec.bar);
        goto END;
    }

    if ((rt = avcodec_send_frame(pCdcCtx, stEnc.pFrm)))
        PrintErrorAV("snapshot encode send", rt);
    else if ((rt = avcodec_receive_packet(pCdcCtx, pPkt)))
        PrintErrorAV("snapshot encode receive", rt);

    EncoderRun(enc, 0);
    pthread_barrier_wait(&stDec.bar);

    if (rt == 0) callback(topic, pPkt->data, pPkt->size);

    av_packet_unref(pPkt);

END:
    EncoderFree(enc);
    if (pPkt) av_packet_free(&pPkt);
    if (pCdcCtx) avcodec_free_context(&pCdcCtx);

    return rt;
}

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

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

Вопрос - как бэ из потока декодера запускать сразу 2 потока енкодеров, при этом поток декодера должен ждать завершения обоих???

В идеале бы конешно на С, т.к. сишный модуль этим занимается.

Спасибо за любые идеи )

Приветствую, отдельно потужно постоянных читателей моих тем ))

Требуется реализовать очередную хитро.опую очередь для многопоточной обработки, поступающих с h264 камеры nalu блоков, которые в контексте libav библиотек от ffmpeg будем считать условными кадрами.

Для мжпег камер на базе std::deque получился рабочий вариант - поток чтения берет например с начала индекс выделенного массива под кадры и прочитав в элемент кладет этот индекс с другой стороны очереди. Потоки записи кадров, онлайн трансляции, определения движения и просто запроса снимков делают тоже самое только наибарот к очереди - что позволяет во всех случая получать условно самый свежий кадр и отбрасывать все старье.

Теперича хочется тоже самое но в контексте 264 кодека - т.е. для случая чтения например я бы мог заполнять очередь до поступления И кадра и сразу ее опустошать при его считывании (тем самым гарантируя что в начале очереди всегда ключевой кадр), но вот никак не соображу - а как же «потребители» будут понимать что очередь сброшена и надо начинать читать ее сначала? uint64_t счётчик сброса у всех потоков вести!?

Может многопоточники на плюсах сорентируют какие стандартные алгоритмы для таких вещей используются!?

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

Для проксирования видео с камер используется оборачивание в vpn (хотя это мне кажется не важно, т.к. проблема даже если просто запушить) и затем проксирование через mediamtx (он же rtsp-simple-server).

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

Писал разработчику - отвечает ищи сам, у него все в шоколаде ((

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

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

Пытаюсь разобраться, что происходит между чужими ПО сервера и клиента (не работает сервис после обновления). Сдампил rest обмен, ответ выглядит как

HTTP/1.1 200 OK
Date: Thu, 18 Apr 2024 09:52:54 GMT
Server: Apache/2.4.38 (Debian)
Set-Cookie: PHPSESSID=f0ifisf0j0nc8n662i85uevdv4; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 5980
Connection: close
Content-Type: text/html; charset=UTF-8

...собсна тело...

есть способ увидеть его???

Приветствую all! ))

Итакс продолжаю изучать вопрос RTSP публикация надежна?

Вновь уточню, что требуется послать rtp только при запросе с rtsp сервера.

Поскольку в свое поделие rtsp сервера так же выполняю публикацию подготовленного видео потока (Как забирается RTP поток у сервера RTSP?), чтобы организовать отдельный поток сервиса с очередью через локальный интерфейс с его внешними буферами (все штатными либами ффмпега без заморочек про сдп, временные базы, синхронизации потоков и прочее), то запушил так же штатно на внешний халявный rtsp-simple-server, который выполняет роль видео прокси в чужом проекте (с мыслями его перепроектировать).

И значит в tcpdump такой обмен вижу после установления tcp подключения

- моя утилита
OPTIONS rtsp://имя_внешнего_хоста:слушающий_порт/блаблабла RTSP/1.0
CSeq: 1
User-Agent: Lavf59.25.100

- сервер
RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, ANNOUNCE, SETUP, PLAY, RECORD, PAUSE, GET_PARAMETER, TEARDOWN
Server: gortsplib

затем

- утилита
ANNOUNCE rtsp://имя_внешнего_хоста:слушающий_порт/блаблабла RTSP/1.0
Content-Type: application/sdp
CSeq: 2
User-Agent: Lavf59.25.100
Content-Length: 305

- сервер ответ 0 длины, видимо tcp-ое подтверждение доставки, которое вижу после каждой посылки

затем

- утилита
v=0
o=- 0 0 IN IP4 127.0.0.1
s=No Name
c=IN IP4 адрес_сервера
t=0 0
a=tool:libavformat LIBAVFORMAT_VERSION
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z0LAKNoB4AiflmoCAgKAAAADAIAAAApHjBlQ,aM4NyA==; profile-level-id=42C028
a=control:streamid=0

- сервер
RTSP/1.0 200 OK
CSeq: 2
Server: gortsplib
Session: 545498661

затем

- утилита
SETUP rtsp://имя_внешнего_хоста:слушающий_порт/блаблабла/streamid=0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record
CSeq: 3
User-Agent: Lavf59.25.100
Session: 545498661

- сервер
RTSP/1.0 200 OK
CSeq: 3
Server: gortsplib
Session: 545498661
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

затем

- утилита
RECORD rtsp://имя_внешнего_хоста:слушающий_порт/блаблабла RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent: Lavf59.25.100
Session: 545498661

- сервер
RTSP/1.0 200 OK
CSeq: 4
Server: gortsplib
Session: 545498661

ПОСЛЕ этого поделие на основе либ ффмпега начинать слать RTP пакеты по ранее установленному TCP соединению на тот же порт.

т.е. как бэ сервер не говорит «публикации» PLAY только когда требуется, что кажется проблемой…

Что же делать как быть!?

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

На 1 ГБит/с БЕЗ тарификации по объему трафика.

Посоветуйте? В идеале где то на Урале-Сибири, чтобы время отклика минимальное получить.

Сейчас на timeweb плачу 8000 в месяц за выделенный E3-1230v5, 32 Гб RAM, 2 х 240 Gb SSD, но до них 40 мс только пинг ходит от меня.

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

Опять продолжение темы Запись сырого 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).

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