Subject: [AVT] Rapid synchronization / RTP Burst / RTCP burst

From: "Roni Even" <[email-masked]>
Date: Tue, 17 Feb 2009 08:25:05 +0200

Hi,

At the Minneapolis the summary was that the parties will try to progress the
work before SF meeting.

The only thing I saw on the AVT list is a new draft from Peilin, so now
there are three drafts.

Is there any other progress or are you all waiting for SF to discuss
progress.

The deadline for contributions is March 2nd for new drafts and March 9th for
the rest.

Regards

Roni Even

AVT co-chair

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Tue, 17 Feb 2009 09:53:46 +0100

Dear Roni,
 
we (that is the authors of the two drafts on "Rapid MC synchronisation")
are in the process of  delivering a new draft that combines some of the
elements in both existing drafts and takes into account the comments
from the ad-hoc meeting. Our ambition is indeed to submit this new draft
before the SF meeting deadline. We decided to go for a two-step
approach, where in the 1st step we sort out the differences among the
two drafts that have already been presented and discussed within the
IETF community, and in the second step (starting with the IETF SF
meeting) , we want to discuss with Peilin and all other interested
people on the new features proposed in his draft on this topic.
 
Kind Regards,
Tom

________________________________

From: Roni Even [mailto:[email-masked]] 
Sent: dinsdag 17 februari 2009 7:25
To: 'Ver Steeg, Bill'; 'Orit Levin'; VAN CAENEGEM Tom; [email-masked];
[email-masked]; 'Peilin YANG'
Cc: 'IETF AVT WG'
Subject: Rapid synchronization / RTP Burst / RTCP burst

Hi,

At the Minneapolis the summary was that the parties will try to progress
the work before SF meeting.

The deadline for contributions is March 2nd for new drafts and March 9th
for the rest.

Regards

Roni Even

AVT co-chair

---

From: Peilin YANG <[email-masked]>
Date: Tue, 17 Feb 2009 17:30:34 +0800

Dear Tom，

I am very glad to discuss with you and all other interested guys on this topic.

Best regards,

Peilin
******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

----- 原邮件 -----
发件人: VAN CAENEGEM Tom <[email-masked]>
日期: 星期二, 二月 17日, 2009 下午5:23
主题: RE: Rapid synchronization / RTP Burst / RTCP burst
收件人: Roni Even <[email-masked]>, "Ver Steeg, Bill" <[email-masked]>, Orit Levin <[email-masked]>, [email-masked], [email-masked], Peilin YANG <[email-masked]>
抄送: IETF AVT WG <[email-masked]>

> Dear Roni,
> 
> we (that is the authors of the two drafts on "Rapid MC 
> synchronisation")are in the process of  delivering a new draft 
> that combines some of the
> from the ad-hoc meeting. Our ambition is indeed to submit this new 
> draftbefore the SF meeting deadline. We decided to go for a two-step
> At the Minneapolis the summary was that the parties will try to 
> progressthe work before SF meeting.
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 17 Feb 2009 11:35:03 +0200

Hi,

These are good news, please try to include Peilin in your discussion,
hopefully we will manage to have an ad-hoc meeting in SF to get further
progress. 

I think it will be good to include the input from Peilin document as early
as possible in order to expedite the work. 

The summary of the ad-hoc meeting that was on the AVT list had a couple of
discussion points. Are there any resolution, my view is that if you post
this to the list early it will help with progressing the work.

About the first discussion point I had some other feedback suggesting that
RTCP may be used from retransmission server   to send information that was
previously in the RTP stream if there is no obvious way to fit it in the
retransmission stream.

Regards

Roni Even

From: VAN CAENEGEM Tom [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2009 10:54 AM
To: Roni Even; Ver Steeg, Bill; Orit Levin; [email-masked];
[email-masked]; Peilin YANG
Cc: IETF AVT WG
Subject: RE: Rapid synchronization / RTP Burst / RTCP burst

Dear Roni,

we (that is the authors of the two drafts on "Rapid MC synchronisation") are
in the process of  delivering a new draft that combines some of the elements
in both existing drafts and takes into account the comments from the ad-hoc
meeting. Our ambition is indeed to submit this new draft before the SF
meeting deadline. We decided to go for a two-step approach, where in the 1st
step we sort out the differences among the two drafts that have already been
presented and discussed within the IETF community, and in the second step
(starting with the IETF SF meeting) , we want to discuss with Peilin and all
other interested people on the new features proposed in his draft on this
topic.

Kind Regards,

Tom

  _____  

Hi,

Regards

Roni Even

AVT co-chair

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 26 Feb 2009 13:39:11 -0500

Folks,
 
Roughly, how much delay can be saved in average by using the basic mechanism
that is common for all the drafts (i.e. using an additioal unicast burst for
the Key Information)? Does anyone have a figure?
 
When trying to make an estimation, I tried to figure out how exactly the
system works, but it turned out that that is still unclear after reading all
the drafts. Can anyone help answer a couple of clarification questions
below?
 
Let's use an example with an H.264/AVC stream. Assume that the network works
perfectly - no packet loss. The video stream structure is as follows. 
 
 ParameterSets IDR0 B1 B2 P3 B4 B5 P6 B7 B8 P9 B10 B11 P12 B13 B14
ParameterSets IDR15 P16 B17 B16 P19 B20 B21 ...
 
>From left to right is the presentation order. IDR0 and IDR15 are random
access points, and the presentation time difference between them is 1
second. In other words, if the presenation time of IDR0 is 0, then the
presentation time of P3 is 0.2s. Assume that a user starts the process of
switching to the channel when other users are displaying the picture P3 (for
simplicity in description, assume that all the users are synchronized in
playback).
 
Questions: 
- What does the Key Information contain, i.e. what information will be sent
to the user via the unicast session? 
- Starting from which picture the playback will be started by the user
equipment?
 
Please feel free to make any other assumptions, e.g. the value of the
unicast session bandwidth, whenever needed. 
 
BR, YK

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: Tuesday, February 17, 2009 4:35 AM
To: 'VAN CAENEGEM Tom'; 'Ver Steeg, Bill'; 'Orit Levin'; [email-masked];
[email-masked]; 'Peilin YANG'
Cc: 'IETF AVT WG'
Subject: Re: [AVT] Rapid synchronization / RTP Burst / RTCP burst

Hi,

Regards

Roni Even

Dear Roni,

Kind Regards,

Tom

  _____  

Hi,

Regards

Roni Even

AVT co-chair

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 26 Feb 2009 11:01:43 -0800

YK,
 
There are a couple of IEEE papers that explain this scheme in simple
words. They should help with all of your questions. They have results,
too.
 
I don't want to spam everyone with the pdfs, but here is the citation
info:
 
Ali C. Begen, Neil Glazebrook and William Ver Steeg, "Reducing channel
change times in IPTV with real-time transport protocol," to appear in
IEEE Internet Comput., Special Issue on IPTV, May/June 2009
 
Ali C. Begen, Neil Glazebrook and William Ver Steeg, "A unified approach
for repairing packet loss and accelerating channel changes in multicast
IPTV," in Proc. IEEE Consumer Communications and Networking Conf.
(CCNC), Special Session on IPTV Towards Seamless Infotainment, Las
Vegas, NV, Jan. 2009
 
If you have access to IEEExplore, you can get the 2nd paper. The first
one is inprint. If anybody is interested, pls send me a private message
and I will forward the pdf.
 
BR,
-acbegen

	From: Ye-Kui Wang [mailto:[email-masked]] 
	Sent: Thursday, February 26, 2009 10:39 AM
	To: 'Roni Even'; 'VAN CAENEGEM Tom'; Bill Ver Steeg (versteb);
'Orit Levin'; Dave Oran (oran); Ali C. Begen (abegen); 'Peilin YANG'
	Cc: 'IETF AVT WG'
	Subject: RE: [AVT] Rapid synchronization / RTP Burst / RTCP
burst

	Folks,
	 
	Roughly, how much delay can be saved in average by using the
basic mechanism that is common for all the drafts (i.e. using an
additioal unicast burst for the Key Information)? Does anyone have a
figure?
	 
	When trying to make an estimation, I tried to figure out how
exactly the system works, but it turned out that that is still unclear
after reading all the drafts. Can anyone help answer a couple of
clarification questions below?
	 
	Let's use an example with an H.264/AVC stream. Assume that the
network works perfectly - no packet loss. The video stream structure is
as follows. 
	 
	 ParameterSets IDR0 B1 B2 P3 B4 B5 P6 B7 B8 P9 B10 B11 P12 B13
B14    ParameterSets IDR15 P16 B17 B16 P19 B20 B21 ...
	 
	From left to right is the presentation order. IDR0 and IDR15 are
random access points, and the presentation time difference between them
is 1 second. In other words, if the presenation time of IDR0 is 0, then
the presentation time of P3 is 0.2s. Assume that a user starts the
process of switching to the channel when other users are displaying the
picture P3 (for simplicity in description, assume that all the users are
synchronized in playback).
	 
	Questions: 
	- What does the Key Information contain, i.e. what information
will be sent to the user via the unicast session? 
	- Starting from which picture the playback will be started by
the user equipment?
	 
	Please feel free to make any other assumptions, e.g. the value
of the unicast session bandwidth, whenever needed. 
	 
	BR, YK

		From: [email-masked] [mailto:[email-masked]]
On Behalf Of Roni Even
		Sent: Tuesday, February 17, 2009 4:35 AM
		To: 'VAN CAENEGEM Tom'; 'Ver Steeg, Bill'; 'Orit Levin';
[email-masked]; [email-masked]; 'Peilin YANG'
		Cc: 'IETF AVT WG'
		Subject: Re: [AVT] Rapid synchronization / RTP Burst /
RTCP burst

		Hi,

		These are good news, please try to include Peilin in
your discussion, hopefully we will manage to have an ad-hoc meeting in
SF to get further progress. 

		I think it will be good to include the input from Peilin
document as early as possible in order to expedite the work. 

		The summary of the ad-hoc meeting that was on the AVT
list had a couple of discussion points. Are there any resolution, my
view is that if you post this to the list early it will help with
progressing the work.

		About the first discussion point I had some other
feedback suggesting that RTCP may be used from retransmission server
to send information that was previously in the RTP stream if there is no
obvious way to fit it in the retransmission stream.

		Regards

		Roni Even

		From: VAN CAENEGEM Tom
[mailto:[email-masked]] 
		Sent: Tuesday, February 17, 2009 10:54 AM
		To: Roni Even; Ver Steeg, Bill; Orit Levin;
[email-masked]; [email-masked]; Peilin YANG
		Cc: IETF AVT WG
		Subject: RE: Rapid synchronization / RTP Burst / RTCP
burst

		Dear Roni,

		we (that is the authors of the two drafts on "Rapid MC
synchronisation") are in the process of  delivering a new draft that
combines some of the elements in both existing drafts and takes into
account the comments from the ad-hoc meeting. Our ambition is indeed to
submit this new draft before the SF meeting deadline. We decided to go
for a two-step approach, where in the 1st step we sort out the
differences among the two drafts that have already been presented and
discussed within the IETF community, and in the second step (starting
with the IETF SF meeting) , we want to discuss with Peilin and all other
interested people on the new features proposed in his draft on this
topic.

		Kind Regards,

		Tom

		From: Roni Even [mailto:[email-masked]] 
		Sent: dinsdag 17 februari 2009 7:25
		To: 'Ver Steeg, Bill'; 'Orit Levin'; VAN CAENEGEM Tom;
[email-masked]; [email-masked]; 'Peilin YANG'
		Cc: 'IETF AVT WG'
		Subject: Rapid synchronization / RTP Burst / RTCP burst

		Hi,

		At the Minneapolis the summary was that the parties will
try to progress the work before SF meeting.

		The only thing I saw on the AVT list is a new draft from
Peilin, so now there are three drafts.

		Is there any other progress or are you all waiting for
SF to discuss progress.

		The deadline for contributions is March 2nd for new
drafts and March 9th for the rest.

		Regards

		Roni Even

		AVT co-chair

---

From: <[email-masked]>
Date: Fri, 27 Feb 2009 15:47:19 +0100

10th IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks
15-19 June 2009, Kos, Greece

Call For Papers -- Industrial Track

http://www.ics.forth.gr/wowmom09/callforindustrialpapers.html

Important dates:

* Paper submission deadline: 15 March 2009 (HARD DEADLINE)

* Acceptance notification: 29 March 2009

* Camera-ready copy deadline: 11 April 2009

IEEE WoWMoM 2009 http://www.ics.forth.gr/wowmom09/index.html is soliciting original and previously unpublished research papers from industry researchers and professionals for a one-day Industry Session. Specific topics of interest include, but are not limited to:

* Conversational Mobile Multimedia

* (Personal) Mobile Broadcast Delivery and Applications

* Mobile broadcast implementation issues (including, but not limited to, DVB-H, MBMS, DMB, ATSC-M/H, MediaFLO, etc.)

* Mobile P2P distribution of real-time Multimedia

* Scalable Media architectures for mobile networks

* Social Multimedia and co-creation

* 3D Video modeling and applications

* Context-based real-time media

* Semantic description and scene context extraction of real-time media

* Multimodal sensing and context.

The Industry Session track is intended to specially highlight system experiences and proofs-of-concept in the areas above. Like regular papers, the Industry Session papers will undergo a review process by an International TPC and will appear in the conference proceedings.

However, the selection criteria for Industry Session papers are slightly different. In particular, papers should describe applications, prototypes or experiences of clear industry relevance. Papers with narrow algorithmic focus or only high-level design details are discouraged. A key goal of this session is to present systems-oriented research that exposes the academic and research communities to real-life issues and problems being faced in industry. Accordingly, papers will be evaluated, less on the novelty of specific algorithmic content, but by the originality and general applicability of insights that can be inferred from the authors' implementation experience.

Papers must be formatted according to the guidelines given in http://www.ics.forth.gr/wowmom09/papersubmission.html and submitted by the authors to BOTH the Industry Chairs by midnight US Pacific Time of 15 March 2009.

Industry Chairs:

Igor D.D. Curcio (Nokia Research Center), E-mail: igor.curcio AT nokia.com

Kumar Ramaswamy (Thomson), E-mail: kumar.ramaswamy AT thomson.net