Re: [video-codec] draft-filippov-netvc-requirements-01

[Filippov Alexey <[e-mail]>]

>There is a *huge* difference for a casual user’s forgiveness between when he does a channel change time vs. he uses skype, webex or another conversational application.

>Most people do not notice anything if the channel change time is 100 ms vs 900 ms (anything less than a second is more than acceptable to users). Whereas 100ms vs even 300 ms would make a big difference in how much you will enjoy your skype talk.

I agree that the tolerance for delay is more in the case of channel change but it does not mean that any delay is acceptable. Yes, the appropriate channel change time is less than 1 sec but for video on demand, 5, 15 sec or more are OK. Some people are ready to wait 30 min while downloading a movie because no real-time interaction with the video content is required. Another use-case without interaction is uploading video to a video hosting server. It can take, for example, 5 min and this time acceptable because any real-time interaction is not needed. You mentioned that 100ms vs even 300 ms make a big difference for conversational applications but for game streaming, this latency can be even more crucial (BTW, what is more interactive than games over the Internet? But you propose to remove this use case). Of course, a concrete value depends on the type of interaction. However, the borderline between low-latency and high-latency applications is in the necessity of interaction with the video content (it’s not just my opinion:  http://www.cast-inc.com/blog/white-paper-understanding-and-reducing-latency-in-video-compression-systems).

>The “interactive” applications on your settop or connected TV do not demand a low latency as much as skype-like apps do. More than often, the lag on TVs, settops are due to the hardware or the software, not video encoding/decoding related delay. So even if you have the best codec, it won’t make a big difference
If guess if you have the best codec but the de-jitter buffer size is big or HW/SW doesn’t work well, it won’t make a big difference as well. Obviously, low-delay codec does not guarantee low-delay solution. What we could (and probably should) do is to specify values of delay that could be introduced by a codec.

>True. That is what IPTV means. The term you are looking for networks without SP QoS is “IP (or internet) video” not IPTV.
From the codec point of view the only difference between “IPTV” and “IP video”(OTT, OpenIPTV, etc.)  is managed or unmanaged network (i.e. error robustness). Correct? If so, we can consider these two applications as a single use-case with a requirement for error resilience if the network is unmanaged.
In this case, my main question is whether you mind to consider OTT video as a use case for NETVC codec or not?