Re: [xrblock] after the IPR Disclosure related to draft-ietf-xrblock-rtcp-xr-video-lc

[Alan Clark <[e-mail]>]

Dan

The video loss concealment draft IPR situation continues to get muddier.

(a) I would like to withdraw my name from the list of authors on this 
draft as I cannot support what appears to have happened. Whether or not 
Huawei withdraw their IPR disclosure and the draft does/ does not go 
forward, I do not want to be associated with this document.

(b) I strongly recommend that the WG abandon this draft.

Best Regards

Alan Clark


On 3/24/16 7:49 AM, Alan Clark wrote:
> Hi Mo,
>
> The language you suggest removing is, as you say, inconsequential to 
> the draft and could easily be removed.
>
> In fact the insertion of language from a patent into the draft without 
> a coincident verbal disclosure of the patent to the WG seems rather 
> strange and could be seen as a potential violation of IETF patent policy?
>
> We should also ask why the language describing this "example" in the 
> draft became much more specific between the -00 and -01 drafts, did 
> this change in language tie the draft more closely to a patent?
>
> Working Group Draft 00 - February 2015
> e.g., motion vector of each macroblock, and imperceptibly embed them 
> into other parts of the video frame.
>
> Working Group Draft 01 - July 2015
> e.g., redundant motion vector of the first macroblock in a slice of 
> this area and redundant motion vector difference of other macroblocks 
> in this slice of this area, and imperceptibly embed them into other 
> parts of the video frame sent in a different RTP packet or in the next 
> frame, e.g., other slices of this area.
>
> Clearly an implementer of the metrics reporting protocol would not 
> need to implement a loss concealment algorithm in order to report the 
> metrics - hence the disclosure should be withdrawn regardless of 
> whether this language is present or not.
>
> Regards
>
> Alan
>
>
>
> On 3/24/16 5:20 AM, Huangyihong (Rachel) wrote:
>>
>> *From:*xrblock [mailto:[e-mail]] *On Behalf Of *Mo 
>> Zanaty (mzanaty)
>> *Sent:* Thursday, March 24, 2016 9:09 AM
>> *To:* [e-mail]
>> *Subject:* Re: [xrblock] after the IPR Disclosure related to 
>> draft-ietf-xrblock-rtcp-xr-video-lc
>>
>> On 3/8/16 2:27 PM, Romascanu, Dan (Dan) wrote:
>>
>> > We have two options:
>>
>> > 1. Continue as planned with the approval and publication process
>>
>> > 2. Not proceed with this document.
>>
>> I would like to propose a third option:
>>
>> 3. Remove an inconsequential sentence in the draft and remove the IPR 
>> disclosure before progressing the draft.
>>
>> After reading the draft, IPR disclosure and patent, it is very clear 
>> that the patent relates to a single "For example" sentence in section 
>> 3 d) of the draft ("Error Resilient Encoding") since they even share 
>> common language.
>>
>> However, this "For example" sentence of the draft is purely 
>> informational background on some examples of loss concealment 
>> techniques within some video codec implementations. It is completely 
>> inconsequential to the rest of the draft, and does not even provide 
>> any additional motivation beyond the rest of the introductory sections.
>>
>> I propose the authors remove this "For example" sentence and the IPR 
>> holders remove the IPR disclosure if it no longer applies to the 
>> revised draft.
>>
>> https://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-video-lc-05#section-3
>>
>> OLD:
>>
>> d) Error Resilient Encoding
>>
>> The sender encodes the message in a redundant way so that receiver
>>
>> can correct errors using the redundant information.There are usually
>>
>> two kinds of Error Resilient Encoding: One is that the redundant data
>>
>> useful for error resiliency performed at the decoder can be embedded
>>
>> into the compressed image/video bitstream. For example, the encoder
>>
>> can select a crucial area of an original video frame, extract some
>>
>> important characteristics of this area as the redundant information,
>>
>> e.g., redundant motion vector of the first macroblock in a slice of
>>
>> this area and redundant motion vector difference of other macroblocks
>>
>> in this slice of this area, and imperceptibly embed them into other
>>
>> parts of the video frame sent in a different RTP packet or in the
>>
>> next frame, e.g., other slices of this area. The other is bit-block
>>
>> level encoding, e.g., FEC.
>>
>> NEW:
>>
>> d) Error Resilient Encoding
>>
>> The sender encodes the message in a redundant way so that receiver
>>
>> can correct errors using the redundant information.There are usually
>>
>> two kinds of Error Resilient Encoding: One is that the redundant data
>>
>> useful for error resiliency performed at the decoder can be embedded
>>
>> into the compressed image/video bitstream. The other is bit-block
>>
>> level encoding, e.g., FEC.
>>
>> If this third option is not possible, I suggest not progressing the 
>> draft (option 2).
>>
>> Regards,
>>
>> Mo
>>
>>
>>
>> _______________________________________________
>> xrblock mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/xrblock
>
>
>
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock