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

Filippov Alexey <Alexey.Filippov@huawei.com> Wed, 22 July 2015 09:51 UTC

Return-Path: <Alexey.Filippov@huawei.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33DD1A89FF for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 02:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Twj349dGyLtz for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 02:51:12 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862D21A87A7 for <video-codec@ietf.org>; Wed, 22 Jul 2015 02:51:08 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZA60985; Wed, 22 Jul 2015 09:51:06 +0000 (GMT)
Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jul 2015 10:51:05 +0100
Received: from SZXEMA508-MBS.china.huawei.com ([169.254.8.36]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 17:50:54 +0800
From: Filippov Alexey <Alexey.Filippov@huawei.com>
To: "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: Re: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AdDEY+SA0077AnUFRC2IsQvplos36g==
Date: Wed, 22 Jul 2015 09:50:53 +0000
Message-ID: <A95DB243D3936149BBFA3B43ED71074570525F45@szxema508-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.64.80]
Content-Type: multipart/alternative; boundary="_000_A95DB243D3936149BBFA3B43ED71074570525F45szxema508mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/ng49a7LRRjXeHR0QcBuBMHg9a74>
Cc: "tdaede at mozilla.com" <tdaede@mozilla.com>, "Ali C. Begen (abegen)" <abegen@cisco.com>, "mohammedsraad@raadtech.com" <mohammedsraad@raadtech.com>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Video codec BoF discussion list <video-codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/video-codec>, <mailto:video-codec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/video-codec/>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 09:51:15 -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.