[x264-devel] Multislicing support

[List, Peter]

Dear Etienne,
Thank you very much for taking this task! I believe this was an important effort for x264! (Even more so, if you will manage to split a frame into slices of specific byte sizes).

Just one comment to your "--no-mv-inter-slices" option. 
To my knowledge the H.264 standard says, that inter-slice prediction is forbidden in ALL CASES! To my understanding it is the very meaning of slices to...

> allowing one slice to be completely removed without causing any harm to 
> the decompression of the remaining ones.

...as you said below. There is no other reason for having slices at all. 
Most of all, that would mean, if one would turn this option off, the resulting bitstream would NOT BE H.264 complient!
 
Probably I missed something! Please explain.

Best regards
Peter


> -----Ursprüngliche Nachricht-----
> Von: Etienne Bömcke [mailto:etienne.bomcke at uclouvain.be]
> Gesendet: Montag, 18. Februar 2008 15:11
> An: Mailing list for x264 developers
> Betreff: Re: [x264-devel] Multislicing support
> 
> Ok, so here's the patch I created to add support for multiple slices
> in one frame. I use the following two command-line options : --mb-
> slicesize and --no-mv-inter-slices. The first option allows one to
> specify the desired slice size in number of macroblocks, while the
> latter forbids any inter-slice prediction, allowing one slice to be
> completely removed without causing any harm to the decompression of
> the remaining ones. I tested it the way Lorren described in his e-
> mail. Comparing x264's fdec.yuv file and the output of the standard
> decoder (actual version, 13.2 I think) using the 'diff' utility gives
> a blank result, which means that both files are identical.
> However, I haven't been able to test Mojtaba's part, ie the splitting
> of frames in multiple NALs when specifying a maximum NAL size in
> bytes. If anybody could take a look and tell me if it seems clean, I'd
> appreciate it.
> 
> One last thing : You'll notice that I changed the macroblock scanning
> condition in file encoder.c . Seems to me that the last macroblock of
> the slice (stored in sh->i_last_mb) should be the last macroblock
> contained in the slice, and not the first one just outside. I checked
> for further reference to that variable, but it seems like it's not
> used a lot, so this modification didn't break anything.
> 
> Etienne
>