Subject: Re: [AVT] SVC design team - March 25th meeting summary

From: Alex Eleftheriadis <[email-masked]>
Date: Sat, 5 Apr 2008 12:45:55 +0300

Roni, all -

Nokia's switching to a non-assert statement on their IPR on this  
draft is a great step forward.

Comb1 and comb2 were designed as compromise solutions under the  
premise of the more restrictive Nokia IPR statement and the BT  
statement. With Nokia's commitment for a non-assert, I believe we can  
focus our energy to make a CL-DON solution work technically in the  
best possible way. If that's comb2, so be it, but I wouldn't tie a  
decision to make CL-DON mandatory in session multiplexing with mode  
1, to this being identical to chosing comb2.

As it stands, the only remaining item to be resolved appears to be  
the BT statement. It would be great to have some input from BT on  
this so that we can keep moving forward.

--Alex

On Mar 28, 2008, at 10:16 AM, Even, Roni wrote:
> The SVC design team had a conference call on March 25th.
>
>
>
> The first objective of the design team is to get consensus on the  
> decoding order recovery solution. Roni mentioned that if there will  
> be no agreement the WG chairs will draft a proposal and send it to  
> the AVT list trying to see if there if consensus can be agreed on  
> the list and if no consensus we may need to sue RFC 3929 procedures.
>
> Roni Noted that there are three IPR statements concerning this  
> draft from LMI (Vidyo), Nokia and BT
>
>
>
> The meeting started with a presentation on the "decoding order  
> recovery" prepared by Ye-kui (thanks).  The presentation describes  
> the two optional solutions: "Classical" RTP and CL-DON.
>
> The presentation suggested two options to combine the two methods:
>
> •          Combination of the two existing solutions for the non- 
> interleaved packetization mode
>
> –         Comb#1: Receivers are required to support the 1st  
> solution even PACSI NAL units carrying CS-DON information are  
> present, meaning that insertion of video NAL units to avoid type I  
> non-AU-aligned NAL units in sent NAL unit stream is always needed,  
> though that is not needed by the 2nd solution.
>
> –         Comb#2: An alternative is to mandate both inclusion of  
> PACSI NAL units carrying CS-DON information and insertion of video  
> NAL units to avoid type I non-AU-aligned NAL units in sent NAL unit  
> stream, such that the receiver can freely choose which solution to  
> use.
>
>
>
> Stephan Wenger announced that Nokia may be willing to change the  
> IPR statement adding non-assert clause if CL-DON will be mandatory.  
> (Making Comb#2 as the compromised solution)
>
> Stephan also pointed out that such non-assert terms will be less  
> restrictive then the LMI one.
>
>
>
> Thomas Wiegand said that this is a good direction and asked for  
> time to get feedback.
>
> Alex mentioned that Vidyo will review their statement.
>
>
>
> The group mentioned that there is still the BT IPR declaration that  
> does not have the non-assert term and asked if BT can reconsider  
> its IPR statement based on the good faith shown by the other  
> parties. (There was no BT member in the meeting)
>
>
>
> The summary is that the parties will look at a possibility to adopt  
> Comb#2 based on Stephan's statement and will try to give the  
> response to the next meeting of the design team
>
>
>
> The editors of the draft should continue with the text addressing  
> the other open issues in order to expedite the work.
>
> There is also a need to expand the text explaining the decoding  
> order procedures.
>
>
>
> The next meeting is on April 8th
>
> Time: 7:00 PST (San Francisco), 17:00 Israel
>
>
>
> http://www.timeanddate.com/worldclock/fixedtime.html? 
> month=4&day=8&year=2008&hour=7&min=0&sec=0&p1=224
>
>
>
> Dial in number: +1-678-7955235
>
>
>
> Regards
>
> Roni Even
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 6 Apr 2008 09:11:00 +0300

Alex,
I think that is order to progress the work we need to see some proposal
which we can get consesus on. From your reply I understand that you
object to comb2 so currently that leaves in your view only option 1.
That keeps us where we were for the last couple of months
Roni 

-----Original Message-----
From: Alex Eleftheriadis [mailto:[email-masked]] 
Sent: Saturday, April 05, 2008 12:46 PM
To: Even, Roni
Cc: [email-masked]
Subject: Re: [AVT] SVC design team - March 25th meeting summary

Roni, all -

Nokia's switching to a non-assert statement on their IPR on this draft
is a great step forward.

Comb1 and comb2 were designed as compromise solutions under the premise
of the more restrictive Nokia IPR statement and the BT statement. With
Nokia's commitment for a non-assert, I believe we can focus our energy
to make a CL-DON solution work technically in the best possible way. If
that's comb2, so be it, but I wouldn't tie a decision to make CL-DON
mandatory in session multiplexing with mode 1, to this being identical
to chosing comb2.

As it stands, the only remaining item to be resolved appears to be the
BT statement. It would be great to have some input from BT on this so
that we can keep moving forward.

--Alex

On Mar 28, 2008, at 10:16 AM, Even, Roni wrote:
> decoding order recovery solution. Roni mentioned that if there will be

> no agreement the WG chairs will draft a proposal and send it to the 
> AVT list trying to see if there if consensus can be agreed on the list

> and if no consensus we may need to sue RFC 3929 procedures.
>
> Roni Noted that there are three IPR statements concerning this draft 
> from LMI (Vidyo), Nokia and BT
>
>
>
> recovery" prepared by Ye-kui (thanks).  The presentation describes the

> two optional solutions: "Classical" RTP and CL-DON.
>
> *          Combination of the two existing solutions for the non- 
> -         Comb#1: Receivers are required to support the 1st  
> solution even PACSI NAL units carrying CS-DON information are present,

> meaning that insertion of video NAL units to avoid type I 
> -         Comb#2: An alternative is to mandate both inclusion of  
> PACSI NAL units carrying CS-DON information and insertion of video NAL

> units to avoid type I non-AU-aligned NAL units in sent NAL unit 
> Stephan Wenger announced that Nokia may be willing to change the IPR 
> statement adding non-assert clause if CL-DON will be mandatory.
> Thomas Wiegand said that this is a good direction and asked for time 
> to get feedback.
>
> does not have the non-assert term and asked if BT can reconsider its 
> IPR statement based on the good faith shown by the other parties. 
> (There was no BT member in the meeting)
>
>
>
> Comb#2 based on Stephan's statement and will try to give the response 
> to the next meeting of the design team
>
>
>
> The editors of the draft should continue with the text addressing the 
> other open issues in order to expedite the work.
>
> There is also a need to expand the text explaining the decoding order 
> procedures.
>
>
>

---

From: Alex Eleftheriadis <[email-masked]>
Date: Sun, 6 Apr 2008 11:44:48 +0300

Hi Roni. No, what I said (at least tried to) is that the "comb"  
solutions are combinations of two techniques, not necessarily  
elegant, which were necessitated by the limitations prior to the  
introduction of the non-assert by Nokia. What I suggested in my email  
below is that we may now be able to focus on a single solution (not a  
"comb" one), based on CS-DON. From a technical point of view I would  
much prefer to have a single technique in the draft addressing a  
problem, and not two (if possible). In this context, I would use  
elements from the non-CS-DON technique only to the extent that they  
improve the performance of CS-DON, and not for the sake of offering  
an alternative technique. CS-DON has a problem with mode 0 and FU-As,  
and the slides suggest a possible way to overcome them, albeit not  
very error resilient. If we agree that these modes are not  
particularly interesting in practice, we may be able to live with  
that, or we can try to fix it.

But we need to hear from BT if they are able and willing to switch to  
a non-assert on this. If not, then comb2 may be the way to go.

--Alex

On Apr 6, 2008, at 9:11 AM, Even, Roni wrote:
> premise
>> the
>> present,
>> NAL

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 6 Apr 2008 11:50:51 +0300

Alex,
Thanks, for clarifying, I probably had an understanding problem.
I think a way foreward is to have some text that we can look.

As for BT, we have to assume thay will keep their current IPR statement
unless we will get some other message
Roni

-----Original Message-----
From: Alex Eleftheriadis [mailto:[email-masked]] 
Sent: Sunday, April 06, 2008 11:45 AM
To: Even, Roni
Cc: [email-masked]
Subject: Re: [AVT] SVC design team - March 25th meeting summary

Hi Roni. No, what I said (at least tried to) is that the "comb"  
solutions are combinations of two techniques, not necessarily elegant,
which were necessitated by the limitations prior to the introduction of
the non-assert by Nokia. What I suggested in my email below is that we
may now be able to focus on a single solution (not a "comb" one), based
on CS-DON. From a technical point of view I would much prefer to have a
single technique in the draft addressing a problem, and not two (if
possible). In this context, I would use elements from the non-CS-DON
technique only to the extent that they improve the performance of
CS-DON, and not for the sake of offering an alternative technique.
CS-DON has a problem with mode 0 and FU-As, and the slides suggest a
possible way to overcome them, albeit not very error resilient. If we
agree that these modes are not particularly interesting in practice, we
may be able to live with that, or we can try to fix it.

But we need to hear from BT if they are able and willing to switch to a
non-assert on this. If not, then comb2 may be the way to go.

--Alex

On Apr 6, 2008, at 9:11 AM, Even, Roni wrote:
> Alex,
> I think that is order to progress the work we need to see some 
> proposal which we can get consesus on. From your reply I understand 
> that you object to comb2 so currently that leaves in your view only 
> option 1.
> That keeps us where we were for the last couple of months Roni
>

> decision to make CL-DON mandatory in session multiplexing with mode 1,

> to this being identical to chosing comb2.
>

>> be

---

From: Thomas Schierl <[email-masked]>
Date: Sun, 06 Apr 2008 17:11:21 +0200

Hi Roni,

You are right. We have to proceed as there will be no new statement from 
BT. This means, I will deliver improved text on the decoding order 
recovery with classical RTP mechanisms as requested by Ye-Kui. But I do 
not think that I will make it before the next SVC design team's phone 
call on Tuesday. So, let us see whether we get any news until Tuesday.

Best regards,
Thomas Schierl
----------------
Fraunhofer HHI

>>> Dial in number: +1-678-7955235

----
Visit us at

Photonics Europe / Strasbourg, France / 7-11 April 2008 / Booth 321
http://spie.org/photonics-europe.xml
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Mon, 7 Apr 2008 11:02:18 +0100

I think that it is best to follow Roni's advice and assume that BT will
maintain their current IPR statement.

I have raised the issue internally, and the legal advice I have received
is that we should not take a different position on this internet draft
than on any other internet draft or draft standard in any other
standards body.

Best regards

Mike

Mike Nilsson 
Multimedia Analysis and Coding
BT Group Chief Technology Office
___________________________ 

Sirius House (B54-MH), Room 92 
Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK 
Tel:    +44 1473 645413 
Mobile: +44 7917 025433 
Fax:    +44 1908 862365 
Email:  [email-masked]

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Even, Roni
Sent: 06 April 2008 09:51
To: Alex Eleftheriadis
Cc: [email-masked]
Subject: Re: [AVT] SVC design team - March 25th meeting summary

Alex,

-----Original Message-----
From: Alex Eleftheriadis [mailto:[email-masked]] 
Sent: Sunday, April 06, 2008 11:45 AM
To: Even, Roni
Cc: [email-masked]
Subject: Re: [AVT] SVC design team - March 25th meeting summary

--Alex

---

From: Alex Eleftheriadis <[email-masked]>
Date: Mon, 7 Apr 2008 13:19:10 +0300

Thanks Mike. I appreciate the heads-up and the effort. At least now  
we know what's the context in which we have to proceed.

--Alex

On Apr 7, 2008, at 1:02 PM, <[email-masked]> wrote:
>> draft
>>> response
>>> order