Review-OEM 4mp AI Cam IPC-T5442TM-AS Starlight+

Dseg42

Getting the hang of it
Joined
Apr 17, 2016
Messages
169
Reaction score
14
Location
Palm City, FL
The 5231 has a 1/2.8" sensor while the 5442 has 1/1.8"

No one really commented on the increase in clarity going from 1080p to 1520p on the 4MP or whatever. Definitely noticeable.
 
Last edited:

cb8

Getting comfortable
Joined
Jan 16, 2017
Messages
111
Reaction score
64
I do notice with the 2.8mm lens you can see more than the 5231 zoomed out.
Edit: I think I just found out that more MPs does not get a wider viewing angle, correct?
Wondering why I can see more with my 5442 than my 5231 side by side.
My 5442 is 2.8mm fixed with 5231 being motorized lens, zoomed out should be 2.7mm
It's because of the difference in sensor size. The 5231 would have to have a 2.0mm lens to have the same field of view as the 5442 with a 2.8mm. On the same note, a 5231 with a 4mm lens has about the same field of view as a 5442 with a 6mm lens with the 5442 having a slightly more narrow field of view. A great tool for better comparing the field of view and depth of field between cameras with different sensor sizes is dofsimulator.net
 
Last edited:

SecuritySeeker

Pulling my weight
Joined
Oct 5, 2018
Messages
266
Reaction score
156
Location
Netherlands
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:

Christopher Berry says:
15 April 2009 at 2:47 pm
Hi,

Nice article, however, you miss a couple of vital points.

H264's deblocking filter kills fine grained detail in an image with a great depth of view. Try doing the same tests with a camera installed in shopping mall or street scene and you will see what I mean. Whilst the foreground image is fine, the detail in the background objects is destroyed. Especially when the object approaches or breaches the sharp edge of a slightly moving foreground object.
H264 is also very poor at handling low light scenes. It's breakdown is almost 50% worse than MJPEG.

We recently tested the new 6 channel AXIS H264/MJPEG encoder in a city centre scheme. Whilst its fine for viewing and manipulation of the camera we still required MJPEG images for recording.

I have a white paper that discusses the codecs on our website.
Greg Innes says:
16 April 2009 at 10:34 am
Thanks Christopher.

I agree. If image quality is paramount then you should always record using MJPEG. That's a given.
steven says:
2 December 2014 at 12:22 am
Thanks for the great article. I have to agree with both comments from Chris and Greg. We jumped into H.264 about 8 years ago but found it has some niceties but it's not without it's own peculiar issues.

To be honest, we found H.264 only compares with M-JPEG for quality where there is controlled lighting, but we won't never use H.264 for recording in day/night or in crappy lighting. M-JPEG rules in low light.
 

handinpalm

Getting comfortable
Joined
Sep 21, 2016
Messages
679
Reaction score
1,432
Location
Tampa Bay FL
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:
Good synopsis @SecuritySeeker. I guess using h26x encoding in low light, the algorithm has to make a determination if the pixel changed between frames. This "threshold" of change between frames evidently is hard to discern in the algorithm. That is a good explanation on why the algorithm does not see a change and leaves the pixel the same a preceding frame, giving the moving object the semi-transparent look. This may be due to some hysteresis around the threshold they need in the algorithm, so the video does not produce noisy/grainy video. Thanks for pointing this out. Nothing is ever free, there are always some sacrifices on one method to another. I agree, it would be good for anyone to make a comparison between h26x encoding and MPEG, but MPEG would win for quality, with a large sacrifice.
 
Last edited:

reeves1985

Pulling my weight
Joined
Sep 13, 2015
Messages
776
Reaction score
241
Good synopsis @SecuritySeeker. I guess using h26x encoding in low light, the algorithm has to make a determination if the pixel changed between frames. This "threshold" of change between frames evidently is hard to discern in the algorithm. That is a good explanation on why the algorithm does not see a change and leaves the pixel the same a preceding frame, giving the moving object the transparent look. Thanks for pointing this out. I agree, it would be good for anyone to make a comparison between h26x encoding and MPEG.
I think the only encoding available within the camera is h264 and h265
I don't believe mpeg is an option
 

reeves1985

Pulling my weight
Joined
Sep 13, 2015
Messages
776
Reaction score
241
Just had a quick look and the only options to encode are

H264 h264H and h265 Screenshot_20190608-131257_Chrome.jpg
 

civic17

Getting the hang of it
Joined
Dec 7, 2018
Messages
175
Reaction score
60
Location
Canada
That's very interesting that it doesn't offer smart IR ,

You'd think that would be a standard issue on these next gen cameras.

As you mention that's a firmware related fix.

Will you try running the cam in h264 if you have time as that might be playing a part with the ghosting if it's a poorly implemented algorithm
I logged into my IPC-HDW5442TM-AS and IPC-HDW2231R-ZS to see what the menu for IR shows. The 2231 has manual, smartIR, and off. The 5442 has manual, auto, and off. On Dahua website the specs show the 5442 has Smart IR Support. Would smart IR be a hardware feature or firmware like you guys mention?
2231-IR.JPG 5442-IR-mode.JPG
IPC-HDW5442TM-AS
 

Dseg42

Getting the hang of it
Joined
Apr 17, 2016
Messages
169
Reaction score
14
Location
Palm City, FL
I logged into my IPC-HDW5442TM-AS and IPC-HDW2231R-ZS to see what the menu for IR shows. The 2231 has manual, smartIR, and off. The 5442 has manual, auto, and off. On Dahua website the specs show the 5442 has Smart IR Support. Would smart IR be a hardware feature or firmware like you guys mention?
View attachment 43330 View attachment 43331
IPC-HDW5442TM-AS
My 5442 is the same as yours, no SmartIR. My 5231 has the SmartIR though.
 

reeves1985

Pulling my weight
Joined
Sep 13, 2015
Messages
776
Reaction score
241
My 5442 is the same as yours, no SmartIR. My 5231 has the SmartIR though.
I think reading between the lines here eith these newer 4mp starlight+ models is it may take a firmware upgrade or 2 to get them in the sweet zone.
 

civic17

Getting the hang of it
Joined
Dec 7, 2018
Messages
175
Reaction score
60
Location
Canada
Tested the 5442 last night by walking back and forth like this guy in video. The camera in auto mode is either not smart ir or it doesn't work properly by lowering the intensity of the ir.
 

ThomasPI

Pulling my weight
Joined
May 9, 2017
Messages
305
Reaction score
212
Tested the 5442 last night by walking back and forth like this guy in video. The camera in auto mode is either not smart ir or it doesn't work properly by lowering the intensity of the ir.
The AUTO mode does NOT equate to SMART IR per @looney2ns previous comments. As Andy said, these need work and until these camera have the same features available as the 2MP Starlights, such as Smart IR and the availability of VF lenses in the turret models, my money is still on the 2MP versions. As @nayr and @looney2ns have stated time and time again along with others, don't chase megapixels and don't forget to take into account your PC running BI,the new cameras are going to tax older systems and you're likely going to need to update hardware. Within the next few months I"m going to buy 12 cameras give or take and as of today, my money is on the 2 MP cameras based on what I've seen. YMMV.
 

Dseg42

Getting the hang of it
Joined
Apr 17, 2016
Messages
169
Reaction score
14
Location
Palm City, FL
The AUTO mode does NOT equate to SMART IR per @looney2ns previous comments. As Andy said, these need work and until these camera have the same features available as the 2MP Starlights, such as Smart IR and the availability of VF lenses in the turret models, my money is still on the 2MP versions. As @nayr and @looney2ns have stated time and time again along with others, don't chase megapixels and don't forget to take into account your PC running BI,the new cameras are going to tax older systems and you're likely going to need to update hardware. Within the next few months I"m going to buy 12 cameras give or take and as of today, my money is on the 2 MP cameras based on what I've seen. YMMV.
I was worried about my system too but after experimenting with two of the new cameras, the impact was minor to unnoticeable.
Also do not need VP lenses if you know what lens you need, cheaper too.
 

reeves1985

Pulling my weight
Joined
Sep 13, 2015
Messages
776
Reaction score
241
The point is though at the moment these are not working great.

I think the ideal here is to have at least equal or better night time quality and obviously higher daylight quality.

The fixed or V/F at the minute is a none issue
 

Dseg42

Getting the hang of it
Joined
Apr 17, 2016
Messages
169
Reaction score
14
Location
Palm City, FL
I wouldn't say "not working great." I have mostly 5231s and the 5442 are equal, if not better, compared to the the 5231s.
 

reeves1985

Pulling my weight
Joined
Sep 13, 2015
Messages
776
Reaction score
241
I wouldn't say "not working great." I have mostly 5231s and the 5442 are equal, if not better, compared to the the 5231s.
I'd disagree at the moment.

The lack of smart IR for a start makes it an inferior product.

There seems to be issues with too much ghosting.

I've no doubt after a couple of firmware upgrades it will be on par if not better, but until then I'll stick to my 5231 cams purely because with now smart IR I personally think they become useless at night
 

MakeItRain

Pulling my weight
Joined
Aug 7, 2017
Messages
401
Reaction score
218
looney2ns - good example with the DMV eye test!

The 4MP is clearly better since you can make out lines 8 and 9 better than you can the 2MP.

I used to have a 3MP Amcrest cam and switched to the 4MP Amcrest cam. It is mounted near my garage. The reason being was that the 3MP was struggling to read license plates and wife and I was not happy that we couldn't ID the cars coming into the "shared" driveway. The 4MP was much better in its ability to discern the plates.

Pixels still matter with lots of lighting imho.

I noticed that the 5231R produces more of a blurrier, fuzzy image than the 5442 in your example. May or may not have something to do with the aperture or focus.
 

Mike A.

Known around here
Joined
May 6, 2017
Messages
3,825
Reaction score
6,377
Tested the 5442 last night by walking back and forth like this guy in video...
To be fair, the SmartIR isn't always all that smart either. My Dahua cams with it still will blow out faces depending on settings/scene/circumstances. I don't have them set up in a way to repeat that test exactly but I've seen many examples while setting up, testing, and using them over time with SmartIR on.
 
Last edited:
Top