<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>There have been problems with my mail client, some of the mails I sent did not got through to the mailing list, resulting in a more than confused situation...</div><div>The patch doesn't break rate-control, I did a few tests with clean versions of patched and unpatched code and everything went fine.</div><div>As for the memory crash, I'm pretty sure it occurs when x264_realloc function uses its own code instead of just calling realloc. On my system, it doesn't detect that I have the malloc.h helper file, so it tries to execute it's own implementation of realloc which is causing the crash.</div><div>So, the question is : do I have to define HAVE_MALLOC_H myself in x264's code in order for x264_realloc to call realloc? If yes, then everything's fine as the patched code should run flawlessly under any system having malloc.h, which I believe is available on any modern system, but again I'm guessing here so if I'm wrong feel free to correct me.</div><div><br></div><div>Regards,</div><div><br></div><div>Etienne</div><div><br></div><div><br></div><br><div><div>On 29 Apr 2008, at 17:47, Mojtaba Hosseini wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div> <font size="4"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br> >On 25/04/08 9:58 AM, "Etienne Bömcke" <<a href="mailto:etienne.bomcke@uclouvain.be">etienne.bomcke@uclouvain.be</a>> wrote:<br> >Hi,<br> >I was wondering why I didn't get any feedback to my last mails on this subject, but after a small<br> > investigation I found out that due to a human error (hem) I was sending these mails to myself <br> > instead of the x264 mailing list.<br> <br> Etienne, I tested your patch as follows: I started with a predetermined YUV sequence of 1920x1080 YUV<br> Images. I encoded this sequence with clean (non-patched) version of x264 with 1,4,6 threads. I did the<br> Test with ABR of 2Mbps and another time with CQP=25 and stored the resulting binary stream(TEST1). <br> Then I applied your patch and redid the test but with no slice size threshold or slice mb threshold (TEST2)<br> Then I redid the test with size threshold of 1300 (TEST3)<br> Then I redid the test with mb threshold of 120 (68 slices per frame) (TEST4)<br> The binaries between TEST1 and TEST2 are the same size => the patch does not break anything if disabled<br> The binaries from TEST3 and TEST4 are slightly (<2%) greater in size than those in TEST1. This is expected <br> Because each slice needs headers => more bits<br> I did NOT see the memory crash you mentioned with and without –qp option (or CQP). <br> All binary streams were playable with no error using ffmpeg h264 decoder. <br> So the patch seems fine and I don’t understand why you are observing problems. You’ll have to provide<br> More detail on why you think:<br> (a) patch affects rate control<br> (b) patch breaks with –qp option <br> <br> Mojtaba Hosseini</span></font></font> </div> _______________________________________________<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>