<div dir="rtl"><div>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.</div>
<div> </div>
<div>it is true that by slicing in advance, i will have rate control for each slice. </div>
<div>maybe in some cases i would like to do rate control of the overall frame.</div>
<div> </div>
<div>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?
</div>
<div> </div>
<div>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..</div>
<div> </div>
<div><br><br> </div>
<div><span class="gmail_quote">2007/11/16, Mojtaba Hosseini <<a href="mailto:Mojtaba.Hosseini@magorcorp.com">Mojtaba.Hosseini@magorcorp.com</a>>:</span>
<blockquote class="gmail_quote" style="BORDER-RIGHT: #ccc 1px solid; PADDING-RIGHT: 1ex; PADDING-LEFT: 1ex; MARGIN: 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Fri, 2007-11-16 at 12:32 -0800, Jery Bing wrote:<br>> running diffrent encoder for each slice gives me all the flexibility
<br>> that i need.<br>> i can slice the screen as i want, and the ability to decode each slice<br>> by himself.<br>> also, i can run each slice with it own fps, or in my case, only when<br>> changes are made.
<br>><br>> asking again, what is my lose by doing so? beside the fact the i need<br>> to manage this at the encoder and the decoder side?<br>><br><br>This question is not really related to x264 development but ...
<br>By splitting the frame into slices yourself (and not letting the<br>encoder do it) you have this problem: you do not know what size each manually<br>created slice will be. Since loss on the network happens based on MTU size
<br>(i.e. you normally lose one whole MTU), ideally you want one slice<br>to be coded into an MTU, so that if it is lost, you lose only one slice.<br>But if you arbitrarily split your frame into N slices, then (a) one slice
<br>may be much smaller than MTU (so you are being wasteful) or (b) one slice is<br>much bigger than MTU (so it will be split into multiple MTUs and if one<br>of these is lost, you lose the whole slice). That is the cost of your
<br>suggestion (although it has its own advantages).<br><br>Mojtaba Hosseini<br><br>_______________________________________________<br>x264-devel mailing list<br><a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org
</a><br><a href="http://mailman.videolan.org/listinfo/x264-devel">http://mailman.videolan.org/listinfo/x264-devel</a><br></blockquote></div><br></div>