[x264-devel] Re: AW: Re: Error Concealment

[Ryan Dalzell]

On Wednesday 17 January 2007 13:44, Awadh Bihari wrote:
> 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?

When you say you've lost the 3rd macroblock, do you mean the slice stops 
there in the middle of decoding the macroblock, or you have detected an 
error in the decoding process at the 3rd macroblock?

Well, actually the results are much the same. What is certain is that the 
3rd macroblock and the entire rest of the slice cannot be used for decoding 
(it is either missing or you have lost sync in the decoder because of the 
error). So you certainly have to (try to) conceal the rest of the slice.

But what about the beginning of the slice? If the rest of the slice is 
simply missing you could probably trust the bit you have decoded up to the 
3rd macroblock. But if you actually found an error in the 3rd macroblock it 
is very likely some of the macroblocks before the 3rd are corrupt, and 
usually in an unsightly green and purple. So you can't really trust the 
data before there error. It is really up to you how much you think you 
should conceal before the error, but quite honestly in my experience I 
found the best results by concealing the whole slice. In other words 
completely discarding the slice with the error.

Hope that helps to answer your question.

Cheers,
-Ryan

> On 1/17/07, Ryan Dalzell <x264 at tullyroan.com> wrote:
> > On Wednesday 17 January 2007 12:38, List, Peter wrote:
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: x264-devel-bounce at videolan.org [mailto:x264-devel-
> > > > bounce at videolan.org] Im Auftrag von Ryan Dalzell
> > > > Gesendet: Mittwoch, 17. Januar 2007 13:28
> > > > An: x264-devel at 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

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html