Zoom on rotated 90 degrees cam when viewing direct to wire is stretched the wrong way.

[e46lux]

I have a camera that's rotated 90 degrees from horizontal to vertical in BI. Any streaming choice that is not viewing a direct to wire stream zooms in correctly. Direct to wire is streching the image incorrectly. I believe this worked correctly in 228 and prior. Currently on 229 direct to wire scroll zoom stretches a horizontal camera height-wise, however, when direct to wire streaming the camera is steamed in it's original aspect ratio (not rotated) so you get incorrect scroll zoom ratio - image is stretched height-wise instead of width-wise, if that makes sense. Thanks for all your hard work!

[bp2008]

I see what you mean. Thanks for reporting.

There is a combination of multiple things coming together to cause this issue.

UI3 sizes and scales the video player according to the dimensions defined in the camera's metadata, disregarding the actual dimensions of the video stream that is received. It is done this way because in most cases this is the simplest way to render the video player at a consistent, predictable size no matter what streaming quality is chosen.

Direct-to-wire when combined with Blue Iris's rotation feature causes this to be a problem. It prevents Blue Iris from providing a stream with the appropriate aspect ratio, so UI3 handles it poorly.

The HTML5 video player adds some complexity too, because the HTML <video> element does not act like other drawing surfaces. When UI3 sizes the <video> element to 1280x720 for example, and the actual video resolution is 720x1280, then the video gets drawn letterboxed in the middle. You may not have even noticed this was happening because it would only have an effect in certain viewport sizes, and when affected you might intuitively zoom in to counteract this letterboxing without thinking about it.

UI3-228 introduced a new rendering mode because of numerous bugs when you zoom in on a <video> element (including decoder crashes, video corruption, screen going black). Since version 228, when you zoom in, the <video> element gets swapped with a <canvas> element because <canvas> can be safely zoomed without triggering those bugs. However the <canvas> does not do the same aspect ratio preservation as the <video> element does. That is why you see such a wildly different presentation when you use zoom on a stream that does not match the expected aspect ratio.

I'm not sure what I can do to fix this without making the video scaling code more hideously complex and bug prone.

So what this boils down to is, direct-to-wire has compatibility problems, and 90 degree software rotation of the video stream is one of the things it has problems with.

[e46lux]

Fair enough! Thanks for the quick response! This is not an extremely important issue to me as I only have 1 camera and everything else works fantastically.

I've basically given up on attempting to get wyze cams to stay stable over wifi when streaming directly to BI, so I ended up using rtsp-simple-server to re-stream and it has been rock solid with 7 cameras over wifi! 0 dropped frames in BI after 48 hours so far! rtsp-simple-server even allows you to include ffmpeg inside the docker container, so i'll be attempting to rotate the stream inside the docker next.

Cheers!

EDIT: Curious if you have any thoughts on my experience with direct to wire streaming on iOS devices. I'm guessing it has something to do with the way Safari handles the frames, but even an iPhone 13 Pro Max it is unable to keep up with 30fps on wifi. iOS devices seem to all start lagging once you open the stream and the lag ballons out to a constantly increasing delayed video. My S22 Ultra is able to stream direct to wire at 4k 30fps all day, same on a win 10 desktop, but iOS struggles.

[bp2008]

No idea why iOS struggles with it.

That is interesting that rtsp-simple-server makes your wifi cameras stable. I use it for my wifi doorbell cam because I have two Blue Iris machines consuming the stream and didn't want to double the wifi traffic. It still drops out frequently in Blue Iris.

[e46lux]

The secret sauce was disabling bluetooth coexistence on my 2.4ghz channel. As soon as I enable it my dropped RTP packets (in rtsp-simple-server) go from 0-15 to over 50-500 every few seconds. This is on an AI mesh connected wyzecam v3. I have another v3 and 5 v2s. BI has trouble with dropepd RTP packets and causes it to go into the No Signal mode and with v3's it basically doesn't recover, with v2's by the time it recovers you lose like 20-50 seconds of stream. rtsp-simple-server somehow handles this with grace. With bluetooth coexistance disabled, I get maybe a half a second to a second drop here and there when I'm streaming Steam Big Picture over 5Ghz. And my bedroom bluetooth headphones have started to act up and lose signal in certain spots of the bed. However, this is over 2 years of troubleshooting and this is the best setup I've gotten to so far. I disabled b on 2.4Ghz, WiFi Agile Multiband being on seems to have a good effect on reliability, Target Wake Time disabled, Channel 11, extension channel below, Protected Management Frames capable - with this disabled I get an even better connection but my R4 mini stops connecting to wifi :/ Short preamble, TX bursting and WMM enabled (these were important), and I kept beamforming options enabled. Airtime fairness disabled.

[bp2008]

You probably know this already but I suggest making sure your 2.4 GHz network is set to use 20 MHz channel width, not 40 MHz. Yes it can be slower but there isn't enough 2.4 GHz spectrum to go around and hogging 2/3 of it for one wifi network always seemed like a recipe for trouble to me.