does "smart codec" work?

[scottlamb]

My Dahua Starlight camera has an option called "smart codec" which I haven't ever tried. I'm a little afraid it will enable B-frames (which Moonfire NVR currently doesn't support) or some such. I should try this to see if it actually works.

[scottlamb]

I've been trying it out, and it appears to work with the basic functionality (standard/unfragmented .mp4 files, including clipping recordings), fwiw, when viewed from Chrome desktop. Possibly the first frame or two are white when I load it? It's hard to tell if that's just because this camera's at a higher bitrate than the others or whatnot.

A Dahua wiki page says that it works by "taking reference frames and applying them to refreshed frames". Currently, the TrackRunBoxes (aka trun) that Moonfire NVR generates assumes that there are just I-frames and P-frames which refer only to the previous I-frame. It's possible they mean that a P-frame refers to more than one I-frame or also to a previous P-frame. This would be significant extra work to make correct TrackRunBoxes if so. It'd mean extending the H.264 parsing to read the references, reworking the video index format to describe it correctly, and extending the TrackRunBox generation to make use of that. It's not a real problem now because the current UI doesn't actually make use of the fragmented .mp4 files, but they'll be needed for a scrub bar UI (#32) and web live streaming (#59).

I think the next step is to inspect the H.264 output more closely to see what it's actually doing. I've previously peeked at them with aizvorski/h264bitstream for another issue (#43). That's probably the easiest way.

I also wonder how much the TrackRunBox contents really matter. Do the major browsers (desktop+mobile variants of Chrome/Chromium, Safari, and Firefox) actually use them? Chromium and Firefox at least are open source, so code inspection is one way to check.

Another way is to try it and see of course.

[scottlamb]

In short, yes. Smart Codec works fine with Moonfire NVR.