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.<div>
<br></div><div>Marc<br><div><br></div><div><br><br><div class="gmail_quote">On Sat, Jul 4, 2009 at 4:16 PM, Simon Morlat <span dir="ltr"><<a href="mailto:simon.morlat@linphone.org">simon.morlat@linphone.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello,<br>
<div class="im"><br>
> Why not? If I committed a slicing patch, it would be a *good* slicing<br>
> patch, and it would allow both number-of-MBs per slice,<br>
> number-of-slices-per-frame, and a maximum NALU size as well.<br>
</div>Sorry for this patch to be not so good.<br>
In the meantime, what do you have for years in x264 to control the nalu size ?<br>
Nothing.<br>
<br>
At this time x264 is lacking this important feature, missing the market of<br>
real-time communications...<br>
Look at other proprietary solutions:<br>
Polycom they have it.<br>
e-Conf they have it.<br>
Mirial they have it.<br>
bria, they have it.<br>
Even the intel ipp H264 encoder has options to control (at least) the number<br>
of slices used to encode a picture.<br>
What about ekiga, linphone ? no they don't. And what conclude people that make<br>
tests between the proprietary ones and the open source ones ? That they don't<br>
interoperate because the open-source ones don't implement the first and<br>
simplest mode described in RFC3984. This is not good for the image of open<br>
source.<br>
<br>
It does not matter to me if my patch gets reworked ten times in the future, or<br>
if you prefer merge and rework the one that was submitted last year because it<br>
is better, provided that the feature exists.<br>
<br>
Until you decide to do something for this, I will be forced to maintain a x264<br>
fork. Fortunately it's quite easy with git.<br>
<br>
Regards,<br>
<font color="#888888"><br>
Simon<br>
</font><div><div></div><div class="h5"><br>
<br>
><br>
> > As for the validity of the reason for rejecting the patch, invoking what<br>
> > happens in another project doesn't look like a valid reason to me. You<br>
> > have every right to refuse a patch, but if you invoke a reason, make it<br>
> > at least a good one.<br>
><br>
> ffmpeg is the most popular decoder used for x264 streams, so it only<br>
> makes sense to make judgements based on what happens in that project.<br>
><br>
> There is one solution though: we could turn on the bit that enables<br>
> deblocking between slices, which would break parallelized decoding.<br>
><br>
> Dark Shikari<br>
> _______________________________________________<br>
> x264-devel mailing list<br>
> <a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br>
> <a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
<br>
_______________________________________________<br>
x264-devel mailing list<br>
<a href="mailto:x264-devel@videolan.org">x264-devel@videolan.org</a><br>
<a href="http://mailman.videolan.org/listinfo/x264-devel" target="_blank">http://mailman.videolan.org/listinfo/x264-devel</a><br>
</div></div></blockquote></div><br></div></div>