[x264-devel] Multislicing support

[Etienne Bömcke]

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 mean the reference decoder software, JM version 13.2. I attached two  
files, one in high def and another in low def, both encoded with 5  
slices. Attempting to decode these two files with the reference  
software result in the error mentioned above, and VLC cannot read them  
correctly neither.

>
>
>> 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?)

I noticed something else that I didn't mention in my last mail. When  
encoding with a fixed quantization step, the average Qp given by x264  
differs (5 - 8 for I- and P-slices when using the patch, 9.10 - 10.44  
whith the git version).
Furthermore, encoding with more than 4 slices while using the -q  
option fails with the following error message :

x264lr(288) malloc: *** mmap(size=3829432320) failed (error code=12)

There's obviously something messing up the rate control, but I can't  
figure out exactly what part of the patch is reponsible for that. The  
only part of the code I think could affect this would be the  
statistics computation, could anyone with a better knowledge of the  
rate control related code confirm?


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: hd_5slices.264
Type: application/octet-stream
Size: 2497632 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20080424/476628d7/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ld_5slices.264
Type: application/octet-stream
Size: 464438 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20080424/476628d7/attachment-0003.obj 
-------------- next part --------------

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