It's been a long time but I finally figured out what the SVC option does on my old Hikvision DS-2CD2032-I and newer Dahua 5442 cameras. At first I thought it did nothing. But:
- With SVC off ("level 1" on the Dahuas), each H.264 P frame depends on the frame immediately before. If you have the IDR frame interval set to 30, to decode the final P frame in a GOP, you need to decode the GOP's IDR frame, the previous 28 P frames in order, then the P frame of interest.
- With SVC on (Hikvision) or level 2 (Dahua), only half of the P frames are "reference frames". You can skip the others and get a decodable stream with half the frame rate.
- With Dahua's level 3, the same is true, and there's additionally a more complex pattern. I'm not completely sure yet, but I think if you number the P frames so your stream is I123456789...I123456789..., not only can you discard all the odd numbers (as above), but frame 4 and 8 depend on frames I and 4, respectively. You can get a decodable stream with 1/4th the frame rate.
It's not written as SVC as defined in the H.264 and RTP H.264 payload specifications, and there's no apparent option to get the camera to skip the disposable frames in an RT(S)P stream, but an NVR or proxy could transform it into proper temporal SVC without using significant CPU power. (Only some careful remuxing, no expensive H.264 decoding and even more expensive re-encoding required.)
I don't have the exact numbers in front of me now, but I think this doesn't reduce bandwidth requirements that much: the IDR frames are most of the bytes anyway.
But: if you want to do analytics on only some of the frames, it will let you skip decoding many others. So maybe you want a 1080p stream at 15 fps for mobile streaming. You can do analytics on that same stream at 7.5 fps and not have to decode the other frames. (You could even decode just the I frames when there's no motion, then go back and look at every fourth when they look interesting, then every frame when there's rapid motion.) Cameras support two or three streams but aren't always configurable with exactly the options you want for each, and they don't give you the information to keep them perfectly in sync (particularly around clock changes or on cameras that don't send RTCP sender reports), so SVC might fill the gap.
So... kind of a niche thing but I might end up using it anyway.
