Как заставить VLC повторить попытку, если поток RTSP прерван - PullRequest
0 голосов
/ 27 мая 2019

Я возвращаюсь к своему вопросу здесь. У меня есть система наблюдения, которая передает потоки RTSP на мой ПК и записывает их с помощью VLC,

Как изящно закрыть VLC, используя C #

Я закрываю VLC каждые полчаса и перезапускаю, чтобы он записывал файлы продолжительностью 30 минут.

Команда VLC выглядит следующим образом,

vlc rtsp://*username*:*password*@192.168.1.60:554/ch01/0  --qt-start-minimized --sout=#transcode{ab=128,channels=2,samplerate=44100,scodec=none}:file{dst=D:\CCTV\Concord\2019_05_24\2019-05-24_2111_C1.mp4,no-overwrite}

Проблема сейчас в том, что иногда поток прерывается до истечения 30 минут, и VLC прекращает запись. Кажется, это какая-то проблема с сетью.

Когда это происходит, VLC продолжает работать, но не показывает сетевую активность в диспетчере задач и ничего не записывает.

Как я могу заставить VLC либо выйти, либо повторить попытку в этой ситуации? Иначе как я могу обнаружить эту ситуацию? Если я могу обнаружить, я могу закрыть и перезапустить VLC.

Я использовал эту опцию журнала в VLC и запускал ее в течение дня,

--file-logging --log-verbose=3 --logmode=text --logfile=blah

Файлы журналов заканчиваются примерно так:

main debug: adding a new sout input for `hevc` (sout_input: 0384ac70)
stream_out_transcode debug: not transcoding a stream (fcc=`hevc')
main debug: adding a new input
mp4 warning: Missing frame rate for stream 0, assuming 25fps
mp4 debug: adding input
main debug: Buffering 9%
main debug: Buffering 51%
main debug: Buffering 55%
main debug: Buffering 63%
main debug: Buffering 71%
main debug: Buffering 83%
main debug: Buffering 91%
main debug: Buffering 95%
main debug: Stream buffering done (1030 ms in 655 ms)
main debug: Decoder wait done in 0 ms
mp4 warning: i_length <= 0
live555 warning: no data received in 10s, eof ?
main debug: EOF reached
main debug: waiting decoder fifos to empty
live555 error: keep-alive failed: recvfrom() error: An existing connection was forcibly closed by the remote host
main debug: killing decoder fourcc `hevc'
main debug: removing module "hevc"
main debug: removing a sout input (sout_input: 0384ac70)
mp4 debug: tk 1 elst media time 0 duration 108539273 offset 0
mp4 debug: removing input
main warning: no more input streams for this mux
main debug: removing module "live555"
main debug: Program doesn't contain anymore ES
main debug: dead input
main debug: destroying useless sout
main debug: destroying chain... (name=transcode)
main debug: removing module "stream_out_transcode"
main debug: destroying chain done
main debug: destroying chain... (name=file)
main debug: removing module "stream_out_standard"
main debug: removing module "mp4"
mp4 debug: Close

Принимая это к сведению конкретно,

live555 warning: no data received in 10s, eof ?
main debug: EOF reached
main debug: waiting decoder fifos to empty
live555 error: keep-alive failed: recvfrom() error: An existing connection was forcibly closed by the remote host

Весь этот журнал можно увидеть здесь,

https://www.dropbox.com/s/e4b3e8jesrl08n3/2019-05-27_1622_C4.log?dl=0

UPDATE:

Я экспериментировал с libvlc, который дает мне гораздо больше контроля. Однако то, что я вижу, похоже, не вызывает события EndReached или EncounteredError.

Вместо этого я попробовал просмотреть сообщения журнала, которые поступают, поскольку есть событие журнала. Это немного слабо, но, похоже, это единственный выход. Я ищу следующие записи в журнале,

  • Retry. Как только он пытается повторить попытку, он входит в цикл повторения и никогда не заканчивается. Так что я просто убью его и перезапущу. Я должен посмотреть, как я могу подавить повторную попытку.
  • Существующее соединение было принудительно закрыто удаленным хостом. Но, возможно, ища это и останавливаясь, я останавливаю его до того, как оно достигнет события EncounteredError или EndReached

Я добираюсь туда, и это работает намного лучше. Мне почти нужно написать простое консольное приложение, которое просто подключается и регистрирует каждое событие, чтобы я мог получить полную картину простым способом, а не искать окончательное решение. Однако это требует времени, так как такие случаи разъединений и сбоев происходят только в некоторых случаях.

...