[x264-devel] Custom slice support

[Jery Bing]

I have the same problem. I need to slice the picture before streaming.
what is the lose if i slice the picture some way before encding and run x
instances of the decoder on each slice?


2007/11/16, List, Peter <Peter.List at t-systems.com>:
>
> 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
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20071116/2e5f475f/attachment.htm