[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] SVC design team - March 25th meeting summary
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