On 5/25/2019 12:50 PM, Derek Buitenhuis wrote: > On 25/05/2019 04:25, James Almer wrote: >>> + >> >> Unnecessary empty line. > > Fixed. > >> Could we not? The idea is to eventually kill these, so we should at >> least try to not make them even more widespread... > > As far as I know, they can't be removed, as there isn't a simple replacement > for some of their functionality. Has this changed?
Paul tried to remove them, but as usual a billion obscure use cases and command lines started to behave differently and he gave up. I don't recall if the issue was in swscale or lavfi, but one of those seems to have some code deeply tied to these pseudo formats and no easy solution for it. > > Either we finally act on their """deprecation""", or we at least have > consistent behavior. e.g. libx264.c has almost this exact bit of code, and > users would expect libx265.c to behave the same. libx264 is a very old encoder. New encoders, including this one, vpx and aom, accept only yuv4xxp + color_range value. Is this change really necessary? Why did nobody request it before? > > As far as I'm concerned, until the YUVJ stuff is /actually/ behind deprecation > guards, it's deprecated in name only... for years. > > - Derek > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
