[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] Comments on draft-boyaci-avt-app-sharing-00

Hi Roni,

Thanks for your comments.
The semantics of RTCP PLI you define is not according to the PLI semantics, PLI is an indication from the receiver leaving the sender a free choice how to handle it. If you want a request you either use FIR from the CCM feedback 
RFC or define a different request.
Initially I was using FIR, but then thought that PLI is more generic. I will check the FIR, again. 
We also want to give a choice to the sender how to handle new-comers.
Transmitting the full screen state as soon as getting a PLI may not be feasible due to bandwidth considerations. 



As for the data, you suggest using ,multiple multicast for different
resolution, a better solution may be based on scalable video codec (SVC). One of the problems in the past for using video for screen data was the low resolution making the text unreadable, with SVC using HD resolution you can 
get high quality.


The system does not use video for screen data.
We suggest to use PNG for the screen data and we submit an ID for png- rtp http://tools.ietf.org/html/draft-boyaci-avt-png-00. 
The system uses a video codeFrom avt-bounces at ietf.org  Sun Nov 16 10:44:47 2008
Return-Path: <avt-bounces at ietf.org>
X-Original-To: avt-web-archive at optimus.ietf.org
Delivered-To: ietfarch-avt-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3417E3A69AB;
	Sun, 16 Nov 2008 10:44:47 -0800 (PST)
X-Original-To: avt at core3.amsl.com
Delivered-To: avt at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 378CA3A699F
	for <avt at core3.amsl.com>; Sun, 16 Nov 2008 10:44:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 
	tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001,
	RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 8jRfDVUG2x1a for <avt at core3.amsl.com>;
	Sun, 16 Nov 2008 10:44:45 -0800 (PST)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8])
	by core3.amsl.com (Postfix) with ESMTP id E7F6B3A6966
	for <avt at ietf.org>; Sun, 16 Nov 2008 10:44:44 -0800 (PST)
Received: from [10.71.0.145] (75-146-152-44-minnesota.hfc.comcastbusiness.net
	[75.146.152.44] (may be forged)) (user=ob2108 mech=PLAIN bits=0)
	by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id mAGIigYB022235
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for <avt at ietf.org>; Sun, 16 Nov 2008 13:44:43 -0500 (EST)
Message-Id: <52735723-E8CB-4602-987F-B6ACAAFA6895 at cs.columbia.edu>
From: Omer Boyaci <boyaci at cs.columbia.edu>
To: IETF AVT WG <avt at ietf.org>
In-Reply-To: <492061a4.16538c0a.2bb3.2ef5 at mx.google.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Sun, 16 Nov 2008 12:44:41 -0600
References: <83DD32C6-171F-4B46-9388-2EBF4840DAAD at cisco.com>
	<492061a4.16538c0a.2bb3.2ef5 at mx.google.com>
X-Mailer: Apple Mail (2.929.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8
Subject: Re: [AVT] Comments on draft-boyaci-avt-app-sharing-00
X-BeenThere: avt at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/avt>
List-Post: <mailto:avt at ietf.org>
List-Help: <mailto:avt-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>,
	<mailto:avt-request at ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0821215949=="
Sender: avt-bounces at ietf.org
Errors-To: avt-bounces at ietf.org
Hi Roni,

Thanks for your comments. 


The semantics of RTCP PLI you define is not according to the PLI semantics,
PLI is an indication from the receiver leaving the sender a free choice how
to handle it. If you want a request you either use FIR from the CCM feedback
RFC or define a different request.

Initially I was using FIR, but then thought that PLI is more generic. I will check the FIR, again.
We also want to give a choice to the sender how to handle new-comers. 
Transmitting the full screen state as soon as getting a PLI may not be feasible due to bandwidth considerations.


As for the data, you suggest using ,multiple multicast for different
resolution, a better solution may be based on scalable video codec (SVC).
One of the problems in the past for using video for screen data was the low
resolution making the text unreadable, with SVC using HD resolution you can
get high quality.
The system does not use video for screen data. 
We suggest to use PNG for the screen data and we submit an ID for png-rtp http://tools.ietf.org/html/draft-boyaci-avt-png-00.
The system uses a video codec only for the regions where a movie is playing.
For example, if the user is playing a movie in youtube, the system detects this and uses movie based encoding just for this region.
The rest of the screen will be transmitted via PNG. 

The system detects (via mirror driver) and transmits only the changed regions of the screen.

-Omer

On Nov 16, 2008, at 12:06 PM, Roni Even wrote:

Hi,
I also share Cullen concerns about why using RTP.
To me it looks like you are using RTP as a transport for a protocol. But
note that RTP over UDP or multicast is not reliable.
The semantics of RTCP PLI you define is not according to the PLI semantics,
PLI is an indication from the receiver leaving the sender a free choice how
to handle it. If you want a request you either use FIR from the CCM feedback
RFC or define a different request.

As for the data, you suggest using ,multiple multicast for different
resolution, a better solution may be based on scalable video codec (SVC).
One of the problems in the past for using video for screen data was the low
resolution making the text unreadable, with SVC using HD resolution you can
get high quality.

Roni Even

-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Cullen
Jennings
Sent: Saturday, November 15, 2008 3:52 AM
To: IETF AVT WG
Subject: [AVT] Comments on draft-boyaci-avt-app-sharing-00


I like the idea of an applications share protocol that can be set up  
over SIP and glad to see this submission.

Few comments

At a high level, why not just standardize something like VNC. It seems  
like this would be better than inventing something new.

I also wondered about why run it over RTP vs just be it's own  
protocol. It was not clear that RTP was a good match.

Some more small details ... you might want to look at how X deals with  
mouse and keyboard events - particularly compression of mouse motion.

Make sure that you have some way for the protocol to send a CTRL-ALT-
DEL to the far side without the user actually having to simultaneously  
press CTRL, ALT and DEL.

You probably want your PLI to be able to specify a partial rectangle  
to update.

Cullen in my individual contributor roll

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt