[x264-devel] NAL slice support patch added?

[Mojtaba Hosseini]

On Thu, 2007-10-25 at 15:00 +0200, Michael Roitzsch wrote:

> I came across this problem with an earlier revision of x264, because  
> I needed encoding with arbitrary slice boundaries for a research  
> project. I provided patch back then that fixed all the anomalies for  
> me. I don't know if it still works with today's x264 or if it even  
> applies, but maybe it will help you.
> 
> The problem is basically that x264's check for the available spatial  
> prediction modes assumes full-row slices. It checks for availability  
> of the topleft macroblock, while it should actually check for the top  
> and the left macroblock. If slices always start in column 0, this is  
> equivalent (top and left are there iff topleft is there), but for  
> arbitrary boundaries, this does not hold.
> 

Hello,
  Thanks Michael for the patch. With your patch (except the 'reset mv
bounds' part in slicetype.c which i wasn't sure about), it now works
fine. I have tested it (using method suggested by Loren) with one and
more threads for both slice threshold = 0 (1frame=1NAL for backward
compatibility) and other values and it seems to work. Questions:
1) what else do I need to test to raise confidence in patch?
2) I'm still not sure about compute/print stats in frame_end() 
function of encoder.c (these 2 lines):
    h->stat.i_slice_count[h->sh.i_type]++;
    h->stat.i_slice_size[h->sh.i_type] += h->out.i_frame_size + 
                                          NALU_OVERHEAD;
This doesn't seem right. Should I be changing this to be updated for
all slices in a frame? If so, I can move them to slice_write() 
 function of encoder.c.
3) The point has been raised that the slice threshold isn't really
respected as a maximum. That is, if slice threshold is set to X, then
there is no guarantee that the slice size will be close to X. I believe
this is ok because that is how ffmpeg's h263+ and mpeg4 encoders work.
Plus, the main use of the slice threshold feature is for transmission
over lossy networks. In that case, it is up to the application to 
set slice threshold to something well below their MTU. For typical
MTU of 1500 bytes, slice threshold of 1300 seems to work fine. 

Thank you for all your feedback and help. 

Mojtaba Hosseini
   
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MultipleNALInFramePatch_2.txt
Type: text/x-patch
Size: 10538 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20071025/fb560138/attachment.bin