[HW Accel Support]: Adding go2rtc presets #8658
Comments
|
Need to see more logs |
|
This is the full log after some minutes: |
|
Do you see anything being created in /tmp/cache ? |
|
No, the folder is empty. |
|
That would indicate that ffmpeg is not receiving any data. I'm assuming it's the same when using the restream preset? |
|
Yes, the restream preset doesn't work as well. This is confusing, since I can save the go2rtc stream to a mp4 file on my host machine that uses the same ffmpeg binary as the image. Can I somehow find out the exact ffmpeg command that is used to capture the stream? |
|
Yes if you open |
|
Ah, I see the problem. Now, I used the hardware accel preset preset-rk-h265, since the detect stream directly connects to the cam and decodes the h265 stream. However, the hardware accel preset is also applied to the record command ( Why exactly does the record process use hw acceleration? Does this improve performance? I thought, this process just saves the files. Can I pass |
|
I looked it up in the docs, I can set the hwaccel args for each input. This would solve the problem, I will try it out later. |
|
There's no particular reason, just that the record and detect can be done in the same ffmpeg process so it didn't make sense to force it out for record. In the future they may be forced to be separate in which case that would be easier to do. |
|
Apparently, the hardware presets were not the only issue. The problem still occurs. I will update the issue tomorrow with new log outputs etc. |
|
I have following config and it works I suppose you also need to following into docker-compose.yml Note: that some cameras work using H265X stream or so called H265+ and you can use H264 preset for frigate |
|
Thank you for sharing your config @a2nt!
@NickM-27 Is there any pixel format that should be used when encoding? I didn't set the pixel format for encoding. frigate/frigate/ffmpeg_presets.py Lines 97 to 98 in 7d157df I don't know if there is there is a default value or if the pixel format is left unchanged, the rk-ffmprg docs don't mention it. |
|
To my original transcoding issue:
So, some minutes after starting it suddenly works. However, I am not really happy with this, because of the errors in the logs and I don't know, why there is this problem directly after starting. |
Agreed, but will it slow down detectors? I mean detectors work on raw video stream, but if u will transcode it should have some kind delay
Sorry, just thought you had a warning about pixel format, but it was ffprobe results. |
|
@a2nt If you use transcoding on your detect stream, it will add a delay, yes. However, my config above uses the h265 stream from the camera and just decodes it for detection, so no transcoding on this stream. Only the stream used for recording is transcoded above. |
|
I don't know why this would be, perhaps the data coming out of ffmpeg isn't usable for rtsp at first. I would suggest maybe creating a dummy stream in go2rtc, say This will give you an ffmpeg command that go2rtc generates and hopefully provide some info. And also provide more info for what's going on with the command we expect to work. |
|
I am not sure what you mean, with creating a dummy stream in go2rtc. Should I replace the However, I used this config to generate a trace output of my stream: This is the go2rtc trace output (these messages repeat regularly) This is the output after some minutes, when everything works suddenly (I left out repeating lines with The debug output of ffmpeg: |
|
is the stream really only 5 fps? |
|
yes |
|
I tried it without hw transcoding using libx264 and the same errors occurred. So, this is not directly related to the hardware transcoding part. Maybe the ffmpeg binary is faulty. |
|
Well, now i am puzzled. I used the latest static ffmpeg build from btbn and the error still exists. Perhaps one of the dependent libraries that btbn uses broke. I used FFmpeg 6.0 in both cases. Here is the go2rtc trace log: |
|
I would definitely recommend using the btbn build that frigate uses, many users are encoding without issues |
|
Yes, I will try this next. |
|
I have the same error with the frigate:stable release from ghcr. Does this mean my cam sends invalid data? |
|
Yes that seems to be the case, I've not had this issue. You could try using some MP4 file and transcoding that. |
|
This is my latest docker-compose.yml: this is my config.yml: |
|
Since the issue is on my side, I will do the troubleshooting later. Consider this issue closed for now. When I have more time, I will look at it again and maybe open a new issue with my new insights. Thanks for the help, I really appreciate it! But my main focus is still to enable the rockchip platform for the next release:
Is this the right approach or should I continue differently? |
|
I think go2rtc presets sounds good, at that point I think we'll be ready to push beta 6 and at that point we'd only want to merge bug fixes or docs changes. I understand the want to add more features or other things but I think what's here now (potentially including go2rtc presets) is a great start and pushing to stable will provide more opportunity for exposure to get more users and info. It's always possible to do a 0.13.1 with more fixes after user feedback is collected, we usually done one or two post releases |
|
I absolutely agree 👍🏻 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the problem you are having
I currently try to find the right ffmpeg options for go2rtc transcoding. However, the recording process does not seem to create recordings. The mse live stream in the browser from go2rtc works.
Version
0.13.0-FE52A49
Frigate config file
docker-compose file or Docker CLI command
Relevant log output
FFprobe output from your camera
Operating system
Other Linux
Install method
Docker Compose
Network connection
Wired
Camera make and model
Ctronics 8MP PTZ
Any other information that may be helpful
This command produces a working out.mp4:
sudo ./ffmpeg -hide_banner -fflags +genpts -rtsp_transport tcp -i "rtsp://127.0.0.1:8554/Cam" -c copy out.mp4The text was updated successfully, but these errors were encountered: