Ok Ryan, In that case suppose we lost the 3rd macroblock of the 2nd slice in
a picture containing 3 slices.
Do we need to conceal the whole slice (2nd slice) or only the 3rd macroblock
in the 2nd slice?




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