<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 07:27:36</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 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 side.</DIV>
<DIV>> > > It can only be detected if active sps/pps is not equal to sps/pps ?</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 difficult,</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 happens</DIV>
<DIV>> you can finalize the previous frame, and that's it. Am I missing</DIV>
<DIV>> something</DIV>
<DIV>> here?</DIV>
<DIV> </DIV>
<DIV>Yes, I think you are. Let's say that your receive six slices for a picture</DIV>
<DIV>before a slice with a different POC arrives. Is this all the slices for</DIV>
<DIV>that picture, or are there supposed to be seven and one got 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 lack</DIV>
<DIV>of plain English in the spec it could be there.) Also this could happen</DIV>
<DIV>when packets become reordered due to network jitter or taking different</DIV>
<DIV>routes. Then you don't even know that you have the last slice you are going</DIV>
<DIV>to get when the POC changes. So you have to wait a while to see if there</DIV>
<DIV>are more packets to arrive containing slices for the current 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> </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>