[x264-devel] Re: Slices in x264
Ryan Dalzell
ryan at tullyroan.com
Wed Jan 17 15:30:54 CET 2007
On Wednesday 17 January 2007 12:13, List, Peter wrote:
> 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.
By the way, in case Peter or the rest of the list have labelled me as
an "anti-slice" zealot... :) I do think slices are good for all the reasons
that well described above. Unfortunately, in H.264 there is a serious
problem with slices in the decoder: namely "arbitrary slice order".
Cheers,
-Ryan
--
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html
More information about the x264-devel
mailing list