[x264-devel] Custom slice support

[Jery Bing]

I think that in any case, the slicing of the picture is done once at the
init of the encoder, so the decision can't be releated to the bit
rate/packet size of each slice.

it is true that by slicing in advance, i will have rate control for each
slice.
maybe in some cases i would like to do rate control of the overall frame.

maybe some pointer to the code is needed, but, is it possible in the current
implementation to use distributed rate control? the statistic from all the
encoders saved to a rate control struct and each encoder could update and
retrive the rate control decision from this struct?

this way in case of a relative uniform Quality picture, it may be possible
for each slice to fit into an MTU, and the statistic will be less noisy..




2007/11/16, Mojtaba Hosseini <Mojtaba.Hosseini at magorcorp.com>:
>
> On Fri, 2007-11-16 at 12:32 -0800, Jery Bing wrote:
> > running diffrent encoder for each slice gives me all the flexibility
> > that i need.
> > i can slice the screen as i want, and the ability to decode each slice
> > by himself.
> > also, i can run each slice with it own fps, or in my case, only when
> > changes are made.
> >
> > asking again, what is my lose by doing so? beside the fact the i need
> > to manage this at the encoder and the decoder side?
> >
>
> This question is not really related to x264 development but ...
> By splitting the frame into slices yourself (and not letting the
> encoder do it) you have this problem: you do not know what size each
> manually
> created slice will be. Since loss on the network happens based on MTU size
> (i.e. you normally lose one whole MTU), ideally you want one slice
> to be coded into an MTU, so that if it is lost, you lose only one slice.
> But if you arbitrarily split your frame into N slices, then (a) one slice
> may be much smaller than MTU (so you are being wasteful) or (b) one slice
> is
> much bigger than MTU (so it will be split into multiple MTUs and if one
> of these is lost, you lose the whole slice). That is the cost of your
> suggestion (although it has its own advantages).
>
> Mojtaba Hosseini
>
> _______________________________________________
> 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/86edae87/attachment.htm