[x264-devel] Custom slice support

[List, Peter]

Dear Mojtaba,
Thank you for you detailed explanation.
Regards
Peter
 


> > 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
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel