<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="IncrediMail 1.0" name=GENERATOR></HEAD>
<BODY style="BACKGROUND-POSITION: 0px 0px; FONT-SIZE: 12pt; MARGIN: 5px 10px 10px; FONT-FAMILY: Arial" bgColor=#ffffff background="" scroll=yes ORGYPOS="0">
<TABLE id=INCREDIMAINTABLE cellSpacing=0 cellPadding=2 width="100%" border=0>
<TBODY>
<TR>
<TD id=INCREDITEXTREGION style="FONT-SIZE: 12pt; CURSOR: auto; FONT-FAMILY: Arial" width="100%">
<DIV> </DIV>
<DIV> </DIV>
<DIV id=IncrediOriginalMessage><I>-------Original Message-------</I></DIV>
<DIV> </DIV>
<DIV id=receivestrings>
<DIV dir=ltr style="FONT-SIZE: 11pt" <i><B>From:</B></I> <A href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</A></DIV>
<DIV dir=ltr style="FONT-SIZE: 11pt" <i><B>Date:</B></I> 01/17/07 08:23:25</DIV>
<DIV dir=ltr style="FONT-SIZE: 11pt" <i><B>To:</B></I> <A href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</A></DIV>
<DIV dir=ltr style="FONT-SIZE: 11pt" <i><B>Subject:</B></I> [x264-devel] Re: AW: Re: Error Concealment</DIV></DIV>
<DIV> </DIV>
<DIV>On Wednesday 17 January 2007 13:44, Awadh Bihari wrote:</DIV>
<DIV>> Ok Ryan, In that case suppose we lost the 3rd macroblock of the 2nd slice</DIV>
<DIV>> in a picture containing 3 slices.</DIV>
<DIV>> Do we need to conceal the whole slice (2nd slice) or only the 3rd</DIV>
<DIV>> macroblock in the 2nd slice?</DIV>
<DIV> </DIV>
<DIV>When you say you've lost the 3rd macroblock, do you mean the slice stops</DIV>
<DIV>there in the middle of decoding the macroblock, or you have detected an</DIV>
<DIV>error in the decoding process at the 3rd macroblock?</DIV>
<DIV> </DIV>
<DIV>Well, actually the results are much the same. What is certain is that the</DIV>
<DIV>3rd macroblock and the entire rest of the slice cannot be used for decoding</DIV>
<DIV>(it is either missing or you have lost sync in the decoder because of the</DIV>
<DIV>error). So you certainly have to (try to) conceal the rest of the slice.</DIV>
<DIV> </DIV>
<DIV>But what about the beginning of the slice? If the rest of the slice is</DIV>
<DIV>simply missing you could probably trust the bit you have decoded up to the</DIV>
<DIV>3rd macroblock. But if you actually found an error in the 3rd macroblock it</DIV>
<DIV>is very likely some of the macroblocks before the 3rd are corrupt, and</DIV>
<DIV>usually in an unsightly green and purple. So you can't really trust the</DIV>
<DIV>data before there error. It is really up to you how much you think you</DIV>
<DIV>should conceal before the error, but quite honestly in my experience I</DIV>
<DIV>found the best results by concealing the whole slice. In other words</DIV>
<DIV>completely discarding the slice with the error.</DIV>
<DIV> </DIV>
<DIV>Hope that helps to answer your question.</DIV>
<DIV> </DIV>
<DIV>Cheers,</DIV>
<DIV>-Ryan</DIV>
<DIV> </DIV>
<DIV>> On 1/17/07, Ryan Dalzell <<A href="mailto:x264@tullyroan.com">x264@tullyroan.com</A>> wrote:</DIV>
<DIV>> > On Wednesday 17 January 2007 12:38, List, Peter wrote:</DIV>
<DIV>> > > > -----Ursprüngliche Nachricht-----</DIV>
<DIV>> > > > Von: <A href="mailto:x264-devel-bounce@videolan.org">x264-devel-bounce@videolan.org</A> [mailto:x264-devel-</DIV>
<DIV>> > > > <A href="mailto:bounce@videolan.org">bounce@videolan.org</A>] Im Auftrag von Ryan Dalzell</DIV>
<DIV>> > > > Gesendet: Mittwoch, 17. Januar 2007 13:28</DIV>
<DIV>> > > > An: <A href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</A></DIV>
<DIV>> > > ></DIV>
<DIV>> > > > Betreff: [x264-devel] Re: Error Concealment</DIV>
<DIV>> > > ></DIV>
<DIV>> > > > On Wednesday 17 January 2007 09:53, Awadh Bihari wrote:</DIV>
<DIV>> > > > > Please let me know how to detect the slice loss at the decoder</DIV>
<DIV>> > > > > side. It can only be detected if active sps/pps is not equal to</DIV>
<DIV>> > > > > sps/pps ?</DIV>
<DIV>> > > ></DIV>
<DIV>> > > > Due to arbitrary slice order and the fact that slice headers do not</DIV>
<DIV>> > > > tell</DIV>
<DIV>> > > > you how many macroblocks are in the slice (and assuming you are</DIV>
<DIV>> > > > receiving</DIV>
<DIV>> > > > the video data over a network), I believe that the only way is to</DIV>
<DIV>> > > > actually</DIV>
<DIV>> > > > decode each slice and count the number of macroblocks that it</DIV>
<DIV>> > > > contributes</DIV>
<DIV>> > > > to a picture. Then, after a suitable period of time to allow late</DIV>
<DIV>> > > > packets</DIV>
<DIV>> > > > to arrive, if you still haven't decoded all the macroblocks of a</DIV>
<DIV>> > > > picture</DIV>
<DIV>> > > > then you have lost some slices.</DIV>
<DIV>> > ></DIV>
<DIV>> > > I dont see why you need to count anything. The slice always tells you</DIV>
<DIV>> > > where it's locates in the frame, so you just dump the macroblocks to</DIV>
<DIV>> > > that place. If you have arbitrary slice order, things get more</DIV>
<DIV>> ></DIV>
<DIV>> > difficult,</DIV>
<DIV>> ></DIV>
<DIV>> > > but in principle it should be the same. You should be able to detect</DIV>
<DIV>> > > when the next frame starts (by POC and/or frame_number). If that</DIV>
<DIV>> > > happens you can finalize the previous frame, and that's it. Am I</DIV>
<DIV>> > > missing something</DIV>
<DIV>> > > here?</DIV>
<DIV>> ></DIV>
<DIV>> > Yes, I think you are. Let's say that your receive six slices for a</DIV>
<DIV>> > picture before a slice with a different POC arrives. Is this all the</DIV>
<DIV>> > slices for that picture, or are there supposed to be seven and one got</DIV>
<DIV>> > lost? You can't</DIV>
<DIV>> > tell, short of decoding all the slices and counting the number of</DIV>
<DIV>> > macroblocks provided.</DIV>
<DIV>> ></DIV>
<DIV>> > This gets even worse when slices can be out of order across picture</DIV>
<DIV>> > boundaries. I have searched high and low the spec and I cannot find a</DIV>
<DIV>> > statement that precludes this from happening. (Of course, due to the</DIV>
<DIV>> > lack of plain English in the spec it could be there.) Also this could</DIV>
<DIV>> > happen when packets become reordered due to network jitter or taking</DIV>
<DIV>> > different routes. Then you don't even know that you have the last slice</DIV>
<DIV>> > you are going</DIV>
<DIV>> > to get when the POC changes. So you have to wait a while to see if</DIV>
<DIV>> > there are more packets to arrive containing slices for the current</DIV>
<DIV>> > picture.</DIV>
<DIV>> ></DIV>
<DIV>> > IMO, it's pretty horrible and ASO is a good example of a little extra</DIV>
<DIV>> > flexibility with not much real value but with a high cost in real world</DIV>
<DIV>> > systems.</DIV>
<DIV>> ></DIV>
<DIV>> > Cheers,</DIV>
<DIV>> > -Ryan</DIV>
<DIV>> ></DIV>
<DIV>> > --</DIV>
<DIV>> > This is the x264-devel mailing-list</DIV>
<DIV>> > To unsubscribe, go to: <A href="http://developers.videolan.org/lists.html">http://developers.videolan.org/lists.html</A></DIV>
<DIV> </DIV>
<DIV>--</DIV>
<DIV>This is the x264-devel mailing-list</DIV>
<DIV>To unsubscribe, go to: <A href="http://developers.videolan.org/lists.html">http://developers.videolan.org/lists.html</A></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>--</DIV>
<DIV>No virus found in this incoming message.</DIV>
<DIV>Checked by AVG.</DIV>
<DIV>Version: 7.5.433 / Virus Database: 268.16.13/632 - Release Date: 01/16/2007 4:36 PM</DIV>
<DIV> </DIV>
<DIV>.</DIV></TD></TR>
<TR>
<TD id=INCREDIFOOTER width="100%">
<TABLE cellSpacing=0 cellPadding=0 width="100%">
<TBODY>
<TR>
<TD width="100%"></TD>
<TD id=INCREDISOUND vAlign=bottom align=middle></TD>
<TD id=INCREDIANIM vAlign=bottom align=middle></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE><SPAN id=IncrediStamp><SPAN dir=ltr><A href="http://www.incredimail.com/index.asp?id=54475"><IMG alt="Add FUN to your email - CLICK HERE!" hspace=0 src="http://www2.incredimail.com/contents/stamps/imstp_emo_en.gif" align=baseline border=0></A></SPAN></SPAN></BODY></HTML>