[x264-devel] Multislicing support

[Etienne Bömcke]

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...
The patch doesn't break rate-control, I did a few tests with clean  
versions of patched and unpatched code and everything went fine.
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.
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.

Regards,

Etienne



On 29 Apr 2008, at 17:47, Mojtaba Hosseini wrote:

>
> >On 25/04/08 9:58 AM, "Etienne Bömcke" <etienne.bomcke at uclouvain.be>  
> wrote:
> >Hi,
> >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.
>
> Etienne, I tested your patch as follows: I started with a  
> predetermined YUV sequence of 1920x1080 YUV
> Images. I encoded this sequence with clean (non-patched) version of  
> x264 with 1,4,6 threads. I did the
> Test with ABR of 2Mbps and another time with CQP=25 and stored the  
> resulting binary stream(TEST1).
> Then I applied your patch and redid the test but with no slice size  
> threshold or slice mb threshold (TEST2)
> Then I redid the test with size threshold of 1300 (TEST3)
> Then I redid the test with mb threshold of 120 (68 slices per frame)  
> (TEST4)
> The binaries between TEST1 and TEST2 are the same size => the patch  
> does not break anything if disabled
> The binaries from TEST3 and TEST4 are slightly (<2%) greater in size  
> than those in TEST1. This is expected
> Because each slice needs headers => more bits
> I did NOT see the memory crash you mentioned with and without –qp  
> option (or CQP).
> All binary streams were playable with no error using ffmpeg h264  
> decoder.
> So the patch seems fine and I don’t understand why you are observing  
> problems. You’ll have to provide
> More detail on why you think:
> (a) patch affects rate control
> (b) patch breaks with –qp option
>
> Mojtaba Hosseini
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel

--
Etienne Bömcke
UCL - Laboratoire TELE
etienne.bomcke at uclouvain.be



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20080429/22351a32/attachment.htm