Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-svc-03.txt

From: "BABONNEAU Gerard RD-MAPS-REN" <[email-masked]>
Date: Tue, 27 Nov 2007 17:53:36 +0100

Hi,

I am working on the transport of SVC streams in a french project (scalim@ges) with industrials partners.

I had a look mainly on sections 7, 8.1.1 and 9.
Good work, and I hope this will reach to a future standard including simple means to transport SVC contents in a few RTP sessions. My interest is mainly for non CL-DON mode, and I hope editors will reach a consensus to validate this mode.

1) about synchronisation points in chapter 8.1.1, the document looks to me very confuse: the re-ordering process is right, but I think it describes a particular mode of realization rather than is demonstrates the feasibility of re-ordering without the CL-DON. Other algorithms look feasible, especially to increase the robustness of SVC in case of selective losses.

2) In chapter 7, option I, point b. context ought to be enlarged: I can understand that an encoder has a B layer (for instance Q enhancement) that depend on A layer, and also a C layer (for instance D enhancement that depend on A layer), and optionally a D layer (for instance Q enhancement) that depend on C layer. However in this scheme, the receiver can use only a one-dimensional dependency structure, and the figure 2 in chapter 8.1.1 applies also whatever the dependency path the receiver chooses. Re-ordering always run even if layers A and B are in the same session and the same for C and D, by parsing NALU information in RTP payload headers. SDP as describe in section 9.3 give the receiver information to select the layers it re-orders and decodes, and drops the others.

I suggest to maintain section 8 and set it as non informative, but just to demonstrate the principles of re-ordiring in both cases, and may be to add annexes with examples of re-ordering algorithms? I guess also that some constraints, independant of svc payload, could lead to informational drafts or RFC.

May be I can propose a small contribution to non CL-DON mode?

Regards,

Gérard Babonneau
FT/RD/MAPS/DPC/APA
IG RD AV services and transport protocols
tél. (33)2 99 12 40 08
[email-masked]

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mardi 20 novembre 2007 23:17
À : [email-masked]
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-svc-03.txt 

Hi Colleagues,

In this version, we have worked on all the missing parts, including SDP parameters, semantics and their usage, and security considerations. 

Another major change is the addition to enable decoding order recovery of data units transported in multiple RTP sessions using layered multicast, without the requirement of interleaved mode. For this purpose, two alternative solutions are included. The first is based on cross-layer decoding order number (CL-DON), as specified in 8.1.2, which is close to RFC 3984 when interleaved mode is in use. The second uses timestamp etc., as specified in 8.1.1. The first process has been agreed by the editors, but having the second process in addition has not been agreed by the editors. The editors request the AVT WG to make a decision in this regard. 

There are also numerous smaller changes. In addition, we have addressed all the comments sent to the reflector or in private, but one from Magnus, which will be addressed in the next version. We also noticed that the current version does not display well for semantics of many of the media type parameters. We are sorry for that and will fix it in the next version. 

We thank a lot to Roni, Colin, Thomas Rusert, and Magnus for their reviews and valuable comments to the drafts. Summary of our responses to the comments are as follows:

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Tue, 27 Nov 2007 21:09:46 +0200

Hi Gérard,
 
Thanks for your review and comments. Please see my comments regarding the "no CL-DON mode" in section 8.1.1 in the previous email re Jonathan's comments. 

For your two detailed questions, I think my co-author Thomas will answer. 

I agree with you that section 8 should actually be normative. This is also true to the de-packetization session (session 7) in RFC 3984. In both RFC 3984 and this draft, the de-parketization process is referred to by the semantics of sprop-deint-buf-req, which is normative. 

At last, I think you are certainly welcome to bring any improvements to the draft. 
 
BR, YK

________________________________

	From: ext BABONNEAU Gerard RD-MAPS-REN [mailto:[email-masked]] 
	Sent: Tuesday, November 27, 2007 6:54 PM
	To: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]
	Cc: BERTHELOT Bertrand RD-MAPS-REN; THOMSON (Philippe, BORDES); ALCATEL (Yann, LEPROVOST); TDF (Philippe, COURBOULAY)
	Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-svc-03.txt 

	 Hi,

	

	
	
	Regards,

	Gérard Babonneau
	FT/RD/MAPS/DPC/APA

	

	-----Message d'origine-----
	De : [email-masked] [mailto:[email-masked]]
	Envoyé : mardi 20 novembre 2007 23:17
	À : [email-masked]
	Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Objet : RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-svc-03.txt

	Hi Colleagues,

---

From: "Thomas Schierl" <[email-masked]>
Date: Tue, 27 Nov 2007 12:20:09 -0800

Hi Gerard, all,

Please find my comments below.

Thomas Schierl
--------------
Fraunhofer HHI

> From: BABONNEAU Gerard RD-MAPS-REN
> Sent: Tuesday, November 27, 2007 8:54 AM

> 1) about synchronisation points in chapter 8.1.1, the document looks to me
very confuse: the re-ordering process is right, but I think it describes a
particular mode of realization rather than is demonstrates the feasibility
of re-ordering without the CL-DON. Other algorithms look feasible,
especially to increase the robustness of SVC in case of selective losses.

Yes, I agree. It just should give the idea how it works, not more. But, I do
not think that it should demonstrate any feasibilities. Please could you
stress, what is confusing about section 8.1.1?

> 2) In chapter 7, option I, point b. context ought to be enlarged: I can
understand that an encoder has a B layer (for instance Q enhancement) that
depend on A layer, and also a C layer (for instance D enhancement that
depend on A layer), and optionally a D layer (for instance Q enhancement)
that depend on C layer. However in this scheme, the receiver can use only a
one-dimensional dependency structure, and the figure 2 in chapter 8.1.1
applies also whatever the dependency path the receiver chooses. Re-ordering
always run even if layers A and B are in the same session and the same for C
and D, by parsing NALU information in RTP payload headers. SDP as describe
in section 9.3 give the receiver information to select the layers it
re-orders and decodes, and drops the others.

Yes, you are right. For the first step, I wanted to keep these constraints
as tight as possible to guarantee it works. But, I also think that relaxing
this section (point 7.I.b) as proposed by Jonathan is a good idea. There is
in principal no problem to support multi dimensional hierarchies, if
following the RTP session dependencies. I want to avoid parsing any NAL unit
headers, since re-ordering should be feasible on RTP level.

> I suggest to maintain section 8 and set it as non informative, but just to
demonstrate the principles of re-ordiring in both cases, and may be to add
annexes with examples of re-ordering algorithms? I guess also that some
constraints, independant of svc payload, could lead to informational drafts
or RFC.

As described above, I do not think this is necessary.

> May be I can propose a small contribution to non CL-DON mode?

If you want more text, I could extend section 8.1.1 and move it into an
informative annex. Since, there will not be any normative text in it.