<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 12 Feb 2008, at 18:13, Mojtaba Hosseini wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><blockquote type="cite">I finally had some time to look at your patch, but it seems that the <br></blockquote><blockquote type="cite">archives of last year's mails has been erased and is not accessible <br></blockquote><blockquote type="cite">anymore. Could you please forward me Lorren's mail you mentioned in <br></blockquote><blockquote type="cite">the following mail? I also wanted to ask you some pointers about how <br></blockquote><blockquote type="cite">to make the slice headers array a dynamically growing array, instead <br></blockquote><blockquote type="cite">of a hard-coded 8 elements array as it is now.<br></blockquote><br>Loren's original email from gmane:<br><br><a href="http://article.gmane.org/gmane.comp.video.x264.devel/3167">http://article.gmane.org/gmane.comp.video.x264.devel/3167</a><br><br>The patch I emailed does dynamically growing array of NALs so if you<br>have a look here:<br><br>http://article.gmane.org/gmane.comp.video.x264.devel/3183<br><br>you'll see that you can use realloc to keep growing the number of NALs. </blockquote><div><br class="webkit-block-placeholder"></div>I modified my code the following way :</div><div><br class="webkit-block-placeholder"></div><div>- The slice header array is now defined this way : '<span class="Apple-style-span" style="color: rgb(63, 110, 116); font-family: Monaco; font-size: 10px; ">x264_slice_header_t<span style="color: #000000"> *shs;'<span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; ">.</span></span></span></div><div>- At run time, once the slice number has been determined from the frame size and the slice size in macroblock, memory is allocated to the slice header array using x264_malloc : '<span class="Apple-style-span" style="color: rgb(63, 110, 116); font-family: Monaco; font-size: 10px; "><span style="color: #000000">h-></span>shs<span style="color: #000000"> = </span><span style="color: #26474b">x264_malloc</span><span style="color: #000000">(</span><span style="color: #aa0d91">sizeof</span><span style="color: #000000">(</span>x264_slice_header_t<span style="color: #000000">) * param-></span>i_slices_number<span style="color: #000000">);<span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; ">'.</span></span></span></div><div>- Right before the closing of the encoder, the buffer h->shs is freed using x264_free.</div><div><br class="webkit-block-placeholder"></div><div>As the size of this array isn't supposed to change during the whole encoding process, I don't think I have to provide a way to grow it dynamically. Is this a clean way to proceed? Another question : Should I create/free the shs buffer each time a frame is encoded, or is it better to do this one time only (after x264_encoder_open and before x264_encoder_close)? I don't have sufficient knowledge of the C language to answer this question.</div><div><br><blockquote type="cite"><br><br><blockquote type="cite">Furthermore, I'm afraid I won't be able to merge our two patches, as <br></blockquote><blockquote type="cite">they don't really do the same thing. My patch breaks a frame in <br></blockquote><blockquote type="cite">multiple slices, forbidding both spatial and temporal prediction <br></blockquote><blockquote type="cite">between different slices. If I followed your method, I wouldn't have <br></blockquote><blockquote type="cite">any access to the prediction constraints.<br></blockquote><br>If I'm not mistaken, once a slice is created, then other slices should NOT<br>predict from it. This is already taken care of in x264 (someone correct me<br>if I'm wrong). So the main difference between the two patches is the<br>criteria for starting a new slice: 1) slice size in bytes exceeding a threshold<br>versus 2) mbs in a slice exceeding a given number. I would expect the common code<br>to be plenty. </blockquote><div><br class="webkit-block-placeholder"></div><div>My mistake, I didn't read your patch thoroughly, and it seems we could merge them afterall. The thing is, I need to add an option preventing a slice to be predicted from another one, even in the temporal domain. The ultimate goal is to be able to completely replace one slice of the sequence by a different sequence, encoded with the same options and GOP format than the original one. I'll work on the merging of the two patches starting tomorrow. If I succeed, will you give me a hand for the testing ? I'd really like to see this functionnality eventually added to the official code.</div><div><br class="webkit-block-placeholder"></div><div>Thanks again,</div><div><br class="webkit-block-placeholder"></div><div>Etienne</div><br><blockquote type="cite"><br><br>Mojtaba<br><span><winmail.dat></span>_______________________________________________<br>x264-devel mailing list<br><a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br>http://mailman.videolan.org/listinfo/x264-devel<br></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Etienne Bömcke</div><div>UCL - Laboratoire TELE</div><div><a href="mailto:etienne.bomcke@uclouvain.be">etienne.bomcke@uclouvain.be</a></div><div><br></div></div></span><br class="Apple-interchange-newline"> </div><br></body></html>