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

[Simon Morlat]

Le dimanche 5 juillet 2009 01:43:02, Marc Schulz a écrit :
> If you want the feature then write a patch that will conform to the high
> standards of x264.
Is there any document explaining the "high standarts of x264" ?

> Then once they are ready to add this feature it will be
> added.
Ok, in two years, when the patch no more applies....

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

Other people before me contributed similar patches (with even more features) 
and they haven't been merged. It seems that there will always have good reason 
to reject a patch.
I don't like forks because it does not make the world simple. I would have 
prefered this small 10-lines-added patch to be integrated.
We are writting more lines in this mailing list than the patch itself 
contains...
x264 is a great project. The code is very well written, works very well, very 
stable and runs very fast. Achieving this, for my standpoint, is not 
incompatible with managing the project in a bit more opened way.

Simon



> 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