Could it be hardware issue, if H264+ is hardware decoded?
Yeah, it could be. Some software decoders I tried could mostly manage the h264+ stream, so it does not deviate too far from the standard h264 spec. The reality is if they ever plan on using hardware decoders it *must* be compliant with standard h264 in the bits that matter to the decoder, and that's quite a bit these days.
It'd be interesting to do some real side by side tests to compare things like minor scene changes, motion compensation and response to gross scene changes.
Unfortunately I just tested on a 2CD6026FHWD and remembered that enabling h264+ knocks out the remainder of the h264 encoder, so I can't compare it with the third stream and it limits the second stream to 704x576, so it's not a fair fight. Last time I looked at it I used a couple of 2CD4526FWD domes next to each other with one on standard and the other on h264+, but that was last year and it's all a bit hazy.
I just plugged it into a Geutebruck VMS and that had no trouble decoding the h264+ stream, but the camera switching time took lots of seconds while it waited for an I frame.
It also played flawlessly with vlc or mplayer whereas last time I tested I was getting blockies and jaggies tearing the stream intermittently.
Now having said that, this camera is on about 5 firmware revisions (and many months) later than when I originally tried this, but it suffers from the same issues in that waiting for an I frame is like waiting for a London bus. That makes rapid camera switching impossible and also means seeking in the stream is exceedingly difficult (for reverse playing for example).
I'll look at it a bit deeper in a week or two when I get some more time. Cursory investigation says encoding performance has improved over the last couple of firmware revisions, but you lose the third stream when you enable h264+ along with the other performance and reliability issues others have noticed. You are going to get that with a proprietary extension to a standard however.
