[x264-devel] Custom slice support

[Mojtaba Hosseini]

On Wed, 2007-11-14 at 15:40 +0100, List, Peter wrote:
> 
> Dear Mojtaba,
> I'm sorry; it seems I don't really get it...
> How do you guarantee that "prediction between slices is not done"
> (Mojtaba) when "Current x264 doesn't support slices at all" (Loren)
> 

Hello Peter,
  I believe Loren means that the current x264 that you can get from
svn right now puts one frame into one NAL. It does NOT split it into
multiple slices. 
  Now how does the patch (which is not in svn) guarantee no prediction
from MB outside of slice? Take a look at x264_macroblock_cache_load()
method in /common/macroblock.c. This function is called for each MB
(from x264_slice_write() of encoder.c) and it sets the MB's i_neighbour
variable. It does so by taking into account the slice's first mb
variable. So the top MB is not available if its index is less than
that slice's first MB. Same for left, top left, etc. So the patch in of
itself does not guarantee that prediction is not done from outside of
the slice BUT that is because the x264 encoder code as is provides that
guarantee. 

> How is this patch working...
> The process starts with x264 producing macroblocks until one packet is 
> full, right? Than your patch produces a slice header and completes one
> NALU.
> If x264 then continues, how does it know that it needs to produce a new
> slice? Does the x264code still have all the necessary variables and
> methods to obey the H264 slice restrictions, so that your patch can
> feedback the fact, that a new slice is to be coded into the original
> x264 code? 
  I don't understand exactly what you are asking. The patch lets x264
encode until the bitsteam size exceeds a given value (note that this 
does NOT provide any guarantee on maximum size), then it ends this
slice and sets up all the variables for a new slice to begin. If you
look at the patch, this part is fairly straight forward. 

> If that is true what else could we want?? Why is Loren saying then:
> 
> >> Current x264 doesn't support slices at all. It will support
> horizontal 
> >> slices when I get around to merging that patch. 
> 
 I believe Loren means that the current x264 code resident in the svn
does not support slices until he merges the patch I have been referring
to into the svn code. There is nothing in x264 that inherently prevents
support for multiple slice per frame feature. 

>  
> If that is true, we have no problem, because slice headers (at least
> H264-slice headers) DO HAVE all the information in them we need. 
> 
Right. As long as frame level things like width and height don't change
and you don't lose an SPS and PPS (which are NALs) containing that
change in transmission, decoder DOES have all the information to decode
an independent NAL. Even if previous NALs were lost. 

> To me that only makes sense if a NALU is equivalent to a slice in the
> H264-definition (or multiple complete slices, or parts of slices, that
> become complete with multiple complete NALU's).
> Is that the case??? 
 I believe so. Each NAL represents a slice in a frame according to
H264-definition.

Mojtaba