<div dir="rtl"><div>I have the same problem. I need to slice the picture before streaming.</div>
<div>what is the lose if i slice the picture some way before encding and run x instances of the decoder on each slice?<br><br> </div>
<div><span class="gmail_quote">2007/11/16, List, Peter <<a href="mailto:Peter.List@t-systems.com">Peter.List@t-systems.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">Dear Mojtaba,<br>Thank you for you detailed explanation.<br>Regards
<br>Peter<br><br><br><br>> > I'm sorry; it seems I don't really get it...<br>> > How do you guarantee that "prediction between slices is not done"<br>> > (Mojtaba) when "Current x264 doesn't support slices at all" (Loren)
<br>> ><br>><br>> Hello Peter,<br>> I believe Loren means that the current x264 that you can get from<br>> svn right now puts one frame into one NAL. It does NOT split it into<br>> multiple slices.<br>
> Now how does the patch (which is not in svn) guarantee no prediction<br>> from MB outside of slice? Take a look at x264_macroblock_cache_load()<br>> method in /common/macroblock.c. This function is called for each MB
<br>> (from x264_slice_write() of encoder.c) and it sets the MB's<br>i_neighbour<br>> variable. It does so by taking into account the slice's first mb<br>> variable. So the top MB is not available if its index is less than
<br>> that slice's first MB. Same for left, top left, etc. So the patch in<br>of<br>> itself does not guarantee that prediction is not done from outside of<br>> the slice BUT that is because the x264 encoder code as is provides
<br>that<br>> guarantee.<br>><br>> > How is this patch working...<br>> > The process starts with x264 producing macroblocks until one packet<br>is<br>> > full, right? Than your patch produces a slice header and completes
<br>one<br>> > NALU.<br>> > If x264 then continues, how does it know that it needs to produce a<br>new<br>> > slice? Does the x264code still have all the necessary variables and<br>> > methods to obey the H264 slice restrictions, so that your patch can
<br>> > feedback the fact, that a new slice is to be coded into the original<br>> > x264 code?<br>> I don't understand exactly what you are asking. The patch lets x264<br>> encode until the bitsteam size exceeds a given value (note that this
<br>> does NOT provide any guarantee on maximum size), then it ends this<br>> slice and sets up all the variables for a new slice to begin. If you<br>> look at the patch, this part is fairly straight forward.<br>
><br>> > If that is true what else could we want?? Why is Loren saying then:<br>> ><br>> > >> Current x264 doesn't support slices at all. It will support<br>> > horizontal<br>> > >> slices when I get around to merging that patch.
<br>> ><br>> I believe Loren means that the current x264 code resident in the svn<br>> does not support slices until he merges the patch I have been<br>referring<br>> to into the svn code. There is nothing in x264 that inherently
<br>prevents<br>> support for multiple slice per frame feature.<br>><br>> ><br>> > If that is true, we have no problem, because slice headers (at least<br>> > H264-slice headers) DO HAVE all the information in them we need.
<br>> ><br>> Right. As long as frame level things like width and height don't<br>change<br>> and you don't lose an SPS and PPS (which are NALs) containing that<br>> change in transmission, decoder DOES have all the information to
<br>decode<br>> an independent NAL. Even if previous NALs were lost.<br>><br>> > To me that only makes sense if a NALU is equivalent to a slice in<br>the<br>> > H264-definition (or multiple complete slices, or parts of slices,
<br>that<br>> > become complete with multiple complete NALU's).<br>> > Is that the case???<br>> I believe so. Each NAL represents a slice in a frame according to<br>> H264-definition.<br>><br>> Mojtaba
<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>_______________________________________________<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>