[Support]: Transcoded stream trips up ffmpeg #2334
Comments
|
The only thing that seems wrong to me is the discrepancy between the ffprobe output above and the ffmpeg output from the transcoder pod: So here it states that the transcoded streams are |
|
So I think there might be two problems here.
So I'm guessing it fails to start within 20 seconds most of the time, and when it does. Well the above happens which I'm not quite sure about. |
|
Ha! Setting A bit too early to celebrate it seems. The stream worked fine in Frigate and was snappy to load in vlc, so I re-enabled my 5 other cameras (3 reolink and 2 hikvision) and now I'm back to the same errors. I guess I just got lucky once :/ |
|
Okay, finally got this working by moving from qsv to vaapi:
This works perfectly and the transcoder is not even using half the capacity of my quicksync gpu when doing this for 3 cameras at the time. So, I was using this approach with a transcoder pod to get a better feedback loop when developing the ffmpeg command. Now though I'm uncertain about how to best implement this. So the Reolink cameras have a crappy sub stream which isn't good enough for detection in my case, which is why I nead to create two outputs. Would I be able reuse this ffmpeg command in frigate to create both the sub stream and main stream in one go? In other words without fetching the camera stream twice? |
|
So the above worked, but kept crashing every few minutes. And the stream was still fairly slow to load. This seems to have been the final part of the puzzle:
So basically adding Update, do not use the force_key_frames options. It completely messes up the vedio when there is motion. So now I'm back to having the stream be slow to start, but working with frigate. |
|
So now both streams are working and looking perfect in VLC, and Frigate seems happy. But whenever events are recorded they look terrible. There is tearing, artifacts and wherever there is movement the screen gets a green layer. But theres no error in the frigate logs though and the debug/detect stream looks the same as in VLC. Any ideas? Edit: So setting the bitrate |
|
So I logged into the frigate container and ran the command to save the 'record' stream to disk manually. Then I get a bunch of output that is was not included from the frigate logs. Basically a never ending stream of: So I'm guessing my transcoder stream isn't providing a monotonous DTS, which trips up the stream. What I don't get is why VLC can play the stream just fine with no DTS messegas. The only output I can find from VLC is this: There are just a few of these in VLC, but a storm in ffmpeg in the Frigate container with the DTS message. I guess if a few frames are in the wrong place, then VLC is just ignoring them, but ffmpeg is trying to fit them into the video. Update: What really bugs me about this is that if I just download the stream like so: |
|
have you check if h264 encoding in hardware is fully supported? https://wiki.libav.org/Hardware/vaapi i am no expert, but may it helps to find the right answer. |
|
Yeah my Xeon E-2224G (Intel® UHD Graphics P630) fully supports decode and encode of both formats in hardware. And the interesting thing here is that the video plays just fine in VLC. That is VLC still prints messages about some frames being too soon, and some being too late. Playing the video in quicktime however will reveal the choppyness, same as in my browser. It's really weird tbh. |
Are you certain it's the segment creation? Try adding the segment options to that simple command to check. |
only from my experiments with ffmpeg: its mostly invisivle if ffmpeg falls back to software-defaults. even if hardware could do, ffmpeg must use it. and hard to find a clue, if ffmpeg uses the configured hw-support. instead fallen silently back to softwaer. but your problem is maybe something else... |
Actually no, that was wrong. It's the option |
|
Does that solve your issue? It's ok to remove that parameter if needed. |
|
Yeah, I don't want to dig any deeper into this rabbit hole than I have to, and now it works. Thanks, let's close this 👍 |
|
Hi brujoand, |
Describe the problem you are having
So I'm trying to force my horde of Reolink rlc-820a cameras to play ball with Frigate. I've set up a pod which is transcoding the streams with ffmpeg and rtsp-simple-server like so:
So basically I've got the camera streaming h265(4k, 20fps) video to a transcoder pod, which decodes h265 and creates a main stream of h264(4k, 20fps) and a substream of h264(720p,5pfs). I can view these two transcoded streams just fine with VLC, but frigate refuses to even aknowledge that video is being recieved:
No frames received from stua in 20 seconds. Exiting ffmpeg...So I'm assuming that there is something wrong about the way I'm re-encoding the stream that I'm feeding into Frigate, but I can't quite figure out what. Any advice?
Version
0.9.4-26ae608
Frigate config file
Relevant log output
FFprobe output from your camera
Frigate stats
{ "detection_fps": 0, "detectors": { "coral": { "detection_start": 0, "inference_speed": 10, "pid": 216 } }, "service": { "storage": { "/dev/shm": { "free": 16750.5, "mount_type": "tmpfs", "total": 16750.8, "used": 0.3 }, "/media/frigate/clips": { "free": 4564372.2, "mount_type": "nfs4", "total": 11615690.3, "used": 7051318.1 }, "/media/frigate/recordings": { "free": 4564372.2, "mount_type": "nfs4", "total": 11615690.3, "used": 7051318.1 }, "/tmp/cache": { "free": 168012.8, "mount_type": "overlay", "total": 210304.5, "used": 31537.5 } }, "uptime": 11563, "version": "0.9.4-26ae608" }, "stua": { "camera_fps": 0, "capture_pid": 226, "detection_fps": 0, "pid": 223, "process_fps": 0, "skipped_fps": 0 } }Operating system
Other Linux
Install method
Docker CLI
Coral version
M.2
Network connection
Wired
Camera make and model
RLC-820a
Any other information that may be helpful
No response
The text was updated successfully, but these errors were encountered: