Re: [xrblock] Loss-Type concealment vs Buffer adjustment type concealment

Also - we should note that with video it is possible to use RTP based
retransmission and also FEC (e.g. COP3) - typically these would only be used
with IPTV as this is less delay sensitive than interactive services.

Alan

On 10/10/12 5:02 AM, "Alan Clark" <alan.d.clark@telchemy.com> wrote:

> Qin
> 
> The wording in draft-ietf-xrblock-xr-consec-.. is definitely related to audio.
> Video does have loss concealment and there are a range of methods used, for
> example:
> 
> (i) Frame freeze
> In this case the impaired video frame is not displayed and the previously
> displayed frame is hence ³frozen² for the duration of the loss even
> 
> (ii) Inter-frame extrapolation
> If an area of the video frame is damaged by loss, the same area from the
> previous frame(s) can be used to estimate what the missing pixels would have
> been.  This can work well in a scene with no motion but can be very noticeable
> if there is significant movement from one frame to another.  Simple decoders
> may simply re-use the pixels that were in the missing are, more complex
> decoders may try to use several frames to do a more complex extrapolation
> 
> (iii) Interpolation
> A decoder may use the undamaged pixels in the image to estimate what the
> missing block of image should have
> 
> (iv) Noise insertion
> A decoder may insert random pixel values - which would generally be less
> noticeable than a blank rectangle in the image
> 
> Alan
> 
> On 10/10/12 3:41 AM, "Qin Wu" <bill.wu@huawei.com> wrote:
> 
>> Hi,
>> In draft-ietf-xrblock-rtcp-xr-concsec,concealment is splitted into two type
>> of concealments.
>> One is Loss-Type concealment and the other is Buffer adjustment type
>> concealment.
>> So the question is are these two type of concealments applied to video? If
>> the answer is yes,
>> how to take video loss concealment into account? Since in the current draft,
>> when we define
>> Loss-type concealment and buffer adjustment type concealment, only audio loss
>> concealment 
>> is considered. See section 2.2 of draft-ietf-xrblock-rtcp-xr-concsec below
>> for defintions of loss-type concealment
>> and buffer adjustment type concealment:
>> "    
>>      Loss-type concealment is reactive insertion or deletion of samples
>>       in the audio playout stream due to effective frame loss at the
>>       audio decoder.  "Effective frame loss" is the event in which a
>>       frame of coded audio is simply not present at the audio decoder
>>       when required.  In this case, substitute audio samples are
>>       generally formed, at the decoder or elsewhere, to reduce audible
>>       impairment.
>>  
>>       Buffer Adjustment-type concealment is proactive or controlled
>>       insertion or deletion of samples in the audio playout stream due
>>       to jitter buffer adaptation, re-sizing or re-centering decisions
>>       within the endpoint. Because this insertion is controlled, rather than
>> occurring
>>       randomly in response to losses, it is typically less audible than
>>       loss-type concealment.  For example, jitter buffer adaptation
>>       events may be constrained to occur during periods of talker
>>       silence, in which case only silence duration is affected, or
>>       sophisticated time-stretching methods for insertion/deletion
>>       during favorable periods in active speech may be employed.  For
>>       these reasons, buffer adjustment-type concealment MAY be exempted
>>       from inclusion in calculations of Concealed Seconds and Severely
>>       Concealed Seconds.
>> "
>>  
>> Regards!
>> -Qin 
>> 
>> 
>> _______________________________________________
>> xrblock mailing list
>> xrblock@ietf.org
>> https://www.ietf.org/mailman/listinfo/xrblock
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock