[x264-devel] AW: Re: Slices in x264

[List, Peter]

Hello everyone,

 

Concerning "error concealment":

I think the terms "error concealment" and "error robustness" are mixed up a little bit in many discussions. In the case of slices it's more "error robustness" in a sense that a decoder can better handle errors in a bitstream.  Here, destroyed areas in a video-frame (due to packet-loss) get SMALLER. The fact that they are smaller also leads to more possibilities for concealment.  

 

let me shortly explain why I think slices are "good":

 

In general, if ANY error occurred in the bitstream, the decoder will lose sync. To regain sync again THE ONLY POSSIBILITY is to search for the next header structure in the bitstream.  If no slices are present this header will be the next frame-header. The consequence is: the decoder will lose the complete rest of the frame which might correspond to many network-packets. Even worse, if the error-rate is high enough, that a packet-loss occurs on average in every frame, than the decoder will (almost) never be able to decode the bottom parts of the video. And don't be missleaded here, for instance in mobile applications this is very well possible. You only have to have a large distance to you base-station and and you will experience a lot of packet-losses. 

Slices are constructed in a way, that each slice is independently decodable. So, if for instance every slice corresponds to 1 row of macroblocks, only 16 lines in a video-frame would be missing if a slice got lost. These 16 lines can easily be CONCEALD (most simple) by putting the content of the last frame into the current frame. Also some estimated motion could be used to replace the missing parts by some content of the last frame...

 

Maybe this group was not so much aware of the problems that occur in error prone environments, but I tell you: error resilience is an important area!! As a consequence I would propose to reintroduce the concept of slices into x264 and handle it independently of threading. 

 

Regards, 

                  Peter

 

 

> -----Ursprüngliche Nachricht-----

> Von: Guillaume Poirier [mailto:gpoirier at mplayerhq.hu]

> Gesendet: Mittwoch, 17. Januar 2007 10:39

> An: x264-devel at videolan.org

> Betreff: [x264-devel] Re: Slices in x264

> 

> Hi Måns,

> 

> Måns Rullgård wrote:

> > Guillaume Poirier <gpoirier at mplayerhq.hu> writes:

> >

> >

> >>Hi,

> >>

> >>List, Peter wrote:

> >>

> >>>Hello everyone,

> >>>

> >>>

> >>>

> >>>I am new to this group although experienced with H.264. I tried to use

> >>>the x264 encoder to prepare sequences for an error-resilience test.

> >>>

> >>>I was very surprised, when I discovered, that x264 CAN NOT produce

> >>>slices! Slices are the basic tool to cope with packet-losses over

> >>>IP-based networks (without retransmission), and in fact can make a huge

> >>>difference for subjective quality, in particular at high loss-rates.

> >>

> >>Very basic indeed. _I_ think it's better to add more advanced parity

> >>(which allow the errors to be recovered) infos somewhere in the

> >>transport layer stream than using slices.

> >

> >

> > Using error correcting coding at the transmission layer substantially

> > increases the bitrate.  With slices a transmission error will ruin the

> > rest of the slice, while other slices still decode properly.

> > Sometimes a little damage here and there is acceptable if it means you

> > can keep the bitrate down.  Besides, you don't always have control

> > over the transmission encoding.

> >

> > Put another way, slices limit the scope of the damage caused by

> > whatever transmission errors make it through your error correction

> > layers.

> >

> > Anyone who has watched digital TV should appreciate the usefulness of

> > slices.

> 

> Mmmm. I guess I did not understand what "error concealment" meant. My

> dictionary translates it to "dissimulation des erreurs" which more or

> less translates back in English as "error hiding", which by my book

> means that if an error occurs, it doesn't show, up to a certain amount

> of errors you can't recover.

> 

> As far as I understand, slices don't allow that, that's why I thought

> that better error correction blocks was the solution.

> 

> But now that I understand what "error concealment" means, and I see

> that slices seem like the right tool for that job.

> 

> Sorry for the trouble. I'm learning smth new every day :-)

> 

> 

> >>>Did I miss something here, or is it true that x264 can only produce 1

> >>>slice per frame???

> >>

> >>It used until r609 to but it was replaced by a much better and faster

> >>multi-threaded encoding mode.

> >

> >

> > Multithreaded encoding and slices are really distinct features.

> > Slices may be desired, as the OP says, with or without multithreading.

> 

> Loren, Out of curiosity, did you remove sliced encoding support

> because it was too deeply "interleaved" with multi-threaded support,

> so your new multi-threaded encoding mode had to make sliced encoding

> go away? Or are there other reasons?

> 

> Guillaume

> 

> --

> 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/0c203b5f/attachment.htm