[x264-devel] Multislicing support

[Etienne Bömcke]

I ran a few tests to check where this bug was located, and here's what  
I got. When using the function realloc instead of x264_realloc,  
everything's fine. The function x264_realloc should normally return  
the result of realloc as it is available on my system, but the flag  
HAVE_MALLOC_H doesn't seem to be defined anywhere. It then tries do  
reallocate memory using a temporary pointer and a memcpy call, but as  
I reported earlier this looses all data in the nal array.
Anybody has an idea how this bug should be corrected?

Etienne

On 20 Feb 2008, at 13:53, Etienne Bömcke wrote:

> There seems to be a bug in your code. Each time x264_realloc is used
> to grow the number of nals, the payload value of every nal is lost,
> which leads eventually to a crash. I don't know really well the memcpy
> function so I wasn't capable of resolving it myself. Could you please
> take a look at it?
>
> Etiene
>
>
> On 12 Feb 2008, at 18:13, Mojtaba Hosseini wrote:
>
>>
>>> I finally had some time to look at your patch, but it seems that the
>>> archives of last year's mails has been erased and is not accessible
>>> anymore. Could you please forward me Lorren's mail you mentioned in
>>> the following mail? I also wanted to ask you some pointers about how
>>> to make the slice headers array a dynamically growing array, instead
>>> of a hard-coded 8 elements array as it is now.
>>
>> Loren's original email from gmane:
>>
>> http://article.gmane.org/gmane.comp.video.x264.devel/3167
>>
>> The patch I emailed does dynamically growing array of NALs so if you
>> have a look here:
>>
>> http://article.gmane.org/gmane.comp.video.x264.devel/3183
>>
>> you'll see that you can use realloc to keep growing the number of
>> NALs.
>>
>>> Furthermore, I'm afraid I won't be able to merge our two patches, as
>>> they don't really do the same thing. My patch breaks a frame in
>>> multiple slices, forbidding both spatial and temporal prediction
>>> between different slices. If I followed your method, I wouldn't have
>>> any access to the prediction constraints.
>>
>> If I'm not mistaken, once a slice is created, then other slices
>> should NOT
>> predict from it. This is already taken care of in x264 (someone
>> correct me
>> if I'm wrong). So the main difference between the two patches is the
>> criteria for starting a new slice: 1) slice size in bytes exceeding
>> a threshold
>> versus 2) mbs in a slice exceeding a given number. I would expect
>> the common code
>> to be plenty.
>>
>> Mojtaba
>> <winmail.dat>_______________________________________________
>> 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
>
>
>
> _______________________________________________
> 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