[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] SVC design team - March 25th meeting summary
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
Even, Roni wrote:
> 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:alex at vidyo.com]
> Sent: Sunday, April 06, 2008 11:45 AM
> To: Even, Roni
> Cc: avt at ietf.org
> 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
>>
>> -----Original Message-----
>> From: Alex Eleftheriadis [mailto:alex at vidyo.com]
>> Sent: Saturday, April 05, 2008 12:46 PM
>> To: Even, Roni
>> Cc: avt at ietf.org
>> 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:
>>
>>> 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
>>> 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
>
>
>
----
Visit us at
Photonics Europe / Strasbourg, France / 7-11 April 2008 / Booth 321
http://spie.org/photonics-europe.xml
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt