Приветствую.
Накодил по своей старой теме чтение записанного архива Одновременное чтение и запись «файла»
теперь надо послать все это дело через ентернеты, планирую через ffmpeg, используя только rtp.
И вот вопрос возник - а во что лучше всего пожать видео, чтобы отправив такой ФАЙЛ хоть кому, он хоть где прочитался???
Приветствую!
Продолжаю мучать тему С++ vs прямая запись на флешку
Вроде пишется как хотел, НО теперь дошла очередь чтения записываемого видео архива, т.е. все надо делать ОДНОВРЕМЕННО.
Тем кому лень читать всякое мое старье - напомню что пишу на сырую флешку через Cишный stdio с кешем setvbuf(pf, NULL, _IOFBF, 256 * 1024) mjpeg кадры в разрешении 2мп.
Вопрос - что будет шустрее - еще раз открывать на чтение этот же диск-«файл» (как насчет недоступности для чтения того что в кеше?) или лучше все же устраивать «передергивание» позиции на уже открытом - чтение с нужной позиции, пока не приходит событие отдать «файл» на запись и т.д. ???
Критика идеи приветствуется )
Приветствую, может кто сталкивался - пересжимаю из MJPEG в H264 и отдаю это через RTSP публикацию на сервер, все работает хорошо ровно 13 часов и 15 минут, потом временные метки pts/dts на сервере вдруг не с того не с сего начинают приходить с нуля, следовательно онлайн видео ложится, в коде у себя нигде такой хрени не делаю, как и не задаю длительность для онлайн стрима.
где может задаваться длительность трансляции или что может влияет???
Периодически требуется тысячам устройств проверить актуальность своего ПО и скачать последнюю версию к себе.
Устройства все на С/C++ написаны, соответственно и клиент будет на этом же, посоветуйте самый производительный способ, да чтоб еще сервер не ддосился таким обменом.
Спасибо
Приветствую
Подскажите, как в makefile сложить все в одно место одной же командой, так что то ругается
gcc -c $(shell find ./lvgl/src -type f -name '*.c') -I./lvgl/ -o $@ $<
gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files
Есть гора у меня NanoPi Neo, которые использую помаксимуму (пока для перекодирования и стриминга через rtsp).
Вроде ну все уж сделал - усб камеру, сеть, флешку - повесил прерывания на разные ядра цпу, поднял частоту на максимум, один фиг - то камера отвалится, то сеть, в dmesg такое
[Wed Jan 25 08:05:02 2023] INFO: rcu_sched self-detected stall on CPU
[Wed Jan 25 08:05:02 2023] 1-...: (1 GPs behind) idle=326/140000000000002/0 softirq=206202/206203 fqs=1871
[Wed Jan 25 08:05:02 2023] INFO: rcu_sched detected stalls on CPUs/tasks:
[Wed Jan 25 08:05:02 2023] (t=4203 jiffies g=96027 c=96026 q=426)
[Wed Jan 25 08:05:02 2023] NMI backtrace for cpu 1
[Wed Jan 25 08:05:02 2023] CPU: 1 PID: 3269 Comm: kworker/1:0 Tainted: G O 4.14.111 #126
[Wed Jan 25 08:05:02 2023] Hardware name: sun8i
[Wed Jan 25 08:05:02 2023] Workqueue: events dbs_work_handler
[Wed Jan 25 08:05:02 2023] [<c02287fc>] (unwind_backtrace) from [<c0225398>] (show_stack+0x10/0x14)
[Wed Jan 25 08:05:02 2023] [<c0225398>] (show_stack) from [<c0a1b5bc>] (dump_stack+0x94/0xa8)
[Wed Jan 25 08:05:02 2023] [<c0a1b5bc>] (dump_stack) from [<c0a20e70>] (nmi_cpu_backtrace+0xc0/0xc4)
[Wed Jan 25 08:05:02 2023] [<c0a20e70>] (nmi_cpu_backtrace) from [<c0a20f54>] (nmi_trigger_cpumask_backtrace+0xe0/0x11c)
[Wed Jan 25 08:05:02 2023] [<c0a20f54>] (nmi_trigger_cpumask_backtrace) from [<c0294c4c>] (rcu_dump_cpu_stacks+0x98/0xc8)
[Wed Jan 25 08:05:02 2023] [<c0294c4c>] (rcu_dump_cpu_stacks) from [<c0294368>] (rcu_check_callbacks+0x764/0x8e4)
[Wed Jan 25 08:05:02 2023] [<c0294368>] (rcu_check_callbacks) from [<c0297ce0>] (update_process_times+0x30/0x5c)
[Wed Jan 25 08:05:02 2023] [<c0297ce0>] (update_process_times) from [<c02a7d98>] (tick_sched_timer+0x40/0x9c)
[Wed Jan 25 08:05:02 2023] [<c02a7d98>] (tick_sched_timer) from [<c0298ac8>] (__hrtimer_run_queues+0x110/0x184)
[Wed Jan 25 08:05:02 2023] [<c0298ac8>] (__hrtimer_run_queues) from [<c0298d04>] (hrtimer_interrupt+0xb8/0x20c)
[Wed Jan 25 08:05:02 2023] [<c0298d04>] (hrtimer_interrupt) from [<c07eef60>] (arch_timer_handler_phys+0x28/0x30)
[Wed Jan 25 08:05:02 2023] [<c07eef60>] (arch_timer_handler_phys) from [<c0289134>] (handle_percpu_devid_irq+0x74/0x134)
[Wed Jan 25 08:05:02 2023] [<c0289134>] (handle_percpu_devid_irq) from [<c0284380>] (generic_handle_irq+0x24/0x34)
[Wed Jan 25 08:05:02 2023] [<c0284380>] (generic_handle_irq) from [<c02848a0>] (__handle_domain_irq+0x5c/0xb4)
[Wed Jan 25 08:05:02 2023] [<c02848a0>] (__handle_domain_irq) from [<c0201528>] (gic_handle_irq+0x3c/0x78)
[Wed Jan 25 08:05:02 2023] [<c0201528>] (gic_handle_irq) from [<c0225e78>] (__irq_svc+0x58/0x74)
[Wed Jan 25 08:05:02 2023] Exception stack(0xc9e67c18 to 0xc9e67c60)
[Wed Jan 25 08:05:02 2023] 7c00: 00000000 600a0193
[Wed Jan 25 08:05:02 2023] 7c20: 00000013 00009fcb defb6800 600a0113 c9f0b800 00000000 c9f0b8e8 c1061520
[Wed Jan 25 08:05:02 2023] 7c40: c1202080 40000000 df4019c0 c9e67c68 c06f39d8 c06d9da0 600a0113 ffffffff
[Wed Jan 25 08:05:02 2023] [<c0225e78>] (__irq_svc) from [<c06d9da0>] (__usb_hcd_giveback_urb+0x80/0x148)
[Wed Jan 25 08:05:02 2023] [<c06d9da0>] (__usb_hcd_giveback_urb) from [<c06daaa0>] (usb_giveback_urb_bh+0x9c/0xec)
[Wed Jan 25 08:05:02 2023] [<c06daaa0>] (usb_giveback_urb_bh) from [<c02458bc>] (tasklet_hi_action+0x74/0x110)
[Wed Jan 25 08:05:02 2023] [<c02458bc>] (tasklet_hi_action) from [<c020165c>] (__do_softirq+0xf4/0x220)
[Wed Jan 25 08:05:02 2023] [<c020165c>] (__do_softirq) from [<c0245d64>] (irq_exit+0xe0/0x13c)
[Wed Jan 25 08:05:02 2023] [<c0245d64>] (irq_exit) from [<c02848a4>] (__handle_domain_irq+0x60/0xb4)
[Wed Jan 25 08:05:02 2023] [<c02848a4>] (__handle_domain_irq) from [<c0201528>] (gic_handle_irq+0x3c/0x78)
[Wed Jan 25 08:05:02 2023] [<c0201528>] (gic_handle_irq) from [<c0225e78>] (__irq_svc+0x58/0x74)
[Wed Jan 25 08:05:02 2023] Exception stack(0xc9e67d40 to 0xc9e67d88)
[Wed Jan 25 08:05:02 2023] 7d40: 80befc00 00000000 00000001 1c9c3800 00000002 00000001 80befc00 80befc00
[Wed Jan 25 08:05:02 2023] 7d60: 1c9c3800 1c9c3800 00000001 00000001 00000001 c9e67d90 9bdd3c00 c05971b4
[Wed Jan 25 08:05:02 2023] 7d80: 800a0013 ffffffff
[Wed Jan 25 08:05:02 2023] [<c0225e78>] (__irq_svc) from [<c05971b4>] (ccu_nkmp_find_best+0x178/0x20c)
[Wed Jan 25 08:05:02 2023] [<c05971b4>] (ccu_nkmp_find_best) from [<c0597480>] (ccu_nkmp_set_rate+0xb4/0x1e8)
[Wed Jan 25 08:05:02 2023] [<c0597480>] (ccu_nkmp_set_rate) from [<c058ebb8>] (clk_change_rate+0x1bc/0x254)
[Wed Jan 25 08:05:02 2023] [<c058ebb8>] (clk_change_rate) from [<c058ee88>] (clk_core_set_rate_nolock+0x68/0xb0)
[Wed Jan 25 08:05:02 2023] [<c058ee88>] (clk_core_set_rate_nolock) from [<c058eef4>] (clk_set_rate+0x24/0x34)
[Wed Jan 25 08:05:02 2023] [<c058eef4>] (clk_set_rate) from [<c0625d80>] (dev_pm_opp_set_rate+0x1e0/0x384)
[Wed Jan 25 08:05:02 2023] [<c0625d80>] (dev_pm_opp_set_rate) from [<c07cd168>] (__cpufreq_driver_target+0x24c/0x5c8)
[Wed Jan 25 08:05:02 2023] [<c07cd168>] (__cpufreq_driver_target) from [<c07d1234>] (od_dbs_update+0xe0/0x168)
[Wed Jan 25 08:05:02 2023] [<c07d1234>] (od_dbs_update) from [<c07d1b88>] (dbs_work_handler+0x2c/0x60)
[Wed Jan 25 08:05:02 2023] [<c07d1b88>] (dbs_work_handler) from [<c02576fc>] (process_one_work+0x138/0x34c)
[Wed Jan 25 08:05:02 2023] [<c02576fc>] (process_one_work) from [<c0257944>] (worker_thread+0x34/0x52c)
[Wed Jan 25 08:05:02 2023] [<c0257944>] (worker_thread) from [<c025d020>] (kthread+0x128/0x158)
[Wed Jan 25 08:05:02 2023] [<c025d020>] (kthread) from [<c0222058>] (ret_from_fork+0x14/0x3c)
[Wed Jan 25 08:05:02 2023] 1-...: (1 GPs behind) idle=326/140000000000002/0 softirq=206202/206203 fqs=1874
[Wed Jan 25 08:05:02 2023] (detected by 2, t=4205 jiffies, g=96027, c=96026, q=434)
[Wed Jan 25 08:05:02 2023] Sending NMI from CPU 2 to CPUs 1:
[Wed Jan 25 08:05:02 2023] NMI backtrace for cpu 1
[Wed Jan 25 08:05:02 2023] CPU: 1 PID: 3269 Comm: kworker/1:0 Tainted: G O 4.14.111 #126
[Wed Jan 25 08:05:02 2023] Hardware name: sun8i
[Wed Jan 25 08:05:02 2023] Workqueue: events dbs_work_handler
[Wed Jan 25 08:05:02 2023] task: de636400 task.stack: c9e66000
[Wed Jan 25 08:05:02 2023] PC is at __usb_hcd_giveback_urb+0x80/0x148
[Wed Jan 25 08:05:02 2023] LR is at ehci_urb_enqueue+0xa3c/0xd98
[Wed Jan 25 08:05:02 2023] pc : [<c06d9da0>] lr : [<c06f39d8>] psr: 600a0113
[Wed Jan 25 08:05:02 2023] sp : c9e67c68 ip : df4019c0 fp : 40000000
[Wed Jan 25 08:05:02 2023] r10: c1202080 r9 : c1061520 r8 : c9f0b8e8
[Wed Jan 25 08:05:02 2023] r7 : 00000000 r6 : c9f0b800 r5 : 600a0113 r4 : defb7000
[Wed Jan 25 08:05:02 2023] r3 : 00009fd1 r2 : 0000000b r1 : 600a0193 r0 : 00000000
[Wed Jan 25 08:05:02 2023] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[Wed Jan 25 08:05:02 2023] Control: 30c5387d Table: 5ebc9fc0 DAC: 3f1634e1
[Wed Jan 25 08:05:02 2023] CPU: 1 PID: 3269 Comm: kworker/1:0 Tainted: G O 4.14.111 #126
[Wed Jan 25 08:05:02 2023] Hardware name: sun8i
[Wed Jan 25 08:05:02 2023] Workqueue: events dbs_work_handler
[Wed Jan 25 08:05:02 2023] [<c02287fc>] (unwind_backtrace) from [<c0225398>] (show_stack+0x10/0x14)
[Wed Jan 25 08:05:02 2023] [<c0225398>] (show_stack) from [<c0a1b5bc>] (dump_stack+0x94/0xa8)
[Wed Jan 25 08:05:02 2023] [<c0a1b5bc>] (dump_stack) from [<c0a20e24>] (nmi_cpu_backtrace+0x74/0xc4)
[Wed Jan 25 08:05:02 2023] [<c0a20e24>] (nmi_cpu_backtrace) from [<c0227800>] (handle_IPI+0xac/0x194)
[Wed Jan 25 08:05:02 2023] [<c0227800>] (handle_IPI) from [<c0201560>] (gic_handle_irq+0x74/0x78)
[Wed Jan 25 08:05:02 2023] [<c0201560>] (gic_handle_irq) from [<c0225e78>] (__irq_svc+0x58/0x74)
[Wed Jan 25 08:05:02 2023] Exception stack(0xc9e67c18 to 0xc9e67c60)
[Wed Jan 25 08:05:02 2023] 7c00: 00000000 600a0193
[Wed Jan 25 08:05:02 2023] 7c20: 0000000b 00009fd1 defb7000 600a0113 c9f0b800 00000000 c9f0b8e8 c1061520
[Wed Jan 25 08:05:02 2023] 7c40: c1202080 40000000 df4019c0 c9e67c68 c06f39d8 c06d9da0 600a0113 ffffffff
[Wed Jan 25 08:05:02 2023] [<c0225e78>] (__irq_svc) from [<c06d9da0>] (__usb_hcd_giveback_urb+0x80/0x148)
[Wed Jan 25 08:05:02 2023] [<c06d9da0>] (__usb_hcd_giveback_urb) from [<c06daaa0>] (usb_giveback_urb_bh+0x9c/0xec)
[Wed Jan 25 08:05:02 2023] [<c06daaa0>] (usb_giveback_urb_bh) from [<c02458bc>] (tasklet_hi_action+0x74/0x110)
[Wed Jan 25 08:05:02 2023] [<c02458bc>] (tasklet_hi_action) from [<c020165c>] (__do_softirq+0xf4/0x220)
[Wed Jan 25 08:05:02 2023] [<c020165c>] (__do_softirq) from [<c0245d64>] (irq_exit+0xe0/0x13c)
[Wed Jan 25 08:05:02 2023] [<c0245d64>] (irq_exit) from [<c02848a4>] (__handle_domain_irq+0x60/0xb4)
[Wed Jan 25 08:05:02 2023] [<c02848a4>] (__handle_domain_irq) from [<c0201528>] (gic_handle_irq+0x3c/0x78)
[Wed Jan 25 08:05:02 2023] [<c0201528>] (gic_handle_irq) from [<c0225e78>] (__irq_svc+0x58/0x74)
[Wed Jan 25 08:05:02 2023] Exception stack(0xc9e67d40 to 0xc9e67d88)
[Wed Jan 25 08:05:02 2023] 7d40: 80befc00 00000000 00000001 1c9c3800 00000002 00000001 80befc00 80befc00
[Wed Jan 25 08:05:02 2023] 7d60: 1c9c3800 1c9c3800 00000001 00000001 00000001 c9e67d90 9bdd3c00 c05971b4
[Wed Jan 25 08:05:02 2023] 7d80: 800a0013 ffffffff
[Wed Jan 25 08:05:02 2023] [<c0225e78>] (__irq_svc) from [<c05971b4>] (ccu_nkmp_find_best+0x178/0x20c)
[Wed Jan 25 08:05:02 2023] [<c05971b4>] (ccu_nkmp_find_best) from [<c0597480>] (ccu_nkmp_set_rate+0xb4/0x1e8)
[Wed Jan 25 08:05:02 2023] [<c0597480>] (ccu_nkmp_set_rate) from [<c058ebb8>] (clk_change_rate+0x1bc/0x254)
[Wed Jan 25 08:05:02 2023] [<c058ebb8>] (clk_change_rate) from [<c058ee88>] (clk_core_set_rate_nolock+0x68/0xb0)
[Wed Jan 25 08:05:02 2023] [<c058ee88>] (clk_core_set_rate_nolock) from [<c058eef4>] (clk_set_rate+0x24/0x34)
[Wed Jan 25 08:05:02 2023] [<c058eef4>] (clk_set_rate) from [<c0625d80>] (dev_pm_opp_set_rate+0x1e0/0x384)
[Wed Jan 25 08:05:02 2023] [<c0625d80>] (dev_pm_opp_set_rate) from [<c07cd168>] (__cpufreq_driver_target+0x24c/0x5c8)
[Wed Jan 25 08:05:02 2023] [<c07cd168>] (__cpufreq_driver_target) from [<c07d1234>] (od_dbs_update+0xe0/0x168)
[Wed Jan 25 08:05:02 2023] [<c07d1234>] (od_dbs_update) from [<c07d1b88>] (dbs_work_handler+0x2c/0x60)
[Wed Jan 25 08:05:02 2023] [<c07d1b88>] (dbs_work_handler) from [<c02576fc>] (process_one_work+0x138/0x34c)
[Wed Jan 25 08:05:02 2023] [<c02576fc>] (process_one_work) from [<c0257944>] (worker_thread+0x34/0x52c)
[Wed Jan 25 08:05:02 2023] [<c0257944>] (worker_thread) from [<c025d020>] (kthread+0x128/0x158)
[Wed Jan 25 08:05:02 2023] [<c025d020>] (kthread) from [<c0222058>] (ret_from_fork+0x14/0x3c)
Ядро там 4.14.111, пакеты Ubuntu 16.04.7 LTS
Посоветуйте, что еще можно сделать???
Приветствую, нуждаюсь в совете.
Надо файл перекинуть через пару NATов, свой лисапед на С/C++ я уже попробовал с какой то чужой либой, возвращающей мне параметры ната от чужого STUN сервера - вроде все не сложно, обмениваемся получаемыми параметрами от стуна через какой то сигнальный сервер (в моем случае MQTT), создаем маршрут в НАТе посылкой UDP пакета и погнали качать.
НО во всей этой канители напрягает пара моментов, под которые нужно продолжать пилить лисапед
Последнее важно, но не так как первое.
Посоветуйте НЕБОЛЬШУЮ широко используемую либу под эти цели???
Не было печали, пока не решил еще одну библиотеку в проект засунуть и оказалось что имена функций повторяются
Как победить можно???
# make -j2 -B Recorder
rm -f Recorder
gcc -c RecorderFDisk.c -I./util-linux/ -Wall -pedantic -O3
gcc -c RecorderArchive.c -I./paho.mqtt.c/src/ -Wall -pedantic -O3
gcc -c RecorderFFmpeg.c -I./FFmpeg/ -Wall -pedantic -O3
gcc -c RecorderFFserver.c -I./FFmpeg/ -O3
g++ -o Recorder Recorder.cpp ./libcommon/Sys.cpp \
RecorderFDisk.o RecorderArchive.o RecorderFFmpeg.o RecorderFFserver.o \
./util-linux/libblkid/src/libblkid_la-probe.o \
./util-linux/libuuid/src/libuuid_la-parse.o \
./util-linux/libuuid/src/libuuid_la-unparse.o \
./util-linux/libuuid/src/libuuid_la-gen_uuid.o \
./util-linux/disk-utils/fdisk-fdisk-list.o \
./util-linux/.libs/libcommon.a \
./util-linux/.libs/libsmartcols.a \
./util-linux/.libs/libtcolors.a \
./util-linux/.libs/libblkid.a \
./util-linux/.libs/libuuid.a \
./util-linux/.libs/libfdisk.a \
./FFmpeg/libavdevice/libavdevice.a \
./FFmpeg/libavfilter/libavfilter.a \
./FFmpeg/libavformat/libavformat.a \
./FFmpeg/libavcodec/libavcodec.a \
./FFmpeg/libavutil/libavutil.a \
./FFmpeg/libswscale/libswscale.a \
./FFmpeg/libswresample/libswresample.a \
./paho.mqtt.c/build/src/libpaho-mqtt3a.a \
-lpthread -ltinfo -lm -lx264 -lv4l2 -lasound -Wall -pedantic -O3
./paho.mqtt.c/build/src/libpaho-mqtt3a.a(WebSocket.c.o): In function `uuid_generate':
WebSocket.c:(.text+0x11): multiple definition of `uuid_generate'
./util-linux/libuuid/src/libuuid_la-gen_uuid.o:/root/utils/util-linux/libuuid/src/gen_uuid.c:551: first defined here
./paho.mqtt.c/build/src/libpaho-mqtt3a.a(WebSocket.c.o): In function `uuid_unparse':
WebSocket.c:(.text+0xc0): multiple definition of `uuid_unparse'
./util-linux/libuuid/src/libuuid_la-unparse.o:/root/utils/util-linux/libuuid/src/unparse.c:74: first defined here
collect2: error: ld returned 1 exit status
Makefile:39: ошибка выполнения рецепта для цели «Recorder»
make: *** [Recorder] Ошибка 1
Приветствую.
Суть проблемы - мой перекодировщик (написанный на либах от ffmpeg) из мжпег в х264 отправляет пакеты в мой ртсп сервер (написанный на основе исходника ffserver), проблема в том, что если сервер перестает читать, а перекодировщик писать в произвольном месте - приходится долго ждать на просмотр первый И(idr) кадр, когда требуется продолжить просмотр новому клиенту.
Можно как то принудительно заставлять кодек его генерировать в произвольном месте???
зы. уменьшить расстояние между опорными кадрами не предлагать, т.к. нужно в узенький канал влезать на фуллхд )
Предстоит перелопатить говнопроект, написанный с помощью этой библиотеки для ARMHF архитектуры.
как то все «в блокноте» писал раньше небольшое, потом через gcc собирал, хотя вряд ли для армки можно что то архисложное написать (ffmpeg + ffserver удалось «в блокноте» втащить в своей проект)
Есть смысл выкидывать это поделие или лучше с ним разбираться? Проблемы говнопроекта сами по себе многогранны, хотя и используются доступы в БД и HTTP, многопоточность очевидно, может что то еще (XML и JSON точно понадобятся)
В задаче есть ограничение на ресурсы как по памяти, так и высоконагруженное цпу
Подключаюсь к сервису на сервере через проброс порта через ссш тунель, все работало замечательно, пока сервис не переехал дальше за шлюз.
Можно как то подключение к порту локалхоста перенаправить на порт в локальной сети через iptables ???
Форвардинг порта без ссш тунеля работает, но не для локалхоста почему то
Сгорела значит у меня сервачная плата, старая как .овно мамонта на 775 сокете еще, крутился там одинокий астериск, глянул на авиту - ба, да 2х процессорные 1366 платы + камни сущие копейки (за новые сервачные БП только ценнег дерут), заказал - пришло.
И тут мысль свербит значит куда девать такую мощу то теперь, а не перенести ли мне задачи из облачного астериска и не добавить ли туда москиту, одно напрягает - сервак за НАТом (с фаерволом конеш) на другой теперь уже сравнительно более слабой железке.
Ваше мнение?
Если нужно просто из цикла условно одновременно во ВСЕХ потоках выходить, то что разумней цикл по мутексу делать или по atomic_bool ??? или вообще это все работает одинаково и на атомике просто кода будет меньше
Оговорюсь С++20 недоступен, поэтому atomic_flag урезан.
Конструкция класса мутекса (заимствовано)
class multithr_off
{
private:
using guard = unique_lock<mutex>;
bool _on;
mutable condition_variable cv;
mutable mutex lock;
public:
using ptr_t = shared_ptr<multithr_off>;
multithr_off() : _on(true) {}
bool isOn() const
{
guard g(lock);
return _on;
}
void off()
{
guard g(lock);
_on = false;
g.unlock();
cv.notify_all();
}
};
auto poff = make_shared<multithr_off>();
Варианты проверок (все имеют тело цикла с обработкой)
1. ожидание вода с клавиатуры (вообще выходит отсюда по isOn!?)
while ((c = getchar()) != EOF && poff->isOn())
2. ожидание семафора, который отпустят из другого потока
while (sem_wait(psem) == 0 && poff->isOn())
3. ожидание сброса атомика из другого потока
atomic_bool abRunRead(false);
abRunRead.store(true);
while (abRunRead.load() && poff->isOn())
Честно говоря даже не знаю - проверяются сразу оба условия или последовательно и, например, второе не проверяется если первое ложно.
В продолжении темы Конкурирующая очередь в thread C++
суть которой в кратце
GetIdxPkt из начала списка индекс, пишет кадр по этому номеру буфера и добавляет PutIdxPkt индекс в конец, п2 и 3 забирают индекс с конца списка и после обработки кадра добавляют индекс в начало.Собсна код очереди, указатель на которую передам в эти потоки, нуждаюсь в оценке его адекватности
typedef struct
{
time_t ts;
uint8_t pos;
} stPktLive_t;
enum eQueuePos_t
{
FRONT,
BACK
};
class CQueue
{
private:
const uint8_t maxQ;
uint8_t cntQ;
list<stPktLive_t> ltQ;
mutex mtx;
condition_variable cvPut, cvGet;
using guard = unique_lock<mutex>;
public:
CQueue(uint8_t lQueue)
: maxQ(lQueue), cntQ(0)
{}
~CQueue()
{
if (ltQ.size() > 0) ltQ.clear();
}
int PutIdxPkt(stPktLive_t stV, eQueuePos_t pos)
{
guard g(mtx);
while (cntQ == maxQ) cvPut.wait(g);
mtx.lock();
if (pos == FRONT) ltQ.push_front(stV);
else ltQ.push_back(stV);
cntQ++;
cvGet.notify_all();//notify_one()
mtx.unlock();
return cntQ;
}
int GetIdxPkt(stPktLive_t & stV, eQueuePos_t pos)
{
guard g(mtx);
while (cntQ == 0) cvGet.wait(g);
mtx.lock();
if (pos == FRONT)
{
stV = ltQ.front();
ltQ.pop_front();
}
else
{
stV = ltQ.back();
ltQ.pop_back();
}
cntQ--;
cvPut.notify_all();
mtx.unlock();
return cntQ;
}
};
стар и остановку работу с очередью еще не обдумал
Продолжаю мучить сообщество своими хлупыми вопросами на похожие темы ) Вернуть результат thread в С++ без мутексов?
Необходимо запараллелить 3 потока
В однопоточной реализации вариантов 1+3 или 1+2 все работает вроде эффективно, задача 1 выполняется менее 30 мс, 2 - от 30 до 100мс, 3 - в районе 50мс
Теоретически конечно потоки 2 и 3 должны только читать память из потока 1 (хотя что происходит внутри сторонней либы потока 2 я не знаю) и теоретически можно было бы обойтись одним семафором для основного потока 1, НО поток 3 должен читать и записывать данные (кадры) на диск через равные промежутки времени, а поток 2 читать все данные (кадры) без задержек.
В предыдущей теме меня пнули в сторону атомиков, из чтения всяких хабров я понял следующее - работающие только с памятью атомик существенно быстрее, чем системный вызов мьютекса/семафора, однако как я понял в этом случае предлагается ждать в бесконечном цикле изменение атомика - но ведь это загрузит поток на 100%, а у меня только поток 2 грузит оставшиеся 300% на 4х ядрах
При этом как бы еще решить проблему конкуренции за ПОСЛЕДНИЙ кадр, все что раньше попало в очередь уже не имеет значения и просто считаю дропнутым
ЗЫ. Извините за многобукав! ЗЫ1. хотелось бы понять направление в которое двигаться.
Можно так?
Логика - запускаю thread.detach(), который либо после проверок сразу завершается, если проверки пройдены встает на ожидание внешнего события (слушает на сокете порт), как только событие наступает делает некоторые действия и завершается - так вот из основного потока хотелось бы знать выполняется ли еще этот поток, если нет, то получить из него значение БЕЗ блокировки основного потока?
Показалось future с его async() подойдет, но оказалось valid() проверяет всего лишь был ли async() и не делали ли еще get(), а не отсутствие результата для get(), следовательно если поток не завершился get() блокирует основной поток.
Не то чтобы мутексы проблема использовать, но может проще можно как то для одного единственного простого значения состояния?
Подскажите, как сделать?
Все что вижу
root@NanoPi-NEO-Core:~# ls -l /sys/class/mmc_host/mmc*
lrwxrwxrwx 1 root root 0 Feb 11 18:22 /sys/class/mmc_host/mmc0 -> ../../devices/platform/soc/1c11000.mmc/mmc_host/mmc0
lrwxrwxrwx 1 root root 0 Feb 11 18:22 /sys/class/mmc_host/mmc1 -> ../../devices/platform/soc/1c0f000.mmc/mmc_host/mmc1
Видится только /dev/mmcblk0, а должен еще появиться /dev/mmcblk1
В dmesg тишина, как будто и флешку не вставлял.
Понятно, что могу ребутнуться и флешка увидится, но мне на нее изменения внести надо сначала иба она загрузочная.
Приветствую.
Продолжнаю мучать тему Свой RTSP север для ffmpeg
Покамесь удалось скомпилировать ffserver.c от версии 3.4 с библиотеками 5.1, вроде разобрался как там диалог производится между RTSP сервером и клиентом (правда оказалось что ffplay шлет одну последовательность ртсп команд - нет команды SETUP, только OPTIONS, DESCRIBE и потом PLAY, а vlc нескольку другую).
Надо бы теперь RTP поток стримануть на клиента, с наскока не удается сообразить - а для ртп тоже что ли нужен слушающий пишущий сокет или «клиентская» сторона все таки выступает в роли ртп сервера?
Приветствую.
Сейчас удалось с помощью библиотек ффмпега стримануть видео на другой ртсп сервер (сейчас использую rtps-simple-server) через функции avformat_alloc_output_context2(&pFmtCtxOut, NULL, «rtsp», rtsp_url) и av_interleaved_write_frame, но нужна более сложная логика работы с сами видео, а не ртсп сервером, поэтому сторонний сервер не очень подходит.
Да я знаю что поддержка ffserver закончилась в 3.4 версии ффмпега, но можно ли что то простое наваять в с последней версией, например, в логике
хотелось бы сохранить и логику писать на другой рстп сервер, т.к. планирую еще соединение точка-точка для rtp протокола чтобы проходить через NATы, а это элементарно только поменять тип в avformat_alloc_output_context2
Нуждаюсь в ликбезе )
Раньше как то приходилось использовать только в С++ для контроля изменении в объекте класса, а что то в процедурном варианте не соображу как безопасно?
Есть 2 потока декодирования и кодирования, в неком участке кода декодирования мне нужно скопировать память для потока кодирования, понятно что это место нужно защитить мьютексом и хотелось бы это сделать в потоке кодирования, однако как правильно обрабатывать
переменную int состояния ошибок в потоках - нужно ли 2 таких переменных (ошибка в любом потоке должна останавливать оба), можно ли писать и читать из разных потоков одновременно без мутексов когда их 2 (каждый либо пишет, либо читает), чтобы не тормозить выполнение?
потоки должны ждать друг друга - после декодирования когда скопируется память, после кодирования когда будут готовы новые данные для копирования - получается еще 2 переменных!? каждую тоже нужно защищать мутексом? или как в п.1 раз один поток только пишет, а другой только читает можно без них обойтись?
или вообще какой то спецфический тип мутекса нужен!?
ПС. а то у меня получается 3 или 5 мутексов мне нужно чтоб каждую операцию обрабатывать.
| ← назад | следующие → |