On 2/14/17, wm4 <nfx...@googlemail.com> wrote: > On Tue, 14 Feb 2017 09:51:54 +0100 > u-9...@aetey.se wrote: > >> On Tue, Feb 14, 2017 at 06:51:46AM +0100, wm4 wrote: >> > On Mon, 13 Feb 2017 18:51:39 +0100 >> > u-9...@aetey.se wrote: >> > >> > > Then abstracting a "mini-swscale" could become justifiable. >> > >> > And this is why we should probably reject this patch. >> > What you wrote paints a horrifying future. >> --^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > Note that we would have this discussion even if it'd speed up the h264 >> > decoder. Pissing all over modularization is not a good thing to do. >> -----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > If you really want to get anything applied, you should probably try >> > looking at outputting ycgco, which appears to be the native colorspace >> > of the codec (and convert it vf_colorspace, I guess). >> >> Dear wm4, >> >> Your readiness to give feedback and your endeavor to keep the high quality >> of the code are appreciated. Nevertheless: >> >> I kindly ask you to mind your use of disparaging terms >> (emotionally charged expressions like "horrifying" or "pissing" >> which attribute a negative quality or attitude to your opponent), >> the corresponding phrases are marked above for your reference >> >> and please check your data. >> >> For additional information I would suggest >> >> https://ffmpeg.org/developer.html#Code-of-conduct >> >> https://multimedia.cx/mirror/cinepak.txt >> >> the contents of this thread > > Nevertheless your patches are rejected.
Correct way in solving this is outputing in cinepak decoder actual native format that it uses and not do any conversions of colorspace which is currently done. Implement correct colorspace conversions of cinepak format to others in libswscale. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
