On 4/26/18, 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. > > 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.
That was with default configuration for both of them. That's like comparing apples and oranges. I fail to see how that makes your statements true. > >> None of your claims are really true. > > Given how much you embarrassed us in the prores > discussion, I wonder why you make this claim;-) Now, this is just rude. I expected this all the time. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel