<HTML>
<HEAD>
<TITLE>Re: [x264-devel] Multislicing support</TITLE>
</HEAD>
<BODY>
<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" <etienne.bomcke@uclouvain.be> 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>
</BODY>
</HTML>