SVC (Scalable Video Coding)?

[slamb]

Has anyone gotten the "SVC" option under Video/Audio to do anything? I believe this is supposed to be Scalable Video Coding (a single stream that can be downsampled in frame rate and/or quality) but it doesn't seem to work for me.

Context: I'm writing my own NVR software. I would dearly love to stream/store just the high-quality stream and be able to save CPU by decoding only part of it when doing on-NVR motion detection. Likewise I'd like to be able to save bandwidth when streaming to clients over poor connections and/or when streaming multiple cameras at once.

I have DS-2CD2032-I cameras:

• when running the "V4.0.9 130306" firmware, there's no SVC option.
• when running the "V5.1.6 build 140612" firmware, SVC switches between OFF and ON. I see no effect.
• when running the "V5.3.0 build 150513" firmware, SVC switches between OFF, AUTO, and ON. I see no effect.

I've tried rebooting after applying the setting. No difference. I'm wondering if the firmware option is meant for some fancier camera and they just mistakenly left it visible but ineffective. I don't see any cameras that specifically mention SVC

Here's what I believe this should do:

When responding to an RTSP DESCRIBE command, it should offer H264-SVC as described in RFC 6190 section 7.3.1:

m=video 20000 RTP/AVP 97 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4de00a; packetization-mode=0; sprop-parameter-sets={sps0},{pps0};
a=rtpmap:97 H264-SVC/90000
a=fmtp:97 profile-level-id=53000c; packetization-mode=1; sprop-parameter-sets={sps0},{pps0},{sps1},{pps1};[/CODE]
​

what I actually see is this:

v=0
o=- 1462266397175965 1462266397175965 IN IP4 192.168.5.106
s=Media Presentation
e=NONE
b=AS:5050
t=0 0
a=control:rtsp://192.168.5.106:554/
m=video 0 RTP/AVP 96
c=IN IP4 192.168.5.106
b=AS:5000
a=recvonly
a=control:rtsp://192.168.5.106:554/trackID=1
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=420029; packetization-mode=1; sprop-parameter-sets=Z00AKZpmA8ARPyzUBAQFAAADA+gAAOpgBA==,aO48gA==
a=Media_header:MEDIAINFO=494D4B48010100000400010000000000000000000000000000000000000000000000000000000000;
a=appversion:1.0
​

I also checked in the actual H.264 stream for NAL unit types 14, 15, and/or 20, as mentioned in H.264 Annex G. No luck there either.

 

[pghcamman]

maybe I'm misunderstanding but Instead of reinventing the wheel cant you accomplish this by keeping the mainstream(recording quality)settings like quality, fps, and bitrate high; then lower all these settings for the substream settings(remote steaming to client)? or what about enabling channel zero encoding for clients?

 

[slamb]

Yeah, I'll probably end up using both the main and sub streams, but this isn't as good in a few ways:

• To support adaptive bitrate streaming, I'd want the streams' timestamps to match up exactly into a single ordering of all frames across both streams. I don't think that's possible with main vs sub. The RTP streams' timestamps are relative to a random offset (see RFC 3550 section 5.1), so I can't directly compare them between streams. The version 5.1.6 firmware sends a RTCP Sender Report matching up the stream's RTP timestamp with an absolute reference (NTP timestamp). But it only sends it every 10 seconds or so (and not as soon as the stream starts), and the other firmware versions I've tried don't even send this packet (though they're supposed to according to ONVIF Profile G). (Apparently I'm not the only one to have been frustrated by this.) For both reasons, I may not have one to work with at all for a given stream. So basically I don't think adaptive bitrate streaming is possible without seeing the stream jump forward and back in time when the bitrate changes, which seems like a pretty horrible user experience.
• main+sub gives only two levels of quality, where SVC potentially provides several. The sub vs the main can be a pretty dramatic jump, especially if I have to keep the sub quality down enough that low-powered NVR hardware can decode the H.264 and do salient motion detection on all streams continuously. It'd be better to have more levels of quality between.
• Storing main+sub requires more disk on the NVR, or equivalently, decreases the duration of video I can keep. With SVC, the high-quality data refines the low-quality data in an efficient way. With main vs sub, the main stream starts from scratch.

What's channel zero? I'm not familiar with the term. From this manual fragment, it sounds like it's the NVR hardware decoding the main stream, downsampling/dropping frames, and re-encoding. If so, I can't do that. In particular, when running on cheap hardware (think Raspberry Pi 3 to ODROID-XU4), there's no way I have the CPU budget to do that for multiple streams at once (which I'd have to do to make it useful for simultaneous viewing, whether I do it ahead of time or on-demand).