[x264-devel] Multislicing support

[List, Peter]

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
>