Thread by @greentheonly

So here is some info about dashcam vs what Tesla stores for themselves.

As many of you may know, Tesla stores dashcam video in overly compressed h264 yuv420p (for compatibility?) at 36 fps with ~4Mbps bitrate.
On mcu cars it's main, and pillar cams, on MCU2 they added backup cam

(NB: it's interesting that original dashcam was using the narrow cam as the video source, but they switched to the more sensible main cam later, not exactly sure when).

All compression on hw2.5 is done on the b node that's otherwise idle. mcu jsut captures the stream from

the network and dumps it on sdcard using gstreamer. They probably decided even that marginal load is too much for mcu1 and that's why they did not add backup cam on mcu1. Even then plenty of reports of mcu2 "usb drive is slow".
In the code there's fisheye support too

but it's inactive and I imagine it's mostly because then those usb2 drives will become really-really overstretched.

Of course the main problem here is that this fas implemented in a very stupid manner where instead of storing the footage in the in-RAM buffer they just stream

it all to USB device and rotate in place, causing untold excess wear and otherwise stressing the subsystem needlessly.

Anyway, the reason why it's done on the B node is because A node ISP is already at 100% capacity (rated at 4K at 30 fps up to 100Mbps developer.download.nvidia.com/embedded/L4T/r…)

so you might wonder what is it that's hogging all that ISP capacity? Well, of course Tesla compresses same video in an in-RAM buffer from all 8 cameras into h265 at much higher bitrates (variable, 12-40Mbps observed) in 10bit as Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv)

This is another reason why on hw2.0 you don't get any dashcam - because Tesla needs go before yours even if they are 100% sure they will never need the footage (e.g. because the car is parked and using sentry mode).

Also in order to improve usefullness of the video for them, they store it as four "quadrants" - every pixel in the color filter pattern is stored as a separate PiP-like block. This looks strange, but allows you to reconstruct the original raw image much better without it being

destroyed by the bayering process or by compression without bayering (this Tesla knows first hand as they used to just do raw sensor dumps into h265 encoder until v9 or so)

This is how it looks like (actual file from car): filedropper.com/mainunprocessed

Of course the unfortunate sideeffect of it is we cannot really compare footage from the two as on our end we run our own debayering and such and their ISP also applies tons of sharpening and different kind of color correction (note the green light color)

I guess the only exception would be the backup camera that comes as color-correct yuv stream from the cam, but then having an mcu1 car I cannot easily get that dashcam stream myself.

So in order to demonstrate actual fine detail loss I am going to return to that old experiment with partially blocked camera sensors and just show a few frames of interest.

We'll use stop sign because it shows the problem most.

Ignore the washed out sky - that could be processed much better from the 10 bits we have, just see if you can read the actual word on the sign:
(sky tint is a byprocess of the camera cover)

here's another one, see the stop sign and the sign under it but also other detalization like the curb at the right

It's kind of annoying that Tesla puts their own needs ahead of those of the owners but such is life in Tesla land where the mission is everything or some such I guess.

At least now you know the data they get is much better than could be imagined from the footage.

btw in that "quadrant" video you can see pixels are arranged as:

CR
BC

note how things like stop lights and traffic signal have different intensity when different color filter is in front of the pixel. That's how most cams work nowadays but you never see it like this