It seems clear to me that there is a problem with the compression going on with both the new 4MP and the older 5231ZE in this footage. Compare this:
to this:
The footage from Nayr looks much better imho. Yes, different environment, different camera but both are 2MP Starlight cams. The ghosting/trailing and apparent transparency of the subject is much more present in the looney2ns footage for the most part. BUT if you look at the start of the nayr footage you wil notice that he also appears semi-transparent as he walks into the frame.
Seeing all this I started thinking that perhaps H.264/H.265 are perhaps not such a good choice for recording security footage in low-contrast environments. I'm pretty certain that security footage was not the main concern in developing these codecs, they are intended for encoding movies and television events where lighting is probably at least adequate. The whole idea of this sort of sort of lossy encoding is to use bits where there is the most contrast etc. so that as a whole our
perception of the scene is satisfying. In most scenarios the low-contrast areas and scenes are not the ones people will be looking at (ie. expecting a lot of detail) and thus relatively few bits are used to encode those and instead use them when, for instance, there is a big explosion after a darker scene.
Another issue might be the limited CPU power available in the cameras, encoding into these formats is not just one single deal. You can make all kinds of decisions when implementing and fine-tuning encoders. As long as the result data stream can be
decoded by a standard H.264/H.265 decoder it's valid data.
I'm wondering what the
actual bit rate is of these recordings. It's quite possible that, despite setting it to 8192 or something (which is typically the
maximum you want to allow), the resulting bitstream has a much lower bit rate simply because the algorithm thinks there's no content that warrants spending those bits on.
I'm also wondering if these were recorded with CBR or VBR. If it's VBR, perhaps CBR will give better results.
I'd also be interested in seeing footage encoded with MJPEG if the cameras support that. Perhaps having that re-encoded by Blue-Iris into H.26x with settings optimized for low-light/contrast scenes will provide better quality.
Of course YouTube may also be contributing to this by re-encoding the footage, although I think the problem lies with the cameras and not YouTube.
I'm wondering Loony2nd, would you be willing and able to dive into this a bit more and see if there are other settings (CBR, MJPEG) that will make a difference? Also, would it be possible to upload the original video footage to some file sharing service such as WeTransfer so we can rule out YouTube being a factor?
Before finishing this I though I'd do a very quick Google to see if anyone shares my guess about H.26x perhaps not being a good choice for low-light/contrast recordings and I did find this:
Using H.264 video compression in IP video surveillance
Some quotes from that page:
