So I have some more information on the issue that we are seeing at a customer. What they are trying to do is reuse their IP camera hardware if they can as a decode unit in another part of the store; specifically at a security guards desk. So ideally they’d like a DM6446 footprint-compatible solution; and in truth; this may come down to SW anyhow. What they are doing is trying to decode a stream from the IP net cam; they have DMVA2 and a DM6446 version; both have the same issue.
The h.264 decoder they use is whatever it is we ship with our DVSDK v1.20 for the DM6446. Now, the issue is; when they decode the stream, and blow it up to a 42” monitor; it looks pretty bad; like the photo shown below.
Now we are not 100% sure why it looks so bad; but the jagged edges on the diagonal lines suggest one of two things to me- either there is an outright incompatibility in the net cam output and the DM6446’s ability to decode it; or there is an artifact being introduced at the DM6446 decoder end. Normally I would have described this as an interlacing artifact, but if you look close at it it almost looks like the diagonals got the wrong way within the artifact range, suggesting to me something more sinister like an endian error in the 4:2:0 to 4:2:2 conversion process on the backend. Here’s why I get to that conclusion. In the course of debugging this; we have found that:
The imager itself outputs 4:2:2 video; and if we connect that direct to the TV it looks great (no encoding, no decoding). Now we know that the DM6446 ENCODER software (the camera side here) only supports 4:2:0 input, so we use the resizer to convert the 4:2:2 to 4:2:0 before the RTSP stream is created. Now of course this was suspect; but, if we ‘tune’ the that stream with a PC video decoder it still looks fine; and as such, we are pretty confident that the encoded 4:2:0 stream is good. The problem is, that we really need to get back to 4:2:2 to get to the TV; so , if we replace the PC-based decoder with another DM6446 and try to decode with that; and set up for a 4:2:2 output, we get this squirreled up result. What I don’t know about our SW decoder is if this 4:2:0 (which it would natively support) to 4:2:2 conversion is being done in SW or is also trying to use the resizer (I’ve always understood the resizer to be on the video input side, so I suspect this is more a brute force SW implementation on the decoder end); but in any case there are clearly artifacts that are not present when using a PC-based decoder.
Just a a sidebar; we have tested the MJPEG encoder and decoder because those DO support 4:2:2; and it looks great; but the problem is they need to use h.264, and hence our issue.
