poor behavior when camera has audio enabled #36
Comments
This works around #36 for now. I'll need to do something different when I actually implement audio support.
|
Here's the offending ffmpeg code, in |
|
For others reading this issue, commit 091217b addressed the issue by isolating the video stream only thereby ignoring the stream marked "audio":
Further references: FFmpeg Trac Ticket 5018 incorrect PTS/DTS on first frame of RTSP stream See also: FFmpeg Trac Ticket 6415 Strange DTS of first packet in RTSP stream |
|
Note the ffmpeg ticket 5018 is a separate problem. Since it affects only the first frame, my workaround (in if discard_first {
info!("Discarding the first packet to work around https://trac.ffmpeg.org/ticket/5018");
stream.get_next()?;
}The discontinuity on SNTP adjustment is a bigger problem, not yet reported to ffmpeg folks; it's a deal-breaker for audio. |
|
I'll review both issues and see if I can propose to you, Scott Lamb, a draft for submission to FFmpeg's Trac system. Can't do until this weekend. |
|
It may be with the current high watermark of FFmpeg that the problem in FFmpeg Trac Ticket 5018 is less egregious. See my update: Comment #4 I decided it is appropriate to create a reproducible test with the least few variables and therefore sought a solution where:
Select a publicly available MP4 so everyone can use the same file. 3 Consoles. Console A: launch the rts-simple-server Console B: stream with ffmpeg the file to the rtsp-simple-server Console C: pull the stream and run ffmpeg in debug mode. Preserve Create a log file name for this test and launch script: then in the script shell: then review the color-preserved log in the main shell: The concern I have with the proposed test in Ffmpeg Trac Ticket 5018 (https://trac.ffmpeg.org/ticket/5018) is that Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bunny.mp4': The ac3 codec was a proprietary codec developed by Dolby for Surroundsound. |
|
I also should add, I tried using FFmpeg against my Reolink cameras several weeks ago and duplicated the "monotonic" errors. jlpoole@taurus /tmp/test $ ffmpeg -loglevel debug -rtsp_transport tcp -rtsp_flags prefer_tcp -t 20 -i rtsp://admin:[REDACTED]@192.168.1.48:554/h264Preview_01_main -map 0:v -filter:v showinfo -frames:v 1200 -f null /dev/null |
* switch the config interface over to use Retina and make the test button honor rtsp_transport = udp. * adjust the threading model of the Retina streaming code. Before, it spawned a background future that read from the runtime and wrote to a channel. Other calls read from this channel. After, it does work directly from within the block_on calls (no channels). The immediate motivation was that the config interface didn't have another runtime handy. And passing in a current thread runtime deadlocked. I later learned this is a difference between Runtime::block_on and Handle::block_on. The former will drive IO and timers; the latter will not. But this is also more efficient to avoid so many thread hand-offs. Both the context switches and the extra spinning that tokio appears to do as mentioned here: scottlamb/retina#5 (comment) This may not be the final word on the threading model. Eventually I may not have per-stream writing threads at all. But I think it will be easier to look at this after getting rid of the separate `moonfire-nvr config` subcommand in favor of a web interface. * in tests, read `.mp4` files via the `mp4` crate rather than ffmpeg. The annoying part is that this doesn't parse edit lists; oh well. * simplify the `Opener` interface. Formerly, it'd take either a RTSP URL or a path to a `.mp4` file, and they'd share some code because they both sometimes used ffmpeg. Now, they're totally different libraries (`retina` vs `mp4`). Pull the latter out to a `testutil` module with a different interface that exposes more of the `mp4` stuff. Now `Opener` is just for RTSP. * simplify the h264 module. It had a lot of logic to deal with Annex B. Retina doesn't use this encoding. Fixes #36 Fixes #126
There's an ffmpeg bug when a camera has audio enabled. I'll quote the troubleshooting guide below. Either we need this ffmpeg bug fixed (and the fixed version bundled with Moonfire NVR) or we need to switch RTSP libraries.
Error: pts not monotonically increasing; got 26615520 then 26539470If your streams cut out with an error message like this one, there are a couple possibilities.
One is that your camera outputs B frames. If you believe this is the case, file a feature request; Moonfire NVR currently doesn't support B frames. You may be able to configure your camera to disable B frames in the meantime.
A more subtle problem occurs in cameras such as the Dahua Starlight series when the following is true:
Moonfire NVR currently uses the ffmpeg library to talk to the cameras. ffmpeg doesn't properly support this situation. It uses the NTP time to adjust the PTS and DTS, and thus experiences jumps forward and backward. The forward jumps cause one frame to be artificially lengthened. The backward jumps create an impossible situation which causes Moonfire NVR to abort the session and retry.
In the long term, Moonfire NVR will likely implement its own RTSP support.
In the short term, you can use either of two workarounds:
The text was updated successfully, but these errors were encountered: