[x264-devel] Multislicing support

[List, Peter]

Dear Etienne,
sorry for bothering you. It seems I was a little confused. 
Inter-slice (pixel) prediction is actually NOT forbidden.

Regards
Peter



> -----Ursprüngliche Nachricht-----
> Von: x264-devel-bounces at videolan.org [mailto:x264-devel-
> bounces at videolan.org] Im Auftrag von Etienne Bömcke
> Gesendet: Dienstag, 19. Februar 2008 11:37
> An: Mailing list for x264 developers
> Betreff: Re: [x264-devel] {Spam?} Re: Multislicing support
> 
> It seems like I wasn't as clear as I thought. Correct me if I'm wrong,
> but I think that the H.264 standard only forbids inter-slices
> prediction inside of one frame. Removing a slice of one frame ony
> shouldn't cause any harm to the decoding process of the rest of the
> frame.
> The option I added (no-mv-inter-frames, complicated name but it was
> the best I could come up with. If anybody has a better idea, I'm open
> for suggestions) allows one to encode a sequence in two or more
> completely independant slices. That means that you could remove a
> given slice from the whole sequence while the remaining slices could
> still be decoded.
> Basically I modified the motion estimation related code and restrained
> the search range so that a macroblock of a given slice can only be
> predicted from a macroblock in the same slice, even when predicting
> from previous frames.
> As I said in one of my first e-mails, the objective for this task is
> to be able to replace a part of an H.264 sequence by a whole different
> sequence directly in the bitstream. This restriction allows one to do
> that without any decompression error cause by the slice replacement.
> 
> I hope I'm clear enough this time, if not do not hesitate to ask me
> further explanations.
> 
> Regards,
> 
> Etienne
> 
> PS : Thanks for your comments, I really appreciate it.
> 
> 
> 
> 
> On 19 Feb 2008, at 10:05, List, Peter wrote:
> 
> >
> > 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
> >>
> >
> > _______________________________________________
> > 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