Live view aspect ratio different than original camera stream

[rici44]

trafficstars

I setup Frigate v14 in privileged container on Raspberry Pi CM4 module and connected Tapo C120 camera as tapo source. Frigate automatically choose MSE/WebRTC streams which are provided by go2rtc v1.9.2.

If MSE stream is chosen then live view aspect ratio is different than original camera stream. Camera has stream aspect ratio 16:9 but go2rt v1.9.2 provide MSE stream in aspect ratio 4:3.

If WebRTC stream is chosen then live aspect ratio is the same as the original camera stream 16:9.

I tested standalone go2rtc v1.9.7 with the same config of the same camera and results are the same (MSE 4:3, WebRTC 16:9).

Is it possible to setup correct aspect ratio in MSE stream ? Is go2rtc doing something with original stream when providing MSE stream?

[AlexxIT]

The camera is probably wrongly sending this information about the ratio. It's a fairly common situation. Unfortunately I don't have any cameras with these problems to fix. You can try to use ffmpeg source.

[rici44]

The camera is probably wrongly sending this information about the ratio. It's a fairly common situation.

Why MSE and WebRTC streams are both OK in 16:9 when using Firefox browser?

Unfortunately I don't have any cameras with these problems to fix.

What would help to solve this exact camera?

You can try to use ffmpeg source

Won't it get more resources from CM4?

[AlexxIT]

• Different decoder implementations
• Probably FFmpeg
• Minor

[dgibbs64]

I have the same issue. I just moved from rtsp stream on my tapo camera to use tapo:// protocol since tp-link released a fix for the cloud password issue https://github.com/JurajNyiri/HomeAssistant-Tapo-Control/issues/551 . The recording is 16:9, but the live view is 4:3. ALso when I click to enable 2-way audio the steam goes back to 16:9. Also noticed that this is not an issue in firefox but is in Edge (Chrome)

I am using a C320WS

[AlexxIT]

Nothing have changed. 16:9 for WebRTC and 4:3 for MSE. Some strange video metadata from TP-Link developers.

[dgibbs64]

Yeah, im getting the impression that just using rtsp might be the best option. I think 2-way audio might be the only thing I lose.

[adamoutler]

As a workaround to this go2rtc issue, I found the least invasive way to pre-process the stream is to add an ffmpeg compatibility layer as follows:

go2rtc:
  streams:
    driveway_stream: onvif://admin:[email protected]:8000?subtype=CH01
    driveway_stream_ffmpeg: ffmpeg:driveway_stream

This allows for simply changing the reference back to the source at a later time rather than working out new URLs and changing the original source.

[AlexxIT]

You right. FFmpeg can fix broken metadata. But it increases the start time of the stream.

[lngarrett]

Hi, I'm very new to go2rtc so I might be misunderstanding. Is this work around meant to preserve 2-way audio and also fix aspect ratio? I'm trying to achieve both, but the work around seems to break 2-way audio.

foocam_tapo:
      - tapo://admin:[email protected]
foocam:
      - ffmpeg:foocam_tapo

[AlexxIT]

streams:
  tapo:
  - ffmpeg:rtsp://...
  - tapo://...

[NevarVit]

On cameras with OpenIPC firmware there is the same problem :(

[AlexxIT]

I'll check my OpenIPC camera.

[borgqueenx]

Was there any luck fixing this issue?