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

"Ali C. Begen (abegen)" <abegen@cisco.com> Wed, 22 July 2015 10:02 UTC

Return-Path: <abegen@cisco.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 031591ACE16 for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 03:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Wb2mFFZNnIds for <video-codec@ietfa.amsl.com>; Wed, 22 Jul 2015 03:02:43 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FAC91ACD3C for <video-codec@ietf.org>; Wed, 22 Jul 2015 03:02:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14542; q=dns/txt; s=iport; t=1437559363; x=1438768963; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D14G+QKslYT6k6pAZ/SoJlh0Da0qcZ6bRdlQeSeAZ9w=; b=doQGDZ6bqetKtt2NynS5qC1NXP6aRxqMk+/Wtb80yvnaPbakVKOhn4m+ ItohGBHFpPr7jk+wDD/NKrDDiAvllLixKpIoyRprsd4f7OLrewLz87u6n yBhoEAIG4K4T5p4Dhz6YY6roAiWW/FJPcJlJ1knGCL9z2HWVZYgt9vveh w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CSBQD3aK9V/5JdJa1bgkhNVGkGgx24Y4FtgkuDPgIcgSo5EwEBAQEBAQGBCoQjAQEBBCMKTBACAQgRAwECKAMCAgIwFAkIAQEEAQ0FH4gPtg+WNgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLTIQuRxEHCYJfL4EUBZRXAYR0hRSCKYFDFTGTJ4NhJoN8b4EFQoEEAQEB
X-IronPort-AV: E=Sophos;i="5.15,522,1432598400"; d="scan'208,217";a="171075032"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP; 22 Jul 2015 10:02:42 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6MA2gOp014076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 10:02:42 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.64]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 05:02:42 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Filippov Alexey <Alexey.Filippov@huawei.com>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: [video-codec] draft-filippov-netvc-requirements-01
Thread-Index: AdDEY+SAW0GCvpXJZECxIZTezzBngAAPFTeA
Date: Wed, 22 Jul 2015 10:02:41 +0000
Message-ID: <F9407E60-EA4F-4AA9-91A6-0303912D721B@cisco.com>
References: <A95DB243D3936149BBFA3B43ED71074570525F45@szxema508-mbs.china.huawei.com>
In-Reply-To: <A95DB243D3936149BBFA3B43ED71074570525F45@szxema508-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/0.0.0.150701
x-originating-ip: [10.61.214.86]
Content-Type: multipart/alternative; boundary="_000_F9407E60EA4F4AA991A60303912D721Bciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/yD31HoMWqSmsM91x7APOGbVG_r8>
Cc: "tdaede at mozilla.com" <tdaede@mozilla.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 10:02:46 -0000


From: Filippov Alexey
Date: Wednesday, July 22, 2015 at 11:50 AM
To: "video-codec@ietf.org<mailto:video-codec@ietf.org>"
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 even the open Internet).
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 )

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