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

[Filippov Alexey <[e-mail]>]

>> The borderline is the necessity of feedback. For example, in the case of
>> video conferencing, replies are needed. In the case of IPTV
>> broadcasting, user is switching between channels and doesn't want to
>> wait long enough (more, than 1 sec). If a person selected a movie and
>> wants to watch it, there is no reasons for any feedback.

>The feature you are looking for is seekability, aka frequent I-frames,
>*not* low latency. The "high latency" configuration I specified would be
>fine for this use case.

No, a better word is interaction. I guess http://www.cast-inc.com/blog/white-paper-understanding-and-reducing-latency-in-video-compression-systems provides a comprehensive explanation what we are discussing. "Low latency is a design goal for any system where there is real-time interaction with the video content, such as video conferencing... When humans interact with video in a live video conference or when playing a game, latency lower than 100ms is considered to be low, because most humans don't perceive a delay that small." You are absolutely right that frequent intra-frames are needed for minimizing the delay while switching between channels but GOP structure, de-jitter buffer size, etc. significantly impact the latency as well. When I wrote about feedback, I meant that low latency is required in such applications where immediate reaction of a user can be needed. So, video-on-demand is a high-latency application (e.g., a movie has been already selected and a user can wait 1,2, 5 or even 10 sec for the moment when the movie starts playing) but video conferencing obviously requires a low latency.



>> IPTV is a very popular use case for Internet users. If it will be
>> removed, it is reasonable to discuss not an Internet video codec but a
>> codec for interactive video. I agree that use case definition should be
>> described more clearly but I disagree that this application should be
>> removed.

>You still need to specify exactly what IPTV is, and most importantly,
>what sort of transport it is expected be delivered over. I assumed DASH,
>but you mentioned error resilience which is not required for DASH. If
>you intended some other transport, it should be made clear.

I think http://iptvpavilion.com/features/iptv-unicast-multicast-0319/ is a good description of 2 IPTV use cases. Thus, I propose the following definition of IPTV: "IPTV is a service for delivering television content over IP-based networks. IPTV services may be classified into two main groups based on
o             unicast (e.g., for video on demand),
o             multicast/broadcast (e.g., for transmitting news or other live programs)."
Error resilience is required as "the delivery of high-quality multimedia through a reliable network is core to IPTV". But not all IP-based networks are reliable. In the case of video on demand, it is enough to increase buffer size to improve the situation with network reliability. However, error resilience is required to provide low latency (more details can be found in my previous comment).

Alexey