On 4/26/18, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > 2018-04-26 13:48 GMT+02:00, Paul B Mahol <one...@gmail.com>: >> 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. > > Which is not the most likely usecase?
Even if it is, that is unfair comparison. Because options and settings are incompatible. I hope you understand this. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
