On Thu, 26 Apr 2018 13:39:56 +0200 Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 2018-04-26 13:34 GMT+02:00, Paul B Mahol <one...@gmail.com>: > > On 4/26/18, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > >> 2018-04-26 13:17 GMT+02:00, Josh de Kock <j...@itanimul.li>: > >>> On 2017/06/26 15:09, Paul B Mahol wrote: > >>>> Rationale: > >>>> - Slower then other encoder > >>>> - Less configurable > >>>> - Does not support alpha profile > >>>> - Does not set interlaced flag > >>>> - Worse output quality > >>>> - No need for 2 encoders > >>>> > >>>> Signed-off-by: Paul B Mahol <one...@gmail.com> > >>>> > >>> Is there any reason this was not pushed? > >>> I can't seem to see any argument against it. > >> > >> It was shown in the past that this encoder is faster, > >> more efficient and produces better quality. > > > > Why are you not telling real truth? > > This is surprisingly rude: > I am always trying to tell the truth, one of the things > that make me less happy about contributing here is > both that I am not allowed to write the truth anymore. What would those truths be? Note: insults are not truths. > Anyway: In the discussion about adding one of the > features you mention above, tests were posted that > showed this encoder to produce better (objective, > with all its disadvantages) quality using measurably > less cycles. > > > None of your claims are really true. > > Given how much you embarrassed us in the prores > discussion, I wonder why you make this claim;-) That is surprisingly rude. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel