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

From: Filippov Alexey <[email-masked]>
Date: Wed, 22 Jul 2015 09:50:53 +0000

>If you implement RFC 6285, you dont need frequent I-frames, either. This is something implemented in most IPTV deployments.
Yes, RFC 6285 provides a way of how to achieve low latency for a user. If we'll go back to your initial question ("And where is the borderline?"), the borderline is interaction. If an immediate reaction can be needed (video conferencing, switching between channels), latency should be kept low. Otherwise, it can be high enough.

>IPTV does not (and should not) mean DASH like streaming services or progressive download. IPTV means multicast for linear delivery and unicast for VoD delivery over a QoS enabled SP network (not even the open Internet).
Does it mean that if we do not have QoS enabled SP network, it is not IPTV anymore? I guess this definition is a bit restrictive. Many people watch movies and live programs using their SmartTV, laptops, tablets, and even smartphones connected to the open Internet, not to "a QoS enabled SP network". I don't think it's reasonable to ignore this use case for an Internet video codec (projects like Open IPTV or  Android TV )

>I gather that what is meant by "interactive" is real time communications. If you limit the netvc effort to only real time communications then you are ensuring that it will not have a chance to be dominant once it is complete because the argument for adoption will be weakened by the fact that another codec will be needed for the high quality material.
I entirely support this point of view.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 22 Jul 2015 10:02:41 +0000

From: Filippov Alexey
Date: Wednesday, July 22, 2015 at 11:50 AM
To: "[email-masked]<mailto:[email-masked]>"
Cc: "Ali C. Begen", Mohammed Raad, "tdaede at mozilla.com"
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01

>If you implement RFC 6285, you dont need frequent I-frames, either. This is something implemented in most IPTV deployments.
Yes, RFC 6285 provides a way of how to achieve low latency for a user. If we’ll go back to your initial question (“And where is the borderline?”), the borderline is interaction. If an immediate reaction can be needed (video conferencing, switching between channels), latency should be kept low. Otherwise, it can be high enough.

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.

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.

>IPTV does not (and should not) mean DASH like streaming services or progressive download. IPTV means multicast for linear delivery and unicast for VoD delivery over a QoS enabled SP network (not eve…
Does it mean that if we do not have QoS enabled SP network, it is not IPTV anymore?

True. That is what IPTV means. The term you are looking for networks without SP QoS is “IP (or internet) video” not IPTV.

I guess this definition is a bit restrictive. Many people watch movies and live programs using their SmartTV, laptops, tablets, and even smartphones connected to the open Internet, not to “a QoS enabled SP network”.

And that is IP video, and some of us call is “over the top” video. It is certainly not IPTV in strict sense.

I don’t think it’s reasonable to ignore this use case for an Internet video codec (projects like Open IPTV or  Android TV )

---

From: Filippov Alexey <[email-masked]>
Date: Wed, 22 Jul 2015 11:18:38 +0000

>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 differ…

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?

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 22 Jul 2015 11:34:56 +0000

From: Filippov Alexey
Date: Wednesday, July 22, 2015 at 1:18 PM
To: "Ali C. Begen", "[email-masked]<mailto:[email-masked]>"
Subject: RE: [video-codec] draft-filippov-netvc-requirements-01

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?

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.

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 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.

As I said, it should not be the focus at the moment, later a different profile can be developed as needed.

---

From: Filippov Alexey <[email-masked]>
Date: Wed, 22 Jul 2015 12:38:58 +0000

>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, anythi…
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 ov…
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?

>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.

---

From: Jack Moffitt <[email-masked]>
Date: Wed, 22 Jul 2015 06:44:39 -0600

> Then, it would be hard to explain why Opus is used by YouTube, and NETVC
> codec is currently not even targeted at it.

If you are basing this assessment on the requirements draft, then note
that the requirements draft is a work in progress and is not complete.
Streaming use cases should be added there, and I'm quite surprised I
managed to leave it out of the first draft.

jack.

---

From: Filippov Alexey <[email-masked]>
Date: Wed, 22 Jul 2015 13:01:32 +0000

>If you are basing this assessment on the requirements draft, then note that the requirements draft is a work in progress and is not complete.
>Streaming use cases should be added there, and I'm quite surprised I managed to leave it out of the first draft.
Agreed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jack Moffitt
Sent: Wednesday, July 22, 2015 3:45 PM
To: Filippov Alexey
Cc: Ali C. Begen (abegen); [email-masked]
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01

> Then, it would be hard to explain why Opus is used by YouTube, and 
> NETVC codec is currently not even targeted at it.

If you are basing this assessment on the requirements draft, then note that the requirements draft is a work in progress and is not complete.
Streaming use cases should be added there, and I'm quite surprised I managed to leave it out of the first draft.

jack.