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. 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;-) Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
