[x264-devel] Multislicing support

[Etienne Bömcke]

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.
So, here are the recent news I'd like to share with you :

- 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 et voilà! No more deperdition in the  
encoding speed.

- When encoding with more than 4 slices, output stream is not decoded  
correctly neither by JM 13.2 nor by VLC.

- Usage of the -q option when encoding with more than 4 slices result  
in a memory error.

I found the bug causing the strange behaviour described in these last  
two items, and the responsible is the function x264_realloc. 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 realloc, 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. :-)

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...

Best regards,

Etienne


On 24 Apr 2008, at 10:33, List, Peter wrote:

> Hallo Etienne,
> see my comments below:
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: x264-devel-bounces at videolan.org [mailto:x264-devel-
>> bounces at videolan.org] Im Auftrag von Etienne Bömcke
>> Gesendet: Mittwoch, 23. April 2008 18:07
>> An: Mailing list for x264 developers
>> Betreff: Re: [x264-devel] Multislicing support
>>
>> Ok, I just finished a batch of tests, and here are my conclusions :
>>
>> 1. Comparison of x264's fdec.yuv and JM output show no difference,
>> regardless of the size of the sequence and the parameters used  
>> (both --
>> mb-slicesize and --max-slicesize).
>>
>> 2. When forcing a large number of slice ( more than 4 showed my
>> tests ), the decoder isn't able to perform. It fails with the message
>> "free_mem2Dpel: trying to free unused memory", which leads me to
>> believe that the error is in the decoder code.
>
> When you say "the decoder" what decoder do you mean? Ffmpeg?
> Anyways, if it seems useful for you, you can send me a *.264 file with
> slices, that does not run correctly. I can feed it to my own decoder  
> and
> tell you very quickly (I hope) what's wrong with it.
>
>> I suppose the program
>> cannot handle the decoding of many slices, as x264 behaves perfectly
>> well during the encoding.
>> I just tried reading an output stream with more than 4 slices with
>> VLC, and although the stream is read without VLC giving an error, the
>> image appears only in the last seconds. I'll have to investigate this
>> problem further and check if the error lies in the patched code.
>>
>> 3. Encoding speed is reduced by up to 10% when using the patched code
>> to encode in one slice.
>
> That is very surprising! Something MUST be broken! (with  
> multithreading?)
>
>> 4. Output stream bitrate increases significantly regardless of which
>> bitrate control method is used (fixed Q or target bitrate).
>>
>> The last two observations indicate that there's something messing the
>> rate control in the patch. I did more tests with the patch only
>> partially applied, and I think the problem comes from the  
>> modification
>> of the stats computation. I did not write this code myself, it was
>> Mojtaba who did. Mojtaba, could you give it a look and check if
>> there's no mistake in the stats computation?
>>
>> I'll try to resolve the problem of the many slices, if I manage
>> interesting results I'll let you know.
>>
>> Thank you all for your feedback,
>>
>> Etienne
>>
>
> _______________________________________________
> 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/20080425/6326bc31/attachment.htm