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

[Filippov Alexey <[e-mail]>]

>Nope. In IPTV, the bandwidth is provisioned so you know your packets will not really face a loss or large delay unless something really bad happens. In IP video, there are no such guarantees, anything can happen to your packets. Thus, IP/OTT video uses mostly TCP (with HTTP). Such apps have entirely different set of goals to optimize (or trade off) compared to IPTV apps.
Could you please give several examples of how these differences could affect *codec* requirements? What specific requirements for codec should be stated for OTT video as compared to IPTV? I see just two differences: in rate control (however, different rate control mechanisms can be implemented for the same codec) and error resilience. IMHO, the differences between these apps are mainly in streaming but not in codec.


>In my view, neither IPTV nor IP/OTT video should be error resilient. They should be error free, that is it. But to me, skype, conferencing, rtcweb must be error resilient, especially when running over non-QoS networks.
So, the main difference is that packets don’t face a loss or large delay. Yes, mostly TCP is used for IP/OTT but resending undelivered packets is not always the best way of solving the problem of packet loss and, especially, of large delay. If low delay is needed, other mechanisms can work better. These alternative mechanisms can be implemented on transport level (e.g., FEC) or on codec level (e.g., redundant slices). So, I think error resilience tools implemented on codec level should be complementary to the error protection mechanisms implemented on transport level. Isn’t it?


>>In this case, my main question is whether you mind to consider OTT video as a use case for NETVC codec or not?
>As I said, it should not be the focus at the moment, later a different profile can be developed as needed.
Then, it would be hard to explain why Opus is used by YouTube, and NETVC codec is currently not even targeted at it.