Reolink RTSP-->ffmpeg, RTP: PT=xx: bad cseq if stopped/restarted quickly

Steven Kan

My BeeCam is a Raspberry Pi3/Raspbian Stretch w/freshly compiled ffmpeg version N-89882-g4dbae00bac running this as a service:

#!/bin/bash
cd /usr/local/bin/
while true
do
./ffmpeg -re -thread_queue_size 512 -rtsp_transport tcp -i 
"rtsp://anonymous:password@192.168.1.11:554" -i WilliamTellOverture.mp3 
-vcodec copy -acodec copy -t 00:11:51 -f flv 
"rtmp://a.rtmp.youtube.com/live2/my-youtube-streaming-key"
sleep 10s
done

where 192.168.1.11 is my spiffy new Reolink RLC-423S, and -t 00:11:51 is the length of my royalty-free MP3. This normally works quite well:

https://www.youtube.com/user/IAmTheWaterbug/live

and it loops continuously. The YT stream will glitch when it restarts, but the stream resumes with only about 15 seconds of video lost. It ran continuously overnight for at least 8 hours (e.g. many loops) before I started fiddling with it.

I changed the sleep to 5s, and that doesn't seem to bother it.

But on occasion I've done a sudo systemctl stop StreamToYouTube followed by sudo systemctl start StreamToYouTube, within 1-2 seconds (e.g. as fast as I can type Up Up Up and Enter), and sometimes when I do that, the stream fails, and ffmpeg starts dumping:

[rtsp @ 0x302c2f0] RTP: PT=60: bad cseq e680 expected=0b49
[rtsp @ 0x302c2f0] RTP: PT=60: bad cseq 93ab expected=0b49
[rtsp @ 0x302c2f0] RTP: PT=60: bad cseq 93ac expected=0b49
[rtsp @ 0x302c2f0] RTP: PT=60: bad cseq e682 expected=0b49

endlessly.

Rebooting the Pi doesn't fix this (e.g. the YT stream still fails, and sudo systemctl status StreamToYouTube returns the same stream of "bad cseq" errors), but rebooting the RLC-423S does fix it. I'm wondering what exactly that error means.

During the "failed" state, the camera appears to be working properly from other clients, e.g. I can launch the Reolink.app on my Mac or view the camera's web page from any browser, and the video looks fine.

But for some reason the RTSP stream goes funky in a way that ffmpeg can't resolve.

It's quite repeatable if I stop/start the service quickly, but restarting with a 5 second pause in my script doesn't seem to bother it.

Thanks!
BadCseq.png

alex

I am having the same issue with my RLC-410 and RLC-420.
The stream works great if I let them rest for ~30 seconds between running my application (which is using ffmpeg).
Something is not getting cleaned up properly on the camera-side when the stream is closed.
2019-04-23_14-29-17.png

Steven Kan

So that 30 second pause fixes things? I'll try putting a 30 second pause in my watchdog timer.

Thanks!

bigger_lawxx

Have the same problem here. 30 second pause doesnt fix the problem.

Cynthia

Could you please send an email to support@reolink.com? Our support team will check it for you soon. Thanks.

Venryx

I had the same issue as the posters above, and found a solution here: https://superuser.com/a/1562786/231129

Regarding the 30 second pause: It seems it differs by model. Some cameras (my C2 and alex's RLC 410 and 420) appear to have an "auto cleanup" of streams after a wait of about 30 seconds (after stream termination from the computer end), whereas for others (the cameras Steven Kan and bigger_law have), it appears there isn't such a function (thus requiring a camera reboot).

Anyway, check and see if the solution I linked to works for you. (I'm guessing it will solve at least some of other people's cases)

Steven Kan

Thanks! I'm incredibly impressed that you were able to duplicate and fix such as obscure problem!

I'm copying and pasting your solution from GitHub:

FFMpeg.prototype.stop = function() {

// replace this...
//this.child.kill();

// with this...
this.child.stdin.write("q\r\n");

delete this.child;
this.emit('stop');
};

Does this mean I have to make this change in the ffmpeg source and recompile it?

Thanks!

Venryx

No, the fix I made was in the NodeJS library that was launching (and non-graciously killing) the ffmpeg process.

This is the file I changed: https://[censored]/agsh/rtsp-ffmpeg/blob/master/lib/rtsp-ffmpeg.js

So for your case, I would look to the source code of whatever program is "killing" the ffmpeg process. If nothing (in your program) is explicitly killing the subprocess, then I guess you'll need to add a "cleanup" function that graciously ends the subprocess prior to your program overall being terminated.

Steven Kan

Ah, I see. Right now I'm calling ffmpeg through a bash script:

#!/bin/bash
cd /usr/local/bin/
while true
do
./ffmpeg -re -thread_queue_size 512 -rtsp_transport tcp -i \
"rtsp://anonymous:password@192.168.1.11:554" -i WilliamTellOverture.mp3 \
-vcodec copy -acodec copy -t 00:11:51 -f flv \
"rtmp://a.rtmp.youtube.com/live2/my-youtube-streaming-key"
sleep 10s
done

that I'm running as a service:

[Unit]
Description=Streamer
After=network-online.target
Requires=network-online.target

[Service]
ExecStart=/usr/local/bin/StreamToYouTube1.sh
Restart=always
KillSignal=TERM

[Install]
WantedBy=multi-user.target

Can you advise on how I can specify the correct termination method when I send a:

'sudo systemctl stop StreamToYouTube'?

Thanks!

Venryx

Unfortunately I don't know much (basically anything) about Linux/Mac services, so I won't be much help for the specifics.

One thing I can say is that it probably involves this:
KillSignal=TERM

In the NodeJS library I referenced, that is the same kill-signal it had been sending to the ffmpeg process to end it (which was causing the issue).

So, you'd need to find some way to have the "stop service" command send the "gracious exit" input I mentioned ("q\r\n"), rather than the "TERM" (ie. "SIGTERM") kill-signal.

It's possible the "sudo systemctl stop StreamToYouTube" approach you're using doesn't support this, meaning you'd need to find an alternative way of sending the "gracious quit" message. (though maybe it does support it, I don't know ^_^)

Steven Kan

Ah, ok. Thanks! I'll ask over on arstechnica, where they know Unix. You still get a cookie for finding the solution!

Venryx

Haha thanks! I like your stream by the way.