<div>Ok Ryan, In that case suppose we lost the 3rd macroblock of the 2nd slice in a picture containing 3 slices. </div>
<div>Do we need to conceal the whole slice (2nd slice) or only the 3rd macroblock in the 2nd slice? </div>
<div> </div>
<div><br><br> </div>
<div><span class="gmail_quote">On 1/17/07, <b class="gmail_sendername">Ryan Dalzell</b> <<a href="mailto:x264@tullyroan.com">x264@tullyroan.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Wednesday 17 January 2007 12:38, List, Peter wrote:<br>> > -----Ursprüngliche Nachricht-----<br>> > Von:
<a href="mailto:x264-devel-bounce@videolan.org">x264-devel-bounce@videolan.org</a> [mailto:<a href="mailto:x264-devel-">x264-devel-</a><br>> > <a href="mailto:bounce@videolan.org">bounce@videolan.org</a>] Im Auftrag von Ryan Dalzell
<br>> > Gesendet: Mittwoch, 17. Januar 2007 13:28<br>> > An: <a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br>> ><br>> > Betreff: [x264-devel] Re: Error Concealment<br>> >
<br>> > On Wednesday 17 January 2007 09:53, Awadh Bihari wrote:<br>> > > Please let me know how to detect the slice loss at the decoder side.<br>> > > It can only be detected if active sps/pps is not equal to sps/pps ?
<br>> > Due to arbitrary slice order and the fact that slice headers do not<br>> > tell<br>> > you how many macroblocks are in the slice (and assuming you are<br>> > receiving<br>> > the video data over a network), I believe that the only way is to
<br>> > actually<br>> > decode each slice and count the number of macroblocks that it<br>> > contributes<br>> > to a picture. Then, after a suitable period of time to allow late<br>> > packets
<br>> > to arrive, if you still haven't decoded all the macroblocks of a<br>> > picture<br>> > then you have lost some slices.<br>><br>> I dont see why you need to count anything. The slice always tells you
<br>> where it's locates in the frame, so you just dump the macroblocks to<br>> that place. If you have arbitrary slice order, things get more difficult,<br>> but in principle it should be the same. You should be able to detect
<br>> when the next frame starts (by POC and/or frame_number). If that happens<br>> you can finalize the previous frame, and that's it. Am I missing<br>> something<br>> here?<br><br>Yes, I think you are. Let's say that your receive six slices for a picture
<br>before a slice with a different POC arrives. Is this all the slices for<br>that picture, or are there supposed to be seven and one got lost? You can't<br>tell, short of decoding all the slices and counting the number of
<br>macroblocks provided.<br><br>This gets even worse when slices can be out of order across picture<br>boundaries. I have searched high and low the spec and I cannot find a<br>statement that precludes this from happening. (Of course, due to the lack
<br>of plain English in the spec it could be there.) Also this could happen<br>when packets become reordered due to network jitter or taking different<br>routes. Then you don't even know that you have the last slice you are going
<br>to get when the POC changes. So you have to wait a while to see if there<br>are more packets to arrive containing slices for the current picture.<br><br>IMO, it's pretty horrible and ASO is a good example of a little extra
<br>flexibility with not much real value but with a high cost in real world<br>systems.<br><br>Cheers,<br>-Ryan<br><br>--<br>This is the x264-devel mailing-list<br>To unsubscribe, go to: <a href="http://developers.videolan.org/lists.html">
http://developers.videolan.org/lists.html</a><br><br></blockquote></div><br>