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

[rambler]

-------Original Message-------
 
From: x264-devel at videolan.org
Date: 01/17/07 07:45:23
To: x264-devel at videolan.org
Subject: [x264-devel] Re: AW: Re: Error Concealment
 
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 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




 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20070117/f511dfd3/attachment.htm 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT1.txt
Url: http://mailman.videolan.org/pipermail/x264-devel/attachments/20070117/f511dfd3/attachment.txt 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20070117/f511dfd3/attachment-0001.htm 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT3.txt
Url: http://mailman.videolan.org/pipermail/x264-devel/attachments/20070117/f511dfd3/attachment-0001.txt