[x264-devel] [patch] control of maximum nalu size (multi-sclicing)

[Marc Schulz]

If you want the feature then write a patch that will conform to the high
standards of x264. Then once they are ready to add this feature it will be
added. There is absolutely no point in being a child about this. Besides as
you stated you already maintain a fork, so this should work for people who
absolutely need this feature at the moment.
Marc



On Sat, Jul 4, 2009 at 4:16 PM, Simon Morlat <simon.morlat at linphone.org>wrote:

> Hello,
>
> > Why not?  If I committed a slicing patch, it would be a *good* slicing
> > patch, and it would allow both number-of-MBs per slice,
> > number-of-slices-per-frame, and a maximum NALU size as well.
> Sorry for this patch to be not so good.
> In the meantime, what do you have for years in x264 to control the nalu
> size ?
> Nothing.
>
> At this time x264 is lacking this important feature, missing the market of
> real-time communications...
> Look at other proprietary solutions:
> Polycom they have it.
> e-Conf they have it.
> Mirial they have it.
> bria, they have it.
> Even the intel ipp H264 encoder has options to control (at least) the
> number
> of slices used to encode a picture.
> What about ekiga, linphone ? no they don't. And what conclude people that
> make
> tests between the proprietary ones and the open source ones ? That they
> don't
> interoperate because the open-source ones don't implement the first and
> simplest mode described in RFC3984. This is not good for the image of open
> source.
>
> It does not matter to me if my patch gets reworked ten times in the future,
> or
> if you prefer merge and rework the one that was submitted last year because
> it
> is better, provided that the feature exists.
>
> Until you decide to do something for this, I will be forced to maintain a
> x264
> fork. Fortunately it's quite easy with git.
>
> Regards,
>
> Simon
>
>
> >
> > > As for the validity of the reason for rejecting the patch, invoking
> what
> > > happens in another project doesn't look like a valid reason to me. You
> > > have every right to refuse a patch, but if you invoke a reason, make it
> > > at least a good one.
> >
> > ffmpeg is the most popular decoder used for x264 streams, so it only
> > makes sense to make judgements based on what happens in that project.
> >
> > There is one solution though: we could turn on the bit that enables
> > deblocking between slices, which would break parallelized decoding.
> >
> > Dark Shikari
> > _______________________________________________
> > x264-devel mailing list
> > x264-devel at videolan.org
> > http://mailman.videolan.org/listinfo/x264-devel
>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20090704/88c1ff75/attachment-0001.htm>