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

["Ali C. Begen (abegen)" <[e-mail]>]

-----Original Message-----
From: video-codec on behalf of Thomas Daede
Date: Wednesday, July 22, 2015 at 12:21 AM
To: "[e-mail]"
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01

>On 07/21/2015 07:19 PM, Filippov Alexey wrote:
>
>> 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.

If you implement RFC 6285, you dont need frequent I-frames, either. This is something implemented in most IPTV deployments.

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

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

If you wanna mean streaming services, just say streaming. No need to confuse people with other terms. 

>
>Thomas
>
>_______________________________________________
>video-codec mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/video-codec