<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi,</div><div><br></div><div>I was wondering why I didn't get any feedback to my last mails on this subject, but after a small investigation I found out that due to a human error (hem) I was sending these mails to myself instead of the x264 mailing list.</div><div>So, here are the recent news I'd like to share with you :</div><div><br></div><div>- Further tests show little or no variation in the encoding speed when encoding in one slice using the patched code vs. unpatched code. I got lost in the different versions of x264 I have on my computer, so yesterday I did a clean install <i>et voilà</i>! No more deperdition in the encoding speed.</div><div><br></div><div>- When encoding with more than 4 slices, output stream is not decoded correctly neither by JM 13.2 nor by VLC.<br><br>- Usage of the -q option when encoding with more than 4 slices result in a memory error.<br></div><div><br></div><div>I found the bug causing the strange behaviour described in these last two items, and the responsible is the function <i>x264_realloc</i>. I remember someone telling me the function was buggy, but I thought it had been corrected since then. I'm afraid I can't help with that, as I barely understand how the function works. There is just one thing I'd like to know : how come the function doesn't call <i>realloc</i>, as the file malloc.h is obviously present on my computer? Isn't the variable HAVE_MALLOC_H defined on any system having the malloc helper file? This is more a basic C question, but if anybody has an answer it would help me having an even greater week-end. :-)</div><div><br></div><div>In conclusion, the patch seems okay in my opinion considering the facts that it doesn't reduce the encoding speed and that the output streams are H.264 compliants. However, as long as the function x264_realloc stays buggy, theres this problem described in the last two items, and I suppose that just replacing the bug-creating x264_realloc call by realloc isn't a solution...</div><div><br></div><div>Best regards,</div><div><br></div><div>Etienne</div><div><br></div><br><div><div>On 24 Apr 2008, at 10:33, List, Peter wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hallo Etienne,<br>see my comments below:<br><br><br><blockquote type="cite">-----Ursprüngliche Nachricht-----<br></blockquote><blockquote type="cite">Von: x264-devel-bounces@videolan.org [<a href="mailto:x264-devel-">mailto:x264-devel-</a><br></blockquote><blockquote type="cite"><a href="mailto:bounces@videolan.org">bounces@videolan.org</a>] Im Auftrag von Etienne Bömcke<br></blockquote><blockquote type="cite">Gesendet: Mittwoch, 23. April 2008 18:07<br></blockquote><blockquote type="cite">An: Mailing list for x264 developers<br></blockquote><blockquote type="cite">Betreff: Re: [x264-devel] Multislicing support<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Ok, I just finished a batch of tests, and here are my conclusions :<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">1. Comparison of x264's fdec.yuv and JM output show no difference,<br></blockquote><blockquote type="cite">regardless of the size of the sequence and the parameters used (both --<br></blockquote><blockquote type="cite">mb-slicesize and --max-slicesize).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">2. When forcing a large number of slice ( more than 4 showed my<br></blockquote><blockquote type="cite">tests ), the decoder isn't able to perform. It fails with the message<br></blockquote><blockquote type="cite">"free_mem2Dpel: trying to free unused memory", which leads me to<br></blockquote><blockquote type="cite">believe that the error is in the decoder code. <br></blockquote><br>When you say "the decoder" what decoder do you mean? Ffmpeg?<br>Anyways, if it seems useful for you, you can send me a *.264 file with<br>slices, that does not run correctly. I can feed it to my own decoder and<br>tell you very quickly (I hope) what's wrong with it. <br><br><blockquote type="cite">I suppose the program<br></blockquote><blockquote type="cite">cannot handle the decoding of many slices, as x264 behaves perfectly<br></blockquote><blockquote type="cite">well during the encoding.<br></blockquote><blockquote type="cite">I just tried reading an output stream with more than 4 slices with<br></blockquote><blockquote type="cite">VLC, and although the stream is read without VLC giving an error, the<br></blockquote><blockquote type="cite">image appears only in the last seconds. I'll have to investigate this<br></blockquote><blockquote type="cite">problem further and check if the error lies in the patched code.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">3. Encoding speed is reduced by up to 10% when using the patched code<br></blockquote><blockquote type="cite">to encode in one slice.<br></blockquote><br>That is very surprising! Something MUST be broken! (with multithreading?)<br><br><blockquote type="cite">4. Output stream bitrate increases significantly regardless of which<br></blockquote><blockquote type="cite">bitrate control method is used (fixed Q or target bitrate).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The last two observations indicate that there's something messing the<br></blockquote><blockquote type="cite">rate control in the patch. I did more tests with the patch only<br></blockquote><blockquote type="cite">partially applied, and I think the problem comes from the modification<br></blockquote><blockquote type="cite">of the stats computation. I did not write this code myself, it was<br></blockquote><blockquote type="cite">Mojtaba who did. Mojtaba, could you give it a look and check if<br></blockquote><blockquote type="cite">there's no mistake in the stats computation?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I'll try to resolve the problem of the many slices, if I manage<br></blockquote><blockquote type="cite">interesting results I'll let you know.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thank you all for your feedback,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Etienne<br></blockquote><blockquote type="cite"><br></blockquote><br>_______________________________________________<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>