[Config Support]: Rotated camera does not hold proper aspect ratio

[derzahla]

Describe the problem you are having

I have a doorbell cam that streams sideways by default, so I use go2rtc to rotate the image and forcing the proper height/width. However I cant get the proper aspect ratio to stick. In the frigate UI, when first opened, it will usually show the correct width/height:

But after a few seconds it will switch to the inverted width/height of what I am setting in go2rtc.

When I make the camera fullscreen it will always use the inverted width/height, resulting in a vertically smushed and horizontally stretched stream. So is the same viewing recordings:

Note: This has been a problem for me for a long time, nothing specific to version 0.17.0.

Am I missing something in my config or is this a bug?

Version

0.17.0

Frigate config file

- ffmpeg:rtsp://user:pass@wvdb1.iot.local:554/ch0#video=h264#rotate=90#width=1080#height=1920#audio=copy#hardware

Relevant Frigate log output

none

Relevant go2rtc log output

none

Frigate stats

n/a

Operating system

Debian

Install method

Docker Compose

docker-compose file or Docker CLI command

n/a

Object Detector

RKNN

Screenshots of the Frigate UI's System metrics pages

No response

Any other information that may be helpful

No response

[inkeep-ai-assistant[bot]]

The aspect ratio switching behavior you're experiencing on the Live dashboard is a known characteristic of how Frigate handles streams. Frigate uses different streams for different purposes, and with Smart Streaming enabled, it shows a static image from the detect stream when no activity is present, then switches to the live stream when motion is detected. (1)

The camera image will change size if your streams use different aspect ratios. To prevent this, you need to make the detect stream match the go2rtc live stream's aspect ratio (resolution does not need to match, just the aspect ratio). (1)

Since you're rotating the stream to 1080x1920 (portrait orientation), you need to ensure your detect configuration also uses a matching portrait aspect ratio. For example:

cameras:
  your_doorbell_cam:
    detect:
      width: 720
      height: 1280  # Maintains 9:16 portrait aspect ratio to match your rotated stream

(1), (2)

Additionally, when using go2rtc's ffmpeg source for rotation and transcoding, the stream format is being re-encoded. If the video codec might be unsupported by your browser or if there are issues with the rotated output, you may want to check the go2rtc web interface at port 1984 to verify the stream is being received correctly with the expected dimensions. (3)

For recordings specifically, ensure the recording stream input also receives the properly rotated stream from go2rtc's restream output rather than the original camera stream directly.

📚 Sources:

1. Live View
2. Full Reference Config
3. Configuring go2rtc

---

Have another question? Just tag @inkeep.

[derzahla]

@inkeep I am setting the proper width/height in the detect section as well:

wvdb1:
enabled: true
lpr:
enabled: false
ffmpeg:
inputs:
- path: rtsp://127.0.0.1:8554/wvdb1
input_args: preset-rtsp-restream
roles:
- record
- detect
- audio
detect:
enabled: true
width: 1080
height: 1920
fps: 5

Viewing the stream in go2rtc on port 1984 shows the distorted aspect ratio as well. Maybe my config is wrong?

[inkeep-ai-assistant[bot]]

Since the distorted aspect ratio is visible directly in go2rtc's web interface at port 1984, the issue is occurring at the go2rtc stream level before Frigate even processes it. (1)

Your go2rtc ffmpeg source configuration appears to be the problem area. When using the ffmpeg module in go2rtc with rotation and dimension parameters, the syntax and parameter order matter. (1)

Looking at your go2rtc config:

- ffmpeg:rtsp://user:pass@wvdb1.iot.local:554/ch0#video=h264#rotate=90#width=1080#height=1920#audio=copy#hardware

(1)

A few things to check:

1. Verify the source stream dimensions first - If your original camera stream is outputting at a resolution that doesn't cleanly rotate to 1080x1920, forcing those dimensions may cause stretching/distortion.

2. Try without forcing dimensions - Let go2rtc handle the rotation without explicitly setting width/height to see what the natural rotated dimensions would be, then adjust your detect config to match.

3. Check codec compatibility - If the video doesn't play correctly in go2rtc's web interface, the video codec might be unsupported. If using H265, try switching to H264. (1)

Since this is a go2rtc ffmpeg transcoding/rotation issue rather than a Frigate configuration issue, I don't have specific documentation on the exact ffmpeg rotation parameters supported by go2rtc. You may want to consult the go2rtc FFmpeg documentation for the correct syntax for rotation with dimension preservation.

📚 Sources:

1. Configuring go2rtc

---

Have another question? Just tag @inkeep.

[derzahla]

@inkeep the original stream is 1920x1080. Without forcing the width and height the stream does not appear in the frigate UI. It just shows an empty black box with "no frames have been received" message. HOWEVER, when I view the stream on port 1984 it is viewable and in the correct aspect ratio! So it looks like Frigate just doesnt like the rotated stream for some reason?

[inkeep-ai-assistant[bot]]

This is an interesting finding. The fact that the stream displays correctly in go2rtc's web interface (port 1984) but Frigate shows "no frames have been received" suggests the issue is with how Frigate is receiving or processing the rotated stream from go2rtc's restream.

A few things to investigate based on the documentation:

1. Detect resolution mismatch - Frigate uses the detect width and height settings to determine the expected frame dimensions. (1) If the rotated stream dimensions don't exactly match what Frigate expects, it may fail to process frames. Try ensuring your detect dimensions precisely match the rotated output:

detect:
  width: 1080
  height: 1920

(1)

2. Aspect ratio and jsmpeg rendering - The Live view documentation mentions that incorrect dimensions in your detect width or height can cause rendering issues with the jsmpeg player. It recommends adjusting to a standard aspect ratio. (2) Since 1080x1920 is a 9:16 ratio (standard portrait), this should be fine, but you could try slightly adjusting if needed.

3. Stream codec compatibility - For Live view, the recommended video codec is H.264 and audio codec is AAC. (2) Verify that your go2rtc ffmpeg transcoding is outputting H.264. The #video=h264 parameter in your config should handle this, but confirm the output codec in go2rtc's stream info.

4. Check stream info - You can access go2rtc stream info at /api/go2rtc/streams which can be helpful to debug and provide useful information about your camera streams. (3) This may reveal if there's a mismatch between what go2rtc is outputting and what Frigate expects.

Unfortunately, the specific interaction between go2rtc's rotation/transcoding and Frigate's frame reception isn't fully documented in the available sources. This may require further debugging or could be a bug worth reporting with the specific details about the rotated stream working in go2rtc but not in Frigate.

📚 Sources:

1. Full Reference Config
2. Live View
3. Restream

---

Have another question? Just tag @inkeep.

[derzahla]

@inkeep

1. the detect resolution matches and shown in my pasted config
2. What other aspect ration/resolutions should I try?
3. The camera does output h265 but is being converted to h264 by go2rtc
4. i do not see anything out of place in the stream info

[inkeep-ai-assistant[bot]]

Based on what you've described, here are some specific things to try:

2. Alternative aspect ratios/resolutions to try:

The Live view documentation specifically mentions adjusting detect dimensions to standard aspect ratios when experiencing display issues. (1) Examples given include:

• 640x352 becomes 640x360
• 800x443 becomes 800x450
• 2688x1520 becomes 2688x1512

For your 9:16 portrait orientation, try these standard portrait resolutions:

• 720x1280 (standard 9:16)
• 540x960 (standard 9:16)
• 1080x1920 should already be standard, but try 1080x1912 or 1080x1928 to see if slight adjustments help (1)

3. H.265 to H.264 conversion:

Since your camera outputs H.265 and you're transcoding to H.264, this is the correct approach for browser compatibility. (2) The documentation confirms that if using H265, you should switch to H264, and if unable to switch from H265 to H264, re-encode the video using FFmpeg parameters. (2)

Additional debugging step:

If the stream works correctly in go2rtc's web interface but not in Frigate, try enabling "compatibility mode" in your camera group dashboard's stream settings. This option is specifically mentioned for cases where the live stream displays color artifacts or has rendering issues. (1) However, the documentation notes that depending on your browser and device, more than a few cameras in compatibility mode may not be supported. (1)

Given that the rotated stream displays correctly in go2rtc but Frigate can't receive frames without forcing dimensions (which then causes distortion), this appears to be a specific interaction issue between rotated/transcoded streams and Frigate's frame processing that isn't fully covered in the available documentation.

📚 Sources:

1. Live View
2. Configuring go2rtc

---

Have another question? Just tag @inkeep.

[derzahla]

@inkeep

Here are the errors in the frigate log for this particular stream:
e17 | 2026-03-13 18:50:41.559342067 [2026-03-13 18:50:41] watchdog.wvdb1 INFO : No frames received from wvdb1 in 20 seconds. Exiting ffmpeg...
frigate17 | 2026-03-13 18:50:41.559954273 [2026-03-13 18:50:41] watchdog.wvdb1 INFO : Waiting for ffmpeg to exit gracefully...
frigate17 | 2026-03-13 18:50:41.663792693 [2026-03-13 18:50:41] frigate.video ERROR : wvdb1: Unable to read frames from ffmpeg process.
frigate17 | 2026-03-13 18:50:41.664249732 [2026-03-13 18:50:41] watchdog.wvdb1 INFO : Waiting for capture thread to exit...
frigate17 | 2026-03-13 18:50:41.664684314 [2026-03-13 18:50:41] frigate.video ERROR : wvdb1: ffmpeg process is not running. exiting capture thread...
frigate17 | 2026-03-13 18:50:41.666154307 [2026-03-13 18:50:41] watchdog.wvdb1 ERROR : The following ffmpeg logs include the last 100 lines prior to exit.
frigate17 | 2026-03-13 18:50:41.666690387 [2026-03-13 18:50:41] ffmpeg.wvdb1.detect ERROR : [Parsed_scale_rkrga_0 @ 0xaaaadd626070] No hw context provided on input
frigate17 | 2026-03-13 18:50:41.667183010 [2026-03-13 18:50:41] ffmpeg.wvdb1.detect ERROR : [Parsed_scale_rkrga_0 @ 0xaaaadd626070] Failed to configure output pad on Parsed_scale_rkrga_0
frigate17 | 2026-03-13 18:50:41.667917423 [2026-03-13 18:50:41] ffmpeg.wvdb1.detect ERROR : Error initializing filters!
frigate17 | 2026-03-13 18:50:41.668545962 [2026-03-13 18:50:41] ffmpeg.wvdb1.detect ERROR : Error marking filters as finished
frigate17 | 2026-03-13 18:50:41.669075334 [2026-03-13 18:50:41] ffmpeg.wvdb1.detect ERROR : [out#1/rawvideo @ 0xaaaadd58e830] Nothing was written into output file, because at least one of its streams received no packets.

[inkeep-ai-assistant[bot]]

The error logs reveal the root cause of your issue. The key error is:

[Parsed_scale_rkrga_0 @ 0xaaaadd626070] No hw context provided on input

This indicates a hardware acceleration incompatibility between the stream coming from go2rtc (which was transcoded/rotated) and Frigate's RKNN/Rockchip hardware acceleration for decoding. The scale_rkrga filter is Rockchip's hardware-accelerated scaling filter, and it's failing because the input stream doesn't have the proper hardware context.

When go2rtc transcodes and rotates your stream, the output is a software-decoded stream. When Frigate then tries to apply Rockchip hardware acceleration to decode/scale this already-transcoded stream, the hardware context chain is broken.

Potential solutions:

1. Disable hardware acceleration for this specific camera - You can override the hwaccel_args for just this camera to use CPU decoding instead: (1)

cameras:
  wvdb1:
    ffmpeg:
      hwaccel_args: ""  # Disable hardware acceleration for this camera
      inputs:
        - path: rtsp://127.0.0.1:8554/wvdb1
          input_args: preset-rtsp-restream
          roles:
            - record
            - detect
            - audio
    detect:
      enabled: true
      width: 1080
      height: 1920
      fps: 5

(1)

The documentation notes that you may need to disable hardware acceleration (hwaccel_args: "") for dummy/test cameras when using transcoded streams. (2) The same principle applies here since your stream is being transcoded by go2rtc before Frigate receives it.

2. Alternative approach - If CPU decoding causes high CPU usage, consider whether the rotation can be handled differently, though this may require changes outside of Frigate's configuration.

📚 Sources:

1. Full Reference Config
2. Analyzing Object Detection

---

Have another question? Just tag @inkeep.

[derzahla]

@inkeep hwaccel_args: "" on that specific camera seems to fix it. But im not sure I understand the problem. go2rtc has already converted and rotated the video, presumably in hardware. Why does frigate have a problem with the output of go2rtc only on this camera? What is the 'hardware context' that needs to be provided and how can this be fixed so I dont have disable hwaccel?

[inkeep-ai-assistant[bot]]

The issue relates to how hardware-accelerated video decoding works at a fundamental level.

Why this happens:

When go2rtc transcodes and rotates your stream using its #hardware flag, it uses hardware acceleration on its side to produce the output. However, the output of that transcoding is a standard H.264 video stream delivered over RTSP. This output stream doesn't carry the special "hardware context" that Rockchip's hardware decoder (scale_rkrga) needs to process it using the GPU memory pipeline.

Hardware acceleration for video decoding works by keeping video frames in GPU memory throughout the decode and scaling pipeline. When Frigate receives a stream that was already decoded/transcoded elsewhere (even if that transcoding used hardware), the frames are coming over the network as a regular encoded stream. When Frigate's Rockchip hardware decoder tries to apply hardware-accelerated scaling, it expects the frames to already be in GPU memory with the proper hardware context—but they're not, because they came from go2rtc's restream. (1)

This only affects your rotated camera because your other cameras send their original streams directly to Frigate (via go2rtc restream without transcoding), allowing Frigate's hardware decoder to establish the full hardware context from the start. (1)

Can this be fixed without disabling hwaccel?

The available documentation doesn't describe a method to re-establish hardware context for streams that have been transcoded by go2rtc. The hardware acceleration documentation focuses on ensuring hardware devices are accessible and using the correct presets for direct camera streams. (1)

Your current workaround of disabling hwaccel_args for just that camera is the documented approach for handling transcoded/test streams. (2) Since it's only one camera, the CPU impact should be manageable.

📚 Sources:

1. High CPU Usage
2. Full Reference Config

---

Have another question? Just tag @inkeep.

[derzahla]

@inkeep Your following statement is untrue:

"This only affects your rotated camera because your other cameras send their original streams directly to Frigate (via go2rtc restream without transcoding), allowing Frigate's hardware decoder to establish the full hardware context from the start. (1)"

While wvdb1 is the only camera I am rotating, I am using go2rtc to transcode many cameras from h265 to h264. Why is frigate trying to do 'scaling'? It just needs to decode the h264 stream from go2rtc, no resolution changes should be needed.

[inkeep-ai-assistant[bot]]

You're correct, and I apologize for the inaccurate statement. Let me address your actual question.

Why Frigate is attempting scaling:

Frigate applies scaling when the stream resolution doesn't match the configured detect width and height. (1) Looking at your config, you have:

detect:
  width: 1080
  height: 1920

(1)

Frigate uses the detect width and height settings to determine the expected frame dimensions for the input with the detect role. (1) If the incoming stream resolution differs from these values, Frigate will scale the frames to match.

The error [Parsed_scale_rkrga_0 @ ...] indicates Frigate is invoking the Rockchip hardware scaling filter. This happens because either:

1. The rotated stream's actual output dimensions from go2rtc don't exactly match 1080x1920
2. Or Frigate's hardware acceleration pipeline includes scaling as part of its processing chain regardless

Why your other H.265→H.264 transcoded cameras work:

The difference is likely that those cameras maintain their original resolution through transcoding, and that resolution matches what Frigate expects. The rotation operation changes the dimensional relationship in a way that may cause a mismatch or trigger the scaling path differently.

Unfortunately, the available documentation doesn't provide detailed information about the internal hardware acceleration pipeline behavior or why the scale_rkrga filter specifically fails on transcoded streams while other transcoded streams work. (2) This appears to be a specific interaction with Rockchip hardware acceleration that isn't fully documented.

📚 Sources:

1. Full Reference Config
2. High CPU Usage

---

Have another question? Just tag @inkeep.

[derzahla]

@inkeep ok, when I use ffplay on the stream rtsp://frigate:8554/wvdb1, the resolution is detected as 1536x2304. Strange, why would it be upscaling it? I tried to turn hardware decoding back on and set the detect section to width=1536 and height=2304m but I get the same errors:

[Parsed_scale_rkrga_0 @ 0xaaaaec0bdcb0] No hw context provided on input
ERROR : [Parsed_scale_rkrga_0 @ 0xaaaaec0bdcb0] Failed to configure output pad on Parsed_scale_rkrga_0

If you dont have any more ideas hopefully a dev can chime in. Without hwaccel that one cam eats up over 50% of the cpu.

[inkeep-ai-assistant[bot]]

The 1536x2304 resolution is unexpected—your original camera is 1920x1080, which when rotated 90° should become 1080x1920. The upscaling to 1536x2304 is happening in go2rtc's ffmpeg transcoding, likely due to the #width=1080#height=1920 parameters in your go2rtc config interacting unexpectedly with the rotation.

The scale_rkrga error persists regardless of matching detect dimensions because the fundamental issue is that Rockchip's hardware acceleration pipeline cannot process streams that were transcoded by go2rtc. The stream lacks the GPU memory context that scale_rkrga requires—this isn't about resolution matching, it's about the stream's origin.
(1)

Regarding the upscaling issue:

Your go2rtc config:

- ffmpeg:rtsp://user:pass@wvdb1.iot.local:554/ch0#video=h264#rotate=90#width=1080#height=1920#audio=copy#hardware

(2)

Try removing the explicit width/height parameters and let go2rtc handle the rotation naturally:

- ffmpeg:rtsp://user:pass@wvdb1.iot.local:554/ch0#video=h264#rotate=90#audio=copy#hardware

Then check ffplay again to see what resolution the rotated stream actually outputs, and set your detect dimensions to match that exactly.

The core hwaccel incompatibility with Rockchip and transcoded streams isn't documented with a workaround in the available sources. A developer would need to provide guidance on whether there's a way to make scale_rkrga work with restreamed content, or if CPU decoding is the only option for this use case.

📚 Sources:

1. Installation
2. Restream

---

Have another question? Just tag @inkeep.

[derzahla]

@inkeep I had already removed the "#width=1080#height=1920" from the go2rtc ffmpeg line.

However, I just tried adding it back and inverting the width and height, ie: "ffmpeg:rtsp://thingino:berbderbz@wvdb1.iot.ded.haus:554/ch0#video=h264#width=1920#height=1080#rotate=90#audio=copy#hardware".

This results in the go2rtc output stream now being 1080x1920, interestingly.

But without hardware accel disabled in frigate for the camera I still get the Failed to configure output pad on Parsed_scale_rkrga_0 error.

[inkeep-ai-assistant[bot]]

Good progress on getting the correct 1080x1920 output resolution from go2rtc. The persistent scale_rkrga error confirms that the Rockchip hardware acceleration issue is fundamentally about the stream being transcoded/rotated by go2rtc, not about resolution mismatches.

The available documentation doesn't provide a method to make Rockchip hardware acceleration work with streams that have been transcoded by go2rtc. (1) The scale_rkrga filter requires frames to be in GPU memory with proper hardware context, which isn't present when the stream comes from go2rtc's restream after transcoding.

Your options based on the documented configurations:

1. Keep hwaccel disabled for this camera (your current working solution):

cameras:
  wvdb1:
    ffmpeg:
      hwaccel_args: ""

(2)

2. Consider if rotation can happen at the camera level - If your doorbell camera firmware supports rotating the output stream natively, that would allow Frigate to receive the stream without go2rtc transcoding, preserving the hardware context.

The 50%+ CPU usage you're seeing without hwaccel is significant. This specific incompatibility between Rockchip's scale_rkrga and go2rtc-transcoded streams isn't addressed in the available documentation—a developer would need to confirm whether there's an alternative hardware acceleration path or if this is a known limitation of the RKNN/Rockchip platform when processing restreamed content.

📚 Sources:

1. Restream
2. Full Reference Config

---

Have another question? Just tag @inkeep.

[derzahla]

@inkeep ok it looks like we are stuck. rotation at the camera level causes very high load on the camera so not a good option.

I want to reiterate though, that many other streams are working fine that ARE transcoded by go2rtc first from h265->h264. So Frigate doesnt appear to have any problem with streams that are transcoded by go2rtc. Only this stream that is also rotated. Hopefully someone else can help shed some light on how to fix

[inkeep-ai-assistant[bot]]

You've identified an important distinction—the issue is specifically with rotation combined with transcoding, not transcoding alone. This narrows down the problem to how the rotation operation in go2rtc's ffmpeg module interacts with Rockchip's hardware acceleration pipeline.

The available documentation doesn't address this specific scenario of rotated streams and Rockchip hardware acceleration compatibility. (1) The go2rtc configuration guides cover transcoding and rotation parameters, but don't document hardware context requirements for rotated output streams when consumed by Rockchip-based hardware decoders. (1)

What the documentation does confirm:

When using the ffmpeg module in go2rtc for transcoding, the stream is re-encoded. (1) The rotation operation likely changes something about the stream's metadata or encoding characteristics that breaks compatibility with scale_rkrga specifically, while standard H.265→H.264 transcoding without rotation preserves whatever properties Rockchip needs.

Your working configuration for reference:

cameras:
  wvdb1:
    ffmpeg:
      hwaccel_args: ""
      inputs:
        - path: rtsp://127.0.0.1:8554/wvdb1
          input_args: preset-rtsp-restream
          roles:
            - record
            - detect
            - audio
    detect:
      width: 1080
      height: 1920

(2)

This appears to be a platform-specific limitation with Rockchip/RKNN that isn't documented. A developer familiar with the Rockchip ffmpeg implementation would need to explain why rotation specifically breaks the hardware context while transcoding alone doesn't.

📚 Sources:

1. Configuring go2rtc
2. Full Reference Config

---

Have another question? Just tag @inkeep.

[derzahla]

@inkeep I noticed that 0.17.0-rk build is using ffmpeg v6. It also has ffmpeg v7 installed in the container. Is there a way to try using ffmpeg v7 instead of v6 without switching to all custom 'exec' calls in go2rtc?

[NickM-27]

keep in mind ffmpeg 7 is standard arm64, does not have any RK hwacel

[derzahla]

@NickM-27 I was afraid that may be the case. But it looks like ffmpeg 7.0 is compiled with --enable-rkmpp and --enable-rkrga, I dont notice any options that look rockchip related enabled on the v6.0 version. Are you sure?

Unfortunately the config change that @inkeep suggested only switches the Frigate launched ffmpeg process version though. The ffmpeg called by go2rtc(which is where the rotation is done) still uses ffmpeg v6.

[TCS-UK]

I had a very similar issue and had to use exec in go2rtc. (Needs adding to docker-compose to work).

This does a few more things than just rotate—like set fps, gop, gpu, and framerate. When rotating, you can only seem to have the rotation work done on the CPU and the rest of the pipeline on gpu with Nvidia due to missing npp in ffmeg (as its non free). Not sure what hardware you're using.

go2rtc config:

front_door_raw:
  - rtsp://{FRIGATE_CAMLOGIN}@192.168.20.77:554/Streaming/Channels/101

front_door:
  - exec:/usr/lib/ffmpeg/7.0/bin/ffmpeg -hide_banner -rtsp_transport tcp -hwaccel cuda -hwaccel_device 0 -i rtsp://127.0.0.1:8554/front_door_raw -an -vf transpose=2,hwupload_cuda=device=0,scale_cuda=1520:2688 -c:v h264_nvenc -gpu 0 -preset p1 -tune ll -rc cbr -b:v 8M -maxrate 8M -bufsize 8M -r 15 -g 15 -keyint_min 15 -bf 0 -f rtsp -rtsp_transport tcp {{output}}

front_door_sub:
  - exec:/usr/lib/ffmpeg/7.0/bin/ffmpeg -hide_banner -rtsp_transport tcp -hwaccel cuda -hwaccel_device 0 -i rtsp://127.0.0.1:8554/front_door_raw -an -vf transpose=2,hwupload_cuda=device=0,scale_cuda=720:1280 -c:v h264_nvenc -gpu 0 -preset p1 -tune ll -rc cbr -b:v 2M -maxrate 2M -bufsize 2M -r 5 -g 5 -keyint_min 5 -bf 0 -f rtsp -rtsp_transport tcp {{output}}

frigate config:

cameras:
  front_door:
    enabled: true
    ffmpeg:
      hwaccel_args: preset-nvidia  
      inputs:
        - path: rtsp://127.0.0.1:8554/front_door
          input_args: preset-rtsp-restream
          roles:
            - record
        - path: rtsp://127.0.0.1:8554/front_door_sub
          input_args: preset-rtsp-restream
          roles:
            - detect
    detect:
      enabled: true
      width: 720
      height: 1280
      fps: 5
    live:
      streams:
        SD Stream: front_door_sub # Using Sub Stream as Primary in UI
        HD Stream: front_door

[NickM-27]

actually yeah that is right, I did not realize we got both versions in rockchip build. as far as inkeeps suggestion, the same config under the go2rtc config works

[TCS-UK]

Thanks for the reply. So it sounds like you are saying that even when you use the custom 'exec' the rotation is still done on the CPU. Am I misunderstanding? I am using rockchip hardware, on the latest 0.17.0 branch and my default ffmpeg command looks like this for the cam I am rotating:

/usr/lib/ffmpeg/6.0/bin/ffmpeg -hide_banner -loglevel warning -threads 2 -user_agent FFmpeg Frigate/0.17.1-416a9b7 -rtsp_transport tcp -timeout 10000000 -i rtsp://127.0.0.1:8554/wvdb1 -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c:v copy -c:a aac /tmp/cache/wvdb1@%Y%m%d%H%M%S%z.mp4 -r 5 -vf fps=5,scale=1080:1920 -threads 2 -f rawvideo -pix_fmt yuv420p pipe

If you were able to get rotation to work in hardware with the custom exec, what exactly did you need to modify on ffmpeg switches to achieve it?

I’m using a nvidia gpu and I know for 100% the rotate cannot be done using it. This is only due to ffmpeg not being complied with the required flags to enable the needed filters. In regards to your hardware, I have no idea. Hopefully someone else will jump in 🤞

[derzahla]

@NickM-27 I tried a bunch of combinations of versions without success. Specifying ffmpeg: path: "7.0" under the go2rtc section didn't seem to do anything and I couldnt get my custom v7 exec command to work either.

Its weird, since the rotation actually does seem to happen in hardware on go2rtc, but afterwards when frigate launched ffmpeg tries to decode go2rtcs stream that is when it then fails (unless I disable hwaccel for frigate ffmpeg)

My last hail mary was to just force ffmpeg v7 globally in the frigate config. That actually seemed to work! I no longer need 'hwaccel_args: "" ' under the camera and I have confirmed every ffmpeg process(including the go2rtc launched ones) are all using v7!

@NickM-27 do you know why v7 isnt default yet? Any downsides to using it?

[NickM-27]

#19227

[derzahla]

@NickM-27 ok great. thanks for the background. so I am assuming that the included /usr/lib/ffmpeg/7.0 is actually 7.1 then? I t only displays "ffmpeg version a8c04e01e7-20250720" so I wasnt clear

[inkeep-ai-assistant[bot]]

Yes, you can configure Frigate to use FFmpeg 7 instead of the default version. In your Frigate config, you can set the ffmpeg path globally or per-camera: (1)

ffmpeg:
  path: "7.0"

(1)

This can be set globally to use FFmpeg 7 for all cameras, or at the camera level to use it only for specific cameras. (2)

The documentation specifically notes this option when encountering certain hardware acceleration errors on Rockchip platforms. If you see errors like: (2)

[Parsed_scale_rkrga_0 @ ...] No hw context provided on input
[Parsed_scale_rkrga_0 @ ...] Failed to configure output pad on Parsed_scale_rkrga_0
Error initializing filters!

(2)

...you should try upgrading to FFmpeg 7 using this config option. (2)

Note that this setting controls which FFmpeg Frigate uses for its processing—it's separate from the path parameter under camera inputs (which specifies the RTSP stream URL). (2)

📚 Sources:

1. Full Reference Config
2. Video Decoding

---

Have another question? Just tag @inkeep.

[inkeep-ai-assistant[bot]]

You're correct that the ffmpeg.path: "7.0" config option only affects the FFmpeg process that Frigate launches directly—it doesn't change which FFmpeg go2rtc uses internally for its transcoding operations. (1)

For go2rtc to use a different FFmpeg version, you would need to use the exec source type in your go2rtc configuration to explicitly call the FFmpeg 7 binary path. Based on the earlier community suggestion in this thread, you could configure go2rtc to use an explicit exec call with the FFmpeg 7 path:

go2rtc:
  streams:
    wvdb1_raw:
      - rtsp://user:pass@wvdb1.iot.local:554/ch0
    wvdb1:
      - exec:/usr/lib/ffmpeg/7.0/bin/ffmpeg -hide_banner -rtsp_transport tcp -i rtsp://127.0.0.1:8554/wvdb1_raw -vf transpose=1 -c:v h264 -f rtsp -rtsp_transport tcp {{output}}

(2), (1)

This approach uses the raw stream as input and explicitly calls FFmpeg 7.0 for the rotation/transcoding. You'll need to adjust the transpose value and other parameters for your specific rotation needs.

Regarding whether FFmpeg 7 in the -rk image has Rockchip hardware acceleration support—NickM-27's comment suggests it may not. The documentation confirms that FFmpeg 7 can be used on Rockchip platforms, but the specific compilation flags would determine hardware acceleration availability. (1)

📚 Sources:

1. Video Decoding
2. Camera Specific Configurations

---

Have another question? Just tag @inkeep.