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

[List, Peter]

> -----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 14:27

> An: x264-devel at videolan.org

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

> 

> 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.

 

I was expecting that my network interface would sort the packets for me. That may be naïve though. A delay would be involved as well in this case, but I need a receiving buffer anyways, right?

 

> 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.)

 

I will check if that is possible, but I definitely do not believe it is!

And yes, this standard is not that easy to read :-) 

 

> 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 

 

I have heard a lot of different things about FMO (Flexible Macroblock Ordering). Some said it was absolutely easy to implement (on PC: simply have more than one input-buffer, one for every slice-group. Then, while decoding from left to right, top to bottom simply switch to the right buffer). Some others said it was horrible. 

Could you comment? 

 

> ASO is a good example of a little extra flexibility with not much real 

> value but with a high cost in real world systems.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20070117/6cd6ed34/attachment.htm