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

[rambler]

-------Original Message-------
 
From: x264-devel at videolan.org
Date: 01/17/07 07:41:30
To: x264-devel at videolan.org
Subject: [x264-devel] Re: AW: Re: Slices in x264
 
On Wednesday 17 January 2007 12:30, List, Peter wrote:
> > -----Ursprüngliche Nachricht-----
> > Von: x264-devel-bounce at videolan.org [mailto:x264-devel-
> > bounce at videolan.org] Im Auftrag von Tobias Bergmann
> > Gesendet: Mittwoch, 17. Januar 2007 11:17
> > An: x264-devel at videolan.org
> > Betreff: [x264-devel] Re: Slices in x264
> >
> > Guillaume Poirier wrote:
> > > Måns Rullgård wrote:
> > >> Guillaume Poirier <gpoirier at mplayerhq.hu> writes:
> > >> 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 :-)
> >
> > What slices support as-is is spatial "error containment". Together with
> > a defined I frame interval (or at least intra-mb interval) temporal
> > "error containment" is provided as well.
> >
> > If I get it right, the new method tries to "fix" parts of the broken
> > stream based on surrounding motion vectors. That could be called "error
> > concealment" but has nothing to do with slices.
> >
> > A better tool instead of slices is that completely coded macroblock
> > which resets the stream. It can be placed as often as needed depending
> > on current line quality (if there is a feedback on that).
>
> I guess by "completely coded" you mean Intra coded macroblocks. The
> problem here is that artefacts due to bitstream errors usually get
> smeared over the whole picture. In other words you can not fix one wrong
> macroblock with one correct intra-macroblock. Errors DON'T get smeared
> over slice boundaries though. An Intra-Slice once in a while DOES fix the
> problem for that slice!
 
Errors do get smeared over slice boundaries in subsequence pictures that use
the error picture for reference. There is no clause that states that motion
vectors cannot cross slice boundaries in the picture that they are
referencing. So to force update using an intra slice in any picture after
the next one in decoding order you need to determine how much the error
could have travelled. This gets quite complicated I would imagine.
 
Of course, you could design the encoder to use the same fixed arrangement of
slices in every picture and not cross those slice boundaries with motion
vectors. That would make the forced update as simple as you describe. But
you would lose the ability to create slices that fit efficiently into a
single network packet and you would lose some coding efficiency, possibly
quite a lot.
 
Cheers,
-Ryan
 
--
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html
 
 
 
--
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.433 / Virus Database: 268.16.13/632 - Release Date: 01/16/2007
4:36 PM
 
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20070117/347605dc/attachment.htm