LINUX.ORG.RU

Как дождаться окончания процесса openrtsp (Live555), который порождает суб-процессы после exit?

 


0

1

Сабж, в первый раз такое вижу :-)
Запускаем:

openRTSP -i -b 500000 -d 10 -t -P 100 -F test1.avi rtsp://###;  
openRTSP -i -b 500000 -d 10 -t -P 100 -F test2.avi rtsp://###

по логике оно должно выполнить первую строчку, которая пишет файл 10 секунд, потом вторую, и соотв. записать второй файл продолжительностью в 10 секунд, один за другим (да, я в курсе что можно -d 20 -P 10 но это для примера).
на практике оно стартует первую строку и сразу стартует вторую = имеем два почти одинаковых файла.

первое что приходит в голову - процесс порождает суб-процесс, который и пишет файл, а себя сразу завершает, но нет:

#!/bin/bash

openRTSP -i -b 500000 -d 15  -t -P 100 -F test.avi rtsp://###
for job in `jobs -p`
do
    echo $job
    wait $job
done

сразу после старта говорит что джоб один ([0]) и что у него сразу done приехали, хотя оно продолжает себе спокойно писать 10 секунд

как это они так хитро сделали и как бы таки дождаться окончания записи? :-)

★★★★

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

зачем тебе это г… ?

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

вот вполне рабочее асинхронное решение:

спасибо, гляну, правда там:
-No QoS/RTCP
-No keepalives
которые оба два весьма недурно работают в 555

rukez ★★★★
() автор топика

jobs это фоновые задачи шелла, к субпроцессам запущеных прог они отношения не имеют

Варианты:

  1. поставь туда sleep 10 в середину (самое простое)

  2. городи сложные проверки списка процессов на предмет отсутствия там этого (но чтобы всё правильно сделать придётся много возиться - например что бы не получать побочного влияния от того что кто-то ещё запустит на этом компе другой openrtsp)

  3. проверяй наличие коннектов к указанному адресу, как исчезли - видимо тот openrtsp закончился, но тут похожие проблемы как в п.2

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

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

поставь туда sleep 10 в середину (самое простое)

я пока так и сделал, но есть две очевидные побочки:

  • слип начинается в момент запуска процесса а не подключения, при этом опенртсп пишет заданное время с момента коннекта т.е. поток закрывается (и запись заканчивается) через 10+N секунд, где N (время с момента запуска до приёма первого фрейма) - непредсказуемое число. При этом второй процесс, начнётся аккуратно через 10 секунд и если его N будет меньше то второй файл захватит кусок первого (в целом не критично кроме двойной нагрузки на сеть, диск и камеру) а если второй N будет больше то соотв. будет разрыв между файлами, что не хорошо
  • во время слипа мы никак не контролируем началась ли запись и продолжается ли она (ибо у нас нет выхлопа субпроцесса и нет понимания жив ли он вообще) т.е. если опенртсп не смог подключиться то привет, начало можно проверить по наличию файла а продолжение по темпу его роста но несколько костыльно, с ффмпегом знамо проще - можно и выхлоп мониторить и если процесс кончился раньше времени то значит точно печалька :-)

городи сложные проверки списка процессов на предмет отсутствия там этого

проблемно - они запускаются в овердофига потоков (т.е. там почти всегда есть другие потоки опенртсп) и я не уверен что пиды будут сохраняться после старта

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

то-же проблемно - параллельно эти девайсы опрашивает самописанный онвиф клиент и иногда ось пингует, притом у онвифа может совпадать порт назначения если он с ртсп дергает кусочки

возможно у openrtsp есть опция чтобы не уходить в фоновый режим

вот это было бы идеальным вариантом, но я её не нашёл - вдруг кто в курсе чего ему надо сказать чтоб он одумался и вёл себя по человечьи :-)

или ты сможешь его пропатчить для такого

я бегло пробежался по исходникам и понял что это маловероятно :-D

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

проблемно - они запускаются в овердофига потоков (т.е. там почти всегда есть другие потоки опенртсп) и я не уверен что пиды будут сохраняться после старта

Я же сразу написал - сложные проверки. Это не распарсить вывод ps axu регулярками, а отдельное мониторинговое приложение, хранящее своё внутреннее состояние чтобы запоминать историю процесслиста и пытаться эвристически догадываться кто от кого запустился (да, есть ppid, но можно не успеть его прочесть перед тем как он превратится в 1; хотя ещё есть такие понятия как session id, или ещё мельче - process group id, возможно через них будет легко это сделать, если оно специально не путает следы, может быть + время старта процесса использовать, опять же не втупую сравнивая с временем команды). Про список коннектов - в идеале аналогичная история, можно даже объединить эти два источника информации.

я бегло пробежался по исходникам и понял что это маловероятно :-D

Ну, можно кого-нить (не меня, мне лень) попросить, не думаю что это прям сильно сложно. Либо пропатчить его на создание/удаление какого-то локфайла на время работы.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.