[x264-devel] Multislicing support

[Etienne Bömcke]

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.

I modified my code the following way :

- The slice header array is now defined this way :  
'x264_slice_header_t *shs;'.
- At run time, once the slice number has been determined from the  
frame size and the slice size in macroblock, memory is allocated to  
the slice header array using x264_malloc : 'h->shs =  
x264_malloc(sizeof(x264_slice_header_t) * param->i_slices_number);'.
- Right before the closing of the encoder, the buffer h->shs is freed  
using x264_free.

As the size of this array isn't supposed to change during the whole  
encoding process, I don't think I have to provide a way to grow it  
dynamically. Is this a clean way to proceed? Another question : Should  
I create/free the shs buffer each time a frame is encoded, or is it  
better to do this one time only (after x264_encoder_open and before  
x264_encoder_close)? I don't have sufficient knowledge of the C  
language to answer this question.

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

My mistake, I didn't read your patch thoroughly, and it seems we could  
merge them afterall. The thing is, I need to add an option preventing  
a slice to be predicted from another one, even in the temporal domain.  
The ultimate goal is to be able to completely replace one slice of the  
sequence by a different sequence, encoded with the same options and  
GOP format than the original one. I'll work on the merging of the two  
patches starting tomorrow. If I succeed, will you give me a hand for  
the testing ? I'd really like to see this functionnality eventually  
added to the official code.

Thanks again,

Etienne

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20080213/8fac7cf3/attachment.htm 
-------------- next part --------------
_______________________________________________
x264-devel mailing list
x264-devel at videolan.org
http://mailman.videolan.org/listinfo/x264-devel