On 5/25/2019 6:03 PM, James Almer wrote: > 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?
Ah hell, whatever, just push it. Jeeb pointed out the reason you wrote this patch. Reverting this patch in the future should be trivial anyway. Anyone wants to write libavscale and solve this mess? > >> >> 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".
